URL structure for SEO: the six rules Google publishes, and one command to audit yours

A good url structure is readable words, hyphens between them, as few parameters as possible, and one casing you never vary. Google publishes this as a crawling requirement rather than a style preference: its page on the subject opens by telling you to "use a crawlable URL structure", and warns that if your URLs miss the criteria, "Google Search will likely crawl your site inefficiently — including but not limited to extremely high crawl rates, or not at all".

Before you start

This chapter is about designing addresses for pages that do not exist yet, or for a section you are about to build. Changing the address of a page that already ranks is a different job with its own damage list, set out in does changing a URL affect SEO. If you have two addresses serving the same page and need to pick one, that is how to use canonical tags, not this.

The url structure rules Google actually publishes

Six of them, and every one is short enough to check by eye. The wording below is Google's, retrieved 2026-08-29.

The hyphen rule comes with a reason attached, which is worth keeping because it explains the whole list: hyphens are preferred "as it helps users and search engines better identify concepts in the URL". The address is read, by people and by machines, before anything on the page is.

Underneath the six sits one more instruction, and it is the least quoted: follow IETF STD 66, the standard that defines what a URI is allowed to look like. Most of the list above is that standard restated in plain words. It matters because it tells you where the authority comes from — these are not preferences a search engine invented, they are the shape addresses were specified to have, and a router that violates them will break in places that have nothing to do with search.

A URL is the only part of your page that gets read before the page loads.

The parameters that cause the damage

Google names three kinds by example, and all three multiply one page into many addresses. Referral parameters such as ?click=6EE2BF1AF6A3D705D5561B7C3564D9C2, shopping sort parameters such as ?search_sort=relevance, and session IDs, where the documented alternative is blunt: consider using cookies instead.

Two more shapes get named as things to avoid. Broken relative links can generate an unbounded set of addresses, and calendar pages that link forward without a stop date do the same thing on purpose; Google's suggestion for the calendar case is to mark the forward links with nofollow. Both create work for a crawler that produces nothing for you.

There is also a rule about how content is selected. "Don't use URL fragments to change content" — the fragment after # is not sent to the server, so a page that swaps its content on fragment change has one address for many states. The documented replacement is the History API.

Do it: five steps for a new section

Twenty minutes once, then it is a template decision rather than a per-page decision.

1. Write the address before you write the page. If you cannot describe the page in three or four hyphenated words, the page has more than one subject and the address is telling you so.
2. Fix one casing, lowercase, and enforce it in the router. Google's page says plainly that URLs are case sensitive, which means /Handbook and /handbook are two pages until you decide otherwise.
3. Decide which parameters are allowed to change what a visitor sees. Everything else — tracking, sorting, session — should either not be in the address or should not produce a separate indexable page.
4. Pick the multi-regional shape now, not later. Google names country-specific domains such as example.de and country subdirectories such as example.com/de/; both are listed, and switching between them later means moving every address you have.
5. Run the audit below against your sitemap and fix what it prints, before the section has any links pointing into it.

Deliverable: audit every address in your sitemap

One command. It reads your sitemap and prints only the addresses with something wrong, so silence means clean.

curl -s https://example.com/sitemap.xml \
| grep -o '<loc>[^<]*</loc>' | sed 's/<[^>]*>//g' \
| python3 -c '
import sys, urllib.parse
for line in sys.stdin:
    u = line.strip()
    p = urllib.parse.urlparse(u)
    bad = []
    if "_" in p.path: bad.append("underscore")
    if p.path != p.path.lower(): bad.append("uppercase")
    if p.query: bad.append("parameters")
    if p.fragment: bad.append("fragment")
    if any(ord(c) > 127 for c in u): bad.append("unencoded non-ascii")
    if len(u) > 115: bad.append("length %d" % len(u))
    if bad: print(u, "|", ", ".join(bad))
'

The length threshold is ours, not Google's — the documentation sets no maximum, and 115 characters is simply where an address stops fitting in a search result or a chat citation without being cut. Treat that column as a prompt to look, not as a failure.

Three ways this goes wrong

Two of these are decisions that felt free at the time.

1. Putting the date in the address. /2024/03/how-to-x ages the page in public and makes a refresh look like an old page, and the only fix later is a move you did not need to make.
2. Renaming for tidiness. Every rename spends redirects, internal links and whatever the page had accumulated; the address being slightly better is almost never worth it.
3. Letting the CMS choose. Default addresses built from post IDs are the exact case Google names first, and they are hardest to change once a few hundred exist.

Where url structure stops mattering

None of this makes a page rank. Google presents the list as what it takes to be crawled efficiently, and the strongest claim in the documentation is about crawl behaviour, not position. A perfectly formed address on a page nobody can fetch does nothing, and whether a crawler reaches your pages at all is a separate check you can run with the AI crawler check.

We also cannot tell you how much a bad address costs, because no public number exists for that, and any figure you have seen attached to it was made up. The honest reason to get addresses right is that they are permanent and free at the moment of creation, and expensive at every moment after.

Common questions

Do hyphens or underscores matter for SEO?

Google recommends hyphens, in those words, because they help identify separate concepts in the address. Underscores are not an error; they are the less legible option.

How long can a URL be?

The documentation sets no limit. Shorter addresses survive being displayed in results and citations, which is a readability argument rather than a ranking one.

Should I use my own language in URLs?

Yes. Google's instruction is to use words in your audience's language, transliterated where that applies, and to percent encode anything outside ASCII.

Are URLs case sensitive?

Yes, and Google tells you to be aware of it. Serve one casing and redirect the other, or you have two addresses for one page.

Can I put parameters in a URL at all?

Yes, using the standard shape: an equal sign between key and value, an ampersand between pairs. Keep the ones that change what a reader sees and drop the ones that do not.

Should the address match the page title word for word?

No, and trying to make it match is how addresses get long. The title is a sentence written for a reader scanning results; the address is three or four words naming the subject. They should agree, not be identical.

Do I need a different domain for each country?

Not necessarily. Google lists country-specific domains and country subdirectories side by side, so both shapes are documented. Pick on the basis of what you can operate — a subdirectory is one deployment, a set of domains is several — and decide before the first localised page exists, because the two shapes do not convert into each other cheaply.