Astro vuela. Eso no significa que tu SEO también
Hay una escena que se repite bastante cuando un proyecto abandona WordPress y pasa a Astro, Next.js, Hugo, Gatsby o cualquier otro framework moderno. La nueva web carga más rápido, el HTML es más limpio, el servidor trabaja menos, Lighthouse sonríe y los Core Web Vitals mejoran.
Durante unos minutos parece que hemos resuelto el SEO técnico por el sencillo procedimiento de cambiar de tecnología.
El problema aparece después, cuando empiezan las preguntas menos vistosas.
- ¿Dónde está el canonical?
- ¿Por qué una misma URL existe con y sin barra final?
- ¿Por qué el sitemap contiene páginas que no deberían indexarse?
- ¿Qué pasa con las redirecciones antiguas?
- ¿Quién está gestionando el noindex?
- ¿Dónde se define el Open Graph?
- ¿Cómo se evita que una plantilla genere metadatos distintos a otra?
El problema no es Astro. Tampoco es que WordPress sea mejor para SEO. El problema es que, cuando abandonamos un CMS tradicional, muchas decisiones que antes estaban resueltas pasan a ser responsabilidad nuestra.
Ahrefs lo resume bien en su análisis sobre SEO para sitios estáticos: WordPress y otros CMS gestionan silenciosamente una parte importante del SEO técnico mediante funcionalidades nativas y plugins, mientras que en una web estática muchas de esas tareas tienen que configurarse de forma explícita.
Eso no convierte a Astro en una mala elección. Lo convierte en una elección que exige saber qué estás haciendo.
Lo que WordPress estaba resolviendo sin que apenas lo notaras
WordPress tiene defectos de sobra. Después de tantos años de evolución, también ha acumulado una enorme cantidad de soluciones y convenciones alrededor del SEO. Muchas de ellas pasan completamente desapercibidas porque simplemente funcionan.
Instalas un plugin como Yoast SEO o Rank Math y aparecen mecanismos para gestionar canonicals, sitemaps, metadatos, Open Graph, Schema, robots y exclusiones de indexación. El usuario medio no piensa demasiado en cómo se construyen esas señales.
Lo importante es que el sistema ya trae una lógica bastante madura detrás.
Tomemos los canonicals. La documentación técnica de Yoast sobre URLs canónicas explica cómo el plugin genera estas etiquetas en función del tipo de contenido y de la URL que considera principal.
Lo mismo ocurre con los sitemaps. La documentación de Yoast sobre XML sitemaps detalla cómo se incluyen o excluyen contenidos según su estado, su indexabilidad o sus canonicals.
La cuestión importante no es que WordPress sea mágico. La cuestión es que ha convertido estas decisiones en parte del comportamiento esperado del sistema. Muchas veces solo las echamos de menos cuando desaparecen.
Astro no elimina esas necesidades. Las devuelve al proyecto
Astro permite construir una web técnicamente muy sólida. Su propia documentación de configuración permite definir cuestiones importantes como la URL principal del sitio, una ruta base o el comportamiento de las barras finales.
Estos valores afectan a cómo se construyen URLs y, por tanto, pueden influir en elementos como canonicals o sitemaps.
Pero Astro no intenta actuar como un CMS SEO. Los metadatos deben definirse dentro del <head> y la lógica que determina qué title, description, canonical o robots corresponde a cada página depende de cómo esté construido el proyecto.
Eso ofrece mucha libertad, pero también implica que una web puede ser rapidísima y estar mal resuelta desde el punto de vista SEO. Los problemas no aparecen porque Astro haga algo mal. Aparecen porque una decisión no se tomó, se tomó de forma inconsistente o se asumió que el framework la resolvería por su cuenta.
El sitemap es un buen ejemplo de esta diferencia
Astro cuenta con una integración oficial, @astrojs/sitemap, que permite generar el sitemap durante el proceso de construcción del proyecto. La instalación es sencilla y resuelve buena parte de la tarea básica.
Sin embargo, disponer de un sitemap no significa haber resuelto correctamente la indexación. Todavía tenemos que decidir qué URLs deben aparecer, cuáles deben quedar fuera, cómo se tratan determinadas rutas dinámicas y qué ocurre con páginas que no queremos enviar a los buscadores.
El problema real nunca ha sido generar un archivo XML. El problema es mantener una lógica coherente entre lo que queremos indexar, lo que declaramos como canonical y lo que enviamos a Google.
En WordPress, un plugin SEO suele relacionar automáticamente estas decisiones. Si una página está en noindex, normalmente desaparece también del sitemap. En Astro, esa relación debe formar parte de la lógica del proyecto.
Los canonicals son sencillos hasta que dejan de serlo
Añadir una etiqueta canonical a una plantilla es trivial. Lo complicado es garantizar que esa etiqueta sea correcta en todos los escenarios.
Hay que decidir qué ocurre con barras finales, parámetros, subdirectorios, entornos de staging, páginas paginadas, rutas alternativas y versiones duplicadas. También hay que asegurarse de que los enlaces internos utilicen la misma convención que los canonicals y que el sitemap no contradiga esa política.
Astro permite configurar parte de este comportamiento mediante opciones como site, base y trailingSlash. El problema no es la ausencia de herramientas. El problema es que alguien tiene que decidir cómo deben utilizarse.
Una web puede tener un rendimiento excelente y enviar señales contradictorias sobre cuál es la URL principal de cada contenido. Lighthouse no suele ponerse nervioso por eso. Google, en cambio, sí necesita entenderlo.
Las redirecciones dejan de ser una tarea editorial
En WordPress es habitual gestionar redirecciones desde un plugin, desde el servidor o desde determinadas herramientas SEO. Cuando un editor cambia un slug, puede existir incluso una sugerencia automática para redirigir la antigua URL.
En un proyecto estático, esta lógica suele estar más cerca del código, del hosting o de la plataforma de despliegue. Desde un punto de vista técnico puede ser más limpio, pero también cambia la responsabilidad.
Si eliminamos una ruta o modificamos un slug y nadie ha definido qué ocurre con la URL anterior, acabamos de crear un 404. El framework no sabe que esa página tenía tráfico, backlinks o años de señales acumuladas. Solo sabe que la ruta ya no existe.
Para el desarrollo puede ser una pequeña modificación. Para SEO puede ser una pérdida importante si la migración no se ha planteado correctamente.
noindex deja de ser un interruptor
Algo similar ocurre con las directivas de indexación.
En WordPress, marcar una página como noindex puede ser una acción editorial desde el panel. En Astro tenemos que decidir cómo representamos ese estado dentro de los datos, cómo llega a la plantilla y cómo termina convirtiéndose en una directiva robots.
Pero no basta con generar la etiqueta. Si una URL está en noindex, también debemos decidir si debería aparecer en el sitemap, si puede recibir enlaces internos importantes o si forma parte de una plantilla que está heredando una configuración incorrecta.
Aquí aparece una idea que se repite continuamente: el problema no está en implementar cada elemento de forma aislada. Está en conseguir que todos trabajen de forma coherente.
Metadata y Open Graph funcionan bien hasta que crece el proyecto
En una web pequeña es fácil crear un componente SEO y pasarle un título y una descripción. El problema aparece cuando el proyecto crece y empiezan a existir artículos, categorías, productos, autores, landings, páginas locales, filtros, paginaciones y contenidos con necesidades distintas.
En ese momento ya no estamos resolviendo etiquetas. Estamos diseñando un sistema de metadata.
Tenemos que decidir qué campos son obligatorios, cuáles tienen fallback, qué páginas necesitan un canonical específico, qué plantillas deben generar noindex, cómo se construyen las imágenes sociales o qué ocurre cuando falta una propiedad.
Astro facilita bastante esta arquitectura mediante componentes, pero no la impone. Podemos construir un sistema muy limpio o podemos terminar con cada plantilla generando metadatos de una forma distinta. Ambos proyectos seguirán siendo Astro.
Schema también pasa a ser una responsabilidad explícita
Con los datos estructurados ocurre algo parecido.
En WordPress existen plugins que generan automáticamente marcado para artículos, organizaciones, productos, breadcrumbs o autores. En Astro podemos hacerlo con mucho más control si queremos, pero antes tenemos que diseñarlo.
Hay que decidir qué tipo de Schema corresponde a cada plantilla, de dónde proceden los datos, qué ocurre cuando falta una propiedad y cómo evitar estructuras inconsistentes entre páginas.
El problema no es escribir JSON-LD. El problema es mantener una política común en todo el proyecto.
En sitios pequeños puede parecer exagerado. En sitios con miles de URLs deja de serlo bastante rápido.
Las páginas 404 también cuentan
Una página 404 no es simplemente una pantalla simpática con un mensaje de error.
Debe devolver realmente un código HTTP 404. Los soft 404 siguen apareciendo en todo tipo de proyectos porque la página muestra un error al usuario, pero el servidor responde con un 200.
En una arquitectura personalizada conviene comprobar este comportamiento de forma explícita, sobre todo cuando existen rutas dinámicas o contenidos procedentes de un CMS headless que pueden haber desaparecido.
De nuevo, no estamos ante un problema específico de Astro. Estamos ante una responsabilidad que no debemos dar por resuelta solo porque la página se vea correctamente.
La velocidad no compensa una arquitectura mal resuelta
Esta es probablemente la confusión más habitual.
Astro puede ofrecer un rendimiento excelente y reducir de forma drástica la cantidad de JavaScript enviada al navegador. Eso puede ayudar mucho a Core Web Vitals y a la experiencia de usuario.
Pero rendimiento y SEO técnico no son sinónimos.
Una página puede cargar en 300 milisegundos y tener un canonical incorrecto. Puede obtener una puntuación excelente en Lighthouse y estar bloqueada por robots.txt. Puede tener un CLS impecable y generar dos versiones indexables de cada URL por una mala política de trailing slash.
La velocidad mejora una web bien construida. No corrige una arquitectura incoherente.
Ese matiz es importante porque muchas migraciones se justifican precisamente por rendimiento. Mejorar la velocidad es una buena razón. Suponer que ese cambio resolverá automáticamente el SEO técnico es otra cosa.
WordPress + plugin SEO frente a Astro
La comparación tampoco debe entenderse como una lista de cosas que Astro no puede hacer. Puede hacerlas todas. La diferencia es quién se ocupa de ellas y cuánto trabajo de arquitectura necesitan.
La diferencia no está en lo que se puede hacer, sino en quién se ocupa de hacerlo.
La conclusión no es que WordPress sea técnicamente superior. La conclusión es que WordPress lleva muchos años acumulando automatismos y convenciones alrededor del SEO. Cuando salimos de ese ecosistema, tenemos que reconstruir aquellas que sigan siendo necesarias.
Qué revisaría antes de lanzar una web con Astro
Antes de publicar un proyecto estático, no me limitaría a comprobar rendimiento.
Revisaría primero que exista una única versión válida de cada URL y que protocolo, dominio, barras finales y rutas sigan una política consistente. Después comprobaría que todas las páginas indexables tengan canonical correcto, title, description y directivas de robots adecuadas.
El sitemap debería contener únicamente URLs que realmente queremos indexar, todas ellas con respuesta 200 y coherentes con sus canonicals. También revisaría redirecciones antiguas, especialmente si existe una migración desde WordPress u otra plataforma.
Las páginas 404 deberían devolver el código correcto. El Schema debería auditarse por tipo de plantilla y no únicamente mediante una página de muestra. Lo mismo ocurre con Open Graph, hreflang, paginaciones y cualquier lógica asociada a filtros o rutas dinámicas.
Por último, rastrearía el sitio completo con una herramienta como Screaming Frog.
No porque Astro necesite un tratamiento especial, sino precisamente porque no lo necesita. Hay que auditarlo como cualquier otra web y comprobar que todas las decisiones que antes resolvía el CMS siguen presentes.
El verdadero cambio no es tecnológico
Este es el punto que suele perderse cuando discutimos si WordPress, Astro, Next.js o cualquier otra tecnología es mejor para SEO.
Los buscadores no posicionan frameworks. Posicionan URLs, documentos y contenidos dentro de una arquitectura.
No existe un bonus por utilizar Astro. Tampoco existe una penalización por utilizar WordPress.
La tecnología condiciona lo fácil o difícil que resulta implementar determinadas cosas, pero el resultado depende de cómo esté construido el proyecto.
Ahrefs llega a una conclusión parecida en su análisis sobre sitios estáticos. No existe un framework inherentemente mejor para SEO. Astro, Next.js, Gatsby, Hugo o Jekyll pueden soportar perfectamente una implementación sólida, pero canonicals, metadatos, Schema, sitemaps, directivas de indexación y redirecciones siguen dependiendo de cómo configuremos el sistema.
Ese es probablemente el aprendizaje más útil de todo esto.
Cuando migramos desde WordPress a una arquitectura estática no estamos eliminando necesidades SEO. Estamos cambiando quién se ocupa de ellas.
Para acabar el café
Astro puede ser una opción excelente para construir una web rápida, ligera y técnicamente limpia. En muchos proyectos ofrece ventajas claras frente a un CMS tradicional.
Pero rendimiento y SEO técnico no son sinónimos.
WordPress, especialmente cuando trabaja junto a un plugin SEO maduro, resuelve automáticamente muchas decisiones que hemos terminado considerando normales. Canonicals, sitemaps, exclusiones, metadatos, Schema o determinados comportamientos de URLs forman parte de esa capa de automatización.
Cuando pasamos a Astro, esas decisiones no desaparecen. Vuelven al proyecto.
Eso no debería ser un motivo para evitar los frameworks modernos. Debería ser un motivo para utilizarlos con una arquitectura SEO definida desde el principio.
Porque una web puede volar y seguir enviando señales equivocadas a los buscadores.
Cuando eso ocurre, el problema no es Astro.
Es la implementación.
