Plan URL mappings, redirects, and language variants before a redesign, then verify old and new pages and monitor errors without promising unchanged rankings.
A redesigned website can be faster and clearer while still sending a customer from an old link to an irrelevant page. The failure is not the button color. It is treating page addresses as disposable implementation details. URLs live in search results, advertisements, bookmarks, and old messages. A redesign needs a transition plan for these entrances, not only approved interface screenshots.
Do not change an address merely because the design changes
First ask whether new URLs are necessary. A different content system or frontend can preserve useful page addresses. If a URL is understandable and stable, changing it may offer little operational benefit. Merging overlapping services or removing a confusing old structure can justify a move. Record that reason rather than treating cleaner URLs as an isolated objective.
Imagine an equipment company with Arabic, English, and Turkish pages. It plans to move an old repair page from /repair to /services/equipment-maintenance. This is a hypothetical planning example, not a claim about a real migration. The content owner decides whether the service remains equivalent, the developer plans the redirect, and marketing checks campaign destinations. Put their responsibilities in a clear project brief.
Inventory old entrances before listing new pages
Collect URLs from the content system, sitemap, traffic reports, and links used by sales staff. Include downloadable proposals, important images, and campaign pages absent from the main navigation. Clicking around the homepage will miss some of them. Classify each address as staying, moving, merging, or being removed without a genuine replacement.
For our equipment company, record the old address, language, purpose, proposed destination, decision owner, and test result. The repair page goes to its new counterpart. Two pages explaining the same service might merge into a comprehensive replacement. An expired offer with no equivalent should not automatically point to the homepage. Google's site-move guidance recommends URL mapping and warns against unrelated redirect destinations.
Choose a valid destination, then test the redirect
For a permanent move, Google's redirect documentation recommends a permanent server-side redirect such as 301 or 308 where possible. Watching a JavaScript transition in your browser is not the same check. Inspect the old URL's response, actual destination, and final content. Prefer a direct destination over an avoidable old-to-intermediate-to-new chain.
Test the repair example as a typed URL, a campaign link with tracking parameters, and an old address saved by staff. Decide deliberately which parameters survive. Dropping a parameter that selects a product or language is a functional change, not housekeeping. Review trailing slashes, letter case, and www variants according to the site's chosen policy rather than letting each produce an accidental competing address.
Treat languages as related pages, not a decorative switch
In our example, the old Turkish page should not send visitors to Arabic simply because Arabic is the default. Map each old page to its appropriate counterpart and test language switching from the new page. If a translation is unfinished, make an explicit release decision: complete it first or retain a valid old version under a controlled plan. Do not silently show English content at a supposedly Turkish address.
Google's localized-page guidance describes reciprocal language alternatives through hreflang. Canonicalization concerns representative URLs for duplicate content; it is not a reason to discard genuine translations. Inspect title, description, main text, and links together for each language. Translating the menu alone does not translate the article.
Rehearse a release that can be recovered
Preserve the previous redirect configuration, new deployment plan, and content needed for recovery. Name the person authorized to decide on rollback and define meaningful triggers: a broken core service, failed request forms, or many important pages disappearing. One keyword changing position during one hour is not a useful operational rollback threshold.
Use a protected test environment and the same URL checklist that will be exercised after publication. If customer records change during the move, plan synchronization or a controlled change window. Restoring an old database must not erase newly received requests. This concern is separate from visual design and needs its own owner in the launch checklist.
Check the actual release
- Every important old URL has an approved outcome: correct content, a correct redirect, or intentional removal.
- Internal links, buttons, and downloads point directly to the intended new addresses.
- Service pages and forms work on mobile in every language, with submissions reaching the correct team.
- Staging indexing restrictions have not accidentally reached public pages.
- The sitemap contains intended indexable addresses, not test or private-account pages.
Google's noindex documentation explains that crawlers need page access to read that directive. Its sitemap documentation also makes clear that submission does not guarantee indexing. Treat both as checks in a larger release process, not switches that guarantee search visibility.
Monitor changes you can explain
After publication, inspect broken addresses and successful submissions, then compare old and new landing-page performance over comparable periods. Record campaign changes alongside the migration date. Otherwise, a paused advertisement may be mistaken for migration damage. Investigate a specific failing address before repeatedly rewriting the entire redirect configuration.
Can a migration guarantee unchanged rankings? No. Google notes that search visibility can fluctuate during a move. The objective is fewer avoidable failures and continuity for visitors, not a fixed ranking promise. Keep redirects in the maintenance plan rather than deleting them after one successful visit. Completion means knowing where the old entrances lead and who will maintain them.
Prepared with AI assistance; technical references are included for verification.