Before a website redesign, record existing URLs and search performance, preserve useful pages, map changed addresses to relevant replacements and test permanent redirects. Check production indexability, canonical URLs, internal links and the sitemap at launch. Monitor errors and enquiries afterwards. These steps reduce avoidable problems; they cannot guarantee unchanged rankings.
A website redesign can change more than its appearance. Replacing the platform, renaming service pages or consolidating articles can alter the addresses customers and Google already use. Plan that work before approving the new site structure.
Our website planning and budget guide helps define the project scope. If you have not decided whether to rebuild, use the redesign versus improvement guide first. This checklist covers the search handover once a redesign is justified.
Record what exists before changing it
Create an inventory of page URLs, important downloads and images. Record page purpose and whether the content will stay, merge or be removed. Save available Search Console page and query data for a consistent date range. Record enquiry activity too, so you can distinguish search changes from a broken contact route.
Keep a backup and identify who can restore the previous release. Write down who owns the domain, hosting and Search Console access. These are project dependencies, including when the site stays on the same domain.
Preserve working addresses where practical
A visual redesign does not require new URLs. Retaining useful addresses removes unnecessary mapping work, although content and template changes still need review.
Where an address must change, map it to a relevant replacement. A redirect from an old plumbing service page to a new plumbing service page has a clear purpose. Sending every removed page to the homepage can confuse customers. Content with no replacement may need a genuine not-found or gone response.
An IDJoy example: mapping a legacy blog address
IDJoy’s repository maps the legacy article identifier web-design-charges-south-africa to /blog/how-much-should-a-small-business-website-cost-in-south-africa/. The old topic and the destination both concern South African website costs. This is a concrete example of choosing a relevant replacement, not evidence of a measured ranking improvement.
Use the same reasoning when preparing your own mapping sheet:
| Old address or identifier | Decision | Destination | Verification |
|---|---|---|---|
| IDJoy legacy website charges article | Replace with current cost guide | Current website cost article | Check server redirect and final page |
/services/cleaning/ |
Keep if the service remains | Same address | Check successful response and page content |
/old-service/ |
Remove if discontinued with no equivalent | No invented replacement | Confirm appropriate error response |
The last two rows are illustrative. Give every real changed URL its own recorded decision. Include query-string addresses and old downloads where they have visitors or links.
Ask for launch evidence
A buyer does not need to write redirect rules. Ask the developer to supply results for these checks:
- Changed addresses use an appropriate permanent server redirect and reach the final relevant page without a loop.
- Retained pages and new destinations load successfully with the expected content.
- Production pages meant for search have no accidental staging
noindexinstruction or crawl block. - Canonical annotations identify the intended production URLs.
- Internal links and the sitemap use the final addresses.
- Navigation and contact routes work on a phone and by keyboard; a real enquiry reaches its destination.
These recommendations follow Google’s site-move documentation. Its guidance covers URL mapping, redirect relevance, production checks and monitoring. Use the documentation with your developer rather than applying a generic redirect to every page.
Separate the migration from unnecessary changes
Changing the domain, platform, page structure and content simultaneously makes problems harder to isolate. Where practical, agree a sequence and test each stage. If several changes must ship together, record the dependencies and rollback process before release.
Keep a separate list of proposed content improvements. Preserving a useful page does not mean keeping every sentence forever. It means understanding its purpose and existing evidence before removing or merging it.
Monitor after publication
Check important old URLs immediately after launch. Review new pages, contact delivery and sitemap access. In Search Console, watch indexing issues and compare page and query performance using comparable periods. Our first seven days after launch guide gives the business owner a wider operational checklist.
A traffic dip needs investigation: check redirects, indexability, content changes and measurement setup. Search performance also varies with demand and other websites. Do not attribute every change to the redesign without evidence.
Google advises retaining redirects for as long as possible, generally at least a year. It also warns that rankings can fluctuate while changed pages are processed. Budget for monitoring and fixes rather than accepting a promise of unchanged rankings.
Include migration work in the redesign quote
Ask IDJoy about website design and development with your existing URL, required changes and available performance data. Request an explicit scope for the content inventory, URL decisions, launch tests and post-launch checks. That makes the handover reviewable before the old site is replaced.