Am 17. November 2026 erreicht Chrome 158 den Stable-Kanal, und clientseitiges XSLT hört darin auf zu funktionieren. Microsoft Edge nutzt dieselbe Engine. Trägt irgendeine Datei auf deiner Website eine <?xml-stylesheet?>-Anweisung — und bei WordPress mit nahezu jedem SEO-Plugin tut das eine — dann ändert sich an diesem Tag die Seite, die ein Mensch im Browser öffnet.
Diese Website gehört dazu. Geprüft am 12. Oktober 2026 enthält doctor-seo.net/sitemap_index.xml die Zeile <?xml-stylesheet type='text/xsl' href='//doctor-seo.net/wp-content/plugins/wordpress-seo/css/main-sitemap.xsl'?>. Die freundliche Tabelle, die ein Besucher heute sieht, erzeugt also XSLT — und nach Chrome 158 wird sie nicht mehr erzeugt.
Die ehrliche Kurzfassung: für die Suchmaschinenoptimierung bedeutet das deutlich weniger, als die Schlagzeilen nahelegen, und für Menschen, die XML lesen, deutlich mehr. Am Crawling ändert sich nichts. Was sich ändert, ist das lesbare Gesicht jeder XML-Datei, die du veröffentlichst.
Was XSLT genau ist
XSLT — Extensible Stylesheet Language Transformations — ist eine Sprache, die ein XML-Dokument in ein anderes Dokument überführt. Man gibt ihr eine XML-Datei und ein Stylesheet aus Vorlagenregeln, und sie liefert HTML, Text oder anderes XML. XSLT 1.0 wurde 1999 zur W3C-Empfehlung, und 1.0 ist die Version, die Browser umsetzen; die späteren Fassungen 2.0 und 3.0 leben außerhalb des Browsers.
Im Browser läuft das über eine Processing Instruction am Anfang der XML-Datei: <?xml-stylesheet type='text/xsl' href='stil.xsl'?>. Lädt der Browser das XML und findet diese Zeile, holt er das Stylesheet, führt die Transformation im Browser aus und zeigt das Ergebnis statt des XML. Daneben gibt es den Skriptweg XSLTProcessor, der dasselbe aus JavaScript heraus tut.
Die entscheidende Eigenschaft, die fast jede Berichterstattung überspringt: Das ist ein Darstellungsschritt und sonst nichts. Das XML auf der Leitung bleibt unverändert. Alles, was die Datei auswertet statt sie anzuzeigen — ein Crawler, ein Feedreader, ein Skript — führt das Stylesheet nie aus. XSLT ist eine kosmetische Schicht über maschinenlesbaren Daten, und genau deshalb ist sein Wegfall sehr sichtbar und für die Suche sehr nebensächlich.
Was Google veröffentlicht hat, und wann
Google hat den Plan in Removing XSLT for a more secure browser auf der Chrome-Entwicklerseite dargelegt, verfasst von Mason Freed und Dominik Röttsches, Stand 29.10.2025. Die Begründung ist Sicherheit. Das Dokument sagt, XSLT 1.0 weiter in Browsern zu führen „stellt ein erhebliches und unnötiges Sicherheitsrisiko dar“, beschreibt die zugrunde liegenden Bibliotheken als „komplexe, alternde C/C++-Codebasen“, die „weit weniger Pflege und Sicherheitsprüfung erhalten als die zentralen JavaScript-Engines“, nennt die Schwachstellen CVE-2025-7425 und CVE-2022-22834 in libxslt und schließt, das Risiko „überwiegt den begrenzten modernen Nutzen bei Weitem“. Die Übersetzungen der Zitate sind unsere.
Die Nutzungszahl hinter diesem Urteil stammt von Google selbst: Dieselbe Seite nennt „nur etwa 0,02 % der heutigen Seitenaufrufe“, die XSLT überhaupt verwenden, und weniger als 0,001 % für XSLT-Processing-Instructions. Google veröffentlicht die Stichprobenziehung hinter diesen Zählern nicht, also ist das Plattform-Telemetrie und keine unabhängige Studie, und eine Stichprobengröße wird nicht genannt.
Zwei Notausgänge gibt es, und beide haben ein Ablaufdatum. Eine Unternehmensrichtlinie, XSLTEnabled, kam mit Chrome 146; ein Origin Trial startete mit Chrome 152. Chrome Platform Status führt den Entfernungs-Meilenstein als 158 und das Origin-Trial-Fenster von 152 bis 175; beide Ausgänge schließen in Chrome 176 am 17. August 2027. Chromium Dash, live gelesen am 12. Oktober 2026, gibt für Chrome 158 das Stable-Datum 2026-11-17 und den Branch Point 2026-10-26 an. Stabil ist heute Chrome 156.
Das ist nicht nur Chrome
Microsofts Seite zu seitenrelevanten Änderungen in Edge sagt, XSLT-Unterstützung „stellt eine unverhältnismäßige Angriffsfläche dar“, und Edge werde Chromium folgen. Sie dokumentiert eine Feature-Richtlinie XSLTEnabled in Edge 147 und fordert Organisationen auf, mit deaktivierter Richtlinie zu testen. Edge 147 hat einen engeren Fall bereits entfernt: XSLT zur Umwandlung von XML in SVG. Die eigentliche Abkündigung steht dagegen als „Future release, TBD“. Microsoft hat kein Datum veröffentlicht.
Auch die anderen Engines halten nicht dagegen. Chrome Platform Status verzeichnet die Positionen von Gecko und WebKit zur Entfernung als positiv und die Sicht der Webentwickler als negativ. In Mozillas Standards-Positions-Register schrieb Simon Pieters am 27. August 2025, es „wäre gut für die langfristige Gesundheit der Webplattform und gut für die Sicherheit der Nutzer, XSLT zu entfernen“. Die Richtung geben also alle großen Engines vor, und der Widerspruch kommt von denen, die die Funktion nutzen, nicht von denen, die sie ausliefern.
Wie das aussehen wird
Googles Seite beschreibt eine Warnleiste, zeigt das Ergebnis aber nicht — also haben wir es erzeugt. Am 12. Oktober 2026 haben wir den Sitemap-Index dieser Website zweimal in Chromium 141 gerendert: einmal normal und einmal mit dem Browser-Start --disable-blink-features=XSLT, also genau dem Schalter, den die Entfernung umlegt. Mit XSLT erzeugt das Yoast-Stylesheet eine Seite mit Überschrift und einer zweispaltigen Tabelle aus Sitemaps und Änderungsdaten. Ohne XSLT druckt der Browser eine Leiste mit dem Text „This document cannot be formatted as intended. It uses XSLT, which the browser does not support“ — dieses Dokument lässt sich nicht wie vorgesehen formatieren, es nutzt XSLT, und der Browser unterstützt das nicht — und darunter den rohen XML-Baum samt Processing Instruction.
Was bricht und was nicht
Vier Einsatzformen machen fast das gesamte clientseitige XSLT im offenen Web aus, und sie fallen nicht gleich aus. Ein Stylesheet auf einer Sitemap oder einem Feed verliert sein Aussehen und sonst nichts. Eine öffentliche XML-Datenseite — ein Register, die Codeliste einer Behörde, die Daten einer Wetterstation — verliert die einzige Form, in der ein Mensch sie lesen konnte. Und wo XSLT innerhalb einer Anwendung arbeitet, hört die Funktion auf zu laufen und nicht nur gut auszusehen.
Für die Suche selbst lautet die ehrliche Antwort: nichts passiert. Crawler holen und parsen das XML; sie führen kein Stylesheet aus. Googles eigene Dokumentation stützt das durch Auslassung: Build and submit a sitemap, Stand 8.7.2026, enthält im Fließtext kein „XSLT“, kein „stylesheet“, kein „xml-stylesheet“ und kein „browser“, und beschreibt den Mechanismus rein als Holen und Auswerten: „Google wird versuchen, deine URLs genau so zu crawlen, wie sie gelistet sind“, und eine Sitemap einzureichen sei „lediglich ein Hinweis“. Ein Stylesheet war nie an eine Suchmaschine gerichtet. Es war an dich gerichtet und an alle, denen du die URL schickst.
Das ist der Teil, den man parat haben sollte, wenn ein Kunde panisch den Screenshot der Warnleiste weiterleitet. Es wurde nichts deindexiert. Die Datei validiert weiter, listet dieselben URLs, und der Weg vom Crawling zur Indexierung ist unverändert. Geändert hat sich nur, dass die Datei jetzt aussieht wie das, was sie immer war.
Was diese Woche zu tun ist
- Wenn du es nicht von Hand machen willst, nimm unseren XSLT-Checker. Domain einfügen, und er meldet Datei für Datei, welche von XSLT abhängen und was ein Mensch ab dem 17. November sieht.
- Finde heraus, ob du überhaupt eines ausspielst.
curl -s https://beispiel.de/sitemap_index.xml | grep xml-stylesheetklärt das in einer Zeile. Wiederhole es für den Feed und für jeden XML-Endpunkt, den du veröffentlichst. - Öffne heute die Browser-Konsole auf diesen URLs in Chrome. Abkündigungswarnungen werden seit Chrome 143 ausgegeben, die Konsole ist also ein kostenloses Inventar aller XSLT-Dateien, die deine Website lädt.
- Entscheide pro Datei zwischen Lassen und Ersetzen. Das Stylesheet stehen zu lassen ist harmlos: Nach Chrome 158 wird die Anweisung schlicht ignoriert. Ersetzen heißt entweder serverseitig transformieren und HTML ausliefern oder eine schlichte HTML-Seite veröffentlichen, die auf das XML verlinkt.
- Bei den Sitemaps des WordPress-Kerns gibt es den Schalter schon. Der Filter
wp_sitemaps_stylesheet_url, seit 5.5.0 im Kern, zeigt rohes XML ohne Stylesheet, sobald er einen falschen Wert zurückgibt — praktisch, um den Zustand nach der Entfernung schon vor November zu sehen. - Für RSS und Atom das tun, was Google empfiehlt. Setze
<link rel='alternate' type='application/rss+xml'>in deine HTML-Seiten, damit Leser und Feed-Clients den Feed finden, ohne je die rohe Datei anzusehen. - Trägt XSLT eine Anwendung, fang jetzt an und nicht im November. Dokumentiert sind serverseitige Transformation, die Umstellung des Endpunkts auf JSON oder eine Client-Bibliothek — Google nennt die JavaScript-Umsetzung von Saxonica und ein WebAssembly-Polyfill. Unternehmensrichtlinie und Origin Trial verschaffen Zeit bis zum 17. August 2027 und keinen Tag länger.
- Schreibe deine Sitemap-Strategie nicht um. Es gibt keine Crawling-Änderung, für die man optimieren könnte, und eine Sitemap, die heute validiert, validiert auch am 18. November.
Wo die Branche wirklich uneins ist
Reicht ein Nutzungszähler eines Browsers aus, um eine Funktion der Webplattform zu entfernen? Ein Lager sagt ja, und die Rechnung sei nicht einmal knapp: 0,02 % der Seitenaufrufe rechtfertigen keinen ungepflegten C-Parser im meistangegriffenen Programm auf fast jedem Rechner, alle Engines sind sich einig, und eine Plattform, die nie etwas entfernen kann, lässt sich am Ende nicht absichern. Das andere Lager sagt, ein Nutzungszähler messe Seitenaufrufe und keine Folgen, die 0,02 % säßen genau dort, wo ein Bruch am teuersten ist, und der Vorschlag sei nie gegen den langen Schwanz geprüft worden. Die stärkste Fassung dieses Arguments ist der WHATWG-Thread „XSLT removal will break multiple government and regulatory sites across the world“, der unter anderem congress.gov, govinfo.gov, weather.gov, europarl.europa.eu, tga.gov.au und das Europäische Schadstofffreisetzungs- und -verbringungsregister nennt und argumentiert, „der Vorschlag, XSLT aus der Spezifikation zu entfernen, erkennt bestehende Anwendungsfälle jenseits der Chrome-Status-Zählerstatistik nicht an“ und „es gibt keine Untersuchung des langen Schwanzes von Websites, wie viele genau brechen würden“.
Niemand kann das aus veröffentlichten Belegen entscheiden, denn keine Seite hat eine Zählung der betroffenen Websites veröffentlicht. Google veröffentlichte einen Prozentsatz von Seitenaufrufen; die Gegenseite veröffentlichte eine Liste von Beispielen. Das sind verschiedene Einheiten, und keine lässt sich in die andere umrechnen. Dieser Artikel berichtet die Uneinigkeit und löst sie nicht auf.
Die Meinung des Autors — Txema Hermoso
Was ich verteidige, ist eng und nachprüfbar: XSLT im Browser ist eine Darstellungsschicht, Googles Sitemap-Dokumentation erwähnt es nicht, und die Aufnahme oben zeigt genau, was verschwindet. Jeder kann diese Aufnahme mit einem einzigen Browser-Schalter wiederholen.
Was ich nicht sage: dass dies ein Ranking-Ereignis sei, denn das ist es nicht — und ebenso wenig, dass das Sicherheitsargument falsch sei. Ich bin nicht in der Lage, die Angriffsfläche eines ungepflegten Parsers gegen eine Liste von Behörden-URLs aufzuwiegen, und niemand, der dazu publiziert, ist das, weil die Zählung, die das erlauben würde, von keiner Seite veröffentlicht wurde.
Das einzige Urteil, das ich hinzufüge, betrifft Prioritäten. Wer Websites betreut, hat mit XSLT eine halbe Stunde Inventur und danach eine Entscheidung, die meist „so lassen“ lautet. Die Kosten dieser Änderung treffen keine SEO-Teams: Sie treffen öffentliche Stellen, die maschinenlesbare Daten veröffentlicht und sie auf dem billigsten Weg, den die Plattform bot, für Menschen lesbar gemacht haben. Diese Asymmetrie ist die eigentliche Nachricht, und sie verdient mehr Aufmerksamkeit als das Aussehen deiner Sitemap — weshalb das Thema auch in die Ebene technisches SEO gehört, als Lektion über die Abhängigkeit von einer Darstellung, die man nicht kontrolliert.
Was weiterhin unbekannt ist
Ob Edge die Entfernung nach Chromes Fahrplan ausliefert oder nach einem eigenen, denn Microsoft hat kein Datum genannt. Ob Firefox und Safari folgen und wann: Beide Engines haben eine positive Position hinterlegt, und keiner hat einen Fahrplan veröffentlicht. Wie viele Websites tatsächlich brechen, was niemand gezählt hat. Ob der Origin Trial über Chrome 176 hinaus verlängert wird. Und ob ein Plugin-Anbieter vor November einen Ersatz für die Sitemap-Ansicht liefert oder das Stylesheet einfach wirkungslos werden lässt.
Quellen
- Mason Freed und Dominik Röttsches, Google, Removing XSLT for a more secure browser, Stand 29.10.2025, gelesen am 12. Oktober 2026 (zweimal).
- Chrome Platform Status, Feature 4709671889534976, XSLT, über die öffentliche API gelesen am 12. Oktober 2026: Abkündigung 143, Entfernung 158, Origin Trial 152–175, Ende 176; Positionen von Gecko und WebKit positiv, Sicht der Webentwickler negativ.
- Chromium Dash, Zeitplan für Meilenstein Chrome 158, gelesen am 12. Oktober 2026: Stable-Datum 2026-11-17, Branch Point 2026-10-26. Aktueller Stable-Meilenstein 156.
- Microsoft, Site impacting changes in Microsoft Edge, gelesen am 12. Oktober 2026. Abkündigung als „Future release, TBD“; Richtlinie
XSLTEnabledin Edge 147. - Simon Pieters, mozilla/standards-positions, Issue 1287, 27. August 2025.
- whatwg/html, Issue 11582, „XSLT removal will break multiple government and regulatory sites across the world“, gelesen am 12. Oktober 2026.
- Google, Build and submit a sitemap, Stand 8.7.2026, gelesen am 12. Oktober 2026.
- WordPress, wp_sitemaps_stylesheet_url, seit WordPress 5.5.0 im Kern.
- Eigene Daten:
doctor-seo.net/sitemap_index.xmlund dessen Rendering in Chromium 141, aufgenommen am 12. Oktober 2026.
Die einzigen Prozentwerte in diesem Artikel sind Googles eigene Plattformzähler, veröffentlicht ohne Stichprobengröße und ohne Erhebungsmethode, und genau das steht dort, wo sie vorkommen. Keine andere hier genannte Quelle ist eine Studie.