Plan de migración de sitio web: fases, redirecciones y comprobaciones de lanzamiento

Un estudio de 2025 sobre 892 migraciones de dominios descubrió que el sitio promedio tardó 523 días en recuperar su nivel anterior de tráfico orgánico estimado, según Search Engine Journal, tal como se informó en la guía de rebranding de sitios web de Veza Digital^[1]. Esa es una razón para tratar la migración como protección del tráfico que ya ganas, no solo como una implementación exitosa.

Un plan de migración de sitio web debe cubrir lo que sucede después de que se publica el archivo de redirecciones. Los motores de búsqueda deben descubrir los cambios, los visitantes aún deben completar sus tareas y alguien debe hacerse cargo de las URL antiguas mucho después de que el equipo de lanzamiento se haya marchado.

Esta guía es el plan del proyecto. Para la secuencia detallada de pruebas, consulta nuestra guía sobre pruebas de migración de sitios web, y para un cambio de dominio específicamente, cambio de dominio SEO.

Fases, responsables y resultados de la migración de un vistazo#

Construye el calendario en torno a hitos de aceptación, no a la fecha de lanzamiento preferida por el equipo de diseño. Lo siguiente es un calendario de proyecto ilustrativo, no un requisito universal de plazo de preparación.

Fases, plazos, resultados y responsables de la migración

Programa las dependencias antes de las fechas#

El responsable de SEO aprueba los destinos antes de que ingeniería escriba las reglas de producción. Las redirecciones deben pasar la validación en staging antes de que cambie el sitemap, y las pruebas de experiencia deben terminar antes de que el equipo se comprometa con el cambio.

Para un sitio corporativo pequeño con contenido estable, la auditoría y la asignación de mapas pueden ejecutarse a la vez. Eso ahorra tiempo de traspaso, pero no justifica omitir las pruebas de tareas: un formulario de consulta defectuoso puede hacer que una migración por lo demás ordenada sea comercialmente inútil.

Donde la tabla enumera responsabilidades compartidas, designa un responsable principal y registra a los revisores de apoyo. Hazlo antes de que empiece la auditoría, incluida la persona que puede retrasar el lanzamiento y quién puede autorizar la reversión. De lo contrario, las decisiones sin resolver tienden a llegar a ingeniería justo cuando se cierra la ventana de despliegue.

Audita el sitio heredado y establece una línea base#

Empieza con un rastreo del sitio en vivo usando Screaming Frog o Sitebulb. Complétalo con exportaciones del CMS, sitemaps XML, páginas de aterrizaje de analítica y registros del servidor, porque un rastreador no descubrirá páginas huérfanas a través de enlaces internos.

No asumas que la configuración del nombre de host es obvia. En muestras de escritorio, el uso de www disminuyó del 48,64 % en 2019 al 41,01 % en 2022, según el informe tecnológico de HTTP Archive^[2]. El comportamiento de tu propio host necesita pruebas explícitas, no una decisión basada en la convención.

Producir exportaciones auditables#

Asigna a cada exportación un esquema definido para que otro miembro del equipo pueda reproducir la línea base.

• crawl-export.csv: Incluye URL, código de estado, destino canónico, indexabilidad, título, plantilla y recuento de enlaces internos. Conserva la cadena URL original junto con cualquier clave de coincidencia normalizada.
• gsc-landing-pages-12m.csv: Exporta el historial anual disponible de Search Console con página de destino, fecha, clics, impresiones y propiedad. Mantén coherentes los filtros entre exportaciones.
• backlinks-by-url.csv: Usa Ahrefs, Semrush u otra herramienta de backlinks para registrar la URL de destino, el recuento de dominios de referencia y las páginas enlazantes importantes.
• host-check.csv: Registra la URL solicitada, la secuencia de redirecciones, el nombre de host final y la etiqueta canónica para solicitudes seguras e inseguras, variantes del nombre de host, diferencias de mayúsculas y minúsculas y el comportamiento de la barra final.

Una revisión externa puede ayudar a distinguir los problemas de visibilidad existentes de los riesgos de migración. El recurso de Baikou para revisar la visibilidad de búsqueda de tu sitio web^[3] es un contexto útil al decidir qué páginas heredadas merecen una investigación más detallada.

Congelar una referencia utilizable#

Crea baseline-metrics.csv con recuentos de páginas indexadas, estadísticas de rastreo, Core Web Vitals por plantilla y eventos de conversión por tipo de página. Incluye las fechas de medición y los métodos de recopilación para que nadie compare el rendimiento de campo con una prueba de laboratorio no relacionada.

Adjunta los resultados automatizados de accesibilidad y los hallazgos de tareas realizadas solo con teclado para las plantillas importantes. Registra si los visitantes pueden abrir la navegación, enviar formularios, recuperarse de errores y completar la autenticación, en lugar de guardar solo una puntuación de auditoría.

Guarda las exportaciones en una carpeta compartida con fecha y acceso de lectura para cada propietario. Una vez que se cierre la auditoría, conserva esa instantánea; las correcciones deben ir en una nueva versión fechada con una nota de cambio.

Mapea cada URL y redacta las reglas de redirección#

Trabaja en el inventario siguiendo una secuencia deliberada:

1. Clasifica la URL heredada. Combina el estado de respuesta, el tráfico, los backlinks y el valor del contenido.
2. Elige su destino. Selecciona la página más cercana que satisfaga la misma intención del visitante.
3. Asigna la respuesta. Distingue entre movimientos permanentes, enrutamiento temporal y eliminaciones genuinas.
4. Prueba el comportamiento de las reglas. Revisa rutas, parámetros, recursos, normalización del nombre de host y precedencia de reglas.

Elige la relevancia antes que la comodidad#

Una página rota con dominios de referencia valiosos necesita investigación. Un archivo superficial sin contenido útil puede no merecer un reemplazo. Ninguna de estas decisiones debe tomarse solo a partir del código de respuesta actual.

La consolidación necesita aprobación editorial. Si varios artículos se convierten en un centro temático, el responsable del contenido debe confirmar que ese centro responde a las preguntas que abordaban esos artículos. Una página de categoría amplia no es automáticamente un destino equivalente.

Acción de redirección y código de estado por caso de URL heredada

Usa comportamiento de redirección permanente frente a temporal para definir la intención antes de la implementación. El enrutamiento temporal necesita una decisión de caducidad, no solo un código de respuesta diferente.

Una comprobación de un salto que puedes repetir#

Cada fila de la tabla anterior debería terminar en un solo salto. El 27 de octubre de 2026 (aproximadamente a las 01:20 UTC) solicitamos las cuatro variantes de la página de inicio de RedirHub con curl desde un servidor en la nube, sin seguir redirecciones. Cada variante con redirección llegó a la página de inicio canónica en un solo salto:

Ejecuta curl -sS -o /dev/null -w "%{http_code} %{redirect_url}" sobre cada variante de tu propio host, y corrige cualquiera que devuelva una segunda redirección antes de lanzar. La combinación de 301 y 308 de arriba está bien: ambas son permanentes, y la elección solo importa cuando se debe preservar el método de la solicitud.

Escribe excepciones explícitas#

Conserva la atribución de campañas y los parámetros funcionales de la consulta, pero no arrastres ciegamente identificadores de sesión obsoletos ni parámetros que rompan el destino. Prueba caracteres codificados, parámetros repetidos y rutas profundas contra la aplicación real.

Incluye archivos descargables e imágenes vinculadas. Para proyectos de comercio electrónico, las mejores prácticas de redirección para migraciones a Shopify^[4] de Grumspot proporcionan contexto específico de la plataforma para revisar las reglas junto con el comportamiento de la tienda.

La lista de verificación de migración de Patrick Stox^[5] recomienda asignaciones directas y permanentes, incluidos los recursos, y mantener las cadenas en aproximadamente tres saltos o menos. Prefiere la resolución directa al destino final en lugar de encadenar una redirección del host, una redirección del protocolo y una reescritura de la ruta.

Guarda el mapa aprobado como un archivo versionado con la URL antigua, el destino, la respuesta prevista, la justificación, el responsable y el revisor. Da prioridad a las asignaciones específicas frente a los patrones amplios, y exige revisión cada vez que alguien modifique cualquiera de las dos. El Migration Redirect Mapper puede ayudar a organizar los pares de URL antiguas y nuevas.

Configurar Search Console para ambos sitios#

Prepare el acceso a los informes antes del cambio. El responsable de SEO necesita inspeccionar las propiedades antigua y nueva de forma independiente; un panel combinado puede ocultar una sección heredada con problemas detrás del crecimiento en otra parte.

Prepare el acceso y los informes#

• Verifique la propiedad: Use una verificación duradera controlada por la organización, no la cuenta de un contratista que se va. Incluya en el alcance de supervisión los subdominios que generan tráfico.
• Haga coincidir el alcance de la propiedad: Las propiedades de dominio incluyen variantes de hostname y protocolo, mientras que las propiedades con prefijo de URL tienen límites más estrechos. Asegúrese de que las comparaciones cubran conjuntos de URL equivalentes.
• Prepare el sitemap: Genérelo a partir de los destinos canónicos previstos y valídelo antes del lanzamiento. Retenga el envío hasta que esos destinos y sus redirecciones funcionen en producción.
• Archive los informes: Guarde las exportaciones de rendimiento e indexación en la carpeta de auditoría, con los filtros y los nombres de las propiedades registrados.
• Asigne revisores: Nombre un responsable y un suplente para cada propiedad, con una cita de revisión periódica durante la estabilización.

Gestione el cambio de dominio deliberadamente#

Para un cambio de dominio elegible, prepare el flujo de trabajo de Cambio de dirección en la propiedad antigua y envíelo después de que las redirecciones estén activas y superen sus comprobaciones. No lo use como sustituto de la asignación de URL ni para cambios que no admite.

Mantén verificada la propiedad antigua mientras las URL heredadas sigan siendo relevantes para la supervisión. Retirar el acceso demasiado pronto dificulta investigar impresiones persistentes, URL omitidas y comportamientos de rastreo inesperados.

Preserva también la continuidad de la analítica. Confirma los nombres de eventos, el comportamiento del consentimiento y la configuración entre dominios para que un cambio de seguimiento no se confunda con una pérdida de tráfico o de conversiones.

Para una replatformación en el mismo dominio, donde el dominio sigue siendo el mismo pero cambia la plataforma detrás de él, Integration Mode permite que la nueva plataforma (Cloudflare Workers, Next.js en Vercel o Caddy) sirva el mapa de redirecciones desde RedirHub sin un cambio de DNS y reporte los 404 que los visitantes siguen encontrando después del lanzamiento.

Comprobaciones previas al lanzamiento y la llamada de ir o no ir#

Una página de inicio que funcione no demuestra que el sitio esté listo. Construye el conjunto de pruebas a partir de páginas con tráfico, recursos enlazados, formas alternativas de URL y las plantillas que los visitantes usan para completar tareas valiosas.

Reproduce el inventario en staging#

El equipo de ingeniería debe reproducir el enrutamiento de producción en un entorno aislado, incluidas las reglas de CDN y las redirecciones de la aplicación. Usa una sustitución de host o una configuración controlada equivalente para probar solicitudes heredadas sin exponer staging a los motores de búsqueda.

El informe de reproducción debe incluir la URL solicitada, el destino esperado, el destino real, el recorrido de la respuesta, el resultado del parámetro y la indexabilidad final. Señala bucles, cadenas inexplicadas, respuestas exitosas inesperadas, desajustes de destino, parámetros perdidos y redirecciones que terminan en errores.

Revisa también los recursos y las señales de descubrimiento:

• Activos de la aplicación: JavaScript, CSS, imágenes y descargas deben cargarse sin autenticación ni fallos de enrutamiento.
• Directrices de búsqueda: Revisa robots.txt, las etiquetas canónicas, las referencias hreflang, los enlaces internos y las entradas del sitemap.
• Controles de lanzamiento: Confirma que producción no heredará contraseñas de staging, bloqueos de rastreo accidentales ni directivas noindex no deseadas.
• Medición: Verifica los eventos de conversión usando envíos de prueba y transacciones completadas, no solo páginas vistas.

Nuestro Comprobador de redirecciones gratuito puede apoyar la repetición, mientras que nuestro Servicio de redirecciones 301 admite el mapeo de destinos, el reenvío requerido de rutas y consultas, y las pruebas de recorrido previas al lanzamiento. Usa el flujo de trabajo de comprobación masiva de redirecciones para que los resultados sean repetibles en lugar de depender de comprobaciones puntuales en el navegador.

Compara las distribuciones por clase de respuesta con la línea base, teniendo en cuenta las eliminaciones aprobadas. Los recuentos de páginas indexadas, los clics orgánicos y la actividad del rastreador se convierten en comparaciones de producción después del lanzamiento; el staging puede establecer la preparación técnica, no la recuperación de la búsqueda.

Prueba si las personas pueden finalizar#

Ejecuta tareas equivalentes en las experiencias antigua y nueva usando solo el teclado, un lector de pantalla y dispositivos móviles. Incluye procesos de pago o formularios de captación de leads, autenticación, errores de validación y recuperación después de un envío fallido.

La Ley Europea de Accesibilidad entró en vigor el 28 de junio de 2025 para los productos y servicios cubiertos que atienden a usuarios de la UE, como se describe en la guía de migración de sitios web de Niteco^[6]. Trata la aceptación de accesibilidad como un aspecto relevante para el cumplimiento cuando corresponda, y haz que el especialista legal o de accesibilidad responsable confirme el alcance del proyecto.

Redacta los criterios de aceptación de las tareas antes de probar. Exige la finalización satisfactoria sin una ralentización repetible en condiciones comparables, e investiga las diferencias de tiempo en lugar de tratar la variación normal de los participantes como un defecto.

Haz explícita la decisión de lanzamiento#

El responsable de la migración debe recopilar la aprobación basándose en evidencia concreta:

• Inventario y mapeo: El inventario está fechado, las decisiones de destino están aprobadas y la versión del mapa revisada se referencia en el lanzamiento.
• Aceptación técnica: No quedan fallos de enrutamiento sin explicación en las URLs de alto valor.
• Aceptación de experiencia: Las tareas críticas no tienen regresiones de accesibilidad o funcionales sin resolver.
• Preparación para la recuperación: Las copias de seguridad se pueden restaurar, la reversión se ha ensayado y la conciliación de transacciones tiene un responsable.
• Cobertura operativa: Cada fase tiene una persona responsable y un contacto de escalamiento.

Un elemento de alto valor fallido retrasa el lanzamiento. Los problemas cosméticos pueden entrar en una cola de remediación documentada, pero el checkout roto, el rastreo bloqueado y los formularios inaccesibles no son cosméticos.

Procedimiento del día de lanzamiento en orden#

Use un runbook con un operador, un verificador y un resultado registrado para cada acción. Elige una ventana de bajo tráfico en la que las personas necesarias para el diagnóstico estén disponibles, no solo la hora más tranquila en el gráfico de tráfico. Un lanzamiento a las 3 a. m. que nadie pueda solucionar es más arriesgado que un lanzamiento a una hora moderada con todo el equipo en línea.

Ejecutar el corte de transición#

1. Congela los cambios. Detén la publicación de contenido y las ediciones de URL en ambos sistemas durante el intervalo previo al corte de transición acordado. Documenta las excepciones esenciales y vuelve a generar las pruebas de mapeo afectadas antes de continuar.
2. Verifica el artefacto de la versión. Compara la configuración de redirecciones con el mapa aprobado usando una suma de comprobación o un identificador de versión. Un nombre de archivo familiar no demuestra que ingeniería haya revisado las reglas.
3. Despliega el enrutamiento y el nuevo sitio juntos. Coordina los cambios de la aplicación, la CDN y la infraestructura para que los visitantes no se encuentren con un entorno parcialmente migrado. Elimina las restricciones de acceso exclusivas de producción y los bloqueos de indexación no intencionados como parte del lanzamiento controlado.
4. Haz una prueba rápida de las URL prioritarias. Revisa las páginas de destino heredadas de mayor valor, los destinos de enlaces entrantes y los puntos de entrada a transacciones. Verifica el enrutamiento directo, las respuestas previstas, los parámetros requeridos y un destino canónico indexable; después, inicia la repetición completa del inventario.
5. Publica y envía el sitemap. Publica el sitemap de producción solo después de que sus destinos resuelvan correctamente. Mantén accesible la propiedad antigua de Search Console y completa cualquier notificación de traslado aplicable.
6. Comprueba todos los nombres de host. Verifica la resolución DNS, la cobertura del certificado y el enrutamiento de los dominios antiguos y los subdominios activos. No retires un servidor antiguo hasta que otro extremo pueda servir sus redirecciones de forma fiable.
7. Supervisa el comportamiento en vivo. Ingeniería supervisa los errores del servidor y los registros de redirección mientras analítica comprueba los eventos entrantes y UX verifica las tareas críticas. Registra la hora del despliegue para que las investigaciones posteriores puedan distinguir los efectos del lanzamiento de los cambios no relacionados.
8. Aplica la regla de reversión acordada. Detén o revierte la versión afectada cuando fallen los recorridos críticos, aparezcan bucles de redirección o los errores del servidor superen la tolerancia de referencia acordada. Evita improvisar reescrituras amplias en producción mientras los clientes estén experimentando fallos.

Mantén utilizable la reversión#

Define si la reversión significa restaurar los archivos de la aplicación, cambiar el enrutamiento, restaurar los datos o alguna combinación. En los sitios transaccionales, revertir la infraestructura sin conciliar los nuevos pedidos o envíos puede crear un segundo incidente. Asigna el paso de conciliación a un responsable designado antes del lanzamiento y ensaya la secuencia completa para que el equipo sepa cuánto tarda una reversión bajo carga.

Trata la capa de redirección como parte de la decisión de reversión, no como un telón de fondo fijo. Si las nuevas reglas de enrutamiento son la causa de los fallos, revertir solo el código deja activas las mismas redirecciones rotas. La documentación de Google sobre migración de sitios^[7] recomienda redirecciones del lado del servidor desde el momento en que comienza el traslado, el envío del mapa del sitio después de que las nuevas URL resuelvan, y un seguimiento separado de las propiedades antiguas y nuevas de Search Console. Por lo tanto, el despliegue es un hito operativo, no el punto en el que termina la responsabilidad de la migración.

Supervisión posterior al lanzamiento y gobernanza de redirecciones#

Mantén a un responsable designado vinculado a cada ventana de monitoreo. La guía de Siteimprove sobre el riesgo en transformaciones web^[8] identifica un inventario de redirecciones actualizado, la propiedad asignada, umbrales de escalamiento y decisiones de caducidad de reglas temporales como lagunas operativas en la planificación de migraciones.

Cadencia de supervisión posterior al lanzamiento

A continuación se propone un calendario operativo. Ajusta el personal según el riesgo sin eliminar los controles.

Gestiona los cambios, no solo los incidentes#

Analytics es responsable de la integridad del seguimiento y de las comparaciones de referencia; SEO se encarga de la investigación de búsqueda; ingeniería, de la implementación y reversión; y el contenido, de la relevancia del destino y de las correcciones de enlaces internos. Usa un flujo de trabajo documentado de supervisión de redirecciones para que las alertas lleguen a la persona responsable.

Mantén el inventario buscable y versionado, con un revisor para cada edición. Las reglas temporales necesitan una fecha de caducidad y un revisor asignado; la caducidad debe activar una decisión, no una eliminación automática sin revisar el tráfico.

La documentación de Google sobre cambios de sitio recomienda conservar las redirecciones durante al menos 180 días, y más tiempo cuando las URL antiguas siguen recibiendo tráfico de Google Search. Nuestra recomendación es mantener indefinidamente las redirecciones permanentes de migración, porque los backlinks, los marcadores y las URL indexadas pueden seguir enviando visitantes durante años.

Imagina que una empresa SaaS mueve su blog a un directorio de recursos. Más tarde, los boletines antiguos siguen enviando visitantes cualificados a las direcciones de los artículos heredados, por lo que el propietario del contenido mantiene esos mapeos activos en lugar de retirarlos para ordenar el inventario.

Evalúa la recuperación a lo largo de tendencias sostenidas, con comparaciones estacionales y diagnóstico a nivel de página. Una semana de lanzamiento tranquila no demuestra el éxito, y una caída del tráfico por sí sola no identifica la causa.

RedirHub ofrece mapeos de migración con importación CSV, reenvío de rutas y parámetros de consulta, y HTTPS automático para los hostnames conectados. Visita RedirHub para poner en funcionamiento tu mapa de URL aprobado y mantener activos los enlaces antiguos después del lanzamiento.