WordPress থেকে Next.js-এ মাইগ্রেশন: আসলে কী কী লাগে

ওয়েবের একটা বড় অংশ WordPress চালায়, আর অনেক কিছুই ভালো করে। Next.js দ্রুততর, ডেভেলপারদের জন্য রক্ষণাবেক্ষণযোগ্য, আর নতুন কাজের জন্য ক্রমশ টিমগুলোর পছন্দ।

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

প্রথমে: যাওয়া উচিত কি?

যাবেন না যদি:

• আপনার সাইট চলছে আর কারিগরি নন এমন মানুষ স্বচ্ছন্দে হালনাগাদ করছেন। WordPress-এর এডিটর সত্যিই ভালো। আপনার টিম যদি সাহায্য ছাড়াই প্রকাশ করতে পারে, তার মূল্য যেকোনো পারফরম্যান্স স্কোরের চেয়ে বেশি।
• সাইট ধীর, কিন্তু আপনি সেটি ঠিক করার চেষ্টা করেননি। বেশিরভাগ ধীর WordPress সাইট ধীর ক্যাশ না থাকা, পুরোনো PHP আর অপ্টিমাইজ না করা ছবির কারণে — দেখুন WordPress দ্রুত করার গাইড। সেটি ঠিক করা একদিনের কাজ। মাইগ্রেশন কয়েক মাসের। আগে একদিনেরটা চেষ্টা করুন।
• এমন প্লাগইনের ওপর নির্ভরশীল, যার বিকল্প নেই। জটিল WooCommerce ব্যবস্থা, মেম্বারশিপ সিস্টেম, এলএমএস প্ল্যাটফর্ম। ওগুলো নতুন করে বানানো মাইগ্রেশন নয়, নতুন করে লেখা।
• আপনার ডেভেলপার নেই। Next.js রক্ষণাবেক্ষণ করার মতো কাউকে দরকার। WordPress-এর দরকার নেই।

যান যদি:

• ডেভেলপারের গতিই বাধা। আপনার টিম যা বানায় তার চেয়ে বেশি সময় সিএমএসের সঙ্গে লড়ে।
• আপনার সত্যিকারের একটি অ্যাপ্লিকেশন দরকার, অ্যাপ্লিকেশন জুড়ে দেওয়া একটি সাইট নয়।
• একই কনটেন্ট সাইটে, অ্যাপে আর কিয়স্কে চান। হেডলেস ঠিক এ কারণেই আছে।
• এমন পারফরম্যান্স সীমায় পৌঁছেছেন, যা ক্যাশিং দিয়ে ওঠানো যাচ্ছে না।
• নিরাপত্তা রক্ষণাবেক্ষণ বোঝা হয়ে দাঁড়িয়েছে। প্লাগইনের দুর্বলতাই ছোট সাইট আক্রান্ত হওয়ার সবচেয়ে প্রচলিত কারণ, আর স্ট্যাটিক বা সার্ভার-রেন্ডার করা ফ্রন্ট এন্ড ওই গোটা পৃষ্ঠটাই মুছে দেয়।

এই ধাপে সৎ থাকুন। "আমাদের সাইট আরও দ্রুত হওয়া উচিত" — মাইগ্রেশনের খরচের মুখোমুখি হয়ে এই যুক্তি খুব কমই টেকে।

মাইগ্রেশনের দুটি ধরন

হেডলেস — WordPress থাকুক এডিটর হিসেবে

WordPress থেকে যায়, জনসাধারণের চোখের আড়ালে। Next.js REST বা GraphQL এপিআই দিয়ে সেখান থেকে কনটেন্ট আনে আর ফ্রন্ট এন্ড রেন্ডার করে।

ভালো কারণ: আপনার এডিটররা পরিচিত ইন্টারফেসেই থাকেন, কনটেন্ট সামলানো প্লাগইনগুলো এখনো চলে, আর মাইগ্রেশনটা কেবল ফ্রন্ট-এন্ডের।

খরচ: এখন আপনি দুটি ব্যবস্থা চালাচ্ছেন। WordPress-এর এখনো হোস্টিং, আপডেট আর নিরাপত্তা লাগে — এটি জনসাধারণের জন্য নয়, কিন্তু আছে তো।

পূর্ণ মাইগ্রেশন — WordPress পেছনে ফেলে আসা

কনটেন্ট চলে যায় আধুনিক সিএমএসে — Payload, Sanity, Contentful, বা রিপোজিটরির ফাইলে — আর WordPress বন্ধ করে দেওয়া হয়।

ভালো কারণ: একটিই ব্যবস্থা, PHP নেই, প্লাগইন আপডেট নেই, আর কনটেন্ট আপনার নিজের নকশা করা কাঠামোয়।

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

কোনটি বাছবেন: সম্পাদনা দল বড় বা অনিচ্ছুক হলে হেডলেস, দল ছোট ও কারিগরি হলে পূর্ণ মাইগ্রেশন। হেডলেস একটি বৈধ সিঁড়িও — আগে ফ্রন্ট এন্ড সরান, ফ্রন্ট এন্ড স্থিতিশীল হলে পরে ব্যাকএন্ড বদলান।

যে ধাপটি ঠিক করে দেয় আপনি ট্র্যাফিক ধরে রাখবেন কি না

এই পাতার বাকি সবই প্রকৌশল। এই অংশটাই ঠিক করে প্রকল্পটি সাফল্য হবে, নাকি সম্মেলনে বলা একটি গল্প।

প্রতিটি বিদ্যমান URL-কে কাজ করতে হবে — একই ঠিকানায়, নয়তো তার হুবহু সমতুল্যে ৩০১ রিডাইরেক্ট দিয়ে।

হোমপেজে নয়। ক্যাটাগরি পাতায় নয়। সমতুল্য পাতাটিতে। সবকিছুকে গণহারে /-এ রিডাইরেক্ট করাই কোনো সাইটের সার্চ পারফরম্যান্স ধ্বংস করার সবচেয়ে কার্যকর উপায়, আর রিডাইরেক্ট প্রকল্পের শেষে ফেলে রেখে তাড়াহুড়ো করে করলে এটাই ঘটে।

এভাবে করুন:

1. শুরুর আগেই ইনডেক্স হওয়া প্রতিটি URL রপ্তানি করুন। Search Console, আপনার সাইটম্যাপ, অ্যানালিটিক্স, আর Screaming Frog বা সমমানের কিছু দিয়ে একটি ক্রল। সবগুলো মিলিয়ে নিন — প্রতিটি উৎস এমন URL জানে যা অন্যরা জানে না।
2. প্রতিটিকে মানচিত্রে বসান তার নতুন ঠিকানায়। স্লাগ ধরে রাখলে বেশিরভাগই যান্ত্রিক।
3. সম্ভব হলে URL কাঠামো ধরে রাখুন। সেরা রিডাইরেক্ট সেটাই, যেটির দরকারই হয়নি। /2019/03/post-name-কে /blog/post-name করা মানে একই সঙ্গে আপনার URL পরিসরের নতুন নকশা এবং একটি মাইগ্রেশন — করতেই হলে আলাদা আলাদা করুন।
4. ভুলবেন না ফিড, অ্যাটাচমেন্ট পাতা, পেজিনেটেড আর্কাইভ, ক্যাটাগরি ও ট্যাগ পাতা, আর পুরোনো ছবির URL।
5. লঞ্চের পর যাচাই করুন, ক্লিক করে নয়, ক্রলার দিয়ে। ওই রিপোর্টের প্রতিটি ৪০৪ মানে একটি হারানো পাতা।

সেই সঙ্গে: প্রথম দিন থেকেই robots.txt ও সাইটম্যাপ ঠিক রাখুন, আর প্রথম পক্ষকাল প্রতিদিন Search Console দেখুন। Google আবার ক্রল করার সময় র‍্যাঙ্কিংয়ে কিছু ওঠানামা স্বাভাবিক। খাড়া পতন স্বাভাবিক নয়, আর তার কারণ সাধারণত রিডাইরেক্ট।

কনটেন্ট সরানো

সাধারণ পথ WordPress REST এপিআই:

curl "https://oldsite.com/wp-json/wp/v2/posts?per_page=100&page=1&_embed"

_embed একই উত্তরে লেখক, ফিচার্ড ছবি আর টার্মগুলো নিয়ে আসে, যা অনেক বাড়তি অনুরোধ বাঁচায়।

মানুষ যা কম গুরুত্ব দেয়:

post_content-এর ভেতরের HTML। WordPress রেন্ডার করা HTML জমা রাখে, সঙ্গে শর্টকোড, ব্লক কমেন্ট আর এক দশকের এডিটরের ইনলাইন স্টাইল। সেটিকেই আপনার নতুন সিএমএস যা ব্যবহার করে তাতে রূপান্তর করতে হবে। এর জন্য সত্যিকারের সময় রাখুন — সাধারণত এটিই সবচেয়ে বড় একক কাজ।

ছবি। নামিয়ে নিজে হোস্ট করুন; পুরোনো ডোমেইনের দিকে দেখিয়ে রাখবেন না, নইলে সেটি কখনো বন্ধ করতে পারবেন না। যেহেতু প্রতিটি ছবিতেই হাত দিচ্ছেন, সঙ্গে সঙ্গে WebP-তে রূপান্তরও করে নিন।

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

⚠ যে কনটেন্ট সরাচ্ছেন সেটি পড়ুন। এই সাইটের নিজের আর্কাইভ সরানোর সময় আমরা দেখেছিলাম WordPress ডেটাবেসটি লিংক-ইনজেকশন এসইও স্প্যামারের হাতে আক্রান্ত: সাধারণ লেখার মতো দেখাতে স্টাইল করা পঁচিশটি ছদ্মবেশী লিংক, চোদ্দটি নিবন্ধে গুঁজে দেওয়া, জুয়া আর অ্যাফিলিয়েট ডোমেইনের দিকে নির্দেশ করা। একটি নিবন্ধে পরপর পাঁচটি বানানো অনুচ্ছেদ ছিল, যা সম্পর্কহীন একটি কোম্পানির সুপারিশ করত। যে মাইগ্রেশন post_content বিশ্বস্তভাবে কপি করে, সে এসবও নতুন সাইটে কপি করে নেয়। আক্রান্ত WordPress ডেটাবেস সাধারণ ঘটনা, আর মাইগ্রেশনই একমাত্র মুহূর্ত যখন আপনি প্রতিটি নিবন্ধ চোখে দেখবেন। সুযোগটা নষ্ট করবেন না।

যা নতুন করে বানাতে হবে

WordPress যা বিনামূল্যে দিত, এখন সেগুলো আপনার:

আলাদাভাবে কোনোটিই কঠিন নয়। একসঙ্গে এগুলোই সেই অংশ, যা হিসাব থেকে সবসময় বাদ পড়ে — আর এ কারণেই মাইগ্রেশন সময় ছাড়িয়ে যায়।

দুটির কথা আলাদা করে বলা দরকার:

এসইও মেটাডেটা। Yoast অনেক ছোট ছোট জিনিস ঠিকভাবে করে। ক্যাননিক্যাল, Open Graph, বহুভাষিক হলে hreflang, আর বৈধ স্ট্রাকচার্ড ডেটা — সবই নতুন করে বানাতে হবে, আর শেষেরটিতে সূক্ষ্ম ভুল করা সহজ। কাজ করার তালিকাটি হলো টেকনিক্যাল এসইও চেকলিস্ট।

স্প্যাম সুরক্ষা। উন্মুক্ত একটি ফর্ম এন্ডপয়েন্ট কয়েক দিনের মধ্যেই বটেরা খুঁজে পায়। কেবল ভ্যালিডেশন নয়, একটি বট চেক আর হানিপট দরকার।

একটি বাস্তব ক্রম

1. অডিট। প্রতিটি URL, প্রতিটি প্লাগইন, প্রতিটি কনটেন্ট টাইপ, প্রতিটি ইন্টিগ্রেশন। আপনার আসলে কী আছে তা জানতে দুই সপ্তাহ।
2. হেডলেস না পূর্ণ — সিদ্ধান্ত নিন।
3. বিদ্যমান WordPress এপিআইয়ের বিপরীতে ফ্রন্ট এন্ড বানান। এখনো কিছুই লাইভ নয়।
4. পূর্ণ মাইগ্রেশন করলে কনটেন্ট সরান। স্ক্রিপ্ট লিখুন, বারবার চালান, ঠিকঠাক করুন — এটি কখনোই হাতে করবেন না।
5. রিডাইরেক্ট মানচিত্র বানান। প্রতিটি পুরোনো URL থেকে তার নতুন ঠিকানায়।
6. স্টেজ করুন, noindex করে, আর যাঁরা এটি ব্যবহার করবেন তাঁদের দিয়েই ব্যবহার করান।
7. নিরিবিলি একটি দিনে লঞ্চ করুন। শুক্রবার নয়, আর কোনো প্রচারাভিযানের ঠিক আগেও নয়।
8. পক্ষকাল ধরে প্রতিদিন Search Console দেখুন। ৪০৪-এর জন্য ক্রল করুন।
9. পুরোনো সাইটটি এক মাস রাখুন। এর থেকে কিছু না কিছু আপনার লাগবেই।

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

আসলে কী পাবেন

নির্দিষ্ট করে, আর সৎভাবে।

সত্যিকারের লাভ: উল্লেখযোগ্যভাবে ভালো Core Web Vitals, বিশেষত INP — কারণ আপনি অনেক কম জাভাস্ক্রিপ্ট পাঠাচ্ছেন আর প্রতি রিকোয়েস্টে কোনো PHP চলছে না; প্লাগইন-দুর্বলতার আক্রমণ পৃষ্ঠ মুছে যায়; ডেভেলপাররা ভার্সন কন্ট্রোল আর কোড রিভিউসহ স্বাভাবিক কোডবেসে কাজ করেন; আর কনটেন্ট নানা জায়গায় পুনর্ব্যবহারযোগ্য হয়।

সত্যিকারের ক্ষতি: WordPress-এর সম্পাদনা অভিজ্ঞতা, বিশাল প্লাগইন ইকোসিস্টেম, এক বিকেলে কাউকে নিয়োগ দিতে পারার সুবিধা, আর কারিগরি নন এমন কারও ডিপ্লয় ছাড়াই কোনো পাতার বিন্যাস বদলাতে পারার ক্ষমতা।

শেষেরটি মাইগ্রেশনের পর অন্য সব কারিগরি সমস্যার মিলিত পরিমাণের চেয়ে বেশি ঘর্ষণ তৈরি করে। কে কী বদলাতে পারবেন তা আগেভাগে ঠিক করুন, আর সম্পাদনা অভিজ্ঞতাটা তাঁদের জন্য বানান যাঁরা সত্যিই ব্যবহার করবেন — যাঁরা বানিয়েছেন সেই ডেভেলপারদের জন্য নয়।

সচরাচর জিজ্ঞাসা

Next.js কি WordPress-এর চেয়ে দ্রুত? সাধারণত হ্যাঁ, অনেকটাই — কারণ পাতা স্ট্যাটিক বা সার্ভার-রেন্ডার হতে পারে, ক্লায়েন্ট জাভাস্ক্রিপ্ট অনেক কম আর প্রতি রিকোয়েস্টে PHP চলে না। তবে ভালো হোস্টিংয়ে ঠিকমতো ক্যাশ করা WordPress সাইট খারাপভাবে বানানো Next.js সাইটকে হারিয়ে দেয় — ফ্রেমওয়ার্কই পুরো গল্প নয়।

মাইগ্রেশন কি আমার এসইও নষ্ট করবে? কেবল যদি রিডাইরেক্ট ভুল করেন। প্রতিটি পুরোনো URL-কে ৩০১ দিয়ে তার হুবহু নতুন সমতুল্যে পাঠান, যেখানে পারেন স্লাগ ধরে রাখুন, আর লঞ্চের পর ক্রল করে যাচাই করুন। কয়েক সপ্তাহ কিছু ওঠানামা ধরে রাখুন; খাড়া পতন মানে রিডাইরেক্ট।

হেডলেস WordPress কী? WordPress-কে কনটেন্ট এডিটর ও অ্যাডমিন হিসেবে রেখে দেওয়া, কিন্তু সর্বসাধারণের সাইটটি অন্য কিছু দিয়ে রেন্ডার করা — এখানে Next.js — যা REST বা GraphQL এপিআই দিয়ে কনটেন্ট আনে। এডিটররা পরিচিত ইন্টারফেসেই থাকেন; ভিজিটররা WordPress কখনো দেখেন না।

WordPress থেকে Next.js মাইগ্রেশনে কত সময় লাগে? কয়েকশ পোস্টের কনটেন্ট সাইটের জন্য কনটেন্ট রূপান্তর ও রিডাইরেক্টের কাজসহ ছয় থেকে দশ সপ্তাহ। কেবল ফ্রন্ট এন্ড দ্রুত হয়; সময় নেয় কনটেন্টের HTML আর নতুন করে বানানো প্লাগইন সুবিধাগুলো।

WordPress এডিটর কি ব্যবহার করে যেতে পারব? হ্যাঁ, হেডলেস ব্যবস্থায়। পূর্ণ মাইগ্রেশনের বদলে হেডলেস বাছার প্রধান কারণই এটি, বিশেষত বড় বা কারিগরি নন এমন সম্পাদনা দল থাকলে।

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