Analizar enlaces en cambios de sitio web alrededor de una migración

Construye el mapa de redirecciones antes del lanzamiento

El mapa de redirecciones es la parte de un cambio que la gente subestima. Los destinos son lo más importante. Antes de analizar los datos de enlaces de sitio web después de un cambio, las URLs antiguas necesitan un destino claro, porque esas son las direcciones a las que ya apuntan tus enlaces.

Uno a uno supera un volcado a la página principal

Enviar cientos de URLs antiguas no relacionadas a la página principal dice muy poco a los motores de búsqueda y a los visitantes. La relevancia es la prueba. Mapea cada URL antigua de alto valor a su página nueva más cercana y envía el resto a una sección que aún coincida con su tema.

Exporta primero las URLs antiguas con sus códigos de estado. Guarda ese archivo. Ese archivo es la lista de verificación y muestra qué páginas ganaron los enlaces.

Donde una página no tenga una coincidencia cercana, indícalo en el mapa y envíala a la sección más cercana, con una nota. Las celdas en blanco ocultan decisiones. Una celda en blanco en la tabla es una decisión que nadie tomó.

Aplana las cadenas antes del lanzamiento

Una redirección que pasa por dos reglas anteriores antes de llegar a la página nueva añade retraso y riesgo. Las cadenas son fáciles de crear cuando una segunda migración se superpone a la primera, así que revisa el mapa antes de cada cambio en lugar de asumir que sigue limpio. Cada salto adicional tiene un costo. Solicita cada URL antigua una vez después del cambio y confirma que responde con un solo salto.

Arregla eso temprano. Corrige las cadenas en el propio mapa, no una por una después del lanzamiento, para que la lista se mantenga corta.

Mantén las rutas que aún funcionan

Cambiar la estructura de URL en un rediseño es la pérdida más evitable. Cada cambio a una ruta es también un cambio para cada enlace que apunta a ella, y esos enlaces están fuera de tu control. Mantén lo que funciona. Si una ruta aún funciona, mantenla y cambia solo lo que el cambio te obligue a cambiar.

Menos redirecciones, menos errores. Cada ruta que mantienes es un enlace que nunca necesitó una redirección en absoluto.

Una ruta mantenida significa que las filas antiguas de anchors siguen apuntando a algo útil, lo cual es una cosa menos que reconstruir en la hoja. Menos reconstrucción más tarde.

Qué esperar después

Ellos hacen el trabajo pesado, y una redirección 301 de la URL antigua a la nueva permite que los enlaces antiguos sigan funcionando. Mantener una redirección por URL antigua, sin cadenas intermedias, es la forma más sencilla de mantener intacto el valor de cada enlace. Redirecciones. Las cadenas de tres o cuatro saltos ralentizan a los rastreadores y es mejor aplanarlas.

El anchor text no cambia cuando una URL se mueve, porque el texto vive en la página que enlaza. Lo que cambia es el recuento de destinos: tu tabla de páginas principales mostrará que el host antiguo se desvanece y el nuevo aumenta durante algunas actualizaciones mensuales. Los destinos cambian lentamente.

Una sorpresa común es eliminar la plataforma antigua demasiado pronto. No lo hagas. Squarespace, Wix y hosts similares a menudo mantienen las reglas de redirección, por lo que cancelar el plan puede eliminarlas, y los enlaces apuntarán a un callejón sin salida hasta que reconstruyas las reglas en otro lugar.

Hreflang y canonicals también merecen una mirada. Las discrepancias son comunes. Después de una migración de CRA a Next.js, por ejemplo, los sitios a menudo terminan con etiquetas canonical que discrepan de sus conjuntos hreflang, y los enlaces se dividen entre dos versiones de una página.

Si los números discrepan después del cambio, verifica la tabla de solución de problemas antes de asumir que se perdieron enlaces. Una actualización mensual sola explica muchas lagunas. Las lagunas suelen ser cuestión de tiempo.

Espera la primera comparación limpia sobre dos actualizaciones mensuales después del lanzamiento, y escribe la fecha de cada actualización en tu hoja para que un mes plano no se confunda con uno atascado. Dale tiempo. Ahrefs o Semrush pueden llenar la brecha con rastreadores más frescos si necesitas una lectura intermedia.

Vigila lo que se mueve sin un aviso de lanzamiento

El día del lanzamiento tiene una lista de verificación, pero varios problemas llegan más tarde y en silencio. Aparecen en las filas y en el índice, mucho después de que el equipo haya pasado a otras tareas. Son fáciles de pasar por alto.

Noindex que viaja con una compilación de staging

Una copia de staging que se mantuvo fuera de la búsqueda puede llevar sus configuraciones al sitio en vivo. Verifica las etiquetas meta robots y cualquier encabezado noindex en el primer rastreo, y muestra páginas de cada sección en lugar de solo la página principal. Muestra cada sección.

Las plantillas se rompen primero. Si toda una sección se elimina del índice después del lanzamiento, mira su plantilla antes de mirar su contenido.

Las capturas de pantalla también ayudan. Guarda una copia de la configuración de robots de la compilación de staging también. Cuando algo se elimina del índice, comparar los dos conjuntos de configuración toma minutos en lugar de una tarde.

Enlaces fragmentados que se indexan

Enlaces de salto como un ancla de tabla de contenidos pueden aparecer como URLs separadas en los resultados de búsqueda. Los motores de búsqueda generalmente pliegan estos en la página principal, pero cuando no lo hacen, el mismo contenido puede aparecer bajo varias direcciones. Dividen las señales de la página principal y pueden parecer páginas duplicadas en un informe de cobertura. Las URLs con hash se multiplican en silencio.

Una versión, una dirección. Una etiqueta canonical que apunta a una dirección mientras el sitemap lista otra envía señales mixtas, y el informe mostrará la discrepancia. Establece una versión canonical de cada página y confirma que el sitemap lista la misma versión.

Verifica el informe de cobertura después del lanzamiento para URLs con un hash en ellas, porque esas son las que se multiplican en silencio. Los hashes son los culpables.

Un subdominio que se convierte en el dominio principal

Mover un sitio de un subdominio de staging al dominio principal trae duplicados por sí mismo, porque ambas versiones pueden permanecer accesibles durante un tiempo. Decide cuál es el host canónico antes del lanzamiento. Elige el host temprano.

Un host, en todas partes. Cuando un host cambia en un lugar y no en otro, la versión más antigua puede seguir recopilando enlaces durante meses sin que nadie lo note. Luego, mantén el sitemap, las etiquetas canonical y cualquier conjunto hreflang apuntando a ese único host.

Enlaces do-follow que parecen desaparecer

Después de un rediseño, las filas do-follow en una herramienta pueden caer drásticamente, y la primera suposición es que los enlaces se han ido. Compara las páginas principales antiguas con las nuevas antes de aceptar esa suposición, luego verifica si cada dirección antigua ahora redirige correctamente. Verifica antes de entrar en pánico.

Arregla eso primero. Un enlace que aún existe en la página enlazante pero apunta a una dirección muerta es el caso a arreglar primero.

Establece la fecha temprano. Dale al equipo una fecha fija para la comparación, para que nadie vuelva a ejecutar la extracción todos los días y lea ruido como noticias.

Trabajar con un desarrollador durante el cambio

La mayor parte del trabajo de redirección recae en un desarrollador, y el monitoreo recae en quien lea la hoja. Escribir la división como una tabla corta, con un nombre en cada celda, a menudo es suficiente para evitar que dos personas asuman la misma tarea. Divide esos roles en papel antes del lanzamiento, para que nadie asuma que el otro está vigilando. Los roles necesitan nombres.

Dale al desarrollador un mapa, no una lista de tareas

Una lista de tareas le dice a un desarrollador qué hacer, mientras que un mapa muestra a dónde va cada dirección antigua. Envía la tabla uno a uno con los códigos de estado y la razón de cada fila, para que los casos extremos reciban una decisión en lugar de una suposición. Las decisiones superan a las suposiciones.

Los planes de prueba vienen primero. Pide un plan de prueba corto que comience con las direcciones antiguas del archivo de páginas principales.

Acuerda quién lee el archivo mensual

La primera comparación limpia viene sobre dos actualizaciones después del lanzamiento, y el archivo necesitará un lector. La primera lectura después del lanzamiento suele ser ruidosa, y un lector que sepa eso evitará reaccionar a un mes inusual. Nombra a esa persona, el día que lo abre y la hoja donde va el resultado. Alguien tiene que hacerse cargo.

Las fechas resuelven la pregunta. Escribir la fecha de actualización junto a cada archivo convierte una preocupación por un índice atascado en un hecho claro sobre el calendario. Un mes plano es fácil de malinterpretar como uno atascado a menos que alguien anote las fechas de actualización.

Pide a esa persona que escriba una línea por actualización, incluso cuando nada cambió, para que el archivo mantenga un registro continuo. Una línea cada vez.

Planifica la reversión antes del lanzamiento

Si el nuevo host rompe una ruta crítica, el equipo necesita una forma de volver atrás que haya sido probada con anticipación. Escribe los pasos, incluyendo quién puede dar el paso y cómo se comportan las redirecciones mientras se deshace. Ensáyalo antes del lanzamiento.

Escribe la reversión. Una reversión que existe solo en la cabeza de una persona no es un plan.