Deploy: WordPress en tu servidor, front en el edge

En local, todo esto son dos carpetas en tu ordenador. En producción, dos servicios que se hablan por HTTP. Vamos a ver dónde va cada pieza y —lo que más preocupa a todo el mundo— por qué actualizar WordPress no te va a borrar el contenido.

El mapa

• WordPress: en un hosting PHP normal, en un subdominio privado tipo cms.tudominio.com. Nadie lo visita salvo tú, para editar.
• Front Astro: compilado a HTML estático y desplegado en el edge (Vercel, Netlify, Cloudflare Pages). Es lo que ve el mundo.

El miedo de todos: «¿un update me borra el contenido?»

No. Un update del núcleo de WordPress solo reemplaza wp-admin, wp-includes y los wp-*.php. No toca ni la base de datos (donde vive todo tu contenido) ni wp-content/uploads (tus medios).

El peligro real aparece solo en contenedores: si redespliegas un WordPress en Docker sin volúmenes persistentes, el disco es efímero y vuelve de fábrica. Por eso se separan dos cosas:

• Núcleo (desechable): la imagen de WordPress. Se actualiza sin miedo.
• Estado (persistente): base de datos y medios, en volúmenes que nadie toca.

# docker-compose.yml (resumen)
services:
  wordpress:
    image: wordpress:php8.3-apache   # núcleo desechable
  db:
    image: mysql:8.4
volumes:
  db_data:      # ← tu contenido, intacto entre updates
  wp_uploads:   # ← tus medios, intactos

En Hostinger, paso a paso (lo más sencillo)

Si no quieres gestionar servidores, un hosting como Hostinger te sobra: la persistencia y los backups ya vienen resueltos. Y para actualizar el WordPress desde tu propio agente, lo más cómodo es su despliegue por Git. Se configura una vez:

1. Sube tu carpeta de código (los mu-plugins) a un repositorio de GitHub.
2. En hPanel: Websites → tu web → Dashboard → Advanced → Git.
3. Conecta el repo, elige la rama main y como carpeta destino public_html/wp-content/mu-plugins.
4. Activa el auto-deploy.

A partir de ahí, actualizar es un git push —el mismo gesto que el front—. ¿No quieres montar Git? Arrastra el archivo por SFTP con FileZilla y listo.

Un detalle: CORS

Si el front pide los datos solo en el build (como aquí), las peticiones son de servidor a servidor y CORS ni interviene. Solo si haces fetch desde el navegador tendrás que abrir el origen del front en el mu-plugin.

El flujo de publicación

1. Escribes y pulsas «Publicar» en WordPress.
2. Un webhook avisa a la plataforma del front.
3. Astro vuelve a pedir el contenido y regenera el HTML.
4. En segundos, el cambio está online en toda la CDN.

Editas con la comodidad de WordPress. Sirves con la velocidad y la seguridad de un sitio estático. Y si mañana cambias el front entero, el contenido ni se entera.

Que lo despliegue tu agente

Prepárame el deploy siguiendo la skill wp-wow: el front Astro
en Vercel con un deploy hook, y el WordPress en Hostinger con despliegue
por Git hacia wp-content/mu-plugins. Explícame cómo conectar el webhook
de publicación para que el front se reconstruya solo al publicar.

Ya está en el aire. Última pieza: cómo hacerlo crecer sin miedo.