URLs are content, not addresses:
A URL is more than a web address. It’s a short, public description of the page that lives in search results and social shares. Read out loud, a good URL tells you what the page is about before you click.
That matters because URLs serve three audiences at once. Readers see them in search results and decide whether a link looks worth clicking. Search engines read them as one of many signals about page content; the signal is lightweight compared to page content, but it still contributes context. Browsers and sharing systems surface them wherever the link travels — a readable URL travels better than a string of parameters.
Most URL guidance comes down to readability. Most URL mistakes come from forgetting that someone, somewhere, is going to look at the URL and decide whether to click it.
Every URL has four jobs: protocol, host, path, slug:
A URL is built from layers. Each layer does one job.
https://example.com/blog/seo-fundamentals/url-structure
└─┬─┘ └────┬────┘└─┬─┘└──────┬──────┘└──────┬──────┘
│ │ │ │ │
protocol host path subfolder slugThe protocol is the front of the URL: https:// is the only acceptable answer in 2026. HTTP without the S is flagged as insecure in major browsers, and Google has confirmed HTTPS as a lightweight ranking signal since 2014.
The host is the domain name plus any subdomain. example.com is the root domain. blog.example.com is a subdomain, which Google treats as a separate site for ranking purposes.
The path is the folders that signal hierarchy — /blog/ or /products/ or /services/ — and each folder narrows scope. The slug is the final piece that names the specific page. /url-structure describes one article inside one folder inside one site.
The slug is the part writers control most often. The other three layers are usually set by the site architecture. But each piece contributes to whether the URL reads cleanly.
Read the URL out loud — does it describe the page?:
The test for a good URL is simple. Read it aloud. If it describes what’s on the page, it works. If it doesn’t, rewrite it.
Three principles produce URLs that pass this test:
| Bad URL | Good URL |
|---|---|
| <!–INLINECODE7–> | <!–INLINECODE8–> |
| <!–INLINECODE9–> | <!–INLINECODE10–> |
| <!–INLINECODE11–> | <!–INLINECODE12–> |
Each good URL describes its destination. Each bad URL forces the reader to click and find out.
The principles behind those good URLs come down to short, descriptive, lowercase. Short means under 60 characters when possible — long URLs get truncated when shared and become harder to remember. Descriptive means using words that match the page’s actual topic, since a URL is a chance to confirm what the page is about before the reader commits. Lowercase prevents duplicate content issues: some web servers treat /Page and /page as different URLs, and Google’s documentation recommends standardizing on lowercase to remove the ambiguity.
What doesn’t work is stuffing keywords. A URL like /best-running-shoes-running-shoe-reviews-best-shoes-for-runners doesn’t outrank a shorter alternative. Google has stated that URL words are a very lightweight ranking factor, not a way to boost rankings through repetition.
Hyphens separate, underscores connect:
Use hyphens between words. Not underscores.
Google’s documentation recommends hyphens specifically because the search engine treats them as word separators. A URL like /url-structure-best-practices is read as four distinct words. That makes the page discoverable for queries combining any of those terms.
Underscores work differently. Google reads /url_structure_best_practices as one word: urlstructurebestpractices. Matt Cutts confirmed this distinction in a 2011 Google video explaining the segmenter logic. The practical result: underscored URLs are less discoverable through keyword variations than hyphenated ones.
Two practical notes follow from this. Spaces in URLs get encoded as %20, which looks broken in browsers and email clients, so hyphens handle word separation in a way that survives sharing. And don’t change existing underscored URLs just to switch separators — Mueller has explicitly advised against this, since the redirect and recrawl cost outweighs the small readability gain. The hyphen rule applies to new URLs.
For domain names themselves, the opposite advice applies. Hyphens in domains look spammy and hurt brand recall. Underscores in domains aren’t valid in most registrars. The hyphen-as-separator rule is for paths and slugs, not the domain itself.
Cut the and, the of, the for:
Stop words are short, common words that connect other words: “and,” “the,” “of,” “for,” “a,” “to,” “in.” They appear constantly in titles and headlines. They usually don’t belong in URLs.
The reason isn’t SEO weight. Mueller has stated directly that stop words in URLs don’t matter for ranking. The reason is readability and length.
Compare /the-complete-guide-to-writing-meta-descriptions-for-your-website against /writing-meta-descriptions. Same topic. Same page. The second one fits in a tweet and displays cleanly on mobile.
The pattern for trimming is straightforward. Remove articles like “the,” “a,” “an” — they almost never carry meaning in a URL context. Remove prepositions (“for,” “of,” “to,” “in”) when the relationship is obvious from word order. Remove “complete,” “ultimate,” “best,” “guide-to” wrappers, since these signal nothing the reader can’t infer from the rest of the URL.
The exception: when removing a stop word makes the URL confusing or changes its meaning. /run-fast reads differently from /run-for-fast-relief. The shorter version isn’t always better; it has to still describe the page.
URL depth mirrors content depth, not page count:
URL hierarchy should reflect how content is organized, not how many pages exist. A site with three blog posts doesn’t need three layers of folders. A site with 5,000 product pages probably does.
Two patterns work, depending on size. A small site can use a flat structure where most pages sit one level below the root: /about, /services, /contact, /blog/url-structure. A larger site benefits from hierarchy: /products/running-shoes/road-running/nike-pegasus-40 or /blog/seo/on-page/url-structure. Google’s Gary Illyes has recommended hierarchical structure for larger sites and flat structure for smaller ones. Hierarchy helps users and crawlers understand topical relationships. Flat structure works when those relationships are simple enough that depth would be artificial.
The signals that you’ve nested too deep show up quickly. URLs with more than three or four folder levels in a typical path. Folders that exist solely to hold one page each. Path segments that don’t actually narrow scope, like /blog/articles/posts/. Going the other direction, signs that you’ve gone too flat include all pages sitting at the root level regardless of category. Search results can’t distinguish between similar topics. Users have no clear way to move up to a parent category.
URL hierarchy and breadcrumb navigation are related but distinct. Breadcrumbs are a UX element that shows the path on the page. URLs are the underlying structure. They often mirror each other, but the URL is the source of truth.
Parameters are exceptions, not defaults:
Query strings — the part of a URL after the ? — handle filtering, sorting, and tracking. They’re useful when the variation is real, like different filtered views of a product list. They’re a problem when they’re used for content that should have its own clean URL.
Common parameter patterns map to specific uses:
| Parameter type | Example | Appropriate use |
|---|---|---|
| Filter | <!–INLINECODE32–> | Product list refinements that don't need separate indexing |
| Sort | <!–INLINECODE33–> | View modifications of the same content |
| Tracking | <!–INLINECODE34–> | Analytics attribution; doesn't change content |
| Session | <!–INLINECODE35–> | User state; should usually not appear in indexed URLs |
| Pagination | <!–INLINECODE36–> | Sequential views of a list |
Google’s 2025 URL guidelines clarified parameter formatting. Use = between parameter names and values. Use & between parameters. Avoid colons and brackets in parameter values, since these characters carry syntactic meaning.
What to avoid: using parameters for content that deserves a stable, shareable URL. A product page at /product?id=4729 should be /products/nike-air-zoom-pegasus-40. The parameterized version is functional but fails the read-aloud test. It produces duplicate content issues when filters generate near-identical pages. It also limits how the URL travels in shares and citations.
Two specific risks come with parameter-heavy URLs. Duplicate content is the first: /category and /category?sort=newest may serve the same content, which splits ranking signals across two URLs. Canonical tags signal a preferred URL when duplicates exist — that’s a separate topic worth handling carefully. Crawl waste is the second: filter combinations multiply into thousands of URL variations, each consuming crawl budget. Google offers tools in Search Console for managing parameter handling at scale.
URLs are the smallest unit of context:
Google has stated that URL text is a very lightweight ranking factor. Mueller has confirmed that words in URLs play a tiny role for Google Search. The words become more relevant when Google is seeing a URL for the first time, before it has crawled the content.
But “lightweight” isn’t “zero.” URLs contribute in specific ways. They help Google’s first-pass classification when it encounters a new URL — the URL text assigns initial topical relevance before the page is fully indexed. They function as anchor text content when other sites link using the URL itself as the visible text. They appear in search results above titles on some queries, and breadcrumb-style URLs display more cleanly than parameter-heavy ones. They carry contextual weight in shares and citations, where a descriptive URL travels with more meaning than an opaque one.
The mistake is treating URL keywords as a ranking lever. They aren’t. The right framing is treating URLs as a small, consistent signal that compounds across thousands of links and shares over a page’s lifetime.
Every URL change is a redirect promise:
URLs are stable infrastructure. Once published, a URL is the destination for every external link, every shared post, every bookmark, every cached search result. Changing a URL breaks all of that unless you redirect properly.
The basic mechanic: when a URL changes, set up a 301 redirect from the old URL to the new one. A 301 tells search engines and browsers that the move is permanent and the new location should inherit the old URL’s signals.
Three rules govern URL changes. Don’t change URLs without a reason — “cleaner URL” alone usually isn’t worth the recrawl cost, so wait for an opportunity that justifies the disruption (site migration, restructure, brand change). Always 301, never let URLs 404. A page that returns a 404 after a URL change loses every external link pointing to it, while a 301 preserves the link equity. Update internal links too. External redirects work, but internal links should point to the new URL directly, since chains of redirects slow crawling and dilute signals.
This is a small section of a larger topic. Site migrations and mass URL changes are their own discipline. The principle here is simpler: every URL you publish is a promise that the URL will keep working, or that you’ll forward it cleanly if it doesn’t.
Seven URL anti-patterns:
Most URL problems on real sites cluster into a small set of patterns. Each has a clean fix.
- ID-based URLs.
/product?id=4729or/article.php?p=12345. Numbers describe nothing. Fix: rewrite to descriptive slugs that name the product or article topic.
- Mixed-case URLs.
/About-Usand/about-usmay resolve to the same page or different pages depending on server config. Ambiguity creates duplicate content risk. Fix: standardize on lowercase everywhere.
- Underscores between words.
/seo_url_best_practices. Google reads as one word. Fix: use hyphens. For existing underscored URLs that rank well, leave them alone.
- Keyword stuffing in slugs.
/best-running-shoes-running-shoe-reviews-shoes-for-runners. Repetition doesn’t boost ranking. Fix: pick one descriptive phrase. Cut repetitions.
- Trailing slash inconsistency.
/blog/postand/blog/post/treated as different URLs. Fix: pick one convention site-wide. Set up redirects so both forms resolve to the canonical version.
- Session IDs in indexed URLs.
/page?sid=8a2b9c. Each visit generates a new URL. Crawl waste and duplicate content. Fix: use cookies for session state. Keep session data out of URLs that should be indexed.
- Changing URLs without 301s. Restructure, launch, migration — URLs change. Without redirects, every external link breaks. Fix: map every old URL to its new equivalent. Set up 301 redirects before the change goes live.
An eighth worth flagging: dates in URLs that need updating. /best-tools-2024 becomes a problem in 2026. If the content updates yearly but the URL stays the same, the URL ages out. If the URL changes yearly, every external link breaks. Either avoid year-stamping URLs or commit to redirecting every year.
Clean URLs compound:
A single URL doesn’t make or break a site’s SEO. A thousand clean URLs across a site, across years, create a structural advantage that adds up.
The work is mostly editorial. Pick descriptive words. Use hyphens. Keep things short. Match the URL to the page’s actual topic. Avoid parameters when a clean path will do. Don’t change URLs unless you have to, and redirect them when you do.
None of this requires advanced tooling. Most CMS platforms generate clean URLs by default. The work is recognizing when defaults produce something readable and when they don’t — and rewriting when they don’t. That’s the whole job.