En WordPress, una author archive es una página pública que agrupa las entradas publicadas por un autor, normalmente bajo una ruta del tipo /author/<slug>/.

A nivel técnico, WordPress genera y enlaza estas páginas mediante funciones como get_author_posts_url(), que devuelve la URL del archivo de autor para un usuario dado (incluyendo el nicename/slug del autor).
Esto aparece de forma natural en temas y plantillas: por ejemplo, funciones como get_the_author_posts_link() construyen enlaces a la author archive usando get_author_posts_url().

Traducción operativa: si el sitio muestra el nombre del autor en entradas, es habitual que exista un enlace a /author/... y que esa URL sea rastreable.

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

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

1) Dónde está el riesgo real: enumeración y “riesgo compuesto”

1.1 Qué entendemos por enumeración aquí

En este contexto, “enumeración” es la capacidad de listar o inferir autores existentes (y, en ciertos casos, acercarse a identificadores reutilizables) mediante:

  • el propio patrón /author/<slug>/,
  • mecanismos de canonical redirect,
  • sitemaps de usuarios/autores,
  • o endpoints que exponen listados de autores.

El riesgo no suele ser “se filtra un secreto crítico” por sí solo; el riesgo es que se reduce el coste de reconocimiento y se facilita automatización.

OWASP trata la enumeración de cuentas como un problema de identidad: si el sistema responde de manera distinta ante identidades válidas vs inválidas, puede facilitar listados de cuentas y apoyar ataques posteriores.

1.2 Por qué “author archives activas” no siempre es un problema

En un blog multi-autor, las author archives pueden ser parte del UX/SEO. Si:

  • los autores son públicos por diseño,
  • hay 2FA y controles anti-bot en autenticación,
  • y el sistema está endurecido,

entonces la enumeración aporta poco adicional.

1.3 Cuándo sí se convierte en un riesgo material (casos comunes)

Aquí es donde debemos ser estrictos. El riesgo aumenta cuando se combina con otros factores:

Caso A — Sitio corporativo sin intención de exponer autores
Si no hay valor SEO/UX en author pages, pero existen porque WordPress las genera, estamos manteniendo superficie pública innecesaria.

Caso B — Slug del autor “demasiado informativo”
Si el slug se parece al login, email, nombre interno o convención corporativa, la enumeración puede ayudar a ataques dirigidos (phishing, fuerza bruta, etc.). En el ecosistema WordPress existe debate sobre si ciertos mecanismos facilitan inferir “usernames” (por ejemplo, discusiones en Trac sobre sitemaps de usuarios).

Caso C — Riesgo compuesto con ataques de autenticación
La enumeración cobra valor cuando se combina con presión real al login (bots, credential stuffing). OWASP destaca que en ataques como credential stuffing los atacantes usan pares usuario/contraseña filtrados y técnicas distribuidas, por lo que debemos asumir automatización y escala.

2) Cómo evaluarlo con evidencia (sin asumir)

Para decidir correctamente, recomendamos un proceso corto, repetible y defensivo:

Paso 1 — Confirmar si /author/ está realmente activo y accesible

  • Abrimos una URL de autor conocida (desde un post publicado con byline/link).
  • Verificamos si responde 200 y si indexa contenido “útil” o es una página pobre (thin content).

Paso 2 — Ver si existen vías de agregación (sitemap de usuarios/autores)

Desde WordPress 5.5 existe sitemap nativo extensible por providers.
En particular, el provider WP_Sitemaps_Users genera sitemaps de usuarios y está diseñado para crear listas de URLs relacionadas con usuarios.

Si el sitio expone un sitemap de usuarios/autores, el riesgo de enumeración aumenta por agregación (la lista se obtiene en bloque).

Paso 3 — Confirmar si hay redirecciones “canónicas” que faciliten enumeración

WordPress incluye un mecanismo de redirección canónica (redirect_canonical) que intenta llevar URLs “incorrectas” a su versión “correcta”.
En muchos entornos, esa lógica (o plugins asociados) puede terminar convirtiéndose en una vía de enumeración basada en IDs (p. ej., patrones tipo /?author=<id> que derivan en /author/<slug>/). Este comportamiento se aborda explícitamente por plugins cuyo propósito es “deshabilitar la redirección de author archive” para evitar enumeración.

Punto clave: no debemos darlo por hecho; lo verificamos en el sitio.

Paso 4 — Evaluar el valor SEO/UX de mantener author archives

  • Sitio editorial: puede aportar navegación y señales de autoría.
  • Sitio corporativo: con frecuencia aporta poco y puede generar thin content.

Paso 5 — Evaluar el “riesgo compuesto”

Si tenemos:

  • login expuesto,
  • sin 2FA,
  • sin rate limiting,
  • ataques observados,

entonces la enumeración es un acelerador del riesgo. OWASP recomienda defensas por capas contra ataques de autenticación y monitorización asociada.

3) Opciones de protección (de menor a mayor impacto)

A continuación proponemos opciones ordenadas por impacto operativo. La elección correcta depende del modelo editorial.

Opción 1 — Mantener /author/ pero reducir “agregación”

Cuándo aplica: sitios multi-autor donde author pages son parte del diseño.
Qué hacemos:

  • Mantener páginas de autor.
  • Eliminar autores del sitemap si no aporta valor (o filtrar qué autores entran).
  • Asegurar que slugs no sean sensibles.
  • Aplicar rate limiting a rutas de enumeración.

Esto reduce la facilidad de obtener listados completos.

Opción 2 — Filtrar autores “publicables” y excluir cuentas técnicas

Si author pages son necesarias, pero hay cuentas (admins, técnicos, integraciones) que no deberían figurar como autores públicos, conviene:

  • limitar quién publica con qué cuenta,
  • filtrar inclusión en sitemaps (cuando se usan providers de usuarios).

Opción 3 — Desactivar el sitemap de usuarios/autores

Si no hay valor claro en indexar author pages, desactivar el provider de usuarios es una medida limpia, porque el sistema de sitemaps es extensible y “por piezas”.
(En paralelo, debemos decidir si las author pages deben existir.)

Opción 4 — Desactivar author archives (404/redirect) de forma controlada

Cuándo aplica: sitios corporativos o sitios donde autoría no debe ser un recurso público indexable.
En estos casos, la opción más robusta es devolver 404 (o redirigir a una URL neutra, según estrategia), de manera consistente.

Hay plugins dedicados a “desactivar author archives” devolviendo 404, lo que refleja que este patrón es común cuando no se desean esas páginas.

Opción 5 — Medidas compensatorias cuando debemos mantener author pages

Si por razones de negocio debemos mantener author pages y sitemaps:

  • endurecemos autenticación (2FA),
  • rate limiting / anti-bot,
  • y reducimos señales (slugs no informativos).

OWASP enfatiza que MFA/2FA y defensas multi-capa son de las mejores mitigaciones para ataques basados en credenciales.

4) Implementación práctica: WP, servidor y WAF/rate-limit

4.1 Desactivar author archives a nivel WordPress (404) sin romper el sitio

La forma típica es interceptar la carga de plantilla y responder con 404 cuando la query es de autor.

El hook template_redirect se ejecuta antes de determinar qué plantilla cargar y es apropiado para redirecciones/alteraciones con conocimiento de la query.

Ejemplo (recomendado como mu-plugin para estabilidad):

<?php
/**
 * Plugin Name: Policy - Disable Author Archives
 * Description: Devuelve 404 para /author/ (author archives).
 */

add_action('template_redirect', function () {
    if (is_author()) {
        global $wp_query;
        $wp_query->set_404();
        status_header(404);
        nocache_headers();
        // Cargar plantilla 404 del tema si existe
        include get_404_template();
        exit;
    }
});

Nota operativa: en algunos sitios, la redirección canónica puede interferir o “corregir” rutas. redirect_canonical() es la función responsable de esos intentos de corrección.
Si detectamos que /?author=<id> redirige a /author/... y queremos cortar esa vía, podemos evaluar la conveniencia de desactivar la redirección canónica solo en contexto autor, con extremo cuidado para no afectar SEO global (no recomendamos deshabilitarla de forma general sin análisis).

4.2 Bloqueo/limitación a nivel servidor (si el negocio lo permite)

Si decidimos que /author/ no debe ser accesible, bloquear en Nginx/Apache evita carga en PHP y reduce superficie.

Nginx (ejemplo conceptual):

location ^~ /author/ {
  return 404;
}

Apache (ejemplo conceptual):

RedirectMatch 404 ^/author/.*$

En entornos con CDN/WAF, es preferible hacerlo en el edge (menos carga), pero mantener coherencia (edge y origin deben alinearse).

4.3 Mitigación de enumeración sin desactivar author pages (WAF/rate limiting)

Si mantenemos /author/, recomendamos medidas “quirúrgicas”:

  • Rate limit sobre:
    • /?author= (si existe esa vía),
    • /author/,
    • y endpoints de enumeración de usuarios cuando aplique (p. ej., REST users si está expuesto).
  • Reglas por comportamiento: bursts, IPs de datacenters, user agents anómalos, etc.

El objetivo no es “impedir que Google rastree”, sino frenar automatización hostil. OWASP advierte que ataques de autenticación y enumeración pueden ser distribuidos, por lo que conviene apoyarse en inteligencia de IP/proxy/ASN y no depender únicamente de contadores por IP.

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

Consideramos el riesgo gestionado cuando:

Decisión de negocio

  • Hemos decidido si las author pages aportan valor real (editorial/UX/SEO) o son residuo técnico.

Si NO aportan valor

  • /author/ devuelve 404 (o se redirige de forma controlada).
  • No existe enumeración por redirecciones relacionadas con author (si estaba presente).
  • No se publican autores en sitemap (si existía provider de usuarios).

Si SÍ aportan valor

  • El sitemap de usuarios/autores se filtra o se mantiene solo para autores “de negocio”.
  • Slugs de autor no exponen identificadores sensibles (verificado).
  • Existen controles anti-automatización (WAF/rate limit) para rutas de enumeración.
  • La postura de autenticación está reforzada (2FA + controles por capas).

6) Preguntas frecuentes

¿Tener /author/ activo es una vulnerabilidad?

No necesariamente. Es una característica que puede convertirse en factor de riesgo cuando facilita enumeración y se combina con controles débiles de autenticación. OWASP trata la enumeración como un problema cuando el sistema ayuda a distinguir cuentas válidas o a agregarlas de forma útil para ataques posteriores.

¿Desactivar author archives afecta SEO?

Depende del modelo editorial. En un blog multi-autor, puede afectar rastreo/indexación de esas páginas. En un sitio corporativo sin estrategia de autoría, normalmente el impacto es mínimo y se reduce “thin content”.

¿Qué opción recomendamos por defecto?

  • Corporativo / institucional: desactivar /author/ (404) o, como mínimo, retirar autores del sitemap y evitar slugs sensibles.
  • Editorial multi-autor: mantener /author/, filtrar autores “válidos” y aplicar mitigaciones (rate limit + 2FA).