۸۴۴ هزار وب‌سایت llms.txt را پذیرفتند اما ربات‌های غول AI آن را نادیده می‌گیرند

اگر امروز هزینه‌ی زیادی برای بهینه‌سازی محتوای وب‌سایتتان می‌کنید تا در پاسخ‌های هوش مصنوعی ظاهر شوید، احتمالاً بخشی از تلاش شما روی ابزاری است که هیچ‌کس از آن استفاده نمی‌کند. تا ۲۵ اکتبر ۲۰۲۵، ۸۴۴ هزار وب‌سایت استاندارد llms.txt را پیاده‌سازی کرده‌اند، اما واقعیت تلخ این است که ربات‌های هدف، اصلاً به دنبال این فایل نیستند. در حالی که تبلیغات گسترده‌ی صنعت، این فایل را کلید دیده‌شدن در عصر AI معرفی می‌کنند، لاگ‌های سرور واقعیت متفاوتی را نشان می‌دهند: ارائه‌دهندگان اصلی مدل‌های زبانی بزرگ (LLM) راسته به دنبال این فایل نمی‌گردند. اینکه آیا GPTBot، ClaudeBot یا PerplexityBot واقعاً این فایل را فراخوانی می‌کنند یا خیر، سوالی است که تنها با تحلیل لاگ‌های دسترسی سرور خودتان می‌توانید به آن پاسخ دهید. این مقاله متدولوژی دقیق برای این تاییدیه را ارائه می‌دهد.

این استاندارد در ۳ سپتامبر ۲۰۲۴ توسط جرمی هوارد (Jeremy Howard) از Answer.AI و fast.ai پیشنهاد شد و مستندات آن در llmstxt.org قرار دارد. هدف این بود که یک خلاصه با فرمت مارک‌داون (Markdown) از سایت ارائه شود تا مدل‌های زبانی در لحظه‌ی استنتاج (Inference) — یعنی همان لحظه‌ای که مدل در حال تولید پاسخ برای کاربر است — سریع‌تر به محتوای کلیدی دسترسی پیدا کنند. مکانیزم پیشنهادی این است که ربات فایل را در مسیر example.com/llms.txt پیدا کند، عنوان و خلاصه را بخواند و از طریق لینک‌های منتخب، به مهم‌ترین صفحات داخلی با توضیحات کوتاه دسترسی یابد. وعده داده شده این است که سیستم‌های هوش مصنوعی هنگام پاسخ به سوالات درباره یک برند، از llms.txt به عنوان یک سیگنال زمینه‌ای (Context Signal) استفاده کنند تا سایت را سریع‌تر بفهمند، محتوای درست را اولویت‌بندی کنند و منابع را با دقت بیشتری ذکر کنند. این مکانیسم از نظر تئوری پذیرفتنی است، اما شواهد تجربی در حال حاضر غایب هستند.

همان‌طور که در پوشش پیشین ما درباره‌ی استراتژی‌های برندها برای دیده شدن در عصر AI اشاره کردیم، فایل llms.txt به عنوان یک اهرم اصلی برای این قابلیت بازاریابی شد. در عرض تنها ۱۲ ماه، این پیشنهاد از یک ایده تک‌نفره به یک توصیه استاندارد در تقریباً هر مقاله GEO (بهینه‌سازی برای موتورهای تولید محتوا) و AI-SEO تبدیل شد. شرکت‌های بزرگی مانند Ahrefs، Semrush، Yoast، نیل پاتل و ده‌ها آژانس دیجیتال، راهنماهای گام‌به‌گام برای راه‌اندازی آن منتشر کردند. اما برای مقایسه، فایل robots.txt در تخمین زده شده ۱۰۰ میلیون سایت فعال است؛ این بدان معناست که llms.txt با وجود رشد چشمگیر فصلی، هنوز دو مرتبه کوچک‌تر است. شکاف میان «پیاده‌سازی» و «استفاده واقعی» به یک نقطه شکست بحرانی برای بسیاری از استراتژی‌های AI-SEO تبدیل شده است. حتی شرکت آنتروپیک (Anthropic) یک فایل llms.txt در مسیر docs.anthropic.com دارد، اما این اقدام صرفاً در سمت کلاینت برای میزبانی مستندات است و تأییدی رسمی بر پشتیبانی سرورهای آن‌ها از کراول کردن و بهره‌برداری از این استاندارد نیست.

شکاف میان ادعا و واقعیت

گوگل اولین بازیگر بزرگی بود که صراحتاً اهمیت این فایل را پایین آورد. جان مولر (John Mueller) در آوریل ۲۰۲۵ در ردیت (که در Search Engine Journal نقل شد)، llms.txt را با تگ‌های قدیمی keywords در متا-تگ‌ها مقایسه کرد. تگ keywords تلاشی در دهه ۹۰ میلادی بود تا به وب‌مسترها رابطی برای اعلام محتوای سایت به موتورهای جست‌وجو بدهد، اما گوگل تا سال ۲۰۰۹ آن را به عنوان سیگنال رتبه‌بندی کنار گذاشت، زیرا دستکاری آن بسیار آسان بود و نیاز داشت تا با محتوای واقعی صفحه تطبیق داده شود. مولر تأکید کرد که لاگ‌های سرور نشان می‌دهند سرویس‌های AI حتی درخواست llms.txt را نمی‌فرستند و این فایل عملاً زائد است؛ زیرا هر سیستم هوش مصنوعی در هر صورت باید اطلاعات «خود-اعلامی شده» در فایل را با محتوای واقعی صفحات تطبیق دهد (Cross-check). این هزینه پردازشی برای تأیید، فایل را غیرضروری می‌کند.

داده‌های تجربی این تردید را تقویت می‌کنند:

• سِماراش (Semrush) یک آزمایش را روی Search Engine Land (یکی از دارایی‌های وابسته) از اواسط آگوست تا اواخر اکتبر ۲۰۲۵ رصد کرد. آن‌ها دریافتند که در کل این دوره ۱۰ هفته‌ای، هیچ بازدیدی از سوی GPTBot، ClaudeBot، PerplexityBot یا Google-Extended برای فایل llms.txt ثبت نشده است. در حالی که Googlebot و Bingbot این فایل را درخواست کردند، اما هیچ وضعیت خاص یا اولویتی برای آن قائل نشدند.
• رایان لاو (Ryan Law)، مدیر بازاریابی محتوای Ahrefs، خاطرنشان کرد که «هیچ شواهدی» وجود ندارد که این فایل باعث بهبود بازیابی اطلاعات توسط AI، افزایش ترافیک یا ارتقای دقت مدل‌ها شود. Ahrefs توصیه می‌کند به جای این فایل، بر نظارت بر برند در AI و تحلیل‌های ربات متکی شوید.
• بررسی فلاویو لونگاتو (Flavio Longato) روی ۱۰۰۰ دامنه Adobe Experience Manager (AEM) در بازه ۳۰ روزه از لاگ‌های CDN نشان داد که ۹۴.۹٪ از بازدیدهای llms.txt مربوط به Googlebot-Desktop بود.
• در مطالعه لونگاتو، تنها ۱.۱٪ درخواست‌ها از سوی OAI-SearchBot بود. GPTBot، ClaudeBot و PerplexityBot کاملاً از نتایج غایب بودند. ذکر می‌شود که این داده‌ها مربوط به یک ممیزی واحد است و میانگین چندین مطالعه نیست.
• داده‌های کیفی از ردیت الگوی مشابهی را نشان می‌دهد: یک میزبان دامنه با بیش از ۲۰ هزار سایت گزارش داد که تنها کراولرهای اکتشافی (مانند BuiltWith) فایل را دریافت کرده‌اند، در حالی که هیچ ربات استنتاجی (Inference Bot) چنین کاری نکرده است.

روش ممیزی لاگ‌های سرور

از آنجا که داشبوردهای ابزارهای شخص ثالث می‌توانند گمراه‌کننده باشند، تنها راه تایید اینکه آیا ربات‌های AI فایل شما را می‌خوانند، بررسی لاگ‌های دسترسی (Access Logs) خودتان است. اظهارات فروشندگان ابزار نمی‌تواند جایگزین این کار شود، زیرا رفتار ربات‌ها بسته به دامنه و بازه زمانی متفاوت است. این متدولوژی برای Apache، Nginx و لاگ‌های CDN در فرمت Combined-Log کاربرد دارد.

گام اول: تعریف ربات‌های هدف
برای دریافت یک خوانش دقیق، باید ربات‌های هدف را با دقت تعریف کنید. تفکیک بین کراولرهای آموزشی، ایندکس‌های جست‌وجو و ربات‌های دریافت زنده (Live-fetch) حیاتی است:

• OpenAI: شامل GPTBot (کراولر آموزشی)، OAI-SearchBot (ایندکس جست‌وجو برای ChatGPT Search) و ChatGPT-User (دریافت زنده برای نشست‌های کاربر). OpenAI این‌ها را با محدوده IPهای منتشر شده مستند کرده است.
• Anthropic: شامل ClaudeBot (آموزشی)، Claude-SearchBot (جست‌وجو برای Claude Search) و Claude-User (دریافت زنده). مستندات تا ۱۵ ژوئن ۲۰۲۶ نشان می‌دهد که این‌ها متمایز هستند. رشته‌های قدیمی مانند "anthropic-ai" و "Claude-Web" دیگر لیست نشده‌اند.
• Perplexity: شامل PerplexityBot (کراولر جست‌وجو که به robots.txt احترام می‌گذارد) و Perplexity-User (دریافت زنده در هنگام پرسش‌های کاربر).
• سایر سیگنال‌ها: Google-Extended (برای خارج کردن داده‌ها از آموزش Gemini)، Applebot-Extended (برای آموزش AI اپل)، CCBot (Common Crawl که دیتاست بالادستی بسیاری از LLMهاست) و Bytespider (برای آموزش ByteDance).

توجه داشته باشید که Bingbot مایکروسافت گاهی به عنوان ربات AI شمرده می‌شود زیرا نتایج بینگ به Copilot تغذیه می‌شود. با این حال، کراولرهای اکتشافی مانند BuiltWith یا اسکنرهای various agencies اغلب ظاهر می‌شوند و به اشتباه به عنوان «کراولرهای AI» تفسیر می‌شوند.

گام دوم: اجرای تحلیل لاگ
برای کسانی که از Apache یا Nginx استفاده می‌کنند، دستورات زیر برای استخراج داده‌ها از /var/log/nginx/access.log کاربرد دارد:

• بررسی دسترسی کلی: grep "llms.txt" /var/log/nginx/access.log | awk -F" '{print $6}' | sort | uniq -c | sort -rn
• بررسی ربات‌های AI خاص: grep "llms.txt" /var/log/nginx/access.log | grep -E "GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-SearchBot|Claude-User|PerplexityBot|Perplexity-User|Google-Extended|Applebot-Extended|CCBot|Bytespider" | awk '{print $1, $4, $9, $(NF-1)}'
• شمارش ربات‌ها: استفاده از grep -oE برای جداسازی نام ربات و ارسال آن به uniq -c برای شمارش نهایی.

اگر لاگ‌های شما چرخانده شده‌اند (access.log.1.gz و غیره)، grep را با zgrep جایگزین کنید یا از یک حلقه (loop) استفاده نمایید. برای CDNهایی مانند Cloudflare، Fastly یا CloudFront، مسیر لاگ متفاوت است اما اصل کار یکسان است: ابتدا فیلتر مسیر روی llms.txt و سپس فیلتر User-Agent.

گام سوم: پروب مقایسه‌ای (Comparison Probe)
بخش حیاتی این متدولوژی «پروب مقایسه‌ای» است. نتیجه‌ی صفر برای llms.txt تنها زمانی قابل تفسیر است که ربات‌های AI به بخش‌های دیگر دامنه شما بازدید کرده باشند. شما باید یک URL مشابه، مانند robots.txt یا sitemap.xml یا یک صفحه محتوایی با ترافیک بالا را بررسی کنید.

مثال برای دستورات پروب:

• grep "robots.txt" /var/log/nginx/access.log | grep -oE "GPTBot|OAI-SearchBot|..." | sort | uniq -c | sort -rn
• grep -oE "GPTBot|OAI-SearchBot|..." /var/log/nginx/access.log | sort | uniq -c | sort -rn

اگر GPTBot صد بار از robots.txt شما بازدید کرده اما هرگز به llms.txt سر نزده است، شما مدرکی قطعی بر بی‌میلی او دارید. اما اگر GPTBot اصلاً از سایت بازدید نکرده، نتیجه‌ی صفر برای llms.txt بی‌معنی است. یافته‌ها باید متناسب (Proportional) باشند تا از نظر متدولوژیک معتبر باشند.

گام چهارم: زمان‌بندی و تأیید
تحلیلگران پنجره مشاهده‌ی حداقل ۶۰ تا ۹۰ روزه را توصیه می‌کنند. ربات‌های LLM بسیار کمتر از Googlebot کراول می‌کنند، بنابراین بازه ۱۴ روزه ناکافی است. آزمایش Semrush از ۱۰ هفته به عنوان خط أساس (Baseline) استفاده کرد. ایده‌آل این است که این بازه را با یک رویداد انتشار خاص (مانند یک صفحه محتوایی جدید با لینک‌های برجسته) به عنوان محرک ترکیب کنید.

برای ممیزی‌های با دقت بالا، محدوده‌های IP را از طریق Reverse-DNS تأیید کنید، زیرا رشته‌های User-Agent به‌راحتی جعل می‌شوند. OpenAI آی‌پی‌های GPTBot را در openai.com/gptbot.json و آنتروپیک لیستی را در claude.com/crawling/bots.json منتشر کرده‌اند. اگرچه این کار برای بسیاری از کسب‌وکارهای کوچک بیش‌از‌حد مهندسی‌شده (Over-engineering) به نظر برسد، اما برای نتایجی که در ممیزی‌های رسمی یا ارائه‌های تجاری استفاده می‌شوند، ضروری است.

سلسله‌مراتب واقعی سیگنال‌های AI

اگر llms.txt در حال حاضر بی‌اثر است، چه چیزی واقعاً برای دیده‌شدن در AI کار می‌کند؟ شواهد نشان می‌دهد که سیستم‌های AI به سیگنال‌های تعبیه شده مستقیماً در HTML رندر شده تکیه می‌کنند تا فایل‌های جداگانه.

• نشانه‌گذاری Schema.org: ربات‌های GPTBot و ClaudeBot به‌طور فعال طرح‌های Article، Organization، FAQ و Breadcrumb را تجزیه (Parse) می‌کنند. این‌ها مؤثر هستند چون در HTML رندر شده قرار دارند و نیاز به درخواست جداگانه ندارند.
• فایل Robots.txt: این فایل همچنان رابط اصلی برای اعطای اجازه یا مسدود کردن دسترسی کراولرهای آموزشی AI است. این یک رابط احرازی (Authorization Interface) است، هرچند محتوا را توصیف نمی‌کند.
• تراکم بالای حقایق (High Fact Density): سیستم‌های AI منابعی را ترجیح می‌دهند که غلظت بالایی از اعداد concrete، تاریخ‌ها، نقل‌قول‌های مستند و نویسندگانی با ارجاعات شفاف داشته باشند. محتوایی که در برابر حقیقت-سنجی (Fact-checking) مقاومت کند، اولویت می‌یابد.
• HTML معنایی (Semantic HTML): استفاده درست از سلسله‌مراتب H1-H3 (به جای استفاده تزئینی) و پاراگراف‌های تمیز. استفاده از لیست‌ها برای شمارش‌ها، ساختاری را فراهم می‌کند که AI نیاز دارد؛ HTML معنایی همان ساختاری را می‌دهد که Markdown می‌دهد.
• سیگنال‌های E-E-A-T: بیوگرافی‌های لینک‌شده‌ی نویسنده، پروفایل‌های LinkedIn و وابستگی‌های سازمانی، فاکتورهای اندازه‌گیری شده‌ای در نحوه ارزیابی اعتبار منبع توسط AI هستند.

اجماع بازار

صنعت در حال حاضر به سه جبهه تقسیم شده است:

۱. حامیان پیاده‌سازی: (مانند Yoast، Publii، نیل پاتل و آژانس‌های مختلف). آن‌ها استدلال می‌کنند که این یک حرکت کم‌ریسک، ارزان و برای آینده‌نگری است. استدلال‌های آن‌ها عمدتاً هنجاری است («باید این‌طور باشد»).
۲. شکاک-خنثی: (مانند Ahrefs، Semrush، Wix Studio). آن‌ها به فقدان شواهد تجربی و نتایج منفی آزمایش‌ها اشاره می‌کنند.
۳. ردکنندگان: (مانند گوگل/جان مولر و ممیزان لاگ). آن‌ها به مشابهت با تگ keywords-meta و غیبت کامل سیگنال‌های استفاده در لاگ‌ها استناد می‌کنند. استدلال‌های آن‌ها تجربی (Empirical) است.

برای اکثر کسب‌وکارها، مسیر عمل‌گرایانه این است که فایل را پیاده کنند زیرا هزینه آن حداقلی است (یک فایل مارک‌داون در ریشه) و ضرری ندارد. با این حال، باید با آن به عنوان «زیرساخت هشدار زودهنگام» برخورد کنید تا اگر OpenAI یا Anthropic در سال ۲۰۲۶ یا ۲۰۲۷ رسماً این استاندارد را پذیرفتند، آماده باشید.

انتظار افزایش ناگهانی در ارجاعات Perplexity را صرفاً با آپلود یک فایل مارک‌داون نداشته باشید. مطالعه Search Engine Land نشان داد هر جا ترافیک افزایش یافته، به دلیل تغییرات موازی — مانند پوشش‌های روابط عمومی (PR)، FAQهای جدید یا بازسازی صفحات محصول — بوده است، نه فایل llms.txt.

اولویت خود را بر پاکسازی HTML معنایی و متادیتای Schema.org قرار دهید. این‌ها سیگنال‌های اثبات شده‌ای هستند که کراولرهای AI امروز پردازش می‌کنند. پس از بهینه‌سازی آن‌ها، llms.txt می‌تواند به عنوان یک جایگاه (Placeholder) باقی بماند. یک کرون-جاب (Cron-job) هفتگی برای نظارت بر لاگ‌های خود تنظیم کنید؛ اگر نتایج را شش ماه دیگر بررسی کنید، به جای «نظر»، «مدرک» خواهید داشت.

گام بعدی شما

• لاگ‌های سرور خود را برای بازه‌ی ۹۰ روزه با دستورات ارائه شده بررسی کنید تا واقع‌نمایان (Bot) فعال در سایتتان را بشناسید.
• به‌جای تکیه بر llms.txt، روی پیاده‌سازی دقیق Schema Markup برای مقالات و سازمان خود تمرکز کنید.
• یک Cron-job هفتگی برای نظارت بر درخواست‌های فایل llms.txt تنظیم کنید تا تغییر رفتار ربات‌ها در سال ۲۰۲۶ را رصد کنید.

اما اثر این تغییرات بر نحوه استدلال مدل‌ها در زمان پاسخ‌دهی پیچیده‌تر است — به تحلیل ما درباره‌ی زنجیره تفکر (CoT) در مدل‌های جدید مراجعه کنید.