PDF optimisation for AI citations is the practice of structuring a PDF document, its text layer, tag tree, and embedded metadata, so that AI crawlers such as GPTBot, ClaudeBot, and PerplexityBot can extract its content as reliably as they extract an ordinary HTML page. It matters because a large share of the documents organisations most want cited, whitepapers, spec sheets, annual reports, government filings, academic papers, exist only as PDFs, and a PDF that is not built for machine reading is functionally invisible to an AI model even when a human reader can open it without any trouble.
Most AEO guidance, including several of our own posts, tells you to avoid PDFs entirely and publish the same content as HTML instead. That advice is correct where you control the format: a blog post, a product page, a table of pricing tiers. It is not always an option. A regulator may require a filed report as a PDF. A published paper exists as a PDF because that is how the journal distributes it. A spec sheet ships as a PDF because that is the format procurement teams expect to download. For all of these, the real question is not whether to use a PDF, but how to build one an AI model can actually read.
How AI crawlers actually read a PDF
A PDF is a page-description format, not a text format. It tells a viewer where to draw each glyph on a page, and only incidentally carries an underlying text layer that a program can extract without OCR. Whether that text layer exists, and whether it preserves a sensible reading order, determines almost everything about whether an AI crawler can use the document at all.
Text layer or scanned image
A PDF exported from a word processor, a design tool, or a report generator normally carries a real text layer: every character is stored as text, selectable and copyable in a viewer. A PDF produced by scanning a printed page, or by flattening a document to an image before saving, has no text layer at all, only pixels. Most AI crawlers do not run OCR on PDFs they fetch. A scanned report with no text layer is, to a crawler, a blank page with a filename, regardless of how much useful information it holds for a human who opens it.
Reading order, not just presence
Having a text layer is necessary but not sufficient. Many page-layout tools write text to the underlying stream in the order objects were placed on the canvas, not the order a reader would actually read them. A two-column report where the second column was drawn first can extract with its paragraphs interleaved out of sequence, which produces the same practical result as an unstructured document with no headings: a model that can see the words but cannot reliably reconstruct what they mean together.
- Export from the source document (Word, Google Docs, LaTeX, InDesign with tagging enabled) rather than printing to PDF from a rendered web page or flattening a design file
- Run every PDF through a text-extraction check before publishing: copy-paste a full page into a plain text editor and confirm the paragraph order matches the visual layout
- Never publish a scanned or flattened-image PDF as the sole version of a document that needs to be cited; OCR it and verify the resulting text layer if a scan is unavoidable
- Avoid multi-column layouts for any report whose findings you want an AI model to quote accurately, or verify column order survives extraction if the layout is fixed
- Keep body text as real text, not text converted to outlines or curves for a print-design look, since outlined text has no character data to extract at all
Tags: the structure most PDFs are missing
Beyond the raw text layer, a PDF can carry a tag tree, the same idea as heading levels and semantic elements in HTML, marking which text is a heading, which is a table cell, which is a caption, and what order they belong in. This is the accessibility feature that lets a screen reader narrate a PDF sensibly, and it is the same structure an AI crawler benefits from for the same reason: it turns a wall of extracted text back into a document with a shape.
Untagged PDFs, which is most of them, hand a crawler one long, flat stream of text with no signal about which lines were a heading, which were a table, and which were a footer repeated on every page. A tagged PDF, exported correctly from Word, Google Docs, or Adobe InDesign with tagging enabled, preserves that structure through extraction, which is the PDF equivalent of correct heading hierarchy on a web page.
Most word processors can export a tagged PDF with one setting change: in Word, enable 'Document structure tags for accessibility' in the PDF export options; in Google Docs, tagging is on by default when you use File > Download > PDF. Check the result with a free tag-tree viewer before publishing, since the setting is easy to leave off without noticing.
Metadata that AI models actually use
A PDF carries its own metadata fields, separate from anything in the visible page content, and a crawler reads these before it opens the first page. Title, Author, and Subject are the three fields most consistently populated by AI ingestion pipelines, and most PDFs ship with them empty or set to a meaningless default like the export tool's filename.
- Title: the actual document title, not the source filename ("Q3-report-FINAL-v3.pdf" is not a title)
- Author: the organisation or named author, matched consistently with how you present authorship elsewhere on your site
- Subject: a one-sentence description of what the document covers, functioning like a meta description for the file itself
- Keywords: a short, genuine list of the terms the document is actually about, not a stuffed list of unrelated queries
- Creation and modification dates: kept accurate, since a report with no reliable date signal is a weaker citation candidate under any freshness-aware ranking
These fields are set in the export dialog of most authoring tools, or after the fact with a PDF editor. They take minutes to fill in correctly and are one of the few places where PDF citability is genuinely quicker to fix than the equivalent problem on an HTML page.
The HTML companion pattern
The single most reliable fix, when it is available to you, is publishing an HTML companion page alongside the PDF rather than the PDF alone. The HTML page carries the same core content, the executive summary, the key figures, the main findings, as ordinary crawlable text, with the PDF offered as a download for readers who want the full formatted report. This is the same pattern we recommend for video and podcast transcripts: publish the citable version as visible HTML, and treat the alternate format as a convenience layer on top of it, not a replacement for it.
A companion page also solves the reading-order and tagging problems by sidestepping them: HTML text extracts cleanly by default, so a well-built companion page is citable even if the PDF export it links to is imperfect. Where a full HTML rewrite of a 40-page report is not realistic, a shorter companion page covering the abstract, key statistics, and main conclusions still captures most of the citation value, since AI models overwhelmingly quote the headline finding of a report rather than a paragraph from page 23.
Discovery: getting the PDF found at all
A perfectly structured PDF that no crawler ever fetches cannot be cited. Discovery for PDFs works the same way it does for any other page a crawler needs to find, with one added risk specific to the format: PDFs are frequently hosted on a separate document management system, a media CDN, or an investor-relations subdomain that a site's primary sitemap and robots.txt review never touches.
- List PDF URLs in your XML sitemap alongside HTML pages, with an accurate lastmod date so a crawler can prioritise recently updated reports
- Confirm the robots.txt covering the PDF's actual hosting domain, not just your primary domain, allows the AI crawler user agents you want to reach
- Link to each PDF from at least one crawlable HTML page, ideally the companion page described above, rather than leaving it reachable only through a search box or a gated download form
- Check response headers for an X-Robots-Tag that unintentionally blocks indexing; PDF hosting setups on a separate CDN sometimes carry a stricter default than the main site
- Avoid gating the PDF itself behind a form submission if you want it cited; gate a bonus asset instead, and keep the core findings openly accessible on the companion page
Investor-relations and compliance PDFs are commonly hosted on a third-party platform with its own robots.txt, entirely separate from the corporate domain's configuration. If your annual report or SEC filing lives on such a platform, audit that platform's crawler access directly. A permissive robots.txt on your main site tells you nothing about it.
Measuring whether it is working
Server log analysis, the same technique covered in our crawler log analysis guide, applies to PDF hosting too: filter access logs for GPTBot, ClaudeBot, and PerplexityBot user agents against the specific paths or subdomain that serve your PDFs. If those crawlers never request the file, nothing about the text layer, tags, or metadata matters yet, since the document has not been fetched at all. Once you confirm the fetch is happening, ask the assistants directly about the report's headline finding and check whether the response cites the PDF, the HTML companion page, or neither.
The realistic goal for most organisations is not to make every PDF a top citation source. It is to stop the PDFs that carry genuinely citable information, a proprietary study, a compliance figure, a spec table found nowhere else, from being invisible to AI crawlers purely because of preventable formatting choices made at export time.