El portal de clientes salió en marzo. Funciona, la gente lo usa y nadie se queja. En octubre, alguien de marketing busca uno de los productos en Google y el primer resultado es la ficha de un distribuidor. La página propia no está. En Search Console, buena parte de las URL figuran como no indexadas, y cuando le preguntan a un asistente de IA por la empresa, responde con lo que decía el sitio anterior.
En desarrollo web a medida este problema suele tener el mismo origen: la aplicación entrega un HTML casi vacío y depende de que el visitante ejecute JavaScript para ver algo. Un navegador lo hace sin problema. Google también, pero con una cola de por medio y algunas condiciones. Varios rastreadores de asistentes de IA, en cambio, no lo hacen. Si estás eligiendo arquitectura antes de construir, en SPA, SSR o sitio estático comparamos las opciones. Este artículo es para el caso de una aplicación que ya está en producción, no aparece en buscadores y hay que decidir qué arreglar primero.
Primero, confirma que el problema es el JavaScript
No todo sitio que no aparece en Google tiene un problema de renderizado. Antes de cambiar la arquitectura, haz tres pruebas que toman menos de media hora.
- Abre una página pública y mira el código fuente (Ctrl+U), no el inspector del navegador. El inspector muestra el DOM después de ejecutar JavaScript; el código fuente muestra lo que recibe un bot que no lo ejecuta. Si en el
<body>solo hay algo como<app-root></app-root>y un par de scripts, ese es el punto de partida. - Usa la herramienta de inspección de URL de Search Console con la opción de probar la URL publicada. Según la guía de Google para resolver problemas de JavaScript, ahí ves los recursos cargados, los errores de consola y el HTML renderizado. Si el renderizado tampoco tiene tu contenido, Google no lo está viendo.
- Desactiva JavaScript en el navegador y recorre el sitio. Lo que no aparezca así no existe para cualquier rastreador que no ejecute código.
| Lo que encuentras | Qué significa probablemente |
|---|---|
| Código fuente vacío, renderizado de Google completo | Google te ve, pero tarde. Otros bots no te ven. |
| Código fuente vacío, renderizado de Google también vacío o con errores | Algo falla al renderizar: recursos bloqueados, errores de JS o una API que no responde. |
| Código fuente completo, página igual sin indexar | El problema no es el renderizado. Revisa noindex, canónicas, enlaces internos y calidad del contenido. |
Los errores que más vemos en una SPA
Cuando el diagnóstico apunta al JavaScript, casi siempre aparece alguno de estos, y varios se corrigen sin rehacer nada.
- Enlaces que no son enlaces. Google indica que, en general, solo puede rastrear un enlace si es un elemento
<a>con atributohref. Un botón o un<span>con evento de clic sirve al usuario, pero Google no lo sigue como enlace. - Rutas con
#. Una SPA que carga vistas distintas enejemplo.cl/#/productostiene, para Google, una sola URL. La recomendación oficial es usar la History API para que cada vista tenga su propia URL. - Todo responde 200. Si una ruta que no existe devuelve código 200 y una página de "no encontrado" dibujada por JavaScript, Google la trata como soft 404 y puede indexar páginas de error. Hay que redirigir a una URL que responda 404 de verdad o agregar
noindexen esos casos. - Un
noindexen el HTML inicial. Google pone en cola de renderizado las páginas con código 200, salvo que una etiqueta robots le diga que no indexe (conceptos básicos de SEO con JavaScript). Si el HTML de partida traenoindexy el JavaScript lo quita después, ese JavaScript no llega a correr para Google. - JavaScript bloqueado en
robots.txt. Google no renderiza JavaScript de archivos bloqueados. Una regla antigua que excluye/assets/o/static/deja la página en blanco para el renderizador. - Contenido que depende del estado. El renderizador de Google borra el almacenamiento local, el de sesión y las cookies entre una carga y otra. Si el contenido aparece solo después de que el usuario eligió una región o aceptó algo, Google ve la versión sin elegir.
- Archivos sin huella en el nombre. Google guarda en caché los recursos de forma agresiva y puede usar un JavaScript antiguo. Nombres como
main.2bb85551.js, que cambian con cada versión, evitan el problema. Revisa que tu compilación de producción los genere así.
Google no es el único que lee tu sitio
Google ejecuta JavaScript, pero hoy una parte de la búsqueda pasa por asistentes de IA que leen el sitio con sus propios rastreadores.
En un análisis publicado por Vercel en diciembre de 2024 sobre el tráfico de su red, ninguno de los principales rastreadores de IA medidos ejecutaba JavaScript: ni los de OpenAI (GPTBot, OAI-SearchBot, ChatGPT-User) ni ClaudeBot, de Anthropic. Descargaban los archivos .js (11,5% y 23,8% de sus solicitudes, respectivamente), pero no los corrían. El estudio tiene casi dos años y estas empresas cambian sus rastreadores sin mucho aviso, así que tómalo como referencia y no como regla fija.
Para una SPA, la consecuencia es concreta: si el nombre del producto, el precio o la descripción del servicio solo existen después de ejecutar código, ese asistente no tiene de dónde sacarlos.
Cuatro salidas, según cuánto quieras cambiar
| Opción | Qué implica | Cuándo conviene |
|---|---|---|
| Corregir la SPA | Rutas reales, enlaces con href, códigos HTTP correctos, títulos por ruta, robots.txt revisado | Pocas páginas públicas y la mayor parte del sistema detrás de un login |
| Prerenderizar las rutas públicas | El HTML de esas páginas se genera al compilar y se publica como archivo | Contenido público que cambia poco: servicios, blog, documentación |
| SSR o renderizado híbrido | Un servidor arma el HTML de las rutas públicas en cada visita | Catálogos con precio o stock que cambian seguido y además deben posicionar |
| Separar en dos | Sitio público estático y la aplicación privada como SPA | Cuando el sitio comercial y la plataforma tienen ritmos y equipos distintos |
Una opción que no recomendamos es el renderizado dinámico, que consiste en mostrar a los bots una versión prerenderizada y a las personas la SPA. Google lo describe como una solución provisoria que no recomienda, por la complejidad y los recursos que suma.
La primera fila suele ser el paso inicial en cualquier caso. Prerenderizar o pasar a SSR no arregla un enlace sin href ni un 200 en una página de error.
Lo que hicimos con nuestro propio sitio
En Disrupsoft pasamos por esto. Nuestro sitio anterior se armaba en el navegador, y el blog y las páginas de servicio dependían del JavaScript para mostrar el contenido. Lo migramos a páginas que se generan al compilar, y hoy cada artículo llega con el HTML completo, su título y su descripción desde la primera respuesta del servidor.
En una migración así, lo que más trabajo da no es el framework. Es el inventario: listar todas las URL que existían, decidir cuáles se mantenían, redirigir las que cambiaban y confirmar en Search Console que Google veía lo mismo que un visitante. Si vas a hacer una migración parecida, parte por ahí.
Cómo comprobar que quedó resuelto
Después del cambio, repite el diagnóstico del principio. El código fuente debería mostrar el contenido y la inspección de URL no debería tener errores de recursos. Además:
- Envía un sitemap con las URL reales y revisa que no incluya rutas con
#ni páginas de error. - Sigue el informe de indexación de Search Console durante varias semanas, no unos pocos días. La reindexación no es inmediata.
- Mide los Core Web Vitals antes y después. Los umbrales y cómo exigirlos en un contrato están en desarrollo web a medida en Chile.
Preguntas frecuentes
¿Google indexa una SPA hecha en Angular o React?
Puede hacerlo. Google ejecuta JavaScript, pero las páginas pasan por una cola de renderizado y tienen que cumplir condiciones: URL reales, enlaces con href, códigos HTTP correctos y recursos no bloqueados. Si la página tiene que posicionar, entregar el HTML ya armado es más seguro.
¿Tengo que reescribir la aplicación para que aparezca en Google?
Casi nunca. Lo habitual es corregir rutas, enlaces y códigos HTTP, y luego prerenderizar o renderizar en servidor solo las páginas públicas. La zona privada puede seguir siendo una SPA.
¿Los asistentes de IA leen mi sitio igual que Google?
No necesariamente. Un estudio de Vercel de diciembre de 2024 encontró que los rastreadores de OpenAI y Anthropic que midió no ejecutaban JavaScript. Si tu contenido existe solo después de ejecutar código, esos rastreadores reciben una página vacía.
Revisemos tu aplicación
En Disrupsoft desarrollamos aplicaciones web a medida con Angular, Node.js, Azure y Power Platform. Si tu plataforma funciona bien para los usuarios pero no aparece en buscadores, podemos ayudarte a diagnosticar la causa y definir el cambio más acotado que la resuelva. Conversemos sobre tu proyecto de desarrollo a medida.
