logo-small
Funciones Precios
Noticias 0
Últimas noticias Ver todos

No disponible temporalmente. Por favor, visítanos en otro momento.

Ver todos
Webinars 0
Próximos webinars Ver todos
Próximos webinars

Lo sentimos, no se han podido encontrar próximos webinars.

Visualiza los webinars grabados
Blog 0
Posts recientes Ver todos

No disponible temporalmente. Por favor, visítanos en otro momento.

Ver todos
Fernando Maciá Domene

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

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

Toda empresa que hace SEO internacional se enfrenta a una serie de problemas que podrá resolver de distintas formas. 

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

La casuística es tan variada que, a pesar de las múltiples recomendaciones a favor o 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, suele ser de compromiso entre lo óptimamente recomendable desde el punto SEO, lo técnicamente posible y lo corporativamente deseable.

El problema de la página home en sitios Web multi-idioma y multirregionales

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

En efecto: en un sitio Web que cuenta con múltiples versiones de idiomas, incluso con versiones específicas para países y mercados concretos, ¿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 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 en concreto?

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

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

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

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 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 SEO es aún 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 dilema es a lo que denominamos el “problema de la página home”.

Y esto es así, porque la decisión no es obvia: hay 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 personalizado en la raíz del dominio.
  • URL de raíz del dominio no indexable.

Veamos qué ventajas e inconvenientes presenta cada solución.

SEO internacional - Opciones página home

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 casi como único contenido protagonista.

Por ejemplo, zara.com tiene implementada 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 user-agent del usuario para establecer las opciones por defecto del selector, por 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 hacia el subdirectorio, por ejemplo, correspondiente a España en español: www.zara.com/es/es.

Ventajas

  • Permite establecer variables de idioma y de mercado para configurar correctamente el portfolio de producto, moneda, precios, impuestos aplicables, opciones de envío y otras múltiples variables que precisa una tienda online para funcionar correctamente.
  • Al almacenar estas variables en una cookie, las siguientes visitas del usuario lo llevan a la versión correcta de una forma 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, ya que la raíz del dominio distribuye su popularidad entre las distintas versiones de forma equitativa si incluye enlaces a todas ellas (como vemos en la versión en caché de Google de la home de Zara):

Version de texto de la caché de la raíz del dominio zara.comLa raíz del dominio de Zara.com incluye enlaces que permiten a los buscadores descubrir el resto de versiones.

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 principal contenido de esta URL, de alguna manera estamos desperdiciando 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 primera vez desde que entra en la raíz del dominio hasta que llega realmente 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 variables de sesión (por 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 correctamente el sitio ya que no aceptan cookies.

¿Cuándo es recomendable 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 a la hora de personalizar la oferta: tipos de productos ofertados, familias disponibles, divisa, precios, opciones de envío, impuestos aplicables, etc.
  • Cuando el reconocimiento de la marca por parte de los usuarios reduce la proporción habitual de tráfico orgánico, por lo que la dependencia de un buen posicionamiento para búsquedas 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, éstos aún cuentan con una ventaja respecto a sus competidores.

¿Qué debemos tener en cuenta?

  • Debemos establecer contenido “por defecto” que los buscadores puedan rastrear en ausencia de cookies o variables de sesión.
  • Debemos tener en cuenta cómo afecta la personalización que pudiera introducir el servidor en base a la IP de origen o el user-agent del navegador de forma que los user-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 distintas homes de cada versión (y sólo ahí), deberíamos configurar el elemento de enlace alternate/hreflang apuntando a la raíz del dominio con la opción “x-default” (además 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 además del propio alternate/hreflang apuntando hacia sí mismo.
  • En este caso, la página home que suele mostrar Google cuando hacemos una búsqueda de marca (por ejemplo, “zara”) es la indicada en el correspondiente alternate/hreflang. Por eso, para Zara muestra como home www.zara.com/es.

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 principal 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 sitio Web para España con su correspondiente home mientras que si introducimos simplemente www.apple.com encontramos la página por defecto para el mercado norteamericano.

Ventajas

  • En comparación con la opción anterior, alojar la página por defecto de nuestro principal 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 acumula en el sitio Web. Como coincide con nuestro principal mercado, puede decirse que con esta opción estamos defendiendo un mejor posicionamiento en el país donde mayor potencial de venta existe.
  • Acorta la distancia en clicks desde que un usuario llega por primera vez al sitio Web hasta 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. lo cual 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 variables de sesión, por lo que se minimiza el riesgo de problemas de indexabilidad.

Inconvenientes

  • Un usuario que no entienda el idioma de la versión principal puede verse un poco perdido hasta encontrar 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 comparar los precios de los distintos productos en los distintos mercados. Algo que suele incomodar a los propietarios de tiendas online donde las diferencias de precio entre países pueden despertar suspicacias entre los compradores.

¿Cuándo es recomendable esta opción?

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

¿Qué debemos tener en cuenta?

  • 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 recomendable configurar ningún elemento de enlace 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 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.

Posicionamiento SEO para audiencias internacionalesA veces, es preciso priorizar la experiencia del usuario por encima de criterios SEO.

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 tipo de personalización del contenido de la home. En este caso, 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 localización e idioma, por supuesto, es positiva.

El problema surge con el rastreo por parte de los buscadores.

En efecto, aunque desde 2015 Google rastrea desde distintas IP en todo el mundo, la mayoría de sus visitas procede todavía desde IP geolocalizadas en Estados Unidos y el user-agent de sus rastreadores se identifica como un usuario que navega en inglés, por lo que tendremos que tener en cuenta estos dos 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 correspondiente a la que mostraría el servidor a un usuario norteamericano, en caso de que exista una versión apropiada a ese perfil.

Y, a partir de los enlaces al resto de las versiones, encontraría el resto de las homes de las mismas.

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

Sólo que en el caso anterior nosotros estamos decidiendo 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.

Ventajas

  • La principal ventaja reside en la mejor experiencia de usuario. Cualquier persona desde cualquier país e idioma accederá directamente en la raíz del dominio al contenido que hemos preparado específicamente para esa audiencia.

Inconvenientes

  • Es más difícil controlar cómo rastrearán los buscadores el sitio Web pues sus robots pueden identificarse como usuarios que llegan desde distintas IP y geolocalizaciones, así como navegadores configurados en distintos idiomas.
  • Si el sitio se rastrea sucesivamente desde IPs distintas, es posible que la raíz del dominio se indexe alternativamente en distintos idiomas.
  • Existe un riesgo de detección de contenido duplicado 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 dinámicos, entonces perderemos la popularidad de la URL correspondiente a la raíz del dominio, pues no se indexará.

¿Cuándo es recomendable esta opción?

  • Cuando se da máxima prioridad a la experiencia de usuario y el sitio 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 sólo relativo.
  • Si se opta por implementar elementos de enlace canonical dinámicos, entonces la URL de la raíz del dominio no se indexará, y el escenario se comportará tal y como se describe en el caso siguiente.

¿Qué debemos tener en cuenta?

  • 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 mostrará el servidor cuando no pueda encontrar las variables que necesita para personalizar el contenido, pues así será como lo rastreará Google.
  • En este escenario, podría indexarse contenido en distintos idiomas bajo la misma URL (sucesivas visitas del robot de Google desde IP geolocalizadas en países distintos) o bien podría indexarse el mismo contenido con dos URL distintas (contenido duplicado) al encontrar 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 elemento de enlace canonical dinámico apuntando a la URL canónica 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 con la URL del subdirectorio correspondiente (lo cual evitaría el contenido duplicado pero, al mismo tiempo, desindexaría la raíz del dominio).

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 ocurrir por la configuración de algún tipo de redirección en la raíz del dominio (frecuentemente, personalizada de forma similar al escenario anterior de acuerdo con la geolocalización de la IP o el idioma identificado en el user-agent del navegador) o 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 enlaces 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.

Ventajas

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

Inconvenientes

  • Si todas 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 posterior redirección introducirán un retraso adicional en el acceso del usuario al contenido.

¿Cuándo es recomendable esta opción?

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

¿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éramos que alguna de las versiones fuera identificada como la versión por defecto, esa redirección podría ser 302. En ese caso, el canonical de la home de ese subdirectorio debería apuntar a la raíz del dominio. Sólo una de las versiones debería estar configurada así, y los elementos de enlace alternate/hreflang deberían estar configurados coherentemente 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). Por supuesto, aquí nos saldríamos de este escenario pues la raíz del dominio sí se indexaría.

Conclusión: no hay solución obvia

A la hora de comprobar todo este tipo de comportamientos en el servidor, son muy útiles herramientas como HMA! VPN y HTTP Sniffer, que permiten modificar nuestra IP así como nuestro user-agent.

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

Jugando con todos estos elementos podremos identificar las distintas configuraciones de personalización del servidor y nos será más sencillo entender cómo 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 adecuada para configurar el posicionamiento internacional correcto en buscadores internacionales como Yandex o Google, es muy importante analizar cada escenario, qué aspecto debemos priorizar en cada caso y cuáles son las exigencias de nuestra infraestructura tecnológica para seleccionar la opción más adecuada para nuestra página home.

Descarga

Foto (posicionamiento internacional): Shutterstock

Y tú ¿cuál crees que es la mejor solución para “el problema de la página home” al hacer seo internacional?

Fernando Maciá Domene es el fundador y director de Human Level Communications, una de las consultoras de posicionamiento Web líder en España y al frente de la cual ha dirigido numerosos proyectos de SEO internacional.

Fernando es el autor de SEO Técnicas Avanzadas (2015), Marketing online 2.0 (2013) y Técnicas avanzadas de posicionamiento en buscadores (2011) y también es coautor de Marketing en redes sociales (2016), Posicionamiento en buscadores ed. 2012 (2012), Marketing con redes sociales (2011), Marketing online (2010), Posicionamiento en buscadores ed. 2009 (2009) y Posicionamiento en buscadores (2006), todos ellos best-sellers en su especialidad de la editorial Anaya Multimedia.

Fernando es profesor en universidades y escuelas de negocio de España y Latinoamérica y ponente habitual de congresos como The Inbounder, ClinicSEO, eShow, SMX, Online Marketing Expo, Search/Web Congress, Feria de Tiendas Virtuales o E-Comm Retail.

2000 es el número máximo de caracteres permitido
Omar Rivero
Hola, Fernando; antes que nada, quiero decirte: ¡Gran artículo! Muy completo, y a pesar de ser muy técnico, muy bien explicado. Excelente. Ya lo comparto en las redes, para que se difunda. Felicidades.
En segundo lugar, quería preguntarte sobre un caso de mi experiencia; lo diré resumido para no quitarte tiempo.
La cuestión es que modifiqué la home de una web para potenciar su SEO; pero Google indexaba y rastreaba la versión en inglés; la cual era la que aparecía como resultado de búsqueda. Gracias a tu artículo, comprendo que es porque el dominio está configurado como "contenido personalizado" y google rastrea e indexa la versión en inglés. El problema es que es una web principalmente española, y los resultados se muestran en inglés como dije. Con Search Console comprobé que Google se redirecciona automáticamente la versión en inglés; cosa que solo sucede en la home.
¿Qué puedo hacer para Google muestre e indexe la versión española? Muchas gracias de antemano por la ayuda.
Fernando Maciá Domene
Por lo que comentas, en efecto, seguramente es por eso. Ten en cuenta también que hay sitios web que personalizan el contenido así y NO CAMBIAN LA URL. En este caso, Google sólo puede indexar UNA versión del sitio Web y lo hará frecuentemente en inglés, como corresponde a su iP de origen y el idioma de su user-agent. Comprueba si hay URLs distintas para cada versión, o si éstas se muestran con la misma. Si es este último caso, la única forma de lograr que Google indexe los distintos idiomas es cambiando la configuración del sitio para que haya distintas URLs para cada contenido en cada uno de los idiomas.
Omar Rivero
Fernando Maciá Domene
Gracias, gracias. He revisado. Y el dominio de la página que comento es por ejemplo así www1.example.com; más Google rastrea e indexa www1.example.com/en. Es evidente que es la versión en inglés. Es decir, una URL en para cada versión. En este caso, ¿cómo fuerzo a Google a indexar la versión en español y no la "/en"? De antemano, Gracias por tu tiempo.
Fernando Maciá Domene
Este comentario se ha borrado.
Fernando Maciá Domene
Hola Fernando.
Tenía entendido que Google termina tomando los 302 tras un tiempo como un 301. ¿Sabes si esto es correcto?
Gracias.
Fernando Maciá Domene
Antonio Ruiz
No siempre. Depende, en parte, de cómo esté enlazada y referenciada esa página. Si la URL tiene enlaces externos y, sobre todo, internos y la referencia de los hreflang también apunta a la raíz del dominio, lo más probable es que Google indexara ésta en lugar de la del destino del redirect.
Cristian Sepulveda
Fernando, excelente articulo, muy completo y explicativo. He utilizado varias de las opciones que mencionas y efectivamente depende de muchos factores la elección. Me abría gustado ver ejemplos de código.
Podrías fundamentar o explicar un poco cuando dices dentro de la opción URL No Indexable, “En ese caso, el canonical de la home de ese subdirectorio debería apuntar a la raíz del dominio”. Por que tendríamos que hacer eso en vez de apuntar canónicamente a la sub carpeta? Al definir cada sub carpeta en Google Search Console estas adquieren ribetes de Home finalmente. Cual sería entonces el objetivo de apuntar canónicamente a la raíz desde las subcarpetas en este caso?
En el caso de URL no indexable podría aportarte otro inconveniente relacionado con la IP del robot de Goolge. Este problema se produce debido a que si usamos un motor de redirecciones automáticas dependiendo de la GeoIP y la IP de Googlebot normalmente es de USA, pasa que el robot va a ser redirigido a la versión en ingles o peor aun la versión para USA si lo tenemos definido por país. Una solución sería incluir manualmente un link a la versión en español y otras versiones de lo contrario podrías tener problemas de indexabilidad para las versiones del sitio.
Fernando Maciá Domene
Cristian Sepulveda
Hola Christian. La verdad es que lo escribí en "tiempo récord" en mitad de una semana muy apretada y ya no me dió tiempo a preparar unos pantallazos con diagramas como los que suelo incluir en mis presentaciones. Muchas gracias y me alegro de que te haya gustado. Paso a contestarte.
Primera cuestión: URL no indexable. Lo que comento en ese punto es que, si en este escenario deseamos que Google considere como prioritaria una de las opciones, entonces el redirect de la home sería en todos los casos 301 a la home de cada subdirectorio que corresponda EXCEPTO cuando es a la home que queremos darle más importancia. Sólo en ese caso sería un redirect 302. Ojo: con el 301 estamos indicando que no queremos que se indexe la raíz del dominio, sino cada una de las homes de cada subdirectorio. Al cambiar el comportamiento para convertir una de las versiones en prioritarias, lo que hacemos es que el 302 indique a Google que la home de esa versión no es la home del subdirectorio correspondiente sino la raíz del dominio. En ese escenario, normalmente se indexaría la raíz del dominio con el contenido de esa versión y NO se indexaría la home del subdirectorio correspondiente. Para apoyar este comportamiento, los hreflang/alternate correspondientes en las diferentes homes de cada subdirectorio apuntarán al resto (cada una con su subdirectorio) excepto a la que hemos definido como prioritaria, en cuyo caso apuntaremos a la raíz del dominio. Con ello somos coherentes con la configuración de un 302 en lugar de un 301 para este caso. ¿Queda ahora más claro?
Y la segunda cuestión que planteas: totalmente de acuerdo. Quizá no he sido específico en el post pero daba por sobreentendido que siempre es recomendable incluir enlaces rastreables desde cada home al resto de versiones para facilitar su indexación.
Muchas gracias por tu comentario, Christian.
Have a Suggestion?