SEO para Angular: evita estos errores que yo cometí

Corría 2018, ya llevaba unos buenos años trabajando como SEO Manager en agencias de marketing. En ese entonces me asignaron un proyecto que ya venía con historia: un sitio desarrollado en Angular. El cliente había migrado recientemente desde una plataforma tradicional a una SPA con Angular, y aunque el rediseño visual y de experiencia de usuario era impecable, los resultados SEO eran catastróficos. Literalmente, las páginas más importantes para el negocio no estaban posicionando en Google y el tráfico orgánico había colapsado.

Como parte del servicio de SEO, me pidieron auditar el proyecto. Yo ya tenía experiencia en SEO técnico, pero esta fue la primera vez que me enfrenté a fondo con una SPA construida completamente en JavaScript. Y fue el inicio de un viaje de aprendizaje que me llevaría a entender cómo Google realmente indexa este tipo de sitios.

Cuando Google no ve nada (aunque tu sitio esté «perfecto»)

Lo primero que hice fue inspeccionar algunas URLs con la herramienta «Explorar como Google» de Search Console. Lo que vi me dejó helado: el HTML renderizado consistía básicamente en un <app-root> vacío. Nada de contenido, ni titulares, ni enlaces internos. En resumen: Google no veía absolutamente nada.

Revisando más a fondo, entendí por qué. Angular entregaba un HTML inicial mínimo, y todo el contenido se inyectaba dinámicamente desde el cliente mediante JavaScript. Para un navegador moderno esto no es problema. Para Googlebot en 2018, sí lo era.

Aprendiendo a golpes: los errores que encontramos

Uno de los primeros descubrimientos fue que Googlebot usaba por entonces una versión desactualizada de Chrome (41). Esto significaba que muchas funcionalidades modernas de JavaScript —y en especial de Angular 6+— simplemente no eran compatibles o se ejecutaban con errores. En consecuencia, el renderizado del contenido fallaba parcialmente o completamente.

Además, Google trabajaba en ese entonces bajo un esquema de indexación en dos fases: primero indexaba el HTML estático, y luego, en una segunda ronda, renderizaba el JavaScript (si podía). Pero esa segunda ronda podía demorarse horas, días o incluso no ocurrir si la página quedaba al fondo de la cola de renderizado.

El sitio que heredamos tenía varios problemas técnicos:

• Navegación sin enlaces <a href> tradicionales: solo usaba routerLink, lo que impedía que Google descubriera nuevas rutas.
• Falta de title y meta description únicos por página: todas las rutas compartían el mismo título y metadatos.
• Sitemap XML inexistente: sin un sitemap, Googlebot tenía aún más dificultades para descubrir las URLs de secciones y artículos.
• Carga asincrónica del contenido principal sin fallback: el texto de los artículos se cargaba tras una petición XHR, sin ninguna representación en el HTML inicial.

Buscando soluciones: de Dynamic Rendering a Angular Universal

Una vez diagnosticado el problema, investigué qué alternativas recomendaba Google en ese momento. Encontré que en 2018 Google estaba promoviendo el uso de Dynamic Rendering como solución temporal para sitios JavaScript pesados. Consistía en servir HTML prerenderizado solo a bots (como Googlebot), mientras que a los usuarios se les entregaba la SPA original.

Implementamos Rendertron, un headless browser que generaba versiones HTML estáticas de cada página bajo demanda. Usábamos detección de User-Agent para servir estas versiones a los bots. La mejora fue inmediata: el contenido empezó a indexarse y las visitas orgánicas repuntaron.

Pero sabíamos que eso era solo un parche. Por eso, meses después, propusimos y ejecutamos una migración del sitio a Angular Universal, el motor de Server-Side Rendering (SSR) para Angular. Con esta arquitectura, el HTML de cada ruta se generaba en el servidor, por lo que Google ya no necesitaba esperar para renderizar.

Esto permitió:

• Servir title y meta tags dinámicos por ruta usando el servicio Meta de Angular.
• Incluir contenido completo en el HTML inicial, acelerando la indexación.
• Eliminar la dependencia del prerendering condicional.

Google también aprendió: evolución del renderizado de JavaScript

Hoy, en 2025, la situación ha cambiado radicalmente. Desde 2019, Googlebot se volvió \»evergreen\», lo que significa que siempre está basado en la última versión estable de Chromium. Esto le permite:

• Ejecutar JavaScript moderno, incluyendo ES6+, Fetch API y Web Components.
• Renderizar la mayoría de SPAs sin necesidad de soluciones alternativas.
• Reducir el tiempo promedio de espera en la cola de renderizado a menos de 5 segundos en muchos casos.

Además, Google ha declarado obsoleto el Dynamic Rendering desde 2022. Y aunque sigue recomendando SSR, también ha sido claro en que el renderizado ya no es una limitación crítica, siempre que el sitio esté bien estructurado y optimizado.

Pero aun así, conocer la teoría y los principios de cómo Google indexa sitios JavaScript sigue siendo fundamental. Porque si algo falla —sea por un bug en el código, una API caída o un robots.txt mal configurado— podrías dejar a Google mirando una página vacía, sin darte cuenta.

Datos duros: por qué aún importa

Varios estudios recientes refuerzan esto:

• En 2023, un análisis de más de 16 millones de páginas reveló que el 62% nunca fue indexado. Muchas pertenecían a sitios JavaScript con renderizado mal implementado.
• En experimentos de seoClarity y Onely, se demostró que Google sí puede indexar contenido generado dinámicamente, incluso con retardos de 5 segundos, pero solo si se cumplen ciertas condiciones.
• En proyectos propios, he visto diferencias drásticas en la indexación entre páginas con routerLink sin href y otras que usan enlaces HTML estándar.

Conclusión: la lección que me dejó 2018

Lo que aprendí ese año no solo cambió mi forma de hacer SEO. Cambió mi forma de entender la web. Aprendí que los frameworks modernos no están reñidos con el posicionamiento, pero exigen mayor colaboración entre desarrolladores y especialistas SEO.

También entendí que, aunque Google hoy puede renderizar casi todo, eso no significa que debas dejarle todo el trabajo. Un sitio bien construido, con SSR o prerendering, enlaces claros, metas dinámicas, y performance optimizada, será siempre más confiable.

Y si me preguntan si volvería a trabajar con Angular para un sitio orientado a SEO, la respuesta es sí. Pero con una gran diferencia: ahora conozco las reglas del juego.

Así que si estás empezando en SEO para sitios JS o heredaste un proyecto similar, no te asustes. Estudia cómo renderiza Google, identifica los cuellos de botella, y aplica buenas prácticas. A veces los errores —como los que cometimos en 2018— son el mejor maestro.

Pero si puedes evitarlos, mejor.