A redesign is often sold as a way to look more modern, but the useful reason to rebuild is usually functional: the site is hard to update, hard to use on a phone, or no longer reflects the business you run. This checklist helps you decide, prepare and rebuild without losing ground.
Decide whether a redesign is actually the fix
Write down the three biggest problems in your own words. If they are about content or clarity, the fix might be copy and structure rather than a rebuild. If they are about mobile usability, editing speed, security updates or integrations, a rebuild is more defensible.
A useful test is to ask your team to update a page and time how long it takes. If a routine change needs a developer, you are paying maintenance for a site you cannot control.
Audit the current site before changing anything
Collect every existing page with its URL and current title. Note which pages get visits and which produce enquiries, using whatever data you already have. Record any traffic decline by page, not just in total, because a site can grow overall while one important service page quietly disappears from search.
Then list what must be kept: pages that rank well, pages customers link to, URLs used in printed material or on WhatsApp messages, and forms people have learned to use.
Plan the structure before the design
Build a simple sitemap. Decide which pages are top-level, which are service pages, and which can be combined. A good structure has a short path from the home page to any service, usually no more than one click away.
Write the scope with page names, not page numbers. Include privacy, terms and any thank you or confirmation pages, since they are frequently forgotten and are needed for forms and advertising compliance.
Protect what already works
Create a redirect plan. Every old URL that changes should point somewhere sensible, and the mapping should be agreed before launch, not after. Keep page titles and descriptions consistent unless you have a reason to change them, and avoid moving content to new URLs without need.
Ask whether the new site will be launched on the same domain. If you change domain, expect a temporary visibility dip and a longer recovery than most people expect.
Review content as part of the rebuild
Old content is often the real reason a redesign is needed. Remove pages with no purpose, update services you no longer offer, and rewrite pages that rank for the wrong intent. Keep facts consistent across the site, since contradictory pricing or address details damage trust quickly.
Plan the launch window
Choose whether to launch all at once or in stages. Staging reduces the risk of a broken form or missing page going live unnoticed, and it lets you compare performance afterwards. Either way, keep the old site available until the new one is verified.
Decide who does the work and how it is paid
Decide between updating the existing site and rebuilding it, and be suspicious of anyone who can only deliver one option. Updating in place is cheaper and less disruptive when the platform is supported and performs acceptably. Rebuilding is the honest choice when the code is unmaintainable, heavily modified or built on something no longer supported.
Whichever route you take, agree how changes during the project are paid for. Without a written change process, every small addition is a negotiation. Ask for a schedule with milestones, a revision allowance per stage and a clear payment schedule, then keep to it.
Write the scope in a way both sides can check
A one-page scope with a page list, named features and clear exclusions prevents most redesign disputes. State who supplies copy and images, who approves, and how many revisions each stage allows. Then attach the page list to the contract rather than describing it in general terms.
Also agree what happens to content you decide not to carry over. Old pages that are deleted should redirect to something relevant, not to the home page, because redirecting everything to one URL is confusing for visitors and unhelpful for search.
Aftercare checklist
Confirm backups run automatically, updates are applied on a schedule, the SSL certificate renews, and someone is responsible for monitoring. Then review search data and enquiry volume over the following weeks, not days, before drawing conclusions.
If you want a second reading of your current site, our website development services page explains how we scope a rebuild, and you can send the details of your existing site for a view on which route makes sense.
Common questions
Will a redesign damage my search rankings?
A redesign changes URLs and structure, so there is genuine risk of losing rankings if it is not planned. The mitigation is a one-to-one mapping of old pages to new ones, permanent redirects for everything that changes, consistent page titles and descriptions, and keeping the same content where it still serves the visitor. A staged launch usually reduces risk.
How do I know if my website actually needs a redesign?
Look at behaviour rather than appearance. If mobile visitors struggle, if updating a page requires a developer, if pages have slow load times, if enquiries arrive from only one or two pages, or if the site no longer reflects the business you run now, a redesign is usually justified. A cosmetic refresh is not enough.
Should I rebuild from scratch or improve what I have?
It depends on the platform and its condition. If the current build is on a supported system and performs reasonably, targeted improvements are usually cheaper and less disruptive. If the platform is unsupported, heavily modified, or built in a way your team cannot edit, a rebuild may be the honest option. Ask a provider to compare both routes.