Chrome 158 drops XSLT: What changes for sitemaps and feeds

What Chrome 158 removes on November 17

Chromium has officially deprecated XSLT, and it covers both ways the browser has run the language so far: the XSLTProcessor JavaScript API and the XSLT processing instruction at the top of an XML file, meaning a line such as <?xml-stylesheet type="text/xsl" href="sitemap.xsl"?> (Chrome for Developers). The Chrome documentation names version 158 on November 17, 2026 as the removal date (Chrome for Developers). The Chromium project's release schedule lists the same day as the stable date for milestone 158 (Chromium Dash).

Even so, November 17 is a single cutoff only on paper. According to the same schedule, Chrome 158 already goes out as an early stable release to part of the user base on November 4 (Chromium Dash). The Chromium project describes this stage as the first time a new milestone ships to a small percentage of stable channel users (Chromium Docs). The actual stable rollout is then staged and generally reaches all users within one to two weeks (Chromium Docs). How much the new cadence has shortened test windows is covered in the article on Chrome's two-week release cycle.

All dates in the table come from the timeline in the Chrome documentation (Chrome for Developers). Two rows matter more in practice than the cutoff itself. The first: since Chrome 145, Canary, Dev and Beta disable XSLT by default (Chrome for Developers). Anyone who wants to know how their own sitemap will look after November 17 can check it in one of these channels today. The second is the last row with its transition period.

Why Chrome is removing XSLT

XSLT, short for Extensible Stylesheet Language Transformations, transforms XML documents into other formats, most often HTML. The World Wide Web Consortium published XSLT as a recommendation on November 16, 1999 (Chrome for Developers). The language itself kept evolving: XSLT 2.0 arrived in 2007 and XSLT 3.0 in 2017 (Chrome for Developers). None of that reached browsers. All major browser engines natively support only the original XSLT 1.0 from 1999 (Chrome for Developers).

Chrome names security as the main reason for the removal. According to the documentation, the libraries that run these transformations, libxslt in the case of Chromium, are complex, aging C and C++ codebases, and this kind of code is particularly prone to memory safety bugs (Chrome for Developers). As examples of high-severity vulnerabilities, the documentation cites CVE-2025-7425 and CVE-2022-22834, both in libxslt (Chrome for Developers). In parallel, Chrome plans to move XML parsing to a memory-safe library written in Rust. XML itself stays in the browser; only XSLT is slated for removal (Chrome for Developers).

Low usage adds to that. According to the usage data cited in the Chrome documentation from October 2025, only about 0.02 percent of page loads use XSLT at all, and less than 0.001 percent do so through the processing instruction (Chrome for Developers). Chrome is not alone in this step: according to the documentation, the Firefox and WebKit projects have also indicated plans to remove XSLT from their engines (Chrome for Developers). The Chrome documentation does not give dates for those projects.

What XSLT has to do with sitemaps and feeds

An XML file can associate a stylesheet through a processing instruction in its prolog; a separate W3C recommendation defines this (W3C). If that instruction points to an XSL file, the browser transforms the XML before display, typically into an HTML table with column headings and clickable URLs. The same file, however, is primarily meant for programs. The sitemap protocol exists to give search engines details about the pages of a website (sitemaps.org). RSS is a dialect of XML (RSS Advisory Board), and Atom is specified as an XML-based format for syndicating web content (RFC 4287).

For feeds, the Chrome documentation states the purpose of the styling explicitly: in many existing RSS and Atom feeds, XSLT makes the raw XML readable when someone opens the feed directly in the browser (Chrome for Developers). Styled sitemaps follow the same pattern. The sitemap file gets a line pointing to an XSL file, and anyone who opens the URL in the browser sees an overview instead of the tags. The top of such a file looks like this:

<?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/products/</loc>
  </url>
</urlset>

From Chrome 158 on, exactly the step in which the browser applies the XSL file goes away. When XSLT is disabled, Chrome shows a warning banner that links directly to an extension search page (Chrome for Developers). How search engine crawlers handle the processing instruction is not covered by the Chrome documentation. What is documented is which formats Google accepts for sitemaps: XML, RSS, mRSS, and Atom 1.0 as well as text files (Google Search Central). A sitemap that was valid XML before remains valid XML, even if Chrome no longer styles it.

Who needs to act and who does not

Whether the end of XSLT creates work depends on who reads the file. Three cases can be distinguished, and only one calls for a real rebuild:

A look at the first lines of the files shows which case applies. If they contain type="text/xsl", the file is affected. Whether the view is still usable afterwards can be checked in Chrome Canary, Dev or Beta, where XSLT has been off by default since Chrome 145 (Chrome for Developers). If you run your own scripts with XSLTProcessor, you can capture usage through the Reporting API: the documentation shows a ReportingObserver that evaluates deprecation reports with the ID XSLT (Chrome for Developers). For sitemaps and feeds, the command line is usually enough:

Besides the main sitemap, the inventory should include the sitemap index, child sitemaps, news and image sitemaps, and every feed. If one template generates all of these files, a mistake in it hits every file at once.

Rebuild mistakes that do more harm than the end of XSLT

The real risk is not the deprecation but the rebuild that follows. If you insist on keeping the styled view and redirect the sitemap URL to an HTML page or serve one in its place, you replace a file for machines with a page for people. The server keeps answering with status 200; only the content is wrong. It is the same pattern as a soft 404 with status 200: the availability check stays green, and the error only surfaces when someone looks at the content. These mistakes typically show up in such rebuilds:

1. HTML at the XML URL. A redirect from /sitemap.xml to an HTML overview, or a single-page application that serves its home page for every unknown URL, returns status 200 with HTML. The Sitemaps report in Search Console lists sitemaps in an unsupported format as errors (Google Search Console Help).
2. Wrong media type. For XML documents, application/xml is the standardized type, and text/xml is defined as an alias (RFC 7303). A rebuild that suddenly serves the file as text/html gives itself away in the response header.
3. Foreign elements in the sitemap. The sitemap protocol defines the structure: a urlset with a namespace, and one url with a loc per page (sitemaps.org). Extensions are meant to go through a namespace of your own (sitemaps.org). The polyfill approach, which places a script element in the XML file, is described in the Chrome documentation in general terms and for feeds; it does not mention sitemaps (Chrome for Developers).
4. Encoding and size. If you merge files while you are at it, keep the limits in mind: no more than 50,000 URLs and 50 MB uncompressed per sitemap (Google Search Central), with the file encoded in UTF-8 (sitemaps.org).
5. References to the old URL. If the file name changes, the Sitemap: line in robots.txt, the sitemap index and the submissions to search engines have to follow. The entry in robots.txt is an intended way to tell search engines where the sitemap is (sitemaps.org). Which other mistakes lurk there is covered in the article on robots.txt mistakes.

Feeds: keeping people and feed readers apart

Feed readers read the XML and need no styling. The XSL view was meant for people who click a feed link. For that case, the Chrome documentation names the standard HTML approach: announce the feed in the head of the HTML page with <link rel="alternate" type="application/rss+xml"> instead of placing a visible link to the XML file (Chrome for Developers). Feed readers then find the feed even when someone enters only the website URL, and visitors see the normal page. The documentation sums this up as the usual division of labor on the web: HTML for humans, XML for machines (Chrome for Developers).

<link rel="alternate" type="application/rss+xml"
      title="News from the shop"
      href="https://www.shop.example/feed.xml">
<link rel="alternate" type="application/atom+xml"
      title="News from the shop (Atom)"
      href="https://www.shop.example/atom.xml">

As a second approach, the documentation describes an additional line in the feed that loads a polyfill and reproduces the previous transformation in the browser. According to the documentation, this should not affect feed readers because the script element sits directly under the root element (Chrome for Developers). It does mean that a file which used to contain pure data now carries a script that needs maintenance. Whether that is worth it depends on how often people actually open the feed in the browser.

A feed can double as a sitemap. The sitemap protocol accepts RSS 2.0 as well as Atom 0.3 and 1.0 (sitemaps.org), and Google supports RSS, mRSS, and Atom 1.0 as sitemap formats (Google Search Central). If you rebuild the feed, you also change what search engines receive as a sitemap in that case. Atom has a clear rule on top of that: Atom documents must be well-formed XML (RFC 4287). An inserted HTML fragment that breaks the XML can therefore affect any feed reader, not just Chrome.

Styling without XSLT: three approaches and their consequences

If you want to keep a readable view, you have more options than a complete rebuild. The smallest step is switching from XSL to CSS. The processing instruction stays; it simply points to a CSS file, and Chrome keeps supporting that (Chrome for Developers). CSS styles the existing elements but does not transform them: loc and lastmod do not turn into a table with column headings, but into a neatly formatted list.

/* at the top of 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; }

The second approach moves the transformation to the server and delivers finished HTML (Chrome for Developers). For the sitemap, however, there is a hard limit: the HTML version belongs at its own URL, for example an overview page for visitors, and /sitemap.xml stays XML. Merging both at one URL produces exactly the mistake from the previous section.

The third approach is the least conspicuous: remove the processing instruction and otherwise leave the file as it is. For a sitemap whose purpose under the protocol is to inform search engines, that is often the most sensible solution, since no XSL file is left to maintain. The overview puts the approaches side by side:

A checklist for the weeks around November 17

The plan separates the question of styling from the question of whether the file stays intact for machines. Only the second has to be measured, after every change and once more after the cutoff.

• Take inventory: find every XML URL with type="text/xsl", meaning sitemap, sitemap index, child sitemaps and feeds.
• Preview: open the files in Chrome Canary, Dev or Beta, where XSLT has been off by default since Chrome 145 (Chrome for Developers).
• Decide per file: do nothing, remove the reference, switch to CSS, or create a separate HTML page at its own URL.
• Measure after every change: status 200, a media type containing xml, first bytes <?xml or <urlset, and a URL count matching the one before the rebuild.
• Check the search engine side: look at the Sitemaps report in Search Console for fetch and format errors (Google Search Console Help).
• Check again around the cutoff: the Chrome 158 rollout is staged and generally reaches all users only after one to two weeks (Chromium Docs).
• Update references: robots.txt, link elements in the HTML head, and entries in the sitemap index.

Especially during the weeks of the staged rollout, a colleague may still see the sitemap as a table while a customer already sees raw XML. That is not a server error but a browser version difference. How to narrow down such discrepancies between your own machine and a customer's is described in the article The site works for us but not for the customer.

Monitoring sitemaps and feeds after the rebuild

SEO monitoring from XICTRAQ® takes over part of this measurement on a fixed schedule. The check fetches /sitemap.xml, counts the URLs it contains and detects a sitemap index; for an index it collects up to 50 child sitemaps and up to 3,000 URLs (XICTRAQ documentation). If the URL answers with status 200 but with HTML instead of XML, XICTRAQ® treats the sitemap as unreachable (XICTRAQ documentation). The check is included in every plan and runs every 24 hours on the Free plan and every 12 hours on the paid plans (XICTRAQ documentation). Details are in the SEO monitoring documentation.

If the number of URLs changes, the change log records it, together with the added and removed paths. That makes it visible when a rebuild loses child sitemaps or a template suddenly outputs fewer pages. How to set up sitemap monitoring in general is covered in the article on sitemap monitoring. For a quick one-off check right after the rebuild, there is the free sitemap validator: it reports the HTTP status, checks whether XML arrives and can be parsed, and counts the URLs. The live demo shows what the SEO area of the dashboard looks like.

The sitemap check does not cover the feed. For that, an endpoint check in API monitoring works well; it is included from the Starter plan. It fetches the feed URL at the configured interval and checks the HTTP status as well as, through a text-contains check, whether the response includes something like <rss or <feed. If the check fails twice in a row, XICTRAQ® reports it through the alert channels you have set up.