Editor de WordPress vs. Rol de Administrador: Una Guía Técnica Completa

WordPress incluye un sistema granular de control de acceso basado en roles (RBAC) integrado directamente en su núcleo. De todos los roles predeterminados, Administrador y Editor son los dos más importantes — y los que se asignan incorrectamente con mayor frecuencia. El Administrador tiene capacidad sin restricciones sobre cada objeto de WordPress, mientras que el Editor opera con amplia autoridad sobre el contenido pero sin acceso a los controles a nivel de infraestructura, como temas, plugins o configuraciones del sitio.

Confundir esta distinción no es un inconveniente menor. Otorgar acceso de Administrador a un redactor de contenido en un sitio en producción es una superficie de ataque directa: una cuenta comprometida puede instalar un plugin malicioso, exfiltrar la base de datos o bloquear a todos los demás usuarios. Esta guía le proporciona la profundidad técnica necesaria para tomar la decisión correcta en todo momento.

Cómo funcionan realmente los roles y capacidades de WordPress

Antes de comparar los dos roles, vale la pena entender la arquitectura subyacente. WordPress no almacena los roles como una propiedad fija de una cuenta de usuario. En cambio, almacena un array serializado de capacidades en la tabla wp_usermeta bajo la clave wp_capabilities (donde wp_ es el prefijo de su tabla). Cada rol es simplemente un conjunto de capacidades con nombre registrado en la clase WP_Roles.

Cuando un usuario intenta realizar una acción — publicar una entrada, eliminar un plugin, editar el perfil de otro usuario — WordPress llama a current_user_can(), que resuelve las capacidades almacenadas del usuario frente a la primitiva solicitada. Esto significa que las capacidades son aditivas y, fundamentalmente, pueden personalizarse por usuario de forma independiente a su rol mediante plugins como Members o User Role Editor.

La implicación práctica: si necesita un usuario que pueda hacer *casi* todo lo que puede hacer un Editor pero que también gestione un plugin específico, no necesita escalarlo a Administrador. Puede otorgar una única capacidad adicional. Entender esto previene el error de sobreaprovisionamiento más común en la gestión de equipos de WordPress.

Rol de Administrador: Desglose completo de capacidades

El rol de Administrador se corresponde con prácticamente todas las capacidades primitivas que expone WordPress. En una instalación de sitio único, esto incluye, entre otras:

Capacidades de gestión del sitio principal:

manage_options — leer y escribir todas las configuraciones a través de wp-admin/options-general.php, incluyendo la URL del sitio, el correo electrónico del administrador, la estructura de permalinks y la zona horaria
install_plugins, activate_plugins, update_plugins, delete_plugins — control completo del ciclo de vida de los plugins
install_themes, switch_themes, edit_themes, delete_themes — control completo del ciclo de vida de los temas, incluyendo la edición directa de archivos a través del editor de temas integrado (un vector de ataque significativo)
edit_files — acceso al editor de código integrado para temas y plugins (esta capacidad se deshabilita cuando DISALLOW_FILE_EDIT se establece en true en wp-config.php)

Capacidades de gestión de usuarios:

create_users, edit_users, delete_users, promote_users, list_users — autoridad total sobre cada cuenta de usuario del sitio, incluyendo la capacidad de degradar o eliminar a otros Administradores
remove_users — eliminar usuarios de una red Multisite

Capacidades de contenido:

edit_others_posts, edit_published_posts, delete_others_posts, delete_published_posts, delete_private_posts

Capacidades avanzadas:

import — importar contenido a través del importador de WordPress (puede usarse para inyectar contenido arbitrario a escala)
export — exportar todo el contenido del sitio como un archivo XML, incluyendo todos los datos de usuarios
update_core — activar actualizaciones del núcleo de WordPress
manage_categories, moderate_comments, unfiltered_html — publicar HTML sin procesar incluyendo etiquetas <script> sin sanitización

La capacidad unfiltered_html merece especial atención. En una instalación estándar de sitio único, tanto los Administradores como los Editores la reciben. En WordPress Multisite, solo los Super Administradores la conservan. Este es un límite de seguridad significativo: sin unfiltered_html, el filtro wp_kses_post() elimina JavaScript y otro marcado potencialmente peligroso del contenido guardado.
Cuándo asignar el rol de Administrador

La persona que es propietaria de la cuenta de alojamiento y es responsable de la integridad técnica del sitio
Un desarrollador o ingeniero DevOps verificado que realiza desarrollo de temas, configuración de plugins o trabajo de integración del lado del servidor
Un especialista en migración durante una operación puntual de importación/exportación (considere revocar el rol posteriormente)

Nota operativa crítica: Nunca asigne el rol de Administrador a una cuenta compartida o genérica. Cada Administrador debe ser una persona identificada con una contraseña única y segura y autenticación de dos factores habilitada. Si está ejecutando WordPress en un entorno de Hosting VPS, combine la higiene del Administrador a nivel de WordPress con la separación de usuarios a nivel del sistema operativo — el proceso de su servidor web nunca debe ejecutarse como root, y la propiedad de los archivos de WordPress debe ser distinta a la del usuario del servidor web.
Rol de Editor: Desglose de capacidades
El rol de Editor está diseñado específicamente para operaciones de contenido. Otorga amplia autoridad sobre entradas, páginas, medios, comentarios y taxonomía — pero excluye deliberadamente todas las capacidades a nivel de infraestructura.
Capacidades de contenido que tiene un Editor:

edit_posts, edit_others_posts, edit_published_posts, edit_private_posts

Lo que un Editor explícitamente no puede hacer:

• Acceder a wp-admin/options-general.php o a cualquier pantalla de configuración
• Instalar, activar, desactivar o eliminar plugins o temas
• Ver o modificar cualquier cuenta de usuario que no sea su propio perfil
• Ejecutar actualizaciones del núcleo de WordPress
• Acceder a los editores de archivos de temas o plugins integrados
• Cambiar las estructuras de permalinks, lo que rompería todas las URL existentes en todo el sitio
• Exportar o importar datos del sitio

Cuándo asignar el rol de Editor

• Un editor jefe o director de contenido que gestiona el calendario editorial y aprueba borradores de múltiples colaboradores
• Un especialista en SEO que necesita publicar, programar y optimizar entradas pero no tiene ningún motivo para tocar la configuración de los plugins
• Un gestor de redes sociales o de marketing responsable de mantener el blog activo
• Un cliente que necesita actualizar sus propias páginas sin el riesgo de romper accidentalmente el sitio

Administrador vs. Editor: Comparación lado a lado

Implicaciones de seguridad de la asignación incorrecta de roles

El problema del Editor con exceso de privilegios

Un patrón común en las agencias: a un redactor de contenido se le otorga acceso de Administrador porque “es más fácil”. Esto crea varios riesgos concretos:

1. La instalación de plugins como vector de ejecución de código. Cualquier Administrador puede instalar un plugin. Un plugin es código PHP que se ejecuta en su servidor. Una cuenta de Administrador comprometida equivale a ejecución remota de código.
2. Recolección de credenciales mediante exportación. La herramienta de exportación de WordPress produce un archivo XML que contiene todo el contenido de las entradas, comentarios y metadatos de autores. Un Administrador puede activar esto de forma silenciosa.
3. Persistencia de escalada de privilegios. Un atacante que obtiene acceso de Administrador puede crear una nueva cuenta de Administrador y luego eliminar la evidencia — bloqueando al propietario legítimo.
4. Abuso de unfiltered_html. Incluso sin acceso a plugins, un Administrador puede inyectar etiquetas <script> directamente en el contenido de las entradas, habilitando ataques XSS almacenados contra los visitantes del sitio.

Reforzar el rol de Administrador

Más allá de la asignación de roles, aplique estos controles a nivel de WordPress en cualquier sitio en producción:

Añada lo siguiente a wp-config.php para deshabilitar el editor de archivos integrado:

define( 'DISALLOW_FILE_EDIT', true );
define( 'DISALLOW_FILE_MODS', true ); // Also blocks plugin/theme installation

Restrinja el área de administración de WordPress por IP a nivel del servidor. Para Nginx:

location /wp-admin/ {
    allow 203.0.113.0/24;
    deny all;
}

Para Apache, añada a .htaccess:

<Files "wp-login.php">
    Require ip 203.0.113.0/24
</Files>

Aplique contraseñas seguras y autenticación de dos factores usando un plugin como WP 2FA o Wordfence Login Security. Si su sitio se ejecuta en un Servidor Dedicado, considere colocar el panel de administración de WordPress detrás de una VPN o un túnel SSH en lugar de exponerlo a internet público.

Proteger el rol de Editor del abuso

El rol de Editor es significativamente más seguro que el de Administrador, pero no está exento de riesgos:

• Un Editor con unfiltered_html puede inyectar píxeles de seguimiento, redirecciones de afiliados o scripts maliciosos en el contenido de las entradas. En Multisite, esta capacidad se elimina — un argumento sólido para ejecutar una red Multisite cuando se tienen muchos colaboradores de contenido.
• Un Editor puede eliminar permanentemente cualquier entrada o página, incluidas las que no ha creado. No existe una papelera de reciclaje integrada para las páginas. Utilice una estrategia de revisiones o copias de seguridad para mitigar esto.
• Un Editor puede aprobar comentarios, incluidos los que contienen enlaces de spam, lo que afecta al SEO y la reputación de su sitio.

WordPress Multisite: Cómo cambian los roles

En una red WordPress Multisite, la jerarquía de roles gana un nivel adicional: Super Administrador. El Super Admin se sitúa por encima de todos los Administradores a nivel de sitio y controla la configuración de toda la red, la activación de plugins en todos los sitios y la creación de usuarios a nivel de red.

En Multisite, un Administrador a nivel de sitio pierde varias capacidades que existen en las instalaciones de sitio único, incluyendo la capacidad de instalar plugins (solo los Super Admins pueden hacerlo en toda la red) y la capacidad unfiltered_html. Esto hace que Multisite sea una arquitectura más defendible para las agencias que gestionan sitios de clientes o editores que gestionan múltiples propiedades editoriales.

Si está construyendo una plataforma de publicación multi-tenant, un VPS con cPanel puede simplificar la capa de gestión del lado del servidor mientras WordPress Multisite gestiona la separación de roles a nivel de aplicación.

Roles personalizados: Cuándo ni Administrador ni Editor se ajustan

Las funciones add_role() y add_cap() de WordPress le permiten definir roles con exactamente las capacidades que requiere su flujo de trabajo. Por ejemplo, un Editor Sénior que puede hacer todo lo que puede hacer un Editor más gestionar usuarios (pero no plugins) puede crearse de forma programática:

add_role(
    'senior_editor',
    'Senior Editor',
    array(
        // Inherit all standard Editor capabilities
        'read'                   => true,
        'edit_posts'             => true,
        'edit_others_posts'      => true,
        'edit_published_posts'   => true,
        'publish_posts'          => true,
        'delete_posts'           => true,
        'delete_others_posts'    => true,
        'delete_published_posts' => true,
        'edit_pages'             => true,
        'edit_others_pages'      => true,
        'edit_published_pages'   => true,
        'publish_pages'          => true,
        'delete_pages'           => true,
        'manage_categories'      => true,
        'moderate_comments'      => true,
        'upload_files'           => true,
        // Extended capability
        'list_users'             => true,
        'edit_users'             => true,
    )
);

Coloque este código en un plugin específico del sitio (no en el functions.php de un tema) para que el rol persista a través de los cambios de tema. Los roles se almacenan en la base de datos después del primer registro, por lo que add_role() solo necesita ejecutarse una vez — envuélvalo en un hook de activación de plugin usando register_activation_hook().

Matriz de decisión práctica para la asignación de roles

Use esta lista de verificación antes de asignar cualquier rol:

Asigne Administrador solo si el usuario:

• Es propietario del sitio o tiene una responsabilidad contractual sobre su operación técnica
• Necesita instalar, configurar o actualizar plugins y temas
• Debe gestionar otras cuentas de usuario o cambiar roles de usuario
• Requiere acceso a la configuración de WordPress, la estructura de permalinks o la URL del sitio
• Tiene habilitada la autenticación de dos factores y usa una cuenta única no compartida
• Entiende que DISALLOW_FILE_MODS se establecerá en true en producción

Asigne Editor si el usuario:

• Es responsable de la calidad del contenido, los calendarios de publicación o la revisión editorial
• Necesita gestionar entradas y páginas creadas por otros miembros del equipo
• Debe poder moderar comentarios y gestionar medios
• No necesita — y no debería tener — acceso a ningún plugin, tema o pantalla de configuración
• Puede ser un cliente, freelancer o contratista cuya seguridad de cuenta no puede controlar completamente

Considere un rol personalizado si:

• El Editor integrado es demasiado restrictivo (por ejemplo, el usuario necesita list_users para un plugin de flujo de trabajo editorial)
• El Administrador integrado es demasiado permisivo (por ejemplo, un desarrollador que necesita acceso a plugins pero no debe tocar las cuentas de usuario)
• Está ejecutando una red Multisite con responsabilidades diferenciadas entre sitios

Para los equipos que gestionan WordPress junto con correo electrónico transaccional, considere combinar su estrategia de roles con una configuración dedicada de Hosting de Correo Electrónico para que los correos de notificación de WordPress (restablecimientos de contraseña, nuevos registros de usuarios, alertas de comentarios) se enruten a través de un servidor de correo confiable y autenticado en lugar del sendmail predeterminado del servidor de alojamiento — un punto de fallo de entregabilidad común que afecta el flujo de trabajo de todos los roles.

Si su sitio WordPress gestiona comercio electrónico, membresías o cualquier dato de usuario, asegúrese de que sus Certificados SSL estén actualizados y correctamente configurados. Un certificado caducado no solo afecta al SEO — rompe el contexto de seguridad del navegador que protege las credenciales de inicio de sesión del Administrador en tránsito.

Conclusiones técnicas clave

• Las capacidades de WordPress se almacenan por usuario en wp_usermeta, no están codificadas de forma fija — pueden personalizarse sin cambiar el rol mostrado de un usuario.
• DISALLOW_FILE_EDIT y DISALLOW_FILE_MODS en wp-config.php son innegociables en cualquier sitio en producción con múltiples Administradores.
• La capacidad unfiltered_html existe tanto para Administradores como para Editores en instalaciones de sitio único. Multisite la elimina de todos los que están por debajo del Super Admin.
• Un Editor puede eliminar permanentemente cualquier entrada o página, incluido el contenido de otros usuarios. Implemente una estrategia de copias de seguridad o revisiones antes de otorgar este rol a alguien fuera de su equipo principal.
• Nunca use una cuenta de Administrador compartida. Una cuenta por persona, autenticación de dos factores obligatoria y registros de auditoría habilitados mediante un plugin como WP Activity Log.
• Los roles personalizados mediante add_role() son la solución correcta cuando ningún rol predeterminado se ajusta — no sobreaprovisionne para compensar una capacidad faltante.
• En Multisite, los Administradores a nivel de sitio no pueden instalar plugins. Esto es una característica, no una limitación — es la arquitectura correcta para entornos multi-tenant gestionados.

Preguntas frecuentes

¿Puede un Editor eliminar las entradas de otro usuario en WordPress?

Sí. El rol de Editor incluye delete_others_posts y delete_others_pages. Un Editor puede eliminar permanentemente cualquier entrada o página del sitio, independientemente de quién la haya creado. No existe un paso de confirmación integrado ni una papelera de reciclaje para las páginas, por lo que esta acción es irreversible sin una copia de seguridad.

¿Cuál es la diferencia entre Administrador y Super Administrador en WordPress?

En una instalación de WordPress de sitio único, el Administrador es el rol más alto. En una red WordPress Multisite, el Super Administrador se sitúa por encima de todos los Administradores a nivel de sitio y controla la configuración de toda la red, la instalación de plugins en todos los sitios y la capacidad de añadir o eliminar sitios de la red. Un Administrador a nivel de sitio en Multisite no puede instalar plugins ni usar unfiltered_html.

¿Puedo dar a un Editor acceso a la configuración de un plugin específico sin convertirlo en Administrador?

Sí. Use add_cap() para otorgar una capacidad específica a un usuario individual, o cree un rol personalizado que incluya las capacidades predeterminadas del Editor más la capacidad específica que registra el plugin. La mayoría de los plugins bien codificados usan current_user_can( 'manage_options' ) o una capacidad personalizada para sus páginas de configuración — revise el código fuente del plugin para identificar la capacidad exacta requerida.

¿Es seguro tener múltiples Administradores en un sitio WordPress?

Depende completamente de sus controles operativos. Múltiples Administradores multiplican la superficie de ataque — cada cuenta es un punto de entrada potencial. Si son necesarios múltiples Administradores, aplique la autenticación de dos factores para todos ellos, restrinja el acceso a /wp-admin/ por IP a nivel del servidor, establezca DISALLOW_FILE_MODS en true, y use un plugin de registro de actividad para auditar todas las acciones administrativas.

¿Cómo puedo auditar qué capacidades tiene realmente un usuario específico de WordPress?

Consulte la base de datos directamente o use un plugin como Members o User Role Editor. Para una verificación programática, use get_user_meta( $user_id, $wpdb->prefix . 'capabilities', true ) en un script personalizado o en WordPress CLI:

wp user get <user_id> --field=roles
wp user list-caps <user_id>

El comando wp user list-caps muestra cada capacidad que tiene el usuario, incluidas las que se otorgaron individualmente fuera de su rol asignado — que es la forma más confiable de auditar cuentas con exceso de aprovisionamiento.