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 persuasion than on what a machine finds in a few hundred milliseconds: a noun, a number and a compatible PMS. This post is about what that read looks like from the page’s side.

What is the fetch?

OpenAI’s documentation for the web search tool 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. The answer to “how much does it cost” is a number. “Contact us for pricing” is a gap the engine fills from a third-party site.

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?

1. JavaScript-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.
2. 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.
3. Hero copy without nouns. “Maintenance, reimagined.” “The future of resident experience.” An engine reading those lines learns nothing about category, buyer, price or PMS, and moves on to a page that tells it.
4. Facts in images or hidden tabs. Tabbed content where only the first tab is in the DOM costs a fact the engine would otherwise have had. So does a product name that is also a common word, with nothing around it.

Server-render the facts or put them in plain HTML, and let any PDF be the download.

What does a rewrite look like?

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 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, so the engine will describe this company using someone else’s words, if at all.

After:

[Vendor] is maintenance coordination software for property management companies with 100 to 5,000 doors. Residents submit requests through the app, and the system triages and dispatches to your own vendors or technicians.

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, and most customers manage single-family and small multifamily portfolios.

Reading the after paragraph

Same length. Now the machine has a category, a buyer, a mechanism, 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 on the demo, and the paragraph’s job is to survive the fetch.

Where does the page fit?

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 one archived ChatGPT run whose consulted pages are visible, a maintenance prompt from 3 September 2026, reddit.com was the most-consulted domain, ahead of 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.

For the markup side, structured data for AI covers what to mark up and what to leave alone. The llms.txt guide covers the one file that tells a fetcher where the facts live.

More field notes from each edition are on the blog.