Migración de WordPress Multisite: manual completo para 2026

Probablemente usted se encuentre ahora mismo en una de dos situaciones. O bien una red multisitio ha superado el servidor, el modelo de gobernanza o la estructura de URL con los que empezó, o bien alguien del negocio ha decidido que un subsitio debe convertirse en su propia plataforma sin perjudicar la visibilidad en buscadores, los flujos editoriales ni los ingresos.

Ahí es donde la migración de WordPress Multisite deja de ser una tarea rutinaria de hosting y se convierte en un proyecto de ingeniería. El traslado técnico importa, pero los mayores riesgos suelen estar en otra parte: una licencia de plugin que deja de validarse tras la extracción, una configuración multilingüe que pierde sus etiquetas canonical, una biblioteca de medios que parece correcta hasta que el equipo editorial descubre archivos rotos tres días después, o un plan de reversión que solo existe como una vaga promesa.

Las migraciones más limpias que he visto siguen todas el mismo patrón. Tratan el traslado de la base de datos como una parte de un cambio controlado más amplio. Fijan el alcance pronto, prueban como investigadores y dan por hecho que algo fallará mientras no se haya verificado. Esa mentalidad es la que evita que una migración multisitio se convierta en un incidente de madrugada.

Estrategia previa a la migración y evaluación de riesgos

Viernes, 20:40. El DNS está a punto de cambiar, la importación de la base de datos ha terminado y alguien pregunta si se han conservado las etiquetas hreflang del subsitio francés y qué licencias de plugins premium sobrevivirán al traslado. Si esa pregunta surge la noche de la migración, la planificación ha fallado.

Una migración de WordPress Multisite empieza por el control del alcance y la planificación de fallos. La base de datos y los archivos importan, pero los proyectos de alto riesgo suelen fallar por cuestiones de continuidad del negocio: licencias de plugins vinculadas al dominio antiguo o al tipo de instalación, reglas de SEO multilingüe que desaparecen tras la extracción y planes de reversión que suenan bien hasta que alguien tiene que decidir bajo presión si revierte el DNS.

Trate el plan como un runbook de incidentes. Antes de que nadie toque producción, debe responder a cuatro preguntas:

1. Qué se traslada exactamente
2. Qué debe seguir disponible
3. Qué desencadena la reversión
4. Quién tiene autoridad para aprobar la puesta en producción o revertirla

Defina el alcance de la migración antes de elegir herramientas

«Trasladar el multisitio» no es un alcance útil. En la práctica, la petición suele ser más enrevesada: separar un subsitio que genera ingresos en un WordPress independiente, dejar atrás dos subsitios heredados, conservar los dominios mapeados, mantener al equipo editorial trabajando el lunes por la mañana y no perder posiciones en tres idiomas.

Anote primero el inventario.

• Cada subsitio: URL actual, dominio mapeado, responsable de negocio y tolerancia a la inactividad
• Modelo de activación: plugins activados en la red frente a plugins a nivel de sitio
• Código a medida: mu-plugins, drop-ins, tablas personalizadas, tareas cron, webhooks y sobrescrituras del tema
• Dependencias compartidas: referencias a medios, integraciones de API, SSO, formularios, búsqueda y scripts de analítica

Si nadie puede decir qué subsitios pueden estar fuera de línea y durante cuánto tiempo, la migración no está lista.

Este es también el momento en que los equipos deciden si mantienen el trabajo internamente o recurren a un especialista en servicios de migración de WordPress. La disyuntiva es sencilla. Los equipos internos conocen el stack. Los operadores externos suelen aportar un runbook más limpio, más disciplina en la reversión y menos suposiciones.

Audite los puntos de fallo que duelen tras la puesta en producción

La exportación y la importación de la base de datos son la parte fácil. Los fallos caros aparecen más tarde, cuando el sitio parece «correcto en general».

Las licencias de plugins son un caso habitual. Los plugins premium pueden validarse por dominio principal, contexto de red, número de sitios o entorno. Un subsitio extraído de un multisitio puede arrancar correctamente y aun así perder el acceso a actualizaciones, la representación de campos, las funciones de traducción o las integraciones de pago porque la licencia ya no coincide con la nueva instalación. Revise las condiciones de los proveedores antes del traslado, no después.

El SEO multilingüe merece la misma atención. Si la red utiliza WPML, Polylang, una salida hreflang personalizada, canonicals específicos por mercado o slugs traducidos, documente el comportamiento actual. Eso incluye etiquetas title, canonicals, etiquetas hreflang, sitemaps XML, reglas de redirección y plantillas basadas en la configuración regional. Un sitio puede superar el control de calidad visual y aun así perder valor de búsqueda porque la capa de metadatos cambió sin que nadie se diera cuenta.

Los medios son otra trampa. En un multisitio, los editores suelen pegar URL de archivos entre subsitios, usar campos personalizados que hacen referencia a rutas de subida antiguas o depender de plugins que reescriben la gestión de medios. Las miniaturas rotas son molestas. Los documentos, los materiales de campaña y los PDF localizados rotos generan tickets de soporte muy rápido.

Cree un registro de riesgos que de verdad pueda usar

Manténgalo lo bastante breve como para que el responsable de la migración lo lea durante el cambio.

Establezca desencadenantes objetivos de reversión

La reversión no debe depender de la confianza, del estado de ánimo ni de quién habla más alto en la llamada. Establezca desencadenantes medibles antes de la puesta en producción.

Ejemplos:

• Falla el acceso de administración para los propietarios principales de los sitios
• Fallan el checkout, los formularios de captación o los flujos de inicio de sesión
• El mapeo de dominios dirige el tráfico al subsitio equivocado
• Faltan metadatos multilingües críticos en páginas de producción
• Las licencias de plugins desactivan funciones necesarias
• Las tasas de error se disparan y no se pueden corregir dentro de la ventana de mantenimiento

Ponga el umbral por escrito y obtenga la aprobación del responsable de la migración, del product owner y de la persona que controla el DNS. También recomiendo escribir los comandos y las acciones exactas de la reversión, no solo la regla de decisión. En los incidentes reales, la claridad gana al optimismo.

Por ejemplo, si la reversión incluye restaurar la base de datos antigua y forzar el DNS de vuelta, anote la secuencia:

# Example rollback checks
wp site list
wp plugin list --network
wp search-replace 'https://new.example.com' 'https://old.example.com' --network --dry-run

Utilice ejecuciones de prueba (dry runs) durante la planificación para confirmar que el equipo tiene los accesos que cree tener. La noche de la migración, la falta de permisos de WP-CLI o una clave SSH equivocada consumen el tiempo que necesitaba para la recuperación.

Las buenas migraciones multisitio son cambios controlados. Los equipos que las superan limpiamente deciden el alcance pronto, documentan las dependencias ocultas, prueban el comportamiento de las licencias y del SEO antes del cambio y definen la reversión como si esperaran usarla.

Preparar los entornos y el DNS

La mayoría de las migraciones fallidas empiezan con un desajuste entre el entorno antiguo y el nuevo. No un desajuste dramático. Uno silencioso. Una extensión de PHP que falta en el destino, un problema de permisos del sistema de archivos en uploads, un hueco en las reglas de reescritura o cambios de DNS que se dejan para la última hora.

El nuevo entorno debe ser aburrido. Ese es el objetivo. Si el destino se comporta de forma distinta al origen de maneras que usted no ha tenido en cuenta, la migración sacará a la luz esas diferencias en forma de sesiones rotas, problemas con los medios o fallos de plugins.

Construya el destino a imagen del origen

Empiece con una instalación limpia de WordPress en el destino y prepárela para multisitio antes de importar nada. Si se traslada a una red nueva, cree el mismo patrón estructural que ya utiliza. No cambie de subdirectorios a subdominios en la misma migración salvo que haya un motivo de peso y una línea de pruebas independiente.

En esta fase, confirme:

• Compatibilidad de PHP: Ajuste las versiones compatibles que exigen el tema y el conjunto de plugins actuales.
• Acceso a la base de datos: Pruebe el acceso por CLI, los permisos de importación y el comportamiento al crear tablas.
• Propiedad del sistema de archivos: Asegúrese de que WordPress puede escribir en los directorios correctos sin apaños de permisos.
• Acceso por shell: Confirme el acceso por SSH y WP-CLI antes del día de la migración.
• Correo y servicios externos: Prepare todo lo que la red necesite para formularios, flujos transaccionales o webhooks.

Para los equipos que trasladan infraestructura como parte de un cambio de proveedor, en este punto resulta relevante una guía práctica para migrar un sitio de WordPress a un nuevo hosting, porque el cambio de hosting y el traslado del multisitio suelen solaparse en lo operativo aunque la ruta de los datos sea distinta.

Prepare el DNS tanto para el lanzamiento como para la retirada

La planificación del DNS no recibe suficiente atención en la mayoría de las guías de migración. Debería. Usted quiere que el cambio final sea rápido, pero también que la retirada lo sea si falla la validación en producción.

El hábito clave es reducir los TTL con mucha antelación a la ventana de migración. Eso le da un cambio más limpio y una opción de reversión realista. Si deja la preparación del DNS para demasiado tarde, aún puede migrar, pero su ventana de recuperación será más difícil de controlar.

Utilice esta lista de comprobación previa al cambio:

• Reduzca los TTL pronto: Hágalo mucho antes del lanzamiento, no durante.
• Documente los dominios mapeados: Sobre todo en redes multisitio con dominios de marca, de idioma o de cliente.
• Confirme la cobertura SSL: Los subdominios y los dominios mapeados deben resolverse correctamente tras el cambio.
• Prepare hosts de verificación: Utilice métodos de validación no públicos para probar el enrutamiento antes de cambiar el tráfico de producción.

No se salte la instalación limpia

Muchos equipos quieren copiar primero toda la instalación antigua y «limpiarla después». Eso suele arrastrar viejas suposiciones al nuevo entorno. Una instalación nueva en el destino le da una base conocida y facilita aislar los fallos.

Si el traslado incluye convertir un sitio independiente en un subsitio, o crear primero una red en el destino, la preparación del entorno también debe tener en cuenta las constantes de multisitio y la estructura de sitios que esperarán los datos importados. Ahí es donde los proyectos de migración o siguen bajo control o empiezan a acumular arreglos puntuales.

Copia de seguridad completa y migración de la base de datos

En esta fase, un solo comando erróneo puede tumbar todos los sitios de la red. En un multisitio, los usuarios, los roles, las tablas de los sitios, los ajustes de red y muchos datos de plugins están entrelazados. Una importación descuidada no falla limpiamente. Provoca roturas parciales que el equipo editorial descubre días después.

Hay dos caminos viables. Utilizar un plugin de migración creado para multisitio, o hacer el traslado con WP-CLI y responsabilizarse de cada paso. Yo uso ambos. La elección correcta depende del tamaño de la red, de la ventana de cambio y de cuánta disciplina operativa pueda mantener el equipo a las 2 de la madrugada.

Elija el método de migración según el riesgo, no la preferencia

Un plugin suele ser más seguro cuando el proyecto tiene una ventana de mantenimiento corta, un equipo de traspaso con menos experiencia o una red con muchos subsitios y dominios mapeados. All-in-One WP Migration sigue siendo una opción habitual porque empaqueta la red de forma que reduce los errores a nivel de tabla y realiza una búsqueda y sustitución consciente de WordPress durante la importación. Esa protección importa en un multisitio porque hay valores serializados dentro de opciones, widgets, datos de constructores de páginas y ajustes de plugins en toda la red.

WP-CLI encaja mejor cuando necesita repetibilidad mediante scripts, sustituciones selectivas, control específico por entorno o un registro de migración que pueda entregar a otro ingeniero durante una reversión. También es la mejor opción cuando las exigencias empresariales van más allá de la transferencia básica de datos. Las licencias de plugins pueden romperse tras un cambio de dominio o de servidor. Los plugins multilingües suelen guardar los metadatos SEO en tablas personalizadas o en conjuntos de opciones serializadas. Si esos valores no se migran limpiamente, las posiciones y las activaciones de licencias pueden caer a la vez.

Si el destino se construye desde cero, parta de una red limpia que coincida con la estructura que esperan los datos importados. Esto importa aún más si convierte una instalación independiente en una red o cambia entre el modo de subdominios y el de subdirectorios. Siga un proceso documentado de instalación y configuración de WordPress Multisite antes de importar para que la base de datos llegue a una red con las constantes y los supuestos de tablas correctos.

Flujo de trabajo con WP-CLI para equipos que necesitan control

Empiece con una exportación completa. No un volcado parcial. No «solo las tablas del sitio activo». Toda la red.

wp db export network-backup.sql --all-tables

Antes de cambiar las URL, haga una ejecución de prueba y revise la salida:

wp search-replace 'old-domain.com' 'new-domain.com' --network --precise --recurse-objects --all-tables --dry-run

Si el alcance parece correcto, ejecute la sustitución real:

wp search-replace 'old-domain.com' 'new-domain.com' --network --precise --recurse-objects --all-tables

Esos flags hacen un trabajo real. --network evita desajustes de un sitio a otro. --precise cambia velocidad por precisión, que suele ser el intercambio correcto durante una migración. --recurse-objects protege las estructuras serializadas. --all-tables incluye las tablas de plugins y personalizadas que los equipos olvidan hasta que falla algo crítico para el negocio.

Los datos serializados son la mina terrestre. Si la herramienta no entiende la serialización de WordPress, manténgala lejos de la base de datos.

Comandos esenciales de búsqueda y sustitución de WP-CLI para multisitio

Haga la copia de seguridad de la red como si esperara revertirla

Un conjunto de copias útil incluye más que una exportación SQL guardada en una carpeta compartida. En redes donde hay mucho en juego, quiero cuatro cosas antes de que nadie toque producción:

• Volcado completo de la base de datos: Incluya las tablas de red, de usuarios, de plugins y todo lo personalizado.
• Instantánea de wp-content: Temas, plugins, mu-plugins, subidas, archivos de idioma y código de integraciones a medida.
• Copias de la configuración: wp-config.php, ajustes de la caché de objetos, reglas vhost del servidor y cualquier configuración de cron o workers vinculada a la red.
• Notas de recuperación: Ubicación exacta de la restauración, quién la verificó, qué versión se capturó y cuánto se espera que tarde la restauración.

Este es también el momento de exportar todo lo que podría no sobrevivir limpiamente a un traslado normal de archivos y base de datos. Las claves de licencia de plugins premium son un ejemplo habitual. Algunos proveedores vinculan las activaciones a dominios, IP o huellas de máquina. Desactive cuando proceda, documente las activaciones actuales y confirme las condiciones de reemisión antes del cambio. Si la red utiliza plugins de SEO multilingüe, compruebe dónde se guardan los datos hreflang, los slugs traducidos, las reglas de redirección y los metadatos SEO. Perder esos datos no siempre aparece como un error de PHP. Aparece como pérdida de tráfico una semana después.

Errores recurrentes de base de datos en proyectos multisitio

Los mismos fallos aparecen una y otra vez:

• Ejecutar sustituciones SQL directas sobre contenido serializado
• Exportar solo las tablas visibles del sitio y omitir las tablas de red o de plugins
• Importar en un destino con el modo multisitio equivocado o con supuestos erróneos sobre el prefijo de tablas
• Olvidar los pasos de reactivación de licencias de plugins hasta que dejan de funcionar funciones críticas
• Actualizar los dominios principales sin revisar los campos de SEO multilingüe, las etiquetas canonical o las referencias hreflang

La solución no es complicada, pero exige disciplina. Exporte la red completa. Registre cada comando. Pruebe las sustituciones con --dry-run. Guarde intacta una copia de la base de datos previa a la migración. En las migraciones empresariales, el historial de comandos, los artefactos SQL y los inventarios de licencias forman parte de la continuidad del negocio, no son papeleo adicional.

Migrar los archivos y configurar la red

Los cambios del viernes por la noche fallan aquí más que en ningún otro sitio. La base de datos se importa limpiamente, la página de inicio se muestra, todo el mundo se relaja, y entonces el equipo editorial descubre medios que faltan, los plugins con licencia pasan a un modo restringido o un sitio regional mapeado empieza a servir los recursos equivocados. En una migración multisitio, el sistema de archivos y la configuración de la red deciden si la puesta en producción es estable o solo lo parece durante los primeros diez minutos.

El directorio de mayor riesgo suele ser wp-content/uploads. Es grande, desordenado y está lleno de archivos críticos para el negocio que nadie echa en falta hasta que desaparece una landing page de campaña, un PDF traducido o una imagen de producto.

Traslade los archivos: primero la integridad, después la velocidad

En redes grandes, rsync es la opción por defecto porque conserva la estructura, puede reanudarse limpiamente y le ofrece un método de transferencia que puede ejecutar más de una vez antes del cambio. Eso importa. Una única copia masiva de una sola vez es más lenta de validar y menos fiable.

Un patrón estándar es este:

rsync -avz --progress /path/to/source/wp-content/ /path/to/destination/wp-content/

En redes empresariales, divido la transferencia en fases. Primero copio temas, plugins y mu-plugins. Las subidas, por separado. Después, cerca del cambio, ejecuto una sincronización final que recoge solo los archivos modificados:

rsync -avz --delete /path/to/source/wp-content/uploads/ /path/to/destination/wp-content/uploads/

El flag --delete es útil, pero solo cuando está seguro de que el destino es desechable o ya está verificado. Si lo usa sin cuidado, puede borrar recursos que se prepararon manualmente en el destino.

Evite las sesiones largas de FTP para este trabajo. Son lentas, ocultan fallos parciales y dejan registros de auditoría confusos cuando alguien pregunta qué archivos llegaron. En directorios de subidas grandes, copiar de forma progresiva con rsync es una manera práctica de preservar la integridad de los archivos y mantener la transferencia repetible.

Los permisos merecen una comprobación aparte. Si la propiedad o los modos de los archivos cambian durante el traslado, la generación de imágenes, las escrituras en caché y las actualizaciones de plugins pueden fallar después del lanzamiento. Valídelos explícitamente:

find /path/to/destination/wp-content -type d -exec chmod 755 {} ;
find /path/to/destination/wp-content -type f -exec chmod 644 {} ;
chown -R www-data:www-data /path/to/destination/wp-content

Configure correctamente el multisitio en wp-config.php

El destino debe coincidir con el modelo de red que está migrando. Una pequeña errata en wp-config.php puede manifestarse como bucles de inicio de sesión, cookies rotas o subsitios que se resuelven al sitio principal.

Si se está activando el multisitio en el destino, añada:

define('WP_ALLOW_MULTISITE', true);

Esa constante va justo antes de la línea /* That's all, stop editing! Happy publishing. */. Una vez completada la configuración de la red, WordPress genera el resto de las constantes de multisitio y las reglas de reescritura según el modo de subdominios o de subdirectorios. Mantenga esos valores generados tal cual. Editarlos a mano sin motivo es la forma en que las redes que funcionan se vuelven incoherentes.

Si necesita una referencia sobre la instalación mientras valida las decisiones de arquitectura, esta guía para instalar WordPress Multisite le será útil antes de fijar la configuración del destino.

Dos ajustes merecen un escrutinio adicional durante la migración: la estructura de dominios y los supuestos sobre rutas. Si la red de origen usaba subdirectorios y el destino se reconstruye con subdominios, puede que los ajustes de los plugins, la lógica de redirección y las rutas del SEO multilingüe ya no coincidan con lo que tienen almacenado. La página de inicio puede seguir cargando mientras se rompen las referencias hreflang, los canonicals y las URL de medios específicas de cada idioma.

La guía de Updraft para convertir WordPress en multisitio también recuerda que WP_ALLOW_MULTISITE es solo el punto de entrada. En los proyectos en los que un sitio único pasa a ser un subsitio, importan el estado de los plugins y el destino correcto de la restauración. Restaurar en el contexto de sitio equivocado puede sobrescribir las tablas equivocadas o dejar el subsitio configurado como una instalación independiente.

Elija la estructura según la operativa, no la preferencia

Los subdominios y los subdirectorios son igual de válidos. La elección correcta depende de cómo funciona el negocio.

• Los subdominios encajan mejor cuando cada sitio se trata como una marca, un país o una entidad jurídica independiente, con su propio DNS, SSL y flujos de marketing.
• Los subdirectorios encajan mejor cuando la red se comporta como una única plataforma de publicación con autoridad compartida y contenidos estrechamente relacionados.
• Los dominios mapeados aumentan el riesgo operativo porque cada propiedad mapeada añade consideraciones de SSL, DNS, redirecciones, caché y reversión.

Aquí es también donde afloran los conflictos de licencias de plugins. Algunos plugins premium se licencian por dominio, por entorno o por sitio activo. Una red que funcionaba en el servidor de origen puede mostrar de repente funciones desactivadas en los dominios mapeados tras la migración. Revise los paneles de licencias antes del lanzamiento, sobre todo en los plugins de SEO, formularios, traducción y constructores de páginas. Esos fallos no siempre generan un error visible. Aparecen como salida de schema que falta, actualizaciones bloqueadas o avisos de administración que solo ven los administradores de la red.

Este es un recorrido útil antes de cerrar esos ajustes:

No pase por alto el código que vive fuera del tema

Los fallos de un multisitio suelen venir de código que nunca estuvo en el tema activo.

Revise todo lo siguiente:

• Plugins de uso obligatorio (must-use)
• Drop-ins
• Scripts cron personalizados
• Includes específicos de cada entorno
• Dependencias de las reglas de reescritura del servidor

Verifique también los drop-ins de caché de objetos, la configuración de sunrise si el mapeo de dominios depende de ella y cualquier enlace simbólico creado durante el despliegue. Esas piezas suelen dar soporte a la autenticación, las redirecciones, la caché de páginas, el tratamiento de imágenes y el enrutamiento multilingüe. Si falta una, la red puede parecer funcional mientras rutas clave del negocio fallan bajo carga o en dominios secundarios.

Trate el traslado del sistema de archivos como un despliegue en producción. Inventaríelo, sincronícelo por etapas y verifique primero las partes que afectan a los ingresos, al SEO y a la reversión.

Pruebas posteriores a la migración y mapeo de dominios

La migración no ha terminado cuando carga la página de inicio. Ese es el primer movimiento de las pruebas, no su conclusión. Una red multisitio puede parecer sana a simple vista mientras oculta roles de usuario rotos, rutas de medios no válidas, redirecciones mal formadas o un dominio mapeado que lleva al sitio equivocado.

La forma más rápida de detectarlo es tratar la validación posterior a la migración como un trabajo forense. No está demostrando que el sitio carga. Está intentando demostrar que no falta nada crítico.

Empiece por los sistemas más propensos a fallar

Delicious Brains indica que el manejo incorrecto de las rutas de los archivos multimedia es un escollo habitual en las migraciones multisitio y se produce en aproximadamente el 35 % de los intentos de migración manual, mientras que las migraciones automatizadas con comprobaciones previas pueden alcanzar un 92 % de éxito y las migraciones manuales sin comprobaciones previas fallan en un 28 % de los casos, según su análisis sobre cómo separar un WordPress Multisite y migrar un subsitio.

Esos datos coinciden con lo que ven los equipos en producción. Los medios son lo primero que se rompe porque dependen a la vez de la estructura de rutas, de los permisos y de que las URL sean correctas.

Empiece por:

• Bibliotecas de medios: Abra entradas antiguas, no solo nuevas. Revise imágenes destacadas, galerías, imágenes insertadas y archivos descargables.
• Acceso de administración: Verifique el Network Admin, la administración de los subsitios y los inicios de sesión de cada rol.
• Formularios y transacciones críticos: Pruebe envíos de formularios, búsqueda, carritos, contenido restringido y acciones activadas por correo electrónico.
• Salida de los plugins: Inspeccione todo lo que escriba URL personalizadas, incruste scripts o guarde datos en tablas personalizadas.

La página de inicio es la página de prueba menos útil en una migración multisitio. El contenido profundo revela el daño real.

Haga una ronda de verificación estructurada

Una buena ronda posterior a la migración va de las comprobaciones a nivel de red a las comprobaciones a nivel de subsitio. No salte de un lado a otro.

Comprobaciones a nivel de red

• Registro de sitios: Confirme que existe cada subsitio esperado y que se enruta correctamente.
• Usuarios compartidos: Pruebe con un usuario que pertenezca a varios sitios y verifique sus permisos en cada uno.
• Plugins de red: Confirme que los plugins activados en la red siguen funcionando como deben.
• Disponibilidad de temas: Asegúrese de que los temas habilitados son visibles donde deben serlo.

Comprobaciones a nivel de subsitio

• Representación del front-end: Revise la página de inicio, las landing pages clave, los archivos de entradas y los formularios.
• Experiencia editorial: Abra el editor de bloques, el cargador de medios, los patrones reutilizables y los campos personalizados.
• Comportamiento de las URL: Compruebe los enlaces permanentes, la paginación y las redirecciones.
• Contenido localizado: Revise el contenido y la navegación de cada idioma si la red es multilingüe.

Un registro de pruebas sencillo ayuda a los equipos a ser honestos:

Mapee los dominios solo cuando la red haya superado la validación

El mapeo de dominios debería ser uno de los últimos pasos, no una suposición temprana. Una vez que la red importada sea estable en el destino, apunte cada propiedad mapeada de forma deliberada y valide la respuesta sitio por sitio.

En redes sensibles al SEO, el mapeo de dominios también se cruza con la estructura de búsqueda. Si un subsitio multilingüe o un dominio regional cambia de comportamiento tras el traslado, debe revisar los canonicals, las etiquetas alternate y las rutas de rastreo. Esto es especialmente relevante para los equipos responsables del SEO de WordPress Multisite, donde el enrutamiento técnico y las señales de búsqueda están estrechamente vinculados.

Vuelva a guardar y a comprobar, pero no confíe solo en eso

Sí, volver a guardar los enlaces permanentes suele ayudar tras una importación. No, no es una solución completa. No restaurará las subidas que faltan, no resolverá los problemas de licencias de plugins ni recuperará las asignaciones de roles que salieron mal.

Una ronda de pruebas madura solo termina cuando los usuarios reales pueden hacer su trabajo en la nueva red. Hasta entonces, la migración sigue siendo provisional.

Planes de reversión y optimización de la puesta en producción

A las 2:07 de la madrugada, el cambio de DNS está activo, el inicio de sesión sigue funcionando y la página de inicio parece correcta. Diez minutos después, el tráfico de pago empieza a llegar al sitio regional equivocado, un plugin premium pasa al modo de prueba en dos subsitios y los canonicals vuelven a apuntar al dominio antiguo. Esa es la parte de una migración de WordPress Multisite que las listas de comprobación estándar subestiman. La transferencia puede salir bien y el lanzamiento fallar igualmente.

La reversión tiene que ser un procedimiento operativo, no una vaga promesa de «restaurar la copia de seguridad». En el trabajo de agencia, la diferencia es sencilla. Un plan de reversión real nombra el punto de restauración exacto, la secuencia de comandos, quién puede aprobar la marcha atrás, quién cambia el DNS y qué condiciones desencadenan la decisión. Sin eso, los equipos pierden de 30 a 60 minutos debatiendo mientras los usuarios y los rastreadores siguen llegando a un stack roto.

Escriba el plan de forma que el ingeniero de guardia pueda ejecutarlo medio dormido. Manténgalo breve y concreto:

1. Identificador de la versión vinculado al volcado final de la base de datos y a la instantánea de archivos
2. Comandos de restauración para la base de datos y las subidas
3. Responsable de revertir el DNS y vía de acceso al registrador o a la CDN
4. Notas de recuperación de licencias de plugins para todo lo que esté vinculado a un dominio, una IP o un entorno
5. Desencadenante de negocio para la reversión, como un fallo del checkout, administradores sin acceso o errores de enrutamiento entre dominios
6. Validación posterior a la reversión de las pocas funciones que importan primero

Por ejemplo, si la base de datos de destino ya está cargada y necesita revertir rápido, el runbook debería incluir los comandos exactos, no una referencia a «la copia de seguridad en S3»:

wp db import /backups/prod-prelaunch.sql
rsync -av /backups/uploads/ wp-content/uploads/
wp cache flush

Si intervienen la caché de objetos o Redis, añada también ese comando. Si su capa edge gestiona redirecciones, anote si la reversión incluye desactivar page rules o anulaciones del origen. He visto restauraciones de bases de datos técnicamente correctas fracasar porque Cloudflare, Route 53 o un balanceador de carga seguían sirviendo el nuevo origen.

El DNS suele ser la parte más lenta de una marcha atrás, por eso la optimización de la puesta en producción empieza antes de la noche del lanzamiento. Los TTL cortos ayudan, pero no garantizan una corrección instantánea. Algunos resolvedores los ignoran. Algunos clientes están detrás de cachés agresivas. Prevea un periodo de tráfico mixto en el que parte del público ve el stack antiguo y parte el nuevo.

Esa realidad cambia la forma de lanzar. Congele el contenido antes del cambio. Ponga en cola los pedidos o los cambios editoriales si el negocio puede tolerarlo. Si no puede, necesita un plan de conciliación para los comentarios, formularios, datos de comercio y registros de usuarios creados durante la ventana de solapamiento.

El SEO multilingüe necesita su propio umbral de reversión. En la práctica, es uno de los lugares donde más fácil resulta pasar por alto el riesgo de negocio, porque la página se muestra con normalidad. Los fallos ocultos están en los canonicals, los pares hreflang, las redirecciones regionales, los slugs traducidos, los sitemaps XML y los selectores de mercado. Según nuestra experiencia, las propiedades multisitio migradas suelen perder parte de esas señales durante la extracción o la reasignación de dominios, sobre todo cuando los plugins de SEO guardan los ajustes en un ámbito distinto del que esperaba el equipo.

Compruebe estos elementos inmediatamente después del cambio:

• Etiquetas canonical en las plantillas principales y las landing pages clave
• Pares hreflang para cada variante de idioma o de mercado
• Estructuras de URL localizadas como /de/ o subdominios por país
• Sitemaps generados por el plugin de SEO activo en el destino
• Comportamiento de las redirecciones desde las URL regionales heredadas
• Controles de indexación, para que las reglas noindex de staging no se cuelen en el lanzamiento

Las licencias de plugins merecen la misma atención. Los equipos empresariales caen aquí porque el plugin funcionaba dentro de la red antigua y luego falla en el sitio extraído o en el nuevo dominio. El modo de fallo rara vez es dramático. A menudo es un grupo de campos que falta, el envío de formularios desactivado, un canal de actualizaciones bloqueado o un banner que se convierte en una salida rota cuando caduca la caché. Si un proveedor de plugins vincula la licencia a la red original, incluya los pasos de activación manual en el runbook del lanzamiento y decida si esa situación es un desencadenante de reversión o una tarea conocida posterior al lanzamiento.

La optimización de la puesta en producción llega después de las comprobaciones de estabilidad, no antes. Vacíe las capas de caché. Precaliente las páginas importantes. Revise los logs de PHP, los logs del servidor web, las cadenas de redirección, los eventos de cron y el correo transaccional. Después, pruebe las rutas comerciales en condiciones reales: sesiones iniciadas, cambio de idioma, envíos de formularios, búsqueda, checkout y cualquier callback de terceros.

Utilice WP-CLI para la limpieza que debe ser repetible:

wp cache flush
wp rewrite flush --hard
wp cron event run --due-now
wp search-replace 'https://staging.example.com' 'https://example.com' --network --skip-columns=guid

Ese último comando es potente y peligroso. En un multisitio, ejecútelo solo después de confirmar los dominios de destino, los hosts mapeados y el alcance de los datos serializados. Una sustitución defectuosa en toda la red es la forma de provocar una segunda caída mientras intenta arreglar la primera.

Un buen lanzamiento es aburrido en el mejor sentido. Los usuarios siguen trabajando. Las señales de búsqueda se mantienen intactas. Los plugins con licencia siguen validándose. Y si alguno de ellos se rompe lo bastante como para amenazar los ingresos o las operaciones, la reversión es rápida porque el equipo ya eligió el desencadenante, el responsable y los comandos exactos.

Escenarios avanzados y preguntas frecuentes clave

Viernes, 17:30: la importación de la base de datos ha terminado, las subidas están en su sitio y el subsitio carga. Entonces las traducciones desaparecen de las etiquetas hreflang, un plugin de formularios pasa al modo de prueba y el equipo de SEO se da cuenta de que los canonicals apuntan ahora al antiguo dominio de la red. Esa es la parte que las guías estándar de migración multisitio suelen pasar por alto.

Los fallos caros en una migración de WordPress Multisite ocurren después de trasladar los archivos y las tablas. Las licencias de plugins pueden romperse cuando un subsitio sale de una red. Los plugins multilingües pueden seguir mostrando páginas mientras pierden las relaciones entre idiomas o los metadatos. Un plan de reversión que parecía correcto sobre el papel puede desmoronarse si nunca se probaron la reactivación de licencias, los tiempos del DNS o los callbacks de terceros.

Las licencias de plugins son un riesgo operativo, no una tarea de limpieza

Los debates del foro de soporte sobre la migración multisitio en WordPress.org señalan una y otra vez los plugins rotos como un problema habitual después de la migración, a menudo relacionado con las licencias, complementos de multisitio que faltan o ajustes específicos de la red. Trátelo como una línea de trabajo previa al lanzamiento, no como una sorpresa posterior.

Un plugin premium puede comportarse correctamente dentro de una red y fallar en cuanto un sitio pasa a ser independiente. Lo veo sobre todo con licencias vinculadas a un dominio, con plugins que guardan su estado en wp_sitemeta en lugar de en opciones por sitio y con proveedores que venden el soporte multisitio como un derecho aparte.

Revise estos puntos antes de aprobar el cambio:

• ¿Admite el plugin tanto instalaciones multisitio como independientes?
• ¿Es válida la licencia actual para el dominio de destino?
• ¿Los datos de activación están en opciones de red, opciones del sitio, tablas personalizadas o una API externa?
• ¿Se puede reactivar el plugin por CLI o solo a través de wp-admin?
• Si la licencia falla, ¿pierde el sitio funciones, pierde actualizaciones o deja de mostrar contenido crítico?

Si el proveedor no puede responder con claridad a esas preguntas, prevea una corrección manual y decida si un fallo del plugin bloquea el lanzamiento.

Puede inspeccionar rápidamente el ámbito de las opciones con WP-CLI:

wp option get active_plugins
wp site option get active_sitewide_plugins
wp db query "SELECT meta_key FROM wp_sitemeta ORDER BY meta_key;"

En los subsitios extraídos, compare también las tablas específicas de cada plugin. Algunos plugins guardan licencias, correspondencias de idiomas o el estado de colas fuera de las opciones normales.

El SEO multilingüe se rompe en silencio

Un subsitio multilingüe puede parecer correcto para el equipo editorial y aun así perder valor de búsqueda tras la migración. Los fallos habituales son canonicals incorrectos, etiquetas hreflang que faltan, slugs de URL traducidos rotos y selectores de idioma que apuntan a hosts antiguos. Por eso la validación multilingüe pertenece a la lista de comprobación del lanzamiento y no solo al control de calidad general.

En configuraciones con WPML, Polylang o soluciones multilingües a medida, verifique todo lo siguiente en el sitio migrado:

• Las etiquetas canonical apuntan al dominio activo correcto
• Las etiquetas hreflang hacen referencia a las variantes de idioma correctas
• Las páginas traducidas siguen vinculadas entre sí
• Los sitemaps XML incluyen todos los idiomas y los nombres de host correctos
• Las reglas de redirección conservan las rutas de idioma antiguas y los parámetros de consulta cuando es necesario

No se fíe de una comprobación de la página de inicio. Pruebe URL profundas, archivos paginados y las páginas que generan ingresos.

Tres preguntas frecuentes clave

¿Se puede migrar un sitio único a una red multisitio existente?
Sí, pero cree primero el subsitio de destino y restaure en el contexto de blog ID correcto. Si importa datos con el ID de sitio equivocado, las rutas de subida, los roles de usuario y los ajustes de los plugins pueden acabar vinculados a las tablas equivocadas. Compruebe el destino antes de importar con:

wp site list
wp db tables | grep _2_

Sustituya _2_ por el blog ID real que piensa utilizar.

¿Se puede separar un subsitio en su propia instalación independiente de WordPress?
Sí. La transferencia en sí suele ser sencilla. El riesgo está en todo lo que la rodea: reescritura de rutas de medios, tareas programadas, plugins con licencia y señales de SEO que antes se gestionaban a nivel de red. En los proyectos reales, la separación es donde se pone a prueba la continuidad del negocio.

¿Y los usuarios y los permisos?
En un multisitio, los usuarios son globales. Los roles, no. Tras la migración, confirme las capacidades en el sitio de destino, sobre todo para editores, gestores de tienda y cualquier cuenta integrada mediante SSO. Si la red original compartía usuarios entre propiedades, verifique si esos usuarios deben existir siquiera en el sitio extraído.

La pregunta que nadie hace a tiempo

¿Cuál es la reversión segura más rápida si el sitio migrado está en producción y empiezan a fallar las rutas que generan ingresos?
Utilice una reversión que restaure la última base de datos que se sabe que funcionaba, devuelva el tráfico al entorno antiguo e incluya los pasos con proveedores necesarios para volver a validar licencias o reactivar los servicios multilingües. Si su reversión depende de que las personas resuelvan cosas sobre la marcha durante una caída, no es un plan de reversión.

Tenga por escrito una secuencia con responsables designados, supuestos sobre los TTL del DNS y comandos de restauración exactos. Por ejemplo:

wp db import prelaunch-backup.sql
wp search-replace 'https://new.example.com' 'https://old.example.com' --skip-columns=guid
wp cache flush

Ejecútelo solo en el entorno que pretende restaurar. En un multisitio, una búsqueda y sustitución descuidada puede ampliar la caída.

Lo difícil de una migración multisitio es preservar el comportamiento del negocio bajo presión. La transferencia de datos es solo una capa. Las licencias, el SEO multilingüe y la disciplina de reversión son lo que evita que el traslado se convierta en un incidente que afecte a los ingresos.

Si su equipo necesita manos con experiencia para un traslado multisitio de alto riesgo, IMADO es el tipo de socio de ingeniería que conviene incorporar pronto. Se ocupa de las partes que suelen subestimarse, como la arquitectura multilingüe, la complejidad del multisitio, el rendimiento y la disciplina del lanzamiento, sin convertir el proyecto en una genérica «transferencia de sitio».