Rebuild your website, keep your Google rankings

A website migration is any change big enough to change how search engines see your site. A redesign that changes page addresses is one. So is moving from WordPress to another platform, changing your domain, merging two websites, adding language versions or moving to HTTPS.

Each of these changes something search engines have learned about your site over years: where each page lives, what it is about and which other sites link to it. A migration is the work of moving all of that to the new site, so the trust your old pages earned isn’t left behind at addresses that no longer exist.

Many redesigns treat this as a small job at the end. We treat it as its own project, planned from the first week, because it decides whether the new site starts with your search traffic or without it.

Rankings are rarely lost to the new design itself. They are lost to a handful of avoidable mistakes.

• Pages vanish. Old addresses return errors, so search engines drop them and the links pointing to them go nowhere.
• Redirects go to the wrong place. Everything is sent to the home page, which search engines treat as missing pages.
• Content that ranked is cut or merged until it no longer answers the search it ranked for.
• Signals are dropped: titles, descriptions, structured data, internal links and hreflang tags left behind.
• Staging settings go live, such as a noindex tag or a robots rule that blocks the whole site.
• Tracking breaks, so nobody notices any of the above until the enquiries slow down.

A careful migration is a checklist against each of these, worked through before, on and after launch day.

Before anything is designed, we find out what the current site is worth in search. We crawl every page, pull clicks and search terms from Search Console, visits and conversions from analytics, and the links pointing in from other sites.

That shows which pages matter. On most sites, a fairly small share of pages brings most of the search visits and enquiries, while others have links from other sites that are worth keeping. We also record where you stand today for the searches that matter to you, so there is a clear benchmark to compare against after launch.

The audit often finds problems worth fixing in the move: duplicate pages, broken links, missing titles and old addresses that already return errors. On large sites we also read the server logs, which show the addresses search engines actually visit, including old ones no crawl would find from the menus.

The redirect map is the heart of the migration. It lists every old address and the new page that replaces it, matched by meaning, not just by name. A product page goes to the same product’s new page, a guide to its updated version, a category to its new category.

Where a page has no true replacement, we send it to the closest useful page or let it return a proper “gone” response; we never send everything to the home page. PDFs, images that get search traffic and old addresses with links from other sites are mapped too.

Large sites are mapped with pattern rules and then checked line by line where the traffic is. You review and approve the map before launch, and it stays with you as a record of what moved where.

Redirects tell search engines where a page went; the new page still has to be as good as the old one. For each page we carry across or rebuild the title, the description, the main heading, the structured data, canonical tags, hreflang for language versions and alt text for images.

Links inside the site are updated to the new addresses, so menus, footers and links in old articles point straight at the new pages instead of hopping through redirects. The XML sitemap lists only the new addresses, and robots rules are checked so nothing important is blocked.

Content can be improved during the move, but carefully. Rewriting a page that ranks well changes what search engines see, so we change what needs changing and leave the rest.

A migration has to keep your measurements working, or you can’t see whether it went well. Google Analytics 4, Tag Manager, conversion events, Google Ads and Meta tags, and cookie consent are rebuilt on the new site and tested on staging before launch.

Analytics history stays in the same property, so before and after can be compared. If the domain changes, the new domain is added to Search Console and verified before launch, so its data starts on the first day. Ad campaigns pointing at old landing pages are updated to the new addresses, so paid clicks don’t pass through redirects or land on errors.

The new site is built on a staging copy behind a password, so search engines can’t index it and it never competes with the live site. There, we test the whole redirect map against the new pages: every old address should reach its final page with a single permanent redirect.

We crawl the staging site as a search engine would, check titles, structured data and internal links, and compare the result with the old site’s crawl. Anything missing or broken is fixed before the switch, not discovered afterwards.

Launch is a checklist, not a moment of hope. DNS changes are prepared ahead so the switch reaches everyone quickly, and the launch is timed for a quiet hour on a working day, when your team and ours are both around. The new site goes live, redirects switch on, and we test them again in bulk on the live site. Staging settings such as noindex tags and password protection are confirmed gone.

The new XML sitemap is submitted in Google Search Console and Bing Webmaster Tools, and key pages are inspected so search engines pick them up quickly. If the domain changes, Search Console’s change of address tool is used and the old domain keeps redirecting for as long as possible, and at least a year, as Google advises. We also ask the sites that link to you most to update their links where we can.

The weeks after launch are when problems show, so we watch closely. Search Console shows old addresses leaving Google’s index as the new ones are picked up, along with any crawl errors, pages not found or pages excluded by mistake.

Each problem is fixed as it appears: a missed redirect added, a broken template corrected, a page that dropped out inspected. Rankings and clicks for the pages that matter are compared with the benchmark from the audit. Some movement is normal while Google recrawls; a page that keeps falling gets attention.

When the new addresses have replaced the old ones and the numbers have settled, we send a short report of what moved, what was fixed and how search traffic and enquiries compare with before.

We need access, early. That means Search Console and analytics, your DNS and hosting, the current site’s admin, and your ad accounts if campaigns point at the site. Access can be given to our team’s accounts and removed once the work is done.

We also need someone who knows the business to review the redirect map, especially where pages are being merged or dropped, and to tell us about seasons and campaigns so the switch happens at a quiet time. If another team is building the new site, we work alongside them, so the migration is part of their plan rather than a job squeezed in at the end.