Technical SEO · November 11, 2026 · 8 min read
Does Changing a Blog Post URL Hurt SEO?
Changing a blog post URL only costs you something if that URL already ranks or has links. Here is the decision rule, the redirect checklist, and how to tell when it has settled.
By FluxWriter
Changing a blog post URL hurts SEO only when the old URL had something worth losing. A post published three weeks ago with no rankings, no links and no traffic can be renamed freely. One that ranks and has links pointing at it costs you a re-crawl cycle even with a clean 301 in place, and that bill is paid in weeks of unsettled positions rather than in permanent damage. This walks through when the swap is free, what a redirect does not carry over, and how to read Search Console to tell when it has settled.
What the Old URL Already Earned Decides the Answer
A URL on its own is worth nothing. What has value is what accumulated against it: the positions a search engine recorded for that address, the links other sites point at it, the internal links on your own site, and the click history in Search Console. Change the URL and you are asking for all of that to be moved. The move normally works. It is the interval between asking and confirmation that costs you.
Check three things before touching a slug. Does the post get organic impressions in Search Console over the last three months. Does any other site link to it. Is it referenced anywhere you do not control, such as an email sequence, a partner's resource page or a paid landing page. If all three come back empty, the URL has no equity and the change is free.
Most posts on most blogs fall into that group. On a blog of 80 posts, a handful usually carry the large majority of organic traffic. Check rather than assume, because the post you write off as inert is occasionally the one with a link from a trade publication.
A 301 Moves the Signals, Not the Timing
A 301 redirect tells crawlers and browsers the page has permanently moved. Use a 301 and not a 302: a 302 says temporary, and temporary is not what you mean when you rename a slug.
What a redirect cannot do is make the change instant. The old URL has to be recrawled before the redirect is discovered, the new URL has to be crawled, and the new address accepted as the canonical version of that content. A site crawled daily moves through that quickly; a small blog crawled every few weeks does not. As a rough rule, assume a few weeks before the new URL reports normally and treat anything faster as a bonus.
Positions can wobble during that window. The page may hold, or slip a few places and come back. What you should not do is react to a dip in week two by changing the URL again, which restarts the cycle and adds a redirect hop.
Good Reasons to Change a Slug Are Narrower Than You Think
The reasons that hold up are the ones where the URL is actively wrong. A stale year in the slug, a product name you no longer sell, auto-generated noise like /post-name-2 or a bare numeric permalink, a post rewritten so heavily it now answers a different question, or a directory move because the whole blog is shifting from /2019/03/ to a flat structure. Those are structural problems and they are worth the re-crawl.
The cosmetic reasons do not hold up. A slug rewrite on its own rarely moves position: the title, the body and the links do that work, and the words in the URL are a small part of the picture.
That matters because of where the anxiety usually starts. Changing the title of a post does not require changing its URL. Rewrite the headline, the intro and half the body, and leave the address as it was.
The Cost Scales With What the Page Already Does
The traffic figures below are illustrative rather than measured, and are there only to make the trade-off concrete.
| Page state | Illustrative monthly organic visits | What the change costs you | Worth doing |
|---|---|---|---|
| Published recently, no impressions | 0 | Nothing | Yes, do it now |
| Ranking beyond page two | 20 | A re-crawl cycle, no visible dip | Yes, if the slug is wrong |
| Ranking in the top ten | 300 | Weeks of unsettled position | Only for a structural reason |
| Carrying links from other sites | 300+ | Link signals route through a redirect | Only if the redirect is permanent |
| Used in email or paid campaigns | Varies | Broken tracking and an extra hop | Update the sources first |
Put a number on the middle case. A post pulling 300 organic visits a month that sits 30% below its usual level for six weeks loses about 90 visits a month for a month and a half, roughly 135 visits in total. That is the realistic shape of the downside on a page that recovers: small enough that a genuinely wrong URL is still worth fixing, large enough that you should not rename your best page because the slug reads awkwardly.
Rewrite the Internal Links Rather Than Leaving Them to the Redirect
A redirect is a safety net, not a fix. Every internal link still pointing at the old slug sends visitors and crawlers through an extra hop. One hop is cheap. The problem arrives the second time: rename that URL again next year and the old links pass through two redirects, and chains are where crawlers lose patience and a stray mistake becomes a loop.
So the order is fixed. Put the redirect in place, then find and update every internal link. Search your own content for the old slug. Check the navigation, the footer, any related-posts block that stores URLs instead of post IDs, and any link hard-coded into a theme file or widget. On WordPress a search-and-replace across post content catches most of it, but menus and widgets are stored separately.
Then regenerate the XML sitemap so it lists the new URL only; if the old URL is still listed the next day, rebuild it by hand. Last, confirm the canonical tag on the new page points at itself rather than the old address. A canonical left pointing backwards is the most common way a rename quietly fails.
Some Things a Redirect Never Carries
Analytics history splits at the moment of the change. GA4 and most analytics tools report by page path, so the old path stops collecting and the new one starts from zero. Nothing is lost, but any month-over-month report on that page now needs both paths added. Search Console works the same way: Performance data is keyed to the URL, so the new address starts with an empty record and the old one keeps its history until it ages out.
Share counters displayed on the page reset, because those numbers are keyed to the exact URL string. Comment systems that key by URL, Disqus being the common one, can orphan the thread until you run their migration tool. Native WordPress comments are attached to the post rather than the address, so those survive.
None of that is a ranking problem. It is a reporting problem, and it is the part people forget because their attention went to the redirect. Note the date of the change somewhere you will find it again, so that in three months a cliff on the old path does not read as a penalty.
Search Console Tells You When the Swap Has Settled
Three checks, in order. Inspect the new URL first. You want it reported as indexed, with the Google-selected canonical matching the new address. If the inspection names the old URL as the canonical, the new page has been crawled but the move has not been accepted yet, and the answer is to wait.
Then inspect the old URL. Once processed it should come back as a page with a redirect, and it will appear under that label in the Pages report. That label is the confirmation you want, not an error to fix. Do not request indexing on the old URL to hurry it along.
Then read the Performance report. Filter to the new URL and watch impressions arrive; filter to the old one and watch them decay. When the new address carries roughly the impression volume the old one held, and the old one is near zero, the swap has settled. Requesting indexing once on the new URL is reasonable; repeating it achieves nothing.
FAQ
Can I delete the old URL instead of redirecting it?
You can, and if the page genuinely had no impressions, no links and no references anywhere, a 404 does no harm. The catch is that a redirect costs nothing to add, so a deliberate 404 saves you a minute of work. Where there is any doubt about what pointed at the old address, redirect it.
How long should I keep the redirect in place?
Google's published guidance for site moves is at least a year, and on a blog there is no practical reason to remove one after that. Links on other people's sites do not get updated, and an old redirect costs nothing to keep. Treat removing redirects as a task you never schedule.
Does putting a keyword in the slug improve rankings?
It rarely moves position on its own. The words in a URL are a small signal next to the title, the content and the links pointing at the page. Write a slug that is short and readable, then leave it alone.
The Practical Takeaway
This week, separate the posts you can rename freely from the ones that need a plan. Pull the last three months of Search Console data at page level and sort by impressions. Everything at zero can be renamed today with a redirect and an internal-link sweep. Anything with real impressions goes on a shorter list, gets changed only if the URL is structurally wrong, and gets the full sequence: 301 in place, internal links rewritten, sitemap regenerated, canonical checked, Search Console inspection a week later. Start by exporting that Pages report and marking every URL with zero impressions as safe to change.