«Error HTTP» al subir imágenes en WordPress es un aviso genérico, no una causa concreta. La petición puede bloquearse antes de llegar a PHP, fallar al recibir el archivo o completarse y encontrar un problema al generar miniaturas. Subir límites o desactivar plugins sin saber qué fase falla puede no resolver nada.
Si el mensaje dice «Falta una carpeta temporal», consulta esa guía específica del temporal de PHP. Si las imágenes se suben pero no se ven, registra ese comportamiento por separado. No todos los problemas de la biblioteca tienen el mismo origen.
Empieza con dos archivos y una petición concreta
Prueba un JPEG pequeño con nombre sencillo y después la imagen que falla. Anota peso, dimensiones, formato, hora y usuario que realiza la prueba. Que el archivo pequeño funcione orienta hacia diferencias entre archivos o límites; no descarta todos los problemas de permisos, filtros o rutas.
En las herramientas del navegador, identifica la petición de subida fallida en la pestaña de red. Guarda su estado HTTP y el mensaje de respuesta, si lo hay. No compartas una exportación de red sin revisarla: puede contener cookies, cabeceras de autorización y datos privados.
Cómo interpretar las señales más habituales
- 413: revisa el límite del cuerpo de la petición en el servidor o proxy que devuelve la respuesta. No demuestra por sí solo que el límite esté en PHP.
- 403: comprueba permisos de la acción, sesión y registros del sistema de seguridad. No desactives el firewall para toda la web.
- 500 o timeout: correlaciona la hora con los registros del servidor y PHP. El código por sí solo no identifica memoria, plugin o librería.
- Respuesta 200 con un error dentro: lee el resultado de la aplicación; recibir HTTP 200 no garantiza que WordPress haya creado el adjunto.
- Archivo presente sin miniaturas: revisa el procesamiento posterior, el formato y los errores de generación de tamaños.
Los estados describen la respuesta de una capa, no un diagnóstico completo. Puedes consultar las definiciones de 413 y 403 para interpretar el bloqueo antes de elegir una corrección.
Revisa límites sin confundir peso y dimensiones
upload_max_filesize limita un archivo; post_max_size limita la petición completa y necesita margen para sus otros datos. También puede haber límites del proxy o del hosting. Pide los valores efectivos del PHP web y la capa que rechaza la petición. Cambiar una constante de WordPress no modifica automáticamente todos esos límites.
Una imagen comprimida puede ocupar pocos megabytes y tener dimensiones enormes. Decodificarla y generar varios tamaños exige recursos diferentes de transferirla. Revisa el error real, la memoria disponible para PHP y la librería utilizada. WP_MEMORY_LIMIT no garantiza que el servidor conceda más memoria ni corrige una política de Imagick.
Comprueba destino y librería de imágenes
Si el archivo no puede guardarse, comprueba el temporal de PHP, el directorio final de subidas, cuotas y acceso del proceso. Los permisos dependen del propietario y del modelo de alojamiento; no sustituyas el diagnóstico por una receta de 755, 644 o 777.
Si la recepción funciona, revisa en Salud del sitio la información disponible sobre GD o Imagick y los formatos admitidos por la instalación. Relaciona esos datos con el archivo concreto. Una conversión a JPEG sirve como prueba para acotar un formato; conserva el original y comprueba si necesitas transparencia o calidad que esa conversión no mantiene.
Aísla conflictos con una prueba acotada
Compara los cambios recientes con los registros antes de tocar componentes. Si la evidencia apunta a un plugin de optimización, almacenamiento externo o seguridad, reproduce el fallo en staging y cambia una sola variable. Define qué función afecta, cómo restaurarla y cómo repetir la prueba. Desactivar todos los plugins en producción puede interrumpir formularios, pedidos y accesos.
Si necesitas ayuda para ordenar esa intervención, el proceso de reparación de WordPress empieza por evaluación y alcance. Una limitación de hosting debe coordinarse con quien controla esa capa.
Qué comprobar después de corregir la causa
- Sube una imagen pequeña y otra representativa del trabajo real.
- Comprueba el adjunto y los tamaños esperados en la biblioteca.
- Inserta la imagen en una página de prueba y abre esa página en la web.
- Repite el formato que fallaba y revisa los errores del mismo intervalo.
- Confirma que se han restaurado las protecciones o componentes usados en la prueba.
No repitas indiscriminadamente una subida grande que vuelve a agotar recursos. Conserva una prueba reproducible y evita generar adjuntos duplicados durante el diagnóstico.
Qué enviar para solicitar una evaluación
Prepara URL, mensaje exacto, hora, peso y dimensiones del archivo, respuesta HTTP, cambios recientes y resultado de la prueba pequeña. Explica si bloquea publicaciones, productos o una campaña. Envía únicamente información revisada; nunca contraseñas, cookies o un registro completo sin filtrar.
Solicita una evaluación del error de subida. Se revisa el síntoma y se acuerda el alcance antes de intervenir; no se puede elegir una reparación solo por el texto «Error HTTP».
Preguntas frecuentes sobre el error HTTP
¿Una imagen más pequeña soluciona el problema?
Puede evitar un límite concreto y ayudar a diagnosticarlo. No confirma que se haya corregido la configuración ni que el archivo original se pueda procesar.
¿Debo aumentar la memoria de WordPress?
Solo si el error y los límites efectivos lo justifican. Un bloqueo del proxy o del firewall requiere otra intervención.
¿HTTP 200 significa que la subida ha funcionado?
No necesariamente. Comprueba la respuesta de WordPress y que exista el adjunto con sus tamaños previstos.
¿Es seguro desactivar todos los plugins?
No es un primer paso adecuado para una web en producción. Una prueba controlada debe tener alcance, recuperación y verificación.
CRITERIO DE INCIDENTE WP REPAIR
Cómo acotar el fallo sin adivinar
El cargador de medios combina transferencia, autenticación, escritura y procesado de imagen. Un archivo pequeño de control revela qué etapa falla antes de tocar permisos o memoria.
Prueba un JPEG pequeño y anota la respuesta de red de la subida.
Confirma si el archivo llega a uploads aunque falle la creación de miniaturas.
Lee logs PHP por errores de Imagick, GD, memoria o timeout a la misma hora.
Verifica tamaño de subida y POST, propietario y directorio temporal.
Qué debe quedar verificado
- Suben una imagen pequeña y otra grande realista.
- Se generan y pueden leerse los tamaños esperados.
- El front las sirve sin errores de permisos ni contenido mixto.
Fuentes técnicas oficiales
Esta guía explica el diagnóstico. Si la web está afectada ahora, la intervención debe preservar una vía de vuelta y verificar el recorrido real del negocio.
Ver el servicio de reparación urgente →SOBRE ESTE SÍNTOMA
Preguntas frecuentes de esta guía.
¿Cómo puedo reducir rápidamente si esto es un problema de tamaño o algo más?+
Intente subir primero un pequeño JPEG de 100 KB. Si eso tiene éxito, el problema es específico para el tamaño o procesamiento en lugar de permisos o un bloque de servidor de manta, que descarta inmediatamente una gran categoría de causas.
¿Está bien simplemente establecer los permisos de la carpeta de subidas a 777 para hacer que el error desaparezca?+
No — que cambia un inconveniente menor por una exposición de seguridad real. El directorio de subidas debe ser escrito (755 para carpetas, 644 para archivos) y propiedad del usuario web correcto, lo que es suficiente; aflojarlo aún más no es necesario y no es seguro.
La imagen sube bien y aparece en la biblioteca de medios, pero ¿es suficiente para considerarla fija?+
No necesariamente — una carga que aterriza en la biblioteca pero que no produce versiones de miniaturas redimensionadas sigue siendo una tubería rota. Confirme que las versiones redimensionadas fueron creadas y que la imagen se muestra correctamente en la parte delantera, no sólo que aparece en la biblioteca.
¿Podría mi theme estar causando esto a pesar de que el error se parece a un problema del servidor?+
Sí. Un theme puede conectarse a la tubería de carga e interferir con el procesamiento, por lo que cambiar temporalmente a una theme predeterminada es uno de los pasos estándar para aislar la causa, junto con la comprobación de Site Health para una biblioteca de imágenes faltante o un límite de memoria bajo.