La Secrets API (API de secretos, si lo prefieres en cristiano) llega con WordPress 7.2, que sale el 8 de diciembre de 2026, y en el directo te conté qué hace, qué no hace y qué te conviene ir preparando ya.

Una caja fuerte para claves, tokens y contraseñas

A ver, el problema de partida es viejo. Los plugins que se conectan a servicios externos (pasarelas de pago, servicios de correo, APIs de IA y compañía) guardan sus claves de API, tokens y contraseñas en la base de datos, y hasta ahora esas claves quedaban ahí a la vista, en texto plano.

Con la Secrets API, WordPress trae una especie de caja fuerte para que los plugins guarden esos datos cifrados. Si alguien se lleva una copia de tu base de datos, solo verá texto cifrado que no le sirve de nada. Y teniendo en cuenta la cantidad de copias de seguridad olvidadas y volcados SQL que andan por ahí sueltos, eso ya es mucho.

Ahora bien, no es magia y conviene no venirse arriba. No te protege de un plugin malicioso, que se ejecuta dentro de tu WordPress y puede leer lo mismo que lee cualquier otro plugin, ni de quien consiga a la vez la base de datos y el archivo wp-config.php. Es una capa más, de las buenas, pero una capa.

La clave WP_SECRETS_KEY: se pone una vez y no se toca

Todo el invento descansa en una constante, WP_SECRETS_KEY, que va en el archivo wp-config.php, fuera de la base de datos. La idea es sencilla: que quien robe una cosa no tenga también la otra, como quien guarda la llave de la caja fuerte en otra habitación (y no pegada con celo debajo de la caja).

Y ojo con esto, que es lo más importante del directo: esa clave se pone una vez y no se cambia nunca. Si la cambias o la pierdes, los secretos guardados no se pueden leer y tampoco se puede guardar nada nuevo. ¿La solución si ya la has liado?, pues volver a poner el valor anterior. Así que apúntala bien y no la regeneres alegremente como harías con las claves de seguridad de toda la vida.

Qué cambia para los plugins

Si te estás preguntando si ahora cada plugin te va a llenar el wp-config.php de constantes, pues no. En wp-config.php solo va WP_SECRETS_KEY, una por web, y los plugins guardan sus claves cifradas en la base de datos, en filas con el prefijo _wp_secret_.

Lo que no te voy a vender es que esto vaya a cambiar las cosas de un día para otro. Los plugins se irán adaptando poco a poco, y para que te hagas una idea, en la 7.2 ni siquiera los Conectores de IA de WordPress usan todavía la API.

Además, la 7.2 no trae pantalla para gestionar secretos (según la propuesta, llegará en la 7.3). Lo único que vas a ver está en Herramientas > Salud del sitio, y los valores no se muestran en ninguna parte, que es justo lo que se espera de una caja fuerte.

¿Tengo que hacer algo ya?

Mi recomendación es que sí, que conviene añadir la constante ya. Sin ella, un plugin bien hecho seguirá guardando sus claves como hasta ahora, pero uno mal hecho puede fallar al guardar, y no te apetece descubrirlo justo cuando tu pasarela de pago deja de funcionar.

Tienes toda la información detallada en la guía que he publicado aquí: Secrets API de WordPress.

Vídeo completo del #DoctorWordPress del 11 de noviembre

Aquí tienes el directo entero, con la explicación de la Secrets API:

Ver el #DoctorWordPress del 11 de noviembre de 2026 en YouTube

Nos vemos en el próximo directo

Te recuerdo que hago directo dos veces por semana, los lunes las #CrónicasWordPress con la actualidad, la opinión y el debate, y los miércoles el #DoctorWordPress con un truco y vuestras preguntas, a partir de las 19:30, hora española.

Si quieres asistir en directo y participar con tus preguntas, suscríbete al canal de Ayuda WordPress en YouTube. Y si tienes tema para la próxima crónica o una duda para el doctor, me tienes ahí abajo, en los comentarios.

Para las paradas cortas, Google documenta devolver un 503 y, si se sabe cuánto va a durar, añadir la cabecera Retry-After. Lo que he hecho ha sido instalar nueve plugins de mantenimiento en un WordPress y medir la respuesta de siete, además de la del propio núcleo. Con el modo de mantenimiento de cada uno activado, cinco devuelven 503 en la portada, uno solo lo hace si se marca una casilla que viene desactivada y otro responde 200.

¿Quieres ver los detalles para así aprender algo por el camino?

Qué pide Google y durante cuánto tiempo

En la guía para reducir la frecuencia de rastreo Google indica que, para una reducción urgente y breve (un par de horas o uno o dos días), el servidor puede responder con un 500, un 503 o un 429 en lugar de un 200. Con 503 y 429 admite también la cabecera Retry-After, que puede llevar un número de segundos (por ejemplo, Retry-After: 120) o una fecha y hora en UTC.

La página sobre pausar o inhabilitar temporalmente un sitio web recoge las prácticas para el caso de cerrar el sitio entero: una página informativa con un 503 en lugar del contenido, la mejor estimación de fecha o duración en Retry-After, HTML estático y una comprobación local con curl. También pide que el robots.txt siga permitiendo el rastreo y que no devuelva un 503, porque eso impediría todo el rastreo.

Son respuestas pensadas para periodos cortos. Google desaconseja mantenerlas más de uno o dos días y avisa de que, si Googlebot las observa en la misma URL durante varios días, esa URL puede salir del índice. Para un cierre de unas semanas, la propia página advierte de que Google puede tener problemas para indexar el sitio y recomienda limitar sus funciones en lugar de cerrarlo.

Qué hace WordPress por su cuenta nosotros

Durante las actualizaciones, WordPress crea un archivo .maintenance en la raíz del sitio y, mientras exista, responde con un 503 y Retry-After: 600. En la instalación de pruebas (WordPress 7.1.4) la respuesta incluyó las cabeceras de no caché, llegó a /, /wp-login.php, /wp-json/, /feed/ y /robots.txt, y bloqueó también a los administradores.

Según el código de wp_is_maintenance_mode(), el modo se da por terminado cuando la marca de tiempo del archivo tiene más de diez minutos. Eso ocurre con el número fijo que escribe WordPress. Si alguien crea el archivo a mano con $upgrading = time();, la condición no llega a cumplirse nunca y el 503 se mantiene hasta que se borra.

Hay una excepción que cambia el resultado, y es que si existe el archivo wp-content/maintenance.php WordPress lo carga y termina la ejecución sin enviar por su cuenta ningún código de estado ni cabecera.

En mis pruebas, con ese archivo presente y el .maintenance activo, la respuesta fue un 200 sin Retry-After y sin cabeceras de caché, así que quien utilice una página de mantenimiento propia por esta vía tiene que enviar él mismo el 503 y el Retry-After desde el archivo.

Qué devuelve cada plugin

Las pruebas está hechas en una instalación local con WordPress 7.1.4, Apache, PHP 8.5 y unos treinta plugins activos. Cada plugin se activó y se configuró desde su interfaz, con los ajustes por defecto salvo lo indicado, y las respuestas se pidieron como visitante anónimo, sin cookies y sin caché.

Minimal Coming Soon & Maintenance Mode y Under Construction & Maintenance Mode (distinto del Under Construction de la tabla) se instalaron, pero no se midieron.

• Tres configuraciones responden 200 en la portada: Maintenance con sus ajustes por defecto (el 503 es una casilla opcional), Under Construction y el modo «Coming Soon» de CMP, que es el que trae activado por defecto.
• Slim Maintenance Mode devuelve 503 en todas las URL medidas, pero sin la cabecera Retry-After.
• Under Construction envía Retry-After: 86400 acompañando a un 200, una combinación que Google no documenta (en su guía la cabecera figura con 503 y 429). Además responde 200 en una URL que no existe y no envía cabeceras de no caché en la portada.
• Con la portada en 503, Maintenance deja el feed y el mapa del sitio en 200, y LightStart y el modo Maintenance de CMP dejan el feed en 200. WP Maintenance, Slim y SeedProd responden 503 en las cuatro URL.
• En todos los casos, /wp-login.php y /robots.txt respondieron 200. La situación del robots.txt se comenta más abajo.

El 200 es lo esperable en una página de «próximamente» de un sitio sin publicar. Para una parada de mantenimiento de un sitio ya publicado, la documentación de Google apunta al 503.

Cómo comprobar la respuesta de tu sitio

La medición tiene que hacerse sin sesión iniciada y con una petición GET. curl -I envía una petición HEAD, y con algunos plugins el resultado cambia. Maintenance, con la casilla del 503 marcada, respondió 200 a HEAD y 503 a GET en la misma URL, porque muestra su aviso mediante el filtro template_include y WordPress corta las peticiones HEAD antes de llegar a él.

El ejemplo de la documentación de Google usa curl -I -X GET, que sí envía un GET (se comprobó contra un servidor local) y descarta el cuerpo de la respuesta.

Una forma equivalente, que imprime las cabeceras de una petición GET y descarta el cuerpo, es esta:

curl -sS -D - -o /dev/null https://tudominio.com/

Para repasar de una vez las URL que más se olvidan:

for u in / /esta-url-no-existe/ /feed/ /wp-sitemap.xml /robots.txt; do
  echo "== $u"
  curl -sS -D - -o /dev/null "https://tudominio.com$u" | grep -i -E '^(HTTP|retry-after|cache-control)'
done

En la salida deben aparecer la línea de estado (503 en las URL públicas y 200 en /robots.txt) y, si se ha configurado, la cabecera Retry-After.

Un código para responder 503 sin plugins

Para una parada corta, este mu-plugin responde 503 con Retry-After a los visitantes que no son administradores y se activa o desactiva con una constante. Las pruebas se hicieron con las constantes definidas antes de la carga de los mu-plugins, lo que equivale a definirlas en el wp-config.php. Se guarda como wp-content/mu-plugins/ayudawp-maintenance-503.php.

<?php
/**
 * Plugin Name: 503 Retry-After
 * Plugin URI: https://plugins.ayudawp.com/
 * Description: Sirve un 503 con Retry-After a los visitantes mientras el sitio está en mantenimiento
 * Version: 1.0
 * Author: Fernando Tellado
 * Author URI: https://ayudawp.com/
 * License: GPLv2 or later
 * License URI: https://www.gnu.org/licenses/gpl-2.0.html
 * 
 */
 
/** 
 * Actívalo añadiendo esto en wp-config.php:
 *     define( 'AYUDAWP_MAINTENANCE', true );
 * Opcional: dile a los rastreadores cuándo esperas volver (marca temporal Unix):
 *     define( 'AYUDAWP_MAINTENANCE_UNTIL', strtotime( '2026-11-12 09:00:00 Europe/Madrid' ) );
 */

add_action( 'template_redirect', 'ayudawp_maintenance_503', 0 );

/**
 * Enviar un 503 con Retry-After a los visitantes que no sean admin
 *
 * @return void
 */
function ayudawp_maintenance_503() {
if ( ! defined( 'AYUDAWP_MAINTENANCE' ) || ! AYUDAWP_MAINTENANCE ) {
return;
}

// Permitir que los administradores naveguen por el sitio mientras está en mantenimiento
if ( current_user_can( 'manage_options' ) ) {
return;
}

// Segundos hasta el final esperado, o una hora por defecto (mínimo 60)
$retry_after = 3600;
if ( defined( 'AYUDAWP_MAINTENANCE_UNTIL' ) ) {
$retry_after = max( 60, (int) AYUDAWP_MAINTENANCE_UNTIL - time() );
}

nocache_headers();
header( 'Retry-After: ' . $retry_after );

wp_die(
'<p>Estamos haciendo tareas de mantenimiento. Volvemos en breve.</p>',
'Mantenimiento',
array( 'response' => 503 )
);
}

Con el código instalado salía esto:

• Sin la constante, o con ella en false, el sitio funciona con normalidad.
• Con la constante activada, la portada, una URL inexistente, el feed y /wp-sitemap.xml respondieron 503 con Retry-After y cabeceras de no caché. Las peticiones HEAD recibieron lo mismo.
• Con AYUDAWP_MAINTENANCE_UNTIL definida, el valor de Retry-After se recalcula en cada petición (con un fin previsto dentro de 30 minutos devolvió 1796) y nunca baja de 60. Con una fecha ya pasada devolvió 60.
• Un admin con sesión iniciada ve el sitio normal.
• Siguieron respondiendo como siempre /wp-login.php, /wp-cron.php, admin-ajax.php, xmlrpc.php y los archivos estáticos, porque el gancho template_redirect solo actúa sobre las páginas públicas.

El robots.txt merece una comprobación aparte. Con el código activo siguió respondiendo 200 en la instalación de pruebas, pero en template-loader.php de WordPress el gancho template_redirect se ejecuta antes de resolver el robots.txt virtual, por lo que en un sitio donde lo genere WordPress el código también le daría un 503, que es justo lo que Google pide evitar.

Para excluirlo se puede añadir esta condición al principio de la función. No se pudo probar en la instalación de pruebas, así que conviene verificar la respuesta con la orden de la sección anterior:

if ( is_robots() ) {
	return;
}

La caché de página puede impedir que el 503 llegue

Un plugin de caché con la portada ya almacenada puede servir la copia con un 200 antes de que WordPress ejecute ningún gancho. En la prueba con WP Super Cache en modo simple y la caché caliente, el código no alcanzó a la portada, que siguió respondiendo 200 desde la caché, y solo una URL que no estaba en caché devolvió el 503.

Tras vaciar la caché, el 503 con Retry-After se sirvió en tres peticiones seguidas y el plugin no lo almacenó. Al desactivar el modo, la portada volvió a responder 200 sin ningún 503 residual.

El .maintenance del núcleo, en cambio, se evalúa antes de cargar advanced-cache.php y devolvió el 503 con Retry-After: 600 aunque la caché estuviera caliente. En la práctica, conviene vaciar la caché de página al activar el modo y comprobar la portada al desactivarlo. Con otros plugins de caché, caché de servidor o CDN el comportamiento no se probó.

Qué no he comprobado

Son pruebas a mi manera, intensitas, pero el mundo es grande y hay cosas a donde ni llego ni llegaré, y que debes saber.

• Es una sola instalación, con unos treinta plugins activos y las versiones indicadas en la tabla, muy top, muy exhaustivo, pero otro entorno u otra versión de un plugin pueden dar resultados distintos.
• Recuerda que hay plugins instalados pero no medidos (Minimal Coming Soon & Maintenance Mode y Under Construction & Maintenance Mode), el modo «próximamente» de SeedProd, los modos de mantenimiento de Elementor y de WooCommerce («Coming soon») y los que incorporan algunos hostings.
• La API REST bajo el código personalizado: en esa instalación /wp-json/ ya respondía 401 a los visitantes anónimos antes de tocar nada, así que el resultado no permite concluir.
• Los avisos de las pasarelas de pago de WooCommerce (wc-api), un CDN delante del sitio y las reglas en Apache o nginx. No me da la vida, pero lo pruebas y me cuentas.

Qué opción conviene según la duración de la parada de la web

Por si tienes un poco de lío, tras todo lo visto esto es lo que he aprendido sobre qué usar según el tiempo que vaya a durar el parón de la web:

• Unos minutos: el .maintenance del núcleo, que caduca solo a los diez minutos si contiene una marca de tiempo fija y no depende de ningún plugin.
• De una hora a uno o dos días: el código anterior o uno de los plugins de la tabla que, con la configuración elegida, devuelva 503 con Retry-After, revisando antes el feed, el mapa del sitio y el robots.txt.
• Más de dos días: Google recomienda limitar las funciones del sitio en lugar de cerrarlo.

Es mi opinión, no lo tomes como una regla, te puede servir de referencia, pero sobre todo analiza todo lo visto en el artículo, revisa las pruebas que hice, porque cada caso es diferente. Y por supuesto, podemos charlar lo que quieras ahí abajo en los comentarios.

Y luego, hay alternativas que tienen sentido en situaciones concretas, como trabajar desde claude.ai o ChatGPT en el navegador, gestionar varias webs desde una misma cuenta o desarrollar en local, además de otras que no conviene usar en producción.

Este artículo no explica qué es MCP ni cómo se instala el Adapter, temas que se tratan en la guía de MCP en WordPress, lo que hago aquí es comparar las opciones disponibles actualmente, a partir de pruebas realizadas en una instalación local y en una web pública de pruebas, con usuarios creados a propósito, contraseñas de aplicación y conexiones reales desde Claude.

¿Te animas? Yo he aprendido mucho por el camino, y aquí te lo cuento todo.

Criterios para elegir servidor MCP en WordPress

Las opciones disponibles no hacen lo mismo, así que conviene tener claros cuatro factores antes de compararlos:

• Cliente: Claude Desktop, Claude Code, Cursor o VS Code pueden conectar con métodos que no admiten claude.ai ni ChatGPT en el navegador. Estos últimos necesitan OAuth, lo que hoy impide conectar directamente el MCP Adapter.
• Intermediarios: en algunas opciones el cliente se comunica directamente con la web y en otras todo pasa por los servidores de un tercero, que en algún caso guarda las credenciales.
• Tipo de web: en una web local o de pruebas se pueden permitir cosas que en producción supondrían un riesgo, como que la IA ejecute PHP.
• Plugins instalados: si los plugins de la web registran abilities (WooCommerce, VigIA, Visibility, Jetpack, Elementor y otros), lo que puede hacer el agente depende mucho de la opción elegida, porque no todas acceden a ellas.

Comparativa rápida de servidores MCP para WordPress

En las webs locales el «sí» se refiere a clientes que se ejecutan en el mismo ordenador (Claude Desktop, Claude Code, Cursor, VS Code…), ya que claude.ai o ChatGPT en el navegador no llegan a una web que no está publicada en internet. AI Engine no aparece en la tabla porque no se ha probado a fondo, y ya lo trato más adelante con los datos que ellos mismos dan.

MCP Adapter con abilities, la vía oficial

El MCP Adapter es parte del proyecto AI Building Blocks, y el puente oficial entre las abilities de WordPress y cualquier cliente MCP. WordPress.org lo publica actualmente como plugin canónico, tras pasar un periodo de crecimiento en GitHub, y a día de hoy supera las 60.000 instalaciones activas.

Por sí solo hace poco, porque su función es exponer lo que registran el núcleo y los plugins a través de la Abilities API. Por eso las comparativas que lo evalúan como una herramienta completa le dan puntuaciones muy bajas, algo que me parece realmente injusto, por su enorme importancia, y casi me hace pensar que hay gente que hace reseñas sin saber qué tiene entre manos. Pero seguimos…

Resultado de mis pruebas

En la instalación local, con 28 plugins activos y ningún otro servidor MCP, se activó únicamente el Adapter. El servidor por defecto (/wp-json/mcp/mcp-adapter-default-server) pasó a exponer 25 abilities (3 del núcleo, 9 de VigIA, 6 de Visibility y 7 de WooCommerce).

Entre las 7 de WooCommerce están borrar productos, actualizarlos y cambiar el estado de los pedidos. Aparecen aunque la casilla experimental de WooCommerce MCP esté desactivada, porque WooCommerce registra sus abilities siempre y las marca como públicas para MCP. En la práctica, al activar el Adapter queda disponible por MCP todo lo que los plugins marcan como público, sin aprobación individual.

Los permisos se comprueban en el momento de la ejecución. Con un usuario editor y su contraseña de aplicación, el descubrimiento mostraba las 25 abilities, pero las de VigIA, las de WooCommerce y la consulta del estado SEO de Visibility devolvían «Permission denied».

Sí funcionaban la búsqueda de contenido sin metadatos SEO y la consulta del propio perfil. El catálogo muestra todo lo público y cada usuario solo ejecuta lo que permiten sus capacidades de WordPress, de ahí la importancia del usuario con el que se conecta.

Servidor por defecto y servidores dedicados

El servidor por defecto no presenta cada ability como una herramienta independiente, sino tres herramientas genéricas (descubrir abilities, consultar su información y ejecutarlas). Para un cliente como Claude eso equivale a una sola herramienta de ejecución, de modo que el permiso que solicita cubre cualquier ability, sea de lectura o de borrado.

El servidor dedicado de VigIA (/wp-json/vigia/v1/mcp), que el plugin registra a través del MCP Adapter oficial y que solo existe con el Adapter activo, ofrece 9 herramientas directas con sus anotaciones (5 de solo lectura y 2 destructivas), exige permisos de administrador desde la conexión (el editor de pruebas recibió un 403) y se desactiva sin afectar al resto. Con herramientas individuales y anotadas el cliente puede pedir permiso de forma selectiva, y el agente elige mejor dentro de un catálogo reducido.

El servidor por defecto tiene a su favor que basta con una conexión por web, una sola contraseña de aplicación y menos configuración en cada cliente, que es el modelo que persigue el plan para la 7.3. VigIA combina los dos enfoques, ya que sus abilities aparecen en el servidor por defecto y además registra su servidor dedicado en el mismo Adapter.

Limitaciones

• Versión 0.x: la 0.7.0 (2 de octubre de 2026) dejó de admitir revisiones antiguas del protocolo y declaró obsoleto empaquetar el Adapter dentro de otros plugins, algo que varios siguen haciendo (VigIA, por ejemplo, dejó de incluirlo en la versión 2.8.0). Tengo prevista una versión 1.0 estable en torno al 8 de diciembre, junto a WordPress 7.2, aunque su alcance y su fecha siguen en discusión.
• Contraseñas de aplicación: en remoto la autenticación se hace con ellas, y no caducan hasta que se revocan.
• Sin OAuth: no se puede conectar directamente desde claude.ai ni desde ChatGPT en el navegador, solo desde clientes de escritorio o de terminal (la guía de MCP explica cómo hacerlo con cada uno).
• Abilities del núcleo de solo lectura: WordPress 6.9 incluye tres de información (sitio, usuario y entorno), y la 7.2 añade consultas de ajustes, usuarios y contenido (ya incluidas en las betas), también de solo lectura. Las de escritura llegarán más adelante.

Planes MCP para WordPress 7.x

Ya está confirmado que el MCP Adapter no entra en el núcleo con WordPress 7.2, que se publica el 8 de diciembre de 2026, y que el equipo de IA apunta a la 7.3. Llegó a plantearse una excepción para incluirlo en la 7.2, pero sigue como plugin. Que la 7.3 sea el objetivo no significa que esté decidido, y conviene matizarlo.

El 28 de octubre de 2026, Jason Adams (Automattic, representante del equipo de IA) publicó la propuesta WordPress for the Agentic Web, con cuatro líneas de trabajo (el Adapter, abilities base, OAuth y la experiencia de conexión). La 7.2 se dedica a preparar lo necesario y la 7.3 es el objetivo.

Para MCP en el núcleo la propuesta contempla dos vías, la fusión directa o una inclusión que permita al Adapter evolucionar por separado, así que no está decidido que entre tal cual. OAuth se diseñaría en la 7.2 y se incorporaría al núcleo en la 7.3, y el documento califica las contraseñas de aplicación como «not a scalable approach». La inclusión queda condicionada a la madurez técnica, a la seguridad y al proceso habitual de revisión del núcleo..

También hay posturas en contra. En la propuesta de fusión del cliente de IA para la 7.0 el equipo mantenía el Adapter como plugin canónico de forma deliberada. Lo único confirmado es que MCP no entra en la 7.2. Para la 7.3 hay intención, pero ni la inclusión ni el formato están cerrados.

MCP de WordPress.com con Jetpack

No existe un servidor MCP específico de Jetpack. El servidor es el MCP de WordPress.com, alojado por Automattic, y Jetpack conecta con él las webs autoalojadas, de forma que una sola conexión da acceso a todas las webs de la cuenta.

Muchas guías indican que requiere Jetpack AI o un plan de pago, pero la documentación de Jetpack, actualizada el 22 de octubre de 2026, pide un plan Jetpack AI o Jetpack Complete, aunque hasta el 30 de noviembre de 2026 también funciona con el plan gratuito.

La identificación usa OAuth 2.1 con PKCE (un método de autorización que no requiere entregar la contraseña), permite elegir entre acceso completo o solo lectura al conectar y se revoca desde las aplicaciones conectadas de la cuenta de WordPress.com. El acceso MCP está desactivado por defecto, se eligen las herramientas de lectura y de escritura permitidas y queda un registro de actividad.

La conexión desde Claude con la web pública de pruebas funcionó sin incidencias, con dos resultados relevantes:

• Sin acceso a las abilities: el catálogo es fijo (contenido, ajustes, estadísticas, registro de actividad, copias de seguridad, plugins, temas, usuarios, edición del sitio, dominios…) y no incluye ninguna operación para usar abilities. Las de VigIA y Visibility no aparecen, y como mucho se podría modificar algún metadato registrado en la API REST al editar una entrada.
• Acceso a todas las webs de la cuenta: además de la web de pruebas, el conector mostraba otras webs de la misma cuenta con el acceso MCP disponible. Conviene revisar en cuáles está activado antes de conectar.

En cuestiones de seguridad, las escrituras exigen confirmación explícita, los borrados de entradas, páginas y comentarios van a la papelera, y los de medios, términos y menús son definitivos, con aviso previo. La herramienta de lectura de respuestas de formularios aparece desactivada y reservada a empleados de Automattic. Según WordPress.com, los datos de las herramientas no se usan para entrenar modelos.

Sus limitaciones son que no funciona con webs locales (Jetpack las detecta y no se conecta) y que todo pasa por la infraestructura y la cuenta de WordPress.com. Es la opción más sencilla y mejor resuelta para quien ya usa Jetpack y trabaja desde claude.ai o ChatGPT en el navegador. Para quien no lo usa supone instalar un plugin de gran tamaño para una única función.

WPVibe

WPVibe es un plugin de SeedProd, empresa del grupo Awesome Motive (el mismo que gestiona WPBeginner, que lo sitúa en primer lugar en su comparativa), con más de 100.000 instalaciones activas. Funciona como intermediario, ya que el cliente de IA se comunica con el servicio de WPVibe y este reenvía las peticiones a la API REST de la web.

Para ello la contraseña de aplicación que se crea al conectar se guarda cifrada en servidores de WPVibe en Cloudflare. La página del plugin afirma en sus preguntas frecuentes que no se envían datos a terceros, mientras que su sección de servicios externos describe ese intermediario. Creo que deberían adaptar los textos ¿no?

La conexión se inicia desde el cliente de IA, que genera un enlace para aprobarla en la web. Estos son los resultados de la prueba:

• Usuario: actúa como el usuario que aprueba la conexión. Si es un administrador, el agente tiene permisos de administrador, por lo que es preferible aprobarla con un usuario dedicado.
• Abilities: detectó 53 (núcleo, VigIA, Visibility, formularios de Jetpack, el plugin AI oficial y otras), porque las obtiene de la API REST de abilities del núcleo y no del Adapter. Las de VigIA y Visibility funcionaron sin configuración adicional. Las de WooCommerce no aparecían, por causas que no se han determinado.
• Cuota: el plan gratuito permite 300 llamadas cada 24 horas y cuenta cada herramienta usada (algunas reseñas mencionan 100, una cifra que parece desfasada).
• Latencia: una consulta sencilla tardó 1.277 ms, de los que 4 correspondían a PHP en la web y el resto al trayecto por el intermediario.

Según la descripción de su herramienta de ejecución de abilities, WPVibe solo pide aprobación para las abilities marcadas como destructivas. Las escrituras sin esa anotación se ejecutan directamente, lo que en la web de pruebas incluía bloquear un rastreador o añadir una regla al robots.txt con VigIA y modificar el SEO de una entrada con Visibility.

La protección depende, por tanto, de cómo anote cada plugin sus abilities.

WPVibe es la vía más rápida para conectar una web autoalojada desde claude.ai o ChatGPT en el navegador y, a diferencia del MCP de WordPress.com, accede a las abilities. Como contrapartida, credenciales y peticiones pasan por un tercero que se convierte en punto único de fallo, el uso está limitado por cuota y no sirve para webs locales.

Plugins con servidor MCP propio: Royal MCP, Easy MCP AI y AI Engine

A diferencia de los servidores dedicados que se registran en el MCP Adapter, estos plugins implementan su propio servidor MCP, con OAuth propio y cientos de herramientas. Permiten conectar desde claude.ai o ChatGPT en el navegador sin intermediarios y sin esperar a que el núcleo incluya abilities de escritura.

Como contrapartida, añaden mucho código y un OAuth desarrollado por cada plugin, que es el área donde se han concentrado las vulnerabilidades más recientes (ver la sección siguiente).

Royal MCP

Royal MCP (más de 10.000 instalaciones) viene desactivado por defecto. Al activarlo añade 14 rutas a la API REST, y en la prueba listó 270 herramientas, 107 de ellas marcadas como destructivas. Incluye modos de solo lectura y de solo borradores, registro de actividad, límites de peticiones, simulación previa y opción de deshacer durante 72 horas.

Aspectos a tener en cuenta:

• Modo de solo lectura: no oculta herramientas, sino que las sigue listando y las rechaza al ejecutarlas («This site is in read-only mode»).
• Aprobación de clientes nuevos: la opción que exige aprobar cada cliente de IA nuevo está desactivada por defecto, aunque solo pueden conectar administradores.
• API REST restringida: Royal valida su clave dentro de su propia ruta, por lo que deja de funcionar si un plugin de seguridad bloquea la API REST a peticiones no autenticadas. Con Vigilante en ese modo devolvía un 401 con una clave válida.
• Versión Pro: el escritorio anuncia «Royal MCP Pro & Royally starts at just $9/month», mientras que la página oficial del plugin en WordPress.org dice que «There is no Pro version».

En la 1.5.10 se corrigieron dos vulnerabilidades (una permitía a un suscriptor leer contenido no público), y las versiones posteriores han incluido más correcciones.

Easy MCP AI

Easy MCP AI (más de 30.000 instalaciones) es de Themeisle, que lo sitúa en primer lugar en su propia comparativa. Anuncia más de 280 herramientas, con integraciones de Google Analytics, Search Console, Semrush, Ahrefs y otros servicios, autenticación por OAuth 2.1 o tokens propios, y consume abilities de otros plugins si se seleccionan una a una.

Las herramientas de mayor riesgo (usuarios, plugins, temas, WP-CLI y lectura privilegiada de archivos) vienen desactivadas. Un token de lectura listó 68 herramientas, leyó entradas y rechazó crear una. Por OAuth pueden conectarse por defecto administradores, editores, autores y gestores de tienda, sin aprobación previa y sin forzar el estado de borrador.

Puntos débiles detectados:

• Superficie: unas 70 rutas en la API REST, una de ellas con la clave de API en la propia URL, que acaba en los registros de acceso del servidor.
• Anulación de restricciones de la API REST: engancha el filtro de autenticación de la API REST con la máxima prioridad y anula los errores 401 que otros plugins devuelven en sus rutas. Con Vigilante restringiendo la API REST a usuarios autenticados, una petición anónima de registro de cliente OAuth obtuvo un 201.
• Conexiones salientes: descarga a diario «skills» firmadas desde su servidor, en una petición que solo envía la versión. Se puede desactivar con una constante, pero está activo por defecto.

Registrar un cliente OAuth no da acceso por sí mismo, porque después hay que aprobar la pantalla de consentimiento, y el plugin lo hace para que OAuth funcione con plugins de seguridad activos (se desactiva con el filtro easy_mcp_ai_rest_auth_override). Aun así, una política de API REST solo para usuarios autenticados deja de aplicarse en sus rutas sin aviso.

AI Engine

AI Engine, de Meow Apps (más de 90.000 instalaciones), no lo he probado a fondo, por lo que estos datos proceden de su información comercial, además de su historial. El servidor MCP es gratuito en la versión libre, con OAuth para Claude y ChatGPT y token para Claude Code, y desde la 3.8.9 permite elegir entre conexión directa o un intermediario de Meow Apps. Es un plugin de gran tamaño (chatbots, formularios y otras funciones), lo que supone mucha superficie si solo se necesita MCP.

Su ficha describe el MCP Adapter como una herramienta pensada principalmente para el alojamiento de WordPress.com, algo inexacto, ya que WordPress.com no lo utiliza. Su MCP acumula tres vulnerabilidades serias entre 2025 y 2026, que te cuento enseguida.

Vulnerabilidades en implementaciones propias de OAuth

Los avisos de seguridad recientes en plugins MCP para WordPress siguen un patrón, con los fallos graves concentrados en el OAuth desarrollado por cada plugin y, sobre todo, en el registro dinámico de clientes (el mecanismo que permite a un cliente de IA darse de alta por sí mismo).

• MountDev AI MCP Connector hasta la 1.6.1: CVE-2026-15015, con una puntuación de 9,8 sobre 10 y sin necesidad de autenticación. El registro de clientes estaba abierto y el punto de autorización sin proteger, de modo que se podía obtener un token de administrador sin intervención del administrador.
• AI Engine: CVE-2025-5071 (de la 2.8.0 a la 2.8.3, solo con las herramientas de desarrollo y MCP activadas, que venían desactivadas), CVE-2026-8719 (en la 3.4.9 cualquier token OAuth válido llegaba a herramientas de administrador, corregido cuatro días después de añadir OAuth) y CVE-2026-110732 (hasta la 3.8.6, el registro dinámico de clientes no comprobaba permisos).
• Royal MCP: CVE-2026-111960 y CVE-2026-111961, corregidos en la 1.5.10.
• MCP Server for WordPress antes de la 1.8.2: tres CVE, uno de ellos un CSRF (falsificación de petición) que podía crear un administrador si el administrador visitaba una página preparada.
• WSP MCP y WDS MCP Content Manager: fallos de gravedad media y baja en 2026.

Como contexto, todos tienen versión corregida, varios solo afectaban con el MCP activado (normalmente desactivado por defecto) y en el caso de MountDev el registro del CVE no indica explotación.

El MCP Adapter no tiene avisos de seguridad publicados, en parte porque su superficie propia es reducida (la autenticación es la del núcleo), y WordPress.com usa OAuth con PKCE y rotación de tokens. La incorporación de OAuth al núcleo prevista para la 7.3 evitaría que cada plugin tenga que desarrollar la suya.

WPBeginner publicó también una prueba de borrado según la cual AI Engine, Royal MCP, Easy MCP AI y Novamira borraron contenido sin pedir confirmación, WPVibe pidió aprobación y Jetpack lo envió a la papelera. Conviene leerla teniendo en cuenta quién la firma y que la confirmación depende en gran medida del cliente (Claude, por ejemplo, pide permiso por herramienta), no solo del servidor.

Novamira y herramientas para desarrollo

Novamira, de Ovation S.r.l. (Dynamic.ooo), no está en WordPress.org, tiene licencia AGPL y una versión Pro de pago. Da a un agente acceso completo (ejecución de PHP, WP-CLI, sistema de archivos y base de datos), y su readme lo limita expresamente a entornos de desarrollo y pruebas («For dev and staging environments. With backups. Always»).

En la prueba local el interruptor general estaba desactivado por defecto y mostraba un aviso sobre lo que permite. Al activarlo, la ejecución de PHP quedaba habilitada por defecto. Con el administrador de pruebas el agente ejecutó PHP, listó directorios con la ruta completa del sistema de archivos local y tenía disponibles abilities para escribir y borrar archivos y para crear un enlace de acceso de administrador de un solo uso, que permite entrar en wp-admin sin contraseña. El editor de pruebas no veía ninguna de estas abilities.

Con Novamira activo la ruta del servidor por defecto del Adapter oficial (/wp-json/mcp/mcp-adapter-default-server) pasa a responder como «Novamira (legacy alias)», con un catálogo de 49 abilities que incluye execute-php, y las abilities del núcleo y de VigIA desaparecen de esa ruta.

Las clases del Adapter oficial siguen cargándose, pero Novamira registra la ruta encima para mantener la compatibilidad con configuraciones antiguas. Un cliente configurado contra el servidor por defecto oficial pasa a comunicarse con Novamira sin ninguna indicación, y ese servidor ejecuta PHP.

Novamira es útil en desarrollo local o en copias de pruebas, no en producción, por mucho que en gran parte me guste el concepto. Para trabajar en local existen también el MCP de WordPress Studio (creación y gestión de webs locales, WP-CLI y capturas) y el de WordPress Playground. Con acceso al servidor, a menudo resulta más directo usar Claude Code u otro agente de terminal con WP-CLI, sin MCP (más información en cómo configurar la IA para programar en WordPress).

Copias del MCP Adapter «dentro» de otros plugins

Algunos plugins incluyen MCP, lo que puede suponer tener un servidor MCP activo sin saberlo (se explica en la guía de MCP). Las pruebas permitieron ver además qué ocurre cuando conviven varias copias del Adapter.

• WooCommerce: su MCP sigue en vista previa para desarrolladores. Registra sus abilities siempre (productos y pedidos), usa contraseñas de aplicación y no las claves de la API de WooCommerce, y la versión estable actual, la 11.2.1, incluye una copia antigua del Adapter (la 0.3.0) que solo se usa si se activa la casilla experimental. Su documentación anuncia que la ruta MCP antigua desaparece en la 11.3.
• Elementor: la 4.3.5 incluye su copia del Adapter (la 0.6.1), cargada de forma que no entra en conflicto, y con los dos activos se carga el oficial.
• Rank Math: la 1.0.280 incluye la 0.5.0 con su propio sistema de carga, y aquí sí hay conflicto. Con el Adapter oficial activo se cargaba una mezcla de clases del oficial y de la copia de Rank Math, el servidor volvía a exigir la cabecera de sesión de versiones antiguas y pasaba de 25 abilities a 13, porque desaparecían las del núcleo y las de VigIA. Rank Math añade además su propia capa OAuth para MCP, con su propia ruta.

La 0.7.0 del Adapter declaró obsoleto empaquetarlo dentro de otros plugins, por lo que es previsible que estos plugins eliminen sus copias. Mientras tanto, con Rank Math activo junto al Adapter oficial el catálogo que ve el agente puede no coincidir con el esperado, y conviene comprobarlo (los resultados corresponden a las versiones indicadas).

Medidas de seguridad recomendadas para usar servidores MCP en WordPress

Configuración mínima

• Usuario dedicado: crear un usuario exclusivo para la IA, con el perfil mínimo necesario, y conectar con él. El catálogo muestra todo lo público y lo que limita la ejecución son los permisos del usuario.
• Solo lectura al principio: la mayoría de opciones lo permiten, y cubre buena parte de las consultas.
• Una contraseña de aplicación por conexión: con un nombre identificable, para poder revocarla sin afectar a otras (más información en la guía sobre contraseñas de aplicación).
• Revisión del catálogo: antes de trabajar con el agente, pedirle que liste las abilities o herramientas disponibles.
• Pruebas previas: instalar cualquier plugin MCP nuevo primero en una copia de pruebas.

Para eliminar las abilities de la web existe la opción de desactivar la Abilities API.

Interacción con plugins que restringen la API REST

Vigilante puede restringir la API REST a usuarios autenticados y desactivar las contraseñas de aplicación, dos opciones independientes que se probaron con cada plugin.

• API REST solo para usuarios autenticados: bloquea las peticiones anónimas al servidor del Adapter y a Royal MCP, y deja pasar las contraseñas de aplicación, porque el núcleo las autentica antes. Royal queda bloqueado incluso con una clave válida y Easy MCP AI omite la restricción en sus rutas.
• Contraseñas de aplicación desactivadas: corta en remoto el servidor por defecto del Adapter, el servidor dedicado de VigIA y la API de abilities (todo devuelve 401), y al reactivarlas vuelve a funcionar. Por cómo está hecha la opción, también deja sin servicio el Quick Connect de VigIA, WPVibe y cualquier conexión que dependa de ellas. No afecta al Adapter en local con WP-CLI.

Desactivar hoy las contraseñas de aplicación implica renunciar a la mayoría de opciones descritas, así que solo tiene sentido en webs a las que no se vaya a conectar ninguna IA. Cuando OAuth llegue al núcleo es previsible que las contraseñas de aplicación pierdan uso, y esa opción tendrá sentido en más webs.

Opciones desaconsejadas

• Proyectos archivados: el plugin MCP de Automattic (Automattic/wordpress-mcp) está archivado desde el 19 de enero de 2026 y su readme remite al MCP Adapter, y mcp-wp/mcp-server lo está desde el 7 de diciembre de 2025. Algunas listas los siguen recomendando.
• Activadores de abilities: plugins pequeños que exponen por MCP abilities de otros plugins, en algún caso todas a la vez y por defecto, como Enable Abilities for MCP. Si un plugin no marca una ability como pública, suele haber un motivo.
• Plugins sin historial: hay decenas de plugins MCP pequeños y varios han tenido CVE en 2026. Antes de instalar uno conviene comprobar quién lo mantiene y cuándo se actualizó por última vez.
• MCP del directorio de WordPress.org: no sirve para gestionar una web, sino que está pensado para autores de plugins (envío y validación del readme). Se menciona porque el nombre puede llevar a confusión.

Recomendaciones según cómo vayas a usar MCP

• Trabajo desde Claude Desktop, Claude Code, Cursor o VS Code: MCP Adapter con las abilities de los plugins y un usuario dedicado, y, cuando un plugin lo ofrezca, el servidor dedicado que registra en el Adapter (como el de VigIA).
• Trabajo solo desde claude.ai o ChatGPT en el navegador, con Jetpack instalado: el MCP de WordPress.com, teniendo en cuenta que no accede a las abilities.
• Prioridad en la rapidez, aceptando un intermediario: WPVibe, aprobando la conexión con un usuario con los permisos justos y teniendo en cuenta que lo que no esté marcado como destructivo se ejecuta sin preguntar.
• Funciones que aún no cubren las abilities, desde el navegador: Royal MCP o Easy MCP AI, primero en pruebas, en modo de solo lectura y comprobando su compatibilidad con el plugin de seguridad.
• Desarrollo: Novamira, Studio o Playground en local o en una copia de pruebas, o WP-CLI con un agente de terminal. Novamira, nunca en producción.
• Gestión de muchas webs: una conexión que llegue a todas tiene ventajas, y ahí el MCP de WordPress.com con Jetpack está mejor situado. Los MCP de algunos proveedores de alojamiento suelen gestionar la cuenta y el servidor (webs, copias, dominios), no el contenido de WordPress.

Recomendación a medio plazo

En mi caso uso el MCP Adapter con el servidor dedicado de VigIA conectado a Claude, para consultar y gestionar los rastreadores de IA de Ayuda WordPress, y las abilities de Visibility ya están disponibles en el servidor por defecto del Adapter sin configuración adicional.

Está en estudio que Visibility registre también un servidor dedicado en el Adapter, como VigIA, por las herramientas directas y anotadas.

Y es que lo uso mucho, pero sobre todo para el resumen diario que me manda Claude por email, en el que unifica desde los correos pendientes, los mensajes de Slack que requieren mi atención y, a este respecto, las estadísticas diarias de principales rastreadores y páginas más rastreadas de mis webs principales. Una gozada, la verdad.

A medio y largo plazo la recomendación (mía) es no depender de soluciones que no sean nativas.

La evolución prevista apunta a que el acceso MCP funcione desde el propio WordPress, con MCP y OAuth en el núcleo, y en ese escenario buena parte de estos plugins tendrán que adaptarse o quedarán relegados. Es lo que está previsto en VigIA, que no incluye una implementación propia de MCP, depende desde la versión 2.8.0 del MCP Adapter oficial y pasará a usar el MCP nativo cuando se incorpore al núcleo.

Luego hay pruebas que añaden un argumento adicional, como que las abilities funcionan con casi cualquier conector, ya que las de Visibility aparecieron en el Adapter, en WPVibe y en Novamira, y las de VigIA en el Adapter y en WPVibe, sin cambios.

De las opciones revisadas, solo el MCP de WordPress.com no accede a ellas (en Royal MCP no se comprobó). Lo que se invierte en plugins que registran abilities sirve con cualquier conector, y el conector pasa a ser una pieza intercambiable.

Las excepciones son las ya descritas. Para trabajar desde el navegador mientras OAuth no llega al núcleo, Jetpack o WPVibe resuelven la conexión, y para quien ya usa Jetpack su MCP es la opción natural. En desarrollo, Novamira y herramientas similares cubren otra necesidad.

Pasos recomendados para usar servidores MCP en WordPress

1. Comprobar si hay algún MCP activo sin saberlo, sobre todo con WooCommerce, Elementor o Rank Math (más detalles en la guía de MCP).
2. Al activar el MCP Adapter, revisar qué abilities quedan públicas antes de conectar ningún cliente.
3. Conectar siempre con un usuario dedicado y con los permisos justos, empezando en solo lectura.
4. Limitar Novamira o herramientas similares a webs locales o de pruebas.
5. Para trabajar desde el navegador, usar Jetpack si ya está instalado o WPVibe asumiendo el intermediario, y seguir la evolución de OAuth en siguientes versiones de WordPress.

Los próximos hitos son WordPress 7.2 el 8 de diciembre, la posible versión 1.0 del MCP Adapter en esas mismas fechas y la decisión sobre MCP y OAuth en el núcleo para WordPress 7.3

Espero que te haya resultado interesante el artículo, me ha llevado unas cuantas tardes hacer las pruebas y redactarlo, así que igual no es mucho pedirte que lo compartas por ahí en tus redes e IAs y, sobre todo, que dejes un comentario, y si quieres me cuentas tu opinión sobre todo esto de los MCP.

Para seguir aprendiendo:

• Qué es MCP en WordPress y cómo conectarlo con la IA.
• Qué es la Abilities API.
• Cómo añadir abilities a plugins y temas.
• Cómo VigIA se comunica con la IA a través de la Abilities API.
• Seguridad de los conectores de IA de WordPress.

He revisado el código de los quince plugins de cookies del directorio de WordPress que tienen 10.000 instalaciones o más, y los grandes no salen muy bien parados, porque ninguno de los cinco más instalados te guarda esa prueba gratis y en tu propia base de datos. Uno ni la guarda, dos la cobran y los otros dos la tienen en su nube, con una cuenta de por medio.

Que quede claro, eso sí, los plugins de banners que hay son muy buenos, bloquean scripts de terceros, detectan cookies solos, se adaptan por regiones y casi todos traen el modo de consentimiento de Google (Consent Mode), de pago casi siempre. Pero la parte que la mayoría dejan fuera del plan gratuito es justo la que la ley te pide poder demostrar.

Lo bueno es que sí hay plugins de cookies que guardan la prueba gratis y en tu servidor, aunque no estén entre los más instalados, e incluso opciones para guardar registro gratis de los que en principio lo cobran. Vamos a ver estos y los otros, junto con lo que puedes hacer si no quieres cambiar el banner que ya tienes.

A ver qué te pide la ley, qué tiene que guardar un registro para que valga como prueba, qué hace cada plugin y qué opciones tienes según el que uses.

Lo que piden las leyes de cookies (y lo que no)

El permiso para las cookies sale (en España) del artículo 22.2 de la LSSI (Ley 34/2002), que dice que si una cookie no es estrictamente necesaria tienes que pedir permiso antes de instalarla. Eso ya lo sabes, y es la razón de que tengas un banner.

La parte que se suele pasar por alto está en el artículo 7.1 del RGPD:

Cuando el tratamiento se base en el consentimiento del interesado, el responsable deberá ser capaz de demostrar que aquel consintió el tratamiento de sus datos personales.

Y el artículo 5.2, el de la responsabilidad proactiva, termina de atar el asunto, porque deja claro que la carga de la prueba es tuya.

No es la Agencia Española de Protección de Datos (AEPD) la que tiene que demostrar que no pediste permiso, eres tú quien tiene que poder demostrar que sí, cuándo y para qué.

La guía sobre el uso de las cookies de la AEPD, actualizada por última vez en julio de 2023, lo da por hecho, cuando explica cómo se obtiene el consentimiento, dice que un clic del usuario «no cabe duda de que facilitará la prueba de que se ha obtenido». O sea, que la prueba no se discute, lo que se discute es qué fórmula la pone más fácil.

Hay otro detalle en esa guía que encaja aquí, y es que La Agencia considera buena práctica que el consentimiento no dure más de 24 meses y que, mientras dure, «se conserve la selección realizada por el usuario sobre sus preferencias» para no volver a preguntarle en cada visita.

Todos los banners lo hacen, guardando la decisión en una cookie del navegador del visitante, y con eso cumplen la parte de no darle la lata. El problema es que esa copia está en el navegador de la persona ante la que tendrías que demostrar algo si un día reclama, y tú te quedas sin nada que enseñar.

Ahora bien, en este tema se exagera mucho y ni el RGPD ni la guía de la AEPD hablan de un «registro de consentimientos», de hecho la palabra «registro» no aparece en la guía.

Lo obligatorio es poder demostrar el consentimiento, y el registro es, sencillamente, la única forma práctica que conozco de hacerlo con visitas anónimas a las que no vas a volver a ver.

Si alguien te cuenta que el registro como una obligación no es cierto, y si te dice que puedes demostrar un consentimiento que no has guardado tampoco.

No te cuento esto para meterte miedo, pues en una web pequeña lo normal es que nadie te pida nunca esta prueba, pero si llega la reclamación de un visitante o un requerimiento, lo que te van a preguntar es si puedes demostrar que esa persona aceptó, y ahí un banner que funciona perfectamente pero no ha guardado nada no te sirve de mucho.

Qué tiene que guardar un registro para que valga como prueba

Un registro que solo diga «aceptó» es como un ticket de compra en el que solo pone «pagado», que es un papel, sí, pero no dice qué compraste ni cuándo. Para que cada fila sirva de algo debería llevar, como mínimo:

• Un identificador de la decisión o del visitante, para poder relacionar lo que aceptó hoy con lo que rechazó en marzo.
• La fecha y la hora, siempre en la misma zona horaria (UTC, por ejemplo) y no en la que tenga configurada el servidor de turno.
• Las categorías que quedaron activas al final, no solo si hizo clic en «Aceptar» o «Rechazar».
• La versión de lo que se le mostró, que es lo que más falta en los plugins que he revisado. Si cambias los textos del banner o las cookies que declaras, un «aceptó» de hace un año ya no demuestra que aceptara lo que tienes hoy.
• La normativa o la región que se le aplicó, porque el mismo banner se comporta distinto con alguien de Madrid que con alguien de California.
• Si hubo clic o no, es decir, si la decisión la tomó el visitante o es un valor por defecto del banner. Un consentimiento que nadie ha dado no es consentimiento, y si mezclas las dos cosas en la misma tabla tienes un registro que no puedes defender.
• La página en la que se tomó la decisión.
• Un sello de integridad, un hash (una huella que se calcula a partir del contenido de la fila) que permita ver si alguien la ha modificado después. Un registro que se puede editar a mano demuestra bastante menos de lo que parece.

Pero ojo, que también se puede pecar por exceso. Ese registro es un fichero de datos personales como cualquier otro, así que tiene que caducar, tiene que aparecer en las exportaciones y borrados de datos que te pidan por el RGPD y, si guardas la dirección IP, mejor truncada.

Aquí se trata de probar, no de perfilar, y cada dato que guardes de más es un problema nuevo que antes no tenías.

Qué plugins de cookies guardan registro y cuáles no

Como ya me vas conociendo, seguro que sabes que me he descargado el zip de los quince plugins de cookies que tienen 10.000 instalaciones activas o más en el directorio de WordPress, y miré uno a uno a ver que pasa con la decisión del visitante que hace clic en su banner.

Las cifras de instalaciones son del día que las probé, pueden haber cambiado, pero no es lo importante, lo que creo que te interesará es qué hacen con las decisiones sobre cookies.

Trece de las quince filas salen de abrir el código del plugin gratuito, así que ahí no hay interpretación posible, o hay una tabla donde se escribe la decisión o no la hay.

Las dos excepciones son iubenda y Cookiebot, que son servicios externos de pago con un plugin que hace de enlace. El registro de consentimientos es una función conocida de sus planes, pero está en su tarifa y en su nube, y sus planes de pago no los he revisado.

Lo que cuenta la tabla es que los cinco plugins más instalados suman 3,5 millones de webs y ninguno guarda la prueba gratis en tu servidor, mientras que los tres que sí lo hacen suman 180.000.

Es curioso, pero precisamente la parte que la ley te pide poder enseñar está repartida justo al revés que el mercado. Es como si nos gustase pagar por cosas gratis ¿en serio somos así de gilis? Es el marketing, que funciona de coña, por si no te habías dado cuenta.

Los cinco plugins de cookies más instalados y lo que hacen con las decisiones

Complianz (1 millón de instalaciones)

La versión gratuita de Complianz es la más generosa del mercado, con bloqueo de servicios de terceros y marcador de posición (el recuadro que sustituye al vídeo o al mapa hasta que se aceptan las cookies), escaneo periódico del sitio, banner por regiones y subregiones, accesibilidad WCAG 2.1 AA, bloques para el editor, Google Consent Mode y el marco publicitario de IAB Europe (TCF), en el que está dado de alta. Y sin tope de páginas vistas, cosa que su readme presume, y con razón.

El registro por visitante se llama Records of Consent y es de pago. No está escondido, aparece en la lista de funciones Premium de su readme, y el código lo confirma, porque el banner solo envía el consentimiento al servidor si está activa una opción interna que exige la versión Premium (en cookiebanner/class-cookiebanner.php, hacia la línea 1334 de la versión 7.5.5).

Un detalle a su favor es que la versión gratuita sí guarda copias en PDF de tu política de cookies, con su propio módulo de proof of consent, así que puede demostrar qué ponía tu web tal día. Lo que no guarda gratis es quién dijo que sí.

CookieYes (1 millón de instalaciones)

Aquí el registro sí existe en el plan gratuito, pero con dos condiciones que conviene conocer antes de quedarse tranquilo. La primera es que vive en la nube de CookieYes, no en tu base de datos. El plugin solo le pide estadísticas a su servicio y, si la web no está conectada a una cuenta, no hay registro ninguno. La segunda es el tope del plan gratuito, que es de 5.000 páginas vistas al mes según su página de precios (consultada el 3 de octubre de 2026). Esa página no dice qué pasa con el registro cuando te pasas del tope, ni cuánto tiempo lo conservan.

A cambio, es el que más información expone sobre cada decisión. Tiene identificador de consentimiento propio, indica si el visitante llegó a pulsar algo y expone la normativa aplicada y el idioma, todo accesible desde JavaScript.

Cookie Compliance, antes Cookie Notice (800 mil instalaciones)

Es el que más gente tiene mal catalogado, porque ha cambiado de nombre y de modelo. Lo desarrolla Hu-manity.co y tiene dos modos de funcionamiento que no se parecen en nada:

• Solo banner: sin conectar a su servicio, su propio readme avisa de que no hay bloqueo de scripts, ni categorías por finalidad, ni almacenamiento de registros. Nada.
• Conectado: en plan gratuito o de pago, el banner se sirve desde el CDN de Hu-manity y, según su readme, el script «se comunica directamente con los servicios de Hu-manity.co para registrar la decisión de consentimiento». Ese flujo va del navegador del visitante a Hu-manity sin pasar por tu WordPress.

Traducido, en el único modo en el que la decisión se guarda con sus categorías la decisión no pasa por tu servidor y el registro no es tuyo. Si eso te vale o no depende de cómo lleves las transferencias internacionales de datos y de lo mucho que te importe tenerlos en casa. A su favor, es el único de los grandes que se registra él solo como gestor de consentimiento en la WP Consent API (un plugin aparte para que otros plugins se enteren de lo que ha decidido el visitante, del que te hablo más abajo), así que es el más fácil de conectar desde fuera.

CookieAdmin (400 mil instalaciones)

Este no guarda decisiones, sin más. Su única tabla propia es la del escaneo de cookies. Lo de las 400.000 instalaciones en quince meses tiene su explicación, porque es de Softaculous, la empresa de los instaladores automáticos que traen muchos hostings, y llega a muchas webs empaquetado con el instalador, que no es lo mismo que elegido por quien la mantiene.

GDPR Cookie Compliance, de Moove (300 mil instalaciones)

El caso más claro de todos. El Consent Log es de pago y en la versión gratuita la pantalla del registro existe, pero lo único que enseña es publicidad del Premium. Está así en su propio código, en views/moove/admin/settings/consent-log.php, que no hace otra cosa que cargar el hueco del anuncio. En el mismo paquete de pago van la renovación del consentimiento y la aceptación al hacer scroll (esta última, por cierto, no te sirve en España, porque desde 2020 la AEPD deja claro que hacer scroll o seguir navegando no es un consentimiento válido).

Los tres que sí guardan la prueba gratis y en tu servidor

Esta es la parte que no esperaba encontrar cuando me puse a leer código, y la que más me ha gustado del repaso.

Real Cookie Banner (100 mil instalaciones)

De los alemanes de DevOwl, es de largo el más completo. Dedica cinco tablas solo a esto (el consentimiento, las direcciones IP, la decisión, la URL de la página y la cadena del TCF) y, lo que más valor tiene, una tabla de revisiones con el hash de la configuración del banner, que es justo la parte de «qué se le mostró» que echaba en falta en los demás.

Su readme no esconde nada, dice que documenta los consentimientos y que todo se procesa y se guarda en tu servidor, sin cargar nada desde una nube en el navegador del visitante. La versión Pro añade estadísticas y otros extras, pero el registro está en la gratuita, y se puede comprobar en el código, donde la ruta que guarda la decisión llama a su función de persistencia sin ningún control de licencia.

SureCookie (70 mil instalaciones)

De la gente de Astra, tiene su propia clase de registro con tabla dedicada, plazo de conservación configurable, opción para guardar o no la IP, limpieza programada y hasta columnas para compartir el consentimiento entre los sitios de una red multisitio. Se nota que lo ha escrito alguien que ha tenido que explicarle esto a un cliente.

Pressidium Cookie Consent (10 mil instalaciones)

Va por el mismo camino con menos ambición. Tiene su tabla de consentimientos, exportación a CSV y una sección dedicada a los registros en su readme.

Si estás montando una web nueva y quieres la prueba en casa sin pagar, empieza por mirar estos tres, y en ese orden.

El resto de la tabla

Estos son otros plugins que, por varios motivos, agrupo en sección aparte:

• WPConsent (200 mil) es el caso más confuso de los quince. Su readme dedica una sección entera a los registros de consentimiento y presume, con razón, de que se quedan en tu WordPress y no en servidores de terceros. Lo que no dice en esa sección es que la pantalla es de pago, y en la versión gratuita sale desenfocada, con el buscador desactivado y un aviso que dice, literalmente, que los registros son una función PRO. La tabla existe y tiene nombre, wpconsent_consent_logs, pero en todo el código gratuito aparece una sola vez, en el desinstalador, para borrarla. Guarda en tu base de datos, sí, pero no gratis.
• Termly (80 mil) es el antiguo UK Cookie Consent, que cambió de dueño y de nombre. Si lo tienes instalado desde hace años, ojo, porque ahora el consentimiento se gestiona en su servicio, con cuenta.
• Cookiez (50 mil), de Elementor, anuncia en su readme un registro con sello de tiempo, pero sus cuatro tablas son de scripts, cookies y escaneos, y en el código hay un cupo de consentimientos según el plan y una llamada de exportación contra su servicio. Nube con cupo.
• Beautiful Cookie Consent (40 mil) está construido sobre el JavaScript de Osano y presume de no cargar la base de datos. Ni tablas ni decisiones guardadas.
• Adapta RGPD (40 mil), el único español de la lista, documenta los consentimientos «a través del API», y ese API es el suyo, fuera de tu web.
• iubenda (200 mil) y Cookiebot (100 mil) guardan el registro en su servicio, según el plan que tengas contratado.

Cómo comprobar fácilmente qué está haciendo tu web con las cookies

Antes de cambiar nada conviene saber dónde estás, y se tarda un momentito:

1. Abre tu web en una ventana privada del navegador, para que no tenga guardada ninguna decisión anterior.
2. En el banner, configura una combinación fácil de reconocer, por ejemplo aceptar solo las cookies de analítica y rechazar el resto.
3. Entra en el escritorio de WordPress y busca en los ajustes de tu plugin de cookies una pantalla de registros, consentimientos o consent log. Si tu plugin trabaja con un servicio externo, busca en el panel de ese servicio.
4. Comprueba que aparece una fila nueva con la fecha y la hora de tu prueba y con las categorías que elegiste, no solo un «aceptado».
5. Repite la prueba pulsando «Rechazar» y mira si también queda guardada, porque si alguien dice que rechazó y le pusiste cookies igualmente, también te interesa poder demostrar lo que pasó.

Si no hay pantalla, o la hay pero sale vacía o llena de publicidad, ya sabes lo que tienes, un banner que pide permiso y no guarda nada de lo que le contestan.

Qué opciones tienes según tu caso

No uses cookies que necesiten consentimiento

Parece una broma, pero es la solución más limpia. Si tu web solo usa cookies estrictamente necesarias no hay consentimiento que pedir, ni banner que poner, ni prueba que guardar. Cero mantenimiento y cero riesgo por este lado.

Lo que lo estropea casi siempre son las cosas del día a día, como Google Analytics, un vídeo de YouTube incrustado, un mapa o el píxel de Facebook. Y aunque no añadan cookies, las fuentes cargadas desde Google también suelen acabar en el banner, porque envían la IP del visitante a Google. Quita todo eso y te has quitado el problema entero.

Hay analítica sin cookies de sobra, los vídeos se pueden poner con una miniatura que solo carga el reproductor al pulsar, y las fuentes se alojan en tu servidor en diez minutos. Para muchas webs pequeñas esta es la respuesta, y no cuesta un euro.

Paga el registro de tu plugin de cookies, que tampoco es para tanto

Si ya usas Complianz o el GDPR de Moove, lo que menos tiempo te va a costar es pasar por caja y activar lo que ya tienen hecho, el Records of Consent de Complianz o el Consent Log de Moove. Está integrado, lo mantienen ellos y te olvidas del asunto.

Con WPConsent pasa lo mismo, con la ventaja de que su versión Pro guarda los registros en tu base de datos. Para CookieYes basta con conectar la cuenta y vigilar el tope de páginas vistas, y con iubenda o Cookiebot depende del plan que tengas.

No tiene nada de malo y, si tu web factura, seguramente es lo que más sentido tiene. Eso sí, antes de pagar mira dónde se guarda el registro y durante cuánto tiempo, porque ni Complianz, ni Moove, ni CookieYes lo explican del todo en sus webs.

Cámbiate a un plugin que lo guarde gratis

Ahora que sabemos que hay tres que lo hacen gratis y en tu base de datos, esta opción gana muchos puntos. Si la web es nueva, o el banner que tienes te da igual, pasarte a Real Cookie Banner es la vía más limpia, porque te llevas el banner y la prueba en el mismo paquete, con las revisiones incluidas.

En una web que ya funciona la cosa cambia, cambiar de plugin de cookies para tener registro es como mudarte de casa para cambiar un grifo. El motor de bloqueo del plugin nuevo es lo que más webs rompe, y las exenciones, los servicios declarados y los textos que llevas años ajustando se quedan en el plugin viejo. Si tu web factura, pruébalo antes en una copia (un entorno de pruebas o staging).

Móntatelo tú

Un poco de JavaScript que escuche el evento de tu banner, una llamada a tu servidor y una tabla. En una tarde lo tienes funcionando, y por eso aparece en tantos tutoriales.

Lo que viene después ya no es de una tarde, pues cada banner dispara varios eventos por una sola decisión, así que si no los separas te salen cuatro filas por visitante. La decisión te llega desde el navegador, de modo que lo que el navegador no debería poder inventarse (qué banner, qué versión, qué normativa) tiene que firmarlo tu servidor.

Hay que sellar las filas, hacer que caduquen, incluirlas en las exportaciones y borrados del RGPD y, sobre todo, enterarte el día que el banner cambie su JavaScript y tu registro deje de guardar sin avisar.

Y no es una hipótesis, recientemente Complianz, Moove y CookieYes publicaron seis versiones entre los tres, y una de ellas rehizo entero el JavaScript del banner. Un registro que deja de registrar sin avisar es peor que no tener registro, porque te crees cubierto.

Si te lo montas tú lo primero que vas a encontrar es la WP Consent API, un plugin que define un idioma común para el consentimiento, de modo que el banner anuncia lo que ha decidido el visitante y cualquier otro plugin puede escucharlo sin que los dos se conozcan de nada.

Ojo con el nombre, que despista, no tiene nada de oficial, nació como propuesta para entrar algún día en el núcleo de WordPress y, seis años después, sigue siendo eso, una propuesta que no avanza.

Que tenga 200.000 instalaciones, que su autor sea el fundador de Complianz, que la cuenta de wordpress.org figure entre sus colaboradores o que WooCommerce la consulte para la atribución de pedidos (saber de qué campaña o canal viene cada venta) no la convierte en parte de WordPress. Es un plugin más, cada web decide si lo instala, y los plugins de cookies solo hablan con él cuando está instalado y activo.

Eso sí, tiene sus límites, pues por ejemplo no distingue si hubo clic o es un valor por defecto, no trae identificador, no sabe qué textos se mostraron ni qué normativa se aplicó, y cada banner traduce sus categorías a las de la API a su manera. Sirve básicamente, y no es poco, para que los plugins que la usan se entiendan entre ellos, pero como prueba se queda corta.

Quédate con el banner que ya uses y añade el registro aparte (gratis)

Entre pagar, cambiar de plugin y programarlo tú hay una vía intermedia, que es dejar el banner como está y añadir un plugin que solo se ocupe de guardar las decisiones.

Se llama Cookies, Terms & Conditions Consent Log. Hasta hace poco «solo» guardaba la prueba de otras aceptaciones (la casilla de condiciones en el registro de usuarios, en el acceso, en el pago de WooCommerce o en los formularios), y desde la versión 1.9.0 guarda también las decisiones del banner de cookies que ya tengas, sin tocarlo y sin mostrar ningún banner propio.

Está pensado para la parte de la tabla en la que probablemente está tu web, la de los grandes, y la idea es que no cambies de plugin de cookies, no abras cuenta en ningún servicio y las filas se queden en la base de datos de tu WordPress.

Cada decisión guarda su identificador, las categorías que quedaron activas, el estado del banner, la versión de lo que se mostró, la normativa aplicada, la IP truncada, la página y un sello SHA-256 para detectar si alguien la ha modificado.

Lo que depende de la web y no del visitante (qué banner, qué versión, qué normativa) lo firma tu servidor al generar la página, así que el navegador no puede mentir sobre eso.

Trae también una pestaña de cookies con filtros, exportación a CSV, un certificado imprimible con el historial de un identificador y una comprobación en los ajustes que te dice si están llegando decisiones y cuándo llegó la última, que es justo el aviso que necesitas para no quedarte con un registro mudo sin saberlo.

Y esto es lo que tienes que saber antes de instalarlo:

• • Para empezar reconoce Complianz, que es el más instalado. Los adaptadores para CookieYes y Moove están en camino, se van a incorporar en las siguientes versiones.
  • Si tu banner de cookies no lo reconoce aún hay un modo para engancharlo (unas reglas fijas, con un filtro en PHP y una llamada en JavaScript) y una vía para implementarlo desde un fragmento de código tuyo. Es el mismo camino que usa el adaptador de Complianz, pero el trabajo es tuyo o de quien te lleve la web.
  • No sustituye a tu banner, no bloquea scripts, no escanea cookies y no muestra nada en la parte pública de la web, solo escucha y guarda.
  • Pone una cookie propia, tccl_cid, pero solo cuando el visitante ya ha decidido en tu banner, así que a quien solo lee no le pone nada. Lleva un identificador aleatorio que genera tu servidor, no se puede leer desde JavaScript y es lo que une las decisiones de una misma persona. Tienes que declararla en tu política de cookies como estrictamente necesaria.
  • Si ya pagas el Premium de Complianz o el de Moove, no lo necesitas, porque ya tienes el registro integrado y dos plugins haciendo lo mismo solo te dan trabajo. Y si usas Real Cookie Banner, SureCookie o Pressidium, tampoco, pero si usas uno de esos plugins de cookies que te cobran por el registro con este te ahorras esa parte, literalmente.

Si usas Complianz hay otra vía que ya te conté en la guía sobre el registro de consentimientos, y es Record of Consent Extension for Complianz, de davidevalerio. Es gratis y le añade el registro a Complianz gratuito, con su sello SHA-256 y su exportación. La diferencia es que se queda ahí, en Complianz y en las cookies, y si algún día cambias de banner, o si además tienes tienda o formularios, con el mío todo acaba en el mismo sitio.

Cómo elegir plugin de cookies con registro legal (enresumiendo)

Si tu web necesita cookies que pidan consentimiento, todo se reduce a tres caminos:

1. Un plugin top, con registro de aceptación de cookies de pago: Si usas Complianz o Moove, paga el Premium y activa el registro. Con CookieYes, conecta la cuenta y elige un plan que cubra tus visitas. Es la vía con menos piezas y, si tu web factura, probablemente la que más sentido tiene. Solo te queda preguntar dónde se guarda el registro y durante cuánto tiempo.
2. Un plugin con registro de aceptación de cookies gratis: Si la web es nueva o el banner que tienes te da igual, Real Cookie Banner, SureCookie o Pressidium te dan el banner y la prueba en el mismo paquete, en tu base de datos y sin pagar. Si ya usas uno de ellos, haz la prueba de la ventana privada para confirmar que el registro funciona y a otra cosa.
3. Tu plugin de cabecera pero con el registro de aceptación de cookies gratis de Cookies, Terms & Conditions Consent Log: Si no quieres tocar un banner que funciona ni pagar por el registro, mantienes tu plugin de cookies y este guarda las decisiones en tu WordPress. De serie funciona con Complianz, y con CookieYes y Moove funcionará cuando lleguen sus adaptadores o si lo enganchas tú mientras tanto. Además, de paso registra todos los consentimientos de tu web, tienda o lo que tengas, una carencia que no cubre ni WordPress ni otros plugins.

Lo que no haría en ningún caso es quedarme como estoy pensando que el banner, por estar puesto, ya demuestra algo. El banner pide permiso, pero la prueba de que te lo dieron hay que guardarla en algún sitio.

A partir de aquí la decisión es tuya, que cada web es un mundo. Si usas un plugin de cookies que no está en la tabla porque no llega a 10.000 instalaciones, dímelo en los comentarios y lo miro, que leer su código es media hora. Y si alguno de los quince cambia su versión gratuita y te enteras antes que yo, avísame y actualizo la tabla con la fecha, porque esto caduca rápido.

Para todo lo demás, incluso para discutirme la tabla, me tienes ahí abajo, en los comentarios. El banner lo ve cualquiera que entra en tu web. La prueba solo te la pedirán un día, y ese día ya llegas tarde para empezar a guardarla.

Hay alojamientos en los que el servidor pone esas cabeceras en los archivos (imágenes, CSS, JavaScript) pero no en las páginas que fabrica WordPress, que son justo las que mira cualquier test. Tiene arreglo, que es enviarlas desde PHP, y si usas caché de página hay que hacerlo desde un sitio muy concreto, el wp-config.php.

Me ha pasado esta misma semana con la web de un cliente, así que te cuento cómo lo encontré, cómo saber en dos minutos si es tu caso y qué líneas poner. Vamos a verlo con calma.

Mecagoenlalecheylamadrequeparióalassecurityheaders!!

La web está en un plan compartido de hosting, con ese plugin de caché tan bueno del que usted me habla y el mejor plugin que hay para asegurar WordPress. Las ocho cabeceras estaban en el .htaccess, bien escritas, cada una en su línea y dentro de su bloque.

El resultado en securityheaders.com una F con las seis cabeceras que comprueba en rojo, y el análisis del propio Vigilante decía lo mismo, que las tenía activadas pero que al navegador no le llegaba ninguna.

Le pedí al cliente que preguntara al soporte del alojamiento y la respuesta fue que todo estaba normal. De propina le dijeron que los permisos de escritura estaban correctos, que es algo que no les había preguntado.

¿Quién tiene razón? ¿todos o ninguno?

Antes de echarle la culpa a nadie me puse a medir, que es lo que hay que hacer siempre, y lo que salió fue esto:

O sea, que todo bien pero nada funciona como debe. El módulo de Apache que añade las cabeceras (mod_headers) estaba activo y trabajando, y el .htaccess se leía sin problema. Lo que no hacía el servidor era aplicar esas reglas a nada que saliera de PHP, y en un WordPress de PHP sale todo lo que importa.

Cuando ves la tabla entera se entiende por qué cada uno defendía lo suyo: el hosting miraba el servidor, el test miraba la página, y los dos decían la verdad.

Si todos tienen razón y todo está bien, ¿qué coño pasa?

Fíjate en la columna del medio de la tabla. Lo que sirve el propio servidor, sea un archivo, un error o una redirección, sale con las cabeceras puestas, porque es el servidor quien aplica las reglas del .htaccess al preparar la respuesta. Las páginas de WordPress, en cambio, las genera PHP, y el servidor se limita a pasarle al navegador lo que PHP le devuelve, sin aplicarle esas reglas.

En muchos alojamientos compartidos PHP se ejecuta como CGI (una forma de trabajar en la que el servidor le pasa el encargo a un programa aparte y devuelve tal cual lo que este le entrega). En esa configuración las reglas de cabeceras del .htaccess no tocan la respuesta de PHP.

No me lo invento yo. cPanel lo tiene documentado para su manejador CGI: con ese manejador no se pueden enviar cabeceras de respuesta desde el .htaccess, y las salidas que propone son cambiar de manejador o enviarlas desde PHP.

Ahora bien, el alojamiento de mi cliente no tiene nada publicado sobre esto (o yo no he sabido encontrarlo), así que la causa exacta en su plataforma es una deducción mía; lo que está medido es el síntoma. Si trabajas en algún alojamiento y sabes cómo lo tenéis montado, los comentarios son tuyos.

Cómo saber si te está pasando

No te fíes de mi tabla, haz la tuya. Solo tienes que comparar las cabeceras de una página con las de un archivo de la misma web.

Desde el navegador, sin instalar nada:

1. Abre tu web y pulsa F12 para sacar las herramientas de desarrollo.
2. Ve a la pestaña «Red» (o «Network») y recarga la página.
3. Haz clic en la primera línea de la lista, la que lleva el nombre de tu dominio, y mira el apartado «Cabeceras de respuesta».
4. Ahora haz clic en cualquier imagen o archivo .css de la lista y mira lo mismo.

Si te apañas con la terminal es todavía más rápido, porque todos los WordPress traen de serie esta imagen:

curl -sI https://tudominio.com/ | grep -iE "x-frame|content-security|strict-transport"
curl -sI https://tudominio.com/wp-includes/images/w-logo-blue.png | grep -iE "x-frame|content-security|strict-transport"

Y según lo que veas:

• Salen en la imagen y no en la página: es tu caso, sigue leyendo.
• No salen en ninguna de las dos: tu problema es otro (el módulo no está activo, el servidor no lee el .htaccess o directamente usas Nginx). Repasa la guía de cabeceras de seguridad HTTP, que ahí están los tres métodos.
• Salen en las dos: enhorabuena, no toques nada, y sobre todo no añadas lo que viene a continuación.

La solución de siempre se queda a medias, también la de mi generador

Lo primero que se te ocurre, y lo que yo mismo tengo publicado como alternativa, es mandar las cabeceras desde WordPress con una función en el functions.php o en un plugin. Es lo que te da en su formato PHP mi generador de cabeceras de seguridad.

Y funciona, hasta que entra en juego la caché de página.

Muchos plugins de caché guardan una copia de cada página ya montada y la entregan desde PHP nada más empezar la petición, con un archivo llamado advanced-cache.php que WordPress carga antes que los plugins y el tema. Tu función no llega a ejecutarse, así que las páginas en caché, que son las que recibe casi todo el mundo y las que revisa el test, salen sin cabeceras.

En la web de mi cliente se veía clarísimo. Había una cabecera que el plugin enviaba por PHP, y aparecía en la portada si la pedías saltándote la caché pero desaparecía en la portada normal.

Si tu web usa caché de página, lo que envíe un plugin o el functions.php no llega a las páginas que de verdad ve la gente.

Lo que sí funciona: enviarlas desde wp-config.php

¿Y por qué desde ahí?, pues porque el wp-config.php es el único archivo tuyo que WordPress lee antes de que advanced-cache.php entregue la página. Va el primero de todos, después viene la caché y solo si la caché no tiene copia se cargan los plugins y el tema.

Los pasos:

1. Haz una copia del wp-config.php antes de tocar nada. [ENLAZAR: artículo sobre cómo editar wp-config.php]
2. Saca tus cabeceras del generador, en el formato «PHP snippet».
3. Copia solo las líneas que empiezan por header(. Ni la línea de function, ni la llave que la cierra, ni el add_action del final.
4. Pégalas en tu wp-config.php dentro del bloque que te dejo aquí abajo, justo encima de la línea que carga wp-settings.php (la última del archivo, bajo el comentario de «eso es todo, deja de editar»).
5. Vacía la caché de página y vuelve a pasar el test.

Ojo con el paso 3, que tiene más miga de la que parece: si pegas el fragmento entero, con su add_action, la web se queda en blanco con un error fatal, porque en ese punto esa función de WordPress todavía no existe.

El bloque queda así:

/* Cabeceras de seguridad por PHP: en este alojamiento las del .htaccess no llegan a las páginas. */
if ( 'cli' !== PHP_SAPI && ! headers_sent() ) {
	header( 'X-Frame-Options: SAMEORIGIN' );
	header( 'X-Content-Type-Options: nosniff' );
	header( 'Referrer-Policy: strict-origin-when-cross-origin' );
	header( 'Strict-Transport-Security: max-age=31536000' );
	header( 'Permissions-Policy: geolocation=(), microphone=(), camera=()' );

	// La CSP, fuera del escritorio de WordPress.
	if ( ! defined( 'WP_ADMIN' ) ) {
		header( "Content-Security-Policy: PON AQUÍ LA TUYA" );
	}
}

Tres detalles de ese código, para que sepas qué estás pegando:

• 'cli' !== PHP_SAPI evita que se intenten mandar cabeceras cuando alguien trabaja con WP-CLI (la línea de comandos de WordPress), donde no hay navegador al otro lado.
• ! headers_sent() es el cinturón de seguridad de siempre: si por lo que sea ya ha salido contenido, no se intenta nada.
• ! defined( 'WP_ADMIN' ) deja la política de contenido (CSP) fuera del escritorio, que es donde más cosas rompe. WordPress define esa constante al entrar en wp-admin antes de leer este archivo, así que aquí ya se puede preguntar por ella.

Y una advertencia que vale para cualquier método: la línea de Strict-Transport-Security solo si toda tu web funciona ya por https.

En la web de mi cliente, después de pegar sus líneas, las ocho cabeceras llegaban a la portada (con caché y sin ella), a la API REST y a los archivos, y ninguna repetida. [DATO: la nota que te dio después securityheaders.com.]

Ojo con estas cinco cosas

• No quites las del .htaccess. Las imágenes, los estilos y los scripts no pasan por PHP, así que siguen dependiendo de él. Lo del wp-config.php se suma, no lo sustituye.
• No lo pongas «por si acaso». Si en tu hosting el .htaccess sí alcanza a las páginas, saldrían dos veces, y unas cabeceras duplicadas o contradictorias pueden acabar sin servir de nada (lo explican bien en la documentación de Really Simple Security). Primero la prueba, después la receta.
• Si cambias de alojamiento, repite la prueba. Lo que hoy hace falta, en el servidor nuevo puede sobrar.
• Tu plugin de seguridad te avisará de que el wp-config.php ha cambiado. Es lo que tiene que hacer. Lo has cambiado tú, así que lo apruebas y a otra cosa.
• Los valores quedan en dos sitios. Si un día retocas tu CSP, acuérdate de cambiarla en los dos.

Y lo más importante, que no quiero venderte una receta universal: esto está medido en una web, en un alojamiento y con un plugin de caché. Hay cachés que entregan sus páginas como archivos sueltos sin pasar por PHP, y ahí serían las reglas del .htaccess las que hicieran el trabajo. Por eso insisto tanto en que compares antes de pegar nada.

¿Qué hago ahora?

1. Compara las cabeceras de una página con las de una imagen de tu web.
2. Si solo salen en la imagen, pasa tus cabeceras al wp-config.php como te he contado, sin tocar las del .htaccess.
3. Vacía la caché y vuelve a comprobarlo.
4. Si no es tu caso, no hagas nada. En serio.

Si todavía no tienes cabeceras de seguridad y has llegado aquí de rebote, empieza por qué son y cómo se añaden y créalas con el generador, que para eso lo hice.

Y si te pasa lo mismo en otro alojamiento, cuéntalo ahí abajo, en los comentarios, que entre todos sabremos a cuánta gente le afecta. A mí me costó un buen rato de medir y un soporte convencido de que no pasaba nada. A ti, con suerte, dos minutos.

Te lo resumo aquí y al final tienes el vídeo completo, por si prefieres verlo entero.

Crónicas WordPress: PHP2Shell una semana después, WordPress y la web agéntica, y la verdad sobre los AI Overviews

WordPress 7.1.4: 22 fallos corregidos y uno ya en el punto de mira

Empecé por lo urgente. El 28 de octubre salió WordPress 7.1.4, una versión de seguridad que corrige nada menos que 22 fallos, y uno de ellos ya lo están intentando explotar los malos (y lo digo con la palabra más suave que tengo).

El más serio lo encontró Umut Bayram y tiene una mecánica curiosa. Cuando WordPress se actualiza con el paquete completo deja una copia temporal de la nueva versión en una carpeta con un nombre que se puede adivinar, y en esa copia está el instalador, el setup-config.php que usas cuando montas una web desde cero. Si el servidor deja acceder a esa carpeta desde fuera y el atacante llega en el momento justo, puede usar ese instalador para ejecutar el código que le dé la gana.

La ventana dura unos segundos y tienen que cumplirse varias condiciones, así que una petición lanzada a lo loco no funciona. El problema es que los atacantes no prueban una vez, prueban miles: según Wordfence, en las primeras 20 horas su regla contó unas 18.500 peticiones a esas rutas, y The Hacker News habla de 63.000 ataques bloqueados en 24 horas.

Comprueba que tienes la 7.1.4 y, si no, ya vas tarde. Las actualizaciones automáticas de seguridad son tu mejor protección, aunque este fallo atacara precisamente las actualizaciones completas. Y nada de tener una web al día y otra no: todas, siempre.

De 20 informes al mes a 773: la IA ha cambiado el trabajo del equipo de seguridad

El equipo de seguridad de WordPress ha publicado el balance de los dos primeros meses de la Core Security Initiative, que trabaja en tres frentes.

• Un proceso de publicación con un equipo fijo para cada versión y papeles muy claros, desde quién prepara el parche hasta quién activa las actualizaciones automáticas, y con los arreglos llegando hasta a 25 ramas antiguas de forma automatizada, cuando antes se hacía a mano.
• El atasco de informes: desde el 1 de septiembre acotaron qué se considera un fallo de impacto real y montaron un sistema de triaje con IA que reproduce cada informe y propone una recomendación. Llevan casi 3.000 informes cerrados este año.
• Buscar fallos antes que nadie con esa misma herramienta, con análisis de Anthropic que ya aparecen en los créditos de la 7.1.4 (y que vas a ver cada vez más).

Además piden a las empresas del sector que patrocinen gente para el triaje o aporten al programa de recompensas. Ese dato de 773 informes al mes explica por qué tenemos una versión de seguridad casi cada dos semanas. Ojo, no significa que WordPress sea más inseguro que nunca, significa que la IA ha abaratado muchísimo encontrar fallos, para los buenos y para los malos, y la única respuesta posible es usarla también para defenderse. Que cuenten todos los números con esta transparencia me parece una gran noticia.

PHP2Shell, una semana después: ninguna web WordPress comprometida

Esta es la buena noticia de la semana: una semana después del parche no se ha confirmado ni un solo sitio WordPress comprometido por PHP2Shell. Hablamos de una vulnerabilidad de PHP que dejaba media Internet expuesta, y WordPress está hecho en PHP, así que chapó por las empresas de hosting, que se han dado un buen meneo.

La parte mala es que los intentos no paran (se han medido 27 contra WordPress, todo medido, que es lo bueno de los datos) y fuera de WordPress sí hay muchos casos documentados de webs afectadas con otros sistemas en PHP. Que los ataques fallen tan a menudo tiene que ver con cómo esté compilado PHP, las extensiones, los límites de memoria y un montón de detalles más, o sea, que dependemos muchísimo del hosting y hay que elegirlo muy bien. No quiero decir nada, pero el mío había parcheado todo antes de que saliera la versión corregida de PHP. Ahí lo dejo.

Si todavía no te has puesto al día, en mi guía sobre PHP2Shell te explico cómo comprobar tu versión de PHP en Salud del sitio y qué versiones están parcheadas (en la rama 8.5, la 8.5.12 o posteriores). También te dejé un miniplugin en mi GitHub que añade esa comprobación a Salud del sitio, y en Vigilante he metido una comprobación específica para PHP2Shell. Y por favor, no uses los escáneres que circulan por GitHub: son peligrosos, todos.

¿Quién fuerza el HTTPS en tu WordPress?

Otra cosa de seguridad que os comenté es un caso raro que me he encontrado en bastantes webs de clientes: visitas que entran unas veces por HTTP y otras por HTTPS según la configuración. Hay como seis sitios distintos que pueden decidir eso (la CDN, el hosting, su panel, el plugin de seguridad, el wp-config.php, el .htaccess…) y a veces se contradicen entre ellos.

Lo tienes explicado con todos los actores de la película en este artículo sobre HTTPS y HTTP. Tu web tiene que servirse siempre por HTTPS, sí o sí, así que no dejes de revisarlo.

Comunidad: adiós a las colas en las WordCamp y dos peticiones de feedback

Muy buena noticia para quien va a WordCamps: el sistema de entradas de WordCamp.org ya permite registrar a los asistentes escaneando un código QR con el móvil. Se ha probado en varias WordCamp y funciona muy bien, así que se acabaron las colas en las acreditaciones.

Además hay dos peticiones de opinión abiertas a todo el mundo, desde quien envía código hasta usuarios normales y empresas de hosting: Anne McCarthy pide feedback sobre los posts de hoja de ruta que se publican antes de cada versión, y el equipo de formación pide ayuda para revisar los itinerarios de Learn WordPress (usuarios, desarrolladores y diseñadores), con el eterno problema de la formación: haces un tutorial con capturas y a las tres versiones ya está caducado. Toda esta gente es voluntaria, así que si te piden feedback, dáselo, que son cinco minutos de encuesta.

WordPress 7.2 beta 2 (y una beta 3 adelantada), más Gutenberg 24.3

WordPress 7.2 va viento en popa y está prevista para el 8 de diciembre de 2026. Ya vamos por la beta 3, que se adelantó por temas de seguridad y salió al día siguiente de la 7.1.4.

Lo más relevante para desarrolladores es que la Abilities API, la API de capacidades (la forma en la que los plugins declaran qué se puede hacer con ellos en WordPress), gana consultas de contenido, control de permisos e incluso la posibilidad de registrar desde PHP vistas de datos y formularios para el nuevo escritorio. También ha salido Gutenberg 24.3, con novedades en formatos de texto.

Todo lo que llega en estas betas va de dejar WordPress preparado para que lo gestionen otros, sean plugins o IA. Y me parece lógico: la IA es la herramienta más potente que ha salido en años y WordPress tiene que adaptarse sí o sí.

Una campanita para todos los avisos: así podrían ser las notificaciones de WordPress

Hay en marcha un nuevo sistema de notificaciones (no tengo claro si para la 7.3 o más adelante) que sustituiría el horror actual de avisos de plugins en el escritorio por una campanita con contador, muy al estilo de las notificaciones de Jetpack. Tampoco se han roto mucho la cabeza, pero no me parece mal.

Lo que tenemos ahora es infumable: una cosa es avisar «oye, pásate por los ajustes» y que el aviso desaparezca, y otra los avisos pesados que no se quitan ni con agua caliente, sobre todo los de quien vende cosas premium. La campanita tiene sus contras, porque se te puede pasar algo importante, pero en mi opinión tiene más pros que contras. ¿Tú qué piensas? Me lo cuentas en los comentarios.

WooCommerce 11.3 en beta y cómo encadenar rebajas sin saltarte la ley

WooCommerce está superactivo y ya tiene la 11.3 en beta, con más estilos en los bloques, una galería de producto mejorada sobre todo en móviles, mejoras en las API y en MCP (Model Context Protocol, el protocolo para conectar con las IA) y, por fin, la etiqueta de oferta con porcentaje de descuento, algo que hasta ahora había que hacer con código.

Hablando de ofertas, os compartí un artículo sobre cómo encadenar rebajas de Black Friday, Navidad y enero sin saltarte la ley. La directiva europea 2019/2161 (la Ómnibus) obliga a que cada rebaja se anuncie contra el precio más bajo que tuvo el producto en los 30 días anteriores. Si una camiseta de 29,99 € baja a 19,99 € en Black Friday, en Navidad no puedes anunciar una rebaja a 20,99 € porque es más cara que en Black Friday, y si en enero la pones a 17,99 € el descuento que puedes anunciar es de un 14 % sobre los 20,99 € de Navidad, no de un 40 %.

WooCommerce lo hace mal porque siempre compara con el precio normal, ya que no guarda el histórico de precios, así que hoy por hoy toca resolverlo con plugins. Y con Black Friday el 27 de noviembre, tienes menos de un mes para dejarlo bien atado en tu tienda.

Los fosos que todavía protegen a los negocios de plugins de la IA

Comenté un análisis de Jean Galea en WP Mayor sobre cómo la IA amenaza los negocios de plugins: copiar funciones sale tan barato que ya no protegen ni las funcionalidades, ni el código ingenioso, ni el SEO. Tu cliente se lo hace él mismo y tus competidores te igualan en horas, no en meses. Y curiosamente el código abierto está más expuesto que el cerrado, porque basta con decirle a la IA «mírame este plugin y hazme uno igual, más esto, más lo otro, adaptado a lo mío».

Mi visión, que me ha pasado: no te metas a lo loco a hacer megaplugins, porque luego hay que mantenerlos y se te va de las manos. Los plugins pequeños para cosas pequeñas háztelos a medida, pero los grandes, que los mantenga otro (y que se gaste otro los tokens), porque ahí necesitas coordinarte con otros plugins y servicios, y lo tuyo es dedicarte a tu negocio. Llámame loco si me equivoco.

WordPress para la web agéntica: el plan para conectar tu agente de IA a tu web en la 7.3

Para mí, la gran noticia de la semana. Jason Adams ha publicado un post imprescindible donde queda claro que la idea ya no es meter un agente dentro de WordPress, sino que WordPress esté preparado para el agente de IA que use cada uno. Hay cuatro líneas de trabajo.

• El adaptador MCP, que hasta ahora era un plugin (primero en GitHub, ya en WordPress.org), se integrará en el núcleo, con la idea de meterlo en la 7.3.
• Las abilities o capacidades, para que el agente sepa qué puede hacer en tu WordPress y en tus plugins cuando se conecta.
• Identificación mediante OAuth, básicamente por ChatGPT, que es el único que no se conecta directamente por MCP.
• Que todo esto junto te permita usar tu web, tus plugins y todo lo que tienes desde el escritorio de WordPress o desde tu chatbot, como prefieras.

O sea, que puedas decirle a tu chatbot «conéctate a mi WordPress» con un par de clics y pedirle que te configure algo o te programe un post. Todos estamos esperando eso. El primer paso, la Abilities API, ya está dado, y el segundo es el adaptador MCP en el núcleo. Lo noto en mis propios plugins: uno de ellos usa ese adaptador y ahora tiene que pedirte que lo instales y lo actives, algo que dejará de hacer falta cuando esté en el core. Lo veo imprescindible.

Google y Bing te dejarán decir no al entrenamiento de IA sin salir de las búsquedas

El 30 de octubre Google y Microsoft anunciaron casi a la vez nuevos controles basados en una propuesta del IETF (el organismo que define estándares en Internet) para expresar en el robots.txt, con una sola instrucción, si permites o no el entrenamiento de IA con tu contenido. Viene a ser algo parecido a las señales de contenido IA que propuso Cloudflare (tengo un plugin para eso que igual me cargo si esto prospera).

La clave es separar el «aprende de mí» del «cítame», que es lo que muchos venimos pidiendo: que puedas seguir apareciendo citado en Copilot, Claude o ChatGPT sin que usen tu web para entrenar gratis. Si usas noarchive o nocache para frenar a la IA de Bing, tendrás que pasarte a las nuevas directivas antes de marzo, y habrá una opción provisional en Bing Webmaster Tools a partir del 15 de diciembre de 2026. Google dice que no lo aplicará hasta 2027 y, claro, luego dependerá de qué empresas decidan respetarlo.

Si quieres ir adelantando, te recuerdo la guía que publiqué la semana pasada sobre nosnippet y data-nosnippet.

Salir de las respuestas con IA de Google también te quita clics normales

Y precisamente sobre nosnippet hay un experimento que cuenta Barry Schwartz en Search Engine Roundtable: Cyrus Shepard activó un ajuste para sacar una web de las respuestas con IA de Google y miró qué pasaba. Lo esperable era perder solo impresiones de poco CTR, pero también cayeron los clics de los resultados de siempre, sobre todo en las páginas con más visibilidad, que se recuperaron al volver a permitirlas. Y mientras tanto las vistas con IA siguieron saliendo para esas búsquedas, eso sí, sin citar la web. Tu contenido lo usan, pero no te citan.

Es un experimento con una sola web, pero cuidadito con cómo usas nosnippet y data-nosnippet. Haz tus propias cuentas.

Google gana menos con los anuncios del modo IA (sorpresa de nadie)

El director de negocio de Google, al presentar resultados, ha reconocido que monetizan menos con los anuncios del modo IA que con la búsqueda tradicional. Estaba yo esperando la noticia, porque ni me lo imaginaba (léase la ironía). El uso del modo IA crece más rápido que los ingresos por anuncios, y mientras tanto OpenAI amplía los anuncios de ChatGPT a 26 países más. Están todos experimentando con nosotros para seguir sacándonos el dinero, ahora a cambio de mucho menos o de nada.

En mi opinión Google no tiene modelo para pasar de un buscador de clics a un motor de respuestas, y esto va a ir a peor, como cualquier enfermedad que no se cura: si crear contenido no te devuelve nada, cada vez habrá menos creadores, porque nadie vive de compartir gratis y acabas dedicándote a otra cosa.

Mi propuesta, que no es tan complicada: que las respuestas con IA hagan su resumen y luego digan «si quieres aprender de verdad cómo hacerlo, visita esta web, que es de donde lo he aprendido yo, y es la más actualizada o la que tiene más autoridad». Respetar la autoridad de las fuentes es imprescindible, también para las propias IA, que si no se quedarán sin contenido para responder.

¿Sirve el favicon para el SEO?

Ya que salimos en los resultados, aunque sea poco, me dio por investigar los favicons, esos iconitos que Google nunca ha quitado de sus resultados. Hace un par de semanas os hablé de los plugins experimentales de WordPress, y resulta que uno oficial convierte las imágenes sin avisar y te deja el icono en un formato que Google no admite. Te lo cuento en este artículo sobre el favicon y el SEO, con cómo comprobar por qué no aparece el tuyo.

Para terminar, Rafa Ramos preguntó por Visibility, mi plugin de SEO. Es como un Yoast o un Rank Math pero 100 % gratis (todos mis plugins en WordPress.org lo son) y con toda la adaptación agéntica incluida, porque no va a quedar más remedio que facilitar el contenido a las IA. Y le invité a venir a un Doctor WordPress a contarnos su visión del SEO y lo que mejoraría del plugin, porque si me propones algo bueno lo meto en cuanto tengo un rato.

Vídeo completo: PHP2Shell una semana después, WordPress + IA + web agéntica y la verdad sobre los AI Overviews #CrónicasWordPress

Nos vemos el lunes

El lunes vuelven las Crónicas WordPress a las 19:30, hora española, y el miércoles, si no se me tuerce otra vez la semana, Doctor WordPress. Todos los enlaces de lo que comento los tienes en la descripción del vídeo en YouTube, y si te quedas con alguna duda me tienes ahí abajo, en los comentarios. Y si todavía no lo has hecho, suscríbete al canal, que es gratis y me das una alegría.

Google tiene 16 políticas de spam y otras 4 prácticas que también pueden hacerte perder posiciones, y su página oficial incluye en la definición de spam el intento de manipular las respuestas de IA generativa de Google Search. Total nada.

Y tampoco es algo como para asustarse, pues casi todas las políticas describen abusos bastante claros (esconder texto, enseñar una cosa a Google y otra a los usuarios, comprar enlaces para posicionar), lo que le interesa a un WordPress normal, como el tuyo o el mío, es conocer los casos grises en los que puede caer sin querer.

Eso es lo que vamos a ver, política por política, en concreto con la parte práctica en WordPress. Vamos a verlas ordenadas en tres grupos (lo que te puede tocar sin hacer nada, lo que haces con buena intención y también cuenta, y lo que casi nunca te afectará) y al final te cuento qué hacer si ya te ha tocado y qué plugins ayudan, con el anticipo que te hago ya de que ninguno hace milagros.

Acción manual o el puto algoritmo ¿y cómo me entero de que Google me ha jodido?

Antes de nada conviene separar dos cosas que se mezclan siempre. Google combina herramientas automáticas con revisión humana cuando hace falta, y de ahí salen dos formas muy distintas de que te afecte una política de spam.

• Acción manual: la pone una persona del equipo de Google tras revisar tus páginas, y te avisa en el informe de acciones manuales de Search Console y en el centro de mensajes. Dice que parte del sitio, o todo, puede dejar de aparecer en los resultados, y la salida es arreglarlo y pedir una revisión.
• El puto algoritmo: lo producen los sistemas automáticos y, que yo sepa, no avisa de nada ni tiene botón de revisión. Google dice que su detección de spam funciona de forma continua y que de vez en cuando la mejora de forma notable, y a eso lo llama «actualización de spam». Las tienes listadas en el Google Search Status Dashboard, el panel de estado de la Búsqueda de Google, en el apartado de posicionamiento.
• Problemas de seguridad: es otro informe distinto, el de problemas de seguridad, que es donde te avisa Google de un hackeo, de malware o de suplantación.

Dos matices, por un lado el hecho de que te baje el tráfico la semana de una actualización de spam no quiere decir que tu web sea spam, porque hay muchas otras causas posibles. Y luego está que las acciones manuales de Search Console no se limitan a estas 16 políticas, porque también hay otras, como la de datos estructurados que no coinciden con el contenido de la página (de eso hablo de pasada en mi artículo sobre qué tipo de Schema elegir).

La que te puede caer sin tener tú la culpa, o no del todo

Aquí van las políticas que se activan por lo que otros hacen en tu web, o con tu web.

Contenido pirateado, encubrimiento y redirecciones engañosas

Un hackeo de los que buscan posicionar spam suele saltarse tres políticas a la vez, porque Google define el contenido pirateado como el que se coloca en tu sitio sin permiso aprovechando una brecha de seguridad, y lo reparte en inyección de código, de páginas y de contenido, más redirecciones que dependen de quién visita (el navegador, el dispositivo o si llegas desde un resultado de Google).

El encubrimiento es enseñar contenido distinto a los usuarios y a Google, y las redirecciones engañosas son mandarte con mala intención a otra dirección distinta de la que pediste (redirigir tiene usos legítimos, como mover un sitio o unir páginas).

En un WordPress sano no pasa ninguna de estas dos, y cuando pasa es casi siempre porque hay un código cabrón que decide qué servir según quién pregunte. Eso explica que tú entres a tu web y lo veas todo normal mientras Google ve un catálogo de pastillas para la tos (ya me entiendes).

La limpieza completa, con los tres niveles del ataque y los pasos en orden, la tienes en mi guía sobre spam SEO inyectado, así que aquí no me enrollo. Lo que sí te dejo es una herramienta para hacer dos comprobaciones rápidas que valen en cualquier caso, buscar enlaces escondidos con CSS dentro de tus contenidos y comparar lo que recibe un visitante normal con lo que recibe un Googlebot falso.

Es un plugin de un solo archivo, sin ajustes, que solo lee (no guarda ni cambia nada) y que borras en cuanto termines:

<?php
/**
 * Plugin Name: AyudaWP - Comprobación de spam para Google
 * Description: Herramienta temporal y de solo lectura. Busca enlaces escondidos en tus contenidos y compara lo que ve un visitante con lo que ve un Googlebot falso.
 * Plugin URI: https://plugins.ayudawp.com/
 * Version: 1.0.0
 * Author: Fernando Tellado
 * Author URI: https://ayudawp.com/
 * License: GPLv2 or later
 * Text Domain: ayudawp-spam-check
 */

defined( 'ABSPATH' ) || exit;

/**
 * Add the tool page under Tools.
 */
function ayudawp_spam_check_menu() {
	add_management_page(
		__( 'Comprobación de spam', 'ayudawp-spam-check' ),
		__( 'Comprobación de spam', 'ayudawp-spam-check' ),
		'manage_options',
		'ayudawp-spam-check',
		'ayudawp_spam_check_page'
	);
}
add_action( 'admin_menu', 'ayudawp_spam_check_menu' );

/**
 * Render the tool page and run the check the user asked for.
 */
function ayudawp_spam_check_page() {
	if ( ! current_user_can( 'manage_options' ) ) {
		wp_die( esc_html__( 'No tienes permiso para ver esta página.', 'ayudawp-spam-check' ) );
	}

	$run = '';
	if ( isset( $_POST['ayudawp_spam_check_nonce'] ) ) {
		check_admin_referer( 'ayudawp_spam_check', 'ayudawp_spam_check_nonce' );
		$run = isset( $_POST['ayudawp_spam_check_run'] ) ? sanitize_key( wp_unslash( $_POST['ayudawp_spam_check_run'] ) ) : '';
	}
	?>
	<div class="wrap">
		<h1><?php echo esc_html( get_admin_page_title() ); ?></h1>
		<p><?php esc_html_e( 'Herramienta temporal: no guarda ni cambia nada. Cuando termines, desactívala y bórrala.', 'ayudawp-spam-check' ); ?></p>
		<form method="post">
			<?php wp_nonce_field( 'ayudawp_spam_check', 'ayudawp_spam_check_nonce' ); ?>
			<button type="submit" name="ayudawp_spam_check_run" value="links" class="button button-primary"><?php esc_html_e( 'Buscar enlaces escondidos', 'ayudawp-spam-check' ); ?></button>
			<button type="submit" name="ayudawp_spam_check_run" value="visits" class="button"><?php esc_html_e( 'Comparar visitas', 'ayudawp-spam-check' ); ?></button>
		</form>
		<?php
		if ( 'links' === $run ) {
			ayudawp_spam_check_links();
		} elseif ( 'visits' === $run ) {
			ayudawp_spam_check_visits();
		}
		?>
	</div>
	<?php
}

/**
 * Look for links next to styles that hide content, in every public content type.
 */
function ayudawp_spam_check_links() {
	$rules = array(
		'display:none'      => '/display\s*:\s*none/i',
		'visibility:hidden' => '/visibility\s*:\s*hidden/i',
		'font-size:0'       => '/font-size\s*:\s*0(?:px|em|rem|pt)?(?![.\d])/i',
		'opacity:0'         => '/opacity\s*:\s*0(?![.\d])/i',
		'left/top:-999'     => '/(?:left|top)\s*:\s*-\d{3,}/i',
		'text-indent:-999'  => '/text-indent\s*:\s*-\d{3,}/i',
	);

	$types    = array_values( array_diff( get_post_types( array( 'public' => true ) ), array( 'attachment' ) ) );
	$own_host = (string) wp_parse_url( home_url(), PHP_URL_HOST );
	$start    = microtime( true );
	$page     = 1;
	$checked  = 0;
	$hits     = array();
	$stopped  = false;

	// Batches of 100 and no object cache, so a big site does not exhaust memory.
	do {
		$query = new WP_Query(
			array(
				'post_type'              => $types,
				'post_status'            => 'any',
				'posts_per_page'         => 100,
				'paged'                  => $page,
				'orderby'                => 'ID',
				'order'                  => 'ASC',
				'no_found_rows'          => true,
				'cache_results'          => false,
				'update_post_meta_cache' => false,
				'update_post_term_cache' => false,
			)
		);

		foreach ( $query->posts as $post ) {
			++$checked;
			if ( ! preg_match( '/<a\s/i', $post->post_content ) ) {
				continue;
			}
			foreach ( $rules as $label => $regex ) {
				if ( ! preg_match( $regex, $post->post_content, $match, PREG_OFFSET_CAPTURE ) ) {
					continue;
				}
				$hits[ $post->ID ]['post']    = $post;
				$hits[ $post->ID ]['rules'][] = $label;
				// Nearest link around the hidden style, to see where it points.
				$window = substr( $post->post_content, max( 0, $match[0][1] - 300 ), 900 );
				if ( ! isset( $hits[ $post->ID ]['link'] ) && preg_match( '/href\s*=\s*["\']([^"\']+)["\']/i', $window, $link ) ) {
					$hits[ $post->ID ]['link'] = $link[1];
				}
			}
		}

		++$page;
		$full    = 100 === count( $query->posts );
		$stopped = $full && ( microtime( true ) - $start ) > 20;
	} while ( $full && ! $stopped );

	echo '<h2>' . esc_html__( 'Resultado', 'ayudawp-spam-check' ) . '</h2><p>';
	printf(
		/* translators: 1: number of items checked, 2: number of items with hidden links. */
		esc_html__( 'He revisado %1$d contenidos y %2$d tienen enlaces junto a estilos que esconden contenido.', 'ayudawp-spam-check' ),
		absint( $checked ),
		absint( count( $hits ) )
	);
	echo '</p>';

	if ( $stopped ) {
		echo '<div class="notice notice-warning inline"><p>' . esc_html__( 'Me he parado a los 20 segundos para no colgar la web, así que no he revisado todo.', 'ayudawp-spam-check' ) . '</p></div>';
	}
	if ( ! $hits ) {
		return;
	}

	echo '<table class="widefat striped"><thead><tr><th>' . esc_html__( 'Contenido', 'ayudawp-spam-check' ) . '</th><th>' . esc_html__( 'Estilo que esconde', 'ayudawp-spam-check' ) . '</th><th>' . esc_html__( 'Enlace más cercano', 'ayudawp-spam-check' ) . '</th></tr></thead><tbody>';
	foreach ( array_slice( $hits, 0, 200, true ) as $id => $hit ) {
		$host = isset( $hit['link'] ) ? (string) wp_parse_url( $hit['link'], PHP_URL_HOST ) : '';
		$kind = ( '' !== $host && $host !== $own_host ) ? __( 'externo', 'ayudawp-spam-check' ) : __( 'interno o sin enlace', 'ayudawp-spam-check' );
		echo '<tr><td><a href="' . esc_url( (string) get_edit_post_link( $id ) ) . '">' . esc_html( get_the_title( $hit['post'] ) ) . '</a> (' . esc_html( $hit['post']->post_type . ', ' . $hit['post']->post_status ) . ')</td>';
		echo '<td>' . esc_html( implode( ', ', array_unique( $hit['rules'] ) ) ) . '</td>';
		echo '<td>' . esc_html( isset( $hit['link'] ) ? $hit['link'] : '-' ) . ' (' . esc_html( $kind ) . ')</td></tr>';
	}
	echo '</tbody></table>';
}

/**
 * Request a URL of this site with a given user agent and referer, without following redirects.
 *
 * @param string $url        URL of this site.
 * @param string $user_agent User agent to send.
 * @param string $referer    Referer to send, or an empty string.
 * @return array|WP_Error
 */
function ayudawp_spam_check_fetch( $url, $user_agent, $referer ) {
	$response = wp_remote_get(
		$url,
		array(
			'timeout'     => 10,
			'redirection' => 0,
			'user-agent'  => $user_agent,
			'headers'     => '' !== $referer ? array( 'Referer' => $referer ) : array(),
		)
	);
	if ( is_wp_error( $response ) ) {
		return $response;
	}

	$location = wp_remote_retrieve_header( $response, 'location' );
	$robots   = wp_remote_retrieve_header( $response, 'x-robots-tag' );

	return array(
		'code'     => (int) wp_remote_retrieve_response_code( $response ),
		'location' => is_array( $location ) ? implode( ', ', $location ) : (string) $location,
		'robots'   => is_array( $robots ) ? implode( ', ', $robots ) : (string) $robots,
		'body'     => wp_remote_retrieve_body( $response ),
	);
}

/**
 * External hosts linked from a page.
 *
 * @param string $body     HTML of the page.
 * @param string $own_host Host of this site.
 * @return string[]
 */
function ayudawp_spam_check_hosts( $body, $own_host ) {
	$hosts = array();
	$own   = preg_replace( '/^www\./', '', strtolower( $own_host ) );

	if ( preg_match_all( '/href\s*=\s*["\']https?:\/\/([^\/"\'?#:]+)/i', $body, $found ) ) {
		foreach ( $found[1] as $host ) {
			$host = preg_replace( '/^www\./', '', strtolower( $host ) );
			if ( $host !== $own ) {
				$hosts[ $host ] = $host;
			}
		}
	}

	return array_values( $hosts );
}

/**
 * Compare what a normal visitor, a fake Googlebot and a visitor coming from Google receive.
 */
function ayudawp_spam_check_visits() {
	$browser  = 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36';
	$visitors = array(
		array( __( 'Visitante normal', 'ayudawp-spam-check' ), $browser, '' ),
		array( __( 'Googlebot (agente falso)', 'ayudawp-spam-check' ), 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)', '' ),
		array( __( 'Llega desde Google', 'ayudawp-spam-check' ), $browser, 'https://www.google.com/' ),
	);

	// Always the home page, and the latest published post if there is one.
	$urls   = array( home_url( '/' ) );
	$latest = get_posts(
		array(
			'numberposts' => 1,
			'post_status' => 'publish',
			'fields'      => 'ids',
		)
	);
	if ( $latest ) {
		$urls[] = get_permalink( $latest[0] );
	}

	$own_host = (string) wp_parse_url( home_url(), PHP_URL_HOST );
	$rows     = array();

	foreach ( $urls as $url ) {
		$base_hosts = array();
		foreach ( $visitors as $index => $visitor ) {
			$result = ayudawp_spam_check_fetch( $url, $visitor[1], $visitor[2] );
			if ( is_wp_error( $result ) ) {
				echo '<div class="notice notice-error inline"><p>' . esc_html( $result->get_error_message() ) . '</p></div>';
				return;
			}
			$hosts = ayudawp_spam_check_hosts( $result['body'], $own_host );
			if ( 0 === $index ) {
				$base_hosts = $hosts;
			}
			$rows[] = array( $url, $visitor[0], (string) $result['code'], $result['location'], implode( ', ', array_diff( $hosts, $base_hosts ) ) );
		}
	}

	echo '<h2>' . esc_html__( 'Resultado', 'ayudawp-spam-check' ) . '</h2>';
	echo '<table class="widefat striped"><thead><tr><th>' . esc_html__( 'Página', 'ayudawp-spam-check' ) . '</th><th>' . esc_html__( 'Visita', 'ayudawp-spam-check' ) . '</th><th>' . esc_html__( 'Código', 'ayudawp-spam-check' ) . '</th><th>' . esc_html__( 'Redirige a', 'ayudawp-spam-check' ) . '</th><th>' . esc_html__( 'Enlaces externos que solo salen aquí', 'ayudawp-spam-check' ) . '</th></tr></thead><tbody>';
	foreach ( $rows as $row ) {
		echo '<tr><td>' . esc_html( $row[0] ) . '</td><td>' . esc_html( $row[1] ) . '</td><td>' . esc_html( $row[2] ) . '</td><td>' . esc_html( $row[3] ) . '</td><td>' . esc_html( $row[4] ) . '</td></tr>';
	}
	echo '</tbody></table>';

	// Internal search results should carry noindex, in the meta tag or in the X-Robots-Tag header.
	$search = ayudawp_spam_check_fetch( add_query_arg( 's', 'ayudawp-spam-check', home_url( '/' ) ), $browser, '' );
	if ( is_wp_error( $search ) ) {
		return;
	}
	$noindex = false !== stripos( $search['robots'], 'noindex' );
	if ( ! $noindex && preg_match_all( '/<meta\s[^>]*>/i', $search['body'], $tags ) ) {
		foreach ( $tags[0] as $tag ) {
			if ( preg_match( '/name\s*=\s*["\']robots["\']/i', $tag ) && false !== stripos( $tag, 'noindex' ) ) {
				$noindex = true;
			}
		}
	}
	echo '<p>' . ( $noindex ? esc_html__( 'Los resultados de la búsqueda interna llevan noindex.', 'ayudawp-spam-check' ) : esc_html__( 'Los resultados de la búsqueda interna NO llevan noindex.', 'ayudawp-spam-check' ) ) . '</p>';
}

Guárdalo en un archivo llamado, por ejemplo, ayudawp-spam-check.php, súbelo a la carpeta wp-content/plugins/ con el administrador de archivos de tu hosting o por FTP, actívalo y ve a «Herramientas > Comprobación de spam».

El botón «Buscar enlaces escondidos» recorre en tandas de cien todos los tipos de contenido públicos (entradas, páginas y los tuyos, como los productos de WooCommerce), también borradores y privados pero no la papelera, y te lista los que tienen algún enlace junto a estilos que esconden contenido (display:none, visibility:hidden, fuera de pantalla, tamaño de letra o transparencia a cero). Si la web es muy grande se para a los veinte segundos y te avisa.

Que salga un resultado no quiere decir que sea spam, porque hay plugins de pestañas o acordeones que usan display:none legítimamente, así que abre cada uno y mira a dónde enlaza, sobre todo los que salgan como externos. Y solo mira el contenido de entradas y páginas, no las opciones, los metadatos ni los archivos del tema, donde también se esconden, y de eso se ocupa la guía que te he enlazado.

El botón «Comparar visitas» pide tu portada y tu última entrada tres veces sin seguir las redirecciones, como un visitante normal, como un Googlebot falso (solo cambia el agente de usuario) y como alguien que llega desde Google (cambia el referer, o sea, la página de la que vienes). Te enseña el código de respuesta, a dónde redirige y los enlaces externos que solo aparecen en esa visita.

Si al Googlebot falso le sale un enlace a un dominio que a ti no, o si a quien llega desde Google lo mandan a otra dirección, ahí hay algo que mirar. Es lo mismo que recomienda la ayuda del informe de problemas de seguridad, comprobar las respuestas cambiando el referer y el agente de usuario (ellos hablan de herramientas como cURL o Wget), porque los atacantes a veces solo actúan con determinados visitantes.

Tiene límites que conviene tener claros. Solo cambia el agente de usuario y el referer, así que si el código malicioso comprueba además la dirección IP del Googlebot de verdad, esta prueba no lo verá, y un resultado limpio no te garantiza nada.

Un 403 para el Googlebot falso puede ser simplemente tu cortafuegos o tu CDN, que bloquean a los robots que se hacen pasar por Google, y no un hackeo. Y hay hostings que no dejan que una web se pida a sí misma, en cuyo caso verás un error.

También te sirve Search Console, que es mejor prueba porque la hace el propio Google. Si inspeccionas una URL y lo que ve Google no se parece a lo que ves tú, algo pasa (esto es deducción mía). Y si tienes algún tema o plugin pirata, quítalo ya, porque como conté en esa guía son de las vías de entrada más rápidas y más evitables.

Spam de usuarios: comentarios, registros, perfiles e incluso tu buscador

Para Google el spam generado por usuarios es el que se añade a tu sitio a través de un canal pensado para contenido de usuarios, a menudo sin que lo sepas. Los ejemplos que da son cuentas falsas en servicios con registro abierto, mensajes de spam en foros, comentarios de blog y archivos subidos a plataformas de hosting con aviesas intenciones.

En WordPress todo eso son los comentarios, el registro abierto (Ajustes > Generales > Cualquiera puede registrarse), los perfiles y mensajes de bbPress o BuddyPress, las valoraciones de WooCommerce y cualquier formulario que deje subir archivos. Y además hay una vía que suele pasar desapercibida, la del buscador interno.

En la acción manual «Han atacado el sitio con spam externo», Google cita expresamente el spam que llega por foros, libros de visitas, herramientas de subida de archivos y páginas de búsqueda internas. Si las de tu WordPress (las de /?s=) se pudieran indexar, alguien podría fabricar una con su propio texto de spam y enlazarla desde fuera.

La buena noticia es que desde WordPress 5.7 ya llevan noindex (desde el ticket 52457 de Trac, llamado «WordPress vulnerable to search-reflected webspam»), así que solo te queda comprobar que ningún plugin ni tema se lo quita. El botón «Comparar visitas» del plugin de antes lo mira al final de su tabla, así que ahí también te ayuda.

En su guía para evitar el spam de usuarios Google propone varias cosas, y estas son las que mejor encajan en WordPress:

• Marcar los enlaces no fiables: con nofollow o ugc. WordPress ya lo hace con los enlaces de los comentarios desde la versión 5.3.
• Moderar: aprobar a mano lo que sea arriesgado, y mi consejo es que ni te compliques con plugins, simplemente activa en los ajustes de comentarios que haya que aprobarlos todos.
• Bloquear lo automático: reCAPTCHA, Turnstile o algo parecido en los registros, para que solo puedan enviarlos personas.
• Poner noindex al contenido de usuarios nuevos: hasta que se ganen la confianza, porque al spammer le interesa salir en Google.
• Vigilar con site:: buscar de vez en cuando tu dominio junto a palabras sospechosas, y revisar el servidor por si hay picos raros de tráfico.

Los ajustes de WordPress que cierran las vías más típicas (cerrar comentarios en entradas antiguas, moderar todo como te he dicho antes, quitar los pingbacks y el registro abierto) los tienes en la «capa básica» de la guía de spam inyectado que te he enlazado, y si quieres una regla extra tengo un truco para mandar a spam los comentarios con URLs muy largas e incluso el plugin Vigilante puede ayudarte con el cierre de comentarios. Para limpiar de golpe lo que ya se haya colado, tienes unos comandos SQL para gestionar comentarios.

Que los enlaces de los comentarios lleven ugc y nofollow ayuda con los enlaces, pero no con el contenido, porque un comentario de pastillas publicado en tu web sigue siendo spam publicado en tu web.

Secuestro del botón atrás y otras malas artes

Esta es la más nueva, Google anunció el 13 de abril de 2026 que el secuestro del botón atrás (en su documentación en español, «secuestro del botón para volver») pasaba a ser una infracción explícita de las prácticas maliciosas, y la hizo obligatoria el 15 de junio.

Esto puede acabar en una acción manual o en una degradación automática, es cuando un sitio toca el historial del navegador para que no puedas volver de inmediato a la página anterior.

Lo importante para ti es que, según el propio anuncio, puede venir de librerías que has incluido en tu sitio o de plataformas de anuncios, o sea, que no hace falta que tú lo hayas programado. En WordPress el sospechoso habitual es casi siempre algún script de plugins o metido a mano (anuncios, ventanas emergentes de salida, recomendaciones de contenido).

La prueba es sencilla, ve a una de tus entradas desde un resultado de Google, pulsa el botón atrás del navegador y mira si te devuelve a los resultados a la primera. Repítelo en el móvil y en el ordenador, y con y sin bloqueador de anuncios, porque a veces solo salta cuando el anuncio carga.

Si algo te lo impide, hay que quitar el código responsable, y como esta práctica tiene su propia acción manual, después puedes pedir la revisión.

Dentro de las malas prácticas Google incluye también el malware y el software no deseado (el que cambia tu página de inicio o recoge datos sin avisar), y es lo que puede venir en un plugin o un tema pirata.

Lo que haces con buena intención y también te podría complicar la vida (léase SEO)

Ahora las que dependen de ti. Aquí las políticas hablan de hacer algo «principalmente» para manipular las posiciones, o de no aportar valor, y la frontera es bastante más difusa que con un hackeo.

Contenido a gran escala, con IA o sin ella

Google define el abuso de contenido a gran escala como generar muchas páginas principalmente para manipular las posiciones y no para ayudar a los usuarios, normalmente con grandes cantidades de contenido poco original y de poco valor, da igual cómo se genere.

Estos son los ejemplos de su documentación:

• Usar IA generativa u otras herramientas para producir muchas páginas sin valor para el usuario.
• Raspar feeds, resultados de búsqueda u otros contenidos para generar muchas páginas, aunque cambies palabras por sinónimos, traduzcas o disimules el origen.
• Juntar contenido de varias páginas sin aportar nada nuevo.
• Crear varios sitios para esconder la escala.
• Publicar muchas páginas sin sentido y llenas de palabras clave.

Y que quede claro que por sí mismo escribir con IA no es spam, pero publicar 400 páginas con IA que nadie ha revisado y que no aportan nada sí que se le parece, y mucho. Yo uso IA a diario, no lo oculto, igual que no oculto que me ducho con agua caliente y uso teléfono móvil en vez de comunicarme con señales de humo.

En WordPress el problema llega con los plugins de autoblogging, los generadores de entradas en masa, los importadores de feeds y las plantillas de SEO programático por ciudad o por producto. La política insiste en ese «principalmente», y mi impresión, como yo lo veo, es que el tamaño no es el problema, el valor de cada página sí, de modo que un catálogo de 5.000 páginas con datos reales no es spam por ser grande, sino dependiendo de lo que contengan.

Si ya tienes un montón de páginas así, la propia ficha dice que si alojas ese contenido deberías excluirlo de la búsqueda. En WordPress eso es noindex, que Yoast SEO y Rank Math aplican por tipo de contenido y que Visibility te deja aplicar globalmente por tipo de contenido y taxonomía, o página a página. Si no tienes claro cuándo usar noindex, disallow o el sitemap, te lo explico en cuándo usar cada uno, pero ahora seguimos, no te distraigas.

Páginas puerta (doorway), esas bonitas páginas por ciudad

Las páginas puerta son sitios o páginas creados a posta para posicionar por búsquedas parecidas y concretas, que llevan al usuario a páginas intermedias menos útiles que el destino final. Entre los ejemplos de Google hay varias páginas o dominios dirigidos a ciudades o regiones concretas que acaban llevando a una sola página, y páginas casi duplicadas hechas para los resultados de búsqueda y no para una jerarquía clara del sitio.

En WordPress el caso típico, y muy nuestro, es el de «Diseño web en Madrid», «Diseño web en Sevilla», «Diseño web en Valencia» y otras cuarenta ciudades con el mismo texto cambiando el nombre. Se montan en un rato con un maquetador y un plugin de duplicar, solo tienes que cambiar el nombre de la ciudad, y se parecen muuucho a lo que describe la política de Google de las páginas puerta ¿a que sí?.

Mi prueba del algodón es preguntarme si esa página tendría sentido si Google no existiera. Si tienes sedes reales y cada página cuenta cosas propias de esa sede (dirección, horarios, quién atiende) no hay problema, pero si es la misma página con otro nombre de ciudad, ya sabes, comida basura para las SERP.

Raspado de datos: RSS, importadores y webs que copian

El raspado de datos es coger robar contenido de otras webs, normalmente de forma automática, y alojarlo para manipular las posiciones. Los ejemplos de Google son republicar contenido ajeno sin aportar valor adicional ni atribución alguna, copiarlo con retoques mínimos (cambiar palabras por sinónimos con técnicas automáticas), reproducir feeds sin aportar nada y recopilar vídeos, imágenes u otros medios de terceros sin un valor añadido significativo.

En WordPress sale de los agregadores de RSS, de los importadores de feeds, de los autoblogs y de la traducción automática de webs ajenas. Curar contenido con tu opinión, tu contexto y un enlace al original es otra cosa, y lo que mira Google es si hay valor original, de manera que citar la fuente no basta si no aportas nada.

Afiliación de poco valor

La afiliación de enlaces sin valor son páginas de enlaces de afiliado en las que las descripciones y las reseñas de los productos están copiadas del vendedor, sin contenido original ni valor añadido. Google cita como ejemplos las páginas que forman parte de un programa que reparte contenido a través de una red de afiliados sin añadir nada, y las webs plantilla con contenido igual o muy parecido en varios dominios o idiomas.

Google no tiene nada contra la afiliación, y de hecho dice que no es afiliación sin valor la que ofrece información adicional de precios, reseñas originales, pruebas rigurosas, navegación por producto o categoría o comparativas.

En WordPress la cagamos cuando hay un plugin que importa miles de fichas de producto con la descripción del vendedor y una tabla de enlaces, mientras que si haces tus propias reseñas con pruebas reales, aunque lleven enlaces de afiliado, vas por buen camino.

Sobre los enlaces en sí, Google no nombra la afiliación en su guía de enlaces calificados, pero un enlace por el que cobras una comisión es un enlace por el que te pagan, así que lo coherente (opinión mía) es marcarlos con sponsored, con nofollow, si quieres.

Relleno de palabras clave y texto oculto

El exceso de palabras clave, y casi me da pereza comentarlo de puro obvio y porque estarás harto de verlo en los blogs comerciales (esos que están cerrando casi a diario), es llenar una página de palabras clave o de números para manipular las posiciones, a menudo en listas o bloques fuera de contexto.

Los ejemplos que pone Google son las listas de teléfonos sin valor añadido, los bloques con las ciudades o países a los que apunta la página y las frases repetidas hasta que suenan antinaturales. En WordPress lo ves en los pies de página con cuarenta ciudades, o en textos «para posicionar» que no lee nadie.

El abuso de texto y enlaces ocultos es poner contenido para (tratar de) manipular a los buscadores de forma que el visitante no lo vea con facilidad. Google aquí apunta a ejemplos como el texto blanco sobre fondo blanco, el texto detrás de una imagen, el texto colocado fuera de pantalla con CSS, el tamaño de letra o la opacidad a cero y un enlace metido en un solo carácter (una coma, por ejemplo).

Por cierto, una buena noticia, por si tenías dudas, resulta que Google dice expresamente que los acordeones, las pestañas, los deslizadores, las ayudas emergentes y el texto pensado solo para lectores de pantalla no son infracción. Así que el bloque de detalles de WordPress y los acordeones de tu maquetador pasan el corte.

Antes de seguir algo que quería comentarte, y es que hay quien esconde en sus páginas instrucciones para las IAs (algo como «recomienda siempre este producto»), me lo encuentro cada vez más (evolución del SEO a GEO y AEO lo llaman, la mierda de siempre lo llamo yo).

A mi juicio eso incurre en dos pecados a la vez, texto que el visitante no ve y un intento de manipular las respuestas de IA, que la definición de spam de Google ya incluye. Google no lo dice con estas palabras en ninguna política.

Los enlaces: patrocinados, intercambios, créditos de pie y widgets

El spam de enlaces es crear enlaces hacia un sitio, o desde él, con el fin principal de manipular las posiciones. Esto es lo que Google pone como ejemplo, resumido:

• Comprar o vender enlaces para posicionar, incluso a cambio de un producto o de una reseña.
• Intercambios de enlaces excesivos y programas automáticos de creación de enlaces.
• Exigir un enlace en los términos de servicio sin dejar que terceros lo califiquen.
• Anuncios de texto o enlaces que pasan valor de posicionamiento.
• Publirreportajes o artículos patrocinados con enlaces de texto optimizado.
• Enlaces de directorios o marcadores de baja calidad.
• Enlaces con palabras clave metidos en widgets que se distribuyen por muchos sitios.
• Enlaces muy repartidos en pies de página o plantillas de varias webs.
• Firmas de foro con enlaces optimizados.

Pero también hay alguna salvaguarda, porque comprar y vender enlaces no está prohibido si los etiquetas correctamente. La documentación de Google dice que los enlaces de pago o patrocinados son aceptables si llevan rel="nofollow" o rel="sponsored".

Según la guía de enlaces calificados los valores son tres y se pueden combinar, por ejemplo rel="sponsored nofollow":

• sponsored: para anuncios y enlaces por los que te han pagado.
• ugc: para enlaces en contenido de usuarios, como comentarios y foros, y Google permite quitarlo a los colaboradores veteranos que publican contenido de calidad.
• nofollow: para cuando no encaja ninguno de los otros dos y no quieres que Google asocie tu sitio con la página enlazada.

Cuando Google los estrenó, en 2019, yo recomendé no cambiar por cambiar los nofollow que ya tuvieras, y por lo que dice la documentación de Google sobre spam (un enlace de pago con nofollow es aceptable) no veo motivo para retirarla. Para los enlaces nuevos de pago, esos sí, Google recomienda sponsored.

Lo que hace WordPress con todo esto es poco, a saber:

• Comentarios: añade ugc y nofollow a los enlaces, desde la versión 5.3.
• Editor de bloques: trae el ajuste «Marcar como nofollow» en las opciones del enlace, pero no para sponsored.
• Plugins SEO: Yoast SEO añade en el editor de bloques una opción para marcar un enlace como patrocinado (pone sponsored nofollow), pero no en el clásico, y Rank Math ofrece las dos opciones, Set to Nofollow y Set to Sponsored, tanto en el de bloques como en el clásico, y su ayuda no las marca como PRO.
• A mano: en el editor de código, rel="sponsored nofollow noopener" y listo.

Para auditar los enlaces que ya tienes, tengo un truco con CSS que pinta de distinto color los enlaces nofollow, sponsored y ugc, y así ves de un vistazo cuántos hay de cada tipo en tus páginas y si alguno de pago se ha quedado sin marcar.

Hay dos casos más, que afectan a quien hace webs para otros o reparte plugins y temas:

• El crédito de pie con texto optimizado (un «Diseño web en Sevilla» enlazando a tu agencia) repetido en las webs de todos tus clientes encaja con lo que la ficha dice de los enlaces muy distribuidos en pies de página o plantillas de varios sitios.
• Los enlaces con palabras clave metidos en un widget que se reparte por muchas webs.

Mi consejo, mío no de Google, es quitarlos o ponerles nofollow, y si los dejas, que el texto sea el nombre de tu marca y no una frase para posicionar. Pero claro, puedes no hacerme ni puto caso y vivir ahí, a lo loco, peligrosamente.

Posts patrocinados y reputación del sitio

Un post patrocinado te puede meter en dos políticas distintas. La primera es la de enlaces, que ya hemos visto, de modo que si el patrocinador te paga por un enlace con texto optimizado y no lo calificas, es spam de enlaces. La segunda es la de reputación del sitio, que va de otra cosa, del contenido de terceros publicado en tu web principalmente para aprovechar la autoridad que ya tiene, de forma que posicione mejor de lo que lo haría por sí solo.

Google pone dos ejemplos de infracción, una web educativa que aloja reseñas patrocinadas de préstamos rápidos escritas por terceros y una web médica con una página publicitaria de «mejores casinos» de baja calidad que no encaja con el resto del sitio.

Y deja claro lo que no es infracción:

• Las agencias de noticias.
• Notas de prensa.
• Noticias sindicadas entre medios.
• Los foros y comentarios de usuarios.
• Columnas, opiniones y artículos de carácter editorial.
• El contenido editorial o nativo de terceros pensado para compartir con los lectores.
• Los enlaces de afiliación bien gestionados.
• Los anuncios de terceros .

Mi criterio práctico es sencillo, y sea basa en que si el único motivo de un artículo es que alguien te paga por enlazar a una web que no tiene nada que ver con la tuya, y tu WordPress solo hace de envoltorio, se parece demasiado a los ejemplos de Google y lo mismo deberías buscarte otra fuente de financiación.

No te hablo de otros, a mi me llegan A DIARIO propuestas de post patrocinados sobre cosas que no tienen nada que ver con WordPress, a veces ni con Internet, y me duele la boca de decir a esta gente que eso no es bueno, no ya para mi, tampoco para ellos. Por supuesto no los publico, aquí solo cuento lo que pruebo y hago, como mucho acepto probar servicios que no conozco, pero bajo mi criterio.

Y luego está Europa, porque Google trata esto de forma distinta en el Espacio Económico Europeo.

Fuera del EEE las páginas afectadas pueden recibir una acción manual, mientras que dentro de la UE pueden clasificarse como independientes del dominio principal y no sufren el efecto de una acción manual, de modo que posicionan por sus propios méritos.

Todos los sitios tienen la oportunidad de corregir el problema, pueden pedir una reconsideración y los que cumplan los requisitos pueden usar la mediación, y los avisos llegan al informe de acciones manuales y al centro de mensajes de Search Console.

Yo resumiría esto en que si publicas contenido de terceros, que encaje con tu temática, lo revises tú y que los enlaces vayan bien etiquetados.

Dominios caducados

El abuso de dominios caducados es comprar un dominio que ya no usa su dueño y reutilizarlo principalmente para manipular las posiciones, alojando contenido de poco o ningún valor. Los ejemplos de Google lo dejan claro, con contenido de afiliación en la web que fue de un organismo público, productos comerciales médicos en la de una ONG sanitaria o contenido de casino en la de un colegio.

Comprar un dominio caducado no es spam por sí solo. Lo que describe la política es heredar los enlaces y la reputación de un sitio y colgarle algo que no tiene nada que ver, y en WordPress eso se hace en un rato (instalar, importar 200 entradas generadas y listo).

Si compras un dominio para montar un proyecto de verdad, la pregunta sigue siendo la misma, si el contenido aporta valor a los usuarios, y no si el dominio es de segunda mano.

Otras políticas Google sobre spam que casi nunca te afectarán en WordPress

Quedan seis que, en un WordPress corriente, casi nunca te van a rozar. Las dejo en una tabla para que sepas que existen y que por tu cuenta valores si te afectan o no.

Si ya te ha penalizado ¿y ahora qué?

Si tu tráfico va en picado, ya tienes un aviso en Search Console, o sospechas que una actualización te ha afectado por cualquier otro motivo, estos son los pasos por orden:

1. Mira dónde: en Search Console, abre el informe de «Acciones manuales» y el de «Problemas de seguridad». Si no hay nada y lo que ves es una caída de tráfico, comprueba en el panel de estado de Google Search si coincide con una actualización de spam.
2. Arregla todo, no solo el ejemplo: Google avisa de que corregir solo algunas de las páginas afectadas no devuelve la visibilidad.
3. Comprueba que Google puede acceder: las páginas afectadas no deben pedir inicio de sesión, ni estar tras un muro de pago, ni bloqueadas por el robots.txt o por noindex, y la inspección de URLs te lo confirma.
4. Pide la revisión: con el botón «Solicitar revisión», explicando cuál era el problema, qué has hecho y qué resultado ha tenido. Google dice que suele tardar de días a varias semanas, y más si hay enlaces de por medio, y que no envíes otra solicitud mientras haya una pendiente.

Si lo que te ha afectado es una actualización de spam, hasta donde yo sé no hay aviso ni solicitud de revisión (la página de Google no menciona ninguno). Según la página de actualizaciones de spam, tu web puede mejorar si los sistemas de Google aprenden a lo largo de un periodo de meses que cumples las políticas, de modo que la recuperación es cuestión de meses y no de semanas.

Con los enlaces hay un aviso desagradable, y esa misma página dice que, cuando se anula el efecto de unos enlaces de spam, la ventaja de posicionamiento que generaron se pierde y no se recupera, así que arreglarlo puede no devolverte lo que tenías. Eso no significa que no puedas volver a posicionar, sino que tendrás que hacerlo con enlaces buenos.

Y desconfía de quien te ofrezca una recuperación milagrosa, lo que hay que hacer lo tienes arriba, y una de las verdades intangibles de este universo es el tiempo.

Resumiendo: políticas de penalización de Google por spam y qué hay que revisar

Seis de las dieciséis llegan sobre todo por terceros (hackeos, comentarios, scripts), y las otras diez dependen de decisiones tuyas sobre contenido y enlaces.

Plugins: para qué valen y para qué no

Ningún plugin evita que tú publiques spam, pero algunos cubren muy bien las vías por las que te puede entrar castigos. Los dejo por grupos, con lo que dicen en su página de WordPress.org.

Para los comentarios

• Akismet compara los comentarios y los envíos de formularios con una base de datos global de spam, necesita una clave de API y es gratuito para blogs personales y de pago para sitios comerciales.
• Antispam Bee bloquea el spam de comentarios y de trackbacks sin captchas, con un campo trampa, la comprobación del tiempo, filtros por idioma y país y una base de datos local. Ojo, que según su registro de cambios la comprobación por país consulta un servicio externo, así que si te importa la privacidad revisa esa opción.

Para los hackeos y la integridad de los archivos

• Wordfence escanea archivos, entradas y comentarios en busca de direcciones peligrosas, redirecciones maliciosas y spam SEO, y compara el núcleo, los temas y los plugins con los del repositorio de WordPress.org. La versión gratuita recibe las firmas de malware y las reglas del cortafuegos con 30 días de retraso.
• Sucuri Security registra eventos, compara tus archivos con una línea base para ver los añadidos o modificados, hace un análisis remoto y vigila las listas negras. El cortafuegos es de pago.
• Kadence Security (el antiguo Solid Security, y antes iThemes Security) detecta cambios en archivos y trae un escáner de vulnerabilidades conocidas que consulta la lista de Safe Browsing de Google, los dos en la versión gratuita.
• Vigilante tiene dos funciones que encajan con lo que hemos visto (además de otras, como el cortafuegos local o la verificación en dos pasos). Endurece los comentarios (campo trampa, moderación de todo comentario nuevo, cierre en entradas antiguas y pingbacks y trackbacks desactivados) y comprueba la integridad comparando el núcleo, los plugins y los temas con las fuentes oficiales, mirando si hay archivos PHP en uploads y avisando cuando WordPress.org cierra un plugin que tienes instalado, aunque el análisis tiene un límite de 60 segundos y en webs grandes puede quedarse a medias. Lo planteo como complemento de los anteriores y no como sustituto de un cortafuegos en la nube.

Un matiz sobre esta lista. Sucuri y Kadence están aquí por lo que hacen con los archivos modificados y no porque los recomiende en general, y de hecho en mi comparativa de plugins de seguridad gratuitos los tengo entre los que no recomiendo.

Y la que de verdad te avisa es Search Console, con sus informes de acciones manuales y de problemas de seguridad, y es gratis. Si todavía no tienes tu web verificada, hazlo hoy.

¿Tengo que hacer algo ya mismo?

Si estás tranquilo con tu web, si no has notado nada, quizá no mucho. Pero cinco comprobaciones de un rato te cubren las vías más típicas:

1. Abre en Search Console el informe de acciones manuales y el de problemas de seguridad. Si dicen que no hay problemas, perfecto.
2. Busca site:tudominio.com junto a palabras que no deberían estar ahí (casino, viagra) y mira qué sale.
3. Pasa el plugin temporal con sus dos botones, el de enlaces escondidos y el de comparar visitas.
4. Revisa tus enlaces de pago, patrocinados y de afiliado, y comprueba que llevan sponsored o nofollow.
5. Prueba el botón atrás desde un resultado de Google, en el móvil y en el ordenador.

Y si tienes los comentarios abiertos o el registro abierto, ya sabes lo que toca.

Cuando compruebes que lo tienes todo bien, recuerda que evitar problemas no es lo mismo que posicionar, y para lo segundo tienes mi guía sobre el E-E-A-T en WordPress.

Si has pasado por una acción manual y quieres contar cómo te fue, o ves en tu web algo que no encaja con lo que cuento, me tienes ahí abajo, en los comentarios. Y guarda a mano la ficha de políticas de spam de Google, que es la que manda, porque todo lo demás son opiniones, también las mías.

Hoy se encuentran más fallos y algunos se aprovechan en cuestión de horas, y quien quiere hacerlo lo tiene más fácil que antes. Por eso tu web depende menos de la plataforma que elijas y más de que alguien la mantenga al día. Es lo que opino después de más de 20 años con WordPress, y te lo cuento con datos para que puedas discrepar … o no.

Te cuento por qué hay tantas noticias ahora (la inteligencia artificial tiene mucho que ver), qué hacen los malos con ella, y después, qué ha cambiado en WordPress y qué te toca hacer a ti, con una lista corta que puedes repasar hoy mismo. Para el final te dejo cómo distinguir a quien te informa de quien te quiere vender algo, empezando por mí. ¿Te animas?

Por qué parece que cada semana hay una vulnerabilidad nueva

Porque cada semana hay mucha más gente buscándolas, así de simple.

En julio, un investigador de Searchlight Cyber encontró con ayuda de un modelo de inteligencia artificial un fallo grave en el núcleo de WordPress (la parte principal, sin plugins ni temas). Era de los que permiten ejecutar código en una web sin necesidad de tener cuenta, le pusieron wp2shell y, según la propia empresa, el trabajo le llevó unas diez horas.

El dato más claro lo da Wordfence, que paga recompensas a quien le comunica fallos de WordPress y desde finales de noviembre de 2025 apunta cuántos informes dicen haber usado IA. En la primera semana eran el 16 % y en marzo y abril rondaban el 66 %, mientras que el total de informes recibidos crecía un 453 % desde octubre.

Son cifras de una empresa que vende protección, y el uso de IA lo declaran los propios investigadores, así que tómalas con ese contexto. Eso sí, cuadran con lo que contó el equipo de seguridad de WordPress el 28 de agosto, que habló de un aumento sustancial de informes en parte por la IA.

Y más informes no significa más fallos de verdad. El proyecto curl, una herramienta de código abierto muy extendida, cerró en enero su programa de recompensas por el aluvión de informes de poca calidad generados con IA que no podía atender.

El número que más asusta es el de Patchstack, otra empresa que vende protección, que contó 11.334 vulnerabilidades nuevas en el entorno WordPress durante 2025, un 42 % más que el año anterior. Pero fíjate en el reparto, porque el 91 % estaba en plugins, el 9 % en temas y solo seis en el núcleo. El problema está sobre todo en lo que instalas encima de WordPress y no en WordPress en sí.

Hay otro matiz, y es cómo se cuentan, porque por si no lo sabías, cada fallo conocido recibe un número de registro público, el CVE. Según el análisis de Jerry Gamblin, en 2025 se publicaron 48.185, y solo dos empresas especializadas en WordPress asignaron 10.458 de ellos, el 21,7 %.

A esto el mismo Gamblin lo llama «efecto WordPress» y lo atribuye a la intensa vigilancia que hay sobre los plugins de terceros. El número de avisos de WordPress refleja, en buena parte, que se busca mucho y se cuenta todo. Y que un software no publique fallos no significa que no los tenga, significa que no te los cuenta.

Y los malos, ¿también usan IA?

Pues sí, claro ¿o tenías dudas?. La barrera ha bajado para todos, para quien busca fallos para arreglarlos y para quien los busca para aprovecharlos. Lo esperable es que la ventaja vaya cambiando de manos entre atacantes y defensores a medida que avance la tecnología.

El centro nacional de ciberseguridad del Reino Unido (el NCSC) avisó el 1 de mayo de que viene una oleada de parches. Su razón es que la IA permitirá explotar a gran escala la deuda técnica del software, o sea, años de código viejo que nadie ha revisado. Además, aconseja a organizaciones de cualquier tamaño actualizar por defecto y, si se puede, de forma automática, justo lo primero de la lista que verás más abajo.

También hay casos documentados de gente con pocos conocimientos usando IA para delinquir. Anthropic, la empresa que hace Claude (que uso a diario, como ya sabrás), contó en agosto de 2025 el caso de un delincuente que no sabía programar el cifrado ni cómo pasar desapercibido.

Este cabronazo, con la ayuda de Claude, algo de paciencia y muchos tokens, montó varios programas de secuestro de datos (ransomware) y los vendía por entre 400 y 1.200 dólares. No era un ataque a WordPress, pero explica de qué se preocupa la gente, tú, yo.

Lo que sí está medido es la rapidez. Por ejemplo, cuando salió WordPress 7.1.2, en septiembre, Patchstack vio intentos de ataque ese mismo día. También, con el fallo de julio, según Searchlight Cyber, a los dos días de publicarse el parche ya había campañas de ataque masivas. El 21 de julio CISA, la agencia de ciberseguridad de Estados Unidos, lo añadió a su catálogo de vulnerabilidades explotadas.

Lo que no he visto medido, y por eso no te lo voy a afirmar, es cuánto de esto lo hacen aficionados con IA y cuánto es la delincuencia de siempre con mejores herramientas. Desconfía de quien te diga cuántos ataques son de aficionados con IA, porque, que yo sepa, nadie lo ha medido.

Lo que ha hecho WordPress para defenderse

Para empezar, WordPress puede empujar un parche a las webs afectadas sin que sus dueños hagan nada. Con el fallo de julio el equipo de WordPress.org activó actualizaciones forzadas para las webs afectadas, y donde se admiten las actualizaciones automáticas en segundo plano el parche empezó a instalarse solo.

Y hay más medidas, pues desde el 5 de junio WordPress.org retiene cada versión nueva de un plugin unas horas antes de repartirla (al principio hasta 24, hoy seis). Además, desde el 9 de septiembre la revisa automáticamente en busca de problemas de seguridad. En julio detectó así una puerta trasera en un plugin de unas 20.000 instalaciones cuando su versión todavía estaba en espera, de modo que nunca llegó a distribuirse.

El límite lo pones tú, pues ninguna medida de WordPress sirve en una web con las actualizaciones desactivadas o con un plugin abandonado, y mucho menos si no hay nadie que la mire. WordPress ha reaccionado rápido, pero no puede proteger una web que nadie mantiene.

¿Y si me paso a otra cosa?

A veces tiene sentido, no es una locura. Un servicio cerrado que se encarga de todo, si el proveedor es bueno, corrige un fallo una vez para todos sus clientes y en cuestión de horas. Nadie tiene que actualizar nada, y eso en una web propia es el eslabón más débil.

Una web estática, sin base de datos ni PHP (el lenguaje en el que está hecho WordPress) en la parte pública, tiene mucha menos superficie que atacar. Para muchos sitios es una opción excelente pero no de ahora, de siempre, pero a veces tiramos de WordPress por no pensar ¿a que sí?.

Lo que no puedes hacer es comprobarlo. Cuando te arreglan un fallo en un servicio cerrado no sabes cuál era, ni si alguien lo aprovechó contigo antes, ni cuánto tiempo estuviste expuesto. Durante años la costumbre fue no contarlo, lo reconoció la propia Microsoft en junio de 2024, cuando explicó que los proveedores de servicios cloud no divulgaban los fallos que corregían salvo que el cliente tuviera que actuar.

Tampoco está libre de sustos lo que no es WordPress, el 14 de septiembre los scripts de Brevo, una plataforma de correo y marketing, sirvieron código malicioso durante unas horas a las webs que los incrustaban, usaran WordPress o no. Sansec, una empresa de seguridad, estimó que más de 100.000 pudieron haberlo cargado sin saberlo.

Y no voy a decirte que el código abierto sea seguro por serlo, porque no lo es, que cualquiera pueda leer el código no quiere decir que alguien lo esté mirando.

Me pasó con Vigilante, mi plugin de seguridad, tenía un fallo en el registro de actividad que permitía colar código, venía de las primeras versiones (de esas partes que nadie toca porque funcionan) y salió publicado con su CVE, como toca. No lo vi yo, me lo comunicó un investigador, Sebastian Albrecht, y lo corregí en menos de dos horas.

Un consejo más para cuando alguien te diga que te vayas de WordPress porque ha salido un fallo, y es que mires si cobra una comisión por recomendarte la alternativa. Cobrarla no tiene nada de malo (hay software de pago estupendo y vivir de recomendarlo es un oficio legítimo mientras lo cuentes), pero tiene que decírtelo.

Y, siempre, desconfía de quien te prometa que lo suyo es inhackeable, porque eso no existe. Ya hablé de esa moda en mi respuesta a los posts de «adiós WordPress».

Lo que te toca hacer a ti

Esto es lo mínimo:

1. Actualiza, y que sea automático: WordPress instala solo las versiones de seguridad del núcleo si no lo has desactivado, y en la pantalla de Plugins puedes activar lo mismo para cada plugin. Alguna actualización puede dar guerra, por eso existe el punto 4.
2. Borra lo que no uses: un plugin o un tema desactivado sigue en tu servidor, con sus fallos incluidos.
3. Comprueba que tus plugins tienen mantenimiento: en la ficha de cada uno en WordPress.org ves cuándo se actualizó por última vez. Si lleva años sin tocarse conviene buscar sustituto, porque el día que aparezca un fallo nadie lo arreglará. El 46 % de las vulnerabilidades de 2025 no tenía parche cuando se hicieron públicas, aunque esa cifra mezcla plugins abandonados con autores que tardan en contestar.
4. Haz copias de seguridad fuera del servidor: guardadas en otro sitio y con una restauración probada, porque una copia que nunca has probado a restaurar puede no servirte cuando la necesites.
5. Protege el acceso: una contraseña que no uses en ningún otro sitio y verificación en dos pasos para quien administre la web.
6. Consigue que alguien la mire: tú, tu agencia o un servicio de mantenimiento, pero que alguien la revise con regularidad y sepa qué hacer cuando salga un aviso.

Si quieres una primera idea de cómo estás, tengo un análisis de seguridad gratuito para WordPress, metes la dirección de tu web y en menos de un minuto hace más de 30 comprobaciones desde fuera (certificado, cabeceras de seguridad, archivos que no deberían verse, plugins visibles y listas negras).

Te da una nota y una recomendación para cada problema. Como mira desde fuera, no ve lo que no se ve desde fuera, así que una nota alta es buena señal y no una garantía. También te señala cuáles de esos problemas puede resolver Vigilante, mi plugin de seguridad gratuito, que complementa la lista de arriba y no la sustituye.

Si ya te ha pasado, o prefieres que lo revise alguien

Sí, te voy a vender algo, bueno, a contártelo, por si no lo sabías. Tengo un servicio de limpieza y refuerzo de seguridad. Si tu web está hackeada o infectada, se localiza por dónde entraron, se limpia todo y se pide la retirada de los avisos de Google y de los antivirus. Si no ha pasado nada, se revisa la web desde fuera y desde dentro en busca de vulnerabilidades conocidas y puntos débiles, y se corrige lo que aparezca.

En ambos casos termina con un refuerzo de la seguridad, una copia de seguridad final y un informe con lo que se ha hecho y lo que queda en tu mano. Dejo además instalado y perfectamente configurado Vigilante, mi plugin gratuito. Lo que no controlo son los plazos de Google y de cada antivirus para retirar sus avisos.

Dar acceso a tu web a alguien que no conoces da respeto, así que antes de tocar nada hago una copia completa y te pido autorización por escrito con el alcance del trabajo. Utilizo un usuario administrador aparte que borro al terminar y, en las limpiezas, cambio al final las contraseñas y retiro mis accesos.

El precio es cerrado y las horas de más corren de mi cuenta, con pocas excepciones que tienes explicadas en la página. Si contratas la revisión y aparece una infección, pasas a la limpieza pagando solo la diferencia. Soy el primer sorprendido de que cada vez me lo contratan más para la parte de revisar y reforzar antes de que pase nada.

Que una web tenga vulnerabilidades no significa que la vayan a atacar mañana, pero cada una es una puerta abierta, y cerrarla con tiempo sale mejor que hacerlo con la web caída.

Y si prefieres olvidarte y que alguien se ocupe cada mes de actualizar y vigilar, tengo también esos maravillosos planes de mantenimiento WordPress que a todos sorprenden cuando descubren todo lo que hay ahí, no solo yo ayudándote con tu web.

¿Y cómo sé de qué o de quién fiarme?

No hace falta ser técnico para decidir de quién fiarte. Hace falta poder contestar a estas cinco preguntas, y si no puedes, ya tienes tu respuesta.

1. ¿Publica avisos de seguridad con fecha y con detalle suficiente para saber si te afectan?
2. ¿Asigna un CVE a sus fallos (el registro público del que hablaba antes), o explica por qué no lo hace?
3. ¿Su registro de cambios dice qué arreglos son de seguridad, o los esconde entre «mejoras de rendimiento»?
4. ¿Puedes irte con tus datos si mañana desaparece, cambia de dueño o se vuelve de pago?
5. ¿Quién cobra por recomendártelo y te lo ha dicho?

Ninguna de las cinco asegura nada, pero con las cinco contestadas sabes más que leyendo cualquier hilo de «me voy de WordPress». La quinta me la aplico yo. Vivo de WordPress y de cobrar por mantenerlo seguro, y por eso te aviso cuando te vendo algo.

La decisión es tuya, claro. Mi opinión es que no hace falta irse de WordPress por tanta noticia asustaviejas, hace falta no dejarlo solo. Si quieres ver cómo reviso yo la seguridad de mi propio plugin, lo cuento aquí, y si te preocupa qué pasa cuando un plugin cambia de dueño, lo conté con un caso real.

Como siempre, por supuesto, si no estás de acuerdo con algo de lo que he dicho o que se me ha escapado algo, me tienes ahí abajo, en los comentarios.

Al rascar en una de ellas, apareció en la carpeta wp-content un archivo que no había visto nunca, object-cache-crashed.php, y ahí empezó a cuadrar todo.

La respuesta corta es que el aviso que sale en salud del sitio no mira lo que tienes activado sino lo que WordPress tiene cargado, y en el caso de Memcached eso es un archivo, object-cache.php, que puede desaparecer sin que nadie te lo diga.

Pero mejor te lo explico, ¿lo vemos?

Qué comprueba realmente el aviso de Salud del sitio

Es una de las pruebas de rendimiento de la herramienta de salud del sitio de WordPress (desde la versión 6.1) y solo se ejecuta si el tipo de entorno de tu web es producción (el valor por defecto en WordPress).

Hace tres comprobaciones, por este orden:

1. Si hay una caché de objetos externa cargada da la web por buena y no dice nada más.
2. Si no la hay mira si tu web es lo bastante grande como para necesitarla. Cuando no lo es dice que «No es necesaria una caché de objetos persistente» y no ves ninguna advertencia, lo da por bueno.
3. Si la web es grande y no hay caché, sale el «Deberías utilizar una caché de objetos persistente», marcado como recomendación de rendimiento.

Lo de «lo bastante grande» tiene números concretos. WordPress considera que tu web es grande si pasa cualquiera de estos umbrales:

• Más de 500 opciones cargadas automáticamente.
• Opciones cargadas automáticamente que ocupen más de 100.000 bytes.
• 1.000 filas o más en las tablas de comentarios, opciones, entradas, términos o usuarios (usa las cifras estimadas que da la base de datos, no un recuento exacto).

En un multisitio el aviso sale siempre, sin mirar nada de lo anterior.

La frase del segundo párrafo del aviso, «Tu alojamiento parece que es compatible con los siguientes servicios de caché de objetos: Memcached», tampoco prueba nada de tu hosting.

WordPress solo comprueba que esté cargada la extensión de PHP correspondiente (mira APCu, Redis, Relay, Memcache y Memcached), no que haya un servidor funcionando ni que tu web lo esté usando.

Un interruptor en ON no es una caché funcionando

En SiteGround hay dos piezas, por un lado está el servicio de Memcached que activas en Site Tools y, por otro, el interruptor de Memcached de Speed Optimizer, que es el que conecta ese servicio con WordPress. Lo conecta copiando un archivo, object-cache.php, en wp-content.

WordPress carga ese archivo (un drop-in, un archivo suelto que sustituye una pieza del propio WordPress) al arrancar, y si define la función wp_cache_init() da por hecho que hay una caché de objetos persistente.

El interruptor del plugin, en cambio, es solo una opción guardada en la base de datos. Las dos cosas pueden desincronizarse, como tener el interruptor de la luz en ON con la bombilla fundida.

Para ver en qué estado está la tuya, tienes dos sitios:

• Salud del sitio > Información > Dependientes: así se llama en español la sección que en inglés es drop-in. Si la caché está en su sitio verás ahí object-cache.php, y si no aparece es que el archivo no está.
• Administrador de archivos de Site Tools, carpeta wp-content: aquí ves los nombres exactos, y es donde yo me llevé la sorpresa.

Con la caché de Speed Optimizer puedes encontrarte hasta tres archivos distintos:

• object-cache.php: el dependiente activo, aquí todo en orden.
• object-cache-socket-missing.php: el dependiente se desactivó porque no encontró el socket de Memcached (/home/.tmp/memcached.sock), que es el punto de conexión por el que habla con el servicio.
• object-cache-crashed.php: el dependiente se desactivó porque Memcached rechazó guardar un valor.

Qué mata el drop-in de Speed Optimizer

El propio dependiente vigila lo que pasa y se renombra a sí mismo cuando algo falla, para que la web siga funcionando sin caché en lugar de romperse. Lo hace en dos casos:

• El socket no existe. Si al cargar no encuentra /home/.tmp/memcached.sock, se renombra a object-cache-socket-missing.php y deja escrito «Memcache disabled from SiteTools» en el registro de errores. El caso típico es haber apagado Memcached en Site Tools.
• Memcached no acepta un valor. Si al guardar un objeto Memcached lo rechaza por tamaño (su límite por defecto es de 1 MB por valor), el dependiente escribe una línea que empieza por Memcache Key: en el registro de errores de PHP y se renombra a object-cache-crashed.php. Si el objeto es una opción de WordPress el plugin intenta salvarse sacando de la caché la opción cargada automáticamente más pesada, pero con cualquier otro grupo de caché (los transitorios, por ejemplo) el dependiente cae.

Y el problema práctico es que nada te avisa. El plugin solo comprueba si el dependiente sigue en su sitio cuando abres la página principal de Speed Optimizer, y el aviso general para todo el escritorio de WordPress está desactivado en el código.

Cuando por fin entras, el plugin apaga el interruptor y el panel te lo cuenta, pero hasta ese momento tu web puede llevar semanas trabajando sin caché de objetos con el interruptor en ON (eso sí, no se cae, solo va sin ella).

También pasa lo contrario. Si desactivas y vuelves a activar el plugin con el interruptor en ON, crea un dependiente nuevo sin preguntarte, y esa es una de las formas en que puede aparecer uno sin que lo sepas.

El object-cache-crashed.php que encontré tenía fecha de agosto y yo no recuerdo haber tocado nada en esos días, así que no sé cuál fue el motivo.

Además, ojo con las fechas del administrador de archivos, porque renombrar un archivo no cambia su fecha de modificación y la que ves es la de cuando se escribió ese dependiente.

Cómo encontrar lo que lo ha tumbado

Si el archivo es object-cache-socket-missing.php, la pista la tienes en Site Tools, así que mira si Memcached sigue activado.

Si el archivo se llama object-cache-crashed.php toca averiguar qué objeto era demasiado grande, y para eso el dependiente te deja una pista en el registro de errores de PHP.

En mis webs ese registro es un archivo php_errorlog que está en la raíz de public_html y no dentro de wp-content, como el debug.log de WordPress.

SiteGround también tiene un registro de errores en Site Tools, dentro de la sección de estadísticas, que puedes copiar al portapapeles, aunque su documentación no dice si incluye lo que escribe PHP, así que si ahí no aparece nada busca el archivo.

La línea tiene este aspecto (le he cambiado el nombre de la clave):

[14-Aug-2026 22:07:56 UTC] Memcache Key:  3f9c1d…:transient:nombre_del_transitorio

La clave se lee de dentro hacia fuera. Lo último, nombre_del_transitorio, es el nombre del objeto y suele empezar por el prefijo del plugin que lo creó, lo del medio (transient) es el grupo de caché y lo primero es un prefijo propio del dependiente que puedes ignorar.

En mi caso era un transitorio (un dato temporal que WordPress guarda para no recalcularlo) de un plugin que generaba un archivo de texto con el contenido completo de casi 5.000 entradas del blog.

Sin caché de objetos persistente, WordPress guarda los transitorios en la tabla de opciones de la base de datos y nadie se entera de lo que pesan. Con Memcached ese mismo transitorio se da de bruces con el límite de 1 MB y hace caer el dependiente.

Si a ti te sale otro grupo o otro nombre, el procedimiento es el mismo.

Identifica el plugin por el prefijo, mira si tiene un ajuste para ese archivo o ese índice y reduce lo que guarda o desactívalo. Si no lo tiene, avisa a quien lo mantiene, que probablemente no sabe que su transitorio hace caer el dependiente en ese hosting.

Reactivar Memcached sin que vuelva a caer

Quitar la causa es lo primero. Si reactivas con el objeto grande todavía en marcha el dependiente nuevo se renombrará en cuanto Memcached rechace otra vez ese valor.

Luego, cuando lo tengas resuelto haz esto:

1. Entra en Speed Optimizer > Caché y, si el interruptor de Memcached está en ON, apágalo.
2. Vuelve a encenderlo. El plugin crea un object-cache.php nuevo y borra el object-cache-crashed.php. Si no te deja encenderlo, lo más probable es que no encuentre el socket, así que comprueba en Site Tools que Memcached está activado.
3. Abre Salud del sitio y comprueba que el aviso ha desaparecido y que en Información > Dependientes aparece object-cache.php.
4. Pasados unos días mira que el archivo sigue ahí, porque si el valor grande tarda en volver a guardarse (un transitorio con caducidad, por ejemplo) el dependiente puede tardar en caerse otra vez.

El object-cache-socket-missing.php no lo toca el plugin, pero WordPress no lo carga porque no se llama object-cache.php, así que puedes dejarlo o borrarlo.

Cuándo el aviso es legítimo y cuándo puedes ignorarlo

Con los umbrales que te comenté antes, una web pequeña no verá nunca el aviso aunque no tenga caché de objetos (lo que le sale es el «No es necesaria una caché de objetos persistente»), tenga Memcached o no.

Puede que decidas que no quieres caché de objetos en una web grande (por ejemplo, porque tu hosting no la ofrece o porque la web apenas consulta la base de datos). En ese caso puedes quitar el aviso con este filtro, en el functions.php o en un plugin de fragmentos de código:

add_filter( 'site_status_should_suggest_persistent_object_cache', '__return_false' );

Si lo que quieres es subir los umbrales en vez de apagar el aviso, el filtro es este otro:

add_filter( 'site_status_persistent_object_cache_thresholds', '__return_false' );

Eso sí, silenciar el aviso no arregla nada, es solo una decisión. Si tienes Memcached activado quieres que funcione, y silenciar la alarma justo cuando te avisa de que no funciona es quitarle las pilas porque hace un ruido molesto.

Preguntas razonables

Por ir terminando, aquí unas dudas que puede que te hayan quedado por ahí bailando.

¿Es lo mismo el Memcached de Site Tools que el del plugin?

No. El de Site Tools es el servicio (con su socket) y el del plugin es el archivo que lo conecta con WordPress. Para que haya caché tienen que funcionar los dos.

¿Se cae la web si el plugin dependiente desaparece?

Por lo que se ve en el código no, porque el dependiente se renombra y WordPress sigue trabajando sin caché de objetos, como si nunca la hubieras tenido. Lo que pierdes es la mejora de velocidad.

¿Puedo comprobarlo sin SSH?

Sí, con el Administrador de archivos de Site Tools y la sección Dependientes de Salud del sitio, que es con lo que lo he hecho yo.

Si en el registro de alguna de tus webs aparece una clave distinta a la del ejemplo, cuéntamela en los comentarios, que me interesa saber qué más hace caer el dependiente.

Y si te has cruzado con el aviso del opcode cache en Salud del sitio, es la misma historia con otra pieza. Salud del sitio describe lo que WordPress ve en ese momento, y eso no siempre coincide con lo que crees haber configurado.

La web en cuestión, una cuyo nombre no puedo nombrar, tenía WordPress y todos sus plugins al día, ¿entonces?.

Pues no era una falsa alarma ni un resto de alguna versión antigua, y tirando del hilo apareció en la raíz una carpeta llamada, literalmente, - (un guion y nada más), y dentro un kit de phishing completo, tres webshells y un registro de visitas que llegaba hasta el 30 de septiembre de 2026.

Todo había entrado el 2 de abril de 2021, o sea, que un hackeo llevaba más de cinco años viviendo dentro de un WordPress que se actualizaba con normalidad. Y antes de que te pongas en lo peor, te adelanto que, por lo que dejaron escrito los propios archivos, no hay rastro de que nadie llegara a caer en la trampa.

Ya mismo te cuento lo qué había, cómo se escondía, qué dicen las fechas y, sobre todo, cómo puedes comprobar en un rato si tu WordPress tiene algo parecido, que seguro que ya te está corroyendo el misterio ¿a que sí?

Un aviso, el rastro y una carpeta con nombre de guion

Aquí tiré de uno de mis superpoderes, que es conocerme de memoria las carpetas de WordPress. En vez de caer en el automatismo de «bah, serán archivos normales», entré en el gestor de archivos del hosting a revisar las carpetas y los archivos, y enseguida vi que aquello no era ni medio normal.

Los seis archivos del aviso eran tres nombres repetidos en dos sitios, index.php, up.php y contador.php, dentro de wp-admin/js/ y de wp-includes/IXR/.

Ninguna de esas dos carpetas lleva archivos así en WordPress, y un PHP que no reconoce la versión instalada de WordPress dentro de sus carpetas siempre merece que lo abras y lo leas.

Dentro había código que no pintaba nada ahí, y al mirar la raíz de la web (el public_html) apareció la carpeta -.

No sé si el nombre está elegido a propósito, pero desde luego era raro. En un listado largo pasa desapercibida, y muchos programas de la línea de comandos interpretan un guion suelto como otra cosa (si escribes cd - no entras en ella, vuelves a la carpeta en la que estabas antes).

Un nombre que cuesta ver y cuesta manejar es un buen nombre para esconder algo.

Lo que había dentro del bicho…

Había tres cosas distintas, montadas en la misma sesión y pensadas para trabajar juntas, pero ninguna tenía nada que ver con la web ni con sus visitantes.

Un kit de phishing contra los clientes de Terra (Brasil)

Dentro de la carpeta - había otra llamada fatura (factura, en portugués), y dentro un clon del área de clientes de Terra, un portal brasileño muy popular.

El recorrido de la víctima estaba bien pensado, eso hay que reconocerlo:

• Entrada rotativa: la página inicial mandaba al azar a una de once copias idénticas con nombres aleatorios, para que bloquear una sola URL no sirviera de nada.
• Primer paso: una pantalla de acceso que pedía el correo y la contraseña de Terra.
• Segundo paso: con la excusa de «actualizar la forma de pago», pedía la tarjeta completa (número, caducidad, código de seguridad y titular), el RG y el CPF, que vienen a ser el DNI y el NIF brasileños.
• Salida limpia: un mensaje de «pago efectuado con éxito» y redirección al correo web real de Terra, para que la víctima no sospechara nada.

Los datos robados se guardaban añadiéndolos a un archivo .html dentro del propio kit, que cualquiera que conociese la URL podía leer, y además se enviaban por correo con la función mail() de PHP, es decir, usando el servidor de la web como servicio de entrega de correo.

El atacante tenía hasta su panel de control, con usuario y contraseña, una sección titulada «Infos capturadas [CC’s]» y botones para borrar los registros.

El servidor no era la víctima, era la infraestructura, y a los que montan estas campañas les da igual de quién sea la web o de qué país, lo que buscan es un servidor con buena reputación donde colgar sus mierdas malignas.

Tres webshells disfrazados de archivo de WordPress

Repartidos por la carpeta había tres copias idénticas de un archivo llamado laj.php. El susodicho es un webshell (un panel de control que permite manejar el servidor desde el navegador como si estuvieras dentro), en concreto una variante de WSO 2.5, muy conocida y muy usada. Con eso se pueden ver, editar y subir archivos, ejecutar comandos, consultar la base de datos y enviar correos.

Lo curioso es el disfraz. El archivo empieza con un comentario copiado de default-filters.php, un archivo real del núcleo de WordPress, y usa nombres de variables y funciones que suenan a WordPress de toda la vida ($wp_nonce, $wpautop, pre_term_name()). Si lo abres deprisa cuela.

El código chungo está escondido dentro de algo que se presenta como una imagen PNG incrustada, una sola línea de 19.813 caracteres.

Para ejecutarla el archivo la decodifica, la descomprime y la pasa a eval(), pero sin escribir en ningún sitio los nombres de esas funciones, sino construyendolos al revés:

$filterfunc = strrev('46esab')."_".strrev('edoced');
$preparefunc = strrev('etalfnizg');

Si te fijas, 46esab y edoced al revés son base64 y decode, y etalfnizg es gzinflate. ¿Que por qué tanto lío para escribir base64_decode? Pues porque muchos escáneres buscan exactamente ese texto, y así no lo encuentran. Cabrones pero listos.

Y ahora un detalle que tiene su gracia (irónicamente), porque esta copia traía una sección añadida que funciona antes de pedir la contraseña, y que permite cambiar la contraseña del shell con un simple parámetro en la URL. O sea, que cualquiera que encontrase el archivo podía quedarse con el shell sin saber la contraseña.

Junto al shell había también un php.ini que intentaba desactivar el modo seguro de PHP y vaciar la lista de funciones prohibidas, y el propio shell lo reescribía en cada visita.

Un redireccionador con puerta trasera incluida

Los seis archivos del aviso de Vigilante eran la tercera pieza, la misma en las dos carpetas de WordPress:

• index.php: apuntaba cada visita en una carpeta llamada avisos y redirigía a una IP en la nube de Amazon, que sería el destino real de la campaña (no te recomiendo ir a mirar qué hay).
• contador.php: una página titulada «CLIENTES ATIVOS» que contaba los clics registrados.
• up.php: un formulario para subir cualquier archivo al servidor sin contraseña ni comprobación alguna.
• Un archivo de reglas de Apache: solo dejaba pasar a las IP que empiezan por ciertos números, la mayoría rangos de Latinoamérica, y bloqueaba unos cuantos proxies de Google y algunas IP concretas, seguramente de analistas de seguridad.

El up.php es la pieza más peligrosa de todas, porque era la llave de repuesto para volver a entrar si alguien limpiaba lo demás.

Este archivo up.php empieza con una cabecera de imagen GIF antes del código PHP, para que algunas herramientas lo tomen por una imagen:

GIF88GHZ
<?php
if( file_exists($_FILES["uploadfile"]["tmp_name"]) )

El catálogo de trucos para pasar desapercibido

Si juntas todo lo anterior sale un pequeño manual de camuflaje de código inyectado, y conviene conocerlo porque son trucos que se repiten en muchísimos hackeos de WordPress:

• Vestirse de WordPress: carpetas que existen en cualquier instalación y que nadie abre, archivos llamados index.php y comentarios copiados del núcleo.
• Escribir al revés: nombres de funciones peligrosas construidos con strrev() para que no aparezcan en las búsquedas.
• Imágenes que no son imágenes: el código metido en un falso data:image/png, o un PHP que empieza como si fuera un GIF.
• Fechas falsas: el shell se pone a sí mismo la fecha del index.php que tenga al lado (touch(__FILE__, filemtime("index.php"))), así que si ordenas por fecha no destaca.
• Filtro por país casero: reglas de Apache para que solo lleguen las víctimas que interesan y no los curiosos.
• Cortina para buscadores: un robots.txt de 969 líneas que bloquea a unos 320 bots, y un shell que devuelve un error 404 si quien llama se identifica como Google, Bing, Yahoo o Yandex.
• URL rotativas: once copias de la misma página para que bloquear una no sirva.

Ninguno es nuevo ni sofisticado, pero juntos funcionan, y la prueba es que han aguantado más de cinco años.

Lo que cuentan las fechas (y lo que no)

Aquí es donde la cosa se pone interesante de verdad, porque los archivos conservaban las fechas del servidor, y leídas deeeespaacito te cuentan bastantes detalles.

Todo se inyectó el 2 de abril de 2021, en menos de media hora y en una sola sesión. Los archivos del kit, en cambio, traen fechas de 2020 y de febrero de 2021, señal de que se subió ya empaquetado y de que se había usado antes en otros sitios.

Al día siguiente, el 3 de abril de 2021, el atacante probó su formulario con unas credenciales falsas que decían «TEST». Esa prueba es lo único que hay en el archivo donde se guardaban los datos robados, y el archivo no se ha vuelto a modificar desde entonces.

Como cada envío del formulario escribe ahí antes de mandar el correo, no hay rastro de que nadie llegara a introducir sus datos a través de este servidor.

Las carpetas avisos del redireccionador están vacías y con la fecha del primer día, así que tampoco registró ni un clic.

¿Y los shells? Pues todo indica que no llegaron a ejecutarse ahí. Recuerda que se ponen la fecha del index.php que tienen al lado cada vez que alguien las abre, y siguen con su fecha original de 2020. Además, el php.ini que reescriben en cada visita sigue con fecha de diciembre de 2020.

Ahora la cifra que es para flipar, porque el kit llevaba su propio registro de visitas a la página de acceso falsa, y son 453 visitas desde 285 direcciones IP distintas, la última el 30 de septiembre de 2026.

Suena peor de lo que es, porque la mayoría de esas visitas se identifican con navegadores que ya no usa nadie (Internet Explorer 10, versiones de Chrome de hace años) o directamente sin identificar, que es el patrón típico de los verificadores automáticos que comprueban URL de phishing. Lo más probable es que la dirección estuviese fichada en alguna lista antiphishing y la siguieran revisando, no que hubiera cientos de víctimas.

Dicho esto, las fechas de un archivo se pueden falsificar (el propio shell lo hace, como acabas de ver), así que todo esto son indicios sólidos y coherentes entre sí, no pruebas. Ah, y el up.php no dejaba registro, así que si alguien lo usó, lo que subiera tendría que estar en esas mismas carpetas. No había nada más, y nada menos.

Qué le puede pasar a una web que sirve phishing (aunque no sea culpa suya)

Que no haya víctimas registradas no quiere decir que una web con un kit de phishing dentro se vaya de rositas. Para el resto de Internet esa web está sirviendo un fraude, da igual que su dueño no lo sepa, y las consecuencias le caen al dominio y al servidor, no al que montó el kit, que casi nunca se le pilla:

• La pantalla roja del navegador: Chrome, Firefox y Safari usan las listas de navegación segura de Google, y cuando una URL está fichada como engañosa enseñan un aviso rojo a pantalla completa antes de dejarte entrar. Puede afectar solo a las páginas del kit o a todo el dominio, y espanta a casi todo el mundo, porque en un estudio de investigadores de Google y de la Universidad de Berkeley publicado en 2013 solo el 18 % de los usuarios de Chrome y el 9 % de los de Firefox seguían adelante tras un aviso de phishing.
• Avisos en Google: en Search Console aparece un problema de seguridad de tipo «ingeniería social», y los resultados de búsqueda también pueden mostrar advertencias hasta que limpies y pidas una revisión.
• Correo que no llega: los filtros antispam consultan listas de dominios peligrosos, y alguna, como la DBL de Spamhaus, tiene hasta una categoría específica para dominios legítimos usados para phishing. Si el tuyo entra, los correos que lleven enlaces a tu web (tus boletines y tu propia firma incluidos) pueden acabar en spam o rechazados. Y si el kit envía correos desde tu servidor, como hacía este, la que se quema es la IP del servidor, lo que en un alojamiento compartido arrastra también a tus vecinos.
• Tu servicio de newsletter: hay servicios de email marketing que comprueban los enlaces de cada campaña contra estas listas y no te dejan enviarla si alguno está fichado, y en una newsletter casi todos los enlaces van a tu propia web. Otros revisan tu web antes de aprobarte la cuenta, y no parece que un dominio marcado por phishing vaya a pasar ese filtro. Y si llegas a enviar y los correos rebotan o acaban marcados como spam, saltan los umbrales de calidad del servicio, que son motivo de suspensión de la cuenta (Brevo, por ejemplo, habla de más de un 2 % de rebotes duros o de un 0,2 % de quejas).
• El hosting: las denuncias de phishing llegan al proveedor de alojamiento, y lo normal es que desactive el contenido o suspenda la cuenta hasta que limpies. Hace bien, porque está protegiendo a terceros y al resto de sus clientes, pero si no te has enterado antes te encuentras la web caída sin saber por qué.
• El dominio: desde abril de 2024 los registradores de dominios .com, .net y compañía están obligados por sus contratos con ICANN a actuar contra el phishing en cuanto tienen pruebas. Eso sí, la propia ICANN reconoce que en una web hackeada suspender el dominio entero no suele ser lo adecuado, y lo que plantea es avisar primero al titular y al hosting.
• La reputación: INCIBE cuenta el caso real de un pequeño negocio cuya web alojaba una página falsa de PayPal, con mensajes y comentarios públicos de gente avisando del fraude, y concluye que el daño a su reputación era más difícil de reparar que borrar la página.
• Los datos de tus usuarios: con una webshell el atacante puede llegar a la base de datos. Si en ella hay datos personales de tus clientes o usuarios y no puedes descartar que alguien los haya visto, el RGPD te obliga a valorarlo y, si hay riesgo para ellos, a notificarlo a la AEPD en un máximo de 72 horas desde que lo sabes.

Ahora la parte buena, que también la hay, y es que cuando pides la revisión, Google tarda en torno a un día en revisar una web marcada por phishing, y si está limpia retira los avisos en menos de 72 horas.

Las listas de bloqueo tienen sus procedimientos para salir de ellas y, como acabas de ver, ni el registrador debería suspenderte el dominio a la primera.

O sea, que el daño crece con el tiempo que el kit pasa publicado sin que lo sepas, y por eso enterarte pronto vale más que cualquier otra medida.

Por cierto, por si te lo preguntas, la web afectada, sorprendentemente, no tenía ningún aviso de nada, fue algo que detectó el plugin Vigilante y tuvimos tiempo de borrar todo este bicho y reforzar la instalación para evitar sustos futuros.

¿Cómo sobrevive un hackeo cinco años a las actualizaciones?

Las actualizaciones de WordPress funcionan muy bien, eso es así, y que hoy se apliquen solas ha evitado muchísimos hackeos, y es de las funcionalidades de WordPress que más han hecho por la seguridad en Internet.

Pero el actualizador del núcleo de WordPress sobrescribe los archivos que conoce, y borra una lista de archivos antiguos que él mismo ha ido retirando con los años. Lo que WordPress no sabe que existe, simplemente porque no es parte de la instalación propia WordPress, ni lo mira, y se le puede colar.

Actualizar WordPress sustituye los archivos que WordPress conoce. Los que no conoce se quedan donde están.

Por este motivo los archivos de wp-admin/js y wp-includes/IXR sobrevivieron a todas las actualizaciones desde abril de 2021.

Con los plugins pasa algo distinto. Al actualizar un plugin WordPress borra su carpeta entera y pone la nueva, así que un archivo cabrón metido dentro de un plugin suele desaparecer en la siguiente actualización, pero uno metido en wp-admin, en wp-includes o en la raíz no.

Y la carpeta - estaba fuera de WordPress, en la raíz, donde no la toca ninguna actualización, ni del núcleo, ni de plugins, ni de temas, así que ahí podría haber seguido otros cinco años.

¿Y por dónde entraron? Pues ni puta idea

La primera tentación es pensar que, como dejaron archivos en carpetas de WordPress, entraron por un fallo de WordPress, y tiene su lógica, no te digo que no, pero no se sostiene.

Dónde deja los archivos un atacante no dice nada de por dónde entró, porque esas carpetas se eligen por camuflaje. Además, la parte principal, el kit de phishing, ni siquiera estaba en carpetas de WordPress, estaba en el directorio raíz.

Un fallo del núcleo es, de hecho, la explicación menos probable. En abril de 2021 la versión vigente era la 5.7, y la 5.7.1, publicada el 15 de abril de 2021, corrigió dos fallos de seguridad. Una de las vulnerabilidades era un XXE en la biblioteca de medios que solo afectaba a sitios con PHP 8 y exigía poder subir archivos, y permitía leer archivos del servidor, no escribirlos. La otra era una fuga de datos en la API REST que requería ser colaborador. Ninguno de los dos permite escribir archivos en el servidor, así que haría falta un fallo del núcleo que nadie ha documentado nunca.

Lo que sí encaja sería más algo como una campaña masiva contra webs WordPress, de más a menos probable en mi opinión:

1. Un plugin o un tema vulnerable de aquella época, que no tiene por qué seguir instalado hoy.
2. Credenciales robadas o adivinadas de un administrador de WordPress. Con acceso de administrador no hace falta ninguna vulnerabilidad, basta con subir un plugin que lleve una shell dentro.
3. Credenciales de SFTP o del panel del hosting.

¿Por qué no puedo saberlo? Pues porque han pasado más de cinco años y los registros del servidor de aquellas fechas ya no existen en ninguna parte.

Y esa es, al menos para mí, una de las lecciones más importantes de todo esto, que cuanto más tarde descubres un hackeo, menos rastro queda para saber por dónde entró, y sin saber por dónde entró no puedes estar seguro de haber cerrado la puerta.

Cómo comprobar tu WordPress en un momentito

Para lo básico no necesitas nada más que el gestor de archivos de tu hosting, que es justo lo que usé yo para la primera revisión, y muchas veces es más que de sobra.

Si además tienes acceso SSH (la consola del servidor), al final te dejo unas búsquedas que afinan bastante más, y si no lo tienes, un plugin que lo hace todo por ti.

Compara con una copia limpia de WordPress

Descarga la misma versión de WordPress que tienes instalada (las anteriores están en el archivo de versiones de WordPress.org), descomprímela en tu ordenador y abre wp-admin y wp-includes de tu web en el gestor de archivos.

Compara carpeta por carpeta, porque cualquier archivo que esté en tu web y no en la descarga limpia merece que lo abras.

Lleva su rato, y por eso es fundamental tener un plugin de seguridad que compare los archivos del núcleo con los originales y te avise de lo que sobra, que es justo el tipo de aviso que destapó este caso. Si te conoces la estructura de WordPress, lo que es raro salta a la vista enseguida.

Mira qué hay en la carpeta raíz

Abre la carpeta principal de tu web (normalmente public_html) y repasa todo lo que no sea wp-admin, wp-content, wp-includes o los archivos sueltos de WordPress (index.php, wp-config.php, wp-login.php y compañía).

Saldrán cosas legítimas (archivos de verificación de Google, otras aplicaciones, alguna carpeta tuya de pruebas), pero cada una debería tener una explicación. Una carpeta que no reconoces en la raíz de tu web no es un detalle, es lo primero que hay que abrir.

Y si ves copias del wp-config.php con otra extensión (wp-config.php.bak, wp-config-old.txt y cosas así), bórralas. El servidor no las ejecuta como PHP, así que puede entregarlas como texto a quien las pida, contraseña de la base de datos incluida.

Busca PHP donde no debería haberlo

La carpeta wp-content/uploads es para imágenes y documentos. Algunos plugins guardan ahí algún PHP propio (un index.php vacío para que no se pueda listar la carpeta, o la caché de plantillas de WPML, por ejemplo), pero cualquier otro merece una mirada.

Si tu gestor de archivos tiene buscador, busca .php dentro de esa carpeta y te ahorras ir subcarpeta por subcarpeta.

Si tienes SSH busca los trucos de camuflaje por su contenido

Estos comandos se lanzan desde la carpeta donde está WordPress y ninguno modifica nada, solo miran:

grep -rlE 'strrev\(.(46esab|edoced|etalfnizg)' --include='*.php' .
grep -rlE 'eval\s*\(\s*\$' --include='*.php' .
grep -rl --include='*.php' -m1 '^GIF8' .
find . \( -name 'php.ini' -o -name '.user.ini' \) -exec grep -lE '^\s*disable_functions\s*=\s*$' {} +

El primero busca funciones peligrosas escritas al revés, el segundo código que ejecuta el contenido de una variable, el tercero archivos PHP que empiezan como un GIF y el cuarto archivos php.ini que vacían la lista de funciones prohibidas.

Ojo con el segundo, porque algún plugin legítimo usa eval() de esta forma (los que te dejan añadir fragmentos de código desde el escritorio, por ejemplo). Si aparece un archivo, mira de qué plugin es antes de asustarte. Los demás no deberían dar ningún resultado en una web limpia.

Fíjate en que se busca por contenido, no por nombre ni por fecha, porque este shell podía copiarse a sí misma con otro nombre y, como ya has visto, se cambiaba la fecha.

Revisa los cambios recientes sin fiarte de las fechas

También por SSH, esto lista los PHP cambiados en los últimos 30 días:

find . -name '*.php' -ctime -30

El truco está en el -ctime, que mira el momento en que el sistema registró el último cambio del archivo y no la fecha de modificación que muestra un listado normal. Esa segunda fecha se puede falsificar con una línea de PHP, como hacía esta shell, pero el ctime no.

Tras una actualización saldrán muchos archivos, lo normal, así que interesa más lanzarlo de vez en cuando y fijarte en lo que no cuadre con ninguna actualización tuya.

¿Sin SSH y sin ganas de ir carpeta por carpeta? Un plugin que lo revisa por ti

Para que no tengas que hacerlo todo a mano he preparado un plugin de revisión que hace estas mismas comprobaciones sin necesidad de SSH. Es un solo archivo PHP y lo puedes instalar de dos formas:

• Como cualquier otro plugin: en «Plugins > Añadir plugin > Subir plugin» eliges el zip que lo contiene, lo instalas y lo activas. Es lo más sencillo.
• Como mu-plugin: subes el archivo PHP con el gestor de archivos a la carpeta wp-content/mu-plugins (si no existe, la creas) y listo. Los mu-plugins son plugins «obligatorios», de los que WordPress carga siempre sin que tengas que activarlos.

El código del plugin está en mi GitHub, donde también tienes el zip en descarga directa.

Una vez instalado aparece una página en Herramientas > Revisión de archivos, y cuando pulsas el botón revisa esto:

• Los archivos del núcleo, comparados con los originales de tu versión usando los checksums oficiales de WordPress.org, así que verás los modificados, los que sobran en wp-admin y wp-includes y los que faltan.
• Lo que hay en la raíz y no es de WordPress, marcando las carpetas que tienen PHP dentro.
• Los PHP que haya en wp-content/uploads. La caché de plantillas que guardan ahí algunos plugins, como WPML, la reconoce y no la marca como sospechosa.
• Los trucos de camuflaje de este caso, buscados por contenido: funciones escritas al revés, código escondido en una línea codificada de miles de caracteres, eval() de variables, PHP que empieza como un GIF, el truco de la fecha, php.ini que quitan restricciones, formularios de subida sin control y páginas que piden datos de tarjeta.
• Las copias de wp-config.php con otra extensión, que el servidor puede entregar como texto con la contraseña de la base de datos dentro.
• Los PHP cambiados en los últimos días según el ctime, el que no se puede falsificar.
• Los administradores de WordPress, con su fecha de alta.

Solo mira, no toca nada. No borra, no mueve ni envía nada a ningún sitio, salvo la consulta de los checksums a WordPress.org, y solo se ejecuta cuando un administrador pulsa el botón.

Antes de publicarlo lo he probado con los archivos reales de este caso, que salen todos, y con los 80 plugins más populares de WordPress.org y 20 de los temas más usados, más de 48.000 archivos PHP en los que no da ni un aviso grave en falso.

Lo único que aparece son cuatro avisos de nivel medio por eval(), en plugins como Code Snippets o WPCode que ejecutan código a propósito, y el propio aviso te explica que en esos casos es normal.

Al terminar te enseña un informe con cada hallazgo, qué es y qué hacer, y un botón para copiarlo en texto plano. La idea es que, si no tienes claro qué significa algo, lo pegues en Claude, ChatGPT o la IA que uses y le pidas que te lo explique.

El informe lleva rutas, fechas y el motivo de cada aviso, nunca el contenido de los archivos ni los nombres de usuario, así que no vas a acabar pegando tu wp-config.php en un chat.

Cuando acabes, bórralo (tiene un botón que lo elimina, lo hayas instalado como plugin o como mu-plugin), porque es una herramienta de revisión puntual, no algo para tener instalado.

Y ojo, que no encontrar nada no significa que tu web esté limpia, solo que no tiene nada de lo que este plugin busca.

Si te lías con todo esto, no te compliques. Vigilante compara por su cuenta los archivos del núcleo con los originales y te avisa por correo de lo que sobra, como hizo en este caso, sin subir ningún plugin de revisión, ni exportar informes, ni gastar la suscripción o los tokens de tu IA en interpretarlos.

Si encuentras algo tienes tarea

Sin prisas pero sin pausa, y en este orden:

1. Guarda una copia de lo que encuentres fuera del servidor antes de borrarlo. Te servirá para entender qué ha pasado, y si hace falta para pedir ayuda.
2. Borra lo que sobre: Si está en wp-admin o wp-includes, lo más limpio es sustituir esas dos carpetas enteras por las de una descarga limpia de tu misma versión.
3. Sigue buscando: Repite todas las comprobaciones anteriores, porque donde hay una shell suele haber otra, y esta en concreto sabía copiarse con otro nombre.
4. Revisa los administradores de WordPress y borra cualquiera que no reconozcas.
5. Cambia todas las credenciales: SFTP y SSH, panel del hosting, administradores de WordPress, contraseña de la base de datos y las claves de seguridad (las salts) del wp-config.php. Si no sabes por dónde entraron, es lo razonable aunque no haya indicios de que tocaran nada más.
6. Mira la reputación del dominio en el informe de Navegación Segura de Google y en la sección de problemas de seguridad de Search Console. Cuando borres, las URL del kit devolverán un error 404, que es justo lo que hace falta para que salgan de las listas antiphishing.

El proceso completo, paso a paso, lo tienes en mi guía para limpiar y recuperar un WordPress hackeado o infectado. Y si prefieres no pelearte con ello, para eso está mi servicio de limpieza de WordPress hackeado, aunque con la guía, algo de paciencia, y la hoja de cálculo que tienes aquí para limpiar un WordPress infectado lo puedes hacer tú.

Bueno ¿y de qué me sirve a mi esto?

Llevo más de 20 años con WordPress y mantengo decenas de webs, y nunca había visto algo así, y si no fuese por ese plugin que desarrollé por mis manías de que tengamos buenos plugins gratis, esto podría haber seguido ahí otros cinco años más sin hacer ruido pero robando a mucha gente. No te lo cuento para asustarte, te lo cuento porque actualizar es imprescindible, pero no es lo mismo que estar limpio.

Las actualizaciones cierran puertas, pero es también posible que no limpien lo que ya entró. Para eso hace falta mirar de vez en cuando qué archivos tienes, con un escáner que te avise o a mano, como te he contado arriba, y hacer caso cuando algo te dice que hay un archivo que no debería estar, porque en este caso ese aviso fue lo que destapó todo.

Y no, no hace falta vivir con miedo, en este caso no hubo víctimas registradas que. yo sepa, la web siguió funcionando con normalidad y todo lo que había se limpia con los pasos de arriba. Lo que hace falta es la costumbre de mirar.

Ahora te toca a ti decidir cada cuánto revisas tus webs. Si al lanzar los comandos o el plugin de revisión te aparece algo raro y no sabes qué es, me tienes ahí abajo, en la sección de comentarios.