URL Structure Best Practices: How to Build URLs Google and Users Can Actually Read

This post covers how to construct a new URL: length, word choice, separators, folder depth, and consistency rules. It does not cover what to do when two URLs serve the same content; that’s a duplicate-content problem, and the fix lives in canonical tags, which get their own dedicated coverage elsewhere on this site. If you came here looking for how to handle ?session_id= or ?utm_source= in your URLs, that’s a canonical and parameter-handling question, not a construction question, and you’ll get a more useful answer from that content than from this one.

What Google Has Actually Said About URL Structure and Ranking

Most “URL best practices” articles imply that a clean URL is a ranking lever. It isn’t, at least not directly. Google’s own URL structure documentation frames the guidance around crawlability and user experience, not rankings. John Mueller has been explicit on this point in Search Console community threads and office-hours discussions: URL length and keyword presence in the URL are not ranking factors in themselves. The one place URL characteristics do matter is indirect: Google has described using URL similarity as one of many, very lightweight signals when it has to pick a canonical URL among near-duplicates, not as something that boosts one page over a genuinely different competing page.

That distinction matters because a lot of older SEO advice treats “put your keyword in the URL” as a meaningful ranking tactic. It’s not fabricated so much as overstated. There’s no published, precise percentage for how much URL structure affects anything, and any article that gives you one (a specific “0.1% ranking impact” or similar) is presenting a number Google has never confirmed. The honest version: URL structure is about making pages easy to crawl, easy to read at a glance, and easy to share, not about squeezing out a ranking edge.

One related, real, and checkable claim worth keeping distinct from the vague “keywords in URLs help rankings” idea: Google’s exact-match domain (EMD) update, which Search Engine Journal’s history of Google algorithm updates dates to late September 2012, specifically targeted low-quality sites that were ranking largely on the strength of owning a domain name that exactly matched a search query. Matt Cutts described it at the time as affecting a small percentage of English-language US queries, and its effect was to reduce, not eliminate, the weight a domain name carrying an exact keyword match could carry when the site behind it was thin. That’s a real, dated, citable event. It’s evidence that domain and URL wording have never been a reliable shortcut to rankings on their own merit, not evidence that URL wording is actively harmful or irrelevant to include when it’s also the clearest, most natural way to describe the page.

Formatting Rules That Actually Hold Up

Lowercase. URLs are case-sensitive at the server level in most configurations, and /Blog/Post-Title and /blog/post-title can be treated as two different URLs, creating an accidental duplicate-content problem. Stick to lowercase everywhere.

Hyphens, not underscores. This is one of the few URL-structure claims Google has stated directly and consistently: hyphens are treated as word separators, so url-structure-best-practices is read as four distinct words. Underscores are not reliably treated as separators, so url_structure_best_practices risks being read as one long token. Google’s guidance on this has held for years and is worth following exactly as stated, not as a stylistic preference.

Length: two different limits, not one. There’s a real technical ceiling and a separate practical SEO recommendation, and conflating them causes bad advice. On the technical side, most browsers and servers reliably handle URLs up to roughly 2,000 characters before something in the chain (a proxy, an older server config, a sharing platform) starts truncating or rejecting them. That’s an infrastructure constraint, not an SEO one. Separately, for readability and shareability, SEO guidance generally recommends keeping URLs well under that, often cited in the 50-60 character range for the path itself, because a URL a person can read and remember at a glance is more useful in search results, in a shared link, and in a browser address bar than one that’s technically valid but meaningless to a human.

Word choice and stop words. A URL should describe the page in plain, natural language, the same words a person would actually use to talk about the content, not a keyword-stuffed string. /blog/how-to-fix-a-leaking-faucet reads clearly and tells both a person and a crawler exactly what’s on the page. Stripping small connecting words entirely (/blog/fix-leaking-faucet) shaves a few characters but isn’t a meaningful improvement either way; there’s no evidence Google penalizes or rewards the presence of “a,” “to,” or “the” in a URL path. The actual failure mode to avoid is the opposite direction: repeating a keyword multiple times in one path (/plumbing/plumbing-services/emergency-plumbing-services-atlanta) in an attempt to reinforce relevance. That reads as manipulative to a human, and there’s no indication it does anything positive for a crawler either.

Hierarchy and Depth

Flat versus nested structure is a navigation decision more than an SEO one. A few working rules:

• Use subfolders when they represent a real content grouping a user would recognize (/blog/technical-seo/ for a technical SEO category), not as decoration.
• Avoid depth for its own sake. A page buried five folders deep with no real reason for that structure doesn’t help crawlers or users find it; it just adds unnecessary path length.
• If in doubt, ask whether the folder structure would make sense to someone reading the breadcrumb trail out loud. If it wouldn’t, it’s probably not adding value.

A concrete comparison makes the difference clearer. /products/kitchen/appliances/small-appliances/countertop/toasters/stainless-steel-4-slice-toaster is technically descriptive but six folders deep before reaching the actual product; a visitor or crawler has to traverse a hierarchy that mirrors an internal warehouse taxonomy rather than how anyone actually shops. /products/toasters/stainless-steel-4-slice-toaster gives up almost nothing (the product category is still explicit) while cutting the depth to something a breadcrumb trail can display cleanly and a visitor can mentally track. The test isn’t “fewer folders is always better,” it’s whether each folder in the path represents a grouping someone browsing the site would actually recognize and use to navigate, not an internal categorization scheme surfaced directly into the URL.

Consistency Basics

These are largely settled problems by 2026, worth stating plainly rather than over-explaining:

Decision	Standard	Why
HTTPS vs HTTP	HTTPS everywhere	Baseline expectation for both browsers and search engines; not a debate anymore
www vs non-www	Either is fine, pick one	Google treats both as valid; the failure mode is inconsistency, not the choice itself
Trailing slash	Pick one, apply site-wide	<!–INLINECODE12–> and <!–INLINECODE13–> can resolve as separate URLs if not redirected consistently
Case	Lowercase only	Prevents accidental duplicate URLs on case-sensitive servers

Once a standard is picked, the actual work is enforcement: making sure internal links, sitemaps, and server redirects all point to the same version consistently, rather than mixing www.example.com/page/ in one place and example.com/page in another.

Subdirectory vs. Subdomain

For content sections like a blog or help center, the subdirectory approach (example.com/blog/) is generally the simpler default: it keeps the content under the same root domain, which tends to consolidate authority signals and simplifies analytics and crawling. A subdomain (blog.example.com) makes sense when the section is run on genuinely different infrastructure (a separate CMS, a different team, a third-party help desk platform that only supports subdomain deployment) and the operational separation outweighs the consolidation benefit. Neither choice is inherently better for rankings; it’s a practical infrastructure decision more than an SEO one.

When You Have to Change a URL

Sometimes a URL has to change: a redesign, a category rename, a platform migration. When it does, a 301 redirect from the old URL to the new one is the safety net, and the goal is a single, direct redirect rather than a chain (old URL to an intermediate URL to the final URL). Redirect chains slow crawling and can dilute the signal Google uses to consolidate the old page’s history with the new one. The mechanics of diagnosing and fixing redirect chains are covered in depth elsewhere on this site; the short version here is simple: change the URL when there’s a real reason to, redirect it once, and don’t let chains accumulate over multiple redesigns.

Quick Checklist

• Lowercase throughout, no exceptions
• Hyphens between words, never underscores
• Path length reasonable for readability, well under the ~2,000-character technical ceiling
• Folder depth reflects a real content hierarchy, not arbitrary nesting
• HTTPS, one www/non-www choice, one trailing-slash convention, all enforced consistently
• Subdirectory for content sections unless there’s a real infrastructure reason for a subdomain
• Single-hop 301 redirects when URLs change, never chains

Conclusion

Good URL structure is mostly a crawlability and readability discipline, not a ranking hack. Get the mechanical parts right (lowercase, hyphens, reasonable length, consistent protocol and domain formatting), keep the hierarchy honest to the actual content structure, and treat any claim of a precise ranking impact from URL formatting with skepticism, because Google has never published one. What you build here is the foundation duplicate-content and canonicalization decisions get layered onto later, which is exactly where this post’s job ends and the canonical-tag content picks up.