Migración a Multisite reciente? Un ajuste de la zona mal hecho puede provocar que subsitios muestren contenido equivocado, sesiones cruzadas o entradas desaparecidas; esa es la preocupación de quien gestiona varios blogs y quiere acelerar la red sin sorpresas.
La caché en Multisite: opciones seguras sin romper subsitios. Se puede activar la caché en una red Multisite sin romper subsitios si se siguen opciones seguras: elegir plugins compatibles con Multisite, usar esta localidad por sitio (no global), prefijar claves para Redis/Memcached, probar en staging y purgar por subsitio. Incluye plugins recomendados, configuraciones sencillas y un checklist de pruebas y rollback seguro ; todo explicado paso a paso. Empieza por el Resumen del proceso para aplicar cambios seguros.
Resumen del proceso
Crear backup y staging para reproducir la red Multisite.
Elegir plugin y decidir network‑activate o activar por sitio según homogeneidad.
Configurar caché de objetos con prefijos por blog_id o DB separadas en Redis.
Probar purgas por subsite: panel, WP‑CLI y API CDN (purga por URL o tags).
Validar en staging, medir rendimiento y preparar rollback (scripts y snapshots).
Seis acciones rápidas: snapshot, staging, activar por sitio, prefijo Redis, purga por URL y pruebas de login/checkout. Hacer esto toma entre 1 y 3 días si se tiene staging listo.
1. Backup + Staging
2. Elegir plugin
3. Configurar object cache
4. Purgas por subsite
5. Validar + Tests
Objetivo: cambios reversibles. Probar 3 días en staging antes de desplegar a producción.
✉
¿Quieres más información? Escríbenos y te orientamos
Paso 1: preparación, backups, staging y métricas base
Antes de tocar nada, crear un snapshot completo del servidor y copia de la base de datos. Se recomienda un backup completo y una réplica de staging. Si el hosting ofrece snapshots en 1 clic, usarlo.
Registrar métricas base: medir TTFB, FCP y LCP con Lighthouse y WebPageTest. Esto permite comparar antes/después. Un ejemplo orientativo: TTFB sin caché puede estar entre 400–800 ms; con page cache bien configurado suele bajar a 50–200 ms.
Comprobar si el proveedor ya aplica caché a nivel servidor. Hosts conocidos como Kinsta, WP Engine o SiteGround suelen tener soluciones propias. Si el host aplica caché por zona y no permite purgas por subsite, la estrategia cambia.
Leer la guía oficial de Multisite para entender la estructura de subsitios antes de avanzar.
Si no hay staging y no se puede revertir con snapshots, no activar caché de página en producción. Hacer pruebas en vivo sin rollback implica riesgo alto.
Para Multisite es crucial distinguir entre subdominios y subdirectorios desde el punto de vista de la caché y del servidor. En instalaciones por subdominios (SUBDOMAIN_INSTALL=true) conviene usar un bloque de servidor que acepte comodines (server_name *.midominio.es) y asegurarse de que el cache key incluye el host (por ejemplo, en Nginx: fastcgi_cache_key "$scheme$request_method$host$request_uri"), lo que evita servir contenido de un subsite a otro. En instalaciones por subdirectorios la entrada de la URI y la ruta del cookie son más relevantes: hay que comprobar que las cookies de autenticación usan path=/ para no limitar su alcance erróneamente y que las reglas de rewrite preservan la estructura /sitio/uri.
También revisar certificados TLS: con subdominios se suele usar wildcard TLS, mientras que con domain mapping cada dominio puede necesitar su propio certificado o SNI correctamente configurada en el CDN o servidor. Antes de desplegar, probar ambas topologías en staging (hostnames distintos o rutas simuladas) y validar headers (Host, Set-Cookie, X-Cache-Status) para confirmar que la clave de caché y el scope de cookies son los esperados.
Paso 2: plugins seguros para multisite, network‑activate vs per‑site
La decisión más importante: activar en red (network‑activate) o activar por sitio . Network‑activate aplica reglas y comportamientos globales. Esto facilita gestión central, pero puede imponer purgas globales y reglas de servidor que afecten a todos los subsitios.
Activar por sitio aísla problemas. Cada administrador local puede gestionar purgas y exclusiones. Para redes heterogéneas con subsitios independientes, activar por sitio suele ser la opción más segura.
Network‑activate vs activar por sitio: mapa de decisiones
Si la red tiene más de 25 subsitios y todos son homogéneos, considerar network‑activate con pruebas en staging.
Si la red tiene subsitios con e‑commerce, login personalizado o plugins distintos, activar por sitio.
Si el hosting ofrece purga por site a nivel servidor, network‑activate puede funcionar.
Comparativa práctica de plugins
Plugin
Network‑activate seguro
Recomendado por sitio
Purge por subsite
Soporte WP‑CLI
Soporte object cache
Coste
WP Rocket
Parcial
Sí
Sí (por sitio)
Limitado
No (usa object cache externo)
Pago (licencia anual)
LiteSpeed Cache
Sí, en servidores LiteSpeed
Sí
Sí
Sí
Integrado
Gratis/Ítems Premium
WP Super Cache
Limitado
Sí
Básico (archivos)
No
No
Gratis
W3 Total Cache
Complejo (riesgo de reglas globales)
Sí (si admin experimentado)
Sí (configurable)
Sí
Sí
Gratis/Pro
La compatibilidad real depende del hosting y la versión del plugin. Verificar en staging.
Paso 3: cómo configurar exclusiones y purgado por subsitios sin romper nada
Objetivo: purgar o invalidar cache de un subsitio sin afectar a toda la red.
Algunos plugins muestran un botón de purga global si están network‑activated. Esto puede provocar interrupciones. Se recomienda comprobar si el plugin ofrece purga por site.
Purgado desde el panel vs vía WP‑CLI
Panel del plugin: usar siempre la opción "limpiar caché del sitio actual" si existe.
WP‑CLI es la opción más fiable para purga dirigida. Ejemplos:
bash
wp --url=https://sub.dominio.es cache flush
wp --url=https://sub.dominio.es transient delete --all
wp --url=https://sub.dominio.es redis flush
Comprobar con wp help qué comandos añade cada plugin. Siempre probar en staging.
Purgado por CDN/edge
Purgar por zona afecta a todos los dominios. Se recomienda purga por URL o por tags si el CDN lo soporta. Ejemplo Cloudflare (curl):
bash
curl -X POST "https://api.cloudflare.com/client/v4/zones/{ZONE_ID}/purge_cache" /
-H "Authorization: Bearer " /
-H "Content-Type: application/json" /
--data '{"files":["https://sub.midominio.es/pagina-a-purgar"]}'
Almacenar las credenciales de la API de forma segura. Combinar purga CDN y purga servidor para evitar contenido desactualizado.
Reglas de servidor para excluir subsitios o usuarios logueados
Nginx (FastCGI Cache) — ejemplo que evita cache a usuarios logueados y usa $host en la clave:
nginx
map $http_cookie $no_cache {
~*wordpress_logged_in_ 1;
default 0;
}
fastcgi_cache_bypass $no_cache;
fastcgi_no_cache $no_cache;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
Incluir $host evita mezclar cache entre subdominios. En caso de subdirectorios, $request_uri distingue rutas.
Apache/.htaccess, evitar cache para usuarios logueados:
apache
SetEnvIf Cookie "wordpress_logged_in_" NO_CACHE=1
Header set Cache-Control "no-cache, no-store, must-revalidate" env=NO_CACHE
ExpiresActive On
ExpiresByType text/css "access plus 1 week"
Varnish / reverse proxy: usar BAN o purgas por host y URI. Configurar reglas que incluyan el Host header.
Domain mapping y CDN con subsitios
Si cada subsite usa dominio propio, purga por URL es directa. Si hay domain mapping con proxying, asegurarse que el CDN respeta Host header y no cachea contenido por zona completa.
Advertencia: una purga global puede causar carga alta al regenerar caché. No ejecutar purga global en horas pico. Ejecutar purga por partes o por tags.
En redes Multisite con domain mapping es fácil que el CDN actúe a nivel de zona y borre caché de todos los dominios si no se configura correctamente. Para evitarlo: (1) preferir purgas por URL o por tags/surrogate‑keys en el CDN, (2) configurar el cache key para que incluya el Host (o usar una zona diferente por dominio si el CDN no permite incluir Host en la clave), y (3) añadir headers de origen como Surrogate-Key: site_{blog_id} para poder purgar por sitio. Fastly permite purgas por surrogate key vía API: curl -X POST -H "Fastly-Key: <API_KEY>" "https://api.fastly.com/service/<SERVICE_ID>/purge/site_123" (donde site_123 es el surrogate key añadido desde el origen).
En Cloudflare, si no tienes Cache Keys personalizadas, usa purga por URL y evita purgas por zona; si dispones de Cloudflare Workers/Enterprise, exige el Host en la clave de caché para segregar contenidos. En CloudFront, activa la opción de cache based on selected headers e incluye el Host header, o usa una distribución por dominio mapeado para prevenir contaminación entre subsites.
✉
¿Quieres más información? Escríbenos y te orientamos
Paso 4: Redis/Memcached vs caché de página, ventajas prácticas en multisite
La caché de objetos acelera consultas internas y reduce carga de base de datos. La caché de página reduce el TTFB. Ambos se complementan.
Riesgo en Multisite: contaminación de claves en Redis/Memcached. Si no se usan prefijos por sitio, un transient o sesión puede ser devuelto en otro subsite.
Estrategias para caché de objetos en multisite: prefijos y DB por blog_id
Opciones seguras:
Prefijo por blog_id: añadir un prefijo como wp_{$blog_id}_ a todas las claves.
Usar DB separadas en Redis (si el proveedor lo permite): WP_REDIS_DATABASE = $blog_id.
Instalar un drop‑in object-cache.php que incluya blog_id en la clave.
Ejemplo conceptual en wp-config.php (idea):
php
// Cargar temprano en mu‑plugin o wp-config
$blog_id = defined('BLOG_ID_CURRENT_SITE') ? Get_current_blog_id() : 0;
define('WP_REDIS_PREFIX', 'wp_' . $blog_id . ':');
Confirmar con redis-cli KEYS 'wp_*' que aparecen prefijos distintos por sitio.
Ventajas prácticas
Caché de página: baja la CPU y acelera entrega estática.
Redis/Memcached: reduce latencia de consultas y acelera transients.
OPCache: imprescindible para PHP; no sustituye a cache de página u objeto.
Cómo comprobar contaminación entre subsitios
Crear un transient con valor único en un subsite y buscar la clave en Redis. Repetir en otro subsite. Si las claves se mezclan, el prefijo no está funcionando.
Herramientas: redis-cli, memcached-tool, APM (New Relic) y logs del hosting.
Para valorar cambios en caché en Multisite necesitas casos de prueba reproducibles y métricas concretas por subsite. Recomendación práctica: (a) registrar TTFB, FCP, LCP y cache‑hit ratio antes y después por subsite; (b) medir el tiempo de reconstrucción de caché tras una purga simulada: ejecutar un test de carga controlado y cronometra cuántas peticiones por segundo el servidor puede regenerar sin degradar el servicio (herramientas: wrk -t4 -c100 -d30s https://sub.midominio.es/ o hey -n 1000 -c 50 https://sub.midominio.es/); (c) pre‑calentar el caché con un script que recorra las URLs más importantes (xargs -n1 curl -s -o /dev/null < urls.txt) y medir el tiempo hasta alcanzar un cache‑hit ratio estable; (d) medir picos de CPU y consultas SQL durante el rebuild (New Relic/APM o top/mysqlslowlog).
Registrar estos datos por subsite te permitirá decidir si activar page cache globalmente o por sitio, y estimar el impacto de una purga global frente a una purga localizada.
Paso 5: checklist, elegir plugin seguro para tu multisite paso a paso
Preparación
Crear snapshot del servidor y backup de base de datos.
Montar entorno staging que reproduzca Multisite (subdominios o subdirectorios).
Registrar métricas base con Lighthouse y WebPageTest.
Verificar si el hosting aplica caché a nivel servidor y cómo purgarlo.
Implementación en staging
Instalar plugin y preferir activar por sitio salvo que exista soporte claro de network‑activate.
Configurar exclusiones: /wp-admin, /wp-login.php, cookies de usuario, checkout y REST API.
Configurar object cache con prefijos por blog_id o DBs separadas.
Probar purga por sitio desde panel, con WP‑CLI y con la API del CDN.
Validar funciones críticas: login, checkout, formularios, feeds y REST endpoints.
Validación y benchmarking
Comparar métricas pre/post: TTFB, FCP, LCP y cache hit ratio.
Revisar headers HTTP: X‑Cache, X‑Cache‑Status, Cache‑Control.
Realizar pruebas de carga controladas para ver reconstrucción de caché.
Plan de rollback rápido
Desactivar plugin (per‑site o network) y ejecutar wp --url=... Cache flush.
Purga CDN por URL (no por zona) para evitar borrar todo.
Restaurar snapshot si hay corrupción de datos.
Revertir cambios en Nginx/.htaccess con copia de seguridad.
Checklist resumido: snapshot, staging, activar por sitio, prefijos en object cache, purga por URL, pruebas de login y rollback script. Seguir este flujo reduce probabilidades de romper subsitios.
Errores que arruinan el resultado
Activar un plugin de la zona en network‑activate sin comprobar purgado por site. Esto puede imponer reglas .htaccess/nginx globales.
Configurar Redis/Memcached sin prefijo por sitio. Resultado: sesiones o transients cruzados entre subsitios.
No probar con usuarios registrados o con el proceso de checkout. Sitios con e‑commerce requieren pruebas de pago.
Cambiar reglas Nginx o .htaccess en caliente sin script de rollback. Una regla mal escrita puede dejar la web inaccesible.
Confiar en purga del hosting sin validarla. Algunos hosts hacen purgas por zona y no por subsite.
✉
¿Quieres más información? Escríbenos y te orientamos
Cuándo no funciona este método / alternativas
No aplica cuando la instalación es single‑site. Tampoco aplica si el hosting aplica un cache a nivel servidor que no permite purgas por subsite. En esos casos la opción es:
Pedir al proveedor que habilite purgas por host o path.
Migrar a un hosting que soporte purgas por subsite.
Si no hay posibilidad de staging ni rollback, no activar cache de página; limitarse a object cache y optimizaciones front‑end.
Caso donde no aplicar: red con subsitios altamente dinámicos por usuario (por ejemplo intranets o apps con sesiones intensas). La caché de páginas puede romper experiencia de usuario y producir problemas legales si se cachea información personal.
Preguntas frecuentes
¿Cuál es el mejor caché para WordPress?
Depende del caso. Para Multisite conviene evaluar WP Rocket por sitio, LiteSpeed Cache si el hosting usa LiteSpeed y la caché a nivel de hosting (WP Engine, Kinsta) cuando ofrecen purgas por site. Redis o Memcached son recomendables para object cache cuando hay muchas consultas.
¿Limpiar caché WordPress sin plugin?
Sí: usar WP‑CLI y herramientas de servidor. Comandos útiles: wp --url=https://sub.midominio.es transient delete --all y wp --url=https://sub.midominio.es cache flush. También se pueden borrar archivos en wp-content/cache y purgar CDN mediante su API.
¿WordPress debería utilizar una caché de objetos persistente?
Sí cuando hay muchas consultas a la base de datos o uso intensivo de transients. En Multisite conviene usar prefijos por blog_id o DB separadas en Redis para evitar contaminación de claves entre subsitios.
¿Cómo purgar la caché en WordPress?
Se puede purgar desde el panel del plugin (por sitio si existe), con WP‑CLI (wp --url=... Cache flush) o con herramientas del servidor (redis-cli FLUSHDB para una DB). Para CDNs usar la API (ej. Cloudflare) y purgar por URL o tags, no por zona completa.
¿Borrar caché WordPress sin plugins?
Primera línea: WP‑CLI y borrar archivos de cache físicos. Segunda: limpiar transients con wp transient delete --all y purgar CDN vía API. Tener cuidado con operaciones globales en producción.
¿Cómo borrar el caché en WordPress?
Usar la opción de purga del plugin por sitio o wp --url=... Cache flush. Si el plugin no soporta WP‑CLI, usar herramientas del servidor o la API del CDN para purgas por URL.
¿Puedo activar WP rocket en network‑activate?
Se puede, pero no es la opción por defecto. Si no se verifica el comportamiento multisite y las purgas, activar por sitio evita riesgos de reglas globales que afecten a todos los subsitios.
Costos, riesgos y errores comunes al activar caché multisite
Los costes no son solo licencias. Incluir en el presupuesto instancias Redis o Memcached (servicios gestionados), tiempo de pruebas, y monitorización. Servicios gestionados en AWS o DigitalOcean tienen coste mensual por nodo.
Riesgos legales: cachear endpoints con datos personales sin control puede generar problemas con el RGPD/GDPR y la AEPD. Evitar cachear páginas que contienen datos personales o configurar exclusiones.
Errores frecuentes ya listados: network‑activate sin pruebas, falta de prefijos, no probar usuarios registrados, cambios de servidor sin rollback.
Casos reales: en una red de ~30 subsitios se produjo una purga global accidental que dejó feeds y endpoints con contenido stale durante 2 horas. Lección: implementar purgas por tags y pruebas de rollback.
Referencias a organizaciones y práctica: según W3Techs, WordPress sigue dominando una gran parte de la web, por lo que gestionar redes Multisite con buenas prácticas resulta especialmente relevante. Consultar documentación oficial en WordPress.org y la documentación de CDNs para purgas por tags.
Resumen accionable y próximos pasos
Resumen: preparar snapshot y staging, preferir activar plugins por sitio salvo que el hosting ofrezca purgas por subsite, configurar object cache con prefijos por blog_id, purgar por URL o tag en CDN y validar con pruebas de login y checkout.
Plan de 5 días para desplegar de forma segura:
Día 0: snapshot y preparar staging.
Día 1: instalar plugin en 2 subsitios representativos y activar por sitio.
Día 2: configurar Redis/Memcached con prefijos y validar claves.
Día 3: pruebas funcionales (login, checkout), medir TTFB y LCP.
Día 4: planificar despliegue gradual en producción en ventana de baja carga.
Con staging, backups y un script de rollback, el beneficio de reducir TTFB y mejorar la experiencia compensa el riesgo. Si no se dispone de estas garantías, priorizar object cache y optimizaciones front‑end hasta poder probar.
Autor: Jesús Barrios. Con más de 12 años de experiencia con WordPress y plugins. Fecha: 2026-03-27. Herramientas mencionadas: WP‑CLI, Redis, Memcached, Cloudflare, Lighthouse.
