What an assistant reads is not what you see.

The request is not a browser request

When a person visits, a browser fetches the document, runs the JavaScript, applies the styles, and assembles what you designed. When an assistant visits, most of that does not happen. It issues an HTTP request, takes what comes back, and reads it. It generally does not execute your JavaScript, it does not wait for a client-side router to swap content in, and it is working to a budget — the version it keeps is usually the version it got first time.

That single difference accounts for most of what goes wrong. A catalog rendered from a client-side fetch is, to the reader that matters here, a catalog that is not there. An application serving the same shell markup at every URL is, from the outside, one page. Nothing is broken, and every human visitor sees exactly what you intended. The site is simply answering a question it was never asked: it was written for a renderer, and the thing on the other end is a parser.

The test is blunt and takes about a minute. Fetch one of your important pages without a browser — curl will do — and read what comes back. If the words a customer needs are missing from that response, they are missing from the assistant’s view of you too.

Access rules are read literally

Before anything is read, something decides whether it may be. robots.txt is the first file requested and the least examined file most organizations publish. It gets inherited from a template, a staging environment or a platform default, and it is wrong in ways that stay invisible until someone looks: a blanket disallow left over from a launch, a blocked assets path that also holds the data the page depends on, or a rule aimed at one crawler that quietly excludes every other.

AI crawlers sit on top of that as a newer and messier layer. Several operate under their own user agents, separately from the search crawler you may already permit, and they read the file just as literally. Which of them you want is a real business decision with defensible answers at both ends. Making that decision by accident, through a file nobody has opened since the site was built, is not one of them.

Page-level directives deserve the same look. A noindex tag copied across from a section that genuinely needed one will hide a page from everything that respects it, and the rendered page looks identical either way. So will a canonical tag still pointing at a URL retired two redesigns ago.

Structured data is the part that is unambiguous

Most of a page is prose, and prose has to be interpreted. Structured data — JSON-LD, in schema.org’s vocabulary, inside a script tag — is the part that does not. It states plainly that this page concerns an organization with this legal name at this address, offering these services, and that this piece carries this headline and this publisher. Nothing has to infer it.

Two rules separate markup that helps from markup that hurts. The first is that it must describe what is actually on the page: markup claiming a product, a rating or an event a reader cannot find is a mismatch, and platforms treat a mismatch as grounds to distrust everything else you declared. The second is that its identifiers have to resolve. A provider pointing at an identifier that no node on the site emits is a dangling reference — it validates as syntax and carries no meaning as data. It is the defect we find most often, and it usually arrives the same way: markup copied from one page onto four, where the node it referred to only ever existed on the first.

Start with the nodes that describe you rather than the ones that chase a rich result. One organization node, with your legal name, your logo and the profiles you genuinely control. One for the site. Then a service, product or article node on the pages that really are one. Three accurate nodes beat a dozen ambitious ones, and they are far easier to keep true through a redesign.

Entity clarity beats keyword coverage

The hardest of the three to fix, and the one that pays best, is being a clearly defined thing. An assistant asked to recommend a supplier is not matching keywords against a page. It is assembling an entity — a name, a category, a location, a set of capabilities, some evidence — and then judging whether that entity fits the request. Fuzzy edges are fatal to that judgment in a way no amount of content volume compensates for.

Sites blur those edges in consistent ways. The company is described in a different register on every page. Its name appears in four forms: the trading name, the legal name, an abbreviation and the flagship product. The locations live in a footer graphic. The services are named with vocabulary the company invented and no customer uses. Each is defensible on its own; together they produce something that cannot be resolved into one organization.

The correction is unglamorous and mostly editorial. Say who you are, in the same words, in the same place, on every page. Name your services the way a customer would name the problem. Put the facts that establish credibility — locations, accreditations, named clients, dates, quantities — in text rather than in an image. Link related pages to one another so the relationships between them are stated rather than implied by a navigation menu.

The order these go in

Sequence matters, because each step depends on the one before it. Access first: nothing else is worth doing while a page cannot be fetched. Then the content in the initial response, because structured data describing content an agent never received makes the mismatch problem worse rather than better. Then the markup, for what the page genuinely contains. Then entity clarity, which is a content and information-architecture job, and the one that takes longest.

• Fetch three important pages without a browser and read what actually comes back.
• Open robots.txt and decide, on purpose, which agents may read what.
• Check that every identifier your structured data references is a node something on the site emits.
• Pick one name for the organization and one name per service, then use them everywhere.
• Move the facts that establish credibility out of images and into text.

None of this produces a grade. These are observed signals, not an overall score — each one present or absent, each with a specific fix and a specific owner. That is a less satisfying deliverable than a single number, and a considerably more useful one.