Audit canonical URLs before duplicate article versions split your search signals

A canonical audit should begin with the preferred article URL, not with a plugin's green indicator. Google uses canonicalization to choose a representative among duplicate or very similar pages. Its canonicalization explanation makes the key point: the selected URL is a search-engine decision informed by signals, not simply a value that a site owner types into a field.

For a publisher, the immediate problem might be an article available as a normal page, a print view and a parameterized URL. The goal is to make the intended version clear without hiding useful translations or treating genuinely different articles as duplicates. Start with a few representative examples, then expand the fix only after the pattern is understood.

Choose a destination that deserves to represent the content

Open the proposed canonical URL directly and check that it returns the intended article. It should not point to a retired page, a login screen, a broken route or an unrelated category merely because that destination seems more authoritative. A canonical relationship needs a defensible content relationship, not just a shared keyword.

Google's canonical implementation guidance treats redirects and canonical annotations as strong signals, while sitemap inclusion is weaker. These signals can support each other, but none justifies contradictory instructions. If the duplicate version no longer needs to exist for visitors, consider the appropriate redirect instead of keeping an unnecessary page solely to attach a canonical.

If the alternate version remains useful, such as a printable article, keep the visitor experience and the search preference distinct. Confirm that the preferred page is accessible and intended for indexing. A canonical that points to a page excluded from indexing creates a conflict the owner should resolve rather than hope Google interprets favorably.

Write the intended mapping in a short working record: alternate URL, preferred URL, reason and the person responsible for the template. The mapping should be specific enough that someone else can open both pages and understand why they belong together. “All articles to the homepage” is not a meaningful duplicate-content strategy.

Inspect what the server and browser actually publish

A plugin setting is an input, not the final evidence. Inspect the delivered page source and relevant response headers, then check the rendered result where JavaScript changes the page. Look for more than one canonical declaration, a relative or malformed destination, and a value left over from a staging domain or an earlier URL structure.

Where two plugins or a theme and a plugin both produce canonical markup, identify which component should own it. Do not keep adding another declaration to outvote the old one. Remove the conflicting source through a controlled change and inspect a fresh response afterward, including any cache layer that could still serve the previous version.

For a PDF or another non-HTML document, Google's guidance supports a canonical through the HTTP Link header for web search. This is not the same as adding a visual link inside the PDF. The server delivering the file must provide the intended response header, and the chosen destination must still be an appropriate equivalent.

Record one actual response for each tested template and file type. Do not mark every article complete because the homepage passed. A print template, attachment route and normal article template may be produced by different components, so the evidence needs to match the output being assessed.

Compare your preference with Google's indexed choice

Google's URL Inspection documentation distinguishes the declared canonical from the Google-selected canonical where that information is available. Check the indexed record for both the alternate and preferred URLs. A live test is useful for current accessibility and rendering, but it does not predict the canonical Google will select after indexing.

When the selected URL differs from the intended one, check the evidence before changing everything. Are the pages genuinely similar? Do internal links favor the intended address? Does the sitemap include the preferred version? Does a redirect or a different declaration send a competing signal? Treat the mismatch as a diagnostic question, not immediate proof of a penalty.

Use one bounded change at a time and record the observation date. Google's stored index information may reflect an earlier crawl, while the current page already contains a correction. Keep those timelines separate so that a stale report does not trigger repeated, contradictory edits before the first fix has been assessed.

Do not promise a ranking increase from a canonical correction. The defensible objective is a coherent preferred-URL signal and a clearer interpretation of indexed duplicates. Whether search visibility changes afterward is an observation to measure, not a guaranteed outcome of adding a tag.

Keep language editions out of the duplicate cleanup

Translated editions should not automatically canonicalize to the English article merely because English was the source text. Google's implementation guidance says to use a same-language canonical when working with hreflang where that version exists. Each intended indexable edition needs its own appropriate preferred URL, while hreflang describes the language alternatives.

For a multilingual publication, test the article template in every enabled language. Check the language prefix, the preferred destination and the alternate-language references together. Our multilingual website launch guide addresses the wider publishing workflow; a canonical fix that removes useful editions would work against that goal.

Keep this article-version audit separate from policies for large filtered URL families. The faceted-navigation guide covers crawl management for that different pattern. Both involve URLs, but a duplicate print view and thousands of filter combinations should not automatically receive the same remedy.

Close the audit with a verified mapping, a single coherent implementation per tested output and a dated record of Google's indexed selection. Recheck after template changes or migrations rather than treating the first pass as permanent. The useful result is not merely that a canonical exists, but that the site consistently explains which version should represent each piece of content.