Site migration SEO checklist. The 70-step playbook we follow every time.

What counts as a site migration

A site migration is any change to your website significant enough that Google has to re-learn parts of what it already knew. The textbook examples are easy: a new domain, a CMS swap, a redesign that changes URL patterns, an HTTP-to-HTTPS upgrade. The less obvious examples catch people out: a navigation overhaul that changes the internal-link graph, a hosting move that changes IP addresses and response times, a theme update that swaps the templating layer, a major content prune that retires hundreds of URLs at once.

If any of the following are true, you are running a migration and need this checklist: URLs are changing, the underlying platform is changing, the domain is changing, the protocol or subdomain is changing, large sections of content are being retired or consolidated, or the internal-linking structure is being significantly altered. Anything else is a routine update.

Two distinctions matter before we get into the steps. First, a migration is a process, not an event. The launch is the visible moment; the work runs from four weeks before launch to 90 days after. Skipping the pre-work or the post-launch monitoring is how migrations fail in slow motion. Second, the SEO checklist runs in parallel with the build checklist, not after it. Most agencies do the build, launch it, then ask SEO to "look at" what happened. By then, the redirect map is missing, the meta tags are not in the new template, and the recovery is a six-month project that should have been a six-week one.

Migrations also vary in risk. An HTTPS upgrade with no URL changes is low risk if the redirects are correct. A simultaneous domain change, CMS swap and redesign is the highest-risk move in SEO and we strongly discourage doing all three at once. Split the project into phases if you can. Migrate the platform first, redesign next quarter, change the domain six months later. Sequential migrations let you isolate which change caused which dip. Simultaneous migrations leave you guessing.

Why so many migrations bleed traffic

Three reasons. The same three, every time we audit a botched migration.

First, the redirect map. Either it does not exist, or every old URL points at the homepage, or the redirects are 302 (temporary) instead of 301 (permanent), or the redirect chains go three or four hops deep. Every one of those is a traffic loss. A missing 301 throws away the authority a page accumulated over years. A homepage redirect tells Google the old page does not exist and the homepage is the closest equivalent, which is rarely true. A 302 tells Google to keep the old URL in the index. A redirect chain leaks authority at every hop.

Second, the meta tags and signals do not survive the template change. The old site had a canonical generator that worked, hreflang declarations on the country variants, schema markup on the product pages and a sitemap that excluded the parameter URLs. The new template was built fresh, the developer assumed those signals were just CSS, and the live site launches with a homepage canonical on every page, no hreflang, no schema and a sitemap full of staging URLs. We audit migrated sites where every single technical signal was lost on launch and the team had no idea until the rankings came off three weeks later.

Third, nobody baselined the old site. Without a baseline, the team cannot tell whether the migration worked. Traffic is down, but was traffic already down? Rankings dropped, but for which keywords specifically? Conversions are off, but is that the migration or seasonality? A baseline taken in the week before launch removes the guessing. Without it, post-launch is a debate instead of a diagnosis.

One political reason worth naming. The agency that built the new site is rarely the agency that loses the most when it bleeds traffic. The client does. So the build agency ships the new site, ticks the project off, and the SEO conversation starts two months later when somebody noticed the leads stopped. The checklist below is what stops that handoff failing. It belongs to whoever cares about the post-launch result, which is usually you, not the build team.

The nine-phase 70-step process

The checklist runs nine phases. Each phase has its own checks and its own owner. Skipping phases is how migrations fail. Running them in the wrong order is how teams waste a fortnight on the wrong work.

Phase 1. Baseline the old site (week minus 4)

Snapshot everything you will want to compare later. Rankings on your top 200 commercial keywords, daily organic sessions for the last 12 months, conversion volume and rate by landing page, indexed page count from Search Console, total backlink count and root domains from Ahrefs or Semrush, and Core Web Vitals for your top 10 templates. Save it all in a spreadsheet with the date stamped on it. This baseline is non-negotiable. Without it, every post-launch conversation is opinion.

Phase 2. Crawl and inventory the old site (week minus 4)

Run a full Screaming Frog crawl. Export every URL with its status code, indexability, canonical tag, title, meta description, H1, word count, internal-link count and external-link count. This list is the source of truth for what you have to migrate. Cross-reference with the sitemap and with Search Console's Pages report to catch URLs Google knows about that the crawler missed. For sites above 10,000 URLs, pull server logs and add any URL Googlebot has hit in the last 90 days that is not already on the list. The combined list goes into a single spreadsheet, sorted by traffic and by inbound links.

Phase 3. Build the URL redirect map (week minus 3)

Every old URL gets a line. Each line maps to its new equivalent on the new site. Where the new site has a direct one-to-one match (an old product page maps to a new product page), the mapping is mechanical. Where the new site has consolidated several old URLs into one, several lines map to the same destination. Where an old URL has no equivalent at all, decide: redirect to the closest parent category, or let it 404 if it never earned any traffic anyway. Never redirect to the homepage by default. That is the lazy choice and it costs you.

The map gets two extra columns: the old URL's monthly organic traffic and the old URL's backlink count. Sort by either descending. The top 200 rows are the ones to triple-check by hand. The bottom 2,000 can be checked by spot sampling. Hand the final map to the developer for implementation in the new server config or CDN rules.

Phase 4. QA the staging build (week minus 2 to minus 1)

The staging environment is where most of the actual SEO work happens. Crawl staging behind authentication using Screaming Frog with custom HTTP headers or a username and password. Then check every signal:

1. robots.txt. Confirm staging blocks all crawlers (Disallow: /), and that the production-ready robots.txt is staged separately and ready to swap in at launch. Full chapter: robots.txt and meta robots.
2. Meta robots and X-Robots-Tag headers. Staging should be noindex globally. Production needs noindex removed from every page that should be indexed and kept on pages that should not (thank-you pages, internal admin, test templates).
3. Canonical tags. Every page self-references unless deliberately pointing elsewhere. No canonicals pointing to staging URLs. Full guide: canonical tags explained.
4. Hreflang annotations. If you serve multiple countries or languages, every variant needs return tags pointing to every other variant. Hreflang fails silently and at scale. Full chapter: hreflang for international SEO.
5. Schema markup. Every page that had it before should still have it. Run a sample of templates through the Schema.org validator. Structured data is one of the most commonly lost signals on a template change.
6. Title and meta descriptions. Every old title and meta description should map across to the new page. If the new CMS strips them or replaces them with template defaults, that is a finding.
7. Internal linking. Compare the internal-link graph on staging to the old site. Major navigation changes that drop links from a top-level template can quietly orphan dozens of pages. Cross-reference with internal linking strategy.
8. JavaScript rendering. If the new build uses React, Vue, Next or similar, run the rendering checks from the JavaScript SEO chapter. A migration to a client-side rendered build with no server-side rendering is the single highest-risk pattern we see.

Nothing ships to production until every check on this list is green. We have walked away from launches on the morning of cutover because the staging robots.txt was still on production. That was the right call.

Phase 5. Prepare launch-day assets (week minus 1)

Six artefacts have to be ready: the updated XML sitemap with only canonical production URLs; the production robots.txt allowing crawl with the production sitemap declared; the redirect rules in the format your stack expects (Nginx config, Apache .htaccess, Cloudflare Page Rules, CDN edge functions); the GA4 and Search Console verification tags in the new template; a one-page incident response plan with named contacts and decision triggers; and the rollback procedure with a specific go/no-go threshold (typically more than 50 percent organic dropoff over the first 24 hours triggers rollback).

Phase 6. Execute the cutover (launch day)

Launch on a Tuesday or Wednesday morning. Not a Friday, not a Monday, not late afternoon. You need the team available for 24 to 48 hours of monitoring with daylight on both sides.

Sequence: confirm staging is final, swap production DNS or deploy the build, push the redirect rules live, swap the robots.txt, submit the new sitemap in Search Console, then verify the first 100 URLs by hand. Each verified URL should return 200 if it is a new page, 301 if it is an old URL mapped to a new one. Anything else is an incident.

Phase 7. Day-one verification (first 24 hours)

Within an hour of cutover, run a Screaming Frog crawl of the live production site. Compare the URL list to the redirect map. Any old URL returning 200, 404, or 302 instead of 301 is a defect that needs fixing today, not next week. Check Search Console's URL Inspection on five top templates and confirm the new pages can be rendered by Google.

For the rest of the first 24 hours: hourly checks of GA4 real-time data against the previous-week baseline; hourly checks of the most important transactional templates for 200 status codes; spot checks of the redirect chain depth using a tool like httpstatus.io. Any anomaly that crosses the rollback threshold triggers the rollback. Better to roll back, regroup and re-launch on Thursday than to leave a broken site live over a long weekend.

Phase 8. 30-day stabilisation watch (weeks one to four)

Daily checks for the first week. Weekly checks for the next three. The metrics that matter: indexed page count in Search Console, organic sessions by template, ranking on your top 50 commercial keywords, Core Web Vitals from PageSpeed Insights field data. Rankings will wobble in the first two weeks; that is normal as Google reprocesses the redirects. Sessions will dip by 10 to 25 percent in the first ten days; that is also normal.

What is not normal: indexed page count down by more than 30 percent at the 14-day mark, sessions still 30 percent below baseline at the 21-day mark, or any single high-value template (top-converting landing pages) showing zero impressions in Search Console. Those are signals for deeper diagnostics.

Phase 9. 90-day audit and sign-off

Re-baseline at 90 days. Compare every metric from phase one to the new values. Document what worked, what surprised us and what we would do differently next time. Lock the post-mortem so future migrations get the institutional memory. Most migrations are signed off here. The 5 percent that still show issues at 90 days get rolled into a remediation engagement.

That is the playbook. Nine phases, 70 individual checks, six weeks of work end to end on an average site. Twelve weeks on a large e-commerce or directory site. The whole thing lives in a single spreadsheet, the checklist itself is one tab, the redirect map is another, the baseline is a third. Nothing fancy. Just discipline.

Common migration mistakes

If a migration playbook you have been handed does not look like the "good" column, push back before launch. After launch, it is remediation work.

Tools and the checklist itself

The minimum kit:

1. Google Search Console. Free. The Coverage, Pages and Sitemaps reports tell you what the index thinks of the new site. Verify both the old and new properties before launch and keep both live for 90 days.
2. Screaming Frog SEO Spider. Crawl the old site, the staging build and the live new site. Three separate crawls, archived for comparison.
3. A redirect map spreadsheet. The single most important artefact in the migration. Every old URL, its destination, its old traffic, its old backlink count.
4. GA4 with goals configured before launch. Real-time data is your first signal that something is wrong on launch day.
5. Rank tracking. AccuRanker, Ahrefs Rank Tracker or similar. Daily tracking on your top 200 commercial keywords from week minus 4 through to week 12 post-launch.
6. Our free SEO audit tool. Useful for spot-checking individual templates on launch day. Lighthouse scores, indexability flags, schema validation in one place.

For larger or higher-stakes migrations: PageSpeed Insights API for automated CWV monitoring on top templates; httpstatus.io or similar for bulk redirect verification; and log file analysis on day one and day 30 to confirm Googlebot's behaviour matches the redirect map. The full process for that is in log file analysis for SEO.

If you would rather have us run the migration with you, that is the website audit service for the planning phase, the SEO retainer for the ongoing monitoring, and speed optimisation if the migration is also touching Core Web Vitals.

Perth and WA context

We have run migration support on a meaningful number of WA sites and the patterns differ by sector.

Perth metro service businesses (trades, healthcare, professional services) migrating to a new WordPress build or to a platform like Webflow or Squarespace tend to have the same failure modes every time. The old site's location-page set canonicalises wrong on the new platform. The schema for the local business loses the multi-suburb declarations. The new theme's URL structure for blog posts changes from /blog/post-name to /news/post-name without redirects. None of those are exotic; all of them happen on most rebuilds. The Perth metro SEO page and Local SEO Perth both have notes on the patterns we see.

South West regional businesses, particularly across Bunbury and Busselton, often migrate to a new build constructed by a Perth metro agency who never localised the technical signals. The schema reverts to a generic Perth address. The contact-page hours forget local opening times. The hreflang or geo-targeting in Search Console does not get set up for the new property. Easy fixes if someone runs the migration checklist properly; expensive if nobody does.

Mining-services catalogues based around Karratha, Port Hedland and Kalgoorlie tend to be the highest-stakes migrations. Five-figure URL counts, complex product variant structures, faceted navigation with thousands of parameter combinations. We routinely see migrations of these sites lose 50 to 70 percent of organic traffic because the redirect map was hand-coded for the top 100 products and everything below that got 404s. The mining SEO industry page covers the broader picture.

Real estate and property platforms have a particular migration pattern around listing churn. Sold listings on the old platform get archived. The new platform either keeps them at different URLs or deletes them entirely. Either way, the redirect map has to handle the historical URLs with the same care as the active ones. The real estate SEO industry page walks through the pattern.

E-commerce on Shopify and WooCommerce, particularly the Mandurah and Rockingham retailers on our books, has its own migration shape. Variant URL patterns differ between platforms. The collection-page filter URLs differ. The default sitemap behaviour differs. A WooCommerce-to-Shopify migration without a thorough redirect map at the variant level loses traffic in places nobody thought to check. The e-commerce SEO industry page goes deeper.

One Perth pattern that crosses every sector. The site was built by an agency that did not run an SEO checklist. The client found out three months later when the leads dried up. By then, the redirects are partially in place, the old URLs are mostly 404ing, and the team is arguing about whose fault it is. Remediation works, but it takes six months of careful re-work that should have been six weeks of careful planning. The checklist above is what stops that.

Related guides

• Back to the Technical SEO pillar for the full 12-chapter index.
• The technical SEO audit. The audit you should run before launch, and again on day one of the new site.
• 301 vs 302 redirects. The single most important detail in the redirect map.
• Canonical tags explained. The signal that fails first on most template changes.
• Robots.txt and meta robots. The artefact that has to swap from staging to production at cutover.
• XML sitemaps explained. The new sitemap is one of six launch-day assets.
• Hreflang for international SEO. The signal most likely to be silently lost on a multi-country migration.
• JavaScript SEO essentials. Required reading if the new build is React, Vue, Next or Nuxt.
• Log file analysis for SEO. The day-one check that confirms Googlebot is finding the new URLs.
• HTTPS and SSL for SEO. The migration sub-case for protocol upgrades.
• Crawling, indexing and ranking. The conceptual model the migration is protecting.
• Internal linking strategy. Where the navigation-change diagnostics go to get fixed.