How to verify an SEO site migration in Search Console

Start with the migration contract, not the traffic chart

Post-launch verification asks whether a specific old page has become the correct new page for users and Google. It is not a general investigation into every possible cause of lower traffic.

Freeze the launch timestamp, approved URL map, redirect configuration version and expected exceptions. Keep access to the old domain, DNS, hosting and Search Console. Without that evidence, a redirect that works today cannot explain what happened at launch.

Google’s site-move guide recommends mapping old URLs to new ones, implementing permanent server-side redirects and monitoring both sites. Treat those as separate checks, not one launch checkbox.

Define success per URL class before interpreting totals. A migrated guide should resolve to its replacement; a deliberately retired service may correctly return 404 or 410. A catch-all homepage redirect is not an acceptable substitute for missing mapping decisions.

Build an old-to-new ledger with explicit exceptions

Use one row per old canonical URL, with its intended destination, disposition, business priority and test evidence. Start with previously clicked pages, linked pages, sitemap entries and every template or redirect-rule pattern. Include parameter and trailing-slash variants where they test different rules.

This mapping is illustrative, not a report from a real migration. The old host is https://old.example.com; the new host is https://new.example.com.

For consolidations, retain both source rows but count the destination only once in the new-page cohort. Otherwise your measurement duplicates its clicks.

Do not mark an entire template green after testing its homepage. Sample high-value URLs and edge cases across each rule, and validate the full map with a rate-limited checker when practical. Log the tested time and observed destination, not just a pass flag.

Verify HTTP delivery before interpreting Google’s index

Google recommends HTTP 301 or 308 redirects, preferably directly to the final destination rather than through chains. A redirect to the wrong page can be technically valid and still fail the migration contract.

These read-only GET requests use reserved example hosts. Replace them with authorized URLs you own; they show commands, not executed test results. Inspect one response first, then the complete chain:

curl --silent --show-error --dump-header - --output /dev/null \
  'https://old.example.com/guides/setup'

curl --silent --show-error --location --max-redirs 5 \
  --dump-header - --output /dev/null \
  --write-out '\nFinal: %{url_effective} Status: %{http_code}\n' \
  'https://old.example.com/guides/setup'

curl --silent --show-error \
  'https://new.example.com/learn/setup'

The first response should have the intended permanent status and Location. The chain should end at the mapped page with a successful response, not a login screen, unrelated category, loop or error template returning 200. Read the final HTML for content, robots directives and canonical tags; inspect response headers for X-Robots-Tag too.

A terminal fetch does not render JavaScript or reproduce Googlebot’s access. Follow up with browser checks and URL Inspection for important templates. Check both hosts’ robots.txt rules independently: Google must be able to crawl the old redirect and the intended new content.

Use a verification matrix to separate delivery from indexing

Keep live observations apart from Google’s last recorded state. URL Inspection documentation distinguishes indexed results from live tests; a live test cannot predict Google’s canonical choice.

A self-referencing canonical on the new page should agree with redirects, internal links and sitemap URLs. Google’s canonical guidance describes redirects and canonical annotations as strong signals, not commands that guarantee selection.

For non-HTML documents, check any canonical HTTP header as well. A clean HTML template does not prove migrated PDFs send consistent signals.

Inspect old and new properties without losing the distinction

Verify access to both Search Console properties. For a domain move, inspect the old URL in the old property and its replacement in the new property. URL Inspection requires the inspected URL to belong to the selected property. For a path-only move, both URLs can belong to one property; retain separate page cohorts anyway.

For each important pair, record:

• Old URL’s indexed status, last crawl and redirect evidence.
• New URL’s indexed status, last crawl, user-declared canonical and Google-selected canonical.
• New URL’s live-test result and the date any defect was fixed.

An indexed snapshot from before launch cannot validate a post-launch fix. Conversely, an old URL excluded because it redirects can be the intended outcome. Use the not-indexed diagnostic guide when an important replacement remains excluded, rather than trying to make every old address indexed again.

Change of Address applies to supported domain or subdomain moves, not directory-only changes or HTTP-to-HTTPS migrations. Check ownership and other prerequisites in that documentation. Its checks cover only a sample of redirects, so acceptance is not a full-map audit and does not replace redirects.

Compare equivalent page cohorts and complete date windows

Keep separate old and new exports, with property, search type, dates, country and device filters recorded. Use equal-length windows with matching weekdays; exclude launch day from a clean before/after comparison and flag preliminary data. The chosen window is an analysis convention, not a promised recovery deadline.

Build a stable entity key from the mapping. For each window, sum clicks and impressions across the mapped old pages and distinct new destinations. Include both sides in both windows: the new host may already have had traffic, and old URLs may still receive clicks after launch.

Use non-overlapping URL-prefix properties or deduplicated page exports. Never add a Domain property’s totals to a contained subdomain property’s totals. For a same-domain path move, partition page rows into disjoint old and new sets instead.

Google’s Performance report documentation explains that page and property aggregation differ and newest data can be preliminary. Keep aggregation consistent. Do not average two CTRs or average positions; derive combined CTR from summed clicks and impressions, and inspect position separately for stable query-page segments.

Do not substitute the Queries table total for the page cohort: privacy filtering and row limits can make it incomplete. Keep exported totals and filters with each review so another analyst can reproduce the comparison. Track intentionally retired URLs separately instead of silently removing their historic clicks from the baseline.

Review the ledger in a fixed order: unresolved delivery failures, conflicting indexing signals, then visibility changes. Preserve previous observations rather than overwriting them. That history distinguishes a defect that is still live from a repaired defect awaiting a newer indexed snapshot.

Annotate content mergers, removed pages, redesigns and changing demand. Matching dates and URLs reduces confounding; it does not prove migration causality. If both cohorts lose visibility despite clean technical checks, continue with the traffic-drop investigation. If only analytics sessions change, check GSC clicks versus GA4 sessions before blaming the move.

Decide whether to repair, escalate or consider rollback

Escalate immediately for reproducible failures affecting important routes: redirect loops, widespread 5xx responses, broken TLS, unintended noindex, inaccessible destinations or a template pointing canonicals back to the old host. Attach mapped examples, timestamps and response evidence to the incident.

Prefer a scoped repair when the defect is isolated and the new site remains usable. Re-test the same URLs after the fix, then check indexed snapshots only once their crawl dates can reflect it.

Consider rollback with the engineering owner when the replacement cannot reliably serve users and a known-good restoration is feasible. Plan domain routing, redirects, canonicals and any Change of Address cancellation together. Avoid creating bidirectional redirects or alternating versions. Search Console does not automatically undo a migration.

A traffic chart alone is not a rollback trigger. Assign an owner and next review point to unresolved indexing or visibility issues. Google recommends retaining redirects generally for at least a year; that is redirect-maintenance guidance, not a recovery promise.

Frequently asked questions

Do I need Change of Address for every migration?

No. Use it for a supported domain or subdomain move, not a path-only change or an HTTP-to-HTTPS move. Check Google’s prerequisites and retain URL-level redirects.

Should old URLs remain indexed after a migration?

Old URLs can remain visible while Google reprocesses the move. Judge their redirects and intended replacements together; an old redirect URL being excluded is not itself a defect.

Does a successful live test prove the migration is complete?

No. It checks the current page’s accessibility and some indexing requirements. It does not prove indexing, canonical selection or transferred search visibility.

Can I add old and new Search Console clicks together?

You can sum matching, non-overlapping page cohorts for a defined period as an operational comparison. Do not add overlapping properties or average their CTR and position values.

Should a traffic decline trigger an immediate rollback?

No. Escalate confirmed delivery or indexing-control failures first. A rollback is an engineering decision with its own redirect and canonical risks, not an automatic response to a chart.

Create a GSC Magic account.