--- title: "Feeds, sitemap y una cabecera que sobra: pequeña auditoría de un sitio WordPress con curl" description: "Valencia, 08/09/2026, G.B. Hay comandos que uno lanza casi por rutina y que, sin embargo, acaban destapando cosas interesantes. La semana pasada me tocó revisar el sitemap nativo de uno de mis sitios..." url: https://indaga.net/feeds-sitemap-y-una-cabecera-que-sobra-pequena-auditoria-de-un-sitio-wordpress-con-curl/ date: 2026-09-07 modified: 2026-09-04 author: "Directorio Indaga" image: https://indaga.net/wp-content/uploads/2026/09/curl.jpg categories: ["GNU Linux", "Recursos y Utilidades", "WordPress"] tags: ["blog", "curl", "feeds wordpress", "php.ini", "sitemaps wordpress", "wordpress"] type: post lang: es --- # Feeds, sitemap y una cabecera que sobra: pequeña auditoría de un sitio WordPress con curl Valencia, 08/09/2026, G.B. Hay comandos que uno lanza casi por rutina y que, sin embargo, acaban destapando cosas interesantes. La semana pasada me tocó revisar el sitemap nativo de uno de mis sitios en WordPress y, de paso, aproveché para repasar algo que tenía pendiente desde hace tiempo: los feeds del sitio y una cabecera HTTP que no debería estar ahí. ## Qué es el feed de un sitio en WordPress El feed es una versión del contenido en XML —normalmente RSS 2.0, aunque WordPress también sabe hablar Atom— pensada para que lectores de noticias, agregadores o scripts consuman las entradas sin tener que «leer» el HTML de la página. Es una de esas piezas del núcleo de WordPress que llevan ahí desde siempre y que casi nadie mira hasta que algo deja de funcionar (a mí me pasó hace poco con un gadget de Blogger de terceros que dejó de refrescar entradas porque un `Disallow: */feed/` en el `robots.txt` se lo estaba impidiendo). Lo interesante es que WordPress no genera un único feed, sino uno por cada «vista» relevante del sitio: - **Feed general**, con todas las entradas: `/feed/` - **Feed de comentarios** de todo el sitio: `/comments/feed/` - **Feed de una categoría**: `/category/nombre-categoria/feed/` - **Feed de una etiqueta**: `/tag/nombre-etiqueta/feed/` - **Feed de un autor**: `/author/nombre-autor/feed/` - **Feed de comentarios de una entrada concreta**: `/nombre-entrada/feed/` - **Feed de una búsqueda**: `/?s=termino&feed=rss2` - **Feed de un tipo de contenido personalizado**, si el CPT lo soporta: `/tipo-contenido/feed/` Y todavía hay una capa más: dentro de cada uno de esos ámbitos, el formato de salida se puede forzar con el parámetro `?feed=`, con hasta cuatro variantes: `rss2` (el que usa WordPress por defecto), `rss` (RSS 0.92, un formato ya legado), `atom` y `rdf` (RSS 1.0). En total, contando ámbitos y formatos, un sitio WordPress típico expone bastantes más «puertas de entrada» XML de las que uno recuerda a primera vista. ## El sitemap no es un feed Conviene no confundir los feeds con el sitemap. Desde WordPress 5.5 (2020), el núcleo genera automáticamente un sitemap XML nativo en `/wp-sitemap.xml`, sin necesidad de plugins de SEO. No es RSS ni Atom: es un índice que agrupa entradas, páginas, taxonomías y usuarios en sub-sitemaps independientes (`wp-sitemap-posts-post-1.xml`, `wp-sitemap-users-1.xml`, etc.), pensado para que los buscadores rastreen el sitio de forma eficiente. Para comprobar rápidamente si el sitemap responde bien, sin descargarlo entero, uso el [comando curl](https://curl.se/docs/manpage.html): ```bash curl -I https://midominio.com/wp-sitemap.xml ``` El `-I` fuerza una petición `HEAD`: solo pide las cabeceras HTTP de la respuesta, no el cuerpo. Es la forma más rápida de saber si una URL existe, qué código de estado devuelve y qué tipo de contenido sirve, sin gastar ancho de banda en el XML completo. ## Lo que las cabeceras cuentan (y lo que delatan) Al lanzar ese `curl -I` contra uno de mis sitios, obtuve algo así (he sustituido la versión de PHP que aparecía por X.X.XX en el código que adjunto por motivos de seguridad): ``` HTTP/2 200 content-type: text/xml;charset=UTF-8 date: Fri, 04 Sep 2026 06:42:34 GMT server: Apache x-powered-by: PHP/X.X.XX ``` Todo correcto salvo un detalle: `x-powered-by: PHP/X.X.XX` está anunciando al mundo, con número de versión exacto, qué motor PHP corre detrás. No es una vulnerabilidad en sí misma, pero sí información gratuita para cualquiera que esté buscando qué CVEs probar contra esa versión concreta. Es el tipo de cabecera que no aporta nada al visitante legítimo y sí algo a quien está reconociendo el terreno. La buena noticia es que `server: Apache` ya venía sin número de versión, así que esa parte no hacía falta tocarla. ## Cómo quitar la cabecera con [php.ini](https://www.php.net/manual/en/configuration.file.php) Yo tengo creado el archivo `php.ini` (o `.user.ini`) propio en el directorio del sitio. El mío ya incluía algunos ajustes habituales: ```ini upload_max_filesize = 128M post_max_size = 128M max_execution_time = 300 memory_limit = 512M zlib.output_compression = 1 zlib.output_compression_level = 9 ``` Simplemente basta con añadir una línea más: ```ini expose_php = Off ``` Tras guardar el archivo -y en algunos casos esperar unos minutos a que el hosting recargue la configuración- un nuevo `curl -I` me ha confirmado que la cabecera `x-powered-by` había desaparecido. Un cambio de una sola línea, pero de esos que conviene no dejar pendientes. ## Resumiendo - Un sitio WordPress puede exponer más de media docena de feeds distintos, cada uno con hasta cuatro formatos posibles. - El sitemap nativo (`/wp-sitemap.xml`) es una pieza distinta, propia del núcleo desde la versión 5.5. - `curl -I` es la herramienta de cabecera rápida para auditar cualquier URL sin descargar su contenido. - Si tu hosting lo permite, `expose_php = Off` en tu `php.ini` o `.user.ini` es un cambio mínimo con un beneficio de seguridad nada despreciable.