Empiezas con cinco webs en una misma instalación y todo parece más sencillo: un solo acceso, plugins compartidos y menos tareas repetidas. Meses después, la red reúne decenas de subsites, varios administradores y picos de visitas, por lo que cada actualización, copia e incidencia debe planificarse para toda la red.
Una red grande depende de carga, no de subsites
Una red de WordPress Multisite no se vuelve lenta por alcanzar una cifra concreta de subsitios, sino por la carga que generan al mismo tiempo.
Una referencia útil para planificar: entre 50 y 100 subsites suele ser el punto en que conviene formalizar permisos, copias granulares y pruebas previas. Entre 100 y 500, la monitorización y el aprovisionamiento repetible dejan de ser opcionales. Con más de 500, trata la red como una plataforma: mide cada cambio y evita depender de acciones manuales.
Qué carga más que el número de sitios
El tráfico simultáneo es el dato que más condiciona la velocidad de una red: diez visitas leyendo páginas guardadas en caché apenas consumen recursos, pero diez personas pagando en WooCommerce activan PHP, sesiones, pasarelas de pago y consultas a la base de datos.
Revisa estos elementos antes de culpar al número de sitios:
Picos de visitas: campañas, matrículas, rebajas o publicaciones que atraen usuarios a la misma hora.Páginas sin caché: carrito, cuenta de cliente, buscadores internos, formularios y zonas privadas.Plugins con muchas consultas: reservas, filtros de productos, estadísticas en tiempo real y constructores visuales.Bibliotecas pesadas: imágenes originales, vídeos subidos al servidor y copias antiguas que ocupan disco.Importaciones y correos: sincronización de productos, boletines y tareas masivas ejecutadas en horario de visitas.
Señales de que la red ya va justa
Los errores 502 y 504 suelen indicar que el servidor no ha podido responder a tiempo, no que WordPress esté roto; si el panel de red tarda entre 5 y 10 segundos, las colas de tareas crecen o las copias fallan, necesitas investigar antes de crear más subsites.
Mide el tiempo de respuesta, uso de CPU, memoria, procesos PHP ocupados, consultas lentas y espacio de disco. Un hosting serio debe mostrar estas cifras o ayudarte a obtenerlas. Sin esos datos, contratar un plan mayor es como cambiar de coche sin saber si el problema era el motor, una rueda pinchada o el depósito vacío.
WordPress Multisite es una única instalación de WordPress que administra varios subsitios WordPress desde un panel de red. Comparten el mismo núcleo, la carpeta de plugins y temas disponibles y parte de la información global, como la lista de usuarios de la red; en cambio, cada subsite conserva sus propias tablas de contenido y ajustes, identificadas normalmente por su ID. Esta arquitectura simplifica actualizaciones y gobierno, pero también significa que una incompatibilidad en un plugin activado para toda la red, un problema en la base de datos o un consumo excesivo de recursos puede afectar a más de una web.
Por eso, el rendimiento de una red WordPress depende tanto de la infraestructura común como de las decisiones tomadas en cada subsite.
✉
¿Quieres más información? Escríbenos y te orientamos
Multisite encaja si las webs comparten operación
WordPress Multisite encaja cuando las webs comparten equipo, tema base, plugins aprobados y calendario de mantenimiento.
Criterio de decisión WordPress Multisite Instalaciones independientes Headless o SaaS Equipo y gestión Un equipo central y reglas comunes Cada web decide su gestión Proceso muy estandarizado Plugins y temas Catálogo limitado y compartido Selección propia por web Libertad limitada por la plataforma Aislamiento ante fallos Bajo si el fallo es global Alto entre instalaciones Depende del proveedor Migrar o vender una web Más trabajo técnico Normalmente sencillo Puede haber dependencia del proveedor Uso más adecuado Franquicias, centros, sedes o portales homogéneos Clientes y negocios distintos Producto digital con front-end propio
Casos donde una red sí ahorra trabajo
Una red de centros educativos con la misma estructura, un portal por municipio o una marca con delegaciones suelen beneficiarse de Multisite porque todas las webs pueden partir de una plantilla común, usar el mismo diseño y recibir actualizaciones revisadas por un equipo central.
El mapeo de dominios permite que cada subsite muestre su propio dominio, aunque viva dentro de la misma instalación. Por ejemplo, academia-madrid.es y academia-valencia.es pueden compartir base técnica sin que el visitante vea la dirección interna de la red.
Casos donde conviene separar las webs
Las instalaciones independientes son más seguras para proyectos con dueños, facturas, proveedores y necesidades distintas, ya que una tienda de un cliente no debería depender de que otra tienda actualice un plugin o consuma todos los recursos del servidor.
No conviene elegir Multisite si cada web pertenece a un cliente independiente, requiere plugins propios, necesita aislamiento de seguridad o debe migrarse y facturarse por separado. Tampoco suele compensar para dos o tres webs sin diseño, equipo o mantenimiento compartidos.
La estructura de URL debe elegirse antes de crecer. Los subdirectorios, como ejemplo.com/madrid/, suelen ser prácticos cuando todos los sitios pertenecen a una misma marca y comparten autoridad de dominio, analítica y estrategia SEO. Los subdominios, como madrid.ejemplo.com, aportan una separación visual mayor y requieren configurar DNS comodín y certificados que cubran las nuevas direcciones. Los dominios mapeados, como ejemplo-madrid.es, permiten una identidad independiente para cada sede o franquicia, aunque añaden gestión de DNS, SSL y renovaciones.
Cambiar de subdirectorios a subdominios después de publicar muchas URLs exige redirecciones 301, revisión de enlaces internos y validación en Search Console para no perder tráfico orgánico.
Hosting para 50, 100 o 500 subsites
El hosting de una red grande debe crecer según peticiones dinámicas, no según una promesa comercial de sitios ilimitados.
Los PHP workers son procesos que atienden páginas no guardadas en caché. Si todos están ocupados, las nuevas visitas esperan en cola, como clientes ante todas las cajas de un supermercado. No existe una cifra correcta por número de subsites: depende de cuánto tarda cada petición y cuántas ocurren a la vez.
Recursos que debes pedir al proveedor
Un hosting compatible con WordPress Multisite debe permitir PHP actualizado, base de datos MariaDB o MySQL afinada, almacenamiento SSD o NVMe y acceso a registros de errores; también debe admitir certificados SSL, dominios mapeados, subdominios comodín cuando los uses y reglas correctas en .htaccess.
La caché de objetos persistente, como Redis, guarda resultados frecuentes de la base de datos en memoria. Es como dejar a mano los documentos que consultas cada mañana, en vez de bajar al archivo cada vez. Resulta útil cuando muchos subsites realizan consultas parecidas.
Caché y cron sin romper la red
Instala un plugin de caché compatible con Multisite primero en un entorno de pruebas, actívalo para una subsite de ejemplo y comprueba portada, formularios, sesión de usuario, carrito y área privada antes de valorar la activación para toda la red.
1. Visita
2. Caché de página
3. Redis
4. PHP y base de datos
La velocidad mejora cuando cada capa evita trabajo innecesario antes de llegar a PHP y la base de datos. Programa WP-Cron desde el servidor cada 5 o 10 minutos en lugar de lanzarlo con cada visita, si tu proveedor sabe configurarlo. Este cambio debe probarse porque una tarea mal programada puede dejar correos o publicaciones pendientes.
✉
¿Quieres más información? Escríbenos y te orientamos
Plugins y permisos: menos cambios globales
Una red estable usa pocos plugins para WordPress, todos revisados y compatibles con Multisite.
El superadministrador controla la red completa desde el panel de administración de red, mientras que un administrador local solo gestiona su subsite. Confundir ambos roles es como entregar las llaves del cuarto de contadores a cualquier vecino porque necesita cambiar una bombilla.
Un catálogo pequeño evita conflictos
Define un catálogo de plugins aprobados con fecha de revisión, responsable y función concreta. Si existen dos herramientas para comprimir imágenes, dos para seguridad o dos para caché, escoge una y retira la otra tras probarlo.
Los MU-plugins , o plugins obligatorios, se cargan siempre y no pueden desactivarse desde el panel normal. Son apropiados para reglas técnicas muy concretas, como una redirección común o una protección interna. No son un cajón para instalar cualquier plugin que el equipo no quiera que toquen.
Permisos y cambios que no deben delegarse
Cada actualización global debe pasar por staging, una copia de pruebas separada del sitio público. Anota qué cambias, quién lo hace, qué subsites se ven afectadas y cómo volver atrás: parece burocracia, pero evita que una actualización urgente se convierta en una caída de toda la mañana.
La documentación de WordPress.org sobre redes explica la base técnica de la instalación, incluidos wp-config.php y .htaccess. Antes de cambiar esos archivos, guarda una copia y prueba siempre fuera de producción.
Copias granulares evitan restaurar toda la red
Una copia válida para una red grande permite recuperar una sola subsite con sus tablas, medios, usuarios relevantes y dominio mapeado sin revertir las demás.
La base de datos compartida guarda tablas comunes de la red y tablas propias para cada sitio. Restaurar una copia total por un error en una web puede borrar pedidos, entradas o cambios recientes de otras 99, por lo que la restauración granular es una condición de compra, no una función secundaria.
Qué recuperar de una única subsite
Una restauración por subsite debe incluir sus tablas de contenido y opciones, la carpeta de archivos subidos, usuarios y roles afectados, configuración de dominio y certificados si el proveedor los gestiona fuera de WordPress; también revisa redirecciones, DNS y conexiones con analítica o correo.
Pregunta al proveedor o al plugin de copias cuánto tarda una restauración de prueba. Para una web corporativa, entre 30 y 90 minutos puede ser aceptable; para una tienda con ventas constantes, debes reducir ese tiempo y prever un procedimiento de emergencia.
Cómo localizar un fallo sin apagar todo
La monitorización debe avisar de páginas caídas, certificados próximos a vencer, poco espacio de disco, copias fallidas y respuesta lenta. Si una subsite concreta dispara el consumo, limita su proceso o desactiva temporalmente su función local antes de tocar los componentes comunes.
La Agencia Española de Protección de Datos recuerda que el RGPD y la LOPDGDD exigen proteger los datos personales. Si una red guarda formularios, pedidos o cuentas, define quién puede acceder a copias y registros, cuánto tiempo se conservan y dónde están alojados.
Migrar una subsite fuera de la red exige tratarla como un proyecto de extracción, no como una simple copia de archivos. Hay que exportar sus tablas de contenido y opciones, trasladar los archivos de uploads correspondientes, revisar qué usuarios deben mantenerse y comprobar si el tema o los plugins dependen de componentes activados a nivel de red. Después se sustituyen las URLs internas, se configura el dominio definitivo, se preparan redirecciones 301 desde las direcciones antiguas y se validan formularios, correos, analítica, caché WordPress y enlaces multimedia.
Antes del cambio de DNS conviene probar la instalación destino en una URL temporal o mediante un archivo hosts, para detectar errores sin interrumpir el sitio público.
Altas masivas requieren plantillas y revisión
Crear muchas subsites de forma segura exige una plantilla base y un proceso repetible para dominios, permisos y ajustes.
Una plantilla base debe incluir el tema hijo, páginas legales, menú, ajustes de SEO, consentimiento de cookies, analítica, caché y plugins autorizados. El objetivo no es que todas las webs sean idénticas, sino que empiecen desde una base conocida y revisable.
Proceso seguro para crear cada sitio
Crea primero unas pocas subsites manualmente y documenta cada decisión. Cuando el resultado sea estable, puedes automatizar las altas con WP-CLI, una herramienta de línea de comandos para WordPress, o mediante la API, que permite conectar sistemas entre sí.
Recoge los datos: dominio, responsable, idioma, plantilla y finalidad del nuevo sitio.Crea desde una plantilla: aplica tema, páginas y catálogo aprobado de plugins.Mapea el dominio: comprueba DNS, SSL, redirección www o sin www y URL canónica.Prueba antes de publicar: revisa móvil, formulario, cookies, caché y correos.Registra la entrega: anota responsable, accesos, fecha y próxima revisión.
Dominios y legalidad en España
Cada dominio mapeado necesita DNS correcto, SSL activo y redirecciones coherentes. También debe quedar claro quién paga su renovación y quién tiene acceso al registrador; perder ese control puede dejar inaccesible una subsite aunque WordPress funcione bien.
Si recoges datos personales, revisa textos de privacidad, contratos con encargados de tratamiento y banner de cookies conforme al RGPD, la LOPDGDD y la LSSI-CE. La Agencia Española de Protección de Datos ofrece criterios y guías para responsables en España.
✉
¿Quieres más información? Escríbenos y te orientamos
Preguntas frecuentes
¿Cuántas subsites puede tener WordPress multisite?
WordPress Multisite puede alojar cientos o miles de subsites, pero no hay un límite práctico basado solo en el número. Entre 50 y 500 webs, el límite real suele estar en tráfico simultáneo, PHP workers, consultas de base de datos, tareas cron y espacio de almacenamiento.
¿Qué plugin de caché sirve para multisite?
Sirve un plugin que indique de forma expresa compatibilidad con Multisite y con tu servidor. Prueba primero una subsite y verifica al menos portada, sesión, formularios, carrito y cierre de sesión antes de activarlo para toda la red.
¿Son demasiados 50 plugins en una tienda de WooCommerce?
Cincuenta plugins pueden ser demasiados si duplican funciones o añaden consultas en checkout, aunque el número por sí solo no decide nada. Audita cada plugin por función, soporte, compatibilidad con WooCommerce y efecto en las páginas de pago.
¿Cómo creo un subdominio en multisite?
Debes configurar la red para subdominios, crear un DNS comodín si el proveedor lo exige y comprobar que el certificado SSL cubre las nuevas direcciones. Prueba primero en staging, porque algunos hostings compartidos limitan esta configuración.
Decide la arquitectura antes de añadir más sitios
Multisite merece la pena cuando puedes tratar la red como una sola operación: mismos criterios, mismos componentes y un equipo que controla los cambios.
Una red de sitios no se dimensiona por cuántas webs contiene, sino por cuántas acciones simultáneas debe resolver sin afectar a las demás.
