साइटमैप वैलिडेटर जाँचता है कि XML साइटमैप में अपेक्षित संरचना और समर्थित फ़ील्ड मान हैं या नहीं। Screpy एक दस्तावेज़ की जाँच करके त्रुटियाँ, चेतावनियाँ और स्रोत का प्रमाण दिखाता है, ताकि आप साइटमैप बनाने वाले सिस्टम को सुधार सकें। साफ़ परिणाम केवल जाँच के दायरे पर लागू होता है: इससे यह साबित नहीं होता कि सूचीबद्ध पेज काम करते हैं या Google ने उन्हें इंडेक्स किया है।
वह दस्तावेज़ चुनें जिसकी जाँच करनी है
प्रकाशित फ़ाइल जाँचने के लिए उसका पूरा सार्वजनिक XML पता दर्ज करें, जैसे https://example.com/sitemap.xml। यह काल्पनिक पता केवल प्रारूप समझाने के लिए है। होमपेज से XML के बजाय HTML मिल सकता है; पहले साइटमैप ढूँढने के लिए Sitemap Checker इस्तेमाल करें।
प्रकाशित करने से पहले स्रोत की जाँच करने या सहेजे हुए दस्तावेज़ को देखने के लिए XML पेस्ट करने वाला विकल्प चुनें। कच्चा XML कॉपी करें, ब्राउज़र की सजाई हुई तालिका नहीं। यहाँ फ़ाइल अपलोड करने का विकल्प नहीं है। वैकल्पिक आधार URL, origin की तुलना के लिए संदर्भ देता है; यह सापेक्ष पतों को ठीक नहीं करता। आधार के तौर पर https://example.com/ देने पर भी <loc>/products/</loc> में पूरा HTTP या HTTPS पता देना ज़रूरी है।
आधार URL के बिना पेस्ट किए गए XML में origin की इस तुलना का संदर्भ नहीं होता। फिर भी उसकी समर्थित संरचना और फ़ील्ड मानों की जाँच हो सकती है।
मूल एलिमेंट, नेमस्पेस और XML एस्केपिंग सुधारें
पेजों के साइटमैप में मानक साइटमैप नेमस्पेस वाला urlset मूल एलिमेंट होना चाहिए और हर url के अंदर एक loc होना चाहिए। एक एंट्री वाला यह काल्पनिक दस्तावेज़ आवश्यक संरचना दिखाता है:
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://example.com/products/blue-mug/</loc>
</url>
</urlset>
नेमस्पेस URI को ठीक इसी रूप में रखें, जिसमें http भी शामिल है। यह XML शब्दावली की पहचान है; इसे https में बदलने से सुरक्षा बेहतर नहीं होती, बल्कि पहचान बदल जाती है। साइटमैप इंडेक्स का मूल एलिमेंट अलग होता है, जिसका वर्णन आगे है। Sitemaps प्रोटोकॉल दोनों संरचनाएँ निर्धारित करता है।
XML में URL के & को & लिखें: उदाहरण के लिए ?color=blue&size=m। ज़रूरी URL पैरामीटर हटाने के बजाय जनरेटर की एस्केपिंग ठीक करें। बंद करने वाले टैग गायब हों, सामग्री असमर्थित हो या DOCTYPE घोषणा हो, तो विस्तृत रिपोर्ट बनने से पहले जाँच रुक सकती है। असफल जाँच का अर्थ सफल वैलिडेशन नहीं है।
हर समस्या को स्रोत में सुधार से जोड़ें
परिणाम और कवरेज के बैज एक साथ पढ़ें। लाल रंग त्रुटियाँ बताता है; पीला चेतावनियाँ या आंशिक कवरेज बताता है; हरा बताता है कि जाँचे गए दायरे में ध्यान माँगने वाली कोई समस्या नहीं मिली। रंगों के साथ टेक्स्ट और आइकन भी हैं। प्रमाण और एंट्री की शुरुआती पंक्ति से उसका XML ब्लॉक ढूँढें, फिर उसे बनाने वाले स्रोत को सुधारें।
| समस्या | उदाहरण | स्रोत में सुधार |
|---|---|---|
| अमान्य पता | /products/ या खाली loc |
अपेक्षित पूरा HTTP या HTTPS URL दें। |
| अमान्य वैकल्पिक मान | lastmod में 2026-02-30 या priority में 1.2 |
मान सुधारें या वह वैकल्पिक फ़ील्ड हटा दें जिसे सही बनाए रखना संभव नहीं है। |
| दोहराया गया फ़ील्ड | एक एंट्री में दो loc फ़ील्ड |
उस फ़ील्ड का एक ही मान बनाएँ; यह त्रुटि है। |
| दोहराया गया पता | दो एंट्रियों में एक ही पता | स्रोत सूची से अनचाहा दोहराव हटाएँ; यह चेतावनी है। |
| अप्रत्याशित एलिमेंट | इंडेक्स की एंट्री में priority |
दस्तावेज़ के प्रकार के अनुसार फ़ील्ड रखें। |
दोहराव की जाँच, पतों के शुरू और अंत का खाली स्थान हटाकर उनके टेक्स्ट की तुलना करती है। यह नहीं बताती कि अलग URL पर एक ही सामग्री है, और न ही कैनोनिकल URL चुनती है। किसी दूसरी फ़ाइल में वही पता दोहराया गया है या नहीं, यह भी एक दस्तावेज़ की इस जाँच के दायरे में नहीं है।
“समीक्षा की ज़रूरत वाली एंट्रियाँ” केवल त्रुटि वाली एंट्रियाँ गिनता है, हर चेतावनी या पूरे दस्तावेज़ की समस्या नहीं। इसलिए मूल एलिमेंट या नेमस्पेस की त्रुटि होने पर भी यह संख्या शून्य हो सकती है। इस संख्या को वैधता का स्कोर मानने के बजाय समस्याएँ पढ़ें। कई समस्याएँ एक ही एंट्री से संबंधित हो सकती हैं।
तारीख के प्रारूप के साथ उसका अर्थ भी जाँचें
पेज साइटमैप में lastmod, changefreq और priority वैकल्पिक हैं। उनका न होना फ़ील्ड की त्रुटि नहीं है। तारीख देने पर 2026-09-01 या 2026-09-01T14:30:00Z जैसा वैध मान इस्तेमाल करें। प्रारूप सही दिखने से कैलेंडर में असंभव तारीख सही नहीं हो जाती।
पेज के लिए lastmod उसके महत्वपूर्ण संशोधन को दिखाना चाहिए, हर बार साइटमैप दोबारा बनाने को नहीं। सभी तारीखें आज की तारीख से बदलने वाला जनरेटर सही सिंटैक्स के बावजूद भ्रामक डेटा बना सकता है। स्रोत तारीख की तुलना पेज के वास्तविक बदलावों से करें; यह वैलिडेटर संशोधन का इतिहास सत्यापित नहीं कर सकता।
Google के साइटमैप निर्देश बताते हैं कि वह लगातार सही और सत्यापित किए जा सकने वाले संशोधन समय का इस्तेमाल करता है तथा priority और changefreq को अनदेखा करता है। इन दोनों फ़ील्ड को सुधारने से दिए गए मेटाडेटा की मरम्मत होती है; रैंकिंग नहीं बढ़ती। इन्हें रखने पर priority का मान 0 से 1 के बीच होना चाहिए और बदलाव की आवृत्ति के लिए weekly जैसा समर्थित लोअरकेस मान चाहिए।
इंडेक्स को फ़ाइलों की सूची के रूप में पढ़ें
sitemapindex में sitemap एंट्रियाँ होती हैं। हर loc एक चाइल्ड साइटमैप फ़ाइल का पता देता है; वैकल्पिक lastmod उस फ़ाइल का संशोधन समय बताता है। वह चाइल्ड फ़ाइल के हर पेज का संशोधन समय नहीं बताता। इसलिए तीन फ़ाइलों वाले इंडेक्स में तीन एंट्रियाँ हैं, वेबसाइट के तीन पेज नहीं।
Screpy भेजे गए इंडेक्स की ही जाँच करता है। वह चाइल्ड फ़ाइलें नहीं खोलता। किसी चाइल्ड के अंदर की समस्या देखने के लिए संबंधित चाइल्ड की अलग जाँच करें। डाउनलोड करने योग्य सूची चाहिए तो XML Sitemap Parser एंट्रियाँ निकालता है; वह इंडेक्स को सभी पेजों की संयुक्त सूची में नहीं बदलता।
Origin की चेतावनी एंट्री की स्कीम, होस्टनाम और पोर्ट की तुलना प्राप्त दस्तावेज़ के अंतिम URL से, या पेस्ट किए गए XML के आधार URL से करती है। पता बदलने से पहले अप्रत्याशित http, दूसरे होस्ट या पोर्ट की जाँच करें। अंतर मिलने का अर्थ समीक्षा की ज़रूरत है, अपने आप यह फैसला नहीं कि सबमिशन अमान्य है।
Google सही कॉन्फ़िगरेशन के साथ अलग साइटों के लिए साइटमैप सबमिशन की अनुमति देता है, जहाँ आवश्यक स्वामित्व या हर साइट का उचित साइटमैप संदर्भ उपलब्ध हो। यह टूल उन सेटिंग्स को सत्यापित नहीं कर सकता। केवल चेतावनी हटाने के लिए सही पतों को बदलने से पहले अपेक्षित सबमिशन व्यवस्था की पुष्टि करें।
सुधार के बाद रिपोर्ट के दायरे में दोबारा जाँचें
प्रोटोकॉल के अनुसार एक फ़ाइल में अधिकतम 50,000 एंट्रियाँ और बिना कंप्रेस की गई 50 MiB सामग्री हो सकती है। Screpy में अधिकतम 256 KiB XML पेस्ट किया जा सकता है या दूरस्थ स्रोत से 50 MiB डिकोड किया गया XML लिया जा सकता है। ये सीमाएँ बाइट मापती हैं, अक्षर नहीं।
50,000 एंट्रियाँ प्रोसेस होने पर वैलिडेशन रुक जाता है; पूरा कुल और XML पूरी तरह सही संरचना में है या नहीं, यह अज्ञात रह सकता है। अधिकतम 1,000 पंक्तियाँ रखी जाती हैं और जवाब के आकार की सीमा परिणाम को और छोटा कर सकती है। दिखाई देने वाली पंक्तियों से अधिक एंट्रियाँ पढ़ लेने पर भी प्रदर्शित सूची पूरी नहीं हो जाती। कुल समझने या रिपोर्ट साझा करने से पहले कवरेज देखें।
CSV और TXT में रखी गई एंट्रियाँ होती हैं; JSON में सीमित रिपोर्ट होती है। आंशिक परिणाम का एक्सपोर्ट पूरी सूची होने की गारंटी नहीं देता। एक्सटेंशन एलिमेंट के कारण भी कवरेज आंशिक हो सकती है: यह टूल समर्थित मूल फ़ील्ड जाँचता है, पूरे एक्सटेंशन स्कीमा या संपूर्ण XSD अनुपालन नहीं।
जनरेटर, टेम्पलेट या स्रोत रिकॉर्ड सुधारें, XML फिर से बनाएँ और सुधरे हुए प्रकाशित पते की दोबारा जाँच करें। केवल बनी हुई फ़ाइल बदलने पर अगला रीबिल्ड उस बदलाव को मिटा सकता है। बड़ी फ़ाइल के लिए छोटे स्रोत साइटमैप अलग-अलग जाँचें और नोट करें कि किसकी जाँच पूरी हुई।
अंत में पेजों का व्यवहार अलग जाँचें। Bulk HTTP Status Checker सूचीबद्ध URL के जवाब और रीडायरेक्ट देखने में मदद करता है। XML जाँच सफल होने से पेज का स्टेटस, कैनोनिकल चयन, noindex या इंडेक्सिंग साबित नहीं होती। सबमिशन के बाद इस रिपोर्ट को खोज में दिखाई देने का प्रमाण मानने के बजाय Google में साइटमैप प्रोसेसिंग और पेज इंडेक्सिंग का प्रमाण देखें।