पृष्ठ और समर्थित फीचर से शुरू करें
हर उस schema.org प्रकार को जोड़कर शुरू न करें जो आपके व्यवसाय से संबंधित लगता है। Schema.org एक व्यापक साझा शब्दावली है, जबकि Google की Search Gallery वे रिच-रिज़ल्ट फीचर दस्तावेज़ करती है जिन्हें वह सपोर्ट करता है और उन फीचरों के लिए किन प्रॉपर्टीज़ की आवश्यकता होती है। एक उत्पाद, इवेंट, या आर्टिकल पृष्ठ को पहले मार्कअप के बिना उपयोगी होना चाहिए।
प्रत्येक टेम्पलेट के लिए, उसका मुख्य विषय और दृश्य सहायक तथ्य नामित करें। फिर मेल खाते फीचर के लिए Google के वर्तमान गाइड को पढ़ें। Product, Recipe, Article, Breadcrumb, Event, Organization, Local business, और Video उदाहरण हैं। केवल एक शब्दावली प्रकार Google फीचर नहीं बनाता; उस फीचर की आवश्यक प्रॉपर्टीज़ पात्रता निर्धारित करती हैं।
प्राथमिक दृश्य आइटम को प्राथमिक मार्कअप बनाएं।
फीचर व्यवहार के लिए Google का गाइड और शब्दावली के लिए schema.org देखें।
दृश्य पृष्ठ को स्रोत सत्य मानें
मार्कअप को मुख्य पृष्ठ सामग्री का प्रतिनिधित्व करना चाहिए, न कि छिपी, अप्रासंगिक या भ्रामक सामग्री का। यदि मार्कअप कहता है कि कोई प्रदर्शनकर्ता उपस्थित है, तो पृष्ठ को उस प्रदर्शनकर्ता का वर्णन करना चाहिए। यदि यह एक समेकित रेटिंग (aggregate rating) को मार्कअप करता है, तो विज़िटर को वह रेटिंग दिखाई देनी चाहिए। इससे यह रोका जाता है कि कोई टेम्पलेट भ्रामक सार में बदल जाए।
पृष्ठ कॉपी और मार्कअप को एक ही अनुमोदित रिकॉर्ड से बनाएं। एक उत्पाद फ़ीड, इवेंट सिस्टम, या CMS दोनों प्रदान कर सकते हैं, पर मानों को प्रकाशन से पहले समीक्षा की जरूरत है। मूल्य, स्टॉक स्थिति, तिथि, या समीक्षा कुल को केवल मार्कअप-केवल फ़ील्ड में कॉपी न करें जिसे भुला दिया जा सकता है। जब दृश्य जानकारी बदलती है तो मार्कअप अपडेट या हटाएँ।
नाम, तिथियाँ, मूल्य, उपलब्धता, और रेटिंग पृष्ठ के साथ संरेखित रखें।
कभी भी अनुमानित या पुराने मानों से प्रॉपर्टीज़ भरें नहीं।
रखरखाव-योग्य डेटा लेयर के रूप में 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 का परीक्षण करें।
जब टूलिंग मार्कअप जोड़ती है तो रेंडर्ड पेज, स्रोत, और टेस्ट परिणाम की तुलना करें।
संभावित प्रदर्शन को अंतिम प्रदर्शन की गारंटी न समझें।
इसे उपयोगकर्ता-उन्मुख टेम्पलेट परिवर्तन की तरह जारी करें
संरचित डेटा अक्सर टेम्पलेट, फ़ीड, और प्रकाशन नियमों पर निर्भर करता है। एक रीडिज़ाइन, इन्वेंटरी इंटीग्रेशन परिवर्तन, लोकलाइज़ेशन अपडेट, या हटाया गया कम्पोनेंट कई आइटम तोड़ सकता है। प्रतिनिधि मार्कअप चेक्स को प्री-रिलीज़ समीक्षा में जोड़ें जो canonical टैग, शीर्षक, और छवियों के लिए उपयोग होती है। टेम्पलेट, पृष्ठ उदाहरण, स्रोत फ़ील्ड, और रिलीज़ तिथि रिकॉर्ड करें।
जब कोई टेम्पलेट गलत मार्कअप देता है, तो साझा स्रोत या टेम्पलेट को सुधारें, एक छोटा नमूना मान्य करें, सबसे संकीर्ण सुरक्षित परिवर्तन तैनात करें, और प्रभावित URL का पुनः परीक्षण करें। यदि फिक्स अप्रत्याशित व्यवहार करे, तो आपके सामान्य रोलबैक प्रक्रिया का उपयोग करें। उद्देश्य क्षतिग्रस्त वेब क्षमता का साक्ष्य-आधारित सुधार है, न कि आउटेज अलर्ट।
एकल URL का नहीं, प्रतिनिधि पृष्ठ सेट की जाँच करें।
अनुवर्ती सुधार से पहले परिवर्तन और मार्कअप कम्पोनेंट रिकॉर्ड करें।
रखरखाव, माप, और प्रदर्शन सीमा को स्वीकार करें
डिप्लॉयमेंट के बाद, संबंधित Search Console रिच-रिज़ल्ट रिपोर्ट का उपयोग करके समस्याओं की जाँच करें और फिक्स की पुष्टि करें। रिपोर्टें पूर्ण सूची नहीं बल्कि नमूने होती हैं, और गिनती आइटम्स को संदर्भित करती है, पृष्ठों को नहीं। आवश्यकता होने पर किसी विशेष URL का निरीक्षण करें।
माप सावधानीपूर्वक करें। Google स्थिर, पर्याप्त रीड पृष्ठों पर महीनों के समयावधि में पहले और बाद की तुलना करने का सुझाव देता है। रिलीज़ तिथि और अन्य पृष्ठ परिवर्तनों को रिकॉर्ड करें। सही मार्कअप केवल पात्रता सक्षम करता है; खोज प्रस्तुति का निर्णय Google लेता है।
CMS, टेम्पलेट, फ़ीड, नीति, या कंटेंट-मॉडल परिवर्तन के बाद पुन: जाँच करें।
जहाँ अन्य बड़े पृष्ठ परिवर्तन अलग हों उन तुलना से बचें।