Why do PDFs slow down a site migration?

Why does Google treat PDFs differently from HTML pages?

PDF files are not treated as standard HTML content. Google applies a crawling logic based on the observed update frequency. A PDF published once and never modified will be crawled sporadically — sometimes weekly, sometimes monthly, sometimes never.

This approach is not a bug but a crawl budget optimization. Google prioritizes its resources for content that evolves. A static 15 MB PDF does not justify daily visits from the bot. The problem is that during a migration, this prioritization calculation can become a major hindrance.

What happens during a site migration?

During a migration, Google needs to recrawl all of your URLs — both old and new — to understand the correspondence and transfer signals. If your site contains hundreds of PDFs, Googlebot will have to process them one by one, at a slowed pace.

The bot will first identify redirects and then attempt to recrawl the new locations. But if a PDF is 8 MB and hasn't changed in three years, Google will not prioritize it. The result is that your crawl budget gets depleted on secondary content while your strategic pages are left waiting.

Do large PDFs present a specific problem?

Yes, and John Mueller explicitly states this. The larger the file, the more bandwidth and processing time it consumes on Google's side. A 20 MB PDF can use as much crawl budget as 50 lightweight HTML pages.

During a migration, this friction is amplified. Google will have to download these files from the new server, verify that they match the old ones, extract text, and analyze internal links. All of this takes time — and that time is taken away from crawling your truly strategic content.

• PDFs are crawled less frequently than HTML because they rarely change
• A large PDF consumes a lot of crawl budget compared to a standard page
• During a migration, this sluggishness delays the overall site indexing
• Google does not prioritize PDFs if they haven’t been recently modified
• The file size is a blocking factor for efficient crawling

Is this statement consistent with real-world observations?

Absolutely. We regularly see migrations being blocked for weeks due to unoptimized PDF catalogs. An e-commerce client with 400 product sheets in 5 MB PDFs can easily consume 80% of the crawl budget without generating a single penny of revenue.

What’s interesting is that Mueller does not say that Google refuses to crawl PDFs — he only says it takes more time. In practice, this means that if you migrate without cleaning up your stock of PDFs, you will slow down your traffic recovery by several weeks. This is from experience.

What nuances should be applied to this statement?

The first nuance: not all PDFs are created equal. A strategic whitepaper of 500 KB that generates conversions deserves to be crawled quickly. An old 12 MB report that no one has consulted since 2018? No. Google does not make this distinction on its own — it’s up to you to assist it via robots.txt, priority sitemaps, or outright deletion.

The second nuance: the update frequency matters, but it’s not the only factor. A PDF linked from your homepage will be crawled more often than an orphan PDF, even if it is three years old. The internal linking and click depth also play a role. [To be checked]: we lack public data on the exact weight of these factors compared to content freshness.

In what cases does this rule not apply?

If you have few PDFs (fewer than 50) and they are lightweight (less than 1 MB each), the impact will be marginal. Google will process them without saturating your crawl budget. The real problem arises when you have hundreds of heavy files — typically seen in publisher sites, technical media, or research institutes.

Another case is if you prepare for migration properly by cleaning up outdated PDFs in advance, compressing files, and submitting a clean XML sitemap, Google won’t have to waste time. The rule still applies, but you mitigate its effects.

What should be done concretely before a migration?

First, audit your PDFs. Pull the complete list from your sitemap or via Screaming Frog. For each file, note: size, last modified date, number of organic visits over 12 months, incoming backlinks. You will quickly identify the parasites — those 8 MB PDFs that have never been consulted will weigh down your migration.

Next, ask yourself the brutal question: does this PDF need to remain indexable? If the answer is no, deindex it via meta robots noindex in the HTTP header (yes, this is possible for a PDF). If the answer is “maybe,” consider converting it to an HTML page — Google prefers it, and you maintain control over the semantic markup.

How to optimize the PDFs that need to remain?

Compress them ruthlessly. There are tools like Adobe Acrobat Pro, Ghostscript, or APIs like iLovePDF that can reduce size by 60 to 80% without noticeable quality loss. A 6 MB PDF reduced to 1.5 MB consumes four times less crawl budget.

Add structured metadata in the file properties: title, author, description. Google reads them and uses them for display in the SERPs. A well-tagged PDF has a better chance of being crawled quickly than a raw file without context.

What mistakes should absolutely be avoided?

Don’t let duplicate PDFs hang around. Googlebot will crawl them all, realize they are identical, and waste budget for no reason. Use 301 redirects or canonicalize via the HTTP Link header if multiple URLs point to the same file.

Another classic error: not submitting a dediated XML sitemap for PDFs. Google takes longer to discover them through natural crawling. A clean, updated sitemap post-migration speeds up processing. And most importantly, don’t migrate your PDFs last — integrate them into the overall redirect plan right from the start.

• Audit the weight and usefulness of each PDF before migration
• Compress large files to reduce crawl budget consumption
• Deindex outdated or non-strategic PDFs via meta robots
• Submit a dedicated XML sitemap for PDFs after migration
• Check for duplicates and canonicalize if necessary
• Monitor PDF crawling via Search Console during the 4 weeks post-migration