Website Migration SEO Checklist Template

Free editable Website Migration SEO Checklist Template. Copy, personalize, or download the Word .docx template from UNmiss.

Migrations are where hard-won rankings quietly disappear. The danger is rarely one big mistake. It's the dozens of small ones: a redirect that points to the homepage instead of the matching page, a title tag that got rewritten, a robots.txt rule that survived from staging, a sitemap that never got resubmitted. This checklist forces a disciplined, repeatable process around each risk. Start by benchmarking your current rankings, traffic, and index coverage so you have a baseline to measure recovery against. Keep URLs identical wherever you can; where you can't, map every old URL to its closest new equivalent with a single 301. Preserve titles, meta, headings, content, and internal links. Submit the new XML sitemap, confirm robots.txt isn't blocking, and migrate during a low-traffic window. Work the phases in order and you'll migrate with confidence instead of crossed fingers.

6 ready-to-use variants

Pre-Migration Benchmark & Inventory

Capture a complete baseline of rankings, traffic, and URLs before you change anything, so you can prove recovery later.

Phase 1: Benchmark & Inventory

You cannot measure what you never recorded. Before touching a single URL, freeze a snapshot of how the current site performs and exactly which pages exist. This baseline becomes your reference point for spotting losses after launch.

  • Export current organic rankings for your priority keywords [Date Recorded]
  • Record organic traffic and conversions from analytics for the trailing 3–6 months
  • Note index coverage totals in Search Console (valid, excluded, errors)
  • Run a full crawl of the live site [Crawl Tool] and save the export
  • Build a complete URL inventory with status codes, titles, and meta
  • Capture top backlinked pages so you protect their equivalents
  • Save the current robots.txt, XML sitemap, and structured data

Owner: [Name] & Baseline locked: [Date]. Store every export in one shared folder: you'll compare against it for weeks.

Redirect Mapping (1:1 Old → New)

Build a clean, page-by-page redirect map so every old URL lands on its closest new equivalent with a single 301.

Phase 2: Redirect Mapping

Redirects carry your authority from old URLs to new ones. The goal is a 1:1 map. Each retiring URL points to the single most relevant page on the new site. Sloppy mapping is the most common cause of traffic loss in a migration.

  1. List every old URL from your Phase 1 inventory [Source File]
  2. Match each to its closest new URL: same topic, same intent
  3. Use permanent 301 redirects, not 302s, for moved pages
  4. Avoid redirect chains and loops. Point straight to the final URL
  5. Never bulk-redirect to the homepage; map orphans to the best section page
  6. Decide handling for retired pages with no equivalent [410 or Redirect]
  7. Preserve URL parameters and trailing-slash conventions deliberately

Test the full map on staging before launch. Map reviewed by: [Name]. A complete, chain-free map is the single biggest lever you control.

On-Page Parity

Confirm titles, meta, headings, content, and internal links carry over so search engines see continuity, not a new site.

Phase 3: On-Page Parity

Search engines re-evaluate every page they recrawl. If your titles, headings, and content stay consistent, you signal continuity and protect relevance. Treat parity as the default and improvements as deliberate exceptions, not accidents.

  • Carry over title tags exactly, or improve them intentionally, never drop them
  • Preserve meta descriptions for pages that earn clicks
  • Keep the H1 and heading hierarchy aligned with the old page
  • Match body content, don't quietly trim or thin key pages
  • Update internal links to point at final new URLs, not redirects
  • Re-point navigation, footer, and breadcrumb links
  • Migrate structured data and image alt text [Schema Types]

Spot-check your highest-traffic and highest-converting templates first. Parity QA owner: [Name]. Where you do change copy, log it so you can correlate any ranking shift with the edit.

Technical Setup

Get robots.txt, sitemaps, canonicals, hreflang, and analytics correct on the new site before and at launch.

Phase 4: Technical Setup

The technical layer tells crawlers how to read your new site. One stray staging rule or a missing canonical can undo careful parity work, so verify each item explicitly rather than assuming defaults are safe.

  1. Confirm robots.txt does not block crawling on production [URL]
  2. Remove any noindex tags left over from staging
  3. Generate a clean XML sitemap listing only final, indexable URLs
  4. Set self-referencing canonical tags on every page
  5. Configure hreflang if you serve multiple languages or regions
  6. Verify HTTPS and that HTTP requests redirect to the secure version
  7. Install analytics and Search Console on the new property [GA / GSC ID]

Validate the sitemap and run a fresh crawl of staging to catch errors early. Tech checks signed off by: [Name]. Get this right before launch day, not during it.

Launch-Day Checklist

Execute the cutover in a low-traffic window with a tight sequence so nothing is missed under pressure.

Phase 5: Launch Day

Launch day is execution, not decision-making. Every decision should already be made. Run the cutover during a low-traffic window and follow the sequence so a calm checklist replaces last-minute scrambling.

  1. Schedule the cutover for a low-traffic period [Date / Time]
  2. Deploy the new site and activate all 301 redirects at once
  3. Confirm the production robots.txt allows crawling and has no leftover blocks
  4. Submit the new XML sitemap in Search Console
  5. Spot-check key redirects return 301 → 200, not chains or 404s
  6. Verify analytics is firing and tracking the new URLs
  7. Test forms, search, checkout, and other critical paths

Keep the team on call for a few hours after go-live. Launch lead: [Name] & Time live: [Time]. Resist making content changes the same day: isolate launch from edits.

Post-Launch Monitoring

Watch Search Console, crawl errors, and rankings after launch to catch and fix issues fast.

Phase 6: Post-Launch Monitoring

The migration isn't done at launch: it's done when performance stabilizes. Expect a temporary fluctuation as engines recrawl and reindex, then watch closely so real problems get fixed before they compound.

  • Monitor Search Console daily for coverage and crawl errors
  • Watch for spikes in 404s and fix or redirect them quickly
  • Recrawl the live site to catch broken links and bad redirects
  • Confirm new URLs are getting indexed and old ones dropping out
  • Track rankings and traffic against your Phase 1 baseline
  • Use the Change of Address tool if you moved domains
  • Verify the sitemap is processed, and if you configured hreflang, confirm it has no errors

Log every fix with a date so you can connect actions to recovery. Monitoring owner: [Name] & Review through: [End Date]. Don't panic at early dips: investigate, document, and give recrawling time.

How to use this template

  1. Benchmark first. Before changing anything, export current rankings, organic traffic, conversions, and Search Console index coverage, then save them as your baseline for measuring recovery.
  2. Inventory every URL. Run a full crawl of the live site and build a complete list of URLs with their status codes, titles, and meta so nothing is forgotten in the move.
  3. Keep URLs identical where you can. The safest migration changes as few URLs as possible; only remap the ones that genuinely have to change.
  4. Map redirects 1:1. Point each retiring URL to its single closest equivalent with a 301, avoiding chains, loops, and bulk redirects to the homepage.
  5. Preserve on-page parity. Carry over titles, meta descriptions, headings, and content, and update internal links to point at the final new URLs rather than through redirects.
  6. Lock down the technical setup. Confirm robots.txt isn't blocking, remove staging noindex tags, set self-referencing canonicals, configure hreflang if needed, and submit a clean XML sitemap.
  7. Launch in a low-traffic window. Deploy the site, activate all redirects at once, resubmit the sitemap, and spot-check that key pages return 301 then 200.
  8. Monitor after launch. Check Search Console daily for crawl and coverage errors, fix 404s fast, track rankings against your baseline, and expect a temporary fluctuation before things settle.

Pro tips

  • Don't redirect everything to the homepage. A 301 to an irrelevant page is treated like a soft 404 and passes little value: always map to the closest matching page instead.
  • Eliminate redirect chains. Every extra hop wastes crawl budget and dilutes signals; point old URLs straight at the final destination, not through intermediate redirects.
  • Update internal links to the final URLs. Linking through redirects works but is wasteful; editing nav, body, and footer links to the new URLs keeps your site clean and fast to crawl.
  • Expect a temporary dip and don't overreact. Rankings often wobble while engines recrawl and reindex; investigate genuine errors, but give a correctly executed migration time to settle rather than reversing course.

Frequently asked questions

Will I lose rankings when I migrate my website?

A temporary fluctuation is normal as search engines recrawl and reindex your new URLs. A carefully executed migration, with 1:1 301 redirects, preserved on-page elements, and a resubmitted sitemap, is positioned to recover, while a sloppy one can cause lasting losses. The benchmarking, mapping, and parity steps in this checklist exist specifically to minimize and shorten that dip.

Should I keep my URLs the same when migrating?

Yes, wherever possible. The fewer URLs you change, the less can go wrong, because you avoid the need for redirects and the signal loss that can come with them. Only change URLs when the migration genuinely requires it (such as a new domain or a platform that enforces a different structure) and map every changed URL carefully to its new equivalent.

What's the right way to set up redirects for a migration?

Use permanent 301 redirects mapped 1:1, so each old URL points to the single closest equivalent on the new site. Avoid redirect chains and loops by pointing straight to the final URL, and never bulk-redirect unrelated pages to the homepage: search engines may treat those as soft 404s and pass little or no value.

Do I need to resubmit my sitemap and check robots.txt after migrating?

Yes. Generate a fresh XML sitemap containing only your final, indexable URLs and submit it in Search Console to speed up discovery. Just as importantly, confirm your production robots.txt isn't blocking crawling and that no noindex tags survived from staging. A single leftover rule can keep your new site out of the index.

When is the best time to launch a migration?

Schedule the cutover during a low-traffic window so any issues affect the fewest users and you have room to react. Activate all redirects at once, resubmit your sitemap, and keep the team on call for a few hours afterward. Avoid making unrelated content changes on the same day so you can isolate the migration's effect when monitoring.

What should I monitor after the migration goes live?

Watch Google Search Console daily for crawl errors and coverage issues, fix or redirect any spike in 404s quickly, and recrawl the live site to catch broken links and bad redirects. Track rankings and traffic against the baseline you recorded before migrating, and confirm new URLs are being indexed while old ones drop out. Expect a temporary fluctuation before things stabilize.