Migración de dominio WordPress sin perder SEO: 301, canónicos, sitemaps y cero drama

Lo que realmente estás cambiando (y por qué el SEO se enfada)

Una migración de dominio no es «actualizar DNS y hacer clic en Guardar». Es un intercambio de identidad coordinado para cada URL que tu sitio haya publicado alguna vez. Los motores de búsqueda no posicionan tu instalación de WordPress. Posicionan tus URLs y sus señales: enlaces, contenido, rendimiento, datos estructurados y la promesa implícita de que esta URL sirve consistentemente esto.

Cuando cambias dominios, le pides a Google y compañía que transfieran la confianza de las URLs antiguas a las nuevas. Esa transferencia ocurre mediante una cadena de evidencias:

• Redirecciones HTTP (típicamente 301) que mapean las URLs antiguas a sus equivalentes nuevas.
• Etiquetas canónicas que dicen «la URL preferida de esta página está aquí».
• Sitemaps que listan las URLs nuevas y ayudan al descubrimiento.
• Enlaces internos actualizados para dejar de sabotearse a sí mismos con referencias al dominio antiguo.
• Comportamiento de respuesta consistente (códigos de estado, caché, contenido) que no parezca un engaño.

Haz bien eso y el cambio será en su mayoría un bamboleo temporal. Hazlo mal y crearás contenido duplicado, trampas de rastreo, bucles de redirección y confusión de indexación de larga duración—generalmente mientras tu equipo de marketing actualiza paneles como si fuera un monitor cardíaco.

Hechos y contexto que explican las partes extrañas

Un poco de historia y mecánica concretas. No son trivia; explican por qué ciertos «atajos ingeniosos» son una mala decisión profesional.

1. 301 vs 302 solía interpretarse más literalmente que hoy. Durante años, un 302 podía frenar la transferencia de señal; los motores modernos son más inteligentes, pero 301 sigue siendo la opción por defecto para movimientos permanentes.
2. Google introdujo rel=canonical en 2009. Se diseñó para reducir la indexación duplicada cuando el mismo contenido existe en varias URLs—justo lo que creas durante una migración.
3. Los sitemaps XML se hicieron comunes a mediados de los 2000. No «mejoran el ranking», pero reducen el tiempo de descubrimiento y te ayudan a ver errores de cobertura más rápido.
4. WordPress ha soportado siempre “Dirección del sitio (URL)” vs “Dirección de WordPress (URL)”. Malinterpretar esa división causa la mitad de las caídas autoinfligidas en los cambios de dominio.
5. Los navegadores empezaron a aplicar reglas más estrictas de contenido mixto durante los 2010s. Un dominio nuevo en HTTPS con recursos incrustados en HTTP puede romper la renderización y el seguimiento en silencio.
6. HTTP/2 (estandarizado en 2015) cambió el modelo de coste de rendimiento. Las cadenas de redirección siguen siendo costosas, pero menos que en la era de «una conexión por recurso»—aún no son gratis.
7. Los CDN popularizaron el caché agresivo de redirecciones. Un 301 erróneo puede quedar cacheado en el edge y sobrevivir a tu corrección rápida, lo cual es emocionante de manera parecida a un pager.
8. Los motores de búsqueda tratan las cadenas largas de redirección como un problema de calidad y eficiencia. Pueden dejar de seguirlas después de demasiados saltos, y el presupuesto de rastreo es finito.

Una idea para tener siempre en mente, porque se aplica directamente aquí: la esperanza no es una estrategia; mide, automatiza y verifica. — Gene Kim (idea parafraseada)

No negociables: lo que debe ser verdadero cuando haces el corte

Antes de tocar TTL de DNS o ajustes de WordPress, asegúrate de estas invariantes. No son «agradables de tener». Son la frontera entre «bajón temporal» y «por qué nos desindexaron».

1) Cada URL antigua devuelve un 301 de un solo salto a su equivalente nuevo

No «la página de inicio para todo», no un 302 «por ahora», no una cadena como antiguo → http nuevo → https nuevo → www nuevo. Un solo salto. Manténlo soso.

2) Las páginas nuevas se canonizan a sí mismas al nuevo dominio

Cuando un rastreador llega al dominio nuevo, el canónico debe apuntar al dominio nuevo. Si los canónicos siguen referenciando el dominio antiguo, estás diciendo a Google que prefiera las URLs antiguas… mientras rediriges esas URLs. Eso es conflicto, y los conflictos no posicionan.

3) Los enlaces internos dejan de apuntar al dominio antiguo

Las redirecciones son para externos. Tu propio sitio no debería necesitarlas. Los enlaces internos al dominio antiguo inflan el desperdicio de rastreo y ocultan problemas de contenido.

4) Sitemaps y robots.txt reflejan la nueva verdad

Publica sitemaps que listan solo las URLs del nuevo dominio. robots.txt no debe deshabilitar rutas importantes porque alguien copió una regla de staging.

5) El tracking y las integraciones críticas sobreviven

Analytics, callbacks de pago, URIs de redirección OAuth, webhooks, cabeceras CSP, plantillas de email y píxeles de marketing son sensibles al dominio. Haz una lista desde el principio.

Broma #1: Una migración de dominio sin un mapa de redirecciones es como cambiar la dirección de tu oficina y luego sorprenderte cuando tu correo va a «Residente desconocido».

Guía de diagnóstico rápido (revisa esto en orden)

Cuando el tráfico o la indexación se ven mal, no hagas gestos inútiles. Ejecuta un triaje corto y reproducible que encuentre el cuello de botella rápido.

Primero: ¿las redirecciones son correctas y de un solo salto?

• Elige 20 URLs de alto tráfico desde analytics y prueba códigos de estado, cabeceras Location y recuento de saltos.
• Confirma que HTTP→HTTPS y la decisión non-www→www no crean saltos extra.
• Confirma que el dominio antiguo no sirve otra cosa que redirecciones (excepto quizás desafíos ACME).

Segundo: ¿los canónicos son coherentes?

• En el dominio nuevo, ver el código fuente y confirmar que el canónico apunta al dominio nuevo.
• Revisa que archivos paginados, páginas de categoría y productos usen reglas canónicas consistentes.
• Confirma que ningún plugin esté reescribiendo canónicos al host antiguo.

Tercero: ¿los rastreadores pueden descubrir y recuperar las URLs nuevas eficientemente?

• Verifica que los sitemaps carguen, no estén bloqueados y listan el host correcto.
• Revisa robots.txt: sin disallow accidental, directiva sitemap apunta al dominio nuevo.
• Confirma que las respuestas del servidor sean estables: sin picos 5xx, sin bloqueos WAF para Googlebot.

Cuarto: ¿estás duplicando el sitio en múltiples hosts por accidente?

• Asegura que solo un host «preferido» sea indexable (www vs apex). Otros hosts deben 301.
• Asegura que el dominio antiguo no esté sirviendo páginas 200 OK mediante un bypass (IP de origen, vhost olvidado).

Quinto: ¿las cachés te están mintiendo?

• Purga cachés CDN para redirecciones y HTML.
• Revisa si un «301 malo» fue cacheado con TTL largos.
• Confirma que la caché de páginas de WordPress no esté sirviendo canónicos antiguos.

Listas de verificación / plan paso a paso (pre-vuelo a post-vuelo)

Fase 0: Decide qué significa “misma URL”

Si solo cambias el dominio (oldsite.com → newsite.com) pero mantienes las rutas idénticas, la vida es más fácil. Si además cambias la estructura de permalinks, fusionas categorías o «limpias contenido», detente. Sepáralo en dos proyectos. La migración de dominio ya es un riesgo suficiente.

Fase 1: Inventario y mapeo

• Exporta una lista de URLs indexadas (Search Console), páginas de entrada principales (analytics) y URLs de sitemap (antiguo).
• Crea un mapa de redirecciones: URL antigua → URL nueva, incluyendo casos borde (barra final, mayúsculas, assets legados).
• Decide host preferido: dominio apex vs www. Elige uno y cúmplelo.

Fase 2: Construye el sitio nuevo en paralelo

• Levanta el dominio nuevo en staging con HTTPS.
• Configura Home/Site URLs de WordPress al dominio nuevo de forma controlada.
• Actualiza enlaces internos, URLs de medios si es necesario, y el comportamiento canónico.
• Genera nuevos sitemaps y verifica que listan solo URLs del nuevo host.

Fase 3: Verificación previa al corte

• Ejecuta un crawl del dominio staging/nuevo y revisa canónico, código de estado y distribución de host en enlaces internos.
• Prueba reglas de redirección contra una lista de muestra de URLs antiguas antes de que el mundo las vea.
• Fija el TTL de DNS bajo con antelación (no cinco minutos antes del corte).

Fase 4: Corte

• Activa redirecciones en el dominio antiguo (preferible a nivel de servidor).
• Cambia DNS o el enrutamiento del balanceador para el dominio nuevo.
• Verifica certificados (tanto antiguos como nuevos si el antiguo sirve redirecciones HTTPS).
• Observa logs y tasas de error como si te importara.

Fase 5: Limpieza post-corte (primeras 72 horas)

• Envía nuevos sitemaps, solicita indexación de páginas clave.
• Monitorea 404s y bucles de redirección; corrige brechas del mapeo.
• Actualiza integraciones de terceros y dominios permitidos.
• Mantén las redirecciones del dominio antiguo activas a largo plazo (piensa en un año+; más tiempo está bien).

Tareas prácticas con comandos, salidas y decisiones (12+)

Estos son chequeos de nivel producción. Cada uno tiene: comando → salida típica → qué significa → qué decides después. Ejecútalos desde un shell con acceso de red a tu sitio y, cuando haga falta, a tus servidores.

Task 1: Verify a single URL does a clean one-hop 301

cr0x@server:~$ curl -I https://old.example.com/products/widget
HTTP/2 301
date: Sat, 27 Dec 2025 10:11:02 GMT
location: https://new.example.com/products/widget
cache-control: max-age=3600

Significado de la salida: HTTP 301 es correcto; Location apunta a la URL nueva exacta; no se muestra aquí un salto intermedio.

Decisión: Si Location apunta a la página de inicio o a una ruta incorrecta, tu mapa de redirecciones es incompleto o demasiado genérico. Corrige las reglas antes del corte o antes de que el daño de indexación se propague.

Task 2: Measure redirect hop count (chains kill efficiency)

cr0x@server:~$ curl -s -o /dev/null -w "%{url_effective} %{num_redirects} %{http_code}\n" -L https://old.example.com/products/widget
https://new.example.com/products/widget 1 200

Significado de la salida: Una redirección y luego 200 en la URL final.

Decisión: Si num_redirects > 1, reduce saltos colapsando reglas (p. ej., combinar http→https y normalización de host en una sola redirección cuando sea posible).

Task 3: Confirm the old domain never serves 200 content

cr0x@server:~$ curl -I https://old.example.com/
HTTP/2 301
location: https://new.example.com/

Significado de la salida: El dominio antiguo es estrictamente un redireccionador.

Decisión: Si ves HTTP 200 con HTML, estás ejecutando dos copias indexables. Eso es contenido duplicado y confusión canónica. Haz que el dominio antiguo sea solo redirecciones.

Task 4: Spot-check canonical tags on the new domain

cr0x@server:~$ curl -s https://new.example.com/products/widget | grep -i -m1 canonical

Significado de la salida: El canónico apunta al host nuevo y a la ruta correcta.

Decisión: Si apunta a old.example.com, estás diciendo a los rastreadores que prefieran el dominio antiguo. Corrige ajustes de WordPress, configuración del plugin SEO y cualquier comportamiento hardcodeado del tema.

Task 5: Detect mixed content (common after HTTPS migration)

cr0x@server:~$ curl -s https://new.example.com/ | grep -Eo 'src="http://[^"]+' | head
src="http://old.example.com/wp-content/uploads/2023/hero.jpg

Significado de la salida: El HTML incluye URLs de assets en HTTP (y en el dominio antiguo).

Decisión: Reemplaza en la base de datos y/o aplica reescritura de contenido. El contenido mixto puede romper la renderización de la página y degradar en silencio las señales SEO.

Task 6: Confirm sitemap lists the new host

cr0x@server:~$ curl -s https://new.example.com/sitemap_index.xml | head -n 12



https://new.example.com/post-sitemap.xml

Significado de la salida: El índice de sitemap existe y referencia sitemaps del dominio nuevo.

Decisión: Si las entradas loc apuntan al dominio antiguo o a http, corrige la configuración del generador de sitemaps y purga caches.

Task 7: Validate robots.txt isn’t blocking the new site

cr0x@server:~$ curl -s https://new.example.com/robots.txt
User-agent: *
Disallow:
Sitemap: https://new.example.com/sitemap_index.xml

Significado de la salida: Sin disallow global; sitemap apunta correctamente.

Decisión: Si ves Disallow: / o reglas de staging, corrige inmediatamente. Un único robots.txt malo puede hacer que tus hermosas redirecciones sean irrelevantes.

Task 8: Ensure WordPress Home/Site URLs are correct via WP-CLI

cr0x@server:~$ wp option get home
https://new.example.com
cr0x@server:~$ wp option get siteurl
https://new.example.com

Significado de la salida: WordPress cree que vive en el dominio nuevo para ambos valores.

Decisión: Si estos son del dominio antiguo (o hay un desajuste), arréglalo con WP-CLI y vacía caches. Un desajuste entre home/siteurl crea bucles de redirección y sesiones de admin rotas.

Task 9: Search for old-domain strings in the database (dry run)

cr0x@server:~$ wp search-replace 'old.example.com' 'new.example.com' --dry-run --all-tables
+-----------------------+--------------+--------------+
| Table                 | Column       | Replacements |
+-----------------------+--------------+--------------+
| wp_posts              | post_content | 812          |
| wp_postmeta           | meta_value   | 144          |
| wp_options            | option_value | 19           |
+-----------------------+--------------+--------------+
Success: 975 replacements to be made.

Significado de la salida: Referencias al dominio antiguo están incrustadas en contenido/meta/options.

Decisión: Planifica la ejecución real en una ventana de mantenimiento, con backup primero. Si los reemplazos son masivos, considera si tienes datos serializados y confía en el manejo seguro de WP-CLI (gestiona serialización).

Task 10: Execute the replacement (after backup)

cr0x@server:~$ wp search-replace 'old.example.com' 'new.example.com' --all-tables --precise
Success: Made 975 replacements.

Significado de la salida: Referencias en la base de datos actualizadas.

Decisión: Purga inmediatamente la caché de páginas y el object cache. Luego vuelve a comprobar canónicos y hosts en enlaces internos con un crawl rápido o muestreo con grep.

Task 11: Find top 404s in NGINX access logs after cutover

cr0x@server:~$ sudo awk '$9==404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head
48 /wp-content/uploads/2019/legacy-logo.png
31 /category/old-campaign/
19 /products/widget-pro/

Significado de la salida: Estas rutas se solicitan y devuelven 404.

Decisión: Añade redirecciones dirigidas o restaura assets faltantes. Para páginas de contenido, mapea a los mejores equivalentes. Para assets, o sírvelos o redirígelos a su nueva localización; evita redirigir cada archivo faltante a la página de inicio.

Task 12: Confirm TLS cert coverage for both domains

cr0x@server:~$ echo | openssl s_client -servername old.example.com -connect old.example.com:443 2>/dev/null | openssl x509 -noout -subject -issuer -dates
subject=CN = old.example.com
issuer=CN = R3, O = Let's Encrypt
notBefore=Dec 10 00:00:00 2025 GMT
notAfter=Mar  9 23:59:59 2026 GMT

Significado de la salida: El dominio antiguo tiene un certificado válido, lo cual importa si redirige sobre HTTPS.

Decisión: Si el certificado del dominio antiguo es inválido/expirado, navegadores y rastreadores pueden no seguir redirecciones con fiabilidad. Renuévalo y automatiza la renovación; no dejes que el dominio antiguo se pudra.

Task 13: Validate host normalization (www vs apex) behaves as planned

cr0x@server:~$ curl -I https://new.example.com/ | sed -n '1,5p'
HTTP/2 301
location: https://www.new.example.com/

Significado de la salida: new.example.com redirige al host canónico elegido (www en este ejemplo).

Decisión: Asegura que cada host no preferido haga 301 al preferido. Luego garantiza que WordPress esté configurado para generar el host preferido en enlaces y canónicos.

Task 14: Identify redirect loops quickly

cr0x@server:~$ curl -I -L --max-redirs 5 https://old.example.com/wp-admin/ 2>&1 | tail -n 6
curl: (47) Maximum (5) redirects followed

Significado de la salida: Existe un bucle—a menudo causado por redirecciones en conflicto entre WordPress, el servidor web y un CDN.

Decisión: Inspecciona dónde la redirección cambia host/proto/path. Luego elige una capa para encargarse de la normalización (prefiere el edge/servidor web), y configura WordPress para que coincida.

Estrategia de redirecciones: 301s que no se derriten

Las redirecciones son la columna vertebral de la migración. Si están mal, todo lo demás se convierte en una curita sobre un fémur roto.

Principios que resisten bajo carga

• Usa redirecciones a nivel de servidor, no un plugin de WordPress. Quieres que las redirecciones funcionen incluso si PHP está caído, y que sean rápidas.
• Prefiere mapeos exactos para páginas principales. Para la larga cola, una regla general está bien (misma ruta en el dominio nuevo), pero no adivines en páginas de alto valor.
• Evita cadenas de redirección. Un salto es la meta. Dos son tolerables en emergencias. Tres es cómo terminas depurando «por qué Google no lo ve» durante meses.
• No redirijas todo a la página de inicio. Eso es un patrón soft-404 y descarta señales de relevancia.
• Mantén las redirecciones activas por mucho tiempo. Enlaces externos y marcadores antiguos no caducan porque tu roadmap lo diga.

Ejemplo Nginx: de dominio antiguo a nuevo, preservando URI

cr0x@server:~$ sudo nginx -T | sed -n '1,40p'
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
# ...snip...
server {
    listen 443 ssl http2;
    server_name old.example.com;

    return 301 https://www.new.example.com$request_uri;
}

Significado de la salida: La prueba de configuración de Nginx fue exitosa; el bloque de servidor devuelve un solo 301 preservando path y query string.

Decisión: Si también necesitas normalización de host en el dominio nuevo, hazlo con cuidado para que old→new siga siendo un salto. A menudo eso significa redirigir old directamente al host preferido nuevo.

Ejemplo Apache: antiguo a nuevo en un vhost o .htaccess

Apache funciona bien; solo evita apilar reglas de forma que se creen bucles o saltos extra. Si puedes colocar redirecciones en la configuración del vhost en lugar de .htaccess, hazlo por rendimiento y claridad.

Query strings: consérvalas a menos que tengas razón para no hacerlo

Parámetros de campaña y seguimiento deberían trasladarse. Eliminarlos puede simplificar logs, pero te dejará ciego durante las semanas en que más necesitas atribución.

Broma #2: Un 301 cacheado en el edge del CDN es como purpurina: una vez que está mal, está mal en todas partes y para siempre.

Canónicos: el asesino silencioso de tus rankings

Si las redirecciones son la columna vertebral, los canónicos son el sistema nervioso. No siempre aparecen en «chequeos básicos», pero controlan qué URL recibe el crédito.

Cómo deberían lucir las etiquetas canónicas durante y después de la migración

• En el dominio nuevo: el canónico apunta a la URL nueva (el canónico autorreferencial es normal).
• En el dominio antiguo: idealmente no sirves páginas 200, solo redirecciones. Si debes servir contenido temporal, los canónicos deberían aun así apuntar al dominio nuevo—con cuidado y consistencia.
• Elige una variante de host: www o apex. El canónico debe coincidir exactamente.
• HTTPS en todas partes: el canónico debe ser https si ese es tu esquema canónico.

Dónde fallan los canónicos en WordPress

• Configuración del plugin SEO fijada al URL del sitio antiguo. Algunos plugins almacenan URLs absolutas en ajustes o caches.
• Canónico hardcodeado en plantillas del tema. Alguien «optimizó SEO» en 2018 y dejó una mina.
• Caché de página sirviendo HTML antiguo. Arreglaste la base de datos, pero la caché sigue enviando canónicos viejos.
• Quirks de multisite y domain mapping. La generación de canónicos puede depender de IDs de sitio y tablas de mapeo; un «simple search-replace» puede ser insuficiente.

Canónico vs redirección: ¿cuál gana?

En la práctica, los motores resuelven señales usando múltiples indicios. Si tu redirección dice «ve aquí» pero tu canónico dice «prefiere el antiguo», has creado una discusión. A los rastreadores les gustan las instrucciones claras. No son fanáticos de las discusiones familiares.

Sitemaps: haz el trabajo de Google aburrido

Los sitemaps no son polvo mágico que mejora ranking. Son herramientas operativas para la indexación. En una migración, eso es exactamente lo que necesitas: descubrimiento más rápido, informes más claros y menos «incógnitas desconocidas».

Reglas para sitemaps tras un cambio de dominio

• Genera sitemaps que listan solo URLs del dominio nuevo.
• Expón el índice de sitemap en una ubicación estable (el default común está bien).
• Asegura que los sitemaps devuelvan 200 OK, no estén detrás de autenticación ni bloqueados por desafíos WAF.
• Mantén accesibles los sitemaps antiguos si se solicitan, pero deberían 301 a las ubicaciones nuevas de sitemap o reemplazarse con referencias al dominio nuevo.

Sitemaps de imágenes y vídeo

Si tu negocio depende de búsqueda de imágenes o resultados enriquecidos, no olvides las entradas de sitemap de imágenes. Una migración puede «funcionar» para HTML mientras la detección de medios cae en silencio porque las URLs de imágenes siguen en el host antiguo o están bloqueadas por reglas de hotlink.

Search Console y analytics: demuestra que funcionó

Aquí es donde transformas «creo que está bien» en evidencia. Necesitas dos tipos de prueba: corrección visible para rastreadores y comportamiento visible para usuarios.

Esenciales de Search Console

• Añade y verifica la propiedad del dominio nuevo (a nivel de dominio si es posible).
• Envía los sitemaps nuevos.
• Usa la herramienta de cambio de dirección si aplica a tu configuración (cuando te mudas entre dominios bajo la misma propiedad verificada).
• Monitorea reportes de cobertura: picos en «Excluded», «Crawled – currently not indexed», o «Duplicate, Google chose different canonical» son señales accionables.

Esenciales de analytics

• Actualiza ajustes de URL por defecto donde haga falta (depende del stack de analytics).
• Verifica exclusiones de referencia y tracking cross-domain, especialmente si tienes flujos de checkout.
• Anota el tiempo de migración y las correcciones mayores (cambios en reglas de redirección, reenvío de sitemaps).

La verificación basada en logs vence a las sensaciones del dashboard

Los dashboards te dicen resultados. Los logs te dicen causas. Durante la primera semana quieres ambos, pero los logs son donde verás patrones de bots, bucles de redirección y grupos de 404 antes de que un reporte los agregue en una vaga «caída».

Cachés/CDN y efectos secundarios de rendimiento

Las migraciones de dominio a menudo incluyen un cambio de CDN, cambios en terminación TLS, o «ya que estamos, añadimos WAF». Está bien. También es la forma en que accidentalmente introduces bloqueos a rastreadores y bugs de caché.

Caché de redirecciones: útil hasta que no lo es

Un 301 es cacheable por navegadores e intermediarios. Eso es una ventaja. También por eso debes probar reglas de redirección antes de ponerlas en vivo. Si publicas un 301 erróneo con cache-control generoso, has distribuido tu error a cada ubicación edge y agente de usuario que lo tocó.

Caché de página y object cache

Después de cambiar dominios, debes purgar:

• Caché de página completa (plugin, reverse proxy, CDN).
• Object cache (Redis/Memcached) porque opciones y fragmentos renderizados pueden estar cacheados.
• Caché de opcode si desplegaste nueva configuración que afecta la generación de URLs (menos común, pero no lo supongas).

Reglas WAF y comportamiento de bots

Los WAFs disfrutan los falsos positivos durante las migraciones porque cambian los patrones de tráfico: más fetches de bots, más probes de 404, más ráfagas. Asegúrate de que tu WAF permita a los rastreadores legítimos y no les sirva desafíos JavaScript.

Almacenamiento, copias y rollback: trata el contenido como datos

Las migraciones de WordPress son migraciones de datos. El dominio es solo la pieza más visible.

Haz backup de la base de datos y uploads como si quisieras conservar tu trabajo

Necesitas una instantánea puntual de:

• La base de datos (consistente en transacciones si es posible).
• wp-content/uploads (y cualquier directorio de contenido personalizado).
• Configuración: wp-config.php, vhosts del servidor web, reglas de CDN, registros DNS.

Plan de rollback: simple, probado y no teórico

Un rollback para una migración de dominio suele ser reversión de DNS + enrutamiento más desactivar reglas de redirección. Pero solo funciona si:

• El sitio antiguo puede servir el contenido original correctamente.
• No mutaste la base de datos de forma que rompa el dominio antiguo (p. ej., reemplazo irreversible sin snapshot).
• Puedes emitir certificados válidos rápidamente para ambos dominios.

Caso límite de almacenamiento: protección hotlink y assets legados

Muchos sitios tienen protección hotlink basada en referrer o host. Cuando cambias dominios, esa protección puede bloquear tus propias páginas de cargar imágenes si las reglas no se actualizaron. Si tus assets están en object storage detrás de un CDN, valida cabeceras Host y comportamientos de URLs firmadas.

Tres microhistorias corporativas desde las trincheras de migración

Microhistoria 1: El incidente causado por una suposición errónea

La empresa estaba en medio de un rebranding. Dominio nuevo, logo nuevo, mismo WordPress. Alguien dijo, con confianza, «Simplemente pondremos el dominio nuevo en WordPress y manejará las redirecciones». Sonaba plausible. WordPress redirige algunos flujos de admin e intenta ser útil. Útil no es lo mismo que correcto.

La noche del corte fue tranquila hasta que llegó la mañana y el tráfico. Las campañas pagadas aterrizaron en el dominio antiguo y fueron redirigidas… a veces. Otras veces, los visitantes obtuvieron un 200 OK en la página de inicio antigua porque un vhost de Apache olvidado aún servía contenido en el host antiguo cuando la petición llegó sin SNI durante una mala configuración TLS. Mientras tanto, las páginas de producto en el dominio nuevo tenían canónicos apuntando al dominio antiguo porque el plugin SEO había cacheado los URLs del sitio.

El resultado fue una tormenta perfecta de «dos sitios, un conjunto de contenido». Los rastreadores vieron duplicados. Los usuarios vieron comportamiento inconsistente. Los equipos internos discutieron porque cada persona probó una URL distinta y obtuvo una realidad distinta.

La solución fue aburrida: forzar que el dominio antiguo redirigiera en el edge para todas las peticiones, renovar correctamente el certificado antiguo, purgar caches y regenerar canónicos. Luego pasaron dos semanas limpiando la larga cola de redirecciones faltantes descubiertas en logs.

La lección: no supongas que la capa de la aplicación posee la migración. Haz que el servidor web o el CDN sean la fuente de verdad para old→new, y que la aplicación genere canónicos consistentes para el host nuevo.

Microhistoria 2: La optimización que salió mal

Otra organización quería que la migración fuera «rápida para los rastreadores». Su plan fue mantener el sitio antiguo sirviendo 200 OK durante un mes mientras añadían rel=canonical apuntando al dominio nuevo, con la teoría de preservar la experiencia de usuario y «transicionar a Google gradualmente». También usaron redirecciones 302 para algunas rutas «por si necesitamos volver atrás».

Sonaba cauteloso. No lo fue. Crearon tres señales en conflicto: contenido 200 OK en URLs antiguas, a veces 302s, y canónicos apuntando a otra parte. Los rastreadores respondieron dudando: indexaron ambas versiones, escogieron sus propios canónicos y demoraron la consolidación porque nada parecía autoritativo.

Luego el CDN «amablemente» cacheó un subconjunto de los 302s con TTL largos. Algunos clientes vieron el dominio antiguo por semanas; otros cambiaron inmediatamente. Los tickets de soporte se pusieron raros porque los usuarios estaban literalmente en universos distintos según el estado del caché.

Después de perseguir fantasmas, cambiaron a 301s consistentes para todas las URLs antiguas, hicieron que el dominio antiguo fuera solo redirecciones y eliminaron la complejidad de la «transición suave». La indexación se estabilizó. Los rankings se recuperaron.

La lección: las migraciones no son lugar para ambigüedad de señales. Si la mudanza es permanente, usa 301s, no buenas intenciones.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Otro equipo hizo una migración de dominio tan anodina que nadie fuera de ingeniería lo notó. Que nadie lo notara es el mejor cumplido que puedes recibir.

Comenzaron con un mapa de redirecciones construido desde tres fuentes: sitemaps existentes, páginas de entrada principales y logs del servidor de los últimos 30 días. Categorizaron URLs en: «deben mapearse exactamente», «pueden mapearse por regla» y «retiradas intencionalmente». Las páginas retiradas obtuvieron redirecciones pensadas a equivalentes cercanos—no a la página de inicio—a menos que realmente no tuvieran reemplazo, en cuyo caso devolvían un 410.

Probaron redirecciones en un entorno staging reproduciendo una lista de URLs antiguas y verificando códigos de estado y cabeceras Location automáticamente. También comprobaron canónicos y hostnames de sitemap con un pequeño script y no hicieron el corte hasta que el recuento de errores fue cero.

En el corte, habían reducido TTLs de DNS días antes, los certificados ya estaban emitidos y las cachés configuradas con TTLs sensatos para redirecciones. La «sala de guerra» post-corte fue mayormente ver gráficos permanecer aburridos y responder a una pequeña lista de 404s de assets legados oscuros.

La lección: las prácticas de ingeniería aburridas—inventario, automatización y verificación—no son burocracia. Son cómo evitar reuniones de emergencia con demasiadas personas.

Errores comunes: síntomas → causa raíz → solución

1) Rankings caen fuerte y se mantienen bajos tras dos semanas

Síntomas: Páginas nuevas indexadas lentamente; páginas antiguas persisten; aumenta «Duplicate, Google chose different canonical».

Causa raíz: Señales en conflicto: redirecciones inconsistentes, canónicos siguen apuntando al dominio antiguo, o múltiples variantes de host devuelven 200.

Solución: Haz que el dominio antiguo sea solo redirecciones. Asegura un único host preferido en el dominio nuevo. Audita canónicos en todo el sitio y purga caches. Colapsa cadenas de redirección a un solo salto.

2) Todo redirige a la página de inicio

Síntomas: Usuarios se quejan «los enlaces no van al producto correcto»; Search Console muestra soft 404s; desaparece el tráfico de larga cola.

Causa raíz: Regla de redirección demasiado amplia sin preservación de path o tabla de mapeo faltante.

Solución: Implementa redirección que preserve path. Añade redirecciones explícitas para secciones movidas/renombradas. Usa logs para priorizar 404s de alto volumen y arregla iterativamente.

3) Bucles infinitos de redirección

Síntomas: El navegador muestra «demasiadas redirecciones»; curl alcanza max-redirs; el login admin falla.

Causa raíz: Normalización en conflicto entre CDN, servidor web y WordPress home/siteurl; mezcla de enforcement HTTP/HTTPS.

Solución: Elige una capa para imponer esquema y host (preferible edge/servidor web). Configura home y siteurl de WordPress al canónico final. Asegura X-Forwarded-Proto correcto detrás de un proxy.

4) El sitio nuevo carga pero las imágenes/CSS están rotos

Síntomas: Falta estilo, imágenes rotas, errores en consola; métricas SEO degradan.

Causa raíz: Contenido mixto (assets http), URLs de assets hardcodeadas al dominio antiguo, o protección hotlink ligada al dominio antiguo.

Solución: Reemplazo en BD de host antiguo; actualiza reglas CDN/hotlink; asegura URLs de assets en HTTPS. Purga caches.

5) Search Console muestra “Submitted URL blocked by robots.txt”

Síntomas: Sitemap enviado pero URLs excluidas; rastreo estancado.

Causa raíz: robots.txt de staging desplegado en prod o plugin en modo «desalentar indexación».

Solución: Corrige robots.txt y la opción de WordPress «Disuadir a los motores de búsqueda». Solicita re-rastreo y reenvía sitemaps.

6) Las redirecciones funcionan para humanos pero los rastreadores son bloqueados

Síntomas: En logs, Googlebot recibe 403/429; la indexación ralentiza; tableros WAF muestran bloqueos.

Causa raíz: Protección WAF/bot no ajustada al comportamiento de rastreadores; límites de tasa demasiado estrictos; páginas de desafío servidas.

Solución: Allowlist IPs verificadas de rastreadores cuando sea apropiado (con cuidado), reduce falsos positivos y asegúrate de que los bots puedan recuperar sitemaps y HTML sin desafíos JS.

7) El dominio antiguo sigue posicionando en lugar del nuevo

Síntomas: SERPs muestran URLs antiguas; las nuevas aparecen de forma esporádica; los backlinks parecen «no transferirse».

Causa raíz: URLs antiguas devuelven 200 o tienen canónicos a sí mismas; redirecciones son 302 o inconsistentes.

Solución: Convierte a 301s consistentes. Elimina respuestas 200 del dominio antiguo. Asegura que las URLs nuevas se canonizan a sí mismas. Mantén redirecciones estables a largo plazo.

FAQ

1) ¿Cuánto tiempo debo mantener las redirecciones del dominio antiguo?

Al menos 12 meses. Más tiempo es más seguro. Enlaces externos, marcadores y rastreadores lentos seguirán golpeando URLs antiguas durante años.

2) ¿Debería usar un plugin para redirecciones en WordPress?

No para una migración a nivel de dominio. Haz redirecciones en el servidor web o CDN. Usa redirecciones a nivel de WordPress solo para un número pequeño de correcciones editoriales donde necesites la conveniencia de la UI.

3) ¿Tengo que cambiar la estructura de permalinks durante la migración de dominio?

No. Separa proyectos. Si cambias dominio y rutas a la vez, depurar se convierte en arqueología.

4) ¿Cuál es la mejor redirección: 301 o 308?

Ambas son permanentes. 308 preserva el método estrictamente; 301 es universalmente entendida y convencional para contenido web. Usa 301 a menos que tengas una razón fuerte para lo contrario.

5) ¿Tengo que actualizar enlaces internos si las redirecciones funcionan?

Sí. Los enlaces internos que apuntan al dominio antiguo desperdician presupuesto de rastreo y ocultan problemas. Actualízalos para que el sitio navegue directamente a las URLs canónicas.

6) ¿Qué hay de www vs non-www?

Elige un host preferido y aplícalo en todas partes: redirecciones, canónicos, sitemaps y ajustes de WordPress. La inconsistencia aquí crea URLs duplicadas que compiten entre sí.

7) ¿Habrá una caída de tráfico tenga lo que tenga?

Normalmente hay una oscilación a corto plazo. El objetivo es minimizar duración y magnitud proporcionando señales consistentes y evitando ineficiencias de rastreo (cadenas, duplicados, recursos bloqueados).

8) ¿Puedo eliminar el contenido del sitio antiguo inmediatamente después del movimiento?

Eliminar contenido, sí. Eliminar la infraestructura del dominio antiguo que sirve redirecciones, no. Mantén el dominio antiguo sirviendo redirecciones rápidas y fiables sobre HTTPS con certificados válidos.

9) ¿Cómo manejo páginas retiradas sin reemplazo?

Si no hay un equivalente significativo, devolver 410 puede ser apropiado. Si existe una alternativa cercana, redirígela allí. Evita redirigir todo a la página de inicio; parece un patrón de soft 404.

10) ¿Necesito re-enviar archivos de desautorización (disavow) o algo así?

Eso es específico por caso y poco común hoy en día. Enfócate primero en redirecciones, canónicos y corrección de sitemaps—esos son los mecanismos que mueven resultados con fiabilidad.

Pasos prácticos siguientes

Si quieres una migración de dominio que no se convierta en una reunión recurrente, haz tres cosas ahora:

1. Construye un mapa de redirecciones a partir de datos reales (sitemaps, analytics, logs) y pruébalo con curl antes del corte.
2. Audita canónicos y enlaces internos en el dominio nuevo, luego purga cada capa de caché que pueda servir HTML antiguo.
3. Operacionaliza la verificación: vigila logs por grupos de 404, confirma redirecciones de un solo salto y mantiene TLS y redirecciones del dominio antiguo saludables a largo plazo.

El SEO durante una migración trata sobre todo de reducir la ambigüedad. Dale a los rastreadores una historia clara, sírvela de forma consistente y no te «optimices» hasta quedarte sin salida.