अपनी साइट को HTTP से HTTPS पर कैसे स्विच करें

किसी साइट को HTTP से HTTPS पर स्विच करने का मतलब है अपने सर्वर पर एक SSL सर्टिफिकेट इंस्टॉल करना, अपनी साइट को उसके https URLs की ओर पॉइंट करना, और पुराने http URLs को रीडायरेक्ट करना ताकि कुछ भी छूट न जाए। यह काम खुद अधिकतर साइटों पर एक दोपहर में हो जाता है। नीचे पूरी प्रक्रिया छह चरणों में दी गई है, साथ ही यह भी बताया गया है कि सबसे ज्यादा पूछे जाने वाले पांच प्लेटफॉर्म्स पर यह सेटिंग कहां मिलती है।

त्वरित उत्तर: एक SSL सर्टिफिकेट प्राप्त करें (अधिकतर होस्ट एक मुफ्त सर्टिफिकेट जारी करते हैं), इसे अपने सर्वर पर इंस्टॉल करें, अपने प्लेटफॉर्म की सेटिंग्स में अपनी साइट के URLs को http से https में बदलें, पुराने लिंक्स को फॉलो कराने के लिए एक 301 रीडायरेक्ट जोड़ें, जो कुछ भी अभी भी http पर लोड हो रहा हो उसे ठीक करें, फिर Google Search Console में https प्रॉपर्टी जोड़ें और अपना साइटमैप फिर से सबमिट करें।

SSL (Secure Sockets Layer का संक्षिप्त रूप, हालांकि आज जारी किए जाने वाले सभी सर्टिफिकेट TLS का उपयोग करते हैं) ही https को संभव बनाता है। अगर आप पहले पृष्ठभूमि पढ़ना चाहते हैं, तो पढ़ें SSL सर्टिफिकेट क्या है।

6 चरणों में HTTP से HTTPS पर कैसे स्विच करें

1. एक SSL सर्टिफिकेट प्राप्त करें। अपने होस्ट या Let’s Encrypt से मुफ्त, या अगर आपको वारंटी, सत्यापित कंपनी विवरण या वाइल्डकार्ड कवरेज चाहिए तो भुगतान वाला।
2. इसे अपने सर्वर पर इंस्टॉल करें। अपने होस्टिंग पैनल के माध्यम से, Certbot के साथ, या CSR से मैन्युअल रूप से।
3. अपने प्लेटफॉर्म को उसके https URLs की ओर पॉइंट करें। हर CMS अपना खुद का साइट पता स्टोर करता है, और इसे अपडेट करना होगा।
4. http को https पर स्थायी रूप से रीडायरेक्ट करें 301 के साथ, सर्वर स्तर पर।
5. जो अभी भी http पर लोड हो रहा है उसे ठीक करें: मिश्रित सामग्री, आंतरिक एब्सोल्यूट लिंक्स, कैश और फीड्स।
6. सर्च इंजनों को बताएं। Search Console में https प्रॉपर्टी जोड़ें, अपना साइटमैप फिर से सबमिट करें, अपने कैनोनिकल्स जांचें।

प्रत्येक चरण को नीचे विस्तार से बताया गया है। अगर आपके पास पहले से ही सर्टिफिकेट है और आपको केवल प्लेटफॉर्म सेटिंग की जरूरत है, तो चरण 3 पर जाएं।

शुरू करने से पहले: अपनी साइट और उसके डेटाबेस का बैकअप लें, और अगर आपके पास स्टेजिंग एनवायरनमेंट है, तो पहले वहां यह बदलाव करके देखें। नीचे दिए गए दो चरण आपको आपके ही एडमिन से बाहर लॉक कर सकते हैं अगर सर्टिफिकेट काम नहीं कर रहा हो, इसलिए बैकअप ही पांच मिनट के फिक्स और एक खराब दोपहर के बीच का अंतर होता है। किसी दुकान (शॉप) पर, यह काम पीक ऑवर्स के बाहर करें: चेकआउट के अनुपलब्ध होने का हर मिनट एक खोया हुआ ऑर्डर होता है।

अभी क्यों स्विच करें: Chrome अक्टूबर 2026 में HTTPS को डिफॉल्ट बनाता है

HTTPS के लिए सामान्य तर्क अब भी सही हैं, लेकिन अब इसके साथ एक तारीख जुड़ी हुई है, जो अभी भी इसे टाल रहे किसी भी व्यक्ति के लिए गणना बदल देती है।

Chrome डिफॉल्ट रूप से Always Use Secure Connections को दो चरणों में चालू कर रहा है। अप्रैल 2026 में, Chrome 147 ने इसे Enhanced Safe Browsing पर हर किसी के लिए सक्षम किया, जो एक अरब से अधिक लोग हैं। अक्टूबर 2026 में, Chrome 154 इसे दुनिया भर के सभी उपयोगकर्ताओं तक विस्तारित करता है। इसके चालू होने पर, Chrome पहले https आजमाता है और उपयोगकर्ता द्वारा पहले न देखी गई सार्वजनिक http साइट लोड करने से पहले चेतावनी दिखाता है।

दूसरे शब्दों में, अगर आपकी साइट अक्टूबर 2026 के बाद भी http पर है, तो आपके आगंतुकों का एक बड़ा हिस्सा उस तक पहुंचने से पहले एक इंटरस्टिशियल चेतावनी का सामना करेगा। राउटर और इंट्रानेट जैसे प्राइवेट पतों को अलग तरह से माना जाता है और डिफॉल्ट रूप से उनके बारे में चेतावनी नहीं दी जाती।

HTTPS अब एक स्पीड निर्णय भी है

इस हिस्से को अधिकतर माइग्रेशन गाइड्स में छोड़ दिया जाता है। HTTP/2 औपचारिक रूप से एन्क्रिप्शन की आवश्यकता नहीं रखता, लेकिन किसी भी प्रमुख ब्राउज़र ने इसे कभी भी अनएन्क्रिप्टेड कनेक्शनों पर लागू नहीं किया है, इसलिए व्यवहार में आप इसे HTTPS के बिना उपयोग नहीं कर सकते। HTTP/3 और आगे जाता है: इसे TLS 1.3 की जरूरत होती है और इसमें कोई अनएन्क्रिप्टेड मोड ही नहीं है। इसलिए http पर बने रहने से आपकी साइट दोनों आधुनिक ट्रांसपोर्ट प्रोटोकॉल्स और उनके साथ आने वाले प्रदर्शन से बाहर हो जाती है।

जानी-पहचानी वजहें अब भी लागू होती हैं। ब्राउज़र http पेजेज को Not Secure के रूप में लेबल करते हैं, फॉर्म डेटा और पासवर्ड बिना सर्टिफिकेट के खुले (क्लियर) में यात्रा करते हैं, पेमेंट गेटवे http पर काम करने से इनकार करते हैं, और Google 2014 से HTTPS को एक रैंकिंग सिग्नल के रूप में मानता आ रहा है। यह अंतिम बात एक वास्तविक लेकिन हल्का सिग्नल है, इसलिए इसे मुख्य वजह की बजाय बोनस के रूप में लें।

चरण 1: एक SSL सर्टिफिकेट प्राप्त करें

पहले अपना होस्टिंग पैनल जांचें। अधिकतर होस्ट अब SSL/TLS या AutoSSL सेक्शन के जरिए मुफ्त Let’s Encrypt सर्टिफिकेट जारी करते हैं, और कई ने पहले से ही एक जारी कर दिया है जिसका आप उपयोग नहीं कर रहे। एक मुफ्त सर्टिफिकेट ट्रैफिक को उतना ही अच्छा एन्क्रिप्ट करता है जितना कि एक भुगतान वाला; जो अलग होता है वह यह है कि सर्टिफिकेट अथॉरिटी ने इसे जारी करने से पहले क्या सत्यापित किया, और जब कुछ गलत होता है तो इसके पीछे क्या समर्थन है।

प्रकार	CA क्या जांचता है	जारी होने में समय	उपयुक्त
Domain Validation (DV)	कि आप डोमेन को नियंत्रित करते हैं	मिनटों में	ब्लॉग्स, ब्रोशर साइट्स, अधिकतर छोटी साइट्स
Organization Validation (OV)	डोमेन के साथ-साथ आपका पंजीकृत संगठन	1 से 3 कार्यदिवस	बिजनेस साइट्स, सदस्य क्षेत्र, क्लाइंट पोर्टल्स
Extended Validation (EV)	कंपनी की पूरी कानूनी और परिचालन जांच	1 से 3 कार्यदिवस	स्टोर्स, वित्त, जहां भी पहचान मायने रखती है

अगर आपकी साइट सबडोमेन्स का उपयोग करती है, तो एक वाइल्डकार्ड सर्टिफिकेट एक ही सर्टिफिकेट से उन सभी को कवर कर लेता है। पक्का नहीं कि कौन सा प्रकार लागू होता है? SSL Wizard कुछ सवालों में इसे सीमित कर देता है, या सीधे सर्टिफिकेट्स ब्राउज़ करें।

आप जो भी चुनें, उसके लिए एक चीज की योजना बनानी होगी: Let’s Encrypt सर्टिफिकेट 90 दिनों तक चलते हैं और समाप्ति से लगभग 30 दिन पहले स्वचालित रूप से नवीनीकृत होने के लिए बनाए गए हैं। जब यह ऑटोमेशन टूटता है, और यह टूटता है, साइट कुछ हफ्तों तक काम करती रहती है और फिर बिना किसी चेतावनी के असुरक्षित हो जाती है। पुष्टि करें कि ऑटो-नवीनीकरण चालू है, और पहली अपेक्षित नवीनीकरण तारीख के बाद एक बार सर्टिफिकेट जांचें।

चरण 2: इसे अपने सर्वर पर इंस्टॉल करें

• होस्टिंग पैनल। सबसे तेज़ रास्ता। cPanel पर, SSL/TLS Security के अंतर्गत होता है। एपेक्स डोमेन और www संस्करण दोनों के लिए जारी करें, वरना जो भी आपने छोड़ा वह एक नाम बेमेल (mismatch) चेतावनी देगा।
• बिना पैनल वाले VPS पर Certbot। यह सर्टिफिकेट जारी करता है, सर्वर को कॉन्फ़िगर करता है और अपना खुद का नवीनीकरण टाइमर इंस्टॉल करता है।
• भुगतान वाले सर्टिफिकेट के लिए मैन्युअल रूप से: CSR generator या हमारे CSR कैसे बनाएं इस पर 70 से अधिक ट्यूटोरियल्स में से किसी एक के साथ एक CSR जनरेट करें, वैलिडेशन पूरा करें, फिर सर्टिफिकेट, की और इंटरमीडिएट्स इंस्टॉल करें। हमारे पास 80 से अधिक SSL इंस्टॉलेशन गाइड्स हैं, जिनमें cPanel भी शामिल है।

आगे बढ़ने से पहले सत्यापित करें। अपने डोमेन के खिलाफ SSL Checker चलाएं। सबसे आम शांत विफलता है एक अधूरी सर्टिफिकेट चेन: साइट आपके डेस्कटॉप ब्राउज़र में एक पैडलॉक दिखाती है, क्योंकि उसने कहीं और से इंटरमीडिएट सर्टिफिकेट कैश किया हुआ होता है, जबकि मोबाइल ब्राउज़र और पेमेंट गेटवे विफल हो जाते हैं। चेकर इसकी रिपोर्ट करता है।

चरण 3: अपने प्लेटफॉर्म को उसके HTTPS URLs की ओर पॉइंट करें

एक काम करने वाला सर्टिफिकेट https को उपलब्ध बनाता है। आपकी साइट तब तक http लिंक्स बनाती रहेगी जब तक आप इसे ऐसा न करने के लिए न कहें, क्योंकि हर CMS अपना खुद का पता स्टोर करता है। यहां बताया गया है कि वह सेटिंग कहां मिलती है।

प्लेटफॉर्म	सेटिंग कहां मिलती है
WordPress	Settings > General, WordPress Address (URL) और Site Address (URL) दोनों बदलें। संस्करण 5.7 से, कोर भी दोनों के https पर होने के बाद आपकी सामग्री में असुरक्षित URLs को फिर से लिखता है, और 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 URLs जारी करने के लिए बनाती हैं; केवल एडमिन वाली एक रीडायरेक्ट लागू करती है, इसलिए स्टोरफ्रंट को अभी भी चरण 4 की जरूरत है
Drupal	कोई कोर सेटिंग नहीं है, और .htaccess में चालू करने के लिए कुछ भी नहीं है: Drupal जो कमेंटेड नियम वहां शिप करता है वे www और non-www के बीच रीडायरेक्ट करते हैं, http को https में नहीं। चरण 4 का सर्वर-स्तरीय नियम उसी फ़ाइल में जोड़ें
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 पर ही रह जाता है। इसके बजाय चरण 4 के सामान्य Apache नियम का उपयोग करें।

अगर आपका प्लेटफॉर्म सूचीबद्ध नहीं है, तो समकक्ष सेटिंग ढूंढने की चिंता न करें। अगले चरण में सर्वर-स्तरीय रीडायरेक्ट इस पर काम करता है चाहे उसके ऊपर कुछ भी चल रहा हो।

चरण 4: 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) पर सेट करें और ओरिजिन पर एक वैलिड सर्टिफिकेट रखें।

चरण 5: जो अभी भी HTTP पर लोड होता है उसे ठीक करें

मिश्रित सामग्री। https पर सर्व किया गया एक पेज जो अभी भी http पर एक इमेज, स्क्रिप्ट या स्टाइलशीट खींचता है, मिश्रित सामग्री कहलाता है। ब्राउज़र चुपचाप कुछ संसाधनों को अपग्रेड कर देते हैं, ज्यादातर इमेजेज और मीडिया को, और अन्य को पूरी तरह से मना कर देते हैं, इसलिए एक प्रभावित पेज पूरी तरह से बिना स्टाइल के आ सकता है। ब्राउज़र कंसोल दोषी फ़ाइल का नाम बताता है। मिश्रित सामग्री को कैसे ठीक करें पर हमारी गाइड निदान को कवर करती है।

आंतरिक एब्सोल्यूट लिंक्स। आपकी अपनी साइट पर पूरे http पते के रूप में लिखा गया कोई भी लिंक अभी भी http पर पॉइंट करता है, और अब हर क्लिक पर एक अतिरिक्त रीडायरेक्ट हॉप लेता है। रिलेटिव लिंक्स को कुछ नहीं चाहिए। यह चरण लगभग सार्वभौमिक रूप से छोड़ दिया जाता है, और यही अंतर है एक ऐसे माइग्रेशन के बीच जो पूरा हो गया है और एक ऐसे के बीच जो सिर्फ काम करता है।

कैशेज, CDN और फीड्स। अपना पेज कैश और CDN साफ करें, वरना एक http पेज की कैश्ड कॉपी पुराना मार्कअप सर्व करती रहेगी और एक पूरा हो चुका माइग्रेशन टूटा हुआ दिखेगा। फिर उन जगहों को जांचें जहां एक डेटाबेस सर्च और रिप्लेस कभी नहीं पहुंचता: ईमेल टेम्प्लेट्स, इनवॉइस, प्रोडक्ट फीड्स और कोई भी चीज़ जो एक थर्ड-पार्टी सर्विस आपकी साइट के बारे में स्टोर करती है।

यह कैसे जानें कि यह काम कर गया

चार जांचें, क्रम में।

1. अपना http पता एक ब्राउज़र में टाइप करें और पुष्टि करें कि यह लोड होने के बजाय https पर पहुंचता है।
2. अपने डोमेन के www और non-www संस्करणों के लिए भी ऐसा ही करें, क्योंकि केवल एक को कवर करने वाला सर्टिफिकेट दूसरे पर एक नाम बेमेल दिखाएगा।
3. कुछ आंतरिक पेजेज खोलें, न कि सिर्फ होम पेज, और पुष्टि करें कि हर एक पर पैडलॉक बना रहता है।
4. फिर एक बार फिर SSL Checker चलाएं, जो चेन और एक्सपायरी समस्याओं को पकड़ता है जिन्हें एक ब्राउज़र आपसे छिपा देगा।

चरण 6: सर्च इंजनों को बताएं

• Google Search Console में https प्रॉपर्टी जोड़ें। एक http प्रॉपर्टी https URLs पर रिपोर्ट नहीं करती। नई प्रॉपर्टी जोड़ें और पुरानी रखें, या एक Domain प्रॉपर्टी का उपयोग करें, जो दोनों प्रोटोकॉल्स को एक साथ कवर करती है।
• https URLs के साथ अपना साइटमैप फिर से सबमिट करें। 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 पर विचार करें, जो ब्राउज़रों को आपके डोमेन के लिए सीधे plain http को अस्वीकार करने के लिए कहता है और पहली रिक्वेस्ट व रीडायरेक्ट के बीच के अंतर को बंद कर देता है। शुरुआत में preload निर्देश को बंद रखें: इसे उलटना धीमा है, और यह किसी भी सबडोमेन को जो अभी भी http पर है, अनुपलब्ध बना देगा।

अगर अभी भी कुछ ठीक नहीं है, तो SSL एरर गाइड्स विशिष्ट ब्राउज़र एरर कोड्स को संभालती हैं।

क्या आप HTTPS से HTTP पर वापस स्विच कर सकते हैं?

तकनीकी रूप से हां, रीडायरेक्ट को हटाकर और अपनी साइट URLs को वापस बदलकर। व्यवहार में आपको लगभग कभी ऐसा नहीं करना चाहिए। यह इंडेक्स चर्न के दूसरे दौर के साथ एक दूसरा साइट मूव है, और ब्राउज़र चेतावनियां सीधे वापस आ जाती हैं, जिसका अक्टूबर 2026 के बाद मतलब है अधिकतर आगंतुकों के लिए एक इंटरस्टिशियल। अगर आपने HSTS सक्षम किया है, तो ब्राउज़र्स आपके डोमेन के लिए http को तब तक अस्वीकार करेंगे जब तक पॉलिसी समाप्त नहीं हो जाती, इसलिए रोलबैक साफ तरीके से काम भी नहीं करेगा।

एक नियमित अपवाद स्थानीय विकास (लोकल डेवलपमेंट) है, जहां एक स्व-हस्ताक्षरित सर्टिफिकेट या एक मशीन पर plain http जिस तक कोई और नहीं पहुंच सकता, सामान्य है। अगर एक लाइव साइट https पर गलत व्यवहार कर रही है, तो कारण लगभग हमेशा सर्टिफिकेट, मिश्रित सामग्री या एक रीडायरेक्ट लूप होता है, और उनमें से किसी एक को ठीक करना माइग्रेशन को उलटने से कहीं ज्यादा सस्ता है।

अक्सर पूछे जाने वाले प्रश्न

कोई खास प्लेटफॉर्म चला रहे हैं? हमारे पास WordPress, Joomla और PrestaShop के लिए विस्तृत गाइड्स हैं।