Google's Search Relations team yesterday published episode 115 of its Search Off the Record podcast, a 25-minute discussion of how Google Search handles PDF files in which Martin Splitt and John Mueller described an internal converter that turns PDFs into HTML before indexing, said converted PDFs rank and appear in AI Overviews and AI Mode like any other page, and said they did not know the specific PDF size limit - a figure Google's own crawler documentation has stated as 64MB since at least February 2026.

In Short

Two Google employees spent an episode of their podcast explaining that Google turns every PDF it finds into a regular web page behind the scenes before deciding where it ranks. That matters to anyone who publishes menus, forms, reports or catalogues as PDFs, because those files can show up in normal search results and in Google's AI answers, but only if the text inside them can be selected and copied. The catch is that Google rarely goes back to check a PDF for changes, so an updated PDF kept at the same address may stay out of date in search for a long time.

What was published

The episode, titled "PDFs in Search: Indexing, AI & Pitfalls" on the Google Search Central YouTube channel, carries the date 13/10/2026 on its video page. At the time the page was captured, it showed 133 views, 8 likes and one comment, on a channel with 808,000 subscribers. The speakers listed in the description are Martin Splitt and John Mueller. A nine-page transcript was published alongside it, and the conversation runs from an introduction at 00:11 to an outro at 24:46.

The format is informal. Mueller, who introduces the show as the podcast where "we, the Search Relations team, take you a little bit behind the scenes at Google Search," asks questions and Splitt answers most of them. Several answers are framed as personal understanding rather than documented fact. Mueller acknowledges this directly midway through: "I realize some of these things maybe we just don't know the details, so we're kind of trying to extrapolate from what we do know."

That caveat matters when weighing the content. Search Off the Record is a Google-produced podcast, not documentation, and the statements in it carry the hedges the speakers attached to them.

The converter inside indexing

The most technical portion of the episode concerns where PDFs go once Googlebot fetches them. Splitt began by distinguishing PDF from text formats. "I think what a lot of people don't realize is that PDF is a binary format versus a plethora of plain text formats," he said. A text file, a Markdown file or an HTML file can be read in a text editor; a PDF opened the same way produces "lots of strange-looking characters on your screen because it is a binary container, so to speak, not standard plain text."

Google does not run a PDF viewer on these files. According to Splitt, Search has "a component called a converter," and its position in the pipeline is specific: "The converter component is part of what happens in indexing. It happens right after rendering and right before something potentially makes it into the index."

The converter is not PDF-specific. Splitt listed converters for "rich text files, document files, Excel sheets, and Lotus Notes documents for some reason," alongside the PDF converter. The output in every case is HTML, because, in his words, "the processing in the rest of the pipeline pretty much only works with HTML." Images and videos are excluded from that statement; Splitt said they "go to slightly different pipelines."

The practical consequence is that the HTML version is what Google evaluates. Splitt described the conversion as aiming for "a representation in HTML that is as true as is possible to that original format," which is why links embedded in a PDF are visible to Google. "Because we convert it into an HTML page and then the rest of our systems are like, 'I know how to deal with an HTML page,' and they just do their stuff."

That description sits beside earlier reporting. A PPC Land article from July 2024 on Google Search and JavaScript rendering noted that non-HTML files such as PDFs are typically not processed through headless browsing. Splitt's account does not contradict that: he placed the converter after the rendering step, not inside it. What the episode adds is the name and position of the component that handles PDFs instead, and the fact that it shares machinery with converters for spreadsheets and word-processing files. The broader process is what the industry calls indexing, and the episode is one of the few public descriptions of a sub-stage within it.

Images inside PDFs

Mueller asked whether Google picks up images embedded in a PDF. Splitt's answer was qualified. "I think we might actually pick them up. I'm not sure how we would process them," he said. Image Search normally works from image URLs, and an image embedded inside a PDF has none. "So I think we understand there is an image, but I don't think we can actually process it like a normal image for image search. But that might change or might have changed; that's my current understanding of how that pipeline works."

For publishers who distribute product sheets or catalogues with photography embedded in PDFs, that is a statement of uncertainty from Google rather than a rule, and the episode offered nothing firmer.

The size limit nobody in the room could state

The section most likely to draw attention from technical SEO practitioners concerns file size. Mueller asked how size limits work for PDFs. Splitt said: "Probably fetching the PDF has a different limit than the web page limit, but probably there's a limit for the web page kind of representation. I'm not so sure where these limits are applied."

He went on: "I assume that we have a larger file limit, just the same as we do for videos and images. But I don't know the specific limit for PDF files."

Google has, however, put a number in writing. When Google updated its Googlebot documentation on February 3, 2026, the per-resource limit for HTML and other supported file types fell from 15MB to 2MB, and the same documentation stated that Googlebot fetches the first 64MB of a PDF file. On March 31, 2026, Google published two Search Central blog posts that repeated the 2MB HTML cap and the 64MB PDF figure, with a 15MB platform default for crawlers that set no limit of their own. Those posts distilled episode 105 of the same podcast, recorded by Gary Illyes and Splitt, in which Illyes mentioned 64MB while saying he was unsure of the exact figure.

Splitt's recollection of the HTML number in yesterday's episode was also vague. "I know that we did discuss - what was it, two megabytes? Something megabytes. I don't even remember the number because to me they are large enough for normal websites to not be affected by this."

He offered a reason Google avoids committing to limits: "You can change this limit. So whatever would be the limit today might actually differ in the future. That's why we are not super keen on documenting it, because we know that whatever we say keeps floating around for a really long time." He described a scenario in which widespread use of very large files would prompt an increase: "If we see like, 'Oh, everyone now does a hundred-megabyte PDFs for some reason,' then we might just bump it up because we would otherwise lose interesting and useful information on the internet."

The tension is plain. Google's documentation does carry the 64MB figure; two members of the team responsible for explaining Search to site owners said in a published episode that they did not know it. Mueller instead invited outside testing. "I'm sure there are a bunch of super smart SEOs out there who will take a PDF from Project Gutenberg and be like, 'At which sentence does this indexing stop?'" he said. Splitt added: "So if you all find out what the limit is by experimentation, let us know."

A second open question went unanswered. Splitt distinguished between the fetch limit and a possible limit on "the web page kind of representation" - the HTML the converter produces. Google has not published a figure for the converted output, and the episode did not supply one. A 64MB PDF could in principle produce an HTML representation far larger than the 2MB cap applied to fetched HTML; whether any cap applies at that stage is not known from either source.

Ranking, AI Overviews and AI Mode

On ranking, the speakers were unambiguous. Mueller asked whether converted PDFs "can rank normally in search." Splitt replied: "Yeah, indexing and ranking is pretty much the same as any other document." Asked whether that extends to "AI overviews, AI mode, all of those things," Splitt said: "Because it is basically internally a normal HTML page, nothing wild." He drew a parallel to JavaScript: "we don't track if something was generated by JavaScript, and we don't care if something was a PDF originally."

Mueller later extended the claim beyond Google. "We already talked about GEO - whether PDFs work for that - and at least at Google, yes, they do. I have seen them also referenced in other AI systems. I assume that most of the AI systems want to be able to train on all of this content, so they want to use PDFs. And they probably also similarly use it for grounding."

That sentence carries two separate points. The first concerns GEO, the term for optimizing content to be cited in generative answers. The second is an admission that AI systems, by Mueller's assumption, want PDF content for training as well as for grounding at query time. Neither he nor Splitt addressed how a publisher might allow ranking while declining training use, and the controls they did mention - password protection and robots.txt - block search access as well.

Splitt closed the topic with a phrase Google has used repeatedly this year. "Absolutely. And good SEO is good GEO. So a PDF that works for your website works for AI systems as well. At least on ours." The same formulation headlined a Think with Google piece in June 2026 in which Google's Brendon Kraham told CMOs that good SEO is still all that is needed for AI. That position has drawn criticism: in May 2026, iPullRank's Mike King argued that Google's AI search guide serves the platform over the open web, contending that retrieval mechanics such as passage selection differ from traditional ranking in ways Google's guidance plays down. The PDF episode does not engage with that debate; it restates Google's position.

The pitfalls Google listed

Most of the episode's second half covered problems with PDFs. Some apply to search engines; several apply to users.

Rasterized pages

Splitt called rasterized pages "the worst one." A PDF can store pages as images, which removes the text layer entirely. "So you lose all text content," he said. His test requires no tools: open the file, select all text, and paste it into a document or text file. "If text shows up, congratulations, it's not lost in the rasterized page. If it's not there, then that is a problem. Then we can't see the content inside the PDF."

He added that rasterized pages are, by default, also difficult for screen readers and other assistive technology, "unless the PDF generator has made an effort to make sure that the content is accessibly available to users."

Mueller connected this to scanned books and archives. "Some systems might be able to do OCR (Optical Character Recognition) on the image, but you kind of can't rely on it." Neither speaker said whether Google's converter applies OCR to scanned PDFs. The phrasing leaves that unstated.

Mobile performance and reflow

Splitt noted that PDFs on mobile devices "have to download entirely and then can be shown, versus HTML, which starts to show something on screen as quickly as possible." He also pointed to zoom behavior: "some PDFs are really weird when you try to zoom in on them - they don't reflow, for instance." Mueller agreed that PDFs "stick to their layout, which is nice as an author who wants to know where exactly the image sits in the text, but it's not always convenient on a small screen."

Identical files and canonicalization

Mueller raised duplication. Because a PDF is "this binary blob," a copy downloaded and re-hosted elsewhere is byte-for-byte identical to the original. "So canonicalization is a lot harder there because it's not like 'this page is mostly the same or very similar.' It's really 'this is one-to-one identical as we've seen elsewhere.'"

He named two mitigations. One is the rel="canonical" link header in the HTTP response, "which probably not a lot of people do because it's cumbersome." The other is a visible link to the publisher's homepage at the top of the PDF, which survives conversion: "when Google's systems turn that PDF into an HTML page, they automatically keep that link with it." Splitt added that PDF metadata fields such as author, description and source link are worth filling in.

Google updated its canonicalization troubleshooting guide on July 10, 2026, to say that pages can stay in a duplicate cluster for up to two weeks after a fix. The episode did not say whether that timing applies to PDFs, which, by Mueller's account, are refetched less often than HTML.

Blocking and protection

Splitt said password-protected PDFs cannot be read by search engines, and that robots.txt "basically prevents us from looking at the PDF anyway." Printing protection was mentioned, with no statement on whether it affects indexing.

Recrawl frequency and the new-filename approach

One statement in the episode carries direct operational weight for anyone publishing price lists, catalogues or rate cards as PDFs. Mueller said Google's systems treat PDFs like images when deciding how often to refetch them. "So our systems are not going to refetch the PDF file every couple of minutes, because they basically assume that this file is probably not going to change for a really long time."

His conclusion: "That also means that if you do want to make changes to a PDF file, it can make sense to just use a new file name." A new URL, once linked, is discovered and crawled as new content. He tied the slow refresh to server load: "We don't want to just fetch a whole bunch of really large files from a server, which could cause problems."

No interval was given. For comparison, Gary Illyes presented internal data at Search Central Live in Barcelona on October 2, 2026, showing that discovering a new URL typically takes about 20 hours while refreshing a known URL takes about 30 days. Those figures, reported from an attendee's recap, covered URLs generally. If PDFs are refreshed less often than the typical known URL, as Mueller described, an edited PDF at an unchanged address could remain stale in search for longer than a month. That is an inference from the two statements; Google gave no PDF-specific figure.

Mueller also recalled a CMS - "maybe Joomla or something like that" - that offered PDF versions of every page. Because the PDFs were refreshed less often than the HTML, "you could end up in this weird state where your old content is indexed as a PDF and your new content as an HTML page," with the two versions competing and out of sync. His view was that frequently changing content generated as PDFs is better kept out of the index.

Splitt suggested HTTP caching settings matched to update frequency, citing a quarterly catalogue as an example where caching "for a couple of months" would be reasonable.

LLMs.txt as a PDF

The episode opened with a joke that carried a real position. Mueller asked whether it makes sense to save an llms.txt file as a PDF. Splitt: "First things first, why does this keep coming up? And second, no." He explained: "The whole idea of LLMs.txt was to make the content available in the simplest possible form for LLMs to consume it. And PDF is not the simplest form of content on the web."

When Mueller suggested a Markdown version for other crawlers, Splitt replied, "We're back to Markdown. We had an episode on Markdown before." Mueller closed the episode with: "And no LLMs.txt in PDFs, please. I mean, do what you want, but I don't think it makes much sense."

The file's standing at Google remains mixed. In the previous episode, number 114 on sitemaps, published October 1, 2026, Mueller said Google's systems cannot process llms.txt as a sitemap and that he "would not rely on it." Yet on May 5, 2026, Google added an llms.txt check to Chrome Lighthouse under agentic browsing audits. Usage data suggests the file draws little traffic regardless of format: a July 2026 report found that 97% of llms.txt files received zero requests in May 2026, according to Ahrefs server-log research, even as adoption rose 8.8 times in a year according to Originality.ai. Earlier, in February 2026, Mueller had questioned separate Markdown pages built for AI crawlers, asking why LLMs would need a page "that no user sees."

When PDFs make sense, by Google's account

Asked whether site owners should publish PDFs, Splitt said yes "if your content warrants it," naming specific formatting requirements, print fidelity and interactive forms. His example was a holiday lodge publishing a registration form. He also noted his own preference: "Obviously HTML is a really flexible format and I prefer that."

Restaurant menus came up twice. Splitt said a printed menu uploaded as a PDF is "better than not having your menu on the website at all." Mueller, asked directly, gave the same answer with a qualification: if the choice is between a PDF menu and an HTML page, he prefers HTML because "it's easier to interact with," zooms better, reflows on mobile and loads faster. For small restaurants with limited time, he said keeping only the PDF is understandable, and "if it's indexable text... then we can use it for search."

The YouTube description summarizes the same point in its takeaways: "A PDF menu is better than no menu at all for restaurants, but a responsive HTML web page provides superior performance, accessibility, and user experience."

Discrepancies between the two documents

The transcript and the YouTube page describe the same episode, but they differ in places. The video description lists one of the advice areas as "SEO, AEO (SEO)," an apparent editing error in Google's own text. Some chapter timestamps in the description do not match the transcript: the description places "Mobile connection delays, layout locking, and zoom issues" at 12:53, where the transcript shows Mueller beginning his point about scanned pages, with Splitt's mobile remarks starting at 13:17. The description also lists how PDFs are "referenced in Google Search, AI Overviews, and broader AI systems for training and grounding" as a covered topic, whereas the transcript records that point only as Mueller's assumption ("I assume that most of the AI systems want to be able to train on all of this content").

Why this matters for marketers and publishers

PDFs remain the default container for a long list of commercial material: media kits, rate cards, whitepapers, annual reports, product specification sheets, menus and registration forms. The episode confirms that Google indexes such files through the same downstream systems as HTML pages, and that they are eligible for AI Overviews and AI Mode. For marketers measuring where brand content surfaces in Google's AI features, that puts PDFs within scope.

It also exposes three operational gaps. The first is freshness: by Mueller's account, PDFs are refetched rarely, so pricing or availability information in a PDF at a stable URL may lag. The second is duplication: syndicated or re-hosted PDFs are exact copies, and the canonical signal that resolves duplication for HTML is set in an HTTP header that, Mueller conceded, few publishers configure. The third is size: Google's documentation states 64MB, two of its spokespeople said they did not know the number, and neither could say whether a separate limit applies to the converted HTML.

The training point is the least discussed and arguably the most consequential. Mueller's remark that AI systems "want to be able to train on all of this content" was presented as context for GEO, not as a disclosure, and the episode offered no mechanism for a publisher to separate search visibility from model training for PDF content.

Timeline

Summary

Who: Martin Splitt and John Mueller of Google's Search Relations team, hosts of the Search Off the Record podcast published on the Google Search Central YouTube channel.

What: Episode 115, "PDFs in Search: Indexing, AI & Pitfalls," described a converter component that turns PDFs into HTML during indexing, stated that converted PDFs rank and appear in AI Overviews and AI Mode like other pages, listed problems including rasterized pages, identical-file canonicalization and slow recrawling, and included both hosts saying they did not know the PDF size limit that Google's documentation states as 64MB.

When: The episode was published yesterday, October 13, 2026.

Where: On the Google Search Central YouTube channel, with a published transcript; the guidance concerns Google Search globally.

Why: PDFs carry a large share of commercial content such as menus, rate cards, catalogues and reports, and the episode sets out how Google processes them, what limits apply, and why an edited PDF at an unchanged URL may stay outdated in search for an extended period.