Cómo retirar accesos de WordPress al cambiar de agencia, desarrollador o proveedor

Cambiar de agencia, desarrollador, proveedor de mantenimiento o responsable interno no consiste solo en pedir una contraseña. Una web puede acumular accesos en WordPress, panel de hosting, SFTP, SSH, base de datos, correo, DNS, servicios de copias, cuentas de analítica y herramientas externas.

El problema no es únicamente que alguien conserve acceso después de terminar una colaboración. También puede ocurrir lo contrario: retirar una credencial sin saber qué proceso dependía de ella y dejar sin funcionar formularios, copias de seguridad, envíos de correo o una integración comercial.

La forma segura de hacer el relevo es tratarlo como una transición operativa: primero inventariar, después crear accesos nuevos controlados, comprobar que funcionan y, por último, revocar o rotar los anteriores. Esta guía sirve tanto si hay una relación profesional que termina correctamente como si se necesita recuperar el control de un sitio con urgencia.

Antes de retirar nada: asegura el control del dominio y del correo

El orden importa. No empieces borrando usuarios de WordPress si todavía no controlas la cuenta de correo que recibe los restablecimientos de contraseña o el dominio desde el que se gestionan los DNS.

Antes de cualquier cambio, confirma quién puede entrar en:

• El registrador del dominio.
• La zona DNS.
• La cuenta de correo asociada al propietario y a los administradores de WordPress.
• El panel de hosting o Plesk.
• El servicio de copias de seguridad.
• La cuenta de facturación del hosting, cuando afecte a renovaciones o soporte.

El correo es especialmente importante. Si una dirección antigua sigue siendo la de recuperación de una cuenta crítica, quien la controle puede recuperar acceso aunque se haya cambiado otra contraseña.

También conviene guardar una fotografía del estado actual: lista de usuarios, roles, plugins activos, tareas programadas, datos de contacto del proveedor y capturas o exportaciones de las configuraciones relevantes. No es para mantener accesos antiguos indefinidamente, sino para poder identificar qué se ha retirado y volver atrás si se detecta una dependencia legítima.

1. Haz un inventario de todos los puntos de acceso

Una cuenta de administrador de WordPress es solo una parte del problema. Haz una lista sencilla con estas columnas: sistema, usuario o integración, nivel de acceso, propietario, finalidad, fecha de revisión y acción prevista.

Como mínimo, revisa estos grupos.

WordPress

• Usuarios administradores, editores, gestores de tienda y cuentas de soporte.
• Usuarios creados para desarrolladores, agencias, migraciones o pruebas.
• Cuentas de servicios que publican contenido o consumen la API.
• Contraseñas de aplicación.
• Claves API o tokens guardados por plugins.

Servidor y hosting

• Panel de hosting o Plesk.
• Usuarios SFTP, FTP y SSH.
• Acceso al proveedor de copias de seguridad.
• Usuarios de base de datos y las aplicaciones que los usan.
• Cron del sistema y tareas programadas fuera de WordPress.
• Accesos de soporte del proveedor o de la agencia, si existen.

Servicios alrededor de la web

• Registrador y DNS.
• Servicio SMTP o cuenta de correo usada para enviar formularios.
• CDN, WAF y cuentas de Cloudflare u otros servicios similares.
• Analítica, Search Console, Tag Manager y píxeles publicitarios.
• Pasarela de pago, herramientas de reservas, CRM, newsletters y automatizaciones.
• Repositorios, despliegues automáticos y servicios de monitorización.

No des por hecho que una cuenta con un nombre técnico es prescindible. Antes de borrarla, identifica qué hace, quién la creó y si hay registros de uso. Si no puedes determinarlo, es preferible desactivar temporalmente el acceso, observar el servicio y documentar el resultado antes de eliminarlo definitivamente.

2. Crea primero tus accesos nuevos y pruébalos

El relevo debe empezar creando una cuenta propia para cada sistema crítico. No reutilices la contraseña que te han entregado ni mantengas una cuenta compartida como único acceso.

Para WordPress, crea al menos una cuenta administradora individual a nombre de la persona responsable. Para el hosting, el dominio, DNS y correo, establece también cuentas nominativas o, si el proveedor no lo permite, guarda las credenciales en un gestor de contraseñas bajo control del propietario.

Comprueba cada acceso en una sesión independiente antes de tocar los anteriores:

1. Entra en WordPress con la nueva cuenta y verifica que puede realizar las tareas necesarias.
2. Entra en el hosting, pero no cambies configuraciones todavía.
3. Confirma que puedes acceder al dominio y a DNS.
4. Envía y recibe un correo de prueba desde la cuenta relevante.
5. Comprueba que puedes localizar y restaurar una copia de seguridad sin ejecutarla en producción.

Activa 2FA en las cuentas administrativas y de proveedor cuando esté disponible. WordPress recomienda aplicar 2FA a administradores y usuarios con privilegios; el núcleo de WordPress no lo incorpora por sí mismo, por lo que debe añadirse mediante un plugin o un proveedor de identidad.[2]

3. Revisa los usuarios y roles de WordPress

En Usuarios > Todos los usuarios, revisa quién tiene acceso y qué puede hacer. No basta con fijarse en el rol de administrador: un gestor de tienda, un editor con publicación directa o una cuenta conectada a herramientas externas puede tener capacidades que afecten a contenido, pedidos o datos personales.

Para cada usuario, decide una de estas acciones:

• Mantenerlo: Es una persona o servicio activo, identificado y necesario.
• Reducir su rol: Sigue colaborando, pero ya no necesita permisos elevados.
• Suspenderlo de forma temporal: Hay dudas sobre su uso y necesitas comprobar dependencias.
• Eliminarlo: No existe necesidad operativa y se ha comprobado que no deja contenido o procesos sin propietario.

Al eliminar una cuenta, WordPress permite atribuir el contenido a otro usuario. Revisa esa opción antes de confirmar la eliminación: borrar un administrador sin reasignar artículos, páginas o entradas personalizadas puede generar problemas de autoría o de gestión posterior.

No compartas cuentas administrativas entre personas. Una cuenta individual permite aplicar 2FA, cerrar su sesión y saber qué acceso debe retirarse cuando cambia el equipo.

4. Revoca contraseñas de aplicación y tokens de integraciones

Una integración no necesita utilizar la contraseña principal de un administrador. WordPress ofrece las contraseñas de aplicación para servicios que se conectan a la REST API o, cuando esté habilitado, XML-RPC. Son credenciales específicas por aplicación, se muestran solo al crearlas y se pueden revocar de forma individual sin cambiar la contraseña principal.[1]

Revísalas desde el perfil de cada usuario y elimina las que no tengan un nombre, una finalidad y un responsable claros. Si una integración sigue siendo necesaria, crea una contraseña de aplicación nueva con un nombre descriptivo, actualízala en el servicio y prueba el flujo antes de revocar la anterior.

Haz la misma revisión con:

• Claves API de plugins y servicios SaaS.
• Webhooks entrantes y salientes.
• Tokens de automatizaciones.
• Credenciales SMTP.
• Claves de pasarelas de pago.
• Claves de almacenamiento externo para copias o medios.

No publiques estos valores en tickets, correos sin cifrar ni capturas de pantalla. Si deben entregarse temporalmente, utiliza un canal acordado y elimínalos de ese canal cuando ya no sean necesarios.

5. Rota las credenciales del hosting y del servidor

Cuando un proveedor o desarrollador ha tenido acceso al servidor, eliminar un usuario concreto puede no ser suficiente. Puede haber credenciales compartidas, claves SSH autorizadas, usuarios SFTP adicionales, tareas cron o accesos al panel que no aparecen en WordPress.

Revisa y rota, según corresponda:

• La contraseña principal del panel de hosting.
• Usuarios SFTP, FTP y SSH.
• Claves públicas autorizadas para SSH.
• Contraseñas de bases de datos y las aplicaciones que dependen de ellas.
• Credenciales de despliegue, repositorios y servicios CI/CD.
• Usuarios del panel de copias de seguridad.

No cambies una contraseña de base de datos sin tener preparado el cambio equivalente en wp-config.php y sin confirmar si otras aplicaciones comparten esa misma base de datos o usuario. Un cambio aparentemente simple puede dejar la web sin conexión a la base de datos.

Con SSH, retirar una cuenta no elimina necesariamente todas las llaves autorizadas. Revisa también los archivos y paneles donde se administren claves públicas. Con SFTP, confirma qué directorio tenía asignado cada usuario: un acceso olvidado a una raíz de suscripción puede abarcar más de una web.

6. Revisa correo, DNS y servicios que permiten recuperar accesos

Un cambio de proveedor puede fallar aunque WordPress esté bajo control si los sistemas de recuperación siguen apuntando a otra persona.

Comprueba que las direcciones de recuperación de WordPress, hosting, registrador, CDN, pasarela de pago y analítica pertenecen al propietario o a un equipo autorizado. Cambia también teléfonos de recuperación, contactos de facturación y direcciones que reciben avisos de renovación o seguridad.

En DNS, documenta los registros actuales antes de modificar nada: A, AAAA, CNAME, MX, TXT, SPF, DKIM y DMARC. Un acceso de DNS puede redirigir la web o el correo, pero una limpieza precipitada de registros puede interrumpir formularios, correo corporativo, validaciones de servicios y subdominios.

Si se usa un proveedor SMTP externo, crea un acceso controlado para el responsable actual y rota la clave utilizada por WordPress después de actualizarla en la configuración del plugin. Envía un formulario de prueba y comprueba la entrega real antes de cerrar el acceso anterior.

7. Cierra sesiones y revisa señales de acceso no autorizado

Rotar contraseñas reduce el riesgo de reutilización, pero no sustituye una revisión. Tras un relevo especialmente tenso o si no hay una lista fiable de accesos, revisa:

• Administradores o cuentas de servicio desconocidas.
• Plugins, temas y MU-plugins no documentados.
• Archivos modificados fuera del proceso habitual.
• Tareas WP-Cron o cron del servidor que no tengan propietario claro.
• Redirecciones, reglas de firewall y configuraciones del servidor.
• Registros de acceso, errores y actividad administrativa disponibles.

Si hay indicios de cambios no autorizados, no empieces borrando pruebas. Conserva los registros disponibles, limita los accesos expuestos y trata el caso como una posible incidencia de seguridad. Una auditoría de seguridad WordPress puede ayudar a distinguir una cuenta antigua inofensiva de una persistencia o de un acceso no autorizado.

Checklist final para cerrar el relevo

Antes de dar el cambio por terminado, confirma:

• El propietario controla dominio, DNS, hosting y correos de recuperación.
• Existe una cuenta individual y protegida con 2FA para gestionar WordPress.
• Los administradores de WordPress han sido revisados, reducidos o eliminados según corresponda.
• Se han revisado y revocado las contraseñas de aplicación, tokens y claves API antiguas.
• Los accesos SFTP, FTP, SSH, hosting y copias de seguridad tienen un responsable actual.
• Las credenciales compartidas se han rotado y probado.
• El correo saliente, formularios, copias e integraciones críticas siguen funcionando.
• Las direcciones de recuperación, contactos de facturación y avisos son correctos.
• Se ha documentado qué accesos se mantienen, quién los usa y cuándo se revisarán de nuevo.

Retirar accesos no es romper relaciones: es ordenar responsabilidades

Una transición bien hecha protege a todas las partes. El propietario recupera control sobre activos que son críticos para su negocio, el nuevo responsable sabe qué sistemas gestiona y el proveedor saliente deja de cargar con permisos que ya no necesita.

La clave está en evitar dos extremos: conservar cuentas antiguas “por si acaso” o borrar accesos sin comprobar qué servicio dependía de ellos. Inventario, cuentas nuevas, pruebas, revocación y documentación permiten hacer el cambio sin improvisar.

Si necesitas recuperar el control de una web tras cambiar de agencia o proveedor, el mantenimiento de seguridad WordPress puede ayudarte a revisar accesos, permisos, configuraciones e integraciones sin perder de vista la continuidad del sitio.

Fuentes

1. Application Passwords — WordPress Developer Resources
2. Brute Force Attacks — WordPress Developer Resources