أخطاء يجب تجنبها عند تطبيق ترميز البيانات المنظمة

 أخطاء يجب تجنبها عند تطبيق ترميز البيانات المنظمة


أخطاء يجب تجنبها عند تطبيق ترميز البيانات المنظمة

تسمح لنا البيانات المنظمة بتحديد نوع المعلومات التي يحتوي عليها موقع الويب لبرنامج Googlebot ، حتى يتمكن من تفسيرها بشكل أفضل.


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


يمكن أن تعاقب الصفحة نتيجة لمراجعة يدوية بواسطة Google.


في الامس القريب تطرقنا الى حل مشكلة مسار التنقل data-vocabulary.org وتصحيح خطأ Breadcrumb أدوات مشرفي المواقع

- تقديم عام :

عند قراءة الوثائق المتعلقة بالإجراءات اليدوية التي تنفذها Google لمعاقبة موقع ويب ، نواجه العديد من الأمثلة على إساءة استخدام البيانات المنظمة أو إساءة استخدامها. 


يتم دائمًا ارتكاب هذه الأخطاء عن قصد كجزء من إستراتيجية Black Hat SEO ، من أجل الظهور في SERPs مع مقتطفات منسقة. إن ارتكاب .


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


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


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


في الفقرات التالية ، سنرى أنواع الأخطاء التي يجب أن نتجنبها ، إذا أردنا أن تفسر Google بياناتنا بشكل صحيح ، وإذا كنا لا نريد الحصول على عقوبة. 


في الأساس ، يمكن أن يكون لدينا هذه الأخطاء:


  1. الأخطاء النحوية من نوعين :
  2. تلك المصنوعة فيما يتعلق بتنسيق اللغة.
  3. تلك المصنوعة فيما يتعلق بالقواعد المحددة بواسطة Schema.org و Google.
  4. الأخطاء الدلالية.
  5. يمكن أن تحدث هذه الأخطاء بغض النظر عن لغة الترميز.


- أقرأ أيضا :


1- أخطاء في بناء الجملة

تحدث الأخطاء النحوية عندما نكتب بلغة برمجة دون اتباع قواعد قواعدها النحوية. في حالة البيانات المنظمة ، يتعين علينا اتباع نوعين من القواعد النحوية : قواعد التنسيق .


والتي سنستخدمها لكتابتها (على سبيل المثال ، JSON-LD) ، وقواعد القواعد التي تحددها مفردات Schema.org.

2- أخطاء في بناء الجملة المتعلقة بالتنسيق

كما ذكرنا سابقًا ، هذه أخطاء تحدث عندما نكتب تنسيق البيانات المنظمة ، إما JSON-LD أو البيانات الجزئية ، مما يؤدي إلى استحالة تفسير نوع البيانات.


دعنا نرى مثالاً حيث نرى بشكل عام JSON-LD مع العديد من أخطاء بناء الجملة النموذجية. أحدها ، لأننا لم نعتبر أن سمة "الترخيص" يمكن أن تكون فارغة عند إنشاء هذا الرمز:


{

   "context": "https://schema.org/"،

   "type": "BlogPosting"،

   رخصة:

   العنوان: "مثال" ،

}


إذا لم تكن لدينا قيمة لـ "الترخيص" ، فيجب علينا إما إزالة هذه السمة ، أو إضافة سلسلة فارغة بالطريقة التالية ، لمنع أخطاء في بناء الجملة والحصول على JSON صحيح:


{

   "context": "https://schema.org/"،

   "type": "BlogPosting"،

   "رخصة": ""،

   "العنوان": "مثال"

}


الأخطاء الأخرى التي تم تصحيحها في المثال الثاني ، إذا لم تكن قد لاحظت ، هي علامات الاقتباس التي تحتوي على السمات ، وإزالة الفاصلة الأخيرة قبل قوس الإغلاق المتعرج. 


السمات الأخرى المطلوبة مفقودة أيضًا ، لكنها ليست تنسيقات أخطاء في بناء الجملة. وبدلاً من ذلك ينتمون إلى فئة أخطاء بناء جملة المفردات.


لتجنب هذه الأخطاء في تعريف البيانات المنظمة لدينا ، يجب أن نتبع قواعد JSON النحوية ، المحددة في RFC 7159 ، ومواصفات W3C JSON-LD;


ومواصفات WhatWG للبيانات الجزئية.


عندما تتبع لغة الترميز القواعد النحوية المحددة بشكل صحيح ، يُقال أنه تم تنسيقها بشكل صحيح (على سبيل المثال ، في أدوات التحقق من صحة XML.


مثل ملف Sitemap ، من الشائع تشغيل هذا التعبير).


- أقرأ أيضا : 


3- أخطاء في بناء الجملة المتعلقة بـ Schema.org و Google

هذه أخطاء لا تتبع القواعد النحوية لموقع Schema.org أو مواصفات Google.


بعض الأمثلة على أخطاء في بناء الجملة :


لتعيين نوع بيانات غير صحيح أو غير موجود كقيمة سمة. على سبيل المثال ، إذا كان كاتب السمة يمكن أن يكون فقط من النوع Organization أو Person.


فلا يمكننا كسر القواعد النحوية من خلال تخصيص نوع بيانات الحدث لها.


لإضافة سمة إلى نوع البيانات التي لا تحتوي على واحدة ، كنتيجة لحدوث خطأ عند اتباع المواصفات. على سبيل المثال ، إضافة السمة addressLocality مباشرة إلى نوع LocalBusiness.


{

  "context": "http://schema.org"،

  "type": "LocalBusiness"،

  "addressLocality": "Madrid"

}


هذا خطأ ، لأن المواصفات تشير إلى أن LocalBusiness يتكون من سمة عنوان من نوع PostalAddress. العنوان الموقع ينتمي إلى الأخير ، وليس إلى LocalBusiness.


{

  "context": "http://schema.org"،

  "type": "LocalBusiness"،

  "تبوك": {

    "type": "PostalAddress"،

    "addressLocality": "Madrid"

  }

}


يمكن تقسيم الأخطاء النحوية الناتجة عن عدم اتباع مواصفات المفردات إلى نوعين: تلك الناتجة عن عدم اتباع المواصفات العامة لـ Schema.org.


وتلك الناتجة عن عدم اتباع مواصفات Google. لقد أوضحنا بالفعل في الماضي كيفية تفسير Schema.org لإنشاء بيانات منظمة ، وأن مواصفات Google.


 تقدم قيودًا إضافية لمواصفات Schema.org ، مثل السمات المطلوبة.


عندما تتبع لغة الترميز قواعد بناء الجملة الخاصة بتنسيقها ومفرداتها ، يُقال إنها صالحة ، مما يعني أيضًا أنها منسقة بشكل صحيح.

4- كيفية تحديد نوع الخطأ في بناء الجملة باستخدام أدوات التحقق من الصحة

لا يحدد المترجمون الفوريون الذين تستخدمهم أدوات التحقق من صحة البيانات المنظمة ما إذا كانوا قد عثروا على أخطاء نحوية في التنسيق أو المفردات .


ولكن لديهم طريقتهم الخاصة للتعبير عن أنهم وجدوا خطأً في بناء جملة التنسيق. إذا عرضت الأداة نوعًا مختلفًا من الخطأ ، فهذا خطأ يتعلق بقواعد المفردات :


هذا مهم ، لأنه لكي تكون مفردات نوع البيانات المنظمة صحيحة ، يجب أولاً أن يكون تنسيقها صحيحًا من الناحية التركيبية. لذلك ، إذا كان لدينا خطأ في بنية التنسيق فقط .


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


6- الأخطاء الدلالية

الأخطاء الدلالية هي تلك الأخطاء التي تزود البيانات بمعنى مختلف عن المعنى الموجود بالفعل. من الأمثلة الواضحة والمبالغ فيها بشكل واضح استخدام نوع بيانات الكتاب في الوصفة. 


فيما يتعلق بالصياغة ، يمكن القيام بذلك ، بالإضافة إلى أن كل من Book and Recipe يرثان نفس سمات CreativeWork التي يمكننا ملؤها ، لكن المعنى الذي سنمنحه له لن يكون صحيحًا.


من الشائع العثور على حالات يمكن فيها تحسين المعنى على الرغم من عدم وجود خطأ. على سبيل المثال ، من خلال تعيين نوع بيانات المقالة لإدخال مدونة .


بدلاً من اشتقاق نوع BlogPosting. ومع ذلك ، هذا ليس سببًا لعقوبة.


لا توجد أداة تلقائية واحدة ستخبرنا ما إذا كان المستند صحيحًا من الناحية المعنوية. لهذا السبب تجري Google مراجعات يدوية ، وسبب وجود البيانات المنظمة .


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


الأخطاء الدلالية هي تلك التي يمكن أن تؤدي إلى عقوبة بعد المراجعة اليدوية ، بينما تؤدي أخطاء بناء الجملة فقط إلى تحذيرات  Google Search Console .


دون أي نوع من العقوبة ، إلى جانب وجود بيانات منظمة غير صحيحة.


7- مواصفات البيانات المنظمة من Google

إذا نظرنا إلى مواصفات البيانات المنظمة من Google ، فسنواجه المعنى الدلالي لكل نوع بيانات ، بتفاصيل أكثر بكثير من Schema.org. 


بالإضافة إلى ذلك ، تتضمن وثائق محرك البحث أمثلة لتجنب سوء التفسير ، مما قد يؤدي إلى عقوبة.


هذا هو نوع الخطأ الذي ترتكبه مُحسّنات محرّكات البحث عن قصد في Black Hat. على سبيل المثال ، حدث هذا كثيرًا مؤخرًا مع FAQPage و How to. 


أدى ظهور المقتطفات المنسقة في SERPs والبحث الصوتي إلى إساءة استخدام هذه العلامات. يتم استخدامها على الصفحات ، التي لا تقدم إرشادات أو إجابات.


عن طريق إضافة أجزاء من المحتوى بشكل مصطنع إلى أنواع الصفحات حيث لا علاقة للمحتوى الرئيسي بها. هدفهم الوحيد هو شغل مساحة أكبر في النتائج .


دون التفكير في حقيقة أن هذا شيء سيقلل من أهميتها فيما يتعلق بما يريدون حقًا الترتيب له ، وخفض ترتيبهم وزيادة معدل الارتداد.


8- أخطاء أخرى

يعد تنفيذ البيانات المنظمة على المعلومات التي لا توجد حتى على الصفحة ، أو المعلومات المخفية عن المستخدم خطأ شائعًا في أكثر عمليات تحسين محركات البحث جرأة في Black Hat. 


يمكن اعتبار هذا أيضًا خطأً دلاليًا ، مما يوفر أسبابًا للعقوبة. على سبيل المثال ، يعد هذا أمرًا شائعًا مع المقتطفات المنسقة للمراجعة ، والتي تُستخدم لتكوين تقييمات.


والتي لا تظهر أبدًا على الصفحة ، أو يتم إخفاؤها ببساطة ، والغرض الوحيد منها هو الظهور بتصنيف نجمي في نتائج البحث.


في الآونة الأخيرة ، حدت Google من عدد أنواع البيانات المنظمة التي يمكن تطبيقها عليها ، ولا تسمح باستخدامها في التعليقات ذاتية الخدمة لأنواع LocalBusiness و Organization .


بسبب سوء الاستخدام المتكرر الذي عانى منه هذا النوع من البيانات المنظمة.


من بين إرشادات Google ، يمكننا العثور على متطلبات منطقية أخرى ، مثل عدم تطبيق البيانات المنظمة على المحتوى غير القانوني ، أي: انتحال المحتوى .


أو عمليات الاحتيال ، أو الاحتيال ، أو أي نوع آخر من المحتوى المؤسف أخلاقياً.


- أقرأ أيضا :


- استنتاج

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


لقد وضعونا في مواقع أفضل للأشياء التي نحن على صلة بها ، مما يقلل من معدل الارتداد ، والذي يحسن الترتيب في نفس الوقت.


تعتبر التغييرات المرئية التي توفرها المقتطفات المنسقة مفيدة أيضًا في زيادة نسبة النقر إلى الظهور في SERPs ، لكن معظم مُحسّنات محرّكات البحث لا ترى هذا التأثير إلا. 


من حين لآخر ، تسيء مُحسّنات محرّكات البحث في Black Hat ذلك ، لدرجة تشويه معنى المحتوى تمامًا ، وهو ما يؤدي إلى نتائج عكسية ويؤدي إلى عقوبة.


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


أضف تعليق

أحدث أقدم

Comments

no-style