El 17 de noviembre de 2026, Chrome 158 llega a la versión estable y el XSLT de cliente deja de funcionar. Microsoft Edge usa el mismo motor. Si algún archivo de tu web lleva una instrucción <?xml-stylesheet?> —y si tienes WordPress con casi cualquier plugin de SEO, alguno la lleva— la página que abre una persona en el navegador cambiará ese día.
Esta web está en ese grupo. Comprobado el 12 de octubre de 2026, doctor-seo.net/sitemap_index.xml incluye <?xml-stylesheet type='text/xsl' href='//doctor-seo.net/wp-content/plugins/wordpress-seo/css/main-sitemap.xsl'?>, así que la tabla amable que ve hoy un visitante la produce XSLT y dejará de producirse después de Chrome 158.
El resumen honesto es que esto importa bastante menos para el posicionamiento de lo que sugieren los titulares, y bastante más para las personas que leen XML. El rastreo no se toca. Lo que cambia es la cara legible de todos los archivos XML que publicas.
Qué es XSLT exactamente
XSLT —Extensible Stylesheet Language Transformations— es un lenguaje para convertir un documento XML en otro documento. Le das un archivo XML y una hoja de reglas de plantilla, y produce HTML, texto u otro XML distinto. XSLT 1.0 se convirtió en recomendación del W3C en 1999, y 1.0 es la versión que implementan los navegadores; las posteriores, 2.0 y 3.0, viven fuera del navegador.
Dentro del navegador funciona mediante una instrucción de proceso al principio del archivo XML: <?xml-stylesheet type='text/xsl' href='estilo.xsl'?>. Cuando el navegador carga el XML y encuentra esa línea, descarga la hoja de estilo, ejecuta la transformación en el propio navegador y muestra el resultado en lugar del XML. Existe además una vía por script, XSLTProcessor, que hace lo mismo desde JavaScript.
La propiedad importante, y la que casi toda la cobertura se salta, es que esto es un paso de representación y nada más. El XML que viaja por la red no cambia. Todo lo que analiza el archivo en vez de mostrarlo —un rastreador, un lector de feeds, un script— nunca llega a ejecutar la hoja de estilo. XSLT es una capa cosmética sobre datos legibles por máquinas, y justo por eso su retirada es muy visible y, para el posicionamiento, muy menor.
Qué publicó Google, y cuándo
Google expuso el plan en Removing XSLT for a more secure browser, en el sitio para desarrolladores de Chrome, firmado por Mason Freed y Dominik Röttsches y actualizado el 29-10-2025. El razonamiento es de seguridad. El documento dice que mantener XSLT 1.0 en los navegadores «presenta un riesgo de seguridad significativo e innecesario», describe las bibliotecas subyacentes como «bases de código C/C++ complejas y envejecidas» que «reciben mucho menos mantenimiento y escrutinio de seguridad que los motores de JavaScript principales», cita las vulnerabilidades CVE-2025-7425 y CVE-2022-22834 en libxslt, y concluye que el riesgo «supera con creces su limitada utilidad moderna». Las traducciones de las citas son nuestras.
La cifra de uso que sostiene ese juicio es del propio Google: la misma página afirma que «solo alrededor del 0,02% de las cargas de página usan hoy XSLT», y que menos del 0,001% usa instrucciones de proceso XSLT. Google no publica el muestreo que hay detrás de esos contadores, así que son telemetría de plataforma y no un estudio independiente, y no se indica ningún tamaño de muestra.
Hay dos vías de escape y las dos tienen fecha de caducidad. Una política de empresa, XSLTEnabled, llegó con Chrome 146; una prueba de origen se abrió en Chrome 152. Chrome Platform Status registra el hito de retirada en la 158 y la ventana de la prueba de origen entre la 152 y la 175, y las dos vías se cierran en Chrome 176, el 17 de agosto de 2027. Chromium Dash, leído en directo el 12 de octubre de 2026, da a Chrome 158 una fecha estable de 2026-11-17 y un corte de rama el 2026-10-26. La versión estable de hoy es Chrome 156.
Esto no es solo cosa de Chrome
La página de cambios con impacto en sitios de Microsoft para Edge dice que el soporte de XSLT «representa una superficie de ataque desproporcionada» y que Edge seguirá a Chromium. Documenta una política de característica XSLTEnabled en Edge 147 y pide a las organizaciones que prueben con ella desactivada. Edge 147 ya eliminó un caso más estrecho: usar XSLT para transformar XML en SVG. La obsolescencia principal, en cambio, figura como «versión futura, por determinar». Microsoft no ha publicado ninguna fecha.
Los demás motores tampoco van a resistir. Chrome Platform Status registra como positivas las posturas de Gecko y de WebKit sobre la retirada, y como negativa la de los desarrolladores web. En el registro de posturas de Mozilla, Simon Pieters escribió el 27 de agosto de 2025 que «sería bueno para la salud a largo plazo de la plataforma web y bueno para la seguridad del usuario retirar XSLT». Así que la dirección la marcan todos los motores importantes, y la disidencia viene de quienes usan la función, no de quienes la mantienen.
Qué aspecto va a tener
La página de Google describe un aviso pero no enseña el resultado, así que lo produjimos nosotros. El 12 de octubre de 2026 renderizamos el índice de sitemaps de esta misma web dos veces en Chromium 141: una con normalidad y otra lanzando el navegador con --disable-blink-features=XSLT, que es el mismo interruptor que acciona la retirada. Con XSLT, la hoja de estilo de Yoast produce una página con título y una tabla de dos columnas con los sitemaps y sus fechas de modificación. Sin XSLT, el navegador imprime un aviso que dice «This document cannot be formatted as intended. It uses XSLT, which the browser does not support» —este documento no puede formatearse como estaba previsto, usa XSLT y el navegador no lo admite— y debajo el árbol XML en crudo, instrucción de proceso incluida.
Qué se rompe y qué no
Cuatro usos concentran casi todo el XSLT de cliente que hay en la web abierta, y no fallan por igual. Una hoja de estilo en un sitemap o en un feed pierde su aspecto y nada más. Una página pública de datos XML —un registro, la lista de códigos de un organismo, los datos de una estación meteorológica— pierde la única forma en la que una persona podía leerla. Y donde XSLT hace trabajo dentro de una aplicación, la función deja de ejecutarse, no solo de verse bien.
Para el posicionamiento en concreto, la respuesta honesta es que no pasa nada. Los rastreadores descargan y analizan el XML; no ejecutan una hoja de estilo. La documentación de Google lo respalda por omisión: Build and submit a sitemap, actualizada el 8-7-2026, no contiene «XSLT», ni «stylesheet», ni «xml-stylesheet», ni «browser» en ningún punto de su cuerpo, y describe el mecanismo en términos puros de descarga y análisis: «Google intentará rastrear tus URL exactamente como aparecen», y enviar un sitemap «es solo una pista». Una hoja de estilo nunca se dirigió a un buscador. Se dirigía a ti, y a quien le pases la URL.
Esa es la parte que conviene tener a mano cuando un cliente reenvía la captura del aviso en pánico. No se ha desindexado nada. El archivo sigue validando, sigue listando las mismas URL y el camino del rastreo a la indexación es idéntico. Lo que ha cambiado es que ahora el archivo parece lo que siempre fue.
Qué hacer esta semana
- Si prefieres no hacerlo a mano, usa nuestro comprobador de XSLT. Pega tu dominio y te dice, archivo por archivo, cuáles dependen de XSLT y qué verá una persona desde el 17 de noviembre.
- Averigua si publicas alguna.
curl -s https://ejemplo.com/sitemap_index.xml | grep xml-stylesheetlo resuelve en una línea. Repítelo con tu feed y con cualquier endpoint XML que publiques. - Abre hoy la consola del navegador en esas URL con Chrome. Los avisos de obsolescencia se imprimen desde Chrome 143, así que la consola es un inventario gratis de todos los archivos XSLT que carga tu propia web.
- Decide archivo por archivo entre dejarlo y sustituirlo. Dejar la hoja de estilo es inofensivo: después de Chrome 158 la instrucción simplemente se ignora. Sustituirla significa o transformar en el servidor y servir HTML, o publicar una página HTML normal que enlace el XML.
- En los sitemaps del núcleo de WordPress el interruptor ya existe. El filtro
wp_sitemaps_stylesheet_url, en el núcleo desde la 5.5.0, muestra el XML en crudo sin hoja de estilo cuando devuelve un valor falso: útil para ver el estado posterior a la retirada antes de noviembre. - Para RSS y Atom, haz lo que recomienda Google. Pon
<link rel='alternate' type='application/rss+xml'>en tus páginas HTML para que lectores y clientes de feeds descubran el feed sin mirar nunca el archivo en bruto. - Si XSLT sostiene una aplicación, empieza ahora y no en noviembre. Las vías documentadas son transformar en el servidor, pasar el endpoint a JSON, o una biblioteca de cliente: Google menciona la implementación en JavaScript de Saxonica y un polyfill en WebAssembly. La política de empresa y la prueba de origen dan margen hasta el 17 de agosto de 2027 y ni un día más.
- No reescribas tu estrategia de sitemaps. No hay ningún cambio de rastreo que optimizar, y un sitemap que valida hoy valida también el 18 de noviembre.
Donde el sector discrepa de verdad
¿Basta un contador de uso de un navegador para retirar una función de la plataforma web? Un bando dice que sí y que la cuenta no está ni cerca: un 0,02% de las cargas de página no justifica un analizador en C sin mantenimiento dentro del programa más atacado del ordenador de casi cualquiera, todos los motores están de acuerdo, y una plataforma que nunca puede retirar nada acaba siendo imposible de asegurar. El otro bando dice que un contador de uso mide cargas de página y no consecuencias, que ese 0,02% se concentra justo donde la rotura cuesta más, y que la propuesta nunca se contrastó con la cola larga. La versión más fuerte de ese argumento es el hilo de WHATWG titulado «XSLT removal will break multiple government and regulatory sites across the world», que nombra entre otros a congress.gov, govinfo.gov, weather.gov, europarl.europa.eu, tga.gov.au y el Registro Europeo de Emisiones y Transferencias de Contaminantes, y sostiene que «la propuesta de retirar XSLT de la especificación no reconoce casos de uso existentes más allá de las estadísticas del contador de Chrome Status» y que «no hay ninguna investigación sobre la cola larga de sitios web, sobre cuántos exactamente se romperían».
Nadie puede zanjarlo con la evidencia publicada, porque ninguna de las partes ha publicado un recuento de sitios afectados. Google publicó un porcentaje de cargas de página; quienes se oponen publicaron una lista de ejemplos. Son unidades distintas y ninguna se convierte en la otra. Este artículo informa de la discrepancia y no la resuelve.
La opinión del autor — Txema Hermoso
Lo que defiendo es estrecho y reproducible: el XSLT del navegador es una capa de representación, la documentación de sitemaps de Google no lo menciona, y la captura de arriba enseña exactamente qué desaparece. Cualquiera puede repetir esa captura con un solo parámetro del navegador.
Lo que no voy a decir es que esto sea un evento de posicionamiento, porque no lo es, y tampoco voy a decir que el argumento de seguridad esté equivocado. No estoy en condiciones de pesar la superficie de ataque de un analizador sin mantenimiento frente a una lista de URL de organismos públicos, y nadie que esté publicando sobre esto lo está, porque el recuento que permitiría hacerlo no lo ha publicado nadie.
El único juicio que añado es sobre prioridades. Si gestionas webs, lo de XSLT es media hora de inventario y después una decisión que casi siempre se responde con «déjalo así». El coste de este cambio no cae sobre los equipos de SEO: cae sobre organismos públicos que publicaron datos legibles por máquinas y los hicieron legibles por personas de la forma más barata que ofrecía la plataforma. Esa asimetría es la noticia, y merece más atención que el aspecto de tu sitemap, que es también por lo que encaja en el nivel de SEO técnico como lección sobre depender de una representación que no controlas.
Qué sigue sin saberse
Si Edge publicará la retirada con el calendario de Chrome o con el suyo, porque Microsoft no ha dado fecha. Si Firefox y Safari seguirán, y cuándo: los dos motores han registrado una postura positiva y ninguno ha publicado un calendario. Cuántos sitios se rompen de verdad, que nadie ha contado. Si la prueba de origen se prorrogará más allá de Chrome 176. Y si algún fabricante de plugins publicará un sustituto para la vista del sitemap antes de noviembre, o dejará simplemente que la hoja de estilo quede inerte.
Fuentes
- Mason Freed y Dominik Röttsches, Google, Removing XSLT for a more secure browser, actualizada el 29-10-2025, leída el 12 de octubre de 2026 (dos veces).
- Chrome Platform Status, función 4709671889534976, XSLT, leída por su API pública el 12 de octubre de 2026: obsolescencia 143, retirada 158, prueba de origen 152–175, final 176; posturas de Gecko y WebKit positivas, la de los desarrolladores web negativa.
- Chromium Dash, calendario del hito Chrome 158, leído el 12 de octubre de 2026: fecha estable 2026-11-17, corte de rama 2026-10-26. Hito estable actual, 156.
- Microsoft, Site impacting changes in Microsoft Edge, leída el 12 de octubre de 2026. Obsolescencia como «versión futura, por determinar»; política
XSLTEnableden Edge 147. - Simon Pieters, mozilla/standards-positions, incidencia 1287, 27 de agosto de 2025.
- whatwg/html, incidencia 11582, «XSLT removal will break multiple government and regulatory sites across the world», leída el 12 de octubre de 2026.
- Google, Build and submit a sitemap, actualizada el 8-7-2026, leída el 12 de octubre de 2026.
- WordPress, wp_sitemaps_stylesheet_url, en el núcleo desde WordPress 5.5.0.
- Datos propios:
doctor-seo.net/sitemap_index.xmly su renderizado en Chromium 141, capturado el 12 de octubre de 2026.
Los únicos porcentajes de este artículo son contadores de plataforma del propio Google, publicados sin tamaño de muestra ni método de muestreo, y así se indica donde aparecen. Ninguna otra fuente citada es un estudio.