Use hyphens to separate ordinary words in new WordPress slugs. Do not bulk-rename established URLs just because they contain underscores. First determine whether a URL change solves a real problem, what depends on the old address and whether you can maintain a correct redirect. A naming preference and a migration decision are different tasks.
What Google's Guidance Says
Google's URL structure documentation recommends hyphens for word boundaries and explains why underscores can represent concepts intended to stay together. The guidance also favors understandable URLs. This is not evidence of a new ranking penalty for every underscore, nor does it establish that renaming a working post will improve traffic.
For a new draft, choose a short, descriptive slug that matches the reader's task. Review it before publication and before sending links in emails or campaigns. That is the simplest point to establish a consistent convention because there is no existing public destination to migrate.
Distinguish Words From Identifiers
An underscore may be part of the thing the page documents. A cookie name, code function, product identifier or API parameter is not necessarily prose that should be rewritten. For example, _gcl_au is a cookie identifier, not three ordinary words to replace throughout a technical website.
Check each path segment separately. A post called /guides/site_backup_plan can use clearer word separation in a planned migration. A lookup route keyed by an exact identifier may need that identifier unchanged. A blanket search-and-replace across URLs, query parameters, code samples and storage keys can break functionality while appearing to improve consistency.
| URL situation |
Recommended decision process |
| New unpublished article |
Set the intended readable slug now |
| Established page with useful traffic |
Identify a concrete benefit before changing |
| Machine identifier in a route |
Confirm the routing and lookup contract |
| Duplicate pages with the same task |
Choose the owner and plan consolidation |
| Larger approved redesign |
Include the change in the migration map |
Inspect the Existing Page Before Editing
Use Search Console's page filter to review the current landing URL over comparable periods. Note its queries, clicks, impressions and canonical status. Add analytics conversions where you have reliable consent-aware measurement, plus known email, QR-code and advertising destinations. Search traffic is only one dependency.
Review internal links and important external references. A page with few impressions may still be a customer onboarding resource. Conversely, an address with many impressions but irrelevant queries does not automatically deserve preservation at any cost. Write down the business reason rather than treating either number as a decision by itself.
The planning worksheet should identify the current URL, intended destination, reason, owner and acceptance evidence. If the only reason is that an underscore looks untidy, leaving the live address alone is often the more proportionate choice. This is an operational judgment, not a guarantee that URL wording never matters.
An existing URL change needs an explicit mapping and acceptance test. New naming conventions do not require mass migration. Explanatory diagram, not a customer test.
If You Change It, Treat It as a Real Move
Google's site-move guidance calls for mapping old URLs to appropriate new destinations, redirects and monitoring. It also warns that search visibility can fluctuate while changed URLs are processed. Do not promise an immediate lift or a fixed recrawl deadline.
Use the WordPress redirect-map worksheet to document the old and new path. Test the proposed destination before changing production. It should contain the expected article, not the homepage, a search page or a generic application shell.
After the approved change, check the old URL with an HTTP GET, follow its redirect and inspect the final document. Confirm that the destination returns the correct status, has a self-referencing canonical and contains the complete article. Check both the server-rendered response and the visible page. A redirect plugin's success message alone is insufficient evidence.
Update contextual internal links to the final destination and publish the intended canonical URL in the sitemap. Avoid creating a second physical article copy to keep the old spelling alive. The old route should send the reader to the new owner through the site's redirect mechanism.
Keep Attribution and Content Parameters Intact
Test a harmless campaign-tagged URL as well as the plain path. Decide explicitly which parameters should survive, and verify the result against the site's attribution and privacy requirements. Do not globally replace underscores inside utm_source or custom parameter names. Those names may be consumed by forms, analytics or integrations.
Use synthetic markers rather than real customer identifiers in test URLs. Check that the final landing page and the form's attribution behavior still work. A visually correct page can hide a broken lead-source handoff after an overbroad redirect rule.
Monitor the Move, Not Just the New Page
Track both addresses after launch and record the deployment date. Investigate redirect loops, unexpected 404s, wrong canonicals and missing content before making another URL change. Do not repeatedly rename a page while waiting for Google to process the first move.
If a move has already hurt useful landing pages, continue with rankings after a WordPress migration. HandL WP migration repair can reconcile the redirect map, CDN behavior and search evidence. A good outcome is a dependable destination and measurable continuity, not a prettier URL at any cost.
References checked October 25, 2026. Diagnostic recipes are not claims of a test on your installation.