Lista de Verificación SEO para Migración de Sitio Web

Una migración de sitio web es un cambio controlado en la plataforma, dominio, protocolo, arquitectura de información, estructura de URL o sistema de renderizado de un sitio. Se completa solo cuando los usuarios, rastreadores y analíticas pueden acceder al contenido previsto a través de rutas estables y el equipo puede demostrar que la visibilidad valiosa sobrevivió.

Lista de verificación: SEO para migración de sitio web. Tiempo estimado: comience de 6 a 12 semanas antes del lanzamiento para un sitio mediano; reserve los últimos 5 días hábiles para un congelamiento de cambios, el día del lanzamiento para validación con personal dedicado, y al menos 4 semanas para monitoreo activo. Responsable: un líder de migración responsable de todo el lanzamiento, apoyado por propietarios designados de ingeniería, SEO, analíticas, contenido e infraestructura.

Por qué existe esta lista de verificación y por qué se ejecuta aquí

Esta capa de control de lanzamiento dentro del proceso SEO consume evidencia de rastreo e índice de la auditoría técnica de referencia , decisiones de conservar/fusionar/eliminar del inventario y auditoría de contenido , y la jerarquía de destino del mapa temático y arquitectura de información . Esos resultados deben existir antes de que se puedan juzgar las redirecciones o el entorno de staging.

Ejecútela después de que la estructura de destino esté aprobada pero antes de que las rutas de producción estén congeladas. Si se ejecuta antes, el equipo mapea redirecciones hacia destinos que aún pueden cambiar. Si se ejecuta después, el enrutamiento, las plantillas, las analíticas o las comunicaciones de lanzamiento pueden ser demasiado costosas de corregir de forma segura.

El mapa de redirecciones es el artefacto de mayor riesgo porque conecta rutas antiguas con nuevas. Cada URL antigua valiosa debe ir uno a uno al destino más cercano que preserve su propósito. Nunca use la página de inicio como comodín: frustra a los visitantes y oculta destinos faltantes.

Entradas y salidas

Las salidas son el contrato con las operaciones de lanzamiento. Una hoja de cálculo sin responsables, evidencia o condiciones de aceptación no es una entrega formal.

La lista de verificación

Cada elemento indica qué, por qué, cómo, herramienta y una condición observable de finalización. Reemplace un umbral solo con una regla más estricta o una basada en la línea base documentada.

Fase 1: inventario previo a la migración

1. Construya el inventario de URLs unificado. Qué: combine cada URL antigua descubrible proveniente de rastreos, sitemaps XML, analíticas, Search Console, exportaciones de backlinks, registros CMS, campañas pagadas y registros del servidor. Por qué: ninguna fuente individual contiene cada URL valiosa o solicitada; una página ausente de la navegación puede tener aún enlaces, tráfico o importancia contractual. Cómo: normalice protocolo, host, mayúsculas/minúsculas, barra final, parámetros y caracteres codificados mientras conserva el valor fuente original. Desduplique solo después de registrar dónde se encontró cada URL. Herramienta: rastreador, exportación CMS, analíticas, Search Console, datos de backlinks y registros. Finalización: cada fuente tiene fecha, cada fila tiene una URL normalizada y fuente de descubrimiento, los duplicados están resueltos y los totales de las fuentes coinciden con el inventario final.

2. Clasifique la disposición de cada URL. Qué: etiquete cada URL como conservar, mover, fusionar, eliminar o investigar. Por qué: las redirecciones no pueden mapearse correctamente hasta que la decisión de contenido sea explícita. Cómo: combine tráfico, conversiones, backlinks, estado de índice, calidad de contenido, necesidad comercial e intención; registre la evidencia y el responsable aprobador. Herramienta: libro de trabajo de inventario y auditoría de contenido. Finalización: el 100% de las URLs dentro del alcance tienen una disposición, un responsable, un destino o motivo de eliminación, y no queda ninguna fila sin resolver de “investigar” al momento del congelamiento.

3. Capture la línea base firmada. Qué: conserve las sesiones orgánicas previas al lanzamiento, clics, impresiones, conversiones, ingresos, URLs indexadas, errores de rastreo, códigos de respuesta, disponibilidad y rendimiento para plantillas y directorios prioritarios. Por qué: sin un punto de comparación fechado, la variación normal y el daño de la migración se ven iguales. Cómo: exporte al menos 28 días comparables, anote campañas y estacionalidad, e identifique URLs prioritarias que requieran revisión diaria. Herramienta: analíticas, Search Console, rastreador, datos de posiciones y monitoreo. Finalización: la línea base es de solo lectura, reproducible, segmentada, con marca de tiempo y aprobada por los responsables de SEO y analíticas.

Fase 2: mapeo de redirecciones

4. Mapee fuentes uno a uno siempre que sea posible. Qué: asigne cada URL antigua movida o fusionada a la URL nueva más cercana con la misma intención principal. Por qué: un destino preciso preserva la continuidad para el visitante y proporciona a los rastreadores una señal de reemplazo coherente. Cómo: compare tema, producto, geografía, idioma y tarea; mapee las fusiones a la página superviviente y documente las eliminaciones deliberadas. Nunca mapee URLs no coincidentes a la página de inicio. Herramienta: libro de trabajo de mapa de redirecciones, inventario y rastreo de destino. Finalización: cada fuente cambiante tiene exactamente un resultado aprobado, cada destino es relevante y está dentro del alcance, y las asignaciones comodín a la página de inicio son cero.

5. Valide la mecánica de redirecciones antes del lanzamiento. Qué: pruebe códigos de estado, destinos, comportamiento de consultas, variantes de mayúsculas/minúsculas, protocolo, subdominios, barras finales, archivos y URLs de campaña. Por qué: una hoja de cálculo de aspecto correcto puede producir bucles, cadenas, comodines que se tragan páginas válidas o destinos que devuelven errores. Cómo: genere las reglas de staging o proxy, solicite cada fuente, siga los saltos y compare la URL final con el mapa aprobado. Herramienta: prueba HTTP automatizada, rastreador y revisión de configuración del servidor. Finalización: el 100% de las fuentes mapeadas llegan al destino 200 aprobado en un solo salto de redirección permanente; bucles, cadenas, redirecciones temporales y destinos con error son cero.

6. Reconcilie canónicas, enlaces y sitemaps con las redirecciones. Qué: haga que la URL canónica , los enlaces internos, las referencias hreflang, los datos estructurados, los feeds y los sitemaps XML apunten directamente a las URLs finales. Por qué: redirigir URLs antiguas mientras se siguen publicando crea señales de migración contradictorias y desperdicia solicitudes de rastreadores. Cómo: rastree cada fuente de referencia y compare los destinos normalizados con el mapa de redirecciones. Herramienta: rastreador, HTML renderizado, analizador de sitemaps y diff de configuración. Finalización: las páginas finales se auto-canonican a menos que una excepción aprobada indique lo contrario, las referencias internas a URLs redirigidas son cero y los nuevos sitemaps contienen solo URLs 200 canónicas.

Fase 3: validación de staging

7. Pruebe el staging sin hacerlo indexable públicamente. Qué: rastree la versión completa de staging mientras impide que los motores de búsqueda indexen el entorno. Por qué: el equipo necesita evidencia a nivel de rastreador sin permitir que un sitio duplicado aparezca en los resultados de búsqueda. Cómo: use control de acceso para rastreadores externos, luego ejecute un rastreo interno autenticado con renderizado JavaScript donde el sitio de producción dependa de ello. Trate el bloqueo de staging como configuración temporal de lanzamiento, no como algo a copiar ciegamente a producción. Herramienta: rastreador autenticado, navegador e inspección de encabezados de respuesta. Finalización: el inventario esperado de staging es rastreable por el equipo de pruebas, la indexación pública no autorizada está bloqueada y la lista de verificación de lanzamiento a producción elimina explícitamente los controles exclusivos de staging.

8. Verifique plantillas y recorridos prioritarios. Qué: pruebe páginas representativas de cada plantilla más navegación, búsqueda, formularios, registro, checkout, localización, paginación, filtros y páginas de error. Por qué: una prueba exitosa de la página de inicio no puede revelar un error canónico en páginas de producto ni un estado de consentimiento roto que suprima las analíticas. Cómo: cree una matriz de dispositivo y plantilla, pruebe sesiones limpias y recurrentes, y registre capturas de pantalla o evidencia de respuesta para cada resultado. Herramienta: navegador, verificador de accesibilidad, validador de datos estructurados, depurador de analíticas y pruebas de transacciones. Finalización: cada plantilla dentro del alcance y recorrido primario se prueba correctamente en los navegadores y dispositivos acordados, con cero defectos críticos abiertos.

9. Compare el staging con los contratos aprobados. Qué: compare títulos, descripciones, encabezados, canónicas, directivas robots, datos estructurados, enlaces internos, códigos de respuesta, contenido y etiquetas de analíticas con el sitio antiguo y la especificación de destino. Por qué: las migraciones de plataforma a menudo pierden metadatos o cambian el renderizado incluso cuando el texto visible parece intacto. Cómo: rastree la producción antigua y el staging con configuraciones coincidentes, segmente las diferencias por plantilla y apruebe solo los cambios intencionados. Herramienta: informe de diff de rastreo e inspección de fuente. Finalización: cada diferencia material está corregida o listada como un cambio aprobado con responsable y motivo; los cambios accidentales de noindex, canónica, contenido y seguimiento son cero.

10. Congele el candidato a lanzamiento. Qué: congele el inventario de URLs, mapa de redirecciones, definiciones de rutas, reglas canónicas y de robots, generación de sitemaps, configuración de analíticas y consentimiento, plan de DNS/CDN y despliegues de producción no relacionados. Por qué: un resultado de prueba aplica solo a la versión probada. Cómo: etiquete los artefactos de lanzamiento, restrinja los cambios a la ruta de incidentes y exija volver a probar cualquier cosa afectada por una edición de emergencia. Herramienta: sistema de despliegue, registro de cambios y registro de aprobación. Finalización: un candidato inmutable está nombrado, el acceso está restringido, todas las excepciones tienen un responsable y cada cambio posterior al congelamiento lleva un resultado de prueba.

Fase 4: día del lanzamiento

11. Ejecute un runbook con un único responsable. Qué: despliegue enrutamiento, aplicación, DNS/CDN, analíticas, sitemaps y monitores en el orden aprobado. Por qué: los cambios paralelos sin secuencia dificultan el aislamiento de fallos y hacen insegura la reversión. Cómo: un líder de migración indica cada paso, el operador asignado registra la finalización y los validadores prueban la evidencia antes del siguiente paso dependiente. Herramienta: runbook, registros de despliegue, verificaciones de DNS y canal de incidentes compartido. Finalización: cada línea tiene una hora real, operador, resultado y enlace de evidencia, y ninguna dependencia se marca como completada solo con una confirmación verbal.

12. Ejecute la prueba de humo de lanzamiento. Qué: pruebe la página de inicio, el archivo robots, los sitemaps, al menos una URL por plantilla, cada recorrido prioritario, la recepción de analíticas y una muestra estratificada de fuentes de redirección. Por qué: la respuesta segura más rápida proviene de detectar un fallo amplio antes de que las cachés y los rastreadores lo propaguen. Cómo: pruebe desde fuera de la red de producción, use escritorio y móvil, verifique tanto el HTML servido como la salida renderizada, y compare con las expectativas congeladas. Herramienta: rastreador, navegador, cliente HTTP, vista en tiempo real de analíticas y monitor de transacciones. Finalización: las páginas críticas devuelven el estado y contenido previstos, las redirecciones prioritarias llegan a sus destinos exactos, los eventos de analíticas llegan con las URLs correctas y todas las comprobaciones que bloquean el lanzamiento se superan.

13. Envíe y verifique las señales de descubrimiento. Qué: publique los sitemaps finales, confirme el comportamiento de robots y canónicas, y solicite inspección para un conjunto pequeño de URLs prioritarias. Por qué: las señales de descubrimiento limpias ayudan a los rastreadores a encontrar el conjunto de destinos sin tratar el envío como una garantía de indexación. Cómo: envíe cada sitemap de producción una vez, inspeccione URLs nuevas representativas y registre la canónica informada por Google y el estado de índice. Herramienta: Sitemaps e Indexación e Inspección de URL . Finalización: los sitemaps son accesibles y contienen el inventario canónico congelado, las inspecciones representativas no muestran bloqueo de producción ni canónica incorrecta, y cada advertencia tiene un responsable.

Fase 5: monitoreo posterior al lanzamiento

14. Vigile las primeras 72 horas como ventana de incidentes. Qué: monitoree disponibilidad, 5xx, 4xx, fallos de redirección, latencia, volumen de rastreo, recepción de analíticas, conversiones, procesamiento de sitemaps y recorridos prioritarios de forma continua o en el intervalo práctico más corto. Por qué: los defectos de infraestructura y enrutamiento se manifiestan rápidamente, mientras que el rendimiento de búsqueda tarda más y no debe usarse como la única alarma de lanzamiento. Cómo: compare con la línea base firmada, segmente por plantilla y directorio, y enrute las alertas a un responsable de guardia. Herramienta: registros, analíticas, rastreador, Monitores de Disponibilidad y panel de incidentes. Finalización: el panel no tiene ninguna alerta crítica de lanzamiento sin explicación, cada incidente tiene un responsable y marca de tiempo, y las revisiones de 24, 48 y 72 horas están firmadas.

15. Continúe el monitoreo de búsqueda e índice después de la estabilidad. Qué: realice seguimiento de clics por página, impresiones, estado de índice, canónicas seleccionadas, errores de rastreo, rendimiento por directorio y resultados de conversión durante al menos cuatro semanas. Por qué: el rastreo, la selección de canónicas y el reemplazo de índice van por detrás de la validación de infraestructura. Cómo: compare ventanas equivalentes, separe las URLs movidas de los controles sin cambios, e investigue grupos en lugar de reaccionar al total de un solo día. Herramienta: Páginas de Google Search , Vista de Directorio , Inspección de URL, analíticas y registros. Finalización: los destinos prioritarios son descubribles e indexables, las URLs antiguas resuelven consistentemente a los destinos aprobados, las pérdidas inexplicables tienen tickets asignados, y la propiedad se transfiere a la cadencia de informes habitual.

Herramientas en AmICited

AmICited proporciona evidencia de lanzamiento y superficies de monitoreo; el mapa de redirecciones aprobado y los registros de despliegue siguen siendo la fuente de verdad operativa.

Reglas de decisión

Estas son barreras de protección del lanzamiento, no umbrales universales de motores de búsqueda. Acuérdelas antes del lanzamiento y ajústelas donde el riesgo lo requiera.

La reversión restaura un estado de servicio conocido como bueno; no revierte las fluctuaciones ordinarias de búsqueda. La autoridad de lanzamiento aplica las reglas acordadas y registra la evidencia.

Entregable

Entregue un paquete de control de migración versionado accesible para ingeniería y SEO. Use un libro de trabajo o base de datos para registros a nivel de fila, un runbook para acciones de lanzamiento y un panel para mediciones en vivo.

Debe contener el inventario congelado y la reconciliación de fuentes; mapa de redirecciones aprobado con responsables y pruebas; rastreos antiguo, de staging y nuevo emparejados; diffs de metadatos, canónicas, robots, sitemaps, hreflang, datos estructurados, enlaces y analíticas; línea base firmada y cohortes prioritarias; runbook de lanzamiento y procedimiento de recuperación; reglas numéricas de reversión y responsable de la decisión; y la evidencia de 24, 48 y 72 horas con responsabilidad de monitoreo de cuatro semanas.

El líder de migración debe poder identificar la versión exacta del lanzamiento, probar cada prueba crítica, reconstruir cada decisión de enrutamiento y asignar cada excepción. De lo contrario, el paquete está incompleto.

Qué sale mal

El mapa de redirecciones usa solo el sitemap actual. Las URLs huérfanas, de campaña, backlinks y rutas previamente indexadas desaparecen, por lo que cada fila de la hoja de cálculo se aprueba mientras las solicitudes reales fallan.

La página de inicio se convierte en el destino predeterminado. Los usuarios llegan a algún lugar irrelevante, las señales para los rastreadores se vuelven ambiguas y el contenido faltante se disfraza como progreso de implementación.

Las redirecciones funcionan, pero las referencias siguen siendo antiguas. La navegación, hreflang, canónicas, datos estructurados y sitemaps continúan enviando rastreadores a través de saltos innecesarios y destinos conflictivos.

La protección de staging llega a producción. Un noindex, regla de autenticación, bloqueo robots o política CDN copiados destruyen la indexabilidad . Exija un paso de eliminación explícito y una prueba externa.

El equipo valida solo la página de inicio. Una plantilla compartida puede configurar incorrectamente miles de páginas mientras la página de inicio se prueba correctamente. Examine cada plantilla y rastree reglas a escala.

Los lanzamientos no relacionados se despliegan juntos. Cuando plataforma, analíticas, consentimiento, navegación, checkout y cambios de CDN comparten una ventana, los fallos se vuelven difíciles de aislar o revertir.

La búsqueda se juzga demasiado temprano o de forma demasiado amplia. Los totales del sitio ocultan directorios rotos y un día volátil provoca correcciones innecesarias. Compare cohortes migradas, controles sin cambios, directorios y ventanas equivalentes.

La reversión se debate durante la interrupción. Un buen plan nombra umbrales, responsable de decisión, tiempo de recuperación, comandos, consecuencias de datos y secuencia de validación antes del lanzamiento.

Siguiente fase

Una vez que las primeras 72 horas sean estables, el siguiente paso es el refrescamiento e iteración continua . Necesita la línea base firmada, el mapeo final de URLs, las anotaciones de lanzamiento, las cohortes de directorio, las excepciones conocidas, el historial de incidentes y los responsables designados de esta lista de verificación. Sin esas entradas, una pérdida posterior de tráfico no puede separarse de manera confiable en daño por migración, cambio ordinario de demanda, deterioro de contenido o fallo de medición.

Mantenga el mapa de redirecciones y la anotación de migración de forma permanente. Traslade los hallazgos no críticos a la cadencia de informes habitual con una severidad, hipótesis, responsable, fecha de vencimiento y método de verificación.

Preguntas frecuentes

¿Cuándo debe el equipo de SEO unirse a una migración de sitio web?

Antes de que las rutas, plantillas y restricciones de la plataforma estén fijadas. El SEO necesita tiempo suficiente para inventariar las URLs actuales, preservar los destinos valiosos, influir en la nueva arquitectura de información, definir el comportamiento de las redirecciones y acordar reglas medibles de lanzamiento y reversión.

¿Deben las URLs antiguas redirigir a la página de inicio cuando no hay un reemplazo directo?

No. Redirija una URL antigua a la página más cercana que satisfaga la misma intención del usuario. Si no existe un destino relevante y el contenido no debe conservarse, devuelva un 404 o 410 honesto en lugar de enviar usuarios y rastreadores a una página de inicio no relacionada.

¿Por cuánto tiempo deben mantenerse las redirecciones de migración?

Mantenga las redirecciones permanentes mientras las URLs antiguas puedan seguir recibiendo visitas, enlaces, marcadores o solicitudes de rastreadores. Trátelas como infraestructura de enrutamiento duradera, no como andamios de lanzamiento para eliminar después de unas semanas.

¿Qué debe congelarse antes del lanzamiento de la migración?

Congele el inventario de URLs aprobado, el mapa de redirecciones, las reglas canónicas y de robots, la generación de sitemaps, la configuración de analíticas y consentimiento, los cambios de DNS y CDN, y los lanzamientos de producción no relacionados. Las correcciones de emergencia siguen la ruta de control de cambios designada.

¿Cuándo debe revertirse una migración?

Utilice criterios acordados antes del lanzamiento. Revierta ante fallos como indisponibilidad sostenida, respuestas 5xx generalizadas, recorridos primarios rotos, ausencia de analíticas o defectos de enrutamiento que afecten una parte material de las URLs prioritarias y no puedan corregirse de forma segura dentro de la ventana de recuperación acordada.