Tu equipo sabe usar WordPress. Publica notas, cambia precios, sube fotos. Nadie quiere aprender otro sistema. Pero el sitio se siente pesado, cada plugin nuevo es una apuesta y rediseñar parece una mudanza completa.
Hay un camino intermedio que muchas empresas no conocen: WordPress headless. Seguís usando el mismo panel para cargar contenido, pero el sitio que ve tu cliente se construye aparte, con tecnología pensada para cargar rápido.
En esta nota vas a ver qué es, qué cambia para tu equipo, qué ganás, qué cuesta y cómo migrar sin perder lo que ya construiste en Google.
Tu WordPress anda, pero ¿por qué se siente lento?
WordPress hace dos trabajos a la vez. Guarda el contenido y también arma cada página que ve el visitante, con el tema y los plugins que tengas instalados.
Ese doble rol es su mayor fortaleza y, con el tiempo, su punto débil. Cada plugin puede sumar código a todas las páginas. Cada actualización del tema puede romper algo. Y el diseño queda atado a lo que ese tema permite.
Los síntomas suelen ser parecidos:
- Páginas que tardan en mostrar el contenido principal, sobre todo en el celular.
- Un panel lleno de plugins que nadie se anima a desactivar.
- Cambios de diseño que dependen de un page builder y se rompen al actualizar.
- Miedo a tocar el sitio porque "funciona" y no se sabe bien por qué.
Google mide parte de esta experiencia con las Core Web Vitals: cuánto tarda en aparecer el contenido, cuánto tarda la página en responder y cuánto se mueve mientras carga. Si tu sitio falla ahí, el problema no siempre es el hosting. Muchas veces es la forma en que se arma cada página.
¿Y si pudieras conservar WordPress para cargar contenido, pero cambiar por completo la forma en que se muestra?
Qué es WordPress headless, en simple
Es usar WordPress solo como gestor de contenido. El panel sigue igual. Lo que cambia es que ya no arma las páginas: entrega el contenido a otra aplicación, que es la que construye el sitio.
Es el mismo principio de cualquier CMS headless, que separa la carga de contenido de la presentación. La diferencia es que acá no cambiás de herramienta: aprovechás la que ya tenés. Si en cambio preferís empezar con una herramienta nueva, una alternativa de código abierto es Strapi, un CMS headless que podés alojar donde quieras.
WordPress trae lo necesario de fábrica. Su manual oficial de la API REST explica que esa API permite enviar y recibir el contenido del sitio como objetos JSON. Con ella podés construir una experiencia de frontend nueva o llevar tus contenidos a aplicaciones totalmente separadas.
Si el equipo técnico prefiere GraphQL, existe WPGraphQL. Según su documentación, es un plugin gratuito y de código abierto que agrega un esquema y una API de GraphQL a cualquier sitio WordPress.
Del otro lado, el frontend puede hacerse con distintas tecnologías. La documentación de Astro sobre WordPress headless muestra cómo traer las entradas desde la API REST y generar una página por cada una. Y aclara que esa API está disponible por defecto en cualquier sitio WordPress.
Hasta acá, la parte técnica. ¿Pero qué cambia en el día a día de quienes cargan el contenido?
Qué cambia para tu equipo y qué sigue igual
Esta es la buena noticia para quien edita: casi todo sigue igual.
Lo que sigue igual:
- El panel de WordPress, con el mismo usuario y contraseña.
- El editor de bloques para escribir notas y páginas.
- La carga de imágenes, categorías y etiquetas.
- Los roles y permisos de cada persona.
Lo que cambia:
- La vista previa. Ver cómo queda una página antes de publicar requiere una configuración extra entre WordPress y el frontend.
- El diseño ya no se toca desde el panel. Los cambios de estructura o de estilo los hace el equipo de desarrollo en el frontend.
- Publicar puede no ser instantáneo. Si el sitio se genera de forma estática, cada publicación dispara una nueva compilación que tarda unos minutos.
- Algunos plugins dejan de tener efecto, porque WordPress ya no es el que muestra las páginas.
Para un equipo de contenido, el cambio es chico. Para el equipo técnico, es grande. Esa diferencia explica casi todo lo que viene después.
Si el equipo casi no nota el cambio, ¿qué gana entonces la empresa?
Lo que ganás: velocidad, seguridad y libertad de diseño
Las tres ventajas tienen una condición: que el frontend esté bien construido. Un WordPress headless mal hecho puede ser tan lento como el sitio que reemplaza.
Velocidad
Como el frontend es independiente, se puede generar el sitio como páginas estáticas, listas para servirse sin consultar la base de datos en cada visita. Ese es el enfoque de herramientas como Astro, que mandan al navegador solo el código necesario. En por qué Astro ayuda al SEO vas a ver cómo impacta eso en el posicionamiento.
Seguridad
En un WordPress tradicional, el panel y el sitio público conviven en el mismo servidor. En el modelo headless, el panel puede quedar en otra dirección, con el acceso restringido. El sitio que ven tus clientes no expone el panel ni la base de datos.
Eso achica la superficie de ataque, pero no la elimina. WordPress hay que seguir actualizándolo. Y la API tiene que exponer solo lo que corresponde: el manual oficial aclara que el contenido privado o protegido solo está disponible con autenticación.
Libertad de diseño
El frontend ya no depende de un tema ni de un page builder. Se diseña a partir de tu marca y de lo que necesita tu cliente. Y si en unos años querés rediseñar, cambiás el frontend sin tocar el contenido.
Todo esto tiene un precio, y no solo en plata. ¿Qué se pierde y qué hay que sumar?
Lo que cuesta: plugins que dejan de servir, desarrollo y mantenimiento
Antes de decidir, conviene mirar los costos de frente. Son de tres tipos.
Plugins que dejan de servir
Muchos plugins de WordPress trabajan sobre las páginas que arma el tema: constructores visuales, sliders, formularios, pop-ups, cachés, algunos ajustes de SEO. En un sitio headless, el tema ya no se usa para mostrar las páginas, así que esas funciones hay que resolverlas en el frontend.
Antes de empezar, hacé una lista de cada plugin activo y anotá qué hace. Vas a ver cuáles siguen siendo útiles en el panel y cuáles hay que reemplazar.
Desarrollo
El frontend se construye desde cero. No hay un tema para instalar. Eso significa diseño, programación, pruebas y la conexión con la API de WordPress. Es la parte más grande del proyecto.
Mantenimiento
Pasás de mantener un sistema a mantener dos. WordPress sigue necesitando actualizaciones, copias de seguridad y monitoreo. El frontend necesita su propio alojamiento, sus propias actualizaciones y alguien que lo entienda.
Ninguno de estos costos es un motivo para descartar la idea. Lo que hacen es ayudarte a responder la pregunta importante: ¿te conviene a vos, hoy?
¿Te conviene a vos? Señales para dar el paso o esperar
Estas señales indican que WordPress headless probablemente tiene sentido:
- Tu equipo está cómodo con WordPress y no querés cambiarle la herramienta.
- La velocidad del sitio afecta tus resultados y ya agotaste las mejoras dentro del tema.
- Querés un diseño propio que el tema o el page builder no te permiten.
- Necesitás mostrar el mismo contenido en el sitio y en otros canales, como una app.
- Tenés acceso a un equipo de desarrollo, propio o externo, para sostener el frontend.
Y estas otras sugieren esperar:
- El sitio es chico, cambia poco y hoy cumple su función.
- Dependés de plugins que modifican el frontend y no tenés cómo reemplazarlos.
- Tu equipo necesita armar páginas nuevas sin ayuda técnica todas las semanas.
- No vas a tener soporte de desarrollo después del lanzamiento.
Si estás en el medio, lo mejor es evaluar el sitio actual antes de decidir. En ARTDEPARTMENT revisamos qué conservar y qué construir nuevo al principio de cada proyecto de diseño y desarrollo web.
Supongamos que decidiste avanzar. ¿Cómo se hace el cambio sin perder el tráfico que ya tenés?
Cómo es la migración paso a paso, sin perder SEO
La migración a WordPress headless tiene una ventaja: el contenido no se muda. Queda en el mismo WordPress. Lo que cambia es la forma de mostrarlo, y ahí está el riesgo para el SEO.
Google tiene una guía oficial para trasladar sitios con cambios de URL. Estos pasos siguen su lógica:
- 1. Inventario. Listá las URLs que importan: las del mapa del sitio, las que más tráfico reciben y las que tienen enlaces externos. Incluí imágenes y PDF.
- 2. Mismas URLs si es posible. Si el frontend nuevo respeta la estructura actual, te ahorrás la mayoría de los problemas. Si alguna cambia, anotá a dónde va.
- 3. Redirecciones permanentes. Google recomienda redireccionamientos 301 o 308 desde cada URL vieja a su nueva versión, sin cadenas largas y sin mandar todo a la home.
- 4. Etiquetas SEO completas. Títulos, metadescripciones, canonical, datos estructurados y robots tienen que generarse en el frontend nuevo. Si antes los manejaba un plugin, revisá que no se pierdan.
- 5. Un cambio a la vez. La guía sugiere no cambiar dominio, CMS y diseño al mismo tiempo. Mantener WordPress ya te ayuda: cambiás la presentación, no el contenido.
- 6. Probar antes de abrir. Revisá el sitio nuevo completo, sacá los bloqueos de noindex o robots.txt usados en desarrollo y probá las redirecciones.
- 7. Mapa del sitio y Search Console. Enviá el mapa del sitio nuevo y seguí los informes de indexación y rendimiento.
La misma guía advierte que puede haber fluctuaciones temporales en el ranking mientras Google vuelve a rastrear el sitio. Es normal. Lo importante es detectar a tiempo errores como redirecciones rotas o páginas bloqueadas.
Quedan algunas dudas que aparecen casi siempre. Vamos a las más comunes.
Preguntas frecuentes
¿WordPress headless sigue siendo WordPress?
Sí. El contenido, los usuarios y el panel siguen en WordPress. Solo cambia quién arma las páginas que ve el visitante.
¿Necesito un plugin para usar WordPress en modo headless?
No necesariamente. La API REST viene incluida en WordPress. Si el equipo técnico prefiere GraphQL, puede sumar WPGraphQL.
¿Pierdo los plugins de SEO?
El plugin puede seguir siendo útil para cargar títulos y descripciones en el panel. Pero las etiquetas que ve Google las tiene que generar el frontend. Hay que conectarlas para que no se pierdan.
¿Mi equipo tiene que aprender algo nuevo?
Para cargar contenido, casi nada. El cambio más visible suele ser la vista previa y, si el sitio es estático, que una publicación tarde unos minutos en verse.
¿Puedo hacer el cambio de a partes?
Sí. La guía de Google recomienda, en sitios grandes, trasladar por secciones para detectar problemas antes. Por ejemplo, empezar por el blog y seguir con el resto.
WordPress headless no es para todos. Pero si tu equipo ya trabaja cómodo en WordPress y tu sitio necesita dar un salto, es una de las formas más ordenadas de modernizarlo sin empezar de cero.
