What to check before a website redesign

A redesign can improve the website and still break the routes customers already use. An old service link stops working. A quote form no longer reaches the owner. A domain move disrupts business email because nobody recorded what depended on the account.

Before choosing layouts, make a small preservation plan. Identify what already matters, decide what will change, and assign the checks that protect customer contact and search access. Keep the URL list and contact-path checks beside the design references. They belong in the brief too.

This guide covers preflight work. It does not authorize changes to your site or promise that a redesign will preserve every search position.

Assemble access and a baseline

Bring together the current website, domain registrar, hosting arrangement, business email dependency, and the people authorized to change them. Record account ownership without putting passwords or recovery codes in the brief.

Gather:

• Current page URLs and useful downloads.
• Important incoming links and search-report findings where available.
• Forms, phone links, assistant inquiry paths, and their destinations.
• Approved content, work photos, and permission records.
• A recoverable backup or export appropriate to the current platform.
• Existing provider terms and the proposed change scope.

If access is uncertain, settle it before setting a launch date. A designer's ability to edit pages does not prove the business controls the domain or can restore the current site.

1. Decide what the redesign needs to fix

Describe the business problem before the visual preference. "Customers cannot tell which service fits" is actionable. "Make it more modern" does not define success.

Choose a few concrete outcomes to check, such as clearer service explanations, a working mobile inquiry route, or accurate business information. Do not attach an unsupported conversion target to justify the project.

Separate a redesign from extra systems work. A website change may improve inquiry capture without connecting the CRM or automating appointment follow-up. Name those as separate requirements if you need them.

For a fictional local service business, the brief might preserve a useful repair page while simplifying the form and updating the coverage description. Replacing every page would not automatically help those tasks.

Our article on website scope and cost models covers the purchasing decision. This preflight begins after you identify the work, so valuable existing routes survive the change.

2. Inventory URLs before renaming anything

List the pages customers can reach, including pages outside the main navigation. Add PDFs, important images, and other resources that may have incoming links.

Use the current sitemap, search reports, and provider's page inventory where available. Open the important URLs yourself. A spreadsheet row saying "services" is not a check of the actual address.

Mark each item as keep, improve, combine, or remove, with a reason. A low-traffic page can still matter to an existing customer or support a printed QR code. Do not delete it based on one number alone.

Prefer keeping a useful stable URL when there is no reason to change it. If URLs will change, create a specific old-to-new mapping rather than waiting for broken links after launch.

Google's site-move guidance recommends identifying old URLs, mapping them to appropriate new destinations, and planning redirects. That guidance applies when addresses change; a visual refresh on stable URLs is not automatically a site move.

3. Preserve useful content and its meaning

Read the current service information with the owner. Keep the details customers need, including exclusions, location conditions, and the next step.

A shorter page is not better if it deletes the answer to a common buying question. Conversely, do not preserve an unsupported claim merely because it has been on the website for years.

Record which facts need correction and which artifacts need renewed permission. Photos and customer comments should retain accurate context when moved into a new layout.

Keep titles and headings understandable. If the existing page explains a specific service, replacing its title with "Solutions that inspire" can make the page harder for the reader to interpret.

Archive the original content privately according to the business's record policy. That gives the reviewer a comparison when checking what changed without forcing every old paragraph to stay public.

4. Trace every contact route to its destination

List click-to-call links, ordinary forms, assistant inquiries, scheduling tools, and any embedded third-party route. Record what the customer sees and where the business receives the request.

For each, confirm the responsible person and expected notification timing. A redesigned button that opens a form is only the first part of the path.

Have the provider plan approved end-to-end tests using contact details and destinations you control. Keep real customers out of trial sends, and do not reserve actual appointments as a casual check.

Inspect mobile labels and confirmation wording. A preferred date must not turn into a "confirmed booking" because the new design uses a generic success template.

For a website assistant, preserve the approved information and handoff boundaries. A new layout does not create live human support or automatically carry custom integrations into the scope.

5. Make technical handoffs explicit

Confirm who handles the domain, hosting, certificates, forms, analytics, assistant configuration, and email-related settings. A redesign can cross several of these boundaries even when it appears to concern only pages.

Ask which changes affect existing services. Domain records used for business email need particular care; do not replace them with a guessed template for the new host.

Record the rollback plan and who can use it. "We have a backup" is incomplete unless someone knows what it contains, how to restore it, and whether the old arrangement remains available during the move.

Do not assume a managed website is transferable after cancellation. Read the relevant agreement. LeadSpark's current Business Hub plans state that the domain and business data remain the owner's while the website, hosting, and managed service belong to the active plan arrangement. Custom work follows its written scope.

Settle permissions and responsibilities before the switch, not while customers are reporting missing pages.

6. Agree on the prelaunch checks

Ask for a reviewable preview and compare it with the preservation plan. Check page content, important links, phone actions, image context, and the inquiry routes.

If addresses change, exercise the redirect mapping. Each old important URL should reach the appropriate new destination rather than landing indiscriminately on the homepage. Check internal links and canonical references as part of the provider's technical review.

Google's move guidance also warns about carrying temporary indexing restrictions into the released site. Confirm that preview protections are handled deliberately and that pages intended to be public are not left blocked by mistake.

Keep desktop and mobile review separate. Look for clipped text, covered buttons, awkward images, and a contact action that disappears below a large visual.

Write down failed checks and retest the corrected target. Do not sign off solely because the homepage looks finished.

Plan the first postlaunch review before launch

Agree who verifies the live URLs and contact paths after the release, and who watches for reports of missing content. A successful preview is not the same as a working production site.

When URLs change, keep the redirect plan and supporting records available. Google's current guidance recommends keeping redirects for at least a year and notes that site moves can involve search fluctuations while changes are processed. Do not promise an instant, consequence-free transition.

Compare later search and inquiry observations with the saved baseline, using the same definitions. A change in traffic after release is a finding to investigate, not automatic proof that the redesign caused it.

The Websites and Conversions hub covers broader website decisions. The preflight's job is to make this particular change safe enough to review.

What if the old provider cannot give us an export?

Clarify the contract and available options before proceeding. You may need to preserve approved content manually or choose a different transition. Do not describe unverified recovery as guaranteed.

Can we redesign while leaving the domain alone?

Often the public domain can remain stable, but hosting and record changes may still be involved. Have the implementer explain the actual plan rather than treating it as a purely visual change.

If your business needs a managed website, compare Business Hub plans. Bring the URL inventory and contact-path list into the conversation. Specialized migrations and integrations need their own review and scope before anyone changes production.