URL Structure

URL structure is the naming convention of your web addresses — the protocol, hostname, path segments, and how words are separated and cased within them. It's the address system your site architecture gets written down in: the hierarchy decides where a page belongs, the URL structure decides what that location is called.

The stakes are asymmetric, and that's the key thing to understand about URLs. A good URL earns you modest, steady benefits: a readability bump in the SERP, a keyword relevance whisper, links that don't break, analytics you can actually segment by folder. A bad URL system costs you enormously — duplicate content from uppercase/lowercase variants, redirect chains from every restructure, session IDs spawning infinite crawl space. You optimize URLs less to win and more to not lose. And because every URL change requires a redirect, this is a decision you effectively make once. Get the convention right before page one ships.

Good and bad, side by side

The same product page, five ways it ships in the wild:

https://example.com/coffee/grinders/baratza-encore/        ← the target
https://example.com/index.php?id_product=1287&controller=product
https://example.com/Coffee/Grinders/Baratza_Encore
https://example.com/coffee/coffee-grinders/coffee-grinder-baratza-encore-conical-burr-coffee-grinder/
https://example.com/p/1287/

The first is readable by a human, guessable, hierarchical, and stable. The second is a raw CMS query string — crawlable, but zero information scent and prone to parameter permutations. The third works until someone links to the lowercase version and you discover URLs are case-sensitive and you're indexing both. The fourth stuffs "coffee" in four times and reads like spam because it is a spam pattern. The fifth is stable and short but wastes the one chance a URL gets to say what the page is.

Patterns that work and patterns that bite

How to check it on your own site

1. Crawl the site and export All URLs. Sort alphabetically and skim — inconsistencies (mixed case, mixed separators, stray extensions, date folders) jump out fast in a sorted list.
2. Test the variants by hand: request a URL with uppercase, with and without trailing slash, with www and without, over http. Exactly one variant should 200; everything else should 301 in one hop to it.
3. In Screaming Frog, check the URL tab filters — Uppercase, Underscores, Parameters, Over 115 Characters, Multiple Slashes, Repetitive Path. Each filter is a pre-built audit finding; repetitive-path URLs in particular are covered in depth in the repetitive path check.
4. Grep your redirect map for chains: crawl, export the redirect report, and look for 301 → 301 → 200 sequences. Chains are the fossil record of past URL restructures, and each hop leaks.
5. Check GSC's page indexing report for "Duplicate without user-selected canonical" — URL-variant duplication shows up there before you notice it anywhere else.

Common mistakes

• Changing URLs for cosmetic reasons. The most damaging URL mistake is churn. Renaming /blog/seo-tips/ to /insights/seo-tips/ because marketing rebranded costs redirects, temporary rankings volatility, and split signals — for zero search benefit. URLs are infrastructure; renovate only with a structural reason.
• Category paths baked into product URLs. /camping/tents/msr-hubba/ looks tidy until the product gets recategorized and the URL either breaks or lies. On catalogs where items move, keep products at a stable path (/products/msr-hubba/) and let categories be the browse layer. E-commerce specifics — variants, out-of-stock handling — are covered in the product page SEO guide.
• Letting the CMS append -2 forever. /contact-2/, /home-3/ — the slug collision leftovers of deleted drafts, live and indexed. Audit for numeric-suffix slugs; they're almost always accidents.
• Fixing redirects at the map instead of the source. After a restructure, teams add redirects and stop. The internal links still point at old URLs, so every crawl walks the redirect graph forever. Update the hrefs.
• Believing slug keywords will move rankings. They barely do — the controlled comparisons in the URL length and format study found format effects are small next to content and links. Which is exactly why re-slugging existing pages "for SEO" is negative expected value: real migration cost, negligible upside.

FAQ

Do keywords in the URL help rankings?

Marginally — it's a confirmed but lightweight signal, and most of the visible benefit is human (readability in SERPs, cleaner anchor text when the bare URL gets pasted). Write slugs for people; the keyword lands naturally because the slug describes the page.

How long is too long for a URL?

There's no ranking penalty at a specific length, but past ~75–100 characters URLs truncate in SERPs, break awkwardly when shared, and usually indicate slug stuffing or excessive nesting. Short enough to read aloud is a decent test.

Should I remove dates from my blog URLs?

On a new site, don't include them for evergreen content. On an existing site with rankings, removing them is a migration — worth it only if you're systematically refreshing that content anyway and can eat the redirect cost as part of a bigger project. Never do it casually.

Subfolder or subdomain for the blog?

Subfolder, absent an infrastructure reason. This is really a site architecture question — the URL is just where the decision becomes visible.

What about query strings — are they bad URLs?

Parameters are legitimate machinery (pagination, tracking, filtering); they're a problem when they create indexable duplicates or infinite spaces. That's its own discipline with its own handling table — see URL parameters.