Porque é que «nenhum site encontrado» costuma estar errado

Verificar se um negócio tem site parece trivial: pesquisa-se o nome e vê-se se aparece um site. Construir uma ferramenta que o faz automaticamente, em escala e corretamente ensinou-me mais sobre qualidade de dados do que qualquer outra parte do projeto.

#A primeira versão: confiante e errada

A primeira versão pesquisava o nome e a zona do negócio. Se não aparecesse nenhum site plausível nos resultados, marcava o negócio como sem site. O resultado foi uma lista longa de negócios aparentemente sem site.

Quando verifiquei manualmente uma amostra, a maioria tinha sites perfeitamente bons.

O fornecedor de pesquisa tinha devolvido resultados fracos, o nome era genérico ou o site simplesmente não estava bem indexado. A ferramenta tinha transformado não o encontrei em não existe — o erro mais comum na investigação automatizada.

#Um modelo de dados que consegue dizer «desconhecido»

A solução começou no modelo de dados, não no código. A presença online de um negócio tem agora quatro estados:

• Tem site — encontrado e acessível.
• Site fraco — acessível, mas sem o básico (versão para telemóvel, contacto, HTTPS).
• Avariado — de certeza que não funciona.
• Desconhecido — sem evidências suficientes em nenhum sentido.

«Sem site» só é atribuído quando uma fonte de confiança e autorizada o confirma. A ausência de um resultado de pesquisa nunca o pode produzir.

#Vários sinais independentes

Em vez de uma única pesquisa, o sistema combina agora:

1. Uma fonte de pesquisa no servidor para o nome e a zona.
2. Domínios candidatos gerados a partir do nome (fadedistrict.co.uk, fade-district.com…) e verificados diretamente.
3. Análise do site para cada candidato, com várias variantes de URL.

Adivinhar domínios revelou-se surpreendentemente bom. Um fornecedor bloqueava totalmente o tráfego de servidores, outro devolvia resultados irrelevantes; simplesmente experimentar os domínios óbvios encontrou sites que as pesquisas tinham falhado.

#Também «avariado» exige uma fasquia alta

Depois surgiu o problema inverso: sites marcados como avariados que abriam normalmente no browser. Causas:

• Páginas anti-bot que devolviam 403 ou um desafio.
• O www funcionava mas o domínio simples não, ou vice-versa.
• Servidores lentos que ultrapassavam um timeout curto.

Agora um site só está avariado depois de uma falha de DNS ou de um 404/410 definitivo em todas as variantes de URL. As páginas de proteção contam como funcionais. Os timeouts contam como desconhecidos.

#As evidências junto ao veredicto

Cada veredicto guarda o que foi encontrado: o domínio correspondente, os códigos de cada variante, o título da página e as fotos descobertas. Quando alguém contesta um resultado, a resposta está no ecrã em segundos. Isso transformou a ferramenta de algo de que se duvida em algo em que se confia.

#Respeite os sites que verifica

Um verificador automático continua a ser um visitante. Identifica-se, usa timeouts curtos, descarrega só o que precisa e não sobrecarrega nenhum servidor. As fotos encontradas na análise passam por um endpoint que só aceita imagens abaixo de um certo tamanho e recusa endereços de rede privada — proteção básica contra abusos.

#O que se pode generalizar

• A ausência de evidência não é evidência de ausência. Construa o «desconhecido» desde o primeiro dia.
• Combine sinais independentes em vez de depender de um só.
• Defina limiares assimétricos: quanto mais custa um rótulo errado, mais evidências deve exigir.
• Guarde as evidências junto a cada decisão automática.
• Invista num sinal de confiança antes de acrescentar muitos fracos.

A arquitetura está descrita em mais detalhe no estudo de caso sobre verificação de presença online.