'हो गया' वेबसाइट एक मिथक है: अपने बॉस को रखरखाव के लिए मनाएँ

Summary

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

आपके बॉस ने अभी वेबसाइट को 'हो गया' घोषित किया — तो उस शब्द से आपका पेट क्यों खाली हो जाता है?

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

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

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

निर्माण मोड और लाइव मोड अलग-अलग काम हैं

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

यह अंतर एक कारण से मायने रखता है: यह बदलता है कि आपका बॉस क्या स्वीकृत कर रहा है। बिल्ड मोड में, लक्ष्य 'इसे वास्तविक बनाना' है। लाइव मोड में, लक्ष्य 'इसे विश्वसनीय रखना' है। नीचे दी गई तालिका वह संस्करण है जिसका उपयोग मैं गैर-तकनीकी हितधारकों के साथ करता हूं, क्योंकि यह प्रत्येक चीज़ जो 'हो गया' लगती है, उसे इस बात से जोड़ता है कि वास्तव में साइट लाइव होने के बाद उसका क्या मतलब है।

क्षेत्र	बॉस को "हो गया" का क्या अर्थ लगता है	वास्तव में "हो गया" का क्या अर्थ है
डोमेन	हमने पता खरीदा, इसलिए यह हमारा है	पता एक अवधि के लिए पंजीकृत है; प्रक्रिया के ICANN के विवरण के अनुसार, आप एक नाम चुनते हैं, एक रजिस्ट्रार के माध्यम से उपलब्धता की जांच करते हैं, और संपर्क विवरण प्रदान करते हैं। वे विवरण निर्धारित करते हैं कि नवीनीकरण अधिसूचनाएं किसे मिलती हैं, इसलिए उन्हें सही और देखा जाना चाहिए
होस्टिंग	फाइलें इंटरनेट पर कहीं हैं	IBM वेब होस्टिंग को इंटरनेट एक्सेसिबिलिटी के लिए सर्वर पर आपकी साइट की फाइलों को संग्रहीत करने के रूप में परिभाषित करता है। वह सर्वर एक लागत के साथ एक आवर्ती संबंध है, और किसी को पता होना चाहिए कि इसमें कैसे लॉग इन करना है
सॉफ़्टवेयर	हमने नवीनतम संस्करण पर लॉन्च किया	सॉफ़्टवेयर को पैच किया जाता है, प्लगइन्स को अपडेट किया जाता है, और एकीकरण की समीक्षा की आवश्यकता होती है। यह सब लॉन्च के बाद होता है, पहले नहीं
सामग्री	प्रति स्वीकृत थी	सामग्री आपके बाजार के साथ बातचीत है। यह ऑफ़र, कीमतों, सबूत बिंदुओं और उत्पाद के नाम बदलने के साथ पुरानी हो जाती है
खोज	Google जानता है कि हम मौजूद हैं	खोज इंजनों पर फिर से जाने की आवश्यकता है; XML साइटमैप में नए URL जोड़े जाने चाहिए, robots.txt फाइलें सटीक रहनी चाहिए, और तकनीकी आधार स्वस्थ रहना चाहिए

आप उस तालिका को दो तरह से पढ़ सकते हैं। कामों की सूची के रूप में, यह भारी है। आपकी वेबसाइट वास्तव में क्या है — एक प्रणाली जिसमें आप नियंत्रित करते हैं — के विवरण के रूप में, यह स्पष्ट करने वाला है। आपका बॉस समापन चाहने में गलत नहीं है। वे इस बारे में गलत हैं कि समापन कैसा दिखता है।

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

रखरखाव को कैलेंडर बनाएं, डराने की कहानी नहीं

तो आप कहाँ से शुरू करते हैं? एक नाटकीय सुरक्षा प्रस्तुति के साथ नहीं। सबसे ठोस, कम से कम भावनात्मक आवर्ती कार्य से शुरू करें, और उसके चारों ओर एक कैलेंडर बनाएं।

डोमेन लें। कल्पना करें कि संस्थापक ने इसे पांच साल पहले व्यक्तिगत ईमेल पते के साथ पंजीकृत किया था। रजिस्ट्रार का डैशबोर्ड एक लॉगिन के पीछे है जिसे केवल एक व्यक्ति जानता है। ICANN की डोमेन पंजीकरण प्रक्रिया एक नाम चुनने, एक रजिस्ट्रार के माध्यम से उपलब्धता की जांच करने और संपर्क जानकारी प्रदान करने के साथ शुरू होती है — और वह संपर्क जानकारी रजिस्ट्रार को एक वास्तविक मानव से जोड़ने वाली कड़ी है। यदि संपर्क ईमेल को नहीं देखा जाता है, तो नवीनीकरण अधिसूचना एक मेलबॉक्स में आ सकती है जिसे कोई नहीं पढ़ता है। समाधान एक तकनीकी सुधार नहीं है; यह एक स्प्रेडशीट लाइन, एक साझा इनबॉक्स और नवीनीकरण से तीन सप्ताह पहले एक कैलेंडर अनुस्मारक है। यह उबाऊ है। यही कारण है कि यह पहला आइटम है: यह साबित करता है कि रखरखाव छोटे, प्रबंधनीय कार्यों से बना है।

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

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

वह खतरा जो हैकर नहीं है

सुरक्षा वार्तालाप आमतौर पर विफल रहता है क्योंकि यह गलत खलनायक से शुरू होता है। 'हम एक छोटी मार्केटिंग साइट हैं,' आप खुद से कहते हैं। 'कोई हमें निशाना नहीं बना रहा है।' और आप शायद सही हैं — लेकिन सबसे संभावित खतरा एक लक्षित हैकर नहीं है। यह उपेक्षा है।

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

आइए इसे ठोस बनाते हैं। कई इन-हाउस टीमों को एक साझा एडमिन लॉगिन के साथ एक साइट विरासत में मिलती है जिसका उपयोग हर कोई करता है: सेल्स टीम, मार्केटिंग इंटर्न, फ्रीलांसर जिसने एक ब्लॉग पोस्ट लिखा था। कोई नहीं जानता कि फ्रीलांसर कौन था। UpGuard इसे उपयोगकर्ता विशेषाधिकार समस्या कहेगा; आप इसे एक जोखिम कह सकते हैं जिसे आपका बॉस पहले से समझता है। यदि आप नहीं जानते कि कौन लॉग इन कर सकता है, तो आप नहीं जानते कि होमपेज को कौन संपादित कर सकता है, मूल्य निर्धारण बदल सकता है, या कुछ ऐसा स्थापित कर सकता है जो वहाँ नहीं होना चाहिए। समाधान सरल है: पासवर्ड रीसेट करें, व्यक्तिगत खाते बनाएं, और लोगों के जाने पर पहुंच हटा दें। यह एक सुरक्षा परियोजना नहीं है; यह एक सुरक्षा कार्य है।

मैं एक विपरीत सुझाव दूंगा: बजट के लिए प्रस्ताव देते समय सुरक्षा के साथ नेतृत्व न करें। एक छोटी टीम के लिए, 'सुरक्षा' शब्द या तो 'हमारे पास आईटी बजट नहीं है' या 'ऐसा हमारे साथ नहीं होगा' ट्रिगर करता है। जो कार्रवाई ट्रिगर करता है वह एक ठोस निकट-मिस है: एक ब्राउज़र चेतावनी क्योंकि SSL/TLS प्रमाणपत्र समाप्त हो गया, एक बैकअप जो कभी नहीं चला, एक पूर्व ठेकेदार जो अभी भी लॉग इन कर सकता है। उन ठोस वस्तुओं का उपयोग मासिक 'साइट स्वास्थ्य' ब्लॉक के लिए एक मामला बनाने के लिए करें। आप डर नहीं बेच रहे हैं; आप क्षमता बेच रहे हैं।

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

खोज आपका इंतजार नहीं करती

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

एक यथार्थवादी परिदृश्य: आपके बिक्री प्रमुख पूछते हैं कि एक प्रतियोगी आपके अपने उत्पाद नाम के लिए आपसे आगे क्यों है। आप जांच करते हैं और पाते हैं कि XML साइटमैप लॉन्च के बाद से अपडेट नहीं हुआ है, और robots.txt फ़ाइल नए पृष्ठों के एक अनुभाग को ब्लॉक कर रही है। ये दोनों तकनीकी सेटअप कार्य हैं जो पहले दिन किए गए लगते थे। समाधान एक दस मिनट की मासिक समीक्षा है: साइटमैप में नए URL जोड़ें, इसे फिर से सबमिट करें, और जांचें कि robots फ़ाइल आपकी सर्वोत्तम सामग्री छिपा नहीं रही है। SEO मार्गदर्शन पर शोध भी तकनीकी आधार के हिस्से के रूप में HTTPS सुरक्षा की ओर इशारा करता है — जो आपके द्वारा अभी निर्धारित सुरक्षा कार्यों पर वापस लूप करता है।

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

चेक पर हस्ताक्षर करने वाले व्यक्ति को रखरखाव बेचना

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

राजस्व सुरक्षा के साथ नेतृत्व करें। यह मत कहें कि 'हमारे पास तकनीकी ऋण है' या 'हमें अपने CMS को अपडेट करने की आवश्यकता है।' कहें 'साइट स्टोरफ्रंट है, और स्टोरफ्रंट को नियमित रखरखाव की आवश्यकता होती है।' सबूत के रूप में आपके द्वारा पहले बनाए गए रखरखाव कैलेंडर का उपयोग करें: यहाँ नवीनीकरण की तारीखें हैं, यहाँ पहुंच समीक्षाएँ हैं, यहाँ बैकअप परीक्षण है जो हम हर महीने चलाते हैं। बॉस से आप पर भरोसा करने के लिए नहीं कहा जा रहा है; उन्हें एक ऐसी प्रणाली दिखाई जा रही है जो पहले से चल रही है।

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

एक चेतावनी: बॉस अभी भी ना कह सकता है। यदि ऐसा होता है, तो शीर्ष दो जोखिम लें — आमतौर पर एक्सेस नियंत्रण और बैकअप सत्यापन — और अपने खाली समय में उन्हें वैसे भी ठीक करें। आप ना को अनदेखा नहीं कर रहे हैं; आप यह दिखाने के लिए समय खरीद रहे हैं कि रखरखाव एक मापने योग्य अंतर बनाता है। यह वही तर्क है जो क्लाइंट साइट रखरखाव परिपक्वता मॉडल के पीछे है, भले ही आपका 'क्लाइंट' आपका अपना आंतरिक हितधारक हो। मॉडल एक साइट को आग से फ्रेमवर्क में ले जाता है, और यह दो-व्यक्ति मार्केटिंग टीम में उतना ही अच्छा काम करता है जितना एक एजेंसी में।

पूर्ण वेबसाइट मौजूद नहीं है

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

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