Chrome 158 deja los sitemaps con hoja XSL en XML sin formato

Chrome prevé dejar de aplicar XSLT con su versión 158, cuyo despliegue estable general está previsto para el 17 de noviembre de 2026, según su documentación para desarrolladores. Muchos sitemaps dependen de ello: la línea <?xml-stylesheet type="text/xsl" href="…"?> del principio del fichero es la que hace que una persona vea una tabla con enlaces en lugar de etiquetas. Desde ese día, quien abra uno de esos sitemaps en Chrome verá el XML en bruto. El cambio afecta a lo que ve una persona, no a las etiquetas que leen los buscadores (lo explicamos más abajo).

El aviso ya está en pantalla. Chrome estable pinta una banda roja en los XML que llevan hoja XSLT: «Este sitio usa XSLT, una función que se va a eliminar de este navegador muy pronto…».

Se retiran la instrucción xml-stylesheet con type="text/xsl" y la API XSLTProcessor de JavaScript. El XML se queda, y la misma instrucción con type="text/css" «sigue siendo compatible», en palabras de Chrome. El motivo es la seguridad: la biblioteca que hace las transformaciones, libxslt, es código C antiguo con vulnerabilidades graves recientes. Quien necesite más tiempo tiene dos prórrogas (último apartado de alternativas).

Si has leído «Chrome 155» en otro sitio, es la numeración anterior. La página de Chrome todavía decía 155 en marzo de 2026, según la Wayback Machine; hoy dice 158 y mantiene la fecha.

Firefox y Safari quieren quitarlo, pero no tienen fecha

Mozilla apoya la retirada, pero el bug para desactivar XSLT por defecto en Firefox sigue abierto y sin versión asignada a 2 de noviembre de 2026. En WebKit, el motor de Safari, el bug equivalente tampoco tiene fecha. Anne van Kesteren, que respondió por WebKit en el debate del estándar, avisó en agosto de 2025 de que probablemente esperarían a que otro navegador lo retirase del todo.

Los buscadores leen el XML; la hoja solo cambia lo que ve una persona

El protocolo de sitemaps define las etiquetas que leen los buscadores (urlset, url, loc, lastmod…) y no dice nada de hojas de estilo. La guía de Google para crear y enviar un sitemap, actualizada el 8 de julio de 2026, tampoco las menciona. Google no se ha pronunciado sobre la retirada de XSLT: no hemos encontrado nada en su documentación de sitemaps ni en las últimas entradas de su blog a 2 de noviembre de 2026.

Nuestra lectura es que cambiar o quitar la hoja no toca ninguna etiqueta del protocolo ni la URL del sitemap, así que no vemos motivo para esperar cambios en el rastreo ni para volver a enviarlo en Search Console. Yoast y el soporte de Rank Math lo explican igual. El problema es de quien abre el sitemap en el navegador: tú, tu cliente o el equipo que revisa qué se ha publicado.

Yoast prepara una hoja CSS para el 17 de noviembre

Yoast SEO, Rank Math, All in One SEO, SEOPress y los sitemaps propios de WordPress escriben hoy type="text/xsl". La redacción lo comprobó en el código de las versiones enlazadas en la tabla. Esto es lo que tienen previsto, a 2 de noviembre de 2026:

Si no quieres esperar, dos de ellos tienen un filtro para quitar o cambiar esa línea: rank_math/sitemap/{tipo}_stylesheet_url en Rank Math y aioseo_sitemap_show_credits en All in One SEO, que con false quita la hoja y también el comentario de créditos. En SEOPress la línea está escrita en la plantilla y no hemos visto un filtro solo para ella.

Nuestra lectura: quien use Yoast llegará a tiempo si la 28.9 sale cuando dice su changelog, el mismo día que Chrome 158. Si los otros tres no publican un cambio antes, sus sitemaps perderán ese formato en Chrome. Con los sitemaps nativos de WordPress puede ocurrir lo mismo hasta la 7.2, si se mantiene el calendario previsto.

Una hoja CSS mantiene la tabla, pero no los enlaces

Es la salida que ha elegido Yoast (issue #23663) y la más directa: cambiar type="text/xsl" por type="text/css" y apuntar a una hoja CSS servida como text/css y en UTF-8. CSS no transforma el XML, solo lo decora, pero da para bastante:

• @namespace, para dirigirse a los elementos del protocolo y a los de imágenes (image:) o noticias (news:);
• contadores, para numerar las filas y dar el total;
• ::before con content, para poner títulos y etiquetas que el XML no tiene;
• :has(), para que el título cambie según el contenido, por ejemplo «Sitemap de noticias» si hay news:news;
• prefers-color-scheme, para el modo oscuro.

CS · Sitemaps, el plugin de sitemaps para WordPress de Carlos Sánchez, director de este periódico, ya lo resuelve así. Desde su versión 1.5.0, la vista para personas usa una hoja CSS en lugar de la XSL, con filas numeradas, fechas, recuento al pie y modo claro y oscuro. Puede verse en el índice de sitemaps de sanchezdonate.net, que Chrome muestra con formato y sin la banda roja.

Un ejemplo mínimo. En el sitemap, la instrucción va justo después de la declaración XML:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="/sitemap.css"?>

Y /sitemap.css puede empezar así, para el índice y para cada sitemap:

@namespace url(http://www.sitemaps.org/schemas/sitemap/0.9);

urlset, sitemapindex {
  display: block; max-width: 70rem; margin: 2rem auto; padding: 0 1rem;
  font: 15px/1.5 system-ui, sans-serif; counter-reset: fila;
}
urlset::before, sitemapindex::before { display: block; font-size: 2rem; font-weight: 700; }
urlset::before { content: "Sitemap"; }
sitemapindex::before { content: "Índice de sitemaps"; }
url, sitemap {
  display: flex; gap: 1.5rem; padding: .5rem 0;
  border-bottom: 1px solid #ddd; counter-increment: fila;
}
url::before, sitemap::before { content: counter(fila); min-width: 3ch; color: #777; }
loc { flex: 1; overflow-wrap: anywhere; }
lastmod { font-family: monospace; color: #555; }
url > *|*:not(loc):not(lastmod) { display: none; }
urlset::after, sitemapindex::after { display: block; margin-top: 1rem; content: "Total: " counter(fila); }
@media (prefers-color-scheme: dark) { :root { background: #111; color: #ddd; } }

Los límites son los que reconoce Yoast en su issue y alguno más:

• Las URL no son enlaces pulsables. Los navegadores no admiten XLink en un XML genérico, solo en SVG y MathML, como recordó Paul Biron en la discusión de WordPress.
• En este ejemplo, el recuento se muestra al pie, después de recorrer las filas.
• Las fechas salen tal cual, en formato ISO.
• Las imágenes no se ven en miniatura; como mucho, su URL.
• La vista móvil puede quedar limitada: este XML no incorpora la configuración de viewport de una página HTML.

En nuestra opinión, es la mejor relación entre esfuerzo y resultado para la mayoría de sitios. Si nadie necesita pulsar las URL, no hace falta más.

Quitar la hoja, como hará WordPress 7.2

WordPress ha optado por no decorar nada. El cambio (ticket #65593, changeset 64073, fusionado el 3 de octubre de 2026) quita la instrucción xml-stylesheet de los sitemaps nativos, elimina las rutas /wp-sitemap.xsl y /wp-sitemap-index.xsl y deja obsoletos los filtros wp_sitemaps_stylesheet_*, cuyo resultado ya no se usa. Llega con WordPress 7.2, prevista para el 8 de diciembre de 2026.

A favor: no hay nada que mantener y el fichero lleva solo lo que pide el protocolo. En contra: Chrome enseña su vista de árbol, con un aviso de que el fichero no tiene información de estilo. A un SEO le basta; a un cliente le parecerá que algo se ha roto.

Weston Ruter señaló un caso límite en la misma discusión: si una caché sigue sirviendo el sitemap antiguo con la línea de la hoja, el navegador pide un /wp-sitemap.xsl que ya no existe, recibe la portada y Firefox muestra un error.

Una página HTML aparte recupera los enlaces

Si necesitas que las URL se puedan pulsar, la transformación tiene que hacerse antes de llegar al navegador: el servidor genera una versión HTML del sitemap y la sirve en otra URL. Es lo que proponía Paul Biron en el PR #12584 de WordPress (la misma dirección del sitemap terminada en .html), que se cerró sin fusionar cuando entró el cambio del apartado anterior. Yoast la deja en su issue como posibilidad futura, fuera de su cambio.

Si ya tienes una XSL, puedes aplicarla en el servidor. En PHP hace falta la extensión XSL, como explica su manual; comprueba que tu hosting la tiene. Si no, genera el HTML directamente con los mismos datos que el sitemap.

A favor: enlaces, recuentos, fechas legibles y un diseño que se adapta al móvil, en cualquier navegador y sin JavaScript. En contra: es otra URL que mantener, hay que decidir si se indexa, y el XML sigue viéndose en bruto si no le pones también una hoja CSS.

Creemos que, si vas a hacer una página así, conviene pensar en un mapa del sitio en HTML para personas más que en una copia del sitemap con otro formato. Ese mapa tiene valor propio para el enlazado interno y el rastreo, como explica Carlos Sánchez, director de este periódico, en su guía de sitemaps; conviene diseñarlo para que ayude a localizar las páginas importantes.

El polyfill conserva tu XSL a cambio de meter un script en el sitemap

El polyfill que propone Chrome es libxslt y libxml2 compilados a WebAssembly. Lo publica Mason Freed, coautor de la página de Chrome. Para que transforme un sitemap hay que añadir dentro del propio XML, como hijo del elemento raíz, una línea como esta:

<script src="/xslt-polyfill.min.js" xmlns="http://www.w3.org/1999/xhtml"></script>

Su documentación pone tres condiciones. La transformación automática solo actúa si el navegador ya no tiene XSLT nativo. La hoja se pide en modo mismo origen, así que una XSL alojada en otro dominio se bloquea aunque tenga CORS. Y el script tiene que servirse en UTF-8. En la medición que la redacción hizo de la versión 1.0.34, publicada el 29 de octubre de 2026, el archivo minificado ocupaba unos 1,4 MB y 525 KB con gzip.

La pega es de mantenimiento y de limpieza del fichero: cada sitemap lleva un elemento que no es del protocolo y que tú o tu plugin tenéis que mantener. El esquema de sitemaps.org solo admite elementos de otros espacios de nombres en sitios concretos, como antes del primer <url>, y Google no documenta cómo trata uno así dentro de un sitemap.

Nuestra lectura: el propio autor lo presenta en el README «solo como un parche provisional». Sirve para ganar tiempo si tu XSL hace algo que no puedes rehacer con CSS, no como solución definitiva.

Origin Trial, Enterprise Policy y la extensión solo dan tiempo

• Origin Trial. Registras tu dominio en el programa de Chrome y envías el token en la cabecera HTTP Origin-Trial, porque un XML no tiene <head> donde poner la etiqueta meta. Permite conservar temporalmente XSLT en Chrome mientras el sitio y el token cumplan las condiciones del programa.
• Enterprise Policy. La política XSLTEnabled solo afecta a los navegadores que gestiona una empresa. Sirve si tu equipo o el de un cliente depende de herramientas internas con XSLT.
• Extensión. XSLT Polyfill aplica el mismo polyfill en el navegador de quien la instala. Te sirve para seguir viendo con formato los sitemaps de clientes que aún no han cambiado; tus visitantes no la tendrán.

Las dos primeras dejan de funcionar con Chrome 176, el 17 de agosto de 2027. Para entonces hay que haber elegido una de las salidas anteriores.

Tres comprobaciones antes de Chrome 158

1. Abre tus sitemaps en Chrome, el índice y uno de cada tipo. Si ves la banda roja, usan XSLT. Mira también los feeds RSS con hoja XSL, a los que Chrome dedica un apartado propio en su documentación.
2. Actualiza el plugin cuando publique el cambio y mira el resultado en el navegador. Si usas Yoast News SEO, Video SEO o Local SEO, sus sitemaps seguirán con XSL hasta que cada complemento cambie. Después de actualizar, vacía la caché de los sitemaps para no caer en el caso que describe Weston Ruter.
3. Decide si necesitas enlaces pulsables. Si solo miran los sitemaps los SEO, basta con una hoja CSS o con ninguna. Si los usan clientes o redactores para navegar por el sitio, haz una página HTML. El polyfill y las prórrogas, solo para ganar tiempo.