SEO site migration with visibility checks

How we work on a migration

We run a migration in five stages. Each ends with something that can be checked: a list of URLs, a redirect map, a test result, a launch checklist and a visibility comparison.

If the migration has already happened and visibility fell, start with the section What to do when visibility fell after a migration.

What to prepare for a conversation about a migration

• The current site’s address and the planned publication date.
• The scope of the change: domain, platform or page URLs.
• Contact details of the person who deploys the new version.
• Whether the migration is still being planned or the site already runs on the new URLs.

The analysis will need data on the old URLs and on visibility. We agree with your team how to share Search Console and the staging version.

Types of migration and how their risk differs

An SEO migration is any change after which Google’s crawler has to work out again where the old content now lives. The more URLs change, the greater the risk of a visibility drop.

• Domain change. Every URL gets a new beginning. The risk is high, and correct redirects are one of the main conditions for success, along with testing the new site and checking indexing.
• Switch from http to https. Every URL changes, the content stays. The risk is lower if redirects, canonicals and internal links all point to the https version and the TLS certificate is valid.
• CMS or shop platform change. The new system has different templates and markup, and often different rules for generating URLs. The risk comes from the page code changing, often along with the URLs. You need to check which URLs stay and which need redirects.
• URL structure change. Pages change URLs on the same domain, for example after renaming categories. The risk grows with the number of URLs affected.
• Merging sites. Several domains or shops move under one address. You have to decide which content stays, which is merged and which disappears.

When a migration combines several changes at once, it is harder to find the cause of a drop. If you can spread them over time, it is worth doing so.

Taking inventory of URLs before the migration

You can only redirect what you know about, so a full list of the old site’s URLs is the first step. No single source shows everything, so we combine several.

• Site crawl. A crawler follows links the way Google does. It will not find pages that nothing links to.
• Search Console. The Performance report shows URLs that appeared in results, together with their queries. The Page indexing report shows what is in the index.
• Sitemap. It shows the URLs submitted to search engines. Sitemap URLs that the crawl did not find may point to orphaned pages. First we rule out blocks, server errors and crawl settings.
• External links. An export from a link analysis tool shows URLs that other sites link to. A URL with no search visits can still pass on value.
• Images, videos and files. URLs of images, videos, JavaScript and CSS files go into the plan too, because they have to be moved like the rest of the content.

These sources produce a single table: URL, response code, title, links, impressions and queries, indexing status. We also record a visibility baseline: keywords in the top 10, domain visibility, and citations in ChatGPT, Gemini, Perplexity and Claude answers. After the migration we compare new measurements against it.

A one-to-one 301 redirect map

A 301 redirect tells browsers and crawlers that a URL has moved permanently. The redirect map assigns each old URL its content equivalent.

1. From the URL list we mark those that have links, impressions or positions.
2. For each one we name the equivalent on the new site. Where URLs follow a regular pattern, a rule is enough, and we map the rest by hand.
3. Pages that disappear are redirected only when the new site has content that replaces them. When there is no such content, the URL returns a 404 or 410 status.
4. We check the map with a script: every old URL should return a 301 and end on a URL with a 200 status.

What to avoid

• Redirect chains. When A leads to B and B to C, the crawler wastes time. A redirect should go straight to the final URL.
• Redirecting everything to the home page. The home page is not an equivalent of a removed page, so such a redirect confuses users, and Google may treat it as a soft 404 error.
• 302 redirects. A 302 means a temporary change. A migration is permanent, so we use 301 or 308.
• Redirect loops. Two URLs pointing at each other make the page impossible to load.
• Missed variants. URLs with and without a trailing slash, with and without www, can have links too.
• JavaScript redirects. They may not run, so we set redirects on the server.

After a migration, the Page indexing report in Search Console lists redirected URLs under “Page with redirect”. That status is expected for old URLs, and a problem only when a URL that should stay live appears there.

Testing the staging version before launch

A staging version is a copy of the new site at a separate address. It is meant to expose errors before Google sees them, so first it has to be closed to indexing.

• Password or IP access. The most reliable method, because a crawler cannot see the content.
• A noindex tag. An additional safeguard. It has to be removed at launch.
• A robots.txt disallow. It blocks crawling, but the URL can still get into the index if someone links to it. At launch the file has to be changed.

On the staging version we check:

• redirects from the map, with no chains,
• canonicals pointing to the target URLs and correct meta robots,
• titles, descriptions and headings carried over from the old pages,
• internal links pointing straight to the new URLs,
• structured data, the sitemap and hreflang,
• rendering: whether the content is visible after JavaScript runs,
• the new version’s performance in tests. After launch, once data from real visits is available, we assess Core Web Vitals: LCP up to 2.5 s, INP up to 200 ms and CLS up to 0.1 for 75% of visits.

We compare a crawl of the staging version with a crawl of the old site and look for URLs that vanished or changed content.

Launch day: a checklist

1. Back up the old site, its robots.txt and its sitemap.
2. Deploy the new site and switch on the 301 redirects from the map.
3. Remove the staging blocks and check robots.txt in production.
4. Review the key pages: status 200, correct canonical, no noindex.
5. Run the whole redirect map through a script on the live server.
6. Submit the new sitemap with the target URLs in Search Console.
7. Verify the new domain or property if the domain changed.

Record the launch date, and have a developer and the person who decides on a rollback available during deployment.

The first weeks after launch: what to monitor

After launch, the search engine processes redirects gradually, so fluctuations in visibility are normal. Lasting errors have to be told apart from temporary ones, so we check several areas regularly.

• Redirects. Re-crawl the old URLs: do they return 301 and end on a 200?
• 404 errors. The Page indexing report in Search Console and server logs show URLs outside the map. Those with links or impressions get added to the redirects.
• Indexing. The number of new URLs in the index should rise and the number of old ones fall. When new ones do not get in, we check for noindex, robots.txt blocks and whether the canonical points to the right URL.
• Top 10 keywords and visibility. A comparison with the baseline, separately for groups of pages: services, categories, articles.
• AI citations. Whether ChatGPT, Gemini, Perplexity and Claude point to working URLs. Ongoing measurement is covered by monitoring of your brand in AI answers.

We assess results by groups of pages. Single position swings are normal. A group whose visibility keeps falling is the warning sign.

Changing the domain and the Change of Address tool in Search Console

1. Check the history of the new domain for spam and earlier penalties.
2. Add and verify both the old and the new domain in Search Console.
3. Deploy 301 redirects from the old domain to the new one, URL by URL.
4. In the old property, use the Change of Address tool and point it at the new domain.
5. Submit the new domain’s sitemap.
6. Keep control of the old domain, because the redirects must work for as long as they are needed.

The tool tells Google about the move, but it does not replace redirects. It is not used for a switch from http to https or for moving pages within the same domain.

After a domain change we also update the Google Business Profile, business directories, social media profiles and the organisation data in schema.org, so that search engines and AI assistants link the new domain to the same brand.

What to do when visibility fell after a migration

1. Establish the scope. Compare visibility and indexing before and after the migration, by groups of pages.
2. Check for blocks. Common causes are a noindex or a robots.txt disallow carried over from staging, and canonicals pointing to old URLs.
3. Verify the redirects. Check URLs from the inventory that do not end with a 200. Add the missing ones and shorten the chains.
4. Compare content. Set the titles, headings and copy of important pages side by side, before and after. Lost keywords weaken the match to queries.
5. Check internal linking. The new template may have removed links from the menu or the body.
6. Examine performance and rendering. The new platform may have worsened Core Web Vitals or moved content into scripts.
7. Fix in order of impact. Blocks and missing redirects first, then content and linking.

After the fixes we ask Google to re-index the most important URLs and watch the same indicators as before the migration. How fast visibility returns depends on the site, so we do not state it in advance. Before a planned migration it is worth ordering an SEO and GEO audit. The principles of our work on visibility are described on the SEO services page, and online shops are covered in e-commerce SEO.

Describe the drop after your migration