فایل robots.txt چیست؟ راهنمای ساخت، تست و عیب‌یابی

یک اسلش اشتباه در robots.txt می‌تواند Crawl یک بخش مهم را متوقف کند؛ یک تصور اشتباه هم می‌تواند URL محرمانه را عمومی نگه دارد یا مانع دیده‌شدن noindex شود. این فایل کوچک «کلید رتبه» نیست و فایروال هم نیست؛ قراردادی عمومی برای Crawlers قانونمند است که می‌گوید کدام URLها را درخواست کنند یا نکنند.

این راهنما فایل robots.txt را بر اساس RFC ۹۳۰۹ و رفتار جاری Google توضیح می‌دهد: Scope هر Origin، قواعد User-agent/Allow/Disallow، تفاوت Crawl و Index، HTTP status و Cache، WordPress و فروشگاه، تست URL matrix، Rollout، Monitoring و Runbook خطا. نمونه‌ها باید با URLهای واقعی و مستندات هر Crawler آزموده شوند؛ کپی‌کردن فایل سایت دیگر تصمیم امنی نیست.

پاسخ کوتاه: فایل robots.txt چیست؟

robots.txt یک فایل متنی UTF-۸ در ریشه هر Origin است که Robots Exclusion Protocol یا REP را بیان می‌کند. Crawler پیش از درخواست URLهای آن Scope، فایل را می‌گیرد و گروه متناسب با Product token خودش را پیدا می‌کند. قواعد Allow و Disallow روی مسیر URL تعیین می‌کنند Request مجاز است یا نه.

مثلاً قواعد https://example.com/robots.txt برای همان Scheme، Host و Port معتبرند؛ به http://example.com، https://shop.example.com یا Port دیگر سرایت نمی‌کنند. فایل در /folder/robots.txt نیز robots.txt معتبر آن Origin نیست.

robots.txt چه کاری نمی‌کند؟

این فایل رمز عبور، ACL، WAF، Rate limiter عمومی یا تضمین حذف از نتایج نیست. Bot مخرب می‌تواند آن را نادیده بگیرد و حتی مسیرهای حساس را از فایل عمومی کشف کند. User-agent header نیز قابل جعل است. برای داده شخصی، Admin، Backup، فایل پیکربندی و محیط Staging از احراز هویت، مجوز، Network restriction و حذف دسترسی عمومی استفاده کنید.

Disallow به معنی «این محتوا را Index نکن» نیست. Google ممکن است URL مسدودشده‌ای را از لینک‌های دیگر کشف و بدون محتوای Crawl‌شده در نتیجه نشان دهد. همچنین اگر صفحه هم Disallow و هم noindex باشد، Googlebot نمی‌تواند صفحه را بخواند تا noindex را ببیند.

آیا هر سایت به robots.txt نیاز دارد؟

خیر. نبود فایل که پاسخ 404 سالم می‌دهد، برای Google به‌معنای نبود محدودیت Crawl است. سایت کوچک با URLهای تمیز و بدون مشکل ظرفیت شاید به Rule نیاز نداشته باشد. وجود فایل خالی نیز امتیاز SEO یا نشانه «حرفه‌ای‌بودن» ایجاد نمی‌کند.

فایل زمانی ارزش دارد که Scope روشن باشد: Facetهای انفجاری، Search داخلی، Calendar بی‌نهایت، Endpointهای Crawl‌ناپذیر، فایل‌های کم‌ارزش یا Botهای مشخص. قبل از افزودن Rule، ثابت کنید مشکل در Crawl است و کنترل مناسب‌تری در معماری URL، لینک داخلی، Canonical، Status یا Authentication وجود ندارد.

Scope دقیق: Scheme، Host و Port

برای هر Origin فعال Inventory بسازید: Apex، www، فروشگاه، تصاویر، API، HTTP قدیمی، HTTPS و Portهای عمومی. هرکدام فایل یا رفتار مستقل دارند. Redirect کردن robots.txt میان Hostها ممکن است کار کند، اما Dependency و Failure mode اضافه می‌کند؛ فایل نهایی باید در زنجیره کوتاه، قابل‌دسترسی و متناسب با همان Origin باشد.

Fragment پس از # به سرور ارسال نمی‌شود و موضوع Rule نیست. مسیر و Query می‌توانند در Matching اثر داشته باشند؛ Case نیز مهم است. /Private/ و /private/ یکسان فرض نشوند. Encoding، Slash پایانی، حروف فارسی و پارامترهای مرتب‌شده را با URL واقعی تست کنید.

ساختار فایل و Directiveهای استاندارد

هر خط معتبر شامل Field، دونقطه و Value است. نام Field به حروف بزرگ/کوچک حساس نیست، اما Path حساس است. Comment با # شروع می‌شود و باقی همان خط نادیده گرفته می‌شود. فایل باید Plain text و UTF-۸ باشد؛ از Word processor، Quote خمیده و Markup HTML استفاده نکنید.

User-agent و گروه‌ها

User-agent Product token Crawler را تعیین می‌کند. چند User-agent متوالی می‌توانند یک Group را تعریف کنند؛ Ruleها تا شروع Group بعدی ادامه دارند. برای Google، Groupهای مختص همان Product token با هم ترکیب می‌شوند، اما Ruleهای * را خودکار به Group اختصاصی Googlebot به ارث ندهید؛ Common rule لازم را صریح و با تست نگه دارید.

Allow و Disallow

Disallow مسیر غیرمجاز و Allow استثنای مجاز را بیان می‌کند. در تطبیق، Rule مشخص‌تر—Match طولانی‌تر—برنده می‌شود؛ در طول برابر، Allow بر Disallow ترجیح دارد. Disallow: بدون Path محدودیتی ایجاد نمی‌کند. ترتیب ظاهری Rule را جایگزین آزمون Parser ندانید.

Sitemap و Directiveهای پشتیبانی‌نشده

Sitemap باید URL کامل Sitemap را بدهد و خارج از Group هم قابل درج است. Google فقط user-agent، allow، disallow و sitemap را در این فایل پشتیبانی می‌کند؛ crawl-delay را پشتیبانی نمی‌کند و noindex داخل robots.txt نیز برای Google معتبر نیست.

یک فایل حداقلی و معتبر

اگر هدف فقط اعلام Sitemap و اجازه Crawl است، فایل می‌تواند بسیار کوتاه باشد. Disallow: خالی لازم نیست؛ نبود Rule نیز Allow پیش‌فرض است. سادگی، سطح خطا و هزینه نگهداری را کم می‌کند.

User-agent: *
Sitemap: https://www.example.com/sitemap.xml

برای بستن مسیر Search داخلی و بازگذاشتن همه مسیرهای دیگر:

User-agent: *
Disallow: /search/

Sitemap: https://www.example.com/sitemap.xml

این نمونه فقط وقتی درست است که URLهای Search واقعاً زیر /search/ باشند، صفحه ارزش Index نداشته باشد، URLهای قدیمی ناخواسته در Index مدیریت شده باشند و هیچ Asset لازم داخل این مسیر قرار نگیرد.

Wildcard و پایان مسیر را با URL matrix تست کنید

Google از * برای دنباله کاراکترها و $ برای انتهای URL پشتیبانی می‌کند. این Extensionها در Crawlerهای دیگر ممکن است تفاوت داشته باشند. Rule کوتاه می‌تواند Queryهای غیرمنتظره را هم Match کند؛ بنابراین برای هر Pattern حداقل نمونه Allow و Disallow و Edge case بنویسید.

User-agent: Googlebot
Disallow: /*?sort=
Disallow: /*.pdf$
Allow: /public/reports/*.pdf$

Crawl، Render، Index و Serving را جدا کنید

Google ابتدا URL را Discover، سپس در صورت اجازه Request می‌کند، ممکن است Render و برای Index ارزیابی کند و بعد نتیجه را Serve کند. robots.txt در مرز Request عمل می‌کند. noindex در پاسخ HTML/Header دیده می‌شود. Canonical سیگنال انتخاب نسخه است، Redirect جابه‌جایی و Status وجود Resource را بیان می‌کند.

برای تشخیص کامل مرحله شکست، راهنمای حل مشکل ایندکس نشدن صفحات را ببینید. قرار دادن همه مسائل زیر عنوان «Blocked» باعث Fix اشتباه می‌شود.

noindex، Canonical و robots.txt را چگونه ترکیب کنیم؟

اگر می‌خواهید صفحه عمومی از Index خارج شود، اجازه Crawl بدهید و noindex را در Meta یا X-Robots-Tag برگردانید. بعد از پردازش و خروج، ممکن است برای کاهش Crawl بعضی Patternها تصمیم جدا بگیرید؛ اما این Transition باید با Evidence و Monitoring انجام شود.

Canonical جانشین Disallow یا noindex نیست. Google باید نسخه‌ها را Crawl کند تا Canonical را ببیند. برای Duplicate قابل‌دسترسی، Canonical و لینک‌های داخلی سازگار معمولاً از مسدودکردن نسخه سیگنال روشن‌تری می‌دهند. برای URL حذف‌شده از Status مناسب استفاده کنید و برای مهاجرت به مقصد معادل، نقشه ریدایرکت ۳۰۱ و مهاجرت URL را اجرا کنید.

امنیت و حریم خصوصی: مسیر حساس را منتشر نکنید

robots.txt برای هر بازدیدکننده قابل خواندن است. نوشتن Disallow: /backups-client-1405/ هم محافظت نمی‌کند و هم نام مسیر را افشا می‌کند. Bot مخرب ممکن است Ruleها را نادیده بگیرد. فایل Private را از Web root خارج، دسترسی را احراز و مجوز را سمت سرور اعمال و Exposure را در Log کنترل کنید.

برای تشخیص Googlebot واقعی به User-agent اعتماد نکنید؛ IP ranges یا Reverse/Forward DNS مطابق راهنمای رسمی را Verify کنید. حتی Bot معتبر نباید از کنترل Authorization عبور کند. Robots policy یک لایه همکاری است، نه Boundary امنیتی.

رفتار HTTP robots.txt؛ یک قرارداد Availability

پاسخ خود فایل بر Crawl کل Origin اثر می‌گذارد. برای Google، 2xx باعث Parse فایل می‌شود؛ Redirectهای 3xx دست‌کم تا پنج Hop دنبال می‌شوند و پس از آن مثل نبود فایل رفتار می‌شود؛ بیشتر 4xxها جز 429 به‌معنای نبود محدودیت‌اند؛ 429 و 5xx مشکل Availability محسوب می‌شوند.

طبق توضیح جاری Google، پس از Fetch ناموفق ابتدا تا ۱۲ ساعت Crawl متوقف می‌شود؛ از ۱۲ ساعت تا ۳۰ روز آخرین نسخه موفق استفاده می‌شود. بعد از ۳۰ روز، رفتار به دسترس‌پذیری Homepage وابسته است. این منطق را به‌عنوان مجوز تولید خطای عمدی استفاده نکنید؛ برای Semantics کامل پاسخ‌ها، راهنمای کدهای وضعیت HTTP را ببینید.

Cache، CDN و حجم فایل

Google معمولاً robots.txt را تا ۲۴ ساعت Cache می‌کند و ممکن است تحت خطا بیشتر نگه دارد؛ Cache-Control max-age می‌تواند عمر را تغییر دهد. بنابراین تغییر Deploy‌شده فوراً در همه Crawl workerها دیده نمی‌شود. فایل نوسانی که در ساعت‌های مختلف Rule متفاوت می‌دهد، نتیجه پیش‌بینی‌پذیری ندارد.

Google فقط ۵۰۰ KiB اول را پردازش می‌کند. فایل بزرگ نشانه این است که معماری URL یا Ruleها باید Consolidate شوند. Edge/CDN، Origin، Plugin و فایل فیزیکی می‌توانند نسخه‌های متفاوت بسازند؛ از چند نقطه و با Host/Scheme دقیق Fetch کنید. برای اصول لایه‌ها و Purge، راهنمای معماری Cache سایت را بخوانید.

Crawl budget را فقط برای سایت واجدشرایط بهینه کنید

Google راهنمای Crawl budget را عمدتاً برای سایت‌های بسیار بزرگ یا پرتغییر می‌داند: حدود یک میلیون صفحه با تغییر متوسط، ده‌هزار صفحه با تغییر روزانه یا سهم بالای «Discovered – currently not indexed». سایت کوچک نباید با ده‌ها Disallow و نگرانی نظری، Discovery و Rendering را خراب کند.

ابتدا URL inventory، Link graph، Sitemap freshness، Duplicate generation، Response time، Status، Redirect chain و Log را اصلاح کنید. robots.txt می‌تواند Request به Space کم‌ارزش را کم کند، اما «بودجه آزادشده» تضمین نمی‌کند بلافاصله به صفحه دلخواه منتقل یا رتبه بهتر شود. برای Audit سراسری از چک‌لیست ممیزی کامل سئو استفاده کنید.

Facet، Filter و Search داخلی در فروشگاه

مسدودکردن همه Query stringها نسخه عمومی خطرناکی است: Pagination، Language، Product variant یا Tracking cleanup ممکن است در همان Space باشند. ابتدا Facet matrix بسازید: Demand، Utility، Inventory stability، Index decision، Canonical، Link policy و Crawl cost. بعد Pattern دقیق برای URLهای واقعاً بی‌ارزش بنویسید.

تصمیم Catalog، Variant، Facet و Pagination در راهنمای سئو فروشگاه اینترنتی با جزئیات آمده است.

CSS، JavaScript، تصویر و API موردنیاز Render

اگر Googlebot نتواند CSS یا JavaScript لازم را بگیرد، Render و فهم صفحه ممکن است ناقص شود. مسیر /assets/ را فقط به‌دلیل «در نتایج صفحه نیست» نبندید. مشخص کنید Resource برای Main content، Layout، Structured data، Navigation یا Hydration لازم است و Rendered output را بررسی کنید.

در PWA و SPA، Shell، Chunkهای Hashed، API عمومی Render و Fallback باید با Policy هماهنگ باشند. راهنمای سئو فنی PWA و JavaScript Rendering مرز Crawl/Render/Cache را عمیق‌تر پوشش می‌دهد.

WordPress: فایل مجازی، فایل فیزیکی و Plugin owner

WordPress می‌تواند وقتی فایل فیزیکی وجود ندارد، robots.txt مجازی تولید کند و Hook رسمی robots_txt خروجی را Filter می‌کند. Web server، SEO plugin، Security plugin، CDN و کد Theme ممکن است هم‌زمان ادعای مالکیت داشته باشند. Source of truth را تعیین کنید؛ وگرنه Preview ادمین با پاسخ عمومی فرق می‌کند.

الگوی رایج زیر نقطه شروع است، نه نسخه همه سایت‌ها:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://www.example.com/wp-sitemap.xml

قبل از استفاده بررسی کنید Sitemap واقعی کدام است، آیا Plugin آن را Redirect می‌کند، آیا Asset یا Endpoint لازم زیر مسیر بسته است و آیا Multisite/Subdirectory Scope متفاوت دارد. «Discourage search engines» در WordPress برای Staging جای Authentication نیست؛ پس از Launch نیز Rule کل سایت و Meta robots را کنترل کنید.

Sitemap در robots.txt؛ Discovery نه تضمین Index

می‌توانید چند خط Sitemap با URL کامل بنویسید، اما Sitemap index معمولاً نگهداری را ساده‌تر می‌کند. فقط URLهای Canonical و Index-eligible را وارد کنید، lastmod را با تغییر معنادار به‌روز و Status/Fetch آن را Monitor کنید. حضور در Sitemap Crawl یا Index را تضمین نمی‌کند.

Sitemap: https://www.example.com/sitemap-posts.xml
Sitemap: https://www.example.com/sitemap-products.xml

Search Console Sitemaps report و خط robots هر دو Discovery را کمک می‌کنند؛ یکی جای دیگری را از نظر Monitoring نمی‌گیرد. اگر Sitemap روی Host دیگری است، Ownership و مجازبودن Cross-site submission را مطابق مستندات موتور بررسی کنید.

Crawlerهای متفاوت و Botهای AI

RFC یک روش اعلام Preference است، اما همه Botها یک Directive extension یا Policy یکسان ندارند و Bot بدخواه ممکن است هیچ Ruleای را رعایت نکند. برای هر Crawler مهم، Product token، هدف، IP verification، Directive support و اثر Block را از مستندات همان اپراتور ثبت کنید. User-agentهای حدسی یا فهرست‌های کپی‌شده به‌سرعت منقضی می‌شوند.

مسدودکردن Crawl برای یک Bot لزوماً درباره Index، Training، Citation، Cache، دسترسی کاربرمحور یا حقوق استفاده همان سرویس تصمیم کامل نمی‌دهد. Terms، Controls و پیامد Product را جدا بررسی کنید و برای Enforcement از کنترل فنی/قراردادی مناسب بهره ببرید. راه دورزدن محدودیت یک سرویس یا جعل Bot پیشنهاد نمی‌شود.

Staging، Redesign و Migration

Staging باید با Authentication یا Network allowlist حفاظت شود؛ Disallow: / فقط مکمل است. در فرایند Deploy، Robots rule محیط Test نباید به Production نشت کند. یک Release gate خودکار بسازید که Status فایل، Rule کل سایت، Meta noindex، Canonical، Sitemap و صفحه‌های حیاتی را پیش و پس از انتشار بررسی کند.

در Migration دامنه، هر دو Origin قدیم و جدید robots مستقل دارند. Google باید بتواند Redirectهای قدیم و مقصد جدید را Request کند. بستن دامنه قدیم با Disallow می‌تواند مشاهده Redirect را مختل کند. TLS، DNS، CDN و نگهداری robots هر Origin را در URL map وارد کنید.

تغییر Crawl rate؛ Crawl-delay نسخه Google نیست

Google crawl-delay را نادیده می‌گیرد و Crawl Rate Limiter قدیمی Search Console از ۸ ژانویه ۲۰۲۴ کنار گذاشته شده است. اگر بار غیرعادی می‌بینید، ابتدا با Log و IP/DNS بررسی کنید Request واقعاً Googlebot است. سپس Capacity، Response time، URL explosion و Cache را اصلاح کنید.

Googlebot به کندی پاسخ و خطاهای Server واکنش نشان می‌دهد، اما برگرداندن عمدی 500 برای صفحات سالم راهبرد عادی نیست و می‌تواند Availability و Crawl را آسیب بزند. در Incident واقعی از Status متناسب، Retry/Capacity plan و فرم گزارش فعالیت غیرعادی Googlebot استفاده کنید. Botهای دیگر ممکن است Control جدا داشته باشند.

فرایند امن ساخت یا اصلاح robots.txt

URL test matrix؛ واحد پذیرش واقعی

به‌جای اینکه Parser فقط بگوید Syntax معتبر است، مجموعه URLهای واقعی را برای هر Bot و هر Origin تست کنید. حداقل Critical page، Disallowed pattern، Exception، Case variant، Query order، Encoded URL، CSS/JS، Sitemap و URL تازه Migration‌شده را پوشش دهید.

origin,crawler,url,expected,reason,owner
https://www.example.com,Googlebot,/products/,allow,category canonical,SEO
https://www.example.com,Googlebot,/search/?q=test,disallow,internal search,SEO
https://www.example.com,Googlebot,/assets/app.js,allow,render dependency,Frontend
https://img.example.com,Googlebot-Image,/products/a.webp,allow,product image,Commerce

Google در Search Console Robots report خطا/هشدار و زمان آخرین Fetch را نشان می‌دهد؛ برای URL مشخص از URL Inspection استفاده کنید. Library متن‌باز Parser Google نیز برای تست محلی در دسترس است. Legacy «Robots Tester» را به‌عنوان تنها مسیر جاری معرفی نکنید.

تست Delivery با HTTP، نه فقط محتوای Editor

فایل درست روی لپ‌تاپ کافی نیست. پاسخ Public را بدون Follow redirect و سپس با Follow کنترل‌شده بررسی کنید: Status، Location، Content-Type، Cache-Control، Byte size، Encoding و Body. از Networkهای مختلف و Host header درست تست کنید.

curl -i --max-redirs 0 https://www.example.com/robots.txt
curl -fsS https://www.example.com/robots.txt
curl -fsS https://www.example.com/robots.txt | wc -c

در CI، Parser و URL matrix را روی Draft اجرا و پس از Deploy Public fetch را مقایسه کنید. Secret، Cookie یا PII را در Log خروجی CI ذخیره نکنید. Robots endpoint باید بدون Session و Personalization پاسخ ثابت بدهد.

Monitoring و SLO پیشنهادی

برای سایت بزرگ یا حیاتی، robots.txt یک Dependency سطح Origin است. SLO می‌تواند درصد پاسخ موفق ۲۰۰/۴۰۴ مطابق Intent، Latency، Hash مورد انتظار، اندازه فایل و Age آخرین Fetch موفق را پوشش دهد. Alert روی تغییر Disallow: /، 5xx/۴۲۹، HTML body، Redirect chain و حذف Sitemap ارزشمند است.

Runbook مسدودشدن ناخواسته

1. دامنه حادثه را مشخص کنید: کدام Origin، Bot، Pattern، زمان و Release؟
2. Public response مستقیم، Cache/CDN و robots گزارش‌شده در Search Console را Capture کنید.
3. اگر Rule علت است، کوچک‌ترین اصلاح امن را Deploy و Cache مربوط را Purge کنید.
4. URL matrix کامل، Critical CSS/JS و Sitemap را دوباره اجرا کنید.
5. در Robots report برای وضعیت اضطراری Recrawl درخواست و URLهای حیاتی را Inspect کنید.
6. Log Crawl، Index state و Business outcome را تا بازگشت Baseline پایش کنید.
7. Root cause، زمان کشف/رفع، Guardrail ازدست‌رفته و اقدام پیشگیرانه را ثبت کنید.

بازگشت Crawl به معنی بازگشت فوری Index یا رتبه نیست. سه Clock تحویل Fix، مشاهده Crawler و پردازش Search را جدا گزارش کنید.

مثال فرضی: فروشگاه ایرانی با Facet انفجاری

فرض کنید فروشگاهی ۸۰هزار محصول دارد اما ترکیب رنگ، سایز، برند، مرتب‌سازی و UTM بیش از ۲میلیون URL می‌سازد. Crawl Stats و Log نشان می‌دهد بخش بزرگی از Requestها به ترکیب‌های بدون تقاضا می‌روند و Categoryهای اصلی دیرتر Recrawl می‌شوند. این داده فرضی است و Benchmark بازار نیست.

تصمیم مرحله‌ای

تیم ابتدا Link generation و Parameter normalization را اصلاح، Facetهای دارای تقاضا را Curated، Sitemap را پاک و Duplicateها را Canonical می‌کند. URLهای لازم برای خروج از Index مدتی Crawlable و noindex می‌مانند. پس از مشاهده خروج و تثبیت Link graph، Patternهای کم‌ارزش در robots محدود می‌شوند.

Rule و Guardrail

User-agent: Googlebot
Disallow: /*?sort=
Disallow: /*&sort=
Disallow: /*?view=
Disallow: /*&view=

Sitemap: https://shop.example.ir/sitemap_index.xml

Matrix باید Parameter order، Pagination، Category curated، Product، CSS/JS و Campaign URL را پوشش دهد. Guardrail شامل Crawl Category/Product، Index eligibility، Organic landing outcome و Server load است. اگر URL مهم Block شود، Rollback فوری اجرا می‌شود.

برنامه ۳۰روزه اجرا

اشتباهات رایج robots.txt

• استفاده از Disallow برای امنیت، محرمانگی یا حذف قطعی از Index.
• ترکیب Disallow و noindex پیش از آنکه Crawler بتواند noindex را ببیند.
• کپی فایل WordPress یا فروشگاه دیگر بدون Inventory مسیر و Plugin.
• فراموش‌کردن Scope مستقل HTTP/HTTPS/Subdomain/Port.
• بستن CSS، JavaScript، Image یا API لازم برای Render.
• Pattern عمومی برای همه Queryها و آسیب به Pagination/Variant/Language.
• اتکا به ترتیب Rule به‌جای Specificity و URL matrix.
• پاسخ ۴۰۳ به فایل با تصور اینکه Crawler را می‌بندد؛ Google بیشتر 4xxها را نبود Rule می‌بیند.
• توصیه Crawl-delay یا Crawl Rate Limiter منسوخ برای Google.
• انتشار فایل بدون Status/Cache/CDN/Redirect/Encoding QA.
• نوسان Ruleها بر اساس ساعت یا User personalization.
• گزارش «بودجه خزش بهتر شد» بدون Log، Crawl stage و Outcome.

چک‌لیست پیش از انتشار

• Origin registry شامل Scheme، Host، Port، Sitemap، Owner و Source of truth است.
• برای هر Pattern، هدف Crawl از Index و Security جدا شده است.
• فایل UTF-۸ Plain text، کوچک، خوانا و بدون Directive پشتیبانی‌نشده است.
• Groupهای اختصاصی Common rule لازم را صریح دارند.
• Path، Case، Encoding، Query order، Wildcard و $ تست شده‌اند.
• Critical page، CSS/JS، Image، API و Sitemap Allow هستند.
• Public endpoint با Status، Header، Body، Redirect و Cache درست پاسخ می‌دهد.
• URL matrix برای Botهای هدف در CI و بعد Deploy پاس شده است.
• Change ticket، Approver، زمان انتشار و Rollback مشخص‌اند.
• Robots report، URL Inspection، Crawl Stats، Log و Index baseline پایش می‌شوند.
• Staging و داده حساس با Authentication محافظت شده‌اند، نه فقط Disallow.

پرسش‌های متداول robots.txt

آیا robots.txt از ایندکس‌شدن صفحه جلوگیری می‌کند؟

نه به‌صورت قطعی. URL مسدودشده ممکن است از لینک‌ها کشف و بدون محتوای Crawl‌شده نمایش داده شود. برای خروج صفحه عمومی از Google از noindex قابل‌خزش استفاده کنید؛ برای داده خصوصی Authentication و Authorization لازم است.

اگر robots.txt نداشته باشیم چه می‌شود؟

اگر URL فایل 404 سالم بدهد، Google آن را نبود محدودیت Crawl می‌داند. این وضعیت لزوماً خطا نیست. سایت کوچک شاید فقط به Sitemap و معماری URL سالم نیاز داشته باشد؛ فایل خالی مزیت رتبه ایجاد نمی‌کند.

چگونه بفهمیم یک URL برای Googlebot Block است؟

فایل Public و Robots report را بررسی و URL مشخص را با URL Inspection تست کنید. برای تغییر پیش از Deploy از Library متن‌باز Parser Google و URL matrix محلی استفاده کنید. به Preview افزونه یا Legacy tester به‌تنهایی اتکا نکنید.

آیا Crawl-delay برای Google کار می‌کند؟

خیر؛ Google آن را پشتیبانی نمی‌کند و Crawl Rate Limiter قدیمی Search Console نیز در ژانویه ۲۰۲۴ کنار گذاشته شد. بار را با Verify bot، Log، Capacity، Cache، URL policy و پاسخ‌های درست Server مدیریت کنید. رفتار Bot دیگر را از مستندات اپراتور خودش بگیرید.

robots.txt وردپرس چه محتوایی داشته باشد؟

نسخه جهانی وجود ندارد. فایل مجازی/فیزیکی، SEO plugin، Sitemap واقعی، Multisite، مسیر Admin، Asset و Endpointهای لازم را Inventory کنید. Rule حداقلی بسازید و روی URLهای واقعی تست کنید؛ نمونه /wp-admin/ و admin-ajax.php را کورکورانه کپی نکنید.

جمع‌بندی: robots.txt را Policy قابل‌تست ببینید

فایل robots.txt یک Policy عمومی و Cache‌شونده برای کنترل Request Crawlerهای همکار است. ارزش آن در تعداد Ruleها نیست؛ در Scope دقیق، انتخاب کنترل درست، Delivery پایدار، آزمون URL واقعی و Monitoring پس از تغییر است.

از Origin inventory شروع کنید، Crawl/Index/Security را جدا کنید، Rule حداقلی بسازید، Parser و Delivery را آزمایش و Rollout را با Rollback انجام دهید. هر تغییر باید پاسخ دهد چه Requestی کم می‌شود، چه URL حیاتی محفوظ می‌ماند و با کدام داده تصمیم ادامه یا بازگشت گرفته می‌شود. برای پذیرش سطح صفحه نیز چک‌لیست سئو داخلی پیش و پس از انتشار را اجرا کنید.

منابع رسمی و استاندارد

• RFC Editor: RFC 9309 — Robots Exclusion Protocol
• Google Search Central: مقدمه robots.txt
• Google Crawling Infrastructure: تفسیر مشخصات robots.txt
• Google: ساخت و انتشار robots.txt
• Google Search Console: Robots.txt report
• Google Search Console: Crawl Stats و Availability فایل
• Google: جلوگیری از Index با noindex
• Google Crawling Infrastructure: مدیریت Crawl budget
• Google Search Central: Googlebot و روش Verify
• Google Search Central: توقف Crawl Rate Limiter در Search Console
• WordPress Developer Resources: Hook رسمی robots_txt