SEO en Angular: renderizado en servidor y errores comunes

Una aplicación Angular recién creada con el CLI es, por defecto, casi vacía en su HTML inicial: un index.html mínimo y un paquete de JavaScript que construye todo el DOM en el navegador. Google indexa en dos oleadas -primero lee el HTML crudo, luego encola esa URL para renderizarla con un Chromium headless, un proceso que puede tardar de segundos a varios días- así que un fallo en esa segunda pasada (un timeout, un error de JavaScript, una API que no responde) puede dejar la página indexada como un cascarón vacío.

Este artículo cubre el SSR de Angular, la hidratación y por qué es donde más proyectos se rompen, cuándo conviene el prerenderizado en vez de SSR, los servicios Title y Meta, las decisiones de enrutamiento que afectan al rastreo y los errores propios del stack de Angular, distintos de los de Next.js o Nuxt.

Por qué Angular necesita un tratamiento distinto al de React o Vue

El renderizado 100% en cliente no es exclusivo de Angular, pero el framework llegó tarde a resolverlo de forma integrada. Durante años, el CLI generaba por defecto una SPA pura y el SSR era un paquete aparte (Angular Universal) que había que añadir a mano; frameworks como Next.js o Nuxt nacieron con SSR por defecto. Esa diferencia de arquitectura tiene consecuencias reales en cómo aparecen -o no- las páginas en el buscador.

El síntoma es fácil de detectar: si abres "ver código fuente" sobre una URL de producción y ves un <app-root></app-root> vacío, esa es la respuesta que recibe cualquier sistema que no ejecute JavaScript, incluida la primera pasada de rastreo de Google. Cada dependencia añadida al proceso -llamadas a APIs externas, timeouts, errores no controlados- es un punto más donde ese renderizado puede fallar en silencio.

• Código fuente casi vacío en una URL pública que debería mostrar contenido de inmediato.
• La vista "HTML" de la inspección de URLs en Search Console difiere de lo que ve el usuario final.
• Contenido que tarda en aparecer incluso con JavaScript activado, señal de dependencias lentas en el renderizado.

Renderizado en servidor (SSR) en Angular: cómo funciona

El SSR de Angular (hoy integrado en el CLI como @angular/ssr, antes distribuido como Angular Universal con paquetes como @nguniversal/express-engine) ejecuta la misma aplicación en Node.js en vez de en el navegador. Al llegar una petición, el servidor instancia los componentes de esa ruta, resuelve sus datos y serializa el resultado a HTML completo, enviado de inmediato. El navegador -o el rastreador- recibe contenido real desde la primera respuesta, sin esperar a que se descargue y ejecute el bundle de JavaScript.

Esto no es gratis: renderizar el árbol de componentes consume CPU en cada petición, no una sola vez como en un sitio estático, así que el TTFB sube bajo carga sin caché por delante, y eso golpea a Core Web Vitals, señal de posicionamiento documentada. La configuración vive en angular.json, junto al punto de entrada del servidor, que decide qué motor HTTP atiende las peticiones.

Un matiz frente a otros frameworks: Angular no separa "páginas" como archivos de primera clase; toda la app es un único árbol de rutas del Router, y cualquier guard, resolver o interceptor que se ejecute al activar una ruta corre también en el servidor, sin window, sin localStorage, sin eventos de ratón.

Hidratación: la parte donde más se rompen los proyectos Angular

La hidratación es el proceso por el que la aplicación, ya en el navegador, toma el control del HTML que llegó del servidor en vez de reconstruirlo desde cero. En las primeras versiones de Angular Universal el navegador borraba el DOM del servidor y remontaba toda la app, con un parpadeo visible y el trabajo del servidor desperdiciado. Las versiones recientes incorporan hidratación no destructiva: Angular reutiliza los nodos existentes si coinciden con lo esperado, y solo reasigna los listeners sobre ese DOM ya presente.

El problema aparece cuando el HTML del servidor no coincide con lo que el cliente renderizaría: un componente que usa Date.now() o Math.random() en la plantilla, código que accede a window sin comprobar el entorno, o un widget de terceros que manipula el DOM fuera del renderer de Angular. Al detectar el desajuste, Angular descarta ese subárbol y lo rerenderiza en cliente -el coste que la hidratación existe para evitar- y suele producir un salto de layout justo cuando la página se vuelve interactiva.

La forma práctica de evitarlo: proteger el código dependiente del navegador comprobando la plataforma (isPlatformBrowser) o moviéndolo a afterNextRender. La manipulación directa del DOM fuera de las APIs de Angular es la causa más frecuente de mismatches en proyectos que integran gráficos, mapas o editores pensados solo para el navegador.

Prerenderizado (SSG) en Angular: cuándo usarlo en vez de SSR puro

Angular también permite generar HTML estático en tiempo de compilación para un conjunto de rutas conocido. La diferencia con SSR es cuándo se paga el coste: con SSR en cada visita; con prerenderizado una vez durante ng build, y el resultado son archivos que cualquier servidor -sin Node, sin motor de renderizado- puede servir directamente. Para contenido que no cambia entre compilaciones (páginas institucionales, landing pages, contenido editorial) esto es estrictamente mejor: menor TTFB y menos superficie de fallo.

La limitación es que necesita conocer de antemano qué rutas existen. Rutas con parámetros fijos y enumerables pueden listarse en la configuración de build; rutas cuyo contenido depende de una consulta en tiempo real -resultados de búsqueda, un listado que cambia con el inventario- no son viables, porque quedarían desactualizadas hasta la siguiente compilación.

El patrón que mejor funciona es mixto: prerenderizar el conjunto pequeño y estable (home, categorías, contenido editorial) y reservar SSR para las rutas que de verdad necesitan datos frescos en cada petición.

Los servicios Title y Meta: la parte que Angular obliga a hacer a mano

A diferencia de frameworks con una API de metadatos por ruta, Angular no genera automáticamente un título ni una descripción distintos por página. Expone dos servicios -Title y Meta- que hay que inyectar y llamar explícitamente: setTitle() para la etiqueta <title> y updateTag() para cada <meta>. Sin esas llamadas en el momento correcto, toda la aplicación comparte el título y la descripción del index.html original.

El error más visible es actualizar el título solo desde el componente raíz: todas las rutas terminan con el mismo <title>, con lo que todas aparecen en los resultados con el mismo título aunque el contenido de cada página sea distinto. El más difícil de detectar es actualizarlo dentro de ngOnInit de un componente perezoso: si la actualización llega después de que el servidor serializó la respuesta, el HTML que recibe el rastreador conserva el título por defecto, aunque el usuario nunca lo note.

La solución robusta es definir título y descripción en la propiedad data de la ruta, o resolverlos con un resolver antes de activarla, para que estén listos antes de serializar el HTML. Angular tampoco genera una etiqueta canónica por defecto; hay que añadirla manualmente como elemento link (el servicio Meta solo gestiona etiquetas meta), y sin ella, variantes de la misma URL con parámetros de consulta o con/sin barra final pueden indexarse como páginas separadas.

• Actualizar título y meta descripción en cada cambio de ruta, incluidas las rutas hijas perezosas.
• Definir los metadatos en la configuración de la ruta o en un resolver, no solo en ngOnInit.
• Añadir explícitamente la etiqueta canónica; Angular no la genera por sí sola.
• Verificar el HTML que sale realmente del servidor, no lo que muestra el navegador tras hidratar.

Router y URLs: decisiones que afectan directamente al rastreo

El Router de Angular admite dos estrategias de localización. HashLocationStrategy genera URLs con fragmento (dominio.com/#/producto); todo lo que sigue al # nunca llega al servidor, así que el buscador ve una sola URL sin importar cuántas rutas internas tenga la app. PathLocationStrategy genera URLs limpias y es la opción correcta, pero exige que el servidor -o el proxy delante- reescriba cualquier ruta profunda hacia el punto de entrada, o una recarga directa devolverá un 404 real en vez de dejar que Angular resuelva la ruta.

La consistencia de formato tampoco la decide Angular por ti: el Router puede coincidir o no con una barra final según cada ruta, y si /producto y /producto/ responden igual sin que una redirija a la otra, se crea contenido duplicado. La solución es una regla 301 en el servidor SSR o en el proxy, hacia una única forma canónica.

Los módulos cargados de forma perezosa (loadChildren) no son un problema de SEO si el servidor de SSR resuelve ese chunk antes de responder -algo que conviene verificar con una petición directa, sin navegador. Y conviene decidir con intención qué va en la ruta y qué en query string: un filtro que no aporta una página distinta debería quedar fuera de la indexación vía canónica; una variación con demanda propia merece su propio segmento de ruta.

Errores comunes que aparecen solo en el stack de Angular

Algunos fallos no tienen equivalente directo en otros frameworks, porque nacen de decisiones específicas del toolchain de Angular.

Ninguno de estos errores es exclusivo de un proyecto mal hecho: son consecuencia de que Angular deja piezas como la transferencia de estado o el código de respuesta como decisiones explícitas del equipo, en vez de resolverlas por convención.

• Peticiones duplicadas tras la hidratación: si los datos que obtuvo el servidor durante el SSR no se transfieren al cliente con TransferState, el navegador repite las mismas llamadas a la API al arrancar, duplicando la carga sobre el backend.
• Coste de Zone.js y tamaño de bundle: la sobrecarga histórica de Zone.js y un bundle sin optimizar infla el tiempo hasta que la página es interactiva, algo que se refleja en Core Web Vitals; recortar el JavaScript suele traer mejoras medibles.
• Metadatos fijados en el constructor: llamar a setTitle o updateTag ahí en vez de en ngOnInit puede ejecutarse en un momento distinto en servidor y cliente, con la misma inconsistencia que un mismatch de hidratación, aunque el síntoma aparezca en el <head>.
• Códigos de estado ignorados: una SPA en cliente siempre responde 200, incluso para una ruta que Angular resuelve internamente como "no encontrada" -un 404 suave clásico. El SSR sí puede devolver un código real, pero solo si el servidor conecta el estado del Router con la respuesta HTTP; muchos setups nunca hacen esa conexión.

Cómo comprobar que una aplicación Angular es realmente indexable

La comprobación más fiable no usa el navegador con las herramientas de desarrollo abiertas, porque la app ya se hidrató y lo que se ve es el resultado final, no lo que recibió el rastreador. Una petición directa al servidor (con curl, sin ejecutar JavaScript) muestra el HTML real de la primera respuesta: si el título, la descripción y la canónica ya están ahí, el SSR funciona; si aparecen vacíos, el problema está antes de la serialización.

La inspección de URLs de Search Console complementa esa comprobación mostrando el HTML que Google usó al renderizar y una captura de la página, lo que distingue un problema de SSR (el HTML crudo ya está mal) de uno de la segunda oleada (el HTML crudo está bien, pero algo falla al ejecutar JavaScript). Probar rutas inexistentes y comprobar que devuelven un 404 real -no un 200 con una página de error dentro- cierra la verificación del enrutamiento.

• Petición directa al servidor sin navegador, para ver el HTML real de la primera respuesta.
• Inspección de URLs en Search Console, comparando el HTML renderizado con lo esperado.
• Verificación de que rutas inexistentes devuelven un código de estado 404 real.
• Confirmación de que título, meta descripción y canónica cambian entre rutas distintas.