En 2021 un cliente vino a mí con un brief que había escuchado aproximadamente cuarenta veces antes: "Queremos el backend de WordPress que conocen nuestros editores, pero el sitio necesita ser rápido. Muy rápido". Habían leído algo sobre arquitectura headless en una página de marketing de Vercel. Estaban convencidos antes de que dijera una palabra. Tomé el proyecto, construí un frontend Next.js en Vercel extrayendo contenido de una API REST de WordPress, y entregué algo genuinamente impresionante. Las puntuaciones de Lighthouse eran hermosas. Al cliente le encantó durante aproximadamente tres meses.fast. Like, really fast." They'd read something about headless architecture on a Vercel marketing page. They were sold before I said a word. I took the project, built a Next.js frontend on Vercel pulling content from a WordPress REST API, and delivered something genuinely impressive. The Lighthouse scores were beautiful. The client loved it for about three months.
Luego su gerente de marketing quiso agregar un formulario emergente. Luego un plugin de membresía. Luego chat en vivo con lógica condicional vinculada a categorías de publicaciones. Y lentamente, silenciosamente, toda la configuración comenzó a crujir.
Ese proyecto me enseñó más sobre los límites reales de WordPress headless que cualquier tutorial jamás lo hizo. Así que permíteme darte la imagen honesta.
Qué Significa Realmente "WordPress Headless en Vercel"
Vale la pena ser preciso aquí, porque la gente usa el término de manera vaga.
Estás ejecutando WordPress (generalmente en un servidor separado, un host administrado como Kinsta o WP Engine, o incluso un VPS económico) únicamente como un sistema de gestión de contenidos. Ningún tema sirve el frontend. En su lugar, tu aplicación Next.js (o Nuxt, o Astro, o SvelteKit) obtiene contenido a través de la WordPress REST API o WPGraphQL, y luego Vercel compila e implementa ese frontend.Kinsta or WP Engine, or even a cheap VPS) purely as a content management system. No theme serves the frontend. Instead, your Next.js (or Nuxt, or Astro, or SvelteKit) app fetches content via the WordPress REST API or WPGraphQL, then Vercel builds and deploys that frontend.
Vercel no aloja WordPress en sí. Punto final. WordPress necesita PHP, una base de datos (MySQL) y ejecución del lado del servidor. Vercel ejecuta funciones serverless de Node.js y archivos estáticos. No puedes colocar una instalación de WordPress en Vercel de la misma manera que la colocarías en un servidor cPanel.
Entonces, cuando alguien dice "alojar WordPress en Vercel", lo que realmente significa es: alojar el frontend en Vercel, mientras que WordPress se ejecuta en otro lugar completamente. Esa distinción es enormemente importante, y me sorprende lo a menudo que se pasa por alto en los blogs.frontend on Vercel, while WordPress runs somewhere else entirely. That distinction matters enormously, and I'm shocked how often it gets glossed over in blog posts.
Cuándo esta configuración realmente brilla
Quiero ser justo aquí. He implementado proyectos de WordPress headless + Vercel de los que estoy genuinamente orgulloso, y hay condiciones específicas donde la arquitectura justifica su complejidad.
Sitios editoriales o de medios con mucho tráfico
Seahawk tuvo un proyecto para una editorial de medios deportivos en 2022. Decenas de miles de visualizaciones de página al día, equipo de contenido de doce personas, editores que se negaban rotundamente a abandonar WordPress. Construimos un frontend Next.js en Vercel con Regeneración Estática Incremental (ISR) configurada en ventanas de revalidación de 60 segundos. En un día de gran partido, el servidor WordPress de origen apenas se inmutó. La red edge de Vercel absorbió el pico de tráfico sin una sola conversación sobre escalabilidad.
Para sitios donde el contenido cambia en lotes (los artículos se publican, no se editan cada dos minutos), ISR es un ajuste brillante. Obtienes rendimiento de archivo estático en el edge con contenido razonablemente fresco.
Sitios que necesitan flexibilidad extrema del frontend
Si tu diseñador quiere animaciones de scroll personalizadas, transiciones de componentes complejas, o una herramienta interactiva basada en React insertada en medio de la página, un tema de WordPress tradicional te está peleando todo el tiempo. Un frontend desacoplado le devuelve ese control al desarrollador completamente. Las restricciones de diseño de los temas de WordPress simplemente desaparecen.
Equipos de desarrolladores ya inmersos en el ecosistema Node/React
Si tu equipo despliega aplicaciones React todo el día y trata PHP como un idioma extranjero, forzarlos al desarrollo de temas WordPress es genuinamente doloroso. Headless les permite quedarse en su mundo mientras les da a los editores de contenido una herramienta que ya conocen. Eso es una ganancia real de productividad en el equipo correcto.
El Stack de Herramientas que Realmente Uso
Si estoy usando WordPress headless + Vercel hoy, así se ve el stack:
- Host WordPress: Kinsta o Cloudways. Ambos manejan copias de seguridad de MySQL administradas sin que yo tenga que pensar en ello. Kinsta or Cloudways. Both handle managed MySQL backups without me thinking about it.
- Capa GraphQL: complemento WPGraphQL. Hace que las consultas de contenido sean mucho más limpias que la API REST para tipos de publicación complejos. WPGraphQL plugin. It makes content queries far cleaner than the REST API for complex post types.
- Framework frontend: Next.js. App Router si el equipo se siente cómodo con ello, Pages Router si necesitamos una entrega más rápida a alguien menos experimentado. Next.js. App Router if the team is comfortable with it, Pages Router if we need a faster handoff to someone less experienced.
- Despliegue: Vercel, obviamente. Los despliegues en vista previa por PR valen el precio de entrada por sí solos. Vercel, obviously. Preview deployments per PR are worth the price of admission alone.
- Revalidación bajo demanda: webhooks de WordPress (mediante un complemento personalizado o hooks de Advanced Custom Fields) que alertan a un endpoint de revalidación de Vercel cuando se publica contenido. WordPress webhooks (via a custom plugin or Advanced Custom Fields hooks) that ping a Vercel revalidation endpoint when content is published.
- Contenido en vista previa: el paquete @wpengine/headless o una configuración personalizada de modo de borrador de Next.js para que los editores puedan ver una vista previa de publicaciones no publicadas sin una reconstrucción. The
@wpengine/headlesspackage or a custom Next.js draft mode setup so editors can preview unpublished posts without a rebuild.
Ese último punto sobre previsualizaciones me tomó más tiempo del que me gustaría admitir para hacerlo bien. Los editores esperan hacer clic en "Previsualizar" en WordPress y ver exactamente lo que se publica en vivo. Con una configuración desacoplada, conectar eso correctamente requiere un día sólido de trabajo.
Dónde Falla (Y Falla)
Bien. Aquí es donde tengo que ser honesto contigo, porque esta es la parte que la mayoría de los posts "headless es el futuro" omiten.
Plugins. Tantos plugins.
El poder de WordPress viene de su ecosistema de plugins. WooCommerce, Gravity Forms, plugins de membresía, sistemas de reservas, herramientas SEO avanzadas como Yoast (sí, Yoast sigue funcionando, pero la renderización frontend de sus meta tags requiere cableado adicional), plugins de carrusel, cualquier cosa que toque el frontend. En una configuración tradicional, el plugin renderiza PHP directamente en la página. En una configuración headless, no hace nada visible a menos que hayas construido explícitamente un componente frontend para replicar su salida.
Tenía un cliente a finales de 2023 que vino a mí a mitad del proyecto (no era un proyecto de Seahawk, era un desorden de otro que heredé). Habían ido headless con buenas intenciones y luego intentaron añadir WooCommerce. Lo que siguió fue un desvío de cuatro meses construyendo un flujo de carrito y checkout personalizado en React, llamando a la REST API de WooCommerce, manejando webhooks de Stripe manualmente, y generalmente reinventando ruedas que WooCommerce ya había construido. El costo de tiempo fue aproximadamente tres veces lo que hubiera sido simplemente usar una configuración tradicional de WordPress + WooCommerce.
WooCommerce headless es viable. WooCommerce ha documentado bien su REST API. Pero "viable" y "vale la pena" son preguntas diferentes.WooCommerce has documented their REST API well. But "doable" and "worth it" are different questions.
La experiencia de previsualización nunca coincide completamente
He lanzado seis o siete proyectos headless de WordPress ahora y nunca he tenido un cliente que estuviera completamente satisfecho con el flujo de trabajo de previsualización. Siempre hay una brecha entre hacer clic en "Previsualizar" en WordPress y ver lo que realmente se renderiza. A veces es un problema de cookie en modo borrador. A veces es timing de caché ISR. Los editores que vinieron de una configuración tradicional de WordPress lo encuentran desorientador, y las quejas llegan silenciosamente pero persistentemente.
Dos sistemas para mantener
Esto suena obvio pero genuinamente se les escapa a los equipos. Ahora estás ejecutando dos preocupaciones de infraestructura separadas: el servidor WordPress (con sus propias actualizaciones, parches de seguridad, conflictos de plugins, backups de base de datos) y el frontend de Vercel (con su propio pipeline de build, variables de entorno, límites de funciones serverless). Cuando algo se rompe a las 2am, tienes el doble de lugares donde buscar.
En Seahawk hemos tenido proyectos donde un plugin de WordPress se actualizó automáticamente y cambió silenciosamente la forma de una respuesta de REST API, lo que rompió un componente del frontend. Sin error lanzado en el lado de WordPress. Solo un vacío de contenido silencioso en el sitio en vivo. Ese tipo de fallo es genuinamente más difícil de detectar que un error tradicional de WordPress.
El contenido en tiempo real es incómodo
Si tu sitio tiene contenido que cambia frecuentemente (piensa en puntuaciones en vivo, precios de acciones, comentarios generados por usuarios, cualquier cosa que necesite actualización en menos de un minuto), el modelo de revalidación de ISR es un ajuste deficiente. Terminas sirviendo datos obsoletos o golpeando tu backend de WordPress en cada solicitud, lo que anula una parte significativa del argumento de rendimiento.
Los Costos: Lo que Nadie Pone en la Propuesta
Déjame ser concreto sobre dinero y tiempo, porque he visto a agencias hacer ofertas bajas en estos proyectos.
- Gastos iniciales de build: Presupuesta al menos 30-40% más tiempo de desarrollo comparado con un build tradicional de WordPress de complejidad equivalente. Esa brecha es real. La he rastreado en proyectos. Budget at least 30-40% more development time compared to a traditional WordPress build of equivalent complexity. That gap is real. I've tracked it across projects.
- Precios de Vercel: El plan Hobby gratuito no será suficiente para trabajo comercial. Pro es $20/mes por usuario, y los costos de ancho de banda y ejecución de funciones serverless se acumulan en sitios de alto tráfico. Ejecuta los números antes de comprometerte. The free Hobby plan won't cut it for commercial work. Pro is $20/month per seat, and bandwidth and serverless function execution costs stack up on high-traffic sites. Run the numbers before you commit.
- Hosting de WordPress: Aún necesitas un host gestionado confiable. Eso es otros $30-100/mes dependiendo del tráfico. Entonces tu narrativa de "hosting estático barato" se desmorona rápidamente. You still need a reliable managed host. That's another $30-100/month depending on traffic. So your "cheap static hosting" narrative falls apart quickly.
- Mantenimiento continuo: Dos plataformas, dos conjuntos de problemas potenciales. Factor en al menos 20% más tiempo de retainer mensual comparado con una configuración tradicional de WordPress gestionado. Two platforms, two sets of potential problems. Factor in at least 20% more monthly retainer time compared to a traditional managed WordPress setup.
Cuándo realmente lo recomendaría
Después de todo lo que acabo de decir, estos son los escenarios específicos donde le diría a un cliente que WordPress headless en Vercel vale la pena por los compromisos:
- El sitio tiene mucho contenido y mucho tráfico de lectura: principalmente artículos o landing pages, no flujos transaccionalescontent-heavy and read-heavy: mostly articles or landing pages, not transactional flows
- El equipo de contenido ya conoce WordPress y no está dispuesto a cambiar de CMSalready knows WordPress and won't entertain switching CMS
- El rendimiento a escala es un requisito genuino del negocio, no solo algo deseable
- El equipo de desarrollo está cómodo con React y herramientas modernas de JavaScript
- No hay dependencias de plugins complejos en el alcance, o ya los han excluido explícitamente are in the brief, or you've explicitly scoped around them
- Hay un propietario técnico a largo plazo que entiende ambos lados del stack
Y estos son los escenarios donde me opondría:
- El cliente quiere WooCommerce o cualquier función frontend dependiente de plugins
- El equipo es pequeño y no puede asumir la sobrecarga de mantenimiento de dos sistemas
- Los editores necesitan un flujo de preview rápido y familiar, y no hay presupuesto para construirlo correctamente
- El sitio tiene cuentas de usuario, personalización dinámica, o requisitos de datos en tiempo real
- El cliente simplemente lo quiere "porque suena moderno"
Ese último. Lo escucho más de lo que debería.
Alternativas Que Vale la Pena Considerar Primero
Antes de optar por defecto a este stack, al menos pondría estas opciones sobre la mesa:
- WordPress tradicional en un buen host administrado: Kinsta, Cloudways, o Rocket.net con caché adecuado (WP Rocket o Nginx FastCGI cache) te darán puntuaciones de Lighthouse en los 90 sin desacoplar nada. He visto esto sorprender a clientes que asumían que necesitaban ir headless solo para ser rápidos. Kinsta, Cloudways, or Rocket.net with proper caching (WP Rocket or Nginx FastCGI cache) will get you Lighthouse scores in the 90s without decoupling anything. I've seen this surprise clients who assumed they needed to go headless just to be fast.
- Faust.js de WP Engine: Construido específicamente para WordPress headless, maneja mucho del boilerplate (preview mode, autenticación, enrutamiento) que de otro modo tendrías que construir tú mismo. Vale la pena echarle un vistazo si estás comprometido con la arquitectura. Built specifically for headless WordPress, it handles a lot of the boilerplate (preview mode, authentication, routing) that you'd otherwise build yourself. Worth a look if you're committed to the architecture.
- Un CMS headless creado con propósito: Si tu equipo no necesita realmente el ecosistema de plugins de WordPress, algo como Sanity o Contentful podría ser simplemente un ajuste más limpio para un frontend Next.js alojado en Vercel. Sin servidor PHP que mantener en absoluto. If your team doesn't actually need WordPress's plugin ecosystem, something like Sanity or Contentful might just be a cleaner fit for a Vercel-hosted Next.js frontend. No PHP server to maintain at all.
---
FAQ
¿Puedo desplegar WordPress directamente en Vercel?
No. WordPress requiere PHP y una base de datos MySQL. La infraestructura de Vercel está construida alrededor de funciones serverless Node.js y servicio de archivos estáticos. Puedes desplegar tu frontend Next.js (u otro JavaScript) a Vercel, y tener ese frontend obteniendo contenido de una instancia de WordPress alojada en otro lugar, pero WordPress mismo se ejecuta en un servidor separado.
¿El WordPress headless perjudica mi SEO?
No inherentemente, pero puede hacerlo si lo configuras descuidadamente. Con Next.js obtienes renderizado del lado del servidor y generación estática, ambos producen HTML completamente renderizado que los motores de búsqueda pueden indexar sin problemas. Las áreas de riesgo son el manejo de etiquetas meta (la salida de Yoast necesita ser explícitamente consumida y renderizada por tu frontend) y la generación de sitemaps (querrás construir una ruta de sitemap dinámica en Next.js que extraiga de WordPress). Si lo haces bien, el SEO está garantizado.
¿Es el plan gratuito de Vercel suficiente para un frontend WordPress headless?
Para un proyecto personal o prototipo, posiblemente. Para un sitio comercial, no. El plan Hobby prohíbe el uso comercial en los términos de Vercel, y alcanzarás los límites de invocación de funciones serverless en cualquier sitio con tráfico real. Presupuesta el plan Pro desde el primer día.
¿Cómo manejo el modo preview de WordPress en Next.js?
Next.js tiene Draft Mode integrado (anteriormente Preview Mode en el Pages Router). El patrón es: crear una ruta /api/preview en Next.js que establezca una cookie de preview, luego configurar un botón "Preview" de WordPress para llamar a esa ruta con un token secreto. Cuando la cookie está presente, tus componentes de página obtienen contenido de borrador directamente de WordPress en lugar de la versión estática en caché. WPGraphQL soporta consultas de posts en borrador de forma nativa, por eso lo prefiero sobre la REST API para este flujo en particular./api/preview route in Next.js that sets a preview cookie, then configure a WordPress "Preview" button to call that route with a secret token. When the cookie is present, your page components fetch draft content directly from WordPress instead of the cached static version. WPGraphQL supports draft post queries natively, which is why I prefer it over the REST API for this particular flow.
¿Y qué hay con los formularios y páginas de contacto?
Los formularios son una de las migraciones más limpias de plugin a headless. Un envío de Gravity Forms puede publicarse directamente en la API REST de Gravity Forms. Alternativamente, salta los formularios de WordPress por completo y usa algo como Netlify Forms (aunque estés en Vercel) o una integración directa de Formspree en el frontend. Honestamente, para formularios, normalmente solo recurro a Formspree y lo dejo hecho en una tarde.Formspree and call it done in an afternoon.
---
WordPress headless en Vercel es una arquitectura real con casos de uso reales. No es una solución universal ni es un truco de marketing. Los equipos que más sacan provecho son aquellos que entraron con los ojos bien abiertos sobre lo que estaban sacrificando, presupuestaron el tiempo de compilación extra, y tenían un problema específico de rendimiento o flexibilidad que estaban resolviendo. Si eso suena como tu proyecto, vale la pena. Si no es así, ahórrate la complejidad.