Changing a published post’s URL in WordPress takes about four seconds: open the post, edit the permalink field, hit update. The clean-up afterwards is what takes the time \u2014 and skipping it is how a page that ranked perfectly well quietly disappears from search over the following month.<\/p>\n
This guide is the whole workflow: whether the change is worth making at all, what actually breaks, and a step-by-step order of operations that keeps the traffic. We’ll finish with the scarier version of this job \u2014 changing your site-wide permalink structure<\/em>, which rewrites every URL you have at once.<\/p>\n Honest answer, most of the time: no. A slug that’s slightly long, or has a stop word in it, or doesn’t exactly match your target keyword, is costing you approximately nothing \u2014 Google has said repeatedly that words in the URL are a very minor ranking factor, and a page that already ranks has links, history and trust attached to that specific address<\/em>. Trading a real asset for a cosmetic gain is a bad deal. The cases that do justify it:<\/p>\n Everything else \u2014 “I want the keyword in there”, “it’s three words too long” \u2014 is the itch you should not scratch. If you’re mid-way through a content audit<\/a> and tempted to tidy dozens of slugs at once, tidy the content instead and leave the URLs alone.<\/p>\n A useful test: if you can’t name a concrete thing that gets better for a reader, don’t change the URL. “It bothers me” is a real feeling but not a reason.<\/p><\/blockquote>\n Changing a slug on a published post doesn’t move the old URL. It deletes<\/em> it. Everything that pointed there is now pointing at a 404 until you fix it:<\/p>\n WordPress does have a built-in “old slug redirect” that sometimes rescues a renamed post \u2014 genuinely helpful, but it only covers slug changes it recorded itself and doesn’t survive every scenario. Treat it as a bonus, not a plan.<\/p>\n Do these in order. The order is the point \u2014 several steps get much harder once the old URL has stopped resolving.<\/p>\n Copy the full old URL into a note. Then open Search Console, go to the Performance report, filter by that exact page, and write down clicks and impressions for the last 3 months plus the top queries it ranks for. Two minutes’ work, and it’s the only way you’ll be able to answer “did this go wrong?” in three weeks \u2014 without a baseline, any dip looks like a disaster and any recovery looks like luck.<\/p>\n In the block editor, open the post settings sidebar, find the URL or permalink field, and edit the slug. Keep the new one short, lowercase, hyphen-separated and descriptive. Resist the urge to stuff it \u2014 three to five meaningful words is plenty, and dropping the year or the stale product name is usually the entire job. Update the post. The old URL is now dead, so don’t wander off; step 3 is the one that matters.<\/p>\n A 301 Moved Permanently<\/strong> tells browsers and search engines the page has moved for good and passes ranking signals to the new address. This is the step that turns changing a URL from a risky move into a routine one.<\/p>\n Set it up however suits your site \u2014 a redirect plugin, an Everyone skips this, because the redirect makes the site look fine. It isn’t. A redirect is a safety net for links you can’t<\/em> control \u2014 other people’s sites, old newsletters, bookmarks. Links in your own content you can<\/em> control, and leaving them on the dead URL means every reader and crawler takes two hops instead of one: wasted crawl budget, added latency, and one more link in a chain that a future rename turns into A \u2192 B \u2192 C, which Google follows only so far.<\/p>\n So search your content for the old URL and replace it: post bodies, menus, widgets, reusable blocks, theme files. Finding every one by hand is the tedious part; a linking tool with a bulk URL-change or broken-internal-link report does the sweep in one pass \u2014 our own JnK Linkweave<\/a> (disclosure: it’s our plugin) includes that report, and any tool that indexes your internal links does the same job. Either way, the same pass that finds broken links<\/a> surfaces the stale internal ones.<\/p>\n Your sitemap regenerates automatically in most setups \u2014 WordPress core, Yoast and Rank Math all handle it. Load Then open Search Console’s URL Inspection tool, paste the new<\/em> URL and click Request Indexing \u2014 not a magic button, just a nudge that usually gets the page crawled in days rather than weeks. Inspect the old URL too, to confirm Google sees the redirect, but don’t request indexing for it; you want it dropped, not refreshed.<\/p>\n The redirect covers everyone else’s links, but some external links are yours, and a direct link always beats a redirected one: social bios and pinned posts, email signatures and automated sequences, docs and support macros, guest posts you can still get edited, directory listings and repos. Ten minutes, and it flushes out places you’d forgotten were linking to you.<\/p>\n For the next two to four weeks, watch two things in Search Console: the old URL’s impressions declining toward zero and the new URL’s climbing to replace them. In the Pages report the old URL should eventually appear under “Page with redirect” \u2014 that’s your confirmation Google has processed the move. A short dip in between is normal, not a failure; Google has to recrawl, follow the redirect and re-evaluate the new URL, and rankings can soften until that settles. What you should not<\/em> see is 404s reported for the old URL, or the new one failing to get indexed at all \u2014 either means the redirect isn’t working, so re-test it with Everything above is about one post. Settings \u2192 Permalinks is a different animal: it changes the URL of every<\/em> post at once, so going from Expect a larger and longer dip than a single-post change; you’ve asked Google to re-crawl and re-map the entire site. If your structure is merely inelegant rather than actively harmful, this is one of the clearest cases in WordPress of leaving well alone.<\/p>\n It hurts if you change the slug and stop there, because the old URL immediately returns a 404 and every link pointing at it is wasted. With a 301 from the old URL to the new one, ranking signals pass through and the damage is limited to a temporary dip while Google recrawls the page. The bigger risk is doing it for no reason: words in the URL are a very minor ranking factor, so unless you have a real problem like a rebrand, a stale year or a misleading slug, leaving it alone is the safer call.<\/p>\n Yes. WordPress does store previous slugs and can often forward an old URL to the new one, which is a helpful backstop, but it only covers changes it recorded itself and doesn’t reliably survive every setup, caching layer or permalink structure change. Set an explicit 301 so the behaviour is deterministic and testable, and turn on your redirect plugin’s option to create that 301 automatically whenever a published permalink changes.<\/p>\n Typically a few days to a few weeks, depending on how often the page is crawled. You can speed it up by requesting indexing for the new URL in Search Console’s URL Inspection tool and resubmitting your sitemap. You’ll know the move has been processed when the old URL appears under “Page with redirect” in the Pages report and the new URL starts accumulating impressions in the Performance report \u2014 a temporary dip in between is normal.<\/p>\nFirst: is it actually worth changing?<\/h2>\n
\n
\/best-x-2022\/<\/code> on a post you rewrite every January. Strip the year out once and you never have to do this again.<\/li>\nWhat actually breaks<\/h2>\n
\n
The safe workflow, step by step<\/h2>\n
1. Record the old URL and its current performance<\/h3>\n
2. Change the slug<\/h3>\n
3. Add a 301 from the old URL to the new one<\/h3>\n
.htaccess<\/code> rule, or an nginx directive. We’ve covered the mechanics, status codes and testing in our guide to redirecting a URL in WordPress<\/a>, so rather than repeat it: use a 301, not a 302, and verify it with curl -I<\/code> before moving on. One tip worth stealing from that guide \u2014 most redirect plugins can create the 301 automatically<\/em> whenever a published permalink changes. Turn that on before you start and this step does itself.<\/p>\n4. Update your internal links<\/h3>\n
5. Update the sitemap and request indexing<\/h3>\n
\/wp-sitemap.xml<\/code> (or your SEO plugin’s equivalent) and confirm the new URL is there and the old one isn’t; purge your page cache first or you’ll be reading a stale file.<\/p>\n6. Fix the external references you control<\/h3>\n
7. Monitor, and expect a dip<\/h3>\n
curl<\/code>.<\/p>\nChanging the site-wide permalink structure<\/h2>\n
\/2019\/03\/my-post\/<\/code> to \/my-post\/<\/code> is a full site migration in one click. WordPress does try to handle it and can often work out the right destination from an old-style URL \u2014 but with heavy caching, nginx, or custom post types in play, that behaviour is far less reliable than people assume. If you genuinely need the change:<\/p>\n\n
RedirectMatch 301 ^\/[0-9]{4}\/[0-9]{2}\/(.*)$ \/$1<\/code> maps every dated URL to its flat equivalent in one line; on nginx, a rewrite<\/code> with a capture and permanent<\/code>.<\/li>\ncurl -I<\/code>: a recent post, an old post, a page, a category, a custom post type.<\/li>\nFrequently asked questions<\/h2>\n
Does changing a permalink hurt SEO?<\/h3>\n
Do I still need a redirect if WordPress handles old slugs automatically?<\/h3>\n
How long does it take Google to update a changed URL?<\/h3>\n