Chrome 158 ohne XSLT: Was sich für Sitemap und Feed ändert

Was Chrome 158 am 17. November entfernt

Chromium hat XSLT offiziell abgekündigt, und zwar beide Wege, über die der Browser die Sprache bisher ausführt: die JavaScript-Schnittstelle XSLTProcessor und die XSLT-Verarbeitungsanweisung im Kopf einer XML-Datei, also eine Zeile wie <?xml-stylesheet type="text/xsl" href="sitemap.xsl"?> (Chrome for Developers). Als Termin für die Entfernung nennt die Chrome-Doku Version 158 am 17. November 2026 (Chrome for Developers). Denselben Tag führt der Veröffentlichungsplan des Chromium-Projekts als Stable-Datum für Meilenstein 158 (Chromium Dash).

Ein einzelner Stichtag ist der 17. November trotzdem nur auf dem Papier. Laut demselben Plan geht Chrome 158 bereits am 4. November als frühe Stable-Version an einen Teil der Nutzer (Chromium Dash). Das Chromium-Projekt beschreibt diese Stufe als erste Auslieferung eines neuen Meilensteins an einen kleinen Prozentsatz der Stable-Nutzer (Chromium Docs). Die eigentliche Stable-Auslieferung läuft danach gestaffelt und erreicht in der Regel innerhalb von ein bis zwei Wochen alle Nutzer (Chromium Docs). Wie kurz die Testfenster durch den neuen Takt geworden sind, beschreibt der Beitrag zum Zwei-Wochen-Takt von Chrome.

Alle Termine der Tabelle stammen aus dem Zeitplan der Chrome-Doku (Chrome for Developers). Zwei Zeilen sind für die Praxis wichtiger als der Stichtag selbst. Die erste: Seit Chrome 145 schalten Canary, Dev und Beta XSLT standardmäßig ab (Chrome for Developers). Wer wissen will, wie die eigene Sitemap ab dem 17. November aussieht, kann das in einem dieser Kanäle schon heute nachsehen. Die zweite ist die letzte Zeile mit ihrer Übergangsfrist.

Warum Chrome XSLT abschafft

XSLT, kurz für Extensible Stylesheet Language Transformations, wandelt XML-Dokumente in andere Formate um, meist in HTML. Das World Wide Web Consortium hat XSLT am 16. November 1999 als Empfehlung verabschiedet (Chrome for Developers). Die Sprache selbst hat sich weiterentwickelt: XSLT 2.0 erschien 2007, XSLT 3.0 im Jahr 2017 (Chrome for Developers). In den Browsern ist davon nichts angekommen. Alle großen Browser-Engines unterstützen nativ nur das ursprüngliche XSLT 1.0 von 1999 (Chrome for Developers).

Als Hauptgrund für die Entfernung nennt Chrome die Sicherheit. Die Bibliotheken, die diese Umwandlungen ausführen, im Fall von Chromium libxslt, sind laut der Doku komplexe, alternde Codebasen in C und C++, und gerade diese Art von Code ist anfällig für Fehler in der Speicherverwaltung (Chrome for Developers). Als Beispiele für schwerwiegende Lücken nennt die Doku CVE-2025-7425 und CVE-2022-22834, beide in libxslt (Chrome for Developers). Parallel will Chrome das Lesen von XML auf eine speichersichere Bibliothek in Rust umstellen. XML selbst bleibt dabei im Browser, nur XSLT steht zur Entfernung an (Chrome for Developers).

Hinzu kommt die geringe Verbreitung. Nach den Nutzungsdaten, auf die sich die Chrome-Doku vom Oktober 2025 stützt, verwenden nur etwa 0,02 Prozent der Seitenaufrufe überhaupt XSLT, und weniger als 0,001 Prozent nutzen dafür die Verarbeitungsanweisung (Chrome for Developers). Chrome steht mit dem Schritt nicht allein: Auch die Projekte Firefox und WebKit haben laut der Doku zu erkennen gegeben, dass sie XSLT aus ihren Engines entfernen wollen (Chrome for Developers). Eigene Termine dieser Projekte nennt die Chrome-Doku nicht.

Was XSLT mit Sitemap und Feed zu tun hat

Eine XML-Datei kann über eine Verarbeitungsanweisung im Prolog eine Stilvorlage einbinden; das regelt eine eigene Empfehlung des W3C (W3C). Zeigt diese Anweisung auf eine XSL-Datei, wandelt der Browser das XML vor der Anzeige um, typischerweise in eine HTML-Tabelle mit Spaltenköpfen und klickbaren Adressen. Dieselbe Datei richtet sich aber in erster Linie an Programme. Das Sitemap-Protokoll ist dafür gemacht, Suchmaschinen Angaben zu den Seiten einer Website zu liefern (sitemaps.org). RSS ist ein XML-Dialekt (RSS Advisory Board), und Atom ist als XML-basiertes Format für die Verbreitung von Webinhalten spezifiziert (RFC 4287).

Für Feeds beschreibt die Chrome-Doku den Zweck der Gestaltung ausdrücklich: In vielen bestehenden RSS- und Atom-Feeds macht XSLT das rohe XML lesbar, wenn jemand den Feed direkt im Browser öffnet (Chrome for Developers). Bei Sitemaps folgt die Gestaltung demselben Muster. Die Sitemap-Datei bekommt eine Zeile, die auf eine XSL-Datei zeigt, und wer die Adresse im Browser aufruft, sieht eine Übersicht statt der Tags. Der Kopf einer solchen Datei sieht so aus:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="/sitemap.xsl"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.shop.example/</loc>
  </url>
  <url>
    <loc>https://www.shop.example/produkte/</loc>
  </url>
</urlset>

Ab Chrome 158 fällt genau der Schritt weg, in dem der Browser die XSL-Datei anwendet. Ist XSLT abgeschaltet, zeigt Chrome einen Warnhinweis, der direkt auf eine Suchseite für Erweiterungen verweist (Chrome for Developers). Wie Suchmaschinen-Crawler mit der Verarbeitungsanweisung umgehen, behandelt die Chrome-Doku nicht. Belegt ist dagegen, welche Formate Google für Sitemaps annimmt: XML, RSS, mRSS und Atom 1.0 sowie Textdateien (Google Search Central). Eine Sitemap, die vorher gültiges XML war, bleibt gültiges XML, auch wenn Chrome sie nicht mehr gestaltet.

Wer handeln muss und wer nicht

Ob das XSLT-Ende Arbeit macht, hängt davon ab, wer die Datei liest. Drei Fälle lassen sich unterscheiden, und nur einer verlangt einen echten Umbau:

Welcher Fall vorliegt, zeigt ein Blick in die ersten Zeilen der Dateien. Steht dort type="text/xsl", ist die Datei betroffen. Ob die Ansicht danach noch brauchbar ist, lässt sich in Chrome Canary, Dev oder Beta prüfen, wo XSLT seit Chrome 145 standardmäßig aus ist (Chrome for Developers). Wer eigene Skripte mit XSLTProcessor betreibt, kann Nutzungen über die Reporting API erfassen: Die Doku zeigt einen ReportingObserver, der Abkündigungsberichte mit der Kennung XSLT auswertet (Chrome for Developers). Für Sitemaps und Feeds reicht in der Regel die Kommandozeile:

Neben der Haupt-Sitemap gehören Sitemap-Index, Teil-Sitemaps, News- und Bild-Sitemaps sowie alle Feeds in die Bestandsaufnahme. Erzeugt dieselbe Vorlage alle diese Dateien, wirkt ein Fehler darin an allen Stellen zugleich.

Die Umbaufehler, die mehr schaden als das XSLT-Ende

Das eigentliche Risiko liegt nicht in der Abkündigung, sondern im Umbau danach. Wer die gestaltete Ansicht unbedingt behalten will und dafür die Sitemap-Adresse auf eine HTML-Seite umleitet oder neu ausliefert, ersetzt eine Datei für Maschinen durch eine Seite für Menschen. Der Server antwortet weiter mit Status 200, nur der Inhalt stimmt nicht mehr. Das ist dasselbe Muster wie beim Soft 404 mit Status 200: Die Verfügbarkeitsprüfung bleibt grün, und der Fehler fällt erst auf, wenn jemand den Inhalt ansieht. Die folgenden Fehler treten bei solchen Umbauten typischerweise auf:

1. HTML unter der XML-Adresse. Eine Umleitung von /sitemap.xml auf eine HTML-Übersicht oder eine Einzelseiten-Anwendung, die für jede unbekannte Adresse ihre Startseite ausliefert, liefert Status 200 mit HTML. Sitemaps in einem nicht unterstützten Format führt der Sitemap-Bericht der Search Console als Fehler (Google Search Console-Hilfe).
2. Falscher Medientyp. Für XML-Dokumente ist application/xml standardisiert, text/xml gilt als Alias (RFC 7303). Ein Umbau, der die Datei plötzlich als text/html ausliefert, verrät sich bereits im Kopf der Antwort.
3. Fremde Elemente in der Sitemap. Das Sitemap-Protokoll legt den Aufbau fest: ein urlset mit Namensraum, je Seite ein url mit loc (sitemaps.org). Erweiterungen sind über einen eigenen Namensraum vorgesehen (sitemaps.org). Den Polyfill-Weg, der ein Skript-Element in die XML-Datei setzt, beschreibt die Chrome-Doku allgemein und für Feeds; Sitemaps erwähnt sie nicht (Chrome for Developers).
4. Kodierung und Größe. Wer bei der Gelegenheit Dateien zusammenlegt, muss die Grenzen im Blick behalten: höchstens 50.000 URLs und 50 MB unkomprimiert je Sitemap (Google Search Central), die Datei in UTF-8 (sitemaps.org).
5. Verweise auf die alte Adresse. Ändert sich der Dateiname, müssen die Sitemap:-Zeile in der robots.txt, der Sitemap-Index und die Einreichung bei den Suchmaschinen mitziehen. Die Angabe in der robots.txt ist ein vorgesehener Weg, Suchmaschinen den Ort der Sitemap mitzuteilen (sitemaps.org). Welche Fehler dort sonst lauern, zeigt der Beitrag zu Fehlern in der robots.txt.

Feeds: Menschen und Feedreader auseinanderhalten

Feedreader lesen das XML und brauchen keine Gestaltung. Die XSL-Ansicht war für Menschen gedacht, die auf einen Feed-Link klicken. Für diesen Fall nennt die Chrome-Doku als üblichen HTML-Weg, den Feed im Kopf der HTML-Seite über <link rel="alternate" type="application/rss+xml"> anzukündigen, statt einen sichtbaren Link auf die XML-Datei zu setzen (Chrome for Developers). Feedreader finden den Feed dann auch, wenn jemand nur die Adresse der Website einträgt, und Besucher sehen die normale Seite. Die Doku fasst das als gewohnte Arbeitsteilung des Webs zusammen: HTML für Menschen, XML für Maschinen (Chrome for Developers).

<link rel="alternate" type="application/rss+xml"
      title="Neuigkeiten aus dem Shop"
      href="https://www.shop.example/feed.xml">
<link rel="alternate" type="application/atom+xml"
      title="Neuigkeiten aus dem Shop (Atom)"
      href="https://www.shop.example/atom.xml">

Als zweiten Weg beschreibt die Doku eine zusätzliche Zeile im Feed, die einen Polyfill lädt und die bisherige Umwandlung im Browser nachbildet. Nach ihrer Darstellung sollte das die Feedreader nicht beeinträchtigen, weil das Skript-Element direkt unter dem Wurzelelement steht (Chrome for Developers). Damit trägt eine Datei, die bisher reine Daten enthielt, ein Skript, das gepflegt werden will. Ob sich das lohnt, hängt davon ab, wie oft Menschen den Feed tatsächlich im Browser öffnen.

Ein Feed kann zugleich als Sitemap dienen. Das Sitemap-Protokoll nimmt RSS 2.0 sowie Atom 0.3 und 1.0 an (sitemaps.org), und Google unterstützt RSS, mRSS und Atom 1.0 als Sitemap-Format (Google Search Central). Wer den Feed umbaut, verändert in diesem Fall auch, was Suchmaschinen als Sitemap erhalten. Für Atom gilt zudem eine klare Regel: Atom-Dokumente müssen wohlgeformtes XML sein (RFC 4287). Ein eingeschobenes HTML-Fragment, das das XML bricht, kann deshalb jeden Feedreader treffen, nicht nur Chrome.

Gestaltung ohne XSLT: drei Wege und ihre Folgen

Wer die lesbare Ansicht behalten will, hat mehr Möglichkeiten als einen Komplettumbau. Der kleinste Schritt ist der Wechsel von XSL auf CSS. Die Verarbeitungsanweisung bleibt, sie zeigt nur auf eine CSS-Datei, und das unterstützt Chrome weiter (Chrome for Developers). CSS gestaltet die vorhandenen Elemente, wandelt sie aber nicht um: Aus loc und lastmod wird keine Tabelle mit Spaltenköpfen, sondern eine lesbar gesetzte Liste.

/* im Kopf der sitemap.xml:
   <?xml-stylesheet type="text/css" href="/sitemap.css"?> */
urlset  { display: block; margin: 2rem; font-family: system-ui, sans-serif; }
url     { display: block; padding: 0.4rem 0; border-bottom: 1px solid #e2e8f0; }
loc     { display: block; color: #004d43; }
lastmod { display: block; color: #64748b; font-size: 0.85rem; }

Der zweite Weg verlegt die Umwandlung auf den Server und liefert fertiges HTML aus (Chrome for Developers). Für die Sitemap gilt dabei eine harte Grenze: Die HTML-Fassung gehört unter eine eigene Adresse, etwa auf eine Übersichtsseite für Besucher, und /sitemap.xml bleibt XML. Wer beides unter einer Adresse zusammenführt, erzeugt genau den Fehler aus dem vorigen Abschnitt.

Der dritte Weg ist der unscheinbarste: die Verarbeitungsanweisung entfernen und die Datei sonst lassen, wie sie ist. Für eine Sitemap, deren Zweck nach dem Protokoll die Information von Suchmaschinen ist, ist das oft die vernünftigste Lösung, denn es bleibt keine XSL-Datei zu pflegen. Die Übersicht stellt die Wege nebeneinander:

Ein Prüfplan für die Wochen um den 17. November

Der Plan trennt die Frage der Gestaltung von der Frage, ob die Datei für Maschinen intakt bleibt. Nur die zweite muss gemessen werden, nach jeder Änderung und noch einmal nach dem Stichtag.

• Bestand aufnehmen: alle XML-Adressen mit type="text/xsl" finden, also Sitemap, Sitemap-Index, Teil-Sitemaps und Feeds.
• Vorab ansehen: die Dateien in Chrome Canary, Dev oder Beta öffnen, wo XSLT seit Chrome 145 standardmäßig aus ist (Chrome for Developers).
• Je Datei entscheiden: nichts tun, Verweis entfernen, auf CSS umstellen oder eine eigene HTML-Seite unter eigener Adresse anlegen.
• Nach jeder Änderung messen: Status 200, ein Medientyp mit xml, die ersten Bytes <?xml oder <urlset und eine URL-Zahl wie vor dem Umbau.
• Suchmaschinenseite prüfen: den Sitemap-Bericht der Search Console auf Abruffehler und Formatfehler ansehen (Google Search Console-Hilfe).
• Rund um den Stichtag erneut prüfen: Die Auslieferung von Chrome 158 läuft gestaffelt und erreicht alle Nutzer in der Regel erst nach ein bis zwei Wochen (Chromium Docs).
• Verweise nachziehen: robots.txt, Link-Elemente im HTML-Kopf und Einträge im Sitemap-Index.

Gerade in den Wochen der gestaffelten Auslieferung kommt es vor, dass eine Kollegin die Sitemap noch als Tabelle sieht und ein Kunde schon als rohes XML. Das ist kein Fehler auf dem Server, sondern ein Versionsunterschied im Browser. Wie man solche Abweichungen zwischen dem eigenen Rechner und dem eines Kunden eingrenzt, beschreibt der Beitrag Bei uns geht die Seite, beim Kunden nicht.

Sitemap und Feed nach dem Umbau überwachen

Einen Teil dieser Messung übernimmt das SEO-Monitoring von XICTRAQ® im festen Takt. Die Prüfung ruft /sitemap.xml ab, zählt die enthaltenen URLs und erkennt einen Sitemap-Index; bei einem Index sammelt sie bis zu 50 Kind-Sitemaps und bis zu 3.000 URLs ein (XICTRAQ-Dokumentation). Antwortet die Adresse mit Status 200, aber mit HTML statt XML, wertet XICTRAQ® die Sitemap als nicht erreichbar (XICTRAQ-Dokumentation). Die Prüfung ist in jedem Plan enthalten und läuft im Free-Plan alle 24 Stunden, in den bezahlten Plänen alle 12 Stunden (XICTRAQ-Dokumentation). Einzelheiten stehen im Handbuch zum SEO-Monitoring.

Ändert sich die Zahl der URLs, hält das Änderungsprotokoll den Wechsel fest, mit den hinzugekommenen und entfallenen Pfaden. So wird sichtbar, wenn ein Umbau Teil-Sitemaps verliert oder eine Vorlage plötzlich weniger Seiten ausgibt. Wie sich Sitemap-Überwachung grundsätzlich aufbauen lässt, beschreibt der Beitrag zum Sitemap-Monitoring. Für eine schnelle Einzelprüfung direkt nach dem Umbau gibt es den kostenlosen Sitemap-Validator: Er meldet den HTTP-Status, prüft, ob XML ankommt und sich lesen lässt, und zählt die URLs. Wie der SEO-Bereich im Dashboard aussieht, zeigt die Live-Demo.

Den Feed deckt die Sitemap-Prüfung nicht ab. Dafür eignet sich ein Endpunkt-Check im API-Monitoring, das ab dem Starter-Plan enthalten ist: Er ruft die Feed-Adresse im eingestellten Intervall ab und prüft den HTTP-Status sowie per Text-Enthält-Prüfung, ob die Antwort etwa <rss oder <feed enthält. Schlägt die Prüfung zweimal in Folge fehl, meldet XICTRAQ® das über die eingerichteten Alarmkanäle.