Te reconozco que esto me tiene bastante molesto. Me los encuentro activos en montones de webs de clientes, funcionando como si fueran un plugin más, a veces incluso cuando lo que hacen ya forma parte de WordPress desde hace tiempo.

Lo mío es casi anecdótico al lado de los números, pues resulta que el plugin Speculative Loading tiene más de 70.000 instalaciones activas pero resulta que la carga especulativa está dentro de WordPress desde la versión 6.8, de abril de 2025 ¿ves el problema?.

Otros plugins experimentales como Performance Lab y Modern Image Formats pasan de las 100.000 cada uno, Gutenberg de las 400.000, y el plugin AI, que no lleva ni un año en el directorio, ya va por las 60.000.

Que conste que no tengo nada contra estos plugins, de ahí han salido algunas de las mejores cosas que ha estrenado WordPress en los últimos años, lo que no me parece ni medio normal es que no avisen de forma clara, y permanente, de lo que son y de lo que no.

Sigo…

Plugins que no son plugins

En WordPress.org se los llama plugins canónicos, y la idea es ya antigua, y te te hablé de ello en 2009, cuando se propuso, así que no me repetiré.

Luego, en 2022 la recuperó Matt Mullenweg en un artículo en Make WordPress, donde los definía como la recomendación oficial para funciones que no tienen por qué estar en el núcleo, con la puerta abierta a entrar en él si triunfan.

Para complicar aún más las cosas, resulta que hay dos familias grandes de estos plugins, que a veces se suelen confundir, pero que en realidad son bastante distintas.

Por un lado están los plugins experimentales del equipo de rendimiento, con Performance Lab como lanzadera, desde el que se instalan los demás y una docena de plugins sueltos (Speculative Loading, Modern Image Formats, Optimization Detective, Image Prioritizer, Enhanced Responsive Images y compañía).

Y luego están los que publica la propia cuenta de WordPress.org, a modo de plugins beta, pero que no siempre lo son tanto, como Gutenberg, el plugin AI o el más reciente MCP Adapter.

Todos tienen algo en común, y es que normalmente no están pensados para ser un producto acabado sino para probar ideas, que algunas veces acabarán en WordPress y otras no.

Lo dicen ellos mismos, aunque en letra pequeña:

• Performance Lab: sus preguntas frecuentes reconocen que «it can mostly be considered a beta testing plugin», o sea, que viene a ser un plugin para probar cosas en beta, y piden prudencia a quien lo use.
• El plugin AI: su readme avisa de que es «an experimental plugin» y recomienda probarlo antes en una web de pruebas.
• Gutenberg: su readme lo presenta como un «beta plugin» para quien quiera probar funciones antes de que salgan. Y en 2021 la propia WordPress.org publicó que «it is not recommended to use the plugin on a site that has launched and is actively in use», es decir, que no lo uses en una web ya publicada y en marcha.

Ni WordPress.org se aclara con el nombre

De verdad es que esto es para mear y no echar gota, pues resulta que en julio de 2025 los responsables del núcleo se reunieron para poner orden en los tipos de plugins oficiales. Dejaron por escrito que los feature plugins (plugins que prueban funciones candidatas al núcleo) son exploratorios y de corto plazo, y que los canónicos tienen soporte oficial y un responsable directo.

Pero el equipo de IA llama canónico a su plugin AI, que según su propio readme es experimental, y en la práctica todo el mundo usa la palabra para lo mismo.

Así que yo, para entendernos, los voy a seguir llamando canónicos, o directamente experimentos. Me refiero a estos, a los de pruebas, no a plugins oficiales como Classic Editor o el importador de WordPress, que son otra cosa y no tienen nada de experimento.

Y si quien los publica no se aclara con el nombre, el que los instala ni te cuento, va listo.

¿Por qué digo que son peores que un plugin en beta?

Pues porque un plugin en beta normal aspira a ser la versión estable de sí mismo. Lo instalas sabiendo que puede tener fallos, pero el plan es que algún día deje de tenerlos y siga ahí, a tu servicio.

Un experimento no tiene ese plan, su objetivo es comprobar si una idea funciona, y acaba en el núcleo, con lo que el plugin sobra, o en la papelera.

Hay casos intermedios, como Modern Image Formats. En 2022 se decidió no convertir las imágenes a WebP por defecto en el núcleo y dejar esa función en un plugin, y ahí sigue, en tierra de nadie, pero con más de 100 mil webs con el plugin instalado, un plugin que nadie mantiene, ni vigila, ni actualiza.

Encima llevan el sello de WordPress.org, que da una confianza que no te daría la beta de un desarrollador cualquiera. Si lo firma WordPress algo bueno tendrá, ¿no?

Ahora bien, todo hay que decirlo, sin estos plugins WordPress habría mejorado bastante más despacio. El atributo fetchpriority (el que le dice al navegador qué imagen cargar primero) llegó al núcleo en la versión 6.3, el sizes="auto" de las imágenes con carga diferida en la 6.7 y la carga especulativa en la 6.8. Todo eso salió de aquí.

Probar en webs reales es como se mejora WordPress, y quien los instala sabiendo lo que hace le está haciendo un favor a todos. El problema no es ese, sino que la gente los instale(mos) sin saberlo, o no todo lo claro que se debería.

¿Por qué no te enteras de que tienes un experimento instalado?

Porque las advertencias están donde no miras. Fíjate en el camino que hace cualquiera desde que busca el plugin hasta que lo tiene funcionando:

• En la página del directorio de plugins: la de Performance Lab no lleva ninguna etiqueta de beta ni de experimento. Lo único es un «(experimental)» junto a View Transitions dentro de la descripción, y el aviso de verdad está en las preguntas frecuentes, al final de la página, en esa sección que no lee nadie.
• En la sección Beta del directorio: existe una sección Beta, pero es un cajón de sastre. Mete plugins cuyo readme parece el de cualquier otro y deja fuera precisamente los plugins de rendimiento con más instalaciones, como Modern Image Formats, Speculative Loading u Optimization Detective. De esa familia solo aparece Performance Lab.
• En el instalador de tu escritorio: en «Plugins > Añadir plugin» existe una pestaña Pruebas beta, pero WordPress solo la enseña si tu versión lleva un guion en el número, es decir, en versiones de desarrollo como una beta o una RC. En una web en producción esa pestaña no aparece nunca.
• En la lista de plugins instalados: lo único que ves es la descripción. La del plugin AI dice «AI features, experiments and capabilities for WordPress» y la de Performance Lab «Performance plugin from the WordPress Performance Team» (que suena más a garantía que a aviso). Las de Speculative Loading o Modern Image Formats no dan ninguna pista. Solo Gutenberg se presenta como «development plugin», y Optimization Detective, Image Prioritizer y Embed Optimizer llevan un «-beta» en el número de versión.
• Dentro del propio plugin: en los ajustes del plugin AI, «Experimentos en el editor» y «Experimentos en la administración» son el nombre de dos grupos de funciones, no un aviso. Lo de probarlo antes en una web de pruebas solo está en el readme.

Y lo saben sus equipos, no es algo que se les haya pasado. En abril de 2025, en otra de esas reuniones de los responsables del núcleo, quedó escrito que «It’s often not widely known that canonical plugins exist or that they are officially maintained» (poca gente sabe que existen o que son oficiales).

También que «Feedback is mainly received from users when something breaks», o sea, que las opiniones de los usuarios les llegan sobre todo cuando algo se rompe.

Su conclusión entonces fue que había que promocionarlos más, y en julio se pusieron como siguiente paso redactar los criterios para clasificar los plugins oficiales en canónicos, de funciones, experimentales y de soporte. Quince meses después, que yo sepa, esos criterios siguen sin publicarse.

Promocionarlos me parece bien, pero promocionarlos sin etiquetarlos adecuadamente es justo lo que nos ha traído hasta aquí.

Lo que te puede pasar con uno de estos plugins activo

No quiero meterte miedo, que la mayoría hace lo que promete y hay muchas webs usándolos sin problemas. Pero conviene que sepas qué estás aceptando, porque no es algo trivial, en muchas ocasiones es incluso perjudicial usar estos plugins si no tienes 100% claro lo que supone.

Te cambian la web nada más activarlos

Modern Image Formats es el ejemplo más claro. Con la configuración por defecto cada imagen que subas a partir de ese momento se guarda en WebP o AVIF (formatos de imagen modernos que pesan menos), en todos sus tamaños, incluida la versión principal que usa WordPress. El JPEG o PNG que subiste se conserva como original, pero WordPress deja de usarlo.

Y ojo, porque desactivarlo o desinstalarlo no deshace nada. Las imágenes que subiste con el plugin activo se quedan en WebP o AVIF y WordPress las sigue sirviendo así. No se rompe nada, los navegadores actuales las leen sin problema, pero no es un cambio que quites con un clic.

Speculative Loading es otro de los puñeteros, especialmente. La carga especulativa nativa de WordPress solo hace prefetch (descargar por adelantado el HTML de la página a la que seguramente vas a ir) y de forma prudente, cuando ya estás pulsando el enlace. El plugin, en cambio, hace prerender por defecto, que es cargar la página entera en segundo plano, con sus scripts y todo, en cuanto pasas el ratón por encima.

Es más rápido, pero tiene su precio. En 2024 el plugin hizo que en tiendas WooCommerce se añadieran productos al carrito solo con pasar el ratón por encima, sin hacer clic. Lo corrigieron rápido, eso sí, pero sigue abierta otra incidencia en la que el carrito y la página de pago, precargados, muestran datos del pedido desfasados.

Cambian las reglas sin avisar, o desaparecen

El plugin AI lo deja claro en su documentación sobre el ciclo de vida de sus experimentos, donde dice que están «subject to breaking changes or removal without notice», expuestos a cambios que rompen cosas o a desaparecer sin previo aviso. Se comprometen a intentar que esos cambios lleguen en versiones mayores, que algo es.

Un ejemplo de hace unos días. En la versión 1.4.0, por un cambio en Gutenberg, las directrices editoriales que tuvieras guardadas para la IA hay que volver a meterlas a mano, porque no se migran. Dos experimentos encadenados, y el que paga el pato eres tú.

Luego está lo de desaparecer. Web Worker Offloading, otro plugin del equipo de rendimiento con más de 10.000 instalaciones, avisa en su readme de que es experimental y de que está «intended to be sunset», en vías de retirada. Al menos lo dicen, aunque solo se entera quien se lee el readme.

Que un plugin normal cambie las reglas o se abandone es un accidente, en un experimento cambiar o desaparecer entra dentro del plan, es lo esperado, salvo por el detalle de que no siempre te informa como debería.

Duplican o pisan a tus otros plugins

El plugin AI, por ejemplo, tiene un experimento que genera con IA la meta description de tus entradas. Si detecta Yoast, Rank Math, All in One SEO o SEOPress, la guarda en el campo de ese plugin y no imprime nada por su cuenta, que está bien.

Pero si usas otro plugin de SEO, como The SEO Framework o Slim SEO, el plugin AI imprime su propia meta description y esa entrada sale con dos. Pasa solo si activas el experimento y aplicas una descripción generada, pero pasa, y tener dos meta description en la misma página no es nunca buena idea.

Tiene arreglo, eso sí, aunque está en manos del desarrollador de tu plugin de SEO. El plugin AI incluye un filtro, wpai_meta_description_seo_plugins, con el que cualquier plugin de SEO puede apuntarse a esa lista, y a partir de ese momento la descripción generada se guarda en su campo y no se duplica.

Es lo que he hecho yo con Visibility, y son unas pocas líneas de código, así que si tu plugin de SEO no está entre los cuatro de antes, pídeselo a quien lo desarrolla.

Con los plugins de rendimiento pasa algo parecido. Image Prioritizer decide qué imágenes cargar primero y cuáles retrasar, igual que hacen muchos plugins de optimización, y ya te conté en el artículo sobre por qué WordPress todavía no acierta con el LCP cómo pueden pisarse entre ellos.

Tienen un coste aunque no los uses

En la versión actual del plugin AI, cada función que no has activado nunca cuesta una consulta a la base de datos en cada visita, también en la parte pública. Ocurre en webs sin caché de objetos persistente (tipo Redis o Memcached). Con 21 funciones son 21 consultas por página en una instalación recién estrenada, y además te deja dos widgets fijos en el escritorio.

El arreglo de las consultas ya está hecho y llegará en una próxima versión, y con caché de objetos el problema casi desaparece. Aun así, es un buen ejemplo de que tener un experimento activo sin usarlo no sale gratis.

Y ojo con lo que dice su propia FAQ, que sus funciones «require manual triggering – nothing happens automatically without your approval», o sea, que solo se ponen en marcha si tú lo pides y que nada pasa solo sin tu aprobación.

Activar un experimento ya es aprobarlo, vale, pero la moderación de comentarios analiza cada comentario nuevo que no esté ya marcado como spam, también los de visitantes sin registrar, y cada uno de esos comentarios viaja a tu proveedor de IA y puede costarte tokens.

Optimization Detective funciona con datos de tus visitantes reales. Para eso necesita la API REST de tu web abierta a cualquiera, y los navegadores de tus visitas le envían métricas que se guardan en tu base de datos. Tiene sus límites (una petición por minuto por IP, y borra lo que tiene más de tres meses), pero son escrituras en tu base de datos que antes no tenías.

Como ves, no son algo que no afecte a tu web, sí pasa algo si los dejas ahí.

Gutenberg, el experimento con más instalaciones

El plugin Gutenberg es el abuelo de todos, con más de 400.000 instalaciones activas. Su propio readme te explica que no te hace falta para usar el editor de bloques, porque cada versión de WordPress ya incluye lo que está listo, y que solo lo necesitas si quieres las funciones en beta sin esperar a WordPress, pero a riesgo de que luego algo no llegue o llegue diferente.

En noviembre de 2022 pasó lo que tenía que pasar. Las webs con una versión antigua del plugin que se actualizaron solas a WordPress 6.1 se quedaron con un error fatal, sin acceso ni a la portada ni al escritorio. La solución pasó por que WordPress desactive al actualizarse las versiones de Gutenberg que se han quedado demasiado viejas, que algo hemos ganado.

Cuando su funcionalidad llega a WordPress el plugin sigue ahí

Esto es lo más delicado, cuando una funcionalidad llega al núcleo de tu WordPress, el plugin que la probaba sigue activo en miles de webs, como un zombi, y como mucho deja una notita en el readme.

Lo más triste es que antes se hacía bien. WP Auto-Updates y Plugin Dependencies, dos plugins de funciones que acabaron en WordPress 5.6 y 6.5, se desactivaban solos al detectar que su función ya estaba en el núcleo.

Better Code Editing mostraba un aviso en el escritorio diciendo, literal, que su función ya estaba en el núcleo y que se podía desactivar y desinstalar.

Hasta el propio manual del núcleo sobre plugins de funciones pide que el plugin deje de hacer nada en cuanto su funcionalidad entra en WordPress.

Ahora mira lo que pasa con los del equipo de rendimiento:

• Speculative Loading: su readme reconoce que la carga especulativa entró en WordPress 6.8, pero el plugin sigue activo en más de 70.000 instalaciones sin avisar de nada, y encima sustituye la configuración prudente del núcleo por la suya, más agresiva.
• Enhanced Responsive Images: lo de sizes="auto" entró en WordPress 6.7, y lo único que sigue aportando el plugin, según su propio readme, no está disponible para temas clásicos. Tiene más de 50.000 instalaciones, y en cualquier web con tema clásico no hace nada.
• Performant Translations: su readme avisa de que casi todo entró en WordPress 6.5 y de que «You might not need it anymore». Es verdad que sigue sirviendo para traducciones que no vienen de WordPress.org, pero el aviso está donde no lo lee ni el tato.

Yo mismo, con un plugin mío bastante más modesto, saqué una última actualización con un aviso antes de cerrarlo, para que nadie se quedara con un plugin muerto sin enterarse.

Si lo hace un desarrollador cualquiera como yo, el equipo oficial de WordPress también puede. Dejar zombis repartidos por miles de webs me parece mala política, y no hay más.

Si lo que cuenta es la adopción, que al menos sea informada

Hay un detalle que me parece importante, y es que en la hoja de ruta de WordPress 7.2 se dice que las funciones de IA tienen que demostrar «clear adoption and practical value» antes de plantearse para el núcleo, y se anima a la gente a usar y probar el plugin AI.

En aquella reunión de abril de 2025 reconocían que las instalaciones activas son «currently the only metric available», la única métrica que tienen.

No digo que nadie esté inflando nada a propósito, ni mucho menos, pero si las instalaciones cuentan como prueba de que algo funciona, 60.000 instalaciones de un plugin experimental no son 60.000 personas probando algo a sabiendas.

Si las instalaciones activas son la prueba de que un experimento funciona, lo mínimo es que quien lo instala sepa que está participando en una prueba.

Mi propuesta, que no es para volverse loco

No pido que dejen de hacer estos plugins, ni que dejen de promocionarlos, que son más qué útiles, solo pido que sean explícitos, y lo concreto en seis cosas:

1. Una etiqueta visible en el directorio: en la ficha de cada plugin, arriba y a la vista, no escondida en las preguntas frecuentes, y también en los resultados del instalador, no solo en una pestaña que en producción no existe.
2. Un aviso permanente en la lista de plugins: una línea fija debajo del plugin, que no se pueda cerrar, diciendo que es un plugin de pruebas.
3. Una explicación al activarlo: qué es, para qué sirve probarlo y qué riesgos tiene usarlo en una web en producción.
4. Etiquetas distintas para cosas distintas: no es lo mismo un experimento que una función candidata al núcleo o un plugin oficial estable, y hoy todo cabe en el mismo cajón de «Beta».
5. Avisar y apartarse cuando su función entra en el núcleo: como hacían los plugins de funciones antiguos y como pide el propio manual.
6. Publicar los criterios prometidos en julio de 2025: los de clasificación de los plugins oficiales, que siguen sin aparecer.

Lo bueno es que los puntos 2, 3 y 5 no necesitan tocar el núcleo de WordPress, los puede hacer hoy mismo cada equipo en sus propios plugins. De hecho el equipo de rendimiento ya marca como experimentales algunos de sus plugins, pero solo dentro de la pantalla de Performance Lab, donde View Transitions sale con su «(experimental)». Se trata de llevar esa etiqueta al propio plugin.

He abierto una incidencia en el GitHub del equipo de rendimiento con esta propuesta, y otra en el del plugin AI (donde han contestado y parece que lo contemplarán). En esta última pido además que cada experimento diga si se ejecuta solo, qué contenido envía al proveedor de IA y si puede gastar tokens sin que nadie haga nada.

Si estás de acuerdo pásate por ambos y deja tu comentario, que un caso real bien explicado vale más que un pulgar hacia arriba.

Mientras tanto, revisa tu web (o las de tus clientes)

Hasta que cambie algo te toca a ti. Para reconocerlos fíjate en estas señales:

• En el directorio el autor es «WordPress Performance Team» o «WordPress.org».
• El número de versión lleva «-beta».
• Las preguntas frecuentes o el readme hablan de beta, de experimento o de probarlo antes en una web de pruebas.
• Aparece en la sección Beta del directorio, aunque ya has visto que no están todos.

Esto es lo que yo haría con los más habituales:

• Speculative Loading: si tienes WordPress 6.8 o posterior, tu web ya precarga páginas sin el plugin. Quédatelo solo si quieres su modo más agresivo y lo has probado bien, sobre todo si tienes tienda. Y si prefieres quitar también la nativa, te lo cuento en cómo desactivar la carga especulativa de WordPress.
• Enhanced Responsive Images: si tu tema es clásico, desactívalo, porque lo que añade no funciona con temas clásicos. Con un tema de bloques, decide si te compensa.
• Performant Translations: solo tiene sentido si usas plugins o temas con traducciones que no vienen de WordPress.org.
• Modern Image Formats: si lo quieres, que sea sabiendo que convierte tus imágenes a partir de ese momento y que quitarlo no lo deshace.
• Optimization Detective, Image Prioritizer y Embed Optimizer: llevan la beta en el número de versión, así que trátalos como tal.
• El plugin AI: pruébalo antes en una web de pruebas, y si lo usas en producción, revisa qué experimentos tienes activos en «Ajustes > IA».
• Gutenberg: si no desarrollas ni pruebas funciones nuevas, no lo necesitas, que el editor ya viene con WordPress.

Si quieres que tu escritorio te diga lo que WordPress.org no te dice, aquí tienes un fragmento de código que añade una nota debajo de cada uno de estos plugins en la lista de plugins instalados. Si además su función, o parte de ella, ya está en tu versión de WordPress, añade una segunda nota que te lo avisa:

/**
 * Etiqueta plugins de prueba de WordPress.org (canonical, feature o experimentales) en la pantalla de plugins
 *
 * Añade una etiqueta roja bajo cada plugin de la lista, y cuando su funcionalidad ya es
 * parte del núcleo de WordPress, y una segunda ficha te avisa también de esto
 */

/**
 * Lista de plugins de pruebas de WordPress.org, anotados por su carpeta de plugin
 * Añade más al array si sale alguno nuevo
 *
 * 'core' es una función o clase que solo existe cuando la funcionalidad (o parte
 * de ella) ya está en el core. 'note' es el texto mostrado en su caso
 *
 * @return array
 */
function ayudawp_test_plugins() {
	$plugins = array(
		'gutenberg'               => array(),
		'performance-lab'         => array(),
		'webp-uploads'            => array(),
		'speculation-rules'       => array(
			'core' => 'wp_get_speculation_rules_configuration',
			'note' => 'Ya está en tu WordPress, y este plugin cambia su configuración',
		),
		'optimization-detective'  => array(),
		'image-prioritizer'       => array(),
		'embed-optimizer'         => array(),
		'dominant-color-images'   => array(),
		'auto-sizes'              => array(
			'core' => 'wp_sizes_attribute_includes_valid_auto',
			'note' => 'Parte ya está en tu WordPress, el resto solo sirve con temas de bloques',
		),
		'view-transitions'        => array(),
		'web-worker-offloading'   => array(),
		'nocache-bfcache'         => array(),
		'performant-translations' => array(
			'core' => 'WP_Translation_Controller',
			'note' => 'Casi todo ya está en tu WordPress',
		),
		'ai'                      => array(),
		'mcp-adapter'             => array(),
	);

	return apply_filters( 'ayudawp_test_plugins', $plugins );
}

/**
 * Añade las etiquetas a la fila de datos del plugin
 *
 * @param array  $meta        Datos meta en la ficha de plugins
 * @param string $plugin_file Archivo del plugin relativo al directorio de plugins
 * @return array
 */
function ayudawp_flag_test_plugins( $meta, $plugin_file ) {
	$plugins = ayudawp_test_plugins();
	$folder  = dirname( $plugin_file );

	if ( ! isset( $plugins[ $folder ] ) ) {
		return $meta;
	}

	$meta[] = '<span class="ayudawp-badge ayudawp-badge-test">' . esc_html( 'Plugin de pruebas de WordPress.org' ) . '</span>';

	$plugin = $plugins[ $folder ];
	if ( ! empty( $plugin['core'] ) && ( function_exists( $plugin['core'] ) || class_exists( $plugin['core'], false ) ) ) {
		$meta[] = '<span class="ayudawp-badge ayudawp-badge-core">' . esc_html( $plugin['note'] ) . '</span>';
	}

	return $meta;
}
add_filter( 'plugin_row_meta', 'ayudawp_flag_test_plugins', 10, 2 );

/**
 * Estilos de las etiquetas para que se vean bien
 *
 * @param string $hook_suffix Current admin page.
 */
function ayudawp_test_plugins_styles( $hook_suffix ) {
	if ( 'plugins.php' !== $hook_suffix ) {
		return;
	}

	wp_register_style( 'ayudawp-test-plugins', false, array(), '1.0' );
	wp_enqueue_style( 'ayudawp-test-plugins' );
	wp_add_inline_style(
		'ayudawp-test-plugins',
		'.ayudawp-badge{display:inline-block;padding:2px 10px;border-radius:999px;color:#fff;font-size:12px;font-weight:600;line-height:1.6;}
		.ayudawp-badge-test{background:#b32d2e;}
		.ayudawp-badge-core{background:#8a4b00;}'
	);
}
add_action( 'admin_enqueue_scripts', 'ayudawp_test_plugins_styles' );

Si no sabes muy bien dónde pegarlo, lo tienes explicado en ¿Plugin, functions.php, plugin de snippets o mu plugin? ¿dónde meto ese código en WordPress?.

La lista va escrita a mano, así que si sale un plugin nuevo de este tipo puedes añadirlo con el filtro ayudawp_test_plugins.

Por cierto, si lo que te preocupa es que alguno de los plugins que usas se cierre en el directorio y te quedes sin actualizaciones sin enterarte, de eso ya te avisa Vigilante, mi plugin de seguridad, más majo él.

La decisión, como siempre, es tuya

Probar está bien, y alguien tiene que hacerlo, pero lo que no tiene sentido es tener un experimento en producción sin saberlo, y menos aún cuando ya ni siquiera hace falta.

Revisa lo que tienes, decide con datos y, si estás de acuerdo con la propuesta, échale una mano en la incidencia. Y si no estás de acuerdo, si me he dejado algún plugin en el tintero, me tienes ahí abajo, en la sección de comentarios.

Ojalá dentro de un tiempo este artículo deje de tener sentido.

Aceptas, pasas a la siguiente pantalla y vuelta a empezar, aunque seas administrador y la web te deje hacer todo lo demás.

La culpa no es tuya ni de WordPress, es casi seguro del tema, que carga en todo el escritorio un script que comprueba si puedes instalar plugins y, si no puedes, te lo suelta en un aviso. Y sí, aun siendo administrador hay situaciones en las que WordPress no te deja instalar plugins.

Me lo encontré hace poco en la web de un cliente del servicio de mantenimiento, y te reconozco que al principio no le veía ningún sentido, porque yo tenía permisos completos y podía entrar en todas partes.

Vamos a ver de dónde sale y cómo quitártelo de encima sin romper nada.

De dónde sale el aviso (y por qué no es de WordPress)

La primera pista está en el propio mensaje, que sale en inglés en un escritorio en español. Los mensajes de permisos del núcleo llegan traducidos («Lo siento, no tienes permisos…» y así), por lo que que si ves un error de permisos en inglés en un WordPress en español, lo más probable es que venga de un tema o de un plugin.

En el caso que me tocó era el tema, que hace esto en cada pantalla del escritorio:

1. Carga un archivo JavaScript, plugin-installer.js, en todas las pantallas de administración y no solo en las suyas.
2. Al cargar la página ese script pregunta por AJAX (una petición en segundo plano a admin-ajax.php) si está instalado el plugin complementario del tema.
3. Antes de contestar, el código del servidor comprueba si el usuario puede instalar plugins. Si no puede, devuelve el error y el script te lo enseña con un alert(), esa ventana del navegador que no te deja hacer nada hasta que pulsas Aceptar.

¿Y por qué te lo pregunta a ti, que solo has entrado a editar una página? Pues porque el script no mira dónde estás ni qué vas a hacer, salta en todas partes y con todo el mundo.

Fíjate además en un detalle, porque el mensaje dice «manage» (gestionar), pero lo que se comprueba es si puedes instalar plugins, que no es lo mismo, y ahí está la clave de todo esto.

Si soy administrador, ¿por qué no puedo instalar plugins?

Esto tiene su gracia, o no, bueno, mola, eso seguro. Gestionar plugins (activarlos y desactivarlos) e instalarlos son permisos distintos, y hay situaciones en las que WordPress te quita el de instalar aunque tengas el perfil más alto.

WordPress no decide los permisos solo mirando el perfil. El perfil de administrador incluye la capacidad install_plugins, pero cuando un código pregunta current_user_can( 'install_plugins' ) la respuesta pasa antes por la función map_meta_cap(), que tiene en cuenta el contexto.

Y si en el wp-config.php está definida la constante DISALLOW_FILE_MODS a true, la respuesta es que no, para todo el mundo, administradores incluidos.

Esa constante bloquea cualquier cambio de archivos desde el escritorio, o sea, instalar, actualizar o borrar plugins y temas, actualizar el núcleo y usar el editor de archivos, genial ¿no?. Con ella activa sigues pudiendo activar y desactivar plugins desde el menú de plugins, pero desaparece «Añadir nuevo plugin».

En mi caso la había activado ManageWP, pero puede venir del hosting, de un plugin de seguridad o de alguien que la puso a mano en el wp-config.php.

Y que conste que DISALLOW_FILE_MODS es una buena medida de seguridad, porque si alguien consigue entrar en tu escritorio no puede instalarte un plugin con una puerta trasera ni meter código en un archivo del tema. El precio es que las actualizaciones tienes que hacerlas por otra vía, y quien la activa suele tenerlo resuelto.

Hay dos casos más en los que vas a ver el aviso sin que haya constante de por medio:

• Usuarios que no son administradores: editores, autores o gestores de tienda no pueden instalar plugins, así que les sale en cada pantalla.
• Multisitio: en una red solo el superadmin puede instalar plugins, así que los administradores de cada sitio también lo sufren.

Cómo saber si te pasa

Antes de tocar nada compruébalo, que es un momento:

• El menú «Plugins»: si no te aparece «Añadir nuevo plugin», no tienes permiso para instalar.
• La petición que lo dispara: abre las herramientas para desarrolladores del navegador (F12 en casi todos), ve a la pestaña Red, filtra por admin-ajax y recarga la página. Si ves una petición cuya acción termina en _check_plugin_status (o algo parecido) y su respuesta trae el mensaje, ya tienes al culpable, y en la columna Iniciador verás qué script la ha lanzado.
• WP-CLI: si lo usas (sí, esa herramienta que no usa ni el tato y que en estos casos te ahorra un buen rato, y así de paso me salió un pareado), ejecuta el comando que tienes justo debajo con tu usuario.

wp eval 'var_dump( defined( "DISALLOW_FILE_MODS" ) && DISALLOW_FILE_MODS, current_user_can( "install_plugins" ) );' --user=tu_usuario

Si te devuelve bool(true) y bool(false), la constante está activa y tu usuario no puede instalar plugins. Caso cerrado. Si quieres sacarle más partido a la línea de comandos, tienes mi tutorial de WP-CLI.

Lo que no deberías hacer

Hay tres formas rápidas de quitarte el aviso de encima, pero ninguna es buena idea:

• Quitar la constante: el aviso desaparece, sí, pero cambias seguridad por comodidad. Es peor el remedio que la enfermedad.
• Dar permiso para instalar plugins a editores y compañía: con un plugin de gestión de perfiles se puede, y lo he visto recomendar en algún foro de soporte, pero es abrir la puerta de par en par para dejar de oír el timbre.
• Editar el functions.php del tema: funciona hasta la siguiente actualización del tema, que te lo deja como estaba.

Si la constante está ahí por seguridad, lo que sobra es el aviso, no la constante.

La solución es quitar lo que realmente sobra, esa birria de script

Lo limpio es que el script del tema no se cargue cuando el usuario no puede instalar plugins, y no pierdes nada, porque el botón del tema para instalar su plugin tampoco te iba a funcionar.

Lo hago con un mu-plugin (must-use plugin, un plugin que WordPress carga siempre y que no se puede desactivar desde el escritorio, como te explico aquí). Así no depende del tema, sobrevive a sus actualizaciones y nadie lo desactiva por error.

1. Entra en la carpeta wp-content por FTP, por SSH o con el administrador de archivos del hosting.
2. Si no existe la carpeta mu-plugins, créala.
3. Crea dentro un archivo PHP, por ejemplo silenciar-instalador-tema.php, con el código que tienes a continuación.

<?php
/**
 * Plugin Name: Silenciar instalador de plugins del tema
 * Description: Evita el aviso «You do not have permission to manage plugins» cuando el usuario no puede instalar plugins.
 */

defined( 'ABSPATH' ) || exit;

add_action( 'admin_enqueue_scripts', 'ayudawp_dequeue_theme_plugin_installer', 100 );

function ayudawp_dequeue_theme_plugin_installer() {
	if ( current_user_can( 'install_plugins' ) ) {
		return;
	}

	$scripts   = wp_scripts();
	$theme_uri = get_template_directory_uri();

	foreach ( $scripts->queue as $handle ) {
		if ( ! isset( $scripts->registered[ $handle ] ) ) {
			continue;
		}

		$src = (string) $scripts->registered[ $handle ]->src;

		if ( str_starts_with( $src, $theme_uri ) && str_ends_with( $src, 'plugin-installer.js' ) ) {
			wp_dequeue_script( $handle );
		}
	}
}

Guarda, recarga el escritorio y el aviso no debería volver a salir.

Por si quieres entender lo que subes (que deberías, nunca pegues código sin saber qué hace), esto es lo que hace:

• • Si el usuario puede instalar plugins, no hace nada y el tema funciona como siempre.
  • Si no puede, repasa los scripts que se van a cargar en esa pantalla y quita los que salen de la carpeta del tema y terminan en plugin-installer.js.

• Se engancha con prioridad 100 para ejecutarse después de que el tema haya encolado su script, cosa que hace con la prioridad normal, 10.
• Compara con la carpeta del tema padre (get_template_directory_uri()), que es desde donde lo carga el tema, así que funciona igual con un tema hijo activo.
• str_starts_with() y str_ends_with() son funciones de PHP 8, pero WordPress las incluye por su cuenta desde la versión 5.9, así que no hay problema con PHP 7.

Nota: si en tu caso el script se llama de otra forma, lo localizas con la columna Iniciador que te comentaba antes. Cambia plugin-installer.js por el nombre que corresponda y listo. Y si algún día quitas la constante, el script vuelve a cargarse solo, sin tocar nada más.

Un apunte para quien desarrolla temas

Comprobar los permisos en el servidor antes de instalar nada está bien hecho, eso hay que reconocerlo. Lo que sobra es lo demás, porque un script que solo sirve en un par de pantallas del tema no tiene por qué cargarse en todo el escritorio, ni preguntar nada a quien no puede instalar plugins, y mucho menos contestarle con un alert() con el que no puede hacer nada salvo aceptar.

Lo correcto sería comprobar current_user_can( 'install_plugins' ) antes de encolar el script y cargarlo solo en las pantallas donde se usa.

Si el tema que usas hace esto, cuéntaselo a su desarrollador, que es un cambio pequeño y le ahorra el mal rato a mucha gente.

Para cualquier duda, o si te ha salido algo parecido con otro tema o con otro mensaje, me tienes ahí abajo, en los comentarios. Un aviso menos, y a otra cosa.

Últimamente me lo estoy encontrando bastante, en varios clientes distintos del servicio de mantenimiento y con la misma dinámica, y como ya tengo visto el problema y varias posibles soluciones creo que ya tocaba compartirlo.

Te cuento qué pasa, cómo comprobar si te afecta y cómo parar esta locura, que lo es, y que puede tirar abajo prácticamente cualquier tienda online.

Culpable: un filtro que crea URLs a lo loco

El filtro por atributos clásico de WooCommerce, el que te deja elegir talla, color o lo que tengas, funciona con enlaces normales y sin AJAX (la técnica que actualiza una página sin recargarla).

Cada vez que marcas una opción de selección de atributo se carga una dirección nueva con los parámetros del filtro, como esta:

/categoria-producto/camisetas/?filter_color=azul,rojo&query_type_color=or&filter_talla=m,l&query_type_talla=or

Con 10 tallas hay 1.023 formas de marcar al menos una, con 30 ya son 1.073.741.823, y eso con un solo atributo, porque al sumar color, material y compañía las combinaciones se multiplican entre sí. Nadie las va a probar todas salvo un robot que no se cansa ni tiene pausas para el almuerzo, y aquí empieza el problema.

Lo que genera el problema es la suma de tres factores:

1. Combinaciones casi infinitas: el número de URLs posibles es enorme, pero a un robot no le cuesta nada solicitarlas.
2. Enlaces que cualquiera puede seguir: el widget clásico de atributos marca los enlaces del filtro con rel="nofollow", pero eso es una pista y no una barrera, porque nada obliga a un robot a hacerle caso. Además, según la documentación de Google sobre navegación por facetas el atributo solo funciona si lo lleva cada enlace que apunta a esa dirección.
3. Casi ninguna se sirve desde caché: con tantas direcciones distintas, una caché de página casi nunca tendrá la copia lista cuando llega el robot, y WordPress y WooCommerce montan cada página desde cero. Google lo resume diciendo que rastrear este tipo de direcciones suele costar al sitio muchos recursos de cómputo.

Con toda esta tormenta perfecta la cuenta de tu web en el hosting se puede quedar sin cuota de CPU o de procesos y el servidor empieza a rechazar visitas.

El síntoma típico es el error 508, Resource Limit Is Reached, que significa que tu cuenta ha superado alguno de sus límites de recursos.

Este problema (gordo) tiene incluso nombre y apellido, trampa de rastreo (crawl trap, si buscas en inglés), y consiste básicamente en que un robot que sigue enlaces puede meterse en un laberinto con casi infinitas salidas.

Para tumbar una tienda no hace falta un ataque enorme

Cuando una tienda se cae así cualquiera pensaría en un ataque DDoS (un ataque de denegación de servicio, con montones de máquinas pidiendo cosas a la vez para colapsar tu web), pero en realidad hace falta mucho menos.

Una página que ya está almacenada en caché la sirve cualquier hosting a un ritmo altísimo, pero una que WordPress y WooCommerce tienen que montar desde cero, con sus consultas a la base de datos, cuesta muchísimo más.

Si todas las peticiones son de las segundas, sin caché, un hosting compartido, e incluso muchos Cloud y VPS, con sus cuotas de recursos asignadas, aguanta mucho menos.

Los que recorren esas direcciones son de dos tipos, por un lado están los rastreadores conocidos como Googlebot o el agente de Meta (meta-externalagent), y cada vez más los rastreadores de las IAs, que al menos te dicen quiénes son.

Y luego están los robots que se hacen pasar por un navegador corriente y no se identifican. Por eso conviene bloquear por el patrón de la dirección y no por quién la pide, porque a los segundos no hay forma fiable de reconocerlos.

Si te interesa ver cuáles de esos rastreadores de IA te visitan y poder cerrarles el paso, mi plugin VigIA detecta más de 60 por su identificador y permite bloquearlos. Pero lo hace por quién pide y no por la dirección, así que no sustituye a las capas de más abajo, y no ve a los que se hacen pasar por un navegador ni a Googlebot.

Dos pistas que delatan el problema son, por un lado picos de peticiones a horas en las que no compra nadie, y por otro visitas masivas desde países donde no vendes, si tu hosting o tu CDN te dejan ver de dónde llegan.

Cómo saber si estás sufriendo una trampa de rastreo debido a los filtros de atributos

Los registros de acceso (la lista de todo lo que ha pedido cada visitante) lo dirían todo, pero leerlos mediante comandos de consola no es para todo el mundo, y hay alternativas más cómodas, de menos a más esfuerzo. Te las cuento, porque yo suelo también usarlas así, en este orden creciente.

La prueba de la barra de direcciones

Entra en una categoría de tu tienda, marca una opción del filtro y mira la barra de direcciones. Si aparece algo como ?filter_color=azul, tu filtro escribe la selección en la dirección, la causa del problema del que estamos hablando.

Para saber si los robots pueden llegar hasta ahí, pulsa Ctrl+U en Chrome o Firefox (en Mac, Cmd+Option+U en Chrome y Cmd+U en Firefox) para ver el código fuente de la página, busca filter_ y fíjate en si lo que encuentras son enlaces (<a href="…filter_…").

Si tus enlaces son de ese tipo un robot puede seguirlos y deberías seguir leyendo esta guía. Si no hay ninguno el riesgo es menor, pero no des el caso por cerrado sin mirar los registros o el contador del que te hablo más abajo.

Los registros de tu hosting

Si en el panel de tu hosting puedes descargar o ver los registros de acceso, ábrelos con un editor de texto y busca filter_. Si lo llevan la mayoría de las líneas, ya sabes cuál es tu problema.

Mini plugin para tener un contador con el que diagnosticar el problema

Si no tienes acceso a los registros, o prefieres una cifra clara, puedes poner a contar a la propia web con un pequeño plugin de un solo archivo.

Crea en tu ordenador un archivo de texto llamado ayudawp-filter-detector.php con este contenido, súbelo a la carpeta wp-content/plugins con el gestor de archivos de tu hosting o por FTP, o si lo prefieres lo comprimes en un zip y lo instalas como como siempre, y actívalo en la pantalla de plugins.

<?php
/**
 * Plugin Name: AyudaWP Detector de filtros
 * Plugin URI:  https://plugins.ayudawp.com
 * Description: Diagnóstico temporal. Cuenta las peticiones públicas con parámetros de filtro de WooCommerce y muestra el total en el escritorio.
 * Version:     1.0.0
 * Author:      Fernando Tellado
 * Author URI:  https://ayudawp.com
 * License:     GPL-2.0-or-later
 */

if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

/**
 * Indica si los parámetros incluyen algún nombre filter_*.
 *
 * Lee los parámetros ya interpretados por PHP, igual que WooCommerce.
 *
 * @param array $params Parámetros de la petición ($_GET).
 * @return bool
 */
function ayudawp_fd_has_filter( array $params ): bool {
	foreach ( array_keys( $params ) as $name ) {
		if ( 0 === strpos( (string) $name, 'filter_' ) ) {
			return true;
		}
	}
	return false;
}

/**
 * Cuenta la petición y guarda las últimas direcciones. No guarda IP ni navegador.
 *
 * El recuento es aproximado: dos peticiones simultáneas pueden pisarse.
 */
function ayudawp_fd_record(): void {
	if ( is_admin() || wp_doing_ajax() || wp_doing_cron() ) {
		return;
	}

	// phpcs:ignore WordPress.Security.NonceVerification.Recommended -- Solo se leen nombres de parámetros, no se guarda ni se muestra nada.
	if ( ! ayudawp_fd_has_filter( $_GET ) ) {
		return;
	}

	$uri = ( isset( $_SERVER['REQUEST_URI'] ) && is_string( $_SERVER['REQUEST_URI'] ) )
		? esc_url_raw( wp_unslash( $_SERVER['REQUEST_URI'] ) )
		: '';

	$stats = get_transient( 'ayudawp_fd_stats' );
	if ( ! is_array( $stats ) ) {
		$stats = array(
			'since' => time(),
			'count' => 0,
			'last'  => array(),
		);
	}

	++$stats['count'];
	array_unshift( $stats['last'], substr( $uri, 0, 150 ) );
	$stats['last'] = array_slice( $stats['last'], 0, 10 );

	set_transient( 'ayudawp_fd_stats', $stats, WEEK_IN_SECONDS );
}
add_action( 'init', 'ayudawp_fd_record' );

/**
 * Muestra las cifras en el escritorio, solo a administradores.
 */
function ayudawp_fd_notice(): void {
	global $pagenow;

	if ( 'index.php' !== $pagenow || ! current_user_can( 'manage_options' ) ) {
		return;
	}

	$stats = get_transient( 'ayudawp_fd_stats' );
	if ( ! is_array( $stats ) || empty( $stats['count'] ) ) {
		echo '<div class="notice notice-info"><p><strong>AyudaWP.com - Detector de filtros</strong></p>';
		echo '<p>Activo, pero todavía no ha contado ninguna petición con parámetros de filtro. Un cero no descarta el problema: si hay una caché, Cloudflare, el .htaccess o el plugin de bloqueo por delante, esas peticiones no llegan hasta aquí.</p></div>';
		return;
	}

	echo '<div class="notice notice-warning"><p><strong>AyudaWP.com - Detector de filtros</strong></p><p>';
	printf(
		'Peticiones con parámetros de filtro: %1$s (desde el %2$s).',
		esc_html( number_format_i18n( (int) $stats['count'] ) ),
		esc_html( wp_date( 'j/n/Y H:i', (int) $stats['since'] ) )
	);
	echo '</p><p>Últimas direcciones pedidas:</p><ul>';
	foreach ( (array) $stats['last'] as $address ) {
		echo '<li><code>' . esc_html( (string) $address ) . '</code></li>';
	}
	echo '</ul></div>';
}
add_action( 'admin_notices', 'ayudawp_fd_notice' );

// Al desactivar el plugin se borran los datos del contador.
register_deactivation_hook(
	__FILE__,
	static function () {
		delete_transient( 'ayudawp_fd_stats' );
	}
);

Este pequeño plugin cuenta las peticiones de la parte pública de la web que llevan parámetros filter_ y, cuando entras a «Escritorio > Inicio» como administrador, te muestra el total, desde cuándo está contando y las últimas direcciones pedidas. Mientras no haya contado ninguna, el aviso te dice que está activo y que todavía no ha visto nada.

Para comprobar que funciona, añade ?filter_prueba=1 al final de la dirección de tu tienda desde una ventana de incógnito y vuelve a «Escritorio > Inicio» y el contador debería marcar 1. Si no sube, algo atiende esa petición antes de que llegue a PHP, como una caché o una regla de bloqueo.

El código no guarda direcciones IP ni identificadores de navegador. Las cifras son aproximadas, porque si dos peticiones coinciden en el mismo instante una puede pisar a la otra, y los datos caducan solos tras siete días sin peticiones con filtro.

También ten en cuenta que solo ve las peticiones que llegan hasta PHP, y las que sirve una caché o corta Cloudflare, el .htaccess o el plugin de bloqueo (si ya lo tienes activo) no pasan por aquí, de modo que la cifra real será igual o mayor.

Úsalo unas horas y quítalo. Cada petición que cuenta hace unas cinco consultas a la base de datos (en una instalación sin caché de objetos persistente son tres lecturas y dos escrituras), y si tu servidor ya va justo se notan. Cuando tengas la cifra, desactívalo y bórralo desde Plugins.

Cómo parar una trampa de rastreo en 3 capas

Mi criterio es cortar lo más lejos posible de WordPress, porque cuanto antes pares una petición, menos trabajo le llega a tu servidor. Las capas van en este orden y puedes montar una, dos o las tres.

Las tres capas bloquean por el nombre del parámetro y no distinguen quién lo envía. Si usas otro plugin que ponga parámetros que empiecen por filter_ en la parte pública de tu web, comprueba que sigue funcionando después.

Lo mismo vale para los bloques de filtro de producto que trae el propio WooCommerce, que usan esos mismos parámetros y también se ven afectados por el bloqueo total.

Cloudflare y el .htaccess buscan el texto filter_ tal como llega en la dirección, mientras que la tercera capa lee los parámetros que PHP entrega a WooCommerce. Para los robots que siguen los enlaces del filtro da igual, porque piden justo las direcciones que el filtro genera.

Pero no para quien escriba a mano una variante como filter.color=azul (PHP convierte el punto en un guion bajo y WooCommerce la entiende igual), pues se salta las dos primeras capas, y solo el plugin la para.

Además, las reglas solo cubren los parámetros filter_: el widget clásico de filtrar por valoración usa enlaces con rating_filter, que también se pueden rastrear y que estas reglas no tocan.

Primera capa: Cloudflare, antes de que llegue a tu hosting

Cloudflare con su plan gratuito permite hasta 5 reglas personalizadas, con la acción de bloquear incluida. Con una sola puedes parar estas peticiones sin que tu servidor se entere. Para crearla:

1. En el panel de Cloudflare entra en la página «Security rules» (si tienes el panel en español, puede aparecer traducida) y pulsa «Create rule» y después «Custom rules».
2. Ponle un nombre que te acuerdes de qué hace, por ejemplo «Bloquear filtros de WooCommerce».
3. Pulsa el enlace «Edit expression», junto a la vista previa de la expresión, para editarla a mano, y pega esto:

   (starts_with(http.request.uri.query, "filter_") or http.request.uri.query contains "&filter_") and not starts_with(http.request.uri.path, "/wp-admin/")

4. En la acción elige «Block» y pulsa «Deploy».

La primera parte busca parámetros que empiecen por filter_, ya sea al principio de la dirección o detrás de un &, y la segunda deja fuera el escritorio de WordPress, porque el botón «Filtrar» de las listas de entradas, páginas y productos envía un parámetro llamado filter_action y sin esa excepción te quedarías sin él.

• Tu web tiene que estar detrás de Cloudflare con el proxy activado (la nube naranja de «Proxied»): Con la nube gris, Cloudflare solo hace de DNS y no aplica ninguna regla.
• Pruébala: añade ?filter_color=azul al final de la dirección de tu tienda y, si funciona, verás una página de bloqueo en lugar de tu tienda. Para ver cuántas peticiones ha parado, mira en Analytics la pestaña Events, donde en el plan gratuito sale una muestra de los eventos y no todos, y se guardan hasta 31 días.
• Mientras la regla esté activa, el filtro deja de funcionar para tus clientes: El resto de la tienda va con normalidad, que es mejor que una web caída. Si de verdad lo usan, la tercera capa te deja un punto medio.
• El límite de velocidad del plan gratuito se queda corto para esto: solo admite una regla, con ventanas de 10 segundos y por IP, y un límite por IP sirve de poco contra robots que llegan desde muchas direcciones distintas.

Si todavía no tienes tu web en Cloudflare, ponerla lleva su proceso (lo habitual es cambiar los servidores de nombres de tu dominio, o sea, los DNS) y no es lo que quieres hacer con la tienda caída. Pasa a la capa siguiente y deja Cloudflare para cuando respires.

Segunda capa: el servidor, con una regla en el .htaccess

Si no usas Cloudflare, o quieres una segunda barrera por si alguien llega a tu servidor sin pasar por él, la regla va en el .htaccess. Haz antes una copia del archivo y pega esto al principio, antes de la línea # BEGIN WordPress, para que WordPress no la toque.

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/wp-admin/ [NC]
RewriteCond %{QUERY_STRING} (^|&)filter_ [NC]
RewriteRule .* - [F,L]
</IfModule>

La regla devuelve un 403 a cualquier petición con un parámetro que empiece por filter_, y deja fuera /wp-admin/ por el mismo motivo que en Cloudflare. Si en tu filtro solo usas un atributo puedes afinar más y poner su nombre, por ejemplo (^|&)filter_talla=.

Vale para Apache y LiteSpeed, que leen el .htaccess, pero no para nginx. Y como en la capa anterior, mientras esté activa, el filtro deja de funcionar para tus clientes.

Tercera capa: un plugin que cierra la puerta desde WordPress

Si no puedes tocar ni Cloudflare ni el .htaccess, o quieres que tus clientes puedan seguir filtrando con un límite razonable, esta es tu capa.

Se ejecuta dentro de WordPress, así que el servidor ya ha hecho parte del trabajo, pero corta la petición antes de que cargue WooCommerce y el tema, y por tanto antes de que hagan sus consultas.

Se instala igual que el contador que hemos visto antes, en este caso el nombre del archivo recomendado sería ayudawp-filter-trap-guard.php:

<?php
/**
 * Plugin Name: AyudaWP Bloqueo de filtros
 * Plugin URI:  https://plugins.ayudawp.com
 * Description: Rechaza las direcciones con filtros de WooCommerce (filter_*) antes de que carguen WooCommerce y el tema.
 * Version:     1.0.0
 * Author:      Fernando Tellado
 * Author URI:  https://ayudawp.com
 * License:     GPL-2.0-or-later
 */

if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

// Opciones de filtro que se permiten en una petición. Con 0 se bloquea cualquier filtro,
// y con 2 tus clientes pueden combinar hasta dos opciones y se rechaza lo que pase de ahí.
if ( ! defined( 'AYUDAWP_FTG_MAX_OPTIONS' ) ) {
	define( 'AYUDAWP_FTG_MAX_OPTIONS', 0 );
}

/**
 * Indica si los parámetros traen más opciones de filtro de las permitidas.
 *
 * Lee los parámetros ya interpretados por PHP, igual que WooCommerce, así que también
 * pilla nombres escritos de forma rara. Cada valor de cada filter_* cuenta como una opción.
 *
 * @param array $params Parámetros de la petición ($_GET).
 * @param int   $max    Opciones permitidas. Con 0 se rechaza cualquier filtro.
 * @return bool
 */
function ayudawp_ftg_should_block( array $params, int $max ): bool {
	$found   = false;
	$options = 0;

	foreach ( $params as $name => $value ) {
		if ( 0 !== strpos( (string) $name, 'filter_' ) ) {
			continue;
		}

		// WooCommerce espera un texto separado por comas, nunca una lista.
		if ( is_array( $value ) ) {
			return true;
		}

		$found    = true;
		$options += max( 1, count( array_filter( explode( ',', (string) $value ), 'strlen' ) ) );
	}

	return $found && ( 0 === $max || $options > $max );
}

/**
 * Responde 403 y corta si la petición es un filtro rechazado.
 */
function ayudawp_ftg_maybe_block(): void {
	// El escritorio, AJAX y cron usan nombres filter_* para sus cosas.
	if ( is_admin() || wp_doing_ajax() || wp_doing_cron() ) {
		return;
	}

	// phpcs:ignore WordPress.Security.NonceVerification.Recommended -- Solo se leen nombres y recuentos de parámetros, no se guarda ni se muestra nada.
	if ( ! ayudawp_ftg_should_block( $_GET, (int) AYUDAWP_FTG_MAX_OPTIONS ) ) {
		return;
	}

	status_header( 403 );
	header( 'Cache-Control: no-store, max-age=0' );
	header( 'Content-Type: text/plain; charset=utf-8' );
	exit( 'Forbidden' );
}

ayudawp_ftg_maybe_block();

El número que manda está al principio, en AYUDAWP_FTG_MAX_OPTIONS, y lo cambias editándolo en el propio archivo (o definiéndolo en el wp-config.php, si prefieres no tocar el plugin).

• Con 0, cualquier dirección con filter_ recibe un 403, igual que en las capas anteriores.
• Con 2, tus clientes pueden combinar hasta dos opciones (un color y una talla, por ejemplo) y todo lo que pase de ahí se rechaza. En el ejemplo de las 10 tallas, pasas de 1.023 combinaciones posibles a 55.

Los robots seguirán pidiendo las combinaciones que sí se permiten, y el widget seguirá ofreciendo la tercera opción a tus clientes: quien la marque verá un Forbidden en texto plano en lugar de su tienda.

Es un parche poco elegante, pero muuucho mejor que una tienda caída. Si tu hosting está en las últimas empieza con 0 y sube el número cuando pase el apretón.

Para probarlo, con el valor 0, abre tu tienda con ?filter_color=azul al final. Si ves un texto que dice Forbidden, funciona.

WordPress carga los plugins activos por orden alfabético y este empieza por «ayudawp», así que corta antes de que cargue WooCommerce. Solo se te adelantaría uno cuyo nombre empiece antes, como Akismet.

Si prefieres que el plugin se cargue siempre el primero, el mismo archivo funciona sin cambios en wp-content/mu-plugins/, donde WordPress carga los mu-plugins antes que cualquier plugin normal y sin activarlos.

¿Sirven de algo el robots.txt, el canonical y los errores 4xx?

Sobre esto circula mucho consejo por ahí, y prefiero quedarme con lo que dice la documentación de Google ¿y tú?:

• robots.txt: una regla como Disallow: /*?*filter_ hace que Googlebot deje de pedir esas direcciones, y Google la recomienda en primer lugar para la navegación facetada. Tiene dos límites, uno es que según su documentación sobre robots.txt una página bloqueada puede indexarse igualmente si otros sitios enlazan a ella, y el otro que solo lo cumplen los robots que quieren cumplirlo, es declarativo, como todo en el fichero robots.txt, no obligatorio.
• Canonical: apuntar las páginas filtradas a la categoría sin filtrar le dice a Google cuál es la versión buena, pero según esa misma documentación sobre navegación por facetas solo puede reducir el volumen de rastreo con el tiempo y a largo plazo es menos eficaz que el robots.txt.
• Errores 4xx: según la documentación de Google sobre códigos de estado, todos los 4xx se tratan igual salvo el 429, y no distingue entre un 404 y un 410. Devolver un 403 o un 410 da lo mismo, y las direcciones que ya estuvieran indexadas y pasen a devolver cualquiera de ellos acaban saliendo del índice. Eso sí, esa misma página desaconseja usar el 401 y el 403 para limitar el ritmo de rastreo, y los que hacen que Googlebot afloje son los errores 5xx y el 429. El 403 de tus capas no sirve para que venga menos, y lo que consigues es que cada visita cueste muy poco.

Si bloqueas las direcciones en el robots.txt, Googlebot no las pide y por tanto nunca ve ese 403. Si en Search Console ves direcciones con filtro indexadas y quieres que desaparezcan quita el Disallow una temporada (tus reglas las responden sin esfuerzo) y deja que Google compruebe que ya no existen. Si no hay ninguna indexada déjalo como está.

Quitar la causa y no solo tapar el agujero

Las capas frenan el golpe pero el filtro sigue roto para tus clientes, salvo que hayas puesto un límite en la tercera. Hay dos salidas habituales, con lo que te llevas y lo que te cuesta cada una.

Lo bueno y lo malo de quitar los filtros con muchos valores

A favor

• Cuesta cero y no hay nada que mantener.
• Desaparecen los enlaces del laberinto en su origen. Como las combinaciones crecen de forma exponencial, quitar el atributo con 30 valores elimina de golpe los más de mil millones de direcciones que generaba.
• Un filtro menos que probar cada vez que actualizas WooCommerce o el tema.

En contra

• Pierdes una función que quizá usan tus clientes. Mira tu analítica antes de quitar nada.
• Reduce el problema, pero no lo cierra. Tres atributos de cuatro valores cada uno ya dan 4.095 direcciones, más que de sobra para un robot que no se cansa, así que las capas se quedan igual.
• Si en tu sector el filtro es parte de cómo se compra, quitarlo puede costar ventas, y solo lo sabrás midiendo.

Lo bueno y lo malo del filtro AJAX

Un filtro AJAX actualiza los productos sin recargar la página y puede funcionar sin enlaces con parámetros que los robots sigan, aunque eso depende de cómo esté hecho cada plugin.

Entre los plugins de este tipo están FacetWP, de pago, y annasta Filters for WooCommerce, disponible en el directorio de WordPress.org, en parte gratis y en parte de pago.

A favor

• Mantienes el filtro para la gente que sí lo usa.
• Si las opciones no son enlaces, los robots se quedan sin laberinto. FacetWP dice en su documentación que las facetas son invisibles para los buscadores, y los bloques de filtro de WooCommerce pintan las opciones con JavaScript.
• Algunos plugins traen controles de SEO. La ficha de annasta anuncia canonical automático en las páginas filtradas y opciones de noindex y nofollow.

En contra

• Cuesta dinero o tiempo: FacetWP Basic son 99 dólares al año para entre 1 y 3 sitios, annasta es gratuito pero con funciones de pago, y en los dos casos hay que configurarlo y probarlo con tu tema y tu maquetador.
• Es JavaScript y una dependencia más que mantener y actualizar.
• Las direcciones filtradas siguen existiendo: FacetWP escribe la selección en la dirección (con parámetros que empiezan por _), esa dirección se puede abrir directamente y, según su propia documentación, si alguien la enlaza puede acabar indexada. Si no quieres eso, hay que añadir noindex. Y la descripción de annasta anuncia que puede actualizar la URL del navegador y convertir los parámetros en enlaces permanentes, así que esas opciones conviene mirarlas con la prueba en la mano.
• El trabajo pasa de los robots a las personas: cada cambio en el filtro es una petición al servidor. Con mucho tráfico, conviene medirlo.

Sea cual sea el plugin que elijas repite la prueba de la barra de direcciones y del código fuente. Lo que abre la trampa son los enlaces con parámetros que un robot puede seguir, y si el filtro nuevo los deja en el código volverías a tener el problema, aunque los parámetros se llamen de otra forma y tus reglas, que buscan filter_, no los pararían.

Si el plugin nuevo trabaja con los mismos parámetros filter_, tus propias reglas bloquearán a tus clientes, y conviene probarlo con ellas activas antes de dar el trabajo por terminado.

Cuando lo tengas funcionando retira el filtro nativo (el widget o el bloque) para que desaparezcan los enlaces. Las reglas se quedan, porque los robots ya conocen esas direcciones y es probable que sigan pidiéndolas durante un tiempo.

Cómo decidir entre una salida y otra

Para decidir te traslado tres preguntas.

1. ¿Alguien usa el filtro?: si casi nadie lo toca quítalo del todo y te ahorras todo el problema.
2. ¿Cuántos valores tienen tus atributos?: con decenas el problema se dispara, y con tres o cuatro es manejable.
3. ¿Quién va a cuidar el plugin?: un filtro de pago pide actualizaciones y pruebas, y si no tienes quien las haga, quitar es más sensato que instalar.

Cuando me he encontrado esto en un cliente, lo primero que hago es analizar el tráfico y los registros, y con esos datos diagnostico el problema con la ayuda de mi equipo y el refuerzo de la IA, en mi caso con Claude Code, y siempre doy con una solución, pero cambia según el sitio.

La decisión depende de lo que digan los datos y el resultado del análisis del problema, pues cada tienda es un mundo.

¿Por dónde empezar?

1. Marca una opción de tu filtro, mira la barra de direcciones y el código fuente de la página. Si ves enlaces con filter_, esto va contigo.
2. Si no tienes claro cuánto te está pasando, deja el contador unas horas y apunta la cifra.
3. Si tu web está en Cloudflare, crea la regla de bloqueo. Es una regla corta y tu hosting ni se entera.
4. Añade la regla del .htaccess (con copia previa) o, si no puedes tocar ese archivo, instala el plugin de bloqueo, que además para las variantes retorcidas.
5. Mira en Google Search Console si hay direcciones con filtro indexadas y decide qué haces con el Disallow del robots.txt.
6. Con los datos delante, decide qué haces con el filtro: quitarlo, pasar a uno AJAX o dejarlo con el límite de la tercera capa. Si cambias, repite con el nuevo la prueba del código fuente y comprueba que no choca con tus reglas.

Para seguir con la defensa de tu web, tienes mi guía sobre ataques DDoS en WordPress y, si te interesa un problema parecido, el artículo sobre evitar el rastreo de «Añadir al carrito», en cierto modo relacionado.

Si tienes dudas con alguna de las capas, o quieres contarme qué ves tú en tu tienda, me tienes ahí abajo, en la sección de comentarios.

He convertido en skills públicas el procedimiento que surgió de ahí, y antes de enseñártelas quiero contarte de dónde vienen.

Porque una skill no enseña nada por sí sola, eso para empezar,  es simplemente el formato que he elegido para pasarte lo que aprendí a las malas, de manera que puedas aprovecharlo, incluso aunque no sepas demasiado de seguridad, con una IA que te haga de ayudante.

Lo que vale es lo aprendido, creo, y de eso va este artículo.

Qué pasó con el plugin … de seguridad

El 11 de septiembre de 2026 se publicó el CVE-2026-81754, una vulnerabilidad de tipo XSS almacenado (un código sospechoso que podía quedarse guardado en tu web y ejecutarse cuando alguien abre la página donde se muestra) que afectaba a Vigilante hasta la versión 2.10.2, y qué corregí en la 2.10.3 (en menos de una hora, eso sí).

Te cuento qué pasaba procurando usar los mínimos tecnicismos posibles…

El registro de actividad de Vigilante guarda el User-Agent de cada visita, que es el texto con el que un navegador o un robot se presenta al entrar en tu web. Lo escribe quien visita, así que puede poner lo que quiera, y cuando el administrador abría el registro, una función de JavaScript preparaba ese texto para mostrarlo y lo hacía a medias, porque codificaba los símbolos < y > pero dejaba pasar las comillas.

Con un User-Agent bien elegido cualquiera sin cuenta en la web podía salirse del atributo HTML donde se pintaba el texto y ejecutar código en el navegador del administrador.

Hay matices, y conviene decirlos, porque la puntuación CVSS es de 7.2, hace falta que un administrador abra el registro para que ocurra algo, y cuando se publicó la ficha la valoración de CISA indicaba que no se conocía ninguna explotación. Nada de eso le quita importancia, pero contarlo sin esos datos sería contarlo mal, e incluso injusto.

Lo encontró y me lo comunicó Sebastian Albrecht, y se lo agradezco. Que le pase esto a un plugin de seguridad escuece el doble, pero prefiero contarlo yo con todos los datos antes de que lo cuente otro con la mitad.

Lo que de verdad me dio que pensar

Lo que más me inquietó no fue el fallo en sí. La función que escapaba mal venía de las primeras versiones del plugin, de esas que nadie toca porque funcionan, y todas las versiones posteriores habían pasado por mi revisión.

Mi revisión de entonces se fijaba sobre todo en lo que cambiaba de una versión a otra. Si tocaba algo, lo repasaba, y lo que quedaba sin tocar lo daba por bueno, y además, el fallo era en el JavaScript, donde mis comprobaciones miraban poco, y mal, porque una revisión que solo mira lo que cambia no ve lo que ya estaba mal, y este fue mi mayor aprendizaje.

Revisarlo todo y cerrar cada puerta

Con la versión 2.10.3 quedó cerrado el CVE, como te he comentado, pero me quedé con una idea ahí clavada a fuego, y es que si había una puerta abierta que nadie había mirado, podía haber más.

Así que me puse a revisar el plugin entero, sin fijarme en qué había cambiado, y a cerrar cada posible puerta que encontraba, hasta la última versión antes de la 3.0.0. Fueron muchas versiones y no te las voy a contar una a una, pero algunos hallazgos te enseñan lo que pasa cuando por fin miras todo:

• La identificación en dos pasos, el 2FA, tenía un camino para saltárselo, que cerré en la 2.10.3 junto al CVE. Más tarde, una revisión cruzada encontró otro, porque el código se pedía en el formulario de acceso de WordPress pero no en otros formularios de inicio de sesión, como los de WooCommerce, y lo cerré en la 2.11.0. En ambos casos hacía falta conocer la contraseña de la cuenta, pero una doble verificación que se puede esquivar, por raro que sea el caso, no cumple su función, no al menos en mis estándares.
• El bloqueo de intentos de accesos falló en sitios que no usaban la hora UTC durante 73 versiones, de la 1.0.0 a la 2.10.5, porque la tabla de intentos mezclaba la hora del sitio con la UTC. Se corrigió en la 2.11.0.
• Al guardar copias de wp-config.php y .htaccess en la base de datos para comparar cambios, acababa ahí información sensible como la contraseña de la base de datos y las claves de seguridad (desde la 2.7.0). Lo fui limpiando entre la 2.11.2 y la 2.11.9, y en las preguntas frecuentes del plugin explico que, si alguien pudo leer tu base de datos o sus copias, conviene regenerar esas claves y cambiar la contraseña.
• La IP del visitante se leía de la cabecera X-Forwarded-For por el lado equivocado, también desde la 2.7.0. Cada proxy va añadiendo su dato a esa cabecera, pero el visitante puede escribir la suya al principio de la lista, de modo que leerla por ese extremo es creerse lo que diga el visitante. Solo afectaba a sitios con esa opción activada y quedó corregido en la 2.11.8.

Todo consta con su versión en el registro de cambios público del plugin, que es lo que más me importa, porque sin ese rastro lo que cuento sería solo mi palabra, y la transparencia es vital. Si tienes un problema y lo solucionas demuestras responsabilidad, si lo ocultas no esperes que nadie se fíe de ti y tus productos.

No todo lo encontré yo. Albert Calzada, un usuario muy activo del plugin, se dedicó a revisar las diferencias entre versiones, artprojectgroup leyó el código de la 2.11.11 y dio con problemas en el 2FA que corregí en la 2.11.12, y Antonio Cambronero, freelancesgroup y pepelopex me avisaron de fallos de funcionamiento por el camino. Todos lo hicieron como se debe hacer, directamente y con educación, sin montar un escándalo y dándome tiempo para arreglarlo. Gracias a todos, de verdad, sois parte de la grandeza del código abierto.

Lo que aprendí por el camino

De esa revisión salió un procedimiento que ahora aplico antes de publicar cualquier versión. Los pasos concretos están en la skill, aquí te cuento los aprendizajes o ideas sobre los que está basada:

• Se revisa todo lo que el plugin expone, haya cambiado o no: Cada punto por donde entran datos de fuera (formularios, cabeceras, campos que viajan por la API REST) se mira en cada versión, aunque nadie haya tocado ese código en años.
• No todas las versiones merecen el mismo esfuerzo: El proceso completo me llevó unas diez horas en una versión corriente, y lo que no se aguanta acaba saltándose. Por eso hay tres niveles de profundidad, según sea un cambio ordinario, uno sensible o un plugin de seguridad con una vulnerabilidad publicada.
• Quien revisa no puede ser quien escribió el cambio: Una revisión cruzada y a ciegas, hecha por otra persona o por otra IA que no haya visto cómo se hizo, encuentra lo que el autor ya no ve. Para la 3.0.0 hice diez rondas solo sobre la autoprotección del plugin, y dos más sobre la parte visible, que conté en el artículo sobre Vigilante 3.
• Una comprobación nunca debe decir «no hay nada» cuando la verdad es «no he podido mirar»: Por eso cada herramienta y cada nota de versión lleva escrito, además de lo que encontró, lo que no ha visto, y la nota incluye cifras de cuántas comprobaciones se hicieron. En mi opinión es la regla más valiosa de todas.
• Se mide el efecto, no que el código esté escrito: Haber añadido una corrección no prueba nada. Hay que reproducir el fallo contra la versión anterior y comprobar que con la nueva ya no ocurre, y así reproduje el segundo atajo del 2FA contra la 2.10.5 antes de darlo por cerrado.

La parte mecánica de las comprobaciones la he dejado en tres scripts. Uno busca funciones de JavaScript que escapan texto sin codificar las comillas, o sea, justo el fallo del CVE. Otro lista los avisos de seguridad del analizador de código que alguien ha silenciado sin explicar por qué, y el tercero detecta llamadas a métodos que no existen cuando copias código de un plugin a otro. Llevan un autotest de siete casos y cada uno tiene escrita la lista de lo que no ve.

Todo esto cobra más sentido con la revisión automática de seguridad que WordPress.org aplica desde junio de 2026, donde cada versión pasa por un periodo de espera mientras la analizan varios modelos de IA junto con Jetpack Scan, y si la puntuación de riesgo sale alta, la versión se bloquea y los sitios siguen recibiendo la anterior.

Que una revisión con Plugin Check te salga sin errores ni avisos tristemente actualmente sirve de bien poco, te cuenta cosas, te informa de límites de procedimiento y cosa básicas de seguridad, pero no es un pentest ni de lejos.

El proceso completo, de un vistazo

Todo lo anterior cabe en un mapa. Es el recorrido de una versión de mi plugin, desde que decido cuánta revisión le toca hasta que llega a los sitios, con las tres puertas que pueden pararla por el camino.

En el mapa salen unas palabras que no he usado hasta ahora y que resumen bien cómo pienso la revisión:

• Puerta: Es un punto del recorrido donde, si algo falla, la versión no sigue, y hay tres:
  1. Una comprobación mecánica que da error o una cifra que no cuadra.
  2. Un hallazgo de gravedad media o superior en el análisis o en la revisión cruzada.
  3. Un riesgo alto en la revisión automática de WordPress.org. No hay posibilidad de «ya lo arreglo luego».
• Canario: Es un caso de prueba cuyo resultado conoces de antemano. Cuando un comando que busca algo en el código te dice «cero coincidencias», no sabes si no hay nada o si el comando no ve nada. Por eso lo ejecuto antes sobre un archivo hecho a propósito, con líneas que sí deben saltar, y solo me fío del cero si ahí encuentra lo que debe. Lo llamo canario porque es lo primero que avisa de que algo va mal, por lo de los pajaritos que se llevaban a la mina, por si no conocías la referencia.

También te cuento acerca de otra terminología que uso para el procedimiento, para que comprendas mejor como funciona mi cabeza (spoiler: raro):

• Arnés: Es el conjunto de pruebas permanentes del plugin, y a cada prueba suelta la llamo celda. Crece con cada hallazgo, se ejecuta entero en cada versión y no lleva número de versión, porque no es de ninguna en concreto. Cuando se publica una vulnerabilidad, su prueba de concepto, que es el código que reproduce el fallo, entra en el arnés ese mismo día: falla contra la versión vulnerable y pasa contra la actual. No va dentro del zip del plugin, es mi herramienta de trabajo y no algo que instales en tu web.
• Mutante: Cada vez que arreglo un hallazgo grave añado una celda para que no vuelva. Y para saber si esa celda sirve de algo vuelvo a meter el fallo a propósito, eso es el mutante, y compruebo que la celda falla. Si con el fallo puesto sigue pasando, no protege nada. Para la 3.0.0 de Vigilante inyecté 71 mutantes y las pruebas cazaron todos menos uno, que no cambiaba el comportamiento del plugin y dejé anotado como tal.

Lo que ves en el mapa es el procedimiento que viene en la skill de seguridad. No hace falta pasar por todo en cada versión, para eso están los tres niveles, pero así sabes qué hay detrás de cada paso cuando se lo pidas a tu asistente.

Qué es una skill y por qué las comparto

Si no te suena el término, una skill es una carpeta con instrucciones, y a veces con documentos de referencia y scripts, que le das a tu asistente de IA para que trabaje con un método concreto en lugar de tirar solo de lo que recuerda. Piensa en la nota que dejas en la nevera para quien se queda en tu casa, no le enseña a sobrevivir, solo le dice cómo haces tú las cosas.

Todo este tipo de procesos los expliqué con más calma, y cómo cargarlas en cada IA, en el artículo sobre vibe coding de plugins para WordPress.

Esto eran procedimientos internos, notas mías para no volver a chocar con la misma piedra, y lo normal habría sido quedármelos para mis plugins, pero llevo más de veinte años haciendo webs, buena parte de lo que sé lo aprendí de gente que compartió lo suyo, y la filosofía Open Source va de eso, así que he empaquetado mi procedimiento actual como skills para que lo aproveche quien quiera.

Dónde están las skills, qué incluyen y qué no

Las dos que salen de esta historia las tienes disponibles en el repositorio de skills para IA que tengo en GitHub, junto a otras que ya tenía, como la de rendimiento o las de humanizar textos.

• wp-plugin-security, en su versión 1.3, trae la skill principal, cuatro documentos de referencia, los tres scripts y la puerta de seguridad previa a cada versión, con sus tres niveles, los comandos que hay que ejecutar y la plantilla de la nota de versión. Recoge también cosas como usar los datos que elige quien hace la petición (el User-Agent, las cabeceras de proxy, la IP) solo para registrar y nunca para decidir, o lo que borra en silencio sanitize_text_field() de una URL con caracteres codificados, algo que dejó al cortafuegos de Vigilante analizando una copia distinta de la petición hasta la 2.9.9.
• wp-plugin-development unifica lo que la documentación no cuenta sobre desarrollar y publicar plugins, como la receta para que los textos por defecto traducibles no se guarden en la base de datos y se queden congelados en un idioma.

De todos modos, a riesgo de ser pesado, insisto en que una skill no garantiza un plugin seguro ni sustituye a una auditoría. Las puertas de revisión cazan regresiones, es decir, que rompas lo que ya funcionaba, pero no te dicen si el diseño original era bueno. Los scripts no lo detectan todo, y el ejemplo de la doble verificación de la skill de seguridad es un boceto con la lista de lo que le falta, no una implementación completa.

Si descargaste la skill de seguridad antes de esta actualización bájala de nuevo, pues corregí en esta versión (1.3) un ejemplo con lo del 2FA que daba por bueno un atajo que se saltaba el código en los formularios de acceso distintos de wp-login.php.

Cómo obtener las skills y usarlas

El README del repositorio está en inglés, así que te resumo lo que necesitas.

1. Entra en el repositorio, pulsa el botón «Code», elige «Download ZIP» y descomprímelo. Cada skill es una carpeta (wp-plugin-security, wp-plugin-development y así), y te quedas con las que quieras.
2. Carga la skill en tu asistente de IA: En Claude con proyectos, añade los archivos de la skill al conocimiento del proyecto. En Claude Code copia la carpeta entera a ~/.claude/skills/. En ChatGPT, crea un GPT personalizado y sube los archivos a su base de conocimiento. En cualquier otro asistente, usa su apartado de archivos o conocimiento, o las instrucciones personalizadas.
3. Sube siempre la carpeta completa, no solo SKILL.md, porque ese archivo remite a los de references y scripts, y sin ellos la skill queda coja.
4. Los scripts necesitan Node.js, PHP en línea de comandos con la extensión mbstring y Python 3. Los ejecutas tú, o tu asistente si trabaja con acceso a una terminal.
5. Para actualizarlas, dale al icono del ojo (watch) para que te avise cuando suba cambios, vuelve a descargar el repositorio y sustituye los archivos.

Con la skill ya cargada, pídele a tu asistente de IA que aplique la puerta de seguridad antes de publicar una versión, dile qué nivel crees que toca y que te entregue la nota de versión con lo que ha comprobado y lo que no ha podido mirar. Si es la primera vez que lo haces empieza por el nivel más bajo en tu próxima versión y sube solo si el cambio lo pide. Y lee esa nota con ojo crítico, porque la IA también se equivoca y ninguna skill cambia eso.

Para terminar

Si tienes Vigilante instalado, comprueba que estás en una versión actual, sino valiente apaño he hecho ¿no?

Y luego, bueno, si quieres me cuentas en los comentarios si has vivido algo parecido con tus propios plugins o temas, o si ves algún hueco en este procedimiento. Estaré encantado de comentarlo contigo, que de eso también se aprende.

A mí me tocó aprenderlo a las malas, y lo mínimo es que a ti te salga más barato, y para ello espero que las skills te ayuden.

Así que el resumen de hoy es todo del #DoctorWordPress del miércoles, donde me puse a contar algo que me tenía un poco mosqueado desde hace tiempo: las estadísticas de los plugins en WordPress.org.

Te cuento lo que vimos y, al final, tienes el vídeo completo.

Doctor WordPress: estadísticas de plugins que sí te dicen algo

Antes de nada, semana gallega

Arranqué el directo con la agenda, porque esta semana me tocaba Galicia. El jueves 15 di una charla sobre seguridad en WordPress en la meetup de WordPress Coruña, en Sngular, y entre el 16 y el 18 de octubre se celebra WordCamp Galicia 2026 en Coruña, la que muchos llamamos «PulpoCamp» por razones obvias.

Además, el viernes por la mañana he imparatido allí un taller de iniciación a WordPress de dos horas y media (dos de taller y media de preguntas), con entrada gratuita y plazas limitadas por espacio. Hubo más de 80 alumnos, sala llena, y hasta lo pasamos bien.

Contributor Résumé, o cómo presumir de tus contribuciones

Lo primero que enseñé fue mi perfil en WordPress.org, ese que se genera solo en cuanto participas en algo: soporte en los foros, traducciones en Polyglots, plugins, contribuciones al core, eventos… En mi caso salen, por ejemplo, más de 4.000 cadenas revisadas en traducciones y 23 plugins publicados.

Para mostrar todo eso en tu web hice hace tiempo Contributor Résumé, un plugin que, ya te lo digo, no va a ser un superventas, es más bien una cosa para amiguetes. Lo que hace es coger ese perfil de WordPress.org y pintarlo en una página de tu web, con bloque o shortcode, y lo puedes personalizar a tu gusto:

• Varios estilos: clásico, moderno y uno monoespaciado con colorines para los más programadores.
• Eliges qué secciones se muestran y en qué orden.
• Puedes añadir los eventos en los que participas, la actividad reciente y hasta tu perfil de GitHub.
• Vista previa antes de crear la página.

¿Por qué molestarse? Pues porque, en mi opinión, el mejor currículum que puedes tener en WordPress son tus contribuciones a WordPress, y tenerlo a la vista en tu web personal tiene su miga.

El problema: «más de 10 instalaciones» no significa nada

Ahora bien, lo interesante del directo vino después. Si alguna vez has publicado un plugin en WordPress.org te habrás quedado mirando las estadísticas como un bobo, porque lo que te da el directorio es una cifra de instalaciones activas de hoy y redondeada a la baja. ¿Qué quiere decir «más de 10»? ¿11? ¿87? Pues no se sabe.

La vista avanzada de cualquier plugin (la puede ver cualquiera, no solo el autor) te enseña las instalaciones por versión y la evolución de descargas, y poco más. No sabes si tus instalaciones suben o bajan ni desde cuándo, ni en qué posición sales cuando alguien busca «formulario de contacto», ni cuánta gente desinstala tu plugin. Antes había bastante más información, pero se quitó, y aunque se ha pedido varias veces que vuelva, ahí sigue.

Consecuencia: han salido un montón de servicios que cogen los datos de la API pública, que es gratis, y te los cobran por suscripción. Lo conté con detalle, con todos los precios, en el artículo sobre estadísticas de plugins y temas de WordPress.org.

Mi solución: lo mismo, pero gratis

Y como tengo esa manía, pensé: ¿para qué va a pagar la gente por algo que se está dando gratis? En vez de crear otro plugin, aproveché Contributor Résumé, que lo van a instalar sobre todo desarrolladores que contribuyen, y le añadí una pestaña de estadísticas de tus plugins y temas. Esto es lo que enseñé:

• Descargas por día de los últimos 7, 30 y 90 días, 12 meses y hasta 2 años.
• Histórico de instalaciones activas, con una única limitación: empieza a contar desde el día en que activas el plugin, así que cuanto antes, mejor.
• Avisos de nueva versión publicada, valoraciones nuevas y hilos de soporte sin contestar.
• Tendencias ordenables, para ver qué plugins han subido o bajado más en el periodo que elijas.
• Ficha detallada de cada plugin, con adopción por versiones, valoraciones, traducciones y exportación a CSV.
• Posiciones en las búsquedas del directorio, tanto para tus etiquetas como para las palabras clave que tú configures.
• Correos con resúmenes diarios, semanales o mensuales, y un widget en el escritorio con los que más suben y los que más bajan.

Lo de las búsquedas es, para mí, lo más jugoso. Las etiquetas (máximo cinco por plugin) tienen su URL en WordPress.org, pero nadie las usa, la gente escribe en el buscador, y ahí es donde te tienes que medir. En el directo vimos, por ejemplo, uno de mis plugins, Visibility, en la posición 61 para «SEO» entre casi 9.000 resultados, después de subir 10 puestos en 90 días, que para un plugin nuevo de SEO no está nada mal.

Y una cosa más: puedes cambiar el usuario y curiosear las estadísticas de cualquier otro autor, porque son datos públicos. Como nadie se animó a darme su slug (cobardes), le tocó a Nilo Vélez, que tiene, entre otras cosas, un tema con más de 10.000 instalaciones activas.

Lo que vendrá…

Tengo previsto añadir comparativas con plugins competidores, avisos cuando alguien te adelanta en una búsqueda, una estimación más fina dentro de cada tramo de instalaciones, y bloques y shortcodes para mostrar las estadísticas públicamente. Si veo que se instala, lo iré metiendo poco a poco, y si no, lo meteré para mí, porque yo los plugins los hago primero para mí y luego para todos. Así de egoísta soy, y precisamente por eso los mantengo actualizados.

Si tienes plugins o temas en WordPress.org, pruébalo y me cuentas qué echas en falta, que en el foro de soporte del plugin o ahí abajo, en los comentarios, me tienes.

Vídeo completo del #DoctorWordPress del 14 de octubre

Aquí tienes el directo entero, con la demo del plugin paso a paso:

Ver el #DoctorWordPress del 14 de octubre de 2026 en YouTube

El lunes volvemos con las Crónicas WordPress, que hay noticias jugositas. Si no quieres perdértelas, suscríbete al canal de Ayuda WordPress en YouTube y nos vemos en directo.

El ajuste de Search Console te saca de todas esas funciones a la vez, la etiqueta nosnippet deja una página entera sin fragmento en ningún sitio, y el atributo data-nosnippet tapa solo el trozo de texto que marques, aunque la ficha que lo explica solo habla de fragmentos.

Si quieres mi opinión, yo solo excluiría textos que tengo clarísimo que no quiero ver resumidos, y todo lo demás lo dejaría como está. Lo que sigue sale de la documentación de Google, revisada en octubre de 2026 (esto cambia rápido), y cuando algo es lectura mía te lo aviso. ¿Te lo piensas mientras te lo cuento?…

Los tres controles de un vistazo

Piensa en el folleto de una inmobiliaria… El ajuste de Search Console es pedir que tu piso no salga en el folleto nuevo, el de las respuestas con IA, aunque siga en el de siempre. nosnippet es dejar tu piso en todos los folletos sin descripción, y de paso fuera del nuevo. Luego está data-nosnippet, que es pegar un post-it sobre un párrafo concreto de la descripción.

En una tabla se ve mejor.

Hay un cuarto, max-snippet, que fija cuántos caracteres puede enseñar Google (con valor 0 es lo mismo que nosnippet). Es un ajuste muy fino y no le voy a dedicar una sección , al menos no hoy.

El ajuste de Search Console, el de toda la web

Está en Search Console, en «Ajustes > IA generativa en la búsqueda», y según la ayuda de Google lo ha desplegado para todas las webs desde el 31 de agosto de 2026.

Tiene tres opciones:

1. Heredar el valor de la propiedad superior, por defecto si tu propiedad tiene alguna.
2. Incluir tu web
3. Excluirla

Si excluyes tu web dejan de salir enlaces y contenido tuyos en las vistas creadas con IA, en el modo IA y en las funciones generativas de Google Discover, y Google te avisa de que no recibirás tráfico ni impresiones de ellas.

Lo que rastree de tu sitio tampoco podrá usarse como base de esas respuestas. El contenido de otras webs seguirá apareciendo, y puede que se parezca al tuyo (o sea, que la IA seguirá contestando, solo que sin ti).

Antes de pulsar nada conviene tener claras cuatro cosas:

• No es una señal de posicionamiento: Google dice que este ajuste no se usa como señal de posicionamiento ni de inclusión para otras partes de la Búsqueda, así que tus páginas siguen en los resultados de siempre.
• El entrenamiento de los modelos queda fuera: este ajuste no lo toca, y para limitarlo Google remite a Google-Extended, que es otro control distinto. Sobre bloquear a los bots de IA tengo otro artículo si quieres seguir por ahí.
• Salir de Google por completo es otra cosa: para eso lo que hay es noindex.
• No es inmediato: según Google el contenido queda excluido en uno o dos días desde que se aplica el cambio, aunque parte puede tardar más.

¿Es todo o nada? No del todo, aunque esto lo digo con la boca pequeña. Según la ayuda de Google, cada propiedad de Search Console tiene su propio ajuste, y el dueño de una propiedad hija (el ejemplo que ponen es una carpeta añadida como prefijo de URL, del estilo https://dominio.com/empresa/gatos) puede elegir un valor distinto para esa propiedad y sus sub-páginas.

O sea, que en teoría podrías sacar de estas funciones solo una carpeta y dejar el resto de la web como está. Por lo que he visto en mi Search Console también valdría para subdominios, pero no lo he probado, si te animas nos cuentas.

Google ha lanzado además un informe de rendimiento de IA generativa, con las impresiones de tu web en las Vistas creadas con IA y en el Modo IA por página, país, dispositivo y fecha. Sirve para ver qué páginas aparecen, pero no decidas solo con él, porque cuenta impresiones (las veces que se muestran enlaces a tu web) y no visitas, y es muy reciente. Y si ya has excluido tu web, puede salirte vacío.

nosnippet: excluir una URL completa de las búsquedas e IA

Es una etiqueta meta robots (o una cabecera HTTP X-Robots-Tag) que le dice a Google que no enseñe ni fragmento de texto ni vista previa de vídeo de esa página, en ninguna parte de la búsqueda (web, imágenes, Discover, vistas creadas con IA y modo IA).

Según la página de Google sobre la etiqueta meta robots, también impide que el contenido se use como entrada directa de las vistas creadas con IA y del modo IA. Una miniatura de imagen estática puede seguir saliendo si Google considera que mejora la experiencia.

Hay una segunda parte en esto, y aquí empieza mi lectura, y es que la guía de Google sobre las funciones de IA pide, para salir como enlace de apoyo en esas funciones, que la página esté «indexada y apta para mostrarse en la búsqueda de Google con un fragmento» (traducción mía, el original está en inglés).

Vamos, que si juntas las dos frases, una página con nosnippet no tiene pinta de poder aparecer como enlace ahí, pero esa conclusión es mía, Google no la escribe tal cual ¿tú qué opinas?

El precio se pagaría en los resultados de búsqueda, porque la página sale sin la descripción bajo el título. Cuánto te cueste en visitas no lo sé, y Google tampoco lo dice, porque ni su ficha de robots meta ni la de fragmentos documentan ningún efecto de nosnippet en la posición ni en los clics.

Mi opinión, y es solo eso, es que una página sin descripción lo tiene más difícil para que hagan clic en ella, pero no tengo un dato que lo demuestre.

Ojo con un detalle que se pasa por alto, y es que Google solo lee estas etiquetas si puede entrar a la página. Si la bloqueas en el robots.txt no llega a ver el nosnippet. De la relación entre robots.txt, el noindex y el mapa del sitio hablo en otro artículo, pero no lo visites, que queda aún el pequeñín, y también el más curioso de todos estos tres controles.

data-nosnippet: excluir solo parte de un texto de las búsquedas e IA

Este es un atributo HTML que se pone en la parte de texto que no quieres que Google use como fragmento en las SERP y los resúmenes con IA.

Se ve mejor con un ejemplo.

<p>Este texto puede salir en un fragmento
<span data-nosnippet>y esta parte no saldría</span>.</p>

<div data-nosnippet>Este bloque entero tampoco.</div>

Las reglas de Google son estas:

• Solo en tres etiquetas: span, div y section. Si lo pones en un párrafo (<p data-nosnippet>) o en una etiqueta inventada, Google lo ignora.
• Es un atributo booleano: cualquier valor se ignora, y eso incluye data-nosnippet="false", que sigue ocultando el trozo. Con que esté el atributo, vale.
• El HTML tiene que ser válido y con las etiquetas bien cerradas: un div sin cerrar hace que cuente todo lo que viene después.
• Nada de JavaScript: Google pide no añadirlo ni quitarlo con JavaScript en elementos que ya existen, porque a veces lee la página antes de renderizarla y a veces después.

Y luego están los dos (importantes) matices…

1. No es un bloqueo total: data-nosnippet no es un noindex. La página sigue indexada y el texto sigue ahí para cualquiera que la abra, solo se queda fuera de lo que Google enseña como fragmento. Si ese texto no debería ver nadie, no lo marques, quítalo de la página.
2. Lo que dice (y lo que no dice) Google sobre las IA: La frase de la «entrada directa» para las vistas creadas con IA y el modo IA aparece en los apartados de nosnippet y de max-snippet de la ficha de robots meta, pero no en el de data-nosnippet, que solo habla de fragmentos. Lo que sí hace Google es citarlo, en su guía de las funciones de IA, entre los controles para limitar lo que se muestra de tus páginas en la búsqueda. Lo que me hace deducir que sí sirve para eso, pero no hay una regla escrita de que un texto marcado quede fuera de las respuestas de IA.

Un ejemplo de uso razonable lo tienes en el plugin de compartir y resumir en IA, que marca con data-nosnippet el bloque del resumen que pone en la página, para que Google no enseñe tu propio resumen en los resultados en lugar de tu artículo. Lo conté en el artículo sobre los resúmenes con IA integrados en tu web.

En WordPress puedes escribir ese HTML a mano, en la pestaña de texto del editor clásico o en un bloque HTML personalizado, y el sistema no lo borra, porque el filtro que limpia el HTML de los usuarios sin permiso de HTML libre (wp_kses_post) deja pasar este atributo en span, div y section. Funciona, pero es incómodo y fácil de romper, y para eso están los plugins y el código de más abajo, si quieres usar este atributo de manera habitual.

Qué plugins traen estos controles

La mayoría de los plugins de SEO traen nosnippet por entrada, y casi ninguno ofrece algo para el data-nosnippet:

El último de la tabla, Visibility, ya sabrás que lo desarrollé yo, y con nosnippet por entrada hace lo mismo que los otros, pero también más cosas:

• Marcar partes de texto: un interruptor en el panel del bloque Grupo añade data-nosnippet a ese grupo cuando se muestra la página, y para palabras o frases sueltas hay un formato de texto (y botones en el editor clásico) que las envuelve en un span. Solo marca los Grupos que sean div o section, porque Google no lee el atributo en otras etiquetas.
• Reglas por tipo de contenido y por taxonomía: en Ajustes > Visibility > pestaña Indexado hay una tabla donde marcas nosnippet para todas las entradas de un tipo de contenido, y una entrada concreta se libra desmarcando su propia casilla. En las taxonomías la regla afecta a la página de archivo (la de la categoría, por ejemplo) pero no a las entradas que contiene.
• Edición rápida y acciones masivas: «Marcar como nosnippet» y «Vaciar nosnippet» desde el listado de entradas, para no abrir una por una.
• Textos marcados fuera de las descripciones automáticas: lo que marcas no se cuela en la meta descripción generada ni en las descripciones de Open Graph y Twitter.
• «Respetar nosnippet»: con esta opción (activada por defecto en las instalaciones nuevas), las páginas con nosnippet tampoco reciben texto de Visibility en llms.txt, llms-full.txt, las versiones en Markdown ni en el FAQPage.

Dos advertencias, que para eso estamos. De los plugins que he mirado ninguno más trae una función para marcar texto con data-nosnippet, mientras que nosnippet por página lo tienen casi todos, o sea que ahí hay paridad.

Y otra cosa, el atributo de los grupos se añade al mostrar la página, así que si algún día desactivas Visibility esos grupos dejan de llevarlo. Las palabras sueltas, que quedan guardadas en el contenido, sí lo conservan.

Lo mismo sin plugin, con un poco de código

Si prefieres no instalar nada, se puede hacer a mano, con un código que te recomiendo vaya en un plugin de funcionalidades propio o como mu-plugin, y si dudas de dónde pegarlos lo tienes en el artículo sobre dónde pegar códigos PHP, JS y CSS en WordPress.

El primero de estos códigos necesita WordPress 5.7 o superior (cuando llegó el filtro wp_robots), y el segundo 6.2 o superior (el procesador de etiquetas HTML que usa).

nosnippet en las páginas que elijas

Este código añade nosnippet a la etiqueta meta robots de las entradas que tengan un campo personalizado concreto, de los tipos de contenido que indiques y de una categoría con sus entradas. Cambia los nombres por los tuyos:

add_filter( 'wp_robots', 'ayudawp_nosnippet_robots' );

/**
 * Añade nosnippet a la meta tag robots de las páginas que elijas
 *
 * @param array $robots Directivas que WordPress va a generar
 * @return array
 */
function ayudawp_nosnippet_robots( $robots ) {
    $apply =
        // Entries with the custom field "ayudawp_nosnippet" set to 1.
        ( is_singular() && '1' === get_post_meta( get_queried_object_id(), 'ayudawp_nosnippet', true ) )
        // Todas las entradas de estos tipos de contenido
        || is_singular( array( 'curso', 'leccion' ) )
        // El archivo de la categoría llamada "premium" y todas sus entradas
        || is_category( 'premium' )
        || ( is_singular( 'post' ) && has_category( 'premium', get_queried_object_id() ) );

    if ( $apply ) {
        $robots['nosnippet'] = true;
    }

    return $robots;
}

Para usar el campo personalizado (ayudawp_nosnippet con valor 1) en una entrada, activa el panel de campos personalizados en las preferencias del editor.

Como usa el filtro de WordPress, la directiva se une a la etiqueta meta robots que ya genera tu web. Y si algún plugin imprime la suya aparte, por ejemplo con max-snippet:-1, Google suma las reglas y se queda con la más restrictiva, así que nosnippet gana.

data-nosnippet en cualquier bloque

Con este otro cualquier bloque que lleve la clase CSS adicional ayudawp-nosnippet (la escribes en el panel avanzado del bloque) recibe el atributo. Solo lo añade si el bloque empieza con div, span o section, porque en un párrafo suelto Google no lo leería, como te comenté antes.

add_filter( 'render_block', 'ayudawp_block_nosnippet', 10, 2 );

/**
 * Añade data-nosnippet a cualquier bloque de texto que tenga la clase CSS ayudawp-nosnippet
 *
 * Google lee data-nosnippet solo si está en un span, div y elementos section elements
 * Un bloque cuya primera tag sea otra (un p por ejemplo) queda fuera
 *
 * @param string $block_content Rendered HTML of the block.
 * @param array  $block         Datos del bloque, incluidos sus atributos
 * @return string
 */
function ayudawp_block_nosnippet( $block_content, $block ) {
    if ( '' === $block_content || empty( $block['attrs']['className'] ) ) {
        return $block_content;
    }

    $classes = preg_split( '/\s+/', trim( $block['attrs']['className'] ) );
    if ( ! in_array( 'ayudawp-nosnippet', $classes, true ) ) {
        return $block_content;
    }

    $processor = new WP_HTML_Tag_Processor( $block_content );
    if ( $processor->next_tag() && in_array( $processor->get_tag(), array( 'DIV', 'SPAN', 'SECTION' ), true ) ) {
        $processor->set_attribute( 'data-nosnippet', true );
    }

    return $processor->get_updated_html();
}

Con este código pasa lo mismo que con el plugin Visibility como te dije antes, que el atributo se añade al mostrar la página, así que si quitas el código desaparece el data-nosnippet del bloque. Y como se añade desde el servidor y no con JavaScript, cumple lo que pide Google.

Cómo comprobar si Google va a «ver» tu decisión

1. Abre la página, mira el código fuente y busca nosnippet, que saldrá dentro de la etiqueta <meta name="robots">, o data-nosnippet en el texto que hayas seleccionado.
2. Pasa la URL por la herramienta de inspección de URLs de Search Console y mira el HTML que recibió Googlebot, que es justo lo que recomienda Google para comprobar que el control es correcto y visible para su rastreador. Ten paciencia, porque Google avisa de que el rastreo puede tardar desde varios días hasta varios meses según la frecuencia con la que decida refrescar la página. Puedes pedirle un nuevo rastreo desde la propia inspección.

Esto vale para nosnippet y data-nosnippet. El ajuste de Search Console va por otro camino y, según su ayuda, se aplica en unos días.

Qué haría yo, de menos a más

A ver, mi orden es empezar siempre por lo más pequeño, que además es lo que menos cuesta.

• Un texto concreto, con data-nosnippet: Lo que te dije antes. Solo recomiendo excluir textos cuando tienes muy claro que son párrafos que quitarías tú mismo antes de que salieran en una vista creada con IA o en cualquier resumen, esas cosas que van en tus páginas y que nunca has querido ver reproducidas fuera de ellas. Hablo de los textos legales que pegas al final de una página (el párrafo, no la página legal entera), de frases comprometidas o de palabras que pueden bloquearte en según qué entornos. Y recuerda lo de antes, que no es un candado ni una promesa sobre las IA, así que si de verdad no quieres ese texto a la vista, quítalo de la página.
• Una página entera, con nosnippet: Lo reservaría para páginas que no tiene sentido que Google resuma ni extracte, como contenido de pago o las de un curso o un área de socios que se vean desde fuera. Y no lo pondría en ninguna de las que quieres que te traigan visitas desde Google, porque a esas les quitarías la descripción y, según mi lectura, la posibilidad de salir como enlace en las funciones de IA.
• Toda la web, con el ajuste de Search Console: Es una decisión de negocio más que técnica, y no la tomaría por miedo, que es lo que menos recomiendo. Si tu negocio depende de que el contenido solo se vea en tu web, tiene sentido planteárselo, pero sales de todas las funciones a la vez (salvo que lo apliques a una carpeta) y con un informe que mide impresiones, no visitas. Si lo haces, cambia una cosa cada vez y apunta la fecha, para saber qué ha pasado después.

¿Que tienes un caso concreto y no sabes en cuál de los tres encaja?, pues cuéntamelo en los comentarios y lo vemos juntos. Y si quieres seguir con el tema, tengo escrito bastante sobre las AI Overviews de Google, de cómo bloquear a los bots de IA y no menos de las etiquetas meta robots duplicadas en WordPress.

Lo normal es que lo primero que se te ocurra sea subir el límite, y muchas veces funciona. Pero subir el límite sin saber quién gasta la memoria es como poner un cubo más grande bajo una gotera, el suelo deja de mojarse, pero el tejado sigue jodido.

La documentación oficial de WordPress avisa de que ampliar la memoria puede esconder la causa real del problema, y de que si el error sigue saliendo con un límite alto toca depurar en vez de seguir subiéndolo.

Pero oye, que no seré yo quien te quite de nada, si tienes prisa ve directo al apartado de subir el límite. Si prefieres que no te vuelva a pasar el mes que viene, sigue leyendo, que te ahorra más de un susto.

Qué significa el error «Allowed memory size exhausted»

El mensaje completo tiene esta pinta:

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 65536 bytes) in /var/www/html/wp-includes/class-wpdb.php on line 1995

El primer número es el límite que tenía PHP en ese momento, expresado en bytes, para pasarlo a algo legible divides entre 1.048.576, así que en el ejemplo hablamos de 128 MB. Para que no tengas que sacar la calculadora estos son los que más te vas a encontrar:

• 33.554.432 bytes son 32 MB.
• 41.943.040 bytes son 40 MB, el valor por defecto de WordPress en una instalación normal.
• 67.108.864 bytes son 64 MB, el valor por defecto en multisitio.
• 134.217.728 bytes son 128 MB.
• 268.435.456 bytes son 256 MB.
• 536.870.912 bytes son 512 MB.
• 805.306.368 bytes son 768 MB.

El segundo número, el de «tried to allocate», es la petición que no cupo y no lo que gasta tu web. Si ves «tried to allocate 65536 bytes» (64 KB) no pienses que el culpable es una tontería de 64 KB. La memoria ya estaba casi llena y esa es la última croqueta que no te cabía después de comerte medio cocido.

La ruta y la línea te dicen dónde se acabó la memoria, no quién la gastó. Si el error termina en un archivo del núcleo, como en el ejemplo, no significa que WordPress tenga la culpa. Puede que un plugin cargara antes cien mil registros en memoria y el núcleo fuera el que se dio de bruces con el techo.

Y ojo, que muchas veces ni siquiera ves ese mensaje, pues desde WordPress 5.2, cuando un fallo fatal tumba una página, el visitante ve una pantalla que dice algo así como «Ha habido un error crítico en esta web», y si el fallo salta en el escritorio o en la pantalla de acceso, el texto te pide además que mires el correo del administrador.

Ahí puede haber un mensaje con el asunto «[Nombre de tu web] Tu sitio tiene problemas técnicos» y una frase del estilo «Se ha producido un error del tipo E_ERROR en la línea…», seguida del mensaje de PHP.

Ese correo no llega siempre. Según el código de WordPress 7.1, hace falta que el fallo salte en el escritorio, en el acceso o en alguna acción protegida, y no en la parte pública. Hace falta también que el archivo donde se acabó la memoria esté dentro de la carpeta de un plugin o de un tema, porque si es del núcleo no se envía nada. Tampoco se manda en multisitio, y por defecto WordPress envía como mucho uno cada 24 horas.

Y ahí vuelve el problema de la ruta, porque WordPress señala al plugin o al tema por el archivo donde se cortó la ejecución, así que si el plugin A se ha comido casi toda la memoria y el B es el que pide los últimos 64 KB, el correo acusará a B. Es una pista y nada más.

Qué límite manda: memory_limit, WP_MEMORY_LIMIT y WP_MAX_MEMORY_LIMIT

Aquí nos liamos casi todos, porque hay tres valores con nombres parecidísimos y cada uno hace una cosa distinta.

• memory_limit de PHP. Lo fija tu servidor, en el php.ini o en el selector de PHP del panel del hosting. Es el techo con el que arranca cada petición.
• WP_MEMORY_LIMIT. Lo define WordPress y vale 40 MB por defecto (64 MB en multisitio). Se usa para intentar subir el límite de PHP al arrancar, y solo para subirlo, nunca para bajarlo. Si PHP ya te da 256 MB y tu constante dice 64 MB, te quedas con los 256 MB.
• WP_MAX_MEMORY_LIMIT. Es el techo para las tareas pesadas, como el escritorio, el procesado de imágenes y las tareas programadas de WP-Cron (estas últimas desde WordPress 6.3). Vale 256 MB por defecto, o el límite que ya tenga PHP si es mayor.

Si tu hosting no deja cambiar el límite desde PHP, WordPress adopta el que haya y las constantes que pongas en el wp-config.php no te van a servir de nada. Eso explica muchos «he puesto 512 MB y sigue igual».

Si defines WP_MEMORY_LIMIT por encima de 256 MB y no tocas WP_MAX_MEMORY_LIMIT, este último se iguala a lo que hayas puesto, así que con una sola línea mueves los dos.

Al cargar una pantalla del escritorio, WordPress solo sube el límite hasta WP_MAX_MEMORY_LIMIT si el usuario puede gestionar opciones, o sea, un administrador. Un editor o un gestor de la tienda arranca con el límite normal, salvo en tareas concretas como tratar imágenes. Si el error solo les sale a ellos, ya tienes una pista.

Para ver qué tienes de verdad, ve a «Herramientas > Salud del sitio > Información». En la sección «Servidor» aparece el «Límite de memoria PHP», y en «Constantes de WordPress» tienes WP_MEMORY_LIMIT y WP_MAX_MEMORY_LIMIT. Si el límite del escritorio es distinto del general, salud del sitio te enseña dos líneas, la segunda con el texto «solo para las pantallas de administración».

Averigua qué consume la memoria antes de subir el límite

Antes de tocar nada, ve preguntando de lo más barato a lo más caro.

• ¿Cuándo salta?: En la portada, solo en el escritorio, al subir una imagen, al hacer una importación o a una hora fija, y eso ya cierra cerco al sospechoso. Si falla al subir imágenes, recuerda que se descomprimen en memoria y lo que cuenta son los píxeles y no el peso del archivo. Una foto de 24 megapíxeles ocupa muchas decenas de megas aunque el JPG pese 5. Si falla a horas fijas repasa tus tareas programadas como expliqué en la guía de WP-Cron.
• El correo de recuperación: Si te ha llegado ya sabes en qué carpeta se cortó la ejecución. Si no te ha llegado eso no significa que no haya fallo, pero repasa las condiciones del primer apartado.
• El archivo debug.log: Es el registro de WordPress y se activa con las constantes de depuración. Añade esto en el wp-config.php, encima de la línea «That's all, stop editing!»:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

El registro se crea en wp-content/debug.log. Busca ahí las líneas con «Allowed memory size» y fíjate en si la misma ruta se repite. Una vez es una pista y cinco veces ya es un patrón. Cuando termines desactiva la depuración y borra el archivo, porque puede ser accesible desde el navegador.

• El registro de errores del hosting: Casi todos los hostings tienen un registro de errores de PHP en el panel, que recoge los fallos aunque la depuración de WordPress esté apagada. Mira si sale ahí la misma ruta.
• El descarte que siempre hay que hacer y nunca haces aunque sea el más sencillo de probar, que mira que me duele la boca de decirlo: En un entorno de pruebas, desactiva todos los plugins y activa un tema por defecto. Si el error desaparece, ve reactivando uno a uno hasta que vuelva. Es lento, pero funciona.

Query Monitor te ayuda en las páginas que sí llegan a cargar, porque enseña consultas lentas y errores de PHP con el componente responsable. Para un fallo fatal por memoria no es para lo que está pensado, porque la página se corta antes de pintarse, y su propia documentación avisa de que en páginas con cientos de consultas él mismo gasta más memoria.

Subir el límite cuando de verdad hace falta

Cuando ya sabes que el consumo es razonable, o que vas a tratar al culpable aparte, ampliar la memoria es totalmente lógico. Eso sí, antes de tocar nada haz una copia de seguridad del wp-config.php. El orden bueno es de fuera hacia dentro, como en casi todo.

1. Primero, el panel del hosting. Casi todos tienen un selector de PHP donde puedes cambiar el memory_limit. Es el valor que manda sobre el resto, así que si puedes cambiarlo ahí, empieza por ahí.
   
2. Después, WP_MEMORY_LIMIT en el wp-config.php. Va encima de la línea que dice «That's all, stop editing!», que normalmente sigue en inglés aunque tu WordPress esté en español:

   define( 'WP_MEMORY_LIMIT', '256M' );

Fíjate en que va en mayúsculas. Las constantes de PHP distinguen mayúsculas de minúsculas, así que wp_memory_limit en minúsculas, que se ha colado en algún tutorial, no hace nada. Con la directiva del php.ini pasa algo parecido, porque se llama memory_limit y no memory.

Para empezar, 256 MB es un punto de partida razonable. Es el techo por defecto de WordPress para el escritorio y lo que SiteGround aplica a las instalaciones nuevas. Si solo necesitas más margen para el escritorio, las imágenes o las tareas programadas, puedes dejar el límite general como está y ampliar únicamente el techo de las tareas pesadas:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Así una importación desde el escritorio puede llegar a 512 MB sin que cada visita a la portada pueda pedir tanto. Piensa también que el límite es por petición, y que con muchas visitas a la vez acaba mandando la memoria total del servidor.

Ampliar no sustituye a diagnosticar. Si con 256 MB, o con 512 MB, el error sigue saliendo, el problema ya no es el límite, así que vuelve al apartado anterior y, si es un proceso pesado como una importación o un envío masivo, plantéate sacarlo al cron o partirlo en lotes.

Si tu hosting no te deja subirlo

Hay hostings donde nada de lo anterior funciona porque el valor viene fijado. En SiteGround, por ejemplo, el memory_limit de PHP está fijo en 768 MB en los planes compartidos y no se puede cambiar. Pero vamos, que con 768 MB de partida, cuando salta el error lo normal es que el problema no esté en el límite.

Otros hostings añaden un límite de RAM por cuenta, distinto del de PHP. Si el tuyo lo tiene, la web puede caerse sin que PHP llegue a escribir «Allowed memory size», y la solución pasa por el soporte de tu proveedor, no por el wp-config.php.

Subir imágenes grandes en WordPress 7.1

Si el error te sale al subir imágenes, con la 7.1 el camino puede ser distinto, y conviene saberlo para no diagnosticar a ciegas.

La 7.1 puede generar las miniaturas en tu navegador y no en el servidor. Según la nota para desarrolladores, eso evita los fallos de memoria de PHP con imágenes grandes, porque el trabajo se hace en la memoria del navegador.

Esto solo ocurre si se dan unas condiciones. Hace falta una web servida por HTTPS, un navegador basado en Chromium (Chrome o Edge 137 o superior), un equipo con más de 2 GB de memoria y al menos dos núcleos, una conexión que no sea 2G ni lenta, y una política de seguridad de contenido (CSP) que permita crear workers desde blob:. En Firefox y Safari, o si falla cualquiera de esas condiciones, WordPress vuelve a procesar la imagen en el servidor sin avisar.

Y ojo, que solo funciona en las pantallas del editor de bloques (entradas y páginas, editor del sitio y widgets). Si subes la imagen desde Medios > Añadir nuevo, las miniaturas las sigue generando el servidor.

En la práctica, si una foto te da error de memoria, prueba a subirla desde el editor con Chrome y desde la biblioteca de medios. Si solo falla por una de las dos vías, ya sabes de qué lado está el problema. Y si por algún motivo necesitas apagar el procesado en el navegador, la nota documenta este filtro, que puedes poner en un plugin propio o en el functions.php de tu tema hijo:

add_filter( 'wp_client_side_media_processing_enabled', '__return_false' );

Todo esto afecta a las subidas nuevas. Si lo que quieres es regenerar las miniaturas de toda la biblioteca, tienes la guía para regenerar miniaturas, que incluye un apartado sobre el error por memoria agotada.

Qué hacer si el error vuelve a salir

• Apunta cuándo salta y qué ruta aparece, con fecha y hora, para ver si hay un patrón.
• Comprueba qué límite tienes de verdad en salud del sitio antes de cambiar nada.
• Si la misma ruta se repite, desactiva ese plugin o ese tema en un entorno de pruebas y mira si el error desaparece.
• Sube el límite solo cuando sepas que el consumo es razonable, y deja anotado el valor que has puesto y por qué.

Si lo que te sale es otro error distinto, en la guía de los principales errores de WordPress y su solución tienes los más habituales. Para todo lo demás, dudas, besos y abrazos, me tienes ahí abajito, en los comentarios.

Curiosamente es sobre esto sobre lo que más me están preguntando últimamente los clientes del servicio de mantenimiento WordPress, siempre con la misma duda de ¿hay que hacer algo?, ¿con qué?, ¿tengo que pagar a alguien?

Pues tranqui, que en la mayoría de los casos no tienes que hacer nada, porque la caché ya está funcionando y es WordPress el que no sabe verlo. Ahora bien, «la mayoría» no es «siempre», así que vamos a ver de dónde sale el aviso, cómo saber si en tu caso es real y qué hacer en cada situación.

De dónde sale el aviso de Opcode, así, de repente

Lo que es OPcache ya te lo conté en detalle en la guía de tipos de caché en WordPress, así que no me repito, pero resumiendo mucho simplemente que sepas que guarda el código PHP ya compilado para que el servidor no tenga que procesarlo en cada visita, y es de las cachés que más se notan.

El aviso no lo habías visto antes porque no estaba ahí, llegó con WordPress 7.0, que añadió una comprobación nueva de caché de código a la salud del sitio (el ticket #63697, por si te va el cotilleo técnico).

La comprobación es de lo más fácil, porque llama a la función de PHP opcache_get_status() y si no recibe datos que digan que OPcache está activo te suelta el aviso.

El problema es que hay dos configuraciones muy habituales en las que esa función no confirma que OPcache esté activo aunque esté funcionando a pleno rendimiento:

• Caché solo en archivo: hay servidores que guardan la caché de OPcache en disco en lugar de en memoria compartida (el modo file_cache_only), y en ese modo la función responde que OPcache no está activo, porque ese dato solo se refiere a la caché en memoria (reportado en el ticket #64707).
• Consulta bloqueada por el hosting: muchos alojamientos compartidos restringen esa función por seguridad, porque podría mostrar información de los archivos de otros clientes del mismo servidor. Plesk, por ejemplo, la desactiva por defecto (es el ticket #65395).

Los dos tickets tienen propuesta de arreglo pero siguen abiertos, y WordPress aún no incluye ninguno, así que el aviso va a seguir ahí un tiempo.

El aviso no dice que OPcache esté desactivado, dice que WordPress no ha podido comprobar que esté activo, que no es lo mismo.

Cómo comprobar si el aviso de Opcode es real

Casi me da cosa decir esto, pero no te fíes de la pestaña información de la propia salud del sitio para esto, porque en estos casos tira de la misma función y te va a contar lo mismo. Sí, lo he dicho: no te fíes de WordPress 🙁

El que no miente es el phpinfo de tu servidor. Algunos paneles de hosting te lo muestran directamente, y si el tuyo no lo hace puedes crear un archivo llamado info.php con este contenido y subirlo a donde tengas instalado WordPress:

<?php phpinfo();

Visítalo en el navegador (tudominio.com/info.php), busca el bloque que empieza con Zend OPcache y fíjate en estas líneas:

• Opcode Caching: si pone Up and Running es que OPcache está funcionando, diga lo que diga WordPress.
• SHM Cache y File Cache: te dicen si la caché va en memoria compartida, en archivo o en ambas. Si SHM está en Disabled y File Cache en Enabled, estás en el modo solo archivo del que hablaba antes.
• opcache.restrict_api: si tiene alguna ruta como valor es que tu hosting está limitando la consulta, si no, pondrá no value, que significa que no hay ninguna ruta restringida.

Borra el archivo info.php en cuanto termines, porque enseña a cualquiera la configuración completa de tu servidor, y eso no se deja a la vista.

Los tres escenarios posibles

Con el phpinfo delante vas a estar en uno de estos tres casos:

• OPcache funciona y WordPress no lo ve: es lo más habitual. Pone Up and Running y el aviso es un falso positivo, así que no tienes que hacer nada más allá de ignorarlo o corregirlo con el código que te pongo más abajo. Es lo que pasa, por ejemplo, en SiteGround, que usa caché solo en archivo, de modo que el aviso sale en todas las webs alojadas allí aunque OPcache esté activo.
• OPcache está disponible pero apagado: aparece el bloque Zend OPcache pero opcache.enable está en Off, o el estado no es Up and Running. Mira en el selector de PHP de tu panel si hay una opción para activarlo y, si no la encuentras, pídeselo al soporte de tu hosting. Aquí sí ganas rendimiento.
• Tu hosting no lo ofrece: no hay ni rastro del bloque Zend OPcache. Aquí el aviso es real y, como ya te dije en la guía de cachés, un hosting que no ofrece OPcache a estas alturas es motivo para ir pensando en cambiar.

Por cierto, para que no te quedes con una idea equivocada, el modo archivo de OPcache sigue ahorrándote lo más pesado, que es compilar el código en cada petición, pero lo lee del disco en lugar de tenerlo en una memoria compartida, que es el peaje razonable de aislar la caché de cada cliente en un hosting compartido.

Cómo quitar el aviso de Opcode

Si has confirmado que es un falso positivo y te molesta verlo (o te molesta que el cliente te pregunte cada semana), tienes dos opciones.

A lo bruto es quitar el test entero con el filtro site_status_tests, igual que te enseñé en el artículo sobre optimizar la herramienta de salud del sitio, eliminando $tests['direct']['opcode_cache']. Funciona, pero tiene una pega, y es que si mañana cambias de hosting y allí OPcache está apagado de verdad, no te vas a enterar.

La que sí te recomiendo es corregir solo el resultado cuando el aviso es falso. Este código mira la configuración de PHP, que no se ve afectada ni por el modo solo archivo ni por el bloqueo del hosting, y únicamente da OPcache por activo si de verdad está activado. Si no lo está, el aviso sigue saliendo, que es lo que quieres.

Además corrige las dos pestañas, porque si solo arreglas la de estado te encuentras la prueba superada mientras «Información → Servidor» sigue diciendo que la caché está desactivada, y eso también podría despistar, y como poco sería incongruente:

<?php
/**
 * Plugin Name: AyudaWP - Corrige el falso aviso de caché Opcode
 * Description: Corrige el falso positivo de la caché Opcode en salud del sitio cuando OPcache está activo pero WordPress no puede consultar su estado.
 * Plugin URI: https://plugins.ayudawp.com/
 * Description: Corrige el falso positivo de la caché Opcode en salud del sitio cuando OPcache está activo pero WordPress no puede consultar su estado.
 * Version: 1.0.0
 * Author: Fernando Tellado
 * Author URI: https://ayudawp.com/
 * License: GPLv2 or later
 */

defined( 'ABSPATH' ) || exit;

/**
 * Comprueba OPcache en la configuración de PHP, no con opcache_get_status()
 */
function ayudawp_opcache_is_enabled() {
	return extension_loaded( 'Zend OPcache' ) && filter_var( ini_get( 'opcache.enable' ), FILTER_VALIDATE_BOOLEAN );
}

/**
 * Pestaña Estado: convierte el falso aviso en prueba superada
 */
function ayudawp_fix_opcode_cache_false_positive( $result ) {
	if ( ! isset( $result['test'] ) || 'opcode_cache' !== $result['test'] || 'good' === $result['status'] ) {
		return $result;
	}

	if ( ayudawp_opcache_is_enabled() ) {
		// Reutiliza cadenas nativas para que salgan traducidas
		$result['status']      = 'good';
		$result['label']       = __( 'Opcode cache is enabled' );
		$result['description'] = sprintf(
			'<p>%s</p>',
			__( 'Opcode cache improves PHP performance by storing precompiled script bytecode in memory, reducing the need for PHP to load and parse scripts on each request.' )
		);
	}

	return $result;
}
add_filter( 'site_status_test_result', 'ayudawp_fix_opcode_cache_false_positive' );

/**
 * Pestaña Información: corrige el «Desactivado» de la sección Servidor
 */
function ayudawp_fix_opcode_cache_debug_info( $info ) {
	if ( isset( $info['wp-server']['fields']['opcode_cache'] )
		&& true !== $info['wp-server']['fields']['opcode_cache']['debug']
		&& ayudawp_opcache_is_enabled() ) {
		$info['wp-server']['fields']['opcode_cache']['value'] = __( 'Enabled' );
		$info['wp-server']['fields']['opcode_cache']['debug'] = 'enabled (status not available)';
	}

	return $info;
}
add_filter( 'debug_information', 'ayudawp_fix_opcode_cache_debug_info' );

Lo ideal es que lo añadas como mu-plugin, guardándolo como un archivo PHP (por ejemplo ayudawp-opcode-cache-fix.php) dentro de la carpeta wp-content/mu-plugins/, que si no existe la creas. Así no depende del tema ni de que alguien desactive un plugin por error. Los textos son los mismos que usa WordPress, así que te saldrán traducidos al español sin hacer nada.

Vuelve a entrar en la salud del sitio y verás que la caché Opcode pasa a las pruebas superadas y que en la pestaña de información ya aparece como activada.

Lo que no te recomiendo hacer

Con este aviso circulan por ahí unas cuantas soluciones que o no sirven o empeoran las cosas:

• Instalar un plugin de OPcache para «activarlo»: estos plugins sirven para ver estadísticas o vaciar la caché, no pueden activar nada que el servidor no tenga activo, y con la consulta bloqueada por el hosting ni siquiera ven los datos.
• Copiar el filtro wp_site_health_opcache_status: lo verás en algún sitio como solución, pero sale de una propuesta en borrador para WordPress que no se ha incorporado, así que no hace absolutamente nada.
• Lanzar opcache_reset() a ver si se arregla: vaciar la caché no tiene nada que ver con el aviso, y en un servidor compartido sin restricciones puede vaciarla para todas las webs del servidor, no solo la tuya.
• Abrir un ticket con prisas: antes de pedirle al soporte que te active OPcache mira el phpinfo, porque lo más probable es que te contesten que ya lo tienes.
• Desactivar la salud del sitio entera: por un falso positivo te quedas sin avisos que sí importan, como una versión de PHP obsoleta o un fallo de comunicación con WordPress.org.

¿Tengo que hacer algo ya mismo?

Lo justo y necesario, para poder seguir con tu vida, en este orden:

1. Mira el phpinfo de tu servidor y si lo creas tú luego borra el archivo al terminar.
2. Si pone Up and Running olvídate del aviso o corrígelo con el código de arriba.
3. Si OPcache existe pero está apagado, actívalo desde el panel o pídeselo al soporte del hosting.
4. Si tu hosting no lo ofrece apúntalo en la lista de motivos para cambiar de hosting.

Cuando WordPress incorpore alguno de los arreglos pendientes el aviso dejará de salir solo, y el código de este artículo seguirá siendo inofensivo porque únicamente actúa cuando la prueba de salud del sitio falla.

Si en tu hosting el aviso sale y no encajas en ninguno de los tres casos, me tienes ahí abajo, en los comentarios, y lo miramos.

El miércoles no hubo Doctor WordPress porque estaba en el WordPress Agency Forum de Madrid, así que esta semana te dejo el resumen de las Crónicas solamente. La semana que viene vuelvo con las dos sesiones.

Crónicas WordPress: dos semanas de noticias en un solo directo

WordPress 7.1.2, de las actualizaciones que no se pueden dejar para mañana

Empecé por lo más serio. WordPress 7.1.2 salió el 22 de septiembre y corrige un único fallo, pero de los gordos, con una puntuación CVSS de 9,2 (el estándar con el que se mide la gravedad de las vulnerabilidades). Permitía a un atacante conseguir que WordPress incluyera un archivo PHP de su elección desde fuera de la carpeta del tema y, a partir de ahí, ejecutar código en remoto.

Hacía falta que el tema activo cumpliera cierta condición en su estructura de carpetas, algo que se da en un montón de temas muy usados. Se informó el 20 de julio y se arregló con divulgación responsable, en secreto, como debe ser. El problema es que ya había gente aprovechando la vulnerabilidad, hasta el punto de que se avisó a agencias gubernamentales de Estados Unidos. Si todavía no estás en la 7.1.2, ya estás tardando.

Un malware que se reconstruye solo y 50.000 credenciales robadas

Sucuri ha detectado un malware para WordPress que da un poquito de miedo. Se esconde en el .user.ini, en los drop-ins de caché como advanced-cache.php, en el functions.php de un tema falso o como plugin obligatorio (mu-plugin). Se instala en ocho sitios distintos y cada copia es capaz de reconstruir a las demás, así que borras una y otra la vuelve a escribir, como un bicho de muchas cabezas.

Casi siempre entra por temas y plugins «gratis» de procedencia dudosa. Te ahorras 60 dólares al año en un negocio con el que se supone que vas a ganar dinero y acabas regalando tu web para que mine criptomonedas. Tú verás.

También comenté el caso de un kit de herramientas que, a gran escala, ha robado unas 50.000 credenciales de acceso buscando copias de seguridad olvidadas, como un wp-config.php.bak, un debug.log o las contraseñas que guardan algunos plugins de correo SMTP. Ojito con lo que dejas tirado en el servidor.

Aproveché para hablar de Vigilante 3.0.0, que ahora intenta autoprotegerse. No es invulnerable (nada lo es, y el propio plugin tuvo su vulnerabilidad, de la que aprendí bastante y que os contaré en el blog), pero se trata de ponerle al campo todas las puertas que puedas.

Elementor y un clic que crea administradores

Elementor ha tenido una semana movidita. Patchstack publicó el 25 de septiembre una vulnerabilidad CSRF (falsificación de peticiones entre sitios) en las versiones 4.3.0 y 4.3.1, con un CVSS de 8,8. Un administrador con la sesión abierta que hiciera clic en un enlace manipulado podía crear, sin enterarse, otra cuenta de administrador para el atacante. Está corregida desde la 4.3.2, y con los millones de webs que lo usan todavía queda muchísima gente sin actualizar.

Ya que hablábamos de actualizar, os enseñé mi guía sobre por qué WordPress se actualiza sin tu permiso aunque hayas desactivado las actualizaciones automáticas. Muchos hostings tienen su propio sistema, que trabaja en un plano donde lo que pongas en WordPress les da igual, y en la guía repaso los tres casos (alojamiento gestionado, compartido con autoinstalador y servidor propio) y cómo controlar cuándo se actualiza. Mi consejo sigue siendo actualizar, y si tu hosting lo hace por ti y encima hace copia antes, te está haciendo un favor.

Comunidad: WordPress al frente de la Open Website Alliance y adiós a Meetup

La parte alegre. WordPress, a través de la WordPress Foundation, ha asumido la presidencia rotatoria de la Open Website Alliance, la coalición que agrupa a las organizaciones detrás de WordPress, Drupal, Joomla, TYPO3 y compañía. Se anunció el 25 de septiembre y una de sus líneas de trabajo es la Ley de Ciberresiliencia europea, sobre la que firmaron un informe en agosto. Las normativas europeas tienen su parte buena, siempre que no se vayan de olla y no frenen la innovación con la excusa de protegernos.

La otra noticia chula es events.wordpress.org: la comunidad va a dejar Meetup.com para usar un sistema propio integrado en WordPress.org. Ya se ha hecho formación para organizadores y el piloto está en marcha. El punto débil es que, por privacidad, probablemente no se migren las listas de asistentes y haya que animar a la gente a registrarse de nuevo. Si organizas un meetup en España o en cualquier país hispanohablante, te animo a apuntarte al programa piloto desde el equipo de comunidad en make.wordpress.org/community.

Y octubre viene animadísimo:

• WordPress Agency Forum, el 7 de octubre en Madrid, un evento para profesionales con mucho trabajo en grupo y aforo muy limitado.
• WordPress Accessibility Day, el 7 y 8 de octubre, online y gratuito, desde las 17:00 (hora peninsular) y con el responsable de accesibilidad de GitHub abriendo el programa.
• Meetups en Palma, Collado Villalba y León, entre otros.
• Meetup de A Coruña el 15 de octubre, donde daré una charla sobre seguridad en WordPress con presupuesto cero.
• WordCamp Galicia, el 16 de octubre en A Coruña, donde daré un curso gratuito de WordPress a primera hora.
• WordCamp Valencia, el 31 de octubre, donde también tendré la suerte de dar una charla.

WooCommerce 11.2 y las nuevas obligaciones europeas

WooCommerce 11.2 tenía que salir el 6 de octubre con estas novedades:

• Correos configurables para el derecho de desistimiento.
• Campos de fecha en la API de pago con el selector nativo del navegador, útiles para fechas de nacimiento o de entrega.
• Un importador CSV que por fin encuentra productos por GTIN, UPC, EAN o ISBN cuando no hay ID ni SKU.

Lo del checkout basado en agentes de IA se ha aparcado, así que eso no romperá nada. Lo que sí conviene revisar con tu desarrollador son los filtros de fecha si tienes algún desarrollo a medida.

Hablando de obligaciones de la UE, he actualizado mi plugin de derecho de desistimiento para que también muestre la etiqueta de garantía legal, obligatoria desde el 27 de septiembre para quien venda bienes físicos en la Unión Europea. Revisé los plugins que había, ninguno lo daba todo gratis, así que se lo añadí al mío en una mañana. En el artículo os comparo las opciones y elegís vosotros.

Lo último que he publicado en el blog

También repasé algunos artículos recientes de Ayuda WordPress que creo que os pueden venir bien:

• Las zonas, clases y métodos de envío de WooCommerce, de lo más raro que tiene el plugin desde siempre y de lo que más me preguntan los clientes.
• Cómo servir actualizaciones automáticas de tus propios plugins y temas desde tu web, con el sistema nativo de WordPress y sin obligar al cliente a instalar nada extra. Es lo que uso con plugins premium como Intelimerce.
• Dónde poner el código que comparto: functions.php solo para lo que depende del tema, un plugin propio para lo demás y ojo con abusar de los mu-plugins.

Multisitio, robots.txt y un usuario que me hace trabajar

Saludé a Albert Calzada, un usuario de Vigilante con una red multisitio que me ha ido avisando de cosas mejorables, y gracias a él Vigilante 3.1 se lleva bastante mejor con multisitio. Yo recomiendo multisitio para muy pocos casos (él lo usa para webs multilingües, uno de los pocos donde tiene sentido), y por eso casi ningún plugin está bien preparado para él.

Un ejemplo práctico: en una red multisitio con dominios mapeados, si tienes un robots.txt físico en el sitio principal, todos los sitios comparten ese mismo archivo. La solución es tirar del robots.txt virtual que WordPress genera de serie y que mi plugin SEO Visibility permite editar por sitio, igual que el llms.txt. Así lo resolví con un cliente que quería bloquear los PDF en el sitio principal pero no en los subsitios.

WordPress e IA: Novamira, Presence API y un invento raro de Automattic

Novamira es un plugin que conecta agentes de IA con WordPress mediante un servidor MCP (que, para entendernos, funciona como una API para agentes). Da acceso a ejecución de PHP, sistema de archivos, base de datos, WP-CLI y Gutenberg, se configura con abilities, skills en Markdown y políticas propias, y tiene versión gratuita y una Pro por 49 al año. Me han pedido compatibilidad con SEO Visibility y lo más probable es que le añada la Abilities API (Vigía ya la tiene). Casi todos los consejos de un chatbot sobre WordPress fallan porque no sabe qué hay en tu web, y con este tipo de integración sí lo sabe.

También comenté la Presence API, presentada en abril, que muestra en la barra de administración una etiqueta cuando un agente de IA está editando por API o MCP.

Y lo que más me sorprendió: Automattic ha lanzado sin hacer ruido una plataforma que convierte lo que genera un agente de IA en una web con su propia dirección, al estilo de Astro o Next.js. Lo que no entiendo es que, cuando en Twitter le preguntaron a Matt qué iba a hacer WordPress para competir con este tipo de herramientas, enlazara esto. Con todo lo que tiene WordPress ahora mismo (MCP, Abilities API, Presence API), promocionar otra cosa me parece un tiro en el pie.

SEO: Google, cada vez más peaje y menos tráfico

Las AI Overviews ya aparecen en el 80 % de las búsquedas de marca, y sus enlaces ni siquiera llevan a la web de la marca, sino al modo IA. Además, Merchant Center ha activado automáticamente el checkout nativo en el modo IA y en Gemini para las tiendas compatibles con UCP (un protocolo parecido a MCP pero para comercio electrónico). Puedes vender ahí, sí, pero es como Amazon: al final vas a pagar un peaje.

Google ya ha empezado a pagar a unos 100 medios por usar su contenido en las vistas creadas con IA, en un programa piloto que supone en torno al 0,1 % de sus ingresos publicitarios. Migajas, pero algo es algo. Y mientras tanto sus directrices piden revisar a mano todo el contenido hecho con IA y dicen que el bueno es el humano, justo el que se está quedando sin incentivos porque ni le dan tráfico, ni enlaces, ni dinero. Pone normas como si fuera la Unión Europea, pero no hace nada por devolver el tráfico.

Un hackeo con spam japonés y por qué un 410 lo arregló

Os conté el caso que explico en mi artículo sobre redirecciones 301, errores 404 y 410. A un cliente le hackearon la web y le llenaron Google de URLs con spam en japonés que desplazaron sus resultados de toda la vida (con los maravillosos filtros antispam de Google mirando para otro lado). Después de limpiar la web, marcar esas URLs con un 410 hizo que en pocos días desaparecieran del índice y volvieran a salir las buenas. Lo hice con SEO Visibility, que para eso lo tengo.

También os enseñé el nuevo apartado de «navegación agéntica» que aparece en PageSpeed Insights, que incluso mira el llms.txt, a pesar de que Google dice que pasa de él. En un artículo os explico qué mide y si tenéis que hacer algo, porque vuestros clientes os lo van a preguntar. Para medir estas señales tenéis mi analizador de visibilidad y una auditoría SEO automática más completa, y si no os llega os ofrezco una personalizada.

Respondiendo a un comentario sobre si ayuda mandar traducciones de plugins a WordPress.org: ayuda muchísimo, aunque yo no pueda aprobarlas, porque hace que el plugin llegue a más gente en su idioma. Y aproveché para soltar una opinión mía: tengo la sensación de que en el directorio se confía menos en los desarrolladores con apellidos que no suenan anglosajones, algo que comentan mucho los desarrolladores de la India. Llámame loco, pero se nota.

Vídeo completo: Crónicas WordPress del 5 de octubre en YouTube

Si quieres asistir en directo y participar con tus preguntas, suscríbete al canal de Ayuda WordPress en YouTube.

Las dudas que me llegan son casi siempre estas, y las trataré de contestar todas a lo largo del artículo:

• Mi aviso legal y mi política de privacidad, ¿los pongo en Disallow, en noindex o en las dos cosas?
• ¿Los dejo en el mapa del sitio o los quito?
• ¿Por qué Google Search Console me dice que una página está indexada si yo la había bloqueado?
• ¿Qué hago con la página de agradecimiento, con los filtros de mi tienda o con esa entrada del blog que no pega con el resto?

Si lo tienes claro no sé que haces leyendo aún, sino pues tira, que aquí se viene a aprender, y un poco a discutir también…

Tres herramientas, tres preguntas distintas

La forma más fácil de recordarlo es pensar en un edificio de oficinas, o un centro comercial de varias plantas, lo que mejor te encaje o apetezca.

Digamos que el Disallow es el portero, que decide quién pasa a qué plantas o departamentos.  Luego estaría el noindex, que sería como un cartel dentro que dice algo como «Zona privada: prohibido el paso», y terminaríamos con el mapa del sitio, que sería el directorio de secciones o departamentos, de cada planta, que no muestra todo lo que hay, sino solo lo que quieres facilitar el acceso.

Otro modo de explicarlo, ya el de verdad, sería así:

• Disallow (en robots.txt): responde a «¿Puede pasar por aquí el rastreador/crawler?». Google explica en su documentación sobre el robots.txt que sirve sobre todo para no saturar tu web de peticiones y que no es un mecanismo para mantener una página fuera de Google, porque si otra web enlaza esa URL Google puede indexarla igualmente, aunque no haya podido leerla.
• Noindex (en el código fuente): responde a «¿Debe salir salir esta URL en los resultados de búsqueda?». Google entra, lee la página, encuentra la etiqueta (o la cabecera HTTP equivalente) y, según su guía del noindex, la saca por completo de los resultados, aunque otras webs la enlacen.
• Mapa del sitio (archivo wp-sitemap.xml o similar en la raíz del sitio): responde a «¿Quieres que pase a ver esta URL?». Es la lista de contenidos que te gustaría que aparezcan en las SERP, y así lo plantea la guía de Google para crear un sitemap. Que una URL esté en la lista no garantiza que se indexe, ojo, es solo tu forma de decirle cuáles prefieres.

El error más habitual: Disallow y noindex a la vez

Si bloqueas una URL con Disallow y además le pones noindex, el noindex no sirve de nada, porque el rastreador no llega a entrar para leerlo. Es el cartel de la oficina con el portero delante, y nadie llega a verlo.

Lo dice la propia guía del noindex de Google, y es que para que funcione la página no puede estar en Disallow en el robots.txt, porque si lo está el rastreador nunca verá la regla y la página puede seguir apareciendo en los resultados si otras páginas la enlazan.

En Search Console lo vas a ver como el aviso «Se ha indexado aunque un archivo robots.txt la tenía bloqueada», dentro del informe de indexación de páginas.

Google explica ahí que la página se ha indexado a pesar del bloqueo porque ha encontrado un enlace a ella en otra web, y que al estar bloqueada los snippets que salen en los resultados suelen ser muy limitados.

Pasa lo mismo al revés. Si quieres que Google sepa que una URL es noindex y no le dejas rastrearla, no se va a enterar. Lo que toca es dejar el noindex y quitar el Disallow, esperar a que Google vuelva a pasar y, cuando la URL ya haya salido de los resultados, decidir si además quieres ahorrarte el rastreo.

Qué usar en cada caso

Esta tabla resume los casos más habituales, y debajo explico los que necesitan algún matiz.

Los filtros y la ordenación de una tienda

Los filtros de WooCommerce (color, talla, precio…) generan una URL distinta por cada combinación, con parámetros como filter_, min_price, max_price u orderby.

En su guía sobre navegación por facetas Google recomienda que si no necesitas esas URLs indexadas bloquees su rastreo con el robots.txt, y del canonical y del nofollow dice que suelen ser menos efectivos a largo plazo. Un ejemplo sencillo sería este:

User-agent: *
Disallow: /*?*filter_
Disallow: /*?*min_price=
Disallow: /*?*max_price=
Disallow: /*?*orderby=

Si esas URLs ya están indexadas el Disallow no las va a sacar de Google, así que primero se pone el noindex , y cuando han desaparecido se bloquea. Y pruébalo siempre antes, que un patrón mal escrito puede llevarse por delante más URLs de las que querías.

El validador de robots.txt comprueba la sintaxis, y después conviene vigilar el informe de indexación de páginas de Search Console por si empiezan a aparecer URLs bloqueadas que no esperabas.

Ofertas, sorteos y empleos que ya han caducado

Si la página tiene enlaces o visitas, lo normal es redirigirla a la oferta vigente o a la categoría, y si no tiene nada que aportar, borrarla y dejar que dé un 410 o un 404.

Aquí el noindex solo tiene sentido si la página debe seguir existiendo para quien ya la conoce, como el histórico de ganadores de un sorteo. Lo tienes explicado con detalle en el artículo sobre qué hacer con la URL de un contenido borrado.

La entrada de blog que no tiene mucho que ver con el resto de tu web

Este es el caso más discutible, y lo siguiente es mi opinión y no una regla o algoritmo de Google. De hecho ya te anticipo que, que yo sepa, Google no dice en ningún sitio que una entrada totalmente ajena a la temática habitual perjudique al resto de tu web, lo que sí pregunta en su guía de contenido útil es si tu sitio tiene un propósito o un enfoque principal.

Tampoco te hagas ilusiones con borrar, porque esa misma guía avisa de que quitar mucho contenido antiguo para que el sitio parezca más fresco no funciona.

Mi criterio es que, si la entrada enseña de verdad a las personas del equipo, cuenta cómo trabajáis o qué os importa, funciona como una extensión de tu página de «Quiénes somos», así que lo dejaría indexable y, solo que si no quieres tampoco reforzarla, la dejes fuera del mapa del sitio.

Si es una entrada de blog puramente de relleno con tres fotos y dos líneas, la mejoraría, la fusionaría con otra o le pondría noindex y arreando. Y si al final la borras, pues que vaya con redirección o un bonito 410.

Contenido duplicado con canonical a otra URL

Cuando la misma página existe en dos URLs (un artículo que re-publicas en otro sitio, una variante de una landing), en el mapa del sitio va la URL que prefieres y no la otra.

Google lo recuerda en su guía de canonicalización, donde pide no indicar una URL en el mapa del sitio y otra distinta como canónica para la misma página. Y para elegir la canónica tampoco uses noindex, porque según esa misma guía bloquearía la página por completo en la búsqueda.

Si tu plugin de SEO no saca solo del mapa del sitio las páginas con canonical a otra URL (no todos lo hacen), sácala tú a mano.

¿Y qué hacemos con la mierda esa de las páginas legales, las indexamos o no?

Para empezar, ninguna norma te obliga a indexar el aviso legal, la política de privacidad o la de cookies, pero tampoco nada te lo prohíbe, lo que piden las legislaciones y reglamentos es que el usuario las vea fácilmente, que no las ocultes.

La LSSI, en su artículo 10, pide que los datos del titular de la web estén disponibles «de forma permanente, fácil, directa y gratuita», y la página oficial de la ley aclara que basta con que sean accesibles mediante enlaces visibles con títulos claros, como el típico «quiénes somos».

Con el RGPD pasa algo parecido, y la Agencia Española de Protección de Datos habla en su informe sobre políticas de privacidad de información de fácil acceso, con enlaces en el pie de página y al final de los formularios.

Ni la ley ni el informe de la AEPD mencionan a los buscadores. Eso sí, yo no soy abogado, así que si tu caso tiene alguna particularidad consúltalo con quien te lleve lo legal.

¿Y Google? En su documentación no he encontrado ninguna regla específica para las páginas legales, así que aquí no hay una verdad oficial a la que agarrarse y toca razonarlo con lo que hace cada herramienta.

• Disallow: no sirve para nada, porque no las saca de Google (si alguien las enlaza se pueden indexar igualmente) y encima impediría leer un noindex.
• noindex: las quitaría de los resultados, pero tus visitantes las seguirían encontrando en el enlace del pie, que es lo que pide la ley. Puedes hacerlo sin incumplir nada de lo que he leído, aunque tampoco ganas nada.
• Mapa del sitio: si las dejas indexables, van como cualquier otra página normal.

Mi consejo, y es solo eso, un consejo, es ni Disallow ni noindex, y si las tienes ahora mismo en noindex tampoco es ningún drama, de hecho yo mi me acordaba y las tenía así de siempre.

Queda el argumento del E-E-A-T, que es el otro que se oye mucho. Google dice en su guía de contenido útil que el E-E-A-T en sí mismo no es un factor de posicionamiento concreto, y cuando habla de lo que ayuda a fiarse de un sitio cita las páginas de autor y la de «Acerca de», sin nombrar las legales.

Lo que sí suma es que se vea quién está detrás de la web y, en una tienda, cómo son sus envíos y sus devoluciones, y por eso esas páginas van indexables en la tabla.

Aplicarlo en WordPress, a mano o con plugin

El Disallow va en el robots.txt. WordPress genera uno virtual que solo bloquea /wp-admin/ (dejando pasar el admin-ajax.php).

Puedes ampliarlo desde un plugin de SEO, y varios traen editor para ello (Visibility, el mejor mío incluido), o subiendo tú un archivo robots.txt real a la raíz de tu web.

Si no quieres escribirlo a mano, el generador de esa misma herramienta te crea uno con las carpetas y los bots que elijas.

Ah, y ojo con la opción «Pedir a los motores de búsqueda que no indexen este sitio» de los ajustes de lectura de tu WordPress, porque mucha gente cree que mete un Disallow: / y lo que hace desde WordPress 5.3 es poner noindex a todo el sitio, como conté en su día.

El noindex se pone por página, y para ello Yoast SEO, Rank Math, All in One SEO, SEOPress y Visibility tienen una casilla en el editor de cada entrada o página.

Si prefieres hacerlo a mano este código se lo añade a las páginas que le indiques:

// Añadir noindex a páginas específicas
add_filter( 'wp_robots', 'ayudawp_noindex_paginas_concretas' );

function ayudawp_noindex_paginas_concretas( $robots ) {
    // Reemplaza los slugs con las páginas que quieras dejar fuera de los resultados
    if ( is_page( array( 'gracias', 'pedido-recibido' ) ) ) {
        $robots['noindex'] = true;
    }

    return $robots;
}

Y con el mapa del sitio hay que ir con más cuidado, porque el nativo de WordPress no sabe nada de noindex y lista todas las páginas publicadas (salvo que uses Visibility, que se integra con él y te deja personalizar eso y más cosas).

Por lo que se ve en el código, WooCommerce pone noindex al carrito, al pago y a mi cuenta, pero no las quita del mapa del sitio, eso sería cosa tuya, así que compruébalo abriendo /wp-sitemap-posts-page-1.xml en tu web.

Los plugins de SEO (Yoast SEO, Rank Math, All in One SEO, SEOPress y Visibility) pueden quitar del mapa del sitio lo que marcas como noindex. Para sacar páginas concretas sin ponerles noindex, Rank Math y All in One SEO tienen una lista de exclusión, Visibility una casilla en cada entrada (la puedes ve en la captura de más arriba, y Yoast solo lo permite por código.

Con el mapa nativo, a mano si tu plugin no lo contempla, sería así:

// Dejar fuera del mapa del sitio de WordPress páginas específicas
add_filter( 'wp_sitemaps_posts_query_args', 'ayudawp_excluir_paginas_del_sitemap', 10, 2 );

function ayudawp_excluir_paginas_del_sitemap( $args, $post_type ) {
    if ( 'page' !== $post_type ) {
        return $args;
    }

    // Reemplaza lo siguiente con los IDs de las páginas que quieras dejar fuera
    $excluded = array( 123, 456 );

    $args['post__not_in'] = array_merge( (array) ( $args['post__not_in'] ?? array() ), $excluded );

    return $args;
}

Si dudas de dónde meter estos fragmentos, lo tienes explicado en el artículo sobre dónde pegar códigos PHP, JS y CSS en WordPress.

Comprobarlo en Search Console

Con la herramienta de inspección de URLs ves cómo ha rastreado e indexado Google una página concreta, y en el informe de indexación de páginas te salen los avisos que más te interesan aquí.

• «Se ha indexado aunque un archivo robots.txt la tenía bloqueada»: es el error de Disallow más noindex del que hablábamos, y se arregla quitando el Disallow.
• «Página alternativa con etiqueta canónica adecuada»: es lo normal en las páginas que apuntan con su canonical a otra, y lo que quieres ver.
• «Duplicada: Google ha elegido una versión canónica diferente a la del usuario»: Google no ha hecho caso a tu canonical, así que revisa que el mapa del sitio, tus enlaces internos y la propia etiqueta apunten todos a la misma URL.

Tres preguntas antes de tocar nada

Cuando dudes con una página, hazte estas preguntas en este orden.

1. ¿Quiero que Google pueda entrar a verla? Si no, Disallow, pero solo si no necesitas que lea un noindex.
2. ¿Quiero que la enseñe en los resultados? Si no, noindex, y con la puerta abierta para que pueda leerlo.
3. ¿Quiero recomendársela? Si sí, al mapa del sitio y con la URL que prefieres.

Si tienes alguna página que no sabes en cuál de estos casos encaja, me tienes ahí abajo, en los comentarios, y la miramos.

Si lo que te preocupa es la web al completo pásala por la auditoría SEO gratuita, que revisa entre otras cosas el robots.txt, los mapas del sitio y la indexación, y si después te siguen quedando dudas puedes pedirme un análisis más completo al final del informe, también gratis.

Por si quieres seguir con el tema, tengo más escrito sobre los archivos por fecha y los archivos de autor, sobre cómo configurar el mapa del sitio nativo, sobre el robots.txt en multisitio y sobre si te conviene bloquear a los bots de IA.

Para todo lo demás, me preguntas ahí abajo en los comentarios.