No contrates un único hosting «headless» para WordPress, el frontend y las APIs. En una arquitectura desacoplada, cada capa tiene cargas distintas: WordPress prioriza edición y base de datos; Next.js o Astro, entrega y compilación; la CDN, caché global; y las APIs propias, ejecución y límites de consumo.
El mejor hosting para sitios headless y APIs separa WordPress y su base de datos del frontend, la CDN y las funciones o servicios API. Así escalas y presupuestas cada capa según su uso real, aunque debes definir desde el inicio la caché, los webhooks, la autenticación, los límites de las APIs y la monitorización para no trasladar el coste al mantenimiento y las incidencias.
Índice
Anuncio
Elige las capas antes que el proveedor
Un WordPress desacoplado mantenible se contrata por capas, no como un único servidor.
Las seis capas que debes presupuestar
El CMS reúne WordPress, PHP y MySQL o MariaDB; exige copias verificables, restauración granular, WAF y soporte que entienda plugins, cron y webhooks. El frontend necesita CDN, despliegues desde GitHub y entornos preview, mientras que las APIs propias requieren revisar duración, concurrencia, autenticación y registros.
Cuándo no compensa desacoplar
No desacoples si la web es pequeña, depende de plugins visuales o nadie puede mantener dos despliegues, integraciones y alertas.
Pymes y ecommerce: reparto de hosting rentable
Para una pyme o tienda, aloja WordPress en una capa estable y elige el frontend según use SSG, ISR o SSR.
| Opción | Mejor para | SSR y funciones | CDN y regiones UE | Coste operativo |
|---|---|---|---|---|
| Vercel | Next.js con previews | SSR e ISR integrados; vigilar invocaciones | CDN global; regiones configurables | Bajo al inicio, variable con tráfico |
| Netlify | Jamstack y equipos pequeños | Funciones con límites de duración | CDN global incluida | Previsible en sitios estáticos |
| Cloudflare | CDN, WAF y edge runtime | Workers, no backend persistente clásico | Red global; controles de caché finos | Muy competitivo si cacheas bien |
| DigitalOcean o VPS | Node.js, Docker y APIs propias | Control total; tú gestionas límites | Añadir CDN externa | Más horas técnicas |
| AWS, Google Cloud o Azure | SaaS y alta carga | Contenedores, gateways y serverless | Frankfurt e Irlanda disponibles | Flexible, pero requiere gobierno |
CMS cerca de su base de datos
WordPress y su base de datos deben estar cerca entre sí para reducir la latencia de edición, consultas y webhooks. Si recoges clientes o pedidos, documenta los datos que salen de la Unión Europea y los encargados de tratamiento conforme al RGPD y la LOPDGDD.
APIs propias: serverless o contenedores
Una llave de seguridad USB añade una segunda prueba física para acceder a GitHub, al panel del hosting y a cuentas de administración. Es especialmente útil cuando varias personas publican código o gestionan WordPress.
- Reduce el riesgo de acceso por robo de contraseñas en cuentas de despliegue
- Protege cambios de DNS, repositorios y credenciales de producción
- Permite exigir una segunda prueba física a perfiles con permisos críticos
Al comparar opciones, evalúa el CMS headless y el frontend headless como contratos distintos. Para el alojamiento WordPress, verifica versión de PHP, rendimiento de base de datos, copias restaurables, cron, acceso a logs, soporte para webhooks y ubicación de datos. Para el frontend, confirma si admite generación estática SSG, regeneración ISR, renderizado SSR, edge runtime, despliegues desde GitHub, dominios de preview y rollback inmediato.
El hosting de APIs debe especificar concurrencia, tiempos máximos de ejecución, conexiones salientes, secretos, regiones y límites de base de datos. Una plataforma puede ser excelente para publicar páginas estáticas y resultar insuficiente para una API con procesos largos o tráfico autenticado.
Cuando una aplicación tiene una API REST propia, conviene colocar un gateway delante de los servicios Node.js, contenedores Docker o funciones serverless. El gateway centraliza autenticación, CORS, rate limiting, cuotas por cliente, versionado de rutas y validación básica de peticiones antes de que lleguen al backend. Por ejemplo, una API pública de SaaS puede publicar /v1/ mientras prepara cambios incompatibles en /v2/, aplicar un límite distinto a cada token y bloquear patrones abusivos en el WAF.
Las tareas de larga duración, como importar catálogos o generar informes, deben pasar a una cola; la API devuelve un identificador de trabajo y un proceso independiente lo completa sin agotar el tiempo de respuesta.
Anuncio
SSR, ISR y CDN: rendimiento sin factura sorpresa
SSG e ISR reducen latencia y coste porque la CDN sirve copias preparadas, mientras SSR ejecuta código por visita.
Purga selectiva con webhooks
Un webhook avisa cuando WordPress publica, edita o borra contenido y debe revalidar solo la URL, etiqueta o colección afectada. Protégelo con firma secreta, registros y reintentos: una URL abierta permitiría forzar reconstrucciones y aumentar costes.
Qué rutas deben quedar fuera
No guardes en CDN respuestas con JWT, cookies de sesión, cabeceras Authorization, datos de cliente o checkout. Define reglas para /mi-cuenta/, /carrito/, búsquedas privadas y endpoints internos; además, limita las peticiones de la API REST y WPGraphQL.
Protege APIs y opera sin puntos ciegos
Una API expuesta necesita autenticación, rate limiting, WAF, registros y un plan de restauración probado.
Alertas, logs y recuperación
Registra errores 4xx y 5xx, duración de funciones, fallos de webhook, uso de base de datos y tasa de aciertos de CDN. Las copias deben incluir WordPress, base de datos, archivos subidos y configuración, y debes probar una recuperación cada 3 o 6 meses.
Checklist antes de contratar
Comprueba backups, previews, límites de ejecución, reglas de caché, MFA, secretos, CORS, rate limiting, rollback y restauración sin depender de una sola persona.
El presupuesto de una arquitectura headless no debe basarse solo en la cuota del proveedor. Separa el coste fijo del CMS, la base de datos, el almacenamiento de medios y los entornos de prueba del coste variable de CDN global, egress, solicitudes al origen, renderizado SSR, regeneración ISR, invocaciones de funciones serverless y retención de logs. Un sitio editorial con caché de página y generación estática SSG puede servir muchas visitas con poco cómputo, mientras que un ecommerce con búsquedas, personalización y checkout puede incrementar las peticiones no cacheables.
Calcula también la monitorización, las copias externas, las alertas y el margen para picos de tráfico; así detectas qué capa encarece cada lanzamiento antes de comprometerte con un plan anual.
Preguntas y respuestas
¿Qué es WordPress headless?
WordPress headless usa WordPress para gestionar contenido y un frontend independiente para mostrarlo. La conexión suele hacerse mediante API REST de WordPress o WPGraphQL, que entrega datos en lugar de una página HTML completa.
¿Cuál es el mejor hosting headless?
El mejor hosting headless combina proveedores según CMS, frontend, API y CDN. Para una web editorial, WordPress gestionado más SSG o ISR suele bastar; para SaaS con API pública, añade gateway, límites y backend propio.
¿Cuándo conviene usar SSR en next.js?
SSR conviene cuando el HTML cambia para cada usuario o depende de datos en tiempo real. Úsalo en cuentas, checkout y permisos; evita usarlo en artículos o páginas corporativas que una CDN puede servir sin ejecutar código.
¿Necesito una CDN si uso vercel o cloudflare?
Sí, aunque muchas plataformas ya incluyen CDN como parte del servicio. Debes configurar qué rutas se almacenan, cuánto tiempo se conservan y cuáles quedan fuera por llevar sesión o datos privados.
¿Cómo actualizo una página al publicar en WordPress?
Un webhook firmado debe avisar al frontend para revalidar solo la URL afectada. Si no existe ese flujo, el visitante puede seguir viendo contenido antiguo hasta que expire la caché o se reconstruya todo el sitio.
¿Es seguro exponer la API REST de WordPress?
Sí, si separas contenido público de acciones privadas y aplicas controles adecuados. Protege las operaciones de escritura con JWT u OAuth 2.0, limita peticiones y revisa registros de acceso para detectar abusos.
¿Cuánto cuesta mantener una arquitectura headless?
Una arquitectura sencilla suele sumar entre 60 y 180 euros mensuales antes de desarrollo y soporte especializado. El coste sube con SSR, egress, funciones, bases de datos, retención de logs y picos de tráfico.
- Separa WordPress, frontend, APIs y CDN para elegir recursos adecuados a cada carga.
- Usa SSG o ISR en contenido público y reserva SSR para datos personalizados.
- Diseña webhooks, purgas y exclusiones de caché antes de lanzar el sitio.
- Calcula tráfico, egress, logs y soporte, no solo la cuota mensual inicial.
Anuncio
Fuentes de interés
Otros artículos que pueden complementar lo que acabas de leer:
- What Is Headless WordPress (And How Do You Use It)? — wordpress.com
- How Headless WordPress and REST APIs Power Modern ... — pantheon.io
- ¿Qué es Headless WordPress? — inspectwp.com
- ACF | What Is Headless WordPress and Is It Worth It? — advancedcustomfields.com
- El error de llevar tu portal a Headless sin presupuesto
- Tu startup no gana velocidad ni conversión por ser headless
Josu Barrios
Somos especialistas en mantenimiento WordPress para empresas, profesionales y tiendas online. Contamos con experiencia en seguridad web, optimización de rendimiento, actualizaciones, copias de seguridad y resolución de incidencias técnicas, ayudando a que cada sitio funcione de forma rápida, estable y protegida. Nuestro enfoque combina soporte técnico profesional, buenas prácticas de seguridad y seguimiento continuo para ofrecer un servicio fiable, transparente y orientado a resultados reales.