بودجه خزش یا Crawl Budget به تعداد و نحوه درخواست‌هایی اشاره دارد که خزنده موتور جست‌وجو در یک بازه از سایت انجام می‌دهد. این مفهوم برای همه سایت‌ها به یک اندازه مسئله‌ساز نیست؛ یک وب‌سایت کوچک با چند ده صفحه معمولاً بیشتر از آنکه به مدیریت بودجه خزش نیاز داشته باشد، به محتوای مفید و ساختار سالم نیاز دارد. اما در فروشگاه‌های بزرگ و سایت‌هایی با URLهای پارامتری فراوان، هدایت خزش به صفحات مهم می‌تواند اهمیت پیدا کند.
۱. ظرفیت خزش و تقاضای خزش را از هم جدا کنید
به شکل ساده، دو موضوع مهم مطرح است: ظرفیت خزش و تقاضای خزش. ظرفیت به تعداد درخواست‌هایی مربوط است که سرور می‌تواند بدون افت کیفیت پاسخ دهد. تقاضا به علاقه موتور جست‌وجو برای مراجعه دوباره به URLها مربوط می‌شود؛ اهمیت صفحات، تازگی محتوا، لینک‌های داخلی و تغییرات سایت می‌توانند در آن نقش داشته باشند. این دو مفهوم در عمل با یک عدد ثابت و قابل کنترل از سوی مدیر سایت خلاصه نمی‌شوند.
بودجه خزش را با تعداد صفحات ایندکس‌شده اشتباه نگیرید. ممکن است خزنده صفحه‌ای را بازدید کند اما آن را ایندکس نکند، یا صفحه‌ای در ایندکس بماند اما به ندرت دوباره خزش شود. افزایش تعداد درخواست‌ها لزوماً موفقیت نیست. اگر ربات بیشتر وقت خود را صرف URLهای بی‌ارزش، پارامترهای تکراری یا صفحات خطادار کند، خزش بیشتر فقط بار سرور و پیچیدگی گزارش را بالا می‌برد.
۲. چه سایت‌هایی باید به آن توجه کنند؟
اگر سایت چند ده صفحه ثابت دارد و ساختار ساده‌ای دارد، معمولاً نیازی به پروژه پیچیده مدیریت Crawl Budget نیست. در مقابل، فروشگاه‌هایی با هزاران محصول، فیلترهای متعدد، صفحه‌بندی عمیق، محتوای روزانه یا صفحات تولیدشده توسط کاربران ممکن است با انفجار URL روبه‌رو شوند. سایت‌هایی که موجودی محصولات مرتب تغییر می‌کند نیز باید مسیر کشف و به‌روزرسانی صفحات مهم را بررسی کنند.
نشانه‌های قابل بررسی شامل تعداد زیاد URLهای کم‌ارزش، درخواست مکرر به صفحات تکراری، تأخیر در خزش محتوای تازه، پاسخ کند سرور و خطاهای زیاد در لاگ است. هیچ‌یک به تنهایی اثبات نمی‌کند که مشکل حتماً بودجه خزش است. ابتدا مطمئن شوید URLهای مهم لینک داخلی دارند، پاسخ ۲۰۰ می‌دهند، canonical درست دارند و محتوای آن‌ها برای ایندکس مناسب است.
۳. گزارش سرچ کنسول را در بازه زمانی تحلیل کنید
گزارش Crawl Stats اطلاعاتی درباره درخواست‌های خزنده، نوع فایل، پاسخ سرور و وضعیت میزبان ارائه می‌کند. روندها را در بازه زمانی بررسی کنید و به تغییر ناگهانی تعداد درخواست‌ها، افزایش پاسخ‌های ۵xx یا رشد زمان پاسخ توجه داشته باشید. یک روز پرترافیک یا افت کوتاه به تنهایی مبنای تصمیم نیست؛ آن را با انتشار محتوا، تغییر قالب، کمپین یا تغییر زیرساخت تطبیق دهید.
گزارش Page Indexing برای دیدن وضعیت صفحات مفید است، اما جایگزین لاگ سرور نیست. سرچ کنسول همه جزئیات درخواست‌های واقعی را نشان نمی‌دهد و داده‌های آن با تأخیر و محدودیت نمونه‌گیری ارائه می‌شود. چند URL مهم را با URL Inspection بررسی کنید و نتیجه را کنار گزارش خزش و لاگ قرار دهید. برای تفسیر داده‌ها، راهنمای تحلیل سرچ کنسول را هم ببینید.
۴. لاگ سرور را به منبع تشخیص تبدیل کنید
لاگ دسترسی وب‌سرور نشان می‌دهد چه رباتی، در چه زمانی، کدام URL را درخواست کرده و چه پاسخی دریافت کرده است. برای تحلیل معتبر، ربات واقعی موتور جست‌وجو را از user-agent جعلی جدا کنید؛ درج نام Googlebot در user-agent اثبات هویت نیست. در صورت نیاز، روش‌های تأیید IP و DNS معکوس را مطابق مستندات معتبر به کار ببرید و داده‌های حساس کاربران را در گزارش منتشر نکنید.
URLها را بر اساس الگوی مسیر گروه‌بندی کنید: محصول، دسته، مقاله، جست‌وجوی داخلی، فیلتر، صفحه‌بندی و فایل استاتیک. سهم درخواست هر گروه، کد پاسخ، زمان پاسخ و تکرار درخواست را بسنجید. اگر بخش بزرگی از خزش به پارامترهای بی‌ارزش اختصاص دارد، منبع تولید لینک و سیاست URL را پیدا کنید. اصلاح علت معمولاً پایدارتر از مسدودسازی عجولانه نشانه‌هاست.
۵. URLهای تکراری و پارامتری را کنترل کنید
فیلترها، مرتب‌سازی، پارامترهای رهگیری، جست‌وجوی داخلی و ترکیب‌های صفحه‌بندی می‌توانند تعداد URLها را چند برابر کنند. بعضی صفحات برای کاربر لازم‌اند اما ارزش مستقل جست‌وجویی ندارند. ساختار پارامترها را مستند کنید و مشخص کنید کدام الگو باید crawl شود، کدام باید canonical به نسخه ترجیحی داشته باشد و کدام به شکل محدود مدیریت شود. ترتیب پارامترها را استاندارد کنید تا یک حالت واحد چند URL نسازد.
canonical برای معرفی نسخه ترجیحی و noindex برای جلوگیری از حضور صفحه در نتایج کاربرد دارند، اما هیچ‌کدام جایگزین اصلاح معماری لینک‌ها نیستند. robots.txt نیز می‌تواند دسترسی خزنده را محدود کند، ولی اگر صفحه‌ای با noindex در آن مسدود شود، ربات ممکن است دستور را نبیند. پیش از هر قانون، نمونه URLها را بررسی و اثر آن را روی مسیرهای مهم آزمایش کنید. مقاله سئوی صفحات فیلترشده برای فروشگاه‌ها مفید است.
۶. صفحات مهم را با لینک داخلی و نقشه سایت تقویت کنید
خزنده از لینک‌ها برای کشف مسیرهای جدید استفاده می‌کند. اگر صفحه مهم فقط در نقشه سایت معرفی شده و هیچ لینک داخلی مرتبطی ندارد، معماری سایت فرصت انتقال زمینه و اولویت را از دست می‌دهد. از صفحات دسته، راهنماها و مطالب مرتبط به صفحات ارزشمند لینک دهید. لینک‌ها باید طبیعی و برای کاربر مفید باشند؛ افزودن صدها لینک بی‌هدف در فوتر یا منو راهکار مناسبی نیست.
نقشه سایت باید URLهای canonical و قابل ایندکس را معرفی کند، نه تمام URLهایی که سایت می‌تواند تولید کند. صفحات noindex، ریدایرکت‌شده، خطادار و نسخه‌های تکراری را از آن حذف کنید. lastmod فقط زمانی به‌روزرسانی شود که محتوای مهم صفحه واقعاً تغییر کرده باشد. برای کنترل ساختار، راهنمای نقشه سایت XML را بررسی کنید.
۷. پاسخ سرور و محتوای کم‌ارزش را اصلاح کنید
سرور کند یا ناپایدار می‌تواند ظرفیت خزش را محدود کند. زمان پاسخ، نرخ خطا، محدودیت منابع PHP، پایگاه داده و سرویس‌های خارجی را بررسی کنید. اگر ربات با تعداد زیادی پاسخ ۵xx یا timeout مواجه شود، ممکن است مراجعه به سایت کاهش یابد تا وضعیت پایدار شود. کش صفحه، بهینه‌سازی کوئری‌ها، کاهش درخواست‌های خارجی و ارتقای منابع می‌توانند کمک کنند، اما باید با داده اندازه‌گیری شوند.
صفحات جست‌وجوی داخلی، آرشیوهای خالی، برچسب‌های کم‌محتوا و URLهای خودکار را از نظر ارزش کاربر، ترافیک و لینک ورودی بررسی کنید. محصول ناموجود نیز همیشه نباید حذف شود؛ اگر موقتاً ناموجود است، اطلاعات و جایگزین‌های مرتبط می‌توانند مفید باشند. اگر برای همیشه حذف شده، مقصد مناسب یا پاسخ ۴۰۴ را انتخاب و لینک‌های داخلی را اصلاح کنید. راهنمای ممیزی سئوی فنی برای این کار مفید است.
۸. اجرای جاوااسکریپت و برنامه اولویت‌بندی را بررسی کنید
اگر محصولات یا لینک‌های صفحه فقط پس از اجرای اسکریپت ساخته می‌شوند، بررسی کنید خزنده بتواند محتوای نهایی را دریافت کند. رندر سمت سرور یا تولید استاتیک برای بخش‌های مهم می‌تواند دسترسی را پایدارتر کند. بارگذاری تنبل باید طوری پیاده شود که محتوای اصلی بدون تعامل غیرضروری قابل کشف باشد. در ابزار URL Inspection، نسخه زنده و HTML رندرشده را مقایسه کنید و خطاهای API یا جاوااسکریپت را پیدا کنید.
URLها را بر اساس ارزش تجاری، تقاضای جست‌وجو، وضعیت ایندکس و میزان خزش غیرضروری اولویت‌بندی کنید. اصلاح صفحه محصول پرفروش معمولاً از حذف پارامتر کم‌اهمیت در بخشی کم‌ترافیک مهم‌تر است. تغییرها را مرحله‌ای منتشر کنید و پس از هر مرحله لاگ و سرچ کنسول را بسنجید. اگر هم‌زمان robots.txt، canonical و ساختار URL را تغییر دهید، تشخیص علت نتیجه دشوار خواهد شد.
چک‌لیست مدیریت بودجه خزش شامل شناسایی URLهای فیلتر و جست‌وجو، لینک داخلی مناسب، نقشه سایت تمیز، کنترل خطاهای سرور، تحلیل لاگ ربات و بررسی رندر محتواست. مدیریت Crawl Budget نباید برای سایت کوچک به پروژه‌ای پیچیده تبدیل شود؛ اندازه سایت و داده واقعی را مبنا قرار دهید و ابتدا سلامت فنی صفحات مهم را بهبود دهید.
