glimanaDocs Open Glimana →

Issue guide · Indexability

Canonical is outside <head> (Google ignores it)

SeverityHigh
CategoryIndexability
ScopePer page
EffortSmall
Verified byRe-crawl after you mark the task done
Rule keycanonical_outside_head

Short answer

Google accepts rel=canonical only inside <head>. Yours ends up in <body> — usually because an <img>, <div>, <iframe> or similar element appears inside <head> and makes the browser (and Google) close the head early. Move that element into the body, or move the canonical above it.

Why it matters

HTML parsers close <head> the moment they meet an element that is only allowed in <body>. Everything after it — your canonical, hreflang, sometimes even the title — is parsed as body content. Google explicitly disregards a canonical in the body. The page then has no canonical at all, and on sites with parameter duplicates that means signals split between versions. The cause is often an analytics or chat snippet pasted into the head with an <img> or <noscript><iframe> fallback.

How Glimana detects it

The crawler parses the HTML the way a browser does and records where the canonical element ends up. The rule fires when the canonical is found in the body; the evidence names the first invalid element that closed the head (for example img or div), when one was found.

How to fix it

  1. Find the affected pages in Glimana. Open Issues › Canonical is outside (Google ignores it). 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.
  2. Apply the fix on your platform.

    Find the element named in the evidence and move it. Tag snippets with <noscript><img …></noscript> (Facebook pixel, some ad tags) belong at the top of <body>. Alternatively, place the canonical and hreflang links before any third-party snippets in the head, so they are parsed before the head is closed.

    Snippets are usually injected by a "Header and Footer scripts" plugin or the theme's Theme Options → Header code field. Move pixel code to the Body field. If a plugin outputs the element, update it or set its position to body.

    Look in theme.liquid and in app-injected code (Online Store → Themes → Customize → App embeds). Move pixel <noscript> blocks below <body>.

    Validate templates with the W3C validator; it reports "Element img not allowed as child of element head". Keep the head to meta, link, title, style and script elements.

  3. 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.

  4. 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 canonical is parsed inside <head>. 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 the canonical is parsed inside <head>.

Sources