How to check for invalid elements in the <head>

Craig AddymanUpdated 4 November 20266 min read

Why one stray tag matters

Browsers don't throw errors on bad HTML. They repair it. When the HTML parser meets something that can't live in the head, it closes the head right there and starts the body, even though your </head> is further down.

A script that ends up in the body still runs, so that does no harm. SEO tags are different. Everything after the stray element is now in the body, and Google stops reading the head at that point, so those tags can be missed. Google's own guidance on valid page metadata says it treats an invalid element as the end of the head.

<head>
  <meta charset="utf-8">
  <title>Blue Widgets</title>
  <img src="/pixel.gif">
  <link rel="canonical" …>
  <meta name="robots" …>
</head>
<body> …

<head>
  <meta charset="utf-8">
  <title>Blue Widgets</title>
</head> ← closed early
<body>
  <img src="/pixel.gif">
  <link rel="canonical" …> ← now in body
  <meta name="robots" …> ← now in body

Same HTML, two views. This is also why the problem is easy to miss: DevTools shows you the repaired version on the right, not what you shipped.

What usually causes it

It's rarely a developer writing <img> in the head by hand. It's normally something pasted in or injected:

How to check by hand

Three ways. Methods 1 and 3 read the HTML your server sends. Method 2 reads the page the browser built, which is where the damage shows.

Copy// SEO tags that the browser moved out of the head
document.querySelectorAll(
  'body link[rel~=canonical i], body link[hreflang], body meta[name=robots i], body meta[name=googlebot i], body meta[name=description i], body meta[name=viewport i], body meta[charset], body base, body title:not(svg title)'
).forEach(el => console.log(el.outerHTML, '\n  after:', el.previousElementSibling?.outerHTML.slice(0, 120)));

Copy// Lists elements in the server HTML head that don't belong there
const html = await (await fetch(location.href, { cache: 'no-store', headers: { Accept: 'text/html' } })).text();
// Drop comments and the contents of script-like elements first, then keep everything before the body.
const head = html
  .replace(/<!--[\s\S]*?-->/g, '')
  .replace(/<(script|style|noscript|template|title|textarea)\b[\s\S]*?<\/\1\s*>/gi, '')
  .split(/<\/head\s*>|<body[\s>]/i)[0];
const ok = /^(html|head|meta|link|base|script|style|noscript|template|title)$/i;
const bad = [...head.matchAll(/<([a-z][\w-]*)/gi)].map(m => m[1].toLowerCase()).filter(t => !ok.test(t));
console.log(bad.length ? 'Not allowed in <head>: ' + [...new Set(bad)].join(', ') : 'Head looks clean');

What about elements added by JavaScript?

A script can insert a <div> into the head after the page loads. Inserting it that way doesn't re-run the parser, so nothing gets moved and it stays in the head. It's still worth cleaning up, but the server HTML is the part that pushes your tags out, so start there. The exception is document.write, which old pixel tags still use: it writes into the parser while the page loads, and can end the head just like server HTML.

So if methods 2 and 3 both come back clean but a tool still reports an <iframe> or <img> in the head, a script almost certainly added it. To see what's there, paste:

Copy// Elements in the live head that don't belong there (including ones added by scripts)
const ok = /^(meta|link|base|script|style|noscript|template|title)$/i;
[...document.head.children].filter(el => !ok.test(el.tagName))
  .forEach(el => console.log(el.outerHTML.slice(0, 200)));

The src usually tells you which tag or vendor added it. With the server HTML clean and nothing printed by method 2, it's low priority: tidy it up through the tag manager or app settings when you can.

Two related head problems

How to fix it

1. Move the stray element into the body. For tag manager and pixel fallbacks, put the <noscript> part straight after the opening <body> tag.
2. If you can't move it (a locked app or plugin), move your title, meta description, canonical, robots and hreflang tags above it, as near the top of the head as you can.
3. Check again with method 2. The list should come back empty.

On Shopify, WordPress and Next.js

• Shopify: Go to Online Store > Themes, open Edit code and read the head in theme.liquid. Apps often add code there, so if the stray element isn't in the file, check recently installed apps.
• WordPress: Anything hooked to wp_head can print into the head. Disable plugins one at a time on a staging site until the stray element disappears, then check the theme's header.php.
• Next.js: Since version 15.2, metadata from generateMetadata can be streamed and added to the <body>, so a check can report it outside the head. Next.js says Googlebot reads it correctly. To keep it in the head for every visitor, set htmlLimitedBots: /.*/ in next.config.js, though that can slow responses.

How crawlers report this

If a crawl sent you here, these are the labels to look for. Our guide to Screaming Frog and Sitebulb issues covers other common ones.

Related checks