Tengo acceso a WordPress, pero no al hosting: qué puedes hacer y qué necesitas recuperar

Puedes entrar en WordPress. Tienes un usuario administrador. Ves las páginas, los plugins y las actualizaciones pendientes.

Todo parece estar bajo control hasta que intentas hacer algo un poco más serio.

El plugin de copias de seguridad no puede crear un directorio. WordPress te avisa de que la versión de PHP es antigua. Una actualización falla. Alguien te dice que necesitas entrar en cPanel, utilizar SFTP o revisar la base de datos.

Y entonces aparece la pregunta:

«Si soy administrador de WordPress, ¿por qué no puedo hacer esto?»

Porque administrar WordPress y controlar el alojamiento son dos cosas diferentes.

Un administrador de WordPress puede tener muchísimo poder dentro de la aplicación, pero eso no significa que controle el servidor donde está instalada, la cuenta del hosting, las copias del proveedor, PHP, los DNS o la base de datos desde fuera de WordPress.

Si estás gestionando una web heredada y solo tienes acceso a /wp-admin, no significa que hayas perdido la web. Pero antes de actualizar PHP, realizar una migración o introducir cambios importantes conviene recuperar una vía de acceso que siga funcionando si WordPress deja de funcionar.

Ese es el problema que hay que resolver primero.

Tener acceso a WordPress no significa tener acceso al servidor

WordPress funciona sobre una infraestructura que normalmente incluye un servidor web, PHP y una base de datos MySQL o MariaDB. WordPress.org explica que el alojamiento proporciona precisamente ese entorno sobre el que funciona la aplicación.

Por eso conviene separar las piezas.

La distinción es importante porque una web puede estar funcionando perfectamente mientras nadie dentro de la empresa conoce las credenciales de su alojamiento.

Eso no suele notarse al cambiar un texto. Se nota el día que hay una incidencia.

Si además quieres revisar quién debería controlar cada una de estas cuentas, en ¿Tu empresa controla realmente su WordPress? analizamos dominio, hosting, DNS, WordPress, backups y licencias desde el punto de vista de la empresa. Qué accesos de WordPress debe controlar tu empresa

Qué puedes averiguar antes de tener acceso al hosting

No tener las credenciales del servidor no significa que debas trabajar a ciegas.

Si conservas un administrador de WordPress, una de las primeras pantallas que merece la pena consultar es Herramientas → Salud del sitio → Información.

WordPress muestra ahí información sobre la versión instalada, plugins, temas, servidor, base de datos, constantes y permisos del sistema de archivos. Es una pantalla informativa: que muestre un problema no significa que puedas corregirlo desde allí. La propia documentación de WordPress indica, por ejemplo, que determinados ajustes de PHP o problemas con permisos pueden requerir la intervención del proveedor de alojamiento.

También puedes aprovechar el acceso actual para identificar qué WordPress has heredado: versiones instaladas, tema activo, plugins activos e inactivos, usuarios administradores, dirección de correo de administración y herramientas de backup o seguridad existentes.

Ese inventario tiene valor incluso aunque después intervenga otra persona. Reduce considerablemente el número de incógnitas.

Lo que no conviene es confundir tener información sobre el servidor con controlarlo.

Salud del sitio puede indicarte qué versión de PHP está ejecutándose. No te entrega por ello la cuenta desde la que puedes cambiarla.

«Mi plugin de backup dice que no tiene permisos». ¿Qué significa?

Este caso merece atención porque conduce fácilmente a soluciones equivocadas.

Imagina que intentas generar una copia y el plugin responde que no puede escribir en una carpeta. Después intentas instalar otra herramienta y WordPress tampoco puede crear su directorio.

El dato importante es este:

WordPress está intentando escribir en una ubicación y no puede hacerlo.

Eso es un síntoma. Todavía no es un diagnóstico.

Puede haber un problema de permisos, propiedad de archivos, configuración del servidor u otra limitación del entorno. La documentación oficial de WordPress explica que determinadas carpetas necesitan ser escribibles en función de la configuración del alojamiento y que los permisos dependen también del usuario con el que se ejecuta el servidor web.

Lo que no haría en una web empresarial es empezar a cambiar permisos indiscriminadamente hasta que desaparezca el error.

Mucho menos aplicar permisos excesivamente abiertos a carpetas enteras sin entender la configuración del servidor.

Y existe una pista bastante clara cuando WordPress ni siquiera puede crear el directorio necesario para instalar otro plugin: instalar un plugin de gestión de archivos como puente puede no resolver el problema que te impide instalarlo en primer lugar.

En ese punto, recuperar el acceso correcto al alojamiento suele ser más razonable que encadenar parches desde WordPress.

¿Puedo hacer una copia completa si solo tengo wp-admin?

A veces sí. Pero no debes darlo por garantizado.

Un plugin de backups puede generar una copia completa desde WordPress si la instalación funciona correctamente, dispone de permisos suficientes y el servidor tiene los recursos necesarios.

El problema es que precisamente una web heredada puede fallar en alguno de esos puntos.

Además, hay una diferencia importante entre exportar contenido y hacer un backup completo.

WordPress dispone de Herramientas → Exportar, desde donde puede generar un archivo WXR con entradas, páginas, tipos de contenido, comentarios, campos personalizados, categorías, etiquetas y otros datos. Es útil para trasladar contenido, pero no equivale a una copia integral de la instalación.

Para poder reconstruir un WordPress normal necesitas considerar dos partes: archivos y base de datos.

Los archivos contienen, entre otras cosas, temas, plugins, imágenes, configuraciones y código. La base de datos contiene páginas, entradas, ajustes y muchos de los datos utilizados por la aplicación. WordPress documenta expresamente que copiar solamente los archivos no suele incluir la base de datos y que una recuperación completa debe contemplar ambos componentes.

Por tanto, si el plugin de backups que tienes instalado falla y tampoco controlas el hosting, no asumiría que una exportación de WordPress resuelve el problema.

Puedes guardar esa exportación como una capa adicional de protección, pero seguiría intentando recuperar una copia completa antes de una intervención importante.

En Copias de seguridad en WordPress: la diferencia entre creer que las tienes y saber que funcionan explicamos con más detalle por qué la existencia de un archivo de backup tampoco demuestra por sí sola que puedas restaurar la web. Cómo saber si tus copias de seguridad de WordPress funcionan

Por qué un plugin «File Manager» no sustituye al acceso al hosting

Puede parecer una solución perfecta: si no tienes SFTP ni panel de hosting, instalas un gestor de archivos dentro de WordPress y ya puedes modificar archivos.

Pero estás resolviendo otra cosa.

Un gestor de archivos ejecutado desde WordPress sigue funcionando dentro del entorno y de los permisos que el servidor concede a WordPress. No convierte tu usuario de WordPress en propietario de la cuenta del alojamiento.

Incluso si consigue acceder a determinados archivos, sigues sin haber recuperado necesariamente el control de la cuenta del proveedor, su soporte, las copias externas, la configuración de PHP, las herramientas de recuperación, determinados registros del servidor, el dominio o los DNS.

Hay además otra diferencia muy práctica: ¿qué ocurre con ese gestor de archivos cuando WordPress deja de cargar?

Desaparece justo la vía de acceso de la que dependías.

Por eso resulta mucho más útil pensar en una segunda puerta de entrada independiente de WordPress.

Puede ser el panel del alojamiento, SFTP u otra herramienta proporcionada por el proveedor. Lo importante no es coleccionar credenciales técnicas. Lo importante es tener una vía desde la que puedas diagnosticar y recuperar la instalación aunque /wp-admin no esté disponible.

¿Cómo averiguo dónde está alojada una web que he heredado?

Antes de utilizar herramientas técnicas, buscaría algo mucho más aburrido: quién está pagando el servicio.

Facturas, movimientos contables, correos de renovación, antiguos presupuestos, contratos, gestores de contraseñas compartidos y conversaciones con el desarrollador anterior suelen aportar más información que intentar deducir el proveedor exclusivamente desde fuera.

También puedes encontrar pistas en la configuración del dominio o en los DNS, pero conviene interpretar esas pistas con cuidado.

El registrador del dominio no tiene por qué ser el proveedor de hosting. El proveedor DNS tampoco tiene por qué alojar la web.

Y obtener una dirección IP pública tampoco siempre identifica el servidor real. Por ejemplo, cuando una web utiliza registros DNS con proxy de Cloudflare, las consultas públicas pueden devolver direcciones de Cloudflare en lugar de la IP del servidor de origen. La propia documentación de Cloudflare explica que ese comportamiento sirve precisamente para ocultar la dirección del servidor original.

Por la misma razón, un WHOIS del dominio puede ayudarte a identificar información sobre el registro del dominio, pero no deberías tratarlo automáticamente como respuesta a «¿dónde está alojado WordPress?».

Si consigues identificar al proveedor, entonces sí: busca el procedimiento oficial de recuperación de cuenta o contacta con soporte aportando la información de la empresa que pueda acreditar la relación contractual.

El antiguo desarrollador pagaba el hosting: ¿y ahora qué?

Esta situación cambia el problema.

Puede que la empresa sea propietaria del contenido y utilice el dominio, pero que la cuenta concreta del alojamiento esté contratada desde el correo y los datos del profesional que desarrolló la web.

No intentaría resolverlo técnicamente saltándome esa cuenta.

Primero hay que reconstruir quién contrató cada servicio.

Puede ser necesario localizar facturas, contratos, antiguos correos, datos de facturación y la cuenta desde la que se renueva el dominio. Después, el proveedor podrá indicar qué proceso admite para recuperar o transferir el servicio.

Y si el antiguo profesional simplemente ha dejado de responder, merece la pena tratar la situación como un problema más amplio que una contraseña perdida. En Mi desarrollador web ha desaparecido: cómo recuperar el control de tu WordPress explicamos cómo inventariar activos y accesos antes de empezar a eliminar usuarios o cambiar configuraciones. Qué hacer si tu desarrollador WordPress ha desaparecido

Hay algo que evitar especialmente: cambiar los nameservers o registros DNS para experimentar.

Los DNS pueden afectar no solo a la web, sino también al correo y a otros servicios asociados al dominio. Si necesitas entender esa parte antes de intervenir, puedes revisar ¿Te han pedido cambiar los DNS? Esto es lo que debes saber antes de tocar nada. Cómo cambiar DNS sin romper la web ni el correo

Tengo PHP antiguo y WordPress pendiente de actualizar: ¿puedo hacerlo ya?

Aquí es donde disponer solamente de wp-admin empieza a ser realmente incómodo.

WordPress recomienda actualmente PHP 8.3 o superior como base moderna, junto con MariaDB 10.11+ o MySQL 8.0+. También indica que puede seguir funcionando en determinadas versiones heredadas, pero que estas han alcanzado el final de su vida oficial.

Eso no significa que debas ver una web antigua con PHP obsoleto y saltar inmediatamente a la versión recomendada.

Una web heredada puede tener un tema antiguo, plugins abandonados, código personalizado o integraciones que no sean compatibles con versiones modernas de PHP.

Y aquí no existe una regla universal del tipo «primero PHP y luego WordPress» que sea segura para todas las instalaciones.

Lo sensato es conocer primero el estado de los componentes, disponer de una copia recuperable, saber cómo volver atrás y probar los cambios en un entorno separado cuando el salto sea importante.

Sobre todo, no cambiaría simultáneamente PHP, WordPress, el tema y todos los plugins en producción. Si después aparece un error, habrás multiplicado las posibles causas.

Además, el cambio de versión de PHP normalmente pertenece al entorno de hosting, no al panel de administración de WordPress.

Si estás precisamente ante una instalación que lleva años sin tocarse, Cómo actualizar un WordPress antiguo sin romper la web desarrolla ese escenario con más detalle. Cómo actualizar un WordPress antiguo sin romperlo

Antes de actualizar, necesitas saber cómo volver atrás

«Haré un backup antes» es una buena intención.

La pregunta más importante es:

¿cómo lo restaurarías si después de actualizar ya no puedes entrar en WordPress?

Si la única herramienta de restauración vive dentro del mismo WordPress que acaba de dejar de funcionar, puedes encontrarte con una copia perfectamente válida y sin una vía clara para utilizarla.

Ahí es donde el acceso al alojamiento cambia el escenario.

Dependiendo del proveedor, puede darte acceso a copias realizadas por el propio hosting, archivos, base de datos, registros de errores, configuración de PHP o herramientas de staging y recuperación.

No todos los proveedores ofrecen exactamente lo mismo, así que conviene saber qué tienes antes de necesitarlo.

Una copia no debería ser solo algo que sabes generar. Debería formar parte de un procedimiento de recuperación que sabes ejecutar.

¿Qué ocurre si mañana ya no puedo entrar en wp-admin?

WordPress dispone de un Recovery Mode para determinados errores fatales. Cuando se activa, puede enviar a la dirección administrativa un enlace especial que permite entrar con los plugins o temas problemáticos pausados para esa sesión.

Es muy útil.

Pero no deberías convertirlo en tu único plan de recuperación.

El correo puede no llegar. El problema puede no ser un error compatible con Recovery Mode. Puede existir un fallo de servidor, de base de datos o de configuración que impida utilizar esa vía.

La propia documentación de WordPress contempla entonces alternativas como las herramientas del proveedor o el acceso a archivos para intervenir fuera del administrador.

Esta es probablemente la mejor forma de entender por qué necesitas recuperar el hosting:

mientras wp-admin funciona, la falta de acceso al servidor parece administrativa; cuando wp-admin deja de funcionar, se convierte en un problema de recuperación.

Si ya estás ante el mensaje «Ha habido un error crítico en esta web», no conviene empezar desactivando componentes al azar. En Error crítico en WordPress: qué significa y qué hacer explicamos cómo separar el síntoma del diagnóstico y qué vías existen cuando tampoco funciona el administrador. Qué hacer ante un error crítico de WordPress

¿Y si lo que quiero es llevarme la web a otro hosting?

Tener acceso a wp-admin puede ser suficiente para que determinadas herramientas de migración clonen una web.

Pero, de nuevo, dependerás de que WordPress esté sano y de que el servidor permita completar el proceso.

Una migración convencional necesita trasladar archivos y base de datos y posteriormente comprobar que la web funciona en el nuevo entorno. La documentación oficial de WordPress trata archivos y base de datos como las dos piezas esenciales de una copia recuperable.

En una web pequeña y sencilla, una herramienta de migración puede facilitar mucho el trabajo.

En una instalación antigua, grande, con permisos problemáticos o con funciones empresariales importantes, resulta especialmente útil conservar también acceso al origen hasta haber comprobado que el nuevo sitio funciona correctamente.

Si finalmente el camino es cambiar de proveedor, en Cómo hacer una migración de hosting de una web con WordPress tienes el proceso completo y las comprobaciones posteriores. Migración de hosting WordPress paso a paso

El acceso mínimo que intentaría recuperar antes de tocar una web heredada

No necesitas convertir a la empresa en administradora de sistemas.

Necesitas evitar que toda la web dependa de una única contraseña de WordPress.

Antes de una actualización importante, una migración o una intervención sobre una instalación desconocida, intentaría dejar documentado como mínimo:

• la cuenta del hosting y un método de recuperación controlado por la empresa; el registrador del dominio y quién administra los DNS; un administrador de WordPress propio; dónde están los backups y cómo se restauran; una vía de acceso a los archivos cuando sea necesaria; acceso a la base de datos o al procedimiento del proveedor para recuperarla; usuarios administrativos existentes; correo administrativo de WordPress; licencias y servicios externos relevantes; y qué persona o proveedor es responsable de mantener cada pieza.

No todas estas credenciales tienen que utilizarse a diario.

De hecho, algunas deberían permanecer guardadas de forma segura y utilizarse muy pocas veces.

Lo importante es que, cuando haya que intervenir, nadie descubra por primera vez que el hosting pertenece a una cuenta desconocida.

Un mapa rápido: qué acceso necesitas según el problema

Si ahora mismo solo tienes WordPress, no empieces por actualizar

Empieza por reducir incertidumbre.

Averigua qué web tienes delante. Revisa Salud del sitio. Identifica plugins, tema, usuarios y versiones. Comprueba qué backups existen. Localiza quién paga el alojamiento. Recupera la cuenta o habla con el proveedor. Documenta el dominio y los DNS.

Y solo entonces decide qué necesita actualización, migración o reparación.

Pulsar «Actualizar» es fácil.

Lo difícil es saber qué hacer cinco minutos después si aparece un error, desaparece el administrador o descubres que la única copia disponible no se puede restaurar.

El objetivo no es conseguir veinte contraseñas más.

Es bastante más sencillo:

que WordPress no sea la única puerta que puedes abrir precisamente cuando WordPress deja de funcionar.