تصور کنید وبسایتی دارید که تمام استانداردهای جدید را پیاده کرده است؛ فهرستی دقیق، ۱۸ نسخه پاکسازیشده از محتوا و یک فایل جامع برای دسترسی سریع. با این حال، در آزمون آمادگی Cloudflare، نمره افتضاح ۲۱ از ۱۰۰ را میگیرد. این اتفاق برای spintax.net رخ داد و حقیقتی تلخ را برملا کرد: بسیاری از توسعهدهندگان، یک قرارداد ساده در نامگذاری فایلها را با زیرساخت واقعی «خوانایی ماشینی» اشتباه میگیرند.
عاملهای هوش مصنوعی (AI Agents) — شبیه دستیارهای شخصی دیجیتالی که به جای خواندن ساده، میتوانند دستورات پیچیده را اجرا کنند — در حال تبدیل شدن از خزندههای ساده به کلاینتهای پیشرفتهای هستند که انتظار رعایت پروتکلهای استاندارد وب را دارند. طبق گزارش منتشر شده در ۲۸ ژوئیه ۲۰۲۶، بسیاری تصور میکنند ارائه فهرستی مثل llms.txt آخرین قدم در بهینهسازی برای AI است. اما واقعیت این است که عاملها برای یافتن بهترین فرمت محتوا، به مکانیزمهای قدیمی HTTP تکیه میکنند. این اسکنر، آمادگی سایت را در ۲۱ معیار و ۵ دستهبندی شامل کشفپذیری، دسترسی به محتوا، کنترل دسترسی باتها، کشف پروتکل و تجارت میسنجد.
همانطور که در تحلیلهای پیشین ما دربارهی استانداردهای دسترسی دادهها اشاره کردیم، تفاوت میان «قرارداد» و «مکانیزم» حیاتی است. شکست spintax.net در بخش دسترسی به محتوا (نمره صفر از یک) به دلیل نبود «مذاکره محتوا» (Content Negotiation) بود. وقتی یک اسکنر درخواستی با هدر Accept: text/markdown میفرستد، منتظر پاسخی با همان نوع محتواست. اگر سرور فقط text/html برگرداند، حتی اگر فایلهای Markdown در جای دیگری از سایت موجود باشند، تست شکست میخورد.
در حالی که llms.txt فقط یک قرارداد است (فایلی در مسیری مشخص که کلاینت باید از قبل بداند)، مذاکره محتوا یک مکانیزم است که به هر کلاینتی اجازه میدهد بدون دانستن ساختار سایت، فرمت Markdown را درخواست کند. برای حل این مشکل، تیم spintax.net از یک Cloudflare Pages Function به عنوان میانافزار (Middleware) استفاده کرد.
به نقل از مستندات فنی این پروژه، آنها از گزینه پیشفرض «Markdown for Agents» در پلنهای تجاری کلودفلر استفاده نکردند؛ زیرا تبدیلهای خودکار نمیتوانند قوانین سفارشی برای جداول و کارتهای پیچیده را مدیریت کنند. خروجی دستساز در اینجا بر خروجی عمومی اولویت داشت. این رویکرددقیق به محتوا، یادآور اهمیت کیفیت خروجی است؛ چنانکه بررسیهای ما نشان داد ویرایش انسانی محتوای تولید شده توسط هوش مصنوعی میتواند نرخ تبدیل را بهطور قابلتوجهی افزایش دهد.
این میانافزار درخواستهای GET را رهگیری کرده و هدر Accept را بررسی میکند. اگر کلاینت ترجیح خود را برای Markdown اعلام کند (و مقدار q در هدر بیشتر از صفر باشد)، تابع wantsMarkdown فعال شده و یک نسخه پیشساخته از محتوا را با هدرهای زیر برمیگرداند:
Content-Type: text/markdown; charset=utf-8: شناسایی صریح فرمت.Vary: Accept: برای جلوگیری از ارسال Markdown به مرورگرهای انسانی در حافظه کش.X-Robots-Tag: noindex: جلوگیری از ایندکس شدن نسخههای Markdown در موتورهای جستجو.Link: <URL>; rel="canonical": هدایت عاملها به صفحه اصلی HTML.
پیادهسازی منطق در مقابل یک سایت استاتیک میتواند باعث کاهش سرعت شود. برای جلوگیری از این اتفاق، تیم از فایل _routes.json استفاده کرد تا فقط مسیرهای ضروری (مثل /docs/) به تابع Worker برسند و سایر صفحات (۹۷ صفحه محلی و صفحه ۴۰۴) مستقیماً از حافظه استاتیک سرو شوند.
در جریان استقرار روی Cloudflare Pages، دو تله فنی شناسایی شد. اول، مشکل «اتصال هدرها»؛ وقتی قوانینی برای /*.md و مسیرهای خاص تعریف شد، کلودفلر هر دو را با هم ترکیب کرد و یک Content-Type نامعتبر ساخت. راهکار، تعریف صریح ۱۸ قانون مجزا برای هر فایل بود. دوم، کشینگ در wrangler pages dev؛ تغییرات هدرها فقط در زمان استارتآپ اعمال میشوند و نیاز به ریاستارت کامل سرور دارند.
بر اساس بررسی منابع متعدد، سه اقدام کمهزینه دیگر نیز نمره آمادگی سایت را به شدت بالا میبرد:
- سیگنالهای محتوا: استفاده از دستورات
contentsignals.orgدر فایلrobots.txtبرای تعیین حقوق استفاده از دادهها در آموزش مدلها. - هدرهای پاسخ لینک: افزودن رابطههای
describedbyبرای فایلllms.txtوalternateبرای نسخههای Markdown در هدرهای HTTP. - فهرست مهارتهای عامل: ایجاد یک فایل
index.jsonدر مسیر/.well-known/agent-skills/همراه با اثر انگشت SHA256 برای تضمین عدم دستکاری فایلها.
البته برخی شکستها در این تستها درست هستند. برای example، یک سایت مستنداتی نیازی به API یا سیستم پرداخت ندارد، بنابراین نمره پایین در بخش «تجارت» اهمیتی ندارد. همچنین، برخی تستهای اسکنر مثل DNS-AID بر اساس پیشنویسهایی هستند که حتی دامنه خودِ اسکنر (isitagentready.com) نیز در آنها شکست میخورد.
یکی از بزرگترین موانع، پیادهسازی سرور پروتکل زمینهٔ مدل (MCP) بود. نویسندگان این پروژه به دلیل تغییرات گسترده در نسخه ۲۸ ژوئیه ۲۰۲۶ و محدودیت شدید CPU در پلن رایگان کلودفلر (۱۰ میلیثانیه برای هر درخواست)، این مورد را به تعویق انداختند. این حساسیت به دقت در پاسخدهی، مشابه نیاز به بهینهسازی خط لولههای ارزیابی خودکار بود تا توهمات مدلهای زبانی در مقیاس بالا کاهش یابد. بنچمارکها نشان داد که یک «راهاندازی سرد» (Cold Start) — یعنی لحظهای که کد برای اولین بار پس از مدتی اجرا میشود و شبیه گرم کردن ماشین در زمستان است — به تنهایی ۱۲.۵ میلیثانیه زمان میبرد و بودجه رایگان را میسوزاند.
در نهایت، این مسیر فنی نمره سایت را از سطح ۱ به سطح ۴ رساند. درس اصلی این است که آمادگی برای عاملها، یک مسئله زیرساختی است، نه محتوایی. ۱۰۰ فایل Markdown بیفایدهاند اگر سرور نتواند از طریق هدرهای استاندارد HTTP وجود آنها را به عامل اعلام کند.
گام بعدی شما
- وبسایت خود را با ابزار
isitagentready.comبررسی کنید تا شکافهای زیرساختی را بیابید. - به جای تکیه بر فایلهای متنی، پیادهسازی «مذاکره محتوا» (Content Negotiation) را در سطح سرور یا CDN بررسی کنید.
- اگر از Cloudflare استفاده میکنید، محدودیتهای CPU در پلن رایگان را برای اجرای توابع Worker در نظر بگیرید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو