Why is my rel=canonical tag missing?

A canonical URL missing from your page is not automatically a defect — but when the same content is reachable through more than one URL, the absence of a canonical hint leaves Google to decide which version to show. The risk is that Google picks a URL you did not intend, and ranking signals meant for one page end up attributed to another. This page explains when the tag matters, when it does not, and the exact markup to add.

Why this matters

Google's canonicalisation documentation says that while you are encouraged to use canonicalisation methods, none of them are required, and a site will often do fine without specifying a preference, because Google will identify which URL is objectively the best version to show. The tag becomes important when duplicates genuinely exist. Common causes are the same page reachable with and without a trailing slash, with tracking parameters such as ?gclid=, as a www and bare-host variant, or as AMP, print, and paginated variants. In those cases a canonical hint lets you tell Google which URL should represent the content, which consolidates link signals onto one URL and simplifies tracking. When every page has exactly one URL and no near-duplicates, a missing canonical tag is a non-issue and adding one is unnecessary. The subtle danger is pointing the tag at the wrong URL. If page A declares page B as canonical, or two duplicates point at each other, Google may ignore the conflicting signal entirely — or, worse, follow a mistaken declaration and drop the page you actually wanted indexed. Google explicitly warns against specifying different canonical URLs for the same page through different methods, and against using noindex to manage canonicals within a site, because noindex removes the page from Search altogether.

How to fix it

Add a single rel="canonical" link element in the <head> of the page, pointing at the preferred absolute URL. Google recommends absolute URLs rather than relative paths, because relative paths can cause problems later, for example if a staging site is accidentally crawled. Include a self-referential canonical on the canonical page itself, so every duplicate explicitly names the same target. Choose one method and stay consistent: if you set the canonical in an HTML element, do not also send a conflicting rel="canonical" HTTP header. Link internally to the canonical URL rather than to a duplicate, which helps Google understand your preference. If you use a CMS, look for its built-in canonical setting instead of hand-editing templates. Before publishing, confirm the target URL returns 200 OK and is the version you want in search results — never point a canonical at a 404, a redirect, or a page with different content.

<!-- exact markup: one self-referential canonical in the <head> -->
<link rel="canonical" href="https://www.example.com/green-dress">

<!-- preferred: absolute URL -->
<link rel="canonical" href="https://www.example.com/green-dress">

<!-- avoid: relative URL (Google does not recommend it) -->
<link rel="canonical" href="/green-dress">

How to verify the fix

Open the page and inspect the <head>. In DevTools, select the <link rel="canonical"> node in the Elements panel and confirm the href is the absolute URL you intend, that it matches the page's own canonical URL, and that there is exactly one such element. Because client-side JavaScript can add or alter the tag, also check the raw HTML source (View Source) to confirm the canonical is present before scripts run. Finally, fetch the target URL and confirm it responds 200 OK rather than redirecting or erroring.

# confirm the canonical in raw HTML
curl -s https://www.example.com/green-dress | findstr /I "rel=\"canonical\""

# confirm the canonical target actually resolves
curl -sI https://www.example.com/green-dress | findstr /I "HTTP"

Automated check

App Readiness Auditor does not read your canonical tags, does not detect duplicates, and does not check whether a canonical target resolves, so it cannot confirm or deny a canonical URL missing from your markup. The nearest check it does perform is for a missing meta description, another <head> metadata gap that is easy to ship unnoticed and straightforward to detect by fetching the rendered HTML.

Scan your app free →

Related issues