URL Structure

TL;DR — A URL is the address of a page. Good URLs are readable, lowercase, use hyphens between words, and describe what the page is about. But don’t expect URLs to move your rankings much — they’re mostly for crawling and for humans. The biggest mistake is changing URLs you don’t need to change.

What a URL is

A URL — Uniform Resource Locator — is the full address of a page on the web. Break one apart and you get a handful of pieces:

https://www.example.com/blog/url-structure/?ref=newsletter#anatomy
└─┬─┘   └┬┘ └────┬────┘└───────┬──────────┘└──────┬──────┘└──┬───┘
scheme  sub   domain         path             query string  fragment

• Scheme — https://. Use HTTPS; it’s the secure version and the expected default.
• Subdomain — www. (or blog., shop., etc.). Optional.
• Domain — example.com. Your site’s name.
• Path — /blog/url-structure/. The folders and the page “slug.” This is the part you usually control.
• Query string — ?ref=newsletter. Extra parameters, often for tracking or filtering.
• Fragment — #anatomy. Jumps to a spot on the page. Search engines mostly ignore it.

What makes a good URL

Keep it simple:

• Use words, not numbers. /blog/url-structure/ beats /p?id=4321.
• Use hyphens between words. red-shoes, not red_shoes or redshoes.
• Lowercase everything. Page and page can be treated as two different URLs.
• Keep it reasonably short and readable — short enough that a human can guess what’s on the page.
• Match your site structure. The folders should reflect how your site is organized.

The thing most people get wrong

URLs are a very small ranking factor. Google has said for years that keywords in a URL “have hardly any effect.” So don’t agonize over stuffing keywords into URLs, and — more importantly — don’t go renaming a bunch of existing URLs hoping it’ll boost rankings. It almost never does, and changing URLs carries real risk (broken links, lost equity if redirects are botched). If your URLs already work, leave them alone.

Want hyphens-vs-underscores in Google’s own words, the case-sensitivity gotchas, and how parameters waste crawl budget? Switch to the Advanced tab.

TL;DR — URL structure is mostly a crawling and comprehension concern, not a ranking lever. Keywords in URLs are a “very light weight” signal that fades once a page is indexed. Use hyphens (Google joins on underscores, separates on hyphens). Path casing can identify distinct URLs depending on server behavior, so mixed casing can create duplicate crawl paths. Parameters are the real crawl-efficiency risk. And changing existing URLs helps “very, very rarely” — so don’t, unless they’re genuinely broken.

Anatomy of a URL

Every URL decomposes into the same parts, and each has its own SEO implications:

Reserved characters must be percent-encoded per the standard; use non-ASCII text in your users’ language (transliterated where it helps) rather than gibberish IDs.

Do URLs affect rankings? Barely.

This is the question everyone actually wants answered. The honest answer: minimally.

• Keywords in the URL are, per Google’s own Starter Guide, a factor where “the keywords in the name of the domain (or URL path) alone have hardly any effect beyond appearing in breadcrumbs.” John Mueller has called it “a very small ranking factor” and “a very light weight factor… less so after [the page is] indexed.” So a keyword in the URL might help Google during initial discovery, before it has crawled the content — but once the page is indexed, the content does the talking.
• What matters more than URL wording is click depth — how many clicks from the homepage a page sits. Logical directory structure helps Googlebot estimate crawl frequency (a /policies/ folder rarely changes; /promotions/ changes often), but that’s about crawling, not ranking.

Bottom line: don’t restructure URLs purely to inject keywords. The juice isn’t worth the squeeze.

Hyphens vs. underscores

This is the one genuinely settled technical rule, and it’s Google-specific.

Google treats a hyphen as a word separator and an underscore as a word joiner. So red_shoes is parsed as the single token redshoes, while red-shoes is parsed as red and shoes. Gary Illyes’ reasoning: “many things on the internet have an underscore in them, [Google] can’t easily segment at underscore.” Matt Cutts said the same back in 2007 (“we still join on the underscore and separate on the dash”), and Google’s current docs still recommend hyphens.

There’s a wrinkle worth knowing: Mueller once said in 2016 the difference “doesn’t matter,” which muddied things — but the live documentation still says use hyphens, and that’s the safe call.

Bing is different. A Bing spokesperson confirmed: “We do not differentiate between dash and underscore in our URL ranking features.” So underscores don’t hurt you in Bing. But since you’re optimizing for both, use hyphens — it’s correct for Google and neutral for Bing.

URL length and the canonicalization myth

You’ll hear “shorter URLs rank better.” That’s a misreading.

URL length has no direct ranking impact. What’s true is narrower: when Google is choosing a canonical among duplicate or near-duplicate URLs, it may prefer the shorter, cleaner one — specifically a clean URL over the same URL with tracking parameters tacked on. As I put it in my canonicalization research: “This has been misconstrued over the years by SEOs to say that all your URLs should be shorter. But that’s not what was meant.” The preference is for a clean, parameter-free version over a parameter-heavy duplicate — not a universal “shorter wins” law. URL length is just one of roughly 40 canonicalization signals Google uses, alongside HTTPS preference, www vs non-www, trailing slash, and casing.

Case sensitivity is a real risk

URL paths, filenames, and query parameters are case-sensitive; the hostname is not. So example.com/Apple and example.com/apple are two different URLs (but Example.com and example.com are the same host).

Google can usually tell when two casings serve identical content and will canonicalize them — but you shouldn’t make it do that work. If both versions are reachable and not consolidated, you get duplicate content. And there’s a sharp edge most people miss: robots.txt is also case-sensitive. A Disallow entry for /Private/ does not block /private/. Standardize on lowercase and you sidestep all of it.

Exactly which casings resolve, redirect, or 404 depends on your server and application config — it’s not a universal rule. Test the actual responses (curl -I or a crawler) rather than assuming.

Trailing slashes

A trailing slash matters everywhere except the root:

• Root domain: example.com and example.com/ are treated identically — no difference.
• Everything else: example.com/page and example.com/page/ are different URLs. If both are reachable and neither consolidates to the other, that’s duplicate content.

Note that adding a trailing slash to an actual file (page.html/) won’t load the file. As I wrote in my trailing slash guide: “There’s always a risk with changes, so unless your setup is causing issues I wouldn’t try to force a change to your URLs.” Pick one format, enforce it with redirects and canonicals, and keep internal links consistent. As with casing, the actual non-root behavior is server- and application-dependent — verify what your setup actually returns rather than assuming.

URL parameters: the real crawl problem

Query parameters are where URL structure does the most SEO damage at scale. I split them two ways in my URL parameters guide:

• Active parameters change page content — filtering, sorting, pagination, language, on-site search.
• Passive parameters don’t change content — affiliate IDs, UTM tags, session IDs.

Both cause trouble. Passive parameters on internal links create duplicate URLs and waste crawl budget; active parameters (especially faceted filtering) can generate near-infinite URL combinations — a classic spider trap. Google’s own ecommerce guidance warns about exactly this: content getting missed, the same content crawled repeatedly, and the crawler thinking your site has infinite pages because a URL contains a continually changing value like a timestamp.

How to control them:

• rel=canonical is the primary lever now — point variants at the clean URL. For optional variant parameters, Google recommends using “the URL with the query parameter omitted as the canonical URL.”
• noindex where a parameter page genuinely shouldn’t be in the index.
• robots.txt to keep bots out of clearly junk parameter spaces (but remember it controls crawling, not indexing).
• And for tracking specifically: use analytics event tracking instead of URL parameters where you can — most analytics systems can record the data without bloating your URLs.

One historical note: Google’s old URL Parameters tool in Search Console was deprecated and removed in 2022. Canonical tags are the replacement.

What a clean URL looks like

Pulling it together, the target format:

• Descriptive words, not numeric IDs
• Lowercase
• Hyphens between words
• HTTPS
• No unnecessary parameters
• Reflects your site’s directory structure
• Stable and permanent (URLs you won’t need to change)

Should you change your URLs? Almost never.

This is the most important practical takeaway. John Mueller, asked whether changing URLs for SEO helps: “Will it help the site? Very, very rarely… Will a change negatively affect the site for a while until it’s reprocessed? Probably.”

Justified reasons to change URLs are narrow: genuinely cryptic/unreadable URLs (example.com/p?=123), outdated references baked into the URL, or fixing a findability problem — not a cosmetic preference for shorter, cleaner, or more keyword-rich paths on URLs that already work. If a concrete defect does justify a change, do it as a real migration, not a spot fix: build a complete old-to-new URL mapping covering every affected path, put direct, permanent (301) redirects on each one (avoid redirect chains through an intermediate old URL), update internal links and canonical tags to point straight at the new URLs, update your XML sitemaps, and use the change-of-address tooling where it applies. Then monitor both the old and new URLs afterward — crawl stats, Search Console coverage, and server logs — rather than assuming the redirect map is complete because a few sample URLs worked. Solid redirect management reduces the risk of losing equity, but neither Google nor anyone else guarantees a recovery timeline or that rankings carry over unchanged. The permanence angle matters more than ever now that AI assistants cite URLs: broken-on-change links become broken citations.

Where this sits

URL structure overlaps with several neighbors in the website-structure and crawling worlds: canonicalization (the ~40 signals that pick a representative URL), URL parameters (the deep dive on active vs passive), trailing slash handling, site architecture and crawl depth (where click depth, not URL wording, does the real ranking work), and redirects (how you move URLs without losing equity). Each is its own deep dive.

AI summary

A condensed take on the Advanced version:

• A URL has six parts: scheme (https://), subdomain, domain, path/slug, query string (?key=value), and fragment (#section). Hostname isn’t case-sensitive; the path is.
• URLs barely affect rankings. Keywords in the URL are, per Google, a signal with “hardly any effect beyond appearing in breadcrumbs” — “very light weight” and fading once indexed. Click depth matters more than URL wording.
• Hyphens vs underscores (Google-specific): Google separates on hyphens and joins on underscores, so red_shoes = redshoes. Use hyphens. Bing doesn’t differentiate between the two.
• URL length isn’t a ranking factor. The “shorter wins” idea is a misreading of canonicalization: Google may prefer a clean URL over the same URL with parameters — not “shorter is better” universally.
• Case sensitivity is a duplicate-content risk. Paths/filenames are case-sensitive (/Apple ≠ /apple); so is robots.txt. Standardize on lowercase.
• Trailing slash: identical only on the root domain; everywhere else /page ≠ /page/.
• Parameters are the real crawl problem — passive (UTM, session, affiliate) and active (filter/sort/paginate) parameters create duplicates and crawl waste. Control with rel=canonical (primary), noindex, robots.txt; the GSC URL Parameters tool was removed in 2022.
• Changing URLs helps “very, very rarely” (Mueller) — only for truly broken/ cryptic URLs or a concrete defect, never for cosmetic preference. When justified, treat it as a full migration: complete old-to-new URL mapping, direct 301s, updated internal links/canonicals/sitemaps, and monitoring of both old and new URLs afterward — with no guaranteed recovery timeline.

Official documentation

Primary-source documentation from the search engines.

Google

• URL structure best practices — hyphens over underscores, descriptive paths, case consistency, minimal parameters, percent-encoding.
• SEO Starter Guide — URLs as breadcrumbs in results; keywords in the URL path “have hardly any effect.”
• Canonicalization — selecting the representative URL; the common duplicate-URL scenarios (HTTP/HTTPS, www, trailing slash, casing, parameters).
• Designing a URL structure for ecommerce sites — missed content, duplicate crawling, infinite crawling; descriptive paths over numeric IDs; omit-parameter canonicals.

Bing / Microsoft

• Bing Webmaster Guidelines — keep URLs short and keyword-rich; avoid session variables and docIDs.
• Better than canonical — URL Normalization — Bing’s preferred way to collapse parameter variations.

Quotes from the source

On-the-record statements from Google and Bing. Each link deep-links to the quoted passage where the source page supports it.

Hyphens vs. underscores

• “We recommend using hyphens (-) instead of underscores (_) to separate words.” — Google Search Central, URL structure docs. Jump to quote
• Gary Illyes (Google), on why: Google recommends dashes because “many things on the internet have an underscore in them, they can’t easily segment at underscore.” Coverage
• Matt Cutts (Google), 2007: “We still join on the underscore and separate on the dash.” Coverage
• Bing spokesperson: “We do not differentiate between dash and underscore in our URL ranking features.” Coverage

Keywords in URLs

• Google SEO Starter Guide: “the keywords in the name of the domain (or URL path) alone have hardly any effect beyond appearing in breadcrumbs.” Jump to quote
• John Mueller (Google): keywords in URLs are “a very light weight factor” — and matter even less once a page is indexed. Coverage
• John Mueller (Google): URLs “provide minimal additional signals for search engines.” Coverage

URL length / canonicalization

• Google: when deduplicating, it tends to pick the shorter, cleaner URL as canonical — not a universal “shorter ranks better” rule. Coverage

Case sensitivity

• John Mueller (Google): URL path, filename, and query parameters are case-sensitive; the hostname is not — and robots.txt is case-sensitive too, so be consistent. Coverage

Changing URLs

• John Mueller (Google): “Will it help the site? Very, very rarely… Will a change negatively affect the site for a while until it’s reprocessed? Probably.” Coverage

URL audit checklist

A pass to catch the URL problems that actually cause trouble:

• HTTPS everywhere — no HTTP URLs reachable without redirecting to HTTPS.
• One canonical host — www vs non-www consolidated to a single version.
• Lowercase consistently — no mixed-case paths creating duplicates; check that robots.txt rules match the casing actually used.
• Hyphens, not underscores or run-on words, separating words in slugs.
• Trailing slash decided and enforced — one format site-wide (root domain excepted), with redirects + canonicals backing it.
• Descriptive slugs, not numeric IDs (/url-structure/ not /p?id=4321).
• Parameters under control — passive tracking params (UTM, session, affiliate) aren’t on internal links; active params (filter/sort) have canonicals pointing to the clean URL.
• No spider traps — faceted nav, calendars, or timestamped URLs aren’t generating near-infinite URL spaces.
• Fragments aren’t used to differentiate content (Google ignores them).
• Reserved/non-ASCII characters percent-encoded correctly.
• Both URL versions aren’t both indexed — check GSC for split reporting across casing, slash, or parameter variants.
• No needless URL changes planned — if URLs work, leave them; if a concrete defect justifies a change, a complete old-to-new URL mapping, direct 301s, updated internal links/canonicals/sitemaps, and post-change monitoring of both old and new URLs are queued (not just a redirect and a sitemap ping).

The mental models

1. URLs are for crawling and humans, not ranking. Before optimizing a URL, ask what you’re actually trying to improve. Keywords in the URL are “very light weight.” Readability and crawl efficiency are the real payoffs — so optimize for those, not for an imagined ranking bump.

2. Consistency beats optimization. The damage from URLs comes from inconsistency — mixed casing, both slash versions live, the same page reachable with and without parameters. Pick one clean format and enforce it. A consistent “imperfect” scheme beats an “optimal” scheme applied unevenly.

3. The duplicate-URL quadrants. Most URL SEO problems are one page reachable as many URLs: HTTP/HTTPS, www/non-www, slash/no-slash, casing, and parameters. Each is a canonicalization decision. Map which variants exist, then consolidate with redirects (for hard cases) or canonicals (for soft ones).

4. Parameters: active vs passive. Passive params (tracking) should never change content and ideally never hit an internal link — push that data to analytics events. Active params (filter/sort/ paginate) change content and need deliberate canonical/index handling so they don’t explode into a spider trap.

5. The change-a-URL decision rule. Default to no. Only change a URL if it’s genuinely cryptic, broken, or unfindable — and never for a marginal keyword gain. When you do, 301 + sitemap + change-of-address, every time. Mueller’s “very, very rarely” is the prior.

URL best practices — cheat sheet

Tools for auditing URL structure

• Canonicalization Checker — test whether a parameter, case, or format variant sends consistent canonical and indexability signals.
• Redirect Chain Mapper — inspect every hop before a URL reaches its preferred HTTPS, hostname, path, and slash format.
• Redirect Checker — run fast spot checks when a small set of renamed or normalized URLs ships.
• A full-site crawler — inventory paths, parameters, canonicals, status codes, and internal-link destinations at scale; group variants before deciding whether they are duplicates.
• Server logs and Search Console — confirm which URL forms bots actually request and which ones Google records, rather than judging structure only from a template.

URL tools can show inconsistency, but they cannot justify a migration on their own. Changing stable URLs still requires a business reason, a complete redirect map, and proof that the expected benefit outweighs the transition risk.

Test yourself: URL Structure

Five quick questions on how URLs are built and what actually matters for SEO. Pick an answer for each, then check.

Resources worth your time

My related writing

• Trailing Slash: To Use or Not to Use? — when the slash matters (and the root-domain exception).
• URL Parameters: A Complete Guide for SEOs — active vs passive parameters and how to control them.
• Google Uses ~40 Canonicalization Signals — including HTTPS, www, slash, casing, and the shorter-URL preference explained.
• Redirects for SEO: A Simple (But Complete) Guide — moving URLs without losing equity.
• The Beginner’s Guide to Technical SEO — where URL structure fits the bigger picture.

My speaking

• A Crash Course in Technical SEO (SlideShare, Beer & SEO Meetup) — includes URL structure.
• Troubleshooting Technical SEO Problems (SlideShare, Raleigh SEO Meetup) — URL issues in context.

From around the industry

• URL structure best practices (Google Search Central) — the canonical do/don’t list.
• Google & Bing (Still) Handle Underscores & Dashes Differently (Search Engine Land) — the hyphen/underscore split, with the Bing quote.
• Changing URLs for SEO reasons: When is it OK? (Search Engine Land) — the “very, very rarely” Mueller guidance.
• Google Says Words In A URL Are A Very Light Weight Factor (Search Engine Roundtable).
• Reminder: Google On Case Sensitivity For URLs (Search Engine Roundtable).
• Google: We Pick Shorter URLs For Canonicalization (Search Engine Roundtable) — the source of the misread “shorter wins” idea.
• Better than canonical — URL Normalization (Bing Webmaster Blog) — Bing’s parameter-collapsing approach.

URL Structure

URL structure is how the parts of a web address — scheme, domain, path, query string, and fragment — are organized and formatted. It mostly affects crawling, usability, and how engines understand a page, not rankings directly.

Related: Canonicalization, URL Parameters

URL Structure

A URL (Uniform Resource Locator) is the full address used to identify a resource on the web. URL structure is how its components are organized and formatted: the scheme (https://), an optional subdomain (www.), the domain (example.com), the path (/folder/page/), an optional query string (?key=value), and an optional fragment (#section).

Most of what URL structure does is for crawling, usability, and comprehension — not ranking. Google describes keywords in the URL path as having “hardly any effect beyond appearing in breadcrumbs,” so URLs are a very light-weight signal at best. Where structure genuinely matters is the technical side: hyphens vs. underscores (Google treats - as a word separator and _ as a word joiner; Bing makes no distinction), case sensitivity (paths and filenames are case-sensitive, so mixed casing can spawn duplicate URLs), trailing slashes, and query parameters that multiply duplicate or low-value URLs.

The practical rule is consistency over optimization. Pick one clean format — lowercase, hyphen-separated, descriptive words, minimal parameters — and stick to it. Changing existing URLs almost never helps SEO and carries real risk, so reach for 301 redirects only when URLs are genuinely broken or unreadable.

Related: Canonicalization, URL Parameters

Changelog