Landet dein Bilderlink bei Google? noindex-Test von 7 Foto-Hostern (2026)

Deutsche Nutzer gelten als besonders datenschutzbewusst — trotzdem landet der Link, den man eben schnell in eine WhatsApp-Gruppe oder auf Discord gepostet hat, öfter in der Google-Suche, als den meisten bewusst ist. Das Problem sitzt nicht bei den Nutzern, sondern eine Ebene tiefer: in der robots.txt und den Meta-Tags der Foto-Hoster selbst.

Ende Juli 2026 sorgte ein Fall für Aufsehen, der zeigt, wie so etwas passiert, ohne dass irgendwer aktiv etwas falsch macht: Wer bei Google site:claude.ai/share eingab, fand massenhaft fremde KI-Chatverläufe — mit API-Schlüsseln, Kryptowallet-Seeds, juristischen Anfragen, Lebensläufen. Kein Hackerangriff, sondern ein Konfigurationskonflikt. Die Freigabeseiten waren in der robots.txt als „nicht crawlbar" markiert, gleichzeitig aber mit X-Robots-Tag: none versehen. Das Problem: Sobald Googlebot durch die robots.txt ausgesperrt ist, kommt er gar nicht erst zur Seite — und liest dort folglich auch nicht das eigentlich wirksame noindex. Die Seite wurde also über externe Links gefunden und indexiert, ohne dass irgendein Mechanismus das hätte verhindern können. Es war innerhalb eines Jahres bereits der vierte vergleichbare Vorfall, nach ChatGPT (geschätzt 70.000 bis 100.000 Gespräche) und Grok (mehrere Hunderttausend).

Was hat das mit Bilder-Hosting zu tun? Direkt: nichts — dort ging es um KI-Chat-Links, nicht um Fotos. Aber der Mechanismus lässt sich eins zu eins übertragen: Jede Freigabefunktion, die sich auf „wer den Link nicht kennt, sieht nichts" verlässt, aber die Crawler nicht sauber blockiert, läuft in dieselbe Falle. Auch die Ansichtsseite eines Foto-Hosters funktioniert nach dem Prinzip „wer die URL kennt, kommt rein" — und hängt genauso von drei ineinandergreifenden Ebenen ab: robots.txt, meta robots, X-Robots-Tag. Ist eine davon falsch konfiguriert, landet das Bild in den Suchergebnissen. Aus eigener Erfahrung mit Datenschutz-Audits bei Unternehmen: Foto-Lecks fallen oft noch später auf als Chat-Lecks, weil niemand auf die Idee kommt, dass auch ein schnell hochgeladener Screenshot durchsuchbar sein könnte.

Also habe ich es getestet.

Drei Ebenen entscheiden, ob ein Bild gefunden wird

Damit die Tabelle weiter unten nicht wie Kaffeesatzleserei wirkt, erst die Grundlagen: Ob eine URL bei Google landet, hängt von drei getrennten Mechanismen ab.

robots.txt entscheidet, ob ein Crawler den Pfad überhaupt betreten darf. Das <meta name="robots">-Tag im HTML entscheidet, ob eine bereits gecrawlte Seite indexiert werden soll. Der X-Robots-Tag im HTTP-Header ist eine dritte, unabhängige Anweisung mit derselben Wirkung wie das Meta-Tag — nur eben ohne HTML-Änderung. Die drei Ebenen sind technisch unabhängig, werden aber in der Praxis oft als ein und dasselbe behandelt — genau das war die Ursache beim Claude-Vorfall: robots.txt sperrte den Zugang, X-Robots-Tag war korrekt gesetzt, aber niemand konnte ihn je lesen.

Merksatz für die Praxis: Damit noindex wirkt, muss der Crawler den Pfad zuerst betreten dürfen. Wer einen Pfad per robots.txt sperrt und gleichzeitig darauf vertraut, dass ein noindex-Tag auf genau diesem Pfad greift, baut einen Widerspruch ein — meist wirkt am Ende keine der beiden Regeln.

Testmethode: was ich gemacht habe — und was nicht

Ehrlich gesagt ist bei so einem Test die größte Gefahr, aus dem Bauch heraus zu urteilen. Deshalb zuerst die Vorgehensweise: Im September 2026 habe ich mit curl -I gegen die Ansichtsseite jedes Dienstes die HTTP-Header abgerufen (für X-Robots-Tag), zusätzlich den vollständigen HTML-Quelltext nach <meta name="robots"> durchsucht und die robots.txt jedes Dienstes direkt per curl gelesen. Bei Diensten, deren Inhalte per JavaScript nachgeladen werden und bei denen curl keine echten Links liefert — bei Imgur betrifft das den Empfehlungsbereich auf der Startseite —, habe ich stattdessen Browser-Automatisierung verwendet, um die Seite tatsächlich zu laden und die Links danach auszulesen.

Ob ein Bild wirklich auffindbar ist, habe ich zusätzlich über eine echte Google-Suche geprüft — mit einer Einschränkung, die ich hier offen nenne: Das von mir verwendete Suchwerkzeug wird von der Domain imgur.com selbst blockiert (nicht von Google, sondern von Imgurs eigenem Bot-Schutz). Die Spalte „bereits auffindbar" konnte ich für Imgur deshalb nicht auf demselben Weg verifizieren, sondern nur anhand der technischen Konfiguration beurteilen, dass es „theoretisch indexierbar" ist. Das ist keine Verschleierung, sondern eine Werkzeuggrenze — und die gehört klar benannt, statt so zu tun, als hätte ich es getestet.

Ergebnistabelle

Jede Zeile hier ist eine URL, die ich diesmal wirklich abgerufen habe — nicht aus der Dokumentation übernommen.

Dienst	Indexstatus (Stand 2026-09)	robots.txt-Einschränkung	meta robots / X-Robots-Tag	Beispiel-URL
ImgBB	Bereits indexiert — direkt über normale Suchbegriffe mehrere echte Bilderseiten gefunden	robots.txt vollständig leer	keines von beiden gesetzt	ibb.co/xxx
Postimages	Bereits indexiert — ebenfalls mehrere Seiten mit Dateinamen im Titel gefunden	robots.txt vollständig leer	keines von beiden gesetzt	postimg.cc/xxx
Flickr	Bereits indexiert — konkrete Fotoseite eines bestimmten Nutzers gefunden	namentlich gelistete Crawler (inkl. Googlebot) dürfen /photos/ besuchen	nur noarchive, kein noindex	flickr.com/photos/user/id
Google Fotos	Bereits indexiert — Freigabelinks anderer Nutzer über Suche gefunden, teils weiterhin abrufbar	/share/-Pfad nicht explizit ausgeschlossen	Seite ist JS-gerendert, per curl nicht beurteilbar	photos.app.goo.gl/xxx
Imgur	theoretisch indexierbar; wegen Blockade des Suchwerkzeugs durch imgur.com nicht direkt verifizierbar	/gallery/-Pfad nicht gesperrt	keines von beiden gesetzt (Standard: indexierbar)	imgur.com/gallery/xxx
Catbox	strukturell gibt es keine indexierbare Ansichtsseite	einzelne Admin-Pfade gesperrt, ClaudeBot/GPTBot explizit ausgeschlossen	Datei ist reiner Binär-Direktlink, kein HTML für Meta-Tags	files.catbox.moe/xxx
lpic.cc	explizit noindex — laut Design soll die Ansichtsseite gar nicht erst indexiert werden	Allow: / auf Startseiten-Ebene	Quellcode setzt explizit index: false, follow: true	lpic.cc/Kurzcode

Bei Google Fotos musste ich kurz innehalten — ehrlich gesagt hatte ich mit diesem Ergebnis nicht gerechnet.

Analyse pro Anbieter: wo genau liegt das Problem

ImgBB und Postimages sind die zwei eindeutigsten Gegenbeispiele in diesem Test: robots.txt liefert eine leere Antwort, es gibt also keinerlei Pfadbeschränkung, und auf den Seiten selbst fehlt jedes meta robots-Tag. Keine Sperre plus kein Tag ergibt „vollständig offen" — und das ist der Standardzustand, keine Option, die man beim Upload abwählen könnte. Die Suche lieferte fast sofort Treffer, viele davon mit dem Originaldateinamen der Handykamera als Seitentitel (IMG_ gefolgt von Datum und Uhrzeit) — ein klares Zeichen für Direkt-Uploads vom Smartphone.

Flickr ist der differenziertere und leichter fehlinterpretierbare Fall. Die robots.txt listet knapp vierzig namentlich genannte Crawler (Googlebot eingeschlossen); diese Positivliste schließt nur einzelne Konten und Funktionsseiten aus, der reguläre Pfad /photos/nutzername/foto-id steht nicht auf der Ausschlussliste. Die Seite selbst trägt lediglich noarchive (kein Cache-Snapshot), aber kein noindex. Konkreter Fund: Die von mir gefundene Fotoseite war ausgerechnet ein offizieller Beitrag mit dem Titel „So teilst du Flickr-Fotos" — die Anleitung zum Teilen wurde selbst zum Suchtreffer. Eine gewisse Ironie liegt darin schon.

Google Fotos war für mich das aufschlussreichste Ergebnis des ganzen Tests. Ein Freigabelink wirkt auf den ersten Blick wie ein privater Mechanismus — „nur wer den Link bekommt, sieht das Bild" —, aber mit einer ganz normalen Suchanfrage, ohne Spezialbefehle, ließen sich fremde photos.app.goo.gl-Kurzlinks finden (aus Datenschutzgründen nenne ich hier keine konkreten Links). Ein Teil verlangte beim Aufruf inzwischen eine Anmeldung — die Freigabe wurde also nachträglich geändert oder ist abgelaufen —, ein anderer Teil ließ sich weiterhin öffnen. Ein „nur an bestimmte Personen" gedachter Link kann also weiterhin oder zumindest zeitweise über die öffentliche Suche gefunden werden. Das ist strukturell dasselbe Risiko wie beim Claude-Vorfall: Der Link selbst war nicht zur Veröffentlichung gedacht, aber Details in den Crawler-Regeln entscheiden, ob eine Suchmaschine ihn trotzdem einsammelt.

Catbox ist ein Sonderfall. Es gibt keine separate „Ansichtsseite" wie bei den anderen Diensten — nach dem Upload bekommt man einen Direktlink auf die Datei selbst, ohne HTML-Hülle für ein meta robots-Tag. Die klassische Meta-Robots-Prüfung läuft hier also komplett ins Leere. Das heißt aber nicht, dass es sicherer ist, das Risiko verschiebt sich nur: Die Google-Bildersuche kann Direktlinks auf Bilddateien ebenfalls indexieren, nur nach anderen Kriterien als bei HTML-Seiten. Für diesen Teil habe ich keine verlässliche Prüfmethode gefunden — ich sage das offen, statt mir eine Zahl aus den Fingern zu saugen.

lpic.cc, mein eigenes Produkt, habe ich mitgetestet — alles andere wäre unfair. Im Quellcode ist bei der Ansichtsseite fest robots: { index: false, follow: true } hinterlegt — selbst wenn dein Kurzlink weitergegeben und von einem Crawler gefunden wird, sagt die Seite selbst aktiv „bitte nicht indexieren". Das war eine Design-Entscheidung von Anfang an, kein nachträglicher Patch für diesen Test. Aber auch hier die ehrliche Einschränkung: noindex verhindert nur die Aufnahme in Suchergebnisse, nicht das grundsätzliche Problem „wer die URL kennt, kommt rein" — genau dafür gibt es zusätzlich den Passwortschutz, beide Mechanismen ergänzen sich erst zusammen zu echtem Schutz.

DSGVO, Recht auf Löschung und was das für Bilderlinks bedeutet

Ein Aspekt, der in einem rein technischen Vergleich oft untergeht: Innerhalb der EU greift bei indexierten Bildern mit Personenbezug zusätzlich die DSGVO. Nach Art. 17 DSGVO besteht grundsätzlich ein Recht auf Löschung, wenn personenbezogene Daten — dazu zählt auch ein Foto, auf dem eine Person erkennbar ist — ohne ausreichende Rechtsgrundlage verarbeitet werden. Der Bundesgerichtshof hat in seinen „Recht auf Vergessenwerden"-Entscheidungen von 2020 zudem klargestellt, dass Suchmaschinenbetreiber unter bestimmten Voraussetzungen Ergebnisse aus der Trefferliste entfernen müssen, auch wenn die zugrunde liegende Seite selbst weiterbesteht. Von den beiden am 27. Juli 2020 entschiedenen Verfahren blieb eine Klage (VI ZR 405/18) erfolglos, im anderen Fall (VI ZR 476/18) hat der BGH das Verfahren ausgesetzt und Fragen zur Vorabentscheidung dem Europäischen Gerichtshof vorgelegt.

Wichtig für die Einordnung: Ein DSGVO-Löschanspruch und ein technisches noindex sind zwei getrennte Ebenen. noindex verhindert die Indexierung präventiv und liegt in der Hand des Betreibers; das Recht auf Löschung greift nachträglich und muss aktiv geltend gemacht werden — bei Google über das eigene Formular zur Entfernung von Suchergebnissen, unabhängig davon, ob der Hoster selbst je ein noindex gesetzt hat. Wer in Deutschland oder der EU ein bereits indexiertes, personenbezogenes Bild entfernen lassen möchte, hat damit zwei parallele Ansatzpunkte, nicht nur einen.

Welches reale Risiko das für dich bedeutet

Übersetzt in Klartext: Wer ein Bild mit Personalausweis, Rechnung, Chat-Screenshot oder Adressangabe auf ImgBB oder Postimages hochlädt — beides Dienste mit standardmäßig vollständig offener Indexierung —, riskiert, dass es über Suchbegriffe oder über im Bild enthaltenen Text auffindbar wird. Man braucht dafür nicht einmal den geteilten Link, es reicht, dass die Suchmaschine die Seite bereits gecrawlt hat. Das unterscheidet sich technisch kaum davon, die Datei direkt öffentlich auf der eigenen Website abzulegen.

Ein oft übersehenes Szenario: Wer in einem Forum oder auf Discord einen Bilderlink postet, denkt selten aktiv darüber nach, ob das Bild suchbar wird. Enthält es aber Namen, Adresse oder Teile einer Ausweisnummer — typisch bei Screenshots von Steuerunterlagen, Rücksendungen oder Anträgen —, bleiben diese Informationen nach der Indexierung dauerhaft öffentlich zugänglich, bis man es selbst bemerkt und eine Entfernung beantragt. Die meisten wissen gar nicht, wo sie das überhaupt prüfen könnten.

Wie du deinen eigenen Freigabelink schützt

Nicht jedes Bild braucht denselben Schutz — der Punkt ist, zwischen „schnell geteiltem Meme" und „Screenshot mit Personenbezug" zu unterscheiden und dafür unterschiedliche Werkzeuge zu nutzen. Drei konkrete Schritte:

• Selbst vorab suchen. Vor und nach dem Upload den Dateinamen oder einen markanten Textausschnitt im Bild bei Google eingeben und prüfen, ob es bereits Treffer gibt.
• Für sensible Inhalte keine standardmäßig voll indexierten Hoster nutzen, sondern Dienste mit explizitem noindex oder Passwortschutz.
• Ablaufdatum für Freigabelinks aktiv setzen, statt sich auf „die URL kennt ja niemand" zu verlassen — der Claude-Vorfall hat gezeigt, dass ein Crawler die URL gar nicht selbst kennen muss, ein einziger externer Link reicht.

Wer einen Foto-Hoster sucht, bei dem „Freigabelink standardmäßig nicht indexiert" und Passwortschutz von Anfang an eingebaut sind, findet beides bei lpic.cc — die Ansichtsseite ist von Grund auf als noindex konzipiert, zusätzlich zum Passwortschutz. Zur Einordnung gehört aber auch die Einschränkung: Im kostenlosen Tarif laufen Medien standardmäßig 30 Tage nach Upload ab (das Upload-Formular hat „automatische Verlängerung bei Ansicht" standardmäßig aktiviert) und werden danach gelöscht, und der Betrieb finanziert sich über Werbung — das sollte man vorher wissen, nicht erst nach dem Hochladen.

Häufig gestellte Fragen

Frage 1: Bedeutet ein gesetztes noindex, dass ein Bild garantiert nie gefunden wird? Nicht garantiert. noindex ist eine „Bitte" an den Crawler, es nicht zu indexieren — Google hält sich in den meisten Fällen daran, aber nur, wenn der Crawler das Tag überhaupt lesen kann. Sperrt robots.txt gleichzeitig den Pfad, kommt der Crawler gar nicht erst hin und sieht das noindex nie — genau das war die Ursache des Claude-Vorfalls.

Frage 2: Wird ein Direktlink wie bei Catbox trotzdem gefunden? Über meta robots lässt sich das nicht beurteilen, da es keine HTML-Seite gibt. Theoretisch kann die Google-Bildersuche auch Direktlinks auf Bilddateien indexieren, die Prüfmethode unterscheidet sich aber von normalen Webseiten. Für diesen Test habe ich dafür keine verlässliche Prüfmethode gefunden und mache dazu keine unbelegte Aussage.

Frage 3: Mein bereits bei ImgBB hochgeladenes Bild ist indexiert — kann ich das rückgängig machen? Zuerst das Originalbild löschen, damit die URL ungültig wird, dann über das Werkzeug „URLs entfernen" in der Google Search Console eine Entfernung beantragen — deutlich schneller, als auf das natürliche Neu-Crawlen zu warten.

Frage 4: Kann ich mich in der EU auf die DSGVO berufen, wenn mein Bild bereits indexiert wurde? Ja, zusätzlich zu jeder noindex-Einstellung des Hosters. Nach Art. 17 DSGVO besteht ein Löschanspruch bei personenbezogenen Daten, und bei Google lässt sich unabhängig davon ein Antrag auf Entfernung aus der Trefferliste stellen. Das ist ein nachträglicher, aktiv geltend zu machender Weg — kein Ersatz für ein von vornherein gesetztes noindex.

Frage 5: Der Test ist von September 2026 — was, wenn eine Plattform ihre Einstellungen später ändert? robots.txt und Meta-Tags können sich jederzeit ändern, eine dauerhafte Garantie gibt es dafür grundsätzlich nicht. Statt sich diese Tabelle zu merken, lohnt es sich mehr, selbst einmal curl -I oder die Entwicklertools des Browsers zu benutzen — die Methode bleibt länger gültig als das Ergebnis.

Quellen

• Berichterstattung zum Vorfall der indexierten Claude-Freigabelinks (2026-07-29)
• robots.txt von Imgur, ImgBB (ibb.co), Postimages (postimg.cc), Flickr, Google Fotos (photos.google.com) und Catbox (catbox.moe), direkt abgerufen im September 2026
• HTTP-Header und HTML-Quellcode der jeweiligen Ansichtsseiten, im September 2026 per curl und Browser-Automatisierung geprüft
• Quellcode der lpic.cc-Ansichtsseiten-Metadaten (app/(public)/[locale]/[code]/page.tsx)