Read a URL out loud. If it tells you what the page is about before you click, it is doing its job. If it reads as a string of numbers and question marks, it is failing three different audiences at once, and no amount of on-page work fully makes up for it.
That read-aloud test is the whole discipline compressed into one habit. A URL is not just an address the browser needs. It is a short, public description of the page that shows up in search results, in social shares, in emails, and anywhere someone copies a link. Readers scan it to decide whether a result looks worth a click. Search engines read it as one lightweight signal among many about what the page covers. Sharing systems carry it wherever the link travels, and a readable path travels better than an opaque one.
Most URL advice reduces to readability. Most URL mistakes come from forgetting that a human, somewhere, is going to look at the thing and decide whether to trust it.
The parts of a URL, and which ones you control #
A URL is built in layers, and each layer does one job. Take https://example.com/blog/seo-fundamentals/url-structure. The protocol is https://, the host is example.com, the path is the folder structure like /blog/seo-fundamentals/, and the slug is the final piece, url-structure, that names the specific page.
The protocol should be https://, full stop. Browsers now flag plain HTTP as insecure, and Google has treated HTTPS as a lightweight ranking signal since 2014. The host is the domain plus any subdomain, and it is worth knowing that Google treats a subdomain like blog.example.com as a largely separate site from the root domain for ranking purposes. The path is the sequence of folders that signal hierarchy, each one narrowing scope. The slug is the final segment that names the page.
Of these, the slug is the part a writer or editor controls most often. The other three are usually fixed by the site architecture and the CMS. So most of the practical work in this guide lands on the path and the slug, where editorial judgment actually changes the outcome.
Short, descriptive, lowercase #
Three principles produce URLs that pass the read-aloud test, and they are easy to remember because they describe a good slug directly: short, descriptive, lowercase.
Short means keeping the visible path under roughly 60 characters when you can. Long URLs get truncated when shared, wrap awkwardly on mobile, and are harder to remember or dictate. Descriptive means using words that match the page’s actual topic, so the URL confirms the subject before the reader commits to a click. Lowercase matters because some servers treat /Page and /page as two different addresses, which can split signals across duplicate URLs. Google’s documentation recommends standardizing on lowercase to remove that ambiguity.
What does not work is stuffing keywords into the slug. A path like /best-running-shoes-running-shoe-reviews-best-shoes-for-runners does not outrank a shorter, cleaner alternative. This is where a persistent myth needs correcting: the idea that a keyword-rich URL delivers a meaningful ranking boost. It does not. Google’s John Mueller has repeatedly described words in the URL as a very small ranking factor, and has put it plainly that keywords in URLs are overrated and that you should make URLs for users. The right takeaway is not to strip topical words out, but to stop treating the URL as a place to force repetition for rankings.
Hyphens separate, underscores connect #
Use hyphens between words. Not underscores. This is one of the few URL rules with a concrete technical mechanism behind it rather than a readability preference.
Google’s documentation recommends hyphens because its parser treats them as word separators. A slug like /url-structure-best-practices is read as four distinct words, which makes the page discoverable for queries that combine any of those terms. Underscores behave differently: Google reads /url_structure_best_practices as the single joined string urlstructurebestpractices. Matt Cutts confirmed this segmenter distinction in a 2011 Google video. The practical result is that underscored slugs are less discoverable through keyword variations than hyphenated ones.
Two notes follow. First, spaces in URLs get encoded as %20, which looks broken in browsers and email clients, so a hyphen is the separator that actually survives sharing. Second, and this is the part people get wrong: do not go back and change existing underscored URLs just to switch separators. Mueller has advised against exactly this, because the recrawl and redirect cost outweighs the small readability gain, and a site already ranking well can take a short-term dip while Google reinterprets the new addresses. The hyphen rule is for new URLs. Existing ones that rank fine are best left alone.
One exception to the hyphen habit: it applies to paths and slugs, not to the domain name itself. Hyphens in a domain tend to look spammy and hurt brand recall, and underscores are not even valid in most domain registrars.
Cut the stop words #
Stop words are the short connectors that fill titles and headlines: “and,” “the,” “of,” “for,” “a,” “to,” “in.” They belong in prose. They usually do not belong in URLs.
The reason is not ranking weight. Mueller has stated that stop words in URLs do not matter for ranking. The reason is length and readability. Compare /the-complete-guide-to-writing-meta-descriptions-for-your-website against /writing-meta-descriptions. Same page, same topic. The second fits in a tweet and displays cleanly everywhere.
The trimming pattern is simple. Drop articles like “the,” “a,” and “an,” which almost never carry meaning in a URL. Drop prepositions like “for,” “of,” and “to” when word order already makes the relationship obvious. And cut wrapper words like “complete,” “ultimate,” “best,” and “guide-to,” which signal nothing a reader cannot infer from the rest of the slug.
The one caution: stop when removing a word changes the meaning. /run-fast reads differently from /run-for-fast-relief. Shorter is not automatically better. The slug still has to describe the page.
Depth should mirror content, not page count #
URL hierarchy should reflect how content is organized, not how many pages happen to exist. A site with three blog posts does not need three folder levels. A site with 5,000 product pages probably does.
Two patterns work, sized to the site. A small site can stay mostly flat, with pages one level below the root: /about, /services, /blog/url-structure. A larger site benefits from hierarchy that groups related pages: /products/running-shoes/road-running/pegasus-40 or /blog/seo/on-page/url-structure. Google’s Gary Illyes has recommended hierarchical structure for larger sites and flatter structure for smaller ones, because hierarchy helps users and crawlers understand topical relationships, while forcing depth onto a small site just creates artificial folders.
The warning signs show up quickly in either direction. Too deep looks like paths with more than three or four folder levels, folders that exist to hold a single page, or segments like /blog/articles/posts/ that do not actually narrow scope. Too flat looks like every page sitting at the root regardless of category, with no clear way for a user to move up to a parent section and no structural cue to help search separate similar topics.
Worth naming so it stays out of scope here: URL hierarchy and breadcrumb navigation are related but distinct. Breadcrumbs are the on-page UX element that displays the path; the URL is the underlying structure. They often mirror each other, but the URL is the source of truth, and breadcrumb markup is its own topic.
Parameters are exceptions, not defaults #
Query strings, the part of a URL after the ?, exist to handle filtering, sorting, and tracking. They are the right tool when the variation is real, such as different filtered views of a product list. They become a problem when they carry content that deserves its own stable, shareable URL.
A rough map of common parameter types: filters (?color=blue) refine a product list that does not need separate indexing; sort parameters (?sort=price) reorder the same content; tracking parameters (?utm_source=...) attribute analytics without changing content; session identifiers hold user state and should stay out of indexed URLs; and pagination parameters step through sequential views of a list. Google’s 2025 URL guidance clarified parameter formatting: use = between a parameter name and its value, use & between parameters, and avoid colons and brackets in values, since those characters carry syntactic meaning.
The failure mode is using a parameter for something that should be a clean path. A product at /product?id=4729 should live at /products/nike-air-zoom-pegasus-40. The parameterized version works, but it fails the read-aloud test and travels badly in shares and citations. It also invites two specific risks. The first is duplicate content: /category and /category?sort=newest may serve nearly identical pages, splitting ranking signals across two URLs. Deciding which version search should treat as primary is where canonical tags come in, which is a separate topic worth handling on its own. The second is crawl waste: filter combinations can multiply into thousands of URL variations, each consuming crawl budget. Search Console offers tooling for managing parameter handling at scale.
Treat every URL as stable infrastructure #
Once published, a URL is the destination for every external link, every shared post, every bookmark, every cached search result. Change it carelessly and you break all of that.
The core mechanic is straightforward: when a URL has to change, set up a 301 redirect from the old address to the new one. A 301 tells search engines the move is permanent and that the new location should inherit the old URL’s accumulated signals. Three rules keep this clean. Do not change URLs without a reason, because “cleaner URL” alone rarely justifies the recrawl cost; wait for a real occasion like a migration, restructure, or rebrand. Always 301, and never let a moved URL simply 404, since a 404 forfeits every external link pointing at it while a 301 preserves that equity. And update internal links to point directly at the new URL rather than relying on the redirect, because chains of redirects slow crawling and dilute signals.
Mass URL changes and full site migrations are their own discipline, well beyond this guide. The principle here is smaller and more durable: every URL you publish is a promise that it will keep working, or that you will forward it cleanly when it cannot.
Seven anti-patterns worth checking for #
Most real-world URL problems cluster into a handful of patterns, each with a clean fix.
- ID-based URLs like
/product?id=4729. Numbers describe nothing. Rewrite to descriptive slugs that name the product or topic. - Mixed-case URLs like
/About-Usalongside/about-us. Depending on server config these resolve to the same page or two different ones, creating duplicate-content risk. Standardize on lowercase everywhere. - Underscores between words like
/seo_url_best_practices. Google reads that as one word. Use hyphens for new URLs, and leave existing well-ranking underscored URLs alone. - Keyword stuffing in slugs like
/best-running-shoes-running-shoe-reviews-shoes-for-runners. Repetition does not boost ranking. Pick one descriptive phrase and cut the rest. - Trailing-slash inconsistency, where
/blog/postand/blog/post/are treated as different URLs. Pick one convention site-wide and redirect the other form to it. - Session IDs in indexed URLs like
/page?sid=8a2b9c. Every visit spawns a new URL, wasting crawl budget and creating duplicates. Keep session state in cookies, not in indexable URLs. - Changing URLs without 301s during a restructure or launch. Map every old URL to its new equivalent and set up the redirects before the change goes live.
An eighth is worth flagging too: dates baked into URLs, like /best-tools-2024, which age out. If the content refreshes yearly but the URL stays, the URL lies; if the URL changes yearly, external links break. Either avoid year-stamping or commit to redirecting every year.
Frequently asked questions #
Do keywords in the URL help rankings?
Only very slightly. Google has described words in URLs as a very small signal, most relevant when Google first encounters a URL and has not yet crawled the page. Use descriptive words because they help readers and travel well in links, not because repeating them moves rankings.
Should I convert my underscored URLs to hyphens?
Not for existing URLs that rank well. Mueller has advised against redirecting purely to swap separators, because the recrawl and short-term ranking risk outweigh the small gain. Apply the hyphen rule to new URLs going forward.
How long should a URL be?
Aim for the visible path under about 60 characters when practical. That is a readability and sharing guideline, not a hard ranking threshold. A slightly longer URL that clearly describes the page beats a short one that hides it.
Do I need to change my URLs to improve SEO?
Usually not on its own. Most CMS platforms generate clean URLs by default. Change URLs when there is a real reason, and when you do, redirect them with 301s.
Where the value actually comes from #
A single URL does not make or break a site’s SEO. A thousand clean URLs, across a site, across years, add up to a structural advantage that compounds every time one of them is linked, shared, or cited.
The work is mostly editorial rather than technical. Pick descriptive words, use hyphens, keep things short, match the slug to the page’s real topic, avoid parameters when a clean path will do, and do not move URLs unless you have to. Most platforms already produce reasonable defaults; the job is recognizing when a default reads cleanly and when it does not, and rewriting the ones that do not. If you only adopt one habit from all of this, make it the read-aloud test, and let everything else follow from it.