Canonical target returns an error or redirects
canonical_to_errorShort answer
This page says "the real version is over there", and "over there" is a 404, a 5xx or a redirect. Google ignores a canonical it cannot verify and picks a version itself. Point the canonical at a URL that returns 200 and declares itself canonical.
Why it matters
Google only honours a canonical whose target it can fetch and that is itself canonical. A canonical to a redirect sends Google on a chase; a canonical to an error is simply discarded. Either way you lose control over which URL is indexed, and after a migration you can end up with the old URL still ranking because the new page's canonical pointed at a broken address.
How Glimana detects it
For every page with a canonical to a different URL, Glimana looks up that target in the crawl. The rule fires when the target responded with 3xx, 4xx or 5xx, or when the target itself declares a different canonical. The evidence shows the target and its status.
How to fix it
- Find the affected pages in Glimana. Open Issues › Canonical target returns an error or redirects. 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.
Change the canonical to the final, working URL — the one that returns 200 and canonicalises to itself. If the target was deleted, the page probably should canonicalise to itself.
Clear the Canonical URL field in the SEO plugin for the page (self-reference), or paste the final URL. After a slug change, the plugin updates canonicals automatically; a stale value means the field was filled by hand.
Occurs with apps that rewrite canonicals for collection filters or variant URLs; update the app's target or remove the app's canonical override for this page.
Derive the canonical from the current route rather than from stored URLs; when a page is renamed, old canonical values stored in the database are the usual source.
-
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 every target returns 200 with a self-referencing canonical. 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 affected pages and their canonical targets are re-fetched; the task closes when every target returns 200 with a self-referencing canonical.