Rendering: What, how, why

Resumen de la ponencia

Por primera vez en la historia de Andalu-SEO, un representante de Google subió al escenario. Martin Splitt, del equipo de Search Relations de Google en Zúrich y referente mundial en renderizado, indexación y rastreo, dedicó su ponencia a explicar el renderizado desde tres ángulos: qué es, cómo lo hace la Búsqueda de Google y por qué importa (y cómo comprobarlo en tu propio sitio). Antes de entrar en materia, despachó una pregunta recurrente: el llms.txt no recibe ningún tratamiento especial por parte de los sistemas de Google; Chrome lo incluyó en Lighthouse por si otros agentes lo usan en el futuro, pero a día de hoy no hace gran cosa.

¿Qué es el renderizado?

En esencia, renderizar es convertir texto (el HTML del que está hecha una web) en píxeles. Martin lo explicó con la analogía de la receta y el plato final: el HTML, el CSS y las imágenes son los ingredientes; el navegador es quien cocina las tortitas. Y con el dibujo de una casa a partir de una especificación ("dos pisos, tejado puntiagudo, tres ventanas, una puerta") demostró que los mismos ingredientes producen resultados distintos según el dispositivo, el tamaño de pantalla o la orientación: ahí reside precisamente el poder de la web.

Los conceptos clave del proceso:

• El DOM (Document Object Model) es el "modelo mental" del navegador: el árbol que se construye a partir del HTML y que sobrevive a todo lo que ocurre después, incluido el JavaScript. Es la masa de las tortitas.
• El árbol de renderizado combina DOM y CSSOM y añade el layout: dónde va cada cosa y qué tamaño tiene en pantalla.
• Para indexar, Google usa el DOM (el contenido) junto con el árbol de renderizado (tamaño y posición visual de las cosas). Nada en el DOM indica si un contenido vino en el HTML original o fue inyectado por JavaScript, y a Google le da exactamente igual: si está ahí, es indexable y puede posicionar.

A quien sí le importa el JavaScript es al usuario: un script mal usado puede bloquear el hilo principal del navegador durante un segundo entero, convirtiendo la experiencia en algo lento y frustrante. Para medir eso existen los Core Web Vitals.

Cómo renderiza la Búsqueda de Google

Martin describió la infraestructura real: una URL se descubre (enlaces, sitemaps, Search Console), entra en la cola de rastreo, el crawler —"básicamente un curl o wget muy optimizado"— descarga el HTML, el procesamiento evalúa códigos de estado y canónicos, y lo que no se ha visto antes pasa a la cola de renderizado. Y aquí desmontó un mito histórico: según sus propios logs, el 90% de las URLs pasa solo unos minutos en la cola de renderizado. Donde las URLs pasan horas o días es en la cola de rastreo. El renderizado no es el cuello de botella que la comunidad SEO creía.

Otro dato clave: desde 2019-2020, Google renderiza prácticamente todas las URLs con una instancia de Chromium headless. Renderizar páginas sin JavaScript no cuesta nada, y mantener heurísticas para decidir qué renderizar solo añadía bugs. Por tanto, si algo "rastreado pero no indexado" no aparece, la culpa casi nunca es del renderizado: puede ser un problema de rastreo, de APIs bloqueadas a los bots en aplicaciones client-side, o simplemente de calidad del contenido. En el turno de preguntas fue muy franco al respecto: la mayoría de páginas no indexadas no lo están "porque son malas" o porque ya hay muchas páginas que responden lo mismo — cuanta más competencia, más difícil es que algo nuevo merezca ser indexado.

¿Cómo comprobar si tienes un problema de JavaScript? Sencillo: la herramienta de inspección de URLs de Search Console. Miras el HTML renderizado de tus páginas importantes: si el contenido está ahí, no tienes problema de JavaScript; si falta, lo tienes.

Estrategias de renderizado para el dueño de la web

La segunda mitad abordó el renderizado desde la perspectiva del propietario del sitio: da igual si usas WordPress, Shopify o lo que sea, siempre hay plantillas y datos, y renderizar es decidir dónde y cuándo meter los datos en las plantillas:

• Pre-renderizado / generación estática: si el contenido cambia poco y de forma controlada, un generador de sitios estáticos produce HTML plano. Rapidísimo y prácticamente imposible de hackear, pero muy rígido.
• Server-side rendering: el servidor genera el HTML en cada petición (ideal para contenido que cambia, como reseñas), con la posibilidad de cachear si el contenido solo cambia cada pocos minutos u horas.
• Client-side rendering: máxima flexibilidad e interactividad, pero también la mayor probabilidad de que algo falle, porque no controlas el navegador, la batería ni la red del usuario.
• Hidratación: el enfoque híbrido. Su consejo fue tajante: mucha complejidad y mucho código; "simplemente no lo hagas".

¿Cuál es la correcta? Depende de lo que quieras hacer y de los recursos disponibles. No hay bala de plata: hay que entender el mecanismo para elegir con criterio.