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

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

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

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

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

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

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

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

Robots.txt के यूआरएल के उदाहरण
http://example.com/robots.txt मान्य यूआरएल:
  • http://example.com/
  • http://example.com/folder/file
अमान्य यूआरएल:
  • http://other.example.com/
  • https://example.com/
  • http://example.com:8181/
http://www.example.com/robots.txt

मान्य यूआरएल:http://www.example.com/

अमान्य यूआरएल:

  • http://example.com/
  • http://shop.www.example.com/
  • http://www.shop.example.com/
http://example.com/folder/robots.txt यह robots.txt फ़ाइल मान्य नहीं है. क्रॉलर, सबडायरेक्ट्री में robots.txt फ़ाइलें नहीं खोजते हैं.
http://www.exämple.com/robots.txt मान्य यूआरएल:
  • http://www.exämple.com/
  • http://xn--exmple-cua.com/

अमान्य यूआरएल:http://www.example.com/

ftp://example.com/robots.txt

मान्य यूआरएल:ftp://example.com/

अमान्य यूआरएल:http://example.com/

http://212.96.82.21/robots.txt

मान्य यूआरएल:http://212.96.82.21/

अमान्य यूआरएल:http://example.com/ (भले ही, इसे 212.96.82.21 पर क्यों न होस्ट किया गया हो)

http://example.com:80/robots.txt

मान्य यूआरएल:

  • http://example.com:80/
  • http://example.com/

अमान्य यूआरएल:http://example.com:81/

http://example.com:8181/robots.txt

मान्य यूआरएल:http://example.com:8181/

अमान्य यूआरएल:http://example.com/

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

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

गड़बड़ियों और एचटीटीपी स्टेटस कोड को हैंडल करना
2xx (सफल) कार्रवाई सफल होने का सिग्नल देने वाला एचटीटीपी स्टेटस कोड, Google के क्रॉलर को, सर्वर से उपलब्ध कराई गई robots.txt फ़ाइल को प्रोसेस करने का सिग्नल देता है.
3xx (रीडायरेक्ट करना)

Google, आरएफ़सी 1945 के मुताबिक कम से कम पांच बार रीडायरेक्ट होकर आगे बढ़ने का तरीका अपनाता है. इसके बाद, वह रुकता है और इसे robots.txt फ़ाइल के लिए 404 मानकर इसका इस्तेमाल करता है. यह तरीका, रीडायरेक्ट चेन के किसी ऐसे यूआरएल पर भी लागू होता है जिसे क्रॉल करने की अनुमति न हो. ऐसा इसलिए होता है, क्योंकि क्रॉलर, रीडायरेक्ट की वजह से नियमों को फ़ेच नहीं कर पाता है.

Google, robots.txt फ़ाइलों में लॉजिकल रीडायरेक्ट के मुताबिक काम नहीं करता (फ़्रेम, JavaScript या मेटा रीफ़्रेश-टाइप रीडायरेक्ट).

4xx (क्लाइंट गड़बड़ियां)

4xx गड़बड़ियां मिलने पर, Google के क्रॉलर यह मानते हैं कि मान्य robots.txt फ़ाइल मौजूद नहीं है. इसका मतलब है कि वे बिना किसी पाबंदी के क्रॉल कर सकते हैं.

5xx (सर्वर की गड़बड़ी)

यह स्टेटस कोड तब मिलता है, जब सर्वर Google के robots.txt अनुरोध का सही रिस्पॉन्स नहीं दे पाता है. इस वजह से Google, सर्वर की गड़बड़ियों को कुछ समय के लिए ऐसे देखता है, जैसे कि पूरी साइट के लिए अनुमति न मिली हो. Google, robots.txt फ़ाइल को क्रॉल करने की कोशिश तब तक करता रहता है, जब तक उसे बिना किसी सर्वर की गड़बड़ी वाला एचटीटीपी स्टेटस कोड नहीं मिल जाता. 503 (service unavailable) गड़बड़ी की वजह से कई बार कोशिश करनी पड़ती है. अगर robots.txt फ़ाइल को 30 से ज़्यादा दिनों से ऐक्सेस नहीं किया जा सका है, तो Google पिछली बार कैश की गई मेमोरी का इस्तेमाल करता है. अगर robots.txt की पिछली कॉपी उपलब्ध नहीं है, तो Google यह मानकर चलता है कि क्रॉल करने की कोई पाबंदी नहीं है.

जो पेज मौजूद नहीं हैं उनके लिए, अगर हमें यह पता चलता है कि किसी साइट को 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 फ़ील्ड को डायरेक्टिव भी कहा जाता है. ये डायरेक्टिव हमेशा directive: [path] के रूप में बताए जाते हैं, जहां [path] ज़रूरी नहीं होता है. डिफ़ॉल्ट रूप से, तय किए गए क्रॉलर के लिए क्रॉल करने पर कोई प्रतिबंध नहीं है. क्रॉलर, बिना [path] वाले डायरेक्टिव को अनदेखा करते हैं.

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

user-agent

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

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

disallow

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

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 Images googlebot-images, ग्रुप 2 को फ़ॉलो करता है, क्योंकि googlebot-images के लिए कोई खास ग्रुप नहीं बनाया गया है.
Googlebot-News (इमेज क्रॉल करते समय) इमेज क्रॉल करते समय googlebot-news, ग्रुप 1 को फ़ॉलो करता है. googlebot-news, Google Images के लिए इमेज क्रॉल नहीं करता है. इसलिए, यह सिर्फ़ ग्रुप 1 को फ़ॉलो करता है.
Otherbot (वेब) अन्य 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
/fish/

/fish/ फ़ोल्डर में मौजूद किसी भी चीज़ से मेल खाता है.

मिलते-जुलते पाथ:

  • /fish/
  • /animals/fish/
  • /fish/?id=anything
  • /fish/salmon.htm

वे पाथ जो मेल नहीं खाते हैं:

  • /fish
  • /fish.html
  • /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 के क्रॉलर कौनसे नियम लागू करेंगे.

स्थितियों के उदाहरण
http://example.com/page

allow: /p
disallow: /

लागू होने वाला नियम: allow: /p, क्योंकि यह ज़्यादा सटीक है.

http://example.com/folder/page

allow: /folder
disallow: /folder

लागू होने वाला नियम: allow: /folder, क्योंकि मिलते-जुलते नियमों के मामले में, Google सबसे कम पाबंदी वाले नियम का इस्तेमाल करता है.

http://example.com/page.htm

allow: /page
disallow: /*.htm

लागू होने वाला नियम: disallow: /*.htm, क्योंकि यह यूआरएल में ज़्यादा वर्णों से मेल खाता है. इसलिए, यह ज़्यादा सटीक है.

http://example.com/page.php5

allow: /page
disallow: /*.ph

लागू होने वाला नियम: allow: /page, क्योंकि मिलते-जुलते नियमों के मामले में, Google सबसे कम पाबंदी वाले नियम का इस्तेमाल करता है.

http://example.com/

allow: /$
disallow: /

लागू होने वाला नियम: allow: /$, क्योंकि यह ज़्यादा सटीक है.

http://example.com/page.htm

allow: /$
disallow: /

लागू होने वाला नियम: disallow: /, क्योंकि allow नियम सिर्फ़ रूट यूआरएल पर लागू होता है.