Abre el directorio ra\u00edz de cualquier sitio WordPress de larga vida por SFTP y encontrar\u00e1s archivos que no deber\u00edan estar ah\u00ed. Viejas copias de seguridad de desarrolladores con nombres como functions24-02-2026.php. Archivos de prueba olvidados como info.php. Archivos comprimidos de instalaciones anteriores. Hojas de c\u00e1lculo exportadas por plugins. Volcados SQL que quedaron de una migraci\u00f3n del a\u00f1o pasado. El sitio sigue funcionando, as\u00ed que nadie los elimina, y se van acumulando.<\/p>
La mayor\u00eda son basura inofensiva. Algunos son graves riesgos de seguridad y SEO. El problema es que muy pocos propietarios de sitios miran alguna vez, as\u00ed que la l\u00ednea entre unos y otros es invisible. Este art\u00edculo describe las categor\u00edas m\u00e1s comunes, por qu\u00e9 algunas importan y c\u00f3mo auditar el directorio ra\u00edz con regularidad.<\/p>
Una auditor\u00eda reciente en el sitio de una agencia de S\u00eddney con la que trabajamos revel\u00f3 decenas de estas. La carpeta del tema activo conten\u00eda functions24-02-2026.php, header31-01-2026.php, footer19-01-2026.php, 404-04-08-2025.php y una larga lista de archivos hermanos fechados de forma similar. Cada uno era una copia de seguridad del desarrollador creada antes de un cambio, pensada como opci\u00f3n de reversi\u00f3n local, y nunca eliminada.<\/p>
WordPress no carga estos archivos, as\u00ed que no afectan al comportamiento del sitio. Pero son accesibles p\u00fablicamente por su URL. Cualquiera que adivine el nombre del archivo puede leer el c\u00f3digo fuente de versiones pasadas, que puede incluir credenciales, rutas escritas a mano o firmas de funciones vulnerables. Adem\u00e1s, dificultan cada auditor\u00eda futura porque saturan el c\u00f3digo con archivos que parecen reales pero no lo son.<\/p>
El lugar correcto para las copias de c\u00f3digo es el control de versiones, no el servidor en producci\u00f3n. Mu\u00e9velas a git y elimina las copias fechadas.<\/p>
Un archivo SQL con la exportaci\u00f3n de la base de datos en el directorio ra\u00edz es uno de los artefactos m\u00e1s peligrosos de un sitio WordPress. Si un atacante lo descarga, tiene tu tabla de usuarios, tus contrase\u00f1as cifradas, tus claves secretas a trav\u00e9s de wp_options y todo el contenido. Lo mismo aplica a los archivos comprimidos con la copia completa del sitio.<\/p>
Los archivos de copia de seguridad nunca deber\u00edan vivir en el directorio ra\u00edz. Deben estar fuera del sitio, en una ubicaci\u00f3n de almacenamiento que la web p\u00fablica no pueda alcanzar. Si encuentras cualquier archivo de copia en el directorio ra\u00edz, elim\u00ednalo de inmediato y revisa los registros de acceso de tu hosting por si hubo descargas previas.<\/p>
El error cl\u00e1sico. Un desarrollador va a hacer un cambio de configuraci\u00f3n. Copia wp-config.php a wp-config.bak como red de seguridad. Hace el cambio. Deja la copia atr\u00e1s. La extensi\u00f3n .bak no la ejecuta PHP, as\u00ed que el archivo se sirve como texto plano. Cualquier atacante que pruebe el nombre obvio tiene tu configuraci\u00f3n completa, incluidas las credenciales de la base de datos y los salts.<\/p>
Nunca dejes una copia de wp-config de ninguna forma en el servidor en producci\u00f3n. Usa control de versiones. Si tienes que copiar, copia a una ruta fuera del directorio ra\u00edz y elim\u00ednala en cuanto termine el trabajo.<\/p>
Muchos desarrolladores crean un peque\u00f1o archivo info.php con phpinfo para confirmar la versi\u00f3n de PHP en un servidor nuevo, y luego olvidan borrarlo. El archivo queda accesible, y phpinfo vuelca una enorme cantidad de detalles del servidor que los atacantes pueden usar para planear un ataque. Versi\u00f3n de PHP, extensiones cargadas, rutas del servidor, variables de entorno, a veces m\u00e1s.<\/p>
Cualquier archivo de prueba, por inocente que parezca, deber\u00eda eliminarse una vez cumplida su funci\u00f3n. info.php, test.php, hello.html, cualquier cosa que no necesites en el sitio p\u00fablico no pinta nada ah\u00ed.<\/p>
Este es el peligroso. Si en el disco existe una carpeta con el mismo nombre que una p\u00e1gina de WordPress, el servidor web resuelve primero la carpeta. El enrutamiento de URLs de WordPress nunca tiene ocasi\u00f3n de gestionar la petici\u00f3n. El visitante ve el contenido de la carpeta, no la p\u00e1gina de WordPress.<\/p>
El caso de la agencia de S\u00eddney que hemos mencionado era exactamente este patr\u00f3n. El atacante cre\u00f3 cinco carpetas en la ra\u00edz, nombradas para imitar p\u00e1ginas reales de WordPress. Los archivos dentro de esas carpetas interceptaban cada petici\u00f3n a esas URLs y serv\u00edan spam SEO encubierto. El propietario no ten\u00eda ni idea, porque el panel de WordPress segu\u00eda mostrando las p\u00e1ginas originales, y una visita casual a la portada parec\u00eda normal.<\/p>
Audita el directorio ra\u00edz espec\u00edficamente en busca de carpetas que coincidan con los slugs de p\u00e1ginas de WordPress. Todo lo que no puedas justificar es sospechoso.<\/p>
Algunos editores de texto crean archivos de intercambio temporales cuando editas un archivo: sufijos .swp, ~, .orig y similares. Si un desarrollador edita un archivo directamente en el servidor, estos pueden quedar atr\u00e1s. A menudo contienen el mismo contenido que el archivo original, pero PHP no los ejecuta, as\u00ed que se sirven como texto plano si se accede a ellos por URL.<\/p>
Peor a\u00fan, un directorio .git dejado en el directorio ra\u00edz puede exponer todo el repositorio, incluidos commits pasados, ramas y secretos hist\u00f3ricos. Esto ha sido la causa de varias brechas de gran repercusi\u00f3n a lo largo de los a\u00f1os. La carpeta .git nunca deber\u00eda estar en un servidor en producci\u00f3n, o si lo est\u00e1, debe bloquearse a nivel de servidor.<\/p>
La auditor\u00eda es sencilla. Con\u00e9ctate por SFTP o mediante el gestor de archivos de tu hosting. Explora el directorio ra\u00edz. Todo lo que est\u00e9 fuera de los archivos est\u00e1ndar del n\u00facleo de WordPress en la ra\u00edz, m\u00e1s las carpetas wp-admin, wp-includes y wp-content, deber\u00eda investigarse. Todo lo que haya dentro de wp-content que no sea themes, plugins, uploads, mu-plugins o una carpeta de cach\u00e9 conocida merece una mirada m\u00e1s de cerca.<\/p>
Dentro de la carpeta del tema activo, busca copias fechadas, archivos de prueba y restos del editor. Dentro de la carpeta de plugins, busca plugins que no est\u00e9n activos y plant\u00e9ate eliminarlos por completo. Dentro de uploads, busca archivos PHP. No deber\u00eda haber casi ninguno.<\/p>
Mensual es razonable para un sitio de empresa. Trimestral es el m\u00ednimo. Despu\u00e9s de cualquier trabajo de desarrollo que implicara cambios de archivos directamente en el servidor en producci\u00f3n. Despu\u00e9s de cualquier incidente, por peque\u00f1o que sea.<\/p>