SEO website
migration

Why migrations go wrong

A new website is usually a design project. The designer focuses on how it looks, the developer on how it works, and nobody is responsible for what Google already knows about the old site. Then launch day comes, the old addresses disappear, and over the following weeks the phone gets quieter. By the time someone checks, the traffic has been falling for a month.

The value of an established website lives in its addresses. Each page that ranks has a history: links pointing to it, clicks from searchers, signals Google has collected over years. Change the address without telling Google where the page went, and that history is thrown away.

The inventory: know what you have

Before anything moves, I build a complete list of the old site's addresses and what each is worth:

• pages that get clicks from search, from Google Search Console;
• pages that bring visitors and conversions, from Analytics;
• pages that other websites link to;
• every address a full crawl finds, including old ones still indexed.

This list is the safety net. It shows which pages must survive with similar content, which can be merged and which can be retired. It often surprises owners: an old blog post or a forgotten service page turns out to bring a big share of enquiries.

The redirect map

Every old address with value gets a permanent (301) redirect to the most relevant new page. Not to the home page: redirecting everything there tells Google the old content is gone. Where the new site combines pages, the redirects point to the combined page. Where content was cut, I argue for keeping it if it ranks. The map is a simple spreadsheet you can see and approve.

Launch checks

Before going live, I test the new site on staging: titles and descriptions, headings, canonical tags, structured data, internal links, mobile layout and analytics tags. On launch day I check that redirects work, the "noindex" setting from staging is gone, the new sitemap is submitted and tracking records visits and conversions. Many migration disasters are caused by one checkbox nobody unticked.

After launch: 90 days of attention

Google doesn't process a migration instantly. For the first weeks, I check Search Console regularly for errors, addresses returning "not found", pages dropping out of the index and keyword groups that lose positions. Small problems caught in week two are cheap to fix; the same problems found in month three have already cost you customers.

Analytics must carry over too. If you move from one setup to another, make sure goals and conversions are recreated on the new site; GA4 and Tag Manager setup covers this.

Migration when I build your new site

When I build the new site, either a website redesign or a new site on a custom CMS, SEO migration is part of the job, not an extra. I keep your domain, move and improve the content that ranks, and handle redirects and checks myself. One person responsible for design, code and SEO means nothing falls between the cracks.

If someone else is building it, I can still oversee the SEO side. For a step-by-step view you can share with your developer, read how to move or redesign a website without losing Google traffic.

Domain changes and rebrands

Changing the domain name is the riskiest kind of migration because every address changes at once. It can be done safely: complete redirects, Google's change of address tool in Search Console, updated Google Business Profile and directory listings, and the old domain kept renewed for years. If you're rebranding, plan the SEO side together with the rebranding itself, not after it.