Desde WordPress 5.5 existe funcionalidad nativa de XML sitemaps y, por defecto, WordPress incluye proveedores (providers) para distintos tipos de URLs, entre ellos “users” (usuarios/autores) además de posts y taxonomías.

A nivel de implementación, el provider de usuarios (WP_Sitemaps_Users) genera entradas cuyo loc apunta a la URL de archivo de autor (get_author_posts_url).
Además, el listado se construye únicamente con usuarios que tienen posts publicados (has_published_posts) en post types públicos (excluyendo page y attachment).

Traducción operativa: el sitemap puede “sugerir usuarios” porque, en realidad, está listando páginas públicas de autor, no porque WordPress esté intentando publicar credenciales.

📌 Guía completa: Seguridad WordPress (checklist + prioridades).

✅ Acción rápida: Iniciar auditoría gratis y recibir evidencias en minutos.

1) Cuándo hay exposición real (criterio práctico)

Aquí conviene separar “existe una URL pública de autor” de “esto crea un riesgo material”.

Caso A — Bajo riesgo (normal en blogs multi-autor)

  • El sitio publica autores de forma explícita (byline, página de autor, etc.).
  • El sitemap solo lista URLs públicas de autor coherentes con el contenido.

En este caso, el sitemap no “revela algo nuevo”: simplemente facilita el rastreo.

Caso B — Riesgo moderado por enumeración útil

Aunque el sitemap liste “solo URLs de autor”, puede facilitar:

  • enumeración de autores,
  • y reducción del coste de ataques de fuerza bruta cuando el login está expuesto y no hay rate limiting/2FA.

En WordPress Trac hubo un ticket que planteó precisamente la preocupación de que el sitemap de usuarios podría facilitar ataques al proporcionar una lista de usernames; el ticket se cerró como invalid, pero el debate ilustra el punto: la enumeración puede ser útil operacionalmente para un atacante.

Caso C — Riesgo alto (cuando no debería existir “autor público”)

  • Web corporativa con un único autor “técnico” o cuentas administrativas que han publicado contenido.
  • Sitio sin intención de exponer archivos de autor.
  • Entorno donde el login está expuesto y se han observado intentos automatizados.

En este escenario, suele ser razonable retirar la presencia de autores del sitemap y/o desactivar archivos de autor.

2) Cómo evaluarlo (pasos concretos, con evidencia)

  1. Comprobar si existe sitemap nativo y si incluye “users”
  • Revisar /<sitemap> (habitualmente wp-sitemap.xml) y localizar referencias a wp-sitemap-users-*.xml.
  1. Abrir el sitemap de usuarios y revisar qué URLs lista
  • Confirmar si los loc son URLs de autor (esto es lo esperable por diseño).
  1. Determinar si esos “autores” aportan valor SEO real
  • ¿Existe estrategia editorial multi-autor?
  • ¿Se enlazan páginas de autor desde el site?
  • ¿Google debería rastrearlas?
  1. Cruzar con postura de acceso y ataques observados
  • Si el panel/login está expuesto y hay fuerza bruta, enumerar autores empeora el escenario (por combinación de factores).

3) Mitigación sin romper el sitio (enfoque seguro)

Opción 1 — Desactivar el provider “users” del sitemap (recomendación cuando no se necesita)

WordPress documenta que podemos eliminar providers (por ejemplo, el de “users”) usando el filtro wp_sitemaps_add_provider.

Cuándo elegirla

  • Sitios corporativos o con un único autor.
  • Sitios sin valor en páginas de autor.
  • Sitios con presión de bots/fuerza bruta.

Impacto esperado

  • No rompe el frontend.
  • Reduce rastreo de páginas de autor vía sitemap (si aun existen, podrían seguir accesibles por otras rutas).

Opción 2 — Mantener “users” pero reducir alcance (solo autores que deben ser públicos)

El provider usa una query filtrable (wp_sitemaps_users_query_args).
Esto permite adaptar criterios sin eliminar completamente el sitemap de usuarios (por ejemplo, excluir ciertos roles o condiciones), cuando se justifique editorialmente.

Opción 3 — Desactivar archivos de autor (si no tienen sentido en el negocio)

Si no queremos páginas /author/... públicas, podemos desactivarlas. Existen enfoques por código o plugin; por ejemplo, un plugin específico lo describe como “desactivar completamente los archivos/páginas de autor” devolviendo 404.

Advertencia operativa: si el sitio es multi-autor o depende de páginas de autor por UX/SEO, esta opción debe evaluarse con cautela.

4) Checklist de cierre (criterios de aceptación)

Consideraremos la situación correctamente gestionada cuando:

  • Hemos decidido explícitamente si el sitio debe tener páginas de autor públicas.
  • Si NO deben existir, están desactivadas o devuelven 404.
  • Si NO necesitamos autores en sitemap, el provider “users” está deshabilitado mediante el mecanismo previsto por WordPress.
  • Si SÍ se necesitan, el sitemap de usuarios lista únicamente URLs de autor esperadas (por diseño usa get_author_posts_url y filtra por has_published_posts).
  • Se ha validado que no se afecta negativamente a SEO (Search Console) ni a navegación interna.