سئوCDNDNSامنیت

دسترسی گوگل‌بات به سایت ایرانی: چرا رتبه گوگل افت می‌کند؟

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

nsin8 دقیقه مطالعه

یک سایت می‌تواند از داخل ایران کاملاً سالم باشد — کاربران صفحه‌ها را بدون مکث باز می‌کنند و لاگ سرور چیز نگران‌کننده‌ای ندارد — و در همان لحظه برای خزنده گوگل عملاً وجود نداشته باشد. نتیجه چند هفته بعد در Search Console ظاهر می‌شود: خطای خزش، کاهش نرخ خزش و بعد حذف تدریجی صفحه‌ها از ایندکس. این مقاله درباره همان شکاف بین «سایت من که بالاست» و «گوگل می‌گوید در دسترس نیست» است.

چرا سایتِ سالم برای کاربر ایرانی، برای گوگل در دسترس نیست

Googlebot سایت شما را از داخل ایران نمی‌خزد؛ گوگل رسماً اعلام کرده خزش عمدتاً از دیتاسنترهای این شرکت در آمریکا انجام می‌شود. یعنی مسیر خزنده هیچ ربطی به مسیر کاربر ایرانی شما ندارد و نقاط شکست خودش را دارد:

  • ناپایداری ترانزیت بین‌الملل — مسیرهای ورودی به ایران در بازه‌های اختلال از بیرون قابل اتکا نیستند، حتی وقتی ترافیک داخلی برقرار است.
  • فایروال هاست که رنج خارجی را می‌بندد — بستن IP غیرایرانی روی سرور، عادتی رایج برای کاهش حمله است؛ همان قانون Googlebot را هم می‌بندد.
  • DNS که فقط از داخل جواب می‌دهد — اگر nameserverهای دامنه از بیرون کند باشند، خزش پیش از رسیدن به وب‌سرور شکست می‌خورد. نقش هر رکورد را در راهنمای رکوردهای DNS باز کرده‌ایم.
  • قانون امنیتی بیش از حد سخت‌گیر — یک rate limit عمومی یا قانون WAF که User-Agent ناشناس را رد می‌کند، به خزنده HTTP 403 می‌دهد.
  • گواهی SSL منقضی یا زنجیره ناقص — خزنده گوگل TLS ناسالم را خطای خزش ثبت می‌کند.

تست از داخل ایران هیچ چیزی را ثابت نمی‌کند

مهم‌ترین اشتباه تشخیصی همین است: باز شدن سایت در مرورگر خودتان چیزی درباره دسترس‌پذیری آن برای گوگل ثابت نمی‌کند. دو مسیر متفاوت را آزمایش می‌کنید.

گوگل وقتی نمی‌تواند بخزد، دقیقاً چه می‌کند

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

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

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

تفاوت حیاتی 5xx و 404

این تمایز، مرز بین «چند هفته افت» و «حذف کامل» است:

  • خطای 5xx و به‌ویژه 503 یعنی «الان نه، بعداً بیا». گوگل عقب می‌کشد، دوباره تلاش می‌کند و صفحه را فعلاً در ایندکس نگه می‌دارد. برای نگهداری برنامه‌ریزی‌شده، 503 با هدر Retry-After پاسخ درست است.
  • خطای 404 یا 410 یعنی «این صفحه وجود ندارد» و گوگل خیلی سریع‌تر آن را از ایندکس بیرون می‌کشد. برگرداندن 404 برای یک قطعی موقت، خودزنی است.
  • صفحه خطا با کد HTTP 200 بدترین حالت است. بعضی مبدأها هنگام قطعی دیتابیس صفحه «خطایی رخ داد» را با کد 200 برمی‌گردانند؛ گوگل این را soft 404 می‌بیند و متن خطا را محتوای صفحه ثبت می‌کند.
  • پاسخ 5xx روی robots.txt کل سایت را درگیر می‌کند: وقتی گوگل نتواند robots.txt را بخواند، خزش کل سایت را موقتاً متوقف می‌کند، نه فقط یک صفحه را.

تشخیص: سه ابزاری که واقعاً جواب می‌دهند

۱. بخش Crawl Stats در Search Console

در Settings → Crawl stats سه شاخص Host status را ببینید: واکشی robots.txt، وضعیت DNS resolution و server connectivity. اگر هرکدام هشدار دارد، مشکل زیرساختی است نه محتوایی. بعد نمودار By response را باز کنید و دنبال این الگو بگردید: رشد پاسخ‌های 5xx یا Failed هم‌زمان با افت کل درخواست‌های خزش — امضای دقیقِ «گوگل عقب کشیده».

۲. ابزار URL Inspection و تست زنده

آدرس را در URL Inspection وارد کنید و حتماً Test live URL را بزنید؛ گزارش ایندکس وضعیت گذشته است، اما تست زنده همین الان از زیرساخت گوگل درخواست می‌زند. اگر تست زنده شکست بخورد ولی صفحه در مرورگر شما باز شود، جواب را گرفته‌اید: مشکل مسیر است، نه کد.

۳. بررسی دسترس‌پذیری از بیرون ایران

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

curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://example.com/robots.txt
dig +trace example.com A

HTTP و DNS را جدا و از چند منطقه تست کنید. هرگز whitelist امنیتی را روی User-Agent نسازید؛ Googlebot واقعی فقط با reverse DNS به googlebot.com و سپس forward lookup تأیید می‌شود. سریع‌ترین راه دیدن واقعیت هم لاگ زنده درخواست‌ها در پنل nsin است: می‌بینید درخواست خزنده به لبه رسیده یا نه.

جدول تشخیص: علامت، علت، راه‌حل

علامتعلت محتملراه‌حل
DNS resolution هشدار داردnameserver از بیرون کند است یا پاسخ نمی‌دهدانتقال زون به DNS ابری
server connectivity ناموفق، ولی سایت از ایران باز استفایروال هاست رنج خارجی را بسته یا ترانزیت مختل استلبه بین‌المللی جلوی مبدأ؛ فایروال فقط برای IP لبه
جهش ناگهانی 5xx در Crawl Statsمبدأ در دسترس نیست یا timeout می‌دهدسرو نسخه کش‌شده هنگام قطعی؛ failover چند مبدأ
افت تدریجی درخواست‌های خزشگوگل نرخ خزش را کم کردهرفع ریشه خطا؛ بازگشت خزش زمان‌بر است
صفحه‌ها با «Not found (404)» ناپدید شده‌اندمبدأ برای خطای موقت 404 برگرداندههرگز 404 برای قطعی؛ 503 با Retry-After
Googlebot پاسخ 403 می‌گیردقانون WAF یا rate limit خزنده را بلاک می‌کندسقف نرخ مسیرهای پرخزش را با path rule شل کنید و پیش از هر بلاک، خزنده را با reverse DNS تأیید کنید
خطای TLS در تست زندهگواهی منقضی یا زنجیره ناقصSSL با تمدید خودکار از لبه

چرا صفحه کش‌شده قدیمی از خطای تازه بهتر است

فرض کنید مبدأ شما بیست دقیقه در دسترس نیست. خزنده یا صفحه‌ای با محتوای بیست دقیقه پیش و کد HTTP 200 می‌گیرد، یا یک خطای 503 کاملاً دقیق. از نگاه گوگل این دو قابل مقایسه نیستند: صفحه کمی قدیمی خزش موفق ثبت می‌کند، ایندکس را دست‌نخورده نگه می‌دارد و سیگنالی برای کاهش خزش نمی‌فرستد.

برای یک قطعی کوتاه، صفحه کمی قدیمیِ کش‌شده با کد 200 خزش موفق ثبت می‌کند و سیگنال کاهش نرخ خزش نمی‌فرستد؛ و اگر نسخه کش‌شده‌ای در کار نیست، پاسخ درست 503 همراه Retry-After است — نه 404 و نه صفحه خطا با کد 200.

این کاری است که یک لبه با کش درست انجام می‌دهد. سازوکار TTL و اینکه چه چیزی کش می‌شود را در کش لبه چطور کار می‌کند توضیح داده‌ایم؛ نکته کلیدی اینجا فعال بودن سرو نسخه کش‌شده هنگام در دسترس نبودن مبدأ است.

لبه دوطرفه چه چیزی را حل می‌کند

تفاوت یک CDN معمولی با لبه‌ای که برای شرایط ایران طراحی شده در جهت اتصال است: مسئله فقط رساندن محتوا به کاربر خارجی نیست، بلکه باز نگه‌داشتن مسیر بین مبدأ ایرانی و بیرون است — در هر دو جهت. این قابلیت‌ها در nsin همین را هدف می‌گیرند:

  • سرو محتوای کش‌شده وقتی مبدأ پاسخ نمی‌دهد، تا خزنده به‌جای خطا صفحه بگیرد.
  • failover چند مبدأ، برای وقتی یک مسیر یا سرور از کار می‌افتد.
  • SSL رایگان با تمدید خودکار روی لبه، تا انقضای گواهی به خطای خزش تبدیل نشود.
  • DNS ابری، تا اولین گام خزش خودش نقطه شکست نباشد.
  • موتور قوانین با path rule و rate limit، که به‌جای بلاک کور سیاست دقیق اعمال می‌کند؛ WAF و محافظت در برابر DDoS نقطه شروع تنظیم آن است.

جزئیات فنی، از هدرهای کش تا override کردن host header، در مستندات آمده و چرا CDN رتبه سئو را بهبود می‌دهد همین بحث را از زاویه Core Web Vitals می‌بیند.

پرسش‌های متداول

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

سریع‌ترین راه، دکمه Test live URL در ابزار URL Inspection است؛ نتیجه Page fetch: Successful یعنی در همان لحظه دسترسی برقرار بوده. برای دید بلندمدت هم Host status در Crawl stats را چک کنید.

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

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

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

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

آیا CDN باعث می‌شود گوگل نسخه کش‌شده را ایندکس کند؟

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

قدم بعدی

اگر در Crawl Stats رشد 5xx یا افت درخواست‌های خزش می‌بینید، منتظر بازگشت خودبه‌خودی نمانید؛ گوگل تا مطمئن نشود سایت پایدار است برنمی‌گردد. دامنه را در پنل nsin اضافه کنید، کش صفحه‌ها و سرو نسخه کش‌شده هنگام قطعی را فعال کنید و یک هفته نمودار خزش را زیر نظر بگیرید. هر دامنه جدید یک دوره آزمایشی هفت‌روزه کامل Enterprise دارد؛ برای دیدن اینکه گوگل چه چیزی از سایت شما می‌گیرد، همین کافی است.