Google explains how Search indexes and ranks PDF files

Google has released a Search Off the Record podcast episode on how Search handles PDF files, with Martin Splitt and John Mueller walking through how PDFs are converted for indexing, whether they rank, how they show up in AI features, and the ways they commonly go wrong.

The episode, titled "PDFs in Search: Indexing, AI & Pitfalls", was published on YouTube on 13 October, with an official transcript linked from the video description. It is broken into chapters covering the llms.txt question, conversion and crawling, the restaurant menu debate, PDFs for AI grounding, and the common pitfalls.

For a business owner the question is simple. Should the menu, the price list, the brochure or the annual report be a PDF or a web page? Google's answer is mostly "web page", with a few exceptions.

Check Content-Type headers on PDFs

A PDF is not plain text like an HTML page. It is a binary container that needs a specific parser before the words inside can be read. Google's documentation lists PDF alongside Word, Excel and PowerPoint files as encoded file types it can index, separate from flat text formats such as HTML, CSV and plain text.

In the episode, Martin Splitt explained that Google runs PDFs through a converter during indexing that turns them into an HTML representation. From that point on, Google's internal systems treat the document much like any other web page.

Splitt placed the converter in the indexing stage, after rendering and just before a document is considered for the index. Google runs similar converters for rich text, word processing files, Excel sheets and even Lotus Notes documents.

That has two practical consequences. Text links inside a PDF survive the conversion and are crawled normally. Images do not fare as well. Splitt said his understanding is that because embedded images have no URL of their own, Google probably cannot process them for Google Images like normal images, though he noted that could change.

Google's documentation also says the file type is decided by the Content-Type header the server returns, not by the file extension, although Google may fall back to the extension or re-parse the file if the header is missing or wrong. If your server is mislabelling PDFs, that is worth checking.

PDFs can rank and can appear in AI Overviews

Converted PDFs go through the same core indexing and ranking systems as HTML pages. Splitt said that once converted, a PDF is internally a normal HTML page and Google does not care whether something was a PDF originally, so PDFs can appear in AI Overviews and AI Mode like any other page. John Mueller said PDFs work in Google's AI features, and that he assumes other AI systems also use PDFs for training and probably for grounding. Beyond that, the AI guidance was brief and general: Mueller said a PDF is not going to wreck your visibility in AI search, but if the same content can go into HTML, that makes everything a little easier.

That is also the part of the episode with the least detail. Most of the material is ground Google has covered before, with the possible exception of the generative AI angle, where Google did not say much. Google has previously said that PDFs are not mobile friendly, that it indexes PDFs but refreshes them slowly, and that Googlebot's file limit for PDFs is 64MB.

So a PDF can rank. The real question is whether it is the best version of that content to put in front of Google and a reader on a phone.

On ranking itself, Mueller raised one caveat: length. He said a whole book in a single PDF is probably no different from a whole book on one HTML page, and search engines can struggle to tell whether the document as a whole deserves to rank or just one sentence buried inside it. Splitt agreed. Splitt summed up the AI side as "good SEO is good GEO": a PDF that works for Search works for Google's AI systems too.

How much of a PDF Google will read

In the episode, Martin Splitt said he assumed PDFs get a larger limit than HTML pages but did not know the figure, adding that Google is not keen on documenting limits because they can change.

Google's own Googlebot documentation does publish numbers. For Search, Googlebot reads up to 64MB of a PDF and up to 2MB of other supported file types, and both limits are measured on the uncompressed file. Once the cutoff is reached, Googlebot stops fetching and sends only the part it already downloaded for indexing.

For most business documents 64MB is generous. It bites on image-heavy brochures and scanned reports, where a few high-resolution pages can push a file past what anyone on a mobile connection wants to download.

Scanned pages and password protection stop Google reading PDFs

The back half of the episode is a list of ways PDFs fail in Search. These are the ones that matter most for a small business:

• Scanned or rasterised pages. If the PDF is a picture of text rather than actual text, Google cannot read it without OCR. The quick test is to open the file, highlight some text, copy it and paste it into a text editor. If nothing comes across, Google sees nothing either.
• Mobile. A PDF has to download completely before it renders on a phone, and its fixed print layout does not reflow when the reader zooms. Google's Googlebot documentation says most sites are now indexed primarily from their mobile version, so this is a core issue rather than a side one.
• Accessibility. PDFs that are not structured properly are a barrier for screen readers.
• Duplicates and canonicals. Two copies of the same PDF are exact binary duplicates, which makes cross-domain canonicalisation hard. Mueller suggested a rel=canonical HTTP header and a link back to your site at the top of the PDF; Splitt separately recommended filling in PDF metadata such as author and description.
• Password protection. A password-protected PDF cannot be read or indexed by search engine bots.
• Slow recrawls. John Mueller said Google recrawls PDFs far less often than web pages because, like images, they tend not to change for a long time. His suggestion for getting an updated PDF picked up quickly was to upload it under a new file name, so Google finds it as a new URL, instead of overwriting the old file.
• Auto-generated print PDFs. CMS tools that produce a PDF copy of every page can leave the PDF competing with the live page in results, and because the PDF is recrawled less often, the version Google shows may be out of date.

In our experience the first and the last of those are the common ones on Australian small business sites. Usually it is a scanned price list uploaded straight from the office copier, or a print-to-PDF plugin that nobody remembers installing.

A few smaller points from the same part of the episode are easy to miss. Splitt said a PDF is harder to change than a CMS page, because editing one needs Adobe Pro or a similar tool; otherwise you keep the original file and regenerate it. He also suggested setting HTTP caching to match how often the file changes, so a catalogue updated each quarter can be cached for a couple of months. Mueller said the slow recrawl is partly deliberate, since Google does not want to keep pulling large files from a server.

For anything fresh or dynamic, such as a regularly regenerated map of a region, Mueller's advice was ideally to keep the PDF from being crawled and indexed, because it will always lag behind the live version.

The restaurant menu debate

The episode gave the restaurant menu its own chapter, and it is a fair stand-in for every small business that has a PDF doing the job of a web page.

Google's position is that HTML should be the default. It is easier to edit, reflows on a phone and loads a little faster, and Google recrawls it more often than PDFs. PDFs make sense for content with specific formatting or print requirements, forms, and long-form documents that must keep a fixed layout.

Splitt's own example was a holiday lodge registration form: if a PDF makes it easier to process guests, publish it as a PDF.

For a restaurant, Google said a PDF menu is acceptable if building an HTML version is impractical. A menu on a web page can be updated in minutes when a dish or price changes, loads on a phone without a download, and gives Google and AI systems clean text to work with. A PDF menu is slower to update and to open on a phone, and only gives Google usable text if the text can be selected and copied.

The llms.txt warning

The episode opened with an unusual question about whether an llms.txt file can be saved as a PDF. The short answer from Google was no. Files meant to be read by machines, like llms.txt, should stay as plain text, because the whole point of the format is to be simple and lightweight. Wrapping one in a PDF defeats the purpose.

Audit every PDF a customer can reach from Google

Start by opening your website and listing every PDF a customer might land on from Google: menus, price lists, service brochures, catalogues, application forms and reports.

For each one, ask whether it needs to be a PDF. If it is a menu, a price list or a service overview, it almost certainly should be a web page, with the PDF kept as an optional download for people who like to print.

For the PDFs that stay, run the copy-and-paste test to make sure the text is real text, check the file is not password protected, fill in the author and description metadata, and put a link back to your site on the first page. If you update a PDF, give it a new file name so Google picks up the change sooner.

Finally, check whether your CMS is auto-generating print PDFs of your pages. If it is, and you did not ask for it, turn it off, or keep those PDFs out of the index with a noindex X-Robots-Tag header (or point a rel=canonical header at the web page) so they stop competing with the pages you actually want to rank.