أثار تقرير جديد حالة من القلق بين أصحاب المواقع بعد ظهور صفحات تفقد وجودها في نتائج البحث بينما تختار جوجل نطاقًا خارجيًا غير مرتبط بها باعتباره النسخة الأساسية. لكن توضيح جون مولر من جوجل يشير إلى أن ما يبدو كأنه مشكلة في canonical في جوجل قد يكون في بعض الحالات نتيجة لخطأ تقني يجعل صفحات مختلفة تعرض رسالة خطأ متطابقة أمام Googlebot، وليس بالضرورة هجومًا أو اختراقًا مباشرًا.
الإجابة السريعة
رد جون مولر على حالة ظهرت فيها صفحات موقع كأنها فقدت الفهرسة لصالح نطاق خارجي غريب. وأوضح أن السبب المحتمل قد يكون أن Googlebot زحف أثناء عطل مؤقت وشاهد رسالة خطأ أو صفحة fallback مشتركة بين مواقع مختلفة، فتعامل معها النظام كصفحات متشابهة. نصيحته الأساسية كانت استخدام فحص URL المباشر في Search Console ومراقبة الصفحات الحرجة لاكتشاف الأخطاء قبل أن تستقر في فهرس جوجل.
كيف بدأت قصة canonical في جوجل؟
بدأت الحالة بمنشور في مجتمع BigSEO على Reddit من صاحب موقع لاحظ تراجعًا تدريجيًا في فهرسة بعض صفحاته. المفاجأة كانت أن Search Console أظهر نطاقًا آخر مرتبطًا بموقع مراهنات باعتباره canonical لبعض الصفحات، رغم أن صاحب الموقع قال إنه لا توجد علاقة واضحة في المحتوى بين الجانبين.
هذا النوع من النتائج يبدو مقلقًا لأن canonical في جوجل عادةً يستخدم للإشارة إلى النسخة الأساسية من صفحات متشابهة أو مكررة. وعندما تختار جوجل نطاقًا مختلفًا بالكامل، قد يفسر صاحب الموقع ما يحدث على أنه مشكلة cross-domain canonical أو حتى محاولة اختراق.
لكن تفاصيل الحالة كشفت احتمالًا آخر يفسر بعض مشكلات canonical في جوجل. مستخدم آخر ذكر أنه واجه شيئًا مشابهًا عندما كانت صفحاته تعرض أحيانًا رسالة خطأ JavaScript عامة أثناء الأعطال، بينما كانت مواقع أخرى تعرض الرسالة نفسها. وبحسب تفسيره، ربما زحف Googlebot إلى هذه الصفحات في لحظة الخطأ، فرأى محتوى متطابقًا تقريبًا بدل المحتوى الحقيقي، ثم جمع بعض العناوين في مجموعة واحدة من الصفحات المتشابهة.
جون مولر: افحص ما يراه Googlebot فعلًا
جون مولر من جوجل وافق على أن هذا السيناريو ممكن في حالات canonical في جوجل، ونصح صاحب الموقع باستخدام اختبار URL المباشر داخل Google Search Console للتحقق من النسخة التي تصل فعليًا إلى Googlebot. هذه النقطة مهمة لأن ما يراه صاحب الموقع في المتصفح العادي ليس بالضرورة ما تلقاه محرك البحث في لحظة زحف سابقة.
إذا كان الخادم أو التطبيق يعرض للمستخدم المحتوى الصحيح حاليًا، فقد تبقى في الفهرس آثار لحالة مؤقتة حدثت سابقًا. لذلك فإن تشخيص canonical في جوجل لا يبدأ فقط بالنظر إلى وسم rel=canonical، بل يتطلب أيضًا فحص استجابة الخادم والمحتوى الذي يتم تقديمه إلى Googlebot.
مولر أوضح كذلك أن النتيجة النهائية بالنسبة للبحث قد تكون متشابهة حتى لو اختلف السبب التقني: إما أن الصفحة الأصلية تصبح canonical لكنها مفهرسة برسالة الخطأ، أو تُعامل كـ soft 404، أو تختار جوجل صفحة أخرى كنسخة أساسية. في الحالات الثلاث قد تختفي الصفحة الطبيعية من نتائج البحث لمحتواها الحقيقي.
ما هو canonical ولماذا لا تلتزم به جوجل دائمًا؟
توضح وثائق Google Search Central أن canonical هو عنوان URL الذي تختاره جوجل ليمثل مجموعة من الصفحات المتطابقة أو شديدة التشابه. ويمكن لأصحاب المواقع إرسال إشارات تفضيلية من خلال إعادة التوجيه أو rel=canonical أو خريطة الموقع، لكن جوجل تؤكد أن canonical الذي يحدده صاحب الموقع يظل إشارة وليس أمرًا إلزاميًا في كل الحالات.
وتشير الوثائق الرسمية أيضًا إلى أن جوجل تجمع الصفحات المتشابهة، وهو جوهر فهم canonical في جوجل، ثم تختار عنوانًا تعتبره الأكثر تمثيلًا. ولهذا قد تظهر مشكلة canonical في جوجل عندما تجعل أخطاء الخادم عدة صفحات مختلفة تبدو متشابهة أكثر مما ينبغي في اللحظة التي يزحف فيها Googlebot إليها.
هل يعني ظهور نطاق غريب أن الموقع تعرض للاختراق؟
ليس بالضرورة. عند ظهور مشكلة canonical في جوجل، تذكر وثائق جوجل بالفعل أن الاختراق قد يكون أحد أسباب اختيار canonical خارجي، خصوصًا إذا قام المهاجم بحقن rel=canonical يشير إلى نطاق آخر أو أضاف تحويلات 3xx غير مصرح بها. لكن هذه ليست الحالة الوحيدة الممكنة.
في السيناريو الذي ناقشه مولر، لم يظهر دليل واضح على وجود canonical خبيث داخل الصفحة. وهذا جعل فرضية رسالة الخطأ المشتركة أكثر منطقية. لذلك يجب عدم القفز مباشرة إلى استنتاج أن الموقع مخترق قبل مراجعة HTML الفعلي، رؤوس HTTP، التحويلات، وإصدار الصفحة الذي يراه Googlebot.
من هو جون مولر؟
جون مولر هو Search Advocate في جوجل ويعمل ضمن فريق Google Search Relations، الذي يربط بين فرق هندسة البحث وأصحاب المواقع والمتخصصين في تحسين محركات البحث. ويظهر اسمه باستمرار في توضيحات Google Search Central المتعلقة بالفهرسة والزحف والمشكلات التقنية التي يواجهها الناشرون.
ماذا يجب أن يفعل صاحب الموقع إذا ظهرت المشكلة؟
أفضل مسار عملي عند تشخيص canonical في جوجل هو التعامل مع المشكلة باعتبارها مشكلة فنية في العرض والزحف أولًا، ثم التحقق من إشارات canonical. ويمكن تنفيذ الخطوات التالية:
- استخدم URL Inspection في Search Console وشغّل الاختبار المباشر للصفحة.
- قارن HTML الذي يحصل عليه Googlebot بالمحتوى الذي يظهر للمستخدم العادي.
- راجع rel=canonical داخل الصفحة وفي HTTP headers.
- تحقق من عدم وجود تحويلات 3xx غير متوقعة.
- افحص سجلات الخادم بحثًا عن أخطاء 500 أو صفحات fallback مؤقتة.
- تأكد من أن صفحات الخطأ ترجع status code مناسبًا بدل 200 OK.
- راقب أهم الصفحات دوريًا حتى تكتشف الأعطال قبل أن يزحف إليها جوجل.
وتوضح جوجل في دليل حل مشكلات canonical أن فحص URL هو أول خطوة لمعرفة canonical الذي اختارته جوجل، ثم يجب البحث عن أخطاء تقنية أو محتوى يجعل الصفحات تبدو متطابقة. وتذكر الوثائق كذلك أن إعادة التقييم بعد إصلاح المشكلة قد تستغرق وقتًا، وقد تبقى الصفحات ضمن مجموعة التكرار لمدة تصل إلى نحو أسبوعين في بعض الحالات.
مراقبة الموقع قد تكون أهم من تعديل canonical نفسه
النقطة الأهم في رد مولر هي أنه لم يركز على تعديل وسم canonical بقدر ما ركز على منع الموقع من تقديم صفحة خطأ مستقرة لمحركات البحث. وأشار إلى أن الاختبارات الآلية أو أنظمة المراقبة التي تزور الصفحات الحرجة بانتظام يمكن أن تكشف هذه المشكلات مبكرًا.
إذا كان الموقع يعرض خطأ عامًا مع كود 200، فقد يتعامل محرك البحث مع هذا الخطأ باعتباره محتوى حقيقيًا. وعندما تعرض عدة مواقع الخطأ نفسه، يصبح التشابه بينها أكبر من المتوقع، وهو ما قد يفسر بعض الحالات الغريبة المرتبطة باختيار canonical في جوجل.
هذا مهم خصوصًا للمواقع المبنية على تطبيقات JavaScript أو خدمات تعتمد على أكثر من طبقة بين الخادم والمستخدم، لأن تعطل إحدى الطبقات قد ينتج صفحة fallback موحدة بدل خطأ HTTP واضح.
متى يكون cross-domain canonical حقيقيًا؟
إذا كانت الصفحة نفسها تحتوي بالفعل على rel=canonical، فإن حالة canonical في جوجل تحتاج إلى فحص مصدر هذه الإشارة، خصوصًا إذا كانت تشير إلى نطاق خارجي. وقد يكون ذلك مقصودًا في بعض عمليات نقل المحتوى أو ناتجًا عن خطأ في CMS أو إضافة SEO، أو في حالات أسوأ عن اختراق.
أما إذا لم توجد أي إشارة من هذا النوع، فإن مجرد ظهور نطاق خارجي داخل اختيار جوجل لا يثبت وحده وجود cross-domain canonical متعمد. ولهذا يجب فصل السبب التقني الحقيقي عن التفسير الذي يبدو واضحًا من الخارج.
صلة المشكلة بمستقبل SEO التقني
هذه الحالة تذكر أصحاب المواقع بأن مشكلات الفهرسة لا تأتي دائمًا من المحتوى أو الروابط أو خوارزميات الترتيب. أحيانًا يكون السبب صفحة خطأ ظهرت لبضع دقائق في التوقيت الخطأ. ومع اعتماد المواقع على أطر JavaScript وخدمات سحابية متعددة، أصبحت مراقبة ما يراه Googlebot جزءًا أساسيًا من SEO التقني.
وكان سوالف قد تناول مؤخرًا موقف جوجل من العلاقة بين GEO وSEO، حيث أكدت الشركة أن أساسيات SEO التقنية والمحتوى القابل للزحف والفهرسة ما زالت ضرورية حتى مع توسع البحث بالذكاء الاصطناعي. والحالة الحالية مثال عملي على أهمية هذه الأساسيات.
الخلاصة في تحديث canonical في جوجل
الرسالة الأساسية من هذه الحالة أن ظهور نطاق غريب كنسخة أساسية لا يعني تلقائيًا أن جوجل تعرضت لخلل في نظام canonical أو أن الموقع تعرض للاختراق. قد يكون السبب ببساطة أن Googlebot شاهد رسالة خطأ متطابقة عبر أكثر من موقع في وقت سابق.
لذلك، عند مواجهة مشكلة canonical في جوجل، يجب البدء بما يراه Googlebot بالفعل، ثم مراجعة حالة الخادم ورؤوس HTTP والـcanonical والتحويلات. ويمكن مراجعة دليل Google Search Central الرسمي لحل مشكلات canonical، إلى جانب النقاش الأصلي على Reddit الذي شارك فيه جون مولر لفهم الحالة التي أثارت هذا التوضيح.
لا يسمح بنقل هذا المحتوى من سوالف دون الاشارة برابط مباشر
