WordPress multisite con errores comunes y solución

Qué es WordPress Multisite y qué problemas suele concentrar

WordPress Multisite permite administrar una red de sitios WordPress desde una única base de código y una sola instalación principal. Cada sitio de la red puede tener su propio contenido, usuarios, configuración visual y, en algunos casos, su propio dominio, mientras que la administración global queda centralizada para el Super Admin.

Su ventaja operativa es clara: simplifica mantenimiento, actualizaciones y gestión centralizada. El problema es que también centraliza puntos críticos. Un pequeño error en la activación de la red, en wp-config.php, en las reglas de reescritura o en la resolución DNS puede afectar a todos los subsitios al mismo tiempo.

Los fallos más repetidos suelen agruparse en estas áreas:

• Activación incorrecta de la red o mezcla de ajustes heredados de una instalación monositio.
• Configuración incompleta de subdominios o subdirectorios.
• Reglas de reescritura mal aplicadas en Apache o configuración equivalente incompleta en Nginx.
• Errores de acceso, cookies, sesiones o redirecciones HTTP/HTTPS.
• Plugins y temas que funcionan en un sitio único, pero no están preparados para una red multisitio.
• Incidencias tras migraciones, cambios de dominio, activación de CDN o capas de caché del hosting.

En la práctica, Multisite no es complejo solo por WordPress: lo delicado es la relación entre WordPress, servidor, DNS y dominios. Por eso conviene diagnosticar por capas y no asumir que todos los entornos se comportan igual.

Errores al activar la red: wp-config.php, .htaccess y requisitos previos

Uno de los primeros puntos donde aparecen errores en wordpress multisite es la activación inicial. WordPress genera instrucciones para modificar wp-config.php y .htaccess, pero esas instrucciones solo funcionan bien si se aplican sobre una base coherente: enlaces permanentes activos, módulos de reescritura operativos si se usa Apache, y una estructura de red compatible con el dominio principal.

La relación entre ambos archivos es clave:

• wp-config.php define que la instalación funciona como red y contiene constantes que condicionan el comportamiento global.
• .htaccess aplica las reglas de reescritura para que las peticiones lleguen al sitio correcto en redes basadas en Apache.

Si el primer archivo declara la red pero el segundo no reescribe correctamente las URL, pueden aparecer 404 en subsitios, redirecciones al sitio principal o pantallas de acceso que no resuelven bien. A la inversa, si las reglas existen pero la configuración interna no es correcta, WordPress puede no interpretar la red como debería.

Antes de activar o reactivar la red, conviene comprobar estos requisitos previos:

• Copia de seguridad completa de archivos y base de datos.
• Confirmar si la red usará subdominios o subdirectorios, porque cambiarlo después puede implicar una reconfiguración seria.
• Verificar que no hay reglas antiguas o personalizadas en .htaccess que entren en conflicto.
• Revisar si el hosting aplica reglas adicionales de caché o seguridad que alteren redirecciones.
• Comprobar que no existen plugins de redirección, seguridad o caché activos que interfieran durante la activación.

En redes ya migradas o reconstruidas, un problema muy habitual es dejar constantes antiguas, dominios obsoletos o rutas heredadas. También es frecuente que el archivo .htaccess haya sido sobreescrito por un plugin o por una herramienta del hosting, algo que rompe la estructura de enlaces de los subsitios sin tocar aparentemente WordPress.

Si el servidor usa Nginx, la lógica es la misma, pero la reescritura no depende de .htaccess. En ese caso, conviene revisar la configuración del bloque de servidor o la plantilla que use el proveedor, porque WordPress no puede corregir por sí solo reglas mal definidas a ese nivel.

Fallos con subdominios, subdirectorios, DNS y certificados SSL

Los problemas de resolución son muy comunes en una configuración multisite, sobre todo cuando la red se monta con subdominios. Si un subsitio devuelve error DNS, carga el sitio principal o muestra una respuesta distinta según el navegador, la causa puede estar fuera de WordPress.

En redes con subdominios, conviene revisar:

• Que exista un registro wildcard adecuado, normalmente orientado a resolver subdominios de la red.
• Que el panel DNS del proveedor haya propagado correctamente los cambios.
• Que el servidor web acepte esas peticiones y no solo el dominio principal.
• Que el certificado SSL cubra el dominio principal y, si corresponde, los subdominios mediante wildcard o una alternativa válida según la arquitectura elegida.

En redes con subdirectorios, el DNS suele ser más simple, pero aparecen otros riesgos: conflictos con rutas existentes, instalaciones previas, páginas reservadas o reescrituras mal aplicadas. Si un subsitio responde con 404 aunque el dominio principal funcione, suele ser buena idea revisar enlaces permanentes, reglas de reescritura y la estructura de rutas.

Respecto a SSL, un error muy frecuente es mezclar redirecciones forzadas a HTTPS a nivel de plugin, servidor, CDN y proxy inverso al mismo tiempo. Eso puede generar:

• Bucles de redirección.
• Cookies de acceso inconsistentes entre HTTP y HTTPS.
• Acceso correcto al sitio principal pero fallo en subsitios o dominios mapeados.

Si además se usan dominios mapeados wordpress, el diagnóstico debe ir un paso más allá. No basta con que el nuevo dominio apunte al servidor: también conviene validar que el certificado sea válido para ese dominio, que no exista una redirección previa al dominio principal y que la caché del navegador, del hosting o de la CDN no esté sirviendo reglas antiguas.

Un patrón real muy habitual en España es ver redes alojadas en paneles gestionados donde el DNS externo está en un proveedor distinto al hosting. En esos casos, puede parecer un error de WordPress cuando en realidad falta un registro, el wildcard no existe o el virtual host solo atiende el dominio principal.

Problemas de acceso, permisos, subida de archivos y roles en Multisite

Los problemas de acceso en Multisite suelen manifestarse como bucles de login, cierres de sesión al entrar al escritorio de un subsitio, usuarios que ven menos opciones de las esperadas o imposibilidad de subir archivos. No siempre se deben a la misma causa: a veces es un ajuste de roles, a veces una política del servidor y, en otros casos, un conflicto de caché o cookies.

En Multisite hay que diferenciar claramente entre:

• Super Admin, con control de la red completa.
• Administrador de un subsitio, con capacidad limitada al sitio concreto.
• Editores, autores y otros roles locales, que no heredan permisos globales.

Muchas incidencias vienen de asumir que un administrador de subsitio puede instalar plugins, cambiar ajustes de red o administrar dominios. Eso no es así por diseño. Si una acción “falta” en el panel, puede no ser un error, sino una limitación normal del rol.

Cuando el problema sí es técnico, conviene revisar:

• Configuración de cookies y redirecciones, especialmente si hay mezcla de www, no-www, HTTP y HTTPS.
• Restricciones del servidor para tamaño de subida, memoria, tiempo de ejecución o reglas ModSecurity.
• Permisos de archivos y carpetas, sobre todo tras migraciones manuales.
• Configuración de cuotas de almacenamiento por sitio dentro de la red.
• Bloqueos provocados por plugins de seguridad o por el firewall del proveedor.

Si los medios no suben o se generan errores en miniaturas, puede deberse a rutas mal resueltas, permisos de escritura insuficientes, límites de PHP o a una migración incompleta del directorio de subidas. En redes antiguas o convertidas desde monositio, también conviene revisar si la estructura de carpetas y las URLs de archivos siguen siendo coherentes con el modo multisitio.

Cuando un usuario entra correctamente en la red pero no en un subsitio concreto, lo recomendable es comprobar si realmente está asignado a ese sitio, con qué rol, y si hay un plugin que esté alterando capacidades de usuario a nivel de red o de sitio individual.

Incompatibilidades de plugins, temas, caché y dominios mapeados

No todo plugin o tema está preparado para Multisite, aunque funcione bien en instalaciones normales. Una incompatibilidad en este contexto no siempre rompe la web de forma evidente: a veces altera redirecciones, guarda opciones en el sitio equivocado, genera tablas inesperadas o muestra contenido cruzado entre subsitios.

Los conflictos más habituales se concentran en:

• Plugins de caché que no separan correctamente contenido por dominio o por sitio.
• Plugins de seguridad que limitan accesos administrativos o cambian URLs de login sin contemplar la red completa.
• Constructores visuales o extensiones que guardan rutas absolutas y fallan tras migraciones o mapeo de dominios.
• Temas con lógica no preparada para detectar contexto de sitio dentro de la red.
• Plugins que deberían activarse por sitio, pero se activan en red sin necesidad, o al revés.

La caché merece atención especial. En una red multisitio puede haber varias capas activas a la vez: plugin de caché, caché del hosting, Varnish o similar, CDN y caché del navegador. Si una sola capa no distingue bien entre sitios, pueden aparecer páginas servidas desde otro subsitio, redirecciones antiguas, estilos que no coinciden o paneles administrativos con contenido desactualizado.

Con dominios mapeados wordpress, el riesgo aumenta. Si una CDN o caché de proxy no varía por host, puede mostrar un sitio bajo el dominio de otro. También conviene revisar cabeceras, reglas de canonical y forzado de dominio, porque algunas configuraciones automáticas de SEO o seguridad no interpretan bien redes con varios dominios públicos.

La recomendación práctica es probar cualquier plugin crítico en un entorno de staging o clon técnico de la red antes de activarlo en producción. En Multisite, un plugin aparentemente menor puede impactar en todos los subsitios si se activa a nivel de red.

Cómo diagnosticar y resolver errores de WordPress Multisite paso a paso

Para resolver errores wordpress multisite de forma ordenada, conviene seguir una secuencia que reduzca variables. El objetivo es identificar si el fallo pertenece a WordPress, al servidor, al DNS, al SSL o a un componente externo como la caché o la CDN.

1. Define el síntoma exacto. No es lo mismo un 404 en subsitios, un subdominio que no resuelve, un login en bucle o un dominio mapeado que muestra otra web. Anota qué URL falla, qué devuelve y si afecta a toda la red o solo a un sitio.
2. Comprueba si el problema es de resolución o de aplicación. Si el subdominio ni siquiera resuelve, revisa DNS y servidor antes que WordPress. Si resuelve pero carga contenido erróneo, examina configuración de red, reescritura y dominio asignado.
3. Revisa wp-config.php y la configuración de la red. Verifica que las constantes y ajustes de Multisite correspondan con la estructura real de la instalación y que no queden restos de migraciones o dominios antiguos.
4. Valida reglas de reescritura. En Apache, comprueba htaccess multisite; en Nginx, la configuración equivalente. Si todos los subsitios redirigen a la principal, aquí suele haber una pista importante.
5. Desactiva temporalmente capas de caché. Vacía caché de plugin, hosting, CDN y navegador. Muchos falsos positivos en Multisite vienen de reglas antiguas almacenadas.
6. Aísla plugins y tema. Si el entorno lo permite, desactiva primero plugins de redirección, seguridad, caché y SEO. Después revisa si el error persiste con un tema estándar y en un subsitio de prueba.
7. Confirma SSL y dominios. Si hay redirecciones raras o avisos de sesión, revisa certificados, hostnames cubiertos y reglas forzadas de HTTPS a todos los niveles.
8. Consulta registros. Los logs de PHP y del servidor suelen revelar rutas inválidas, permisos denegados, límites superados o reescrituras defectuosas.

Si se necesita una referencia oficial, la documentación de WordPress sobre creación y administración de redes Multisite suele ser el mejor punto de contraste para validar si la configuración base está bien planteada antes de buscar causas específicas del hosting o clonar WordPress a staging para pruebas seguras.

Cuándo conviene reparar la red actual y cuándo replantear la configuración

No todas las incidencias justifican rehacer una red. Si el problema está localizado en reglas de reescritura, DNS, certificados, caché o un plugin conflictivo, normalmente compensa reparar la red actual. En estos casos, una revisión técnica metódica suele devolver estabilidad sin rediseñar la arquitectura.

Sí conviene replantear la configuración cuando se repiten varios de estos escenarios:

• La red se creó con subdirectorios, pero la necesidad real exige dominios independientes y reglas más complejas.
• El hosting actual no gestiona bien wildcard, certificados o reglas de servidor necesarias para Multisite.
• La red arrastra migraciones antiguas, dominios históricos y ajustes heredados difíciles de mantener.
• Hay demasiados plugins no compatibles o una dependencia excesiva de personalizaciones que complican cada actualización.
• La estructura actual mezcla webs que, por negocio, seguridad o rendimiento, deberían estar separadas.

Antes de tomar una decisión de fondo, conviene valorar impacto operativo, coste técnico, mantenimiento futuro y riesgo en producción. No siempre la solución correcta es "tocar más"; a veces lo sensato es congelar cambios, clonar el entorno, validar hipótesis y aplicar ajustes en una ventana controlada.

En resumen, los errores más críticos en WordPress Multisite suelen concentrarse en la activación de la red, la relación entre wp-config.php y .htaccess, la resolución DNS de subdominios, el SSL, los permisos, la caché y los plugins no preparados para multisitio. Corregirlos exige validar la configuración real del entorno antes de cambiar nada en producción.

Si la red presenta fallos recurrentes, una siguiente acción razonable es hacer una revisión técnica completa con inventario de dominios, reglas, DNS, caché y plugins activos. Ese análisis previo suele ahorrar tiempo, evitar cambios contradictorios y marcar si conviene reparar la instalación actual o rediseñar su arquitectura con soporte especializado.