Seitenressourcen konnten nicht geladen werden und "Other error": Warum der Livetest der URL Prüfung scheitert

Was bedeutet "Seitenressourcen konnten nicht geladen werden" in der URL Prüfung?

Die Meldung bedeutet, dass der Livetest der URL Prüfung (URL Inspection) in der Search Console einige Dateien Ihrer Seite nicht abrufen konnte, etwa CSS, JavaScript, Bilder oder Schriften. Die Seite selbst kann dennoch erreichbar sein. Außerdem heißt die Meldung allein nicht, dass Google die Seite verworfen hat; zunächst klären Sie, welche Dateien aus welchem Grund fehlen.

In diesem Beitrag geht es um genau eine Situation: Der Livetest zeigt eine Ressourcenwarnung, und in der Ressourcenliste steht "Other error" (auf Deutsch sinngemäß "Sonstiger Fehler"). Oberflächentexte ändern sich mit der Zeit, und wir konnten nicht jede deutsche Bezeichnung in der offiziellen Hilfe Wort für Wort bestätigen. Deshalb sprechen wir von einer ähnlichen Warnung und nennen die englischen Namen in Klammern.

Vorab der wichtigste Punkt: Die Search Console Hilfe von Google sagt ausdrücklich, dass Informationen im Livetest von der indexierten Version abweichen können. Die Warnung bedeutet also nicht automatisch einen Rankingverlust. Dennoch sollten Sie sie ernst nehmen und systematisch prüfen.

Wie unterscheidet sich der Livetest von der indexierten Version?

Die URL Prüfung zeigt Ihnen zwei Ansichten. Konkret: Die erste ist die Version, die Google in seinem Index gespeichert hat. Die zweite Ansicht ist dagegen der Livetest, den Sie mit "Test live URL" starten und der die Seite in diesem Moment neu abruft. Zwischen beiden Ansichten können Sie wechseln. Daher sind unterschiedliche Ergebnisse für dieselbe Adresse normal.

Laut der offiziellen Hilfeseite gibt es einen Screenshot nur bei einem erfolgreichen Livetest. Für die indexierte Version gibt es dagegen keinen. Zusätzliche Antwortdaten erscheinen außerdem nur, wenn der Teststatus "URL is available to Google" oder "URL is available to Google, but has issues" lautet. Wenn Sie also Ressourcenfehler sehen, war die Seite selbst sehr wahrscheinlich erreichbar.

Der Unterschied ist wichtig, denn ein Livetest ist eine einzelne, sofortige Anfrage. Die indexierte Version stammt dagegen aus früheren Crawls des Googlebots. Eine Datei, die der Googlebot letzte Woche problemlos abgeholt hat, kann im heutigen Test scheitern. Hintergründe zum Crawler finden Sie in unserem Beitrag Was ist der Googlebot und wie verifizieren Sie ihn.

Warum erscheint "Other error" in der Ressourcenliste?

"Other error" ist also eine Sammelbezeichnung. Das Tool konnte eine Ressource nicht laden, aber den Fehler keiner genaueren Kategorie zuordnen. Gibt es einen klaren Grund, etwa eine robots.txt Regel, nennt das Tool meist genau diesen. Ein allgemeines Label deutet dagegen auf Netzwerkprobleme, Zeitüberschreitungen oder ungewöhnliche Serverantworten hin.

Die Dokumentation von Google listet nicht jede mögliche Ursache für dieses Label auf. Statt zu raten, sammeln Sie deshalb Belege. Diese kurze Routine hilft dabei:

• Zunächst notieren Sie, welche Dateien fehlschlagen: CSS, JavaScript, Bilder oder Schriften.
• Dann prüfen Sie, ob die Datei auf Ihrer eigenen Domain oder bei einem Drittanbieter liegt.
• Danach öffnen Sie dieselbe Datei direkt im Browser und achten auf Statuscode und Antwortzeit.
• Schließlich wiederholen Sie den Livetest nach wenigen Minuten und vergleichen die Listen.

Diese vier Schritte machen aus einem vagen Label eine konkrete Frage. Fällt zum Beispiel nur die Datei eines externen Dienstes aus, wissen Sie sofort, wen Sie fragen müssen.

Sind Seitenressourcen konnten nicht geladen werden auch beim echten Googlebot ein Problem?

Nicht immer, denn der Livetest läuft über den Crawler Google InspectionTool. Laut Googles Crawler Dokumentation betrifft dieser Abrufer Testwerkzeuge wie den Rich Results Test und die URL Prüfung in der Search Console. Die echte Indexierung ist dagegen ein getrennter Prozess und arbeitet stark mit zwischengespeicherten Ressourcen.

Die Dokumentation zu JavaScript SEO nennt dazu zwei wichtige Punkte. Erstens speichert der Googlebot aggressiv zwischen, um Netzwerkanfragen zu sparen. Zweitens kann der Rendering Dienst von Google Cache Header ignorieren. Folglich kann eine Datei im Livetest hängen, obwohl sie beim Crawl für die indexierte Version einwandfrei geladen hat.

Das gibt Ihnen allerdings keinen Freibrief, die Warnung zu ignorieren. Wiederholt sich die Meldung "Seitenressourcen konnten nicht geladen werden", schauen Sie genauer hin. Scheitern dieselben Ressourcen auch in der indexierten Ansicht, oder fehlt im gerenderten HTML Ihr Hauptinhalt, haben Sie ein echtes Problem. Wie Sie das unterscheiden, zeigen die nächsten Abschnitte.

Verursachen robots.txt Regeln für CSS und JavaScript diesen Fehler?

Ja, und das ist die häufigste echte Ursache, die wir sehen. Nach Googles Dokumentation zu JavaScript SEO führt Google Search kein JavaScript aus, das aus per robots.txt gesperrten Dateien oder Seiten stammt. Außerdem hält die Crawler Dokumentation fest, dass die allgemeinen Google Crawler robots.txt Regeln befolgen. Das Google InspectionTool gehört dazu.

In diesem Fall scheitert die Ressource auch für das Testwerkzeug und erscheint als fehlgeschlagene Zeile. Der Screenshot kann dann ohne Styling oder leer ausfallen. Das ist also kein vorübergehender Aussetzer, sondern das dauerhafte Ergebnis Ihrer eigenen Konfiguration.

Zur Kontrolle öffnen Sie Ihre robots.txt und suchen nach Regeln, die Theme, Plugin oder Build Ordner sperren. Zum Beispiel sehen wir in älteren Installationen oft Style und Skript Ordner, die "aus Sicherheitsgründen" gesperrt sind. Typische Muster zeigt unser Beitrag zu robots.txt Fehlern. Außerdem können Sie die Datei neu aufsetzen mit dem robots.txt Generator. Grundlagen finden Sie unter Was ist robots.txt.

Wie stört ein langsamer Server den Livetest?

Zunächst versucht der Livetest, Ihre Seite und deren Ressourcen in kurzer Zeit abzurufen. Antwortet Ihr Server langsam, laufen manche Dateien in eine Zeitüberschreitung und erscheinen als Fehler. Google veröffentlicht kein exaktes Zeitlimit, deshalb nennen wir keine Zahl. Logisch gilt aber: Langsame und schwankende Antworten erhöhen das Risiko.

Besonders diese Situationen steigern das Risiko von Zeitüberschreitungen:

• Shared Hosting mit längeren Antwortzeiten zu Stoßzeiten.
• Dynamische Seiten ohne Cache, die bei jeder Anfrage die Datenbank abfragen.
• Dutzende kleine CSS und JavaScript Dateien, die einzeln angefordert werden.
• Eine Firewall, die schnelle, browserähnliche Anfragen kurzzeitig abweist.

Den letzten Punkt übersehen viele. Eine Firewall oder ein Ratenlimit kann Googles Ressourcenanfragen als Bot Verkehr einstufen und ablehnen. Dann läuft in Ihrem Browser alles glatt, während das Testwerkzeug Fehler meldet. Deshalb lohnt ein Blick in die Serverprotokolle auf abgewiesene Anfragen rund um den Testzeitpunkt klärt den Fall oft vollständig.

Warum lösen Ressourcen von Drittanbietern die Warnung aus?

Zudem lädt Ihre Seite vielleicht Dateien von Diensten außerhalb Ihrer Domain. Schriftanbieter, Analyse Skripte, Chat Widgets, Karten und Video Einbindungen gehören dazu. Wird einer dieser Dienste langsam oder schränkt er Googles Zugriff ein, erscheint seine Datei als fehlgeschlagene Ressource. Diese Server betreiben Sie nicht, daher ist Ihre Kontrolle begrenzt.

Die entscheidende Frage lautet: Trägt die fehlgeschlagene Ressource Inhalte, oder ist sie nur Dekoration? Ein Tracking Skript, das nicht lädt, spielt für den Inhalt keine Rolle. Fällt aber ein Skript aus, das Ihre Produktliste oder Ihren Artikeltext nachlädt, bleibt das HTML, das Google sieht, leer. Dann liegt ein echtes Problem vor.

Teilen Sie Ihre Ressourcen deshalb in zwei Gruppen: solche mit Inhalt und solche ohne. Liefern Sie vor allem alles, was Inhalt trägt, nach Möglichkeit von Ihrer eigenen Domain aus. Bei den übrigen lohnt es sich eher, die Gesamtzahl zu senken, statt jede einzeln zu reparieren. Die Ladeseite beleuchtet unser Beitrag zu JavaScript und Ladezeit.

Können CDN, Cache Plugin und Hotlink Schutz Ressourcenfehler verursachen?

Ja, das ist möglich. Ein häufiges Beispiel aus der Praxis ist der Hotlink Schutz, der verhindert, dass andere Seiten Ihre Bilder einbinden. Ist die Regel zu weit gefasst, lehnt sie womöglich auch die Bildanfragen des Testwerkzeugs ab. Im Screenshot fehlen dann die Bilder.

Auch bei CDNs gibt es ähnliche Risiken. Manche Konfigurationen drosseln Anfragen, die wie Bots wirken. Cache Plugins, die Dateien bündeln oder verkleinern, erzeugen zudem manchmal veraltete Dateiadressen. Ihr Browser zeigt die Seite dann vielleicht korrekt an, während das Testwerkzeug eine alte Adresse anfragt und einen Fehler erhält.

Prüfen Sie diese Punkte:

• Sperren Ihre CDN oder Sicherheitsregeln fälschlich Google Crawler?
• Erlaubt die Hotlink Regel Anfragen von Ihrer eigenen Domain?
• Sind die gebündelten Dateien Ihres Cache Plugins aktuell und erreichbar?
• Verweist die Seite nach einem Umzug noch auf eine alte Dateiadresse?

Hinweis: Diese Liste beruht auf unserer Praxiserfahrung. Sie garantiert nicht, dass jede Seite dasselbe Ergebnis zeigt.

Mit welchen Schritten stellen Sie die Diagnose?

Bevor Sie die Seite panisch ändern, folgen Sie zunächst einer festen Reihenfolge. Die folgenden Schritte entsprechen dem Ablauf, den unser Team nutzt. Dabei baut jeder Schritt auf dem vorherigen Ergebnis auf.

1. Geben Sie die Adresse in der URL Prüfung ein, starten Sie den Livetest mit "Test live URL" und warten Sie das Ende ab.
2. Danach prüfen Sie, ob der Status "URL is available to Google" oder "has issues" lautet.
3. Öffnen Sie "View tested page" für Screenshot, HTML und Ressourcenliste.
4. Schreiben Sie jede fehlgeschlagene Ressource auf und ordnen Sie sie der eigenen Domain oder einem Drittanbieter zu.
5. Dann kontrollieren Sie Ihre robots.txt auf Regeln, die diese Ressourcen sperren.
6. Schließlich wiederholen Sie den Test nach einigen Minuten und vergleichen Sie die Ergebnisse.
7. Schauen Sie sich dieselben Ressourcen in der indexierten Ansicht unter "More info" an.

Nach diesen sieben Schritten halten Sie eine konkrete Tabelle in der Hand: welche Datei, welche Ursache, dauerhaft oder vorübergehend. Ohne diese Tabelle bleibt also jede Änderung eine Vermutung.

Wie vergleichen Sie Screenshot und gerendertes HTML?

Den eigentlichen Beleg liefern stattdessen Screenshot und gerendertes HTML, nicht allein die roten Zeilen. Eine fehlgeschlagene Zeile beweist also keinen Inhaltsverlust. Entscheidend ist, ob Google Ihren Hauptinhalt sehen kann.

Fragen Sie im Screenshot nach Folgendem: Sind Überschrift, Haupttext und Produktdetails vorhanden? Wirkt das Layout grob richtig? Ist das Styling zusammengebrochen, sodass nur nackter Text bleibt? Ein optischer Fehler allein muss nicht schlimm sein. Fehlt jedoch der Inhalt, schlagen Sie Alarm.

Suchen Sie im HTML nach Ihrer Hauptüberschrift, einigen zentralen Absätzen, internen Links und Produktnamen. Die Dokumentation zu JavaScript SEO sagt klar, dass Inhalt, der im gerenderten HTML fehlt, nicht in den Index gelangt. Deshalb ist die Bestätigung, dass Ihr wichtiger Inhalt im gerenderten HTML steht, ein stärkeres Signal als die Ressourcenliste.

Wann zählt die Warnung als echtes Problem?

Ein einfacher Entscheidungsrahmen hilft. Ist zum Beispiel die Warnung vorübergehend und der Inhalt intakt, warten Sie ab und testen erneut. Besteht sie dauerhaft und fehlen Inhalt, Links oder Schema Daten, handeln Sie. Diese Liste fasst die echten Warnsignale zusammen:

• Dieselben Ressourcen scheitern in mehreren Tests im Abstand von Tagen.
• Außerdem sperrt eine robots.txt Regel die fehlgeschlagene Datei.
• Im gerenderten HTML fehlen Haupttext, Produktdetails oder interne Links.
• Zudem ist der Screenshot leer, komplett ohne Styling oder ohne Inhalt.
• Schließlich zeigt die indexierte Ansicht dieselben Ressourcenfehler.

Andererseits beunruhigt uns ein ausgefallenes Analyse oder Werbeskript meist nicht. Kurz gesagt entscheidet die Wirkung auf den Inhalt, nicht der Dateiname. Fragen Sie sich, warum eine Seite im Index fehlt, hilft Ihnen außerdem unsere Anleitung zum Finden nicht indexierter Seiten.

Welches Symptom deutet auf welche Ursache?

Konkret ordnet die folgende Tabelle die Symptome, die uns am häufigsten begegnen, möglichen Ursachen zu. Sie ist eine schnelle Orientierung, keine Diagnosegarantie. Für ein sicheres Urteil brauchen Sie daher weiterhin Belege.

Nutzen Sie die Tabelle wie eine Checkliste: Symptom suchen, erste Prüfung durchführen, dann anhand des Ergebnisses entscheiden.

Welche Lösungen helfen, wenn der Fehler immer wiederkehrt?

Die Lösung hängt von der Ursache ab. Liegt zum Beispiel es an der robots.txt, entfernen oder verengen Sie die sperrende Zeile. Danach geben Sie Crawlern Zugriff auf Theme, Plugin und Build Dateien, die Ihre Seite für Darstellung und Inhalt braucht. Öffnen Sie die Datei danach im Browser, um sicherzugehen, dass sie live ist.

Liegt es am Server, senken Sie zunächst die Antwortzeit. Richten Sie außerdem Caching ein, bündeln und komprimieren Sie Dateien und entfernen Sie unnötige Plugins. Liegt es an einer Firewall, formulieren Sie eine Regel, die echte Google Crawler nicht mehr einschränkt. Hier zählt der Identitätsnachweis. Verlassen Sie sich nicht auf den Namen des User Agents, sondern nutzen Sie die von Google empfohlene Verifizierung.

Bei Drittanbietern gibt es zwei Wege. Holen Sie inhaltstragende Dateien auf Ihre eigene Domain oder erzeugen Sie sie auf dem Server. Verzögern oder entfernen Sie dagegen Dateien ohne Inhalt. Zur Performance Seite zeigt unser Leitfaden zu den Core Web Vitals, was weniger Ressourcen für die Nutzererfahrung bringen.

Welche falschen Lösungen sollten Sie vermeiden?

Weil Panik den Blick trübt, wirken riskante Abkürzungen verlockend. Manche lösen das Problem nicht, andere erzeugen neue. Deshalb raten wir von Folgendem ab:

• Alle Regeln in der robots.txt zu löschen, denn das öffnet auch Seiten, die Sie nie crawlen lassen wollten.
• Die Firewall komplett abzuschalten, denn das lässt Ihre Seite echten Angriffen offen.
• Alle Skripte zu entfernen, nur weil der Screenshot komisch aussieht.
• Nach jeder Warnung immer wieder Indexierungsanfragen zu senden.
• Bots andere Inhalte auszuliefern als Nutzern. Das gilt als Umgehung von Googles Systemen und kann ernste Folgen haben.

Der letzte Punkt verdient Nachdruck. Google etwas anderes zu zeigen als Nutzern, verstößt gegen die Regeln. Stattdessen ist der richtige Weg, dass beide denselben Inhalt sehen. So bleiben Sie auf der sicheren Seite und schützen Ihr langfristiges Ergebnis.

Wie bestätigen Sie, dass Seitenressourcen konnten nicht geladen werden behoben ist?

Öffnen Sie nach einer Änderung zunächst selbst die Seite und prüfen Sie, ob der Inhalt vollständig kommt. Starten Sie dann den Livetest in der URL Prüfung erneut. Die Ergebnisse bessern sich unter Umständen nicht sofort, denn Caches, DNS und Firewall Regeln brauchen einige Minuten.

Nutzen Sie diese Kriterien zur Kontrolle:

• Erstens: Ist die Zahl der fehlgeschlagenen Zeilen in der Ressourcenliste gesunken?
• Zweitens: Ähnelt der Screenshot jetzt der echten Seite?
• Enthält das gerenderte HTML Hauptüberschrift, Haupttext und interne Links?
• Schließlich: Lautet der Teststatus weiterhin "URL is available to Google"?

Fallen alle Antworten positiv aus, sind Sie fertig, und die Meldung Seitenressourcen konnten nicht geladen werden erscheint nicht mehr. Erhalten Sie weiterhin denselben Fehler, gehen Sie zu den früheren Ursachen zurück und schließen Sie sie nacheinander aus. Ändern Sie daher immer nur eine Sache, damit Sie erkennen, was wirklich geholfen hat.

Sollten Sie die Indexierung beantragen, bevor Sie alles geprüft haben?

Nach einem sauberen Livetest wirkt eine Indexierungsanfrage verlockend. Allerdings sind Anfragen begrenzt, und zum falschen Zeitpunkt verpuffen sie. Bestätigen Sie daher zuerst, dass die Seite wirklich repariert ist, und beantragen Sie die Indexierung dann nur für wichtige Seiten.

Stoßen Sie an eine Grenze, erklärt unser Beitrag zur Meldung Kontingent überschritten, was zu tun ist. Kurz gesagt: Sehen Sie das Kontingent als Budget zum Priorisieren, nicht als Rettungswerkzeug. Eine Sitemap und saubere interne Links helfen Google zudem, Ihre Seite zu finden.

Sehen Sie außerdem einen Fehler bei Schema Daten, ist das ein eigenes Thema. Lesen Sie dann den Beitrag zu nicht parsbaren strukturierten Daten. Trennen Sie beide Themen sauber, damit Sie Ihre Zeit am richtigen Ort investieren.

Beeinflusst der Ressourcenfehler Indexierung und Rankings?

Eine direkte Strafe gibt es nicht. Stattdessen entsteht die Wirkung entsteht dadurch, wie Google die Seite versteht. Sieht Google Ihren Hauptinhalt, Ihre Links und das Layout, schaden einige fehlende Nebendateien in der Regel nicht. Ist der Inhalt dagegen nicht sichtbar, kann die Seite dünn oder leer wirken.

Messen Sie die Wirkung daher mit drei Fragen. Erstens: Steht der Haupttext im HTML, das Google sieht? Zweitens: Sind die internen Links vorhanden, sodass der Weg zu anderen Seiten offen bleibt? Drittens: Ist das Layout für mobile Besucher lesbar? Lauten alle drei Antworten ja, besteht kein Grund zur Eile.

Natürlich sehen Sie nicht alle Signale von Google von außen. Trotzdem stützen diese drei Fragen Ihre Entscheidung auf Belege. Beobachten Sie außerdem einen Trafficrückgang, schieben Sie nicht alles auf den Ressourcenfehler. Nutzen Sie den breiteren Ansatz aus unserem Beitrag zur Analyse eines Trafficeinbruchs.

Tritt die Meldung Seitenressourcen konnten nicht geladen werden nur auf einer Seite auf oder auf der ganzen Website?

Zunächst gilt: Den Umfang zu messen, ist der schnellste Weg, die Ursache einzugrenzen. Führen Sie den Livetest für die Problem URL und für zwei bis drei Seiten mit demselben Template durch. Danach wählen Sie je eine Seite pro Templatetyp, etwa Startseite, Kategorie, Artikel und Produkt. So erkennen Sie, auf welcher Ebene das Problem beginnt.

Scheitert zum Beispiel nur eine Seite, liegt vermutlich ein Skript, eine Einbindung oder ein Bild dieser Seite zugrunde. Scheitern alle Seiten eines Templates, ist eine templategebundene Datei schuld. Scheitert die ganze Website, prüfen Sie gemeinsame Ebenen: robots.txt, Server, CDN oder Firewall.

Die Methode wirkt schlicht, spart aber Stunden. Außerdem verhindert sie, dass Sie auf der falschen Ebene graben. Wer zum Beispiel eine seitenweite Ursache im Inhalt einer einzelnen Seite sucht, verschwendet seinen Tag. Halten Sie die Ergebnisse in einer Tabelle fest, damit das ganze Team dieselbe Sprache spricht.

Ist ein Lighthouse Ergebnis dasselbe wie dieser Ressourcenfehler?

Nein, denn beide Werkzeuge beantworten unterschiedliche Fragen. Lighthouse bewertet Geschwindigkeit, Barrierefreiheit und bewährte Verfahren. Die URL Prüfung zeigt dagegen, wie Google die Seite abgerufen hat, welche Version im Index liegt und welche Ressourcen der Test laden konnte.

Folglich bedeutet ein hoher Lighthouse Wert nicht, dass in der URL Prüfung keine Ressourcenfehler auftauchen. Auch umgekehrt gilt das. Eine Datei kann in Lighthouse schnell laden und für Googles Testwerkzeug trotzdem per robots.txt gesperrt sein.

Lesen Sie beide Werkzeuge deshalb als Ergänzung. Nutzen Sie Lighthouse für Tempo und Nutzererfahrung und die URL Prüfung als Beleg dafür, was Google sieht. Die Lighthouse Grundlagen wiederholen wir hier nicht; sie stehen im früheren Beitrag zum Lighthouse Test für die Website Performance.

Welche typischen Denkfehler sollten Sie vermeiden?

Erstens besteht der Fehler darin, jede rote Zeile als Katastrophe zu sehen. Tatsächlich sind viele Zeilen Nebendateien, die Ihren Inhalt nie berühren. Zweitens gibt es das Gegenteil: abwarten, weil das Problem "bestimmt vorübergehend" ist, während der Screenshot leer bleibt. Ein dauerhaft leerer Screenshot bedeutet ein echtes Problem.

Drittens entscheiden viele nach einem einzigen Test zu entscheiden. Weil der Livetest eine Momentaufnahme ist, wiederholen Sie ihn mehrmals, bevor Sie Schlüsse ziehen. Viertens vermischen manche die Werkzeuge. Rich Results Test, Lighthouse und URL Prüfung beantworten verschiedene Fragen, daher lesen Sie jedes im eigenen Zusammenhang.

Wie geht unser Team in dieser Situation vor?

Wir von Talha Aslan und Team sammeln zuerst Belege und empfehlen erst danach Änderungen. Auf Kundenseiten prüfen wir robots.txt, Serverantworten und Drittanbieter Skripte in derselben Sitzung. Das Ziel ist also nicht, eine Warnung zum Schweigen zu bringen, sondern sicherzustellen, dass Google den Inhalt korrekt sieht.

Ein Beispielszenario: Eine Unternehmensseite hat ihren Theme Ordner in der robots.txt gesperrt. Im Livetest scheitern die Style Dateien, und der Screenshot fällt auf nackten Text zurück. Danach, nachdem wir die Regel verengt haben, kehrt der Screenshot zum Normalzustand zurück. Das ist nur ein Beispielszenario. Echte Seiten unterscheiden sich, und wir garantieren kein Ergebnis.

Für technische SEO Audits und laufendes Monitoring schauen Sie sich unsere SEO Beratung an. Außerdem prüfen Sie für aktuelle Fakten Googles Hilfeseite zur URL Inspection, die Grundlagen zu JavaScript SEO und die Dokumentation der allgemeinen Google Crawler. Menünamen können sich ändern, bestätigen Sie die aktuelle Oberfläche daher immer in der offiziellen Quelle.