A services firm's website exists to answer three questions: who are these people, what do they do, and how do I get in touch. A person answers them by reading the about page, skimming the services page and finding the email address. An agent asked to "find a firm that does this and draft an enquiry" asks the same three questions of the raw HTML, and it needs each answer in a form it can check rather than infer. Three checks on the rubric map onto those questions almost exactly: D2, verifiable identity; D3, policies discoverable; and C1, form usability. Between them they are 13 of the 100 points, all three are fixable inside a day, and a firm with no catalogue and no checkout that gets them right has covered most of what an agent will ever ask of it.
We are a services firm ourselves, so the examples below are our own pages, and the scan that reads them is public at /site/agentfriendlyrank.com.
The pages an agent fetches
An agent working on a services enquiry fetches the homepage, follows a link to whatever describes the services, reads the about page to work out who is behind the site, and lands on the contact page to act, all of it from raw HTML. Our crawler follows the same instinct: when it picks the five pages after the homepage, paths containing /about, /company and /contact are preferred ahead of anything else on a site with no pricing or product routes. So the pages that matter to an agent are also the pages the scan is most likely to read, and the fixes below are about putting the answers in their HTML.
Who are these people
Check D2 is worth 4 points, rated Low effort, and splits in two. Two points if any fetched page links to a path containing /contact, /about, /impressum or /legal, or carries any mailto: link. Two points if the JSON-LD on any fetched page contains an Organization type whose sameAs holds at least one URL. The evidence fields are contactDiscoverable, hasOrganizationSchema and sameAsCount. Verifiable identity goes through the mechanism in detail; the point here is what a services firm should put behind it.
For a firm, the identity a program can corroborate is the legal one. Our about page carries a card with the trading name, the legal entity and its form, the tax registration and the registered address, and the Organization node in our sitewide schema says the same things: name, legalName, address, email and a sameAs pointing at one company profile we control. The Organization type has fields for all of this, and a model comparing the schema with the visible page and the profile at the other end of sameAs finds three sources agreeing. An agent asked "is this a real firm" is not asking "is this a large firm"; it is asking whether the claims check out.
What do they do
Nothing in the rubric scores a services page directly, but two checks read it. B2 collects every schema type across the crawled pages and, for a site typed "other", which is what most services firms are, awards three points for any of Article, FAQPage, Service or SoftwareApplication. B3 wants one h1, no skipped heading levels and real main, nav and footer landmarks on every page.
The structure that satisfies both, and that an agent can parse, is one page per service, each with a Service node whose provider points at the organisation's @id, plus an index page that lists them under one h2 each. Ours is built that way: the services index links each engagement to its own page, and each page's serviceSchema() sets name, description, url and serviceType from the same fields that render the visible copy.
Write the description for a reader that will repeat it. A model asked what your firm does quotes what the page says. If the page says "transformative solutions for ambitious organisations", that is the answer it gives. If the page says "fixed-fee audits of websites against a published rubric, with the evidence for each finding", the answer is useful to the person who asked.
How do I get in touch
Check C1 is worth 5 points, rated Medium effort, and is the one that decides whether an agent can act rather than merely read. It audits every form on the crawled pages. Three points scale with the share of inputs that carry a label, whether a label with a matching for, an aria-label, an aria-labelledby or a wrapping label element. One point if no input has the wrong type for its name: a field named email that is not type="email", or one named phone or tel that is not type="tel", costs it. One point if every form has a real submit control, a button with type="submit", a button with no type, or an input type="submit". The evidence fields are forms, inputs, unlabelled, wrongTypes and realSubmit. A site with no forms at all scores three of the five, because nothing was proved either way.
Our contact page is a server-rendered form with four fields: an email input with type="email", a company field, a website field, and a message textarea, each with a visible label, and a button type="submit". It posts to a handler that works with JavaScript off. The website field deliberately uses inputMode="url" rather than type="url", because the browser's URL validation rejects the bare domains people actually type; the type url trap explains that decision. Beside the form, three mailto: links give the general, privacy and security addresses, and the registered address is in an address element. That is the pattern: a form an agent can fill, and a direct address for the agent that would rather hand off to a person. A third-party form loaded by script into a div contributes nothing to either; the scan sees no form, and an agent doing a plain fetch sees no way to write to you.
Which policies
Check D3 is worth 4 points, Low effort. For a site not typed e-commerce it wants an href containing privacy on some crawled page, for two points, and one containing terms, tos or conditions, for two more. It is a link test, which is why the footer is where it is won and lost. Policies agents look for covers the mechanism and the classification.
For a services firm handling client data, a third document earns nothing on the rubric and is worth publishing anyway: a data processing agreement. A prospect's agent asked to shortlist vendors that will sign one can only confirm it if the page exists. Ours is at /dpa, linked from the same footer column as privacy and terms.
Why blocking any crawler is the wrong instinct here
A publisher has an argument for blocking the training crawlers; the text is the product. A services firm has no such argument. Its copy exists to be found and repeated, and the risk runs the other way: an assistant asked about you answers from a directory listing or a review site because your own site refused the fetch. Check A2 is six points, one per crawler, and the six AI crawlers decision matrix gives the services-firm row as allow all six, and A5 then tests whether the edge agrees with the file.
The fixes, in order of effort
| Effort | Fix | Check |
|---|---|---|
| Minutes | A mailto: and a /contact link in the server-rendered footer |
D2 |
| Minutes | Privacy and terms links in the same footer, with those words in the URL | D3 |
| Minutes | Allow all six AI crawlers in robots.txt and at the CDN |
A2, A5 |
| An hour | An Organization node with legalName, address and a sameAs that resolves |
D2 |
| An hour | Labels, correct input types and a button type="submit" on the contact form |
C1 |
| A morning | A Service node per service page, one h2 per service on the index |
B2, B3 |
| A day | Replace an embedded third-party form with one in your own HTML | C1 |
None of this needs a rebuild; most of it lives in the footer and head of a shared layout.
Check your own site
The free scan reports contactDiscoverable, sameAsCount, hasPrivacy, hasTerms and the five C1 fields, with the evidence for each. The definitions are under trust and freshness and actionability on the methodology page, and if you would rather have the footer, schema and form done for you, that is the implementation service.