कौन-से schema.org प्रकार वास्तव में खोज परिणामों को प्रभावित करते हैं

संक्षिप्त उत्तर

Schema.org मार्कअप अपने-आप रैंकिंग नहीं सुधारता। हालांकि, यह किसी पेज को उन्नत खोज उपस्थिति के लिए पात्र बना सकता है: रिच रिज़ल्ट, प्रोडक्ट पैनल, ब्रेडक्रंब, इवेंट लिस्टिंग, जॉब मॉड्यूल, वीडियो प्रीव्यू, और इसी तरह की सुविधाएँ।

यह अंतर महत्वपूर्ण है। Schema.org वेब पर चीज़ों का वर्णन करने के लिए एक व्यापक शब्दावली है। खोज इंजन इसका केवल एक हिस्सा समर्थन करते हैं, और हर खोज सुविधा के अपने नियम होते हैं। आप किसी पेज को Thing, CreativeWork, या Service के साथ पूरी तरह मार्कअप कर सकते हैं और फिर भी खोज परिणामों में कोई दृश्य परिवर्तन नहीं देख सकते, क्योंकि संभव है कि उस प्रकार से जुड़ी कोई खोज सुविधा न हो।

इसलिए उपयोगी प्रश्न यह नहीं है कि “कौन-से schema प्रकार मौजूद हैं?” बल्कि यह है कि “कौन-से schema प्रकार खोज इंजनों द्वारा दृश्य या संचालनात्मक खोज सुविधाएँ बनाने के लिए उपयोग किए जाते हैं?”

नीचे इसका व्यावहारिक उत्तर है।

पहले: संरचित डेटा पात्रता है, अधिकार नहीं

संरचित डेटा खोज इंजनों को स्पष्ट संकेत देता है। यह उन्हें कुछ भी दिखाने के लिए बाध्य नहीं करता।

किसी पेज पर संरचित डेटा का दृश्य प्रभाव दिखने से पहले आम तौर पर ये सभी बातें आवश्यक होती हैं:

• मार्कअप दृश्य पेज सामग्री से मेल खाना चाहिए।
• आवश्यक और अनुशंसित प्रॉपर्टी मौजूद होनी चाहिए।
• पेज इंडेक्स किए जाने योग्य होना चाहिए और robots नियमों से अवरुद्ध नहीं होना चाहिए।
• सामग्री को गुणवत्ता और स्पैम नीतियों का पालन करना चाहिए।
• खोज इंजन को यह तय करना चाहिए कि उन्नत परिणाम उपयोगकर्ता की मदद करता है।

इसीलिए दो तकनीकी रूप से वैध पेज खोज में अलग-अलग व्यवहार कर सकते हैं। एक को प्रोडक्ट रिच रिज़ल्ट मिल सकता है; दूसरा साधारण नीले लिंक के रूप में दिख सकता है। मार्कअप केवल एक इनपुट है।

इसी वजह से अस्पष्ट schema प्रकारों के पीछे भागना आम तौर पर समय का अच्छा उपयोग नहीं है। यदि उस प्रकार से जुड़ी कोई समर्थित खोज सुविधा नहीं है, तो लाभ अधिकतर दृश्य नहीं बल्कि अर्थगत होता है।

सबसे स्पष्ट प्रभाव वाले प्रकार

Product, Offer, AggregateRating, और Review

ईकॉमर्स और सॉफ़्टवेयर पेजों के लिए, प्रोडक्ट मार्कअप सबसे अधिक दृश्य रूप से उपयोगी संरचित डेटा परिवारों में से एक है।

एक Product पेज कीमत, उपलब्धता, रेटिंग, शिपिंग, रिटर्न, और मर्चेंट लिस्टिंग सुविधाओं के लिए पात्र बन सकता है। सबसे महत्वपूर्ण सहायक प्रकार आम तौर पर ये होते हैं:

• कीमत, मुद्रा, उपलब्धता, और विक्रेता जानकारी के लिए Offer
• सारांशित रेटिंग के लिए AggregateRating
• जहाँ उचित हो, व्यक्तिगत समीक्षाओं के लिए Review
• निर्माता या विक्रेता संदर्भ के लिए Brand या Organization

यह मार्कअप तब सबसे उपयोगी होता है जब पेज वास्तव में किसी विशिष्ट प्रोडक्ट के बारे में हो, न कि किसी श्रेणी या अस्पष्ट सेवा पेज के बारे में। खोज इंजन समीक्षा और रेटिंग के दुरुपयोग को लेकर अधिक सख्त होते जा रहे हैं, विशेषकर आत्म-हितकारी समीक्षाओं के मामले में। यदि रेटिंग पेज पर उपयोगकर्ताओं को दिखाई नहीं देती, तो उसे मार्कअप न करें।

Product schema क्लासिक ऑर्गेनिक स्निपेट और मर्चेंट-शैली की सतहों, दोनों को प्रभावित कर सकता है। रिटेलरों के लिए, यह अक्सर सबसे अधिक रिटर्न देने वाले संरचित डेटा कार्यान्वयनों में से एक होता है।

BreadcrumbList

BreadcrumbList आकर्षक नहीं है, लेकिन व्यावहारिक है। यह खोज परिणामों में URL/पथ प्रदर्शन को प्रभावित कर सकता है, और किसी उलझे हुए URL को अधिक साफ़ हाइरार्की से बदल सकता है।

ब्रेडक्रंब मार्कअप इनके लिए उपयोगी है:

• ईकॉमर्स श्रेणी और प्रोडक्ट पेज
• डॉक्यूमेंटेशन साइटें
• बड़े ब्लॉग और प्रकाशन
• SaaS सहायता केंद्र

यह शायद ही कभी कोई नाटकीय रिच रिज़ल्ट बनाता है, लेकिन समझ को बेहतर कर सकता है। उपयोगकर्ता क्लिक करने से पहले देख सकते हैं कि पेज कहाँ स्थित है। खोज इंजनों को भी साइट संरचना का अधिक स्पष्ट दृश्य मिलता है।

यदि आपकी साइट में गहरी नेविगेशन है, तो ब्रेडक्रंब मार्कअप शुरुआती चरण में करना उचित है।

Article, NewsArticle, और BlogPosting

Article, NewsArticle, और BlogPosting खोज इंजनों को शीर्षक, लेखक, तारीख, छवि, और प्रकाशक जानकारी समझने में मदद कर सकते हैं। प्रकाशकों के लिए, यह लेख-केंद्रित सुविधाओं की पात्रता को प्रभावित कर सकता है, विशेषकर जब इसे मजबूत क्रॉलेबिलिटी, ताज़गी, और सामग्री गुणवत्ता के साथ जोड़ा जाए।

यह अपेक्षा न करें कि article schema किसी साधारण ब्लॉग पोस्ट को समाचार परिणाम में बदल देगा। यह कमजोर रिपोर्टिंग, गायब लेखक जानकारी, या पतली सामग्री की भरपाई नहीं करेगा।

फिर भी, संपादकीय साइटों के लिए article मार्कअप समझदारी भरा है। मूल तथ्यों को अस्पष्टता से मुक्त करने के लिए इसका उपयोग करें:

• शीर्षक
• लेखक या संगठन
• प्रकाशित तारीख और संशोधित तारीख
• मुख्य छवि
• प्रकाशक
• Canonical URL

यदि आपकी टीम AI-सहायता प्राप्त प्रकाशन का उपयोग करती है, तो संरचित डेटा खुलासे या संपादकीय जवाबदेही का विकल्प नहीं है। हमने इसके मानवीय पक्ष को एक छोटी वेबसाइट पर ईमानदार AI प्रकटीकरण कैसा दिखता है में कवर किया है। खोज प्रणालियाँ आपके मार्कअप को पार्स कर सकती हैं, लेकिन पाठक पेज को ही परखते हैं।

LocalBusiness और इसके उपप्रकार

स्थानीय संगठनों के लिए, LocalBusiness और इसके उपप्रकार—जैसे Restaurant, Dentist, Store, या ProfessionalService—किसी वेबसाइट को व्यवसाय संबंधी तथ्यों से जोड़ने में मदद कर सकते हैं: नाम, पता, फ़ोन नंबर, खुलने का समय, भू-निर्देशांक, और same-as प्रोफ़ाइल।

दृश्य प्रभाव प्रोडक्ट या रेसिपी मार्कअप की तुलना में कम अनुमानित होता है, क्योंकि स्थानीय खोज व्यवसाय लिस्टिंग, निकटता, प्रमुखता, समीक्षाओं, और उपयोगकर्ता मंशा पर बहुत निर्भर करती है। फिर भी, सुसंगत स्थानीय व्यवसाय मार्कअप उपयोगी स्वच्छता है।

इसे उस पेज पर उपयोग करें जो व्यवसाय स्थान का प्रतिनिधित्व करता है, हर ब्लॉग पोस्ट पर बेतरतीब ढंग से नहीं। यदि आपके कई स्थान हैं, तो हर स्थान पेज को उसके अपने पते और खुलने के समय के साथ मार्कअप करें।

Event

Event मार्कअप पात्र पेजों को इवेंट-संबंधित खोज सुविधाओं में तारीखों, स्थानों, और टिकट जानकारी के साथ दिखा सकता है।

यह इनके लिए अच्छा मेल है:

• कॉन्सर्ट
• कॉन्फ़्रेंस
• वेबिनार
• कक्षाएँ
• फ़ेस्टिवल
• सामुदायिक इवेंट

मुख्य बात विशिष्टता है। “हमारा वार्षिक प्रशिक्षण कार्यक्रम” के बारे में पेज वैसा नहीं है जैसा किसी तारीख़ वाले इवेंट का पेज, जिसमें प्रारंभ समय, स्थान, आयोजक, और उपस्थिति मोड हो।

ऑनलाइन इवेंट के लिए, वर्चुअल उपस्थिति विवरण शामिल करें। भौतिक इवेंट के लिए, स्थल की जानकारी शामिल करें। रद्द, स्थगित, और पुनर्निर्धारित इवेंट को अद्यतित रखें; बासी इवेंट मार्कअप, मार्कअप न होने से भी खराब है।

JobPosting

JobPosting संरचित डेटा द्वारा किसी विशिष्ट खोज अनुभव को संचालित करने का सबसे स्पष्ट उदाहरण है। सही ढंग से मार्क किए गए जॉब पेज नौकरी खोज सुविधाओं के लिए पात्र हो सकते हैं, जिनमें भूमिका, स्थान, वेतन, रोजगार प्रकार, और पोस्टिंग तारीख शामिल हैं।

यह मार्कअप केवल वास्तविक जॉब पोस्टिंग पेजों पर उपयोगी है। इसे सामान्य करियर पेजों पर लागू न करें जो अलग-अलग विवरण पेजों के बिना कई भूमिकाएँ सूचीबद्ध करते हैं।

महत्वपूर्ण फ़ील्ड में शामिल हैं:

• नौकरी का शीर्षक
• भर्ती करने वाला संगठन
• स्थान या रिमोट स्थिति
• पोस्ट की गई तारीख
• Valid-through तारीख
• रोजगार प्रकार
• पारिश्रमिक, जहाँ उपलब्ध हो

समाप्त हो चुकी नौकरियों को हटाया जाना चाहिए, उचित रूप से रीडायरेक्ट किया जाना चाहिए, या अब मान्य नहीं के रूप में चिह्नित किया जाना चाहिए। खोज इंजन उपयोगकर्ताओं को बंद अवसरों पर भेजना पसंद नहीं करते।

Recipe

Recipe मार्कअप क्लासिक रिच-रिज़ल्ट मामलों में से एक बना हुआ है। यह छवि थंबनेल, रेटिंग, पकाने का समय, सामग्री, पोषण, और गाइडेड रेसिपी अनुभवों को प्रभावित कर सकता है।

यह संरचित डेटा के सबसे अधिक दुरुपयोग वाले क्षेत्रों में से भी एक है। यदि पेज ज़्यादातर व्यक्तिगत निबंध है और रेसिपी नीचे कहीं छिपी है, तब भी मार्कअप को दृश्य रेसिपी का सटीक वर्णन करना चाहिए। संरचित डेटा को पाँच मिनट की तैयारी का दावा नहीं करना चाहिए, जब निर्देश कुछ और कहते हों।

रेसिपी पेज छवियों पर बहुत निर्भर होते हैं, इसलिए संरचित डेटा काम का केवल एक हिस्सा है। अच्छी छवियाँ, समझदार compression, और उपयोगी alt text सभी मायने रखते हैं। यदि आप भोजन, प्रोडक्ट, या संपादकीय छवियों को बेहतर कर रहे हैं, तो 2026 में image alt text के लिए एक व्यावहारिक मार्गदर्शिका schema कार्य के लिए उपयोगी साथी है।

VideoObject

VideoObject मार्कअप वीडियो प्रीव्यू, key moments, थंबनेल, अवधि, अपलोड तारीख, और वीडियो इंडेक्सिंग को प्रभावित कर सकता है। यह तब उपयोगी होता है जब वीडियो पेज का अर्थपूर्ण हिस्सा हो, न कि नीचे लगा कोई आकस्मिक embed।

कम से कम, ये प्रदान करें:

• नाम
• विवरण
• Thumbnail URL
• अपलोड तारीख
• अवधि
• Embed या content URL

निर्देशात्मक या लंबे वीडियो के लिए, key moments खोज इंजनों को वीडियो के हिस्से समझने में मदद कर सकते हैं। इससे खोज में वीडियो का प्रदर्शन बेहतर हो सकता है, हालांकि फिर से, यह स्थान की गारंटी नहीं देता।

Organization, Logo, और WebSite

Organization मार्कअप किसी साइट के पीछे की इकाई को परिभाषित करने में मदद करता है। WebSite साइट-स्तरीय समझ का समर्थन कर सकता है और कुछ मामलों में, जब खोज इंजन दिखाने का निर्णय ले, तो sitelinks search box जैसी सुविधाओं का भी।

यह मार्कअप चकाचौंध वाला नहीं, बल्कि आधारभूत है। यह इन बातों को स्पष्ट करने में मदद कर सकता है:

• आधिकारिक साइट पहचान
• Logo
• Social profiles
• संपर्क जानकारी
• Parent या subsidiary संबंध

हर गंभीर व्यवसाय, प्रकाशन, गैर-लाभकारी संस्था, और प्रोडक्ट कंपनी के पास कहीं स्थिर जगह पर साफ़ organization मार्कअप होना चाहिए, आम तौर पर homepage या about page पर।

इसमें हर संभव प्रॉपर्टी न भरें। लक्ष्य इकाई की स्पष्टता है, डेटाबेस dump नहीं।

FAQPage: तकनीकी रूप से समर्थित, लेकिन अधिकांश साइटों के लिए शायद ही दिखाई देता है

FAQPage विशेष उल्लेख का पात्र है क्योंकि यह पहले आसान जीत हुआ करता था। वर्षों तक, FAQ मार्कअप प्रश्न-उत्तर अकॉर्डियन के साथ snippets को विस्तारित कर सकता था। इससे यह आकर्षक बना, और अनुमानतः, इसका अधिक उपयोग हुआ।

बाद में Google ने FAQ rich results को बहुत सीमित कर दिया, आम तौर पर इन्हें केवल प्रसिद्ध, आधिकारिक सरकारी और स्वास्थ्य साइटों के लिए दिखाया। अन्य खोज इंजन FAQ मार्कअप का अलग तरह से उपयोग कर सकते हैं, और मार्कअप अभी भी मशीनों को सामग्री संरचना समझने में मदद कर सकता है, लेकिन अधिकांश वाणिज्यिक और संपादकीय साइटों को दृश्य FAQ rich results की अपेक्षा नहीं करनी चाहिए।

FAQ मार्कअप का उपयोग केवल तब करें जब पेज में वास्तव में FAQ हो। केवल खोज में अधिक जगह पाने के लिए नकली Q&A ब्लॉक न जोड़ें।

DiscussionForumPosting और ProfilePage

समुदाय सामग्री खोज परिणामों में अधिक प्रमुख हो गई है, और संरचित डेटा फ़ोरम थ्रेड और प्रोफ़ाइल पेजों की पहचान करने में मदद कर सकता है।

DiscussionForumPosting फ़ोरम, Q&A समुदायों, और चर्चा प्लेटफ़ॉर्मों के लिए उपयोगी हो सकता है जहाँ मुख्य सामग्री उपयोगकर्ता-निर्मित चर्चा है। ProfilePage लोगों या योगदानकर्ताओं के बारे में पेजों की पहचान करने में मदद कर सकता है, विशेषकर जहाँ विशेषज्ञता, लेखकीयता, या समुदाय पहचान मायने रखती है।

यह साधारण marketing testimonials या blog comments के लिए उपयुक्त नहीं है। पेज प्रकार वास्तविक अनुभव से मेल खाना चाहिए।

उपयोगी लेकिन अक्सर बढ़ा-चढ़ाकर आँके जाने वाले प्रकार

कुछ schema.org प्रकार अर्थगत रूप से उचित होते हैं, लेकिन अपने-आप दृश्य खोज enhancements शायद ही बनाते हैं।

उदाहरणों में शामिल हैं:

• Service
• Thing
• CreativeWork
• Person
• Place
• ImageObject
• WebPage
• AboutPage
• ContactPage

ये “खराब” प्रकार नहीं हैं। ये किसी पेज का अधिक सटीक वर्णन करने में मदद कर सकते हैं, और व्यापक knowledge graph संदर्भों में उपयोगी हो सकते हैं। लेकिन यदि आपका लक्ष्य खोज परिणामों में दृश्य बदलाव है, तो ये आम तौर पर द्वितीयक होते हैं।

उदाहरण के लिए, किसी consulting पेज को Service के रूप में मार्क करने से भरोसेमंद रूप से कोई विशेष service rich result नहीं बनेगा। स्पष्ट copy, internal links, तेज़ rendering, और विश्वसनीय प्रमाण वाला सुव्यवस्थित पेज, विस्तृत लेकिन असमर्थित मार्कअप की तुलना में खोज प्रदर्शन के लिए अधिक करेगा।

इसी तरह, ImageObject छवियों का वर्णन कर सकता है, लेकिन image search प्रदर्शन आसपास के text, filenames, captions, image quality, indexing, और accessibility पर भी निर्भर करता है। Schema मूलभूत बातों का विकल्प नहीं है।

JSON-LD आम तौर पर सबसे अच्छा कार्यान्वयन फ़ॉर्मैट है

खोज इंजन Microdata और RDFa सहित कई संरचित डेटा फ़ॉर्मैट पढ़ सकते हैं, लेकिन JSON-LD आम तौर पर सबसे साफ़ विकल्प है।

यह मार्कअप को HTML presentation से अलग रखता है, test करना आसान है, और designers द्वारा templates बदलने पर टूटने की संभावना कम होती है। अधिकांश टीमों के लिए, पेज head या body में JSON-LD व्यावहारिक default है।

एक सरल product उदाहरण ऐसा दिखता है:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Acme Carbon Tripod",
  "image": "https://example.com/images/tripod.jpg",
  "description": "A lightweight carbon tripod for travel photography.",
  "brand": {
    "@type": "Brand",
    "name": "Acme"
  },
  "offers": {
    "@type": "Offer",
    "priceCurrency": "USD",
    "price": "149.00",
    "availability": "https://schema.org/InStock",
    "url": "https://example.com/products/carbon-tripod"
  }
}

यह उदाहरण जानबूझकर साधारण है। अधिकांश संरचित डेटा उबाऊ होना चाहिए। चतुराई से बेहतर सटीकता है।

एक व्यावहारिक प्राथमिकता मॉडल

यदि आप तय कर रहे हैं कि पहले क्या लागू करना है, तो इस क्रम का उपयोग करें:

1. उन पेज प्रकारों से शुरू करें जो समर्थित खोज सुविधाओं से मेल खाते हैं। Product, recipe, event, job, video, breadcrumb, article, और local business मार्कअप आम तौर पर अस्पष्ट प्रकारों से पहले ध्यान के योग्य होते हैं।
2. केवल वही मार्कअप करें जो उपयोगकर्ता देख सकते हैं। छिपे हुए दावे एक सामान्य कारण हैं जिनसे संरचित डेटा अयोग्य या जोखिमपूर्ण बन जाता है।
3. व्यक्तिगत पेज नहीं, templates सुधारें। संरचित डेटा को बनाए रखना सबसे आसान तब होता है जब यह आपके CMS या product database से generated हो।
4. Validate करें, फिर monitor करें। आधिकारिक rich result और schema validation tools का उपयोग करें, फिर जहाँ उपलब्ध हो, Search Console enhancement reports देखें।
5. Page experience को नज़रअंदाज़ न करें। Rich results presentation में मदद कर सकते हैं, लेकिन उपयोगकर्ता फिर भी पेज पर आते हैं। यदि performance reports आपकी टीम को परेशान करती हैं, तो schema को एक और distraction बनाने से पहले बिना घबराए Lighthouse reports पढ़ें।

सामान्य गलतियाँ जो प्रभाव घटाती हैं

गलत पेज प्रकार को मार्क करना

Category page, product page नहीं होता। Careers landing page, job posting नहीं होता। आगामी webinars की सूची ज़रूरी नहीं कि एक event हो।

Search features आम तौर पर विशिष्ट page intents के आसपास डिज़ाइन की जाती हैं। मार्कअप को पेज के प्रमुख उद्देश्य से मिलाएँ।

ऐसी properties जोड़ना जो दिखाई नहीं देतीं

यदि पेज rating नहीं दिखाता, तो aggregateRating शामिल न करें। यदि job page salary का उल्लेख नहीं करता, तो compensation markup गढ़ने में सावधानी रखें। यदि कोई product out of stock है, तो उसे in stock के रूप में मार्क न करें।

Structured data को दृश्य तथ्यों को parse करना आसान बनाना चाहिए, पेज का समानांतर संस्करण नहीं बनाना चाहिए।

Validation को सफलता मान लेना

Validator पास करना केवल यह बताता है कि syntax स्वीकार्य है और आवश्यक fields मौजूद हो सकते हैं। इसका मतलब यह नहीं है कि पेज को rich result मिलेगा।

Validation को outcome नहीं, floor समझें।

Schema एक बार लागू करके भूल जाना

Prices बदलती हैं। Jobs expire होती हैं। Events postpone होते हैं। Authors चले जाते हैं। Logos redesign होते हैं।

Stale fields से generated structured data चुपचाप inaccurate हो सकता है। जब भी आप templates, CMS fields, या business data sources बदलें, इसकी समीक्षा करें।

<!-- tool-cta:start -->

💡 इसे आज़माएँ: यह जाँचने से पहले कि कौन से स्कीमा प्रकार वास्तव में मायने रखते हैं, अपने JSON-LD को JSON Formatter से साफ़ करें ताकि संरचना का ऑडिट करना आसान हो।

<!-- tool-cta:end -->

शांत अनुशंसा

अधिकांश साइटों के लिए, schema रणनीति सीमित और सोच-समझकर होनी चाहिए।

वे प्रकार लागू करें जो आपकी वास्तविक सामग्री से मेल खाते हैं और समर्थित खोज सुविधाओं से map होते हैं। डेटा सटीक रखें। इसे भरोसेमंद स्रोतों से generate करें। Validate करें। Results monitor करें। फिर रुक जाएँ।

आपको पेज पर हर noun को मार्क करने की ज़रूरत नहीं है। आपको बारह nested schema types की ज़रूरत नहीं है क्योंकि किसी checklist ने ऐसा कहा। और आपको निश्चित रूप से ऐसे structured data की ज़रूरत नहीं है जो पेज से अधिक कहता हो।

Schema.org तब सबसे उपयोगी है जब यह अस्पष्टता हटाता है। खोज परिणाम तब बेहतर होते हैं जब यह स्पष्टता उन सुविधाओं से मेल खाती है जिन्हें खोज इंजन वास्तव में support करते हैं।