The Ottawa Website Redesign Checklist: What to Fix Before You Rebuild

“The website is outdated” is a real feeling, but it is not yet a project brief. Ask what makes it feel outdated. Is the offer unclear? Are service pages missing? Does the site fail on mobile? Are updates too hard? Are visitors asking questions the website should answer? Has the organization changed since the current structure was created? These answers may point to a content rewrite, a component refresh, a platform change, or a complete rebuild. Naming the problem keeps a redesign from becoming an expensive moodboard.

Collect evidence from several places. Review analytics and search queries, but also talk to the staff who answer calls, qualify leads, publish updates, and hear complaints. Watch someone new try to find a service or contact option. List pages that still receive visits, links, or conversions. Note outdated claims, duplicate content, broken paths, and components that the team avoids using. An audit does not have to be elaborate. It has to make the starting point more accurate than a screenshot of the homepage.

Before changing the structure, make a list of public URLs and what each one currently does. Record important traffic, backlinks, rankings, conversions, titles, and content quality where that information is available. Mark pages to keep, combine, rewrite, redirect, or retire. Pay attention to service pages, location pages, resources, campaign landing pages, and old URLs that may still have value. Deleting a page because it looks old can remove a useful entry point for someone who is ready to act.

The new architecture should be simpler to use, not merely different. Group pages around audience questions and business priorities. Create clear relationships between services, proof, FAQs, articles, and contact paths. If a URL must change, decide the redirect before launch and make sure internal links, canonical tags, sitemap entries, and analytics references follow the new structure. Search preservation is not a reason to keep confusing content forever; it is a reason to change it with evidence and care.

Many redesigns fail because the visual system changes while the old content remains. A business that has added services, changed its audience, or developed a stronger point of view needs more than new spacing and colours. Revisit the main promise, the language customers use, the proof that reduces hesitation, and the questions that repeat in sales conversations. Write a page outline before styling the page. It is much easier to find a content gap in an outline than in a polished mockup.

Decide what belongs in the first release. A redesign does not need to solve every editorial ambition on day one. Prioritize pages that support revenue, access, trust, and search value. Define who supplies missing content, images, translations, approvals, and legal review. Include enough real copy during design to test headings, cards, forms, comparisons, and long paragraphs. A layout that only works with placeholder text is a concept, not a dependable component.

A redesigned desktop page can look better and still create a worse experience for someone on a phone. Test the order of information, navigation, form completion, buttons, tables, accordions, image crops, and sticky elements at realistic widths. Decide which content must appear first when space is limited. Make calls and directions easy to use for local visitors. Check the awkward middle sizes where a layout often exposes a hidden dependency on a wide screen.

Accessibility should shape the new component system. Check heading order, landmark structure, colour contrast, focus visibility, keyboard order, labels, error messages, touch targets, motion preferences, zoom, and readable type. Use semantic controls instead of making clickable containers behave like buttons. An automated scan can identify useful issues, but it cannot replace human testing. A redesign is a good moment to fix patterns once and repeat the fix consistently instead of patching individual pages.

A new visual direction does not automatically require a new platform. First ask whether the current system can support the content model, editing workflow, integrations, performance, security, and access requirements you have identified. A familiar CMS may be the safest option if the team knows how to maintain it. A hosted platform may remove infrastructure work. Custom development may be justified when the experience or data model truly needs more control. The right decision is the one the organization can sustain.

If a migration is needed, treat it as a project stream rather than a footnote. Plan content exports, redirects, media, users, permissions, forms, analytics, third-party scripts, backups, DNS, certificates, and rollback options. Confirm who owns every account. Test the new publishing workflow with the people who will use it after launch. A platform change can create a cleaner future, but only if the transition protects the information and processes the business relies on today.

A redesign checklist should include more than proofreading. Review every important path on real devices. Test forms, notification emails, phone links, booking flows, analytics events, redirects, 404 pages, metadata, canonical URLs, structured data, sitemap, robots rules, images, permissions, backups, and staging protection. Confirm that temporary copy and development accounts are gone. Check that the site can be found from the public domain and that no old environment is being treated as canonical.

Give one person authority to coordinate the launch and one person responsibility for watching the first weeks. Review search coverage, crawl errors, form submissions, broken links, performance, accessibility issues, and visitor questions. Do not make ten changes at once if something looks unexpected; identify the pattern first. A calm launch has a documented plan, a known rollback path, clear ownership, and enough time for the team to observe what real visitors do.

The first month after launch should answer whether the new structure is helping. Which pages are easier to find? Which forms are completed? Which questions still arrive by phone? Which parts of the CMS are confusing? Which content is becoming stale? Use those observations to improve the system. The goal is not to return to constant redesign mode. It is to create a manageable rhythm of small, evidence-based changes.

Write down the decisions that should survive staff changes: who owns access, how content is reviewed, what the design system allows, which metrics matter, how redirects are handled, and when technical maintenance happens. A successful Ottawa redesign leaves the organization with more clarity and control than it had before. It should make the next improvement easier, not make the business dependent on remembering why a particular page was built five years ago.

The first step does not have to be a full request for proposal. Start with the evidence you already have: the pages that matter, the questions customers ask, the updates your team avoids, the places people get lost, and the changes in your business since the last launch. Put that material in front of the people who make decisions. Name the highest-value problem and the risk of doing nothing. This gives an agency or internal team something far more useful to work with than a request for “a modern website.”

Then choose a sequence that protects the important parts first. Keep strong content where it belongs, repair the paths that are blocking action, and plan migration work before a visual change makes it harder to see. A redesign can feel like a large leap, but it is usually a chain of manageable decisions. With an accurate audit, clear content ownership, and a careful launch plan, an Ottawa business can improve its website without losing the value it has already earned.

Share the brief early with sales, service, operations, and communications teams. They each see a different part of the customer journey, and their observations can stop a redesign from becoming too focused on the homepage. The stronger the shared picture of the current problem, the more confidently the project can prioritize the work that will make a difference.