Conflicting canonicals (different URLs)
canonical_conflictShort answer
Two or more canonicals with different URLs — two <link rel="canonical"> tags, or an HTML canonical that disagrees with the Link: HTTP header. Google will likely ignore all of them and choose on its own. Remove the extras so exactly one canonical URL is declared.
Why it matters
Google lists "multiple rel=canonical" among the most common canonical mistakes: when the declarations disagree, none of them is trusted. The usual cause is two SEO plugins, a theme that outputs its own canonical next to the plugin's, or a CDN/server adding a Link header with a different URL than the HTML. The page ends up without a usable canonical, which matters most on sites with URL variants.
How Glimana detects it
The crawler counts distinct canonical URLs in the HTML head and compares the HTML canonical with the Link: <…>; rel="canonical" header. The rule fires when more than one distinct URL is declared; the evidence shows the count and each value.
How to fix it
- Find the affected pages in Glimana. Open Issues › Conflicting canonicals (different URLs). Every affected page is a row; open one to see the evidence Glimana recorded for it (the measured value, the offending element or the target URL). The same list sits on the task card under Tasks, and the page's own detail view under Pages shows its full signals.
-
Apply the fix on your platform.
- If two SEO plugins are active (Yoast and Rank Math, or All in One SEO alongside), keep one.
- If the theme prints its own canonical, disable that option in the theme settings or remove the line from
header.php. - For a header canonical, check the hosting control panel or a security/CDN plugin that sets
Linkheaders.
Apps that add canonicals for filtered collections or variant pages can duplicate the theme's
{{ canonical_url }}. Keep the theme's line and turn off the app's canonical injection.Output the canonical in one place. If you also set a
Linkheader at the edge, make it identical to the HTML value, or drop one of the two methods — Google notes that using both is more error-prone. -
Publish and clear caches. Save and publish, then make sure the crawler will see the new version: WordPress — clear the page cache in your cache plugin and purge the CDN; Shopify — theme and content changes go live on save, but purge any CDN in front of the store; custom code — deploy and purge the edge cache. Check in a private window or with
curl -s https://your-domain/page | grep -i '<title\|canonical\|robots'that the live HTML has changed; Glimana reads what the server sends, not what your browser has cached. - Verify in Glimana. Open the task under Tasks and click Mark as done. The affected pages are queued for a verification crawl within a few hours, and the task closes when a single canonical URL is declared across HTML and headers. If the check still fails, the task returns to New with a note; when it passes, the task is listed under Resolved technical issues on Impact reports. To check sooner, use Re-crawl affected pages on the issue.
How the fix is verified
The page is re-crawled; the task closes when a single canonical URL is declared across HTML and headers.