Planning guide / Website redesign
Website redesign checklist.
A stage-by-stage framework for improving a website without casually discarding the useful content, URLs, data and operating knowledge already attached to it.
Direct answer
What should a website redesign checklist include?
A website redesign checklist should cover goals and baseline evidence, stakeholder and user needs, a full page and URL inventory, content decisions, information architecture, conversion journeys, responsive UI, accessibility, technical architecture, CMS ownership, performance, security, analytics, SEO and redirect migration, structured data, quality assurance, launch, rollback and post-launch monitoring. Preserve what already works, document every material URL change and assign an owner to the website after release.
01 / Before pixels
Define why the redesign should exist.
A visual preference is not enough to guide scope or judge whether the result is useful.
Redesign brief checklist
- State the business problem and what should become easier for visitors and internal teams.
- Name priority audiences, their important questions and the actions the website should support.
- Record current evidence: user feedback, search queries, analytics, support questions, sales questions and content-maintenance friction.
- Define scope boundaries: domains, languages, markets, campaigns, portals, integrations and content types.
- Identify fixed constraints such as brand rules, legal review, platform contracts, internal skills and launch dependencies.
- Agree decision-makers and content, design, technical, privacy and launch responsibilities.
- Define measures connected to useful outcomes, together with how they will be collected and interpreted.
Capture a baseline before replacing tracking or changing URLs. Historical comparisons can become unreliable if events, consent behaviour, reporting definitions or channel attribution change during the redesign; document those changes.
02 / Know what exists
Inventory pages, assets, URLs and dependencies.
A redesign is also a migration. Anything not deliberately reviewed can be lost, duplicated or left disconnected.
Create a working inventory from several sources: the CMS, site crawl, analytics, search performance tools, XML sitemaps, internal records and known campaign pages. No single source is guaranteed to reveal everything.
| Inventory field | Record | Decision |
|---|---|---|
| URL and status | Current address, canonical, indexability, response and redirect | Keep, update, merge, redirect, archive or remove |
| Purpose | Audience question, business role and intended action | Preserve, clarify or retire the purpose |
| Evidence | Search queries, visits, conversions, backlinks, internal use and feedback where available | Protect demonstrated value; investigate rather than delete blindly |
| Content | Owner, accuracy, age, duplication, media and accessibility issues | Reuse, rewrite, consolidate, create or obtain approval |
| Template | Page type, fields, components and structured data | Map to the new content model and template |
| Dependencies | Forms, scripts, embeds, downloads, feeds, integrations and campaigns | Replace, reconnect, test or intentionally retire |
| Migration | New URL, redirect target, metadata, content owner and verification status | Assign and track through launch |
When a useful page moves, redirect its old URL to the closest relevant replacement. If there is no meaningful replacement, the appropriate response may be removal rather than an unrelated redirect. Migration decisions should reflect user intent, content and current search guidance.
03 / Content and IA
Organize around questions and tasks.
Navigation should expose a useful mental model; content should give people enough context to decide what to do next.
Information architecture checklist
- Group content around audience needs and business concepts rather than the internal department chart alone.
- Create a proposed sitemap and test whether important information can be found through expected routes.
- Define page types and the job of each type: explain, compare, prove, guide, transact, support or contact.
- Plan contextual internal links between related services, evidence, guides and next steps.
- Keep labels specific and consistent; avoid making every call to action say “Learn more.”
- Design search, filtering or resource taxonomy only when the content volume and user need justify it.
- Define breadcrumbs and parent-child relationships for deeper sections.
Content model checklist
- Give every page one primary purpose, a clear title and an accountable content owner.
- Answer the main user question early, then add evidence, detail, caveats and next steps.
- Separate reusable structured fields from long blocks of rich text where this improves maintenance.
- Specify image, video and document requirements, alternatives, captions, rights and replacement ownership.
- Use verifiable claims; identify approvals required for testimonials, case studies, certifications or regulated statements.
- Plan review dates, expiry rules and what happens when a service, employee, location or offer changes.
Write representative content before finalizing components. Designing with realistic headings, tables, errors and long values exposes layout and content-model problems that placeholder copy hides.
04 / UX and accessibility
Design complete journeys and states.
A polished homepage cannot compensate for unclear forms, hidden decisions or broken keyboard use elsewhere.
Experience checklist
- Map priority journeys from entry through decision, action, confirmation and follow-up.
- Design navigation, menus, search, filters, forms, errors, empty states and confirmation—not only ideal content screens.
- Test content hierarchy and calls to action at narrow and wide viewport sizes.
- Make interactive elements recognizable, with useful hover, focus, active, disabled and loading states.
- Keep forms as short as the real task allows; use labels, instructions, validation and error recovery that do not rely on colour alone.
- Provide user control over motion and ensure essential meaning does not depend on animation, hover or pointer movement.
- Check touch targets, zoom, reflow, text spacing and device orientation where relevant.
Accessibility workstream
Agree the applicable accessibility target and make it part of requirements, design review, development and content—not a single scan near launch. Automated tools can find some issues, but keyboard review and human evaluation of priority journeys are also needed.
- Use semantic headings, landmarks, lists, buttons, links, labels and tables appropriate to the content.
- Provide visible focus, logical focus order and a way to bypass repeated navigation.
- Check contrast, non-colour cues, meaningful link wording and content at text zoom.
- Give informative images useful alternatives; mark decorative images so they can be ignored.
- Ensure dialogs, drawers, accordions and custom controls expose names, states and keyboard behaviour.
- Make media controls and alternatives appropriate to the media and audience.
05 / Technical foundation
Select a stack the team can operate.
Architecture should follow content, integration, security, performance and ownership requirements—not the novelty of a tool.
| Area | Decisions to document | Verification |
|---|---|---|
| CMS | Content types, roles, workflow, preview, localization, media and revision needs | Ask content owners to complete representative publishing tasks. |
| Front end | Rendering, browser support, progressive enhancement, component ownership and dependency policy | Test important pages and interactions on agreed devices and browsers. |
| Integrations | Forms, CRM, email, maps, analytics, search, feeds and external services | Test success, validation, timeout, failure, duplicate and recovery paths. |
| Performance | Image and font strategy, caching, third-party budget, rendering and measurement | Measure representative pages under defined conditions, including after consent. |
| Security | Access, secrets, headers, dependencies, patching, logging and incident ownership | Review configuration and responsibilities before and after deployment. |
| Continuity | Backups, restore, environments, deployment, rollback, credentials and documentation | Rehearse the recovery route appropriate to the site. |
Performance and sustainability checklist
- Use appropriately sized, compressed media and avoid loading decorative assets before they are useful.
- Load only the font styles, scripts and third-party services the experience needs.
- Set explicit dimensions for media to reduce layout movement.
- Keep core content and navigation usable when optional JavaScript or external services fail.
- Review tag-manager and marketing additions as ongoing product changes, not invisible extras.
- Measure after real content, analytics, consent and integrations are present.
06 / SEO and answer discovery
Preserve meaning while changing presentation.
Search migration is a content and URL responsibility. AEO depends on the same foundation: clear, accessible, trustworthy answers that systems can retrieve and interpret.
SEO migration checklist
- Export current URLs, canonical references, indexability signals, titles, descriptions and important internal links.
- Use search performance, analytics and backlink evidence as inputs to page decisions without treating any one metric as the whole value.
- Maintain a one-to-one redirect map for changed URLs and avoid redirect chains.
- Keep canonical URLs, internal links, hreflang where relevant and XML sitemaps aligned with the final production addresses.
- Give pages unique, descriptive titles and headings that match the visible content and intent.
- Validate robots directives, robots.txt, response codes and canonical tags in the production environment.
- Implement structured data only for supported content that is visible and accurate; validate the generated markup.
- Keep important content in crawlable HTML and link new pages through normal anchors.
- Verify the site in appropriate webmaster tools, submit the final sitemap and monitor coverage after launch.
AEO content checklist
- State the primary answer near the top, then support it with definitions, steps, comparisons and caveats.
- Use specific entities, terminology and relationships consistently; explain ambiguous terms.
- Show who is responsible for the content and when planning guidance was updated.
- Prefer useful tables, lists and descriptive headings where they make information easier to extract and verify.
- Link to deeper service and guide pages so a reader or system can follow the topic.
- Do not invent expertise, reviews, statistics or guarantees to make content appear authoritative.
Good technical foundations, content and migration discipline reduce avoidable problems and help search systems understand a site. Rankings and answer inclusion remain controlled by search systems and competing information; they cannot be promised by a developer or agency.
07 / Quality assurance
Test content, behaviour and operations together.
Quality assurance should trace requirements across templates and complete user journeys, not only check whether pages resemble designs.
Pre-launch QA checklist
- Review every template with realistic short, long, missing and unusual content.
- Test navigation, breadcrumbs, search, filters, links, forms, downloads, embeds and external-service states.
- Check agreed browsers, viewport sizes, input methods and representative networks.
- Run keyboard and accessibility reviews of priority journeys; resolve critical issues before release.
- Verify page titles, descriptions, canonical tags, structured data, social metadata, response codes and redirect rules.
- Confirm analytics and consent events against a written measurement plan; prevent internal or test activity where appropriate.
- Review privacy notices, form destinations, data retention and third-party disclosures with responsible owners.
- Check administration permissions, publishing, preview, media handling, revisions and user documentation.
- Confirm production configuration, domain records, certificates, security headers, backups, monitoring and rollback.
Record issues with severity, affected journey, evidence, owner and retest status. A launch decision should distinguish blockers from improvements that can safely follow, with known risks accepted by an accountable owner.
08 / Release and learn
Make launch observable and reversible.
Deployment is one technical event inside a wider migration involving people, content, domains and external systems.
Launch sequence
- Freeze and record. Agree content freeze rules, final data sources, current configuration and responsible people.
- Back up and prepare recovery. Know what can be restored, by whom and under which conditions.
- Deploy and migrate. Follow the runbook for code, content, media, configuration, redirects and domains.
- Run smoke tests. Verify priority pages, navigation, forms, authentication where relevant, integrations, analytics and redirects on production.
- Open deliberately. Remove temporary access or indexing restrictions only after checks pass.
- Monitor. Watch availability, errors, form delivery, search crawling, redirects, external services and user questions.
- Review and improve. Compare against the documented baseline carefully and prioritize evidence-led changes.
Post-launch ownership checklist
- Name who owns content, technical updates, access, analytics interpretation, search monitoring and vendor relationships.
- Keep a change log for significant releases, tracking changes and content migrations.
- Schedule content review and maintenance appropriate to the site.
- Review real queries, failed searches, form issues and support questions for improvement opportunities.
- Retest critical journeys when dependencies, browsers, tracking or content models change.
Hich Web Development
Planning guidance from the organization.
Published and updated .
09 / Focused answers
Common redesign questions.
These answers help frame scope; the correct route depends on the existing site and goals.
Should all old website content be copied to the redesign?
No. Inventory it first, then keep, improve, consolidate, archive or remove it based on purpose, accuracy, audience value and evidence. Content that moves should have an owner and a place in the new structure.
Should URLs change during a redesign?
Only where a change creates meaningful structural or content value. If a useful URL changes, map it to the closest relevant replacement, update internal references and verify the redirect. Stable URLs reduce migration work and risk.
Can a redesign improve SEO automatically?
A redesign can improve technical and content foundations, but it can also damage visibility if content, URLs, internal links or indexability are handled poorly. Audit, migration planning and post-launch monitoring are essential; results cannot be guaranteed.
When should content writing begin?
Content planning should begin during discovery and structure work. Representative final content should inform templates and components early; waiting until the end hides missing fields, unclear approvals and layout problems.
10 / Continue
Turn the checklist into a migration plan.
Explore the build, UX and search routes that commonly connect to a redesign.