Forms and Search in a Headless WordPress Site

A WordPress form plugin does three things: renders HTML into a theme, runs its own JavaScript for validation and submission, and handles the submission server-side — storing it, emailing it, and running spam checks.

In a headless setup the first two are gone, because there's no theme to render into. The third still works, which means the usual approach is to build the form in your frontend and post to something that handles the submission.

That something can be WordPress — a custom REST endpoint, or a form plugin's own API if it has one — or a third-party form service. Both are legitimate.

A custom REST endpoint is straightforward and keeps everything in one system: submissions are stored in WordPress, visible in the admin, and exportable alongside your other data.

• Register the route with a permission callback of __return_true, deliberately, because the caller is an anonymous visitor.
• Validate and sanitise every field through the args definition, so the handler can trust its input.
• Store the submission first, then attempt notification. A failed email must never mean a lost enquiry.
• Rate limit the endpoint. A public write endpoint without rate limiting is a spam endpoint the day someone finds it.
• Return specific validation errors so the frontend can highlight the right field.
• Configure CORS for your frontend's origin, since the browser is calling WordPress cross-origin.

A dedicated form service handles storage, notification, spam filtering and often a submissions dashboard, with no backend work at all.

It's a reasonable choice when the form is simple and the submissions don't need to live in WordPress. The trade-offs are a subscription, another system to check, and your submission data sitting with a third party — which matters for a contact form collecting personal details.

If the submissions need to reach a CRM anyway, a service that integrates directly may be less work than building the same path yourself.

A public form endpoint attracts automated submissions within days of going live. Plan for it before launch rather than after the first hundred.

• A honeypot field, hidden from people and from assistive technology, that bots fill in. Cheap and catches a surprising amount.
• A time check: a form submitted under a couple of seconds after the page loaded wasn't filled in by a person.
• A CAPTCHA or proof-of-work challenge, ideally invisible to legitimate users.
• Rate limiting per IP at the endpoint or the edge.
• Server-side content heuristics — a message that's a wall of links, or a name containing a URL.
• Answer spam submissions with a success response so a bot learns nothing about what was filtered.

This catches people out in every headless build, and in plenty of normal ones. Email sent by PHP from a web server frequently lands in spam or is rejected outright, because the server isn't an authorised sender for your domain.

Send through a transactional email service with proper SPF, DKIM and DMARC records on your domain. That's the difference between notifications arriving and notifications silently not arriving.

Also consider an acknowledgement email to the person who submitted. It confirms the message arrived, which reduces duplicate submissions and support queries — and it exercises the email path often enough that you notice when it breaks.

Monitor it. A form that stops delivering looks exactly like a form nobody is using, and the gap is usually discovered weeks later.

WordPress's core search does a LIKE query against post titles and content. It has no relevance ranking beyond date, no typo tolerance, no stemming, no weighting and no faceting. It also doesn't search custom fields or taxonomies unless you make it.

In a theme, people live with it. Going headless is a good moment to reconsider, because you're rebuilding the interface anyway and the REST API's search parameter inherits all the same limitations.

• The REST API's search parameter — free, no dependencies, and adequate for a small site where people mostly know what they're looking for.
• A custom endpoint with a better query: search titles, excerpts, selected meta fields and taxonomy terms, with weighting so a title match ranks above a body match. A decent middle ground.
• A hosted search service — index your content on publish, query it from the frontend. Typo tolerance, instant results, faceting and analytics, at the cost of a subscription and an index to keep in sync.
• A self-hosted search engine, for when the data can't leave your infrastructure. Most capable, most operational work.
• Client-side search over a prebuilt index, which works well for a site with a few hundred pages and no server-side search at all.

Any external search means a second copy of your content that can drift. Index on publish and on update, and remove on delete or unpublish — a search result linking to a deleted post is a bad look.

Use a webhook from WordPress rather than a scheduled full reindex, so changes appear immediately. Keep a full reindex available as a repair mechanism, because indexes do get out of step.

Handle the failure case: if indexing fails, the content still needs to publish. Queue the index update rather than blocking the save.

• Show results as the person types, if the backend can keep up.
• Handle no results properly — suggest alternatives, show popular content, offer the contact page.
• Highlight the matched terms in the results.
• Log what people search for. It's the clearest signal you have about what your content is missing.
• Make sure results are keyboard navigable and announced to screen readers.
• Noindex the search results pages themselves; they're infinite and thin.