بيانات Canonical الوصفية لا تتغير بشكل صحيح في تطبيق Discourse عند عدم تحميلها بواسطة زاحف الويب

هناك خطأ في تطبيق Discourse يتعلق بتحديث عنصر البيانات الوصفية <link rel="canonical"> في قسم <head> من هيكل DOM الخاص بـ Discourse.

بشكل أساسي، عندما يدخل عميل المتصفح إلى التطبيق ويتم تحميله لأول مرة، يتم ضبط عنصر <link rel="canonical" href=""> وفقًا لتحميل الصفحة الأولي؛ ولكن عندما ينقر المستخدم داخل التطبيق (سلوك مستخدم عادي)، دون إعادة تحميل الصفحة يدويًا، لا يتم تحديث رابط <link rel="canonical">.

لقد اختبرت هذا الخطأ وأعدت إنتاجه في موقع meta:

الشكل 1. الدخول إلى موقع meta من الصفحة الرئيسية، رابط canonical صحيح، وكذلك عنصر العنوان.

الشكل 2. زيارة موضوع. يتغير عنصر العنوان بشكل صحيح، لكن رابط canonical غير صحيح (لا يتم تحديثه كما ينبغي).

الشكل 3. زيارة موضوع آخر. يتغير عنصر العنوان بشكل صحيح، لكن رابط canonical غير صحيح (لا يتم تحديثه كما ينبغي).

الآثار على تحسين محركات البحث (SEO)

قد يؤثر هذا الخطأ سلبًا على تحسين محركات البحث لأن عندما يقوم جوجل بفهرسة الصفحة، إذا لم يكن Googlebot يقوم بإعادة تحميل “صارمة” لكل صفحة، فستكون معلومات canonical غير صحيحة لكل صفحة (كما في تسلسل الصور أعلاه).

إمكانية إعادة الإنتاج

لقد أعدت إنتاج هذا الخطأ بشكل متسق على كل من موقع meta وموقعنا.

ملاحظات

لقد رأيت مشاكل دورة حياة من نوع node.js (SPA) من قبل مع أطر عمل ويب أخرى (ليس فقط Ember) حيث لا يتم تحديث عناصر DOM، بناءً على خطافات دورة الحياة (لـ Ember وأطر عمل SPA الأخرى) داخل إطار عمل تطبيق الويب.

إعجاب واحد (1)

لن يحدث هذا أبدًا لأننا لا نقدم تطبيق الصفحة الواحدة (SPA) لـ Googlebot. يمكنك تعيين وكيل المستخدم (User Agent) الخاص بك إلى معرف GoogleBot UA أيضًا لترى كيف يعمل.

4 إعجابات

مرحبًا @Falco

شكرًا لك على ردك.

نعم، لا توجد مشكلة عند تعيين UA إلى GoogleBot (تم التأكد من ذلك).

أتفق على أن هذا قد لا يشكل مشكلة في تحسين محركات البحث (SEO) نظرًا لأنك لا تقدم SPA إلى GoogleBot، لكنه مع ذلك خطأ في SPA.

أيضًا، أحتاج إلى التفكير في تداعيات عدم تقديم SPA إلى GoogleBot.

شكرًا لك على إخباري بهذه “الحقيقة الصغيرة”…:slight_smile:

(ملاحظة: لم يكن لدي أي فكرة أن “المواضيع المقترحة” لا تُقدّم إلى GoogleBot، لكنني الآن أعرف… شكرًا لتزويدي بالمعلومة).

إعجاب واحد (1)

نقدم مستندًا مختلفًا تمامًا لمحركات البحث، حيث لا يمكن لكل محرك بحث تشغيل JavaScript، ونريد أن يكون Discourse متاحًا لهذه العملاء أيضًا، حتى لو تلقوا وظائف محدودة، فيمكنهم الوصول إلى جميع المحتويات.

5 إعجابات

شكرًا جزيلاً لإبلاغي بذلك.

الآن أدركت أن بعض النقاشات السابقة حول التطبيقات أحادية الصفحة (SPA)، و"التمرير اللانهائي"، وقضايا تحسين محركات البحث (SEO) الأخرى كانت خاطئة تمامًا، حيث إن تطبيق SPA لا يُقدَّم إلى GoogleBot.

هذا يغيّر نهجي تجاه بعض الأكواد المخصصة التي كتبتها مؤخرًا؛ والآن أعرف أنني بحاجة إلى التحقق باستخدام معرف مستخدم GoogleBot في وحدة التحكم.

شكرًا جزيلاً على ذلك، @Falco! تقديري كبير.

سؤال:

ما أفضل طريقة لإضافة ملف جافا سكريبت مخصص واحد إلى HTML الذي يُقدَّم إلى GoogleBot؟

هل توجد طريقة “قياسية” لتعديل HTML الذي يُقدَّم للروبوتات؟

السبب في طلبي هذا هو أننا نملك بعض الأكواد المخصصة التي تم إنشاؤها في إضافة (plugin) قمت بكتابتها (مخصصة للروبوتات)؛ لكنني تحققت باستخدام معرف مستخدم GoogleBot في وحدة التحكم (شكرًا مرة أخرى على إخباري بذلك)، ولم يستهلك GoogleBot أيًا من أكواد الإضافة المخصصة هذه.

إعجاب واحد (1)

في الوقت الراهن، وبما أنني لا أستطيع تحقيق ما أريد عبر إضافة (مبنية على Handlebars) للصفحات HTML الموجهة لمحركات البحث، فقد قررنا ببساطة إزالة وسوم canonical من Discourse. هذا حل جزئي مؤقتًا حتى أتمكن من معرفة كيفية تعديل وسم canonical باستخدام JavaScript لمحركات البحث.

توفر منصة Discourse آلية ممتازة لمثل هذه التغييرات في ملفات yml الخاصة بالحاويات، وهذا ما قمت به اليوم.

أشكر بشدة مجتمع Discourse Meta على توضيح أن تطبيق Discourse الموجه لمحركات البحث (المُعرَّفة) يختلف عن الصفحات الموجهة للمستخدمين.

يرجى ملاحظة أنني لا أنصح بهذا “الحل المؤقت” لمسؤولي أنظمة Discourse الآخرين. أنا مجرد شاركت ما قررت فعله في هذا الوقت، وكيف قمت به (حتى نبتكر حلاً أكثر إثارة).

إعجابَين (2)