How AI Engines Read a Vendor Page, and What They Skip

When a property manager asks an engine which maintenance coordination software to look at, the engine goes and reads. It fetches a handful of pages, pulls out the parts that look like facts, and assembles a shortlist from them. Your vendor page is one of the candidates. Whether it makes the cut depends less on how persuasive it is and more on whether a machine reading it in a few hundred milliseconds can find a noun, a number and a compatible PMS. This post is about what that read looks like from the page’s side.

What the fetch is

OpenAI’s documentation for the web search tool in its API describes the model issuing searches, opening result pages and returning the answer with citations to the pages it used. Perplexity’s API documentation describes the same shape: a search step, a set of retrieved pages, an answer with numbered citations back to them. Google’s Search Central documentation says AI Overviews and AI Mode draw on the same index and the same content guidelines as regular Google Search. Three products follow the same pattern: search, fetch, extract, write.

The fetch is the part vendors underestimate. The engine is not browsing your site the way a prospect does, clicking Pricing, then Integrations, then Customers. It lands on one URL from a search result, reads what is there, and moves on. If the fact it needs is on the next page, or behind a tab, or in a script that has not run, the fact does not exist for that answer.

What gets extracted

Five parts of a vendor page do most of the work, judging by what answers repeat back.

The title tag and H1. This is the line the engine is most likely to read, and it is where category membership gets decided. “Maintenance coordination software for property managers” tells the engine what shelf you belong on. “Fix more, stress less” does not.

The first paragraph. Our working assumption is that engines weight the top of the page the way a skimming reader does. If the first paragraph says what the product is, who buys it, and what it connects to, the extraction is done in one pass. If the first paragraph is a mission statement, the engine has to keep reading, and it may not.

The pricing table. A table with a price per unit, a minimum, and what is included is one of the most quotable objects on a vendor site, because the answer to “how much does it cost” is a number and the table already has one. “Contact us for pricing” is a gap the engine fills from a third-party site, and third-party pricing pages are wrong more often than you would like.

The integration list. Property-ops buyers ask by PMS. “Which maintenance software integrates with Buildium” is a real prompt shape in the Index library. Writing the PMS out on the page, in plain text, is how the engine connects you to that question. A wall of logos is not text.

Comparison tables. A “vs” table or an alternatives page with structured rows gives the engine the shape it produces: vendors down a column, attributes across. Pages like this get pulled into answers because they have already done the engine’s work.

What breaks extraction

JS-only content. If the price, the integrations or the feature grid renders only after a client-side script runs, an engine that does not execute the script sees an empty container. Google’s Search Central documentation says Googlebot renders JavaScript. The other engines’ fetchers are not documented to, and our working assumption is that they do not. Server-render the facts or put them in plain HTML.

PDFs. A pricing sheet or integration guide that lives only in a PDF is, for practical purposes, invisible. Some fetchers parse PDFs and some do not, and even the ones that do lose the structure. Put the same facts on an HTML page and let the PDF be the download.

Hero copy without nouns. This is the most common failure on property-ops vendor sites and the cheapest to fix. “Maintenance, reimagined.” “The future of resident experience.” “Work smarter, not harder.” An engine reading those lines learns nothing about category, buyer, price or PMS. It moves on to a page that tells it.

Smaller breakages add up too: facts trapped in images, tabbed content where only the first tab is in the DOM, and product names that are also common words with nothing around them to disambiguate. Each one costs a fact the engine would otherwise have had.

A before and after

The example below is invented. It describes no real vendor, and the numbers are made up for the illustration.

Before:

We’re on a mission to transform how property teams handle the unexpected. Our intelligent platform brings residents, technicians and managers together in one seamless experience, so you can focus on what matters most. Trusted by forward-thinking operators nationwide. Book a demo to see the magic.

Read that as a machine. Category: unknown, since “handle the unexpected” could be maintenance, security or insurance. Buyer: “property teams,” which could mean anything from an HOA board to a REIT. Price: none. PMS: none. Proof: “forward-thinking operators nationwide,” which is not a fact. There is nothing here to extract, so the engine will describe this company using someone else’s words, if it describes it at all.

After:

[Vendor] is maintenance coordination software for property management companies with 100 to 5,000 doors. Residents submit requests through the app, the system triages and dispatches to your own vendors or technicians, and every job syncs back to AppFolio, Buildium, Rent Manager or Yardi. Pricing is $2 per door per month with a 100-door minimum and no setup fee. Most customers manage single-family and small multifamily portfolios.

Same length. Now the machine has a category (maintenance coordination software), a buyer (PM companies, 100 to 5,000 doors), a mechanism (resident request, triage, dispatch to own vendors, sync), four PMS names in plain text, a price, a minimum, and a segment. Every one of those is a fact an answer can carry.

Nothing in the after paragraph is persuasive in the marketing sense. That is fine. The persuasion happens later, on the demo. The paragraph’s job is to survive the fetch.

Where this fits

The page is the last step. Before an engine reads your page it has to find it, and the pages it finds first are often not yours. In the first Index run, in maintenance coordination, the domain ChatGPT cited most was reddit.com, not any vendor’s site. Measuring which sources those are is the other half of the problem, and the AI search optimization guide covers how the engines choose sources in the first place. For the markup side, structured data for AI covers what to mark up and what to leave alone, and the llms.txt guide covers the one file that tells a fetcher where the facts live. The rest of the field notes are on the blog.