व्यक्तिगत वेबसाइटों के लिए JSON-LD की व्याख्या

 (hawksley.dev)
2 पॉइंट द्वारा GN⁺ 8 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • व्यक्तिगत वेबसाइट में भी structured data जोड़ने पर crawler पेज, व्यक्ति और लेख के बीच के संबंध को बेहतर समझ सकते हैं, जिससे link preview और search visibility की गुणवत्ता सुधर सकती है
  • इसे लागू करने का तरीका <head> के भीतर <script type="application/ld+json"> में @context को Schema.org पर सेट करना और @graph में WebSite, Person, BlogPosting जैसे nodes रखना है
  • एक ही @id इस्तेमाल करने पर web crawler कई पेजों के node properties को merge कर सकते हैं, लेकिन सिर्फ एक पेज पढ़ने वाले scraper या LLM ऐसा merge नहीं करते
  • root page में मूल रूप से WebSite, ProfilePage, Person रखें, और blog·project·list pages में उनके स्वरूप के अनुसार Blog, BlogPosting, SoftwareApplication, CollectionPage, BreadcrumbList जोड़ें
  • Person का sameAs, पेज का breadcrumb, और लेख के image·license·date fields सीधे व्यक्ति की पहचान, search result path, article preview, usage conditions और freshness के आकलन में काम आते हैं

JSON-LD की भूमिका और बुनियादी संरचना

  • JSON-LD का अर्थ JSON Linked Data है, और यह वेबपेज में structured data जोड़ने का एक format है
  • यह crawler को साइट की semantic structure समझने में मदद करता है, और अधिक समृद्ध link preview तथा search ranking में संभावित सुधार में योगदान दे सकता है
  • पेज में जोड़ते समय <head> सेक्शन के भीतर नीचे दिए गए रूप का script रखा जाता है
    • <script type="application/ld+json"> MIME type को application/ld+json घोषित करता है
    • यह type दिए जाने पर browser का JavaScript engine इसे execute नहीं करता
    • Googlebot जैसे विशेष crawler इस element को खोजकर उसकी content को parse करते हैं

@context, @graph, node ID

  • @context उस context को निर्दिष्ट करता है जिसका JSON-LD data पालन करता है, और web crawler Schema.org को standard के रूप में उपयोग करते हैं
  • Schema.org JSON में उपयोग किए जा सकने वाले valid key-value pairs को परिभाषित करता है
  • JSON-LD document को एक labeled directed graph की तरह देखा जा सकता है, और data @graph के अंतर्गत रखा जाता है
  • graph में कई nodes हो सकते हैं, और nodes directed connections से जुड़े होते हैं
  • हर node में सामान्यतः ये तत्व होते हैं
    • @type: node क्या है, यह बताता है। उदाहरण: WebSite, SoftwareApplication
    • @id: आमतौर पर URL के अंत में unique hash value जोड़कर बना node identifier
    • properties: node की विशेषताओं को बताने वाले key-value pairs
  • web crawler एक ही @id साझा करने वाले nodes की properties को कई पेजों में merge कर सकते हैं
  • लेकिन केवल एक पेज पढ़ने वाले scraper या LLM properties को merge नहीं करते, इसलिए कई पेजों में JSON-LD reuse करते समय इस अंतर को ध्यान में रखना चाहिए
  • @id के लिए #website जैसे hash को URL के अंत में जोड़कर node को uniquely identify करना recommended है

साइट और पेज का वर्णन करने वाले nodes

  • WebSite

    • WebSite साइट का metadata रखता है और crawler को यह तय करने के लिए संकेत देता है कि साइट को कैसे प्रदर्शित किया जाए
    • root page पर url, name, alternateName, description, inLanguage, publisher, image जैसी properties वाला विस्तृत version रखा जा सकता है
    • हर पेज में पूरा WebSite node डालना आवश्यक नहीं है
    • domain के root page को विस्तार से लिखें, और बाकी पेजों पर @type, @id, url, name वाला संक्षिप्त version भी पर्याप्त है
    • यह संक्षिप्त version सिर्फ एक पेज पढ़ने वाले crawler को साइट का नाम सही समझने के लिए आवश्यक context देता है

  • WebPage

    • WebPage मौजूदा पेज स्वयं, यानी HTML physical page को दर्शाता है
    • इसे BlogPosting जैसे content type से अलग समझना चाहिए; WebPage उस पेज को दर्शाता है जिसमें वह content मौजूद है
    • उदाहरण properties में url, isPartOf, name, inLanguage, breadcrumb शामिल हैं
    • ProfilePage, CollectionPage, WebPage के अधिक specific subtypes हैं
    • कम सामान्य subtypes को Schema.org की WebPage definition में देखा जा सकता है

व्यक्तिगत पहचान और profile pages

  • Person

    • व्यक्तिगत वेबसाइट के सभी पेजों में Person node जोड़ना recommended है
    • Person यह दर्शाता है कि साइट का मालिक कौन है, और Google के content quality signals के एक हिस्से के रूप में उपयोग होता है
    • LLM crawler भी अपने उत्तरों में किसे cite करना है, यह तय करने में Person information का बढ़ता हुआ उपयोग कर रहे हैं
    • WebSite के विपरीत, Person इतना महत्वपूर्ण context है कि इसे हर पेज में शामिल करना उचित है
    • महत्वपूर्ण properties ये हैं
      • url: root page की ओर संकेत करके node को anchor करता है
      • name, givenName, familyName: नाम को स्पष्ट रूप से दर्शाते हैं
      • image: संभव हो तो अपनी photo या संबंधित logo का उपयोग करके canonical image जोड़ें
      • sameAs: crawler को अन्य profiles बताता है, जिससे व्यक्ति की पहचान में मदद मिलती है
    • sameAs खास तौर पर सामान्य नाम वाले लोगों के लिए एक ही नाम वाले अन्य लोगों से अलग पहचान करने में उपयोगी है, और कई पेजों में knowledge graph representation बनाने में काम आता है
    • अन्य Person properties अधिक विवरण जोड़ने में उपयोगी हैं, लेकिन अनिवार्य नहीं हैं, और उन्हें कम करने पर प्रभाव भी सीमित रहता है

  • ProfilePage

    • ProfilePage साइट के भीतर किसी विशेष व्यक्ति के बारे में पेज को दर्शाता है
    • अगर आप home page पर अपना परिचय देते हैं तो इसे वहीं उपयोग कर सकते हैं, और यदि अलग about page है तो वहाँ रखना अधिक उपयुक्त हो सकता है
    • isPartOf के माध्यम से इसे व्यापक WebSite node से जोड़ना महत्वपूर्ण है
    • mainEntity crawler को बताता है कि पेज किसके बारे में है
    • dateCreated, dateModified crawler के लिए freshness signal के रूप में उपयोगी हैं, लेकिन यदि साइट में इन्हें आसानी से उपलब्ध कराना संभव नहीं है तो बहुत चिंता की बात नहीं है

projects और breadcrumb path

  • SoftwareApplication

    • यदि पेज किसी software को प्रस्तुत करता है, तो SoftwareApplication node के माध्यम से उस software का metadata देना अच्छा है
    • और अधिक specific types के रूप में MobileApplication, WebApplication, VideoGame उपयोग किए जा सकते हैं
    • url property उस स्थान की ओर संकेत करनी चाहिए जहाँ project deploy या distribute किया गया है
    • उदाहरण के लिए crates.io जैसा distribution page उपयुक्त है
    • sameAs project से जुड़े अन्य पेजों, जैसे source code repository, के लिए उपयोग करें
    • applicationCategory के valid values Google की SoftwareApplication definition में देखे जा सकते हैं
    • FOSS project होने पर भी offers शामिल करना चाहिए और price को 0 पर सेट करना चाहिए

  • BreadcrumbList

    • BreadcrumbList root page को छोड़कर लगभग सभी पेजों में उपयोगी है
    • यह पेज का classification path दर्शाता है, और इसका वास्तविक URL path से बिल्कुल मेल खाना आवश्यक नहीं है
    • search engine इसका उपयोग यह नियंत्रित करने में कर सकता है कि किसी विशेष पेज का path कैसे दिखाया जाए
    • यदि साइट का path पहले से छोटा है, तो इस node का लाभ कम है और इसे छोड़ा जा सकता है
    • लंबे path वाली साइटों में BreadcrumbList search results के path को छोटा करने में उपयोगी हो सकता है

सूची, ब्लॉग और लेख पेज

  • CollectionPage

    • CollectionPage WebPage का subtype है, जिसका उपयोग मुख्यतः सूची वाले पेजों के लिए किया जाता है
    • उदाहरण के लिए अन्य profiles को एकत्र करने वाला /elsewhere/ पेज या blog posts की सूची वाला /blog/ पेज
    • about के माध्यम से संबंधित Person node जोड़ा जा सकता है
    • breadcrumb को हमेशा मौजूदा पेज के सही BreadcrumbList से जोड़ा जाना चाहिए

  • Blog

    • Blog node को ब्लॉग के index या home page में जोड़ा जाता है
    • यह WebSite और अलग-अलग BlogPosting के बीच intermediate node की भूमिका निभाता है
    • dateModified freshness signal के रूप में उपयोगी है, लेकिन यदि इसे आसानी से उपलब्ध नहीं कराया जा सकता तो छोड़ा जा सकता है
    • license crawler को बताता है कि लेख किस शर्त पर उपयोग किया जा सकता है
    • व्यक्तिगत वेबसाइट में publisher को Organization की जगह Person पर सेट किया जा सकता है
    • Google documentation अब पहले की तरह नहीं, बल्कि Person को भी valid रूप से अनुमति देता है, और व्यक्तिगत वेबसाइटों के लिए यह अधिक सटीक हो सकता है

  • BlogPosting

    • BlogPosting हर प्रकाशित blog post में शामिल होना चाहिए
    • यह crawler को लेख को अधिक सटीक रूप से प्रस्तुत करने के लिए अतिरिक्त जानकारी देता है
    • इसका उपयोग search results में अधिक सटीक placement और समृद्ध विवरण दिखाने के लिए किया जा सकता है
    • व्यक्तिगत साइटों में author और publisher का एक ही Person node की ओर संकेत करना स्वीकार्य है
    • image property को लेख के link preview में उपयोग होने वाली OG image के साथ मिलाना अच्छा है
    • license का उपयोग लेख की उपयोग शर्तें दर्शाने के लिए किया जा सकता है

न्यूनतम implementation और लागू करने के मानदंड

  • व्यक्तिगत साइट के लिए आवश्यक JSON-LD को पेज के स्वभाव के अनुसार चयनात्मक रूप से कॉन्फ़िगर किया जा सकता है
  • build step के बिना static site होने पर भी root page में कम-से-कम नीचे दिए गए nodes जोड़कर लाभ लिया जा सकता है
    • WebSite
    • ProfilePage
    • Person
  • यदि ब्लॉग है, तो Blog और BlogPosting जोड़ें, और post list या बाहरी profile list pages में CollectionPage का उपयोग किया जा सकता है
  • project introduction pages में SoftwareApplication, और root के अलावा अन्य pages में BreadcrumbList पर विचार किया जा सकता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 8 시간 전
Hacker News टिप्पणियाँ

  • उपमा लें तो यह पिछला युद्ध फिर से लड़ने जैसा लगता है
    मेरी WWW साइट के नज़रिए से, Google अब लोगों को मेरी असली लिखाई तक भेजने के बजाय ऊपर गलती-भरे लंबे LLM-generated summary दिखा रहा है
    ‘breadcrumb’ या domain की जगह अच्छा display name मिल जाना इस हकीकत को हल नहीं करता कि Google ऐसी चीज़ों को चाहे जैसे सजाए-सँवारे, उनकी प्राथमिकता कम कर रहा है
    यानी ऐसी चीज़ पर बहुत मेहनत लग रही है जिसे साइट पर सीधे आने वाले लोग कभी नहीं देखेंगे, और Google इस्तेमाल करने वालों के लिए भी वह Google के अपने LLM-युक्त version के नीचे धकेली हुई, ढूँढना मुश्किल चीज़ बन गई है

    • अगर आप ऐसी दुनिया चाहते हैं जहाँ इस तरह का data मायने रखे, तो पहले बीज बोने होंगे
      चाहे Google इसका इस्तेमाल न करे, अगर पूरा इंटरनेट इस तरह का metadata अपनाए तो LLM scraping पर निर्भर न रहने वाले प्रतियोगियों के लिए विकल्प देने की ज़मीन तैयार होगी
      Google के आगे झुकने से सिर्फ उसकी पकड़ और मज़बूत होगी, प्रतियोगियों के लिए entry barrier बढ़ेगी, और उन्हें भी वही तकनीक अपनाने पर मजबूर होना पड़ेगा
    • बिल्कुल। हमारी company भी अब Google search में ऐसे दिखती है:
      $STATE-आधारित IT company, जो Midwest businesses के लिए practical AI workflow और information management solutions बनाने में विशेषज्ञ है। यह agile fixed-price contract model पर काम करती है और enterprise-जैसी फूली हुई संरचना से बचते हुए ठोस नतीजे देने पर केंद्रित है
      मुझे तो पता ही नहीं था कि हम अब practical AI workflow देते हैं
      फिर यह मिलते-जुलते लेकिन साफ़ तौर पर अलग नाम वाली competitor company का नाम मिला देता है, और मुझे executive बना कर दिखाता है। गनीमत बस यह है कि competitor ने अपनी contact info को “बुक अ कंसल्टेशन” form के पीछे छिपा रखा है, इसलिए सिर्फ हमारी contact info दिखती है
    • अब मैं Google को अपनी साइट crawl और index करने भी नहीं देता
    • अब Google भी उन targets में शामिल है जहाँ “अगर bot साइट में आए तो उसे 10GB zipbomb मिले”
      अभी यह कोई value add नहीं कर रहा, बस और समस्याएँ पैदा कर रहा है
    • सही बात। कई सालों तक मैंने website में ढेर सारे microdata tags और attributes डाले, इस उम्मीद में कि ट्रैफ़िक मिलेगा
      नतीजा बस इतना हुआ कि Google से लोगों को बाहर न जाने देने वाली उसकी AI को train करने में मदद मिली

  • अगर आप practical सोच रखते हैं, तो website के लिए Google docs में JSON-LD पढ़ने की सलाह दूँगा
    https://developers.google.com/search/docs/appearance/structu...
    आप यह भी देखेंगे कि बहुत-सी जानकारी सिर्फ कुछ खास sites के लिए ही relevant है। Rotten Tomatoes JSON-LD के ज़रिए फिल्म critics ratings प्रकाशित कर सकता है, लेकिन मैं फिल्म review लिखूँ तो वह मेरे लिए खास मायने नहीं रखता
    JSON-LD आसान है और search engines सच में इसका इस्तेमाल करते हैं, इसलिए यह ठीक है। यह webpage के अंदर की जानकारी को duplicate कर सकता है, लेकिन मुझे लगता है कि जानकारी दस्तावेज़ में ठीक एक बार ही दिखाई दे और सब कुछ पूरी तरह annotate हो — यह सपना गोलाकार गाय और द्रव्यमान-रहित रस्सी जैसी आदर्श कल्पना के ज़्यादा करीब है
    webpage बनाने में इंसानी मेहनत लगती है, और अंतिम नतीजे में थोड़ी duplication होना ठीक है

    • बड़ी site न होने पर भी movie reviews में JSON-LD इस्तेमाल किया जा सकता है
      मैं अपनी site पर books, games और movie reviews में इसका इस्तेमाल करता हूँ, और लगता है कि ज़्यादातर search engines में star ratings जैसी जानकारी दिखती है
    • 403. That’s an error.
      यह कहता है कि client को इस server के /search/docs/appearance/structured-data/intro-structured-data URL को लाने की अनुमति नहीं है
    • लेकिन data duplicate करने से पानी की खपत बढ़ेगी न। /s

  • rich link previews के लिए OpenGraph, JSON-LD की तुलना में, कहीं ज़्यादा बार supported होता है
    अगर मकसद search engine optimization है, तो search engines जिन JSON-LD प्रकारों को support करते हैं वे बहुत specific और सीमित हैं। target search engine के docs, यानी Google[1] या Bing[2], देखना और उन्हें ठीक वैसे ही follow करना कहीं बेहतर है; बाकी लगभग समय की बर्बादी है
    search engines के बाहर भी, अगर कोई खास उद्देश्य नहीं है, तो JSON-LD आम तौर पर बेकार है। अगर JSON-LD की कोई ठोस ज़रूरत है, तो जो data उपयोगी होगा वही डालें; उसके अलावा data डालना हवा में चिल्लाने जैसा है
    IndieWeb[3] structured data का इस्तेमाल करता है, लेकिन JSON-LD को DRY का उल्लंघन मानता है और इसकी जगह Microformats[4] का उपयोग करता है
    0: https://ogp.me
    1: https://developers.google.com/search/docs/appearance/structu...
    2: https://www.bing.com/webmasters/help/marking-up-your-site-wi...
    3: https://indieweb.org/
    4: https://microformats.org/

  • हर वेबसाइट पर असल में जो लागू करना चाहिए, वह Schema.org vocabulary का इस्तेमाल करने वाला structured data है
    JSON-LD उसका एक तरीका है, और RDFa व Microdata भी हैं
    इसे पहली बार सीखते समय मैंने इस लेख का सहारा लिया था, और यह सिफारिश करने लायक है: https://neilpatel.com/blog/get-started-using-schema/
    कौन-सा data जोड़ना है, यह आप इस टूल से देख सकते हैं: https://technicalseo.com/tools/schema-markup-generator/
    पूरी सूची schema.org साइट पर देखी जा सकती है: https://schema.org/docs/schemas.html

  • कुछ साल पहले मुझे पता चला कि फ्लाइट टिकट एम्बेड होना या shipping tracking info दिखने जैसी चमकदार email features सब ईमेल के अंदर JSON-LD से लागू होती हैं
    हालांकि, मेरी जानकारी में सिर्फ Gmail इसे सपोर्ट करता है
    अतिरिक्त जानकारी: https://www.emailonacid.com/blog/article/email-development/s...

    • Outlook और iCloud भी टिकट या reservation जैसी कुछ features को सपोर्ट करते हैं

  • मुझे जिज्ञासा है कि क्या ये properties वास्तव में search visibility में मदद करती हैं, या फिर सिर्फ search engine के लिए यूज़र को search results page पर रोके रखना आसान बनाती हैं

    • JSON-LD जोड़ने के बाद Google ने मेरी साइट के अंदर जाने वाले sublinks दिखाने शुरू कर दिए। वह ठीक था
    • अगर यह business site है, तो JSON-LD map platforms को data देने में इस्तेमाल हो सकता है
      जैसे address, business hours, phone number, menu वगैरह

  • semantic HTML पहले से मौजूद है, फिर भी अजीब बात है कि ब्राउज़र जिस script टैग को प्रोसेस नहीं करता, उसके अंदर custom अजीब JSON से वेबसाइट का अर्थ फिर से व्यक्त करना पड़ता है

    • मैंने अपनी वेबसाइट पर JSON-LD इस्तेमाल किया है, और मुझे लगता है कि यह semantic HTML से अलग ज़रूरत पूरी करता है
      semantic HTML उन चीज़ों को तय करता है जिन्हें ब्राउज़र प्रोसेस करता है, जैसे title और heading। JSON-LD data metadata है, जैसे created date, modified date, tags, author
      इन्हें HTML के अंदर microdata से भी व्यक्त किया जा सकता है, लेकिन JSON-LD आसान है, इसलिए मैंने microdata का इस्तेमाल बंद कर दिया
      JSON-LD उसी data से भरा जाता है जिससे साइट generate होती है, और इसी metadata से 2024 के blog post की सूची या topic X से जुड़े सभी लेखों जैसे index pages भी बनते हैं। JSON-LD का मुख्य consumer search engine है
      अगर और चिढ़ना हो, तो यह सोचिए कि उसी पेज में OpenGraph metadata भी डाला जा रहा है। यानी एक ही पेज पर metadata के दो अलग फ़ॉर्मैट हैं
    • Microdata भी है, और अगर मैं गलत नहीं हूँ तो यह JSON-LD वाली ही vocabulary को सपोर्ट करता है। schema.org इसके लिए अच्छा resource है
      लेकिन JSON-LD कुछ समय से default बन गया है, कुछ-कुछ वैसे ही जैसे हमने broadly REST को छोड़कर RPC की तरफ रुख किया। मुझे नहीं पता कि आज भी बड़े parsers microdata को पूरी तरह सपोर्ट करते हैं या नहीं, और खासकर जब Google search visibility चाहने वाली e-commerce sites जैसे client sites बनाते थे, तब हम default रूप से LD ही इस्तेमाल करते थे
      semantic HTML से तुलना करते समय एक और बात ध्यान देने लायक है। semantic HTML markup structure को परिभाषित करने में मदद करता है, लेकिन यह real-world context जैसे “यह बिक्री के लिए product है” या “यह train timetable है” तक व्यक्त नहीं कर पाता
    • लगता है मैं लेख को पूरी तरह समझ नहीं पाया
      JSON-LD और script टैग के बिना भी HTML के अंदर Schema.org/FOAF/WikiData जैसी ontologies का इस्तेमाल किया जा सकता है
    • आदर्श दुनिया में server और browser content negotiation कर सकें, browser पहले वेबसाइट से सिर्फ JSON-LD मांगे, और फिर अपना internal renderer format इस्तेमाल करे
    • semantic HTML उस दायरे को कवर नहीं करता जिसे JSON-LD और दूसरे microformats संभालते हैं
      सिर्फ लेख में दिए उदाहरणों को देखें, तो सवाल उठता है कि person, breadcrumb list, software application, blog, blog post को दर्शाने वाले semantic elements कौन-से हैं
      semantic HTML का उद्देश्य screen reader इस्तेमाल करने वाले लोगों को “navigation” या “article” जैसे सामान्य elements में नेविगेट करने में मदद करना है

  • क्या यह बस OpenGraph को JSON में लिखना नहीं है? इसका फ़ायदा क्या है?

  • 2024 के बाद से हमारे content-driven marketing pages का traffic लगभग 85% गिर गया है
    जो बात समझ नहीं आती, वह यह है कि zero-click search results pages बढ़े हैं, फिर भी क्या Google को भी बड़ा नुकसान नहीं हुआ होगा?
    search results page ads का revenue, जो clicks पर आधारित है, उसे भी इसी तरह गंभीर रूप से गिरना चाहिए था, लेकिन इस परिकल्पना को खारिज या पुष्ट करने वाले कोई सार्वजनिक आँकड़े मुझे नहीं मिले

  • एक बिंदु के बाद सहजीवन का रिश्ता शोषण में बदल जाता है, और यह संतुलन बहुत नाज़ुक होता है
    वेबसाइटों का search engine की मदद से visibility पाना लंबे समय तक काफ़ी हद तक mutually beneficial रिश्ता था
    लेकिन अब स्थिति पूरी तरह उस दिशा में जा रही है जहाँ वेबसाइट मालिकों को अपनी मेहनत से बनाए काम से कुछ भी हासिल नहीं होता