संक्षेप
यह दस्तावेज़ इस बारे में बताता है कि किस तरह 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 यूआरएल के उदाहरण:
| 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/ |
किसी उप डोमेन का robots.txt सिर्फ़ उस उप डोमेन के लिए मान्य होता है. |
| 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/ | IDN उनके पनीकोड वर्शन के बराबर होते हैं. RFC 3492 भी देखें. |
| 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 पर होस्ट किया गया हो) | होस्ट नाम के रूप में आईपी पते के साथ एक robots.txt सिर्फ़ उस आईपी पते के होस्ट नाम के रूप में क्रॉल करने के लिए मान्य होगा. यह उस आईपी पते पर होस्ट की गई सभी वेबसाइटों के लिए अपने आप मान्य नहीं होगा (हालांकि हो सकता है कि robots.txt फ़ाइल शेयर की गई हो, इस स्थिति में यह शेयर किए गए होस्ट नाम में भी उपलब्ध होगा). |
| http://example.com:80/robots.txt | http://example.com:80/ http://example.com/ |
http://example.com:81/ | मानक पोर्ट नंबर (http के लिए 80, https के लिए 443, ftp के लिए 21) उनके डिफ़ॉल्ट होस्ट नामों के बराबर हैं. [portnumbers] भी देखें. |
| http://example.com:8181/robots.txt | http://example.com:8181/ | http://example.com/ | गैर-मानक पोर्ट नंबर पर मौजूद robots.txt फ़ाइलें सिर्फ़ उन पोर्ट नंबर के ज़रिए उपलब्ध सामग्री के लिए मान्य हैं. |
HTTP नतीजा कोड संभालना
Robots.txt फ़ाइलों को लाए जाने पर आम तौर पर तीन अलग-अलग नतीजे होते हैं:
- पूरी अनुमति: सभी सामग्री को क्रॉल किया जा सकता है.
- बिल्कुल अनुमति नहीं: कोई सामग्री क्रॉल नहीं किया जा सकता है.
- शर्तों के साथ अनुमति: Robots.txt में निर्देश कुछ सामग्री को क्रॉल करने की क्षमता तय करते हैं.
- 2xx (सफल)
- सफलता का संकेत देने वाले HTTP नतीजा कोड क्रॉलिंग की "शर्त के साथ अनुमति" के रूप में नतीजे देते हैं.
- 3xx (दूसरे वेबलिंक पर भेजना)
- रीडायरेक्ट का आम तौर पर फ़ॉलो तब तक किया जाएगा जब तक एक मान्य नतीजा नहीं मिल जाता है (या एक लूप पहचाना जाता है). हम सीमित संख्या में रीडायरेक्ट होकर आगे बढ़ना फ़ॉलो करेंगे (HTTP/1.0 के लिए RFC 1945 तक 5 बार तक आगे बढ़ने की अनुमति देता है) और फिर इसे रोकें और 404 के रूप में देखेंगे. अस्वीकार किए गए यूआरएल पर robots.txt रीडायरेक्ट के इस्तेमाल के बारे में कुछ नहीं बताया गया है और इससे बचने की सलाह दी जाती है. 2xx (फ़्रेम, JavaScript या मेटा रीफ़्रेश-प्रकार रीडायरेक्ट) लौटाने वाली HTML सामग्री के आधार पर robots.txt फ़ाइल के लिए तार्किक रीडायरेक्ट के इस्तेमाल के बारे में नहीं बताया गया है और इससे बचने की सलाह दी जाती है.
- 4xx (क्लाइंट गड़बड़ियां)
- Google सभी 4xx गड़बड़ियों को एक ही तरीके से देखता है और मानता है कि कोई मान्य robots.txt फ़ाइल मौजूद नहीं है. यह माना जाता है कि कोई प्रतिबंध नहीं है. इसमें क्रॉल करने की "पूरी अनुमति" है. ध्यान दें: इसमें 401 "अधिकार नहीं" और 403 "वर्जित" HTTP नतीजा कोड शामिल हैं.
- 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 समाचार | (समूह 1) | सिर्फ़ सबसे खास समूह को फ़ॉलो किया जाता है, दूसरे सभी को नज़रअंदाज़ कर दिया जाता है. |
| Googlebot (वेब) | (समूह 3) | |
| Googlebot इमेज | (समूह 3) | कोई खास googlebot-images समूह नहीं है, इसलिए ज़्यादा सामान्य समूह को
फ़ॉलो किया जाता है. |
| Googlebot समाचार (इमेको क्रॉल करते समय) | (समूह 1) | इन इमेज को Googlebot समाचार के लिए और इसके ज़रिए क्रॉल किया गया है, इसलिए सिर्फ़ Googlebot समाचार समूह को फ़ॉलो किया जाता है. |
| दूसरा-बॉट (वेब) | (समूह 2) | |
| दूसरा-बॉट (समाचार) | (समूह 2) | किसी संबंधित क्रॉलर के लिए कोई प्रविष्टि होने पर भी, यह सिर्फ़ तभी मान्य होगा जब यह खास तौर पर मेल खाता हो. |
Google के क्रॉलर और उपयोगकर्ता-एजेंट स्ट्रिंग भी देखें
समूह-सदस्य रिकॉर्ड
इस सेक्शन में सिर्फ़ सामान्य और Google के लिए खास समूह-सदस्य रिकॉर्ड प्रकार शामिल हैं. इन रिकॉर्ड प्रकारों को क्रॉलरों के लिए "निर्देश" भी कहा जाता है. ये निर्देश वहां "निर्देश: [path]" के रूप में बताए गए होते हैं जहां [path] वैकल्पिक होता है. डिफ़ॉल्ट रूप से, तय किए गए क्रॉलरों के लिए क्रॉल करने पर कोई प्रतिबंध नहीं है. [path] के बिना निर्देशों को नजरअंदाज कर दिया जाता है.
[path] मान, अगर बताया गया हो तो, को उस वेबसाइट के रूप से सापेक्ष देखा जाना चाहिए जिसके लिए robots.txt फ़ाइल ली गई थी (उसी प्रोटोकॉल, पोर्ट नंबर, होस्ट और डोमेन नामों का इस्तेमाल करके). रूट तय करने के लिए पथ मान "/" से शुरू होना चाहिए. पथ केस-सेंसिटिव होता है. ज़्यादा जानकारी नीचे "पथ मानों के आधार पर यूआरएल मिलान" सेक्शन में पाई जा सकती है.
अनुमति नहीं है
disallow निर्देश उन पथों के बारे में बताता है जिन्हें तय किए गए क्रॉलर
के ज़रिए एक्सेस नहीं किया जाना चाहिए. जब कोई पथ बताया नहीं गया हो, तो निर्देश को
अनदेखा किया जाता है.
इस्तेमाल:
disallow: [path]
अनुमति है
allow निर्देश उन पथों के बारे में बताता है जिन्हें तय किए गए क्रॉलर
के ज़रिए एक्सेस किया जा सकता है. जब कोई पथ बताया नहीं गया हो, तो निर्देश को
अनदेखा किया जाता है.
इस्तेमाल:
allow: [path]
पथ के मानों के आधार पर यूआरएल का मिलान
पथ मान का इस्तेमाल यह तय करने के लिए आधार के रूप में किया जाता है कि किसी साइट पर एक खास यूआरएल पर नियम लागू होता है या नहीं. वाइल्डकार्ड के अपवाद के साथ, पथ का उपयोग यूआरएल (और उसी पथ से शुरुआत करने वाला कोई मान्य यूआरएल) की शुरुआत से मेल खाता है. पथ में गैर-7-बिट ASCII (एएससीआईआई) वर्णों को UTF-8 अक्षरों के रूप में या प्रति RFC 3986 प्रति प्रतिशत-अपवाद वाले UTF-8 एन्कोड किए गए वर्णों के रूप में शामिल किया जा सकता है.
नोट: "AJAX-क्रॉलिंग" यूआरएल को उनके क्रॉल किए गए वर्शन में बताया जाना चाहिए.
Google, Bing, Yahoo और Ask पर पथ मानों के लिए "वाइल्डकार्ड" के सीमित रूप काम करते हैं. वे हैं:
- * किसी भी मान्य वर्ण के 0 या उससे ज़्यादा इंस्टेंस बताता है
- $ यूआरएल का अंत बताता है
उदाहरण पथ मिलान
| [path] | मिलान | मिलान नहीं होता है | टिप्पणियां |
|---|---|---|---|
| / | कोई भी मान्य यूआरएल | रूट और किसी भी निचले स्तर के यूआरएल से मेल खाता है | |
/* | / के बराबर | / के बराबर | "/" के बराबर -- पीछे के वाइल्डकार्ड को अनदेखा किया जाता है. |
/fish | /fish /fish.html /fish/salmon.html /fishheads /fishheads/yummy.html /fish.php?id=anything |
/Fish.asp /catfish /?id=fish |
केस-सेंसिटिव मिलान पर ध्यान दें. |
/fish* | /fish /fish.html /fish/salmon.html /fishheads /fishheads/yummy.html /fish.php?id=anything |
/Fish.asp /catfish /?id=fish |
"/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 पर काम करने वाले गैर-समूह-सदस्य रिकॉर्ड
साइटमैप
Google, Ask, Bing, Yahoo पर काम करता है; sitemaps.org पर परिभाषित किया गया है.
इस्तेमाल:
sitemap: [absoluteURL]
[absoluteURL] साइटमैप, साइटमैप इंडेक्स फ़ाइल या इसके बराबर के यूआरएल को इंगित करता है.
यूआरएल को robots.txt फ़ाइल वाले होस्ट पर होना ज़रूरी नहीं है.
एक से ज़्यादा sitemap प्रविष्टियां मौजूद हो सकती हैं. गैर-समूह-सदस्य रिकॉर्ड
होने के नाते, ये किसी भी खास उपयोगकर्ता-एजेंट से बंधे नहीं हैं और इसे
सभी क्रॉलर फ़ॉलो कर सकते हैं, बशर्ते इसकी अनुमति नहीं दी गई हो.
समूह-सदस्य रिकॉर्ड के लिए प्राथमिकता क्रम
समूह-सदस्य स्तर पर, खास तौर पर allow और
disallow निर्देशों के लिए, [path] प्रविष्टि की लंबाई के आधार पर
सबसे खास नियम कम खास (छोटा) नियम को बाहर कर देगा.
वाइल्डकार्ड के साथ नियमों के लिए प्राथमिकता क्रम तय नहीं किया गया है.
उदाहरण स्थितियां:
| यूआरएल | अनुमति है: | अनुमति नहीं है: | फ़ैसला | टिप्पणियां |
|---|---|---|---|---|
| http://example.com/page | /p |
/ | अनुमति है | |
| http://example.com/folder/page | /folder/ |
/folder | अनुमति है | |
| http://example.com/page.htm | /page |
/*.htm | तय नहीं है | |
| http://example.com/ | /$ |
/ | अनुमति है | |
| http://example.com/page.htm | /$ |
/ | अनुमति नहीं है |