Tu web tiene veinte páginas, unas cuantas fotografías y quizá una tienda pequeña. A simple vista, no parece que pueda ocupar demasiado.
Entonces llega el aviso del hosting: “Has alcanzado el límite de espacio en disco.”
Entras en el panel y descubres que la cuenta utiliza 15, 30 o 50 GB. Puede que incluso hayas ampliado el alojamiento hace unos meses y vuelvas a estar cerca del límite.
La reacción lógica es buscar qué borrar.
Pero esa no debería ser la primera pregunta.
La pregunta correcta es: ¿qué está ocupando realmente ese espacio y por qué ha crecido?
En WordPress pueden acumularse copias de seguridad, imágenes y sus diferentes tamaños, archivos de caché, registros de errores, datos de plugins, instalaciones antiguas y otros archivos que ni siquiera forman parte de la web que estás viendo.
Borrar sin identificar primero el origen puede liberar espacio durante unas horas, no solucionar nada o, en el peor de los casos, eliminar datos necesarios para recuperar o hacer funcionar la web.
Vamos a diagnosticarlo en un orden más seguro.
El tamaño visual de una web dice muy poco sobre el espacio que utiliza en el servidor.
Una página que muestra diez imágenes no significa necesariamente que existan solo diez archivos de imagen. Cuando subes una fotografía, WordPress puede generar automáticamente varios tamaños derivados que utilizará según dónde y cómo se muestre. Los temas y plugins también pueden registrar tamaños adicionales. WordPress documenta este comportamiento como parte normal de su gestión de medios.
Además, el alojamiento puede contener mucho más que las páginas que ven tus visitantes:
Por eso una web corporativa aparentemente sencilla puede convivir con una cuenta de hosting que ha ido creciendo durante años.
Y por eso tampoco conviene empezar instalando un plugin de “limpieza”.
Primero hay que descubrir dónde están los gigabytes.
“Te has quedado sin espacio” puede resumir situaciones distintas.
Es el volumen de almacenamiento que ocupa la cuenta: archivos, bases de datos y, dependiendo de cómo esté configurado el proveedor, otros elementos del alojamiento.
En paneles como cPanel existe una estadística específica de Disk Usage que muestra el espacio utilizado por la cuenta.
También puede existir un límite sobre la cantidad de archivos y directorios.
cPanel, por ejemplo, distingue entre Disk Usage y File Usage; esta última métrica representa el número de archivos y directorios —inodos— utilizados por la cuenta.
La diferencia importa.
Puedes tener miles o millones de archivos pequeños y alcanzar un límite de ficheros sin haber consumido una cantidad espectacular de gigabytes. Una caché muy fragmentada, sesiones, archivos temporales u otros procesos pueden contribuir a ello.
Así que, antes de investigar WordPress, mira el mensaje exacto del proveedor:
¿has alcanzado almacenamiento, número de archivos o ambos?
Si no queda claro, pregúntalo.
No hace falta empezar analizando cada archivo.
La forma más eficiente es trabajar de mayor a menor.
Desde el panel del alojamiento, busca herramientas llamadas Uso de disco, Disk Usage, File Manager, Storage o similares. El nombre cambia entre proveedores.
El objetivo inicial es separar grandes bloques:
wp-content?Si una sola carpeta utiliza 25 GB de los 30 GB de la cuenta, ya has reducido enormemente el problema.
A partir de ahí puedes investigar ese directorio.
Desde wp-admin puedes revisar algunas cosas, pero no tendrás la misma visibilidad sobre el sistema de archivos, las cuotas, las bases de datos o las copias del proveedor.
Si te encuentras en esa situación, conviene resolver primero quién controla el alojamiento y qué accesos existen. En arreglotuweb.com explicamos qué puedes hacer cuando tienes acceso a WordPress pero no al hosting. Tengo acceso a WordPress, pero no al hosting: qué puedes hacer y qué necesitas recuperar
Esta es una de las primeras cosas que merece la pena comprobar.
Un sistema de backups puede crear archivos grandes. Si además conserva varias generaciones dentro de la misma cuenta, el almacenamiento puede multiplicarse.
Imagina una instalación que ocupa 4 GB.
Si guardas varias copias completas dentro del mismo hosting, puedes terminar usando mucho más espacio en backups que en la propia web.
Eso no significa que debas borrarlos inmediatamente.
Antes necesitas saber:
No elimines el único backup válido para solucionar un problema de espacio.
Además, guardar todas las copias únicamente junto a la web tiene una debilidad evidente: un problema grave en esa cuenta puede afectar tanto al original como a las copias.
En nuestra guía sobre copias de seguridad de WordPress explicamos por qué tener varios archivos llamados “backup” no equivale a tener un sistema de recuperación fiable.
La cuestión no es acumular ZIP.
Es poder recuperar la web cuando haga falta.
wp-content/uploadsEn una instalación convencional, WordPress utiliza el directorio de uploads para los archivos multimedia. La ruta predeterminada está dentro de wp-content/uploads, aunque WordPress permite modificarla.
En webs con años de funcionamiento esta carpeta puede convertirse en una de las zonas más grandes.
Y hay una razón que no siempre resulta evidente.
Al subir una imagen, WordPress genera metadatos y distintos tamaños derivados. Temas y plugins también pueden solicitar tamaños adicionales.
Por eso 5.000 fotografías en la biblioteca multimedia pueden representar bastantes más de 5.000 archivos físicos.
Esto no significa que esos tamaños sean “basura”. Muchos existen porque la web los utiliza para servir imágenes adecuadas en distintos contextos.
Tampoco significa que debas entrar por FTP y empezar a eliminar versiones que tengan nombres parecidos.
Podrías provocar imágenes rotas o eliminar archivos que todavía utiliza el sitio.
Lo que sí merece la pena investigar es:
uploads;Si el problema son imágenes, la solución sostenible no es únicamente eliminar archivos antiguos. También hay que evitar que la biblioteca vuelva a crecer de forma innecesaria.
La caché existe precisamente para almacenar información que pueda reutilizarse y evitar trabajo repetitivo.
Por definición, algunos sistemas de caché crean archivos.
Eso normalmente es positivo para el rendimiento. El problema aparece si esos archivos dejan de limpiarse correctamente, se generan en cantidades inesperadas o una configuración produce un crecimiento continuo.
Una pista útil es encontrar un directorio de caché que ocupa varios gigabytes y sigue creciendo.
Pero aquí también hay una diferencia importante entre:
“He encontrado una caché grande”
y
“Puedo borrar esta carpeta sin consecuencias”.
No todas las herramientas utilizan la misma estructura ni gestionan sus archivos del mismo modo.
La opción más segura suele ser identificar primero qué sistema creó la caché y utilizar su propio mecanismo de purgado cuando exista.
Si además estás investigando lentitud, no confundas almacenamiento con rendimiento. Una web que ocupa mucho disco no es automáticamente una web lenta, y una web lenta no se arregla necesariamente contratando más almacenamiento. En cómo saber si WordPress va lento por el hosting o por la propia web explicamos cómo separar ambos problemas.
Los registros son útiles.
Cuando una web genera un error, un pago falla o una integración no responde, un log puede ser precisamente lo que permita averiguar qué ocurrió.
El problema aparece cuando el mismo evento se registra una y otra vez durante días o semanas.
WooCommerce incorpora su propio sistema de logging. Con el almacenamiento por archivos, sus registros se guardan por defecto en un subdirectorio wc-logs dentro del directorio de uploads. WooCommerce también dispone de políticas de rotación y retención configurables.
Desde el administrador pueden consultarse en:
WooCommerce → Estado → Registros
Si encuentras logs enormes o una misma fuente generando registros constantemente, la pregunta importante no es únicamente:
“¿Los puedo borrar?”
Es:
“¿Por qué se están generando tantos?”
Eliminar un registro puede recuperar espacio. No corrige necesariamente el error que vuelve a crearlo.
WooCommerce recomienda precisamente investigar los logs recurrentes que están llenando los archivos en lugar de limitarse a ignorarlos.
Lo mismo se aplica a otros registros del servidor o a debug.log si la depuración de WordPress ha quedado activa. WooCommerce documenta que, cuando WP_DEBUG_LOG está configurado para escribir en archivo, el registro de depuración puede encontrarse en wp-content/debug.log.
Un debug.log que crece continuamente es una señal para diagnosticar el problema, no un sistema de almacenamiento que debamos vaciar cada viernes.
El espacio ocupado por WordPress no está únicamente en sus carpetas.
La base de datos contiene buena parte de la información con la que funciona el sitio. WordPress utiliza tablas para contenidos, metadatos, usuarios, comentarios, opciones y otras clases de información; los plugins también pueden crear sus propias tablas.
En una web corporativa pequeña puede representar una parte relativamente modesta del total.
En otros proyectos puede crecer considerablemente:
Si descubres que el problema está en MySQL/MariaDB, no lo soluciones borrando tablas cuyo nombre no reconoces.
Una tabla desconocida puede seguir siendo necesaria.
Tenemos una guía específica para limpiar la base de datos de WordPress sin tocar código donde explicamos qué puede acumularse y por qué conviene hacer una copia comprobada antes de eliminar datos.
El objetivo de este diagnóstico es identificar el responsable del crecimiento, no convertir phpMyAdmin en una papelera.
Esta causa es fácil de pasar por alto porque no siempre aparece dentro de la instalación principal.
Puedes descubrir directorios con nombres como:
old
backup
staging
dev
web-antigua
public_html_old
o incluso otro dominio que nadie recuerda.
El nombre de una carpeta, por sí solo, no demuestra que se pueda borrar.
Una copia antigua podría ser:
Antes de eliminarla conviene averiguar de cuándo es, quién la creó, si recibe tráfico y si contiene algo que no está en producción.
Esto tiene además una dimensión de mantenimiento y seguridad: acumular instalaciones que nadie mantiene añade complejidad y hace más difícil saber qué existe realmente dentro de la cuenta.
Un buen mantenimiento de WordPress no consiste únicamente en pulsar “Actualizar”; también implica conocer el estado real de la infraestructura y detectar problemas antes de que terminen afectando a la web.
Hay un error de interpretación bastante habitual:
“Mi cuenta de hosting ocupa 20 GB, así que WordPress ocupa 20 GB.”
No necesariamente.
Si el correo de la empresa está alojado dentro de la misma cuenta, buzones con años de mensajes y archivos adjuntos pueden representar una parte considerable del almacenamiento.
Lo mismo puede ocurrir con otras webs o dominios incluidos en el mismo plan.
Por eso es importante distinguir:
espacio utilizado por WordPress
de
espacio utilizado por toda la cuenta de hosting.
Si public_html ocupa 2 GB pero el panel dice que la cuenta consume 25 GB, seguir limpiando WordPress probablemente no sea la mejor investigación.
Aquí conviene ser especialmente prudente.
Un archivo desconocido no es automáticamente prescindible.
Puede pertenecer a:
Y un crecimiento inexplicable también puede justificar revisar si existe una incidencia técnica o de seguridad.
Antes de eliminar un archivo grande intenta determinar:
Si no puedes identificarlo con suficiente confianza, detenerse es más sensato que probar suerte.
Cuando el hosting está al 99 %, la presión por actuar deprisa es comprensible.
Pero hay atajos que pueden convertir un problema de almacenamiento en una web caída.
WordPress no está lleno porque wp-admin tenga demasiados archivos.
Primero averigua para qué sirven y si contienen datos que deban conservarse.
Puedes dejar páginas con recursos rotos o eliminar originales que después necesites.
Tamaño no equivale a inutilidad.
Liberar cinco gigabytes perdiendo tu única vía de recuperación es un mal intercambio.
A veces contratar más espacio es totalmente razonable.
Pero si una web ha pasado de 5 a 25 GB porque cada noche añade otra copia local, ampliar a 50 GB solo retrasa la siguiente alerta.
Si has recibido un aviso de espacio, este es un buen orden de revisión:
Registra:
Determina cuánto corresponde aproximadamente a:
En especial:
wp-content/uploads;No supongas que los archivos son todo el problema.
Esta es la pregunta decisiva.
Encontrar 8 GB de logs es útil.
Descubrir que un mismo error añade cientos de megabytes cada día es mucho más útil.
Especialmente si vas a eliminar algo más importante que cachés regenerables.
El orden importa.
Primero evita que el problema se reproduzca. Después limpia lo acumulado que ya hayas identificado como prescindible.
No existe una cifra universal que permita decir que una instalación “debería” ocupar 500 MB, 2 GB o 10 GB.
Una web corporativa con pocas imágenes y una tienda con miles de productos no son comparables.
Tampoco lo son dos webs visualmente similares si una conserva diez años de medios, varias copias locales e historiales de plugins y la otra acaba de crearse.
La comparación útil no es con una cifra genérica encontrada en Internet.
Es con tu propia web a lo largo del tiempo.
Si una instalación llevaba meses alrededor de 4 GB y en dos semanas pasa a 15 GB sin que hayas importado miles de imágenes ni realizado otro cambio que lo explique, merece una investigación.
El crecimiento inesperado suele proporcionar más información que el tamaño absoluto.
Pueden ser ambas cosas.
Una web puede haber crecido legítimamente y necesitar más almacenamiento. Es perfectamente normal que una tienda con más productos, pedidos y fotografías necesite más recursos que hace tres años.
Pero contratar más espacio debería ser una decisión tomada después de entender qué estás almacenando.
Podemos resumirlo así:
Si el espacio lo ocupan datos necesarios y el crecimiento es razonable, probablemente necesites más capacidad.
Si lo ocupan copias duplicadas, caches descontroladas, logs recurrentes o restos identificados, conviene corregir primero esa situación.
Si no sabes qué lo ocupa, todavía no tienes información suficiente para decidir.
Y si además del almacenamiento existen problemas de CPU, memoria, lentitud o caídas, no los mezcles automáticamente. En nuestro diagnóstico sobre WordPress y hosting explicamos cómo valorar esos recursos por separado.
Optimizar el almacenamiento no consiste en perseguir cada megabyte.
Una caché puede ocupar espacio y resultar útil.
Los logs pueden ser necesarios para investigar una incidencia.
Las imágenes derivadas pueden servir para mostrar la fotografía correcta en cada pantalla.
Un backup ocupa espacio precisamente porque contiene datos que quieres conservar.
El problema no es que WordPress almacene cosas.
El problema es no saber qué almacena, por qué crece y si sigue siendo necesario.
Si tu proveedor te avisa de que estás llegando al límite, evita empezar por el botón de borrar.
Empieza por el mapa:
qué ocupa el espacio → qué lo genera → si sigue siendo necesario → qué se puede eliminar con seguridad → cómo evitar que vuelva a crecer.
Ese diagnóstico puede terminar diciendo que necesitas ampliar el hosting.
O puede descubrir que estabas pagando por almacenar copias de copias, logs de un error que lleva meses repitiéndose o restos de una web que nadie recordaba.
La diferencia está en saberlo antes de borrar nada.
