ज़्यादा बेहतर नतीजे (रिच रिज़ल्ट) की स्टेटस रिपोर्ट

देखें कि 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 " का इस्तेमाल किया जाना चाहिए आपको इन तीन में से सिर्फ़ एक प्रॉपर्टी इस्तेमाल करना होगा.
ग्लोबल आइडेंटिफ़ायर उपलब्ध नहीं करवाया गया (जैसे, जीटीआईएन, एमपीएन, आईएसबीएन) अपने प्रॉडक्ट की पहचान के लिए, आपको इनमें से कम से कम एक ग्लोबल आइडेंटिफ़ायर उपलब्ध कराना होगा: 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 Search में ज़्यादा बेहतर नतीजे (रिच रिज़ल्ट) के तौर पर नहीं दिखाया जा सकता. आइटम का गड़बड़ी की स्थिति में दिखने का मतलब है कि उनमें कम से कम एक गड़बड़ी है. इसके अलावा, उनमें एक या एक से ज़्यादा चेतावनियां भी हो सकती हैं.
  • चेतावनियों के साथ मान्य: ज़्यादा बेहतर नतीजे (रिच रिज़ल्ट) को Google Search में ज़्यादा बेहतर नतीजे (रिच रिज़ल्ट) के तौर पर दिखाया जा सकता है. चेतावनी वाली समस्याओं के बारे में, वैकल्पिक वैल्यू के मौजूद न होने या गलत होने या गैर-ज़रूरी प्रॉपर्टी में गड़बड़ी होने की जानकारी के तौर पर बताया जा सकता है. इसके अलावा, ये ऐसी प्रॉपर्टी के इस्तेमाल के बारे में चेतावनियां हो सकती हैं जो अब इस्तेमाल नहीं की जातीं. स्ट्रक्चर्ड डेटा में, गैर-ज़रूरी प्रॉपर्टी की जानकारी देने से भी उपयोगकर्ता को कई बार बेहतर अनुभव मिल सकता है.
  • मान्य: ज़्यादा बेहतर नतीजा (रिच रिज़ल्ट), Google Search में ज़्यादा बेहतर नतीजे (रिच रिज़ल्ट) के तौर पर दिख सकता है. इसके लिए सभी ज़रूरी और वैकल्पिक डेटा सही तरीके से उपलब्ध कराया जाता है.

अगर आपको किसी ज़्यादा बेहतर नतीजे (रिच रिज़ल्ट) की सारी गड़बड़ियां देखना है, तो गड़बड़ियों की जांच करने के तरीके देखें.

टेबल में हर स्थिति की कुल संख्या, ग्राफ़ के लिए दिखाई देने वाली स्थिति में मौजूद मिलती-जुलती स्थितियों की कुल संख्या से ज़्यादा हो सकती है. ऐसा होने की वजहों के दो उदाहरण:
  • तीन अलग-अलग चेतावनियों वाला कोई आइटम, टेबल में तीन बार दिखेगा (कुल = 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 दिनों के बाद, फिर से नया इंस्टेंस दिखता है, तो समस्या 'ठीक नहीं की गई है' के तौर पर दिखेगी. साथ ही, इसके पहली बार पता चलने की तारीख ही इसके पता चलने की ओरिजनल तारीख रहेगी.
  • अगर इस समस्या के सभी इंस्टेंस ठीक कर लेने के 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 समस्या की पुष्टि की स्थिति पुष्टि बाकी है के तौर पर दिखे.

 

ऐसी समस्याएं जिनकी पहले से जानकारी है

आगे दी गई समस्याएं, Search Console की ऐसी समस्याएं हैं जिनके बारे में पहले से जानकारी है. इन समस्याओं के बारे में हमें रिपोर्ट करने की ज़रूरत नहीं है, लेकिन हम चाहते हैं कि आप दूसरी सुविधाओं या समस्याओं के बारे में हमें अपने सुझाव ज़रूर दें. इसके लिए, नेविगेशन बार में मौजूद सुझाव देने का तरीका इस्तेमाल करें.

  • कुछ समस्याओं के नाम लंबे हैं, जो समझने में आसान नहीं हैं.
क्या यह उपयोगी था?
हम उसे किस तरह बेहतर बना सकते हैं?
खोजें
खोज साफ़ करें
खोज बंद करें
Google ऐप
मुख्य मेन्यू
खोज मदद केंद्र
true
83844
false