Website Redesign Checklist Before You Rebuild

A redesign should not begin with a request to make the website look newer. It should begin with a decision about the condition of the current site, the business problem that needs to be solved, and how much of the existing foundation still has value.

Write down the business reason for the work before reviewing layouts. A useful goal describes a customer or operating problem, not a style preference. The redesign might need to clarify services, improve mobile inquiry paths, support a new offer, reduce content-management friction, or prepare the site for a larger system.

• Name the primary audience and the decision that audience needs to make.
• Identify the pages or journeys that support the most important inquiries, bookings, purchases, applications, or support needs.
• Document what the current website prevents the business from doing well.
• Separate launch requirements from ideas that can wait for a later phase.
• Choose practical indicators to monitor after launch without treating improvement as guaranteed.

A clear outcome helps prevent the project from becoming a collection of unrelated preferences. It also makes it easier to decide which existing elements should remain and which changes deserve the cost and migration risk.

Create a working inventory of the current site. This can begin with the sitemap and be expanded with analytics, Search Console, CMS exports, form records, and input from the people who update or sell through the website.

• Every indexable page and its current URL.
• Page title, purpose, audience, primary action, owner, and last meaningful update.
• Navigation links, footer links, breadcrumbs, and important internal links.
• Forms, confirmation pages, automated emails, downloads, scheduling tools, and payment paths.
• Analytics tags, consent settings, conversion events, advertising pixels, and Search Console access.
• Third-party scripts, plugins, embedded tools, APIs, DNS records, hosting, email dependencies, and authentication flows.

A page can be valuable for several reasons. It may attract relevant search visits, answer a frequent sales question, support a campaign, earn external links, explain a complex service, or provide a trusted destination for existing customers. Low traffic alone does not automatically make a page disposable.

Record the decision beside every URL. This becomes the bridge between content planning, development, redirects, internal links, and launch QA.

The content review should examine whether each page helps a real visitor understand the offer and choose a next step. The navigation review should test whether related pages are grouped in a way that matches how customers think, not only how the business is organized internally.

• Content: confirm accuracy, ownership, usefulness, duplication, tone, proof boundaries, and the questions each page still needs to answer.
• Navigation: test service labels, hierarchy, page depth, breadcrumbs, footer routes, search paths, and dead ends.
• Mobile: review tap targets, text wrapping, media crops, sticky elements, forms, menus, load behavior, and whether the primary action remains reachable.
• Accessibility: review semantic headings, keyboard access, focus order, labels, error messages, contrast, alternative text, motion, and zoom behavior.
• Visual system: identify brand elements worth preserving and inconsistent patterns that make the site harder to understand or maintain.

These reviews are related. A navigation label can be technically functional but unclear. A form can look polished but be difficult to complete with a keyboard. A strong desktop layout can hide the primary action below several screens on mobile.

List the actions that matter today and trace each one from entry page to confirmation and follow-up. Examples include a call, consultation request, quote, booking, application, purchase, download, account login, or support request.

• Which pages introduce each action, and whether the CTA matches the visitor's context.
• Which form fields are required and whether each field improves qualification or routing.
• Where submissions are stored, who receives notifications, and what happens when delivery fails.
• Which confirmation pages, emails, CRM records, tasks, or scheduling steps follow submission.
• Which consent, privacy, security, or sensitive-data boundaries apply to the workflow.
• Which events are currently measured and how duplicate or test submissions are excluded.

Record the current measurement setup before changing page paths, forms, or consent behavior. Capture the property and container identifiers, event names, conversion definitions, referral exclusions, campaign parameters, consent rules, and the people or vendors who control each account.

• Export a baseline view of important landing pages, traffic sources, search queries, form starts, submissions, calls, bookings, and other agreed events.
• Document where tags are installed and which events depend on specific buttons, form fields, page paths, or thank-you routes.
• Separate business-critical measurement from tags that are obsolete, duplicated, or no longer approved.
• Plan a production verification step that checks both event delivery and consent behavior after launch.

Historical data will not prove that a redesign caused a future outcome, but it gives the team a reference point and helps reveal whether measurement continuity was lost during the migration.

SEO migration planning is about continuity and clear signals. It does not guarantee stable rankings. It reduces avoidable loss caused by missing pages, changed URLs, weakened content, broken links, conflicting directives, or incomplete launch checks.

• Map current URLs, status codes, titles, meta descriptions, canonicals, headings, structured data, indexability directives, internal links, and sitemap inclusion.
• Identify pages with useful search visibility, external links, local relevance, or strong alignment with a commercial service.
• Keep valuable URLs when the page purpose remains the same and the route is still appropriate.
• When a URL must change, map it to the most relevant live replacement rather than sending every retired page to the homepage.
• Update internal links, navigation, canonicals, structured data, hreflang where applicable, and sitemap output to use final destinations.
• Check redirects and final pages in production, then monitor crawl and indexing signals after launch.

A public website often depends on systems that are not visible in the page design. Before choosing a new architecture, document what connects to the current site, who owns it, how it authenticates, what data it receives, and what would break if its URL or configuration changed.

• CRM, email delivery, scheduling, payments, ecommerce, membership, and client portal systems.
• Maps, reviews, social feeds, chat, video, forms, search, translation, and downloadable-resource tools.
• DNS, domain registrar, hosting, CDN, certificates, transactional email records, and deployment accounts.
• Plugins, themes, licenses, API keys, webhooks, allowed domains, callback URLs, and rate or usage limits.
• Legal, consent, accessibility, security, or data-retention requirements tied to a specific workflow.

Use the redesign to remove dependencies only when the replacement is understood. Newer software is not automatically a better fit, and silent removal can create an operational problem that appears after launch.

Keep the current CMS or platform when it can support the required content, performance, accessibility, integrations, deployment, security, ownership, and maintenance model without fragile workarounds. A redesign does not require migration by default.

• Who needs to edit the site, what they need to change, and how often.
• Whether the current platform supports the required page structure and reusable content.
• Performance and accessibility constraints that cannot be corrected reasonably in the current setup.
• Integration, authentication, ecommerce, or workflow requirements.
• Hosting, deployment, backup, security-update, and recovery responsibilities.
• Licensing, vendor lock-in, developer dependency, and the cost of ongoing maintenance.

Migration is justified when the existing foundation creates a documented constraint. If the platform is healthy, keeping it can reduce scope and risk while allowing the redesign to focus on the customer experience.

The launch checklist should be based on real routes and workflows, not a quick tour of the homepage. Assign owners, test in a production-like environment, and record what must be checked again after deployment.

• Content, spelling, dates, contact details, legal links, and approved brand assets.
• Responsive layouts, navigation, focus states, keyboard use, zoom, forms, error states, and meaningful image crops.
• Forms, notifications, storage, CRM routing, scheduling, payment, login, downloads, and confirmation paths.
• Page titles, descriptions, canonicals, robots directives, structured data, sitemap, redirects, internal links, and status codes.
• Analytics, conversion events, consent behavior, campaign parameters, Search Console access, and monitoring.
• Performance, image sizing, caching, third-party scripts, security headers, DNS, certificates, email records, backups, and rollback responsibilities.

A successful deployment is the start of production verification. Review the routes and workflows with the highest business and migration risk first, then continue monitoring long enough to find issues that only appear through real traffic or scheduled processes.

• Redirect errors, broken links, crawl issues, indexability, sitemap processing, canonical behavior, and important landing pages.
• Form delivery, spam filtering, CRM records, automated email, bookings, payments, downloads, and login workflows.
• Analytics events, consent states, campaign attribution, call tracking, and reporting access.
• Performance, runtime errors, mobile usability, accessibility feedback, and third-party service failures.
• Customer questions, sales-team feedback, content gaps, and maintenance requests that should shape the next iteration.

Do not judge the redesign from a single short period or one metric. Search visibility, conversion behavior, sales quality, seasonality, traffic mix, and operational changes can move independently. Use evidence to decide what to improve next.

• Choose maintenance, redesign, or rebuild based on the health of the current foundation.
• Define the business outcome and the customer journey the work must support.
• Inventory every current page, URL, form, event, integration, and owner.
• Mark pages and content to preserve, improve, consolidate, redirect, archive, or remove.
• Review navigation, content, mobile UX, accessibility, and the visual system.
• Map complete conversion paths from landing page through response and follow-up.
• Document analytics, consent, search, metadata, structured data, and current measurement.
• Create and test URL redirects, internal links, sitemap, canonical, and indexability changes.
• Document third-party tools, accounts, API connections, DNS, hosting, and operational dependencies.
• Keep or change the platform based on verified constraints, not novelty.
• Run route-based content, functional, responsive, accessibility, SEO, analytics, and launch QA.
• Monitor production workflows and migration signals, then prioritize improvements from real evidence.

If the inventory is difficult to assemble, begin with the current public website. A free website audit can identify visible opportunities and risks, while a deeper website redesign discovery can connect those findings to content, systems, ownership, migration, and implementation scope.