A canonical tag is a link element added to a page’s head section that tells a search engine “this URL is the primary version of this group” when the same or very similar content can be reached through multiple addresses. Google considers this declaration a strong signal but does not implement it as a binding command; it selects the canonical URL through its own evaluation. This also provides the practical answer to “what is a canonical tag”: the tag declares a preference and produces the expected result only when it points in the same direction as other signals.
This guide explains correct syntax for the rel=”canonical” element, how Google clusters duplicate pages, how it differs from other canonicalization methods such as redirects and sitemaps, WordPress’s default behavior, and how to read Google’s selected address in Search Console’s URL Inspection tool. The explanations are based on Google Search Central documentation and apply to every platform.
What is a canonical tag, and what does it do?
A canonical tag is the <link rel="canonical"> element indicating which duplicate page should represent the group in search results. Google calls this process “canonicalization” and the selected address the “canonical URL”. The canonical page becomes the version crawled most regularly; other duplicates are visited less often to avoid placing a load on the server.
There are four concrete benefits to using the tag: users see the clean, parameter-free address in results; the value of external links pointing to different duplicates is consolidated at one address; and the same content’s performance is tracked in a single row. Crawlers also focus on new or updated pages instead of wasting time on duplicates.
Duplicate content alone is not a reason for a penalty. Google’s canonicalization documentation explicitly states that having duplicate content on a website is normal and does not violate spam policies. The real problem is conflicting signals determining which version should be shown.
Where do duplicate URLs come from?
Most duplicate URLs arise from the website’s normal operation rather than malicious intent. A single product or post page may open through five or six different addresses without anyone noticing. The most common sources are as follows:
- Protocol and domain versions: serving the same content separately over secure and insecure protocols and with and without www before the domain name.
- Tracking and session parameters: addresses with an advertising click ID, campaign tag, or session number added.
- Sorting and filtering options: ecommerce category versions with price sorting or a color filter applied.
- Device variants: pages published on a separate mobile subdomain.
- Regional variants: content in the same language served at separate addresses for different countries.
- Forgotten test copies: a demo or staging environment left accessible to crawlers.
Language versions count as duplicates only when the body text remains in the same language. If only navigation elements and footer text have been translated while the body remains unchanged, Google places these pages in one cluster; actually translated pages are evaluated as separate content.
How does Google choose the canonical URL?
Google first identifies each page’s primary content, groups pages with the same or very similar content into one cluster, and then marks the version most complete and useful to users as canonical. In this selection, signals such as HTTPS use, redirects, inclusion in the sitemap, and the rel=”canonical” declaration are weighed together.
The website owner’s declaration is only one of these signals. If the canonical tag points to one address while internal links and the sitemap point to another, Google makes its own choice. The search result does not always show the canonical page either: even if the desktop version is canonical, a suitable mobile version may be shown to a mobile user.
The HTTPS preference is also subject to an exception. Google selects HTTPS by default between equivalent HTTP and HTTPS pages; however, if the certificate is invalid, the page loads insecure resources, or the HTTPS version redirects to HTTP, this preference may be reversed.
Ways to declare a canonical URL: redirects, rel=”canonical”, and sitemaps
Google’s guide to specifying a canonical URL ranks the methods of declaring a preference in three tiers by their impact and states that they are more effective when used together. The method to choose depends on whether the duplicate will continue to exist:
| Method | Signal strength | Suitable situation | Point to watch |
|---|---|---|---|
| Permanent redirect | Strong | When the duplicate should no longer open at all | The visitor also goes to the destination; the duplicate page becomes unavailable |
| rel=”canonical” link element | Strong | When duplicates such as filters and parameter versions need to remain accessible | Works only on HTML pages; maintaining mappings on large websites takes effort |
| rel=”canonical” HTTP header | Strong | Non-HTML files such as PDF and Word | Access to server configuration is required |
| Sitemap inclusion | Weak | Declaring canonical addresses in bulk on large websites | Google still has to discover the duplicates itself |
The main difference between a redirect and a canonical tag is user experience. With a redirect, the old address disappears; with a canonical tag, the duplicate page remains open to visitors and only a preference is declared to the search engine. A redirect is more appropriate for an address permanently abandoned, and a canonical tag for a filter page that continues to serve its purpose.
Page contents
How do you write the rel=”canonical” tag correctly?
The correct syntax is to add a single link element to the duplicate page’s head section, pointing to the canonical address as an absolute URL. For example, a filtered category page contains this line: <link rel="canonical" href="https://www.example.com/kategori/ayakkabi/" />. Google recommends adding the same line to the canonical page itself, meaning that the page references itself.
Details overlooked when writing the tag can make it ineffective. The points checked in practice are as follows:
- Use an absolute address: although relative paths are supported, they are not recommended because they can cause problems such as accidentally identifying the staging environment as canonical.
- Keep the element in the head: the tag is read only in the head section; an invalid HTML element inside the head may close the section early and place the tag in the body.
- Provide a single value: two different canonical tags on the same page, or different addresses in the header and HTML, increase the likelihood of errors.
- Do not use URL fragments: Google generally does not support fragment addresses beginning with a hash sign.
- Do not mix in alternative attributes: a canonical declaration containing an hreflang, media, or type attribute is not used for canonicalization.
On websites generating content through JavaScript, the safest approach is to include the canonical address in the HTML source and ensure scripts do not change this value. If it cannot be added to the source, the value should be provided only through JavaScript; two different declarations should not be left together.
Canonical through an HTTP header: PDFs and other files
For non-HTML files, canonical is declared through the Link header added to the server’s response. If the same catalog is published as both PDF and Word files, a header identifying the PDF address as canonical can be added to the Word version’s response. Google supports this method for web search results and requires an absolute address here too.
The header method does not increase page size and can map an unlimited number of duplicates. In return, it requires access to server configuration. Although using both a header and an HTML element on the same page is supported, it is not recommended; one of the two sources becoming outdated over time produces a conflicting signal.
Let’s investigate duplicate page problems together
If pages are waiting with a “Duplicate” status in Search Console, let’s find which signal is conflicting together. A free preliminary assessment is provided for canonical, redirect, and sitemap checks; once the scope is clear, a proposal is shared the same day.
How are canonical tags managed in WordPress?
WordPress core automatically adds a self-referencing canonical element on individual posts and pages. According to the rel_canonical() reference on developer.wordpress.org, this output is generated only for singular content. Category, tag, and archive pages are not covered by the core.
An SEO plugin generally comes into play for archive pages and custom redirection needs. These plugins provide a “canonical URL” field on each post’s editing screen and also generate self-referencing tags for archives. What matters here is that the theme and plugin do not output tags simultaneously; if two canonical lines appear in the source code, one must be disabled.
When the domain or permalink structure changes, canonical values may not update automatically, especially addresses entered manually in plugin fields, which remain in their old form. For this reason, during WordPress website migration , canonical values are also reviewed together with the redirect map.
How do you see Google’s selected canonical URL in the URL Inspection tool?
The address Google considers canonical is visible in the “Page indexing” section of Search Console’s URL Inspection tool. The tool’s help page defines two fields separately: “User-declared canonical” is the website owner’s declaration, while “Google-selected canonical” is Google’s decision.
The check is performed in the following order:
- Open the relevant property in Search Console and enter the address to inspect in the search box at the top.
- Open the indexed result and expand the “Page indexing” section.
- Compare the declared and Google-selected canonical URL lines.
- If the two values differ, examine internal links, the sitemap, redirects, and differences in page content.
- After making corrections, submit indexing requests for important addresses.
The live test does not answer this question; the help page states that the canonical version can be read only from indexed data and that the live test cannot predict it. The “Duplicate, Google chose different canonical than user” status in the Page Indexing report is the website-wide view of the same conflict. Google also notes that it may keep pages in a duplicate cluster for up to two weeks even after the content difference has been resolved.
Canonical, noindex, robots.txt, and 301: when should each be used?
These four tools perform different jobs and cause problems when used interchangeably. Canonical says “this page is a duplicate of that one”; a 301 redirect says “this address is now over there”; noindex says “do not index this page”; and robots.txt says “do not crawl this address”.
Google does not recommend using robots.txt for canonicalization. An address blocked from crawling may be indexed without its content being read, and Google may never see the canonical declaration on that page. Likewise, using noindex to influence canonical selection within a website is not recommended; this method removes the page from search completely, while canonical transfers its value to the primary page. The URL removal tool is not a solution either, because it temporarily hides all versions of the relevant address.
A practical distinction is as follows: use 301 if the content has actually moved, canonical if the duplicate continues to serve a purpose, noindex if the page should never appear in search, and robots.txt if there is a technical area that crawlers should not enter at all. Making crawlability and indexing directives consistent across the website is addressed through technical SEO services for the website.
Common canonical mistakes and the correct approach
Most canonical mistakes arise from signals contradicting one another rather than a single incorrect line. The situations most frequently encountered in audits and their correct approaches can be described as follows:
- Pointing all pages to the homepage: if a theme setting places the homepage address on every page, internal pages may be considered duplicates. Each page should indicate its own address.
- Linking paginated lists to the first page: the second and third pages of a blog archive contain different content; they need to indicate their own addresses.
- Keeping duplicate addresses in the sitemap: if the sitemap contains the parameter version and the tag contains the clean version, the signals conflict. Only canonical addresses belong in the sitemap.
- Pointing internal links to the duplicate: if menu and in-content links consistently go to the old or parameter-based address, Google may select that address.
- Leaving an HTTP canonical on an HTTPS page: an old value left over from migration may cause Google to prefer the HTTP version.
- Declaring a redirected address as canonical: the tag should point directly to the final address returning 200, rather than an address that redirects elsewhere through 301.
Connecting different products to a single page through canonical tags is another common mistake. Pages whose content is truly different are not duplicates; Google may disregard the declaration in this situation. A broader checklist for product variants and filter pages is available in the ecommerce SEO checklist article.
How should canonical checks be included in routine maintenance?
Canonical configuration is not a task to set up once and forget; a theme update, plugin change, new filter, or campaign parameter can create new duplicates each time. The check is therefore added to the website’s regular maintenance schedule.
Looking at duplicate statuses in the Page Indexing report once a month, opening a few priority pages with the URL Inspection tool, and checking that the source contains a single canonical line is a sufficient routine for most websites. After a major structural change, the sitemap, internal links, and redirects are reviewed together on the same day. How this audit fits into the website’s overall search compatibility is explained in the SEO-friendly website guide.
Let’s establish your canonical URL setup together
Let’s review the website’s current situation together for parameter-based addresses, filter pages, or signals confused after migration. The preliminary assessment is free; once the required steps are clear, we share the scope and proposal in writing the same day.
Frequently asked questions
Will a website without canonical tags experience problems?
Generally no; Google selects the most suitable version in the cluster itself even when no canonical URL is declared. However, if parameter-based addresses, filters, or www and https versions exist, making a declaration increases the likelihood of the desired address appearing in search results.
Does Google have to follow the canonical tag?
No, rel=”canonical” is a hint, not a rule. Google may select a different page as canonical by examining other signals such as content differences, internal links, the sitemap, and redirects.
Is it necessary to add a self-referencing canonical to every page?
Yes, Google recommends that the canonical page have a self-referencing canonical tag. This line identifies the primary address in advance when parameter-based copies of the page arise.
Are canonical tags and 301 redirects the same thing?
No. A 301 sends the visitor and crawler to the new address, and the old address no longer opens; canonical leaves the duplicate page accessible and declares a preference only to the search engine.
Where can you see Google's selected canonical URL?
In Search Console’s URL Inspection tool, opening “Page indexing” in the indexed result shows the “Google-selected canonical” line. This information is in indexed data, not in the live test.
When does Google update its canonical selection after a correction?
There is no fixed schedule; the update depends on the page being recrawled and reevaluated. Google states that pages may remain in a duplicate cluster for up to two weeks even after the content difference has been resolved.
Can canonical be used for content published on another website?
Google considers preventing the duplicate from being indexed more effective than canonical on syndication partner websites. Because the pages are often sufficiently different, cross-domain canonical may not produce the expected result.
Call us
Call us for detailed information.
Let us call you!
Share your number and let us call you!
Our other services
- › Corporate web design
- › Ecommerce website development
- › SEO optimization
- › WordPress website development
- › Google advertising management
- › WordPress speed optimization
Service areas
- › Web design in Sakarya
- › Web design in Tekirdağ
- › Web design in Bursa
- › Web design in Beşiktaş
- › Web design in Şişli
- › Web design in Tuzla
- › Web design in Ümraniye
- › Web design in Kadıköy
- › Web design in İstanbul
- › Web design in Ankara
- › Web design in Ataşehir
- › Web design in Üsküdar
- › Web design in Kartal
- › Web design in Maltepe
- › Web design in Pendik
- › Web design in Kocaeli
- › Web design in İzmir
- › Web design in Antalya
