Why Your Spec Sheet PDF Is Invisible to AI
Your tolerance tables and certifications might sit in a PDF no AI can actually read. Here's the exact test to check yours this afternoon.
Open the spec sheet PDF for your best-selling product. Zoom in on the tolerance table. It looks complete: clean columns, a materials callout, a certification stamp in the corner. Now click into a paragraph of the surrounding text and try to select it with your cursor, the way you'd select a sentence to copy into an email. If nothing highlights, or what lands in your clipboard is a scrambled run of characters in the wrong order, you've just found the reason an AI assistant can't describe your product accurately. It never read the page. It saw a picture of one.
A PDF is not automatically a document
A PDF can hold two completely different things behind the same visual surface: actual text, stored as character data a machine can extract, or a picture of text, stored as pixels or shapes that happen to look like letters to a human eye. Both render identically on your screen. Only one of them can be read by a system that indexes the web to build an AI assistant's knowledge base.
There are three common ways a technical PDF ends up in the second category. The most obvious is a scanned document: someone put the printed datasheet on a scanner, and the resulting PDF is a photograph of a page, one raster image per sheet, with no characters stored anywhere. The second is a page exported as an image from CAD software or a drawing package, saved into a PDF that otherwise contains real pages, so the datasheet looks consistent but one page in the middle is silently a picture. The third is subtler: text converted to vector outlines, sometimes called "curves" in design software. This happens when a font isn't embedded properly, or when someone flattens a PDF to stop others from editing it. The letters still look like letters, drawn with precision, but there is no character behind the shape, only a polygon that resembles the letter M. A retrieval system pulls text, not shapes. If there's no text layer, it has nothing to extract, and for the purpose of an AI answer, the page might as well not exist.
Run the test yourself, this afternoon
You don't need any special software to check this. Open the PDF, click into a paragraph, drag to select a sentence, and paste it into a plain text editor.
- Nothing selects. The page is an image. This is the scanned-document or flattened-outline case above.
- Something selects, but it's garbled or out of order. There is a text layer, but the structure is broken. More on this below.
- A clean paragraph, in the right order. That page is fine. Test another page before you relax, because spec sheets routinely mix a real text-based cover page with an image-based tolerance table two pages later.
If you want a second signal, open the PDF in a browser tab and try Ctrl+F or Cmd+F to search for a word you know is printed on the page, like the product name or "temperature". If the search finds nothing, the page has no text layer, full stop.
A text layer isn't the whole problem
A PDF can pass the copy-paste test on its cover page and still fail where it matters. The tolerance table, the one table a buyer or an AI assistant actually needs, is frequently pasted in as a bitmap image, exported straight from a CAD tool or inherited from an older scanned version, sitting inside an otherwise perfectly textual document. Nobody notices, because the page still looks complete.
Multi-column layouts cause a different kind of damage. A two- or three-column datasheet reads naturally to a human eye, top to bottom, left column then right. Most PDF text extraction, absent explicit structure tags telling it otherwise, reads left to right straight across the page. The result is a sentence that starts in column one and finishes, mid-word, with a fragment from column two. A system trying to lift a single fact out of that text gets a fact stitched together from two unrelated sentences.
The third failure is about where the facts live, not how they're encoded. Picture a valve manufacturer whose operating temperature range, rated pressure and applicable material standard are all correctly stated, but only inside the caption of a technical drawing, not anywhere in the body text. A model extracting text from that page gets the surrounding paragraphs about installation and warranty, and none of the numbers that actually distinguish this valve from a competitor's.
What makes a spec sheet machine-readable
Three things, all falsifiable with the test above:
- Real, selectable text. Not a scan, not an image export, not flattened outlines. If you can select and copy a paragraph cleanly, this part is solved.
- Tables as structured text, not graphics. A tolerance table should extract as rows and values a machine can parse, not as a single image with no text behind it.
- Key facts stated in plain sentences, outside the diagram. Material, tolerance range, operating temperature, the relevant ISO or ASTM designation, each written as an ordinary sentence somewhere in the body text, not only as a label inside a drawing.
None of this needs new software. A datasheet built normally in a modern layout tool, exported as PDF with fonts embedded and text intact, already clears the first bar. The second and third points are editorial: someone has to decide the tolerance table is worth typing out as text, and the temperature range belongs in a sentence, not only in a drawing's callout.
The second, easier way to lose this content
Even a spec sheet that passes every test above is still, on its own, harder for a retrieval system to reach than an ordinary web page. Systems built to index the web are built around HTML first. A PDF is a format they have to specifically decide to fetch, open and parse separately, and every extra step is a place where the attempt gets skipped for a given page. Many manufacturers publish a product's full specifications only as a downloadable PDF and never mirror the same table and sentences on an actual HTML page on their own site. That's a second, independent way to lose this content, unrelated to whether the PDF itself is well-formed.
The fix isn't glamorous: take what's already correct in the PDF, the material, the tolerance range, the certification, and put it on an HTML page too, as ordinary text and an ordinary table. It's more work than uploading a file once, and it's the version most likely to actually get read.
Where this fits, and what it doesn't fix
This is separate from whether your brand is recognized as an entity a model can name at all, or how visibility holds up across export markets and languages, both covered elsewhere. A spec sheet no retrieval system can read is a narrower, concrete failure: the content exists, it's just structurally unreachable.
Checking your own PDFs this way tells you whether this specific failure applies to you. It won't tell you whether AI assistants currently mention your brand, what they say about you compared to competitors, or whether that changes by market and language, which is a measurement problem, not a document-formatting one. That's what PSentry tracks: whether and how your brand shows up in AI answers, across platforms and languages. It doesn't audit, fix or rewrite your PDFs, that's a separate job, arguably a more foundational one, worth doing regardless of what any monitoring tool later tells you.
Frequently Asked Questions
If I convert my PDF to HTML with an automated tool, does that solve the problem?
Only if the source PDF already has real text to convert. Feed a scanned PDF into a converter and it typically runs OCR behind the scenes, which has its own error rate. Run the copy-paste test on the converted output before trusting it.
Can I just add OCR text to a scanned datasheet afterward?
Yes, and it adds a text layer where there was none, which beats nothing. But OCR guesses characters from pixel shapes, and dense numeric content like tolerance tables is exactly where OCR misreads are most common. Spot-check the output against the original rather than assuming it's accurate.
Does a copy-protected or password-restricted PDF cause the same problem?
It can, independently of whether a text layer exists. If a PDF's permissions block copying, an automated extraction attempt can be refused at that level even when the underlying text is real. Check permissions separately from the text-layer test.
Is this just an old search engine indexing problem with a new name?
Largely, yes, the underlying mechanism predates generative AI by a long way. What's changed is the consequence: a traditional search result can still surface your unreadable PDF as a ranked link a human might open anyway. A generative answer that can't extract your text doesn't surface anything, it states a competitor's numbers instead of yours.
My datasheet has a detailed CAD drawing. Do I need to make the drawing itself readable?
No, and that's usually not realistic. The goal is to state the same key facts, materials, tolerances, certifications, as ordinary sentences elsewhere on the page, so a text source exists even though the drawing itself never will be one.
Do I need to fix every page of a long datasheet?
No. Prioritize the pages carrying facts someone would actually ask about: dimensions, tolerances, materials, certifications, operating ranges. A cover page that's a nicely designed image doesn't matter much. A tolerance table inside that same PDF as a bitmap does.