Last updated: October 2026

A successful redesign is a business and content project as much as a design project. The most expensive mistakes usually happen before development: unclear scope, missing account access, unassigned content, untested forms, and URLs that have no replacement plan.

This website redesign planning guide helps small and mid-sized businesses decide what to change, preserve useful search and customer pathways, brief a provider, and determine whether a site is ready to launch. It is designed to support a practical decision rather than promote a particular platform or visual style.

Planning is also the point at which a business can separate essential requirements from preferences. A required customer login, reliable quote form, accessible navigation, or controlled redirect plan should be documented differently from a preferred colour, animation, or page transition. That distinction helps the team protect important outcomes when time or budget requires tradeoffs.

Choose the right project scope before discussing design

Begin by describing the problem in specific terms. “The site looks old” may describe a visual issue, but it may also point to unclear messaging, poor navigation, slow pages, outdated functionality, inaccessible content, or an ownership problem.

A migration moves existing material without necessarily changing the experience. A refresh improves selected parts while retaining much of the current structure. A redesign changes the broader visual system, information architecture, user journey, functionality, or platform.

Decision rule: choose the smallest scope that solves the documented problem. If the current navigation works and only several pages are weak, a controlled refresh may be safer than rebuilding everything. If visitors cannot understand the services, complete important tasks, or use the site across devices, broader change may be justified.

How to tell whether the problem is structural

Look for repeated problems rather than relying on a single impression. If visitors regularly ask where to find a service, staff cannot update important pages, forms fail to reach the right person, or mobile users cannot complete key tasks, the issue is probably more than visual styling.

Review customer questions, support requests, sales feedback, analytics where available, and the experience of staff who manage the site. The goal is not to treat every complaint as proof that a rebuild is necessary. It is to identify whether the proposed scope addresses a recurring obstacle.

Define business goals and user tasks

Replace “make the website better” with a short list of outcomes and visitor tasks. Depending on the business, visitors may need to request a quote, understand a service, find a product, download a document, book an appointment, contact a representative, submit a support request, or complete an order.

For each priority audience, record the task they need to complete, the page or pathway that should support it, and the evidence the business will review after launch. Measures may include qualified inquiries, completed forms, product orders, document downloads, appointment requests, or successful support journeys. These are useful planning measures, not guaranteed outcomes.

Canada’s content design guidance recommends identifying the user’s task first and allowing that task to guide design decisions. A documented website design workflow can connect those goals to content planning, prototypes, development, quality assurance, and launch.

Do not approve a homepage concept until the team can explain which audience and business problem it supports. A polished homepage cannot compensate for an unclear service structure, incomplete customer journey, or missing call to action.

Write requirements that can be checked

Each priority goal should have a corresponding acceptance check. For example, “make quote requests easier” might mean that a visitor can identify the relevant service, understand what information is needed, submit the form on a phone, receive confirmation, and reach the correct internal recipient.

This approach makes project discussions more practical. Instead of asking whether a page feels modern, the team can ask whether the page explains the offer, supports the intended task, works at the required screen sizes, and has been approved by the person responsible for the information.

Audit the current website before changing it

Build one working inventory of what exists before deciding what to keep, rewrite, consolidate, redirect, archive, or replace. The inventory should cover more than visible pages because a redesign can break systems that visitors never see directly.

• Record page URLs, titles, headings, metadata, internal links, traffic information where available, and important entry pages.
• Inventory images, videos, downloadable files, brand assets, fonts, and licensed materials.
• List forms, email notifications, calendars, search, customer accounts, booking tools, and other integrations.
• Document ecommerce categories, products, filters, checkout steps, order notifications, inventory, and administrative workflows where relevant.
• Record analytics, advertising tags, consent tools, backups, reporting connections, and conversion tracking.
• List domains, DNS records, hosting, administrator accounts, plugins, themes, software licences, and third-party services.
• Assign a named owner to each important page, asset, system, approval, and account.

For every URL, mark whether it serves an important business or search function, whether its information remains accurate, and what should happen if it is removed. A simple keep, rewrite, combine, redirect, archive, or create decision makes later work more controlled.

Review the current site with people who use it. Sales staff may know which pages help prospects, customer-service staff may know which questions are difficult to answer, and administrators may know which forms or integrations are fragile. Their input can reveal valuable pathways that analytics alone will not explain.

Audit access and dependencies separately

Make a separate access list for the domain registrar, DNS, hosting, content management system, analytics, email delivery, advertising accounts, customer relationship tools, payment services, backups, and third-party plugins. Record the account owner, administrator, recovery method, renewal responsibility, and business email associated with each account.

Do not place passwords in a general project brief. Instead, confirm that the appropriate people can provide secure access through an agreed method. The important planning question is whether the business can recover and control the systems required to build, launch, operate, and maintain the website.

Stop point: pause if nobody can access the domain, hosting, analytics, content management system, or key integrations. A redesign cannot be planned responsibly when the business does not know which accounts exist or who controls them.

Plan content, navigation, and information architecture

Use the audit to create a proposed page map rather than copying the old navigation automatically. Organise pages around visitor tasks, recognisable service or product terms, and the information customers need before taking action.

For each proposed page, identify its purpose, primary audience, owner, source material, required call to action, and approval path. Decide whether the content will be migrated as written, rewritten, consolidated, newly created, or removed. Include a target date for review so unapproved copy does not quietly become a launch dependency.

Content responsibilities may include drafting, subject-matter review, legal or regulatory review where relevant, image selection, accessibility review, and final sign-off. Make the same decisions for downloadable documents, product data, forms, error messages, confirmation emails, and other content that is easy to overlook.

Clear structure also supports accessibility. British Columbia accessibility guidance highlights descriptive hierarchical headings, consistent structure, search where appropriate, keyboard navigation, assistive-technology access, and user testing.

Use labels that visitors understand rather than internal department names. A navigation item such as “Services,” “Products,” “Support,” or “About” may be clearer than an organisational term that makes sense only to staff. Test the proposed sitemap with realistic questions: Where would a new customer look for pricing? Where would an existing customer find help? Where would a supplier find the relevant contact?

Build the page map around decisions

A page map should show more than page titles. Include the page’s purpose, intended audience, primary action, source of the information, owner, status, and relationship to nearby pages. This helps the team identify duplicate pages, missing steps, weak calls to action, and content that should be consolidated.

Plan reusable templates where appropriate, but do not force every page into the same pattern. A service page, product detail page, support article, contact page, and legal notice may have different information needs. Consistency should make the site easier to understand without hiding distinctions that matter to visitors.

Stop point: if content has no owner or approval date, do not treat the page map as final. Unapproved content is a common reason for late changes, incomplete pages, and delayed testing.

Protect search visibility during the redesign

A redesign does not automatically improve search performance. The safer approach is to preserve useful intent and pathways while making deliberate improvements to structure, content, performance, and user experience.

• Capture important old URLs before development begins.
• Map each changed URL to a relevant new destination with the same underlying intent.
• Use redirects when addresses change and test them from the old URL.
• Review titles, headings, visible copy, internal links, image descriptions, and metadata.
• Preserve useful topic coverage unless there is a documented reason to consolidate or remove it.
• Check canonical settings, indexing controls, XML sitemaps, analytics, and tracking after launch.
• Review broken links, redirect chains, missing pages, and unexpected changes in crawlable content.

Do not redirect every old page to the homepage. A relevant service, product, location, or information page is usually more useful when the original page has been replaced. Keep a record of removed URLs, the reason for removal, and the replacement destination.

Separate content decisions from URL decisions

A page can be outdated while its URL remains valuable, and a new page can require a clear address from the beginning. Review the content decision and the URL decision separately: first determine whether the information should remain, change, combine, or disappear; then determine the most relevant destination and redirect treatment.

Review search-focused changes in context. A shorter page is not automatically better, and retaining every paragraph is not automatically safer. The decision should consider the page’s user task, business value, accuracy, internal links, and relationship to other pages in the new structure.

Specify responsive, accessible, performance, and technical requirements

Turn design preferences into requirements that can be demonstrated and tested. A responsive website should keep content readable, navigation understandable, forms usable, and important actions available across phones, tablets, and desktop screens.

Include requirements for text size and contrast, reflow at narrow widths, descriptive headings, keyboard operation, focus visibility, form labels, error messages, alternative text, and assistive-technology access. Do not claim formal compliance unless the project includes a defined assessment against the relevant standard and identifies the standard being assessed.

Document performance expectations, image handling, hosting, security, analytics, email delivery, CRM connections, search, downloads, backups, and third-party integrations. Specify who configures each item and how it will be tested. “Fast,” “secure,” and “integrated” are useful goals only when the project explains what will be delivered and checked.

If the site sells online, include product data, categories, filters, customer accounts, payments, shipping, taxes, returns, inventory, notifications, order administration, and customer-service workflows as applicable. Ecommerce testing should include failed payments, incomplete addresses, confirmation messages, duplicate submissions, mobile checkout, and administrative handling – not only a successful desktop order.

Use responsive design testing checks to review representative devices and complete journeys rather than judging only the homepage. Big Time IT Solutions describes responsive website design, ecommerce development, website optimisation, prototyping, and quality-assurance-related capabilities; exact deliverables still need confirmation in the project scope.

Define what “ready” means for each requirement

For every technical requirement, identify a visible or repeatable test. A form requirement might include delivery to the correct inbox, a useful confirmation message, validation for missing information, and protection against duplicate submissions. A responsive requirement might include readable content, usable controls, and no horizontal scrolling at the agreed screen sizes.

This prevents technical language from becoming a promise with no shared meaning. It also gives the business a practical basis for accepting work, recording defects, and deciding which issues must be resolved before launch.

Put scope, deliverables, and ownership in writing

A useful redesign brief gives every participant the same definition of “finished.” Include business goals, priority audiences, user tasks, page inventory, proposed sitemap, content responsibilities, design direction, technical requirements, integrations, search safeguards, accessibility expectations, milestones, approval points, testing responsibilities, launch support, maintenance, and exclusions.

State who supplies copy, images, product data, legal notices, credentials, and approvals. Also identify who configures forms, analytics, redirects, hosting, backups, email notifications, and third-party integrations. A responsibility matrix can show whether each item is owned by the business, provider, or a named shared team.

Confirm that the business will retain appropriate administrator access to the domain, DNS, hosting, content management system, analytics, advertising accounts, email services, and connected tools. Clarify ownership of content, customer data, design files, development files, databases, licensed assets, and backups if the relationship ends.

Compare providers by scope, process, communication, technical fit, support, and ownership terms – not only by screenshots. Big Time IT Solutions Inc is based in Surrey, BC, and states that it serves clients locally and across Canada, the US, and the UK. Its published process refers to project analysis, prototyping, delivery, and quality-assurance testing; confirm the precise scope, milestones, access terms, and handover requirements in writing.

If the redesign supports printed materials, signage, or an in-person installation, coordinate digital brand decisions with the physical implementation plan. Related branded installation planning can involve practical site and approval considerations beyond screen design.

Clarify post-launch responsibility

Launch is not the end of the ownership discussion. Identify who monitors forms, updates content, renews domains and services, applies software updates, manages backups, reviews analytics, handles defects, and approves future changes. Also specify how urgent problems will be reported and who can authorise a rollback or temporary workaround.

Stop point: if a proposal uses broad terms such as “SEO,” “responsive,” “ecommerce,” or “support” without listing actual tasks and exclusions, request clarification before signing.

Test the complete website before approving launch

Test representative pages and complete journeys, not just attractive screens. Include phones, tablets, desktop widths, portrait and landscape orientations, and realistic connection conditions where they matter.

• Navigate menus, search, breadcrumbs, calls to action, and error pages.
• Complete forms with valid, invalid, missing, unusually long, and incorrectly formatted entries.
• Use keyboard navigation and verify focus order, visible focus states, labels, and error recovery.
• Check headings, readable content, images, links, downloadable files, and alternative text.
• Test redirects, internal links, metadata, analytics, tracking, indexing controls, and XML sitemaps.
• Test ecommerce product browsing, filters, cart, checkout, confirmation, notifications, and administration where applicable.
• Confirm integrations, email delivery, backups, security settings, and rollback procedures.
• Obtain content-owner approval for every launch-critical page.

Prioritise defects by impact

Assign one person authority to record defects and another authority to approve launch. Classify issues by severity so a cosmetic spacing issue does not receive the same treatment as a failed form, missing redirect, inaccessible checkout, or broken customer-data integration.

A useful test record identifies the page or journey, device or environment, steps taken, expected result, observed result, evidence, owner, severity, and retest status. Keep a separate list of accepted limitations so the business knows which issues remain after launch and who is responsible for addressing them.

Run a final content review after technical fixes. Late development changes can remove copy, alter headings, break links, change form recipients, or replace approved images. The final approval should therefore cover both function and the visible information customers will receive.

Use a launch-readiness decision

Proceed when goals, scope, content owners, account access, sitemap, technical requirements, redirects, testing, approvals, and post-launch responsibilities are documented. The team should know who can make the final decision and what evidence supports it.

Narrow the scope when the audit shows that the current structure works and the problem is limited to selected content, visual elements, performance improvements, or a controlled platform migration. A smaller release can reduce risk while creating evidence for later work.

Pause when the business lacks domain or system access, nobody owns content decisions, critical integrations are undefined, important URLs have no destination, or launch approval has no clear authority. Pausing before development is usually less expensive than repairing an undocumented migration afterward.

Frequently asked questions

What is website redesign planning?

Website redesign planning is the process of defining the business problem, user tasks, scope, content, structure, technical requirements, ownership, testing, and launch responsibilities before rebuilding or substantially changing a website. It helps a business choose an appropriate scope and reduce avoidable content, access, usability, and search-visibility problems.

How do I know whether my website needs a refresh or a full redesign?

Choose a refresh when the structure and user journeys work but selected content, visuals, performance issues, or functions need improvement. Choose a full redesign when navigation, accessibility, information architecture, performance, branding, or core functionality require broader change.

What should be included in a website redesign brief?

Include goals, audiences, user tasks, page inventory, proposed sitemap, content responsibilities, design direction, technical requirements, integrations, search safeguards, accessibility expectations, milestones, approvals, testing, ownership, launch support, maintenance, and exclusions. The brief should also identify who supplies credentials, content, images, data, and final approval.

How can I preserve search visibility during a website redesign?

Inventory important URLs, map changed pages to relevant destinations, implement and test redirects, preserve useful content intent, review titles and headings, check internal links, and monitor indexing and analytics after launch. These actions reduce avoidable losses but do not guarantee ranking improvements.

What should I test before launching a redesigned ecommerce website?

Test product discovery, categories, search, filters, product details, cart, checkout, payments, shipping, taxes, confirmation messages, order notifications, returns information, mobile layouts, error states, analytics, and administrative workflows. Include failed and incomplete transactions, not only a successful desktop order.

Discuss your website redesign requirements

Good website redesign planning starts with evidence from the current site and ends with a documented launch decision. Audit what exists, define the user tasks that matter, select the smallest scope that solves the real problem, and assign responsibility for content, access, testing, and ongoing support.

Big Time IT Solutions Inc provides responsive website design, ecommerce development, website optimisation, prototyping, and quality-assurance-related services for businesses in Surrey and beyond. Request a discussion to confirm whether its stated capabilities and process fit your redesign requirements.