Ratio de renderizado
El ratio de renderizado es la proporción del texto de una página que ya existe en el HTML que manda el servidor, antes de que se ejecute ningún JavaScript.
Una página al 95 % la puede leer cualquier cosa capaz de descargar una URL. Una al 10 % es un cascarón casi vacío que solo se convierte en página dentro de un navegador, y la mayoría de los rastreadores no son navegadores. Es la comprobación que más webs suspenden.
¿Por qué el ratio de renderizado decide si la IA puede citarte?
Un modelo no navega. Algo descarga tu URL, se queda con el texto que recibe, y ese texto es todo lo que el modelo va a tener de ti. Si tu contenido se monta en el cliente, lo que se queda es una barra de navegación y un estado de carga.
Google es la excepción que causa la confusión. Sí ejecuta JavaScript, en una fase aparte posterior al rastreo, y su propia documentación sigue recomendando renderizar en servidor porque, con sus palabras, no todos los bots pueden ejecutar JavaScript. Los bots que traen respuestas están en su mayoría en ese segundo grupo.
¿Qué ratio de renderizado es bueno?
Se mide como la proporción del texto final presente en el HTML crudo. Los tramos son bastos a propósito: por encima del 90 % la página está prácticamente completa sin scripts, y por debajo del 60 % un rastreador ve algo distinto de lo que publicaste.
- Por encima del 90 % — la página está prácticamente completa sin JavaScript.
- Entre el 60 % y el 90 % — el contenido principal está y hay partes que no. Suelen ser reseñas, precios o pestañas.
- Por debajo del 60 % — un rastreador que no ejecuta JavaScript ve una página distinta de la que publicaste.
- Cerca del 0 % — un cascarón vacío. El sitio existe solo para navegadores.
¿Cómo se arregla un ratio de renderizado bajo?
Renderizado en servidor o generación estática para el contenido que importa, algo que soporta cualquier framework moderno y que la mayoría de los proyectos sencillamente nunca activó. Ni el diseño cambia ni la tecnología: lo que cambia es quién monta el HTML.
Cuando una reconstrucción no está sobre la mesa, el parche barato es servir una versión en texto a quien la pida, por negociación de contenido o con una copia en Markdown documentada. No repara la página, y sí hace que el contenido exista en algún sitio al que un rastreador llegue.
¿Sobre qué se apoya esto?
La documentación de Google es aquí la fuente más fuerte, y es la que suele citarse al revés. Las tres se leen enteras y gratis.
- JavaScript SEO basics, Google Search Central
Documenta las tres fases —rastreo, renderizado, indexación— y afirma que renderizar en servidor sigue siendo buena idea porque no todos los bots pueden ejecutar JavaScript. Esa frase es todo el argumento.
- GEO: Generative Engine Optimization
Mide qué hace visible un contenido dentro de las respuestas generadas. Nada de ello aplica a un contenido que el rastreador nunca recibió.
- La convención llms.txt
El parche parcial habitual: publicar una versión en Markdown de lo que dice la página, para agentes que no van a ejecutar un script.
Preguntas frecuentes sobre Ratio de renderizado
¿Google no ejecuta JavaScript de todas formas?
- Sí lo ejecuta, en una fase de renderizado posterior al rastreo. Eso cubre a Google y no dice nada del resto, y la propia documentación de Google sigue recomendando renderizar en servidor porque no todos los bots pueden ejecutar JavaScript. Optimizar para el único rastreador que renderiza es apostar por el rastreador equivocado.
¿Tener buen ratio de renderizado significa renunciar a React?
- No. React, Vue y Svelte renderizan en servidor, y los frameworks construidos sobre ellos lo hacen por defecto. Un ratio bajo es casi siempre una configuración que nunca se activó, no un límite de la tecnología.