Por qué Google revierte migraciones de dominio tras 4 meses y cómo salvar WooCommerce

Cambiar de nombre de dominio en una tienda online WooCommerce en producción representa una de las operaciones técnicas más complejas en el comercio electrónico. En octubre de 2026, los foros de debate de Google Search Central y varios análisis en Search Engine Roundtable documentaron un caso de gran impacto: cuatro meses después de haber implementado redirecciones HTTP 301 y de haber completado la herramienta de cambio de dirección en Google Search Console, el buscador comenzó de manera inesperada a devolver el tráfico orgánico y la indexación al dominio antiguo.

Muchos directores de tecnología y responsables de proyectos asumen equivocadamente que una migración concluye en el momento en que Search Console aprueba la notificación y las primeras páginas nuevas aparecen en los resultados. En la práctica, los algoritmos de Google evalúan las señales canónicas de forma ininterrumpida. Si las bases técnicas del nuevo dominio muestran debilidades, el motor de búsqueda revierte de oficio la elección canónica.

En este artículo analizamos la arquitectura de este problema, identificamos los errores más graves en bases de datos de WooCommerce y detallamos los protocolos de ingeniería para blindar una tienda online frente a pérdidas drásticas de facturación orgánica.

#Por qué Google vuelve al dominio antiguo meses después de la migración

La reversión de una migración de dominio no responde a un error arbitrario de los rastreadores, sino que constituye el resultado directo del sistema de canonicalización de Google (Canonicalization System). Google no interpreta una redirección 301 ni una notificación en Search Console como una cesión patrimonial definitiva de señales de posicionamiento. Las valora como recomendaciones intensas que deben ser confirmadas día a día mediante docenas de parámetros independientes.

Cuando Googlebot inspecciona el dominio antiguo y recibe una cabecera HTTP/1.1 301 Moved Permanently, transfiere autoridad hacia el nuevo destino. Sin embargo, al mismo tiempo evalúa la robustez del nuevo entorno. Si durante los meses posteriores se producen incidentes técnicos:

1. El nuevo dominio registra caídas intermitentes del servidor (códigos 500, 502, 504) ante la carga simultánea de rastreadores de IA y usuarios compradores.
2. Múltiples páginas del nuevo catálogo responden con el código 200 OK, pero muestran plantillas vacías o advertencias de PHP, lo que genera clasificaciones automáticas de soft 404.
3. Las etiquetas rel="canonical" del nuevo sitio continúan apuntando hacia el dominio antiguo por descuidos en la configuración de plugins de SEO o filtros manuales en el tema hijo.
4. El enlazado interno (menús principales, pies de página, fichas de producto, migas de pan) retiene URLs asociadas al dominio anterior.
5. El perfil de enlaces entrantes hacia el nuevo dominio no despega, mientras fallos en la caché perimetral del servidor antiguo empiezan a perder cabeceras 301.

En este escenario, el índice de confianza algorítmica sobre el nuevo dominio desciende con rapidez. Una vez superado el umbral de incertidumbre, Googlebot deduce que el cambio de dominio fue una maniobra fallida o provisional, procediendo a restaurar las URLs originales en el índice de búsqueda.

#Cómo evalúa Google las señales canónicas en un cambio de dominio

La canonicalización en los motores de búsqueda actuales opera como un motor de decisión multivariable. No se limita a examinar una etiqueta en el encabezado HTML, sino que contrapone las instrucciones declaradas frente a la conducta real de la infraestructura.

#Qué señales canónicas deciden la elección del dominio en el algoritmo

La siguiente tabla resume la jerarquía de señales que analiza Googlebot para dilucidar entre URLs redirigidas o duplicadas:

Cuando estas señales entran en colisión (por ejemplo, si una redirección 301 apunta al nuevo dominio, pero la etiqueta canónica en el HTML del nuevo dominio señala al antiguo), el algoritmo entra en conflicto. Con el paso de las semanas, el sistema favorece al dominio con mayor longevidad y mejor soporte de enlaces externos.

#Por qué las etiquetas rel canonical erróneas revierten la migración en Google

En instalaciones de WooCommerce, herramientas de SEO como Yoast SEO, Rank Math o The SEO Framework generan etiquetas canónicas basadas en las opciones registradas en WordPress. Si los desarrolladores duplican la base de datos pero conservan modificaciones obsoletas en el archivo de funciones:

// Filtro erróneo en el archivo functions.php del tema hijo
add_filter('wpseo_canonical', function($canonical) {
    return str_replace('nueva-tienda.es', 'antigua-tienda.es', $canonical);
});

Cada ficha de producto en el nuevo catálogo comunica a Googlebot una orden tajante: este documento es únicamente una copia secundaria, y el texto auténtico pertenece al dominio antiguo. Al comprobar miles de páginas con esta incoherencia, Googlebot acata la directiva y elimina el nuevo dominio de los resultados de búsqueda.

#Qué fallos en redirecciones 301 destruyen una tienda WooCommerce

Definir las rutas de reenvío exige una planificación mucho más estricta que incorporar reglas genéricas en un archivo .htaccess. En tiendas con catálogos extensos, los errores en la lógica de enrutamiento provocan averías de indexación difíciles de detectar.

#Por qué las cadenas de redirecciones y los límites de CDN provocan el retroceso

Las plataformas en el perímetro de red aplican restricciones técnicas que se deben tener presentes. Cloudflare Pages, por ejemplo, impone un límite estricto de 100 KB para el archivo de configuración _redirects (equivalente a unas 2000 a 2500 líneas de reglas estáticas). Si se despliega un archivo de 400 KB, el entorno no cancela el despliegue con un error visible, sino que corta silenciosamente las reglas que sobrepasan esa cuota.

De este modo, los primeros 2000 productos redirigen de manera adecuada con código 301, mientras que los 15 000 enlaces restantes de productos y categorías devuelven errores 404 o terminan en la página de inicio.

Otro problema habitual son las cadenas de redirección acumuladas:

URL Vieja -> URL Nueva (HTTP) -> URL Nueva (HTTPS sin www) -> URL Nueva (HTTPS con www y barra final)

Según la documentación de Google sobre errores HTTP, Googlebot sigue como máximo 10 saltos de redirección al rastrear contenido web, y la herramienta de inspección de URLs no sigue redirecciones en absoluto. La guía de traslado de sitios recomienda además evitar las cadenas y redirigir cada URL antigua directamente a su destino final. Cada salto intermedio es una petición HTTP adicional antes de llegar al contenido, multiplicada por cada URL del catálogo.

#Cómo redirigir la navegación facetada y los parámetros de filtrado limpiamente

Las tiendas de WooCommerce generan infinidad de variantes de URL mediante parámetros GET destinados a filtros:

• ?filter_color=negro
• ?filter_talla=xl&min_price=100
• ?marca=fabricante-a

Un error recurrente consiste en intentar mapear cada combinación de filtros de forma estática en tablas de reescritura. Esta práctica colapsa la memoria de los servidores web. La solución de ingeniería recomendada reside en aplicar reglas dinámicas en Nginx:

# Configuración de Nginx en el host antiguo: conservación de rutas y parámetros
server {
    listen 443 ssl http2;
    server_name antigua-tienda.es www.antigua-tienda.es;

    ssl_certificate /etc/ssl/certs/antigua-tienda.crt;
    ssl_certificate_key /etc/ssl/private/antigua-tienda.key;

    # Reenvío exacto 1:1 conservando la ruta y la cadena de parámetros
    location / {
        return 301 https://nueva-tienda.es$request_uri;
    }
}

Mediante la variable $request_uri, una solicitud dirigida a https://antigua-tienda.es/categoria/calzado/?filter_color=negro se traslada al instante a https://nueva-tienda.es/categoria/calzado/?filter_color=negro en un único salto de red, salvaguardando la relevancia de la búsqueda.

#Cómo migrar la base de datos de WooCommerce sin romper taxonomías

La base de datos de WordPress almacena información bajo esquemas específicos. Los ajustes de temas, composiciones de bloques Gutenberg y metadatos de artículos se guardan a menudo como objetos serializados en PHP.

#Por qué las consultas SQL directas destruyen datos serializados en PHP

Una cadena serializada en PHP incluye datos explícitos sobre la cantidad de caracteres que contiene. Véase un registro típico en la tabla wp_options:

s:22:"https://antigua-tienda.es";

El valor s:22 define que el texto posterior mide con exactitud 22 caracteres. Si se ejecuta una consulta básica en phpMyAdmin o MySQL:

-- CONSULTA PELIGROSA: CORROMPE ESTRUCTURAS SERIALIZADAS EN PHP
UPDATE wp_options 
SET option_value = REPLACE(option_value, 'antigua-tienda.es', 'nueva-tienda-online.es');

El nuevo dominio nueva-tienda-online.es contiene 22 caracteres, pero si variase aunque fuera en un solo carácter, el indicador de longitud quedaría desfasado. Al intentar leer el registro con la función unserialize(), el motor de PHP detecta una ruptura de formato y entrega valores nulos. Como consecuencia, desaparecen las credenciales de pasarelas de pago, se reinician las zonas de envío y se desestructura el diseño en el editor de bloques.

#Script WP-CLI completo para cambiar el dominio de forma segura en la base de datos

El método homologado para actualizar dominios en entornos WordPress es la utilidad de consola WP-CLI. Esta herramienta carga las cadenas serializadas en memoria, realiza la sustitución de términos, recalcula las longitudes de texto y serializa los datos con corrección antes de escribir en MySQL.

El siguiente script en Bash automatiza el proceso completo, incluyendo copia de seguridad y purga de caché:

#!/usr/bin/env bash
# Migración segura de dominio para WooCommerce con WP-CLI
set -euo pipefail

OLD_DOMAIN="antigua-tienda.es"
NEW_DOMAIN="nueva-tienda.es"
WP_PATH="/var/www/nueva-tienda/public"

echo "=== Iniciando procedimiento de migración de base de datos ==="

# 1. Copia de seguridad preventiva de la base de datos
wp db export "${WP_PATH}/backup-pre-migration-$(date +%F).sql" --path="${WP_PATH}"

# 2. Ejecución de prueba para comprobar coincidencias (Dry Run)
echo "Comprobando sustituciones con Dry Run..."
wp search-replace "https://${OLD_DOMAIN}" "https://${NEW_DOMAIN}" \
    --all-tables \
    --dry-run \
    --path="${WP_PATH}"

# 3. Sustitución efectiva de direcciones completas en HTTPS
echo "Aplicando sustitución real para direcciones HTTPS..."
wp search-replace "https://${OLD_DOMAIN}" "https://${NEW_DOMAIN}" \
    --all-tables \
    --precise \
    --recurse-objects \
    --path="${WP_PATH}"

# 4. Sustitución de dominio simple omitiendo la columna GUID
wp search-replace "${OLD_DOMAIN}" "${NEW_DOMAIN}" \
    --all-tables \
    --precise \
    --skip-columns=guid \
    --path="${WP_PATH}"

# 5. Regeneración de enlaces permanentes de WooCommerce
echo "Regenerando reglas de reescritura..."
wp rewrite flush --hard --path="${WP_PATH}"

# 6. Limpieza de memoria intermedia (Redis / Memcached)
wp cache flush --path="${WP_PATH}"

echo "=== Migración de base de datos finalizada con éxito ==="

El parámetro --skip-columns=guid resulta indispensable. De acuerdo con las normas de desarrollo del núcleo de WordPress, la columna guid en la tabla wp_posts actúa como un identificador único global para lectores de noticias y jamás debe alterarse durante un cambio de dominio.

#Cuánto tiempo debes mantener el sitemap XML y el servidor antiguo activos

Uno de los errores de gestión más dañinos consiste en apagar el servidor antiguo o dejar expirar el registro del dominio cuando transcurren solo seis meses desde la migración.

La documentación oficial de Google Search Central estipula que la infraestructura de redirecciones debe seguir operativa durante un mínimo de 12 meses. En el ámbito del comercio electrónico, lo más prudente es mantener el dominio y las redirecciones de forma permanente. Un dominio que queda libre puede ser adquirido por granjas de enlaces automatizadas, perjudicando la reputación que costó años consolidar.

Asimismo, en el dominio anterior debe permanecer accesible un mapa del sitio XML específico que detalle todas las URLs históricas:

<?xml version="1.0" encoding="UTF-8"?>
<!-- Mapa XML en antigua-tienda.es con la relación de URLs redirigidas -->
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://antigua-tienda.es/producto/ordenador-portatil/</loc>
    <lastmod>2026-10-14</lastmod>
  </url>
  <url>
    <loc>https://antigua-tienda.es/categoria/electronica/</loc>
    <lastmod>2026-10-14</lastmod>
  </url>
</urlset>

Este archivo se envía a la consola de Google Search Console en la propiedad del dominio antiguo. Proporciona a Googlebot una lista organizada de recursos que debe rastrear de manera periódica para certificar que la respuesta 301 Moved Permanently es estable y permanente.

#Cómo analizar los registros del servidor y detectar la reversión en Search Console

Detectar cualquier anomalía a tiempo evita caídas críticas en la facturación de la tienda online. Cuando una migración comienza a fallar, las señales de advertencia se aprecian en los registros de acceso del servidor semanas antes de que se reflejen en las posiciones orgánicas.

#Qué anomalías vigilar en el informe de indexación de Search Console

En el panel de Google Search Console, controle estos tres indicadores principales:

1. Informe de indexación de páginas en el nuevo dominio: Un incremento repentino de estados como Rastreada: actualmente sin indexar o Duplicada: el usuario no ha indicado ninguna versión canónica. Esto denota que Googlebot tiene dudas a la hora de integrar las nuevas URLs en el índice principal.
2. Informe de rendimiento del dominio anterior: Si el volumen de impresiones en el dominio antiguo empieza a repuntar tras meses sin actividad, significa que Google vuelve a mostrar las URLs antiguas a los usuarios en los resultados.
3. Herramienta de inspección de URLs: Audite fichas de producto clave. Si el campo Canónica seleccionada por Google indica el dominio antiguo mientras que Canónica declarada por el usuario señala el nuevo, el sitio web padece un conflicto canónico activo.

#Cómo monitorizar códigos de estado HTTP en Cloudflare Logpush y Nginx

Examinar los registros de peticiones aporta datos en tiempo real sobre la actividad del buscador. Con este comando en terminal puede filtrar las consultas de Googlebot en el servidor antiguo:

# Filtrar registros de acceso de Nginx por códigos de respuesta para Googlebot
awk -F'"' '$6 ~ /Googlebot/ { print $1, $2, $3 }' /var/log/nginx/antigua-tienda.access.log \
  | awk '{ print $1, $6, $7 }' \
  | sort | uniq -c | sort -nr | head -n 30

En condiciones óptimas, todos los registros deben mostrar el código de estado 301. Cualquier registro con códigos 200, 302, 404 o 502 para peticiones dirigidas al dominio viejo indica problemas de configuración que requieren solución inmediata.

#Qué hacer con los enlaces internos en bloques Gutenberg y campos ACF

Un detonante muy extendido en la anulación de procesos de migración en WordPress procede de enlaces internos que pasan desapercibidos. A pesar de aplicar wp search-replace, pueden quedar referencias antiguas en formatos singulares como textos codificados en Base64, estructuras JSON en wp_termmeta o plantillas estáticas de diseño.

Conviene revisar los siguientes puntos críticos:

• Menús de navegación de WordPress: En la sección Apariencia -> Menús, asegúrese de que los elementos configurados como Enlaces personalizados no contengan URLs estáticas hacia antigua-tienda.es.
• Plantillas de bloques (Full Site Editing): Archivos HTML en los directorios /templates y /parts que puedan incorporar enlaces fijos hacia la política de privacidad, avisos legales o formularios de contacto.
• Campos flexibles de ACF: Las páginas principales suelen registrar relaciones mediante identificadores de publicación, pero en módulos de texto WYSIWYG se conservan a menudo enlaces pegados manualmente.
• Módulos de pasarela de pago: Verifique que las extensiones de pago y transporte no mantengan URLs de retorno antiguas en sus pantallas de administración.

Para rastrear el código HTML procesado de la nueva tienda en busca de vínculos residuales, recurra a un crawler de consola:

# Rastrear la nueva tienda online en busca de enlaces hacia el dominio anterior
wget --spider --recursive --no-verbose --output-file=wget-scan.log https://nueva-tienda.es || true
grep "antigua-tienda.es" wget-scan.log || echo "No se detectaron enlaces directos al dominio antiguo."

#Cómo recuperar el sitio web en 7 pasos si Google revierte la migración

Si su tienda online ha sufrido una reversión de migración y el buscador vuelve a mostrar las páginas antiguas en los resultados, ejecute este plan de contingencia:

+-------------------------------------------------------------------+
|               PROTOCOLO DE RECUPERACIÓN TRAS REVERSIÓN            |
+-------------------------------------------------------------------+
                                  |
                                  v
         [ PASO 1: Auditar cabeceras HTTP y eliminar bucles 301 ]
                 (Comprobar que cada URL vieja entrega 301 directo)
                                  |
                                  v
        [ PASO 2: Verificar etiquetas rel canonical en nuevo host ]
               (Ninguna página puede remitir al dominio antiguo)
                                  |
                                  v
       [ PASO 3: Subsanar errores soft 404 en el catálogo ]
               (Productos agotados deben responder con código 200)
                                  |
                                  v
      [ PASO 4: Limpiar de nuevo enlaces internos en la base ]
               (Revisar menús, campos ACF, widgets y pie de página)
                                  |
                                  v
         [ PASO 5: Renovar y enviar mapas del sitio XML ]
               (Enviar sitemaps en ambas cuentas de Search Console)
                                  |
                                  v
       [ PASO 6: Reanudar cambio de dirección en Search Console ]
               (Reenviar solicitud tras solventar fallos técnicos)
                                  |
                                  v
      [ PASO 7: Potenciar señales externas hacia el nuevo dominio ]
               (Actualizar Google Business Profile y redes sociales)

1. Auditoría de cabeceras HTTP: Utilice cURL para comprobar que cada ruta del dominio antiguo deriva de forma directa con código 301 hacia su URL equivalente en el nuevo sitio, eliminando saltos intermedios.
2. Corrección de etiquetas canónicas: Examine el código fuente en el nuevo dominio. La etiqueta rel="canonical" debe ser idéntica a la URL activa, contemplando el protocolo HTTPS y las directivas de barra final.
3. Eliminación de estados soft 404: Revise el listado de incidencias de contenido en Search Console. En WooCommerce, los productos sin existencias deben responder con código 200 OK, indicación de disponibilidad y recomendaciones de artículos similares, en lugar de plantillas de error vacías.
4. Saneamiento de la base de datos: Ejecute wp search-replace con las opciones --precise y --all-tables, verificando que no persista ninguna mención al dominio anterior en opciones o contenidos.
5. Administración de sitemaps dobles: Cerciórese de que el sitemap de la nueva tienda contiene únicamente URLs canónicas con código 200 OK, y mantenga en el dominio antiguo un sitemap con los enlaces redirigidos.
6. Renovación del cambio de dirección: Si han transcurrido más de 180 días desde la primera solicitud, vuelva a presentar el cambio de dirección en Search Console una vez que todos los fallos técnicos hayan sido corregidos.
7. Refuerzo de enlaces externos: Actualice las direcciones de su empresa en Google Business Profile, plataformas de cobro, perfiles de redes sociales y portales sectoriales para enviar señales externas inequívocas a los motores de búsqueda.

#Conclusión técnica para arquitectos de software y responsables de tiendas online

La revocación de una migración de dominio por parte de Google representa un aviso inequívoco: los algoritmos del buscador han descubierto contradicciones sustanciales entre la intención declarada del cambio y el comportamiento real de la infraestructura tecnológica.

En plataformas de comercio electrónico modernas, culminar con éxito un cambio de dominio se apoya en el rigor operativo:

• Las redirecciones deben funcionar en un solo salto y conservar íntegros los parámetros de filtrado.
• Las bases de datos de WordPress y WooCommerce deben actualizarse mediante WP-CLI para preservar objetos serializados de PHP.
• Las etiquetas canónicas y los enlaces internos deben orientarse exclusivamente al nuevo dominio desde el primer instante del cambio de DNS.
• El dominio anterior, su certificado de seguridad SSL y su correspondiente mapa del sitio XML deben mantenerse activos durante al menos 12 meses.

Antes de ejecutar el cambio definitivo de servidores, consulte nuestra evaluación de migración WordPress para detectar incidencias de redirección y discrepancias en base de datos.

Aplicando con constancia estas pautas de ingeniería, erradicará el riesgo de reversión en la indexación y asegurará la estabilidad comercial de su tienda online a largo plazo.