Migrating International websites, by Aleyda Solis

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.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *