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.

Vamos a verlo, porque tiene más miga de la que parece.

Para empezar ¿qué es eso del unfiltered_html y qué hace?

WordPress filtra el HTML que guardas en las entradas con una función llamada wp_kses, que viene a ser el segurata que decide qué tags pasan y cuáles no, y por eso un suscriptor o un colaborador no puede colarte un <script> ni un <iframe> raro. Hasta ahí bien.

El problema es quién se puede saltar esa medida de seguridad. En una instalación normal, de un solo sitio, los administradores y los editores tienen la capacidad unfiltered_html, que les deja escribir el HTML que les dé la gana, sin filtrar ninguno. Lo que teclean va directo a la base de datos tal cual, scripts incluidos.

Si tienes una red multisitio con WordPress la cosa cambia, porque ahí solo los superadministradores la tienen, ni siquiera los administradores de cada subsitio. Así que este truco va sobre todo para las webs de un solo sitio, que son la mayoría.

¿Que esto es teórico? Ni de lejos. Ya conté en su día una vulnerabilidad en Divi, Extra y Divi Builder por la que usuarios de perfil bajo, como un simple autor, podían usar HTML sin filtrar en el contenido cuando editaban con el maquetador, justo lo que se supone que solo pueden hacer los administradores, lo que sería un escalado de privilegios de manual.

Por qué es un problema de seguridad, y no de confianza

El riesgo no es que tu editor sea mala gente, es que alguien se haga con su cuenta. Una contraseña reutilizada que aparece en una filtración, un phishing bien montado o un plugin comprometido que escala permisos, y de repente alguien tiene entre manos una cuenta con unfiltered_html.

Con esa cuenta no necesita romper nada, le basta con editar una entrada, pegar un <script> que robe cookies de sesión o redirija a los visitantes, guardar y a correr. Es XSS almacenado, del que se queda en tu base de datos y se ejecuta en el navegador de cada persona que abre esa página, tú incluido cuando entras al escritorio.

Mira qué fácil es impedir el unfiltered_html

La parte buena de todo esto es que el problema, que lo puede ser, se arregla simplemente definiendo una constante en el wp-config.php. Ábrelo por FTP o desde el gestor de archivos de tu hosting y añade esta línea antes de la que dice /* That's all, stop editing! Happy publishing. */:

define( 'DISALLOW_UNFILTERED_HTML', true );

Y ya está. A partir de ahí WordPress le quita la capacidad a todo el mundo, administradores y superadministradores incluidos, y todo lo que se guarde pasa por el filtro wp_kses como si lo escribiera un colaborador cualquiera. Ya no puedes meter una etiqueta <script>.

Para comprobar que funciona entra como administrador, mete un bloque de HTML personalizado con un <script>alert(1)</script> dentro, guarda y recarga. Si la constante está bien puesta, el script habrá desaparecido solo.

¿Se rompe algo si quito el unfiltered_html?

Esto no es gratis del todo,porque al capar el HTML sin filtrar WordPress también va a vaciar cosas seguramente normales que metas a mano como código, como un <iframe> de un mapa pegado en un bloque de HTML personalizado, un incrustado manual, un script de seguimiento que colabas en una entrada concreta, o ciertos atributos que wp_kses no admite por defecto.

Y luego hay otro efecto colateral, y es que desaparece también la opción de CSS adicional del personalizador. WordPress usa la capacidad edit_css para ese cuadro donde escribes CSS, y esa capacidad está enganchada por dentro a unfiltered_html, así que al desactivar una te llevas la otra por delante.

Lo mismo pasa con el CSS personalizado del editor de sitio en los temas de bloques. Si metes tus estilos por ahí tenlo claro antes de activar la constante.

Entonces, ¿cuándo la activo?

• Sí, sin pensarlo, si tienes varios redactores, editores o autores, o si mantienes webs de clientes donde no controlas quién toca qué. El riesgo de una cuenta comprometida pesa mucho más que la comodidad de pegar un iframe de vez en cuando.
• Con cuidado, o mejor no, si eres el único que edita, metes HTML crudo por el editor a menudo o dependes del CSS adicional del personalizador. En ese caso tienes salidas más finas.

Sí, hay otras maneras de protegerte sin hacerlo a la brava, para este segundo caso. Una es que en vez de capárselo a todos con la constante, quites la capacidad solo a los perfiles que no la necesitan, como editores y autores, con un filtro sobre map_meta_cap, y dejársela a los administradores. Solo tendrías que añadir un código como este:

/* Filtrar el HTML sin filtrar solo a los que no son administradores */
add_filter( 'map_meta_cap', 'ayudawp_limitar_unfiltered_html', 10, 3 );
 
function ayudawp_limitar_unfiltered_html( $caps, $cap, $user_id ) {
 
	// Solo actuamos sobre la capacidad de HTML sin filtrar
	if ( 'unfiltered_html' === $cap ) {
 
		// Leemos los datos del usuario directamente para no provocar
		// una llamada recursiva a este mismo filtro, como pasaría con user_can()
		$user = get_userdata( $user_id );
 
		// Si no es administrador (no tiene manage_options), se la denegamos
		if ( ! $user || empty( $user->allcaps['manage_options'] ) ) {
			$caps = array( 'do_not_allow' );
		}
	}
 
	return $caps;
}

Con esto los administradores siguen metiendo el HTML que quieran y a los editores se les filtra igual que a un colaborador, sin tocar el wp-config.php ni llevarte por delante el CSS adicional del personalizador. Y si lo que buscas es que tus redactores no puedan ni acercarse al HTML a mano, tienes el otro camino, desactivar el editor de código del editor de bloques. Depende de cómo trabajéis.

No te relajes que eso no es todo, aun te pueden colar código

La constante cierra la puerta del editor, que es la más grande, pero no es la única. Un plugin con una vulnerabilidad de XSS, un comentario mal filtrado o un formulario pueden colar un script por otro lado, y ahí esta línea no llega.

Para eso está la cabecera Content-Security-Policy (CSP), que es la que de verdad frena que un script se ejecute aunque haya conseguido meterse en tu base de datos.

Si tu política solo permite ejecutar JavaScript de tu propio dominio, el <script> del atacante que apunta fuera se queda mirando. Es la defensa con más rentabilidad contra el XSS, como ya expliqué en la guía de protección contra XSS.

Cabeceras CSP las gestionan muchos plugins de seguridad, pero el más completo en este sentido es Vigilante, que incluye incluso un comprobador de cabeceras. La idea es tener las dos capas trabajando juntas, la constante para que el script no entre por el editor y la CSP para que no se ejecute si entra por otro sitio.

¿En qué quedamos, impido el unfiltered_html o no?

Si en tu web publica más gente que tú, o llevas webs de clientes, la respuesta corta es sí. añade la línea al wp-config.php y te quitas de encima uno de los vectores de XSS más tontos y más habituales que hay. Pero administras y alimentas la web solo tú y usas el CSS adicional del personalizador o pegas iframes a mano, valora antes la alternativa de capárselo solo a ciertos perfiles.

Tienes más contexto en la lista completa de constantes de WordPress por si quieres seguir apretando tuercas en el wp-config.php, y en la guía de XSS para montar la parte de la CSP como es debido.

¿Tú la tenías capada o acabas de descubrir que tus editores podían hacer esto? Me lo cuentas ahí abajo, en los comentarios … o no.

El lunes tocaron unas Crónicas WordPress cargadas hasta arriba de noticias, con la IA comiéndose el tráfico de Google como tema estrella. Y el miércoles vino un Doctor WordPress dedicado a algo que me preguntáis un montón, cómo hacer que te vean los buscadores y las IAs sin pagar un duro, tirando de lo que ya trae WordPress de serie. Te cuento.

Crónicas WordPress: la semana en que la IA se comió el tráfico (y Elementor le echó la culpa)

Abrí pidiendo disculpas, todo hay que decirlo, porque el miércoles anterior me salté el Doctor WordPress. ¿La razón? Pues el verano, que me fui a dar un baño y cuando quise darme cuenta eran las ocho y media y se me había pasado la hora. Cosas que pasan. Aclarado esto, vamos a la ronda de titulares, que hubo tela.

Seguridad

En el frente de siempre, semana movidita:

• Wordfence cerró la semana con casi 200 vulnerabilidades nuevas, para que te hagas una idea del ritmo al que va esto.
• El fallo crítico de UpdraftPlus (CVE-2026-10795) se sigue explotando en 3 millones de webs, y menos mal que los hostings buenos ya están parcheando y avisando.
• Y una que me encantó, la de un desarrollador que tumbó un ataque de spam de registro con un filtro hecho con ayuda de Claude y Codex. El spam de registro es de lo más pesado que hay, así que ver a alguien resolverlo con IA y buen criterio me alegró el lunes.

Comunidad

La bomba de la semana fue Elementor, que ha echado al 30 % de su plantilla y le echa la culpa a la IA. A ver, la IA será lo que quieras, pero la decisión de despedir la toman ellos, no ChatGPT. Echarle la culpa a la máquina queda muy moderno, pero es su decisión y su responsabilidad.

Más cosas de comunidad que comenté:

• Marina Broca, que sabe un rato de la parte legal y es buena amiga, publicó en el blog de WordPress.com un artículo estupendo sobre el botón de desistimiento para tiendas, esa directiva europea que ya está en vigor. Y mira tú por dónde, ahí recomiendan mi plugin gratuito para cumplir con ello, cosa que me hizo ilusión.
• Salió el informe «State of WordPress Agencies 2026», sobre cómo trabajan de verdad las agencias, muy enfocado al mercado anglosajón pero con lecturas interesantes.
• Y el informe sobre el estado de los temas, que deja una brecha curiosa, los desarrolladores se han pasado a los bloques y los usuarios ni de lejos.
• WPBakery sacó su versión 9.0 en beta, por si todavía tiras de él.
• Y hablé de Dismissed, ese muro de la vergüenza de los avisos que los plugins te clavan en el escritorio.

IA, SEO y el tema gordo del tráfico

Aquí es donde la cosa se pone interesante de verdad. Un estudio ha desmontado el discurso de Google sobre las AI Overviews, hablamos de un 39,8 % menos de clics, y encima los que se pierden no eran de peor calidad, como quería vender Google. Te lo resumo en que esas respuestas de IA ya saltan en más del 40 % de las búsquedas, y eso se traduce en una pérdida de tráfico brutal, no solo informacional, también transaccional, gente que compraría y que ya no llega nunca a tu web.

¿Quieres una pista de lo gordo que es esto? Fíjate en la de anuncios de empresas financieras online que ves últimamente. Están compensando con publicidad la caída enorme de tráfico orgánico. Para que luego digan que la IA no le cambia el negocio a nadie.

Otras de IA y buscadores que toqué:

• El modo Thinking de ChatGPT cita marcas distintas según cómo lo uses, lo que me sirve para repetir una de mis manías, no pagues por nada que mida tus menciones en las IAs, porque son de lo más aleatorio, hasta el mismo modelo te recomienda cosas distintas de una vez a otra.
• Cloudflare ya te deja bloquear a los bots de IA, aunque ojo con no cerrarle la puerta de paso a Googlebot.
• Lo enlacé con la pregunta del millón, ¿bloqueo los crawlers de IA o mido primero su valor? Que tiene más miga de la que parece, y de ahí sale medio Doctor de esta semana.
• Y hablé de los nuevos estándares ARD y OKF, y de si de verdad tienes que implementarlos ya en tu WordPress (con calma, que no cunda el pánico).

Tienes todos los titulares con sus enlaces en la descripción del vídeo, que los dejo siempre ordenaditos.

Aquí tienes las Crónicas WordPress completas: Nuevos estándares IA: ARD, OKF, valor de las menciones de IA y bajada tremenda de tráfico desde Google.

Doctor WordPress: SEO, AEO, GEO y cómo ser visible en las IAs gratis con WordPress

Este fue el último Doctor antes del verano, y lo dediqué a lo que os había prometido, cómo posicionar hoy, cuando ya no vale solo con salir en Google. Ahora hay que aparecer también en las IAs, que más que buscadores son respondedores, te sueltan la respuesta y listo. De ahí lo del SEO de siempre más el AEO y el GEO, las siglas de moda para una misma idea, que te encuentren y te citen.

La buena noticia, y el motivo del directo, es que puedes hacer muchísimo gratis con lo que WordPress ya trae de serie, sin pagar por un plugin de SEO monstruoso:

• WordPress genera su propio mapa del sitio en wp-sitemap.xml. Los plugins de SEO no inventan nada nuevo, solo le cambian la ruta, cada uno la suya.
• La etiqueta de título sale del propio título del documento, que controlas desde los ajustes generales y desde cada contenido.
• Y las metaetiquetas y los datos estructurados también los puedes gestionar sin cargarte la web de código que no necesitas.

Para enseñarlo tiré de un plugin mío, Visibility (más info en visibility.quest), que forma parte de esa familia de plugins gratuitos que voy soltando, como el Vigilante. ¿Que por qué me meto en el jardín de hacer un plugin de SEO? Pues justo por esto, porque está montado sobre las funciones que ya existen en WordPress (el manejo de robots, los sitemaps, los metadatos, los canonical nativos) en lugar de duplicarlas como hacen otros. Menos grasa y más músculo.

Y una perla práctica que engancha con lo de Cloudflare de las Crónicas: no bloquees a lo loco a todos los bots de IA. A los de entrenamiento sí les puedes cerrar la puerta, que consumen recursos a lo bestia y no te devuelven nada. Pero a los de asistente y búsqueda ni se te ocurra, porque son justo los que te citan y te enlazan en tiempo real, y esos sí te traen visitas. Saber distinguir unos de otros es media batalla.

El resto del directo fue lo de siempre en el Doctor, vuestras preguntas de WordPress, SEO, IA y de casi cualquier cosa, que para eso está la consulta abierta.

Aquí tienes el Doctor WordPress completo: SEO, AEO, GEO y Visibilidad en IAs gratis en WordPress.

Nos vemos después del verano

Con estos dos directos me despido (de vídeos) hasta la vuelta, que toca desconectar unas semanas. Si te quedan ganas de WordPress para el verano, tienes las dos sesiones enteras ahí arriba para verlas con calma, y de paso puedes cacharrear con lo de la visibilidad gratis, que es buen plan para una tarde de estas sin prisa.

Y si te surge cualquier duda o te apetece debatir algo de lo que conté, me tienes en los comentarios. Buen verano, y a la vuelta más.

La respuesta corta es que no pintan gran cosa, pero no anticipemos tanto, que si no quieres seguir leyendo ya tenías los resúmenes con IA, aquí hemos venido a aprender ¿o no?

Qué son y por qué casi siempre sobran

WordPress crea de forma automática un archivo por cada año y cada mes en los que has publicado, un listado que agrupa las entradas por su fecha.

El problema es que la fecha no es un criterio por el que busque nadie, la gente busca por temas, no por «lo que publicaste en noviembre de 2025».

Así que esas páginas no le sirven de nada al visitante y, de paso, se llevan parte del rastreo que Google podría dedicar a tu contenido bueno.

A diferencia del archivo de autor, que tiene su miga porque ancla tu autoridad y ahí la decisión no es tan obvia, los archivos de fechas no aportan ninguna señal que te interese conservar. Fácil ¿verdad?

Qué hacer con los archivos por fecha de cara a SEO

Tienes dos opciones razonables, y las dos sirven:

• Desindexarlos con noindex, follow: La página desaparece de Google, pero este sigue los enlaces hacia tus entradas. Es lo mínimo y lo más seguro.
• Desactivarlos del todo: Que la URL de fecha ni exista. La mayoría de plugins permiten desactivarlos con un clic.

Y lo que no debes hacer, igual que con cualquier archivo, es ni bloquearlos por robots.txt (Google no leería el noindex y podría acabar indexando la URL igual) ni poner su URL canonical apuntando a la portada.

Pero eso ya lo sabías, porque eres un fiel lector y estás suscrito a la newsletter de Ayuda WordPress para no perderte nada ¿a que sí?

Cómo deshacer SEO con los archivos de fecha

Como siempre, para todos los gustos, con códigos y con plugins.

Por código

Si no quieres instalar nada, un mu-plugin en la carpeta /wp-content/mu-plugins/ con este contenido deja los archivos por fecha en noindex, follow:

<?php
/**
 * Plugin Name: Noindex para archivos por fechas
 * Description: Añade noindex, follow a los archivos de fechas.
 * Author: Fernando Tellado
 */

add_filter( 'wp_robots', 'ayudawp_noindex_date_archives' );

function ayudawp_noindex_date_archives( $robots ) {
	if ( is_date() ) {
		$robots['noindex'] = true;
		$robots['follow']  = true;
	}
	return $robots;
}

Funciona desde WordPress 5.7, que es cuando llegó el filtro wp_robots, que es el que usa el código.

Por ajustes y plugins

• Yoast SEO los desactiva del todo desde SEO > Apariencia en el buscador > Archivos.
• Rank Math y All in One SEO te dejan desindexarlos desde sus ajustes de apariencia en el buscador.
• Visibility te permite añadir el noindex, follow nativo, lo que hemos visto antes, con una casilla, a un clic, sin tablas en la base de datos ni código.

Lo que yo haría

Con los archivos por fecha no hay mucho que debatir, desindéxalos con noindex follow o desactívalos, da igual el tamaño de tu web.

Donde sí tienes que pararte a pensar es en el archivo de autor, que ahí entra en juego tu E-E-A-T y la cosa cambia.

¿Dudas? Te leo en los comentarios.

En mi artículo sobre precarga de recursos, prefetch y prerender significan una cosa, luego, en cuando escribí sobre carga especulativa nativa de WordPress, las mismas dos palabras significan otra completamente distinta y, para seguir enredando, luego está eso de la bfcache, que no precarga nada de nada, va al revés.

Son cuatro técnicas con nombres que se pisan, y cada una vive en su propia capa del navegador, con sus propias reglas, así que se me ha ocurrido que igual no está de más ponerlas en orden para que dejemos de mezclarlas.

Si lo que buscas es la otra caché, la que guarda resultados ya generados para no repetir trabajo (página, objetos, base de datos, OPcache, CDN), esa la tienes entera en la guía de tipos de caché en WordPress.  Hoy toca hablar de la familia de cachés que adelanta o conserva trabajo del navegador, no del servidor, que es un asunto distinto aunque también se llame caché en algún sitio.

Resource hints: precarga recurso a recurso

Esta es la que lleva más tiempo en el navegador y la que seguramente ya conoces, aunque no la llames así. Son cuatro etiquetas <link> distintas, cada una con un trabajo muy concreto sobre un recurso suelto, nunca sobre una página entera.

• dns-prefetch: resuelve el nombre de dominio de un origen externo antes de que haga falta, así cuando llegue el recurso de verdad esa parte ya está hecha.
• preconnect: hace lo mismo que dns-prefetch y además abre la conexión TCP y negocia el TLS, así que cuando el recurso llega de verdad el navegador no tiene que esperar nada de eso.
• prefetch: descarga un recurso suelto entero, un documento o un recurso cualquiera, con prioridad baja, para tenerlo ya en caché cuando se necesite.
• preload: igual que prefetch pero con prioridad alta y de obligado cumplimiento, el navegador no puede ignorarlo. Se usa para lo que sabes seguro que vas a necesitar ya, como la fuente del título o la imagen del LCP.

Los cuatro se controlan recurso a recurso, dominio a dominio, decisión que tomas tú o que automatizas con plugins como DietPress, a golpe de clic, sin que escribas una sola línea de código.

WordPress trae de serie el filtro wp_resource_hints desde la versión 4.6 para añadir dns-prefetch y preconnect sin tocar el <head> a mano, aunque mucha gente, este blog incluido en su día, sigue escribiendo el echo directo en wp_head en vez de usarlo.

Si quieres un tutorial con el código y las herramientas para aplicarlo en la guía de prefetch, preload, preconnect y prerender en WordPress.

Un apunte para no liar (aún más) el tema es lo relativo al atributo fetchpriority, que suena de la misma familia, y a veces se mete en el mismo saco, pero hace algo distinto. No anticipa nada que el navegador no fuese a pedir igualmente, solo le dice con qué prioridad pedirlo, no es un resource hint en sentido estricto, es una instrucción de orden. Si quieres ampliar información puedes ver la guía de fetchpriority.

El prerender de siempre ya no hace nada

De las etiquetas de arriba hay una que solía acompañarlas, <link rel="prerender">, y que merece su propio apartado porque hoy no sirve absolutamente para nada. Chrome la abandonó hace años, sustituida por la tecnología de la siguiente sección, y cualquier navegador actual la ignora sin más.

No pasa nada por tenerlo, simplemente no aporta nada.

Speculation Rules: prefetch y prerender nativos de WordPress

Desde WordPress 6.8, trae de serie la carga especulativa, creada sobre la Speculation Rules API del navegador. Y aquí empieza el lío, porque esta tecnología también tiene su propio prefetch y su propio prerender, con los mismos nombres que los de la primera sección, pero que no funcionan igual ni a la misma escala.

Un resource hint clásico es como pedir que te dejen ya el cubierto puesto en la mesa. Speculation Rules es como si la cocina empezara a prepararte el plato entero en cuanto te ve mirar el menú, antes de que hayas pedido nada, o sea, precarga la página completa, con su HTML, su CSS y su JavaScript, no un recurso suelto.

Se declara en JSON dentro de un <script type="speculationrules">, es automático, y WordPress lo activa de serie solo para visitantes que no están conectados y solo si usas enlaces permanentes bonitos. Hay tres niveles de anticipación, la conservadora espera al clic, la moderada se dispara al pasar el cursor y la ansiosa salta con solo acercarte.

La compatibilidad con navegadores es la otra pieza importante para decidir si te conviene. Funciona en Chrome, Edge y el resto de navegadores con motor Chromium, que es la inmensa mayoría del tráfico mundial, Safari la incluye desde la versión 26.2 pero la trae desactivada por defecto, como función experimental, y Firefox de momento no la ha implementado, aunque sí se ha posicionado a favor de la parte de prefetch para más adelante.

Puedes excluir URLs concretas con el filtro plsr_speculation_rules_href_exclude_paths, o apagarla entera con wp_speculation_rules_configuration. Tienes el desarrollo completo, con el código y los pros y contras, en qué es y cómo funciona la carga especulativa nativa y en si te conviene desactivarla.

bfcache: la única caché que no anticipa nada, conserva lo que ya tenías

Las tres técnicas anteriores miran hacia delante, adivinan qué vas a necesitar y se adelantan. Sin embargo bfcache (back/forward cache) hace justo lo contrario y mira hacia atrás. Cuando sales de una página el navegador la congela en memoria tal cual estaba, y si pulsas atrás te la devuelve al instante en lugar de pedirla otra vez al servidor.

Es una optimización nativa de los navegadores desde hace años, no necesita ningún código tuyo para existir, pero WordPress la bloquea por su cuenta para usuarios conectados al enviar la directiva no-store en la cabecera de respuesta. Quitar esa directiva con el filtro wp_headers, o con el plugin Instant Back/Forward, es lo que la reactiva.

No tiene relación de competencia con ninguna de las tres anteriores, todo lo contrario, se complementan, porque bfcache acelera las páginas que ya visitaste, Speculation Rules acelera las que aún no has visto.

Las cuatro juntas y ordenadas, por aclarar

Qué tienes activado ahora mismo en tu web

No hace falta que lo adivines, las herramientas de desarrollador de Chrome te lo dicen directamente:

• Resource hints clásicos: mira el código fuente de tu web y busca en el <head> etiquetas <link rel="dns-prefetch">, <link rel="preconnect"> o <link rel="preload">.
• Speculation Rules: abre DevTools, pestaña Application, apartado Speculative loads, sección Speculations. Pasa el cursor por algún enlace de tu web y mira si aparece algo en la lista.
• bfcache: misma pestaña Application, apartado Background services, sección Back/forward cache, botón Run test. Te dice si la página entraría en bfcache o el motivo exacto por el que no.

Si en los tres casos sale en blanco, ya sabes a cuál de los artículos enlazados más arriba acudir para arreglarlo. Por dónde empezar depende de tu web. Si tienes un blog que actualiza poco, el bfcache es la ganancia más rápida y casi sin pegas, actívalo primero.

Si llevas una tienda con WooCommerce, revisa antes las exclusiones de Speculation Rules en el carrito y en finalizar compra, y prueba bien bfcache con un pedido real antes de darlo por bueno, que ahí sí hay estado que cuidar.

Si todavía no has tocado nada de esto, abre las DevTools del apartado anterior antes de instalar ningún plugin nuevo, para saber de qué punto partes. Y si después de mirarlo te queda alguna duda sobre cuál de las cuatro te conviene en tu caso, ya sabes dónde encontrarme, en los comentarios.

Hay tres posibles situaciones en las que se me ocurre que este artículo te va a resultar útil:

1. Has encargado que te desarrollen un tema a medida y quieres saber si lo que te han entregado es sólido antes de que llegue tráfico real.
2. Tu equipo asume el mantenimiento de una web que no conoce, y el tema a medida es ese territorio sin documentar donde se concentran los apaños, los atajos y los retoques de todo el que ha pasado por el proyecto antes que tú.
3. Te encargan mejorar, actualizar o rediseñar un tema existente, y antes de escribir una sola línea nueva necesitas saber sobre qué base estás trabajando.

En los tres casos la revisión es la misma, lo que cambia es el momento en que la haces y lo que puedes decidir con los resultados.

El artículo va en dos velocidades, de manera que si no te manejas con código cada bloque te indica qué puedes detectar con herramientas visuales y qué pedirle a una IA, y por otro lado, si eres el técnico del proyecto, encontrarás el análisis estático, los comandos y el nivel de detalle que completan el trabajo.

Pretende ser una guía para todo tipo de perfiles, aunque no te veas del todo en los propuestos, lo importante es que nadie se quede sin información útil, incluso si simplemente quieres leerlo para aprender o pillar ideas.

Entorno y herramientas

Antes de revisar una sola línea de código conviene tener preparado lo que vas a necesitar. No es mucho, pero todo imprescindible.

Si no te manejas con código

Lo primero es activar el modo depuración de WordPress. Abre el archivo wp-config.php de tu instalación de pruebas (nunca en producción) y añade estas tres líneas antes de la que dice «That’s all, stop editing!»:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Con esto WordPress empezará a registrar en un archivo debug.log cualquier función obsoleta, aviso de compatibilidad o error que aparezca al navegar por la web. Para leer ese archivo sin salir del administrador instala Debug Log Manager. Luego instala también el plugin oficial Health Check & Troubleshooting, que entre otras cosas te muestra la versión de PHP activa y el estado general de la instalación.

Con esas dos herramientas y una IA (Claude o cualquier otra) ya puedes revisar la mayor parte de lo que este artículo cubre.

Si eres el técnico del proyecto

La combinación que cubre la mayor parte del análisis estático son PHP CodeSniffer con los WordPress Coding Standards y el paquete PHPCompatibility. Con esa combinación puedes detectar problemas de compatibilidad PHP, funciones obsoletas y violaciones de los estándares de WordPress sin ejecutar el código, solo analizando los archivos.

Para análisis en tiempo real mientras navegas la instalación, Query Monitor es la referencia. Y WP-CLI para los comandos que se mencionan a lo largo del artículo.

Si quieres una auditoría asistida por IA de toda la carpeta del tema de una vez, Claude Code con la instrucción inicial sobre el directorio completo es la forma más rápida de tener un primer mapa de problemas priorizado.

Compatibilidad con PHP

Un tema con funciones eliminadas en PHP 8.x no da aviso: da error crítico. Es el tipo de problema que aparece el día que el hosting actualiza la versión de PHP, que es exactamente lo que van a hacer tarde o temprano.

Sin código, WP_DEBUG + Debug Log te avisa de las funciones obsoletas en cuanto navegas por la web con el tema activo. Health Check te muestra la versión de PHP que tienes y si el tema declara una versión mínima compatible.

Con código, PHP CodeSniffer + PHPCompatibility analiza el tema completo sin ejecutarlo, incluyendo archivos que quizás no se llaman en ninguna URL de prueba.

Para el nivel sin código también puedes pegar el contenido de functions.php en una IA con el prompt: «Eres revisor de código PHP. Identifica funciones PHP eliminadas o incompatibles con PHP 8.x en este código de tema WordPress. Para cada caso dime el nombre de función, el número de línea y la alternativa recomendada.»

Crítico

• Uso de funciones eliminadas en PHP 8.x: ereg(), ereg_replace(), mysql_*, create_function(), each(), split(). Si aparecen en el código, el tema puede dejar de funcionar en cualquier actualización de PHP.
• Operador @ usado de forma sistemática para suprimir errores: oculta fallos reales y puede romper el comportamiento en PHP 8 sin aviso ninguno.

Importante

• Comparaciones con == en contextos donde PHP 8 cambia el comportamiento (cadenas numéricas, comparaciones con null): el código parece funcionar pero produce resultados incorrectos en determinadas condiciones.
• Versión PHP mínima declarada en la cabecera del tema muy por debajo de la que el código realmente necesita. Si el tema dice Requires PHP: 5.6 pero usa sintaxis de PHP 7.4, la declaración es incorrecta y puede inducir a error al gestor del hosting.

Menor

• Sintaxis PHP 7.0-7.3 que funciona en 8.x pero no aprovecha las mejoras disponibles: planificable para la próxima iteración, no urgente.
• Ausencia de typed properties o tipado de parámetros: no es un error, es una omisión de buenas prácticas.

Nota importante para WordPress 7.x: el núcleo sube el mínimo a PHP 7.4. Cualquier tema que declare una versión inferior necesita actualizar esa cabecera y revisar el código si usaba sintaxis más antigua.

Funciones de WordPress obsoletas

Una función obsoleta no rompe hoy, pero romperá cuando WordPress decida eliminarla. Y eso pasa en cada versión mayor. La diferencia entre una función obsoleta y una eliminada es solo tiempo.

WP_DEBUG registra los avisos de obsolescencia en el log cada vez que el tema llama a una función que ya no debería usar. Con eso y el log ya tienes la lista. Para el perfil técnico, PHP CodeSniffer con WPCS detecta las funciones obsoletas sin necesidad de ejecutar el tema.

Crítico

• Funciones de WordPress eliminadas del todo (no solo obsoletas): si aparecen en el código, el tema puede dar un error crítico en la próxima actualización del núcleo.
• Modificaciones directas de archivos de wp-includes o wp-admin desde el tema: raro en proyectos modernos, pero ocurre en temas muy antiguos que «parchearon» algo del núcleo directamente.

Importante

• Funciones obsoletas con aviso pero que siguen funcionando: wp_title() (obsoleta desde WP 4.4), get_currentuserinfo(), the_attachment_link(). Funcionan hoy, pero hay que planificar la sustitución.
• Código que asume que el directorio wp-content está en su ruta por defecto usando rutas absolutas literales, en lugar de las constantes WP_CONTENT_DIR o WP_CONTENT_URL.
• Hooks que fueron renombrados pero los originales siguen como alias: el alias puede desaparecer en una versión mayor sin previo aviso adicional.

Menor

• Widgets registrados solo con la API clásica sin compatibilidad con el editor de bloques: funcional hoy, pero visible como deuda si el cliente trabaja con Gutenberg.
• Template files que no usan get_template_part() donde deberían, con código de plantilla duplicado en varios archivos.

Hay una señal que merece párrafo aparte porque no rompe nada hoy pero crea un problema real el día que el cliente quiera cambiar de tema: funcionalidades de plugin metidas dentro del tema. CPTs, shortcodes globales, taxonomías personalizadas dentro de functions.php. Si el cliente cambia de tema, desaparece su contenido. Es Importante a corto plazo y Crítico como estado permanente de un proyecto.

Seguridad del código

Este bloque tiene solapamiento con el artículo sobre temas WordPress con código malicioso. Lo que cubre aquel artículo es código ofuscado, backdoors y malware. Lo que cubre este bloque son los problemas de seguridad que un desarrollador descuidado introduce sin mala intención: variables sin escapar, SQL sin preparar, ausencia de nonces. Son igual de peligrosos y mucho más frecuentes.

PHP CodeSniffer con WPCS detecta automáticamente la mayor parte de los problemas de escapado y sanitización. Para el nivel sin código, el prompt de IA más útil para este bloque es: «Identifica en este código PHP de un tema WordPress variables impresas sin escapar, datos de usuario sin sanitizar y consultas SQL sin usar $wpdb->prepare(). Explica cada caso en términos simples.»

Crítico

• Variables de $_GET, $_POST o $_REQUEST impresas directamente en el HTML sin sanitizar ni escapar: XSS directo.
• $wpdb->query(), $wpdb->get_results() o cualquier otra función de base de datos con interpolación directa de variables sin $wpdb->prepare(): inyección SQL activa.
• Formularios que procesan datos sin verificar nonce con check_admin_referer() o check_ajax_referer().
• Acciones de administración o procesamiento de datos sin current_user_can(): cualquier usuario puede ejecutar esas acciones.
• Uso de eval(), base64_decode() aplicado a variables externas, system() o exec(): señal de alerta máxima. Saltar directamente al artículo de código malicioso para saber qué hacer.

Importante

• echo get_the_title() sin esc_html(): XSS potencial en contextos concretos, no siempre explotable de forma inmediata, pero hay que corregirlo.
• Llamadas a APIs de terceros que envían datos de usuarios sin opción de desactivar y sin mención en la política de privacidad.
• Ausencia de sanitización en campos del Customizer que no se imprimen directamente en el front: riesgo no inmediato, pero es deuda documentada.

Menor

• Fuentes de Google cargadas desde fonts.googleapis.com sin opción de desactivar: problema de cumplimiento del RGPD, no de seguridad activa, pero requiere solución.
• Nonces ausentes en formularios de solo lectura que no modifican datos: bajo riesgo real, pero incumple los estándares de WordPress.

Rendimiento

Los problemas de rendimiento de un tema a medida no siempre aparecen en el desarrollo. Aparecen cuando la web tiene contenido real, con cientos de entradas y miles de visitas. Un N+1 que pasa desapercibido en desarrollo puede tumbar un servidor con tráfico real.

Query Monitor es la herramienta para ambos perfiles: se instala como plugin, no necesita configuración y muestra en tiempo real las queries que ejecuta cada carga de página, cuánto tarda cada una y de dónde viene. Para el resultado agregado, PageSpeed Insights da la imagen completa del impacto en el usuario.

Crítico

• WP_Query o get_posts() dentro de un bucle de posts: el N+1 clásico. Si tienes 50 entradas en un listado y cada una dispara su propia query adicional, son 51 queries donde debería haber 1 o 2.
• wp_remote_get() o llamadas curl en cada carga de página sin ninguna caché con transients: cada visita hace una petición HTTP a un servicio externo que puede tardar segundos o estar caído.
• jQuery propio incluido en la carpeta del tema cargando en paralelo al de WordPress: doble carga y conflictos de versión garantizados.

Importante

• Scripts y estilos encolados en todas las páginas sin condición cuando solo hacen falta en plantillas concretas: un slider de JavaScript cargando en cada entrada del blog aunque el slider solo esté en la portada.
• WP_Query sin 'no_found_rows' => true en consultas que no paginarán nunca: WordPress hace un COUNT(*) adicional innecesario. Coste medible con tráfico real.
• Opciones guardadas en wp_options con autoload=yes cuando no hacen falta en cada carga de página: se suman al peso de la consulta de opciones que WordPress ejecuta en cada petición.
• CSS crítico no inline, haciendo que el navegador espere una hoja de estilos externa antes de renderizar nada visible.

Menor

• Scripts encolados en el header que podrían ir al pie con el quinto parámetro a true en wp_enqueue_script().
• Imágenes del tema sin loading="lazy" donde procede.

Malas prácticas y estándares heredados

Este bloque cubre los problemas que no rompen nada hoy pero que hacen el mantenimiento difícil y el comportamiento impredecible. Son los que aparecen cuando hay que cambiar el dominio, migrar el proyecto a un nuevo servidor o simplemente actualizar algo que estaba «atado con alambres».

Crítico

• Funciones sin prefijo o con prefijo genérico: get_menu(), init(), setup(). Si en algún momento se activa un plugin que declara una función con el mismo nombre, el conflicto es un error fatal.
• IDs de páginas o entradas hardcodeados en la lógica del tema: if ( $post->ID === 42 ). Ese ID 42 no existe en el servidor de desarrollo, ni en el staging, ni en el siguiente proyecto que use el mismo tema base.
• Slugs de categorías o taxonomías hardcodeados en condicionales: mismo problema exacto que los IDs.
• URLs absolutas hardcodeadas al dominio de producción o de desarrollo: si el dominio cambia, el tema queda roto en silencio. Buscar cualquier cadena con https:// o http:// dentro del código PHP y las plantillas.

Importante

• Rutas absolutas de servidor hardcodeadas como /var/www/html/wp-content/themes/... en lugar de get_template_directory() o get_stylesheet_directory().
• Colores, dimensiones o configuraciones hardcodeadas en JavaScript que deberían venir de variables CSS o de opciones del Customizer: cuando el cliente quiere cambiar el color corporativo, toca editar código.
• Archivos de desarrollo dentro de la carpeta del tema: node_modules, .git, archivos .log, copias .bak, .DS_Store. Ninguno de esos tiene que llegar a producción.
• die() o exit() donde debería usarse wp_die(): WordPress pierde el control de la ejecución y el usuario recibe un pantallazo en blanco sin contexto.

Menor

• Cadenas de texto no envueltas en funciones de traducción (__(), _e()): el tema no es internacionalizable, pero no rompe nada. Planificable si el proyecto va a necesitar varios idiomas.
• functions.php de varios miles de líneas sin estructura de includes ni documentación: no rompe nada, pero hace el mantenimiento muy difícil.
• Comentarios en el código en el idioma del desarrollador original cuando no es el del equipo que hereda el proyecto.
• Código comentado con funcionalidades a medias o parches rápidos sin explicación.

Dependencias y servidumbres

Un tema a medida acumula dependencias que no siempre son visibles en el código. Algunas son técnicas, otras son contractuales. El momento de descubrirlas no es cuando algo deja de funcionar, sino antes de comprometerte a mantener el proyecto.

Crítico

• Plugins bundled (empaquetados) dentro de la carpeta del tema sin los cuales el tema da error crítico: si ese plugin falla, se desactiva o deja de existir en WordPress.org, la web se cae. Los plugins son plugins, van en su carpeta, no dentro del tema.
• Código que llama a is_plugin_active() sin manejar el caso de que el plugin no esté activo: en el momento en que alguien desactiva ese plugin por lo que sea, el tema da un error fatal.
• Librerías JavaScript o CSS de terceros copiadas dentro del tema con versiones que tienen vulnerabilidades conocidas. Buscar en Patchstack o WPScan las versiones incluidas.

Importante

• Dependencia de un page builder integrado en el tema de forma que desinstalarlo afecta al contenido existente: es una decisión de arquitectura que hay que documentar y comunicar al cliente.
• APIs de terceros integradas sin fallback: si la API no responde, ¿la página da error o simplemente no muestra esa sección? Hay que saberlo antes de que le pase al usuario.

Menor

• Fuentes de Adobe Fonts, Typekit u otros servicios de pago integrados sin documentar la licencia activa ni quién la controla: funciona mientras la licencia esté vigente, pero hay que saber quién paga eso.
• Tema hijo de un tema padre comercial (Divi, Avada, Genesis): la dependencia de la licencia del padre hay que documentarla y saber quién la controla.

SEO y estructura semántica

Aquí es donde más destrozos se acumulan en temas a medida y donde menos gente mira. Un tema puede pasar todos los controles anteriores y seguir siendo un problema grave para el posicionamiento y para los lectores de pantalla. La estructura semántica incorrecta no da error ninguno, pero Google y los motores de búsqueda la leen y la valoran cada vez que rastrean la página.

Para el propietario sin código, las herramientas más útiles aquí son el inspector del navegador (clic derecho > Ver código fuente para el HTML completo) y la extensión Headings Map para Chrome o Firefox, que visualiza el árbol completo de encabezados de una página de un vistazo. Lighthouse en DevTools detecta imágenes sin alt y otros problemas de accesibilidad. Para el análisis semántico asistido por IA, pegar el código fuente HTML completo de la página con el prompt: «Analiza la estructura de encabezados de este HTML. Dime cuántos H1 hay, si hay saltos de jerarquía y si algún encabezado está en un lugar estructuralmente incorrecto.»

Crítico

• Múltiples etiquetas <h1> en la misma página: el logotipo, el nombre del sitio y el título de la entrada con el mismo nivel de importancia. Google espera un solo <h1> por página.
• <h1> ausente en páginas de contenido o colocado en elementos decorativos sin contenido relevante.
• El tema genera su propia etiqueta <title> hardcodeada ignorando WordPress y el plugin SEO activo: el resultado es dos etiquetas <title> en el HTML.
• Meta description o canonical generados por el tema en paralelo a los del plugin SEO: conflicto directo entre dos fuentes que dicen cosas distintas.
• Etiquetas Open Graph (og:title, og:image, og:description) hardcodeadas en el tema: invalida completamente lo que configuren tanto el cliente como el plugin SEO.
• Schema markup emitido por el tema en paralelo al del plugin SEO: datos estructurados duplicados o contradictorios que Google puede ignorar o interpretar mal.
• Meta robots hardcodeado en el tema: puede estar bloqueando la indexación de páginas enteras sin que nadie lo sepa.

Importante

• Saltos de jerarquía de encabezados: pasar de <h1> a <h4> directamente porque visualmente quedaba mejor así.
• Encabezados <h2> o <h3> usados en menús de navegación, sidebars o footer por razones de estilo: rompen la jerarquía del contenido de cada página.
• Paginación implementada con JavaScript sin etiquetas <a href> reales: Google no puede rastrear el contenido paginado si no hay URLs enlazables.
• Botones de acción o elementos de navegación implementados con onclick o <div> sin href real: invisibles para Google y para el teclado.
• Imágenes sin atributo alt, incluso las decorativas que deberían llevar alt="": problema de accesibilidad y de SEO de imágenes.
• Links sin texto visible (solo icono sin aria-label): los motores de búsqueda no saben qué enlaza ese elemento.
• Microdata (itemscope, itemtype) incompleta o mezclada con JSON-LD del plugin SEO: la fuente única de schema debería ser el plugin SEO, no el tema.

Menor

• Imágenes con alt que contiene el nombre de archivo literal (IMG_4582.jpg): no aporta nada y el buscador lo sabe.
• Elementos semánticos HTML5 (<article>, <main>, <nav>, <footer>) ausentes o usados de forma incorrecta: impacto principalmente en accesibilidad, menor en SEO directo.
• Múltiples elementos <nav> sin aria-label que los distinga: los lectores de pantalla no pueden diferenciarlos.
• Atributos target="_blank" en links externos sin rel="noopener".
• Texto oculto con display:none o visibility:hidden sobre contenido con palabras clave: puede interpretarse como intento de manipulación aunque no lo sea.

Estructura general del código

Antes de tocar nada conviene saber exactamente qué tienes entre manos. No para arreglarlo de inmediato, sino para no romper algo que no sabías que existía.

Crítico

• Tema que es en realidad un tema padre comercial modificado directamente (Divi, Avada, Elementor Hello con cambios en los archivos del padre): en la próxima actualización del padre, los cambios desaparecen sin dejar rastro.
• Ausencia total de tema hijo cuando se trabaja sobre un tema padre: cualquier actualización borra las personalizaciones sin aviso.
• Código del tema que escribe o modifica archivos del servidor en tiempo de ejecución fuera de la carpeta de uploads: señal de alerta que puede ser un mecanismo de persistencia.

Importante

• functions.php monolítico de varios miles de líneas sin estructura de includes ni organización visible: funciona, pero el mantenimiento es costoso y el riesgo de romper algo al editar es alto.
• Mezcla de lógica de tema y lógica de negocio en los mismos archivos: hace difícil separar qué es el tema y qué es personalización específica del proyecto.

Menor

• Ausencia de changelog o historial de cambios, aunque sea en comentarios: no rompe nada, pero hace imposible saber qué se tocó y cuándo.
• Tema hijo con un style.css vacío o con cabecera incorrecta o incompleta: técnicamente funcional, pero señal de que se creó con prisas.

Tiendas online

Si no hay WooCommerce en la instalación, este bloque no aplica y puedes saltarlo. Si la hay, es igual de importante que cualquiera de los anteriores.

Plantillas de WooCommerce

Cuando un tema a medida copia plantillas de WooCommerce a su propia carpeta woocommerce/, esas plantillas quedan congeladas en la versión de WC que había cuando se programó el tema. Cada actualización de WooCommerce puede cambiar esas plantillas, y si el tema no las actualiza al mismo ritmo, la tienda empieza a comportarse de formas inesperadas y a veces invisibles hasta que el cliente llama.

WooCommerce avisa en WooCommerce > Estado > Herramientas si hay plantillas obsoletas, con la versión de la plantilla original y la que tiene el tema. Si hay plantillas en esa lista, hay trabajo pendiente.

Schema y breadcrumbs de WooCommerce

Si el tema emite su propio schema de producto (JSON-LD o microdata) en las páginas de producto de WooCommerce, entra en conflicto con el que genera el plugin SEO. Uno de los dos debe ganar, y lo razonable es que sea el plugin SEO, no el tema. Revisar el código fuente de una página de producto y buscar bloques <script type="application/ld+json">: si hay más de uno, hay un problema.

Lo mismo con las migas de pan: si el tema tiene los suyos y los de WooCommerce también están activos, el resultado puede ser dos migas de pan en la misma página o ninguna en las páginas de producto.

Crítico

• Acceso directo a pedidos mediante wp_posts o wp_postmeta con post_type='shop_order': desde WooCommerce 7.1, HPOS (High Performance Order Storage) mueve los pedidos a tablas propias. Si el tema consulta pedidos de la forma antigua, falla en cualquier instalación con HPOS activo.
• Uso de $woocommerce->cart, $woocommerce->session u otros accesos directos al global $woocommerce: reemplazados por WC()->cart, WC()->session hace años. Funcionan en instalaciones antiguas, rompen en las nuevas.
• Funciones de WooCommerce eliminadas en versiones recientes: igual que con las funciones de WordPress, si aparecen en el código el tema puede dar error crítico en la próxima actualización mayor de WC.
• Código que llama a funciones de WooCommerce sin comprobar previamente si WC está activo: si WC se desactiva aunque sea temporalmente, el tema da error fatal en lugar de degradar con gracia.

Importante

• Plantillas de WooCommerce sobreescritas con versiones muy por detrás de la actual: el riesgo de rotura es proporcional a la diferencia de versiones.
• Hooks de WooCommerce obsoletos con alias activos: funcionan, pero el alias puede desaparecer en una actualización mayor. Planificar sustitución.
• Assets de WooCommerce desactivados globalmente en el tema cuando solo deberían desactivarse fuera de las páginas de tienda: puede producir carrito roto o checkout sin estilos en algún caso concreto.

Menor

• Plantillas sobreescritas con una o dos versiones de diferencia y sin cambios funcionales conocidos en esas versiones: bajo riesgo inmediato, pero hay que revisarlas en la próxima actualización de WC.

Por dónde empezar

Los tres niveles del artículo trasladan directamente a la priorización del trabajo:

Crítico: corregir antes de entregar, publicar o tocar nada más

No hay entrega válida con críticos abiertos. Si el encargo es asumir el mantenimiento de un proyecto heredado, los críticos se resuelven antes de cualquier otra tarea.

• Vulnerabilidades de seguridad activas: SQL sin preparar, variables sin escapar impresas, ausencia de nonces en formularios que modifican datos.
• Incompatibilidades PHP que pueden dar error crítico con la próxima actualización del servidor.
• Funciones de WordPress o WooCommerce eliminadas del todo.
• Conflictos SEO activos: doble etiqueta <title>, metas duplicadas, meta robots hardcodeado.
• N+1 queries en producción con tráfico real.
• Tema padre comercial modificado directamente sin tema hijo.

Importante: planificar en la próxima actuación

Antes de la siguiente actualización mayor de WordPress o PHP.

• Funciones WP o PHP obsoletas con sustitución conocida.
• Scripts y estilos sin condición que cargan en todas las páginas.
• IDs, slugs y URLs hardcodeados en la lógica del tema.
• APIs de terceros sin fallback documentado.
• Plantillas WooCommerce con varias versiones de diferencia.
• Saltos de jerarquía de encabezados y paginación sin links reales.

Menor: documentar y corregir

Cuando se pase por ese código por otra razón.

• Estilo de código y cumplimiento de estándares de WordPress.
• Cadenas sin traducir, comentarios en el idioma incorrecto, archivos sobrantes.
• Scripts que podrían ir al pie, imágenes sin lazy load.
• Alt de imagen con nombre de archivo, elementos semánticos HTML5 ausentes.

Una vez el tema está limpio y en producción, el escáner de cambios de archivos de Vigilante avisa si alguien modifica un archivo del tema sin que lo sepas, que es exactamente lo que ocurre cuando un ataque planta un backdoor en un archivo que ya existía. No te libra de hacer la auditoría, pero cierra la puerta después de haberla hecho.

Compatibilidad futura

La auditoría que acabas de hacer es una foto del tema en este momento. Un tema bien hecho hoy puede dejar de funcionar en seis meses si nadie vigila lo que viene. Este bloque no es sobre arreglar nada: es sobre no tener que volver a arreglar las mismas cosas en la siguiente revisión porque nadie las anticipó.

PHP

El patrón de PHP es siempre el mismo: lo que hoy es un aviso de obsolescencia, en la siguiente versión mayor desaparece sin más. La lista de lo que PHP 9 va a eliminar ya existe hoy, en forma de avisos de obsolescencia en PHP 8.x. Eso significa que si el tema genera avisos de obsolescencia con PHP 8.5 o con la 8.6 que llega a finales de 2026, esos avisos son exactamente lo que va a romper cuando llegue PHP 9.

PHP 9 no tiene fecha oficial todavía, pero eso no cambia la lógica: las obsolescencias actuales son las eliminaciones futuras. PHPCompatibility te permite pasar como parámetro una versión objetivo futura para que analice el código contra lo que sabe que vendrá. Si aún no tienes configurado PHP CodeSniffer con PHPCompatibility, este es el argumento más práctico para hacerlo.

Para seguir el roadmap de PHP sin tener que buscar manualmente, PHP.Watch mantiene una lista actualizada de todas las versiones en desarrollo, con las obsolescencias y eliminaciones previstas para cada una. Suscribirse a su feed RSS o newsletter es el método más directo de no perderse nada relevante antes de que llegue al servidor.

Lo que hay que comprobar con PHPCompatibility al auditar un tema a medida no es solo la versión de PHP actual del servidor, sino también las siguientes:

• PHP 8.5 (estable desde noviembre de 2025): la versión que muchos hostings tienen como recomendada para 2026.
• PHP 8.6 (prevista para finales de 2026): ya tiene calendario oficial y los primeros RFCs de obsolescencias aprobados.
• PHP 9.x (sin fecha oficial): usar PHPCompatibility en modo --runtime-version=9.0 avisa de lo que ya está marcado como candidato a eliminación en los milestones públicos de php-src.

WordPress

WordPress avisa con antelación de todo lo que deja obsoleto y de todo lo que planea eliminar. El problema es saber dónde mirarlo. Estos son los canales que importan si mantienes un tema a medida:

• Make WordPress Core: el blog de desarrollo del núcleo. Aquí se publican las agendas de los dev chats semanales, los field guides de cada versión y las propuestas de cambios que afectarán a temas y plugins. Si solo sigues un canal, que sea este.
• WordPress Developer Blog: el canal oficial para desarrolladores de plugins y temas. Las dev notes de cada versión se publican aquí con el detalle de qué cambia, qué queda obsoleto y qué hay que actualizar antes de la siguiente mayor.
• Make WordPress Security: el blog del equipo de seguridad. Publica las notas de los problemas resueltos en cada versión puntual y las iniciativas de seguridad del ecosistema.

Ambos blogs tienen feed RSS. Añadirlos al lector de feeds del equipo es suficiente. No hace falta revisar Make Core a diario: las entradas importantes son fáciles de identificar por las etiquetas dev-notes y field-guide.

Para el perfil técnico, el comando wp core check-update de WP-CLI comprueba si hay actualizaciones pendientes del núcleo. Y revisar periódicamente con PHP CodeSniffer + WPCS las funciones del tema contra la versión de WPCS actualizada detecta lo que el equipo de WordPress Core ya ha marcado como deprecated en el estándar, aunque el tema aún funcione hoy sin avisos visibles.

Seguridad

Un tema a medida no está en ninguna base de datos de vulnerabilidades públicas, así que las alertas que importan aquí son las de las librerías de terceros que incluya y las del ecosistema general de WordPress. El 91% de las vulnerabilidades reportadas en WordPress en 2025 estaban en plugins y temas de terceros, no en el núcleo.

Si el tema incluye librerías JavaScript o PHP copiadas en su carpeta, esas librerías sí pueden aparecer en las bases de datos.

Las fuentes que conviene tener activas:

• Patchstack Database: base de datos gratuita de vulnerabilidades en plugins, temas y el núcleo de WordPress. El plan gratuito incluye alertas por email con hasta 48 horas de antelación sobre nuevas vulnerabilidades reportadas. Útil tanto para los plugins de la instalación como para identificar si alguna librería incluida en el tema tiene CVE conocido.
• WPScan Vulnerability Database: base de datos pública con vulnerabilidades de WordPress clasificadas por severidad. Tiene API gratuita para consultas automatizadas y se puede integrar en pipelines de CI/CD.
• WordPress.org Security: las notas oficiales de cada versión de seguridad del núcleo. Feed RSS disponible. Las versiones menores de WordPress (las que tienen tres números, como x.x.1) suelen ser parches de seguridad, y el equipo de WordPress las publica con descripción de lo que corrigen.
• Wordfence Intelligence: el blog de inteligencia de amenazas de Wordfence publica análisis de vulnerabilidades activas, con descripción técnica y estado de explotación. Especialmente útil cuando una vulnerabilidad está siendo explotada masivamente y el tema puede incluir el componente afectado.

WooCommerce

WooCommerce sigue un ciclo de lanzamientos propio, independiente del de WordPress, con versiones mayores que introducen cambios de API y obsolescencia propias. Para mantenerse al día conviene seguir el WooCommerce Developer Blog y revisar el changelog de cada versión mayor antes de actualizar en producción. Las plantillas sobreescritas que ya revisaste en el bloque anterior son exactamente el tipo de deuda que se acumula cuando el mantenedor no sigue ese ritmo.

Periodicidad mínima de revisión

Todo lo anterior tiene sentido si se convierte en un hábito, no en una tarea puntual. Esta es la cadencia mínima razonable para un tema a medida en producción:

• Mensual: revisar las alertas de Patchstack o WPScan para los componentes que incluye el tema. Aplicar las actualizaciones de seguridad pendientes del núcleo y los plugins.
• Con cada versión mayor de WordPress: ejecutar PHP CodeSniffer + WPCS actualizado sobre el tema para detectar lo que la nueva versión ha dejado obsoleto. Revisar las dev notes del Developer Blog antes de actualizar en producción.
• Con cada versión mayor de PHP disponible en el hosting: ejecutar PHPCompatibility contra esa versión en staging antes de cambiarla en producción.
• Anual: repetir la auditoría completa de este artículo. Lo que era Menor el año pasado puede haberse convertido en Crítico si el ecosistema ha avanzado y el tema no.

La IA como herramienta de auditoría: los prompts que más uso

Estos son los prompts prácticos para las revisiones más habituales. No sustituyen al análisis en tiempo de ejecución (Query Monitor, el log de errores) pero cubren gran parte del análisis estático sin instalar nada.

Para el propietario sin código (pegar el contenido de functions.php):

Lee este archivo functions.php y dime en términos simples si hay algo peligroso, algo obsoleto y algo que podría dar problemas de rendimiento. No asumas que sé programar.

Para el análisis SEO (pegar el código fuente HTML completo de la página):

Analiza la estructura de encabezados de este HTML. Dime cuántos H1 hay, si hay saltos de jerarquía y si algún encabezado está en un lugar estructuralmente incorrecto. Busca también si hay más de una etiqueta title o más de una meta description.

Para el técnico (Claude Code sobre la carpeta completa del tema):

Audita este tema WordPress a medida. Busca: 1) vulnerabilidades de seguridad (XSS, SQL injection, ausencia de nonces y de comprobaciones de capacidades); 2) funciones PHP eliminadas o incompatibles con PHP 8.x; 3) funciones WordPress obsoletas; 4) N+1 queries; 5) scripts encolados sin condición en todas las páginas. Clasifica los hallazgos en Crítico, Importante y Menor, y dame el archivo y la línea de cada uno.

Una limitación que hay que tener clara es que la IA detecta problemas en el código estático, no en la ejecución, no rastrea el comportamiento en tiempo real, no ejecuta el tema ni simula una carga real. Es complementaria a Query Monitor y al log de errores, no los reemplaza.

Un regalo para terminar

Y ya que has llegado hasta aquí, para no tener que documentar la auditoría en un Excel improvisado ni en un bloc de notas, hay una herramienta gratuita, la auditoría de temas WordPress, que he creado exactamente para esto.

La abres al lado de lo que estés revisando, vas añadiendo hallazgos con el bloque, la descripción, la gravedad y la acción propuesta, y cuando terminas un botón genera el informe completo listo para exportar, descargar en PDf, imprimir o enviar al cliente. Sin cuenta, sin IA, sin conexión necesaria, todo en tu navegador.

Si tienes dudas sobre lo que encuentres, o quieres apoyo en el mantenimiento continuo de la web una vez resuelta la auditoría, en mi servicio de mantenimiento web tienes la opción de delegar eso. Y para cualquier cosa que no quede clara me tienes en los comentarios.

A eso se le llama spam SEO inyectado, y no persigue tumbar tu web ni robarte datos, lo que busca es aprovechar la autoridad que llevas años construyendo para posicionar webs basura de farmacias ilegales, tiendas de imitaciones de lujo o casinos online. Usan tu dominio como trampolín, y mientras ellos cobrando las comisiones de afiliados.

El informe State of WordPress Security de Patchstack recoge datos de Sucuri que cifran en más de 422.000 los incidentes de spam SEO detectados en 2024, con el spam japonés como la variante más extendida, responsable del 27,77% de todos los casos. No es un problema marginal ni de lejos.

Vamos a ver qué formas tiene este ataque de inyección de spam, cómo detectarlo y cómo cerrarlo, desde lo más básico hasta lo más potente.

Tres tipos de spam SEO, tres niveles de problema

No todos los ataques de spam SEO son iguales ni entran por el mismo sitio ni se detectan igual. Conviene distinguirlos antes de ponerse a tapar agujeros a ciegas.

El más visible: spam en los comentarios

El atacante (o casi siempre un bot automatizado) publica comentarios que incluyen enlaces a las webs que quieren posicionar. Google rastrea esos enlaces cuando visita tu web y les transfiere autoridad, el resultado es que tu web contribuye al SEO de una farmacia sin receta, una tienda de relojes falsificados o cualquier otra web de mierda.

Es el nivel básico, es feo, molesto y contraproducente para tu propio perfil de enlazado, pero por otro lado es fácil de detectar porque lo ves tú mismo en la sección de comentarios.

El nivel medio: inyección de enlaces en la base de datos

Aquí ya el atacante ha conseguido entrar en tu instalación, pues en lugar de dejar un comentario, inyecta enlaces directamente en el contenido de tus entradas o páginas, en campos de la base de datos como wp_options o wp_postmeta, o en el código del tema. Los enlaces pueden ir con CSS que los oculta visualmente a los visitantes humanos, pero que los rastreadores de los buscadores leen perfectamente.

No lo ves navegando tu web, pero lo puedes ver revisando el código fuente de la página o auditando la base de datos.

El más peligroso: el pharma hack y el spam japonés con cloaking

Este es el nivel que da más guerra, nunca mejor dicho, pues el atacante instala en tus archivos o en la base de datos un código que comprueba quién está visitando la página antes de decidir qué contenido servir.

Si detecta que es un rastreador de Google, Bing o Yandex, sirve páginas llenas de palabras clave farmacéuticas o texto en japonés, si detecta a un visitante humano normal, muestra tu contenido de siempre. Podríamos decir que es hackeo inteligente.

El resultado es que tú entras a tu web y ves todo perfecto, pero ve un catálogo de medicamentos sin receta con miles de páginas generadas automáticamente.

Esta técnica se llama cloaking (camuflaje), y es deliberada porque los atacantes no quieren que lo descubras. Cuanto más tiempo lleve activo, más autoridad de tu dominio han aprovechado, y cuanto más tarde en detectarse, más difícil es la recuperación del SEO después.

El truco que hace invisible la infección

Para entender por qué no lo ves desde el escritorio de WordPress hay que entender cómo funciona el cloaking.

El código malicioso, que puede vivir en tu .htaccess, en tu wp-config.php, en el functions.php del tema o en archivos de plugins, lee la cabecera User-Agent de cada petición que llega al servidor. Esa cabecera identifica quién hace la petición: si es Chrome, Firefox, Safari o un bot de Google.

Si el User-Agent es Googlebot, Bingbot, baiduspider o cualquier rastreador conocido, el código conecta con el servidor del atacante, descarga el contenido de spam del momento y lo sirve. Si eres tú entrando desde el navegador, con tu sesión de WordPress activa o simplemente con un User-Agent de navegador normal, ves tu web tal cual.

Este mecanismo explica por qué muchos propietarios de WordPress llevan meses o incluso años con la infección activa sin saber nada. Y explica también por qué la primera señal de alarma suele venir de fuera, como de un aviso de Google Search Console, un cliente que lo vio en Google, o una caída inexplicable del tráfico orgánico.

El código malicioso se esconde habitualmente en estos sitios:

• Las primeras o últimas líneas del wp-config.php, camuflado como comentario o como código de configuración aparentemente legítimo.
• El archivo .htaccess, con reglas de redirección condicionales.
• El functions.php del tema activo, aprovechando que se ejecuta en cada carga.
• La carpeta mu-plugins/ (de must-use plugins), que se ejecuta automáticamente en cada carga de página y no aparece en la lista de plugins del escritorio, lo que la convierte en el escondite preferido para la persistencia después del hackeo.
• La carpeta uploads/, donde a veces aparecen archivos .php disfrazados de imágenes.
• Opciones de la base de datos en wp_options, codificadas en base64 para dificultar la detección.

Y sobre la cadena de suministro como vector de entrada, si no leíste el artículo de los ataques a la cadena de suministro en WordPress que publiqué hace unas semanas, te lo resumo en que el caso Essential Plugin fue exactamente esto, una puerta trasera que servía spam SEO camuflado solo a los rastreadores, invisible para los propietarios. El ataque más sofisticado posible a través del canal oficial de actualización de plugins.

Cómo saber si te han inyectado spam SEO antes de enterarte por Google

No esperes al aviso de Search Console. Para cuando Google te manda la alerta, la infección lleva semanas o meses activa y el daño al SEO ya está hecho, es mucho mejor buscarlo activamente ¿a que sí?.

La búsqueda más directa

Ve a Google y escribe site:tudominio.com, revisa los resultados que aparecen, y si ves páginas con caracteres japoneses, títulos sobre medicamentos, casinos o productos que no tienen nada que ver con tu contenido real, date por inyectado.

También puedes añadir términos sospechosos: site:tudominio.com viagra, site:tudominio.com casino. Si aparece algo ya tienes la confirmación.

Google Search Console

En la sección de seguridad y acciones manuales aparecerán los avisos si Google ya ha detectado el problema. Pero no esperes solo a eso, en el inspector de URLs puedes comparar cómo procesa Google una URL concreta de tu web frente a cómo la ves tú. Si el contenido que ve Google no coincide con el que ves tú, ¡te han cloakeado!

Ojo también con los usuarios que tienen acceso a tu Search Console. Una técnica habitual es añadir un usuario del atacante como propietario o delegado para poder manipular el sitemap e indexar las páginas de spam. Revísalo en Ajustes → Usuarios y permisos.

Herramientas de escáner externo

El escáner gratuito Sucuri SiteCheck analiza tu web desde fuera, como lo haría un motor de búsqueda, y detecta código malicioso, listas negras y redirecciones sospechosas. No necesitas instalar nada.

También la base de datos de WPScan te permite comprobar si alguno de tus plugins tiene vulnerabilidades conocidas activas.

Lo que puedes ver desde el escritorio de WordPress

Ve a Usuarios → Todos los usuarios y filtra por el perfil de administrador. ¿Los reconoces todos? Una práctica habitual tras un hackeo es crear usuarios administradores falsos para mantener el acceso aunque limpies los archivos. Borra sin piedad cualquier usuario que no reconozcas.

WP-CLI si tienes acceso por SSH

Si tienes acceso al servidor, estos tres comandos te dan una imagen rápida del estado:

wp core verify-checksums
wp plugin verify-checksums --all
wp user list --role=administrator --format=table

El primero compara los archivos del núcleo de WordPress con los oficiales y te dice si alguno ha sido modificado, el segundo hace lo mismo con los plugins que tienen checksums en WordPress.org (esto mismo puedes hacerlo con Vigilante), y el último lista todos los administradores para que compruebes quién está ahí.

Para buscar código sospechoso en PHP lanza esto en la raíz de tu instalación:

grep -ri "base64_decode\|eval(" wp-content/ --include="*.php" -l
find wp-content/uploads -name "*.php" -ls

El primer comando busca los patrones de ofuscación más comunes, el segundo lista todos los archivos PHP que hay en uploads/, donde no debería haber ninguno.

De lo más básico a lo más serio: así cierras la puerta

Ninguna medida por sí sola es suficiente. La defensa funciona por capas, y cada capa tapa los agujeros que la anterior deja sin cubrir.

Capa básica: comentarios y acceso público

La primera y más sencilla. No protege contra el pharma hack ni el spam japonés, pero sí contra el spam de comentarios y contra que atacantes anónimos inyecten contenido.

• Cierra los comentarios en entradas antiguas: En Ajustes → Comentarios, activa «Cerrar automáticamente los comentarios de entradas con más de X días de antigüedad». Los bots de spam atacan preferentemente entradas viejas porque suelen tener menos supervisión.
• Modera todos los comentarios antes de publicarlos: En el mismo panel, activa «El comentario debe aprobarse manualmente». Ningún enlace de spam se publica sin que tú lo veas primero.
• Instala un filtro de spam: Akismet sigue siendo la referencia, aunque requiere clave de API. Alternatives gratuitas como Antispam Bee o CleanTalk funcionan bien en la mayoría de casos.
• Desactiva los pingbacks: En Ajustes → Comentarios, desmarca «Permitir avisos de enlace de otros blogs». Los pingbacks tienen un uso muy limitado en 2026 y son un vector de abuso.
• Desactiva el registro de usuarios si no es imprescindible: En Ajustes → Generales, desmarca «Cualquiera puede registrarse». Si tu web no necesita que los visitantes tengan cuenta, no hay razón para exponerlo.

Capa media: archivos, permisos y credenciales

Aquí va el grueso de la protección contra los ataques más sofisticados. Patchstack registró en 2025 la cifra de 11.334 vulnerabilidades en el ecosistema WordPress, con un tiempo medio de apenas 5 horas desde que se publica la vulnerabilidad hasta que los bots la explotan. Mantener todo actualizado no es opcional, es la primera línea de defensa real.

• • Actualiza siempre y cuanto antes: WordPress, plugins y temas. El 91% de las vulnerabilidades de 2025 estaban en plugins, no en el núcleo. Cada plugin sin actualizar es una puerta potencialmente abierta.
  • Permisos de archivos correctos: Los archivos deben estar a 644 y los directorios a 755. El wp-config.php puede ir a 440 o 400 si tu servidor lo permite.
  • Protege los archivos sensibles desde el servidor: Añade esto por encima del bloque # BEGIN WordPress:

# Proteger wp-config.php
<Files wp-config.php>
  Order Allow,Deny
  Deny from all
</Files>

# Proteger .htaccess
<Files .htaccess>
  Order Allow,Deny
  Deny from all
</Files>

# Bloquear ejecución de PHP en uploads
<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteRule ^wp-content/uploads/.*\.php$ - [F,L]
</IfModule>

# Deshabilitar listado de directorios
Options -Indexes

• Bloquea la ejecución de PHP en la carpeta uploads/: Esta carpeta tiene que poder recibir archivos subidos, pero nunca ejecutar PHP. Es uno de los vectores de acceso más habituales una vez que un atacante ha conseguido subir un archivo malicioso.
• Contraseñas fuertes y únicas para todos los administradores: Si tienes varios usuarios con rol de Administrador, cada uno con su propia contraseña segura. Un gestor de contraseñas como Bitwarden lo hace fácil y gratuito.
• Elimina el usuario admin si todavía lo tienes: Es el primer nombre de usuario que prueban todos los ataques automatizados.
• Elimina temas y plugins nulled o piratas: Esto no lo negocies: los temas y plugins de fuentes no oficiales son el vector de infección más rápido y más evitable. Si los tienes, quítalos.
• Desactiva XML-RPC si no lo usas: La mayoría de webs WordPress no lo necesitan actualmente y es un vector de ataque muy usado para inyectar contenido de forma remota.

Capa avanzada: monitorización activa

Llegamos al punto donde la defensa deja de ser reactiva y se vuelve proactiva. No solo cerramos puertas sino que detectamos cuando alguien intenta abrirlas.

El archivo .htaccess y wp-config.php son los primeros objetivos de cualquier atacante que consiga acceso a tu servidor. Si esos archivos cambian sin que tú hayas tocado nada, tienes una infección activa. El problema es que nadie mira esos archivos todos los días.

Puedes usar Vigilante para monitorizar ambos archivos contra su línea base original, muestra un diff línea a línea de cualquier cambio y manda un aviso por correo en el momento en que detecta la modificación. En vez de enterarte semanas después porque Google te manda un aviso de acción manual, te enteras cuando el atacante toca el archivo. Eso es la diferencia entre limpiar una infección de horas y limpiar meses de daño en el SEO.

Más allá de eso, un escáner periódico de integridad de archivos compara los archivos de tu instalación con los oficiales de WordPress.org y detecta modificaciones, archivos añadidos o código sospechoso en temas y plugins. Lo ideal es que esto corra de forma automática y te mande el informe.

Otras medidas avanzadas:

• Activa la identificación en dos pasos (2FA) para todos los administradores: Si las credenciales quedan expuestas en una filtración, el 2FA es lo que evita que sirvan de algo.
• Registra toda la actividad con un log de auditoría: Logins, cambios de contraseña, activaciones de plugins, modificaciones de entradas, así todo queda registrado y con alerta si algo parece raro. Si un atacante crea un usuario administrador o activa un plugin que no reconoces, necesitas saberlo en el momento.
• Revisa la carpeta mu-plugins/ periódicamente: Los archivos que hay ahí se ejecutan en cada carga de página sin aparecer en la lista de plugins. Si encuentras algo que no pusiste tú, bórralo.
• Usa un cortafuegos a nivel de aplicación: Cloudflare como primera capa (gratis en su plan básico) más un plugin de seguridad con WAF dentro de WordPress bloquea la mayor parte del tráfico malicioso antes de que llegue a intentar explotar nada.
• Activa la detección de plugins cerrados: WordPress.org cierra plugins cuando se descubren problemas de seguridad. Si tienes uno instalado y lo cierran, necesitas saberlo ese mismo día, no cuando busques en Google por qué tu web se comporta raro. Esto lo tiene Vigilante, nadie más.

Para completar la defensa contra fuerza bruta, tienes una guía específica en el plan de batalla contra ataques de fuerza bruta con el detalle de cómo montar la protección por capas desde Cloudflare hasta el plugin.

Ya lo tengo ¿qué hago?

Si llegas a este punto con la confirmación de que tu web está infectada, para. No borres nada todavía. El orden importa porque si limpias sin cerrar el vector de entrada, la infección vuelve en horas.

1. Haz una copia de seguridad completa ahora mismo, incluyendo archivos y base de datos. Incluso de la versión infectada. La necesitarás como referencia para saber exactamente qué cambió y para no perder el contenido legítimo si algo sale mal durante la limpieza.
2. Pon el sitio en modo mantenimiento para que los visitantes no lleguen a las páginas infectadas mientras limpias.
3. Ejecuta un escáner completo (Wordfence, Sucuri o Vigilante) y guarda el informe completo antes de tocar nada. Necesitas la lista de todo lo afectado antes de empezar a limpiar.
4. Limpia el núcleo de WordPress. Descarga la versión exacta que tienes de wordpress.org y sustituye las carpetas wp-admin/ y wp-includes/ por las originales. No toques wp-content/ ni wp-config.php en este paso.
5. Elimina todos los plugins y temas y reinstálalos desde cero. Descarga versiones limpias desde WordPress.org o de sus fuentes oficiales. No reactivar los plugins nulled.
6. Revisa wp-config.php buscando código inyectado al principio o al final del archivo, y revisa .htaccess buscando redirecciones condicionales que no pusiste tú. Si usas Vigilante y tenías el monitoreo activado, el diff te muestra exactamente qué líneas cambiaron.
7. Audita la carpeta mu-plugins/ y la carpeta uploads/ buscando archivos PHP que no deberían estar ahí.
8. Limpia la base de datos. Revisa wp_posts buscando contenido con enlaces ocultos o contenido que no reconoces. Revisa wp_options buscando valores codificados en base64. Busca en wp_users usuarios administradores que no reconoces.
9. Elimina todos los usuarios administrador que no reconozcas y cambia las contraseñas de todos los que sí reconozcas.
10. Cambia las credenciales de todo: WordPress, base de datos, FTP y cuenta de hosting. Si la contraseña que usaban para entrar sigue activa, vuelven.
11. Actualiza WordPress, todos los plugins y todos los temas a la última versión disponible.
12. Ejecuta un segundo escáner completo para verificar que la limpieza ha sido efectiva antes de quitar el modo mantenimiento.

Si después de limpiar la infección vuelve en horas o días, hay algún punto de re-entrada que no has cerrado: un plugin vulnerable que no actualizaste, un usuario comprometido que no eliminaste, o una puerta trasera en mu-plugins/ o en uploads/ que te has dejado. Vuelve al escáner y revisa esos puntos específicamente.

Si el proceso te supera o si el sitio tiene un volumen de páginas infectadas que hace que la limpieza manual sea inviable, el servicio de recuperación de web hackeada existe exactamente para esto.

Recuperar el SEO después del golpe

Limpiar la infección es la mitad del trabajo, la otra es convencer a Google de que ya no hay problema.

Si Google emitió una acción manual contra tu sitio, aparecerá en Search Console → Seguridad y acciones manuales → Acciones manuales. Una vez limpias la web, puedes solicitar revisión desde esa misma pantalla. El equipo de calidad de Google suele responder en unos días en los casos más claros.

Si no hay acción manual sino penalización algorítmica (tu tráfico cayó pero no hay aviso explícito), el proceso es más lento porque Google necesita volver a rastrear las páginas afectadas y procesar que el contenido ya no está. Puedes acelerar esto enviando tu mapa del sitio actualizado desde Search Console y usando la herramienta de inspección de URLs para solicitar la indexación de tus páginas principales.

Las páginas de spam que Google tenía indexadas (los miles de URLs con contenido japonés o farmacéutico) irán desapareciendo del índice a medida que Google las reindexe y confirme que el contenido ya no está. Este proceso puede tardar semanas, no es inmediato, pero sí progresivo.

Monitoriza desde Search Console el número de páginas indexadas de tu dominio durante las semanas siguientes a la limpieza. Si vas bien, verás cómo esas URLs spam van desapareciendo del recuento.

Una última cosa

El spam SEO inyectado no es un ataque de película que requiere un hacker sofisticado persiguiendo tu web específicamente. Son ataques automatizados que explotan vulnerabilidades conocidas a escala industrial. El destino del ataque no eres tú, es el plugin sin actualizar que tienes instalado, y hay bots que escanean millones de webs buscando exactamente eso.

La buena noticia es que la defensa tampoco es complicada, se basa en mantener todo actualizado, cerrar los comentarios donde no hacen falta, monitorizar los archivos que más se tocan en un hackeo (wp-config.php y .htaccess) y tener un escáner que avise cuando algo cambia cubre la inmensa mayoría de los casos. Para eso desarrollé Vigilante, para que no tengas que pagar por todas esas funcionalidades des seguridad imprescindibles.

El trabajo hay que hacerlo antes de que llegue el problema, no después. Cuando Google te manda el aviso el daño ya lleva semanas hecho.

Si tienes dudas o has pasado por esto y quieres compartir cómo fue el proceso, me tienes ahí abajo en los comentarios.

Crónicas WordPress: la actualidad de la semana, sin anestesia

El lunes toca Crónicas WordPress, mi repaso a la actualidad con opinión incluida, que para eso es mi casa. Y esta semana la seguridad se llevó el protagonismo, y no precisamente para bien.

Seguridad: semana movidita

Arrancamos fuerte con la Operación EndGame, el operativo internacional que ha desmantelado una red enorme de malware, con un montón de webs infectadas de por medio. De ahí saltamos a los sospechosos habituales del jardín WordPress, que no dieron tregua:

• Gravity SMTP: una vulnerabilidad ha dejado las claves de correo a la intemperie, con millones de intentos de ataque aprovechando el agujero. Si lo tienes instalado, actualiza ya mismo.
• Avada Builder: fallo crítico que permitía borrar archivos sin ni siquiera estar autenticado, o sea, cualquiera desde fuera. De los que quitan el sueño.
• Secuestro de cookies de sesión: te conté cómo alguien puede colarse en tu WordPress sin contraseña ni 2FA (el doble factor de autenticación), robándote la sesión, y qué hacer para taparlo. Lo tienes con calma en mi artículo sobre la seguridad de las cookies de sesión.

El «congelador» de 24 horas y la rebelión de los desarrolladores

WordPress.org ha decidido retrasar 24 horas la publicación de las actualizaciones de plugins para poder revisarlas antes de que lleguen a tu web. La idea, sobre el papel, tiene sentido. El problema es que los desarrolladores se le han rebelado en bloque, y hay razones para las dos posturas. Le dediqué el último Doctor entero, así que te lo cuento un poco más abajo.

Comunidad: dos WordCamps, un adiós y culebrón judicial

• WordCamp Costa Rica 2026: los días 18 y 19 de septiembre en San José.
• WordCamp Galicia 2026: 17 y 18 de octubre en A Coruña, y las entradas ya están a la venta, así que ya sabes.
• Om Malik: nos ha dejado a los 59 años uno de los primerísimos usuarios de WordPress. Un recuerdo desde aquí.
• Automattic contra WP Engine: el culebrón judicial sigue su curso y Automattic se ha apuntado un tanto en la pelea por los mensajes de Slack. A río revuelto…
• Panel de contribuciones: estrena escalas personalizables, un detalle majo para quien echa una mano al proyecto.

Versiones y producto: WordPress 7.0.1, 7.1 y compañía

En el frente del desarrollo también hubo tela que cortar:

• WordPress 7.0.1 viene de camino, con su candidata a versión final y lanzamiento a la vuelta de la esquina.
• WordPress 7.1 va a esconder el bloque Clásico del insertor. Que no eliminarlo, ojo, que aquí nadie se toca nada todavía.
• WooCommerce 10.9 llega con registro de emails transaccionales y mejoras de interfaz.
• IA en el propio core: el equipo de inteligencia artificial propone meter wp_knowledge en WordPress. El melón está abierto.

IA y SEO ¡ya está liada!

Y cerramos por donde más se mueve el suelo últimamente, la IA y el SEO. Los plugins se están poniendo las pilas: SEOPress 10 se abre a los agentes de IA, trae asistente en el editor y compatibilidad con la Abilities API, mientras que Visibility mete SEO, AEO y GEO (el posicionamiento de toda la vida más el de los buscadores y las respuestas de IA) en un mismo plugin. Sobre si te puedes fiar de los plugins hechos con IA, ya te di mi opinión con matices en este artículo.

En el lado de Google, la actualización de spam de junio de 2026 se completó en tiempo récord, y como muestra del terremoto conté el caso de WPBeginner, que ha pasado de 2,6 millones a 27.000 clics mensuales. Ahí es nada. Si te preguntas qué pintas tú en todo esto, la respuesta pasa por el E-E-A-T, que te expliqué en esta guía.

Ver el directo completo de Crónicas WordPress en YouTube.

Y ya está, porque esta semana no pude hacer el Doctor WordPress por temas de agenda, y ya que lo siento.

Nos vemos en el próximo directo

Y hasta aquí el repaso de la semana. Si te ha quedado alguna duda de cualquiera de los temas, o quieres soltarme tu opinión sobre lo del congelador de plugins (que seguro que tienes la tuya), me tienes ahí abajo, en los comentarios.

Recuerda que hago directo dos veces por semana: Crónicas los lunes y Doctor los miércoles, a partir de las 19:30, en el canal de Ayuda WordPress. Si te suscribes y le das a la campanita, no se te escapará ninguno.

Lo lógico es querer quitarla de los resultados, y haces bien en planteártelo, pero conviene darle una vuelta, porque solo hay una forma correcta de hacerlo y varias maneras de echarlo todo a perder. Y además, una de esas maneras incorrectas se carga justo la señal de autoridad de autor que tanto cuesta construir.

Antes de liarnos ten en cuenta un detalle, y es que desindexar un archivo no es lo mismo que eliminarlo. Desindexar es decirle a Google «esta página existe pero no la muestres en tus resultados», eliminar es hacer que esa página devuelva un error 404, o redirigirla a otra. No es lo mismo ni de lejos, y elegir mal tiene consecuencias, luego vemos por qué.

¿Le damos una vuelta?

Qué es el archivo de autor y por qué «suele» sobrar

WordPress, además de tus entradas y páginas, genera de forma automática varios archivos, que son listados de contenidos, ya sean por categoría, por etiqueta, por fecha, por autor y alguno más. Hoy vamos a por uno en concreto, el de autor.

El archivo de autor (la URL tudominio.com/author/tunombre/) lista todo lo que ha publicado un usuario. Si en tu web publicas tú solo, ese listado es prácticamente idéntico a la portada del blog, así que tienes dos páginas mostrando lo mismo. En un blog con varios autores la cosa cambia, pero en uno de un solo autor el archivo de autor es un clon de tu blog.

Hasta aquí el consejo de toda la vida, que es correcto, pero el archivo de autor esconde un matiz importante que cada vez tiene más importancia, o debería.

¿Lo dejo, lo desindexo o me lo cargo?

Tienes 3 posibilidades, y conviene saber qué haces con cada uno:

• Dejarlo indexado: No tocas nada, la página tiene su propia URL canónica y Google decide. En el archivo de autor, ya lo verás, muchas veces es justo lo que te interesa.
• Desindexar con noindex, follow: Le pones a la página la etiqueta noindex (que le dice a los bots que no la indexen) junto con follow (pero sigue los enlaces que hay dentro). Es la opción más equilibrada, porque la página desaparece de los resultados pero Google sigue rastreando los enlaces hacia tus entradas. Si desindexas hazlo siempre con follow, nunca con nofollow, que si no le cortas a Google el camino hacia tu contenido.
• Eliminar el archivo: Es lo que hace, por ejemplo, mi viejo artículo sobre eliminar los archivos de categoría, autor y fecha, que los convierte en un 404 con código. Funciona, pero es la opción más bestia, porque matas la página del todo. Yoast tiene una variante más fina para el de autor, que es redirigirlo a la portada o al listado de entradas en lugar de devolver un 404, mejor pero tampoco lo ideal.

Y luego hay 2 cosas que no debes hacer nunca:

1. Bloquear este archivo por robots.txt, porque si bloqueas el rastreo Google no entra a leer la etiqueta noindex y puede acabar indexando la URL igual, con el cartelito de «no hay información disponible para esta página». Lo explico a conciencia en mi artículo sobre cómo evitar que Google indexe los feeds RSS, y aquí se aplica igual.
2. Poner la URL canonical de este archivo apuntando a la portada, porque eso confunde a Google y puede esconderle contenido tuyo.

¿Te acuerdas del E-E-A-T? ¿Qué le pasa si desindexas tu archivo de autor?

Aquí está el detalle que cambia la decisión, y tiene que ver con tu autoridad como autor.

Es cierto que Google ha dicho que no pasa nada por no indexar los archivos de autor, y yo mismo lo recojo en mi guía sobre enumeración de usuarios. Hasta ahí bien, pero el problema no es lo que diga Google, sino dónde tienes montada en la práctica tu identidad de autor.

El E-E-A-T (experiencia, pericia, autoridad y fiabilidad) se apoya mucho en esa identidad, que se construye, entre otras cosas, con datos estructurados, un bloque de código Person que le dice a Google y a las IAs quién eres, con tu nombre, tu bio y tus enlaces a perfiles, el llamado sameAs que conecta tu ficha con tu LinkedIn, tu GitHub, tu Wikidata y demás.

Lo tienes explicado a fondo en mi artículo sobre E-E-A-T en WordPress, y es totalmente obligado asimilar todo lo que expliqué ahí, no es opcional, así que luego lo lees, que entra en el examen.

¿Y dónde se suele poner ese bloque Person completo? Pues justo en el archivo de autor, lo tengo incorporado en ese pedazo de plugin llamado Visibility. En cada entrada el autor del artículo es solo una referencia, un puntero que dice «el autor es esta ficha», mientras que la ficha completa, con el sameAs, la bio y la foto, se emite únicamente en el archivo de autor y, en justicia, la mayoría de plugins de SEO funcionan parecido, no solo el mío.

¿Ves la liada que puedes armar si lo haces mal? Si desindexas el archivo de autor estás escondiendo la única página donde vive tu identidad de autor.

Y la cosa siempre puede ir a peor, porque Google confirmó hace años que una página con noindex permanente acaba tratándose como un soft 404, es decir, deja de rastrearla. Vamos, que ese listado que parecía un simple clon de tu blog resulta ser el ancla de tu E-E-A-T, y lo ibas a tirar a la basura sin saberlo.

El archivo de autor no es solo un listado repetido, en muchas webs es el carné de identidad online de quien escribe. Antes de esconderlo o quitarlo mira bien qué te llevas por delante.

¿Soluciones? Tienes dos limpias, según tu caso.

• Deja el archivo de autor indexado y conviértelo en tu página de autoridad: Ponle una bio de verdad, tus enlaces sociales y tus mejores artículos, y que sea una página que merezca estar en Google. En un blog de un solo autor es, en mi opinión, la opción más sensata.
• Desindexa el de autor solo si llevas tu identidad a otra página indexable: Si tienes una página «Acerca de…» o «Quién soy» con su propio bloque Person y su sameAs, entonces sí puedes esconder el archivo de autor sin perder la señal, porque vive en otro sitio que Google sí indexa.

Lo que no tiene sentido es desindexar el archivo de autor y a la vez pretender cuidar el E-E-A-T. O una cosa o la otra, pero las dos a la vez no cuadran.

¿Me libra esto del peligro de la enumeración de usuarios?

Un malentendido muy habitual, desindexar el archivo de autor no protege tu acceso. Son cosas distintas.

El archivo de autor cuelga de una URL tudominio.com/author/tunombre/, y ese «tunombre» suele ser tu nombre de usuario de WordPress, justo la mitad de lo que necesita un atacante para entrar (le falta la contraseña).

El problema es que el noindex saca esa URL de Google, pero la URL sigue ahí y sigue filtrando tu usuario a quien la pida directamente o sondee el clásico tudominio.com/?author=1. Eso es la enumeración de usuarios, y el noindex no la frena ni de lejos.

Para frenarla de verdad necesitas seguridad, no SEO, y aquí tienes mi guía completa sobre enumeración de usuarios con todos los métodos.

Si quieres taparlo de un plumazo, mi plugin de seguridad Vigilante intercepta los ?author=N para que WordPress no te redirija al /author/usuario/ y filtre el nombre, bloquea la enumeración por la REST API (/wp-json/wp/v2/users) y evita que tu nombre de usuario se muestre en público. Eso es lo que tapa el agujero, el noindex solo lo disimula.

Cómo desindexar los archivos de autor

Si te has decidido por la vía de desindexar tenemos como siempre dos maneras principales, con código si te manejas, o con ajustes si prefieres ir a clics.

Por código

Si quieres desindexar el archivo de autor sin instalar nada, créate un mu-plugin (un plugin que se ejecuta siempre y no se puede desactivar por error desde el escritorio) en la carpeta /wp-content/mu-plugins/ con este contenido:

<?php
/**
 * Plugin Name: Noindex archivos de autor
 * Description: Añade noindex, follow a archivos de autor.
 * Author: Fernando Tellado
 * Author URI: https://tellado.es
 * Version: 1.0
 * Plugin URI: https://ayudawp.com
 */

// Añade noindex, follow a archivos de autor
add_filter( 'wp_robots', 'ayudawp_noindex_author_archives' );

function ayudawp_noindex_author_archives( $robots ) {
// Únicamente los archivos de autor en el HTML generado por WordPress
if ( is_author() ) {
$robots['noindex'] = true;
$robots['follow']  = true;
}
return $robots;
}

Ese código le pone noindex, follow al archivo de autor (funciona desde WordPress 5.7, que es cuando llegó el filtro wp_robots).

Pero recuerda lo que hemos visto, que en un blog de un solo autor mi consejo es justo el contrario, dejarlo indexado, así que usa este código solo si has decidido esconderlo y tienes tu identidad de autor en otra página indexable.

Por ajustes y plugins

Si usas un plugin de SEO lo tienes a un par de clics, y aquí cada uno tiene lo suyo.

• Yoast SEO además de poner el archivo de autor en noindex lo redirige a la portada. Lo tienes en SEO > Apariencia en el buscador > Archivos.
• Rank Math y All in One SEO también te dejan desindexar el archivo de autor desde sus ajustes de apariencia en el buscador.
• Visibility, mi plugin gratuito de SEO nativo, permite aplicar (opcional) el noindex, follow al archivo de autor con una casilla, sin tablas en la base de datos ni código de tu parte.

Te nombro los tres grandes y uno pequeñito (pero matón), que cada uno use el que mejor le venga. Una sola regla de oro, no instales dos plugins de SEO a la vez para esto, porque acabarás con etiquetas duplicadas peleándose en el código.

De nuevo, aún a riesgo de ser pesado, acuérdate del E-E-A-T, si desindexas el de autor asegúrate de que tu ficha de autor vive en una página indexable.

¿Qué recomiendo yo?

Ya sabes que no soy SEO, pero tengo una opinión, que llevo más de 20 años viviendo de Internet, así que me equivoco algunas veces, y también acierto otras. Te dejo mi punto de vista en plan decisión rápida:

• Blog de un solo autor: mi consejo es dejar el archivo de autor indexado y convertirlo en tu página de autoridad, con bio y enlaces sociales. Si prefieres esconderlo, hazlo solo si tu identidad de autor vive en otra página indexable.
• Blog con varios autores: si cada autor tiene su ficha bien currada, déjalos indexados, que suman E-E-A-T. Si son fichas vacías, noindex follow.
• En todos los casos: el noindex no frena la enumeración de usuarios, eso va aparte con un buen plugin de seguridad.

Si te queda alguna duda, o quieres contarme cómo lo tienes montado tú, me tienes ahí abajo en los comentarios, como siempre.

Se llaman ARD y OKF, suenan importantes, y como era de esperar ya empiezan a salir los artículos de turno avisándote de que tienes que implementarlos ya mismo en tu web o te quedas atrás, peroooo…

A ver, tranqui, si tu web es un WordPress de contenido normal, un blog, una web de empresa o una tienda, ahora mismo no tienes que tocar absolutamente nada. Y te lo explico con calma, porque entender qué son estas dos cosas y, sobre todo, qué NO son, te va a ahorrar caer en las prisas de siempre.

Vamos a verlo, sin emocionarnos demasiado y con los datos en la mano.

OKF y ARD: dos estándares que nacen juntos pero ni se tratan

Es raro, pero sí, han salido dos estándares casi a la vez, los dos con olor a Google, y ninguno menciona al otro, como si no supieran que el otro existe, como dos primos cabreados. Y, sin que sirva de precedente, esta vez Joost tiene toda la razón, es justo lo que ha pasado.

Pero como me acabo de dar cuenta de que no te he explicado de qué van aquí va una pequeña explicación:

• OKF (Open Knowledge Format) es una forma de empaquetar una base de conocimiento, un montón de ficheros de texto en formato Markdown con tus contenidos organizados por temas. Pero ojo con el detalle, porque que alguien encuentre ese paquete no es asunto suyo, lo dice la propia especificación. Un OKF montado en tu servidor es, por diseño, invisible.
• ARD (Agentic Resource Discovery) es justo la pieza que le falta al otro, la capa que se encarga de que te encuentren. Publicas un fichero en una ruta fija de tu dominio, /.well-known/ai-catalog.json, donde listas lo que tu web ofrece a los agentes de IA, y desde ahí se puede apuntar incluso a un paquete OKF, o a otra cosa.

O sea, que uno empaqueta y el otro encuentra. Por separado cada uno está cojo, y juntos encajan bien, sea casualidad o no, pero eso no significa que vayas a tener que montar ambas tecnologías, ni de coña.

Las tres capas mezcladas, no agitadas

Para no perderte, quédate con que en todo esto hay tres capas distintas, y el lío viene precisamente de mezclarlas … o agitarlas, ya me he perdido un poco, ustedes me perdonen.

Imagínate tu web como un negocio a pie de calle, tienes un escaparate, que es tu contenido, lo que cualquiera que pasa, persona o bot, puede ver y leer. Detrás puede haber una trastienda con máquinas que hacen cosas, un cajero, una fotocopiadora, lo que sea, y esas serían tus capacidades, funciones que un agente puede activar para que hagan algo por él.

Y luego está la guía de comercios del barrio, donde alguien busca «quién me imprime aquí cerca». ¿Lo has entendido, o me he explicado?, no ¿verdad?, lo pongo con viñetas:

• La capa de contenido (el escaparate): Para las IAs, el cartel de ese escaparate es el llms.txt (un fichero de texto que les dice a los bots qué hay de interesante en tu web y cómo leerlo, una especie de robots.txt pero pensado para inteligencias artificiales).
• La capa de capacidades (la trastienda): El ai-catalog.json de ARD es el listado de máquinas de tu trastienda. Aquí no va tu contenido, van cosas que un agente puede invocar, como un servidor MCP (un conector que le da herramientas a la IA), un agente A2A (agentes que se hablan entre ellos) o una API.
• La capa de descubrimiento (la guía de comercios): Son los registros de ARD, buscadores que rastrean esos catálogos por toda la web y, cuando un agente pregunta «quién sabe hacer X», le devuelven una lista.

¿Ves el problema? Si tu web es solo escaparate, que es el caso de la inmensa mayoría de blogs y webs corporativas, tu listado de máquinas está vacío, no tienes trastienda que enseñar. ¿Y vas a montar el catálogo igualmente?, como verás cuando me ponga la gorra de VigIA, te sale peor que no montarlo.

ARD está bien (pero todavía no toca)

ARD no es un experimento de fin de semana, no es EmDash de Cloudflare. Lo firman Google, Microsoft y Hugging Face, está construido sobre el modelo de datos AI Catalog del grupo de trabajo de la Linux Foundation, y detrás andan nada menos que Amazon, GitHub, Salesforce, Snowflake, Nvidia o Cisco.

GitHub ya lo ha metido en Copilot (te recuerdo que ambos son Microsoft) con su Agent Finder, y Hugging Face tiene su propia implementación funcionando. Cuando se junta gente así lo normal es que la cosa acabe siendo el estándar para esto.

Y además es que resuelve un problema real, el de que un agente encuentre la herramienta adecuada entre las miles que va a haber repartidas por mil empresas distintas. Eso es ya un problema en el mundo de las grandes integraciones.

Ahora bien, dos matices, así para nosotros:

• Esto es la capa de capacidades, no la de contenido: Cuando leas por ahí que publicar el ai-catalog.json «pasa a ser lo mínimo exigible», ojo, eso es para quien ofrece capacidades en ese mundo empresarial, no para el blog de recetas ni para la web del fontanero del barrio. Tu WordPress de contenido no tiene nada que catalogar ahí.
• Es una versión 0.9, un borrador que todavía se va a mover: Y no es que pueda cambiar en el futuro, es que ya se contradice consigo misma hoy. La especificación base llama a un campo mediaType y la capa de ARD lo llama type, para exactamente lo mismo. Cuando ni los que la escriben se ponen de acuerdo en cómo se llaman las cosas, montar eso a ciegas en tu web es querer jugar un partido que aún no tiene ni equipos, ni campo, ni fecha.

OKF igual hasta sobra

Y OKF, ¿qué pinta en tu WordPress?, pues todavía menos.

OKF va de empaquetar tu base de conocimiento en ficheros Markdown para que la IA la consuma, suena bien, pero…

1. Está más verde aún que ARD, hasta el punto de que ni siquiera existe un tipo de fichero registrado para un paquete OKF. Cada cual se inventará el suyo y no habrá manera de que coincidan.
2. Lo de «dale a la IA todo mi contenido en bruto» ya está cubierto, y con una convención mucho más extendida, que es elllms-full.txt (la versión del llms.txt que vuelca el contenido completo, no solo el índice). Si ya generas ese fichero adoptar OKF sería cambiar algo que funciona y que todo el mundo entiende (aunque lo lean pocos) por algo más inmaduro que nadie lee, para tapar una necesidad que ya tenías tapada. No le veo el sentido, sinceramente.

¿Tenemos que hacer algo?

Te lo resumo en lo que sí merece tu atención y lo que puedes ignorar tranquilamente.

• Cuida tu llms.txt: Esta es la capa que de verdad te toca como web de contenido, y la que puede que ayude a que las IAs te lean y te citen bien. Si aún no lo tienes, igual es el momento de hacerlo, cuesta cero añadirlo (con VigIA menos que cero), no en ARD ni en OKF.
• No generes un ai-catalog.json «porque sí»: Si tu web no expone capacidades reales déjalo estar. Un fichero vacío en /.well-known/ no te suma nada, y encima esa ruta es delicada, que ahí viven cosas como la validación de los certificados SSL y lo que toquen otros plugins.
• Vigila quién empieza a llamar a tu puerta: Esto sí que puede ser interesante de verdad. A medida que ARD se extienda van a empezar a aparecer por tu web rastreadores nuevos, los de esos registros, pegando a tu /.well-known/ para ver si tienes catálogo. Saber quién te rastrea y para qué siempre ha sido la mejor brújula en todo este lío de la IA, mucho mejor que correr detrás de cada estándar que sale.

¿Y VigIA? ¡¡Una solución queremos!!

Déjame ponerme la gorra de VigIA un momento, que para algo es mi plugin de visibilidad para IA. Lo fácil, lo que vas a leer por todas partes en cuanto ARD coja algo de impulso, es que montes tú también tu catálogo en /.well-known/ai-catalog.json.

Y oye, tiene su lógica, porque la idea de que un agente descubra solo lo que tu web ofrece es buena, y porque generar ese fichero es de lo más sencillo, y además VigIA ya se sabe todas tus URLs.

Pues precisamente por eso no lo voy a hacer (todavía), generar el fichero es lo barato, ser el responsable de que esté bien en miles de webs, para siempre, es lo caro.

Estamos hablando de una norma que está en pañales (versión 0.9) y que se contradice a sí misma, pues hay un campo que en un sitio se llama de una manera y en otro de otra, y ni siquiera está registrada la etiqueta que dice qué clase de archivo es esto.

El día que arreglen ese lío, la mudanza de todas esas webs no la hace quien escribió la norma, la hago yo, mientras no, gracias.

Y hay un error más de fondo, que es el más importante, el hecho de que un catálogo ARD es la carta de un restaurante, lista lo que puedes pedir, no lo que hay en la despensa. O sea, lista capacidades, cosas que un agente llama para que pase algo, pero tiene que haber ese «algo».

De todo lo que hace VigIA, eso solo lo es el servidor MCP. El llms.txt y los .md para agentes son la despensa, o sea, contenido para leer, no platos que pedir.

Si los metes en la carta, te toca inventarte una etiqueta de archivo que no existe en ningún registro. Y si no los metes, en una web normal y corriente, de puro contenido, el catálogo se te queda casi vacío, y un catálogo vacío es peor que no tener ninguno, porque le pones al agente un cartel de «mírame» pero luego resulta que no hay nada.

Así que lo que voy a hacer con VigIA es lo contrario de fabricarte el fichero, medirlo. El analizador de visibilidad mirará si tu web (o la del vecino, para el caso) publica un ai-catalog.json válido y qué expone, y te lo dirá. Sin escribir una sola línea en el .well-known de nadie, que para colmo es un cajón compartido donde ya andan metiendo mano el certificado SSL y medio plugin de seguridad.

¿Que el día de mañana esto cuaja de verdad, con la norma cerrada y algún agente leyéndola de verdad? Pues entonces VigIA podrá generarlo, faltaría más, pero como una opción que activas tú a conciencia y solo con lo que de verdad es una capacidad, sin colarte el contenido por el medio.

Mientras tanto, prefiero un VigIA que te dice la verdad sobre tu web a uno que te llena el disco de ficheros que no lee nadie. Tú verás lo que te encaja, pero esa es mi apuesta y te la cuento tal cual.

Cuándo sí tendrán sentido OKF y ARD en WordPress

Y para que veas que no te digo «pasa de esto para siempre», te lo concreto. ¿Cuándo deja tu WordPress de ser solo escaparate y tiene una trastienda de verdad que catalogar?

Pues cuando expongas capacidades reales, y en WordPress eso es tener un endpoint MCP, o sacar tu REST API o la nueva Abilities API (la que permite registrar capacidades (abilities) que un agente puede usar) como herramientas para agentes. Ese día tu trastienda deja de estar vacía y la conversación cambia.

Hasta entonces, lo dicho.

Mi opinión, por si te sirve

En toda esta ola de la IA, en la que yo soy ya surfista apasionado, casi profesional, el que gana no es el que corre a montar cada estándar el día que sale, es el que entiende qué capa le afecta y pone el esfuerzo donde pasan cosas de verdad que puedes aplicar.

Para tu web de contenido, esa capa hoy es el contenido y vigilar quién te lo rastrea, no canales para agentes que todavía no te visitan.

Así que ya tienes los datos y un poco de mi visión, lo que hagas con tu web, como siempre, lo decides tú. Si quieres seguir el hilo, tengo más cosas escritas sobre IA y WordPress donde seguro que aprendes algo. Y si quieres debatirlo, o contarme que tú lo ves de otra manera, me tienes ahí abajo, en la sección de comentarios.