Hreflang x-default: cuándo usarlo y adónde apuntar

El valor x-default de hreflang es la respuesta del sitio a una pregunta concreta: qué URL debe ver alguien cuyo idioma o país no coincide con ninguna de las versiones que has declarado. No es un idioma, no mejora posiciones y no sustituye a los demás valores; es la red de seguridad del conjunto. La página correcta suele ser una de dos: tu versión genérica (normalmente la internacional o la que mejor sirve a cualquier visitante) o una página selectora de idioma y país.

La confusión aparece porque ambas opciones son válidas y cada una encaja en situaciones distintas. Este artículo explica cómo se lee x-default, cómo elegir su destino con un criterio práctico, cómo escribirlo en las tres formas admitidas (etiquetas, cabeceras HTTP y sitemap) y qué errores lo dejan sin efecto sin que aparezca ningún aviso evidente.

Qué hace x-default y qué no hace

Hreflang existe para que Google muestre a cada usuario la versión de una página que corresponde a su idioma o región cuando tienes varias equivalentes. Cada versión se etiqueta con un código como es, es-mx o en-gb. El problema es evidente: siempre habrá usuarios que no encajen. Un visitante con el navegador en japonés, si solo tienes versiones en español, inglés y alemán, no coincide con ninguna etiqueta. Para ese caso existe x-default, que marca la URL de reserva.

Conviene separar dos cosas que se mezclan a menudo. La primera es lo que dice la documentación de Google: x-default designa la página que debe mostrarse cuando ningún otro idioma o región coincide, y además puede señalar una página selectora. La segunda es lo que la gente imagina: que x-default da más autoridad a una versión, que fusiona señales entre versiones o que es obligatorio. Nada de eso es cierto. Hreflang es una señal para intercambiar la URL mostrada en los resultados, no un factor para subir posiciones, y x-default es opcional.

Tampoco es un código de idioma. Se escribe exactamente como x-default, sin combinarlo con un idioma ni con un país. Valores como x-default-en o es-x-default no existen y se ignoran. Y la URL que lleva x-default puede ser, a la vez, la de una versión con su propio código: la misma dirección puede aparecer declarada como en y como x-default dentro del mismo conjunto, y es un patrón muy habitual.

Las dos opciones: versión por defecto o selector de idioma

La decisión real es a qué URL apunta. Hay dos respuestas legítimas y conviene entender qué hace cada una.

Opción A: la versión por defecto. Eliges la versión que sirve mejor a un visitante desconocido, casi siempre la inglesa o la de tu mercado principal, y la declaras como x-default. El usuario que no coincide llega directamente a contenido útil, sin pasos intermedios. Es la opción más sencilla y la que menos fricción causa, porque cada clic aterriza en una página con contenido real que puede posicionar por sí misma.

Opción B: una página selectora. Es una URL cuyo trabajo es preguntar al visitante su idioma o país y enviarlo a la versión adecuada. Tiene sentido cuando ninguna versión es razonablemente neutra: una marca con tiendas por país, con catálogos, monedas y condiciones distintas, donde mostrar la tienda equivocada es peor que pedir una elección. También encaja cuando el sitio no tiene una versión principal clara.

• Elige la versión por defecto cuando existe un mercado o idioma claramente dominante, y el contenido de esa versión es comprensible para casi cualquiera.
• Elige el selector cuando los precios, el envío o las condiciones cambian tanto por país que enviar al usuario a una versión equivocada le causaría un problema real.
• En un sitio de contenido (blog, documentación, medio) casi siempre gana la versión por defecto: un selector no aporta nada a quien solo quiere leer.
• Si dudas, empieza por la versión por defecto. Es más fácil añadir un selector después que limpiar un selector que nadie usa.

Cómo debe ser una página selectora para funcionar como x-default

Si optas por el selector, no basta con crear una página con banderas. Para que sea un destino válido debe cumplir varias condiciones, y la mayoría de los fallos vienen de ahí.

Primero, debe ser una página real, indexable y con un código de respuesta 200. Sin redirecciones, sin noindex y sin estar bloqueada en robots.txt. Segundo, sus enlaces a las versiones deben ser enlaces HTML normales que un rastreador pueda seguir, no un menú desplegable que solo funciona con JavaScript y eventos de clic. Tercero, debe tener algo de texto propio que explique de qué trata el sitio, en lugar de ser un fondo con botones, para que no se considere una página vacía.

Lo más importante: el selector no debe redirigir automáticamente según la IP o el idioma del navegador. Si detectas el país y envías al usuario a otra URL sin que intervenga, el rastreador de Google, que suele rastrear desde direcciones de Estados Unidos, vería siempre el mismo destino y nunca descubriría el resto. Usar una redirección automática en la URL que declaras como x-default anula precisamente la función para la que lo declaras. Si quieres sugerir un idioma, hazlo con un aviso visible que el usuario pueda aceptar o ignorar, y deja siempre la página accesible.

Cómo se escribe: etiquetas, cabeceras HTTP y sitemap

Hay tres sitios donde se puede declarar hreflang, y se elige uno por página o por conjunto. Mezclar sistemas contradictorios para la misma URL es una fuente clásica de problemas, así que conviene decidir uno y mantenerlo.

Etiquetas en el head. Es la forma más habitual. Cada página incluye la lista completa, con ella misma incluida. Un ejemplo para un sitio con versión general en inglés, versión en español y versión mexicana:

link rel="alternate" hreflang="en" href="https://ejemplo.com/en/"; link rel="alternate" hreflang="es" href="https://ejemplo.com/es/"; link rel="alternate" hreflang="es-mx" href="https://ejemplo.com/mx/"; link rel="alternate" hreflang="x-default" href="https://ejemplo.com/en/". Aquí la URL inglesa aparece dos veces, como en y como x-default, y es correcto.

Cabeceras HTTP. Sirven para archivos que no son HTML, como los PDF, donde no hay head donde poner etiquetas. Se envía una cabecera Link con los mismos pares de URL y código, y el valor x-default se escribe igual.

Sitemap XML. Es la opción más cómoda cuando hay miles de URL, porque todo queda en un sitio y no pesa en cada página. Cada entrada url incluye elementos xhtml:link con rel alternate, hreflang y href, repetidos para todas las versiones. Es la vía preferible en sitios grandes porque se genera desde la base de datos y se revisa con un solo script, en lugar de tocar plantillas.

Reglas de reciprocidad que x-default también debe cumplir

Hreflang funciona solo si las anotaciones son recíprocas. Si la página A declara a la B como alternativa, la B debe declarar a la A. Sin confirmación mutua, Google puede ignorar el par, porque no puede comprobar que ambas páginas pertenecen de verdad al mismo conjunto. Con x-default ocurre lo mismo: la URL que designas como x-default tiene que incluir a su vez la misma lista completa, y cada versión debe incluir la línea x-default.

Esto se rompe fácilmente en la práctica. Un ejemplo: añades una nueva versión en francés, la declaras en la home francesa y en la home inglesa, pero olvidas actualizar la alemana y la española. Las páginas antiguas no apuntan al francés, así que la versión nueva queda incompleta desde tres de sus cuatro vecinas. Lo mismo vale para el selector: si es la URL x-default, debe aparecer en la lista de cada página del conjunto y llevar la lista completa en la suya.

Además, la regla se aplica por conjunto de páginas equivalentes, no por sitio. Cada tema o producto tiene su propio conjunto, y cada conjunto tiene su propio x-default. No existe un x-default global para todo el dominio que valga para todas las URLs. Un producto que solo existe en dos idiomas necesita su propio conjunto con sus dos versiones y, si lo quieres, su x-default. Y dentro de un conjunto solo debe haber un valor x-default.

Errores frecuentes con x-default

La mayoría de los fallos no son de sintaxis sino de coherencia entre señales. Estos son los que más se repiten al auditar sitios internacionales.

• x-default apuntando a una URL con redirección. Si la URL declarada redirige a otra, hreflang espera la URL final. Declara siempre la dirección definitiva, sin redirecciones intermedias ni parámetros de sesión.
• Canonical contradictorio. Si la página x-default tiene un canonical hacia otra URL, le estás diciendo a Google que la página real es otra y que la declarada no merece indexarse. Las URLs de hreflang y sus canonicals deben coincidir: cada versión debe ser canónica de sí misma.
• Destino con noindex o bloqueado. Una URL que Google no puede indexar no puede ser alternativa. Revisa meta robots, cabecera X-Robots-Tag y robots.txt.
• Varios x-default en el mismo conjunto. Es una señal ambigua. Deja uno solo y que sea el mismo en todas las páginas del conjunto.
• Un x-default distinto en cada página. Por ejemplo, que la versión alemana apunte a su propia home como x-default y la inglesa a la suya. El valor debe ser el mismo destino en todas.
• Usarlo como sustituto de hreflang. Declarar solo x-default sin las versiones por idioma no dice nada. Es un complemento, no un atajo.
• Errores de código. Escribir en-UK en lugar de en-gb, o usar eng, o poner el país solo. El idioma va primero en formato ISO 639-1 y la región después, en ISO 3166-1 alfa-2. Un código inválido invalida esa anotación.
• URLs relativas. Usa siempre URLs absolutas con protocolo y dominio completos. Mezclar http y https también rompe la coincidencia con las URLs indexadas.

Cómo comprobar que funciona

Como hreflang no da errores visibles en la página, la verificación es un trabajo aparte y conviene hacerlo en tres pasos.

El primero es estructural: rastrea el sitio con un crawler capaz de leer hreflang, y revisa el informe de conjuntos. Busca retornos ausentes, destinos con redirección, noindex o canonical distinto y códigos no válidos. Para un sitio pequeño basta un script que descargue cada URL del conjunto y compare las listas: todas deben ser idénticas salvo por el orden.

El segundo es de indexación: inspecciona con Search Console las URLs clave. Si una versión aparece como no indexada, su anotación hreflang dejará de tener efecto, y el problema real es la indexación, no el hreflang. Search Console ya no ofrece el antiguo informe de segmentación internacional, así que la comprobación pasa por la inspección de URL y por los datos de rendimiento filtrados por país.

El tercero es de comportamiento real: busca la marca o una consulta propia desde dispositivos o ubicaciones distintas y mira qué versión se muestra. No es una prueba concluyente, porque los resultados dependen de muchos factores, pero detecta los fallos más flagrantes, como que a un usuario mexicano se le muestre sistemáticamente la versión de España. Recuerda también que Google puede tardar semanas en reprocesar los cambios, así que espera antes de concluir que algo no funciona.

Un caso práctico de decisión

Imagina una tienda con versiones en español para España, español para México e inglés internacional. El tráfico principal viene de España, pero los envíos a Latinoamérica tienen otras condiciones, y la versión inglesa es la única pensada para el resto del mundo. ¿Dónde va x-default?

Si el español de España es lo único que tiene contenido completo, cualquier visitante desconocido se encontraría con un sitio en un idioma que quizá no entiende. La versión inglesa, en cambio, es comprensible para una parte mucho mayor del público sin ubicación conocida. Aquí la opción razonable es marcar la versión inglesa como x-default, declarando la misma URL también como en. Un selector no aporta valor, porque los precios ya están separados por versión y la mayoría de los visitantes no coincidentes simplemente necesitan una página comprensible.

Cambia el escenario: una marca con seis tiendas nacionales, cada una con moneda, impuestos y stock propios, y sin versión dominante. Mostrar una tienda al azar a un visitante de otro país provoca pedidos imposibles. En este caso un selector como x-default es la decisión correcta, y es razonable que esa página sea liviana, clara y se pueda rastrear. En ambos casos el criterio es el mismo: qué página evita la peor experiencia a alguien de quien no sabes nada.