तथ्यों की जांच (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 स्ट्रक्चर्ड डेटा मार्कअप वाले कई पेज होने चाहिए.
  • आपको स्ट्रक्चर्ड डेटा से जुड़े सभी दिशा-निर्देशों और 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 自动提取这些结果。

问题排查

如果您在实施或调试结构化数据时遇到问题,请查看下面列出的一些实用资源。

  • 如果您使用了内容管理系统 (CMS) 或其他人负责管理您的网站,请向其寻求帮助。请务必向其转发列明问题细节的任何 Search Console 消息。
  • Google 不能保证使用结构化数据的功能一定会显示在搜索结果中。如需查看导致 Google 无法将您的内容显示为富媒体搜索结果的各种常见原因,请参阅结构化数据常规指南
  • 您的结构化数据可能存在错误。请参阅结构化数据错误列表
  • 如果您的网页受到结构化数据手动操作的影响,其中的结构化数据将会被忽略(但该网页仍可能会出现在 Google 搜索结果中)。如需修正结构化数据问题,请使用“人工处置措施”报告
  • 再次查看相关指南,确认您的内容是否未遵循指南。问题可能是因为出现垃圾内容或使用垃圾标记导致的。不过,问题可能不是语法问题,因此富媒体搜索结果测试无法识别这些问题。
  • 针对富媒体搜索结果缺失/富媒体搜索结果总数下降进行问题排查
  • 请等待一段时间,以便 Google 重新抓取您的网页并重新将其编入索引。请注意,网页发布后,Google 可能需要几天时间才会找到和抓取该网页。有关抓取和索引编制的常见问题,请参阅 Google 搜索抓取和索引编制常见问题解答
  • Google 搜索中心论坛中发帖提问。