URL structure

What a URL actually encodes

Every page you will ever rank, link to, or migrate is reachable through one string, and that string is the only stable identifier Google holds across the whole life of the document. The title gets rewritten: Ahrefs reports Google changed displayed title tags 76.04 % of the time on Q1 2025 data. The meta description gets replaced by a snippet lifted from the body. The H1 sits inside a rendered DOM that may or may not survive a JavaScript failure. The URL is what remains constant. Treat it as an identifier first, and as a ranking lever a very distant second.

The acronym repays unpacking, because it explains the design. Uniform, because the syntax is the same whatever the scheme: a mailto: address and an https: web address parse under the same grammar. Resource, because what sits at the other end is not necessarily an HTML document, it can be a JSON payload, an image, a redirect instruction. Locator, because it tells a browser where to go and how to get there, unlike a URN which names a resource without saying how to fetch it. That last distinction is mostly academic in day-to-day SEO work, but it explains why the specification is a general addressing grammar rather than a web page format.

One consequence of that grammar bites constantly in audits: the host component is case insensitive, the path is not. /Guide/ and /guide/ are two different resources under the specification, and two different URLs in the index, even when your server cheerfully returns 200 for both. Same story for the trailing slash: /blog/url-structure and /blog/url-structure/ are distinct strings, and only a redirect or a declared canonical version tells Google which one you meant.

Anatomy: why the answer is five, six or nine parts

Ask three SEOs how many parts a URL has and you get three numbers. All of them are defensible. They cut the same string at different depths, and the confusion in the SERPs on this question comes from nobody saying so out loud. Take a full example: https://www.example.com:443/blog/url-structure/?utm_source=newsletter&page=2#anatomy.

RFC 3986, published by the IETF as STD 66, specifies five top-level components. The scheme (https) names the protocol and ends at the colon. The authority (www.example.com:443) says which server answers, and may itself carry userinfo and a port. The path (/blog/url-structure/) identifies the resource inside that authority. The query (utm_source=newsletter&page=2), introduced by a question mark, carries key/value pairs. The fragment (#anatomy), introduced by a hash, points inside the resource and is never sent to the server.

The six-part count appears when you promote the port, or the userinfo, out of the authority and treat it as a component of its own. The nine-part count, the one people search for, comes from decomposing further: subdomain (www), second-level domain (example), top-level domain (com), port, path segments, individual parameter keys and values, and the fragment. Neither is wrong. The specification defines five; the SEO reading splits the authority and the query because those are the pieces you actually manipulate. What matters operationally is knowing which layer you are talking about when you say «the domain», because a subdomain and a path folder do not behave the same way in crawl, in consolidation, or in how a media buyer values a placement.

Two components deserve more respect than they usually get. The query string is not decoration: it is the surface through which a template can generate an unbounded number of addressable URLs, which is how a 400-page catalogue becomes a 400,000-URL crawl problem. The fragment is the opposite, a client-side pointer the server never sees, which is precisely why using it to switch page content leaves Google with a single URL and no way to address the variants.

What Google's 2025-2026 documentation actually asks for

Google refreshed its URL structure guidance on 10 December 2025, and the update is unusually prescriptive for a Search Central page. Crawlable URLs should follow IETF STD 66. The fragment should not be used to change page content. Query strings should use conventional encoding, an equals sign between key and value, an ampersand between parameters, rather than a homemade separator scheme. And dynamic URLs generated by internal search, calendars, sorting and filtering should be controlled when they create crawl inefficiency. That last point is the whole faceted-navigation problem stated in one sentence, and it is a crawl budget question long before it is a ranking question.

Two clarifications landed a week later and both concern how the URL is resolved rather than how it is written. On 17 December 2025 Google spelled out that canonicalization happens both before and after rendering, so the canonical URL should be identical in the original HTML and in the rendered version; where that is impossible, Google recommends omitting the canonical from the raw HTML rather than shipping two conflicting signals. On 18 December 2025 it clarified that pages returning non-200 status codes may not be sent for rendering the same way a 200 is, which makes correct status codes and clean redirect handling decisive during a URL migration rather than merely tidy.

The documentation itself moved on 20 November and 17 December 2025: faceted navigation, crawl budget, HTTP status codes, DNS and network errors and robots.txt were folded into Google's broader crawling-infrastructure documentation, because the same crawlers now feed Search, Shopping, News, Gemini and other products. The functionality did not change, but the framing did, and it is a useful reminder that your URLs are being fetched by more consumers than the blue-link index.

Here is the stance worth holding: URL structure is not a documented ranking factor, and it never appears as one in Google's ranking-update record. The February 2026 ranking update ran 21 days 17 hours, the March 2026 one 12 days 4 hours, and neither dashboard entry says anything about URLs. When a section of a site loses visibility after a slug change, the evidence lives in crawl logs, canonical selection and the indexing report, not in the update timeline. Attributing a URL problem to a core update is how teams spend three weeks waiting instead of thirty minutes fixing.

Where URL structure decides the fate of a link

A backlink is an anchor plus a destination string, and the string is the fragile half. Anchors can be renegotiated; a destination that no longer resolves cannot. Every URL decision therefore has an off-site cost that on-page audits systematically ignore. Editorial.link's 2026 survey of 518 SEO professionals put the average acceptable price of a high-quality backlink at $508.95, and a 2026 survey of 500 SEO professionals found 58 % increased their link-building budgets while 75 % expect costs to rise over the next two years. Against numbers like those, what a single placement actually costs makes the case on its own: a slug renamed without a mapping is not a hygiene issue, it is a write-off.

Migrations are where this compounds. Google added a clarification on 17 June 2026 stating that the Change of Address process should account for all domain variants, including www and non-www subdomains. That is not a detail. Historical link profiles are almost always split across variants, and a migration that maps the apex cleanly while leaving the www host pointing at the old target strands whatever equity arrived there. Chained hops make it worse: each additional intermediate step in a permanent redirect from the old address is one more place for a rule to be dropped during a server config rewrite.

The same discipline applies on the acquisition side. Across the French editorial media we operate in-house, the destination URL a client supplies is the one that gets written permanently into an editorial paragraph, so we ask for the final resolved address rather than a redirecting one: a link that lands on a 301 works, a link that lands on a 301 that later becomes a 404 does not, and nobody edits a published article two years later to find out. If you want to see how that translates into a filterable inventory of hosts, the catalogue we publish openly, without an account shows the metrics per medium before any commitment.

What we see go wrong

The failure mode that costs the most is slug churn during a CMS replatform. A new system generates /2026/08/post-title/ where the old one produced /blog/post-title/, nobody exports the mapping, and six months of link acquisition lands on a soft 404. The second most expensive is parameter explosion on faceted navigation, where colour, size, sort order and pagination combine into a URL space larger than the catalogue, and the crawler spends its budget on filter combinations that no one will ever search for. Neither is a writing problem, both are architecture problems.

Then come the cheap, endemic ones. Uppercase letters in paths, usually leaking from a category name. Spaces encoded as %20 because an editor uploaded a file with a space in its name. Underscores where hyphens belong, which is a genuinely old rule but still true. Session identifiers in the query string. Internationalized domain names and accented paths that display fine in a browser and travel as punycode or percent-encoded bytes everywhere else, so the same page appears under two spellings in your own analytics. And single-page applications that route on the fragment, which the 10 December 2025 guidance rules out explicitly and which leaves you with exactly one indexable URL for a hundred views.

One 2026-specific cleanup: creating separate URL variants purely to chase FAQ rich results no longer has a payoff. Google announced on 8 May 2026 that the feature would stop appearing in Search from 7 May 2026. The URLs those pages live on can be consolidated or merged into the parent document, and the crawl paths they consumed can go back to pages that convert.

Working rules that survive a real site

Pick one canonical form and enforce it at the server level, not in the CMS: one protocol (https), one host variant, one trailing-slash convention, lowercase paths. Everything else 301s to it. Verify with a crawl rather than a spot check, because the duplicates you find by hand are never the ones that matter. Screaming Frog surfaces the case variants, the parameter families and the redirect chains in one pass; the page indexing report in Search Console tells you which of them Google actually chose as canonical, which is the only opinion that counts.

Keep paths shallow and readable, three segments at most for an article. The reason is not that depth is penalized, it is that deep paths correlate with weak internal linking, and depth in the link graph is what actually limits discovery. Descriptive slugs help humans decide whether to click a bare address pasted into a message, and they help you audit a 40,000-row crawl export at a glance. That is worth more than any marginal keyword effect.

Freeze the slug once a page has links. Refreshing content is not a reason to rename a URL; a rewritten article at the same address keeps its history intact. When a rename is genuinely unavoidable, ship the mapping in the same release as the change, update the internal links pointing to the old address rather than relying on redirects to absorb them, and check the canonical, the sitemap entry and the breadcrumb markup all agree on the new string. Three signals saying the same thing is what makes a migration boring, and boring is the goal.