SEO de aplicaciones SPA: cómo lograr que Google indexe una SPA y que las IA la lean

El SEO de aplicaciones SPA es el conjunto de técnicas que hacen que una aplicación JavaScript creada con React, Vue, Angular o Svelte sea tan fácil de rastrear como un sitio web clásico. El problema está bien documentado: Google explica en sus conceptos básicos de SEO para JavaScript que procesa las páginas JavaScript en tres fases (rastreo, renderizado, indexación), y cada debilidad de una SPA se sitúa en algún punto de esa cadena. Esta guía se centra en las SPA; para los sitios JavaScript en general, lea nuestra guía de SEO para JavaScript.

¿Qué es una aplicación de una sola página y por qué complica el SEO?

Un sitio web tradicional devuelve un documento HTML completo para cada URL. Una SPA devuelve casi el mismo documento para todas las URL: un <div id="root"> vacío, unas pocas metaetiquetas y un gran paquete de JavaScript. El navegador descarga el paquete, llama a una API y después dibuja la página. Cuando el visitante hace clic en un enlace, JavaScript cambia el contenido sin recargar.

Para una persona con un móvil rápido, el resultado parece instantáneo. Para un rastreador, la primera respuesta es un armazón vacío: sin encabezado, sin texto, sin enlaces. Todo depende de si el bot ejecuta el JavaScript, y de cuándo lo hace. Ese único hecho explica la mayoría de los problemas de SEO de las SPA:

• Contenido retrasado o ausente: el texto solo existe después del renderizado, que Google realiza más tarde y que otros bots omiten.
• Una sola URL para muchas vistas: las SPA más antiguas enrutan con fragmentos (/#/pricing), y la parte que sigue al # nunca se envía al servidor, de modo que todas las vistas se reducen a una sola URL.
• Títulos y descripciones idénticos: el armazón lleva un único <title> y, si el enrutador no lo actualiza, todas las páginas lo comparten.
• Enlaces sin href: los botones y los controladores onClick permiten navegar a los usuarios, pero no dan a los rastreadores nada que seguir.
• Errores 404 falsos (soft 404): el servidor responde 200 para cualquier ruta, incluidas las páginas que no existen, así que las vistas de error se indexan como páginas pobres.
• JavaScript pesado: los paquetes grandes ralentizan la primera visualización y las interacciones, lo que perjudica las Core Web Vitals.

¿Cómo rastrea y renderiza Google una SPA?

Googlebot obtiene primero el HTML sin procesar y lee los enlaces y las directivas que encuentra en él. Las páginas que devuelven un estado 200 pasan después a una cola del Web Rendering Service, un Chromium sin interfaz gráfica. Google indica que una página «puede permanecer en esta cola unos segundos, pero puede tardar más». Una vez renderizada, el HTML resultante se analiza de nuevo en busca de contenido y enlaces, y luego se indexa.

Cuatro detalles de la documentación de Google importan para las SPA:

1. Solo los elementos <a> con href son enlaces fiables. Los enlaces insertados por JavaScript funcionan siempre que respeten ese formato.
2. Los fragmentos no son páginas independientes. Google pide usar la History API (pushState) en lugar de rutas con #. Dejó obsoleto su antiguo esquema de rastreo AJAX (las URL con #!) en octubre de 2015.
3. Un noindex en el HTML original prevalece. Google puede omitir el renderizado cuando ve noindex, así que quitarlo después con JavaScript no funciona.
4. El renderizado usa archivos en caché. Googlebot almacena en caché el JavaScript y el CSS de forma agresiva, así que utilice nombres de archivo con huella (un hash del contenido en el nombre del archivo) para evitar paquetes desactualizados.

La consecuencia es clara: Google puede indexar una SPA renderizada del lado del cliente, pero usted añade a cada página un segundo paso, un retraso y un punto de fallo. Un tiempo de espera agotado, una llamada a la API bloqueada o un error de JavaScript durante el renderizado dejan vacía la versión indexada. Compruebe lo que ve Google con la herramienta de inspección de URLs de Search Console y lea nuestra guía sobre cómo funciona la indexación de Google si hay páginas que no entran en el índice.

¿Leen JavaScript ChatGPT, Claude y Perplexity?

En su mayoría, no. En un estudio publicado en diciembre de 2024 sobre el tráfico de su red, Vercel y MERJ comprobaron que «ninguno de los principales rastreadores de IA renderiza JavaScript actualmente»: GPTBot, OAI-SearchBot y ChatGPT-User (OpenAI), ClaudeBot (Anthropic), PerplexityBot, Meta-ExternalAgent y Bytespider leen solo el HTML sin procesar. Sí descargan archivos JavaScript (alrededor del 11,5 % de las solicitudes de ChatGPT y del 23,8 % de las de Claude), pero no los ejecutan. Las excepciones son Gemini, que se apoya en la infraestructura de renderizado de Google, y AppleBot, que utiliza un rastreador basado en navegador.

Para una SPA renderizada del lado del cliente, esto significa que los rastreadores de IA que alimentan ChatGPT, Claude y Perplexity ven una página vacía. Su producto puede posicionar en Google y seguir siendo invisible en las respuestas de las IA, porque el asistente nunca ha leído ni una palabra. Lo mismo ocurre con la mayoría de los bots de vista previa de enlaces de las redes sociales y de las aplicaciones de mensajería, que leen las etiquetas Open Graph en el HTML sin procesar. Una vez que el contenido esté en el HTML, compruebe también que su robots.txt permite los rastreadores de IA que desea.

¿Qué estrategia de renderizado debe usar una SPA?

La solución es enviar HTML real desde la primera respuesta. En su documentación sobre el renderizado dinámico, Google califica el renderizado dinámico (servir una versión prerenderizada solo a los bots) de «solución alternativa» que no recomienda, y remite en su lugar al renderizado del lado del servidor, al renderizado estático o a la hidratación. Las definiciones siguientes se basan en la referencia Rendering on the Web de web.dev.

La mayoría de los frameworks modernos permiten combinar estrategias por ruta: estática para las páginas de marketing, renderizada en el servidor para el catálogo y renderizada en el cliente para la aplicación con sesión iniciada. Esta configuración híbrida ofrece a los rastreadores HTML completo allí donde llega el tráfico de búsqueda y mantiene la experiencia SPA allí donde aporta valor.

Opciones por framework

Los sitios generados con creadores de webs basados en IA merecen una mención especial: muchos exportan una aplicación React renderizada del lado del cliente. Si ha creado su sitio con uno de ellos, consulte nuestras notas sobre SEO y GEO en Lovable antes de dar por hecho que Google y ChatGPT pueden leerlo.

Lista de comprobación de SEO para SPA: qué corregir ruta por ruta

1. Dé a cada vista una URL limpia y rastreable

Utilice la History API (/pricing, nunca /#/pricing), una URL por contenido y la misma URL tanto si el visitante llega directamente como si navega dentro de la aplicación. Cada URL debe cargar el contenido correcto al abrirse en una pestaña nueva: es la prueba que realiza un rastreador.

2. Use enlaces reales

Todo elemento de navegación que lleve a una página indexable debe ser un <a href="/path">. Los componentes de enlace de los frameworks (Link, NuxtLink, routerLink) generan este marcado; los controladores de clic personalizados en elementos div o button, no. Los buenos enlaces también sostienen la arquitectura de su sitio: si una página no recibe enlaces, los rastreadores rara vez la encuentran.

3. Actualice título, descripción y canónica en cada ruta

Cada ruta necesita su propio título, su metadescripción, su URL canónica y sus etiquetas Open Graph, generados en el servidor siempre que sea posible. Nuestra página sobre metaetiquetas enumera lo que hay que definir. Mantenga una sola etiqueta canónica: Google recomienda definirla en el HTML y, si JavaScript la modifica, el resultado no debe contradecir el original.

4. Devuelva códigos de estado honestos

Los productos inexistentes y los artículos eliminados no deben responder 200 con un mensaje de error. Con SSR, devuelva un 404 o un 410 real desde el servidor. En una SPA pura, Google acepta dos alternativas: redirigir con JavaScript a una URL que devuelva un 404 o añadir una metaetiqueta robots noindex a la vista de error.

5. Ponga el contenido principal y los datos estructurados en el HTML

Los encabezados, el texto, los precios, las preguntas frecuentes y los datos estructurados JSON-LD deben estar en la respuesta del servidor, no cargarse después de un clic o un desplazamiento. El contenido oculto tras pestañas que se renderizan bajo demanda, o tras botones de «Cargar más», a menudo se pierde.

6. Mantenga ligero el JavaScript

Divida el paquete por rutas, aplace lo que no sea necesario para la primera vista y evite volver a renderizar toda la página durante la hidratación. Tenga en cuenta que los datos de campo de Chrome (CrUX) atribuyen las métricas de las navegaciones dentro de la aplicación a la URL que el visitante cargó primero, así que pruebe sus plantillas clave una por una.

7. Compruebe lo que reciben los bots

Compare tres versiones de cada plantilla clave: el HTML sin procesar (vea el código fuente u obtenga la página con una herramienta de línea de comandos), el HTML renderizado por Google (Inspección de URLs y después «Ver página rastreada») y la página con JavaScript desactivado. Si el texto principal solo aparece en la segunda versión, los rastreadores de IA no lo ven. Nuestra auditoría de rastreabilidad para IA gratuita y el comprobador de indexabilidad realizan estas verificaciones en cualquier URL.

¿Cómo saber si su SPA tiene un problema de SEO?

SEO y GEO de las SPA: aparecer en Google y ser citado por las IA

Durante años, el renderizado del lado del cliente fue un riesgo asumible, porque Google acababa renderizando el JavaScript. Ahora que parte del descubrimiento ocurre en ChatGPT, Claude, Gemini y Perplexity, el coste ha cambiado: una página que solo existe tras ejecutar JavaScript no figura entre las fuentes que la mayoría de los asistentes pueden leer. La rastreabilidad en el HTML sin procesar se ha convertido en la primera condición de la optimización para motores generativos (GEO).

Una vez completo el HTML, lo demás sigue las reglas habituales: las páginas que responden con claridad a una pregunta, con datos con fuente y datos estructurados, son las que citan los asistentes. Las funciones de optimización GEO de Sorank le ayudan a redactar y publicar ese contenido, y el seguimiento de menciones en IA muestra si ChatGPT, Claude y Gemini citan su marca después de corregir el renderizado.

La regla clave del SEO de aplicaciones SPA cabe en una frase: todo lo que quiera que Google posicione y que las IA citen debe estar en el HTML que envía el servidor. Reserve la SPA para la experiencia con sesión iniciada, renderice las páginas públicas en el servidor o en la compilación y compruebe lo que reciben los bots antes y después de cada lanzamiento.