WordPress no sube imágenes: causas y soluciones
WordPress no sube imágenes: causas y soluciones en España. Diagnóstico paso a paso, límites del servidor, permisos, plugins, seguridad y plan de acción
Que WordPress no suba imágenes suele parecer un problema menor, pero en la práctica bloquea tareas críticas: publicar contenidos, actualizar productos en WooCommerce, cargar creatividades de campañas o mantener una web corporativa al día. Además, cuando la biblioteca multimedia falla, es frecuente que el síntoma oculte una causa más seria, como límites del servidor, permisos incorrectos, conflictos de plugins o reglas de seguridad que cortan peticiones legítimas. El impacto puede ser directo en captación y reputación, especialmente si el equipo no puede actualizar la web con normalidad.
El objetivo de esta guía es ayudarle a diagnosticar y resolver el fallo de forma ordenada, con enfoque preventivo: qué revisar primero, qué pruebas conviene guardar y qué decisiones evitar si ya se han realizado cambios (actualizaciones, instalación de plugins, ajustes en el hosting o migraciones). Por transparencia, el análisis siempre depende del acceso disponible, de los registros, de los cambios recientes y de la configuración concreta; si tiene dudas, es preferible una revisión técnica previa a actuar para minimizar tiempos de caída, con un enfoque práctico aplicable en España, aunque algunos detalles pueden variar según proveedor de hosting, CDN o políticas de seguridad.
Fuentes consultadas
Índice
- 1. Contexto del problema en WordPress
- 2. Diagnóstico inicial y señales útiles
- 3. Causas habituales y cómo confirmarlas
- 4. Seguridad, malware y spam
- 5. Rendimiento y estabilidad
- 6. Plugins, temas y actualizaciones
- 7. Hosting, dominio y correo en España
- 8. Pruebas, accesos y documentación técnica
- 9. Plan de acción ordenado
- 10. Si ya se ha tocado algo o hay urgencia
- 11. Preguntas frecuentes
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.
Qué ocurre en la práctica: el síntoma “no sube imágenes” suele ser el primer aviso de que el entorno está al límite o de que se ha aplicado una regla de seguridad demasiado estricta. Resolverlo bien implica identificar el punto exacto de corte y dejar trazabilidad para que no se repita.
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.
Qué ocurre en la práctica: cuando el error es genérico, la diferencia entre resolver en 10 minutos o en 2 horas suele estar en capturar evidencias desde el inicio: hora exacta, archivo de prueba, mensaje, y si el fallo depende del tamaño o del tipo de imagen.
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.
Qué ocurre en la práctica: muchos incidentes se resuelven al identificar si el corte está en el límite de subida o en la generación de miniaturas. Esa distinción evita cambios innecesarios en plugins o en el tema.
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.
Qué ocurre en la práctica: un WAF o un plugin de seguridad puede bloquear subidas legítimas tras una actualización de reglas. Si el bloqueo coincide con cambios de seguridad, es más eficiente revisar logs y reglas que desactivar protecciones a ciegas.
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.
Qué ocurre en la práctica: en sitios con recursos ajustados, el problema aparece “de repente” tras crecer el catálogo o cambiar a imágenes más pesadas. La solución sostenible suele combinar límites adecuados con una política de imágenes y una revisión de carga del servidor.
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.
Qué ocurre en la práctica: un plugin puede “funcionar” en general pero fallar en una ruta concreta del panel, como el endpoint de subida. Aislar el conflicto con un método repetible suele ser más rápido que ajustar parámetros al azar.
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.
Qué ocurre en la práctica: dos instalaciones idénticas pueden comportarse distinto por políticas del proveedor. Por eso, cuando el problema coincide con un cambio de plan, migración o ajuste del panel del hosting, conviene revisar primero límites, cuotas y reglas de seguridad del servidor.
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.
Qué ocurre en la práctica: cuando se abre un ticket al hosting, aportar hora exacta, IP si aplica, y el log o el mensaje concreto suele acelerar la identificación de bloqueos por WAF o límites de recursos.
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.
Qué ocurre en la práctica: el orden importa. Si primero se desactivan protecciones o se cambian muchas variables, luego es difícil saber qué solucionó el problema y qué dejó el sitio más expuesto o inestable.
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.
Qué ocurre en la práctica: cuando hay prisa, se tiende a “reiniciar” el problema. Sin embargo, conservar evidencias y reducir cambios simultáneos suele acortar el tiempo total de recuperación y evita recaídas.
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.
Resumen accionable
- Reproduzca el fallo con una imagen pequeña y otra grande y anote mensaje, hora y pantalla exacta.
- Compruebe si el problema es de subida (mover a uploads) o de procesado (miniaturas y metadatos).
- Verifique espacio en disco y cuotas, porque un disco lleno impide guardar archivos.
- Revise permisos y propiedad de wp-content/uploads sin abrir permisos en exceso.
- Confirme límites de PHP: upload_max_filesize, post_max_size, memory_limit y tiempos.
- Aísle conflictos desactivando temporalmente plugins relacionados con medios, caché y seguridad, idealmente en staging.
- Si coincide con una actualización, revise cambios recientes y planifique reversión controlada si procede.
- Si sospecha de seguridad, haga copia, rote contraseñas y revise usuarios antes de “limpiar” sin método.
- Guarde evidencias: logs, capturas, archivo de prueba y lista de cambios para soporte o auditoría.
- Tras corregir, verifique subida, miniaturas, editor y monitorice estabilidad durante las horas siguientes.
Aviso: este contenido es informativo y general, no sustituye una revisión técnica individualizada. La solución práctica depende del entorno, del acceso disponible, de los cambios recientes y de la configuración.
Cierre de conversión suave: si lo desea, en reparawordpress.com podemos realizar una revisión técnica o auditoría con enfoque preventivo y realista. Lo habitual es empezar por diagnóstico, copia y un plan de corrección priorizado para reducir riesgos y tiempos de caída.
¿Necesitas orientación personalizada?
Te ayudamos a entender tus opciones y el siguiente paso.