تحسينات مخطط منتدى النقاش

مرحباً. نتلقى حاليًا هذه الرسالة في Google Search Console. لست متأكدًا تمامًا مما تعنيه. هل يمكنني الحصول على مزيد من التوضيح بشأن هذه المشكلة؟ هل هناك حل؟ بالإضافة إلى ذلك، أود أن أذكر أننا جربنا استخدام سمات متعددة للمنصة، ولكن نفس الخطأ لا يزال مستمراً.

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

أهلاً، يا متعثر!

تساعد البيانات المنظمة محركات البحث على توفير المزيد من السياق، بشكل أساسي.

لا يجد بحث Google حقلاً اختيارياً url في هذا الموضوع.

يمكنك رؤية ذلك على validator.schema.org أنه صالح تماماً دون أي تحذيرات.

لا يوجد ما يدعو للقلق.
ومع ذلك، إذا سلط بحث Google الضوء على هذا الحقل، فسيكون ذلك سبباً وجيهاً لإضافته في Discourse.

3 إعجابات

كما أوضح @Arkshine أعلاه، هذه ليست مشكلة بل اقتراح من جوجل لإضافة حقل اختياري في المخطط. سألقي نظرة على الأمر.

إعجابَين (2)

من الموضوع الآخر:

إذًا، نعم، “url” اختياري، ولكن هناك أخطاء حقيقية وصحيحة هنا أيضًا.

يساعد itemprop="url" جوجل على تجميع عدة كتل Comment على عناوين URL مختلفة تنتمي إلى نفس الموضوع.

حاولت إعادة إنتاج الأخطاء التي تراها من خلال اختبار المواضيع الوصفية في اختبار النتائج الغنية من Google، ولكنني لا أرى أي أخطاء.

هل يمكنك تقديم رابط للموضوع الذي تظهر فيه أخطاء Google؟

أول شيء يجب أن تلاحظه هو أن الرابط الذي أظهرته يشير إلى أن الرابط لا يحتوي على مخطط منتدى المناقشة. هذا الرابط يحتوي فقط على مخطط “Breadcrumbs” ، ولا يحتوي على مخطط “Discussion Forum” على الإطلاق. يحدث هذا لأنك تختبر الرابط في وضع “الهاتف الذكي” ، وليس في وضع “سطح المكتب”.

https://search.google.com/test/rich-results/result?id=TlLcA6saLMo3BrxbQYnFuw

عندما تقوم بتبديل الرابط إلى اختبار سطح المكتب ، يظهر مخطط “Discussion Forum” ، ويشير إلى مشكلة “حقل url مفقود”.

لتكرار الأخطاء الحرجة ، يجب عليك اختبار سلسلة طويلة باستخدام المعلمة ?page=2 للرابط ، مثل هذا:

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

أود أن أشير إلى أنني أعتقد أنه خطأ مهم في Discourse أن المخطط لا يظهر في وضع الهاتف الذكي. لن يتمكن Google من اكتشافه (لأن Google يكتشف الأخطاء فقط في المخطط الموجود)، ولكن الزحف والفهرسة للهواتف الذكية هو الوضع الافتراضي لـ Google منذ سنوات، لذا من المهم أن يظهر أي مخطط في وضع الهاتف الذكي وفي وضع سطح المكتب.

إعجابَين (2)

تم إصلاح المشكلة الموضحة في المنشور الأول بالإضافة إلى بعض المشكلات الأخرى في هذا الالتزام:

شكرًا على الاقتراحات هنا @rrit! :+1:

يحدث هذا لأن المنشور الأول غير مدرج من الصفحة الثانية فصاعدًا في عرض الزاحف. @sam هل يجب علينا تضمين المنشور الأول في جميع الصفحات في عرض الزاحف لإصلاح مشكلات المخطط؟ :thinking:

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

لا أعتقد ذلك، تكرار المحتوى لا ينتهي بشكل جيد، هل هناك خيارات أخرى؟

3 إعجابات

الخيار الآخر سيكون استبدال microdata schema بـ JSON-LD (والذي توصي به Google). سيفصل هذا البيانات المعروضة عن البيانات المهيكلة وسيعمل أيضًا على الأجهزة المحمولة (كما أشار Dan أعلاه).

نحن نستخدم بالفعل مخطط JSON-LD في solved plugin.

3 إعجابات

بالتأكيد، يبدو هذا حلاً أكثر صحة.

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

لا تقم بتضمين بيانات/نص المنشور الأول في الصفحات اللاحقة، ولكن قم دائمًا بإضافة itemprop="url" الذي يشير إلى الصفحة الأولى:

انظر Google structured data for forums and profile pages - #9 by rrit

3 إعجابات

لا توجد قاعدة بدون استثناء: بالنسبة لـ DiscussionForumPosting، توصي Google باستخدام Microdata وليس JSON-LD.

انظر Discussion Forum (DiscussionForumPosting, SocialMediaPosting) Schema Markup | Google Search Central  |  Documentation  |  Google for Developers

المبادئ التوجيهية الفنية

  • على عكس تفضيلنا العام للبيانات المنظمة، نوصي بتقديم ترميز DiscussionForumPosting بتنسيق Microdata (أو RDFa) إن أمكن. هذا يمنعك من الحاجة إلى تكرار كتل نصية كبيرة داخل الترميز. ومع ذلك، هذه مجرد توصية، ولا يزال JSON-LD مدعومًا بالكامل.
4 إعجابات

هل هذا متاح بالفعل على meta.discourse.org؟

يرجى الاطلاع على تعليقي على github:

يجب تعريف وسم الرابط هذا بالكامل فقط لـ post.is_first_post - لا حاجة لتكراره بنفس عنوان URL المتطابق لكل عنصر Comment.

على meta.discourse.org، تم تشويه علامات الاقتباس حاليًا:
<link itemprop='mainEntityOfPage' href="…"
انظر Schema Markup Validator

3 إعجابات

نعم، نحن نفعل ذلك الآن وفقًا لـ التزام حديث، ولكن حتى بعد إضافة ذلك، فإننا نفتقد بعض الحقول المطلوبة (author، datePublished، text) للصفحات اللاحقة (?page=2).

اكتشاف رائع! تم الإصلاح في طلب السحب هذا:

أوه نعم. تم تأكيد ذلك أيضًا بواسطة @rrlevering هنا:

لذا أعتقد أننا سنضطر إلى تحسين مخطط Microdata مع التأكد من أننا لا نكرر المحتوى في الصفحات اللاحقة.

7 إعجابات

شكراً على الإصلاح الخاص بخاصية mainEntityOfPage.

وتحديد جيد لعلامة meta مقابل علامة link :+1:
<link itemprop='url' content='<%= @topic_view.absolute_url %>'>

أفضل من ذلك:
<link itemprop='url' href='<%= @topic_view.absolute_url %>'>

انظر:
– هذا الرابط قديم، لكن YouTube لا يزال يستخدم link itemprop='url' href='…' اليوم. –

“لتوفير عنوان URL في HTML5، […] استخدم السمة href [لعلامة link]”
“إذا استخدمت عنوان URL كقيمة للسمة content لعنصر meta، فسيُمثل سلسلة نصية (تبدو وكأنها عنوان URL)، وليس عنوان URL.”


لقد أعدت التحقق من المستندات التي قدمتها Google حول DiscussionForumPosting: الخصائص:

الخصائص المطلوبة:

  • author
  • author.name
  • datePublished
  • إما text أو image أو video

ملاحظة خاصة حول: إما text أو image أو video

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

الخصائص الموصى بها

  • url
  • […]

ملاحظة خاصة حول: url

“عنوان URL الأساسي للمناقشة. في المواضيع متعددة الصفحات، اضبط هذه الخاصية على عنوان URL للصفحة الأولى. بالنسبة لمناقشة فردية، يكون هذا عادةً عنوان URL الحالي.”

لذا أستنتج:

  • لا نحتاج إلى إضافة text مرة أخرى في page=2+ (تم)
  • يجب علينا إضافة الخاصية الاختيارية url - خاصة للصفحات page=2+ (تم)

الحاجة لمزيد من التحقيق:

  • هل هذه “الخصائص المطلوبة” author و author.name و datePublished مطلوبة حقًا في page=2+ أم يمكننا الاستغناء عنها؟
    validator.schema.org لا يشتكي من نقص الخصائص في page=2+. (تم)
    → انتظر وتحقق من “وحدة تحكم بحث Google → تقرير: التحسينات → منتدى المناقشة” للحصول على بيانات مباشرة جديدة بعد أن تكون هذه الإصلاحات التي تم تنفيذها بالفعل سارية المفعول لبعض الوقت. (مطلوب)

البيانات المنظمة: الأدوات والموارد

المخطط

schema.org

developers.google.com

المدققات

schema.org

  • المدقق العام:
    https://validator.schema.org/
    يتحقق هذا من توافق البيانات المنظمة مع تعريفات المخطط، وأن الترميز متوافق مع HTML/XML.
    → المتطلبات التي تم فحصها تتبع Standard™ وهي واسعة جدًا وغير محددة.
    → أوصي بإصلاح كل خطأ تم اكتشافه.

وحدة تحكم بحث Google

  • تقرير: التحسينات → منتدى المناقشة:
    https://search.google.com/search-console/r/discussion-forum?hl=en
    يقدم هذا ملاحظات مباشرة حول المعلومات التي تمت معالجتها بواسطة زاحف Google.
    هذه التقارير ملزمة بشكل ما كحقائق قاطعة حول تحسين محركات البحث في Google: إذا أعلن Google عن وجود خطأ، فإن Google يعتقد أيضًا أنه خطأ - حتى لو لم يكن كذلك.
    → إذا تم تمييز شيء ما على أنه “غير صالح” أو “بحاجة إلى تحسين”، أوصي بالتفكير أولاً في الإصلاح. وإذا لم تكن هناك آثار جانبية معروفة، فقم دائمًا بتنفيذ الإصلاح.

Google: اختبار النتائج الغنية

  • https://search.google.com/test/rich-results?hl=en
    يقدم هذا ملاحظات محاكاة فقط وهو ليس زاحف Google.
    رأيي: أداة تسويق من Google لإخبار مالكي المواقع “افعلوا شيئًا بشأن بياناتكم المنظمة!”.
    → يتم إهمال هذه الأداة إلى حد ما من قبل Google وليست دائمًا محدثة بأحدث التوصيات الفنية التي تقدمها Google نفسها.
    Rich Results Test لا يقدم دائمًا نفس النتيجة مثل Google Search Console - في حالة الشك: ثق بـ Google Search Console بشكل أفضل.
5 إعجابات

دعني أكتب بعض الكود الزائف للفحص الحالي المعروض في Search Console. أعتقد أن هذا سيساعد كثيرًا في هذه المواضيع. يمكنني إرسال ShEx أو SHACL لك، لكنهما أقل قابلية للقراءة البشرية.

    if not (IsDeletedContent() OR IsExternalContent())
       then if not ("text" OR "articleBody" OR "sharedContent" OR "image" or "video")
         then report(OneOfThreeRequired("text", "image", "video"))
    if not ("author")
       then Report(Required("author"))
    if not("datePublished")
       then Report(Required("datePublished")

الفكرة هي أنه إذا كان محتوى DiscussionForumPosting/OP موجودًا في الصفحة الحالية، فيجب أن يكون هناك حقل محتوى من نوع ما.

إذا كان DiscussionForumPosting يشير إلى محتوى في صفحة مختلفة (مثل الصفحة الأصلية لمحتوى متعدد الصفحات)، فيمكن أن يحتوي فقط على جزء يمثل أي شيء (مثل عنوان موضوع OP) ثم يشير إلى عنوان URL للصفحة الأولى. هذا هو فحص IsExternalContent() الذي يتحقق فقط مما إذا كان url != page URL.

المثال الثاني في مستنداتنا كان من المفترض أن يمثل هذه الحالة بالضبط (الصفحة 14 تشير إلى منشور مختصر من الصفحة الأولى).

author و date مطلوبان حاليًا بغض النظر عن قواعد التحقق لدينا. هذا في الغالب لمنع خطوة إضافية للعثور على هذه البيانات. يمكنك على الأقل رؤية كيف يمكن أن يكون معرفة تاريخ OP مفيدًا لفهم مدى قدم التعليق. هل يمكنك فقط إضافة عناصر meta بهذه البيانات؟ لم أكن قلقًا بشأن هذه الحقول بقدر ما كنت قلقًا بشأن تضخيم الصفحة ببيانات زائدة.

7 إعجابات

شكراً على السياق والنصائح يا رايان!

تم ذلك. البيانات الوصفية للصفحات اللاحقة (الصفحة 2 وما بعدها) تبدو جيدة الآن!

3 إعجابات

هل لا يزال من المنطقي إضافة عنوان URL للمؤلف (author) بينما يكون المسار محظورًا بواسطة ملف robots.txt الافتراضي الخاص بنا؟ هل يجب علينا إزالة الحظر من robots.txt الآن بعد أن روجنا لعناوين URL هذه؟

إعجابَين (2)