Canonical declared in both HTML and the HTTP header
canonical_both_methodsShort answer
Both a <link rel="canonical"> and a Link: <…>; rel="canonical" header are present, with the same URL. Nothing is wrong today. Google notes that using both methods together is more error-prone — the day they disagree you get the conflicting canonicals issue — so consider keeping one.
Why it matters
The HTTP header method exists for non-HTML files (PDFs) and for cases where you cannot edit the HTML. On an HTML page it only adds a second place that must be kept in sync. This is informational and does not affect the health score.
How Glimana detects it
The crawler sees a canonical in both places with identical normalised URLs.
How to fix it
- Find the affected pages in Glimana. Open Issues › Canonical declared in both HTML and the HTTP header. 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.
Keep one canonical source. For HTML pages the
<link rel="canonical">in the document is the one you control page by page; remove theLink: <…>; rel="canonical"HTTP header for HTML responses (it is typically added at the CDN or web server) and keep the header for non-HTML files such as PDFs, where it is the only option. If both come from the same source and always agree, you can leave them, but every future change then has to be made in two places.The header is not added by WordPress itself; look at the host (some managed hosts and Cloudflare APO add it), a security/CDN plugin, or an
.htaccessHeader set Linkrule. Remove it there and keep the SEO plugin's tag.Shopify does not send a Link canonical header; if you see one, it comes from a proxy or Cloudflare rule in front of the store.
Remove the header for
text/htmlresponses in the web server or middleware; keep it for PDFs and other non-HTML assets. -
Publish and clear caches. Apply the server or CDN change (reload Nginx/Apache, save the Cloudflare rule), purge the cache, then check the live response with
curl -sI https://your-domain/page— the status line and headers you see there are exactly what Glimana and Googlebot get. - 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 the page declares its canonical in one place only. 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
Re-crawl; the task closes when the page declares its canonical in one place only.