Choosing between hyphens and underscores in URLs is a small editorial decision for a new page. Changing an address that customers already use is a maintenance decision. Before renaming a published page, establish what the change will improve and how visitors using the old link will reach it.
This guide separates three questions: which characters the URI standard permits, which naming convention your team prefers, and what you need to test when an address changes. It does not report a new search-engine policy or predict a ranking gain from replacing a separator.
Both characters are permitted in URI syntax
RFC 3986, section 2.3, includes both the hyphen and underscore among unreserved characters. An underscore alone therefore does not make an address invalid. The standard describes syntax; it does not say which punctuation will improve your position in search results.
For new page names, our editorial preference is a short phrase with hyphens between words: /wordpress-maintenance/, for example. We find that convention straightforward to read and apply consistently. That is a practical recommendation for managing content, rather than a claim that the alternative /wordpress_maintenance/ cannot work.
Write down the convention wherever your team prepares new pages. Include a sample service page and a sample article so an editor can make the choice without asking a developer each time. Agree the words first: changing punctuation will not make an unclear page name useful.
Give an existing address a reason to change
Imagine a consultancy with an established /it_support/ page and a new backup service ready to launch. We would name the new page /managed-backup/. We would leave the support address alone unless there were a stronger reason to change it, such as a restructuring already approved by the team. This is a hypothetical example, not a customer case study.
Our suggested review starts with the page owner. Ask what is wrong with the current address, which visitors would benefit from changing it, and whether the content itself needs work first. Record the answer in the change request. A preference for tidy punctuation can otherwise turn into a project whose purpose nobody can explain.
Next, list the places your team controls that use the old address. Think about navigation, related articles, campaign links and downloadable documents. Ask colleagues about printed materials too. This inventory is our recommended planning step; it helps decide whether the benefit justifies the work.
Plan what happens to the old link
MDN’s guide to HTTP redirections explains that permanent redirects can preserve links and bookmarks after URLs change. It describes a redirect response carrying a destination in the Location header, which the browser then requests.
For an approved change, prepare a simple record containing the old address, the intended destination, the person implementing the redirect and the test result. Check the destination before release. Sending somebody to a page with a similar name is not enough if it answers a different question.
MDN’s 301 reference describes that status as a permanent move. It also distinguishes request handling: a redirected POST may become GET with 301, while 308 preserves the method. If the address accepts form submissions or API requests, ask the developer to review that behaviour instead of treating it like an ordinary article link.
Test the visitor’s route before closing the task
Our release checklist starts with the old address, entered directly rather than reached through the updated menu. Confirm that it lands on the intended page and that the content, contact links and relevant actions still work. Then follow the site’s navigation separately to check that editors have updated the links they control.
- Record the old address and final destination.
- Confirm the redirect response and test for loops.
- Check a bookmark-style visit and a visit through the site menu.
- Assign an owner to investigate errors reported after release.
MDN notes that a redirect adds another network round trip. Our preference is to keep the route simple and avoid building a chain of successive renames. For a small site, a clear naming convention for future pages is often a more manageable first step than renaming its entire archive.
Keep the completion note with the change request so a future maintainer can understand why the address moved. The useful outcome is a readable new name and a working route for existing visitors. Neither a syntax standard nor a successful redirect test establishes a measurable search-ranking improvement.
Technical sources checked on 24 October 2026. RFC 3986 supports the character-syntax explanation; MDN supports the redirect behaviour. The naming preference, examples and maintenance checklist are Nevelit’s editorial recommendations.
Leave a Reply