robots.txt وردپرس در سال ۲۰۲۶ (واقعاً چه چیزی باید داخلش باشد)

یک robots.txt خوب برای وردپرس حدود پنج خط است. مسیر /wp-admin/ را مسدود کنید، admin-ajax.php را مجاز کنید، خزنده‌ها را به نقشهٔ سایتتان اشاره بدهید و همان‌جا تمامش کنید — آن فهرست‌های ۴۰ خطی و شلوغی که در انجمن‌ها پیدا می‌کنید بیشترشان یا رندر را خراب می‌کنند یا اصلاً هیچ کاری نمی‌کنند. کل فایل:

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

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

دامنه را عوض کنید، و اگر از افزونهٔ سئویی استفاده می‌کنید که کنترل نقشهٔ سایت را در دست می‌گیرد، خط Sitemap را به فهرست همان افزونه اشاره بدهید. همین. اگر فایل شما از این بلندتر است، خط‌های اضافه احتمالاً دارند چیزی از شما می‌گیرند.

وردپرس خودش یکی می‌سازد — تا وقتی که شما فایل واقعی بسازید

وردپرس یک robots.txt مجازی ارائه می‌کند. وقتی درخواستی برای /robots.txt می‌آید و هیچ فایل واقعی در ریشهٔ وب شما نیست، وردپرس درخواست را می‌گیرد و پاسخی را در حافظه چاپ می‌کند. چیزی روی دیسک نوشته نمی‌شود. خروجی پیش‌فرض همان بلوک wp-admin بالاست، به‌علاوهٔ یک خط Sitemap: برای wp-sitemap.xml که هسته از وردپرس ۵.۵ به بعد منتشرش می‌کند.

دو چیز آن خروجی را عوض می‌کنند. اگر گزینهٔ تنظیمات ← خواندن ← موتورهای جستجو را از فهرست‌بندی این سایت منصرف کن تیک خورده باشد، وردپرس کل ماجرا را با Disallow: / جایگزین می‌کند، که همه چیز را مسدود می‌کند. آن تیک، رایج‌ترین دلیل ناپدید شدن یک سایت از جستجو بعد از راه‌اندازی است. دوم اینکه افزونه‌ها و قالب‌ها می‌توانند خروجی مجازی را از طریق فیلتر robots_txt تغییر بدهند، و افزونه‌های سئو دقیقاً از همین راه خط‌های نقشهٔ سایت و قوانین خودشان را تزریق می‌کنند.

حالا آن بخشی که بعدازظهر مردم را هدر می‌دهد. یک فایل robots.txt فیزیکی در ریشهٔ وب شما، بی‌سروصدا همهٔ این‌ها را بی‌اثر می‌کند. وب‌سرور شما یک فایل واقعی روی دیسک پیدا می‌کند، سروش می‌کند، و وردپرس اصلاً بارگذاری نمی‌شود. تولیدکنندهٔ مجازی اجرا نمی‌شود. فیلتر robots_txt شلیک نمی‌کند. ویرایشگر robots.txt در افزونهٔ سئوی شما ممکن است همچنان یک رابط تر و تمیز با قوانین درست نشانتان بدهد، و هیچ‌کدام از آن‌ها به دست هیچ خزنده‌ای نمی‌رسد.

قوانین کجا زندگی می‌کنند	قابل ویرایش در پیشخوان وردپرس	برندهٔ یک درخواست زنده
مجازی (بدون فایل روی دیسک)	بله، از طریق فیلتر robots_txt یا یک افزونه	فقط وقتی هیچ فایل فیزیکی وجود نداشته باشد
فایل فیزیکی در ریشهٔ وب	فقط اگر افزونه روی دیسک بنویسد	همیشه

پس پیش از عیب‌یابی هر چیزی: آدرس https://yoursite.com/robots.txt را در مرورگر باز کنید، بعد با SFTP یا فایل‌منیجر هاستتان وصل شوید و بررسی کنید که آیا یک robots.txt واقعی کنار wp-config.php و .htaccess نشسته است یا نه. اگر بله، همان فایل، robots.txt شماست. یا همان‌جا ویرایشش کنید یا حذفش کنید و بگذارید وردپرس کار را دست بگیرد — اما یکی را انتخاب کنید. اجرای هم‌زمان هر دو، همان چیزی است که سایت‌ها را به آدرس نقشهٔ سایتِ کهنه‌ای می‌رساند که هیچ‌کس پیدایش نمی‌کند.

چرا /wp-admin/ مسدود است اما admin-ajax.php مجاز

مسیر /wp-admin/ پیشخوان را نگه می‌دارد. آن آدرس‌ها در نتایج جستجو بی‌فایده‌اند و خزیدنشان بودجهٔ خزش را صرف صفحاتی می‌کند که به صفحهٔ ورود ریدایرکت می‌شوند. مسدود کردن این پوشه جای بحث ندارد.

اما admin-ajax.php داخل همان پوشه است و یک صفحهٔ مدیریتی نیست. این همان نقطهٔ انتهایی (endpoint) است که افزونه‌ها و قالب‌ها برای مدیریت درخواست‌های AJAX در بخش کاربری استفاده می‌کنند — دکمه‌های «بیشتر بارگذاری کن»، شبکه‌های فیلترشدهٔ محصولات، ماشین‌حساب‌ها، فرم‌ها. اگر خزنده نتواند آن را بگیرد، محتوایی را که این قابلیت‌ها بارگذاری می‌کنند نمی‌بیند، و گوگل صفحهٔ شما را همان‌طور رندر می‌کند که یک بازدیدکننده با قابلیت خراب می‌دید.

اینکه گوگل واقعاً روی سایت مشخص شما نیاز دارد admin-ajax.php را بگیرد یا نه، بستگی دارد به اینکه بخش کاربری شما از آن استفاده می‌کند یا نه. پاسخ صادقانه: روی بسیاری از سایت‌های امروزی اصلاً فرقی نمی‌کند، چون قالب به جایش از REST API در مسیر /wp-json/ استفاده می‌کند. آن خط Allow یک بیمهٔ ارزان در برابر یک حالت خرابی واقعی است، نه یک فاکتور رتبه‌بندی. نگهش دارید چون هزینه‌ای ندارد.

مسیرهای /wp-content/ یا /wp-includes/ را مسدود نکنید

این بدترین توصیهٔ robots.txt است که هنوز دست‌به‌دست می‌شود، و از دورانی می‌آید که گوگل صفحات را رندر نمی‌کرد.

پوشهٔ /wp-content/ قالب‌ها، افزونه‌ها و بارگذاری‌های شما را در خود دارد — همان شیوه‌نامه‌ها، اسکریپت‌ها و تصویرهایی که باعث می‌شوند صفحات شما شبیه صفحه به نظر برسند. پوشهٔ /wp-includes/ جاوااسکریپت هسته را دارد که افزونه‌ها به آن وابسته‌اند. گوگل پیش از قضاوت دربارهٔ صفحات شما، آن‌ها را با یک مرورگر بدون رابط گرافیکی رندر می‌کند. این پوشه‌ها را مسدود کنید و رندرکننده صفحه‌ای بدون CSS و بدون تصویر تحویل می‌گیرد. چیزی که گوگل ارزیابی می‌کند دیواری از متن بی‌استایل با چیدمانی خراب است، و این روی درک آن از محتوای شما و روی امتیاز کاربردپذیری موبایل اثر می‌گذارد.

اگر فایلی را با این خط‌ها به ارث برده‌اید، حذفشان کنید:

Disallow: /wp-content/
Disallow: /wp-includes/
Disallow: /wp-content/plugins/
Disallow: /wp-content/themes/

خودتان می‌توانید این خرابی را در ابزار URL Inspection در Google Search Console تأیید کنید. روی هر صفحه‌ای یک تست زنده اجرا کنید، اسکرین‌شات رندرشده را ببینید و فهرست منابع صفحه را از نظر موارد مسدودشده بررسی کنید. اگر CSS شما به‌عنوان مسدودشده نمایش داده می‌شود، علت همین است.

دستور Sitemap

یک خط، آدرس مطلق، و می‌تواند هر جای فایل بنشیند — به هیچ گروه User-agent گره نخورده است.

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

از آدرسی استفاده کنید که واقعاً باز می‌شود. هستهٔ وردپرس wp-sitemap.xml را سرو می‌کند. بیشتر افزونه‌های سئو نقشه‌های سایت هسته را غیرفعال می‌کنند و فهرست خودشان را در مسیری دیگر ارائه می‌دهند، معمولاً sitemap_index.xml. پیش از آنکه آدرس را نهایی کنید، آن را در مرورگر باز کنید — یک خط Sitemap که به یک ۴۰۴ اشاره می‌کند از نبودِ آن خط بدتر است، چون در ممیزی درست به نظر می‌رسد.

آوردن چند نقشهٔ سایت اشکالی ندارد، هرکدام در یک خط. ثبت جداگانهٔ نقشه‌های سایت در Search Console همچنان ارزش دارد؛ دستور robots.txt همان راهی است که خزنده‌هایی که هرگز حساب Search Console شما را نمی‌بینند از طریقش آن‌ها را پیدا می‌کنند.

robots.txt نه noindex است و نه امنیت

این دو سوءتفاهم عامل بیشتر خسارت‌های robots.txt هستند.

مسدود کردن یک آدرس آن را از گوگل حذف نمی‌کند. robots.txt خزیدن را اداره می‌کند. اگر سایت دیگری به یک آدرس مسدودشده لینک بدهد، گوگل می‌تواند خودِ آدرس را فهرست‌بندی کند — نتیجه‌ای می‌گیرید با آدرس خالی و یادداشتی مبنی بر اینکه اطلاعاتی در دسترس نیست. و یک تلهٔ بدتر هم هست: اگر صفحه‌ای همین حالا متا تگ noindex دارد و بعد آن را در robots.txt مسدود کنید، گوگل نمی‌تواند بخزدش، نمی‌تواند آن noindex را ببیند، و صفحه می‌تواند تا مدت نامعلومی در ایندکس بماند. برای حذف یک صفحه، خزیدن را مجاز کنید و یک متا تگ noindex در هد صفحه یا یک هدر X-Robots-Tag سرو کنید. گوگل از سال ۲۰۱۹ پشتیبانی از دستورهای noindex داخل robots.txt را متوقف کرده است.

مسدود کردن یک مسیر از آن محافظت نمی‌کند. فایل robots.txt شما طبق تعریف عمومی است. آوردن /private-client-files/ در آن، به هر بازدیدکننده و هر اسکنری دقیقاً می‌گوید کجا را بگردد، و رعایتش هم داوطلبانه است — گوگل رعایتش می‌کند، ربات‌های خصمانه نه. هر چیزی که نیاز به محافظت دارد به احراز هویت، محدودیت IP یا قوانین سطح سرور در .htaccess نیاز دارد، نه به یک خط در فایل متنی‌ای که محل هدف را تبلیغ می‌کند.

قوانینی که ارزش اضافه کردن دارند و قوانینی که ارزش رد کردن

دو مورد روی بسیاری از سایت‌ها واقعاً مفیدند. مسدود کردن مسیر نتایج جستجو جلوی خزنده‌ها را از تولید آدرس‌های بی‌ارزشِ بی‌پایان از جستجوی داخلی شما می‌گیرد. مسدود کردن مسیر سبد خرید یا تسویه‌حساب در WooCommerce آدرس‌های حاوی پارامتر نشست را از خزش بیرون نگه می‌دارد.

Disallow: /?s=
Disallow: /search/

از این‌ها بگذرید:

• Crawl-delay — گوگل کاملاً نادیده‌اش می‌گیرد. اگر واقعاً مشکل بار سرور دارید، از کنترل‌های نرخ خزش در Search Console استفاده کنید.
• مسدود کردن /feed/ یا /trackback/ — این‌ها آدرس‌های بی‌ضرری هستند و فیدها مفیدند.
• فهرست‌های بلند از نام تک‌تک ربات‌ها — بیشتر ربات‌هایی که مردم می‌خواهند مسدودشان کنند، اصلاً صادقانه خودشان را معرفی نمی‌کنند.
• مسدود کردن /wp-json/ — ممکن است همان چیزی باشد که قالب شما برای رندر محتوا از آن استفاده می‌کند.

فایل را با تولیدکنندهٔ robots.txt وردپرس بسازید، که نسخهٔ حداقلی و درست را تولید می‌کند و به شما اجازه می‌دهد قوانین جستجو و فروشگاه را بدون ویرایش دستی نحو اضافه کنید.

بعد از اینکه تغییرش دادید

آدرس https://yoursite.com/robots.txt را مستقیماً باز کنید و مطمئن شوید بایت‌هایی که سرو می‌شوند همان چیزی است که انتظار دارید — نه آنچه ویرایشگر افزونه نشانتان می‌دهد. بعد در Search Console روی یک صفحهٔ معمولی یک بازرسی زندهٔ آدرس اجرا کنید و بررسی کنید که هیچ منبع CSS یا جاوااسکریپتی به‌صورت مسدودشده برنمی‌گردد. گوگل فایل robots.txt را حدود یک روز کش می‌کند، پس نه اصلاح فوراً اثر می‌کند و نه اشتباه. همین تأخیر دلیل آن است که به جای تست کردن روی سایت زنده و بعد منتظر ماندن، با دقت راستی‌آزمایی کنید.