Glosario DOM
El Document Object Model es la representación que el navegador construye a partir del HTML: un árbol de elementos que se puede leer y modificar con JavaScript. El HTML es el texto que llega; el DOM es lo que el navegador hace con él.
La distinción que más malentendidos evita en SEO técnico: el código fuente y lo que finalmente hay en la página pueden ser dos cosas distintas.
El servidor envía HTML. El navegador lo lee, construye con él un árbol de nodos y, a partir de ese momento, ambos pueden separarse. JavaScript añade elementos, quita otros, cambia textos y atributos. El código fuente sigue igual; la página, no.
Por eso dos comprobaciones habituales dan respuestas distintas: ver código fuente muestra el HTML entregado y las herramientas de desarrollo muestran el DOM actual. Confundirlas es buscar un fallo donde no está.
Google evalúa el DOM renderizado, no el HTML entregado. Lo que añade JavaScript puede contar, pero sólo después del renderizado, que ocurre en una segunda pasada.
De ahí se siguen las dos caras. Un canonical, un título o un noindex puestos sólo por JavaScript pueden surtir efecto, aunque más tarde y sin garantía. Y al revés: un script que inserta un noindex puede sacar una página del índice aunque en el código fuente no haya nada de eso.
Para medir, esto significa que el texto renderizado es la fuente fiable. Una comprobación contra el código fuente responde a una pregunta distinta de la que se suele hacer.
Tres vías, cada una con un alcance distinto:
curl, Ctrl+U): el HTML entregado, sin JavaScript.Al extraer texto conviene un detalle: innerText devuelve lo visible y textContent también lo que CSS ha ocultado. Una frase que aparece cinco veces en el HTML suele estar una sola vez para quien lee.
El tamaño del árbol cuesta. Cada nodo ocupa memoria y cada cambio obliga al navegador a recalcular el diseño y el pintado. Árboles muy profundos o muy anchos vuelven una página perceptiblemente lenta aunque el archivo sea pequeño.
Dos vínculos con las Core Web Vitals: los elementos insertados después que desplazan contenido generan CLS. Y si el elemento principal sólo entra en el árbol tras ejecutarse JavaScript, el LCP se retrasa.
Tomar el código fuente por la página. Quien busca un elemento en el código fuente y no lo encuentra concluye demasiado pronto que falta: puede llevar rato en el DOM. Y al revés, un elemento en el DOM no demuestra que Google lo haya visto.
Medir en el DOM y juzgar el servidor. Quien comprueba con una herramienta que ejecuta JavaScript lo ve todo siempre, y se le escapan justo los casos en que el contenido aparece tarde. Comparar ambas versiones es la comprobación; una sola es la mitad.
Una auditoría técnica revisa esto y el resto en un solo paso.
Solicitar auditoríaEl DOM renderizado. Primero procesa el HTML entregado y después, en una segunda pasada, el resultado tras ejecutar JavaScript. Por eso lo añadido por script puede contar, aunque más tarde y sin plazo comprometido.
Porque el navegador muestra el DOM y «ver código fuente» muestra el HTML entregado. Entre ambos ha corrido JavaScript. No es un error: son dos momentos distintos de la misma página.
No hay un número oficial de Google que sirva como límite. Lo útil es la tendencia: cuanto más profundo y más ancho es el árbol, más caro resulta cada cambio. Si una página se siente lenta sin ser pesada, merece la pena mirar el tamaño del DOM.
Puede funcionar, porque Google evalúa el DOM renderizado, pero añade una dependencia innecesaria: si el renderizado falla o se retrasa, la señal llega tarde o no llega. Un canonical pertenece a la primera respuesta.
innerText devuelve lo que está visible; textContent, todo el texto del subárbol, incluido lo oculto por CSS. Para comprobar qué lee una persona, innerText es el valor correcto. Medir con textContent cuenta texto que nadie ve.