Do AI Engines Read PDFs, Menus and Images? What Actually Gets Extracted
By the alphaa team — we run AI-visibility scans across thousands of local businesses and inspect what the engines actually retrieve from their sites. Last updated 11 August 2026.
Short answer: PDFs usually get read. Images usually do not. Text-layer PDFs are crawled, parsed and cited much like web pages, so a price list or brochure in PDF form can end up in an AI answer. A photograph of that same price list is, to most retrieval pipelines, an opaque file with a filename and maybe some alt text. Scanned PDFs sit in between and are unreliable. If a fact about your business exists only inside pixels — the menu, the hours sign, the service-area map, the rate card — assume the assistants answering questions about you do not have it.
Why the distinction exists at all
It is tempting to assume that because ChatGPT, Claude and Gemini are all multimodal — they can look at an image you upload — they must also look at the images on your website. They are two different systems. The model can see pixels when a user hands it pixels. The retrieval layer that fetches pages when someone asks "what does this business charge?" is a search-and-fetch pipeline, and that pipeline is built around text.
Concretely, when an assistant answers a question about your business it typically runs a search, pulls back a handful of URLs, extracts the text of those documents, and writes an answer grounded in the extracted text. Running vision inference on every image on every fetched page would be enormously more expensive than reading the HTML, and it is not what these pipelines do at scale. What survives the extraction step is what the model gets to use. The same principle governs JavaScript-rendered content: it is not a question of whether a model could understand it, but whether it ever arrives.
What actually gets extracted, format by format
HTML text — fully extracted
Server-rendered text in the page body is the gold standard. It is cheap to fetch, trivially parsed, and directly quotable. Everything you want an engine to be able to say about you should exist here in some form, even if a prettier version exists elsewhere.
Text-layer PDFs — usually extracted, sometimes cited
A PDF exported from Word, Google Docs, InDesign or a web page carries a real text layer. Search engines have indexed these for two decades and AI crawlers parse them too. In scans we regularly see PDFs turn up as cited sources — annual reports, service brochures, fee schedules, council documents. The caveats are real, though: PDFs are re-crawled less often than HTML pages, they carry no internal navigation the crawler can follow onward, their titles are often garbage ("Untitled-2 final FINAL v3"), and multi-column layouts scramble into confusing reading orders when extracted. A PDF is a usable source, not a good one.
Scanned PDFs — unreliable
A scanned document is images wrapped in a PDF container. Whether any text comes out depends entirely on whether an OCR pass ran, and you have no control over and no visibility into that. Treat scanned PDFs as invisible until proven otherwise. The two-second test: open the file and try to select a sentence with your cursor. If nothing highlights, there is no text layer.
Images — effectively not extracted
The text inside a JPG or PNG is not available to the retrieval layer. What is available is the surrounding HTML: the alt attribute, the filename, the caption, nearby headings and body copy. That is a description of the image, not its contents — a 40-item menu cannot be reconstructed from alt="Our menu".
Embedded widgets and iframes — usually not extracted
Third-party booking widgets, embedded PDF viewers, review carousels and menu platforms load their content from another origin after the page loads. The crawler fetches your page and gets a container with nothing in it. This is why a restaurant whose menu lives in an embedded viewer and a clinic whose hours live in a booking widget both look, to an engine, like businesses that never published a menu or their hours.
SVG and HTML tables — extracted better than people expect
SVG text is real text in the markup and generally survives extraction. Plain HTML tables extract cleanly and are one of the most quotable structures you can publish — a two-column table of service and starting price is close to ideal input for an answer engine.
The failure we see most often
The single most common version of this problem in our scans is a business whose most decision-relevant information — the exact thing a customer asks an assistant about — exists only as an image. A few real shapes of it:
- A restaurant with a beautifully designed menu uploaded as a photo. Ask an assistant "do they have gluten-free options?" and it cannot say, so it names a competitor whose menu is HTML. This is a large part of why restaurant AI visibility is so uneven.
- A contractor whose service area is a map graphic. The engine knows the city the business is in and nothing about the twelve suburbs it serves, so every "near me" question in those suburbs resolves to someone else.
- A clinic with holiday hours posted as a graphic. The assistant confidently states the regular hours it found in structured data, and the customer arrives at a closed door.
- A studio whose entire price list is a PDF rate card with no HTML equivalent. Better than an image, but the PDF is stale, re-crawled rarely, and the numbers in AI answers lag reality by months. We cover the general case in how pricing pages shape AI recommendations.
In every case the business believes it has published the information. It has — for humans. The machine reading the page sees a heading, a paragraph of marketing copy, and a file it cannot open.
The fix, in the order we do it
This is a couple of hours of unglamorous work and it is often the highest-return change on the whole site.
- 1. Audit what a text-only reader sees. Open your key pages with images and JavaScript disabled, or view the page source and read only what is between the tags. Anything a customer needs that is missing from that view is a gap. Do this for your menu or services page, pricing, hours and contact, and your service-area page.
- 2. Give every image-only fact an HTML twin. Keep the pretty graphic. Add the same information as real text on the same page — a list, a table, a paragraph. You are not replacing the design, you are adding a machine-readable copy underneath it. This alone closes most of the gap.
- 3. Convert critical PDFs into pages. If a PDF is the only home of something people ask about — fees, services, eligibility, specifications — publish an HTML version and link the PDF from it rather than the other way around. The HTML page gets crawled more often, can be updated in seconds, and can link onward to the rest of your site.
- 4. Un-embed what you can. Where a third-party widget holds important content, put a plain-text summary next to it. The widget stays for booking; the text carries the facts.
- 5. Write alt text that states facts, not decoration. Alt text will not carry a full menu, but "Emergency callout rate card: $149 diagnostic, waived if you book the repair" is strictly more useful than "pricing image". Write it for a person who cannot see the image, which is exactly what the crawler is.
- 6. Mirror it in structured data. Hours, price ranges, menus and services all have schema types. Structured data is the most reliable way to hand a fact to a machine without relying on prose extraction — see schema markup for AI search.
- 7. Re-ask the assistants a month later. Ask ChatGPT, Perplexity and Gemini the specific question the image used to answer. If the answer now matches your page, the extraction gap was the problem.
Questions we get asked
Should I stop using PDFs entirely?
No. PDFs are fine for things that are genuinely documents — reports, forms, specification sheets, anything meant to be printed or archived. The rule is that a PDF should never be the only place a customer-facing fact lives. Publish the fact in HTML; offer the PDF as a download.
Does this hurt my Google rankings too, or only AI answers?
Both, for the same underlying reason, though AI answers are less forgiving. Google has decades of infrastructure for guessing at images and can lean on your Google Business Profile for hours and location. An assistant composing a paragraph from a handful of retrieved documents has far less to fall back on — if the fact is not in the extracted text, it usually does not appear in the answer.
What about images the model can see — do they ever help?
Yes, in the situations where a user hands the image over directly: someone photographs your storefront sign and asks what it is, or uploads your brochure and asks a question about it. That is a real and growing path, and it is a reason to keep visual assets clear and legible. It is not, however, the path that decides whether you get named when someone asks "who should I call?" — that one runs on retrieved text.
Will fixing this get me recommended?
Honestly: it removes a reason you are being left out, which is not the same as being chosen. If an assistant cannot confirm you offer the thing being asked about, you are excluded before any judgment about quality happens. Making your facts machine-readable puts you into the candidate set. Reviews, third-party corroboration and genuine specificity decide what happens next. Nobody can guarantee a recommendation, and you should be wary of anyone who says otherwise.
The bottom line
Answer engines can only recommend what they can read. A design decision made for humans — put the menu in the pretty graphic, put the rate card in the PDF — quietly removes your most persuasive information from the only version of your site a machine ever sees. The fix is not a redesign. It is a text twin for every fact that currently lives in pixels, and it usually takes an afternoon.