في أحد مشاريعي الخاصة بـ SEO كان Yandex قد فهرس 12,500 صفحة. لو نظرت إلى هذا الرقم وحده لبدت حالة الموقع جيدة. لكن الزيارات الحقيقية من روسيا كانت شبه معدومة.
كنت أبني هذا المشروع الكبير في SEO أيضًا لكي أطور مهاراتي كمطوّر frontend.
كان رد فعلي الأول أن أبحث عن مشكلة SEO. بعد التتبع وجدت مشكلة أبسط وأعمق: مسار الشبكة. كان الموقع خلف Cloudflare ولم يكن الوصول إليه من روسيا موثوقًا. وبما أنني كنت أعيش خارج روسيا، فقد كانت المشكلة شبه غير مرئية من بيئة عملي.
أجبرني هذا الحادث على فصل ثلاثة مؤشرات يسهل التعامل معها كأنها شيء واحد: الفهرسة، وقابلية الوصول، والترافيك. هذه أشياء مختلفة. قد تبقى الصفحة في الفهرس بينما لا يستطيع مستخدمون حقيقيون على شبكات معينة تحميلها.
ما الذي أستطيع تأكيده فعلًا؟
الحقائق التي عشتها مباشرة بسيطة. كنت أشغل مشروع SEO كبيرًا خلف Cloudflare. كان Yandex قد فهرس 12,500 صفحة، لكن الزيارات من روسيا كانت شبه صفر. تحققت من المشكلة وحصرتها في طبقة الشبكة. بعد ذلك عطلت بروكسي Cloudflare بالكامل، وأعددت Nginx على خادم VDS الخاص بي ليتولى ما كنت لا أزال أحتاج إليه: التخزين المؤقت، والضغط، والحماية الأساسية.
بعد هذا التغيير عاد الوصول من روسيا فورًا. هذه أقوى نتيجة أستطيع الدفاع عنها في هذا المثال: تغيير مسار التوصيل أعاد قابلية الوصول.
ومن المهم بالقدر نفسه توضيح ما لا يثبته هذا المثال. لا يمكنني منه تحديد عدد الزيارات المفقودة بدقة، أو جميع الشبكات الروسية المتأثرة، أو مقدار تعافي الزيارات العضوية لاحقًا. ما رصدته كان مشكلة وصول وترافيكًا شبه معدوم، وليس تجربة SEO مضبوطة.
الأدلة العامة أدق من تفسيري الأول
في البداية وصفت ما حدث كما لو أن Roskomnadzor حجب نطاقات IP محددة تابعة لـ Cloudflare. هذه صياغة أكثر تحديدًا مما تسمح به الأدلة التي أستطيع دعمها.
في 26 يونيو 2025 نشرت Cloudflare تقريرها، وقالت إن المستخدمين في روسيا الذين يصلون إلى خدمات محمية بـ Cloudflare يتعرضون منذ 9 يونيو 2025 لعملية throttling من مزودي الإنترنت الروس. ووفق تحليل Cloudflare الداخلي، كان بعض الاتصالات المتأثرة يسمح بتحميل أول 16 KB فقط من مورد الويب، وهو ما يكفي لتعطيل التصفح الطبيعي في كثير من الصفحات. التفاصيل في تقرير Cloudflare عن قيود الاتصال في روسيا.
هذا الوصف يتوافق مع نوع العطل الذي رأيته، لكنه لا يثبت آلية التنفيذ الدقيقة لدى كل مزود إنترنت، ولا يتيح لي أن أنسب كامل انخفاض الترافيك مباشرة إلى Roskomnadzor. الصياغة الأدق هي: مسار توصيل موقعي عبر بروكسي Cloudflare لم يكن يعمل من روسيا بصورة موثوقة، وتجاوز هذا البروكسي أعاد الوصول في حالتي.
لماذا لم تعنِ 12,500 صفحة مفهرسة أن الموقع سليم
هذا هو الفرق المفاهيمي الذي قللت من أهميته. رأيت 12,500 صفحة في الفهرس وتعاملت مع ذلك كإشارة عامة إلى قابلية الوصول. لكن crawl محرك البحث واتصال المستخدم النهائي نظامان مختلفان.
قد يكون محرك البحث قد زحف إلى URL سابقًا، أو يصل إليه عبر مسار شبكة مختلف، أو يبقي الصفحة في الفهرس حتى لو لم يعد بعض المستخدمين يحصلون على الاستجابة كاملة. لذلك وجود URL في الفهرس لا يثبت أن مستخدمًا لدى ISP روسي معين يستطيع فتح الصفحة اليوم. في حالتي كان الأمران صحيحين في الوقت نفسه: 12,500 صفحة كانت في Yandex، والترافيك الحقيقي من روسيا كان شبه صفر.
الفهرسة ليست قابلية الوصول. وقابلية الوصول ليست الترافيك.
ما الذي غيرته؟
- عطلت بروكسي Cloudflare بالكامل. لم يعد HTTP/HTTPS يمر عبر Cloudflare قبل الوصول إلى بنيتي التحتية.
- نقلت الوظائف التي أحتاجها إلى Nginx. أعددت على VDS التخزين المؤقت والضغط وبعض ضوابط الحماية الأساسية بنفسي.
المغزى ليس أن Nginx «أفضل» من Cloudflare. لقد أزلت اعتمادًا شبكيًا أصبح مشكلة في سوق مهم بالنسبة لي.
عاد الوصول، لكن المسؤولية عادت أيضًا
تجاوز reverse proxy ليس ترقية بلا تكلفة. توضح وثائق Cloudflare الحالية أن DNS-only يوجه المستخدم إلى origin مباشرة ولا يمرر HTTP/HTTPS عبر بروكسي Cloudflare. وبذلك تختفي مزايا تعتمد على البروكسي، مثل التخزين المؤقت وعدة طبقات حماية، وقد يظهر عنوان IP الخاص بالـ origin. راجع وثائق Proxy status الرسمية.
يمكن لـ Nginx تغطية جزء من احتياجاتي مثل cache المحلي والضغط ومعالجة الطلبات والفلترة الأساسية. لكنه لا يعيد تلقائيًا شبكة Cloudflare العالمية أو قدرتها المُدارة على مواجهة DDoS أو كل وظائف الأمان. لذلك كانت الهجرة مقايضة: تحكم مباشر أكبر في مسار التوصيل مقابل مسؤولية تشغيلية أكبر.
في هذا المشروع كانت المقايضة منطقية لأن الوصول من روسيا كان المشكلة الفورية. لكن ذلك لا يجعل VDS + Nginx البنية الأكثر أمانًا في كل الحالات.
كيف سأشخّص مشكلة مشابهة الآن؟
إذا انهار الترافيك في بلد أو منطقة شبكة بعينها، فلن أبدأ بإعادة كتابة العناوين أو المحتوى. سأفصل الطبقات أولًا:
- هل يمكن تحميل الصفحة من البلد المستهدف وعبر أكثر من ISP؟
- هل يستلم العميل جسم الاستجابة كاملًا وليس مجرد HTTP 200؟
- هل يتغير السلوك عند تجاوز CDN أو reverse proxy في اختبار مضبوط؟
- هل ما زال URL يُزحف إليه ويُفهرس؟
- بعد التأكد من قابلية الوصول فقط: هل تتغير impressions وclicks وsessions فعلًا؟
الخلاصة العملية هي القياس من السوق الذي يهمك. اختبار من دولة أخرى قد يثبت أن الـ origin يعمل، لكنه قد يفوّت بالكامل مشكلة اتصال إقليمية.
ما الذي خرجت به من هذا الحادث؟
بدأ الأمر كلغز SEO: 12,500 صفحة مفهرسة، لكن زيارات روسيا شبه معدومة. الإجابة المفيدة كانت في طبقة أدنى من الـ stack.
إزالة بروكسي Cloudflare وإعادة بناء ما أحتاجه في Nginx على VDS أعادا الوصول من روسيا فورًا. هذه نتيجة يمكنني الدفاع عنها. أما ما لا يمكنني الدفاع عنه فهو تحويل هذا المثال إلى دليل على تأثير مؤكد في ترتيب Google أو Yandex، أو إثبات لآلية حجب تنظيمية محددة، أو قاعدة عامة تقول إن الجميع يجب أن يترك Cloudflare.
قاعدتي بعد هذا المثال أبسط: إذا كان سوق ما مهمًا، فقِس قابلية الوصول من داخل ذلك السوق. عدد الصفحات في الفهرس لا يخبرك إن كان مستخدم حقيقي قادرًا على استلام الصفحة كاملة.