لماذا يُعد التوجيه التلقائي للغة قاتلًا لـSEO: حالة Googlebot وAccept-Language (بأدلة من موقعنا)
التوجيه التلقائي بحسب IP ولغة المتصفح يُري Googlebot نسخة واحدة من موقعك. الآلية، وإجراء اختبار في 15 دقيقة، والنمط الصحيح للإعداد.
بقلم Roozbeh Nazari · CEO
على الورق تبدو الفكرة مضيافة: افتح الموقع بالتركية للزائر من إسطنبول وبالعربية للقادم من دبي. هذا الإعداد — تخمين اللغة من لغة المتصفح أو من IP ثم التوجيه تلقائيًا — من أكثر أخطاء المواقع متعددة اللغات كلفة، لأن ما يُفعل باسم تجربة المستخدم يمنع محرك البحث من رؤية معظم الموقع. في هذه المقالة نفكك الآلية خطوة خطوة ونترك لك أوامر تختبر بها كل ادعاء على موقعك في خمس عشرة دقيقة؛ لست مضطرًا لتصديق أحد — خذ الدليل من خادمك أنت.
أولًا، حقيقتان موثّقتان. الأولى: لا يرسل Googlebot ترويسة Accept-Language مع طلباته — أي أن منطق "وجّه بحسب لغة المتصفح" يُسقط البوت دائمًا في الفرع الافتراضي. الثانية: يزحف Googlebot في الغالب من عناوين IP أميركية. اجمعهما: الموقع الذي يوجّه بحسب IP واللغة يُري Googlebot النسخة الواحدة نفسها في كل زيارة تقريبًا — الإنجليزية عادة، أو ما كان الافتراضي. ولهذا بالذات يوصي دليل Google للمواقع متعددة المناطق صراحة بتجنب التوجيه التلقائي المبني على اللغة المفترضة، وإبقاء كل النسخ متاحة للمستخدمين والزواحف. بعبارة أخرى: هذا ليس اختلاف تفسير، بل إعداد يخالف دليل المصنّع مباشرة.
الضرر لا يبقى محصورًا بل يتسلسل. نسخ اللغات التي لا يمكن زحفها لا تُفهرس أو تسقط من الفهرس. وسوم hreflang تبدأ بالإشارة إلى بدائل متعذرة؛ وGoogle لا يستخدم ربطًا لا يستطيع التحقق منه، فتُعرض حتى النسخ الباقية في الأسواق الخطأ. المستخدم الذي ينقر عنوانًا عربيًا في النتائج يُقذف إلى لغة أخرى لحظة وصوله؛ وهذا الانقطاع بين ما بحث عنه وما وجده يضر بالتحويل وبإشارات السلوك معًا. ثم طبقة البنية التحتية: إذا خزّن CDN رد 301 فإن التوجيه الخاطئ يُقدّم مجمدًا لكل المستخدمين؛ ويُحبس مستخدمو VPN والمسافرون في السوق الخطأ. ولأن التحويلات الدائمة تُخزّن في المتصفحات أيضًا، يظل الضحايا القدامى يصلون إلى العنوان الخطأ مدة حتى بعد إصلاح الخلل.
والآن إجراء الاختبار. الاختبار الأول من سطر الأوامر: اطلب رابطًا لغويًا عميقًا بوكيل مستخدم Googlebot وانظر رمز الحالة — مثلًا اسحب صفحة خدمة تحت /ar/ بـ curl -sI -A "Googlebot". الجواب المتوقع 200؛ فإن رأيت 301 أو 302 فوصول البوت إلى تلك الصفحة يُقطع بتحويلة. الأمر الثاني يقيس أثر ترويسة اللغة: اطلب الرابط نفسه مرة مع Accept-Language: ar ومرة بلا ترويسة إطلاقًا؛ وانظر خصوصًا إلى أين يذهب الرابط الجذر في الطلب بلا ترويسة، لأن ذلك هو الفرع الذي يراه Googlebot. تنبيه: بعض الإعدادات مكتوبة لتعامل عناوين البوت الموثقة فقط معاملة مختلفة، لذا حتى لو خرجت اختبارات سطر الأوامر نظيفة لا تتخطّ الاختبارين التاليين. واجعل حفظ مخرجات الأوامر عادة؛ فعند تكرار الاختبارات نفسها بعد الإصلاح سيكون لديك سجل قبل وبعد قابل للمقارنة.
الاختبار الثاني في Search Console: أعط URL Inspection رابطًا عميقًا عربيًا أو إنجليزيًا وشغّل اختبارًا حيًا. إن رأيت أن الصفحة تعذر جلبها أو أنها غير قابلة للفهرسة بسبب تحويلة، فقد انتهى التخمين ووُضع التشخيص. الاختبار الثالث في سجلات الخادم: اعزل طلبات Googlebot الموثقة (تنشر Google نطاقات IP الرسمية لبوتاتها، ويتحقق منها reverse DNS أيضًا) وانظر نسبة ردود 30x التي تتلقاها. إذا كانت حصة معتبرة من طلبات البوت إلى نسخ اللغات تنتهي بتحويلات، فقد وجدت مصدر مشكلة الفهرسة. نشغّل هذا الإجراء الثلاثي قياسيًا في إعداداتنا نحن أيضًا؛ ويجب إعادة التحقق من النتيجة في كل موقع تتغير فيه طبقة middleware أو CDN، لأن تحديث إطار عمل بريء المظهر قد يجلب سلوك توجيه بصمت.
ثمة حل وسط يُقترح كثيرًا: "لنستثنِ Googlebot من التوجيه." لا ننصح به لسببين. الأول الهشاشة: الاستثناءات المبنية على قوائم وكلاء المستخدم وIP تتعطل مع تغير بنية البوتات، ولا تلاحظ العطل عادة إلا بعد هبوط الزيارات. الثاني مبدئي: معاملة المستخدم بطريقة والبوت بأخرى سير على حافة cloaking؛ ونصيحة Google العامة ألا يُخص Googlebot بمعاملة. المشكلة تُحل بتغيير السلوك من جذره، لا بالالتفاف حول البوت.
النمط الصحيح هو الاقتراح بدل التوجيه. تبقى كل روابط اللغات متاحة بحرية للجميع. يرى الزائر لأول مرة شريطًا صغيرًا قابلًا للإغلاق بحسب لغته المخمّنة: "هذه الصفحة متاحة بالعربية أيضًا." إن اختار المستخدم، تُحفظ رغبته في cookie وتُطبق في الزيارات اللاحقة على الرابط الجذر فقط؛ ولا تُمس الروابط العميقة تلقائيًا بأي حال. وفي جانب hreflang يشير x-default إلى صفحة اختيار اللغة أو إلى النسخة التي تخدم الجمهور الأوسع. وفي الحالات الاستثنائية التي تفرض فيها القوانين فرق محتوى بحسب البلد، تُستخدم تحويلات غير دائمة وترويسات Vary صحيحة ونطاق ضيق — وهذه مسألة منفصلة عن توجيه اللغة العام. وعند تصميم الشريط تذكّر تحذيرات Google من العناصر البينية المزعجة: طبقة لغة بملء الشاشة تغطي المحتوى تضع مكان المشكلة التي حللتها مشكلة جديدة؛ يكفي شريط صغير قابل للإغلاق لا يعيق القراءة.
إن كان التوجيه التلقائي قائمًا بالفعل، فخطة التراجع يجب أن تكون منضبطة كالاختبارات. الترتيب: أزل قاعدة التوجيه أولًا وفعّل نمط الشريط؛ ثم امسح ردود التوجيه المخزّنة في طبقة CDN والحافة، وإلا ظل السلوك حيًا مدة حتى بعد تغير الكود. بعدها أعد إرسال خرائط مواقع كل اللغات إلى Search Console، واطلب إعادة زحف الصفحات الحرجة عبر URL Inspection. تابع التعافي أسبوعيًا في تقارير فهرسة الصفحات — واضبط التوقعات: نسخة لغوية لم تُزحف طويلًا تحتاج أسابيع لا أيامًا لتجد مكانها السليم في الفهرس مجددًا.
الخلاصة لصانعي القرار: التوجيه التلقائي للغة صفقة تخفي أسواق لغات كاملة عن محرك البحث مقابل توفير نصف ثانية للمستخدم — والطرف الخاسر فيها أنت دائمًا. والتراجع عنها ليس رخيصًا: تنظيف التحويلات المخزّنة وتعافي الفهرس يأخذان وقتًا. في مشاريع الإعداد متعدد اللغات والهجرة، هذا القرار من أول بنود قائمة التدقيق في خدمة SEO التقني لدى SEO Evaluate؛ وننصح بتكرار الاختبارات الثلاثة أعلاه على موقعك كل ربع سنة، وفحص سلوك الرابط الجذر بعد كل نشر كبير. روتين اختبار من خمس عشرة دقيقة هو تأمين ضد خسارة فهرسة تمتد أشهرًا. واترك لفريقك قاعدة من جملة واحدة: لا ينبغي لأي مستخدم أن ينقر نتيجة بحث ثم يستفيق في صفحة بلغة غير التي بحث بها. إن كسرت ميزة جديدة أو اختبار A/B أو طبقة تخصيص هذه القاعدة، فليس أمامك مفاضلة تُناقش بل خطأ يُتراجع عنه؛ والنقاش الوحيد هو كيف تفعل ذلك مع بقاء القاعدة سليمة.