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

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

اول تفکیک کنیم: خزش، رندر، ایندکس

سه اتفاقِ جدا هستند و هر کدام جای دیگری خراب می‌شود:

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

افتِ رتبه بعد از قطعیِ شبکه، تقریباً همیشه از لایهٔ اول یا دوم می‌آید.

روش ۱: آزمونِ زندهٔ سرچ کنسول

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

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

روش ۲: گزارشِ آمارِ خزش

در تنظیماتِ سرچ کنسول، بخشِ آمارِ خزش نمودارِ درخواست‌ها و وضعیتِ میزبان را نشان می‌دهد. الگوهایی که باید نگرانتان کند:

روش ۳: لاگِ سرور — معتبرترین منبع

لاگ دروغ نمی‌گوید. روی سرورِ لینوکسی ببینید خزنده در ۲۴ ساعتِ گذشته آمده یا نه:

# آخرین بازدیدهای خزنده
grep -i "googlebot" /var/log/nginx/access.log | tail -30

# شمارشِ کدهای پاسخی که به خزنده داده‌ایم
grep -i "googlebot" /var/log/nginx/access.log 
  | awk '{print $9}' | sort | uniq -c | sort -rn

اگر در خروجیِ دوم تعدادِ زیادی 403 یا 429 دیدید، سرورِ خودتان خزنده را رد می‌کند. عددِ 503 در بازهٔ قطعی طبیعی است؛ اگر بعد از پایانِ قطعی هم ادامه دارد، تنظیماتِ حالتِ تعمیر را فراموش کرده‌اید.

مراقبِ خزندهٔ جعلی باشید

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

host 66.249.66.1
# باید به دامنه‌ای متعلق به گوگل برگردد، سپس:
host crawl-66-249-66-1.googlebot.com

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

روش ۴: بررسی از بیرونِ ایران

سایتِ شما ممکن است از داخل باز شود و از بیرون نه. یک سرورِ ارزانِ خارجی یا هر ابزارِ بررسیِ چندنقطه‌ای، این را در چند ثانیه روشن می‌کند:

curl -I -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" 
     https://example.com/

پاسخِ 200 یعنی مسیر باز است. اگر پاسخی نگرفتید یا 403 برگشت، به سراغِ فهرستِ زیر بروید.

هفت مسدودکنندهٔ رایج، به ترتیبِ احتمال

1. محدودسازیِ جغرافیایی: شایع‌ترین دلیل. بسیاری از پنل‌های میزبانیِ داخلی گزینه‌ای دارند که ترافیکِ غیرایرانی را می‌بندد. با فعال بودنِ آن، گوگل هم بسته می‌شود.
2. سرویسِ امنیتیِ شرکتِ میزبان: قواعدِ ضدربات، خزنده را با ربادِ مخرب اشتباه می‌گیرد.
3. محدودیتِ نرخِ درخواست: خزنده در بازه‌های کوتاه درخواست‌های زیادی می‌فرستد و قاعدهٔ سخت‌گیرانه آن را می‌بندد.
4. خطای robots.txt: یک خطِ Disallow: / جامانده از دورهٔ توسعه.
5. ماندنِ برچسبِ noindex: از زمانِ بالا آوردنِ سایت.
6. حالتِ تعمیر با کدِ نادرست: صفحهٔ تعمیر با کدِ 200 برمی‌گردد، پس گوگل آن را محتوای واقعیِ صفحه می‌داند.
7. گواهیِ منقضی‌شده: خزنده هم مثلِ مرورگر به سایتِ با گواهیِ نامعتبر بی‌اعتماد می‌شود.

دو فایلی که باید کنترل کنید

robots.txt

این فایل خزش را کنترل می‌کند، نه ایندکس را. یک نکتهٔ مهم که خیلی‌ها اشتباه می‌کنند: اگر نشانی‌ای را در robots.txt ببندید، خزنده نمی‌تواند برچسبِ noindexِ داخلِ آن صفحه را ببیند و ممکن است نشانی را بی‌محتوا در نتایج نگه دارد. برای حذفِ صفحه از نتایج، راهِ درست noindex است و باید مسیر برای خزنده باز بماند.

فایل را مستقیم بخوانید و مطمئن شوید خطِ جامانده‌ای از دورهٔ توسعه ندارد:

curl -s https://example.com/robots.txt

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

نقشهٔ سایت

نقشهٔ سایت به گوگل نمی‌گوید چه چیزی را ایندکس کند، اما کشفِ صفحه‌های جدید و بازدیدِ دوبارهٔ صفحه‌های تغییریافته را سریع‌تر می‌کند. سه چیز را رعایت کنید: فقط نشانی‌های با کدِ 200 در آن باشند، تاریخِ تغییر واقعی باشد نه تاریخِ امروزِ همهٔ صفحات، و نشانیِ نقشه در robots.txt اعلام شده باشد.

پس از رفعِ مشکل چه کنیم؟

باز کردنِ مسیر، پایانِ کار نیست. بازیابیِ خزش تدریجی است و می‌توانید تسریعش کنید:

1. در ابزارِ بررسیِ نشانی، برای پنج تا ده صفحهٔ مهم درخواستِ ایندکس بفرستید. صفِ درخواستِ دستی محدود است، پس آن را برای صفحه‌های پردرآمد خرج کنید نه همه.
2. تاریخِ تغییرِ نقشهٔ سایت را به‌روز کنید و نقشه را دوباره ثبت کنید.
3. یک هفته آمارِ خزش را روزانه ببینید؛ بازگشتِ نمودار به سطحِ قبل نشانهٔ حلِ واقعیِ مشکل است.
4. اگر افتِ رتبه دیده‌اید، انتظار داشته باشید بازگشتش چند هفته طول بکشد. تغییرِ عجولانهٔ محتوا در این بازه، تشخیصِ علت را سخت‌تر می‌کند.

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

در قطعیِ واقعی چه کنیم تا ایندکس نپرد؟

این پرسش در شرایطِ قطعی اینترنت بین‌الملل بیشتر از همیشه مطرح می‌شود. گوگل با قطعیِ کوتاه‌مدت مدارا می‌کند، به شرطی که سیگنالِ درست بگیرد:

• کدِ 503 همراه با هدرِ Retry-After برگردانید. صفحه در ایندکس می‌ماند.
• هرگز به‌جای محتوا صفحهٔ خطا با کدِ 200 نفرستید.
• نشانی‌ها را در قطعی به صفحهٔ اصلی هدایت نکنید؛ این کار به ایندکس آسیبِ ماندگار می‌زند.
• بعد از بازگشت، در سرچ کنسول درخواستِ بازبینی برای چند صفحهٔ مهم بفرستید.
• نقشهٔ سایت را با تاریخِ تغییرِ به‌روز نگه دارید تا خزنده بداند کجا را دوباره ببیند.

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