Spec sheets, manuals, menus, price lists and catalogs often hold the exact facts a shopper asks an AI assistant about. When those facts live only in a PDF, and especially in a scanned one, agents may never find them. This guide explains which facts belong in HTML, how to make the PDFs you keep readable, and how to name and link them so agents can find the right one.
Why documents are a weak spot
Ask an assistant "does the Fernwood 5-quart Dutch oven work on induction?" and the answer may be on page 3 of a care guide PDF. Whether the assistant gets there depends on several things going right:
- It has to find the file. A PDF linked as "Download" from a tab that only opens with a script is easy to miss.
- It has to open it. Many agents fetch HTML pages first. Some will follow a link to a PDF; others won't spend the time when the product page doesn't answer the question.
- The PDF has to contain text. A scanned page is a picture of text. Without text recognition, there are no words to read.
- The text has to make sense in order. A two-column layout without structure can come out as alternating half-sentences, and a table can come out as a stream of unrelated numbers.
- It has to be current. PDFs get downloaded, copied and forgotten. The 2023 price list may still rank above the 2026 one.
Search engines do read PDFs: Google lists PDF among the file types it indexes. But being indexed isn't the same as being the quickest place for an agent to confirm a fact for a shopper. The product page is.
- The fact exists Somewhere in your documents
- The file is found Linked in plain HTML
- The file is opened The agent follows the link
- It has real text Not a scanned image
- It reads in order Tagged, current, clear
Put the key facts in HTML
The single most useful change is to lift the facts shoppers ask about out of the document and onto the page. Keep the PDF for what it's good at: the full manual, the printable version, the regulatory paperwork.
| Document | Put on the HTML page | Fine to leave in the PDF |
|---|---|---|
| Spec sheet | Dimensions, weight, materials, compatibility, certifications, what's in the box | Exploded diagrams, test reports |
| Manual | Care and cleaning basics, warranty length, the answers to common questions | Step-by-step assembly, troubleshooting tables |
| Restaurant menu | Dishes, prices, dietary and allergen labels, hours | A designed, printable version |
| Price list | Current prices and what each includes | Archived lists for existing contracts |
| Catalog | A product page per item, with its own URL | The look-book or print edition |
Facts on the page should be text, with labels and units, as described in product descriptions AI agents can compare. Prices belong in the page HTML; see prices AI agents can read. For a menu, write it as an HTML list or table, not an image of the printed menu. Agent readiness for local businesses covers menus and hours in more detail.
Only in the PDF
- "Specifications: see spec sheet"
- Menu as a scanned image
- Price list as a download
On the page, PDF as backup
- Specs in a table on the product page
- Menu as HTML text with prices
- Prices on the page, PDF to print
Make every PDF real text
If you keep a PDF, make sure it contains text an agent can read:
- Export from the source. A PDF saved from Word, InDesign or your product system keeps its text. A PDF made by scanning a printout doesn't.
- Run text recognition on scans. For documents that only exist on paper, OCR (optical character recognition) turns the picture back into text. W3C's technique for scanned PDFs covers this, including correcting the words the software wasn't sure it recognized.
- Check with a simple test. Open the PDF and try to select a sentence and copy it into a text editor. If you can't select it, or what you paste is garbled, agents get the same result.
- Keep text as text. Don't flatten pages into images to stop copying. It stops agents and screen readers too.
Watch the numbers. Recognition errors in prose are annoying; in a spec sheet or price list they're wrong answers. Check every figure in an OCR'd document against the original before you publish it.
Tag your PDFs for structure
A tagged PDF carries a hidden structure that says what each piece of text is: a heading, a paragraph, a list, a table cell, an image. It's the PDF equivalent of HTML markup, and it's what accessibility guidelines ask for. The W3C's techniques for meeting WCAG in PDFs include:
- Headings marked with heading tags, so a reader can tell sections apart.
- Tables marked with table tags, so each value stays with its row and column.
- Lists marked with list tags.
- Reading order set correctly, so two columns don't interleave.
- Text alternatives for meaningful images, and decorative images marked as artifacts.
- The document language and a document title set in the file's properties.
The tools that make PDFs (word processors, design tools, Adobe Acrobat) can produce tagged files if the source document uses real heading styles, list formats and tables. That's the cheap way: get the source right and export with tagging turned on. Fixing tags by hand afterwards is slow. The same structure that helps a screen reader helps an agent make sense of the text; see accessibility work is agent readiness work.
A readable PDF
- Real text you can select and copy
- Tagged headings, lists and tables
- Reading order that follows the columns
- Title and language set in the file
- Scanned pages with no recognized text
Names, titles and links
An agent decides whether a document is worth opening from what surrounds it. Help it choose:
- Descriptive link text. "Fernwood 5-quart Dutch oven care guide (PDF, 4 pages)" instead of "Download" or "Click here". Saying it's a PDF, and how long, sets expectations.
- Descriptive file names.
fernwood-dutch-oven-5qt-care-guide.pdf, notDOC_0042_final_v3.pdf. - A real document title. Set the title in the file's properties. W3C's technique for PDF titles notes that the title identifies the document without anyone having to read its pages, and viewers can show it in the window or tab.
- Linked in plain HTML from the product page. Not only from a script-driven tab or a "resources" portal that needs a sign-in. See login walls and gated content.
- A stable URL with a date or version inside. Replace the file at the same address when it changes, and print "Version 3, September 2026" on the first page so an agent can tell which edition it read.
- Not blocked. Check that your robots.txt doesn't disallow the folder your documents live in, unless you mean it to. See robots.txt for AI agents.
What AgentScore checks
AgentScore doesn't open or score PDFs. Its Readability checks look at your HTML pages: whether text is there before JavaScript runs, whether product pages have structured price and stock data, and whether prices are in the HTML. Moving key facts out of documents and onto your pages is what improves those results. If a key journey depends on a document, such as checking a compatibility chart before buying a part, you can set up a Ghost Agent test for that journey in the app. Its step-by-step replay shows each page the agent saw and its reasoning, so you can see where it got stuck. Ghost Agents stay on the site they're testing, so they won't follow a link to a document hosted somewhere else.
Where to start
A one-afternoon document audit:
- List the PDFs linked from your product, menu or pricing pages. Your CMS or a site search for ".pdf" will find most of them.
- For each, try selecting and copying a sentence. Mark the ones that fail as scans.
- For your top ten products, check whether the specs shoppers ask about are on the page or only in the PDF.
- Copy the missing facts onto the pages as text, with labels and units.
- Rename unclear files, set their titles, and rewrite "Download" links to say what the document is.