A website redesign is easier to manage when the team agrees on the customer problem before choosing a visual direction. This guide provides a practical sequence for writing a brief, auditing existing pages, planning content and URLs, testing the new experience, and measuring the release without promising a particular business or search result.
Write the brief around customer tasks
A redesign brief should describe what people need to do, what currently gets in their way, and what the business needs the site to support. “Make it modern” is a visual preference, not a project objective. More useful goals might be helping visitors compare services, finding a product specification, understanding eligibility, or submitting a qualified enquiry. Start with the audiences and tasks that matter, then note what evidence supports those priorities: support questions, sales conversations, analytics, search queries, usability observations, or feedback from staff who work with customers.
Record a baseline before changing anything. Depending on the site, that may include successful form submissions, checkout errors, search traffic to important pages, mobile task completion, page response times, or support requests caused by missing information. Do not select a target before checking how the existing number is measured. The brief should distinguish an outcome from a deliverable: a new navigation system is something to build; helping visitors find the right service is the outcome it is intended to support.
Audit the current site before replacing it
Create an inventory of the current URLs, page types, important content, forms, integrations, and owners. A crawl can reveal titles, response codes, internal links, canonical tags, and pages that are difficult to reach. Analytics and Search Console can help identify pages with meaningful visits or search impressions, while customer-support and sales teams can explain which information people regularly need. Review mobile and desktop behavior separately; a page that appears complete on a wide monitor may hide its primary action or key information on a phone.
Classify every important page as keep, improve, combine, redirect, or retire. These choices should be based on usefulness and evidence, not on whether the page fits the new design. An old article may still answer a customer question; two service pages may be competing because their purpose is unclear; a retired product may need a relevant replacement rather than a blanket redirect to the homepage. Record decisions and owners in a spreadsheet or content-management tool so the project team can track unresolved copy, approvals, and dependencies.
Define scope, owners, and constraints
List the page templates, unique page types, functional requirements, and integrations that are actually in scope. A small brochure site with a handful of reusable layouts is different from a catalog with filters, account access, payment, and inventory connections. Name who approves content and design, who can provide product or legal information, and who will maintain the site after launch. Delayed decisions and missing content often affect delivery more than the choice of framework, so make review responsibilities visible before implementation begins.
Capture technical and operational constraints: the current CMS, hosting, domain access, analytics setup, consent requirements, accessibility commitments, security needs, and third-party services. Ask what must not change, such as a checkout provider or a support workflow. Identify risks that need investigation, including legacy URLs, undocumented integrations, large media libraries, or forms that route leads to a shared mailbox. A clear scope protects the project from quietly accumulating features that were never estimated or approved.
Plan content and information architecture
Design the navigation and page hierarchy around the language customers use and the decisions they need to make. Group related services or products, keep important paths easy to find, and use labels that are understandable without internal company jargon. A proposed sitemap is a discussion tool: test whether a first-time visitor can locate essential information, compare relevant options, and understand what happens after an enquiry. Do not create a page for every keyword variation or location name; a page should have a distinct purpose and enough useful information to justify its place.
For each retained page, define its audience, purpose, key message, proof points, call to action, and content owner. Decide which facts need review, such as prices, service areas, certifications, customer quotations, and performance claims. Replace unsupported statistics with verifiable information or remove them. Prepare content before visual polish so designers can see the real length, terminology, and interactions the page must accommodate. Google's SEO Starter Guide emphasizes useful, people-focused content and notes that no change guarantees a specific search position.
Design for real tasks and accessibility
Prototype the important journeys before building every page. For a service company, that might mean understanding a service, checking whether it fits, and contacting the right team. For an online store, it may mean narrowing a category, comparing a product, reviewing delivery and returns, and completing a purchase. Test prototypes with representative users where practical, and include small-screen layouts rather than treating mobile as a compressed desktop version. Clear labels, helpful errors, visible focus, and predictable interactions matter as much as the visual system.
Accessibility should be included in design and development acceptance criteria. Check keyboard operation, logical focus order, text alternatives for meaningful images, form labels, contrast, headings, and error messages. Prefer native HTML controls where they fit the interaction, and test with assistive technology rather than relying only on automated scans. A redesign is also a good time to review performance: identify large images, unnecessary scripts, heavy fonts, and third-party widgets before they become part of every page template.
Plan the technical foundation early
Choose a platform based on the content workflow, integrations, team skills, security responsibilities, and long-term maintenance—not only on a launch demonstration. Document who updates content, how changes are reviewed, where media is stored, how backups work, and who receives monitoring alerts. Confirm that forms, search, authentication, payment, and other integrations have test environments or safe ways to validate them. For custom features, describe expected behavior and failure states before selecting implementation details.
Agree on content models, reusable templates, URL conventions, and environment separation before the page count grows. Use staging to test realistic content and permissions. Establish privacy-aware analytics events for tasks that matter, and avoid sending sensitive form values to analytics tools. Define performance checks for representative page types on mobile connections. Technical decisions are easier to compare when the team can see their effects on authoring, speed, reliability, accessibility, and operating cost.
Treat migration as a project
If URLs change, map old addresses to the closest relevant new destination and implement direct permanent redirects where appropriate. Avoid sending every retired URL to the homepage; that can confuse visitors and search engines. Carry forward useful page content, internal links, metadata, structured data that remains accurate, and any necessary files. Decide which pages should be indexable, set canonical URLs consistently, and ensure the sitemap contains only preferred pages that should appear in search. Test these decisions in rendered HTML and server responses, not only in a spreadsheet.
Keep the old-site inventory and redirect map available during launch. Crawl the staging site to find broken links, duplicate titles, missing metadata, unexpected noindex directives, and pages that return errors. After launch, check a sample of old URLs, review server logs and Search Console, and fix important misses quickly. Search engines may take time to process changes, and performance can fluctuate for reasons beyond a redesign. Preserve a clear record of what changed so later analysis does not rely on guesswork.
Test the complete experience before launch
Build a test plan from actual customer and staff tasks rather than checking pages by appearance alone. Verify navigation, search, forms, confirmation messages, email routing, account access, checkout, consent controls, and error states. Test current versions of common browsers on mobile and desktop, use a keyboard for key flows, and confirm that assistive-technology labels make sense. Check every page template with short, long, missing, and translated content if those cases apply. Make sure a failed external service does not leave users with a blank page and no next step.
| Area | Example check | Evidence to keep |
|---|---|---|
| Content and links | Important pages, contact details, and internal links are accurate | Reviewed page inventory and crawl report |
| Forms and integrations | A test enquiry reaches the correct team with a useful confirmation | Test record with personal data removed |
| Accessibility and mobile | Primary tasks work with keyboard and at narrow widths | Issue list and retest results |
| Search and performance | Canonical URLs, redirects, metadata, and key page loads are checked | Redirect map, crawl, and performance baseline |
Do a final content and legal review with the people responsible for those details. Remove placeholder text, verify dates and contact information, confirm consent and privacy behavior, and ensure that analytics are recording the intended events. Prepare a rollback or recovery plan for high-impact systems. The launch checklist should have named owners and a clear sign-off, not just a collection of unchecked tasks in a chat thread.
Launch carefully and monitor the result
Choose a launch window when the responsible team can verify the site and respond to issues. Before switching traffic, confirm backups, domain and DNS access, certificates, analytics configuration, environment variables, and any third-party credentials. Immediately after release, test the highest-priority tasks on the production domain, inspect a representative group of redirects, submit test forms, and review error monitoring. Check that the live site is not accidentally blocked from crawling or left in a staging noindex state.
Monitor the launch over the following days and weeks. Compare conversions, search visibility, customer feedback, page performance, and technical errors with the baseline, while accounting for campaigns, seasonality, and other releases. Fix critical usability or routing problems before making cosmetic refinements. Record unexpected effects and their resolution. A redesign is not finished when the new homepage appears; it is finished when the important journeys work reliably and the team can maintain the site.
Avoid common redesign planning mistakes
A frequent mistake is treating the project as a visual refresh while leaving unclear navigation, outdated content, or broken processes untouched. Another is replacing every URL without a migration map, or beginning development before content owners and integrations are known. Teams also underestimate review time: a page can be implemented quickly yet wait for weeks for product, legal, or leadership approval. Make dependencies visible and decide who can resolve disagreements before they block the work.
Avoid publishing performance claims, customer logos, certifications, or testimonials without permission and evidence. Do not promise that a redesign will guarantee more traffic, a certain ranking, or a fixed conversion lift. Set realistic measures, explain what the team controls, and review outcomes after people use the new experience. A brief grounded in customer tasks, clear migration decisions, and careful quality checks gives the project a stronger foundation than an untested promise of quick results.
