Screpy का संरचित डेटा जाँचकर्ता किसी सार्वजनिक पृष्ठ या चिपकाए गए कोड का JSON-LD जाँचता है। यह पार्सिंग त्रुटियाँ पहचानता है, घोषित इकाइयाँ दिखाता है और पाँच समर्थित स्कीमा प्रकारों की चुनी हुई प्रॉपर्टी की समस्याएँ बताता है। रिपोर्ट से तय करें कि क्या सुधारना है और किस हिस्से की व्यापक जाँच करनी है। मान्य सिंटैक्स, समर्थित जाँचें और Google के रिच रिज़ल्ट की पात्रता अलग प्रश्न हैं; यहाँ हरी स्थिति तीनों का उत्तर नहीं देती।
पृष्ठ URL या चिपकाया गया JSON-LD चुनें
प्रकाशित पृष्ठ, जैसे उत्पाद विवरण या व्यवसाय संपर्क पृष्ठ, जाँचने के लिए पेज URL चुनें। हमेशा होमपेज देने के बजाय उस विशेष पृष्ठ का सार्वजनिक HTTP या HTTPS पता दें: अलग टेमप्लेट में अलग मार्कअप हो सकता है। URL मोड पृष्ठ से लौटाया गया HTML पढ़ता है। निजी या पासवर्ड से सुरक्षित पृष्ठ वही सार्वजनिक प्रमाण नहीं देता, और पृष्ठ प्राप्त करने में विफलता उसके संरचित डेटा के खराब होने का प्रमाण नहीं है।
ड्राफ़्ट, निकाली गई स्क्रिप्ट या आपके पास मौजूद HTML देखने के लिए कोड पेस्ट करें चुनें। केवल JSON देने के लिए JSON-LD चुनें, उसके आसपास <script> एलिमेंट न रखें। इनपुट में <script type="application/ld+json"> ब्लॉक हों तो HTML चुनें। अलग JSON फ़ाइल का पता HTML पृष्ठ नहीं है; उसकी सामग्री JSON-LD मोड में चिपकाएँ। चिपकाए गए इनपुट की सीमा UTF-8 बाइट में २५६ KiB है, इसलिए स्वीकार्य अक्षरों की संख्या पाठ पर निर्भर करती है।
URL जाँच JavaScript नहीं चलाती। पृष्ठ लोड होने के बाद जोड़ा गया मार्कअप प्राप्त स्रोत में नहीं हो सकता। Google गतिशील रूप से जोड़े गए JSON-LD को संसाधित कर सकता है, इसलिए रिपोर्ट में ब्लॉक का न मिलना यह साबित नहीं करता कि Google भी उसे नहीं देखता। यह अंतर महत्वपूर्ण हो तो संबंधित रेंडर किया गया मार्कअप देखें या Google का फ़ीचर परीक्षण इस्तेमाल करें। चिपकाया गया कोड केवल आपके दिए इनपुट की जाँच करता है; वह लाइव पृष्ठ से भेजे जाने वाले मार्कअप का प्रमाण नहीं है।
संरचित डेटा रिपोर्ट पढ़ें
पहले जाँच कवरेज देखें, फिर निष्कर्ष और इकाइयों की तालिका पढ़ें। JSON-LD ब्लॉक HTML में मिली स्क्रिप्ट गिनता है; चिपकाया गया JSON-LD एक ब्लॉक माना जाता है। इकाइयाँ घोषित प्रकार वाले सुरक्षित रखे गए ऑब्जेक्ट गिनता है, जिनका JSON सफलतापूर्वक पार्स हुआ; एक स्क्रिप्ट में कई इकाइयाँ हो सकती हैं। सिंटैक्स त्रुटियाँ संसाधित किए गए उन ब्लॉक की संख्या है जो पार्स नहीं हो सके। ये अलग संख्याएँ हैं, इसलिए तीन ब्लॉक वाले पृष्ठ में तीन इकाइयाँ होना ज़रूरी नहीं। आंशिक रिपोर्ट में पहचाने गए ब्लॉक की संख्या हर ब्लॉक के जाँचे जाने का प्रमाण नहीं है।
हर पंक्ति सिंटैक्स और दायरा अलग दिखाती है। हरा मान्य सिंटैक्स बताता है कि JSON पार्सर ने ब्लॉक स्वीकार किया। हरी समर्थित जाँच बताती है कि इकाई इस टूल की चुनी हुई प्रॉपर्टी जाँचों की शर्तों पर खरी उतरी। उसके निष्कर्ष भी पढ़ें: कोई भी लेबल सभी प्रॉपर्टी सही होने का प्रमाण नहीं है। लाल पार्सिंग त्रुटि या त्रुटि वाले निष्कर्ष, पीला चेतावनी और आंशिक कवरेज, तथा धूसर असमर्थित या अनुपलब्ध प्रमाण दर्शाता है। रंग के साथ लिखी स्थिति भी पढ़ें।
पथ कॉलम नेस्टेड ऑब्जेक्ट खोजने में मदद करता है। उदाहरण के लिए $.author रूट के अंदर लेखक का ऑब्जेक्ट बताता है, जबकि $.@graph[1] किसी @graph ऐरे का दूसरा ऑब्जेक्ट बताता है। पथ अपने JSON-LD ब्लॉक के सापेक्ष होते हैं, इसलिए कई स्क्रिप्ट में एक जैसा पथ आ सकता है। डाउनलोड किए गए JSON में उन्हें अलग पहचानने के लिए ब्लॉक नंबर होते हैं।
नाम कॉलम name पढ़ता है, हर प्रकार की प्रदर्शित नाम वाली प्रॉपर्टी नहीं। इसलिए मान्य headline वाले Article में नाम का सेल खाली हो सकता है। उसे सामग्री की समस्या मानने से पहले संबंधित प्रॉपर्टी और निष्कर्ष देखें।
प्रॉपर्टी की चेतावनी से पहले JSON सिंटैक्स सुधारें
अमान्य ब्लॉक इकाइयों के बारे में विश्वसनीय निष्कर्ष नहीं दे सकता। पहले JSON ठीक करें, फिर अनुपस्थित प्रॉपर्टी की चेतावनी समझने से पहले जाँच दोबारा चलाएँ। आम कारणों में नाम या पाठ के आसपास सिंगल कोट, आख़िरी प्रॉपर्टी के बाद अतिरिक्त कॉमा, बंद करने वाला ब्रैकेट गायब होना और पाठ के भीतर एस्केप न किया गया कोटेशन मार्क शामिल हैं। JSON डबल कोट वाली स्ट्रिंग और सदस्यों के बीच कॉमा इस्तेमाल करता है; RFC 8259 उसका व्याकरण निर्धारित करता है।
यह काल्पनिक Organization कोड पेस्ट करें → JSON-LD के लिए सिंटैक्स का न्यूनतम उदाहरण है:
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Example Studio",
"url": "https://example.com/"
}
उदाहरण में Organization के लिए इस जाँचकर्ता द्वारा देखी जाने वाली दोनों प्रॉपर्टी हैं। यह Google के किसी खोज फ़ीचर का पूरा टेमप्लेट नहीं है। काल्पनिक मानों की जगह पृष्ठ के सही तथ्य दें और प्रकाशित करने से पहले संबंधित फ़ीचर की आवश्यकताएँ पढ़ें।
केवल मान्य JSON उपयोगी संरचित डेटा साबित नहीं करता। अकेली स्ट्रिंग या संख्या मान्य JSON हो सकती है, लेकिन अपेक्षित इकाई का वर्णन नहीं कर सकती; यह टूल बताता है कि रूट पर ऑब्जेक्ट या ऐरे चाहिए। इसी तरह घोषित @type के बिना पार्स हुआ ऑब्जेक्ट किसी इकाई की पंक्ति न दे सके। सिर्फ़ रिपोर्ट के संदेश हटाने के लिए प्रॉपर्टी जोड़ने से पहले वास्तविक संरचना जाँचें।
कौन सी स्कीमा प्रॉपर्टी जाँची जाती हैं?
संरचित डेटा जाँचकर्ता पहचाने गए कॉन्टेक्स्ट के साथ पाँच सटीक प्रकारों पर चुनी हुई जाँचें करता है। निष्कर्ष समझने के लिए यह तालिका देखें; इसे Schema.org की सभी प्रॉपर्टी या Google के आवश्यक फ़ील्ड की पूरी सूची न मानें।
| घोषित प्रकार | यह जाँचकर्ता क्या देखता है | निष्कर्ष का उपयोग कैसे करें |
|---|---|---|
Organization |
name और url की मौजूदगी |
देखें कि वे वास्तविक संगठन और उसकी सही वेबसाइट का वर्णन करते हैं। |
LocalBusiness |
name और address की मौजूदगी |
व्यवसाय की वास्तविक पहचान और पता जाँचें; पते के घटक पूरी तरह सत्यापित नहीं होते। |
Article |
headline, author, datePublished और image की मौजूदगी |
मानों को लेख से मिलाएँ और फ़ॉर्मैट अलग से जाँचें। |
Product |
name की मौजूदगी; क्या offers, review या aggregateRating में से कोई दिया गया है |
केवल सही और लागू उत्पाद डेटा इस्तेमाल करें। चेतावनी हटाने के लिए ऑफ़र या समीक्षा न गढ़ें। |
BreadcrumbList |
गैर-खाली itemListElement ऐरे; हर जाँचे गए आइटम की धनात्मक पूर्णांक position और गैर-खाली पाठ name |
बताए गए आइटम को सुधारें, फिर पूरी नेविगेशन शृंखला और गंतव्य URL अलग से जाँचें। |
अधिकांश जाँचें केवल मौजूदगी देखती हैं। किसी मान का URL, तारीख, चित्र, ऑब्जेक्ट की संरचना या तथ्य गलत होने पर भी वह मौजूद हो सकता है। खाली ऑब्जेक्ट मौजूदगी की जाँच पूरी कर सकता है, और केवल स्पेस वाले मान हर जाँच में अस्वीकार नहीं होते। इसलिए समर्थित स्थिति पता, लेखक या ऑफ़र पूरा होने की पुष्टि नहीं करती।
ब्रेडक्रंब की जाँचें आइटम के चुने हुए मान भी देखती हैं, लेकिन क्रमिक या अद्वितीय स्थिति, सही item URL या पूरा ListItem अर्थगत सत्यापन स्थापित नहीं करतीं। रिपोर्ट हर इकाई के लिए अधिकतम १०० प्रॉपर्टी निष्कर्ष रखती है। लंबी नेविगेशन शृंखला या बार-बार दोष वाली इकाई को उसके बाद भी अतिरिक्त समीक्षा की ज़रूरत हो सकती है।
पृष्ठ के संदर्भ में निष्कर्ष सुधारें। किसी लेख का लेखक व्यक्ति हो तो सही लेखक संरचना रखें, भले ही नेस्टेड Person इस जाँचकर्ता के दायरे से बाहर दिखे। केवल हरे लेबल पाने के लिए सही मार्कअप बदलने से मूल समस्या हल होने के बजाय छिप सकती है।
मान्य मार्कअप असमर्थित या आंशिक क्यों दिखता है?
असमर्थित का अर्थ है कि टूल ने उस इकाई पर चुनी हुई प्रॉपर्टी जाँचें नहीं कीं। इसका अर्थ यह नहीं है कि Schema.org उस प्रकार को प्रतिबंधित करता है। उदाहरण के लिए समर्थित Article में नेस्टेड Person लेखक हो सकता है। Article की चुनी हुई जाँचें होती हैं, लेकिन Person असमर्थित दिखती है और कवरेज आंशिक हो जाता है। Restaurant अधिक विशिष्ट व्यवसाय प्रकार होने के बावजूद पाँच सटीक समर्थित प्रकारों से बाहर है। विषय का सही वर्णन करने वाला प्रकार रखें और बाकी जाँचों के लिए व्यापक वैलिडेटर इस्तेमाल करें।
कॉन्टेक्स्ट भी यही अंतर पैदा कर सकता है। यह जाँचकर्ता साधारण http://schema.org या https://schema.org कॉन्टेक्स्ट पहचानता है, अंत में स्लैश हो या न हो, और पैरेंट ऑब्जेक्ट से मिला कॉन्टेक्स्ट भी। यह ऑब्जेक्ट या ऐरे कॉन्टेक्स्ट हल नहीं करता। ऐसे रूप W3C के JSON-LD कॉन्टेक्स्ट विनिर्देश के अनुसार मान्य हो सकते हैं। इकाई कई प्रकार घोषित करती हो तो प्रॉपर्टी की जाँच चलने के लिए सभी प्रकार समर्थित समूह में होने चाहिए।
कवरेज की सीमाएँ भी हैं। जाँचकर्ता पहले ५० JSON-LD ब्लॉक देखता है और अमान्य ब्लॉक की पंक्तियों सहित अधिकतम ५०० परिणाम पंक्तियाँ रखता है। ३२ नेस्टिंग स्तरों से आगे या हर ब्लॉक में १०,००० देखे गए मानों के बाद संरचना में आगे बढ़ना रुक जाता है। इससे बाद की इकाइयाँ बिना जाँच के रह सकती हैं। HTML में Microdata या RDFa मिलना भी रिपोर्ट को आंशिक बनाता है, क्योंकि ये फ़ॉर्मैट यहाँ सत्यापित नहीं होते।
बड़े चिपकाए इनपुट को पूरे JSON-LD ब्लॉक में बाँटकर अलग-अलग जाँचें। ऑब्जेक्ट बीच में काटकर नई सिंटैक्स त्रुटि न बनाएँ। मूल स्रोत रखें और बताएँ कि हर रिपोर्ट किन हिस्सों को शामिल करती है। ये अलग जाँचें अपने आप पूरे पृष्ठ के ऑडिट में नहीं जुड़तीं।
मार्कअप सुधारने के बाद पृष्ठ सत्यापित करें
पहले मार्कअप को उस जानकारी से मिलाएँ जो उपयोगकर्ता पृष्ठ पर पढ़ सकता है। पहचान, तारीख, पते, उत्पाद विवरण और समीक्षा वास्तविक सामग्री से जाँचें। Google के संरचित डेटा दिशानिर्देश प्रासंगिक, सही जानकारी और लागू फ़ीचर आवश्यकताओं का पालन माँगते हैं; पार्सर उन तथ्यों की पुष्टि नहीं कर सकता। प्रॉपर्टी की चेतावनी हटाने के लिए काल्पनिक विवरण न जोड़ें।
अनसुलझे प्रश्न के अनुसार अगली जाँच चुनें। Microdata और RDFa सहित व्यापक Schema.org मार्कअप जाँच के लिए Schema.org Markup Validator इस्तेमाल करें। इसकी भी सीमाएँ हैं: यह दूसरे कॉन्टेक्स्ट URL प्राप्त या व्याख्या नहीं करता। समर्थित Google खोज फ़ीचर और उनकी बताई गई त्रुटियाँ या चेतावनियाँ देखने के लिए Google का Rich Results Test इस्तेमाल करें। परीक्षण पास होने से Google पर रिच रिज़ल्ट दिखना सुनिश्चित नहीं होता।
व्यवसाय मार्कअप तैयार कर रहे हों तो स्थानीय व्यवसाय Schema जनरेटर आपके वास्तविक विवरण से JSON-LD बना सकता है। प्रकाशित करने से पहले आउटपुट पढ़ें। विशिष्ट व्यवसाय प्रकार और नेस्टेड PostalAddress ऑब्जेक्ट इस जाँचकर्ता में असमर्थित रह सकते हैं; बनाना और चुना हुआ सत्यापन अलग काम हैं।
सुधार लागू करने के बाद केवल ड्राफ़्ट पर नहीं, प्रकाशित पृष्ठ पर संबंधित जाँच फिर चलाएँ। पुष्टि करें कि भेजे गए मार्कअप में इच्छित बदलाव है और बचे निष्कर्षों की तुलना करें। उस जाँच के ब्लॉक नंबर, इकाई पथ, निष्कर्ष और कवरेज सुरक्षित रखने के लिए JSON डाउनलोड करें इस्तेमाल करें। निर्यात के साथ इनपुट और दायरा रखें ताकि दूसरा समीक्षक प्रमाण समझ सके। सुरक्षित रिपोर्ट एक जाँच का रिकॉर्ड है; यह भविष्य में टेमप्लेट या सामग्री के बदलाव लगातार नहीं देखती।