AI agent readiness: 332 of 432 email, phone and password fields carried no autofill token

What does AI agent readiness mean for a form field?

It means the field states its own purpose in a way a machine can resolve without guessing from the layout. The HTML standard reserves one attribute for that, autocomplete, and defines a table of 54 field names it may carry: name, given-name, family-name, email, tel, street-address, postal-code, cc-number, one-time-code and the rest. The standard says the attribute can be used to hint to the user agent how to, or indeed whether to, provide such a feature, and that where a field name is present the user agent may store the control's data, and may offer previously stored values to the user. That text is in the autofill section of the form control infrastructure chapter, at html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofill, written as plain text here because this site links only registered hosts.

Mozilla's reference puts the same thing in operational terms. Its page on the autocomplete attribute, last modified on 27 August 2026, says the attribute lets web developers specify what if any permission the user agent has to provide automated assistance in filling out form field values, as well as guidance to the browser as to the type of information expected in the field. Two separate things are being granted there: permission to help, and a description of what the field holds. A page that omits the attribute withholds the description. A page that sets it to off withholds the permission as well.

There is also a conformance requirement attached to it. Success Criterion 1.3.5 Identify Input Purpose in WCAG 2.2 is Level AA, and it requires that the purpose of each input field collecting information about the user can be programmatically determined when the field serves a purpose on the published Input Purposes list and the technology supports identifying the expected meaning for form input data. The W3C page states that the list borrows from the HTML specification's autofill definitions. So the attribute is not an optimisation somebody invented for agents. It predates the agents, it has a conformance level, and the field names an agent would need are the field names a screen reader needed first.

One limit belongs here rather than at the end. No agent was run against any site in this measurement. Nothing below observes what ChatGPT, Claude or any browsing agent does with an autocomplete attribute, because that is not a thing a scanner can see from outside, any more than it could see what a crawler did with the prose it was served. What was measured is what the page declares, which is the half of the exchange the site owner controls.

How many of 1,419 sites gave a crawler a form to read?

The method was one GET of robots.txt per hostname and then, where the file left a route in, one GET of the home page, both as LantadBot/1.0 with redirects followed and a twenty second timeout. Of the 1,419 hostnames, 1,108 answered robots.txt with a 2xx status, 1,100 of those a plain 200. 224 answered a 4xx, which RFC 9309 says imposes no restrictions on a crawler, and 57 answered a 5xx, which the same specification tells a crawler to read as a complete disallow. 30 failed at the transport before any status existed.

Resolving the site root for the token LantadBot with the matcher in core/src/robots.ts, the one this site's robots.txt tester runs, left 69 hostnames with no route to the home page. 57 of those are the 5xx group, which never refused anything and simply could not be read, and 12 were closed by an actual rule in a parsed file. The scanner's own token and the reason it is honest about itself are set out on the bot page. The remaining 1,320 were asked for a page: 1,073 answered a 2xx and all of them were HTML, 244 answered something else, 224 of those a 403, and 3 failed at the transport. A 403 to a named scanner on a site that serves a browser is a familiar shape in this corpus, measured directly when 103 of 1,089 sites served an unknown bot and refused GPTBot.

Of the 1,073 pages read, 562 carried at least one form element and 511 carried none at all. 644 carried at least one form control, which is more pages than carried a form, because 1,234 of the 4,014 controls sat outside any form element entirely. On 134 of those 644 pages the only controls were search boxes, so a fifth of the pages with anything to operate offer nothing to fill in but a query. That is worth holding next to the finding that 84 of 1,091 home pages offered a crawler no path at all: the home page is a thin surface for this kind of question, and what it holds is mostly signup, search and login.

How many fields named their own purpose?

367 of the 4,014 controls carried one of the 54 autofill field names. 3,151 carried no autocomplete attribute at all, 490 carried only on or off, which grants or withholds permission without describing anything, and 6 carried a value that is not a field name: the word disabled on clinicbarcelona.org, and an empty value on canonical.com and four times on dishoom.com. Counted by page rather than by control, 87 of the 644 pages with a control carried a field name somewhere and 557 carried none.

The 367 do not mean what the raw count suggests, and this is the part of the measurement that would mislead if it were reported as a trend. 209 of them are a single token, one-time-code, and they come from 8 hosts: getdianahr.com, daytona.io, trueform.agency, nocodeweek.io, abcblind.com, leapingai.com, crazycreative.design and framer.com. Every one of the 209 is a plain text input, every one carries a name attribute, not one carries a label or a placeholder, and they arrive in multiples of 11 per page, from 11 on framer.com itself to 44 on getdianahr.com, so these are one component rendered repeatedly rather than 209 decisions. All 8 hosts sit in the Framer, no-code, single page application or SaaS marketing strata of the platform frame, which is exactly the concentration that made a per-platform guide like the Framer fix page worth writing. Set those aside and 158 field names remain across everything else.

What the 1,073 pages collectively used was 14 of the 54 names available: current-password, email, family-name, given-name, name, new-password, one-time-code, organization, organization-title, postal-code, street-address, tel, url and username. Nothing in the corpus declared a credit card field, a birthday, a country or any of the address-line names. That is not a complaint about the sites. It is a statement about what a home page is for, and it is the same reason the structured data on these pages tends to declare an organisation and little else. A vocabulary is only used where the page has something to say with it.

The fields whose own type says what they collect

Counting every control against the autofill list is unfair to the list, because most controls are not asking for a fact about the person. A checkbox consenting to marketing, a radio choosing a room size and a search box are all outside what the 54 names cover, and 848 checkboxes and 382 radios sit in the full population. So the honest cut is the set of controls whose own input type already states the kind of datum they collect and for which the list holds an exact name: 432 controls on 233 pages, being 329 of type email, 55 of type password and 48 of type tel.

100 of those 432 carried a field name. 290 carried no autocomplete attribute at all, 40 carried on or off, and 2 carried an empty value, which is 332 fields that state the type of the datum in one attribute and decline to state its purpose in the other. Only 69 of the 233 pages carried a field name on any such control. Password is the sharpest case: 12 of 55 password controls carried current-password or new-password, and the six hosts responsible are nowhabersham.com, thehill.com, browserstack.com, eurostar.com, rwandair.com and dcu.org. For telephone fields the six are thewireguyelectric.com, calltree.ai, runcopycat.com, canonical.com, nationwide.com and statefarm.com.

Four named cases show the range. nato.int served 9 email and password controls, every one of them properly labelled and not one of them carrying a field name, which is a site that did the accessibility work and skipped this attribute. quantamagazine.org served 11, one of them with autocomplete set to off. amtrak.com set off on four separate password fields, and patsnap.com set off on both its email and its password field, neither of which carries a label element or an aria-label, so the only text describing either one is a placeholder. 15 of the 432 controls are in that state across 9 hosts, homedepot.com and cambridgeday.com among them, and all 15 fall back on a placeholder, so none of them leaves a machine with nothing at all. bergfreunde.de is the counterexample worth naming: email on both of its email fields, and nothing on the password beside them.

Reading autocomplete off as hostile would be the wrong conclusion and this post does not draw it. A site may have set it years ago for reasons that had nothing to do with machines reading pages, and the HTML standard itself defines off as a legitimate value, meaning that the user agent should not remember the control's data and should not offer past values to the user. The finding is narrower and it is about information rather than intent: on 332 of 432 fields there is no published description of the field's purpose in the markup, so anything operating the form has to infer it, and inference is where answer engine optimization work usually goes wrong.

Was the field labelled at all?

Better than the token picture, and with a specific floor under it. 2,011 of the 4,014 controls were named by a label element whose for attribute matched the control's id. A further 531 sat inside a wrapping label element, 353 more carried an aria-label and 7 more an aria-labelledby, giving 2,902 controls with a name a machine can read. 31 had only a title attribute. 443 had only a placeholder, and 638 had none of those things at all. On 113 of the 644 pages with a control, not one control was labelled.

A placeholder is not a label, and that is not a style preference. Mozilla's page on the placeholder attribute, last modified on 14 October 2026, states that the placeholder must not be used instead of a label, and that using one for a prompt harms usability and accessibility because it disappears once the field holds a value. For a machine reading the document the objection is simpler: a placeholder is an example of the expected input, and 443 controls here offer an example of the answer in place of the question.

The failures concentrate by control type rather than spreading evenly. Checkboxes and radios are nearly all named, 829 of 848 and 369 of 382, because the visible text beside them is usually a real label element. Search inputs do well at 238 of 282. Plain text inputs are the problem at 787 of 1,443 labelled, with 368 carrying nothing readable. Select elements are worse proportionally, 244 of 376 labelled with 126 carrying nothing, and number inputs are the worst in the set at 7 of 42. That ordering is familiar from the way 379 of 1,066 home pages declared no main landmark and from the finding that 3,291 of 7,124 custom elements arrived with no text: the markup that a person never sees is the markup that goes unwritten, and the components a framework generates inherit whatever its template decided once.

The submit control is the one part of a form this corpus gets right. 2,073 submit buttons and inputs were found, and 2,000 carried a name from their own text, a value attribute, an alt, an aria-label, an aria-labelledby or a title, leaving 73 with nothing. That is a better rate than the fields themselves, which makes a certain sense: a button with no words on it looks broken to a person, and an unlabelled input next to visible design text does not.

Where does the form go?

The last thing a machine reading a form needs is the destination, and on a large minority of these pages the document does not contain one. 458 of the 1,532 form elements declared no action attribute, which means the submission exists only in JavaScript that the page loads, and 246 of the 562 pages carrying a form carried at least one such form. That pattern appeared in all 18 strata of the corpus, from 25 pages each in the SaaS, ecommerce and finance frames down to 1 in the static documentation frame, so it is not a platform artefact the way the one-time-code blocks were. A further 103 forms declared an action on a different host, which is the ordinary shape of an embedded email signup.

For a crawler fetching HTML this is the same class of gap as a fact that only exists after rendering, which this blog measured when 1,344 of 5,669 answer-bearing facts were absent from the HTML a crawler receives. For an agent driving a real browser it is not a gap at all, because the script runs and the handler exists, and that asymmetry is the honest thing to say about it. A form with no action is readable by the thing that executes code and opaque to the thing that does not, which is the opposite direction from most findings here and the same split that made 11 of 271 pages depend on JavaScript for their prose interesting rather than alarming.

It also sits next to a scarcer signal. When this corpus was read for machine-readable agent interfaces, 1 of 1,419 sites published an agent card, and when it was read for the token Anthropic's hosted browsers send, 0 of 1,102 robots.txt files named Claude-Agent. Against that, 100 fields carrying a correct autofill name is not a small number. The infrastructure for agents is mostly absent from real sites, and the part of it that does exist is the part that was built for accessibility years before anyone used the word agent, which is the practical answer to what to do about any of this.

What this measurement does not show

Four limits, and the first is the one that could change the numbers most. Each page was fetched once with no JavaScript executed, so a form a script builds after load is absent from this reading entirely, and some of the 511 pages that carried no form almost certainly have one. The direction of that error is knowable even though its size is not: this measurement can undercount forms and the attributes on them, and it cannot overcount them. The same fetch-once method and its consequences are set out on the methodology page, and what a single crawler-view fetch does and does not contain is what the crawler view tool exists to show directly.

Second, these are home pages. A checkout, a booking flow or a long application form is where the autofill list earns its keep, with its address lines and card fields, and none of that was measured here. What a home page holds is a newsletter box, a search field and sometimes a login, which is why 329 of the 432 typed controls are email inputs. Reading this as the state of forms on the web would be wrong, and reading it as the state of the first form an agent meets is about right.

Third, the corpus is a stratified sampling frame assembled for platform and industry coverage, not a random sample of the web, and the one-time-code blocks are a reminder of what that means in practice: a single platform component can produce more than half of a token count. The frame and how it was built are described in the crawlability study, and the general caution applies here as it does to every corpus figure on this blog.

Fourth, Lantad does not score any of this today. The scanner grades access, prose parity, structure and schema, and no part of the AI visibility score it publishes looks at a form control. This run used the shipped robots matcher and the same HTML parser the extractor uses, with a form level tally written for this measurement and nothing else, which is the same arrangement under which 429 of 2,982 named accordion panels were found missing from the HTML. Whether it should be scored is a question for the weights rather than for a post, and the case against is sitting in the data: on 411 of the 644 pages with a control there is no field of the kind this post counted at all, and the only thing to fill in is a search box, a checkbox or a text box whose purpose no published list names.