Website Redesign Checklist for Service Businesses

What to keep

Begin with an inventory rather than a new menu. List known URLs from the site, CMS, sitemap and available records; include assets, downloadable files and campaign destinations. For each page, record its purpose, useful content, links and enquiry role. If reliable traffic or lead evidence exists, attach its source and date range. If it does not, mark performance as unknown. Missing analytics is not evidence that a page is worthless.

• Keep established useful routes and distinct answers unless a reviewed decision justifies a change.
• Record working forms, confirmation states, receiving systems and the owner who can verify acceptance.
• Retain approved factual evidence and useful accessibility behaviour, not just the visible text and photographs.
• Save the existing configuration and content needed for recovery before replacing templates or data structures.

Review URL decisions before implementation

Classify each route as retained, revised at the same URL, proposed for consolidation or needing more evidence. Compare the actual content and purpose before proposing consolidation. Where a URL move is justified, map it to a relevant replacement and check links and canonical annotations. Google advises against sending unrelated old pages to one generic destination. An attractive new navigation structure is not a reason to discard useful older URLs.

• Keep unresolved decisions visible in the inventory with a named reviewer; do not turn uncertainty into an automatic deletion.
• Record the old route, intended destination, reason and approval separately from whether the change has been implemented.
• Test any approved redirect directly and confirm the final page supplies the promised information.

Source: Google Search Central: site moves and URL changes
URL-move guidance applies when routes actually change. It does not require a visual redesign to change URLs or guarantee rankings after a migration.

What to change

Separate the work into messaging, navigation, visual design, performance, form delivery and measurement. A new hero image will not clarify an ambiguous offer. A different CMS will not repair missing response ownership. Write the observed problem, proposed change and acceptance check for each work item. This makes it possible to improve one area without silently replacing behaviour that already works.

• Messaging: can a reader identify the service, intended audience and next step without interpreting vague claims?
• Navigation: can people reach the relevant detail and return to related topics without relying only on search?
• Delivery: does the action reach its intended local or production system, with truthful success and failure feedback?
• Measurement: are definitions preserved or deliberately versioned so before-and-after numbers remain interpretable?

What to test before launch

Create an acceptance worksheet with one row per route or critical journey. Include expected behaviour, observed result, evidence location, test date, owner and unresolved issue. Check the actual rendered page as well as server responses. Use synthetic data for form tests, and distinguish a local test from a production delivery test. Do not activate external services simply to make a preview appear complete.

• Route and content: expected response, correct page body, one clear main heading, preserved useful sections and a functioning missing-page response.
• Search settings: intended canonical, robots instructions, sitemap membership and metadata agree with the route’s approved status. Preserve deliberate noindex restrictions.
• Links and assets: destination relevance, in-page anchors, images, downloads and any approved redirects work without misleading labels.
• Forms: required fields, validation, retained input, accepted state, duplicate retry, receiving record and failure recovery match the promised behaviour.
• Accessibility: keyboard path, visible focus, labels, contrast, zoom and mobile layout remain usable; record manual checks alongside automated results.
• Ownership: every failed critical check has a responsible person and a decision; a green build does not resolve an untested business journey.

Check performance without overstating the result

Review loading, responsiveness and layout stability rather than a single score. Current Core Web Vitals cover LCP, INP and CLS. The good-experience thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds and CLS at or below 0.1, assessed at the 75th percentile with mobile and desktop segmented. Use local and lab checks to catch regressions; they do not establish real-user performance for a site that has not launched.

• Record the tested URL, device or emulation, network conditions and build so a comparison can be repeated.
• Investigate unexpectedly heavy images, delayed main content, blocked interactions and moving elements in the actual template.
• If field data is unavailable or insufficient, state that limitation instead of substituting a local score for a public performance claim.

Source: web.dev: Web Vitals and measurement guidance
The thresholds describe experience metrics, not a guaranteed search result. Lab evidence and real-user field evidence are different.

Planning sequence

Approve a small, reviewable release scope before changing the live environment. Name who can authorize release, who verifies the business journey and who can restore the previous working state. Keep the backup and rollback instructions available to those owners, then test the recovery approach in an appropriate isolated environment. A backup that has never been read back leaves an important uncertainty unresolved.

• Inventory and decisions: establish what exists, what must survive and what is explicitly changing.
• Implementation and rehearsal: build the approved changes, run the acceptance worksheet and resolve critical failures.
• Release gate: verify backups, access, unresolved risks and owner approval for the exact environment and integrations.
• Readback and recovery: inspect the released routes and permitted receiving systems; follow the recorded rollback decision if a critical check fails.

Where momentum usually breaks

Teams often finish the visible layout before agreeing how to handle old content, unverified claims or unsuccessful submissions. Another common gap is assuming that a CMS save, deployment message or analytics event proves the user journey works. Reconcile each claim with its actual system of record. Keep local readiness, public availability and verified delivery as separate statuses, and do not describe a redesign as a completed migration before release readback.

• Do not promise unchanged rankings: search visibility can move even when the technical work is careful.
• Do not remove a restriction simply because it prevents a page from appearing in the public sitemap; first establish why it exists.
• Use the website development page for service scope, the platform comparison for technology choice and the lead-form guide for field-level decisions.