Add a Working Contact Form to an AI Website

A contact form works only when a submitted message reaches a receiver you control and you can verify the result. A visible form, green success message, or browser POST request is not enough. On a static site, first choose a supported form handler on your existing host or an existing backend. Then test browser validation, backend receipt, owner notification, abuse controls, and failure states as separate steps.

This guide starts with a generated static page. For form migration, see the builder migration guide.

Where will the submitted data go?

Trace the current form before changing it. Look at the <form> element: action, method, and each control's name. If there is no action, a form normally submits to its current page. If JavaScript calls preventDefault() but never sends data, it is only a visual interaction. If it shows "Thanks" before checking a server response, it can falsely report success.

MDN explains that a form is a request to a server and that its action names the destination in Sending form data (accessed 2026-09-23). Choose a receiver before you ask an agent to add UI. A static file host does not automatically provide an inbox. You might already have host-managed forms, or you might own an endpoint that validates and stores messages. Do not place an email-service secret in client-side JavaScript. Do not add a paid service only because a generated template names one.

For a concrete example, suppose the site is already hosted on Netlify. Enable form detection in the site's Forms settings. Add the static form below to the deployed HTML. Its form-level name="contact" identifies it in Netlify; each field also needs its own name. Netlify scans the built HTML during deployment and injects a hidden form-name field. The native form uses Netlify's default success page, so it needs no JavaScript or custom action. This is host-specific and not live-tested here. Check your plan and usage first. See Netlify form setup (accessed 2026-09-23).

What should the first form contain?

Keep it small: name, email, message, and a submit button. This is a complete form element for a static HTML page on an existing Netlify site; place it in that page's <main> and keep the site's privacy notice nearby:

<form name="contact" method="POST" data-netlify="true">
  <label for="contact-name">Name</label>
  <input id="contact-name" name="name" required maxlength="100">
  <label for="contact-email">Email</label>
  <input id="contact-email" name="email" type="email" required maxlength="200">
  <label for="contact-message">Message</label>
  <textarea id="contact-message" name="message" required maxlength="2000"></textarea>
  <button type="submit">Send</button>
</form>

Do not copy this Netlify marker to another host and expect delivery. Do not call this a working form until a deployed test submission appears in the Forms tab. If JavaScript renders the form only after page load, Netlify's static scanner needs a matching static HTML form; see its JavaScript form setup (accessed 2026-09-23).

The browser can catch empty fields and malformed email addresses with required and type="email". It improves the visitor's experience, but it is not a security boundary. A client can send a direct request that bypasses HTML validation. Validate expected fields, type, length, and allowed values again at the server or host handler. MDN's input validation guidance makes this distinction clear (accessed 2026-09-23).

Ask an agent to name the receiver, accepted fields, storage location, and success condition. If it cannot, do not accept its "working form" claim.

How do you prevent duplicate or abusive messages?

Keep the normal submit path usable without a puzzle. Add the spam controls your handler supports, such as a honeypot, rate limit, or verified-spam filter. A honeypot alone is not a guarantee. Limit message length on the server and avoid public logs with full message content. If you use cookies or authentication, review cross-site request protection. A hidden client-side token is not a secret.

The sample uses native submission and Netlify's default success page. For a JavaScript-enhanced form, prevent repeat sends, keep the message on failure, and show a retry path. Storage and email notification remain separate delivery checks.

What exact test proves delivery?

Use a unique test marker such as FORM-TEST-2026-09-23-A. Submit it from the deployed page, not only localhost. Record the URL, time, and marker. Find it under Forms > contact in Netlify. If email notification is configured, verify the same marker in the owner inbox and spam folder. The notification docs explain that optional step (accessed 2026-09-23). This marker is test data, not a real lead.

Run negative tests too. Try a blank field and malformed email. Test an invalid or oversized request in a local fixture or staging handler; the HTML limit alone does not prove server validation. Check the response to a failed network request and a repeat submission. Do not stress-test a live vendor without permission.

No live Netlify submission was made for this article. Backend receipt, spam handling, and inbox delivery remain untested. The markup follows official setup docs; only your deployed receipt and inbox checks can establish delivery.

What is the launch decision?

Publish only after the deployed receiver shows the test marker and, if required, the owner gets the notification. Record who monitors the inbox and how quickly the team should respond. If delivery is not verified, keep a working existing contact route visible instead of presenting a dead form.

The AI with your website page can help prepare a scoped form-change prompt. It cannot connect a receiver by itself. Figment's AI editor access page describes an early-access editor for a separate imported static copy. That copy does not transfer the original site's forms, checkout, or backend. Do not point a new form at a Figment copy unless you have separately verified its destination and delivery.

Sources and access date

• Netlify Forms setup, submissions, and notifications, accessed 2026-09-23. These document the handler, form name, stored submissions, and optional email alert.
• MDN input validation, accessed 2026-09-23. Browser checks do not replace server validation.