How to Index PDFs on Google

Google has indexed PDFs for a long time. They appear in ordinary results, they can rank, and for certain queries (a product manual, a compliance document, a datasheet) a PDF is exactly what the searcher wants. Yet if you try to index a PDF on Google and then check what actually made it in, PDFs are reliably among the last files on a site to show up, and often they never do. The mechanics are mostly the same as for an HTML page. The failure modes are not.

This post walks through the ones that matter, in the order you should check them.

How Google reads a PDF

When Googlebot fetches a PDF, it extracts the text and treats it roughly the way it treats the text of a page: the words become searchable, the title shown in results comes from the PDF’s title metadata or, failing that, from the content, and links inside the PDF can be discovered and followed. Two consequences follow.

First, the text has to exist as text. A scanned document saved as a PDF is a stack of images. There is nothing to extract, so there is nothing to index against a query. If you cannot select and copy the text in a PDF viewer, Google has the same problem you do. Run scans through OCR and export a text layer before publishing, or better, publish the content as a page.

Second, a PDF has no head section. There is nowhere to put a meta robots tag, a canonical tag, or structured data. Everything you would normally declare in the HTML head has to be declared in HTTP headers instead, which is where several of the traps below live.

Why PDFs sit unindexed

Most unindexed PDFs are not being refused. They are simply never found, or found and deprioritised. The usual causes, roughly in order of frequency:

They are orphaned. A PDF gets uploaded to a media library, linked once from a blog post that itself is not indexed, and that is its entire connection to the site. No navigation points at it, no sitemap lists it. Discovery depends on a single thread.

They are missing from the sitemap. Most CMS sitemap generators list pages and posts and silently skip uploads. Google’s sitemap documentation is explicit that sitemaps are for URLs you want crawled, and a PDF is a URL like any other. If your sitemap plugin cannot include file uploads, list the PDFs in a separate sitemap file and reference it from your robots.txt or sitemap index.

The uploads directory is blocked. It is common to find Disallow: /downloads/ or Disallow: /wp-content/uploads/ in a robots.txt, usually added years ago for a reason nobody remembers. A blocked PDF cannot be crawled, so its content cannot be indexed.

An X-Robots-Tag header says noindex. Since a PDF cannot carry a meta tag, the X-Robots-Tag: noindex HTTP header is the documented way to keep one out of the index, and Google’s noindex documentation covers it precisely because it applies to non-HTML files. Some servers and CDNs apply this header to entire file types as a default. Check with curl -I on the PDF’s URL. If the header is there and you did not put it there, you have found your answer.

The content already exists as a page. If the PDF is a print version of an HTML page, Google will usually pick one of the two, and it prefers HTML. That is normally the outcome you want, so treat it as a decision rather than a defect, which brings us to canonicals.

Decide which version you want indexed

For every PDF, ask whether an HTML twin exists or should exist. Three honest positions:

1. The PDF is the canonical content (a manual, a datasheet, a form). Link to it prominently, put it in the sitemap, and leave the headers alone.
2. The HTML page is canonical and the PDF is a convenience. Declare it: serve the PDF with a Link: <https://example.com/page>; rel="canonical" HTTP header, or simply add X-Robots-Tag: noindex to the PDF and let the page do the work.
3. You have not decided. This is the position most sites are actually in, and it is the one that produces duplicate clutter and unpredictable indexing. Pick one of the first two.

For e-commerce sites this decision multiplies: spec sheets, size guides, and compliance certificates often shadow product pages one for one. The same discipline that governs indexing product pages at scale applies to their attached documents, and the broader crawl and canonical groundwork is covered in the full guide to Google indexing.

Submit the PDFs you kept, then verify

Once a PDF is crawlable, listed, and canonical, it still has to be discovered and judged. You can wait for a natural crawl, use Search Console’s recrawl request for a handful of URLs, or submit them through a pipeline in bulk.

Whichever route you take, remember that submitted is not indexed. Submission asks Google to look. Inclusion is Google’s decision, made on Google’s schedule, and a PDF is judged like any other document: readable text, a reachable URL, and some reason to exist that the HTML version does not already cover.

This is also where PDF-specific mistakes surface early if your tool checks before it sends. AIndexify runs a preflight on every URL and marks a PDF served with a noindex header or blocked by robots.txt as Couldn’t check, with the credit refunded, rather than billing a submission that cannot succeed. Documents that pass are then checked against live Google results on a fixed schedule, so each one ends the week as Indexed with a date, or Not indexed as of a date, rather than as a guess. For a catalogue’s worth of documents, a CSV upload takes up to 10,000 URLs in one submission.

The short version

Make the text real text. Put the PDF in a sitemap and link to it from an indexed page. Check robots.txt and the X-Robots-Tag header with curl before assuming anything. Decide, per document, whether the PDF or its HTML twin is canonical, and declare the choice in headers. Then submit what remains and verify the outcome instead of assuming it.

PDFs do not need special treatment so much as they need the ordinary treatment sites forget to give them. See where your documents actually stand: submit your URLs and read back what Google decided, date by date.