Verificação de tráfego: como confirmar que os links levam ao domínio correto

O que considerar como acesso ao domínio correto

O tráfego chega ao domínio correto quando o usuário, após todos os redirecionamentos, abre a página no host de destino. Não basta verificar o endereço inserido na descrição da live, no perfil ou no anúncio: o link pode passar por um encurtador, um rastreador, um domínio antigo, uma landing page intermediária ou um redirecionamento geográfico.

Verifique não apenas o nome do domínio, mas também a sua variação: com e sem www, HTTP e HTTPS, domínio principal e subdomínio. Os endereços site.example, www.site.example e promo.site.example podem pertencer ao mesmo projeto, mas para o navegador, o analytics e os logs são hosts diferentes.

Abra o link da mesma forma que o público o abre

Acesse o link a partir do local real de publicação: da descrição da transmissão, do perfil, da mensagem fixada, do post ou do anúncio. Após o carregamento da página, verifique a barra de endereços. O importante é a URL que permaneceu no navegador, e não o endereço original da publicação.

• Confira o host final com o domínio da landing page.
• Verifique o caminho: o link pode levar ao domínio correto, mas a uma seção desatualizada.
• Certifique-se de que o acesso mobile não vá para um subdomínio técnico.
• Compare o resultado para o link com e sem tags UTM.
• Verifique se os parâmetros da campanha foram preservados após todos os redirecionamentos.

Desvantagem da verificação manual: ela mostra apenas um cenário — o seu navegador, dispositivo, região e conjunto de cookies. Para parte do público, as regras podem funcionar de forma diferente.

Verifique toda a cadeia de redirecionamentos no navegador e via curl

Para uma verificação técnica, use o curl com os parâmetros -I e -L: o comando mostrará os cabeçalhos de resposta e percorrerá os redirecionamentos. Procure os status 301, 302, 307, 308 e os cabeçalhos Location. Eles mostram para qual endereço o servidor direciona o usuário em cada etapa.

Para verificar em um navegador real, abra as ferramentas de desenvolvedor, vá até a aba Network e ative o Preserve log. Em seguida, abra o link original. Na lista de requisições, é possível ver os redirecionamentos, o documento final e as requisições que são executadas já após o carregamento da página.

1. Ative o Preserve log para que a lista não seja limpa após o redirecionamento.
2. Se necessário, desative o cache do navegador.
3. Abra o link original da publicação ou cole-o em uma nova aba.
4. Encontre as respostas com status 3xx.
5. Confira o Request URL de cada etapa com o valor de Location.
6. Verifique o domínio e a URL do último documento com status 200.

Quando o domínio antigo na cadeia é normal e quando é um erro

Um domínio antigo na cadeia nem sempre indica um problema. Após uma migração, é normal uma rota como old-site.example/stream → site.example/stream: o endereço antigo recebe a requisição e redireciona permanentemente o usuário para a página equivalente do novo site. O domínio final está correto, o caminho foi preservado e as tags UTM não desapareceram.

O bug é a situação em que old-site.example/stream leva à página inicial do novo site, a outra landing page ou deixa o usuário no domínio antigo. Um problema separado surge quando, após o redirecionamento, a string após o ponto de interrogação desaparece: o usuário chega à página correta, mas o analytics perde utm_source, utm_medium e utm_campaign.

Verifique não apenas o domínio final, mas também o caminho com os parâmetros. Um acesso a site.example sem a página ou as tags necessárias pode distorcer os dados da campanha tanto quanto um acesso a um host errado.

Considere redirecionamentos JavaScript e parâmetros do link

O curl é útil para respostas do servidor, mas nem sempre vê os redirecionamentos que são acionados por script após o carregamento da página. O DevTools no navegador ajuda a perceber esse cenário: primeiro abre-se uma página intermediária, depois o script altera o endereço ou envia o usuário para outro domínio.

No Network, verifique não apenas o documento principal, mas também o momento da alteração do endereço após o seu carregamento. Se as tags UTM desapareceram, compare a URL original, o valor de Location e a string final na barra de endereços. Assim, é possível entender em qual etapa a regra de redirecionamento descartou os parâmetros.

Desvantagem de repassar todos os parâmetros sem verificação: valores técnicos desnecessários podem chegar ao domínio de destino. Para links importantes, vale definir previamente quais tags, cupons e parâmetros de afiliado devem ser preservados.

Verifique os navegadores integrados dos aplicativos

Redes sociais, mensageiros e plataformas de streaming frequentemente abrem o link não no navegador principal do dispositivo, mas em um navegador integrado. Esse navegador pode enviar outro user-agent, limitar scripts, não salvar cookies ou processar os redirecionamentos de forma diferente.

Abra o link diretamente do aplicativo da plataforma onde ele está publicado. Depois, repita o teste pela opção "Abrir no navegador", se estiver disponível. Compare o domínio final, o caminho, as tags UTM e o comportamento do formulário, do pagamento ou da autorização.

Desvantagem da verificação no navegador integrado: nem todos os aplicativos permitem visualizar a cadeia técnica de requisições. Ela continua sendo importante, porque é assim que o público mobile costuma acessar.

Compare acessos de diferentes regiões e condições

Se o site usa redirecionamentos geográficos, CDN ou versões diferentes de landing pages, repita a verificação via VPN, proxy ou dispositivo remoto na região desejada. Compare o domínio final, o caminho, os parâmetros da URL e o conteúdo da landing page.

Verifique não apenas o país, mas também o idioma do navegador, a autorização, os cookies e o tipo de dispositivo. Essas condições podem influenciar a rota: por exemplo, um usuário de uma região é enviado para um subdomínio local, enquanto um visitante sem cookies é enviado para uma landing page geral.

Desvantagem de VPN e proxy: eles nem sempre reproduzem completamente as condições de um espectador real. A geolocalização pode ser determinada por vários sinais, portanto esse teste confirma um possível problema, mas não cobre todo o público.

Confirme o domínio no Yandex Metrica e no GA4

No Yandex Metrica, consulte os relatórios de páginas de entrada e URLs das páginas. Filtre os dados pelo endereço completo ou pelo domínio desejado e, em seguida, adicione um segmento por tag UTM, origem ou campanha. Assim, é possível ver em qual host as visitas começaram após uma publicação específica.

No GA4, para essa verificação, use a dimensão Hostname junto com a landing page, a origem da sessão e a campanha. Compare quantas sessões chegaram ao domínio principal, ao endereço antigo e aos subdomínios importantes. Se a tag estiver instalada em vários hosts, o relatório mostra rapidamente a mistura de tráfego.

Desvantagem do analytics: os contadores não registram parte das visitas por causa de bloqueadores, JavaScript desativado ou fechamento da página antes do carregamento da tag. Além disso, os dados não ajudarão em um domínio onde o contador não está instalado.

Verifique as requisições nos logs do servidor

Os logs do servidor confirmam quais requisições realmente chegaram à infraestrutura do site. Para a verificação, são necessários campos com horário, Host, URL, código de resposta, user-agent e referer, se ele for enviado. Procure acessos no período de lançamento do link e observe separadamente as requisições aos domínios antigo e de destino.

As respostas 301, 302, 307 e 308 mostrarão que o servidor redirecionou o usuário. Requisições com status 200 ao host de destino confirmarão que a página foi entregue pelo domínio correto. Se nos logs houver acessos ao host antigo, mas não houver requisições ao novo, verifique as regras de redirecionamento e possíveis erros de conexão.

Desvantagem dos logs: neles entram bots, scanners e requisições técnicas. O referer frequentemente está ausente em acessos vindos de aplicativos e mensageiros, portanto nem sempre será possível recuperar a origem de uma visita específica.

Separe o domínio principal e os subdomínios nos relatórios

A landing page, a área do usuário, o pagamento e a base de conhecimento podem estar em subdomínios diferentes. Se forem reunidos em um único relatório sem segmentos, pode passar despercebido que o link da live leva a promo.site.example em vez do site principal, ou a checkout.site.example antes do contato com a oferta.

Crie um segmento separado para o host de destino e mantenha um relatório geral de todos os domínios do projeto. O primeiro ajudará a controlar o tráfego de entrada, o segundo — a ver o caminho do usuário entre a landing page, o pagamento e a área do usuário.

Desvantagem de uma filtragem muito rígida: um redirecionamento normal entre subdomínios pode desaparecer do relatório, e o funil parecerá interrompido.

Checklist de verificação do link antes da publicação

• Abrir o link a partir do local onde o público o verá.
• Verificar o domínio final, o caminho e os parâmetros na barra de endereços.
• Observar a cadeia 3xx e os cabeçalhos Location via curl ou Network.
• Certificar-se de que o domínio antigo preserva o caminho e as tags UTM no redirecionamento.
• Repetir o acesso no navegador integrado do aplicativo.
• Verificar outra região, se forem usadas regras geográficas.
• Conferir o Hostname e as landing pages no analytics após o lançamento.
• Confirmar as requisições ao host correto pelos logs do servidor.

Após mudar o domínio, a CDN, a landing page ou as regras de redirecionamento, verifique tanto os links novos quanto os antigos. Descrições antigas de lives, vídeos e posts fixados podem continuar levando o público a uma rota desatualizada.