The DOM (Document Object Model) is the live, structured version of a web page that a browser builds in memory from the HTML, and that scripts can read and change. When SEOs talk about the “rendered DOM”, they mean the page as it exists after JavaScript has run, which can be quite different from the HTML file the server sent.
How the DOM works
A browser receives HTML as plain text and parses it into a tree of nodes: the document at the root, then the head and body, then headings, paragraphs, links and images nested inside them, down to individual pieces of text. That tree is the DOM. CSS is applied to it to work out what appears where, and JavaScript can add, remove or rewrite any node at any time.
This is why viewing the source and inspecting an element show different things. View source shows the original HTML response. The Elements panel in Chrome DevTools shows the current DOM, including everything scripts have inserted since: a product grid fetched from an API, a review widget, a cookie banner or, on a fully client-side app, almost the entire page.
Google works the same way. Googlebot fetches the HTML, queues the page for rendering in a recent version of Chromium, and indexes the rendered result. Rendering usually follows quickly, but it is a second step that can fail or time out, and some other crawlers, including several AI crawlers, do not run JavaScript at all.
Why it matters
Search engines can only rank what ends up in the version of the page they process. If the main copy, internal links or structured data exist only after a script runs, you depend on that script working for every crawler. Content that loads only after a click, or only when a scroll event fires, may never be seen, because crawlers do not click buttons or scroll the way people do. Links built as buttons with JavaScript click handlers, instead of proper anchor elements with an href attribute, are generally not followed.
DOM size affects speed as well. Page builders often wrap each visible element in several layers of containers, producing pages with thousands of nodes. A large, deep DOM takes longer to style and lay out, uses more memory on mid-range phones and makes every tap slower to respond, which shows up in Interaction to Next Paint. Lighthouse flags an excessive DOM size for exactly this reason.
Common mistakes
- Checking only the source. Auditing raw HTML misses problems scripts introduce, such as a second canonical tag or a noindex added by a plugin.
- Checking only the rendered DOM. The reverse mistake: a page that looks complete in DevTools may send almost nothing in its HTML, leaving non-rendering crawlers with an empty shell.
- Tabs and accordions that fetch content on click. Text tucked into an accordion is fine if it is in the DOM on load; text loaded only when someone clicks is not.
- Bloated page builder markup. Ten nested wrappers around a single heading slow every page that uses the template.
- Scripts that rewrite titles or meta tags. When the rendered value differs from the HTML value, you cannot be sure which one each search engine uses.
How to act on it
Compare the two versions of your key templates. In Google Search Console, the URL Inspection tool’s “View crawled page” option shows the HTML Google rendered. Set it beside your source HTML and check that the main content, headings, internal links, canonical and structured data are present without depending on any user action. A crawler such as Screaming Frog can do the same at scale with JavaScript rendering switched on and will list content that exists only in the rendered version.
Where important content relies on client-side scripts, consider moving it into the server response through server-side rendering or static generation. Trim DOM size by simplifying page builder sections and removing unused widgets, and use semantic HTML so the structure carries meaning. If you are unsure where the gaps are, a technical SEO audit includes a rendered-versus-source comparison for each template.