بیشتر بحث‌هایی که درباره دیده‌شدن در جستجوی هوش مصنوعی می‌شود، روی محتوای ساخت‌یافته، تعریف دقیق موجودیت (Entity) و مجوزهای درست در robots.txt متمرکز است. اما موضوعی بسیار پایه‌ای‌تر وجود دارد که مقدم بر همه این‌هاست و تقریباً هیچ ناشر دیجیتالی درباره‌اش حرف نمی‌زند.
OpenAI از یک لایه بررسی امنیتی مرکزی استفاده می‌کند تا تصمیم بگیرد ابزارهای مرور وبش اجازه اتصال به یک سایت مشخص را دارند یا نه. اگر سایتی توسط این سیستم — که در کدها و مستندات داخلی OpenAI با نام Aura شناخته می‌شود و نباید آن را با Atlas اشتباه گرفت — علامت‌گذاری شود، ابزارهایی مثل Browser Use در Codex و جستجوی زنده ChatGPT از باز کردن آن خودداری می‌کنند؛ حتی اگر تنظیمات کاربر و قوانین robots.txt شما کاملاً باز باشد.
اگرچه بیشتر سایت‌ها هرگز به این محدودیت‌ها برخورد نمی‌کنند، شرکت‌های معمولی و شناخته‌شده هم می‌توانند ناگهان وارد این لیست سیاه شوند. متأسفانه در حال حاضر هیچ راه عمومی برای فهمیدن دلیل بلاک‌شدن یا درخواست بازبینی وجود ندارد.
این بلاک چیست و چه چیزی نیست؟
برای درک درست این مسئله، اول باید یک سوءتفاهم رایج درباره نحوه کار خزنده‌های وب را برطرف کنید. تفاوت خزنده‌های جمع‌آوری داده و ابزارهای مرور زنده، در تشخیص اینکه چرا یک ایجنت نمی‌تواند صفحه‌ای را باز کند حیاتی است. اگر این مفاهیم برایتان تازه‌اند، مطالعه راهنمای نحوه کار موتورهای جستجوگر تصویر روشنی به شما می‌دهد.
OpenAI به‌طور رسمی چند خزنده وب معرفی کرده است: GPTBot برای آموزش مدل‌ها، OAI-SearchBot برای قابلیت‌های جستجو و ChatGPT-User برای درخواست‌های مستقیم کاربران. این خزنده‌ها آدرس‌های IP خود را منتشر می‌کنند و از قوانین استاندارد وب پیروی می‌کنند، اما جدا از قوانین امنیتیِ کنترل‌کننده ایجنت‌ها عمل می‌کنند.
بررسی امنیت سایت مثل یک نگهبان جداگانه تصمیم می‌گیرد که ابزارهای خودکار اجازه بازدید از یک لینک خاص را دارند یا نه. OpenAI اشاره می‌کند محدودیت‌های مروری برای جلوگیری از باز کردن محتوای خطرناک وجود دارد، اما توضیح نمی‌دهد این سیستم دقیقاً چطور کار می‌کند.
صفحات راهنمای رسمی می‌گویند ایجنت‌ها به دلایل امنیتی، ایمنی و انطباق ممکن است با استفاده از یک لیست سیاه سراسری از بازدید بعضی سایت‌ها منع شوند. مستندات سیستم هم اضافه می‌کند مرورِ سایت‌های مرتبط با فعالیت غیرقانونی بلاک است؛ تدبیری که برای همه منطقی و قابل قبول است.
چیزی که OpenAI علنی نمی‌کند، ساختار فنی پشت این سیستم است؛ چیزی که در ترافیک شبکه می‌توان آن را به شکل درخواست‌هایی به chatgpt.com/backend-api/aura/site_status دید. وقتی سایتی بلاک علامت‌گذاری شود، این تصمیم به مدت ۲۴ ساعت به‌صورت محلی ذخیره می‌شود و هیچ مسیر رسمی برای اعتراض یا پرس‌وجو به مالک سایت داده نمی‌شود.
دو نکته فنی دیگر هم هنگام بررسی عملکرد این بلاک‌ها اهمیت ویژه‌ای دارند؛ فهم این جزئیات توضیح می‌دهد چرا بلاک‌های اشتباه می‌توانند برای یک سایت دردسرساز باشند.
خطا به سمت بسته‌شدن است، نه باز
مهندسان OpenAI گفته‌اند اختلالات شبکه هنگام بررسی وضعیت، به‌صورت پیش‌فرض به اجازه دسترسی می‌انجامد؛ اما بلاک‌های صریح سایت کاملاً سخت‌گیرانه اعمال می‌شوند. حتی اگر مدیران یک شرکت در سیستم خودشان قوانین اجازه سفارشی تعریف کرده باشند، تصمیم داخلی OpenAI بر آن‌ها غلبه می‌کند و از بارگذاری صفحه جلوگیری می‌شود.
نمی‌دانیم چه چیزی دامنه‌ای را وارد لیست می‌کند
چون درخواست‌های ارسالی به API وضعیت، جزئیات گفتگو را همراه لینک‌های وب ارسال می‌کنند، بعضی پژوهشگران حدس می‌زنند تاریخچه پرامپت‌های خاصی ممکن است ناخواسته بلاک سراسری سایت را فعال کند. هر چه دلیل نهایی باشد، پلتفرم‌های تجاری مطمئن — از رسانه‌های شناخته‌شده گرفته تا برندهای بزرگ — با بلاک‌های بی‌توضیحی مواجه می‌شوند که مانع بازدید ایجنت‌ها از آن‌ها می‌شود.
مدرک زنده: ناشری شناخته‌شده که ChatGPT نمی‌تواند بازش کند
نویسنده این تحلیل در حال مشاوره به یک ناشر بین‌المللی رسانه‌ای بود که محتوای رسمی خبری و مجله‌ای منتشر می‌کند و اخیراً یک کمپین تبلیغاتی ۲۴ ساعته با OpenAI اجرا کرده بود تا این پلتفرم را ارزیابی و یک کانال پشتیبانی اضافه بسازد. با وجود robots.txt کاملاً باز و پشتیبانی از ابزارهای OpenAI، ناشر با مشکلات دسترسی غیرقابل توضیح در وب‌سایت اصلی‌اش مواجه شد.
از ماه مه ۲۰۲۶، ChatGPT بارها نتوانست صفحات وب ناشر را بارگذاری کند و بدون هیچ تلاشی برای اتصال، پیام‌های خطای عمومی برمی‌گرداند. لاگ‌های دقیق سرور نشان داد هیچ ترافیکی از ChatGPT هرگز به سایت نرسیده؛ یعنی بلاک در مرحله‌ای بالاتر اتفاق می‌افتد.
تست‌هایی که با Codex CLI و اپلیکیشن‌های دسکتاپ انجام شد تأیید کرد Browser Use به‌طور صریح از بازدید سایت خودداری می‌کند. پیام امنیتی به‌طور مشخص قوانین site-safety را تنها دلیل متوقف‌کردن درخواست اعلام می‌کرد.
«Browser Use این اقدام را به دلیل سیاست امنیتی مرورگر رد کرد. دلیل: سیاست site-safety این اقدام را بلاک می‌کند؛ هیچ پرامپت مجوز کاربر یا بازبینی خودکاری تلاش نشد. مرور وب روی [دامنه] مجاز نیست.»
علاوه بر این، سیستم ایجنت به مدل زیرین دستور می‌داد هیچ راهکار جایگزینی برای بارگذاری صفحه امتحان نکند؛ نشانه‌ای که ثابت می‌کرد این قانون در سطح پلتفرم به‌سختی اجرا می‌شود.
یک سری تست مقایسه‌ای ثابت کرد این خطای اتصال ناشی از برچسب امنیتی اشتباه است، نه مشکل در پیکربندی سایت. با تغییر یک متغیر در هر بار و در چت‌های مختلف، مدرک واضحی جمع شد که سایت به‌طور عمدی بلاک شده است:
- در همان جلسه، دو پلتفرم رقیب مستقیم روزنامه و مجله دیجیتال بدون مشکل بارگذاری شدند.
- صفحه یک روزنامه ثالث که با فناوری خودِ برند اجرا می‌شد اما روی دامنه دیگری میزبانی می‌شد، هم بدون مشکل باز شد؛ همان فناوری، نام میزبان متفاوت، بدون بلاک.
- مجوزهای کروم روی «همیشه مجاز» تنظیم شده بود و ورود صریحی برای برند ثبت شده بود؛ باز هم بلاک برقرار بود.
- چند هفته بعد، هر پنج URL تست‌شده (سایت اصلی، زیردامنه‌ها، صفحات مقالات) همچنان بلاک بودند.
همزمان آمار ترافیک سایت فقط حدود ۵ هزار اتصال موفق از خزنده‌های آموزشی OpenAI در ۳۰ روز گذشته را نشان می‌داد. برای سایتی با این اندازه، این رقم در مقایسه با خزنده‌های بزرگ دیگر هوش مصنوعی — گوگل با ۴۷۷ هزار و Anthropic با ۵۶۴ هزار — تقریباً هیچ است؛ یعنی کل دسترسی خزش، حتی با وجود بلاک کامل مرور ایجنت‌ها، در حداقل بود.
مکاتبات مداوم با تیم پشتیبانی فنی OpenAI جزئیات جالبی آشکار کرد. بررسی‌های اولیه کارکنان خط مقدم پشتیبانی به‌سرعت به ارجاع تیکت به تیم‌های تخصصی داخلی منجر شد.
«…برای تعیین اینکه آیا [دامنه] مشمول محدودیت site-safety در سمت OpenAI است و شناسایی اقدامات بعدی مناسب.»
ایمیل‌های بعدی تأیید کردند گروه‌های تخصصی فعالانه در حال بررسی‌اند که آیا بلاک این دامنه عمدی بوده یا نه. این بازبینی داخلیِ در جریان، نبودِ کامل گزینه‌های مدیریتی شفاف و خودکار را برای مالکان سایت‌های تحت تأثیر نشان می‌دهد.
«پرونده را به تیم تخصصی منتقل می‌کنیم تا بلاک را بررسی و مشخص کند که آیا انتظار رفته است یا نه.»
این وضعیت به‌طور مستقیم با صفحات راهنمای عمومی OpenAI در تناقض است؛ صفحاتی که معمولاً شکست مرور را به قوانین امنیتی خودِ سایت نسبت می‌دهند. چون سیستم ناشر سوابق ترافیکی تمیز و بازدیدهای سالم خزنده‌ها را داشت، بلاک به‌وضوح از داخل زیرساخت OpenAI اعمال می‌شد.
چطور بفهمید به‌اشتباه بلاک شده‌اید؟
اگر مشکوکید سایت‌تان قربانی یک بلاک امنیتی اشتباه شده، بلافاصله یک برنامه تست مرحله‌به‌مرحله را اجرا کنید. رویکرد ساخت‌یافته به شما کمک می‌کند پیش از مراجعه به پشتیبانی، مدرک فنی محکم جمع کنید:
- همان URLها را روی سطوح مختلف تست کنید: fetch زنده ChatGPT (درخواست باز کردن یک URL مشخص)، مرورگر ابری ChatGPT، و Browser Use و Computer Use در Codex. بلاک site-safety معمولاً روی بیش از یک سطح ظاهر می‌شود.
- در همان جلسه، سایت‌های رقیب را به‌عنوان کنترل باز کنید. اگر دو سه سایت رقیب بلافاصله بارگذاری شدند و سایت شما نشد، مشکل عمومی ایجنت‌ها منتفی است.
- لاگ‌های CDN و سرور را برای نبودِ درخواست بررسی کنید. بلاک سمت سایت ردپا دارد: کد 403، صفحه چالش یا رویداد WAF. بلاک سمت OpenAI در زمانِ تلاش ناموفق، هیچ درخواستی در لاگ‌های شما ثبت نمی‌کند.
- تحلیل‌های خزنده را چک کنید. اگر GPTBot، OAI-SearchBot یا ChatGPT-User از سایت شما پاسخ 2xx می‌گیرند اما ایجنت‌ها رد می‌شوند، مشکل در بالادستِ سایت شماست.
- لبه‌ها را تست کنید: زیردامنه‌ها، URLهای عمیق مقالات و در صورت امکان صفحه‌ای ثالث که فناوری شما را روی دامنه دیگری اجرا می‌کند. طبقه‌بندی در سطح نام میزبان، دو مورد اول را بلاک و مورد سوم را مجاز می‌کند.
- متن دقیق خطا را ثبت کنید. عبارت‌هایی مثل «The site-safety policy blocks this action»، «Browser use is not permitted on…» و «URL cannot be opened (non-retryable error)» نمونه‌های رایج هستند. از آن‌ها اسکرین‌شات بگیرید و زمان‌سنجی را همراه منطقه زمانی یادداشت کنید.
- استک خودتان را هم رد کنید: robots.txt، قوانین WAF و مدیریت ربات (از جمله تنظیمات بات‌های هوش مصنوعی کلودفلر)، ژئوبلاک و ریت‌لیمیت را بازبینی کنید. اگر از CDN داخلی مثل ابر آروان استفاده می‌کنید، تنظیمات ضدربات آن را هم چک کنید. گاهی بلاک واقعاً از سمت خودتان است؛ پیش از شکایت مطمئن شوید.
اگر تست‌ها در ابزارهای مختلف نشان داد درخواست‌ها رد می‌شوند در حالی که لاگ سرور شما هیچ بازدید ورودی از ایجنت‌ها ثبت نکرده، تقریباً قطعی است که یک بلاک داخلی در کار است. برای بازبینی و ویرایش robots.txt در وردپرس ابزارهایی مثل افزونه Rank Math Pro ادیتور داخلی دارند و برای قوانین سطح سرور، راهنمای افزایش امنیت وردپرس با htaccess چک‌لیست کاملی به شما می‌دهد. اگر جمع‌آوری این مدارک یا بررسی لاگ‌ها و فایروال برایتان پیچیده بود، خدمات تخصصی افزایش سرعت وردپرس و ووکامرس این بررسی‌ها را با ضمانت برایتان انجام می‌دهد.
چه کار می‌توانید بکنید؟
چون هیچ صفحه خودخدمتی برای اصلاح طبقه‌بندی Aura وجود ندارد، رفع یک بلاک اشتباه نیازمند مدارک کامل و پیگیری مداوم است. مدیران سایت باید بسته‌های تشخیصی شفافی برای پشتیبان‌گیری از درخواست‌هایشان آماده کنند:
- بسته مدرک بسازید: اسکرین‌شات خطاها همراه زمان‌سنجی، تست‌های کنترل رقبا، استخراج لاگِ نشان‌دهنده نبود درخواست ورودی، تحلیل خزنده‌ها نشان‌دهنده خزش موفق OpenAI و فایل robots.txt.
- تیکت پشتیبانی باز کنید و شماره پرونده‌ها را نگه دارید. اگر بیش از یک محصول تحت تأثیر است، در هر پرونده اشاره کنید و صریحاً بخواهید پرونده‌ها به هم لینک شوند. فرض نکنید OpenAI خودش این کار را می‌کند.
- سه سؤال مشخص بپرسید: اول، آیا دامنه طبقه‌بندی site-safety دارد و اگر دارد، چرا؟ دوم، چه سطوحی را در بر می‌گیرد: fetch زنده ChatGPT، جستجو از طریق OAI-SearchBot، مرورگر ابری یا ایجنت، و Codex؟ سوم، فرآیند درخواست بازبینی چیست؟
- از هر رابطه‌ای که دارید استفاده کنید: تبلیغ‌دهندگان، شرکای ناشر و مشتریان سازمانی باید این موضوع را از طریق مدیر حساب‌ها هم مطرح کنند، نه فقط از مسیر پشتیبانی.
- سراغ دورزدن نروید. ابزارها صریحاً به ایجنت‌ها می‌گویند سیاست را دور نزنند و قوانین استفاده OpenAI نیز دورزدن ملاحظات امنیتی را ممنوع کرده است. تلاش برای قاچاق‌کردن یک طبقه‌بندی، سریع‌ترین راه برای تبدیل اشتباه مثبت به بلاک موجه است.
- پایش کنید. URLهای کلیدی‌تان را به‌صورت دوره‌ای دوباره تست و نتایج را ثبت کنید. باید بدانید چه زمانی رفع می‌شود و آیا برمی‌گردد.
اثر تجاری
برای سنجش عملکرد سایت در جستجوی هوش مصنوعی، شرکت‌ها معمولاً سراغ دیده‌شدن، درستی اطلاعات و ترافیک ارجاعی می‌روند. اگر به‌اشتباه توسط Aura بلاک شده باشید، عملاً کل حضورتان در اکوسیستم OpenAI صفر می‌شود و این می‌تواند عواقب تجاری جدی داشته باشد.
با حرکت کاربران به سمت ایجنت‌های خودکاری که وب را جستجو و کارها را مستقیم انجام می‌دهند، سایت‌های بلاک‌شده به‌طور خودکار از گزینه‌ها حذف می‌شوند. وقتی ایجنت نمی‌تواند سایت شما را باز کند تا اطلاعات زنده بگیرد یا کاری انجام دهد، به سادگی سراغ منبع دیگری می‌رود.
بیشتر سازمان‌ها این را مشکل دیده‌شدن تلقی می‌کنند و منابع زیادی برای حل مسئله نبودِ حضور در ChatGPT خرج می‌کنند؛ در حالی که بلاک پنهان یعنی می‌توانید بهترین کمپین GEO/AEO تاریخ — بهینه‌سازی برای موتورهای مولد پاسخ — را هم اجرا کنید و باز هم نتیجه‌ای نبینید.
در تست‌های نویسنده، سایت‌های خبری رقیب در همان جلسات گفتگو بدون هیچ دردسری باز می‌شدند. نتیجه اینکه هر وقت ایجنت برای پاسخ‌دادن به دسترسی زنده وب نیاز پیدا کند، برندهای رقیبِ در دسترس، ترافیک را به‌صورت پیش‌فرض می‌برند.
بدون دسترسی مستقیم به صفحات اصلی سایت، ChatGPT پاسخ‌ها را از منابع ثانویه، پست‌های فروم و اخبار قدیمی می‌سازد؛ برای برندهای جاافتاده‌ای که به اعتماد و دقت وابسته‌اند، این یعنی ریسک جدی برای اعتبار عمومی.
چون بلاک‌های Aura اتصال را قبل از خروج درخواست از OpenAI قطع می‌کنند، لاگ‌های سرور وب هیچ ردی از بازدید ناموفق ثبت نمی‌کنند. مگر اینکه تیم شما به‌طور مشخص اقدامات ایجنت‌ها را تست کند، از دست رفتن بازدیدهای بالقوه کاملاً از چشم تحلیل‌هایتان پنهان می‌ماند. رفتارهای نامتعارف این مسیر جدید — مثل اینکه جستجوی هوش مصنوعی کاربران را ۳ برابر بیشتر از گوگل به صفحات ۴۰۴ می‌فرستد — نشان می‌دهد اکوسیستم هنوز جوان است؛ برای سایت‌های فارسی‌زبان که سهم رو به رشدی از کاربران ChatGPT دارند، شروع پایش از همین امروز یعنی مزیت رقابتی.
مالکان سایت‌های تحت تأثیر نه صفحه وضعیت دارند، نه قوانین شفاف، نه فرم اعتراض رسمی و نه زمان تقریبی رفع مشکل. جالب‌تر اینکه تبلیغ‌دهندگانِ پرداخت‌کننده ممکن است در حال هزینه‌کردن برای نمایش در ChatGPT باشند در حالی که ایجنت‌های مرور آن حتی اجازه باز کردن لینک‌هایشان را ندارند.
جمع‌بندی
منطقی است که OpenAI دسترسی به سایت‌های واقعاً خطرناک را برای جلوگیری از حملات تزریق پرامپت و کلاهبرداری وب محدود کند؛ ایجاد یک لایه امنیتی قوی بالاتر از انتخاب‌های کاربر، گام محافظت‌کارانه درستی برای ابزارهای هوش مصنوعیِ مرورکننده وب است.
اما هر سیستمی که بتواند شرکت‌های تجاری واقعی را بی‌صدا بلاک کند، باید ابزارهای مدیریتی مناسب — پیام‌های خطای شفاف و فرآیندهای بازبینی مستند — ارائه دهد. همان‌طور که موتورهای جستجو برای حل پنالتی‌های دستی ابزارهای وبمستر ساختند، پلتفرم‌های جستجوی هوش مصنوعی هم باید فرآیندهای مدیریتی روشنی برای مالکان سایت بسازند.
تا زمانی که چنین ابزارهایی فراهم نشده، مسئولان حضور جستجوی یک سازمان باید بررسی دسترسی ایجنت‌ها را جزئی از ممیزی‌های دوره‌ای جستجوی هوش مصنوعی خود کنند؛ از سئوی فنی و بهینه‌سازی تصاویر برای سئو و جستجوی مالتی‌مودال گرفته تا اطمینان از اینکه سایت شما نه‌فقط قابل خزش، بلکه قابل باز شدن توسط ایجنت‌های خودکار است.
