WordPress को शेयर्ड होस्टिंग से VPS पर कैसे ले जाएँ

ईमेल या DNS खोए बिना शेयर्ड होस्टिंग से VPS पर WordPress साइट कैसे ले जाएँ

WordPress को शेयर्ड होस्टिंग से वर्चुअल प्राइवेट सर्वर (VPS) पर ले जाने से PHP, सर्वर संसाधनों और कॉन्फ़िगरेशन पर आपका नियंत्रण बढ़ सकता है। लेकिन अगर आप इस प्रक्रिया को सिर्फ़ फ़ाइलें कॉपी करना समझें, तो ईमेल सेवा बाधित हो सकती है या विज़िटर गलत जगह पहुँच सकते हैं। सबसे ज़रूरी है कि वेबसाइट को उन सेवाओं से अलग रखें जो पहले से आपके डोमेन पर निर्भर हैं।

अगर आप जानना चाहते हैं कि WordPress साइट को VPS पर कैसे माइग्रेट करें, तो पहले यह सूची बनाएँ कि आपका मौजूदा होस्ट वास्तव में कौन-कौन सी सेवाएँ देता है। डोमेन का रजिस्ट्रेशन एक कंपनी के पास, DNS दूसरी के पास, ईमेल तीसरी के पास और WordPress चौथी कंपनी के पास हो सकता है। इन सभी सेवाओं को एक साथ स्थानांतरित करना ज़रूरी नहीं है।

1. माइग्रेशन का दायरा तय करें: वेबसाइट को उन सेवाओं से अलग रखें जो वहीं रहेंगी

लिख लें कि WordPress की फ़ाइलें और डेटाबेस कहाँ हैं, फिर पता करें कि हर संबंधित सेवा का ज़िम्मेदार प्रदाता कौन है। डोमेन रजिस्ट्रार, DNS होस्ट, ईमेल प्रदाता और CDN या इमेज स्टोरेज जैसी किसी अलग सेवा की जाँच करें। होस्टिंग कंट्रोल पैनल में इनमें से कुछ जानकारी दिख सकती है, लेकिन डोमेन के नेमसर्वर और DNS रिकॉर्ड बताते हैं कि ट्रैफ़िक वास्तव में कहाँ भेजा जा रहा है।

उदाहरण के लिए, कोई साइट शेयर्ड होस्टिंग पर चल सकती है, उसका DNS Cloudflare के ज़रिए प्रबंधित हो सकता है और कर्मचारियों का ईमेल Google Workspace पर हो सकता है। ऐसी स्थिति में WordPress को VPS पर ले जाने के लिए डोमेन या ईमेल खातों को स्थानांतरित करने की ज़रूरत नहीं होती। आम तौर पर सिर्फ़ वे रिकॉर्ड बदलने होते हैं जो वेब ट्रैफ़िक को सही जगह भेजते हैं; मेल रिकॉर्ड वैसे ही रहने चाहिए।

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

2. उन निर्भरताओं की पहचान करें जो साधारण साइट कॉपी में छूट सकती हैं

WordPress बैकअप में साइट की फ़ाइलें और डेटाबेस हो सकते हैं, लेकिन ज़रूरी नहीं कि उसमें साइट पर निर्भर हर सेवा शामिल हो। शेड्यूल किए गए टास्क, बाहर भेजे जाने वाले ईमेल की सेटिंग, एक्सटर्नल स्टोरेज, रीडायरेक्ट, SSL व्यवस्था और सर्वर-विशिष्ट कॉन्फ़िगरेशन जाँचें। उदाहरण के लिए, किसी मेंबरशिप साइट में खातों की अवधि समाप्त करने के लिए शेड्यूल किया गया जॉब ज़रूरी हो सकता है, जबकि कोई ऑनलाइन स्टोर ऑर्डर के संदेश भेजने के लिए बाहरी SMTP सेवा इस्तेमाल कर सकता है।

शेड्यूल किए गए जॉब के लिए होस्टिंग कंट्रोल पैनल और WordPress प्लगइन देखें। WordPress का अंतर्निर्मित टास्क सिस्टम किसी विज़िटर के पेज खोलने पर चल सकता है, जबकि सर्वर का cron job तय समय पर किसी खास स्क्रिप्ट को चला सकता है। हर जॉब का कमांड, चलने की आवृत्ति और टाइम ज़ोन लिख लें। अगर VPS पर उसका नया cron entry नहीं बनाया गया, तो पुराने होस्ट पर हर घंटे चलने वाला टास्क माइग्रेशन के बाद बंद हो सकता है।

जाँचें कि साइट ईमेल कैसे भेजती है। लिख लें कि वह होस्टिंग प्रदाता का मेल सर्वर, SMTP प्लगइन या ट्रांज़ैक्शनल ईमेल सेवा इस्तेमाल करती है, और यह भी पुष्टि करें कि साइट किस प्रेषक पते का उपयोग करती है। अगर मेल सर्वर पुराने होस्ट ने दिया था, तो हो सकता है कि वही सेटिंग VPS से काम न करे। ईमेल प्रदाता से पूछें कि क्या वह कनेक्शन सीमित करता है या किसी खास प्रमाणीकरण तरीके की ज़रूरत है।

एक्सटर्नल स्टोरेज और सर्वर सेटिंग की सूची भी बना लें। कोई मीडिया प्लगइन अपलोड को WordPress के uploads फ़ोल्डर के बजाय ऑब्जेक्ट स्टोरेज में रख सकता है। साइट किसी खास PHP वर्ज़न, PHP एक्सटेंशन, rewrite rules या .htaccess की सेटिंग पर निर्भर हो सकती है। इन जानकारियों की कॉपी रखें; साइट लाइव होने के बाद अंदाज़े से काम करने पर छोटी-सी संगतता समस्या भी लंबे आउटेज में बदल सकती है।

3. साइट की वास्तविक ज़रूरतों के मुताबिक VPS तैयार करें

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

डेटाबेस, वेब सर्वर और PHP हैंडलर सेट अप करें। फिर फ़ाइलों के स्वामित्व और अनुमतियाँ इस तरह कॉन्फ़िगर करें कि WordPress फ़ाइलें पढ़ सके और सिर्फ़ ज़रूरत पड़ने पर उनमें लिख सके। किसी त्रुटि को दबाने के लिए हर फ़ाइल को लिखने योग्य न बनाएँ। एडमिनिस्ट्रेटिव ऐक्सेस सीमित करें, फ़ायरवॉल चालू करें और डेटाबेस तथा साइट फ़ाइलों—दोनों का बैकअप लेने की व्यवस्था करें।

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

4. लाइव साइट में बदलाव किए बिना फ़ाइलें और डेटाबेस स्थानांतरित करें

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

अगर साइट पर बार-बार बदलाव होते हैं, तो पहले बैकअप के बाद बनाए गए नए ऑर्डर, टिप्पणियों या पोस्ट को संभालने की योजना बनाएँ। एक तरीका है कि पहले कॉपी लेकर निजी तौर पर उसकी जाँच करें और फिर थोड़े समय की मेंटेनेंस विंडो में डेटाबेस दोबारा ट्रांसफ़र करें। ऑनलाइन स्टोर के लिए, दोनों कॉपी पर ऑर्डर लेना बंद रखें—डुप्लिकेट या गायब ऑर्डर का डेटा सुधारना, पहले से घोषित थोड़े समय के विराम से कहीं मुश्किल है।

फ़ाइलें और डेटाबेस VPS पर ले जाएँ, फिर ज़रूरत के अनुसार WordPress कॉन्फ़िगरेशन में नया डेटाबेस नाम, यूज़र, पासवर्ड और होस्ट अपडेट करें। पुरानी और नई सेटिंग का सुरक्षित रिकॉर्ड रखें। अगर डोमेन या फ़ाइल पाथ बदलते हैं, तो साइट सेटिंग सावधानी से अपडेट करें। सीरियलाइज़्ड डेटा को सही ढंग से संभाले बिना बड़े पैमाने पर search-and-replace करने से डेटाबेस खराब हो सकता है।

अभी सार्वजनिक DNS को VPS की ओर न मोड़ें। निजी कॉपी की जाँच के दौरान पुराना होस्ट ही सार्वजनिक डेस्टिनेशन बना रहना चाहिए। जब तक आप ट्रैफ़िक स्थानांतरित करने के लिए तैयार न हों, नए सर्वर पर ग्राहकों की असली गतिविधि नहीं आनी चाहिए।

5. सार्वजनिक DNS बदलने से पहले निजी तौर पर जाँच करें

सार्वजनिक DNS बदले बिना अपने ब्राउज़र को VPS पर भेजने के लिए अपने कंप्यूटर की hosts फ़ाइल में override जोड़ें या अस्थायी staging hostname इस्तेमाल करें। hosts फ़ाइल का override सिर्फ़ उसी डिवाइस पर असर करता है जहाँ उसे जोड़ा जाता है, इसलिए नए साइट की जाँच दूसरे विज़िटर से पहले करने के लिए यह उपयोगी है। जाँच के बाद यह एंट्री हटा दें, ताकि निजी रूट को सार्वजनिक रूट न समझ बैठें।

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

शेड्यूल किए गए टास्क और साइट को बाहर से कॉल करने वाले इंटीग्रेशन भी जाँचें। उदाहरण के लिए, पेमेंट सेवा किसी खास URL पर सूचना भेज सकती है, जबकि मॉनिटरिंग सेवा किसी विशेष जवाब की उम्मीद कर सकती है। VPS पर HTTPS भी जाँचें। staging hostname का प्रमाणपत्र प्रोडक्शन डोमेन से मेल न खाए, इसलिए विज़िटर को नए सर्वर पर भेजने से पहले अंतिम सर्टिफ़िकेट व्यवस्था की जाँच करें।

प्रोडक्शन डोमेन के लिए रीडायरेक्ट और canonical URL देखें। अगर साइट की बाउंस रेट ज़्यादा है, तो खराब लैंडिंग पेज या रीडायरेक्ट समस्या को और बढ़ा सकता है; यह गाइड बताती है कि वेबसाइट की अच्छी बाउंस रेट क्या होती है और इस मेट्रिक को कैसे समझें। माइग्रेशन टेस्ट में खास गड़बड़ियों पर ध्यान दें, जैसे त्रुटि देने वाला फ़ॉर्म या ऐसा अपलोड जो दिखाई न दे।

6. ईमेल और रोलबैक की योजना के साथ DNS बदलें

DNS बदलने से पहले मौजूदा रिकॉर्ड सेव करें और साफ़-साफ़ लिखें कि किन वेब रिकॉर्ड को अपडेट करना है। अगर वेबसाइट के लिए डोमेन A रिकॉर्ड इस्तेमाल करता है, तो उसका डेस्टिनेशन VPS के पते पर बदलें। अगर वेब hostname के लिए CNAME है, तो ज़रूरत के अनुसार उसे अपडेट करें। मेल रिकॉर्ड—MX रिकॉर्ड और ईमेल प्रमाणीकरण के लिए इस्तेमाल होने वाले TXT रिकॉर्ड सहित—ज्यों के त्यों रखें, जब तक कि आप जान-बूझकर ईमेल प्रदाता न बदल रहे हों।

WordPress माइग्रेशन में ईमेल और DNS कैसे सुरक्षित रखें, इसका मुख्य नियम है कि DNS बदलाव से पहले रिकॉर्ड की कॉपी लें और वेब रिकॉर्ड को मेल रिकॉर्ड से अलग पहचानें। माइग्रेशन से पहले DNS का time to live (TTL) कम करने से कुछ resolvers को नया डेस्टिनेशन जल्दी मिल सकता है, लेकिन इससे यह गारंटी नहीं मिलती कि बदलाव पूरी दुनिया में तुरंत लागू हो जाएगा। रिकॉर्ड संपादित करने से पहले मौजूदा DNS सेटअप और प्रदाता के निर्देश देखें। अगर आप proxy या CDN इस्तेमाल करते हैं, तो पुष्टि करें कि origin address सीधे VPS की ओर जाना चाहिए या नहीं, और proxy का SSL mode वहाँ इंस्टॉल किए गए सर्टिफ़िकेट से मेल खाता है या नहीं।

ऐसा cutover समय चुनें जब आप साइट पर नज़र रख सकें और समस्या आने पर तुरंत कार्रवाई कर सकें। तय किया हुआ वेब रिकॉर्ड बदलें, फिर एक से अधिक नेटवर्क या DNS lookup सेवा से डोमेन जाँचें। रोलबैक के निर्देश लिखकर रखें: पुराने वेब डेस्टिनेशन को बहाल करें, यह तय रखें कि बदलाव कौन कर सकता है और पुराने होस्टिंग खाते का ऐक्सेस बनाए रखें। DNS कैश के कारण विज़िटर पुराने होस्ट पर जा सकते हैं, इसलिए साइट को तुरंत बंद न करें।

cutover के दौरान ईमेल की अलग से जाँच करें। किसी बाहरी खाते से डोमेन के पते पर संदेश भेजें और संभव हो तो उसी पते से जवाब दें। अगर ईमेल बंद हो जाए, तो और बदलाव करने से पहले मौजूदा DNS रिकॉर्ड की सेव की गई कॉपी से तुलना करें। वेब सर्वर स्थानांतरित करने के लिए मेल रिकॉर्ड हटाने की ज़रूरत नहीं होनी चाहिए।

7. लॉन्च के बाद नए सेटअप की पुष्टि करें

जब सार्वजनिक ट्रैफ़िक VPS पर आने लगे, तो HTTPS, ज़रूरी पेज, फ़ॉर्म, लॉगिन और कमाई से जुड़े कामकाज की जाँच करें। WordPress और सर्वर—दोनों के लॉग में PHP त्रुटियाँ, फ़ाइल ऐक्सेस अस्वीकृत होने, डेटाबेस कनेक्शन विफल होने या बार-बार न मिलने वाले URL के अनुरोध देखें। होमपेज सामान्य दिख सकता है, जबकि किसी प्लगइन की त्रुटि से संपर्क फ़ॉर्म चुपचाप काम करना बंद कर दे।

पुष्टि करें कि VPS पर बैकअप चल रहे हैं और आपको पता है कि उन्हें कैसे बहाल करना है। बैकअप की जगह जाँचें और यह भी पक्का करें कि हाल के बैकअप में डेटाबेस तथा फ़ाइलें—दोनों मौजूद हैं। उपलब्धता और सर्टिफ़िकेट की समय-सीमा की निगरानी सेट अप करें, फिर यह पुष्टि करें कि ईमेल दोनों दिशाओं में काम कर रहा है। पुरानी होस्टिंग योजना रद्द करने से पहले ये जाँच ज़रूर कर लें।

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