Astro o WordPress: cuál elegir para tu web corporativa

La diferencia de fondo: cuándo se genera el HTML

WordPress genera la página en el momento en que alguien la pide: PHP consulta la base de datos, ejecuta las extensiones activas y devuelve el HTML. Con caché ese trabajo se hace una vez y se reutiliza, que es por lo que casi todo WordPress serio lleva caché.

Astro genera el HTML una sola vez, al desplegar. Lo que queda son archivos estáticos que se copian a una red de distribución y se sirven desde el punto más cercano al visitante. No hay base de datos que consultar en tiempo real ni proceso que pueda saturarse.

De esa diferencia salen casi todas las demás: la velocidad, la superficie de ataque, el coste de alojamiento y lo que ocurre cuando llega un pico de tráfico inesperado.

Dónde gana Astro

En rendimiento, con distancia. Astro no envía JavaScript al navegador salvo donde hay interacción real, así que una página de servicios llega como HTML y CSS y poco más. Un WordPress con plantilla comercial arrastra jQuery, los scripts de cada extensión y con frecuencia un constructor visual entero.

En seguridad, porque no hay nada que ejecutar en el servidor. La lista de vulnerabilidades de WordPress no está en su núcleo, que se mantiene bien, sino en la larga cola de extensiones de terceros que nadie actualiza.

Y en coste de operación: alojamiento estático que en la mayoría de proyectos entra en un plan gratuito, sin actualizaciones semanales obligatorias ni copias de seguridad de base de datos que vigilar.

Dónde sigue ganando WordPress

En el ecosistema. Si necesitas reservas con calendario, una zona privada de socios, un foro o una integración con un sistema de facturación concreto, es muy probable que exista una extensión que lo resuelve esta misma tarde. Reconstruir eso a medida cuesta bastante más.

En la disponibilidad de gente. Encontrar a alguien que sepa mantener un WordPress es trivial en cualquier ciudad; encontrar a alguien con experiencia en Astro es más difícil, aunque sea un framework más sencillo de aprender.

Y en la costumbre. Si tu equipo lleva ocho años publicando en el editor de WordPress y funciona, cambiar de herramienta tiene un coste real que hay que poner en la balanza, no despacharlo como resistencia al cambio.

Cómo decidimos nosotros

Cuatro preguntas, en este orden:

• ¿La web es sobre todo contenido publicado y leído, o hay sesiones, permisos y datos de usuario? Si hay sesiones de verdad, WordPress o una aplicación a medida.
• ¿Cuántas personas publican y con qué frecuencia? Un gestor headless cubre bien de una a diez personas; con redacciones grandes y flujos de aprobación complejos, WordPress tiene ventaja.
• ¿Cuánto duele que la web vaya lenta? En captación con publicidad de pago, mucho: cada décima cuesta dinero medible.
• ¿Quién va a mantenerla dentro de dos años? Si la respuesta es «un proveedor local cualquiera», eso pesa a favor de WordPress y hay que decirlo.

Y si migro, ¿qué pasa con el posicionamiento?

No pasa nada si la migración se hace bien, y pasa un desastre si se hace mal. La parte que importa es el inventario de URLs: qué direcciones existen hoy, cuáles reciben tráfico y enlaces, y a qué página nueva va a corresponder cada una.

Cada URL antigua acaba en una de dos listas: se conserva igual, o se redirige de forma permanente a su equivalente. Las redirecciones se escriben a mano, se comprueban antes de lanzar y se vuelven a comprobar la semana siguiente en Search Console. Con eso, la caída de tráfico típica de las primeras semanas se recupera en poco tiempo, y a partir de ahí la mejora de velocidad juega a favor.