Why we build small business websites on Sanity instead of WordPress

As of mid 2026, WordPress runs about 41 percent of all websites, which is roughly 60 percent of every site built on a recognised content management system. Those are W3Techs figures and they have barely moved in years. When a small business asks for a website, WordPress is the default answer almost everywhere, and it was our default too until we sat down and worked out what we were signing clients up to for the following five years.

We build on Sanity and Next.js instead. This is the long version of why, including the parts where WordPress is still the better choice, because there are some.

A traditional CMS does two jobs in one application. It stores your content, and it builds the pages your customers see. WordPress works this way by default. Someone visits your site, WordPress wakes up, queries a database, runs whatever plugins are installed, assembles a page in PHP and sends it down the wire.

A headless CMS only does the first job. Sanity stores your content and hands it out through an API. Something else, in our case Next.js, turns that content into pages. The tool you edit in and the website your customers load are two separate things that talk to each other.

The practical consequence for a business owner is simple enough. The thing your customers load is not the thing you log into. Your website cannot be slowed down by the editor, and the editor cannot be broken by the website.

This is the part that settled the decision for us. Patchstack, which tracks security issues across the WordPress ecosystem, recorded 11,334 new vulnerabilities in 2025, a 42 percent increase on the year before. 91 percent of them were in plugins and 9 percent in themes. WordPress core itself had six, and all of them were rated low priority.

The pattern is consistent year on year. WordPress itself is well maintained software. The extensions bolted onto it are where the trouble lives, and every small business WordPress site I have opened up has had at least a dozen of them installed, usually without the owner knowing what half of them do.

Two more numbers from the same report. 46 percent of those vulnerabilities had no fix available from the plugin developer at the point they were made public. And for the vulnerabilities that get attacked hardest, the weighted median time between public disclosure and the first exploitation attempt was five hours.

Which makes the standard advice, keep your plugins updated, necessary but nowhere near sufficient. You cannot patch inside five hours while you are on a job in Princes Risborough, and in almost half of cases there is nothing to patch with. Patchstack also ran penetration tests against a group of hosting providers and found their combined defences blocked 26 percent of vulnerability attacks. Good hosting helps. It does not solve this.

On a Sanity and Next.js build there is no PHP application sitting on a server you are responsible for, and no plugin ecosystem running code on it. Your content lives in Sanity's infrastructure and your pages are built ahead of time and served from a CDN. I am not going to claim it cannot be attacked, because that would be nonsense. The attack surface is smaller by a large margin, and the difference shows up in what a client has to think about on a Sunday night.

This is the less obvious advantage, and the one clients tend to notice after six months rather than on day one.

In a typical WordPress page, everything is one long blob of formatted text. Your opening hours are a sentence inside that blob. Your prices are a table someone pasted in from Word in 2019. If you want the opening hours to appear on the contact page, in the footer, and in the structured data that search engines read, somebody types them three times. Three times is where mistakes come from, and it is why so many local businesses have a website quietly advertising last year's Christmas hours.

In Sanity you define the shape of your content up front. Opening hours are a field. A price is a number attached to a service. A location has a name, an address and a set of hours. You edit it once and it changes everywhere it appears, including the machine readable markup underneath.

That last part matters more than it did two years ago. When someone asks ChatGPT or Google's AI results for a recommendation, the answer is assembled from whatever those systems can parse about you. Structured content is easier for them to read correctly than a blob of HTML with your phone number buried in the middle of a paragraph. We also publish a plain text version of the whole site at /llms.txt, though I would not oversell that one. No major AI company has committed to reading those files yet, and we treat it as cheap insurance rather than a trick.

There is a second benefit that sounds abstract until it happens to you. Because your content sits in a database rather than being welded to a theme, redesigning the site does not mean rebuilding the content. We can throw away the entire front end and your words come across untouched. Anyone who has been through a WordPress theme migration and spent a fortnight untangling shortcodes knows what the alternative feels like.

Google publishes the thresholds it uses. Under Core Web Vitals, the main content of a page should render within 2.5 seconds, the page should respond to a tap within 200 milliseconds, and the layout should not shift about while it loads. These are measured on real visits from real people, and you need three quarters of them to pass.

A WordPress site can hit those numbers. Plenty do, with decent hosting and disciplined plugin use. But you are working against the architecture rather than with it, because every request still means PHP, a database query and whatever plugins have hooked themselves into the process. The entire caching plugin industry exists to paper over that one fact.

With Next.js the pages are built in advance and served from a CDN close to the visitor, so they are already fast before anyone starts optimising anything. On a phone with two bars of signal outside a village hall, that gap is the difference between a call and a bounce.

There are situations where I would tell you to use it, and I would rather say so myself than have somebody else say it for me.

If you need a full shop with complicated stock, subscriptions or booking rules, WooCommerce and its ecosystem will get you there faster and cheaper than a custom build. If you are the sort of person who enjoys installing things and tinkering on a Sunday, WordPress is built for that and Sanity is not. And if your entire budget is a few hundred pounds, WordPress on shared hosting with a bought theme is the only honest answer anyone can give you.

There is also a practical point about people. There are WordPress developers in every town in Buckinghamshire. There are fewer who work with Sanity and Next.js. If you fell out with us tomorrow, replacing us would take longer than replacing a WordPress developer. We deal with that by keeping the content model documented and the code standard rather than clever, so anyone competent can pick it up, but it is a real consideration and you should weigh it rather than take my word that it does not matter.

And a badly built Sanity site is worse than a well built WordPress one. The stack is not what makes a website good. It changes which things are easy, which are hard, and what you have to worry about in year three.

• You log into an editor that shows your content and nothing else. No dashboard full of plugin notifications, licence renewals and upgrade prompts.
• Nothing needs updating on your side, so there are no security patches for you to miss while you are busy running the business.
• The site loads quickly on a phone on a bad connection, which around here is most of the time.
• Your content is yours in a portable form. If you ever leave us you leave with a structured export, not a database dump that only the next developer can open.
• Running costs are low. Sanity has a free tier that a typical small business site does not outgrow, and serving a static site costs very little.

What you give up is the ability to install a plugin yourself on a Sunday evening. In my experience that is the thing that breaks small business websites in the first place, so I am comfortable with the trade.

The short version, for anyone technical who has read this far. Content is modelled in Sanity as documents plus reusable sections, queried with GROQ, and rendered by Next.js server components. Editors assemble a page from an ordered list of sections, so adding a new page does not need a developer. Every section carries an optional anchor id, which means a link can point at a specific part of a page rather than the top of it. The sitemap and the robots rules are generated from the CMS rather than hard coded, and there is a /llms.txt endpoint that gives AI crawlers a plain text version of the site.

We built our own site this way, which is the only honest way to sell it. If you want to see what editing actually feels like, we will show you the real editor rather than a screenshot of one.

If you have a WordPress site that has turned into a maintenance problem, or you are choosing a platform for the first time and would rather not choose wrong, get in touch. We do a free health check covering speed, mobile behaviour and how you show up in search, and we will tell you plainly whether a rebuild is worth the money or whether you would be better off spending it somewhere else.