SEO internacional: ¿Qué es el problema de la página home?

1) Toda empresa que hace posicionamiento web en buscadores internacional se enfrenta a una serie de problemas que va a poder resolver de distintas formas. 

A pesar de los abundantes publicados, el posicionamiento en buscadores de sitios Web multi-idioma y multirregionales presenta para el profesional del posicionamiento web múltiples desafíos y desafíos, en tanto que son enormemente variados los escenarios que se pueden presentar y es difícil hallar soluciones específicas, contrastadas y probadas que sean trasladables de manera directa de unos casos a otros.

La casuística es tan variada que, pese a las múltiples recomendaciones a favor o bien contra un tipo o bien otro de despliegue, al final es responsabilidad del posicionamiento en buscadores el valorar las múltiples variables involucradas en un proyecto para adoptar la mejor solución a cada caso específico.

Solución que, habitualmente, suele ser de compromiso entre lo óptimamente recomendable desde el punto posicionamiento SEO, lo técnicamente posible y lo corporativamente deseable.

2) ¿Tu lugar está en varios idiomas?

Aprende a administrar un sitio multilingüe

Please specify a valid domain, y también.g., www.example.com

Back to top

1) El problema de la página home en sitios Web multiidioma y multirregionales

No obstante, hay un aspecto concreto sobre lo que no es tan simple encontrar información y es lo que llamamos aquí “el problema de la página home”.

En efecto: en un lugar Web que cuenta con múltiples versiones de idiomas, aun con versiones concretas para países y mercados específicos, ¿cuál es el contenido que debería residir en la raíz del dominio, en la página home por defecto?

O, mejor todavía: ¿debería o bien no haber algún contenido en la página home si resulta que disponemos de páginas por defecto para cada país y también idioma en concreto?

Aunque, como ya hemos comentado, la casuística que se puede presentar es casi infinita, a efectos de este blog post vamos a considerar que hemos optado por un despliegue de versiones internacionales en subdirectorios, estructura que sería, siempre y en toda circunstancia y por defecto, mi opción preferida.

En este caso, podríamos contar con versiones estructuradas en forma de subdirectorios por idioma (por servirnos de un ejemplo, http://www.midominio.com/es/, http://www.midominio.com/en/, etcétera) o bien subdirectorios por idioma/país (por poner un ejemplo, http://www.midominio.com/es/MX/ o bien http://www.midominio.com/es-MX/).

Y, en todos y cada caso, configuraríamos la orientación geográfica desde Google Search Console y los elementos de link hreflang/alternate conforme correspondiese si deseamos enfocarnos o bien no a un país específico.

En este escenario, tendríamos en cada subdirectorio la página por defecto de esa versión.

Así, en el primer caso, en http://www.midominio.com/es/ tendríamos la página por defecto para nuestra audiencia en español y en http://www.midominio.com/en/ la página por defecto para nuestra audiencia en inglés.

Mientras que, en el segundo, tendríamos la página por defecto para nuestra audiencia de México en http://www.midominio.com/es/MX/ o en http://www.midominio.com/es-MX/.

¡Perfecto!

Salvo por un detalle: ¿qué contenido hallaría el usuario en la raíz del dominio http://www.midominio.com/?

Y lo que para un posicionamiento SEO es todavía más importante: ¿qué contenido encontraría Google en la URL que tiene el perfil de popularidad más potente del sitio Web?

A este problema es a lo que llamamos el “problema de la página home”.

Y esto es de este modo, porque la resolución no es obvia: existen muchas opciones, cada una con sus ventajas e inconvenientes.

Veamos algunas posibles soluciones:

• Pre-home con selector de idioma.
• Página en la raíz del dominio con versión de idioma o idioma/país preferente por defecto.
• Contenido adaptado en la raíz del dominio.
• URL de raíz del dominio no indexable.

Veamos qué ventajas y también inconvenientes presenta cada solución.

Back to top

2) Página pre-home con selector de idioma/país

Se trata de alojar en la raíz del dominio un selector de idioma y/o país prácticamente como único contenido protagonista.

Por ejemplo, zara.com tiene implementada esta solución y la raíz del dominio está dedicada sencillamente a establecer el idioma y el mercado del usuario.

El servidor analiza la IP y el user-agent del usuario para establecer las opciones por defecto del selector, con lo que una vez confirmadas estas opciones quedan almacenadas en la cookie del navegador.

Así, la próxima vez que el usuario navegue a la raíz del dominio, la configuración de su cookie servirá para activar un redireccionamiento cara el subdirectorio, por ejemplo, correspondiente a España en español: www.zara.com/es/es.

2.1) Ventajas

• Permite establecer variables de idioma y de mercado para configurar adecuadamente el portfolio de producto, moneda, costos, impuestos aplicables, opciones de envío y otras múltiples variables que precisa una tienda en línea para marchar adecuadamente.
• Al guardar estas variables en una cookie, las siguientes visitas del usuario lo llevan a la versión correcta de una manera bastante transparente, lo que favorece el engagement y la conversión.
• Ninguna versión “pesa” más que las demás en cuanto a concentración de la popularidad, en tanto que la raíz del dominio distribuye su popularidad entre las diferentes versiones de forma equitativa si incluye links a todas ellas (como vemos en la versión en caché de Google de la home de Zara):

La raíz del dominio de Zara.com incluye links que permiten a los buscadores web descubrir el resto de versiones.

2.2) Inconvenientes

• Normalmente, la raíz de un dominio es la URL que más enlaces –internos y externos– recibe. Al incluir sólo el selector de idioma/país como primordial contenido de esta URL, de alguna manera estamos desaprovechando la fuerza de nuestra URL más potente que se diluye al distribuirse entre las múltiples homes de cada país.
• Añade un click extra al usuario que visita la Web por vez primera desde que entra en la raíz del dominio hasta que llega verdaderamente a los productos que le pueden interesar. Y sabemos que cuanto menos clicks de distancia haya entre la home y una página cualquiera, mejor es el posicionamiento y también la conversión.
• Si condicionamos la navegación a la existencia de estas cookies o bien variables de sesión (por servirnos de un ejemplo, forzando una redirección a la raíz del dominio para que el usuario establezca sus opciones de idioma y país), es posible que la araña de los motores de búsqueda tenga problemas para rastrear adecuadamente el sitio puesto que no aceptan cookies.

2.3) ¿En qué momento es conveniente esta opción?

• Cuando la audiencia está muy fragmentada en múltiples países y no hay ningún país que concentre una cuota de nuestra demanda significativamente mayor que el resto.
• Cuando las variables de idioma y país son determinantes en el momento de personalizar la oferta: géneros de productos ofertados, familias disponibles, divisa, costos, opciones de envío, impuestos aplicables, etc.
• Cuando el reconocimiento de la marca por la parte de los usuarios reduce la proporción habitual de tráfico orgánico, por lo que la dependencia de un buen posicionamiento para buscas genéricas es menor.
• Cuando la autoridad del dominio es tan grande que, pese a diluirse la popularidad de la raíz del dominio en múltiples subdirectorios, estos aún cuentan con una ventaja con respecto a sus contendientes.

2.4) ¿Qué debemos tomar en consideración?

• Debemos establecer contenido “por defecto” que los motores de búsqueda puedan rastrear en ausencia de cookies o variables de sesión.
• Debemos tener en consideración de qué forma afecta la personalización que pudiera introducir el servidor basándonos en la IP de origen o bien el usuario-agent del navegador de manera que los usuario-agents e IP de origen de los robots de los buscadores no impidan que el lugar se pueda rastrear en sus múltiples versiones.
• En las diferentes homes de cada versión (y solo ahí), deberíamos configurar el factor de link alternate/hreflang apuntando a la raíz del dominio con la opción “x-default” (aparte de los pertinentes alternate/hreflang a las homes de las demás versiones).
• En la raíz del dominio, incluiremos elementos de link alternate/hreflang apuntando a la home de cada versión aparte del propio alternate/hreflang apuntando cara sí mismo.
• En este caso, la página home que acostumbra a enseñar Google cuando hacemos una busca de marca (por ejemplo, “zara”) es la indicada en el correspondiente alternate/hreflang. Por eso, para Zara muestra como home www.zara.com/es.

Back to top

3) Página con versión de idioma o bien idioma/país preferente por defecto

Se trata de alojar en la raíz del dominio la página home por defecto para el primordial mercado de la empresa.

Por ejemplo, apple.com presenta en la raíz del dominio la página home de su sitio Web para el mercado americano por defecto y cualquier otro país “cuelga” de su correspondiente subdirectorio.

Por ejemplo, en www.apple.com/es encontramos el lugar Web para España con su correspondiente home mientras que si introducimos sencillamente www.apple.com hallamos la página por defecto para el mercado norteamericano.

3.1) Ventajas

• En comparación con la opción precedente, alojar la página por defecto de nuestro primordial mercado en la raíz del dominio cuenta con el beneficio de respaldar dicho contenido con la fuerza de la popularidad de la URL que más links amontona en el sitio Web. Como coincide con nuestro principal mercado, puede decirse que con esta alternativa estamos defendiendo un mejor posicionamiento en el país donde mayor potencial de venta existe.
• Acorta la distancia en clics desde que un usuario llega por vez primera al lugar Web hasta el momento en que ve algo que le interesa. Al prescindir del selector de idioma, el usuario queda expuesto desde el primer instante a nuestros productos, promociones, etcétera lo que favorece un mayor engagement, menor ratio de rebote desde la home, mejor conversión, etc.
• Concentra el mayor peso de popularidad en la versión que compite en el mercado más jugoso para la marca.
• Tanto los usuarios como los buscadores pueden navegar por el sitio Web sin necesidad de cookies o bien variables de sesión, con lo que se minimiza el riesgo de problemas de indexabilidad.

3.2) Inconvenientes

• Un usuario que no entienda el idioma de la versión primordial puede verse un tanto perdido hasta hallar el selector de idioma/país para poder navegar a su versión.
• Los usuarios tienen mucho más fácil navegar por las distintas versiones y equiparar los precios de los diferentes productos en los diferentes mercados. Algo que acostumbra a incomodar a los dueños de tiendas on line donde las diferencias de precio entre países pueden despertar suspicacias entre los compradores.

3.3) ¿En qué momento es conveniente esta alternativa?

• Cuando uno de los mercados a los que nos dirigimos concentra una gran cuota de la demanda total, por lo que merece la pena priorizar el posicionamiento de una versión determinada de todas y cada una de las disponibles.
• Cuando se desea identificar corporativamente un sitio Web con un determinado país como origen de una compañía o identficación nacional de una corporación.

3.4) ¿Qué debemos tomar en consideración?

• En este caso, no hay problema en el rastreo del sitio Web en ausencia de cookies o bien variables de sesión.
• En principio, no es conveniente configurar ningún elemento de link alternate/hreflang con la opción x-default de contenido por defecto. Sólo sería recomendable prever directorios de contenido por defecto en cada idioma para dirigir a los usuarios para los que no hay una versión específica para su país. Por poner un ejemplo, apple.com dispone del subdirectorio /lae/ enfocado a todo el público sudamericano que navega en inglés y que no se corresponde con ningún otro directorio de país de esta área geográfica.

Back to top

4) Contenido personalizado

Este escenario corresponde con un sitio Web alojado en un servidor en el que hemos implementado algún tipo de sniffer que pueda identificar la IP del usuario, el idioma del navegador y/o sistema operativo del usuario y realizar algún género de personalización del contenido de la home. En un caso así, esta personalización se correspondería con presentar la home pertinente a la IP y/o idioma del usuario.

Desde la perspectiva del usuario, la experiencia de verse recibido en la raíz del dominio con contenido relevante para su localización y también idioma, por supuesto, es positiva.

El problema brota con el rastreo por parte de los motores de búsqueda.

En efecto, si bien desde dos mil quince Google rastrea desde distintas IP en todo el mundo, la mayor parte de sus visitas procede aún desde IP geolocalizadas en E.U. y el usuario-agent de sus rastreadores se identifica como un usuario que navega en inglés, con lo que deberemos tener en consideración estos 2 aspectos porque, en este caso, influiría sobre la versión “por defecto” que vería Google.

Es decir, que mientras que cada usuario vería un contenido propio para su país y/o idioma, Google encontraría en la raíz del dominio la home pertinente a la que mostraría el servidor a un usuario de Norteamérica, en caso de que exista una versión apropiada a ese perfil.

Y, desde los links al resto de las versiones, hallaría el resto de las homes de exactamente las mismas.

Como conclusión: esta implementación se parecería a la precedente en que Google rastrearía una versión como “preferente” y todo el resto como “secundarias”.

Sólo que en el caso anterior decidimos qué versión priorizamos y, en este caso, la versión rastreada como prioritaria depende de factores más complejos y difíciles de prever.

4.1) Ventajas

• La principal ventaja radica en la mejor experiencia de usuario. Cualquier persona desde cualquier país y también idioma va a acceder de forma directa en la raíz del dominio al contenido que hemos preparado específicamente para esa audiencia.

4.2) Inconvenientes

• Es más difícil supervisar de qué manera rastrearán los buscadores el lugar Web puesto que sus robots pueden identificarse como usuarios que llegan desde diferentes IP y geolocalizaciones, así como navegadores configurados en diferentes idiomas.
• Si el lugar se rastrea sucesivamente desde IPs distintas, posiblemente la raíz del dominio se indexe de forma alternativa en distintos idiomas.
• Existe un riesgo de detección de entre el contenido rastreado en la home de la raíz (por ejemplo, www.midominio.com) que sería el que vería Google por defecto, y el correspondiente a la home para EEUU (por ejemplo, www.midominio.com/us).
• Si se opta por incluir elementos de enlace canonical activos, entonces perderemos la popularidad de la URL correspondiente a la raíz del dominio, puesto que no se indexará.

4.3) ¿Cuándo es conveniente esta alternativa?

• Cuando se da máxima prioridad a la y el sitio Web se apoya en medios de generación de tráfico que hacen que el peso del tráfico desde buscadores sobre el total sea sólo relativo.
• Si se opta por incorporar elementos de enlace canonical dinámicos, entonces la URL de la raíz del dominio no se indexará, y el escenario se comportará tal como se describe en el caso siguiente.

4.4) ¿Qué debemos tener en consideración?

• Si el mercado norteamericano no es nuestro mercado prioritario o no tenemos una versión específica para este mercado, debemos prever qué contenido por defecto va a mostrar el servidor cuando no pueda hallar las variables que necesita para personalizar el contenido, puesto que de esta manera será como lo rastreará Google.
• En este escenario, podría indexarse contenido en diferentes idiomas bajo la misma URL (consecutivas visitas del robot de Google desde IP geolocalizadas en países diferentes) o bien podría indexarse el mismo contenido con dos URL diferentes (contenido copiado) al hallar Google el mismo contenido por defecto en la raíz del dominio y en la home del subdirectorio orientado al mercado norteamericano. 
• Por ello, es conveniente incluir un factor de link canonical dinámico apuntando a la URL preceptiva que correspondería a cada caso. De esta forma, cuando Google rastreara el contenido “norteamericano” en la raíz del dominio encontraría el canonical apuntando a www.midominio.com/us/, e indexaría ese contenido no bajo la URL raíz del dominio sino con la URL del subdirectorio correspondiente (lo que evitaría el contenido copiado mas, al mismo tiempo, desindexaría la raíz del dominio).

Back to top

5) URL no indexable

Este último escenario mezcla aspectos de los descritos anteriormente.

Veamos.

En este escenario, la URL correspondiente a la raíz del dominio no se indexa.

Esto puede suceder por la configuración de algún tipo de redirección en la raíz del dominio (a menudo, adaptada de forma afín al escenario precedente de acuerdo con la geolocalización de la IP o bien el idioma identificado en el user-agent del navegador) o bien por la implementación de elementos de link canonical apuntando a las URLs correspondientes a las distintas versiones.

En este caso, ningún contenido capitalizará la popularidad de la URL con mayor número de links entrantes del dominio (la raíz del dominio), por lo que en este aspecto se comportará como el escenario en que dedicamos la página por defecto a alojar un simple selector de idioma/país.

5.1) Ventajas

• La redirección personalizada es casi transparente para el usuario, por lo que éste va a percibir una experiencia de usuario, a nivel de contenido, tan satisfactoria como en la personalización de la página home del escenario anterior.

5.2) Inconvenientes

• Si todas las redirecciones son 301, la raíz del dominio no se indexará, con lo que vamos a perder la popularidad de la página con mayor peso del dominio.
• La detección de IP/idioma de la consulta y la posterior redirección introducirán un retraso auxiliar en el acceso del usuario al contenido.

5.3) ¿En qué momento es conveniente esta alternativa?

• Cuando estamos empleando algún género de gestor de contenidos que requiere “arrancar” desde un subdirectorio o hay algún otro condicionante técnico que demanda este funcionamiento.

5.4) ¿Qué debemos tener en cuenta?

• Si personalizamos redirecciones en la home para redirigir al usuario hacia la home del subdirectorio correspondiente a su geolocalización por IP y/o idioma, entonces esas redirecciones deberían ser siempre redirect 301.
• Alternativamente, y si quisiésemos que alguna de las versiones fuera identificada como la versión por defecto, esa redirección podría ser 302. En un caso así, el canonical de la home de ese subdirectorio debería apuntar a la raíz del dominio. Solo una de las versiones debería estar configurada de esta manera, y los elementos de enlace alternate/hreflang habrían de estar configurados coherentemente con dicha configuración (todos ellos apuntando a cada subdirectorio, salvo el definido por defecto, que debería apuntar a la raíz del dominio). Como es lógico, aquí nos saldríamos de este escenario puesto que la raíz del dominio sí se indexaría.

5.5) Conclusión: no hay solución obvia

A la hora de revisar todo este género de comportamientos en el servidor, son muy útiles herramientas como HMA! VPN y HTTP Sniffer, que dejan alterar nuestra IP así como nuestro usuario-agent.

También es muy útil emplear extensiones como Web Developer for Mozilla Firefox que nos permite bloquear las cookies o aun editar sus valores.

Jugando con todos estos elementos podremos identificar las diferentes configuraciones de personalización del servidor y nos será más sencillo comprender de qué manera está rastreando Google los contenidos.

Si, en lugar de examinar la indexabilidad de una configuración ya incorporada, nuestro papel es ofrecer las recomendaciones sobre cuál es la configuración más adecuada para configurar el posicionamiento internacional adecuado en buscadores web internacionales como o Google, es fundamental examinar cada escenario, qué aspecto debemos priorizar en todos y cada caso y cuáles son las demandas de nuestra infraestructura tecnológica para elegir la opción más conveniente para nuestra página home.

Back to top