Skip to main content

Technical insight · XML sitemaps, Search engine optimisation, Web standards

A readable XML sitemap without XSLT, before Chrome removes it

Chrome removes XSLT from stable releases in version 158 (17 November 2026), and with it the usual way of making an XML sitemap readable in a browser. CSS on XML is not being removed. This is how our sitemap uses a plain CSS stylesheet instead, and what that approach cannot do.

By PrajnaBytesPublished 4 min read

The problem

An XML sitemap is written for search engines. It lists the pages of a website in the format defined at sitemaps.org, and crawlers read it as data. People open it too, though: site owners checking that a page is listed, developers, auditors. Shown raw, it is a wall of tags.

For years the usual way to make a sitemap readable was an XSLT stylesheet, declared at the top of the file:

<?xml-stylesheet type="text/xsl" href="/sitemap.xsl"?>

The browser transforms the XML into an HTML page. Many sitemap plugins still ship this way.

That route is closing. Chrome's developer documentation (published 29 October 2025) announces that Chromium has deprecated XSLT, both the XSLTProcessor API and the XSLT processing instruction, and gives a removal schedule: XSLT stops working in stable Chrome 158, dated 17 November 2026, apart from origin-trial and enterprise-policy exceptions that end with Chrome 176. The same document notes that the Firefox and WebKit projects have indicated plans to remove XSLT as well, and that Chrome shows a warning banner when it meets XSLT that it no longer runs.

The approach

The same document points out what is not being removed: the <?xml-stylesheet?> processing instruction with type="text/css". A CSS stylesheet can lay out raw XML elements directly, as it can HTML. So the PrajnaBytes sitemap uses plain CSS:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="/sitemap.css?v=…"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url><loc>https://prajnabytes.com/</loc></url>
  …
</urlset>

We tried an XSLT version first. It worked, and was removed the same day once the deprecation warning appeared. The CSS version has replaced it since (decision DEC-067 in our records).

How it works

Every element in the sitemap can be selected and styled like an HTML element:

  • urlset becomes the page: display: block, a background and a coloured top border.
  • urlset::before draws the header. Generated content (content: "…") carries the company name as an ASCII banner, with white-space: pre to keep its line breaks, and a background places the emblem.
  • Each url becomes a card. A CSS counter (counter-increment: page) numbers the cards, and url::before shows the number in a coloured badge that cycles through the brand colours with :nth-of-type(5n+…).
  • loc is set in a strong weight, with word-break: break-all so long addresses wrap on phones.
  • A prefers-color-scheme: dark query provides a dark version.

Three practical details:

  1. A static file. The site's Content Security Policy does not allow inline styles, so the CSS lives in public/sitemap.css, not inside the XML.
  2. Cache busting. The stylesheet address carries a short hash of the file (?v=…), computed when the sitemap is generated, so a changed design is never hidden behind a cached copy.
  3. Nothing changes for crawlers. Search engines read the urlset as before; the processing instruction is ignored by them.

We also stopped the sitemap from drifting out of date. An automated test walks every public page route of the application and fails if one is missing from the sitemap, unless the page is deliberately excluded (sign-in, private areas, pages disallowed in robots.txt).

We checked the result in the Chromium, Firefox and WebKit engines (the browser builds used by our automated browser tests) on 5 November 2026: all three apply the stylesheet.

Trade-offs

  • No links. CSS can style text but cannot turn an XML element into a hyperlink, so the addresses in the human view are not clickable. XSLT could produce real links. For a page that people mostly read, we accepted this.
  • No transformation. CSS cannot sort, group or filter entries. What you see is the document order. Group related pages when you generate the file if order matters.
  • Generated content is decorative. Text added with ::before is not part of the data. Keep anything important in the XML itself.
  • Large sitemaps. CSS renders every entry. A sitemap with tens of thousands of URLs will be long; split it with a sitemap index, as the protocol recommends.

If your sitemap, RSS feed or other XML relies on an XSLT stylesheet for its human view, check it before Chrome 158 reaches your users. For a readable listing, CSS is often enough.

Sitemaps and site health are part of looking after a website (Technology Operations) and of making it findable (Digital Marketing and Digital Business Services).

  • Technology Operations

    Hosting, domains, certificates, maintenance, monitoring, backup and security support, so that business systems stay available and maintained.

  • Digital Marketing and Digital Business Services

    Search, social media, email and paid campaigns run as a measured part of the business, connected to the website and systems behind it.

Request a technical consultation

Not sure whether your website, feeds or sitemaps depend on XSLT? Ask us to check.

Reading is free and needs no details. We only ask for contact details if you decide to write to us.

About this publication

How it was produced. Drafted with AI assistance from our engineering records (decision DEC-067, the sitemap code and its tests), then edited.

Review. Checked on 5 November 2026 against the live sitemap, its source code and automated test, and the Chrome documentation cited below.

References

  1. Removing XSLT for a more secure browser. Chrome for Developers. Published 29 October 2025; accessed 5 November 2026.
  2. Sitemaps protocol. sitemaps.org. Accessed 5 November 2026.
  3. Associating Style Sheets with XML documents 1.0 (Second Edition). W3C Recommendation. Accessed 5 November 2026.
  4. Build and submit a sitemap. Google Search Central. Accessed 5 November 2026.

About the same service

Technical insightInternal implementation4 min read

A strict Content Security Policy for a React website, without inline styles

How the PrajnaBytes website runs a Content Security Policy with no 'unsafe-inline' for scripts or styles, while still using React, UI libraries and dynamic effects: stylesheet classes, one per-request nonce, CSS custom properties set through the CSSOM, and self-hosted assets.

  • Content Security Policy
  • Web security
  • React

About the same service

Case studyIndependent research17 min read

AIIMS Delhi Website Ad Injection: A Historical Third-Party JavaScript Case Study

In December 2022 a visitor-counter script on the official AIIMS Delhi website was found to be placing third-party advertising at the top of the page. This case study reconstructs what happened from the original report and from archived copies of the script, separates verified facts from interpretation, and sets out what the episode teaches about third-party JavaScript.

  • Third-party JavaScript
  • Web security
  • Supply-chain risk
  • Content Security Policy