সার্চ র‍্যাঙ্কিং ধসিয়ে না দিয়ে কীভাবে ডোমেইন মাইগ্রেট করবেন

ডোমেইন পরিবর্তন এমন কয়েকটি SEO প্রকল্পের একটি, যেখানে প্রযুক্তিগতভাবে ছোট একটি ভুল খুব দ্রুত খুব দৃশ্যমান হয়ে উঠতে পারে। একটি অনুপস্থিত রিডাইরেক্ট, ব্লক করা crawl path, বা ভুলে যাওয়া canonical—এসব একটি সরল rebrand-কে কয়েক সপ্তাহের ranking volatility-তে পরিণত করতে পারে।

কিছু ওঠানামা স্বাভাবিক। সার্চ ইঞ্জিনের পুরোনো URLs crawl করতে, রিডাইরেক্ট খুঁজে পেতে, signals প্রক্রিয়া করতে, এবং নতুন ডোমেইনকে index-এ স্থির করতে সময় লাগে। লক্ষ্য প্রতিটি dip এড়ানো নয়। লক্ষ্য হলো migration-কে বিরক্তিকরভাবে সরল করা: একটি পুরোনো URL একটি সমতুল্য নতুন URL-এ যায়, server স্পষ্টভাবে response দেয়, এবং গুরুত্বপূর্ণ কিছু হারিয়ে যায় না।

রিডাইরেক্ট rule দিয়ে নয়, inventory দিয়ে শুরু করুন

সবচেয়ে সাধারণ migration failure হলো এটিকে server configuration task হিসেবে দেখা। এটি তা নয়। এটি একটি information architecture task, যার শেষ ধাপ হিসেবে server configuration আসে।

DNS স্পর্শ করার আগে, গুরুত্বপূর্ণ URLs-এর একটি তালিকা তৈরি করুন:

• যেসব URLs organic traffic পায়
• যেসব URLs-এর external backlinks আছে
• যেসব URLs conversion ঘটায়, leads তৈরি করে, বা campaigns support করে
• আপনার XML sitemap-এ বর্তমানে থাকা canonical URLs
• PDFs, images, এবং downloadable files যেগুলো externally linked
• উচ্চ-মূল্যের legacy URLs, যেগুলো বর্তমান navigation-এ নাও থাকতে পারে

প্রতিটি পুরোনো URL-এর জন্য নতুন ডোমেইনে একটি destination নির্ধারণ করুন। বেশিরভাগ ক্ষেত্রে, সেই destination একই intent সহ একই page হওয়া উচিত। যদি /pricing হয় https://newdomain.com/pricing, সেটি সহজ। যদি তিনটি পুরোনো product page একত্র করে একটি নতুন guide বানানো হয়, সিদ্ধান্তটি সচেতনভাবে document করুন।

অলস pattern এড়িয়ে চলুন: সবকিছু নতুন homepage-এ redirect করা। এটি সুবিধাজনক, কিন্তু relevance নষ্ট করে। সার্চ ইঞ্জিন এবং ব্যবহারকারী—দুজনেই আশা করে destination যেন original URL-এর একই প্রয়োজনের উত্তর দেয়।

যেখানে সম্ভব URL structure ধরে রাখুন

Paths স্থিতিশীল থাকলে domain migration সহজ হয়। oldsite.com/blog/example থেকে newsite.com/blog/example-এ যাওয়া একই সময়ে domain, CMS, slugs, folder structure, এবং content বদলানোর চেয়ে অনেক পরিষ্কার।

কখনও redesign বা CMS migration-এর কারণে URL পরিবর্তন অনিবার্য হয়। সে ক্ষেত্রে সিদ্ধান্তগুলো আলাদা করুন:

1. ডোমেইন বদলানোর কারণে কী পরিবর্তন হচ্ছে?
2. site structure বদলানোর কারণে কী পরিবর্তন হচ্ছে?
3. কী delete, merge, বা rewrite করা হচ্ছে?

আপনি যত বেশি variable যোগ করবেন, পরে সমস্যা diagnose করা তত কঠিন হবে। migration যদি গুরুত্বপূর্ণ হয় এবং বর্তমান site ভালো perform করে, আগে domain move করে পরে redesign করার কথা ভাবুন।

Permanent, one-hop redirects ব্যবহার করুন

সত্যিকারের domain migration-এর জন্য পুরোনো URLs থেকে তাদের নতুন equivalents-এ server-side 301 বা 308 redirects ব্যবহার করুন। Temporary redirects temporary পরিস্থিতির জন্য। JavaScript redirects, meta refreshes, এবং soft redirects দুর্বল signals এবং ভাঙার ঝুঁকিও বেশি।

আপনার redirect goals সরল:

• প্রতিটি গুরুত্বপূর্ণ পুরোনো URL একটি permanent redirect return করে।
• প্রতিটি redirect সরাসরি final destination-এ যায়।
• HTTP পরিষ্কারভাবে HTTPS-এ redirect করে।
• www এবং non-www variants consistentভাবে handle করা হয়।
• প্রয়োজন না হলে redirects fragile query-string behavior-এর উপর নির্ভর করে না।

একটি খারাপ chain দেখতে এমন:

http://oldsite.com/page → https://oldsite.com/page → https://www.oldsite.com/page → https://newsite.com/page → https://www.newsite.com/page

এটি শেষ পর্যন্ত হয়তো সঠিক page-এ পৌঁছাবে, কিন্তু এটি slow, crawl করা কঠিন, এবং ভুল লুকিয়ে ফেলার সম্ভাবনা বেশি। প্রতিটি পুরোনো variant থেকে final new URL-এ one hop লক্ষ্য করুন।

Behavior validate করার সময় browser যা দেখায় সেটি বিশ্বাস না করে actual HTTP responses inspect করুন। এখানে আমাদের debugging redirects and HTTP headers in production guide কাজে লাগবে, কারণ browsers অত্যন্ত ভদ্র: তারা chain follow করে এবং অগোছালো অংশগুলো লুকিয়ে ফেলে।

Launch-এর আগে DNS এবং certificates প্রস্তুত করুন

DNS সরাসরি rankings transfer করে না, কিন্তু খারাপ DNS migration-কে broken দেখাতে পারে। launch window-এর আগে TTL values কমিয়ে দিন, যাতে changes আরও predictably propagate করে। নতুন domain-এ web traffic, email, এবং প্রয়োজনীয় subdomains-এর জন্য সঠিক records আছে কি না নিশ্চিত করুন।

দুই domain-এর জন্য valid TLS certificates-ও দরকার। এটি সহজেই চোখ এড়িয়ে যায়। migration-এর পরও পুরোনো domain-কে HTTPS redirects serve করতে হবে। তার certificate expire করলে users এবং crawlers নতুন site-এ পৌঁছানোর আগেই browser warnings দেখতে পারে।

Move যদি email-কে প্রভাবিত করে, এটিকে afterthought হিসেবে নেবেন না। Domain changes প্রায়ই SPF, DKIM, DMARC, MX records, tracking links, এবং transactional mail ভেঙে দেয়। গুরুত্বপূর্ণ records নিয়ে refresher চাইলে আমাদের developer-friendly guide MX, SPF, DKIM, and DMARC দেখুন।

Canonicals, internal links, এবং sitemaps পরীক্ষা করুন

Launch-এর পর নতুন domain-এর আচরণ এমন হওয়া উচিত, যেন content-এর canonical home সবসময় সেটিই ছিল।

এর মানে:

• Canonical tags পুরোনো domain নয়, নতুন URLs-এ point করে।
• Internal links নতুন domain বা root-relative paths ব্যবহার করে।
• XML sitemaps-এ শুধুমাত্র final, indexable new URLs থাকে।
• hreflang annotations ব্যবহার করলে সেগুলো new URLs reference করে।
• Open Graph, structured data, এবং alternate links update করা হয়।
• Robots.txt গুরুত্বপূর্ণ sections block করে না।

পুরোনো URLs-এ ভরা sitemap publish করে redirects সেটি পরিষ্কার করে দেবে—এমন আশা করবেন না। Sitemap হলো আপনি যেসব URLs indexed চান, সেগুলোর তালিকা। migration-এর পর এর মানে নতুন domain-এর final URLs।

Canonical contradictions-ও লক্ষ্য করুন। যে page পুরোনো থেকে নতুনে redirect করে, কিন্তু canonical আবার পুরোনো domain-এ point করে, সেটি mixed signals পাঠায়। সার্চ ইঞ্জিন সাধারণত কিছু inconsistency সামলে নিতে পারে, কিন্তু তাদের কাছে সেটি চাওয়া উচিত নয়।

Launch day-তে সবকিছু বদলাবেন না

Migration নিজেই যথেষ্ট বড় event। সম্ভব হলে এটিকে major content pruning, template rewrites, navigation changes, JavaScript rendering changes, বা নতুন performance profile-এর সঙ্গে মিলিয়ে করবেন না।

এটি কুসংস্কার নয়। এটি debugging discipline। launch-এর পর rankings কমে গেলে আপনাকে জানতে হবে কারণটি redirect mapping, crawl access, changed content, slower rendering, missing structured data, নাকি অন্য কিছু।

Initial launch যতটা practical, পুরোনো site-এর কাছাকাছি রাখুন। নতুন domain stable হলে বড় editorial এবং design changes ছোট batches-এ করুন।

সার্চ ইঞ্জিনকে জানান কী বদলেছে

Google Search Console-এ পুরোনো এবং নতুন—দুই domain-ই verify করুন। তারপর move যদি domain-level change হয় এবং content নতুন domain-এ যাচ্ছে, তাহলে Change of Address tool ব্যবহার করুন। launch-এর পর নতুন sitemap submit করুন।

এটি redirects-এর বিকল্প নয়। এটি সেগুলোকে support করে। URL-level mapping বোঝার জন্য সার্চ ইঞ্জিনের এখনও crawlable, persistent redirects দরকার।

Bing এবং অন্যান্য সার্চ ইঞ্জিনের ক্ষেত্রে, যেখানে available সেখানে তাদের webmaster tools ব্যবহার করুন। এছাড়া যেসব জায়গা আপনি control করেন সেগুলো update করুন: social profiles, business listings, ad destinations, email footers, documentation, partner links, এবং syndicated content-এ canonical references।

External links সব update হবে না, এবং সেটি ঠিক আছে। কিন্তু সবচেয়ে গুরুত্বপূর্ণগুলো হওয়া উচিত। কোনো major partner, app marketplace, documentation portal, বা press page যদি পুরোনো domain-এ link করে, update চাইুন।

Launch-এর পর সঠিক জিনিস monitor করুন

Migration-এর পর প্রথম কয়েক দিন celebration নয়, active monitoring হওয়া উচিত।

Check করুন:

• পুরোনো এবং নতুন domains-এ crawl activity-এর জন্য server logs
• 404s এবং unexpected 5xx errors
• Redirect chains এবং loops
• Search Console-এ indexing status
• Sitemap discovery এবং processing
• Organic landing pages এবং query patterns
• পুরোনো URLs-এর উপর নির্ভরশীল conversion paths
• Analytics filters এবং referral exclusions

Reporting noise প্রত্যাশা করুন। কিছু analytics tools ঠিকভাবে configure না থাকলে নতুন domain-কে নতুন property হিসেবে ধরে। কিছু dashboards old-domain traffic-এর সঙ্গে new-domain traffic compare করে migration-কে বাস্তবের চেয়ে খারাপ দেখায়।

Search visibility কয়েক সপ্তাহ fluctuate করতে পারে। যা আপনি চান না তা হলো এমন pattern, যেখানে high-value old URLs বারবার crawl হচ্ছে কিন্তু ঠিকভাবে redirected হচ্ছে না, বা new pages discover হচ্ছে কিন্তু old domain-এর duplicates হিসেবে marked হচ্ছে।

Performance-ও উপেক্ষা করা উচিত নয়। নতুন domain যদি heavier templates, broken caching, বা unoptimized assets নিয়ে launch হয়, ব্যবহারকারীরা migration-কে slowdown হিসেবে অনুভব করতে পারে। আপনি checks-এর অংশ হিসেবে Lighthouse ব্যবহার করলে priorities মাথায় রেখে পড়ুন; আমাদের how to read a Lighthouse report without panicking লেখা meaningful issues থেকে noise আলাদা করতে সাহায্য করে।

পুরোনো domain দীর্ঘ সময় ধরে রাখুন

Migration “works” করার পর পুরোনো domain expire হতে দেবেন না। যতদিন সম্ভব সেটি registered রাখুন, certificates valid রাখুন, এবং redirects চালু রাখুন। বাস্তবে, এর মানে প্রায়ই কয়েক বছর।

পুরোনো links blog posts, bookmarks, documentation, PDFs, emails, এবং social posts-এ থেকে যায়। Redirects হলো সেই historical footprint এবং নতুন domain-এর মধ্যে bridge। খুব তাড়াতাড়ি সেগুলো বন্ধ করলে users-এর paths ভেঙে যায় এবং জমা হওয়া signals নষ্ট হয়।

আপনার redirect map এবং launch notes-এর একটি copy-ও রাখুন। ছয় মাস পরে কেউ যখন জিজ্ঞেস করবে একটি legacy URL কেন নির্দিষ্টভাবে behave করছে, তখন documentation রাখার জন্য আপনি খুশি হবেন।

<!-- tool-cta:start -->

💡 এটি চেষ্টা করুন: কাটওভারের পরে, আপনার পুরোনো URLগুলো Redirect Checker দিয়ে ট্রেস করুন, যাতে নিশ্চিত করা যায় যে প্রতিটি সঠিক নতুন পৃষ্ঠায় একটি মাত্র 301 হপে রিজলভ হচ্ছে।

<!-- tool-cta:end -->

একটি বাস্তবসম্মত migration checklist

Launch-এর আগে:

• Search Console-এ দুই domain-ই verify করুন।
• বর্তমান site crawl করুন এবং গুরুত্বপূর্ণ URLs export করুন।
• One-to-one redirect map তৈরি করুন।
• DNS TTLs কমিয়ে দিন।
• পুরোনো এবং নতুন domains-এর জন্য TLS certificates প্রস্তুত করুন।
• Canonicals, internal links, hreflang, structured data, এবং sitemaps update করুন।
• Staging বা controlled environment-এ redirects test করুন।

Launch day-তে:

• Redirects deploy করুন।
• HTTP থেকে HTTPS behavior confirm করুন।
• প্রতিটি template type থেকে গুরুত্বপূর্ণ URL samples test করুন।
• নতুন sitemap submit করুন।
• যেখানে appropriate, Change of Address tool ব্যবহার করুন।
• Server errors, redirect loops, এবং blocked resources নজরে রাখুন।

Launch-এর পর:

• Crawl errors এবং indexing reports monitor করুন।
• যেখানে পারেন গুরুত্বপূর্ণ external links update করুন।
• শুধু domain totals নয়, landing page intent অনুযায়ী traffic compare করুন।
• Redirects অনির্দিষ্টকাল live রাখুন।
• Move stable না হওয়া পর্যন্ত unrelated redesign বা content experiments delay করুন।

Domain migrations risk-free নয়, কিন্তু manageable। Migration যখন unclear signals পাঠায়—missing redirects, changed content, contradictory canonicals, blocked crawlers, বা ভুলে যাওয়া old domain—তখন সাধারণত rankings ক্ষতিগ্রস্ত হয়। সার্চ ইঞ্জিন এবং users-কে একটি পরিষ্কার map দিন, এবং move অনেক কম dramatic হয়ে উঠবে।