Cuando una red WordPress Multisite empieza a ir lenta, el problema no siempre está en el servidor: una caché mal configurada puede dejar fuera a wp-admin, romper el login o mostrar contenido equivocado entre sitios secundarios. En redes con subdominios, subdirectorios o tiendas con usuarios autenticados, un ajuste genérico suele traer más conflictos que rendimiento.
La Cache en Multisite puede acelerar toda la red, pero no se configura igual según el tipo de red, el hosting y el uso de usuarios autenticados. Elegir bien el plugin, purgar por subsite y excluir áreas sensibles como wp-admin o login evita errores, duplicados y problemas de acceso. Aquí se identifica qué conviene usar según cada caso y cómo mantener la estabilidad sin sacrificar velocidad.
Cómo funciona y qué caché elegir en WordPress Multisite
La caché guarda copias listas para servir, como cuando una cocina deja platos preparados para no cocinar desde cero cada vez. En una red WordPress Multisite, esa copia puede vivir en el navegador, en el servidor, en un plugin o en una CDN.
El problema aparece cuando una copia sirve para el sitio equivocado. En una red con subdominios, subdirectorios o dominios mapeados, un plugin mal afinado puede enseñar contenido de otro subsite o dejar fuera cambios recientes. La frase que resume el riesgo es clara: la caché acelera, pero también puede equivocarse de destinatario.
Caché de página, objeto y navegador
La caché de página guarda HTML ya montado. Es la más visible y la que más acelera una web pública. Para un blog o una landing, suele ser la primera candidata.
La caché de objeto guarda consultas repetidas y resultados internos, como si dejara apuntadas las respuestas más usadas. Aquí entran Redis y Memcached. Ayudan mucho en paneles cargados, pero no sustituyen la caché de página.
La caché de navegador guarda archivos como imágenes, CSS o JavaScript en el equipo del usuario. Sirve para que no descargue lo mismo en cada visita. En Multisite, este punto importa mucho si varios subsites comparten recursos.
Qué cambia en multisite
En una red normal, el plugin piensa en un solo sitio. En Multisite, tiene que distinguir varios sitios dentro de una misma instalación y aplicar reglas, purgas y exclusiones por subsite cuando haga falta. Eso es especialmente importante en redes con subdominios, subdirectorios o dominios mapeados, donde una configuración global puede mezclar contenidos, no respetar actualizaciones o servir páginas equivocadas.
Qué caché elegir según tu red y tu hosting
La mejor caché en Multisite no es la más famosa, sino la que encaja con la infraestructura real. El hosting manda más de lo que suele parecer: LiteSpeed, Nginx, Apache o una capa propia del proveedor pueden cambiar la elección por completo. Antes de tocar un plugin, conviene mirar el stack completo, porque cuando entran Varnish o una caché gestionada por el hosting, la recomendación puede cambiar más por la infraestructura que por el propio nombre del plugin.
Si la red tiene poco tráfico y mucho contenido público, una configuración simple suele bastar. Si hay WooCommerce, accesos con usuario y áreas privadas, hacen falta exclusiones finas. Un caso habitual: una tienda en Multisite con caché global activa y sin excepciones terminó mostrando el carrito vacío a varios clientes, hasta que se excluyó esa ruta y se separó la purga por subsite.
Red pequeña con poco tráfico
En una red pequeña, conviene priorizar sencillez. Un plugin con reglas claras, purga fácil y poco mantenimiento suele dar mejor resultado que una suite pesada.
WP Rocket encaja bien cuando se quiere algo fácil de mantener. W3 Total Cache ofrece más control, pero pide más cuidado. En redes sencillas, la diferencia la marca más la configuración que la marca del plugin.
Red con tienda o login
En una red con WooCommerce, membresías o acceso privado, la caché debe respetar sesión y carrito. Aquí no vale servir la misma página a todo el mundo. Hay que definir exclusiones, separar purgas por subsite y evitar que páginas dinámicas queden cacheadas como contenido público.
Ajustes que evitan fallos en accesos
La caché da problemas cuando trata igual a visitantes y a usuarios con sesión. En Multisite, ese error se nota antes, porque hay más rutas, más cookies y más páginas privadas.
Un ajuste útil consiste en separar lo público de lo sensible. La portada, el blog o la ficha informativa sí pueden ir cacheados. El panel, el login y el checkout no deberían hacerlo.
Exclusiones para usuarios logueados
Los usuarios autenticados no deberían recibir la misma página que un visitante anónimo. Esa diferencia parece obvia, pero es donde más se tropieza.
El sitio puede usar cookies para saber si el usuario ha iniciado sesión. Si el plugin no respeta esa señal, puede mostrar menús equivocados, barras de administración o formularios que no responden bien. La caché para usuarios logueados solo funciona cuando el plugin distingue bien las cookies de sesión.
Regla para wp-admin y login
La zona de administración no necesita caché de página. Necesita respuestas rápidas del servidor y una sesión estable.
Lo normal es excluir /wp-admin/ y /wp-login.php. Si el login falla después de activar una caché, casi siempre hay una regla de exclusión incompleta o una capa del servidor que está metiendo mano donde no debe.
Carritos, cuentas y checkout
WooCommerce cambia el juego. El carrito no puede congelarse, porque su contenido varía con cada acción del usuario.
La página de checkout, la cuenta y el carrito deben quedar fuera de la caché de página. Si no, el usuario puede ver totales viejos o estados que ya no existen. Eso no es un detalle pequeño. Es una fuga de confianza.
El mayor riesgo de la caché en Multisite aparece con usuarios que inician sesión. Un visitante anónimo puede recibir caché de página, pero un usuario autenticado no debería ver un wp-admin lento ni un login intermitente por culpa de una regla demasiado agresiva. Si el plugin no respeta bien las cookies de sesión, pueden aparecer barras de administración, menús o contenidos mezclados entre subsites.
En redes con membresías o WooCommerce, la combinación de caché global y usuarios autenticados exige probar la experiencia completa: acceso, cambio de idioma, carrito, actualización de perfil y salida de sesión.
Cómo purgar por subsite sin tumbar toda la red
La purga correcta limpia solo lo necesario. La purga global parece cómoda, pero puede castigar toda la red cuando solo ha cambiado un subsite.
Lo que omiten la mayoría de guías sobre caché en Multisite es la gran diferencia entre borrar todo y borrar bien. Una red grande no agradece limpiezas completas cada vez que alguien actualiza una página en un sitio secundario.
Purga manual y automática
La purga manual sirve para incidencias puntuales. La automática funciona mejor cuando se publica contenido nuevo, cambia una plantilla o se actualiza un módulo crítico.
La clave está en que el plugin permita apuntar al subsite exacto. Si no lo hace, cada cambio arrastra a toda la red. Eso se nota más en redes con muchas visitas.
TTL por tipo de subsite
El TTL es el tiempo que una copia vive antes de renovarse. Piensa en él como la fecha de caducidad de una comida preparada.
Un blog con pocas actualizaciones puede usar un TTL más largo. Una tienda o un área con contenido dinámico necesita un TTL corto. En la práctica, la revisión de estos tiempos evita servir datos viejos durante horas.
Limpieza de transients
Los transients son pequeños datos temporales que WordPress guarda para ir más rápido. Si se acumulan o se quedan viejos, pueden ralentizar o dar resultados raros.
Limpiarlos ayuda, pero no arregla todo. Sirve como parte del mantenimiento WordPress, no como sustituto de una caché bien montada. Si la base de datos ya va pesada, conviene revisar también consultas, autoload y plugins que cargan demasiado.
La purga en WordPress Multisite funciona mejor cuando se segmenta por sitio, no por toda la red. Si cambias una landing en un subdirectorio, lo ideal es limpiar solo esa ruta y sus recursos relacionados; si actualizas un subdominio o un dominio mapeado, conviene vaciar la caché asociada a ese host y comprobar que no quedan restos en la CDN. Esto es especialmente útil en redes grandes, porque una purga global puede disparar picos de carga y vaciar páginas que no han cambiado.
En tiendas con WooCommerce, además, merece la pena excluir carrito, checkout y cuenta de la purga automática para evitar estados inconsistentes.
Subdominios, subdirectorios y dominios
La estructura de la red cambia la forma de cachear. En subdominios, cada sitio se parece más a una isla. En subdirectorios, la frontera es más fina. En dominios mapeados, la separación debe ser todavía más cuidadosa.
Subdominios y aislamiento
Los subdominios suelen permitir una separación más clara entre sitios. Eso facilita algunas reglas de caché y reduce el riesgo de mezclar contenido.
Aun así, no basta con pensar que cada subdominio es independiente. Si comparten cookies, plantillas o reglas globales, la mezcla puede seguir apareciendo.
Subdirectorios y colisiones
En subdirectorios, las rutas viven bajo la misma raíz. Eso vuelve más fácil que una regla demasiado amplia afecte a varios subsites a la vez.
Aquí es donde una purga mal hecha se nota más. Un cambio en una sección puede arrastrar caché de otra. Si el plugin no segmenta bien por ruta, el ahorro de tiempo se convierte en trabajo extra.
Dominios mapeados y reglas
Con dominios mapeados, cada subsite responde en su propio dominio. Eso suena limpio, y a veces lo es. Pero también obliga a revisar cookies, cabeceras HTTP y reglas de CDN con más calma.
En redes con dominios mapeados, una mala regla de caché puede enseñar contenido de un dominio en otro. La comprobación básica es sencilla: abrir cada subsite en incógnito y verificar que el login, el header y el contenido cambian de verdad.
Preguntas frecuentes sobre multisite y rendimiento
¿Cuáles son las desventajas de WordPress
La principal desventaja es la complejidad. Una red Multisite concentra varios sitios en una sola instalación, y eso hace que una mala caché afecte a más de un subsite. También complica actualizaciones, copias de seguridad y pruebas, sobre todo cuando hay usuarios autenticados o tiendas online.
¿Qué permite WordPress multisite?
Permite gestionar varios sitios desde un solo WordPress. Cada subsite puede tener su contenido, usuarios y configuración, pero comparte núcleo, plugins y temas permitidos. Eso ahorra trabajo, aunque exige más cuidado con la caché de página y la caché de objeto.
¿Cómo puedo configurar la caché en WordPress?
Conviene empezar por la capa del servidor y después el plugin. Primero se revisa si hay LiteSpeed, Varnish, Redis, Memcached o caché del hosting. Luego se excluyen login, wp-admin, carrito y cuenta, y por último se prueba cada subsite con navegador privado.
¿Debo habilitar WPMu multisitio?
Solo si de verdad necesitas varios sitios en una misma instalación. Si gestionas una sola web, Multisite añade complejidad sin aportar mucho. Si ya trabajas con una red, entonces sí merece la pena, pero con una caché pensada para esa estructura y no para un sitio único.
¿La caché puede mezclar contenido entre subsites?
Sí, y ese es uno de los fallos más delicados. Pasa cuando el plugin no distingue bien dominios, subdominios o rutas, o cuando una CDN aplica reglas demasiado amplias. La comprobación correcta es probar cada subsite con sesión cerrada y sesión abierta.
¿Redis sustituye al plugin de caché?
No. Redis acelera objetos y consultas internas, pero no sustituye la caché de página. En Multisite, suele funcionar mejor como apoyo que como solución única. Si el servidor ya va justo, Redis ayuda; si el contenido público no está cacheado, el salto de velocidad será limitado.
¿Qué hago si wp-admin se rompe tras activar caché?
Primero desactiva la caché de página para usuarios autenticados. Después revisa exclusiones para wp-admin, wp-login.php, carrito y cuenta, y comprueba si el hosting mete una capa adicional. Si el fallo sigue, la causa puede estar en cookies, reglas del servidor o un plugin que no respeta Multisite.
Qué hacer ahora
La mejor decisión suele ser simple: elige un plugin compatible con Multisite, mira qué capa de caché ya pone el hosting y excluye todo lo que dependa de sesión. Si hay tienda, login o dominios mapeados, prueba primero en un subsite aislado y no en toda la red.
En una red pequeña con tráfico bajo, una opción sencilla y bien ajustada suele bastar. En una red con WooCommerce, miembros o varios dominios, merece la pena una revisión más fina de purga, TTL y exclusiones. Esa es la diferencia entre acelerar de verdad y crear un problema nuevo.
Si la lentitud viene de imágenes pesadas, plugins defectuosos o un servidor corto de recursos, la caché no arregla el fondo del problema. En ese caso, primero conviene medir el cuello de botella y luego decidir qué capa de caché merece la pena.
