WordPress form not submitting: the cached page

A WordPress form usually carries a hidden token with the page, which tells the server the submit came from that page and not from somewhere else. Caching plugins store the finished page and hand the same copy to signed-out visitors for a while. If the token inside that copy has expired, the server refuses the submit, and some forms answer with no message at all, so the visitor sees the button return to normal. Your own test passes because your logged-in session is usually served a fresh page. The failure sits in the copy the stranger received, not in the form you can see.

• Submit the form in a private window, signed out. Does any message appear?
• Open the browser's error console before you press submit. Does a failed request show up?
• Clear the site cache in the caching plugin, then submit signed out again. Does it now work?
• Note the exact point where the form stops: the button, the message box or the send.

When you press send after signing in, the request is usually built from a page the server has just produced. A signed-out visitor is more likely to receive a stored copy of the same page, built earlier and possibly for someone else. That copy looks correct. The labels, the layout and the button all appear, so nothing on the screen reveals that the token inside is stale. Owners tend to find this only after a visitor writes in, because their own test passed.

A stale token and a broken script leave different traces, so do not treat them as one problem. A refused submit usually shows an error response for the form request, which you can see in the browser's network panel for that page. A script error shows a red line in the console before you submit, and it can stop the button from doing anything at all. If the console is clean and the request is never sent, look at the button and the form script before you look at the cache.

Test the two cases in turn. Clear the cache, then submit signed out. If the form works, the copy was the cause. If it still fails with a clean console, the next suspect is the form's own address or a security rule that blocks the request. Do not conclude anything from a logged-in submit, since it skips the copy entirely. Write down the request address and the status it returned, so the fix has something exact to aim at.

A signed-out visit is the one that reproduces a stranger's path. It starts with no session, so it gets the same cached page a stranger would get, presses the same button and stops where the stranger stops. A simulated visitor records the step, a screenshot and any failed request on that step, so you can match the stop to the request rather than guess from an inbox that stays empty.

Clearing the cache fixes the copy in front of you, but the rule that builds the next copy stays the same, so the form can break again on the next cached visit. After each change, run the same signed-out visitors through the contact page and compare how far each one got. Repeat the check after every plugin update, too.