SEO Website Migration Checklist: Pre, Launch & Post-Launch

What Counts as an SEO Migration (and Why the Checklist Format Matters)

A site migration is any change that alters URLs, hosting, or structure at scale: a domain switch, a CMS replatform, a URL restructure, an HTTP-to-HTTPS move, a subdomain consolidation, or a full redesign. Any of these can reset how Google understands your site if handled loosely. This piece skips the "why rankings drop" theory — covered in full in our SEO site migration checklist pillar — and gives you the literal sequence to run, phase by phase.

Pre-Launch Checklist: Before You Touch the Live Site

Everything here happens before a single live URL changes. This is where most ranking losses are actually prevented, not fixed later.

• Benchmark current performance. Export current rankings, organic traffic by landing page, and total indexed page count from Google Search Console for a "before" snapshot.
• Crawl and export the full URL list. Crawl the live site to capture every indexable URL, not just what's in your sitemap — orphaned pages and old campaign URLs still carry equity.
• Build a 1:1 redirect map. Every old URL should map to one clear new destination. Avoid mapping everything to the homepage; that's the single most common cause of post-migration traffic collapse.
• Audit and preserve title tags, meta descriptions, and H1s. Pull these into a spreadsheet before the rebuild so nothing gets regenerated by a new CMS template.
• Stage the new site behind noindex and password/staging protection. It needs to be crawlable by your team but invisible to Google until go-live.
• Test redirects in staging. Confirm the redirect map resolves correctly before it touches production — a broken map found on launch day is far more expensive to fix.

This is also the moment to run a full technical crawl comparison between old and new site structures; a dedicated site audit tool will catch template-level issues — missing canonicals, duplicate H1s, broken internal links — before they go live at scale. Pre-launch is where the pre launch SEO checklist and url mapping migration work happen together; skipping either one undermines the other.

Launch Day Checklist: The Cutover Window

Launch day has a strict order of operations. Doing these out of sequence — or skipping verification steps — is what turns a planned migration into an emergency.

1. Remove noindex tags and staging blocks from the new live environment. Confirm this across every template, not just the homepage.
2. Activate server-side 301 redirects for the entire redirect map. Client-side or meta-refresh redirects don't reliably pass ranking signals and shouldn't be your primary method.
3. Update canonical tags so every page canonicalizes to its new live URL, not a staging domain or an old path. Canonical mismatches are a quiet, frequent cause of indexing delays — see common canonical tag failures that basic crawls tend to miss.
4. Generate and submit the new XML sitemap in Google Search Console, reflecting only live, indexable new URLs.
5. Verify robots.txt isn't blocking crawlers. A staging robots.txt file accidentally pushed to production will disallow the entire site — check this immediately after deploy.
6. Spot-check redirects with a live crawl. Crawl a sample of high-value old URLs post-launch to confirm each returns a 301 to the correct destination, not a 302, 404, or redirect chain.
7. Submit a Change of Address in Search Console if the domain changed, to tell Google to transfer signals from the old property to the new one.

Google's own Site Moves and Migrations guidance covers the redirect and canonical testing expectations behind steps 2–4, and is worth bookmarking for the cutover window. This 301 redirects migration sequence — noindex removal, redirects, canonicals, sitemap, robots.txt, spot-check, Change of Address — is the exact launch day SEO checklist order; treat it as non-negotiable.

Post-Launch Monitoring Checklist: First 30–90 Days

Rankings and indexing don't stabilize instantly. This is where post launch SEO monitoring earns its place as a distinct phase, not an afterthought.

Daily (first 1–2 weeks):

• Check indexed page count in GSC Coverage — a widening gap between submitted and indexed pages signals a crawl or quality problem.
• Watch your rank tracker for volatility on money pages specifically, not just average position. A rank tracker built for this should let you segment by URL group so you catch problems on revenue pages before they show up in aggregate traffic reports.
• Scan for 404s and redirect chains appearing in crawl reports or GSC.

Weekly (through week 12):

• Review server logs to confirm Googlebot is actually crawling the new URL structure at expected rates — log file analysis will show whether crawl budget is going where it should, or getting wasted on redirect chains and dead URLs.
• Keep every redirect live. Google recommends maintaining 301s for at least 180 days after a move, per the Change of Address tool guidance — don't decommission redirects early just because traffic looks stable.
• Audit your backlink profile for referring domains still pointing at old URLs, and reach out to update the highest-value ones where feasible.
• Track rank tracking after migration trends weekly and log any sustained drop (not single-day noise) that correlates with a specific URL cluster — that's usually a redirect or canonical issue, not a ranking penalty.

If crawl errors after migration pile up — thin content flags, orphaned pages, slow server response on new templates — prioritize fixes using a structured approach rather than patching randomly; see how to fix technical SEO issues by priority.

Quick-Reference Table: Steps by Migration Type

Not every migration needs every checklist item at full intensity. Use this table to know where to focus.

Checklist Item	Domain Change	Platform/CMS Change	URL Structure Change	HTTPS/Subdomain Move
1:1 redirect map	Critical	Critical	Critical	Critical
Change of Address submission	Required	Not needed	Not needed	Required (if subdomain/host changes)
Title/meta/H1 preservation audit	High priority	Critical (template resets)	Medium	Low
Canonical tag verification	High priority	Critical	Critical	Critical
robots.txt check	Critical	Critical	Medium	Critical
Server log crawl monitoring	Critical	High priority	High priority	Medium
Backlink profile review	Critical	Medium	Low	Low

A domain migration SEO checklist leans hardest on Change of Address and backlink cleanup, since external signals need to transfer to a new property entirely. Platform migration SEO work is dominated by template-level regressions — meta tags, canonicals, and internal linking often reset silently during a CMS switch. A url structure change SEO effort is almost entirely about redirect mapping and canonical accuracy, since the domain and content usually stay the same. HTTPS or subdomain moves are comparatively low-risk but still require the full robots.txt and canonical checks, since a misconfigured HTTPS rollout can inadvertently create duplicate HTTP/HTTPS versions competing for the same rankings.

Where Manual Migration Tracking Breaks Down

The checklist above is straightforward on paper. In practice, executing it means logging into a crawler for the redirect audit, a separate rank tracker for volatility, Search Console for coverage and Change of Address, and raw server logs for crawl behavior — often across multiple tabs, exports, and spreadsheets, during the exact window when a missed regression is most costly. A redirect that silently breaks on day 4, or a canonical that points at the wrong domain, can sit undetected for a week if nobody's watching all four sources at once.

This is the gap Rankevra is built for. Instead of stitching together a separate crawler, a separate migration monitoring tool for rank volatility, and manual GSC checks, Rankevra runs the audit, tracks rankings before and after cutover, and flags crawl and indexing anomalies inside one workflow — so a missed redirect or a canonical mismatch surfaces as an alert, not a quarterly traffic report surprise. Teams that automate audit work during a migration window catch these issues in hours, not weeks. If you're planning a migration in the next quarter, running Rankevra alongside your launch plan is the fastest way to turn this checklist into something monitored automatically rather than checked manually.

Frequently Asked Questions

How long does it take to recover rankings after a website migration?

Most well-executed migrations see rankings stabilize within 2 to 8 weeks, though full recovery can take up to 90 days depending on site size and how much Google needs to re-crawl. Domain changes and large URL restructures tend to take longer than platform swaps that keep URLs intact. Consistent redirect maintenance and clean canonical tags shorten this window significantly.

Do I need to keep 301 redirects forever after a migration?

Google recommends keeping 301 redirects live for at least 180 days after a migration, per its official Change of Address guidance. Many experienced teams keep them active indefinitely for high-value or frequently linked pages, since removing them too early can strand backlink equity and confuse returning visitors.

What's the biggest mistake that causes traffic loss during a migration?

Mapping old URLs to the homepage instead of building a true 1:1 redirect map is the most common and costly mistake. It breaks the direct relevance signal Google relies on to transfer rankings, effectively resetting every affected page instead of preserving its equity.

Should I migrate everything at once or in stages?

Staged migrations are generally lower-risk for large sites, since they let you validate redirects and monitor indexing on a subset of URLs before rolling out site-wide. Smaller sites can often migrate in a single cutover safely, provided the pre-launch redirect map and canonical setup are fully tested in staging first.

How do I know if Google has fully re-indexed my new site?

Check the Coverage report in Google Search Console and compare indexed page counts on the new domain or URL structure against your pre-migration benchmark. Once the indexed count stabilizes near your submitted sitemap total and old URLs stop appearing in search results, re-indexing is substantially complete.

Does changing from HTTP to HTTPS count as a migration that needs this checklist?

Yes, an HTTP-to-HTTPS switch is a migration and needs redirect mapping, canonical verification, and a Change of Address submission if the protocol change is registered as a separate property in Search Console. It's lower-risk than a domain or URL structure change, but skipping the checklist still risks duplicate content issues between HTTP and HTTPS versions.