रिच रिज़ल्ट आइटम की स्टेटस रिपोर्ट

देखें कि Google को आपकी साइट पर ज़्यादा बेहतर नतीजे (रिच रिज़ल्ट) वाले कौनसे आइटम मिले

जानें कि Google को आपकी साइट पर कौनसे रिच रिज़ल्ट आइटम मिले और उनसे जुड़ी कौनसी गड़बड़ियां मिलीं.

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

अगर आपने साइट पर ऐसे रिच रिज़ल्ट आइटम डाले हैं जिन्हें आपकी प्रॉपर्टी पर इस्तेमाल किया जा सकता है, लेकिन प्रॉपर्टी में आपको उनकी रिपोर्ट नहीं दिख रही है, तो न दिखने वाले रिच रिज़ल्ट देखें.

 

Search Console खोलें

 

Search Console में ज़्यादा बेहतर नतीजों (रिच रिज़ल्ट) पर निगरानी रखना - Google Search Console की ट्रेनिंग

रिपोर्ट देखना

Search Console के नेविगेशन पैनल में जाकर कोई रिपोर्ट खोलें. इन रिपोर्ट में पेज के बजाय, रिच रिज़ल्ट आइटम दिखते हैं. हालांकि, एक पेज पर एक ही या अलग-अलग तरह के एक या एक से ज़्यादा स्ट्रक्चर्ड डेटा आइटम होस्ट किए जा सकते हैं.

आपको कोई रिपोर्ट सिर्फ़ तब दिखेगी, जब Search Console में आपकी साइट पर मौजूद उस तरह के ज़्यादा रिच रिज़ल्ट आइटम से जुड़ा डेटा मौजूद हो. ऐसा तब भी होगा, अगर Search Console उस तरह के आइटम के लिए रिपोर्ट बनाता हो.

रिपोर्ट में खास जानकारी वाला पेज और ज़्यादा जानकारी वाला पेज होता है:

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

रिपोर्ट में क्या देखें

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

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

यहां यह तय करने का तरीका बताया गया है कि आपकी साइट पर रिच रिज़ल्ट आइटम की कौनसी गड़बड़ियां ज़्यादा गंभीर हैं, जिन्हें पहले ठीक करने की ज़रूरत है. साथ ही, उन गड़बड़ियों को ठीक करने का तरीका भी बताया गया है:

  1. रिच रिज़ल्ट आइटम की रिपोर्ट की खास जानकारी वाले पेज पर, चेतावनियों और मान्य आइटम को फ़िल्टर करें और सबसे पहले गड़बड़ियों पर ध्यान दें.
  2. जिन आइटम पर असर हुआ है उनकी संख्या के हिसाब से गड़बड़ियां ठीक करें:
    1. अगर गड़बड़ियों वाले चार्ट में किसी गड़बड़ी की संख्या में तेज़ बढ़ोतरी हुई है, तो टेबल की गड़बड़ी वाली लाइनों में इससे मिलती-जुलती बढ़ोतरी की संख्या ढूंढें.
    2. अपनी साइट की गड़बड़ी ठीक करें और देखें कि गड़बड़ी ठीक हुई या नहीं. साथ ही, पक्का करें कि वेब पर अब गड़बड़ियां न दिख रही हों. अपने स्ट्रक्चर्ड डेटा आइटम को देखने और समस्या हल करने में इस्तेमाल होने वाले अलग-अलग टूल के बारे में जानने के लिए, गड़बड़ियों की जांच करने के तरीके देखें.
    3. पुष्टि की प्रोसेस शुरू करने के लिए, समस्या की जानकारी वाले पेज पर वापस जाएं और समस्या ठीक होने की पुष्टि करें बटन पर क्लिक करें. इस प्रोसेस में कई दिन लग सकते हैं और आपको इससे जुड़ी सूचनाएं ईमेल से मिलती रहेंगी.
    4. अगर वह समस्या सभी जगहों पर ठीक हो चुकी है और समस्या ठीक होने की पुष्टि की जा चुकी है, तो जिन आइटम पर इस समस्या का असर हुआ था उनकी संख्या शून्य हो जाएगी. साथ ही, समस्या का स्टेटस अपडेट कर दिया जाएगा.
  3. गड़बड़ियां ठीक करते रहें.
  4. जब सभी गड़बड़ियां ठीक हो जाएं, तो चेतावनियों वाला फ़िल्टर हटा दें और चेतावनियां डीबग करना शुरू करें. ज़्यादातर चेतावनियां, आपके स्ट्रक्चर्ड डेटा में वैकल्पिक प्रॉपर्टी मौजूद न होने के बारे में होती हैं. रिच रिज़ल्ट में ज़्यादा जानकारी होने से, आपकी साइट पर आने वाले लोगों को ज़्यादा फ़ायदा होगा.
समस्या हल करने के लिए उपयोगी रिसॉर्स:

गड़बड़ियों की जांच करना

स्ट्रक्चर्ड डेटा की गड़बड़ियों की जांच करने के लिए, अलग-अलग टूल इस्तेमाल किए जा सकते हैं:

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

 

गड़बड़ियों में बढ़ोतरी की समस्या को हल करना
गड़बड़ियों में बढ़ोतरी की सबसे आम वजह, किसी ऐसे टेंप्लेट में गड़बड़ी होना है जिसे आपकी साइट के कई पेजों पर इस्तेमाल किया जा रहा है.

देखें कि गड़बड़ियों में यह बढ़ोतरी, आइटम के किसी ग्रुप में गड़बड़ी की गंभीरता की स्थिति में बदलाव होने की वजह से तो नहीं हुई है:

  1. अगर किसी गड़बड़ी की संख्या में ज़्यादा बढ़ोतरी दिखती है, तो पता करें कि क्या किसी दूसरी स्थिति (चेतावनी या मान्य) में, बढ़ी हुई संख्या जितनी ही कमी हुई है.
  2. अगर आपको मिलती-जुलती संख्या में कमी दिखती है, तो यह जांचें कि क्या यह कमी उन ही यूआरएल में हो रही है जिनमें बढ़ोतरी देखी गई थी.
  3. अगर आइटम की स्थिति बदली है, तो गड़बड़ियों की बढ़ोतरी जांचें और जानें कि ऐसा क्यों हुआ.

उदाहरण वाले किसी आइटम की गहराई से जांच (ड्रिल-डाउन) करके और गड़बड़ियों की जांच करने के ऊपर दिए गए तरीके से किसी समस्या को हल करें.

शामिल नहीं किए गए रिच रिज़ल्ट या रिच रिज़ल्ट की कुल संख्या में गिरावट आने की समस्या हल करना

रिपोर्ट में रिच रिज़ल्ट न दिखने की इनमें से कोई एक वजह हो सकती है:

  • फ़िलहाल, इस रिपोर्ट में सभी तरह के रिच रिज़ल्ट नहीं दिखते. ऐसे रिच रिज़ल्ट की सूची देखें जिनकी रिपोर्ट देखी जा सकती है.
  • सिर्फ़ इंडेक्स किए गए पेजों के रिच रिज़ल्ट दिखाए जा सकते हैं. आपकी साइट के सभी पेज क्राॅल न किए जाने की कई वजहें हो सकती हैं. अगर आपकी साइट बहुत बड़ी है, तो आपको साइट के स्ट्रक्चर्ड डेटा वाले पेजों की संख्या और रिपोर्ट में बताए गए रिच रिज़ल्ट की संख्या में काफ़ी अंतर दिख सकता है. अगर आपको अपनी साइट के रिच रिज़ल्ट में अचानक गिरावट दिखती है, तो देखें कि क्या आपके इंडेक्स किए गए पेजों में भी ऐसी गिरावट हुई है.
  • ऐसा हो सकता है कि Google ने अब तक पेज को क्रॉल न किया हो. Google को नए या अपडेट किए गए पेजों को क्रॉल करने में कुछ समय लग सकता है. Google को अपने यूआरएल को फिर से क्रॉल करने का अनुरोध किया जा सकता है. इंडेक्स करने के अनुरोध पर तुरंत कार्रवाई नहीं होती. इसमें एक हफ़्ता लग सकता है.
  • Google, इस पेज को ऐक्सेस नहीं कर सकता. यूआरएल की जांच करने वाले टूल का इस्तेमाल करके देखें कि Google पेज को ऐक्सेस कर सकता है या नहीं.
  • शायद, स्ट्रक्चर्ड डेटा इतना अमान्य है कि Google उसकी पहचान रिच रिज़ल्ट के रूप में न कर पाए. अपने पेज की जांच करने के लिए, रिच रिज़ल्ट जांचने वाला टूल इस्तेमाल करें. टूल में स्ट्रक्चर्ड डेटा का कोड चिपकाने के बजाय, लाइव पेज का यूआरएल देखें. अगर स्ट्रक्चर्ड डेटा मिल गया है, लेकिन इसे पार्स नहीं किया जा सकता, तो यह पार्स न किए जा सकने वाले स्ट्रक्चर्ड डेटा की रिपोर्ट में दिखेगा.
  • आपका रिच रिज़ल्ट शायद अभी आपके देश में उपलब्ध न हो. रिच रिज़ल्ट आपके देश के लिए उपलब्ध है या नहीं, यह देखने के लिए दस्तावेज़ पढ़ें.
  • ऐसा हो सकता है कि रिच रिज़ल्ट की कुल संख्या में कुछ पेज शामिल न हों. इस रिपोर्ट में आपके पेज का सिर्फ़ एक सैंपल कवर किया जाता है. हालांकि, इस सैंपल का साइज़ कभी-कभी बदल सकता है.
  1. अपने पेज पर रिच रिज़ल्ट का टेस्ट करके देखें कि Google आपके पेज को ऐक्सेस करके रिच रिज़ल्ट वाला कोड देख सकता है या नहीं. इस टेस्ट के ज़रिए रिच रिज़ल्ट वाले कोड की पुष्टि भी की जा सकती है.
  2. यूआरएल जांचने वाले टूल की मदद से देखें कि आपकी साइट के पेज इंडेक्स हुए हैं या नहीं और क्या Google उन्हें ऐक्सेस कर सकता है. पेज के लाइव वर्शन की जांच करके भी इस बात की पुष्टि करें कि Google उसे ऐक्सेस कर सकता है या नहीं.
स्ट्रक्चर्ड डेटा से जुड़ी सामान्य गड़बड़ियों की सूची
इस रिपोर्ट में दिखाई जाने वाली सबसे सामान्य गड़बड़ियों की सूची यहां दी गई है:
गड़बड़ी ब्यौरा
"प्रॉपर्टी का नाम" प्रॉपर्टी में अमान्य यूआरएल बताई गई प्रॉपर्टी में अमान्य यूआरएल.
"प्रॉपर्टी का नाम" प्रॉपर्टी नहीं मिली ज़रूरी प्रॉपर्टी नहीं मिली.
"प्रॉपर्टी का नाम" प्रॉपर्टी में अमान्य कैलोरी फ़ॉर्मैट कैलोरी प्रॉपर्टी के लिए अमान्य वैल्यू.
"प्रॉपर्टी का नाम" प्रॉपर्टी में तारीख/समय ISO 8601 फ़ॉर्मैट में नहीं है बताई गई किसी प्रॉपर्टी के लिए तारीख की अमान्य वैल्यू. तारीख ISO 8601 फ़ॉर्मैट में होनी चाहिए.
"प्रॉपर्टी का नाम" प्रॉपर्टी में वैल्यू मौजूद नहीं है किसी बताई गई प्रॉपर्टी के लिए कोई वैल्यू मौजूद नहीं है.
"प्रॉपर्टी का नाम" प्रॉपर्टी में अमान्य वैल्यू किसी बताई गई प्रॉपर्टी के लिए अमान्य वैल्यू.
"प्रॉपर्टी का नाम" प्रॉपर्टी में स्ट्रिंग की अमान्य लंबाई बताई गई किसी प्रॉपर्टी के लिए स्ट्रिंग की वैल्यू काफ़ी लंबी या बहुत कम है.
"प्रॉपर्टी का नाम" प्रॉपर्टी के लिए अमान्य ऑब्जेक्ट टाइप बताई गई किसी प्रॉपर्टी के लिए स्ट्रक्चर्ड डेटा ऑब्जेक्ट का गलत टाइप.
"प्रॉपर्टी का नाम" प्रॉपर्टी के लिए अमान्य वैल्यू टाइप बताई गई किसी प्रॉपर्टी के लिए गलत टाइप की वैल्यू.
प्रॉपर्टी के बारे में कोई जानकारी नहीं "प्रॉपर्टी का नाम" आपने अपने स्ट्रक्चर्ड डेटा में उस प्रॉपर्टी का इस्तेमाल किया है जिसके बारे में कोई जानकारी है.
डुप्लीकेट प्रॉपर्टी "प्रॉपर्टी का नाम" एक ही ऑब्जेक्ट में डुप्लीकेट प्रॉपर्टी का इस्तेमाल.
"प्रॉपर्टी 1" या "प्रॉपर्टी 2" का इस्तेमाल किया जाना चाहिए आपको इन दो प्रॉपर्टी में से सिर्फ़ एक का इस्तेमाल करना होगा.
"प्रॉपर्टी 1 "," प्रॉपर्टी 2 "या" प्रॉपर्टी 3 " का इस्तेमाल किया जाना चाहिए आपको इन तीन में से सिर्फ़ एक प्रॉपर्टी इस्तेमाल करना होगा.
ग्लोबल आइडेंटिफ़ायर उपलब्ध नहीं करवाया गया (जैसे, GTIN, एमपीएन, ISBN) अपने प्रॉडक्ट की पहचान के लिए, आपको इनमें से कम से कम एक ग्लोबल आइडेंटिफ़ायर उपलब्ध कराना होगा: gtin8, gtin13, gtin14, mpn या isbn
"प्रॉपर्टी का नाम" प्रॉपर्टी में पॉज़िटिव वैल्यू होनी चाहिए दिखाई गई प्रॉपर्टी की वैल्यू, एक पॉज़िटिव नंबर होना चाहिए.
"प्रॉपर्टी" प्रॉपर्टी में अमान्य इंटीजर बताई गई किसी प्रॉपर्टी के लिए अमान्य इंटीजर वैल्यू.
"प्रॉपर्टी" प्रॉपर्टी में कीमत के लिए इस्तेमाल किया गया अमान्य फ़ॉर्मैट बताई गई किसी प्रॉपर्टी के लिए कीमत का अमान्य फ़ॉर्मैट.
"प्रॉपर्टी का नाम" प्रॉपर्टी में प्रॉडक्ट की उपलब्धता के लिए अमान्य वैल्यू प्रॉडक्ट की उपलब्धता के लिए अमान्य वैल्यू.
आपने आइटम के बजाय समीक्षा काे रेट कर दिया है आपने आइटम के बजाय औसत रेटिंग के हिसाब से एक समीक्षा काे रेट कर दिया है.
यह पता नहीं लगाया जा सका कि रेटिंग किस स्केल पर दी गई है आपने ऐसा रेटिंग स्केल दिया है जिसे हम समझ नहीं सके.
सबसे अच्छी और सबसे खराब रेटिंग वाले फ़ील्ड ज़रूरी हैं, लेकिन इनमें से एक या दोनों में काेई वैल्यू मौजूद नहीं है किसी रेटिंग के लिए सबसे अच्छी और/या सबसे खराब वैल्यू नहीं मिली.
रेटिंग के तौर पर डाली गई वैल्यू, तय सीमा के मुताबिक नहीं है दी गई रेटिंग वैल्यू तय सीमा से बाहर है.
समीक्षा में एक से ज़्यादा औसत रेटिंग दी गई हैं समीक्षा की कई औसत रेटिंग हैं; सिर्फ़ एक रेटिंग दी सकती है.
कई समीक्षाओं में aggregateRating ऑब्जेक्ट मौजूद नहीं है आपने औसत रेटिंग दिए बिना कई समीक्षाएं दी हैं.
"प्रॉपर्टी का नाम" प्रॉपर्टी में दी गई संख्या रेंज से बाहर है संख्या वाली प्रॉपर्टी तय (या इस्तेमाल की जाने वाली) रेंज से बाहर है.
Sitelinks खोज बॉक्स में सिंटैक्स की गड़बड़ी Sitelinks खोज बॉक्स के इस्तेमाल में सामान्य सिंटैक्स गड़बड़ी.
टारगेट यूआरएल में पसंद के मुताबिक क्वेरी पैरामीटर नहीं दिया गया (Sitelinks खोज बॉक्स) Sitelinks के यूआरएल टेंप्लेट में क्वेरी की उस वैल्यू के लिए गड़बड़ी वाली स्ट्रिंग जिसकी जानकारी नहीं है.
टारगेट यूआरएल में बेमेल क्वेरी पैरामीटर नाम (Sitelinks खोज बॉक्स) target में इस्तेमाल किया गया क्वेरी वैरिएबल नाम, query-input में इस्तेमाल किए गए वैरिएबल नाम से अलग है. उदाहरण के लिए, शायद आपने कुछ ऐसा किया हो:
"target": "https://query.example.com/search?q={search_term_string}",
"query-input": "required name=my_query"

'q' और 'क्वेरी इनपुट' में इस्तेमाल किया गया नाम एक ही होना चाहिए:
"target": "https://query.example.com/search?q={search_term_string}",
"query-input": "required name=search_term_string"
टारगेट यूआरएल डोमेन, वेबसाइट यूआरएल डोमेन से बाहर है

(Sitelinks खोज बॉक्स) target और url में मौजूद यूआरएल का रूट डोमेन एक ही होना चाहिए. यहां मिलते-जुलते और मेल न खाने वाले यूआरएल के उदाहरण दिए गए हैं:

  • http://www.example.com और http://example.com -- मेल खाते हैं
  • http://m.example.com और http://query.example.com - मेल खाते हैं
  • http://www.example.com और http://example.fr.co -- मेल नहीं खाते हैं
  • http://www.example.com और http://exaample.com -- मेल नहीं खाते हैं
अमान्य टारगेट यूआरएल (Sitelinks खोज बॉक्स) target प्रॉपर्टी में अमान्य यूआरएल.
बिना एचटीटीपी वाला टारगेट यूआरएल (Sitelinks खोज बॉक्स) target प्रॉपर्टी में अमान्य यूआरएल: एचटीटीपी या एचटीटीपीएस होना चाहिए.
Sitelinks खोज बॉक्स के इस्तेमाल में गड़बड़ी (Sitelinks खोज बॉक्स) Sitelinks खोज बॉक्स के इस्तेमाल में गड़बड़ी.
"प्रॉपर्टी का नाम" प्रॉपर्टी में गिनती की अमान्य वैल्यू प्रॉपर्टी की वैल्यू, गिनती के लिए किसी भी तय वैल्यू से मेल नहीं खाती.
अज्ञात गड़बड़ी एक गड़बड़ी हुई जो यहां दी गई किसी भी अन्य कैटगरी में नहीं आती है.
@context के लिए अमान्य या काम न करने वाली वैल्यू

JSON-LD मार्कअप में @context एट्रिब्यूट के लिए तय की गई वैल्यू गलत लिखी गई है, काम नहीं करती है या उस एलिमेंट पर लागू नहीं होती है. फ़िलहाल, Google सिर्फ़ इन वैल्यू को इस्तेमाल करने की अनुमति देता है:

  • http://schema.org
  • http://schema.googleapis.com
  • http://gs1.org/voc
  • पिछली वैल्यू के https और पीछे वाले / मार्क के वर्शन

Google, JSON-LD के ऐसे संदर्भों के साथ काम नहीं करता है जो पसंद के मुताबिक हों और जिनका एलान रिमोट तौर पर किया गया हो. उदाहरण के लिए: http://example.com/schemas/custom_schema

 

रिपोर्ट में एक जगह से दूसरी जगह जाना

रिपोर्ट के बारे में खास जानकारी वाला पेज

रिपोर्ट में स्ट्रक्चर्ड डेटा आइटम को गिना जाता है, पेजों को नहीं. एक पेज पर कई स्ट्रक्चर्ड डेटा आइटम हो सकते हैं.

ग्राफ़, रिच रिज़ल्ट के हर मामले को उस पर असर डालने वाली सबसे गंभीर समस्या के आधार पर लेबल करता है: इसलिए, जिस आइटम में गड़बड़ी होती है और चेतावनी का मैसेज मिला होता है उसे "गड़बड़ी" वाला स्टेटस असाइन किया जाता है. ग्राफ़ में एक मामले की गिनती सिर्फ़ एक बार की जाती है.

टेबल:

  • आइटम अमान्य क्यों हैं: यह टेबल उन गंभीर समस्याओं को दिखाती है जिनसे आपकी साइट पर मौजूद आइटम पर असर पड़ता है. इन समस्याओं की वजह से, Google आपके स्ट्रक्चर्ड डेटा का इस्तेमाल नहीं कर पाता. किसी आइटम पर गंभीर और सामान्य समस्याओं का असर पड़ सकता है. ये समस्याएं एक या उससे ज़्यादा हो सकती हैं.
  • आइटम के दिखने के तरीके को बेहतर बनाएं: यह आपकी साइट के स्ट्रक्चर्ड डेटा पर असर डालने वाली ऐसी समस्याओं को दिखाता है जो गंभीर नहीं हैं.

खास जानकारी वाले पेज पर चार्ट के नीचे मान्य आइटम से जुड़ा डेटा देखें पर क्लिक करने पर, मान्य आइटम दिखते हैं.

स्ट्रक्चर्ड डेटा वाले एक आइटम पर असर डालने वाली सभी समस्याओं को देखने के लिए, गड़बड़ियों की जांच करने के तरीके देखें.

रिच रिज़ल्ट की कम संख्या

रिपोर्ट के ग्राफ़ में दिखाए गए आइटम की कुल संख्या, आपकी साइट पर मौजूद आइटम की असल संख्या से कम हो सकती है. इसकी अलग-अलग वजहें हो सकती हैं. इसलिए, मान्य और अमान्य आइटम की कुल संख्या, उन आइटम की संख्या से कम हो सकती है जिनकी जानकारी Google के पास है.

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

समस्याओं की कुल संख्या, मान्य और अमान्य समस्याओं की कुल संख्या से ज़्यादा क्यों है

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

समस्या की ज़्यादा जानकारी देने वाला पेज

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

समस्या की जानकारी वाले पेज पर यह जानकारी दिखाई जाती है:

समस्या का शीर्षक और सहायता पेज का लिंक
इसमें समस्या के बारे में कम शब्दों में दिया गया ब्यौरा शामिल होता है. साथ ही, रिच रिज़ल्ट के इस टाइप के बारे में दस्तावेज़ बनाने के लिए ज़्यादा जानें वाला लिंक भी शामिल होता है. समस्या का कोई उदाहरण देखने के लिए, उदाहरण टेबल में दिए गए किसी मामले पर क्लिक करें. इससे, कोड में हाइलाइट की गई गड़बड़ी देखी जा सकती है.
स्थिति
अगर पुष्टि की प्रोसेस शुरू की गई थी, तो इस समस्या की पुष्टि की स्थिति देखी जा सकती है.
समस्या का पता पहली बार कब चला था
आपकी साइट पर यह समस्या पहली बार पता चलने की तारीख. ध्यान दें: अगर सभी समस्याएं हल कर लेने के बाद भी, 90 दिनों के अंदर कोई समस्या फिर से सामने आती है, तो उसकी तारीख वह मूल तारीख होगी जब उस समस्या का पता चला था, न कि वह तारीख जब समस्या फिर से सामने आई थी.
उदाहरण
उन ज़्यादा बेहतर नतीजों (रिच रिज़ल्ट) की सूची जिन पर इस गड़बड़ी का असर हुआ है. ध्यान दें कि उदाहरणों की सूची में से कुछ पंक्तियां हटाए जाने की कई वजहें हो सकती हैं. जैसे, कुछ जगहों पर यह गड़बड़ी तब सामने आई हो, जब आपकी साइट को पिछली बार क्रॉल किया गया हो या ऐसी गड़बड़ियां जिनका असर 1,000 से ज़्यादा आइटम पर पड़ा हो. इस टेबल में 1,000 से ज़्यादा पंक्तियां नहीं हो सकतीं.
आइटम का नाम
किसी आइटम के स्ट्रक्चर्ड डेटा में name की वैल्यू.
पिछली बार क्रॉल किए जाने का समय
वह समय जब इस गड़बड़ी वाले पेज को पिछली बार क्रॉल किया गया था.

किसी पेज पर मौजूद गड़बड़ी के बारे में ज़्यादा जानने के लिए, उदाहरणों वाली टेबल में वह गड़बड़ी चुनें.

यूआरएल जांचने वाला टूल इस्तेमाल करने के लिए, टेबल में यूआरएल के बगल में मौजूद 'जांच करें' आइकॉन Search पर क्लिक करें. इस टूल में, गड़बड़ी की जानकारी, लाइव टेस्ट, और इंडेक्स किए गए नतीजे के साथ-साथ एक स्क्रीनशॉट होता है.

 

रिपोर्ट शेयर करने का तरीका

आप पेज पर मौजूद शेयर करें बटन पर क्लिक करके, कवरेज या बेहतर बनाने की रिपोर्ट में समस्या से जुड़ी जानकारी शेयर कर सकते हैं. जिस व्यक्ति के पास यह लिंक है, वह इससे सिर्फ़ मौजूदा समस्या से जुड़ी ज़्यादा जानकारी वाले पेज और पुष्टि के इतिहास वाले किसी भी पेज को ऐक्सेस कर सकता है. यह लिंक आपके संसाधन के दूसरे पेजों का ऐक्सेस नहीं देता है. इस लिंक के ज़रिए, किसी दूसरे उपयोगकर्ता को आपकी प्रॉपर्टी या खाते पर किसी भी तरह की कार्रवाई करने की अनुमति नहीं दी जा सकती. इस पेज को शेयर किए जाने की सुविधा बंद करके आप इस लिंक के ज़रिए मिलने वाली मंज़ूरी पर रोक लगा सकते हैं.

रिपोर्ट का डेटा एक्सपोर्ट करने का तरीका

कई रिपोर्ट में डेटा को एक्सपोर्ट करने के लिए, एक्सपोर्ट करें बटन होता है. चार्ट और टेबल, दोनों का डेटा एक्सपोर्ट किया जाता है. रिपोर्ट में ~ या - (उपलब्ध नहीं है/संख्या नहीं है) के तौर पर दिखाया गया कोई भी मान, डाउनलोड किए गए डेटा में शून्य होगा.

साइट में मौजूद समस्याओं को ठीक करके उनकी पुष्टि करना

अपनी साइट पर किसी खास तरह की समस्या के सभी मामलों को ठीक करने के बाद, Google से अनुरोध करके उन समस्याओं के ठीक होने की पुष्टि कराई जा सकती है. किसी समस्या के सभी इंस्टेंस ठीक कर लेने पर, समस्याओं की जानकारी देने वाली टेबल में समस्याओं की संख्या शून्य हो जाती है और वह टेबल के सबसे निचले हिस्से में चली जाती है.

पुष्टि क्यों करनी चाहिए

किसी खास स्थिति या कैटगरी वाली सभी समस्याओं को ठीक करने के बारे में Google को बताने के ये फ़ायदे हैं:

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

अपनी वेबसाइट पर किसी समस्या को ठीक करना और उसकी पुष्टि करना हर बार सही नहीं होता. उदाहरण के लिए, हो सकता है कि robots.txt का इस्तेमाल करके यूआरएल, जान-बूझकर ब्लॉक किए गए हों. किसी समस्या को ठीक करना है या नहीं, यह तय करने के लिए अपनी सूझ-बूझ का इस्तेमाल करें.

पुष्टि किए बिना भी समस्याओं को ठीक किया जा सकता है. Google, समस्या वाले किसी पेज को क्रॉल करने पर समस्याओं की संख्या को अपडेट कर देता है. ऐसा दोनों स्थितियों में किया जाता है, चाहे आपने समस्या के ठीक होने की पुष्टि करने का अनुरोध साफ़ तौर पर किया हो या न किया हो.

पुष्टि की प्रोसेस शुरू करना

Search Console को यह बताने के लिए कि आपने किसी समस्या को ठीक कर लिया है:

  1. अपनी साइट पर इस समस्या के सभी इंस्टेंस ठीक करें. अगर आपसे कोई समस्या छूट गई है, तो Google उस समस्या का एक भी इंस्टेंस मिलने पर, पुष्टि करने की प्रोसेस रोक देगा.
  2. ठीक की गई समस्या की ज़्यादा जानकारी देने वाला पेज खोलें. आपकी रिपोर्ट में मौजूद, समस्याओं की सूची में, ठीक की गई समस्या पर क्लिक करें.
  3. समस्या ठीक होने की पुष्टि करें पर क्लिक करें. जब तक समस्या के ठीक होने की पुष्टि नहीं हो जाती या समस्या बने रहने की जानकारी नहीं मिल जाती, तब तक 'समस्या के ठीक होने की पुष्टि करें' पर दोबारा क्लिक न करें. Google आपकी समस्याओं के ठीक होने की जांच कैसे करता है, इस बारे में ज़्यादा जानकारी.
  4. पुष्टि की प्रोग्रेस पर नज़र रखी जा सकती है. आम तौर पर, पुष्टि करने की प्रोसेस में करीब दो हफ़्ते लगते हैं. हालांकि, कुछ मामलों में इससे ज़्यादा समय भी लग सकता है. इसलिए, कृपया थोड़ा इंतज़ार करें. समस्या के ठीक होने की पुष्टि होने या समस्या बने रहने का पता चलने पर, आपको इसकी सूचना मिलेगी.
  5. अगर पुष्टि नहीं हो पाती है, तो समस्या की जानकारी वाले पेज पर जानकारी देखें पर क्लिक करें. ऐसा करने पर, आपको वह यूआरएल दिखेगा जिसकी वजह से पुष्टि नहीं हो पाई. इस पेज पर मौजूद समस्याएं ठीक करें. जिन यूआरएल में पुष्टि बाकी है की स्थिति दिख रही है उनमें सभी सुधारों की पुष्टि करें. इसके बाद, फिर से पुष्टि करना शुरू करें.

किसी यूआरएल या साइट के किसी हिस्से में आई समस्या को "ठीक कर लिया गया" के तौर पर कब मार्क किया जाता है?

यहां दी गई शर्तों में से किसी एक के पूरा होने पर, यूआरएल या आइटम से जुड़ी समस्या को 'ठीक कर लिया गया' के तौर पर मार्क किया जाता है:

  • जब यूआरएल क्रॉल किया जाता है और पेज पर समस्या नहीं मिलती. एएमपी टैग की गड़बड़ी के लिए, इसका मतलब यह है कि आपने टैग को ठीक कर लिया है या ज़रूरत न होने पर इसे हटा दिया है. पुष्टि करने के दौरान, टैग पर समस्या ठीक हो गई है का लेबल लगा दिया जाएगा.
  • अगर किसी वजह (पेज हटा दिया गया है, पेज पर noindex नियम लागू है, पेज देखने के लिए मंज़ूरी लेना ज़रूरी है वगैरह) से Google को पेज नहीं मिलता, तो उस यूआरएल के लिए, समस्या को 'ठीक कर लिया गया' के तौर पर मार्क किया जाएगा. पुष्टि के दौरान, इसे पुष्टि की अन्य स्थिति के रूप में गिना जाता है.

समस्या का जीवनकाल

किसी वेबसाइट पर मौजूद समस्या के जीवनकाल में, उसकी पहचान किए जाने के समय से लेकर उसके आखिरी इंस्टेंस को पूरी तरह ठीक किए जाने के 90 दिनों बाद तक का समय शामिल होता है. अगर 90 दिनों के बाद समस्या फिर से नहीं दिखती है, तो इसे समस्याओं की जानकारी देने वाली टेबल से हटा दिया जाता है.

जिस तारीख को समस्या की पहली बार पहचान की गई हो उसे समस्या के जीवनकाल का वह समय माना जाता है जब पहली बार उसका पता लगा. इस तारीख में कोई बदलाव नहीं होता है. इसलिए:

  • अगर किसी समस्या के सभी इंस्टेंस ठीक कर लेने के 15 दिनों के बाद, उसका कोई नया इंस्टेंस दिखता है, तो समस्या 'ठीक नहीं की गई है' के तौर पर दिखेगी. साथ ही, इसके पहली बार पता चलने की तारीख ही इसके पता चलने की ओरिजनल तारीख रहेगी.
  • समस्या के किसी मामले के ठीक होने के 90 दिन बाद, उसे 'ठीक कर लिया गया' के तौर पर मार्क कर दिया जाता है. हालांकि, ऐसा होने के 91 दिन बाद, हो सकता है कि यह समस्या फिर से दिखे. ऐसे में, इस मामले को नई समस्या के तौर पर रिकॉर्ड किया जाता है. साथ ही, इस समस्या के दोबारा दिखने की तारीख को, समस्या के पहली बार पता चलने की तारीख के तौर पर सेट कर दिया जाता है.
पुष्टि करने की प्रोसेस

किसी समस्या के लिए समस्या ठीक होने की पुष्टि करें पर क्लिक करें और पुष्टि करने की प्रोसेस देखें. इस प्रोसेस में कई दिन लग सकते हैं. आपको इससे जुड़ी सूचनाएं ईमेल के ज़रिए मिलती रहेंगी.

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

भले ही, आपने कभी भी 'पुष्टि की प्रोसेस शुरू करें' पर क्लिक न किया हो, Google किसी समस्या के ठीक किए जा चुके इंस्टेंस पहचान सकता है. Google को अगर नियमित रूप से किए जाने वाले क्रॉल के दौरान पता चलता है कि किसी समस्या के सभी मामले ठीक कर लिए गए हैं, तो वह रिपोर्ट में समस्या की संख्या को बदलकर शून्य कर देगा.

दोबारा पुष्टि करना

⚠️ दोबारा पुष्टि किए जाने का अनुरोध करने से पहले, पुष्टि की मौजूदा प्रोसेस पूरी होने तक इंतज़ार करें, भले ही आपने अनुरोध किए जाने के बाद कुछ समस्याएं ठीक की हों.

फ़ेल हो चुकी किसी पुष्टि की प्रोसेस को दोबारा शुरू करने के लिए:

  1. फ़ेल हुई पुष्टि की प्रोसेस के बारे में जानकारी पाने के लिए, पुष्टि करने वाले लॉग पर जाएं: जिस समस्या की पुष्टि नहीं हो पाई उसकी ज़्यादा जानकारी वाला पेज खोलें. इसके बाद, ज़्यादा जानकारी देखें पर क्लिक करें.
  2. पुष्टि की नई प्रोसेस शुरू करें पर क्लिक करें.
  3. पुष्टि बाकी है या समस्या ठीक नहीं हुई के तौर पर मार्क किए गए सभी यूआरएल की पुष्टि की प्रोसेस दोबारा शुरू हो जाएगी. साथ ही, समस्या के उन इंस्टेंस के लिए भी पुष्टि की प्रोसेस दोबारा शुरू हो जाएगी जिनका पता पिछली पुष्टि की कोशिश के बाद, सामान्य क्रॉलिंग के ज़रिए चलेगा. समस्या ठीक हो गई है या अन्य के तौर पर मार्क किए गए यूआरएल को दोबारा नहीं जांचा जाता.
  4. आम तौर पर, पुष्टि करने की प्रोसेस में करीब दो हफ़्ते लगते हैं. हालांकि, कुछ मामलों में इससे ज़्यादा समय भी लग सकता है. इसलिए, कृपया थोड़ा इंतज़ार करें.

पुष्टि की स्थिति देखना

पुष्टि होने की प्रोसेस चालू नहीं होने की स्थिति में, पुष्टि करने के मौजूदा अनुरोध की स्थिति या पिछले अनुरोध का इतिहास देखने के लिए:

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

किसी भी समस्या की पुष्टि की प्रोसेस पर, पुष्टि की ये स्थितियां लागू होती हैं:

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

पुष्टि का अनुरोध करने के बाद, किसी भी समस्या के हर मामले के लिए, पुष्टि का खास स्टेटस दिखाया जाता है. यह स्टेटस, इनमें से एक हो सकता है:

  • पुष्टि बाकी है: पुष्टि करने के लिए इसे सूची में जोड़ लिया गया है. पिछली बार जब Google ने क्रॉल किया था, तब समस्या का यह मामला मौजूद था.
  • समस्या ठीक हो गई है: [सभी रिपोर्ट में उपलब्ध नहीं है] समस्या वाले इंस्टेंस की जांच करने पर, Google को पता चला कि यह अब मौजूद नहीं है. समस्या इस स्थिति में सिर्फ़ तब पहुंच सकती है, जब आपने समस्या के इस इंस्टेंस के लिए, पुष्टि करें पर क्लिक किया हो.
  • समस्या ठीक नहीं हुई: समस्या वाले इंस्टेंस की जांच करने पर, Google को पता चला कि यह अब भी मौजूद है. समस्या इस स्थिति में सिर्फ़ तब पहुंच सकती है, जब आपने समस्या के इस इंस्टेंस के लिए, पुष्टि करें पर क्लिक किया हो.
  • अन्य: [सभी रिपोर्ट में उपलब्ध नहीं] Google, उस पेज के यूआरएल को ऐक्सेस नहीं कर पाया, जिस पर समस्या के मामले हैं. इसके अलावा, स्ट्रक्चर्ड डेटा के मामले में यह हो सकता है कि उसे पेज पर अब वह आइटम नहीं मिला. यह स्थिति समस्या ठीक हो गई है वाली स्थिति जैसी ही है.

ध्यान दें कि अलग-अलग समस्याओं के लिए, एक ही यूआरएल के अलग-अलग स्टेटस हो सकते हैं. उदाहरण के लिए, एक ही पेज पर X और Y, दोनों तरह की समस्याएं है. ऐसे में, हो सकता है कि X समस्या की पुष्टि का स्टेटस समस्या ठीक हो गई है हो और उसी पेज पर Y समस्या की पुष्टि का स्टेटस, पुष्टि बाकी है के तौर पर दिखे.

 

 
क्या यह उपयोगी था?
हम उसे किस तरह बेहतर बना सकते हैं?

और मदद चाहिए?

आगे दिए गए कदमों को आज़माएं:

खोजें
खोज साफ़ करें
खोज बंद करें
Google ऐप
मुख्य मेन्यू
खोज मदद केंद्र
false
false
true
true
83844