साइट माइग्रेशन जो आपके SEO को नुकसान न पहुँचाए

मैंने पाँच अंकों की माइग्रेशन को छह अंकों की SEO आपदा में बदलते देखा है क्योंकि टीम माइग्रेशन को तकनीकी समस्या की जगह निरंतरता समस्या के रूप में मानती थी। पैटर्न हमेशा एक जैसा होता है। नई साइट बनाइए। स्विच दबाइए। अगले आठ हफ्तों में ऑर्गेनिक ट्रैफिक चालीस से सत्तर प्रतिशत तक गिरते देखिए। अगली तिमाही को कटओवर दिन पर खोई हुई चीज को वापस पाने की कोशिश में लगा दीजिए।

तकनीकी स्थानांतरण ही वह नहीं है जो आपको मारता है। अस्सी प्रतिशत पूर्ण रीडायरेक्ट मैप्स आपको मारते हैं। कैनोनिकल टैग जो स्टेजिंग डोमेन की ओर इशारा करते हैं आपको मारते हैं। आंतरिक लिंक जो अभी भी पुरानी संरचना की ओर इशारा करते हैं आपको मारते हैं। URL परिवर्तन जो "जब हम यहाँ हैं" करते हैं आपको मारते हैं। बिल्ड खुद ही आसान हिस्सा है; निरंतरता का काम वह जगह है जहाँ मैंने बड़े पैमाने पर जो भी माइग्रेशन भेजी है वह जीती या मरी है।

पाँच चीजें, जो मैंने Seahawk Media पर 5,000 साइटों में मुश्किल तरीके से सीखी हैं। हर माइग्रेशन पर जो मैं भेजता हूँ वह गैर-परक्रामणीय है।

पहले, रीडायरेक्ट मैप को किसी भी कोड से पहले बनाया जाता है। हर पुरानी URL को 301 के साथ अपने नए संस्करण पर भेजा जाता है। हम Search Console, Ahrefs और मौजूदा sitemap से स्रोत URL सूची निर्यात करते हैं, फिर एक स्प्रेडशीट में mapping बनाते हैं जो cutover के लिए truth का स्रोत बन जाती है। Build linter deploy को विफल कर देता है अगर कोई भी pre-migration URL map से गायब है।

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

तीसरा, दस हजार से अधिक pages वाली sites को phased rollout मिलता है। सबसे कम traffic वाली content को पहले migrate करो, validate करो कि rankings बने रहते हैं, फिर expand करो। एक staged migration blast radius को limit करता है अगर किसी particular template या content type पर कुछ गलत हो जाए, और team को high-traffic pages affected होने से पहले issue को ठीक करने का मौका देता है।

चौथा, एक parallel-run period। पुरानी site launch के बाद तीस दिनों के लिए read-only mode में live रहती है। अगर नई site में कोई issue है, तो traffic तुरंत वापस reroute हो जाता है। एक महीने के लिए दो stacks चलाने की cost एक चार-सप्ताह की traffic recovery cycle की cost के मुकाबले छोटी है।

Migration के कुछ ही shapes हमारे लगभग सभी project work के लिए account करते हैं। हर एक का अपना playbook और अपने usual failure modes हैं।

WordPress से Next.js या Astro सबसे आम engagement है। Brief आमतौर पर एक marketing या content site के बारे में होता है जो classic WordPress पर performance ceiling से टकरा चुकी है और एक team जो modern front-end DX चाहती है editorial team के लिए wp-admin खोए बिना। Headless WordPress with WPGraphQL plus एक Next.js या Astro front-end दोनों sides को satisfy करता है।

Drupal, Sitecore या Typo3 से WordPress दूसरा पैटर्न है। लीगेसी एंटरप्राइज CMS से माइग्रेट करना बिना उन रैंकिंग को तोड़े जो लीगेसी टीम एक दशक में बना चुकी है। धीमे माइग्रेशन, अधिक जटिल कंटेंट मॉडलिंग, लेकिन प्लेबुक वही है, पूर्ण रीडायरेक्ट मैप, जहाँ संभव हो संरक्षित URL, समानांतर-रन, चरणबद्ध रोलआउट।

Shopify से headless commerce तीसरा है। Shopify Plus storefront एक Next.js या Hydrogen front-end के साथ, full custom design, faster Core Web Vitals, commerce engine को रखा गया। Shopify catalogue, inventory, और checkout के लिए source of truth बना रहता है; front-end custom चला जाता है।

जो दूसरे पैटर्न हम नियमित रूप से देखते हैं वे हैं डोमेन कंसोलिडेशन (कई लीगेसी डोमेन एक में मर्ज होना सही canonical और redirect स्ट्रेटेजी के साथ), subdomain से subdirectory में कंसोलिडेशन (blog.example.com को example.com/blog/ में ले जाना link equity को consolidate करने के लिए), और होस्टिंग और प्लेटफॉर्म माइग्रेशन (managed WordPress को Kinsta, WP Engine, Pressable के बीच मूव करना, या bare-metal infrastructure को)।

एक हजार से कम पेज वाली साइट्स चार से आठ हफ्ते पूरे से पूरे तक चलती हैं जिसमें प्लानिंग, redirect मैपिंग, कंटेंट माइग्रेशन, QA, और post-launch मॉनिटरिंग शामिल है। दस हजार से बीस हजार पेज वाली साइट्स बारह से बीस हफ्ते चलती हैं। पचास हजार पेज या उससे ज्यादा के enterprise माइग्रेशन कम से कम छह से नौ महीने चलते हैं, जिसमें phased rollouts और parallel-run periods टाइमलाइन में बने होते हैं।

सबसे बड़ा variable स्रोत पर कंटेंट की गुणवत्ता है। अव्यवस्थित taxonomies, duplicate URLs, और inconsistent metadata प्लानिंग फेज में हफ्ते जोड़ते हैं। हम आपको audit के दौरान ईमानदारी से बताएंगे कि आपकी स्रोत साइट migration-ready है या क्या उसे पहले कंटेंट cleanup pass की जरूरत है। यह दिखाना कि स्रोत साफ है जब वह नहीं है, यह वह तरीका है जिससे माइग्रेशन एक क्वार्टर से आधे साल में फिसल जाता है।

हाल के अनुबंधों से आधारभूत मूल्य निर्धारण, जानबूझकर सरल रखा गया है। पाँच सौ पृष्ठों से कम के छोटे व्यावसायिक माइग्रेशन $3k से शुरू होते हैं। मध्य-बाजार कार्य, एक से दस हजार पृष्ठों तक, $7k से शुरू होता है। दस से एक लाख पृष्ठों तक एंटरप्राइज माइग्रेशन $29k से शुरू होता है, और इसमें पहली तिमाही में लॉन्च के बाद SEO समर्थन शामिल है।

लागत का तीस से चालीस प्रतिशत प्लानिंग और QA में जाता है, तकनीकी build में नहीं। जो टीमें आपको सस्ता quote करती हैं वे वही हैं जो प्लानिंग को skip करती हैं। आप इसके लिए बाद में खोए हुए rankings में भुगतान करते हैं, और rankings को फिर से बनाने की लागत हमेशा उन्हें संरक्षित करने की लागत से ज्यादा होती है।