AI Website Builders vs WordPress: An Honest Guide for Charities

Across the charity groups we follow on Facebook and LinkedIn, one question keeps surfacing: “has anyone built their website with AI?” Usually followed by some version of “thinking of trying it before we go to an agency”.

Why charities are asking

Money, first. The Charity Digital Skills Report 2026 found 63% of charities citing squeezed finances as a significant barrier to digital progress. If a tool promises a working website for the price of a monthly subscription, of course you would try it first. One respondent in that report described how AI had “revolutionised our online offering” and saved them a considerable sum on a new service platform for beneficiaries.

The other reason is that people want more say over their own website, and not to spend the whole journey in the passenger seat.

That usually traces back to something specific. Waiting a fortnight for a paragraph to be changed. Being quoted for something that felt like it should take ten minutes. A design process where they were shown three options and quietly steered towards one. A site they cannot touch without emailing someone and hoping.

Some of that frustration is fair, and the industry earned it. AI tools feel like the antidote because they put you in the driving seat. You describe what you want, it appears, you adjust it. No ticket, no invoice, no waiting.

That holds up well for the first few weeks. The harder question is whether it survives month 18, when you want one specific thing changed and nothing else disturbed, and the person who wrote the original prompts has moved on.

What we are actually comparing

“An AI website” covers at least three different things. A prompt-to-site tool like Lovable, v0, Bolt or Replit, generating a React or Next.js application from a description. A developer using AI assistance to work faster. Or a conventional platform with AI features bolted on for drafting copy and writing alt text.

“A WordPress website” is just as broad. A block-based build using the native editor behaves nothing like an Elementor site, a legacy theme, or a headless setup feeding a JavaScript front end. Around 60% of WordPress sites now use a page builder of some kind, according to the HTTP Archive’s 2025 Web Almanac, and that single decision shapes how the site performs and how it ages.

The more useful framing is that AI is a production method and WordPress is an operating model. One is about how the site gets made. The other is about who runs it, edits it, patches it and owns it for the next five years. Most charity website decisions come unstuck by optimising hard for the first and ignoring the second.

The case for building with AI

The 2026 WebAIM Million report tested the home pages of the top one million websites for detectable accessibility failures. Sites built with Next.js averaged 40.9 errors per page, 27.1% below the overall average of 56.1. WordPress sites averaged 52.8, only 5.8% below average. On that dataset the modern JavaScript framework beats the CMS we build on.

Two caveats. WebAIM is clear that you cannot always credit or blame a technology for its error count, and the 23,863 Next.js home pages in that sample were mostly built by well-resourced product teams rather than generated from a prompt on a Tuesday afternoon. Even so, anyone claiming AI-adjacent stacks are inherently less accessible is arguing with the evidence.

Performance points the same way. In the Web Almanac’s 2025 data, 45% of WordPress sites passed Core Web Vitals on mobile, among the lowest of any major CMS, with a median mobile Lighthouse performance score of 41. A statically generated or server-rendered front end starts from a considerably higher ceiling.

There is also a whole class of charity project where prompt-generated builds are the right call. Campaign microsites with an end date. Prototypes to show a funder what a service could look like. Internal tools nobody outside the organisation will open. Landing pages for a single appeal. Where the lifespan is short and known, and one reasonably confident person owns it, most of the maintenance argument below does not apply.

Where AI-generated builds fall down

Generated code usually works. Whether it is safe is a separate question.

Veracode’s 2026 GenAI Code Security Report tested over 100 models on security-sensitive coding tasks. Around 44% of tasks produced code containing a known vulnerability, and the average security pass rate was 56%, barely moved from 55% the year before. Their summary: “syntax is solved, security is not”. Results also varied enormously by vulnerability type. Models passed 83% of SQL injection tests but only 15% of cross-site scripting ones, which is the category that matters most on a public website with forms on it.

The same WebAIM report that flattered Next.js has a harder finding. In 2026, 95.9% of the top one million home pages had detectable WCAG failures, up from 94.8% and reversing six straight years of slow improvement. The average page now carries 1,437 elements, a 22.5% jump in a single year. ARIA attributes rose 27% year on year to over 133 per page, and pages using ARIA averaged 59.1 errors against 42 for pages without it.

WebAIM attributes this to heavier reliance on third-party frameworks and libraries, alongside automated and AI-assisted coding. Their recommendation is “better practices and simpler systems”. Generated output tends towards more markup, more ARIA and more complexity, and accessibility problems multiply with all three.

Iteration is the harder problem, and it does not show up in a demo. These tools are excellent at producing something. They are much worse at changing one specific thing without disturbing five others a year later, particularly when the person making the change did not write the original prompts. Charity websites are long-lived assets looked after by rotating staff and volunteers, which is close to the worst possible fit for a regenerate-rather-than-edit workflow.

If the appeal of AI is more say over your own site, it is worth checking whether the tool gives you that permanently or only at the start.

The case against WordPress

Patchstack’s State of WordPress Security in 2026 logged 11,334 new vulnerabilities across the WordPress ecosystem during 2025, a 42% increase on the year before. More high-severity vulnerabilities appeared in 2025 than in the previous two years combined. The weighted median time from disclosure to first observed exploitation was five hours. When Patchstack pentested hosting providers, standard defences blocked 26% of vulnerability attacks.

Ninety-one per cent of those vulnerabilities were in plugins and 9% in themes. Six were reported in WordPress core, all low priority. That makes it a procurement problem more than a platform one. Every plugin a charity installs is a third-party supplier on an unwritten contract, and 46% of vulnerabilities never received a patch from the vendor before public disclosure.

Combined with the performance data, the fair verdict is that WordPress hands you an enormous amount of rope. Well-built block sites are lean, and the Web Almanac puts WordPress at a median 638 KB of JavaScript on mobile, lighter than Wix or Shopify at over 1.6 MB. Badly built ones are dreadful. The platform does not decide which you end up with.

The divide is the operating model, not the code

The question we would put to a trustee board weighing this up: who changes the text on the donate page at four o’clock on a Friday, and what happens if they have left?

A charity website is a five to eight year asset, owned by an organisation running on three year funding cycles, with staff turnover, volunteers, and a comms team that might be one part-time person on a Wednesday.

The sector’s own data shows the gap. The Charity Digital Skills Report 2026 found 79% of charities using AI in some form, but only 13% using it for technical work like coding or building tools. At the same time, 44% are either poor at using AI tools day to day or not using them at all, and 56% name limited skills and technical expertise as the single biggest barrier to progress. Adoption has run well ahead of the capability to maintain what gets adopted.

The same report captured a values dimension. Alongside real excitement, charities raised concerns about accuracy, environmental impact and losing their own voice. One respondent warned about organisations leaning so heavily on AI that the output turns generic and hard to read, taking the human character of their communications with it.

Four questions worth answering first

1. Accessibility: who is accountable?

UK charities are service providers under the Equality Act 2010, which carries an anticipatory duty to make reasonable adjustments. You cannot wait for a disabled user to complain. Charities delivering public functions or receiving certain public funding may also fall under the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018, and if you sell services to EU consumers the European Accessibility Act has applied since 28 June 2025. WCAG 2.2 Level AA is the practical benchmark across all of them.

Neither platform gives you this for free. With 95.9% of the top million home pages failing automated checks, accessibility is a discipline rather than a technology choice. Ask who is responsible for WCAG conformance, what testing happened beyond an automated scan, and who fixes what turns up in year three. If nobody can answer, the platform question is academic.

2. Usability: who publishes, and how often?

Map your real publishing rhythm before choosing anything. A charity posting news monthly and updating service pages quarterly has very different needs from one running six campaigns a year with volunteer-written copy. Then look at the editing experience from the point of view of the least technical person who will have to use it.

This is where the control question gets answered properly. Structured block-based editing with a decent pattern library is deliberately less freeform than a blank canvas, and that constraint is the point. It is how a volunteer publishes a new page at half past four without breaking your heading structure or dropping the colour contrast below AA. Real control is not the ability to change anything, it is the confidence to change something without wondering what you have just broken.

3. Maintainability: what does year three cost?

Build cost gets board approval. Total cost of ownership decides whether the site still works in 2031. Budget for security patching, dependency updates, accessibility fixes, hosting, and the periodic content review that every charity site needs and almost none get. With a five hour median time to exploitation, updating when someone remembers is not a maintenance plan on any platform.

AI genuinely does cut the cost of building. It does not cut the cost of working out what the site should say, how someone finds the right service page, or how the donation journey flows. That thinking is usually the expensive part, and generated output can disguise it, because you end up with something that looks finished before anyone has asked the awkward questions.

4. Ownership: can you leave?

Charities consistently underweight this one. Can you export your content and your code and take them to a different supplier, a different host, or in-house? Are you tied to a platform account, a credit balance, or one tool’s continued existence? Open source licensing means a WordPress site is genuinely portable. Some AI-generated builds are too, if you export the code and can find someone willing to maintain it. Others are effectively rented. Ask before you sign rather than when you are unhappy.

Where this is heading

Patchstack, whose commercial interest sits squarely in WordPress security, expects the two approaches to merge rather than compete. Their forecast is that “Vibe coding is here to stay, and it’s rapidly merging with WordPress”, with agencies generating plugins on demand and AI producing React front ends while WordPress supplies the backend content infrastructure.

The ecosystem is already shifting that way. Web Almanac data shows Elementor’s share of WordPress page builders falling from roughly 56% to 43% between 2024 and 2025, while the native Block Editor grew to about 18% and WPBakery dropped from 21% to 13%. The direction of travel is towards block-native, structured, semantic output.

The bigger shift for charities is disintermediation: people getting answers from AI summaries and chat interfaces instead of visiting your website at all. The Charity Digital Skills Report found 7% of charities reporting traffic falls from AI search tools, rising to 19% among large charities. Another 48% said the question was either not applicable or they did not know, so awareness is lagging the trend badly.

Research by the agency Tank, covering 800 organisations across 16 sectors, found charity website traffic growth slowing from 15% to 12.5% between 2024 and 2025. Across all industries the fall was steeper, from 26.3% to 3.7%. Charities have held up comparatively well, partly because they publish the sort of trustworthy, well-structured information AI systems want to cite.

That has consequences for the build decision. The Web Almanac notes that pages leaning heavily on client-side rendering, large JavaScript bundles or delayed hydration may be less visible to LLM-based systems, because extraction gets slower and less complete. Clean server-rendered HTML, sensible heading structure and well-scoped structured data are becoming a discoverability requirement rather than an SEO nicety. The same qualities that make a page readable to a screen reader make it legible to an answer engine.

Regulation is tightening alongside it. Under the EU Cyber Resilience Act, commercial WordPress plugins will need vulnerability disclosure programmes to stay available to European users. Whatever you build on, supply chain accountability is becoming a documented obligation.

So which should a charity choose?

• Prompt-generated builds suit short-lived, single-purpose sites: campaign microsites, prototypes for funding bids, internal tools, appeal landing pages. Short known lifespan, one technically confident owner.
• A structured CMS suits your main organisational site: donations, service information, safeguarding content and public credibility, edited by several non-technical people over many years.
• Either works if you fund the maintenance, and neither works if you do not. An unmaintained WordPress site is a liability, and so is an AI-generated one nobody left understands.
• AI belongs in the process either way. As the Web Almanac puts it, in content management AI is currently a workflow accelerator rather than a performance optimiser. We use it every day. The question is whether it produces the thing, or assists the people who own the thing.

We build on WordPress for charities despite it losing on several of the measures above. A well-built block-based site is editable by the people who work there, portable if they would rather leave us, patchable when something breaks, and legible to screen readers and answer engines alike. Those are operating characteristics rather than build characteristics.

The Web Almanac’s conclusion puts it well: outcomes depend less on the logo at the bottom of the site than on how well a platform’s constraints fit the site’s complexity, the team’s capacity and its long-term maintenance goals.

The website your charity can still safely update in 2031 is worth more than the one that looked remarkable in 2026.

Frequently ask questions

Sources and further reading

1. WebAIM, The WebAIM Million 2026, March 2026.
2. Zoe Amar Digital and Think Social Tech, Charity Digital Skills Report 2026, July 2026.
3. Veracode, 2026 GenAI Code Security Report, July 2026.
4. Patchstack and Monarx, State of WordPress Security in 2026, February 2026.
5. HTTP Archive, Web Almanac 2025: CMS, January 2026.
6. Zoe Amar, Disintermediation is a wake-up call for our sector, Third Sector, August 2025.
7. CharityComms, The Great Decoupling: How AI search is impacting charities, November 2025.
8. Charity Digital, How to maximise website traffic from AI searches (Tank research on sector traffic growth).