On 17 November 2026, Chrome 158 reaches stable and client-side XSLT stops working in it. Microsoft Edge inherits the same engine. If any file on your site carries an <?xml-stylesheet?> instruction — and if you run WordPress with almost any SEO plugin, one of them does — the page a human opens in a browser will change that day.
This site is in that group. Checked on 12 October 2026, doctor-seo.net/sitemap_index.xml carries <?xml-stylesheet type='text/xsl' href='//doctor-seo.net/wp-content/plugins/wordpress-seo/css/main-sitemap.xsl'?>, so the friendly table a visitor sees today is produced by XSLT and will not be produced after Chrome 158.
The short version is that this matters a lot less for search than the headlines suggest, and rather more for the humans who read XML. Crawling is untouched. What changes is the readable face of every XML file you publish.
What XSLT actually is
XSLT — Extensible Stylesheet Language Transformations — is a language for turning one XML document into another document. Give it an XML file and a stylesheet of template rules, and it emits HTML, or text, or different XML. XSLT 1.0 became a W3C Recommendation in 1999, and 1.0 is the version browsers implement; later versions, 2.0 and 3.0, live outside the browser.
Inside a browser it works through a processing instruction at the top of the XML file: <?xml-stylesheet type='text/xsl' href='style.xsl'?>. When the browser loads the XML and finds that line, it fetches the stylesheet, runs the transformation in the browser, and renders the result instead of the XML. There is also a scripting path, XSLTProcessor, which does the same thing from JavaScript.
The important property, and the one most coverage skips, is that this is a rendering step and nothing else. The XML on the wire is unchanged. Anything that parses the file rather than displaying it — a crawler, a feed reader, a script — never runs the stylesheet at all. XSLT is a cosmetic layer over machine-readable data, and that is exactly why its removal is both very visible and, for search, very minor.
What Google published, and when
Google set out the plan in Removing XSLT for a more secure browser on the Chrome developer site, written by Mason Freed and Dominik Röttsches and Last updated 2025-10-29 UTC. The reasoning is security. The document says the continued inclusion of XSLT 1.0 in browsers “presents a significant and unnecessary security risk”, describes the underlying libraries as “complex, aging C/C++ codebases” that “receive far less maintenance and security scrutiny than core JavaScript engines”, cites CVE-2025-7425 and CVE-2022-22834 in libxslt, and concludes that the risk “far outweighs its limited modern utility”.
The usage figure behind that judgement is Google’s own: the same page states that “only about 0.02% of web page loads today actually use XSLT at all”, and that fewer than 0.001% use XSLT processing instructions. Google does not publish the sampling behind those counters, so they are platform telemetry rather than an independent study, and no sample size is given.
Two escape hatches exist and both have end dates. An enterprise policy, XSLTEnabled, went live in Chrome 146; an origin trial opened in Chrome 152. Chrome Platform Status records the removal milestone as 158 and the origin trial window as 152 to 175, with both hatches closing in Chrome 176 on 17 August 2027. Chromium Dash, read live on 12 October 2026, gives Chrome 158 a stable date of 2026-11-17 and a branch point of 2026-10-26. Today’s stable release is Chrome 156.
This is not only Chrome
Microsoft’s site-impacting-changes page for Edge says XSLT support “represents a disproportionate attack surface” and that Edge will follow Chromium. It documents an XSLTEnabled feature policy in Edge 147 and tells organisations to test with it disabled. Edge 147 has already removed one narrower case: using XSLT to transform XML into SVG. The main deprecation, though, is listed as “Future release, TBD”. Microsoft has published no date.
The other engines are not holding out either. Chrome Platform Status records the Gecko and WebKit positions on removal as Positive, and the web developer view as Negative. On Mozilla’s standards-positions tracker, Simon Pieters wrote on 27 August 2025 that “it would be good for the long-term health of the web platform and good for user security to remove XSLT”. So the direction of travel is every major engine, and the dissent is coming from the people who use the feature, not from the people who ship it.
What it will actually look like
Google’s page describes a warning banner but does not show the result, so we produced it. On 12 October 2026 we rendered this site’s own sitemap index twice in Chromium 141: once normally, and once with the browser launched as --disable-blink-features=XSLT, which is the same switch the removal flips. With XSLT, Yoast’s stylesheet produces a titled page with a two-column table of sitemaps and last-modified dates. Without it, the browser prints a banner reading “This document cannot be formatted as intended. It uses XSLT, which the browser does not support. You might be able to install a browser extension that allows you to view it.” and below it the raw XML tree, processing instruction included.
What breaks, and what does not
Four uses account for almost all client-side XSLT on the open web, and they do not fail equally. A stylesheet on a sitemap or a feed loses its appearance and nothing else. A public XML data page — a register, a regulator’s code list, a weather station feed — loses the only form in which a person could read it. And where XSLT is doing work inside an application, the function stops running rather than merely stops looking right.
For search specifically, the honest answer is that nothing happens. Crawlers fetch and parse the XML; they do not execute a stylesheet. Google’s own documentation backs that up by omission: Build and submit a sitemap, Last updated 2026-07-08 UTC, contains no “XSLT”, no “stylesheet”, no “xml-stylesheet” and no “browser” anywhere in its body, and describes the mechanism purely in fetch-and-parse terms: “Google will attempt to crawl your URLs exactly as listed”, and submitting one “is merely a hint”. A stylesheet was never addressed to a search engine. It was addressed to you, and to whoever you send the URL to.
That is the part worth holding onto when a client forwards a screenshot of the warning banner in a panic. Nothing has been deindexed. The file still validates, still lists the same URLs, and the path from crawling to indexing is identical. What changed is that the file now looks like what it has always been.
What to do this week
- If you would rather not do it by hand, use our XSLT checker. Paste your domain and it reports, file by file, which ones depend on XSLT and what a person will see from 17 November.
- Find out whether you ship one.
curl -s https://example.com/sitemap_index.xml | grep xml-stylesheetanswers it in one line. Repeat for your feed, and for any XML endpoint you publish. - Open the browser console on those URLs in Chrome today. Deprecation warnings have been printed since Chrome 143, so the console is a free inventory of every XSLT file your own site loads.
- Decide, per file, between leaving it and replacing it. Leaving a stylesheet in place is harmless — after Chrome 158 the instruction is simply ignored. Replacing it means either transforming on the server and serving HTML, or publishing a plain HTML page that links the XML.
- On WordPress core sitemaps, the switch already exists. The
wp_sitemaps_stylesheet_urlfilter, in core since 5.5.0, displays raw XML with no stylesheet when it returns a falsey value — useful for seeing the post-removal state before November. - For RSS and Atom, do the thing Google recommends. Put
<link rel='alternate' type='application/rss+xml'>in your HTML pages so readers and feed clients discover the feed without ever looking at the raw file. - If XSLT is load-bearing in an application, start now, not in November. The documented routes are server-side transformation, moving the endpoint to JSON, or a client-side library — Google names Saxonica’s JavaScript implementation and a WebAssembly polyfill. The enterprise policy and the origin trial buy time until 17 August 2027 and no longer.
- Do not rewrite your sitemap strategy. There is no crawling change to optimise for, and a sitemap that validates today validates on 18 November too.
Where the industry genuinely disagrees
Is a browser usage counter a sufficient basis for removing a web platform feature? One camp says yes and says the arithmetic is not close: 0.02% of page loads cannot justify an unmaintained C parser inside the most attacked program on most people’s computers, every engine agrees, and a platform that can never remove anything eventually cannot be made safe. The other camp says a usage counter measures page loads and not consequence, that the 0.02% is concentrated in exactly the places where breakage costs most, and that the removal proposal was never tested against the long tail. The strongest version of that case is the WHATWG issue titled “XSLT removal will break multiple government and regulatory sites across the world”, which names congress.gov, govinfo.gov, weather.gov, europarl.europa.eu, tga.gov.au and the European Pollutant Release and Transfer Register among others, and argues that “the proposal to remove XSLT from the spec doesn’t acknowledge existing use cases beyond Chrome Status counter stats” and that “There’s no investigation into the long tail of web sites, of how many exactly would be broken”.
Nobody can settle it from published evidence, because no party has published a count of affected sites. Google published a percentage of page loads; the objectors published a list of examples. Those are different units, and neither converts into the other. This article reports the disagreement and does not resolve it.
The author’s opinion — Txema Hermoso
What I will defend is narrow and reproducible: XSLT in the browser is a rendering layer, Google’s sitemap documentation does not mention it, and the capture above shows exactly what disappears. Anyone can re-run that capture with one browser flag.
What I will not say is that this is a ranking event, because it is not one, and I will not tell you that the security argument is wrong either. I am not in a position to weigh an unmaintained parser’s attack surface against a list of government URLs, and neither is anyone else publishing on this, because the count that would let you do it has never been published by anybody.
The one judgement I will offer is about priorities. If you manage sites, the XSLT story is a thirty-minute inventory task and then a decision you can mostly answer with “leave it”. The cost of this change does not land on SEO teams at all; it lands on public bodies that published machine-readable data and made it human-readable the cheapest way the platform offered. That asymmetry is the story, and it is worth more of your attention than your sitemap’s appearance — which is also why it belongs in the technical SEO level as a lesson about depending on rendering you do not control.
What is still unknown
Whether Edge ships the removal on Chrome’s schedule or its own, since Microsoft has published no date. Whether Firefox and Safari follow, and when — both engines have recorded a positive position and neither has published a timeline. How many sites actually break, which nobody has counted. Whether the origin trial is extended past Chrome 176. And whether any plugin vendor ships a replacement for the sitemap view before November, or simply lets the stylesheet become inert.
Sources
- Mason Freed and Dominik Röttsches, Google, Removing XSLT for a more secure browser, Last updated 2025-10-29 UTC, read 12 October 2026 (twice).
- Chrome Platform Status, feature 4709671889534976, XSLT, read via the public API 12 October 2026: deprecation 143, removal 158, origin trial 152–175, final 176; Gecko and WebKit positions Positive, web developer view Negative.
- Chromium Dash milestone schedule for Chrome 158, read 12 October 2026: stable date 2026-11-17, branch point 2026-10-26. Current stable milestone 156.
- Microsoft, Site impacting changes in Microsoft Edge, read 12 October 2026. Deprecation listed as “Future release, TBD”;
XSLTEnabledpolicy in 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”, read 12 October 2026.
- Google, Build and submit a sitemap, Last updated 2026-07-08 UTC, read 12 October 2026.
- WordPress, wp_sitemaps_stylesheet_url, introduced in WordPress 5.5.0.
- First-party:
doctor-seo.net/sitemap_index.xmland its rendering in Chromium 141, captured 12 October 2026.
The only percentages in this article are Google’s own platform counters, which are published without a sample size or a sampling method, and that is stated where they appear. No other source here is a study.