How to Plan a Website Redesign

A website redesign is easiest to control when it is planned as a migration of a working business asset, not merely as a new visual design. The project must preserve useful content, customer journeys, accounts, data and search signals while improving the parts that no longer work.

Step 1: Define the problem and success criteria

Write down why the redesign is being considered. Examples include:

• customers cannot complete important tasks on mobile;
• the structure no longer reflects the services;
• the platform is unsupported or difficult to maintain;
• the site cannot support a required booking or payment process;
• content is inaccurate, duplicated or hard to update;
• the business lacks control of critical accounts.

Attach a measurable result to each problem. “Modernise the site” is not enough. “Reduce failed mobile form submissions” or “allow staff to update service pages without developer support” can be tested.

Step 2: Create an inventory of the current site

Record every important URL and its role. Include pages, posts, files, images, forms, redirects and indexable archives. Add available data such as traffic, search impressions, external links, enquiries, sales and last review date.

Minimum redesign inventory fields

Field	Purpose
Current URL	Prevents pages from disappearing unnoticed
Page purpose and owner	Shows why the page exists and who can approve it
Performance evidence	Identifies valuable or problematic pages
Decision	Keep, improve, merge, redirect or remove
New destination	Provides the migration and redirect map
Content status	Ready, update required, rewrite or missing

Step 3: Audit ownership and dependencies

Confirm access to:

• domain registrar and DNS;
• current hosting and backups;
• content management system;
• email and transactional email service;
• analytics and Search Console;
• payment, booking and CRM systems;
• advertising and social accounts;
• licences, fonts, images and source files.

Identify integrations and renewal dates. Do not wait until launch week to discover that an old supplier controls the domain or that a plugin licence cannot be transferred.

Step 4: Define the future information architecture

Map customer tasks to pages and navigation. Decide which existing pages retain their URL, which are consolidated and which new pages are necessary. Avoid changing URLs only to make them look cleaner. A stable, understandable URL that already works is usually safer to retain.

Step 5: Prepare content early

Design with real content. Assign each page a writer, reviewer and deadline. Record evidence needed for claims, photographs, product data, policies and calls to action. Resolve duplicated and outdated content before migration.

Step 6: Specify functional and non-functional requirements

Functional requirements describe what the site does. Non-functional requirements describe qualities such as accessibility, performance, security, compatibility and maintainability.

• forms and notifications;
• booking, payment and account flows;
• search, filters and navigation;
• editorial workflow and permissions;
• mobile behaviour;
• keyboard access and error handling;
• backup and recovery;
• page speed and image handling;
• privacy and consent controls;
• logging and monitoring.

Step 7: Plan staging, migration and rollback

Build the new version on a protected staging environment. Decide:

• how fresh content and orders will be synchronised;
• when a content freeze is needed;
• who changes DNS or deployment settings;
• how redirects are installed;
• how the old site is preserved;
• what conditions trigger rollback;
• who has authority to make that decision.

Step 8: Create acceptance tests

Each requirement should have a test and an owner. Include representative devices and browsers, real forms, payment modes, email delivery, redirects, error pages, consent choices, account permissions, backups and restoration.

Step 9: Schedule launch monitoring

For the first days and weeks, monitor:

• server and application errors;
• forms, payments and bookings;
• 404s and redirect chains;
• important search landing pages;
• indexability, sitemap and canonical signals;
• performance and customer reports;
• email delivery and DNS-related services.

Planning checklist

• The redesign has written objectives.
• The current URL and content inventory is complete.
• Business-controlled access is confirmed.
• Every old URL has a decision.
• Content owners and deadlines are assigned.
• Requirements and acceptance tests are documented.
• Migration, redirect and rollback plans exist.
• Post-launch monitoring has an owner.

The next practical step is to finish the current-site inventory before approving templates or deleting any content.