Lista de verificación de migración del sitio: de la semana T-4 al día 45
Cambio de dominio, nueva plataforma, cambio de hosting o un nuevo esquema de URL: a los enlaces que apuntan a ti no les importa cuál sea. Esta lista te indica qué capturar antes del lanzamiento y qué volver a comprobar después.
Equipo de investigación de ArchiLinks ·
Nuestra posición
La mayoría de las pérdidas por migración se deben a redirecciones faltantes, no al tipo de redirección
Los equipos discuten durante horas sobre si usar 301 o 302 y luego despliegan con 3.000 URLs con enlaces externos que devuelven 404. Encuentra todos los backlinks a un sitio web antes de decidir cualquier otra cosa, porque la lista te indica dónde reside el riesgo.
- Extrae las páginas enlazadas 4 semanas antes, no la noche anterior.
- Cada URL con un enlace externo necesita una redirección 301 de un solo salto a una página relevante.
- Mantén las redirecciones activas durante al menos un año, porque los enlaces antiguos a menudo sobreviven a las páginas a las que apuntaban originalmente.
La línea de tiempo
T-4 semanas: inventario
Rastrea el sitio antiguo, exporta el informe de rendimiento de Search Console y ejecuta toppages más refdomains para el host antiguo. Guarda los tres archivos juntos con la fecha.
T-3 semanas: mapeo
Construye el mapa de redirecciones primero desde las páginas enlazadas, segundo desde el tráfico y tercero desde el rastreo. La receta del mapa de redirecciones muestra el script de clasificación.
T-2 semanas: prueba en staging
Ejecuta cada URL antigua contra staging y verifica un solo salto, estado 301 y un 200 al final. Falla la compilación si hay una cadena o un bucle.
T-0: lanzamiento
Despliega las redirecciones, el nuevo sitemap, las etiquetas canonical actualizadas y los enlaces internos en una sola versión. Envía el nuevo sitemap en Search Console. Para un cambio de dominio, usa la herramienta Cambio de dirección.
T+1 semana: registros y cobertura
Verifica los registros del servidor en busca de visitas de Googlebot en las URLs antiguas, luego el informe de Páginas para picos en 404 o 404 suaves. Corrige el mapa; no esperes.
T+30 a 45 días: diferencia de enlaces
Después de la actualización mensual, extrae refdomains para el nuevo host y compáralo con el archivo antiguo. Las diferencias mayores a unos pocos porcentajes merecen un análisis.
Qué cambia según el tipo de movimiento
| Movimiento | Redirecciones | Verificaciones adicionales | Enfoque en datos de enlaces |
|---|---|---|---|
| Nuevo dominio | 301 a nivel de host, a nivel de ruta donde las rutas cambian | Herramienta Cambio de dirección, dominio antiguo mantenido al menos 12 meses | Dominios de referencia que migran al nuevo host con el tiempo |
| HTTP a HTTPS o cambio de www | 301 a nivel de host | Canonical, HSTS, contenido mixto | Pocas diferencias; confirma que ambos hosts resuelvan a uno |
| Nueva plataforma, mismo dominio | Mapa a nivel de ruta | Paginación, parámetros, barras finales | Páginas más enlazadas que cambiaron de ruta |
| Subdominio a subcarpeta (o viceversa) | Mapa a nivel de ruta, reglas a nivel de host | Cookies, robots.txt por host, analytics | Si los enlaces apuntan al host antiguo o al nuevo |
| Fusión de dos sitios | Mapa de muchos a uno | Contenido duplicado, elecciones de canonical | Superposición de dominios enlazadores mediante intersect |
La lista de verificación del día del lanzamiento
- Las URLs antiguas devuelven 301 en un solo salto, probado por un script en lugar de manualmente.
- El nuevo host devuelve 200 con un canonical auto-referenciado en cada plantilla.
- robots.txt en el nuevo host no contiene reglas de staging. Un Disallow: / dejado atrás es el accidente clásico del día del lanzamiento.
- El sitemap XML lista solo URLs 200, indexables y canonical.
- Los enlaces internos, la navegación y los datos estructurados apuntan a las nuevas URLs, no a las redirigidas.
- Las propiedades de Analytics y Search Console existen para el nuevo host antes del cambio.
- Los archivos JSON de línea base están comprometidos, con la fecha en el nombre de cada archivo.
Nuestro grafo de enlaces se reconstruye aproximadamente una vez al mes. Un enlace creado en la semana de tu lanzamiento puede no aparecer en la extracción del día 30. Usa el informe de Enlaces de Search Console para la última milla, y juzga la diferencia a partir de la segunda actualización. Los mismos datos alimentan la revisión de equidad de enlaces internos vs externos después del lanzamiento, y dominios regionales hreflang cubre el caso multirregional.
Un 301 que termina en 404 no conserva nada
Algunos equipos envían todas las URLs antiguas a la nueva casa y dejan que las páginas de destino expiren más tarde. La redirección en sí funciona. Por eso el hábito es arriesgado, ya que cada salto parece limpio en un registro mientras que la página al final responde con un 404.
Digamos que mueves una tienda a un nuevo dominio y solo conservas los productos que aún se venden. Las páginas de categoría que contenían la mayoría de los enlaces externos ahora rebotan hacia nada útil. Cuenta las URLs enlazadas externamente antes de retirar cualquier cosa. Hazlo como primer paso. Una página con dominios enlazadores necesita un objetivo activo en el mismo tema, no un encogimiento de hombros.
Mantén la regla corta: un salto, luego un 200 final. Cualquier otra cosa es una fuga que elegiste.
Qué protege un 301 de un solo salto a una página activa
El valor de un enlace reside en la URL a la que apunta. Una redirección lleva ese valor solo si la dirección a la que llega responde y aún coincide con el tema. Un producto movido al mismo producto en el nuevo catálogo pasa esa prueba, mientras que un producto enviado a la página principal generalmente no, incluso cuando era la página a la que todos enlazaban.
Vuelve a verificar el estado final después de cada cambio de plantilla. Una redirección que funcionaba en el lanzamiento puede terminar en un 404 después de una versión posterior, cuando alguien elimina una categoría durante una limpieza de menú.
Cuándo un 410 es la respuesta honesta
Algunas URLs antiguas no tenían enlaces, visitas ni reemplazo real. Para esas, un 404 claro o un 410 es más honesto que una redirección a una página que no responde a la pregunta que hacía la antigua. Una redirección a una página no relacionada a menudo se trata como un 404 suave, por lo que no rescata nada.
Escribe la decisión para cada grupo de URLs, con la razón al lado. Una carpeta de tutoriales retirados recibe una respuesta diferente a una carpeta de páginas con ochenta dominios enlazadores, y querrás explicar esa diferencia a un colega en seis meses.
Verificar el último salto, no solo el primero
La mayoría de las pruebas de redirección se detienen en la primera respuesta, que es el lugar equivocado para detenerse. Sigue la cadena hasta su final, luego registra el número de saltos y el estado final junto a la URL antigua. Una cadena de dos saltos no está rota, pero añade demora y un lugar más para que una regla falle.
Si un script está fuera de alcance, una hoja de cálculo y algunas llamadas curl harán el trabajo. La página de scripts de API tiene una versión que puedes programar.
Sitemaps y solicitudes manuales después del lanzamiento
Mantén el sitemap antiguo accesible durante unas semanas después del cambio. Los rastreadores que revisiten el host antiguo aún pueden encontrar esas direcciones en una lista, lo que acelera su primera pasada por las redirecciones.
Las solicitudes manuales son una herramienta diferente. Úsalas para las pocas páginas que más importan, no para cientos de URLs enviadas una por una. Una página solicitada sin enlaces internos y con contenido escaso tiende a desaparecer de nuevo, por lo que la solicitud es solo tan buena como la página detrás de ella.
Esperar es un plan válido. Dale tiempo al rastreo, luego júzgalo con datos.
Mantener el sitemap antiguo listado por un tiempo
Deja el sitemap antiguo en Search Console hasta que las URLs antiguas dejen de aparecer en las estadísticas de rastreo. Luego elimínalo a propósito y anota la fecha en el registro de migración.
No lo elimines el día del lanzamiento solo para que la propiedad se vea ordenada. La eliminación temprana oculta la única lista que nombra cada URL antigua que aún necesitas rastrear.
Solicitar indexación para las páginas que llevan enlaces
Elige las veinte nuevas URLs con más enlaces externos, usando la misma unión que construiste para el mapa de redirecciones, y solicita esas manualmente. El esfuerzo sigue el riesgo en lugar del tamaño del sitio.
Si una página solicitada sigue faltando después de unas semanas, mira la página antes de volver a pedir. Verifica sus enlaces internos, su canonical y su contenido. Una quinta solicitud no cambia nada.
Cuánto tiempo antes de que se pueda juzgar el cambio
Juzga el cambio a partir de la segunda extracción de enlaces, no la primera. Nuestro índice se actualiza aproximadamente una vez al mes, por lo que una extracción el día tres muestra principalmente la imagen del mes pasado. Ejecuta la segunda extracción después de la actualización, y úsala para encontrar todos los backlinks a un sitio web en el nuevo host.
El informe de Páginas y los datos de enlaces responden a preguntas diferentes. Léelos lado a lado, no como vereditos competidores sobre el mismo cambio.
Cinco verificaciones antes de que el sitio de staging se ponga en vivo
Mantén staging fuera del índice
Pon una contraseña o una lista de permitidos delante de staging. Una regla de robots.txt sola no impide que los motores de búsqueda indexen URLs que ya conocen por enlaces.
Verifica las configuraciones noindex y canonical
Abre la plantilla y la configuración del CMS, y busca una bandera noindex o un canonical que nombre otra URL. En WordPress, la configuración de visibilidad de búsqueda es la que la gente olvida después de copiar un sitio desde staging.
Reemplaza el archivo robots de staging
Obtén el robots.txt en vivo una vez hecho el cambio, y compáralo con el archivo que ibas a desplegar. Las reglas de staging que llegan a producción pueden mantener a los rastreadores fuera de todo el host.
Ejecuta la prueba de saltos en el host en vivo
Staging demuestra que el mapa funciona en una copia. Ejecuta la prueba de un solo salto nuevamente en el dominio real después de los cambios de DNS, porque una caché de CDN o una regla de host pueden comportarse de manera diferente allí.
Mantén el host antiguo respondiendo
Deja que el dominio antiguo sirva redirecciones durante el tiempo que sus URLs sigan recibiendo enlaces o visitas. Pon la fecha de renovación en un calendario antes de que alguien olvide que el dominio existe.
Vigilar el sitio después del lanzamiento, no solo antes
Una auditoría previa al lanzamiento registra lo que era cierto el día que se ejecutó. La mayoría de los daños del lanzamiento aparecen más tarde, después de una actualización de plugin, un cambio de regla de CDN o una plantilla que toca una configuración que nadie revisó.
Trata la vigilancia posterior al lanzamiento como un conjunto de pequeñas diferencias contra una línea base guardada. No se necesita un panel de control. Un calendario y una carpeta de archivos con fecha harán.
Qué debería comparar una vigilancia semanal
Elige las verificaciones que más dolerían si cambiaran, y ejecútalas el mismo día cada semana.
- Código de estado y URL final para las 50 URLs antiguas más enlazadas
- robots.txt y la etiqueta meta robots en las plantillas principales
- Conteo de URLs 200 activas contra el conteo en el nuevo sitemap
- Etiquetas canonical en la página de inicio, una categoría y un artículo
Por qué una auditoría única pierde la deriva lenta
La deriva de configuraciones después del lanzamiento. Una bandera de prueba dejada activada, un plugin que reescribe permalinks, o una redirección añadida para arreglar una página pueden deshacer parte del plan. Una auditoría tomada el día del lanzamiento no puede ver ninguna de ellas.
Una diferencia programada puede. Mantén los archivos de línea base en control de versiones y compara la salida de cada semana contra ellos, para que un cambio inesperado sea visible el día que ocurre.
Subdominios, eliminaciones y cambios de dominio de todo el sitio
Algunos equipos mueven una sección a un subdominio e indexan solo sus páginas populares. Eso puede funcionar. El costo es que los enlaces dirigidos a las páginas más silenciosas ahora llegan a un host con menos historial, así que cuéntalos antes de cortar algo.
Las solicitudes de eliminación son más estrechas de lo que parecen. Search Console aplica una eliminación a la propiedad donde la presentas, por lo que una solicitud hecha en un subdominio no actúa en el dominio principal. Verifica la propiedad primero. Luego envíala, y mantén ambas verificadas.
Indexar solo las páginas populares en un subdominio
Comienza con los enlaces por URL en esa sección. Las páginas que llevan enlaces externos pero poco tráfico son las primeras que una regla de solo páginas populares ocultaría. Mantenlas rastreables, o redirige cada una a su página popular más cercana y escribe la razón junto a la regla.
Dónde el sitio principal enlaza al subdominio decide qué tan fácilmente se encuentran sus páginas. Lista esos enlaces antes de elegir qué páginas permanecen ocultas, porque una página que el sitio principal nunca enlaza es difícil de alcanzar de cualquier manera.
Un cambio de dominio de todo el sitio, página por página
Una regla a nivel de host maneja la raíz, pero un cambio de dominio también necesita un mapa a nivel de ruta. Cuando la primera parte de la URL cambia y el slug permanece igual, un intercambio de host cubre la mayoría de las páginas, y las excepciones necesitan sus propias líneas.
Construye la lista desde las páginas enlazadas primero, luego empareja cada ruta antigua con su nueva. La receta del mapa de redirecciones muestra cómo clasificar esa lista por enlaces.
