WordPress no carga por límite de inodos del hosting

Contexto del problema en WordPress

Un inodo representa un archivo, carpeta o enlace del sistema de ficheros. Por eso un WordPress puede tener espacio libre en disco y, aun así, dejar de funcionar si ha alcanzado el límite de inodos asignado por el hosting. Es una incidencia típica en sitios con muchas imágenes, cachés de página o de objeto mal gestionadas, copias de seguridad guardadas dentro de la propia cuenta o plugins que generan miles de archivos temporales.

En WordPress este límite afecta a operaciones críticas. Pueden fallar las actualizaciones del núcleo, de plugins o de temas, la creación de miniaturas, la subida de medios, la escritura de logs o sesiones y hasta el funcionamiento del correo local si el proveedor lo aloja en la misma cuenta. El síntoma visible suele ser que la web no carga o responde con errores ambiguos, cuando la causa real está en el sistema de archivos y no en el contenido publicado.

• El problema no depende solo de los gigabytes usados, sino del número total de elementos almacenados.
• Una instalación con pocas visitas puede agotarlos si acumula miles de archivos pequeños.
• Las carpetas de caché, backups y logs suelen ser responsables frecuentes.
• En sitios con WooCommerce también influyen sesiones, exportaciones y adjuntos.
• La resolución exige revisar el origen del consumo, no solo borrar por liberar espacio.

Diagnóstico inicial y señales útiles en ámbito general

Antes de borrar nada, conviene confirmar si el límite de inodos es realmente la causa principal. Las señales más habituales son avisos del panel de hosting, errores al subir archivos a la biblioteca multimedia, fallos en la actualización automática, copias de seguridad incompletas, correos que dejan de entregarse y respuestas 500 o 503 cuando WordPress intenta escribir ficheros temporales. También puede haber alertas de Search Console si Google detecta errores del servidor persistentes.

Las comprobaciones deben ser prudentes. Lo más seguro es revisar el panel del hosting, el uso de inodos por cuenta, las fechas de crecimiento y las carpetas con mayor número de elementos. Si hay acceso SSH o administrador de archivos, es mejor listar directorios y tamaños antes de eliminar. Activar depuración en WordPress debe hacerse de forma controlada para evitar mostrar errores en producción o generar todavía más archivos de log.

• Compruebe si el panel del hosting muestra porcentaje de inodos consumidos o límite alcanzado.
• Revise mensajes como file write failed, upload failed, unable to create directory o errores 500 tras cambios recientes.
• Observe picos de CPU o I/O asociados a tareas programadas, escaneos, backups o generación de caché.
• Contraste si hubo actualizaciones recientes de plugins, tema, PHP o ajustes del servidor.
• Evite borrar carpetas completas de wp-content, caché o correo sin inventario previo y sin copia.

Causas habituales y cómo confirmarlas

La causa más común es la acumulación masiva de archivos pequeños. WordPress genera miniaturas de imágenes, plugins de caché crean estructuras con miles de ficheros, algunas copias de seguridad se guardan dentro de la propia cuenta y ciertos plugins de seguridad o de registro añaden logs rotativos sin limpieza adecuada. También son frecuentes los residuos de migraciones, instalaciones antiguas en subcarpetas, entornos de prueba olvidados y archivos temporales de importación o exportación.

Confirmar la causa exige correlacionar fecha, carpeta y cambio reciente. Si el crecimiento se produjo tras instalar un plugin de caché, una herramienta de optimización de imágenes o un sistema de backup, suele verse en rutas como wp-content/cache, wp-content/uploads, directorios de respaldo o carpetas ocultas de sesiones y logs. Cuando la cuenta de correo comparte hosting, miles de mensajes pequeños también pueden disparar el consumo de inodos aunque la web parezca la única afectada.

• Backups locales acumulados dentro de wp-content o del home de la cuenta.
• Cachés de página, cachés de imágenes y archivos temporales que no se purgan.
• Subidas masivas de medios con demasiadas miniaturas o regeneraciones repetidas.
• Logs de depuración, escaneo, acceso o correo con rotación deficiente.
• Cuentas de correo, webs antiguas, staging olvidado o malware que crea miles de ficheros.

Seguridad, malware y spam

Aunque un límite de inodos no implica por sí mismo una intrusión, sí puede ser una señal indirecta. Algunos incidentes de seguridad generan miles de archivos para ocultar puertas traseras, crear spam, desplegar scripts en subdirectorios o dejar copias del malware con nombres variables. También puede ocurrir con plugins vulnerables, credenciales filtradas, permisos inseguros o cargas no controladas desde formularios.

La respuesta debe ser proporcionada. Antes de limpiar, haga copia de la evidencia disponible si el acceso lo permite, revise usuarios administradores, cambie contraseñas, fuerce la salida de sesiones y compruebe si hay archivos extraños en uploads, cache, mu-plugins, themes o carpetas temporales. El hardening básico, las actualizaciones controladas y la reducción de superficie de ataque ayudan a prevenir que el mismo patrón vuelva a consumir inodos y recursos.

• Señales útiles son archivos recientes con nombres aleatorios, cron anómalo o spam saliente.
• Un plugin vulnerable puede dejar scripts ocultos en uploads o subcarpetas poco visibles.
• La rotación de contraseñas debe incluir WordPress, hosting, FTP, base de datos y correo.
• Revise permisos y usuarios para detectar accesos innecesarios o persistencia maliciosa.
• No borre evidencia crítica sin copia ni mezcle limpieza de malware con cambios masivos de estructura.

Rendimiento y estabilidad

El exceso de inodos impacta en la estabilidad porque el servidor necesita gestionar directorios cada vez más pesados y WordPress falla al crear nuevos ficheros. Eso repercute en tiempos de respuesta, tareas programadas, caché, regeneración de miniaturas, exportaciones y procesos internos del plugin o del tema. En alojamiento compartido, además, el problema suele mezclarse con límites de CPU, memoria, entrada y salida de disco.

La solución sostenible no consiste solo en limpiar una vez. Conviene revisar la política de caché, limitar la retención de logs, sacar las copias de seguridad fuera de la cuenta principal, controlar la generación de miniaturas y auditar la necesidad real de cada plugin. Cuando el patrón del sitio exige muchos archivos, puede ser razonable valorar un plan o arquitectura distintos, siempre según proveedor y configuración concreta.

• La saturación de inodos puede romper cron, sesiones y tareas periódicas aunque la web siga cargando a ratos.
• Una caché mal configurada puede mejorar velocidad durante unos días y desestabilizar después.
• Los logs enormes o demasiado fragmentados afectan al mantenimiento y al diagnóstico.
• Las miniaturas innecesarias multiplican archivos y aumentan el coste de copia y restauración.
• La monitorización posterior es clave para comprobar que el consumo vuelve a una tendencia normal.

Plugins, temas y actualizaciones

Los plugins y temas son una fuente directa de crecimiento de inodos. Los de caché, backups, seguridad, importación, formularios, optimización de imágenes y registro de actividad suelen generar muchos ficheros auxiliares. Una actualización fallida puede dejar restos de paquetes temporales o directorios duplicados. También ocurre cuando se suben versiones manuales por FTP sin limpiar antes componentes obsoletos.

La buena práctica es trabajar con staging cuando sea posible, documentar cambios, validar compatibilidades y comprobar después el efecto real en archivos, rendimiento y errores. Si aparece un conflicto tras actualizar, lo prudente es aislarlo con una secuencia ordenada, sin desactivar en bloque a ciegas ni borrar carpetas de plugin sin saber si almacenan datos operativos o de recuperación.

• Pruebe actualizaciones en staging cuando el sitio sea crítico o tenga comercio electrónico.
• Mantenga un registro de versión de WordPress, PHP, plugins y tema antes de intervenir.
• Verifique si un plugin crea backups, caché o logs dentro de la misma cuenta.
• Tras actualizar, revise si quedaron directorios temporales, paquetes zip o archivos duplicados.
• Si hay conflicto, desactive con método y conserve trazabilidad para poder revertir con criterio.

Hosting, dominio y correo en España

En España es frecuente que una sola cuenta agrupe web, correo, bases de datos y a veces varios dominios o subdominios. Eso hace que el límite de inodos se consuma entre distintos servicios, no solo por WordPress. El panel del proveedor puede mostrar el dato total de la cuenta, mientras que la causa real está en buzones con muchos correos pequeños, en una caché de servidor, en directorios temporales o en restos de migraciones anteriores.

También conviene revisar DNS, SSL, versión de PHP, manejadores de caché del servidor y restricciones del plan. Si el sitio usa CDN, firewall o correo transaccional externo, la configuración puede mitigar síntomas, pero no elimina el límite local de inodos. Por eso cada proveedor tiene matices de panel, nomenclatura y rutas, y la actuación debe adaptarse a sus condiciones concretas sin dar nada por supuesto.

• Compruebe si el panel separa consumo web, correo, cron y archivos temporales.
• Revise DNS y SSL solo como parte del contexto, porque pueden añadir errores paralelos al problema principal.
• Verifique versión de PHP y módulos si la web falla tras limpieza o tras una actualización forzada.
• Consulte si la caché de servidor o del panel genera archivos persistentes bajo la cuenta.
• Si hay correo transaccional o formularios, revise colas, rebotes y buzones que compartan recursos.

Pruebas, accesos y documentación técnica

Para resolver bien esta incidencia hace falta evidenciar qué pasó, cuándo empezó y qué cambió. Sin esa trazabilidad se corre el riesgo de liberar inodos hoy y perder tiempo mañana ante la misma caída. La documentación mínima debería permitir comparar el antes y el después, justificar la limpieza realizada y detectar si el crecimiento se reanuda tras unas horas o unos días.

Los accesos útiles suelen ser panel de hosting, WordPress administrador, gestor de archivos o SSH y, cuando proceda, acceso a correo o DNS. Si intervienen varias personas, conviene registrar qué usuario hizo cada cambio y en qué momento. En un servicio técnico como el de reparawordpress.com, esta base documental reduce riesgos y evita decisiones irreversibles tomadas con prisa.

• Trazabilidad de cambios recientes con registro de actualizaciones, lista de plugins activos y changelog disponible.
• Evidencias técnicas como logs, capturas, URLs afectadas, alertas del hosting y mensajes exactos de error.
• Inventario de carpetas con más archivos, fecha de crecimiento y tipo de contenido acumulado.
• Estado de las copias de seguridad, export de base de datos e informes de seguridad si existen.
• Accesos temporales y documentados a hosting, WordPress, SFTP o SSH para actuar con control de cambios.

Plan de acción ordenado en ámbito general

El orden importa. Primero conviene contener el impacto para evitar más escritura en disco, después asegurar copia o evidencia mínima, luego diagnosticar por carpetas y procesos, y solo entonces corregir. Una vez liberados inodos, hay que verificar la web, el panel, el correo y las tareas automáticas. Si no se valida todo el flujo, pueden quedar errores latentes que reaparezcan en la siguiente actualización o en el siguiente pico de actividad.

Tras la corrección inicial, la monitorización es parte del trabajo, no un añadido opcional. Debe revisarse la tendencia de crecimiento, la respuesta del sitio, el estado de los backups y si el origen del problema ha sido realmente desactivado, reconfigurado o movido fuera del hosting principal. En algunos casos bastará con higiene técnica; en otros hará falta replantear el plan o la arquitectura.

• Contenga la incidencia pausando tareas pesadas como backups, escaneos o regeneraciones automáticas.
• Genere una copia o al menos un inventario de evidencia antes de eliminar contenido.
• Identifique la carpeta y el proceso causante del crecimiento de inodos.
• Corrija la causa con limpieza selectiva, reconfiguración o traslado de archivos fuera de la cuenta.
• Verifique web, admin, subidas, actualizaciones, formularios, correo y cron, y monitorice después.

Si ya se ha tocado algo o hay urgencia

Es muy habitual que, antes de pedir ayuda, alguien haya instalado un plugin de seguridad, restaurado una copia parcial, cambiado de hosting, editado functions.php, borrado un plugin crítico o intentado limpiar malware sin copia. En una urgencia esto es comprensible, pero cada intervención puede alterar la evidencia, mover el problema de sitio o añadir un fallo nuevo que complique distinguir entre causa y consecuencia.

La recomendación es detener cambios impulsivos y reconstruir una línea temporal. Anote qué se tocó, quién lo hizo y qué efecto tuvo. Si hubo restauración parcial, compare archivos y base de datos. Si se cambió de hosting, confirme si el límite de inodos se resolvió de verdad o solo se enmascaró. Y si se editó código manualmente, revise sintaxis y alcance antes de atribuir todos los errores al alojamiento.

• Si se instaló un plugin de seguridad, revise si ha creado cuarentenas, logs o escaneos que aumentan archivos.
• Si se restauró una copia parcial, compruebe desajustes entre base de datos, medios y plugins activos.
• Si se cambió de hosting, valide límites nuevos, rutas, permisos, DNS y correo antes de cerrar el caso.
• Si se tocó functions.php o se borró un plugin crítico, descarte errores de código y dependencias rotas.
• Si se intentó limpiar malware sin copia, preserve lo que quede de evidencia y documente cada hallazgo.

Preguntas frecuentes

Estas dudas suelen repetirse cuando WordPress deja de cargar por consumo de inodos. Las respuestas dependen del proveedor y de la configuración, pero sirven como orientación inicial.

P: ¿Qué diferencia hay entre espacio en disco e inodos?

R: El espacio en disco mide cuánto ocupan los datos. Los inodos cuentan cuántos archivos y carpetas existen. Puede quedar espacio libre y, aun así, no poder crear ni un archivo más.

P: ¿Borrar imágenes grandes siempre soluciona el problema?

R: No necesariamente. Si el exceso viene de miles de archivos pequeños, logs, caché o correo, borrar unas pocas imágenes grandes puede liberar megabytes pero no suficientes inodos.

P: ¿Puede afectar al correo aunque el error parezca solo de WordPress?

R: Sí. Si el correo comparte cuenta de hosting, también consume archivos e inodos. Un buzón saturado o con mucha retención puede contribuir al bloqueo general.

P: ¿Es buena idea activar WP_DEBUG en producción?

R: Solo con cautela y de forma temporal. Bien configurado ayuda a diagnosticar, pero también puede generar más logs o exponer errores si no se controla correctamente.

P: ¿Cuándo conviene pedir soporte técnico?

R: Cuando no esté claro qué carpeta dispara el consumo, haya sospecha de malware, se mezclen fallos de web y correo o ya se hayan hecho cambios sin un resultado estable.