हर बार प्रकाशित करते समय तैयार सार्वजनिक पेजों के सेट से अपना साइटमैप फिर से बनाएँ, फिर दोनों को साथ अपलोड करें। Mac पर यह वर्कफ़्लो एक छोटी Python स्क्रिप्ट का उपयोग करके जोड़े गए पेज शामिल करता है और हटाए गए पेजों को अपने-आप निकाल देता है, साथ ही सार्वजनिक परिणाम की जाँच भी करता है।
यहाँ काम Mac से निर्यात की गई एक छोटी स्थिर वेबसाइट के साइटमैप को बनाए रखना है। उदाहरण में रंगों के बारे में काल्पनिक पेज इस्तेमाल किए गए हैं। इसमें माना गया है कि आपकी मौजूदा प्रकाशन प्रक्रिया निर्यात फ़ोल्डर अपलोड कर सकती है और सार्वजनिक साइट से अप्रचलित फ़ाइलें हटा सकती है।
चुनें कि साइटमैप को फिर से बनाना कहाँ होना चाहिए
पहले जाँचें कि क्या आपका प्रकाशन सिस्टम पहले से साइटमैप बनाता है। Google के अनुसार, कई कंटेंट मैनेजमेंट सिस्टम यह काम अपने-आप करते हैं। यदि आपका सिस्टम ऐसा करता है, तो एक और जनरेटर जोड़ने से पहले किसी परीक्षण पेज को जोड़ने और हटाने के बाद उस साइटमैप की जाँच करें। साइटमैप के बारे में जानें।
स्थिर निर्यात के लिए यह क्रम अपनाएँ: पेजों का निर्यात पूरा करें, उस निर्यात से साइटमैप बनाएँ, फिर तैयार फ़ोल्डर प्रकाशित करें। यह एक प्रस्तावित कार्यान्वयन तरीका है: इससे साइटमैप उन्हीं पेजों का विवरण देता है जो प्रकाशक को मिलते हैं।
प्रकाशन के दौरान साइटमैप बनाने से पेज जोड़ने और हटाने के लिए एक समान नियम भी लागू होता है। तैयार निर्यात में मौजूद पेज शामिल होता है; उसमें अनुपस्थित पेज छोड़ दिया जाता है। अपडेट करने के लिए कोई अलग सूची याद रखने की ज़रूरत नहीं होती।
अपने मौजूदा सेटअप के अनुसार एकीकरण चुनें:
| मौजूदा प्रकाशन सेटअप | साइटमैप फिर से कहाँ बनाना है |
|---|---|
| CMS पहले से साइटमैप बनाए रखता है | उसी जनरेटर का उपयोग जारी रखें और पेजों में बदलाव के बाद उसका व्यवहार जाँचें |
| स्थिर निर्यातक निर्यात के बाद कोई कमांड चलाने की सुविधा देता है | अपलोड से पहले वहीं जनरेटर चलाएँ |
| कोई मौजूदा कमांड तैयार फ़ोल्डर प्रकाशित करता है | जनरेटर के वैकल्पिक प्रकाशन आर्ग्युमेंट के ज़रिए उसे चलाएँ |
| आप डेस्कटॉप इंटरफ़ेस से अपलोड करते हैं | पहले साइटमैप बनाएँ, फिर पूरा फ़ोल्डर अपलोड करें; बिना निगरानी सार्वजनिक अपडेट के लिए समर्थित प्रकाशन एकीकरण आवश्यक है |
स्थानीय स्क्रिप्ट अपने-आप किसी दूरस्थ वेबसाइट को नहीं बदल सकती। नीचे दिया गया वर्कफ़्लो साइटमैप बनाने को स्वचालित करता है और मौजूदा प्रकाशन कमांड चला सकता है। वास्तविक अपलोड की ज़िम्मेदारी आपके स्थापित प्रकाशक की रहती है।
तय करें कि साइटमैप में ठीक कौन-से पेज होने चाहिए
साधारण पेज URL के लिए Google एक टेक्स्ट साइटमैप स्वीकार करता है जिसमें हर पंक्ति में एक पूरा URL होता है। इस काम के लिए XML वैकल्पिक है। एक ही सामग्री के URL के कई संस्करणों के बजाय हर पेज का पसंदीदा सार्वजनिक URL शामिल करें। साइटमैप बनाएँ और सबमिट करें।
टेक्स्ट फ़ॉर्मैट के लिए UTF-8 एन्कोडिंग आवश्यक है और इसमें केवल URL होते हैं, शीर्षक या टिप्पणियाँ नहीं। एक फ़ाइल में अधिकतम 50,000 URL और 52,428,800 बाइट हो सकते हैं। इस उदाहरण का साइटमैप साइट के रूट पर रखें, ताकि वह उस स्थान के नीचे निर्यात किए गए पेजों को कवर करे। साइटमैप प्रोटोकॉल: टेक्स्ट फ़ाइलें और स्थान।
यह जनरेटर जानबूझकर एक सरल निर्यात परंपरा अपनाता है:
| निर्यात की गई फ़ाइल | उदाहरणार्थ सार्वजनिक URL |
|---|---|
public/index.html |
https://example.com/ |
public/colors/blue.html |
https://example.com/colors/blue.html |
public/tiles/index.html |
https://example.com/tiles/ |
इस परंपरा का उपयोग तभी करें जब आपका होस्ट ठीक यही URL परोसे। यदि आपका प्रकाशक blue.html को /colors/blue/ में बदलता है या साइट /collection/ जैसे पथ के नीचे उपलब्ध कराता है, तो प्रकाशित करने से पहले उसकी रूट सूची का उपयोग करें या मैपिंग को उसके अनुसार ढालें। केवल फ़ाइलनाम स्कैन करके कस्टम रूटिंग का पता नहीं लगाया जा सकता।
निर्यात फ़ोल्डर में केवल उन्हीं पेजों को रखें जिन्हें शामिल करना है। यह उदाहरण डॉट से शुरू होने वाले पथों और 404.html नाम वाली फ़ाइलों को छोड़ देता है; यह पेज मेटाडेटा, canonical घोषणाओं या रीडायरेक्ट नियमों की जाँच नहीं करता। जिन साइटों पर ये अतिरिक्त शर्तें लागू होती हैं, उन्हें इसके बजाय प्रकाशक की पात्र पेज सूची से साइटमैप बनाना चाहिए।
सामान्य नेविगेशन लिंक भी बनाए रखें। WHATWG, a एलिमेंटों द्वारा href एट्रिब्यूट के साथ बनाए गए हाइपरलिंक परिभाषित करता है, और Google बताता है कि सही ढंग से लिंक किए गए पेज आमतौर पर नेविगेशन के ज़रिए खोजे जा सकते हैं। साइटमैप अपडेट करते समय जोड़े गए या हटाए गए पेजों की ओर जाने वाले लिंक भी अपडेट करें। WHATWG HTML मानक: लिंक, साइटमैप के बारे में जानें।
अपने Mac पर जनरेटर बनाएँ
आपको Python 3.8 या बाद का संस्करण और एक सादा टेक्स्ट एडिटर चाहिए। उपलब्ध इंटरप्रेटर जाँचने के लिए Terminal में python3 --version चलाएँ। Python चाहिए तो Python Software Foundation के macOS इंस्टॉलेशन निर्देशों का पालन करें। इसके दस्तावेज़ Terminal से python3 के साथ स्क्रिप्ट चलाने का तरीका भी बताते हैं। macOS पर Python का उपयोग।
अपने Desktop पर sitemap-demo नाम का फ़ोल्डर बनाएँ। नीचे दिया गया पूरा प्रोग्राम उसमें regenerate_sitemap.py नाम से सेव करें। यह प्रोग्राम Python की मानक लाइब्रेरी का उपयोग करता है और इसके लिए अतिरिक्त पैकेजों की आवश्यकता नहीं है।
import argparse
from pathlib import Path, PurePosixPath
import subprocess
import tempfile
from urllib.parse import quote, urlsplit
def make_sitemap(paths, origin):
parsed = urlsplit(origin)
if (parsed.scheme not in ("http", "https") or not parsed.hostname
or parsed.netloc != parsed.hostname
or parsed.path not in ("", "/")
or parsed.query or parsed.fragment):
raise ValueError("Use a site origin, such as https://example.com")
base = origin.rstrip("/")
urls = set()
for relative in paths:
path = PurePosixPath(relative)
if path.name == "index.html":
parent = path.parent.as_posix()
route = "" if parent == "." else parent + "/"
else:
route = path.as_posix()
urls.add(base + "/" + quote(route, safe="/"))
if not urls:
raise ValueError("No eligible pages; sitemap was not replaced")
if len(urls) > 50000:
raise ValueError("Split the sitemap: more than 50,000 URLs")
data = ("\n".join(sorted(urls)) + "\n").encode("utf-8")
if len(data) > 50 * 1024 * 1024:
raise ValueError("Split the sitemap: larger than 50 MB")
return data
def main():
parser = argparse.ArgumentParser()
parser.add_argument("folder")
parser.add_argument("origin")
parser.add_argument("publish", nargs=argparse.REMAINDER)
args = parser.parse_args()
root = Path(args.folder).resolve()
if not root.is_dir():
parser.error("The export folder must already exist")
paths = []
for file in root.rglob("*.html"):
relative = file.relative_to(root)
if (file.is_file() and file.name != "404.html"
and not any(p.startswith(".") for p in relative.parts)):
paths.append(relative.as_posix())
data = make_sitemap(paths, args.origin)
target = root / "sitemap.txt"
temporary = None
try:
with tempfile.NamedTemporaryFile(dir=root, delete=False) as handle:
temporary = Path(handle.name)
handle.write(data)
temporary.replace(target)
finally:
if temporary is not None:
temporary.unlink(missing_ok=True)
print(f"Wrote {len(data.splitlines())} URLs to {target}", flush=True)
if args.publish:
subprocess.run(args.publish, check=True)
if __name__ == "__main__":
main()
हर बार चलाने पर पूरी URL सूची नए सिरे से बनाई जाती है। परिणाम को क्रमबद्ध और डुप्लिकेट-रहित किया जाता है, पथों में स्पेस जैसे अक्षरों को एन्कोड किया जाता है और sitemap.txt को बदलने से पहले एक अस्थायी फ़ाइल लिखी जाती है। साइटमैप बनाने में कोई त्रुटि होने पर वैकल्पिक प्रकाशन कमांड नहीं चलती।
खाली निर्यात जानबूझकर त्रुटि उत्पन्न करता है और पिछले साइटमैप को जस का तस छोड़ देता है। इससे गलती से चुना गया या अधूरा फ़ोल्डर पकड़ा जा सकता है। सभी पेज जानबूझकर हटाने के लिए एक अलग प्रकाशन निर्णय चाहिए; इस वर्कफ़्लो में खाली निर्यात देना पर्याप्त नहीं है।
प्रकाशन से जोड़ने से पहले पेज जोड़ने और हटाने का परीक्षण करें
Terminal में अपने प्रदर्शन फ़ोल्डर में जाएँ:
cd "$HOME/Desktop/sitemap-demo"
इस पूरी सेटअप कमांड से दो काल्पनिक पेज बनाएँ। इसे नए प्रदर्शन फ़ोल्डर में चलाएँ; यह बताए गए दो नमूना फ़ाइलें लिखती है।
python3 - <<'PY'
from pathlib import Path
root = Path("public")
(root / "colors").mkdir(parents=True, exist_ok=True)
pages = {
"index.html": "<!doctype html><title>Color collection</title><p>Color collection.</p>",
"colors/blue.html": "<!doctype html><title>Blue tile</title><p>A blue tile.</p>",
}
for name, content in pages.items():
(root / name).write_text(content, encoding="utf-8")
PY
स्थानीय साइटमैप बनाएँ और उसकी जाँच करें। उदाहरण का origin केवल समझाने के लिए है; ये कमांड वहाँ कुछ भी प्रकाशित नहीं करते।
python3 regenerate_sitemap.py public https://example.com
cat public/sitemap.txt
अपेक्षित फ़ाइल में ठीक ये दो पंक्तियाँ होंगी:
https://example.com/
https://example.com/colors/blue.html
अब काल्पनिक नीले पेज को हरे पेज से बदलें:
python3 - <<'PY'
from pathlib import Path
root = Path("public")
(root / "colors/blue.html").unlink()
(root / "colors/green.html").write_text(
"<!doctype html><title>Green tile</title><p>A green tile.</p>",
encoding="utf-8",
)
PY
python3 regenerate_sitemap.py public https://example.com
cat public/sitemap.txt
अपेक्षित परिणाम में पहले होम URL और उसके बाद https://example.com/colors/green.html होगा। नीला URL हट जाएगा, क्योंकि उसकी निर्यात की गई फ़ाइल मौजूद नहीं रहेगी। इससे बदलाव के दोनों पहलुओं की जाँच हो जाती है और सर्च इंजन द्वारा बदलाव देखे जाने पर निर्भर नहीं रहना पड़ता।
हर प्रकाशन का हिस्सा बनाएँ
अपनी वास्तविक साइट के लिए प्रदर्शन फ़ोल्डर और origin को अपने वास्तविक तैयार निर्यात फ़ोल्डर और सार्वजनिक origin से बदलें। निर्यात पूरा होने के बाद ही जनरेटर चलाएँ और प्रकाशन पूरा होने तक उस फ़ोल्डर को न बदलें। प्रकाशन क्रमिक रूप से चलाएँ।
यदि प्रोजेक्ट फ़ोल्डर में deploy-site.sh नाम की कोई कार्यशील प्रकाशन स्क्रिप्ट पहले से है, तो नीचे दिया गया एकीकरण कमांड पहले साइटमैप बनाएगा और फिर वह स्क्रिप्ट चलाएगा। इस उदाहरण के लिए मौजूदा स्क्रिप्ट आवश्यक है; जनरेटर उसे नहीं बनाता और न ही होस्टिंग कॉन्फ़िगरेशन देता है।
python3 regenerate_sitemap.py public https://example.com sh ./deploy-site.sh
आपकी प्रकाशन स्क्रिप्ट को उसी public फ़ोल्डर को अपलोड करना चाहिए, जिसमें sitemap.txt भी शामिल हो, और सार्वजनिक साइट से उन फ़ाइलों को हटाना चाहिए जो निर्यात में नहीं रहीं। साइटमैप बनने के बाद उसे पेजों का पुनर्निर्माण नहीं करना चाहिए। यदि प्रकाशक साइट भी बनाता है, तो उसके बिल्ड और अपलोड चरणों के बीच साइटमैप बनाएँ।
यदि साइटमैप बनाना विफल होता है, तो प्रकाशन कमांड छोड़ दी जाती है। यदि प्रकाशन विफल होता है, तो Python विफलता बताता है, लेकिन दूरस्थ साइट में आंशिक बदलाव हो चुके हो सकते हैं। फिर से कोशिश करने से पहले सार्वजनिक परिणाम जाँचें। जहाँ आपका होस्ट एक पूरा रिलीज़ साथ में प्रकाशित करने की सुविधा देता है, वहाँ उसके दस्तावेज़ों में बताए गए तरीके का उपयोग करें।
डेस्कटॉप अपलोडर के लिए, अपलोड हेतु निर्यात फ़ोल्डर चुनने से पहले साइटमैप बनाएँ। पुष्टि करें कि अपलोडर मौजूदा साइटमैप को बदलता है और हटाए गए पेजों को संभालता है। इसके लिए अपलोड की कार्रवाई करनी ही होगी; केवल स्थानीय रूप से साइटमैप बनाना बिना निगरानी सार्वजनिक प्रकाशन नहीं करता।
सार्वजनिक साइटमैप और हटाए गए पेज की अलग-अलग जाँच करें
सफल प्रकाशन के बाद ब्राउज़र में अपना वास्तविक सार्वजनिक sitemap.txt URL खोलें। जाँचें कि जोड़ा गया पेज मौजूद है और हटाया गया पेज नहीं है। फिर प्रभावित हर पेज को सीधे खोलें। इससे सही स्थानीय निर्यात और सही सार्वजनिक रिलीज़ के बीच अंतर पता चलता है।
साइटमैप से कोई प्रविष्टि हटाने से उस पेज के पुराने पते पर HTTP प्रतिक्रिया तय नहीं होती। जिस हटाए गए पेज का कोई विकल्प नहीं है, उसके लिए जाँचें कि होस्ट उपयुक्त गुम-पेज प्रतिक्रिया देता है। RFC 9110 ऐसे संसाधन के लिए 404 परिभाषित करता है जिसकी कोई मौजूदा प्रस्तुति नहीं है, और 410 तब लागू होता है जब उसके अनुपलब्ध रहने की संभावना स्थायी हो। RFC 9110: HTTP शब्दार्थ।
जो पेज गुम-पेज का संदेश दिखाता है, लेकिन 200 लौटाता है, उसे soft 404 माना जा सकता है। Google यह भी बताता है कि पहले इंडेक्स किए गए URL यदि लागू 4xx प्रतिक्रियाएँ लौटाते हैं, तो समय के साथ उसके इंडेक्स से हटा दिए जाते हैं। इसलिए URL को साइटमैप से हटाना उस पेज को हटाने का केवल एक हिस्सा है। HTTP स्थिति कोड Google के क्रॉलरों को कैसे प्रभावित करते हैं।
कुछ गलत दिखने पर यह जाँच क्रम अपनाएँ:
| दिखाई देने वाली समस्या | अगली जाँच |
|---|---|
| स्थानीय साइटमैप में अब भी हटाया गया पेज सूचीबद्ध है | देखें कि निर्यात में उसकी कोई फ़ाइल बची तो नहीं या गलत निर्यात फ़ोल्डर तो नहीं चुना गया |
| स्थानीय साइटमैप सही है, लेकिन सार्वजनिक प्रति अलग है | अपलोड किए गए फ़ोल्डर, गंतव्य और कैशिंग की जाँच करें |
| सार्वजनिक साइटमैप सही है, लेकिन हटाया गया पेज अब भी खुलता है | जाँचें कि प्रकाशन ने पुरानी दूरस्थ फ़ाइल हटाई या नहीं |
| बनाया गया URL गलत पेज खोलता है | फ़ाइलनाम परंपरा के अनुसार होस्ट की रूट मैपिंग जाँचें |
| नया URL सार्वजनिक है, लेकिन खोज में नहीं दिखता | खोज में खोजे जाने और इंडेक्स होने को अलग प्रक्रिया मानें |
कैशिंग के कारण सार्वजनिक साइटमैप अब भी अपरिवर्तित दिख सकता है। RFC 9111 बताता है कि कैश किए गए जवाब कब तक ताज़ा रहते हैं और उनका दोबारा सत्यापन कैसे होता है। यदि आपका होस्ट प्रतिक्रिया हेडर कॉन्फ़िगर करने की सुविधा देता है, तो Cache-Control: no-cache के तहत संग्रहित प्रतिक्रिया का फिर से उपयोग करने से पहले सफल सत्यापन आवश्यक होता है; केवल स्थानीय फ़ाइल बदलने से वह हेडर कॉन्फ़िगर नहीं होता। RFC 9111: HTTP कैशिंग।
साइटमैप का एक स्थिर पता बनाए रखें
Search Console की Sitemaps रिपोर्ट के ज़रिए या साइट की मौजूदा robots.txt फ़ाइल में उसका संदर्भ देकर सार्वजनिक साइटमैप को खोजने योग्य बनाएँ। Google दोनों तरीकों का वर्णन करता है और बताता है कि साइटमैप सबमिट करना केवल एक संकेत है। साइटमैप बनाएँ और सबमिट करें।
उदाहरण वाली साइट के लिए, खोज का संकेत देने वाली पंक्ति यह होगी:
Sitemap: https://example.com/sitemap.txt
प्रकाशन के दौरान साइटमैप की सामग्री बदलते हुए उसका पता स्थिर रखें। पूरा होने की व्यावहारिक जाँच यह है कि सार्वजनिक साइटमैप तैयार निर्यात से मेल खाता हो, जोड़ा गया पेज सूचीबद्ध URL पर खुलता हो और हटाया गया पेज अपेक्षित प्रतिक्रिया देता हो। सर्च इंजन इन बदलावों को अपने समय पर संसाधित करते हैं; साइटमैप में शामिल होने से क्रॉल या इंडेक्स होने की गारंटी नहीं मिलती। साइटमैप के बारे में जानें।
स्रोत
- साइटमैप बनाएँ और सबमिट करें — Google Search Central।
- साइटमैप के बारे में जानें — Google Search Central।
- साइटमैप का XML फ़ॉर्मैट — Sitemaps.org।
- HTML मानक: लिंक — WHATWG।
- macOS पर Python का उपयोग — Python Software Foundation।
- RFC 9110: HTTP शब्दार्थ — RFC Editor / IETF।
- RFC 9111: HTTP कैशिंग — RFC Editor / IETF।
- HTTP स्थिति कोड Google के क्रॉलरों को कैसे प्रभावित करते हैं — Google Crawling Infrastructure।