<head>. Drop anything else in there (a div, an img, an iframe) and browsers plus Googlebot quietly close the head early, which can push your canonical, hreflang, and robots tags into the body where they get ignored.What counts as invalid in the head
The HTML spec is strict about this. The <head> may contain exactly eight elements: title, meta, link, script, style, noscript, base, and template. That is the whole list. A div, a p, an img, an iframe, a stray span, even loose text: all of it is invalid head content.
There is one subtlety people miss constantly. noscript is allowed in the head, but when it sits there it may only contain link, style, and meta. The classic Google Tag Manager fallback snippet wraps an iframe in noscript, which is exactly why Google's own install instructions tell you to place it immediately after the opening body tag, not in the head. Half the broken heads I audit trace back to someone pasting that snippet in the wrong spot.
How one stray element silently breaks everything below it
Browsers do not throw an error when they hit invalid head content. The HTML parser assumes you forgot to close the head, closes it for you, opens the body, and keeps going. Googlebot behaves the same way, and Google's Search Central documentation on valid page metadata says so explicitly: when Google encounters an invalid element in the head, it treats the head as ended at that point.
The consequence is brutal. Every tag that appears after the invalid element is now body content. Canonical link elements, hreflang annotations, meta robots, Open Graph tags: Google only honors most of these in the head. I have watched a single Facebook pixel img fallback torpedo an entire hreflang cluster because every alternate annotation sat below it. The tags were in the source, the SEO plugin reported everything green, and Google saw none of it.
Where invalid head elements usually come from
Almost nobody types a div into their head template on purpose. In practice the culprits are:
- Tag manager and pixel fallbacks. GTM's
noscriptiframe and Meta'snoscriptimg pasted into the head instead of the body. - CMS plugins injecting markup. WordPress plugins that echo banners, SVG sprites, or admin notices into
wp_head. One rogue plugin update can break every page on the site overnight. - A/B testing and personalization scripts that document.write markup into the head at runtime, so the raw source looks clean but the rendered DOM is broken.
- Template accidents. An unclosed comment, a misplaced include, or leading whitespace and text nodes from a PHP file saved with a byte order mark.
How to detect it
Do not trust view-source alone. Scripts modify the DOM after load, so you need to check the rendered head as well as the raw one.
- DevTools console, on the rendered page: run
document.head.querySelectorAll('div, p, img, iframe, span, section'). Anything returned is a problem. Also eyeball where</head>lands in the Elements panel: if your canonical shows up inside<body>, the parser moved it. - Screaming Frog: the Validation tab flags invalid HTML elements in the head out of the box, and crawling with JavaScript rendering enabled catches the runtime injections a raw crawl misses. Run it both ways and diff.
- W3C validator: good for pinpointing the exact byte where the head implicitly closed on a single URL.
- Search Console URL Inspection: view the rendered HTML Google actually got and search it for your canonical and hreflang tags. If they appear after
<body>, you have your answer.
How to fix it, step by step
- Find the first invalid element. Everything breaks from that point, so fix in document order.
- Move tracking fallbacks (
noscriptiframe and img snippets) to immediately after the opening<body>tag, exactly where the vendors tell you to put them. - For plugin-injected junk, disable the offender or hook its output to the body. In WordPress, that usually means moving a
wp_headaction towp_body_open. - Reorder what remains so the critical tags (title, meta robots, canonical, hreflang) sit as early in the head as possible. Cheap insurance against the next accident.
- Re-crawl with rendering enabled and re-inspect a few templates in Search Console to confirm the head survives intact.
Reference: what belongs in the head
| Element | Valid in head? | Notes |
|---|---|---|
title | Yes | Exactly one per document |
meta, link | Yes | Where canonical, robots, hreflang, and Open Graph live |
script, style, template | Yes | Fine in the head, watch render blocking for other reasons |
base | Yes | One max, and it rewrites every relative URL, so handle with care |
noscript | Yes, restricted | In the head it may only contain link, style, meta. No iframes, no imgs. |
div, p, img, iframe, text | No | Parser closes the head at the first one it meets |
What good looks like
A clean head is boring: title first, charset and viewport meta, robots, canonical, hreflang set, Open Graph, then stylesheets and scripts, and not a single element outside the allowed eight. The rendered DOM matches the raw source. Screaming Frog's Validation tab comes back empty, and the rendered HTML in Search Console shows every critical tag above </head>. Once it is clean, add the DevTools one-liner to your release checklist so it stays that way.
- Keep the head to the eight valid elements, nothing else
- Place GTM and pixel noscript fallbacks right after the opening body tag
- Audit the rendered DOM, not just view-source
- Put title, robots, canonical, and hreflang as early in the head as possible
- Re-crawl with JavaScript rendering after every fix
- Paste vendor snippets into the head without reading their placement instructions
- Let plugins echo divs, SVGs, or banners into the head template
- Assume a green light from your SEO plugin means Google sees the tags
- Treat validator warnings about head content as cosmetic
- Fix one template and skip the other page types on the site
FAQ
Does an invalid element in the head hurt rankings directly?
My raw source is clean but Screaming Frog still flags the head. Why?
Is noscript allowed in the head at all?
Does Google really stop reading the head at the first invalid element?
What is the fastest way to check a single page?
An invalid head element is one of a few dozen quiet failures that make correct-looking tags invisible to Google. My advanced SEO audit checks the rendered DOM on every template, not just the source.
Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.
About SEO ProCheck
Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.
Work With Me
Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.
Subscribe to our newsletter!
