আমি এমন একটি ডোমেইন কিনেছিলাম যা প্রথম 2000 সালে নিবন্ধিত হয়েছিল। কাগজে-কলমে এত পুরোনো history বরং সুবিধা বলেই মনে হচ্ছিল। কিন্তু নতুন সাইট চালু করার পর server log এমন সব page-এর request-এ ভরে যেতে শুরু করল যেগুলো আমি কখনও তৈরি করিনি।
নতুন project-এ নেই এমন URL-এ প্রতিদিন 1,000-এর বেশি request আসছিল। Analytics-এ এটি প্রায় zero engagement-সহ direct traffic-এর বড় spike হিসেবে দেখা যাচ্ছিল। একই সময় Yandex crawler পুরোনো path-এ ফিরে এসে 404 Not Found পাচ্ছিল, আর Yandex Webmaster-এ এক রাতেই 900-এর বেশি error জমেছিল।
আমার প্রথম ব্যাখ্যা ছিল সহজ: পুরোনো bot dead URL-এ আঘাত করছে, Yandex সেই activity দেখছে, তাই এগুলো crawl করে যাচ্ছে। আমার দিক থেকে sequence সত্যিই এমন দেখাচ্ছিল। কিন্তু আমার data এই causal relationship প্রমাণ করার জন্য যথেষ্ট ছিল না।
আমি আসলে কী নিশ্চিত করতে পেরেছিলাম
তিনটি আলাদা observation ছিল। প্রথমত, server ডোমেইনের আগের জীবনের URL-এ প্রচুর request পাচ্ছিল। দ্বিতীয়ত, সেই traffic meaningful user engagement তৈরি করছিল না। তৃতীয়ত, Yandex crawler-ও পুরোনো path request করছিল এবং Webmaster dashboard-এ এক রাতেই 900-এর বেশি error দেখা গিয়েছিল।
Operationally এটি বাস্তব সমস্যা ছিল: noisy log, অপ্রয়োজনীয় request এবং পরিষ্কার করতে হওয়া webmaster report। কিন্তু এই facts প্রমাণ করে না যে third-party bot Yandex crawl trigger করেছে, কিংবা error সরাসরি ranking বা organic traffic ক্ষতি করেছে। Crawling indexing নয়, indexing ranking নয়, এবং error report penalty-এর প্রমাণ নয়।
404 আর 410 নিয়ে আমি যেটা বেশি সরল করে ফেলেছিলাম
আগে আমি পার্থক্যটা এভাবে ভাবতাম: 404 মানে “হয়তো এখন নেই”, আর 410 মানে “স্থায়ীভাবে চলে গেছে”। Intuition হিসেবে এটি কাজে লাগে, কিন্তু technically পুরোপুরি নির্ভুল নয়।
404 Not Found মানে server requested resource-এর current representation দিতে পারছে না; status নিজে বলে না অবস্থাটি temporary না permanent। 410 Gone আরও specific: server যখন জানে resource আর available নয় এবং অবস্থাটি permanent হওয়ার কথা, তখন এটি উপযুক্ত।
SEO claim-এর ক্ষেত্রেও এই precision জরুরি। Search engine 404 বা 410—দুই ধরনের URL-ই search থেকে সরাতে পারে। তাই এখন আমি 410-কে কোনো magic “stronger SEO status” বলি না এবং deleted page-এর জন্য 404-কে সবসময় ভুলও বলি না।
তবুও আমার ক্ষেত্রে targeted 410 কেন যুক্তিযুক্ত ছিল
পুরোনো path-গুলো temporary failure ছিল না। সেগুলো ডোমেইনের আগের content-এর অংশ ছিল এবং নতুন project-এ তাদের কোনো স্থান ছিল না। আমি জানতাম নির্দিষ্ট URL-গুলো permanently gone। তাই 410 Gone তাদের বাস্তব অবস্থাকে সঠিকভাবে প্রকাশ করছিল।
আমি সব unknown URL-কে 410 না করে কেবল পরিচিত legacy path-এ targeted 410 configure করলাম। পরিবর্তনের পর পুরোনো path ঘিরে crawl এবং reporting noise কমে গেল এবং webmaster tools-এর অবস্থা অনেক পরিষ্কার হলো।
তবুও causality নিয়ে আমি সতর্ক। আমি বলতে পারি improvement targeted 410-এর পরে এসেছে এবং 410 URL-গুলোর অবস্থার জন্য semantically সঠিক ছিল। কিন্তু শুধু 410 সব bot থামিয়েছে—এটা প্রমাণ করতে পারি না। Third-party bot HTTP status-এর অর্থ উপেক্ষা করে একই path অনন্তকাল request করতে পারে।
এখন আমার decision rule
সঠিক প্রশ্ন “410 কি 404-এর চেয়ে ভালো?” নয়; বরং “এই URL-এর সঙ্গে আসলে কী হয়েছে?”
- স্পষ্ট replacement আছে: সত্যিকারের equivalent নতুন URL-এ
301ধরনের permanent redirect দিন। - পুরোনো resource স্থায়ীভাবে সরানো হয়েছে এবং replacement নেই:
410 Goneprecise choice। - URL শুধু unknown, typo বা কখনও ছিলই না: সাধারণ
404 Not Foundউপযুক্ত।
শুধু error গায়েব করার জন্য সব dead URL homepage-এ redirect করব না। এতে resource-এর real state লুকিয়ে যায় এবং user ও crawler উভয়ের experience খারাপ হতে পারে।
আজ launch-এর আগে aged domain কীভাবে audit করতাম
আবার history-ওয়ালা domain ব্যবহার করলে পুরোনো website migrate না করলেও URL history-কে migration-এর অংশ হিসেবে ধরব।
- পুরোনো footprint দেখুন। Launch-এর আগে historical URL এবং obvious legacy section খুঁজুন।
- প্রথম দিন থেকেই access log দেখুন। আপনি কখনও তৈরি করেননি এমন path-এ repeated request দেখায় domain এখনও external system-এ মনে রাখা আছে।
- Human, search crawler এবং random bot আলাদা করুন। Direct traffic spike আর crawler error আলাদা signal; স্বয়ংক্রিয়ভাবে এক causal story বানাবেন না।
- Recurring dead URL classify করুন। প্রতিটি important pattern-এর জন্য 301, 404 না 410—সচেতনভাবে ঠিক করুন।
- Result আলাদা করে monitor করুন। Request frequency, crawler report এবং indexing আলাদা dimension; এগুলোকে একটি vague “SEO health” metric-এ মিলিয়ে ফেলবেন না।
Log আর webmaster tools noise-এ ভরে যাওয়ার পরে সমস্যা খোঁজার চেয়ে এই কাজের খরচ অনেক কম।
410 কী সমাধান করে না
410 resource-এর state সম্পর্কে HTTP statement। এটি firewall, rate limiter বা bot-blocking mechanism নয়। Scraper 410 পাওয়ার পরেও request পাঠাতে থাকলে server-কে সেগুলো receive ও answer করতেই হবে। আসল সমস্যা যদি abusive request volume হয়, সেটি আলাদা infrastructure problem।
410 SEO boost-ও নয়। Correct status crawler-কে URL-এর কী হয়েছে বুঝতে সাহায্য করে; শুধু সেটি নতুন site-কে ভালো rank করায় না।
যে lessonটা আমার সঙ্গে রয়ে গেছে
পুরোনো domain-এ পুরোনো URL ছিল—এটাই আশ্চর্য বিষয় ছিল না। আশ্চর্য ছিল invisible history launch-এর পর কত দ্রুত ফিরে এল: আমার নেই এমন page-এ দিনে 1,000-এর বেশি request, প্রায় zero engagement এবং Yandex Webmaster-এ এক রাতেই 900-এর বেশি error।
Aged domain কোনো empty namespace নয়। Original content চলে যাওয়ার বহু বছর পরেও পুরোনো link, crawler, script এবং bot path মনে রাখতে পারে। আমার বর্তমান rule সহজ: history audit করুন, reality অনুযায়ী HTTP status দিন, এবং operational bot traffic-কে search-engine conclusion থেকে আলাদা রাখুন।
History asset হতে পারে। একই সঙ্গে সেটি inherited state-ও।