WordPress, custom development and headless aren’t three mutually exclusive kinds of website. WordPress is a CMS, custom development describes work made for your brief, and headless describes separating content management from presentation. A WordPress site can therefore contain custom work and run headlessly too. A useful comparison starts by identifying which decisions you’re comparing. Begin with your brief, as described in our custom website guide.
What do WordPress, custom and headless mean?
The WordPress REST API enables a separate front end or application. Access rules for non-public content still matter. Choosing headless therefore doesn’t automatically mean replacing WordPress.
| Decision | Example of what you choose | What it doesn’t yet determine |
|---|---|---|
| Content management | WordPress or another CMS | How the public site looks or is built |
| Presentation | A theme or separately built front end | How much design work your brief requires |
| Custom development | Own blocks, an integration or a particular user journey | That every component is rebuilt |
| Publication | Direct display, pre-rendering or a combination | Whether editors can work comfortably |
A proposal using only the word ‘custom’ leaves those decisions open. Ask which existing components will be used, what will be made for you and why. That also gives you a better basis for comparing two proposals.
When might a WordPress site with a theme fit?
Investigate this route when the CMS and display can support the required editing tasks together. An existing or purpose-built theme may provide a suitable basis for articles, service pages and other recurring content. Ask to see the pages and exceptions you actually need.
The distinction between an existing theme and an individual design isn’t the distinction between good and bad. An existing component can be useful; a purpose-built one can be poorly implemented. Assess whether the design and editing fields support your work and avoid unnecessary parts.
Ask which extensions are required and who maintains the combination. A plugin name doesn’t establish that the required task works. Have a form tested with its error message, confirmation and delivery, for example. You’re comparing a configured solution, not a list of promised capabilities.
If the main question is still which platform to use, read the WordPress, Webflow, Wix and Shopify comparison. An architecture decision becomes useful once the task is clear.
When is there a reason for a separate front end?
A separately built front end may fit when the desired presentation, user functions or collaboration between channels demonstrably benefits. Consider an existing content source also used in another application. Ask which work the separation makes easier and which work it introduces.
Multiple channels don’t appear simply because a CMS offers an API. Content must be usable beyond its original page. A title and description might be reusable, whereas text referring to ‘the button on the right’ may be less so. Each channel also needs its own display and access arrangements.
Request a trial of the uncertainty. If the reason for headless is a particular product finder, have that search and editing task built. If it’s about two channels, have the same content work in both. A new homepage alone proves neither benefit.
What does headless mean for editors?
Editors need a complete publishing route, not just fields in an administration screen. Use an article with an image, translation and scheduled publication as a trial. Check who can change it, how preview works and when visitors see the new version.
Someone must manage the connection between separate components. A change may require a new build or a refresh of stored content, for example. Agree how failures become visible and who acts when CMS content has changed but the website still shows the old version.
Test reversing changes and deleting content too. What happens to links pointing at a deleted page? Does a withdrawn offer remain visible in another channel? Those questions belong in the content model and publishing arrangements, rather than waiting for the final delivery check.
The Strapi, Payload and Sanity comparison looks further at editing tasks and CMS selection. Choose the system around the work your team needs to do, including permissions and handover.
Does the site automatically become faster or more secure?
No. Headless describes a separation, not how every page loads. A separate front end can contain plenty of browser code or wait on slow data. A WordPress site can reuse pages through caching. Compare implementations with matching content and functions.
For differences in processing, read the Astro, Next.js and WordPress comparison. Have speed measured on representative pages after real images, forms and measurement services have been added. An empty demo isn’t a dependable prediction of the delivered site.
Security depends on implementation too. Separation changes where content, access and processing sit; those responsibilities don’t disappear. Agree who manages accounts, software, keys and any public interfaces. Ask how changes are tested and how recovery works.
For a claimed security benefit, have the supplier explain which risk decreases and which measures are needed. ‘Custom’ or ‘headless’ isn’t itself a security measure and doesn’t produce a maintenance-free system.
How do you compare cost and ownership?
Have proposals cover the same pages, functions, migration and operating period. Separate design, development, content, hosting, licences, support and changes. A split setup may require work for preview, publishing and monitoring the connection between components.
There isn’t a fixed price order for WordPress, custom and headless. A small, focused custom component may involve different work from a large configuration of existing modules. The estimate follows from the actual solution and the responsibilities agreed.
Discuss ownership and handover separately. Rights to your own code differ from rights to standard software, images or services used. Access to files also isn’t the same as a working handover to another supplier. Our explanation of code ownership and supplier dependency helps you set out those agreements.
On departure, request a demonstrably usable result: content, media, settings, documentation and access to the components needed. Have the supplier identify which services will continue and which work a move requires.
Can you switch later without losing everything?
A move is possible, but its scope depends on the existing setup. A content export doesn’t automatically carry over design, plugins, forms, permissions or publishing behaviour. First investigate what can be reused and what needs configuring again.
Run a small trial migration with an ordinary page and a difficult exception. Check images, links between pages, metadata and URLs. Record how missing fields and old references will be handled. That reveals work before you fix a schedule for the entire site.
A move needn’t replace every component at once. Investigate whether a limited change is enough. Give the reason for replacement more weight than the appeal of a new technical label.
How do you actually get started?
Describe who manages content, what visitors need to do and which problem the current setup causes. Then compare two complete implementations against the same tasks, including publication, maintenance and handover.
For website development, TopDevs helps make that assessment concrete. Book a call to discuss the requirements and the smallest useful trial.
