আপনার সাইটকে HTTP থেকে HTTPS-এ কীভাবে পরিবর্তন করবেন

একটি সাইট HTTP থেকে HTTPS-এ রূপান্তর করার অর্থ হলো আপনার সার্ভারে একটি SSL সার্টিফিকেট ইনস্টল করা, আপনার সাইটকে তার https URL-গুলোর দিকে নির্দেশ করা এবং পুরনো http URL-গুলো রিডাইরেক্ট করা যাতে কিছুই বাদ না পড়ে। বেশিরভাগ সাইটেই এই কাজটি করতে এক বিকেল সময় লাগে। নিচে সম্পূর্ণ প্রক্রিয়াটি ছয়টি ধাপে দেওয়া হলো, সাথে সবচেয়ে বেশি জিজ্ঞাসিত পাঁচটি প্ল্যাটফর্মে সেটিংটি কোথায় থাকে তাও জানানো হলো।

দ্রুত উত্তর: একটি SSL সার্টিফিকেট নিন (বেশিরভাগ হোস্ট বিনামূল্যে ইস্যু করে), সেটি আপনার সার্ভারে ইনস্টল করুন, আপনার প্ল্যাটফর্মের সেটিংসে সাইটের URL http থেকে https-এ পরিবর্তন করুন, পুরনো লিংকগুলো অনুসরণ করার জন্য একটি 301 রিডাইরেক্ট যোগ করুন, এখনও http-তে লোড হওয়া যেকোনো কিছু ঠিক করুন, তারপর Google Search Console-এ https প্রপার্টি যোগ করুন এবং আপনার সাইটম্যাপ পুনরায় জমা দিন।

SSL (Secure Sockets Layer-এর সংক্ষিপ্ত রূপ, যদিও আজকাল ইস্যু করা সব সার্টিফিকেটই TLS ব্যবহার করে) হলো যা https সম্ভব করে তোলে। আগে প্রেক্ষাপট জানতে চাইলে পড়ুন SSL সার্টিফিকেট কী।

৬টি ধাপে কীভাবে HTTP থেকে HTTPS-এ পরিবর্তন করবেন

1. একটি SSL সার্টিফিকেট নিন। আপনার হোস্ট বা Let’s Encrypt থেকে বিনামূল্যে, অথবা যদি আপনার ওয়ারেন্টি, যাচাইকৃত কোম্পানির বিবরণ বা ওয়াইল্ডকার্ড কভারেজ প্রয়োজন হয় তবে পেইড।
2. আপনার সার্ভারে এটি ইনস্টল করুন। আপনার হোস্টিং প্যানেলের মাধ্যমে, Certbot দিয়ে, অথবা CSR থেকে ম্যানুয়ালি।
3. আপনার প্ল্যাটফর্মকে তার https URL-গুলোর দিকে নির্দেশ করুন। প্রতিটি CMS নিজস্ব সাইট ঠিকানা সংরক্ষণ করে, এবং এটি আপডেট করতে হবে।
4. সার্ভার লেভেলে 301 দিয়ে http কে স্থায়ীভাবে https-এ রিডাইরেক্ট করুন।
5. যা এখনও http-তে লোড হয় তা ঠিক করুন: মিশ্র কন্টেন্ট, অভ্যন্তরীণ অ্যাবসোলিউট লিংক, ক্যাশ এবং ফিড।
6. সার্চ ইঞ্জিনগুলোকে জানান। Search Console-এ https প্রপার্টি যোগ করুন, আপনার সাইটম্যাপ পুনরায় জমা দিন, আপনার ক্যানোনিক্যালগুলো পরীক্ষা করুন।

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

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

কেন এখনই পরিবর্তন করবেন: অক্টোবর ২০২৬-এ Chrome HTTPS-কে ডিফল্ট করে দিচ্ছে

HTTPS-এর জন্য স্বাভাবিক যুক্তিগুলো এখনও সত্য, তবে এখন একটি নির্দিষ্ট তারিখ সংযুক্ত হয়েছে, যা এখনও এটি বিলম্বিত করে রাখা যেকোনো ব্যক্তির জন্য হিসাবটি পরিবর্তন করে দেয়।

Chrome দুটি পর্যায়ে ডিফল্টভাবে Always Use Secure Connections চালু করছে। এপ্রিল ২০২৬-এ, Chrome 147 এটি Enhanced Safe Browsing-এ থাকা সবার জন্য সক্রিয় করেছে, যা এক বিলিয়নেরও বেশি মানুষের জন্য প্রযোজ্য। অক্টোবর ২০২৬-এ, Chrome 154 এটি বিশ্বব্যাপী সব ব্যবহারকারীর জন্য সম্প্রসারিত করবে। এটি চালু থাকলে, Chrome প্রথমে https চেষ্টা করে এবং ব্যবহারকারী আগে দেখেনি এমন একটি পাবলিক http সাইট লোড করার আগে একটি সতর্কতা দেখায়।

অন্য কথায়, যদি আপনার সাইট অক্টোবর ২০২৬-এর পরও http-তে থাকে, তাহলে আপনার একটি বড় অংশের দর্শক সেখানে পৌঁছানোর আগে একটি ইন্টারস্টিশিয়াল সতর্কতার সম্মুখীন হবেন। রাউটার এবং ইন্ট্রানেটের মতো প্রাইভেট ঠিকানাগুলোকে ভিন্নভাবে বিবেচনা করা হয় এবং ডিফল্টভাবে সেগুলো নিয়ে সতর্ক করা হয় না।

HTTPS এখন একটি গতি সংক্রান্ত সিদ্ধান্তও বটে

এই অংশটি বেশিরভাগ মাইগ্রেশন গাইডে বাদ পড়ে যায়। HTTP/2 আনুষ্ঠানিকভাবে এনক্রিপশন প্রয়োজন করে না, তবে কোনো প্রধান ব্রাউজার কখনোই এনক্রিপ্ট না করা সংযোগের ওপর এটি বাস্তবায়ন করেনি, তাই বাস্তবে HTTPS ছাড়া এটি ব্যবহার করা যায় না। HTTP/3 আরও এগিয়ে: এটি TLS 1.3 প্রয়োজন করে এবং এর কোনো অ-এনক্রিপ্টেড মোডই নেই। তাই http-তে থাকা মানে আপনার সাইট আধুনিক ট্রান্সপোর্ট প্রোটোকল দুটি থেকেই এবং সেগুলোর সাথে আসা পারফরম্যান্স থেকেও বাদ পড়ে যাওয়া।

পরিচিত কারণগুলোও এখনও প্রযোজ্য। ব্রাউজারগুলো http পেজগুলোকে Not Secure হিসেবে চিহ্নিত করে, সার্টিফিকেট ছাড়া ফর্ম ডেটা এবং পাসওয়ার্ড প্লেইন টেক্সটে ভ্রমণ করে, পেমেন্ট গেটওয়েগুলো http-তে কাজ করতে অস্বীকার করে, এবং Google ২০১৪ সাল থেকে HTTPS-কে একটি র‍্যাঙ্কিং সিগন্যাল হিসেবে বিবেচনা করে আসছে। সেই শেষটি একটি বাস্তব কিন্তু হালকা সিগন্যাল, তাই একে মূল কারণের পরিবর্তে একটি বোনাস হিসেবে বিবেচনা করুন।

ধাপ ১: একটি SSL সার্টিফিকেট নিন

প্রথমে আপনার হোস্টিং প্যানেল পরীক্ষা করুন। বেশিরভাগ হোস্ট এখন SSL/TLS বা AutoSSL সেকশনের মাধ্যমে বিনামূল্যে Let’s Encrypt সার্টিফিকেট ইস্যু করে, এবং অনেকেই ইতিমধ্যে একটি ইস্যু করে রেখেছে যা আপনি ব্যবহার করছেন না। একটি বিনামূল্যের সার্টিফিকেট ঠিক পেইড সার্টিফিকেটের মতোই ট্রাফিক এনক্রিপ্ট করে; পার্থক্য হলো সার্টিফিকেট অথরিটি ইস্যু করার আগে কী যাচাই করেছে, এবং কিছু ভুল হলে এর পেছনে কী ব্যাকআপ থাকে।

প্রকার	CA যা যাচাই করে	ইস্যু করার সময়	উপযুক্ত
ডোমেইন ভ্যালিডেশন (DV)	আপনি ডোমেইন নিয়ন্ত্রণ করেন কিনা	মিনিটের মধ্যে	ব্লগ, ব্রোশিওর সাইট, বেশিরভাগ ছোট সাইট
অর্গানাইজেশন ভ্যালিডেশন (OV)	ডোমেইন এবং আপনার নিবন্ধিত সংস্থা	১ থেকে ৩ কার্যদিবস	ব্যবসায়িক সাইট, সদস্য এলাকা, ক্লায়েন্ট পোর্টাল
এক্সটেন্ডেড ভ্যালিডেশন (EV)	কোম্পানির সম্পূর্ণ আইনি ও অপারেশনাল যাচাই	১ থেকে ৩ কার্যদিবস	দোকান, অর্থ, যেখানে পরিচয় গুরুত্বপূর্ণ

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

আপনি যেটিই বেছে নিন না কেন, পরিকল্পনা করার মতো একটি বিষয়: Let’s Encrypt সার্টিফিকেট ৯০ দিন স্থায়ী হয় এবং মেয়াদ শেষ হওয়ার প্রায় ৩০ দিন আগে স্বয়ংক্রিয়ভাবে নবায়ন হওয়ার কথা। যখন সেই স্বয়ংক্রিয়করণ ভেঙে যায়, এবং তা ঘটেই থাকে, সাইটটি সপ্তাহখানেক কাজ করে এবং তারপর কোনো সতর্কতা ছাড়াই অনিরাপদ হয়ে যায়। স্বয়ংক্রিয় নবায়ন চালু আছে কিনা তা নিশ্চিত করুন, এবং প্রথম প্রত্যাশিত নবায়ন তারিখের পর একবার সার্টিফিকেটটি পরীক্ষা করুন।

ধাপ ২: আপনার সার্ভারে এটি ইনস্টল করুন

• হোস্টিং প্যানেল। সবচেয়ে দ্রুত উপায়। cPanel-এ, SSL/TLS Security-এর অধীনে থাকে। apex ডোমেইন এবং www ভার্সন উভয়ের জন্যই ইস্যু করুন, নাহলে যেটি বাদ পড়বে সেটি একটি নাম মেলে না এমন সতর্কতা দেখাবে।
• প্যানেল ছাড়া একটি VPS-এ Certbot। এটি সার্টিফিকেট ইস্যু করে, সার্ভার কনফিগার করে এবং নিজস্ব নবায়ন টাইমার ইনস্টল করে।
• একটি পেইড সার্টিফিকেটের জন্য ম্যানুয়ালি: CSR generator বা আমাদের CSR তৈরি করার ৭০টিরও বেশি টিউটোরিয়াল-এর যেকোনো একটি দিয়ে একটি CSR তৈরি করুন, ভ্যালিডেশন সম্পন্ন করুন, তারপর সার্টিফিকেট, কী এবং ইন্টারমিডিয়েটগুলো ইনস্টল করুন। আমাদের কাছে ৮০টিরও বেশি SSL ইনস্টলেশন গাইড আছে, যার মধ্যে রয়েছে cPanel।

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

ধাপ ৩: আপনার প্ল্যাটফর্মকে তার HTTPS URL-গুলোর দিকে নির্দেশ করুন

একটি কার্যকরী সার্টিফিকেট https কে উপলব্ধ করে তোলে। আপনার সাইট http লিংক তৈরি করতেই থাকবে যতক্ষণ না আপনি এটিকে না করতে বলেন, কারণ প্রতিটি CMS নিজস্ব ঠিকানা সংরক্ষণ করে। এখানে দেখানো হলো সেই সেটিং কোথায় থাকে।

প্ল্যাটফর্ম	সেটিং কোথায় থাকে
WordPress	Settings > General, WordPress Address (URL) এবং Site Address (URL) উভয়ই পরিবর্তন করুন। সংস্করণ 5.7 থেকে, উভয়টি https-এ থাকলে কোর আপনার কন্টেন্টে থাকা অনিরাপদ URL-গুলোও পুনর্লিখন করে, এবং Site Health একটি এক-ক্লিক সুইচ অফার করে
Joomla	System > Global Configuration > Server, Force HTTPS কে Entire Site-এ সেট করুন
PrestaShop	Shop Parameters > General, HTTPS চেক চালান, Enable SSL কে Yes-এ সেট করুন, তারপর Enable SSL on all pages, তারপর Save। দ্বিতীয় সুইচটি প্রথমটি সংরক্ষণ না হওয়া পর্যন্ত লক থাকে
Magento 2	Stores > Configuration > General > Web, Base URLs (Secure) খুলুন, সিকিউর বেস URL-কে https-এ সেট করুন, তারপর Use Secure URLs on Storefront এবং Use Secure URLs in Admin উভয়ই Yes-এ সেট করুন এবং Save Config চাপুন, তারপর ক্যাশ পরিষ্কার করুন। সেই দুটি সেটিং Magento কে https URL ইস্যু করায়; শুধুমাত্র অ্যাডমিন সেটিংটি একটি রিডাইরেক্ট বলবৎ করে, তাই স্টোরফ্রন্টের জন্য এখনও ধাপ ৪ প্রয়োজন
Drupal	কোনো কোর সেটিং নেই, এবং চালু করার মতো .htaccess-এ কিছুই নেই: Drupal যে কমেন্ট করা নিয়মগুলো সরবরাহ করে সেগুলো www এবং non-www এর মধ্যে রিডাইরেক্ট করে, http কে https-এ নয়। ধাপ ৪ থেকে সার্ভার-লেভেল নিয়মটি সেই একই ফাইলে যোগ করুন
Shopify, Wix, Squarespace	কিছু করার নেই। HTTPS স্বয়ংক্রিয় এবং বন্ধ করা যায় না

সেই Drupal সারিটি দুবার পড়ার মতো, কারণ অনেক গাইড এটি ভুল করে বলে। Drupal-এর .htaccess-এ কমেন্ট করা রিডাইরেক্ট নিয়ম রয়েছে, তাই সেগুলোকে HTTPS-এর নিয়ম বলে ধরে নেওয়া সহজ। তারা তা নয়। এখানে আসলে যা আছে তা দেওয়া হলো, এবং এটি শুধুমাত্র www এবং non-www এর মধ্যে বেছে নেয়:

# RewriteCond %{HTTP_HOST} .
# RewriteCond %{HTTP_HOST} !^www. [NC]
# RewriteRule ^ http%{ENV:protossl}://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

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

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

ধাপ ৪: HTTP কে স্থায়ীভাবে HTTPS-এ রিডাইরেক্ট করুন

আপনার পেজগুলো এখন https-এও সাড়া দিচ্ছে, কিন্তু সেগুলো এখনও http-তেও সাড়া দেয়, এবং প্রতিটি পুরনো লিংক, বুকমার্ক এবং ইনডেক্স করা URL সেখানে নির্দেশ করে। একটি স্থায়ী রিডাইরেক্ট এটি ঠিক করে দেয়।

এটি একটি 301 হতে হবে, একটি সাময়িক 302 নয়। একটি 301 সার্চ ইঞ্জিনগুলোকে বলে যে পরিবর্তনটি স্থায়ী। Google জানায় যে 301 এবং অন্যান্য স্থায়ী রিডাইরেক্ট PageRank-এর ক্ষতি করে না, যা জানা মূল্যবান, কারণ র‍্যাঙ্কিং হারানোর ভয়ই বেশিরভাগ সাইটকে যতটা প্রয়োজন তার চেয়ে বেশি সময় http-তে রাখে।

Apache-তে, আপনার সাইট রুটে .htaccess-এর শীর্ষের কাছে এটি যোগ করুন:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

শর্তটিতে অবশ্যই off লেখা থাকতে হবে, অর্থাৎ “রিকোয়েস্ট ইতিমধ্যে সিকিউর না হলে রিডাইরেক্ট করুন”। “on” হিসেবে লেখা হলে, যা প্রকাশিত স্নিপেটগুলোর একটি বিস্ময়কর সংখ্যায় দেখা যায়, এটি শুধুমাত্র ইতিমধ্যে https এমন রিকোয়েস্টগুলোতে সক্রিয় হয় এবং সেগুলোকে আবার https-এ পাঠায়, যা একটি লুপ।

Nginx-এ কোনো .htaccess নেই। সার্ভার ব্লকটি সম্পাদনা করুন:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

nginx -t দিয়ে পরীক্ষা করুন, তারপর systemctl reload nginx দিয়ে রিলোড করুন।

এটি যোগ করার পরপরই যদি আপনি ERR_TOO_MANY_REDIRECTS পান, তাহলে সাধারণ কারণটি হলো Cloudflare-এর মতো একটি প্রক্সি Flexible SSL-এ সেট করা: এটি আপনার সার্ভারের সাথে http-তে কথা বলে অথচ আপনার সার্ভার https-এ রিডাইরেক্ট করে, তাই দুটি রিকোয়েস্টটিকে একে অপরের মধ্যে বাউন্স করতে থাকে। এনক্রিপশন মোডটিকে Full (strict)-এ সেট করুন এবং অরিজিনে একটি বৈধ সার্টিফিকেট রাখুন।

ধাপ ৫: যা এখনও HTTP-তে লোড হয় তা ঠিক করুন

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

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

ক্যাশ, CDN এবং ফিড। আপনার পেজ ক্যাশ এবং CDN পরিষ্কার করুন, নাহলে একটি http পেজের ক্যাশ করা কপি পুরনো মার্কআপ পরিবেশন করতে থাকবে এবং সম্পন্ন হওয়া মাইগ্রেশনকে ভাঙা বলে মনে করাবে। তারপর যেসব জায়গায় ডেটাবেস সার্চ এবং রিপ্লেস কখনো পৌঁছায় না তা পরীক্ষা করুন: ইমেইল টেমপ্লেট, ইনভয়েস, প্রোডাক্ট ফিড, এবং আপনার সাইট সম্পর্কে কোনো তৃতীয়-পক্ষের পরিষেবা যা সংরক্ষণ করে।

এটি কাজ করেছে কিনা তা কীভাবে জানবেন

চারটি পরীক্ষা, ক্রমানুসারে।

1. একটি ব্রাউজারে আপনার http ঠিকানাটি টাইপ করুন এবং নিশ্চিত করুন এটি লোড হওয়ার পরিবর্তে https-এ পৌঁছায়।
2. আপনার ডোমেইনের www এবং non-www ভার্সনের জন্যও একই কাজ করুন, কারণ শুধুমাত্র একটি কভার করা সার্টিফিকেট অন্যটিতে একটি নাম মেলে না এমন সমস্যা তৈরি করবে।
3. শুধু হোম পেজ নয়, কয়েকটি অভ্যন্তরীণ পেজ খুলুন এবং প্রতিটিতে প্যাডলকটি ধরে আছে কিনা তা নিশ্চিত করুন।
4. তারপর আরেকবার SSL Checker চালান, যা চেইন এবং মেয়াদ শেষ হওয়ার সমস্যাগুলো ধরে যা একটি ব্রাউজার আপনার কাছ থেকে লুকিয়ে রাখবে।

ধাপ ৬: সার্চ ইঞ্জিনগুলোকে জানান

• Google Search Console-এ https প্রপার্টি যোগ করুন। একটি http প্রপার্টি https URL-গুলো নিয়ে রিপোর্ট করে না। নতুনটি যোগ করুন এবং পুরনোটি রেখে দিন, অথবা একটি Domain প্রপার্টি ব্যবহার করুন, যা একবারে উভয় প্রোটোকল কভার করে।
• https URL সহ আপনার সাইটম্যাপ পুনরায় জমা দিন। Google উল্লেখ করে যে একটি সাইটম্যাপ জমা দেওয়া একটি সরানোর সময় আবিষ্কারকে দ্রুততর করে।
• আপনার ক্যানোনিক্যাল ট্যাগগুলো পরীক্ষা করুন যেন https-এ নির্দেশ করে। সাইট URL পরিবর্তন হলে বেশিরভাগ SEO প্লাগইন স্বয়ংক্রিয়ভাবে আপডেট হয়, তবে পেজ সোর্সে এটি নিশ্চিত করুন।
• আপনার সাইট URL সংরক্ষণ করা যেকোনো অ্যানালিটিক্স, বিজ্ঞাপন প্ল্যাটফর্ম এবং তৃতীয়-পক্ষের পরিষেবা আপডেট করুন।

Change of Address টুলটি ব্যবহার করবেন না। এটি সতর্ক মানুষদেরও ফাঁদে ফেলে দেয়, কারণ ঠিকানা পরিবর্তনের একটি ফাইল করা ঠিক যা আপনি করবেন বলে আশা করবেন। Google একটি http থেকে https-এ পরিবর্তনকে URL পরিবর্তনসহ একটি সাইট মুভ হিসেবে শ্রেণীবদ্ধ করে, তাই Google-এর সাইট মুভ নির্দেশিকা অনুসরণ করুন। সেই নির্দেশিকাগুলোতে স্পষ্টভাবে বলা আছে যে আপনি যদি HTTP থেকে HTTPS-এ স্থানান্তরিত হচ্ছেন, তাহলে আপনার Change of Address টুল ব্যবহারের প্রয়োজন নেই। এটি একটি ভিন্ন ডোমেইনে স্থানান্তরের জন্য সংরক্ষণ করুন।

এরপর কী প্রত্যাশা করবেন

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

Google কত সময় নেয়। কাজটির চেয়ে বেশি সময়। সাইট মুভ নিয়ে Google-এর নির্দেশনা হলো একটি মাঝারি আকারের সাইটের বেশিরভাগ পেজ ইনডেক্সে সরে যেতে কয়েক সপ্তাহ সময় নেয়, এবং বড় সাইটগুলো আরও বেশি সময় নেয়। সেই সময়কালে আপনার ইমপ্রেশন http এবং https প্রপার্টির মধ্যে বিভক্ত দেখা যায়, এবং র‍্যাঙ্কিং ওঠানামা করে। এটি একটি সাইট মুভের জন্য প্রত্যাশিত আচরণ, কিছু ভেঙে যাওয়ার চিহ্ন নয়।

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

যদি এখনও কিছু ঠিক না থাকে, SSL error guides নির্দিষ্ট ব্রাউজার এরর কোডগুলো নিয়ে সহায়তা করে।

আপনি কি HTTPS থেকে HTTP-তে ফিরে যেতে পারেন?

প্রযুক্তিগতভাবে হ্যাঁ, রিডাইরেক্ট সরিয়ে দিয়ে এবং আপনার সাইট URL ফিরিয়ে নিয়ে। বাস্তবে আপনার প্রায় কখনোই তা করা উচিত নয়। এটি একটি দ্বিতীয় সাইট মুভ, ইনডেক্স চার্নের একটি দ্বিতীয় দফা, এবং ব্রাউজার সতর্কতাগুলো সরাসরি ফিরে আসে, যার অর্থ অক্টোবর ২০২৬-এর পরে বেশিরভাগ দর্শকের জন্য একটি ইন্টারস্টিশিয়াল। আপনি যদি HSTS সক্রিয় করে থাকেন, তাহলে পলিসি মেয়াদ শেষ না হওয়া পর্যন্ত ব্রাউজারগুলো আপনার ডোমেইনের জন্য http প্রত্যাখ্যান করবে, তাই রোলব্যাকটি ঠিকভাবে কাজও করবে না।

একমাত্র নিয়মিত ব্যতিক্রম হলো লোকাল ডেভেলপমেন্ট, যেখানে একটি সেলফ-সাইনড সার্টিফিকেট বা এমন একটি মেশিনে প্লেইন http যা অন্য কেউ পৌঁছাতে পারে না তা স্বাভাবিক। যদি একটি লাইভ সাইট https-এ সমস্যা করে, কারণটি প্রায় সবসময়ই সার্টিফিকেট, মিশ্র কন্টেন্ট বা একটি রিডাইরেক্ট লুপ, এবং সেগুলোর একটি ঠিক করা মাইগ্রেশনটি বিপরীত করার চেয়ে অনেক সস্তা।

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

নির্দিষ্ট একটি প্ল্যাটফর্ম চালাচ্ছেন? আমাদের কাছে WordPress, Joomla এবং PrestaShop-এর জন্য বিস্তারিত গাইড রয়েছে।