সাইট মাইগ্রেশনের আগে ও পরে টেকনিক্যাল এসইও চেকলিস্ট

সাইট মাইগ্রেশনের সময় সবচেয়ে বড় ভুলটা অনেক সময় চালুর দিন হয় না। ভুলটা হয় তারও আগে—যখন পুরোনো সাইটের কোন পেজ ট্রাফিক পাচ্ছে, কোন ইউআরএল ব্যাকলিংক ধরে রেখেছে, কোথায় ক্যানোনিক্যাল সেট করা আছে, বা কোন পথ পরে বদলাবে—এসব লিখে রাখা হয় না।

ফলে মাইগ্রেশনের কয়েক দিন পর ট্রাফিক কমতে শুরু করলে সবাই একই প্রশ্ন করে: সমস্যা আসলে কোথায়? পুনর্নির্দেশে? সাইটম্যাপে? নতুন সার্ভারে? নাকি পুনর্নকশার সময় কোনো টেমপ্লেটে noindex থেকে গেছে?

এই কারণেই একটি এসইও সাইট মাইগ্রেশন চেকলিস্ট-কে শুধু চালুর দিনের তালিকা ভাবলে চলবে না। কাজটি তিন ভাগে ভাবা সহজ: আগে কী সংরক্ষণ করবেন, চালুর সময় কী পরীক্ষা করবেন, আর পরে কোন তথ্য দেখে বুঝবেন সবকিছু ঠিক পথে আছে কি না।

র‍্যাঙ্কিং কিছুটা নড়াচড়া করলেই অবশ্য মাইগ্রেশন ব্যর্থ—এমন নয়। বড় ধরনের সাইট স্থানান্তরের পরে গুগলের নতুন ইউআরএল ক্রল ও প্রক্রিয়াকরণ করতে সময় লাগতে পারে। মাঝারি সাইটে কয়েক সপ্তাহ সময় লাগাও অস্বাভাবিক নয়; বড় সাইটে আরও বেশি সময় লাগতে পারে।

আগে মাইগ্রেশনের ধরন পরিষ্কার করুন

সব মাইগ্রেশন একই ধরনের নয়। এখানে ভুল শ্রেণিবিন্যাস থেকেই অনেক অপ্রয়োজনীয় কাজ শুরু হয়। শুধু হোস্টিং বদলাচ্ছেন? ইউআরএল একই থাকবে। তাহলে মূল দুশ্চিন্তা পুনর্নির্দেশ নয়; ডিএনএস, সার্ভারের প্রাপ্যতা, ফায়ারওয়াল, গুগলবটের প্রবেশাধিকার এবং নতুন অবকাঠামো ঠিকমতো কাজ করছে কি না—সেটা।

ডোমেইন বদলালে বিষয়টি অন্যরকম। যেমন:

example.com → example.net

এখানে পুরোনো ইউআরএল কোন নতুন ইউআরএলে যাবে, গুগল সার্চ কনসোলে কোন প্রপার্টি লাগবে এবং ঠিকানা পরিবর্তন সুবিধা প্রযোজ্য কি না—এসব শুরুতেই ঠিক করতে হবে।

আর ইউআরএল কাঠামো বদলালে:

/blog/seo-guide → /guides/seo-guide

পুরোনো ইউআরএলকে নতুনটির সঙ্গে সরাসরি মিলিয়ে দিতে হবে।

সিএমএস বা নকশা পরিবর্তন আরও একটু জটিল। ইউআরএল একই থাকতে পারে, কিন্তু পেজ টেমপ্লেট বদলানোর সঙ্গে ক্যানোনিক্যাল, অভ্যন্তরীণ লিংক, স্ট্রাকচার্ড ডেটা, মেটাডেটা বা রেন্ডারিং বদলে যেতে পারে।

একটি বাস্তব নিয়ম: ডোমেইন, সিএমএস, নকশা এবং ইউআরএল কাঠামো—চারটিই এক দিনে বদলানো সম্ভব হলেও পরে সমস্যা খুঁজে বের করা খুব কঠিন হয়ে যায়। সুযোগ থাকলে বড় পরিবর্তনগুলো ধাপে করুন।

মাইগ্রেশনের আগে যেগুলো সংরক্ষণ না করলে পরে আফসোস হবে

এখানে অতিরিক্ত জটিলতার দরকার নেই। দরকার একটি ব্যবহারযোগ্য প্রাথমিক অবস্থা।

মাইগ্রেশন শুরু হওয়ার আগে অন্তত নিচের জিনিসগুলো রপ্তানি বা নথিভুক্ত করুন:

• সার্চ কনসোলের ক্লিক, প্রদর্শন এবং বেশি ট্রাফিক পাওয়া ল্যান্ডিং পেজ
• অর্গানিক ট্রাফিক পাওয়া গুরুত্বপূর্ণ ইউআরএল
• ব্যাকলিংক পাওয়া পেজ
• বর্তমান এক্সএমএল সাইটম্যাপ
• শিরোনাম, মেটা বর্ণনা, ক্যানোনিক্যাল ও রোবট নির্দেশনা
• এইচটিটিপি অবস্থা সংকেত এবং আগে থেকেই থাকা পুনর্নির্দেশ
• নেভিগেশন ও গুরুত্বপূর্ণ অভ্যন্তরীণ লিংক
• স্ট্রাকচার্ড ডেটা থাকলে তার বর্তমান অবস্থা
• কোর ওয়েব ভাইটালস বা অন্য কর্মক্ষমতার প্রাথমিক অবস্থা
• robots.txt

শুধু সাইটম্যাপ রপ্তানি করে “ইউআরএল তালিকা তৈরি হয়ে গেছে” ধরে নেওয়া ঠিক হবে না। কোনো পুরোনো ইউআরএল সাইটম্যাপে নেই, কিন্তু গুগল সার্চ থেকে ট্রাফিক পাচ্ছে—এটা খুবই সম্ভব। কোনো পেজ আবার ট্রাফিক খুব বেশি না পেলেও ভালো ব্যাকলিংক ধরে রাখতে পারে। তাই বড় মাইগ্রেশন হলে সাইটম্যাপের সঙ্গে অ্যানালিটিক্স, সিএমএস, সার্চ কনসোল এবং প্রয়োজনে সার্ভার লগও দেখুন।

ইউআরএল ম্যাপিং হলো সেই কাজ, যেটা সবাই দ্রুত শেষ করতে চায়

আর এখানেই পরে সমস্যা হয়।

একটি স্প্রেডশিট বানিয়ে তিনটি কলাম রাখলেই শুরু করা যায়:

পুরোনো ইউআরএল | নতুন ইউআরএল | প্রত্যাশিত অবস্থা

প্রতিটি পুরোনো ইউআরএলের জন্য প্রথম প্রশ্ন হওয়া উচিত:

• এর সত্যিকারের বিকল্প পেজ আছে কি?

থাকলে সেখানে পুনর্নির্দেশ করুন।

না থাকলে শুধু পুনর্নির্দেশ করার জন্য কোনো অপ্রাসঙ্গিক পেজ বেছে নেবেন না।

ধরুন একটি পুরোনো “টেকনিক্যাল এসইও-এর মৌলিক বিষয়” পেজ তুলে দেওয়া হয়েছে। নতুন সাইটে তার কাছাকাছি কোনো পেজই নেই। সেটিকে হোমপেজে পাঠিয়ে দেওয়া প্রযুক্তিগতভাবে পুনর্নির্দেশ বটে, কিন্তু ব্যবহারকারীর কাজে আসছে না। অনেক অপ্রাসঙ্গিক ইউআরএল একই গন্তব্যে পাঠালে গুগল সেটিকে সফট ৪০৪ হিসেবেও ধরতে পারে।

আবার উল্টো পরিস্থিতিও আছে।

পুরোনো তিনটি ছোট নিবন্ধ একত্র করে একটি ভালো নতুন নির্দেশিকা বানিয়েছেন? তাহলে তিনটি ইউআরএলই ওই নতুন একীভূত পেজে পুনর্নির্দেশ করা স্বাভাবিক। আর বিকল্প পেজ একেবারেই না থাকলে 404 বা 410 অবস্থা সংকেত ব্যবহার করা যায়। প্রতিটি মুছে ফেলা ইউআরএলের জন্য জোর করে নতুন গন্তব্য বানানোর দরকার নেই।

পুনর্নির্দেশ যাচাই: ব্রাউজারে খুললেই পরীক্ষা শেষ নয়

স্থায়ী ইউআরএল পরিবর্তনের ক্ষেত্রে 301 বা 308 সার্ভারভিত্তিক পুনর্নির্দেশ ব্যবহার করা সাধারণ পদ্ধতি।

চালুর আগে কিছু প্রতিনিধিত্বশীল ইউআরএল দিয়ে অন্তত এগুলো পরীক্ষা করুন:

• পুরোনো ইউআরএল ঠিক নতুন পেজে যাচ্ছে?
• পুনর্নির্দেশের লুপ তৈরি হচ্ছে?
• মাঝখানে অপ্রয়োজনীয় পুনর্নির্দেশ আছে?
• এইচটিটিপি এবং এইচটিটিপিএস দুটোই ঠিকমতো কাজ করছে?
• www এবং non-www রূপ কোথায় যাচ্ছে?
• পুরোনো অনুসন্ধান পরামিতি বা প্রচারাভিযানের ইউআরএল বাদ পড়ছে?

একটি পরিষ্কার পুনর্নির্দেশ:

পুরোনো ইউআরএল → নতুন ইউআরএল

এর চেয়ে এইটি কম ভালো:

পুরোনো ইউআরএল → পুরোনো এইচটিটিপিএস ইউআরএল → অস্থায়ী ইউআরএল → নতুন ইউআরএল

গুগলবট পুনর্নির্দেশের ধাপ অনুসরণ করতে পারে। কিন্তু ধাপগুলো রাখার দরকার না থাকলে সরাসরি চূড়ান্ত ইউআরএলে পাঠান।

ব্যবহারকারীর জন্যও সেটি দ্রুত।

পরীক্ষামূলক সাইট নিয়ে একটি খুব পরিচিত ভুল

পরীক্ষামূলক সাইটকে গুগল থেকে লুকাতে গিয়ে অনেকে robots.txt দিয়ে বন্ধ করেন, আবার একই পেজে noindex বসান। এতে সমস্যা হলো, গুগলবট পেজটি ক্রল করতে না পারলে noindex নির্দেশনাটাই দেখতে নাও পারে।

ব্যক্তিগত পরীক্ষামূলক পরিবেশ হলে পাসওয়ার্ড সুরক্ষা, লগইন বাধ্যতামূলক করা বা আইপি সীমাবদ্ধতা বেশি পরিষ্কার ব্যবস্থা। সবার জন্য খোলা অস্থায়ী হোস্টনাম ব্যবহার করতেই হলে noindex ব্যবহার করা যেতে পারে, তবে ক্রলারকে নির্দেশনাটি পড়ার সুযোগ দিতে হবে।

আর চালুর দিন এই তালিকাটি সত্যিই কাজে লাগে:

• পরীক্ষামূলক সাইটের noindex মূল সাইটে থেকে গেছে?
• robots.txt এখনও গুরুত্বপূর্ণ ডিরেক্টরি বন্ধ করছে?
• গুগলবট মূল সাইটের পেজ খুলতে পারছে?
• মাইগ্রেশনের জন্য দেওয়া অস্থায়ী ক্রল সীমাবদ্ধতা সরানো হয়েছে?

একটি টেমপ্লেটে ভুল থাকলে একটি পেজ নয়, একসঙ্গে হাজার পেজে সমস্যা হতে পারে। তাই হোমপেজ দেখা এখানে যথেষ্ট নয়।

ক্যানোনিক্যাল ঠিক না থাকলে পুনর্নির্দেশ একা সব সামলাবে না

নতুন ইউআরএল চালু, পুরোনো ইউআরএল পুনর্নির্দেশ হচ্ছে—ভালো। এখন পেজের সোর্স খুলে দেখুন ক্যানোনিক্যাল কোথায় যাচ্ছে। যদি নতুন পেজ এখনও পুরোনো ডোমেইনকে ক্যানোনিক্যাল দেখায়, তাহলে মাইগ্রেশনের সংকেত পরিষ্কার থাকছে না।

বহুভাষিক সাইট হলে hreflang-ও একইভাবে পরীক্ষা করুন।

অভ্যন্তরীণ লিংকের ক্ষেত্রেও একটু শৃঙ্খলা দরকার। মেনু, ব্রেডক্রাম্ব, ফুটার বা নিবন্ধের মূল অংশে যদি নতুন ইউআরএল জানা থাকে, তাহলে পুরোনো ইউআরএল রেখে পুনর্নির্দেশের ওপর নির্ভর করবেন কেন? নিজের সাইটের লিংক সরাসরি চূড়ান্ত ইউআরএলেই দিন।

আরও পড়ুন: Technical SEO Audit কোথা থেকে শুরু করবেন: ধাপে ধাপে পূর্ণ গাইড

সাইটম্যাপ হালনাগাদ করুন, কিন্তু তার ওপর বেশি ভরসা করবেন না

নতুন সাইটম্যাপে নতুন ক্যানোনিক্যাল ইউআরএল রাখুন।

দেখুন:

• পুরোনো পুনর্নির্দেশ হওয়া ইউআরএল রয়ে গেছে কি না
• কোনো পরীক্ষামূলক ইউআরএল ঢুকে গেছে কি না
• ভুল noindex পেজ আছে কি না
• ক্যানোনিক্যাল সাইটম্যাপের ইউআরএলের সঙ্গে মিলছে কি না

তারপর গুগল সার্চ কনসোলে সাইটম্যাপ জমা দেওয়া যায়।

কিন্তু সাইটম্যাপ জমা দেওয়া আর ইনডেক্স হওয়া এক বিষয় নয়। সাইটম্যাপ গুগলকে ইউআরএল খুঁজে পেতে সাহায্য করে; প্রতিটি ইউআরএল ইনডেক্স হওয়ার নিশ্চয়তা দেয় না। এই পার্থক্যটি মনে রাখলে মাইগ্রেশনের পর “সাইটম্যাপ জমা দিয়েছি, তারপরও ইনডেক্স হচ্ছে না কেন?”—এই ভুল অনুসন্ধান অনেকটাই কমে।

ডোমেইন বদলালে সার্চ কনসোল পরে নয়, আগে

ডোমেইন মাইগ্রেশনের আগে পুরোনো এবং নতুন সাইট দুটিই গুগল সার্চ কনসোলে যাচাই করে রাখুন।

প্রাসঙ্গিক ডোমেইনের বিভিন্ন রূপও বাদ দেবেন না।

২০২৬ সালের জুনে গুগল তার সাইট স্থানান্তর নির্দেশিকায় আবার পরিষ্কার করেছে যে একটি ঠিকানা পরিবর্তনের অনুরোধ কোনো ডোমেইনের সব সাবডোমেইন নিজে থেকে স্থানান্তর করে না।

অর্থাৎ www, non-www বা অন্য সাবডোমেইন বাস্তবে ব্যবহার করলে সেগুলো আলাদা করে বুঝতে হবে।

ঠিকানা পরিবর্তন সুবিধা কোথায় কাজে লাগে?

এক ডোমেইন বা সাবডোমেইন থেকে অন্য ডোমেইন বা সাবডোমেইনে যাওয়ার ক্ষেত্রে।

ব্যবহার করার আগে:

• পুরোনো ও নতুন প্রপার্টির মালিকানা থাকতে হবে
• একই গুগল অ্যাকাউন্ট দিয়ে সেগুলো পরিচালনা করতে হবে
• উৎস প্রপার্টি ডোমেইন স্তরের হতে হবে
• পুনর্নির্দেশ আগে চালু থাকতে হবে

এটি এইচটিটিপি → এইচটিটিপিএস, একই ডোমেইনের পথ পরিবর্তন, শুধু হোস্টিং বদলানো বা সিডিএন পরিবর্তনের জন্য নয়। আর ঠিকানা পরিবর্তন সুবিধাকে পুনর্নির্দেশের বিকল্প ভাববেন না। ভুল পুনর্নির্দেশ থাকলে সার্চ কনসোলের এই সুবিধা সেটি ঠিক করে দেবে না।

শুধু হোস্টিং বদলালে অন্য ধরনের সমস্যা দেখবেন

ইউআরএল অপরিবর্তিত বলে হোস্টিং মাইগ্রেশনকে এসইও-ঝুঁকিহীন কাজ ভাবার কারণ নেই।

এখানে তালিকা ছোট, কিন্তু গুরুত্বপূর্ণ:

• নতুন সার্ভার সঠিক কনটেন্ট দিচ্ছে?
• প্রতিক্রিয়া সংকেত ঠিক?
• টিএলএস/এসএসএল বিন্যাস কাজ করছে?
• নিরাপত্তা স্তর বা ফায়ারওয়াল গুগলবটকে আটকে দিচ্ছে?
• সার্ভারের সাড়া অস্বাভাবিক ধীর?
• সার্চ কনসোল যাচাইকরণ ঠিক আছে?

ডিএনএস পরিবর্তনের আগে টিটিএল কমিয়ে রাখলে নতুন রেকর্ড দ্রুত ছড়াতে সুবিধা হতে পারে। আর পুরোনো হোস্টিং মাইগ্রেশনের সঙ্গে সঙ্গে বন্ধ করবেন না। কিছুদিন লগ দেখুন। পুরোনো সার্ভারে অনুরোধ আর আসছে না এবং নতুন অবকাঠামো থেকে ব্যবহারকারী ও ক্রলার দুজনই ঠিক কনটেন্ট পাচ্ছে—তারপর পুরোনো সার্ভার বন্ধ করুন।

চালুর দিনের যাচাই তালিকা

এখানে তালিকা সত্যিই তালিকার মতো হওয়া উচিত।

হোমপেজ দেখে “সব ঠিক” বলবেন না।

চালুর পর নমুনা হিসেবে পরীক্ষা করুন:

• হোমপেজ
• বেশি ট্রাফিক পাওয়া নিবন্ধ
• গুরুত্বপূর্ণ ব্যাকলিংক থাকা পুরোনো ইউআরএল
• বিভাগ বা আর্কাইভ পেজ
• পেজ ভাগের পেজ
• বহুভাষিক পেজ
• ছবি, ভিডিও বা পিডিএফ ইউআরএল
• ক্যানোনিক্যাল
• রোবট নির্দেশনা
• স্ট্রাকচার্ড ডেটা
• সাইটম্যাপ
• মোবাইল রেন্ডারিং

দুই-চারটি ইউআরএল হলে ইউআরএল ইনস্পেকশন যথেষ্ট কাজে দেয়। কিন্তু ৫০ হাজার ইউআরএলের সাইট হাতে খুলে পরীক্ষা করার পরিকল্পনা বাস্তবসম্মত নয়। সেখানে স্বয়ংক্রিয় ক্রলার, স্ক্রিপ্ট বা সার্ভার লগ দরকার।

চালুর পর প্রথম কয়েক দিন কী দেখবেন

সবচেয়ে আগে র‍্যাঙ্কিং ট্র্যাকার নয়।

প্রথমে দেখতে হবে প্রযুক্তিগত সংকেতগুলো ঠিক আছে কি না।

সার্চ কনসোলের কার্যসম্পাদন প্রতিবেদন

পুরোনো ও নতুন প্রপার্টির প্রদর্শন এবং ক্লিক পাশাপাশি দেখুন।

ডোমেইন মাইগ্রেশন হলে পুরোনো ইউআরএলের দৃশ্যমানতা কমতে এবং নতুন ইউআরএলের দৃশ্যমানতা বাড়তে সময় লাগতে পারে।

একদিনের রেখাচিত্র দেখে সিদ্ধান্ত না নিয়ে প্রবণতা দেখুন।

পেজ ইনডেক্সিং

হঠাৎ নতুন সমস্যা তৈরি হয়েছে কি না দেখুন।

বিশেষ নজর দিন:

• 404
• সার্ভার ত্রুটি
• পুনর্নির্দেশ সমস্যা
• ক্যানোনিক্যাল অমিল
• রোবট দ্বারা বাধা
• noindex
• ক্রল বা ইনডেক্সিং সমস্যা

একটি নির্দিষ্ট ইউআরএল সন্দেহজনক হলে পেজ ইনডেক্সিং প্রতিবেদনের চেয়ে ইউআরএল ইনস্পেকশন বেশি কাজে দেবে।

ক্রল পরিসংখ্যান

বড় সাইটে এটি বেশি দরকারি।

ইউআরএল পরিবর্তনসহ মাইগ্রেশন হলে নতুন সাইটে ক্রল কার্যক্রম বাড়তে পারে, কারণ পুরোনো ইউআরএলের অনুরোধ পুনর্নির্দেশ হয়ে নতুন সাইটেও পৌঁছায়।

শুধু হোস্টিং বদলালে আচরণ আবার আলাদা হতে পারে। চালুর পর ক্রলের হার প্রথমে কিছুটা কমে পরে বাড়তে পারে।

দুটিকে একই ধরন ধরে বিচার করবেন না।

সার্ভার লগ

এখানে অনেক বাস্তব সমস্যা দ্রুত ধরা পড়ে।

গুগলবট এখনও কোন পুরোনো ইউআরএল চাইছে? প্রতিক্রিয়া কী? 5xx বেড়েছে? কোনো গুরুত্বপূর্ণ অংশ ক্রল হচ্ছে না?

সার্চ কনসোলের সঙ্গে লগ মিলিয়ে দেখলে চিত্র অনেক পরিষ্কার হয়।

পুনর্নির্দেশ ১৮০ দিন, নাকি ১ বছর?

দুটো সংখ্যাই দেখা যায়। তাই বিভ্রান্তি স্বাভাবিক।

সাইট মাইগ্রেশনের পুনর্নির্দেশ সাধারণভাবে কমপক্ষে ১ বছর রাখা ভালো। ব্যবহারকারীর দরকার থাকলে আরও দীর্ঘ সময় রাখা যায়। অন্যদিকে ঠিকানা পরিবর্তনের মাইগ্রেশন সম্পর্ক ১৮০ দিন সক্রিয় থাকে এবং ওই নথিতেও অন্তত ১৮০ দিন পুনর্নির্দেশ রাখার কথা আছে।

এই দুই নির্দেশনা একই জিনিস বলছে না। ইউআরএল মাইগ্রেশনের ক্ষেত্রে বাস্তব মানদণ্ড হিসেবে ১ বছর ধরে রাখাই বেশি নিরাপদ। পুরোনো ডোমেইনও খুব দ্রুত ছেড়ে দেবেন না। ব্যাকলিংক, বুকমার্ক বা পুরোনো সরাসরি প্রবেশ মাসের পর মাস আসতে পারে।

ট্রাফিক কমলে প্রথম কাজ কনটেন্ট পুনর্লিখন নয়

মাইগ্রেশনের পর ট্রাফিক কমেছে। এখন প্রথম প্রতিক্রিয়া যদি হয়, “সব নিবন্ধ আবার লিখতে হবে”—তাহলে সমস্যা খোঁজা ভুল জায়গা থেকে শুরু হচ্ছে।

আগে এই দশটি প্রশ্ন করুন:

১. পুরোনো ইউআরএল কি সঠিক নতুন ইউআরএলে যাচ্ছে?
২. নতুন ইউআরএল কি সফল এইচটিটিপি প্রতিক্রিয়া দিচ্ছে?
৩. ভুল noindex আছে?
৪. robots.txt কোনো গুরুত্বপূর্ণ পথ বন্ধ করেছে?
৫. ক্যানোনিক্যাল ঠিক?
৬. অভ্যন্তরীণ লিংক নতুন ইউআরএলে গেছে?
৭. সাইটম্যাপে নতুন ক্যানোনিক্যাল ইউআরএল আছে?
৮. সার্চ কনসোলে নতুন ইনডেক্সিং বা ক্রল সমস্যা দেখা যাচ্ছে?
৯. 5xx, সময়সীমা অতিক্রম বা সার্ভারের সক্ষমতার সমস্যা আছে?
১০. সমস্যা পুরো সাইটে, নাকি একটি টেমপ্লেট বা ডিরেক্টরিতে?

শেষের প্রশ্নটি বিশেষ গুরুত্বপূর্ণ। শুধু /blog/ অংশের ট্রাফিক কমে থাকলে পুরো ডোমেইন নিয়ে তত্ত্ব বানানোর আগে ওই অংশের টেমপ্লেট, ক্যানোনিক্যাল, পুনর্নির্দেশ এবং অভ্যন্তরীণ লিংক দেখুন। পুরো সাইট একসঙ্গে নড়ে গেলে তখন সাইটজুড়ে থাকা বিন্যাস বা অবকাঠামো বেশি সন্দেহজনক।

যে ভুলগুলো মাইগ্রেশনকে বেশি কঠিন করে

এগুলো এড়াতে পারলে পরে সমস্যা খুঁজে বের করা অনেক সহজ হয়।

• ইউআরএল ম্যাপিং ছাড়া চালু করা
• সব পুরোনো ইউআরএল হোমপেজে পাঠিয়ে দেওয়া
• অপ্রয়োজনীয় পুনর্নির্দেশ ধাপ রেখে দেওয়া
• নতুন সাইটে পুরোনো ক্যানোনিক্যাল রাখা
• পরীক্ষামূলক সাইটের noindex মূল সাইটে নিয়ে আসা
• robots.txt দিয়ে গুরুত্বপূর্ণ পথ বন্ধ করা
• অভ্যন্তরীণ লিংক পুরোনো ইউআরএলে রেখে দেওয়া
• সাইটম্যাপে পুনর্নির্দেশ হওয়া ইউআরএল রাখা
• ডোমেইন, সিএমএস, নকশা ও ইউআরএল কাঠামো একই দিনে বদলানো
• চালুর পর পর্যবেক্ষণ বন্ধ করে দেওয়া

সবচেয়ে বিপজ্জনক ভুল সাধারণত এমনই কিছু, যা দেখতে ছোট—কিন্তু টেমপ্লেট স্তরের হওয়ার কারণে হাজার ইউআরএলে ছড়িয়ে যায়।

তাহলে মাইগ্রেশন সফল হয়েছে বুঝবেন কীভাবে?

একটি কীওয়ার্ড আগের অবস্থানে আছে কি না, সেটি দিয়ে নয়।

বরং কয়েকটি জিনিস একসঙ্গে দেখুন।

• পুরোনো ইউআরএল কি ঠিক গন্তব্যে যাচ্ছে?
• নতুন গুরুত্বপূর্ণ ইউআরএল কি ক্রল ও ইনডেক্স হচ্ছে?
• সার্ভার ত্রুটি কি নিয়ন্ত্রণে?
• নতুন ইউআরএল কি প্রদর্শন ও ক্লিক পেতে শুরু করেছে?
• গুরুত্বপূর্ণ ল্যান্ডিং পেজ কি অপ্রত্যাশিতভাবে হারিয়ে যাচ্ছে না?

এই প্রশ্নগুলোর উত্তর ধীরে ধীরে স্বাভাবিক দিকে গেলে মাইগ্রেশনও ঠিক পথে আছে। একটি এসইও সাইট মাইগ্রেশন চেকলিস্ট-এর আসল কাজ “একটিও ভুল হবে না” নিশ্চিত করা নয়। সেটি বাস্তবসম্মত প্রত্যাশা নয়।

এর কাজ হলো—ভুল হলে কোথায় খুঁজতে হবে, সেই পথ আগে থেকেই তৈরি রাখা।

সময় কম থাকলে মাইগ্রেশনের আগে দুটি কাজ কোনোভাবেই বাদ দেবেন না: গুরুত্বপূর্ণ ইউআরএলের ম্যাপিং তৈরি করুন এবং বর্তমান এসইও-এর প্রাথমিক অবস্থা সংরক্ষণ করুন।

চালুর পরে ট্রাফিক নড়লে র‍্যাঙ্কিং নিয়ে অনুমান করার আগে একটি পুরোনো ইউআরএল বেছে নিন। সেটি পুনর্নির্দেশ থেকে চূড়ান্ত পেজ, ক্যানোনিক্যাল, ইনডেক্সযোগ্যতা এবং অভ্যন্তরীণ লিংক পর্যন্ত অনুসরণ করুন।

অনেক মাইগ্রেশন সমস্যার সূত্র সেখানেই ধরা পড়ে।

প্রায়শই জিজ্ঞাসিত প্রশ্ন

সাইট মাইগ্রেশনের পর ট্রাফিক কমে গেলে কি সঙ্গে সঙ্গে চিন্তার কারণ আছে?

সব ক্ষেত্রে নয়। বড় ধরনের সাইট মাইগ্রেশনের পর গুগলের নতুন ইউআরএল ক্রল, প্রক্রিয়াকরণ ও ইনডেক্স করতে কিছু সময় লাগতে পারে। তবে ট্রাফিক কমার সঙ্গে 404, ভুল পুনর্নির্দেশ, noindex, ক্যানোনিক্যাল সমস্যা বা সার্ভার ত্রুটি দেখা দিলে সেগুলো দ্রুত পরীক্ষা করা উচিত।

সাইট মাইগ্রেশনের সময় সব পুরোনো ইউআরএল কি হোমপেজে পুনর্নির্দেশ করা যায়?

না। পুরোনো ইউআরএলের সমতুল্য নতুন পেজ থাকলে সেখানেই পুনর্নির্দেশ করা উচিত। অপ্রাসঙ্গিক অনেক ইউআরএল একসঙ্গে হোমপেজে পাঠালে ব্যবহারকারীর জন্য বিভ্রান্তি তৈরি হতে পারে এবং গুগল কিছু ক্ষেত্রে সেটিকে সফট 404 হিসেবে বিবেচনা করতে পারে।

সাইট মাইগ্রেশনের পর ৩০১ পুনর্নির্দেশ কত দিন রাখা উচিত?

গুগলের সাইট মাইগ্রেশন নির্দেশনা অনুযায়ী, পুনর্নির্দেশ যত দীর্ঘ সম্ভব চালু রাখা ভালো এবং সাধারণভাবে অন্তত ১ বছর রাখা উচিত। পুরোনো লিংক, বুকমার্ক বা সরাসরি ভিজিটের কারণে প্রয়োজন হলে এটি আরও দীর্ঘ সময় রাখা যেতে পারে।

শুধু হোস্টিং বদলালে কি Change of Address ব্যবহার করতে হবে?

না। ইউআরএল বা ডোমেইন অপরিবর্তিত রেখে শুধু হোস্টিং বা সার্ভার বদলালে Change of Address ব্যবহার করা হয় না। এ ধরনের মাইগ্রেশনে DNS, সার্ভার প্রতিক্রিয়া, গুগলবটের প্রবেশাধিকার, নিরাপত্তা নিয়ম এবং সার্ভারের সক্ষমতার দিকে বেশি নজর দেওয়া দরকার।

সাইট মাইগ্রেশনের পরে সবচেয়ে আগে কোন বিষয়গুলো পরীক্ষা করা উচিত?

প্রথমে গুরুত্বপূর্ণ পুরোনো ইউআরএল সঠিক নতুন পেজে যাচ্ছে কি না দেখুন। এরপর HTTP response, noindex, robots.txt, canonical, internal link, sitemap এবং Search Console-এর indexing সমস্যা পরীক্ষা করুন। বড় সাইট হলে server log ও crawl data-ও দেখা উচিত।