X-Robots-Tag: noindex für PDFs und andere Dateien

So sieht ein PDF aus, das Google indexieren darf. Die Antwort dieser Seite auf ihren eigenen Spickzettel, abgefragt am 03.10.2026:

$ curl -sI https://www.cyberscale.io/dateien/security-header-spickzettel.pdf
HTTP/2 200
content-type: application/pdf
x-content-type-options: nosniff

Keine Zeile X-Robots-Tag. Das ist hier Absicht, das PDF soll gefunden werden. Soll es das nicht, ist diese Kopfzeile der einzige Weg, denn ein PDF hat keinen <head>, in den ein Robots-Meta-Tag passen würde. X-Robots-Tag trägt dieselben Anweisungen wie das Meta-Tag (noindex, nofollow, nosnippet und die übrigen), steht aber in der Antwort des Servers statt im HTML. Google empfiehlt den Header ausdrücklich für Nicht-HTML-Ressourcen wie PDFs, Video- und Bilddateien. Was noindex selbst tut und wann es das falsche Werkzeug ist, steht in noindex: was es tut und wann es das Falsche ist. Hier geht es um die Kopfzeile, ihre Konfiguration und die Fehler, die man mit ihr macht.

Header oder Meta-Tag#

Bei HTML-Seiten sind beide Wege gleichwertig. Google kennt keine Rangfolge nach dem Ort, nur eine Regel für Widersprüche: Bei Konflikten zwischen Robots-Regeln gilt die restriktivere. Das Beispiel in der Dokumentation ist max-snippet:50 neben nosnippet, es gilt nosnippet. Ein noindex in der Kopfzeile lässt sich also nicht durch ein index im HTML aufheben, und umgekehrt auch nicht.

Der Header hat trotzdem einen Vorzug: Er wird zentral gesetzt. Eine Zeile in der Serverkonfiguration deckt alle PDFs eines Verzeichnisses ab, ohne dass jemand die Dateien anfasst. Dieselbe Reichweite ist später die Gefahr, dazu unten.

Was in der Kopfzeile stehen darf#

Google unterstützt im X-Robots-Tag dieselben Regeln wie im Meta-Tag: noindex, nofollow, none (beides zusammen), nosnippet, max-snippet:[Zahl], max-image-preview:[Größe], max-video-preview:[Sekunden], noimageindex, notranslate, unavailable_after:[Datum], indexifembedded (wirkt nur zusammen mit noindex) und all als Standard ohne Einschränkung.

Mehrere Regeln trennt ein Komma. Es dürfen auch mehrere X-Robots-Tag-Zeilen in derselben Antwort stehen; Google fasst sie zusammen. Groß- und Kleinschreibung spielt weder beim Header-Namen noch bei den Werten eine Rolle.

Vor die Regeln lässt sich ein Crawler-Name setzen, das Beispiel aus der Google-Dokumentation:

X-Robots-Tag: googlebot: nofollow
X-Robots-Tag: otherbot: noindex, nofollow

Regeln ohne Crawler-Namen gelten für alle. Google wertet als Namen googlebot für die Textsuche und googlebot-news für Nachrichten; andere Namen ignoriert Google.

Apache: .htaccess oder Hauptkonfiguration#

Für alle PDFs unterhalb eines Verzeichnisses:

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

<FilesMatch> begrenzt die eingeschlossenen Anweisungen auf Dateinamen, die dem regulären Ausdruck entsprechen, und ist in Serverkonfiguration, virtuellem Host, Verzeichnisblock und .htaccess erlaubt. Für mehrere Endungen: "\.(pdf|docx?|xlsx?)$". Google zeigt in der eigenen Dokumentation dieselbe Konstruktion als <Files ~ "\.pdf$">; Apache nennt <FilesMatch> die bevorzugte Form.

Header set setzt die Kopfzeile und ersetzt eine vorhandene gleichen Namens. Das ist gewollt: Steht schon ein X-Robots-Tag in der Antwort, wird er ersetzt, statt dass zwei Zeilen nebeneinander ausgeliefert werden.

Zwei Bedingungen, an denen der Block scheitert:

1. mod_headers muss geladen sein. Das Modul hat bei Apache den Status „Extension“ und ist nicht in jeder Installation aktiv. Fehlt es, kennt der Server die Anweisung Header nicht, und in der .htaccess ergibt eine unbekannte Anweisung einen 500.
2. In der .htaccess braucht es AllowOverride FileInfo (oder All). Die Apache-Dokumentation ordnet die mod_headers-Anweisungen dieser Gruppe zu. Steht AllowOverride None, wird die Datei gar nicht erst gelesen; ist eine andere Gruppe freigegeben, aber nicht FileInfo, antwortet der Server mit einem internen Fehler.

Wer eine ganze Staging-Umgebung sperren will, setzt die Zeile ohne <FilesMatch> in den virtuellen Host:

Header always set X-Robots-Tag "noindex, nofollow"

Ohne always gilt die Zeile nur für Antworten mit Status 2xx. Mit always geht sie auch bei Fehlerseiten und Weiterleitungen mit; laut Dokumentation landen nur die always-Kopfzeilen in Antworten, die kein Erfolg sind.

nginx: add_header und seine Vererbungsfalle#

Dasselbe für PDFs:

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

~* steht für einen regulären Ausdruck ohne Beachtung der Groß- und Kleinschreibung, report.PDF ist also mit erfasst. nginx prüft reguläre location-Blöcke in der Reihenfolge der Konfigurationsdatei und nimmt den ersten Treffer. Steht weiter oben schon ein location ~* \.(pdf|zip)$ für einen Cache-Header, kommt dieser Block nie an die Reihe.

add_header ist in http, server und location erlaubt. Für eine ganze Umgebung gehört die Zeile in den server-Block. Und hier sitzt die Falle, die in keiner Kurzanleitung steht. Die nginx-Dokumentation hält fest: add_header-Anweisungen werden von der übergeordneten Ebene nur dann geerbt, wenn auf der aktuellen Ebene keine eigene add_header-Anweisung steht. Es ist kein Ergänzen, es ist ein Austausch.

server {
    add_header X-Robots-Tag "noindex, nofollow";

    location /downloads/ {
        add_header Cache-Control "public, max-age=86400";
        # X-Robots-Tag fehlt hier: der Block hat sein eigenes add_header
    }
}

Alles unter /downloads/ ist damit indexierbar, obwohl der server-Block das Gegenteil sagt. Wer die Umgebung mit curl nur an der Startseite prüft, sieht den Header und ist beruhigt. Abhilfe: die Zeile in jedem location-Block wiederholen, der ein eigenes add_header hat. Seit nginx 1.29.3 gibt es außerdem add_header_inherit, mit dem sich die Vererbungsregel umstellen lässt.

Ein zweiter Punkt aus derselben Dokumentation: add_header wirkt nur bei den Statuscodes 200, 201, 204, 206, 301, 302, 303, 304, 307 und 308. Für alles andere braucht es den Parameter always.

Prüfen mit curl -I#

curl -I -L https://www.beispiel.de/dateien/preisliste.pdf

-I holt nur die Kopfzeilen, per HEAD-Anfrage. -L folgt Weiterleitungen, damit man die Antwort der Zieladresse sieht und nicht die einer 301. In der Ausgabe muss eine Zeile X-Robots-Tag: noindex, nofollow stehen, oder eben nicht, je nachdem, was man erwartet.

Mindestens drei Adressen prüfen: eine HTML-Seite, ein PDF, eine Datei aus jedem Block mit eigener Header-Zeile. Der Grund steht einen Abschnitt weiter oben.

Was Google tatsächlich gesehen hat, zeigt die URL-Prüfung der Search Console: Unter „Gecrawlte Seite anzeigen“ stehen HTTP-Anfrage und -Antwort, und die Zeile „Indexierung zulässig?“ nennt den Grund, wenn die Seite ausgeschlossen ist. Im Bericht zur Seitenindexierung landet eine Seite mit Header-noindex unter „URL als „noindex“ markiert“; der Eintrag nennt die Anweisung, nicht den Ort.

Die drei Fallen im Betrieb#

Die robots.txt-Sperre. Robots-Meta-Tags und X-Robots-Tag-Header werden beim Crawlen entdeckt. Darf Google die Adresse laut robots.txt nicht abrufen, werden die Regeln nicht gefunden und ignoriert. Google schreibt ausdrücklich, dass Adressen mit solchen Regeln nicht vom Crawling ausgeschlossen sein dürfen. Wer /dateien/ in der robots.txt sperrt und den PDFs dort ein noindex mitgibt, hat das noindex weggeworfen. Ein PDF, auf das von außen verlinkt wird, kann dann trotzdem im Index landen. Die Reihenfolge, die funktioniert: erst Header, robots.txt offen lassen, warten, dann sperren, wenn überhaupt.

Das Staging-noindex, das mit umzieht. Ein noindex im Header ist unsichtbar. Es steht nicht im Quelltext, Strg+U findet nichts. Wird die Serverkonfiguration der Staging-Umgebung beim Livegang kopiert (virtueller Host, .htaccess, server-Block), zieht die Zeile mit. Die Seite ist dann live, sieht im Browser richtig aus und fällt nach und nach aus der Suche. Google hält fest, dass es je nach Bedeutung der Seite Monate dauern kann, bis der Googlebot sie wieder besucht; das gilt auch für das Entfernen der Zeile. Deshalb gehört curl -I gegen die Live-Adresse in jede Relaunch-Checkliste, direkt neben die Prüfung der robots.txt.

Header und Meta-Tag sagen Verschiedenes. Das passiert, wenn ein Plugin im HTML index, follow schreibt und der Server aus alter Gewohnheit noindex mitschickt, oder umgekehrt. Es gibt keinen Gewinner nach Ort. Die restriktivere Regel gilt, also bleibt die Seite draußen. Wer im HTML ein sauberes Robots-Tag sieht und trotzdem den Eintrag „URL als „noindex“ markiert“ im Bericht hat, sieht als Nächstes die Kopfzeilen an.

Drei Reflexe, die daneben greifen: beides setzen, um sicherzugehen (ändert an der Wirkung nichts, verdoppelt aber die Stellen, an denen man es später entfernen muss); ein Präfix für jeden Crawler (googlebot: noindex, bingbot: noindex, … ist länger als noindex und deckt weniger ab); die robots.txt als Ersatz (sie verhindert das Abrufen, nicht die Aufnahme, und macht den Header in Kombination unwirksam).

In eigener Sache: wie diese Seite es hält#

Diese Seite setzt für PDFs und den RSS-Feed keinen X-Robots-Tag, beide dürfen in den Index. Das noindex für die Dankeseite nach dem Kontaktformular steht als Meta-Tag im HTML, nicht als Header, weil es eine HTML-Seite ist und die Zeile dort beim Bau entsteht statt in der Hosterkonfiguration. Geprüft am 03.10.2026 mit curl -sI auf /dateien/security-header-spickzettel.pdf, /feed/ und /danke/.

Ob eine Seite an diesem Header oder an etwas anderem scheitert, klärt Warum Google Seiten nicht indexiert. Wenn Dubletten gebündelt statt ausgeschlossen werden sollen, ist die Antwort nicht dieser Header, sondern der Canonical-Tag, den es für Dateien ohne HTML ebenfalls als Kopfzeile gibt.

Stand 03.10.2026. Quellen abgerufen und die Abfragen an die eigene Domain am selben Tag ausgeführt.