علت افت Crawl Stats چیست و چطور آن را رفع کنیم؟ (+ پروتکل عملی)

در چند ماه گذشته، خیلی از تیم‌های فنی و سئو بعد از بررسی گزارش Crawl Stats در سرچ کنسول، با افت ناگهانی نمودار Total Crawl Requests مواجه شدند و اعلام کردند Googlebot دیگر مثل قبل سایت‌شان را Crawl نمی‌کند. 

در این مقاله بررسی می‌کنیم که علت این اتفاق چیست، چطور باید این گزارش را تحلیل کنید و اگر واقعاً Crawl Stats سایت‌تان افت کرده بود، چطور با شناسایی و رفع عوامل مؤثر، مسیر بازگشت Googlebot به سایت‌تان را هموار کنید.

در نهایت هم یک چارچوب عملی که خودمان در تیم سئوی لیموهاست روی چندین کیس اجرا کرده و از آن نتیجه خوبی دیده‌ایم را با شما در میان می‌گذاریم.

خلاصه این پروتکل و اقداماتی که باید برای رفع مشکل افت Crawl Stats انجام دهید از این قرار است:

• ارتقای نسخه PHP به 8.1 یا بالاتر، برای افزایش سرعت اجرای PHP و کاهش زمان پردازش؛
• فعال‌سازی OPcache برای جلوگیری از کامپایل مجدد فایل‌های PHP؛
• نصب و پیکربندی افزونه Scope Loader برای کاهش بار اجرایی پلاگین‌ها در سایت‌های وردپرسی؛
• بررسی robots.txt و اطمینان از دسترسی بدون خطای Googlebot؛
• رفع ارورهای 404 در صفحات برای جلوگیری از Requestهای بیهوده و پردازش اضافی؛
• بهبود نرخ Response Time به زیر 500-600ms (حد مرزی 1000ms) برای کاهش هزینه پردازش هر Request؛
• ایجاد و ثبت سایت‌مپ جدید در سرچ کنسول، برای هدایت Googlebot به URLهای ارزشمندتر؛
• تهیه زیرساخت مناسب با Server connectivity بالا؛
• بررسی  و مانیتورینگ نتایج بعد از اجرای این تغییرات.

جلوتر به تفصیل هر یک از این اقدامات را توضیح می‌دهیم.

گوگل چطور سایت شما را کراول می‌کند؟

قبل از اینکه سراغ گزارش Crawl Stats برویم، بیایید ببینیم اصلاً Googlebot چطور سایت‌ها را کراول می‌کند؛ چون تقریباً تمام اطلاعاتی که بعداً در گزارش Crawl Stats می‌بینید، نتیجه همین فرآیند است.

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

کل این فرآیند در پنج مرحله انجام می‌شود:

۱. Discovery؛ پیدا کردن URL

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

اگر گوگل هیچ راهی برای رسیدن به یک صفحه نداشته باشد، طبیعتاً آن صفحه را هم Crawl نخواهد کرد.

۲. Crawling؛ دریافت صفحه

در این مرحله Googlebot درخواست HTTP ارسال و فایل‌های موردنیاز را از سرور دریافت می‌کند.

نکته مهم اینجاست که فقط HTML صفحه دانلود نمی‌شود؛ اگر صفحه برای نمایش صحیح به فایل‌های CSS، JavaScript، تصاویر، فونت‌ها یا حتی فایل‌های JSON نیاز داشته باشد، گوگل آن‌ها را هم دریافت می‌کند.

به همین دلیل است که در گزارش Crawl Stats فقط درخواست‌های مربوط به صفحات HTML را نمی‌بینید و انواع مختلفی از فایل‌ها در آن ثبت می‌شوند.

۳. Rendering؛ ساخت نسخه قابل‌مشاهده از صفحه

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

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

۴. Indexing؛ تصمیم برای ورود به ایندکس

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

سرعت ایندکس‌شدن صفحات، به میزان بودجه خزش (Crawl budget) سایت شما بستگی دارد.

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

۵. Serving؛ نمایش در نتایج جست‌وجو

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

بنابراین Crawl ،Index و Ranking سه مفهوم کاملاً متفاوت هستند و نباید آن‌ها را با هم اشتباه گرفت.

Crawl Budget چیست؟

به بودجه خزش اشاره کردیم؛ یکی از اصطلاحاتی که معمولاً کنار Crawl Stats شنیده می‌شود، Crawl Budget است. 

به زبان ساده، منظور از کراول باجت یا بودجه خزش، تعداد URLهایی است که گوگل می‌تواند و تمایل دارد در یک بازه زمانی Crawl کند.

توجه کنید که این تعریف از دو بخش تشکیل شده و هر دو شرط باید همزمان برقرار باشند:

• Crawl Capacity (ظرفیتی که می‌تواند): سایت شما چقدر ظرفیت پاسخ‌گویی دارد؟ اگر سرورتان کند باشد یا خطا بدهد، گوگل خودش سرعتش را کم می‌کند تا سایت شما را از پا نیندازد.
• Crawl Demand (مقداری که تمایل دارد): گوگل چقدر انگیزه برای Crawl کردن سایت شما دارد؟ این تمایل به تازگی، کیفیت، محبوبیت و ارتباط موضوعی محتوای شما برمی‌گردد.

نکته‌ای که خیلی وقت‌ها نادیده گرفته می‌شود این است که اگر سایت شما از نظر فنی فوق‌العاده سریع باشد، اما Demand پایینی داشته باشید، سرعت زیاد سرور به‌تنهایی باعث افزایش Crawl نمی‌شود. چون ظرفیت کراول فقط سقف را بالا می‌برد؛ این Demand است که تعیین می‌کند گوگل چقدر از آن سقف استفاده کند.

به همین دلیل برای تحلیل Crawl Stats باید هر دو بخش را هم‌زمان بررسی کنید.

بیایید نگاه‌ دقیق‌تری به این دو مفهوم داشته باشیم.

Crawl Capacity Limit چیست؟

Crawl Capacity Limit یعنی حداکثر حجمی از کراول که سایت شما بدون فشار اضافه بر سرور می‌تواند تحمل کند. 

عوامل مختلفی روی Crawl Capacity تأثیر می‌گذارند، از جمله:

• کیفیت DNS
• تعداد Workerهای وب‌سرور یا PHP-FPM
• مشکلات شبکه یا Routing
• مدت باز ماندن Connectionها و تعداد اتصال‌های همزمان
• شاخص‌های TTFB، Latency و Response Time مستقیماً روی این ظرفیت اثر دارند.
• افزایش کدهای پاسخ 5XX و 429 یکی از واضح‌ترین سیگنال‌هایی است که باعث کاهش Crawl Rate از سمت گوگل می‌شود.

اگر سایت شما سریع و پایدار باشد، این ظرفیت به‌مرور زمان افزایش پیدا می‌کند؛ یعنی گوگل به شما اعتماد بیشتری برای خزش سریع‌تر می‌دهد.

Crawl Demand چیست؟

Crawl Demand یعنی میل واقعی گوگل به Crawl کردن URLهای سایت شما، جدا از اینکه سایت‌تان چقدر ظرفیت فنی دارد.

مهم‌ترین عواملی که روی Crawl Demand اثر می‌گذارند، عبارت‌اند از:

• اندازه‌ کلی سایت و تعداد URLهای ارزشمند سایت که گوگل از قبل می‌شناسد،
• فرکانس به‌روزرسانی محتوا (سایت‌هایی که مرتب آپدیت می‌شوند، معمولاً Demand بالاتری دارند)،
• کیفیت محتوا و ارتباط موضوعی صفحات با هم،
• محبوبیت و اهمیت URLها،
• تمیزی URL Inventory و نبود صفحات کم‌ارزش یا تکراری.

پس به بیان ساده، هرچه گوگل احساس کند صفحات یک سایت ارزش بیشتری برای Crawl مجدد دارند، Crawl Demand افزایش پیدا می‌کند.

برای مثال، یک سایت خبری که هر ساعت چند مطلب جدید منتشر می‌کند، معمولاً Crawl Demand بسیار بیشتری نسبت به یک سایت شرکتی دارد که شاید ماهی یک بار محتوای جدید منتشر کند.

البته این به معنی برتری یک سایت نسبت به دیگری نیست؛ بلکه فقط نشان می‌دهد گوگل براساس نوع سایت، رفتار متفاوتی در Crawl کردن آن دارد.

نکته مهم: فکر نکنید اگر سرور را قوی‌تر کنید، گوگل هم حتماً صفحات بیشتری را Crawl خواهد کرد. همیشه در عمل این اتفاق رخ نمی‌دهد.

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

در مقابل، اگر سایت دائماً محتوای باکیفیت و به‌روز منتشر کند، اما سرور پاسخ‌گویی مناسبی نداشته باشد، ظرفیت Crawl محدود می‌شود.

به همین دلیل، وقتی نمودار Crawl Stats نزولی می‌شود، نباید فقط سراغ بررسی سرور یا فقط تولید محتوا بروید؛ بلکه باید هم ظرفیت پاسخ‌گویی سایت و هم میزان تقاضای گوگل برای Crawl را کنار هم بررسی کنید. این دقیقاً همان دیدگاهی است که در ادامه مقاله و هنگام تحلیل گزارش Crawl Stats به آن برمی‌گردیم.

گزارش Crawl Stats در سرچ کنسول چیست؟

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

گزارش Crawl Stats نحوه تعامل خزنده‌های گوگل با سرور سایت شما را نشان می‌دهد. این گزارش به چهار سؤال کلیدی پاسخ می‌دهد:

• چند درخواست برای سایت شما ارسال شده؟
• گوگل چه حجمی از منابع را دانلود کرده؟
• سایت شما با چه سرعتی پاسخ داده؟
• چه نوع خطاها یا Resourceهایی بیشتر دیده شده؟

این گزارش تمام درخواست‌هایی را که Googlebot طی ۹۰ روز گذشته برای سایت شما ارسال کرده، جمع‌آوری و تحلیل می‌کند. 

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

گزارش Crawl Stats به ما چه می‌گوید؟

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

بیایید ببینیم این سه شاخص چه چیزهایی هستند.

Total Crawl Requests

این عدد نشان می‌دهد Googlebot در بازه زمانی انتخاب‌شده، چند درخواست (نه چه تعداد URL یکتا) برای سایت ارسال کرده است.

نکته مهم اینجاست که منظور از Request، فقط صفحات HTML نیست.

هر فایل CSS، JavaScript، تصویر، فونت، فایل JSON یا هر منبع دیگری که Googlebot دریافت کند، یک درخواست محسوب می‌شود. حتی اگر یک URL چند بار Crawl شود یا چند مرحله Redirect داشته باشد، هر درخواست به‌صورت جداگانه در این آمار ثبت می‌شود.

به همین دلیل افزایش Crawl Requests همیشه به معنی Crawl شدن صفحات بیشتر نیست.

مثلاً اگر بعد از یک به‌روزرسانی، تمام فایل‌های CSS و JavaScript آدرس جدیدی پیدا کنند، گوگل مجبور می‌شود همه آن‌ها را دوباره دانلود کند و تعداد درخواست‌ها افزایش پیدا می‌کند؛ در حالی که تعداد صفحات سایت تغییری نکرده است.

پس هنگام بررسی این شتخص، این موارد را در نظر داشته باشید:

• انواع فایل مثل Image، HTML، CSS، JS و JSON هم در این عدد محاسبه می‌شوند.
• اگر یک URL چند بار Crawl شود، هر بار جداگانه شمرده می‌شود.
• هر مرحله از یک Redirect Chain، خودش یک Request جداگانه به حساب می‌آید.

بنابراین افزایش این عدد همیشه به معنی کشف صفحات جدید نیست؛ ممکن است فقط نشانه‌ افزایش Refresh یا Redirect باشد.

Total Download Size

این شاخص حجم کل داده‌ای را نشان می‌دهد که Googlebot در طول Crawl از سایت دانلود کرده است.

در واقع این عدد حاصل‌ضرب دو عامل است:

• تعداد درخواست‌ها (Request)
• در حجم هر پاسخ (Response)

هرچه فایل‌های HTML و منابع سایت بزرگ‌تر باشند یا تعداد درخواست‌ها افزایش پیدا کند، Download Size نیز بیشتر خواهد شد. البته تغییر URL منابع و از رده خارج شدن Cache هم روی این شاخص اثر می‌گذارد.

این را هم بگوییم که بزرگ بودن این عدد لزوماً نشانه خوب یا بدی نیست.

مثلاً اگر تصاویر حجیم، فایل‌های JavaScript بسیار بزرگ یا HTMLهای طولانی داشته باشید، حجم دانلود افزایش پیدا می‌کند و همین موضوع می‌تواند هزینه Crawl را برای گوگل بیشتر کند.

Average Response Time

شاید مهم‌ترین عدد کل گزارش همین باشد.

Average Response Time میانگین زمانی است که Googlebot برای دریافت پاسخ (Response) از سایت صرف می‌کند. دقت کنید که این مدت‌زمان از دید Googlebot اندازه‌گیری می‌شود، نه از دید کاربران یا ابزارهایی مانند PageSpeed Insights.

پس این شاخص عمدتاً برای تشخیص ظرفیت پاسخ‌گویی سایت استفاده می‌شود، نه تجربه‌ بصری کاربر.

به همین دلیل نباید Average Response Time را با معیارهایی مانند LCP، FCP یا Core Web Vitals یکی بدانید.

ممکن است صفحه اصلی سایت شما از نظر PageSpeed عملکرد بسیار خوبی داشته باشد، اما Googlebot هنگام Crawl فایل‌های API، صفحات 404 یا منابع دیگر با پاسخ‌های کند مواجه شود. در این حالت Response Time گزارش Crawl Stats افزایش پیدا می‌کند، حتی اگر امتیاز PageSpeed تغییری نکرده باشد.

بخش‌های تکمیلی گزارش Crawl Stats

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

Host Status

در بخش پایین گزارش، بخشی به نام Hosts یا Host Status وجود دارد که معمولاً کمتر به آن توجه می‌شود؛ در حالی که یکی از مهم‌ترین قسمت‌های گزارش همین بخش است.

این بخش وضعیت کلی دسترسی Googlebot به سایت را بررسی می‌کند و سه مورد اصلی را زیر نظر دارد:

• وضعیت سلامت DNS
• اتصال به سرور
• دسترسی به فایل robots.txt

اگر هرکدام از این بخش‌ها دچار اختلال شوند، Googlebot ممکن است Crawl سایت را کاهش دهد یا حتی موقتاً متوقف کند.

البته سبز بودن Host Status به این معنی نیست که شرایط کاملاً ایده‌آل است.

برای مثال ممکن است DNS و اتصال سرور بدون مشکل باشند، اما به دلیل شلوغ بودن PHP-FPM، تنظیمات WAF، مشکلات Routing یا صف درخواست‌ها، زمان پاسخ‌گویی سرور (Response Time) همچنان بالا باشد.

به همین دلیل همیشه باید Host Status را در کنار Response Time، لاگ‌های سرور و وضعیت خطاها تحلیل کنید، نه جداگانه.

By Response

این بخش درخواست‌ها را بر اساس کدهای پاسخ HTTP دسته‌بندی می‌کند. مهم‌ترین وضعیت‌هایی که در این قسمت مشاهده می‌کنید عبارت‌اند از:

• 200؛ درخواست با موفقیت انجام شده است.
• 301 و 302؛ درخواست به آدرس دیگری ریدایرکت شده است.
• 304؛ فایل تغییری نکرده و نیازی به دانلود مجدد نبوده است.
• 404؛ صفحه یا فایل پیدا نشده است.
• 5XX؛ سرور هنگام پاسخ‌گویی با خطا مواجه شده است.

این گزارش معمولاً اولین جایی است که هنگام افت Crawl باید بررسی شود؛ چون افزایش ناگهانی 5XX یا 429 می‌تواند یکی از مهم‌ترین دلایل کاهش Crawl باشد.

By File Type

در این قسمت می‌توانید ببینید Googlebot چه نوع فایل‌هایی (مثلاً HTML، جاوااسکریپت، CSS، تصاویر و JSON) را بیشتر Crawl کرده است.

اگر سهم HTML کاهش پیدا کند، اما درخواست فایل‌های JavaScript یا تصاویر افزایش یابد، ممکن است ساختار سایت یا نحوه بارگذاری منابع تغییر کرده باشد.

By Purpose

در این گزارش، گوگل درخواست‌های Crawl را از نظر هدف، دسته‌بندی می‌کند. معمولاً دو دسته اصلی در این گزارش دیده می‌شود:

• Discovery: درخواست‌هایی که برای پیدا کردن URLهای جدید انجام شده‌اند.
• Refresh: درخواست‌هایی که برای بررسی دوباره صفحاتی انجام می‌شوند که قبلاً کراول شده‌اند.

اگر سهم Discovery افزایش پیدا کند، معمولاً یعنی گوگل در حال کشف صفحات جدید سایت است؛ ولی اگر بیشتر درخواست‌ها از نوع Refresh باشند، یعنی تمرکز Googlebot روی به‌روزرسانی اطلاعات صفحات قبلی است.

By Googlebot Type

در این بخش می‌توانید ببینید چه نوع Googlebotهایی بیشترین Crawl را انجام داده است. برای مثال:

• Googlebot Smartphone
• Googlebot Desktop
• Image Bot
• Resource Load

در اکثر سایت‌ها، Googlebot موبایل سهم بیشتری از Crawl را به خود اختصاص می‌دهد؛ چون ایندکس گوگل بر پایه Mobile-First Indexing انجام می‌شود.

اگر هم بخش Resource Load سهم بالایی داشته باشد، معمولاً نشان می‌دهد Googlebot زمان زیادی را صرف دریافت فایل‌های CSS، JavaScript و سایر منابع موردنیاز برای رندر صفحات کرده است.

علت افت Crawl Stats چیست؟

وقتی نمودار Crawl Stats تغییر می‌کند، همیشه لازم نیست ده‌ها گزارش مختلف را بررسی کنید.

در بسیاری از مواقع، فقط با مقایسه Response Time و Crawl Requests می‌توانیم حدس اولیه نسبتاً خوبی درباره علت افت Crawl داشته باشیم.

البته این الگوها قانون قطعی نیستند و فقط نقطه شروع تحلیل محسوب می‌شوند:

الگوی اول: Response Time ↑ + Crawl Requests ↓

اگر هم‌زمان میانگین زمان پاسخ‌گویی افزایش پیدا کرده و تعداد Crawlها کاهش یافته است، معمولاً باید سراغ بررسی ظرفیت سایت بروید.

در این حالت احتمال دارد یکی از این مشکلات وجود داشته باشد:

• کمبود منابع سرور
• اشباع Workerهای PHP
• افزایش خطاهای 5XX یا 429
• اختلال DNS یا Routing
• مشکلات CDN یا WAF

الگوی دوم: Response Time ثابت + Crawl Requests ↓

اگر سرعت پاسخ‌دهی تقریباً ثابت مانده، اما Crawl کاهش پیدا کرده است، احتمالاً مشکل از ظرفیت سرور نیست.

در این شرایط معمولاً باید این موارد را بررسی کنید:

• کاهش Crawl Demand
• کاهش انتشار محتوای جدید
• افزایش صفحات تکراری
• URLهای کم‌ارزش
• مشکلات URL Inventory

الگوی سوم: Response Time ↓ + Crawl Requests ↑

این الگو معمولاً خبر خوبی است.

اگر بعد از بهینه‌سازی سایت، Response Time کاهش پیدا کند و هم‌زمان تعداد Crawlها افزایش یابد، احتمالاً Googlebot دوباره ظرفیت بیشتری برای Crawl سایت در نظر گرفته است.

البته این اتفاق معمولاً تدریجی رخ می‌دهد و نباید انتظار داشت بلافاصله بعد از هر تغییر، نمودار Crawl رشد کند.

آیا کاهش کراول مساوی با دی‌ایندکس شدن صفحات در گوگل است؟

یکی از رایج‌ترین برداشت‌های اشتباه بعد از دیدن افت نمودار Crawl Stats این است که: «گوگل دیگر صفحات سایت را Crawl نمی‌کند، پس احتمالاً صفحات ما را از نتایج حذف کرده است.»

اما این برداشت درست نیست.

همان‌طور که قبل‌تر هم اشاره کردیم، Crawl شدن، ایندکس شدن و رتبه گرفتن سه مرحله متفاوت از فرآیند حضور سایت در گوگل هستند. گوگل لازم نیست همه صفحات سایت را هر روز و هر روز کراول کند.

برای مثال، فرض کنید یک مقاله قدیمی و باکیفیت در سایت شما وجود دارد که:

• چند سال است تغییر نکرده؛
• کاربران همچنان از آن استفاده می‌کنند؛
• جایگاه خوبی در نتایج دارد.

در چنین شرایطی طبیعی است که Googlebot کمتر به آن صفحه سر بزنند و این به‌معنای دی‌ایندکس‌شدن آن صفحه نیست؛ اما اگر همان صفحه تغییر کند، لینک‌های جدیدی دریافت کند یا سیگنال‌های جدیدی ایجاد شود، گوگل ممکن است دوباره آن را Crawl کند.

پس افت Crawl Stats به‌تنهایی نشانه جریمه شدن سایت، حذف صفحات یا افت رتبه نیست.

چارچوب عملی برای بهبود سریع Crawl Stats

خب حالا که فهمیدیم چرا این اتفاق می‌افتد و مطمئن شدیم آمار Crawl Stats سایت واقعاً کاهش پیدا کرده، وقت آن است که سراغ حل مشکل برویم.

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

حالا می‌خواهیم تمام مراحل این پروتکل را با شما هم به اشتراک بگذاریم تا بتوانید آن را روی سایت خود اجرا کنید و در مدت کوتاهی Crawl Stats را بهبود دهید.

این پروتکل شامل ۴ مرحله است که باید به‌ترتیب طی کنید:

• اقدامات فوری برای کاهش هزینه‌های اجرای وردپرس
• حذف درخواست‌های پرهزینه و بهینه‌سازی عملکرد سایت
• بازیابی Crawl و اعلام به گوگل
• کنترل نهایی و مانیتورینگ

در ادامه، اقداماتی که در هر مرحله باید انجام دهید را توضیح می‌دهم. 

مرحله اول: اقدامات فوری برای کاهش هزینه اجرای وردپرس

اولین قدم برای بهبود Crawl Stats این است که کاری کنیم هر درخواست (Request) با سرعت بیشتری پردازش شود. هرچه سایت سبک‌تر باشد و منابع کمتری مصرف کند، Googlebot می‌تواند در مدت زمان یکسان، صفحات بیشتری را کراول و بررسی کند. 

برای رسیدن به این هدف، باید این اقدامات را انجام دهید:

۱. نسخه PHP را ارتقا دهید

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

البته قبل از ارتقا، مطمئن شوید که قالب و افزونه‌های سایت با نسخه جدید PHP سازگار هستند. بعد از انجام این تغییر هم فقط باز شدن صفحات سایت را بررسی نکنید؛ بخش‌های مهم مانند پنل مدیریت وردپرس، فرم‌ها، فروشگاه، درخواست‌های Ajax ،Cron و REST API را هم تست کنید تا مطمئن شوید همه‌چیز بدون مشکل کار می‌کند.

۲. از فعال بودن OPcache مطمئن شوید

هر بار که یک کاربر یا Googlebot وارد سایت می‌شود، PHP باید کدهای وردپرس را اجرا کند. OPcache با ذخیره نسخه کامپایل‌شده این کدها در حافظه، باعث می‌شود PHP در درخواست‌های بعدی همان کار را دوباره از ابتدا انجام ندهد. نتیجه این کار هم افزایش سرعت پاسخ‌گویی و کاهش فشار روی سرور است.

ابتدا بررسی کنید که OPcache روی هاست شما فعال باشد. اگر غیرفعال است، معمولاً می‌توانید از طریق تنظیمات PHP یا PHP Selector آن را فعال کنید.

فقط به نصب یک افزونه یا مشاهده یک گزینه در پنل هاست اکتفا نکنید. بعد از فعال‌سازی، حتماً از طریق Site Health وردپرس یا فایل phpinfo() مطمئن شوید که OPcache واقعاً در حال اجراست.

۳. از ابزارهای Scope Loader استفاده کنید

به‌صورت پیش‌فرض، وردپرس در هر درخواست، بیشتر افزونه‌های نصب‌شده را بارگذاری می‌کند؛ حتی اگر آن افزونه در آن صفحه هیچ کاربردی نداشته باشد. برای مثال، ممکن است افزونه فروشگاه در صفحه «درباره ما» هم لود شود، در حالی که اصلاً به آن نیازی نیست.

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

البته نصب Scope Loader به‌تنهایی کافی نیست. بایدافزونه‌های موردنظر باید با Headerهای Scope و Scope-Requires به‌درستی پیکربندی شوند تا مشخص باشد هرکدام در چه بخش‌هایی از سایت بارگذاری شوند.

یکی از نمونه‌های متن‌باز این ابزار، افزونه WandTech Scope Loader است که در پوشه mu-plugins نصب می‌شود.

۴. فایل robots.txt را بررسی کنید

فایل robots.txt یکی از اولین فایل‌هایی است که گوگل‌بات هنگام ورود به سایت بررسی می‌کنند. اگر این فایل به‌درستی در دسترس نباشد، ممکن است روی فرایند کراول سایت تأثیر منفی بگذارد.

برای اطمینان از عملکرد صحیح آن، این موارد را بررسی کنید:

• فایل باید با کد وضعیت HTTP 200 در دسترس باشد؛
• نباید به آدرس دیگری ریدایرکت شود؛
• نباید خطای دسترسی مانند 403 یا 404 نمایش دهد؛
• مقدار Content-Type آن باید text/plain باشد.

اگر به‌جای text/plain، مقدار text/html برگردانده می‌شود، معمولاً مشکل از تنظیمات وب‌سرور، وردپرس یا افزونه‌ای است که فایل robots.txt را ایجاد می‌کند. در این صورت، لازم است تنظیمات آن را اصلاح کنید تا ربات‌های گوگل بتوانند فایل را بدون مشکل بخوانند.

خب این از مرحله اول؛ حالا باید برویم سراغ بهینه‌سازی‌های فنی‌.

مرحله دوم: حذف درخواست‌های پرهزینه و بهینه‌سازی فنی سایت

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

پس هرچه این درخواست‌های اضافی کمتر شوند، سایت سریع‌تر پاسخ می‌دهد و Googlebot هم می‌تواند صفحات بیشتری را در زمان کمتر بررسی کند.

برای این کار، اقدامات زیر را انجام دهید:

۱. خطاهای 404 مربوط به فایل‌های استاتیک را برطرف کنید

گاهی یک صفحه هنوز به فایل‌هایی مثل تصاویر، فونت‌ها، فایل‌های CSS یا JavaScript اشاره می‌کند، اما آن فایل‌ها دیگر روی سرور وجود ندارند. در این حالت، هر بار که کاربر یا Googlebot صفحه را باز می‌کند، درخواستی برای فایل ارسال می‌شود و در نهایت با خطای 404 مواجه می‌شود.

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

برای رفع این مشکل:

• اگر فایل هنوز وجود دارد، اما آدرس آن اشتباه است، لینک یا URL آن را اصلاح کنید.
• اگر فایل حذف شده و دیگر استفاده‌ای ندارد، ارجاع آن را از HTML ،CSS یا JavaScript حذف کنید.
• اگر قرار است فایل واقعاً وجود نداشته باشد، بهتر است وب‌سرور یا CDN مستقیماً یک 404 سبک برگرداند؛ یعنی درخواست اصلاً وارد چرخه اجرای کامل وردپرس نشود. این کار باعث می‌شود سرور زمان و منابع خود را صرف درخواست‌های بی‌فایده نکند.

۲. سرعت پاسخ‌گویی سایت را بهبود دهید

در این مرحله هدف فقط سریع‌تر شدن سایت برای کاربران نیست؛ مهم‌تر از آن، این است که هزینه پردازش هر Request برای سرور کاهش پیدا کند. 

برای رسیدن به این هدف، بهتر است موارد زیر را بررسی و بهینه کنید:

• امتیاز PageSpeed Insights در نسخه موبایل و دسکتاپ را تا حد امکان به ۷۰ یا بیشتر برسانید.
• زمان پاسخ اولیه سرور (TTFB) برای صفحات مهم سایت بهتر است کمتر از ۸۰۰ میلی‌ثانیه باشد.
• حجم فایل HTML صفحات را کاهش دهید و درخواست‌های غیرضروری را حذف کنید.
• از فعال بودن Page Cache مطمئن شوید و هدرهای کش (Cache Headers) را بررسی کنید تا فایل‌هایی که نیازی به دانلود مجدد ندارند، از کش مرورگر یا CDN بارگذاری شوند.
• لاگ‌های سایت را بررسی کنید و Warningها، Fatal Errorها و خطاهای پرتکرار را برطرف کنید؛ چون این خطاها معمولاً باعث افزایش زمان پردازش هر درخواست می‌شوند.

مرحله سوم: بازیابی Crawl و اعلام تغییرات به گوگل

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

هدف‌مان این نیست که گوگل را مجبور به کراول‌کردن سایت کنیم؛ بلکه می‌خواهیم مسیر را برای ربات‌های گوگل هموارتر کنیم تا مهم‌ترین صفحات سایت را سریع‌تر دوباره بررسی کند. 

طبق پروتکل، در این مرحله باید این اقدامات را انجام دهید:

۱. یک Sitemap متمرکز بسازید

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

قبل از قرار دادن هر صفحه در این Sitemap، مطمئن شوید که:

• با کد وضعیت 200 در دسترس است.
• امکان ایندکس‌شدن (Indexable) دارد.
• تگ Canonical آن به خودش اشاره می‌کند.
• در فایل robots.txt یا تگ‌های متا، دسترسی ربات‌های گوگل به آن مسدود نشده است.

هدف‌مان از ساخت این سایت‌مپ این است که گوگل اول روی ارزشمندترین صفحات سایت تمرکز کند و بودجه خزش هدر نرود.

۲. Sitemap جدید را در سرچ کنسول ثبت کنید

بعد از ساخت Sitemap، آن را از طریق بخش Sitemaps در سرچ کنسول گوگل ثبت کنید تا Googlebot راحت‌تر آن را پیدا کند.

همچنین بهتر است آدرس این Sitemap را در انتهای فایل robots.txt نیز قرار دهید. مثل این نمونه:

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

با این کار، هر بار که Googlebot فایل robots.txt را بررسی کند، از وجود Sitemap جدید هم مطلع می‌شود.

۳. از گوگل بخواهید robots.txt را دوباره بررسی کند

اگر فایل robots.txt را تغییر داده‌اید یا Sitemap جدیدی به آن اضافه کرده‌اید، بهتر است از طریق سرچ کنسول درخواست دهید که گوگل این فایل را دوباره بررسی (Recrawl) کند.

در بعضی از حساب‌های سرچ کنسول، گزینه Request a recrawl برای فایل robots.txt در دسترس است. اگر این گزینه را مشاهده کردید، درخواست خودتان را ثبت کنید.

اما اگر این گزینه نمایش داده نمی‌شود، جای نگرانی نیست. کافی است طی چند روز آینده وضعیت فایل robots.txt و Sitemap را در سرچ کنسول زیر نظر بگیرید تا مطمئن شوید گوگل آن‌ها را دریافت و پردازش کرده است.

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

۴. برای صفحات مهم، درخواست ایندکس یا Crawl مجدد ارسال کنید

بعد از ثبت Sitemap، بهتر است چند صفحه مهم سایت را هم به‌صورت جداگانه به گوگل معرفی کنید.

برای این کار، در ابزار URL Inspection سرچ کنسول، آدرس صفحه را وارد کنید و در صورت نمایش گزینه مربوطه، درخواست Request Indexing یا Crawl مجدد را ارسال کنید.

این کار را برای صفحاتی انجام دهید که بیشترین اهمیت را برای کسب‌وکار شما دارند؛ مانند:

• صفحه اصلی
• صفحات خدمات
• صفحات محصولات مهم
• لندینگ‌پیج‌های اصلی
• مقالاتی که ترافیک بالایی دارند

مرحله چهارم: کنترل نهایی و مانیتورینگ نتایج

اینجا مرحله آخر این پروتکل است؛ بعد از اینکه تمام مراحل قبلی را انجام دادید، باید مطمئن شوید که تغییرات به‌درستی اجرا شده‌اند و واقعاً روی Crawl Stats سایت تأثیر گذاشته‌اند. چطور؟

۱. یک بررسی نهایی انجام دهید

قبل از اینکه این پروتکل را تمام‌شده بدانید، چک‌لیست زیر را یک بار دیگر بررسی کنید:

• صفحه اصلی و مهم‌ترین صفحات سایت با کد وضعیت 200 در دسترس هستند.
• فایل robots.txt و Sitemap بدون خطا قابل دسترسی هستند.
• سایت با نسخه جدید PHP بدون خطاهای جدی (Fatal Error) اجرا می‌شود.
• OPcache واقعاً فعال است و در حال استفاده است، نه اینکه فقط در تنظیمات هاست نمایش داده شود.
• اگر از Scope Loader استفاده کرده‌اید، مطمئن شوید باعث اختلال در صفحات سایت، پنل مدیریت، Ajax، REST API یا Cron نشده است.
• فایل‌های استاتیک مهم مانند تصاویر، CSS، JavaScript و فونت‌ها دیگر خطای 404 ندارند.
• زمان پاسخ‌گویی سرور (TTFB و Response Time) نسبت به قبل کاهش پیدا کرده است.

اگر همه این موارد درست باشند، احتمال اینکه تغییرات شما روی Crawl Stats اثر مثبت بگذارند بسیار بیشتر خواهد بود.

۲. نتایج را حداقل دو هفته زیر نظر بگیرید

نتایج بهبود Crawl معمولاً بلافاصله در سرچ کنسول دیده نمی‌شود، چون گزارش‌‌های سرچ کنسول گوگل با کمی تأخیر به‌روزرسانی می‌شوند. به همین دلیل، حداقل ۷ تا ۱۴ روز باید این شاخص‌ها را مانیتور کنید:

• تعداد Crawl Requestها
• Response Time
• خطاهای گزارش‌شده در سرچ کنسول
• وضعیت سلامت هاست (Host Status)

نکته مهم این است که اولین گزارش Response Time را حدود دو روز بعد از اعمال تغییرات بررسی کنید؛ چون همان‌طور که گفتیم، معمولاً داده‌های سرچ کنسول با تأخیر نمایش داده می‌شوند.

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

روزهای ۱ تا ۳

در این چند روز، با بررسی موارد زیر، مطمئن شوید سایت از نظر فنی پایدار است و خطای جدیدی ایجاد نشده:

• وضعیت Cache
• Fatal Errorها
• خطاهای 429 و 5XX
• Response Time

روزهای ۴ تا ۱۴

اگر همه‌چیز پایدار بود، حالا باید با زیر نظر گرفتن این موارد، رفتار Googlebot را آنالیز کنید:

• Discovery و Refresh صفحات
• میزان Crawl صفحات HTML
• تعداد Crawl Requestها
• Host Status

در هفته‌های بعدی هم باید با بررسی مواردی مثل وضعیت ایندکس شدن صفحات (Index Coverage)، رتبه کلمات کلیدی، ترافیک ارگانیک و پایداری عملکرد سرور، ببینید بهبود Crawl چه تأثیری روی عملکرد کلی سایت گذاشته است.

اگر در این بازه زمانی، روند Crawl Requests افزایش پیدا کند، Response Time کاهش یابد و خطاهای سرچ کنسول کمتر شوند، می‌توان نتیجه گرفت که پروتکل بازیابی Crawl با موفقیت اجرا شده است.

در این پروتکل کدام کارها را خودتان می‌توانید انجام دهید؟

اگر فقط به وردپرس یا پنل هاست (سی‌پنل یا دایرکت ادمین) دسترسی دارید، معمولاً می‌توانید این کارها را انجام دهید:

• ارتقای نسخه PHP
• فعال و بررسی کردن OPcache
• تنظیم یا بهینه‌سازی Page Cache
• حذف افزونه‌های غیرضروری
• برطرف کردن خطاهای 404 مربوط به فایل‌های استاتیک
• اصلاح ریدایرکت‌ها
• بهبود Sitemap
• تقویت لینک‌سازی داخلی
• بررسی فایل robots.txt و وضعیت ایندکس شدن صفحات مهم

اگر بعد از انجام مراحل قبلی همچنان Crawl Stats بهبود پیدا نکرد، بهتر است از تیم زیرساخت یا مدیر سرور بخواهید این موارد را بررسی کنند:

• اشباع شدن Workerهای PHP-FPM
• Slow Queryهای پایگاه داده
• مصرف بیش از حد منابع سرور و I/O Wait
• مسدود شدن Googlebot توسط WAF یا فایروال
• خطاهای 5XX و 429
• مشکلات DNS یا Routing، به‌ویژه برای کاربران خارج از کشور
• عملکرد CDN و ارتباط بین CDN و سرور اصلی (Edge-to-Origin)
• نحوه پاسخ‌دهی وب‌سرور به فایل‌های استاتیک 404

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

افت Crawl بعد از قطعی اینترنت، فوری جبران نمی‌شود!

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

اما نباید انتظار داشت با رفع یک مشکل، نمودار Crawl بلافاصله به حالت قبل برگردد.

همان‌طور که گفتیم، Googlebot رفتار خود را براساس داده‌های جدید دوباره تنظیم می‌کند و این فرآیند ممکن است زمان‌بر باشد.

مهم این است که ابتدا علت اصلی را پیدا کنید:

• اگر مشکل Capacity است، زیرساخت را اصلاح کنید.
• اگر مشکل Demand است، روی ارزش و تازگی محتوا کار کنید.
• اگر مشکل Inventory است، URLهای اضافی را مدیریت کنید.
• اگر مشکل Resources است، هزینه Crawl را کاهش دهید.

اگر به راهنمایی بیشتری درباره این موضوع نیاز دارید، مي‌توانید از قسمت نظرات با ما در ارتباط باشید و اگر این مقاله برایتان مفید بود، آن را برای کسانی که فکر می‌کنید با مشکل افت Crawl Stats دست‌وپنجه نرم می‌کنند بفرستید.

سوالات متداول

آیا افت Crawl Stats به معنای حذف سایت از نتایج گوگل است؟ 

نه لزوماً. Crawl، Index و Rank سه مفهوم جدا هستند. افت در گزارش Crawl Stats یعنی Googlebot درخواست کمتری فرستاده؛ این می‌تواند طبیعی باشد (مثلاً چون محتوای سایت به‌روزرسانی کمتری داشته) یا نشانه یک مشکل فنی باشد که باید جداگانه بررسی شود.

بعد از رفع مشکل، چند روز طول می‌کشد تا Crawl به حالت عادی برگردد؟

معمولاً بازیابی تدریجی است. توصیه می‌شود روزهای اول تا سوم روی Cache Status، خطاهای Fatal و کدهای ۴۲۹/۵XX تمرکز کنید، روزهای چهارم تا چهاردهم روند Crawl Requests و Host Status را ببینید، و برای اثر روی رتبه و ترافیک ارگانیک، چند هفته صبر کنید.

آیا درخواست مکرر Request Indexing باعث Crawl سریع‌تر می‌شود؟

ارسال چندباره یک URL الزاماً Crawl آن را سریع‌تر نمی‌کند. این ابزار برای اعلام تغییر به گوگل است، نه یک دکمه فوری‌سازی.

چه فرقی بین Response Time در Crawl Stats و امتیاز PageSpeed Insights است؟

Crawl Stats از دید Googlebot و روی تعداد زیادی Resource مختلف است؛ PageSpeed روی تجربه Load یک URL مشخص تمرکز دارد. این دو عدد را نباید معیار یکسانی در نظر گرفت.