A municipal website is not a marketing site with a government logo on it. It is a service counter. Residents arrive at it to pay a bill, find a collection schedule, book a permit, read a council agenda or report a problem, and they arrive irritated because something in the physical world needs resolving. Every planning decision that treats the site as a brochure produces a redesign that looks better and works worse.
Municipal redesigns also fail in ways corporate redesigns do not. They span budget years and council terms. They carry bilingual and accessibility obligations that are not negotiable. They inherit a decade of documents nobody has authority to delete. Planning for those conditions, rather than discovering them in month four, is most of the work.
Start with the services, not the sitemap
The instinct is to open the current site and redraw its menu. This reproduces the existing problem, because municipal navigation almost always mirrors the organization chart. Residents do not know which department issues a pool permit and should not have to.
Build a service inventory first. One row per thing a resident can actually do, written in the words they would use. For each row, record who owns it internally, how many people do it per year, whether it currently ends in a form, a phone number or a PDF, and whether it is available in both languages. That table is your real requirements document. The sitemap falls out of it, and so does the priority order, because you can now see which twenty services carry most of the volume.
Audit the content before you scope the build
Most municipal sites carry between two and ten times the content anyone believes they have, and the surprise is always in the document library. Run a crawl and produce three numbers before anything else: total URLs, total documents, and the proportion of both that received a single visit in the past twelve months.
That last number is the one that changes the conversation. It is common to find that a large majority of pages serve almost no traffic, which turns an intimidating migration into a manageable one. But the decision to retire content is a governance decision, not a technical one. Records retention rules, council minutes, by-laws and tender archives frequently must remain available regardless of traffic. Establish who is allowed to say “this goes” before you present a single recommendation.
Inventory the URLs before anyone designs a template
Municipal URLs are cited in printed notices, council resolutions, provincial portals, news coverage and other municipalities’ pages. They are referenced far more widely and far more permanently than a commercial site’s URLs, and they cannot be quietly discarded.
So the URL map is a planning artifact, not a launch-week deliverable. Every old address maps to exactly one new address, in a single redirect hop rather than a chain. Documents get the same treatment as pages. Anything genuinely being retired is a deliberate choice with a name attached to it, not an accident discovered in the server logs three weeks after go-live.
Settle the bilingual question early and honestly
Bilingual delivery is a content capacity question disguised as a technical one. The platform side is straightforward. The hard part is that every page now needs an owner who can write and maintain it in both languages, forever.
Decide up front which of these you are actually committing to: full parity across the site, parity on service pages with news and notices in one language, or translation on request. All three are defensible. What is not defensible is launching with parity you cannot sustain, which is how sites end up with a French section that stopped being updated in 2022 and now misinforms the people who rely on it.
Write accessibility into the requirements, not the QA plan
Accessibility obligations apply to municipalities across Canada, with the specific standard depending on jurisdiction. Whatever the citation, the practical target is WCAG 2.2 Level AA, and the expensive parts are decided long before testing: the colour palette, the choice of third-party embeds, the document strategy, and how much freedom the CMS gives authors to create non-compliant content.
Put the standard in the requirements with a version number. Budget for manual testing rather than an automated scan. And plan what happens to the existing document library, because for most municipalities that library is the largest single accessibility liability on the site.
Plan around the governance calendar
Municipal projects run on council cycles and fiscal years, and a plan that ignores them stalls. Three practical rules:
- Never launch during an election period or a budget cycle. The people whose approval you need are unavailable, and the traffic spike is the worst possible audience for a new site’s teething problems.
- Name a single decision-maker with delegated authority. Committee-approved design is slow design. The committee should approve the direction once, then delegate.
- Separate the platform decision from the content decision. They have different approvers and different timelines, and coupling them means the slower one sets the pace for both.
Measure before you touch anything
You cannot demonstrate that a redesign worked if you never recorded what it replaced. Before the project starts, capture the baseline: search visibility and top entry pages, Core Web Vitals on the templates that matter, call volume to the main municipal line and what those calls are about, completion rates on the forms that already exist, and the time it currently takes a department to publish a routine update.
That last measure is the one councils understand best. A redesign that cuts a three-day publishing turnaround to twenty minutes has produced a result you can name in a report, and it is usually the change staff notice first.
Rebuild in place where you can
The riskiest municipal redesign is the one that builds a parallel site for a year and switches over in a single night. Content goes stale during the build, the cutover concentrates every risk into one evening, and there is no way to roll back a decision you only discover was wrong on the Monday.
Where the existing platform allows it, modernize in place: new templates section by section, content migrated by script rather than retyped, redirects in from the start, and each section verified against the baseline before the next one begins. It is less dramatic and considerably harder to get badly wrong.
If you are scoping a municipal or public sector redesign and want to see how we handle the migration and the evidence trail, our website redesign and modernization page sets out the process in detail.