WordPress पर SSL Certificate कैसे सेट अप करें और HTTPS पर कैसे स्विच करें

वर्डप्रेस साइट पर SSL सर्टिफिकेट लगाने के लिए तीन चरण चाहिए होते हैं: अपने सर्वर पर सर्टिफिकेट इंस्टॉल करना, वर्डप्रेस को अपने URLs के HTTPS वर्ज़न पर पॉइंट करना, और पुराने HTTP ट्रैफिक को रीडायरेक्ट करना। अधिकतर होस्ट अब पहला चरण खुद ही संभाल लेते हैं, और वर्ज़न 5.7 से वर्डप्रेस दूसरे चरण का बड़ा हिस्सा खुद ही कर लेता है। यह गाइड मुफ्त और पेड सर्टिफिकेट दोनों के लिए तीनों चरणों को कवर करती है, और उन एरर्स को भी ठीक करती है जो आमतौर पर बाद में सामने आते हैं।

त्वरित उत्तर: अपने होस्टिंग कंट्रोल पैनल के ज़रिए SSL सर्टिफिकेट इंस्टॉल करें, फिर वर्डप्रेस में Settings > General खोलें और WordPress Address (URL) तथा Site Address (URL) दोनों को उनके https वर्ज़न में बदलें। अंत में 301 रीडायरेक्ट जोड़ें ताकि HTTP रिक्वेस्ट्स HTTPS पर पहुँचें।

SSL (जिसका पूरा नाम Secure Sockets Layer है, हालांकि आज जारी होने वाला हर सर्टिफिकेट वास्तव में TLS का ही उपयोग करता है) वही चीज़ है जो http:// को https:// में बदल देती है और एड्रेस बार से “Not Secure” लेबल हटा देती है। यदि आप पहले इसकी पृष्ठभूमि जानना चाहते हैं, तो पढ़ें SSL सर्टिफिकेट क्या है। नहीं तो, नीचे दी गई तालिका से शुरू करें।

आपके सेटअप के लिए कौन-सा तरीका सही है

वर्डप्रेस में SSL जोड़ने के तीन तरीके हैं, और सही तरीका लगभग पूरी तरह से आपकी होस्टिंग पर निर्भर करता है। अपना सेटअप ढूँढें, फिर उस तरीके पर जाएँ।

आपका सेटअप	यह तरीका इस्तेमाल करें	लगभग कितना समय
मैनेज्ड वर्डप्रेस होस्टिंग	कुछ इंस्टॉल करने की ज़रूरत नहीं। सर्टिफिकेट आमतौर पर पहले से ही सक्रिय होता है, तो सीधे वर्डप्रेस को HTTPS पर बदलने वाले हिस्से पर जाएँ	5 मिनट
cPanel या इससे मिलता-जुलता शेयर्ड होस्ट	तरीका 1, होस्ट का मुफ्त AutoSSL	10 मिनट
ऐसा होस्ट जिसमें कोई SSL टूल नहीं है, या आप चाहते हैं कि यह आपके लिए हो जाए	तरीका 2, प्लगइन विज़ार्ड	10 से 15 मिनट
VPS, डेडिकेटेड सर्वर, या पेड सर्टिफिकेट	तरीका 3, मैनुअल इंस्टॉलेशन	30 मिनट प्लस वैलिडेशन समय
Cloudflare आपकी साइट के आगे मौजूद है	तरीका 1 या 3, फिर Cloudflare SSL को Full (strict) पर सेट करें। समस्या-निवारण देखें	15 मिनट

आप जो भी रास्ता अपनाएँ, पहले साइट का बैकअप ले लें, और यदि आपके पास स्टेजिंग एनवायरनमेंट है, तो प्रोडक्शन को छूने से पहले वहाँ बदलाव चलाकर देखें।

क्या आपको वर्डप्रेस के लिए SSL सर्टिफिकेट चाहिए?

हाँ, और अधिकतर लोगों के लिए इसकी वजह वही है जो वे पहले से देख सकते हैं: Chrome, Firefox, Safari और Edge सभी सादे HTTP पेजों को एड्रेस बार में Not Secure के रूप में चिन्हित करते हैं। यह लेबल बिना सर्टिफिकेट वाली साइट के हर पेज पर दिखाई देता है, जिसमें लॉगिन फॉर्म भी शामिल है।

इसे ठीक करने के तीन व्यावहारिक कारण:

• क्रेडेंशियल्स और फॉर्म डेटा बिना एन्क्रिप्शन के भेजे जाते हैं। बिना सर्टिफिकेट के, उसी नेटवर्क पर मौजूद कोई भी व्यक्ति यह पढ़ सकता है कि विज़िटर्स क्या सबमिट कर रहे हैं, जिसमें आपका अपना वर्डप्रेस पासवर्ड भी शामिल है।
• पेमेंट्स के लिए यह ज़रूरी है। यदि आप WooCommerce चलाते हैं, या किसी भी प्रकार का कार्ड डेटा स्वीकार करते हैं, तो HTTPS वैकल्पिक नहीं है। पेमेंट गेटवे HTTP पर काम करने से इनकार कर देंगे।
• Google, HTTPS को रैंकिंग सिग्नल के रूप में इस्तेमाल करता है। यह एक असली सिग्नल है लेकिन हल्का, इसलिए SEO वाली दलील को कारण के बजाय एक बोनस के रूप में देखें। असली कारण ब्राउज़र की चेतावनी है।

वर्डप्रेस साइट के लिए कौन-सा SSL सर्टिफिकेट इस्तेमाल करना चाहिए?

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

वैलिडेशन लेवल

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

यदि आपकी साइट सबडोमेन पर चलती है, जैसे store.example.com पर एक दुकान और blog.example.com पर एक ब्लॉग, तो वाइल्डकार्ड सर्टिफिकेट एक ही सर्टिफिकेट से इन सभी को कवर कर देता है, हर सबडोमेन के लिए अलग सर्टिफिकेट लेने की बजाय। कौन-सा प्रकार आपके लिए उपयुक्त है यह तय नहीं कर पा रहे? SSL Wizard कुछ सवालों में इसे तय कर देता है।

जब मुफ्त सर्टिफिकेट पर्याप्त नहीं रहता

मुफ्त सर्टिफिकेट केवल DV होते हैं, 90 दिन तक चलते हैं, और इनमें कोई सपोर्ट या वारंटी नहीं होती। एक पर्सनल ब्लॉग के लिए यह ठीक है। यह चार स्थितियों में समस्या बन जाता है:

• आप पेमेंट लेते हैं। पेड सर्टिफिकेट में एक वारंटी होती है जो सर्टिफिकेट के फेल होने पर होने वाले नुकसान को कवर करती है। मुफ्त सर्टिफिकेट में यह नहीं होती।
• आपके विज़िटर्स को यह जानना ज़रूरी है कि आप कौन हैं। DV सर्टिफिकेट सिर्फ यह साबित करता है कि किसी का डोमेन पर नियंत्रण है। OV और EV सर्टिफिकेट के भीतर आपके वेरिफाइड संगठन की जानकारी डालते हैं।
• आप सबडोमेन चलाते हैं। मुफ्त वाइल्डकार्ड जारी करना संभव है लेकिन जटिल है, और इसके लिए आमतौर पर DNS ऑटोमेशन चाहिए होता है जो आपका होस्ट शायद न दे।
• रीन्यूअल ऑटोमेटेड नहीं है। एक 90-दिन का सर्टिफिकेट जिसे कोई रीन्यू नहीं करता, वह उतनी ही निश्चितता से साइट को डाउन कर देगा जितना कि सर्टिफिकेट का बिल्कुल न होना। यदि आपका होस्ट ऑटो-रीन्यू नहीं करता, तो एक लंबी अवधि वाला पेड सर्टिफिकेट कम काम की माँग करता है, ज़्यादा की नहीं।

तरीका 1: अपने होस्ट से मुफ्त SSL सर्टिफिकेट प्राप्त करें

यह सबसे तेज़ रास्ता है और पहले इसे ही आज़माएँ। लगभग हर होस्ट अब मुफ्त Let’s Encrypt सर्टिफिकेट देता है, अक्सर वह पहले से ही चालू होता है।

• अपना होस्टिंग कंट्रोल पैनल खोलें और SSL/TLS, Let’s Encrypt, या AutoSSL देखें। cPanel पर यह Security के अंतर्गत होता है।
• अपना डोमेन चुनें और सर्टिफिकेट जारी करें। एपेक्स डोमेन और www वर्ज़न दोनों शामिल करें, वरना उनमें से एक “name mismatch” चेतावनी देगा।
• पुष्टि करें कि ऑटो-रीन्यूअल सक्षम है। यही वह चरण है जिसे लोग अक्सर छोड़ देते हैं।

कोई होस्टिंग पैनल ही नहीं है, क्योंकि आप खुद अपना VPS या डेडिकेटेड सर्वर चलाते हैं? Certbot इस्तेमाल करें, जो Let’s Encrypt क्लाइंट है, जो कमांड लाइन से सर्टिफिकेट जारी करता है और खुद की रीन्यूअल शेड्यूल भी सेट करता है।

Let’s Encrypt सर्टिफिकेट 90 दिनों के लिए वैध होते हैं, और रीन्यूअल स्वतः होना चाहिए, आमतौर पर एक्सपायरी से लगभग 30 दिन पहले। जब यह ऑटोमेशन टूट जाता है, और वह टूटता है, आमतौर पर डोमेन शिफ्ट होने या DNS रिकॉर्ड बदलने के बाद, साइट हफ्तों तक ठीक रहती है और फिर बिना चेतावनी के “Not Secure” हो जाती है। पहली अपेक्षित रीन्यूअल तारीख के लिए अपने कैलेंडर में एक रिमाइंडर डालें और उस तारीख के गुजरने के बाद SSL Checker से सर्टिफिकेट जाँचें। यदि एक्सपायरी तारीख आगे बढ़ी है, तो रीन्यूअल काम कर रहा है।

तरीका 2: प्लगइन के ज़रिए वर्डप्रेस पर SSL इंस्टॉल करें

जिस प्लगइन का इस्तेमाल अधिकतर लोग करते हैं वह है Really Simple Security। इसे सितंबर 2024 तक Really Simple SSL कहा जाता था, जब वर्ज़न 9 ने इसका नाम बदल दिया क्योंकि इसके मुफ्त फीचर सेट ने SSL सेटअप से आगे बढ़कर विस्तार पा लिया था। इसके तीस लाख से ज़्यादा एक्टिव इंस्टॉलेशन हैं।

नाम के साथ जो बदलाव हुआ है वह यहाँ मायने रखता है: प्लगइन अब सिर्फ रीडायरेक्ट को फोर्स नहीं करता, बल्कि Let’s Encrypt विज़ार्ड के ज़रिए आपके लिए सर्टिफिकेट भी हासिल कर सकता है। तो अगर आपका होस्ट यह नहीं करता, तो यह पूरा काम कवर कर लेता है।

• Plugins > Add New Plugin से Really Simple Security को इंस्टॉल और एक्टिवेट करें।
• खुलने वाला ऑनबोर्डिंग फॉलो करें, या नए Security आइटम पर जाएँ जो प्लगइन एडमिन साइडबार में जोड़ता है। पुराने ट्यूटोरियल्स में Settings > SSL लिखा होता है, जहाँ नाम बदलने से पहले यह प्लगइन रहता था। यदि सर्वर पर पहले से ही कोई सर्टिफिकेट इंस्टॉल है, तो प्लगइन उसे पहचान लेता है।
• यदि कोई सर्टिफिकेट नहीं है, तो Install SSL certificate चुनें और मुफ्त Let’s Encrypt सर्टिफिकेट पाने के लिए विज़ार्ड फॉलो करें।
• Activate SSL चुनें। प्लगइन आपकी साइट URLs अपडेट करता है, रीडायरेक्ट सेट करता है, और डैशबोर्ड को HTTPS पर रीलोड करता है।

प्रतिबद्ध होने से पहले जानने लायक एक बात। जो प्लगइन HTTPS फोर्स करता है वह इसे PHP में करता है, हर रिक्वेस्ट पर। सर्वर कॉन्फ़िगरेशन में लिखा गया रीडायरेक्ट वर्डप्रेस लोड होने से पहले होता है, जो तेज़ है और यदि प्लगइन कभी डीएक्टिवेट हो जाए तो भी काम करता रहता है। यदि आप सर्वर फाइलों को एडिट करने में सहज हैं, तो यह बदलाव मैनुअली करें और प्लगइन को क्रिटिकल पाथ से बाहर रखें।

तरीका 3: SSL सर्टिफिकेट मैनुअली इंस्टॉल करें

पेड सर्टिफिकेट के लिए, या ऐसे किसी भी सर्वर के लिए जिसमें वन-क्लिक टूल नहीं है, यही रास्ता है। शेयर्ड होस्टिंग पर पहले यह जाँच लें कि आपका प्लान थर्ड-पार्टी सर्टिफिकेट इंस्टॉल करने की अनुमति देता है; कुछ बजट होस्ट अब भी इसे लॉक कर देते हैं या इसके लिए शुल्क लेते हैं।

• एक CSR जनरेट करें। सर्टिफिकेट साइनिंग रिक्वेस्ट आपके डोमेन और संगठन की जानकारी सर्टिफिकेट अथॉरिटी तक ले जाती है। हमारा CSR जनरेटर इस्तेमाल करें, या अपने विशेष सर्वर के लिए CSR गाइड्स फॉलो करें।
• CSR सबमिट करें सर्टिफिकेट अथॉरिटी को और वैलिडेशन पूरी करें। DV मिनटों में पूरा हो जाता है, OV और EV में कई दिन लगते हैं।
• फाइलें इंस्टॉल करें। आपको सर्टिफिकेट खुद मिलेगा, साथ ही एक या ज़्यादा इंटरमीडिएट सर्टिफिकेट। cPanel में, इन्हें SSL/TLS > Manage SSL sites के अंतर्गत पेस्ट करें, cPanel इंस्टॉलेशन गाइड फॉलो करते हुए। अन्य प्लेटफॉर्म्स SSL इंस्टॉलेशन गाइड्स में कवर किए गए हैं।
• वर्डप्रेस को छूने से पहले SSL Checker से वेरिफाई करें।

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

WordPress Multisite चलाने पर कुछ अतिरिक्त चरण जुड़ते हैं, जो Multisite SSL गाइड में कवर किए गए हैं।

अपनी वर्डप्रेस साइट को HTTP से HTTPS में बदलें

सर्टिफिकेट सर्वर पर है। वर्डप्रेस को अब भी इसके बारे में पता नहीं है। यहीं पर कई गाइड्स आपको हर चीज़ से पहले डेटाबेस सर्च और रिप्लेस चलाने के लिए भेजते हैं, जबकि अधिकतर साइटों के लिए यह वर्षों से ज़रूरी नहीं रहा है।

वर्डप्रेस खुद क्या करता है

मार्च 2021 में जारी हुए WordPress 5.7 के बाद से, कोर यह पता लगाता है कि आपका एनवायरनमेंट HTTPS सपोर्ट करता है या नहीं, और इसे Tools > Site Health > Status में HTTPS status सेक्शन के अंतर्गत रिपोर्ट करता है। जब HTTPS उपलब्ध होता है, तो वह सेक्शन एक बटन देता है जो एक क्लिक में साइट को बदल देता है।

इससे भी ज़्यादा ज़रूरी बात, जब Site Address (URL) और WordPress Address (URL) दोनों https पर होते हैं, तो वर्डप्रेस पेज को रेंडर करते समय आपकी सामग्री में असुरक्षित URLs को फिर से लिख देता है। आपके अपने डोमेन पर http एड्रेस के साथ सेव की गई इमेजेस, लिंक और एम्बेड बिना डेटाबेस को एडिट किए ही https पर सर्व होते हैं। यही वह चरण है जिसे पुराने ट्यूटोरियल्स आपको हाथ से करने के लिए कहते हैं।

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

दोनों URL सेटिंग्स बदलें

यदि Site Health वन-क्लिक बटन नहीं देता, या आप इसे स्पष्ट रूप से खुद करना चाहते हैं, तो Settings > General खोलें। यहाँ दो फील्ड्स हैं और दोनों बदलनी होंगी:

• WordPress Address (URL), जहाँ वर्डप्रेस फाइलें मौजूद हैं।
• Site Address (URL), वह एड्रेस जो विज़िटर्स टाइप करते हैं।

दोनों में http:// को https:// में बदलें, फिर सेव करें। सिर्फ एक को बदलना अपने आप को डैशबोर्ड से बाहर लॉक करने का सबसे आम तरीका है। यदि ऐसा हो जाता है, तो आप FTP के ज़रिए wp-config.php से दोनों सेट कर सकते हैं:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

इन लाइनों को उस लाइन के ऊपर जोड़ें जिसमें “That’s all, stop editing” लिखा है, और example.com को अपने डोमेन से बदलें। ध्यान दें कि जब ये कॉन्स्टेंट्स डिफाइन होते हैं, तो Settings > General के फील्ड्स रीड-ओनली हो जाते हैं।

जब आपको अब भी सर्च और रिप्लेस की ज़रूरत है

कोर की री-राइटिंग रेंडर की गई सामग्री को कवर करती है। यह हर जगह नहीं पहुँचती, इसलिए इनके लिए सर्च और रिप्लेस अब भी उपाय है:

• थीम फाइलों या functions.php में हार्डकोडेड URLs।
• सीरियलाइज़्ड डेटा के रूप में स्टोर की गई प्लगइन सेटिंग्स, यही वजह है कि आपको कभी भी सादा SQL फाइंड और रिप्लेस नहीं चलाना चाहिए।
• पेज बिल्डर्स द्वारा लिखी गई ऑप्शन्स रो, कस्टम फील्ड्स और विजेट कंटेंट।

Better Search Replace इस्तेमाल करें, जो सीरियलाइज़्ड डेटा को सही तरीके से संभालता है और इसमें ड्राई-रन मोड भी है, या WP-CLI इस्तेमाल करें:

wp search-replace 'http://example.com' 'https://example.com' --all-tables --dry-run

ड्राई रन का आउटपुट पढ़ें, फिर इसे लागू करने के लिए कमांड को –dry-run के बिना दोहराएँ। पहले डेटाबेस का बैकअप ले लें।

301 रीडायरेक्ट के साथ वर्डप्रेस में HTTPS फोर्स करें

आपकी साइट अब https पर उत्तर देती है, लेकिन यह अब भी http पर भी उत्तर देती है, और हर पुराना लिंक और बुकमार्क वहीं इशारा करता है। एक स्थायी HTTPS रीडायरेक्ट विज़िटर्स और सर्च इंजन दोनों को सुरक्षित वर्ज़न पर भेजता है और पुराने URLs के रैंकिंग सिग्नल्स को आगे बढ़ाता है। जहाँ भी संभव हो इसे PHP की बजाय सर्वर लेवल पर सेट करें।

Apache

इसे अपनी वर्डप्रेस रूट में .htaccess फाइल के सबसे ऊपर, वर्डप्रेस ब्लॉक से पहले जोड़ें:

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

R=301 फ्लैग ही इसे स्थायी बनाता है। [R,L] के रूप में लिखा गया रूल एक अस्थायी 302 जारी करता है, जो एक ऐसी गलती है जिसे जाँचना उचित है अगर आपने किसी पुराने गाइड से रीडायरेक्ट कॉपी किया है।

Nginx

Nginx में कोई .htaccess नहीं होता और यह Apache के लिए लिखे गए रीराइट रूल्स को नहीं समझता। इसके बजाय अपने साइट कॉन्फ़िगरेशन में सर्वर ब्लॉक एडिट करें:

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

nginx -t से कॉन्फ़िगरेशन टेस्ट करें, फिर systemctl reload nginx से रीलोड करें।

केवल डैशबोर्ड पर HTTPS फोर्स करें

लॉगिन्स और एडमिन एरिया को विशेष रूप से सुरक्षित करने के लिए, इसे wp-config.php में जोड़ें:

define( 'FORCE_SSL_ADMIN', true );

यह wp-admin और लॉगिन पेज को कवर करता है। यह फ्रंट एंड को रीडायरेक्ट नहीं करता, इसलिए यह इसे बदलने की बजाय सर्वर-लेवल रीडायरेक्ट को पूरक बनाता है।

HSTS, जब सब कुछ काम कर रहा हो

HSTS ब्राउज़र्स को आपके डोमेन के लिए सादे HTTP को पूरी तरह से मना करने के लिए कहता है, जिससे पहली रिक्वेस्ट और रीडायरेक्ट के बीच का गैप बंद हो जाता है। Apache पर:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

इसे तभी जोड़ें जब HTTPS कुछ समय से स्थिर रहा हो, और शुरुआत में preload डायरेक्टिव को बंद ही रखें। Preloading को जल्दी वापस पलटना मुश्किल है, और अगर किसी सबडोमेन पर अभी HTTPS नहीं है, तो वह अगम्य हो जाता है।

बदलाव के बाद जो बचता है उसे ठीक करें

मिक्स्ड कंटेंट

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

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

कैशेस और CDN

बदलाव के बाद अपना पेज कैश और अपना CDN पर्ज करें। किसी HTTP पेज की कैश की गई कॉपी पुराना मार्कअप सर्व करती रहेगी और एक पूरे हो चुके माइग्रेशन को भी टूटा हुआ दिखा देगी।

ईमेल और ट्रांज़ैक्शनल टेम्पलेट्स

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

वर्डप्रेस SSL समस्याओं का समाधान

लक्षण	सामान्य कारण	समाधान
अनंत रीडायरेक्ट लूप, ERR_TOO_MANY_REDIRECTS	Cloudflare SSL Flexible पर सेट है। Cloudflare आपके सर्वर से HTTP पर बात करता है, आपका सर्वर HTTPS पर रीडायरेक्ट करता है, Cloudflare इसे वापस भेज देता है	Cloudflare SSL/TLS एन्क्रिप्शन मोड को Full (strict) पर सेट करें और ओरिजिन पर एक वैध सर्टिफिकेट रखें
बदलाव के बाद wp-admin से लॉक आउट होना	दोनों में से सिर्फ एक URL फील्ड बदली गई थी	FTP के ज़रिए wp-config.php में WP_HOME और WP_SITEURL सेट करें
सिर्फ कुछ पेजों पर पैडलॉक गायब	उन पेजों पर मिक्स्ड कंटेंट	ब्राउज़र कंसोल में HTTP रिसोर्स ढूँढें, इसे स्रोत पर ठीक करें
साइट ठीक थी, हफ्तों बाद “Not Secure” हो गई	एक Let’s Encrypt सर्टिफिकेट एक्सपायर हो गया क्योंकि रीन्यूअल टूट गया था	दोबारा जारी करें, फिर अपने कंट्रोल पैनल में ऑटो-रीन्यूअल की पुष्टि करें
ब्राउज़र में काम करता है, ऐप या पेमेंट गेटवे के लिए फेल हो जाता है	चेन में इंटरमीडिएट सर्टिफिकेट गायब	पूरा CA बंडल इंस्टॉल करें, फिर SSL Checker से दोबारा जाँचें
www या एपेक्स पर नाम मिसमैच चेतावनी	सर्टिफिकेट दोनों में से सिर्फ एक को कवर करता है	सर्टिफिकेट को दोबारा जारी करें ताकि यह दोनों नामों को कवर करे; अकेले रीडायरेक्ट इसे ठीक नहीं कर सकता, चेतावनी किसी भी रीडायरेक्ट के चलने से पहले ही दिखती है

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

माइग्रेशन के बाद: SEO चेकलिस्ट और क्या उम्मीद करें

• Google Search Console में HTTPS प्रॉपर्टी जोड़ें। एक HTTP प्रॉपर्टी HTTPS URLs की रिपोर्ट नहीं करती। नई प्रॉपर्टी जोड़ें और पुरानी को भी रखें, या एक Domain प्रॉपर्टी इस्तेमाल करें, जो दोनों को कवर करती है। यदि आप Bing Webmaster Tools इस्तेमाल करते हैं, तो वहाँ भी अपडेट करें।
• अपनी XML साइटमैप को फिर से सबमिट करें https URLs के साथ।
• कैनोनिकल टैग्स जाँचें कि वे https की ओर इशारा करते हैं। साइट URLs बदलने पर अधिकतर SEO प्लगइन्स अपने आप अपडेट हो जाते हैं, लेकिन पेज सोर्स में इसकी पुष्टि करें।
• Google Analytics और Ads प्रॉपर्टी सेटिंग्स अपडेट करें, और वह कोई भी थर्ड पार्टी सर्विस जो आपकी साइट URL स्टोर करती है।
• इंटरनल लिंक्स अपडेट करें जहाँ वे एब्सोल्यूट हों। रिलेटिव लिंक्स को कुछ चाहिए नहीं होता।

बाद में सामान्य क्या दिखता है, क्योंकि यह उन लोगों को चिंतित करता है जिन्होंने यह पहले कभी नहीं किया: Search Console कुछ समय के लिए आपकी इंप्रेशंस को HTTP और HTTPS प्रॉपर्टीज़ में बँटा हुआ दिखाएगा जबकि Google फिर से क्रॉल करता है, और रैंकिंग्स सेटल होने से पहले अक्सर कुछ हफ्तों तक इधर-उधर होती हैं। Google एक HTTP से HTTPS मूव को URL बदलावों के साथ एक साइट मूव मानता है, इसलिए कुछ उतार-चढ़ाव अपेक्षित है, यह कोई संकेत नहीं है कि कुछ टूटा है। जब तक 301 रीडायरेक्ट्स लागू हैं और हर पेज रिज़ॉल्व हो रहा है, तब तक इंतज़ार करने के अलावा कुछ करने की ज़रूरत नहीं है।

एक बात साफ तौर पर कहने लायक है: HTTPS से वापस HTTP पर जाना किसी समस्या का लगभग कभी सही समाधान नहीं होता। इसका मतलब है एक दूसरा साइट मूव, रैंकिंग में एक और दौर की गड़बड़ी, और ब्राउज़र चेतावनियाँ वापस आ जाती हैं। यदि HTTPS समस्या पैदा कर रहा है, तो कारण लगभग हमेशा समस्या-निवारण तालिका में दी गई प्रविष्टियों में से एक होता है, और उसे ठीक करना माइग्रेशन को पलटने से कहीं सस्ता है।

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

किसी दूसरे प्लेटफॉर्म को HTTPS पर ले जा रहे हैं, या सामान्य प्रक्रिया चाहते हैं? हमारी गाइड देखें साइट को HTTP से HTTPS में कैसे बदलें।