How Google indexes PDF files and why you should convert them to HTML in WordPress

#How Google converts PDF files into HTML during indexing

In episode 115 of the official Search Off the Record podcast, published on 13 October 2026, Martin Splitt and John Mueller of Google’s Search Relations team explained how Google Search handles PDF documents. Many companies and online stores still assume that uploading a catalogue or a technical guide as a PDF is the same as publishing a regular web page. The episode shows where the two are alike and where they are not.

HTML is a text format. A search engine parses HTML sequentially, recognising headings, paragraphs, lists, JSON-LD structured data and semantic directives.

The Portable Document Format (PDF) was designed for a different purpose: to keep a document’s exact visual layout when it is printed or shown on any screen. Splitt stresses that PDF is a binary container: open a PDF in a text editor and you get unreadable characters, while an HTML or Markdown file can be read as it is.

Google does not open PDFs with a viewer. According to Splitt, indexing includes a component called a converter, which runs right after rendering and right before a document can make it into the index. Google has converters for several formats (rich text files, document files, Excel sheets and even Lotus Notes documents), and one of them is the PDF converter. Its output is an HTML version of the document, as true to the original as possible, because the rest of the web pipeline works almost exclusively with HTML.

+-----------------------------------------------------------------------------------+
| The path of a PDF file through Google Search (per episode 115):                  |
| 1. Crawling the file (HTTP Content-Type: application/pdf)                         |
| 2. Rendering                                                                      |
| 3. PDF converter: produces an HTML representation of the document                 |
| 4. Links in that representation are discovered like in any HTML page              |
| 5. Indexing and ranking with the same systems as an HTML page                     |
+-----------------------------------------------------------------------------------+

That is why, in Splitt’s words, indexing and ranking a PDF is pretty much the same as for any other document, and a PDF can appear in AI Overviews and AI Mode. Google does not track whether a document was originally a PDF. The official list of indexable file types includes Adobe PDF among the supported encoded formats.

Mueller added a caveat about very long documents: a whole book in a single PDF poses the same problem as a whole book on one HTML page. The search engine struggles to tell which sentence is the reason the document should rank for a query.

#Which PDF files Googlebot can read and when OCR fails

The Google Search Central blog post on PDFs, written by Gary Illyes, sets the basic rule: Google can index the textual content of a PDF in any language and in various character encodings, as long as the file is not password protected or encrypted. If the text is embedded as images, Google may process those images with OCR algorithms.

In episode 115, Splitt names rasterized pages as the worst problem: documents in which each page is effectively an image. All text content is lost. Mueller adds scanned books archived as PDFs: some systems can run OCR on them, but you cannot rely on it.

The test both of them suggest is simple:

1. Open the PDF.
2. Select all text with Ctrl + A or Cmd + A.
3. Paste it into a Google Doc or a text file.
4. If the text shows up, Google can use it. If it does not, Google cannot see the content either.

Splitt adds that rasterized pages are also an accessibility problem: screen readers and other assistive technology cannot read them, unless the PDF generator made a deliberate effort to include the content in an accessible way.

#How large a PDF file Googlebot will download

The Googlebot documentation sets two different limits. For supported file types, Googlebot crawls the first 2 MB. For a PDF, it fetches the first 64 MB. The limit applies to decompressed content, not to the transfer size. Once it is reached, Googlebot stops the fetch and sends only the part already downloaded for indexing.

In the episode, Splitt admitted he did not remember the exact figure for PDFs and explained why Google prefers not to set it in stone: the limit can be changed, and if publishers started shipping much larger PDFs, Google might raise it so as not to lose useful information. The documentation is the current source; the figure can change.

In practice the limit affects few documents. A catalogue full of high-resolution photographs can come close to it, and then the text on the last pages may stay out of the index.

#Why links in PDFs pass PageRank but images do not rank

#How text links behave

Because the converter produces an HTML version, links in the PDF are preserved. The Google Search Central blog confirms it: links in PDF files are treated similarly to links in HTML, they can pass PageRank and other indexing signals, and Google may follow them after crawling the PDF.

• Passing authority: links inside a PDF can pass PageRank to the target pages.
• Discovering new paths: Googlebot may follow the detected targets after crawling the file.
• No nofollow: according to the same post, it is not possible to use nofollow links within a PDF document.

These links have a drawback for anyone measuring results. On a web page, clicks are captured with Google Tag Manager or the page’s analytics script. That script does not run inside a PDF opened in the browser’s viewer, so what the reader does inside the document stays outside your analytics.

#The problem with images embedded in a PDF

On a web page built with WordPress or Astro, each photo is served as a separate resource with its own URL, alt attribute, explicit dimensions and modern formats such as AVIF or WebP. That lets Google Images rank each image on its own.

In a PDF, images are part of the file itself. Splitt explained that Google normally hands image URLs to the image search pipeline, and an image inside a PDF has no URL. His reading is that Google knows there is an image but cannot process it like a normal image for Google Images, although that might change. The 2011 post was blunter: images in PDF files are not indexed, and to get them indexed you should create HTML pages for them.

If your company publishes infographics, architecture diagrams or visual comparisons only inside a PDF, do not count on them bringing traffic from Google Images.

#Why Google is slow to pick up changes to an updated PDF

Mueller explained in episode 115 that the recrawl rate for PDFs resembles that of images. Google’s systems do not refetch a PDF every few minutes, because they assume the file is probably not going to change for a long time, and they do not want to fetch lots of large files from a server, which could cause problems.

Splitt added another difference: an HTML document is easy to edit in a CMS, while a generated PDF cannot be edited without a tool such as Adobe Acrobat Pro; the usual route is to keep the original file and regenerate the PDF.

If you change a price catalogue, a technical manual or a regulation by uploading a new version under the same name and URL, the snippet Google shows and AI Overviews answers can keep relying on the old version for quite a while. Google does not publish a time frame, so there is no reliable figure to give.

#How to get an updated PDF document indexed sooner

Mueller’s recommendation is to use a new file name. When Google finds a link to that new URL, it recognises it as a new document and goes off to crawl and index it. On top of that we add, as our own practice and not as Google guidance, a 301 redirect from the old path:

Versioning strategy to avoid stale content in the index:
Old version:  https://example.com/catalogues/technical-specifications-2025.pdf
New version:  https://example.com/catalogues/technical-specifications-2026-v2.pdf

Server configuration:
Permanent HTTP 301 response from the old path to the new version.
Internal links updated to the new URL.

Splitt rounded off the advice with HTTP caching: if you know a catalogue changes every quarter, you can keep it cached for a couple of months; if a file changes often, long caching makes less sense.

#How to control the title and metadata of a PDF in Google

A PDF has no HTML title tag. According to the Google Search Central blog, Google uses two main elements to pick the title shown in results: the title stored in the file’s metadata and the anchor text of links pointing to the PDF. To give a clear signal, Google recommends updating both.

Splitt added in episode 115 that you should fill in the PDF metadata: who authored it, a description of what it is about and, if possible, a link to where it originally came from. Mueller suggested a more practical step: put a normal link to your homepage in the header of the PDF itself. When Google converts the PDF to HTML, that link is kept, and anyone who lands on the PDF from search has a way back to your site.

In a WordPress workflow this means:

1. Before uploading the PDF, check the document title, author and description fields in the program that generates it.
2. Link to the PDF from an HTML page with descriptive anchor text, not “download” or “here”.
3. Put a visible link on the first page of the PDF to the HTML page it belongs to.

#How to set up the Link rel canonical HTTP header for PDF documents

When an organisation offers a report both as a web article and as a downloadable PDF, duplication becomes a risk. Mueller described an extra problem in the episode: a PDF is a binary blob. If another site downloads your PDF and publishes it, the search engine sees two byte-for-byte identical files, and canonicalisation gets harder than with similar HTML pages.

On an HTML page, the preferred version is declared with a link rel="canonical" tag inside head. A PDF has no such section. Google’s documentation on duplicate URLs says that if you can change your server configuration, you can use a Link HTTP response header with rel="canonical", as defined by RFC 5988, including for non-HTML documents such as PDF files. Google notes that this method applies to web search results only.

The same page gives two warnings that matter for PDFs. Google does not recommend using noindex to prevent selection of a canonical page within a single site, because it blocks the page from Search completely. And you should not specify different canonical URLs for the same page with different techniques. So for a PDF you pick one of two options:

• Canonical: the PDF stays accessible and signals consolidate on the HTML page.
• Noindex: the PDF drops out of results (see the next section).

#Configuration on Nginx servers

location ~* \.pdf$ {
    # Canonical link to the main HTML version
    add_header Link '<https://example.com/technical-documentation/>; rel="canonical"';
}

#Configuration on Apache servers (.htaccess)

With the mod_headers module enabled:

<FilesMatch "\.pdf$">
    Header set Link '<https://example.com/technical-documentation/>; rel="canonical"'
</FilesMatch>

#Configuration on Cloudflare Pages and CDNs

On Cloudflare Pages and similar static hosting platforms, the rule goes in the _headers file:

/documents/*.pdf
  Link: <https://example.com/technical-documentation/>; rel="canonical"

A rule per file pattern points every PDF to the same page. If each PDF has its own HTML page, you need one rule per file or per folder.

#How to remove a PDF from Google search results

According to the Google Search Central blog, the simplest way to keep a PDF out of search results is to send the X-Robots-Tag: noindex HTTP header with the file. If the PDF is already indexed, it will drop out over time; for faster removal, the same post points to the URL removal tool in Search Console.

The robots meta tag documentation shows this case for every PDF on a site, with noindex, nofollow:

<Files ~ "\.pdf$">
  Header set X-Robots-Tag "noindex, nofollow"
</Files>

location ~* \.pdf$ {
  add_header X-Robots-Tag "noindex, nofollow";
}

If you want Google to keep using the PDF’s links to discover pages, noindex alone is enough: the same documentation says that if you do not specify nofollow, Google may use the links on the page to discover the linked pages.

There are two other routes, with different effects:

• Password: Splitt points out that search engines cannot read a password-protected PDF. That suits documents that should not be public.
• robots.txt: it stops Google from fetching the PDF. But the duplicate URLs documentation warns that Google may still index URLs disallowed in robots.txt without their content. If the goal is to keep the file out of results, the noindex header is the right tool, and Google only sees it if it can fetch the file.

#How WordPress handles PDFs uploaded to the media library

When you upload a PDF to the media library, WordPress stores the file in wp-content/uploads and creates an attachment in the database. That file is served directly by the web server (Nginx, Apache) or the CDN, without loading WordPress. This detail decides where headers are configured.

The send_headers hook fires from WP::send_headers() when WordPress handles a request. A direct request to /wp-content/uploads/2026/10/catalogue.pdf never reaches WordPress, so code in functions.php that tries to add a canonical header to that PDF does not run. The header can only be added from PHP if a plugin streams the file through WordPress, and that setup has its own cost. For static files, the header is configured on the server or the CDN, as in the section above.

The attachment also gets its own URL in WordPress: the attachment page. The WordPress 6.4 developer note changed how it behaves:

• On new installations, attachment pages are disabled and redirect to the attachment URL.
• The wp_attachment_pages_enabled option controls this: it is 0 on new installations and set to 1 when an existing site upgrades, so attachment pages keep working as before.

On a site that came from a version older than 6.4, every uploaded PDF can have, besides the file itself, a thin, indexable attachment page. Check the option value with WP-CLI (wp option get wp_attachment_pages_enabled) before deciding whether to change it.

#Risks of automatic PDF export plugins in WordPress

In the WordPress ecosystem it is common to use plugins that add a PDF download button to every post. These extensions rely on PHP libraries such as Dompdf, TCPDF or mPDF to turn the article’s HTML into a PDF file on demand.

Mueller recalled in episode 115 a case from early CMSs, possibly Joomla, which offered to view every page as a PDF. Because Google does not recrawl those files often, a site could end up with the old content indexed as a PDF and the new content as an HTML page: the two versions competed with each other and were out of sync. His conclusion: if the content is fresh and dynamic and you need to offer a PDF, keep that PDF from being indexed.

From an engineering and SEO point of view, the practice causes three problems:

1. Duplicates in the crawl: every post gains a second URL with the same text. Crawlers spend time processing copies instead of new content.
2. Server load: generating a PDF from styled HTML in PHP is an expensive operation, and if a crawler requests many downloads at once, the load lands on PHP-FPM.
3. Lost user experience and conversions: if the PDF version outranks the HTML page, the visitor lands on a static document with no contact forms, navigation or calls to action.

Splitt added that most browsers, on mobile and desktop, already let users save a page as a PDF, so site owners normally do not need to provide that feature. A print stylesheet is enough:

@media print {
  header, footer, nav, aside, .sidebar, .comments, .cookie-banner {
    display: none !important;
  }
  body {
    font-size: 12pt;
    color: #000;
    background: #fff;
  }
  a[href^="http"]:after {
    content: " (" attr(href) ")";
  }
}

With this rule, a user who wants to save the article uses the browser’s print function (Ctrl + P or Cmd + P) and gets a clean PDF generated on their own device, without using your server’s CPU.

#Why the llms.txt file should not be published as a PDF

The llms.txt proposal, published by Jeremy Howard in September 2024, defines a Markdown file at the /llms.txt path with brief background information, guidance and links to more detailed Markdown files, meant to provide content that is easy for language models to process.

Episode 115 opens with exactly this question. Mueller asks whether it makes sense to save llms.txt as a PDF, and Splitt answers no: the idea of llms.txt was to make content available to language models in the simplest possible form, and PDF is not the simplest form of content on the web. The fact that Google can process PDFs does not mean everyone else can or wants to.

The llms.txt file should stay a Markdown text file at the site root (https://example.com/llms.txt), linking to pages or Markdown files that can be read without conversion.

#When it makes sense to publish a PDF on your site

Episode 115 is not a case against PDF. Splitt lists the cases where he recommends it: when content has specific formatting requirements, when it must look a very particular way in print, or when you need interactive forms. His example is a holiday lodge that publishes its guest registration form as a PDF because that makes processing easier.

On restaurant menus, Mueller was pragmatic: a menu as a PDF beats no menu on the site; between a PDF and a normal page, he prefers the page, because it zooms better, flows on mobile and loads a little faster. If the PDF text can be selected and copied, Google can use it in search.

On AI systems, Mueller added that PDFs work at Google, that he has seen them referenced in other AI systems too, and that publishing PDFs does not destroy visibility in those systems. But if the same content can be in HTML, everything gets a little easier.

Splitt also pointed to two usability problems on mobile: a PDF has to download completely before it is shown, while an HTML page starts showing content as quickly as possible, and many PDFs do not reflow text when you zoom in.

#Technical comparison of semantic HTML and static PDF documents

Except for documents whose main purpose is print, a form or a fixed layout, content that has to rank and stay current performs better as an HTML page.

#Migration plan from PDF documents to HTML in WordPress

If your company has dozens or hundreds of PDF files with technical information, product sheets or manuals, an orderly migration to HTML pages puts that content in the format Google recrawls more often and users read better on mobile.

1. Technical inventory: use a crawler to list every .pdf file on the server and check its current organic traffic in Google Search Console.
2. Text test: run the copy and paste test on every PDF. Rasterized documents are the first candidates for HTML, because Google cannot see their content today.
3. Content reorganisation:
   • Move the most valuable information to new WordPress or Astro pages built with semantic blocks.
   • Set up permanent 301 redirects from the old PDF URLs to the new HTML pages.
4. Canonicals for files that must stay: for documents that have to remain downloadable (forms, fillable templates), add the HTTP header Link: <url>; rel="canonical" pointing to the web page that explains the document, or X-Robots-Tag: noindex if they should not appear in Google. Never both at once.
5. Metadata and a link back: fill in the title, author and description of the PDFs that stay, and add a link to your site on the first page.
6. Attachment pages: check wp_attachment_pages_enabled if the site was installed before WordPress 6.4.
7. Remove automatic generators: deactivate plugins that mass-produce PDFs and offer a print stylesheet instead.
8. Consistent internal linking: connect the new pages to the main pillars of your site architecture, following the guidelines in our WordPress security audit and our WooCommerce ERP integration projects.