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

खास जानकारी

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

क्या बदलाव हुए

1 जुलाई, 2019 को Google ने एलान किया था कि robots.txt प्रोटोकॉल इंटरनेट मानक बनने की दिशा में काम कर रहा है. ये बदलाव इस दस्तावेज़ में दिखते हैं.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

हर क्रॉलर के लिए सबसे बड़े आकार की फ़ाइल को लागू किया जा सकता है. सामग्री के लिए तय आकार से बड़ी फ़ाइल को अनदेखा किया जाता है. Google फ़िलहाल, 500 किलोबाइट (केआईबी) की आकार सीमा लागू करता है. robots.txt फ़ाइल का आकार कम करने के लिए ऐसे निर्देश इकट्ठा करें जिनसे robots.txt फ़ाइल का आकार बहुत बड़ा हो जाता है. उदाहरण के लिए, बाहर निकाली गई सामग्री को अलग डायरेक्ट्री में रखें.

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

यहां आरएफ़सी 5234 के मुताबिक ऑगमेंटेड बैकस-नौर फ़ॉर्म (एबीएनएफ़) की जानकारी दी गई है.

robotstxt = *(group / emptyline)
group = startgroupline                    ; We start with a user-agent
        *(startgroupline / emptyline)     ; ... and possibly more user-agents
        *(rule / emptyline)               ; followed by rules relevant for UAs

startgroupline = *WS "user-agent" *WS ":" *WS product-token EOL

rule = *WS ("allow" / "disallow") *WS ":" *WS (path-pattern / empty-pattern) EOL

; parser implementors: add additional lines you need (for example, Sitemaps), and
; be lenient when reading lines that don’t conform. Apply Postel’s law.

product-token = identifier / "*"
path-pattern = "/" *(UTF8-char-noctl)    ; valid URI path pattern; see 3.2.2
empty-pattern = *WS

identifier = 1*(%x2d / %x41-5a / %x5f / %x61-7a)
comment = "#" *(UTF8-char-noctl / WS / "#")
emptyline = EOL
EOL = *WS [comment] NL         ; end-of-line may have optional trailing comment
NL = %x0D / %x0A / %x0D.0A
WS = %x20 / %x09

; UTF8 derived from RFC3629, but excluding control characters
UTF8-char-noctl = UTF8-1-noctl / UTF8-2 / UTF8-3 / UTF8-4
UTF8-1-noctl    = %x21 / %x22 / %x24-7F  ; excluding control, space, '#'
UTF8-2          = %xC2-DF UTF8-tail
UTF8-3          = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2( UTF8-tail ) /
                  %xED %x80-9F UTF8-tail / %xEE-EF 2( UTF8-tail )
UTF8-4          = %xF0 %x90-BF 2( UTF8-tail ) / %xF1-F3 3( UTF8-tail ) /
                  %xF4 %x80-8F 2( UTF8-tail )
UTF8-tail       = %x80-BF

रेखाओं और नियमों का ग्रुप

एक या एक से ज़्यादा ऐसी उपयोगकर्ता-एजेंट रेखाएं जो एक या एक से ज़्यादा नियमों के मुताबिक होती हैं. यह ग्रुप उपयोगकर्ता-एजेंट रेखा या फ़ाइल के आखिर में खत्म होता है. शायद आखिरी ग्रुप में कोई नियम न हो, इसका मतलब है कि यह साफ़ तौर पर हर चीज़ की अनुमति देता है.

ग्रुप के उदाहरण:

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" के लिए एक ग्रुप

आखिरी ग्रुप (ग्रुप "h") को छोड़कर, हर ग्रुप में उसकी ग्रुप-सदस्यता लाइन होती है. आखिरी ग्रुप (ग्रुप "h") खाली है. खाली जगह और खाली लाइनों के इस्तेमाल पर ध्यान दें, ताकि सामग्री को बेहतर ढंग से पढ़ा जा सके. हालांकि, ऐसा करना ज़रूरी नहीं है.

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

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

ग्रुप-सदस्य के लिए नियम

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

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

अनुमति नहीं देना

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

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

disallow: [path]

अनुमति देना

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

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

allow: [path]

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

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

Google, Bing, और दूसरे मुख्य सर्च इंजन पर पाथ के मानों के लिए "वाइल्डकार्ड" के सीमित रूप काम करते हैं. इनके उदाहरण हैं:

  • * किसी भी मान्य वर्ण के शून्य या उससे ज़्यादा इंस्टेंस बताता है.
  • $ यूआरएल का आखिरी हिस्सा बताता है.
उदाहरण पाथ मिलान
/ रूट और किसी भी निचले स्तर के यूआरएल से मेल खाता है
/* / के बराबर. पीछे वाले वाइल्डकार्ड को अनदेखा किया जाता है.
/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, Bing, और दूसरे मुख्य सर्च इंजन पर sitemap काम करता है, जैसा कि 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

Robots.txt के मार्कअप की जांच करना

Robots.txt के मार्कअप की जांच करने के लिए, Google दो विकल्प देता है:

  1. Search Console में robots.txt फ़ाइल की जांच करने वाला टूल.
  2. Google की ओपन सोर्स robots.txt लाइब्रेरी, जिसका इस्तेमाल Google Search में भी किया जाता है.