A redesigned page can look finished while its canonical tag still points to staging, an old path or another page. Visual approval will not catch that. Before closing the launch ticket, check where the server sends visitors and which URL the page identifies as its preferred version.

The handoff should answer one concrete question for each important page: do the redirect, canonical, sitemap entry and internal links agree on the production URL that should remain available?

Start with a small URL map

Take one example from each changed page type: a service page, an article, a product detail page and any localized page affected by the redesign. For a migration with many changed addresses, apply the same checks to the complete mapping before sign-off; the small set is for finding systematic mistakes quickly.

Record the old URL, intended new URL, current response, final destination and declared canonical. Use actual pages, not just the homepage. Templates and plugins can behave differently on an article than on a product page.

Here is a teaching example: an old service page at /services/design has moved to /web-design/. A redirect to the new page is sensible if it is genuinely the replacement. But if the new page declares the old URL as canonical, the site is sending conflicting signals. The fix belongs in the canonical generator or migration mapping, not in a second redirect added at random.

Read the response before inspecting the rendered page

  1. Request the old URL. Note the initial status and each redirect destination. A successful final page can hide an unnecessary detour through staging or an unrelated page.
  2. Request the intended production URL directly. Confirm that it serves the right content without requiring a login or a redirect back to the old address.
  3. Read the original HTML head. Find every canonical link element. Look for a staging hostname, an old slug or two plugins emitting different URLs.
  4. Check the response headers. A Link header can also declare a canonical. If both methods are present, they should not contradict each other.
  5. Compare the rendered DOM. If JavaScript changes the canonical after load, trace that behavior to the application code or metadata component.

Google's canonical URL guidance recommends consistent signals and, for JavaScript-rendered sites, keeping the canonical in the original HTML without having JavaScript change it. Redirects and canonical annotations are strong signals; sitemap inclusion is a weaker one. None is a promise that Google will select the URL you prefer.

Make the rest of the site agree

Follow a navigation link and a contextual link to the page. If they still point through the old redirect, update the relevant link source as part of the approved migration work. Check the sitemap generator as well: listing an old path while the canonical points to a new path leaves contradictory maintenance rules in place.

Do not automatically point every similar-looking page to one generic landing page. Canonicalization is for duplicate or very similar content. Distinct products or services need a content decision, not a blanket rule based on a shared layout. Equally, adding noindex to a page you want searchable is not a substitute for resolving a canonical conflict.

For localized pages, check that the intended canonical and language annotations make sense together. A translated page should not inherit the English homepage as canonical merely because the redesign reused its metadata component.

Separate a live fault from an older search report

Search Console's user-declared and Google-selected canonical fields can disagree. Compare the inspected URL, the date of the crawl information and the current public response. Fixing today's HTML does not immediately replace Google's previously processed information.

If the selected URL still appears wrong, Guangsuan's guide to investigating a different Google-selected canonical offers a broader comparison of the current page, the declared URL and Google's chosen version. Use that comparison to investigate content similarity and conflicting signals rather than repeatedly editing the same tag.

A live test can show what is accessible now; it cannot force Google's indexing choice. Record a follow-up check instead of declaring the migration successful in search simply because the page returns 200.

What belongs in the launch handoff

Keep the URL map, response samples, observed canonical values and the time of verification with the release record. Name the component responsible for generating the canonical and the person who will review the subsequent Search Console result.

This makes two outcomes explicit: production signals are now consistent, and Google's selected canonical is either confirmed or still awaiting observation. The first is a launch check your team can complete. The second is a search-system result that needs separate evidence.