To keep a publicly accessible WordPress PDF out of Google Search, return an X-Robots-Tag: noindex header on the PDF response itself. Setting noindex on the page that links to it is not the same action. For a confidential file, use access controls instead of relying on search instructions.
Google's noindex documentation supports response headers for non-HTML resources. Google must be able to fetch the resource to discover that directive, so blocking the PDF in robots.txt can prevent the intended noindex processing.
Inventory the actual document URLs
Start with a harmless public document. Copy its direct file URL from the published page and follow any redirects. Record the final host and path, including a CDN host if the file is offloaded. Distinguish the PDF, its WordPress attachment page, an embedded viewer page, and old revisions.
Make a small policy list: documents that should remain searchable, public documents that should not be search landing pages, and documents that must require authorization. Do not apply a blanket uploads-directory rule unless that is genuinely the site's intended policy.
Put the rule where the bytes are served
The responsible layer may be the web server, object storage delivery, or a CDN response policy. A WordPress SEO plugin can control a post's HTML without controlling static files delivered outside WordPress. Ask the hosting owner which component produces the final PDF response before adding another plugin.
For one public test file you own, inspect a normal GET while discarding the body:
curl -sS -L --max-time 20 -D - -o /dev/null 'https://example.com/wp-content/uploads/public-guide.pdf'
Replace the example URL. Read the final response after redirects, not just an intermediate header. Expect the actual PDF content type and the intended indexing directive. Do not put signed private URLs in shell history or shared reports.
Target: Final file response checked. Control: Searchable document unaffected. Cache: Public response is current. Google: Recrawl still required. Explanatory checklist, not a customer test result.
Check the scope before clearing cache
Test one targeted PDF and one public document that should stay indexable. Confirm the exclusion has not spilled onto service pages, images, or the whole site. If the origin is correct but the public response is stale, invalidate the affected file through the existing delivery workflow and test again.
Also check alternate public URLs and old filenames that still serve the same document. An excluded attachment page does not cover a separate storage host. Record which URLs were actually verified rather than declaring the whole media library fixed.
Verify discovery, not instant disappearance
Inspect the exact resource in Search Console where supported and monitor the next crawl. A correct live header does not prove Google has already reprocessed the file. If a sensitive document was exposed, restrict access and involve the responsible security team; do not wait for recrawling as a containment measure.
Our password-protected page and public-media guide explains the separate authorization boundary. HandL WP can review the file-serving and indexing path while preserving access for the users who legitimately need the document.
References reviewed October 9, 2026. Examples are explanatory, not customer test results.