A canonical identifies the preferred version of a page. The most useful launch check is whether the canonical you actually return matches the page's intended role. A different canonical is a review prompt, not automatically a mistake: duplicates and syndicated content may intentionally nominate another URL.
Start with a small URL inventory
List your homepage and a few important pages with the URL you want visitors and search engines to use. Include the protocol, host, path and any meaningful query parameters. Then run each through the metadata or noindex checker. Read the final fetched URL beside the canonical. This side-by-side evidence is more useful than a general statement that a canonical exists. The presence of a tag says nothing about whether its target is correct.
Look for launch-specific leftovers
Common causes include a base URL left on the staging domain, a template that copies the homepage canonical onto every page, and two plugins that emit separate tags. A relative canonical can also resolve differently from what a developer expected. NewSiteCheck resolves the detected URL and reports the number of declarations. If there is more than one, inspect the page source and decide which component should own that output.
Distinguish duplicates from unique pages
A tracking parameter version of the same article often should nominate the clean article URL. A distinct service page with its own purpose usually needs an independent identity. If every service points to the homepage, check whether the template is incorrectly treating them as duplicates. Conversely, do not force self-canonicals onto pages you intentionally consolidate. The goal is to express the actual content relationship consistently, not to make every checker result green.
Align links, sitemap and redirects
Choose one preferred public version and use it in navigation, contextual internal links and the sitemap. If www and root hosts both serve the same pages, make their behavior intentional. Trace the alternate version with the redirect checker. Linking to a redirecting variant while declaring a different canonical adds unnecessary ambiguity and requests. Avoid redirect chains that move through several old conventions before reaching the current page.
Check that the target deserves preference
Open the canonical destination. It should be reachable and represent the content relationship you intended. A target that errors, requires a login or redirects to something unrelated is worth correcting. Cross-domain targets need special review because they nominate content on another site. Check ownership and the editorial arrangement before editing. NewSiteCheck shows evidence from the fetched response; it does not choose Google's canonical or verify every nominated destination.
Confirm what Google selected
Search Console can show both your declared canonical and Google's selected canonical for an indexed URL. If they disagree, inspect the content similarity and the surrounding signals before changing syntax. A current declaration may also differ from an older stored crawl. Keep the inspection timestamp, your deployment timestamp and the fresh tool result together. This avoids repeatedly changing a correct tag while waiting for a crawler to observe the update.
Illustrative example
<!-- A unique service page's preferred production URL --> <link rel="canonical" href="https://example.com/services/website-audit">
Adapt this example to the actual page and site configuration.
A practical action checklist
- Write the preferred public URL for each priority page.
- Compare the final response and canonical declaration.
- Remove conflicting tags and staging-domain references.
- Align internal links, sitemap locations and alternate-host redirects.
- Compare Google's selected canonical after a fresh crawl.
NewSiteCheck workflow and examples. Review important production decisions against the applicable official documentation.