Can a Static Website Have a Working Contact Form?

What happens after someone clicks Send?

Separate the customer-facing form from the system that handles submissions. A typical inquiry follows this route:

1. The visitor fills in the page. Use a name, reply address, and the details needed to respond. Avoid collecting information you will not use.
2. The browser submits to an endpoint. The form needs a real destination and an agreed request format.
3. The server checks the submission. Validate required fields, size limits, and anti-spam results before processing the message.
4. The server sends or saves it. This might create a record and send a notification using an email provider.
5. The page shows the actual result. Clear the form only after the endpoint confirms acceptance; show a useful retry option if it fails.

A successful endpoint response and inbox delivery are separate events. Email can still bounce or be filtered after a provider accepts it. Decide who checks delivery failures and how an unanswered inquiry will be found.

Should you use a form service or a Pages Function?

A hosted form service can be a practical choice when you want fewer parts to maintain. Check its allowed domains, submission limits, spam controls, delivery history, data handling, and recurring cost before connecting it.

A Pages Function gives you more control over validation and routing but adds code and operational responsibility. Cloudflare documents Pages Functions as server-side functionality that can run alongside a Pages site. Your static pages can remain static while the submission endpoint does the protected work.

A mailto link is useful as an alternative contact method, but it opens the visitor’s email application rather than operating a website submission service. Do not count opening that link as a delivered lead.

Where do email keys and spam checks belong?

Email-provider API keys and anti-spam secret keys belong in the server environment. Never place them in HTML, browser JavaScript, an AI prompt pasted into public content, or a committed configuration file. A private GitHub repository does not hide values that get bundled into the deployed website.

Use the platform’s secret bindings for server credentials. Keep test and production settings separate, and give each credential only the access needed for its job.

If you use Turnstile, the visible widget is only one part of the check. Cloudflare requires server-side token validation through Siteverify. Reject missing or invalid verification results; do not trust a browser field that says the check passed.

Also enforce sensible field and request-size limits on the server. As MDN’s form validation guidance explains, browser checks help visitors fix mistakes but can be bypassed. Avoid logging the complete contents of every inquiry, especially when messages may contain private information.

Why does the form say sent but no email arrives?

First identify which stage has evidence. Did the browser make the request? Did the endpoint accept it? Did the email provider accept the message? Did the receiving mailbox deliver, filter, or reject it? These are different questions.

• If no network request occurred, inspect the form’s submit handler and destination.
• If the endpoint returned an error, inspect its configuration and server logs without exposing secrets.
• If the provider rejected the send, check the verified sender domain and provider error.
• If the provider accepted it, check delivery events, bounce information, spam folders, and recipient rules.

With providers such as Resend, use a verified sending domain and its required DNS records. Put the visitor’s address in the supported reply-to field rather than impersonating them as the sender. See Resend’s domain verification documentation.

What should a business owner test before launch?

1. Send one valid test and verify both the on-screen response and the actual destination.
2. Leave a required field blank and enter an invalid email address. Confirm the visitor gets understandable errors.
3. Test an intentional server failure in the test environment. The page should not claim success or erase the visitor’s message.
4. Try repeated clicks. Check that the interface does not create an avoidable burst of duplicate inquiries.
5. Verify anti-spam checks on both the preview and production hostnames.
6. Confirm a staff member knows where inquiries go and how to check a reported missing message.

Use synthetic information during testing. If an inquiry involves sensitive documents, payments, or private customer records, scope an appropriate system instead of extending a basic email form casually.

How does this fit into an AI-built website?

Ask your AI assistant to explain the endpoint, credential storage, validation, error states, and evidence of delivery before calling the form finished. Review the implementation and test the result yourself. An attractive form mockup is only the starting point.

The BUILD • PUBLISH • OWN IT guide covers a protected contact form and Resend setup within its static-site workflow. For the wider launch, use the AI-built website testing checklist. Once delivery works, the lead follow-up guide covers assigning and responding to the inquiry.