يظهر الموقع لمستخدم يتحدث الإنجليزية من الولايات المتحدة صفحة واحدة، بينما يرى Googlebot، الذي يتواجد فعليًا في مركز بيانات في ماونتن فيو، صفحة مختلفة تمامًا. من الناحية الرسمية، يعتبر هذا تلاعبًا، حتى لو كنت ترغب فقط في تكييف المحتوى حسب المنطقة. نستعرض 6 أخطاء نموذجية في إعادة التوجيه الجغرافي، والتي تؤدي إلى فقدان المواقع لمراكزها، والحصول على عقوبات يدوية، وحظر نطاقات كاملة في الشبكات الشريكة.
ما هو إعادة التوجيه الجغرافي ولماذا يحتاجه الأعمال
إعادة التوجيه الجغرافي هو آلية تقوم تلقائيًا بإعادة توجيه المستخدم إلى نسخة من الموقع تتناسب مع بلده: لغة مختلفة، عملة، أسعار، عروض. تستخدم المتاجر الإلكترونية هذه الآلية لضمان وصول المشتري من ألمانيا مباشرة إلى النسخة الألمانية بأسعار باليورو، بدلاً من تصفح الكتالوج بالدولار. يستخدم الوسطاء إعادة التوجيه الجغرافي في مجموعات لإظهار عروض مختلفة بناءً على حركة المرور الجغرافية - على سبيل المثال، للمستخدمين من دول Tier-1 صفحة هبوط واحدة، وللآخرين - صفحة بديلة أو منتج آخر.
المشكلة تكمن في أن نفس المنطق الذي يحدد بلد المستخدم حسب IP ينطبق أيضًا على Googlebot. وعناوين IP للروبوتات من Google توجد فعليًا في الولايات المتحدة، بغض النظر عما إذا كانوا يقومون بفهرسة الصفحة للنتائج الروسية أو الكازاخستانية أو الألمانية. إذا لم يميز نظام إعادة التوجيه الجغرافي بين الزاحف والإنسان الحقيقي، فإن النتيجة واحدة - ترى Google صفحة مختلفة عن تلك التي يراها الزوار الحقيقيون. هذا هو التعريف الرسمي للتلاعب وفقًا لتوصيات Google Search Central، والعقوبة عليه تتراوح من انخفاض في الترتيب إلى استبعاد كامل للنطاق من الفهرس.
لماذا يرى Googlebot والإنسان صفحات مختلفة
يحدث التباين لثلاثة أسباب في نفس الوقت، وعادة ما تتداخل هذه الأسباب مع بعضها البعض. أولاً، يقوم Googlebot بفهرسة الموقع من عناوين IP المملوكة لـ Google، وتحدد خدمات الجغرافيا (MaxMind، IP2Location وما شابه) هذه العناوين على أنها أمريكية تقريبًا في 100% من الحالات. ثانيًا، يرسل Googlebot User-Agent خاص به، والذي غالبًا ما تتم معالجته في فرع كود منفصل - أحيانًا عن عمد، حتى لا يتعطل الفهرسة، وأحيانًا ببساطة بسبب خطأ من المطور. ثالثًا، يختلف سلوك Googlebot عند تنفيذ JavaScript عن سلوك المتصفح: قد لا يقوم الزاحف بتنفيذ إعادة التوجيه المرتبطة بـ JavaScript العميل، وبالتالي يقوم بفهرسة نسخة مختلفة تمامًا من الصفحة التي يراها الشخص مع تشغيل JavaScript.
أضف إلى ذلك التخزين المؤقت من CDN، الذي قد "يعلق" على نسخة لدولة واحدة ويقدمها للجميع، وستحصل على حالة حتى بدون نية سيئة من مالك الموقع، يقوم محرك البحث بفهرسة محتوى لا يتوافق مع ما تراه الجمهور. أدناه - ستة سيناريوهات محددة تحدث فيها هذه المشكلة بشكل متكرر.
الخطأ 1: إعادة التوجيه حسب IP دون التحقق من User-Agent للروبوت
الخطأ الأكثر شيوعًا هو أن منطق إعادة التوجيه يعتمد فقط على تحديد البلد حسب IP، دون أي تحقق من هوية الشخص الذي يقوم بالطلب: إنسان أو زاحف. نتيجة لذلك، يدخل Googlebot، الذي يأتي من نطاق IP أمريكي، تلقائيًا إلى النسخة الأمريكية من الموقع، حتى لو كانت الصفحة قد تم الترويج لها في الأصل للطلبات من روسيا أو كازاخستان. بعد عدة أسابيع من الفحص، يجد فهرس Google نفسه محشورًا بـ "النسخة غير الصحيحة"، وتبدأ المراكز في المناطق المستهدفة في الانخفاض دون سبب واضح.
الحل هو دائمًا استبعاد User-Agent وعناوين IP المعروفة للروبوتات (Googlebot، Bingbot، YandexBot) من إعادة التوجيه الجغرافي، مع تقديم النسخة الكانونية من الصفحة بغض النظر عن البلد المحدد. يعتبر التحقق من User-Agent حاجزًا ضروريًا ولكنه غير كافٍ، لأنه سهل التزوير، لذلك تتحقق المشاريع الكبيرة أيضًا من IP عبر استعلام DNS العكسي (reverse DNS lookup)، كما توصي الوثائق الخاصة بـ Google للتحقق من Googlebot.
الخطأ 2: الاختبار باستخدام IP من مراكز البيانات بدلاً من المستخدمين الحقيقيين
يحدث الخطأ الثاني بالفعل في مرحلة الاختبار. يقوم المطور أو المسوق باختبار إعادة التوجيه الجغرافي من خلال بروكسي عادي من مركز البيانات أو VPN، ويعمل المنطق كما لو كان مستخدمًا حقيقيًا من البلد المطلوب. لكن عناوين IP من مراكز البيانات يمكن تمييزها بسهولة عن حركة المرور المنزلية - العديد من شبكات CDN وأنظمة مكافحة الاحتيال تضع علامة عليها بعلم منفصل، وقد يتصرف جزء من منطق الاستهداف الجغرافي بشكل مختلف تمامًا لهذه العناوين مقارنةً بعناوين IP المنزلية العادية.
في النهاية، ينجح الاختبار، وتعمل إعادة التوجيه على خادم التطوير بشكل مثالي، بينما يحصل المستخدمون الحقيقيون من البلد المستهدف على نسخة غير صحيحة، لأن قاعدة بيانات تحديد المواقع الخاصة بالمزود أو قاعدة بيانات CDN تفسر IP الخاص بهم بشكل مختلف عن عنوان IP من مركز البيانات التجريبي. للتحقق الصحيح، من الأفضل استخدام بروكسيات سكنية - لأنها تحتوي على IP من مزودي الخدمة المنزلية الحقيقيين في البلد المطلوب، وتحددها خدمات الجغرافيا بنفس الطريقة التي تحدد بها المستخدم الحقيقي. هذا يوفر صورة دقيقة لما سيراه الزائر الحقيقي للموقع، وليس نسخة مبسطة لـ "IP مركز البيانات النموذجي".
الخطأ 3: التخزين المؤقت وغياب رؤوس Vary
إذا كان الموقع يعمل من خلال CDN (Cloudflare، Fastly، Akamai) وتم تنفيذ إعادة التوجيه الجغرافي على مستوى خادم الأصل، وليس على مستوى CDN نفسه، فمن السهل الوقوع في موقف يقوم فيه CDN بتخزين النسخة الأولى المقدمة من الصفحة ويقوم بتوزيعها على الجميع - بغض النظر عن بلد الزائر التالي. يحدث هذا عندما لا يتم تحديد رأس Vary: Accept-Language الصحيح في استجابة الخادم أو مفتاح تخزين مؤقت مشابه بناءً على المعايير الجغرافية.
في هذه الحالة، قد يجد Googlebot "النسخة الصحيحة" في الزيارة الأولى، ويقوم بتخزينها في أنظمة الفهرسة الخاصة به، ثم يحصل على نفس النسخة في الزيارات المتكررة لأسابيع، حتى لو تم تغيير المحتوى للدول الأخرى منذ فترة طويلة. في هذه الأثناء، يرى المستخدمون النسخة الحالية، ولكنها مختلفة - يتزايد عدم التزامن تدريجيًا، ومن الصعب تشخيصه دون مقارنة مباشرة لاستجابات الخادم لدول مختلفة من خلال أدوات مثل curl مع استبدال الرؤوس أو من خلال بروكسي مع تحديد الموقع الجغرافي المطلوب.
الخطأ 4: إعادة التوجيه بواسطة JS، التي يفسرها الروبوت بشكل مختلف
يمكن لـ Googlebot تنفيذ JavaScript، لكنه يفعل ذلك مع تأخير كبير (قد تستغرق الموجة الثانية من الرندر أيامًا) وليس دائمًا بشكل مطابق لمتصفح المستخدم. إذا تم تنفيذ إعادة التوجيه الجغرافي من خلال JavaScript العميل - على سبيل المثال، عبر window.location بعد طلب fetch إلى geo-API - هناك خطر أن يقوم الزاحف بفهرسة الصفحة قبل تنفيذ إعادة التوجيه، أي "النسخة غير الصحيحة" للمنطقة المحددة.
هذا أمر حاسم بشكل خاص للصفحات ذات الصفحة الواحدة (SPA)، حيث يتم الاحتفاظ بكل منطق التخصيص على جانب العميل. النهج الصحيح هو تنفيذ تحديد الموقع الجغرافي وإعادة التوجيه على جانب الخادم (وظيفة edge لـ CDN، middleware على Node.js، قاعدة في Nginx)، بحيث يحصل Googlebot والمستخدم على إعادة توجيه HTTP 302 قبل أن تبدأ الصفحة في الرندر في المتصفح. هذا يزيل الاعتماد على كيفية معالجة الزاحف لـ JS في لحظة معينة.
الخطأ 5: عنوان URL واحد دون hreflang لنسخ لغوية مختلفة
الخطأ الخامس هو محاولة تقديم عدة نسخ لغوية على نفس عنوان URL دون ترميز hreflang. توصي Google بشكل مباشر: إذا كان المحتوى على عنوان URL واحد يختلف حسب موقع المستخدم، يجب إما تقديم عناوين URL مختلفة لكل نسخة (نطاقات فرعية، مجلدات فرعية أو نطاقات منفصلة) مع ترميز hreflang متقاطع، أو عرض نفس النسخة بصدق للجميع، بما في ذلك الروبوتات، مع إضافة إمكانية التبديل اليدوي للغة.
بدون hreflang، لا يمكن لـ Google فهم أن /product باللغة الروسية و/product باللغة الإنجليزية هما محتوى مختلف عمدًا لجماهير مختلفة، وليس محاولة لإخفاء نسخة واحدة عن الفهرسة لصالح الأخرى. النتيجة هي أن نسخة عشوائية تدخل الفهرس (عادةً تلك التي كانت متاحة للروبوت عند آخر فحص)، وهي التي تبدأ في الترتيب في جميع المناطق في نفس الوقت، مما يؤثر سلبًا على ملاءمة النتائج والتحويل.
الخطأ 6: عدم وجود fallback للمستخدمين الذين يستخدمون VPN والبروكسيات المحمولة
الخطأ السادس يتعلق أكثر بـ Googlebot، ولكنه يتعلق بالمستخدمين الحقيقيين - لكنه مرتبط مباشرة بموضوع إعادة التوجيه الجغرافي، لأن محاولة "إصلاح" السلوك للروبوتات غالبًا ما تكسرها للمستخدمين الحقيقيين الذين يستخدمون VPN أو الإنترنت المحمول. غالبًا ما يتصل مستخدمو شركات الاتصالات بشبكة الإنترنت عبر CGNAT (Carrier-Grade NAT)، حيث يستخدم عشرات الآلاف من المشتركين نفس IP الخارجي، وقد تحدد قاعدة البيانات الجغرافية هذا IP على أنه ينتمي إلى دولة مجاورة أو حتى بشكل خاطئ.
إذا لم يكن هناك مفتاح يدوي لتبديل البلد/اللغة كـ fallback على الموقع، فإن المستخدم الذي لديه IP "غير صحيح" يعلق على نسخة غير ذات صلة دون إمكانية تغييرها - ويغادر ببساطة. لاختبار مثل هذا السيناريو، من الأفضل التحقق من سلوك الموقع من خلال بروكسيات محمولة، التي تحاكي IP من مزودي خدمة الهاتف المحمول مع سلوك تحديد الموقع الجغرافي النموذجي لـ CGNAT - يساعد ذلك على رؤية المشكلة مسبقًا، قبل أن يكتشفها المستخدمون الحقيقيون ويكتبوا إلى الدعم.
كيفية التحقق من إعادة التوجيه الجغرافي من منظور Google من دول مختلفة
الأداة الرئيسية للتشخيص الأولي هي وظيفة "عرض كما Googlebot" في Google Search Console (أداة فحص URL)، التي تظهر HTML التي يحصل عليها الزاحف من Google فعليًا. إذا كانت النسخة المعروضة ليست تلك التي تراها في المتصفح من بلدك، فإن المشكلة مؤكدة. لكن Search Console دائمًا ما يقوم بالفحص من عناوين IP أمريكية، لذا فإن مقارنة سلوك الموقع حسب المناطق تحتاج إلى طبقة اختبار منفصلة.
في الممارسة العملية، يقوم المسوقون والمتخصصون في SEO بإنشاء عدة ملفات تعريف في متصفح مضاد للكشف - Dolphin Anty، AdsPower، Multilogin أو GoLogin - ويربطون كل ملف تعريف ببروكسي من البلد المطلوب، للمرور يدويًا عبر مسار المستخدم: فتح الموقع، رؤية أي نسخة تم تحميلها، أي رأس Accept-Language تم إرساله، ما إذا كانت إعادة التوجيه قد تمت وما هو عنوان URL. للبروكسيات السكنية المناسبة مع اختيار دقيق للمدينة أو المزود - فهي تعطي أفضل محاكاة للزائر الحقيقي، على عكس عناوين مراكز البيانات، التي قد تضعها بعض الخدمات كاشتباه قبل تقييم الجغرافيا.
| نوع البروكسي | لأي نوع من الفحص يناسب | خطر الحصول على نتيجة خاطئة |
|---|---|---|
| بروكسيات سكنية | محاكاة مستخدم منزلي عادي في البلد/المدينة المطلوبة | منخفض |
| بروكسيات محمولة | التحقق من السلوك عند CGNAT وتحديد الموقع الجغرافي المحمول | منخفض |
| بروكسيات مراكز البيانات | التحقق السريع من حدوث إعادة التوجيه حسب البلد | مرتفع: بعض قواعد البيانات الجغرافية تصنف IP بشكل مختلف عن المنزلية |
للتحقق من سلوك منطق الخادم (وليس الرندر المرئي) من المفيد أيضًا النظر إلى الاستجابة الخام من الخادم عبر curl مع استبدال User-Agent بـ Googlebot ورأس X-Forwarded-For بـ IP البلد المطلوب - سيظهر ذلك حالة HTTP والموقع الذي يقدمه الخادم قبل أي رندر JS، ويسمح بالتقاط الخطأ 4 والخطأ 1 من القائمة أعلاه في أمر واحد فقط.
قائمة التحقق لإعدادات إعادة التوجيه الجغرافي بأمان
- تم استبعاد Googlebot وBingbot وYandexBot من منطق إعادة التوجيه الجغرافي حسب User-Agent وتم تأكيدهم عبر DNS العكسي
- تم تنفيذ إعادة التوجيه على جانب الخادم (302/307)، وليس فقط من خلال JavaScript العميل
- تم إعداد رأس
Varyللتخزين المؤقت الصحيح من CDN حسب الجغرافيا/اللغة - لكل نسخة لغوية عنوان URL منفصل مع ترميز hreflang متقاطع
- يوجد مفتاح يدوي مرئي لتبديل البلد/اللغة كـ fallback لـ IP المحدد بشكل خاطئ
- يتم إجراء الاختبارات من خلال بروكسيات سكنية ومحمولة من البلدان المطلوبة، وليس فقط من خلال عناوين مراكز البيانات
- يتم التحقق من Google Search Console مرة كل ثلاثة أشهر - النسخة تتطابق مع ما يراه المستخدمون الحقيقيون
الخاتمة
التباين بين ما يراه Googlebot وما يراه المستخدم نادرًا ما يكون خداعًا متعمدًا لمحرك البحث - غالبًا ما يكون نتيجة تراكم الديون الفنية: إعادة التوجيه حسب IP دون التحقق من الروبوت، التخزين المؤقت بدون رأس Vary، إعادة التوجيه بواسطة JS التي لا يتمكن الزاحف من تنفيذها، وغياب hreflang لنسخ لغوية. يبدو أن كل من هذه الأخطاء بمفردها تافهة، ولكن معًا تشكل صورة كلاسيكية للتلاعب في عيون Google - مع العقوبات المناسبة.
الطريقة الوحيدة الموثوقة للتأكد من أن الموقع يتصرف بصدق متساوي لكل من الروبوتات والبشر هي التحقق منه بانتظام باستخدام IP حقيقية من البلدان المطلوبة. نوصي باستخدام بروكسيات سكنية لمحاكاة مستخدم منزلي نموذجي وبروكسيات محمولة للتحقق من السيناريوهات مع CGNAT - هذا يوفر صورة دقيقة للغاية لما تراه جمهورك في كل منطقة، ويساعد على اكتشاف المشكلة قبل أن يجدها خوارزمية Google.