Skip to content

The SEO Checklist to Run Before You Migrate Anything

Eight things to capture and verify before a website migration starts, because the data you fail to record now is the ranking you cannot recover later.

Published June 30, 2026

3 min read

PortMySite

Almost everything that goes wrong in a migration goes wrong because of something that was not written down beforehand. Once the old site is gone, its data is gone with it. This is the capture-everything pass to run before anyone builds anything.

1. Crawl the entire live site

Run a crawler (Screaming Frog's free tier covers 500 URLs) against the live site and save the full export: every URL, status code, title, meta description, H1 and word count.

This file is the migration's source of truth. It is the complete list of what exists, including the pages everyone forgot about, which are precisely the ones that get lost.

2. Export Search Console data

Performance report → export by page, longest date range available. Two things this gives you:

  • Priority. The pages that actually earn impressions and clicks get first-class treatment in the redirect map. A migration is triage; this is the triage list.
  • A baseline. In six weeks, when you are asking "did we lose anything?", this export is the only honest answer to "compared to what?"

Export the query data too. Knowing which searches each page ranks for tells you what its replacement must keep doing.

3. Record every ranking-relevant element

For your top pages (from step 2), capture what makes them rank: title tags, meta descriptions, H1s and heading structure, image alt text, internal links pointing at them, and any structured data. A crawl catches most of this; screenshot anything unusual.

Rebuilt pages should reproduce these deliberately, not approximately. "We rewrote the titles while we were at it" is a second migration hiding inside the first, do not change content and addresses in the same move if rankings matter.

Pull your most-linked pages from Search Console's Links report (or Ahrefs/Moz if you have them). Pages with external links pointing at them carry equity you cannot recreate, a 404 on a well-linked page burns years of accumulated authority.

Every URL on this list must have a specific, relevant redirect destination. Not the homepage. If a linked page has no equivalent on the new site, build one or redirect to the closest genuinely related page.

5. Draft the redirect map now, not at launch

The old-URL column comes from step 1. Fill in the new-URL column as the new site's structure is decided, the map should evolve with the build, not be reverse-engineered the night before cutover.

Rules that prevent the classic failures: every URL has a destination, destinations are equivalents rather than the homepage, no chains, 301s not 302s.

6. Check the staging site is invisible, and will not stay that way

Two opposite failures live here:

  • The staging site gets indexed during the build, splitting your content across two indexed copies. Staging should carry noindex or sit behind authentication.
  • The noindex ships to production at launch. This is the single most catastrophic migration error, traffic does not dip, it collapses.

Put "check robots.txt and page-source noindex on the live site" in the launch-hour checklist, assigned to a named person. Within the first hour, verify: robots.txt allows crawling, page source contains no noindex, and the sitemap URL resolves.

7. Screenshot what cannot be exported

Analytics dashboards, Search Console reports, form submission history, app configurations, anything living in the old platform's admin. When the subscription ends, so does your access. Five minutes of screenshots now prevents "what were our conversion numbers last spring?" from becoming unanswerable.

8. Agree the rollback plan

Decide, in advance and in writing: if something is badly wrong after cutover, what happens? Usually the answer is simple. DNS points back at the old site, which is why you keep the old subscription active through the transition. But "we can go back within an hour" is only true if nobody has cancelled anything prematurely and DNS TTLs were lowered before the switch.

A rollback plan you never use costs nothing. Needing one you do not have costs everything.

The short version

Crawl everything, export Search Console, record what makes pages rank, list your backlinked URLs, build the redirect map alongside the build, guard against both indexing failures, screenshot the un-exportable, and write down the rollback plan. None of this is difficult, it is just unforgiving of being skipped, because every item protects something that cannot be recovered after the fact.

Doing this yourself?

Or hand it to people who do it weekly.

Fixed price, 7-day delivery, full 301 redirect map, no downtime. Send the URL and get a real quote back within one business day.

Keep reading