How do you keep your Google rankings when you rebuild a website?

There's a single most expensive mistake in rebuild projects: not redirecting the old addresses to the new ones. What usually happens is this. The new site looks good, search traffic drops two weeks later, and nobody can work out why.

We applied the method below when we rebuilt our own site.

Why does traffic get lost?

Google associates the content at an address, and the value of the links pointing to that address, with that address. When the address disappears, so does the association. Even if the content on the new site is identical, Google sees it as a new page because it's published at a different address, and the standing has to be built up from scratch.

A 301 redirect is the standard way of saying "this content has moved permanently to this address", and it carries the signals across to the new address.

Step 1: Produce a full inventory of the old addresses

Before you start the rebuild you need a list of every old address. Sources:

Looking only at the sitemap isn't enough; sitemaps usually carry missing or surplus addresses. Our own old site's sitemap listed 85 addresses, and 8 of those were pages coming from the theme template that returned no content at all.

Step 2: Make a decision for each address

For every old address, one of three options gets chosen:

301, permanent redirect. Used when the content has an equivalent on the new site. The target should be the closest page by subject; redirecting to an unrelated page can be treated by Google as a soft 404.

410, permanently removed. Used when the content genuinely no longer exists and won't have an equivalent. Unlike a 404, it says "stop looking" and drops out of crawling faster.

No change. If the address stays the same, no redirect is needed.

How do you merge duplicate pages?

A common situation on older sites is several pages covering the same subject. On our own old site, five pages carried exactly the same title; on top of that there were two near-identical copies of the page for each of several service areas.

In that case the strongest page is chosen as the target and the others are 301'd to it. The single page that comes out of the merge gathers up the scattered signals.

Step 3: Put the redirect map in writing

The map should be kept in a table, and each row should carry:

This table serves both as the developer's task list and as the post-launch checklist.

Technical points to watch

• Don't build chains. Write A → C directly instead of A → B → C. Chains cost speed and in some cases weaken the transfer of signals.
• Don't create loops. Rows where source and target are identical produce an endless loop.
• Don't use 302. A temporary redirect gives the wrong signal on a permanent move.
• Settle the trailing slash with one rule. If both /page and /page/ work, redirect one to the other.
• Don't forget old addresses with capital letters or non-ASCII characters in them.

Step 4: Pre-launch checklist

• Canonical tags are correct for every page on the new site
• A new sitemap.xml is generated and contains only pages meant to be indexed
• robots.txt carries no leftover "block everything" rule from development
• Page titles and descriptions are no worse than on the valuable pages of the old site
• Internal links point to the new addresses (they don't travel via a redirect)
• Structured data markup produces no errors
• Every row of the redirect map has been tried in the test environment
• Analytics and Search Console tags are installed on the new site
• If the domain is changing, Search Console's change of address tool is ready

The most critical line is the robots.txt one. Carrying the blocking rule that was put in place to keep the site closed during development over to production is the most frequent disaster in rebuild projects.

Step 5: Launch day and after

On launch day:

1. Verify the redirects one by one in production. Don't check from the browser — use a tool that shows you the status code
2. Submit the new sitemap to Search Console
3. Request indexing for the home page and the most valuable pages
4. Start watching the 404 records

For the first 90 days, look at these weekly:

A short-lived dip is normal. Google needs time to recrawl and reassess the new structure. Reverting in a panic only makes the process longer.

What if the domain is changing too?

Try not to change the address structure and the domain at the same time. If both change and something goes wrong, you won't be able to tell which one caused it.

If it's unavoidable, the order should be: move the domain first and set up the 301s, use the change of address tool in Search Console, and once traffic settles, move on to the structural change.

The document to ask your agency for

In a rebuild, the design and the code are the visible part of the job; the work that actually preserves what you've built up is the address inventory and the redirect map. Ask your agency for that map in writing; if there isn't one, this work has most likely not been planned.

You can request a quote for your rebuild, or have a look at our SEO service.