Los archivos ocultos que saturan tu servidor WordPress y por qué importa

Abre el directorio raíz de cualquier sitio WordPress de larga vida por SFTP y encontrarás archivos que no deberían estar ahí. 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álculo exportadas por plugins. Volcados SQL que quedaron de una migración del año pasado. El sitio sigue funcionando, así que nadie los elimina, y se van acumulando.

La mayoría son basura inofensiva. Algunos son graves riesgos de seguridad y SEO. El problema es que muy pocos propietarios de sitios miran alguna vez, así que la línea entre unos y otros es invisible. Este artículo describe las categorías más comunes, por qué algunas importan y cómo auditar el directorio raíz con regularidad.

Copias de seguridad fechadas de archivos del tema

Una auditoría reciente en el sitio de una agencia de Sídney con la que trabajamos reveló decenas de estas. La carpeta del tema activo contenía 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ón de reversión local, y nunca eliminada.

WordPress no carga estos archivos, así que no afectan al comportamiento del sitio. Pero son accesibles públicamente por su URL. Cualquiera que adivine el nombre del archivo puede leer el código fuente de versiones pasadas, que puede incluir credenciales, rutas escritas a mano o firmas de funciones vulnerables. Además, dificultan cada auditoría futura porque saturan el código con archivos que parecen reales pero no lo son.

El lugar correcto para las copias de código es el control de versiones, no el servidor en producción. Muévelas a git y elimina las copias fechadas.

Volcados SQL y archivos de copia de seguridad

Un archivo SQL con la exportación de la base de datos en el directorio raíz es uno de los artefactos más peligrosos de un sitio WordPress. Si un atacante lo descarga, tiene tu tabla de usuarios, tus contraseñas cifradas, tus claves secretas a través de wp_options y todo el contenido. Lo mismo aplica a los archivos comprimidos con la copia completa del sitio.

Los archivos de copia de seguridad nunca deberían vivir en el directorio raíz. Deben estar fuera del sitio, en una ubicación de almacenamiento que la web pública no pueda alcanzar. Si encuentras cualquier archivo de copia en el directorio raíz, elimínalo de inmediato y revisa los registros de acceso de tu hosting por si hubo descargas previas.

Copias de configuración como wp-config.bak

El error clásico. Un desarrollador va a hacer un cambio de configuración. Copia wp-config.php a wp-config.bak como red de seguridad. Hace el cambio. Deja la copia atrás. La extensión .bak no la ejecuta PHP, así que el archivo se sirve como texto plano. Cualquier atacante que pruebe el nombre obvio tiene tu configuración completa, incluidas las credenciales de la base de datos y los salts.

Nunca dejes una copia de wp-config de ninguna forma en el servidor en producción. Usa control de versiones. Si tienes que copiar, copia a una ruta fuera del directorio raíz y elimínala en cuanto termine el trabajo.

Archivos de prueba e info.php

Muchos desarrolladores crean un pequeño archivo info.php con phpinfo para confirmar la versión 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ón de PHP, extensiones cargadas, rutas del servidor, variables de entorno, a veces más.

Cualquier archivo de prueba, por inocente que parezca, debería eliminarse una vez cumplida su función. info.php, test.php, hello.html, cualquier cosa que no necesites en el sitio público no pinta nada ahí.

Páginas y carpetas que ensombrecen URLs de WordPress

Este es el peligroso. Si en el disco existe una carpeta con el mismo nombre que una página de WordPress, el servidor web resuelve primero la carpeta. El enrutamiento de URLs de WordPress nunca tiene ocasión de gestionar la petición. El visitante ve el contenido de la carpeta, no la página de WordPress.

El caso de la agencia de Sídney que hemos mencionado era exactamente este patrón. El atacante creó cinco carpetas en la raíz, nombradas para imitar páginas reales de WordPress. Los archivos dentro de esas carpetas interceptaban cada petición a esas URLs y servían spam SEO encubierto. El propietario no tenía ni idea, porque el panel de WordPress seguía mostrando las páginas originales, y una visita casual a la portada parecía normal.

Audita el directorio raíz específicamente en busca de carpetas que coincidan con los slugs de páginas de WordPress. Todo lo que no puedas justificar es sospechoso.

Archivos de intercambio del editor y directorios de control de versiones

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ás. A menudo contienen el mismo contenido que el archivo original, pero PHP no los ejecuta, así que se sirven como texto plano si se accede a ellos por URL.

Peor aún, un directorio .git dejado en el directorio raíz puede exponer todo el repositorio, incluidos commits pasados, ramas y secretos históricos. Esto ha sido la causa de varias brechas de gran repercusión a lo largo de los años. La carpeta .git nunca debería estar en un servidor en producción, o si lo está, debe bloquearse a nivel de servidor.

Cómo auditar

La auditoría es sencilla. Conéctate por SFTP o mediante el gestor de archivos de tu hosting. Explora el directorio raíz. Todo lo que esté fuera de los archivos estándar del núcleo de WordPress en la raíz, más las carpetas wp-admin, wp-includes y wp-content, debería investigarse. Todo lo que haya dentro de wp-content que no sea themes, plugins, uploads, mu-plugins o una carpeta de caché conocida merece una mirada más de cerca.

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én activos y plantéate eliminarlos por completo. Dentro de uploads, busca archivos PHP. No debería haber casi ninguno.

Con qué frecuencia

Mensual es razonable para un sitio de empresa. Trimestral es el mínimo. Después de cualquier trabajo de desarrollo que implicara cambios de archivos directamente en el servidor en producción. Después de cualquier incidente, por pequeño que sea.

¿Necesitas ayuda?

Si quieres que se audite el directorio raíz de tu sitio WordPress y se limpie todo lo que sobra, Defyn puede encargarse. Es una tarea silenciosa que a menudo saca a la luz problemas que nadie más había notado.