A website migration changes relationships as well as pages. Old addresses need appropriate destinations, internal links need to follow the new structure, and important user tasks need to remain usable. A successful homepage check does not establish that the rest of the move worked.
Build a watchlist before launch, organize checks around the expected old-to-new mapping, and keep unresolved exceptions visible after release. This gives the team concrete evidence to investigate rather than relying on a general impression that the new site looks right.
Build an old-to-new map before deployment
Start with an inventory of important existing URLs and their intended outcomes. Some will retain their address, some will redirect to a relevant replacement, and some will be deliberately retired. Record the reason for each category.
Include URLs from more than the main navigation. Useful inputs include the current sitemap, content inventory, known campaign links, documentation references, and the pages that support important user journeys. Reconcile disagreements using the crawl coverage method.
Google's guidance for site moves with URL changes discusses URL mapping and redirects. Use relevant destinations; redirecting unrelated old pages to the homepage does not preserve the content relationship simply because the response eventually succeeds.
Assign an owner for mapping decisions that remain unclear. A missing replacement is a content decision to resolve, not a detail that should be guessed during deployment.
Capture the evidence you will need later
Save representative old page content, screenshots, response information, and indexing signals before the move. Record the capture conditions and timestamp. Keep those observations separate from the planned new behavior.
Preserve critical details that a layout review may overlook: product identifiers, policy wording, contact information, form destinations, download links, and important query parameters. Decide which must remain equivalent and which are intentionally changing.
The evidence format guide explains why screenshots and saved page structure answer different questions. A visually similar replacement can contain different links or directives. Keeping both forms of evidence makes investigation easier when a discrepancy appears.
Run a launch watchlist by consequence
Do the highest-consequence checks early, then expand through the inventory. The following is a planning example rather than a universal release sequence.
| Area | Launch check | Evidence of completion |
|---|---|---|
| Redirects | Old URLs reach their intended final destinations | Requested URL, redirect path, final URL, and status |
| Key content | Important facts and assets are present | Captured comparison and owner review |
| Search signals | Canonical and indexing policies match the new map | Effective headers and page declarations |
| Navigation | Internal links point to appropriate current pages | Representative link and journey checks |
| Critical tasks | Signup, contact, purchase, or booking still works | Recorded task result under agreed conditions |
| Responsive layout | Important content remains usable at relevant widths | Reviewed screenshots and interaction checks |
Do not treat a successful redirect as completion of the whole row. Inspect the final page. A redirect to a generic error screen or the wrong language version can return a successful response and still be incorrect.
Keep technical SEO signals consistent
Check whether redirects, canonical declarations, internal links, and sitemap entries express the same intended structure. A migration can update one source while leaving another pointed at the old hostname or path.
Use the canonical and noindex release checklist to inspect page-level policies. Review robots.txt for accidental restrictions carried from staging. Reconcile sitemap changes as URL sets so a reorganized file does not obscure a missing section.
Record exceptions individually. Some differences may be intentional, but they need a reason and owner. A broad “migration expected” label should not suppress all changes during the period when careful review is most valuable.
Separate launch verification from follow-up observation
Launch checks answer whether the website currently serves the intended behavior. Follow-up observation answers whether new errors appear, scheduled jobs behave correctly, old links continue to work, and search systems process the move over time.
Set a review cadence that fits the site's traffic, publishing schedule, and operational coverage. Avoid declaring the migration complete solely because a fixed number of hours passed without an alert. Some problems appear only when a content job runs, a campaign link is used, or a less common journey is attempted.
Search visibility can change during a move, but a monitor of page content cannot diagnose every cause. Use appropriate search and analytics reporting alongside website evidence. Do not promise a specific ranking recovery period or interpret a stable screenshot as proof that indexing has settled.
Close exceptions and update the ongoing monitors
Maintain one exception list with the affected address or journey, expected behavior, observed result, owner, and resolution evidence. Group related causes where useful, while keeping the individual important examples accessible.
When a redirect or replacement is corrected, recheck the effective result and preserve the earlier failure. When a redesign is approved, update visual references through the baseline review process. Avoid accepting all new captures as correct simply because the migration is intentional.
Finally, update the ongoing monitoring targets to reflect the new structure. Keep selected old URLs under observation where continued redirects matter. A migration is easier to maintain when the launch checklist becomes a smaller, deliberate set of ongoing checks rather than an abandoned spreadsheet of unresolved assumptions.