Seguridad en la estructura de carpetas de WordPress: Cómo bloquear el acceso a la carpeta "wp-includes"

Seguridad en la estructura de carpetas de WordPress implica que la forma más segura de bloquear el acceso directo a la carpeta "wp-includes" no es impedir el acceso total a toda la carpeta, sino evitar que los archivos PHP dentro de ella se ejecuten desde el exterior y desactivar la visualización del listado de directorios. Esto se debe a que wp-includes contiene JavaScript, CSS y algunos archivos estáticos esenciales para el funcionamiento del núcleo de WordPress; bloquear el acceso completo puede romper el diseño del sitio, el editor o funcionalidades de plugins. La mejor práctica es, si usas Apache, aplicar reglas en el archivo .htaccess, o si usas Nginx, configurar bloques location en el servidor para bloquear el acceso directo a PHP, y luego validar el sitio con respuestas 403/404 y pruebas exhaustivas.

Uno de los errores más comunes en la seguridad de WordPress es confiar únicamente en contraseñas fuertes o plugins de seguridad. Los atacantes suelen escanear directorios que contienen archivos del núcleo, plugins desactualizados, permisos incorrectos y listados de directorios abiertos. La carpeta wp-includes es un blanco frecuente de estos escaneos. En esta guía encontrarás pasos prácticos para limitar el acceso a wp-includes en entornos reales de hosting, qué reglas pueden romper tu sitio, ejemplos para Apache y Nginx, métodos de prueba y una lista de verificación para mantenimiento. Además, para una infraestructura más segura, puedes considerar opciones como Alojamiento WordPress y para una capa adicional de protección certificado SSL.

¿Qué es la carpeta wp-includes y por qué debe protegerse?

La carpeta wp-includes es uno de los directorios principales que contienen las bibliotecas fundamentales del núcleo de WordPress. Dentro de esta carpeta se encuentran el sistema de temas, el editor de bloques, componentes de la REST API, procesamiento de medios, clases, funciones y varios archivos JavaScript. En pocas palabras, wp-includes es una de las "salas de máquina" de WordPress; no es un espacio que los usuarios deban visitar directamente.

Un usuario normal no debería tener que abrir una dirección como sitio.com/wp-includes/. Sin embargo, algunos activos estáticos dentro de wp-includes pueden verse en el código fuente de la página. Por ejemplo, scripts predeterminados de WordPress, scripts de emojis o componentes del editor pueden cargarse desde esta carpeta. Por eso, al implementar medidas de seguridad hay que apuntar bien: bloquear el acceso web directo a archivos PHP sin afectar la carga de archivos estáticos.

Esta distinción es la base del enfoque profesional para la seguridad en la estructura de carpetas de WordPress. Bloquear carpetas indiscriminadamente puede parecer seguro a corto plazo, pero en el sitio en producción puede provocar páginas en blanco, paneles de administración rotos, editor de bloques inutilizable o fallos en la apariencia del tema. El objetivo es proteger los archivos necesarios para WordPress mientras se reduce la superficie de ataque.

¿Qué beneficios aporta bloquear el acceso a wp-includes?

Impedir la ejecución directa de PHP en la carpeta wp-includes no detiene todos los ataques por sí solo, pero reduce significativamente la superficie de ataque. En especial, en sitios infectados con malware, los atacantes intentan cargar archivos PHP maliciosos en directorios accesibles o llamar a archivos existentes. Prohibir la ejecución directa de PHP en wp-includes agrega una barrera extra en estos casos.

Esta medida ofrece las siguientes ventajas:

• Limita la llamada directa a archivos PHP del núcleo mediante URL.
• Ayuda a impedir la visualización del contenido de la carpeta si el listado de directorios está habilitado.
• Reduce la fuga innecesaria de información ante escaneos automáticos de bots.
• Proporciona protección a nivel de servidor web, incluso sin plugins de seguridad.
• Fortalece la seguridad en capas en conjunto con WAF, SSL, versiones actualizadas de PHP y permisos de archivos adecuados.

Es importante entender que esta es solo una capa más de seguridad. Si usas plugins desactualizados, contraseñas débiles o cuentas FTP comprometidas, esta regla por sí sola no es suficiente. La seguridad es la combinación del hosting, la aplicación, la gestión de usuarios y el mantenimiento periódico. Para una base sólida, puedes consultar contenido sobre Hosting Web Seguro y para protección adicional en la gestión de dominios Seguridad de Dominio.

Errores comunes al bloquear wp-includes

Bloquear toda la carpeta

Uno de los errores más frecuentes es bloquear todas las peticiones HTTP a la carpeta wp-includes con un código 403. Esto puede parecer lógico, pero WordPress carga algunos recursos estáticos desde esta carpeta, lo que puede generar problemas inesperados. Por ejemplo, el editor de bloques puede no abrirse, algunos archivos JavaScript no cargarse o el diseño del frontend puede mostrar fallos pequeños pero críticos.

Aplicar la regla sin probar en entorno de desarrollo

Un error mínimo en la configuración del archivo .htaccess o del servidor Nginx puede generar un error 500 Internal Server Error. Implementar directamente en un sitio con mucho tráfico sin pruebas es arriesgado. Es recomendable hacer una copia de seguridad, probar en un entorno staging si está disponible y luego hacer el cambio controladamente en producción. Si usas Hostragons, puedes aprovechar las opciones de staging o backup que se describen en Copia de Seguridad de Alojamiento Web.

Confiar exclusivamente en plugins de seguridad

Los plugins de seguridad son útiles, pero las reglas a nivel de servidor bloquean las peticiones antes de llegar a PHP, lo que reduce el consumo de recursos. Por eso, aunque uses plugins, no debes descuidar las reglas básicas del servidor.

Lista de verificación antes de aplicar

Prepararse antes de limitar el acceso a wp-includes reduce considerablemente el riesgo de interrupciones. Esta lista es especialmente recomendada para sitios WordPress en producción:

• Hacer copia de seguridad de la configuración actual de .htaccess o Nginx.
• Actualizar el núcleo de WordPress, temas y plugins.
• Asegurarse de que la versión de PHP sea soportada y segura.
• Verificar los permisos de archivos: carpetas normalmente 755, archivos 644.
• No dejar permisos de escritura innecesarios en archivos críticos como wp-config.php o .htaccess.
• Si usas caché, CDN o plugins de seguridad, planificar limpiar la caché después del cambio.
• Crear una lista de pruebas para áreas críticas como el panel admin, página principal, entradas, formularios de contacto y páginas de pago.

Esta preparación toma entre 10 y 15 minutos, pero evita horas de interrupciones por errores de configuración. En sitios corporativos, es mejor hacer cambios en horarios de bajo tráfico.

Bloquear ejecución de PHP en wp-includes con .htaccess en Apache

En hosting compartido con Apache, el método más común es usar el archivo .htaccess. Añadiendo reglas adecuadas en el .htaccess en el directorio raíz de WordPress puedes bloquear llamadas específicas a PHP dentro de wp-includes. Antes de empezar, descarga una copia del archivo o crea un backup desde el panel de hosting.

Regla recomendada para .htaccess

La siguiente regla se enfoca en bloquear el acceso directo a PHP dentro de wp-includes mientras permite el acceso a archivos estáticos:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-includes/.*[.]php$ - [F,L]
</IfModule>

La lógica es sencilla: si la URL comienza con wp-includes y termina en .php, la petición se bloquea con un error 403. Así, los archivos PHP dentro de wp-includes no se ejecutan desde el navegador, pero archivos .js, .css, .png, .svg y otros permanecen accesibles. Esto mantiene un equilibrio seguro para el frontend y el panel de administración.

Desactivar listado de directorios

Otra configuración importante es deshabilitar la visualización del contenido de las carpetas si no hay archivo index. Añade esta línea en el archivo .htaccess principal:

Options -Indexes

Esto impide que los usuarios vean listados de archivos en directorios sin index. La mayoría de hostings modernos lo tienen desactivado por defecto, pero es buena práctica confirmarlo.

Pruebas tras aplicar los cambios

Después de añadir las reglas, realiza estas comprobaciones:

• Accede a site.com/wp-includes/ y verifica que no se muestre el listado de archivos.
• Intenta acceder directamente a un archivo PHP conocido dentro de wp-includes y confirma que recibes un error 403 o 404.
• Revisa que la página principal, entradas y panel de administración funcionen correctamente.
• En las herramientas de desarrollador del navegador, revisa en las pestañas Console y Network si aparecen errores 403 o 404 inesperados.
• Si usas caché o CDN, limpia la caché para que los cambios se reflejen.

Si todo funciona bien, puedes dejar la regla activa en producción. Si ves error 500, elimina la regla y restaura el backup para recuperar la funcionalidad rápidamente.

Bloquear ejecución de PHP en wp-includes en Nginx

En servidores VPS, dedicados o gestionados con Nginx, .htaccess no funciona. Debes añadir la regla en el archivo de configuración del sitio, normalmente dentro del bloque server. Para esto necesitas acceso SSH y permisos para editar archivos de configuración. Si no tienes experiencia, es mejor pedir ayuda al soporte de hosting.

Regla recomendada para Nginx

El siguiente bloque deniega todas las peticiones a archivos PHP dentro de wp-includes:

location ~* ^/wp-includes/.*[.]php$ {
deny all;
}

Después de cambiar la configuración, prueba la sintaxis con:

nginx -t

Si no hay errores, recarga Nginx con:

systemctl reload nginx

El comando reload es más seguro que restart porque no interrumpe conexiones activas. De todos modos, haz cambios en horarios de baja carga en sitios críticos.

Consejos al usar Nginx

• Asegúrate de añadir la regla en el bloque server correcto, especialmente si alojas múltiples sitios en el mismo servidor.
• Si usas CDN o proxy inverso, limpia la caché para realizar pruebas reales.
• Verifica que PHP-FPM solo procese los archivos necesarios.
• Revisa logs de acceso y errores para detectar problemas con la regla.

El orden de las reglas location en Nginx es importante para evitar conflictos con el procesamiento de URLs amigables y PHP. Comprueba que no interfiera con otras configuraciones de WordPress.

Comparativa de métodos

La siguiente tabla resume las principales opciones para limitar el acceso a wp-includes:

La mejor protección se logra combinando estos métodos. Por ejemplo, en hosting Apache, aplicar regla en .htaccess, mantener permisos correctos, usar núcleo actualizado, SSL y backups regulares crea una defensa en capas. En entornos empresariales, elegir un hosting con firewall e aislamiento adecuado como Hosting Corporativo marca la diferencia.

Permisos y propiedad de archivos

Bloquear el acceso a wp-includes será insuficiente si los permisos son incorrectos. En WordPress, los permisos recomendados son 755 para carpetas y 644 para archivos. Estos permiten que el servidor web lea los archivos sin otorgar permisos de escritura innecesarios. Algunos hostings tienen configuraciones de usuario y grupo distintas, por lo que es recomendable seguir las recomendaciones del panel de control.

Permisos 777 son un riesgo grave de seguridad, ya que permiten escritura a todos, facilitando la carga de archivos maliciosos. Incluso en carpetas que deben ser escribibles como wp-content/uploads, hay que impedir la ejecución de PHP. La carpeta wp-includes normalmente no debe ser escribible por el usuario.

En una auditoría de seguridad, se pueden revisar estos permisos:

• Carpeta wp-includes: generalmente 755
• Archivos PHP dentro de wp-includes: generalmente 644
• Archivo wp-config.php: idealmente 600 o permisos aún más restrictivos según el hosting
• Archivo .htaccess: normalmente 644, sin permisos de escritura innecesarios tras la configuración

Estos valores pueden variar según el servidor. Permisos incorrectos pueden impedir actualizaciones o lectura adecuada de archivos. Después de cambios, revisa el estado de salud de WordPress y los logs de errores.

¿Los plugins de seguridad aplican esta protección?

Plugins como Wordfence o iThemes Security pueden sugerir reglas de endurecimiento (hardening) automáticamente. Estos plugins ofrecen protección contra fuerza bruta, monitoreo de cambios en archivos, escaneo de malware y seguridad en login. Sin embargo, es importante comprobar qué hacen específicamente con el acceso a wp-includes.

Algunos agregan reglas en .htaccess automáticamente, otros solo protegen a nivel de aplicación. La protección a nivel de aplicación es posterior a la llegada de la petición a WordPress, por lo que no es tan temprana ni eficiente como la protección a nivel servidor. Por eso, la mejor práctica es combinar las reglas del plugin con configuraciones de servidor.

Si usas plugins de seguridad, verifica lo siguiente:

• Si el plugin añade reglas en .htaccess o Nginx para wp-includes.
• Que no haya conflictos entre reglas similares de diferentes plugins.
• Que tras actualizaciones del plugin no se modifiquen o eliminen las reglas importantes.
• Monitorea el impacto en rendimiento, cache y consumo de recursos del servidor.

Usar múltiples plugins de seguridad simultáneamente puede causar conflictos entre reglas de firewall, login y reescritura, afectando rendimiento o provocando bloqueos erróneos.

Cómo probar la protección de wp-includes: escenario práctico

Para asegurarte de que la protección está aplicada sin afectar el sitio, realiza este test de 7 pasos, válido desde pequeños negocios hasta proyectos de comercio electrónico:

• 1. Abre la página principal en una pestaña de incógnito y revisa que no haya problemas visuales.
• 2. Navega por una entrada del blog, página de categorías y página de resultados de búsqueda.
• 3. Ingresa al panel de administración, abre el editor de bloques y la biblioteca de medios.
• 4. En las herramientas de desarrollador del navegador, revisa la pestaña Console para errores.
• 5. En la pestaña Network, verifica que no se bloqueen archivos estáticos dentro de wp-includes.
• 6. Intenta acceder directamente a un archivo PHP dentro de wp-includes y confirma que la respuesta es 403 o 404.
• 7. Revisa los logs de error del servidor para identificar nuevos o recurrentes errores.

Esta prueba toma unos 5 minutos y detecta configuraciones erróneas rápidamente. En sitios con WooCommerce o procesos de pago, asegúrate también de probar el carrito, el pago y las cuentas de usuario. Un pequeño bloqueo de JavaScript puede afectar las conversiones.

Medidas adicionales para seguridad en la estructura de carpetas de WordPress

Proteger wp-includes es un buen comienzo, pero la seguridad debe abordarse de forma integral. Estas medidas adicionales reducen aún más la superficie de ataque:

• Mantén el núcleo actualizado en lugar de intentar ocultar la versión.
• Elimina temas y plugins no usados por completo.
• Usa nombres de usuario administrador difíciles de adivinar.
• Implementa autenticación de dos factores.
• Si no usas XML-RPC, limita su acceso.
• Aplica limitación de tasa o autenticación adicional en wp-login.php.
• Realiza copias de seguridad automáticas diarias y prueba su restauración.
• Usa HTTPS en todo el sitio; sin SSL las credenciales están expuestas.

SSL no bloquea el acceso a wp-includes, pero es fundamental para proteger sesiones de usuario, datos de formularios y el tráfico del panel. Por eso, en guías de seguridad, SSL es siempre una de las primeras capas. Puedes consultar enlaces naturales como comprar certificado SSL y Instalación de SSL gratuita.

¿Cuándo deberías buscar ayuda profesional?

Agregar una regla .htaccess en un hosting Apache básico suele ser manejable para la mayoría de usuarios. Pero si tienes configuraciones avanzadas con Nginx, redes multisite, tienda WooCommerce, sitio de noticias con mucho tráfico o portales corporativos, es recomendable contar con soporte profesional. La regla debe ser técnicamente correcta y además implementarse de forma segura para garantizar continuidad del negocio.

Se recomienda ayuda experta en estos casos:

• Si alojas múltiples sitios WordPress en un solo servidor.
• Si usas simultáneamente Nginx, Varnish, CDN y WAF.
• Si tras cambios incrementan los errores 403, 404 o 500.
• Si tu sitio ha sufrido infecciones previas de malware.
• Si manejas sistemas de pago, membresías o datos personales sensibles.

Un hosting seguro, aislamiento correcto, backups periódicos y soporte especializado son piezas clave en la seguridad de WordPress que muchas veces pasan desapercibidas. Al elegir hosting, no solo consideres espacio en disco; evalúa respaldo, firewall, soporte PHP actualizado, gestión SSL y calidad de soporte técnico. En este sentido, los contenidos Paquetes de Hosting Hostragons y Migración de Sitio WordPress pueden ser útiles.

Conclusión

En la seguridad de la estructura de carpetas de WordPress, la forma correcta de bloquear el acceso a wp-includes no es impedir el acceso total a la carpeta sino bloquear el acceso web directo a los archivos PHP dentro de ella y desactivar el listado de directorios. Esto puede implementarse rápidamente con reglas .htaccess en Apache o bloques location en Nginx, siempre respaldando antes los archivos y probando exhaustivamente el sitio.

En resumen: no bloquees archivos estáticos, limita el acceso a PHP, desactiva el listado de carpetas, revisa los permisos y mantén todo actualizado. Para una infraestructura WordPress más segura y manejable, revisa las soluciones de hosting, dominio y SSL de Hostragons y busca el soporte adecuado para tu caso.

Preguntas frecuentes

¿Es seguro bloquear toda la carpeta wp-includes?

Generalmente no se recomienda. En wp-includes hay JavaScript, CSS y archivos estáticos necesarios para WordPress. Bloquear todo puede romper el diseño o el panel de administración. La opción más segura es bloquear solo el acceso directo a archivos PHP.

¿Qué hago si después de añadir la regla en .htaccess recibo error 500?

Primero, elimina las reglas que añadiste o restaura el archivo .htaccess desde la copia de seguridad. Luego, revisa la sintaxis de la regla para corregir errores. Si continúa el problema, revisa los logs de error del hosting o pide ayuda técnica.

¿Funciona .htaccess en servidores Nginx?

No. .htaccess solo es compatible con Apache y LiteSpeed. En Nginx, restricciones similares se aplican en los archivos de configuración del servidor mediante bloques location, y debes probar la configuración con nginx -t antes de recargar el servicio.

¿Esta medida hace que mi sitio WordPress sea 100% seguro?

No. Bloquear el acceso a PHP en wp-includes es una capa importante, pero no suficiente. Debes combinar actualizaciones, contraseñas fuertes, autenticación de dos factores, SSL, backups, firewall y permisos adecuados.

Si uso plugins de seguridad, ¿debo añadir también reglas para wp-includes?

Depende del plugin. Algunos agregan reglas en .htaccess, otros solo protegen a nivel de aplicación. Para evitar conflictos, lo ideal es combinar reglas a nivel servidor con la protección del plugin para una seguridad más robusta.