A redesign changes more than appearance. Protect useful content and existing URLs, make the new pages easy to navigate, and decide how search engines will find the production version before launch.
Inventory the website you already have
Create a list of existing pages before deciding the new navigation. Review which pages explain important services, answer customer questions or contribute useful traffic and enquiries. Where available, use Search Console and analytics alongside a manual content review.
Assign a destination or action to every significant URL: retain it, improve it, merge it with a genuinely related page or retire it. This exercise prevents a visually clean redesign from accidentally removing the information people came to find. It also gives the development team a concrete migration map.
Give each page a clear purpose
A service page should help a potential customer understand the offer and decide what to do next. A case study should explain the actual assignment and show the work. An article should answer a question with useful detail rather than repeating the sales page in a different form.
Google’s guidance favours helpful content created for people, and its title-link guidance recommends descriptive page titles. Use that as a practical editorial test: does the title describe the page, and does the page fulfil that promise? Avoid creating multiple thin pages that compete to answer the same question.
Plan URL changes and internal links together
For a moved page, map the old URL to the most relevant new destination. Do not treat the homepage as a universal replacement for everything. A visitor looking for a particular service should arrive at that service or a closely related page, not have to start the journey again.
Update navigation, footer links, article links and calls to action to point directly to the intended pages. Test them on the built site, not just in a design file. Every important page should have a sensible route from the main navigation or a relevant parent page.
Separate review settings from launch settings
A private review site can deliberately carry noindex instructions. The public release needs an explicit check of those settings, canonical URLs and the sitemap. A beautiful site that still identifies its temporary review address is not ready for a domain migration.
Agree who controls DNS, hosting, redirects, analytics and search accounts. A launch checklist is only useful if each item has an owner. Keep a record of the old structure and the release configuration so changes can be traced if an issue appears.
Check the rendered experience
Inspect the actual pages on different screen sizes. Verify headings, forms, image descriptions, navigation, keyboard access and video fallbacks. Check that the essential information remains available without relying on an animation to reveal it.
Confirm that page titles and descriptions are specific, images have appropriate dimensions, and missing URLs produce the intended response. Review the structured data against what visitors can actually see. Technical markup should describe the page rather than make claims that the page does not support.
Monitor after the release
After launch, check the production URLs, redirects and sitemap. Review indexing and traffic with enough context to distinguish a migration issue from ordinary variation. Record the launch date and any major content changes so later comparisons are meaningful.
A redesign is complete when the new experience works for visitors and its technical settings match the intended public site. Treat the first post-launch review as part of the project, rather than an optional extra after the design has been approved.
A few useful answers
Will a redesign automatically improve rankings?
No. Design, content, technical changes, competition and other factors affect search performance. A redesign is not a ranking guarantee.
Should old blog posts be deleted?
Review their usefulness and relevance first. Keep, improve or consolidate valuable material rather than deleting everything because the design is changing.
