Google blockiert Immich-Website
Es ist ein Szenario, das jeder Websitebetreiber, Entwickler oder Administrator fürchtet: Ihre Seite läuft eben noch perfekt – und ist im nächsten Moment für die Welt unzugänglich. Besucher sehen nicht Ihre Inhalte, sondern einen beängstigenden Warnhinweis im Vollbild. Die naheliegenden Erklärungen wären ein Serverabsturz, eine DDoS-Attacke oder ein bösartiger Hack. Aber was, wenn der Übeltäter kein externer Angreifer ist, sondern eine lautlose, automatisierte Entscheidung eines der mächtigsten Gatekeeper des Internets?
Genau das erlebte das Team hinter Immich, einer selbstgehosteten Lösung für Foto- und Video-Backups, vor Kurzem. Ihre komplette Domain wurde plötzlich als „gefährlich" eingestuft – faktisch für die meisten Nutzer ausgelöscht. Die frustrierende Suche nach der Ursache offenbart einen gefährlichen blinden Fleck in den automatisierten Systemen, die sich als Sheriffs des Webs verstehen – einen blinden Fleck, der jeden treffen kann.
Fazit: Ein intransparentes Gatekeeping kann Sie aus dem Web löschen
Ein einzelner Flag kann Ihre Sichtbarkeit auslöschen
Google Safe Browsing ist ein kostenloser Dienst, direkt in große Browser wie Chrome und Firefox integriert. Sein Ziel: Nutzer schützen, indem Webseiten blockiert werden, die Malware, unerwünschte Software oder „Social Engineering" betreiben. Sobald eine Seite markiert ist, sehen Besucher einen grellroten Warnbildschirm. Für das Immich-Team war diese Erfahrung ein weiterer Eintrag auf ihrer Liste „Verfluchten Wissens".
Die Auswirkungen sind sofort und verheerend. Wie sie herausfanden: „Ihre Seite wird für alle Nutzer praktisch unzugänglich." Nur ein sehr kleiner Teil technikaffiner Benutzer klickt sich durch die mehrfachen Warnungen zum „unsicheren" Ziel. Für das restliche Publikum existiert Ihre Website nicht mehr. Erschwerend kommt hinzu, dass der tatsächliche Prozess, wie eine Seite als „gefährlich" gilt, nicht transparent ist – das System wird so zu einem mächtigen, aber undurchsichtigen Schiedsrichter über Erreichbarkeit.
Fazit: Die alarmierende Domino-Wirkung eines einzelnen Subdomains
Ein „schlechter" interner Link kann Ihre gesamte Domain lahmlegen
Nach tiefer Analyse der Google Search Console fand das Immich-Team die Quelle: ihre eigenen internen, nicht öffentlichen Preview-Umgebungen. Temporäre Seiten, automatisch für Entwicklungszwecke erzeugt, mit URLs wie main.preview.internal.immich.cloud. Die Google-Crawler hatten diese temporären Seiten offenbar besucht und als „täuschend" bewertet.
Doch die kritischste und kontraintuitivste Erkenntnis war der Kollateralschaden: Ein Flag auf einem einzelnen, internen Subdomain blieb nicht isoliert. Stattdessen erhielt die gesamte immich.cloud-Domain das Label „gefährlich" – inklusive produktiver Services und Informationsseiten. Sogar der produktive Tile-Server unter tiles.immich.cloud war betroffen. Glücklicherweise erfolgen Anfragen an ihn per JavaScript und sind nicht direkt nutzerseitig sichtbar, sodass er scheinbar normal funktionierte.
Am alarmierendsten: Ein einziges markiertes Subdomain kann offenbar die gesamte Domain invalidieren.
Fazit: Die „Lösung" ist eine frustrierende Endlosschleife
Entflaggt zu werden kann zur Sisyphos-Aufgabe werden
Der offizielle Weg: Google-Konto anlegen, Seite in der Search Console registrieren, Überprüfung einreichen und seinen Fall darlegen. Das Immich-Team tat genau das und erklärte, dass die markierten Seiten ihre Deployments seien. Ein bis zwei Tage später wurde die Überprüfung akzeptiert – die Domain war wieder sauber! 🎉
Der Sieg war jedoch flüchtig. Schon bald steckten sie im algorithmischen Fegefeuer. Ihr Entwicklungsprozess erstellt für Pull Requests auf GitHub neue Preview-Umgebungen. Sobald eine neue Preview-URL in einem Kommentar auftauchte, fanden die Google-Crawler sie, crawelten sie und markierten sofort die gesamte immich.cloud-Domain erneut als gefährlich. Der ganze Prozess startete von vorn – ein digitales Whack-a-Mole-Spiel.
Konfrontiert mit diesem endlosen Zyklus entwickelte das Team einen Workaround: Alle Preview-Umgebungen auf eine eigene Domain – immich.build – umziehen. Eine Art Quarantäne, um Entwicklung vom Produktionsbetrieb zu isolieren und zukünftige Domain-weite Sperren zu vermeiden.
Fazit: Das System scheint blind für Open-Source-Entwicklung
Das ist nicht nur das Problem eines Projekts – es bedroht Open Source insgesamt
Diese Erfahrung ist nicht einzigartig. Sie verweist auf ein größeres systemisches Problem, das eine ernsthafte Gefahr für Open-Source- und selbstgehostete Projekte darstellt. Viele andere populäre Projekte – darunter Jellyfin, YunoHost, n8n und NextCloud – sind auf exakt dasselbe Problem gestoßen. Das Problem griff sogar auf Immich-Nutzer über, als „einige begannen, sich über markierte eigene Deployments zu beschweren".
Der Workflow, der moderne, transparente, kollaborative Open-Source-Entwicklung definiert – öffentliche Preview-Umgebungen für Community-Review – wird von Googles automatisierten Systemen als Täuschung fehlinterpretiert. Das ist kein Bug; es ist ein grundlegend blinder Designpunkt.
Google Safe Browsing scheint ohne Berücksichtigung von Open-Source oder selbstgehosteter Software gebaut worden zu sein.
Wenn ein standardisierter, transparenter Entwicklungsworkflow als Bedrohung eingestuft wird, bestraft das genau jene Communities, die freie, offene Tools erschaffen, auf die so viele angewiesen sind.
Fazit: Das Dilemma eines zentralisierten Webs
Die Immich-Geschichte erinnert daran, dass zentrale Gatekeeper enorme – oft willkürliche – Macht besitzen, ganze Bereiche des Webs unzugänglich zu machen. Dienste wie Safe Browsing mögen gut gemeint sein; ihr automatisierter, uniformer Ansatz kann jedoch erheblichen unbeabsichtigten Schaden an legitimen Projekten verursachen. Das zwingt uns zu einer schwierigen Frage.
Während wir immer mehr Kontrolle an intransparente, automatisierte Gatekeeper abgeben, müssen wir uns fragen: Bauen wir wirklich ein sichereres Internet – oder pflastern wir unbeabsichtigt die lebendigen, kollaborativen Räume zu, in denen die nächste Generation von Open-Source-Software entsteht?