An AI Agent Just Filled Out Your Contact Form. Did Anything Break?

On June 3, 2026, Cloudflare's CEO posted that automated traffic had passed human traffic on the web for the first time. Cloudflare Radar, which sees roughly a fifth of all websites, now puts automated requests at 57.5% of HTML traffic against 42.5% from humans. Agent requests specifically are up more than 1,700% year over year.

Most of that is crawling. Some of it is not.

Some of it is a person sitting in ChatGPT Atlas or Perplexity Comet who typed "find me three web developers in my area and ask them for a quote," and then went to make coffee while the browser did it. That request lands in your inbox looking like a lead. Because it is one. There is a human at the end of it with a budget and a problem.

So the question about AI agents using websites is not philosophical any more. It is operational. When one of those agents walks through your contact form, does the form work? Do you find out? And do you accidentally throw the enquiry away?

Bots Passed Humans, and Some of Them Are Carrying a Wallet

The important split is not bot versus human. It is who gave the instruction.

Cloudflare now draws this line explicitly. Its bot categories separate Search (collecting and indexing content to answer questions later), Training (taking content to train a model), and Agent (automated behaviour acting in real time on a person's behalf). That third one is the new thing, and it is the one that can buy something.

The payment networks have already noticed. Visa folded the Trusted Agent Protocol into Visa Intelligent Commerce, Mastercard built the same idea into Agent Pay, and American Express committed to it for its agentic commerce programme. All of it sits on top of Cloudflare's Web Bot Auth work. Nobody builds a payment authentication layer for traffic that has no money behind it.

I have not measured this on a client site. I want to be straight about that. I do not have a "we saw 4% of enquiries come from agents" number, and if someone hands you one, ask hard how they got it. What I have is the same thing you have: a new category of visitor that clearly exists, that is growing fast by every public measure, and that most small business websites were not built to handle.

You Probably Cannot Tell Which Visits Were Agents

Here is the part that annoys me most. You cannot cleanly identify AI agents using websites you own, and that is not your fault.

Atlas and Comet are both Chromium. Under basic fingerprinting they look almost identical to a generic Chrome install. Gemini in Chrome and Copilot in Edge are worse, because they are not separate browsers at all, they are features inside a browser your visitors already use. There is no clean user agent string to filter on. Analytics will show you Chrome, and it will be telling you the truth.

There are hints. Server-side, Atlas sessions often carry CFNetwork and Darwin patterns in the user agent because of how OpenAI's networking layer wraps outbound requests. Stripped Chromium builds miss extension manifest entries and Web Speech API voice lists that full Chrome exposes. You can search GA4 for "Atlas", "Comet", "PerplexityBot" or "CFNetwork" in the browser dimension, and check referrers from perplexity.ai and the OpenAI domains.

But those are hints, not identification. Roughly 70% of AI-adjacent traffic arrives with no referrer at all, which is why so many people describe it as dark traffic. If your plan depends on knowing exactly which visits were agent-driven, the plan does not work yet. Build for the case where you cannot tell.

Cloudflare Changed the Defaults in September. Check Yours.

On September 15, 2026, Cloudflare's new crawler defaults kicked in. Training and Agent traffic is now blocked by default on pages that display ads, while Search stays allowed. This applies to new domains, new customers, and every existing customer on the free tier. Paid existing customers keep their old settings unless they opt in.

Read that again if you are on the free tier. The Agent category is blocked by default. That is the category that includes something acting in real time on a person's behalf.

For a publisher covered in ads, that default is probably right. Cloudflare also rebranded Pay Per Crawl to Pay Per Use, with Ceramic.ai paying publishers when content appears in results and You.com paying when an agent accesses premium content, so there is a real business reason to hold the line.

For a fifteen-page service business site with a contact form and no ads, the calculation is different. You are not selling content. You are trying to get enquiries. Go and look at what your settings actually do right now, because the defaults were chosen for a different kind of website than yours. I wrote about the other side of this problem in AI Bots Are Crawling Your Website to Death. Here's How to Stop Them., and the tension is real: you want the scraper gone and the shopper through. Those are currently hard to separate.

The emerging fix is Web Bot Auth, an IETF draft that applies HTTP Message Signatures (RFC 9421) to automated traffic so an agent can cryptographically prove who it is instead of asserting it in a header. Cloudflare's signed agents programme launched with ChatGPT agent, Goose from Block, Browserbase and Anchor Browser, plus Cloudflare's own Browser Rendering. That is the right shape of solution. It is also early, partial, and covers a handful of the AI agents using websites in the wild right now.

What Actually Breaks

This is the useful part. Agents read your page through three channels: screenshots, raw HTML, and the accessibility tree. Anything that only exists in one of those, or only exists after a mouse does something, is a failure point.

Turnstile and friends. This is the big one. Turnstile scores browser behaviour, device integrity and interaction patterns in the background, before any visible challenge. Reports from people running agent mode describe the challenge failing even when a human takes over and clicks it manually, because the browser environment was already flagged. Your CAPTCHA is not asking "are you human," it is asking "does this session look normal," and a user-driven agent does not. A real customer with a real budget gets a hard stop and no explanation.

Honeypot fields. A classic hidden input named website or phone2 catches dumb spam bots beautifully. It also catches a language model that reads the DOM, sees a field called website, and helpfully fills in the company URL because it is being thorough. Field-level traps assume the filler is stupid. This one is not.

Multi-step wizards. Every step is another place to lose state, another dynamically injected field, another validation rule that fires on blur. Simple forms survive. Five-step qualification funnels with conditional logic do not.

Hover-revealed and scroll-revealed fields. If a field only renders after a mouseover or after an intersection observer fires, it may as well not exist. Same for elements smaller than a few pixels or sitting under a transparent overlay.

JavaScript-gated submit buttons. A <div onclick> styled to look like a button is invisible as an action. A real <button> is not.

Rate limiting. Agents move fast and do not pause. A form that allows one submission per IP per thirty seconds is fine for humans and reads as an attack from something that filled six fields in two seconds. Time traps that reject anything completed in under two seconds have the same problem, and they were a genuinely good anti-spam technique until this year.

Consent walls. The agent will click something. It will not necessarily click what the user would have clicked. If your cookie banner gates the form behind a choice, you now have a consent record that nobody meaningfully gave.

If you are running a static site, How to Add a Contact Form to a Static Astro Site (Without SSR) walks through a setup with few enough moving parts that most of the list above simply does not apply.

Is It a Lead or Is It Spam? Nobody Has Clean Numbers Yet

The honest answer to "do agent-filled enquiries convert" is that I do not know, and neither does anyone quoting you a percentage. The behaviour is roughly a year old at scale. There is no reliable identification, which means there is no reliable cohort, which means there is no reliable conversion rate. Anyone selling you one built it on guesswork.

What you can do is stop optimising your filters for the wrong enemy. LLM-written spam now arrives through the visible form, correctly filled, grammatical, and personalised. It looks exactly like a good enquiry. Meanwhile a genuine agent-assisted enquiry from a real buyer may trip three of your defences at once.

So change what you filter on. Content and intent, not mechanics. Does the message reference something specific about your business that a scraper would not know? Is there a working phone number or a domain that resolves to a real company? Does a reply get answered by a human within a day? That last one is the cheapest test there is, and it works regardless of what filled the form.

Set the bar at "reply to everything that is not obviously junk." Losing one real customer costs more than reading fifty bad emails. My error tracker taught me a related lesson the hard way in My Error Tracker Blew Up at 2 AM. The Attacker Was an SEO Tool.: the thing that looks like an attack is often just software doing its job.

The Boring Good News: This Is Just Accessibility Work

Here is the insight that makes the whole topic tractable.

Agents read the accessibility tree. That is the same browser-native layer of roles, names and states that assistive technology has used for twenty years. OpenAI's own publisher documentation says Atlas uses ARIA tags, the same labels and roles that support screen readers, and points publishers at WAI-ARIA best practices. Google's guidance for agent-friendly sites says the same thing in different words: use real <button> and <a> elements, link labels to inputs with for, keep layouts stable, avoid hover-only interactions, keep interactive elements visible.

Read that list again. It is a WCAG audit. Every single item.

Which means you do not need a new discipline, a new vendor, or an "agent readiness" consultant. You need the accessibility work that has been on your backlog since 2023. Missing labels, unlabelled buttons, div-soup navigation and unclear focus states break a screen reader and an agent in the same way for the same reason. Run our Accessibility Checker against WCAG 2.2 and treat the output as your agent compatibility report, because it very nearly is.

That is a rare thing in this industry: two problems, one fix, and the fix was already worth doing on its own merits.

The Checklist to Run This Week

Half a day, no new tools. This is the whole practical response to AI agents using websites, and none of it is exotic.

1. Open your main contact form in ChatGPT Atlas or Perplexity Comet with agent mode on and tell it to submit an enquiry. Watch where it stops. This single test tells you more than any article, mine included.
2. Check your Cloudflare bot settings. Find out whether the Agent category is blocked on your site. Decide deliberately instead of inheriting a default meant for ad-funded publishers.
3. Audit the form markup. Real <label for> on every input. Real <button type="submit">. No <div onclick>. Correct input types and autocomplete attributes.
4. Kill hover-only and scroll-only reveals anywhere in a conversion path.
5. Rename or remove your honeypot fields. If the field name reads as a legitimate thing to fill in, an LLM will fill it in. Prefer server-side scoring over a single hidden trap.
6. Loosen the time trap. A two-second minimum submission time is now a customer filter, not a spam filter.
7. Check rate limits on the form endpoint. Make sure a fast, legitimate submission is not treated as abuse.
8. Reconsider the CAPTCHA. If it is guarding a low-value contact form rather than a login or a payment, the enquiries it costs you may already outweigh the spam it stops.
9. Collapse multi-step forms to one step where you can. Every step is a failure point for humans too.
10. Run the accessibility audit and fix what it finds. That is most of the work.

Want the printable version? Download the complete agent-readiness audit as a PDF — 9 pages, 60+ checks, no login required.

What Not to Do

Do not block agents wholesale. That is the mistake I expect to see most this year, and it is expensive in a way that never shows up in a report, because nobody sends you an email to say they could not send you an email.

Do not build agent-only shortcuts, hidden endpoints, or a separate simplified form for machines. You will maintain two paths and one of them will silently rot.

Do not hire anyone selling "AI agent optimisation" as a new service line before you have run an accessibility audit. The audit is cheaper and it is most of the answer.

And do not roll this out on your own team without thinking it through. Letting agents use your site is a different question from letting your staff run agents inside your browser sessions, which is a genuine security problem I covered in Don't Let Your Team Install an AI Browser Yet.

If you want to go further than not breaking, the opt-in path is WebMCP, which lets AI agents use your website rather than just read it. That is where this ends up eventually. But WebMCP is a project. Fixing your form labels is a Tuesday.

I do not know how much of this matters yet in raw numbers, and I would rather say that than make one up. What I do know is that the cost of being ready is low, the work is already justified for human visitors, and the downside of not being ready is a customer who quietly went somewhere else.

If you want someone to run that checklist against your site and tell you what is actually broken, that is the kind of work I do. One person, no upsell, honest answer either way.