To plan a municipal website redesign well, treat the site as a service counter. Residents come to pay a tax bill, check a collection schedule, apply for a permit, read a council agenda or report a pothole. Most arrive with a problem to solve, and a little impatient. Plan the site as a brochure and you end up with something that looks better and serves them worse.
Municipal projects also carry risks a company redesign rarely meets. They can run across two budget years and sometimes a council election. Bilingual and accessibility obligations come attached, and so does a decade of documents nobody feels allowed to delete. Planning for those conditions from the start, instead of meeting them in month four, is most of the job.
Start from what residents come to do
The usual first move is to open the current site and redraw its menu. That copies the old problem, because municipal menus tend to follow the org chart. A resident looking for a pool permit has no idea which department issues it, and shouldn’t need to.
Build a service inventory instead. Give each thing a resident can do its own row, in the words they would type into a search box. Then fill in the columns: the internal owner, the yearly volume, how the task ends today (a form, a phone number or a PDF), and whether it exists in both languages. That table becomes your real requirements document. The sitemap comes out of it. So does the priority order, because you can see the short list of services that carry most of the traffic.
Audit the content before you scope the build
Municipal sites often hold much more content than staff expect, and the surprise is usually in the document library. Crawl the site and get three numbers first: total URLs, total documents, and the share of each that had no visits in the past twelve months.
That third number changes the conversation. A large share of pages often turns out to get almost no traffic, and a migration that looked huge becomes manageable. Deciding what to retire is still a governance call. Retention rules can require that council minutes, by-laws and tender archives stay online however few people read them. Find out who has the authority to say “this goes” before you make a single recommendation.
Map every URL before anyone designs a template
A city’s web addresses show up in printed notices, council resolutions, provincial portals, news stories and the sites of neighbouring municipalities. They are cited more widely, and for longer, than the URLs of a commercial site. You can’t quietly let them break.
Build the URL map during planning, long before launch week. Each old address points to exactly one new address, in a single redirect with no chains. Documents get the same treatment as pages; our guide to migrating thousands of documents explains how. When a page is retired, someone decides it on purpose and their name goes next to the decision. The alternative is finding the broken links in the server logs three weeks after go-live.
Settle the bilingual question early
Bilingual delivery looks like a technical question, and the technical part is the easy one. The hard part is staffing. Every page needs someone who can write it and keep it current in both languages, for as long as the site runs.
So decide up front what you are committing to. You can aim for full parity across the site, parity on service pages with news and notices in one language, or translation on request. Any of the three can be defended. Promising full parity without the people to sustain it is how a French section ends up frozen for years. By then it gives residents wrong information.
Put accessibility in the requirements
Municipalities across Canada have accessibility obligations, with a standard that depends on the province. Our guide to Canadian public-sector accessibility requirements sets out what each one asks for. Whatever your legislation cites, the practical target is WCAG 2.2 Level AA. The expensive decisions come well before testing. They sit in the colour palette, the third-party embeds and the plan for documents, and in how much freedom the CMS gives authors to publish content that fails.
Write the standard into the requirements with its version number. Budget for manual testing, since an automated scan catches only part of the problems. And decide early what happens to the existing document library, which for many municipalities is the largest accessibility liability on the site.
Plan around the governance calendar
Municipal projects move at the pace of council meetings and fiscal years. A plan that ignores them stalls. Three rules help:
- Keep the launch away from an election period or the budget cycle. The people who must approve things are busy elsewhere, and a new site’s teething problems will meet its biggest crowds.
- Name one decision-maker with delegated authority. A design approved by committee moves slowly. Let the committee approve the direction once, then hand decisions to that person.
- Decide the platform and the content separately. Each has its own approvers and its own timeline. Tie them together and the slower one sets the pace for both.
Measure before you touch anything
If you never recorded how the old site performed, you can’t show that the new one does better. Capture a baseline before the project starts:
- Search visibility and the top entry pages.
- Core Web Vitals on the templates that matter.
- Call volume on the main city line, and what people call about.
- Completion rates on the forms you already have.
- How long a department takes to publish a routine update.
Councils tend to grasp that last one fastest. If publishing a notice takes three days today and twenty minutes after the redesign, you have a result you can put in a report. Staff usually notice it first, too.
Rebuild in place where you can
The riskiest approach is to build a parallel site for a year and switch over in one night. Content goes stale while the new site is built. Every risk lands on the same evening. And when a decision turns out wrong on Monday morning, there is no easy way back.
Where the current platform allows it, modernize in place. Replace templates one section at a time, migrate content by script instead of retyping it, and set up redirects from day one. Check each section against the baseline before starting the next. It is slower to show off and much harder to get badly wrong.
Scoping a municipal or public-sector redesign? Our website redesign and modernization page shows how we handle the migration and keep the evidence trail.