Das Problem

Du checkst Google Search Console und siehst plötzlich:

Ausgeschlossen durch “noindex”-Tag

URL: https://deathstar.lan/

Was zum…? Du hast nie noindex gesetzt. Deine nginx-Config ist sauber. Trotzdem:

curl -sI https://deathstar.lan/ | grep -i x-robots
X-Robots-Tag: noindex, nofollow

Der Header ist da. Aber woher?

TL;DR

add_header Direktiven außerhalb von server{} Blöcken werden von allen Server-Blöcken geerbt - außer wenn der Server-Block selbst mindestens ein add_header hat. Ein einziges add_header in deinem Server-Block blockt die gesamte Vererbung.

Die Diagnose

Du willst wissen wo das herkommt. Hier ist wie du es findest:

1. Prüfe welche Configs add_header außerhalb von server{} haben

grep -rn "add_header" /etc/nginx/ | grep -v "server {"

Was du suchst:

/etc/nginx/sites-enabled/admin.conf:2:add_header X-Robots-Tag "noindex, nofollow";

Wenn du eine Zeile ohne server { in den vorherigen 5 Zeilen siehst, ist das dein Problem.

2. Prüfe welche Header deine Site tatsächlich sendet

curl -sI https://deathstar.lan/ | grep -iE "x-robots|x-frame|x-content"

Bad Output (Problem):

X-Robots-Tag: noindex, nofollow

Good Output (nach Fix):

X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff

3. Prüfe ob dein Server-Block überhaupt ein add_header hat

grep -A50 "server_name deathstar.lan" /etc/nginx/sites-enabled/deathstar.conf | grep "add_header"

Falls keine Ausgabe: Dein Server-Block erbt alle Header von http{}.

Falls Ausgabe: Dein Server-Block ignoriert geerbte Header.

Das perfide

nginx zeigt dir keine Warnung. Du hast add_header X-Robots-Tag in /etc/nginx/sites-enabled/admin.conf (Zeile 2, außerhalb von server {}), und dieser Header wird stillschweigend an alle anderen Server-Blöcke vererbt - auch an deathstar.lan, das indexiert werden soll.

Das Verhalten ist:

  • ✅ Dokumentiert (nginx Docs erklären es)
  • ❌ Aber nicht intuitiv (ein Header in admin.conf betrifft deathstar.conf)
  • ❌ Schwer zu debuggen (kein Log-Entry, kein nginx-Fehler, nur Google beschwert sich)

Du findest das erst wenn Google dir Wochen später sagt: “Übrigens, deine Seite ist nicht indexiert.”

Die Ursache

nginx hat eine Hierarchie: http{} → server{} → location{}. Direktiven wie add_header werden von oben nach unten vererbt.

http {
    # Diese Zeile steht vielleicht in einer anderen Config-Datei
    add_header X-Robots-Tag "noindex, nofollow";

    server {
        server_name deathstar.lan;
        # Kein add_header hier = erbt X-Robots-Tag von http{}
    }

    server {
        server_name rebellion.local;
        add_header X-Frame-Options "SAMEORIGIN";
        # Hat eigenes add_header = erbt NICHTS von http{}
    }
}

Das Problem: Irgendwo in deinen nginx-Configs steht ein add_header X-Robots-Tag außerhalb eines server{} Blocks. Das kann sein:

  • In /etc/nginx/nginx.conf
  • In einer inkludierten Datei unter /etc/nginx/conf.d/
  • In einer anderen Site-Config die außerhalb ihres server{} Blocks Direktiven hat

Die Lösung

Option 1: Dummy-Header setzen (schnell)

Füge ein beliebiges add_header in deinen server{} Block ein. Das blockt die gesamte Vererbung:

server {
    server_name deathstar.lan;

    # Blockt alle vererbten add_header Direktiven
    add_header X-Powered-By "Death Star Reactor Core" always;

    # ... rest der Config
}

Option 2: Alle gewünschten Header explizit setzen (sauberer)

server {
    server_name deathstar.lan;

    # Security Headers explizit setzen
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;

    # Kein X-Robots-Tag = Google kann indexieren
}

Option 3: Problem an der Wurzel beheben

Finde und entferne das add_header das außerhalb von server{} Blöcken steht:

# Finde alle add_header die NICHT in einem server{} Block sind
grep -B5 "add_header X-Robots" /etc/nginx/sites-enabled/*.conf

Expected Output (zeigt das Problem):

# /etc/nginx/sites-enabled/admin.conf
# Zeile 2:
add_header X-Robots-Tag "noindex, nofollow";

server {
    server_name admin.deathstar.lan;

Fix: Verschiebe die Zeile in den server{} Block:

server {
    server_name admin.deathstar.lan;

    # Nur für diesen Host, nicht global
    add_header X-Robots-Tag "noindex, nofollow" always;
}

Verifikation

Nach dem nginx-Reload:

sudo nginx -t && sudo systemctl reload nginx

Before (Problem):

curl -sI https://deathstar.lan/ | grep -i x-robots
X-Robots-Tag: noindex, nofollow

After (Fixed):

curl -sI https://deathstar.lan/ | grep -i x-robots
# Keine Ausgabe = kein X-Robots-Tag = indexierbar

✅ Google kann jetzt wieder indexieren.

Warum passiert das?

Oft hat man mehrere Sites auf einem nginx Reverse Proxy. Eine interne Anwendung (Admin-Panel auf admin.deathstar.lan, Staging-Umgebung auf staging.rebellion.local) soll nicht indexiert werden:

# /etc/nginx/sites-enabled/admin.conf
add_header X-Robots-Tag "noindex, nofollow";  # ← AUSSERHALB von server{}!

server {
    server_name admin.deathstar.lan;
    proxy_pass http://192.168.66.10:8080;
}

Diese Zeile landet effektiv im http{} Block und wird von allen anderen Server-Blöcken geerbt - auch von deathstar.lan das indexiert werden soll.

Die Falle bei location

Dasselbe gilt für location{} Blöcke:

server {
    server_name deathstar.lan;
    add_header X-Frame-Options "SAMEORIGIN";

    location / {
        # Erbt X-Frame-Options
        proxy_pass http://192.168.66.20;
    }

    location /api/ {
        add_header Content-Type "application/json";
        # Hat eigenes add_header → erbt NICHTS
        # X-Frame-Options fehlt hier!
        proxy_pass http://192.168.66.21;
    }
}

Das Problem: /api/ hat keinen X-Frame-Options Header mehr, weil das add_header Content-Type die gesamte Vererbung blockt.

Die Lösung: Header explizit wiederholen:

location /api/ {
    add_header X-Frame-Options "SAMEORIGIN";
    add_header Content-Type "application/json";
    proxy_pass http://192.168.66.21;
}

Lessons Learned

  1. add_header außerhalb von server{} ist global - betrifft alle Server-Blöcke die kein eigenes add_header haben
  2. Ein einziges add_header blockt ALLE Vererbung - nicht nur den spezifischen Header
  3. nginx warnt dich nicht - das Verhalten ist dokumentiert, aber nicht offensichtlich
  4. Prüfe Header immer mit curl - nicht nur die Config reviewen
  5. Google findet es erst Wochen später - zu spät für schnelle Fixes

Checkliste

Wenn Google Search Console “noindex” meldet aber deine Config sauber aussieht:

  • Alle Configs scannen: grep -rn "add_header" /etc/nginx/
  • Nach Zeilen außerhalb von server{} suchen: grep -B5 "add_header X-Robots" /etc/nginx/sites-enabled/*.conf
  • Response-Header prüfen: curl -sI https://deathstar.lan/ | grep -i x-robots
  • Falls X-Robots-Tag vorhanden: Verschiebe add_header in den server{} Block oder setze Dummy-Header
  • Nach nginx-Reload verifizieren: curl nochmal ausführen
  • Google Search Console: “Indexierung anfordern” für betroffene URLs

Fazit

nginx’s Header-Vererbung ist ein klassisches “Feature, not a Bug” - aber ein gefährliches. Wenn du Security-Header oder SEO-relevante Header setzt:

  1. Setze sie immer im server{} Block, nicht außerhalb
  2. Wenn ein Block eigene Header braucht, setze ALLE gewünschten Header dort explizit
  3. Prüfe nach Änderungen mit curl -sI ob die richtigen Header ankommen
  4. Verwende always flag bei add_header um auch bei Fehler-Responses (4xx, 5xx) Header zu senden

Referenzen