WordPress vs a custom website: the short answer
Choose WordPress when several people publish every week and you want any agency to be able to take the site over. Choose a custom-built website when the site has a few page types, one main job such as winning enquiries, and links to your own systems. Both need someone to keep them updated. The real choice is who you depend on.
Most comparisons of WordPress vs a custom website argue about the platform, which is rarely what goes wrong. Patchstack found 11,334 new security flaws in WordPress software in 2025. Six were in WordPress itself, and 91% were in plugins. What matters is what gets added to a site, and who keeps it up to date, and that's as true of a custom build.
This guide is for founders and managing directors at UK and EU companies of 10 to 200 people, holding one quote that says WordPress and another that says custom. We build custom websites for companies across Europe, so read our view knowing that. The section on when WordPress is the right call is there because it often is.
What each option actually is
WordPress is free, open-source software for building and editing websites, a kind of content management system (CMS). W3Techs counted it on 40.2% of all websites in September 2026. The design comes from a theme, and extra features come from plugins, add-on programs written by other developers.
Two products share the name. WordPress.org is the software you install on hosting you choose, and it's usually what an agency quote means. WordPress.com is a hosted service that runs the same software for you.
"Custom-built" is looser. Usually it means a developer writes the pages as code for your business instead of assembling them from a theme. Your words and photos then live in text files or in a separate CMS that feeds the site.
Some custom sites are static: every page is generated in advance, so the live server has no database and no login page. This blog works that way. Each post starts as a text file and is published as a plain HTML page.
In practice, a quote that says WordPress or custom usually means one of four setups:
- WordPress with a bought theme and a page builder.
- WordPress with a theme written for you and a short list of plugins. Some agencies call this custom.
- A custom-built site fed by a separate CMS, such as Sanity, Storyblok, or WordPress used only for editing.
- A static custom site, with content edited in files.
Each puts the work and the risk in a different place, so ask which one a quote means before you compare anything else.
WordPress vs a custom website at a glance
This table sets setups 1 and 2 against setups 3 and 4. The sections after it explain each row.
| WordPress | Custom-built | |
|---|---|---|
| Suits | Many people publishing often, or features that plugins already cover | A few page types, one main job, links to your own systems |
| Where the security risk sits | Plugins and themes, and how fast they get updated | The site's own code and the libraries it uses; a static site has no login to attack |
| Updates | WordPress applies its own security releases; plugins need a named owner | Code libraries need a named owner; fewer parts run on the live server |
| Editing | Wide freedom, so layouts drift unless the developer locks them | Set fields for each page type; a new kind of page needs a developer |
| Speed | Depends on the theme, the page builder and the plugins | Depends on the build; custom isn't automatically fast |
| Finding your next developer | Easy, because WordPress developers are plentiful | Depends on the framework and the documentation |
| Get in writing | A plugin list with each licence holder; your own admin login | The code repository in your name; documentation |
Plugins: WordPress's strength and its weak point
Plugins are why WordPress is cheap to extend. An events calendar, a membership area or a form that feeds your CRM is often one install away, and someone else maintains it.
Each plugin is also someone else's code, running with full access to your site and updating on its author's schedule. Patchstack found that 46% of the flaws it logged in 2025 had no fix available when they were made public.
Who controls a plugin can change too. In October 2024, during a legal dispute between Automattic and the hosting company WP Engine, WordPress.org took over the listing of Advanced Custom Fields, a plugin WP Engine makes. Sites with auto-updates on were switched to WordPress.org's own copy, renamed Secure Custom Fields.
The plugin's makers said millions of installations were getting code they had not approved. Two months later, a US court ordered the listing returned. The switch needed nothing from site owners. On WordPress, code on your site can change because of a dispute between companies you have never dealt with.
Attackers use the same route. In June 2024, Wordfence found malware in five plugins in the official directory, delivered as ordinary updates. On each site that installed one, it tried to create an administrator account for the attacker.
Paid plugins add a licence to track. Elementor says that if you don't renew Elementor Pro, you can no longer update it. Every paid plugin on a quote is a renewal someone has to own, in your company's name.
So count the plugins on any WordPress quote. Each should do a job the site needs, come from an author who fixes things quickly, and sit on a list with its licence holder. Fewer is safer.
Updates: someone has to press the button, on either kind of site
Neither option looks after itself. By default, WordPress has installed its own minor and security releases automatically since version 3.7. Plugin and theme auto-updates are opt-in: an administrator switches them on one by one.
Timing matters. Patchstack found that about half of high-impact WordPress flaws are exploited within 24 hours of becoming public. A site whose plugins get updated at a monthly check-in can spend weeks exposed.
The server needs care too. WordPress recommends PHP 8.3 or later, the language it runs on, and warns that older versions past their end of life may expose a site to attack.
A custom site has fewer moving parts on the live server, but it isn't maintenance-free. Its code relies on open-source libraries, and those need updating too. In September 2025, CISA, the US cybersecurity agency, warned of a self-spreading worm called Shai-Hulud. It had compromised more than 500 packages on npm, the registry most JavaScript projects install code from.
A static site has no plugins and no login page on the live server, so the routes behind most of those WordPress flaws don't exist. Its build still needs someone watching its libraries.
Whichever you choose, get the update arrangement in writing: who does it, how soon after a fix, and who checks the site afterwards. Our guide to what website maintenance involves sets out the whole job.
Who can edit what, and how much they can break
WordPress was made for people who publish. Its built-in roles fit most teams. An Editor can publish and manage anyone's posts, an Author only their own, and a Contributor can write but not publish.
The same freedom lets layouts drift. The HTTP Archive estimates that around 60% of WordPress sites use a page builder, such as Elementor, WPBakery or Divi. Editors can then drag sections around and change colours and fonts, which is how a homepage ends up in four fonts. WordPress can lock blocks and restrict colours, but only if the developer sets it up.
A custom site gives editors a content model instead: a fixed set of fields for each kind of page. A service page might have a title, a summary, photos and common questions. The editor fills those in, and the layout stays as designed. It's harder to break and less flexible, because a new kind of page needs a developer.
The trap on the custom side is a site nobody can edit without the developer, which is why we design a content model into every website we build. Before you sign, have someone on your team change a photo and a paragraph while you watch. If that needs a developer, the site is yours on paper only.
Speed: the build decides, not the platform
Both can be fast. The difference is how easy each makes it to become slow. The HTTP Archive's 2025 Web Almanac found that 45% of WordPress sites passed Google's Core Web Vitals on mobile, among the lowest of the platforms it measured. It put that mostly down to configuration and tooling choices rather than WordPress itself, and named page builders as a major cause.
A WordPress site with a lean theme and a few plugins can pass comfortably, while a custom site loaded with tracking scripts and full-size photos can fail. The platform on a quote tells you little. The speed target tells you more.
Our guide to what sets the price of a website in the UK lists the targets to ask for. We treat them as a requirement on every site we build.
Then test for yourself. Run your current site, and a site each supplier has built, through Google's PageSpeed Insights and read the mobile results.
Ownership: what you can take with you when you leave
WordPress wins on one kind of freedom. The software is licensed under the GPL, so it runs on almost any hosting. Its export tool saves your posts, pages and users as a file another WordPress site can import. WordPress developers are easy to find, so changing supplier means hiring the next one, not rebuilding.
The export leaves the design behind. The theme, the plugins and their settings travel only in a full backup of the files and the database. Paid plugins arrive with licences that may be in your agency's name.
A custom site is only as portable as its handover. The code should sit in a repository your company owns, on a widely used framework, with documentation another developer can follow. Without those, the one supplier who understands the code becomes the lock-in.
Our own standard is simple. Your domain, hosting, code repository and documentation sit in your accounts. You own the site outright, and our name appears as the studio that built it. Whichever way you go, run the five checks in our guide to whether you own your website before you sign.
When WordPress is the right call
Choose WordPress, or stay on it, if any of these describes you:
- Several people publish every week: articles, news, events or job posts.
- A feature you need already exists as a well-maintained plugin, and building it would be a project of its own.
- You want a large pool of developers to choose from when you change supplier.
- You already run WordPress, and the complaint is speed or security. An audit of the theme and plugins is usually less work than a rebuild, and we'll say so when it is.
- You'll pay someone to keep it updated, and that's in writing.
Say you run a 40-person accountancy firm. Your marketing lead publishes two articles a week, three partners update their profiles, and you run monthly webinars with sign-ups. That's a WordPress site: a theme written for you, a short plugin list, and a named person on updates.
You may need neither. A sole trader who mainly needs to exist online can do well with Wix or Squarespace and a domain in their own name. And if the site is mainly a shop, see our guide to Shopify vs custom ecommerce.
When a custom-built website is worth it
A custom build pays off when the site's job is narrow and important. It fits if:
- The site exists to win enquiries, with a few page types edited monthly rather than daily.
- Speed and search visibility are the point, and you want them designed in rather than rescued from a theme.
- It connects to your own systems, such as a CRM or a quote tool. Once it has logins and rules of its own, it's a web application and should be scoped as one.
- You'd rather have no admin login on the public internet at all.
- The content has a structure no theme expects, such as every service page in three languages.
Say you run a 25-person engineering consultancy. You have eight services, a list of past projects, and a quote form that should reach your CRM with the service already filled in. One person edits the site once a month. A custom build with a small content model fits, and there are no plugins to watch.
The condition is the same as on WordPress: someone owns the site after launch. On the sites we build, monitoring and maintenance are optional and agreed at handover, and the documentation lets you give that job to someone else.
Questions to ask whoever quotes you
Put the same questions to every supplier, whichever platform they propose:
- Which of the four setups is this, exactly?
- For WordPress: which plugins, why each one, who makes them, and whose name is each paid licence in?
- For a custom site: which framework, where will the code live, and what documentation do we get?
- How do we edit a page, change a photo or add a new service? Show us.
- Who applies updates, how soon after a security fix, and who checks the site afterwards?
- What speed will you test to, and on which device?
- If we leave, what do we take with us, and what does handover involve?
A good supplier answers each in a sentence or two. If one answer is "don't worry about that", worry about that one.
This week, ask whoever runs your current site for two things. The first is a list of every plugin or code library it depends on. The second is the name of the person who updates them. If nobody can give you both, fix that before you choose between WordPress and custom.
Questions
Is a page builder like Elementor or Divi the same as a custom design?
No. A page builder lets someone arrange ready-made blocks inside WordPress without writing code. The result can look bespoke, but underneath it's still a theme, a builder and plugins, with the updates and licences each one brings. A custom theme is code written for your site, usually with far fewer plugins behind it.
Can our team keep the WordPress editor they know on a custom-built site?
Yes. WordPress can run headless, as the editing tool only, while a custom-built site displays the content. Your team keeps the screens it knows, and the public site has no WordPress login on it. You still maintain the WordPress install behind it, so this suits teams that publish a lot, not sites edited once a month.
Is WordPress or a custom site better for SEO?
Neither, by itself. Google says its search always seeks to show the most relevant content, even when page experience is poor. Page experience helps when many pages are similarly useful. Both options can carry page titles, structured data, sitemaps and redirects. On WordPress a plugin usually adds them; on a custom site the developer builds them in. What differs is how easy each makes it to become slow.
How we wrote this: drafted with AI, then checked and edited by the people who build our projects. Figures come from our own work or from the linked sources.