Website migration SEO checklist: before, during, and after launch

Before launch: save a baseline you can compare

Export the source URL inventory, sitemap, important search landing pages, and analytics landing-page results. Record the dates and metric definitions. Search clicks and analytics visits are different measurements; compare each with its own history rather than expecting them to match.

Mark pages that generate enquiries, revenue, branded visits, or useful referral traffic. Include PDFs and old articles that still receive visits. A page does not become expendable merely because it is absent from the navigation or looks dated.

Save current titles, descriptions, headings, canonicals, robots directives, structured data, and key internal links for the important pages. Record search-verification methods and tracking identifiers so you can confirm they remain in place after the move.

• Inspect a source sitemap
• Review page metadata

Before launch: map URLs before redesign decisions drift

For every source URL, choose keep, move, merge, or retire. Assign a relevant destination where one exists. Record the expected status, the final URL, and a named tester. Do this before changing navigation and slugs so design decisions do not silently erase valuable routes.

Google recommends mapping old URLs to relevant new ones and avoiding mass redirects to an unrelated homepage. It also advises retaining redirects for at least a year. Read its site-move guidance for the particular change you are making; a hosting change without URL changes is a different case.

Primary documentation: Google: site moves with URL changes · Google: hosting changes without URL changes

Before launch: review the rendered destination

Review the page a browser receives, not only the editor's settings. Check the visible title and main heading, metadata, canonical, image alt text, links, and structured data. Check that staged URLs have not leaked into canonical tags, navigation, or downloadable assets.

Protect the staging environment appropriately. A robots.txt block and a noindex directive do different jobs; a crawler blocked from the page cannot read its noindex. Keep any actual private content behind access controls rather than relying on search directives for privacy.

Prepare the production configuration separately and verify that the intended public pages will be indexable at cutover. Test narrow-screen navigation and forms, including validation and confirmation states. A redesigned page that users cannot operate is not ready just because its metadata is complete.

• Inspect robots.txt

At launch: test redirects where traffic really lands

A redirect configured only in the old CMS does nothing once requests stop reaching that CMS. Identify the destination host or routing layer responsible for each redirect and test it under the production hostname. Confirm root/www and HTTP/HTTPS behavior as well as path changes.

For a mapped route, record the initial response, redirect target, final response, and final canonical. Avoid loops and unnecessary chains. Update your own internal links to the final destination so visitors do not depend on redirects for ordinary navigation.

For pages that keep the same URL, verify that the new server returns the intended content with a successful response. Do not add a redirect simply because the builder changed. For removed pages, verify the approved retirement behavior rather than silently serving an unrelated page.

• Check a redirect chain
• Find broken internal links

At launch: verify the business path and discovery signals

From a fresh browser session, open a high-value landing page, follow its CTA, submit a clearly labeled test enquiry, and verify receipt. Check the analytics event without counting duplicate trackers. Repeat the critical flow on a phone-sized viewport.

Verify the live sitemap contains the intended canonical, indexable URLs rather than staging addresses or redirects. Check that search-property verification still works. Submit the appropriate sitemap through the search engines' tools when ready; submission requests discovery, not guaranteed indexing.

Preserve email-related DNS records and test the new HTTPS certificate. Keep a log of the launch time, DNS changes, content changes, and known exceptions. That timestamp is essential when comparing analytics or investigating a client report later.

After launch: distinguish tracking defects from search changes

Use a daily operational check immediately after cutover, then a recurring review suited to the site's size and traffic. Watch production errors, lead delivery, landing-page traffic, and search indexing. Compare equivalent periods and allow for each reporting system's freshness and ordinary weekday variation.

When a metric changes, investigate the affected URL first. Does it return the expected status? Is its content intact? Does its canonical point to production? Can a visitor complete the form? Is the tracking request present? Work through observable causes before attributing everything to rankings.

Google notes that search visibility can fluctuate during a move while pages are reprocessed. That is not a reason to ignore broken pages, and a sitemap submission is not a recovery guarantee. Escalate verified technical defects promptly while evaluating search changes over an appropriate reporting window.

Primary documentation: Google: what to expect during a site move

Closeout: keep the map and the recovery record

Retain the source inventory, final redirect map, test evidence, and approved content changes. Give the client a clear owner for future redirects and important page updates. If a third party manages routing, document that responsibility before the project closes.

Retire source hosting only after the agreed recovery window and dependency checks. Keep required redirects running on the appropriate system, preserve archives according to the agreed retention policy, and make sure no shared account cancellation affects another client.

• Coordinate the wider agency rollout