तथ्यों की जांच (ClaimReview) का स्ट्रक्चर्ड डेटा

अगर आपके किसी वेब पेज पर दूसरों के दावों की समीक्षा दिखाई जाती है, तो आपके पास उस पेज पर ClaimReview स्ट्रक्चर्ड डेटा शामिल करने का विकल्प होता है. जब आपका पेज उस दावे के लिए खोज नतीजों में दिखता है, तो ClaimReview स्ट्रक्चर्ड डेटा आपके तथ्यों की जांच के छोटे वर्शन को Google Search के नतीजों में दिखा सकता है.

इस गाइड में ClaimReview स्ट्रक्चर्ड डेटा को लागू करने का तरीका बताया गया है. अगर आपको मैन्युअल तरीके से स्ट्रक्चर्ड डेटा नहीं जोड़ना है, तो तथ्यों की जांच के मार्कअप टूल को आज़माएं. ज़्यादा जानने के लिए, तथ्यों की जांच के मार्कअप टूल के बारे में जानकारी देखें.

स्ट्रक्चर्ड डेटा को जोड़ने का तरीका

स्ट्रक्चर्ड डेटा, किसी पेज के बारे में जानकारी देने और पेज के कॉन्टेंट को कैटगरी में बांटने का एक स्टैंडर्ड फ़ॉर्मैट है. अगर आपको स्ट्रक्चर्ड डेटा के बारे में ज़्यादा जानकारी नहीं है, तो स्ट्रक्चर्ड डेटा के काम करने का तरीका देखें.

स्ट्रक्चर्ड डेटा बनाने, उसकी जांच करने, और उसे रिलीज़ करने के बारे में खास जानकारी यहां दी गई है. वेब पेज में स्ट्रक्चर्ड डेटा जोड़ने के सिलसिलेवार निर्देशों के लिए, स्ट्रक्चर्ड डेटा कोडलैब (कोड बनाना सीखना) देखें.

  1. ज़रूरी प्रॉपर्टी जोड़ें. जिस फ़ॉर्मैट का इस्तेमाल हो रहा है उसके हिसाब से जानें कि पेज पर स्ट्रक्चर्ड डेटा कहां डालना है.
  2. दिशा-निर्देशों का पालन करें.
  3. ज़्यादा बेहतर नतीजों (रिच रिज़ल्ट) की जांच का इस्तेमाल करके, अपने कोड की पुष्टि करें. साथ ही, सभी ज़रूरी गड़बड़ियों को ठीक करें. ऐसी अन्य समस्याओं को भी ठीक करें जो टूल में फ़्लैग की जा सकती हैं. ऐसा इसलिए, क्योंकि इससे आपके स्ट्रक्चर्ड डेटा की क्वालिटी को बेहतर बनाने में मदद मिल सकती है. हालांकि, ज़्यादा बेहतर नतीजों (रिच रिज़ल्ट) में शामिल होने के लिए, यह ज़रूरी नहीं है.
  4. स्ट्रक्चर्ड डेटा वाले कुछ पेजों को डिप्लॉय करें. इसके बाद, यूआरएल जांचने वाला टूल इस्तेमाल करके देखें कि Google को पेज कैसा दिखेगा. पक्का करें कि Google आपका पेज ऐक्सेस कर सकता हो. साथ ही, देखें कि उस पेज को robots.txt फ़ाइल और noindex टैग से ब्लॉक न किया गया हो या लॉग इन करना ज़रूरी न हो. अगर पेज ठीक लगता है, तो Google को अपने यूआरएल फिर से क्रॉल करने के लिए कहा जा सकता है.
  5. Google को आगे होने वाले बदलावों की जानकारी देने के लिए हमारा सुझाव है कि आप साइटमैप सबमिट करें. Search Console साइटमैप एपीआई की मदद से, इसे ऑटोमेट भी किया जा सकता है.

उदाहरण

सोचिए कि एक ऐसा पेज है जो धरती के सपाट होने के दावे की जांच करता है. अगर पेज में ClaimReview एलिमेंट है, तो Google Search के नतीजों में "the world is flat" खोजने पर, नतीजा कुछ ऐसा दिख सकता है (ध्यान रखें कि असल डिज़ाइन अलग हो सकता है):

किसी पेज से जुड़े एक दावे की समीक्षा

तथ्यों की जांच वाले पेज पर मौजूद स्ट्रक्चर्ड डेटा का एक उदाहरण:


<html>
  <head>
    <title>The world is flat</title>
    <script type="application/ld+json">
    {
      "@context": "https://schema.org",
      "@type": "ClaimReview",
      "url": "https://example.com/news/science/worldisflat.html",
      "claimReviewed": "The world is flat",
      "itemReviewed": {
        "@type": "Claim",
        "author": {
          "@type": "Organization",
          "name": "Square World Society",
          "sameAs": "https://example.flatworlders.com/we-know-that-the-world-is-flat"
        },
        "datePublished": "2024-06-20",
        "appearance": {
          "@type": "OpinionNewsArticle",
          "url": "https://example.com/news/a122121",
          "headline": "Square Earth - Flat earthers for the Internet age",
          "datePublished": "2024-06-22",
          "author": {
            "@type": "Person",
            "name": "T. Tellar"
          },
          "image": "https://example.com/photos/1x1/photo.jpg",
          "publisher": {
            "@type": "Organization",
            "name": "Skeptical News",
            "logo": {
              "@type": "ImageObject",
              "url": "https://example.com/logo.jpg"
            }
          }
        }
      },
      "author": {
        "@type": "Organization",
        "name": "Example.com science watch"
      },
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": "1",
        "bestRating": "5",
        "worstRating": "1",
        "alternateName": "False"
      }
    }
    </script>
  </head>
  <body>
  </body>
</html>

ज़रूरी योग्यता

Google इस बात की गारंटी नहीं देता कि तथ्यों की जांच को खोज नतीजों में दिखाया जाएगा. भले ही, आपके पेज को ज़्यादा बेहतर नतीजों (रिच रिज़ल्ट) की जांच के मुताबिक, सही तरीके से मार्कअप किया गया हो. स्ट्रक्चर्ड डेटा का इस्तेमाल करने से कोई सुविधा दिखने लगती है. हालांकि, यह इस बात की गारंटी नहीं है कि सुविधा मौजूद ही होगी. Google का एल्गोरिदम, प्रोग्राम के ज़रिए यह तय करता है कि तथ्यों की जांच वाला कॉन्टेंट, रिच रिज़ल्ट में दिखने की ज़रूरी शर्तें पूरी करता है या नहीं. इसमें कई तरह के वैरिएबल अहम होते हैं, जिनमें ये दिशा-निर्देश भी शामिल हैं.

तथ्यों की जांच वाले कॉन्टेंट को, Google Search पर रिच रिज़ल्ट में तथ्यों की जांच के तौर पर दिखाने के लिए, आपको इन ज़रूरी शर्तों को पूरा करना होगा:

  • आपकी साइट पर, ClaimReview स्ट्रक्चर्ड डेटा मार्कअप वाले कई पेज होने चाहिए.
  • आपको स्ट्रक्चर्ड डेटा के लिए दिए गए सभी दिशा-निर्देशों और Google Search पर कॉन्टेंट दिखाने के बुनियादी दिशा-निर्देशों का पालन करना होगा.
  • स्ट्रक्चर्ड डेटा और पेज के कॉन्टेंट में अलग-अलग बातें नहीं होनी चाहिए (उदाहरण के लिए, अगर स्ट्रक्चर्ड डेटा के मुताबिक दावा सही है और पेज पर मौजूद कॉन्टेंट के मुताबिक दावा गलत था). इसलिए, पक्का करें कि कॉन्टेंट और स्ट्रक्चर्ड डेटा, दोनों में एक जैसी जानकारी हो. उदाहरण के लिए, दोनों में यह बताया जाए कि दावा सही है.
  • आपको Google News की सामान्य गाइडलाइन के मुताबिक, जवाबदेही, पारदर्शिता, किसी चीज़ को पढ़ने लायक बनाने, और साइट पर चीज़ों को गलत तरीके से पेश न करने से जुड़े मानकों को पूरा करना होगा.
  • आपके पास सुधार करने की नीति या ऐसी व्यवस्था होनी चाहिए जिसकी मदद से उपयोगकर्ता गड़बड़ियों की शिकायत कर सके.
  • यह सुविधा राजनैतिक इकाइयों (जैसे कि कैंपेन, पार्टियों या चुने गए अधिकारियों) के लिए बनी वेबसाइटों के लिए नहीं है.
  • आपके पाठक, लेख के मुख्य हिस्से में दावों और उनकी जांच का आसानी से पता लगा सकते हैं. आपके उपयोगकर्ता समझ सकते हैं कि किस कॉन्टेंट की जांच की गई है और क्या नतीजे मिले.
  • ऐसे खास दावे को साफ़ तौर पर एट्रिब्यूट देना ज़रूरी है जिसमें किसी के मूल (आपकी वेबसाइट से अलग) का आकलन किया जा रहा हो. भले ही, वह कोई वेबसाइट हो, सार्वजनिक बयान हो, सोशल मीडिया हो या दूसरा कोई ऐसा स्रोत हो जिसके बारे में पता लगाया जा सकता हो.
  • आपका तथ्यों की जांच का विश्लेषण, जानकारी के स्रोतों और अपनाए गए तरीकों के बारे में पता करने लायक और पारदर्शी होना चाहिए. साथ ही, यह जानकारी जिन मूल स्रोतों से ली गई है उनके बारे में संदर्भ के साथ बताएं.

तकनीकी दिशा-निर्देश

  • किसी सिंगल फ़ैक्ट चेक (एक तथ्य की जांच) वाला रिच रिज़ल्ट (ज़्यादा बेहतर नतीजा) पाने के लिए, पेज पर सिर्फ़ एक ClaimReview एलिमेंट होना चाहिए. अगर हर पेज पर एक से ज़्यादा ClaimReview एलिमेंट जोड़े जाते हैं, तो पेज पर किसी एक तथ्य की जांच का ज़्यादा बेहतर नतीजा (रिच रिज़ल्ट) नहीं दिखेगा.
  • अगर ClaimReview एलिमेंट वाले पेज पर फ़ैक्ट चेक और आकलन की पूरी जानकारी न दी जा सके, तो कम से कम शब्दों में खास जानकारी ज़रूर दी जानी चाहिए.
  • कोई खास ClaimReview, आपकी साइट के सिर्फ़ एक पेज पर होना चाहिए. एक जैसे तथ्यों की जांच को कई पेजों पर तब तक न दोहराएं, जब तक वे एक ही पेज के अलग-अलग वर्शन न हों (जैसे कि किसी पेज के मोबाइल और डेस्कटॉप वर्शन पर एक ही ClaimReview पोस्ट किया जा सकता है).
  • अगर आपकी वेबसाइट पर, तथ्यों की जांच वाले लेख दूसरी वेबसाइटों से इकट्ठा करके दिखाए जाते हैं, तो पक्का करें कि उन सभी लेखों में, शर्तों का पालन किया गया हो. साथ ही, तथ्यों की जांच करने वाली उन सभी वेबसाइटों की सूची दें जहां से ये लेख इकट्ठा किए जाते हैं. यह सूची सभी के लिए उपलब्ध होनी चाहिए और इसे ऐक्सेस करने के लिए किसी पासवर्ड की ज़रूरत नहीं होनी चाहिए.

अलग-अलग तरह के स्ट्रक्चर्ड डेटा की जानकारी

तथ्यों की जांच लागू करने के लिए, ऐसे स्ट्रक्चर्ड डेटा की ज़रूरत होती है:

आपका कॉन्टेंट ज़्यादा बेहतर नतीजे (रिच रिज़ल्ट) में दिखे, इसके लिए ज़रूरी प्रॉपर्टी जोड़नी होंगी. अपने कॉन्टेंट के बारे में ज़्यादा जानकारी जोड़ने के लिए, सुझाई गई प्रॉपर्टी भी शामिल करें. इससे उपयोगकर्ताओं को बेहतर अनुभव मिल सकता है.

ClaimReview

ClaimReview की पूरी जानकारी schema.org/ClaimReview पर मौजूद है. Google पर काम करने वाली प्रॉपर्टी ये हैं:

ज़रूरी प्रॉपर्टी
claimReviewed

Text

जांच किए जा रहे दावे के बारे में कम शब्दों में खास जानकारी. इसमें 75 से कम वर्ण रखने की कोशिश करें, ताकि मोबाइल पर दिखाते समय यह कम से कम रैप हो.

reviewRating

Rating

दावे का आकलन. इस ऑब्जेक्ट पर संख्या और शब्द, दोनों आकलन काम करते हैं. फ़िलहाल, खोज नतीजों में सिर्फ़ शब्दों वाली वैल्यू ही दिखाई जाती है.

तथ्यों की जांच के अलग-अलग प्रोजेक्ट में कई तरह की रेटिंग स्कीम होती हैं, जिनमें खास तौर पर बीच की वैल्यू के लिए थोड़े-बहुत फ़र्क़ हो सकते हैं. संख्या वाली रेटिंग का मतलब साफ़ तौर पर समझाने के लिए, यह ज़रूरी है कि इस तरह की रेटिंग स्कीम, दस्तावेज़ के रुप में रिकॉर्ड की जाएं. टेक्स्ट की रेटिंग के सिस्टम में, फ़ैक्ट चेक (तथ्यों की जांच) वाले उन सभी कॉन्टेंट के लिए जिनमें संख्या वाले स्कोर होते हैं, कम से कम कोई संख्या ज़रूर होनी चाहिए.

  • 1 = "गलत"
  • 2 = "ज़्यादातर गलत"
  • 3 = "आधा सही"
  • 4 = "ज़्यादातर सही"
  • 5 = "सही"

ज़्यादा जानकारी के लिए, रेटिंग देखें.

url

URL

उस पेज का लिंक जिसमें फ़ैक्ट चेक (तथ्यों की जांच) से जुड़े पूरे लेख को होस्ट किया जाता है.

इस यूआरएल वैल्यू का डोमेन वही डोमेन होना चाहिए या उस डोमेन का सबडोमेन होना चाहिए जिस पर, ClaimReview एलिमेंट वाला पेज होस्ट किया जाता है. दूसरे वेबलिंक पर भेजने वाले या छोटे किए गए यूआरएल (जैसे कि g.co/searchconsole) ठीक नहीं किए गए हैं. ये यहां काम नहीं करेंगे.

author

Organization या Person

तथ्यों की जांच वाले लेख का प्रकाशक, न कि दावे का प्रकाशक. author को कोई संगठन या व्यक्ति होना चाहिए. author में इनमें से कम से कम एक प्रॉपर्टी मौजूद होती है:

name Text

तथ्यों की जांच को प्रकाशित करने वाले संगठन का नाम.

url

URL

तथ्यों की जांच के प्रकाशक का यूआरएल. यह कोई होम पेज, संपर्क की जानकारी वाला पेज या ऐसा ही कोई दूसरा पेज हो सकता है.

Google, अलग-अलग फ़ीचर के बारे में लिखने वाले लेखकों को बेहतर तरीके से समझ सके, इसके लिए, लेखक के मार्कअप से जुड़े सबसे सही तरीके अपनाएं.

itemReviewed

Claim

किए जा रहे दावे की जानकारी देने वाली कोई चीज़. ज़्यादा जानकारी के लिए, Claim देखें:

Claim

Claim की पूरी जानकारी schema.org/Claim पर मौजूद है.

appearance

URL या CreativeWork

CreativeWork का एक लिंक या इनलाइन जानकारी, जिसमें यह दावा दिखता है.

हमारा सुझाव है कि आप appearance या firstAppearance जोड़ें. आपको दोनों जोड़ने की ज़रूरत नहीं है.

author

Organization या Person

दावे का लेखक, न कि तथ्यों की जांच का लेखक. अगर दावे का कोई लेखक नहीं है, तो author प्रॉपर्टी को शामिल न करें. अगर आप author को शामिल करते हैं, तो इन प्रॉपर्टी के बारे में बताएं:

nameText, ज़रूरी

दावे का प्रकाशक. प्रकाशक कोई व्यक्ति या संगठन हो सकता है.

sameAs URL, सुझाया गया

उस पक्ष को दर्शाता है जो दावा कर रहा है, भले ही पार्टी Person या Organization हो. जब कई प्रकाशक एक ही दावे पर रिपोर्ट करते हैं, तो appearance प्रॉपर्टी को दोहराया जा सकता है. जब कई पार्टियां असल में एक जैसा दावा करती हैं, तो author प्रॉपर्टी को दोहराया जा सकता है.

यूआरएल इनमें से किसी का हो सकता है:

  • दावा करने वाले संगठन का होम पेज.
  • दावा करने वाली पार्टी के बारे में जानकारी देने वाला कोई दूसरा सही यूआरएल. जैसे, किसी व्यक्ति या संगठन के Wikipedia या Wikidata में मौजूद जानकारी का यूआरएल.
datePublished

DateTime या Date

वह तारीख, जब दावा किया गया था या जब लोगों को उसके बारे में पता चला था (उदाहरण के लिए, जब वह सोशल नेटवर्क पर लोकप्रिय हुआ).

firstAppearance

URL या CreativeWork

CreativeWork का लिंक या इनलाइन जानकारी, जिसमें यह खास दावा सबसे पहले दिखता है.

हमारा सुझाव है कि आप appearance या firstAppearance जोड़ें. आपको दोनों जोड़ने की ज़रूरत नहीं है.

Rating

Rating की पूरी जानकारी schema.org/Rating पर मौजूद है.

ज़रूरी प्रॉपर्टी
alternateName

Text

ClaimReview.reviewRating को असाइन की गई सही रेटिंग. यह ऐसे छोटे शब्दों या वाक्यांशों में होनी चाहिए जिसे लोग पढ़ सकें. यह वैल्यू खोज के नतीजों में मौजूद तथ्यों की जांच में दिखाई जाती है. जैसे कि: "सही" या "अक्सर सही".

अगर लंबे वाक्य का इस्तेमाल कर रहे हैं, तो पक्का करें कि वाक्य की शुरुआत में ही मतलब बता दिया गया हो. डिसप्ले में फ़िट करने के लिए वाक्य को छोटा किया जा सकता है. जैसे कि: "ज़्यादातर बातें सही हैं, लेकिन कुल-मिलाकर पूरा दावा कुछ हद तक गुमराह करने वाला है"

bestRating

Number

अंकों में रेटिंग के लिए, सबसे खराब से लेकर सबसे अच्छी रेटिंग के पैमाने पर वह वैल्यू जो सबसे अच्छी रेटिंग के लिए हो. worstRating से ज़्यादा होना चाहिए. यह ज़रूरी है कि संख्या के तौर पर आकलन किया जा सके. उदाहरण: 4

name

Text

alternateName की तरह है और alternateName न दिए जाने पर इस्तेमाल किया जाता है. हालांकि, हमारी सलाह है कि आप name के बजाय alternateName प्रॉपर्टी दें.

ratingValue

Number

इस दावे की अंकों में रेटिंग, worstRatingbestRating के बीच होनी चाहिए. पूर्णांक वैल्यू का सुझाव दिया जाता है, लेकिन ये ज़रूरी नहीं हैं. अंकों में रेटिंग bestRating के जितनी करीब होती है, उतनी ही सही होती है. यह वैल्यू worstRating के जितना करीब होती है, उतनी ही गलत होती है. अंकों में दी गई रेटिंग ऐसी होनी चाहिए जिसका आकलन संख्या में किया जा सके. उदाहरण: 4

worstRating

Number

अंकों में रेटिंग के लिए, सबसे खराब से लेकर सबसे अच्छी रेटिंग के पैमाने पर वह वैल्यू जो सबसे खराब रेटिंग के लिए हो. bestRating से कम होना चाहिए. यह ज़रूरी है कि संख्या के तौर पर आकलन किया जा सके. 1 का कम से कम मान होना चाहिए. उदाहरण: 1

使用 Search Console 监控富媒体搜索结果

Search Console 是一款工具,可帮助您监控网页在 Google 搜索结果中的显示效果。即使没有注册 Search Console,您的网页也可能会显示在 Google 搜索结果中,但注册 Search Console 能够帮助您了解 Google 如何查看您的网站并做出相应的改进。建议您在以下情况下查看 Search Console:

  1. 首次部署结构化数据后
  2. 发布新模板或更新代码后
  3. 定期分析流量时

首次部署结构化数据后

等 Google 将网页编入索引后,请在相关的富媒体搜索结果状态报告中查看是否存在问题。 理想情况下,有效项目数量会增加,而无效项目数量不会增加。如果您发现结构化数据存在问题,请执行以下操作:

  1. 修正无效项目
  2. 检查实际网址,核实问题是否仍然存在。
  3. 使用状态报告请求验证

发布新模板或更新代码后

如果对网站进行重大更改,请监控结构化数据无效项目的增幅。
  • 如果您发现无效项目增多了,可能是因为您推出的某个新模板无法正常工作,或者您的网站以一种新的错误方式与现有模板交互。
  • 如果您发现有效项目减少了(但无效项目的增加情况并不对应),可能是因为您的网页中未再嵌入结构化数据。请通过网址检查工具了解导致此问题的原因。

定期分析流量时

请使用效果报告分析您的 Google 搜索流量。数据将显示您的网页在 Google 搜索结果中显示为富媒体搜索结果的频率、用户点击该网页的频率以及网页在搜索结果中的平均排名。您还可以使用 Search Console API 自动提取这些结果。

समस्या का हल करना

अगर आपको स्ट्रक्चर्ड डेटा लागू करने या डीबग करने में कोई समस्या आ रही है, तो यहां कुछ ऐसे रिसॉर्स दिए गए हैं जिनसे आपको मदद मिल सकती है.