Hyphens vs. Underscores in URLs: What Google Recommends
Google recommends using hyphens to separate words in URLs. For a new page about office cleaning, that means choosing /office-cleaning/ over /office_cleaning/. Its URL structure documentation explains that hyphens help people and search engines identify the concepts in an address.
Search Engine Watch’s October 23 report covers Google’s clarification and what it means for website owners. If you publish articles, service pages, or products, the useful next step is to inspect how your website creates those addresses.
Apply the recommendation to new pages first. Before changing a published address, have a clear reason for the move and a plan for anyone following the existing link.
What Google’s documentation update actually changes
Google’s October 23, 2026 changelog describes the revision as a clarification of word separation guidance. Google says the purpose is to synchronize its documentation with the episodes of its The Non-Canonical Cabinet video series.
That announcement provides no estimated ranking improvement or instruction to rename an entire website. Treat it as guidance for a publishing standard. It doesn’t establish a business case for an archive-wide URL change.
For a small team, that distinction helps determine the workload. Checking the next page’s address is a manageable publishing task. Reviewing hundreds of existing addresses involves a separate decision about the value of changing them.
Why Google prefers hyphens
Google explains that underscores have historically kept terms together, including names such as format_date in programming conventions, while hyphens mark the boundary between words. The updated guidance describes that distinction.
Here are three illustrative addresses for the same hypothetical service page:
| URL path | Format |
|---|---|
/services/office-cleaning/ | Words separated by hyphens; Google’s recommended approach |
/services/office_cleaning/ | Words separated by underscores |
/services/officecleaning/ | Words joined together |
For a new page, choose the first option and document it as the site’s convention. That gives the next person publishing a page a clear example to follow.
Set a convention before publishing new pages
The slug is the part of an address that identifies a particular page, such as office-cleaning in the example above. Some publishing systems generate it from the page title; others let an editor enter it directly.
Give editors a short rule: describe the page’s subject in ordinary words, separate those words with hyphens, and check the generated address before publishing. Google’s broader guidance also recommends readable words and your audience’s language. Its URL best practices explain those choices.
For an article titled “How to Prepare Your Office for a Professional Cleaning Visit,” you might choose:
/blog/prepare-office-for-cleaning/For the page where someone can inquire about the service, you might choose:
/services/office-cleaning/These are editorial examples, not required templates. The useful question is whether the proposed address fits the page’s purpose and the rest of the website.
Before publishing, check that the slug still makes sense after editing the headline. A draft can begin as a checklist and become a detailed guide. Choosing the address at the final review gives the editor a chance to resolve that mismatch.
What if your existing URLs use underscores?
Start with an inventory rather than a replacement rule. Pick a few representative pages and record their addresses, purpose, traffic, inquiries, and known links from other websites.
Suppose an established office-cleaning page uses /office_cleaning/ and appears in customer emails and printed proposals. Include those references in the assessment before scheduling a move. Someone needs to account for how customers already reach that page.
Use a simple threshold: whether the change supports a defined project. A broader restructuring of service pages may create a reason to reconsider addresses. A punctuation preference alone would be a low priority on the list.
Keep the inventory practical. Its job is to identify the pages and references affected by a proposed change, so the person making the decision can assess the actual work.
Plan the move when an address needs to change
Google’s site-move documentation covers changes to URL paths. For a planned change, its guidance supports this checklist:
- Map each old URL to its replacement. Preserve the connection to the corresponding content.
- Use a permanent server-side redirect, such as HTTP 301 or 308, pointing directly to the final destination.
- Update internal links, canonical tags, and the sitemap to use the new addresses.
- Test the redirects and destination pages. Confirm that each old address reaches the intended content.
- Retain the redirects, generally for at least a year, as Google recommends.
- Monitor indexing, traffic, and errors after the move.
For the cleaning page, the intended relationship would be:
/office_cleaning/ -> 301 redirect -> /office-cleaning/Moving a path within the same domain doesn’t require Search Console’s Change of Address tool, which Google reserves for domain and subdomain moves. Google also warns to expect temporary ranking fluctuations during recrawling and reindexing after any significant change to a site. Its migration guidance explains both points.
Make the convention easy to follow
Create a draft page in your publishing system and inspect the address it generates. Try the process used for a normal article, then any separate workflow used for products or service pages.
If the results vary, write down the intended convention and identify which setting or publishing step controls each result. Give the editor one example they can reuse at the next review.
That leaves the team with a concrete improvement: a predictable way to choose the address before the next page goes live.