Website Migration SEO: Site Migration Checklist to Keep Pages Indexed Through a Redesign or Domain Change

Website migration SEO checklist

The order matters more than the contents. Nearly every item below appears on every checklist you will find, but teams routinely do them in an order that makes the important ones impossible. You cannot build an accurate redirect map after the old site is gone, and you cannot tell whether the migration succeeded if you never recorded what success looked like beforehand.

• Before launch: export the full list of URLs Google currently has indexed, not just the URLs in your sitemap. The two lists are never the same, and the difference is usually old pages still earning traffic that nobody on the project knows about.
• Before launch: record current impressions, clicks and average position per URL. This is your baseline. Without it, every post-launch argument about whether traffic dropped is a matter of opinion.
• Before launch: map every old URL to its single closest new equivalent. One hop, no chains. If there is genuinely no equivalent, decide deliberately between a 404 and a redirect to a parent category, and do not default to sending everything to the homepage.
• Before launch: check the staging site for the noindex tag or robots.txt disallow that is protecting it, and write down exactly who removes it and when.
• At launch: verify the redirects return 301 or 308 and not 302. Google treats permanent redirects as a canonical signal and temporary ones as an instruction to keep showing the source page.
• At launch: submit the new sitemap in Search Console. Google says you can remove the old sitemap at that point because it will use the new one going forward.
• At launch: if the registrable domain changed, submit the Change of Address request, including for the domain variants you do not actually use.
• At launch: update internal links, canonicals and hreflang to point at the new URLs directly. Leaving them pointing at redirects works, but it wastes crawl on hops and makes every later audit harder to read.
• After launch: check index coverage on both URL sets, repeatedly, for at least a month. This is the step that gets skipped, and it is the only one that tells you whether the move is actually happening.
• After launch: keep the redirects. Google says to keep them for as long as possible and generally at least a year, which is much longer than the 180 days the Change of Address signal runs.

How long does it take to recover from a site migration?

Google gives a direct answer for the indexing half of the question. Its documentation on moving a site with URL changes says that "as a general rule, a medium-sized website can take a few weeks for most pages to move in our index; larger sites can take longer". It also says that "the visibility of your content in Search may fluctuate temporarily during the move" and that "this is normal and a site's rankings will settle down over time".

A few weeks is the honest expectation for a normal move, and the size of the site is the main variable, because Google has to recrawl each old URL individually to discover its redirect. A ten page site can move in days. A hundred thousand page catalog moves in whatever order Googlebot gets to it, which means you will spend a month watching a chart that is half old URLs and half new ones.

What that guidance does not do is tell you whether your specific migration is progressing or stuck, and those two look identical for the first fortnight. The way to tell them apart is direction of travel, not absolute numbers. A healthy move shows old URLs leaving the index at roughly the rate new ones enter it, week over week. A broken one shows old URLs dropping while the new ones flatline, which usually means Googlebot is following the redirect and then hitting something on the target that stops it, most often a canonical that still names the old URL or a noindex that shipped with the new template.

Set the four week mark as a decision point rather than a deadline. If new URLs are still climbing at four weeks, keep waiting. If they have been flat for two weeks while old ones fall away, stop waiting and go find the blocker, because more patience will not fix a canonical tag.

Does changing your domain name hurt SEO?

A domain change carried out properly costs you a temporary dip and not a permanent loss. Google supports the move explicitly, provides a tool for it, and describes the resulting fluctuation as normal. The permanent losses come from execution: redirect maps that miss whole sections, redirects to the homepage instead of the matching page, chains that pass through two or three hops, and old domains that get switched off before the move has finished.

One detail causes more damage than the rest, and it is a timing mismatch that nothing in the interface warns you about. The Change of Address tool forwards signals for 180 days. Google separately advises keeping your redirects "for as long as possible, generally at least 1 year". Teams read the 180 day figure as the length of the migration, let the domain registration lapse at six or seven months, and lose the redirects that were still doing the work. Renew the old domain for at least two years at the time you migrate, and treat the redirects as infrastructure rather than a temporary measure.

The tool also has boundaries worth knowing before you plan around it. You must be an owner of both properties in Search Console using the same Google account. It works only on properties at the domain level, so you cannot move a path like example.com/petstore/ with it. It does not move subdomains below the domain you specify, www included. And Google says not to use it at all for an HTTP to HTTPS change.

Website redesign SEO: what breaks when the URLs stay the same

A redesign that keeps every URL feels like the safe option, and in indexing terms it mostly is. The risk moves rather than disappearing. Nobody builds a redirect map, because nothing needs redirecting, so nobody builds any migration process at all, and the launch is treated as a normal deploy. The failures then come from the template, and templates ship sitewide.

The specific things worth checking in the new templates, before launch and again on the live site: the meta robots tag, because staging protections are removed page by page and one template is always forgotten. The canonical tag, because a hardcoded canonical or one pointing at the staging hostname will deindex every page using that template. Whether the primary content is in the served HTML or arrives only after JavaScript executes, since a redesign is the most common moment for that to change. Internal links, because a new navigation often quietly orphans older pages that used to be reachable in two clicks. And your XML sitemap, which many platforms regenerate on deploy and sometimes regenerate empty.

The tell for a template-level problem is its shape in the data. A migration problem hits a section, matching the URL pattern that broke. A redesign problem hits a page type, so every product page falls and every blog post is fine, or the reverse. If a drop follows a template rather than a URL pattern, stop reading the redirect map and go read the rendered HTML of one affected page.

How to check which URLs Google reindexed after the migration

A redirect that returns 301 tells you the server is configured. It says nothing about whether Google has crawled the old URL since you configured it, followed it, accepted the target as canonical, and indexed that target. Every one of those steps can fail independently and none of them are visible in a browser or in a redirect checker.

Search Console will show you this, with two constraints that matter during a migration. The URL Inspection tool answers the question precisely but one URL at a time, and Request Indexing is limited to roughly ten to twelve URLs a day per property, which is not a migration tool. The Page indexing report covers the whole site, but its example lists are capped: Google states that "the list of example URLs in the report is limited to 1,000 items, and isn't guaranteed to show all URLs in a given status, even when less than 1,000 items". On a large migration, the URLs you most need to see are frequently the ones the sample leaves out.

That is the gap Indexing fills. Paste both URL sets, the old and the new, and get index status for every one of them rather than a sample, with the not-indexed reasons written in plain English, and rerun it weekly so you are reading a trend rather than a snapshot. Migrated URLs that are eligible get resubmitted through the official Google Indexing API, IndexNow and your sitemaps. If you want the same check on a routine basis rather than during a launch, that is what our index monitoring is for, and if the question is narrower, checking whether one page is in the index, the single URL check answers it faster.