Changing Your Website Without Losing Your Rankings

A redesign is the quickest way to undo years of search visibility. Not because new designs are bad, but because a relaunch changes hundreds of small things at once, and search engines have to re-learn all of them. Do it carefully and the dip is shallow and short. Do it without a plan and the recovery can take longer than the build did.

This is the sequence we work through. Follow it in order; most disasters come from doing step six before step two.

First, work out how risky this actually is

Migrations are not one thing. Rank the risk before you plan the work.

A visual refresh with identical URLs and identical copy is low risk. Nothing about the address or the content changes, so there is little to re-learn.

A new CMS on the same domain is medium risk. URLs usually change even when nobody intended them to, because the new platform has its own opinions about how paths are built.

A restructure — new URL patterns, merged or removed pages is high risk. Every changed address needs a destination and every merged page loses something.

A domain change or a consolidation of several sites into one is the highest risk there is. You are asking search engines to transfer everything they know about one identity to another.

The higher the tier, the more of the checklist below is mandatory rather than advisable.

Build the inventory before you touch anything

You cannot redirect what you have not listed. Do this while the old site is still live.

• Crawl the existing site with a desktop crawler and export every URL that returns a 200, along with its title, H1, meta description and canonical.
• Export the last sixteen months from Search Console. The Performance report Pages tab gives you every URL that has earned an impression. Anything on that list matters, including pages you had forgotten about.
• Export your top landing pages from analytics, sorted by conversions rather than sessions. These are the pages you cannot afford to break.
• Pull your XML sitemaps and your existing redirect rules. Old redirects still carry signals and often need re-pointing.
• List your inbound links. Search Console’s Links report shows which of your pages other sites point at. A page with external links is worth preserving even if its traffic is small.
• Take a rankings snapshot for your important terms. Without a before, you cannot judge the after.

Save all of this somewhere outside the site. Once the old build is gone, it is gone.

Keep the URLs unless you have a reason not to

The safest migration changes no addresses at all. Every URL you preserve is a redirect you do not have to write, a signal you do not have to transfer, and a thing that cannot break.

Designers and developers will want to tidy the structure. Sometimes that is justified — genuinely broken paths, dates baked into article URLs, category folders that no longer describe anything. Often it is aesthetic. Ask what the change buys, and if the answer is neatness, keep the old path.

If URLs must change, change them once. A site that restructures again eighteen months later ends up with chains of redirects pointing at redirects.

The redirect map

This is the document the whole migration hangs on. One row per old URL, one destination per row.

Rules that matter:

Use 301, not 302. A permanent redirect signals a permanent move. Temporary redirects leave the old URL as the one being considered.

Map one to one, as specifically as possible. An old service page should go to the equivalent new service page. Sending it to the homepage or a category listing throws away the relevance that made it rank.

Never blanket-redirect everything to the homepage. Search engines treat mass redirects to an irrelevant destination as soft 404s, and you lose the lot.

Avoid chains. If old A pointed to old B, and B is now C, point A directly at C. Chains dilute signals and slow crawling.

Decide deliberately what to let die. Some pages should return 410 or a proper 404. A tag archive with two posts on it does not need a destination. Redirecting genuinely dead content to something unrelated is worse than letting it go.

Handle the trailing slash and case rules in one place, at server level, so the new site does not create fresh duplicates on day one.

Test the map as a spreadsheet before it becomes code. Sort by destination and look for the URLs receiving hundreds of sources — that is usually a lazy pattern rule, not a decision.

Check the staging site properly

Staging is where migrations are actually saved.

Block it first. Password-protect the staging environment, or serve noindex headers. Do not rely on robots.txt alone, because a disallowed page can still be indexed if something links to it.

Then crawl staging as though it were live, and compare against your original export:

• Are the title tags and H1s present, or did the new theme drop them?
• Are canonicals pointing to the new live domain, or still at staging?
• Did the meta descriptions survive the content migration?
• Is the body copy actually there? Content rendered only by JavaScript sometimes is not.
• Are internal links pointing at new URLs, or at old ones that will now redirect?
• Did structured data, alt text and hreflang come across?
• Do the images exist at their new paths?

Run your redirect map against staging too, so you find the mistakes while they are cheap.

Launch day

Work through this in order, immediately after the switch.

1. Remove the staging block. The single most common relaunch catastrophe is shipping the noindex or the Disallow: / that was protecting the build.
2. Check robots.txt on the live domain. Read it, do not assume it.
3. Confirm redirects fire against the live server, not just in the config file. Spot-check twenty URLs including your top five landing pages.
4. Submit the new XML sitemap in Search Console. For a domain move, use the Change of Address tool and keep the old domain’s Search Console property verified.
5. Verify tracking still runs. Analytics tags and conversion goals are routinely lost in a rebuild, and you will not notice for weeks.
6. Check the site renders and loads on a phone, on a real connection.
7. Keep a copy of the old site’s sitemap and submit it as well. It sounds counterintuitive, but it helps crawlers find the old URLs quickly so they can process the redirects.

The first week, then the first month

Expect some fluctuation. A short dip while pages are recrawled and reassessed is normal even on a clean migration. What you are watching for is whether the trend turns back up.

Days one to seven: check the Search Console Pages report daily for a spike in “Not found (404)” and “Page with redirect” that should not be there. Watch Crawl Stats for a jump in error responses. Look at server logs if you have them. Fix 404s from real referrers immediately — every one is a lost link.

Weeks two to four: compare Search Console impressions against your pre-launch baseline, by page rather than site-wide. Check that the new URLs are being indexed and the old ones are dropping out. Re-run your rankings snapshot. Confirm conversions are being recorded at the same rate.

If things have not stabilised after six to eight weeks, stop waiting and start diagnosing. The usual culprits are a redirect rule that never deployed, a canonical still pointing at the old domain, an indexing block left in place, or content that quietly got thinner in the rebuild.

The part people skip

Nobody budgets for the fortnight after launch. The build gets signed off, the team moves on, and the small breakages accumulate unnoticed until a quarter of traffic has gone.

Book that time before you start. A migration is not finished when the site goes live. It is finished when the indexing reports are clean and the numbers have come back.

If you want the redirect mapping and post-launch monitoring handled alongside the build itself, that is a sensible thing to scope together — and the tracking should be part of the same conversation. To talk it through first, get in touch.