Editorial illustration; the URLs and WordPress-style interface are representative, not a live dashboard.
Changing a WordPress URL can make a page easier to understand, but it also changes the address that visitors, search engines, bookmarks and other sites know. If you edit the slug and stop there, the old link may show a 404 page, redirect to the wrong content or create a chain through several temporary addresses.
The safe question is not “How do I rename this slug?” It is “What should happen to every old address that people may still use?” This guide treats a URL change as a small migration: map the old path, create one clear redirect, update links you control, then test the result from the perspective of a visitor.
Summary
- Record the old URL and decide whether the content is genuinely moving, merging or being retired.
- Change the slug only after you know the final destination and backup/restore path.
- Use one direct permanent redirect for a moved page; do not create chains or redirect unrelated URLs.
- Update internal links, canonical references and feeds where your site controls them.
- Test logged-out and logged-in responses, then monitor 404s and analytics for missed paths.
When should a URL change?
A URL change is justified when the existing path is misleading, contains an obsolete product or category name, has an accidental string of dates, or needs to be merged with a stronger page. It is not automatically worthwhile because a shorter slug looks nicer. Every change creates work for bookmarks and external links.
Before editing, write down the decision:
- Move: the same useful content gets a clearer address.
- Merge: two pages become one, so the weaker page should point to the retained page.
- Retire: the content is no longer available, and a helpful replacement may or may not exist.
If there is no relevant replacement, do not redirect an old article to the home page just to avoid a 404. That confuses visitors and hides the fact that the original resource has gone.
For a site with many templates, the template-parts guide is a useful reminder that repeated structure and page identity are separate concerns. A URL migration should change the page address deliberately, not accidentally alter the layout shared by other pages.
Step 1: Build a URL map
Create a small table with four columns: old URL, final URL, reason, and test status. Include query strings or language paths if they affect routing. Start with the address shown in the editor, then check:
- The public page while logged out.
- The canonical link in the rendered HTML, if your theme or SEO tool outputs one.
- Internal links from navigation, related posts and older articles.
- Any alternate format or attachment path that visitors may use.
The exact set depends on the site. Do not invent aliases you have not observed. If the old page already redirects somewhere, record the full chain before adding another rule. The goal is one known old address to one final address.
Step 2: Make a reversible change
Back up the database and confirm how you would restore the page before editing the slug. A staging site is preferable when the page is important or the site has custom routing. If staging is unavailable, choose a quiet period and keep the URL map open while you work.
In WordPress, edit the post or page permalink/slug, save, and open the public URL. Do not assume the editor’s success notice proves that the public route works. Check the page in a logged-out browser window because a logged-in session may conceal caching or permission problems.
If the URL contains a taxonomy base or a custom post type rewrite, the change may involve more than a post slug. After routing changes, visiting Settings → Permalinks and saving the existing structure can refresh rewrite rules, but it is not a universal repair for custom server or plugin routing. Test the actual URL and document what changed.
Step 3: Add one direct redirect
For a page that has moved permanently, configure a permanent redirect from the old path to the final path. WordPress also has a redirect_canonical() mechanism that attempts to send an incoming URL to the correct canonical URL based on the query, but that automatic behaviour does not replace a deliberate migration map. Read the official developer reference and the documentation for your hosting or redirect tool before choosing the implementation.
Common implementation choices include a hosting/server rule, a redirect-management plugin, or code maintained by the site team. Choose the method that your team can review, test and keep after future updates. Do not install a plugin solely for one redirect if the site already has a maintained redirect layer.
The desired response is conceptually simple:
old URL → one permanent redirect → final URL
Avoid this pattern:
old URL → temporary URL → category URL → final URL
Redirect chains are slower to diagnose and make it harder to know which address should be shared. Never send a moved article to an unrelated page merely because it is available.
Step 4: Update links you control
Search the source Markdown, menus, widgets, templates and content blocks for the old path. Replace internal links with the final URL where practical. This reduces unnecessary redirects for your own visitors and makes future maintenance easier.
Check more than the article body:
- navigation menus and footer links;
- related-post blocks and Query Loop filters;
- XML feeds and custom sitemap entries;
- canonical or alternate-language settings;
- documentation, email templates and campaign links;
- image captions or downloadable files that name the old path.
Do not rewrite external websites or social posts that you do not control. The redirect exists partly to preserve those references.
Step 5: Test the redirect as a visitor
Use the exact old URL in a private browser window. Confirm that it reaches the intended final page, not merely the correct domain. Test with and without a trailing slash if the site treats them differently, and test a representative query string if campaigns use one.
Then test the final page:
- It returns the expected success response.
- The page title and main heading describe the intended content.
- Internal links do not send the visitor back to the old path.
- The page works while logged out.
- The page still works after caches are cleared or refreshed according to your hosting process.
If the site has a staging environment, compare the rendered result there first. Avoid testing by repeatedly clicking the old URL in a logged-in session, where a browser extension or cached session may hide the real response.
Step 6: Watch for missed paths
After publishing the change, monitor the site’s 404 log, analytics landing pages and webmaster tools according to the services your team already uses. Look for old paths that were not in the original map, not for an excuse to redirect every unknown request.
Classify each missed path:
- a real old page that needs a direct redirect;
- a typo that should remain a 404 or receive a helpful search page;
- a bot or attack path that should not be redirected into content;
- a broken internal link that should be fixed at its source.
This classification keeps the redirect layer meaningful. A large list of unrelated redirects can conceal real migration errors.
When not to change the URL
Leave the address alone when the only benefit is personal preference and the page already earns useful links or bookmarks. Improve the title, introduction, headings and internal links without changing the path. A stable URL is itself a usability feature.
If the page is being replaced by a substantially different answer, write a new page or merge the content intentionally. A redirect is not a way to make an unrelated page appear to satisfy an old request.
Mistakes to avoid
- Editing a slug without recording the previous public URL.
- Creating a redirect to the home page for every retired article.
- Adding a second redirect before checking an existing chain.
- Relying on automatic canonical behaviour without testing the old path.
- Updating the page but leaving menus, feeds or internal links pointing to the old address.
- Testing only while logged in or only from the editor preview.
Why this matters
URLs are part of the site’s public interface. A clean migration helps visitors follow bookmarks and external links, gives editors one address to share, and leaves a clearer record for the next person who changes the content. The technical rule is small; the evidence around the rule is what prevents accidental breakage.
My Take
I treat every URL change as a data migration with a before-and-after record. The redirect itself should be boring and direct. Most quality comes from deciding whether the page moved, merged or retired, and from testing the exact paths that visitors will use.
Conclusion
Map the old address, make the slug change reversible, add one direct permanent redirect, update links you control and test from a logged-out browser. Then watch real 404s and fix only the paths that represent genuine visitor intent. That workflow keeps WordPress URLs understandable without turning a small edit into a site-wide mystery.