WordPress no sube imágenes: causas y soluciones

Contexto del problema: por qué WordPress deja de subir imágenes

Cuando WordPress no sube imágenes, el fallo suele ocurrir en uno de estos puntos: el navegador no completa la petición, WordPress no puede escribir en /wp-content/uploads, PHP corta la subida por límites, o el servidor bloquea la operación por reglas de seguridad. En ocasiones, la imagen sí se sube pero no se genera la miniatura, lo que apunta a librerías de procesamiento (GD o Imagick) o a falta de recursos.

En WordPress, la biblioteca multimedia no es solo un “almacén” de archivos. También gestiona metadatos, tamaños intermedios y enlaces en contenidos. Por eso, un fallo al subir imágenes puede derivar en entradas con imágenes rotas, productos sin galería, problemas de rendimiento por imágenes sin optimizar o incluso errores en el editor de bloques si el proceso se interrumpe.

• Subida fallida con mensaje genérico (por ejemplo, HTTP error) y sin más detalle.
• Subida completada pero sin miniaturas o con imágenes en blanco.
• Imposibilidad de escribir en uploads por permisos o propiedad de archivos.
• Bloqueos por límites de PHP o del servidor (tamaño, tiempo, memoria).
• Interferencias por plugins de seguridad, caché, optimización o CDN.

Diagnóstico inicial y señales útiles antes de tocar nada

Antes de cambiar configuraciones, conviene observar señales concretas. El objetivo es evitar “prueba y error” que complique el incidente. Si puede, reproduzca el fallo con una imagen pequeña y otra más grande, y anote exactamente qué ocurre: si aparece un mensaje, si se queda cargando, si devuelve un error al instante o si falla tras unos segundos.

En paralelo, revise indicadores del servidor y del propio WordPress. En muchos casos, el panel del hosting muestra picos de CPU, memoria o procesos, y WordPress puede registrar errores en el log si está habilitado. Estas comprobaciones son prudentes porque no cambian el estado del sitio y ayudan a acotar la causa.

• Mensajes visibles: HTTP error, No se ha podido mover el archivo subido, La subida ha fallado o errores de permisos.
• Señales de caída o inestabilidad: errores 500 intermitentes al subir, tiempo de espera, o editor que se queda bloqueado.
• Alertas del hosting: límites de recursos, bloqueos del WAF, reglas anti bot o avisos de mod_security (si el proveedor los expone).
• Cambios recientes: actualización de WordPress, tema o plugins, cambio de versión de PHP, migración, activación de CDN o plugin de optimización.
• Alertas externas: avisos en Search Console sobre recursos bloqueados o problemas de indexación de imágenes, si aplica.

Causas habituales y cómo confirmarlas con pruebas simples

Las causas más comunes se agrupan en cuatro bloques: límites de PHP, permisos y rutas de subida, procesamiento de imágenes (miniaturas) y bloqueos por seguridad. Confirmarlas requiere pruebas pequeñas y reversibles. Por ejemplo, si una imagen de 200 KB sube y una de 6 MB no, el problema suele ser de límites. Si sube pero no genera miniaturas, suele ser de librerías o recursos.

Para confirmar, conviene separar “subida del archivo” de “procesado posterior”. WordPress primero recibe el archivo y lo mueve a uploads. Después genera tamaños intermedios y metadatos. Un fallo en cualquiera de las dos fases produce síntomas distintos, y eso guía la corrección.

• Prueba por tamaño: subir una imagen muy pequeña y otra grande para detectar límites de upload_max_filesize o post_max_size.
• Prueba por formato: JPG frente a PNG o WebP para detectar problemas de librerías o de validación.
• Prueba por usuario: intentar con un administrador y con un editor para descartar permisos de rol o restricciones del plugin.
• Prueba por navegador: repetir en modo incógnito para descartar extensiones o caché del navegador.
• Prueba por ruta: comprobar si existen carpetas por año y mes en uploads y si se crean al subir.

Seguridad, malware y spam: cuándo la subida se bloquea por protección

Aunque el fallo al subir imágenes suele ser técnico, también puede estar relacionado con seguridad. Algunos sistemas de protección bloquean cargas por patrones que consideran sospechosos, por ejemplo, nombres de archivo extraños, cabeceras inesperadas o intentos repetidos. Además, si el sitio ha sufrido una intrusión, es posible que se hayan alterado permisos, se haya llenado el disco o se hayan añadido reglas que rompen funcionalidades.

Los vectores habituales incluyen plugins vulnerables sin actualizar, credenciales filtradas, usuarios administradores no reconocidos, permisos demasiado abiertos en wp-content o inyecciones que modifican el comportamiento del panel. La respuesta debe ser proporcionada: preservar evidencias, asegurar accesos y evitar “limpiezas” agresivas sin copia, porque pueden borrar pistas y empeorar la recuperación.

• Síntomas: redirecciones raras en el panel, usuarios nuevos, cambios en ajustes de medios, o errores que aparecen solo para ciertos roles.
• Vectores: plugins o temas desactualizados, credenciales reutilizadas, acceso FTP comprometido, permisos inseguros en carpetas.
• Medidas inmediatas: copia de seguridad completa antes de tocar archivos, rotación de contraseñas y revisión de usuarios con rol administrador.
• Hardening básico: limitar permisos de escritura donde no sea necesario y revisar claves de seguridad si hay sospecha de sesión comprometida.
• Revisión de alertas: comprobar avisos públicos y buenas prácticas de seguridad para contextualizar riesgos y priorizar acciones.

Rendimiento y estabilidad: recursos insuficientes al procesar imágenes

Subir imágenes no es solo transferir un archivo. WordPress suele generar varios tamaños, leer metadatos y, en algunos casos, convertir formatos. Si el servidor va justo de memoria o CPU, el proceso puede fallar a mitad, devolviendo errores genéricos. Esto es habitual en webs con muchas visitas, en planes con recursos limitados o cuando coinciden tareas en segundo plano, como copias, cron o regeneración de miniaturas.

Los límites relevantes suelen estar en PHP: memory_limit, max_execution_time, upload_max_filesize y post_max_size. También influyen límites del servidor web o del propio proveedor. Ajustarlos sin criterio puede ocultar el problema real, por lo que conviene hacerlo tras confirmar con pruebas y, si es posible, con registros.

• Confirmación típica: fallos solo con imágenes grandes o al subir varias seguidas.
• Señal indirecta: el panel va lento y el fallo aparece tras esperar, como si agotara tiempo de ejecución.
• Revisión prudente: comprobar en el panel del hosting el consumo de recursos en el momento del fallo.
• Optimización preventiva: reducir peso de imágenes antes de subir y estandarizar tamaños para evitar picos de procesamiento.
• Estabilidad: revisar tareas programadas y procesos concurrentes que puedan coincidir con la subida.

Plugins, temas y actualizaciones: conflictos que afectan a la biblioteca multimedia

Los conflictos de plugins o del tema pueden romper la subida de imágenes, especialmente si intervienen en el editor, en la optimización de medios o en la seguridad. También puede ocurrir tras una actualización: cambia una dependencia, se endurecen validaciones o se modifica el comportamiento del editor de bloques. Por eso, la trazabilidad de cambios recientes es clave para acotar el origen.

La buena práctica es probar cambios en un entorno de staging, con una copia representativa, y aplicar control de cambios. Si ya está en producción, el enfoque más seguro es aislar el conflicto con pruebas controladas: desactivar temporalmente plugins no críticos, cambiar a un tema por defecto para descartar interferencias, y repetir la subida con un archivo de prueba. Todo ello, idealmente, fuera de horas punta.

• Conflictos típicos: plugins de optimización de imágenes, caché, seguridad, editores visuales o constructores.
• Señal frecuente: el fallo aparece justo después de actualizar un plugin o el núcleo.
• Prueba controlada: desactivar plugins por bloques, empezando por los relacionados con medios y seguridad.
• Staging: reproducir el fallo en un clon para evitar impacto en usuarios y para probar ajustes de PHP sin riesgo.
• Compatibilidad: revisar requisitos de versión de PHP y WordPress de plugins clave antes de actualizar.

Hosting, dominio y correo en España: límites, DNS, SSL y cachés del servidor

En el ámbito general de España, muchos proveedores aplican capas de seguridad y optimización a nivel de servidor que pueden afectar a subidas: reglas WAF, límites por proceso, restricciones de escritura o cachés agresivas. Además, la configuración de PHP puede gestionarse desde panel, por archivo .user.ini, por php.ini o por el propio proveedor, y esto condiciona qué cambios tienen efecto.

Aunque el dominio y el correo no suelen ser la causa directa de que no suban imágenes, sí influyen en el diagnóstico y en la operativa. Un SSL mal configurado puede generar bloqueos mixtos o errores en el panel si hay redirecciones inconsistentes. Y si el sitio envía notificaciones (formularios, WooCommerce), conviene mantener el correo transaccional estable durante la incidencia para no perder avisos de pedidos o contactos.

• PHP y límites: confirmar dónde se gestionan upload_max_filesize, post_max_size y memory_limit y si el cambio aplica al FPM o al usuario.
• Disco y cuotas: verificar espacio disponible e inodos, porque un disco lleno impide mover archivos a uploads.
• Permisos y propiedad: revisar que el usuario del servidor pueda escribir en wp-content/uploads sin abrir permisos en exceso.
• SSL y redirecciones: comprobar que el panel carga siempre por HTTPS y que no hay bucles de redirección que afecten a peticiones.
• Cachés de servidor y CDN: purgar caché si afecta al panel y revisar si el CDN interfiere con el endpoint de subida.

Pruebas, accesos y documentación técnica para resolver con trazabilidad

Para resolver con rapidez y sin repetir el incidente, es importante reunir pruebas y accesos mínimos. No se trata de acumular datos, sino de documentar lo necesario para identificar el punto de fallo y justificar cambios. Esto es especialmente útil si intervienen varias personas o si debe escalarse al soporte del hosting.

Si trabaja con un proveedor o con soporte externo, una documentación breve pero precisa reduce tiempos: qué archivo falla, en qué pantalla, desde cuándo, y qué se cambió antes. En reparaciones reales, esta trazabilidad evita que se “arregle” un síntoma y se deje la causa intacta.

• Trazabilidad de cambios recientes: registro de actualizaciones (núcleo, plugins, tema), lista de plugins activos y, si existe, changelog interno de cambios.
• Evidencias técnicas: logs del servidor o de PHP, capturas del error, hora exacta del fallo y URL o pantalla afectada (biblioteca multimedia, editor, producto).
• Estado de copias: última copia completa verificada, y si hay export de base de datos reciente para poder revertir cambios.
• Accesos mínimos: administrador de WordPress, acceso al panel del hosting y, si procede, SFTP para revisar permisos sin usar FTP inseguro.
• Archivo de prueba: una imagen pequeña y otra grande, con nombre simple, para repetir el test de forma consistente.

Plan de acción ordenado para recuperar la subida de imágenes

Un plan ordenado reduce el riesgo de empeorar el problema. La prioridad es contener, hacer copia y diagnosticar con pruebas simples. Después, aplicar correcciones de menor impacto a mayor impacto, verificando en cada paso. Este enfoque es especialmente útil en sitios con negocio activo, donde minimizar tiempos de caída es más importante que “tocar muchas cosas rápido”.

A nivel técnico, suele ser más eficaz empezar por confirmar límites y permisos, y después aislar conflictos. Si hay sospecha de seguridad, se prioriza asegurar accesos y preservar evidencias. Tras corregir, conviene verificar no solo que sube una imagen, sino que se generan miniaturas y que el editor funciona con normalidad.

• Contención: reproducir el fallo con archivo de prueba y registrar mensaje, hora y contexto.
• Copia: asegurar copia completa antes de cambios en servidor, plugins o archivos.
• Diagnóstico rápido: comprobar espacio en disco, permisos de uploads y límites de PHP relevantes.
• Aislamiento: desactivar temporalmente plugins relacionados con medios, caché y seguridad, y probar con tema por defecto si es viable.
• Corrección y verificación: aplicar el ajuste mínimo necesario, probar subida, miniaturas y carga del editor, y monitorizar tras el cambio.

Si ya se ha tocado algo o hay urgencia: cómo evitar agravar la incidencia

En situaciones urgentes es habitual actuar sin plan: instalar un plugin de seguridad, restaurar una copia parcial o tocar archivos del tema. Esto puede resolver temporalmente, pero también puede introducir nuevos fallos o borrar evidencias. Si ya se han hecho cambios, el primer paso es reconstruir la secuencia: qué se tocó, en qué orden y con qué objetivo. Esa línea temporal es parte del diagnóstico.

Si el sitio está en producción, priorice estabilizar y documentar. Evite restauraciones parciales sin entender qué incluyen, porque pueden desincronizar archivos y base de datos. Y si se ha intentado limpiar malware sin copia, extreme la cautela: puede haberse eliminado código legítimo o dejado puertas traseras. En estos casos, es preferible una revisión técnica que combine logs, integridad de archivos y verificación de permisos.

• Se instaló un plugin de seguridad: revisar si bloquea subidas o endpoints del panel y si registró eventos útiles.
• Se restauró una copia parcial: comprobar coherencia entre base de datos y wp-content, y si faltan carpetas de uploads.
• Se cambió de hosting: validar límites de PHP, permisos, propiedad de archivos y reglas WAF del nuevo entorno.
• Se tocó functions.php: revertir cambios recientes si afectan al editor o a filtros de subida, y evitar ediciones directas sin control de versiones.
• Se borró un plugin crítico: restaurar desde copia o reinstalar la misma versión si es necesario para recuperar funcionalidad y registros.

Preguntas frecuentes

Estas dudas aparecen con frecuencia cuando WordPress no sube imágenes. Las respuestas son generales y deben ajustarse a su hosting y configuración.

P: ¿Qué significa exactamente el error “HTTP error” al subir una imagen?

R: Es un mensaje genérico del cargador de medios cuando la petición falla sin un detalle claro en pantalla. Suele estar relacionado con límites de PHP, tiempo de ejecución, bloqueos de seguridad o fallos al generar miniaturas.

P: ¿Por qué sube la imagen pero no aparecen miniaturas o se ve en blanco?

R: Normalmente el archivo se ha guardado, pero el servidor no ha podido procesarlo para crear tamaños intermedios. Es típico por falta de memoria, librerías de imagen no disponibles o restricciones del servidor.

P: ¿Puedo solucionar esto solo aumentando los límites de PHP?

R: A veces ayuda, pero no siempre es la causa. Si hay permisos incorrectos, disco lleno, un WAF bloqueando o un conflicto de plugin, subir límites puede no cambiar nada y además ocultar el origen real.

P: ¿Desactivar plugins es seguro en una web con ventas o formularios?

R: Depende del plugin y del momento. Lo recomendable es hacerlo en staging o en una ventana de baja actividad, empezando por plugins no críticos y documentando cada cambio para poder revertirlo.

P: ¿Qué debo enviar al soporte del hosting para que lo revisen más rápido?

R: La hora exacta del fallo, el mensaje o captura, el tamaño y formato del archivo, la URL o pantalla donde ocurre y si ha habido cambios recientes. Si dispone de logs o de un identificador de bloqueo del WAF, también ayuda.