Does changing a URL affect SEO? Yes — and four quieter things a rewrite breaks

Does changing a URL affect SEO? Yes, and it is the only part of a rewrite that can cost you everything the page has earned. Rewriting the body text is reversible. Changing the address is not, unless you set up the redirect and keep it. Four quieter things break alongside it, and all five should be locked before you touch the page, not repaired afterwards.

Read this first

This chapter is the other half of the rewrite worksheet. That one tells you what to change on a page; this one tells you what the change can knock over. If you have not run a rewrite before, read the one-page SEO rewrite checklist first and come back for the risk side.

It also assumes you saved a before. Every rollback criterion below is a comparison, and a comparison needs two numbers, which is the entire point of recording a baseline before you change anything.

Does changing a URL affect SEO more than the rewrite itself

Almost always, yes. A body rewrite changes what the page says. A URL change changes what the page is, from the point of view of every system that stored a pointer to it — the index, other people's links, your own navigation, analytics history, anything that ever bookmarked it.

Google's redirect documentation describes the mechanism plainly: "Googlebot follows the redirect, and the indexing pipeline uses the redirect as a signal that the redirect target should be canonical." The signal transfers, but only if the redirect exists and stays. Google's site move guidance puts a number on how long: "Keep the redirects for as long as possible, generally at least 1 year. This timeframe allows Google to transfer all signals to the new URLs, including recrawling and reassigning links on other sites that point to your old URLs."

The choice of redirect type matters and is often made carelessly. Permanent and temporary do opposite things: "Permanent redirects: Show the new redirect target in search results" versus "Temporary redirects: Show the source page in search results." Google's advice on which to pick is a sentence worth reading twice — "Use permanent redirects when you're sure that the redirect won't be reverted." Every quotation in this chapter was read on 2026-08-19, from the redirects, site move and canonicalization pages at developers.google.com.

Changing a URL is not an edit. It is a move, and the forwarding address has to outlive your memory of setting it up.

The four quieter things

None of these announces itself. Each one produces a page that looks fine in a browser and reads wrong to a crawler.

The canonical still points at the old address

Templates that build the canonical from a stored field, rather than from the current request, will keep emitting the old URL after the move. The page then redirects you to the new address while telling search engines the old one is the real one. Google's guidance is to use absolute paths here — "Even though relative paths are supported by Google, they can cause problems in the long run" — and a self-referential canonical on the surviving page is the recommended state.

Internal links still point at the old address

They will work, because the redirect works, and that is exactly why nobody notices. Google's site move checklist names this as its own step: "Change the internal links on the new site from the old URLs to the new URLs." A redirect you control inside your own navigation is waste you chose.

Structured data drifts away from the visible page

If the rewrite changed the heading, the description or the author block, and the JSON-LD was written by hand, the two now disagree. Structured data that contradicts what is on the page is worse than none, because it is a claim you are making that the page does not support.

The title changes without anyone deciding to change it

Rewrites tend to touch the h1 and let the title element follow from a template, or the reverse. Either way the search listing changes on the next crawl, and if the old title was the reason a page got clicks, that is the thing you altered by accident.

The deliverable: lock these five before you start

Copy the current values into a file before the first edit. The rightmost column is what you compare against when something looks wrong two weeks later.

The order that keeps it recoverable

Order is the difference between a change you can undo and a change you can only apologise for.

1. Capture the six rows above. This is ten minutes and it is the only step that cannot be done later.
2. Decide whether the URL is changing at all. If the current address is merely ugly rather than wrong, leave it. An ugly URL costs you nothing that a redirect does not cost more.
3. If it is changing, publish the new page and put a permanent redirect on the old address in the same deployment. Not the next day.
4. Update the canonical on the new page to point at itself, and confirm it in the delivered source rather than in the template.
5. Update every internal link that pointed at the old address, using the list from step 1.
6. Re-check the structured data against the rewritten page, field by field.
7. Submit the new address for indexing and make sure it is in your sitemap while the old one is not.

Steps 3 through 5 belong to the same working session. A redirect without updated internal links is a half-move, and half-moves are where the traffic goes missing.

Verify step 3 with a request rather than a browser. Your browser may have cached the old address, or been sent somewhere by a service worker, and either will show you a redirect that is not actually being served. Fetch the old address with something that reports the status code, confirm it is a permanent one, and confirm the destination is the exact new address rather than a second redirect on the way to it.

One extra item if the page has translations: the hreflang annotations on every language version reference this URL, and they are usually stored somewhere other than the page you just moved. A move that updates one language and leaves the others pointing at the old address turns a working cluster into a set of broken declarations.

When to roll back, and when to wait

Waiting is usually right, and knowing why is what stops you reversing a good change on day four.

Google says to expect the dip: "Expect temporary fluctuation in site ranking during the move." It also gives a rough duration for the whole process — "a medium-sized website can take a few weeks for most pages to move in our index; larger sites can take longer". So a decline in the first fortnight is inside the documented behaviour, not evidence of a mistake.

Note what the last row does not say. Reverting the text is cheap; reverting the URL means a second move, and a second move costs the same as the first while looking to search engines like indecision. Once the address has changed, keep it and fix everything else.

Where this chapter stops

We cannot tell you how much traffic a specific URL change will cost, and neither can anyone else, because it depends on how many external links point at the old address — a number you can only partly see. Any percentage you have been quoted for this is somebody's single case.

The one-year redirect figure is Google's own guidance for site moves, not a guarantee, and it says "as long as possible" before it says one year. Our reading is that you should keep them indefinitely unless the redirect itself is causing a problem, but that is our judgement, not something Google states.

Two more limits. This chapter is about one page or a small set; a whole-site migration has failure modes of its own that are not covered here. And on a hosted platform you may not be able to control the redirect type at all, in which case the honest answer is to not change the URL.

If it helps to see how sites actually declare their addresses in practice, we measured it: the canonical tag survey found 23 of 28 homepages shipping one, and every single one agreeing with the address we were served.

Noticing on the day it happens that a redirect was never deployed, or that a canonical is still naming an address you retired, rather than a month later in a report, is what QueryWin is being built to do.

Common questions

Does changing a URL hurt rankings permanently?

Not if a permanent redirect is in place and stays. Google describes the redirect as the signal that transfers canonicality, and asks that redirects be kept generally at least a year.

How long should I keep the old URL redirecting?

At minimum a year, per Google's site move guidance. We keep them longer, because the cost of one more rule is close to zero and the cost of removing it too early is a page that vanishes.

Can I change the URL and the content at the same time?

You can, and then you will not know which one caused what you see. If the page matters, move it first, let it settle, then rewrite.

Is a 302 ever the right choice for a rewrite?

Only if you genuinely might revert. Google's rule is to use a permanent redirect when you are sure it will not be reverted, which is the same test stated from the other side.

Do I need to update internal links if the redirect works?

Yes. Google's own move checklist lists updating internal links as a step, and a redirect inside your own site is a hop you chose to keep paying for.