
Hyphens vs Underscores in URLs: What Google's Updated Doc Says
Quick answer: Use hyphens. Google's URL structure guide, updated in a changelog entry dated 23 October 2026, now explains why: underscores are how programming languages join terms (format_date), so they do not mark word boundaries the way hyphens do. Gary Illyes also called URL keywords "an incredibly small signal", so new slugs should use hyphens, but renaming established underscore URLs purely for this is rarely worth the redirects.
Google has settled the hyphen-versus-underscore question in writing, again, and this time it gave the reason. For anyone building slugs for a docs site, a product directory or a blog, the answer is hyphens. The more useful part of the update is what it says about how little the choice matters for pages that already exist.
What changed in Google's documentation
On 23 October 2026, the Search Central documentation changelog recorded an update to the crawlable URL structure guidance to "clarify word separation guidelines using hyphens versus underscores". Google says the change synchronizes the doc with episodes of The Non-Canonical Cabinet, a new video series on edge-case technical SEO questions.
The URL structure page now states the rule and the rationale together:
- Separate words in URLs with hyphens (
-), not underscores (_). - Hyphens clearly mark word boundaries for users and search engines.
- Underscores are discouraged because programming languages often use them to join terms, as in
format_date. - Its examples favour
summer-clothing/filter?color-profile=dark-greyover underscore versions or run-together words likegreendress.
None of this reverses earlier advice. In June 2022, Search Engine Roundtable reported Gary Illyes explaining that Google "can't easily segment at underscore", which is why it recommends dashes. What is new is that the reason now lives in the official documentation, which makes it easier to win the argument with a developer who prefers snake_case routes.
What Google said in the video
The first Non-Canonical Cabinet episode, published on 14 October with Gary Illyes and Cherry Prommawin, covered what can go in domains and URL paths. According to Search Engine Journal's write-up:
- Google treats words joined by underscores as "one long word".
api_rate_limitsreads as a single token;api-rate-limitsreads as three words. - Illyes called keywords in a URL "an incredibly small signal", mattering mainly when Google has no other information, such as a brand-new site with no content.
- Googlebot will crawl a path containing an emoji and "our system will actually process it", but browsers percent-encode those characters and some apps display them as gibberish.
- Emojis are not allowed in domain names under current standards; internationalized domain names are converted to Punycode.
Put those together and the hierarchy is clear. Hyphens are correct, but the words in a URL are a weak signal compared with the page's title, headings and content. A slug is mostly a readability and consistency decision.
The rest of the URL guidance developers miss
The same page carries rules that cause more real problems than separators. These are the ones worth checking in a framework's router or a CMS's slug function:
| Rule | What Google's doc says | Typical bug |
|---|---|---|
| Case | Paths are case-sensitive: /APPLE and /apple are distinct URLs | A server that serves both creates duplicates; pick one case |
| Non-ASCII | Percent-encode non-ASCII characters in href attributes | Raw Unicode in links from a templating layer |
| Parameters | Use = and &; for several values under one key, use commas such as color=purple,pink | Bracket or double-comma schemes |
| Fragments | Do not use # fragments to change page content; use the History API | Hash-routed single-page apps |
| Irrelevant parameters | Avoid session IDs in URLs; use cookies | Tracking and sort parameters multiplying URLs |
| Relative links | Use root-relative links to avoid infinite URL spaces | Parent-relative links on pages that should 404 |
Case is the one that bites directory sites. If /Products/Foo and /products/foo both return 200, you have two URLs competing for one page. Redirect to a single form and set a canonical tag as a backstop.
Encoding matters in robots.txt too
The second episode, on robots.txt, extended the encoding advice. Per Search Engine Roundtable's summary, Googlebot handles international characters in paths but other or older crawlers may not, so rule paths should use the percent-encoded form your server expects. Parsers silently discard lines they do not understand, which means a malformed rule leaves content crawlable rather than failing loudly. If you generate rules, use a robots.txt generator and test the actual URL patterns.
Should you rename existing underscore URLs?
Usually not. This is our judgement rather than Google's instruction, and it follows from Google's own statements. If URL keywords are an incredibly small signal, the ranking upside of converting /docs/rate_limits to /docs/rate-limits is close to zero. The cost is a site-wide redirect map that must be maintained, internal links to update, and a period of churn.
Google's redirects documentation is clear about doing it properly if you do: use a permanent server-side redirect (301 or 308) whenever possible, which signals that the target should become canonical, and only use permanent redirects when you are sure they will not be reverted. Old URLs can keep appearing in results for a while.
There are cases where renaming is worth it:
- You are already migrating URLs for another reason, such as a new information architecture or framework. Fix separators in the same redirect map.
- Your URLs mix cases or separators, so the same page is reachable at several addresses.
- The slugs are unreadable run-together words that users share and cannot parse.
- The section is new or has almost no external links, so there is little equity to move.
For everything else, change the slug function for new content and leave existing URLs alone.
A slug policy you can actually enforce
The useful output of this update is a rule written into code, not a one-off cleanup. A slug policy for a technical site fits in five lines:
- Lowercase ASCII letters, digits and hyphens only; collapse repeated hyphens and trim them from the ends.
- Transliterate or percent-encode non-ASCII at generation time, never at render time.
- Keep version numbers readable:
typescript-7-1rather thantypescript71. - Generate once and store it; never derive slugs from titles on every request, or an edited title silently changes the URL.
- Reject case variants and trailing-slash variants at the router with a redirect to the stored form.
Test edge cases such as product names with dots, plus signs and emoji in a slug generator before wiring the rule into a CMS. Then make sure the XML sitemap and breadcrumb schema use exactly the stored form, so you are never listing URLs that redirect.
Slugs are also part of a site's taxonomy. If you are designing categories and listing pages, our guides on content taxonomy for directory sites and programmatic SEO without thin pages cover the structural decisions that matter far more than separators.
FAQ
Does Google prefer hyphens or underscores in URLs?
Hyphens. Google's URL structure documentation says to separate words with hyphens, not underscores, because underscores are commonly used in programming to join terms and do not mark word boundaries as clearly.
How does Google read words joined by underscores?
According to Search Engine Journal's report on Google's Non-Canonical Cabinet episode from 14 October 2026, Google treats words joined by underscores as one long word, while hyphens separate them.
Do keywords in URLs help rankings?
Very little. Gary Illyes described URL keywords as an incredibly small signal that matters mainly when Google has no other information, such as for a brand-new site without content.
Should I change my existing underscore URLs to hyphens?
Usually not for SEO alone, given how small the signal is. If you do, use permanent 301 or 308 server-side redirects and update internal links. It is worth doing during a migration you are already running.
Are URL paths case-sensitive for Google?
Yes. Google's documentation says /APPLE and /apple are distinct URLs. If your server treats them the same, standardize on one case so Google can identify duplicates.
Hyphens for every new slug, redirects only when you are moving URLs anyway. The separator was never the hard part.

