در یکی از پروژههای SEO من، یاندکس 12,500 صفحه را ایندکس کرده بود. اگر فقط به این عدد نگاه میکردم، سایت سالم به نظر میرسید. اما ترافیک واقعی از روسیه تقریباً صفر بود.
این پروژه بزرگ SEO را تا حدی هم برای تقویت مهارتهایم بهعنوان یک توسعهدهنده frontend میساختم.
اولین واکنش من این بود که دنبال مشکل SEO بگردم. بعد از بررسی، به مسئلهای بنیادیتر رسیدم: مسیر شبکه. سایت پشت Cloudflare بود و از روسیه بهصورت قابل اتکا در دسترس نبود. چون خارج از روسیه زندگی میکردم، این خرابی از محیط کاری خودم تقریباً دیده نمیشد.
این اتفاق مجبورم کرد سه سیگنال را که خیلی راحت یکی فرض میشوند از هم جدا کنم: ایندکس شدن، دسترسپذیری و ترافیک. اینها یک چیز نیستند. ممکن است صفحه در ایندکس بماند، در حالی که کاربران واقعی در بعضی شبکهها نتوانند آن را کامل بارگذاری کنند.
چه چیزی را واقعاً میتوانم تأیید کنم؟
واقعیتهای مستقیم سادهاند. من یک پروژه بزرگ SEO را پشت Cloudflare اجرا میکردم. یاندکس 12,500 صفحه را ایندکس کرده بود، اما ترافیک روسیه تقریباً وجود نداشت. بررسی کردم و مشکل را تا لایه شبکه محدود کردم. بعد پراکسی Cloudflare را کاملاً خاموش کردم و Nginx را روی VDS خودم برای کارهایی که هنوز لازم داشتم تنظیم کردم: کش، فشردهسازی و امنیت پایه.
بعد از این تغییر، دسترسی از روسیه بلافاصله برگشت. قویترین نتیجهای که از این مورد میتوانم بیان کنم همین است: تغییر مسیر تحویل، دسترسپذیری را برگرداند.
به همان اندازه مهم است که بگویم این مورد چه چیزهایی را اثبات نمیکند. از آن نمیتوانم تعداد دقیق بازدیدهای از دسترفته، همه شبکههای روسی متاثر یا میزان دقیق بازگشت ترافیک ارگانیک را نتیجه بگیرم. مشاهدات من درباره دسترسی و ترافیک تقریباً صفر بود، نه یک آزمایش کنترلشده SEO.
شواهد عمومی از توضیح اولیه من دقیقترند
در ابتدا ماجرا را اینطور توضیح میدادم که Roskomnadzor بعضی محدودههای IP مربوط به Cloudflare را مسدود کرده است. با شواهدی که میتوانم پشتیبانی کنم، این جمله بیش از حد مشخص است.
Cloudflare در 26 ژوئن 2025 گزارش خودش را منتشر کرد و گفت از 9 ژوئن 2025 کاربران در روسیه هنگام اتصال به سرویسهای محافظتشده با Cloudflare با throttling از سوی ISPهای روسی مواجه بودهاند. طبق تحلیل داخلی Cloudflare، در بعضی اتصالهای متاثر فقط 16 KB اول یک منبع وب بارگذاری میشد؛ چیزی که برای خراب کردن مرور عادی بسیاری از صفحات کافی است. جزئیات در گزارش Cloudflare درباره محدودیتهای اتصال در روسیه آمده است.
این توضیح با نوع خرابیای که من دیدم همخوان است، اما مکانیزم دقیق اجرا در هر ISP را ثابت نمیکند و اجازه نمیدهد کل افت ترافیکم را مستقیم به Roskomnadzor نسبت بدهم. بیان دقیقتر این است: مسیر تحویل سایت من از طریق پراکسی Cloudflare از روسیه قابل اتکا نبود و در مورد من، دور زدن آن پراکسی دسترسی را برگرداند.
چرا 12,500 صفحه ایندکسشده به معنی سالم بودن سایت نبود
این همان تفاوت مفهومی بود که دستکم گرفته بودم. 12,500 صفحه در ایندکس میدیدم و آن را نشانه عمومی دسترسپذیری میدانستم. اما crawl موتور جستجو و اتصال کاربر نهایی دو سیستم جدا هستند.
موتور جستجو ممکن است URL را قبلاً crawl کرده باشد، از مسیر شبکه دیگری به آن برسد، یا صفحه را در ایندکس نگه دارد در حالی که بعضی کاربران دیگر پاسخ کامل را دریافت نمیکنند. بنابراین ایندکس بودن URL ثابت نمیکند کاربر یک ISP مشخص روسی امروز میتواند صفحه را باز کند. در مورد من هر دو واقعیت همزمان وجود داشت: یاندکس 12,500 صفحه را ایندکس کرده بود و ترافیک واقعی روسیه تقریباً صفر بود.
ایندکس شدن مساوی دسترسپذیری نیست. دسترسپذیری مساوی ترافیک نیست.
چه چیزی را تغییر دادم؟
- پراکسی Cloudflare را کاملاً خاموش کردم. ترافیک HTTP/HTTPS دیگر قبل از رسیدن به زیرساخت من از Cloudflare عبور نمیکرد.
- وظایفی را که نیاز داشتم به Nginx منتقل کردم. روی VDS خودم کش، فشردهسازی و کنترلهای امنیتی پایه را تنظیم کردم.
نکته این نبود که Nginx «بهتر» از Cloudflare است. من یک وابستگی شبکهای را حذف کردم که در بازاری مهم برای من تبدیل به مشکل شده بود.
دسترسی برگشت، اما مسئولیت هم برگشت
دور زدن reverse proxy ارتقای رایگان نیست. مستندات فعلی Cloudflare توضیح میدهد که در حالت DNS-only کاربر مستقیم به origin میرود و ترافیک HTTP/HTTPS دیگر از پراکسی Cloudflare رد نمیشود. در نتیجه مزایای وابسته به پراکسی، از جمله کش و چند لایه حفاظتی، جلوی origin قرار ندارند و IP مبدا هم ممکن است آشکار شود. جزئیات در مستند رسمی Proxy status آمده است.
Nginx میتواند بخشی از نیازهای من را پوشش دهد: کش محلی، فشردهسازی، مدیریت درخواست و فیلتر ساده. اما شبکه جهانی Cloudflare، ظرفیت مدیریتشده DDoS یا همه قابلیتهای امنیتی آن را خودکار بازسازی نمیکند. بنابراین مهاجرت یک معامله بود: کنترل مستقیم بیشتر بر مسیر تحویل در برابر مسئولیت عملیاتی بیشتر.
برای این پروژه ارزش داشت، چون مشکل فوری من دسترسی از روسیه بود. اما این به معنی آن نیست که VDS + Nginx برای همه امنترین معماری است.
اگر امروز با مشکل مشابه روبهرو شوم چگونه تشخیص میدهم؟
اگر ترافیک فقط در یک کشور یا ناحیه شبکهای سقوط کند، از بازنویسی title یا content شروع نمیکنم. اول لایهها را جدا میکنم:
- آیا صفحه از کشور هدف و از بیش از یک ISP قابل دریافت است؟
- آیا client کل response body را میگیرد یا فقط HTTP 200؟
- آیا با دور زدن CDN یا reverse proxy در یک تست کنترلشده رفتار تغییر میکند؟
- آیا URL هنوز crawl و index میشود؟
- فقط بعد از تأیید دسترسی: آیا impressions، clicks و sessions واقعاً تغییر میکنند؟
درس عملی این است که از بازاری که برایتان مهم است اندازهگیری کنید. تست از کشور دیگر ممکن است نشان دهد origin زنده است، اما یک اختلال منطقهای اتصال را کاملاً از دست بدهد.
چیزی که از این اتفاق یاد گرفتم
در ابتدا شبیه یک معمای SEO بود: 12,500 صفحه ایندکس شده و تقریباً هیچ ترافیکی از روسیه. پاسخ مفید در لایه پایینتری از stack بود.
حذف پراکسی Cloudflare و بازسازی قابلیتهای لازم با Nginx روی VDS بلافاصله دسترسی از روسیه را برگرداند. این نتیجه را میتوانم با اطمینان بیان کنم. اما نمیتوانم آن را به اثبات تاثیر ranking در Google یا Yandex، اثبات مکانیزم دقیق مسدودسازی از سوی رگولاتور، یا قانون عمومی «همه باید Cloudflare را کنار بگذارند» تبدیل کنم.
قانون من بعد از این ماجرا سادهتر است: اگر بازاری مهم است، دسترسپذیری را از همان بازار اندازه بگیرید. تعداد صفحات داخل index نمیگوید آیا کاربر واقعی میتواند کل صفحه را دریافت کند یا نه.