कैसे एक वेबसाइट को लॉन्च के लिए तैयार करें बिना SEO ट्रैफ़िक खोए

कैसे एक वेबसाइट को लॉन्च के लिए तैयार करें बिना SEO ट्रैफिक खोए

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

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

1. लॉन्च से पहले “बदले नहीं जाने वाले” SEO तत्वों को परिभाषित करें

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

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

कुछ पृष्ठ स्वतंत्र रूप से बदल सकते हैं। कुछ नहीं कर सकते। एक होमपेज अधिक परिवर्तन को अवशोषित कर सकता है बनाम एक पृष्ठ जो तीन मुख्य प्रश्नों के लिए रैंक करता है और पांच लेखों से बैकलिंक्स प्राप्त करता है। यह अंतर चेकलिस्ट में स्पष्ट होना चाहिए, न कि एक स्प्रेडशीट में जो कोई दो बार नहीं खोलता।

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

2. पुराने साइट को नए साइट के पृष्ठ के अनुसार मैप करें

सामग्री स्थानांतरित होने से पहले एक प्रतिस्थापन मानचित्र बनाएं। हर महत्वपूर्ण पुराने URL को एक सटीक नए गंतव्य की आवश्यकता होती है, न कि एक अस्पष्ट श्रेणी पृष्ठ और न ही एक "काफी करीब" विकल्प। यदि एक पुराना लेख दो नए पृष्ठों में बदल जाता है, तो दोनों गंतव्यों और विभाजन के कारण को नोट करें।

इस मानचित्र में वे पृष्ठ शामिल होने चाहिए जो विलय, नाम बदलने या रिटायर किए गए हैं। एक रिटायर पृष्ठ को अभी भी एक उत्तर की आवश्यकता होती है। यदि इसके लिंक, ट्रैफ़िक, या खोज परिणामों में एक इतिहास था, तो इसे बस गायब नहीं होना चाहिए। मानचित्र को यह बताना चाहिए कि पृष्ठ एक प्रतिस्थापन, एक माता-पृष्ठ, या समान इरादे के साथ एक नए समकक्ष की ओर इंगित करता है।

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

एक व्यावहारिक ट्रिक: मानचित्र को प्रिंट करें और सबसे महत्वपूर्ण 20 यूआरएल को एक पेन से ट्रेस करें। यह पुरानी शैली की तरह लगता है। यह काम करता है। आप कागज पर 400 पंक्तियों के भीड़भाड़ वाले शीट की तुलना में तेजी से गायब गंतव्यों को नोटिस करते हैं।

3. उन पृष्ठों की सुरक्षा करें जो पहले से खोज ट्रैफ़िक लाते हैं

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

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

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

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

4. हटाए गए, नाम बदले गए, और समेकित सामग्री के लिए रीडायरेक्ट नियम सेट करें

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

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

सटीक गंतव्य का उपयोग करें जो अर्थ को बनाए रखता है। यदि एक ही विषय पर दो पुराने लेखों को मिलाया जाता है, तो दोनों को अंतिम एकीकृत पृष्ठ पर पुनर्निर्देशित करें। यदि एक उत्पाद श्रेणी को समाप्त किया जाता है, तो उपयोगकर्ताओं को उसी उद्देश्य के साथ निकटतम जीवित श्रेणी पर भेजें, न कि किसी यादृच्छिक होमपेज बैनर पर। यह छोटी अनुशासन बहुत सारी सफाई बचाती है।

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

5. नई संस्करण पर इंडेक्सबिलिटी सिग्नल्स को बनाए रखें

लॉन्च से पहले रोबोट निर्देश, कैनोनिकल, पृष्ठांकन, hreflang, और साइटमैप प्रविष्टियों की जांच करें। ये संकेत खोज इंजनों को बताते हैं कि क्या क्रॉल करना है और किस संस्करण को प्राथमिकता देनी है। यदि वे संघर्ष करते हैं, तो क्रॉलर गलत संकेत पर भरोसा कर सकता है और उस पृष्ठ को अनदेखा कर सकता है जिसे आप अनुक्रमित करना चाहते थे।

कैनोनिकल को विशेष देखभाल की आवश्यकता होती है। एक पृष्ठ जो गलत URL पर कैनोनिकल करता है, वह खोज परिणामों से गायब हो सकता है, भले ही यह ब्राउज़र में ठीक दिखता हो। रोबोट निर्देश भी उतने ही हानिकारक हो सकते हैं। एक टेम्पलेट पृष्ठ पर एक आकस्मिक noindex एक साथ कई URL को ब्लॉक कर सकता है। यह एक बुरा आश्चर्य है।

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

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

6. SEO रिग्रेशन के लिए स्टेजिंग वातावरण पर लॉन्च का परीक्षण करें

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

जहां संभव हो, पृष्ठ दर पृष्ठ तुलना करें। शीर्षक, विवरण, H1s, कैनोनिकल्स, और स्थिति कोड की जांच करें। यदि पुराने पृष्ठ में एक साफ 200 था और स्टेजिंग संस्करण एक स्टेजिंग-केवल URL पर 302 लौटाता है, तो वह तैयार नहीं है। यदि एक टेम्पलेट डुप्लिकेट फैसेटेड पृष्ठ बनाता है, तो इसे लॉन्च से पहले ठीक करें। लॉन्च के बाद, इसे ठीक करने में अधिक समय लगता है।

स्टेजिंग वह सही जगह भी है जहां सामग्री वितरण प्रणालियों का परीक्षण किया जा सकता है जो पोस्ट-लॉन्च नोटिस या उपयोगकर्ता अलर्ट भेजते हैं। यदि आपकी टीम भी चलाती है

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

7. पहले पोस्ट-लॉन्च क्रॉल और ट्रैफिक पैटर्न की निगरानी करें

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

पहले 24 घंटों की सावधानी से जांच करें। फिर 48 घंटे बाद फिर से जांचें। एक टेम्पलेट पर छापों में अचानक गिरावट आमतौर पर यह दर्शाती है कि समस्या संरचनात्मक है, मौसमी नहीं। 404s में वृद्धि आमतौर पर एक मैपिंग त्रुटि या एक छूटी हुई पुनर्निर्देशन का संकेत देती है। एक अजीब क्रॉल पैटर्न अवरुद्ध संपत्तियों या एक खराब कैनोनिकल टैग की ओर इशारा कर सकता है।

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

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

8. लॉन्च सप्ताह के लिए एक त्वरित-फिक्स वर्कफ़्लो तैयार रखें

लॉन्च दिन से पहले मालिकों को सौंपें। सामग्री को एक मालिक की आवश्यकता होती है, विकास को एक मालिक की आवश्यकता होती है, और SEO को एक मालिक की आवश्यकता होती है। यदि सुबह 10 बजे कोई समस्या उत्पन्न होती है, तो किसी को यह नहीं सोचना चाहिए कि इसे ठीक करने की अनुमति किसे है।

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

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

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

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