Skip to content
Rescue 404
Rescue

Website Forms

WordPress Form Not Submitting

Intermediate Risk: medium

Last reviewed

Hosting access may not be needed Database access usually not needed

Direct answer

A WordPress form that will not submit usually fails because the browser never completes the AJAX or REST request (script conflict, caching, or a blocked endpoint), a CAPTCHA or spam rule rejects the attempt silently, or field validation stops the send — open the console and Network tab first, then clear cache and check security rules before rebuilding the form.

This guide covers generic WordPress front-end forms — WPForms, Gravity Forms, Formidable, theme/builder forms, and similar — when the submit control does nothing, spins forever, or errors before a successful completion. It is distinct from the Contact Form 7–specific guide and from “form submitted but email never arrives,” which is a mail-delivery problem. Confirm whether the request leaves the browser before you change SMTP or notification settings.

Intermediate

Key facts

Verifiable numbers and definitions — each claim links to its source.

  • WordPress AJAX form handlers must POST to wp-admin/admin-ajax.php with an action parameter; hard-coded URLs break when the site URL or install path differs. (WordPress AJAX in plugins)
  • WordPress documents sending a nonce with AJAX requests that can change data so the server can reject forged or cross-site form submissions. (WordPress AJAX in plugins)
  • Pretty permalinks rely on server rewrite rules; broken permalinks can 404 REST or form endpoints that plugins use after submit. (Using Permalinks)

What the error means

Most modern WordPress forms do not do a classic full-page POST. Clicking Submit runs JavaScript that sends the payload to admin-ajax.php, a REST route under /wp-json/, or a plugin-specific endpoint, then paints a success or error message in place. “Not submitting” can mean the click handler never runs (theme/plugin script conflict, deferred/minified JS broken, or a caching layer serving a page with a stale nonce), the request fires but returns 403/406/500 from a firewall or security plugin, CAPTCHA/honeypot logic rejects a real visitor without a clear message, or client-side validation blocks send on a field the visitor believes is valid. Email delivery is a later stage: if the Network tab never shows a successful response, fixing SMTP will not help. The browser console and the failed request’s status and body are what separate a front-end break from a server rejection.

Common symptoms

  • Submit button does nothing — no spinner, no message, no page change
  • Button shows a loading or “Please wait” state indefinitely
  • Inline validation error appears on fields that look correctly filled
  • Works for admins or on staging but fails for logged-out visitors on the live site
  • Console shows JavaScript errors around jQuery, fetch, axios, or the form plugin’s script handle
  • Network tab shows the submit request missing, canceled, or returning 403/429/500
  • Fails only on mobile, only behind certain networks, or only when a CAPTCHA widget is present

Most likely causes

  1. 01 JavaScript conflict or broken minification/defer settings preventing the form’s submit handler from binding
  2. 02 Page cache or CDN serving a stale nonce or outdated form markup to logged-out visitors
  3. 03 Security plugin, WAF, or bot fight blocking admin-ajax.php or /wp-json/ form routes
  4. 04 reCAPTCHA/hCaptcha/Turnstile misconfigured (wrong keys, wrong domain, script blocked)
  5. 05 Required-field or format validation stricter than the visible UI suggests (hidden required fields, mask mismatch)
  6. 06 REST API or permalinks broken so plugin REST submit routes 404
  7. 07 Theme or page-builder update changed the form embed wrapper and broke expected markup hooks
  8. 08 Two form scripts or duplicate jQuery copies on the same page fighting for the submit event

What changed before the problem started

  • Caching, optimization, or “delay JavaScript” settings enabled or tightened
  • Security / firewall / CAPTCHA plugin installed or rules updated
  • Form plugin, WordPress core, theme, or page builder updated
  • CDN or WAF (including Cloudflare) challenge or bot settings changed
  • New third-party script (chat, analytics, A/B test) added to form pages

Troubleshooting steps

  1. 01

    Reproduce with console and Network tab open

    Private window, DevTools open, submit once. Note any red console errors and whether a request to admin-ajax.php or /wp-json/ appears. Record status code and a short response snippet. This single test splits “JS never ran” from “server said no.”

  2. 02

    Bypass cache and retest as a logged-out visitor

    Purge page cache and CDN for the form URL, then test logged out. If it only works when you are logged in, stale cache or a cached nonce is a prime suspect — exclude the form page from full-page cache or shorten its TTL.

  3. 03

    Turn off JS minify/combine/delay on form pages temporarily

    Disable those optimizations in the performance plugin (or exclude the form page) and retest. Broken deferred scripts commonly produce a dead submit button with a console error.

  4. 04

    Verify CAPTCHA keys and that the widget script loads

    Confirm site/secret keys match the live domain (www vs apex, https). In Network, confirm the CAPTCHA provider script returns 200. A blocked or wrong-domain CAPTCHA often fails submission without a useful message.

  5. 05

    Check security/WAF blocks on the submit endpoint

    If the request returns 403, 406, or a challenge page, briefly disable the firewall module or add an allowlist for the form’s AJAX/REST path, then retest. Re-enable protection with the allowlist kept — do not leave the firewall off.

  6. 06

    Confirm required fields and hidden fields in the form builder

    Look for required fields hidden by conditional logic, honeypot fields filled by autofill, or phone/email masks that reject valid input. Adjust validation to match what visitors actually enter.

When to stop troubleshooting

Stop DIY changes if the submit request never appears no matter which scripts you exclude, you cannot access WAF/host logs for 403s, the form is the primary lead channel and you lack staging to conflict-test safely, or plugin/theme isolation has not found a culprit. Escalate with console errors, the Network request/response, form plugin name/version, and recent cache or security changes. For Contact Form 7–specific behavior, use that dedicated guide instead.

Information to collect before requesting help

  • 01 Form plugin or builder name and version (WPForms, Gravity Forms, Elementor, theme form, etc.)
  • 02 Exact UI behavior: no reaction, endless spinner, or validation message text
  • 03 Console errors and Network status/response for the submit attempt
  • 04 Whether logged-in vs logged-out, or staging vs live, behaves differently
  • 05 Caching/CDN and security plugins in use, plus recent rule changes
  • 06 CAPTCHA provider and whether its script loads on the page
  • 07 Recent form plugin, theme, builder, or WordPress updates
  • 08 Whether email arrives when a test submission somehow succeeds (to separate mail issues)

How a professional repairs the problem

We reproduce the failure with DevTools to pin the break to client script, blocked endpoint, CAPTCHA, or validation. Then we purge or exclude cache correctly, isolate conflicting scripts, correct CAPTCHA domain/keys, and allowlist the real submit route in security/WAF rules without leaving the site unprotected. We confirm a full successful submission end-to-end — including any confirmation message — and only then touch mail/SMTP if notifications are a separate problem.

Frequently asked questions

Is this the same as Contact Form 7 not submitting? +
Same class of failure, different plugin surface. Use the Contact Form 7 guide when that plugin’s AJAX/integration details matter; use this guide for other WordPress forms or when you are not sure which plugin powers the form.
The form “submits” but I never get email — wrong guide? +
Yes if the success message appears and the Network request returned success. That is delivery/SMTP/spam filtering — see contact form emails not received. Stay here when the browser never completes a successful submit.
Why does it work when I am logged in but not for visitors? +
Logged-in users are often excluded from full-page cache, so they get fresh nonces and scripts while visitors get a stale cached page. Purge and exclude the form URL from cache, then retest logged out.
Should I rebuild the form from scratch? +
Rarely as a first step. Most “dead submit” cases are cache, JS optimization, CAPTCHA, or firewall. Rebuild only after those are ruled out or the form’s own configuration is clearly corrupt.
Can a security plugin cause this even if the rest of the site is fine? +
Yes. Firewall rules often single out admin-ajax.php, wp-json, or POST bodies with links/attachments. The rest of the site can look healthy while every form POST is blocked.
Does fixing submission also fix missing notification emails? +
Not automatically. Submission success and mail delivery are separate stages. Confirm the request succeeds first, then diagnose SMTP/SPF if messages still do not arrive.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

  • You will receive a clear explanation of the likely cause.
  • We will tell you if the issue falls outside our repair scope.
  • No additional work will be performed without approval.
  • A backup should be created whenever access and website condition allow it.
Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form — use Password Pusher (self-destructing link). Prefer a dedicated Rescue 404 admin account, not your personal owner login; if you cannot create one yet, we will add ours after repair.

Written by Josh

Last reviewed

Platform note: Full rescue available for WordPress and self-hosted sites. Wix, Squarespace, Webflow, Weebly, and similar closed builders have very limited backend access — fixes may not be possible. I will tell you honestly before we start.