جلوگیری از افت رتبه سایت در زمان قطعی اینترنت بین‌الملل (راهنمای عملی سئو تکنیکال)

قطعی یا اختلال اینترنت بین‌الملل معمولاً با یک نگرانی شروع می‌شود: «نکنه رتبه‌هامون بریزه؟» اما مسئله واقعی اغلب یک پله پایه‌ای‌تر است؛ اینکه آیا Googlebot اصلاً می‌تواند سایت را قابل‌اتکا ببیند، HTML را دریافت کند، منابع حیاتی را لود کند و سیگنال سلامت سرور را بگیرد یا نه.

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

چرا قطعی اینترنت به سئو ضربه می‌زند؟ (واقعیت پشت پرده)

سئو در عمل روی سه ستون می‌ایستد:

• دسترسی‌پذیری: Crawl و Fetch پایدار

• قابل‌فهم بودن: Render/Parse درست (خصوصاً برای سایت‌های JS-heavy)

• اعتمادپذیری: ثبات پاسخ‌ها و کاهش خطاهای تکرارشونده

در اختلال بین‌المللی، ستون اول و دوم مستقیم ضربه می‌خورند (Timeout، DNS fail، منابع لود نمی‌شوند) و ستون سوم هم با تکرار خطاهای 5xx5xx و کندی، آسیب می‌بیند. نکته مهم این است که موتور جست‌وجو مثل کاربر واقعی «بی‌نهایت تلاش» نمی‌کند؛ وقتی دریافت محتوا پرهزینه یا نامطمئن شود، سیستم خزیدن به‌صورت سیستماتیک نرخ Crawl را پایین می‌آورد و اولویت URLها را تغییر می‌دهد.

چرا این مشکل برای سرورهای داخل ایران شدیدتر است؟

وقتی Origin داخل ایران است، مسیر دسترسی گوگل (که عمدتاً از دیتاسنترهای خارج درخواست می‌زند) ممکن است با موارد زیر بدتر شود:

• تعداد Hop بیشتر و نوسان مسیر

• افزایش RTT و ناپایداری TLS/Handshake

• نوسان در DNS resolution

• محدودیت یا قطع مسیرهای بین‌المللی به‌صورت مقطعی

نتیجه‌اش این است که ممکن است کاربران داخلی سایت را «کاملاً سالم» ببینند، اما Googlebot از بیرون با Timeout یا 502/503/504502/503/504 مواجه شود.

«سئو را Pause می‌کنیم» چرا ایده خطرناکی است؟

سئو دکمه توقف ندارد. وقتی دسترسی خزنده قطع شود، این اتفاق‌ها می‌افتد:

• کاهش سیگنال تازه‌سازی محتوا

• کاهش کشف صفحات جدید

• بالا رفتن ریسک خروج تدریجی URLها از چرخه Crawl و حتی ایندکس

• افت اعتماد زیرساختی (به‌خصوص اگر خطاها تکرار شوند)

پس هدف اصلی در بحران اینترنتی این نیست که «تولید محتوا را زیاد کنیم»؛ هدف این است که کاری کنیم گوگل همچنان بتواند سایت را به شکل پایدار ببیند.

رفتار Crawl Budget در زمان اختلال (به زبان ساده)

Crawl Budget ترکیبی از دو بخش است:

• Crawl Capacity Limit: سقفی که گوگل بر اساس توان پاسخگویی سرور تعیین می‌کند

• Crawl Demand: میزان تمایل گوگل به خزیدن (اهمیت، تازگی، محبوبیت)

در اختلال، معمولاً اول Capacity از نگاه گوگل سقوط می‌کند چون:

• Average Response Time بالا می‌رود

• خطاهای 5xx5xx زیاد می‌شود

• Timeout یا connection reset اتفاق می‌افتد

• رندر ناقص می‌شود چون JS/CSS حیاتی لود نمی‌شود

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

هدف بقای سئو در بحران: چه چیزهایی باید همیشه در دسترس باشند؟

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

• HTML صفحات حیاتی (Home، Category، Pillar، Product/Service)

• فایل robots.txtrobots.txt

• sitemapهای اصلی

• CSS/JS حیاتی (یا نسخه HTML-first که بدون JS هم مفهوم بدهد)

• پاسخ‌های درست برای Canonical و Redirectها

یعنی باید «محتوای حیاتی» را تا حد ممکن از وابستگی کامل به اتصال بین‌المللی Origin جدا کنی.

زیرساخت پیشنهادی برای تاب‌آوری سئو (اجرایی و قابل پیاده‌سازی)

1) Reverse Proxy / Edge به‌عنوان سپر سئو

Reverse proxy (مثل Cloudflare یا هر لایه Edge مشابه) فقط ابزار سرعت نیست؛ ابزار حفظ دسترسی HTML در زمان اختلال است. مشکل خیلی از سایت‌ها این است که CDN فقط تصاویر و استاتیک‌ها را کش می‌کند، اما HTML همچنان از Origin می‌آید؛ و وقتی Origin از بیرون ناپایدار شود، گوگل HTML را از دست می‌دهد.

کارهایی که باید انجام دهی:

• کش کردن HTML برای صفحات حیاتی با TTL منطقی

• فعال کردن serve-stale یا stale-if-error (اگر سرویس پشتیبانی کند)

• تعریف Rule برای اینکه در 5xx5xx یا timeout، نسخه کش‌شده سرو شود

2) Static HTML Fallback برای صفحات حیاتی

یکی از بهترین الگوها در بحران: وقتی Origin Down شد، Edge یک نسخه استاتیک از صفحات مهم را نشان دهد.

مزیت‌ها:

• گوگل همچنان HTML قابل فهم می‌گیرد

• لینک‌های داخلی و ساختار سایت حفظ می‌شود

• سیگنال «سایت زنده است» باقی می‌ماند

روش اجرا می‌تواند ساده باشد: روزانه یا هر چند ساعت، Snapshot از صفحات کلیدی بگیری (SSG یا Pre-render)، روی Storage/Edge نگه داری، و Rule بزنی که اگر Origin خطا داد، fallback فعال شود.

3) Hybrid Hosting یا Origin ثانویه خارج از کشور (Failover واقعی)

اگر کسب‌وکار به ورودی ارگانیک وابسته است، داشتن Origin ثانویه بین‌المللی واقعاً ارزش دارد. دو مدل رایج:

• Origin اصلی ایران + Origin ثانویه خارج (برای زمان بحران)

• Split Hosting: HTML/SSR در لایه پایدارتر، API/DB داخل ایران

نکته مهم: ثانویه را «برای SEO» طراحی کن، نه لزوماً برای کل تراکنش‌ها. یعنی ممکن است بخش‌های تراکنشی را محدود کنی، اما صفحات ورودی ارگانیک (لندینگ‌ها، مقالات، دسته‌ها) را کامل سرو کنی.

4) DNS Failover واقعی (نه نمایشی)

Failover واقعی یعنی:

• Health check از چند نقطه جغرافیایی (خارج هم حتماً)

• TTL کنترل‌شده (مثلاً 6060 تا 300300 ثانیه)

• جلوگیری از Split-brain (دو مبدا همزمان نسخه‌های متفاوت ندهند)

تنظیمات Technical SEO که در بحران نجاتت می‌دهند

1) کد وضعیت درست: 503503 برای اختلال موقت + Retry-After

اگر موقتاً سرویس مختل است، بهترین سیگنال به گوگل:

• وضعیت 503503

• هدر Retry−AfterRetry−After (مثلاً 36003600 ثانیه)

• صفحه خطای سبک و استاتیک (نه یک صفحه JS سنگین)

این کار به گوگل می‌گوید «مشکل موقت است، بعداً دوباره تلاش کن» و از تولید سیگنال‌های اشتباه جلوگیری می‌کند.

2) از Soft 404 دوری کن (خیلی جدی)

Soft 404 یعنی صفحه عملاً خالی/خطا است اما با 200200 برمی‌گردد. در بحران این اتفاق زیاد می‌افتد چون بعضی فریم‌ورک‌ها خطا را با 200200 رندر می‌کنند.

چرا بد است؟

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

• Crawl Budget را می‌سوزاند

• روند بازیابی را کند می‌کند

3) robots.txt و noindex را دستکاری نکن

دو اشتباه رایج در بحران:

• بستن robots.txt برای کاهش فشار

• گذاشتن noindex سراسری

این‌ها معمولاً اثر معکوس دارند و برگشت از آن‌ها زمان‌بر است. اگر مشکل دسترسی داری، راه‌حل باید زیرساختی باشد، نه «بستن درِ سایت به روی گوگل».

4) Canonical و URL را ثابت نگه دار

در دوره ناپایداری، ثبات سیگنال حیاتی است:

• canonical باید ثابت بماند

• ساختار URL را تغییر نده

• ریدایرکت‌های عمومی و کور (مثل همه چیز به صفحه اصلی) نزن

مانیتورینگ و لاگ: سریع‌ترین راه تشخیص ضربه به سئو

Search Console مفید است اما با تأخیر. لاگ سرور همان لحظه نشان می‌دهد چه خبر است.

چه چیزهایی را در لاگ پایش کن؟

• افت ناگهانی درخواست‌های Googlebot

• افزایش 5xx5xx و timeout برای خزنده‌ها

• بالا رفتن TTFB برای درخواست‌های خزنده

• وضعیت دریافت robots.txtrobots.txt و sitemap (باید همیشه 200200 باشند)

• افزایش 499/504499/504 (در Nginx معمولاً نشانه قطع ارتباط/timeout است)

Crawl Stats در GSC را چطور بخوانیم؟

در گزارش Crawl Stats به این‌ها دقت کن:

• Average response time

• تعداد درخواست‌های روزانه

• افزایش خطاهای سرور یا DNS

اگر Average response time بالا رفت و تعداد crawl افت کرد، معمولاً گوگل ظرفیت خزیدن را کم کرده است.

وقتی Crawl کم می‌شود، لینک‌سازی داخلی تعیین‌کننده می‌شود

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

کارهای عملی:

• Pillarها و صفحات درآمدزا را در 22 تا 33 کلیک از Home نگه دار

• لینک‌های کلیدی را HTML-first قرار بده (نه پشت تب/اکاردئون وابسته به JS)

• Breadcrumb و ساختار دسته‌بندی را ساده و قابل خزیدن کن

• صفحات کم‌ارزش را از مسیرهای اصلی دور کن (نه اینکه در بحران noindex اضافه کنی)

چه کارهایی را در زمان بحران انجام ندهیم؟

• مهاجرت عجولانه همزمان با اختلال (هاست/دامنه/CMS/URL)

• فعال کردن WAF ruleهایی که Googlebot را challenge می‌کند

• ریدایرکت دسته‌جمعی همه URLها به صفحه اصلی

• تغییرات انبوه canonical، hreflang یا ساختار URL

این‌ها ریسک خطا را چند برابر می‌کنند، آن هم زمانی که توان «تشخیص دقیق اثر تغییرات» پایین آمده است.

بعد از وصل شدن اینترنت: چطور سریع‌تر ریکاوری کنیم؟

• Crawl Stats را چک کن: آیا زمان پاسخ و تعداد crawl به حالت عادی برگشته؟

• خطاهای Coverage را با اولویت robots/DNS/5xx5xx/404404 رفع کن

• sitemapها را با lastmodlastmod واقعی به‌روزرسانی کن

• لینک داخلی به صفحات حیاتی را تقویت کن تا Demand برگردد

• برای 2020 تا 200200 URL حیاتی از Request Indexing استفاده کن (نه برای کل سایت)

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

چک‌لیست سریع (برای مدیر سئو و تیم فنی)

• مانیتورینگ چندمنطقه‌ای خارج از ایران داری

• لاگ Googlebot را جداگانه پایش می‌کنی و برای افت درخواست‌ها آلارم داری

• Edge/CDN می‌تواند HTML صفحات حیاتی را سرو کند

• برای 5xx/timeout5xx/timeout، fallback استاتیک یا serve-stale داری

• در اختلال موقت 503503 + Retry−AfterRetry−After می‌دهی

• Soft 404 نزدیک صفر است

• robots/noindex را در بحران دستکاری نمی‌کنی

• canonical و URL ثابت هستند