چرا «وب‌سایتی پیدا نشد» معمولاً اشتباه است

بررسی اینکه یک کسب‌وکار وب‌سایت دارد یا نه، کار ساده‌ای به نظر می‌رسد: نام را جستجو کنید و ببینید سایتی می‌آید یا نه. ساختن ابزاری که این کار را خودکار، در مقیاس بزرگ و دقیق انجام دهد، بیشتر از هر بخش دیگری از این پروژه به من دربارهٔ کیفیت داده یاد داد.

#نسخهٔ اول: مطمئن و اشتباه

نسخهٔ اول نام و منطقهٔ کسب‌وکار را جستجو می‌کرد. اگر هیچ سایت محتملی در نتایج ظاهر نمی‌شد، کسب‌وکار را بدون وب‌سایت علامت می‌زد. فهرست بلندی از کسب‌وکارهای ظاهراً بی‌سایت تولید کرد.

وقتی نمونه‌ای را دستی بررسی کردم، بیشترشان وب‌سایت‌های کاملاً خوبی داشتند.

ارائه‌دهندهٔ جستجو نتایج ضعیفی برگردانده بود، یا نام کسب‌وکار کلی بود، یا سایت به‌خوبی فهرست نشده بود. ابزار «پیدایش نکردم» را به «وجود ندارد» تبدیل کرده بود — رایج‌ترین اشتباه در پژوهش خودکار.

#مدل داده را طوری طراحی کنید که «نامعلوم» بگوید

راه‌حل از مدل داده شروع شد، نه از کد. حضور وب یک کسب‌وکار حالا چهار حالت دارد:

• سایت دارد — پیدا شده و در دسترس است.
• سایت ضعیف — در دسترس است اما موارد پایه را ندارد (چیدمان موبایل، اطلاعات تماس، HTTPS).
• خراب — قطعاً کار نمی‌کند.
• نامعلوم — شواهد کافی برای هیچ طرف نیست.

«بدون وب‌سایت» فقط وقتی داده می‌شود که یک منبع مطمئن و معتبر تأییدش کند. نبودِ نتیجهٔ جستجو هرگز نمی‌تواند آن را تولید کند.

#چند نشانهٔ مستقل

به‌جای یک جستجو، خط لوله حالا این‌ها را ترکیب می‌کند:

1. یک فید جستجوی سمت سرور برای نام و منطقه.
2. دامنه‌های احتمالی که از روی نام ساخته می‌شوند (fadedistrict.co.uk، fade-district.com…) و مستقیم بررسی می‌شوند.
3. اسکن سایت برای هر دامنهٔ احتمالی، با امتحان چند گونهٔ آدرس.

حدس زدن دامنه به‌طرز شگفت‌انگیزی قوی از آب درآمد. یک ارائه‌دهندهٔ جستجو ترافیک سرور را کاملاً مسدود کرد و دیگری نتایج نامربوط برمی‌گرداند؛ امتحان ساده‌ی دامنه‌های بدیهی سایت‌هایی را پیدا کرد که جستجوها از دست داده بودند.

#«خراب» هم به آستانهٔ بالا نیاز دارد

بعد مشکل برعکس پیدا شد: سایت‌هایی که خراب علامت خورده بودند اما در مرورگر به‌خوبی باز می‌شدند. علت‌ها:

• صفحه‌های محافظت ضد ربات که 403 یا یک چالش برمی‌گرداندند.
• www کار می‌کرد اما دامنهٔ بدون آن نه، یا برعکس.
• سرورهای کندی که از تایم‌اوت کوتاه بیشتر طول می‌کشیدند.

حالا سایت فقط بعد از شکست DNS یا خطای قطعی 404/410 روی همهٔ گونه‌های آدرس خراب حساب می‌شود. صفحه‌های محافظت آنلاین حساب می‌شوند. تایم‌اوت‌ها نامعلوم حساب می‌شوند.

#شواهد را کنار حکم نگه دارید

هر حکم آنچه را پیدا شده ذخیره می‌کند: دامنهٔ منطبق، کدهای وضعیت برای هر گونه، عنوان صفحه و هر عکسی که پیدا شده. وقتی کسی نتیجه‌ای را زیر سؤال می‌برد، جواب در چند ثانیه روی صفحه است. این ابزار را از چیزی که باید به آن شک کرد به چیزی تبدیل کرد که می‌شود به آن اعتماد کرد.

#به سایت‌هایی که بررسی می‌کنید احترام بگذارید

یک بررسی‌کنندهٔ خودکار هم یک بازدیدکننده است. خودش را معرفی می‌کند، تایم‌اوت‌های کوتاه دارد، فقط آنچه لازم دارد را دریافت می‌کند و هرگز یک میزبان را زیر فشار نمی‌گذارد. تصاویری که حین اسکن پیدا می‌شوند از طریق نقطهٔ پایانی‌ای پراکسی می‌شوند که فقط انواع تصویر زیر یک سقف حجم را می‌پذیرد و آدرس‌های شبکهٔ خصوصی را رد می‌کند — محافظت پایه در برابر سوءاستفاده از آن نقطهٔ پایانی.

#چه چیزی قابل تعمیم است

• نبودِ شاهد، شاهدِ نبودن نیست. «نامعلوم» را از روز اول در سیستم بسازید.
• به‌جای اعتماد به یک نشانه، نشانه‌های مستقل را ترکیب کنید.
• آستانه‌های نامتقارن بگذارید: هرچه برچسب اشتباه پرهزینه‌تر باشد، شواهد بیشتری لازم دارد.
• کنار هر تصمیم خودکار، شواهد را ذخیره کنید.
• پیش از اضافه کردن چند نشانهٔ ضعیف، برای یک نشانهٔ مطمئن هزینه کنید.

معماری با جزئیات بیشتر در مطالعهٔ موردی بررسی حضور وب توضیح داده شده.