2026 में WordPress robots.txt की सही प्रैक्टिस (इसमें असल में क्या डालें)

एक अच्छी WordPress robots.txt लगभग पाँच लाइन लंबी होती है। /wp-admin/ रोकिए, admin-ajax.php को अनुमति दीजिए, क्रॉलर को अपने साइटमैप की ओर भेजिए, और वहीं रुक जाइए — फ़ोरम पर मिलने वाली 40-लाइन की फैली हुई ब्लॉकलिस्ट ज़्यादातर या तो रेंडरिंग तोड़ती हैं या कुछ करती ही नहीं। पूरी फ़ाइल:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://example.com/wp-sitemap.xml

डोमेन बदल लीजिए, और अगर आप ऐसा SEO प्लगइन इस्तेमाल करते हैं जो साइटमैप अपने हाथ में ले लेता है, तो Sitemap लाइन को उस प्लगइन के इंडेक्स की ओर मोड़ दीजिए। बस इतना ही। अगर आपकी फ़ाइल इससे लंबी है, तो अतिरिक्त लाइनें शायद आपसे कुछ वसूल रही हैं।

WordPress पहले से एक बनाता है — जब तक आप असली फ़ाइल न बना दें

WordPress एक वर्चुअल robots.txt देता है। जब /robots.txt के लिए रिक्वेस्ट आती है और आपके वेब रूट में कोई असली फ़ाइल नहीं होती, तो WordPress रिक्वेस्ट पकड़कर जवाब मेमोरी में छाप देता है। डिस्क पर कुछ नहीं लिखा जाता। डिफ़ॉल्ट आउटपुट ऊपर वाला wp-admin ब्लॉक है, साथ में wp-sitemap.xml के लिए एक Sitemap: लाइन जो कोर WordPress 5.5 से भेज रहा है।

दो चीज़ें इस आउटपुट को बदलती हैं। अगर Settings → Reading → Discourage search engines from indexing this site पर निशान लगा है, तो WordPress पूरी चीज़ की जगह Disallow: / रख देता है, जो सब कुछ रोक देता है। लॉन्च के बाद किसी साइट के सर्च से गायब हो जाने की सबसे आम वजह यही चेकबॉक्स है। दूसरी, प्लगइन और थीम robots_txt फ़िल्टर के ज़रिए वर्चुअल आउटपुट बदल सकते हैं — SEO प्लगइन इसी से अपनी साइटमैप लाइन और नियम डालते हैं।

अब वह हिस्सा जो लोगों की पूरी दोपहर खा जाता है। आपके वेब रूट में पड़ी एक भौतिक robots.txt फ़ाइल इन सबको चुपचाप ओवरराइड कर देती है। आपका वेब सर्वर डिस्क पर असली फ़ाइल पाता है, उसे परोस देता है, और WordPress लोड ही नहीं होता। वर्चुअल जनरेटर नहीं चलता। robots_txt फ़िल्टर नहीं चलता। आपके SEO प्लगइन का robots.txt एडिटर शायद अब भी एक सुंदर इंटरफ़ेस में सही नियम दिखाता रहे, और उनमें से कुछ भी किसी क्रॉलर तक नहीं पहुँचेगा।

नियम कहाँ रहते हैं	WordPress एडमिन में सम्पादन	लाइव रिक्वेस्ट पर कौन जीतता है
वर्चुअल (डिस्क पर कोई फ़ाइल नहीं)	हाँ, robots_txt फ़िल्टर या प्लगइन से	सिर्फ़ तब जब कोई भौतिक फ़ाइल न हो
वेब रूट में भौतिक फ़ाइल	तभी जब प्लगइन डिस्क पर लिखता हो	हमेशा

इसलिए कुछ भी डीबग करने से पहले: ब्राउज़र में https://yoursite.com/robots.txt खोलिए, फिर SFTP या अपने होस्ट के फ़ाइल मैनेजर से जाँचिए कि wp-config.php और .htaccess के बगल में कोई असली robots.txt तो नहीं पड़ी। अगर है, तो वही आपकी robots.txt है। या तो उसे वहीं सम्पादित कीजिए या मिटाकर WordPress को कमान दीजिए — पर एक ही चुनिए। दोनों साथ चलाने से ही साइटों पर वह पुराना साइटमैप URL रह जाता है जिसे कोई ढूँढ़ नहीं पाता।

/wp-admin/ क्यों रोका जाता है पर admin-ajax.php की अनुमति क्यों है

/wp-admin/ में डैशबोर्ड रहता है। वे URL सर्च परिणामों में बेकार हैं और उन्हें क्रॉल करना ऐसे पेजों पर क्रॉल बजट जलाता है जो लॉगिन स्क्रीन पर रीडायरेक्ट कर देते हैं। इस डायरेक्ट्री को रोकने पर कोई विवाद नहीं।

admin-ajax.php उसी डायरेक्ट्री में है पर एडमिन पेज नहीं है। यह वह एंडपॉइंट है जिससे प्लगइन और थीम फ़्रंट-एंड AJAX रिक्वेस्ट सँभालते हैं — लोड-मोर बटन, फ़िल्टर होने वाले प्रोडक्ट ग्रिड, कैलकुलेटर, फ़ॉर्म। अगर क्रॉलर इसे नहीं ला सकता, तो वह उन फ़ीचरों से लोड होने वाली सामग्री भी नहीं देख सकता, और Google आपके पेज को वैसे रेंडर करता है जैसे कोई विज़िटर उसे टूटे हुए फ़ीचर के साथ देखता।

आपकी ख़ास साइट पर Google को admin-ajax.php लाने की ज़रूरत है भी या नहीं, यह इस पर निर्भर करता है कि आपका फ़्रंट एंड उसका उपयोग करता है या नहीं। ईमानदार जवाब: कई आधुनिक साइटों पर इससे कोई फ़र्क ही नहीं पड़ता, क्योंकि थीम उसकी जगह /wp-json/ पर REST API इस्तेमाल करती है। Allow लाइन एक असली गड़बड़ी के ख़िलाफ़ सस्ता बीमा है, रैंकिंग फ़ैक्टर नहीं। इसे रहने दीजिए, क्योंकि इसकी कोई क़ीमत नहीं।

/wp-content/ या /wp-includes/ मत रोकिए

robots.txt को लेकर अब भी घूम रही यह सबसे ख़राब सलाह है, और यह उस दौर की है जब Google पेज रेंडर नहीं करता था।

/wp-content/ में आपकी थीम, प्लगइन और अपलोड होते हैं — वही स्टाइलशीट, स्क्रिप्ट और इमेज जिनसे आपके पेज पेज जैसे लगते हैं। /wp-includes/ में वह कोर JavaScript है जिस पर प्लगइन निर्भर करते हैं। Google आपके पेज को आँकने से पहले हेडलेस ब्राउज़र से रेंडर करता है। इन डायरेक्ट्री को रोक दीजिए और रेंडरर को बिना CSS, बिना इमेज वाला पेज मिलेगा। Google जिसका मूल्यांकन करेगा वह बिना स्टाइल के टेक्स्ट की दीवार और टूटा लेआउट होगा, जो इस पर असर डालता है कि वह आपकी सामग्री को कैसे समझता है और मोबाइल यूज़ेबिलिटी कैसे आँकता है।

अगर आपको विरासत में ऐसी फ़ाइल मिली है, तो ये लाइनें हटा दीजिए:

Disallow: /wp-content/
Disallow: /wp-includes/
Disallow: /wp-content/plugins/
Disallow: /wp-content/themes/

नुक़सान की पुष्टि आप ख़ुद Google Search Console के URL Inspection टूल में कर सकते हैं। किसी भी पेज पर लाइव टेस्ट चलाइए, रेंडर किया गया स्क्रीनशॉट देखिए, और पेज रिसोर्स की सूची में ब्लॉक हुई चीज़ें जाँचिए। अगर आपकी CSS ब्लॉक दिख रही है, तो वजह यही है।

Sitemap निर्देश

एक लाइन, निरपेक्ष URL, और यह फ़ाइल में कहीं भी रह सकती है — यह किसी User-agent समूह से बँधी नहीं है।

Sitemap: https://example.com/wp-sitemap.xml

वही URL इस्तेमाल कीजिए जो सचमुच खुलता है। WordPress कोर wp-sitemap.xml परोसता है। ज़्यादातर SEO प्लगइन कोर साइटमैप बंद करके अपना इंडेक्स किसी और पाथ पर देते हैं, आमतौर पर sitemap_index.xml। लाइन तय करने से पहले अपना URL ब्राउज़र में खोलकर देखिए — 404 की ओर इशारा करती Sitemap लाइन लाइन न होने से बुरी है, क्योंकि ऑडिट में वह सही लगती है।

एक से ज़्यादा साइटमैप लिखना ठीक है, हर एक अलग लाइन पर। Search Console में साइटमैप जमा करना अब भी अलग से करने लायक है; robots.txt वाला निर्देश उन क्रॉलरों के लिए है जो आपका Search Console अकाउंट कभी नहीं देखते।

robots.txt न noindex है, न सुरक्षा

robots.txt से होने वाला ज़्यादातर नुक़सान इन्हीं दो ग़लतफ़हमियों से आता है।

किसी URL को ब्लॉक करने से वह Google से हट नहीं जाता। robots.txt क्रॉलिंग तय करती है। अगर कोई दूसरी साइट किसी ब्लॉक किए URL से लिंक करती है, तो Google उस URL को ख़ुद इंडेक्स कर सकता है — आपको सिर्फ़ पता दिखता है और साथ में नोट कि कोई जानकारी उपलब्ध नहीं। और एक बदतर जाल भी है: अगर किसी पेज पर पहले से noindex मेटा टैग है और फिर आप उसे robots.txt में ब्लॉक कर देते हैं, तो Google उसे क्रॉल नहीं कर पाता, noindex देख नहीं पाता, और पेज अनिश्चित काल तक इंडेक्स में बना रह सकता है। किसी पेज को हटाना है तो क्रॉलिंग की अनुमति दीजिए और पेज के हेड में noindex मेटा रोबोट्स टैग या X-Robots-Tag HTTP हेडर भेजिए। Google ने 2019 में robots.txt के भीतर noindex निर्देशों का समर्थन बंद कर दिया था।

किसी पाथ को ब्लॉक करने से उसकी रक्षा नहीं होती। आपकी robots.txt परिभाषा से ही सार्वजनिक है। उसमें /private-client-files/ लिखना हर विज़िटर और हर स्कैनर को ठीक-ठीक बता देता है कि कहाँ देखना है, और पालन स्वैच्छिक है — Google मानता है, बदनीयत बॉट नहीं। जिस चीज़ की रक्षा ज़रूरी है उसे प्रमाणीकरण, IP पाबंदी या .htaccess में सर्वर-स्तरीय नियम चाहिए, न कि एक टेक्स्ट फ़ाइल में लिखी वह लाइन जो निशाना ही बता देती है।

जो नियम जोड़ने लायक हैं, और जो छोड़ने लायक

दो चीज़ें कई साइटों पर सचमुच काम की हैं। सर्च-रिज़ल्ट पाथ रोकने से क्रॉलर आपकी आंतरिक खोज से अनगिनत कम-मूल्य URL बनाना बंद कर देते हैं। WooCommerce पर कार्ट या चेकआउट पाथ रोकने से सेशन-पैरामीटर वाले URL क्रॉल से बाहर रहते हैं।

Disallow: /?s=
Disallow: /search/

ये छोड़ दीजिए:

• Crawl-delay — Google इसे पूरी तरह अनदेखा करता है। सर्वर लोड की असली समस्या हो तो Search Console के क्रॉल रेट कंट्रोल इस्तेमाल कीजिए।
• /feed/ या /trackback/ रोकना — ये हानिरहित URL हैं, और फ़ीड काम की होती हैं।
• अलग-अलग बॉट नामों की लंबी सूची — जिन बॉट को लोग रोकना चाहते हैं उनमें से ज़्यादातर वैसे भी अपनी पहचान ईमानदारी से नहीं बताते।
• /wp-json/ रोकना — हो सकता है आपकी थीम सामग्री रेंडर करने के लिए यही इस्तेमाल करती हो।

फ़ाइल WordPress robots.txt जनरेटर से बनाइए, जो न्यूनतम सही संस्करण तैयार करता है और सिंटैक्स हाथ से लिखे बिना सर्च तथा कॉमर्स वाले नियम जोड़ने देता है।

बदलाव के बाद

https://yoursite.com/robots.txt सीधे लोड कीजिए और पक्का कीजिए कि परोसे गए बाइट वही हैं जिनकी आप उम्मीद कर रहे हैं — न कि वह जो आपके प्लगइन का एडिटर दिखा रहा है। फिर Search Console में किसी सामान्य पेज पर लाइव URL इंस्पेक्शन चलाइए और देखिए कि कोई CSS या JavaScript संसाधन ब्लॉक होकर तो नहीं लौट रहा। Google robots.txt को क़रीब एक दिन कैश करता है, इसलिए न सुधार तुरंत लागू होगा, न ग़लती। यही देरी वह वजह है कि प्रोडक्शन में टेस्ट करके इंतज़ार करने के बजाय ध्यान से जाँच कर लेनी चाहिए।