Start with the migration decision, not a hostname replacement
Use the approved old-to-new content mapping to identify the intended canonical destination for each migrated page. Record the release time and mapping version. A simple search for the old domain is useful for finding candidates, but it cannot decide whether every occurrence is wrong: historical references and external links may legitimately mention it.
Group the new URLs by template and content type. Include important service pages, articles and relevant documents, with each language represented where applicable. The aim is to detect a release-wide generation problem without assuming that a passing homepage represents every template. Preserve the expected destination alongside each observation.
Compare declarations across the deployed templates
Retrieve the new public URLs and record the canonical declaration actually delivered. Compare the complete address, including scheme, hostname and path, with the mapping. Check any applicable HTTP canonical header as well as page markup. A correct new hostname attached to the wrong path is still a mismatch.
Google recommends absolute canonical URLs and avoiding conflicting destinations across canonicalization methods. Compare the sitemap and internal references for the same content. Do not treat a new sitemap as proof that an old-domain declaration disappeared from a page; these signals can be produced by different parts of the application.
Trace repeated mismatches to their generating source
If several pages of one type point back to the old host, investigate their common template or base-URL configuration. Record the affected group and an unaffected comparison page. This evidence helps the developer locate the source instead of editing each output file independently and allowing the next build to recreate the issue.
After a correction, regenerate the affected output and recheck the group, including a page that was previously correct. Keep before-and-after declarations with the release identifiers. This is a regression check on the domain move, not a fresh decision about which unrelated pages should be combined or which language should represent another.
Illustrative example: two generators disagree
A fictional website moves its service pages to a new domain. The sitemap generator uses the new host, but the service template still reads an old base URL. The homepage passes its check because it uses a different template. A report limited to the sitemap and homepage would miss the conflicting service declarations.
The reviewer records the affected service paths and expected mapped destinations, then the developer corrects the template input. The rebuilt service pages are compared with the same mapping. Historical mentions of the old company website in article text are reviewed separately rather than erased by a global replacement. This example is hypothetical and includes no claimed ranking result.
Separate current correctness from Google’s observation date
Record Google-selected canonical information separately from the current declared canonical when inspection data is available. Retain the inspection time and last crawl time. An observation based on a crawl before the correction is not proof that the current deployment still emits the old value; equally, a corrected declaration does not prove Google has adopted it.
If a later crawl still shows a different selection, investigate the remaining signals and content relationship before changing the mapping again. Google makes the final canonical choice. A public-page audit helps verify the implementation you control, while dated inspection evidence tracks processing. Neither a clean template check nor sitemap acceptance guarantees immediate consolidation or unchanged rankings.