Chrome XSLT Removal on November 17: What Breaks on Your Sitemaps and Feeds

Chrome XSLT support ends with Chrome 158, which reaches the stable channel on November 17, 2026. From that release, Chrome stops running XSLT stylesheets on XML files, except for sites in Google’s Origin Trial and organizations using an Enterprise Policy. Those two exceptions end with Chrome 176 on August 17, 2027.

XSLT is an old W3C language that turns XML into HTML. Browsers have supported it since about 2000. Most sites never touch it directly, but several common CMS sitemap tools use it quietly to make XML sitemaps look like a readable web page. This post covers the Chrome XSLT timeline, what still uses XSLT on agency and nonprofit sites, what actually breaks, and how to fix it.

The short version: search engines read your sitemap’s XML, not the styled view, so sitemap crawling does not change. What breaks is the human view. Someone opening sitemap.xml or a styled RSS feed in Chrome will no longer see the formatted table. Pages that call the XSLTProcessor JavaScript API will break outright. Check your sitemaps and feeds now, and decide whether to drop the stylesheet, move the transform to the server or add a JavaScript library.

What Google is removing in Chrome 158

Google’s XSLT deprecation page names two things that go away:

• The XSLT processing instruction. This is the line at the top of an XML file that reads <?xml-stylesheet type="text/xsl" ...?>. It tells the browser to style the file.
• The XSLTProcessor class. This is the JavaScript API that runs XSLT inside a web page.

XML itself stays. So does <?xml-stylesheet type="text/css"?>, which styles XML with CSS instead of XSLT.

Google gives three reasons. The C and C++ libraries behind XSLT, such as libxslt, are old and prone to memory safety bugs. Usage is low: Google says about 0.02% of page loads use XSLT, and less than 0.001% use the processing instruction. And newer tools cover the same jobs.

Why the Chrome XSLT date comes sooner than it sounds

Chrome moved to a two-week stable cycle with Chrome 153 on September 8, 2026, according to Google’s two-week release announcement. That is why the version numbers climb so fast. The Chromium release schedule lists Chrome 158 for stable on November 17, with early stable on November 4 and beta from October 28.

Chrome updates itself, so plan as if most visitors will have 158 soon after November 17. Extended Stable keeps its eight-week cycle, Google says. Managed fleets on that channel may reach 158 on a different date. We have not seen a published Extended Stable date for 158.

The timing also lands in a busy stretch. We listed the other year-end dates in our Q4 2026 platform calendar.

Firefox and Safari are moving the same way

Google says the Firefox and WebKit projects "have also indicated plans to remove XSLT from their browser engines." Mozilla’s standards position from August 2025 supports Chrome’s test of whether removal is web-compatible. It also says that if removal proves impossible, Mozilla would replace its current XSLT code with a safer one.

Firefox has a kill switch already. Firefox 151 added an XSLTEnabled enterprise policy, as we covered in our Firefox ESR 140 end-of-life post. As of October 2026, we have not found a removal date from Mozilla or Apple.

So Chrome goes first, by a wide margin. Edge and other Chromium browsers share Chrome’s engine code, but we have not seen Microsoft publish its own date. Our guide to browser engines explains how those browsers relate.

What still uses XSLT on your sites

For our readers, the most common Chrome XSLT exposure is the XML sitemap. We checked the source code of the main WordPress and Drupal tools.

WordPress core. WordPress 7.1 adds the processing instruction to /wp-sitemap.xml, pointing at wp-sitemap.xsl. The 7.1 renderer code lets you turn it off with the wp_sitemaps_stylesheet_url filter. Return a falsey value and WordPress serves raw XML.

WordPress 7.2 changes this. As of October 21, the 7.2 development code marks the stylesheets deprecated "following the deprecation of XSLT by browser manufacturers." Sitemaps no longer carry the processing instruction, and the stylesheet filters do nothing. WordPress 7.2 is set for December 8, three weeks after Chrome 158. Our WordPress 7.2 Beta 1 checklist covers the rest of that release.

Yoast SEO. Yoast’s sitemap code adds a processing instruction pointing at main-sitemap.xsl. Its wpseo_stylesheet_url filter receives the whole line, so returning an empty string removes it. We found no XSLT change in Yoast’s current code as of October 21.

Rank Math. Rank Math’s sitemap generator also adds a main-sitemap.xsl processing instruction. It skips the line when the stylesheet value is empty, and its code exposes a sitemap/{$type}_stylesheet_url filter.

Drupal Simple XML Sitemap. The module added an XSL stylesheet for human readability in its 8.x-3.x branch, per the original Drupal.org issue. Live sitemaps built with it start with a processing instruction pointing at /sitemap_generator/index/sitemap.xsl.

Feeds, library systems and data viewers

RSS and Atom feeds. Google says many feeds use XSLT so the raw XML is readable when someone opens it in a browser. Check your feed URLs the same way you check sitemaps.

Library, archive and government systems. Digital collections, repository software and open data portals publish a lot of XML. Some may style it with XSLT for a browser view. Others may build pages with XSLTProcessor in JavaScript. We have not tested specific products. If you support a library catalog, a finding aid site or a data feed viewer, treat it as a suspect until you check.

Embedded devices. Google also names devices whose built-in admin pages use XSLT. If the device cannot be updated, Google says its browser extension is likely the best option. That is an IT task more than a web task.

What breaks and what does not after the Chrome XSLT removal

Google’s sitemap documentation does not mention stylesheets at all. Google accepts XML sitemaps, RSS 2.0 and Atom 1.0. The stylesheet was always for people.

When XSLT is off, Google says Chrome shows a warning banner that links to an extension search page. Expect a few confused emails from staff who open the sitemap to check it. Our technical SEO guide covers what to check in Search Console instead.

How to check a site for Chrome XSLT use

1. Open each sitemap and feed and view the source. Look for <?xml-stylesheet type="text/xsl" near the top. The browser view can hide it, so use view-source or a command such as curl -s https://example.org/sitemap.xml | head -3.
2. Search your code for XSLTProcessor, .xsl and xml-stylesheet. Include themes, custom modules and old JavaScript.
3. Test in Chrome Beta or Canary. Both already have XSLT off by default, so you can see the Chrome XSLT result today.
4. Watch the console and Lighthouse. Chrome has shown deprecation warnings since Chrome 143.
5. Collect reports at scale. A ReportingObserver can catch deprecation reports with the ID XSLT. Chrome admins can use the Legacy Technology Report.

Chrome XSLT fixes, from simplest to most work

Drop the stylesheet. For sitemaps, this is usually the right call. Use the WordPress, Yoast or Rank Math filter above, or wait for WordPress 7.2 for core sitemaps. People who open the file see plain XML, which is what crawlers see anyway.

Move the transform to the server. Run the same XSLT on the server and send finished HTML. One open WordPress Trac ticket, #65635, proposes a /wp-sitemap.html page built this way. It is still awaiting review.

Use a JavaScript library. Google points to SaxonJS, which supports XSLT 3.0, and to a WebAssembly polyfill that replaces XSLTProcessor. Google says adding the polyfill script to a feed does not affect RSS readers. Test that claim on your own feed before you rely on it.

Use the Origin Trial or Enterprise Policy. Both buy time until August 2027. Use them only while a real fix is in progress.

Link feeds properly. For RSS, Google suggests a <link rel="alternate" type="application/rss+xml"> tag on your HTML pages instead of a visible link to the raw feed.

Frequently Asked Questions