ابدأ بالصفحة وميزة مدعومة
لا تبدأ بإضافة كل نوع من schema.org يبدو ذا صلة بنشاطك. Schema.org عبارة عن مفردات عامة واسعة، بينما توثيق Search Gallery الخاص بـ Google يحدد ميزات النتائج الغنية المدعومة والخصائص المطلوبة لكل ميزة. يجب أن تكون صفحة منتج أو حدث أو مقال مفيدة أولًا بدون وسم.
لكل قالب، سمِّ موضوعه الرئيسي والحقائق الداعمة المرئية. ثم اقرأ دليل Google الحالي للميزة المطابقة. أمثلة على ذلك: Product وRecipe وArticle وBreadcrumb وEvent وOrganization وLocalBusiness وVideo. وجود نوع من المفردات لا ينشئ ميزة Google بحد ذاته؛ خصائص الميزة المطلوبة هي التي تحدد الأهلية.
اجعل العنصر المرئي الأساسي هو العنصر الأساسي في الوسم.
استخدم دليل Google لسلوك الميزة وschema.org للمفردات.
اجعل الصفحة المرئية مصدر الحقيقة
يجب أن يعكس الوسم محتوى الصفحة الرئيسي، لا مواد مخفية أو غير ذات صلة أو مضللة. إذا ذكر أن فنانًا سيظهر، يجب أن تصف الصفحة ذلك الفنان. إذا وسمت تقييمًا تجميعيًا، يجب أن يرى الزائرون ذلك التقييم. هذا يمنع انحراف القوالب إلى تلخيص مضلل.
ابنِ نص الصفحة والوسم من نفس السجلات المعتمدة. يمكن أن يوفر كل من تغذية المنتجات أو نظام الأحداث أو نظام إدارة المحتوى كلا المصدريْن، لكن القيم تحتاج مراجعة قبل النشر. لا تنسخ سعرًا أو حالة مخزون أو تاريخًا أو إجمالي تقييم في حقل يظهر في الوسم فقط وقابل للنسيان. حدِّث أو أزل الوسم عندما تتغير المعلومات المرئية.
حافظ على تطابق الأسماء والتواريخ والأسعار والتوافر والتقييمات مع الصفحة.
لا تملأ خصائص بقيم مخمنة أو قديمة.
استخدم JSON-LD كطبقة بيانات قابلة للصيانة
JSON-LD هو شكل بيانات مترابطة قائم على JSON يُوضع داخل مستند HTML. تدعم Google JSON-LD وMicrodata وRDFa، وتقول إن JSON-LD عادةً أسهل في التنفيذ والصيانة على نطاق واسع. انفصاله عن الوسم المرئي يمكن أن يجعل نمذجة المعلومات المتداخلة أسهل.
استخدم كائن بيانات واضح واحد لكل عنصر حقيقي، بنوع schema.org مناسب وخصائص مدعومة ودقيقة. لكل قالب، وثق دليل الميزة، حقل المصدر، سلوك الحقول المطلوبة، والمالك. افحص الناتج المولَّد أيضًا: يمكن للإضافات أو المكونات أن تضيف وسومًا مكررة أو متضاربة.
اختر الصيغة التي يمكن لفريقك الحفاظ عليها بشكل مستمر.
لا تخترع قيمة مطلوبة عندما تكون بيانات المصدر مفقودة.
تحقق من الكود والصفحة القابلة للوصول
الإختبار يجيب عن سؤالين. أولًا، هل الوسم مكتمل بما يكفي لميزة مدعومة؟ تقبل أداة Rich Results Test لصق الكود أو عنوان URL عام وتبلغ عن النتائج الغنية التي يمكن إنتاجها من البيانات المنظمة. اختبر أمثلة تمثيلية لكل قالب، لا صفحة واحدة كاملة بشكل غير عادي.
ثانيًا، هل يمكن لـ Google الوصول إلى الصفحة والموارد المصدرة؟ لا تُغلق صفحات الوسم في robots.txt أو بـ noindex أو ضوابط وصول. تحقق من عناوين URL للصور ذات الصلة. الاختبار ليس ضمانًا للجودة: قد تمنع مشاكل المحتوى المرئي أو السياسات العرض.
اختبر الكود أولًا، ثم اختبر عنوان URL عام متاح على الإنترنت.
قارن الصفحة المعروضة، والمصدر، ونتيجة الاختبار عندما تضيف الأدوات وسمًا.
الإمكانية المعروضة ليست وعدًا بالعرض النهائي.
أطلقه كما لو أنه تغيير قالب يواجه المستخدم
تعتمد البيانات المنظمة غالبًا على القوالب والتغذيات وقواعد النشر. يمكن لتصميم جديد، أو تغيير في تكامل المخزون، أو تحديث تعريبي، أو إزالة مكوّن أن يكسر عناصر كثيرة. أضف فحوصات وسم تمثيلية إلى مراجعة ما قبل الإصدار المستخدمة للوسوم الكانونية والعناوين والصور. سجِّل القالب، أمثلة الصفحات، حقول المصدر، وتاريخ الإصدار.
عندما يصدر قالب وسمًا خاطئًا، صحح المصدر المشترك أو القالب، تحقق من عينة صغيرة، نشّر أصغر تغيير آمن، وأعد اختبار عناوين URL المتأثرة. إذا عمل التصحيح بشكل غير متوقع، استخدم عملية التراجع العادية. الهدف هو علاج قائم على الأدلة لقدرة متدهورة على الويب، وليس إنذار انقطاع.
افحص مجموعات صفحات تمثيلية، لا عنوان URL واحد.
سجِّل التغيير ومكوّن الوسم قبل أي تصحيح لاحق.
صِله، قِس، واقبل حد العرض
بعد النشر، استخدم تقرير النتائج الغنية المناسب في Search Console للتحقيق في المشكلات وتأكيد التصحيحات. التقارير هي عينات وليست جردًا كاملاً، والأعداد تشير إلى العناصر وليس الصفحات. افحص عنوان URL محددًا عند الحاجة.
قِس بحذر. تقترح Google مقارنة قبل/بعد على صفحات مستقرة وكافية القراءة على مدى شهور في Search Console. سجِّل تاريخ الإصدار وأي تغييرات صفحة أخرى. التصحيح الصحيح للوسم يمكّن الأهلية فقط؛ Google هي التي تحدد العرض داخل نتائج البحث.
أعد الفحص بعد تحديثات CMS أو القالب أو التغذية أو نموذج المحتوى.
تجنب المقارنات التي تختلف فيها تغييرات الصفحة الكبرى الأخرى.