What a website migration checklist contains

A migration checklist exists because a website move has more moving parts than an ordinary launch. The parts most often missed are not the visible ones. They are the invisible infrastructure — redirects, tracking, form destinations, email. Nobody notices these are broken until a customer complains, or a report reveals it weeks later.

Before anything changes: an inventory of URLs and a content audit for the migration checklist

• Full inventory of existing URLs, pulled from a crawl and from Search Console. Not just the site’s own navigation menu — many indexed pages are not linked from the current navigation at all.
• Analytics and Search Console access confirmed and continuous. The accounts measuring the site should not depend on infrastructure that is about to be replaced.
• A content and asset audit, per what to keep from the old site. This identifies what genuinely needs to migrate versus what can be retired.
• A complete redirect map drafted, per redesigning without losing rankings. It should cover every URL identified in the inventory.

During the build, before launch: redirects, forms and tracking

• Forms tested end to end on the new site. Confirm submissions actually reach the intended destination, not just that the form visually renders.
• Tracking code (analytics, any conversion tracking) installed and verified firing correctly on the new site before launch — not discovered missing afterward.
• 301 redirects implemented and individually spot-checked. Confirm a sample of old URLs actually resolve to their correct new equivalents.
• A staging environment reviewed by someone outside the build team. This catches issues a person too close to the work may no longer notice.

At launch: DNS, domain cutover and the XML sitemap

• DNS and hosting cutover sequenced to avoid downtime, per moving hosts without downtime where a host change is also involved.
• XML sitemap for the new site submitted in Search Console immediately.
• Old site’s robots.txt and any staging noindex tags removed or corrected, confirming the live site is actually crawlable — a staging noindex tag accidentally carried into production is a common and serious launch error.

In the days and weeks after launch: checking old URLs and backlinks

• Search Console coverage and performance reports monitored closely, watching specifically for a spike in reported crawl errors or 404s that would indicate a redirect gap.
• A sample of high-value old URLs manually checked to confirm they redirect correctly, rather than relying solely on the automated report.
• Analytics data compared against the pre-migration baseline, checking that traffic and conversion tracking are both reporting sensibly on the new site.
• Email deliverability confirmed, particularly where a domain or hosting change was also involved.

Why the staging noindex mistake happens so often, and what it costs in SEO and crawl visibility

Most staging environments are deliberately configured to block search engines. A site-wide noindex tag or a robots.txt disallow rule is applied automatically. This keeps a work-in-progress site from being indexed alongside the real one. The common failure: this setting is often controlled by a single environment flag or configuration file. That same configuration can carry across to production during launch, without being explicitly flipped. The live site then inherits the staging site’s instruction to stay out of search results. It still looks and functions correctly to a human visitor. So this failure is invisible to ordinary testing. It is only caught by specifically checking the live site’s actual robots.txt and page-level meta tags after launch. Or by noticing weeks later that the site has quietly disappeared from search entirely. That is why it belongs on the checklist as its own explicit item, not assumed to be covered by general testing.

Third-party integrations are a migration risk that needs its own verification step

A payment gateway, a booking widget, a live chat tool, an embedded map or a marketing pixel is often locked to the specific domain or hosting environment it is authorised to run on. A domain, hosting or platform change can silently break one of these integrations. The surrounding page can still render correctly. A payment form can look fine but fail at the final step. A chat widget can fail to load. A map can show an error instead of a location. Each third-party integration in use needs to be checked specifically after a migration. Do not assume it works just because the rest of the page does.

A post-migration rollback plan, decided before launch rather than invented during a problem

Decide, in advance, exactly what a rollback would involve. This might mean reverting DNS to the old host. Or reactivating the old site kept on standby, per running the old and new sites in parallel. Work out how long that reversal would realistically take. Do this before launch, not under pressure if something goes wrong on launch day. A migration checklist that stops at “how to launch” is missing its own safety net. It needs an equally clear answer for “how to reverse this if needed.”

A one-page website migration summary

Phase	Key items
Before	URL inventory, content audit, redirect map drafted, analytics access confirmed
Build	Forms tested, tracking verified, redirects spot-checked, external review
Launch	DNS cutover sequenced, sitemap submitted, robots.txt and noindex checked
After	Search Console monitored, spot-checks on redirects, traffic compared to baseline, email confirmed

What to do next: turning this into a repeatable checklist for future migrations

Turn this into a shared, dated checklist with a named owner for each item before a migration project begins. A checklist nobody is specifically accountable for tends to have its gaps discovered by a customer rather than by the team. The project brief generator is a practical starting point for capturing this scope in writing before a supplier quotes against it.