You're naming a new page and your CMS or code editor is happy to accept either symbol.
blue-widget-guide or blue_widget_guide — both look tidy, both
render fine in a browser, and nothing about the interface warns you that one of them is
quietly working against you in search results.
This isn't a stylistic coin flip. Google has been explicit about how it parses the two symbols differently, and that difference compounds across every page, image, and file name on a site that picked the wrong one by habit.
Use hyphens, not underscores, in URL slugs. Google explicitly treats a hyphen as a word
separator, so blue-widget is read as two words, while an underscore is
ignored, so blue_widget is read as one word, "bluewidget." The fix is
simple — replace underscores with hyphens sitewide and 301-redirect the old URLs so
nothing breaks.
What's actually different between hyphens and underscores?
Both characters do the same visual job — they stand in for a space that a URL can't contain. The difference is entirely in how a crawler parses the string once it gets there.
- A hyphen splits a word. Google's own guidance on URL structure confirms that a hyphen is read as a word boundary, so
best-running-shoesis parsed as three separate, matchable keywords. - An underscore doesn't. The same guidance treats the underscore as part of the word itself, so
best_running_shoesis read closer to one long token than three real keywords. - Humans read both the same way. A visitor glancing at either version sees three words instantly — the gap is purely on the machine-parsing side, not the human-readability side.
- It applies beyond page slugs. The same rule governs image file names, PDF file names, and any other URL-based asset, since a crawler parses all of them the same way.
The takeaway: this was never a taste preference between two similar-looking symbols. One of them helps a crawler extract keywords from your URL, and the other quietly prevents it.
Why this matters for SEO
A single mismatched separator won't sink a page, but the pattern adds up in ways that are easy to miss until they're pointed out:
- Keyword relevance in the URL gets diluted. A URL is a minor ranking signal on its own, and an underscore quietly turns that minor signal off by merging your keywords into one unrecognized string.
- Search snippets look worse. Google sometimes displays the URL path in search results, and a hyphenated slug reads as clean, separated words while an underscored one reads as a run-on.
- Consistency compounds across a whole site. One inconsistent slug is a rounding error; hundreds of underscored URLs across every blog post and product page is a sitewide pattern working against you.
- It's a completely free fix. Unlike most technical SEO work, correcting a separator costs nothing beyond the time to rename the slug and set up a redirect — there's no reason to leave it as-is once you know.
Step-by-step: auditing and fixing your slugs
- Pull a full list of your site's URLs. Export every published page, post, and image path from your CMS, sitemap, or crawler of choice.
- Scan the list for underscores, spaces, and uppercase letters. All three break the same word-separation rule in slightly different ways and should be flagged together.
- Generate the corrected hyphenated version of each slug. Replace every underscore with a hyphen and lowercase the whole path, keeping the wording itself unchanged.
- Set up a 301 redirect from each old URL to its new one. This is the step that actually protects existing rankings and backlinks — never rename a live URL without it.
- Update internal links to point at the new slugs directly. Redirects work, but linking straight to the final URL avoids an unnecessary hop for both users and crawlers.
- Resubmit the affected URLs in Search Console. This nudges Google to recrawl and re-index the corrected paths sooner rather than waiting for the next natural crawl.
- Set a naming rule going forward. Bake "hyphens only, always lowercase" into your CMS's slug settings or your team's publishing checklist so the mistake doesn't reappear on new pages.
Common mistakes when fixing separators
1. Renaming the slug without a redirect
Changing blue_widget to blue-widget on the live URL with no 301
in place turns every existing link and bookmark into a dead end, and hands away whatever
ranking signal the old page had built up.
2. Mixing both separators on the same site
Fixing new pages while leaving years of old underscored posts untouched creates an inconsistent pattern that's harder to reason about later than either convention applied uniformly.
3. Treating this as more important than it is
Separator choice is a small, indirect factor. Rewriting a site's entire URL structure at the expense of fixing actual content or technical issues gets the priority backwards.
4. Forgetting image and file URLs
Slug audits often stop at page URLs and skip product_photo.jpg-style image
file names, which follow the exact same word-separation rule and matter for image search.
Real-world examples
How the same page title turns into a working or a weakened URL, depending on the separator:
In every case, the words on the page didn't change — only whether the URL communicates those same words to a crawler.
Hyphens vs underscores compared
A direct look at how the two separators, plus the other common alternatives, actually behave in a URL.
| Separator | Read by Google as | Human readability | Recommended for URLs |
|---|---|---|---|
| Hyphen (-) | Word boundary | High | Yes |
| Underscore (_) | Part of the word | High | No |
| Space | Encoded as %20 | Low, breaks visually | No |
| camelCase | No clear boundary | Moderate | Not ideal |
Check your URLs right now — free
The Rebrixe Bulk Slug Validator scans an entire list of URLs at once, flags every underscore, space, and uppercase character, and outputs the corrected hyphenated version of each one — ready to hand off for redirects. No account, no watermark.