UNmissChecklist de migración de sitio (PDF)
Usa esta checklist como la hoja imprimible de aprobación para una migración de sitio, la página que cada responsable marca y firma antes y después de la puesta en marcha. Cada variante es una fase, desde la planificación y las copias de seguridad hasta el día del lanzamiento y el monitoreo posterior, terminando con una aprobación formal. Imprímela, revísala fase por fase y no avances hasta que el responsable haya firmado la fase. Mantiene la migración bajo control en lugar de depender de la memoria y las buenas intenciones.
- Formato
- Word .docx editable
- Longitud
- 6 variantes - ~6 pages
- Precio
- 100 % gratis
- Configuración
- Copiar o descargar
Obtén el documento Word editable con un clic.
★★★★★4.9·Gratis · Sin registro · Descarga instantánea
Semrush
Se RankingChecklist de migración de sitio (PDF)
Objetivo: asegurar que la migración sea reversible y esté completamente planificada antes de empezar el trabajo.
Marcar antes de comenzar
- ☐ Copia de seguridad completa del sitio actual (archivos y base de datos) realizada y restauración probada
- ☐ Rastreo completo del sitio antiguo exportado y guardado
- ☐ Mapeo de URL (antiguas a nuevas) redactado para cada página
- ☐ Línea base de Analytics y Search Console registrada: [traffic / rankings snapshot]
- ☐ Plan de rollback escrito y acordado con el responsable de desarrollo
- ☐ Ventana de lanzamiento programada para horas de bajo tráfico: [Date / time]
Aprobación de la fase 1
Responsable: [Name] Fecha: [Date] Firma: [Signature]
6 variantes listas para usar
Copiar todoFase 1: Planificar y hacer copia de seguridad
Cuándo usarla: Cierra el plan y realiza copias de seguridad completas antes de que alguien cambie una sola URL.
Objetivo: asegurar que la migración sea reversible y esté completamente planificada antes de empezar el trabajo.
Marcar antes de comenzar
- ☐ Copia de seguridad completa del sitio actual (archivos y base de datos) realizada y restauración probada
- ☐ Rastreo completo del sitio antiguo exportado y guardado
- ☐ Mapeo de URL (antiguas a nuevas) redactado para cada página
- ☐ Línea base de Analytics y Search Console registrada: [traffic / rankings snapshot]
- ☐ Plan de rollback escrito y acordado con el responsable de desarrollo
- ☐ Ventana de lanzamiento programada para horas de bajo tráfico: [Date / time]
Aprobación de la fase 1
Responsable: [Name] Fecha: [Date] Firma: [Signature]
Fase 2: QA en staging
Cuándo usarla: Verifica el nuevo sitio en staging para detectar los problemas antes de que sean públicos.
Objetivo: confirmar que el nuevo sitio sea correcto y rastreable mientras aún es privado.
Marcar en staging
- ☐ Redirecciones probadas en staging y devolviendo los códigos esperados
- ☐ Títulos, meta descriptions y encabezados presentes en páginas clave
- ☐ Las etiquetas canonical apuntan a las nuevas URL
- ☐ Enlaces internos actualizados a las nuevas URL, sin enlaces al dominio antiguo
- ☐ robots.txt permitirá el rastreo en el lanzamiento (noindex de staging eliminado al salir en vivo)
- ☐ Sitemap XML generado con las nuevas URL y validado
- ☐ Renderizado móvil y velocidad de página comprobados en plantillas clave
Aprobación de la fase 2
Responsable: [Name] Fecha: [Date] Firma: [Signature]
Fase 3: Día del lanzamiento
Cuándo usarla: La secuencia de puesta en marcha, marcada en orden a medida que se completa cada paso.
Objetivo: ejecutar el cambio limpiamente y confirmar lo esencial en cuanto el sitio esté en vivo.
Marcar durante el lanzamiento
- ☐ Noindex / protección con contraseña de staging eliminados
- ☐ Redirecciones desplegadas en producción
- ☐ robots.txt en vivo y permitiendo el rastreo del nuevo sitio
- ☐ Nuevo sitemap enviado en Search Console
- ☐ Analytics y seguimiento de etiquetas confirmados como activos en el nuevo sitio
- ☐ Una muestra de URL antiguas de alta prioridad confirmada manualmente como redirigida
- ☐ Certificado SSL válido en todo el nuevo dominio
Aprobación de la fase 3
Lanzado por: [Name] Hora en vivo: [Time] Firma: [Signature]
Fase 4: Primeras 48 horas
Cuándo usarla: Detecta los errores que solo aparecen cuando el tráfico real llega al sitio en vivo.
Objetivo: encontrar y corregir roturas del día de lanzamiento antes de que cuesten rankings.
Marcar dentro de 2 días
- ☐ Rastreo completo del sitio en vivo ejecutado; 404 y redirecciones rotas registradas
- ☐ Cadenas y bucles de redirección revisados y resueltos
- ☐ Search Console revisado por errores de rastreo y advertencias de cobertura
- ☐ Tasa de errores del servidor y tiempos de carga de página monitoreados: [status]
- ☐ Páginas de alta prioridad confirmadas como indexables y devolviendo 200
- ☐ Cualquier contenido perdido en el traslado restaurado o marcado: [notes]
Aprobación de la fase 4
Responsable: [Name] Fecha: [Date] Firma: [Signature]
Fase 5: Monitoreo de las semanas 1 a 4
Cuándo usarla: Observa cómo se estabilizan rankings, indexación y tráfico para abordar pronto las caídas reales.
Objetivo: confirmar que la migración se mantuvo estable y actuar sobre cualquier cosa que se haya escapado.
Marcar durante el primer mes
- ☐ Indexación de las nuevas URL avanzando en Search Console
- ☐ Rankings de keywords prioritarias comparados con la línea base pre-lanzamiento
- ☐ Tráfico orgánico comparado con el mismo periodo del ciclo anterior: [trend]
- ☐ Cualquier página que haya perdido rankings investigada y corregida
- ☐ Backlinks que apuntan a URL antiguas aún resolviendo mediante redirecciones
- ☐ Sitemap antiguo eliminado una vez indexadas las nuevas URL
Aprobación de la fase 5
Responsable: [Name] Fecha: [Date] Firma: [Signature]
Fase 6: Aprobación final
Cuándo usarla: Cierra el proyecto una vez verificado que la migración está estable y con responsabilidades claras.
Objetivo: cerrar formalmente la migración con cada responsable de fase rindiendo cuentas.
Confirmar antes de cerrar
- ☐ Todas las fases anteriores aprobadas
- ☐ Sin 404 pendientes ni redirecciones rotas en páginas prioritarias
- ☐ Tráfico y rankings dentro de un rango aceptable frente a la línea base, o recuperándose según el plan
- ☐ Incidencias abiertas registradas con responsables y fechas de entrega: [list]
- ☐ Informe post-migración compartido con stakeholders
Aprobación del proyecto
Responsable SEO: [Name] Fecha: [Date] Firma: [Signature]
Responsable de desarrollo: [Name] Fecha: [Date] Firma: [Signature]
Aprobador: [Name] Fecha: [Date] Firma: [Signature]
Cómo usar esta plantilla
- Imprime la checklist y asigna un responsable con nombre a cada fase antes de que empiece cualquier trabajo.
- Completa la fase 1: realiza y prueba una copia de seguridad completa, registra las líneas base y acuerda un plan de rollback.
- Trabaja la fase 2 completamente en staging para verificar en privado redirecciones, metadatos y rastreabilidad.
- Ejecuta la secuencia de lanzamiento de la fase 3 en orden y confirma las redirecciones y el tracking en cuanto salgas en vivo.
- Dentro de las 48 horas, rastrea el sitio en vivo en busca de 404 y problemas de redirección, y corrígelos rápido.
- Monitorea indexación, rankings y tráfico durante las semanas 1 a 4 e investiga cualquier cosa que se desvíe.
- Exige que el responsable de la fase firme cada fase antes de que la migración avance a la siguiente.
- Completa la aprobación final solo cuando las páginas prioritarias estén limpias y los stakeholders tengan el informe.
Consejos profesionales
- Trata cada línea de aprobación como una puerta real, no como una formalidad: una fase sin firmar significa que el trabajo no está verificado, y el trabajo sin verificar es donde las migraciones pierden tráfico.
- Realiza y prueba la restauración de tu copia de seguridad antes de tocar nada; un plan de rollback que nunca has probado es una esperanza, no un plan.
- Programa el lanzamiento para horas realmente de bajo tráfico, de modo que los inevitables ajustes de la primera hora afecten al menor número de usuarios.
- Mantén el monitoreo durante un mes completo; rankings e indexación se estabilizan gradualmente, y las peores caídas suelen aparecer una o dos semanas después del lanzamiento, no el primer día.
Preguntas frecuentes
¿Por qué usar un PDF imprimible en lugar de una hoja de cálculo?
Una hoja de aprobación trata de responsabilidad, no de datos. Imprimirla y hacer que cada responsable marque y firme obliga a detenerse de forma deliberada en cada puerta. Funciona bien junto con una hoja de cálculo de mapeo de URL, que gestiona el detalle fila por fila, mientras esta hoja confirma que cada fase fue realmente completada y asumida por alguien.
¿Con cuánta antelación al lanzamiento debería empezar la fase 1?
Empieza la planificación y las copias de seguridad bastante antes de la ventana de lanzamiento, idealmente con semanas de margen si es un sitio grande. Apurar el plan y el mapeo es de donde viene la mayor parte del daño evitable en una migración. Cuanto antes existan el rastreo, el mapeo y el plan de rollback, menos presión habrá el día del lanzamiento.
¿Cuál es la fase más importante?
Honestamente, la QA en staging de la fase 2 y el rastreo de 48 horas de la fase 4 son los que más detectan. Probar las redirecciones antes del lanzamiento y volver a rastrear justo después cubre las mayores fuentes de pérdida de tráfico. Dicho eso, saltarse la copia de seguridad en la fase 1 es el único error que realmente no puedes deshacer.
¿Debo esperar una caída de tráfico después de migrar?
Una caída breve mientras los motores de búsqueda vuelven a rastrear y reindexar es común, incluso en una migración limpia. Lo importante es que la tendencia se recupere en cuestión de semanas. Una caída que sigue profundizándose suele indicar redirecciones rotas, contenido perdido o problemas de indexación que la fase de monitoreo está diseñada para detectar.
¿Quién debe firmar cada fase?
La persona realmente responsable de ese trabajo: normalmente un desarrollador para el lanzamiento y las redirecciones, y un responsable SEO para QA y monitoreo. Un aprobador final firma todo el proyecto. Los nombres reales en cada línea dejan claro quién verificó qué si algo necesita revisarse más adelante.
¿Puedo reutilizar esto para un cambio más pequeño, como un rediseño?
Sí, aunque puedes omitir las fases que no apliquen. Un rediseño que mantiene las URL sin cambios requiere menos trabajo de redirecciones, pero aun así se beneficia de QA en staging, una copia de seguridad y monitoreo posterior al lanzamiento. Ajusta la hoja a las fases que coincidan con el alcance de tu cambio específico.