Try something that takes ten seconds. Right-click anywhere on your organisation's website and choose "Inspect". A panel opens showing the code your website actually produces.

You do not need to understand it. Notice one thing: is it tidy and organised, or does it look like someone threw alphabet soup at a wall?

That code is:

  • what a browser downloads and assembles before anyone sees your homepage;
  • what screen readers parse when somebody navigates your pages without sight;
  • what your next web developer inherits when they quote you for changes.

On most of the nonprofit websites I have audited, it is a mess. Not because the design is bad, but because the tool that built it produces bad output by default.

This is not only a developer concern. Code quality affects whether donors finish their gifts, whether your site meets accessibility requirements, and how much every future change costs you. That makes it a communications, operations and governance concern.

What most website builders actually produce

Imagine inheriting a filing cabinet from a previous colleague. You expect organised folders: budgets here, reports there, correspondence by date. Instead you find hundreds of unmarked Manila folders nested inside each other.

Every document has its formatting instructions stapled to it, even when fifty documents share the same format. And scattered throughout are sticky notes only the person who built the system could read.

That is what most website builders produce under the surface. The technical term is "div soup":

  • Pointless nesting. Layer upon layer of containers with no structural purpose, each wrapped in another.
  • Meaningless class names. Random strings (.css-1a2b3c, .sc-bdVTJa, .elementor-widget-wrap) that say nothing about what they do.
  • Duplicated inline styles. Repeated on every element instead of defined once and referenced.
  • Unneeded JavaScript. Bundles loaded on every page whether they are needed or not.

"Soup" is doing real work here, because div and span are the two HTML elements that mean nothing. MDN's glossary is blunt about it: a span styled to look like a top-level heading "has no semantic value, so it will not get any extra benefits". Build a page from those two elements and it is legible to the eye and silent to everything else.

Visitors see none of this. They see the same polished design whatever is underneath. But performance, accessibility and maintainability depend entirely on what is underneath.

Why this matters for your organisation

The link between code quality and outcomes is not abstract, and there are published numbers for most of it.

Donations

M+R's 2026 Benchmarks found that 1.6% of all nonprofit website visitors made a donation, and that the average site earned $1.33 per visitor. On the primary donation page, 11% of desktop visitors and 8% of mobile visitors completed a gift, at an average of $168 on desktop and $88 on mobile.

Those are US figures, so read them for shape rather than pounds. A charity website converts a thin slice of its traffic. Anything that loses visitors before they reach the form costs more than it looks like it should.

Page speed

Page weight is one. Google's threshold for Largest Contentful Paint, the time a page's main content takes to appear, is 2.5 seconds or less for the 75th percentile of visits.

Every unused stylesheet, every JavaScript bundle a page does not need and every extra layer of nesting spends part of that budget. Google also documents Core Web Vitals as something its ranking systems reward, so the same bloat can cost you twice.

Accessibility

WCAG 2.2 Success Criterion 1.3.1, Info and Relationships, a Level A requirement, says structure conveyed visually must also be available programmatically. A heading that is only a bigger, bolder span is a heading to you and nothing at all to a screen reader.

That matters because of how people navigate. In WebAIM's tenth Screen Reader User Survey, 71.6% of respondents said they find information on a long page by navigating its headings. WebAIM notes this has grown over time and remains the predominant method.

WebAIM's guidance on semantic structure draws the corollary. Elements like header, nav, main and footer let screen reader users move between a page's major regions. A page built from generic containers offers none of those landings.

So your site can look perfectly accessible to a sighted visitor while being close to unusable with assistive technology. For a charity under public scrutiny that is a reputational problem as well as a compliance one.

The European Accessibility Act has applied since 28 June 2025 to consumer products and services offered in the EU. Whether it reaches your organisation depends on what you offer and where. I have set out what conformance involves in this guide to WCAG 2.2 for charity websites.

Maintenance debt

This cost compounds, and it is the hardest to see from outside. Every change, whether a campaign page, a layout tweak or a new section, means your developer navigating the code underneath.

Clean code makes changes predictable. Messy code turns every change into archaeology: the developer works out what they are looking at before they can do what you asked. You pay for that time. The messier the code, the longer it takes, and the higher the risk that fixing one thing breaks another.

It is also what makes leaving expensive, which is why handover planning is worth doing while you still have the incumbent's goodwill.

What Webflow does differently

Most visual builders put ease of use first, letting you drag any element anywhere with pixel-level precision. To make arbitrary placement work, the tool generates complex positioning code underneath: nested containers, inline styles and auto-generated class names.

Webflow made a different choice. Instead of hiding how the web works, it exposes the actual CSS box model (flexbox, grid, padding, margin) in its visual interface. You work with the same concepts a developer uses writing code by hand, just visually.

So the output maps closely to what you designed:

  • A three-column section is a flex container with three children, not a stack of nested divs with computed positions.
  • Class names are whatever you named them, not auto-generated strings.
  • Styles are reusable classes, not inline properties duplicated on every element.

The tradeoff is a steeper learning curve. You need to understand, at least conceptually, how layout systems work. But that is exactly what makes Webflow suitable for organisations that need their website to be institutional infrastructure rather than a disposable marketing surface.

That said, "clean" is relative. Webflow still ships its own runtime JavaScript for interactions and forms, and class names get messy fast without a naming convention. The output is clean only if the builder applies architectural discipline. A carelessly built Webflow site can be nearly as disorganised as the alternatives. The difference is that Webflow lets you be disciplined. Most other platforms do not.

The hidden cost of "easy"

Wix, Squarespace and the WordPress page builders (Elementor, Divi) sell themselves on ease, and getting a site live is fast. But "easy to build" and "easy to maintain" are different things. For an established organisation running a site for several years, the total cost of ownership tells a different story.

I have written about the specific risks a template build carries and about the point at which an established NGO outgrows one.

Every change on these sites means a developer working against the code the tool generated:

  • Wix. Class names are hashed and unpredictable.
  • Squarespace. The template constrains what is possible in ways that stay invisible until you try something it did not anticipate.
  • WordPress with Elementor. The page builder adds its own layer of complexity on top of WordPress's, with plugins generating their own CSS, JavaScript and database queries.

So maintenance costs escalate. Year one feels affordable. A few years in, every change takes longer, costs more and carries more risk. Eventually you are often facing a complete rebuild, not because the design is outdated but because the code has become unworkable. The easy platform did not save money. It deferred the cost and added interest.

What to ask your agency or developer

You do not need to understand code to hold a supplier to account for it. These five questions tell you whether your site sits on solid foundations or accumulated compromise.

1. What does our Lighthouse score look like across performance, accessibility, best practices and SEO?

Lighthouse is Google's own audit tool. Chrome's documentation bands the scores at 0 to 49 (poor), 50 to 89 (needs improvement) and 90 to 100 (good).

Anything below 90 warrants an explanation. If your agency does not know what Lighthouse is, that tells you something important.

2. Can you show me the heading hierarchy on any page?

A well-structured page has one H1, then H2s for major sections and H3s for subsections. If the hierarchy is random, the accessibility foundations are compromised, and Success Criterion 1.3.1 above is the reason.

Be clear about why you are asking. This is an accessibility question, not a search one. Google's own guidance says heading order does not matter from a Search perspective, so anyone selling heading hygiene as a ranking fix is selling the right thing for the wrong reason.

3. How many unused CSS and JavaScript files load on each page?

Every file that loads but goes unused spends the visitor's time for nothing. A clean build loads only what the page needs, and the same PageSpeed Insights report measures it.

4. What happens if we need to move to a different supplier in two years?

If the answer involves the word "rebuild", you are locked in. A well-built site on a platform like Webflow can be handed to any competent Webflow developer without starting from scratch. Ask this in your annual vendor review, in the calm, not in a crisis.

5. Can someone on our team update a blog post without developer assistance?

If content updates have to go through a developer, or worse an AI coding tool, your content governance has a structural bottleneck. It will slow your communications team and raise your costs indefinitely.

Where to start

You do not need to learn to code. You need to know which questions produce useful answers, and to notice when a supplier would rather you did not ask them.

If you already suspect a problem and the question is how far to go, start with the rebuild-or-remediate decision. The answer is often less drastic than it feels.

If you want an independent read on where your site stands before you decide anything, that is what the Blueprint Audit is for: a structured diagnostic covering architecture, accessibility, security and content governance, delivered as a Board-ready report with specific findings and recommendations you can take to trustees.