WordPress no carga CSS por permisos de archivos

Cuando WordPress no carga CSS por permisos de archivos, el problema no suele estar en el diseño en sí, sino en que el servidor no puede leer o servir correctamente las hojas de estilo. En muchos casos ocurre tras una migración, una restauración, cambios por FTP/SFTP, endurecimiento de seguridad o ajustes del hosting que dejan archivos o carpetas con permisos inadecuados, propiedad errónea o algún bloqueo relacionado.

La consecuencia es muy visible: la web aparece “rota”, sin estilos del tema o de plugins, aunque el contenido siga cargando. La forma correcta de abordarlo no es tocar permisos al azar, sino confirmar primero si el acceso al CSS falla por lectura denegada, por ownership incorrecto o por una capa intermedia como caché, CDN o reglas de seguridad.

Qué significa que WordPress no carga el CSS por permisos de archivos

Significa que el navegador pide uno o varios archivos CSS, pero el servidor no puede entregarlos correctamente porque los permisos o la propiedad de esos archivos y carpetas no permiten el acceso esperado. La solución orientativa suele pasar por revisar la ruta afectada, comprobar códigos de respuesta como 403 o errores de acceso, y ajustar permisos y ownership de forma prudente según el entorno.

En servidores Linux/Unix, muy habituales en WordPress, cada archivo y carpeta tiene un conjunto de permisos y una propiedad asociada. Esos datos determinan quién puede leer, escribir o ejecutar/atravesar una ruta. Para que un CSS se sirva con normalidad, no basta con que el archivo exista: el servidor web y el usuario bajo el que se ejecuta el proceso deben poder acceder a toda la cadena de carpetas necesaria.

Aquí conviene distinguir entre permisos de archivos y permisos de carpetas:

• Archivos: necesitan permiso de lectura para poder servirse. Como referencia común, 644 suele ser válido en muchos entornos WordPress.
• Carpetas: necesitan permitir acceso y recorrido de directorio. Como valor habitual, 755 suele funcionar correctamente en muchos servidores.

No es una regla universal inmutable, porque algunos hostings gestionan usuarios, grupos o políticas adicionales de otra forma. Aun así, 644 para archivos y 755 para carpetas siguen siendo la referencia práctica más común para empezar a diagnosticar.

Cómo identificar si el fallo de estilos viene de permisos y no de caché u otro problema

Antes de cambiar nada, conviene confirmar si el CSS está realmente bloqueado por permisos o si el fallo viene de caché, minificación, CDN, rutas rotas o generación de archivos dinámicos. El objetivo es no aplicar un arreglo incorrecto a un problema distinto.

Qué mirar en el navegador

Abre las herramientas de desarrollo del navegador y revisa la pestaña de Red/Network. Localiza los archivos .css que no cargan y fíjate en el código de respuesta:

• 403: suele indicar acceso denegado. Es una señal compatible con permisos, ownership, reglas del servidor o protección de seguridad.
• 404: el archivo no se encuentra en esa ruta. Puede haber relación indirecta con permisos si un proceso no logró generarlo o moverlo, pero no conviene asumirlo sin revisar.
• 200 con contenido incorrecto: puede apuntar más a caché, minificación rota, CDN desactualizada o un plugin que altera la salida.

Si ves un 403 en hojas de estilo concretas, el foco debe ir a permisos de lectura, propiedad de archivos y reglas que impiden servir recursos estáticos.

Rutas que conviene revisar primero

Según de dónde venga el estilo roto, estas rutas suelen ser las primeras candidatas:

• Tema activo: wp-content/themes/tu-tema/
• Tema hijo: si existe, revisar su carpeta y sus archivos CSS específicos.
• Plugins: wp-content/plugins/, sobre todo si el fallo afecta a maquetadores, optimizadores o plugins que generan CSS.
• Subidas y archivos generados: wp-content/uploads/, donde algunos plugins guardan CSS compilado o assets.
• Caché: carpetas de caché del plugin o del servidor, si el recurso servido proviene de una versión cacheada.

Cómo diferenciar permisos de caché o CDN

Si tras vaciar caché del navegador, plugin, servidor y CDN el recurso sigue devolviendo 403 o aparece como bloqueado, la hipótesis de permisos gana peso. Si en cambio el archivo carga bien desde el origen, pero no desde la versión optimizada o distribuida, puede deberse más a minificación, reescritura de URL o propagación de caché.

Qué permisos revisar en archivos y carpetas de WordPress

Para resolver un caso de permisos archivos WordPress, hay que revisar no solo el archivo CSS final, sino también las carpetas que lo contienen. Si una carpeta intermedia no permite acceso adecuado, el recurso puede fallar aunque el archivo tenga un valor aparentemente correcto.

La relación entre permisos y propiedad del archivo

Un punto clave es que tener 644 o 755 no garantiza por sí solo que todo funcione. Si los archivos pertenecen a un usuario distinto del que necesita gestionarlos o del que usa el proceso del servidor, puede haber problemas para leer, escribir o regenerar recursos. Esto se ve mucho después de migraciones, despliegues automáticos, copias restauradas o cambios hechos desde un usuario SSH/FTP diferente.

En la práctica, si un plugin genera CSS en uploads o en una carpeta propia, y esos archivos quedan con ownership incorrecto, WordPress puede dejar de actualizarlos o el servidor puede no servirlos como se espera. Por eso conviene revisar permisos y propiedad de forma conjunta.

Por qué 777 no es recomendable

Asignar 777 a archivos o carpetas abre lectura, escritura y ejecución para todos los usuarios. Aunque a veces se usa como “prueba rápida”, en la mayoría de casos no es una práctica segura y puede empeorar la superficie de ataque de la web. Además, no siempre resuelve el problema real si el origen está en ownership, políticas del hosting, reglas de seguridad o restricciones del servidor.

Cómo corregir permisos incorrectos sin comprometer la seguridad

La forma más segura de actuar es hacer cambios limitados, sobre las rutas afectadas, y comprobar el resultado. No conviene aplicar ajustes masivos sin saber qué está fallando exactamente.

Revisión por FTP/SFTP o gestor de archivos del hosting

1. Conéctate por SFTP o usa el gestor de archivos del panel del hosting.
2. Ve a la ruta del recurso CSS que falla, por ejemplo dentro de wp-content/themes/ o wp-content/plugins/.
3. Comprueba permisos del archivo CSS y de las carpetas superiores inmediatas.
4. Si el entorno encaja con la configuración habitual, revisa si los archivos están cerca de 644 y las carpetas de 755.
5. Si ves valores claramente restrictivos o incoherentes, ajústalos de forma selectiva y vuelve a probar la carga del recurso.

Si el panel muestra también propietario o grupo, conviene compararlo con el resto de archivos sanos del sitio para detectar diferencias evidentes.

Ejemplos orientativos con chmod y chown

Si tienes acceso por terminal y entiendes tu entorno, puedes usar comandos orientativos como chmod o chown. Deben ejecutarse solo si conoces el usuario correcto y el alcance del cambio, porque un ajuste masivo mal aplicado puede romper más recursos o afectar a la seguridad.

Estos ejemplos son orientativos. El usuario y grupo correctos dependen del servidor, del panel de hosting y del modo en que se ejecuta PHP o el servidor web.

Revisar carpetas donde se generan estilos

No todos los estilos salen directamente del tema. Algunos plugins y constructores generan CSS compilado o caché en carpetas específicas. Si ahí falla la escritura o la lectura, la web puede quedarse sin estilos actualizados. En esos casos conviene:

• Localizar la carpeta donde el plugin guarda CSS o caché.
• Comprobar permisos y ownership de esa carpeta y de los archivos generados.
• Regenerar los estilos desde el propio plugin o maquetador, si dispone de esa opción.

Comprobaciones posteriores al cambio

Después de corregir permisos, conviene validar que el sitio realmente sirve los estilos correctos:

• Vaciar caché del navegador.
• Vaciar caché de WordPress, del plugin de optimización y del servidor si aplica.
• Purgar CDN en caso de usarla.
• Regenerar CSS o archivos estáticos si el tema o plugin lo permite.
• Revisar de nuevo la pestaña de red para confirmar que el CSS devuelve 200 y el contenido es correcto.
• Comprobar si la minificación o combinación de archivos está interfiriendo.
• Si no tienes acceso por FTP alternativas seguras, usa el panel del hosting o métodos equivalentes.

Errores frecuentes al cambiar permisos en WordPress

Muchos problemas se agravan no por el fallo inicial, sino por una corrección aplicada sin criterio. Estos son los errores más habituales:

• Aplicar 777 para “probar”: puede abrir un riesgo de seguridad serio y no resolver la causa real.
• Cambiar permisos en toda la instalación sin discriminar: puede afectar a archivos sensibles o a procesos que antes funcionaban bien.
• Olvidar la propiedad de archivos: el valor numérico puede ser correcto y aun así seguir fallando por ownership.
• Mirar solo el archivo CSS: si una carpeta superior bloquea el acceso, el recurso seguirá sin servirse.
• Confundir 403 con 404: no encontrar el archivo no es lo mismo que tenerlo bloqueado.
• No revisar la caché después del cambio: puede parecer que no se ha arreglado cuando el problema es una copia antigua del recurso.
• Ignorar reglas del hosting o del plugin de seguridad: según el entorno, puede haber restricciones adicionales aunque los permisos parezcan correctos.

También conviene tener presente que algunos paneles de hosting muestran permisos de una forma simplificada. Si los síntomas persisten, puede ser necesario revisar los registros del servidor o pedir al proveedor que confirme si hay denegaciones por seguridad, propietario incorrecto o políticas del sistema de archivos, algo que también aparece en errores de PHP en WordPress tras cambio de hosting.

Cuándo conviene pedir soporte o mantenimiento WordPress

Hay situaciones en las que lo prudente es escalar el caso. Si el fallo afecta a producción, hay varias capas de caché, usas CDN, existe un despliegue automatizado o no está claro qué usuario debe ser propietario de los archivos, tocar permisos sin seguridad puede empeorar el problema.

Conviene pedir soporte WordPress o ayuda del hosting cuando:

• El CSS devuelve 403 y no puedes verificar ownership desde tu acceso actual.
• Los permisos parecen correctos, pero el servidor sigue denegando el recurso.
• El problema apareció tras una migración, clonación, restauración o despliegue.
• Un plugin genera archivos, pero no logra escribirlos o servirlos.
• Hay reglas de seguridad, WAF o configuraciones del hosting que podrían estar bloqueando recursos estáticos.

Un servicio de mantenimiento WordPress resulta especialmente útil cuando este tipo de incidencias se repiten o cuando la web forma parte de un entorno empresarial donde cada cambio debe hacerse con control, copia de seguridad y validación posterior.

Conclusión práctica

Si WordPress no carga CSS por permisos de archivos, lo más habitual es que el servidor no pueda leer o recorrer correctamente la ruta del recurso, o que exista una discrepancia de propiedad entre archivos y usuario de ejecución. La revisión debe centrarse en el código de respuesta del CSS, las rutas dentro de wp-content, los permisos habituales como 644 y 755 cuando encajen, y las capas de caché o generación de estilos.

La clave es corregir lo justo, no abrir permisos en exceso y confirmar después que los estilos vuelven a servirse correctamente. Si hay dudas con ownership, restricciones del hosting o despliegues complejos, el siguiente paso razonable es escalarlo a soporte técnico o a un mantenimiento especializado antes de comprometer seguridad o estabilidad.