Broken HTML can silently shift or destroy SEO signals - and AI crawlers like GPTBot or PerplexityBot often see only the initial HTML without server-side rendering, missing any content loaded via JavaScript. Search Off the Record Episode 105 with Gary Illyes and Martin Splitt delivers the most grounded analysis of HTML parsing and SEO in years.
- Canonical and robots in the body: Google ignores these directives when they appear in the body instead of the head - a single script injecting an iframe can silently push them out of place. For hreflang, incorrect placement can also break language assignment.
- Resource hints don’t help Googlebot crawl: dns-prefetch, preload, and preconnect are designed for browser performance - Google’s crawling infrastructure doesn’t benefit from them directly.
- AI crawlers and JavaScript: GPTBot, ClaudeBot, and PerplexityBot reportedly don’t render JavaScript and only see the initial HTML. Using pure CSR risks making your content invisible to these systems.
- HTML validity is not a ranking factor: Technically invalid HTML doesn’t directly impact rankings, but broken markup can break canonical, hreflang, and robots directives.
When did you last look at the rendered HTML of your website - not the source code, but what the browser actually produces after parsing?
If the answer is “never” or “it’s been a while,” you should keep reading. In Episode 105 of the Search Off the Record podcast (February 26, 2026), Martin Splitt and Gary Illyes from Google’s Search Relations team explained how browsers parse HTML - and why this matters for SEO. The findings surprise even experienced SEOs: much of what gets recommended as “best practice” in technical audits has zero influence on crawling or rankings, according to Google.
In 2026, there’s a second dimension: AI search systems like ChatGPT, Perplexity, and Claude send their own crawlers - and these are far more rigid about JavaScript rendering than Googlebot. Optimize only for Google, and you risk being invisible to everyone else.
In this article: How the HTML parser really works, where it silently destroys SEO signals, why AI crawlers introduce a new problem - and what you can actually do about it.
How Browsers Actually Parse HTML
Once your browser receives an HTML document, it starts building the DOM (Document Object Model) - a tree structure representing all page elements hierarchically. The HTML parser works sequentially through the source code, analyzing each element and inserting it into the DOM tree.
What many don’t realize: the HTML Living Standard is extremely lenient. Missing closing tags, incorrectly nested elements - the parser tries its best to handle them rather than giving up. This isn’t a bug, it’s by design: web pages from the 90s still in circulation need to render correctly.
What happens with CSS and JavaScript?
When the HTML parser encounters a <link> tag for a stylesheet or a synchronous <script> tag, it often has to pause. The browser needs to download and process the CSS, or download and execute the JavaScript, before parsing can continue. This is called “render-blocking.”
After building the DOM, the browser also creates the CSSOM (CSS Object Model). DOM and CSSOM together form the Render Tree - the foundation for the page’s visual presentation.
Why is parser leniency a problem?
Because Google doesn’t always end up with the same result as your browser. In Episode 105, Splitt and Illyes explained exactly this: the “healing” of broken HTML by the parser doesn’t always produce the same result as in your browser. The order of resources in the head and body determines where the parser closes the head section - with potentially severe consequences for SEO signals like canonical and hreflang.
Googlebot vs. Your Browser: What’s Different?
Google uses a headless Chromium browser - the same engine as Chrome, but without a visible interface. Still, there are fundamental differences between what your browser and what Googlebot does with a page:
| Aspect | Browser (Chrome) | Googlebot |
|---|---|---|
| Rendering | Immediately on page load | Two-stage: crawl first, then rendering |
| JavaScript | Executed immediately | Separate rendering queue |
| Resource caching | In real-time | Cached separately, not in sync |
| DNS/Network | Depends on user connection | Google’s internal infrastructure |
| User interaction | Clicks, scrolling, hover | None - initial DOM only |
| HTML limit | No practical limit | Very large HTML documents may only be partially crawled |
Googlebot first crawls the raw HTML and extracts links and basic information. JavaScript rendering follows in a separate step. Gary Illyes emphasizes that Google caches page resources separately “to spare the servers of crawled websites.”
Important: Content that only becomes visible through user interaction - tabs, accordion elements, hover tooltips - doesn’t exist for Googlebot. For crawling and indexing, only what’s in the initial DOM counts.
The Head-Closing Trap: When Meta Tags End Up in the Body
What happens?
The HTML parser closes the <head> section immediately when it encounters elements that don’t belong there. Martin Splitt describes a concrete case in Episode 105: a spec-compliant script tag in the head injected an <iframe> element via JavaScript. Since iframes aren’t allowed in the head, the parser immediately closed the head section. All subsequent <link> and <meta> tags ended up in the body.
In the source code, everything looked correct. The rendered DOM told a different story.
Why is this fatal?
Gary Illyes is clear: Google ignores meta name="robots" tags and rel="canonical" link elements that appear in the body. According to the HTML Living Standard, these belong exclusively in the head. Illyes warns that “it would be dangerous if Google accepted canonical tags in the body - because then someone could hijack the canonical of a foreign page through markup injection.”
For hreflang tags, the picture is slightly different: the strict “body = ignored” rule applies clearly to canonical and robots-meta. With hreflang, incorrect placement caused by head-closing can disrupt language assignment - verify via URL Inspection Tool.
How to check: Open the URL Inspection Tool in Google Search Console for your most important pages and click “View crawled page.” Search there for canonical and hreflang. Alternatively: Chrome DevTools → Elements tab → check whether tags appear under <head> or <body>.
Resource Hints: Why Googlebot Ignores Them
Resource hints are frequently recommended as performance optimizations. Gary Illyes explains in Episode 105 why Googlebot doesn’t benefit from them: Google’s crawling infrastructure operates internally and doesn’t have the latency problems these tags were designed to solve.
Specifically: DNS resolution at Google is so fast that dns-prefetching provides no advantage. Since Googlebot doesn’t load resources synchronously like a browser, preload has no direct effect on crawling behavior either.
This doesn’t mean resource hints should be removed. They still improve browser performance and thereby indirectly affect metrics like Largest Contentful Paint - which in turn influences Core Web Vitals. But they’re not designed to influence Googlebot’s crawling behavior.
AI Crawlers and Server-Side Rendering
While Googlebot supports JavaScript rendering via headless Chromium, third-party analysis suggests a different picture for AI crawlers: an analysis of over 500 million GPTBot requests found no evidence of JavaScript execution. Independent testing points to similar behavior for ClaudeBot and PerplexityBot - official confirmation from the respective providers is still pending.
What does this mean in practice? A Single Page Application (SPA) that loads content exclusively through JavaScript often delivers only the initial HTML shell to these crawlers - without text content, internal links, or structured data. Whether this is complete or situational may change; SSR remains the safe path.
| Crawler | JavaScript Rendering | Powers System |
|---|---|---|
| Googlebot | Yes (headless Chromium) | Google Search, AI Overviews |
| GPTBot | No (per third-party analysis) | ChatGPT, SearchGPT |
| ClaudeBot | No (per third-party analysis) | Claude |
| PerplexityBot | No (per third-party analysis) | Perplexity |
| Bingbot | Limited | Bing, Copilot |
That AI bot traffic is growing rapidly is well documented - specific percentages vary significantly by source and site. More concrete: a case study found that after switching a SPA to server-side rendering, the share of AI bots in total traffic increased substantially, because the content was finally accessible in the initial HTML.
Server-Side Rendering as the solution
Server-Side Rendering (SSR) solves the problem: the server generates complete HTML including all content before sending it to the browser or crawler. On the first request, Googlebot and every AI crawler see the same complete content.
Modern frameworks support SSR natively: Next.js (React), Nuxt (Vue), and Angular Universal deliver interactive pages whose content is still present in the initial HTML. For websites without a framework environment, Static Site Generation (SSG) or prerendering is a pragmatic alternative.
HTML Validity and Semantic Markup: What Google Really Cares About
Gary Illyes is clear: HTML validity is not a ranking factor. His reasoning is logical: validity is binary - either valid or not. Google couldn’t meaningfully rank pages against each other using that signal.
But the distinction matters: valid HTML is not a ranking signal - but broken HTML can cause other SEO signals to stop working correctly. That’s not a contradiction. A page can be technically invalid and still have perfect SEO directives. Or it can be “valid” but have canonical tags that end up in the body.
Semantic HTML
Martin Splitt is surprisingly pragmatic: correct heading hierarchy and HTML5 structural elements like <article>, <section>, or <nav> carry no direct weight for Google rankings according to Splitt - but are valuable for accessibility and screen readers.
AI search and semantic structures
For AI search systems, different logic applies. Google’s AI Overviews, ChatGPT, and Perplexity process web content in semantic blocks. Clear HTML structure - clean heading hierarchy, <article> wrapping, structured lists - helps these systems accurately extract content and cite it as a source.
This isn’t a ranking factor, but it’s a factor for visibility in AI-generated answers. Anyone who wants to appear in AI Overviews or ChatGPT responses benefits from clean semantic HTML - complemented by an understanding of how Google’s algorithm works from crawling to ranking.
<head> or at the end of the <body> should always be correctly implemented.
Your Checklist: HTML Parsing for Better Rankings
| Step | Action | Priority |
|---|---|---|
| 1 | URL Inspection Tool: Are canonical and hreflang still in <head> in the rendered HTML? |
Critical |
| 2 | Check whether scripts in the head inject iframes or body elements that trigger head-closing | Critical |
| 3 | Ensure all important content is present in the initial HTML without JavaScript | High |
| 4 | Implement SSR or prerendering for JavaScript-heavy pages (AI crawler visibility) | High |
| 5 | Move non-critical JavaScript to the body end or use defer consistently |
Medium |
| 6 | Inline critical CSS in the head to minimize render-blocking | Medium |
| 7 | Optimize server performance: TTFB, cache headers, ETags - instead of resource hints | Medium |
| 8 | Test Core Web Vitals - especially LCP and INP reveal parsing-related issues | Medium |
| 9 | Create llms.txt and configure AI crawlers correctly in robots.txt | Optional |
Frequently Asked Questions (FAQ)
Does Google understand JavaScript the same way a regular browser does?
Fundamentally yes - Google uses headless Chromium and can process most JavaScript features. However, Googlebot renders pages with a delay in a separate rendering queue. Content that only appears through user interaction isn’t captured. Google’s JavaScript SEO Basics provide a good overview. AI crawlers like GPTBot and PerplexityBot reportedly don’t execute JavaScript according to current third-party analysis - official confirmation is pending.
How do I find out if my meta tags are ending up in the body?
Easiest via Chrome DevTools: open the page, click “Inspect,” and search the Elements tab for canonical or hreflang. If it appears under <body> instead of <head>, there’s a parsing problem. Alternatively, the URL Inspection Tool in Search Console shows the rendered HTML - search for the tags there under “View crawled page.”
Do AI crawlers like GPTBot or PerplexityBot render JavaScript?
Based on current third-party analysis: reportedly not. An analysis of over 500 million GPTBot requests found no evidence of JavaScript execution; independent testing suggests similar behavior for ClaudeBot and PerplexityBot. Anyone using pure client-side rendering without SSR risks delivering only an empty HTML shell to these crawlers. Server-side rendering or prerendering is the safe approach.
Is HTML validation a waste of time?
Not a ranking factor, but not pure time-wasting either. Gary Illyes explains that Google can’t do anything with a binary valid/invalid signal. But validation helps find parsing errors that break critical SEO directives - exactly the head-closing problems described in this article. Use the W3C Validator selectively for your most important pages, not as a ritual for every page.
Do resource hints like preload or dns-prefetch provide SEO benefits?
For crawling and indexing, no. Google’s infrastructure doesn’t have the latency problems these tags solve. For user experience and Core Web Vitals, they can be useful - but that’s browser performance, not crawling performance. More important: correct cache headers, low TTFB, and clean HTTP status codes.
What’s the difference between source code and the rendered DOM?
Source code is what your server delivers - unchanged. The rendered DOM is the result after parsing and JavaScript execution by the browser. An element that correctly sits in <head> in the source code can end up in <body> after parsing - if a script previously closed the head section. You can’t see this problem in the source code.
Conclusion: What Really Matters in HTML Parsing
Search Off the Record Episode 105 clears up myths: HTML validity is not a ranking factor, resource hints help users but not Googlebot, semantic HTML is not a direct ranking signal. That sounds like relief - and partly is.
But there’s a flip side: broken parsing can silently destroy canonical, hreflang, and robots directives without any error appearing in Search Console. And with the rise of AI search comes a second problem: crawlers that can’t execute JavaScript, for which client-side rendered content simply doesn’t exist.
The practical first step for today: open the URL Inspection Tool for your most important pages and specifically check whether canonical and hreflang are still in the head. Then check whether your core pages deliver complete content without JavaScript rendering. For everything else - resource hints, HTML validation - the verdict is: nice to have, but not the lever that moves rankings.
More on how to configure crawlers and optimize AI visibility in the robots.txt guide and the article on Google’s algorithm from crawling to ranking.
- URL Inspection Tool → view rendered HTML → canonical and hreflang in head?
- Chrome DevTools → Elements tab → rule out head-closing through script injection
- Important content in the initial HTML response (no pure CSR)
- Server-side rendering or prerendering for JavaScript-intensive pages
