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

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

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

पाँच चीजें, Seahawk Media पर बारह हजार साइटों पर सीखी गई कठिन तरीके से। प्रत्येक हर माइग्रेशन पर जो हम भेजते हैं गैर-परक्राम्य है।

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

दूसरा, URL structure को हर जगह सुरक्षित रखा जाता है जहाँ नया platform इसकी अनुमति देता है। हर URL change एक ranking risk है। हम URLs को केवल तभी बदलते हैं जब कोई वास्तविक content कारण हो — कोई duplicate, कोई typo, कोई canonical जिसे हम consolidate कर रहे हैं — कभी नहीं क्योंकि नया platform एक अलग convention सुझाता है। "चलते-चलते सब कुछ साफ-सुथरा करने" का लालच हमारे migration अभ्यास में किसी अन्य decision से अधिक rankings खर्च कर चुका है।

तीसरा, दस हजार से अधिक 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 के मुकाबले छोटी है।

पाँचवाँ, launch के बाद नब्बे दिन की निगरानी। Search Console crawl stats, indexation coverage, impressions, log file analysis, schema validator, Core Web Vitals field data। Regressions को quarters में नहीं, दिनों में ठीक करो। Day ninety तक site स्थिर है और हम या तो साफ-सुथरे तरीके से hand off करते हैं या एक ongoing care plan में चले जाते हैं।

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 दूसरा pattern है। Legacy enterprise CMS से बाहर निकलना बिना उन SEO rankings को तोड़े जिन्हें legacy team ने एक दशक में बनाया है। धीमे migrations, अधिक complex content modelling, लेकिन playbook वही है — full redirect map, preserved URLs जहाँ संभव हो, parallel-run, phased rollout।

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 की जरूरत है। यह दिखाना कि स्रोत साफ है जब वह नहीं है — यह वह तरीका है जिससे माइग्रेशन एक क्वार्टर से आधे साल में फिसल जाता है।

हाल के असली engagements से ईमानदार रेंज। पांच सौ पेज से कम का स्मॉल बिजनेस माइग्रेशन चार हजार से बारह हजार पाउंड चलता है। एक से दस हजार पेज का mid-market माइग्रेशन पंद्रह हजार से साठ हजार तक चलता है। दस से एक लाख पेज का enterprise माइग्रेशन साठ हजार से तीन लाख पाउंड चलता है, जिसमें पहली क्वार्टर के लिए ongoing post-launch SEO सपोर्ट शामिल है।

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