«دسترسی کاذب»؛ دلیل رد درخواست‌های ربات‌های AI در لایه‌های امنیتی

اگر امروز برای سئو (SEO) وب‌سایت خود هزینه می‌کنید، احتمالاً نیمی از تلاش‌های شما در یک دیوار نامرئی متوقف شده است. باید بدانید که حتی اگر سایت شما در مرورگر بی‌نقص باز شود، ربات‌های هوش مصنوعی ممکن است هرگز تک‌بایتی از محتوای شما را نبینند. در حالی که توسعه‌دهندگان به شدت روی رندرینگ سمت سرور (SSR) و ساختارهای JSON-LD تمرکز کرده‌اند، مانع واقعی اغلب یک لایه نامرئی از امنیت لبه (Edge Security) است که خزنده‌های هوش مصنوعی را پیش از آنکه حتی به سرور اصلی (Origin Server) برسند، رد می‌کند. این لایه‌ای است که در زیر تمام لایه‌هایی قرار دارد که همه درباره آن‌ها صحبت می‌کنند و در هر ابزاری که به طور معمول برای بررسی سایت استفاده می‌کنید، کاملاً نامرئی است.

این شکاف اطلاعاتی به این دلیل رخ می‌دهد که اکثر مالکان سایت‌ها برای تأیید دسترسی، به تست‌های مرورگر یا فایل‌های robots.txt تکیه می‌کنند. اما در واقعیت، ما با دو نوع «نه» متفاوت روبرو هستیم. یک فایل robots.txt صرفاً یک درخواست مودبانه است؛ چیزی شبیه به یک «یادداشت چسبانده شده به در» که می‌گوید «لطفاً وارد نشوید». یک خزنده مودب آن را می‌خواند و برمی‌گردد؛ یک خزنده بی‌ادب آن را نادیده می‌گیرد. در هر دو صورت، این یادداشت هرگز با بایت‌های محتوای شما تماس پیدا نمی‌کند.

گیت‌بان واقعی، دیواره آتش اپلیکیشن وب (WAF) یا شبکه توزیع محتوا (CDN) است. این همان «در» واقعی است. WAF در لبه شبکه به درخواست پاسخ می‌دهد، پیش از آنکه هر چیزی به سرور اصلی شما برسد. این لایه یک کد ۴۰۳ (Forbidden)، کد ۴۲۹ (Too Many Requests) یا یک چالش جاوااسکریپت (JavaScript Challenge) ارسال می‌کند که ربات قادر به حل آن نیست. در این حالت، کد HTML پشت آن در می‌تواند یک اثر هنری باشد یا یک صفحه خالی، اما ربات هیچ‌کدام را نمی‌بیند. ربات فقط کد وضعیت (Status Code) را می‌بیند. این چالش‌ها در برخی معماری‌های پیشرفته‌تر شدیدتر است؛ برای مثال در معماری Anubis، تضاد میان دسترسی کاربران و امنیت تهاجمی بر روی ابزارهای استخراج داده به شدت بررسی شده است.

همان‌طور که در تحلیل‌های قبلی ما درباره امنیت مدل‌های بازمتن اشاره کردیم، لایه‌های حفاظتی اغلب بدون دخالت مستقیم کاربر فعال می‌شوند. داده‌های Cloudflare Radar که در ۱۸ جولای ۲۰۲۶ منتشر شد، مقیاس این مسدودسازی نامرئی را آشکار می‌کند. طبق نمای ۷ روزه داشبورد AI Insights، توزیع پاسخ‌های HTTP ارائه شده به ربات‌ها و خزنده‌های هوش مصنوعی به شرح زیر است:

• ۲۰۰ OK: ۷۳.۶٪
• ۴۰۳ Forbidden: ۵.۲٪
• ۴۲۹ Too Many Requests: ۱.۳٪
• ۵۰۳: ۱.۱٪

این بدان معنای است که بیش از یک مورد از هر پانزده درخواست خزنده هوش مصنوعی، به طور فعال در لبه شبکه رد می‌شود. این درخواست‌ها صرفاً اولویت‌بندی نشده‌اند، بلکه «رد» شده‌اند. اکثر این مسدودسازی‌ها تصمیمات آگاهانه مالک سایت نیستند؛ بلکه اغلب نتیجه مجموعه‌قوانین (Rulesets) مدیریت شده پیش‌فرض WAF، یک دکمه «مسدود کردن ربات‌های AI» است که در سال ۲۰۲۴ فعال شده، یا نمره مبارزه با ربات (Bot-fight score) است که بیش از حد بالا تنظیم شده است.

داده‌های ردیابی نشان می‌دهد GPTBot، CCBot و ClaudeBot بیشترین میزان مسدودشدگی را در دامنه‌های برتر دارند. بخش زیادی از این مسدودسازی‌ها ارثی است، نه انتخابی. چون مرورگر مالک سایت در لیست سیاه نیست، او تصور می‌کند سایت در دسترس است. شما دارای یک IP خانگی و یک User-Agent مرورگر کروم هستید؛ بنابراین از تمام فیلترها عبور می‌کنید. مسدودسازی در واقع متوجه دسته‌ای از بازدیدکنندگان است که شما هرگز جزو آن‌ها نخواهید بود. در مقابل، برخی ابزارهای پیشرفته مانند HatFetch با استفاده از استراتژی ارتقای تدریجی سعی می‌کنند این سدهای شناسایی ربات را دور بزنند تا دسترسی خود را تأمین کنند.

حقیقت پنهان در لاگ‌ها

هر ابزاری که برای تایید سایت استفاده می‌کنید — از مشاهده کد منبع (View Source) تا بررسی robots.txt و بارگذاری صفحه — از طرف شماست، نه از طرف GPTBot. چون مرورگر دروغ می‌گوید و robots.txt فقط جنبه توصیه دارد، تنها جایی که حقیقت در آن نهفته است، لاگ‌های دسترسی سرور (Server Access Logs) است. لاگ دسترسی دروغ نمی‌گوید؛ برای هر درخواست واقعی، یک ردیف دارد که User-Agent بازدیدکننده و کد وضعیت دقیق بازگشتی را ثبت می‌کند.

برای شناسایی حالت شکست (Failure Mode) که در آن robots.txt کاملاً باز است اما لبه شبکه در حال مسدود کردن است، می‌توانید لاگ‌های دسترسی خود را برای عامل‌های خاصی که اهمیت دارند، grep کنید:

grep -E "GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-SearchBot|PerplexityBot|Google-Extended" access.log | awk '{print $9}' | sort | uniq -c

در این خروجی، ۲۰۰ به این معنی است که ربات صفحه را دریافت کرده است، ۴۰۳ به این معنی است که لبه شبکه آن را رد کرده و ۴۲۹ به این معنی است که شما نرخ درخواست‌های آن را محدود کرده و آن را به سکوت رانده‌اید. من مواردی را دیده‌ام که ماه‌ها محتوا تولید شده اما هیچ ارجاعی در ChatGPT یا Perplexity وجود نداشته، تا اینکه در یک بازرسی دقیق مشخص شد Cloudflare در تمام این مدت به GPTBot کد ۴۰۳ می‌داد.

خطر اعتماد به User-Agent

تلاش برای رفع این مشکل از طریق لیست سفید کردن (Allowlisting) هر درخواستی که عبارت "GPTBot" در User-Agent آن باشد، یک اشتباه حیاتی است. رشته‌های User-Agent صرفاً متونی هستند که هر کسی می‌تواند آن‌ها را تایپ کند. یک ربات استخراج قیمت (Price Scraper) می‌تواند خودش را GPTBot بنامد و از قانون سخاوتمندانه جدید شما به راحتی عبور کند.

ردیابی‌های شفافیت Cloudflare این ریسک را برجسته می‌کند. تا اواسط ۲۰۲۶، اپراتورهایی مانند ByteDance به عنوان «تأییدنشده» نمایش داده می‌شوند؛ این ثابت می‌کند که User-Agent به تنهایی نمی‌تواند برای احراز هویت مورد اعتماد باشد.

مسیر دسترسی تأییدشده

احراز هویت واقعی بر اساس منشأ (Origin) است، نه نام. در حال حاضر دو روش قابل اعتماد برای اطمینان از ورود ربات‌های درست وجود دارد:

• تأیید محدوده IP: اپراتورهایی مانند OpenAI و Anthropic محدوده‌های IP خزنده‌های خود را از طریق فایل‌های JSON منتشر می‌کنند (به عنوان مثال: openai.com/gptbot.json ، openai.com/searchbot.json و openai.com/chatgpt-user.json). برای تأیید، سرور باید IP درخواست‌دهنده را با Reverse-DNS بررسی کند تا تأیید شود Hostname متعلق به آن شرکت است و سپس آن را دوباره به همان IP برگرداند (Forward-resolve). اگر هر یک از این مراحل شکست بخورد، درخواست‌دهنده یک جعل‌کننده (Spoofer) است.
• امضاهای رمزنگاری: صنعت به سمت Web Bot Auth حرکت می‌کند، که یک پیش‌نویس IETF است (draft-meunier-web-bot-auth-architecture بر پایه RFC 9421). این سازوکار به خزنده‌ها اجازه می‌دهد هر درخواست را با یک کلید Ed25519 امضا کنند، بنابراین هویت آن‌ها ثابت می‌شود، نه اینکه صرفاً ادعا شود.

Cloudflare این قابلیت را در برنامه Verified Bots خود با یک دایرکتوری اختصاصی برای Signed Agents ادغام کرد؛ عامل ChatGPT در سال ۲۰۲۵ در اولین گروه امضا شده قرار داشت. در اواخر سال ۲۰۲۵، AWS WAF نیز پشتیبانی از Web Bot Auth را برای اجازه خودکار به عامل‌های تأییدشده اضافه کرد. اگرچه Web Bot Auth هنوز یک پیش‌نویس فعال IETF است و یک استاندارد تصویب شده نیست، اما حرکت Cloudflare، OpenAI، Anthropic و AWS آن را به جهت‌گیری پیش‌فرض (de-facto) تبدیل کرده است.

گام‌های عملی برای بازرسی (Audit)

برای یک توسعه‌دهنده عمل‌گرا، بازرسی ساده است و باید یک بعدازظهر زمان ببرد، نه یک پروژه کامل. مرورگر را چک نکنید؛ لاگ‌ها را چک کنید. لاگ‌های دسترسی یک هفته را استخراج کنید، برای User-Agentهای هوش مصنوعی فیلتر کنید و به کدهای وضعیت نگاه کنید. اگر کدهای ۴۰۳ یا ۴۲۹ می‌بینید، قانون مربوطه را پیدا کنید. این تقریباً همیشه یک مجموعه‌قوانین مدیریت شده، تنظیمات «مسدود کردن ربات‌های AI» یا یک نمره Bot-fight بیش از حد سخت‌گیر است — نه خط کدی که خودتان نوشته باشید.

خزنده‌هایی را که می‌خواهید با IPهای تأییدشده یا Web Bot Auth در لیست سفید قرار دهید، هرگز تنها بر اساس User-Agent این کار را نکنید. در غیر این صورت، ریسک می‌کنید که خزنده‌ای را که می‌خواهید مسدود کرده و خزنده‌ای را که نمی‌خواهید، پذیرفته باشید.

این تغییر، فرض بنیادی سئو برای هوش مصنوعی (AI SEO) را تغییر می‌دهد. HTML شما آخرین چیز در مسیر درخواست است، نه اولین. پیش از آنکه ربات تک‌بایتی از آن را بخواند، درخواست باید از DNS، CDN، WAF، محدودکننده نرخ (Rate Limiter) و نمره مدیریت ربات عبور کند. هر یک از این‌ها می‌توانند درخواست را با کد وضعیتی به پایان برسانند که شما هرگز نمی‌بینید. ادعای «در مرورگر من کار می‌کند» یک ادعای ضعیف است؛ تنها سؤال درست این است: ربات چه کد وضعیتی دریافت کرد؟

اما این تنها بخش فنی ماجراست؛ اثر این مسدودسازی‌ها بر اقتصاد تولید محتوا و رتبه‌بندی‌های آینده را در گزارش بعدی بررسی خواهیم کرد.