Prerenderizado

## ¿Qué es el prerendering? Defino el prerendering, en el contexto de SEO, como la entrega a los rastreadores de búsqueda de una instantánea HTML completamente renderizada de una página con mucho JavaScript, de modo que el contenido importante esté disponible en la respuesta inicial. Uso esa definición limitada porque los equipos a menudo lo confunden con server-side rendering, static generation y dynamic rendering de forma más amplia. En el trabajo práctico de SEO, esto importa cuando una aplicación de una sola página (SPA) o un sitio renderizado en el cliente envía primero una carcasa HTML delgada y luego confía en JavaScript para obtener y pintar el contenido real más tarde. Cuando inspecciono sitios con ese enfoque, el patrón de fallos recurrente es conocido: el rastreador solicita la página y recibe poco más que un contenedor vacío, contenido copiado con retraso o metadatos incompletos. El objetivo del prerendering es directo: asegurar que los bots reciban una página que ya contenga el texto principal, los enlaces, los metadatos y los datos estructurados necesarios para el indexado. Esto ayuda a evitar el típico problema del “div vacío” y puede conservar la visibilidad orgánica sin obligar a reconstruir por completo el frontend. Esta definición debe mantenerse precisa. Aquí, el prerendering significa **entregar una instantánea HTML renderizada para el acceso de rastreadores en páginas con mucho JavaScript**. Es más útil cuando los frameworks del lado del cliente ralentizan el rastreo, reducen el descubrimiento de contenido o generan incertidumbre sobre si los elementos importantes de la página están disponibles en el HTML que procesan los bots. ## Por qué el prerendering importa para SEO Google puede renderizar JavaScript, y Google Search Central explica que el SEO con JavaScript depende del renderizado, la disponibilidad de recursos y las etapas de procesamiento. Mi conclusión práctica a partir de esa guía es simple: “Google puede renderizar JS” no es lo mismo que “todos los elementos importantes de la página se verán de inmediato y con fiabilidad”. Esa brecha importa aún más porque no todos los rastreadores tienen las capacidades de renderizado de Google. Bing, las herramientas de auditoría SEO, los scrapers sociales, los bots de disponibilidad y las herramientas de búsqueda interna pueden manejar JavaScript de manera diferente. Eso significa que una página puede estar técnicamente “viva” para los usuarios y, aun así, rendir peor en buscadores porque: - en la primera solicitud el rastreador solo ve una página tipo carcasa - el contenido clave se inyecta demasiado tarde - los enlaces internos quedan ocultos detrás de la ejecución de JavaScript - faltan metadatos o canonicals en el HTML inicial - los datos estructurados están incompletos o se agregan de forma poco fiable El prerendering aborda esos problemas devolviendo de entrada una versión HTML rastreable. En mi experiencia, muchos equipos lo consideran cuando necesitan una mejora de SEO con sentido inmediato, pero sin el costo y el calendario de migrar una SPA a un server-side rendering completo. ## Cómo funciona el prerendering Un flujo típico de prerendering se ve así: 1. Un bot solicita una página impulsada por JavaScript. 2. El servidor o el middleware identifica la solicitud como probable que provenga de un rastreador. 3. En lugar de enviar solo la carcasa de la app JavaScript, el stack devuelve una instantánea HTML renderizada. 4. Esa instantánea incluye el contenido visible, los encabezados, los enlaces internos, los metadatos y, a menudo, los datos estructurados. 5. Los usuarios humanos siguen recibiendo la experiencia normal renderizada en el cliente, a menos que el sitio use rendering universal para todos. Esto se puede implementar con: - un servicio de prerendering como Prerender.io - generación estática a nivel de framework - un pipeline con navegador sin cabeza (headless) que captura instantáneas HTML - lógica en el edge o en middleware que sirve el contenido renderizado a los bots Los detalles de implementación pueden variar, pero el propósito SEO se mantiene igual: los bots obtienen el contenido de inmediato, no después de una ejecución de JavaScript incierta. ## Prerendering vs server-side rendering vs dynamic rendering Estos términos suelen usarse de forma laxa, pero no son idénticos. **Prerendering** suele significar generar una instantánea HTML renderizada con antelación o bajo demanda, y luego servir esa salida ya lista a rastreadores o a solicitudes específicas. **Server-side rendering (SSR)** significa que el servidor renderiza el HTML de la página en el momento de la solicitud para usuarios y rastreadores por igual. Frameworks como Next.js pueden hacerlo de forma nativa. **Static site generation (SSG)** construye páginas como archivos HTML antes del despliegue. Yo lo considero la opción más limpia cuando el contenido cambia de forma predecible y no requiere personalización por solicitud. **Dynamic rendering** es el término de Google para servir contenido renderizado distinto a bots y usuarios cuando JavaScript causa problemas de indexado. Google ha descrito el dynamic rendering como una solución temporal y no como un requisito de largo plazo. En la práctica, el prerendering orientado a rastreadores suele comportarse como una forma de dynamic rendering. ## Cuándo el prerendering es una buena opción Por lo general, vale la pena considerar el prerendering cuando: - tu sitio es un React, Vue, Angular o una SPA similar - los rastreadores obtienen páginas, pero el HTML indexado aparece delgado o incompleto - el contenido importante de productos, categorías o editorial se inyecta del lado del cliente - los enlaces internos no se ven en el HTML “crudo” - las páginas se descubren lentamente pese a tener un buen enlazado - los fragmentos de búsqueda u otros resúmenes generados por buscadores parecen omitir el texto principal - una reescritura completa del framework no es realista a corto plazo Yo lo veo primero como una solución puente. Si el negocio necesita mejor SEO ahora, pero el equipo de ingeniería no puede migrar de inmediato a SSR o SSG, el prerendering puede reducir el riesgo preservando la velocidad de desarrollo. ## ¿Qué debería incluirse en una instantánea prerenderizada? Una instantánea prerenderizada útil debería contener el mismo contenido primario relevante que un usuario normal puede ver en la página. Como mínimo, incluye: - el título de la página y la meta description - las etiquetas canonical - directivas robots cuando corresponda - encabezado principal y texto del cuerpo (body copy) - enlaces internos y rutas de navegación relevantes para el descubrimiento - datos estructurados si se usan - etiquetas de imagen con texto alternativo (alt text) significativo cuando sea relevante - señales de paginación o navegación facetada si aplica No trataría la instantánea como un placeholder reducido. Si el HTML renderizado deja fuera el contenido que quieres indexar, el prerendering no resolverá el problema. ## Beneficios SEO del prerendering Cuando se implementa con cuidado, el prerendering puede ayudar a: - hacer que el contenido sea indexable de inmediato - reducir la dependencia del renderizado de JavaScript con retraso - exponer antes los enlaces internos a los rastreadores - mejorar la consistencia entre lo que obtienen las herramientas y lo que ven los usuarios - habilitar una depuración más rica en herramientas de inspección de URLs y pruebas de rastreo - recuperar la visibilidad perdida por arquitecturas tipo “shell” Estos beneficios no están garantizados. Los resultados dependen de la arquitectura del sitio, los patrones de rastreo, la calidad del contenido, los controles de duplicación y de si el HTML prerenderizado está realmente completo. ## Riesgos y limitaciones El prerendering no es una solución mágica. Limitaciones comunes incluyen: ### Frescura de la instantánea (snapshot freshness) Si el contenido cambia a menudo, las instantáneas obsoletas pueden generar discrepancias entre lo que ven los usuarios y lo que reciben los bots. ### Cuestiones de cloaking (encubrimiento) Servir a los bots un contenido sustancialmente distinto al de los usuarios puede implicar riesgo de cumplimiento. El enfoque seguro es mantener el HTML prerenderizado equivalente en significado y en el contenido principal, sin prácticas manipulativas. ### Deuda técnica Una capa de prerendering se convierte en otro sistema que hay que monitorear, cachear, invalidar y depurar. ### Soluciones parciales Si la arquitectura de información débil, el contenido duplicado o los canonicals deficientes son la causa real, el prerendering por sí solo no resolverá las posiciones. ### Manejo de recursos Si tu instantánea omite directivas críticas, hreflang, datos estructurados o enlaces, puedes empeorar sin querer el SEO. ## Cómo validar el prerendering Usa una mezcla de comprobaciones manuales y con herramientas: - Ver el HTML “crudo” desde una solicitud de rastreador y confirmar que el body copy está presente. - Comparar la instantánea con lo que ve un navegador normal. - Usar la Inspección de URLs de Google Search Console para probar la página en vivo. - Comprobar si los títulos, canonicals y datos estructurados aparecen en el HTML renderizado. - Rastrea el sitio con una herramienta que pueda comparar la salida renderizada vs. la no renderizada. - Revisar logs para confirmar que los bots realmente están recibiendo respuestas prerenderizadas. Cuando diagnostico problemas de prerendering, normalmente empiezo por la respuesta del bot en sí, en lugar de la vista del navegador. La guía de Google sobre SEO con JavaScript y las herramientas de Inspección de URLs son buenas referencias aquí. Si una página sigue indexándose sin el texto clave, el problema puede deberse a instantáneas obsoletas, recursos bloqueados o una canonicalización débil, más que a la renderización por sí sola. ## Mejores prácticas - Mantén el HTML prerenderizado semánticamente equivalente a la página visible para el usuario. - Incluye el texto principal y los enlaces internos en la instantánea. - Invalida o actualiza las instantáneas cuando cambie el contenido. - Preserva canonicals, hreflang, directivas robots y el marcado de schema. - Monitorea las respuestas de los bots, no solo las vistas del navegador. - Trata el prerendering como una capa de compatibilidad duradera o como un puente temporal hacia una arquitectura de renderizado más sólida. ## Conclusión Yo veo el prerendering como una capa de compatibilidad SEO práctica para sitios con mucho JavaScript. Sirve a los rastreadores una instantánea HTML completamente renderizada para que puedan acceder de inmediato a contenido indexable. Para SPAs que, de otro modo, exponen a los bots páginas “shell”, contenedores vacíos o contenido con retraso, eso puede marcar la diferencia entre una página que es rastreable en teoría y una página que es entendible en la práctica. La clave es mantener las instantáneas completas, actuales y alineadas de forma significativa con lo que realmente ven los usuarios.