Las migraciones pueden ser muy dolorosas si el SEO no está en el roadmap desde el principio. Y requiere una gran identificación de patrones, sus configuraciones, las configuraciones técnicas, qué no debe cambiar y qué si debe cambiar.

Pero no es solo una cosa de la web propiamente, sino que tenemos que tener en cuenta las señales de geolocalizacion de contenidos o links,… ¿Qué pasa con las webs y su relevancia en un determinado país? ¿Qué pasa si consolidamos muchos países en una sola URL?

Crítico: ¿Seguro que necesitas migrar?

Estas serían las cuestiones por las cuales se podría pensar en hacer una de estas migraciones.

1. Para empezar a targetizar audiencias internacionales.
2. Para rebajar la complejidad técnica.
3. Para consolidar las versiones internacionales.

Los objetivos a conseguir deben estar alineadas con la relevancia a adquirir, no porque tus clientes digan que  mejor un ccTLD es mejor. Una de las ideas fundamentales es si tenemos que intentar trabajar con otros países (y mover el contenido local a un ccTLD y dejar el .com para el target internacional). Pero no es una cuestión “solo” de uso de ccTLD, sino de targetizar lo mismo que tu estrategia de marketing.

1. Para empezar a targetizar audiencias internacionales: están intentando acceder a mercados con el dominio incorrecto (ccTLD intentando posicionar en mercado US o país diferente al del ccTLD)
   1. .co.uk -> .com/uk/ & .com/us/ & .com/fr/
2. Para rebajar la complejidad técnica: tener muchas versiones internacionales es muy costoso en recursos técnicos es buena idea consolidar las URLs.
   1. .co.uk -> .com/uk/ & .it -> .com/it/ & .fr -> .com/fr/
3. Para consolidar las versiones internacionales: no tiene sentido si no vamos a personalizar las estrategias locales (geolocalización específica para cada uno de los negocios)
   1. .es -> .com/es/ & .mx -> .com/es/ & .com.ar -> .com/es/

¿Qué usa Google?

• Search Console
• ccTLD
• hreflang
• Server location (IP del servidor)
• Otras señales

¿Y cómo crawlea Google?

Hay que recordar que el crawler envía un request HTP con Accept-Language, por lo que es importante indentificar al crawler y mostrarle la versión que nos interesa configurar.

Pero no nos quedemos aquí, tengamos en cuenta qué podemos mujar:

• Titulos relevantes
• Jerarquía
• Velocidad
• Contenido duplicado
• Crear las nuevas URLs que nos permitan recibir la relevancia de URLs que no tenemos en las nuevas arquitecturas.

¿Qué herramientas podemos usar?

• Crawler (screaming, fandangoSEO, OnCrawl)
  • Identificar URLs que no están en la arquitectura, páginas huérfanas,…
• Tráfico (URLProfiler)
• Populaidad (Links)
• Crawler (otra vez) para ver cuales son los cambios a la nueva URL (y si hay URLs que estén dando 404).
• Validar en un entorno seguro.
• Search Console para geolocalizar (o no) la nueva versión. E informar que la antigua web recibe los datos de la web antigua.