Website Redesign SEO for Builders: A Pre-Launch Checklist

A new website can look sharper and still lose the pages, search visibility and enquiry data that made the old one valuable.

This often happens when a redesign is treated as a visual project only. The team changes page addresses, combines services, replaces useful copy, removes project evidence and launches new forms without preserving the connections between the old and new site.

Builders and trades do not need to freeze an outdated website to protect SEO. They need an inventory, a decision for every useful URL, working redirects and a launch test that covers both Google and real customers.

This checklist helps home-improvement businesses make the important redesign decisions before launch, when mistakes are still cheap to fix.

First decide what is actually changing

“Website redesign” can describe several technically different projects:

• Visual redesign: the appearance and templates change, but page addresses stay the same.
• Content restructure: services are split, merged or rewritten, so some URLs change.
• Platform or hosting move: the site moves to a new content system, host or CDN.
• Domain move: the business changes from one domain name to another.
• Combined move: design, content, platform and domain all change together.

Risk generally increases as more of these changes happen at once. Google’s Change of Address guidance says that combining a domain move with a redesign and URL restructure can cause traffic loss because individual pages may need to be reassessed.

Keep stable elements stable where there is no commercial reason to change them. A shorter URL is not automatically better than an established URL already earning impressions, links and enquiries.

If the project is only a hosting change and the public URLs remain identical, follow Google’s separate hosting migration guidance. A redesign that changes URLs needs a page-by-page migration plan instead.

Record what the old website already does

Create a baseline before design work starts. Otherwise, nobody can tell whether a missing enquiry route, falling page or lost phone click was caused by the redesign.

Record at least:

• every indexable URL, its title and canonical URL
• current sitemap URLs and any redirects already in place
• Search Console clicks, impressions, queries and landing pages for a useful comparison period
• analytics landing pages and enquiry events
• calls, forms and qualified leads where source data exists
• pages with external links or strong internal-link support
• contact details, service areas and trust information displayed on the site
• important downloads, photographs, videos and project galleries

Do not rank pages by traffic alone. A specialist page may attract few visits but produce valuable enquiries, while a project page may reassure someone who first found the firm through Google Maps. Use business value alongside search data.

A pre-redesign SEO audit should produce an actionable inventory, not simply a list of scores. The key output is a decision for each existing URL.

Give every existing URL one clear outcome

Use four outcomes: retain, improve, merge or retire.

The decision must reflect what the person expected from the old page. Redirecting every removed service page to the homepage gives visitors no equivalent answer. Google’s site-move documentation warns that many old URLs redirected to an irrelevant destination can be treated as soft 404s.

This is also the right time to untangle vague “we do everything” pages. A planned service-page structure can separate roofing repairs, rewires, boiler servicing or extensions where each service has a distinct decision and enough real information to justify its own page.

Build the redirect map before the new site is coded

A redirect map pairs every changing old URL with its most relevant new destination. It should be part of the redesign specification, not an emergency task after launch.

For each row, record:

1. old URL
2. proposed new URL
3. outcome: retain, improve, merge or retire
4. redirect status where required
5. new page purpose and mapping approval

Use server-side permanent redirects, normally 301 or 308, for pages that have permanently moved. Google describes permanent redirects as a strong signal that the destination should be canonical. It also advises sending each old address directly to the final destination and keeping redirect chains short in its redirect guidance.

Avoid sequences such as:

old service page → temporary redesign URL → new service page → trailing-slash version

That creates avoidable delay and more places for the chain to break. Update internal links so they point straight to the final URLs rather than relying on redirects forever.

Google recommends keeping site-move redirects for as long as possible, generally at least one year. From a customer perspective, established useful redirects may deserve to remain indefinitely, especially when old links still appear in emails, directories or printed material.

Protect the staging website without blocking the live launch

A staging site should not compete with the live site or expose unfinished pages. Use password protection or access controls where possible. For a public temporary hostname, Google suggests a noindex rule to prevent it appearing in search.

The launch risk is forgetting to remove that protection. A copied noindex tag or restrictive robots rule can prevent the new pages from being indexed.

Google’s noindex documentation also explains an important distinction: a crawler must be allowed to access a page to see its noindex rule. Blocking the same URL in robots.txt is not a dependable way to communicate the instruction.

Create a launch task that checks the live HTML and HTTP headers for:

• accidental noindex rules
• staging-domain canonical tags
• robots.txt blocks copied from development
• test analytics properties
• placeholder contact details
• links to staging images, scripts or forms

The JavaScript metadata guide for trade websites shows how to compare source and rendered titles, canonicals and robots instructions when a new platform changes them after the page loads.

Transfer the parts customers and search engines rely on

For every retained page, preserve or deliberately improve:

• the service and customer need it addresses
• useful process details and limitations
• real project evidence and approved photographs
• areas genuinely served
• qualifications, memberships and guarantees that are still accurate
• customer questions answered by the page
• title, main heading and description where they remain suitable
• internal links that give the page context
• the enquiry action and expectation it sets

Do not copy old inaccuracies for the sake of consistency. Verify business claims with the person responsible for delivering the work, and use content optimisation to strengthen pages without changing their purpose accidentally.

Project evidence deserves special care. Preserve image permissions, alt text and the connection between each case study and the relevant service. The guide to construction project case studies explains how project pages can support both discovery and trust.

Keep local search details consistent

The website is one part of a local business’s public identity. After a domain or important landing-page change, update the links used by Google Business Profile, other map platforms, trusted directories, social profiles, advertising campaigns, business documents and relevant partners.

Do not change the Business Profile name, category or address merely because the website has been redesigned. Those fields should describe the real business, not the web project.

If the redesign changes the page used on a Business Profile, make sure it still represents the same firm and service. A focused Google Maps SEO review can check how the website and profile support each other, while wider local SEO work should keep service, location and contact signals consistent.

Rebuild tracking before testing the new forms

Tracking is often added late, after the visual work is approved. That creates a blind launch and makes the redesign difficult to evaluate.

List the customer actions that matter:

• click-to-call on mobile
• quote-form start and successful submission
• email or WhatsApp contact where offered
• booking or consultation request
• download of a genuinely useful specification or guide
• qualified lead, site visit and accepted project in the sales process

Test the outcome, not only the button click. Submit each form, confirm the message arrives and verify that the thank-you state appears only after success. Call the displayed number from a mobile, check consent wording and avoid collecting unnecessary information.

Use lead tracking to reconnect website events with qualified enquiries. Otherwise a redesign may appear successful because form clicks increased even while useful jobs declined.

Test the site as a set of customer journeys

Do not approve only the homepage on a desktop monitor. Test representative journeys on real mobile devices and common screen sizes:

• urgent repair search → service page → phone call
• planned renovation search → project example → quote form
• town-specific search → location page → relevant service
• Google Business Profile visit → landing page → contact action
• returning customer using an old bookmarked URL

Check navigation, readable text, keyboard focus, colour contrast, form labels, error messages and tap targets. Confirm that images have sensible dimensions and do not push buttons around while loading.

Performance testing should include the main templates and enquiry flow. The Core Web Vitals guide for construction websites explains how to separate real-user field data from one-off lab tests and prioritise loading, responsiveness and layout stability.

Use a controlled launch sequence

A practical launch order is:

1. freeze unplanned content and URL changes
2. take a final copy of the old URL inventory and redirect map
3. back up the current website and configuration
4. deploy the new site during a period when the responsible people are available
5. remove staging blocks from the live version
6. activate and test redirects from a representative sample and every high-value old URL
7. crawl the live site for broken links, missing pages and redirect chains
8. test calls, forms, analytics events and notification emails
9. verify canonicals, titles, robots rules and structured data
10. publish and submit the new sitemap

Google says submitting a sitemap is a hint rather than a guarantee of crawling. Its sitemap guidance recommends submitting through Search Console so access and processing errors can be monitored.

For a genuine move to a different domain or subdomain, verify both properties, implement the redirects first and then use Search Console’s Change of Address tool. Do not use that tool for ordinary path changes within the same domain, a switch between www and non-www, or a hosting change with identical public URLs.

Monitor without reacting to every daily movement

Google says ranking fluctuations are normal during a significant site move while it recrawls and reindexes URLs. Diagnose a sharp problem before making another large change.

During the first days and weeks, monitor:

• whether important old URLs reach their intended destination
• new 404s and server errors
• sitemap processing and page indexing in Search Console
• impressions and clicks for high-value landing pages
• form delivery, call activity and qualified enquiries
• crawl behaviour and response times where logs are available
• whether old URLs remain in internal links, profiles or campaigns

Do not treat an indexing submission as a substitute for these checks. Google’s Indexing API is not intended for ordinary service, location or project pages, so post-launch discovery still depends on consistent redirects, internal links, canonicals and sitemap URLs.

Investigate patterns. If all service pages disappear, check indexability, canonicals and templates. If one page drops, inspect its redirect and whether the replacement still satisfies the same need. If traffic remains but enquiries fall, inspect the new offer and contact journey rather than assuming a Google problem.

A final go-or-no-go checklist

Do not launch until the owner, developer and SEO lead can answer yes to these questions:

• Is there a recorded outcome for every existing indexable URL?
• Do changed URLs redirect directly to the closest relevant new page?
• Are staging blocks absent from the live site?
• Do canonical tags, internal links and the sitemap use final URLs?
• Have useful service details, projects and trust evidence survived the redesign?
• Do calls and forms work from real mobile devices?
• Is tracking recording successful actions rather than false starts?
• Are Business Profile, directory and campaign links scheduled for updating?
• Is someone responsible for checking errors and enquiries after launch?
• Can the old site be restored if a serious deployment fault appears?

If any answer is “we will sort it out afterwards”, delay that part of the launch. A short controlled delay is usually less expensive than reconstructing lost URLs, leads and evidence from memory.

Final thoughts

In a safe redesign, every change has a reason, every old URL has an outcome and every customer route is tested before launch. Preserve pages that help people, improve weak content deliberately, redirect changed URLs to genuine equivalents and keep enquiry measurement working.

The finished website should be easier to use and easier to maintain without making Google or customers rediscover the business from scratch.

Frequently Asked Questions

Will a website redesign hurt Google rankings?

Not automatically. Risk comes from changes such as lost content, altered URLs without redirects, accidental noindex rules, broken internal links and weaker replacement pages. A planned redesign may still experience temporary fluctuation while Google recrawls significant changes.

Should every old page redirect to the homepage?

No. Redirect an old URL to the closest genuine replacement. If there is no relevant destination, an honest 404 or 410 is usually clearer than sending visitors to an unrelated homepage.

Can we change the domain and redesign at the same time?

It is technically possible, but combining major changes makes faults harder to isolate and may require Google to reassess more pages. Keep the existing structure and content stable where practical, map redirects carefully and use the Change of Address tool only for an eligible domain or subdomain move.

How long should redirects stay in place?

Google recommends keeping site-move redirects for as long as possible, generally at least one year. Established redirects may be worth retaining longer while old links, bookmarks or printed materials still send useful visitors.

What should be checked immediately after launch?

Check indexability, canonical URLs, robots rules, redirects, the sitemap, important page responses, calls, forms and analytics events. Then monitor Search Console and real enquiry quality rather than judging the redesign from appearance or daily rankings alone.