Monitoring a website migration

Design monitoring around decisions

Start with the questions that would change your response. Can visitors reach moved pages? Are important templates exposing their content? Are new URLs being discovered? Has analytics changed? Which failures need an immediate fix, and which observations need more evidence? A dashboard with no connection to decisions quickly becomes background decoration.

Assign owners for delivery, content, search reporting and measurement. Define how an issue moves from an alert to a reproducible ticket. Set observation frequency according to risk and available support, with intensive checks around launch and continuing review as search systems process changes. Avoid a rigid recovery countdown that treats every site as equivalent.

Keep a release annotation register with timestamps and affected components. Subsequent fixes, content edits, tracking changes and infrastructure incidents can all influence the same chart. If those changes are undocumented, later analysis may attribute them to the initial migration incorrectly.

Capture a comparable baseline and mapping key

Save the approved old-to-new URL map and representative pre-release response data. Include status, canonical, robots directives, title, rendered text and internal discovery. Keep the original source inventory as well as the final in-scope list. A monitoring denominator should reflect reviewed pages, not whichever URLs happened to appear in the latest export.

Capture search clicks and impressions over comparable periods and retain enough context to recognise seasonality. Record device, country, search type and page-family dimensions where they matter. Save analytics definitions, conversion events and consent behaviour. A change in measurement configuration is a real change even when the underlying visits remain stable.

Use a stable content or mapping identifier to join old and new addresses. For merged pages, mark the many-to-one relationship explicitly. Otherwise a reporting query can double-count the destination once for every old source. The crawl and Search Console analysis guide covers joining technical and search evidence without losing scope.

Watch delivery before interpreting search outcomes

At launch, request known old sources and new destinations through the public stack. Check redirects, terminal responses, certificates and critical content. Include a genuine missing address as a negative control. Confirm that documents and conversion routes work, since a healthy homepage can coexist with failures in a separate service.

• Retain sampled response traces and expected destinations.
• Track errors by host, route family and delivery layer.
• Inspect production robots directives and canonical references.
• Confirm substantive rendered content on changed templates.
• Verify enquiries or purchases independently of traffic reporting.

Logs can show what the server received and returned, but their coverage needs checking. Edge responses may not appear in origin logs. A Googlebot-looking user agent alone is not reliable identity evidence. Mark the verification method and logging boundary when interpreting crawler activity. Do not let an incomplete log source stand in for the whole public delivery system.

Track search processing without demanding perfect synchrony

Use Search Console to examine the old and new properties or URL groups relevant to the move. Inspect indexing categories and representative examples, then verify live behaviour separately. An old URL excluded because it redirects can be an intended outcome. The same label on a new preferred destination may warrant investigation.

Review query and landing-page changes by mapped content groups. Keep filters consistent when comparing periods. Do not add overlapping property totals or treat a URL-level table as a complete inventory of the site. Old and new observations can overlap in time, and available reports have aggregation and reporting limitations.

Separate discovery, crawl access, index selection and search performance in your notes. A live destination that works is evidence of delivery. It does not establish that Google has selected it for every query. Likewise, indexing alone does not promise meaningful visibility. The domain move guide explains the additional property and hostname responsibilities where the address identity changes.

Investigate losses using competing explanations

When a cohort declines, write at least two plausible explanations and the evidence that would separate them. Delivery failure predicts broken responses or access restrictions. Content loss predicts missing information concentrated in changed templates. Measurement failure predicts disagreement between independent sources. Demand changes may affect similar query groups beyond migrated pages.

Compare a failed cohort with a reasonably similar unaffected group, acknowledging where the comparison is imperfect. A blog section is rarely a clean control for seasonal product pages. Examine devices, markets and search types independently where the redesign or infrastructure could affect them differently.

Prioritise concrete contradictions. If canonicals point to retired URLs, repair them. If analytics falls but successful arrivals and search clicks remain broadly consistent, test tracking before rewriting pages. If both delivery and content checks pass, investigate demand and search-result changes before reversing the migration. Correlation with launch time is useful for scoping; it is not proof of cause.

Illustrative example: a hidden product-template loss

Illustrative example: after a platform move, a retailer sees fewer search clicks to product pages while category pages remain comparatively stable. The redirect report passes. One hypothesis is a mapping problem hidden by aggregate results; another is that the new product template has lost useful specifications.

Pair representative old and new product URLs. Request their redirect traces and compare saved rendered content with production. Suppose the destinations are correct, but specification tables are now fetched only after an interaction. The team has a reproducible content-availability regression to investigate, rather than a reason to alter every redirect.

Acceptance for the repair requires the agreed specifications to be available in the intended rendering path, plus a regression case for another product family. Search monitoring continues after deployment, but the fix is accepted on demonstrated content behaviour. This scenario is illustrative and makes no claim about measured traffic loss, recovery speed or a particular retailer.

Set alerts around actionable failures

Use immediate alerts for clear operational faults: widespread server errors, redirect loops, expired certificates, failed critical transactions or broad production restrictions. Use reviewed trend alerts for slower evidence such as a sustained loss within a mapped content cohort. Choose thresholds from the baseline variability and business exposure, not an unexplained universal percentage.

Every alert needs an owner, first diagnostic step and escalation route. Deduplicate repeated symptoms from one incident. A single routing failure can generate thousands of failed URLs; sending thousands of alerts makes the response slower. Preserve representative evidence and quantify affected scope separately.

Developer acceptance for a monitoring fix should include a deliberately failing fixture, a passing control and confirmation that alerts reach the agreed workflow. Test joins and denominators too. A broken data pipeline that reports zero errors can look healthier than a working one. Use the technical monitoring guide to keep observation reliable after launch.

Choose repairs, rollback and a defensible close

Prefer a focused forward fix when the fault is isolated and understood. Consider rollback for severe availability or transaction problems when recovery is unsafe or too slow. A traffic decline alone is insufficient: reversing a domain or URL move can introduce new contradictions, cached redirects and additional processing.

Document limits whenever communicating results. Search reports do not update instantly, samples exclude untested states and seasonal comparisons can be imperfect. State what is known, what remains uncertain and which observation will resolve it. Avoid claiming a migration is fully processed because a handful of high-profile pages appear in results.

Close launch monitoring when critical journeys are stable, agreed cohorts have been reviewed, outstanding faults have owners and recurring checks are handed over. Keep legacy routing, certificate and domain responsibilities alive. Revisit the broader migration plan if the scope has changed, rather than quietly redefining success to match a convenient dashboard.