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

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

साइट में पहले स्पैम आया, फिर क्रिटिकल एरर

इस केस के बैकग्राउंड में Newspaper 12 का पुराना सेटअप था। काम से जुड़ी जानकारी के मुताबिक, साइट पर अनऑफिशियल क्रैक कॉपी इस्तेमाल हो रही थी, जिसे GPL के नाम पर लिया गया था। शुरुआत में वेबसाइट ठीक चली। कुछ दिन बाद ऐसे पोस्ट आने लगे जिन्हें टीम ने पब्लिश नहीं किया था। फिर नए यूजर अकाउंट बनने लगे और आखिर में साइट पर “There has been a critical error on this website” मैसेज आ गया।

यहाँ एक बात समझ लें: GPL अपने आप में क्रैक या मालवेयर का नाम नहीं है। वर्डप्रेस भी GPL लाइसेंस पर मिलता है। किसी पैकेज पर GPL लिखा होने से वह खराब साबित नहीं होता, और केवल “प्रीमियम” लिखा होने से उसकी फाइलें सुरक्षित साबित नहीं हो जातीं। इस केस में पैकेज का सोर्स भरोसेमंद नहीं था, लेकिन हमारे पास ऐसा फॉरेंसिक रिकॉर्ड नहीं है जो बताए कि अनजान पोस्ट किस फाइल या रास्ते से बने। इसलिए इसे Newspaper की हर कॉपी की समस्या कहना सही नहीं होगा।

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

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

फाइल मैनेजर से हमने समस्या कैसे खोजी?

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

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

प्लगइन का फोल्डर रीनेम करना एक टेम्पररी टेस्ट है। उदाहरण के लिए, सामान्य प्लगइन के wp-content/plugins/plugin-name फोल्डर को plugin-name-disabled करने पर वर्डप्रेस उसे पुराने रास्ते से लोड नहीं कर पाएगा। डैशबोर्ड खुल जाए तो प्लगइन पेज पर उसका स्टेटस चेक करें। सारे सामान्य प्लगइन टेस्ट करने के लिए plugins को plugins.hold किया जा सकता है। प्लगइन पेज खोलने के बाद नाम वापस करें और सिर्फ जाँचे हुए प्लगइन एक-एक करके चालू करें।

स्क्रीनशॉट में दिख रहा mu-plugins अलग तरह का फोल्डर है। इसमें होस्टिंग कंपनी के जरूरी टूल भी हो सकते हैं और ये सामान्य प्लगइन की तरह बंद नहीं होते। इसलिए केवल plugins रीनेम करने से पूरी साइट का हर प्लगइन बंद नहीं होगा। इसी तरह uploads, upgrade या दूसरे अपरिचित फोल्डर देखकर उन्हें डिलीट न करें। नाम और “Last modified” समय जाँच शुरू करने के संकेत हैं, आखिरी फैसला नहीं।

प्लगइन की जाँच के बाद भी क्रिटिकल एरर की समस्या पूरी तरह नहीं हटी, इसलिए हमने wp-content/themes चेक किया। इस केस में एक्टिव थीम बंद करने के बाद एरर हट गया। इससे थीम या उसके साथ चल रहे कोड की तरफ मजबूत संकेत मिला। इससे यह साबित नहीं होता कि स्पैम भी उसी थीम ने बनाया था; उसके लिए अलग जाँच चाहिए। रिकॉर्डिंग के बाद वाले हिस्से में डैशबोर्ड खुलता है और tagDiv Cloud Library तथा Opt-In Builder की थीम-वर्जन से जुड़ी चेतावनियाँ दिखाई देती हैं।

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

एरर हटने के बाद डिजाइन और सिक्योरिटी कैसे संभालें?

क्लाइंट के लिए अगला सवाल सीधा होता है: “साइट खुल गई, लेकिन पुराना डिजाइन कहाँ गया?” थीम बदलने पर हेडर, मेन्यू की जगह, विजेट, पेज बिल्डर के ब्लॉक और लेआउट अलग दिख सकते हैं। इससे यह जरूरी नहीं कि पोस्ट, पेज और इमेज डिलीट हो गई हों। क्लाइंट को पहले ही बता दें कि शुरुआती टेस्ट में डिजाइन कुछ समय के लिए बदल सकता है। पुराना लेआउट वापस लाने का काम उसके बाद किया जाएगा।

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

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

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

सफाई के दौरान होस्टिंग टीम से मालवेयर स्कैन और लॉग की मदद लें। टीम से हर एडमिन अकाउंट कन्फर्म कराएँ; संदिग्ध अकाउंट हटाते समय उसके असली पोस्ट सही यूजर को असाइन करें। साफ डिवाइस से वर्डप्रेस और होस्टिंग के पासवर्ड बदलें, पुराने लॉगिन सेशन खत्म करें और जहाँ संभव हो 2FA लगाएँ। वर्डप्रेस की ऑथेंटिकेशन कीज़ और सॉल्ट्स रीसेट करने से पुराने सेशन लॉगआउट किए जा सकते हैं। डेटाबेस का पासवर्ड बदलें तो wp-config.php में भी सही डिटेल अपडेट करनी होगी।

कुछ समय तक नए यूजर, पोस्ट और फाइलों में बदलाव पर नजर रखें। सर्च कंसोल में सिक्योरिटी रिपोर्ट भी चेक करें। बैकअप या सिक्योरिटी टूल मदद कर सकते हैं, लेकिन सिर्फ नया प्लगइन लगा देना पूरी क्लीनअप की जगह नहीं ले सकता। होस्टिंग और सिक्योरिटी टूल का फर्क हमारे WordPress.com, Pressable और Jetpack वाले गाइड में समझ सकते हैं।

होस्टिंग चुनते समय अपने अकाउंट में फाइल मैनेजर या SFTP, बैकअप रिस्टोर और सपोर्ट के ऑप्शन देखें। तुलना के लिए HostArmada के प्लान और ChemiCloud के प्लान देख सकते हैं। साफ कॉपी तैयार किए बिना होस्टिंग बदलने से संक्रमित फाइलें नई जगह भी पहुँच सकती हैं। ये अफिलिएट लिंक हैं; इनके जरिए खरीदने पर WebTakniki को कमीशन मिल सकता है, आपके लिए कोई एक्स्ट्रा चार्ज नहीं जुड़ता।

इस केस से सीख और कुछ जरूरी सवाल

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

क्या क्रिटिकल एरर हमेशा थीम या प्लगइन से आता है?

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

क्या हर GPL थीम क्रैक होती है?

नहीं। GPL एक ओपन-सोर्स लाइसेंस है। क्रैक या नल्ड पैकेज और GPL को एक ही चीज न समझें। जिस जगह से पैकेज मिला है, उसकी फाइलों, अपडेट और सपोर्ट पर भरोसा होना जरूरी है।

क्या रीनेम करने से मालवेयर हट जाता है?

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

क्या होस्टिंग एक्सेस के बिना साइट ठीक हो सकती है?

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

क्या नई थीम डालते ही पुराना डिजाइन लौट आएगा?

उसी थीम की साफ और कम्पैटिबल कॉपी से डिजाइन लौट सकता है। फिर भी थीम सेटिंग, चाइल्ड थीम और साथ वाले प्लगइन चेक करने होंगे। पूरी साइट देखे बिना पहले जैसा डिजाइन लौटने का वादा नहीं करना चाहिए।

WebTakniki की सलाह: पायरेटेड, क्रैक या अनजान सोर्स से मिले बदले हुए थीम और प्लगइन पैकेज इस्तेमाल न करें। इनमें छिपा कोड हो तो वेबसाइट का डेटा और लॉगिन डिटेल खतरे में पड़ सकती हैं। भरोसेमंद सोर्स, समय पर अपडेट और रिस्टोर किया जा सकने वाला बैकअप रखें। GPL लिखा होना अकेले किसी पैकेज के सुरक्षित या असुरक्षित होने का सबूत नहीं है।