A website can be the first place someone turns when they are worried, in pain, looking for a loved one or trying to understand a referral. NHS WordPress compliance is therefore not a technical badge to add at the end of a build. It is the practical work of making information safe, accessible, accurate and dependable for the people who need it.
For NHS organisations, healthcare providers and partners delivering public services, the stakes are higher than a missed marketing opportunity. An inaccessible form may prevent someone from requesting support. Out-of-date service information can send people to the wrong place. A poorly managed plugin can create a security risk that small teams are then left to resolve under pressure.
WordPress can be a sound platform for NHS-facing sites. But the platform is not compliant by itself. Compliance depends on the decisions around design, content, development, hosting, governance and day-to-day maintenance.
NHS WordPress compliance starts with the user
The most useful question is not, “Does this site meet a checklist?” It is, “Can a person find, understand and act on this information when they need to?” That question should shape every decision.
A clear service page, for example, needs more than an accurate description of a programme. It should explain who the service is for, what happens next, how to get help, any eligibility criteria and what to do if the situation is urgent. It needs to work just as well for a person using a screen reader, someone reading on a phone with limited data, or a carer trying to find an answer late at night.
The NHS design principles and patterns provide a valuable benchmark for creating familiar, plain-English journeys. Not every organisation must reproduce every element of the NHS digital estate, and brand requirements vary by organisation and service. However, the underlying approach is broadly useful: start with user needs, make content easy to scan, test assumptions and avoid making people work harder than necessary.
Accessibility is a continuing responsibility
For public sector bodies, the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations require websites and apps to meet the Web Content Accessibility Guidelines, normally WCAG 2.2 at AA level, unless a valid exemption applies. Many organisations working alongside the NHS will also be expected, contractually and ethically, to meet the same standard.
Accessibility is not solved by choosing a theme labelled ‘accessible’. A theme can provide a helpful foundation, but custom page layouts, uploaded documents, embedded tools and editorial choices can all introduce barriers.
A compliant WordPress build should support keyboard navigation, visible focus states, meaningful heading structures, appropriate colour contrast, descriptive form labels and useful error messages. Images need suitable alternative text where they convey meaning. Video needs captions, and content should not rely on colour, movement or a PDF alone to communicate something essential.
The accessibility statement matters too. It should be specific to the site, state the level of compliance, identify known issues honestly, explain how users can report problems and set out the organisation’s enforcement route where required. Copying a generic statement is not enough. It creates a promise the organisation may not be able to keep.
Security is built into the operating model
WordPress is widely used, well supported and frequently targeted. That is not a reason to avoid it. It is a reason to manage it properly.
Security begins with a lean build. Every plugin, theme and integration adds maintenance responsibility, so the right approach is usually to use fewer, well-supported components rather than installing a plugin for every small request. Bespoke functionality may be justified where a service has complex needs, but it also needs clear documentation, quality assurance and a plan for future support.
Routine updates are essential, but automatic updates are not always the whole answer. On a high-profile or service-critical site, updates should be assessed, tested and deployed through an agreed process. A plugin conflict that breaks an urgent contact route is not a minor inconvenience.
Good WordPress governance also includes strong administrator passwords, multi-factor authentication, role-based access, regular backups, malware monitoring, a web application firewall where appropriate and a tested recovery process. It should be clear who receives security alerts, who can approve changes and what happens if a vulnerability affects the site outside office hours.
Hosting choices need the same care. Organisations should understand where data is hosted, how backups are handled, what support is available during an incident and how the supplier manages access to the environment. UK hosting may be appropriate for contractual or risk reasons, but location alone does not make an arrangement secure or lawful.
Personal data needs a deliberate design
A general information website may process very little personal data. The moment it adds a contact form, newsletter sign-up, appointment request, donation journey, staff portal or analytics tool, that position changes.
The UK GDPR and Data Protection Act 2018 require organisations to be clear about what they collect, why they collect it, how long they keep it and who can access it. The best answer is often to collect less. A ‘tell us about your health issue’ field on a general enquiry form may create unnecessary risk if the team cannot safely handle sensitive information through that route.
Cookie compliance deserves more than a banner added by default. Non-essential cookies and similar tracking technologies generally need valid consent under PECR. Consent should be meaningful, easy to refuse and recorded appropriately. Analytics can help a communications team improve a service, but the configuration, lawful basis and supplier arrangements still need scrutiny.
If a WordPress site connects to clinical systems or supports a pathway where its failure could affect patient safety, further clinical safety and assurance requirements may apply. This is where a proportionate assessment matters. A campaign microsite and a tool that influences care decisions should not be treated as the same level of risk.
Content governance protects people and teams
Many compliance problems begin after launch. A site may be beautifully designed and technically sound, then slowly become harder to use as pages are duplicated, service criteria change and old PDFs remain in search results.
Assign an owner to every important section of the website, especially service information, referral routes, urgent advice and policy content. Set review dates that reflect risk. A page explaining a seasonal awareness campaign can be reviewed less often than a page giving instructions on how to access crisis support.
Editors need a content model that makes the right thing easy to do. That means page templates with sensible headings, pre-defined call-to-action options, prompts for accessible image descriptions and limits on decorative formatting. It also means training. A content management system should give teams independence, not leave them anxious that each update might damage the page.
Plain English is part of compliance in practice. Clinical terminology may be necessary for professional audiences, but public-facing copy should explain it rather than assume knowledge. Be direct about waiting times, access criteria and limitations. People can cope with difficult information better than vague information.
A proportionate route to compliance
There is no single NHS WordPress compliance certificate that covers every organisation, site and service. Requirements depend on whether the organisation is a public body, what data is handled, whether the site supports clinical activity and what contractual standards apply.
That does not mean starting from scratch each time. A practical programme begins with an audit of the existing site: accessibility barriers, outdated content, plugins and integrations, user roles, forms, cookies, hosting arrangements and known operational pain points. From there, teams can prioritise the gaps that carry the greatest risk to users and services.
For a new build, build compliance into discovery rather than saving it for user acceptance testing. Include people with lived experience and disabled users in testing where possible. Ask service teams what information generates the most calls or confusion. Test real tasks, such as finding eligibility criteria or requesting an interpreter, rather than only asking whether stakeholders like the homepage.
Before launch, agree who owns updates, how issues are reported, when accessibility checks happen and what support the organisation can realistically sustain. A smaller, well-maintained website is often safer and more useful than an ambitious one that no one has capacity to manage.
TASK sees this as part of mission-led digital work: creating websites that help teams communicate clearly while protecting the people they serve. The aim is not to turn compliance into a frightening technical exercise. It is to give staff confidence that the information carrying their service into the community is accurate, inclusive and cared for.
When every word can shape whether someone seeks help, good governance is not a constraint on good communication. It is what allows that communication to keep working when it matters most.
