Website Redesign में SEO: पुराने URLs का सही mapping plan कैसे बनाएं?

नई website का design तैयार है। अब सवाल आता है कि पुराने service pages और उन पर आने वाले links का क्या होगा। अगर यह बात launch के आखिरी दिन उठे तो महत्वपूर्ण URLs छूट सकते हैं। Redesign के साथ address बदलना एक अलग planning task है।

यह guide URL changes वाली website migration के लिए है। केवल colour और layout बदलने पर हर URL बदलना जरूरी नहीं। अपने project में पहले यह स्पष्ट करें कि वास्तव में कौन-से addresses बदल रहे हैं।

Google की migration documentation

Google Search Central की site-move guidance पुराने और नए URLs का mapping तैयार करने, relevant destinations और server-side permanent redirects का संदर्भ देती है। Internal links, canonical information और sitemap को नए URLs से मिलाने की बात भी है।

Guidance irrelevant पुराने pages को एक ही unrelated destination पर भेजने से बचने को कहती है। अपनी specific implementation developer से जाँचें। नीचे का review plan business owner और team के coordination के लिए है, हर server की configuration recipe नहीं।

Inventory में केवल navigation pages न रखें

पुरानी website के service, blog, location और important document pages की सूची लें। Analytics, CMS और existing sitemap से available records मिलाएं। जिस page का link menu में नहीं, वह जरूरी नहीं कि बेकार हो।

हर row के सामने owner और purpose लिखें। Content current है, merge होना है या वास्तव में हट चुका है—तीनों अलग decisions हैं। पहले business decision लें; उसके बाद technical handling तय करें।

एक row का अच्छा example

मान लें पुराना page “commercial AC maintenance” के बारे में था। नई website में उसी service का relevant page है तो reviewer दोनों का scope मिलाए। केवल homepage सुंदर है इसलिए हर service URL को वहीं भेज देना user के specific सवाल का जवाब नहीं होगा।

अगर दो पुराने pages एक नए detailed page में merged हैं तो mapping में उसका reason लिखें। यह hypothetical structure है; बिना अपनी content review के copy करने वाला redirect rule नहीं।

Team handover में clear statuses

Mapping sheet में pending review, approved और tested जैसी अपनी states रखें। Content team की approval और developer की implementation अलग columns में हो सकती है। “Done” लिखने से यह स्पष्ट नहीं होता कि किसने क्या verify किया।

Preview environment के links accidentally public mapping में न रह जाएं। New destination पर expected title, main content और user action की जाँच करें। Redirect काम कर रहा हो लेकिन enquiry button broken हो तो launch review अधूरी है।

Before और after की तुलना

Launch से पहले important pages की baseline list रखें। बाद में वही sample दोबारा check करें। Old URL सीधे सही final destination तक पहुंचता है? Relevant image या download भी खुलता है? केवल homepage status देखकर पूरी migration सही न मानें।

Unexpected errors को impact के अनुसार prioritise करें। जो page users को service तक पहुंचाता है, उसके issue की ownership साफ हो। Fix के बाद उसी path को फिर verify करें; केवल configuration edit हो जाना success का प्रमाण नहीं।

Ranking की उम्मीद realistic रखें

Migration के दौरान traffic और indexing को monitor करें, लेकिन किसी single day's fluctuation से पूरा कारण तय न करें। Content, tracking और URL changes साथ हुए हों तो interpretation में उनका context रखें। यह plan ranking बरकरार रहने की guarantee नहीं देता।

Frequently Asked Questions

क्या redesign में URL बदलना जरूरी है?

नहीं। पहले project की actual जरूरत और existing structure देखें।

क्या सारे पुराने URLs homepage पर भेज दें?

Relevant page-level mapping करें। Unrelated destinations user और search interpretation दोनों में समस्या बन सकती हैं।

Business owner को क्या approve करना चाहिए?

Important old pages, नए content का scope और सही destination की सूची review करें।