Google, robots.txt फ़ाइल के निर्देशों को कैसे समझता है

Google के अपने-आप काम करने वाले क्रॉलर, रोबोट एक्सक्लूज़न प्रोटोकॉल (आरईपी) के हिसाब से काम करते हैं. इसका मतलब है कि साइट को क्रॉल करने से पहले Google के क्रॉलर, साइट की robots.txt फ़ाइल को डाउनलोड और पार्स करते हैं. इससे यह जानकारी मिलती है कि साइट के किन हिस्सों को क्रॉल किया जा सकता है. आरईपी, Google के उन क्रॉलर पर लागू नहीं होता जिन्हें उपयोगकर्ता कंट्रोल करते हैं, जैसे कि फ़ीड सदस्यताएं. इसके अलावा, यह उन क्रॉलर पर भी लागू नहीं होता जिनका इस्तेमाल उपयोगकर्ता की सुरक्षा को बेहतर बनाने (जैसे: मैलवेयर का पता लगाने के लिए बारीकी से जांच करना) के लिए किया जाता है.

इस पेज में यह बताया गया है कि Google, आरईपी को किस तरह से समझता है. अगर आपको आरईपी के ओरिजनल ड्राफ़्ट में दर्ज मानकों को देखना है, तो आरएफ़सी 9309 देखें.

robots.txt फ़ाइल क्या हाेती है

अगर आपको क्रॉलर से, आपकी साइट के कुछ सेक्शन को क्रॉल नहीं करवाना है, तो इसके हिसाब से सही नियमों वाली robots.txt फ़ाइल बनाएं. robots.txt फ़ाइल एक सामान्य टेक्स्ट फ़ाइल होती है. इसमें वे नियम शामिल होते हैं जिनसे यह पता चलता है कि कौनसे क्रॉलर, आपकी साइट के किन हिस्सों को क्रॉल कर सकते हैं. उदाहरण के लिए, example.com के लिए robots.txt फ़ाइल कुछ ऐसी दिख सकती है:

# This robots.txt file controls crawling of URLs under https://example.com.
# All crawlers are disallowed to crawl files in the "includes" directory, such
# as .css, .js, but Google needs them for rendering, so Googlebot is allowed
# to crawl them.
User-agent: *
Disallow: /includes/

User-agent: Googlebot
Allow: /includes/

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

अगर आपको robots.txt फ़ाइल के बारे में ज़्यादा जानकारी नहीं है, तो robots.txt फ़ाइल के बारे में बुनियादी जानकारी से शुरुआत करें. robots.txt फ़ाइल बनाने के लिए सलाह भी देखी जा सकती है.

फ़ाइल लोकेशन और वह कहां-कहां मान्य है

आपको robots.txt फ़ाइल को साइट की टॉप लेवल वाली डायरेक्ट्री में रखना होगा. साथ ही, ऐसे प्रोटोकॉल का इस्तेमाल करना होगा जो उसके साथ काम करता हो. robots.txt फ़ाइल का यूआरएल, किसी दूसरे यूआरएल की तरह ही केस-सेंसिटिव (बड़े और छोटे अक्षरों में अंतर) होता है. Google Search के साथ ये प्रोटोकॉल काम करते हैं: एचटीटीपी, एचटीटीपीएस, और एफ़टीपी. एचटीटीपी और एचटीटीपीएस प्रोटोकॉल पर, क्रॉलर बिना शर्तों वाले एचटीटीपी GET अनुरोध से robots.txt फ़ाइल फ़ेच करते हैं. एफ़टीपी प्रोटोकॉल पर क्रॉलर, पहचान ज़ाहिर किए बिना लॉग इन करके स्टैंडर्ड RETR (RETRIEVE) कमांड का इस्तेमाल करते हैं.

robots.txt फ़ाइल में दिए गए नियम सिर्फ़ उन होस्ट, प्रोटोकॉल, और पोर्ट नंबर पर लागू होते हैं जहां robots.txt फ़ाइल होस्ट की गई हो.

मान्य robots.txt यूआरएल के उदाहरण

इस टेबल में, robots.txt के यूआरएल के उदाहरण दिए गए हैं. साथ ही, यह बताया गया है कि वे किन यूआरएल पाथ के लिए मान्य हैं. पहले कॉलम में robots.txt फ़ाइल का यूआरएल दिया गया है. दूसरे कॉलम में ऐसे डोमेन दिए गए हैं जिन पर robots.txt फ़ाइल लागू हो भी सकती है और नहीं भी.

robots.txt यूआरएल के उदाहरण
https://example.com/robots.txt	यह एक सामान्य मामला है. यह अन्य सबडोमेन, प्रोटोकॉल या पोर्ट नंबर के लिए मान्य नहीं है. यह एक ही होस्ट, प्रोटोकॉल, और पोर्ट नंबर पर मौजूद सभी सबडायरेक्ट्री की हर फ़ाइल के लिए मान्य है. इनके लिए मान्य है: https://example.com/ https://example.com/folder/file अमान्य यूआरएल: https://other.example.com/ http://example.com/ https://example.com:8181/
https://www.example.com/robots.txt	किसी सबडोमेन का robots.txt सिर्फ़ उस सबडोमेन के लिए ही मान्य होता है. मान्य यूआरएल: https://www.example.com/ अमान्य यूआरएल: https://example.com/ https://shop.www.example.com/ https://www.shop.example.com/
https://example.com/folder/robots.txt	यह robots.txt फ़ाइल मान्य नहीं है. क्रॉलर, सबडायरेक्ट्री में robots.txt फ़ाइलें नहीं खोजते हैं.
https://www.exämple.com/robots.txt	आईडीएन अपने प्यूनीकोड वर्शन जैसे होते हैं. आरएफ़सी 3492 भी देखें. इनके लिए मान्य है: https://www.exämple.com/ https://xn--exmple-cua.com/ अमान्य यूआरएल: https://www.example.com/
ftp://example.com/robots.txt	मान्य यूआरएल: ftp://example.com/ अमान्य यूआरएल: https://example.com/
https://212.96.82.21/robots.txt	अगर किसी robots.txt फ़ाइल का होस्ट नेम, आईपी पते के तौर पर दिया गया है, तो साइट को क्रॉल करने के लिए उसके होस्ट नेम में भी वही आईपी पता होना चाहिए. यह robots.txt फ़ाइल, उस आईपी पते पर होस्ट की गई सभी वेबसाइटों के लिए अपने-आप मान्य नहीं होती. हालांकि, हो सकता है कि इसे शेयर किया गया हो. इस स्थिति में, यह शेयर किए गए होस्ट नेम के लिए भी मान्य होगी. मान्य यूआरएल: https://212.96.82.21/ अमान्य यूआरएल: https://example.com/ (भले ही, इसे 212.96.82.21 पर क्यों न होस्ट किया गया हो)
https://example.com:443/robots.txt	स्टैंडर्ड पोर्ट नंबर (एचटीटीपी के लिए 80, एचटीटीपीएस के लिए 443, और एफ़टीपी के लिए 21) अपने डिफ़ॉल्ट होस्ट नेम की तरह ही काम करते हैं. मान्य यूआरएल: https://example.com:443/ https://example.com/ अमान्य यूआरएल: https://example.com:444/
https://example.com:8181/robots.txt	नॉन-स्टैंडर्ड पोर्ट नंबर पर मौजूद robots.txt फ़ाइलें, सिर्फ़ उन ही पोर्ट नंबर से उपलब्ध होने वाले कॉन्टेंट के लिए इस्तेमाल की जा सकती हैं. मान्य यूआरएल: https://example.com:8181/ अमान्य यूआरएल: https://example.com/

गड़बड़ियों और एचटीटीपी स्टेटस कोड को हैंडल करना

robots.txt फ़ाइल का अनुरोध करते समय, सर्वर के रिस्पॉन्स से मिले एचटीटीपी स्टेटस कोड का इस बात पर असर पड़ता है कि Google के क्रॉलर, robots.txt फ़ाइल का इस्तेमाल कैसे करेंगे. नीचे दी गई टेबल में यह खास जानकारी दी गई है कि Googlebot, अलग-अलग एचटीटीपी स्टेटस कोड के लिए robots.txt फ़ाइलों का इस्तेमाल कैसे करता है.

गड़बड़ियों और एचटीटीपी स्टेटस कोड को हैंडल करना
2xx (success)	कार्रवाई सफल होने का सिग्नल देने वाले एचटीटीपी स्टेटस कोड, Google के क्रॉलर को, सर्वर से उपलब्ध कराई गई robots.txt फ़ाइल को प्रोसेस करने का सिग्नल देते हैं.
3xx (redirection)	Google, आरएफ़सी 1945 के मुताबिक कम से कम पांच बार रीडायरेक्ट होकर आगे बढ़ने का तरीका अपनाता है. इसके बाद, वह रुकता है और इसे robots.txt फ़ाइल के लिए 404 मानकर इसका इस्तेमाल करता है. यह तरीका, रीडायरेक्ट चेन के किसी ऐसे यूआरएल पर भी लागू होता है जिसे क्रॉल करने की अनुमति न हो. ऐसा इसलिए होता है, क्योंकि क्रॉलर, रीडायरेक्ट की वजह से नियमों को फ़ेच नहीं कर पाता है. Google, robots.txt फ़ाइलों में लॉजिकल रीडायरेक्ट के मुताबिक काम नहीं करता (फ़्रेम, JavaScript या मेटा रीफ़्रेश-टाइप रीडायरेक्ट).
4xx (client errors)	4xx गड़बड़ियां मिलने पर, Google के क्रॉलर यह मानते हैं कि मान्य robots.txt फ़ाइल मौजूद नहीं है. हालांकि, इसमें 429 गड़बड़ियों को अपवाद माना जाता है. इसका मतलब है कि Google यह मानकर चलता है कि क्रॉल करने की कोई पाबंदी नहीं है. क्रॉल दर को सीमित करने के लिए, 401 और 403 स्टेटस कोड का इस्तेमाल न करें. 429 के अलावा, क्रॉल दर पर 4xx स्टेटस कोड का कोई असर नहीं पड़ता है. अपनी क्रॉल दर को सीमित करने का तरीका जानें.
5xx (server errors)	यह स्टेटस कोड तब मिलता है, जब सर्वर Google के robots.txt अनुरोध का सही रिस्पॉन्स नहीं दे पाता. इस वजह से Google, सर्वर की 5xx और 429 गड़बड़ियों को कुछ समय के लिए ऐसे देखता है जैसे कि पूरी साइट के लिए, अनुमति न मिली हो. Google, robots.txt फ़ाइल को क्रॉल करने की कोशिश तब तक करता रहता है, जब तक उसे बिना किसी सर्वर की गड़बड़ी वाला एचटीटीपी स्टेटस कोड नहीं मिल जाता. 503 (service unavailable) गड़बड़ी की वजह से कई बार कोशिश करनी पड़ती है. अगर robots.txt फ़ाइल को 30 से ज़्यादा दिनों से ऐक्सेस नहीं किया जा सका है, तो Google फ़ाइल की आखिरी बार कैश की गई मेमोरी का इस्तेमाल करता है. अगर robots.txt की कैश मेमोरी उपलब्ध नहीं है, तो Google यह मानकर चलता है कि क्रॉल करने की कोई पाबंदी नहीं है. अगर आपको क्रॉल करने की सुविधा कुछ समय के लिए रोकनी है, तो हमारा सुझाव है कि आप साइट पर मौजूद हर यूआरएल के लिए, एक 503 एचटीटीपी स्टेटस कोड दें. जो पेज मौजूद नहीं हैं उनके लिए, अगर हमें यह पता चलता है कि किसी साइट को 404 स्टेटस कोड की जगह 5xx दिखाने के लिए गलत तरीके से कॉन्फ़िगर किया गया है, तो हम उस साइट की 5xx गड़बड़ी को 404 के रूप में देखते हैं. उदाहरण के लिए, अगर 5xx स्टेटस कोड दिखाने वाले किसी पेज पर "पेज नहीं मिला" वाली गड़बड़ी का मैसेज दिखता है, तो हम स्टेटस कोड को 404 (not found) मानेंगे.
अन्य गड़बड़ियां	अगर डीएनएस या नेटवर्क से जुड़ी समस्याओं की वजह से robots.txt फ़ाइल फ़ेच नहीं हो पाती है, तो इसे सर्वर की गड़बड़ी माना जाता है. इन समस्याओं में, टाइम आउट, गलत जवाब, रीसेट होना या कनेक्शन में रुकावट, और एचटीटीपी के छोटे-छोटे हिस्सों में ट्रांसफ़र होने से जुड़ी गड़बड़ियां शामिल हैं.

कैश मेमोरी में रखना

Google आम तौर पर robots.txt फ़ाइल के कॉन्टेंट को 24 घंटों तक कैश मेमोरी में रखता है. हालांकि, ऐसी स्थितियों में इसे ज़्यादा समय के लिए रखा जा सकता है जब कैश मेमोरी में मौजूद वर्शन को रीफ़्रेश करना मुमकिन न हो. उदाहरण के लिए, टाइम आउट होने या 5xx की गड़बड़ियों की वजह से. कैश मेमोरी में रखे गए रिस्पॉन्स को कई क्रॉलर शेयर कर सकते हैं. मैक्स-एज कैश कंट्रोल वाले एचटीटीपी हेडर के आधार पर Google, कॉन्टेंट के कैश में बने रहने का समय घटा या बढ़ा सकता है.

फ़ाइल फ़ॉर्मैट

robots.txt फ़ाइल, UTF-8 एन्कोडिंग वाली सादी टेक्स्ट फ़ाइल होनी चाहिए और इसकी हर लाइन CR, CR/LF या LF से अलग की गई होनी चाहिए.

Google, robots.txt फ़ाइलों में अमान्य लाइनों को अनदेखा करता है और सिर्फ़ मान्य लाइनें इस्तेमाल करता है. अमान्य लाइनों में, robots.txt फ़ाइल की शुरुआत में दिया गया यूनिकोड बाइट ऑर्डर मार्क (बीओएम) भी शामिल होता है. उदाहरण के लिए, अगर डाउनलोड किया गया कॉन्टेंट robots.txt के नियमों की जगह एचटीएमएल है, तो Google, कॉन्टेंट को पार्स करने और नियम बनाने की कोशिश करेगा. साथ ही, बाकी सब कुछ अनदेखा कर देगा.

इसी तरह, अगर robots.txt फ़ाइल की कैरेक्टर एन्कोडिंग UTF-8 नहीं है, तो Google उन वर्णों को अनदेखा कर सकता है जो UTF-8 रेंज का हिस्सा नहीं हैं. ऐसे में, robots.txt के नियम अमान्य हो सकते हैं.

फ़िलहाल, Google ने robots.txt फ़ाइल की सीमा 500 किबीबाइट (केआईबी) तय की है. कॉन्टेंट के लिए तय साइज़ से बड़ी फ़ाइल को अनदेखा किया जाता है. robots.txt फ़ाइल के साइज़ को कम किया जा सकता है. इसके लिए, ऐसे नियमों को इकट्ठा करके एक ही जगह पर रखें जिनकी वजह से साइज़ तय सीमा से ऊपर जा रहा हो. उदाहरण के लिए, बाहर निकाला गया कॉन्टेंट अलग डायरेक्ट्री में रखें.

सिंटैक्स

मान्य robots.txt फ़ाइल की लाइनों में, एक फ़ील्ड, एक कोलन, और एक वैल्यू होती है. खाली जगहें ज़रूरी नहीं हैं. हालांकि, इनका इस्तेमाल करने का सुझाव दिया जाता है, ताकि कॉन्टेंट को बेहतर ढंग से पढ़ा जा सके. लाइन की शुरुआत और आखिर में बची हुई खाली जगह को अनदेखा कर दिया जाता है. टिप्पणियां शामिल करने के लिए, अपनी टिप्पणी के आगे # वर्ण लगाएं. ध्यान रखें कि # वर्ण के बाद की सभी चीज़ों को अनदेखा कर दिया जाएगा. सामान्य फ़ॉर्मैट <field>:<value><#optional-comment> है.

Google पर ये फ़ील्ड काम करते हैं:

• user-agent: इससे पता चलता है कि नियम किस क्रॉलर पर लागू होते हैं.
• allow: यह ऐसा यूआरएल पाथ होता है जिसे क्रॉल किया जा सकता है.
• disallow: यह ऐसा यूआरएल पाथ होता है जिसे क्रॉल नहीं किया जा सकता.
• sitemap: यह किसी साइटमैप का पूरा यूआरएल बताता है.

allow और disallow फ़ील्ड को नियम भी कहा जाता है. इन्हें डायरेक्टिव भी कहते हैं. ये नियम हमेशा rule: [path] के रूप में बताए जाते हैं, जहां [path] ज़रूरी नहीं होता है. डिफ़ॉल्ट रूप से, तय किए गए क्रॉलर के लिए क्रॉल करने पर कोई पाबंदी नहीं है. क्रॉलर, [path] के बिना नियमों को अनदेखा करते हैं.

अगर [path] वैल्यू बताई गई हो, तो वह उस वेबसाइट के रूट के मुताबिक होती है जहां से robots.txt फ़ाइल फ़ेच की गई थी. इसके लिए, उसी प्रोटोकॉल, पोर्ट नंबर, होस्ट, और डोमेन नेम का इस्तेमाल किया जाता है जो वेबसाइट के रूट में इस्तेमाल किए गए हों. रूट तय करने के लिए पाथ की वैल्यू / से शुरू होनी चाहिए और यह वैल्यू केस-सेंसिटिव होती है. पाथ वैल्यू के आधार पर यूआरएल मिलान के बारे में ज़्यादा जानें.

user-agent

user-agent लाइन से पता चलता है कि नियम किस क्रॉलर पर लागू होते हैं. उन उपयोगकर्ता एजेंट स्ट्रिंग की पूरी सूची देखने के लिए जिन्हें robots.txt फ़ाइल में इस्तेमाल किया जा सकता है, Google के क्रॉलर और उपयोगकर्ता एजेंट स्ट्रिंग देखें.

user-agent लाइन की वैल्यू केस-इनसेंसिटिव होती है.

disallow

disallow नियम उन पाथ के बारे में बताता है जिन्हें क्रॉलर को ऐक्सेस नहीं करना चाहिए. यह नियम उन क्रॉलर के लिए होता है जिन्हें disallow नियम के साथ ग्रुप की गई user-agent लाइन ने पहचाना हो. क्रॉलर, बिना नियम वाले पाथ को अनदेखा कर देते हैं.

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

disallow नियम की वैल्यू केस-सेंसिटिव होती है.

इस्तेमाल का तरीका:

disallow: [path]

allow

allow नियम ऐसे पाथ के बारे में बताता है जिन्हें तय क्रॉलर ऐक्सेस कर सकते हैं. जब कोई पाथ न बताया गया हो, तो नियम को अनदेखा कर दिया जाता है.

allow नियम की वैल्यू केस-सेंसिटिव होती है.

इस्तेमाल का तरीका:

allow: [path]

sitemap

जैसा कि sitemaps.org पर बताया गया है, Google, Bing, और अन्य लोकप्रिय सर्च इंजन पर, robots.txt फ़ाइल में sitemap फ़ील्ड काम करता है.

sitemap फ़ील्ड की वैल्यू केस-सेंसिटिव होती है.

इस्तेमाल का तरीका:

sitemap: [absoluteURL]

[absoluteURL] लाइन किसी साइटमैप या साइटमैप इंडेक्स फ़ाइल की लोकेशन बताती है. यह पूरी तरह से क्वालिफ़ाइड यूआरएल होना चाहिए, जिसमें प्रोटोकॉल और होस्ट की जानकारी शामिल हो. साथ ही, ज़रूरी नहीं है कि इस यूआरएल के डेटा को कोड में बदला गया हो. यह ज़रूरी नहीं है कि यूआरएल और robots.txt फ़ाइल एक ही होस्ट पर हों. एक से ज़्यादा sitemap फ़ील्ड तय किए जा सकते हैं. साइटमैप फ़ील्ड, किसी खास उपयोगकर्ता एजेंट से नहीं जुड़ा होता है. इसे सभी क्रॉलर फ़ॉलो कर सकते हैं. हालांकि, अगर इसे क्रॉल करने पर रोक लगी है, तो वे इसे क्रॉल नहीं कर पाएंगे.

उदाहरण के लिए:

user-agent: otherbot
disallow: /kale

sitemap: https://example.com/sitemap.xml
sitemap: https://cdn.example.org/other-sitemap.xml
sitemap: https://ja.example.org/テスト-サイトマップ.xml

लाइनों और नियमों के ग्रुप

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

उदाहरण के लिए:

user-agent: a
disallow: /c

user-agent: b
disallow: /d

user-agent: e
user-agent: f
disallow: /g

user-agent: h

इस उदाहरण में नियमों के चार अलग-अलग ग्रुप दिए गए हैं:

• उपयोगकर्ता एजेंट "a" के लिए एक ग्रुप.
• उपयोगकर्ता एजेंट "b" के लिए एक ग्रुप.
• "e" और "f", दोनों उपयोगकर्ता एजेंट के लिए एक ग्रुप.
• उपयोगकर्ता एजेंट "h" के लिए एक ग्रुप.

किसी ग्रुप के तकनीकी ब्यौरे के लिए, आरईपी का सेक्शन 2.1 देखें.

उपयोगकर्ता एजेंट के लिए प्राथमिकता का क्रम

हर क्रॉलर के लिए सिर्फ़ एक ग्रुप मान्य होता है. Google के क्रॉलर, नियमों का सही ग्रुप तय करते हैं. ऐसा करने के लिए, वे robots.txt फ़ाइल में उस खास उपयोगकर्ता एजेंट वाले ग्रुप को ढूंढते हैं जो क्रॉलर के उपयोगकर्ता एजेंट से मेल खाता हो. इस ग्रुप के अलावा, अन्य सभी ग्रुप को अनदेखा कर दिया जाता है. मेल न खाने वाले हर टेक्स्ट को अनदेखा कर दिया जाता है. जैसे, googlebot/1.2 और googlebot*, दोनों googlebot की तरह ही काम करते हैं. robots.txt फ़ाइल में ग्रुप किस क्रम में शामिल किए गए हैं, इसका क्रॉलिंग पर कोई असर नहीं पड़ता है.

हो सकता है कि किसी उपयोगकर्ता एजेंट के लिए एक से ज़्यादा ग्रुप दिए गए हों. ऐसे में, उस उपयोगकर्ता एजेंट पर लागू होने वाले सभी ग्रुप के सभी नियमों को अंदरूनी तौर पर मिलाकर एक ग्रुप बना दिया जाता है. उपयोगकर्ता एजेंट के खास ग्रुप और ग्लोबल ग्रुप (*) के नियमों को मिलाया नहीं जाता है.

उदाहरण

user-agent फ़ील्ड का मिलान

user-agent: googlebot-news
(group 1)

user-agent: *
(group 2)

user-agent: googlebot
(group 3)

क्रॉलर, काम के ग्रुप इस तरह से चुनेंगे:

वे ग्रुप जिन्हें क्रॉलर फ़ॉलो करते हैं
Googlebot-News	googlebot-news, ग्रुप 1 को फ़ॉलो करता है, क्योंकि इसे खास तौर पर इसी क्रॉलर के लिए बनाया गया है.
Googlebot (वेब)	googlebot, ग्रुप 3 को फ़ॉलो करता है.
Googlebot Storebot	Storebot-Google, ग्रुप 2 को फ़ॉलो करता है, क्योंकि Storebot-Google के लिए कोई खास ग्रुप नहीं बनाया गया है.
Googlebot-News (इमेज क्रॉल करते समय)	इमेज क्रॉल करते समय googlebot-news, ग्रुप 1 को फ़ॉलो करता है. googlebot-news, Google Images के लिए इमेज क्रॉल नहीं करता है. इसलिए, यह सिर्फ़ ग्रुप 1 को फ़ॉलो करता है.
दूसरा-बॉट (वेब)	अन्य Google क्रॉलर, ग्रुप 2 को फ़ॉलो करते हैं.
Otherbot (समाचार)	Google के ऐसे अन्य क्रॉलर जो समाचार से जुड़ा कॉन्टेंट क्रॉल करते हैं, लेकिन googlebot-news नहीं होते, वे ग्रुप 2 को फ़ॉलो करते हैं. किसी मिलते-जुलते क्रॉलर के लिए कोई एंट्री होने पर, यह सिर्फ़ तब ही मान्य होगा, जब यह खास तौर पर मेल खाता हो.

नियमों का ग्रुप बनाना

अगर robots.txt फ़ाइल में ऐसे कई ग्रुप हैं जो किसी खास उपयोगकर्ता एजेंट के काम के हैं, तो Google के क्रॉलर उन सभी ग्रुप को अंदरूनी तौर पर मर्ज कर देते हैं. उदाहरण के लिए:

user-agent: googlebot-news
disallow: /fish

user-agent: *
disallow: /carrots

user-agent: googlebot-news
disallow: /shrimp

क्रॉलर, उपयोगकर्ता एजेंट के हिसाब से अंदरूनी तौर पर नियमों का ग्रुप बनाते हैं, उदाहरण के लिए:

user-agent: googlebot-news
disallow: /fish
disallow: /shrimp

user-agent: *
disallow: /carrots

allow, disallow, और user-agent के अलावा, दूसरे नियमों को robots.txt पार्सर अनदेखा कर देता है. इसका मतलब है कि नीचे दिए गए robots.txt स्निपेट को एक ग्रुप माना जाता है. इसलिए, user-agent a, और b पर disallow: / नियम का असर पड़ता है:

user-agent: a
sitemap: https://example.com/sitemap.xml

user-agent: b
disallow: /

जब क्रॉलर robots.txt के नियमों को प्रोसेस करते हैं, तो वे sitemap लाइन को अनदेखा कर देते हैं. उदाहरण के लिए, क्रॉलर पिछले robots.txt स्निपेट को इस तरह समझेंगे:

user-agent: a
user-agent: b
disallow: /

पाथ की वैल्यू के आधार पर यूआरएल का मिलान

Google allow और disallow नियम में दी गई पाथ वैल्यू का इस्तेमाल करता है. पाथ की वैल्यू को आधार बनाकर, Google यह तय करता है कि साइट के किसी खास यूआरएल पर कोई नियम लागू होगा या नहीं. इसके लिए, नियम की तुलना यूआरएल के उस पाथ कॉम्पोनेंट से की जाती है जिसे क्रॉलर फ़ेच करने की कोशिश कर रहा हो. किसी पाथ में, गैर 7-बिट ASCII वर्णों को UTF-8 वर्णों के रूप में शामिल किया जा सकता है. इसके अलावा, इन्हें हर आरएफ़सी 3986 के पर्सेंट-एस्केप्ड UTF-8 कोड में बदले गए वर्णों के रूप में भी शामिल किया जा सकता है.

Google, Bing, और अन्य प्रमुख सर्च इंजन पर, पाथ की अलग-अलग वैल्यू के लिए कुछ ही तरह के वाइल्डकार्ड इस्तेमाल किए जा सकते हैं. ये वाइल्डकार्ड वर्ण इस्तेमाल किए जा सकते हैं:

• * किसी भी मान्य वर्ण के 0 या उससे ज़्यादा इंस्टेंस बताता है.
• $ से यूआरएल के आखिरी हिस्से की जानकारी मिलती है.

यहां दी गई टेबल से पता चलता है कि अलग-अलग वाइल्डकार्ड वर्णों से पार्सिंग पर क्या असर पड़ता है:

मिलते-जुलते पाथ के उदाहरण
/	रूट और किसी भी निचले स्तर के यूआरएल से मेल खाता है.
/*	/ की तरह ही काम करता है. आखिर में लगे हुए वाइल्डकार्ड को अनदेखा कर दिया जाता है.
/$	सिर्फ़ रूट से मेल खाता है. किसी भी निचले लेवल के यूआरएल को क्रॉल किया जा सकता है.
/fish	/fish से शुरू होने वाले किसी भी पाथ से मेल खाता है. ध्यान रखें कि मेल खाने का तरीका केस-सेंसिटिव (बड़े और छोटे अक्षरों में अंतर) होता है. मेल खाता है: /fish /fish.html /fish/salmon.html /fishheads /fishheads/yummy.html /fish.php?id=anything वे पाथ जो मेल नहीं खाते हैं: /Fish.asp /catfish /?id=fish /desert/fish
/fish*	/fish के बराबर. आखिर में लगे हुए वाइल्डकार्ड को अनदेखा कर दिया जाता है. मेल खाता है: /fish /fish.html /fish/salmon.html /fishheads /fishheads/yummy.html /fish.php?id=anything वे पाथ जो मेल नहीं खाते हैं: /Fish.asp /catfish /?id=fish /desert/fish
/fish/	/fish/ फ़ोल्डर में मौजूद किसी भी चीज़ से मेल खाता है. मेल खाता है: /fish/ /fish/?id=anything /fish/salmon.htm वे पाथ जो मेल नहीं खाते हैं: /fish /fish.html /animals/fish/ /Fish/Salmon.asp
/*.php	.php वाले किसी भी पाथ से मेल खाता है. मेल खाता है: /index.php /filename.php /folder/filename.php /folder/filename.php?parameters /folder/any.php.file.html /filename.php/ वे पाथ जो मेल नहीं खाते हैं: / (भले ही इसे /index.php से मैप किया जाए) /windows.PHP
/*.php$	.php से खत्म होने वाले किसी भी पाथ से मेल खाता है. मेल खाता है: /filename.php /folder/filename.php वे पाथ जो मेल नहीं खाते हैं: /filename.php?parameters /filename.php/ /filename.php5 /windows.PHP
/fish*.php	ऐसे किसी भी पाथ से मेल खाता है जिसमें /fish और .php शामिल हों और ये इसी क्रम में शामिल हों. मेल खाता है: /fish.php /fishheads/catfish.php?parameters वे पाथ जो मेल नहीं खाते हैं:/Fish.PHP

नियमों के लिए प्राथमिकता का क्रम

robots.txt के नियमों का यूआरएल से मिलान करते समय क्रॉलर, नियम के पाथ की लंबाई के आधार पर सबसे सटीक नियम का इस्तेमाल करते हैं. अलग-अलग नियम होने के मामले में, Google सबसे कम पाबंदी वाले नियम का इस्तेमाल करता है. इन नियमों में, वाइल्डकार्ड वाले नियम भी शामिल हैं.

इस उदाहरण से यह पता चलता है कि दिए गए यूआरएल पर, Google के क्रॉलर कौनसे नियम लागू करेंगे.

स्थितियों के उदाहरण
https://example.com/page	allow: /p disallow: / लागू होने वाला नियम: allow: /p, क्योंकि यह ज़्यादा सटीक है.
https://example.com/folder/page	allow: /folder disallow: /folder लागू होने वाला नियम: allow: /folder, क्योंकि अलग-अलग नियमों के मामले में, Google सबसे कम पाबंदी वाले नियम का इस्तेमाल करता है.
https://example.com/page.htm	allow: /page disallow: /*.htm लागू होने वाला नियम: disallow: /*.htm, क्योंकि नियम का पाथ लंबा है और यह यूआरएल में ज़्यादा वर्णों से मेल खाता है, इसलिए यह ज़्यादा सटीक है.
https://example.com/page.php5	allow: /page disallow: /*.ph लागू होने वाला नियम: allow: /page, क्योंकि अलग-अलग नियमों के मामले में, Google सबसे कम पाबंदी वाले नियम का इस्तेमाल करता है.
https://example.com/	allow: /$ disallow: / लागू होने वाला नियम: allow: /$, क्योंकि यह ज़्यादा सटीक है.
https://example.com/page.htm	allow: /$ disallow: / लागू होने वाला नियम: disallow: /, क्योंकि allow नियम सिर्फ़ रूट यूआरएल पर लागू होता है.