Define what the redesign must improve
Write down the commercial problem before discussing colours or layouts. The useful objective may be clearer service positioning, better mobile enquiries, easier product discovery, simpler content maintenance or a safer platform—not merely a newer appearance.
Choose a small set of acceptance measures that match that problem. Examples include a working stored enquiry, fewer steps to a priority service, maintained organic landing-page visibility, improved page responsiveness or a content workflow the team can actually use.
Record the current evidence
Export useful landing pages, search queries, indexed URLs, backlinks, enquiries and conversion paths before changing the site. Mark which pages attract relevant visits, earn links, appear for commercial searches or support sales conversations.
Save the current sitemap, analytics configuration, robots rules, canonical URLs, structured data and important page copy. Screenshots help preserve visual proof, but machine-readable exports are needed to compare URLs and measurement after launch.
A redesign should preserve what already works and improve a defined weakness. Appearance alone is not a measurable project objective.
Inventory content before designing templates
List every indexable page and classify it as keep, improve, merge, redirect or retire. Record its purpose, target customer, priority query, conversion action, owner and required evidence.
Do this before finalising page templates. Otherwise the new design may fit a polished homepage but fail when real service details, comparison content, products, locations or proof must be added.
Keep distinct pages when they satisfy distinct needs. Merge pages that compete for the same intent and add little separate value.
Map every important URL
Keep valuable URLs where possible. When a URL must change, map it one-to-one to the closest relevant replacement with a permanent redirect. Do not send every retired page to the homepage.
Carry forward useful titles, copy, structured information and internal links when they still match the new page intent. Preserve query parameters only when they have a real functional or acquisition purpose.
Prepare the redirect map before launch, then crawl both the old URL list and the new site. A redirect file that was written but never tested is not migration proof.
Protect proof and decision support
Move verified case studies, project photographs, reviews, qualifications, process details and useful answers into the new journey. Do not replace specific evidence with generic marketing copy because the new layout has less room.
Put proof near the decision it supports. A service claim is stronger beside a relevant example, a cost explanation is more useful beside scope boundaries, and a local claim should connect to genuine work or operating context.
Test the complete conversion path
Check mobile navigation, forms, confirmation behaviour, phone and email links, validation, spam controls and the stored enquiry itself. Test keyboard use and useful error messages, not only a successful desktop submission.
Analytics should count a lead only after storage succeeds. Form starts, CTA clicks, email clicks and phone clicks are useful diagnostic events, but they are not enquiries.
Confirm who receives or reviews the enquiry, what happens when notifications fail and whether duplicate submissions are handled safely. A visual confirmation message alone does not prove the lead was retained.
Rebuild search and measurement foundations
Give every indexable page one clear purpose, one primary heading, unique metadata and a self-canonical. Update breadcrumbs, structured data, internal links, the XML sitemap and robots rules so they match the visible site.
Carry forward verified analytics and consent behaviour without loading optional tracking before consent. Annotate the launch date so later changes in traffic or enquiries can be compared with the migration rather than guessed.
Keep staging, previews, internal search results and private account pages out of the public index. Remove temporary blocks from the production site only after the final host and canonical URLs are verified.
Run a release rehearsal
Test the release process in a production-like environment with the real URL map, database migrations, forms, assets and cache behaviour. Check priority pages at desktop and narrow mobile widths and verify that one H1, metadata and structured data render in the final HTML.
Create a dated backup and a specific rollback procedure. A backup is only useful when the team knows which application files, database state, public assets and configuration must be restored.
Launch, verify and watch the right signals
Immediately test status codes, redirects, canonicals, sitemap access, robots rules, important structured data, page assets and the real enquiry journey on the live domain. Read the active release back from production instead of assuming the deployment command changed what visitors receive.
During the first days, watch server errors, crawl and index signals, priority landing pages, matched rankings and stored enquiries. Search reporting arrives with delay, so compare equivalent ranges rather than treating an empty first day as a loss.
Keep the dated rollback until the new release, redirects and conversion path are proven. If a critical journey fails, restore service first; investigate the redesign after customers can use the site again.