Robots Meta Tag Placement: Head, Body and Conflicting Rules
In this article
Robots meta tag placement is less strict than most guides make it sound. Google Search does not enforce placement in the HTML head and respects robots meta tags in the body as well. So a stray noindex anywhere in the page counts. Anywhere. If your theme or page builder spits these tags out in odd places, read on: below is what Google documented, how conflicting rules resolve, how to hunt down unwanted tags, and when a response header is the better tool.
Does robots meta tag placement matter to Google?
Less than you’d think. The documentation still tells you to place the tag in the <head> section, but Google Search processes robots meta tags found outside the head too. On March 24, 2026 Google added a note to the robots meta tags documentation describing how Search handles these tags outside the HTML head, as recorded in the Search Central documentation changelog. The behavior didn’t change, it just was never written down before. So nothing new needs fixing. Auditing, yes.
Keep the head as your standard location: that is what the guidance recommends and what other tools expect. But stop thinking of the body as a place where the tag gets ignored.
Why a noindex in body is a real risk
A robots meta tag in body is obeyed, so a noindex injected mid-page can remove the URL from search results. It usually rides in with code the site owner does not control:
- plugins that print their own indexing rules,
- widgets and page builder blocks,
- embedded templates copied from another site or a staging environment,
- JavaScript that writes tags after the page loads.
Broken head markup is another common culprit. When an element that does not belong in the head shows up there, the parser can close the head early and push everything after it into the body. Your robots tag now sits in the body while the template source still shows it in the head, so it is easy to miss.
Canonicals behave the opposite way. For a canonical tag in head only is the rule: rel=canonical is accepted in the head and nowhere else. So the same misplacement that keeps a noindex alive gets a canonical ignored. A page consolidating trailing slash duplicates can silently lose that signal while a restrictive directive keeps working.
Conflicting robots meta tags: which rule wins?
The more restrictive one. When robots rules conflict, noindex beats index. Rules may be combined in a comma-separated list or in separate meta tags, as described in Google’s robots meta tag specifications.
Conflicts also crop up across locations: a tag in the head can disagree with one in the body or with an X-Robots-Tag header. Google obeys any noindex, wherever it is found.
So adding an “index” tag in the head does not cancel a noindex elsewhere. The stray directive has to be removed at its source.
How to find stray noindex tags on your pages
Compare the raw source with the rendered HTML, because tags injected by JavaScript appear only after rendering. I’d work in this order:
- Search the page source for name=”robots” and for crawler-specific names such as googlebot.
- Inspect the rendered HTML with URL Inspection in Search Console and repeat the search there.
- Check the response headers for X-Robots-Tag.
- Disable plugins, widgets or builder modules one by one until the tag disappears.
- Retest the live URL after the fix.
Go through your SEO plugin settings too, including the per-template and per-post-type toggles that output noindex for archives, tags or attachment pages.
One catch: a page disallowed in robots.txt is not crawled, so its indexing rules will not be found and are ignored. How the two mechanisms differ is explained in noindex and disallow compared, and that difference decides whether your directive is ever read at all.
When to use the X-Robots-Tag header instead
Use the X-Robots-Tag response header for non-HTML resources such as PDF, video or image files, where a meta tag is not possible. Any rule usable in a robots meta tag can also be specified this way.
The header is set in the web server configuration and can apply rules globally with regular expressions. On your own NGINX origin, that means a location block matching the file extensions you want to cover, with an add_header line that sends X-Robots-Tag and the noindex value.
- Meta tag - individual HTML pages where you control the template.
- Response header - files without HTML markup and site-wide patterns.
If your hosting sits behind Jalvo, an NGINX reverse proxy with EU and USA IP addresses, the header is still configured on the origin server. After any change, request the public URL and check the response headers.
The short version of robots meta tag placement: the head is the convention, the body is still obeyed, and the most restrictive rule wins. Audit the rendered HTML and the response headers, not just the template you wrote.
FAQ
Does Google obey a noindex placed in the body?
Yes. Google Search does not enforce head placement and respects robots meta tags in the body too. This is not new, it was only documented recently.
What happens if a page has both index and noindex?
The more restrictive rule applies, so the page is not indexed. A second tag saying “index” does not override the first. Remove the unwanted directive at its source.
Can I block a PDF from indexing with a robots meta tag?
No. Non-HTML files cannot carry a meta tag, so they need the X-Robots-Tag response header set on the web server. The URL must also stay crawlable, because a file blocked in robots.txt is never fetched.
