ওয়েবসাইটটি নতুন করে তৈরি করা হয়েছে। URL কাঠামো বদলেছে, পুরোনো কয়েকটি ঠিকানায় redirect দেওয়া হয়েছে, নকশাও পাল্টেছে। সবকিছু ঠিকঠাক দেখে নতুন সংস্করণটি চালু করা হলো। কয়েক দিন পর দেখা গেল, Google Search থেকে আসা ভিজিটর দ্রুত কমছে। গুরুত্বপূর্ণ কয়েকটি Page Search থেকে হারানো শুরু করেছে।
প্রথম সন্দেহ গেল redirect-এর দিকে। তারপর canonical, sitemap, server response—একটির পর একটি দেখা হলো। শেষে সমস্যাটা পাওয়া গেল এমন একটি ফাইলে, যার আকার মাত্র কয়েক লাইন।
staging সাইটে search engine যেন ঢুকতে না পারে, সে জন্য আগে লেখা ছিল—
User-agent: *
Disallow: /
ওয়েবসাইট production-এ নেওয়ার সময় সেই একই robots.txt ভুল করে live site-এ চলে এসেছে। ফলে crawler-কে কার্যত পুরো ওয়েবসাইটই crawl না করতে বলা হয়েছে।
এই ভুলটা বাস্তবে যতটা সহজে ঘটে, তার ফল ততটাই বিভ্রান্তিকর। অনেক সময় দল content, backlink, algorithm update কিংবা server নিয়ে ঘণ্টার পর ঘণ্টা খোঁজ করে, অথচ আসল সমস্যা পড়ে থাকে domain-এর একেবারে মূল ঠিকানায় থাকা একটি ছোট ফাইলে।
তবে শুরুতেই একটি বিষয় একদম পরিষ্কার থাকা দরকার।
robots.txt crawling নিয়ন্ত্রণ করে, indexing সরাসরি নিয়ন্ত্রণ করে না।
অর্থাৎ, কোনো URL robots.txt দিয়ে block করলেই সেটি Google-এর Search Result থেকে নিশ্চিতভাবে মুছে যাবে—এমন নয়। আবার কোনো Page Search Result-এ না দেখাতে চাইলে robots.txt সব সময় সঠিক উপায়ও নয়।
এই পার্থক্যটি না বুঝেই সবচেয়ে বেশি robots.txt ভুল হয়।
Robots.txt আসলে কী?
robots.txt হলো একটি সাধারণ text file, যা ওয়েবসাইটের মূল ঠিকানায় রাখা হয়। যেমন—
https://example.com/robots.txt
এই ফাইলের মাধ্যমে search engine crawler-কে জানানো হয়, সাইটের কোন অংশ crawl করা যাবে এবং কোন অংশ crawl না করাই উচিত।
ধরা যাক, আপনার সাইটে /admin/ নামে একটি অংশ আছে, যেটি search engine crawler-এর ঘোরার দরকার নেই। তাহলে robots.txt-এ লেখা হতে পারে—
User-agent: *
Disallow: /admin/
এর অর্থ হলো, এই নিয়ম যেসব crawler-এর জন্য প্রযোজ্য, তাদের /admin/ পথের URL crawl না করতে বলা হচ্ছে।
এখানে একটি ভুল ধারণা এড়িয়ে চলা জরুরি। robots.txt কোনো নিরাপত্তা ব্যবস্থা নয়। কোনো গোপন Page-এর URL robots.txt-এ লিখে দিলেই সেটি নিরাপদ হয়ে যায় না। বরং robots.txt নিজেই সাধারণত সবার জন্য খোলা থাকে।
তাই password, ব্যক্তিগত নথি, গ্রাহকের তথ্য বা সংবেদনশীল কোনো অংশ লুকাতে robots.txt ব্যবহার করা উচিত নয়। সে ক্ষেত্রে login, authentication বা অন্য উপযুক্ত নিরাপত্তাব্যবস্থা দরকার।
Robots.txt কোথায় রাখতে হবে?
সঠিক ঠিকানা:
https://example.com/robots.txt
এই ঠিকানায় রাখলে কাজ করবে না:
https://example.com/files/robots.txt
অর্থাৎ, robots.txt অবশ্যই domain বা সংশ্লিষ্ট host-এর মূল ঠিকানায় থাকতে হবে।
অনেক সময় file তৈরি করা হয়েছে, browser-এ খুলছেও, কিন্তু সেটি subfolder-এর ভেতরে। তখন সাইটের মালিক ভাবছেন robots.txt কাজ করছে, অথচ crawler সেটিকে কার্যকর robots.txt হিসেবে ধরছেই না।
Robots.txt-এর সাধারণ Directive
robots.txt-এর কয়েকটি নির্দেশ নিয়মিত ব্যবহার করা হয়। এগুলো দেখতে সহজ হলেও ভুল জায়গায় একটি / বসালেও অনেক URL block হয়ে যেতে পারে।
| Directive | কাজ | উদাহরণ |
| User-agent | কোন crawler-এর জন্য নিয়ম প্রযোজ্য তা জানায় | User-agent: Googlebot |
| Disallow | নির্দিষ্ট URL বা path crawl না করতে বলে | Disallow: /private/ |
| Allow | block করা অংশের মধ্যে নির্দিষ্ট URL crawl করার অনুমতি দেয় | Allow: /private/public-page/ |
| Sitemap | XML Sitemap-এর ঠিকানা জানায় | Sitemap: https://example.com/sitemap.xml |
| Crawl-delay | কিছু crawler-এর ক্ষেত্রে দুই request-এর মধ্যে বিরতি নির্ধারণে ব্যবহৃত হয় | Crawl-delay: 10 |
Crawl-delay নিয়ে একটু সতর্ক থাকা ভালো। কিছু crawler এই নির্দেশ মানে, আবার সব বড় search engine একইভাবে এটি অনুসরণ করে না। বর্তমানে Google-এর robots.txt সমর্থিত নির্দেশের মধ্যে এটি নেই। তাই crawl-এর গতি নিয়ন্ত্রণের একমাত্র বা সর্বজনীন উপায় হিসেবে এটি ধরা উচিত নয়।
Robots.txt দিয়ে block করলে কি Page Google থেকে পুরোপুরি সরে যায়?
না।
robots.txt নিয়ে সবচেয়ে গুরুত্বপূর্ণ এবং সবচেয়ে বেশি ভুল বোঝা বিষয় এটি।
কোনো URL-এর জন্য লেখা হলো—
Disallow: /old-page/
এর মানে crawler-কে ওই Page-এর content crawl করতে বাধা দেওয়া হচ্ছে।
কিন্তু Search Engine অন্য কোনো Page, sitemap, external link বা অন্য উৎস থেকে ওই URL-এর অস্তিত্ব জানতে পারে। সে ক্ষেত্রে crawler content দেখতে না পারলেও URL-টি Search Result-এ দেখা যেতে পারে।
কখনো title বা description স্বাভাবিকভাবে না-ও দেখা যেতে পারে। কারণ search engine Page-এর ভেতরের content পড়তেই পারেনি।
তাই খুব সরলভাবে বললে—
robots.txt বলে: “এই URL crawl কোরো না।”
noindex বলে: “এই Page Search Result-এ রেখো না।”
এ দুটি এক জিনিস নয়।
Robots.txt দিয়ে block করা Page কি index হতে পারে?
হতে পারে।
ধরা যাক, আপনার Page-টির URL হলো—
https://example.com/private-offer/
robots.txt-এ লেখা আছে—
User-agent: *
Disallow: /private-offer/
এখন অন্য একটি ওয়েবসাইট যদি এই URL-এ link দেয়, search engine URL-টি আবিষ্কার করতে পারে। কিন্তু robots.txt-এর কারণে Page-এর content crawl করতে পারবে না।
তাই এমন পরিস্থিতি তৈরি হতে পারে যেখানে URL Search Result-এ আছে, কিন্তু search engine Page-এর title, description বা content সম্পর্কে খুব কম তথ্য জানে।
এই কারণেই robots.txt দিয়ে Page “remove” করার চেষ্টা প্রায়ই ঠিক ফল দেয় না।
Noindex ব্যবহার করতে গিয়ে যে বিরোধ তৈরি হয়
এটি বাস্তবে খুব পরিচিত ভুল।
ধরা যাক, একটি পুরোনো প্রচারণার Page আপনি আর Google-এ দেখাতে চান না। HTML-এর মধ্যে লিখলেন—
<meta name=”robots” content=”noindex”>
তারপর বাড়তি নিরাপত্তার কথা ভেবে robots.txt-এও লিখলেন—
User-agent: *
Disallow: /old-campaign/
দেখতে মনে হতে পারে, একই Page-এ দুটো বাধা দেওয়া হয়েছে, তাই সেটি নিশ্চয়ই Search থেকে দ্রুত সরে যাবে।
কিন্তু সমস্যা হলো, crawler যদি robots.txt-এর কারণে Page-টিতে ঢুকতেই না পারে, তাহলে HTML-এর মধ্যে থাকা noindex পড়বে কীভাবে?
পড়তে পারবে না।
অর্থাৎ noindex দেখতে হলে crawler-কে Page crawl করার সুযোগ দিতে হবে।
এখানেই robots.txt এবং noindex-এর ব্যবহারের মূল পার্থক্য।
কোনো Page live থাকবে, মানুষ খুলতে পারবে, কিন্তু Search Result-এ দেখাতে চান না—এ ক্ষেত্রে সাধারণত Page crawlable রেখে noindex ব্যবহার করাই সঠিক পদ্ধতি।
Robots.txt Block বনাম Noindex
| পদ্ধতি | এটি আসলে কী করে | Search Result-এ প্রভাব | কখন ব্যবহার করবেন |
| robots.txt Disallow | crawler-কে নির্দিষ্ট URL বা অংশ crawl করতে বাধা দেয় | URL অন্য জায়গা থেকে পাওয়া গেলে Search Result-এ দেখা যেতে পারে | অপ্রয়োজনীয় crawling কমাতে বা নির্দিষ্ট অংশ crawler থেকে দূরে রাখতে |
| noindex | crawler-কে Page index না করতে নির্দেশ দেয় | নির্দেশ দেখা হলে Page Search Result থেকে বাদ যেতে পারে | Page চালু থাকবে, কিন্তু Search-এ দেখাতে চান না |
| robots.txt + noindex | robots.txt crawler-কে আগে আটকে দিতে পারে | crawler noindex দেখতে না পারলে Page Search-এ থেকে যেতে পারে | সাধারণত এই মিশ্র ব্যবহার এড়িয়ে চলাই ভালো |
HTML Page ছাড়াও PDF-এর মতো ফাইলে Search থেকে বাদ দেওয়ার নির্দেশ দিতে হলে HTTP header-এর X-Robots-Tag ব্যবহার করা যায়।
কোন robots.txt ভুলে গুরুত্বপূর্ণ Page Search থেকে হারাতে পারে?
robots.txt নিজে কোনো ranking factor নয়। কিন্তু গুরুত্বপূর্ণ Page crawl করা বন্ধ হয়ে গেলে Search Engine সেই Page-এর নতুন content, পরিবর্তন, internal link বা অন্যান্য প্রয়োজনীয় তথ্য নিয়মিত সংগ্রহ করতে পারে না।
দীর্ঘ সময় এমন থাকলে Search visibility ক্ষতিগ্রস্ত হতে পারে।
Production সাইটে ভুল করে Disallow: /
সবচেয়ে বড় বিপর্যয়গুলোর একটি হলো—
User-agent: *
Disallow: /
staging সাইটে এই নিয়ম থাকা স্বাভাবিক হতে পারে। কারণ development চলার সময় অনেকেই চান না test site search engine crawl করুক।
সমস্যা শুরু হয় যখন staging-এর robots.txt production-এ চলে আসে।
এই একটি নিয়ম পুরো সাইট crawl বন্ধ করে দিতে পারে।
ওয়েবসাইট মাইগ্রেশন, নতুন design চালু করা বা server পরিবর্তনের পর তাই শুধু redirect আর canonical দেখলেই হবে না। live robots.txt পরীক্ষা করাও জরুরি।
একটি folder block করতে গিয়ে পুরো section বন্ধ করা
ধরা যাক, আপনি কয়েকটি পুরোনো test file crawl বন্ধ করতে চেয়েছিলেন। ভুল করে লিখলেন—
Disallow: /blog/
অথচ আপনার সব গুরুত্বপূর্ণ article-ই /blog/-এর নিচে।
ফলে শুধু একটি test folder নয়, পুরো blog-ই crawler-এর জন্য বন্ধ হয়ে গেল।
এ ধরনের ভুল বড় সাইটে আরও বিপজ্জনক। বিশেষ করে URL structure যদি হয়—
/blog/news/
/blog/guides/
/blog/reviews/
/blog/category/seo/
তাহলে একটি broad Disallow পুরো content section-এ প্রভাব ফেলতে পারে।
Wildcard বেশি বিস্তৃতভাবে ব্যবহার করা
robots.txt-এ * এবং $ ব্যবহার করে URL-এর ধরন মিলিয়ে নিয়ম লেখা যায়। কিন্তু pattern ঠিকমতো না বুঝলে উদ্দেশ্যের চেয়ে অনেক বেশি URL block হতে পারে।
ধরা যাক, নির্দিষ্ট query parameter block করতে গিয়ে এমন নিয়ম দেওয়া হলো, যা একই ধরনের অন্য গুরুত্বপূর্ণ URL-ও মেলাচ্ছে।
এ ক্ষেত্রে robots.txt দেখেই বোঝা সব সময় সহজ নয়।
নিয়ম চালু করার আগে কয়েকটি আসল URL দিয়ে পরীক্ষা করা ভালো—
কোনটি block হওয়া উচিত, কোনটি নয়।
CSS ও JavaScript block করা
এক সময় অনেকে robots.txt দিয়ে CSS ও JavaScript folder block করতেন। এখন বেশির ভাগ আধুনিক ওয়েবসাইটের ক্ষেত্রে এটি ভালো ধারণা নয়।
Search Engine শুধু HTML text দেখে Page বিচার করে না। অনেক ক্ষেত্রে Page কীভাবে তৈরি হচ্ছে, mobile screen-এ কেমন দেখাচ্ছে, JavaScript-এর মাধ্যমে content পরে আসছে কি না—এসবও বুঝতে হয়।
যদি গুরুত্বপূর্ণ CSS বা JavaScript file robots.txt দিয়ে আটকে দেওয়া হয়, crawler Page ঠিকভাবে তৈরি করে দেখতে না-ও পারে।
উদাহরণ—
Disallow: /assets/
এই /assets/ folder-এর মধ্যে যদি প্রধান JavaScript, CSS এবং layout-এর প্রয়োজনীয় file থাকে, তাহলে পুরো folder block করা ঝুঁকিপূর্ণ।
robots.txt দিয়ে resource block করার আগে তাই দেখতে হবে, Page দেখানো বা content বোঝার জন্য সেগুলো প্রয়োজনীয় কি না।
ইতিমধ্যে index হওয়া Page robots.txt দিয়ে সরানোর চেষ্টা
ধরা যাক, একটি Page Google-এ দেখা যাচ্ছে। আপনি চান এটি আর Search Result-এ না থাকুক।
robots.txt-এ লিখলেন—
Disallow: /outdated-page/
এতে crawler Page crawl বন্ধ করতে পারে, কিন্তু URL index থেকে নিশ্চিতভাবে সরবে না।
বরং উল্টো সমস্যা হতে পারে। URL Search Result-এ থেকে গেল, কিন্তু crawler content পড়তে পারছে না।
এই কারণেই robots.txt-কে Search থেকে Page মুছে ফেলার উপায় হিসেবে ব্যবহার করা ঠিক নয়।
Page-টির অবস্থা অনুযায়ী noindex, 404, 410, redirect, authentication বা Search Engine-এর removal সুবিধার মধ্যে উপযুক্ত পদ্ধতি বেছে নিতে হবে।
URL-এর বড় ও ছোট হাতের অক্ষর ভুল করা
robots.txt-এর path case-sensitive।
উদাহরণ—
Disallow: /Shop/
এটি সব সময় নিচের URL-এর জন্য একইভাবে প্রযোজ্য হবে না—
https://example.com/shop/product-a/
কারণ /Shop/ আর /shop/ এক নয়।
এই ভুল বিশেষ করে তখন হয়, যখন developer URL-এর case বদলেছেন কিন্তু robots.txt পুরোনো অবস্থাতেই আছে।
robots.txt file server error দিচ্ছে
robots.txt ঠিক লেখা আছে, কিন্তু server যদি file-টি ঠিকমতো দিতে না পারে, তবুও crawling সমস্যা হতে পারে।
ধরা যাক—
https://example.com/robots.txt
খুলতে গেলে 5xx server error পাওয়া যাচ্ছে।
Search Engine এ অবস্থায় সতর্ক হতে পারে। কারণ crawler বুঝতে পারছে না, কোন URL crawl করার অনুমতি আছে আর কোনটি নেই।
Google-এর ক্ষেত্রে সাময়িক server error হলে কিছু সময় crawling কমে যেতে বা থেমে যেতে পারে।
অন্যদিকে robots.txt না থাকা এবং server error হওয়া এক বিষয় নয়।
robots.txt URL-এ 404 পাওয়া মানে সাধারণত Google ধরে নেয়, crawl-এর জন্য আলাদা robots.txt বাধা নেই।
কিন্তু 5xx মানে file পাওয়া যাচ্ছে না server সমস্যার কারণে। এই অবস্থাকে অনেক বেশি গুরুত্ব দিয়ে দেখা দরকার।
robots.txt subfolder-এ রাখা
এটিও অদ্ভুতভাবে পরিচিত ভুল।
file রাখা হয়েছে—
https://example.com/config/robots.txt
তারপর ধরে নেওয়া হয়েছে crawler এটি মানবে।
বাস্তবে robots.txt সংশ্লিষ্ট site-এর মূল ঠিকানায় থাকতে হবে।
সঠিক অবস্থান—
https://example.com/robots.txt
সাধারণ ভুল যেগুলোর কারণে Page Search থেকে হারাতে পারে
| ভুল | এর প্রভাব | সমাধান |
| production-এ Disallow: / | পুরো সাইট crawl বন্ধ হয়ে যেতে পারে | live robots.txt দেখে blanket block সরান |
| গুরুত্বপূর্ণ folder ভুল করে block | পুরো category বা content section crawl বন্ধ হতে পারে | কোন কোন URL প্রভাবিত হচ্ছে পরীক্ষা করে নিয়ম সীমিত করুন |
| অতিরিক্ত বিস্তৃত wildcard | প্রয়োজনের বাইরের URL-ও block হয় | আসল URL দিয়ে pattern পরীক্ষা করুন |
| গুরুত্বপূর্ণ CSS/JS block | Search Engine Page ঠিকমতো দেখতে বা বুঝতে সমস্যায় পড়তে পারে | প্রয়োজনীয় file crawlable রাখুন |
| index হওয়া Page robots.txt দিয়ে সরানোর চেষ্টা | URL Search Result-এ থেকে যেতে পারে | Search থেকে বাদ দিতে উপযুক্ত noindex বা অন্য পদ্ধতি নিন |
| noindex Page আবার robots.txt দিয়ে block | crawler noindex দেখতে পারে না | Page crawlable রেখে noindex ব্যবহার করুন |
| path-এর case ভুল | নিয়ম সঠিক URL-এ কাজ নাও করতে পারে | live URL-এর বড়-ছোট হাতের অক্ষর মিলিয়ে দেখুন |
| robots.txt-এ server error | crawler সাময়িকভাবে crawl কমাতে পারে | HTTP response ও server সমস্যা ঠিক করুন |
| file root-এ না রাখা | robots.txt কার্যকর হবে না | domain-এর মূল ঠিকানায় file রাখুন |
Robots.txt ভুল হয়েছে কি না কীভাবে বুঝবেন?
Search থেকে traffic কমেছে বলেই robots.txt দায়ী—এমন সিদ্ধান্ত নেওয়া ঠিক নয়।
সমস্যা হতে পারে redirect, canonical, server response, noindex, content পরিবর্তন, internal linking বা অন্য টেকনিক্যাল কারণে।
তবে ওয়েবসাইট মাইগ্রেশন বা বড় পরিবর্তনের পর হঠাৎ গুরুত্বপূর্ণ Page crawl বন্ধ হলে robots.txt দ্রুত পরীক্ষা করা উচিত।
প্রথমে live robots.txt খুলুন
browser-এ লিখুন—
https://example.com/robots.txt
তারপর দেখুন, production-এর জন্য প্রত্যাশিত নিয়মই আছে কি না।
বিশেষভাবে খুঁজুন—
Disallow: /
এর পাশাপাশি ভুল folder, পুরোনো staging path, অতিরিক্ত broad rule এবং CSS/JS block করা হয়েছে কি না দেখুন।
গুরুত্বপূর্ণ কয়েকটি URL হাতে ধরে পরীক্ষা করুন
ধরা যাক, আপনার একটি গুরুত্বপূর্ণ article—
https://example.com/blog/seo-guide/
robots.txt দেখে বোঝার চেষ্টা করুন, কোন নিয়ম এই URL-এর সঙ্গে মিলছে।
শুধু একটি URL নয়। একই section-এর কয়েকটি URL পরীক্ষা করুন।
কারণ অনেক সময় সমস্যা একটি Page-এ নয়, পুরো path-এ থাকে।
Search Console-এ URL পরীক্ষা করুন
Search Console-এর URL পরীক্ষা করার সুবিধা ব্যবহার করে গুরুত্বপূর্ণ Page-এর crawl ও index অবস্থা দেখা যায়।
সেখানে robots.txt-এর কারণে Page block হয়েছে কি না, Google Page crawl করতে পেরেছে কি না এবং Page index হওয়ার পথে অন্য কোনো বাধা আছে কি না—এসব সম্পর্কে ধারণা পাওয়া যায়।
Search Console-এর interface সময়ের সঙ্গে বদলাতে পারে। তাই নির্দিষ্ট button বা menu মুখস্থ রাখার চেয়ে কোন তথ্য খুঁজছেন সেটি জানা বেশি গুরুত্বপূর্ণ।
আপনার লক্ষ্য হওয়া উচিত—
Page crawl হয়েছে কি না,
index হওয়ার অনুমতি আছে কি না,
robots.txt বাধা দিচ্ছে কি না।
Page indexing report-এ একই ধরনের সমস্যা খুঁজুন
একটি URL block হওয়া আর একই কারণে পাঁচ হাজার URL block হওয়া এক বিষয় নয়।
Page indexing report-এ যদি দেখা যায়, একই ধরনের robots.txt সমস্যায় একটি বড় section প্রভাবিত, তাহলে path-level rule পরীক্ষা করুন।
ধরা যাক, শুধু /blog/-এর URLগুলোতেই সমস্যা।
তাহলে পুরো site ঘাঁটার আগে robots.txt-এ /blog/ সম্পর্কিত rule আছে কি না দেখাই বুদ্ধিমানের কাজ।
robots.txt নিজে server থেকে পাওয়া যাচ্ছে কি না দেখুন
file-এর ভেতরের লেখা ঠিক থাকলেই সব ঠিক—এ ধারণাও ভুল।
robots.txt URL browser বা HTTP testing tool দিয়ে খুলে দেখুন।
আপনি সাধারণত দেখতে চান—
- file পাওয়া যাচ্ছে কি না;
- সঠিক content আসছে কি না;
- server error হচ্ছে কি না;
- অপ্রত্যাশিত redirect হচ্ছে কি না।
Robots.txt সমস্যা শনাক্ত ও ঠিক করার উপায়
| ধাপ/টুল | কী যাচাই করে |
| live /robots.txt খোলা | production-এ কোন নিয়ম বাস্তবে চালু আছে |
| নির্দিষ্ট URL পরীক্ষা | URL Allow নাকি Disallow হচ্ছে |
| Search Console URL পরীক্ষা | Google URL crawl ও index করতে পারছে কি না |
| Page indexing report | একই সমস্যা অনেক URL-এ ঘটছে কি না |
| robots.txt পরীক্ষার সুবিধা | syntax বা matching সমস্যা আছে কি না |
| HTTP response পরীক্ষা | robots.txt 200, 404 নাকি 5xx দিচ্ছে |
| Page rendering পরীক্ষা | প্রয়োজনীয় CSS/JS crawl করা যাচ্ছে কি না |
| server log দেখা | crawler বাস্তবে কোন URL চাইছে বা পাচ্ছে |
Robots.txt পরিবর্তনের আগে যেসব অভ্যাস রাখবেন
robots.txt কয়েক লাইনের file হলেও এটিকে ছোটখাটো configuration file ভেবে অবহেলা করা ঠিক নয়।
কারণ একটি ভুল নিয়ম হাজার হাজার URL-এর crawling বদলে দিতে পারে।
staging এবং production আলাদা রাখুন
staging সাইটে—
User-agent: *
Disallow: /
থাকা অস্বাভাবিক নয়।
কিন্তু production-এ এটি যেন না যায়, সে জন্য প্রকাশের প্রক্রিয়ায় স্পষ্ট ব্যবস্থা থাকা দরকার।
শুধু “deploy করার সময় মনে রাখব”—এভাবে চললে একদিন ভুল হওয়ার সম্ভাবনা থেকেই যায়।
আর staging সত্যিই গোপন রাখতে চাইলে robots.txt-এর ওপর ভরসা করবেন না। password বা authentication ব্যবহার করুন।
আগে ঠিক করুন: crawl বন্ধ করবেন, নাকি Search থেকে সরাবেন?
robots.txt edit করার আগে এই প্রশ্নের উত্তর দিন।
আপনার উদ্দেশ্য যদি হয়—
“Crawler এই URL বারবার crawl না করুক”
তাহলে robots.txt কাজে লাগতে পারে।
কিন্তু উদ্দেশ্য যদি হয়—
“Page live থাকবে, কিন্তু Search Result-এ দেখা যাবে না”
তাহলে noindex বেশি উপযুক্ত।
আর যদি উদ্দেশ্য হয়—
“এই Page কেউ অনুমতি ছাড়া খুলতেই পারবে না”
তাহলে robots.txt বা noindex কোনোটিই নিরাপত্তাব্যবস্থা নয়। সেখানে authentication দরকার।
এই তিনটি উদ্দেশ্য গুলিয়ে ফেললেই সমস্যা শুরু হয়।
নতুন নিয়ম চালু করার আগে আসল URL দিয়ে পরীক্ষা করুন
ধরা যাক, আপনি লিখছেন—
Disallow: /blog/
তখন অন্তত কয়েকটি URL দেখে নিন—
/blog/
/blog/article-one/
/blog/category/seo/
/blogger-profile/
শেষের /blogger-profile/ নিয়মের সঙ্গে মিলছে কি না, সেটিও গুরুত্বপূর্ণ হতে পারে।
বিশেষ করে wildcard থাকলে শুধু অনুমানের ওপর ভরসা করা উচিত নয়।
Robots.txt change-এও review রাখুন
এক লাইন পরিবর্তন হলেও অন্য একজন developer বা SEO দায়িত্বপ্রাপ্ত ব্যক্তি দিয়ে দেখে নেওয়া ভালো।
পরিবর্তনের সঙ্গে খুব ছোট করে লিখে রাখুন—
কেন নিয়মটি দেওয়া হচ্ছে,
কোন URL block হবে,
কোন URL crawlable থাকতে হবে।
তাতে কয়েক মাস পর robots.txt খুলে শুধু নিয়ম নয়, তার কারণও বোঝা যায়।
Website migration-এর তালিকায় robots.txt রাখুন
ওয়েবসাইট মাইগ্রেশনের সময় সবাই redirect, canonical, sitemap, analytics আর Search Console দেখে।
robots.txt-ও একই গুরুত্বে পরীক্ষা করা উচিত।
সাইট চালুর পর অন্তত এসব URL পরীক্ষা করুন—
- homepage;
- প্রধান category;
- কয়েকটি গুরুত্বপূর্ণ article বা product Page;
- প্রয়োজনীয় CSS;
- প্রয়োজনীয় JavaScript;
- Sitemap URL।
এখানে কয়েক মিনিটের পরীক্ষা পরে কয়েক দিনের SEO সমস্যা বাঁচাতে পারে।
Robots.txt ভুল ঠিক করলে কি Page সঙ্গে সঙ্গে Search-এ ফিরে আসে?
সব সময় নয়।
ধরা যাক, একটি গুরুত্বপূর্ণ Page কয়েক দিন বা কয়েক সপ্তাহ robots.txt দিয়ে block ছিল। আপনি নিয়ম ঠিক করে দিলেন।
এখন crawler আবার Page crawl করতে পারবে। তারপর Search Engine-কে Page নতুন করে crawl করতে হবে, content বুঝতে হবে, index-এর অবস্থা হালনাগাদ করতে হবে।
এই কাজ সব সময় সঙ্গে সঙ্গে হয় না।
Search Console দিয়ে গুরুত্বপূর্ণ URL পরীক্ষা করা যায়। প্রয়োজন হলে পুনরায় crawl বা indexing-এর অনুরোধও জানানো যেতে পারে। তবে অনুরোধ করলেই নির্দিষ্ট সময়ের মধ্যে Page অবশ্যই Search-এ ফিরে আসবে—এমন নিশ্চয়তা নেই।
আরেকটি বিষয়ও মনে রাখতে হবে।
robots.txt সমস্যা ঠিক হয়েছে মানেই সব SEO সমস্যা শেষ নয়।
Page-এ এখনও যদি—
- noindex থাকে,
- ভুল canonical থাকে,
- 404 বা 5xx response আসে,
- redirect ভুল থাকে,
- internal link না থাকে,
তাহলে crawler ঢুকতে পারলেও Search visibility স্বাভাবিক নাও হতে পারে।
Robots.txt-এর একটি লাইন বদলানোর আগে এই প্রশ্নটি করুন
শুরুর সেই ওয়েবসাইট মাইগ্রেশনের ঘটনায় সমস্যাটা শুধু Disallow: / ছিল না।
আসল সমস্যা ছিল, production-এ সাইট চালু করার পর কেউ গিয়ে live robots.txt খুলে দেখেনি।
একটি ছোট অভ্যাস এখানে বড় পার্থক্য গড়ে দেয়।
robots.txt পরিবর্তনের আগে নিজেকে প্রশ্ন করুন—
আমি কি crawler-কে Page-এ ঢুকতে দিতে চাই না, নাকি Page-টিকে Search Result-এ দেখাতে চাই না?
প্রথমটির উত্তর robots.txt হতে পারে।
দ্বিতীয়টির উত্তর সাধারণত noindex বা পরিস্থিতি অনুযায়ী অন্য indexing ব্যবস্থা।
robots.txt ভুল হলে Page Search থেকে হারানো নিয়ে তদন্তের সময় এই পার্থক্যটি মাথায় রাখলে অনেক ভুল সিদ্ধান্ত এড়ানো যায়। কারণ robots.txt ছোট একটি file হলেও, ভুল নিয়ম দিলে তার প্রভাব পুরো ওয়েবসাইটের টেকনিক্যাল SEO-তে ছড়িয়ে পড়তে পারে।
জিজ্ঞাসিত প্রশ্ন
Robots.txt দিয়ে block করা Page কি Google-এ দেখা যেতে পারে?
হ্যাঁ। URL অন্য কোনো Page, link বা sitemap থেকে আবিষ্কৃত হলে robots.txt block থাকা অবস্থাতেও সেটি Search Result-এ দেখা যেতে পারে। তবে crawler Page-এর content পড়তে না পারলে স্বাভাবিক title বা description না-ও দেখাতে পারে।
ইতিমধ্যে index হওয়া Page কীভাবে Search থেকে সরাব?
শুধু robots.txt দিয়ে block করবেন না। Page live রাখতে চাইলে সাধারণত crawlable রেখে noindex ব্যবহার করা হয়। Page স্থায়ীভাবে মুছে দিলে 404 বা 410 উপযুক্ত হতে পারে। পরিস্থিতি অনুযায়ী Search Engine-এর সাময়িক removal সুবিধাও কাজে লাগতে পারে।
একই Page-এ noindex এবং Disallow ব্যবহার করা উচিত?
সাধারণত Search থেকে Page সরানোর জন্য এটি ভালো পদ্ধতি নয়। robots.txt crawler-কে Page-এ ঢুকতে না দিলে crawler noindex পড়তে পারবে না। তাই noindex কার্যকর করতে Page crawlable রাখা দরকার।
robots.txt না থাকলে কি SEO ক্ষতি হয়?
না। robots.txt থাকা বাধ্যতামূলক নয়। কোনো crawling সীমাবদ্ধতা না থাকলে file না থাকলেও search engine সাধারণত site crawl করতে পারে। robots.txt দরকার তখনই, যখন নির্দিষ্ট crawling নিয়ন্ত্রণের প্রয়োজন আছে।
