Canonical:
configure and check

Canonical connects versions of the same content

rel="canonical" tells a search engine which URL you prefer as the main version among duplicate or very similar documents. Visitors stay on the page they opened: the address bar does not change. The declaration helps search engines understand the versions, but guarantees neither the chosen URL nor high rankings.

Imagine a service page /services/audit/ and the same content with a campaign tag ?utm_source=newsletter. Visitors see the same content at different addresses. You can keep both accessible and declare the clean URL as preferred. Two different services that share a design are another case. A common template does not make them duplicates: each may have its own purpose, terms and audience.

Search engines can select a primary version themselves. Duplicate content alone does not mean an automatic penalty. Google explains how it chooses a representative for a group in its canonicalization documentation. For a site owner, the practical task is to make the structure clear, align URLs and notice when another document is chosen instead of an important page.

Keep three facts separate: what the CMS settings say, what the site actually serves and what the search engine has processed. Checking only one leaves room for errors.

First decide which pages are truly equivalent

Map the groups of variants for each service, product or article. Open each group’s pages side by side and compare their main content, purpose, product selection and accessibility. Assess what visitors receive without signing in. Different URLs do not prove different content, and similar URLs do not prove identical content.

The preferred URL should lead to a complete, working document. Review current impressions, visits, external and internal links, and migration history. These inform the decision; they do not mean “always choose the shortest URL”. If changing an established address, assess the impact on menus, ads, integrations and saved links.

Record the reason beside each rule. The next developer should not have to guess why a parameter was retained or an archive or print version points to another address.

Canonical, redirects, noindex and Clean-param do different jobs

A campaign parameter and a selected product-model parameter cannot automatically be treated alike. One may only track the visit’s source; the other may change the document itself. Before applying a bulk rule, test the site’s actual responses for several values.

Yandex’s Clean-param help explains the directive’s syntax and scope. Do not apply this rule to Google or list useful parameters without checking. General crawl restrictions are covered in the robots.txt guide.

Blocking crawling prevents the bot from seeing canonical in the page content. Do not assume a newly added tag will be processed on a blocked URL. Access rules, the primary-version choice and exclusion from search should all serve one clear objective.

Canonical URLs in HTML and response headers

For an HTML page, put the declaration inside <head>. In this teaching example, the primary service page is at https://example.com/services/audit/. On its accessible campaign-tagged duplicate, you can specify:

<link rel="canonical" href="https://example.com/services/audit/">

On the primary page itself, the same address is a self-referencing canonical. Use the full URL with the correct protocol and domain. Do not append a fragment such as #section, and check the trailing slash: the specified variant should open directly without an intermediate redirect.

You cannot insert an HTML tag into a PDF in the same way. If a file has equivalent copies, the server can express the relationship through an HTTP header. For example, the response for a duplicate PDF may contain:

Link: <https://example.com/docs/audit-guide.pdf>; rel="canonical"

Configure this header in the server response; do not print it inside the file. Google explains both methods in its guide to specifying a primary URL. In practice, it is easier to define one configuration source and check its output than to add independent settings in the theme, plugin and server.

WordPress example using Yoast SEO

First identify what already generates canonical: the CMS, SEO plugin, theme or custom module. An empty editor field does not mean the live page has no tag. Do not add a manual line on top of working automatic output.

1. Open the relevant page or post in WordPress.
2. In the Yoast SEO panel, open Advanced.
3. If this page needs a different primary address, enter the full URL in the Canonical URL field.
4. Save the page and open its public URL without signing in.
5. Check the resulting HTML and target document, not just the saved field value.

The current steps are given in Yoast’s help. Other CMSs use different field names and output mechanisms. If hundreds of pages of one type are affected, investigate the shared template first: editing every page manually may leave the underlying fault in place.

After updating, clear only the relevant caches and test several pages: a normal page, a parameterised URL, an archive and a paginated page. If admins see the fix but visitors do not, compare the served versions. Investigate caching and template conditions rather than pressing Save repeatedly.

Inspect source HTML, the rendered document and server response

Open the exact URL being tested and record where it ends up after loading. Use View page source to find link elements with rel="canonical". Record their href values. Simply counting occurrences of “canonical” is not enough: the word can appear in article text, scripts or comments without being active markup.

Then open browser developer tools, select Elements and compare the contents of head after JavaScript runs. Google allows canonical to be set with a script but recommends not replacing an existing address with a different one. See the JavaScript SEO documentation.

In Network, reload the page, select the document request and open Response Headers. Look for the Link header, if present. The HTML and header must not specify different primary addresses. Next, open the target itself and repeat the check.

• The target matches the agreed rule.
• The document is accessible and contains the expected content.
• There is no unexpected redirect to another URL.
• The target is not blocked from indexing.
• There is no A → B → C chain or A → B → A loop.

Save the URL, test time and a screenshot of the relevant line. This is the minimum evidence for a developer task. If only one page type is affected, also provide a working URL for comparison.

Compare the declared URL with Google’s choice

In Search Console, select the correct property and paste the full URL into URL Inspection. Open the indexing information and find the user-declared canonical and Google-selected canonical. If there is no data yet, record it as missing information, not a successful configuration.

Compare both fields with the expected rule and last crawl date. After a recent fix, the report may describe an older page version. A live URL test shows the current state but does not replace indexed canonical-selection data. Live-test limitations are listed in the tool’s help page.

If Google chose another page, inspect both documents. They may be nearly identical; alternatively, the main page may have returned incomplete content, been unavailable or sent conflicting signals. Do not switch canonical back and forth merely to make report fields match.

Store three values together: the expected URL, the site’s actual declaration and Google’s selected URL. This shows where the discrepancy arose and supports a later retest.

What to check for a “Non-canonical” status

In Yandex Webmaster, open “Indexing → Searchable pages” and the excluded-pages list. Find the URL and its exclusion reason. “Non-canonical” is explained in the report help page: the page was processed using the canonical URL declared in its markup.

That status is not inherently a defect. If a campaign-tagged variant is excluded and the intended main page appears in search, it may match the plan. If an independent service page is excluded, inspect its code and find why it points to another document.

Search engines differ. The Yandex guidelines state a restriction on canonical targets on another domain or subdomain. They also list reasons for ignoring the declaration: an inaccessible target, substantially different content, multiple addresses and chains. Moving between HTTP and HTTPS requires a separate redirect setup; do not rely on this tag alone.

After editing, confirm the site’s new response first, then request recrawling for important changed pages. Check both the duplicate and the target. Do not close the task merely because the request was submitted: search-status updates happen separately.

Pagination, filters and translations need separate rules

Pagination. If /catalog/?page=2 shows the next set of products, do not make the catalogue’s first page its canonical. Google recommends separate URLs and canonicals for pages in a sequence; see its pagination guidelines. Keep accessible links between catalogue pages and to products. One incorrect tag does not prove every product has disappeared from the index; check individual URLs.

Filters. First decide whether a selection is a useful independent page or a technical variant. Unproven search demand does not make every filter a duplicate of the whole category. If its selection and purpose differ substantially, canonicalising to the parent may be inappropriate. For useless combinations, design separate controls on creation, crawling and indexing.

Product variants. Check whether only the selected colour changes in the interface or the buyer gets a separate product with its own features. Do not extend one product’s rule across the catalogue without representative checks. Record which URLs should remain independent and align this with navigation.

Languages. Do not automatically canonicalise a translation to an original in another language. Use hreflang to connect language versions; canonical and language markup should agree. Practical errors in these relationships are covered in Google’s troubleshooting documentation.

Fix the rule that generates the wrong URL

Identical tags from two sources also deserve a single managed output. Their values may match today, but one module could change the address after an update. Still, do not label every repeated tag proof of traffic loss: record the actual behaviour first.

Do not replace diagnosis with a global domain substitution across the database. Find the specific field, template or rule. Save the previous setting and define a rollback method. This matters especially when a site has multiple languages, environments or page types.

How to build a Screaming Frog report

For a large site, use Screaming Frog SEO Spider. Under Spider → Crawl, check that canonical storage and crawling are enabled, enter the site in Enter URL to spider and click Start. When the crawl ends, open Canonicals. The workflow and reports are explained in the developer’s guide.

Review URLs with multiple declarations, non-indexable targets, chains and canonicals pointing elsewhere. In Missing, an absent tag calls for investigating the rule, not declaring an incident. Export problem rows and group them by template. One category defect may repeat across hundreds of URLs.

A crawler reports what the site served; it does not confirm the search engine’s choice. Cross-check important examples in webmaster tools. Add URLs from the CMS and sitemap: following links may miss orphan pages.

Keep a final log of the source URL, expected target, HTML canonical, HTTP canonical, target status code, indexing restrictions, Google-selected URL, Yandex status and test date. Mark empty fields “no data”. An empty field is not a positive result.

Test a change on one group before extending it

Teaching example: a site has 90 service pages and 30 accessible variants with campaign parameters. An audit finds that 12 distinct services point canonically to a shared section. These are not 42 identical errors: parameterised variants may follow the rules, while the 12 services need separate investigation.

Pick one affected service and record the task: actual URL, wrong target, expected value and test criterion. Fix the output source in staging; check that service, a neighbouring page and a parameterised variant. After deployment, repeat the check on the production domain without signing in.

1. Confirm the HTML and headers contain the intended result.
2. Check the target page’s accessibility and content.
3. Align internal links and the Sitemap with the chosen URLs.
4. Repeat the bulk crawl using the saved list.
5. Record the release date and request recrawling for important changes.
6. Later, compare search data with the new crawl dates.

Separate the technical fix from search updates. One edit cannot guarantee traffic growth or when a primary URL will be selected. The full monitoring process is described in the indexing-check guide.

What the work should leave you with

• A map of page types and primary-URL selection rules.
• A list of tested URLs, including parameters and pagination.
• Proof of the actual output after deployment.
• Accessible target documents without conflicting restrictions.
• Consistent internal links and an XML sitemap.
• Separate dated results from Google and Yandex.
• A list of exceptions awaiting a decision.
• Checks after theme or CMS updates and site migrations.

Include these results in the website acceptance process with the developer. The task is not complete just because “the tags are in place”: the owner must know which pages remain independent and how the rule was tested.

If discrepancies involve site structure and search demand, address them as part of SEO work. Template, server-response and CMS errors are resolved through technical maintenance. Each change needs a verifiable outcome on specific pages.

Common canonical questions