मौजूदा साइट को AI बिल्डर में माइग्रेट करना: इसे गलत करने के तीन तरीके

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

इसके गलत होने के तीन तरीके इतनी बार सामने आते हैं कि मैं सब्जेक्ट लाइन आगे पढ़ने से पहले ही सपोर्ट टिकट का अंदाज़ा लगा सकता हूं। सही तरीका कोई चालाकी भरा नहीं है। यह बस वह चीज़ है जिस तक आप पहुंचते हैं जब आप ये तीन गलतियां करना बंद कर देते हैं।

गलती एक: पुराना कंटेंट डाल देना और उम्मीद करना कि स्ट्रक्चर खुद-ब-खुद ठीक हो जाएगा

यह प्रवृत्ति समझ में आती है। आपके पास एक साइट है, उसमें शब्द हैं, तो आप शब्दों को चैट में पेस्ट कर देते हैं और बिल्डर से "इसे बेहतर बनाओ" कहते हैं। जो निकलता है वह आमतौर पर एक ऐसी साइट होती है जो दिखने में नई लगती है पर पढ़ने में पुरानी — वही रन-ऑन सर्विस पैराग्राफ़, वही तीन हेडिंग्स जो पंद्रह का काम करती हैं, बस अब एक बेहतर टेम्पलेट में लिपटी हुई। बिल्डर ने वही किया जो आपने कहा। आपने उसे रीडेकोरेट करने को कहा, दोबारा सोचने को नहीं।

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

मेरे पास एक क्लाइंट था जिसका "Services" पेज 4,000 शब्दों का था और उसमें ग्यारह अलग-अलग ऑफ़र कवर होते थे। वह इसे जस-का-तस माइग्रेट करना चाहती थी क्योंकि "यह हमेशा से काम करता रहा है।" यह काम नहीं कर रहा था — यह किसी खास चीज़ के लिए रैंक नहीं करता था क्योंकि यह एक साथ सब कुछ के बारे में था। इसे वफ़ादारी से माइग्रेट करना बस उसी न-रैंक करने वाले पेज का एक ज़्यादा सुंदर वर्ज़न बना देता।

यहां असल में जो काम करता है वह है माइग्रेशन को बिल्ड से पहले एक ऑडिट की तरह मानना। पुराना कंटेंट डालें, लेकिन पहले एक कंटेंट इन्वेंटरी मांगें: कौन-कौन से पेज मौजूद हैं, हर एक असल में किस चीज़ के लिए रैंक करने की कोशिश कर रहा है, कहां दो विषय एक ही URL में ठूंस दिए गए हैं और कहां एक विषय पांच पेजों में पतला फैला हुआ है। यह इन्वेंटरी ही प्लान बन जाती है। पुरानी साइट एक सोर्स है, टेम्पलेट नहीं।

गलती दो: यह भूल जाना कि URL ही वह चीज़ है जिस पर Google असल में भरोसा करता है

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

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

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

गलती तीन: बिना वापसी के रास्ते वाला बड़ा धमाकेदार कटओवर

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

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

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

सही तरीका असल में कैसा दिखता है

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