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

संक्षेप

यह दस्तावेज़ बताता है कि Google कैसे 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 फ़ाइलों को लाए जाने पर आम तौर पर तीन अलग-अलग नतीजे होते हैं:

  • पूरी अनुमति: सभी सामग्री को क्रॉल किया जा सकता है.
  • बिल्कुल अनुमति नहीं: किसी भी सामग्री को क्रॉल नहीं किया जा सकता है.
  • शर्तों के साथ अनुमति: 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: [path]

मंज़ूरी देना

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

इस्तेमाल:

allow: [path]

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

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

साइटमैप

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

मंज़ूरी दें: /$

मंज़ूरी न दें: /

फ़ैसला: मंज़ूरी न दें

निम्न के बारे में फ़ीडबैक भेजें...

यह पेज
दस्तावेज़ीकरण फ़ीडबैक
सर्च
सर्च
उत्‍पाद फ़ीडबैक