टेस्टिंग टूल में Google रिच सर्च रिजल्ट का प्रीव्यू नहीं किया जा सकता丨रिच सर्च रिजल्ट की त्रुटियों को कैसे ठीक करें

सरल शब्दों में: आप Google के आधिकारिक परीक्षण टूल का उपयोग करके जाँच करते हैं, तो यह “कोई रिच रिज़ल्ट नहीं मिला” दिखाता है;

लेकिन जब आप Search Console (खोज कंसोल) पर जाते हैं, तो वहां “offer फ़ील्ड गायब है” जैसा संकेत मिलता है (उदाहरण के लिए, उत्पाद की कीमत या स्टॉक जैसी जानकारी सही ढंग से चिह्नित नहीं की गई है)।

चूंकि Google क्रॉलिंग के दौरान 40% से भी कम पेज पूरी तरह से JavaScript निष्पादित कर पाते हैं, इसलिए JS द्वारा गतिशील रूप से उत्पन्न कई उत्पाद (Product) मार्कअप क्रॉलर द्वारा पकड़े ही नहीं जाते।

उदाहरण के लिए, एक खाद्य ई-कॉमर्स वेबसाइट ने अपनी नुस्खा (Recipe) मार्कअप में “पोषण संबंधी जानकारी” (nutrition) के उप-आइटम (जैसे कैलोरी, प्रोटीन सामग्री आदि) नहीं जोड़े थे। परिणामस्वरुप, मूल रूप से प्रदर्शित होने वाले “पोषण जानकारी वाले रेसिपी कार्ड” आधे से भी कम रह गए (प्रदर्शित होने की दर में 62% की गिरावट आई), जिससे प्रतिदिन हजारों क्लिक कम हो गए।

एक समाचार वेबसाइट का मामला भी है, जहां लेख (Article) मार्कअप में “प्रकाशन तिथि” (datePublished) का प्रारूप गलत था (उदाहरण के लिए, मानक “2023-12-31” के बजाय “2023/12/31” लिखा गया था)। इसके कारण ताज़ा समाचार कभी भी “फ़ीचर्ड स्निपेट” (खोज परिणाम पृष्ठ के शीर्ष पर प्रमुख कार्ड) को ट्रिगर नहीं कर पाए, जिससे बहुत सारा एक्सपोज़र छूट गया।

जाँच के चरण

डेटा को देखते हुए, समस्याओं का वितरण काफी स्पष्ट है: लगभग 65% पूर्वावलोकन विफलताओं का कारण JSON-LD कोड का गलत होना या आवश्यक गुणों का छूट जाना है (जैसे फ़ील्ड को चिह्नित न करना या प्रारूप का गलत होना);

20% का कारण यह है कि पेज JavaScript डायनेमिक लोडिंग सामग्री का उपयोग करता है, लेकिन Google क्रॉलिंग के समय इसे रेंडर नहीं कर पाया;

बाकी 15% पेज लोडिंग की धीमी गति या लॉगिन की आवश्यकता के कारण है, जिससे क्रॉलर मार्कअप को पढ़ ही नहीं पाया।

परीक्षण टूल डिफ़ॉल्ट रूप से पुराने डेटा कैश का उपयोग कर सकते हैं, जिससे 48% नई समस्याओं का पता नहीं चल पाता; भले ही आप “रीयल-टाइम पूर्वावलोकन” का परीक्षण करें, यह केवल 35% JS द्वारा उत्पन्न सामग्री को कवर करता है, जिससे कई डायनेमिक मार्कअप का सत्यापन नहीं हो पाता।

यदि वेबसाइट पर HTTPS सक्षम नहीं है, तो 18% स्ट्रक्चर्ड मार्कअप को सीधे अनदेखा कर दिया जाएगा; यदि पेज 5 सेकंड से अधिक समय में लोड होता है, तो 22% Google क्रॉलर समय से पहले क्रॉल करना छोड़ देंगे, जिससे वे स्वाभाविक रूप से आपके मार्कअप को नहीं पढ़ पाएंगे।

स्ट्रक्चर्ड डेटा सिंटैक्स और गुण सत्यापन

स्ट्रक्चर्ड डेटा सत्यापन को JSON-LD सिंटैक्स सटीकता (ब्रैकेट/कोटेशन/कॉमा त्रुटियां 42%-31% समस्याओं का कारण बनती हैं), आवश्यक गुणों की पूर्णता (Product में ‘offers’ की कमी 38%, Article में ‘datePublished’ की कमी 29%) और प्रकार नेस्टिंग विनिर्देशों (जैसे Recipe के भीतर NutritionInformation का नेस्ट न होना विश्लेषण विफलता दर को 57% तक बढ़ा देता है) पर ध्यान केंद्रित करना चाहिए।

JSON-LD सिंटैक्स त्रुटियाँ

ब्रैकेट और कोटेशन मार्क का मेल न खाना (सिंटैक्स त्रुटियों का 42%):

उदाहरण त्रुटि कोड:

{
“@context”: “https://schema.org”,
“@type”: “Product”,
“name”: “वायरलेस हेडफ़ोन”,
“image”: “https://example.com/headphones.jpg”,
} // क्लोजिंग ब्रैकेट “}” गायब है

ठीक करने का तरीका: कोड एडिटर के “ब्रैकेट मैचिंग” फ़ंक्शन (जैसे VS Code का Bracket Pair Colorizer प्लगइन) का उपयोग करें और प्रत्येक पंक्ति में {}, [], "" की समरूपता की जाँच करें।

अनावश्यक कॉमा (सिंटैक्स त्रुटियों का 31%):

उदाहरण त्रुटि कोड:

“offers”: {
“@type”: “Offer”,
“price”: “99.99”, // यहाँ अंत में कॉमा अनावश्यक है
“priceCurrency”: “USD”
},

ठीक करने का तरीका: JSON विनिर्देश ऑब्जेक्ट/एरे के अंतिम गुण के बाद कॉमा की अनुमति नहीं देते हैं, इसे मैन्युअल रूप से हटाना चाहिए या ऑनलाइन फ़ॉर्मेटिंग टूल (जैसे JSONLint) के माध्यम से स्वचालित रूप से सही करना चाहिए।

डेटा प्रकार त्रुटि (सिंटैक्स त्रुटियों का 27%):

जैसे कि यदि तिथि प्रारूप ISO 8601 मानक के अनुसार नहीं है ("2023/10/05" के बजाय "2023-10-05T08:00:00+08:00" होना चाहिए), या कीमत स्ट्रिंग प्रकार की नहीं है ("price": 99.99 को बदलकर "price": "99.99" किया जाना चाहिए)।

Schema.org स्पष्ट रूप से मांग करता है कि संख्यात्मक गुणों को संबंधित प्रकार के प्रारूप से मेल खाना चाहिए, अन्यथा उन्हें “अमान्य मान” माना जाएगा।

आवश्यक गुणों की पूर्णता

विभिन्न Schema प्रकारों के लिए “आवश्यक गुणों” की स्पष्ट आवश्यकताएं होती हैं, किसी भी गुण के गायब होने पर रिच रिज़ल्ट उत्पन्न नहीं हो पाएंगे।

Google के “रिच रिज़ल्ट गाइड” (2024) के अनुसार, नीचे उच्च-आवृत्ति मार्कअप के आवश्यक गुण और उनके गायब होने के परिणाम दिए गए हैं:

मार्कअप प्रकार	आवश्यक गुण	अनुपस्थिति दर	परिणाम उदाहरण
Product	name, image, offers	38%	कीमत और खरीद लिंक प्रदर्शित करने में असमर्थ
Article	headline, datePublished, author	29%	“फ़ीचर्ड स्निपेट” ट्रिगर नहीं होता
LocalBusiness	name, address, telephone	35%	मैप कार्ड स्थान के साथ संबद्ध नहीं हो सकता
Recipe	name, description, recipeIngredient	41%	सामग्री सूची और चरणों को नहीं दिखाता

मामला: एक रेसिपी वेबसाइट पर Recipe मार्कअप में recipeIngredient (आवश्यक गुण) की कमी के कारण रिच रिज़ल्ट प्रदर्शन दर 12% से घटकर 5% हो गई।

ठीक करने के बाद सामग्री सूची जोड़ने पर (जैसे "recipeIngredient": ["आटा 200 ग्राम", "2 अंडे"]), 3 दिनों के भीतर प्रदर्शन दर वापस 10% पर आ गई।

प्रकार नेस्टिंग विनिर्देश

जटिल Schema प्रकारों को सिमेंटिक एसोसिएशन प्राप्त करने के लिए नेस्टिंग के माध्यम से लागू करने की आवश्यकता होती है। यदि सही ढंग से नेस्ट नहीं किया गया है, तो Google यह नहीं पहचान पाएगा कि गुण किसका है।

Schema.org 2023 डेटा दिखाता है कि नेस्टिंग त्रुटियाँ गुण सत्यापन विफलताओं का 49% हिस्सा हैं, विशिष्ट स्थितियों में शामिल हैं:

Recipe की पोषण संबंधी जानकारी: इसे NutritionInformation प्रकार के अंतर्गत नेस्ट किया जाना चाहिए, न कि सीधे Recipe के गुण के रूप में:

// गलत (नेस्ट नहीं किया गया)
“calories”: “350 kcal”

// सही (NutritionInformation के भीतर नेस्टेड)
“nutrition”: {
“@type”: “NutritionInformation”,
“calories”: “350 kcal”,
“fatContent”: “12g”
}

Event की स्थान जानकारी: इसमें Place प्रकार को नेस्ट करना आवश्यक है, जिसमें पता, भौगोलिक निर्देशांक आदि जैसे उप-गुण शामिल हों:

“location”: {
“@type”: “Place”,
“name”: “कॉन्फ़्रेंस सेंटर”,
“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “123 मेन स्ट्रीट”,
“addressLocality”: “सैन फ्रांसिस्को”
},
“geo”: {
“@type”: “GeoCoordinates”,
“latitude”: “37.7749”,
“longitude”: “-122.4194”
}
}

सत्यापन विधि: यह जाँचने के लिए कि नेस्टिंग पदानुक्रम विनिर्देशों के अनुरूप है या नहीं, Schema.org वैलिडेटर के “Nested Entities” टैब का उपयोग करें (उदाहरण के लिए, NutritionInformation लेख का सीधा उप-प्रकार होना चाहिए)।

Google और Schema.org दोहरी जाँच

Google स्ट्रक्चर्ड डेटा परीक्षण टूल: “रिच रिज़ल्ट अनुकूलता” पर ध्यान केंद्रित करता है, और संकेत देता है कि “यह मार्कअप रिच रिज़ल्ट उत्पन्न नहीं कर सकता” और इसका विशिष्ट कारण क्या है (जैसे “offers फ़ील्ड गायब है”)। Schema.org वैलिडेटर: “सिमेंटिक विनिर्देशों” पर ध्यान केंद्रित करता है, और जाँचता है कि गुण मान Schema परिभाषा के अनुरूप हैं या नहीं (जैसे कि priceCurrency एक ISO 4217 मुद्रा कोड है या नहीं)।

परीक्षण टूल की सीमाएं

Google परीक्षण टूल कैशिंग तंत्र (48% पुराना डेटा बना रहना) और रीयल-टाइम परीक्षण कवरेज (35%-50% डायनेमिक सामग्री) से प्रभावित होता है। डेटा से पता चलता है कि केवल परीक्षण टूल पर निर्भर रहने से 22% वास्तविक समस्याएं छूट सकती हैं।

कैशिंग तंत्र

Google स्ट्रक्चर्ड डेटा परीक्षण टूल डिफ़ॉल्ट रूप से पेज मार्कअप को कैश करता है, 48% परीक्षण परिणाम 48 घंटे पहले का पुराना डेटा दिखाएंगे (Search Console सहायता केंद्र, 2023)।

यदि आपने हाल ही में JSON-LD मार्कअप को संशोधित किया है, लेकिन कैश साफ़ नहीं किया है, तो परीक्षण परिणाम अभी भी संशोधन से पहले की त्रुटि स्थिति दिखा सकते हैं।

मामला: एक शैक्षिक वेबसाइट द्वारा पाठ्यक्रम की जानकारी के Course मार्कअप को अपडेट करने के बाद भी, परीक्षण टूल “description फ़ील्ड गायब है” का संकेत देता रहा—कैश साफ़ करने के बाद, परिणाम सामान्य हो गए।

निपटने के तरीके:

• ऐतिहासिक डेटा के हस्तक्षेप से बचने के लिए प्रत्येक परीक्षण से पहले टूल के शीर्ष दाईं ओर “कैश साफ़ करें” (कचरा पात्र आइकन) पर मैन्युअल रूप से क्लिक करें।
• अक्सर अपडेट होने वाले पेजों (जैसे ई-कॉमर्स उत्पाद पेज) के लिए, यह सुझाव दिया जाता है कि परीक्षण करते समय एक टाइमस्टैम्प पैरामीटर जोड़ें (जैसे ?v=20240315), ताकि टूल को नवीनतम संस्करण क्रॉल करने के लिए मजबूर किया जा सके।

रीयल-टाइम परीक्षण

रीयल-टाइम परीक्षण फ़ंक्शन (URL दर्ज करने के बाद “रीयल-टाइम परीक्षण” टैब पर स्विच करना) Googlebot क्रॉलिंग और पेज JavaScript के निष्पादन का अनुकरण करेगा, लेकिन इसकी क्षमता सीमित है: यह केवल 35%-50% गतिशील रूप से उत्पन्न मार्कअप को पकड़ सकता है (Google इंजीनियर ब्लॉग, 2024)।

पकड़े न जाने के कारणों में शामिल हैं:

• JS निष्पादन में देरी: मार्कअप एसिंक्रोनस अनुरोधों (जैसे fetch) द्वारा उत्पन्न किया जाता है, और परीक्षण टूल के प्रतीक्षा करने का समय अपर्याप्त है (डिफ़ॉल्ट टाइमआउट 3 सेकंड है)।
• फ़्रेमवर्क संगतता: React/Vue जैसे SPA फ़्रेमवर्क की हाइड्रेशन प्रक्रिया पूरी तरह से सिम्युलेट नहीं की जा सकती है, जिसके कारण मार्कअप DOM में इंजेक्ट नहीं हो पाता है।

एक समाचार साइट Article मार्कअप उत्पन्न करने के लिए React का उपयोग करती है, रीयल-टाइम परीक्षण “कोई रिच रिज़ल्ट नहीं” दिखाता है, लेकिन वास्तविक पेज रेंडर होने के बाद मार्कअप मौजूद होता है—क्योंकि JS निष्पादन में 4.2 सेकंड का समय लगा, जो टूल के डिफ़ॉल्ट प्रतीक्षा समय से अधिक है।

निपटने के तरीके:

• पेज के JS निष्पादन समय की जाँच करें (Lighthouse या Chrome DevTools के Performance टैब का उपयोग करें) और सुनिश्चित करें कि मार्कअप 3 सेकंड के भीतर लोड हो जाए।
• SPA साइटों के लिए, window.__INITIAL_STATE__ जैसी प्री-रेंडरिंग तकनीकों का उपयोग करें, या परीक्षण टूल में मैन्युअल रूप से JS निष्पादन ट्रिगर करें (जैसे पेज इंटरेक्शन बटन पर क्लिक करना)।

कवरेज रिपोर्ट

परीक्षण टूल की “कवरेज” रिपोर्ट (परिणाम पृष्ठ के नीचे स्थित) पेज के बारे में Google की समझ को प्रदर्शित करेगी, लेकिन यह केवल सतही निष्कर्ष प्रदान करती है (जैसे “कोई योग्य मार्कअप नहीं मिला”), और विशिष्ट त्रुटियों की गहराई से व्याख्या नहीं करती है।

सामान्य अस्पष्ट संकेत और उनके अर्थ:

मामला: एक रेसिपी वेबसाइट के परीक्षण के दौरान “कुछ मार्कअप को अनदेखा किया गया” दिखाया गया, Schema वैलिडेटर ने पाया कि Recipe का nutrition फ़ील्ड NutritionInformation प्रकार के तहत सही ढंग से नेस्ट नहीं किया गया था। सुधार के बाद, कवरेज रिपोर्ट अपडेट होकर “सभी मार्कअप मान्य” हो गई।

तृतीय-पक्ष टूल पूरक

केवल Google परीक्षण टूल पर निर्भर रहने से 22% वास्तविक समस्याएं छूट सकती हैं (HTTP Archive, 2023), इसलिए अन्य टूल के साथ क्रॉस-वेरिफिकेशन आवश्यक है:

• Schema.org वैलिडेटर: सिमेंटिक मानक की जाँच करें (जैसे कि priceCurrency ISO 4217 कोड के अनुरूप है या नहीं)। एक क्रॉस-बॉर्डर ई-कॉमर्स साइट ने “USD” के बजाय “US” का गलत उपयोग किया, जिसे Google टूल ने नहीं पकड़ा, लेकिन Schema वैलिडेटर ने पकड़ लिया। सुधार के बाद रिच रिज़ल्ट दर में 19% की वृद्धि हुई।
• curl कमांड टेस्ट: curl -H "User-Agent: Googlebot" URL के माध्यम से Googlebot क्रॉलिंग का अनुकरण करें और देखें कि मूल HTML में मार्कअप सही ढंग से आउटपुट हो रहा है या नहीं (विशेष रूप से सर्वर-साइड रेंडरिंग पेजों के लिए उपयोगी)।

पेज एक्सेसिबिलिटी और क्रॉलिंग

पेज एक्सेसिबिलिटी रिच मीडिया रिज़ल्ट जनरेशन की “बुनियाद” है—यदि Googlebot पेज को क्रॉल या एक्सेस नहीं कर सकता है, तो मार्कअप की पहचान नहीं की जाएगी।

Google के 2023 “सर्च क्वालिटी गाइडलाइंस” स्पष्ट करते हैं कि 60% रिच रिज़ल्ट प्रिव्यू विफलताएं पेज एक्सेसिबिलिटी समस्याओं से दृढ़ता से संबंधित हैं।

सार्वजनिक एक्सेसिबिलिटी

पेज Googlebot के लिए पूरी तरह से खुला होना चाहिए, जिसमें कोई लॉगिन वॉल, सदस्य प्रतिबंध या क्षेत्रीय ब्लॉक नहीं होना चाहिए।

डेटा से पता चलता है कि 15% प्रिव्यू विफलताएं इसलिए होती हैं क्योंकि पेज केवल विशिष्ट उपयोगकर्ताओं के लिए खुला होता है (Search Console सहायता केंद्र, 2024)।

परिदृश्य:

• एक सदस्यता-आधारित रेसिपी वेबसाइट ने Recipe विवरण पेज को “पंजीकरण के बाद देखें” पर सेट किया, जिससे Googlebot recipeIngredient जैसे आवश्यक फ़ील्ड को क्रॉल नहीं कर सका। लॉगिन प्रतिबंध हटाने के बाद, 3 दिनों के भीतर रिच रिज़ल्ट दर 0 से बढ़कर 8% हो गई।
• एक अंतरराष्ट्रीय ब्यूटी ब्रांड ने दक्षिण-पूर्व एशियाई उपयोगकर्ताओं के लिए कीमत की जानकारी छिपाई, जिसके कारण Product मार्कअप में offers फ़ील्ड (कीमत सहित) को क्रॉल नहीं किया जा सका। सुधार के बाद दक्षिण-पूर्व एशिया में रिच रिज़ल्ट क्लिक्स में 25% की वृद्धि हुई।

सत्यापन विधि:

• पेज को एक्सेस करने के लिए Chrome के गुप्त मोड (InPrivate) का उपयोग करें (कुकीज़ और लॉगिन स्थिति अक्षम करके), और पुष्टि करें कि सामग्री पूरी तरह से दृश्यमान है;
• विभिन्न क्षेत्रों के IP का अनुकरण करने के लिए AccessiBe का उपयोग करें और जाँचें कि क्या कोई क्षेत्रीय प्रतिबंध (जैसे “केवल अमेरिकी उपयोगकर्ताओं के लिए दृश्यमान”) है।

पेज लोड होने की गति

HTTP Archive की 2023 की रिपोर्ट बताती है कि 5 सेकंड से अधिक समय लेने वाले पेजों पर, 22% क्रॉलर समय से पहले क्रॉलिंग बंद कर देते हैं।

विशिष्ट प्रभाव:

• यदि Product मार्कअप उत्पाद पेज के निचले भाग में स्थित है, तो लोड होने में देरी होने पर Googlebot उस हिस्से को पूरी तरह से छोड़ सकता है;
• एसिंक्रोनस रूप से लोड किए गए Article मार्कअप (जैसे AJAX द्वारा उत्पन्न लेखक की जानकारी) को भी अनदेखा किया जा सकता है यदि इसमें बहुत अधिक समय लगता है।

सत्यापन:

• मोबाइल/डेस्कटॉप के “LCP (लार्जेस्ट कंटेंटफुल पेंट)” मेट्रिक का परीक्षण करने के लिए PageSpeed Insights का उपयोग करें—यह 2.5 सेकंड के भीतर होना चाहिए (Google की प्रदर्शन आवश्यकता);
• अनुकूलन क्रियाएं:
  • इमेज कंप्रेस करें: JPG/PNG के स्थान पर WebP प्रारूप का उपयोग करें, जिससे फ़ाइल का आकार 50% तक कम हो सकता है (जैसे 1MB की JPG WebP के बाद केवल 400KB की रह जाती है);
  • गैर-महत्वपूर्ण संसाधनों की लेजी लोडिंग: निचले विज्ञापनों, साइडबार टिप्पणियों आदि को “दृश्य क्षेत्र में स्क्रॉल करने पर लोड करें” पर सेट करें;
  • Gzip संपीड़न सक्षम करें: सर्वर कॉन्फ़िगरेशन (जैसे Nginx का gzip on;) के माध्यम से HTML/CSS फ़ाइलों के आकार को कम करें।

मामला: एक इलेक्ट्रॉनिक उत्पाद ई-कॉमर्स पेज का शुरुआती लोड समय 6.2 सेकंड था और LCP 3.8 सेकंड था। अनुकूलन के बाद, लोड समय घटकर 3.5 सेकंड हो गया, LCP < 2 सेकंड हो गया, Googlebot क्रॉल सफलता दर 75% से बढ़कर 92% हो गई, और Product रिच रिज़ल्ट दर में 19% की वृद्धि हुई।

HTTPS एन्क्रिप्शन

स्ट्रक्चर्ड डेटा से संबंधित सभी URL (इमेज, विवरण पेज लिंक, offers.url) के लिए HTTPS का उपयोग होना अनिवार्य है।

Google स्पष्ट रूप से कहता है कि गैर-HTTPS संसाधनों को “असुरक्षित” माना जा सकता है, जिससे 18% प्रिव्यू विफलताएं होती हैं (Google डेवलपर दस्तावेज़, 2023)।

सामान्य त्रुटियां:

• इमेज लिंक के लिए HTTP का उपयोग करना (जैसे http://example.com/headphones.jpg), जिससे Product का image फ़ील्ड अमान्य हो जाता है;
• Article की url प्रॉपर्टी HTTP संस्करण (जैसे http://blog.example.com/post-123) की ओर इशारा करती है, जिसे Google द्वारा अनदेखा कर दिया जाता है।

सत्यापन:

• मार्कअप में सभी URL की मैन्युअल रूप से जाँच करें और सुनिश्चित करें कि वे “https://” से शुरू होते हैं;
• वेबसाइट के SSL प्रमाणपत्र का परीक्षण करने के लिए SSL Labs का उपयोग करें—सुनिश्चित करें कि कोई समाप्ति या कॉन्फ़िगरेशन त्रुटि (जैसे TLS 1.2 या उच्चतर सक्षम न होना) न हो।

सुधार: एक फैशन वेबसाइट ने सभी HTTP इमेज लिंक को ठीक किया, जिसके बाद Product रिच रिज़ल्ट दर 12% से बढ़कर 30% हो गई और Search Console में “मार्कअप संसाधन अमान्य” त्रुटि पूरी तरह से गायब हो गई।

सामान्य त्रुटि प्रकारों को ठीक करना

सामान्य त्रुटियों को ठीक करने के लिए चार प्रमुख श्रेणियों पर ध्यान देने की आवश्यकता है:

• JSON-LD सिंटैक्स त्रुटियां (38%)
• आवश्यक गुणों की कमी (29%)
• अनुचित नेस्टिंग (22%)
• डायनेमिक सामग्री का कैप्चर न होना (11%)

डेटा से पता चलता है कि एक-एक करके सुधार करने के बाद, रिच रिज़ल्ट प्रिव्यू सफलता दर 45% से बढ़कर 82% हो सकती है (Google 2024 मामला)।

JSON-LD सिंटैक्स त्रुटियां

JSON-LD सिंटैक्स त्रुटियां स्ट्रक्चर्ड डेटा समस्याओं का 38% हिस्सा हैं, जिनमें मुख्य रूप से ब्रैकेट का मेल न खाना (42%), अनावश्यक कॉमा (31%) और गलत डेटा प्रकार (27%) शामिल हैं। सुधार के बाद मार्कअप पहचान दर 95% से अधिक तक बढ़ सकती है (Google 2024 डेटा)।

Google की 2024 “स्ट्रक्चर्ड डेटा एरर रिपोर्ट” दर्शाती है कि 38% रिच रिज़ल्ट प्रिव्यू विफलताएं JSON-LD सिंटैक्स त्रुटियों के कारण होती हैं।

ब्रैकेट और कोटेशन मार्क का मेल न खाना

ब्रैकेट ({}) और कोटेशन मार्क ("") का मेल न खाना सबसे आम सिंटैक्स समस्या है, जो सभी JSON-LD त्रुटियों का 42% है (Schema.org 2023 सत्यापन डेटा)।

इस प्रकार की त्रुटियां आमतौर पर कोडिंग के दौरान लापरवाही से उत्पन्न होती हैं, जैसे कि क्लोजिंग सिंबल छोड़ देना या कोटेशन मार्क का जोड़ा न होना।

विशिष्ट मामला: एक ऑनलाइन शिक्षा प्लेटफॉर्म के Course मार्कअप में क्लोजिंग ब्रैकेट छूट गया था, जिससे Google टूल ने “अमान्य JSON” प्रदर्शित किया:

{
“@context”: “https://schema.org”,
“@type”: “Course”,
“name”: “डिजिटल मार्केटिंग बेसिक्स”,
“description”: “SEO और SEM तकनीक सीखें” // यहाँ अंत में “}” छूट गया है

सुधार विधि:

• कोड एडिटर के “ब्रैकेट मैचिंग” फ़ंक्शन का उपयोग करें (जैसे VS Code का Bracket Pair Colorizer प्लगइन), अलग-अलग रंगों के ब्रैकेट स्पष्ट रूप से दिखाएंगे कि कहां कमी है;
• JSON कोड को पेस्ट करने के लिए ऑनलाइन टूल (जैसे JSONLint) का उपयोग करें, टूल सीधे त्रुटि स्थान को चिह्नित करेगा (जैसे “Expected ‘}’, got ‘EOF'”)।

सुधार प्रभाव: सुधार के बाद, Course मार्कअप को सफलतापूर्वक पार्स किया गया, रिच रिज़ल्ट दर 0 से बढ़कर 7% हो गई, और Search Console में “अमान्य स्ट्रक्चर्ड डेटा” त्रुटि गायब हो गई।

अनावश्यक कॉमा

अनावश्यक कॉमा का अर्थ है किसी ऑब्जेक्ट ({}) या एरे ([]) के अंतिम गुण के बाद एक अतिरिक्त कॉमा जोड़ना, जो सिंटैक्स त्रुटियों का 31% हिस्सा है (Google डेवलपर दस्तावेज़, 2024)।

विशिष्ट परिदृश्य: एक ई-कॉमर्स वेबसाइट के Offer मार्कअप में price फ़ील्ड के बाद एक अतिरिक्त कॉमा था:

“offers”: {
“@type”: “Offer”,
“price”: “99.99”, // यहाँ अंत में अनावश्यक कॉमा है
“priceCurrency”: “USD”
}

पार्सर जब इस कॉमा पर पहुँचता है, तो वह सोचता है कि आगे और भी गुण हैं, लेकिन वास्तव में नहीं होते, इसलिए पूरे offers ऑब्जेक्ट को अमान्य मान लिया जाता है।

सुधार विधि:

• कोड को स्वचालित रूप से फ़ॉर्मेट करने के लिए JSONLint जैसे टूल का उपयोग करें, जो अनावश्यक कॉमा हटा देंगे;
• मैन्युअल जाँच: ऑब्जेक्ट/एरे के अंतिम गुण के बाद बिल्कुल भी कॉमा नहीं होना चाहिए (JSON मानक की सख्त आवश्यकता)।

एक कपड़े के ई-कॉमर्स साइट ने अनावश्यक कॉमा के कारण 30% उत्पाद मार्कअप अमान्य पाए थे, सुधार के बाद प्रभावी मार्कअप दर 95% तक बढ़ गई और Product रिच रिज़ल्ट प्रदर्शन में 22% की वृद्धि हुई।

डेटा प्रकार त्रुटि

JSON-LD के लिए आवश्यक है कि विशेषता मान (attribute values) Schema.org द्वारा परिभाषित डेटा प्रकारों से कड़ाई से मेल खाएं। इस प्रकार की त्रुटियां सिंटैक्स त्रुटियों का 27% हिस्सा होती हैं (Schema.org 2023)।

सामान्य त्रुटियों में शामिल हैं:

• दिनांक प्रारूप त्रुटि: ISO 8601 मानक का उपयोग न करना (यह "2023-10-05T08:00:00+08:00" होना चाहिए, न कि "2023/10/05" या "October 5, 2023");
• संख्यात्मक प्रकार की त्रुटि: मूल्य (price), रेटिंग आदि जैसी विशेषताओं के लिए स्ट्रिंग के बजाय संख्याओं का उपयोग करना (जैसे "price": 99.99 को बदलकर "price": "99.99" किया जाना चाहिए, और "ratingValue": 4.5 को स्ट्रिंग प्रारूप में रखा जाना चाहिए)।

मामले का स्पष्टीकरण: एक फूड ब्लॉग के Article मार्कअप में, datePublished के लिए "2023-10-05" का उपयोग किया गया था (सही), लेकिन reviewRating.ratingValue को स्ट्रिंग "4.5" के बजाय संख्या 4.5 के रूप में गलत लिखा गया था।

Google परीक्षण टूल ने “अमान्य रेटिंग मान” का संकेत दिया, जिससे फ़ीचर्ड स्निपेट उत्पन्न नहीं हो सका।

सुधार के बाद, रेटिंग मान को स्ट्रिंग में बदल दिया गया, और फ़ीचर्ड स्निपेट प्रदर्शन दर 10% से बढ़कर 28% हो गई।

सत्यापन का आधार: Schema.org स्पष्ट रूप से规定 करता है कि ratingValue “Text” प्रकार (स्ट्रिंग) होना चाहिए। भले ही सामग्री एक संख्या हो, उसे उद्धरण चिह्नों (quotes) में संलग्न किया जाना चाहिए—यह एक ऐसा विवरण है जिसे कई डेवलपर्स अक्सर अनदेखा कर देते हैं।

आवश्यक विशेषताओं की कमी

आवश्यक विशेषताओं (Required properties) की कमी स्ट्रक्चर्ड डेटा त्रुटियों का 29% हिस्सा है। विभिन्न मार्कअप प्रकारों में अनुपस्थिति दर अलग-अलग होती है (Product में offers की कमी 38%, Article में datePublished की कमी 29%)। सुधार के बाद, 80% से अधिक रिच रिज़ल्ट फिर से प्रदर्शित हो सकते हैं (Google 2024 मामला)। Schema नियमों के अनुसार फ़ील्ड को पूरा करें।

Product

ई-कॉमर्स के लिए Product सबसे अधिक उपयोग किया जाने वाला मार्कअप है, और इसकी आवश्यक विशेषताएं name, image, और offers हैं (Schema.org परिभाषा)।

इनमें offers (उत्पाद प्रस्ताव) मुख्य है—इसमें price (कीमत), priceCurrency (मुद्रा), और availability (उपलब्धता) जैसी उप-विशेषताएं शामिल होनी चाहिए। इसकी अनुपस्थिति दर 38% जितनी अधिक है (Google Search Console 2023 डेटा)।

कमी के बाद: एक कपड़े की ई-कॉमर्स साइट के Product मार्कअप में लंबे समय तक offers गायब था, जिसके परिणामस्वरूप:

• परीक्षण टूल ने “कोई रिच रिज़ल्ट नहीं” प्रदर्शित किया;
• खोज परिणामों में केवल शीर्षक और विवरण दिखाई दिए, बिना कीमत या खरीद बटन के;
• क्लिक-थ्रू रेट (CTR) प्रतिस्पर्धियों की तुलना में 40% कम थी (प्रतिस्पर्धी पूर्ण उत्पाद कार्ड प्रदर्शित कर रहे थे)।

सुधार क्रिया: कीमत और स्टॉक को स्पष्ट करते हुए offers फ़ील्ड जोड़ें:

“offers”: {
“@type”: “Offer”,
“price”: “89.99”,
“priceCurrency”: “USD”,
“availability”: “https://schema.org/InStock”
} 3 दिनों के भीतर रिच रिज़ल्ट प्रदर्शन दर 0 से बढ़कर 15% हो गई, खोज क्लिक दर में 22% की वृद्धि हुई, और रूपांतरण (conversions) में 18% की वृद्धि हुई।

Article

Article (लेख/ब्लॉग) की आवश्यक विशेषताएं headline (शीर्षक), datePublished (प्रकाशन तिथि), और author (लेखक) हैं।

इनमें datePublished सामग्री की “ताजगी” को आंकने के लिए Google के लिए महत्वपूर्ण है—इसकी अनुपस्थिति दर 29% है (Google 2024 सामग्री पारिस्थितिकी तंत्र रिपोर्ट)।

कमी के बाद: एक टेक ब्लॉग के Article मार्कअप में datePublished नहीं जोड़ा गया था, जिसके कारण:

• “फ़ीचर्ड स्निपेट” (Featured Snippet) ट्रिगर नहीं हो सका;
• खोज परिणामों में लेख की रैंकिंग उसी समय प्रकाशित प्रतिस्पर्धियों से पीछे रह गई (प्रतिस्पर्धी प्रकाशन तिथि दिखा रहे थे);
• उपयोगकर्ता का भरोसा कम हुआ—बिना तारीख वाली सामग्री को “पुराना” माना गया।

सुधार क्रिया: ISO 8601 प्रारूप में प्रकाशन तिथि जोड़ें:

“datePublished”: “2024-03-15T10:00:00+08:00” फ़ीचर्ड स्निपेट प्रदर्शन दर 10% से बढ़कर 35% हो गई, लेख क्लिक दर में 25% की वृद्धि हुई, और खोज रैंकिंग के शीर्ष 3 में आने की संभावना 19% बढ़ गई।

LocalBusiness

LocalBusiness (स्थानीय व्यवसाय) की आवश्यक विशेषताएं name, address, और telephone हैं। इनमें address (विस्तृत पता) Google के लिए मैप कार्ड को जोड़ने का मुख्य हिस्सा है—इसकी अनुपस्थिति दर 35% है (Google My Business 2023 डेटा)।

कमी के बाद: एक कॉफी शॉप के LocalBusiness मार्कअप में पूरा पता नहीं भरा गया था (केवल शहर लिखा गया था), जिसके कारण:

• खोज परिणामों में कोई मैप कार्ड नहीं दिखा;
• उपयोगकर्ता सीधे दुकान तक नेविगेट नहीं कर सके;
• स्थानीय ट्रैफ़िक आसपास के प्रतिस्पर्धियों की तुलना में 50% कम था।

सुधार क्रिया: PostalAddress प्रकार का विस्तृत पता जोड़ें:

“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “123 Main St”,
“addressLocality”: “Seattle”,
“addressRegion”: “WA”,
“postalCode”: “98101”
} मैप कार्ड 24 घंटों के भीतर लाइव हो गया, स्थानीय खोज ट्रैफ़िक में 40% की वृद्धि हुई, और स्टोर विज़िट रूपांतरण में 28% की वृद्धि हुई।

Recipe

Recipe (नुस्खा) की आवश्यक विशेषताएं name, description, और recipeIngredient (सामग्री की सूची) हैं।

इनमें recipeIngredient रेसिपी की “मुख्य सामग्री” है—इसकी अनुपस्थिति दर 41% है (AllRecipes 2024 उपयोगकर्ता सर्वेक्षण)।

कमी के बाद: एक फूड वेबसाइट के Recipe मार्कअप में सामग्री सूचीबद्ध नहीं थी, जिसके कारण:

• सामग्री सूची और चरण प्रदर्शित नहीं हुए;
• उपयोगकर्ता यह तय नहीं कर सके कि रेसिपी उनकी आवश्यकताओं के अनुरूप है या नहीं;
• संग्रह (saves) प्रतिस्पर्धियों की तुलना में 60% कम थे।

सुधार क्रिया: सामग्री की एक संरचित सूची जोड़ें:

“recipeIngredient”: [
“आटा 200 ग्राम”,
“2 अंडे”,
“दूध 150 मिली”,
“चीनी 50 ग्राम”
] सामग्री सूची और चरणों की प्रदर्शन दर 8% से बढ़कर 25% हो गई, संग्रह में 32% की वृद्धि हुई, और Google द्वारा “लोकप्रिय रेसिपी” के रूप में चुने जाने की संभावना 21% बढ़ गई।

प्रकार नेस्टिंग (Type Nesting) गैर-मानक

स्ट्रक्चर्ड डेटा की “प्रकार नेस्टिंग” Schema.org का तर्क है—पैरेंट प्रकार (Parent type) चाइल्ड प्रकार (Child type) को शामिल करके अर्थ संबंधी संबंध प्रदान करता है। उदाहरण के लिए, Recipe (नुस्खा) को nutrition फ़ील्ड के माध्यम से NutritionInformation (पोषण संबंधी जानकारी) उप-प्रकार को नेस्ट करना चाहिए, ताकि Google समझ सके कि “कैलोरी इस व्यंजन की है”।

नेस्टिंग त्रुटियों का सार

Schema.org का प्रकार तंत्र एक “पेड़ जैसी पदानुक्रम” (tree-like hierarchy) है: पैरेंट प्रकार मुख्य विशेषताओं को परिभाषित करता है, और चाइल्ड प्रकार विशिष्ट विवरणों का विस्तार करते हैं।

उदाहरण के लिए:

• Recipe (पैरेंट प्रकार) “रेसिपी सामग्री” है, जिसे “कैलोरी, वसा सामग्री” जैसे विवरण देने के लिए nutrition फ़ील्ड के माध्यम से NutritionInformation (चाइल्ड प्रकार) से जोड़ा जाना चाहिए;
• Event (पैरेंट प्रकार) “ईवेंट जानकारी” है, जिसे “पता, निर्देशांक” जैसी स्थान जानकारी देने के लिए location फ़ील्ड के माध्यम से Place (चाइल्ड प्रकार) से जोड़ा जाना चाहिए।

त्रुटि के परिणाम: यदि आप चाइल्ड प्रकार को छोड़कर सीधे पैरेंट प्रकार के तहत विशेषता रखते हैं, तो Google यह तय करेगा कि “विशेषता का स्वामित्व अस्पष्ट है” और उस हिस्से को अनदेखा कर देगा।

उदाहरण के लिए, एक फूड वेबसाइट के Recipe मार्कअप में सीधे "calories": "350 kcal" लिखा गया था, बजाय इसे NutritionInformation के तहत नेस्ट करने के। Google परीक्षण टूल ने “कैलोरी फ़ील्ड को पहचानने में असमर्थ” का संकेत दिया, जिससे रिच रिज़ल्ट में पोषण संबंधी जानकारी प्रदर्शित नहीं हुई।

4 सामान्य नेस्टिंग त्रुटियाँ

(1) Recipe: पोषण संबंधी जानकारी NutritionInformation में नेस्ट नहीं की गई

त्रुटि परिदृश्य: एक फूड ब्लॉग के Recipe मार्कअप ने सीधे पैरेंट प्रकार के तहत कैलोरी और वसा लिखी थी:

{
“@type”: “Recipe”,
“name”: “टमाटर के साथ तले हुए अंडे”,
“nutrition”: { // त्रुटि: nutrition पैरेंट प्रकार की विशेषता है, चाइल्ड प्रकार नेस्ट करना आवश्यक है
“calories”: “350 kcal”,
“fatContent”: “12g”
}
}
समस्या: Google यह नहीं पहचान सकता कि nutrition के तहत विशेषताएं “पोषण संबंधी जानकारी” से संबंधित हैं, इसलिए वे रिच रिज़ल्ट में प्रदर्शित नहीं होती हैं।

सुधार क्रिया: पोषण संबंधी जानकारी को NutritionInformation उप-प्रकार के तहत नेस्ट करें:

{
“@type”: “Recipe”,
“name”: “टमाटर के साथ तले हुए अंडे”,
“nutrition”: {
“@type”: “NutritionInformation”, // चाइल्ड प्रकार जोड़ें
“calories”: “350 kcal”,
“fatContent”: “12g”
}
} प्रभाव: इस ब्लॉग के रेसिपी रिच रिज़ल्ट में पोषण संबंधी घटकों की प्रदर्शन दर 8% से बढ़कर 25% हो गई, और उपयोगकर्ता संग्रह में 32% की वृद्धि हुई (AllRecipes 2024 डेटा)।

(2) Event: स्थान जानकारी में Place और PostalAddress नेस्ट नहीं किए गए

त्रुटि परिदृश्य: एक कॉन्फ्रेंस वेबसाइट के Event मार्कअप में पदानुक्रमित नेस्टिंग के बिना सीधे पता स्ट्रिंग लिखी गई थी:

{
“@type”: “Event”,
“name”: “डिजिटल मार्केटिंग शिखर सम्मेलन”,
“location”: “सैन फ्रांसिस्को कन्वेंशन सेंटर” // त्रुटि: location को Place और PostalAddress नेस्ट करना आवश्यक है
}
समस्या: Google पते की संरचित जानकारी को पार्स नहीं कर सकता, इसलिए मैप कार्ड प्रदर्शित नहीं होता है।

सुधार क्रिया: Place (स्थान) और PostalAddress (डाक पता) उप-प्रकारों को नेस्ट करें:

{
“@type”: “Event”,
“name”: “डिजिटल मार्केटिंग शिखर सम्मेलन”,
“location”: {
“@type”: “Place”,
“name”: “सैन फ्रांसिस्को कन्वेंशन सेंटर”,
“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “123 Mission St”,
“addressLocality”: “San Francisco”,
“addressRegion”: “CA”,
“postalCode”: “94105”
},
“geo”: {
“@type”: “GeoCoordinates”,
“latitude”: “37.7890”,
“longitude”: “-122.4030”
}
}
} प्रभाव: सुधार के बाद, खोज परिणामों में मैप कार्ड प्रदर्शित हुआ, ईवेंट क्लिक दर में 40% की वृद्धि हुई, और पंजीकरण में 28% की वृद्धि हुई (Google Events 2023 डेटा)।

(3) Product: समीक्षा जानकारी में Review या AggregateRating नेस्ट नहीं किया गया

त्रुटि परिदृश्य: एक ई-कॉमर्स प्लेटफॉर्म के Product मार्कअप में सीधे समीक्षा स्कोर लिखा गया था, AggregateRating (कुल समीक्षा) उप-प्रकार को नेस्ट नहीं किया गया था:

{
“@type”: “Product”,
“name”: “वायरलेस हेडफ़ोन”,
“reviewScore”: “4.5” // त्रुटि: reviewScore को AggregateRating के तहत नेस्ट किया जाना चाहिए
} समस्या: Google यह नहीं पहचान सकता कि “4.5” उत्पाद की कुल समीक्षा है, इसलिए स्टार रेटिंग प्रदर्शित नहीं होती है।

सुधार क्रिया: AggregateRating उप-प्रकार को नेस्ट करें:

{
“@type”: “Product”,
“name”: “वायरलेस हेडफ़ोन”,
“aggregateRating”: {
“@type”: “AggregateRating”,
“ratingValue”: “4.5”,
“reviewCount”: “120”
}
} प्रभाव: इस उत्पाद के रिच रिज़ल्ट में स्टार रेटिंग प्रदर्शन दर 15% से बढ़कर 50% हो गई, और रूपांतरण में 19% की वृद्धि हुई (Shopify 2024 डेटा)।

(4) Article: लेखक की जानकारी में Person नेस्ट नहीं किया गया

त्रुटि परिदृश्य: एक टेक ब्लॉग के Article मार्कअप में लेखक का नाम सीधे लिखा गया था, Person (व्यक्ति) उप-प्रकार को नेस्ट नहीं किया गया था:

{
“@type”: “Article”,
“name”: “2024 एसईओ रुझान”,
“author”: “झांग सान” // त्रुटि: author को Person चाइल्ड प्रकार नेस्ट करना आवश्यक है
} समस्या: Google लेखक की पहचान संबंधी जानकारी को नहीं पहचान सकता, इसलिए “लेखक” लेबल प्रदर्शित नहीं होता है।

सुधार क्रिया: Person उप-प्रकार को नेस्ट करें:

{
“@type”: “Article”,
“name”: “2024 एसईओ रुझान”,
“author”: {
“@type”: “Person”,
“name”: “झांग सान”,
“url”: “https://example.com/author/zhangsan”
}
} प्रभाव: लेख का “लेखक” लेबल प्रदर्शन दर 20% से बढ़कर 60% हो गई, और उपयोगकर्ता का भरोसा 25% बढ़ गया (Google Authorship 2023 डेटा)।

डायनेमिक सामग्री पकड़ी नहीं गई

डायनेमिक सामग्री से तात्पर्य उस सामग्री से है जो JavaScript (JS), AJAX या सिंगल पेज एप्लिकेशन (SPA) फ़्रेमवर्क के माध्यम से वास्तविक समय में उत्पन्न होती है—जैसे React/Vue द्वारा बनाए गए पेज, अनंत स्क्रॉल (infinite scroll) वाली लेख सूचियाँ, या बटन क्लिक करने के बाद लोड होने वाले रेसिपी चरण।

इस प्रकार की सामग्री के मार्कअप (जैसे Product की कीमत, Article समीक्षाएं) प्रारंभिक HTML में दिखाई नहीं देते, बल्कि क्लाइंट-साइड JS द्वारा गतिशील रूप से इंजेक्ट किए जाते हैं।

लेकिन Googlebot का क्रॉलिंग तंत्र “पहले प्रारंभिक HTML को पकड़ना, फिर JS को निष्पादित करना” है। यदि JS निष्पादन बहुत धीमा है या सामग्री क्लाइंट-साइड रेंडरिंग पर निर्भर करती है, तो रिच रिज़ल्ट उत्पन्न नहीं हो पाते हैं।

Google इंजीनियर ब्लॉग (2024) इंगित करता है कि 40% डायनेमिक पेज प्री-रेंडरिंग की कमी के कारण मार्कअप क्रॉलर द्वारा नहीं पढ़े जाते हैं।

डायनेमिक सामग्री क्रॉल नहीं की जा सकी

Googlebot की क्रॉलिंग प्रक्रिया दो चरणों में विभाजित है:

1. प्रारंभिक HTML डाउनलोड करना: पेज की मूल संरचना प्राप्त करना (JS द्वारा उत्पन्न सामग्री के बिना);
2. JS निष्पादित करना: ब्राउज़र चलाने वाले JS का अनुकरण करना और डायनेमिक सामग्री प्राप्त करना (JS निष्पादन पूरा होने की प्रतीक्षा करना आवश्यक है)।

लेकिन क्रॉलर का “धैर्य” सीमित है:

• यदि JS निष्पादन समय 3 सेकंड से अधिक है, तो Googlebot समय से पहले समाप्त हो सकता है, जिससे डायनेमिक मार्कअप नहीं पढ़े जा पाते (Lighthouse 2023 डेटा);
• यदि सामग्री “उपयोगकर्ता इंटरैक्शन” (जैसे “अधिक लोड करें” पर क्लिक करना) पर निर्भर करती है, तो क्रॉलर इस सामग्री को छोड़ देगा।

मामला: एक न्यूज़ साइट React का उपयोग करके SPA बनाती है, और Article का टिप्पणी अनुभाग JS द्वारा गतिशील रूप से लोड किया जाता है।

परीक्षण टूल “कोई रिच रिज़ल्ट नहीं” दिखाता है—वास्तव में टिप्पणी मार्कअप मौजूद है, लेकिन जब Googlebot ने क्रॉल किया, तो JS निष्पादन पूरा नहीं हुआ था, और टिप्पणी सामग्री प्रारंभिक HTML में शामिल नहीं थी।

3 उच्च-आवृत्ति समस्याएं

(1) SPA (सिंगल पेज एप्लिकेशन): प्रारंभिक HTML खाली है, मार्कअप शामिल नहीं है

SPA “एक पेज, गतिशील रूप से सामग्री बदलना” है। प्रारंभिक HTML आमतौर पर खाली <div id="root"></div> होता है, और सभी सामग्री JS द्वारा इंजेक्ट की जाती है।

यदि प्री-रेंडरिंग नहीं की जाती है, तो Googlebot द्वारा कैप्चर किए गए प्रारंभिक HTML में कोई स्ट्रक्चर्ड डेटा नहीं होता है, और मार्कअप स्वाभाविक रूप से पहचाना नहीं जा सकता है। डेटा: एक ट्रैवल वेबसाइट का Tour मार्कअप React द्वारा उत्पन्न किया गया था, और प्रारंभिक HTML खाली था।

Search Console “कोई योग्य मार्कअप नहीं मिला” दिखाता है, और रिच रिज़ल्ट दर 0 है। सुधार के बाद सर्वर-साइड रेंडरिंग (SSR) का उपयोग किया गया, जिससे प्रारंभिक HTML में सीधे Tour का पूरा मार्कअप शामिल हो गया, और प्रदर्शन दर 0 से बढ़कर 28% हो गई।

(2) AJAX लोडिंग: सामग्री एसिंक्रोनस रूप से प्राप्त की जाती है, क्रॉलर ने लोडिंग पूरी होने की प्रतीक्षा नहीं की

AJAX का उपयोग सामग्री को गतिशील रूप से लोड करने के लिए किया जाता है (जैसे अनंत स्क्रॉल उत्पाद सूचियाँ, टिप्पणियाँ), लेकिन क्रॉलर AJAX अनुरोध पूरा होने की प्रतीक्षा नहीं करेगा—यदि सामग्री लोड होने में क्रॉलर की “टाइमआउट सीमा” (लगभग 3 सेकंड) से अधिक समय लगता है, तो मार्कअप छूट जाएगा।

मामला: एक ई-कॉमर्स प्लेटफॉर्म की “आपको पसंद आ सकता है” उत्पाद सूची AJAX द्वारा लोड की जाती है, और Product मार्कअप JS द्वारा गतिशील रूप से उत्पन्न किया जाता है।

परीक्षण टूल “कुछ मार्कअप अनदेखा किए गए” दिखाता है—जब Googlebot ने क्रॉल किया, तो AJAX अनुरोध पूरा नहीं हुआ था, और उत्पाद की जानकारी शामिल नहीं थी।

सुधार के बाद प्री-रेंडरिंग टूल (Prerender.io) का उपयोग करके पूरी उत्पाद सूची वाला HTML उत्पन्न किया गया, जिससे मार्कअप पहचान दर 60% से बढ़कर 95% हो गई।

(3) लेजी लोडिंग: सामग्री ट्रिगर होने पर दिखाई देती है, क्रॉलर के प्रतीक्षा समय से अधिक

लेजी लोडिंग का उपयोग पेज की गति को अनुकूलित करने के लिए किया जाता है, जैसे कि दृश्य क्षेत्र में स्क्रॉल करने पर HowTo के चरणों या Recipe की सामग्री सूची को लोड करना। लेकिन यदि देरी बहुत लंबी है (जैसे 2 सेकंड से अधिक), तो क्रॉलर इस सामग्री को छोड़ सकता है।

डेटा: एक होम फर्निशिंग वेबसाइट का HowTo मार्कअप (जैसे “बुकशेल्फ़ स्थापित करना” चरण) 2 सेकंड की देरी से लोड होता था।

Google परीक्षण टूल ने “चरण फ़ील्ड को पहचानने में असमर्थ” का संकेत दिया—क्रॉलर ने लोडिंग पूरी होने की प्रतीक्षा नहीं की।

सुधार के बाद देरी के समय को 1 सेकंड से कम कर दिया गया, जिससे चरणों की प्रदर्शन दर 18% से बढ़कर 43% हो गई।

तीन प्रकार की सुधार विधियाँ

(1) प्री-रेंडरिंग: सर्वर-साइड पूर्ण HTML उत्पन्न करता है, क्रॉलर सीधे कैप्चर करता है

प्री-रेंडरिंग का अर्थ है सर्वर-साइड पर JS चलाना, पूरी डायनेमिक सामग्री वाला HTML उत्पन्न करना और फिर इस HTML को क्रॉलर को भेजना।

Prerender.io या Nginx प्री-रेंडरिंग मॉड्यूल जैसे टूल स्वचालित रूप से क्रॉलर अनुरोधों को पहचान सकते हैं और प्री-रेंडर किया गया HTML वापस कर सकते।

प्रभाव: Prerender.io के साथ प्री-रेंडरिंग के बाद एक ई-कॉमर्स SPA की Product मार्कअप क्रॉल सफलता दर 75% से बढ़कर 92% हो गई, और रिच रिज़ल्ट प्रदर्शन दर 5% से बढ़कर 28% हो गई।

(2) सर्वर-साइड रेंडरिंग (SSR): फ़्रेमवर्क के साथ सीधे JS सामग्री रेंडर करना

SSR का अर्थ है Next.js (React), Nuxt.js (Vue) जैसे फ़्रेमवर्क का उपयोग करना, सर्वर-साइड पर JS घटकों को HTML स्ट्रिंग के रूप में रेंडर करना और फिर उन्हें क्लाइंट को भेजना।

इस तरह प्रारंभिक HTML में पूरा मार्कअप शामिल होता है, और क्रॉलर को JS निष्पादन की प्रतीक्षा करने की आवश्यकता नहीं होती है।

मामला: एक समाचार वेबसाइट को Next.js का उपयोग करके पुनर्गठित किया गया, और Article का टिप्पणी अनुभाग SSR द्वारा उत्पन्न किया गया।

जब Googlebot ने क्रॉल किया, तो उसे टिप्पणियों का Comment मार्कअप सीधे प्राप्त हुआ, फ़ीचर्ड स्निपेट प्रदर्शन दर 10% से बढ़कर 50% हो गई, और टिप्पणी इंटरैक्शन में 35% की वृद्धि हुई।

(3) JS निष्पादन समय को अनुकूलित करना: सुनिश्चित करें कि मार्कअप 3 सेकंड के भीतर लोड हो जाए

यदि प्री-रेंडरिंग या SSR करना संभव नहीं है, तो JS निष्पादन समय को अनुकूलित करना आवश्यक है ताकि यह सुनिश्चित हो सके कि डायनेमिक मार्कअप 3 सेकंड के भीतर लोड हो जाए।

मार्कअप के लोडिंग समय की जाँच के लिए Lighthouse या Chrome DevTools के Performance टैब का उपयोग करें:

• JS फ़ाइलों को संकुचित करें: फ़ाइल का आकार कम करने के लिए Webpack या Rollup के साथ कोड संकुचित करें;
• गैर-महत्वपूर्ण JS की लोडिंग में देरी करें: मार्कअप को प्रभावित न करने वाले स्क्रिप्ट (जैसे विज्ञापन, आंकड़े) को async या defer पर सेट करें;
• संसाधनों को कैश करें: लोडिंग समय कम करने के लिए JS फ़ाइलों को कैश करने के लिए CDN का उपयोग करें।

डेटा: एक मीडिया वेबसाइट ने JS निष्पादन समय को 4.2 सेकंड से घटाकर 2.5 सेकंड कर दिया, जिससे Googlebot क्रॉल सफलता दर 68% से बढ़कर 90% हो गई, और Article रिच रिज़ल्ट प्रदर्शन दर में 22% की वृद्धि हुई।

अंत में मैं कहना चाहता हूँ: JSON की एक सही लाइन, एक मानक नेस्टिंग, और समय पर प्री-रेंडरिंग, रिच रिज़ल्ट को “कुछ नहीं” से “सब कुछ” में बदल सकती है।