The honest case for AJAX form submission

Every popular WordPress forms plugin ships AJAX submission as the default. Click submit, the page doesn’t reload, you see a spinner, then a success message slides in. Slick.

But AJAX is a tradeoff, not a free upgrade. And the case for it is weaker than most plugin docs let on.

Here’s when it earns its keep, when it costs you, and what I actually do.

What AJAX gives you

Three real wins:

Submission feels instant. No full-page reload. No re-paint. The user clicks, sees a spinner, sees the result.

Inline error display. “Email is invalid” can highlight the email field instead of redirecting to a generic error page. That’s a UX win.

Form state is preserved. If validation fails server-side, the user keeps everything they typed. No “fill it all out again” misery.

These are real benefits. Don’t dismiss them.

What AJAX costs you

Three real losses, and they show up on every site:

You ship JavaScript to every page that has the form. Even just to handle the submit, that’s bytes. Core Forms keeps it under 4 KB; most plugins don’t.

Analytics tracking gets harder. A traditional form post triggers a page view on the success URL. Google Analytics, Plausible, Fathom, all of them count it for free. With AJAX, you have to fire a custom event, and most setups don’t.

The “thank you” page disappears. Conversion tracking in Google Ads, Meta Pixel, LinkedIn Insight Tag, all of these traditionally fire on the thank-you URL. AJAX submissions need a manual event call. If your developer didn’t wire it up, the conversion never gets attributed. I’ve audited campaigns where 70% of leads were going untracked because of this.

The lazy default that costs money

The lazy default in every forms plugin is “AJAX on, no analytics wiring.” So you get:

• A nicer UX.
• Worse conversion tracking.
• Worse data for ad spend optimization.
• A client who can’t figure out why ROAS dropped.

For a brochure site with no ad spend, this is fine. For anything that runs paid traffic, it’s a real problem.

What I actually run

Core Forms lets you toggle AJAX off per-form. The setting is one click in the form’s settings tab.

• Lead-gen forms running paid traffic — AJAX off. Submit, redirect to a clean /thanks/ page, fire conversion pixels there. Lose 200 ms of perceived smoothness, gain accurate attribution.
• Newsletter signup in a sidebar — AJAX on. The user shouldn’t lose their place on the article they were reading.
• Contact forms on a brochure site — AJAX on. Doesn’t matter, no ad spend to attribute.
• Application forms (jobs, scholarships, apply-to-x) — AJAX off. The user wants to feel that the submission “went somewhere.” A redirect to a confirmation page does that.

That’s not theory. That’s what I actually toggle on each form on each client site.

The hybrid approach

The cleanest setup, if you’re running paid ads, is AJAX submission with a redirect on success.

In Core Forms, you set the success behavior to “Redirect to URL.” The frontend does its AJAX submission, gets a success response, then JS redirects to your /thanks/ page. You get:

• Inline error display (errors don’t redirect).
• The thank-you page for analytics and pixels (success redirects).
• Form state preserved on validation failure.

This is the default I use for any client running ads. The setup is in the form settings tab under “Confirmation.”

What you should not do

Two patterns I see often that you should kill:

1. Showing the success message in a modal that auto-closes. Users miss it. Conversion tracking fires once and dies. The user is left wondering whether their submission went through.

2. Showing the success message inline and leaving the form filled. Users re-submit. Triple-submit. By the time their tenth duplicate hits your inbox, their patience has run out and so has yours.

Either redirect to a thanks page, or replace the form HTML entirely with the success message. Don’t half-do either.

The next step

Audit one form on one site. Open the network tab, submit a test entry, watch what happens.

Did your conversion pixel fire? Did GA register the event? If not, you’ve got the AJAX bug, and it’s costing you tracking on every real submission.

In Core Forms the toggle is at form-level. Pick the mode that matches what the form actually does, not whatever the plugin defaulted to.