بودجه خزش یا کرال باجت گوگل چیست؟

بودجه‌ی خزش (crawl budget) از نگاه گوگل

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

این محدودیت فقط مخصوص گوگل نیست.

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

اسم رسمی این رفتار تو مستندات گوگل crawl budget است، ولی بیشتر برداشت های اشتباه از همین جا شروع می شه. خیلی ها فکر می کنن این عدد به بازدید کاربر واقعی یا دفعات لود شدن صفحه توسط مرورگر کاربر ربط داره. اشتباهه. موضوع فقط رفتار Googlebot است، ربات هایی که قبل از رسیدن نوبت به کاربر واقعی، باید صفحه رو ببینن، بفهمن، و به سیستم ایندکس گزارش بدن.

طبق سند رسمی گوگل که آخرین بار در نوزده دسامبر ۲۰۲۵ به روزرسانی شده، بودجه‌ی خزش از ترکیب دو مولفه‌ی مستقل ساخته می شه، یکی سقفی که سرور شما تحمل می کنه بدون این که فشار زیادی ببینه، و دیگری میزان تمایل واقعی گوگل به خزیدن صفحات شما بر پایه محبوبیت و کهنگی محتوا. نکته مهمی که خود همین سند تاکید می کنه اینه که حتی اگه ظرفیت سرور شما پر نشده باشه، اگه اون تمایل پایین باشه، گوگل باز هم کمتر سراغ سایت شما میاد. یعنی داشتن سروری قدرتمند به تنهایی هیچ تضمینی برای خزیده شدن بیشتر نیست.

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

ظرفیت خزش (crawl rate limit) چیست؟

اولین مولفه رو گوگل می گه crawl rate limit.
این یعنی گوگل خودش رو محدود می کنه که چقدر سریع بتونه به سرور شما درخواست بفرسته، بدون این که سایتتون رو کند یا داون کنه.
اگه سرور شما سریع جواب بده، گوگل جسورتر میشه و درخواست بیشتری می فرسته، و اگه کند باشه یا خطای 500 برگردونه، عقب می کشه.
این رفتار خودکاره و شما مستقیم کنترلش نمی کنید، فقط با بهبود سرعت سرور روش اثر می ذارید.

تقاضای خزش (crawl demand) چیست؟

مولفه‌ی دوم، اونی که واقعا جالب تره، تقاضای خزشه.
اینجا دیگه بحث سرعت نیست، بحث میل گوگله.
گوگل حتی اگه سرور شما ظرفیت هزار درخواست در ثانیه رو داشته باشه، اگه فکر کنه صفحه هاتون ارزش خزیده شدن مکرر رو ندارن، باز هم کمتر میاد سراغتون.

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

خانواده (Googlebot) ربات‌های گوگل و وظیفه‌ی هرکدام

تا اینجا هر جا گفتیم "گوگل میاد سایتتون رو می خزه" انگار داریم از یه ربات واحد حرف می زنیم.
واقعیت اینه که گوگل یه خانواده کامل از ربات ها رو می فرسته، هر کدوم با یه ماموریت مشخص.

طبق فهرست رسمی گوگل که تو بیست و سه آوریل 2026 به روز شده، این ها اصلی ترین اعضای این خانواده هستن.
ربات اصلی به اسم Googlebot مسئول دیدن صفحات معمولی برای نتایج جستو جوی گوگله، هم نسخه‌ی موبایلش هم دسکتاپش.
دو ربات تخصصی هم به اسم Googlebot Image و Googlebot Video داریم، که فقط دنبال محتوای تصویری و ویدئویی می گردن.
یه ربات دیگه به اسم Googlebot News، مخصوص بخش اخبار گوگله.
ربات کمتر شناخته شده ای هم به اسم StoreBot هست، وظیفه اش چک کردن قیمت و موجودی محصولاته، برای گوگل شاپینگ.
یه ابزار خزنده به اسم Google-InspectionTool هم هست، پشت ابزارهایی مثل بازرسی آدرس تو سرچ کنسول قرار داره، رفتارش خیلی شبیه Googlebot معمولیه.
یه دسته دیگه به اسم GoogleOther، برای تحقیق و توسعه داخلی تیم های مختلف گوگل استفاده می شه، نه مستقیم برای نتایج جستو جو.
در آخر یه مورد به اسم Google-Extended داریم که فرق اساسی با بقیه داره، چون کارش خزیدن برای نتایج جست‌و جو نیست، بلکه به شما اجازه می ده جدا تصمیم بگیرید محتواتون برای آموزش مدل های هوش مصنوعی گوگل استفاده بشه یا نه.
نکته ای که خیلی ها ازش غافل می شن اینه که هر کدوم از این ربات ها بودجه‌ی جدا و مستقل مصرف می کنن.
یعنی وقتی می گیم "بودجه‌ی خزش سایت"، در واقع داریم رفتار چند ربات جدا رو با هم جمع می زنیم، نه یه ربات تنها.

پشت‌صحنه‌ی تصمیم، نمره‌ی (Crawl Score) اولویت‌بندی آدرس‌ها

تا اینجا فهمیدیم گوگل چقدر می تونه بخزه و چقدر می خواد بخزه.
سوال بعدی اینه، وقتی گوگل هزاران آدرس جلوش داره، از کجا می فهمه اول کدومو بره سراغش؟
جواب این سوال تو مستندات عمومی گوگل نیست، تو پتنت هاشونه، جایی که کمتر کسی سراغش می ره.

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

بالاتر از لایه‌ی روزانه، یه لایه‌ی آنی هم تعریف شده که می تونه شامل میلیون ها آدرس باشه، برای محتوایی که واقعا نیاز به تازگی لحظه ای داره، مثل اخبار در حال وقوع.
پایین تر از لایه‌ی روزانه هم بخش هایی هست که آدرس ها بر اساس درصدی از کل فضای آدرس های شناخته شده تقسیم می شن و با سرعت کندتری بازبینی می شن.
این دقیقا همون چیزیه که خیلی ها اسمش رو ایندکس تازه در برابر ایندکس اصلی می ذارن، بدون این که بدونن ریشه اش از کجا اومده.
یه پتنت دیگه، که مخصوص زمان بندی بر پایه‌ی تغییرات محتواست، یه مکانیزم جالب تر رو باز می کنه.
طبق این پتنت، گوگل صفحات رو تو دسته هایی قرار می ده که هر دسته یه بازه‌ی خزش مشخص داره، مثلا یه دسته که هر روز خزیده می شه، یه دسته که هر دو روز یک بار.
این دسته بندی اولیه بر پایه‌ی محبوبیته، ولی اگه گوگل تشخیص بده یه صفحه سریع تر از چیزی که خودش بهش می گه change frequency اجازه می ده تغییر می کنه، همون صفحه رو به یه دسته‌ی تندتر منتقل می کنه.
یعنی حتی یه صفحه‌ی کم لینک، اگه محتواش مرتب و واقعی عوض بشه، می تونه جای خودش رو تو صف بالاتر ببره، و این دقیقا نقطه ایه که خیلی از سایت های کوچیک ازش غافلن.
یه پتنت دیگه هم مفهومی به اسم آدرس اجباری رو معرفی می کنه.
طبق این مفهوم، اگه نمره‌ی یه آدرس به اندازه‌ی کافی بالا باشه، اون آدرس دیگه وارد رقابت با بقیه نمی شه، بلکه تضمین می شه که حتما خزیده بشه.
یعنی خزش دو مرحله داره، یه مرحله‌ی رقابت معمولی بین آدرس ها، و یه صف تضمین شده و جدا برای صفحاتی که اهمیتشون خیلی بالاست.
و در نهایت، یه پتنت دیگه هم نشون می ده نقش فایل نقشه سایت خیلی جدی تر از چیزیه که فکر می کنیم.

طبق این پتنت، گوگل از اطلاعاتی مثل last modification date، فرکانس به روزرسانی، و اولویتی که خود سایت تو نقشه سایت اعلام کرده، به عنوان یکی از ورودی های همون سیستم امتیازدهی استفاده می کنه، و حتی یه ضریب تقویتی هم بر اساس محبوبیت سند به همون امتیاز اضافه می کنه.
این پتنت همچنین اشاره می کنه که سرعت خزش هر سایت می تونه جدا و اختصاصی ذخیره بشه، یعنی گوگل برای هر دامنه یه حافظه‌ی جداگانه از رفتار قبلی سرور داره و بر پایه‌ی همون حافظه تصمیم می گیره دفعه‌ی بعد با چه سرعتی سراغش بره.
یعنی نقشه‌ی سایت فقط یه فایل تشریفاتی برای کشف آدرس نیست، بلکه مستقیم رو تصمیم زمان بندی خزش هم اثر می ذاره، البته به شرطی که اطلاعاتش دقیق و به روز باشه، چون اگه سایتی همیشه بگه همه چیز هر روز تغییر کرده در حالی که واقعا این طور نیست، گوگل به مرور به همون اعلام اولویت اعتماد کمتری می کنه.

چرا در سرچ کنسول عدد مستقیم بودجه دیده نمی شود

خیلی از کسایی که تازه با این مفهوم آشنا می شن، اول می رن تو سرچ کنسول دنبال یه عدد به اسم بودجه می گردن.
باید همین اول بگم، چنین چیزی وجود نداره.
هیچ جای سرچ کنسول یه جدول یا گزارش نیست که بنویسه بودجه‌ی سایت شما امروز فلان عدده.
چیزی که واقعا وجود داره، گزارشیه به اسم Crawl Stats، که تو بخش تنظیمات پنهان شده.
این گزارش بودجه رو مستقیم نشون نمی ده، بلکه اثر بودجه رو نشون می ده، یعنی رفتار واقعی ربات گوگل رو تو نود روز گذشته.
طبق مستندات پشتیبانی گوگل، این گزارش شامل تعداد کل درخواست هایی می شه که برای آدرس های سایت شما ارسال شده، چه موفق چه ناموفق.
اگه یه منبع تو صفحه‌ی شما باشه، مثل تصویر یا فایل جاوااسکریپت، درخواست اون منبع هم تو همین شمارش حساب می شه، به شرطی که خودش هم رو همون سایت میزبانی شده باشه.
نکته ای که خیلی ها ازش غافلن اینه که درخواست های تکراری برای یه آدرس، جدا از هم شمرده می شن، یعنی اگه گوگل ده بار یه صفحه رو بخزه، این ده بار جدا حساب می شه، نه یک بار.
قبل از هر چیز، این گزارش یه بخش به اسم Host status داره که خیلی‌ها ازش رد می شن، درحالی که مهم ترین بخششه.
طبق همون مستندات، این بخش سه چیز رو جداگانه چک می کنه.
اول، وضعیت دریافت فایل robots.txt، یعنی گوگل تونسته این فایل رو با موفقیت بگیره یا نه.
اگه این فایل برای مدت طولانی در دسترس نباشه، گوگل کلا خزیدن سایت شما رو متوقف می کنه، چون بدون این فایل نمی دونه اجازه‌ی رفتن به کدوم بخش ها رو داره.

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

بخش پاسخ ها نشون می ده گوگل موقع درخواست هاش چه کدهایی گرفته.
اینجا فقط کد 200 (یعنی موفق) و 404 (یعنی صفحه پیدا نشد) نیست، چند کد دیگه هم هست که کمتر شناخته شدن.
کد سیصد و چهار یعنی Not modified، یعنی گوگل قبلا این صفحه رو دیده و الان فقط پرسیده چیزی عوض شده یا نه، و سرور جواب داده نه، که این خودش نشونه‌ی خوبیه چون یعنی سرور شما بهینه جواب می ده و پهنای باند کمتری مصرف می شه.
خطای 500 یعنی سرور شما موقع درخواست خراب شده، که باید فورا رفع بشه.
خطای DNS و DNS unresponsive هم همون مشکل تفکیک دامنه است که تو Host status هم گفتیم، ولی اینجا نمونه‌ی دقیقشو نشون می ده.
Robots.txt not available هم یعنی گوگل موقع همون درخواست خاص نتونسته فایل robots را بگیره.
بخش نوع فایل نشون می ده گوگل بیشتر وقتش رو صرف چی کرده، HTML، تصویر، جاوااسکریپت، یا چیز دیگه.
اگه سهم زیادی از این بخش صرف فایل هایی بشه که برای رتبه گرفتن اهمیتی ندارن، مثل تصاویر تکراری یا فایل های حجیم جاوااسکریپت، این خودش یه نوع هدر رفتن غیرمستقیم بودجه‌ست.

بخش هدف، یا Purpose، نشون می ده چند درصد از درخواست ها برای کشف آدرس تازه بوده و چند درصد برای تازه سازی آدرس قدیمی.
و بخش نوع ربات هم نشون می ده کدوم یکی از خانواده‌ی ربات هایی که تو بخش چهار معرفی کردیم، بیشترین سهم رو از خزیدن سایت شما داشتن.

بخش های مختلف کرال استس by file type.

بخش by response کرال استس.

بخش مختلف by response .

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

تفاوت آمار خزش با گزارش وضعیت نمایه سازی

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

بذارید ردیف به ردیف باز کنیم.
Page with redirect یعنی آدرس اصلی به یه آدرس دیگه ریدایرکت شده، پس خود آدرس اول نمایه نمی شه، این طبیعیه اگه ریدایرکت عمدی و درست باشه.
Server error پنج ایکس ایکس یعنی موقع خزش، سرور شما خطای 500 برگردونده، این جدی گرفته بشه، چون هم نشونه‌ی مشکل واقعی سروره هم مستقیم رو تمایل خزش که تو بخش دو گفتیم اثر منفی می ذاره.
Excluded by noindex tag یعنی خود شما یا سیستم مدیریت محتوا صریحا گفته این صفحه نمایه نشه، معمولا عمدیه، فقط باید مطمئن بشید اشتباهی رو صفحه‌ی مهمی نیفتاده باشه.
Not found 404 یعنی صفحه واقعا وجود نداره، برای گوگل هم مشکلی نیست، به شرطی که این آدرس جایی تو سایت شما لینک نشده باشه.
حالا می رسیم به دو موردی که بیشترین سوءتفاهم رو دارن.
Discovered currently not indexed یعنی گوگل آدرس رو می شناسه، شاید از نقشه‌ی سایت یا یه لینک داخلی، ولی هنوز اصلا نرفته سراغش، این مستقیم به بودجه‌ی خزش ربط داره، یعنی گوگل هنوز وقت یا تمایل کافی برای اومدن سراغش نداشته.
Crawled currently not indexed کاملا فرق داره، یعنی گوگل واقعا اومده، صفحه رو خونده، و بعد از خوندن تصمیم گرفته این محتوا ارزش نمایه شدن نداره، این دیگه بودجه نیست، این یعنی مشکل کیفیت محتواست.

این تفاوت مهمه چون راه حلشون کاملا جداست، برای مورد اول باید لینک داخلی بیشتر بدید تا اهمیت اون صفحه بالاتر بره، برای مورد دوم باید محتوا رو عمیق تر و متفاوت تر کنید، صرفا درخواست نمایه سازی (index) دوباره کمکی نمی کنه.
Duplicate without user selected canonical و Alternate page with proper canonical tag هر دو به تشخیص نسخه‌ی اصلی از نسخه‌ی تکراری مربوطن که تو بحث بودجه هم بهش اشاره کردیم، این دو معمولا طبیعی هستن و نیاز به نگرانی ندارن.
و Redirect error یعنی زنجیره‌ی ریدایرکت شما یا خیلی طولانیه یا به یه حلقه‌ی بی پایان رسیده، این مستقیم بودجه رو هدر می ده و باید اصلاح بشه.
جمع بندی این که کدوم ها واقعا مهمن، سه مورد رو باید جدی بگیرید، خطای سرور، ریدایرکت خراب، و Discovered currently not indexed اگه تعدادش زیاد باشه، بقیه معمولا بخشی از رفتار طبیعی یه سایته و نیازی به دستکاری فوری ندارن.

چیزهایی که بودجه‌ی خزش را هدر می‌دهند

تا اینجا بیشتر تئوری بود.
حالا می‌خوام یه نمونه‌ی واقعی از یکی از مشاوره‌هام بیارم که دقیقاً نشون می‌ده این هدر رفتن بودجه چطور تو عمل اتفاق می‌افته.
تیمی رو دیدم که چون بعضی از کلمات کلیدیشون رتبه نمی‌گرفتن، تصمیم گرفته بودن صفحاتی که فقط از نظر تایتل شبیه هم بودن، ولی از نظر محتوا کاملاً متفاوت بودن، رو به هم ریدایرکت کنن.
فکرشون این بود که این کار سیگنال‌های پراکنده رو یه‌جا جمع می‌کنه و رتبه بالا میره.
نتیجه برعکس شد.
طبق سند رسمی گوگل، ریدایرکت هایی که به مقصد نامعادل می‌رن، رفتار عجیبی از خودشون نشون می‌دن.
مارتین اسپلیت، developer advocate گوگل، تو یکی از قسمت های ویدیویی SEO Office Hours Shorts، در مارس 2025، دقیقاً همین قانون رو توضیح داد، اگه محتوا جای دیگه‌ای رفته، ریدایرکت بزن به همون مقصد واقعی، اگه واقعاً از بین رفته، به نزدیک‌ترین حدس ریدایرکت نکن.

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

نمونه‌ی دوم، وقتی طراح سایت اعتماد گوگل را نابود می کند

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

یعنی فنی مسدود نمی شه، ولی عملا با همون نتیجه‌ی مسدود شدن روبه رو می شی.
دوم، صفحات صفحه بندی (پیجینیشن) رو نوایندکس کرده بود.
نوایندکس جلوی خزش رو نمی گیره، جلوی نمایش تو نتایج رو می گیره، ولی مشکل واقعی این بود که تنها مسیر رسیدن به پست های عمقی از همون صفحه بندی بود، و وقتی اون مسیر هم نوفالو بود هم نوایندکس، عملا هیچ راهی برای رسیدن به پست های عمقی نمی موند.
سوم، بعضی از صفحات هم یه canonical اشتباه داشتن که به آدرس دیگه ای اشاره می کرد.
یعنی حتی اگه گوگل بعضی از این صفحات رو می دید، به خاطر همون canonical، اون رو نسخه‌ی اصلی نمی دونست و ارزش نمایه شدن جدا رو بهش نمی داد.
نتیجه‌ی این سه اشتباه با هم این شد که از شش صد پست، فقط سه تا نمایه شده بودن.
نکته‌ی جالب و نگران کننده این بود که تو گزارش نمایه سازی (ایندکس) سرچ کنسول، حتی عدد Discovered هم تقریبا صفر بود.
یعنی مشکل فقط نمایه نشدن نبود، گوگل اصلا این آدرس ها رو کشف نکرده بود، چون هیچ مسیر لینکی معتبری براشون نمونده بود.
بعد از این که مشکل شناسایی و رفع شد، انتظار می رفت گوگل سریع برگرده و همه چیز رو نمایه کنه.
اتفاقی که واقعا افتاد این بود که حتی بعد از رفع مشکل، سرعت نمایه شدن خیلی کند بود، چیزی حدود یک پست در روز.
این بخش رو باید صادقانه بگم، مشاهده‌ی خودم از این پروژه است، نه چیزی که مستقیم از گوگل نقل قول کرده باشم، ولی با مفهوم تمایل خزش که تو بخش سه گفتیم هم خوانی داره، چون تمایل خزش فقط به تعداد صفحه بستگی نداره، به اعتماد کلی به سایت هم وابسته است، و وقتی اون اعتماد یک بار به شدت آسیب می بینه، برگشتنش زمان بره، نه فقط رفع فنی مشکل.
درسی که از این تجربه می شه گرفت اینه که وقتی همچین آسیبی به یه سایت وارد می شه، فقط رفع مشکل فنی کافی نیست.
باید تا جایی که می شه سیگنال های اجتماعی واقعی برای سایت ساخت، و لینک خارجی با بازدید واقعی برای فهرست محتواهایی گرفت که واقعا با هم مرتبطن، تا اعتماد از دست رفته سریع تر برگرده.

الگویی تکرارشونده، از ثبات تا جهش و بازگشت به ثبات

اگه هر کدوم از نمودارهای واقعی سرچ کنسول رو برای یه دوره‌ی طولانی نگاه کنی، یه الگوی مشخص و تکرارشونده می‌بینی.
یه بازه‌ی نسبتا ثابت، بعد یه جهش ناگهانی و شدید، و بعد نشستن رو یه سطح جدید که معمولا بالاتر از قبله، ولی باز هم ثابت.
این الگو تصادفی نیست، و می‌شه با همون مفاهیمی که تا اینجا باز کردیم توضیحش داد.
بازه‌ی ثابت اول، یعنی نمره‌ی خزش (crawl score) اکثر آدرس‌های سایت شما تو یه محدوده‌ی مشخص و پیش‌بینی‌پذیره.
گوگل هم داره طبق همون فرمولی که تو بخش پنج گفتیم، یه ریتم عادی از بازدید رو دنبال می‌کنه.
جهش ناگهانی معمولا یکی از چند تا اتفاق رو نشون می‌ده.
اولی می‌تونه یه تغییر واقعی تو تمایل خزش (crawl demand) باشه، یعنی یه اتفاق باعث شده گوگل یهو محتوای شما رو مهم‌تر از قبل ببینه، مثلا یه موج لینک‌سازی طبیعی، یا انتشار حجم زیادی محتوای تازه که سیگنال تازگی رو بالا برده.
دومی می‌تونه یه تغییر تو ظرفیت خزش (crawl rate limit) باشه، یعنی شما زیرساخت سرور رو بهتر کردید و گوگل داره همون تست تدریجی‌ای که قبلا گفتیم رو انجام می‌ده، یعنی داره کم‌کم سقف جدید رو امتحان می‌کنه.
سومی که کمتر بهش توجه می‌شه، تغییر تو نتیجه‌ی deduplication است، یعنی وقتی گوگل تصمیم می‌گیره تعداد بیشتری از نسخه‌های نزدیک‌به‌هم رو به‌جای کنار گذاشتن، جدا از هم در نظر بگیره، که این خودش می‌تونه حجم درخواست‌ها رو بالا ببره بدون این‌که واقعا محتوای تازه‌ای اضافه شده باشه.
نکته‌ای که تو بخش هفت هم گفتیم اینجا دوباره مهم می‌شه.
بعد از جهش، بخش زیادی از این درخواست‌های جدید معمولا از نوع refresh می‌شن، نه discovery، یعنی گوگل داره یه‌بار همه‌چیز رو دوباره ارزیابی می‌کنه، نه این‌که فقط داره آدرس تازه پیدا می‌کنه.
و در آخر، دلیل این‌که بعد از جهش دوباره می‌شینه رو یه سطح ثابت، همون منطق سقف مؤثری هست که تو بخش دو گفتیم، بودجه‌ی واقعی همیشه رو کوچیک‌ترین مؤلفه قفل می‌شه، نه بزرگ‌ترین.
یعنی حتی اگه تمایل خزش برای مدتی خیلی بالا بره، به محض این‌که ظرفیت سرور یا سقف طبیعی تقاضا به محدودیت خودش برسه، رفتار دوباره تثبیت می‌شه، فقط رو یه پله‌ی بالاتر.
جمع‌بندیش اینه که این نوسان نشونه‌ی خرابی نیست، نشونه‌ی اینه که گوگل داره مدام تعادل بین این چند تا فاکتور رو دوباره حساب می‌کنه.

موج تازه، ربات‌های هوش مصنوعی (AI bots) و سهم‌خواهی از سرور

تا اینجا هرچی گفتیم فرض‌مون این بود که تنها بازیگر مهم Googlebot است.
ولی از یکی دو سال گذشته، یه متغیر تازه وارد این معادله شده که سند رسمی بودجه‌ی خزش گوگل هم هنوز به‌طور کامل درباره‌ش صحبت نکرده.
طبق گزارش Cloudflare Radar، بین ماه می 2024 تا می 2025، ترافیک خزندگان جستو جو و هوش مصنوعی روی هم رفته هجده درصد رشد کرد.

GPTBot که مال OpenAI است، تو همین بازه سهمش از 5% به 30% رسید، یعنی شش برابر شد.
خود Googlebot هم بی‌تاثیر نبود، ترافیکش نود و 6% رشد کرد، که بخشی از این رشد به راه‌اندازی AI Overviews مربوط می‌شه.

نکته‌ای که این‌جا برای شما مهمه اینه که این ربات‌های تازه، برخلاف Googlebot، هیچ سهمی از همون بودجه‌ای که تا الان توضیح دادیم مصرف نمی‌کنن، چون بودجه‌ی خزش مال Googlebot و خانواده‌ی رباتاش هست، نه مال GPTBot یا Bytespider.
پس مشکل مستقیم نیست، غیرمستقیمه.
وقتی این ربات‌ها همزمان با Googlebot به سرور شما درخواست می‌فرستن، ظرفیت واقعی سرور برای جواب دادن بین همه‌شون تقسیم می‌شه.
و طبق همون فرمولی که تو بخش دو گفتیم، ظرفیت خزش (crawl rate limit) مستقیم به سرعت جواب سرور بستگی داره.
یعنی اگه سرور شما به‌خاطر مشغول بودن با ربات‌های دیگه کندتر جواب بده، Googlebot این کندی رو می‌بینه و خودش رو عقب می‌کشه، حتی اگه خود Googlebot هیچ درخواست اضافه‌ای نفرستاده باشه.
این‌جا یه تصمیم واقعی هم پیش روی صاحبان سایت قرار می‌گیره.
مسدود کردن ربات‌های هوش مصنوعی از طریق robots.txt ظرفیت بیشتری برای Googlebot آزاد می‌کنه، ولی به قیمت این‌که محتوای شما دیگه تو پاسخ‌های تولیدی این پلتفرم‌ها دیده نمی‌شه.
این یه تصمیم استراتژیک و کاملا وابسته به هدف کسب‌وکاره، نه یه قانون ثابت که برای همه یکی باشه.

دیکشنری اصطلاحات کاربردی بودجه‌ی خزش

قبل از این که بریم سراغ بخش های عملی تر، بهتره یه بار همه‌ی اصطلاحاتی که تا اینجا استفاده کردیم رو کنار هم بذاریم، چون تو منابع فارسی این کلمه ها معمولا قاطی هم استفاده می شن.
سقف سرعت (crawl rate limit) یعنی حداکثر سرعتی که گوگل بدون آسیب به سرور شما درخواست می فرسته.
تمایل خزش (crawl demand) یعنی میزان علاقه‌ی واقعی گوگل به اومدن سراغ صفحات شما، بر پایه‌ی محبوبیت و تازه بودن محتوا.
بودجه‌ی خزش (crawl budget) نتیجه‌ی نهاییه، همون ترکیبی که از دو مورد بالا به دست میاد.
نمره‌ی خزش (crawl score) اصطلاحیه که تو پتنت های زمان بندی گوگل اومده، حاصل ضرب محبوبیت صفحه، فرکانس تغییر محتوا، و فاصله‌ی زمانی از آخرین خزش.
لایه‌ی روزانه بخشی از صف خزشه که آدرس های تازه و پراهمیت رو نگه می داره و هر یک دوره، معمولا یک روز، دوباره چک می شه.
لایه‌ی آنی سطحی بالاتر از لایه‌ی روزانه است، برای محتوایی که نیاز به تازگی لحظه ای داره.
آدرس اجباری (must-crawl) به آدرسی گفته می شه که نمره اش اونقدر بالاست که دیگه وارد رقابت با بقیه نمی شه و تضمین می شه خزیده بشه.
آمار خزش (crawl stats) گزارشیه تو سرچ کنسول که رفتار واقعی خزیدن رو نشون می ده، نه خود بودجه رو.
هدف خزش (crawl purpose) تو همون گزارش دو حالت داره، یکی کشف که یعنی گوگل داره یه آدرس تازه رو می بینه، یکی تازه سازی که یعنی داره صفحه ای که قبلا دیده رو دوباره بررسی می کنه.

تاریخچه، از یک‌ماه خزش تا زیر یک دقیقه

برای این‌که بفهمیم چرا امروز اصلا همچین محدودیتی به اسم بودجه‌ی خزش وجود داره، بد نیست یه نگاه به گذشته بندازیم.
جف دین، یکی از فلوهای ارشد گوگل، تو یه سخنرانی تو دانشگاه استنفورد در نوامبر 2010، یه مقایسه‌ی جالب مطرح کرد.

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

رشد وزن صفحات در یک دهه

یه فاکتور دیگه که کمتر بهش توجه می‌شه، رشد فیزیکی خود صفحاته، نه رشد تعداد صفحات.
طبق سند رسمی گوگل درباره‌ی خزش وب، میانه‌ی وزن صفحه‌ی موبایل از 816 کیلوبایت به حدود دو و سه‌دهم مگابایت رسیده، یعنی تقریبا سه برابر شده.

خود گوگل دلیلش رو هم توضیح می‌ده، صفحات وب پیچیده‌تر شدن و امروز میانه‌ی هر صفحه بیش از شصت فایل جدا برای بارگذاری داره، از تصویر گرفته تا اجزای تعاملی.
همین موضوعه که باعث می‌شه گوگل بعضی‌وقت‌ها مجبور بشه یه صفحه رو چند بار بخزه تا بتونه تصویر کاملی از محتوای واقعیش بگیره.
مارتین اسپلیت، developer advocate گوگل، هم تو یکی از گفت‌وگوهاش به همین روند اشاره کرده و تاکید کرده این رشد مستقیم رو زمان و منابعی که Googlebot صرف هر صفحه می‌کنه اثر می‌ذاره.
جان مولر هم یه داده‌ی تکمیلی جالب داده، طبق بررسی خودش رو آرشیو Web Almanac، میانه‌ی حجم HTML خالص (بدون تصویر و جاوااسکریپت) رو موبایل حدود سی و سه کیلوبایته، و نود درصد صفحات وب زیر صد و پنجاه و یک کیلوبایت HTML دارن.
یعنی با وجود این رشد سه‌برابری کلی وزن صفحه، بخش HTML خالص هنوز خیلی کوچیک‌تر از سقفی هست که Googlebot براش در نظر می‌گیره.
و این‌جا دقیقاً باید بگیم اون سقف چقدره.
طبق همون سند رسمی زیرساخت خزش گوگل، یه سقف پیش‌فرض عمومی وجود داره که رو کل خزنده‌ها و fetcherهای گوگل حاکمه، 15 مگابایت برای هر فایل.
ولی Googlebot به‌طور اختصاصی برای جست‌وجو، سقف دقیق‌تری داره، 2 مگابایت برای HTML و متن، و 64 مگابایت برای PDF.
اگه HTML شما از 2مگابایت بیشتر بشه، Googlebot دریافتش رو دقیقاً همون‌جا قطع می‌کنه، و فقط همون بخشی که تا اون نقطه گرفته رو برای نمایه‌سازی می‌فرسته، بقیه‌ی صفحه انگار اصلا وجود نداره.
این سقف شامل هدرهای HTTP هم می‌شه، و روی داده‌ی فشرده‌نشده اعمال می‌شه، یعنی حتی اگه سرور شما با gzip فشرده‌سازی کنه، حجم واقعی قبل از فشرده‌سازی ملاکه.
جان مولر تو بلواسکای، ششم فوریه 2026، این نکته رو هم روشن کرد که Googlebot فقط یکی از خزنده‌های گوگله، نه همه‌شون، یعنی این سقف 2 مگابایتی مخصوص همین رباته، و ربات‌های دیگه‌ای مثل Googlebot Image و Googlebot Video ممکنه سقف‌های متفاوتی داشته باشن که عمومی اعلام نشدن.
نتیجه‌ی عملی این‌که با وجود این‌که میانه‌ی HTML وب هنوز خیلی کوچیک‌تر از 2 مگابایته، اگه شما اسکریپت‌های بزرگ رو به‌جای فایل جدا، مستقیم داخل HTML بنویسید، یا مقدار زیادی داده‌ی base64 وسط کد بذارید، ممکنه بخش‌های مهم صفحه‌تون، مثل تگ‌های ساختاری یا محتوای اصلی، بعد از همون نقطه‌ی برش قرار بگیرن و اصلا دیده نشن.

پتنت‌های خزش گوگل، برای مخاطب حرفه‌ای

اگه تا اینجا اومدی و می‌خوای عمیق‌تر بدونی، این بخش برای توئه.
تو بخش پنج گفتیم گوگل چند تا پتنت داره که مکانیزم اولویت‌بندی رو توضیح می‌ده، حالا بذار جزئیات ثبتی و فنی‌تر هرکدوم رو باز کنیم.
اولین پتنت با شماره‌ی US7725452B1 و عنوان Scheduler for search engine crawler ثبت شده، و بعدها یه نسخه‌ی ادامه‌دار باهاش (continuation) هم به شماره‌ی US10621241B2 منتشر شده، که یعنی گوگل خودش هم بعد از سال‌ها هنوز داره رو همین مکانیزم پایه کار می‌کنه و به‌روزش می‌کنه.

طبق این پتنت، فرمول نمره‌ی خزش دقیقاً این‌طور تعریف شده، نمره برابره با مجذور پیج‌رنک ضرب‌در فرکانس تغییر ضرب‌در فاصله‌ی زمانی از آخرین خزش.
نکته‌ی فنی‌ای که تو بخش پنج نگفتیم اینه که خود پتنت اشاره می‌کنه این فرمول فقط یه نمونه است، و گوگل می‌تونه ضرایب دیگه‌ای مثل اسپم‌بودن دامنه یا سابقه‌ی خطای سرور رو هم به همین فرمول اضافه کنه.
دومین پتنت، US20130144858A1 با عنوان Scheduling resource crawls، یه مفهوم فنی به اسم subscription count معرفی می‌کنه.
طبق این پتنت، سرعت خزش هر منبع با تعداد اشتراک‌کننده‌هاش رابطه‌ی عکس داره، یعنی هرچقدر یه منبع مشترک بیشتری داشته باشه (مثلا از طریق فیدهای RSS یا سیستم‌های اعلان تغییر)، فاصله‌ی زمانی بین خزش‌هاش کوتاه‌تر می‌شه.
این پتنت همچنین یه سازوکار جبرانی داره، اگه نرخ تغییر واقعی یه صفحه خیلی بیشتر از سرعت خزش تخصیص‌یافته باشه، اون صفحه به یه دسته‌ی سریع‌تر منتقل می‌شه، تا از کهنه‌ماندن جلوگیری بشه.
سومین و چهارمین پتنت، US8417686B2 و نسخه‌ی قدیمی‌ترش US8037054B2، هر دو با عنوان Web crawler scheduler that utilizes sitemaps from websites ثبت شدن.

اینجا یه اصطلاح فنی به اسم must-crawl معرفی می‌شه، یعنی اگه نمره‌ی یه آدرس از یه آستانه بالاتر بره، اون آدرس دیگه وارد رقابت با بقیه نمی‌شه و تضمین می‌شه که خزیده بشه.
همین پتنت یه جزئیات فنی جالب دیگه هم داره، برای هر سایت، اطلاعات مربوط به سرعت خزش و فاصله‌ی خزش به‌طور جداگانه تو یه پایگاه‌داده به اسم per-site information database ذخیره می‌شه، یعنی گوگل واقعا یه حافظه‌ی مستقل و اختصاصی برای هر دامنه نگه می‌داره، نه یه قانون سراسری برای کل وب.
جمع‌بندی این چهار پتنت اینه که چیزی که برای خیلی از سئوکارها یه جعبه‌سیاه به‌نظر می‌رسه، در واقع یه سیستم امتیازدهی مستند و قابل ردیابیه، فقط جایی که کمتر کسی زحمت خوندنش رو به خودش می‌ده.

جمع بندی و چند اقدام عملی برای امروز

اگه بخوایم هرچی تا اینجا گفتیم رو تو چند خط جمع کنیم، داستان از این قراره.
بودجه‌ی خزش نه یه عدد ثابته که گوگل بهتون بده، نه چیزی که بشه مستقیم تو سرچ کنسول دیدش، بلکه نتیجه‌ی تعامل دائمی بین ظرفیت سروری که شما فراهم می‌کنید و تمایلی که گوگل بر اساس کیفیت و تازگی محتواتون نشون می‌ده.
این تعامل با یه فرمول ریاضی مشخص و قابل ردیابی تو پتنت‌های خود گوگل مدیریت می‌شه، نه با حدس و گمان.
حالا اگه بخوای همین امروز شروع کنی، این ترتیب رو پیشنهاد می‌دم.
اول، برو سراغ Host status تو گزارش Crawl Stats.
اگه اونجا سرخ یا زرده، هیچ کار دیگه‌ای انجام نده تا اول همون رو حل کنی، چون بدون یه Host status سالم، بقیه‌ی تحلیل‌ها بی‌فایده‌ن.
دوم، نگاه کن ببین سهم بزرگی از درخواست‌های گوگل صرف چه نوع فایلی می‌شه.
اگه سهم زیادی مال تصویر یا جاوااسکریپت اضافه‌ست، این اولین جای هدررفت بودجه‌ست.
سوم، تو گزارش نمایه‌سازی، بین Discovered currently not indexed و Crawled currently not indexed فرق بذار.
اولی مشکل بودجه‌ست، راه حلش لینک داخلی بیشتره.
دومی مشکل کیفیته، راه حلش محتوای عمیق‌تره، نه درخواست نمایه‌سازی دوباره.
چهارم، ریدایرکت‌هات رو یه‌بار کامل بررسی کن.
فقط باید صفحه‌ای که واقعاً محتوای معادل داره مقصد ریدایرکت باشه، نه نزدیک‌ترین حدس، همون درسی که از تجربه‌ی واقعی این مقاله گرفتیم.
پنجم، اگه لینک‌های داخلی سایتت به‌طور گسترده نوفالو هستن، همین امروز بررسی کن چرا، چون این می‌تونه بی‌سروصدا تمایل خزش رو نابود کنه.
و در آخر، اگه سایتت داره با ربات‌های هوش مصنوعی هم سروکله می‌زنه، یه تصمیم آگاهانه بگیر، نه بر اساس ترس، بلکه بر اساس این‌که واقعاً می‌خوای تو نتایج این پلتفرم‌ها دیده بشی یا نه.
بودجه‌ی خزش یه مفهوم انتزاعی نیست، یه رفتار قابل اندازه‌گیریه، و تا وقتی از روی داده‌ی واقعی سایت خودتون تحلیلش نکنید، هر عددی که جای دیگه شنیدید فقط یه حدسه.

تحلیل، جمع آوری و نگارش: شهرام رهبری

منابع :

اسناد رسمی گوگل
developers.google.com/crawling/docs/crawl-budget
developers.google.com/crawling/docs/crawlers-fetchers/google-common-crawlers
developers.google.com/crawling/docs/crawlers-fetchers/overview-google-crawlers
developers.google.com/search/docs/crawling-indexing/googlebot
support.google.com/webmasters/answer/9679690
support.google.com/webmasters/answer/7440203

پتنت‌های گوگل
patents.google.com/patent/US7725452B1
patents.google.com/patent/US10621241B2
patents.google.com/patent/US20130144858A1
patents.google.com/patent/US8417686B2
patents.google.com/patent/US8037054B2

اظهارات گوگلرها
Martin Splitt، Developer Advocate at Google: searchenginejournal.com/googles-martin-splitt-warns-against-redirecting-404s-to-homepage/541549
Martin Splitt، Developer Advocate at Google: searchenginejournal.com/google-pages-are-getting-larger-it-still-matters/570875
John Mueller، Search Advocate at Google: bsky.app (بلواسکای، ششم فوریه 2026)
Jeff Dean، Senior Fellow at Google: سخنرانی دانشگاه استنفورد، دهم نوامبر 2010

داده‌های شخص ثالث
Cloudflare Radar: blog.cloudflare.com/from-googlebot-to-gptbot-whos-crawling-your-site-in-2025