Robots.txt की विशेषताएं

संक्षेप

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

ज़रूरी भाषा

इस दस्तावेज़ में मुख्य शब्द "करना ही है", "नहीं करना है", "ज़रूरी", "करना चाहिए", "नहीं करना चाहिए", "चाहिए", "नहीं होना चाहिए", "सुझाया गया", "किया जा सकता है" और "वैकल्पिक" का मतलब आरएफ़सी 2119 में दी गई जानकारी के मुताबिक समझना चाहिए.

मूल परिभाषाएं

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

लागू होने की शर्तें

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

फ़ाइल की जगह और वह कहां-कहां मान्य है

robots.txt फ़ाइल को होस्ट की सबसे ऊपर के लेवल वाले डायरेक्ट्री में होना चाहिए, जिसे सही प्रोटोकॉल और पोर्ट नंबर से एक्सेस किया जा सके. robots.txt (और वेबसाइटों के क्रॉलिंग) के लिए आम तौर पर स्वीकार किए गए प्रोटोकॉल "http" और "https" हैं. http और https पर, robots.txt फ़ाइल को एचटीटीपी के बिना किसी शर्त वाले GET अनुरोध का इस्तेमाल करके लाया जाता है.

खास Google के लिए : Google एफ़टीपी साइटों के लिए भी robots.txt फ़ाइलों को स्वीकार करता है और उन्हें फ़ॉलो भी करता है. एफ़टीपी पर आधारित 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.müller.eu/robots.txt इनके लिए मान्य:
  • http://www.müller.eu/
  • http://www.xn--mller-kva.eu/

इसके लिए मान्य नहीं: http://www.muller.eu/

ftp://example.com/robots.txt

इसके लिए मान्य: ftp://example.com/

इसके लिए मान्य नहीं: http://example.com/

खास Google के लिए: हम एफ़टीपी संसाधनों के लिए robots.txt का इस्तेमाल करते हैं.

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 में निर्देश कुछ सामग्री को क्रॉल करने की योग्यता तय करते हैं.
एचटीटीपी नतीजे के कोड संभालना
2xx (सफ़ल) पूरा होने का संकेत देने वाले एचटीटीपी नतीजे के कोड क्रॉलिंग की "शर्त के साथ अनुमति" के रूप में नतीजे देते हैं.
3xx (दूसरे वेबलिंक पर भेजना) रीडायरेक्ट को आम तौर पर तब तक फ़ॉलो किया जाएगा, जब तक कि एक मान्य नतीजा नहीं मिल जाता (या एक लूप की पहचान नहीं हो जाती). हम सीमित संख्या में रीडायरेक्ट होकर आगे बढ़ना फ़ॉलो करेंगे (एचटीटीपी/1.0 के लिए (आरएफ़सी 1945 पाँच बार तक आगे बढ़ने देता है) और फिर इसे रोकेंगे और 404 के रूप में देखेंगे. अस्वीकार किए गए यूआरएल पर robots.txt रीडायरेक्ट के इस्तेमाल के बारे में कुछ नहीं बताया गया है और इससे बचने की सलाह दी जाती है. 2xx (फ़्रेम, JavaScript या मेटा रीफ़्रेश-प्रकार रीडायरेक्ट) लौटाने वाली एचटीएमएल सामग्री के आधार पर robots.txt फ़ाइल के लिए लॉजिकल रीडायरेक्ट के इस्तेमाल के बारे में नहीं बताया गया है. साथ ही, इससे बचने की सलाह दी जाती है.
4xx (क्लाइंट गड़बड़ियां) Google सभी 4xx गड़बड़ियों को एक ही तरीके से देखता है और मानता है कि कोई मान्य robots.txt फ़ाइल मौजूद नहीं है. यह माना जाता है कि कोई प्रतिबंध नहीं है. इसमें क्रॉल करने की "पूरी अनुमति" है.
5xx (सर्वर की गड़बड़ियां)

सर्वर की गड़बड़ियों को अस्थायी गड़बड़ियों के रूप में देखा जाता है जिनकी वजह से क्रॉल करने के लिए "पूरी मंजूरी नहीं है" की स्थिति आती है. अनुरोध की तब तक कोशिश की जाती है जब तक बिना सर्वर वाली गड़बड़ी का एचटीटीपी नतीजा कोड नहीं मिल जाता है. एक 503 (सेवा उपलब्ध नहीं है) गड़बड़ी की वजह से कई बार कोशिश करनी होगी. कुछ देर तक क्रॉल करने से रोकने के लिए, एक 503 एचटीटीपी नतीजा कोड देने का सुझाव दिया जाता है. स्थायी सर्वर की गड़बड़ी को ठीक करने के बारे में नहीं बताया गया है.

खास Google के लिए : अगर हम यह तय कर पाते हैं कि किसी साइट को गैरमौजूद पेजों के लिए, 404 के बजाय 5xx दिखाने के लिए गलत तरीके से कॉन्फ़िगर किया गया है, तो हम उस साइट की 5xx गड़बड़ी को 404 के रूप में देखेंगे.

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

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

अपेक्षित फ़ाइल फ़ॉर्मेट UTF -8 में एन्कोड किया गया सादा टेक्स्ट है. फ़ाइल में सीआर, सीआर/एलएफ़ या एलएफ़ से अलग किए गए रिकॉर्ड (रेखाएं) होते हैं.

सिर्फ़ मान्य रिकॉर्ड माने जाएंगें; दूसरी सभी सामग्री को नज़रअंदाज़ कर दिया जाएगा. उदाहरण के लिए, अगर नतीजे में मिला दस्तावेज़ कोई एचटीएमएल पेज है, तो सिर्फ़ मान्य टेक्स्ट पंक्तियों को ध्यान में रखा जाएगा, बाकी को चेतावनी या गड़बड़ी के बिना खारिज कर दिया जाएगा.

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

robots.txt फ़ाइल की शुरुआत में एक वैकल्पिक यूनिकोड BOM (बाइट ऑर्डर मार्क) को नज़रअंदाज़ किया जाता है.

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

<field> एलिमेंट पर अंग्रेज़ी के छोटे-बड़े अक्षरों का असर पड़ता है. <value> एलिमेंट पर <field> एलिमेंट के आधार पर अंग्रेज़ी के छोटे-बड़े अक्षरों का असर पड़ सकता है.

साधारण गड़बड़ियों / गलत वर्तनी (उदाहरण के लिए "उपयोगकर्ता-एजेंट" के बजाय "उपयोगकर्ताएजेंट") वाले <field> एलिमेंट को संभालने के बारे में नहीं बताया गया है. ऐसा हो सकता है कि कुछ उपयोगकर्ता-एजेंट इसे सही निर्देश के रूप में देखें.

हर क्रॉलर के लिए सबसे बड़े आकार की फ़ाइल को लागू किया जा सकता है. सामग्री के लिए तय आकार से बड़ी फ़ाइल को अनदेखा किया जा सकता है. Google फ़िलहाल 500 किलोबाइट (केबी) की आकार सीमा लागू करता है.

औपचारिक सिंटैक्स / परिभाषा

आरएफ़सी 822 के मुताबिक इस्तेमाल होने वाली यह बैकस-नौर फ़ॉर्म (बीएनएफ़)-जैसी जानकारी है, सिवाय इसके कि "|" का इस्तेमाल विकल्पों को तय करने के लिए किया जाता है. अक्षरों को "" के साथ दिखाया जाता है, ब्रैकेट "("और")" का इस्तेमाल एलिमेंट को किसी समूह में शामिल करने के लिए किया जाता है. वैकल्पिक एलिमेंट [ब्रैकेट] में शामिल होते हैं और इन एलिमेंट में n या इसको बार-बार बताने के लिए एलिमेंट से पहले <n>* लगाया जा सकता है; n, 0 पर डिफ़ॉल्ट है.

robotstxt = *entries
entries = *( ( <1>*startgroupline
  *(groupmemberline | nongroupline | comment)
  | nongroupline
  | comment) )
startgroupline = [LWS] "user-agent" [LWS] ":" [LWS] agentvalue [comment] EOL
groupmemberline = [LWS] (
  pathmemberfield [LWS] ":" [LWS] pathvalue
  | othermemberfield [LWS] ":" [LWS] textvalue) [comment] EOL
nongroupline = [LWS] (
  urlnongroupfield [LWS] ":" [LWS] urlvalue
  | othernongroupfield [LWS] ":" [LWS] textvalue) [comment] EOL
comment = [LWS] "#" *anychar
agentvalue = textvalue

pathmemberfield = "disallow" | "allow"
othermemberfield = ()
urlnongroupfield = "sitemap"
othernongroupfield = ()

pathvalue = "/" path
urlvalue = absoluteURI
textvalue = *(valuechar | SP)
valuechar = <any UTF-8 character except ("#" CTL)>
anychar = <any UTF-8 character except CTL>
EOL = CR | LF | (CR LF)

"absoluteURI", "सीटीएल", "सीआर", "एलएफ़", "एलडब्ल्यूएस" के सिंटैक्स आरएफ़सी 1945 में बताए गए हैं. "पाथ" का सिंटैक्स आरएफ़सी 1808 में बताया गया है.

रिकॉर्ड का समूह बनाना

रिकॉर्ड को <field> एलिमेंट के प्रकार के आधार पर अलग-अलग श्रेणी में बांटा गया है:

  • समूह की शुरुआत
  • समूह का सदस्य
  • बिना समूह के

सभी समूह सदस्य रिकॉर्ड, किसी समूह की शुरुआत का रिकॉर्ड से लेकर अगले समूह की शुरुआत का रिकॉर्ड के बीच के रिकॉर्ड को समूह का रिकॉर्ड माना जाता है. user-agent सिर्फ़ एक समूह का शुरुआत फ़ील्ड एलिमेंट है कई सारे समूह की शुरुआत पंक्तियां एक दूसरे के बाद सीधे समूह-सदस्य रिकॉर्ड को फ़ॉलो करेंगी, जो आखिरी समूह की शुरुआत पंक्ति के बाद आएंगी. ऐसे किसी भी समूह-सदस्य रिकॉर्ड को नज़रअंदाज़ कर दिया जाएगा जिसके पहले समूह की शुरुआत रिकॉर्ड नहीं होगा. बिना समूह वाले सभी रिकॉर्ड, सभी समूहों से बाहर मान्य होते हैं.

मान्य <field> एलिमेंट जिनके बारे में आगे इस दस्तावेज़ में अलग-अलग बताया जाएगा, वे हैं:

  • user-agent (समूह की शुरुआत)
  • disallow (सिर्फ़ समूह-सदस्य रिकॉर्ड के रूप में मान्य)
  • allow (सिर्फ़ समूह-सदस्य रिकॉर्ड के रूप में मान्य)
  • sitemap (बिना समूह वाला रिकॉर्ड)

दूसरे सभी <field> एलिमेंट को अनदेखा किया जा सकता है.

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

उदाहरण समूह:

user-agent: a
disallow: /c

user-agent: b
disallow: /d

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

तीन अलग-अलग समूह बताए गए हैं, एक "a" के लिए और एक "b" के साथ-साथ "e" और "f" दोनों के लिए भी एक है. हर एक समूह का अपना समूह-सदस्य रिकॉर्ड होता है. सामग्री को बेहतर तरीके से पढ़े जाने लायक बनाने के लिए वाइट-स्पेस (एक खाली रेखा) के वैकल्पिक इस्तेमाल पर ध्यान दें.

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

किसी खास क्रॉलर के लिए समूह-सदस्य रिकॉर्ड का सिर्फ़ एक समूह मान्य होता है. क्रॉलर को समूह के सबसे खास उपयोगकर्ता-एजेंट के साथ मिलकर रिकॉर्ड के सही समूह को तय करना होगा जो अब भी मेल खाता हो. दूसरे सभी रिकॉर्ड समूहों को क्रॉलर नज़रअंदाज़ कर देता है. उपयोगकर्ता-एजेंट पर अंग्रेज़ी के छोटे-बड़े अक्षरों का कोई असर नहीं पड़ता. सभी मेल नहीं खाने वाले टेक्स्ट को नजरअंदाज कर दिया जाता है (उदाहरण के लिए, googlebot/1.2 और googlebot* दोनों googlebot के बराबर हैं). robots.txt फ़ाइल के अंदर समूहों का क्रम प्रासंगिक नहीं है.

उदाहरण

यह मानते हुए कि यह robots.txt फ़ाइल:

user-agent: googlebot-news
(group 1)

user-agent: *
(group 2)

user-agent: googlebot
(group 3)

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

हर क्रॉलर के लिए फ़ॉलो किया गया रिकॉर्ड समूह
Googlebot समाचार फ़ॉलो किया गया रिकॉर्ड समूह, समूह एक है. सिर्फ़ सबसे खास समूह को फ़ॉलो किया जाता है, दूसरे सभी समूहों को अनदेखा किया जाता है.
Googlebot (वेब) फ़ॉलो किया गया रिकॉर्ड समूह, समूह तीन है.
Googlebot इमेज फ़ॉलो किया गया रिकॉर्ड समूह, समूह तीन है. कोई भी खास googlebot-images समूह नहीं है, इसलिए ज़्यादा सामान्य समूह को फ़ॉलो किया जाता है.
Googlebot समाचार (इमेज क्रॉल करते समय) >फ़ॉलो किया गया रिकॉर्ड समूह, समूह एक है. इन इमेज को Googlebot समाचार के लिए और इसके ज़रिए क्रॉल किया गया है, इसलिए सिर्फ़ Googlebot समाचार समूह को फ़ॉलो किया जाता है.
दूसरा-बॉट (वेब) फ़ॉलो किया गया रिकॉर्ड समूह, समूह दो है.
दूसरा-बॉट (समाचार) फ़ॉलो किया गया रिकॉर्ड समूह, समूह दो है. किसी संबंधित क्रॉलर के लिए कोई एंट्री होने पर भी, यह सिर्फ़ तभी मान्य होगा, जब इसका खास तौर पर मिलान होता हो.

Google के क्रॉलर और उपयोगकर्ता-एजेंट स्ट्रिंग भी देखें.

समूह-सदस्य के रिकॉर्ड

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

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

disallow

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

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

disallow: [path]

allow

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

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

allow: [path]

पथ के मानों के आधार पर यूआरएल का मिलान

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

Google, Bing, Yahoo और Ask पर पथ मानों के "वाइल्डकार्ड" के सीमित रूप काम करते हैं. वे हैं:

  • * किसी भी मान्य वर्ण के 0 या उससे ज़्यादा इंस्टेंस बताता है.
  • $ यूआरएल का आखिरी हिस्सा बताता है.
उदाहरण पथ मिलान
/ रूट और किसी भी निचले स्तर के यूआरएल से मेल खाता है
/* / के बराबर. पीछे वाले वाइल्डकार्ड को अनदेखा किया जाता है.
/fish

मिलान:

  • /fish
  • /fish.html
  • /fish/salmon.html
  • /fishheads
  • /fishheads/yummy.html
  • /fish.php?id=anything

मेल नहीं खाता:

  • /Fish.asp
  • /catfish
  • /?id=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/?id=anything
  • /fish/salmon.htm

मेल नहीं खाता:

  • /fish
  • /fish.html
  • /Fish/Salmon.asp
/*.php

मिलान:

  • /filename.php
  • /folder/filename.php
  • /folder/filename.php?parameters
  • /folder/any.php.file.html
  • /filename.php/

मेल नहीं खाता:

  • / (भले ही इसे /index.php से मैप किया जाए)
  • /windows.PHP
/*.php$

मिलान:

  • /filename.php
  • /folder/filename.php

मेल नहीं खाता:

  • /filename.php?parameters
  • /filename.php/
  • /filename.php5
  • /windows.PHP
/fish*.php

मिलान:

  • /fish.php
  • /fishheads/catfish.php?parameters

मेल नहीं खाता: /Fish.PHP

Google पर काम करने वाले बिना समूह सदस्य के रिकॉर्ड

sitemap

Google, Ask, Bing, Yahoo पर काम करता है; sitemaps.org पर बताया गया है.

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

sitemap: [absoluteURL]

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

समूह-सदस्य रिकॉर्ड के लिए प्राथमिकता का क्रम

समूह-सदस्य स्तर पर, खास तौर पर allow और disallow निर्देशों के लिए [path] एंट्री की लंबाई के मुताबिक सबसे खास नियम, कम खास (छोटे) नियम को बाहर कर देगा. वाइल्डकार्ड के साथ नियमों के लिए प्राथमिकता क्रम तय नहीं किया गया है.

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

allow: /p

disallow: /

फ़ैसला: allow

http://example.com/folder/page

allow: /folder

disallow: /folder

फ़ैसला: allow

http://example.com/page.htm

allow: /page

disallow: /*.htm

फ़ैसला: undefined

http://example.com/

allow: /$

disallow: /

फ़ैसला: allow

http://example.com/page.htm

allow: /$

disallow: /

फ़ैसला: disallow