Why preview and live are different environments
Every site builder and host gives you two versions of your site. The preview is rendered fresh, often with extra helper scripts, bypasses the CDN cache, and usually runs on a temporary domain. The live site is a published snapshot served through caching layers on your real domain, often behind forced-https and host redirects. A form touching any of those four layers can pass in one and fail in the other — which is exactly the symptom that brings people here.
Cause 1: the live site is serving a cached old page
You fixed the form, hit publish, reloaded — and it still fails. Meanwhile the preview (always fresh) works. The live HTML your visitors get is a CDN-cached copy from before the fix.
- Confirm: incognito window → view-source the live URL → search for your
actionURL. Old value or missing form = stale cache. - Fix: purge the CDN cache (Cloudflare: Caching → Purge Everything; Netlify: Deploys → Clear cache and deploy site; Vercel redeploys are fresh by default). Some builders (Wix, Squarespace) need a republish rather than a save.
- Prevent: after any form change, verify with a cache-busting query string (
?v=2) before declaring it broken.
Cause 2: the form depends on preview-only JavaScript
Builders like Elementor, Webflow, and some AI site generators render forms through scripts that behave differently outside the editor: deferred loading, ad-blocker collisions, or scripts simply not included in the published bundle. If your submit handler lives in a builder script, a live-page JS error kills the submit while the preview (which loads everything) keeps working.
Confirm: live page → DevTools → Console. Red errors on submit, or a Network tab showing no request at all when you click Send, means the handler never ran. The robust fix is a form that works with zero JavaScript: a plain HTML <form> posting directly to an endpoint, with JS added only as progressive enhancement (see AJAX contact forms done right).
Cause 3: the endpoint key is locked to the wrong domain
Form backends (splitforms included) can restrict an access key to specific domains so stolen keys are useless to spammers. If the key was created against staging.example.com, localhost, or the builder's preview domain, production submissions from example.com get rejected — typically a 401 or 403 — while preview submissions sail through.
Fix: in your dashboard, add the live domain (and its www variant) to the key's allowed domains. Details in the 401 error guide and the endpoint docs.
Cause 4: a redirect is eating the POST
Live sites force canonical URLs: http:// → https://, apex → www (or the reverse), trailing-slash normalization. If your form's action points at any non-final URL, the browser follows a 301 before the POST completes — and many browsers re-issue the follow-up request as GET, dropping the body. Your endpoint then sees a bodiless GET and returns 405 or a validation error. Preview domains usually have no redirect layer, so everything works there.
# Check whether your action URL redirects:
curl -i -X POST -d "test=1" http://yoursite.com/api/submit
# HTTP/2 301 ← the POST is being redirected (and the body will be lost)
# Always use the final, absolute https URL:
action="https://splitforms.com/api/submit"The 5-minute systematic debug
- Open the live URL incognito (no cache, no extensions).
- DevTools → Network → submit the form → read the POST status: 301/302 redirect issue · 401/403 key/domain issue · 405 posting to a static page (see the 405 guide) · no request JavaScript issue · 200 but no email → the email leg, covered in form works but no email.
- View-source the live page and confirm the deployed HTML is the version you expect.
- Fix the one layer that failed — then run the full pre-launch form test checklist so the next launch catches nothing by surprise.
FAQ
Why does my form work in preview but not on the live site?
Preview and production are different environments. The four usual causes: the live CDN is serving a cached old version of your page; your builder injects the form script only in preview mode; your form endpoint key is locked to a different domain than the live one; or an http→https or www redirect in front of the endpoint converts or strips your POST. Test the live page in a hard-refreshed incognito window first.
How do I check if it's a caching problem?
Open the live URL in an incognito window with a cache-buster (?v=123), view the page source, and search for your form's action URL. If the source shows the old action — or no form at all — the CDN or builder cache is serving stale HTML. Purge the cache (Cloudflare → Purge Everything, Netlify → Clear cache and deploy) and re-test.
Why does my Webflow form work in the Designer but not after publishing?
Webflow's native forms only submit on published .webflow.io or connected domains, and only when the form block is the native Webflow form element. Custom-embedded forms rely on scripts the Designer preview runs differently. If you swapped to a custom endpoint, confirm the action URL is absolute (starts with https://) — relative actions break depending on the published path.
Can a redirect break my form on the live site only?
Yes. Live sites often force https and a canonical host (www or apex). If your form posts to http:// or to the wrong host variant, the browser follows a 301 first — and many browsers re-issue the redirected request as GET, dropping the body entirely. In preview there is no redirect layer, so it works. Use the exact final https URL in the action attribute.
What is a domain-locked access key?
Form backends can restrict a key so it only accepts submissions from listed domains — anti-abuse protection. If you created the key while testing on staging.example.com or localhost and the live site is example.com, production submissions are rejected (often 401/403) while preview keeps working. Add the live domain to the key's allowed list in your dashboard.
How do I debug a live-only form failure systematically?
In an incognito window: open DevTools → Network, submit the form, and read the POST's status code. 301/302 → redirect problem. 401/403 → key or domain-lock problem. 405 → you're posting to a static page (see the 405 guide). 200 but no email → the email leg, not the form. Then view-source to confirm the deployed HTML contains the form you expect.
An endpoint that accepts plain HTML posts from any domain removes three of these four causes. Get a free splitforms access key.
Related: contact form not working, HTML form not submitting, and fixing CORS errors on form submission.