WordPress is very commonly used by parish and town councils to run their website, and it is easy to see why. This guide is for clerks and councillors who are using it for the council, or are weighing it up, and want an honest sense of what it does well and where the work and the risks really are.
England only. General guidance, not legal advice.
What WordPress is good at
WordPress powers a very large share of the web, and for a council most of its attractions are real. It is free and open-source, so there is no licence to buy. It has a vast choice of themes and plugins, so a site can be made to look the part and gain features - a contact form, an events calendar, a cookie banner - without anyone writing code. Hosting is cheap and widely available, local web designers know it well, and once a site exists a clerk can usually be shown enough to add a page or a notice unaided. For publishing a steady stream of ordinary content, it is a sensible choice.
What it is not built for
The difficulty is not the software; it is that a council does not publish ordinary web content. It publishes a structured, dated, legally-significant record - councillors, committees, meetings, agendas and minutes, all of which change over time and have to stay right for years. WordPress, out of the box, has no idea what any of those things are. It gives you pages, posts and a media library, and leaves the modelling, the discipline and the archive to you. Everything below is about covering that gap.
What a council website actually has to carry
The duty to publish is covered in full in what a parish council must publish, and it is worth reading alongside this guide, because it decides how much of the following is a legal requirement and how much is good practice.
In short: a council with turnover of £25,000 or less is bound by the Transparency Code for Smaller Authorities, which requires - among other things - that agendas and meeting papers go up not later than three clear days before the meeting, and that draft minutes of all formal meetings, including committees and sub-committees, go up not later than one month after. It must all be on a website that is free to access. A council above £25,000 is, perhaps surprisingly, not bound by that Code for its meeting papers at all - though almost every council publishes them anyway, and residents expect it.
Either way, a working council website is carrying at least:
- a list of councillors, usually with ward, committee memberships and some means of contact;
- the committees and their membership;
- a forward list of meetings, with dates and venues;
- for each meeting, an agenda before it and minutes after it;
- the statutory transparency items - accounts, the annual governance statement, asset and land registers, the list of member responsibilities;
- and, in most cases, policies, the register of members' interests, and a scattering of notices.
None of that is hard to type into WordPress once. The problem is that almost all of it changes, and keeping it right over years is where councils come unstuck.
Councillors and committees: the pages that quietly go stale
WordPress has no concept of a councillor. So a council builds a "Your councillors" page by hand - a photograph, a name, a ward, a line of committee memberships, perhaps an email address - and it looks fine on the day it is published.
Then someone resigns, there is a by-election, a committee is reshaped at the annual meeting, a councillor changes their contact preference. Each of those is a manual edit to a page that nobody owns, and the page drifts out of date without anyone deciding that it should. A resident reading it has no way to tell whether they are looking at this year's council or last year's.
A few things help:
- Decide who owns the page and when it is reviewed - at the very least after the annual meeting, after any co-option or by-election, and after any committee change.
- Be deliberate about contact details and photographs. Publishing a councillor's personal information engages data protection. A councillor's home address in particular should not go up without good reason. What you may and may not publish is covered in parish councils and personal data.
- Keep the register of members' interests current. A parish council's register must be published on the principal authority's website, and on the council's own website where it has one.1
A committees page has the same failure mode on a slower clock: it is right when written and wrong after the next annual meeting.
Agendas and minutes: the repetitive bit, and the risky bit
This is where most of a clerk's website time goes, and where the one mistake that really matters lives.
Each meeting cycle, the same sequence repeats. Produce the agenda; upload it; link it from the meeting's page; hold the meeting; write the minutes; wait for approval; upload the minutes; link them. Do that for full council and every committee, month after month, and build a tidy archive that a resident - or an auditor - can navigate back through the years. It is not difficult work. It is repetitive work that has to be done correctly every single time, and the cost of a slip is higher than for an ordinary web page.
The wrong-version problem
The single biggest risk in running meeting papers by hand is publishing the wrong version of a document. It takes several forms, and WordPress makes some of them easier than you would like:
-
The draft that should have been the approved version. Minutes are a draft until the next meeting approves them. The Transparency Code expects the draft to be published within a month, so publishing a draft is correct - but it must be clearly labelled as a draft, and then replaced with the approved version once the meeting has agreed it, with the label changed to say so. The error is not publishing a draft; it is leaving an unlabelled draft up as though it were the record, or never going back to swap it.
-
The corrected file that does not actually replace the old one. This one catches people out. When you upload a file to the WordPress media library, it does not overwrite the previous one - it is stored as a new attachment, and if it has the same name WordPress quietly adds a
-1to it. The old file stays on the server at its original web address and can still be found, linked to and indexed by search engines, even after you have pointed the page at the new one. Deleting a document properly means removing the old attachment, not just unlinking it. -
An amended agenda after it has been issued. Changing a published agenda is not simply a re-upload. Adding business is a notice question first - fresh business generally needs fresh notice, rather than being bolted onto an agenda already out - and the amended version has to reach councillors, not just the website. How notice works is covered in three clear days' notice.
-
A confidential or exempt paper uploaded by mistake. If a document contains the detail of an item taken in private, or personal information that should have been redacted, putting it on the website is a disclosure that cannot be taken back once it has been seen, cached or indexed. What may be withheld, and how to handle it, is in exempt business and confidential items and who can see parish council minutes.
Two habits remove most of this risk:
- Put the status in the name. A file called
Minutes-2026-05-full-council-DRAFT.pdf, replaced in due course byMinutes-2026-05-full-council-APPROVED.pdf, is far harder to muddle than two files both calledminutes.pdf. The same goes for the visible link text on the page. - Publish a PDF, not the working document. A
.docxcarries tracked changes, comments and author metadata that you almost certainly do not mean to publish. Finalise in your word processor, export to PDF, and upload the PDF.
Accessibility
Public sector websites, parish and town councils included, must meet the 2018 accessibility regulations. The most common failure by far is uploading agendas and minutes as scanned images - a photograph of a document, with no real text - which a screen reader cannot read at all. A PDF produced by exporting from your word processor is usually fine; a scan of a printout usually is not. This has its own guide: accessible agendas and minutes.
Keeping it all in sync
Step back and the underlying problem is duplication. The council already holds its meetings, committees and councillors somewhere - in the clerk's files, in a back-office system, in their head - and the website is a second copy, maintained by hand. Every change has to be made twice, and the website is the copy most likely to be forgotten, because it is the one furthest from the work.
That is also why the "who maintains the site" question matters. If the website is looked after by an external contractor, every update is a request and a wait; if it is the clerk, it is one more recurring task competing with everything else. Either way, the gap between "the council changed" and "the website says so" is where things go wrong.
Doing it well in WordPress
If the council is staying with a hand-maintained WordPress site, a few disciplines make it far more reliable:
- Name the owner and the review points. The councillor and committee pages get reviewed after the annual meeting and after any change in membership; the archive gets checked at year end.
- Standardise file names with the meeting, the body and the status, as above.
- Export to PDF, never upload the working document, and keep scans out of it.
- Delete superseded files, do not just unlink them.
- Keep a simple, dated archive structure so that older meetings remain findable rather than falling off the bottom of a list.
- Treat anything confidential as off the website entirely unless and until it has been properly redacted.
Running the site itself
Separately from what goes on the pages, a WordPress site is a piece of infrastructure the council has to look after, and a few points are worth settling early:
- Own the domain, the hosting and the logins. The domain name, the hosting account and the administrator login should be registered to the council - an official email address, not a clerk's or a contractor's personal account. The commonest way a council loses control of its website is a clerk leaving, or a web volunteer moving on, with the keys. Write down where the domain is registered and when it renews.
- Keep WordPress, the theme and plugins updated. Out-of-date plugins are the usual route by which sites get defaced or hijacked. Updates are not optional housekeeping; they are the security.
- Take backups, and know how one is restored - ideally automatically, through the host or a plugin.
- Do not make everyone an administrator. Give each person the lowest role that lets them do their job; an administrator account can change or break the whole site.
- Publish the required accessibility statement and a privacy notice. A public sector site must carry an accessibility statement (see accessible agendas and minutes), and a privacy notice covering the personal data the site handles (see parish councils and personal data).
How CouncilPapers handles this
CouncilPapers takes a different route: instead of maintaining the website as a second copy, it treats the work you already do as the single source of truth, and publishes from it.
The CouncilPapers WordPress plugin puts your meetings, agendas, minutes, committees and councillors onto your council's own WordPress site, drawn live from CouncilPapers but rendered by your own theme so they match the rest of your site. You do not publish anything twice - you keep working in CouncilPapers as usual and the website follows. It shows exactly the same public information as your public portal, and no more:
- draft agendas never appear;
- confidential items are shown only as a title, with a note in place of their content;
- minutes appear only once they are published;
- councillor details follow your publication settings.
That design takes the weight off the wrong-version problem: there is no media library of loose files to pick the wrong one from, and the website only ever shows what CouncilPapers has already decided is public - a draft agenda is not public until it is issued, and minutes are not shown until they are published - rather than whatever was last uploaded by hand. You still decide what is public inside CouncilPapers; the website simply follows that decision instead of being a second place to get it wrong. Instant website updates go a step further, telling the site to refresh the moment you change a meeting, agenda, committee or councillor.
If you would like to see it against your own council's site, take a look at CouncilPapers.
Related: what a parish council must publish, accessible agendas and minutes, and who can see parish council minutes.
Localism Act 2011, s.29(7): "A parish council must, if it has a website, secure that its register is published on its website." The register itself is established and maintained by the principal authority's monitoring officer under s.29(1); sensitive interests may be withheld under s.32. ↩
Last reviewed 6 October 2026. General guidance for councils in England, not legal advice.
Agenda and minutes software
CouncilPapers does the work these guides describe — agendas from a committee template, numbering handled, minutes published when approved.
Start a free trialNeed more help? Contact us
Built by a councillor, for council clerks
Save hours of paperwork per meeting
Write agendas and minutes once and publish them straight to your council's website. Councillors get them in the Councillor App. No re-typing, no uploading files one by one. See the features
Records you can stand behind
Agendas and minutes are version-tracked and searchable, with public and confidential versions kept apart. That helps you stay audit-ready, though the council remains responsible for its own compliance. Overview for clerks
Open, accessible council papers
Published papers are designed to meet WCAG 2.2 AA, the standard the Public Sector Bodies Accessibility Regulations 2018 require. Your council's data is stored in the UK (AWS London). Accessibility statement
Councillors get agendas, papers and past minutes in one secure app, not a pile of email attachments. Overview for councillors
Read our story