Si tenés un sitio hecho en React, Vue o cualquier framework de SPA, hay un experimento incómodo que conviene hacer: abrí ChatGPT y preguntale "¿qué hace [tu empresa]?". Si la respuesta es genérica, vaga o directamente errónea, no es porque tu sitio sea malo. Es porque para los LLMs, tu sitio está en blanco.
Eso fue lo que vimos cuando empezamos a auditarnos a nosotros mismos. Y es la razón principal por la que migramos de Vite + React a Astro.
El problema que el Lighthouse no mide
Una Single Page Application (SPA) renderiza en el browser. Cuando un usuario entra al sitio, el servidor le manda un HTML casi vacío con un <div id="root"></div> y un montón de JavaScript que se ejecuta en su navegador para construir la página.
Esto funciona bien para usuarios humanos con conexión decente. Pero los crawlers de los LLMs — los que alimentan a ChatGPT, Claude, Perplexity, Gemini — no siempre ejecutan JavaScript, y cuando lo hacen, lo hacen con timeouts cortos y prioridad baja. Resultado: ven tu sitio como un cascarón. No saben qué vendés, qué hacés, ni qué decís.
Para una agencia cuyo posicionamiento depende de aparecer cuando alguien le pregunta a una IA "agencia de marketing digital en Argentina", eso es un problema de negocio, no técnico.
Qué cambia con Astro
Astro entrega HTML pre-renderizado por default. Cuando un crawler — humano, Google, o LLM — pide una página, recibe el contenido completo en el primer byte: títulos, copy, imágenes, links, schema. Sin esperar JS, sin hidratación previa, sin acertijos.
Donde sí necesitamos interactividad real (el embed de Cal.com en /book, por ejemplo), seguimos usando React, pero como isla: solo ese componente carga JavaScript. El resto de la página queda como HTML estático y liviano.
Es la inversión de la lógica de SPA. En lugar de "todo es JavaScript, salvo lo que sea estático", es "todo es estático, salvo lo que tenga que ser JavaScript". Para un sitio de marketing — landing, blog, casos, contacto — eso es lo correcto el 95% del tiempo.
Lo que ganamos, en concreto
1. Crawleabilidad real para LLMs y buscadores. Cada página de empiredmc.com ahora es legible al primer pedido. Cuando un modelo decide citar fuentes en una respuesta, nuestro contenido está disponible para ser citado. Antes, no.
2. Velocidad de carga notablemente mejor. El sitio carga sustancialmente más rápido en la mayoría de las condiciones, especialmente la primera vista (lo que el usuario ve antes de hacer scroll). No es magia: simplemente hay menos JavaScript que el browser tiene que descargar, parsear y ejecutar antes de mostrar la página.
3. Costo de iteración mucho más bajo. Pasamos de "modificar JSX, commit, deploy" a un sistema donde el blog vive en Notion (escribir → marcar Published → live en 2-3 minutos), las landings se editan en Markdown, y los componentes interactivos se mantienen aislados sin afectar al resto. Para un equipo chico que necesita iterar contenido todas las semanas, esto se siente cada semana.
4. SEO técnico que no depende de la fe. Schema.org en cada página, meta tags servidos directo, sitemap limpio, redirects 308 bien configurados. Cosas que con SPA siempre requieren parches y plugins, y que en Astro vienen de fábrica.
Cuándo no tiene sentido migrar
Si tu sitio es una aplicación real — un dashboard, un SaaS, una herramienta interactiva — quedate en SPA. Astro no fue hecho para eso, y forzarlo te va a doler.
Pero si tu sitio es de marketing, contenido o presencia (que es el caso de la mayoría de los sitios de empresa), y dependés de tráfico inbound — orgánico, IA, redes —, entonces el costo de seguir siendo invisible para los crawlers de LLMs sube cada mes.
La pregunta no es "¿migrar a Astro?". Es "¿el stack que elegí para mi sitio sigue teniendo sentido en un mundo donde la mitad del descubrimiento empieza en un chat con una IA?". Si la respuesta sincera es no, conviene mover ficha antes de que el costo de seguir invisible se acumule.