Website Redesign Checklist: Plan, Protect, and Relaunch

Website redesign checklist: protect the working system

A website redesign checklist should prevent a new presentation from breaking a working business system. The current site may contain useful URLs, indexed pages, functioning forms, measured conversions, and familiar customer journeys even when its visual design feels dated. Record what must survive before deciding what should change.

State the redesign goal in business terms and set the boundary. Improving an unclear service path or an inaccessible form can be measured; merely making the site feel newer cannot. A redesign changes presentation, structure, and content. A simultaneous domain, CMS, or hosting move adds different failure modes and should be separated when possible.

Record goals, baseline evidence, scope, and owners

Capture the baseline before implementation: important landing pages, search impressions and clicks, conversions by journey, current URLs and redirects, representative performance evidence, accessibility barriers, integrations, and support or incident history. Use the same definitions after release so the comparison remains meaningful.

Write explicit in-scope and out-of-scope lists and identify the people authorized to decide. Name owners for content and factual claims, design and accessibility, the technical build, redirects, analytics, account access, and the launch decision. Document the acceptance evidence for each part instead of leaving approval as a general impression.

• Business goal and success measure
• Current evidence and collection date
• Included templates, journeys, content, and integrations
• Decision owner, implementation owners, and launch authority

Inventory content and make an explicit decision for every URL

Build a content inventory from the CMS, sitemap, analytics, and a crawl. Include the URL, title, template, purpose, owner, traffic or conversion evidence where available, and last substantive review. Reconcile the sources so orphaned pages and older campaign URLs do not disappear from the plan.

Assign each item a keep, improve, merge, redirect, or remove decision. Preserve useful material when pages merge, and do not remove a productive page only because it does not fit the new layout. Record where discontinued facts, downloads, images, and legal or policy text will go before the new templates are considered complete.

Preserve URLs or create a direct redirect map

Keep existing URLs when the resource and its purpose remain the same. When a URL must change, map the old address to the closest relevant replacement and use a server-side permanent redirect for a permanent move. Google's site-move guidance recommends avoiding chains, updating internal links and canonical URLs, and submitting a sitemap containing the new URLs.

Test every mapped old URL before and after launch, record the status and final destination, and retain the map. Do not route unrelated retired pages to the homepage. Update navigation, contextual links, canonicals, structured data, hreflang where applicable, feeds, and campaign destinations so the redirect is a safety net rather than the site's permanent internal routing layer.

Validate hierarchy, mobile behavior, and accessibility

Design and approve reusable templates and states: headings, body copy, links, buttons, forms, validation, dialogs, tables, media, empty states, and errors. Test with long names, missing images, detailed articles, real policies, and other content that exposes constraints hidden by placeholder copy.

Review representative templates on actual small and large screens. Apply W3C's Easy Checks and complete the main journey with a keyboard. Confirm page titles, headings, text alternatives, contrast, resizing, focus visibility and order, labels, instructions, and error recovery. Record remaining barriers and specialist review needs without describing this template check as accessibility certification.

Prove ownership, integrations, measurement, and recovery

Confirm that the business controls the registrar, DNS, hosting, CMS, analytics property, form destinations, payments, CRM, scheduling, consent system, email services, and recovery accounts. Give vendors named access rather than leaving essential assets in an individual's or former agency's account.

Test every integration on the new implementation and intentionally rebuild measurement. Record event names, conversion definitions, destinations, and consent behavior. Export the current site's content and configuration before cutover, but understand the export's scope: WordPress's Tools Export creates a content XML file and is not a complete files-and-database backup. Keep a documented, tested rollback path.

Test staging without publishing it to search

Restrict staging with authentication or an equivalent access control appropriate to the platform. A robots rule is a crawler instruction, not an access control. Use non-production payment modes, suppress real customer notifications, protect personal data, and clearly label the environment so tests cannot be mistaken for production activity.

Check the staging host for accidental public links and confirm its URLs have not entered search results. Before launch, create a separate production checklist for removing temporary restrictions and verifying robots directives, canonicals, public assets, analytics configuration, and crawler access on the actual production response.

Run the launch and monitor after release

Write a runbook with ordered actions, owners, verification evidence, stop conditions, and rollback triggers. Schedule the cutover while the people who can diagnose content, DNS, hosting, forms, analytics, and payments are available. Preserve the pre-launch backup and configuration until the monitoring window closes.

After cutover, verify HTTPS and the canonical hostname, response codes, robots and canonical tags, direct redirects, sitemap URLs, critical journeys, notifications, analytics events, and representative performance. Monitor errors, 404s, search reporting, conversions, and Core Web Vitals against the recorded baseline. Investigate a change using the URL map and release record instead of making several untracked corrections at once.

Separate redesign work from migration when possible

A redesign, domain move, CMS replacement, and hosting move affect different layers. Combining them expands the number of possible causes when something fails. Prefer a sequence that keeps design and URLs stable during a platform move, or keeps the platform stable during the redesign, with a baseline and verification period for each stage.

When combined change is unavoidable, document the dependencies and rollback boundary for every layer. Follow the detailed migration checklist for URL and platform changes rather than stretching the redesign checklist into a second migration plan. Your next action is to create the content inventory and make a keep, improve, merge, redirect, or remove decision for every URL.