Errores 404 en elementos estáticos ralentizan la navegación

Cuando accedes a una dirección que no existe en WordPress, este devolverá un error 404 de "página no encontrada" con el diseño de tu propia plantilla, lo cual es una acción lógica puesto que mantiene un flujo de navegación familiar al visitante.

El problema puede surgir cuando una página llama a una imagen, CSS o JavaScript inexistente y la configuración del servidor envía también esa petición a WordPress. No ocurre en todos los servidores: confirma primero qué proceso genera la respuesta 404.

Conviene entender la diferencia de coste. En una configuración que sirve recursos estáticos directamente, un fichero existente no necesita iniciar PHP; el tiempo real depende del servidor y de la red. Un fichero que no existe cae en el enrutado de WordPress, que arranca la aplicación entera, carga los plugins, consulta la base de datos y compone la página 404 de tu plantilla. En un caso real medido en nuestros servidores, cada uno de esos 404 devolvía 28 KB de página renderizada, mientras que el mismo error servido por el servidor web ocupaba 796 bytes.

Si la propia plantilla 404 vuelve a solicitar el recurso ausente, cada error puede generar peticiones adicionales. Para relacionarlas con una sobrecarga, comprueba que coincidan en hora y ruta con el aumento de procesos o del tiempo de respuesta.

Cómo detectarlo

El consumo de CPU alto y varios procesos PHP sobre index.php son indicios, no la causa confirmada. Para comprobar la relación, revisa el registro de accesos en cPanel desde Métricas → Accesos sin procesar.

Busca en él la misma URL repetida muchas veces. Ejemplo basado en el caso, con dirección y dominio de documentación:

192.0.2.10 - - [09/Aug/2026:22:36:03 +0200] "GET /wp-content/plugins/popup-maker/dist/packages/block-library-style.css?ver=7424eb959f91acb8bbb2 HTTP/1.1" 404 28113 "-" "WordPress/6.8.7; https://www.midominio.com"

Hay dos detalles que delatan el problema:

• La IP coincide con la del servidor y el agente declara WordPress. En ese caso concreto era una petición interna; en otro registro hay que contrastar ambos datos antes de afirmarlo.
• El código es 404 y el tamaño era de decenas de kilobytes. Esa medición era compatible con la página renderizada por el tema, pero debes comprobar tu propia respuesta.

En ese caso concreto la web se pedía el mismo CSS inexistente unas seis veces por minuto, de forma ininterrumpida durante semanas, y llegaba a agotar el límite de CPU de la cuenta.

La solución: no dejar que WordPress gestione esos 404

La solución principal es eliminar la referencia al contenido inexistente. Si has confirmado que esas solicitudes entran en WordPress, la siguiente regla actúa como red de seguridad y hace que el servidor responda antes para las extensiones indicadas.

Antes de modificarlo, descarga una copia del .htaccess actual para poder restaurarlo si la web devuelve un error 500. Para desactivar la gestión de los errores 404 en archivos estáticos, añade después el siguiente bloque:

# BEGIN 404 ESTATICOS
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} \.(gif|jpe?g|png|webp|avif|svg|ico|css|js|map|woff2?|ttf|eot)$ [NC]
RewriteRule ^ - [R=404,L]
</IfModule>
# END 404 ESTATICOS

Las dos primeras condiciones dejan pasar cualquier fichero o directorio que sí exista, de modo que solo actúa sobre lo que falta. La tercera limita la regla a extensiones de contenido estático y normalmente deja fuera las direcciones de la web que no llevan extensión. Merece la pena incluir las fuentes (woff, woff2, ttf, eot) y los mapas de código (map), que son de lo que más 404 silenciosos genera una plantilla.

Dónde colocar el bloque

Busca en el fichero la línea # BEGIN WordPress y pega el bloque justo encima. Déjalo fuera de cualquier bloque que un plugin gestione automáticamente.

El motivo de que vaya encima de # BEGIN WordPress es que ese bloque es precisamente el que envía a index.php todo lo que no existe en disco. Si lo pones después, WordPress ya se habrá quedado con la petición.

No lo sitúes por delante de las reglas de LiteSpeed Cache: podrías interceptar una URL que el plugin necesita reescribir. Como los bloques varían según la instalación, prueba una imagen optimizada existente y una URL inventada antes de mantener el cambio.

Comprueba también que ErrorDocument 404 no apunte a PHP. Si usas ErrorDocument 404 /404.shtml, verifica que ese fichero exista, sea estático y no vuelva a pasar por WordPress.

Comprobar que funciona

Después de guardar el fichero, abre estas tres direcciones en tu navegador, sustituyendo midominio.com por el tuyo.

1. Tu web, para descartar una errata

https://midominio.com/

Debe cargar con normalidad. Si aparece un 500 o una pantalla en blanco justo después del cambio, restaura la copia y consulta el registro. Puede existir una errata, una directiva no permitida o una interacción con otras reglas; el código por sí solo no distingue la causa.

2. Un fichero estático que no existe, inventándote el nombre

https://midominio.com/esto-no-existe.css

Debe responder con código 404 y una página ligera servida sin cargar el diseño de WordPress. Su apariencia exacta depende de la configuración del servidor y de ErrorDocument.

Si en cambio te aparece la página de "no encontrado" con el diseño de tu plantilla, el menú y el pie, revisa el orden de la regla y ErrorDocument: puede ser este último el que envíe el error de nuevo a PHP.

3. Una página de tu web que no existe

https://midominio.com/esta-pagina-no-existe/

Aquí sí debes seguir viendo el 404 de tu plantilla, con su diseño de siempre. La regla solo intercepta direcciones inexistentes que terminan en una de las extensiones indicadas. Si tu aplicación utiliza rutas virtuales con esas extensiones, añade una exclusión específica y compruébalas antes de mantener la regla.

Esto es una red de seguridad, no el arreglo

El bloque abarata el error, pero la llamada al fichero que falta sigue produciéndose. Busca el origen con la pestaña Red de las herramientas de desarrollo del navegador, que te dirá qué recurso se está pidiendo y desde dónde.

La pestaña Iniciador y el registro permiten saber qué página o componente solicitó el recurso. Reinstala un plugin solo si has confirmado que el fichero debería pertenecer a ese paquete; si la referencia procede de una caché, purga esa caché después de corregirla.

Si quieres profundizar en el rendimiento de tu instalación, tienes la guía de optimización de WordPress y la de LiteSpeed Cache.

En la prueba de una URL inexistente usa también parámetros de consulta y mayúsculas en la extensión. Verifica cualquier endpoint virtual que termine en .js, .css o una extensión incluida antes de desplegar: la regla no sabe distinguirlo de un archivo ausente. Compara el código HTTP y la carga antes y después, manteniendo la corrección de la referencia como tarea principal.