WordPress no actualiza los cambios: 7 capas de caché y cómo purgarlas

Editas una página, pulsas «Actualizar», el botón cambia a «Actualizado» y todo parece haber ido bien. Pero cuando vas a ver la web desde el navegador… los cambios no están. El texto antiguo sigue ahí, las imágenes nuevas no aparecen, los colores que tocaste en el editor no se reflejan. Si WordPress no actualiza los cambios en tu sitio en producción, la culpa casi nunca es del editor: hay una capa de caché o de configuración en medio que está sirviendo la versión vieja. La buena noticia es que las capas que pueden estar interfiriendo son contadas y todas se purgan en minutos.

En esta guía te explicamos por qué pasa, cómo localizar exactamente dónde está retenida la versión antigua y cómo forzar que el cambio se vea inmediatamente.

Si tu web sigue mostrando contenido antiguo y necesitas que los cambios se vean ya, lo solucionamos hoy mismo.

Habla con nosotros

Por qué WordPress no muestra los cambios que acabas de hacer

Cuando guardas un cambio en WordPress, ese cambio entra en la base de datos casi al instante. Lo que el visitante ve en su navegador no se genera «en vivo» cada vez: pasa por varias capas que pueden quedarse con una copia antigua. Si una de ellas no se entera del cambio, sigue sirviendo lo que tenía guardado.

Las capas habituales que pueden estar interfiriendo son seis: caché del navegador, plugin de caché del sitio, CDN delante de tu web, caché de objetos del servidor (Redis o Memcached), caché de OPcache de PHP y, en menor medida, caché del propio editor o page builder (Elementor, Divi, WPBakery). Atacarlas en orden te lleva al problema en pocos minutos.

Síntomas habituales y cómo identificar dónde está el problema

Antes de purgar a ciegas, identifica el escenario más parecido al tuyo:

  • Tú no ves el cambio pero tus compañeros sí. Es caché del navegador o de tu sesión. Solución en 5 segundos.
  • Nadie ve el cambio, pero el dashboard de WordPress muestra el contenido nuevo. Es caché del sitio (plugin, CDN u objetos). El cambio está guardado, alguna capa retiene la versión vieja.
  • Cambios de Elementor o Divi que no se aplican. El page builder genera CSS en archivos estáticos que hay que regenerar.
  • Cambios solo a veces. Caché parcial: un servidor o nodo del CDN está desincronizado.
  • Después de cambiar de hosting, los cambios no se reflejan. Probable que el DNS aún apunte al servidor antiguo.

Solución 1: caché del navegador (prueba siempre primero)

El 40 % de los casos son simplemente caché del navegador del que está editando. Antes de tocar nada en el sitio, descarta esto:

  1. Abre una ventana de incógnito (Ctrl+Shift+N en Chrome) y carga la URL.
  2. Si el cambio sí aparece en incógnito, era tu navegador. Limpia la caché del navegador habitual (Ctrl+Shift+Del → caché de imágenes y archivos → Borrar) y listo.
  3. Si en incógnito tampoco aparece, el problema no es tu navegador. Sigue bajando por la lista.

Solución 2: purgar el plugin de caché del sitio

Si tienes instalado un plugin de caché (es lo más probable, lo lleva el 80 % de los WordPress de empresa), ese plugin está sirviendo páginas pregeneradas. Los más habituales:

  • WP Rocket: en la barra superior del admin, «WP Rocket → Vaciar caché».
  • W3 Total Cache: «Rendimiento → Dashboard → empty all caches».
  • LiteSpeed Cache: «LiteSpeed Cache → Toolbox → Purge All».
  • WP Super Cache: «Ajustes → WP Super Cache → Delete Cache».
  • Cache Enabler / Hummingbird / Autoptimize: misma lógica, buscar la opción «purgar» o «vaciar».

Si tu hosting usa caché propia (SiteGround SuperCacher, Kinsta Cache, WP Engine, etc.), tienes el botón de purgar en el panel del hosting o en una barra superior dentro del admin de WordPress. Búscalo siempre que toques un plugin de caché normal: las dos capas conviven.

Solución 3: purgar la caché del CDN (Cloudflare y similares)

Si tu web pasa por un CDN (Cloudflare es el más habitual), hay otra capa entre tu servidor y el visitante. Aunque el plugin de caché del sitio esté limpio, el CDN puede seguir sirviendo la versión antigua durante horas.

En Cloudflare, entra al panel → tu dominio → Caching → Configuration → Purge Everything. Confirma y espera 30 segundos. Si solo cambió una URL concreta, usa Custom Purge con la URL específica para no resetear toda la caché. Los hostings tipo Kinsta y WP Engine también usan CDN integrado, donde la opción se llama habitualmente «Clear cache» o «Flush cache».

Solución 4: caché de objetos (Redis o Memcached)

Algunos hostings de alto rendimiento usan caché de objetos en memoria para almacenar consultas a la base de datos. Si tu hosting la tiene activa y un cambio no se refleja, esa caché puede estar reteniendo el dato antiguo. Suele indicarlo el panel del hosting con un botón «Flush Object Cache» o «Restart Redis».

Si tienes acceso SSH y Redis instalado, puedes purgarla con redis-cli FLUSHALL. En la mayoría de casos, el botón del panel de hosting es suficiente. Si no encuentras la opción, pídeselo al soporte: lo hacen en 30 segundos.

Solución 5: regenerar el CSS de Elementor, Divi o WPBakery

Los page builders generan archivos CSS estáticos para acelerar el front-end. Si cambias un color, una tipografía o una clase, el CSS no se actualiza automáticamente: hay que regenerarlo.

  • Elementor: ve a «Elementor → Herramientas → Regenerar CSS y datos».
  • Divi: «Divi → Opciones del tema → Builder → pestaña Performance → «Borrar caché estática del CSS».
  • WPBakery: «WPBakery → Configuración del Page Builder → Eliminar caché».

Después de regenerar, vacía también el plugin de caché del sitio y el CDN. Es la combinación que resuelve casi todos los problemas de «no se ven los cambios» relacionados con builders visuales.

Solución 6: OPcache de PHP y caché del servidor

Menos habitual pero pasa: OPcache de PHP guarda los archivos PHP compilados para acelerar la ejecución. Si haces cambios en código (un tema hijo, un fragmento en functions.php) y no se reflejan, OPcache puede estar la causa. La solución es reiniciar PHP en el panel del hosting (en cPanel: «Software → Seleccionar versión de PHP → Reload») o pedir al hosting que reinicie el servicio.

En hostings modernos esto pasa raramente porque OPcache se invalida automáticamente al detectar el cambio. Si te toca lidiar con ello, normalmente es síntoma de que tu hosting es de calidad limitada.

Solución 7: el DNS aún apunta al servidor antiguo

Si has migrado de hosting recientemente y los cambios que haces en el servidor nuevo no se ven, comprueba primero si estás cargando desde el servidor nuevo o desde el antiguo. Entra a una herramienta como dnschecker.org, mete tu dominio y mira a qué IP está respondiendo. Si la IP no coincide con la del nuevo hosting, los cambios estás haciéndolos en un sitio pero los visitantes (y tú) ven el sitio antiguo.

La propagación de DNS puede tardar hasta 48 horas. Hasta entonces, fuerza la resolución local editando tu archivo hosts (en macOS y Linux, /etc/hosts; en Windows, C:\Windows\System32\drivers\etc\hosts) y añadiendo la IP nueva con tu dominio. Así fuerzas que tu navegador resuelva al servidor correcto sin esperar al DNS.

Preguntas frecuentes

¿Cuál es la diferencia entre la caché del navegador y la caché de la web?

La caché del navegador es local en tu ordenador: solo te afecta a ti. La caché de la web (plugin de caché, CDN, Redis) afecta a todos los visitantes. Si solo tú no ves el cambio, es la del navegador. Si nadie lo ve, es de la web.

¿Cada cuánto debería vaciar la caché de mi web?

Solo cuando hagas cambios importantes y necesites que se vean inmediatamente. Un sitio en producción no necesita vaciar caché a diario: si lo haces, pierdes precisamente la ventaja del cacheo (que el sitio sea rápido).

Tengo Cloudflare activo. ¿Sigue siendo necesario el plugin de caché del sitio?

Sí, conviene tener los dos. Cloudflare cachea estáticos (imágenes, CSS, JS) globalmente, pero el HTML lo regenera tu servidor. El plugin de caché del sitio reduce la carga del servidor sirviendo el HTML cacheado. Las dos capas se complementan.

¿Es seguro vaciar toda la caché de Cloudflare?

Sí, no rompe nada. Lo único que pasa es que durante unos minutos el sitio va un poco más lento porque Cloudflare tiene que volver a generar la caché desde tu servidor. En sitios grandes con mucho tráfico, mejor purgar solo URLs concretas para no estresar el origen.

Hago el cambio, vacío todo, y aun así sigue viéndose la versión antigua. ¿Qué me queda?

Probablemente sea OPcache de PHP o caché de objetos del hosting. Pide al soporte del hosting que reinicie PHP y purgue object cache. Si el hosting no permite hacerlo, valora cambiarte: ese tipo de restricción no es propia de hosting profesional.

Ataca las capas de caché en orden y nunca purgues todo a ciegas

El error más común al pelearse con este problema es purgar todas las capas de caché de golpe sin saber en cuál estaba el problema. Funciona, pero no aprendes nada y la próxima vez que pase volverás al mismo punto sin pistas. El método correcto es ir capa a capa: empezar por el navegador, subir al plugin de caché del sitio, luego al CDN, después a la caché de objetos del servidor y solo al final a OPcache y DNS. Con esa secuencia, en la mayoría de casos identificas la capa culpable en menos de cinco minutos y aprendes a evitarla la próxima vez. Y, sobre todo, te ahorras tener que purgar toda la caché del sitio cuando bastaba con un Ctrl+F5 en tu navegador.

/por

Por qué WordPress no me deja instalar plugins: 7 causas y cómo solucionarlo

Vas al panel de WordPress, entras en Plugins → Añadir nuevo, eliges el que quieres instalar, pulsas «Instalar ahora» y… nada. O sale un error de permisos. O pide credenciales FTP que no tienes. O directamente desaparece el botón de instalación. WordPress no te deja instalar plugins y la web entera depende de poder añadir uno concreto. La buena noticia es que las causas son siempre las mismas siete, y todas tienen solución en menos de quince minutos si sabes por dónde tirar.

En esta guía te explicamos las causas más habituales (de la más simple a la más técnica), cómo identificar cuál es la tuya y cómo resolverlas paso a paso sin romper la web.

Si no quieres entrar a tocar archivos del servidor o llevas dos horas intentándolo, lo recuperamos por ti con backup previo incluido.

Habla con nosotros

Síntomas habituales: cómo identificar tu caso

Antes de aplicar soluciones, conviene saber qué te está pasando exactamente. Estos son los cuatro escenarios típicos:

  • WordPress te pide credenciales FTP al pulsar «Instalar». Eso significa que la carpeta de plugins no tiene permisos de escritura para PHP.
  • Sale un error «DISALLOW_FILE_MODS» o desaparece el menú de instalar plugins por completo. Hay una constante en wp-config.php que está bloqueando cualquier modificación de archivos.
  • Te dice «No tienes permisos suficientes» aunque seas administrador. Tu rol de usuario ha perdido la capacidad install_plugins, probablemente por culpa de un plugin de seguridad o multisite.
  • El plugin se descarga pero no se descomprime, o sale un error genérico. Suele ser por falta de espacio en disco, límite de memoria PHP agotado o un timeout del servidor.

1. Permisos de archivo incorrectos en /wp-content/plugins/

Es la causa más habitual. Cuando WordPress intenta crear la carpeta del plugin y no tiene permisos, te pide credenciales FTP como plan B. La solución correcta es ajustar los permisos del directorio:

  • Las carpetas dentro de /wp-content/plugins/ deben tener permisos 755.
  • Los archivos .php dentro deben tener 644.
  • El propietario debe ser el usuario que ejecuta PHP en tu hosting (suele ser www-data, nobody o un usuario específico de tu cuenta).

Si tienes acceso SSH al servidor:

find /ruta/a/wordpress/wp-content/plugins/ -type d -exec chmod 755 {} \;
find /ruta/a/wordpress/wp-content/plugins/ -type f -exec chmod 644 {} \;

Si no tienes SSH, hazlo por FTP con FileZilla: clic derecho en la carpeta plugins → Permisos del archivo → 755, marca «Aplicar a subdirectorios» y selecciona «Aplicar solo a directorios». Luego repítelo con 644 marcando «Aplicar solo a archivos».

2. Constantes en wp-config.php que bloquean cambios

Algunos hostings o algunos administradores anteriores añaden constantes en wp-config.php que bloquean cualquier modificación de archivos por seguridad. Busca estas líneas:

define('DISALLOW_FILE_MODS', true);
define('DISALLOW_FILE_EDIT', true);

La primera desactiva por completo la instalación, actualización y borrado de plugins y temas desde el panel. Si está en true, cámbiala a false o coméntala con // al principio. La segunda solo bloquea el editor de código de WordPress, no afecta a la instalación pero conviene tenerla controlada.

Una vez modificado wp-config.php, recarga el panel y verás reaparecer las opciones de instalar plugins.

3. Tu usuario no tiene la capacidad install_plugins

Si eres administrador y aun así te dice que no tienes permisos suficientes, lo más probable es que un plugin de seguridad (iThemes Security, Wordfence) o una configuración multisite te haya retirado la capacidad. Tienes dos opciones:

  • Si es una instalación multisite, solo los Super Admins de la red pueden instalar plugins, no los administradores de subsites. Pide a un Super Admin que te lo instale, o que active tu rol como Super Admin.
  • Si es una instalación normal, comprueba los plugins de seguridad activos. Wordfence, iThemes Security y Solid Security tienen opciones para bloquear la instalación de plugins. Desactívalas temporalmente.

Si nada de eso es tu caso, restablece tu rol con un fragmento en functions.php:

add_action('init', function() {
    $role = get_role('administrator');
    if ($role) {
        $role->add_cap('install_plugins');
        $role->add_cap('activate_plugins');
        $role->add_cap('update_plugins');
    }
});

Sube el archivo, visita la home una vez (eso ejecuta la línea), y bórralo inmediatamente para no dejarlo permanente.

4. Memoria PHP agotada (memory_limit)

Si el plugin se descarga pero no llega a descomprimirse, suele ser falta de memoria PHP. El valor por defecto de muchos hostings (32 MB o 64 MB) se queda corto para plugins grandes. Súbelo a 256 MB añadiendo esto en wp-config.php, justo antes de la línea «Eso es todo, deja de editar»:

define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '256M');

Si después de esto sigue fallando, el problema está en la configuración global de PHP. Pide a tu hosting que suba memory_limit a 256 M o más, o edítalo tú mismo si tienes acceso al php.ini.

5. Falta de espacio en disco

Menos habitual pero pasa: el plugin no se instala porque el hosting tiene el cupo de espacio lleno. Entra en el panel de tu hosting (cPanel, Plesk, panel personalizado) y comprueba el uso de disco. Si está al 90% o más, libera espacio borrando: copias de seguridad antiguas, imágenes huérfanas en /wp-content/uploads/, logs antiguos o vaciando la papelera de medios y entradas.

6. Modo de mantenimiento o instalación bloqueada

A veces WordPress queda atrapado en modo mantenimiento tras una actualización fallida y bloquea cualquier nueva instalación. La pista es un archivo llamado .maintenance en la raíz de tu WordPress. Bórralo por FTP y la web vuelve a funcionar.

Si lo que aparece es la pantalla «Actualizando, vuelve en breve» y no se quita, es exactamente el mismo problema: borrar .maintenance lo arregla.

7. Hosting restrictivo o WordPress gestionado (WordPress.com, WP Engine, Kinsta)

Algunos hostings «WordPress gestionado» bloquean la instalación de plugins por política de la empresa, no por error técnico. WordPress.com (el servicio de Automattic, no WordPress.org) solo permite instalar plugins en planes Business o superiores. WP Engine y Kinsta tienen listas negras de plugins que no se pueden instalar nunca por seguridad.

Si estás en uno de esos casos, comprueba la política del hosting antes de seguir buscando soluciones técnicas. La única salida es actualizar el plan o migrar a un hosting con menos restricciones.

Preguntas frecuentes

¿Puedo instalar un plugin manualmente por FTP si el panel no me deja?

Sí. Descarga el ZIP del plugin, descomprímelo en tu ordenador y sube la carpeta resultante a /wp-content/plugins/ por FTP. Luego desde el panel ve a Plugins, lo verás listado y solo tienes que activarlo. Es la solución de emergencia más rápida.

¿Es seguro modificar wp-config.php yo mismo?

Sí, siempre que hagas backup del archivo antes. wp-config.php es texto plano: descarga el original, modifícalo con un editor de texto (Notepad++, Sublime, VS Code, nunca Word) y súbelo de vuelta. Si algo va mal, restauras el original.

Tengo permisos correctos y no me pide FTP, pero el plugin no se instala. ¿Qué más puedo probar?

Revisa los logs de PHP del servidor (suelen estar en /logs/ o en el panel del hosting). El error exacto suele aparecer ahí. Causas habituales: timeout (sube max_execution_time), límite de upload (sube post_max_size y upload_max_filesize).

¿Mi tema puede impedir la instalación de plugins?

Sí, algunos temas premium meten restricciones en functions.php que limitan las capacidades de usuario. Activa temporalmente el tema por defecto (twentytwentyfour) para descartarlo.

¿Y si el plugin pone que no es compatible con mi versión de WordPress?

Ese es un caso distinto: el plugin no funciona con tu versión. Actualiza WordPress al último estable o busca un plugin alternativo. Forzar la instalación de un plugin incompatible casi siempre rompe la web.

Reglas de oro al desbloquear la instalación de plugins en WordPress

Quedarse sin poder instalar plugins parece un problema gordo pero casi nunca lo es. Lo importante es atacarlo en el orden correcto: empezar por la causa más simple (permisos y FTP), bajar a las constantes en wp-config.php, comprobar los plugins de seguridad activos y solo después tocar memoria PHP o espacio en disco. La regla de oro es siempre hacer backup antes de tocar archivos del servidor: si vas a modificar wp-config.php, descárgalo primero. Si vas a ajustar permisos masivos, asegúrate de que tienes la ruta correcta. Y si llegas al punto de tocar functions.php, recuerda borrar el código de emergencia inmediatamente después de que cumpla su función. Con esas precauciones, en quince minutos vuelves a tener el panel de plugins operativo y sin riesgo de romper la web.

/por

No puedo acceder a wp-admin: 7 formas de recuperar el acceso a tu WordPress

,

Pocas cosas generan más estrés a un dueño de web que llegar a tudominio.com/wp-admin y descubrir que no puedes acceder a tu WordPress. La pantalla puede mostrar credenciales incorrectas aunque las introduzcas bien, una redirección infinita, una pantalla en blanco o un escueto error 403. Lo bueno es que en la inmensa mayoría de casos hay solución, y rara vez hay que reinstalar nada.

Esta guía recoge los siete métodos que más usamos para recuperar acceso a un WordPress, ordenados de menos a más invasivo. Empieza por el primero y baja solo si no funciona.

¿Tu web está parada y necesitas recuperar el acceso ya? Resolvemos accesos bloqueados en menos de dos horas, con backup previo incluido.

Habla con nosotros

Síntomas: error de credenciales, redirección infinita, pantalla blanca o 403

Antes de probar soluciones, identifica qué te está pasando exactamente. Esto ahorra tiempo:

  • «Nombre de usuario o contraseña no válidos» → la contraseña se ha corrompido o alguien la cambió. Empieza por el método 1.
  • Redirección infinita entre /wp-admin/ y /wp-login.php → casi siempre es un plugin o el archivo .htaccess. Métodos 4 y 6.
  • Pantalla en blanco al hacer login → conflicto de plugin o tema, o memoria PHP agotada. Métodos 4 y 5.
  • Error 403 / Forbidden → suele ser un plugin de seguridad que ha bloqueado tu IP. Método 4.
  • «No se puede acceder a este sitio web» → el problema no es WordPress, es DNS o servidor. Método 7.

Si lo tuyo es que tu web ha sido hackeada y por eso no puedes entrar, antes de probar nada lee WordPress hackeado: cómo recuperarlo paso a paso. Y si la sintomatología es de redirecciones extrañas, también te conviene problemas de redirección en WordPress.

1. Restablecer la contraseña por email

Lo obvio que casi nadie prueba bien. En la pantalla de login pulsa «¿Has olvidado tu contraseña?» e introduce tu correo o nombre de usuario. WordPress te enviará un enlace para crear una nueva.

Si el correo no llega: comprueba la carpeta de spam, espera 5 minutos (a veces tardan) y, si sigue sin aparecer, pasa al método 2 — probablemente tu WordPress no está enviando correos. De hecho, este es uno de los síntomas que tratamos en WordPress no envía correos: causas y cómo solucionarlo con SMTP.

2. Cambiar la contraseña desde phpMyAdmin

Si el correo de recuperación no funciona, la opción más rápida es cambiar la contraseña directamente en la base de datos. Para esto necesitas acceso al panel de hosting (cPanel, Plesk, hosting personalizado):

  1. Entra en phpMyAdmin desde tu panel de hosting y selecciona la base de datos de WordPress.
  2. Abre la tabla wp_users (el prefijo puede variar: wpxx_users).
  3. Localiza tu usuario y pulsa «Editar».
  4. En el campo user_pass, escribe la nueva contraseña en texto plano.
  5. Importante: en el desplegable de función de la fila user_pass selecciona MD5. Esto encripta la contraseña como WordPress espera.
  6. Pulsa «Continuar» para guardar y prueba a entrar con la nueva contraseña.

Si tu usuario no aparece en wp_users o la contraseña sigue sin funcionar tras esto, es probable que el problema no sea la contraseña en sí. Pasa al método 3.

3. Crear un nuevo usuario administrador vía functions.php

Cuando todo lo demás falla, puedes crear un nuevo usuario admin añadiendo unas líneas al archivo functions.php de tu tema activo (acceso vía FTP):

add_action('init', function() {
    $username = 'inicionet_admin';
    $password = 'cambiar_esta_contraseña_segura';
    $email = 'tu@correo.com';
    if (!username_exists($username) && !email_exists($email)) {
        $user_id = wp_create_user($username, $password, $email);
        $user = new WP_User($user_id);
        $user->set_role('administrator');
    }
});

Sube el archivo, visita la home una vez (eso ejecuta la creación), entra con el nuevo usuario y borra estas líneas inmediatamente para que no se vuelva a crear el usuario y para no dejar credenciales en el código. Una vez dentro, podrás recuperar tu cuenta original.

4. Desactivar todos los plugins por FTP

Cuando el síntoma es pantalla blanca, redirección infinita o error 500 al iniciar sesión, casi siempre es un plugin que ha entrado en conflicto. Por FTP o desde el gestor de archivos del hosting:

  1. Navega a /wp-content/plugins/.
  2. Renombra esa carpeta a plugins_off o plugins.bak.
  3. WordPress detectará que no hay plugins y los desactivará todos a la vez.
  4. Intenta entrar a /wp-admin/. Si entras, vuelve a renombrar la carpeta a plugins y reactívalos uno a uno desde el panel para identificar el culpable.

Si el problema venía de un plugin de seguridad que te había bloqueado por IP (Wordfence, iThemes Security, Limit Login Attempts), entrarás sin problema y podrás retirarte de la lista negra desde el panel del plugin.

5. Volver al tema por defecto por FTP

Si después de desactivar plugins sigues sin entrar, el problema puede estar en el tema. La solución es la misma idea, pero con la carpeta del tema:

  1. Por FTP, ve a /wp-content/themes/.
  2. Renombra la carpeta de tu tema activo (la verás por su nombre).
  3. WordPress activará automáticamente el tema por defecto disponible (twentytwentyfour, twentytwentythree, etc.).
  4. Intenta entrar al panel. Si funciona, el problema estaba en tu tema (probablemente en functions.php).

Una vez dentro, restaura el nombre original del tema y revisa qué se cambió la última vez.

6. Comprobar el archivo .htaccess y regenerarlo

El archivo .htaccess en la raíz de tu WordPress controla las redirecciones y URLs amigables. Si está corrupto, puedes ver redirecciones infinitas o errores de servidor.

Por FTP, descarga .htaccess como copia de seguridad, bórralo del servidor y prueba a entrar. Si funciona, ve a Ajustes → Enlaces permanentes en el panel y pulsa «Guardar cambios» sin tocar nada — eso regenera un .htaccess limpio. Si no quieres entrar al panel, este es el contenido por defecto que puedes pegar:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

7. Cuando «no se puede acceder a este sitio web» — DNS y servidor

Si el navegador devuelve «no se puede acceder a este sitio web» o «ERR_CONNECTION_REFUSED», el problema no es WordPress, es de infraestructura:

  • Comprueba en downforeveryoneorjustme.com si la web está caída para todos o solo para ti.
  • Verifica que tu hosting esté operativo (panel de cliente o status page del proveedor).
  • Comprueba que el dominio no haya caducado y los DNS apunten al hosting correcto.
  • Si has cambiado de hosting recientemente, los DNS pueden tardar hasta 48 horas en propagarse.
  • Si todo lo anterior está bien y aún así no carga, contacta al soporte del hosting — es un problema en su infraestructura, no en tu WordPress.

Prevención: 2FA, Limit Login Attempts y backups automáticos

Una vez recuperado el acceso, dedica diez minutos a evitar que vuelva a pasar:

  • Activa la verificación en dos pasos (2FA) con un plugin como Wordfence o miniOrange.
  • Instala Limit Login Attempts Reloaded para bloquear intentos fuerza bruta contra tu login. Y añádete a una lista blanca de IPs si trabajas siempre desde el mismo sitio.
  • Configura backups automáticos diarios fuera del propio servidor (UpdraftPlus a Google Drive o Dropbox es una opción gratuita y suficiente para la mayoría de webs).
  • Revisa el listado de mejores plugins de seguridad WordPress y nuestra guía de cabeceras de seguridad HTTP en WordPress.
  • Si quieres una visión más amplia, no te pierdas seguridad en la nube.

Preguntas frecuentes

¿Pierdo contenido al desactivar plugins por FTP?

No. Renombrar la carpeta de plugins solo los desactiva temporalmente; el contenido y la configuración siguen intactos en la base de datos. Cuando reactivas la carpeta, todo vuelve.

¿Cómo sé qué plugin está dando problemas si tengo veinte instalados?

Tras renombrar la carpeta y entrar al panel, vuelve a renombrarla a ‘plugins’ (sin reactivarlos en bloque) y actívalos uno a uno, recargando wp-admin entre cada uno. Cuando vuelva el problema, el último que activaste es el culpable.

¿Puedo entrar a phpMyAdmin si solo tengo FTP?

No. phpMyAdmin requiere acceso al panel de hosting (cPanel/Plesk) o credenciales de la base de datos para acceso directo. Si solo tienes FTP, contacta al hosting o usa el método 3 (functions.php).

¿Cuándo es momento de reinstalar WordPress desde cero?

Casi nunca. La reinstalación completa solo merece la pena si tu WordPress está infectado por malware extendido por todo el código y no hay backup limpio. En el 99 % de bloqueos de acceso basta con uno de los siete métodos anteriores.

Empieza por lo simple antes de tocar la base de datos: reglas de oro al recuperar el acceso

Quedarse fuera del panel de WordPress es estresante pero rara vez catastrófico. La regla número uno es respetar el orden: empezar siempre por el método más simple (resetear la contraseña por email) y bajar solo si no funciona, porque cuanto más bajes en la lista, más invasiva es la solución y mayor el riesgo de romper algo que ahora sí funciona. La regla número dos es hacer copia de seguridad antes de tocar nada: si vas a editar la base de datos, exporta antes la tabla wp_users; si vas a modificar functions.php o el .htaccess, descárgalos primero por FTP. Y la regla número tres es la prevención. Una vez recuperado el acceso, dedica diez minutos a activar 2FA, instalar Limit Login Attempts y configurar backups automáticos fuera del propio servidor. Esos diez minutos son los que separan al dueño de web que pasa por esto una vez del que lo sufre cada seis meses.

/por