Todo lo que deberías revisar si vas a auditar un web WordPress, o al menos lo que yo hago

Te llega una web WordPress que no has hecho tú, de la que nadie sabe darte detalles, y tienes que decidir si aceptas mantenerla, cuánto cobras por arreglarla o qué contarle al cliente en la consultoría. Para eso sirve una auditoría técnica: una revisión sistemática, área por área, que termina en un informe con prioridades claras y no en una lista infinita de cosas que «habría que mirar».

Las áreas habituales no son pocas, rondan la decena: entorno y servidor, núcleo de WordPress, tema, plugins, seguridad, rendimiento, SEO técnico, visibilidad IA y RGPD, más tienda online y multisitio si los hay.

Pues bien, hoy quiero compartir contigo cómo lo hacemos en mi servicio de mantenimiento de webs WordPress, y espero que te sea útil, no solo si también ofreces ese tipo de servicio, sino en otras posibles situaciones:

1. Asumes el mantenimiento de una web que no conoces y quieres saber dónde te metes antes de firmar, porque lo que no detectes hoy será tu problema mañana.
2. Te contratan una consultoría y necesitas diagnosticar el estado real de la web antes de recomendar nada.
3. Te encargan mejorar o rediseñar una web existente, o valorar una que tu cliente quiere comprar, y toca saber sobre qué base estás pisando.
4. Quieres analizar tu propia web para saber qué está bien, qué no, y cómo mejorarla de manera generalizada.

Igual que en la guía de auditoría de temas WordPress a medida, el artículo va en dos velocidades. Si prefieres no usar código cada bloque te dice qué puedes comprobar con herramientas visuales y qué pedirle a una IA, y si eres el técnico del proyecto tienes los comandos y el detalle que completan el trabajo.

Y aunque no tengas acceso por SSH ni por FTP, tranquilo, que en cada bloque te doy la manera de comprobar lo mismo desde el escritorio de WordPress, el panel del hosting o una herramienta, para que la falta de un acceso no te deje ningún bloque sin revisar.

Cada bloque de esta propuesta de estructura de auditoría clasifica los hallazgos en tres niveles, los mismos que luego usarás para priorizar el trabajo:

• Crítico (se corrige antes de cualquier otra cosa)
• Importante (se planifica en la próxima actuación)
• Menor (se documenta y se resuelve cuando toque pasar por ahí).

Vamos a verlo con calma.

Antes de tocar nada: accesos, contexto y red de seguridad

Una auditoría sin accesos completos es una auditoría a medias, así que lo primero es pedirle al cliente todo esto, y pedirlo por escrito, que luego las cosas se olvidan:

• Administrador de WordPress: un usuario propio para ti, nuevo, no el que se comparte media empresa por WhatsApp.
• Panel del hosting: sin él no puedes configurar versiones de PHP, base de datos, copias de seguridad con garantías ni logs del servidor.
• FTP/SFTP, WP-CLI o SSH: imprescindible para la velocidad técnica, y tu salvavidas si algo se rompe durante la revisión.
• Gestión del dominio y DNS: a veces está en un registrador distinto del hosting y nadie recuerda la contraseña, mejor descubrirlo ahora que durante una migración.
• Licencias de plugins y temas de pago: cuáles hay, quién las paga y desde qué cuenta se renuevan.
• Google Search Console, Bing Webmasters y Analytics: si existen, pide acceso; si no existen, ya tienes el primer hallazgo del informe.

Pide también contexto, que no todo son contraseñas: quién hizo la web, quién la ha tocado desde entonces, qué problemas recuerdan y si hay algo «que no se puede tocar porque se rompe». Esa última frase, cuando aparece, señala exactamente el sitio donde más falta hace la auditoría.

Y antes de nada, la red de seguridad: copia de seguridad completa, verificada y descargada fuera del servidor. La auditoría en sí no debería romper nada porque es observación, pero posiblemente vayas a activar plugins de diagnóstico y a hurgar en ajustes, y si algo falla quieres poder volver atrás sin depender de la copia (quizás inexistente, ya lo verás en el bloque de seguridad) del hosting.

Todo lo que sea intervención de verdad, en staging (una copia de pruebas de la web), nunca en producción.

Herramientas básicas

Para la velocidad sin código usa el modo depuración de WordPress con registro en archivo, el plugin oficial Health Check & Troubleshooting y la pantalla salud del sitio, que ya viene de serie en la pantalla de herramientas, y es el mejor punto de partida que regala WordPress. Con eso y tu IA de confianza cubres la mayor parte del recorrido.

Para todo lo que normalmente pedirías por FTP, el gestor de archivos del hosting (cPanel, Plesk, las Site Tools de SiteGround o prácticamente cualquier panel) te deja ver y editar ficheros y revisar permisos sin instalar nada ni abrir una consola, que es tu puente para casi todo lo que aquí resuelvo por línea de comandos.

Para la parte más técnica te recomiendo tener Query Monitor instalado durante la auditoría (y desinstalado después), WP-CLI por SSH para los comandos que irán apareciendo, y una hoja de cálculo o herramienta donde ir anotando hallazgos con su gravedad, porque una auditoría que no se documenta sobre la marcha es una auditoría que toca repetir.

Y si la caché no te deja ver el estado real de la web mientras investigas, el plugin Anti-Cache Kit vacía y desactiva de golpe los plugins de caché, activa el modo depuración y lo revierte todo al desactivarlo, con la misma regla que Query Monitor de activo mientras dura la auditoría, fuera al terminar.

Qué puedes auditar sin tener acceso ni una triste contraseña de nada

Mientras esperas los accesos (en la vida real tardan días, ya lo verás) puedes ir adelantando trabajo, porque una parte sorprendentemente amplia de la auditoría se puede hacer desde fuera, con la web pública y cuatro herramientas gratuitas.

La forma rápida de barrer casi todo este bloque es el análisis de seguridad WordPress de las herramientas gratuitas, que hace más de 30 comprobaciones externas de seguridad de una tacada, entre las que están algunas tan importantes como las cabeceras HTTP, certificado SSL, exposición de archivos, listas negras y bastantes más.

Lo anterior lo complementas con PageSpeed Insights para las métricas de experiencia real de usuarios, SSL Labs para el certificado a fondo y MXToolbox para DNS, listas negras y la salud del correo del dominio.

Lo del correo casi nadie lo mete en una auditoría web y luego pasa lo que pasa, y hay cosas que revisar, como los registros SPF, DKIM y DMARC (las firmas DNS que autorizan quién puede enviar correo en nombre del dominio), que determinan si los emails de la web (pedidos, formularios, recuperación de contraseña) llegan a la bandeja de entrada o mueren en spam.

De todo esto ya nos saldrá información que podemos empezar a clasificar.

Crítico

• Certificado SSL caducado, mal instalado o con la cadena incompleta: además del susto del navegador, invalida de facto todo lo demás.
• Dominio o IP en listas negras de spam o malware: hay que averiguar el porqué antes de seguir, puede ser herencia de una infección pasada o señal de una activa.
• Contenido mixto (recursos HTTP dentro de páginas HTTPS): candado roto, avisos al visitante y datos viajando sin cifrar.
• Sin SPF ni DMARC en un dominio que envía correo transaccional: entregabilidad a la ruleta y suplantación del dominio servida en bandeja.

Importante

• Cabeceras de seguridad ausentes (HSTS, X-Content-Type-Options o Referrer-Policy, entre otras): se resuelven en el bloque de seguridad, aquí solo se anotan.
• Métricas Web Principales no superadas en datos de campo: LCP por encima de 2,5 segundos o INP por encima de 200 ms en móvil apuntan maneras para el bloque de rendimiento.
• Versión de WordPress visible en el meta generator y archivos como readme.html accesibles: información regalada a cualquier escáner automático.

Menor

• Sin archivo security.txt (el estándar para que investigadores de seguridad sepan a quién avisar si encuentran algo).
• TTFB (el tiempo que tarda el servidor en empezar a responder) por encima de 800 ms desde ubicaciones cercanas al público del sitio: no es sentencia, pero es la primera pista de un hosting justito.

Entorno y servidor

Con los accesos ya en la mano, lo primero es analizar los cimientos de la web, porque ninguna optimización posterior compensa un servidor por debajo de mínimos. La pantalla de información de la salud del sitio te da casi todo el inventario sin salir de WordPress, y el panel del hosting completa el resto.

Para el técnico, wp cli info, wp core check-update y un vistazo a phpinfo() temporal (que borrarás al terminar, no como los que verás en el bloque de seguridad) cierran la foto.

Lo que hay que inventariar es el hosting y tipo de servidor (Apache, Nginx, LiteSpeed), versión de PHP y sus límites de memoria y ejecución, versión de MySQL o MariaDB, protocolo HTTP, compresión activa, sistema de copias del hosting, CDN si la hay y cómo está gestionado el cron.

Las referencias contra las que comparar las tienes siempre al día en la página oficial de requisitos de WordPress, que son versiones de PHP y base de datos mínimos y recomendados del momento. La regla que nunca caduca es que una versión de PHP sin soporte de seguridad es siempre un mal comienzo, aunque WordPress todavía la acepte, así que un servidor anclado en versiones viejas acumula papeletas más deprisa de lo que su dueño se imagina.

El cron merece párrafo propio, pues WordPress tiene su propio planificador de tareas (wp-cron) que se ejecuta cuando alguien visita la web, lo que significa que en webs con poco tráfico las tareas programadas se retrasan y en webs con mucho tráfico se dispara más de la cuenta.

La configuración sana en producción es desactivarlo con define( 'DISABLE_WP_CRON', true ); y sustituirlo por un cron real del servidor cada pocos minutos. Si encuentras publicaciones programadas que no se publicaron ya sabes por dónde empezar.

Crítico

• Versión de PHP sin soporte de seguridad (que el hosting te la ofrezca no la convierte en segura): sin parches ante vulnerabilidades nuevas, es la primera actualización a planificar, en staging y con calma.
• Sin copias de seguridad del hosting, o existentes pero jamás restauradas: una copia que nunca se ha probado a restaurar es una esperanza, no una copia.
• Correo transaccional saliente sin authentication por PHP con la función mail() en un dominio con SPF estricto: los correos de la web no llegan, y nadie se ha dado cuenta porque nadie los echa de menos hasta que hacen falta.

Importante

• Límite de memoria PHP por debajo de 256 MB en webs con WooCommerce o page builders: errores intermitentes difíciles de reproducir que desaparecen «solos».
• Función wp-cron sin sustituir por cron de sistema en webs de tráfico alto o muy bajo.
• Servidor sin HTTP/2 (ya ni hablamos de HTTP/3) o sin compresión Brotli/GZIP activa: rendimiento regalado que no cuesta dinero activar.
• Base de datos en MySQL 5.7 o MariaDB antiguas: funcionan, pero sin soporte y perdiendo mejoras de rendimiento considerables.

Menor

• Sin CDN en webs con público geográficamente disperso: mejora disponible, no urgencia.
• Espacio en disco o inodos cerca del límite del plan: hoy anécdota, el día que la web no pueda escribir ni una imagen, drama.
• Logs de error del servidor inaccesibles o desactivados: sin ellos, el próximo diagnóstico será a ciegas.

El núcleo de WordPress y ajustes que nadie revisa

Aquí se audita el WordPress en sí, o sea, la versión, integridad del sistema, configuración y usuarios. Es el bloque más rápido de revisar y donde aparecen algunos de los hallazgos más incómodos de explicar al cliente, porque casi todos se arreglaban con un clic que nadie hizo en su momento.

Sin necesidad de código, la herramienta de salud del sitio te dice versión, actualizaciones pendientes y problemas de configuración, y en los ajustes de lectura está la casilla más peligrosa de WordPress, la de disuadir a los motores de búsqueda, que en más de una web estrenada lleva años marcada sin que nadie sepa por qué el SEO no despega.

Repasa también los usuarios para saber cuántos administradores hay, si siguen en la empresa y si alguno se llama admin, que a estas alturas ya es casi una declaración de intenciones.

Con código, la comprobación estrella es la integridad del núcleo:

wp core verify-checksums
wp plugin verify-checksums --all

El primer comando compara cada archivo del núcleo con el original de WordPress.org y delata cualquier archivo modificado o añadido, que es una de las formas más rápidas de detectar una infección. El segundo hace lo mismo con los plugins del repositorio oficial.

Para realizar este tipo de comprobación si no tienes acceso a la interfaz de comandos puedes usar el scanner de integridad de archivos y la auditoría de seguridad del plugin de seguridad Vigilante.

En wp-config.php revisa que las claves y salts de seguridad existan y no sean las de ejemplo, que WP_DEBUG no esté activo en producción y si hay constantes útiles como DISALLOW_FILE_EDIT (desactiva el editor de código del admin, un clásico de la post-explotación).

Crítico

• Núcleo de WordPress varias versiones mayores por detrás: no es solo funcionalidad, cada versión sin aplicar es una lista pública de vulnerabilidades corregidas que la web sigue teniendo.
• Detectar con verify-checksums con archivos modificados o desconocidos en el núcleo: tratar como incidente de seguridad hasta demostrar lo contrario.
• Administradores que ya no trabajan en el proyecto con la cuenta activa, o cuentas compartidas entre varias personas: cada admin de más es una puerta de entrada más.
• Constantes WP_DEBUG con WP_DEBUG_DISPLAY activo en producción: rutas, consultas y errores del servidor impresos en pantalla para quien pase por allí.

Importante

• Actualizaciones automáticas del núcleo desactivadas del todo, sin proceso alternativo que las cubra: las menores de seguridad deberían estar siempre activas.
• Salts de seguridad de wp-config.php sin regenerar desde el año de la instalación, o iguales entre el sitio de producción y copias de staging que andan por ahí.
• Prefijo de tablas wp_ con usuarios y contraseñas heredados de instaladores automáticos antiguos: el prefijo en sí no es la muralla que algunos venden, pero el combo delata una instalación nunca revisada.
• Zona horaria, idioma o ajustes de comentarios sin configurar (bien): spam entrando a manta por comentarios abiertos sin moderación en entradas de hace cinco años, pingbacks y trackbacks activos, emails innecesarios.

Menor

• Etiqueta meta generator con la versión de WordPress en el HTML: información innecesaria de cara al exterior.
• Página «Hola mundo», página de ejemplo y temas de prueba aún publicados: cosmética, pero cosmética que retrata el nivel de mantenimiento que ha tenido la web.

El tema WordPress y sus personalizaciones

Al tema le dediqué una guía completa de auditoría de temas a medida, con análisis de código, seguridad, rendimiento y SEO bloque a bloque, así que no voy a repetirla aquí. Lo que sí forma parte de esta auditoría general es lo que el tema cuenta de sí mismo a nivel de instalación, sin abrir un solo archivo.

En Apariencia → Temas lo razonable a revisar es el tema activo, su tema padre si es un tema hijo, y un tema de respaldo reciente de los de WordPress (el Twenty Twenty-algo de turno) para pruebas y emergencias.

Todo lo demás sobra, y no por manía, pues cada tema instalado es código presente en el servidor que hay que mantener actualizado aunque esté inactivo, porque un tema desactivado también es explotable si tiene una vulnerabilidad.

Crítico

• Tema activo sin actualizaciones disponibles porque el desarrollador desapareció o la licencia caducó: la web funciona sobre código congelado y sin parches, decisión estratégica a poner sobre la mesa del cliente cuanto antes.
• Tema padre modificado directamente, sin tema hijo: la próxima actualización del padre borra los cambios sin avisar.

Importante

• Licencia del tema de pago sin saber quién la paga ni desde qué cuenta: mientras nadie lo aclare, las actualizaciones dependen de una renovación que quizás ya no existe.
• Media docena de temas instalados por si acaso: superficie de ataque y peso de mantenimiento sin beneficio alguno.
• Tema hijo con cambios sustanciales sin documentar: funciona, pero nadie sabe qué se tocó ni por qué, y eso en la práctica es deuda técnica heredada.

Menor

• Tema hijo con cabecera incompleta o style.css vacío: señal de creación con prisas, revisar que al menos esté bien construido.

Si el tema es a medida o hay mucho que revisar, ahí sí, guía completa de auditoría de temas que te comenté antes, y la herramienta gratuita de auditoría de temas WordPress para documentar los hallazgos y generar el informe.

Los plugins

Este es el bloque estrella de la auditoría, y no lo digo por decir, pues la inmensa mayoría de las vulnerabilidades que se descubren en el ecosistema WordPress están en los plugins, casi todo el resto en los temas y un puñado testimonial en el núcleo, año tras año en cada informe del sector.

La seguridad, el rendimiento y buena parte de los problemas raros de una web WordPress viven en su lista de plugins, así que aquí conviene ir despacio.

Lo primero es el inventario. Sin necesidad de código puedes revisar la pantalla de plugins con sus contadores, con código esta línea te da la foto completa lista para pegar en el informe:

wp plugin list --fields=name,status,version,update,auto_update

Y ahora, las preguntas que hay que hacerle a esa lista, una por una:

• ¿Cuántos hay y cuántos están activos?: Los inactivos son código explotable en el servidor. Se verifica que no hagan falta, se borran (no solo desactivar) y listo.
• ¿Cuáles están abandonados?: En la ficha de WordPress.org hay que mirar última actualización hace más de dos años, sin probar en las últimas tres versiones mayores o con el aviso naranja del repositorio. Un plugin abandonado no avisa, simplemente un día deja de funcionar o se convierte en el agujero por el que entran. Si tienes un plugin como Worfence o Vigilante te avisan en su scanner de plugins cerrados y abandonados.
• ¿Hay duplicidades funcionales?: Dos plugins de caché, dos de SEO, tres de seguridad pisándose las reglas entre sí. Pasa muchísimo más de lo que parece, y el resultado nunca es doble protección, es doble carga y conflictos.
• ¿Hay plugins de pago sin licencia?: Versiones pro que no se actualizan desde tiempos inmemoriales, o instaladas desde «clubs GPL» de dudosa procedencia. Además del riesgo legal que el cliente debe conocer, un plugin de pago sin licencia es un plugin sin actualizaciones, y sin actualizaciones no hay parches de seguridad.
• ¿Tiene alguno vulnerabilidades conocidas?: Se busca cada plugin con su versión exacta en Patchstack o WPScan. Si aparece con vulnerabilidad sin parchear, al primer puesto de la lista de acciones.
• ¿Cuánto cuesta cada uno en rendimiento?: Con Query Monitor ves qué plugin mete más consultas y más tiempo en cada carga. No se trata del número de plugins, que ese debate está más que visto y el problema nunca es la cantidad de plugis, es sobrecargar la web con código que no necesita. Cinco plugins bien programados y realmente necesarios pesan menos que un todo-en-uno hinchado.
• ¿Qué hay en mu-plugins y en los drop-ins?: La carpeta mu-plugins (plugins de activación obligatoria que no aparecen en la lista normal) y los drop-ins como object-cache.php o advanced-cache.php son los rincones que nadie mira, donde lo mismo vive una integración legítima del hosting que un regalo de un atacante con acceso pasado. En Plugins → Imprescindibles se listan los mu-plugins y, si hay plugins dependientes (drop-ins), aparece también su pestaña, y por consola los sacan wp plugin list --status=must-use y wp plugin list --status=dropin. Para asomarte a lo que hay dentro de esos archivos sin SSH, tira del gestor de archivos del hosting, que es justo el sitio donde un atacante esconde lo que no quiere que veas.
• ¿Qué dejaron los plugins desinstalados?: Tablas huérfanas en la base de datos, opciones con autoload y tareas cron que siguen ejecutándose contra nada. Lo retomamos en el bloque de rendimiento, pero se detecta aquí, comparando la lista de plugins con lo que hay en la base de datos.

Para algo rápido sin código hay truco, y es pegar la lista completa de plugins (nombre y versión) en tu IA de confianza con este prompt:

Esta es la lista de plugins de una instalación WordPress con sus versiones. Dime: 1) cuáles parecen abandonados o con mala reputación de mantenimiento; 2) qué duplicidades funcionales detectas; 3) cuáles tienen vulnerabilidades conocidas en esas versiones; 4) qué preguntas debería hacerle al propietario sobre licencias. Preséntalo como tabla con nivel de prioridad.

La respuesta no sustituye la comprobación en Patchstack o WPScan (la IA puede no conocer lo de esta semana), pero como primer barrido y detector de duplicidades funciona de maravilla.

Crítico

• Plugins con vulnerabilidades conocidas sin parchear en la versión instalada: actualización o retirada inmediata, antes de terminar la auditoría siquiera.
• Plugins nulled o de procedencia desconocida: retirada y sustitución, sin matices. Nunca sabes qué llevan dentro, y lo que llevan dentro a veces se llama puerta trasera.
• Plugins abandonados ocupando funciones primordial de la web (formularios, tienda, membresías): planificar sustitución ya, no cuando falle.

Importante

• Plugins inactivos acumulados sin verificar ni borrar.
• Duplicidades funcionales activas (especialmente caché y SEO): elegir uno, configurar bien y retirar el resto.
• Licencias de pago sin titular claro: documentar quién paga qué, cuánto y hasta cuándo, en el informe.
• Actualizaciones automáticas sin criterio: ni todo activado a lo loco en una web crítica sin staging, ni todo desactivado y sin nadie que actualice a mano. Lo importante es que haya una decisión consciente, no una casilla olvidada.

Menor

• Plugins de un solo uso puntual (un import de hace años, un generador de algo) que siguen instalados: fuera con ellos.
• Restos menores de plugins desinstalados en base de datos: se limpian en la fase de optimización, con copia previa.

La SEGURIDAD

Instalar un plugin de seguridad y darse por protegido es como comprar un extintor para tu casa y dejarlo en el maletero del coche, porque de algo servirá, pero no es un plan. Lo que se audita aquí es cuántas capas reales de protección tiene la web y cuántas cree tener, que suelen ser números distintos.

Sin tener que tirar de código, el barrido externo ya lo hiciste con el análisis de seguridad del bloque sin accesos, y ahora toca la parte interna, que es probar a mano si responden URLs que jamás deberían responder, como /debug.log, /.env, /phpinfo.php, el listado de directorios en /wp-content/uploads/ o copias de seguridad sueltas tipo backup.zip en la raíz.

Cada una de esas URLs respondiendo contenido es un hallazgo directo al informe, y más habitual de lo que te gustaría creer.

Pero hay un hallazgo que no está en ninguna URL suelta pero aparece más de lo que parece, como una copia de staging, de pre-producción o un clon viejo del sitio accesible al público, que Google indexa y un atacante estudia a placer para colarse por la de verdad.

Si das con una, hasta que decidas si la migras o la borras, lo suyo es cerrarla con acceso obligatorio, y para eso te vale un plugin como Gozer, que deja la web entera detrás del acceso con un clic.

Con código, además de los checksums que ya pasaste en el bloque del núcleo, toca comprobar permisos de archivos (directorios en 755, archivos en 644 y wp-config.php más restrictivo), probar xmlrpc.php (si responde y nadie lo usa para nada, se cierra), consultar /wp-json/wp/v2/users a ver si la web muestra la lista de usuarios a cualquiera (enumeración vía REST API), y revisar a fondo las cabeceras de seguridad que anotaste en el barrido externo.

Si no tienes consola no te preocupes que este bloque de auditoría no se te queda a medias, la propia comprobación de seguridad que trae el plugin Vigilante corre más de 40 chequeos desde dentro de WordPress, incluidos decenas que no se pueden hacer desde fuera, como los permisos de los archivos, los salts por defecto, el prefijo wp_, si hay algún administrador sin 2FA o si tu versión de PHP ya está fuera de soporte.

Así que buena parte de lo que sacarías por SSH lo tienes en una sola pantalla. Los permisos concretos también los ves y los cambias desde el gestor de archivos del hosting, y las URLs que no deberían responder las pruebas tú mismo en el navegador, que para eso no hace falta ni herramienta.

El modelo mental para el informe son 3 niveles de cortafuegos:

• CDN/perímetro (Cloudflare o similar por delante del servidor).
• Servidor (lo que ponga el hosting)
• Aplicación (plugin de seguridad bien configurado)

No son obligatorios los tres en toda web, pero hay que saber cuáles hay, y si la respuesta es «ninguno», eso es un problema, no una opinión.

Y la joya de la corona, las copias de seguridad, donde la regla razonable es la 3-2-1 (tres copias, en dos soportes, una fuera del servidor). La copia de seguridad del hosting cuenta como una, no como el plan entero, porque si el servidor arde o la cuenta se suspende, se llevan la web y la copia en el mismo incendio.

Crítico

• Malware o código inyectado detectado: se acabó la auditoría normal, toca protocolo de limpieza, y si el sitio es un tema a medida revisa la guía de detección de código malicioso antes de tocar nada.
• Archivos debug.log, .env o phpinfo.php accesibles públicamente: exposición directa de rutas, errores, credenciales o configuración del servidor.
• Sin identificación en dos pasos (2FA) en cuentas de administrador, combinado con login sin límite de intentos: la puerta principal abierta a fuerza bruta con toda la paciencia del mundo.
• Copias de seguridad inexistentes, solo en el propio servidor o nunca restauradas de prueba.
• Enumeración de usuarios abierta vía REST API o archivos de autor, con nombres de usuario que coinciden con los del login, con lo que la mitad del trabajo del atacante ya se la das hecha.

Importante

• Cabeceras de seguridad ausentes o incompletas (HSTS, CSP aunque sea básica, X-Frame-Options, Referrer-Policy).
• xmlrpc.php activo sin uso que lo justifique.
• Sin cortafuegos de aplicación ni plugin de seguridad configurado, o instalado con los ajustes de fábrica sin adaptar.
• Listado de directorios activo en uploads o directorios sensibles.
• Sin monitorización de cambios en archivos: para esto Vigilante es fundamental, es un plugin gratuito, escanea los archivos y te avisa si alguien modifica algo sin que lo sepas, que es exactamente lo que hace un atacante cuando planta una puerta trasera en un archivo que ya existía. La auditoría te dice cómo está la web hoy, Vigilante te avisa si deja de estarlo mañana.

Menor

• URL de acceso sin enmascarar: medida cosmética que reduce ruido de bots, no sustituye a nada de lo anterior, pero como higiene vale.
• Meta generator, readme.html y versiones visibles: ya anotado en el barrido externo, se resuelve junto al resto.
• Endpoint de Application Passwords activo sin uso conocido: revisar y cerrar si nadie lo necesita.

Rendimiento y velocidad de carga

Antes de tocar nada conviene separar dos mundos que se confunden constantemente. Me refiero a los datos de campo (lo que experimentan los usuarios reales, que es lo que Google usa para valorar la web) y, por otro lado, a los datos de laboratorio (la simulación que hace la herramienta de turno para diagnosticar).

El informe se abre con los de campo, que salen en PageSpeed Insights si la web tiene tráfico suficiente, y las referencias son las métricas web principales: LCP hasta 2,5 segundos, INP hasta 200 ms y CLS hasta 0,1. El laboratorio viene después, para averiguar el porqué de cada suspenso.

La revisión interna va por capas de caché, que en una web sana son varias y coordinadas:

• Caché de página (el plugin de turno o la del hosting, uno solo y bien configurado)
• Caché de objetos (Redis o Memcached si el hosting la ofrece, imprescindible para tiendas y membresías),
• OPcache de PHP y caché de navegador con sus caducidades.

Como auditor tu misión no es saber si hay un plugin de caché, la cuestión adecuada es más bien cuántas capas hay, si se solapan y con qué criterio se han configurado.

Después, la base de datos, esa gran olvidada. Con código, esta línea te dice cuántos KB de opciones se cargan en memoria en cada petición (autoload):

wp option list --autoload=on --format=total_bytes

Por debajo de 1 MB vas bien, y a partir de ahí cada MB extra es lastre que se carga en todas y cada una de las visitas. El desglose de culpables te lo da AAA Option Optimizer, que además identifica opciones huérfanas de plugins ya desinstalados.

Completa el repaso con revisiones acumuladas por miles, transients caducados y tablas huérfanas, todo ello con copia de seguridad previa antes de limpiar nada.

Quedan los sospechosos habituales, que son las imágenes sin optimizar (formatos modernos WebP o AVIF, tamaños acordes a lo que se muestra, carga diferida nativa).

También cuentan las fuentes cargadas desde Google en vez de alojadas en local (doble motivo para cambiarlo, el segundo te espera en el bloque RGPD), el Heartbeat de WordPress a su ritmo por defecto en el admin, y JavaScript y CSS sin minimizar ni combinar con criterio.

Crítico

• Métricas web principales suspensas en campo en móvil: afectan hoy mismo a usuarios y posicionamiento.
• Sin ninguna caché de página activa en una web con tráfico: cada visita cocina la página desde cero, con el servidor pagando la fiesta.
• Autoload de opciones desbocado (varios MB): impuesto invisible en cada petición, incluidas las del admin.
• Dos o más plugins de caché u optimización activos a la vez: no suman, se pisan, y los efectos son de los que vuelven loco a cualquiera («a veces va lento, a veces no»).

Importante

• Sin caché de objetos disponible o disponible pero sin activar en webs con WooCommerce o membresías.
• Imágenes a pelo: sin formatos modernos, sin dimensionar y sin comprimir. Suele ser la mejora más visible por esfuerzo invertido.
• Fuentes externas de Google sin alojar en local.
• Base de datos sin mantenimiento: revisiones infinitas, transients caducados, restos de plugins.
• Heartbeat sin controlar en webs con muchos usuarios simultáneos en el admin.

Menor

• Minimizado de JS/CSS sin aplicar: mejora real pero modesta, y siempre después de tener el resto en orden.
• Recursos (assets) que cargan en páginas donde no se usan: afinado fino, planificable.

SEO / AEO técnico

Aquí no se audita el contenido ni las palabras clave, se audita la fontanería, las tripas, que lo que debe indexarse se pueda indexar, que lo que no deba no se indexe, y que ninguna configuración esté saboteando el trabajo de nadie. Es un bloque donde los hallazgos críticos suelen ser pocos pero de los que hacen polvo el negocio del cliente.

Empieza por lo que ya viste en el núcleo (la casilla de visibilidad) y sigue con el plugin SEO, y no es complicado, básicamente que haya uno, que sea uno solo y que esté bien configurado, adaptado al sitio, no instalado y ya.

Aquí cada maestrillo tiene su librillo, y yo en mis webs uso Visibility, plugin de SEO nativo y ligero pensado justo para sustituir suites hinchadas, pero lo que se audita no es la marca del plugin sino que la herramienta esté bien elegida y mejor configurada.

Después el robots.txt (que no bloquee CSS ni JavaScript y que no arrastre un Disallow: / heredado de staging), el mapa del sitio (accesible, declarado en robots.txt, enviado a Search Console y Bing, y sin URLs que no deberían estar).

Las redirecciones (una sola cadena de www/no-www y HTTP a HTTPS, sin saltos encadenados) y el estado de indexación real en Search Console Bing Webmasters, que para eso pediste el acceso al principio.

Del lado del código fuente toca ver si el canonical es correcto, que haya un solo H1 por página y jerarquía de encabezados sin saltos (el detalle fino lo tienes en la guía de auditoría de temas), schema sin duplicar entre tema y plugin SEO, y hreflang si hay idiomas.

Para saber en qué se está gastando Google el rastreo de la web, mi analizador de límites de rastreo te da la foto del crawl budget (el presupuesto de rastreo que Google dedica al sitio) sin instalar nada.

Crítico

• Casilla de disuadir buscadores activa, meta robots noindex global o Disallow: / en robots.txt en una web en producción: la web está pidiendo por escrito que no la encuentren.
• Dos plugins SEO activos o schema y metas duplicados entre tema y plugin: dos fuentes contándole a Google cosas distintas sobre la misma página.
• Acciones manuales o problemas de seguridad notificados en Search Console que nadie ha leído: pasa, y más de lo que parece, porque nadie mira el buzón.
• Redirecciones en cadena o bucles entre versiones www/no-www y HTTP/HTTPS.

Importante

• Mapa del sitio con URLs noindex, archivos adjuntos o taxonomías vacías, que son ruido que gasta rastreo.
• Errores 404 en enlaces internos y sin sistema de redirecciones para URLs que cambiaron.
• Enlaces externos dofollow donde deberían ser nofollow (patrocinados, afiliados sin marcar, iconos sociales, páginas legales).
• Imágenes sin texto alternativo de forma sistemática, lo que supone accesibilidad y SEO de imágenes a la vez.

Menor

• Relación texto/código muy baja en páginas clave es señal de plantillas sobrecargadas, se anota para la fase de mejoras.
• Migas de pan ausentes o sin schema correspondiente.

Visibilidad IA

Cada vez más gente pregunta directamente a ChatGPT, Claude, Perplexity y compañía, y Google responde con IA antes de mostrar el primer resultado clásico.

Eso convierte en revisión de auditoría algo que hace tres años no existía, saber si pueden las IAs descubrir, entender y citar el contenido de esta web Y otra duda igual de legítima, si quiere el propietario que puedan.

Porque este bloque tiene una particularidad que no tiene ningún otro, que el resultado correcto depende de una decisión de negocio del cliente.

Hay quien quiere aparecer en cada respuesta de IA y hay quien no quiere ceder ni una coma para entrenamiento. Decidirlo no te toca a ti, tu trabajo es documentar el estado actual y sus consecuencias, que casi siempre son involuntarias, pues la mayoría de las webs ni bloquean ni facilitan, simplemente nadie ha mirado.

Hay mucho que revisar, como las directivas para bots de IA en robots.txt, con el matiz de que el robots.txt es orientativo, quien de verdad quiera bloquear necesita hacerlo por PHP con respuesta 403), archivos llms.txt y llms-full.txt, Content Signals en robots.txt (definido por Cloudflare para declarar qué usos permites de búsqueda, asistentes y entrenamiento de IA), datos estructurados JSON-LD de identidad, etiquetas Open Graph y Twitter Cards, HTML5 semántico, feed RSS accesible, contenido legible sin ejecutar JavaScript y, en el extremo más avanzado, contenido en Markdown para agentes de IA.

Mucho que revisar ¿verdad? No te preocupes, hay ayudas para todo.

Para el diagnóstico externo tienes el analizador de visibilidad IA puntúa la web sobre 100 en cinco categorías y te dice exactamente qué falta. Sencillo, completo y gratis.

Y para implantar y vigilar desde dentro usa VigIA, esa joya de plugin, también gratuito, que monitoriza más de 55 rastreadores de IA con analítica de cuáles pasan y qué leen, genera los llms.txt, sirve el contenido como Markdown para agentes, añade el JSON-LD de identidad y bloquea por PHP a los bots que decidas, todo en uno y de paso midiendo qué rastreadores ignoran tu robots.txt.

Crítico

• Contenido invisible sin JavaScript en una web que vive de ser encontrada: si el HTML llega vacío, para buena parte de los rastreadores de IA la web no existe.
• Bloqueos involuntarios heredados (reglas anti-bots del hosting o CDN que nadie configuró a propósito) en una web cuyo negocio es la visibilidad.

Importante

• Sin decisión documentada sobre bots de IA: ni directivas, ni señales, ni criterio. El hallazgo que apuntas al informe ahí se llama «nadie ha decidido nada».
• Sin datos estructurados de identidad (WebSite/Organization) ni Open Graph: las IAs pueden leer la web pero no saben de quién es ni cómo citarla.
• Feed RSS desactivado o roto: sigue siendo una de las vías favoritas de descubrimiento de contenido, también para las IAs.

Menor

• Sin llms.txt ni Markdown para agentes en una web que sí quiere visibilidad IA: mejora incremental, fácil de añadir con VigIA.
• Sin Content Signals en robots.txt: el estándar es joven, pero declarar intenciones cuesta un minuto.

Legalidad técnica y funcional

Aviso antes de empezar, para que quede claro, no soy abogado y esto no es asesoramiento jurídico. Lo que sí puedo contarte es qué comprueba un técnico en una auditoría para saber si la web tiene los deberes hechos o está coleccionando papeletas para una sanción, y con eso tu cliente ya puede ir a su asesor con datos en vez de con vaguedades.

La comprobación principal se hace con las DevTools del navegador en una ventana de incógnito. Para ello abre la pestaña de red y la de cookies antes de aceptar nada en el banner y mira qué se carga. Si ya hay cookies de analítica o marketing, o peticiones saliendo hacia Google, Meta y compañía antes del consentimiento, el banner es decorativo, y un banner decorativo es peor que no tenerlo, porque documenta que sabías que tenías que pedir permiso.

El criterio vigente de la AEPD añade otra comprobación de primero de RGPD: rechazar tiene que ser tan fácil como aceptar, mismo nivel, mismo número de clics.

Las fuentes de Google cargadas en remoto son el segundo clásico. Un tribunal alemán ya sentenció que enviar la IP del visitante a Google sin consentimiento por cargar una fuente es sancionable, y de aquella sentencia llovieron reclamaciones por media Europa. Se detectan en la pestaña de red (peticiones a fonts.googleapis.com o fonts.gstatic.com).

El mismo repaso vale para vídeos de YouTube incrustados sin modo de privacidad mejorada, mapas y cualquier recurso de terceros que se cargue antes de consentir.

Completa el bloque lo de siempre que casi nunca está, como formularios y su primera capa informativa y casilla de aceptación sin activar por defecto, textos legales que describan lo que la web hace de verdad (no la plantilla de otra web con el buscar-y-reemplazar a medias, que hay por ahí cada política de privacidad con el nombre de otra empresa dentro que asusta), y si hay productos de Google en juego, Consent Mode v2 funcionando, obligatorio para audiencias del Espacio Económico Europeo.

Hasta aquí las cookies, pero hay otro consentimiento que casi nadie audita y que no tiene nada que ver con el banner. Una cosa es ePrivacy, lo del banner de cookies, y otra el consentimiento al que se refiere el artículo 7.1 del RGPD, el de aceptar tus condiciones o tu privacidad en un formulario, en el registro o en el pago.

La mayoría de webs tienen la casilla marcada pero no guardan ninguna prueba de que se marcó, y el 7.1 no pide la casilla, pide que puedas demostrar el consentimiento: cuándo se dio, desde qué IP, y qué texto y qué versión se aceptaron. Sin ese registro una casilla marcada no vale de nada el día que alguien reclama.

Hay plugins de cookies que incluyen algún registro suelto, pero para dejar esa prueba sellada y a prueba de manipulación tienes Terms & Conditions Consent Log, que guarda fecha, IP, agente de usuario, versión y el texto exacto con un hash SHA-256, y funciona con WooCommerce, Contact Form 7, WPForms, Gravity Forms, Fluent Forms y hasta los comentarios y el registro de WordPress.

Y si la web es una tienda (o sitio corporativo de una física), apunta otra obligación que no estaba hace nada, y que desde el 19 de junio de 2026 está en vigor en toda la UE el desistimiento digital, la Directiva 2023/2673, que exige que el cliente pueda desistir de su compra tan fácil como la hizo, con un botón o formulario claro, respetando los 14 días y con las exclusiones del artículo 16 bien marcadas, que es lo que por ley no admite devolución.

Comprobar que ese mecanismo existe y que funciona es tan parte de la auditoría legal como el banner de cookies, y lo verás de verdad al hacer el pedido de prueba del bloque de tienda. Te lo cuento a fondo en la guía del derecho de desistimiento en WooCommerce.

Para cumplirlo ya hay varios plugins de botón de desistimiento en el repositorio, pero ninguna cumplía del todo así que preparé uno que sí, gratis como siempre, EU Withdrawal Compliance, que añade la función de desistimiento, guarda un recibo con hash SHA-256, incluye el formulario modelo del anexo I.B y te deja marcar las exclusiones del artículo 16 por producto y por categoría, con o sin WooCommerce.

La accesibilidad tampoco es ya cosa de buenos samaritanos, la Ley Europea de Accesibilidad está en vigor desde junio de 2025 y obliga a la mayoría de webs comerciales, así que en una auditoría de 2026 hay que mirarla, aunque sea por encima.

No toca hacer aquí una auditoría WCAG completa, pero sí un primer barrido de lo fundamental, o sea contraste suficiente, textos alternativos en las imágenes, que se pueda navegar con el teclado, formularios con sus etiquetas y que no haya barreras evidentes.

Para ese primer barrido tienes el analizador de accesibilidad web de mis herramientas, que revisa la web según las pautas WCAG y te dice qué falla.

Eso sí, ninguna herramienta automática detecta más que una parte de los problemas de accesibilidad, así que lo que salga limpio ahí todavía necesita una revisión a mano, igual que pasa con cualquier análisis automático frente a una auditoría manual.

Y una última de tienda, fundamental si ofreces rebajas, descuentos, ofertas o como lo llames. Me refiero a la directiva Omnibus, que obliga a mostrar el precio más bajo de los últimos 30 días junto al precio rebajado. El clásico «antes 50 €, ahora 30 €» sin ese dato incumple, y es sancionable.

Crítico

• Cookies y rastreadores cargando antes del consentimiento: el hallazgo RGPD más frecuente y el más fácil de demostrar por cualquiera que reclame.
• Sin textos legales, o textos de otra web con nombres de empresa ajenos aún dentro.
• Formularios que recogen datos personales sin información ni aceptación alguna.

Importante

• Banner sin opción de rechazo al mismo nivel que la aceptación.
• Fuentes de Google y recursos de terceros cargando en remoto sin consentimiento.
• Consent Mode v2 ausente usando Google Analytics o Ads con público europeo.
• Nadie sabe qué encargados del tratamiento hay (hosting, CDN, email marketing) ni dónde se firmaron los contratos de encargo.
• Formularios, registro o pago sin prueba del consentimiento: la casilla marcada, pero sin el registro con fecha, IP, texto y versión que exige el artículo 7.1 para poder demostrarlo.
• Tienda sin mecanismo de desistimiento accesible, o sin las exclusiones del artículo 16 marcadas, con la obligación de la Directiva 2023/2673 ya en vigor.
• Barreras de accesibilidad que incumplen la Ley Europea de Accesibilidad: contraste insuficiente, imágenes sin texto alternativo, navegación imposible con teclado o formularios sin etiquetas.

Menor

• Política de cookies desactualizada respecto a las cookies que la web pone en realidad: toca inventario y puesta al día.
• Solicitudes de permisos del navegador (geolocalización, notificaciones) disparadas nada más cargar la página: además de molestas, difíciles de justificar.
• Rebajas sin mostrar el precio más bajo de los últimos 30 días que exige la directiva Omnibus.

Tienda online

Si no hay tienda salta este bloque, y si la hay redobla la atención, porque aquí ya no auditas una web, auditas una caja registradora, y cada fallo tiene un coste que se mide en pedidos perdidos, no en puntuaciones de herramienta.

La primera revisión es el estado de WooCommerce Estado (WooCommerce → Estado), que por sí solo te dice la versión y base de datos de WooCommerce, plantillas sobreescritas obsoletas (lo vimos a fondo en la guía de temas) y el estado de HPOS, el almacenamiento de pedidos en tablas propias que ya es el modo por defecto en instalaciones nuevas.

Si la tienda sigue en modo antiguo, o peor, en modo compatibilidad con sincronización eterna, hay que averiguar qué plugin lo está impidiendo y valorar la migración con calma y en staging.

La segunda revisión obligatoria es hacer una compra, de verdad, del principio al final, probando el modo sandbox de la pasarela o producto de prueba de un céntimo, pero completa.

Esta es la única forma de saber si el checkout funciona, si hay errores de JavaScript en consola a mitad de proceso, si los impuestos cuadran y, atención a esta, si los correos del pedido llegan al cliente y a la tienda, que enlaza con el SPF y el SMTP que auditaste en el bloque de servidor.

Y ya que estás dentro del proceso, comprueba también si hay mecanismo de desistimiento como vimos antes en el bloque de legalidad, porque es aquí, con la compra hecha, donde se ve de verdad si el cliente puede ejercer su derecho con la misma facilidad con la que ha pagado.

Aprovecha para revisar las pasarelas de pago, con las claves de producción donde haga falta y que no haya ningún modo de pruebas olvidado desde el lanzamiento, que haberlos haylos.

Y la tercera es el programador de acciones (la cola de tareas internas de WooCommerce), que se revisa en WooCommerce → Estado → Acciones programadas. Te puedes encontrar con decenas de miles de acciones fallidas o pendientes acumuladas, que pueden ser síntoma de algo roto por debajo, pero siempre son lastre para la base de datos. Si se desmadra (que lo hará) ten siempre a mano el plugin para limpiar las acciones programadas innecesarias.

Crítico

• Pasarela en modo de pruebas en producción, o claves de test y producción mezcladas: pedidos que parecen cobrados y no lo están.
• Correos transaccionales que no llegan: pedidos a ciegas para el cliente y para la tienda.
• Pago con errores de JavaScript o pasos rotos en móvil: dinero saliéndose por el desagüe cada día que pasa.
• Plugins clave de la tienda incompatibles con HPOS consultando pedidos a la antigua: roturas silenciosas ya o en la próxima actualización.

Importante

• Plantillas de WooCommerce sobreescritas varias versiones por detrás.
• Programador de acciones con miles de tareas fallidas o pendientes sin explicación.
• Impuestos mal configurados o precios sin coherencia entre ficha, carrito y checkout.
• Webhooks de integraciones (ERP, email marketing, envíos) fallando en silencio.

Menor

• Checkout con campos innecesarios y distracciones: mejora de conversión a proponer, no urgencia técnica.
• Pedidos de prueba y datos de desarrollo aún en la base de datos de producción.

Para terminar, repasa la sección anterior sobre legalidad, porque en tiendas la cosa está cargadita, y las sanciones son tremendas.

Multisitio: auditar una red no es auditar una web

Si el sitio es una instalación normal sáltate este bloque. Y si es una red multisitio, prepárate, porque una red no es un área más que auditar, es un modo que cambia cómo auditas todo lo anterior.

Aquí varios sitios comparten una sola instalación de WordPress, la misma base de datos, los mismos archivos de plugins y temas y, muchas veces los mismos usuarios, así que un fallo en un rincón puede llevarse la red entera por delante.

Lo primero es tener claro qué está compartido, porque ahí viven casi todos los riesgos.

El código es común, o sea que una vulnerabilidad en un plugin o un tema no afecta a un sitio, afecta a todos a la vez. Los usuarios también son comunes, porque la tabla wp_users es única para toda la red, y una inyección SQL en el sitio más tonto puede exponer los usuarios y las contraseñas de todos, superadministradores incluidos.

Las subidas van a una carpeta compartida, /wp-content/uploads/sites/ID/, donde un archivo malicioso colado en un sitio vive pared con pared con el resto. El caso de manual que se repite es justo ese, un PHP colado en uploads, la tabla de usuarios volcada, una contraseña débil de superadmin reventada y puerta trasera en toda la red en una tarde.

Por encima de todo está el superadministrador, que en una red es el modo dios, pues crea y borra sitios, instala plugins y temas para todos y gestiona a cualquier usuario.

Así que la primera pregunta de la auditoría es cuántos superadmins hay (lo razonable son tres o menos), si alguno es en realidad un cliente que no debería serlo, si todos tienen 2FA y si sigue en el proyecto la gente que aparece en esa lista.

Sin tocar código, casi todo esto lo tienes en el escritorio de red, en Mis sitios → Administrar red. Ahí está la lista de sitios con su estado, los usuarios de toda la red, los plugins y temas disponibles y la pantalla de actualizaciones.

Con eso auditas la red sin abrir una consola. Con WP-CLI, wp site list te saca todos los sitios con su ID y su URL, wp user list --network los usuarios, y para actuar sobre un sitio concreto le añades --url= a cualquier comando. Tras actualizar el núcleo, no olvides wp core update-db --network, que pone al día la base de datos de todos los sitios de golpe.

Dos cosas más que la red cambia respecto a un sitio suelto. Una es que una actualización toca todos los sitios a la vez, así que el staging deja de ser recomendable y pasa a ser obligatorio, porque una incompatibilidad no rompe un sitio, rompe la red.

La otra es que los recursos del servidor son compartidos, de modo que un pico de tráfico o un plugin desbocado en un solo sitio degrada a todos los demás, que es justo lo del bloque de picos de tráfico pero multiplicado.

En lo relativo a la seguridad en redes multisitio la regla de oro es activar en red solo lo imprescindible, porque cada plugin activado en red se ejecuta en todos los sitios en cada carga, y lo demás actívalo sitio a sitio.

Lo que pongas de seguridad, o sea cortafuegos, bloqueo de ejecución de PHP en uploads, escaneo de integridad y registro de actividad, compruébalo antes en un plugin que sea compatible con multisitio, que muchos no lo son.

Vigilante, por ejemplo, funciona en red, aunque con ajustes independientes por sitio y sin un panel único que lo gobierne todo de golpe, así que aseguras cada sitio pero lo configuras uno a uno. Hay modos de hacerlo desde un panel único pero mi consejo es que mientras sea manejable gestiones la seguridad sitio a sitio.

Crítico

• Superadmins de más, alguno que es un cliente, o cuentas de superadmin activas de gente que ya no está: en una red, cada una es la llave maestra de todo.
• Ejecución de PHP habilitada en la carpeta de subidas compartida: la vía más habitual para plantar una puerta trasera que afecta a toda la red desde un solo sitio.
• Un plugin o un tema con vulnerabilidad conocida activo en la red: no es un sitio en riesgo, son todos a la vez.

Importante

• Plugins activados en red que solo usa un sitio: peso y superficie de ataque en todos los demás sin ningún motivo.
• Prefijo de tablas wp_ por defecto y un único usuario de base de datos con permisos de sobra: facilita el salto de un sitio comprometido al resto.
• Sin registro de actividad en los sitios de la red: aunque casi ningún plugin ofrezca todavía un panel único para toda la red, cada sitio debería al menos registrar su actividad para saber qué pasó y quién lo hizo.
• Actualizaciones de red aplicadas sin staging previo.

Menor

• Sitios de la red archivados, marcados como spam o de prueba que nadie ha limpiado: ruido que conviene revisar y retirar.
• Copias de seguridad por sitio en lugar de una copia de toda la red: en multisitio se respalda la instalación completa, no las tablas de un sitio suelto.

El informe

Una auditoría que termina en una lista de 200 problemas (o más) sin orden ni contexto no sirve para nada, o peor, sirve para asustar al cliente y que no contrate ninguna solución.

El valor de una auditoría web no está en encontrar fallos sino en convertirlos en un plan que alguien pueda aprobar, y para eso el informe necesita tres cosas: prioridades, evidencias y separación clara entre lo urgente y lo deseable.

Las prioridades ya las traes hechas, porque los tres niveles de cada bloque trasladan directos al plan de trabajo:

• Lo crítico se corrige antes de cualquier otra cosa (y si asumes el mantenimiento, antes de considerar la web «bajo tu responsabilidad»)
• Lo importante se planifica en la próxima actuación o antes de la siguiente versión mayor de WordPress o PHP
• Lo menor se documenta para resolverlo cuando se pase por ese código o esa configuración por otra razón.

Deja evidencia de todo, con capturas de cada hallazgo (en lo posible), su dato o su URL. No por desconfianza, sino porque dentro de seis meses nadie recordará por qué se decidió algo, y el informe es la memoria del proyecto.

Este esquema, por cierto, no me lo he inventado para el artículo, es el mismo que uso en los informes iniciales cuando asumo el mantenimiento de una web, con la situación previa área por área y las soluciones en dos listas separadas, las inmediatas que se aplican de oficio (copia de seguridad, monitorización, actualizaciones seguras) y las propuestas que requieren aprobación o presupuesto.

Y una recomendación de cierre para el documento es que escribas la parte de conclusiones en el idioma del cliente, no en el tuyo. «El autoload de wp_options pesa 9 MB» no significa nada para quien firma las facturas, pero «tu web carga en cada visita varios megas de imágenes, y tus clientes pueden abandonar la web si tarda más de 3 segundos» sí.

Herramientas gratuitas

Las herramientas de diagnóstico que han ido apareciendo por el artículo, y más, las tienes en herramientas.ayudawp.com: el análisis de seguridad externo, el analizador de visibilidad IA, el de límites de rastreo, el analizador de accesibilidad web y la auditoría de temas para documentar hallazgos e imprimir el informe.

Allí tienes también unos cuantos generadores que te vendrán genial cuando toque corregir lo encontrado, como el de cabeceras de seguridad, el de wp-config.php, el de .htaccess, el de robots.txt o el de security.txt, además del optimizador de imágenes, pero eso ya es otra fase y otro artículo. Son gratuitas, en español, sin registro y funcionando en tu navegador.

Además, luego tienes plugins que considero imprescindibles, y te resumo:

• Seguridad: Vigilante o All in one security
• SEO: Visibility o The SEO Framework
• Visibilidad IA: VigIA, AI Share & Summarize, AI Content Signals, Visibility
• Rendimiento y velocidad de carga: DietPress, Query Monitor, WP Crontrol
• Tienda online: Easy Action Scheduler Cleaner
• RGPD / Legal: EU Withdrawal Compliance, Terms & Conditions Consent Log, un buen plugin de gestión de cookies

Prompts de IA útiles en auditorías

La IA no sustituye las comprobaciones en tiempo real ni las herramientas especializadas, pero traduce y prioriza a una velocidad que compensa usarla en cada auditoría.

Para traducir la salud del sitio (pega el texto del informe que genera WordPress en «Herramientas → Salud del sitio → Información», botón de copiar al portapapeles):

Este es el informe de Salud del sitio de un WordPress. Explícame en términos simples qué problemas hay, cuáles son graves y en qué orden los resolverías. No asumas que sé de servidores.

Para las cabeceras de seguridad (pega la respuesta de curl -I https://laweb.com o las cabeceras que muestra cualquier herramienta externa):

Estas son las cabeceras HTTP de una web WordPress. Dime qué cabeceras de seguridad faltan, cuáles están mal configuradas y qué riesgo real supone cada ausencia. Ordena por importancia.

Para el borrador del informe al cliente (pega tu lista de hallazgos técnicos):

Estos son los hallazgos técnicos de una auditoría WordPress clasificados en Crítico, Importante y Menor. Redacta un resumen ejecutivo de una página para un cliente sin conocimientos técnicos: qué pasa, qué riesgo tiene y qué propongo hacer, sin tecnicismos y sin dramatismo.

Para profundizar aún más pasa Claude Code sobre la carpeta wp-content con una instrucción inicial que le pida clasificar hallazgos por gravedad te da un primer mapa priorizado del código en minutos. Con la misma limitación de siempre, que conviene no olvidar, y es que la IA analiza código estático, no ejecución, así que Query Monitor, los logs y las compras de prueba siguen siendo insustituibles.

¿Cada cuánto repetir todo esto?

La auditoría es una foto, y las webs se mueven. La cadencia que a mí me funciona con las webs que mantengo:

• Completa: al asumir una web nueva, siempre, y después una vez al año, porque lo que era Menor el año pasado puede haberse convertido en Crítico si el ecosistema avanzó y la web no.
• Seguridad: revisión mensual apoyada en alertas automáticas de vulnerabilidades para los plugins instalados, con Vigilante avisando de cambios en archivos entre revisión y revisión.
• Rendimiento: tras cualquier cambio grande (tema nuevo, migración, campaña con tráfico fuerte) y un vistazo trimestral a los datos de campo.
• Con cada versión mayor de WordPress o PHP: repaso de compatibilidad en staging antes de actualizar producción.

Y si todo esto te parece sensato pero no tienes cuándo hacerlo, te viene grande o prefieres derivar responsabilidades, para eso existe mi servicio de mantenimiento web, donde la auditoría inicial, las revisiones y el informe mensual van de serie, es literalmente lo que hacemos cada día.

Si haces tu primera auditoría con esta guía me encantará saber cómo te ha ido, qué te has encontrado y qué echas en falta, y si auditas webs a menudo seguro que tienes revisiones propias que aquí no están, para todo eso, incluso para debatir, me tienes ahí abajo, en la sección de comentarios.

La próxima web que te llegue sin documentación ya no te va a pillar a ciegas, pero sobre todo tendrás una lista de por dónde empezar, por lo menos.

¿Te gustó este artículo? ¡Ni te imaginas lo que te estás perdiendo en YouTube!