Migración de hosting y SEO

TL;DR — Una migración de hosting traslada la maquinaria que hay detrás de su sitio web mientras los visitantes siguen usando las mismas URL. Primero construya y pruebe el nuevo host, reduzca el tiempo de vida (TTL) del DNS antes del lanzamiento, mantenga el host antiguo en funcionamiento durante el cambio y compare lo que devuelven ambos sistemas. Vigile el DNS, los certificados, los códigos de estado, el contenido, la velocidad y el acceso de los rastreadores. Apague el host antiguo solo después de que sus registros muestren que el tráfico ha llegado a cero.

¿Qué es una migración de hosting?

Una migración de hosting cambia dónde o cómo se sirve un sitio web sin cambiar las URL que ven las personas. Cambiar de empresa de hosting es un ejemplo. Añadir o sustituir una red de distribución de contenidos (CDN), cambiar un servidor de origen o cambiar de proveedor de DNS pueden formar parte del mismo proyecto.

Que la URL siga siendo la misma es la condición que lo define. https://example.com/page/ debe seguir siendo https://example.com/page/ antes y después del traslado.

Google lo considera un traslado de sitio sin cambios de URL. Si cambian el dominio, el protocolo, el nombre de host o la ruta, utilice en su lugar el proceso completo de migración web. Puede que esté haciendo dos migraciones a la vez.

¿Por qué un traslado con las mismas URL puede afectar al SEO?

Una migración de hosting puede cambiar todo lo que hay detrás de una dirección estable. Los motores de búsqueda pueden encontrarse con un código de respuesta distinto, un servidor más lento, un certificado caducado, un desafío del firewall, una página en caché obsoleta, una imagen rota, una cabecera ausente o una página renderizada distinta.

El traslado más seguro conserva la respuesta observable mientras sustituye la infraestructura. Los usuarios y los rastreadores deberían obtener del nuevo sistema la misma página correcta que recibían del antiguo.

¿Cuáles son los pasos básicos?

1. Copie o conecte el sitio a la nueva infraestructura.
2. Pruebe el nuevo origen y la CDN sin cambiar el DNS público.
3. Reduzca con antelación el TTL del DNS para que el cambio final se propague más rápido.
4. Confirme los certificados, el almacenamiento en caché, las reglas de seguridad y el acceso de los rastreadores.
5. Cambie el DNS para enviar el tráfico a la nueva infraestructura.
6. Mantenga ambos entornos en línea mientras caducan las cachés de DNS.
7. Monitorice los registros, los errores, la velocidad, el rastreo y el rendimiento en búsqueda.
8. Apague el host antiguo solo cuando sus registros no muestren tráfico restante.

Google recomienda esta misma secuencia de preparar, cambiar, monitorizar y apagar en su documentación sobre el cambio de hosting.

¿Qué hace el TTL del DNS?

El TTL del DNS controla cuánto tiempo puede un resolutor almacenar en caché una respuesta DNS. Un TTL más bajo antes del traslado permite que los registros modificados caduquen antes en las cachés. No hace que todos los resolutores cambien al instante, y bajarlo en el momento del lanzamiento llega tarde para las cachés que ya conservan el valor antiguo.

Google sugiere reducir el TTL a un valor bajo y conservador, como unas pocas horas, al menos una semana antes del traslado. Tómelo como un ejemplo, no como una cifra universal; su proveedor de DNS y sus requisitos operativos determinan el valor exacto.

¿Se necesitan redirecciones?

Una verdadera migración de hosting no necesita redirecciones de SEO porque las URL públicas no cambian. Añadir redirecciones generalizadas durante un traslado que solo afecta al host crea nuevos modos de fallo sin resolver el problema de infraestructura.

Las redirecciones existentes deben seguir comportándose exactamente igual que antes. Pruébelas en la nueva pila, incluidas las reglas heredadas antiguas que puedan residir en el servidor web actual, el CMS, el balanceador de carga o la CDN.

¿Cuándo está completo el traslado?

El traslado de hosting está completo cuando la nueva infraestructura sirve de forma consistente las respuestas previstas y la infraestructura antigua ya no recibe tráfico real de usuarios ni de rastreadores. Google recomienda explícitamente revisar los registros del proveedor antiguo y apagarlo solo después de que el tráfico llegue a cero.

TL;DR — Trate una migración de hosting, CDN o DNS con las mismas URL como un proyecto de paridad de respuesta y enrutamiento de tráfico. Inventaríe cada nombre de host y cada dependencia, reduzca el TTL del DNS antes del lanzamiento, configure el nuevo origen y el borde, valide los certificados y los controles de seguridad, someta a pruebas de carga una demanda realista de rastreadores y usuarios, y compare las respuestas en bruto y las renderizadas. Ejecute en paralelo la infraestructura antigua y la nueva durante la propagación del DNS. Monitorice ambos flujos de registros, las respuestas DNS, los errores, la latencia, el comportamiento de la caché, la actividad de rastreo y Search Console. Revierta restaurando el enrutamiento anterior solo cuando se produzca un fallo de infraestructura acordado de antemano.

Decida si realmente se trata de una migración con las mismas URL

Una migración de hosting con las mismas URL cambia la infraestructura sin cambiar la cadena exacta de la URL pública. El esquema, el nombre de host, el puerto, la ruta, el tratamiento de la cadena de consulta y el comportamiento de la barra final se mantienen estables.

Clasifique el proyecto antes de planificarlo:

No permita que un gestor de proyecto etiquete un cambio de URL como “solo hosting”. El plan de despliegue debe incluir todos los tipos de migración que realmente se lancen.

Elabore el inventario de infraestructura

El inventario de infraestructura evita que las dependencias silenciosas se conviertan en sorpresas el día del lanzamiento. Registre:

• todos los nombres de host públicos, incluidos los de recursos estáticos, imágenes, API, hosts internacionales y alias heredados;
• los registros A, AAAA, CNAME, NS, SOA, CAA, MX, TXT y los registros SRV relevantes;
• emisores de certificados, métodos de validación, Subject Alternative Names y caducidad;
• direcciones de origen, puertos, comprobaciones de estado, balanceadores de carga y comportamiento de conmutación por error;
• claves de caché de la CDN, reglas de caché, redirecciones, transformaciones, workers y métodos de purga;
• reglas de WAF, de bots, de límite de tasa, geográficas, de autenticación y de permitir/denegar IP;
• cabeceras de respuesta, compresión, comportamiento de las cookies y cabeceras de seguridad;
• destinos de los registros, retención, muestreo, campos y zonas horarias;
• métodos de verificación de Search Console y de analítica;
• callbacks de terceros, webhooks, flujos de pago, feeds e IP en listas de permitidos.

La revisión del DNS debe incluir los registros no web. Romper los registros MX, SPF, DKIM, DMARC o de servicio puede no cambiar directamente los rankings, pero sí puede romper el negocio que intentaba proteger.

Establezca una línea base de paridad de respuesta

La paridad de respuesta significa comparar el sistema antiguo y el nuevo para la misma URL solicitada, no solo comprobar que ambos devuelven 200.

Capture un conjunto representativo que abarque plantillas y comportamientos:

• el estado y la cadena de redirecciones;
• la URL final y la negociación de protocolo;
• el título, el canonical, las directivas de robots, el hreflang y los datos estructurados;
• el HTML en bruto y el contenido principal renderizado por el navegador;
• Content-Type, Cache-Control, Vary, la compresión y las cabeceras de seguridad;
• imágenes, fuentes, JavaScript, CSS, PDF y recursos multimedia;
• cookies y variantes con sesión iniciada o personalizadas;
• el comportamiento en móvil y en escritorio;
• la latencia, el tiempo hasta el primer byte y la tasa de errores.

Utilice Staging vs. Production SEO Diff para comprobaciones de páginas emparejadas. Un rastreador completo y un conjunto de peticiones automatizadas deberían cubrir el inventario más amplio.

Prepare el nuevo origen

La preparación del origen empieza por la paridad de contenido y de configuración. Copie el contenido actual, las plantillas, los archivos multimedia, las reglas de robots, las redirecciones, la gestión de errores y los archivos de verificación. Congele o sincronice las escrituras para que la nueva base de datos no se lance desactualizada.

Pruebe el origen directamente mediante un nombre de host controlado, una sobrescritura local del archivo hosts o un mecanismo de vista previa propio del proveedor. La prueba debe conservar la cabecera Host de producción, porque los hosts virtuales, el enrutamiento de la aplicación, los certificados, los canonicals y los enlaces absolutos suelen depender de ella.

El nuevo origen también debe soportar la carga posterior al cambio. Precaliente la aplicación y la base de datos, confirme los grupos de conexiones y el autoescalado, y someta a pruebas de carga la demanda sin caché. Los fallos de caché de la CDN pueden concentrar el tráfico en el origen inmediatamente después del lanzamiento.

Configure la CDN como un sistema aparte

Una migración de CDN cambia más que la geografía. Compare de forma explícita el comportamiento del borde antiguo y del nuevo:

• la composición de la clave de caché, incluidas las cadenas de consulta, las cookies, las cabeceras y las variantes por dispositivo;
• los códigos de estado y los tipos de archivo cacheables;
• el TTL de navegador, el TTL de borde, el servicio de contenido obsoleto, la revalidación y el blindaje del origen;
• redirecciones, reescrituras, transformaciones de cabeceras y funciones de borde;
• reglas de omisión de caché para cuentas, carritos, búsqueda y páginas personalizadas;
• compresión y optimización de imágenes;
• alcance y propagación de la purga;
• WAF, gestión de bots, limitación de tasa y protección del origen.

La documentación actual de Cloudflare, por ejemplo, señala que su almacenamiento en caché predeterminado puede respetar las cabeceras Cache-Control del origen, pero que las reglas de borde pueden anularlo. También ofrece purgas selectivas o completas para forzar nuevas peticiones al origen. El comportamiento exacto depende del proveedor, así que exporte y compare la configuración en lugar de suponer que etiquetas equivalentes implican resultados equivalentes. Consulte la documentación de caché de Cloudflare.

Trate la paridad de caché como paridad de contenido

La configuración de la caché puede servir la página equivocada de forma correcta y rápida. Pruebe las variantes anónimas, autenticadas, localizadas, móviles y con cadena de consulta. Una clave de caché que omita una cookie o una cabecera significativa puede filtrar contenido personalizado. Una clave de caché que incluya todos los parámetros de seguimiento puede fragmentar la caché y sobrecargar el origen.

Purgue o precaliente los recursos y las páginas críticos según el plan de lanzamiento. No purgue todo a ciegas durante los picos de tráfico salvo que el origen se haya probado frente a la tormenta de fallos de caché resultante.

Valide el TLS del usuario al borde y del borde al origen

La validación de TLS tiene dos tramos cuando una CDN termina HTTPS: del navegador a la CDN y de la CDN al origen. Confirme la cobertura de nombres de host, las cadenas de certificados completas, la compatibilidad con protocolos modernos, la renovación y la validación estricta del origen.

Los certificados exclusivos de origen pueden no ser de confianza pública. Cloudflare advierte de que sus certificados Origin CA pueden generar errores de confianza en el navegador si el proxy está desactivado o en pausa. Eso importa durante una reversión: un repliegue en modo DNS-only hacia un origen que usa un modelo de confianza exclusivo del borde puede fallar para los usuarios. Consulte la guía de Cloudflare sobre Origin CA.

Pruebe todos los nombres de host públicos, incluidas las suposiciones sobre comodines y los hosts de recursos o regionales poco utilizados. Un certificado válido para el dominio raíz no demuestra que todos los subdominios estén cubiertos.

Reduzca el TTL del DNS antes del traslado

La planificación del TTL empieza antes del cambio. Google recomienda reducir el TTL correspondiente a un valor bajo y conservador, como unas pocas horas, al menos una semana antes del traslado. Un proveedor de DNS puede imponer mínimos distintos; los registros proxificados también pueden tener valores fijos.

La documentación sobre TTL de Cloudflare explica el compromiso básico: los valores más largos aumentan la reutilización de la caché, mientras que los más cortos permiten que los cambios de registro surtan efecto antes. Anote el TTL original y programe su restauración solo después de que la nueva infraestructura sea estable.

Los cambios de DNS pueden no ser atómicos entre sistemas distribuidos. Cambie lo menos posible durante el cambio, verifique las respuestas desde varios resolutores públicos y mantenga disponible el destino antiguo mientras sigan siendo válidas las respuestas en caché.

Verifique el acceso de los rastreadores y los controles de seguridad

La paridad de seguridad no es paridad en el número de reglas. Un WAF copiado de otro proveedor puede desafiar o bloquear a los rastreadores, eliminar parámetros de consulta, reescribir respuestas o limitar la tasa del rastreo de alto volumen de forma distinta.

La guía de hosting de Google indica que hay que asegurarse de que los firewalls y la protección frente a denegación de servicio no impidan a Googlebot llegar a los servidores de DNS o de hosting. Verifique a Googlebot con los métodos de verificación documentados de Google, no solo con una cadena de agente de usuario.

Pruebe tanto el comportamiento habitual de los rastreadores como los picos legítimos. Evite listas de permitidos amplias que desactiven la protección frente a agentes de usuario suplantados. Conserve los registros de seguridad para poder distinguir las peticiones bloqueadas de los fallos del origen.

Planifique la ejecución en paralelo

La ejecución en paralelo significa que tanto la infraestructura antigua como la nueva pueden servir respuestas de producción correctas durante la propagación. El entorno antiguo debe seguir recibiendo los cambios de contenido o de datos que afectan al sitio. De lo contrario, los usuarios dirigidos por respuestas DNS en caché pueden ver inventarios obsoletos, sesiones rotas o páginas desactualizadas.

Elija una estrategia de sincronización:

• una única base de datos de lectura/escritura compartida por ambas pilas;
• datos replicados con un retardo conocido y una política de conflictos;
• una congelación controlada del contenido durante el cambio;
• replicación unidireccional de eventos para pedidos, formularios o escrituras de usuarios.

El estado de sesión, las subidas de archivos, las invalidaciones de caché y las tareas en segundo plano requieren la misma decisión. “Ambos servidores están encendidos” no es un plan de ejecución en paralelo si sus estados divergen.

Ejecute el cambio

El cambio de hosting debe ser deliberadamente aburrido:

1. Detenga los despliegues no relacionados y confirme la ventana de cambio.
2. Ejecute las comprobaciones finales de paridad, certificados, capacidad y copias de seguridad.
3. Elimine los bloqueos temporales de rastreo o de acceso de la nueva ruta de producción.
4. Cambie únicamente los registros de enrutamiento de DNS o de CDN previstos.
5. Confirme las respuestas esperadas desde múltiples resolutores.
6. Solicite las páginas protegidas por la ruta pública como usuario y como rastreador.
7. Confirme que llegan registros del borde, del nuevo origen y del origen antiguo.
8. Vigile los errores, la latencia, los fallos de caché, la carga del origen y las conversiones.

No utilice la herramienta Change of Address de Google para un traslado que solo afecta al host. Ninguna URL pública ha cambiado, por lo que no hay ningún cambio de dirección que notificar.

Monitorice la evidencia que demuestra el traslado

La monitorización de la infraestructura debe separar el tráfico antiguo del nuevo. Utilice un marcador de despliegue y compare con la línea base del mismo momento de la semana cuando la estacionalidad sea relevante.

Vigile:

• las respuestas DNS y la propagación entre resolutores;
• las peticiones al host antiguo y al nuevo por usuario y por rastreador verificado;
• la distribución de códigos de estado en el borde y en el origen;
• los errores de TLS, de conexión, de tiempo de espera y de aplicación;
• los percentiles de latencia y el tiempo de respuesta del origen sin caché;
• la tasa de aciertos de caché y el volumen de peticiones al origen;
• las peticiones de Googlebot, Crawl Stats, Page Indexing y una URL Inspection representativa;
• comprobaciones sintéticas en distintas regiones y redes;
• analítica, conversiones y transacciones críticas de negocio.

Google señala que una caída temporal de la frecuencia de rastreo de Googlebot inmediatamente después de un cambio de hosting puede ser normal, seguida de un aumento en los días siguientes. Base cualquier decisión en la evidencia de accesibilidad y de errores, no solo en ese patrón esperado.

Defina la reversión antes del lanzamiento

La reversión devuelve el enrutamiento a un estado de infraestructura conocido y correcto. No es una promesa vaga de “volver a cambiar el DNS”. Documente:

• los registros, rutas y configuraciones exactos que se deben restaurar;
• quién puede autorizar y ejecutar la reversión;
• cómo se reconciliarán el contenido modificado, las sesiones, los formularios, los pedidos y las subidas de archivos;
• si los certificados y las dependencias antiguos siguen siendo válidos;
• los pasos de purga de caché en ambas rutas;
• los umbrales de fallo que activan la reversión;
• el tiempo máximo seguro para decidir.

Los desencadenantes de la reversión deben ser observables: fallos sostenidos de disponibilidad, ruptura material de las conversiones, contenido incorrecto generalizado, fallos de certificados, bloqueos de rastreadores o un colapso de capacidad que no pueda corregirse dentro de la ventana. Una fluctuación temporal de la frecuencia de rastreo por sí sola no es un desencadenante de reversión.

Retire la infraestructura antigua según los registros, no según el calendario

La retirada del host antiguo se produce después de que los registros muestren que los usuarios y los rastreadores ya no llegan a él y de que todos los servicios dependientes se hayan trasladado. Google recomienda apagar el host antiguo después de que su tráfico llegue a cero.

Conserve las exportaciones de configuración, los registros y los artefactos de reversión según los requisitos del negocio. Restaure el TTL del DNS al valor de régimen estable previsto una vez demostrada la estabilidad. Elimine las excepciones temporales del firewall y las tareas programadas duplicadas para que la migración no deje un desorden de mantenimiento permanente.

Resumen de IA

• Una migración de hosting cambia los servidores, la CDN, el origen o el DNS mientras las URL públicas permanecen idénticas.
• Los cambios de URL requieren el proceso más amplio de traslado de sitio. Un traslado que solo afecta al host no necesita un nuevo mapa de redirecciones ni un envío mediante Change of Address.
• Inventaríe el DNS, el TLS, el origen, la CDN, el WAF, la caché, los registros, la verificación, los recursos y las dependencias de negocio antes del lanzamiento.
• Reduzca el TTL del DNS antes del cambio, conserve el valor antiguo y restáurelo una vez que la nueva ruta sea estable.
• Compare las respuestas en bruto antiguas y nuevas, las páginas renderizadas, las cabeceras, los recursos, las redirecciones, los códigos de estado, la latencia y el comportamiento de negocio.
• Valide el TLS del navegador al borde y del borde al origen, además de los certificados de cualquier ruta de reversión.
• Ejecute ambos entornos en paralelo y sincronice las escrituras hasta que las respuestas DNS en caché dejen de enviar tráfico a la pila antigua.
• Monitorice ambos flujos de registros, las respuestas DNS, los errores, la carga del origen, el comportamiento de la caché, el acceso de rastreadores verificados, Search Console y las conversiones.
• Retire el host antiguo solo cuando sus registros muestren que el tráfico ha llegado a cero.

Documentación oficial

Google

• Cambiar el alojamiento web y el SEO explica el proceso de preparar, cambiar el DNS, monitorizar y apagar cuando las URL no cambian.
• Migraciones de sitio con cambios de URL se aplica cuando también cambian el esquema, el nombre de host o la ruta.
• Verificar Googlebot documenta la verificación mediante DNS inverso/directo y mediante las IP publicadas.
• Crawl Stats report ayuda a monitorizar las peticiones de Googlebot y la disponibilidad del host.

Referencias de infraestructura

• Cloudflare DNS TTL explica los compromisos entre TTL y propagación.
• Cloudflare cache documenta el almacenamiento en caché en el borde, las reglas de caché y la purga.
• Cloudflare Origin CA documenta los certificados del borde al origen y la limitación de confianza del navegador.

Citas de la fuente

• “This guide is only for migrations that don’t affect the user-visible URL.” (traducción) «Esta guía solo sirve para migraciones que no afectan a la URL visible para el usuario.» Google Search Central. Ir a la guía de hosting
• Paráfrasis: Google recomienda reducir el TTL del DNS antes del traslado, asegurarse de que los firewalls sigan admitiendo el tráfico verificado de Googlebot, contar con una caída temporal de la frecuencia de rastreo y mantener disponible el host antiguo hasta que su tráfico haya terminado. Orientación sobre el TTL, orientación sobre el firewall, orientación sobre la frecuencia de rastreo y orientación sobre el apagado.

Lista de comprobación para la migración de hosting

Alcance y línea base

• Confirmado que ninguna URL pública cambiará.
• Inventariados todos los nombres de host web, de recursos, de API y regionales.
• Exportadas las configuraciones de DNS, CDN, WAF, caché, redirecciones, TLS y origen.
• Guardadas líneas base representativas de respuestas en bruto y renderizadas.
• Registradas líneas base de tráfico, errores, latencia, rastreo, indexación y conversiones.

Nueva infraestructura

• Sincronizados el contenido actual, los archivos multimedia, las redirecciones, las reglas de robots y los archivos de verificación.
• Probados el enrutamiento por cabecera Host y todos los nombres de host públicos.
• Validados los certificados del navegador al borde y del borde al origen.
• Igualados las claves de caché, las omisiones, los TTL, las cookies, las transformaciones y el comportamiento de purga.
• Igualado el comportamiento de WAF, de bots, de límite de tasa y de acceso al origen.
• Sometidos a pruebas de carga los fallos de caché, las dependencias de la aplicación y la capacidad de la base de datos.
• Confirmado que los registros de borde, origen, aplicación y seguridad se conservan y se pueden consultar.

DNS y lanzamiento

• Reducidos los TTL relevantes antes del traslado y registrados los valores originales.
• Conservados los registros no web, DNSSEC, la verificación y las dependencias de servicio.
• Documentados el cambio exacto de enrutamiento y los comandos de reversión.
• Mantenidas activas la infraestructura antigua y la nueva con un plan de sincronización de datos.
• Eliminados todos los bloqueos temporales de rastreo o de acceso en la ruta de producción.
• Verificadas las respuestas DNS a través de múltiples resolutores independientes.

Después del lanzamiento

• Comparados el estado, el contenido, las cabeceras, el renderizado, los recursos y las redirecciones en producción.
• Confirmado que los usuarios y los rastreadores verificados no reciben desafíos ni bloqueos.
• Vigilados los registros antiguos/nuevos, los errores, la latencia, los fallos de caché, la carga del origen y las conversiones.
• Revisados Crawl Stats, Page Indexing y resultados representativos de URL Inspection.
• Restaurado el TTL de régimen estable solo tras demostrar la estabilidad.
• Retirado el host antiguo solo después de que su tráfico llegara a cero.

El marco de paridad de cinco capas

El modelo de estados de la migración

Preparado significa que la nueva pila supera las pruebas de paridad y de carga. En cambio significa que las respuestas DNS y las peticiones están repartidas. Estabilizando significa que la nueva pila sirve casi todo el tráfico mientras la antigua sigue disponible. Completo significa que el tráfico del host antiguo llega a cero y que todas las dependencias se han retirado o transferido.

No dé el proyecto por completo en el punto de “DNS cambiado”. Ese es el comienzo del cambio, no el final de la migración.

¿Qué plan de migración corresponde?

Fallos habituales en las migraciones de hosting

Algunas regiones siguen llegando al host antiguo

Causa probable: respuestas DNS en caché, comportamiento de los resolutores o registros que no se cambiaron de forma consistente. Solución: compare las respuestas autoritativas con varios resolutores públicos, mantenga el host antiguo sirviendo el contenido actual e inspeccione los TTL en lugar de forzar cambios repetidos.

Las peticiones de Googlebot caen tras el lanzamiento

Causa probable: un ajuste normal a corto plazo de la frecuencia de rastreo, un desafío del firewall, un fallo de DNS, latencia o errores de servidor. Solución: revise Crawl Stats y los registros de acceso de bots verificados. La caída a corto plazo documentada por Google no es motivo para ignorar fallos de acceso reales.

Las páginas son rápidas pero muestran contenido obsoleto

Causa probable: un TTL de borde, una clave de caché, un fallo de purga o una fuente de datos divergente. Solución: inspeccione Age, Cache-Control, Vary y las cabeceras de estado de caché del proveedor; pruebe variantes significativas; purgue de forma acotada; después verifique el origen y el borde por separado.

El sitio funciona a través de la CDN pero falla al omitirla

Causa probable: la confianza en el certificado de origen, el enrutamiento por cabecera Host, las listas de permitidos del firewall o una dependencia directa del origen que falta. Solución: valide la ruta prevista del borde al origen y la ruta de reversión documentada. No exponga un origen privado solo para que pase una prueba de omisión no planificada.

Los recursos fallan mientras el HTML funciona

Causa probable: nombres de host de recursos omitidos, CORS, certificados, URL absolutas, reglas de caché, protección contra hotlinking o permisos del origen. Solución: rastree y pruebe en navegador el inventario de recursos, incluidas fuentes, imágenes, CSS, JavaScript, PDF y archivos multimedia.

La carga del origen se dispara de inmediato

Causa probable: cachés frías, una clave de caché modificada, caché omitida, falta de blindaje o tráfico de bots que llega directamente al origen. Solución: restaure las reglas de caché previstas, precaliente con cuidado los objetos de alto valor y añada capacidad. Revierta si los fallos sostenidos superan el umbral acordado.

Herramientas para un traslado de infraestructura con las mismas URL

• DNS Checker compara los tipos de registro habituales a través de varios resolutores públicos. Úselo durante la propagación, pero compare también el resultado con la zona autoritativa.
• HTTP Header Checker muestra las cabeceras a lo largo de las redirecciones, incluidas las huellas de la CDN, la compresión, la seguridad y los controles de caché.
• Staging vs. Production SEO Diff compara URL emparejadas en cuanto a estado, canonicals, directivas, cabeceras seleccionadas, datos estructurados y contenido.
• Bulk HTTP Status Code Checker comprueba el estado, las redirecciones, el destino y la latencia en un conjunto representativo de URL.
• Google Index Checker comprueba los bloqueadores observables de rastreo e indexabilidad y después le remite a Search Console para conocer la propia visión de Google.
• Los registros de servidor y de borde demuestran a dónde fue el tráfico, qué respuesta recibió y cuándo la infraestructura antigua está realmente sin uso.
• La monitorización sintética prueba la disponibilidad pública y las transacciones críticas desde varias redes y regiones.

Demuestre que la migración de hosting funcionó

Prueba de propagación del DNS y de vaciado del host antiguo

• Prueba a ejecutar: consulte el DNS autoritativo y varios resolutores públicos, y después represente en un gráfico el volumen de peticiones en la infraestructura antigua y en la nueva.
• Resultado esperado: las respuestas públicas convergen en la ruta prevista mientras el tráfico del host antiguo desciende hasta cero.
• Interpretación del fallo: registros inconsistentes, respuestas en caché o nombres de host no controlados siguen dirigiendo el tráfico a otro lugar.
• Ventana de monitorización: desde el cambio hasta al menos el TTL relevante anterior más largo y hasta que los registros del host antiguo se mantengan en cero.
• Desencadenante de reversión: regiones significativas no pueden resolver ni alcanzar el nuevo servicio y el problema no puede corregirse dentro de la ventana de recuperación.

Prueba de paridad de respuesta

• Prueba a ejecutar: compare la línea base con producción usando Staging vs. Production SEO Diff, un rastreador y pruebas renderizadas en el navegador.
• Resultado esperado: se conservan el estado previsto, los canonicals, las reglas de robots, el contenido, los datos estructurados, los enlaces internos, los recursos y las cabeceras.
• Interpretación del fallo: la configuración del nuevo origen, del borde o de la aplicación ha cambiado una respuesta visible para la búsqueda pese a que las URL son estables.
• Ventana de monitorización: inmediatamente antes y después del cambio, y luego tras cada corrección del lanzamiento.
• Desencadenante de reversión: un fallo de indexabilidad, de canonical, de contenido o de recursos a nivel de todo el sitio afecta a plantillas protegidas y no puede corregirse en caliente de forma segura.

Prueba de acceso de rastreadores y de capacidad

• Prueba a ejecutar: inspeccione los registros de rastreadores verificados, Crawl Stats de Search Console, la latencia del origen, las tasas de error y los resultados de las pruebas de carga sin caché.
• Resultado esperado: los rastreadores verificados reciben respuestas correctas sin desafíos, mientras el origen se mantiene dentro de su envolvente de capacidad establecida.
• Interpretación del fallo: el WAF, el DNS, el TLS, la limitación de tasa o la capacidad del origen están impidiendo un rastreo fiable.
• Ventana de monitorización: continua durante el lanzamiento y los primeros días de estabilización de la frecuencia de rastreo.
• Desencadenante de reversión: los fallos sostenidos de rastreadores y de usuarios superan el umbral aprobado de errores o de disponibilidad.

Prueba de seguridad de la caché

• Prueba a ejecutar: solicite variantes anónimas, autenticadas, localizadas, móviles y con parámetros de consulta mientras inspecciona las claves de caché y las cabeceras de respuesta.
• Resultado esperado: el contenido público se almacena en caché según lo diseñado; las respuestas privadas o personalizadas no se comparten; las variantes significativas se mantienen diferenciadas.
• Interpretación del fallo: las reglas de clave de caché o de omisión pueden servir contenido incorrecto o sobrecargar el origen.
• Ventana de monitorización: antes del lanzamiento, inmediatamente después del cambio y tras cualquier cambio de regla de caché o de purga.
• Desencadenante de reversión: se expone información personalizada, se sirve contenido obsoleto de forma generalizada o el origen no puede sostener la tasa de fallos de caché.

Recursos que merecen su tiempo

Mis artículos relacionados

• A Website Migration Takes More Than a Checklist to Be Successful cubre el proceso de migración más amplio, las líneas base, el entorno de staging y la monitorización.
• Redirects for SEO explica el comportamiento heredado de las redirecciones que debe sobrevivir a un traslado de infraestructura.

Guías relacionadas en este sitio

• Migración web cubre la clasificación de migraciones y el proceso universal.
• Lista de comprobación para la migración web proporciona la lista de comprobación del proyecto por fases.
• Códigos de estado HTTP explica la capa de respuesta que debería conservar y monitorizar.

Desde el sector

• Google: cambiar el alojamiento
• Google: verificar Googlebot
• Cloudflare: DNS TTL
• Cloudflare: Manage DNS records
• Cloudflare: Cache documentation
• Cloudflare: Origin CA
• Bing: IndexNow

Ponga a prueba sus conocimientos: SEO para la migración de hosting web

Cinco preguntas sobre cómo clasificar, lanzar y validar un traslado de infraestructura con las mismas URL. Elija una respuesta para cada una y después compruebe.

Registro de cambios