সারসংক্ষেপ
Google-এর ওয়েবসাইট ক্রলার কীভাবে সর্বজনীনভাবে উপলভ্য ওয়েবসাইট ক্রল এবং ইন্ডেক্স করে, তা Google-এ robots.txt ফাইলের ব্যবহারের মাধ্যমে নিয়ন্ত্রণ করার বিষয়ে এই ডকুমেন্টে বিশদে বলা আছে।
গুরুত্বপূর্ণ শব্দগুলির অর্থ বুঝে নিন
এই ডকুমেন্টে ব্যবহৃত "করতে হবে", "করা যাবে না", "প্রয়োজনীয়", "হবে", "হবে না", "উচিত", "উচিত নয়", "প্রস্তাবিত", "হতে পারে" এবং "ঐচ্ছিক", এই শব্দগুলির অর্থ RFC 2119-এ দেওয়া আছে।
প্রাথমিক সংজ্ঞা
| সংজ্ঞা | |
|---|---|
| ক্রলার | ক্রলার: যে পরিষেবা বা এজেন্ট কোনও ওয়েবসাইট ক্রল করে, সেটিই হল ক্রলার। কোনও হোস্টে যদি এমন কন্টেন্ট থাকে যা সাধারণ ওয়েব ব্রাউজার অ্যাক্সেস করতে পারে, তাহলে ক্রলার সাধারণত নিজে থেকে সেটির চেনা ইউআরএল বারবার অ্যাক্সেস করতে থাকে। নতুন ইউআরএল খুঁজে পাওয়া গেলে (বিভিন্ন ভাবে পাওয়া যেতে পারে, যেমন আগে ক্রল করা পৃষ্ঠায় দেওয়া লিঙ্কের মাধ্যমে অথবা সাইটম্যাপ ফাইল থেকে) সেগুলিও একইভাবে ক্রল করা হয়। |
| ইউজার-এজেন্ট | একটি বা একাধিক নির্দিষ্ট ক্রলার শনাক্ত করার একটি উপায়। |
| নির্দেশিকা | একটি বা একাধিক নির্দিষ্ট ক্রলারের ক্ষেত্রে প্রযোজ্য নির্দেশাবলীর তালিকা, যা robots.txt ফাইলে উল্লেখ করা থাকে। |
| ইউআরএল | ইউনিফর্ম রিসোর্স লোকেটর, যার সংজ্ঞা RFC 1738-এ দেওয়া আছে। |
| Google-নির্দিষ্ট | এই এলিমেন্টগুলি শুধুমাত্র Google-এ robots.txt ফাইলের ব্যবহারের সাথে সম্পর্কিত এবং অন্য কোনও ক্ষেত্রে প্রাসঙ্গিক নাও হতে পারে। |
প্রযোজ্যতা
এই ডকুমেন্টে উল্লেখ করা নির্দেশাবলী Google-এর সমস্ত অটোমেটিক ক্রলার মেনে চলে। কোনও এজেন্ট যখন ব্যবহারকারীর হয়ে কোনও ইউআরএল অ্যাক্সেস করে (যেমন, অনুবাদ, ম্যালওয়্যার বিশ্লেষণ বা ম্যানুয়ালি সাবস্ক্রাইব করা ফিড দেখার জন্য) তখন এই নির্দেশাবলী প্রযোজ্য নাও হতে পারে।
ফাইলের লোকেশনের এবং ব্যবহারের জন্য উপযুক্ত হিসেবে বিবেচনার শর্ত
robots.txt ফাইলটিকে টপ লেভেল ডিরেক্টরিতে থাকতে হবে এবং যথাযথ প্রোটোকল ও পোর্ট নম্বরের মাধ্যমে সেটি অ্যাক্সেস করা সম্ভব হতে হবে। সাধারণত robots.txt-এর জন্য (এবং ওয়েবসাইট ক্রল করার ক্ষেত্রে) "HTTP" এবং "HTTPS", এই দুটি প্রোটোকল ব্যবহার করা যায়। HTTP এবং HTTPS-এর ক্ষেত্রে robots.txt ফাইলটি HTTP নন-কন্ডিশনাল GET রিকোয়েস্টের মাধ্যমে নিয়ে আসা হয়।
Google-নির্দিষ্ট: এছাড়াও, FTP সাইটের ক্ষেত্রে 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 (করা হয়েছে) | কোনও ইউআরএল "শর্তাধীন অনুমতি" সাপেক্ষে ক্রল করা হয়েছে, তা বোঝানোর জন্য bybohrrit HTTP ফলাফলের কোড। |
| 3xx (রিডাইরেক্ট) | যতক্ষণ না সঠিক ফলাফল খুঁজে পাওয়া যাচ্ছে (অথবা একই ইউআরএলে রিডাইরেক্ট করা হচ্ছে বলে শনাক্ত করা যাচ্ছে), সাধারণত ততক্ষণ রিডাইরেক্ট করে যাওয়া হবে। আমরা সীমিত সংখ্যক 'রিডাইরেক্ট হপ' অনুসরণ করব (RFC 1945 অনুযায়ী, HTTP/1.0-এর জন্য সর্বাধিক ৫টি 'হপ') এবং তার পরে রিডাইরেক্ট বন্ধ করে অনুরোধটিকে 404 হিসেবে বিবেচনা করব। অননুমোদিত ইউআরএলে robots.txt রিডাইরেক্টের বিষয়টি নির্দিষ্ট করা নেই এবং আমরা এই ধরনের রিডাইরেক্ট করার উৎসাহ দিই না। যে HTML কন্টেন্টে 2xx দেখানো হয় (ফ্রেম, জাভাস্ক্রিপ্ট অথবা মেটা রিফ্রেশ-টাইপ রিডাইরেক্ট), সেগুলির উপরে ভিত্তি করা robots.txt ফাইলের ক্ষেত্রে লজিক্যাল রিডাইরেক্ট করার বিষয়টিও নির্দিষ্ট করা নেই এবং আমরা এই ধরনের রিডাইরেক্ট করার উৎসাহ দিই না। |
| 4xx (ক্লায়েন্টের দিকে সমস্যা) | Google 4xx কোডের সমস্ত সমস্যাকে একইভাবে বিবেচনা করে এবং ধরে নেয় যে উপযুক্ত robots.txt ফাইলের অস্তিত্ব নেই। এছাড়া, এও ধরে নেওয়া হয় যে কোনও বিধিনিষেধ নেই। এগুলিকে ক্রল করার ক্ষেত্রে "সম্পূর্ণ অনুমতি" হিসেবে বিবেচনা করা হয়। |
| 5xx (সার্ভারে সমস্যা) | সার্ভারে কোনও সমস্যা হলে সেটিকে সাময়িক সমস্যা হিসেবে ধরা হয় এবং ক্রল করার ক্ষেত্রে "কোনও অনুমতি নেই" হিসেবে বিবেচনা করা হয়। যতক্ষণ না এমন কোনও HTTP ফলাফলের কোড পাওয়া যাচ্ছে যা সার্ভার ছাড়া অন্য কোনও সমস্যার দিকে ইঙ্গিত করে, ততক্ষণ অনুরোধটি বারবার প্রসেস করা হতে থাকে। 503 (পরিষেবা উপলভ্য নয়) সমস্যা হলে বেশ ঘন ঘন সেটি প্রসেস করা হবে। সাময়িকভাবে ক্রলিং বন্ধ করার জন্য HTTP ফলাফলের 503 কোড দেখানো ভাল। সার্ভারের স্থায়ী কোনও সমস্যার ক্ষেত্রে কী করতে হবে তা নির্দিষ্ট করা নেই। Google-নির্দিষ্ট: যদি আমরা শনাক্ত করি যে কোনও সাইটে পৃষ্ঠা বাদ পড়ে যাওয়ার ক্ষেত্রে 404-এর বদলে ভুল করে 5xx ব্যবহার করা হয়েছে, তাহলে আমরা সেই সাইটের 5xx সমস্যাকে 404 হিসেবেই বিবেচনা করব। |
| প্রসেস করা যায়নি এমন অনুরোধ অথবা অসম্পূর্ণ ডেটা | টাইম-আইট, ভুল প্রতিক্রিয়া, কানেকশন রিসেট হওয়া / কানেকশন কেটে যাওয়া বা HTTP চাঙ্কিং সংক্রান্ত সমস্যার মতো ডিনএস অথবা নেটওয়ার্ক সমস্যার কারণে কোনও robots.txt ফাইল নিয়ে আসা না গেলে কী করতে হবে তা নির্দিষ্ট করা নেই। |
| ক্যাশ করা | সাধারণত, robots.txt অনুরোধ এক দিন পর্যন্ত ক্যাশ করে রাখা হয়, তবে ক্যাশ ভার্সন রিফ্রেশ করা না হলে তার বেশিও রেখে দেওয়া হতে পারে (যেমন, টাইম-আউট হয়ে গেলে অথবা 5xx সমস্যা হলে)। ক্যাশ করা প্রতিক্রিয়াটি একাধিক ক্রলার ব্যবহার করতে পারে। Google max-age Cache-Control HTTP হেডারের ভিত্তিতে এই সময়সীমাটি কমাতে অথবা বাড়াতে পারে। |
ফাইল ফর্ম্যাট
সাধারণত UTF-8 দিয়ে এনকোড করা প্লেন টেক্সট ফর্ম্যাটের ফাইল ব্যবহার করা উচিত। এই ফাইলে CR, CR/LF অথবা LF দিয়ে বিভিন্ন রেকর্ড (লাইন) আলাদা করা থাকে।
শুধুমাত্র ব্যবহারযোগ্য রেকর্ড বিবেচনা করা হবে; বাকি সমস্ত কন্টেন্ট উপক্ষা করা হবে। যেমন, রেকর্ড থেকে যদি কোনও HTML পৃষ্ঠায় যাওয়া যায় তাহলে শুধুমাত্র সঠিক টেক্সটের লাইন বিবেচনা করা হবে, বাকিগুলিতে কোনও সতর্কতা অথবা সমস্যা শনাক্ত না করেই সেগুলি বাদ দেওয়া হবে।
যদি অক্ষর এনকোডিং ব্যবহার করার ফলে UTF-8-এর সাবসেটের বাইরের অক্ষর ব্যবহার করা হয় তাহলে ফাইলের কন্টেন্ট ভুলভাবে পার্স করা হতে পারে।
robots.txt ফাইলের শুরুতে কোনও ঐচ্ছিক Unicode 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 নির্দেশিকাটির মাধ্যমে নির্দিষ্ট করা থাকে। কোনও পাথ উল্লেখ করা না থাকলে
নির্দেশিকাটি উপেক্ষা করা হয়।
ব্যবহার:
disallow: [path]
allow
উল্লিখিত ক্রলারগুলি কোন কোন পাথ অ্যাক্সেস করতে পারবে, তা
allow নির্দেশিকাটির মাধ্যমে নির্দিষ্ট করা থাকে। কোনও পাথ উল্লেখ করা না থাকলে
নির্দেশিকাটি উপেক্ষা করা হয়।
ব্যবহার:
allow: [path]
পাথ-এর মানের ভিত্তিতে ইউআরএল মেলানো
কোনও একটি নিয়ম কোনও সাইটের নির্দিষ্ট একটি ইউআরএলে প্রযোজ্য কিনা, তা পাথ-এর মানের ভিত্তিতে নির্ণয় করা হয়। ওয়াইল্ডকার্ড ছাড়া, সাধারণত পাথ-এর মানের সাহায্যে কোনও ইউআরএলের শুরুর অংশটি (এবং একই পাথ দিয়ে শুরু হওয়া যেকোনও ব্যবহারযোগ্য ইউআরএল) মেলানো হয়। যদি কোনও পাথে ৭-বিটের-নয়, এমন অ্যাসকি অক্ষর থাকে তাহলে সেগুলি UTF-8 অক্ষর হিসেবে অন্তর্ভুক্ত করা হতে পারে। অথবা RFC 3986 অনুযায়ী সেগুলিকে শতাংশ চিহ্নের সাহায্যে এস্কেপ করা এবং 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 |
Allow: Disallow: ফলাফল: অনুমতি আছে |
http://example.com/folder/page |
Allow: Disallow: ফলাফল: অনুমতি আছে |
http://example.com/page.htm |
Allow: Disallow: ফলাফল: অনির্দিষ্ট |
http://example.com/ |
Allow: Disallow: ফলাফল: অনুমতি আছে |
http://example.com/page.htm |
Allow: Disallow: ফলাফল: অনুমতি নেই |