Cómo verificar hreflang en vivo a través de un proxy de 10 países.

La marcación hreflang en el código de la página es una cosa, y lo que realmente recibe un visitante de Alemania, Polonia o Brasil es algo completamente diferente. Google puede ignorar las etiquetas, el CDN puede redirigir incorrectamente, y el servidor puede entregar una versión incorrecta según la IP. La única manera de asegurarse de que todo funciona es verificar el sitio "en vivo" desde diferentes países, y no confiar en la marcación en papel.

Qué es hreflang y por qué las etiquetas en el código no son suficientes

Hreflang es un atributo que informa a los motores de búsqueda qué versión lingüística o regional de la página está destinada a qué usuarios. Técnicamente, esto se presenta como un conjunto de enlaces en <head> o en sitemap.xml, donde cada página se refiere a sus alternativas: ru-RU, en-US, de-DE, y así sucesivamente.

El problema es que la verificación a través de validadores de código (Screaming Frog, Ahrefs, Semrush) solo muestra lo que está escrito en la marcación. No responde a la pregunta principal: ¿qué sucede realmente cuando una persona viva de Varsovia o Madrid abre su sitio? ¿Se activa la redirección a la localidad correcta? ¿El CDN redirige al usuario a la versión en inglés debido a la caché? ¿Geo-IP determina correctamente el país si el usuario accede a través de un operador móvil?

Para los especialistas en marketing y SEO que prueban sitios multirregionales, páginas de destino para diferentes geografías o campañas publicitarias en Google Ads y Facebook Ads para países específicos, esto es crítico. Si hreflang está configurado incorrectamente, un usuario del país correcto puede ver la versión incorrecta del sitio, perder conversiones, y el motor de búsqueda puede indexar la URL incorrecta en los resultados de ese país.

Por qué hreflang "miente": 5 razones típicas

En la práctica, la discrepancia entre la marcación y el comportamiento real del sitio ocurre por varias razones, y la mayoría de ellas son imposibles de detectar solo mirando el código de la página.

Redirección Geo-IP interfiere con hreflang. El servidor determina el país por IP y redirige forzosamente a la localidad, incluso si el usuario ha abierto explícitamente otra versión lingüística a través de un enlace directo.
CDN en caché entrega una versión obsoleta. Cloudflare u otro CDN puede almacenar en caché el HTML sin tener en cuenta el país de la solicitud, y todos los usuarios reciben la misma versión independientemente de la geografía.
Inconsistencia en los códigos de idioma y región. En la marcación se indica en, cuando debería ser en-GB y en-US por separado; al final, los usuarios de Gran Bretaña y EE. UU. ven una versión.
Falta de etiqueta auto-referencial. La página no se refiere a sí misma en la lista de hreflang, lo que puede hacer que Google no considere la marcación como válida.
Diferentes variantes de URL con www y sin, http y https. Las etiquetas apuntan a un protocolo, mientras que el servidor realmente redirige a otro, rompiendo la cadena de verificación.

Todos estos problemas solo se manifiestan al acceder realmente con la IP del país correcto. Por lo tanto, la única manera confiable de probar es emular a un visitante de cada país objetivo y ver qué entrega realmente el sitio.

Qué necesitas para la verificación desde 10 países

Para verificar hreflang "en vivo", necesitas obtener física o programáticamente una dirección IP de cada país objetivo y ver qué versión del sitio entrega el servidor a esa IP. Hay tres maneras efectivas de hacerlo:

Proxies con geolocalización al país deseado — la forma más flexible y escalable, adecuada tanto para verificación manual como para automatización.
Navegadores anti-detección (Dolphin Anty, AdsPower, Multilogin, GoLogin, Octo Browser) — son convenientes cuando necesitas mantener perfiles de navegador separados para cada país y comparar visualmente, sin confusión en cookies y caché.
Herramientas de línea de comandos (curl, httpie) con proxy — para una verificación rápida de encabezados HTTP, redirecciones y respuestas del servidor sin cargar la interfaz.

Para probar hreflang desde 10 países, los proxies residenciales son los más adecuados — utilizan IP de usuarios reales de un país específico, por lo que los servicios de geo-IP y CDN los identifican como un visitante normal del sitio. Los proxies de centros de datos a veces son bloqueados por servicios geográficos y pueden dar resultados falsos, cuando el servidor los identifica no por el país declarado, sino como "centro de datos, país desconocido".

Configuración de proxy en un navegador anti-detección

La forma más práctica para un especialista en marketing sin habilidades de programación es crear perfiles separados en un navegador anti-detección para cada uno de los 10 países objetivo y realizar la verificación de hreflang visualmente.

Paso a paso en Dolphin Anty o AdsPower, esto se ve así:

Crea un nuevo perfil de navegador, nómbralo por país, por ejemplo "hreflang-DE" para Alemania.
En la configuración del perfil, abre la sección "Proxy" y selecciona el tipo HTTP/SOCKS5.
Pega los datos del proxy con geolocalización a Alemania: IP o host, puerto, nombre de usuario y contraseña.
Guarda el perfil y espera la verificación; el navegador anti-detección mostrará una geolocalización específica, zona horaria e IP.
Inicia el perfil y abre tu sitio a través de la URL directa, sin pasar por la búsqueda.
Verifica qué versión se abrió: URL en la barra de direcciones, idioma del contenido, valores hreflang a través de "Ver código de página".
Repite para cada uno de los 10 países objetivo, creando un perfil separado para cada uno.

Este enfoque es conveniente porque los perfiles se guardan, y puedes volver a ellos en una semana o un mes para verificar si el comportamiento del sitio ha cambiado después de una actualización del CDN o el despliegue de una nueva versión. Para esta tarea, son adecuados los proxies residenciales con vinculación a una ciudad específica, no solo al país — esto proporciona una emulación más precisa de un visitante real.

Verificación a través de la línea de comandos y curl

Si necesitas verificar rápidamente no la versión visual, sino específicamente los encabezados HTTP, redirecciones y respuestas del servidor, el navegador no siempre proporciona una imagen completa — parte de la lógica está oculta en los encabezados de respuesta. Para esto, es conveniente usar curl con proxy.

Verificación básica a través de proxy con vinculación al país deseado:

curl -x http://login:password@proxy-host:port \
  -I https://example.com/ \
  -H "Accept-Language: de-DE"

La bandera -I muestra solo los encabezados de respuesta, sin el cuerpo de la página. Esto permite ver rápidamente el código de redirección (301 o 302), el encabezado Location, que indica a dónde redirige el servidor, y el encabezado Vary, que informa si se tiene en cuenta Accept-Language en la caché.

Para extraer el HTML y encontrar las etiquetas hreflang en la respuesta del servidor, quita -I y filtra la salida:

curl -x http://login:password@proxy-host:port \
  -s https://example.com/ | grep -i hreflang

Esta consulta extraerá todas las líneas que mencionan hreflang directamente del HTML entregado por el servidor, y no de lo que se espera según la documentación. Si el resultado varía según el proxy del país desde el cual se envió la consulta, significa que el servidor realmente cambia el contenido según la IP, y no simplemente lo declara en la marcación estática.

Para automatizar la verificación de los 10 países, se puede escribir un simple script que recorra la lista de proxies y guarde la respuesta de cada consulta en un archivo separado para comparación:

for country in de fr es it pl nl br mx jp kr; do
  curl -x "http://login:password@${country}.proxy-host:port" \
    -s https://example.com/ | grep -i hreflang > "result_${country}.txt"
done

Después de ejecutar el script, solo queda comparar los archivos — si en todos hay el mismo conjunto de etiquetas hreflang, significa que el servidor no cambia la marcación según la geografía, lo que puede ser un comportamiento esperado (la marcación es estática y universal) o un problema (si se esperaba una canonización diferente para diferentes regiones).

Verificación a través del navegador y DevTools

Para una verificación visual y análisis de la experiencia del usuario, es más conveniente usar un navegador normal con proxy configurado y herramientas de desarrollador abiertas. Esto no requiere código y es adecuado para los especialistas en marketing que quieren ver con sus propios ojos lo que ve el usuario.

Orden de acciones:

Configura el proxy en el navegador a través de una extensión (por ejemplo, FoxyProxy) o a través de la configuración de red del sistema, especificando la IP del país de verificación.
Abre el sitio y presiona F12 de inmediato para abrir DevTools, luego ve a la pestaña "Network".
Recarga la página y encuentra la primera solicitud del documento (generalmente se llama igual que el dominio del sitio).
En el panel de la derecha, abre la pestaña "Headers" y verifica la sección "Response Headers" en busca de redirecciones y el valor Content-Language.
Abre la pestaña "Elements" y a través de Ctrl+F busca todas las ocurrencias de hreflang en el código fuente de la página.
Compara la URL en la barra de direcciones con la que esperabas ver para este país.

Este método es especialmente útil cuando necesitas verificar simultáneamente tanto la corrección técnica de la marcación como la visualización del contenido — por ejemplo, si se muestra correctamente la moneda, el formato de fecha o los banners localizados para un país específico.

Qué proxies elegir para la prueba de geotargeting

No todos los tipos de proxies son igualmente adecuados para verificar hreflang. La diferencia radica en cómo los servicios de determinación de geolocalización reconocen la IP y cuán estable mantiene el proxy la vinculación al país declarado.

Tipo de proxy	Precisión de geo-IP	Cuándo usar
Proxies residenciales	Alta, IP de proveedores reales	Emulación precisa de un visitante real del país y la ciudad
Proxies móviles	Alta, IP de operadores de telecomunicaciones	Verificación del comportamiento para tráfico móvil y versiones AMP
Proxies de centros de datos	Baja, a veces se etiquetan como centro de datos	Verificación rápida de encabezados y redirecciones a través de curl, donde la precisión geográfica no es crítica

Para la verificación final antes del lanzamiento de un sitio multilingüe o una campaña publicitaria internacional en Google Ads, es mejor usar proxies residenciales o móviles — son los que ofrecen resultados más cercanos a lo que verá un usuario real del país objetivo.

Checklist de verificación hreflang para 10 países

Para no omitir nada durante la verificación masiva, utiliza la siguiente lista para cada uno de los 10 países:

Proxy conectado con IP de este país, geolocalización confirmada a través de un verificador de IP.
URL directa del sitio abierta (sin pasar por la búsqueda y sin referenciador).
URL final verificada después de todas las redirecciones — ¿coincide con la localidad esperada?
En el código de la página, hay un hreflang auto-referencial a sí mismo.
En la lista de hreflang están todas las otras 9 versiones lingüísticas sin omisiones.
Los códigos de idioma y región cumplen con el estándar ISO (por ejemplo, pt-BR, y no solo pt, si es necesario distinguir entre Brasil y Portugal).
El encabezado Vary: Accept-Language está presente si el contenido depende del idioma del navegador.
El contenido de la página (moneda, precios, banners) corresponde a la región declarada.
La etiqueta canónica rel="canonical" se refiere a sí misma, y no a otra localidad.
Re-verificación en una semana — después de la actualización de la caché del CDN, el resultado no ha cambiado inesperadamente.

Errores comunes al probar

Al verificar hreflang manualmente a través de proxies, los especialistas en marketing a menudo cometen varios errores recurrentes que distorsionan el resultado de la prueba.

En primer lugar, la verificación se realiza desde una cuenta iniciada o con una sesión guardada — en este caso, el servidor puede mostrar contenido personalizado, y no lo que verá un nuevo visitante. Siempre verifica en modo incógnito o en un perfil limpio de navegador anti-detección sin historial.

En segundo lugar, olvidan limpiar la caché DNS y del navegador entre el cambio de proxies, lo que hace que la versión antigua de la página continúe mostrándose, aunque la IP ya ha cambiado. Utiliza una recarga dura de la página (Ctrl+Shift+R) con cada cambio de geografía.

En tercer lugar, solo prueban la página principal, ignorando secciones internas y fichas de productos — y es allí donde más a menudo se rompe la marcación hreflang debido a la generación dinámica de URL sobre la marcha.

En cuarto lugar, utilizan el mismo proxy para los 10 países, cambiando solo el encabezado Accept-Language — esto no es equivalente a un verdadero geo-IP y puede dar un resultado falso positivo si el servidor se basa precisamente en la IP, y no en el idioma del navegador.

Conclusión

Verificar hreflang a través del código de la página solo ofrece la mitad de la imagen. Para entender lo que realmente recibe un usuario de un país específico, es necesario emular su visita a través de la IP de ese país — utilizando proxies, navegadores anti-detección o una simple consulta curl. Este enfoque revela problemas que no se pueden encontrar en una auditoría estática: redirecciones geo-IP, caché de CDN sin tener en cuenta la región, discrepancias en los códigos de idioma y etiquetas auto-referenciales que se rompen.

Si regularmente pruebas sitios multilingües o preparas campañas publicitarias para 10 o más países, te recomendamos probar proxies residenciales — ofrecen la emulación más precisa de un visitante real para cada país objetivo y permiten verificar hreflang tal como lo vería un usuario vivo, y no un robot de búsqueda.