W3 Total Cache REST API problemas: la versión 2.9.3 del plugin introduce un bug en el output buffering que causa respuestas vacías (0 bytes) en todos los endpoints de /wp-json/, rompiendo desde el Site Health de WordPress hasta integraciones de WooCommerce y plugins que dependen de la API. El fix más rápido es hacer downgrade a 2.9.2 o excluir la REST API del caché.
En 30 segundos
- W3 Total Cache 2.9.3 introdujo un cambio en el manejo de output buffering que suprime respuestas JSON de la REST API de WordPress, dejando 0 bytes como respuesta.
- El síntoma más visible: Site Health muestra error «REST API did not process the context query parameter» y los POST a
/wp-json/no devuelven nada. - Solución rápida: downgrade a la versión 2.9.2 disponible en el archivo histórico de WordPress.org.
- Alternativa sin desactivar W3TC: excluir
/wp-json/.*de Page Cache y Database Cache usando expresiones regulares en la configuración del plugin. - La opción correcta para REST API en W3TC es «Don’t Cache», no «TEST», porque los datos dinámicos y los POST requests no tienen sentido cacheados.
Qué es la REST API de WordPress y por qué es crítica
La REST API de WordPress es la interfaz estándar de comunicación entre el core de WordPress y el mundo exterior. Está habilitada por defecto desde WordPress 4.7 y permite que plugins, aplicaciones móviles, frontends desacoplados y servicios externos lean y escriban datos del sitio usando peticiones HTTP con respuestas en JSON.
No es un detalle técnico opcional. Gutenberg la usa en cada guardado. WooCommerce la necesita para sincronizar pedidos y productos con servicios externos. Plugins de membresía, CRM, formularios avanzados, y prácticamente cualquier integración moderna la requiere para funcionar. Si la REST API devuelve 0 bytes, esos sistemas se rompen en silencio o con errores crípticos que te van a tener horas rastreando el origen.
El endpoint base es /wp-json/ y cada plugin puede registrar sus propias rutas bajo ese prefijo. WordPress core expone rutas como /wp/v2/posts, /wp/v2/users, y así. Cualquier caché que interfiera con esas respuestas tiene consecuencias que van mucho más allá de «la página no carga».
El problema: W3 Total Cache 2.9.3 y la incompatibilidad con REST API
W3 Total Cache es uno de los plugins de caché más usados de WordPress, con más de un millón de instalaciones activas. La versión 2.9.3, según múltiples reportes en el foro de soporte de WordPress.org, introdujo un cambio en la forma en que maneja el output buffering para respuestas JSON y AJAX. El efecto fue catastrófico para la REST API: las respuestas quedan suprimidas antes de llegar al cliente, y lo que recibe cualquier llamada a /wp-json/ son literalmente cero bytes.
El problema es conocido y está bien documentado en los foros oficiales. No es un caso aislado ni una configuración rara: instalaciones estándar de W3TC 2.9.3 empezaron a reportar el mismo comportamiento en múltiples entornos. Un hilo específico en WordPress.org agrupa decenas de afectados con la misma firma de error.
Lo que hace más difícil detectarlo es que el sitio «funciona»: las páginas cargan, el admin de WordPress responde, y a primera vista no hay nada roto. El problema aparece solo cuando algo intenta hablar con la REST API.
Síntomas: cómo identificar que W3TC está rompiendo tu REST API
Ponele que tu tienda WooCommerce deja de sincronizar con tu ERP. O que el editor de bloques se pone lento y no guarda bien. O que un plugin de membresía dice que no puede conectarse. Antes de culpar al servidor o al tema, revisá estos síntomas concretos:
- Site Health muestra error REST API: el mensaje exacto es «REST API did not process the context query parameter». Lo encontrás en Herramientas → Estado del sitio.
- Respuestas vacías (0 bytes): cualquier GET o POST a
/wp-json/devuelve cuerpo vacío con código HTTP 200. El 200 te confunde porque «técnicamente funcionó», pero el contenido no llegó. - Plugins de terceros que no sincronizan: WooCommerce, plugins de reservas, formularios con integraciones externas, todos fallan silenciosamente.
- Errores en consola del navegador: el editor Gutenberg lanza errores de parseo JSON porque recibe una respuesta vacía donde esperaba un objeto.
- Logs del servidor limpios: como el 200 se entrega igual, el servidor no registra error. Esto hace que sea difícil de rastrear si no sabés dónde buscar.
¿Cómo confirmás que es W3TC el responsable? Desactivá el plugin momentáneamente y probá la URL https://tu-sitio.com/wp-json/ en el navegador. Si de repente aparece el JSON con la información del sitio, el culpable es W3TC. Relacionado: desarrollar un plugin personalizado para solucionarlo.
Solución 1: Downgrade a W3 Total Cache 2.9.2
La opción más limpia si necesitás que el sitio funcione ya. El proceso es manual porque WordPress no tiene interfaz nativa para instalar versiones anteriores de un plugin.
Paso a paso:
- Desactivar W3 Total Cache desde el panel de plugins.
- Eliminar el plugin (esto no borra la configuración guardada en la base de datos).
- Ir a
https://wordpress.org/plugins/w3-total-cache/advanced/y descargar la versión 2.9.2 desde el historial de versiones. - Subir el ZIP desde Plugins → Agregar nuevo → Subir plugin.
- Activar.
La configuración previa debería conservarse. Verificá en Site Health que el error de REST API desapareció.
Eso sí: esto es una solución temporal. La versión 2.9.2 no recibe actualizaciones de seguridad y eventualmente vas a tener que actualizar. Guardalo como parche de emergencia mientras esperás una versión estable o configurás una exclusión correcta.
Solución 2: Excluir REST API del caché sin desactivar W3TC
Si tenés 2.9.3 o posterior y no querés hacer downgrade, podés decirle a W3TC que directamente ignore la REST API. Esto requiere configurar exclusiones usando expresiones regulares.
En Performance → Page Cache → Advanced, buscá la sección «Never cache the following pages» y agregá:
/wp-json/.*.*\?rest_route=.*(para compatibilidad con instalaciones donde la REST API va por query string)
Hacé lo mismo en Database Cache si lo tenés habilitado. Y si usás Minify, excluí también cualquier ruta bajo /wp-json/ de las reglas de minificación, porque el intento de minificar respuestas JSON puede generar resultados impredecibles.
Después de guardar, purgá todo el caché desde el panel de W3TC y verificá con una petición directa a /wp-json/wp/v2/posts que la respuesta llega con contenido. Esto se conecta con lo que analizamos en reforzar la seguridad con plugins especializados.
Solución 3: Configurar REST API en W3TC settings correctamente
W3TC tiene una opción específica para la REST API dentro de Performance → Page Cache → Advanced: un selector que dice «REST API» con opciones «TEST» y «Don’t Cache».
La recomendación es «Don’t Cache». Acá viene lo bueno: cachear la REST API tiene sentido solo en escenarios muy específicos, como endpoints públicos con datos que cambian poco y muchas lecturas concurrentes. Para el caso general, y especialmente para cualquier endpoint que reciba POST requests o devuelva datos dinámicos por usuario, cachear es contraproducente y causa exactamente estos problemas.
La opción «TEST» es para la versión Pro de W3TC, que tiene un sistema de caché de REST API más granular donde podés elegir qué rutas cachear y cuáles no. En la versión gratuita, «TEST» puede comportarse de forma impredecible. Si usás la versión free, «Don’t Cache» es la única opción segura.
Alternativas: otros plugins de caché con mejor soporte a REST API
Si después de todo esto llegás a la conclusión de que W3TC no es para vos, hay opciones que manejan la REST API de forma más predecible.
LiteSpeed Cache
Tiene una opción toggle específica para excluir la REST API del caché, visible en la configuración desde la primera vez que lo configurás. No requiere tocar expresiones regulares. Si tu hosting usa LiteSpeed Server (común en planes administrados de proveedores como donweb.com), obtenés además la integración nativa con el servidor para un caché más eficiente.
WP REST Cache
Plugin especializado exclusivamente en cachear la REST API de forma inteligente. A diferencia de W3TC que aplica caché genérico sobre todo, WP REST Cache solo actúa sobre /wp-json/ con reglas específicas para cada tipo de endpoint. Es más quirúrgico y menos propenso a este tipo de conflictos.
W3TC Pro
La versión paga de W3 Total Cache tiene controles granulares para la REST API que la versión gratuita no tiene. Si ya tenés inversión en el ecosistema W3TC y el sitio es de alto tráfico, puede valer la pena antes de migrar a otro plugin.
Comparativa de opciones para manejar el problema
| Opción | Dificultad | Riesgo | Cuándo usarla |
|---|---|---|---|
| Downgrade a W3TC 2.9.2 | Baja | Medio (sin updates) | Emergencia, necesitás que funcione ya |
| Excluir /wp-json/ del caché | Media | Bajo | Querés seguir con 2.9.3 o posterior |
| Configurar «Don’t Cache» en REST API | Baja | Bajo | Primer paso a probar en cualquier versión |
| Migrar a LiteSpeed Cache | Media | Bajo | Hosting con LiteSpeed Server |
| WP REST Cache (plugin separado) | Baja | Bajo | Necesitás caché de REST API pero sin riesgo |
| W3TC Pro | Baja | Bajo | Ya usás W3TC y querés control granular |
Verificar que el problema está resuelto: Site Health y pruebas
Después de aplicar cualquiera de las soluciones, confirmá que efectivamente se resolvió antes de darlo por cerrado. En automatizar la configuración con herramientas avanzadas profundizamos sobre esto.
Primero, andá a Herramientas → Estado del sitio y esperá que termine el análisis. El ítem «REST API» debe aparecer en verde sin advertencias. Si sigue mostrando el error del context query parameter, la exclusión no se aplicó correctamente o el caché viejo todavía está activo. Segundo, purgá todo el caché de W3TC desde el menú flotante del plugin y volvé a correr el Site Health. Tercero, si querés confirmación manual, usá curl desde la terminal del servidor o desde tu máquina:
curl -I https://tu-sitio.com/wp-json/wp/v2/posts
La respuesta debe incluir un header Content-Type: application/json y el campo Content-Length debe ser mayor a 0. Si ves Content-Length: 0 o directamente el header no aparece, la respuesta sigue vacía.
Para POST requests (importante si usás WooCommerce o integraciones externas), podés probar con Postman haciendo una petición autenticada a cualquier endpoint de escritura. Si la respuesta tiene cuerpo JSON, el problema está resuelto.
Errores comunes al intentar resolver esto
Purgar solo el caché de páginas y no el de objetos o base de datos. W3TC tiene múltiples capas de caché independientes. Si excluís la REST API del Page Cache pero no del Database Cache, el problema puede persistir. Purgá todo después de cualquier cambio en la configuración.
Agregar la exclusión como string literal en vez de regex. Si escribís /wp-json/ sin el punto y el asterisco al final (/wp-json/.*), solo excluís exactamente esa URL. Todos los endpoints bajo ese path, como /wp-json/wp/v2/posts, siguen siendo afectados. Usá la expresión regular completa.
Asumir que desactivar y reactivar el plugin soluciona el bug. El problema está en el código de la versión, no en la configuración. Reactivar 2.9.3 después de desactivarlo vuelve a introducir el mismo bug. Para salir del problema sin exclusiones, el único camino es cambiar de versión.
No verificar con Site Health después del fix. Hay casos donde la configuración parece correcta pero el caché viejo sigue entregando respuestas vacías. Siempre corré Site Health como verificación final, no asumas que el cambio se aplicó. Lo explicamos a fondo en probar plugins gratuitos disponibles.
Si querés profundizar en esto, tenemos un análisis detallado en W3 total cache and WordPress Rest API – Issues, can’t solve.
Para sacar más conclusiones, mirá nuestro artículo sobre W3 total cache and WordPress Rest API – Issues, can’t solve.
Para una solución completa, consultá W3 total cache and WordPress Rest API – Issues, can’t solve.
Preguntas Frecuentes
¿Por qué W3 Total Cache rompe mi REST API?
La versión 2.9.3 de W3 Total Cache modificó el sistema de output buffering que usa para interceptar y cachear respuestas. Ese cambio introdujo un conflicto con la forma en que WordPress genera respuestas JSON para la REST API: el buffer captura la respuesta antes de que llegue al cliente y la suprime, dejando cero bytes. No es un problema de configuración sino un bug en el código de esa versión específica.
¿Cómo solucionar errores de respuestas vacías en la API REST?
Las tres opciones en orden de rapidez: primero, hacer downgrade a W3TC 2.9.2 desde el archivo histórico de WordPress.org. Segundo, excluir /wp-json/.* de Page Cache y Database Cache en la configuración avanzada de W3TC usando regex. Tercero, en Performance → Page Cache → Advanced, poner la opción REST API en «Don’t Cache». Después de cualquier cambio, purgá todo el caché y verificá con Site Health.
¿Debería cachear la REST API en WordPress?
En la mayoría de los casos, no. Los endpoints de la REST API devuelven datos dinámicos que cambian por usuario, sesión o estado de la aplicación. Cachear esas respuestas puede hacer que un usuario vea datos de otro, que una operación de escritura no se refleje, o que WooCommerce procese pedidos con información vieja. La única excepción razonable son endpoints públicos de solo lectura con datos que cambian muy poco, y para eso existen soluciones más específicas que un caché de página genérico.
¿Qué versión de W3 Total Cache funciona sin romper la API?
La versión 2.9.2 es la última confirmada como estable para la REST API antes del bug. Versiones posteriores a 2.9.3 pueden haber incluido correcciones, pero la compatibilidad depende de cada entorno. Si actualizás desde 2.9.2, hacé la actualización en un entorno de staging primero y verificá Site Health antes de llevarla a producción.
¿Cómo excluir endpoints de REST API del caché en W3TC?
En Performance → Page Cache → Advanced, en el campo «Never cache the following pages», agregá /wp-json/.* como expresión regular. Repetí el mismo paso en Database Cache si está habilitado. Si usás Minify, excluí también esas rutas de minificación. Guardá cambios, purgá todo el caché y verificá con una petición directa a /wp-json/ que la respuesta incluye JSON con contenido.
Conclusión
El conflicto entre W3 Total Cache 2.9.3 y la REST API de WordPress es un bug real con impacto concreto: rompe WooCommerce, Gutenberg, plugins de terceros y cualquier integración que use /wp-json/. No es algo que se resuelva solo esperando ni ajustando configuraciones al azar.
La solución más directa es el downgrade a 2.9.2 si necesitás salir del problema rápido. Para el mediano plazo, excluir la REST API del caché con la regex correcta es la configuración que deberías tener en cualquier instalación de W3TC, independientemente de la versión, porque cachear respuestas de la API genera más problemas que los que resuelve.
Si después de aplicar las exclusiones el problema persiste, el paso siguiente es evaluar si W3TC es el plugin correcto para tu instalación o si plugins como LiteSpeed Cache tienen mejor integración con tu stack. Lo que no tiene sentido es seguir con una herramienta que requiere workarounds constantes en funcionalidades tan básicas como la API nativa del CMS.