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

1) Toda empresa que hace posicionamiento en buscadores internacional se enfrenta a una serie de inconvenientes que podrá solucionar de diferentes formas. 

A pesar de los numerosos publicados, el posicionamiento en buscadores de sitios Web multi-idioma y multirregionales presenta para el profesional del SEO múltiples desafíos y retos, ya que son enormemente variados los escenarios que se pueden presentar y es bastante difícil encontrar soluciones concretas, contrastadas y demostradas que sean trasladables de manera directa de unos casos a otros.

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

Solución que, frecuentemente, acostumbra a ser de compromiso entre lo óptimamente aconsejable desde el punto posicionamiento web, 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, e.g., www.example.com

Back to top

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

No obstante, hay un aspecto concreto sobre lo que no es tan simple hallar información y es lo que llamamos aquí “el inconveniente 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 radicar 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 e idioma específicamente?

Aunque, como ya hemos comentado, la casuística que se puede presentar es casi infinita, a efectos de este post vamos a estimar 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.) o bien subdirectorios por idioma/país (por ejemplo, http://www.midominio.com/es/MX/ o 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 enlace hreflang/alternate conforme correspondiera si queremos 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 castellano 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 bien en http://www.midominio.com/es-MX/.

¡Perfecto!

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

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

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

Y esto es de esta forma, porque la decisió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 bien 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 incorporada esta solución y la raíz del dominio está dedicada simplemente a establecer el idioma y el mercado del usuario.

El servidor analiza la IP y el usuario-agent del usuario para establecer las opciones por defecto del selector, por lo que una vez confirmadas estas opciones quedan guardadas 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 hacia el subdirectorio, por servirnos de un 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 porfolio de producto, moneda, costos, impuestos aplicables, opciones de envío y otras múltiples variables que precisa una tienda on-line para marchar adecuadamente.
• Al almacenar estas variables en una cookie, las siguientes visitas del usuario lo llevan a la versión adecuada 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 lo que se refiere 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 y cada una (como vemos en la versión en caché de Google de la home de Zara):

La raíz del dominio de Zara.com incluye enlaces que permiten a los motores de búsqueda 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 solo el selector de idioma/país como primordial contenido de esta URL, de alguna forma 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 clic extra al usuario que visita la Web por primera vez desde el momento en que entra en la raíz del dominio hasta el momento en que llega verdaderamente a los productos que le pueden interesar. Y sabemos que cuanto menos clics de distancia haya entre la home y una página cualquiera, mejor es el posicionamiento y asimismo la conversión.
• Si condicionamos la navegación a la existencia de estas cookies o variables de sesión (por poner 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 buscadores tenga problemas para rastrear apropiadamente el sitio puesto que no aceptan cookies.

2.3) ¿Cuándo es recomendable esta opción?

• Cuando la audiencia está muy fragmentada en múltiples países y no hay 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, costes, 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, a pesar de diluirse la popularidad de la raíz del dominio en múltiples subdirectorios, estos aún cuentan con una ventaja con respecto a sus competidores.

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

• Debemos establecer contenido “por defecto” que los buscadores puedan rastrear en ausencia de cookies o bien variables de sesión.
• Debemos tomar en consideración cómo afecta la personalización que pudiese introducir el servidor en base a 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 sitio 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 enlace alternate/hreflang apuntando a la raíz del dominio con la opción “x-default” (aparte de los correspondientes alternate/hreflang a las homes de las demás versiones).
• En la raíz del dominio, incluiremos elementos de enlace alternate/hreflang apuntando a la home de cada versión aparte del propio alternate/hreflang apuntando hacia sí mismo.
• En este caso, la página home que suele enseñar Google cuando hacemos una busca de marca (por servirnos de un ejemplo, “zara”) es la indicada en el pertinente alternate/hreflang. De ahí que, para Zara muestra como home www.zara.com/es.

Back to top

3) Página con versión de idioma o 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 compañía.

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 pertinente subdirectorio.

Por ejemplo, en www.apple.com/es encontramos el sitio Web para España con su correspondiente home al tiempo que si introducimos simplemente www.apple.com encontramos la página por defecto para el mercado de Norteamérica.

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 la ventaja de respaldar dicho contenido con la fuerza de la popularidad de la URL que más enlaces amontona en el lugar Web. Como coincide con nuestro primordial 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 sitio Web hasta el momento en que ve algo que le interesa. Al prescindir del selector de idioma, el usuario queda expuesto desde el primer momento 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 motores de búsqueda pueden navegar por el lugar Web sin necesidad de cookies o variables de sesión, con lo que se minimiza el peligro de inconvenientes de indexabilidad.

3.2) Inconvenientes

• Un usuario que no comprenda el idioma de la versión principal 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 diferentes versiones y comparar los costos de los diferentes productos en los diferentes mercados. Algo que acostumbra a molestar a los dueños de tiendas virtuales donde las diferencias de coste entre países pueden despertar suspicacias entre los compradores.

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

• Cuando uno de los mercados a los que nos dirigimos concentra una enorme cuota de la demanda total, con lo que vale la pena priorizar el posicionamiento de una versión determinada de todas las libres.
• Cuando se quiere identificar corporativamente un sitio Web con un determinado país como origen de una compañía o identficación nacional de una institució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 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. Solo sería recomendable prever directorios de contenido por defecto en todos y cada idioma para dirigir a los usuarios para los que no hay una versión concreta para su país. Por servirnos de un ejemplo, apple.com dispone del subdirectorio /lae/ enfocado a todo el público latinoamericano 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 lugar Web alojado en un servidor en el que hemos incorporado algún género 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 correspondiente 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 ubicación e idioma, lógicamente, es positiva.

El inconveniente brota con el rastreo por parte de los buscadores.

En efecto, aunque desde dos mil quince Google rastrea desde diferentes IP en todo el mundo, la mayor parte de sus visitas procede todavía 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 tendremos que tener en consideración estos 2 aspectos por el hecho de que, en este caso, influiría sobre la versión “por defecto” que vería Google.

Es decir, que al paso que cada usuario vería un contenido propio para su país y/o idioma, Google hallarí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, a partir de los links al resto de las versiones, encontrarí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 precedente 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 e idioma va a acceder directamente en la raíz del dominio al contenido que hemos preparado específicamente para esa audiencia.

4.2) Inconvenientes

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

4.3) ¿Cuándo es recomendable esta alternativa?

• Cuando se da máxima prioridad a la y el lugar Web se apoya en medios de generación de tráfico que hacen que el peso del tráfico orgánico sobre el total sea solo relativo.
• Si se opta por implementar elementos de link canonical activos, 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 cuenta?

• Si el mercado de Norteamérica no es nuestro mercado prioritario o bien 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 forma va a 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 exactamente 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 recomendable incluir un factor de link canonical dinámico apuntando a la URL preceptiva que correspondería a cada caso. Así, 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 más bien con la URL del subdirectorio correspondiente (lo cual evitaría el contenido duplicado 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 género de redirección en la raíz del dominio (habitualmente, adaptada de forma afín al escenario anterior de acuerdo con la geolocalización de la IP o el idioma identificado en el usuario-agent del navegador) o bien por la implementación de elementos de enlace 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, con 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 precedente.

5.2) Inconvenientes

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

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

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

5.4) ¿Qué debemos tener en cuenta?

• Si personalizamos redirecciones en la home para redirigir al usuario cara la home del subdirectorio pertinente a su geolocalización por IP y/o idioma, entonces esas redirecciones deberían ser siempre y en todo momento redirect trescientos uno.
• Alternativamente, y si quisiéramos que ciertas versiones fuera identificada como la versión por defecto, esa redirección podría ser trescientos dos. 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 habría de estar configurada de esta manera, y los elementos de enlace alternate/hreflang deberían estar configurados congruentemente con dicha configuración (todos ellos apuntando a cada subdirectorio, excepto el definido por defecto, que debería apuntar a la raíz del dominio). Como es natural, aquí nos saldríamos de este escenario pues 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 tipo de comportamientos en el servidor, son muy útiles herramientas como HMA! VPN y HTTP Sniffer, que dejan alterar nuestra IP como nuestro usuario-agent.

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

Jugando con todos estos elementos vamos a poder identificar las diferentes configuraciones de personalización del servidor y nos va a ser más fácil comprender de qué manera está rastreando Google los contenidos.

Si, en lugar de analizar la indexabilidad de una configuración ya implementada, nuestro papel es ofrecer las recomendaciones sobre cuál es la configuración más conveniente para configurar el posicionamiento internacional correcto en buscadores web internacionales como o Google, es muy importante analizar 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 adecuada para nuestra página home.

Back to top