Domina XPath: guía interactiva de navegación XML

XPath sigue teniendo una reputación extraña en tecnología: para algunos es una joya imprescindible; para otros, una reliquia del mundo XML. Las dos visiones se quedan cortas. XPath no es “viejo” por definición ni “moderno” por marketing: es un lenguaje especializado para navegar y consultar estructuras jerárquicas, y sigue siendo muy relevante cuando trabajas con XML, XSLT, automatización, documentos con namespaces, SVG, sitemaps o APIs y herramientas que todavía dependen del ecosistema XML. Además, en la plataforma web actual siguen existiendo APIs nativas como Document.evaluate() y XPathResult, disponibles ampliamente en navegadores desde hace años.

Lo importante en 2026 no es repetir que XPath “sirve para seleccionar nodos”, sino entender dónde aporta más que CSS o búsquedas simples, y dónde conviene no usarlo. En automatización moderna, por ejemplo, Selenium sigue soportando xpath como estrategia oficial de localización, mientras que Playwright lo soporta pero recomienda priorizar locators más resilientes como role, text o test id. Además, las herramientas de QA con IA están empezando a generar selectores XPath autocurativos (self-healing) que reducen la fragilidad de las pruebas.

Qué es XPath, explicado sin humo

XPath significa XML Path Language. El propio W3C lo define como un lenguaje de expresiones que permite procesar valores conformes al modelo de datos XDM y cuyo rasgo más distintivo es la path expression, es decir, una forma de direccionamiento jerárquico sobre nodos de un árbol XML. XPath 3.1 no se limita a “árboles XML simples”: el modelo también incluye valores atómicos, secuencias, function items y estructuras añadidas en 3.1 como maps y arrays.

Dicho de forma práctica: XPath te permite moverte por un documento como si fuera un árbol y responder preguntas del tipo “dame todos los productos con precio mayor a X”, “encuéntrame el segundo nodo de este tipo”, “sube al padre”, “busca un hermano anterior”, “filtra por atributo”, “trabaja con namespaces” o “evalúa una condición textual”. Ahí es donde XPath suele ganar potencia frente a enfoques más simples. MDN, de hecho, mantiene una guía específica comparando CSS Selectors y XPath para ayudar a elegir la herramienta correcta según el tipo de consulta.

Por qué XPath sigue siendo importante en 2026

La primera razón es simple: el estándar sigue vigente. No hay una Recommendation posterior a XPath 3.1 en el historial del W3C, así que sigue siendo el punto de referencia normativo actual. Además, XPath no vive aislado: forma parte del ecosistema XQuery/XDM y sigue conectado al mundo de transformación y consulta XML más serio.

La segunda razón es que los navegadores siguen exponiendo XPath. MDN documenta Document.evaluate() como una API ampliamente disponible y usable tanto sobre documentos HTML como XML. Al mismo tiempo, el DOM Standard aclara un matiz importante: las APIs heredadas de DOM Level 3 XPath para evaluar expresiones son APIs de XPath 1.0, ampliamente implementadas, pero que no han recibido mantenimiento activo. Ese detalle importa mucho porque evita confundir el estándar general XPath 3.1 con lo que el navegador expone por DOM.

La tercera razón es que XML no ha desaparecido. El protocolo de Sitemaps sigue definiéndose en formato XML; SVG sigue siendo un lenguaje de marcado basado en XML; y la propia web platform sigue incluyendo DOMParser y XMLSerializer para parsear y serializar XML en el navegador. No estamos en 2008, pero tampoco en un mundo donde XML haya dejado de existir.

La cuarta razón es el tooling. Java sigue incluyendo javax.xml.xpath en su stack estándar, con APIs para evaluar expresiones y trabajar con resultados tipados; y Python mantiene soporte XPath en xml.etree.ElementTree, aunque su propia documentación deja claro que ese soporte es limitado y sólo cubre un subconjunto abreviado, no un motor XPath completo. Eso significa que XPath sigue muy vivo, pero también que no todas las implementaciones ofrecen la misma profundidad.

El error más común: pensar que XPath sólo sirve para “buscar etiquetas”

Ese enfoque reduce muchísimo el lenguaje. XPath no es simplemente una alternativa a getElementsByTagName(). Su valor real aparece cuando necesitas relaciones estructurales y filtros expresivos: padres, ancestros, hermanos, posiciones, atributos, contenido textual, funciones y namespaces. MDN enumera ejes y funciones XPath, y su comparación con CSS muestra precisamente que XPath sigue siendo interesante cuando necesitas navegación estructural más rica.

Modelo mental correcto: piensa en árbol, no en texto

XPath funciona mejor cuando dejas de ver XML como “texto con tags” y lo ves como un árbol de nodos. La documentación de Python sobre ElementTree lo explica muy bien: XML es un formato inherentemente jerárquico y la forma natural de representarlo es un árbol. Una vez tienes ese modelo en la cabeza, expresiones como //book, ../title, @id o [2] dejan de parecer sintaxis rara y pasan a ser navegación entre relaciones del árbol.

Mini laboratorio interactivo: entiende XPath con un XML real

Vamos a usar un XML sencillo:

<library>
  <book id="b1" category="testing">
    <title>Playwright in Action</title>
    <author>Nestor Alonso</author>
    <price>39.99</price>
  </book>
  <book id="b2" category="automation">
    <title>Cypress from Zero to Hero</title>
    <author>Ana Ruiz</author>
    <price>29.99</price>
  </book>
  <book id="b3" category="xml">
    <title>Mastering XPath</title>
    <author>Carlos Vega</author>
    <price>49.99</price>
  </book>
</library>

Ahora, piensa en estas expresiones.

1. Todos los libros

/library/book

Esto selecciona todos los nodos book hijos de library. Es la forma más directa de navegar por ruta absoluta. La documentación de Python muestra este tipo de paths simples como parte del subconjunto XPath que soporta ElementTree, y MDN documenta el mismo tipo de navegación en las APIs de evaluación XPath del navegador.

2. Todos los títulos, sin importar dónde estén

//title

El // indica búsqueda descendente a cualquier nivel. En la práctica es muy cómodo, pero también es una de las causas más comunes de expresiones demasiado abiertas y poco mantenibles cuando se abusa de él. Python documenta // como selección de subelementos en todos los niveles bajo el nodo actual.

3. El libro con id="b2"

//book[@id='b2']

Aquí aparece uno de los patrones más usados: filtrar por atributo con un predicado. Python lo documenta dentro de su sintaxis soportada, y es uno de los motivos por los que XPath sigue siendo tan expresivo incluso en implementaciones recortadas.

4. El segundo libro

/library/book[2]

Los predicados posicionales son otra ventaja clásica de XPath. ElementTree documenta expresamente que position puede ser un entero, last() o una posición relativa a last().

5. El último libro

/library/book[last()]

Este tipo de consulta es muy natural en XPath y mucho menos elegante en otros enfoques. Es una de esas pequeñas cosas que explican por qué XPath sigue siendo tan apreciado en navegación estructural.

6. El título del libro de categoría XML

//book[@category='xml']/title

Aquí combinas filtro por atributo y navegación descendente. XPath se vuelve especialmente potente cuando encadenas pasos simples de árbol en lugar de intentar construir expresiones gigantescas. Esa forma de pensar encaja con la idea de path expression del W3C.

7. Todos los libros cuyo título contenga “XPath”

//book[contains(title, 'XPath')]

Funciones como contains() convierten XPath en algo bastante más expresivo que una ruta rígida. MDN mantiene referencia de las funciones XPath y documenta contains, starts-with, position, last, count y otras muy usadas.

8. El author hermano del title actual

//title/following-sibling::author

Aquí aparece uno de los superpoderes de XPath: los axes. La navegación por hermanos, padres o ancestros es una de las áreas donde XPath suele aportar mucho más que un selector CSS simple, aunque CSS moderno haya reducido parte de esa diferencia en algunos escenarios. MDN compara precisamente ejes de XPath con equivalentes o aproximaciones CSS cuando existen.

Cómo usar XPath en JavaScript del navegador

En navegador, la API clave es document.evaluate(xpathExpression, contextNode, namespaceResolver, resultType, result). MDN documenta que esta API evalúa expresiones XPath sobre documentos HTML o XML y devuelve un XPathResult. También explica que namespaceResolver se usa para resolver prefijos y que resultType controla si quieres número, string, booleano, iterador, snapshot o un solo nodo.

Ejemplo práctico:

const result = document.evaluate(
  "//book[@category='xml']/title",
  document,
  null,
  XPathResult.FIRST_ORDERED_NODE_TYPE,
  null
)

console.log(result.singleNodeValue?.textContent)

Si vas a evaluar la misma expresión muchas veces, MDN también documenta XPathEvaluator.createExpression(), que compila la expresión en un XPathExpression reutilizable. Eso tiene sentido cuando la consulta se repite muchas veces en un mismo flujo.

Otro matiz importante es el tipo de resultado. MDN explica que los resultados iteradores pueden invalidarse si el documento cambia, mientras que los snapshot no se invalidan, aunque pueden dejar de reflejar el estado actual del documento si éste muta. Esa diferencia importa mucho en debugging y en scripts más dinámicos.

Namespaces: donde XPath deja de ser trivial

Muchos desarrolladores dicen que “XPath es difícil” cuando en realidad lo que les está complicando la vida son los namespaces. En XML real, los prefijos importan, y en la web platform Document.evaluate() necesita un namespaceResolver cuando la expresión usa prefijos. MDN lo documenta explícitamente.

En Python, la documentación de ElementTree recomienda crear un diccionario de prefijos propios y usarlo en búsquedas como find() o findall(). También muestra la alternativa menos legible de escribir directamente {namespace}tag. Ese consejo es oro para cualquier artículo serio sobre XPath, porque los namespaces son uno de los motivos más frecuentes de consultas “correctas” que no devuelven nada.

XPath en Python: útil, pero con una advertencia importante

La librería estándar xml.etree.ElementTree es muy práctica para muchos flujos XML, pero su propia documentación aclara que ofrece soporte limitado para expresiones XPath y que un motor XPath completo queda fuera de su alcance. Soporta un subconjunto bastante útil —paths, //, filtros por atributo, textos, posiciones, last() y namespaces—, pero no debes asumir compatibilidad plena con XPath 3.1.

Eso no es una debilidad accidental; es una decisión de diseño. Para tareas normales de parsing y selección, ese subconjunto suele bastar. Para consultas complejas, transformaciones serias o escenarios con mucha semántica XPath, conviene usar tooling más especializado.

XPath en Java: sigue siendo parte del stack serio

Java sigue trayendo javax.xml.xpath como API estándar en java.xml. Oracle documenta este paquete como una API neutral respecto al modelo de objetos para evaluar expresiones XPath y acceder al entorno de evaluación. También documenta interfaces y clases como XPath, XPathExpression, XPathEvaluationResult y XPathNodes. Eso confirma que XPath no es una curiosidad legacy: sigue integrado en uno de los ecosistemas empresariales más usados.

XPath en automatización web: sigue vivo, pero con más criterio

En Selenium, XPath sigue siendo una estrategia oficial de localización. La documentación actual de Selenium mantiene xpath dentro de sus locator strategies, así que sigue siendo parte normal del trabajo E2E y de WebDriver.

Pero el matiz moderno viene de herramientas como Playwright. Playwright soporta CSS y XPath, detecta XPath automáticamente cuando el selector empieza por // o .., pero sus best practices recomiendan priorizar locators de role, text y test id para conseguir tests más resilientes. Además, Playwright advierte que XPath no atraviesa shadow roots. Esta combinación es exactamente la que conviene explicar en 2026: XPath no está muerto, pero tampoco debería ser tu primera opción indiscriminada para testing de UI HTML moderna.

XPath vs CSS en 2026: cuál usar y cuándo

Para HTML moderno y testing de interfaz, CSS o locators semánticos suelen ser una mejor opción cuando la intención está orientada al usuario o a la estructura visual. MDN mantiene una guía comparando CSS y XPath precisamente para ayudar a elegir según el problema.

XPath suele ganar cuando necesitas subir en el árbol, navegar por ejes como ancestros o hermanos, aplicar filtros posicionales complejos, resolver namespaces o trabajar con documentos XML donde CSS simplemente no es el lenguaje natural del problema. CSS suele ganar cuando trabajas con HTML de frontends modernos, especialmente si el objetivo es escribir selectores más simples o alineados con estrategias de test más mantenibles. Playwright refuerza esa línea al priorizar role/text/test id sobre CSS o XPath en sus recomendaciones.

Buenas prácticas para usar XPath bien

La primera es no abusar de rutas absolutas gigantes como /html/body/div[3]/main/.... Funcionan hasta que el DOM cambia un poco. XPath es más potente cuando expresa intención estructural, no cuando memoriza la forma exacta del árbol. La documentación de Selenium incluso incluye errores comunes como InvalidSelectorException cuando los selectores XPath o CSS están mal formados.

La segunda es controlar el contexto. En navegador, document.evaluate() recibe contextNode por una razón: muchas consultas son más claras, rápidas y seguras si se evalúan desde un nodo concreto y no desde todo el documento. MDN lo documenta directamente en la firma del método.

La tercera es tratar los namespaces como parte del diseño, no como una rareza. Cuando aparecen, debes resolverlos correctamente en JavaScript o mapearlos bien en Python. Gran parte de los “XPath no funciona” son realmente “mi documento tiene namespaces y no los contemplé”.

La cuarta es entender qué implementación tienes delante. No es lo mismo hablar de XPath 3.1 como Recommendation del W3C que hablar de las APIs XPath 1.0 del DOM del navegador, ni de la implementación limitada de ElementTree en Python. En este tema, el contexto del motor importa tanto como la sintaxis.

Conclusión

XPath sigue siendo importante en 2026 porque resuelve un problema que sigue existiendo: navegar estructuras jerárquicas con precisión. Sigue vigente como estándar W3C, sigue expuesto por los navegadores, sigue integrado en Java, sigue presente en Python aunque sea con soporte parcial, y sigue siendo relevante en automatización y en documentos XML reales como sitemaps o SVG.

Lo que sí ha cambiado es la forma madura de usarlo. En 2026, dominar XPath no significa meterlo en todas partes; significa saber cuándo te da una ventaja real, cuándo un selector CSS o un locator semántico es mejor, y cómo manejar bien contextos, predicados, posiciones y namespaces. Ahí está la diferencia entre conocer sintaxis y dominar de verdad la herramienta. Si quieres llevar tu automatización de API y UI al siguiente nivel y diseñar estrategias de testing mantenibles, no dudes en contactarme.