Most companies put their best material in PDFs. The annual report, the original research, the technical specification that took three months to write. Then they wonder why an AI engine answering a question about their industry cites a competitor's thin blog post instead.
Part of the answer is boring and mechanical. A PDF is a container format designed for print fidelity, not for machines reading text. Some PDFs are basically HTML in a trench coat and parse cleanly. Others are pictures of words, and to a machine they contain nothing at all.
The Only Distinction That Matters: Text Layer or No Text Layer
A PDF exported from a word processor or a design tool usually carries a real text layer. The characters are stored as characters. Any parser can pull them out.
A PDF produced by scanning a printed document is an image. It might look identical on screen. To a parser it is a picture, and unless somebody ran optical character recognition over it and saved the result back into the file, the text does not exist in any form a machine can read.
You can check this in about four seconds. Open the PDF, try to select a paragraph with your cursor, and try to copy it. If you can highlight individual words, there is a text layer. If your cursor draws a selection box over the whole page like you are cropping a photo, there is not. That second case is the one that quietly kills your citation chances, and it is more common in corporate document libraries than most teams expect, especially for anything older than about 2015 or anything that passed through a signature or approval workflow that involved printing and rescanning.
Layout Complexity Is the Second Problem
Even with a clean text layer, PDFs break in a way HTML does not. HTML has a document order. The parser reads top to bottom and the structure is explicit.
PDFs store text as positioned fragments. A two column layout is not stored as "column one, then column two." It is stored as a pile of text objects with coordinates. A parser has to reconstruct reading order from geometry, and it frequently gets it wrong. Multi column research papers, magazine style layouts, anything with a pull quote floating in the middle of a column, sidebars, footnotes, tables with merged cells: these produce extracted text that reads like someone shuffled the sentences.
This is why a PDF can be technically readable and still fail to earn a citation. The engine pulled text out. The text was incoherent. Nothing in it looked like a confident answer to anything.
Single column layouts extract dramatically better than multi column ones. If you have any influence over how your reports are designed, this is the single change with the best ratio of effort to outcome.
PDFs Skip Most of Your Structural Work
Everything covered in the schema markup guide assumes an HTML page. There is no JSON-LD block inside a PDF. No FAQPage markup, no Article schema, no author entity linked by @id, no dateModified field that a freshness check can read.
PDFs have their own metadata fields, and they are worth filling in. Title, author, subject, and keywords all live in the document properties and survive into most parsing pipelines. Almost nobody fills these in. The default title on a large share of published PDFs is the source filename, which is often something like Final_v3_APPROVED.docx.
But PDF metadata is thin compared to schema. You cannot express the relationships schema expresses. So a PDF competing against a well marked up HTML page is competing without the structural signals discussed throughout this blog, and it will usually lose on those grounds alone, independent of content quality.
The Freshness Problem Is Worse for PDFs
The content decay guide covers how citation confidence erodes as content ages without updates. PDFs make this worse in a specific way: they are almost never updated in place. A revised report becomes report-2026-v2.pdf at a new URL, while the old file sits at the old URL indefinitely, still reachable, still carrying its original date.
Now you have two versions of the same research live at two addresses with no canonical relationship between them, which is the exact ambiguity the canonicalization guide covers for HTML. Except PDFs cannot carry a canonical tag in the document itself. You can set one via an HTTP header at the server level, and hardly anyone does.
The result is that outdated PDF versions linger in AI training data and retrieval indexes long after you consider them superseded.
What I Would Actually Do
Publish an HTML version of anything you care about being cited. Not instead of the PDF, alongside it. The HTML page carries the schema, the author entity, the freshness signal, and the internal links. The PDF remains the download for the person who wants a formatted document to print or share internally.
This is more work than exporting a PDF and calling it done, and I understand why teams skip it. But the alternative is putting your strongest material into the format with the weakest structural signals and hoping it gets found anyway.
If you are not going to build the HTML version, then at minimum: confirm the text layer exists, fill in the document metadata properties, and use a single column layout. That is maybe twenty minutes of work per document and it moves a PDF from invisible to at least parseable.
Checking Whether AI Crawlers Can Reach Them at All
Access is a separate question from parsing, and it fails independently. A PDF sitting behind a form gate, in a directory excluded by robots.txt, or on a CDN path that blocks non browser user agents is unreachable regardless of how cleanly it would have parsed. The AI crawlers guide covers the access side in detail.
The NotionCue AI Crawler Audit checks what specific crawlers actually receive when they request a URL, which applies to PDF paths the same as HTML pages. Teams frequently discover their entire resources directory is blocked by a rule nobody remembers adding.
Start your free NotionCue trial and point the audit at your resources or downloads directory. That is where gated content and stale robots rules tend to accumulate.
Fastest audit available: open your five most important PDFs and try to select text with your cursor. If any of them behave like an image instead of a document, you found your problem, and running OCR on them is a genuinely fast fix.
Common Questions
Do AI engines cite PDFs at all, or should I stop bothering?
They do cite them. Text layer PDFs are indexed and retrievable. The point of this post is that PDFs carry structural disadvantages HTML does not, so they underperform relative to their content quality rather than being excluded outright.
Does password protection or a form gate stop AI crawlers?
Yes, and this is worth being deliberate about rather than accidental. Gated content is unreachable to crawlers, which is fine if the gate is a genuine business decision. It is not fine when someone gated a document years ago for lead capture and nobody revisited whether that tradeoff still makes sense.
Is there any way to add schema to a PDF?
Not in the way HTML supports it. The realistic approach is the HTML companion page described above, where the schema lives on the page and the PDF is the linked download.