404 en estáticos tras CDN en WordPress, arreglo

Cuando aparecen 404 en estáticos tras CDN en WordPress, el problema suele estar en que la CDN sirve, reescribe o busca archivos estáticos con una URL, una caché o una regla distinta a la que esperan WordPress o el servidor de origen. No siempre falla lo mismo: según el proveedor, el plugin de caché, el proxy inverso, DNS, SSL o las reescrituras, el 404 puede nacer en capas diferentes.

La forma más segura de resolverlo es aislar la causa: comprobar primero si el recurso existe en origen sin CDN, revisar después la URL final que genera WordPress y, por último, validar cabeceras, caché y reglas avanzadas. Tocar varias capas a la vez suele alargar el diagnóstico.

Qué significa el error 404 en archivos estáticos tras activar una CDN

Un 404 en CSS, JavaScript o imágenes indica que la URL solicitada no encuentra el recurso en la capa que responde. En una web con CDN, esa respuesta puede venir del edge, de un proxy CDN WordPress o del servidor de origen. Por eso conviene distinguir si el archivo no existe, si existe pero se está pidiendo con una ruta incorrecta, o si la CDN conserva una referencia obsoleta.

En la práctica, esto suele verse como errores 404 en CSS y JS, hojas de estilo que no aplican, scripts que dejan de cargar o un caso típico de CDN WordPress no carga imágenes tras cambiar de dominio de recursos, activar minificación o modificar reglas de caché.

Causas más habituales: URLs, caché, reescrituras y proxy

No hay una causa universal, pero estas son las más habituales cuando aparecen 404 en estáticos tras CDN en WordPress:

• URLs de recursos mal reescritas: el plugin cambia rutas de archivos estáticos a un subdominio o dominio CDN que no apunta al origen correcto.
• Caché desincronizada: el origen ya sirve la versión buena, pero la CDN mantiene una referencia antigua o una regla cacheada que devuelve 404.
• Reescrituras WordPress o del servidor: reglas para mover, combinar o proteger assets que dejan de coincidir al introducir la CDN.
• Configuración de proxy: algunos proveedores actúan como proxy completo y otros solo sirven estáticos; el comportamiento cambia en cabeceras, host y validación de origen.
• Origen, pull o push mal definidos: la CDN puede estar buscando el archivo en una ruta distinta a la publicada realmente.

Cómo revisar paso a paso dónde se rompe la entrega de CSS, JS o imágenes

El orden importa. Empieza por lo simple y evita cambiar ajustes antes de confirmar dónde nace el fallo.

1. Abre la URL exacta del recurso en origen. Si el archivo no responde sin CDN, no empieces por la red perimetral.
2. Compara la URL generada por WordPress con la ruta real del archivo. Busca diferencias de dominio, protocolo, carpeta, versión o mayúsculas.
3. Revisa en el navegador la petición fallida: código de estado, response headers y desde qué host responde.
4. Desactiva temporalmente la reescritura de assets en el plugin de caché u optimización, si el stack lo permite, para verificar si el 404 desaparece.
5. Haz una invalidación selectiva o purga controlada. Si el cambio tarda en reflejarse, puede haber conflicto caché y CDN.

Qué ajustes conviene validar en WordPress, la CDN y el servidor

• En WordPress: URL del sitio, plugins que reescriben assets, minificación, combinación de ficheros y versionado de CSS y JavaScript.
• En la CDN: dominio de origen, política de caché, comportamiento con 404 cacheados, hotlink protection y si sirve en modo pull o push.
• En el servidor: permisos de lectura, reglas de reescritura, exclusiones por extensión, tipos MIME y cabeceras para archivos estáticos.

Si usas un proxy completo, valida también cómo se reenvía el host y si el origen espera un dominio concreto. En ciertos stacks, una discrepancia ahí basta para generar respuestas 404 aparentemente aleatorias.

Errores frecuentes al purgar caché, cambiar dominio CDN o usar plugins de optimización

Uno de los errores más comunes es purgar caché CDN sin limpiar antes o después la caché local del plugin, la del servidor o la del navegador. Si cada capa conserva una versión distinta de las rutas, el diagnóstico se contamina.

• Cambiar el dominio CDN sin regenerar URLs de recursos ya optimizados.
• Combinar minificación y reescritura de assets sin probar primero por separado.
• Mantener reglas antiguas al migrar entre CDN con comportamiento distinto.
• Asumir que un 404 desaparece con una purga general cuando la causa real es una ruta mal resuelta.

Cuándo el problema apunta a SSL, CORS, cabeceras o reglas avanzadas

A veces el recurso no está realmente ausente, pero el navegador lo trata como fallido por otra razón. Si cambias a HTTPS y el asset sigue llamándose por HTTP, puede haber mixed content. Si un recurso se sirve desde otro dominio y depende de fuentes o peticiones cruzadas, revisa CORS en WordPress y en la CDN. También conviene confirmar que el servidor devuelve un tipo MIME coherente para CSS, JS, fuentes e imágenes.

En reglas avanzadas, sé prudente: protección anti-hotlink, bloqueos por referer, firewalls o reglas del proxy pueden devolver 403 o 404 enmascarados según el proveedor. Si el comportamiento cambia por país, agente de usuario o cabeceras, ya no estás ante una simple ruta rota.

Conclusión

Resolver 404 en estáticos tras CDN en WordPress exige separar capas: primero origen, después URL final del recurso, luego cabeceras y, por último, caché y reglas avanzadas. La mayoría de incidencias se aclaran así sin tocar ajustes a ciegas.

Como regla práctica, evita modificar WordPress, CDN y servidor al mismo tiempo. Si el problema afecta a producción, tráfico o Core Web Vitals, lo razonable es hacer un diagnóstico técnico controlado para confirmar en qué capa se rompe la entrega antes de aplicar cambios permanentes.