How to Change an Existing Article URL Safely

A published article's address is a promise. Other sites link to it, search engines have indexed it, and readers have bookmarked it. Change that address carelessly and every one of those connections breaks at once: visitors land on a "page not found" error, and the search visibility the page earned over months has to be rebuilt from scratch.

That does not mean a bad URL can never be fixed. A slug with a typo, a date that no longer fits, or a topic the page has outgrown is a genuine reason to move. But the move must be treated as a controlled operation, not a quick edit: decide whether it is worth it, map the old address to the new one, put a permanent redirect in place, update your own links, and verify that the old address lands where it should. Skip any step and you are gambling with traffic you already earned.

When a URL change is worth it

Start with the hardest question, because the correct answer is usually "don't." A slightly long slug, a missing keyword, or an improved title are not good reasons to move a live page. Words in a URL are only a light signal for search engines, and a stable address beats a perfect one that keeps shifting. A small readability gain is not worth the certain cost of redirecting every existing link.

A change is worth considering when the current address is actively wrong or misleading:

• It contains a typo or the wrong topic. A slug that says "password-tips" on a page now about passphrases misleads readers and search engines alike.
• It carries a date or detail the page has outgrown. An evergreen guide still sitting under a year-specific slug, or a post whose scope has fundamentally changed, confuses anyone who reads the address before clicking.
• It is unreadable. Percent-encoded characters, random IDs, or a string of parameters make an address nobody can quote, type, or trust.
• The page was just published and has no links yet. In the first hours, before anything points at the page, a correction is cheap. After that, treat the slug as fixed unless one of the reasons above applies.

One more check comes before you commit: confirm that your platform actually lets you create redirects. Some hosted builders and custom systems offer no redirect feature at all. If yours is one of them, that alone is a strong argument for leaving the slug alone — a move without a redirect is not a migration, it is a deletion of the old address. And resist changing many URLs at once: a site-wide restructure multiplies every risk in this guide, so move one page and verify it before the next.

Build the redirect map first

Before touching the slug, write down the move: the exact old address, the exact new address, and the redirect type. This map is your single source of truth, and what you will test against after launch. For one article it can be three lines in a note; for a larger move, a spreadsheet with one row per page.

Here is the worked example used throughout this guide. Imagine a small blog with an article whose address no longer fits its content:

Old URL:  https://exampleblog.com/posts/2023/03/10-tips-for-better-passwords-2023/
New URL:  https://exampleblog.com/password-tips/
Action:   301 (permanent) redirect from the old URL to the new URL

Draw the move as a chain, and keep it to exactly one hop:

Old URL  →  301 redirect  →  New URL (final page, status 200)

Three details deserve attention. First, copy the old address character for character, including the trailing slash if your site uses one — a redirect that misses it points at a different address. Second, choose the new slug with the same care as a brand-new post: short, lowercase, hyphenated, evergreen, and checked against your site's existing pages so it does not collide with another article. FBSubNet's SEO-Friendly Slug Generator can draft the new slug from your headline, and the companion guide on creating a short SEO-friendly slug explains the rules behind it. Third, note every place the old address appears: navigation, related-post sections, older articles that link to it, and your sitemap. Those are the links you will update once the redirect is live.

If the move involves more than one page, add a row for every affected address — the page you forget is invariably the one another site linked to years ago.

Set up the 301 redirect correctly

The redirect is the heart of the operation. A 301 status code tells browsers and search engines that the page has permanently moved, so most of the old address's value carries over. It is permanent by definition: old links live for years, so the redirect should too.

How you create it depends on your platform. On Apache, a single line can do it:

Redirect 301 /posts/2023/03/10-tips-for-better-passwords-2023/ /password-tips/

On Nginx, the equivalent rewrite rule is marked permanent:

rewrite ^/posts/2023/03/10-tips-for-better-passwords-2023/$ /password-tips/ permanent;

On WordPress and similar systems, a redirect plugin or your SEO plugin's redirect manager usually provides a form: old path in one field, new path in the other, type set to 301. Whichever route you take, the result must be identical from the outside: requesting the old address returns a 301 pointing at the new address, and requesting the new address returns the page itself with a 200 response.

Four mistakes undo otherwise careful moves:

• Using a 302 instead of a 301. A 302 means "temporarily moved," so search engines keep the old address indexed and do not pass its value along.
• Redirecting everything to the homepage. Sending visitors to a generic page instead of the content they asked for is barely better than an error page, and search engines treat it as a soft error. Every old address should point at its true replacement.
• Creating chains. If the old address redirects to an intermediate address that redirects again, each hop dilutes the signal and slows the page down. Point every old address directly at its final destination, and if a page has moved before, update its earlier redirects to skip the middle step.
• Forgetting trailing-slash and case consistency. If your site serves addresses with a trailing slash, the redirect target must match. Mixed conventions split one page into several apparent addresses.

Update internal links, sitemaps and canonicals

A redirect keeps old links working, but your own site should not keep sending readers through it forever. Once the new address is live, update every internal link that pointed at the old one: navigation menus, category pages, related-post blocks, and links inside your other articles. Search your site for the old slug and replace each occurrence with the new address.

Then fix the signals that tell search engines which address is canonical. The new page's canonical tag should point at its own new address, never at the old one. Your XML sitemap should list the new address and drop the old one — regenerate it through your SEO plugin rather than editing it by hand, so nothing is missed. If you have Search Console access, request indexing for the new address so the move is discovered promptly instead of at the next routine crawl.

External links are the one part you cannot edit directly. For the few that matter most, a short message asking the site owner to update the link is worth sending; most will not, and that is fine, because the redirect covers them. Also update anything outside the site that still quotes the old address: a pinned social post, an email course, a PDF, a slide deck.

Verify after launch

Verification starts the moment the redirect is live. Work through this checklist before you consider the move finished:

1. Open the old address yourself. It should land on the new page, with no error and no intermediate stops. Use a fresh browser session.
2. Check the status codes. A redirect-checking tool, or your browser's developer tools on the network tab, should show a 301 for the old address followed by a 200 for the new one. A 302, a chain, or a 404 anywhere in that sequence means the job is not done.
3. Test variants. Try the old address with and without the trailing slash, and over http as well as https if both were ever served.
4. Crawl the site. A crawl should report no internal links still pointing at the old address and no new 404 errors.
5. Check Search Console. Watch for errors on the old address and confirm the new address appears as indexed.
6. Watch traffic for two to four weeks. Expect a brief wobble as signals transfer. Compare against the old page's previous baseline over the same weekdays; if traffic has not stabilised after about a month, something in the chain is still wrong.

Keep the redirect in place indefinitely. Bookmarks, old social posts, and links on other sites do not expire, and the moment the redirect disappears, all of them break again.

Troubleshooting: when the move goes wrong

Traffic dropped and has not recovered. Re-check the redirect first: is it really a 301, pointing at the final page, with the new page returning a 200? Then check the canonical tag and sitemap — either still naming the old address sends a conflicting signal that can stall the transfer. If both are correct, give it the full few weeks.

Visitors hit a redirect loop. The old address points to the new one, which points back again — usually a rule written twice, or a plugin and a server rule disagreeing. Remove one rule and test in a fresh session, since browsers cache redirects aggressively.

Your platform offers no redirects. Do not change the slug. If the address is truly unbearable, the honest options are to leave it, or to move the site to a platform that supports redirects before making the change. A move without a redirect trades a cosmetic problem for a real traffic problem.

Frequently asked questions

Will I lose rankings if I change a URL?

With a correct 301 redirect, updated internal links, and a matching canonical, most of the old page's standing transfers, usually after a short fluctuation. Without a redirect, you effectively start over at the new address. The redirect is what makes the difference.

Should I change the slug when I update the title?

No. A title is display text; a slug is an address. You can improve a title at any time without touching the slug, and doing so avoids this entire operation. Change the slug only when the address itself is wrong, not when the wording around it could be better.

How long should I keep the redirect?

Indefinitely. Old links do not expire, and removing the redirect years later breaks them just as surely as never setting one up. Treat redirects as permanent infrastructure, and keep a record of them so a future redesign does not silently drop them.

A short checklist before you move a URL

1. Confirm the change is genuinely needed — not cosmetic, not keyword-chasing.
2. Confirm your platform can create permanent redirects. If it cannot, stop here.
3. Write the redirect map: old address, new address, 301, one hop, trailing slash included.
4. Draft the new slug: short, lowercase, hyphenated, evergreen, collision-checked.
5. Put the 301 redirect in place and test the status codes before announcing anything.
6. Update internal links, the canonical tag, and the sitemap; request indexing for the new address.
7. Verify the old address, its variants, and the new page over the following two to four weeks.
8. Leave the redirect in place permanently, and keep the map for the next redesign.

A URL change done this way is unremarkable — and that is the point. Readers clicking an old link arrive at the right page without noticing anything happened. Plan the map, set the redirect, update your links, and verify: that sequence keeps a small edit from becoming lost traffic.