Canonical Tag Audit Checklist

Use this for: Public pages with known or suspected duplicate URL variants.

List likely variants from your CMS or crawler, such as a clean guide address and its tracking version. Open the pages side by side and compare the main text, products or service details. Shared menus and a similar title do not make two pages duplicates.

For a large site, use your crawler’s duplicate findings to select candidate groups, then confirm representative examples yourself. Keep a genuinely different product, guide or language version outside a group unless its main content is actually equivalent.

1. Collect candidate variants from your CMS, links or crawl report.
2. Open the pages and compare their main content and purpose.
3. Group equivalent versions and keep meaningfully different pages separate.

Use this for: Confirmed duplicate groups.

Choose the stable public address that best represents the group’s content. Confirm the exact protocol, hostname, path and required parameters. Use the real preferred destination after existing redirects, rather than inventing a cleaner address that has no working page.

In your CMS, find the page’s SEO or advanced canonical setting, or give the intended address to the developer who owns the template. Agree on this choice before updating declarations, internal links or the sitemap. A canonical preference helps Google interpret the group but does not control its decision.

1. Choose the representative using the group’s actual content and site structure.
2. Confirm the exact public URL and its responsible CMS/template setting.
3. Use that address as the reference for the remaining audit checks.

Use this for: Duplicate or superseded pages whose intended behavior is being decided.

Ask whether people still need the duplicate URL to load separately. A tracking or printable variant may need to remain accessible while declaring the representative. An obsolete address that has permanently moved usually needs a permanent redirect to the relevant replacement.

Do not use a canonical tag to send visitors elsewhere; it does not navigate their browser. Do not point an unrelated retired page at the homepage simply to clear an audit warning. Have the technical owner apply the chosen method to the specific URL group.

1. Decide whether visitors need the alternate address to remain usable.
2. Choose a canonical preference for an accessible duplicate or an appropriate redirect for a permanent move.
3. Test the resulting visitor behavior and the declared destination.

Use this for: HTML pages using or needing an explicit canonical in the source.

Open a page and choose View page source in your browser. Search for rel="canonical" and read the complete href. The canonical link belongs inside a valid head element and should name the intended absolute public URL. A fragment such as #details is not a separate canonical page.

Compare the declaration with your group decision. If it is missing where you want an explicit preference in the source, add it through the CMS canonical field or template. If several HTML declarations compete, remove the extra generator rather than adding another tag.

If the application deliberately adds its only canonical with JavaScript, use the rendered-canonical check below. A missing source tag is not an automatic failure for that supported implementation.

1. View the published page source and locate its canonical link.
2. Check its head placement, complete address and agreement with the chosen target.
3. Correct missing, malformed or competing HTML output at its CMS/template source.

Use this for: HTML pages and non-HTML resources included in a canonical audit.

In Chrome Developer Tools → Network, reload the page and select the main document request. In Headers → Response Headers, look for a Link header containing rel="canonical". Compare its target with the HTML declaration and the intended group representative.

An HTTP Link canonical can also serve a non-HTML file such as a PDF. If HTML and HTTP methods are both used, keep their targets consistent; choosing one implementation is easier to maintain. A header added by the host or CDN may explain a conflict that the CMS field cannot fix.

1. Read the main resource’s response headers in Network.
2. Compare any canonical Link target with the HTML value and intended target.
3. Correct the responsible server/CDN rule when declarations compete.

Use this for: Pages whose templates or JavaScript can affect head metadata.

Compare View page source with Chrome Developer Tools → Elements. In Elements, expand head and find the canonical link after the page has loaded. On a JavaScript site, navigate to a second page through the site and inspect that page’s head as well as loading it directly.

The rendered page should keep the intended target without adding a second conflicting link. Prefer a correct declaration in the initial HTML that scripts leave alone. If the application must add the canonical with JavaScript, it should create one clear correct declaration rather than compete with an existing wrong one.

1. Compare the source canonical with the rendered head in Elements.
2. On a client-routed site, test both direct loading and internal navigation.
3. Fix the component or script that changes or duplicates the declaration.

Use this for: Every declared canonical target in the reviewed sample.

Copy the declared target into a private browser window. In Chrome Developer Tools → Network, reload and inspect the main document’s status and response. For an ordinary public page, expect a direct 200 response with its real content, not a redirect, login challenge or not-found message.

If the target redirects, inspect the final page and decide whether the declaration should use that final address. If the target fails or serves unrelated content, repair it or choose the correct representative before changing every duplicate.

1. Open the exact declared target without a signed-in session.
2. Read the first response, final destination and page content.
3. Repair the target or update the declaration to the correct direct destination.

Use this for: Canonical targets intended to appear in search.

On the preferred target, search its HTML source for robots and googlebot meta tags. In Network → Headers, check X-Robots-Tag. Look for an unintended noindex. Then check the applicable robots.txt rules or use Search Console’s live test to review whether Google can fetch the page.

If the chosen public representative is accidentally excluded, repair the responsible setting and retest. Keep deliberate restrictions on private or intentionally excluded pages; choose a suitable public representative instead. Technical eligibility does not prove the page is indexed.

1. Check the target’s HTML and response-header indexing directives.
2. Check fetch access for the target using the applicable crawl rules or live inspection.
3. Repair unintended restrictions or select an appropriate public target.

Use this for: Duplicate groups with multiple canonical or redirect hops.

Open the target named by a duplicate’s canonical and inspect that target’s own declaration. If it points to another URL, follow the sequence until you find the intended representative or return to an address already visited. A redirect within the sequence also needs review.

Ask the developer to point each reviewed duplicate directly to the agreed representative. For larger crawls, Screaming Frog → Reports → Canonicals → Canonical Chains lists chains and loops; verify the example URLs before applying a broad template change.

1. Follow the declaration from the source through each target.
2. Identify the intended final representative and any cycle.
3. Replace indirect or circular references and fetch the group again.

Use this for: Internal links to content with a chosen representative.

Open the relevant hub, menu or related guide and follow its link to the reviewed content. Inspect the link’s href when needed. It should use the intended representative rather than an old slug or unnecessary tracking variant.

Change the link in the CMS page, menu or shared component that owns it. Keep useful links to genuinely distinct filters, product options or pages when visitors need them; first decide whether those destinations belong to the duplicate group.

1. Find an internal link to a page in the duplicate group.
2. Compare its href with the agreed representative.
3. Update inconsistent links and follow the published link again.

Use this for: Duplicate groups represented in an XML sitemap.

Open the sitemap and relevant child file. Search for the preferred URL and known duplicate variants. For the reviewed group, list the intended representative rather than competing versions of the same content.

When a listed URL declares another canonical, compare both with your decision before editing. The sitemap can be correct while a copied page template is wrong. Fix the incorrect generator or declaration, then read the published output again.

1. Find the group’s representative and variants in the sitemap inventory.
2. Compare membership with the intended and declared canonical.
3. Correct the inconsistent source and check the regenerated output.

Use this for: Published URLs with Search Console canonical data.

In Search Console → URL Inspection, inspect the exact source URL and expand Page indexing. Read User-declared canonical, Google-selected canonical and Last crawl. Compare the reported targets with your intended representative and the date of any recent change.

Use the indexed data for the selected canonical. Test live URL can check current output but cannot predict the canonical Google will select. An alternate page that selects the intended representative can be behaving correctly; it need not be indexed as a separate page.

1. Inspect the source URL’s indexed Page indexing record.
2. Compare both canonical fields and the crawl date with your decision.
3. Keep a matching decision separate from an older or unavailable record.

Use this for: Unexpected Google-selected canonicals requiring investigation.

Open the intended page and the unexpected selected URL. Compare their main content and current delivery. Then compare their declarations, redirects, internal links and sitemap entries. Check whether a shared template, wrong host or failed content request caused several pages to return the same material.

If the pages serve genuinely different purposes, identify the substantive information that distinguishes them and verify that it is present in the fetched/rendered page. If they are effectively duplicates, reconsider whether Google’s representative is reasonable. Do not make superficial word changes just to evade grouping.

1. Compare the current intended and selected pages side by side.
2. Check content delivery and conflicting technical signals for a concrete cause.
3. Repair the cause or revise the group decision, then request/review an appropriate recrawl.

Use this for: Published repairs to canonical settings or related signals.

After the fix is published, repeat the exact check that failed. Review the changed duplicate, its preferred target and another page using the same template. Include a genuinely different page so a broad rule does not accidentally collapse unrelated content.

Confirm the current source, headers, rendered declaration and relevant links or sitemap output. If a Google selection mismatch was involved, retain it as a separate pending outcome until a newer indexed record is available. Request indexing for an important repaired URL when appropriate, without expecting immediate selection or indexing.

1. Repeat the original failed test after the change is public.
2. Check the representative, its duplicate and a distinct control page.
3. Review Google’s later indexed record separately when selection was the issue.