Glossary DOM
The Document Object Model is the representation a browser builds from the HTML: a tree of elements that JavaScript can read and change. The HTML is the text that arrives; the DOM is what the browser makes of it.
The distinction that clears up most misunderstandings in technical SEO: the source code and what ends up on the page can be two different things.
The server sends HTML. The browser reads it, builds a tree of nodes from it — and from that moment the two can diverge. JavaScript adds elements, removes others, changes text and attributes. The source stays the same; the page does not.
That is why two common checks give different answers: view source shows the delivered HTML, developer tools show the current DOM. Confusing them means looking for a fault in the wrong place.
Google evaluates the rendered DOM, not the delivered HTML. So what JavaScript adds can count — but only after rendering, which happens in a second pass.
Both consequences follow. A canonical, a title or a noindex set only by JavaScript may well take effect — just later and without a guarantee. And in reverse: a script that inserts a noindex can remove a page from the index although the source says nothing of the sort.
For measurement this means the rendered text is the reliable source. A check against the source code answers a different question from the one usually being asked.
Three routes, each saying something different:
curl, Ctrl+U) — the delivered HTML, without JavaScript.When reading text out, one detail pays off: innerText returns what is visible, textContent also what CSS has hidden. A sentence that appears five times in the HTML is often there just once for the reader.
The size of the tree costs. Every node takes memory, and every change forces the browser to recompute layout and paint. Very deep or very wide trees make a page noticeably sluggish even when the file is small.
Two links to Core Web Vitals: elements inserted afterwards that push content around produce CLS. And if the main element only enters the tree after JavaScript runs, LCP moves later.
Taking the source for the page. Looking for a missing element in the source and not finding it, you conclude too early that it is absent — it may long since be in the DOM. And in reverse, an element in the DOM does not prove Google saw it.
Measuring in the DOM and judging the server. Checking with a tool that runs JavaScript, you always see everything — and miss exactly the cases where content appears late. Comparing both versions is the check; either one alone is half of it.
A technical audit covers this and everything else in one pass.
Request an auditThe rendered DOM. It first processes the delivered HTML, then in a second pass the result after JavaScript has run. That is why script-added content can count, only later and with no committed timeframe.
Because the browser shows the DOM and «view source» shows the delivered HTML. JavaScript ran in between. This is not a fault but two different moments of the same page.
There is no official Google number that works as a limit. What helps is the direction: the deeper and wider the tree, the more expensive each change. If a page feels sluggish without being heavy, the DOM size is worth a look.
It can work, because Google evaluates the rendered DOM, but it adds an unnecessary dependency: if rendering fails or lags, the signal arrives late or not at all. A canonical belongs in the first response.
innerText returns what is visible; textContent returns all text in the subtree, including what CSS hides. To check what a person reads, innerText is the right value. Measuring with textContent counts text nobody sees.