Website redesign planning guide for established businesses: what to settle before anyone opens a design file

Why established sites need a different plan

A startup building its first website has one job: get something credible live. An organization that has been in business for fifteen years has a harder one. Its current site, however tired, is doing work. It ranks for searches that bring in clients. It holds content that staff send to customers. It feeds forms into a CRM someone depends on. Some of its pages are linked from partner sites, government directories and old press coverage.

A redesign that ignores that inheritance can launch beautifully and still cost the business inquiries for months. The planning is where you prevent that, and it is also where you decide whether a full redesign is even the right call. If you are not yet sure, start with our framework for choosing between a redesign and incremental improvement.

This guide is the operational companion to Your website is a decision system, not a design project. That piece makes the argument for treating the site as a tool for buyer decisions. This one is the checklist for actually running the project.

Start with objectives you can measure

“Modernize the website” is not an objective. It is a mood. Before any vendor conversation, write three to five objectives, each with a way to tell whether it happened.

• Bad: look more professional. Better: qualified inquiries from the website increase, measured as form submissions that sales accepts as a real opportunity.
• Bad: improve the user experience. Better: existing clients can find the document portal and the billing contact without phoning reception.
• Bad: better SEO. Better: organic traffic to service pages holds through the launch and then grows against the pre-launch baseline.
• Bad: easier to update. Better: marketing can publish a case study without a developer, in an afternoon.

Two rules make objectives useful. First, each one needs a baseline captured before launch, otherwise you will be arguing about memories six months later. Second, they need an owner on your side, not just on the vendor’s. If nobody inside the business is accountable for qualified inquiries, nobody will notice when the new site stops producing them.

Run discovery on the site you already have

Discovery is the part of a project people are tempted to shorten, because it does not produce anything that looks like a website. It is also the part that decides whether the expensive work gets built once or twice.

For an established business, discovery should answer four questions:

1. Who actually visits, and what are they trying to do? Look at the top landing pages, the top internal searches if the site has search, and the pages that precede a form submission. Then talk to the people who answer the phone. Front-line staff know exactly which questions the website fails to answer.
2. Where does the current site work? Some pages convert, rank or get shared far more than others. Those pages are the ones you redesign most carefully, not the ones you throw out first.
3. What does the site connect to? Forms, CRM, booking tools, payment, email platforms, client portals, job boards, chat. Every integration is scope, and an undiscovered one becomes a change order.
4. What are buyers comparing you to? Look at the two or three competitors a prospect is most likely to have open in another tab. You are not copying them. You are making sure your site answers the questions theirs leaves hanging.

The output is a short written brief: audiences, their top tasks, the pages that matter, the integrations, and the constraints. If a vendor proposes design concepts before that brief exists, they are guessing.

Inventory every page and decide its fate

The content inventory is the single most skipped step in a redesign, and the one that causes the most post-launch damage. It is unglamorous: a spreadsheet with every URL on the current site. Crawl the site, then add anything the crawl missed, such as PDFs, landing pages from old campaigns and pages only reachable from email.

For each URL, record its traffic, whether it brings in organic search visits, whether other sites link to it, who owns it internally, and when it was last updated. Then give it one of four fates:

• Keep: accurate and useful, moves across with light editing.
• Rewrite: the topic matters but the content is weak or outdated.
• Merge: several thin pages that should become one strong one.
• Retire: no longer needed, and redirected to the closest relevant page.

Every rewrite needs a named writer and a due date that lands well before the build finishes. The most common reason redesigns launch late is not development. It is content that nobody was assigned to write. If your team is producing the copy, read how to write website copy that sells before the first draft, not after.

An illustrative example: a 40-person accounting firm with three offices finds it has several hundred URLs, most of them old news posts and near-duplicate service pages, one per office. The inventory shows that a handful of pages bring in most of the organic visits. The plan becomes obvious: protect those few, consolidate the office duplicates into one service page with location sections, retire the news archive with redirects, and spend the writing effort where buyers actually land.

Set the accessibility standard up front

Accessibility is cheapest when it is a design requirement and most expensive when it is a post-launch audit finding. Decide the standard at the planning stage, name it in the contract, and ask how it will be verified.

The Web Content Accessibility Guidelines (WCAG) are the reference most Canadian organizations and procurement documents point to. Pick the version and conformance level that applies to you (your obligations depend on your sector and where you operate, which is covered in website accessibility and Canadian law), then build it into every phase: colour contrast in the design system, keyboard navigation and form labels in development, alt text and document formats in the content plan.

The content plan matters more than people expect. A compliant template can be undone by the first scanned PDF someone uploads. Training editors on accessible publishing is part of the project, not an optional extra.

Plan the SEO migration before design starts

For an established site, search visibility is an asset you already own. A redesign is one of the few events that can lose it quickly. The protection is a migration plan built from the content inventory: every old URL mapped to its new destination, with permanent redirects in place on launch day.

The details (redirect mapping, canonical tags, structured data, keeping staging out of the index, sitemaps, monitoring) deserve their own list, and they have one: the website migration SEO checklist. At the planning stage, the decisions that matter are these. Will URLs change? Will the domain change? Will the platform change? Each yes adds risk, and each should be a deliberate choice rather than a side effect of a new CMS’s default URL structure.

Also decide who owns the migration. If the answer is “the developer will handle redirects,” ask to see the map before launch. A redirect map that exists only in someone’s head is not a plan.

Define what analytics will measure

Tracking is often bolted on in the last week, which means the first month of data from the new site is incomplete and the baseline comparison is unreliable. Plan it alongside the objectives instead.

Start from the objectives you wrote in step one and list the events that prove each one: form submissions by form type, calls from the site, bookings, document downloads, portal logins. Agree on naming before development, so the reports make sense to someone who did not build them. Confirm that the CRM can tell which inquiries came from the website, because that is the link between the website and revenue. The measurement plan guide covers how to structure this properly.

Capture the baseline from the old site before it is switched off. For a seasonal business this means comparing against the same period last year, not the previous month. When Crabbe Mountain’s site was redesigned, the measurement foundation was built as part of the project, which is why the resort can say with confidence that it saw 130K sessions in one season, two-thirds of it organic. You can read how that came together in the Crabbe Mountain case study.

Agree launch governance and ownership

Launch is not the finish line. It is the moment the site becomes your team’s responsibility, and the plan should say what that means.

Before launch

• A named decision-maker who can approve the go-live, and a short list of people who review. Committees of twelve produce launches that slip by a quarter.
• A launch checklist covering redirects, forms tested end to end, analytics firing, accessibility checks, and the old site archived.
• A launch date that avoids your busiest season and the week before a holiday.

After launch

• A stabilization period with the vendor still engaged, to fix what real visitors find.
• Section owners: which department owns which pages, and how often they review them.
• Editor training and written documentation, so the site survives staff turnover.
• A review at roughly the three-month mark against the baselines, with a short list of what to change next.
• Clear ownership of the domain, hosting account, code and analytics properties, in your organization’s name.

This is the part of website design and development we spend the most time on with established clients, because it decides whether the site is still working in year three. A plan with all seven parts written down also gives you something useful when you go to market: vendors quoting against the same document, which is the only way their numbers are comparable. If budget is the next question, what drives the cost of a business website in Canada walks through it.