Your Sitemap Stops Rendering on 17 November. Here’s the 30-Second Check.
Here is our own XML sitemap, at freestyleinternet.co.uk/sitemap_index.xml, as it looks today:
XML Sitemap
Generated by Yoast SEO, this is an XML Sitemap, meant for consumption by search engines.
This XML Sitemap Index file contains 5 sitemaps.
Followed by a tidy table — Sitemap, Last Modified — listing our posts, pages, case studies, categories and authors. It looks like a page somebody designed, because it is.
On 17 November 2026, in Chrome, it stops looking like that. It becomes a wall of raw XML with a warning banner over the top. Ours included. We checked before writing this, which is rather the point.
This is going to generate a certain number of alarmed emails in late November, so it’s worth understanding now. The short version: your rankings are completely unaffected, Google does not care in the slightest, and the only thing that breaks is a page that humans occasionally look at. But there is a check worth running, and a decision worth making before somebody else makes it for you.
What is actually being removed
Chrome is removing XSLT — Extensible Stylesheet Language Transformations. It’s a 1999 technology for turning XML into something else, usually HTML for display.
Two specific things go:
- The
XSLTProcessorJavaScript API - The XSLT processing instruction —
<?xml-stylesheet type="text/xsl" href="..." ?>
This is not a Chrome-only decision. Both Firefox and WebKit, the engine behind Safari, have indicated they intend to remove XSLT as well.
What is not being removed: the <?xml-stylesheet ?> instruction itself, when used with CSS. type="text/css" continues to work exactly as it does today. Only type="text/xsl" is going. That distinction matters, and a lot of the coverage has blurred it.
The check
Check: Open your sitemap index in a browser — usually yourdomain.co.uk/sitemap_index.xml — then use View Source (Ctrl+U on Windows, Cmd+Option+U on a Mac). Look at the first three or four lines.
Why it matters: This tells you in about thirty seconds whether the November change affects you at all. Nothing else in this article matters if the answer is no.
Fail: You see a line containing type="text/xsl". On a Yoast site it will point at a file called main-sitemap.xsl. On Rank Math and most other SEO plugins it’ll be a similarly named file. This is the styling that goes away in November.
There’s a quicker version of the same test, if you’d rather not read source: if your sitemap currently shows you a heading and a table, it’s using XSLT and it’s affected. If it shows you raw angle brackets, it isn’t. That’s the whole check.
Pass: There’s no text/xsl anywhere in the first few lines. Either you’re using WordPress core’s built-in sitemap, or your sitemap was never styled in the first place. You have nothing to do.
Run the same check on your RSS feed while you’re there — usually yourdomain.co.uk/feed/. Styled feeds use exactly the same mechanism and hit exactly the same deadline.
The timeline
Google published this well over a year ago, and has been shipping console warnings since late 2025. From Chrome’s own deprecation documentation:
| Milestone | Date | What happens |
|---|---|---|
| Chrome 142 | 28 October 2025 | Early warning messages appear in the browser console |
| Chrome 143 | 2 December 2025 | Official deprecation — warnings in the console and in Lighthouse |
| Chrome 146 | 10 March 2026 | Enterprise policy goes live, so managed fleets can test early or defer |
| Chrome 152 | 25 August 2026 | Origin trial goes live, so individual sites can defer |
| Chrome 158 | 17 November 2026 | XSLT stops working in stable Chrome for everyone else |
| Chrome 176 | 17 August 2027 | The origin trial and enterprise policy stop working too. XSLT is gone for good |
One caveat on that table. Google published those version numbers before announcing that Chrome moves to a two-week release cycle from 8 September, so the milestone numbers may not line up exactly by the time we get there. The dates are what to plan against, not the version numbers.
Why Google is doing this
Two reasons, and both are reasonable.
The first is security. The library that does this work in Chromium is libxslt, a complex C codebase that has been around since roughly 2001. That kind of code is prone to memory-safety bugs — buffer overflows and the like, which can lead to arbitrary code execution. There is a documented history of high-severity vulnerabilities in it, and because client-side XSLT is now a niche feature, the library gets far less security attention than the parts of the browser everyone uses. It’s a real attack surface protecting a feature almost nobody needs.
The second is usage. By Google’s own measurement, roughly 0.02% of page loads use XSLT at all, and fewer than 0.001% use the XSLT processing instruction specifically. That is the number that decided this.
Chrome is separately replacing its XML parsing with a memory-safe Rust implementation — that started landing in Chrome 153 this month. XML itself is not going anywhere. Only XSLT is.
Your three options
Option one: do nothing.
Genuinely defensible, and probably the right answer for most business websites. After 17 November your sitemap renders as raw XML in Chrome. Search engines carry on reading it exactly as they always have, because they read the XML and have never once looked at the stylesheet. Your rankings do not move.
The cost is that if you or a client opens the sitemap, it looks broken. Chrome now displays a warning banner on affected pages pointing at a browser extension that restores the formatting, which softens the “is my site broken” moment somewhat, but not entirely.
Do this if nobody but you ever looks at your sitemap, and you know what you’re looking at.
Option two: wait for your plugin to handle it.
Probably the most sensible answer, and the one we’d expect most sites to land on by default. Yoast, Rank Math and the rest all know this deadline is coming. It is very likely they’ll simply stop emitting the stylesheet reference in a release before November, and the problem will resolve itself while you’re not looking. Keeping your plugins current is the whole of the work.
If you want it gone sooner, it can be filtered out in code — but be careful whose instructions you follow. There are blog posts circulating naming a Yoast filter called wpseo_stylesheet_url for this. That filter is not in Yoast’s published sitemap API documentation, and undocumented filters get renamed and removed without notice. If you want this done now, have a developer look at what your specific plugin version actually outputs rather than pasting a snippet from a search result into functions.php.
Option three: keep the styled view working.
There’s a WebAssembly polyfill that restores XSLT behaviour without using the browser’s native implementation. For an XML file, adding one line inside the root element loads it and transforms the document as before. Google’s own deprecation guide documents this approach and links to it.
Worth it if you genuinely use the styled sitemap — some publishers and larger sites do treat it as a navigational artefact — and not worth it otherwise. You’re adding a WASM dependency to keep a page pretty.
For RSS feeds specifically, Google recommends a fourth thing that’s better than any of these: stop linking to the raw feed from your pages at all. Use <link rel="alternate" type="application/rss+xml"> in your HTML <head> instead. Feed readers find it, humans never accidentally click through to a wall of XML, and the whole problem disappears. That’s the standard way to do it and has been for years.
How to read your own result
If your sitemap has no XSL reference: you’re done. Close the tab.
If it does, and nobody ever looks at it: do nothing, or remove the reference next time someone’s in there anyway. This is not worth a change request on its own.
If it does, and you or your team actually use the styled view: decide now whether that’s worth a polyfill, and do it before mid-November rather than in the week somebody notices. It is a fifteen-minute job scheduled, and a stressful one unscheduled.
If you run client sites: run the check across the portfolio in one pass this month, note which ones are affected, and send a one-paragraph heads-up before November. Almost none of them will need work. The value is entirely in not being surprised — and in being the person who mentioned it first.
The thing worth noticing
Your rankings will not move by a millimetre. Google reads the XML in your sitemap and has never looked at the stylesheet, because the stylesheet was never for Google. It was for you.
Which raises a more interesting question than the deadline itself. That styled sitemap page has been sitting on your site for years, generated automatically, styled carefully, and looked at by approximately nobody. It exists because a plugin author in about 2011 thought it would be helpful, and no one has revisited the decision since.
Most websites are carrying a surprising amount of this. Markup for search features that no longer exist. Scripts loading for a tool you stopped using in 2019. Fonts you don’t render, plugins doing nothing, a cookie banner blocking a consent flow that never worked. None of it is urgent, all of it is weight, and it only ever gets found when something forces a look.
Chrome removing a 27-year-old technology is a small, boring deadline. It’s also a decent excuse to go and see what else is in there.
Want a proper look?
If you’d like someone to run this check — and the fifty others like it — across your site and tell you plainly what matters and what doesn’t, that’s the Technical Business Benchmark. It shows you what’s working, what’s holding you back, and the quickest ways to get ahead. £750 + VAT, credited in full against any work you commission afterwards.
If you’d rather this sort of thing was simply handled every month without you having to think about it, that’s Supercharge Your Site — or, for the maintenance layer on its own, our WordPress Care Plans start at £80 + VAT per month.
Schedule a call and we’ll tell you which one you actually need.