Por qué «no se encontró ninguna web» suele ser falso
Lecciones de construir un sistema que comprueba si un negocio tiene una web que funciona: búsquedas bloqueadas, protección antibots y diseñar para lo «desconocido».
3 min de lecturaGryffin Forge
Comprobar si un negocio tiene web parece trivial: buscas el nombre y miras si aparece una web. Construir una herramienta que lo haga de forma automática, a escala y bien me enseñó más sobre calidad de datos que cualquier otra parte del proyecto.
La primera versión: segura de sí misma y equivocada
La primera versión buscaba el nombre y la zona del negocio. Si no aparecía ninguna web plausible en los resultados, lo marcaba como sin web. El resultado fue una larga lista de negocios aparentemente sin web.
Cuando revisé a mano una muestra, la mayoría tenían webs perfectamente válidas.
El proveedor de búsqueda había devuelto malos resultados, el nombre era genérico o la web simplemente no estaba bien indexada. La herramienta había convertido no la he encontrado en no existe: el error más común en la investigación automatizada.
Un modelo de datos capaz de decir «desconocido»
La solución empezó en el modelo de datos, no en el código. La presencia online de un negocio tiene ahora cuatro estados:
- Tiene web: encontrada y accesible.
- Web floja: accesible, pero sin lo básico (versión móvil, contacto, HTTPS).
- Rota: seguro que no funciona.
- Desconocido: no hay pruebas suficientes en ningún sentido.
«Sin web» solo se asigna cuando lo confirma una fuente fiable y autorizada. La falta de un resultado de búsqueda nunca puede producirlo.
Varias señales independientes
En lugar de una sola búsqueda, el sistema combina ahora:
- Una fuente de búsqueda en el servidor para el nombre y la zona.
- Dominios candidatos generados a partir del nombre (
fadedistrict.co.uk,fade-district.com…) y comprobados directamente. - Análisis de la web de cada candidato, con varias variantes de URL.
Adivinar dominios resultó sorprendentemente eficaz. Un proveedor bloqueaba por completo el tráfico de servidores y otro devolvía resultados irrelevantes; probar simplemente los dominios evidentes encontró webs que las búsquedas no habían visto.
«Rota» también exige un listón alto
Luego apareció el problema contrario: webs marcadas como rotas que se abrían con normalidad en el navegador. Causas:
- Páginas antibots que devolvían 403 o un desafío.
wwwfuncionaba pero el dominio sin él no, o al revés.- Servidores lentos que superaban un timeout corto.
Ahora una web solo está rota tras un fallo de DNS o un 404/410 definitivo en todas las variantes de URL. Las páginas de protección cuentan como funcionales. Los timeouts cuentan como desconocido.
Las pruebas junto al veredicto
Cada veredicto guarda lo que se encontró: el dominio coincidente, los códigos de cada variante, el título de la página y las fotos descubiertas. Cuando alguien discute un resultado, la respuesta está en pantalla en segundos. Eso convirtió la herramienta de algo de lo que se duda en algo en lo que se confía.
Respeta las webs que compruebas
Un comprobador automático sigue siendo un visitante. Se identifica, usa timeouts cortos, descarga solo lo que necesita y no sobrecarga ningún servidor. Las fotos encontradas durante el análisis pasan por un endpoint que solo acepta imágenes por debajo de cierto tamaño y rechaza direcciones de red privada: protección básica contra abusos.
Qué se puede generalizar
- La ausencia de pruebas no es prueba de ausencia. Incluye lo «desconocido» desde el primer día.
- Combina señales independientes en lugar de depender de una sola.
- Fija umbrales asimétricos: cuanto más cueste una etiqueta errónea, más pruebas debe exigir.
- Guarda las pruebas junto a cada decisión automática.
- Invierte en una señal fiable antes de añadir muchas débiles.
La arquitectura se describe con más detalle en el caso práctico de verificación de presencia web.