साइट माइग्रेशन चेकलिस्ट: T-4 सप्ताह से लेकर दिन 45 तक
डोमेन बदलना, रीप्लेटफॉर्म करना, होस्ट बदलना या एक नया URL स्कीमा: आपके पास आने वाले लिंक्स को इससे कोई फर्क नहीं पड़ता। यह सूची आपको बताती है कि लॉन्च से पहले क्या कैप्चर करना है और उसके बाद क्या पुनः जांचना है।
ArchiLinks research team ·
हमारी स्थिति
अधिकांश माइग्रेशन नुकसान रिडायरेक्ट्स की कमी से होता है, न कि रिडायरेक्ट टाइप से
टीमें घंटों तक 301 बनाम 302 पर बहस करती हैं और फिर 3,000 एक्सटर्नल-लिंक URLs को 404 लौका देती हैं। किसी भी अन्य निर्णय से पहले किसी वेबसाइट के सभी बैकलिंक्स खोजें, क्योंकि सूची आपको बताती है कि जोखिम कहाँ है।
- लिंक्ड पेजों को 4 सप्ताह पहले खींचें, न कि रात भर पहले।
- हर उस URL के लिए जिसमें एक एक्सटर्नल लिंक है, एक प्रासंगिक पेज पर एक-हॉप 301 रखें।
- रिडायरेक्ट्स को कम से कम एक वर्ष के लिए लाइव रखें, क्योंकि पुराने लिंक्स अक्सर उन पेजों से भी ज़्यादा समय तक चलते हैं जिनकी ओर वे एक बार इशारा करते थे।
समयरेखा
T-4 सप्ताह: इन्वेंटरी
पुरानी साइट को क्रॉल करें, Search Console परफॉर्मेंस रिपोर्ट एक्सपोर्ट करें और पुराने होस्ट के लिए toppages और refdomains चलाएं। तीनों फ़ाइलों को तिथि के साथ एक साथ स्टोर करें।
T-3 सप्ताह: मैप
लिंक्ड पेजों से पहले, ट्रैफ़िक से दूसरा, और क्रॉल से आखिरी रिडायरेक्ट मैप बनाएं। रिडायरेक्ट मैप रेसिपी रैंकिंग स्क्रिप्ट दिखाती है।
T-2 सप्ताह: स्टैजिंग पर परीक्षण
पुराने हर URL को स्टैजिंग के खिलाफ चलाएं और सुनिश्चित करें कि एक हॉप हो, स्टेटस 301 हो और अंत में 200 हो। चेन या लूप पर बिल्ड फेल करें।
T-0: लॉन्च
रिडायरेक्ट्स, नई साइटमैप, अपडेटेड कैनोनिकल टैग और इंटरनल लिंक्स को एक ही रिलीज़ में भेजें। Search Console में नई साइटमैप सबमिट करें। डोमेन बदलने के मामले में, Change of Address टूल का उपयोग करें।
T+1 सप्ताह: लॉग और कवरेज
पुराने URLs पर Googlebot हिट्स के लिए सर्वर लॉग्स जांचें, फिर 404 या सॉफ्ट 404 में वृद्धि के लिए Pages रिपोर्ट जांचें। मैप ठीक करें; प्रतीक्षा न करें।
T+30 से 45 दिन: लिंक डिफ
मासिक रिफ्रेश के बाद, नए होस्ट के लिए refdomains खींचें और इसे पुरानी फ़ाइल से तुलना करें। कुछ प्रतिशत से बड़े अंतरों की जांच की आवश्यकता है।
मूव के प्रकार के साथ क्या बदलता है
| मूव | रिडायरेक्ट्स | अतिरिक्त जांच | लिंक-डेटा फोकस |
|---|---|---|---|
| नया डोमेन | होस्ट-वाइड 301, जहां पथ बदलते हैं वहां पथ-लेवल | Change of Address टूल, पुराना डोमेन कम से कम 12 महीने तक रखा गया | समय के साथ नए होस्ट पर रेफरिंग डोमेन का स्थानांतरण |
| HTTP से HTTPS या www बदलाव | होस्ट-लेवल 301 | कैनोनिकल, HSTS, मिक्स्ड कंटेंट | कुछ अंतर नहीं; पुष्टि करें कि दोनों होस्ट एक ही जगह रिज़ॉल्व करते हैं |
| रीप्लेटफॉर्म, समान डोमेन | पथ-लेवल मैप | पेजिनेशन, पैरामीटर्स, ट्रेलिंग स्लैश | टॉप लिंक्ड पेज जिनका पथ बदला है |
| सबडोमेन से सबफोल्डर (या वापस) | पथ-लेवल मैप, होस्ट-लेवल नियम | कुकीज़, होस्ट के लिए robots.txt, एनालिटिक्स | कि लिंक्स पुराने होस्ट की ओर इशारा करते हैं या नए होस्ट की ओर |
| दो साइट्स का विलय | बहु-से-एक मैप | डुप्लिकेट कंटेंट, कैनोनिकल चयन | intersect के माध्यम से लिंकिंग डोमेन की ओवरलैप |
लॉन्च-डे टिक लिस्ट
- पुराने URLs एकल हॉप में 301 लौटाते हैं, जिसकी जांच हाथ से नहीं बल्कि एक स्क्रिप्ट द्वारा की जाती है।
- नया होस्ट हर टेम्पलेट पर 200 लौटाता है जिसमें एक सेल्फ-रेफरेंसिंग कैनोनिकल हो।
- नए होस्ट पर robots.txt में स्टैजिंग नियम नहीं होने चाहिए। एक बचा हुआ Disallow: / लॉन्च-डे की क्लासिक गलती है।
- XML साइटमैप में केवल 200, इंडेक्स करने योग्य, कैनोनिकल URLs सूचीबद्ध हैं।
- इंटरनल लिंक्स, नेविगेशन और स्ट्रक्चर्ड डेटा नए URLs की ओर इशारा करते हैं, रिडायरेक्टेड URLs की ओर नहीं।
- एनालिटिक्स और Search Console प्रॉपर्टीज स्विच से पहले नए होस्ट के लिए मौजूद होनी चाहिए।
- बेलाइन JSON फ़ाइलें कमिटेड हैं, प्रत्येक फ़ाइल के नाम में तिथि के साथ।
हमारा लिंक ग्राफ़ लगभग एक बार में एक बार पुनर्निर्मित होता है। आपके लॉन्च की सप्ताह में बनाया गया एक लिंक दिन-30 पुल पर दिखाई नहीं दे सकता। आखिरी मील के लिए Search Console के Links रिपोर्ट का उपयोग करें, और दूसरे रिफ्रेश से डिफ का आकलन करें। वही डेटा लॉन्च के बाद इंटरनल बनाम एक्सटर्नल इक्विटी समीक्षा को फीड करता है, और hreflang रिजियोनल डोमेन मल्टी-काउंटी केस को कवर करता है।
एक 301 जो 404 पर समाप्त होता है कुछ भी नहीं रखता
कुछ टीमें हर पुराने URL को नए घर पर भेज देती हैं और मंजिल के पेजों को बाद में एक्सपायर होने देती हैं। रिडायरेक्ट खुद काम करता है। यही कारण है कि यह आदत जोखिम भरी है, क्योंकि हर हॉप लॉग में साफ दिखता है जबकि अंत में पेज 404 के साथ जवाब देता है।
मान लीजिए कि आप एक दुकान को एक नए डोमेन पर ले जाते हैं और केवल उन उत्पादों को रखते हैं जो अभी भी बिक रहे हैं। श्रेणी पेज जिनमें बाहरी लिंक्स का अधिकांश हिस्सा था, अब कुछ भी उपयोगी नहीं पर जा रहे हैं। कुछ भी सेवानिवृत्त करने से पहले एक्सटर्नली लिंक्ड URLs की गिनती करें। इसे पहला कदम बनाएं। एक पेज जिसमें लिंकिंग डोमेन हैं, उसी विषय पर एक लाइव टारगेट की आवश्यकता है, न कि एक श्रद्धांजलि।
नियम छोटा रखें: एक हॉप, फिर एक अंतिम 200। कुछ और चुना हुआ लीक है।
एक लाइव पेज पर एक-हॉप 301 क्या संरक्षित करता है
लिंक का मूल्य उस URL पर बैठता है जिसकी ओर यह इशारा करता है। एक रिडायरेक्ट उस मूल्य को तभी ले जाता है जब वह जिस पते पर उतरता है वह जवाब देता है और विषय से अभी भी मेल खाता है। एक उत्पाद जो नए कैटलॉग में उसी उत्पाद पर जाता है, उस परीक्षण को पास कर देता है, जबकि एक उत्पाद जो होमपेज पर भेजा जाता है आमतौर पर नहीं, भले ही वह पेज हो जिस पर हर कोई लिंक करता था।
हर टेम्पलेट बदलाव के बाद अंतिम स्टेटस को पुनः जांचें। एक रिडायरेक्ट जो लॉन्च पर काम करता था, बाद में एक रिलीज़ के बाद 404 पर समाप्त हो सकता है, जब कोई मेनू टाई-अप के दौरान एक श्रेणी हटा देता है।
जब 410 ईमानदार जवाब है
कुछ पुराने URLs के न तो लिंक्स थे, न ही विज़िट और न ही कोई असली प्रतिस्थापन। उन लोगों के लिए, एक स्पष्ट 404 या 410 एक ऐसे पेज पर रिडायरेक्ट करने से अधिक ईमानदार है जो उस सवाल का जवाब नहीं देता जो पुराना पेज देता था। एक असंबंधित पेज पर रिडायरेक्ट अक्सर एक सॉफ्ट 404 के रूप में माना जाता है, इसलिए यह कुछ भी बचाता नहीं है।
हर URL समूह के लिए निर्णय लिखें, उसके बगल में कारण के साथ। सेवानिवृत्त ट्यूटोरियल्स की एक फोल्डर का जवाब उन पेजों की एक फोल्डर से अलग होगा जिनमें अस्सी लिंकिंग डोमेन हैं, और आप छह महीने बाद एक सहकर्मী को उस अंतर को समझाना चाहेंगे।
आखिरी हॉप की जांच, केवल पहले की नहीं
अधिकांश रिडायरेक्ट टेस्ट पहले प्रतिक्रिया पर रुक जाते हैं, जो रुकने की गलत जगह है। चेन को उसके अंत तक फॉलो करें, फिर हॉप की संख्या और अंतिम स्टेटस को पुराने URL के बगल में रिकॉर्ड करें। दो हॉप की चेन टूटी हुई नहीं है, लेकिन यह विलंबता जोड़ती है और एक और जगह जहां नियम फेल हो सकता है।
यदि एक स्क्रिप्ट दूर है, तो एक स्प्रेडशीट और कुछ curl कॉल्स काम कर सकते हैं। API स्क्रिप्ट्स पेज में एक संस्करण है जिसे आप शेड्यूल कर सकते हैं।
लॉन्च के बाद साइटमैप्स और मैनुअल रिक्वेस्ट
मूव के बाद कुछ सप्ताहों के लिए पुरानी साइटमैप को पहुंच योग्य रखें। क्रॉलर्स जो पुराने होस्ट पर वापस आते हैं, वे उन पतों को एक सूची में अभी भी खोज सकते हैं, जो रिडायरेक्ट्स के माध्यम से उनके पहले पार करने की गति बढ़ाता है।
मैनुअल रिक्वेस्ट एक अलग टूल हैं। उनका उपयोग उन कुछ पेजों के लिए करें जो सबसे ज़्यादा मायने रखते हैं, सैकड़ों URLs को एक-एक करके सबमिट करने के लिए नहीं। एक ऐसे पेज की रिक्वेस्ट जिसके कोई इंटरनल लिंक्स नहीं हैं और जिसका शरीर पतला है, वह अक्सर फिर से गिर जाता है, इसलिए रिक्वेस्ट उतनी ही अच्छी है जितना उसके पीछे वाला पेज है।
प्रतीक्षा करना एक वैध योजना है। क्रॉल को समय दें, फिर डेटा पर इसका आकलन करें।
पुरानी साइटमैप को कुछ समय के लिए सूचीबद्ध रखना
पुरानी साइटमैप को Search Console में तब तक छोड़ दें जब तक कि पुराने URLs क्रॉल सांख्यिकी में दिखाई देना बंद नहीं कर देते। फिर इसे जानबूझकर हटाएं और माइग्रेशन लॉग में तिथि नोट करें।
लॉन्च दिन पर इसे हटाएं नहीं ताकि प्रॉपर्टी साफ दिखे। जल्द हटाने उस एक सूची को छिपा देता है जो हर पुराने URL को नाम देता है जिसे आपको अभी भी ट्रैक करने की आवश्यकता है।
लिंक्स वाले पेजों के लिए इंडेक्सिंग की रिक्वेस्ट करना
सबसे ज़्यादा एक्सटर्नल लिंक्स वाले बीस नए URLs चुनें, उसी जॉइन का उपयोग करके जिसे आपने रिडायरेक्ट मैप के लिए बनाया था, और उन्हें मैनुअली रिक्वेस्ट करें। प्रयास फिर साइट के आकार के बजाय जोखिम का अनुसरण करता है।
यदि एक रिक्वेस्ट किया गया पेज कुछ सप्ताहों के बाद भी गायब है, तो फिर से पूछने से पहले पेज की जांच करें। इसके इंटरनल लिंक्स, कैनोनिकल और कंटेंट की जांच करें। एक पांचवीं रिक्वेस्ट कुछ नहीं बदलेगी।
मूव से पहले कितना समय आकलन किया जा सकता है
मूव को पहले लिंक पुल से नहीं, दूसरे लिंक पुल से आकलन करें। हमारा इंडेक्स रिफ्रेश लगभग एक बार में एक बार होता है, इसलिए दिन तीन पर एक पुल मुख्य रूप से पिछले महीने की तस्वीर दिखाता है। रिफ्रेश के बाद दूसरा पुल चलाएं, और नए होस्ट पर किसी वेबसाइट के सभी बैकलिंक्स खोजने के लिए उसका उपयोग करें।
Pages रिपोर्ट और लिंक डेटा अलग-अलग सवालों का जवाब देते हैं। उन्हें एक साथ पढ़ें, न कि उसी मूव पर प्रतिस्पर्धी निर्णयों के रूप में।
स्टैजिंग साइट लाइव जाने से पहले पांच जांच
स्टैजिंग को इंडेक्स से बाहर रखें
स्टैजिंग के सामने एक पासवर्ड या अलॉ-लिस्ट डालें। एक robots.txt नियम अकेले उन URLs को इंडेक्स करने से खोज इंजनों को रोक नहीं सकता जिनके बारे में वे लिंक्स से पहले से जानते हैं।
noindex और कैनोनिकल सेटिंग्स की जांच करें
टेम्पलेट और CMS सेटिंग्स खोलें, और एक noindex फ्लैग या एक कैनोनिकल खोजें जो एक अन्य URL को नाम देता है। WordPress में, सर्च विज़िबिलिटी सेटिंग वह है जिसे लोग स्टैजिंग से साइट कॉपी करने के बाद भूल जाते हैं।
स्टैजिंग robots फ़ाइल बदलें
स्विच पूरा होने पर लाइव robots.txt फेच करें, और उस फ़ाइल से तुलना करें जिसे आप भेजना चाहते थे। स्टैजिंग नियम जो प्रोडक्शन तक पहुंच सकते हैं, क्रॉलर्स को पूरे होस्ट से बाहर रख सकते हैं।
लाइव होस्ट पर हॉप टेस्ट चलाएं
स्टैजिंग मैप की कार्यक्षमता को एक कॉपी पर साबित करता है। DNS बदलाव के बाद असली डोमेन पर एक-हॉप टेस्ट फिर से चलाएं, क्योंकि एक CDN कैश या होस्ट नियम वहां अलग व्यवहार कर सकता है।
पुराने होस्ट को जवाब देते रखें
पुराने डोमेन को तब तक रिडायरेक्ट्स सर्व करते रखें जब तक कि उसके URLs अभी भी लिंक्स या विज़िट प्राप्त कर रहे हैं। किसी डोमेन के अस्तित्व को किसी ने भूल जाए, इससे पहले रिन्यूअल तिथि को कैलेंडर में डालें।
लॉन्च से पहले नहीं, लॉन्च के बाद साइट की निगरानी
एक प्री-लॉन्च ऑडिट उस दिन की सच्चाई को रिकॉर्ड करता है जिस पर यह चलाया गया था। अधिकांश लॉन्च नुक़सान बाद में दिखाई देता है, एक प्लगइन अपडेट के बाद, एक CDN नियम बदलाव के बाद या एक टेम्पलेट के बाद जिसने एक सेटिंग को छुआ हो जिसकी किसी ने समीक्षा नहीं की हो।
पोस्ट-लॉन्च वॉच को एक सेव्ड बेलाइन के खिलाफ छोटे डिफ की सेट के रूप में मानें। कोई डैशबोर्ड जरूरी नहीं। एक शेड्यूल और तिथि वाली फ़ाइलों का एक फोल्डर काम करेगा।
एक साप्ताहिक वॉच को क्या तुलना करनी चाहिए
उन जांचों को चुनें जो बदलने पर सबसे ज़्यादा नुकसान पहुंचाएंगी, और उन्हें हर सप्ताह एक ही दिन पर चलाएं।
- टॉप 50 लिंक्ड पुराने URLs के लिए स्टेटस कोड और अंतिम URL
- मुख्य टेम्पलेट्स पर robots.txt और robots मेटा टैग
- नई साइटमैप में गिनती के खिलाफ लाइव 200 URLs की गिनती
- होमपेज, एक श्रेणी और एक आर्टिकल पर कैनोनिकल टैग
एक एक-बार ऑडिट धीमी ड्रिफ्ट को कैसे छूट जाता है
लॉन्च के बाद सेटिंग्स ड्रिफ्ट होती हैं। एक टेस्ट फ्लैग छोड़ा गया, एक प्लगइन जो परमालिंक्स को रीराइट करता है, या एक पेज को ठीक करने के लिए जोड़ा गया रिडायरेक्ट योजना के एक हिस्से को रद्द कर सकता है। लॉन्च दिन पर लिया गया एक ऑडिट उनमें से किसी को भी नहीं देख सकता।
एक शेड्यूल किया गया डिफ देख सकता है। बेलाइन फ़ाइलों को वर्जन कंट्रोल में रखें और हर सप्ताक के आउटपुट की तुलना उनसे करें, ताकि एक अप्रत्याशित बदलाव उसी दिन दिखाई दे जब वह होता है।
सबडोमेन, हटाव और व्हाइट-साइट डोमेन बदलाव
कुछ टीमें एक सेक्शन को एक सबडोमेन पर ले जाती हैं और केवल उसके लोकप्रिय पेजों को इंडेक्स करती हैं। वह काम कर सकता है। लागत यह है कि शांत पेजों के लिए निर्देशित लिंक्स अब कम इतिहास वाले होस्ट पर जाते हैं, इसलिए कुछ भी काटने से पहले उन्हें गिनें।
रिमूवल रिक्वेस्ट जितने सुनाई देते हैं उतने संकीर्ण नहीं हैं। Search Console उस प्रॉपर्टी पर एक रिमूवल लागू करता है जहां आप फाइल करते हैं, इसलिए एक सबडोमेन पर की गई रिक्वेस्ट मुख्य डोमेन पर कार्य नहीं करती। प्रॉपर्टी को पहले जांचें। फिर सबमिट करें, और दोनों को सत्यापित रखें।
सबडोमेन पर केवल लोकप्रिय पेजों को इंडेक्स करना
उस सेक्शन में URL प्रति लिंक्स से शुरू करें। पेज जिनके बाहरी लिंक्स हैं लेकिन कम ट्रैफ़िक है, वे पहले ऐसे पेज होंगे जो केवल-लोकप्रिय-पेज नियम छिपा देगा। उन्हें क्रॉल करने योग्य रखें, या प्रत्येक को उसके निकटतम लोकप्रिय पेज पर रिडायरेक्ट करें और नियम के बगल में कारण लिखें।
मुख्य साइट सबडोमेन से कहाँ लिंक करती है यह तय करता है कि उसके पेज कितनी आसानी से पाए जाते हैं। उन पेजों को चुनें जो छिपे रहेंगे, उन लिंक्स की सूची बनाएं, क्योंकि एक पेज जिसे मुख्य साइट कभी लिंक नहीं करती, उस तक पहुंचना किसी भी स्थिति में मुश्किल है।
पेज-बाय-पेज एक व्हाइट-साइट डोमेन बदलाव
एक होस्ट-लेवल नियम रूट को संभालता है, लेकिन एक डोमेन बदलाव में एक पथ-लेवल मैप भी चाहिए। जब URL का पहला हिस्सा बदलता है और स्लैश समान रहता है, तो एक होस्ट स्विप अधिकांश पेजों को कवर करता है, और अपवादों को अपनी अपनी लाइनों की आवश्यकता होती है।
लिंक्ड पेजों से पहले सूची बनाएं, फिर प्रत्येक पुराने पथ को उसके नए पथ से मिलाएं। रिडायरेक्ट मैप रेसिपी दिखाती है कि उस सूची को लिंक्स द्वारा कैसे रैंक करें।
