robots.txt چیست؟ آموزش ساخت، دستورات و تست فایل ربات

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

اهمیت این تفاوت زمانی روشن می‌شود که یک قانون اشتباه، فایل‌های CSS و JavaScript یا تمام صفحات سایت را از دسترس Googlebot خارج کند. پیش از هر تغییر باید هدف URLها، وضعیت ایندکس و نقشه سایت را کنار هم ببینید؛ راهنمای ممیزی فنی خزش و ایندکس برای همین بررسی سراسری مفید است. اگر مسئله شما فقط یک فایل نیست و به معماری محتوا هم مربوط می‌شود، خدمات سئو و تولید محتوا روبینش مسیر کامل‌تری ارائه می‌کند. هدف این مقاله آن است که به‌جای کپی‌کردن یک نمونه عمومی، بتوانید یک سیاست خزش متناسب با سایت خود بسازید.

«فایل robots.txt به خزنده‌های موتور جستجو می‌گوید به کدام URLهای سایت شما می‌توانند دسترسی داشته باشند. این فایل عمدتاً برای جلوگیری از واردشدن بار بیش از حد درخواست‌ها به سایت استفاده می‌شود و سازوکاری برای خارج نگه‌داشتن یک صفحه وب از گوگل نیست.»

فایل robots.txt چیست و دقیقاً چه کاری انجام می‌دهد؟

فایل robots.txt پیاده‌سازی «پروتکل منع ربات‌ها» یا Robots Exclusion Protocol است و مجموعه‌ای از گروه‌ها و قواعد متنی را در خود نگه می‌دارد. خزنده سازگار، پیش از خزش مسیرهای یک مبدا، فایل را دریافت می‌کند و گروه مربوط به user-agent خود را می‌خواند. سپس با توجه به Allow و Disallow تصمیم می‌گیرد درخواست یک URL مجاز است یا نه. نبودن این فایل نیز خطا محسوب نمی‌شود و معمولاً به این معناست که محدودیت عمومی برای خزش تعریف نکرده‌اید.

کاربرد منطقی robots.txt کم‌کردن خزش مسیرهای تکراری، نتایج جستجوی داخلی، پارامترهای بی‌پایان یا بخش‌هایی است که برای موتور جستجو ارزش ندارند. در سایت کوچک و مرتب، لازم نیست فقط برای «داشتن فایل حرفه‌ای» ده‌ها قانون بنویسید؛ هر قانون اضافه سطح ریسک را بیشتر می‌کند. در سایت بزرگ، این فایل می‌تواند بخشی از مدیریت بودجه خزش باشد، اما جای معماری URL، لینک‌سازی داخلی و کیفیت محتوا را نمی‌گیرد. برای درک مسیر کشف صفحات، مطالعه راهنمای نقشه سایت XML مکمل طبیعی این بحث است.

فایل robots.txt کجاست؟ قانون ریشه، دامنه و پروتکل

نام فایل باید دقیقاً robots.txt باشد و در ریشه سایت قرار گیرد؛ برای نمونه https://example.com/robots.txt. قرار دادن آن در /blog/robots.txt یا پوشه‌ای دیگر معتبر نیست، زیرا خزنده برای قواعد عمومی فقط ریشه را بررسی می‌کند. فایل باید متن ساده با کدگذاری UTF-8 باشد و با پاسخ قابل دسترس سرو شود، نه اینکه صفحه HTML قالب‌دار یا صفحه ورود نمایش داده شود. بزرگ و کوچک بودن حروف مسیرها نیز مهم است، چون مقدار مسیر در قواعد به حروف حساس است.

دامنه اعتبار فایل به همان host، protocol و port محدود است. بنابراین فایل روی https://example.com لزوماً برای http://example.com، ساب‌دامین shop.example.com یا پورت غیرمعمول معتبر نیست و هر مبدا به فایل خودش نیاز دارد. نسخه www و بدون www نیز اگر هر دو مستقل در دسترس باشند، باید با سیاست ریدایرکت و فایل صحیح مدیریت شوند. این ظرافت در مهاجرت دامنه یا تغییر HTTPS مهم است و بهتر است در کنار اصول سئو داخلی و سیگنال‌های canonical ارزیابی شود.

ساخت فایل robots.txt از صفر

برای ساخت فایل robots.txt ابتدا فهرستی از مسیرهای قابل خزش و مسیرهای کم‌ارزش تهیه کنید، سپس ساده‌ترین مجموعه قواعدی را بنویسید که همان هدف را محقق می‌کند. فایل را با یک ویرایشگر متن ساده و UTF-8 ذخیره کنید، در ریشه مبدا قرار دهید و در مرورگر بازشدن آدرس نهایی را بررسی کنید. پیش از انتشار، صفحه اصلی، صفحات خدمات، مقالات، فایل‌های CSS و JavaScript و تصاویر ضروری را با قواعد پیشنهادی آزمایش کنید. بعد از انتشار نیز پاسخ HTTP، محتوای فایل و گزارش Search Console را کنترل کنید.

یک نمونه پایه که خزش عمومی را باز می‌گذارد و نقشه سایت را معرفی می‌کند، چنین است. خط خالی گروه‌ها را خواناتر می‌کند و توضیح بعد از علامت # کامنت است. آدرس Sitemap باید مطلق و شامل پروتکل و دامنه باشد. اگر دلیل مشخصی برای مسدودسازی ندارید، این نمونه کم‌ریسک‌تر از فهرستی طولانی و کپی‌شده از سایت دیگر است.

User-agent: *
Allow: /

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

برای سایتی که جستجوی داخلی و یک بخش مدیریتی عمومی دارد، می‌توان قواعد محدودتری نوشت. بااین‌حال، مسیر مدیریت باید با احراز هویت واقعی محافظت شود و Disallow فقط از خزش عادی جلوگیری می‌کند. همچنین پارامترها را کورکورانه نبندید، زیرا بعضی URLهای پارامتری ممکن است برای رندر، محصول یا زبان ضروری باشند. نمونه زیر صرفاً الگو است و باید با URLهای واقعی سایت تطبیق داده شود.

User-agent: *
Disallow: /admin/
Disallow: /search/
Disallow: /*?sort=
Allow: /admin/public-help/

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

دستورات robots.txt: User-agent، Disallow، Allow و Sitemap

User-agent نام خزنده هدف را مشخص می‌کند و ستاره به معنای همه خزنده‌های سازگار است. Disallow مسیر غیرمجاز برای خزش و Allow استثنای مجاز در یک مسیر گسترده‌تر است. Sitemap نشانی کامل نقشه سایت یا sitemap index را اعلام می‌کند و به گروه user-agent خاصی محدود نیست. طبق مستند رسمی، این چهار فیلد هسته قواعدی هستند که گوگل در robots.txt پشتیبانی می‌کند.

دستورهایی مانند crawl-delay برای Googlebot پشتیبانی نمی‌شوند، هرچند ممکن است خزنده دیگری تفسیرشان کند. همچنین قراردادن nofollow یا noindex در robots.txt راه معتبر کنترل گوگل نیست. اگر چند گروه برای یک user-agent مشخص وجود داشته باشد، گوگل قواعد گروه‌های همان user-agent را با هم ادغام می‌کند؛ اما گروه اختصاصی Googlebot با گروه عمومی ستاره ترکیب نمی‌شود. بنابراین تعریف گروه اختصاصی بدون تکرار قواعد لازم می‌تواند ناخواسته محدودیت‌های عمومی را برای آن خزنده کنار بگذارد.

کاربرد دقیق wildcard ستاره و علامت دلار

گوگل، بینگ و چند موتور اصلی شکل محدودی از wildcard را پشتیبانی می‌کنند: * نماینده صفر یا چند نویسه و $ نشانه پایان URL است. برای نمونه Disallow: /*.pdf$ مسیرهایی را هدف می‌گیرد که دقیقاً به .pdf ختم می‌شوند، اما URL دارای پارامتر بعد از پسوند با این الگو یکسان نیست. دستور Disallow: /private/ فقط مسیرهای داخل آن پوشه را می‌گیرد، درحالی‌که Disallow: /private مسیرهایی مانند /private-notes را هم می‌تواند منطبق کند. به همین دلیل یک اسلش یا دلار کوچک، دامنه قانون را جدی تغییر می‌دهد.

وقتی چند قاعده با URL منطبق باشند، گوگل قاعده مشخص‌تر را بر اساس طول مسیر تطبیق‌یافته انتخاب می‌کند و در تعارض هم‌طول، قاعده کم‌محدودکننده را ترجیح می‌دهد. نباید تصور کنید «آخرین خط همیشه برنده است»؛ ترتیب قواعد جای منطق تطبیق را نمی‌گیرد. هر الگوی wildcard را با چند URL مجاز و غیرمجاز واقعی تست کنید، به‌ویژه اگر فروشگاه شما فیلتر، پارامتر یا پسوندهای متعدد دارد. قانون گسترده‌ای مثل Disallow: /*? ممکن است URLهای ضروری را نیز از خزش خارج کند.

تفاوت robots.txt و noindex؛ اشتباهی که ایندکس را پیچیده می‌کند

robots.txt اجازه خزش را کنترل می‌کند، اما noindex دستور ایندکس‌نکردن است که در meta robots صفحه یا هدر HTTP قرار می‌گیرد. گوگل صریحاً اعلام می‌کند که noindex داخل فایل robots.txt پشتیبانی نمی‌شود. اگر URL را Disallow کنید و هم‌زمان روی صفحه noindex بگذارید، Googlebot ممکن است به‌دلیل منع خزش اصلاً صفحه را دریافت نکند تا noindex را ببیند. برای خارج‌کردن صفحه قابل دسترس از نتایج، باید اجازه خزش بدهید و noindex معتبر ارائه کنید.

یک URL disallowed همچنان ممکن است از لینک خارجی، انکر تکست یا نقشه‌های قدیمی کشف شود و آدرسش بدون توضیح محتوایی در نتیجه جستجو ظاهر شود. از robots.txt برای مخفی‌کردن اطلاعات شخصی، فایل قرارداد، محیط staging یا پنل مدیریت استفاده نکنید؛ این فایل عمومی است و حتی نام مسیرهای حساس را آشکار می‌کند. محتوای محرمانه به احراز هویت، محدودیت شبکه یا حذف واقعی نیاز دارد. این تفکیک باید بخشی از چک‌لیست کنترل ایندکس سایت باشد، نه یک اصلاح لحظه‌ای در فایل.

تست robots.txt؛ از مرورگر تا URL Inspection

تست robots.txt را با بازکردن آدرس ریشه در مرورگر و بررسی پاسخ HTTP آغاز کنید. فایل باید محتوای متنی مورد انتظار را برگرداند و گرفتار ریدایرکت زنجیره‌ای، خطای سرور، صفحه ورود یا HTML اشتباه نباشد. سپس مجموعه‌ای از URLهای نماینده تهیه کنید: صفحه اصلی، صفحه خدمت، مقاله، تصویر، فایل استایل، مسیر مدیریت، جستجوی داخلی و URL پارامتری. برای هرکدام مشخص کنید کدام user-agent باید Allowed یا Disallowed باشد و نتیجه واقعی را با انتظار مقایسه کنید.

در سرچ کنسول، گزارش robots.txt فایل‌های شناخته‌شده برای hostهای سایت، زمان آخرین خزش و خطاها یا هشدارهای پردازش را نشان می‌دهد و در تغییر اضطراری امکان درخواست بازخزش دارد. برای یک URL مشخص، ابزار URL Inspection و گزینه Live Test را اجرا کنید و مقدار Crawl allowed? را ببینید. این گزارش جای تست قبل از استقرار را نمی‌گیرد؛ بهتر است پیش‌نویس را در محیط کنترل‌شده یا با parser سازگار با استاندارد اعتبارسنجی کنید. پس از تغییرات مهم نیز چند صفحه درآمدزا را دوباره بررسی کنید تا یک قاعده عمومی باعث افت خزش نشده باشد.

robots.txt در سرچ کنسول چگونه بررسی می‌شود؟

Search Console فایل شما را میزبانی یا ویرایش نمی‌کند؛ نسخه اصلی باید روی سرور سایت تغییر کند. گزارش robots.txt نشان می‌دهد گوگل کدام فایل را برای مبداهای مرتبط دیده، آخرین بار چه زمانی آن را دریافت کرده و آیا هنگام پردازش هشدار یا خطا داشته است. اگر تغییر حیاتی داده‌اید، می‌توانید از همان گزارش درخواست recrawl بدهید، اما کش گوگل و چرخه دریافت به این معناست که اثر تغییر همیشه آنی نیست. گوگل معمولاً فایل را تا حدود ۲۴ ساعت cache می‌کند و در شرایط خطا ممکن است نسخه سالم قبلی را بیشتر نگه دارد.

وضعیت Crawl allowed در URL Inspection پاسخ می‌دهد که قاعده فعلی اجازه خزش URL موردنظر را می‌دهد یا نه، نه اینکه صفحه حتماً ایندکس خواهد شد. ایندکس به noindex، canonical، کیفیت محتوا، پاسخ HTTP و سیگنال‌های دیگر هم وابسته است. اگر صفحه مهم در گزارش Pages دیده نمی‌شود، فقط robots.txt را مقصر ندانید و تحلیل افت و تغییرات گوگل را همراه داده‌های فنی بررسی کنید. برای سایت‌های موبایل‌محور نیز مطمئن شوید منابع لازم برای رندر نسخه اصلی بسته نیستند؛ راهنمای Mobile-First Indexing این وابستگی را توضیح می‌دهد.

robots.txt وردپرس؛ فایل مجازی یا فایل واقعی؟

وردپرس در بسیاری از نصب‌ها وقتی فایل فیزیکی وجود ندارد، یک robots.txt مجازی تولید می‌کند که در آدرس ریشه دیده می‌شود. می‌توانید با افزونه‌های معتبر سئو یا ساخت فایل واقعی در ریشه وب آن را مدیریت کنید، اما هم‌زمان چند منبع تولیدکننده نداشته باشید. گزینه «از موتورهای جستجو درخواست کن تا محتوای سایت را بررسی نکنند» در تنظیمات خواندن برای سایت زنده خطرناک است و باید پس از انتقال از staging بازبینی شود. افزونه نیز نمی‌تواند امنیت /wp-admin/ را تامین کند؛ احراز هویت وردپرس وظیفه دیگری دارد.

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

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?s=
Disallow: /search/

Sitemap: https://example.com/sitemap_index.xml

آرشیو نویسنده، برچسب، دسته و صفحات صفحه‌بندی‌شده را فقط به‌دلیل وردپرسی‌بودن مسدود نکنید؛ تصمیم باید به ارزش و استراتژی ایندکس آن‌ها وابسته باشد. اگر آرشیوی thin یا تکراری است، noindex قابل مشاهده برای خزنده معمولاً از Disallow شفاف‌تر است. تغییر permalink، افزونه کش و CDN نیز می‌تواند باعث شود فایلی متفاوت از چیزی که در پیشخوان می‌بینید سرو شود. همیشه آدرس عمومی نهایی را بعد از پاک‌سازی cache بازبینی کنید.

ساخت robots.txt در Next.js با robots.ts

در Next.js App Router می‌توان فایل را با Metadata Route در app/robots.ts تولید کرد. مزیت این روش آن است که دامنه، نقشه سایت و قواعد با تنظیمات پروژه نسخه‌بندی می‌شوند و در استقرارهای مختلف قابل کنترل‌اند. خروجی نهایی همچنان باید در /robots.txt متن معتبر برگرداند؛ وجود فایل TypeScript به‌تنهایی تضمین نمی‌کند route، دامنه یا متغیر محیطی درست است. پس از deploy، خروجی واقعی production را مانند هر فایل robots.txt دیگری تست کنید.

import type { MetadataRoute } from 'next'

export default function robots(): MetadataRoute.Robots {
  const baseUrl = 'https://example.com'

  return {
    rules: [
      {
        userAgent: '*',
        allow: '/',
        disallow: ['/admin/', '/api/private/', '/search/'],
      },
    ],
    sitemap: `${baseUrl}/sitemap.xml`,
    host: baseUrl,
  }
}

محیط preview یا staging بهتر است پشت احراز هویت یا محدودیت دسترسی باشد، نه اینکه فقط با Disallow: / پنهان شود. اگر robots.ts را بر اساس environment تغییر می‌دهید، از نبودن متغیر یا تشخیص اشتباه production جلوگیری کنید و تست خودکار برای خروجی نهایی بنویسید. Sitemap داینامیک را نیز از همان منبع URLهای public بسازید تا یک صفحه هم‌زمان در نقشه سایت دعوت و در robots منع نشود. نمونه معماری و خطاهای رایج این لایه را می‌توانید در ساخت sitemap برای سایت‌های داینامیک دنبال کنید.

خزنده‌های هوش مصنوعی و robots.txt؛ سیاست جدا بدون بستن Googlebot

برخی ارائه‌دهندگان هوش مصنوعی user-agentهای مشخصی برای خزنده آموزش، جستجو یا بازیابی محتوا معرفی می‌کنند و ممکن است robots.txt را رعایت کنند. پیش از افزودن هر نام، مستند رسمی همان ارائه‌دهنده و هدف دقیق crawler را بررسی کنید؛ نام‌های مشابه لزوماً کاربرد یکسان ندارند و امکان جعل user-agent نیز وجود دارد. تصمیم مسدودسازی باید با سیاست حقوقی، توزیع محتوا، دیده‌شدن برند و ظرفیت سرور هماهنگ باشد. robots.txt تضمین فنی علیه برداشت محتوا نیست و برای حفاظت قطعی از داده خصوصی مناسب نخواهد بود.

مهم‌ترین خطا این است که برای محدودکردن یک AI crawler، گروه عمومی User-agent: * را با Disallow: / ببندید و ناخواسته Googlebot و سایر موتورهای جستجو را هم متوقف کنید. برای هر crawler موردنظر گروه اختصاصی بنویسید و گروه عمومی را جدا و باز نگه دارید. چون Googlebot هنگام وجود گروه اختصاصی، قواعد عمومی را با آن ترکیب نمی‌کند، اگر گروه اختصاصی Googlebot ساخته‌اید تمام قواعد لازم را همان‌جا روشن بنویسید. بعد از تغییر، دست‌کم URLهای اصلی را با user-agent گوگل و قواعد عمومی دوباره تست کنید.

# نام خزنده را فقط از مستند رسمی ارائه‌دهنده بردارید
User-agent: ExampleAIBot
Disallow: /

# موتورهای جستجو را ناخواسته مسدود نکنید
User-agent: *
Allow: /

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

خطاهای رایج robots.txt که باید قبل از انتشار پیدا شوند

خطرناک‌ترین اشتباه Disallow: / روی سایت production است؛ این خط گاهی از محیط آزمایشی به انتشار نهایی منتقل می‌شود. پس از آن، مسدودکردن CSS، JavaScript و منابع تصویری لازم برای رندر، استفاده از مسیر با حروف اشتباه، و قرار دادن فایل در پوشه غیرریشه قرار می‌گیرند. معرفی sitemap نسبی یا قدیمی، کپی قواعد سایت دیگر و فرض اینکه آخرین خط برنده است نیز خطاهای پرتکرارند. هر تغییر کوچک باید مانند تغییر پیکربندی زیرساخت review و ثبت شود.

اشتباه مفهومی دیگر استفاده از robots.txt برای حذف فوری URL از گوگل، پنهان‌کردن فایل محرمانه یا حل محتوای تکراری است. برای duplicate باید canonical، ریدایرکت، لینک داخلی و کیفیت نسخه اصلی را بررسی کرد؛ برای حذف از ایندکس noindex یا وضعیت HTTP مناسب لازم است. مسدودسازی URL دارای noindex باعث می‌شود خزنده نتواند همان دستور را بخواند و فرایند خروج از ایندکس کند یا نامطمئن شود. اگر این موارد در چند بخش سایت تکرار شده‌اند، یک بازبینی کامل سئو تکنیکال از اصلاح تک‌فایل مطمئن‌تر است.

• Disallow: / ناخواسته روی دامنه اصلی
• استفاده از noindex: یا crawl-delay: با انتظار پشتیبانی Googlebot
• بستن فایل‌های رندر و در نتیجه مشاهده ناقص صفحه توسط گوگل
• فراموش‌کردن فایل جدا برای ساب‌دامین، پروتکل یا پورت دیگر
• قرار دادن URLهای مسدودشده داخل sitemap و لینک‌های مهم ناوبری
• استفاده از robots.txt به‌عنوان کنترل امنیت یا حریم خصوصی
• ویرایش افزونه وردپرس بدون بررسی cache، CDN و خروجی عمومی
• نداشتن تست regression پس از deploy یا مهاجرت دامنه

چک‌لیست عملی ساخت و تست فایل robots.txt

قبل از اجرا، هدف هر قانون را در یک جمله بنویسید و مالک فنی آن را مشخص کنید. اگر نمی‌توانید توضیح دهید یک مسیر چرا باید از خزش خارج شود، احتمالاً هنوز برای افزودن آن آماده نیستید. نمونه URLهای مهم و کم‌ارزش را از داده واقعی سایت استخراج کنید، نه از حدس یا یک قالب اینترنتی. سپس مراحل زیر را به‌ترتیب انجام دهید و نتیجه را در مستند انتشار نگه دارید.

1. فهرست hostها، ساب‌دامین‌ها، پروتکل‌ها و محیط‌های قابل دسترس را تهیه کنید.
2. URLهای حیاتی شامل خانه، خدمات، محصولات، مقالات و منابع رندر را علامت بزنید.
3. قواعد را با کمترین تعداد خط و گروه user-agent بنویسید.
4. فایل UTF-8 را دقیقاً در مسیر /robots.txt هر مبدا قرار دهید.
5. پاسخ HTTP، نوع محتوای قابل خواندن و نبودن صفحه HTML یا login را کنترل کنید.
6. wildcard و علامت دلار را روی URLهای دارای پارامتر، پسوند و حروف متفاوت تست کنید.
7. مطمئن شوید صفحه دارای noindex برای دیده‌شدن این دستور قابل خزش است.
8. تطابق Sitemap، canonical، لینک‌های داخلی و قواعد robots را بررسی کنید.
9. گزارش robots.txt و Live Test ابزار URL Inspection را بعد از انتشار ببینید.
10. پس از deploy، مهاجرت، تغییر CDN یا افزونه سئو تست regression را تکرار کنید.

این چک‌لیست را فقط برای صفحه اصلی اجرا نکنید؛ نمونه‌ای از هر template و مسیر پارامتری لازم است. در سایت‌های بزرگ، لاگ سرور نشان می‌دهد Googlebot واقعاً کدام مسیرها را درخواست می‌کند و آیا تغییر قواعد اثر موردنظر داشته است. کاهش خزش همیشه موفقیت نیست؛ شاید مسیرهای ارزشمند را کم کرده باشید یا کشف محتوای تازه کند شده باشد. تصمیم را با داده Search Console، لاگ و اهداف محتوایی بسنجید و در صورت نیاز از کنترل‌های سئو در سطح صفحه کمک بگیرید.

نگهداری فایل پس از مهاجرت، بازطراحی و تغییر محتوا

robots.txt فایل «یک‌بار بساز و فراموش کن» نیست، اما تغییر مداوم و بی‌دلیل هم نباید داشته باشد. پس از مهاجرت دامنه، فعال‌شدن HTTPS، ایجاد ساب‌دامین فروشگاه، تغییر ساختار وردپرس یا افزودن routeهای Next.js آن را بازبینی کنید. قواعد قدیمی ممکن است به مسیرهایی اشاره کنند که دیگر وجود ندارند یا بدتر، با مسیر جدید و ارزشمند هم‌پوشانی پیدا کنند. تاریخ تغییر، دلیل و مجموعه URLهای تست‌شده را در کنترل نسخه یا گزارش فنی ثبت کنید.

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

جمع‌بندی: robots.txt راهنمای خزش است، نه ابزار حذف یا امنیت

robots.txt در ریشه هر host و protocol قرار می‌گیرد و با User-agent، Disallow، Allow و Sitemap به خزنده‌های سازگار درباره دسترسی به مسیرها راهنمایی می‌دهد. URL مسدودشده همچنان ممکن است بدون خزش محتوا ایندکس شود، بنابراین برای عدم ایندکس باید noindex قابل مشاهده، X-Robots-Tag، وضعیت حذف مناسب یا حفاظت واقعی انتخاب شود. noindex داخل robots.txt برای گوگل پشتیبانی نمی‌شود و wildcardهای * و $ نیز باید با URLهای واقعی آزمایش شوند. در وردپرس و Next.js، معیار نهایی همیشه خروجی عمومی /robots.txt و اثر آن بر صفحات مهم است.

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