अपनी search rankings गिराए बिना domain migrate कैसे करें

Domains बदलना उन गिने-चुने SEO projects में से है जहाँ तकनीकी रूप से छोटी गलती बहुत जल्दी बहुत दिखाई देने लगती है। कोई missing redirect, blocked crawl path, या भूला हुआ canonical एक सीधे rebrand को कई हफ्तों की ranking volatility में बदल सकता है.

कुछ movement सामान्य है। Search engines को पुराने URLs crawl करने, redirects discover करने, signals process करने, और नए domain को index में settle करने के लिए समय चाहिए। लक्ष्य हर dip से बचना नहीं है। लक्ष्य migration को boring बनाना है: एक old URL एक equivalent new URL की ओर point करे, server साफ़ response दे, और कुछ भी महत्वपूर्ण गायब न हो.

Inventory से शुरू करें, redirect rule से नहीं

सबसे आम migration failure इसे server configuration task मान लेना है। यह वह नहीं है। यह एक information architecture task है, जो अंत में server configuration तक पहुँचता है.

DNS छूने से पहले, उन URLs की list बनाएं जो मायने रखते हैं:

• वे URLs जिन्हें organic traffic मिलता है
• वे URLs जिनके external backlinks हैं
• वे URLs जो convert करते हैं, leads generate करते हैं, या campaigns support करते हैं
• आपके XML sitemap में मौजूद canonical URLs
• PDFs, images, और downloadable files जिन्हें externally link किया गया है
• High-value legacy URLs जो current navigation में दिखाई नहीं दे सकते

हर old URL के लिए, new domain पर एक destination assign करें। अधिकतर मामलों में, वह destination वही intent वाला वही page होना चाहिए। अगर /pricing अब https://newdomain.com/pricing बनता है, तो यह सरल है। अगर तीन old product pages को एक new guide में merge किया जा रहा है, तो उस decision को जानबूझकर document करें.

Lazy pattern से बचें: सब कुछ new homepage पर redirect करना। यह सुविधाजनक है, लेकिन relevance खो देता है। Search engines और users दोनों expect करते हैं कि destination original URL जैसी ही need का जवाब दे.

जहाँ संभव हो URL structure बचाए रखें

Domain migration आसान होता है जब paths stable रहते हैं। oldsite.com/blog/example से newsite.com/blog/example पर जाना, domain, CMS, slugs, folder structure, और content को एक साथ बदलने की तुलना में कहीं साफ़ है.

कभी-कभी redesign या CMS migration URL changes को unavoidable बना देता है। अगर ऐसा हो, तो decisions को अलग करें:

1. Domain बदलने की वजह से क्या बदल रहा है?
2. Site structure बदलने की वजह से क्या बदल रहा है?
3. क्या delete, merge, या rewrite किया जा रहा है?

जितने अधिक variables आप introduce करते हैं, बाद में problems diagnose करना उतना कठिन हो जाता है। अगर migration महत्वपूर्ण है और current site अच्छा perform कर रही है, तो पहले domain move करने और redesign बाद में करने पर विचार करें.

Permanent, one-hop redirects इस्तेमाल करें

True domain migration के लिए, old URLs से उनके new equivalents तक server-side 301 या 308 redirects इस्तेमाल करें। Temporary redirects temporary situations के लिए हैं। JavaScript redirects, meta refreshes, और soft redirects कमजोर signals हैं और आसानी से टूट सकते हैं.

आपके redirect goals सरल हैं:

• हर important old URL permanent redirect return करता है.
• हर redirect सीधे final destination पर जाता है.
• HTTP साफ़ तरीके से HTTPS पर redirect करता है.
• www और non-www variants consistent तरीके से handle होते हैं.
• Redirects fragile query-string behavior पर निर्भर नहीं करते, जब तक जरूरी न हो.

एक खराब chain ऐसी दिखती है:

http://oldsite.com/page → https://oldsite.com/page → https://www.oldsite.com/page → https://newsite.com/page → https://www.newsite.com/page

यह अंततः सही page पर पहुँच सकती है, लेकिन यह slow है, crawl करना कठिन है, और mistakes छुपाने की अधिक संभावना रखती है। हर old variant से final new URL तक one hop का लक्ष्य रखें.

Behavior validate करते समय, browser जो दिखाता है उस पर भरोसा करने के बजाय actual HTTP responses inspect करें। debugging redirects and HTTP headers in production पर हमारा guide यहाँ उपयोगी है, क्योंकि browsers बहुत polite होते हैं: वे chain follow कर लेते हैं और messy parts छुपा देते हैं.

Launch से पहले DNS और certificates तैयार करें

DNS सीधे rankings transfer नहीं करता, लेकिन खराब DNS migration को broken दिखा सकता है। Launch window से पहले TTL values कम करें ताकि changes अधिक predictably propagate हों। Confirm करें कि new domain में web traffic, email, और किसी भी required subdomains के लिए सही records हैं.

आपको दोनों domains के लिए valid TLS certificates भी चाहिए। इसे overlook करना आसान है। Migration के बाद भी old domain को HTTPS redirects serve करने होंगे। अगर उसका certificate expire हो जाता है, तो users और crawlers new site तक पहुँचने से पहले ही browser warnings देख सकते हैं.

अगर move email को affect करता है, तो उसे afterthought न मानें। Domain changes अक्सर SPF, DKIM, DMARC, MX records, tracking links, और transactional mail तोड़ देते हैं। महत्वपूर्ण records पर refresher के लिए, MX, SPF, DKIM, and DMARC पर हमारा developer-friendly guide देखें.

Canonicals, internal links, और sitemaps check करें

Launch के बाद, new domain को ऐसा behave करना चाहिए जैसे वह content का canonical home हमेशा से रहा हो.

इसका मतलब है:

• Canonical tags new URLs की ओर point करें, old domain की ओर नहीं.
• Internal links new domain या root-relative paths इस्तेमाल करें.
• XML sitemaps में केवल final, indexable new URLs हों.
• hreflang annotations, अगर इस्तेमाल हों, new URLs reference करें.
• Open Graph, structured data, और alternate links update हों.
• Robots.txt important sections block न करे.

Old URLs से भरा sitemap publish करके redirects से उसे साफ़ करने की उम्मीद न करें। Sitemap उन URLs की list होना चाहिए जिन्हें आप index करवाना चाहते हैं। Migration के बाद, इसका मतलब है new domain पर final URLs.

Canonical contradictions पर भी नजर रखें। ऐसा page जो old से new पर redirect करता है लेकिन canonical old domain की ओर point करता है, mixed signals भेजता है। Search engines आमतौर पर कुछ inconsistency से निपट सकते हैं, लेकिन आपको उनसे ऐसा करने को नहीं कहना चाहिए.

Launch day पर सब कुछ न बदलें

Migration पहले से ही काफी बड़ा event है। अगर संभव हो, तो इसे major content pruning, template rewrites, navigation changes, JavaScript rendering changes, या new performance profile के साथ combine करने से बचें.

यह superstition नहीं है। यह debugging discipline है। अगर launch के बाद rankings गिरती हैं, तो आपको पता होना चाहिए कि वजह redirect mapping, crawl access, changed content, slower rendering, missing structured data, या कुछ और है.

Initial launch को practical रूप से old site के जितना करीब हो सके रखें। जब new domain stable हो जाए, तब बड़े editorial और design changes छोटे batches में करें.

Search engines को बताएं कि क्या बदला

Google Search Console में old और new दोनों domains verify करें। फिर जब move domain-level change हो और content नए domain पर जा रहा हो, तो Change of Address tool इस्तेमाल करें। Launch के बाद new sitemap submit करें.

यह redirects का replacement नहीं है। यह उन्हें support करता है। Search engines को URL-level mapping समझने के लिए अब भी crawlable, persistent redirects चाहिए.

Bing और अन्य search engines के लिए, जहाँ उपलब्ध हों वहाँ उनके webmaster tools इस्तेमाल करें। साथ ही उन places को update करें जिन्हें आप control करते हैं: social profiles, business listings, ad destinations, email footers, documentation, partner links, और syndicated content में canonical references.

External links सभी update नहीं होंगे, और यह ठीक है। लेकिन सबसे महत्वपूर्ण links update होने चाहिए। अगर कोई major partner, app marketplace, documentation portal, या press page old domain को link करता है, तो update के लिए कहें.

Launch के बाद सही चीज़ें monitor करें

Migration के बाद पहले कुछ दिन active monitoring के होने चाहिए, celebration के नहीं.

Check करें:

• Old और new domains पर crawl activity के लिए server logs
• 404s और unexpected 5xx errors
• Redirect chains और loops
• Search Console में indexing status
• Sitemap discovery और processing
• Organic landing pages और query patterns
• Conversion paths जो old URLs पर निर्भर हैं
• Analytics filters और referral exclusions

Reporting noise की उम्मीद रखें। कुछ analytics tools new domain को new property मानते हैं, जब तक उन्हें ठीक से configure न किया जाए। कुछ dashboards old-domain traffic की तुलना new-domain traffic से करते हैं और migration को वास्तविकता से खराब दिखाते हैं.

Search visibility कुछ हफ्तों तक fluctuate कर सकती है। जो आप नहीं चाहते वह ऐसा pattern है जहाँ high-value old URLs बार-बार crawl हो रहे हों लेकिन properly redirect न हो रहे हों, या जहाँ new pages discover हो रहे हों लेकिन old domain के duplicates के रूप में marked हों.

Performance को भी ignore नहीं करना चाहिए। अगर new domain heavier templates, broken caching, या unoptimized assets के साथ launch होता है, तो users migration को slowdown के रूप में महसूस कर सकते हैं। अगर आप अपनी checks के हिस्से के रूप में Lighthouse इस्तेमाल कर रहे हैं, तो उसे priorities ध्यान में रखकर पढ़ें; how to read a Lighthouse report without panicking पर हमारा piece बताता है कि meaningful issues को noise से कैसे अलग करें.

Old domain को लंबे समय तक रखें

Migration “works” करने के बाद old domain expire न होने दें। इसे registered रखें, certificates valid रखें, और redirects जितना संभव हो उतने लंबे समय तक चलाते रहें। व्यवहार में, इसका मतलब अक्सर years होता है.

Old links blog posts, bookmarks, documentation, PDFs, emails, और social posts में मौजूद रहते हैं। Redirects उस historical footprint और new domain के बीच bridge हैं। उन्हें बहुत जल्दी बंद करना users के paths तोड़ता है और accumulated signals waste करता है.

अपने redirect map और launch notes की copy भी रखें। छह महीने बाद, जब कोई पूछेगा कि कोई legacy URL एक खास तरीके से behave क्यों करता है, तो आपको खुशी होगी कि आपने इसे document किया था.

<!-- tool-cta:start -->

💡 इसे आज़माएँ: कटओवर के बाद, अपने पुराने URL को Redirect Checker के माध्यम से ट्रेस करें ताकि पुष्टि हो सके कि हर एक सही नए पेज पर एक ही 301 हॉप में रिज़ॉल्व होता है।

<!-- tool-cta:end -->

एक sensible migration checklist

Launch से पहले:

• Search Console में दोनों domains verify करें.
• Current site crawl करें और important URLs export करें.
• One-to-one redirect map बनाएं.
• DNS TTLs कम करें.
• Old और new domains के लिए TLS certificates तैयार करें.
• Canonicals, internal links, hreflang, structured data, और sitemaps update करें.
• Staging या controlled environment में redirects test करें.

Launch day पर:

• Redirects deploy करें.
• HTTP से HTTPS behavior confirm करें.
• हर template type से important URL samples test करें.
• New sitemap submit करें.
• जहाँ appropriate हो Change of Address tool इस्तेमाल करें.
• Server errors, redirect loops, और blocked resources पर नजर रखें.

Launch के बाद:

• Crawl errors और indexing reports monitor करें.
• जहाँ संभव हो important external links update करें.
• Traffic को सिर्फ domain totals से नहीं, landing page intent के हिसाब से compare करें.
• Redirects indefinitely live रखें.
• Move stabilize होने तक unrelated redesign या content experiments delay करें.

Domain migrations risk-free नहीं हैं, लेकिन manageable हैं। Rankings आमतौर पर तब suffer करती हैं जब migration unclear signals भेजता है: missing redirects, changed content, contradictory canonicals, blocked crawlers, या भूला हुआ old domain। Search engines और users को clean map दें, और move बहुत कम dramatic हो जाता है.