पेज का लेबल उस पेज से मेल खाना चाहिए जो आगंतुक देख सकता है
Schema.org मार्कअप सॉफ़्टवेयर को पेज और उसके विषय का एक स्ट्रक्चर्ड विवरण देता है। इसे वही समझाना चाहिए जो पेज पहले से कहता है, न कि ऐसे दावे जोड़ना जिनकी पुष्टि कोई आगंतुक नहीं कर सकता।
पेज के उद्देश्य और उसकी मुख्य Entity को लिखकर शुरुआत करें। फिर सबसे सरल प्रकार चुनें जो फिट बैठता हो। किसी प्रोजेक्ट का "About" पेज और प्रोडक्ट पेज एक-दूसरे के विकल्प नहीं हैं, भले ही वे एक ही वेबसाइट पर हों। यह आपको AI Visibility के लिए schema.org मार्कअप की एक उपयोगी पहली जांच देता है। क्या कोई व्यक्ति प्रत्येक चिह्नित तथ्य के पीछे दिखाई देने वाली सामग्री की ओर इशारा कर सकता है?
| पेज या विषय | संभावित प्रकार | एक व्यावहारिक जांच |
|---|---|---|
| प्रोजेक्ट या कंपनी | Organization | क्या इसका सार्वजनिक नाम और विवरण सटीक हैं? |
| पूरी वेबसाइट | WebSite | क्या रिकॉर्ड साइट का ही वर्णन करता है? |
| एक URL | WebPage | क्या यह वर्णित किए जा रहे पेज की पहचान करता है? |
| संपादकीय संसाधन | Article | क्या इसके लेखक और प्रकाशन विवरण दिखाई दे रहे हैं? |
| प्रोडक्ट या सॉफ़्टवेयर | Product या SoftwareApplication | क्या पेज वास्तव में उस पेशकश का वर्णन करता है? |
हम एक छोटा सेट देखना पसंद करेंगे जिसे आपकी टीम बनाए रख सके, बजाय एक भीड़भाड़ वाले रिकॉर्ड के जिसमें असमर्थित प्रॉपर्टीज़ हों। तकनीकी कार्य के व्यापक दृष्टिकोण के लिए, तकनीकी AEO मार्गदर्शन देखें।
उन प्रोजेक्ट विवरणों से शुरुआत करें जिनके बारे में लोग पहले से पूछते हैं
एक ऐसे Founder की कल्पना करें जिसका पहला लॉन्च शांत रहा। जो एकमात्र व्यक्ति जवाब देता है वह छुट्टी पर चला जाता है, और नए आगंतुकों को अभी भी प्रोजेक्ट के बारे में स्पष्ट विवरण चाहिए।
हम उन पेजों से शुरुआत करेंगे जिनकी उन आगंतुकों को ज़रूरत है, न कि किसी बड़े मार्कअप टेम्पलेट से। हम जाँचेंगे कि क्या प्रोजेक्ट का नाम, प्रोडक्ट विवरण और संपर्क विवरण साइट पर स्पष्ट रूप से दिखाई दे रहे हैं। फिर हम केवल उन दृश्य तथ्यों को उपयुक्त schema.org प्रॉपर्टीज़ से मैप करेंगे। पेज सत्य का स्रोत बना रहता है; मार्कअप उसका अनुसरण करता है।
मान लीजिए प्रोजेक्ट में एक प्रोडक्ट पेज और एक छोटा व्याख्यात्मक लेख है। प्रोडक्ट पेज Product का समर्थन कर सकता है यदि वह वास्तव में प्रोडक्ट का वर्णन करता है। व्याख्यात्मक लेख Article के लिए उपयुक्त हो सकता है जब उसके लेखक और संपादकीय विवरण दिखाए गए हों। यदि पेज किसी फ़ील्ड का समर्थन नहीं करता है, तो उसे छोड़ दें और पहले प्रोजेक्ट के जिम्मेदार व्यक्ति से स्रोत स्पष्ट करने के लिए कहें।
इससे काम सौंपना भी आसान हो जाता है। एक सहकर्मी प्रत्येक फ़ील्ड और पेज के बीच संबंध का अनुसरण कर सकता है, बजाय इसके कि वह अनुमान लगाए कि इसे क्यों जोड़ा गया था। उपयोगी स्रोत पेजों को आकार देने के बारे में अधिक जानकारी के लिए, AI सहायकों के लिए उद्धरण योग्य सामग्री पर जाएँ।
प्रोजेक्ट साइट के विभिन्न भागों के लिए कौन से स्कीमा प्रकार उपयुक्त हैं?
सही स्कीमा प्रकार इस बात पर निर्भर करता है कि कोई विशेष पेज क्या दर्शाता है। एक प्रोजेक्ट वेबसाइट विभिन्न URLs पर कई प्रकारों का उपयोग कर सकती है, बशर्ते प्रत्येक दृश्य सामग्री को प्रतिबिंबित करे।
साइट और उसके पेजों से शुरुआत करें
Organization साइट के पीछे के प्रोजेक्ट या कंपनी का वर्णन कर सकता है। WebSite पूरी वेबसाइट का वर्णन करता है, जबकि WebPage एक व्यक्तिगत URL का वर्णन करता है। इन प्रकारों को जोड़ा जा सकता है जहाँ संबंध वास्तविक और स्पष्ट हो। नाम और सार्वजनिक विवरण पेज और उसके मार्कअप में एक समान रखें।
सामग्री-विशिष्ट प्रकार केवल वहीं जोड़ें जहाँ वे फिट हों
Article एक संपादकीय संसाधन के लिए उपयुक्त हो सकता है जिसमें लेखक या प्रकाशन विवरण दिखाई देते हों। Product एक ऐसे पेज के लिए फिट हो सकता है जो वास्तव में किसी प्रोडक्ट को प्रस्तुत करता हो। SoftwareApplication एक ऐसे पेज के लिए फिट हो सकता है जो सॉफ़्टवेयर का वर्णन करता हो, बशर्ते मार्कअप में दर्शाए गए विवरण वहाँ समर्थित हों।
उदाहरण के लिए, एक पेज जो सॉफ़्टवेयर सुविधा की व्याख्या करता है, उसकी SoftwareApplication उपयुक्तता के लिए समीक्षा की जा सकती है। यदि यह केवल सामान्य रूप से प्रोजेक्ट पर चर्चा करता है, तो उस प्रकार को जोड़ना इसे गलत तरीके से वर्णित कर सकता है। एक त्वरित पेज-दर-पेज समीक्षा एक टेम्पलेट को असमान पेजों पर कॉपी होने से रोकती है।
एक JSON-LD ऑब्जेक्ट छोटा और पढ़ने योग्य हो सकता है। यहाँ, नाम और पता उदाहरणात्मक हैं, आपके प्रोजेक्ट के बारे में तथ्य नहीं:
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Example Project",
"url": "https://example.org/"
}
अपनी साइट के वास्तविक सार्वजनिक विवरणों का उपयोग करें, फिर जाँचें कि रेंडर किया गया पेज उनका समर्थन करता है। प्रश्न पेजों के लिए, FAQ Optimization मार्कअप पर विचार करने से पहले दृश्य उत्तरों की योजना बनाने में मदद कर सकता है।
पेज सूची से जाँचे गए JSON-LD तक एक शांत पाँच-चरणीय प्रक्रिया
एक पेज सूची और एक संक्षिप्त साक्ष्य जांच स्कीमा कार्य की समीक्षा को आसान बनाती है। हम प्रत्येक रिकॉर्ड को उसके द्वारा वर्णित पेज से जोड़े रखने के लिए इस अनुक्रम का उपयोग करते हैं।
- प्राथमिकता वाले URLs चुनें। उन पेजों की सूची बनाएं जो पहले महत्वपूर्ण हैं। प्रत्येक पेज के उद्देश्य, मुख्य Entity और कैननिकल पते पर ध्यान दें।
- एक उपयुक्त प्रकार चुनें। तय करें कि पेज संगठन, वेबसाइट, लेख, प्रोडक्ट, सॉफ़्टवेयर या किसी अन्य उपयुक्त विषय का वर्णन करता है या नहीं।
- प्रत्येक प्रॉपर्टी का पता लगाएं। लिखें कि आगंतुक तथ्य कहाँ देख सकता है, या कौन सा विश्वसनीय प्रोजेक्ट स्रोत इसकी पुष्टि करता है। स्पष्ट समर्थन के बिना फ़ील्ड हटा दें।
- मिलान वाले पेज पर JSON-LD जोड़ें। जाँचें कि इसके URLs इच्छित पेज की ओर इशारा करते हैं और इसका सिंटैक्स पार्स होता है। रिकॉर्ड की तुलना रेंडर की गई सामग्री से करें।
- संपादन के बाद पुनः जाँचें। जब पेज, प्रोडक्ट विवरण, लेखक या संगठन तथ्य बदलता है तो संबंधित मार्कअप की जाँच करें।
हम प्रकाशन से पहले किसी संपादक या प्रोडक्ट के जिम्मेदार व्यक्ति से पहचान और प्रोडक्ट दावों की पुष्टि करने के लिए कहेंगे। वह समीक्षा बेमेल नामों और पुराने विवरणों को तब पकड़ लेती है जब उन्हें ठीक करना अभी भी आसान होता है। चेकलिस्ट को पेज नोट्स के साथ रखें, ताकि भविष्य का कोई संपादक शुरू से तर्क को फिर से बनाए बिना उन्हीं जाँचों को दोहरा सके। यदि आप llms.txt को कैसे लागू करें पर भी विचार कर रहे हैं, तो उस कार्य को अलग रखें: फ़ाइल और पेज मार्कअप अलग-अलग काम करते हैं।
स्ट्रक्चर्ड डेटा और AI प्लेटफ़ॉर्म के बीच का हस्तांतरण
स्ट्रक्चर्ड डेटा किसी पेज के बारे में विवरण को अधिक स्पष्ट बना सकता है। लेकिन यह यह निर्देशित नहीं कर सकता कि ChatGPT, Perplexity, Google या कोई अन्य प्लेटफ़ॉर्म जानकारी का चयन या प्रस्तुतिकरण कैसे करता है। Google का दस्तावेज़ीकरण स्ट्रक्चर्ड डेटा को सामग्री को समझने और समर्थित सर्च उपस्थितियों के लिए पात्रता का आकलन करने में मदद करने के एक तरीके के रूप में वर्णित करता है। कोई उपस्थिति दिखाई जाएगी या नहीं, यह Google का निर्णय बना रहता है। कोई भी स्कीमा प्रकार किसी उद्धरण या विशेष उत्तर का वादा नहीं कर सकता।
वह सीमा आपकी टीम को एक उपयोगी गुणवत्ता परीक्षण देती है। जाँचें कि क्या पेज किसी वास्तविक पाठक की आवश्यकता का उत्तर देता है, क्या उसके दावे समर्थित हैं, और क्या मार्कअप दृश्य कॉपी को दर्शाता है। यदि डेटा पार्स होता है लेकिन पेज अस्पष्ट है, तो अधिक प्रॉपर्टीज़ जोड़ने से पहले पेज में सुधार करें। यदि कोई प्रोजेक्ट विवरण बदलता है, तो पेज को अपडेट करें और फिर संबंधित रिकॉर्ड की समीक्षा करें।
आपने क्या और क्यों बदला, इसके नोट्स रखें। इस तरह, अगला व्यक्ति बता सकेगा कि कोई फ़ील्ड किसी वास्तविक पेज विवरण का प्रतिनिधित्व करती है या पुरानी धारणा का। जब आप तुलना करें कि ChatGPT और Perplexity क्या दिखाते हैं, तो रिकॉर्ड करें कि प्रत्येक प्लेटफ़ॉर्म वास्तव में क्या प्रदर्शित करता है। मार्कअप को उल्लेख या चूक का कारण न मानें। AI सर्च Visibility पर हमारी मार्गदर्शिका व्यापक प्रकाशन परिदृश्य को कवर करती है।
एक छोटा रिकॉर्ड रखें जिसे आपकी टीम दोबारा देख सके
एक संक्षिप्त समीक्षा रिकॉर्ड टीम को पेज तथ्यों, मार्कअप जाँचों और Visibility अवलोकनों को अलग रखने में मदद करता है। यह अगले सामग्री अपडेट के पीछे पुराने विवरण छोड़ने की संभावना को भी कम करता है।
प्रत्येक प्राथमिकता वाले URL के लिए, उसके इच्छित प्रकार, कैननिकल पते, अंतिम समीक्षा और मान्यकरण स्थिति पर ध्यान दें। एक संक्षिप्त नोट तब जोड़ें जब पेज इस तरह से बदलता है जो उसके स्ट्रक्चर्ड डेटा को प्रभावित कर सकता है। फिर प्लेटफ़ॉर्म अवलोकनों को एक अलग जगह पर रखें: जाँचा गया प्रश्न, प्लेटफ़ॉर्म, जाँच की तारीख और उसने क्या दिखाया, रिकॉर्ड करें। ये नोट्स बताते हैं कि आपकी टीम ने क्या देखा; वे यह स्थापित नहीं करते कि किसी प्लेटफ़ॉर्म ने कोई विशेष स्रोत क्यों चुना।
वास्तविक प्रश्नों के एक छोटे सेट का उपयोग करें जो आगंतुक प्रोजेक्ट के बारे में पूछ सकते हैं। जब आप पेज की समीक्षा करें तो उन्हें दोहराएँ, और उत्तर की तुलना प्रकाशित पेज से करें। यदि कोई उत्तर किसी महत्वपूर्ण विवरण को छोड़ देता है, तो स्कीमा बदलने से पहले शब्दांकन और स्रोत जानकारी का निरीक्षण करें। यह काम को उस सामग्री पर आधारित रखता है जिसे लोग सत्यापित कर सकते हैं।
यदि आप व्यापक तकनीकी समीक्षा चाहते हैं, तो llms.txt और AI क्रॉलर सेटअप उस कार्य के एक अलग हिस्से की व्याख्या करता है। अपनी स्वयं की समीक्षा शुरू करने के लिए, कुछ प्राथमिकता वाले URLs, आपके दर्शकों द्वारा पूछे जाने वाले प्रश्न और कोई भी मौजूदा स्कीमा निर्यात एकत्र करें। हम पेज-से-मार्कअप मिलान की जाँच करने और आपकी टीम के लिए स्पष्ट सुधार वापस करने में मदद कर सकते हैं।
यह कैसे काम करता है
- प्राथमिकता वाले पेजों की सूची बनाएंप्रत्येक URL का उद्देश्य, मुख्य Entity और कैननिकल पता रिकॉर्ड करें।
- पेज प्रकार चुनेंऐसे प्रकार चुनें जो प्रत्येक पेज के दृश्य उद्देश्य का वर्णन करते हों।
- तथ्यों का पता लगाएंप्रत्येक प्रॉपर्टी को दृश्य सामग्री या किसी विश्वसनीय प्रोजेक्ट स्रोत से जोड़ें।
- JSON-LD जोड़ें और जाँचेंइसे उस पेज पर रखें जिसका यह वर्णन करता है, इसके सिंटैक्स का परीक्षण करें, और इसके तथ्यों की तुलना रेंडर किए गए पेज से करें।
- संपादन के बाद समीक्षा करेंजब संबंधित पेज सामग्री या प्रोजेक्ट विवरण बदलें तब मार्कअप की दोबारा जाँच करें।
अक्सर पूछे जाने वाले प्रश्न
क्या स्कीमा मार्कअप ChatGPT या Perplexity को किसी प्रोजेक्ट का उल्लेख करने में मदद कर सकता है?
स्कीमा पेज विवरणों को एक स्ट्रक्चर्ड तरीके से वर्णित कर सकता है, लेकिन ChatGPT और Perplexity तय करते हैं कि वे क्या दिखाते और उद्धृत करते हैं। जाँचें कि पेज किसी स्पष्ट पाठक प्रश्न का उत्तर देता है और उसके चिह्नित तथ्य दृश्य पाठ से मेल खाते हैं। जब आप किसी परिणाम की समीक्षा करें, तो प्रश्न और प्लेटफ़ॉर्म को सहेजें ताकि आपकी टीम अवलोकन दोहरा सके।
एक प्रोजेक्ट वेबसाइट को किस स्कीमा प्रकार से शुरुआत करनी चाहिए?
उन पेजों से शुरुआत करें जो आपके पास हैं और प्रत्येक वास्तव में क्या कहता है। Organization प्रोजेक्ट का वर्णन कर सकता है, जबकि WebSite और WebPage साइट और एक व्यक्तिगत URL का वर्णन करते हैं। Article, Product या SoftwareApplication विशिष्ट पेजों के लिए फिट हो सकते हैं जब उनके दृश्य विवरण उन प्रकारों का समर्थन करते हों।
क्या मुझे llms.txt और schema.org मार्कअप दोनों की आवश्यकता है?
ज़रूरी नहीं। Schema.org पेज सामग्री और Entities का स्ट्रक्चर्ड डेटा में वर्णन करता है; llms.txt चयनित साइट संसाधनों की ओर इशारा करने के लिए एक प्रस्तावित टेक्स्ट-फ़ाइल कन्वेंशन है। तय करें कि क्या प्रत्येक किसी अलग आवश्यकता में मदद करता है, और जानकारी को तभी अद्यतन रखें यदि आपकी टीम इसे बनाए रख सकती है।
मैं अपने पेज के विरुद्ध JSON-LD उदाहरण की जांच कैसे कर सकता हूँ?
जाँचें कि सिंटैक्स पार्स होता है, प्रकार पेज पर फिट बैठता है, और प्रत्येक प्रॉपर्टी का दृश्य या विश्वसनीय समर्थन है। प्रकाशन से पहले नामों, URLs और विवरणों की तुलना रेंडर किए गए पेज से करें। एक दूसरा समीक्षक लेखकत्व या प्रोडक्ट जानकारी जैसे विवरणों की पुष्टि कर सकता है जब वे तथ्य स्पष्ट न हों।
क्या प्रश्नों वाले प्रत्येक पेज को FAQPage मार्कअप का उपयोग करना चाहिए?
नहीं। किसी प्रकार का उपयोग केवल तभी करें जब वह पेज का सटीक वर्णन करता हो और संबंधित प्लेटफ़ॉर्म की दस्तावेजी आवश्यकताओं का पालन करता हो। एक पेज FAQPage मार्कअप के बिना भी सामान्य प्रश्नों के स्पष्ट उत्तर दे सकता है। मुख्य जाँच यह है कि क्या आगंतुक डेटा में दर्शाए गए उत्तर पा सकते हैं।
हमारी टीम को स्कीमा मार्कअप की कितनी बार समीक्षा करनी चाहिए?
जब पेज या उसके द्वारा वर्णित विवरण बदलें तब इसकी समीक्षा करें। उदाहरण के लिए, एक संशोधित प्रोडक्ट विवरण या संगठन के नाम से संबंधित रिकॉर्ड की जाँच होनी चाहिए। URL, इच्छित प्रकार और अंतिम समीक्षा को एक संक्षिप्त नोट में रखने से उस जाँच को दोहराना आसान हो जाता है।
अपने प्रोजेक्ट के बारे में बताएं
चार त्वरित प्रश्नों के उत्तर दें और एक मैनेजर एक घंटे के भीतर योजना, समय और मूल्य सीमा भेजेगा। सब कुछ गोपनीय रहता है।
फ़ॉर्म लोड हो रहा है…