প্রতি সপ্তাহে কেউ না কেউ একটা বাস্তব সাইট — যেটার ট্র্যাফিক আছে, ব্যাকলিংক আছে, Google-এর কয়েক বছরের বিশ্বাস অর্জন করা আছে — একটা AI বিল্ডারে স্থানান্তর করতে চান। কোনো নতুন আইডিয়া নয়, কোনো প্রোটোটাইপ নয়। একটা বিদ্যমান ব্যবসা যার হারানোর কিছু আছে। এটা খালি একটা প্রম্পট থেকে শুরু করার চেয়ে সম্পূর্ণ আলাদা কাজ, আর যে বেশিরভাগ যন্ত্রণা দেখেছি তার কারণ হলো এটাকে একই কাজ ধরে নেওয়া।
তিনটা উপায় এতটাই বারবার ভুল হয় যে সাবজেক্ট লাইনের বাইরে না পড়েই আমি সাপোর্ট টিকেটটা অনুমান করতে পারি। সঠিক উপায়টা চতুর নয়। এটা কেবল সেই জিনিস যেখানে আপনি পৌঁছান একবার এই তিনটা করা বন্ধ করলে।
ভুল এক: পুরনো কনটেন্ট ঢেলে দিয়ে আশা করা যে গঠন নিজে থেকেই ঠিক হয়ে যাবে
এই প্রবৃত্তিটা যুক্তিসঙ্গত মনে হয়। আপনার একটা সাইট আছে, এতে শব্দ আছে, তাই আপনি শব্দগুলো চ্যাটে পেস্ট করে বিল্ডারকে বলেন "এটা আরও ভালো বানাও।" যা বের হয় তা সাধারণত নতুন দেখতে কিন্তু পুরনো মনে হয় এমন একটা সাইট — একই দীর্ঘ সার্ভিস প্যারাগ্রাফ, পনেরোটার কাজ করা একই তিনটা হেডিং, এখন একটা সুন্দর টেমপ্লেটে মোড়ানো। বিল্ডারটা যা বলেছিলেন তা করেছে। আপনি এটাকে নতুন করে সাজাতে বলেছিলেন, নতুন করে ভাবতে নয়।
ধ্বংসাবশেষটা প্রায় ছয় সপ্তাহ পরে দেখা দেয়, যখন নতুন সাইটের র্যাংকিং ঠিক পুরনো সাইটের জায়গায় থাকে, বা তার একটু নিচে। কিছুই উন্নত হয়নি কারণ প্রকৃত তথ্য স্থাপত্য সম্পর্কে কিছুই বদলায়নি — একটা সার্ভিসের জন্য একই সমতল পৃষ্ঠা যা তিনটা পৃষ্ঠা হওয়া উচিত ছিল, একই অনুপস্থিত FAQ কনটেন্ট যার উপর একজন প্রতিদ্বন্দ্বীর সাইট এক বছর ধরে র্যাংক করছে। ভুল সংখ্যক ঘরওয়ালা একটা বাড়িতে একটা নতুন রঙ দিলেও তা ভুল সংখ্যক ঘরওয়ালা বাড়িই থেকে যায়।
আমার একজন ক্লায়েন্ট ছিলেন যার একটা ৪,০০০-শব্দের "Services" পৃষ্ঠা ছিল যা এগারোটা আলাদা অফার কভার করত। তিনি এটা যেমন আছে তেমনই স্থানান্তর করতে চেয়েছিলেন কারণ "এটা সবসময় কাজ করেছে।" এটা কাজ করেনি — এটা নির্দিষ্ট কিছুর জন্য র্যাংক করেনি কারণ এটা একসাথে সবকিছু নিয়ে ছিল। এটা বিশ্বস্তভাবে স্থানান্তর করলে শুধু একই র্যাংক-না-করা পৃষ্ঠার একটা সুন্দর সংস্করণ তৈরি হতো।
এখানে আসলে যা কাজ করে তা হলো স্থানান্তরকে বিল্ডের আগে একটা অডিট হিসেবে গণ্য করা। পুরনো কনটেন্ট দিন, কিন্তু প্রথমে একটা কনটেন্ট ইনভেন্টরি চান: কোন পৃষ্ঠাগুলো আছে, প্রতিটা আসলে কীসের জন্য র্যাংক করার চেষ্টা করছে, কোথায় দুটো বিষয় একটা URL-এ গাদাগাদি করা আছে আর কোথায় একটা বিষয় পাঁচটা জুড়ে পাতলা। সেই ইনভেন্টরিই পরিকল্পনা হয়ে ওঠে। পুরনো সাইট একটা সোর্স, টেমপ্লেট নয়।
ভুল দুই: ভুলে যাওয়া যে URL-ই সেই জিনিস যাকে Google আসলে বিশ্বাস করে
এটাই সবচেয়ে ব্যয়বহুল। একটা সাইট মাইগ্রেশন যেখানে URL গঠন বদলানো হয় পুরনো পাথগুলো নতুনগুলোর সাথে ম্যাপ না করেই — এমনকি যখন নতুন কনটেন্ট প্রকৃতপক্ষে ভালো হয় — সেটা বছরের পর বছর জমে থাকা সিগন্যাল ফেলে দেয়। ব্যাকলিংক একটা 404-এ পয়েন্ট করে। Google-কে আবার ক্রল করতে হয় আর অন্য ঠিকানায় ইতিমধ্যে বিশ্বাস করা পৃষ্ঠাগুলোতে নতুন করে বিশ্বাস অর্জন করতে হয়। পুরনো বুকমার্ক আর ইমেইল সিগনেচার থেকে সরাসরি ট্র্যাফিক শেষ হয়ে যায়।
আমি দেখেছি মানুষ এটা শুধু লঞ্চের পরেই খেয়াল করেন, যখন অ্যানালিটিক্স ড্যাশবোর্ড একটা বৃদ্ধির বদলে একটা খাদ দেখায়। ততক্ষণে সমাধান হলো পরে যোগ করা রিডাইরেক্ট, যা কিছুটা ক্ষতি পুনরুদ্ধার করে কিন্তু সবটা নয় — "URL সরে গেছে" আর "কেউ লক্ষ্য করে ঠিক করেছে"-র মধ্যকার ফাঁকটা সপ্তাহের হারানো ইকুইটি দিয়ে পরিমাপ করা হয় যা আপনি ফেরত পান না।
| পুরনো পদ্ধতি | কী ভাঙে | এর পরিবর্তে কী করবেন |
|---|---|---|
| বিল্ডারকে নতুন ডিজাইনের সাথে মানানসই যেকোনো URL গঠন তৈরি করতে দিন | প্রতিটা ইনবাউন্ড ব্যাকলিংক আর বুকমার্ক এখন একটা 404-এ পয়েন্ট করে | প্রথমে পুরনো সাইটম্যাপ এক্সপোর্ট করুন, বিল্ড শুরুর আগে প্রতিটা বিদ্যমান URL-কে তার নতুন সমতুল্যের সাথে ম্যাপ করুন |
| শুধু হোমপেজ রিডাইরেক্ট করুন, ভেতরের পৃষ্ঠাগুলো 404 হতে দিন | গভীর পৃষ্ঠাগুলো নিজস্ব আলাদা লিংক ইকুইটি বহন করে — সেগুলো আলাদাভাবে হারালে তা জমে বাড়ে | প্রতিটা অর্থবহ পুরনো URL 301 করুন, এমনকি যেগুলো একটা বৃহত্তর পৃষ্ঠায় মার্জ হচ্ছে সেগুলোও |
| "লাইভ হওয়ার পর পরে" রিডাইরেক্ট যোগ করুন | ক্রলার আর ক্লিক করা ব্যবহারকারীরা ঠিক সেই সময়ে মৃত প্রান্তে পৌঁছায় যখন ট্র্যাফিক সবচেয়ে অস্থির থাকে | রিডাইরেক্ট নতুন সাইটের সাথে একই মুহূর্তে লাইভ হয়, পরে নয় |
এর কোনোটাই অস্বাভাবিক নয়। এটা দুই কলামের একটা স্প্রেডশিট, বিল্ডার ছোঁয়ার আগেই তৈরি। এটা শুধু সেই ধাপ যা মানুষ এড়িয়ে যায় কারণ এটা একঘেয়ে আর বিল্ডটাই আসল মজার অংশ।
ভুল তিন: ফেরার কোনো উপায় ছাড়া বড় কাটওভার
তৃতীয় ব্যর্থতার ধরনটা মোটেও কনটেন্ট বা URL সম্পর্কে নয় — এটা আসলে কীভাবে পরিবর্তনটা ঘটে তা নিয়ে। কেউ নতুন সাইট বানায়, প্রিভিউতে যা দেখে তা পছন্দ করে, আর সেদিন বিকেলেই ডোমেইনটা সেদিকে পয়েন্ট করে দেয়। কোনো স্টেজিং পিরিয়ড নেই, বাস্তব ট্র্যাফিকের অধীনে কোনো পাশাপাশি তুলনা নেই, প্রিভিউতে ধরা না পড়া কিছু ভেঙে থাকলে কী হবে তার কোনো পরিকল্পনা নেই — নীরবে ব্যর্থ হওয়া একটা কন্টাক্ট ফর্ম, টেস্টিংয়ে কাজ করা কিন্তু বাস্তব পেমেন্ট ভলিউমে আটকে যাওয়া একটা চেকআউট ফ্লো, ডেস্কটপে ঠিকমতো রেন্ডার হওয়া কিন্তু আপনার অর্ধেক গ্রাহক ব্যবহার করেন এমন ঠিক সেই ফোনে ভেঙে যাওয়া একটা পৃষ্ঠা।
এখানকার ধ্বংসস্তূপ সবচেয়ে জোরালো ধরনের, কারণ এটা তাৎক্ষণিক। সাপোর্ট ইনবক্স ভরে যায়। কেউ একজন প্রতি দশ মিনিটে অ্যানালিটিক্স রিফ্রেশ করে দেখছে যে গ্রাফটা ভুল দিকে যাচ্ছে, আর রোলব্যাক করতে গেলে আবার DNS পয়েন্ট করতে হয়, যা প্রোপাগেট হতেও সময় লাগে, ফলে খারাপ অভিজ্ঞতা তখনও থেকে যায় যখন আপনি ইতিমধ্যে সেটা ফিরিয়ে নেওয়ার সিদ্ধান্ত নিয়ে ফেলেছেন।
সমাধানটা তেমন চমকপ্রদ কিছু নয়: কাটওভারের এক-দুই দিন আগে DNS TTL কমিয়ে দিন যাতে প্রয়োজনে রোলব্যাক দ্রুত প্রোপাগেট হয়, নতুন সাইটটা প্রথমে প্রিভিউ বা স্টেজিং সাবডোমেইনে চালান এবং সত্যিই একজন গ্রাহকের মতোই সেটা ব্যবহার করুন, আর পুরনো সাইটের হোস্টিং নতুনটা চালু হওয়ার সাথে সাথেই বন্ধ না করে অন্তত কয়েক সপ্তাহ চালু ও অক্ষত রাখুন। শেষের এই অংশটুকুর জন্য সামান্য কয়েক ডলার হোস্টিং খরচ হয়, কিন্তু এটাই আসল বীমা। মানুষ এটা এড়িয়ে যায় কারণ পুরনো প্ল্যান বাতিল করাকে একটা কাজ সম্পন্ন হওয়ার মতো মনে হয়, আর কাজ সম্পন্ন হওয়াটাই যেন অগ্রগতি বলে মনে হয়।
সঠিক পদ্ধতিটা আসলে যেমন দেখায়
সব মিলিয়ে, এর কোনোটাই ভুল পদ্ধতির চেয়ে বেশি কাজ নয় — এটা একই পরিমাণ কাজ, শুধু ভিন্ন ক্রমে। রিবিল্ড করার আগে অডিট করুন। লঞ্চ করার আগে URL ম্যাপ করুন। কাটওভারের আগে স্টেজে রাখুন, এবং তারপরও কয়েক সপ্তাহ ফিরে যাওয়ার পথ খোলা রাখুন। শেষে যে সাইটটা বের হয়ে আসে, সেটা শুধু নতুন দেখায় না — সেটা পুরনো সাইটের অর্জিত সবকিছুও ধরে রাখে, যা নতুন করে শুরু করার বদলে মাইগ্রেট করার আসল উদ্দেশ্য ছিল।
