Iniciar sesión Empezar gratis

Comprobación de paridad previa a una migración

Las pérdidas por migración se deciden antes del lanzamiento y se diagnostican semanas después, cuando el sitio antiguo ya no existe y la comparación que habría explicado la caída ya no se puede hacer. Las auditorías posteriores al lanzamiento son trabajo de rescate, no de prevención. Esto se ejecuta mientras existen las dos versiones, y su resultado es una decisión de lanzar o no, no una lista de mejoras para más adelante.

CATEGORÍA
SEO técnico
FORMATO
pre-launch-migration-parity-check.md
PASOS
7
PRECIO
Gratis, sin cuenta
CUÁNDO USAR ESTO

Úsala cuando falten semanas para el lanzamiento de un cambio de plataforma, un rediseño o un cambio de dominio y todavía existan a la vez el entorno de staging y el sitio actual en producción.

El archivo de la habilidad

pre-launch-migration-parity-check.md
---
name: pre-launch-migration-parity-check
description: Úsala cuando falten semanas para el lanzamiento de un cambio de plataforma, un rediseño o un cambio de dominio y todavía existan a la vez el entorno de staging y el sitio actual en producción.
---

# Comprobación de paridad previa a una migración

Las pérdidas por migración se deciden antes del lanzamiento y se diagnostican semanas después, cuando el sitio antiguo ya no existe y la comparación que habría explicado la caída ya no se puede hacer. Las auditorías posteriores al lanzamiento son trabajo de rescate, no de prevención. Esto se ejecuta mientras existen las dos versiones, y su resultado es una decisión de lanzar o no, no una lista de mejoras para más adelante.

## Qué necesitas antes

- Un rastreo completo del sitio en producción que exporte URL, estado, canonical, meta robots, title, H1, número de palabras y número de enlaces internos
- Acceso de rastreo a staging detrás de autenticación HTTP o de una lista de IP permitidas, nunca detrás de un bloqueo en robots.txt
- Las URL principales por tráfico, por ingresos y por dominios de referencia, como tres listas separadas y no como una sola
- Una fecha de lanzamiento y el nombre de la persona que tiene autoridad para pararlo

## Método

1. Congela el rastreo de producción como un fichero fechado y guárdalo fuera del proyecto. Después del lanzamiento el conjunto de URL antiguas no se puede reproducir, y ese fichero es la única prueba de lo que existía.
2. Rastrea staging con exactamente la misma configuración y compara las dos listas de URL. Esa diferencia es el mapa de redirecciones; no es un documento que se escriba aparte y después.
3. Confirma que todas las URL de las listas de tráfico, ingresos y backlinks aparecen en el mapa con un destino uno a uno. Agrupar muchas URL antiguas en una categoría o en la home es donde más pierden las migraciones, y siempre se defiende como una limpieza.
4. Compara plantilla contra plantilla en lugar de página contra página: patrón de title, canonical, meta robots, datos estructurados, H1, número de palabras del contenido principal y número de enlaces internos. Una regresión en una plantilla se multiplica por todas las URL que la usan.
5. Confirma que staging está protegido por autenticación y no por robots.txt ni por un noindex global, y confirma después, por separado, que eso que lo protege se retira en el lanzamiento. Cada uno de esos dos fallos ha sacado sitios enteros del índice el mismo día del lanzamiento.
6. Prueba las reglas de redirección en staging contra la lista congelada completa, no contra una muestra: cadenas de consulta, barras finales, rutas en mayúsculas, patrones antiguos que ya nadie recuerda. Las reglas que pasan con veinte ejemplos escogidos a dedo fallan sistemáticamente en la cola larga.
7. Acuerda el conjunto de monitorización antes del lanzamiento: qué URL se comprueban a la hora, al día, a los siete días y a los treinta, qué cifras se vigilan y qué valor dispara una vuelta atrás. Decidir esto después significa discutirlo en plena incidencia.

## Qué produce esto

Un informe de paridad con veredicto de lanzar o no lanzar que contiene el inventario congelado de producción, el mapa completo de redirecciones con cobertura uno a uno de todas las URL valiosas, una comparación por plantilla y un plan fechado de monitorización y vuelta atrás.

## Dónde falla esto

- Proteger staging con robots.txt o con un noindex global, cualquiera de los cuales acaba en producción y desindexa el sitio nuevo el primer día
- Construir el mapa de redirecciones desde el sitemap en lugar de desde los logs y los datos de backlinks, con lo que las URL que nunca estuvieron en el sitemap pero siguen teniendo enlaces y tráfico se pierden sin que nadie se entere
- Lanzar un cambio de plataforma y un rediseño en la misma semana, lo que hace imposible atribuir a uno u otro cualquier caída posterior
- Dar el mapa por terminado en cuanto está escrito, cuando un mapa sin probar es una hoja de cálculo y no una migración

---

De la biblioteca de habilidades de QuQi - https://www.quqi.io/es/skills/pre-launch-migration-parity-check
Descarga gratis · sin cuenta, sin correo

Qué necesitas antes

  • Un rastreo completo del sitio en producción que exporte URL, estado, canonical, meta robots, title, H1, número de palabras y número de enlaces internos
  • Acceso de rastreo a staging detrás de autenticación HTTP o de una lista de IP permitidas, nunca detrás de un bloqueo en robots.txt
  • Las URL principales por tráfico, por ingresos y por dominios de referencia, como tres listas separadas y no como una sola
  • Una fecha de lanzamiento y el nombre de la persona que tiene autoridad para pararlo

Método

  1. 01 Congela el rastreo de producción como un fichero fechado y guárdalo fuera del proyecto. Después del lanzamiento el conjunto de URL antiguas no se puede reproducir, y ese fichero es la única prueba de lo que existía.
  2. 02 Rastrea staging con exactamente la misma configuración y compara las dos listas de URL. Esa diferencia es el mapa de redirecciones; no es un documento que se escriba aparte y después.
  3. 03 Confirma que todas las URL de las listas de tráfico, ingresos y backlinks aparecen en el mapa con un destino uno a uno. Agrupar muchas URL antiguas en una categoría o en la home es donde más pierden las migraciones, y siempre se defiende como una limpieza.
  4. 04 Compara plantilla contra plantilla en lugar de página contra página: patrón de title, canonical, meta robots, datos estructurados, H1, número de palabras del contenido principal y número de enlaces internos. Una regresión en una plantilla se multiplica por todas las URL que la usan.
  5. 05 Confirma que staging está protegido por autenticación y no por robots.txt ni por un noindex global, y confirma después, por separado, que eso que lo protege se retira en el lanzamiento. Cada uno de esos dos fallos ha sacado sitios enteros del índice el mismo día del lanzamiento.
  6. 06 Prueba las reglas de redirección en staging contra la lista congelada completa, no contra una muestra: cadenas de consulta, barras finales, rutas en mayúsculas, patrones antiguos que ya nadie recuerda. Las reglas que pasan con veinte ejemplos escogidos a dedo fallan sistemáticamente en la cola larga.
  7. 07 Acuerda el conjunto de monitorización antes del lanzamiento: qué URL se comprueban a la hora, al día, a los siete días y a los treinta, qué cifras se vigilan y qué valor dispara una vuelta atrás. Decidir esto después significa discutirlo en plena incidencia.

Qué produce esto

Un informe de paridad con veredicto de lanzar o no lanzar que contiene el inventario congelado de producción, el mapa completo de redirecciones con cobertura uno a uno de todas las URL valiosas, una comparación por plantilla y un plan fechado de monitorización y vuelta atrás.

Dónde falla esto

  • Proteger staging con robots.txt o con un noindex global, cualquiera de los cuales acaba en producción y desindexa el sitio nuevo el primer día
  • Construir el mapa de redirecciones desde el sitemap en lugar de desde los logs y los datos de backlinks, con lo que las URL que nunca estuvieron en el sitemap pero siguen teniendo enlaces y tráfico se pierden sin que nadie se entere
  • Lanzar un cambio de plataforma y un rediseño en la misma semana, lo que hace imposible atribuir a uno u otro cualquier caída posterior
  • Dar el mapa por terminado en cuanto está escrito, cuando un mapa sin probar es una hoja de cálculo y no una migración

Usa esta skill en tu propia IA

El archivo es markdown simple, con el nombre y el disparador en su frontmatter. Cuando un asistente sabe cargar skills por su cuenta, es ese frontmatter lo que lee para decidir que esta le aplica.

Claude Code Guárdala como ~/.claude/skills/pre-launch-migration-parity-check/SKILL.md y Claude la carga solo cuando lo que haces coincide con el disparador. Ponla en .claude/skills dentro de un proyecto si la debe tener todo el equipo.
Claude Sube el archivo en la sección de skills de tus ajustes. Una vez ahí se aplica solo en cualquier conversación donde encaje el disparador, sin que tengas que acordarte.
ChatGPT No hay un formato de skills donde instalarla, así que pega el contenido del archivo en las instrucciones de un Proyecto o de un GPT personalizado. Así se aplica a todos los chats de ese proyecto y no solo a aquel donde lo pegaste.
Cualquier otro Pega el markdown en el chat antes de tu pregunta. Funciona en cualquier asistente, solo hay que volver a pegarlo cada vez.

Más en SEO técnico