What your IT team will ask about headless WordPress

On its own private address, separate from the public domain. Only editors and the build process talk to it. It is not linked from the public site, it carries a no-index instruction so search engines ignore it, and where the client’s IT wants it, access is limited to office and VPN addresses. In practice most attacks on WordPress sites start at the login page. Ours is not on the domain anyone can find.

Static files. The public site is HTML, CSS, JavaScript and images, pre-built and served from a content delivery network. There is no PHP running, no database to query, and no login page. A request to the public domain cannot reach WordPress, because WordPress is not there. This is the single biggest security difference from a normal WordPress site, and it is structural rather than a plugin.

When an editor clicks Publish, a build runs. It reads the content from WordPress over a read-only connection, generates the pages, and deploys them to the network. The public site only ever has read access to WordPress, and only at build time. Nothing on the public site can write to the database, because there is no path for it to do so.

The client. Hosting, domain, DNS, the code repository and the WordPress installation are all in the company’s name from the start, with us added as a collaborator. If the relationship ends, the company removes our access. We do not hold anything hostage and we do not want the liability of holding it.

Nothing that a visitor can see. The public site is a copy of the last published version and it keeps serving. Editors cannot publish until WordPress is back, and that is the whole impact. A failed plugin update, a hosting outage, or a compromised admin takes the editing system offline, not the site.

Two systems, two patch cycles. WordPress core and plugins are updated monthly on the care plan, with a tested backup taken first, and there are fewer plugins than on a normal site because WordPress no longer renders pages. The frontend has its own dependencies, which we update and rebuild on the same cycle. The monthly report lists what was updated and what changed. If the company prefers to run its own WordPress hosting and patching, that is a supported option and we look after the frontend only.

WordPress is backed up daily, database and files, and we run a restore test at handover so the backup is known to work rather than assumed to. The frontend needs no backup in the usual sense: it is generated from the repository and the content, and every build is kept, so a bad deploy is rolled back to the previous one in about a minute.

Contact and enquiry forms post to a server route we control, which validates the input and sends the enquiry by email to the company’s own mailbox. We do not route form data through third-party form services unless the client asks for one. Nothing is stored on the public site. Where a form collects more than a name and a message, the data handling is written into the proposal so the company’s privacy notice can describe it accurately.

IT will also ask what the catch is, and there is one. This is more moving parts than a single WordPress install: two systems, a build step, a deployment pipeline. Content changes need no developer, but design changes do, because the layout is code rather than a theme setting. And it costs more up front than a theme-based site, which is why we say in the first call when a well-tuned traditional WordPress site would do the job for a small brochure. For a company whose site gets security-reviewed, that trade is usually the right one. For a five-page pamphlet it usually is not.

If your IT team has a question that is not on this list, send it to us before the meeting. We would rather answer it in writing than have the project stall on it.