Use the checklist before the new design becomes the plan.
The easiest time to protect a useful URL, clarify a form requirement or identify an integration owner is before layouts are approved. Start by recording the current site, then use the checklist to shape the brief, scope and launch plan.
What should you check during a website redesign?
Check the business goal, available evidence, audience, content, URLs, search metadata, mobile experience, accessibility, performance, CMS, integrations, forms, data handling, redirects, launch QA and ownership after release. Record each decision and the person responsible for it.
Give every checklist item a status. An explicit exclusion is safer than an assumption that only appears when the site is ready to launch.
Direction
Decide why the redesign exists before choosing what it should look like.
- 01
Define the business outcome
Write down what should become possible or easier after launch. That may be explaining a changed offer, improving the quality of enquiries, supporting recruitment, reducing manual work or making content manageable.
- One primary outcome
- Priority audience
- Decision owner
- 02
Record the current evidence
Gather the evidence that is genuinely available before changing the site. Useful inputs can include analytics, search data, form quality, customer questions, support requests and feedback from the people who maintain the current experience.
- Available analytics
- Common user questions
- Known failure points
- 03
Set scope, responsibilities and constraints
Identify the required release, the content and systems it depends on, who supplies each input and who gives final approval. Mark unresolved platform or integration decisions for discovery rather than hiding them in assumptions.
- Working scope
- Content owners
- Technical dependencies
Content and search
Protect useful information and search signals while the new structure takes shape.
- 04
Build a content inventory
List every important page and asset. Mark content to keep, update, combine, create or retire, then assign ownership. Review accuracy, duplication, readability and whether each page supports a clear audience need.
- Page and asset list
- Keep or change decision
- Named content owner
- 05
Map every important URL
Export or record the existing URLs before the structure changes. Map each one to its retained URL or closest relevant replacement. This becomes the basis for navigation updates, internal links and permanent redirects.
- Current URL list
- New destination map
- Redirect requirements
- 06
Review how search engines read each page
Give indexable pages a distinct purpose, descriptive title, useful summary, clear main heading and internal links. Review canonical URLs, structured data, image alternatives and which low-value or private pages should not be indexed.
- Page purpose and title
- Canonical and index status
- Internal links and schema
Experience and build
Test the system people will use, not only the desktop composition presented for approval.
- 07
Design for mobile and accessibility from the start
Plan content order, navigation, forms, type and interaction for smaller screens and different input methods. Check semantic headings, keyboard access, visible focus, meaningful labels, colour contrast and reduced-motion behaviour.
- Responsive content order
- Keyboard and focus
- Contrast and motion
- 08
Make performance part of the design decision
Large media, fonts, scripts and motion all have a cost. Agree which assets earn that cost, size images for their rendered use and avoid loading features before they are needed. Measure representative pages during the build.
- Image and video budget
- Font and script review
- Core Web Vitals checks
- 09
Confirm the CMS and integration model
List the content people need to edit and the systems the site must connect to. Confirm permissions, data direction, failure handling and account ownership for forms, CRM, payments, search, booking, analytics or other services.
- Editing requirements
- Integration behaviour
- Account ownership
Launch and continuity
Treat launch as a controlled change with a clear owner and a route for the work that follows.
- 10
Test complete journeys and failure states
Test what happens from arrival to completion across priority journeys. Include empty states, validation, slow connections, missing content, errors and notifications, not just the ideal path shown in a prototype.
- Priority journey QA
- Forms and notifications
- Error and empty states
- 11
Prepare the release details
Confirm DNS access, redirects, canonical URLs, metadata, sitemap, robots rules, consent, approved analytics, backups and rollback responsibilities. Record who is available to make decisions during the release.
- Launch ownership
- Search migration checks
- Backup and recovery route
- 12
Monitor the live site and plan ownership
After launch, check priority URLs, redirects, forms, indexing signals and real-device behaviour. Decide who handles content updates, technical maintenance, incidents and future improvements once the initial project closes.
- Post-launch checks
- Maintenance owner
- Improvement route
Do not let the launch erase the work that search engines already know.
When a redesign changes structure or platform, the release becomes a migration. Existing URLs, internal links and indexation signals need a planned destination. Redirects should point to the closest relevant page, not automatically to the homepage.
Inventory
Record current indexable URLs and valuable assets.
Map
Choose a retained or relevant replacement URL for each page.
Implement
Add redirects, canonicals, metadata and the new sitemap.
Verify
Crawl, test and monitor priority pages after release.
Turn the checklist into a scoped redesign.
You do not need to resolve every item alone. Bring the current site, the reason it needs to change and any evidence you already have. The open decisions can become part of discovery and the written scope.
Website redesign checklist questions.
When should a business redesign its website?
A redesign is worth considering when the current website no longer explains the offer clearly, supports important user tasks, works well on mobile or gives the business a manageable technical foundation. A smaller refresh may be enough when the structure and platform still work well.
Can a website redesign affect SEO?
Yes. Changes to URLs, content, internal links, rendering, metadata and page performance can affect how search engines understand and rank the site. A URL inventory, redirect map, canonical review, sitemap update and post-launch checks help reduce avoidable risk.
Should old pages be deleted during a redesign?
Only after their value and destination have been reviewed. A page may still attract useful visits, answer a specific question or hold external links. If it is removed or consolidated, choose the closest relevant destination and plan the redirect deliberately.
What should be tested before a redesigned website launches?
Test priority journeys, navigation, links, forms, validation, responsive layouts, keyboard access, images, metadata, redirects, analytics where approved, consent behaviour and error states. Check both real devices and representative browser sizes.
Who should be involved in a website redesign?
Include the person responsible for the business outcome, someone who understands the audience and content, the people who manage relevant systems, and a clear final approver. Feedback is easier to use when it is consolidated through one decision route.
