Migración WordPress: hosting, dominio, base de datos y redirecciones

Migración WordPress: hosting, dominio, base de datos y redirecciones

Última verificación: 13 de octubre de 2026
29 min de lectura
Guía
Desarrollador full-stack
500+ proyectos WP

Migrar tu sitio WordPress puede parecer una tarea intimidante, pero con los conocimientos y la preparación adecuados, se convierte en un proceso perfectamente manejable. Ya sea que estés cambiando de dominio, actualizando tu proveedor de hosting o reestructurando la arquitectura de tu sitio, esta guía completa te acompañará en cada paso del proceso de migración de WordPress.

#Dirección de WordPress y dirección del sitio

Antes de adentrarnos en las técnicas de migración, es fundamental entender las dos configuraciones de URL principales en WordPress:

  • Dirección de WordPress (URL): Es donde residen los archivos del núcleo de WordPress
  • Dirección del Sitio (URL): Es la dirección que los visitantes escriben en su navegador para llegar a tu sitio

Ambas configuraciones deben incluir la parte https:// y no deben tener una barra diagonal / al final. Estas configuraciones controlan cómo WordPress muestra las URLs a lo largo de tu sitio, incluyendo la sección de administración y el frontend.

#Cuándo hay que migrar un sitio WordPress

Existen varios escenarios que pueden requerir la migración de tu sitio WordPress:

  1. Cambios de Dominio: Rebranding o cambio a un mejor nombre de dominio
  2. Migración de Hosting: Mudanza a un mejor proveedor de hosting
  3. Cambios de Servidor: Actualización de la infraestructura del servidor
  4. Reestructuración del Sitio: Mover WordPress a un subdirectorio o directorio raíz
  5. De Desarrollo a Producción: Paso de entorno de staging a producción
  6. HTTP a HTTPS: Implementación de certificados SSL

#Copia de seguridad antes de migrar WordPress

#Qué copiar antes de migrar WordPress

Antes de intentar cualquier migración, crea copias de seguridad completas:

  1. Copia de Seguridad de Base de Datos: Exporta tu base de datos WordPress vía phpMyAdmin o WP-CLI
  2. Copia de Seguridad de Archivos: Descarga todos los archivos y directorios de WordPress
  3. Copia de Seguridad de Configuración: Guarda tu archivo wp-config.php por separado
  4. Configuraciónes de Plugins/Temás: Documenta las configuraciones personalizadas

#Cómo probar la migración en un entorno de staging

Siempre prueba las migraciones en un entorno de staging antes de ir a producción:

## Crear un subdirectorio de prueba
mkdir /var/www/html/test-site
## Copiar archivos a la ubicación de prueba
cp -r /var/www/html/wordpress/* /var/www/html/test-site/

#Cómo cambiar las URL de WordPress tras migrar

#Método 1: WP_HOME y WP_SITEURL en wp-config.php

Para cambios temporales de URL, añade estas líneas a tu wp-config.php:

define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

Ventajas: Rápido e inmediato Desventajas: Valores codificados directamente, ya no podrás editarlos en el admin de WordPress

#Método 2: cambiar siteurl y home desde functions.php

Si tienes acceso FTP pero no puedes acceder al admin de WordPress:

  1. Accede al archivo functions.php de tu tema activo
  2. Añade estas líneas después de la etiqueta de apertura <?php:
update_option('siteurl', 'https://example.com');
update_option('home', 'https://example.com');
  1. Sube el archivo y visita tu panel de administración
  2. Importante: Elimina estas líneas después de que el sitio funcióne

#Método 3: la constante RELOCATE en wp-config.php

WordPress incluye un método de reubicación automática:

  1. Edita wp-config.php y añade antes de “¡Eso es todo, deja de editar!”:
define('RELOCATE', true);
  1. Visita https://tusitio.com/wp-login.php
  2. Inicia sesión normalmente
  3. Verifica las URLs en Ajustes > Generales
  4. Elimina la constante RELOCATE después

Advertencia de Seguridad: Nunca dejes la constante RELOCATE en wp-config.php ya que crea vulnerabilidades de seguridad.

#Método 4: editar siteurl y home en phpMyAdmin

Para un control preciso, edita las URLs directamente en la base de datos:

  1. Accede a phpMyAdmin
  2. Selecciona tu base de datos WordPress
  3. Encuentra la tabla wp_options (el prefijo puede variar)
  4. Edita las filas ‘siteurl’ y ‘home’
  5. Actualiza option_value con las nuevas URLs

Crítico: ¡Siempre haz una copia de seguridad de tu base de datos antes de hacer ediciones directas!

#Migración manual de WordPress a otro servidor o dominio

#Cómo mover WordPress a otro servidor

Al migrar a un nuevo servidor:

  1. Copia de Seguridad Completa: Respaldo total del sitio y la base de datos
  2. Exportar Base de Datos: Usa phpMyAdmin o WP-CLI
  3. Transferir Archivos: Usa FTP, SFTP o rsync
  4. Importar Base de Datos: Crea una nueva base de datos e importa
  5. Actualizar wp-config.php: Modifica las credenciales de la base de datos
  6. Actualizar URLs: Usa uno de los métodos anteriores
  7. Probar Exhaustivamente: Verifica toda la funcionalidad

#Cómo cambiar el dominio de WordPress con WP-CLI

El cambio de dominio requiere atención especial a los datos serializados:

## Usando WP-CLI (recomendado)
wp search-replace 'dominioviejo.com' 'dominionuevo.com' --skip-columns=guid

## O usa plugins especializados como:
## - Better Search Replace

Importante: Nunca actualices la columna GUID en la tabla wp_posts. GUID significa Identificador Único Global y nunca debe cambiar para mantener la compatibilidad con lectores de feeds.

#Migración de subdirectorio a raíz

Mover WordPress de un subdirectorio a la raíz:

  1. Actualizar URLs en Admin de WordPress: Ajustes > Generales
  2. Copiar Archivos: Mover los archivos de WordPress a la nueva ubicación
  3. Actualizar .htaccess: Modificar las reglas de reescritura
  4. Actualizar Permalinks: Volver a guardar la estructura de enlaces permanentes
  5. Verificar Enlaces Internos: Actualizar URLs codificadas directamente

#Migración multisitio

WordPress Multisitio requiere consideraciones adicionales:

  1. Respaldo de la Red: Todos los sitios y bases de datos
  2. Editar wp-config.php: Actualizar las constantes multisitio
  3. Actualizar .htaccess: Modificar las reglas de reescritura multisitio
  4. Actualizaciones de Base de Datos: Actualizar las tablas wp_blogs y wp_site
  5. Opciones de Sitios Individuales: Actualizar las tablas de opciones de cada sitio

#Checklist después de migrar WordPress

#Qué probar justo después de migrar

  • Probar la funcionalidad del frontend
  • Verificar el acceso al admin
  • Comprobar todos los formularios y envíos
  • Probar la funcionalidad de e-commerce
  • Verificar el inicio de sesión/registro de usuarios

#Redirecciones 301 y sitemap tras cambiar de dominio

  • Implementar redirecciones 301 desde las URLs antiguas
  • Actualizar sitemap.xml
  • Enviar el nuevo sitemap a los motores de búsqueda
  • Actualizar la propiedad de Google Analytics
  • Verificar Google Search Console

#Caché, base de datos y SSL tras la migración

  • Limpiar todas las cachés
  • Optimizar las tablas de la base de datos
  • Comprobar la compatibilidad de plugins
  • Probar la velocidad del sitio
  • Verificar el certificado SSL

#Errores al migrar WordPress y cómo solucionarlos

#Pantalla blanca de la muerte tras migrar

Generalmente causada por:

  • Agotamiento del límite de memoria
  • Conflictos de plugins
  • Incompatibilidad de temas

Solución: Aumentar el límite de memoria en wp-config.php:

define('WP_MEMORY_LIMIT', '256M');

#Errores de conexión a la base de datos

Verifica los ajustes de wp-config.php:

define('DB_NAME', 'nombre_base_datos');
define('DB_USER', 'usuario');
define('DB_PASSWORD', 'contraseña');
define('DB_HOST', 'localhost');

#Problemas de contenido mixto

Recursos HTTP en páginas HTTPS causan advertencias de seguridad:

## Encontrar contenido mixto
grep -r "http://" wp-content/

#Problemas de enlaces de imágenes y medios

Actualizar URLs de medios en la base de datos:

UPDATE wp_posts SET post_content = REPLACE(post_content,'dominioviejo.com/wp-content/uploads','dominionuevo.com/wp-content/uploads');

#Plugins y herramientas para migrar WordPress

#Plugins de migración recomendados

  1. All-in-One WP Migration: Herramienta completa de migración de sitios
  2. Duplicator: Crea paquetes de migración fácilmente
  3. WP Migrate Lite (antes WP Migrate DB): exportación de la base de datos con buscar y reemplazar
  4. Better Search Replace: buscar y reemplazar desde el escritorio, con soporte para datos serializados (Velvet Blues Update URLs está cerrado en el directorio de plugins desde el 3 de mayo de 2024)
  5. Migrator: copia de seguridad y migración en un solo archivo, sin límite de tamaño artificial (según las FAQ de All-in-One WP Migration, el límite de importación lo fija el tamaño de subida del hosting, no el plugin) y con reescritura de URL segura para datos serializados. Consulta la guía de copia de seguridad y migración.

#Comandos WP-CLI para exportar, importar y reemplazar URL

## Exportación de base de datos con WP-CLI
wp db export backup.sql

## Importación de base de datos con WP-CLI
wp db import backup.sql

## Búsqueda y reemplazo
wp search-replace 'url-antigua' 'url-nueva' --dry-run

#Seguridad al migrar WordPress de hosting

  1. Usa HTTPS: Asegúrate de que SSL esté configurado en el nuevo servidor
  2. Actualiza los Permisos de Archivos: Protege wp-config.php (600) y los directorios (755)
  3. Elimina Scripts de Migración: Borra archivos temporales y constantes
  4. Actualiza las Claves de Seguridad: Genera nuevas claves de WordPress en wp-config.php
  5. Monitorea los Logs: Vigila actividad inusual después de la migración

#Optimización del rendimiento después de la migración

#Optimizar tablas con OPTIMIZE TABLE

OPTIMIZE TABLE wp_posts;
OPTIMIZE TABLE wp_postmeta;
OPTIMIZE TABLE wp_options;

#Caché y CDN en el nuevo hosting

  • Configura el caché de páginas
  • Establece el caché del navegador
  • Activa la integración con CDN
  • Optimiza el caché de la base de datos

#Cómo probar WordPress después de la migración

#Probar menús, formularios, búsqueda y medios

  1. Navegación: Todos los elementos del menú funcionan correctamente
  2. Formularios: Los formularios de contacto y envíos funcionan
  3. Búsqueda: La búsqueda del sitio devuelve resultados
  4. Comentarios: El sistema de comentarios funciona
  5. Medios: Las imágenes y videos cargan correctamente

#Revisar meta etiquetas, URL canónicas y schema

  1. Meta Tags: Los títulos y descripciones se muestran correctamente
  2. URLs Canónicas: Apuntan al nuevo dominio
  3. Datos Estructurados: El marcado schema se válida correctamente
  4. Enlaces Internos: Todos los enlaces funcionan y redirigen apropiadamente

#Monitorizar WordPress después de la migración

#Monitorizar uptime, Search Console y errores 404

  • Configura el monitoreo de tiempo de actividad
  • Supervisa Google Search Console para detectar errores
  • Rastrea las analíticas para patrones de tráfico
  • Vigila errores 404 en los logs

#Mantenimiento continuo después de la mudanza

  • Optimización regular de la base de datos
  • Optimización y compresión de imágenes
  • Monitoreo del rendimiento de plugins
  • Implementación de auditoría de seguridad

#Cómo migrar WordPress sin caída del servicio con el TTL de DNS

Un resolver puede guardar en caché un registro DNS durante el tiempo que permite su TTL (RFC 1035, sección 3.2.1). Eso fija el orden de los pasos:

  • Baja el TTL con antelación. Pon los registros A y AAAA con un TTL corto, por ejemplo 300 segundos, al menos un TTL antiguo completo antes del cambio. Si el valor anterior era 86400 segundos, eso significa un día antes, porque hasta que caduque los resolvers siguen respondiendo con la IP antigua.
  • Prueba el servidor nuevo con el archivo hosts. Asocia el dominio a la IP nueva en tu archivo hosts local y recorre el checkout, el acceso y los formularios en el servidor de destino antes de que cambie el registro público. Los visitantes siguen llegando al servidor antiguo.
  • Congela las escrituras para el volcado final. Los pedidos, comentarios y envíos de formularios que lleguen al servidor antiguo después del último wp db export no se trasladan. Pon el sitio antiguo en modo mantenimiento, o detén la publicación, durante la exportación e importación finales.

#Cómo transferir una biblioteca de medios grande con rsync

FTP vuelve a copiar cada archivo en cada intento. rsync sobre SSH compara origen y destino y envía solo las diferencias, así que una segunda pasada mueve solo lo que cambió desde la primera (manual de rsync).

  • Ejecútalo dos veces. La primera pasada copia wp-content/uploads mientras el sitio antiguo sigue en línea. La segunda, durante la congelación de escrituras, recoge los archivos añadidos entretanto.
  • Reemplaza las URL con WP-CLI, no con SQL. WordPress guarda opciones y ajustes de widgets como arrays PHP serializados que registran la longitud de cada cadena. wp search-replace reescribe esas longitudes, un REPLACE() de SQL no.
  • Regenera las miniaturas si cambia el tema. wp media regenerate vuelve a crear las miniaturas para los tamaños de imagen registrados en la instalación nueva, y --only-missing lo limita a las imágenes a las que les faltan tamaños (WP-CLI: wp media regenerate).

#Cómo revisar SEO, SSL y Core Web Vitals tras migrar WordPress

  • Rastrea la lista de URL antiguas. Cada URL antigua debe responder con un 301 hacia su equivalente nueva, y ningún enlace interno debe devolver un 404. Google recomienda redirecciones permanentes del lado del servidor de las URL antiguas a las nuevas en un traslado de sitio, y un cambio de dirección en Search Console cuando cambia el dominio (Google Search Central: traslados de sitios con cambios de URL).
  • TLS y HSTS. Instala el certificado en el servidor nuevo antes del cambio. HTTP Strict Transport Security obliga a los navegadores a usar solo HTTPS con el dominio durante todo el periodo max-age (RFC 6797), así que actívalo solo cuando HTTPS funcione en todos los subdominios que cubre.
  • Mide antes y después. Pasa PageSpeed Insights por las mismas plantillas en el servidor antiguo y en el nuevo. La caché de página, OPcache, la caché de objetos y la compresión gzip o Brotli del nuevo hosting se notan en el tiempo de respuesta del servidor.

#Obligaciones del RGPD al cambiar de hosting WordPress

Para el sitio de una empresa en la UE, un hosting nuevo es también un nuevo encargado del tratamiento de datos personales:

  • Un contrato de encargo con el nuevo proveedor. El artículo 28 del RGPD exige un contrato que fije el objeto, la duración, la naturaleza y la finalidad del tratamiento, y que obligue al encargado a las medidas de seguridad del artículo 32 (RGPD, Reglamento (UE) 2016/679).
  • Actualiza la política de privacidad. Si el traslado añade una CDN, una nueva ubicación de copias de seguridad o un nuevo hosting, la lista de destinatarios de la política de privacidad cambia con él.
  • Supresión en el proveedor antiguo. Según el artículo 28, apartado 3, letra g, el encargado suprime o devuelve los datos personales al terminar el servicio, a elección del responsable. Cuando el servidor nuevo funcione de forma estable, pide al proveedor antiguo que confirme la eliminación de archivos, bases de datos y copias.

#Despliegue de WordPress con GitHub Actions y rollback

  • Despliega desde el repositorio. Un workflow de GitHub Actions o GitLab CI compila los assets del tema y publica el código en cada push a la rama principal, así que en el servidor no hay archivos editados a mano.
  • Conserva la versión anterior. Cada versión va a su propio directorio y un enlace simbólico apunta a la activa. Revertir el código es apuntar el enlace a la versión anterior. Haz un wp db export antes de cualquier paso que cambie la base de datos, porque revertir el código no deshace cambios en tablas ni en contenido.
  • Las mismas versiones en todas partes. Iguala las versiones de PHP y de MySQL o MariaDB entre local, staging y producción, para que una migración probada en staging se comporte igual en producción.

#Cómo trata wp search-replace los datos serializados

El manual de WordPress advierte que una búsqueda y reemplazo general en la base de datos puede romper los datos serializados y que la columna guid de wp_posts no se debe cambiar nunca (Moving WordPress). wp search-replace está hecho para este caso: maneja datos PHP serializados y no cambia los valores de clave primaria (WP-CLI: wp search-replace). Las opciones que importan en una migración:

  • --dry-run informa de lo que cambiaría y no guarda nada.
  • --skip-columns=guid deja los GUID de las entradas como están.
  • --precise fuerza el procesamiento en PHP de todas las columnas. Es más lento y más fiable con datos serializados complejos.
  • --network abarca todas las tablas de una red multisitio. Sin ella, solo se buscan las tablas del sitio actual.
  • --all-tables-with-prefix añade tablas que los plugins crearon con el prefijo de WordPress sin registrarlas, y --all-tables toma todas las tablas de la base de datos.
  • --export=archivo.sql escribe los datos cambiados en un archivo SQL en lugar de en la base de datos, útil cuando la base de destino está en otro servidor.

Las tablas sin clave primaria se omiten, así que una tabla de plugin sin ella necesita una revisión aparte. Para multisitio, el manual enumera además lo que hay que revisar a mano: las tablas wp_blogs y wp_site y las opciones home, siteurl y fileupload_url de cada sitio.

wp db export y wp db import completan el conjunto. La exportación ejecuta mysqldump con las credenciales de wp-config.php y acepta cualquier opción de mysqldump, y wp db export - escribe en STDOUT (WP-CLI: wp db export). La importación no crea la base de datos, solo ejecuta el SQL del archivo, y wp db import - lee de STDIN (WP-CLI: wp db import). Crea antes la base de datos vacía en el destino.

#Casos reales de migración de WordPress

#Caso de estudio 1: tienda con 50.000 productos a un nuevo dominio

Escenario: Una tienda online popular con más de 50,000 productos necesitaba migrar de tienda-antigua.com a marcanew.com manteniendo los rankings SEO y la confianza del clientes.

Desafíos Enfrentados:

  • Base de datos masiva de productos con variaciones complejas
  • Sesiónes activas de carrito de compras durante la migración
  • Integraciones con pasarelas de pago de terceros
  • Campañas de email con enlaces al dominio antiguo

Estrategia de Migración:

  1. Preparación pre-migración (2 semanas):

    • Creación de copia de seguridad completa incluyendo datos de clientes
    • Configuración de entorno de staging temporal
    • Pruebas de todas las integraciones de pasarelas de pago
    • Preparación de plantillas de email para notificación a clientes

  2. Implementación técnica (4 horas):

    • Uso de WP-CLI para reemplazo de URLs en la base de datos
    • Implementación de reglas de redirección 301 personalizadas
    • Actualización de todos los endpoints de API de terceros
    • Configuración de certificado SSL para el nuevo dominio

  3. Optimización post-migración (1 semana):

    • Monitoreo de Google Search Console para problemas de indexación
    • Actualización de todos los flujos de automatización de marketing
    • Implementación de seguimiento mejorado para impacto de la migración
    • Encuesta de satisfacción del clientes

Resultados:

  • Casi todos los rankings SEO mantenidos en 2 semanas
  • Cero pérdida de datos durante la migración
  • Quejas de clientes claramente reducidas con comunicación adecuada
  • Mejora de la velocidad del sitio gracias a la nueva infraestructura de hosting

Lecciones Clave Aprendidas:

  • La comunicación con el clientes es tan importante como la ejecución técnica
  • Probar las pasarelas de pago en entorno de staging previene pérdida de ingresos
  • Tener un plan de rollback listo proporciona confianza durante la ejecución

#Caso de estudio 2: red multisitio de 200 sitios a la nube

Escenario: Una institución educativa con más de 200 sitios en subdominios necesitaba migrar de hosting compartido a infraestructura cloud dedicada.

Complejidad Técnica:

  • 201 sitios WordPress individuales
  • Roles de usuario personalizados y permisos entre sitios
  • Biblioteca de medios compartida con más de 100GB de contenido
  • Dependencias complejas de plugins entre sitios

Enfoque de Migración:

  1. Fase de Análisis de la Red:

    • Mapeo de todas las interdependencias entre sitios
    • Identificación de configuraciones personalizadas de plugins
    • Documentación de jerarquías de roles de usuario
    • Análisis de patrones de uso de la biblioteca de medios

  2. Configuración del Entorno de Staging:

    • Replicación exacta de la configuración del servidor
    • Creación de scripts de prueba automatizados
    • Implementación de monitoreo de rendimiento
    • Configuración de procedimientos de rollback

  3. Migración por Fases:

    • Migración de 10 sitios piloto primero
    • Documentación y refinamiento del proceso
    • Migración por lotes de los sitios restantes
    • Monitoreo y optimización continúa

Soluciones Técnicas:

## Script personalizado para migración multisitio por lotes
#!/bin/bash
for site in $(wp site list --field=url); do
    echo "Migrando $site"
    wp search-replace 'dominio-antiguo.com' 'dominio-nuevo.com' --url=$site
    wp cache flush --url=$site
done

Resultados:

  • 99.8% de tiempo de actividad durante el proceso de migración
  • 40% de mejora en los tiempos de carga de página
  • Cero corrupción de datos en todos los sitios
  • Administración simplificada a través de gestión centralizada

#Caso de estudio 3: blog a HTTPS y corrección de contenido mixto

Escenario: Un blog con gran cantidad de contenido con más de 10,000 publicaciones y una amplia biblioteca de medios necesitaba la implementación de HTTPS.

Desafíos de Contenido Mixto:

  • Enlaces HTTP codificados directamente en el contenido de publicaciones
  • Recursos externos sin alternativas HTTPS
  • Iframes incrustados de fuentes no seguras
  • CSS personalizado con referencias HTTP

Solución Integral:

  1. Auditoría y Limpieza de Contenido:
-- Buscar y reemplazar referencias HTTP en publicaciones
UPDATE wp_posts
SET post_content = REPLACE(post_content, 'http://ejemplo.com', 'https://ejemplo.com')
WHERE post_content LIKE '%http://ejemplo.com%';

-- No toques la columna guid: la documentación de WordPress dice que nunca se cambia
  1. Actualizaciones de Configuración de Plugins:
// Adiciones personalizadas a functions.php para forzar HTTPS
add_action('template_redirect', function() {
    if (!is_ssl() && !is_admin()) {
        wp_redirect('https://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'], 301);
        exit;
    }
});
  1. Configuración Avanzada de .htaccess:
## Forzar HTTPS para todo el tráfico
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Impacto en el Rendimiento:

  • Caída inicial del 5% en el tráfico durante la primera semana
  • Recuperación total en 3 semanas
  • 10% de mejora en los rankings de búsqueda
  • Métricas mejoradas de confianza del usuario y seguridad

#Migrar bases de datos WordPress grandes y datos serializados

#Cómo migrar bases de datos de más de 1 GB

#Manejo eficiente de bases de datos grandes

Para bases de datos que superan 1GB, los métodos estándar de exportación/importación a menudo fallan. Aquí tienes técnicas avanzadas:

Método 1: Exportación por Fragmentos con WP-CLI

## Exportar por fragmentos para bases de datos grandes
wp db export fragmento1.sql --tables=wp_posts,wp_postmeta --add-drop-table
wp db export fragmento2.sql --tables=wp_options,wp_users,wp_usermeta --add-drop-table

## Combinar e importar por separado
mysql nueva_base_datos < fragmento1.sql
mysql nueva_base_datos < fragmento2.sql

Método 2: volcado comprimido con gzip en lugar de un script PHP propio

## Enviar el volcado directamente a gzip, sin archivo sin comprimir en disco
wp db export - --single-transaction --quick | gzip > db.sql.gz

## Importar desde STDIN en el servidor de destino
gunzip < db.sql.gz | wp db import -

#Manejo de datos serializados

WordPress almacena muchas configuraciones como datos PHP serializados, que se rompen cuando cambian las longitudes de las URLs:

Reemplazo seguro para datos serializados con WP-CLI:

## Primero la vista previa, después sin --dry-run
wp search-replace 'https://dominioviejo.com' 'https://dominionuevo.com' --skip-columns=guid --precise --dry-run
wp search-replace 'https://dominioviejo.com' 'https://dominionuevo.com' --skip-columns=guid --precise

#Script bash para automatizar la migración de WordPress

#Framework de automatización de migración

Crea un script completo de automatización de migración:

#!/bin/bash
## Script de Automatización de Migración WordPress

set -e  # Salir ante cualquier error

## Configuración
OLD_DOMAIN="sitio-viejo.com"
NEW_DOMAIN="sitio-nuevo.com"
BACKUP_DIR="/ruta/a/copias"
STAGING_DIR="/ruta/a/staging"
LOG_FILE="$BACKUP_DIR/migración_$(date +%Y%m%d_%H%M%S).log"

## Función de registro
log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a "$LOG_FILE"
}

## ¿Qué comprobar antes de migrar un sitio WordPress?
pre_migration_checks() {
    log "Iniciando verificaciones pre-migración"

    # Verificar instalación de WordPress
    if ! wp core is-installed --path=/var/www/html; then
        log "ERROR: Instalación de WordPress no encontrada"
        exit 1
    fi

    # Verificar conexión a base de datos
    if ! wp db check --path=/var/www/html; then
        log "ERROR: Falló la conexión a la base de datos"
        exit 1
    fi

    # Crear directorio de copias de seguridad
    mkdir -p "$BACKUP_DIR"
    mkdir -p "$STAGING_DIR"

    log "Verificaciones pre-migración completadas"
}

## Creación de copias de seguridad
create_backups() {
    log "Creando copias de seguridad completas"

    # Copia de seguridad de base de datos
    wp db export "$BACKUP_DIR/base_datos_$(date +%Y%m%d_%H%M%S).sql" --path=/var/www/html

    # Copia de seguridad de archivos
    tar -czf "$BACKUP_DIR/archivos_$(date +%Y%m%d_%H%M%S).tar.gz" /var/www/html

    # Copia de seguridad de configuración
    cp /var/www/html/wp-config.php "$BACKUP_DIR/wp-config_$(date +%Y%m%d_%H%M%S).php"

    log "Copias de seguridad completadas exitosamente"
}

## Reemplazo de URLs
replace_urls() {
    log "Iniciando proceso de reemplazo de URLs"

    # URLs principales de WordPress
    wp search-replace "$OLD_DOMAIN" "$NEW_DOMAIN" --skip-columns=guid --path=/var/www/html

    log "Reemplazo de URLs completado"
}

## Validación post-migración
post_migration_validation() {
    log "Iniciando validación post-migración"

    # Probar accesibilidad del sitio
    if curl -f -s "https://$NEW_DOMAIN" > /dev/null; then
        log "El sitio es accesible"
    else
        log "ERROR: El sitio no es accesible"
        exit 1
    fi

    # Probar admin de WordPress
    if curl -f -s "https://$NEW_DOMAIN/wp-admin/" > /dev/null; then
        log "Admin de WordPress es accesible"
    else
        log "ERROR: Admin de WordPress no es accesible"
        exit 1
    fi

    # Verificar integridad de la base de datos
    wp db check --path=/var/www/html

    log "Validación post-migración completada"
}

## Ejecución principal
main() {
    log "Iniciando proceso de migración WordPress"

    pre_migration_checks
    create_backups
    replace_urls
    post_migration_validation

    log "Migración completada exitosamente"
}

## Ejecutar función principal
main

#Configurar Nginx, PHP y MySQL tras la migración

#Ajustes de Nginx y PHP tras la migración

#Configuración Nginx para sitios migrados

server {
    listen 80;
    server_name sitio-nuevo.com www.sitio-nuevo.com;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    server_name sitio-nuevo.com www.sitio-nuevo.com;

    root /var/www/html;
    index index.php index.html;

    # Configuración SSL
    ssl_certificate /ruta/a/ssl/cert.pem;
    ssl_certificate_key /ruta/a/ssl/private.key;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512;

    # Configuración específica de WordPress
    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;

        # Optimizaciónes de rendimiento
        fastcgi_buffer_size 128k;
        fastcgi_buffers 4 256k;
        fastcgi_busy_buffers_size 256k;
    }

    # Configuración de caché
    location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
    }

    # Cabeceras de seguridad
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "no-referrer-when-downgrade" always;
    add_header Content-Security-Policy "default-src 'self' http: https: data: blob: 'unsafe-inline'" always;
}

#Optimización PHP para rendimiento de migración

; Configuración PHP optimizada para migración WordPress
memory_limit = 512M
max_execution_time = 300
max_input_time = 300
upload_max_filesize = 64M
post_max_size = 64M
max_input_vars = 3000

; Configuración OPcache para mejor rendimiento
opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=2
opcache.fast_shutdown=1

#Ajuste del rendimiento de la base de datos

#Optimización de la configuración MySQL

-- Optimización MySQL para WordPress
SET GLOBAL innodb_buffer_pool_size = 1073741824; -- 1GB
SET GLOBAL innodb_log_file_size = 268435456; -- 256MB
SET GLOBAL innodb_flush_log_at_trx_commit = 2;
SET GLOBAL innodb_flush_method = O_DIRECT;

-- Configuración de caché de consultas
SET GLOBAL query_cache_type = ON;
SET GLOBAL query_cache_size = 67108864; -- 64MB

#Estrategia de indexación de la base de datos

-- Añadir índices para mejor rendimiento
ALTER TABLE wp_posts ADD INDEX idx_post_type_status (post_type, post_status);
ALTER TABLE wp_postmeta ADD INDEX idx_meta_key_value (meta_key, meta_value(191));
ALTER TABLE wp_options ADD INDEX idx_autoload (autoload, option_name);

-- Optimizar tablas grandes
OPTIMIZE TABLE wp_posts;
OPTIMIZE TABLE wp_postmeta;
OPTIMIZE TABLE wp_options;

#Corregir datos serializados y errores de memoria al migrar

#Errores de datos serializados, memoria y plugins

#Problema 1: Corrupción de datos serializados

Problema: Después del reemplazo de URLs, las opciones del tema y la configuración de plugins se corrompen.

Diagnóstico:

<?php
// Listar opciones cuyo valor serializado ya no se puede deserializar (ejecutar con wp eval-file)
global $wpdb;
$rows = $wpdb->get_results( "SELECT option_name, option_value FROM {$wpdb->options}" );
foreach ( $rows as $row ) {
    $v = $row->option_value;
    if ( is_serialized( $v ) && 'b:0;' !== $v && false === @unserialize( $v ) ) {
        echo $row->option_name . "\n";
    }
}

Solución:

## Restaurar el volcado previo al reemplazo y repetirlo con WP-CLI
wp db import backup-before-replace.sql
wp search-replace 'https://dominioviejo.com' 'https://dominionuevo.com' --skip-columns=guid --precise

#Problema 2: Agotamiento de memoria durante migración de base de datos grande

Problema: Los límites de memoria PHP se exceden durante la importación/exportación de la base de datos.

Soluciones:

Método 1: Procesamiento por Fragmentos

<?php
// Procesar base de datos en fragmentos para evitar problemas de memoria
function process_database_in_chunks($table, $chunk_size = 1000) {
    global $wpdb;

    $offset = 0;
    do {
        $results = $wpdb->get_results("
            SELECT * FROM $table
            LIMIT $offset, $chunk_size
        ");

        foreach ($results as $row) {
            // Procesar cada fila
            process_row($row);
        }

        $offset += $chunk_size;

        // Liberar memoria
        $wpdb->flush();

    } while (count($results) === $chunk_size);
}
?>

Método 2: Exportación de Base de Datos por Streaming

## Usar mysqldump con compresión para bases de datos grandes
mysqldump --single-transaction --quick --lock-tables=false \
  --host=localhost --user=usuario --password=contraseña \
  nombre_base_datos | gzip > backup.sql.gz

## Importar con streaming
gunzip < backup.sql.gz | mysql -u usuario -p nombre_base_datos

#Problema 3: Compatibilidad de plugins después de la migración

Problema: Los plugins dejan de funcionar después de los cambios de URL debido a referencias codificadas directamente.

Solución Sistemática:

  1. Crear Verificador de Compatibilidad de Plugins:
<?php
// Verificador de compatibilidad de plugins
function check_plugin_compatibility() {
    $plugins = get_option('active_plugins');
    $issues = [];

    foreach ($plugins as $plugin_path) {
        $plugin_data = get_plugin_data(WP_PLUGIN_DIR . '/' . $plugin_path);

        // Verificar URLs codificadas en archivos de plugins
        $plugin_files = glob(WP_PLUGIN_DIR . '/' . dirname($plugin_path) . '/*.php');

        foreach ($plugin_files as $file) {
            $content = file_get_contents($file);

            // Buscar URLs potencialmente codificadas
            if (preg_match('/https?:\/\/[^\s"\'<]+/', $content, $matches)) {
                $issues[] = [
                    'plugin' => $plugin_data['Name'],
                    'file' => $file,
                    'hardcoded_urls' => $matches
                ];
            }
        }
    }

    return $issues;
}
?>
  1. Reemplazar URL en ajustes de plugins con WP-CLI:
## Solo wp_options, modo PHP para valores serializados anidados
wp search-replace 'https://dominioviejo.com' 'https://dominionuevo.com' wp_options --precise --dry-run

#Automatizar migraciones WordPress con GitHub Actions

#Cómo probar migraciones en un pipeline de CI

#Flujo de trabajo GitHub Actions para pruebas automatizadas

name: Prueba de Migración WordPress

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  migration-test:
    runs-on: ubuntu-latest

    services:
      mysql:
        image: mysql:8.0
        env:
          MYSQL_ROOT_PASSWORD: password
          MYSQL_DATABASE: wordpress_test
        options: >-
          --health-cmd="mysqladmin ping"
          --health-interval=10s
          --health-timeout=5s
          --health-retries=3

    steps:
    - uses: actions/checkout@v3

    - name: Configurar PHP
      uses: shivammathur/setup-php@v2
      with:
        php-versión: '8.1'
        extensións: mysqli, gd, xml, mbstring

    - name: Instalar WordPress
      run: |
        curl -O https://wordpress.org/latest.tar.gz
        tar -xzf latest.tar.gz
        cp -r wordpress/* /var/www/html/

    - name: Configurar WordPress
      run: |
        cp wp-config-sample.php wp-config.php
        sed -i "s/database_name_here/wordpress_test/" wp-config.php
        sed -i "s/username_here/root/" wp-config.php
        sed -i "s/password_here/password/" wp-config.php
        sed -i "s/localhost/127.0.0.1/" wp-config.php

    - name: Instalar WP-CLI
      run: |
        curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
        chmod +x wp-cli.phar
        sudo mv wp-cli.phar /usr/local/bin/wp

    - name: Ejecutar Pruebas de Migración
      run: |
        wp core install --url=http://localhost --title="Sitio de Prueba" --admin_user=admin --admin_password=password [email protected]
        wp plugin install all-in-one-wp-migration --activate

    - name: Validar Migración
      run: |
        wp option get siteurl
        wp option get home

#Script de despliegue automatizado

#!/bin/bash
## Script de Despliegue Automatizado WordPress

set -e

## Variables de entorno
ENVIRONMENT=${1:-staging}
BACKUP_DIR="/copias/wordpress"
DEPLOY_LOG="/var/log/deploy.log"

## Función de registro
log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] [$ENVIRONMENT] $1" | tee -a "$DEPLOY_LOG"
}

## Verificaciones pre-despliegue
pre_deployment_checks() {
    log "Iniciando verificaciones pre-despliegue"

    # Verificar si WordPress está instalado
    if ! wp core is-installed --path=/var/www/html; then
        log "ERROR: WordPress no está instalado correctamente"
        exit 1
    fi

    # Verificar conectividad de base de datos
    if ! wp db check --path=/var/www/html; then
        log "ERROR: Falló la conexión a la base de datos"
        exit 1
    fi

    # Verificar que los plugins requeridos están activos
    if ! wp plugin is-active all-in-one-wp-migration --path=/var/www/html; then
        log "ERROR: Plugin requerido de migración no está activo"
        exit 1
    fi

    log "Verificaciones pre-despliegue completadas"
}

## Crear copia de seguridad del despliegue
create_deployment_backup() {
    log "Creando copia de seguridad del despliegue"

    local timestamp=$(date +%Y%m%d_%H%M%S)
    local backup_file="$BACKUP_DIR/pre_deploy_${ENVIRONMENT}_$timestamp.sql"

    wp db export "$backup_file" --path=/var/www/html

    # Verificar integridad de la copia de seguridad
    if [ -s "$backup_file" ] && tail -n 1 "$backup_file" | grep -q "Dump completed"; then
        log "Copia de seguridad creada y verificada: $backup_file"
    else
        log "ERROR: Falló la creación de la copia de seguridad"
        exit 1
    fi
}

## Ejecutar migración
execute_migration() {
    log "Ejecutando migración WordPress"

    # Actualizar URLs del sitio si es necesario
    if [ "$ENVIRONMENT" = "production" ]; then
        wp search-replace "staging.ejemplo.com" "ejemplo.com" --skip-columns=guid --path=/var/www/html
    fi

    # Limpiar todas las cachés
    wp cache flush --path=/var/www/html

    # Actualizar reglas de reescritura
    wp rewrite flush --path=/var/www/html

    log "Migración completada"
}

## Validación post-despliegue
post_deployment_validation() {
    log "Iniciando validación post-despliegue"

    # Verificar accesibilidad del sitio
    local site_url=$(wp option get siteurl --path=/var/www/html)

    if curl -f -s "$site_url" > /dev/null; then
        log "El sitio es accesible: $site_url"
    else
        log "ERROR: El sitio no es accesible"
        exit 1
    fi

    # Verificar admin de WordPress
    if curl -f -s "$site_url/wp-admin/" > /dev/null; then
        log "Admin de WordPress es accesible"
    else
        log "ERROR: Admin de WordPress no es accesible"
        exit 1
    fi

    # Verificar integridad de la base de datos
    if wp db check --path=/var/www/html; then
        log "Integridad de base de datos verificada"
    else
        log "ERROR: Falló la verificación de integridad de base de datos"
        exit 1
    fi

    # Verificar plugins críticos
    local critical_plugins=("all-in-one-wp-migration" "wp-super-cache")

    for plugin in "${critical_plugins[@]}"; do
        if wp plugin is-active "$plugin" --path=/var/www/html; then
            log "Plugin $plugin está activo"
        else
            log "ADVERTENCIA: Plugin $plugin no está activo"
        fi
    done

    log "Validación post-despliegue completada"
}

## Función principal de despliegue
main() {
    log "Iniciando despliegue WordPress para entorno $ENVIRONMENT"

    pre_deployment_checks
    create_deployment_backup
    execute_migration
    post_deployment_validation

    log "Despliegue completado exitosamente"

    # Enviar notificación (opcional)
    if command -v slack-cli &> /dev/null; then
        slack-cli send "Despliegue WordPress a $ENVIRONMENT completado exitosamente"
    fi
}

## Ejecutar función principal
main

#Conclusión

La migración de WordPress no tiene que ser abrumadora cuando se aborda de forma sistemática. Siguiendo esta guía completa, preparándote exhaustivamente y probando con diligencia, puedes migrar tu sitio WordPress con éxito y con una interrupción mínima para tus usuarios y el rendimiento SEO.

Recuerda que la preparación es clave: nunca intentes una migración sin copias de seguridad completas y un plan de rollback claro. Tómate tu tiempo, prueba exhaustivamente y no dudes en buscar ayuda profesional para migraciones complejas.

Con una planificación y ejecución adecuadas, tu migración de WordPress puede ser un proceso fluido que prepare tu sitio para el crecimiento y el éxito futuro.

En el lado de entrega mantenemos este tema bajo migración a Next.js o Astro.

Siguiente paso

Transforma el artículo en una implementación real

Este bloque refuerza el enlazado interno y lleva al lector al siguiente paso más útil dentro de la arquitectura del sitio.

¿Quieres implementar esto en tu sitio?

Si la visibilidad en Google y en sistemas de IA importa, puedo estructurar contenido, FAQ, schema y enlazado interno para SEO, GEO y AEO.

Escribe sobre la implementaciónVer el blog
Cluster relacionado

Explora otros servicios WordPress y base de conocimiento

Refuerza tu negocio con soporte técnico profesional en áreas clave del ecosistema WordPress.

Migración Next.js / Astro

Migración a Astro, Next.js y headless WordPress.

Ver servicio
Integraciones ERP

Sincronización WooCommerce con ERP y mayorista.

Ver servicio
Automatización de procesos de negocio

Automatización de procesos de negocio en torno a WordPress y sistemas empresariales.

Ver servicio
Biblioteca de automatización

Biblioteca de casos concretos de automatización.

Ver servicio
Desarrollador Astro

Astro, MDX, edge delivery y Core Web Vitals medidos con tráfico real.

Ver servicio
Desarrollador WordPress

Ingeniería WordPress y arquitectura personalizada.

Ver servicio
Soluciones Enterprise

Arquitectura headless, ERP e IA escalable para enterprise.

Ver servicio

Categorías relacionadas

headlesswordpresscommercecomparison

Artículos de apoyo

¿Cuánto tarda una migración a WordPress headless en 2026?
¿Cuánto tarda una migración a WordPress headless en 2026?

De seis a dieciséis semanas para proyectos típicos, en cuatro fases: descubrimiento, alcance, construcción y cutover, ajuste. Las variables son el tamaño del catálogo, el número de integraciones, la preservación de URLs y la disposición del equipo editorial, no la elección del framework.

WordPress headless vs monolítico: guía de coste total de propiedad (TCO) 2026
WordPress headless vs monolítico: guía de coste total de propiedad (TCO) 2026

Análisis exhaustivo del coste total de propiedad (TCO) a 4 años, métricas reales de Core Web Vitals, arquitectura Astro 7 GraphQL APQ y matriz de decisión de 10 puntos para directores de tecnología que eligen entre WordPress desacoplado y tradicional.

Shopify Plus vs WooCommerce headless en 2026: coste, control, IA
Shopify Plus vs WooCommerce headless en 2026: coste, control, IA

La decisión entre Shopify Plus y WooCommerce headless en 2026 ya no es un compromiso binario "plataforma vs personalizado". Ambos pueden funcionar en headless, ambos integran IA, ambos sirven en el edge. Los ejes reales son el control, el coste total a lo largo de cinco años y la estrategia de salida. Este artículo recorre la matriz con datos confirmados de cada plataforma.

FAQ del artículo

Preguntas frecuentes

Respuestas prácticas para aplicar el tema en la ejecución real.

SEO-readyGEO-readyAEO-ready5 Q&A

Preguntas frecuentes

¿Cuánto tiempo toma una migración de WordPress?¿Necesito habilidades técnicas para migrar WordPress?¿Se verá afectado mi SEO por la migración?¿Cuál es la diferencia entre migración manual y con plugin?¿Cómo migro una instalación WordPress multisitio?
¿Cuánto tiempo toma una migración de WordPress?#
El tiempo de migración varía según el tamaño del sitio: Sitios pequeños (1-5GB): 1-2 horas, Sitios mediaños (5-20GB): 2-4 horas, Sitios grandes (20GB+): 4+ horas.
¿Necesito habilidades técnicas para migrar WordPress?#
Las habilidades técnicas básicas son útiles, pero con la orientación y las herramientas adecuadas, incluso los principiantes pueden migrar sitios WordPress con éxito.
¿Se verá afectado mi SEO por la migración?#
Una migración ejecutada correctamente con redirecciones 301 preserva los rankings SEO. Siempre informa a Google sobre los cambios de dominio a través de Search Console.
¿Cuál es la diferencia entre migración manual y con plugin?#
La migración manual ofrece control total pero requiere conocimiento técnico. La migración con plugin es más fácil pero puede tener limitaciones para sitios complejos.
¿Cómo migro una instalación WordPress multisitio?#
La migración multisitio requiere un manejo especial de configuraciones de red, bases de datos compartidas y mapeo de dominios. Considera ayuda profesional para migraciones multisitio complejas.

¿Necesitas un FAQ adaptado a tu sector y mercado? Preparamos una versión alineada con tus objetivos de negocio.

Hablemos

Artículos Relacionados