Fix your contact form after exporting WordPress to static HTML

Published 2026-07-15

Exporting a WordPress site to static HTML — with a plugin like Simply Static, WP2Static, or Static HTML Output — is a good move if you're tired of paying for PHP hosting, patching plugins, or dealing with WordPress uptime for a site that barely changes. The export process handles pages, posts, and most of the theme's assets without much drama.

Your contact form is the exception. Contact Form 7, WPForms, Gravity Forms, Ninja Forms — all of them work by hooking into WordPress's PHP request lifecycle: the plugin needs a live PHP process to validate the submission, send the email, and store the entry. A static export has no PHP process. What actually ships in your exported HTML is either a form that posts to a URL that no longer exists, or in some cases the form markup gets stripped out of the export entirely because the plugin renders it via a shortcode the static crawler can't resolve. Either way, the form is decorative until you replace it with something that doesn't need a server behind your site.

To be direct about scope: SubmissionBuddy doesn't have a WordPress plugin, and this isn't a "keep Contact Form 7 and add SubmissionBuddy underneath it" migration. Contact Form 7 is a PHP plugin — it has no static-export mode. The fix is to delete the plugin-rendered form and put a plain HTML form in its place, one that posts directly to an external endpoint instead of back to your (now nonexistent) WordPress backend.

Step 1: Find where the form used to render

If you used Contact Form 7, your page template likely has a shortcode like [contact-form-7 id="123" title="Contact"], either directly in a template file or inserted via the block/classic editor before export. Open the exported HTML file for that page (or the WordPress page/post before you re-export) and find that shortcode or the surrounding markup — that's what you're replacing.

Step 2: Replace it with a plain HTML form

<form action="https://api.submissionbuddy.io/f/your-form" method="POST">
  <label>Name <input type="text" name="your-name" required /></label>
  <label>Email <input type="email" name="your-email" required /></label>
  <label>Message <textarea name="your-message" required></textarea></label>

  <!-- honeypot: hidden from humans; bots that fill it are silently dropped -->
  <input type="text" name="_honeypot" style="display:none" tabindex="-1" autocomplete="off" />

  <!-- where to send the visitor after a successful submit -->
  <input type="hidden" name="_redirect" value="https://yoursite.com/thanks/" />

  <button type="submit">Send</button>
</form>

Get an endpoint first (free, no credit card) and swap in your form slug. Field names are entirely up to you — there's no schema to configure, so you can keep the same field names your Contact Form 7 template used (as above) or rename them to whatever's clearer; nothing on SubmissionBuddy's side needs to match.

If you re-export with Simply Static after making this change in WordPress (editing the page template or the block directly), the plain <form> tag passes through the static export untouched, because it's just HTML — there's no PHP shortcode left for the export process to choke on.

Step 3: Re-export and verify

Run your static export again, open the generated page, and submit a test entry. You should land on your thank-you page (from the _redirect field) and see the submission appear in your SubmissionBuddy dashboard within a few seconds.

What happens after someone submits

The submission is written to durable storage before anything else happens to it — no PHP process, no database connection from your static host, none of the moving parts Contact Form 7 needed. From there it flows through independently retryable stages: a database write (so it's searchable in your dashboard) and an email notification to whoever used to get your Contact Form 7 notification emails. A hiccup in the email step doesn't lose the submission — it retries automatically.

Spam handling replaces what Contact Form 7's Akismet integration used to do: the _honeypot field above silently drops bot submissions (SubmissionBuddy still returns a normal-looking success, so the bot doesn't learn it failed), and per-IP and per-form rate limiting are on by default on every plan. Paid plans can add an invisible, self-hosted CAPTCHA if a plain honeypot isn't cutting it.

What you lose, honestly

Contact Form 7's conditional fields, file-upload attachments, and multi-step forms all depended on PHP running your logic server-side. A static form posting to SubmissionBuddy doesn't replicate any of that — SubmissionBuddy's endpoint accepts JSON, form-urlencoded, and multipart text fields, but it does not accept file uploads at all. If your Contact Form 7 setup relied on visitors attaching files, that capability doesn't survive the move to static, and this integration won't bring it back. For a straightforward name/email/message contact form — the overwhelming majority of Contact Form 7 installs — the swap above covers it completely.

The free tier

Checked 2026-07-15 against current Simply Static / static-export plugin behavior and Contact Form 7's PHP-dependent architecture. Code samples verified against the live SubmissionBuddy API the same day.