SEO con JavaScript: renderizado en servidor e indexación
¿Puede posicionarse un sitio JavaScript? Qué hace el renderizado en servidor, cómo surgen los problemas de indexación y los errores que restan visibilidad.
Equipo de rabbitclipPublicación: 8 min. de lectura
En breve
Un sitio construido con JavaScript puede aparecer en las búsquedas, pero el posicionamiento y la indexación son más frágiles cuando el contenido se dibuja en el navegador, porque un buscador recibe primero la página como HTML en bruto, y ejecutar el JavaScript para ver el contenido real es un paso separado y posterior. Si el contenido, los títulos, los enlaces y las etiquetas meta ya están en el primer HTML, ese retraso deja de importar. El camino para lograrlo es el renderizado en servidor o las páginas generadas de antemano.
El problema no es JavaScript en sí, sino un contenido que depende de él. Dos sitios construidos sobre el mismo framework pueden comportarse de forma muy distinta en las búsquedas, porque uno prepara la página en el servidor y el otro envía una cáscara vacía y deja el contenido al navegador.
A continuación explicamos cómo procesa un buscador una página JavaScript, qué método de renderizado conviene a cada negocio y los errores que vemos con más frecuencia.
¿Cómo procesa un buscador una página JavaScript?
El proceso tiene más o menos tres pasos. El buscador rastrea la dirección y recibe el HTML en bruto, la página entra en una cola de renderizado y, cuando le llega el turno, se ejecuta el JavaScript para producir la página final, que entonces se indexa. Google realiza este renderizado con un motor de navegador actual, pero el paso es independiente y puede intercalarse una espera.
Por eso una página sin nada en su HTML en bruto parece vacía a primera vista. El contenido llega más tarde, pero el tiempo en la cola varía de una página a otra. Para una página de noticias o de stock que cambia a menudo, esa espera significa que el contenido aparece tarde.
No todos los buscadores ni todos los rastreadores de IA renderizan igual de bien. Algunos no ejecutan nada de JavaScript, o solo una parte. Un contenido que aparece únicamente tras el renderizado pone en riesgo no a un buscador, sino a todas las herramientas que leen su sitio.
¿Qué distingue el renderizado en cliente, el renderizado en servidor y las páginas generadas de antemano?
Con el renderizado en cliente, el servidor envía una cáscara de página vacía y el navegador construye el contenido con JavaScript. Con el renderizado en servidor, la página se prepara en el servidor en el momento de la petición y llega llena; después JavaScript se hace cargo de la interacción en el navegador. Con la generación previa, la página se produce una vez en el momento de la publicación y se sirve como un archivo listo.
Para las páginas que rara vez cambian, la generación previa es la opción más rápida y sólida: páginas de empresa, páginas de servicios, artículos. Las páginas que llevan precios, existencias o datos personalizados encajan mejor con el renderizado en servidor. Las áreas que los buscadores no deben ver de todos modos, como un panel tras el inicio de sesión, pueden usar renderizado en cliente sin problema.
La mayoría de los frameworks modernos permiten mezclar los tres métodos en un mismo sitio. La decisión se toma por tipo de página; no tiene que elegir un único método para todo.
¿Cómo saber si JavaScript perjudica a su sitio?
La prueba más sencilla es ver el código fuente de la página. Si allí ve el título, el texto principal y los enlaces, no hay un problema básico. Si solo ve un elemento raíz vacío y etiquetas de script, el contenido se construye en el navegador.
La segunda prueba es la herramienta de inspección de URL de Google Search Console, que muestra el HTML recibido y la página tal como la ve el buscador tras el renderizado. Cualquier diferencia entre la página real y la renderizada aparece allí. También puede revisar rápidamente sus títulos, descripciones y la estructura del contenido con nuestra auditoría SEO on-page gratuita.
La tercera señal está en los informes del índice: muchas páginas marcadas como rastreadas pero actualmente no indexadas, o resultados cuyo título y descripción no coinciden con el contenido real, pueden apuntar a un problema de renderizado.
- Si el texto principal y los enlaces se ven en el código fuente de la página
- Si el HTML renderizado en la inspección de URL coincide con la página real
- Si el título y la meta descripción están en el primer HTML o se añaden después
- Si los menús y los enlaces dentro del texto se construyen con etiquetas de enlace reales
- Si los archivos de script y de estilo están bloqueados por robots.txt
¿Qué errores son comunes en los sitios JavaScript?
El error más común es construir los enlaces con elementos que funcionan con un evento de clic en lugar de etiquetas de enlace reales. Los buscadores solo siguen enlaces que llevan una dirección; una estructura en la que un botón cambia la página impide que esas páginas se descubran. Un fallo relacionado es poner las páginas tras un fragmento hash en la dirección, lo que comprime páginas distintas en una sola URL.
El segundo es atar el contenido a la interacción del usuario. El contenido que se carga cuando alguien hace clic en una pestaña, se desplaza hacia abajo o pulsa un botón de mostrar más es un contenido que el buscador no ve. El texto central de una página nunca debería quedar tras esas interacciones.
El tercero es bloquear los archivos de script y de estilo en robots.txt, lo que impide al buscador renderizar la página y le lleva a interpretar mal el diseño o el contenido. El cuarto es no devolver un estado de error adecuado para las páginas que no existen: las aplicaciones de una sola página pueden responder a una dirección no válida con un código de éxito y un mensaje de página no encontrada, y el buscador la toma por una página real e intenta indexarla.
¿Se pueden añadir títulos, etiquetas meta y datos estructurados con JavaScript?
Se puede, conociendo el riesgo. Google puede leer los títulos y las etiquetas meta tras el renderizado, pero si faltan en el primer HTML, no todos los rastreadores ni todas las herramientas de vista previa de las redes sociales las verán. Una tarjeta de vista previa vacía al compartir un enlace suele deberse precisamente a esto.
La misma lógica vale para los datos estructurados. Puede añadirlos con JavaScript, pero tenerlos en el primer HTML es más seguro y implica menos dependencias. Las etiquetas críticas, como la dirección canónica y la directiva robots, deben estar en el primer HTML; una directiva cambiada tras el renderizado puede contradecir el valor que el buscador leyó primero.
¿Leen los asistentes de IA el contenido JavaScript?
Este terreno cambia deprisa y no hay una respuesta única. Los rastreadores que usan los asistentes de IA y los resúmenes de búsqueda por lo general no renderizan tan bien como un buscador clásico, y algunos se conforman con el HTML en bruto. Mantener el contenido importante en el primer HTML es, por tanto, la vía más segura para todos los lectores probables.
Si apunta a la visibilidad en IA, ponga la respuesta principal de la página y los datos esenciales en HTML renderizado en servidor. Puede probar cómo ve su sitio estas herramientas con nuestra comprobación gratuita de visibilidad en IA.
¿Cuándo no hace falta pasar al renderizado en servidor?
No todos los sitios JavaScript necesitan reescribirse. Un portal de clientes, una herramienta de reservas o una aplicación tras un inicio de sesión no necesita tráfico de búsqueda, así que basta el renderizado en cliente. De todos modos querrá mantener esas áreas fuera de las búsquedas.
Si su sitio actual muestra contenido en el código fuente, usa etiquetas de enlace reales y la inspección de URL no plantea dudas, no hay motivo para cambiar el método de renderizado. Reconstruir una instalación que funciona por preocupaciones de búsqueda crea fallos nuevos. Mida primero y decida después.
JavaScript no es el enemigo de la visibilidad en las búsquedas; el enemigo es el contenido que solo existe después de ejecutar JavaScript. Ponga el contenido, los enlaces y las etiquetas de las páginas importantes en el primer HTML y deje el resto de la interacción al navegador. Si desea revisar con nosotros cómo ve hoy su sitio un buscador, puede concertar una reunión de descubrimiento con rabbitclip.
Preguntas frecuentes
¿Indexa Google los sitios JavaScript?
Sí. Primero recibe el HTML en bruto y después ejecuta el JavaScript en un paso de renderizado. Ese paso puede retrasarse y no todos los rastreadores lo realizan, por lo que es más seguro mantener el contenido importante en el primer HTML.
¿Es malo para el SEO un sitio hecho con React o Vue?
No. El problema no es el framework, sino cómo se entrega el contenido. Con renderizado en servidor o generación previa sobre el mismo framework, el contenido llega en el primer HTML y el problema desaparece.
¿Cómo compruebo cómo ve un buscador una página?
Vea el código fuente de la página y use la herramienta de inspección de URL de Search Console. Ambos muestran si el texto principal, el título y los enlaces son visibles.
¿Es el renderizado dinámico una solución?
Servir a los buscadores una versión separada y prerrenderizada se usó como solución provisional, pero es difícil de mantener y no se considera una recomendación a largo plazo. La solución duradera es el renderizado en servidor o la generación previa.
¿Afecta al posicionamiento un sitio JavaScript lento?
De forma indirecta. Los scripts pesados dañan la velocidad de interacción y el tiempo de carga, lo que debilita tanto la experiencia del usuario como las mediciones de experiencia de página.
