Verificación del tráfico: cómo asegurarte de que los enlaces llevan al dominio correcto

Qué se considera una visita al dominio correcto

El tráfico llega al dominio correcto cuando el usuario, tras todas las redirecciones, abre una página en el host de destino. No basta con comprobar la dirección insertada en la descripción del stream, el perfil o el anuncio: el enlace puede pasar por un acortador, un tracker, un dominio antiguo, una landing intermedia o una redirección geográfica.

Comprueba no solo el nombre del dominio, sino también su variante: con y sin www, HTTP y HTTPS, dominio principal y subdominio. Las direcciones site.example, www.site.example y promo.site.example pueden pertenecer a un mismo proyecto, pero para el navegador, la analítica y los registros son hosts distintos.

Abre el enlace tal como lo abre la audiencia

Accede al enlace desde el lugar real donde está publicado: desde la descripción de la transmisión, el perfil, el mensaje fijado, la publicación o el anuncio. Tras cargar la página, comprueba la barra de direcciones. Lo importante es la URL que queda en el navegador, no la dirección original de la publicación.

• Compara el host final con el dominio de la página de destino.
• Comprueba la ruta: el enlace puede llevar al dominio correcto pero a una sección obsoleta.
• Asegúrate de que la visita móvil no acaba en un subdominio técnico.
• Compara el resultado para el enlace con etiquetas UTM y sin ellas.
• Verifica si los parámetros de campaña se conservaron tras todas las redirecciones.

Inconveniente de la comprobación manual: muestra un solo escenario —tu navegador, dispositivo, región y conjunto de cookies—. Para parte de la audiencia las reglas pueden funcionar de otra manera.

Comprueba toda la cadena de redirecciones en el navegador y mediante curl

Para la comprobación técnica usa curl con los parámetros -I y -L: el comando mostrará las cabeceras de respuesta y seguirá las redirecciones. Busca los estados 301, 302, 307, 308 y las cabeceras Location. Indican a qué dirección redirige el servidor al usuario en cada paso.

Para comprobar en un navegador real, abre las herramientas de desarrollador, ve a la pestaña Network y activa Preserve log. Después abre el enlace original. En la lista de solicitudes se ven las redirecciones, el documento final y las solicitudes que se ejecutan ya tras la carga de la página.

1. Activa Preserve log para que la lista no se borre tras la redirección.
2. Si es necesario, desactiva la caché del navegador.
3. Abre el enlace original desde la publicación o pégalo en una pestaña nueva.
4. Localiza las respuestas con estados 3xx.
5. Compara la Request URL de cada paso con el valor de Location.
6. Comprueba el dominio y la URL del último documento con estado 200.

Cuándo un dominio antiguo en la cadena es normal y cuándo es un error

Un dominio antiguo en la cadena no siempre indica un problema. Tras una migración es normal una ruta como old-site.example/stream → site.example/stream: la dirección antigua recibe la solicitud y redirige de forma permanente al usuario a la página equivalente del sitio nuevo. El dominio final es correcto, la ruta se conserva y las etiquetas UTM no desaparecieron.

El fallo se produce cuando old-site.example/stream lleva a la página principal del sitio nuevo, a otra landing o deja al usuario en el dominio antiguo. Un problema aparte surge si tras la redirección desaparece la cadena después del signo de interrogación: el usuario llega a la página correcta, pero la analítica pierde utm_source, utm_medium y utm_campaign.

Comprueba no solo el dominio final, sino también la ruta con los parámetros. Una visita a site.example sin la página o las etiquetas necesarias puede distorsionar los datos de la campaña tanto como una visita a un host ajeno.

Ten en cuenta las redirecciones JavaScript y los parámetros del enlace

curl es útil para las respuestas del servidor, pero no siempre detecta las redirecciones que se activan mediante un script tras la carga de la página. DevTools en el navegador ayuda a detectar ese escenario: primero se abre una página intermedia y después el script cambia la dirección o envía al usuario a otro dominio.

En Network comprueba no solo el documento principal, sino también el momento en que cambia la dirección tras su carga. Si las etiquetas UTM desaparecieron, compara la URL original, el valor de Location y la cadena final en la barra de direcciones. Así se puede entender en qué paso la regla de redirección descartó los parámetros.

Inconveniente de transmitir todos los parámetros sin comprobarlos: al dominio de destino pueden llegar valores técnicos innecesarios. Para los enlaces importantes conviene definir de antemano qué etiquetas, códigos promocionales y parámetros de afiliado deben conservarse.

Comprueba los navegadores integrados de las aplicaciones

Las redes sociales, los mensajeros y las plataformas de streaming a menudo abren el enlace no en el navegador principal del dispositivo, sino en uno integrado. Ese navegador puede enviar otro user-agent, limitar los scripts, no guardar cookies o procesar las redirecciones de otra manera.

Abre el enlace directamente desde la aplicación de la plataforma donde está publicado. Después repite la prueba mediante la opción «Abrir en el navegador», si está disponible. Compara el dominio final, la ruta, las etiquetas UTM y el comportamiento del formulario, el pago o la autorización.

Inconveniente de la comprobación en el navegador integrado: no todas las aplicaciones permiten ver la cadena técnica de solicitudes. Aun así es importante, porque así es como suele acceder la audiencia móvil.

Compara las visitas desde distintas regiones y condiciones

Si el sitio usa redirecciones geográficas, CDN o distintas versiones de landing, repite la comprobación mediante VPN, proxy o un dispositivo remoto en la región necesaria. Compara el dominio final, la ruta, los parámetros de la URL y el contenido de la página de destino.

Comprueba no solo el país, sino también el idioma del navegador, la autorización, las cookies y el tipo de dispositivo. Estas condiciones pueden influir en la ruta: por ejemplo, un usuario de una región es enviado a un subdominio local, y un visitante sin cookies, a una landing general.

Inconveniente de la VPN y el proxy: no siempre reproducen por completo las condiciones de un espectador real. La geolocalización puede determinarse por varias señales, por lo que esa prueba confirma un posible problema, pero no cubre a toda la audiencia.

Confirma el dominio en Yandex Metrica y GA4

En Yandex Metrica consulta los informes de páginas de entrada y URL de páginas. Filtra los datos por la dirección completa o el dominio necesario y luego añade un segmento por etiqueta UTM, fuente o campaña. Así se puede ver en qué host comenzaron las visitas tras una publicación concreta.

En GA4, para esa comprobación usa la dimensión Hostname junto con la página de destino, la fuente de la sesión y la campaña. Compara cuántas sesiones llegaron al dominio principal, a la dirección antigua y a los subdominios importantes. Si la etiqueta está instalada en varios hosts, el informe muestra rápidamente la mezcla de tráfico.

Inconveniente de la analítica: los contadores no registran parte de las visitas por bloqueadores, JavaScript desactivado o el cierre de la página antes de cargar la etiqueta. Además, los datos no ayudan con un dominio donde el contador no está instalado en absoluto.

Comprueba las solicitudes en los registros del servidor

Los registros del servidor confirman qué solicitudes llegaron realmente a la infraestructura del sitio. Para la comprobación se necesitan campos con la hora, Host, URL, código de respuesta, user-agent y referer, si se transmite. Busca las solicitudes en el periodo de lanzamiento del enlace y revisa por separado las solicitudes al dominio antiguo y al de destino.

Las respuestas 301, 302, 307 y 308 mostrarán que el servidor redirigió al usuario. Las solicitudes con estado 200 al host de destino confirmarán que la página se entregó desde el dominio correcto. Si en los registros hay visitas al host antiguo pero no hay solicitudes al nuevo, revisa las reglas de redirección y posibles errores de conexión.

Inconveniente de los registros: incluyen bots, escáneres y solicitudes técnicas. El referer a menudo falta en las visitas desde aplicaciones y mensajeros, por lo que no siempre se podrá reconstruir la fuente de una visita concreta.

Separa el dominio principal y los subdominios en los informes

La landing, el área personal, el pago y la base de conocimiento pueden estar en subdominios distintos. Si se agrupan en un solo informe sin segmentos, se puede pasar por alto que el enlace del stream lleva a promo.site.example en lugar del sitio principal, o a checkout.site.example antes de conocer la oferta.

Crea un segmento aparte para el host de destino y deja un informe general de todos los dominios del proyecto. El primero ayudará a controlar el tráfico de la landing; el segundo, a ver el recorrido del usuario entre la landing, el pago y el área personal.

Inconveniente de un filtrado demasiado estricto: del informe puede desaparecer una transición normal entre subdominios y el embudo parecerá interrumpido.

Checklist de comprobación del enlace antes de publicarlo

• Abrir el enlace desde el lugar donde lo verá la audiencia.
• Comprobar el dominio final, la ruta y los parámetros en la barra de direcciones.
• Revisar la cadena 3xx y las cabeceras Location mediante curl o Network.
• Asegurarse de que el dominio antiguo conserva la ruta y las etiquetas UTM al redirigir.
• Repetir la visita en el navegador integrado de la aplicación.
• Comprobar otra región si se usan reglas geográficas.
• Comparar Hostname y páginas de destino en la analítica tras el lanzamiento.
• Confirmar las solicitudes al host correcto mediante los registros del servidor.

Tras cambiar el dominio, la CDN, la landing o las reglas de redirección, comprueba tanto los enlaces nuevos como los antiguos. Las descripciones antiguas de streams, los vídeos y las publicaciones fijadas pueden seguir llevando audiencia a una ruta obsoleta.