The agent readiness checklist for a marketing team with no engineers

You run marketing for a mid-market company. The website lives in a CMS you control, engineering is a ticket queue with a lead time measured in sprints, and someone senior has asked whether the site is ready for AI agents. The useful answer is that most of the rubric is either already yours or briefable, and the split is clean. This is the checklist: what you can do in the CMS this week, what goes into a brief for an agency or engineering, and how to use the free scan to write that brief so it comes back done rather than debated.

Each item carries the check id from the published rubric so that your report, this list and the brief all use the same names. Reading your scan report explains what each line of the report means; the three tiers of fixes explains why the split below falls where it does.

Before you start

Run the scan once, before touching anything, and keep the report. It is the baseline the brief will be measured against, and the evidence blocks are what you will paste into tickets. Every check on it carries a status, points earned against points possible, and an effort rating of Low, Medium or High. The Low ones are almost all yours.

In the CMS this week

These need an editor's access and an afternoon. None of them needs a deploy.

• Titles (B4). Every page has a title of 15 to 70 characters, and no two pages share one. The scanner checks both across every page it crawls; a single duplicate loses the point for all of them.
• Meta descriptions (B4). Every page has a description of 50 to 160 characters. Most CMS SEO fields count for you. Pages with an empty field usually inherit nothing, which scores as absent.
• Open Graph (B4). og:title, og:description and og:image on every page. If the CMS has a default social image, set it, because the check wants all three present on each page rather than on the homepage only.
• Alt text (B6). Content images carry non-empty alt text on at least 80% of images across the crawled pages. Images declared under 50px wide or high are excluded, so icons do not count against you. Work through the media library, not page by page.
• Link text (C2). Fewer than 5% of links use contextless text like "click here". Search the CMS for "click here", "read more" and "learn more" and rewrite them to say where they go.
• Headings (B3, editorial half). One h1 per page, and no jump from h2 to h4 in body copy. The template owns the h1; the editor owns the rest. If the editor's toolbar offers Heading 1, stop using it in body content.
• Policies linked (D3). Privacy and terms in the footer on every page. If you sell physical goods, shipping and returns too. The scanner looks for an href containing privacy, and one containing terms, tos or conditions, or shipping/delivery plus return/refund for shops. It does not read the pages; it looks for the links.
• Contact route (D2, first half). A footer link to a contact or about page, or a mailto: address. Either earns 2 of D2's 4 points on its own.
• Visible dates (D4, one point). Published or updated dates on articles, output as a time element with a datetime attribute. Most CMS article templates do this if the field is filled.
• llms.txt (A4). If the host lets you place a plain text file at the root, this is 3 points for an hour's work: an h1, a one-line summary, then a list of your most useful pages as - [Title](URL): description. The scanner counts lines in that shape; three or more described links score 3, an llms-full.txt adds 1, and a list without descriptions scores 1. Our own is the shape to copy.
• security.txt (D6). Also a root text file, /.well-known/security.txt, with a Contact field and a future-dated Expires. Agree the contact address with whoever handles security before publishing it.
• robots.txt (A1, A2). If the CMS exposes it, confirm it does not disallow GPTBot, OAI-SearchBot, ClaudeBot, Claude-User, PerplexityBot or Google-Extended unless that is a decision someone made. Many templates block everything they do not recognise.

That list, done, moves several checks from partial to full without anyone outside marketing being involved.

To brief to an agency or engineering

These touch templates, forms, rendering or infrastructure. They are the Medium and High effort checks, and the brief is where you spend your leverage.

• Structured data in templates (B1, B2). Valid JSON-LD on the homepage and at least half the crawled pages, with Organization or WebSite sitewide plus the type-specific markup: Product and Offer for a shop, Article, FAQPage or SoftwareApplication otherwise. A template change, applied once.
• Organization sameAs (D2, second half). The Organization node needs a sameAs array with at least one URL that resolves, such as a company profile. Usually a field in the same template.
• Forms (C1). Every input labelled, input types correct (email, tel, number), and a real submit button rather than a click handler. Form builders vary; ask for a fix to the template, not the individual form.
• Buttons and navigation (C2, C3). Links are a elements with an href; buttons are button elements; the menu is reachable by keyboard.
• Server-rendered content (A7). Visible text in the raw HTML at or above 0.8 of the rendered page. If the report shows a low ratio, this is the biggest single item in the brief and the reason the rest of the report may be understating problems.
• Edge and CDN settings (A5). Bot user agents must receive a 200. If the report shows 403s, the fix is in the CDN dashboard and takes minutes, but it needs someone with access.
• Transport (D1) and canonical hygiene (B7). An HSTS header; www, non-www, http and https all resolving to one host; a self-consistent rel=canonical.
• On-site search (C6). A search form that uses GET with a query parameter, so an agent can build a results URL.
• Machine endpoints (C4). An agents.json, an MCP manifest, an OpenAPI spec or a linked API documentation page. Any one scores 3 of 5; two score 5. This is the check most sites score zero on and the one that most needs an engineer.

If you would rather hand the whole second list to us, that is the implementation service, which works in your codebase or your CMS.

Writing the brief from the scan

A brief that comes back done has four parts per item, and the report supplies three of them.

Check:      C1 Form usability (5 points, Medium effort)
Scored:     2 of 5
Evidence:   unlabelled: 4, wrongTypes: 2, realSubmit: false
Asked for:  label every input, set type="email" on the email field
            and type="tel" on the phone field, replace the div
            submit with <button type="submit">
Verify:     re-run https://agentfriendlyrank.com/scan after deploy

Copy the check id, the score and the evidence block from the report verbatim. Write the "asked for" line as the change, not the diagnosis, using the recommendation text under the check as a starting point. Add the verification step so the ticket has a definition of done nobody has to argue about. Order the tickets the way the report orders its top fixes, which is by impact first and effort second, and link each ticket to the check's definition on /methodology so the engineer can read the threshold rather than take your word for it.

One brief, one re-scan, and the report becomes the acceptance test. The next quarter's version of this checklist is whatever is still not green.

Check your own site

Run the free scan, work through the first list yourself, and turn the second into tickets. The check definitions are on the methodology page under understanding and discovery and access.