Hace un tiempo mi portafolio hecho con React y Vite funcionaba perfecto visualmente, pero tenía un problema: el SEO. Las páginas tardaban en indexarse, algunos proyectos nuevos no aparecían en Google y gran parte del contenido dependía completamente del renderizado cliente. Ahí empecé a entender la diferencia entre una SPA tradicional y un sitio generado estáticamente.
El problema de una SPA para el SEO
En una SPA tradicional, gran parte del contenido depende del renderizado cliente. Aunque el crawler de Google puede ejecutar JavaScript, eso añade una etapa extra de procesamiento: primero rastrea el HTML inicial (a menudo un esqueleto limitado) y luego agenda el renderizado completo del JS. Es como si invitaras a alguien a tu casa, pero primero tuvieras que montarle los muebles. En sitios pequeños esto puede no ser grave, pero sigue siendo menos directo que entregar HTML completo desde el inicio.
Consecuencias prácticas
- El título y la meta descripción dependen del bundle JS.
- Parte de la estructura interna puede no detectarse inmediatamente.
- Aunque
robots.txtysitemap.xmlestén correctamente configurados, el contenido principal sigue dependiendo del renderizado cliente.
Google suele esperar y renderizar, pero ese proceso tiene un coste. Si tu web tiene bajo crawl budget o poca prioridad, esa latencia puede traducirse en indexación más lenta.
¿Y Next.js?
Después probé Next.js usando SSG (Static Site Generation). Ahí el HTML ya llegaba completo y la diferencia se notaba inmediatamente.
Pero también descubrí una cosa: Next.js es extremadamente flexible, y esa flexibilidad puede convertirse en complejidad si no tienes cuidado.
Lo que sí me gustó
- SSR y SSG resuelven bien muchos problemas de SEO.
- La metadata de Next es potente.
- Los Server Components reducen bastante el JS cliente cuando se usan correctamente.
Lo que no me terminó convenciendo
- Dependiendo de cómo montes el proyecto, React puede seguir hidratando demasiado.
- Muchos proyectos terminan enviando bundles más grandes de lo necesario.
Para un blog o portafolio sentía que estaba usando una herramienta demasiado grande para algo relativamente simple.
Astro cambió mi forma de ver el SEO
Astro genera HTML renderizado desde el servidor o generado estáticamente desde el inicio, dejando el contenido principal disponible sin depender del renderizado cliente. Eso hace que la experiencia de indexación sea mucho más directa.
Lo que más me gustó
- Cada página controla fácilmente su
<head>. - La estructura del proyecto es muy simple.
- El contenido principal está disponible desde el primer render.
- El JS enviado al cliente suele ser muchísimo menor.
¿Y las islas?
La arquitectura de islas fue probablemente lo que más me convenció. Con Astro puedes usar React, Vue o Svelte solo donde necesitas interactividad: formularios, sliders, buscadores o componentes dinámicos, mientras el resto permanece como HTML estático. Eso significa que el crawler puede leer el contenido principal sin tener que ejecutar una aplicación completa.
Comparativa SEO entre modelos
Estos resultados no son benchmarks absolutos. Son observaciones personales usando Lighthouse y Google Search Console en mi portafolio.
| Aspecto SEO | SPA cliente-only | Next.js (SSG/SSR) | Astro |
|---|---|---|---|
| HTML inicial | Limitado sin SSR/prerender | Completo | Completo |
| Metadata inmediata | Depende del setup | Muy buena | Muy buena |
| JS enviado al cliente | Alto | Medio | Muy bajo |
| Complejidad SEO técnica | Media/Alta | Media | Baja |
| Core Web Vitals | Variables | Buenos si optimizas | Muy buenos |
| Ideal para sitios de contenido | Requiere trabajo extra | Muy bueno | Excelente |
Menos JavaScript no garantiza mejor posicionamiento automáticamente, pero sí suele mejorar performance, estabilidad y Core Web Vitals.
Mi robots.txt y sitemap.xml
En Astro, mi carpeta public/ se ve así:
public/
├── robots.txt
├── sitemap.xml
├── favicon.ico
└── images/En mi caso, el robots.txt no necesita bloquear nada especial. Solo permite el rastreo del sitio y le deja a Google la ruta del sitemap:
User-agent: *
Allow: /
Sitemap: https://kamilavillablanca.cl/sitemap.xmlY el sitemap lo genero desde la configuración de Astro, usando el dominio final del sitio:
import { defineConfig } from "astro/config";
import sitemap from "@astrojs/sitemap";
export default defineConfig({
site: "https://kamilavillablanca.cl",
integrations: [sitemap()],
});Con eso, Astro genera automáticamente el sitemap con las páginas públicas del portafolio. Para un sitio pequeño, esa simpleza se agradece: cada URL queda declarada y no tengo que mantener una lista manual cada vez que publico una página o un artículo nuevo.
Trade-offs de Astro
Astro no es perfecto. Si tu aplicación depende mucho de estado cliente, navegación compleja o una experiencia tipo app, probablemente Next.js siga siendo más cómodo. También hay otras diferencias que conviene mirar:
- El ecosistema es más pequeño.
- Algunas integraciones son menos maduras.
- Si tu stack entero depende de React, la migración puede generar fricción.
Pero para contenido estático o semiestático, esos trade-offs me parecieron poco.
¿Cuándo Astro no es la mejor opción?
Si tu proyecto es principalmente una aplicación privada, dashboards internos o experiencias altamente dinámicas, gran parte del contenido ni siquiera necesita indexación pública. Ahí React, Next.js o incluso una SPA cliente-only pueden tener más sentido. Astro brilla especialmente cuando el contenido está primero y la interactividad es secundaria.
Mi experiencia antes y después
Antes (React SPA cliente-only)
- Varias páginas tardaban días en indexarse.
- Algunas URLs quedaban como “Rastreada, actualmente sin indexar”.
- Lighthouse daba métricas medias.
- El sitio dependía completamente del renderizado cliente.
Después (Astro + islas React)
- Los proyectos nuevos aparecían antes en Search Console.
- El contenido se veía correctamente desde la inspección de URL.
- Lighthouse mejoró casi sin optimizaciones extra.
- El sitio se sentía mucho más liviano.
Conclusión
No necesitas un mega framework para que Google encuentre tu contenido. Un HTML bien armado, una estructura ordenada y contenido disponible desde el inicio ya resuelven buena parte del SEO técnico. Para sitios de contenido, Astro me dio un camino más liviano. Eso sí: si tu aplicación depende completamente del cliente o necesita una experiencia tipo app con mayor complejidad, Astro probablemente no sea la herramienta correcta.