The PDF trap: when your price list is a file, an assistant cannot quote it

What does a fetcher receive when it opens your page?

The HTML your server sends, and that is close to all. Our audit crawler, identifying itself as gaash-audit/1.0, fetched the homepage, the contact page and the about page of each site with JavaScript off, which is how the assistants' own crawlers describe themselves too: none of the operator documentation for OAI-SearchBot, PerplexityBot or Claude-SearchBot promises to run a page's scripts. Google does render JavaScript, but its JavaScript documentation describes rendering as a separate, deferred step after the initial crawl.

So the words that matter have to be in that first response as text. A heading, a paragraph, a table, a list: those are text. A PDF is a separate file behind a link, which a fetcher may or may not open and, if it does, reads as a document rather than as your page. An image of a menu is pixels. A price table that a script assembles from a spreadsheet after the page loads is an empty container at fetch time. Each of these is a common way for the most-asked facts about a business, what it costs, what it offers, when it is open, to leave the page.

What the crawl found

Across the 9,483 sites that answered (40 trades, 90 metros, September 2026), 2.1% kept their real content, the price list or the service menu, inside a PDF. 3.0% served their text only through JavaScript, so a crawler that runs no scripts received an empty shell. Those are small shares next to the 61.5% with no question-and-answer content at all, and they matter out of proportion to their size, because a PDF or an image is where the exact fact a buyer asks about most often tends to live.

The pages around the missing fact were not thin. The median homepage ran to 880 words. A restaurant site with eight hundred words about its history and a menu as a PDF has answered every question except "what do they serve and what does it cost", which is the question a buyer asked the assistant.

Which formats an assistant can and cannot use

The HTML standard's table element exists for exactly the thing a price list is: rows of items with a price beside each, a caption saying what the list is, and a header row a parser can read the columns from. It is also the format that survives being turned into plain text, which is how most retrieval systems read a page. A price list as a table is the same fact stated once for the person and the machine.

Moving a price list or a menu onto the page

1. Open the PDF and type its contents into the page as a table: one row per item, a column for the price or the range, a caption that names the list and the month the prices were current.
2. Group by section with a heading each (starters, mains; call-out, hourly, materials), so a buyer's question about one part lands on that part.
3. Where a price depends on a visit, say so in the row: "quoted after a visit" is a fact; a missing row is a gap.
4. Keep the PDF as a download link under the table for people who print, and say it is the same list.
5. Mark the business up once with the type for your trade and, for a shop or a restaurant, add Offer or Menu markup that repeats the visible prices; which types describe a business is in structured data for AI.
6. Change the table and the PDF on the same day when a price changes. Two versions of a price is a wrong price.

For an image, the same procedure with one extra step: keep the image, because it may be the nicer thing to look at, and give it alt text that says what it is. Google's image documentation is clear that the words a picture contains are not read from the picture; they have to be in the page. The alt text describes the image; the table carries the prices.

Why a script-built page is the same trap

A page that loads a shell and then fills it from a data source is a PDF with extra steps. The 3.0% of audited sites in that state had, in many cases, a modern site with a menu system that fetched its content on the client. To a person with a browser it looked complete; to a fetcher that ran no scripts it was a heading and a spinner. Google may render it eventually, on its own schedule; the assistants' documented crawlers do not promise to.

The fix is on the server side: render the page with its content already in the HTML, which every current site framework can do, or publish the facts as static HTML and update them by editing the page. What you should not do is leave the words to a script and hope. The test is the one that closes every article on this site: view the source with scripts disabled, and read what a fetcher reads.

How to find your own trap in ten minutes

1. Ask yourself the three facts a buyer most often calls about. For most trades: what it costs, what you offer, when you are open.
2. Find where each fact lives on your site. If the answer is "in the PDF", "in the photo" or "in the booking widget", you have found the trap.
3. View the source of that page with scripts disabled and search for one price. If it is not in the text, a fetcher does not have it.
4. Move the fact into the HTML as a table or a paragraph, on the page a buyer would open for it.
5. Ask the four assistants what you charge for the thing you moved, a month later, and read what they say. Our measurement does the same with one of them, Claude, on a fixed panel of twelve questions; the crawler access check confirms the crawlers are allowed as far as the page in the first place.