संक्षेप
यह दस्तावेज़ इस बारे में बताता है कि किस तरह Google, robots.txt फ़ाइल को नियंत्रित करता है, जिससे आप Google के वेबसाइट क्रॉलर के सार्वजनिक रूप से एक्सेस करने योग्य वेबसाइटों को क्रॉल और इंडेक्स करने का तरीका नियंत्रित कर पाते हैं.
ज़रूरतों की भाषा
इस दस्तावेज़ में मुख्य शब्द "करना ही है", "नहीं करना है", "ज़रूरी", "करना चाहिए", "नहीं करना चाहिए", "चाहिए", "नहीं होना चाहिए", "सुझाया गया", "किया जा सकता है" और "वैकल्पिक" का मतलब RFC 2119 में दी गई जानकारी के मुताबिक समझना चाहिए.
बुनियादी परिभाषाएं
| परिभाषाएं | |
|---|---|
| क्रॉलर | क्रॉलर वह सेवा या एजेंट है, जो वेबसाइटों को क्रॉल करता है. आम तौर पर, एक क्रॉलर किसी होस्ट के जाने-पहचाने यूआरएल को अपने आप और बार-बार एक्सेस करता है, जो मानक वेब ब्राउज़र से एक्सेस की जा सकने वाली सामग्री दिखाता है. नए यूआरएल मिलते ही (अलग-अलग तरीकों से, जैसे कि मौजूदा, क्रॉल किए गए पेज पर या साइटमैप फ़ाइलों के लिंक से), उन्हें भी उसी तरह क्रॉल किया जाता है. |
| उपयोगकर्ता-एजेंट | किसी खास क्रॉलर या क्रॉलर के सेट की पहचान करने का ज़रिया. |
| निर्देश | robots.txt फ़ाइल में क्रॉलर या क्रॉलर के समूह के लिए तय किए गए लागू दिशा-निर्देशों की सूची. |
| यूआरएल | यूनिफ़ॉर्म रिसॉर्स लोकेटर जैसा कि RFC 1738 में परिभाषित किया गया है. |
| Google के लिए खास | ये एलीमेंट खास तौर पर Google के ज़रिए robots.txt को लागू करने के लिए होते हैं और हो सकता है कि दूसरे पक्षों के लिए प्रासंगिक न हों. |
लागू होना
इस दस्तावेज़ में बताए गए दिशानिर्देशों के बाद Google पर सभी ऑटोमेटेड क्रॉलर आते हैं. जब कोई एक्सेस किसी उपयोगकर्ता की ओर से यूआरएल एक्सेस करता है (जैसे कि, अनुवाद के लिए, मैन्युअल रूप से सदस्यता ली गई फ़ीड, मैलवेयर विश्लेषण वगैरह), इन दिशानिर्देशों को लागू करने की ज़रूरत नहीं है.
फ़ाइल स्थान और वैधता की सीमा
robots.txt फ़ाइल को होस्ट की शीर्ष-स्तरीय निर्देशिका में होनी चाहिए, जिसे उचित प्रोटोकॉल और पोर्ट नंबर से एक्सेस किया जा सके. robots.txt (और वेबसाइटों के क्रॉलिंग) के लिए आम तौर पर स्वीकार किए गए प्रोटोकॉल "http" और "https" हैं. Http और https पर, robots.txt फ़ाइल को किसी बिना शर्त वाले HTTP GET अनुरोध का इस्तेमाल करके लाया जाता है.
Google के लिए खास: Google फ़ाइल ट्रांसफ़र प्रोटोकॉल (एफ़टीपी) साइटों के लिए robots.txt फ़ाइलों को स्वीकार करता है और उन्हें फ़ॉलो भी करता है. फ़ाइल ट्रांसफ़र प्रोटोकॉल (एफ़टीपी) आधारित robots.txt फ़ाइलों को एक अनजान लॉगिन का इस्तेमाल करके फ़ाइल ट्रांसफ़र प्रोटोकॉल (एफ़टीपी) प्रोटोकॉल के ज़रिए एक्सेस किया जाता है.
robots.txt फ़ाइल में दिए गए निर्देश सिर्फ़ होस्ट, प्रोटोकॉल और पोर्ट नंबर पर लागू होते हैं, जहां फ़ाइल होस्ट की जाती है.
मान्य robots.txt यूआरएल के उदाहरण:
| Robots.txt यूआरएल के उदाहरण | |
|---|---|
http://example.com/robots.txt |
इनके लिए मान्य:
|
http://www.example.com/robots.txt |
इसके लिए मान्य: इनके लिए मान्य नहीं:
|
http://example.com/folder/robots.txt |
मान्य robots.txt फ़ाइल नहीं है. क्रॉलर उपनिर्देशिकाओं में robots.txt फ़ाइलें नहीं खोजेंगे. |
http://www.müller.eu/robots.txt |
इनके लिए मान्य:
इसके लिए मान्य नहीं: |
ftp://example.com/robots.txt |
इसके लिए मान्य: इसके लिए मान्य नहीं: Google के लिए खास: हम फ़ाइल ट्रांसफ़र प्रोटोकॉल (एफ़टीपी) संसाधनों के लिए robots.txt का इस्तेमाल करते हैं. |
http://212.96.82.21/robots.txt |
इसके लिए मान्य: इसके लिए मान्य नहीं: |
http://example.com:80/robots.txt |
इनके लिए मान्य:
इसके लिए मान्य नहीं: |
http://example.com:8181/robots.txt |
इसके लिए मान्य: इसके लिए मान्य नहीं: |
HTTP नतीजे के कोड संभालना
Robots.txt फ़ाइलों को लाए जाने पर आम तौर पर तीन अलग-अलग नतीजे होते हैं:
- पूरी अनुमति: सभी सामग्री को क्रॉल किया जा सकता है.
- बिल्कुल अनुमति नहीं: कोई सामग्री क्रॉल नहीं किया जा सकता है.
- शर्तों के साथ अनुमति: Robots.txt में निर्देश कुछ सामग्री को क्रॉल करने की काबिलियत तय करते हैं.
| HTTP नतीजे के कोड संभालना | |
|---|---|
| 2xx (सफल) | पूरा होने का संकेत देने वाले HTTP नतीजे के कोड क्रॉलिंग की "शर्त के साथ अनुमति" के रूप में नतीजे देते हैं. |
| 3xx (दूसरे वेबलिंक पर भेजना) | रीडायरेक्ट को आम तौर पर तब तक फ़ॉलो किया जाएगा जब तक कि एक मान्य नतीजा नहीं मिल जाता (या एक लूप की पहचान नहीं हो जाती). हम सीमित संख्या में रीडायरेक्ट होकर आगे बढ़ना फ़ॉलो करेंगे (HTTP/1.0 के लिए RFC 1945 5 बार तक आगे बढ़ने देता है) और फिर इसे रोकेंगे और 404 के रूप में देखेंगे. अस्वीकार किए गए यूआरएल पर robots.txt रीडायरेक्ट के इस्तेमाल के बारे में कुछ नहीं बताया गया है और इससे बचने की सलाह दी जाती है. 2xx (फ़्रेम, JavaScript या मेटा रीफ़्रेश-प्रकार रीडायरेक्ट) लौटाने वाली HTML सामग्री के आधार पर robots.txt फ़ाइल के लिए तार्किक रीडायरेक्ट के इस्तेमाल के बारे में नहीं बताया गया है और इससे बचने की सलाह दी जाती है. |
| 4xx (क्लाइंट गड़बड़ियां) | Google सभी 4xx गड़बड़ियों को एक ही तरीके से देखता है और मानता है कि कोई मान्य robots.txt फ़ाइल मौजूद नहीं है. यह माना जाता है कि कोई प्रतिबंध नहीं है. इसमें क्रॉल करने की "पूरी अनुमति" है. |
| 5xx (सर्वर गड़बड़ी) | सर्वर गड़बड़ियों को अस्थायी गड़बड़ियों के रूप में देखा जाता है जिनकी वजह से क्रॉल करने के लिए "पूरी मंजूरी नहीं है" की स्थिति आती है. अनुरोध की तब तक कोशिश की जाती है जब तक गैर-सर्वर-गड़बड़ी HTTP नतीजा कोड नहीं मिल जाता है. एक 503 (सेवा मौजूद नहीं है) गड़बड़ी की वजह से कई बार कोशिश करनी होगी. क्रॉल करने पर कुछ देर के लिए रोक लगाने के लिए, एक 503 HTTP नतीजा कोड देने का सुझाव दिया जाता है. स्थायी सर्वर गड़बड़ी को दूर करने के बारे में नहीं बताया गया है. Google के लिए खास: अगर हम यह तय कर पाते हैं कि किसी साइट को अनुपलब्ध पेजों के लिए 404 के बजाय 5xx लौटाने के लिए गलत तरीके से कॉन्फ़िगर किया गया है, तो हम उस साइट की 5xx गड़बड़ी को 404 के रूप में देखेंगे. |
| असफल अनुरोध या अधूरा डेटा | DNS या नेटवर्क से जुड़ी समस्याओं जैसे कि पहले ही समय खत्म हो जाना, गलत जवाब, रीसेट / रुका हुआ कनेक्शन, छोटे-छोटे हिस्सों में ट्रांसफ़र होने वाली HTTP गड़बड़ियों जैसी वजहों से नहीं लाई जा सकी robots.txt फ़ाइल के बारे में नहीं बताया गया है. |
| कैश मेमोरी में ले जाना | अनुरोध किए गए robots.txt को आम तौर पर एक दिन के लिए कैश मेमोरी में रखा जाता है, लेकिन ऐसी स्थितियों में लंबे समय तक कैश मेमोरी में रखा जा सकता है जब कैश किए गए वर्शन को रीफ़्रेश करना संभव न हो (उदाहरण के लिए, समय खत्म होने या 5xx की गड़बड़ियों की वजह से). कैश किए गए जवाबों को अलग-अलग क्रॉलर के ज़रिए शेयर किया जा सकता है. Google ज़्यादा से ज़्यादा समय के लिए कैश-नियंत्रण HTTP हेडर के आधार पर कैश को संग्रहित करने के समय को बढ़ा या घटा सकता है. |
फ़ाइल फ़ॉर्मैट
अपेक्षित फ़ाइल फ़ॉर्मैट UTF -8 में एन्कोड किया गया सादा टेक्स्ट है. फ़ाइल में CR, CR/LF या LF से अलग किए गए रिकॉर्ड (रेखाएं) होते हैं.
सिर्फ़ मान्य रिकॉर्ड माने जाएंगें; दूसरी सभी सामग्री को नज़रअंदाज़ कर दिया जाएगा. उदाहरण के लिए, अगर नतीजे में मिला दस्तावेज़ एक HTML पेज है, तो सिर्फ़ मान्य टेक्स्ट पंक्तियों को ध्यान में रखा जाएगा, बाकी को चेतावनी या गड़बड़ी के बिना खारिज कर दिया जाएगा.
अगर किसी वर्ण एन्कोडिंग का इस्तेमाल किया जाता है जिसके कारण उन वर्णों का इस्तेमाल किया जाता है जो UTF-8 का सबसेट नहीं हैं, तो इस वजह से फ़ाइल की सामग्री गलत तरीके से पार्स की जा सकती है.
Robots.txt फ़ाइल की शुरुआत में एक वैकल्पिक यूनिकोड BOM (बाइट ऑर्डर मार्क) को नज़रअंदाज़ किया जाता है.
हर एक रिकॉर्ड में एक फ़ील्ड, एक कोलन और एक मान होता है. खाली जगह
वैकल्पिक हैं (लेकिन पठनीयता में सुधार करने का सुझाव दिया जाता है)। टिप्पणियों को "#" वर्ण का इस्तेमाल करके फ़ाइल में किसी भी जगह पर शामिल
किया जा सकता है; एक टिप्पणी की शुरुआत के बाद रिकॉर्ड के आखिर तक
सभी सामग्री को एक टिप्पणी के रूप में माना जाता है और
अनदेखा किया जाता है. सामान्य फ़ॉर्मैट
<field>:<value><#optional-comment> है. रिकॉर्ड की शुरुआत में और आखिर में बची हुई खाली जगह को अनदेखा
कर दिया जाता है.
<field> एलीमेंट केस-सेंसिटिव नहीं होता है. <value>
एलीमेंट <field> एलीमेंट के आधार पर केस-सेंसिटिव हो
सकता है.
साधारण गड़बड़ियों / गलत वर्तनी (उदाहरण के लिए "उपयोगकर्ता-एजेंट" के बजाय
"उपयोगकर्ता-एजेंट") वाले <field> एलीमेंट को संभालने के बारे में नहीं बताया गया है
और हो सकता है कि कुछ उपयोगकर्ता-एजेंट इसे सही निर्देश के रूप में देखें.
प्रति क्रॉलर अधिकतम फ़ाइल आकार लागू किया जा सकता है. अधिकतम फ़ाइल आकार के बाद की सामग्री को अनदेखा किया जा सकता है. Google फ़िलहाल 500 किलोबाइट (केबी) की आकार सीमा लागू करता है.
औपचारिक सिंटैक्स / परिभाषा
RFC 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", "CTL", "CR", "LF", "LWS" के सिंटैक्स RFC 1945 में बताए गए हैं. "पथ" का सिंटैक्स RFC 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: [path]
अनुमति है
allow निर्देश उन पथों के बारे में बताता है जिन्हें तय किए गए क्रॉलर
के ज़रिए एक्सेस किया जा सकता है. जब कोई पथ बताया नहीं गया हो, तो निर्देश को
अनदेखा किया जाता है.
इस्तेमाल:
allow: [path]
पथ के मानों के आधार पर यूआरएल का मिलान
पथ मान का इस्तेमाल यह तय करने के लिए आधार के रूप में किया जाता है कि किसी साइट पर एक खास यूआरएल पर नियम लागू होता है या नहीं. वाइल्डकार्ड के अपवाद के साथ, पथ का उपयोग यूआरएल (और उसी पथ से शुरुआत करने वाला कोई मान्य यूआरएल) की शुरुआत से मेल खाता है. पथ में गैर-7-बिट ASCII (एएससीआईआई) वर्णों को UTF-8 अक्षरों के रूप में या प्रति RFC 3986 प्रति प्रतिशत-अपवाद वाले UTF-8 एन्कोड किए गए वर्णों के रूप में शामिल किया जा सकता है.
Google, Bing, Yahoo और Ask पर पथ मानों के लिए "वाइल्डकार्ड" के सीमित रूप काम करते हैं. वे हैं:
*किसी भी मान्य वर्ण के 0 या उससे ज़्यादा इंस्टेंस बताता है.$यूआरएल का आखिरी हिस्सा बताता है.
| उदाहरण पथ मिलान | |
|---|---|
/ |
रूट और किसी भी निचले स्तर के यूआरएल से मेल खाता है |
/* |
/ के बराबर. पीछे वाले वाइल्डकार्ड को अनदेखा किया जाता है |
/fish |
मिलान होता है:
मिलान नहीं होता है:
|
/fish* |
मिलान होता है:
मिलान नहीं होता है:
|
/fish/ |
पीछे के स्लैश का मतलब है कि यह इस फ़ोल्डर में किसी भी चीज़ से मेल खाता है. मिलान होता है:
मिलान नहीं होता है:
|
/*.php |
मिलान होता है:
मिलान नहीं होता है:
|
/*.php$ |
मिलान होता है:
मिलान नहीं होता है:
|
/fish*.php |
मिलान होता है:
मिलान नहीं होता: |
Google पर काम करने वाले गैर-समूह-सदस्य रिकॉर्ड
साइटमैप
Google, Ask, Bing, Yahoo पर काम करता है; sitemaps.org पर परिभाषित किया गया है.
इस्तेमाल:
sitemap: [absoluteURL]
[absoluteURL] साइटमैप, साइटमैप इंडेक्स फ़ाइल या इसके बराबर के यूआरएल को इंगित करता है.
यूआरएल को robots.txt फ़ाइल वाले होस्ट पर होना ज़रूरी नहीं है.
एक से ज़्यादा sitemap प्रविष्टियां मौजूद हो सकती हैं. गैर-समूह-सदस्य रिकॉर्ड
होने के नाते, ये किसी भी खास उपयोगकर्ता-एजेंट से बंधे नहीं हैं और इसे
सभी क्रॉलर फ़ॉलो कर सकते हैं, बशर्ते इसकी अनुमति नहीं दी गई हो.
समूह-सदस्य रिकॉर्ड के लिए प्राथमिकता क्रम
समूह-सदस्य स्तर पर, खास तौर पर allow और disallow निर्देशों
के लिए [path] एंट्री की लंबाई के आधार पर सबसे खास
नियम कम खास (छोटा) नियम को बाहर कर देगा.
वाइल्डकार्ड के साथ नियमों के लिए प्राथमिकता क्रम तय नहीं किया गया है.
| उदाहरण के लिए स्थितियां | |
|---|---|
http://example.com/page |
अनुमति दें: अनुमति न दें: फ़ैसला: अनुमति दें |
http://example.com/folder/page |
अनुमति दें: अनुमति न दें: फ़ैसला: अनुमति दें |
http://example.com/page.htm |
अनुमति दें: अनुमति न दें: फ़ैसला: तय नहीं है |
http://example.com/ |
अनुमति दें: अनुमति न दें: फ़ैसला: अनुमति दें |
http://example.com/page.htm |
अनुमति दें: अनुमति न दें: फ़ैसला: अनुमति न दें |