Website Redesign-এর সময় SEO Traffic রক্ষা করার পদ্ধতি

নতুন ডিজাইন চালুর পর গুরুত্বপূর্ণ landing page হঠাৎ Google Search থেকে হারিয়ে যেতে পারে। এর প্রভাব শুধু ranking-এ সীমিত থাকে না; lead, বিক্রি এবং বিজ্ঞাপননির্ভর প্রকাশনার আয়ও কমতে পারে।

Website redesign SEO-এর মূল লক্ষ্য তাই শুধু নতুন theme, layout বা CMS চালু করা নয়। পুরোনো সাইটের গুরুত্বপূর্ণ URL, content, internal link, canonical, metadata এবং indexability যেন নতুন সংস্করণে সঠিকভাবে স্থানান্তরিত হয়, সেটিই প্রধান কাজ।

ঝুঁকি কমাতে redesign শুরুর আগে বর্তমান performance-এর baseline নিতে হবে, সব গুরুত্বপূর্ণ URL-এর তালিকা করতে হবে এবং ঠিকানা বদলালে প্রতিটির নতুন destination নির্ধারণ করতে হবে। Server-side permanent redirect, সঠিক sitemap, production canonical এবং launch-এর পর নিয়মিত monitoring—সবই একই migration plan-এর অংশ।

প্রথমে বুঝুন কোন ধরনের পরিবর্তন হচ্ছে

সব website redesign-এর ঝুঁকি এক নয়। একটি সাইটে শুধু রং ও layout বদলানো হতে পারে, আরেকটিতে domain, CMS এবং URL structure একসঙ্গে পাল্টে যেতে পারে। কাজের ধরন আগে নির্ধারণ না করলে অপ্রয়োজনীয় redirect, duplicate URL বা indexing সমস্যা তৈরি হয়।

Design-only redesign: URL এবং মূল content একই থাকবে। পরিবর্তন হবে theme, typography, menu বা page layout-এ।

Platform migration: CMS, hosting, JavaScript framework, rendering system বা database architecture বদলাবে।

URL migration: domain, subdomain, protocol, folder structure, permalink বা slug পরিবর্তিত হবে।

শুধু hosting provider বা CDN বদলালেও user-visible URL একই থাকলে Google সেটিকে URL migration হিসেবে বিবেচনা করে না। এ ধরনের পরিবর্তনে DNS, server capacity, crawl access এবং পুরোনো ও নতুন server-এর traffic পর্যবেক্ষণ বেশি গুরুত্বপূর্ণ।

URL বদলালে প্রস্তুতিও বাড়ে। তখন old-to-new URL mapping, permanent redirect, canonical update, internal link সংশোধন এবং Search Console monitoring প্রয়োজন হয়।

সম্ভব হলে একবারে একটি বড় পরিবর্তন করুন

একই launch-এ domain, CMS, design, navigation এবং content বদলানো প্রকল্প ব্যবস্থাপনার দিক থেকে সুবিধাজনক মনে হতে পারে। কিন্তু traffic কমলে কোন পরিবর্তনটি সমস্যা তৈরি করেছে, তা আলাদা করা কঠিন হয়।

Google বড় site change পর্যায়ক্রমে করার পরামর্শ দেয়। যেমন, আগে domain migration শেষ করে পরে layout পরিবর্তন করা যেতে পারে।

সব প্রকল্পে আলাদা launch সম্ভব নয়। তখন অন্তত দুটি বিষয় ধরে রাখুন:

১. উচ্চ traffic, backlink বা conversion পাওয়া page-এর মূল content ও search intent launch-এর সময় বড়ভাবে বদলাবেন না।

২. URL পরিবর্তন বাধ্যতামূলক না হলে পুরোনো URL রাখুন।

শুধু URL দেখতে পরিষ্কার করার জন্য index করা শত শত page-এর slug বদলে দেওয়া সাধারণত ভালো সিদ্ধান্ত নয়। প্রতিটি পরিবর্তিত ঠিকানার জন্য redirect, testing, recrawling এবং monitoring দরকার হবে।

রিডিজাইনের আগে একটি পরিষ্কার SEO baseline নিন

Launch-এর পর “traffic কমেছে” জানা যথেষ্ট নয়। কোন template, query, device, country বা landing page ক্ষতিগ্রস্ত হয়েছে, সেটি চিহ্নিত করতে আগের data সংরক্ষণ করতে হবে।

কমপক্ষে নিচের তথ্যগুলো রাখুন:

• organic clicks, impressions, CTR এবং average position
• organic landing page, lead, conversion ও revenue
• গুরুত্বপূর্ণ query, country ও device data
• XML sitemap, robots.txt এবং বিদ্যমান redirect rules
• canonical, title, H1, robots meta ও structured data
• backlink পাওয়া গুরুত্বপূর্ণ page
• representative template-এর HTTP status
• সম্ভব হলে server log থেকে crawler activity

Search Console-এর Performance report-এ query, page, country এবং device অনুযায়ী data তুলনা করা যায়। Seasonality থাকা সাইটে শুধু আগের ২৮ দিনের সঙ্গে তুলনা করলে ভুল ধারণা হতে পারে। দীর্ঘ date range এবং আগের বছরের একই সময়ের data দেখলে পরিবর্তনটি migration-এর কারণে হয়েছে, নাকি স্বাভাবিক মৌসুমি ওঠানামা—তা বুঝতে সুবিধা হয়।

সব তথ্য একটি URL-কেন্দ্রিক spreadsheet-এ রাখুন। Launch-এর পর একই sheet-এ status code, redirect destination, canonical, indexing এবং traffic update করা যাবে।

পুরোনো সাইটের পূর্ণ URL inventory তৈরি করুন

শুধু XML sitemap export করলে সব দরকারি URL পাওয়া নাও যেতে পারে। Orphan page, পুরোনো campaign landing page, archived content, media URL বা backlink পাওয়া page sitemap-এর বাইরে থাকতে পারে।

URL সংগ্রহ করুন:

• XML sitemap থেকে
• CMS বা database export থেকে
• website crawler-এর ফলাফল থেকে
• analytics-এর organic landing page report থেকে
• Search Console-এর page ও link data থেকে
• backlink report থেকে
• server access log থেকে

Image, video, PDF, JavaScript এবং CSS-এর URL-ও migration plan-এ প্রয়োজন হতে পারে। বিশেষ করে CDN, media folder বা asset hostname বদলালে এসব URL বাদ দেওয়া যাবে না।

এরপর URL-গুলোকে গুরুত্ব অনুযায়ী ভাগ করুন। Traffic, conversion, backlink এবং ব্যবসায়িক গুরুত্ব পাওয়া page আগে সুরক্ষিত করুন। Developer, content team এবং SEO team-এর জন্য আলাদা তালিকা না রেখে একটি master inventory ব্যবহার করাই বাস্তবসম্মত।

URL mapping-এ প্রতিটি পুরোনো ঠিকানার সিদ্ধান্ত রাখুন

URL বদলালে প্রতিটি পুরোনো page কোথায় যাবে, তা launch-এর আগেই ঠিক করুন। Mapping sheet-এ শুধু old URL ও new URL থাকলে কাজ অসম্পূর্ণ থেকে যায়।

সমমানের নতুন page থাকলে পুরোনো URL সরাসরি সেই destination-এ redirect করুন। একাধিক পুরোনো article সত্যিই একটি বিস্তৃত নতুন guide-এ একীভূত হলে সেগুলো ওই consolidated page-এ নেওয়া যায়।

অপ্রাসঙ্গিক শত শত URL homepage-এ redirect করা ঠিক নয়। ব্যবহারকারী প্রত্যাশিত content পায় না এবং Google এ ধরনের redirect-কে soft 404 হিসেবে বিবেচনা করতে পারে।

সমমানের replacement না থাকলে সঠিক 404 বা 410 response দিন। Error message দেখিয়েও server থেকে 200 status পাঠালে সেটি soft 404 পরিস্থিতি তৈরি করতে পারে।

301 Redirect ঠিকভাবে বসান

স্থায়ী URL পরিবর্তনের জন্য server-side 301 বা 308 Redirect ব্যবহার করুন। Google permanent redirect-কে destination URL canonical হওয়ার একটি শক্তিশালী signal হিসেবে দেখে।

302, 303 ও 307 temporary redirect। স্থায়ী migration-এ এগুলো default হওয়া উচিত নয়।

পুরোনো URL সরাসরি final destination-এ পাঠান:

Old URL → Final New URL

নিচের ধরনের chain এড়িয়ে চলুন:

Old URL → Intermediate URL → Another URL → Final URL

একাধিক redirect অনুসরণ করা সম্ভব হলেও chain page load ধীর করে, crawl process জটিল করে এবং ভবিষ্যতে troubleshooting কঠিন করে দেয়।

Server-side redirect সম্ভব না হলে instant meta refresh একটি বিকল্প। JavaScript redirect শেষ বিকল্প হিসেবে রাখা ভালো, কারণ rendering ব্যর্থ হলে crawler সেটি নাও দেখতে পারে।

Launch-এর আগে batch testing করে দেখুন:

• সঠিক 301 বা 308 status আসছে কি না
• destination প্রাসঙ্গিক কি না
• redirect loop বা chain আছে কি না
• final URL 200 status দিচ্ছে কি না
• query parameter বা trailing slash হারাচ্ছে কি না
• mobile ও desktop request একই ফল দিচ্ছে কি না

Google redirects যত দিন সম্ভব এবং সাধারণভাবে অন্তত এক বছর রাখার পরামর্শ দেয়। পুরোনো bookmark, backlink ও নিয়মিত ফিরে আসা ব্যবহারকারীর কথা বিবেচনা করলে অনেক redirect আরও দীর্ঘ সময় রাখা যুক্তিযুক্ত।

Content এবং on-page signal যেন হারিয়ে না যায়

Redesign-এর সময় page পরিষ্কার করতে গিয়ে মূল text, heading, comparison table, FAQ বা supporting section বাদ দিলে URL একই থাকলেও page-এর অর্থ বদলে যেতে পারে।

গুরুত্বপূর্ণ template-এ মিলিয়ে দেখুন:

• title ও meta description
• H1 এবং heading hierarchy
• primary body content
• image alt text
• internal link ও anchor text
• self-referencing canonical
• robots meta
• structured data
• hreflang
• pagination
• image, video ও PDF link

নতুন URL-এর canonical নতুন URL-কেই নির্দেশ করতে হবে। Redirect, rel=”canonical” এবং sitemap signal একই destination দেখালে preferred URL বোঝানো সহজ হয়। তবে চূড়ান্ত canonical Google নিজেই নির্বাচন করতে পারে।

High-performing page-এর content rewrite এবং technical migration একই release-এ না করাই নিরাপদ। আগে migration স্থিতিশীল করুন, তারপর content improvement আলাদা পর্যায়ে নিন।

Staging site ভুল করে index হতে দেবেন না

Development বা staging site public internet-এ উন্মুক্ত থাকলে duplicate URL index হওয়ার ঝুঁকি থাকে। Password protection বা IP-restricted access সাধারণত সবচেয়ে পরিষ্কার ব্যবস্থা।

Public testing প্রয়োজন হলে crawlable page-এ noindex ব্যবহার করা যায়। তবে শুধু robots.txt দিয়ে staging site search result থেকে লুকানোর চেষ্টা করবেন না। Robots.txt crawling নিয়ন্ত্রণ করে; indexing বন্ধ করার নিশ্চয়তা দেয় না।

আরও গুরুত্বপূর্ণ হলো, robots.txt দিয়ে page block করা থাকলে crawler ওই page-এর noindex tag দেখতেও পারবে না। তাই noindex ব্যবহার করলে page crawler-এর কাছে accessible থাকতে হবে।

Launch-এর আগে নিশ্চিত করুন:

• staging-এর noindex সরানো হয়েছে
• production robots.txt-এ accidental Disallow: / নেই
• canonical staging domain দেখাচ্ছে না
• password বা IP restriction production থেকে সরানো হয়েছে
• test analytics ও test API endpoint বদলানো হয়েছে

Production launch-এর সময় এই তালিকার একটি ভুলই পুরো সাইটের organic visibility ক্ষতিগ্রস্ত করতে পারে।

Mobile ও JavaScript output পরীক্ষা করুন

Google indexing ও ranking-এর জন্য mobile version-এর content ব্যবহার করে। Mobile এবং desktop version আলাদা হলে primary content, headings, title, robots meta, images এবং structured data-এর গুরুত্বপূর্ণ অংশ সমমানের হওয়া দরকার।

Primary content এমনভাবে lazy-load করবেন না, যাতে swipe, click বা typing না করা পর্যন্ত content load না হয়। User interaction ছাড়া crawler content দেখতে না পারলে সেটি indexing-এ ধরা নাও পড়তে পারে।

JavaScript framework বদলালে browser-এ page ঠিক দেখাচ্ছে বলেই কাজ শেষ ধরে নেবেন না। URL Inspection Tool বা Rich Results Test-এ rendered HTML দেখে নিশ্চিত করুন যে title, canonical, text, links এবং structured data crawler-এর কাছে দৃশ্যমান।

Launch-এর আগে ও launch day-তে যা পরীক্ষা করবেন

Launch-এর আগে

• database, media ও configuration backup নিন
• URL mapping ও redirect rules অনুমোদন করুন
• production robots.txt এবং XML sitemap প্রস্তুত রাখুন
• noindex, staging canonical ও temporary restriction সরানোর দায়িত্ব নির্ধারণ করুন
• analytics, consent setup এবং conversion event পরীক্ষা করুন
• mobile ও desktop template crawl করুন
• 404, 5xx, form, checkout ও lead journey পরীক্ষা করুন
• rollback plan তৈরি করুন

Launch-এর সঙ্গে সঙ্গে

• DNS, SSL ও preferred hostname পরীক্ষা করুন
• homepage, category, article, product ও form template 200 status দিচ্ছে কি না দেখুন
• old URL থেকে relevant new URL-এ 301/308 যাচ্ছে কি না পরীক্ষা করুন
• canonical production URL দেখাচ্ছে কি না নিশ্চিত করুন
• robots.txt গুরুত্বপূর্ণ page, CSS বা JavaScript block করছে কি না দেখুন
• internal link final URL-এ update করুন
• নতুন sitemap Search Console-এ submit করুন
• analytics ও conversion tracking data আসছে কি না যাচাই করুন
• server log-এ unexpected 4xx বা 5xx response খুঁজুন

Domain বদলালে পুরোনো ও নতুন Search Console properties verify করে Change of Address submit করুন। HTTP থেকে HTTPS migration-এর জন্য Change of Address tool ব্যবহার করতে হয় না।

Sitemap ও internal link update করুন

নতুন XML sitemap-এ canonical, indexable এবং সফল response দেওয়া URL রাখুন। Redirected, noindex, 404 বা duplicate URL নতুন sitemap-এ না রাখাই পরিষ্কার পদ্ধতি।

Sitemap search engine-কে গুরুত্বপূর্ণ URL আবিষ্কার করতে সাহায্য করে। তবে sitemap-এ URL থাকা মানেই সেটি crawl বা index হবে, এমন নিশ্চয়তা নেই।

পুরোনো sitemap launch-এর পর সরিয়ে ফেলা যায়। তবে কিছু migration-এ old ও new sitemap-এর indexed count তুলনা করে transition পর্যবেক্ষণ করা সুবিধাজনক হতে পারে। এটি বাধ্যতামূলক ধাপ নয়। যেকোনো অবস্থায় old URL list, mapping sheet এবং crawl export আলাদা করে সংরক্ষণ করুন।

Redirect থাকলেও internal links পুরোনো URL-এ রেখে দেবেন না। Navigation, breadcrumbs, body links, related content, footer, hreflang, structured data এবং media reference-এ final URL ব্যবহার করুন।

Launch-এর পর monitoring কীভাবে করবেন

নিচের সময়সীমা কোনো বাধ্যতামূলক Google rule নয়। এটি একটি ব্যবহারিক monitoring schedule। সাইটের আকার, crawl rate এবং migration-এর ঝুঁকি অনুযায়ী সময় বদলাতে পারে।

প্রথম ২৪–৭২ ঘণ্টা: server outage, 5xx, robots block, noindex, redirect failure, canonical error, tracking এবং গুরুত্বপূর্ণ landing page পরীক্ষা করুন।

প্রথম ৩০ দিন: clicks, impressions, indexed pages, queries, landing pages, devices এবং conversions তুলনা করুন।

পরবর্তী ২–৩ মাস: high-value URL, external link, old-to-new transition, crawl pattern এবং persistent traffic gap পর্যবেক্ষণ করুন।

URL migration-এর সময় ranking fluctuation হতে পারে। ছোট বা মাঝারি সাইটের বেশির ভাগ page process হতে কয়েক সপ্তাহ লাগতে পারে; বড় সাইটে আরও সময় প্রয়োজন হতে পারে। এটিকে নির্দিষ্ট recovery deadline হিসেবে দেখা যাবে না।

Site-wide সমস্যা হলে Search Console-এর Page indexing report দেখুন। নির্দিষ্ট কয়েকটি page ক্ষতিগ্রস্ত হলে URL Inspection Tool ব্যবহার করুন।

ট্রাফিক কমলে কোথা থেকে তদন্ত শুরু করবেন

নিচের pattern-গুলো নিশ্চিত কারণ নয়। এগুলো সম্ভাব্য সমস্যার জায়গা সংকুচিত করতে সাহায্য করে।

বেশির ভাগ page একসঙ্গে কমেছে: robots.txt, noindex, server availability, tracking, canonical hostname, security issue এবং site-wide template পরীক্ষা করুন।

শুধু পরিবর্তিত URL কমেছে: redirect mapping, final destination, redirect chain, canonical, sitemap ও internal link দেখুন।

একটি নির্দিষ্ট template কমেছে: title, H1, content parity, mobile rendering, structured data, pagination এবং status code পরীক্ষা করুন।

Impressions স্থিতিশীল, clicks কমেছে: title, snippet, ranking position, query intent এবং search result presentation পর্যালোচনা করুন।

Analytics traffic কম, Search Console clicks স্থিতিশীল: analytics tag, consent configuration, redirect-এর পর tracking, channel grouping ও reporting setup পরীক্ষা করুন। Search Console ও analytics-এর metric এক নয়, তাই দুটি report হুবহু মিলবে না।

প্রতিটি সমস্যার জন্য issue log রাখুন। সেখানে affected URL, প্রথম শনাক্তের সময়, সম্ভাব্য কারণ, owner, fix, deployment time এবং ফলাফল লিখুন। একই সময়ে অনেক পরিবর্তন করলে কোন fix কাজ করেছে, তা বোঝা কঠিন হয়।

যে ভুলগুলো বেশি ক্ষতি করে

• SEO team-কে launch-এর শেষ পর্যায়ে যুক্ত করা
• crawl না করে শুধু menu থেকে URL mapping বানানো
• অপ্রাসঙ্গিক URL homepage-এ redirect করা
• staging-এর noindex production-এ রেখে দেওয়া
• canonical-এ staging বা পুরোনো domain রাখা
• mobile version থেকে মূল content বাদ দেওয়া
• migration-এর সঙ্গে site-wide content rewrite করা
• 301 বসিয়ে internal link update না করা
• নতুন sitemap-এ redirected বা non-indexable URL রাখা
• analytics ও conversion tracking পরীক্ষা না করা
• error page দেখিয়েও 200 status পাঠানো
• redirects অল্প সময়ের মধ্যে বন্ধ করা
• server capacity ও crawler activity না দেখা
• শুধু ranking tracker দেখে সিদ্ধান্ত নেওয়া

Design approval-এর আগেই SEO sign-off নিন

Website redesign SEO-এর বড় সিদ্ধান্তগুলো launch day-তে নেওয়ার কথা নয়। Design mockup অনুমোদনের সময়ই URL policy, content preservation, mobile parity, redirect mapping, crawlability, server capacity এবং measurement plan চূড়ান্ত করা দরকার।

ছোট সাইটে একটি shared spreadsheet দিয়েই URL mapping ও launch status পরিচালনা করা সম্ভব। বড় publisher, e-commerce বা multilingual site-এ automated crawl, redirect testing, log analysis এবং staged rollout প্রয়োজন হতে পারে।

শুরু করার সবচেয়ে বাস্তব উপায় হলো বর্তমান সাইট crawl করে একটি master URL inventory বানানো। সেখানে old URL, proposed URL, traffic priority, canonical, redirect destination, status এবং launch verification রাখুন। এই নথিই redesign-এর সময় SEO ট্রাফিক রক্ষার প্রধান নিয়ন্ত্রণপত্র।

শেষ কথা

ওয়েবসাইট রিডিজাইনের সময় SEO ট্রাফিক রক্ষা করতে সবচেয়ে কার্যকর সিদ্ধান্ত হলো—ডিজাইন কাজ শুরুর আগেই URL, content, redirects, canonical এবং tracking-এর দায়িত্ব স্পষ্ট করা। Launch-এর পরে ভুল খুঁজে ঠিক করার চেয়ে আগে থেকেই migration plan তৈরি করা কম ঝুঁকিপূর্ণ এবং বেশি সাশ্রয়ী।

Website redesign SEO-কে আলাদা কোনো শেষ মুহূর্তের checklist হিসেবে দেখলে গুরুত্বপূর্ণ বিষয় বাদ পড়ে যেতে পারে। এটিকে design, development এবং content workflow-এর অংশ করুন। প্রথম পদক্ষেপ হিসেবে বর্তমান সাইটের একটি পূর্ণ URL inventory তৈরি করুন এবং প্রতিটি গুরুত্বপূর্ণ page নতুন সাইটে কোথায় থাকবে, তা লিখিতভাবে নির্ধারণ করুন। এই নথি ঠিক থাকলে launch-এর পর সমস্যা শনাক্ত ও সমাধান করা অনেক সহজ হবে।

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

URL না বদলালে কি 301 Redirect দরকার?

একই URL-এ নতুন design বা CMS content পরিবেশন করলে সাধারণত 301 Redirect প্রয়োজন হয় না। তবে protocol, hostname, trailing slash, uppercase বা URL parameter-এর আচরণ বদলেছে কি না পরীক্ষা করতে হবে।

Redesign-এর পর traffic সাময়িকভাবে কমা কি স্বাভাবিক?

URL বদলালে Google নতুন page crawl ও process করার সময় কিছু ranking fluctuation হতে পারে। তবে বড় traffic drop-কে স্বাভাবিক ধরে অপেক্ষা করবেন না। Robots, noindex, redirects, canonical, 404, 5xx, content parity এবং tracking দ্রুত পরীক্ষা করুন।

সব পুরোনো URL homepage-এ redirect করা যাবে?

না। Destination প্রাসঙ্গিক না হলে এমন redirect soft 404 হিসেবে বিবেচিত হতে পারে। সমমানের replacement না থাকলে proper 404 বা 410 response বেশি সঠিক।

Domain বদলালে Search Console-এ কী করতে হবে?

পুরোনো ও নতুন properties verify করুন, server-side permanent redirects চালু ও পরীক্ষা করুন, নতুন sitemap submit করুন এবং পুরোনো property থেকে Change of Address ব্যবহার করুন। HTTP থেকে HTTPS পরিবর্তনের জন্য Change of Address দরকার হয় না।