সারসংক্ষেপ
সর্বজনীনভাবে অ্যাক্সেস করা যায় এমন ওয়েবসাইট, 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 ফাইল ব্যবহার করে ও মেনে চলে। FTP ভিত্তিক robots.txt ফাইল FTP প্রোটোকলের মাধ্যমে ছদ্মবেশী লগ-ইন ব্যবহার করে অ্যাক্সেস করা হয়।
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 সর্বাধিক ৫টি 'হপ' ব্যবহার করতে দেয়) এবং তারপরে বন্ধ করে সেটিকে 404 হিসেবে বিবেচনা করি। robots.txt-এর মাধ্যমে অননুমোদিত ইউআরএলে রিডাইরেক্ট করা সম্পর্কে কিছু উল্লেখ করা নেই এবং আমরা সেটি সাজেস্ট করি না। যে HTML কন্টেন্ট 2xx প্রতিক্রিয়া পাঠায় (ফ্রেম, জাভাস্ক্রিপ্ট অথবা মেটা রিফ্রেশ-ধরনের রিডাইরেক্ট), সেটির উপর নির্ভর করে robots.txt ফাইলের মাধ্যমে যুক্তিসম্মত রিডাইরেক্ট পরিচালনা করা সম্পর্কে কিছু উল্লেখ করা নেই এবং আমরা সেটি সাজেস্ট করি না। |
4xx (ক্লায়েন্ট সংক্রান্ত সমস্যা) | 4xx কোডের সমস্ত সমস্যাকে Google একইভাবে দেখে এবং কোনও উপযুক্ত robots.txt ফাইল নেই বলে ধরে নেয়। এছাড়াও, কোনও বিধিনিষেধ নেই বলে ধরে নেওয়া হয়। এগুলিকে ক্রল করার "সম্পূর্ণ অনুমতি" আছে বলে বিবেচনা করা হয়। |
5xx (সার্ভার সংক্রান্ত সমস্যা) | সার্ভার সংক্রান্ত কোনও সমস্যা সাময়িক বলে ধরে নেওয়া হয় এবং এর ফলে ক্রল করার "কোনও অনুমতি থাকে না"। সার্ভার ছাড়া অন্য কোনও সমস্যার জন্য HTTP ফলাফলের কোড না পাওয়া পর্যন্ত অনুরোধ করা হতে থাকে। 503 (পরিষেবা উপলভ্য নয়) সমস্যার জন্য বেশ ঘন ঘন অনুরোধ করা হয়। সাময়িকভাবে ক্রলিং বন্ধ করার জন্য HTTP ফলাফলের 503 কোড দেখানো ভাল। সার্ভারের স্থায়ী কোনও সমস্যার ক্ষেত্রে কী করতে হবে তা উল্লেখ করা নেই। শুধু Google-এর ক্ষেত্রে প্রযোজ্য: কোনও সাইট ভুল করে কনফিগার করার ফলে অনুপস্থিত পৃষ্ঠার জন্য 404-এর পরিবর্তে 5xx দেখাচ্ছে বলে আমরা স্থির করলে, সেই সাইটের 5xx সমস্যাকে 404 হিসেবেই বিবেচনা করব। |
প্রসেস করা যায়নি এমন অনুরোধ অথবা অসম্পূর্ণ ডেটা | টাইম-আউট, ভুল প্রতিক্রিয়া, কানেকশন রিসেট হওয়া / কানেকশন কেটে যাওয়া বা HTTP চাঙ্কিংয়ের মতো ডিএনএস অথবা নেটওয়ার্কে সমস্যার জন্য robots.txt ফাইল ফেচ করা না গেলে কী করতে হবে তা উল্লেখ করা নেই। |
ক্যাশিং | robots.txt অনুরোধ সাধারণত এক দিন পর্যন্ত ক্যাশেতে থাকে। কিন্তু ক্যাশে করা ভার্সন রিফ্রেশ করা না গেলে (যেমন টাইম-আউট বা 5xx সমস্যার ক্ষেত্রে) এটি আরও বেশি সময়ের জন্য ক্যাশেতে রাখা হতে পারে। ক্যাশে করা প্রতিক্রিয়াটি একাধিক ক্রলার শেয়ার করতে পারে। max-age Cache-Control HTTP হেডারের উপর নির্ভর করে Google ক্যাশের সময়সীমা কমাতে বা বাড়াতে পারে। |
ফাইলের ফর্ম্যাট
UTF-8-এ এনকোড করা প্লেন টেক্সট ফর্ম্যাটের ফাইল ব্যবহার করা উচিত। এই ফাইলে CR, CR/LF অথবা LF দিয়ে বিভিন্ন রেকর্ড (লাইন) আলাদা করা থাকে।
শুধুমাত্র ব্যবহারযোগ্য রেকর্ড ছাড়া বাকি সব কন্টেন্ট উপেক্ষা করা হয়। যেমন, প্রাপ্ত ডকুমেন্ট একটি HTML পৃষ্ঠা হলে শুধু সঠিক টেক্সটের লাইন গ্রাহ্য করা হয়, বাকি সবকিছু কোনও সতর্কতা বা সমস্যার মেসেজ না দেখিয়েই বাদ দিয়ে দেওয়া হয়।
অক্ষর দিয়ে এনকোডিং করা থাকলে এবং UTF-8 এর সাবসেট নয় এমন অক্ষর ব্যবহার করা হলে ফাইলের কন্টেন্ট ভুলভাবে পার্স করা হতে পারে।
robots.txt ফাইলের শুরুতে কোনও ঐচ্ছিক ইউনিকোড BOM (বাইট অর্ডার মার্ক) ব্যবহার করা হলে সেটি উপেক্ষা করা হয়।
প্রতিটি রেকর্ডে একটি করে ফিল্ড, কোলন এবং মান থাকে। স্পেস না দিলেও চলে (তবে
স্পেস দিলে সহজে পড়া যায়)। ফাইলের যেকোনও জায়গায় "#" অক্ষর ব্যবহার করে কমেন্ট যোগ করা যেতে পারে; কোনও কমেন্ট শুরু হওয়ার পর থেকে রেকর্ডের শেষ পর্যন্ত সম্পূর্ণ কন্টেন্টকে কমেন্ট হিসেবে বিবেচনা করে উপেক্ষা করা হয়। <field>:<value><#optional-comment>
হল সাধারণ ফর্ম্যাট। রেকর্ডের শুরুতে এবং শেষে
ফাঁকা জায়গা থাকলে তা উপেক্ষা করা হয়।
<field>
এলিমেন্টের ক্ষেত্রে ছোট ও বড় হাতের অক্ষরের মধ্যে পার্থক্য করা হয় না। <field> এলিমেন্টের উপর নির্ভর করে, <value> এলিমেন্টে
ছোট ও বড় হাতের অক্ষরের মধ্যে পার্থক্য করা হতে পারে।
<field>
এলিমেন্টে সাধারণ সমস্যা অথবা টাইপিংয়ে ভুল হলে (যেমন "ইউজার-এজেন্ট"-এর পরিবর্তে "ইউজারএজেন্ট" লেখা) কী করতে হবে তা উল্লেখ করা নেই। কিছু ইউজার-এজেন্ট সেগুলিকে সঠিক নির্দেশ হিসেবেও ধরে নিতে পারে।
প্রতিটি ক্রলারের জন্য ফাইলের সর্বাধিক সাইজ নির্দিষ্ট করে দেওয়া হতে পারে। কন্টেন্ট সেই সীমা অতিক্রম করে গেলে তা উপেক্ষা করা হতে পারে। Google বর্তমানে সাইজের সীমা হিসেবে ৫০০ কিলোবাইটে (কেবি) নির্দিষ্ট করে রেখেছে।
ফর্মাল সিন্ট্যাক্স / সংজ্ঞা
এটি Backus-Naur Form-এর (BNF) সংজ্ঞার মতো, যাতে RFC 822-এর কনভেনশন ব্যবহার করা হয়। শুধু বিকল্প বোঝাতে এই ক্ষেত্রে "|" ব্যবহার করা হয়। যা আক্ষরিক তা "" দিয়ে বোঝানো হয়, এলিমেন্ট গ্রুপ করতে "(" এবং ")" ব্র্যাকেট ব্যবহার করা হয় এবং ঐচ্ছিক এলিমেন্ট [ব্র্যাকেট]-এর মধ্যে রাখা হয়। পরবর্তী এলিমেন্টের 'n' বা আরও পুনরাবৃত্তি বোঝাতে এলিমেন্টের আগে <n>* লেখা যেতে পারে; 'n'-এর ডিফল্ট মান ০ হয়।
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 News | ১ নম্বর রেকর্ড গ্রুপকে অনুসরণ করে। শুধুমাত্র সবচেয়ে নির্দিষ্ট গ্রুপটিকে অনুসরণ করে, বাকি সবগুলিকে উপেক্ষা করে। |
Googlebot (ওয়েব) | ৩ নম্বর রেকর্ড গ্রুপকে অনুসরণ করে। |
Googlebot Images | ৩ নম্বর রেকর্ড গ্রুপকে অনুসরণ করে। googlebot-images -এর জন্য কোনও নির্দিষ্ট গ্রুপ নেই, তাই সেটি
আরও সাধারণ কোনও গ্রুপকে অনুসরণ করে। |
Googlebot News (ছবি ক্রল করার সময়) | >১ নম্বর রেকর্ড গ্রুপকে অনুসরণ করে। Googlebot News নিজের জন্যই এই ছবিগুলি ক্রল করে, তাই শুধুমাত্র Googlebot News গ্রুপকে অনুসরণ করে। |
Otherbot (ওয়েব) | ২ নম্বর রেকর্ড গ্রুপকে অনুসরণ করে। |
Otherbot (খবর) | ২ নম্বর রেকর্ড গ্রুপকে অনুসরণ করে। কোনও সম্পর্কিত ক্রলারের জন্য এন্ট্রি থাকলেও, সেটি সম্পূর্ণ মিললে তবেই সঠিক বলে ধরে নেওয়া হয়। |
Google-এর ক্রলার এবং ইউজার-এজেন্ট স্ট্রিং নিবন্ধটিও পড়ুন।
গ্রুপ-মেম্বার রেকর্ড
এই বিভাগে কেবলমাত্র সাধারণ এবং শুধু Google-এর ক্ষেত্রে প্রযোজ্য গ্রুপ-মেম্বার রেকর্ডের ধরন নিয়ে আলোচনা করা হয়েছে। এই ধরনের রেকর্ডগুলিকে ক্রলারের জন্য দেওয়া "নির্দেশ"
বলা হয়। এই নির্দেশগুলি directive:
[path]
হিসেবে লেখা থাকে, যেখানে [path]
হল ঐচ্ছিক মান। ডিফল্টভাবে, নির্দিষ্ট ক্রলারের জন্য ক্রলিংয়ের ক্ষেত্রে কোনও বিধিনিষেধ আরোপ করা হয় না। নির্দেশে [path]
উল্লেখ করা না থাকলে তা উপেক্ষা করা হয়।
উল্লেখ করা থাকলে, [path]
মানটিকে যে ওয়েবসাইটের রুটের জন্য robots.txt ফেচ (একই প্রোটোকল, পোর্ট নম্বর, হোস্ট ও ডোমেন নেম ব্যবহার করে) করা হয়েছে সেটির আপেক্ষিক হিসেবে বিবেচনা করতে হয়। রুট বোঝাতে পাথের মানের শুরুতে "/" লিখতে হয়। পাথের ক্ষেত্রে ছোট ও বড় হাতের অক্ষরের মধ্যে পার্থক্য করা হয়। নিচে উল্লিখিত "পাথের মানের উপর নির্ভর করে ইউআরএল মেলানো" বিভাগ থেকে এই বিষয়ে আরও জানতে পারবেন।
অননুমোদন
নির্দিষ্ট ক্রলার কোন পাথ অ্যাক্সেস করবে না তা নির্দেশ করতে disallow
ব্যবহার করা হয়। কোনও পাথ উল্লেখ করা না থাকলে, নির্দেশ উপেক্ষা করা হয়।
ব্যবহার:
disallow: [path]
অনুমোদন
নির্দিষ্ট ক্রলার কোন পাথ অ্যাক্সেস করতে পারে তা নির্দেশ করতে allow
ব্যবহার করা হয়। কোনও পাথ উল্লেখ করা না থাকলে, নির্দেশ উপেক্ষা করা হয়।
ব্যবহার:
allow: [path]
পাথের মানের উপর নির্ভর করে ইউআরএল মেলানো
সাইটের একটি নির্দিষ্ট ইউআরএলে কোনও নিয়ম প্রযোজ্য হবে কিনা তা নির্ধারণ করতে পাথের মান ব্যবহার করা হয়। ওয়াইল্ডকার্ড ছাড়া, সাধারণত পাথের মানের সাহায্যে কোনও ইউআরএলের শুরুর অংশটি (এবং একই পাথ দিয়ে শুরু হয় এমন যেকোনও সঠিক ইউআরএল) মেলানো হয়। পাথের ৭ বিট নয় এমন ASCII অক্ষরগুলিকে RFC 3986 অনুযায়ী লেখা UTF-8 অথবা পার্সেন্ট-এসকেপড UTF-8-এ এনকোড করা অক্ষর হিসেবে অন্তর্ভুক্ত করা যেতে পারে।
Google, Bing, Yahoo এবং Ask-এ পাথের মান হিসেবে সীমিত সংখ্যক "ওয়াইল্ডকার্ড" ব্যবহার করা যায়। এখানে সেগুলি উল্লেখ করা হল:
- যেকোনও সঠিক অক্ষরের ০ অথবা তার চেয়ে বেশি ইনস্ট্যান্স বোঝাতে
*
ব্যবহার করা যায়। - ইউআরএলের শেষ বোঝাতে
$
ব্যবহার করা যায়।
পাথ মেলানোর উদাহরণ | |
---|---|
/ |
রুট ও সেটির অধীনস্থ যেকোনও লেভেলের ইউআরএলের সাথে মেলানো হয় |
/* |
/ -এর সমতুল্য। এর পরে কোনও ওয়াইল্ডকার্ড থাকলে সেটিকে উপেক্ষা করা হয়। |
/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 |
ফলাফল: |