WordPress Headless CMS: Guía para Desarrolladores [2026]

WordPress Headless CMS: Guía para Desarrolladores [2026]

WordPress impulsa el 43% de todos los sitios web según W3Techs, y cada vez más equipos eliminan el frontend en PHP por completo para usarlo como una API de contenido. Aquí tienes todo lo que necesitas saber para ejecutar WordPress en modo headless — desde elegir entre REST API y WPGraphQL hasta desplegar un frontend Next.js en Vercel con ISR.

¿Qué es WordPress Headless? (¿Y Por Qué Debería Importarte?)

WordPress headless es una configuración en la que WordPress gestiona el contenido y el almacenamiento mientras una aplicación frontend independiente — construida con Next.js, Nuxt, Astro o cualquier otro framework — obtiene ese contenido a través de una API. WordPress conserva su panel de administración, el editor, el ecosistema de plugins y la base de datos MySQL. Pero en lugar de renderizar páginas con temas PHP, expone el contenido a través de la WordPress REST API o WPGraphQL, y tu frontend se encarga enteramente de la capa de presentación.

Piénsalo así: WordPress se convierte en la cocina y tu framework frontend es el restaurante. La cocina prepara la comida (el contenido), pero el restaurante decide cómo emplatarla, cómo decorar el salón y qué experiencia tendrán los comensales.

Arquitectura Tradicional vs Headless

En WordPress tradicional, todo es un monolito. Un visitante solicita una página, PHP procesa la petición, consulta MySQL, lo pasa por los archivos de plantilla de tu tema y devuelve HTML renderizado. El tema controla el diseño, los estilos, el enrutamiento — todo.

En WordPress headless, eliminas toda esa capa de renderizado. WordPress vive detrás de una API, normalmente en hosting gestionado como WP Engine o Kinsta. Tu frontend — una app de React, Vue o Svelte — hace peticiones a la API para obtener el contenido y luego lo renderiza como quieras. Los dos sistemas pueden vivir en servidores completamente distintos, stacks tecnológicos diferentes y pipelines de despliegue independientes.

Hay un matiz que el 90% de las guías pasan por alto: desacoplado y headless no significan exactamente lo mismo. WordPress desacoplado puede seguir recurriendo al renderizado PHP para ciertas páginas (como el área de administración o rutas antiguas). Completamente headless significa que el frontend de WordPress está totalmente desactivado — solo API, sin renderizado de temas. En esta guía nos centramos en el enfoque completamente headless.

Cuándo Apostar por Headless (y Cuándo Quedarse Tradicional)

Ir a headless tiene sentido cuando tu equipo tiene desarrolladores frontend que quieren trabajar con herramientas modernas, cuando necesitas distribuir contenido en múltiples canales (web, app móvil, cartelería digital) o cuando el rendimiento no es negociable. No tiene sentido para todo el mundo, y ser honesto al respecto te ahorrará semanas de trabajo inútil.

Opta por Headless Cuando...

• Tu equipo ya conoce React/Vue/Svelte. Si tus desarrolladores frontend escriben JSX todo el día, obligarles a trabajar con temas PHP es como pedirle a un chef que cocine con microondas.
• Necesitas distribución multicanal. Un backend WordPress puede alimentar tu sitio de marketing, tu app móvil y el quiosco de tu tienda a través de la misma API.
• El rendimiento es un requisito irrenunciable. Las páginas estáticas servidas desde un edge CDN siempre superarán al renderizado PHP en un servidor compartido.
• Estás ejecutando WooCommerce headless. Los frontends complejos de e-commerce se benefician enormemente de storefronts personalizados con React/Next.js.
• Quieres la experiencia de desarrollo moderna. Hot module replacement, TypeScript, librerías de componentes, CI/CD — toda la cadena de herramientas frontend.

Quédate Tradicional Cuando...

• Los editores necesitan vista previa en vivo y page builders. Gutenberg, Elementor y WPBakery asumen un tema tradicional. Pasarse a headless rompe la mayoría de los flujos de edición visual.
• Eres un desarrollador solo o un equipo pequeño. Headless añade un 40-60% más de complejidad en la configuración. Si solo tú mantienes un blog, un tema tradicional es más sencillo.
• Dependes mucho de plugins de frontend. Formularios de contacto, plugins de SEO (Yoast renderiza meta tags en el servidor), banners de cookies — todos asumen renderizado PHP.
• El presupuesto es ajustado. Necesitarás hosting separado para WordPress y tu frontend. Eso son dos facturas en lugar de una.

REST API vs WPGraphQL: Elegir la Capa de Datos

WordPress te ofrece dos formas de obtener contenido en una configuración headless: la REST API integrada y el plugin WPGraphQL. La REST API viene con el núcleo de WordPress y funciona sin configuración adicional. WPGraphQL requiere instalar un plugin, pero te permite consultar exactamente los campos que necesitas, eliminando el problema del over-fetching que padece REST. En nuestra experiencia, WPGraphQL gana en la mayoría de proyectos, aunque REST tiene una ventaja infravalorada: la caché HTTP nativa.

WordPress REST API: La Opción Integrada

La REST API está disponible en cada instalación de WordPress desde la versión 4.7 (diciembre de 2016). Llama a /wp-json/wp/v2/posts y obtienes JSON de vuelta. Simple, bien documentada y funciona sin ninguna configuración.

¿El problema? El over-fetching. Cuando solicitas un post, WordPress devuelve todo: contenido renderizado, contenido en crudo, extracto, ID del autor, ID del medio destacado, categorías, etiquetas, campos meta, GUID, estado de comentarios, estado de ping, plantilla, y unos 15 campos más que probablemente no necesitas. Para una página de listado de blog donde solo necesitas títulos, slugs y extractos, estás transfiriendo entre 3 y 5 veces más datos de los necesarios.

// REST API: Obtener 5 posts recientes con autor y categorías
const res = await fetch(
  'https://your-site.com/wp-json/wp/v2/posts?per_page=5&_embed'
);
const posts = await res.json();

// El parámetro _embed incluye objetos de autor y categoría
// Pero también incluye TODOS los campos de cada post -- ~8KB por post
// Para 5 posts, estás mirando ~40KB de JSON

Puedes usar el parámetro _fields para limitar los campos devueltos (?_fields=id,title,slug,excerpt), pero no ayuda con los recursos incrustados y seguirás haciendo múltiples peticiones si necesitas datos relacionados.

WPGraphQL: Consulta Lo Que Necesitas

WPGraphQL es un plugin de código abierto y gratuito de Jason Bahl (ahora mantenido por WP Engine) que añade una API GraphQL completa a WordPress. Escribes una consulta especificando exactamente qué campos quieres, y obtienes exactamente eso — nada más.

# WPGraphQL: Misma consulta -- 5 posts recientes con autor y categorías
query RecentPosts {
  posts(first: 5) {
    nodes {
      title
      slug
      excerpt
      date
      author {
        node {
          name
        }
      }
      categories {
        nodes {
          name
          slug
        }
      }
    }
  }
}

# Respuesta: ~2KB de JSON con estructura precisa
# Sin campos extra, sin bloat

Comparación Lado a Lado

Así se ven realmente los payloads de respuesta:

¿Cuál Deberías Elegir?

Usa REST cuando estás construyendo algo rápido, tu equipo no conoce GraphQL, o necesitas caché HTTP agresiva sin herramientas adicionales.

Usa WPGraphQL cuando estás construyendo un frontend de producción con necesidades complejas de datos, quieres payloads más pequeños, o tu equipo ya usa GraphQL en otros proyectos.

Veredicto: Para un proyecto serio de WordPress headless con Next.js, WPGraphQL es la mejor opción. El ahorro en payload, la experiencia de desarrollo con el IDE GraphiQL y la obtención de datos en una sola petición justifican la dependencia del plugin.

Configurar WordPress como CMS Headless

Configurar WordPress como CMS headless implica seis pasos: instalar WordPress, añadir los plugins correctos, configurar tu modelo de contenido, deshabilitar el tema frontend, configurar la autenticación y verificar que tu API funciona. Todo el proceso lleva unos 30-45 minutos si ya lo has hecho antes, o un par de horas la primera vez.

Paso 1: Comienza con una instalación limpia de WordPress en hosting gestionado. Kinsta, WP Engine y Cloudways ofrecen entornos optimizados para WordPress. Si solo estás experimentando, una instalación local con LocalWP funciona perfectamente.

Paso 2: Instala los plugins esenciales:

Paso 3: Crea tu modelo de contenido con ACF. Define grupos de campos que se correspondan con tus componentes frontend. Un tipo de post de portfolio podría tener campos para projectUrl, techStack (repetidor), clientName y projectYear.

Plugins Esenciales

WPGraphQL for ACF merece atención especial. Sin él, tus campos ACF no aparecerán en las consultas GraphQL. Tras instalarlo, puedes consultar campos personalizados así:

query PortfolioProjects {
  projects(first: 10) {
    nodes {
      title
      slug
      projectFields {
        projectUrl
        clientName
        techStack
        projectYear
      }
    }
  }
}

Deshabilitar el Frontend de WordPress

Paso 4: No quieres que los visitantes lleguen a tu URL de WordPress y vean un tema roto. Añade esto al functions.php de tu tema o usa un mu-plugin:

// Redirigir todas las peticiones frontend a la API
add_action('template_redirect', function () {
    if (!is_admin() && !wp_doing_ajax() && !defined('REST_REQUEST') && !defined('GRAPHQL_REQUEST')) {
        wp_redirect('https://your-frontend-domain.com');
        exit;
    }
});

Paso 5: Configura Application Passwords para la autenticación. Ve a Usuarios > Tu Perfil > Application Passwords, genera una contraseña y úsala para peticiones API autenticadas (crear o actualizar contenido desde herramientas externas).

Probar tu API

Paso 6: Abre el navegador y accede a https://your-site.com/graphql — deberías ver el IDE GraphiQL. Prueba a consultar tus posts. Si usas REST, navega a https://your-site.com/wp-json/wp/v2/posts y verifica que obtienes JSON.

Consejo pro: el IDE GraphiQL que incluye WPGraphQL es genuinamente excelente para explorar tu schema. Tienes autocompletado, documentación e historial de consultas. Es la forma más rápida de descubrir qué campos están disponibles y cómo están estructurados tus datos ACF.

Construir un Frontend Next.js con WPGraphQL

La forma más limpia de construir un frontend WordPress headless en 2026 es con el App Router de Next.js 15 y React Server Components. Los Server Components obtienen datos en el servidor sin enviar JavaScript al cliente, y WPGraphQL te da consultas precisas — es una combinación natural. Cuando configuré WPGraphQL con Next.js App Router por primera vez, el mayor problema fue el manejo de imágenes — pero llegaremos a eso.

Configuración del Proyecto y Variables de Entorno

Empieza con un proyecto Next.js nuevo. Vercel también ofrece una plantilla oficial para WordPress si quieres una arquitectura de referencia.

npx create-next-app@latest my-wp-frontend --typescript --app
cd my-wp-frontend

Crea .env.local con tus endpoints de WordPress:

WORDPRESS_API_URL=https://your-wordpress-site.com
NEXT_PUBLIC_WORDPRESS_GRAPHQL_ENDPOINT=https://your-wordpress-site.com/graphql

Ahora crea una utilidad ligera de fetch GraphQL. No necesitas Apollo ni urql para Server Components — el fetch nativo funciona perfectamente porque no hay estado del lado del cliente que gestionar:

// lib/wordpress.ts
const API_URL = process.env.NEXT_PUBLIC_WORDPRESS_GRAPHQL_ENDPOINT!;

export async function fetchGraphQL<T>(
  query: string,
  variables?: Record<string, unknown>
): Promise<T> {
  const res = await fetch(API_URL, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ query, variables }),
    next: { revalidate: 3600 }, // ISR: revalidar cada hora
  });

  const json = await res.json();
  if (json.errors) {
    throw new Error(json.errors[0].message);
  }
  return json.data;
}

Para opciones de framework React, consulta nuestra comparación de Next.js vs React con Vite — hay razones válidas para saltarse el framework, aunque para trabajo con CMS headless, el SSR e ISR integrados hacen de Next.js la elección práctica. Y si estás debatiendo entre Next.js y Remix, lo analizamos en nuestro post sobre por qué recomendamos Next.js para la mayoría de proyectos.

Obtener Posts con Server Components

Aquí está la página de listado del blog como Server Component — sin useEffect, sin estados de carga, sin hidratación en el cliente:

// app/blog/page.tsx
import { fetchGraphQL } from '@/lib/wordpress';
import Link from 'next/link';

interface PostsData {
  posts: {
    nodes: Array<{
      title: string;
      slug: string;
      excerpt: string;
      date: string;
      author: { node: { name: string } };
    }>;
  };
}

const POSTS_QUERY = `
  query AllPosts {
    posts(first: 20, where: { status: PUBLISH }) {
      nodes {
        title
        slug
        excerpt
        date
        author {
          node {
            name
          }
        }
      }
    }
  }
`;

export default async function BlogPage() {
  const data = await fetchGraphQL<PostsData>(POSTS_QUERY);

  return (
    <main>
      <h1>Blog</h1>
      {data.posts.nodes.map((post) => (
        <article key={post.slug}>
          <Link href={`/blog/${post.slug}`}>
            <h2>{post.title}</h2>
          </Link>
          <p>{post.author.node.name} · {new Date(post.date).toLocaleDateString()}</p>
          <div dangerouslySetInnerHTML={{ __html: post.excerpt }} />
        </article>
      ))}
    </main>
  );
}

Páginas de Posts Dinámicas

Las páginas de posts individuales usan generateStaticParams para pre-renderizar todos los posts en el momento de la compilación; luego ISR recoge el contenido nuevo:

// app/blog/[slug]/page.tsx
import { fetchGraphQL } from '@/lib/wordpress';
import { notFound } from 'next/navigation';

const POST_QUERY = `
  query PostBySlug($slug: ID!) {
    post(id: $slug, idType: SLUG) {
      title
      content
      date
      author {
        node {
          name
          avatar {
            url
          }
        }
      }
      categories {
        nodes { name slug }
      }
    }
  }
`;

export async function generateStaticParams() {
  const data = await fetchGraphQL<{
    posts: { nodes: Array<{ slug: string }> };
  }>(`query { posts(first: 100) { nodes { slug } } }`);

  return data.posts.nodes.map((post) => ({ slug: post.slug }));
}

export default async function PostPage({
  params,
}: {
  params: Promise<{ slug: string }>;
}) {
  const { slug } = await params;
  const data = await fetchGraphQL<{ post: any }>(POST_QUERY, {
    slug,
  });

  if (!data.post) notFound();

  return (
    <article>
      <h1>{data.post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: data.post.content }} />
    </article>
  );
}

No olvides configurar next.config.ts para las imágenes de WordPress:

// next.config.ts
const nextConfig = {
  images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: 'your-wordpress-site.com',
        pathname: '/wp-content/uploads/**',
      },
    ],
  },
};

export default nextConfig;

Desplegar WordPress Headless en Producción

Una configuración de WordPress headless en producción usa hosting dual: WordPress vive en hosting gestionado de WordPress (WP Engine, Kinsta o Cloudways), mientras el frontend Next.js se despliega en una plataforma edge como Vercel o Netlify. Esta separación permite que cada capa escale de forma independiente — WordPress gestiona la edición de contenido y las peticiones a la API, mientras el frontend sirve páginas estáticas e ISR desde nodos CDN edge en todo el mundo.

Arquitectura de Hosting

El flujo de datos es este: los editores publican en el panel de administración de WordPress, WordPress almacena el contenido en MySQL, el frontend Next.js obtiene el contenido vía WPGraphQL, Vercel genera HTML estático en el edge, y los visitantes llegan al CDN — sin tocar WordPress directamente.

Para el hosting del frontend, consulta nuestra comparación de Vercel vs Netlify para un análisis detallado. Ambos funcionan bien con WordPress headless. Si estás considerando alternativas basadas en contenedores, nuestra comparación de Railway, Render y Fly.io cubre esas opciones también.

ISR y Revalidación Bajo Demanda

Esta es la parte que hace que WordPress headless sea realmente viable en producción. En nuestra experiencia, la revalidación bajo demanda vale el esfuerzo de configuración, porque sin ella tienes que elegir entre contenido desactualizado (intervalos de revalidación largos) y compilaciones lentas (intervalos cortos que saturan tu API de WordPress).

ISR te permite establecer un tiempo revalidate en cada página. Pasado ese intervalo, el siguiente visitante recibe la página en caché mientras Next.js la regenera en segundo plano. Pero la verdadera magia es la revalidación bajo demanda — disparar una recompilación en el instante en que se publica contenido:

// app/api/revalidate/route.ts
import { revalidatePath } from 'next/cache';
import { NextRequest, NextResponse } from 'next/server';

export async function POST(request: NextRequest) {
  const secret = request.headers.get('x-revalidation-secret');

  if (secret !== process.env.REVALIDATION_SECRET) {
    return NextResponse.json({ message: 'Invalid secret' }, { status: 401 });
  }

  const body = await request.json();
  const slug = body.post?.post_name;

  if (slug) {
    revalidatePath(`/blog/${slug}`);
    revalidatePath('/blog'); // También revalida la página de listado
  }

  return NextResponse.json({ revalidated: true });
}

En el lado de WordPress, añade un webhook que se dispare en publish_post usando un plugin como WP Webhooks o un fragmento simple de functions.php que llame a tu endpoint /api/revalidate de Vercel. Así el contenido se publica en segundos después de pulsar "Publicar" — sin compilaciones completas, sin esperas. Consulta la documentación de ISR de Next.js para más opciones de configuración.

Desglose de Costes

WordPress Headless vs CMS Headless Nativos

Después de trabajar tanto con WordPress headless como con CMSes nativos como Sanity, Contentful y Strapi, aquí va mi opinión honesta: WordPress headless es una opción pragmática cuando tienes un sitio WordPress existente o un equipo de contenido ya familiarizado con él. Rara vez es la mejor opción cuando comienzas desde cero.

Dónde Gana WordPress Headless

• Los editores ya lo conocen. La interfaz de administración de WordPress tiene 20 años de refinamiento. Formar a un equipo no técnico en Sanity Studio o la interfaz de Contentful lleva semanas.
• Ecosistema de plugins. Más de 60.000 plugins. ¿Necesitas multilingüe? WPML. ¿E-commerce? WooCommerce. ¿Análisis SEO de contenido? Yoast (sigue funcionando en el admin). Ningún CMS nativo headless iguala esta amplitud.
• Contratación. WordPress tiene el mayor pool de talento desarrollador de cualquier CMS. Encontrar un desarrollador WordPress es dramáticamente más fácil que encontrar un especialista en Sanity o Payload.
• WooCommerce. Si necesitas e-commerce headless con contenido WordPress, WooCommerce + WPGraphQL es un stack probado. Saleor y Medusa son alternativas, pero WooCommerce tiene la cuota de mercado.

Dónde Ganan los CMSes Nativos Headless

• Modelado de contenido. GROQ de Sanity, los tipos de contenido de Contentful y el schema TypeScript de Payload están diseñados para contenido estructurado desde cero. El modelo post/página/tipo-de-post-personalizado de WordPress parece ensamblado a posteriori.
• Colaboración en tiempo real. Sanity tiene edición en tiempo real al estilo Google Docs. Contentful tiene colaboración en vivo. ¿WordPress? Obtienes una pantalla de bloqueo con "Este post está siendo editado por otra persona".
• Arquitectura API-first. WPGraphQL es brillante, pero sigue siendo un plugin sobre un monolito PHP. La API de Contentful y la de Sanity fueron diseñadas API-first desde el primer día.
• Gestión de medios. La biblioteca de medios de WordPress es funcional pero básica. El pipeline de imágenes de Sanity con recortes automáticos, hotspots y entrega CDN es otra categoría. Contentful y Storyblok se integran con Cloudinary de forma nativa.
• Experiencia del desarrollador. Strapi y Payload te dan una experiencia de desarrollo local con hot-reload en los cambios de schema. WordPress requiere refrescar el admin y ejecutar migraciones de base de datos.

Veredicto: ¿Cuál Deberías Elegir?

Usa WordPress headless cuando: tienes un sitio WordPress existente con años de contenido, tus editores se niegan a aprender un nuevo CMS, necesitas WooCommerce o dependes de un plugin específico de WordPress sin equivalente en otros lugares.

Elige un CMS headless nativo cuando: comienzas un proyecto desde cero, necesitas colaboración en tiempo real, tu modelo de contenido es complejo y estructurado, o tu equipo valora la experiencia del desarrollador por encima de la amplitud de plugins.

En Techsy, hemos construido frontends WordPress headless para clientes que migran desde WordPress tradicional. Nuestro enfoque habitual: WPGraphQL + Next.js App Router en Vercel, con ISR para rendimiento y revalidación bajo demanda para que el contenido esté siempre fresco. Solicita una consulta gratuita →

WordPress MCP y la Abilities API: El Futuro con IA

WordPress 6.9 introdujo la Abilities API, que se está integrando en el núcleo de WordPress 7.0 (abril de 2026). Crea una interfaz estándar, tipada y descubrible para la funcionalidad de WordPress — piensa en ello como WordPress exponiendo sus capacidades en un formato legible por máquinas que las herramientas de IA pueden entender y usar.

El WordPress MCP Adapter conecta esta Abilities API con el Model Context Protocol (MCP), el estándar abierto para conectar sistemas de IA con herramientas externas. ¿Qué significa esto en la práctica? Los agentes de IA en Claude, Cursor o VS Code ahora pueden descubrir qué puede hacer tu sitio WordPress y ejecutar esas acciones directamente.

Un escenario concreto: Claude puede crear un post de WordPress, rellenar campos ACF con datos estructurados, asignar categorías, establecer una imagen destacada y disparar tu webhook de revalidación en Vercel — todo en una sola conversación. Sin navegador, sin panel de administración, sin copiar y pegar.

Esto es todavía temprano, y el adaptador MCP sigue evolucionando. Pero señala algo importante: WordPress no está quieto mientras los CMSes headless nativos innovan. La combinación de Abilities API + MCP podría convertir a WordPress en uno de los CMSes más accesibles para IA disponibles, aprovechando su enorme ecosistema de plugins de formas que las plataformas más nuevas y pequeñas no pueden igualar. Lee el anuncio oficial en el WordPress Developer Blog para todos los detalles técnicos.

Rendimiento: WordPress Headless vs WordPress Tradicional

WordPress headless con un frontend estático mejora drásticamente el rendimiento en comparación con WordPress PHP tradicional. WordPress tradicional sirve páginas dinámicas ejecutando PHP en cada petición, lo que resulta en un Time to First Byte (TTFB) pobre — según datos de rendimiento de mediados de 2025, solo el 31% de los clientes WordPress en escritorio y el 24% en móvil ven puntuaciones TTFB buenas. Pasarse a headless con Next.js e ISR significa que las páginas se pre-renderizan y se sirven desde nodos CDN edge, bajando el TTFB por debajo de 100ms para páginas en caché.

El caso de estudio de WP Engine sobre Android Authority mostró una mejora de 6x en las puntuaciones de rendimiento de Lighthouse tras migrar a WordPress headless. Los datos de Core Web Vitals cuentan una historia similar: solo el 45% de los sitios WordPress superan las tres métricas CWV en móvil, en comparación con el 65% de Shopify y el 83% de Duda.

Una advertencia importante: headless no arregla un backend WordPress lento. Si tu API de WordPress tarda 3 segundos en responder porque estás en hosting compartido barato con 40 plugins, la regeneración de ISR también será lenta. El frontend no puede ser más rápido que la API de la que depende. Invierte en hosting gestionado de calidad — importa más en una configuración headless, no menos. El blog de Weston Ruter, WordPress Performance Lead, tiene datos excelentes sobre qué mueve realmente la aguja en el rendimiento del servidor WordPress.

FAQ

¿Qué es WordPress headless?

WordPress headless es una arquitectura donde WordPress funciona únicamente como backend de gestión de contenido, con su tema PHP frontend completamente desactivado. El contenido se distribuye a través de la REST API o WPGraphQL a una aplicación frontend independiente construida con frameworks como Next.js, Nuxt o Astro. El panel de administración de WordPress sigue siendo completamente funcional para los editores de contenido.

¿Es WordPress bueno como CMS headless?

WordPress funciona bien como CMS headless cuando tienes un sitio WordPress existente, editores familiarizados con la interfaz, o necesitas el ecosistema de plugins (especialmente WooCommerce). Es menos ideal que los CMSes headless nativos como Sanity o Contentful cuando comienzas desde cero, porque el modelado de contenido y la API de WordPress fueron retroadaptados en lugar de diseñados API-first.

¿Cuáles son las desventajas de WordPress headless?

Las principales desventajas son: mayor complejidad (dos entornos de hosting en lugar de uno), pérdida de la edición visual y la funcionalidad de page builders, los plugins de frontend dejan de funcionar (renderizado de meta de Yoast, formularios de contacto, banners de cookies), sin colaboración de contenido en tiempo real, y la API GraphQL es una dependencia de plugin en lugar de funcionalidad del núcleo. El presupuesto también aumenta, ya que pagas hosting WordPress más hosting frontend.

¿Cómo conecto Next.js a WordPress?

Instala WPGraphQL en tu sitio WordPress, luego crea un proyecto Next.js con App Router. Establece tu endpoint GraphQL de WordPress como variable de entorno, escribe una función utilitaria de fetch GraphQL simple basada en fetch, y úsala en Server Components para consultar posts, páginas y tipos de contenido personalizados. No necesitas Apollo ni urql — el fetch nativo funciona porque los Server Components se ejecutan en el servidor.

WPGraphQL vs REST API — ¿cuál es mejor?

WPGraphQL es mejor para frontends de producción porque devuelve solo los campos que solicitas (reduciendo el tamaño del payload un 60-80%), admite consultas anidadas en una sola petición y proporciona un IDE GraphiQL para explorar el schema. La REST API es mejor para prototipos rápidos, equipos no familiarizados con GraphQL, o escenarios donde la caché HTTP nativa es crítica sin herramientas adicionales.

¿Cuánto cuesta WordPress headless?

Una configuración mínima de WordPress headless cuesta alrededor de $14/mes — Cloudways para el hosting WordPress más el nivel gratuito Hobby de Vercel para el frontend. Una configuración de producción con WP Engine y Vercel Pro ronda los $40-70/mes. Añade $0-50/mes por plugins premium como ACF Pro y WPML. Los CMSes headless nativos suelen tener niveles gratuitos generosos, así que el coste por sí solo no es razón para elegir WordPress headless.

¿Puedo usar WooCommerce con WordPress headless?

Sí. WPGraphQL tiene una extensión para WooCommerce (WPGraphQL WooCommerce o "WooGraphQL") que expone productos, pedidos, carrito y funcionalidad de checkout a través de GraphQL. Esto te permite construir storefronts React personalizados con capacidad de e-commerce completa. El flujo de checkout requiere trabajo extra en comparación con los temas WooCommerce tradicionales, pero las ganancias en rendimiento y UX son significativas para tiendas de alto tráfico.

¿Necesito un desarrollador para configurar WordPress headless?

Sí, una configuración de WordPress headless requiere habilidades de desarrollo frontend — concretamente React (o Vue/Svelte) y familiaridad con APIs. Tendrás que construir todo el frontend desde cero o personalizar una plantilla de inicio. Esto no es una solución sin código. Los editores de contenido pueden seguir usando el panel de administración de WordPress con normalidad, pero la configuración inicial y el mantenimiento continuo del frontend requieren participación de un desarrollador.

¿Qué plugins son esenciales para WordPress headless?

Los plugins esenciales son WPGraphQL (API GraphQL), Advanced Custom Fields o ACF (modelado de contenido estructurado) y WPGraphQL for ACF (expone campos personalizados vía GraphQL). Muy recomendados: Custom Post Type UI para registrar tipos de post desde el admin, y un plugin de webhook como WP Webhooks para disparar recompilaciones del frontend al publicar contenido. Evita los plugins dependientes del frontend como el renderizado de meta de Yoast SEO o los plugins de formularios.

¿Es WordPress headless bueno para el SEO?

WordPress headless puede ser excelente para el SEO cuando se implementa correctamente con Next.js o Nuxt, porque obtienes renderizado del lado del servidor, cargas de página más rápidas (mejorando los Core Web Vitals) y control total sobre meta tags, datos estructurados y estructura de URLs. El riesgo es que pierdes las características automáticas de los plugins SEO como el renderizado de meta tags de Yoast — tendrás que gestionar meta tags, sitemaps y datos estructurados en tu código frontend de forma manual.