El archivo subido no se pudo mover a wp-content/uploads: 8 soluciones

Subes una imagen, un PDF u otro archivo a la biblioteca de medios de WordPress y el proceso termina con este mensaje. Significa: WordPress aceptó el archivo guardado temporalmente, pero no pudo moverlo a la carpeta de destino final.

Primero prueba con un segundo archivo JPG o PNG pequeño. Luego comprueba Estado del sitio, espacio libre y inodos, la ruta de subida configurada, permisos y propietario y el directorio temporal de PHP. La ruta con números no es fija: según el mes puede ser por ejemplo wp-content/uploads/2026/01, 2026/02, 2026/04 o 2025/12 aparece. En esta guía usamos por eso /YYYY/MM.

El mensaje proviene del procesamiento de subida de WordPress. WordPress comprueba primero el estado de la subida, el tamaño y el tipo de archivo. Luego determina wp_upload_dir() el destino e intenta mover allí el archivo PHP temporal. Si ese último paso falla aparece el mensaje “The uploaded file could not be moved to …”. Esto se puede seguir en el core de WordPress para el procesamiento de subidas.

Un error de permisos al subir archivos en WordPress es una causa común, pero no la única. Una cuenta de hosting llena, inodos agotados, propiedad incorrecta o un directorio temporal inaccesible acaban mostrando a WordPress lo mismo: no se puede escribir el archivo de destino.

1. Probar otro archivo pequeño: Sube un JPG o PNG conocido de pocos kilobytes. Si funciona, comprueba por separado el tipo de archivo, el nombre y el límite de tamaño del archivo original.
2. Comprobar Estado del sitio de WordPress: Abre Herramientas > Estado del sitio > Información > Permisos del sistema de archivos. La entrada "The uploads directory" debería mostrar "Writable". Esta sección está en versiones actuales de WordPress.
3. Comprobar espacio e inodos: Un gigabyte libre no ayuda si ya se alcanzó el límite de inodos.
4. Comprobar la ruta de subida: Averigua si WordPress realmente usa wp-content/uploads/YYYY/MM o si hay una configuración especial antigua.
5. Comparar permisos y propietario: Comprueba la carpeta principal y la carpeta del año/mes actual.
6. Comprobar directorio temporal de PHP: upload_tmp_dir debe ser accesible y escribible por el proceso PHP.
7. Contactar con el soporte de hosting: Indica la ruta exacta y un momento concreto para que el proveedor pueda revisar los registros PHP y del servidor web adecuados.

Empieza aquí porque esta causa se puede descartar sin tocar archivos o configuración. Una cuenta de hosting puede haber alcanzado su disk quota aunque el archivo subido sea pequeño. Al subir se generan además miniaturas de la imagen original. Además caches, backups, logs y actualizaciones necesitan espacio.

Un inode representa, de forma simplificada, una entrada del sistema de archivos. Si el hosting aún muestra espacio libre pero no hay inodos libres, PHP no puede crear un archivo nuevo. No borres nada a ciegas. Primero comprueba si copias de seguridad antiguas, archivos de caché o copias de staging explican el consumo, y usa la limpieza prevista por tu proveedor o por plugins.

En una WordPress Multisite hay otro límite: la cuota de subida de cada sitio puede agotarse aunque el servidor aún tenga espacio. Como administrador de la red, comprueba el límite de almacenamiento del sitio afectado.

Con SSH estos comandos solo de lectura son útiles:

df -h
df -i

df -h muestra el espacio usado, df -i la utilización de inodos. En Managed Hosting la cuenta puede tener una cuota adicional que no refleje completamente estos valores del servidor. En ese caso, la información del proveedor es la decisiva.

La ruta por defecto es wp-content/uploads. Si la opción de organizar por año y mes está activa, WordPress añade la carpeta de fecha. La estructura queda así:

wp-content/
└── uploads/
    └── YYYY/
        └── MM/
            └── tu-archivo.jpg

Comprueba por SFTP, FTP o el administrador de archivos del hosting si uploads, la carpeta del año y la carpeta del mes actual existen. Una carpeta de mes ausente no es automáticamente un error: WordPress intenta crearla. Si no puede, normalmente la carpeta padre no es escribible o está mal asignada.

Internamente WordPress también tiene en cuenta la opción antigua upload_path. La constante UPLOADS en wp-config.php puede sobrescribir esta ruta. La documentación oficial sobre wp_upload_dir() describe este orden. Busca una configuración especial solo si el error indica una ruta inesperada o el sitio se ha migrado. No cambies la ruta sin motivo.

La carpeta de fecha en sí no es un problema. Si quieres eliminar años y meses de URLs de medios existentes conscientemente, hay una guía separada para mover subidas de WordPress fuera de carpetas por fecha. Para el error actual primero hay que restaurar la posibilidad de escribir.

Abre en tu cliente SFTP o gestor de archivos las propiedades del directorio afectado. 755 para directorios y 644 para archivos son valores iniciales útiles en muchos hostings Linux. No son una norma universal. Algunos entornos de hosting usan permisos de grupo, ACLs u otra modalidad de ejecución de PHP.

Revisa los permisos del camino de fuera hacia dentro: wp-content, uploads, YYYY y MM. El proceso PHP necesita permiso de escritura en el directorio destino y acceso a las carpetas superiores. La guía oficial de WordPress sobre permisos de archivos explica propietarios, grupos y permisos públicos.

Si dominas SSH, este comando muestra los valores actuales sin cambiarlos:

ls -ld wp-content wp-content/uploads wp-content/uploads/YYYY wp-content/uploads/YYYY/MM

Cambia permisos solo en la ruta demostrablemente afectada y según las indicaciones de tu proveedor. Un chmod recursivo sobre toda la instalación de WordPress no es necesario para esta búsqueda de fallos.

Los permisos determinan lo que propietario, grupo y otros pueden hacer. La propiedad determina qué usuario y qué grupo son propietarios. Por eso un chmod 755 puede parecer correcto y aun así fallar la subida.

Este patrón ocurre a menudo tras una migración manual, una restauración como root, un despliegue por SSH o copiar archivos entre cuentas de hosting. La carpeta puede pertenecer por ejemplo al usuario SSH, mientras PHP se ejecuta bajo otra cuenta o en otro grupo.

Compara propietario y grupo de wp-content/uploads con una carpeta en la que WordPress pueda escribir demostrablemente. No ejecutes un copia de chownNo ejecutes el comando mientras no conozcas el usuario de hosting correcto. En alojamiento compartido normalmente solo el soporte puede corregir la asignación de forma fiable. Envíale la ruta de destino y pide concretamente que compruebe owner, group y ACLs para el proceso PHP/Webserver.

Una subida desde el navegador llega primero a un directorio temporal del servidor. Solo después WordPress mueve el archivo a la biblioteca de medios. La configuración de PHP upload_tmp_dir puede indicar una carpeta propia. Si falta esa carpeta, está llena o PHP no puede leerla y escribir en ella, surge un WordPress temporary folder upload error.

También open_basedir puede limitar el acceso. La carpeta temporal y el directorio final de subidas deben estar dentro de las rutas permitidas para el sitio. En hosting gestionado o compartido debes comprobar estos valores en el área de info PHP del proveedor o preguntar al soporte. Edita php.ini o .user.ini solo si el proveedor documenta este método. Un archivo aleatorio de un tutorial externo puede dañar la configuración PHP de todo el sitio.

Con SSH estos comandos dan pistas, aunque la configuración PHP de línea de comandos puede diferir de la versión PHP usada por la web:

php --ini
php -i | grep -E 'upload_tmp_dir|open_basedir'

Si Site Health indica que la carpeta de subidas es escribible, hay espacio e inodos libres y aun así falla cualquier archivo pequeño, esta comprobación merece la pena.

Esta solución solo tiene sentido si la carpeta actual YYYY/MMfalta, está vacía o se creó con propiedad incorrecta. Nunca borres una carpeta de mes con archivos multimedia existentes.

1. Haz una copia de seguridad completa de wp-content/uploads y de la base de datos.
2. Comprueba si hay archivos en la carpeta mensual afectada. Si hay archivos, arregla permisos y propietario en lugar de volver a crear la carpeta.
3. Crea solo la carpeta que falta mediante SFTP o el gestor de archivos, por ejemplo primero YYYY y dentro MM.
4. Copia permisos, propietario y grupo de una carpeta mensual vecina que funcione del mismo hosting.
5. Sube un pequeño archivo de prueba. Luego comprueba si aparece en la biblioteca de medios y si es accesible mediante su URL.

Si una carpeta vacía está dañada, muévela primero con ayuda del proveedor de hosting a un nombre de respaldo en lugar de sobrescribirla inmediatamente. Así la modificación será reversible.

Plugins de seguridad, un Web Application Firewall, ModSecurity o una regla del hosting pueden bloquear subidas. Eso es más probable si solo afectan ciertas extensiones, nombres de archivo o peticiones. Una extensión bloqueada suele generar en WordPress un mensaje distinto al del fallo de movimiento. Trátalo por tanto como una clase de error separada.

Prueba con un pequeño JPG estándar. Si funciona, compara la extensión, el MIME-Type, el nombre de archivo y el tamaño con el archivo problemático. Revisa los registros de eventos o bloqueo de la herramienta de seguridad existente. No desactives plugins a lo loco. Si hace falta una prueba puntual, haz antes una copia de seguridad, usa una ventana de mantenimiento y desactiva solo el componente de seguridad concreto.

En fallos reproducibles anota la hora exacta con segundos. El proveedor podrá así cotejar de forma dirigida los logs de WAF, ModSecurity, PHP y servidor web.

Un mensaje genérico como «no se pueden subir archivos» suele generar preguntas. Copia esta lista de comprobación y sustituye los marcadores:

Adjunta el extracto de Site Health, pero elimina direcciones IP públicas, rutas del servidor y otros datos que el soporte no necesite. Con un proveedor serio, estos datos suelen ser suficientes para distinguir entre cuota, propiedad y configuración de PHP.

• No establezcas permisos 777 de forma permanente. Hacen wp-content/uploads innecesariamente escribible y a menudo enmascaran un error de propiedad.
• No abras completamente wp-content. Para una subida de medios es relevante la ruta concreta de subida.
• No modifiques archivos core de WordPress. El mensaje de error es un síntoma de la configuración del servidor o de rutas.
• No insertes fragmentos aleatorios en wp-config.php. Una nueva UPLOADSconstante puede generar una segunda ruta incorrecta.
• No desactives todos los plugins primero. Memoria, inodos, Site Health, rutas y propietario se pueden comprobar más rápido y con menos riesgo.
• No desactives la carpeta por fecha para evitar el error. Una carpeta principal no escribible no dejará de ser no escribible.

WordPress puede organizar las subidas automáticamente por año y mes. Por eso el mensaje indica la carpeta de destino actual, por ejemplo wp-content/uploads/2026/04. El número cambiará el mes siguiente. El diagnóstico sigue siendo el mismo, por eso una sola instrucción atemporal con /YYYY/MM es suficiente.

755 para directorios y 644 para archivos son un punto de partida sensato en muchos hostings Linux. Sin embargo, lo decisivo es el propietario, el grupo, las ACLs y la forma en que se ejecuta PHP. Si tu proveedor documenta otros valores, siguen sus indicaciones.

chmod modifica permisos, pero no propietario ni grupo. Si PHP se ejecuta bajo otro usuario, una cuota está llena o bloquea open_basedir la ruta, la carpeta sigue siendo inutilizable para el proceso real a pesar de 755.

Sí. También un cupo de inodos lleno o una cuota de Multisite puede impedir que WordPress cree el archivo de destino. Un archivo de 50 KB puede fallar por eso, aunque en sí mismo apenas necesite espacio.

Normalmente no. Un upload_max_filesize o post_max_size suele generar su propio mensaje. “Could not be moved” aparece más tarde en el proceso, después de que el archivo temporal ya haya sido aceptado. Si solo fallan archivos grandes, deberías revisar ambas clases de error.

Sí. WordPress intenta crear la ruta de subida necesaria y, con la estructura por fecha activa, las carpetas de año y mes. Si falla, a menudo la carpeta superior no es escribible o una ruta personalizada es incorrecta. Crea carpetas manualmente solo si puedes aplicar correctamente permisos y propietario.

Sube la misma pequeña archivo de prueba después de cada cambio. Así sabrás qué paso solucionó el error. Luego comprueba el archivo en la Media Library, abre su URL y verifica si WordPress generó las miniaturas esperadas.

Si la subida vuelve a funcionar, puedes limpiar la biblioteca con calma. neo Rename ayuda a renombrar y mover medios y actualiza referencias dentro de WordPress. Para bibliotecas grandes, neo Library añade búsqueda y organización sin que tengas que buscar carpetas en el servidor manualmente.

Fuentes: WordPress _wp_handle_upload(), WordPress wp_upload_dir() y WordPress File Permissions.