Should a Gatineau business repair its website or redesign it?
Test the customer tasks, content and site foundations first. Repair a contained problem; redesign when the structure itself keeps getting in the way.
An owner in Gatineau opens their site on a phone and finds an outdated service, a contact button that is hard to tap and a page that takes too long to appear. A designer proposes a new site. Another offers to fix the current one. How do you decide without paying for a rebuild that solves the wrong problem?
Start with the tasks customers need to complete, then find the smallest change that makes those tasks work reliably. Fix a contained issue when the site’s pages and editing tools are sound. Redesign when the navigation, content structure, language paths or underlying system make repeated repairs slow and fragile. An old-looking design, by itself, does not make a rebuild necessary.
Inspect the site before asking for a quote
List the pages that matter to a real visitor: the home page, core service pages, hours or location, and contact or booking. For a Gatineau business, check the French and English paths that customers actually use. Ask a person unfamiliar with the business to find a service, confirm the area served and contact you on their phone. Watch where they hesitate; do not lead them to the answer.
Check the same journey yourself with a keyboard and at a narrow screen width. Can you read the text, use the menu, submit the form and understand its confirmation? If a page advertises a service you no longer offer, the issue is editorial before it is visual. If the contact form sends messages to an unattended inbox, a new colour scheme will not repair the handoff.
Gather evidence from the site’s own systems where you have access: which pages people visit, what Search Console reports about search and indexing, whether forms actually deliver, and what staff hear from customers. Review these as clues, not as proof that a redesign will increase inquiries. Low traffic can reflect limited demand, poor distribution, measurement gaps or a page that does not answer the searcher’s question.
Give page speed a diagnostic role
Page weight is one useful thing to inspect because images, scripts and fonts can make a working page slow on a phone. The HTTP Archive Web Almanac’s page-weight distribution reports 2,164 KB as the median mobile page weight in its July 2025 crawl. Its methodology describes a broad international set of websites selected from Chrome UX Report activity and tested in a datacentre with an empty cache. This is not a Canadian or Gatineau figure, a target for your site, or evidence that a heavier page needs a redesign. A single page’s bytes also do not describe every visitor’s experience.
Run the important URLs through PageSpeed Insights on mobile and desktop. It separates measured experience from eligible real Chrome users, where available, from a simulated lab test. If there is too little field data, say so; a lab score is still useful for finding likely causes. Inspect what loads before the main content and what makes the page jump or respond slowly. The Search Console Core Web Vitals report groups similar pages using real-user data, but may omit pages without enough data.
If a large hero image or an unnecessary embed is the main problem, compressing or replacing it may be a small repair. If every page loads a tangle of old plugins and scripts that nobody can maintain, the issue may be structural. Neither tool can tell you what to buy. Google’s page-experience guidance also says a good score does not guarantee top search rankings.
When a repair is enough
Keep the current site when the owner can update it, the page hierarchy still matches the services, and customer journeys mostly work. A focused scope might include:
- Correcting service descriptions, hours, addresses and calls to action.
- Fixing a broken form, booking link or mobile menu and testing the message after submission.
- Replacing oversized images or removing an unused embed.
- Improving headings, labels, contrast and keyboard access on the pages customers use.
- Updating supported software, access controls and backups before a failure becomes urgent.
Set a short acceptance test for each repair. For a form, that means sending a test inquiry, receiving it in the intended inbox and checking the confirmation a visitor sees. For a mobile menu, it means opening every important destination on a phone. A repair has value when someone can verify the task now works, even if the site still looks familiar.
It is reasonable to leave a functional site alone if its content is accurate and customers can complete the key tasks. Ask what specific problem a proposed redesign would solve before treating age as a defect.
When a redesign earns its scope
A redesign becomes more plausible when the business has changed enough that the current page structure misleads visitors, or when changing the site safely has become unusually difficult. Examples include a service firm whose offerings and sectors no longer fit its navigation, a restaurant whose menu and reservation paths are scattered across incompatible tools, or a team that cannot maintain corresponding French and English pages.
The right scope may still be smaller than replacing everything. Rework the most important page templates or the navigation while keeping the domain, useful content and stable URLs. A full rebuild is more defensible when the current platform cannot support required tasks, maintenance is impractical, or accessibility and content problems recur across the whole site. Get a technical explanation of the constraint, not merely a preference for a newer tool.
| What you found | Likely next step | Ask before approving work |
|---|---|---|
| One broken path on an otherwise usable site | Repair and retest that path | What caused it, and who will monitor it? |
| Accurate content but confusing navigation | Test a revised structure or a small set of pages | Can useful URLs and content stay? |
| Repeated failures across templates and editing tools | Scope a rebuild | What must migrate, and what can be retired? |
| No verified customer problem | Keep the site and maintain it | What evidence would change the decision? |
The table is a decision aid, not a price or outcome prediction. Compare proposals against the same tasks and maintenance needs, including who will edit pages after launch.
Protect the parts that already work
Before changing the platform or URLs, inventory pages, forms, downloads, search traffic, email addresses and integrations. Keep a copy of the content and assets you own. If pages move, map each old URL to a relevant new one and test its redirect. Google’s site-move guidance recommends preparing and testing the new site, mapping old URLs and monitoring after launch; it warns that search visibility can fluctuate during a significant move. Do not send every old service page to the new home page.
Keep the language experience in the plan. A Gatineau visitor following a French service link should reach the corresponding French content, not an English page or a dead end. Have a fluent reviewer inspect customer-facing French copy and the contact path. A visual mockup alone cannot confirm that either language works end to end.
Ask for a proposal that names the pages and tasks to be fixed, the people who will supply and approve content, the test for each important path, and the handover arrangements. Confirm domain and account ownership, backup access, software subscriptions and what happens to the current site during the change. If a proposal cannot explain the migration and ongoing editing, the apparent simplicity of a new design may hide later work.
Decide with a small, testable brief
Write down the customer task, the current failure, evidence for it and what success would look like. Invite a repair estimate and a redesign estimate only when both are plausible. Ask each provider to identify what can be reused and what cannot, and to explain the tradeoff in maintenance and migration effort. You can prepare a short website project brief before speaking with anyone.
An owner can fix content and test the main journeys without commissioning a project. Professional help is sensible when the failure spans several page templates, languages, forms or systems, or when the team lacks a reliable way to deploy and verify changes. If you are weighing repairs against a new site in Gatineau, discuss your website with Red Comet and bring the pages and tasks that are causing trouble.
Sources
- HTTP Archive, 2025 Web Almanac: Page Weight, figure on page-weight distribution; published January 15, 2026, updated January 16, 2026. Study methodology.
- Google, About PageSpeed Insights and Core Web Vitals report.
- Google Search Central, Understanding page experience and Site moves and migrations.
