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

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

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

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

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

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

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

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

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

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

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

Lo que había dentro del bicho…

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

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

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

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

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

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

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

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

Tres webshells disfrazados de archivo de WordPress

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

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

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

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

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

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

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

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

Un redireccionador con puerta trasera incluida

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

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

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

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

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

El catálogo de trucos para pasar desapercibido

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

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

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

Lo que cuentan las fechas (y lo que no)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cómo comprobar tu WordPress en un momentito

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

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

Compara con una copia limpia de WordPress

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

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

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

Mira qué hay en la carpeta raíz

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

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

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

Busca PHP donde no debería haberlo

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

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

Si tienes SSH busca los trucos de camuflaje por su contenido

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

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

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

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

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

Revisa los cambios recientes sin fiarte de las fechas

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Si encuentras algo tienes tarea

Sin prisas pero sin pausa, y en este orden:

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

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

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

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

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

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

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

El Doctor WordPress del miércoles no lo hice por un asunto personal que no podía mover, así que la semana que viene volvemos a la doble ración habitual.

Te cuento lo más importante de lo que hablé, y al final tienes el enlace al vídeo completo, con todas las fuentes en la descripción.

Crónicas WordPress: PHP2Shell, debacle del tráfico desde ChatGPT y Google, y WordPress 7.2 a la vista

Una de las peores semanas de seguridad que recuerdo

Lo más gordo fue PHP2Shell. El 21 de octubre el proyecto PHP sacó parches de urgencia para todas las ramas con soporte (8.2, 8.3, 8.4 y 8.5) por dos fallos de memoria que, combinados, permitían a un atacante ejecutar código en el servidor sin tener ni siquiera una cuenta, y de paso leer de la memoria contraseñas, tokens y claves de API. Los parches estaban previstos para el 22, pero los identificadores se filtraron el 20 con una puntuación de 10, así que tocó correr.

Todo hay que decirlo, los buenos hosting hicieron su trabajo. SiteGround metió reglas en el servidor para desactivar las funciones afectadas antes de que saliera el parche, Kinsta tiró de reglas de Cloudflare y protección propia, y otros aplicaron mitigaciones temporales. Ahora bien, todavía hay hostings que no han actualizado PHP, y que tu sitio te diga «8.5.3» no te dice si estás a salvo (la segura, en esa rama, es la 8.5.12).

Por eso publiqué un post con un mini plugin que te dice qué versión tienes y cuál deberías tener, y actualicé Vigilante para que te avise si estás en una versión de PHP insegura.

Y no fue solo PHP. Ese mismo día Node.js corrigió diez fallos, uno de ellos en el descompresor Brotli que usa medio internet, y NGINX y MySQL también tuvieron su ración. O sea, en una semana cayeron el lenguaje, el servidor web, la base de datos y la librería de compresión.

Cuando el peligro viene de la versión de pago

En WordPress lo más preocupante fueron dos ataques a la cadena de suministro, y ojo, que no hablamos de plugins gratuitos de WordPress.org, sino de versiones de pago:

• A UpdraftPlus le entraron en la base de datos de clientes y robaron las claves que conectan las webs con UpdraftCentral, su panel de gestión. Con ellas metían puertas traseras que se saltaban el inicio de sesión y el 2FA. Ya está parcheado, pero si lo usas, revisa.
• Rank Math PRO 3.0.123 salió de sus propios servidores con un troyano dentro, entre la noche del 15 y la mañana del 16 de octubre. Si activaste esa versión, lo más probable es que estés hackeado, y el consejo no es actualizar sino borrar la versión afectada e instalar la nueva desde cero.

También comenté el mercado negro de accesos a escritorios de WordPress, que se venden a cien dólares para estafas de falso soporte técnico. Si quieres entender cómo funcionan estos ataques, te dejo por qué ya ni siquiera puedes fiarte de los plugins de WordPress.org (el titular tiene su punto de clickbait, lo admito).

Y ya que estamos, conté cómo reviso ahora la seguridad de mis plugins, por qué cambié el proceso y dónde tienes las skills que uso. Tardo bastante más en sacar cada versión, pero salen bastante más seguras. Me ayudo de la IA, claro, porque si los malos te atacan con metralletas no te vas a defender con una navaja.

Comunidad: herramientas para contribuir y un nuevo patinazo de Mullenweg

La parte buena es el Contributor Toolkit 2.0, una aplicación que te montas en el ordenador con un WordPress dentro y desde la que puedes enviar al Trac un ticket del fallo que encuentres sin pelearte con toda la instalación. No es lo más intuitivo del planeta, pero es mucho más fácil que antes.

La parte mala: Matt Mullenweg apartó a Andrea Fercia, especialista en accesibilidad que lleva contribuyendo desde 2015 y ha participado en 33 versiones de WordPress, y revirtió una mejora para que los avisos del escritorio se pudieran leer con lectores de pantalla. Una persona ciega le ha escrito una carta abierta pidiendo explicaciones. Sigo sin entender estas decisiones, salvo que vea la accesibilidad como un freno a la innovación, que ya sería grave.

Y no pude ir a WordCamp Valencia, donde tenía charla en el meetup y en la WordCamp. Si puedes, ve, que hay gente estupenda que lo va a hacer muy bien sin mí.

WordPress 7.2 beta 1 y lo que viene en desarrollo

Ya está la beta 1 de WordPress 7.2, prevista para el 8 de diciembre. Mucho Gutenberg, mejoras en estilos globales, en la subida de medios y algún widget nuevo de escritorio que no juraría que llegue. Para mí lo importante es la nueva API de secretos, que por fin da a los desarrolladores un modo de guardar cifradas claves de API y tokens, algo que le faltaba a WordPress y que, con todo lo que acabamos de contar, llega en buen momento.

Otras novedades de desarrollo:

• Vuelven las notificaciones unificadas de WordPress, con versión funcional prevista para diciembre. No sé a qué versión irán, yo apostaría más por la 7.3 que por la 7.2.
• Firefox ya apoya, y Safari deja de oponerse, a la política de aislamiento de documentos que necesita WordPress para procesar imágenes en el navegador, así que eso ya no dependerá solo de Chrome.
• El MCP (el protocolo que permite a las IA comunicarse con tu WordPress) va camino del núcleo, con la 7.3 como posible objetivo.

También repasé varios posts que he publicado estas semanas, por si te los perdiste:

• «Allowed memory size exhausted», cómo leerlo antes de subir el límite.
• El aviso de la caché Opcode y el error «You do not have permission to manage plugins», dos avisos del escritorio que no dicen lo que parece.
• Los plugins experimentales de WordPress.org, que deberían avisar mejor de lo que son. Performance Lab tiene más de 100.000 instalaciones, Speculative Loading 70.000 y el plugin oficial de IA 60.000, y son experimentos para probar, no para tenerlos activos de serie.

Las ventas de plugins caen y la IA no manda visitas

Katie Keith, fundadora de Barn2, ha hecho un ejercicio de transparencia que se agradece: sus ventas nuevas han caído un 48 % en dos años, sus visitas orgánicas un 86 % y las búsquedas de tutoriales un 91 %, y en 21 de sus 22 búsquedas objetivo aparece un resumen de IA. Ya tenemos culpable. Su respuesta ha sido menos blog y más redes, YouTube y presencia en otros sitios. Le pone números a lo que muchos notamos y casi nadie cuenta.

A esto se suma el estudio de Marie Haynes: 12 meses de Analytics en 100 webs, más de 145 millones de sesiones, y ChatGPT trajo el 0,62 % de las visitas que trajo Google orgánico, que ya de por sí manda poco. Y sus anuncios, de momento, no venden.

Mi consejo, que es lo que me ha funcionado a mí y a clientes: deja de escribir para la pregunta «cómo hago X», que la IA responde sola, y escribe para «dónde aprendo X» o «qué web me recomiendas para X», que es cuando el usuario ya quiere visitar webs y la IA le manda a ellas.

Mientras tanto, Google mete más enlaces en sus respuestas con IA, pero sin datos de clics en Search Console y asociados a textos que se inventa a partir del tuyo. Por eso escribí sobre nosnippet y data-nosnippet, que ahora Google también documenta en su ayuda, y que te permiten sacar de las respuestas de IA páginas enteras o párrafos concretos. Te explico cómo hacerlo con varios plugins, con mi plugin Visibility [ENLAZAR: Visibility] o con un filtro de código si no quieres plugins.

Y cerré con algo que hemos visto en varias webs de los clientes de mantenimiento, que de repente se caían: los filtros de WooCommerce pueden convertirse en una trampa de rastreo, un laberinto de URL del que los bots no saben salir y que puede tumbar tu tienda.

Vídeo completo: PHP2Shell, debacle del tráfico desde ChatGPT y Google, WordPress 7.2 a la vista #CrónicasWordPress

Nos vemos el lunes

El lunes vuelven las Crónicas y el miércoles el Doctor WordPress, con su truco y sus preguntas en directo. Si quieres que trate algún tema, o tienes una duda para el Doctor, me tienes ahí abajo, en los comentarios, y si no quieres perderte ningún directo, suscríbete al canal.

Lo que sí ha cambiado es que desde el 28 de agosto de 2026 Google dice con todas las letras qué formatos admite para el favicon, y en la lista no están ni WebP, ni AVIF, ni SVG. Y resulta que WordPress te deja subir el icono del sitio en WebP o AVIF, o te lo convierte un plugin de optimización sin que te enteres.

Vamos a ver si el favicon pinta algo en el SEO, qué formatos y etiquetas funcionan y cuáles no, dónde están las trampas de WordPress y cómo comprobar el tuyo en cinco minutos.

¿Pero Google no había quitado los favicons?

Lo que quitó Google fueron las fotos de los autores, en 2014, y poco después toda la autoría que venía de Google+ (¿a que ni te acordabas que Google tuvo su red social?).

Los iconos de las webs son otra historia, y bastante más movida:

• En mayo de 2019 Google rediseñó los resultados del móvil y puso el nombre de la web y su icono encima de cada resultado.
• En enero de 2020 llevó ese diseño al ordenador y, tras una buena ración de críticas porque los anuncios se confundían con los resultados normales, a los pocos días empezó a quitarlos. Sospecho que de ahí viene la idea de que Google los había eliminado, al menos la mía.
• En octubre de 2022, cuando estrenó los nombres de sitio en el móvil, Google dejó claro en su blog que seguía mostrando los favicons, y recomendó un icono de al menos 48 píxeles.
• En marzo de 2023 los nombres de sitio y los iconos llegaron al ordenador, y el 7 de septiembre de 2023 los nombres de sitio llegaron a todos los idiomas, español incluido.

Hoy la galería oficial de elementos visuales de Google incluye el favicon como parte de la atribución de cada resultado, es decir, lo que le dice al usuario de dónde viene, junto al nombre del sitio y la URL visible. El nombre del sitio se controla de otra forma, con datos estructurados, y da para otro artículo.

Y si en agosto de 2026 viste el icono de tu web cambiado por un globo gris, la culpa no era tuya, porque entre el 16 y el 23 de agosto le pasó a muchísimas webs y Google reconoció que el fallo era suyo.

¿Sirve el favicon para el SEO? ¿da autoridad o E-E-A-T?

Por ahí leerás que un buen favicon «transmite confianza» y «mejora tu E-E-A-T». Vamos a poner las cartas sobre la mesa, porque si nos quedamos con lo que dice Google, no encontrarás en su documentación nada que relacione el favicon con el posicionamiento.

• Dónde lo pone Google: la información sobre el favicon está en la parte de la documentación que trata del aspecto de tu web en los resultados, con el nombre del sitio, los títulos y los fragmentos, y no en la que explica cómo ordena Google los resultados.
• El E-E-A-T: las directrices para los evaluadores de calidad, el documento de 182 páginas (versión del 11 de septiembre de 2025) donde Google explica qué es eso del E-E-A-T, no mencionan el favicon ni una sola vez.
• La única relación es en negativo: en el apartado 4.5.3 de esas directrices, entre las webs engañosas que se llevan la nota más baja, están las que se hacen pasar por otra copiando el logo o la imagen de marca de un sitio con el que no tienen nada que ver. Y ni eso te hunde por sí solo, porque las propias directrices aclaran que ninguna valoración individual afecta directamente a cómo aparece una página en Google.

Lo que sí hace es ayudar a que te reconozcan. Cuando alguien ve una lista de resultados, o las fuentes que enlaza la respuesta de la IA de Google, el icono es una de las primeras cosas que distinguen tu web de las demás, sobre todo si esa persona ya te conoce. Y fuera de Google es lo que ves en la pestaña del navegador, en los marcadores y en la pantalla de inicio del móvil cuando alguien guarda tu web, que tampoco es poca cosa.

Y aquí va mi opinión, que no es de Google ni la he medido, y es que un lector que reconoce tu icono entre diez resultados tiene más papeletas para hacer clic en el tuyo, mientras que un globo gris genérico no ayuda nada a que te reconozcan.

El favicon no te sube posiciones, pero es lo que hace que te reconozcan entre los demás resultados.

Si quieres trabajar el E-E-A-T de verdad, tienes mi guía sobre el E-E-A-T en WordPress, y ya te adelanto que el icono no sale.

Los formatos de favicon que admite Google, y los que no

El 28 de agosto de 2026 Google cambió la ficha del favicon para enumerar los formatos admitidos, que son BMP, GIF, ICO, PNG, JPEG, PPM y TIFF. En su registro de cambios explica que los formatos no han cambiado, que antes enlazaba a una referencia externa que se iba actualizando y que eso creaba confusión.

O sea, que el SVG nunca ha estado admitido para el favicon en Google, aunque la referencia de antes llevara a pensar lo contrario.

El SVG merece un comentario aparte, porque los navegadores sí lo admiten como favicon (Chrome y Edge desde la versión 80, Firefox desde la 41 y Safari desde la 26, más del 92 % de los usuarios según Can I use) y muchos generadores de favicons lo incluyen. Para la pestaña del navegador te vale, pero para Google no.

Y no lo confundas con el logo de los datos estructurados de organización, que es otra cosa y sí admite WebP, SVG y AVIF, porque sigue los formatos de Google Imágenes, con un mínimo de 112 × 112 píxeles. El favicon tiene su propia lista, y es más corta.

Mi consejo es que uses un PNG cuadrado de 512 × 512 píxeles y te olvides, porque es lo que pide WordPress y cumple de sobra con Google.

Las etiquetas rel de toda la vida, y cuáles lee Google

Google saca el favicon de una etiqueta <link> en la cabecera de tu portada, y de esa etiqueta solo se fija en dos atributos, rel y href. Los valores de rel que admite son estos:

• icon: el estándar actual.
• shortcut icon: la forma antigua, que Google sigue leyendo por razones históricas.
• apple-touch-icon: el icono pensado para iPhone y iPad.
• apple-touch-icon-precomposed: la variante para versiones antiguas de iOS.

Una declaración a mano, como se ha hecho siempre, sería algo así:

<link rel="icon" href="https://tudominio.com/favicon-192.png" sizes="192x192">
<link rel="apple-touch-icon" href="https://tudominio.com/apple-touch-icon.png">

Los atributos sizes y type le sirven al navegador para elegir, pero Google no los menciona. Tampoco nombra el manifiesto (site.webmanifest o manifest.json), el mask-icon de Safari ni la etiqueta msapplication-TileImage de Windows, así que no cuentes con ellos para salir en Google.

Además del formato la documentación de Google pone estas condiciones:

• En la portada: la etiqueta tiene que estar en la página de inicio, que es de donde la lee Google.
• Cuadrado: proporción 1:1 y al menos 8 × 8 píxeles, aunque Google recomienda más de 48 × 48.
• Rastreable: Googlebot tiene que poder rastrear la portada y Googlebot-Image el archivo del icono, así que ninguno de los dos puede estar bloqueado.
• Con una URL estable: no cambies la dirección del icono cada dos por tres.
• Uno por nombre de host: tudominio.com y tienda.tudominio.com pueden tener cada uno el suyo, pero tudominio.com/blog comparte el de la raíz.
• Representativo y apropiado: tiene que representar tu marca, y si Google ve en él pornografía o símbolos de odio lo cambia por un icono por defecto.

El icono puede estar alojado fuera de tu web, en un CDN por ejemplo. Y aunque cumplas todo lo anterior, Google no garantiza que lo muestre.

Ojo también con el favicon.ico de toda la vida, porque muchas webs tienen ese archivo en la raíz sin ninguna etiqueta que lo declare, ya que los navegadores lo buscan ahí por su cuenta. Google no documenta que haga lo mismo, así que no te fíes de que lo encuentre si no lo declaras en la portada. Al final te cuento qué me he encontrado yo con esto.

Dónde se pone el favicon en WordPress y qué sale

En WordPress se llama icono del sitio, y lo puedes poner en tres sitios:

• En «Ajustes > Generales > Icono del sitio», desde WordPress 6.5.
• En «Apariencia > Personalizar > Identidad del sitio», con los temas clásicos.
• En los temas de bloques, en el bloque «Logotipo del sitio», activando «Usar como icono del sitio».

WordPress te pide una imagen cuadrada de al menos 512 × 512 píxeles, la recorta y genera varios tamaños. En la cabecera de todas tus páginas, portada incluida, imprime algo así:

<link rel="icon" href="https://tudominio.com/wp-content/uploads/2026/10/cropped-icono-32x32.png" sizes="32x32" />
<link rel="icon" href="https://tudominio.com/wp-content/uploads/2026/10/cropped-icono-192x192.png" sizes="192x192" />
<link rel="apple-touch-icon" href="https://tudominio.com/wp-content/uploads/2026/10/cropped-icono-180x180.png" />
<meta name="msapplication-TileImage" content="https://tudominio.com/wp-content/uploads/2026/10/cropped-icono-270x270.png" />

Con un PNG lo hace bien, porque declara uno de 32 × 32 para la pestaña del navegador y otro de 192 × 192 que cumple de sobra con lo que recomienda Google. La etiqueta de 270 × 270 es para los mosaicos de Windows, y Google no la menciona.

El método de toda la vida, pegar la etiqueta en el header.php del tema o colgarla de wp_head, sigue funcionando, pero en WordPress ya no tiene mucho sentido, porque el icono del sitio hace lo mismo y no se pierde al cambiar de tema.

Las trampas del icono del sitio en WordPress

Para no quedarme en lo que dice el código he montado un WordPress 7.1.3 de pruebas y he repetido con iconos en distintos formatos el mismo proceso de subida y recorte que hace la pantalla del icono del sitio. Esto es lo que ha salido.

El icono conserva el formato que subes

WordPress admite imágenes WebP desde la versión 5.8 y AVIF desde la 6.5, y el icono del sitio se queda en el formato del archivo que subes. Con un PNG las cuatro etiquetas salen en PNG, pero con un WebP las cuatro salen en WebP, y ese formato no está en la lista de Google.

El navegador lo enseña sin problema en la pestaña, así que no notas nada raro, y por eso pasa desapercibido.

Con AVIF no pude completar la prueba porque el editor de imágenes de mi servidor de pruebas no lo procesaba bien, pero el código sigue el mismo camino que con WebP, así que cuenta con el mismo resultado. Si tu servidor no sabe procesarlo, al recortar verás el aviso «No se ha podido procesar la imagen».

Un plugin de optimización te lo convierte sin preguntarte

Esta es la más traicionera, porque ni siquiera has subido un WebP. Modern Image Formats, el plugin del equipo de rendimiento de WordPress, con más de 100.000 instalaciones activas, convierte a WebP los PNG y JPEG que subes, y el icono del sitio no se libra. En mi prueba, con la versión 2.7.1 y su configuración por defecto, subí un PNG y las etiquetas del icono salieron en WebP.

La solución está en Ajustes > Medios, en la sección Formatos modernos de imagen, donde tienes que marcar en Salida de imágenes de reserva la casilla Genera también imágenes de reserva en el formato de subida original. Con esa casilla marcada el icono que subí después salió en PNG.

El ajuste solo cuenta para lo que subas a partir de ese momento, así que el icono que ya tenías sigue en WebP hasta que lo vuelvas a subir.

Si usas otro plugin que convierta las imágenes al subirlas y sustituya el original, o algún fragmento de código que use el filtro image_editor_output_format, te puede pasar lo mismo. La forma de saberlo es mirar la extensión de las etiquetas, como te cuento más abajo.

No te deja subir un ICO ni un SVG

En mi prueba la biblioteca de medios rechazó el .ico con el aviso «Lo siento, no tienes permisos para subir este tipo de archivo», y el SVG no está permitido de serie. Con BMP depende del editor de imágenes del servidor, porque con GD el recorte falló y con Imagick funcionó.

Si quieres un favicon.ico de los de siempre, súbelo a la raíz de tu web con el gestor de archivos de tu hosting o por FTP, y el servidor lo entregará directamente, sin pasar por WordPress. Eso sí, acuérdate de lo que te decía antes, porque Google lee las etiquetas de la portada y el archivo de la raíz no sustituye al icono del sitio.

Sin icono del sitio, /favicon.ico lleva al logo de WordPress

Si no configuras un icono del sitio, WordPress no imprime ninguna etiqueta. Y si alguien pide tudominio.com/favicon.ico y no tienes ese archivo en la raíz, WordPress lo redirige con un 302 a wp-includes/images/w-logo-gray-white-bg.png, la W gris de WordPress de 80 × 80 píxeles.

Si tienes icono del sitio esa misma dirección redirige a la versión de 32 × 32 de tu icono, en el formato que tenga.

Otras cosas que lo pueden estropear

• Un icono pequeño: WordPress te pide 512 × 512, pero no te impide subir uno más pequeño, y en ese caso no lo agranda. En mi prueba con uno de 39 × 39 píxeles, la etiqueta de 192 × 192 apuntaba a la imagen original de 39 × 39, por debajo de lo que recomienda Google.
• Varias fuentes de iconos a la vez: algunos temas antiguos tienen su propio campo para el favicon, y los plugins generadores de favicons meten su propio paquete de etiquetas, a veces con un SVG y un manifiesto. Google no documenta cuál elige si hay varios, así que lo sensato es tener una sola fuente de iconos y que lo que declares esté en un formato admitido.
• La caché: después de cambiar el icono vacía la caché de página y la del CDN, porque Google lee el HTML de la portada que le sirves, y si tu caché sigue sirviendo la antigua verá las etiquetas viejas.
• El robots.txt: el icono del sitio vive en wp-content/uploads, así que si bloqueas esa carpeta, o bloqueas a Googlebot-Image para que tus imágenes no salgan en Google Imágenes, Google no podrá leer el icono. Si tienes dudas con los bloqueos, te lo explico en cuándo usar Disallow, noindex o el sitemap.
• Multisitio en subdirectorios: cada sitio de la red puede tener su icono, pero para Google todos comparten el de la portada principal, porque están en el mismo nombre de host. Con subdominios cada uno tiene el suyo, igual que pasa con el robots.txt en multisitio.
• Cambiarlo a menudo: cada vez que subes un icono nuevo, WordPress crea archivos con otro nombre, y Google pide una URL estable. Cambiarlo cuando renuevas tu imagen está bien, pero cada mes no.

Lo que funciona y lo que no con los favicon y Google

Cómo comprobar si tu favicon es visible en Google

1. Abre tu portada y mira el código fuente (Ctrl+U en Windows, Cmd+Option+U en Chrome para Mac). Busca icon y fíjate en la extensión de cada dirección, porque .png, .ico, .jpg o .gif están bien, y .webp, .avif o .svg no.
2. Abre en el navegador la dirección del icono más grande, para ver que carga y que es cuadrado.
3. Mira tu tudominio.com/robots.txt y comprueba que no bloquea wp-content/uploads ni a Googlebot-Image.
4. En Search Console inspecciona la URL de tu portada, pulsa Probar URL publicada y, en Ver página probada, busca las etiquetas en el HTML. Así ves lo mismo que ve Google.
5. Si has cambiado algo vacía la caché y pulsa Solicitar indexación en esa misma inspección.
6. Ten paciencia, porque Google avisa de que volver a rastrear la portada puede llevar de varios días a varias semanas.

Una comprobación en la salud del sitio

Si llevas varias webs, o quieres que WordPress te avise si algún plugin te cambia el formato del icono, te dejo un pequeño plugin que añade una comprobación a Herramientas > Salud del sitio.

Te avisa si no tienes icono del sitio, si WordPress lo está imprimiendo en WebP, AVIF, SVG o HEIC, y si el icono más grande que puede servir mide menos de 48 × 48 píxeles. No mira tu robots.txt, ni tu caché, ni lo que muestra Google, así que úsalo como complemento de la comprobación manual.

Crea en tu ordenador un archivo llamado ayudawp-site-icon-check.php con este contenido, súbelo a wp-content/plugins con el gestor de archivos de tu hosting o por FTP y actívalo en la pantalla de Plugins:

<?php
/**
 * Plugin Name: AyudaWP - Comprobar el icono del sitio para Google
 * Description: Añade a la salud del sitio una comprobación del formato y el tamaño del icono del sitio, según los formatos que admite la Búsqueda de Google.
 * Plugin URI: https://ayudawp.com/
 * Version: 1.0.0
 * Author: Fernando Tellado
 * Author URI: https://ayudawp.com/
 * License: GPLv2 or later
 * Text Domain: ayudawp-site-icon-check
 */

defined( 'ABSPATH' ) || exit;

/**
 * Register the check as a direct Site Health test.
 *
 * @param array $tests Site Health tests.
 * @return array
 */
function ayudawp_site_icon_register_test( $tests ) {
	$tests['direct']['ayudawp_site_icon'] = array(
		'label' => __( 'Icono del sitio para Google', 'ayudawp-site-icon-check' ),
		'test'  => 'ayudawp_site_icon_test',
	);

	return $tests;
}
add_filter( 'site_status_tests', 'ayudawp_site_icon_register_test' );

/**
 * Check the format and size of the icons WordPress prints in the head.
 *
 * @return array Site Health test result.
 */
function ayudawp_site_icon_test() {
	$result = array(
		'label'       => __( 'El icono del sitio está en un formato que Google admite', 'ayudawp-site-icon-check' ),
		'status'      => 'good',
		'badge'       => array(
			'label' => 'SEO',
			'color' => 'blue',
		),
		'description' => '',
		'actions'     => sprintf(
			'<p><a href="%s">%s</a></p>',
			esc_url( admin_url( 'options-general.php' ) ),
			esc_html__( 'Ir a Ajustes > Generales', 'ayudawp-site-icon-check' )
		),
		'test'        => 'ayudawp_site_icon',
	);

	// No site icon: WordPress prints no icon tags and /favicon.ico redirects to the WordPress logo.
	if ( ! has_site_icon() ) {
		$result['status']      = 'recommended';
		$result['label']       = __( 'No has configurado un icono del sitio', 'ayudawp-site-icon-check' );
		$result['description'] = '<p>' . esc_html__( 'Sin icono del sitio, WordPress no imprime ninguna etiqueta de icono en la portada y la dirección /favicon.ico redirige al logo de WordPress, salvo que tengas un archivo favicon.ico propio en la raíz de la web.', 'ayudawp-site-icon-check' ) . '</p>';

		return $result;
	}

	// Formats Google Search does not list as supported for favicons.
	$unsupported = array( 'image/webp', 'image/avif', 'image/svg+xml', 'image/heic', 'image/heif' );
	$bad_formats = array();

	foreach ( array( 32, 192, 180 ) as $size ) {
		$url = get_site_icon_url( $size );
		if ( ! $url ) {
			continue;
		}

		$filetype = wp_check_filetype( (string) wp_parse_url( $url, PHP_URL_PATH ) );
		if ( $filetype['type'] && in_array( $filetype['type'], $unsupported, true ) ) {
			$bad_formats[] = strtoupper( $filetype['ext'] );
		}
	}

	// Largest icon WordPress can serve (a small upload is served as is).
	$image   = wp_get_attachment_image_src( (int) get_option( 'site_icon' ), array( 192, 192 ) );
	$largest = $image ? (int) min( $image[1], $image[2] ) : 0;

	$messages = array();

	if ( $bad_formats ) {
		$messages[] = sprintf(
			/* translators: %s: image format, such as WEBP or AVIF. */
			esc_html__( 'WordPress está imprimiendo tu icono en formato %s, y la Búsqueda de Google solo admite BMP, GIF, ICO, PNG, JPEG, PPM y TIFF. Sube el icono otra vez en PNG y comprueba que ningún plugin lo convierta a WebP o AVIF al subirlo.', 'ayudawp-site-icon-check' ),
			esc_html( implode( ', ', array_unique( $bad_formats ) ) )
		);
	}

	if ( $largest && $largest < 48 ) {
		$messages[] = sprintf(
			/* translators: 1: width in pixels, 2: height in pixels. */
			esc_html__( 'El icono más grande que puede servir WordPress mide %1$d por %2$d píxeles. Google pide un mínimo de 8 por 8 y recomienda más de 48 por 48. Sube una imagen cuadrada de al menos 512 por 512 píxeles.', 'ayudawp-site-icon-check' ),
			$largest,
			$largest
		);
	}

	if ( $messages ) {
		$result['status']      = 'recommended';
		$result['label']       = __( 'El icono del sitio puede no salir en los resultados de Google', 'ayudawp-site-icon-check' );
		$result['description'] = '<p>' . implode( '</p><p>', $messages ) . '</p>';

		return $result;
	}

	$result['description'] = '<p>' . esc_html__( 'El formato y el tamaño del icono cumplen lo que pide Google. Que salga en los resultados depende además de que Google pueda rastrear la portada y el icono, y de que vuelva a pasar por tu web.', 'ayudawp-site-icon-check' ) . '</p>';

	return $result;
}

Lo he probado en el WordPress de pruebas sin icono, con iconos en PNG, GIF, BMP y WebP, con el PNG convertido por Modern Image Formats y con el de 39 × 39 píxeles. En cada caso sale el aviso que toca.

Cuando hayas revisado tus webs desactívalo y bórralo, o déjalo puesto si quieres que vigile. Si no tienes claro dónde poner este tipo de códigos, tienes mi guía sobre plugin, functions.php, snippets o mu-plugin.

¿Que ha pasado con mis webs?

El 14 de octubre de 2026 busqué en Google, desde el ordenador y con el operador site:, cada una de mis webs para ver qué icono enseña. Del móvil no tengo datos, y el diseño de los resultados no es el mismo, así que no lo extrapoles.

• ayudawp.com: declara tres etiquetas con PNG de 32, 192 y 180 píxeles, y sale el logo.
• dietpress.dev: declara un JPG y también sale bien.
• mantenimiento.ayudawp.com: no declara ninguna etiqueta y solo tiene un /favicon.ico que redirige a un PNG de 39 × 39 píxeles. Sale ese icono, que es distinto del de la web principal.
• plugins.ayudawp.com: tampoco declara etiqueta y sale el logo de AyudaWP, aunque como es el mismo de la web principal no sé de dónde lo saca, pero supongo que del dominio principal.
• herramientas.ayudawp.com: declara un ICO y el icono sale casi en blanco.
• visibility.quest: no tiene icono y sale el globo gris.

Lo más curioso es lo de mantenimiento.ayudawp.com: enseña su icono sin tener etiqueta, o sea que Google, en la práctica, sí ha encontrado el /favicon.ico aunque no lo documente. Aun así yo seguiría declarándolo en la portada, porque lo que no está en la documentación puede dejar de funcionar sin avisar.

Esa misma web tiene otro detalle, y es que el archivo del icono se llama .png, pero mi servidor entrega un WebP, y Google lo muestra igualmente. No sé si lo rastreó antes de que pasara o si lo acepta aunque no esté en su lista, así que no lo tomo como regla y me quedo con lo que dice la documentación.

Lo que todavía no he probado es qué pasa si subo un icono en WebP a una web que ya tenga uno bueno, y cuando lo haga actualizaré este artículo con los días que tarda y con lo que sale.

¿Tengo que hacer algo ya mismo?

Si tu icono sale bien en Google no toques nada, que si no está roto mejor no tocarlo.

Si sale el globo gris, o nunca lo has mirado, haz la comprobación de cinco minutos. Si el icono sale en WebP, AVIF o SVG, sube un PNG cuadrado de 512 × 512 píxeles, y si usas Modern Image Formats u otro plugin que convierta imágenes, activa antes la opción del formato original. Luego vacía la caché, pide la indexación de la portada en Search Console y a esperar, que esto va de días o de semanas.

Si te interesa cómo te muestra Google más allá del icono, tienes también cómo conseguir que tus lectores te marquen como fuente preferida en Google.

Y si te ha salido algo raro con tu icono, o ves en Google algo distinto de lo que te cuento, me tienes ahí abajo, en los comentarios. Es un icono de nada, pero es lo que ve la gente antes de entrar en tu web, así que mejor que salga el tuyo y no un globo gris.

Una visita llega a tu web por http, en la calle, Cloudflare la coge del brazo, muy educado, y la manda a la puerta de https, dentro, tu servidor, que no se ha enterado de nada porque Cloudflare le habla por http, la ve entrar por la puerta vieja y la vuelve a sacar a la calle, Cloudflare la recoge otra vez y otra vez la mete por http.

Mientras tanto, un plugin de esos de optimizar WordPress le cambia la dirección escrita en el sombrero, otro de seguridad le pega en la espalda un cartel de «solo por https durante un año», y WordPress, desde el quinto, jura que todo está en orden porque en el wp-config.php pone https.

La pobre visita acaba dando vueltas en esa especie de puerta giratoria, como Charlot, hasta que el navegador se harta y suelta aquello de que la página te ha redirigido demasiadas veces. Cine mudo del bueno, de bastonazo y tarta en la cara, solo que la tarta te la comes tú.

¿Te has liado alguna vez con esto?, pues bienvenido al club.

Entre la CDN, el servidor, el wp-config.php, la base de datos, los plugins y el propio navegador hay seis sitios que pueden decidir si una visita va por http o por https, cada uno actúa en un momento distinto, y a nada que tengas el forzado en dos o tres a la vez empieza la película.

Y lo más gracioso (sic) es que con uno solo tienes de sobra, siempre que sepas cuál. ¡Que empiece la película!

Los síntomas del lío http/s ¿te suena alguno?

Si has llegado hasta aquí buscando algo, seguramente es por uno de estos:

• Marcas «forzar HTTPS» en un plugin y en el .htaccess no cambia nada.
• El navegador te dice que la página te ha redirigido demasiadas veces.
• El candado sale con aviso porque hay contenido mixto (imágenes o scripts que se siguen pidiendo por http).
• La web se queda de repente sin estilos, como recién salida de 1998.
• Desactivas una opción de HTTPS y descubres que te ha devuelto enlaces a http.
• Lo tienes activado en el hosting, en Cloudflare y en dos plugins, y ya no sabes cuál quitar sin romper nada.

Todos tienen la misma raíz: hay varias capas que pueden decidir si una visita va por http o por https, y cada una actúa en un momento distinto. Si no sabes en qué orden, es normal que no entiendas lo que pasa.

El reparto de la película

Pongamos orden, piensa en tu web como un edificio ¿vale?, en la calle hay un portero (la CDN, si usas Cloudflare o similar), en el portal está el conserje (el servidor de tu hosting) y tú vives en el quinto (WordPress). Si el portero ya manda a todo el que llega a la puerta buena, que el conserje y tú lo repitáis no molesta, pero tampoco añade nada, porque a vosotros ya os llega todo el mundo por la puerta correcta.

Y al revés también, lo que hagas en el quinto no lo ve quien se queda en el portal. Toca desentrañar la trama.

La CDN o el proxy: el portero de la calle

Si tu web pasa por Cloudflare (o por cualquier CDN que haga de proxy, un intermediario entre el visitante y tu servidor), lo primero que contesta a una visita es esa CDN, no tu hosting.

Con la opción «Siempre usar HTTPS» activada, Cloudflare manda a https cualquier visita que llegue por http, y lo hace antes de que tu servidor se entere. Esa visita por http no llega nunca a tu hosting, así que todo lo que tengas configurado más abajo para forzar HTTPS se queda sin trabajo.

Ahora bien, aquí está la trampa más habitual, que es el modo de cifrado. Cloudflare te deja elegir cómo habla con tu servidor:

• Flexible: cifra la conexión con el visitante, pero habla con tu servidor por http.
• Completo: cifra las dos conexiones, aunque no comprueba que el certificado de tu servidor sea válido.
• Completo (Estricto): cifra las dos y exige un certificado válido en tu servidor.

Con Flexible pasa exactamente lo de la puerta giratoria del principio. El visitante llega por https a Cloudflare, Cloudflare se lo pasa a tu servidor por http, tu servidor (o WordPress, o un plugin) ve una visita por http y la manda a https, el navegador vuelve a Cloudflare por https, Cloudflare vuelve a pasársela por http… y así hasta que el navegador tira la toalla.

Mi consejo: si tu hosting te da certificado (hoy casi todos lo dan gratis), usa Completo (Estricto) y olvídate del «Flexible».

El servidor: el conserje del portal

La siguiente capa es tu hosting. Aquí el forzado puede estar en el .htaccess (si el servidor es Apache o LiteSpeed), en la configuración de nginx o en una casilla del panel del hosting que lo hace por ti.

La gracia de esta capa es que actúa antes de que se cargue PHP, así que cubre absolutamente todo, ya sean páginas, imágenes, hojas de estilo, scripts y las páginas que tu plugin de caché sirve ya hechas. Es rápido y no depende de que WordPress arranque.

La regla típica en el .htaccess, encima del bloque # BEGIN WordPress, es algo así:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Fíjate en la tercera línea. X-Forwarded-Proto es la cabecera con la que un proxy como Cloudflare le cuenta a tu servidor cómo llegó la visita en origen. Sin esa línea, detrás de un proxy en Flexible, la regla del servidor se suma a la puerta giratoria.

Y ojo con una cosa, porque que no veas la regla en el .htaccess no significa que no exista. Si el forzado está en el panel del hosting o en nginx ahí no lo vas a encontrar.

El wp-config.php: lo que WordPress cree que es

En el wp-config.php hay unas cuantas constantes relacionadas con esto, y conviene saber qué hace cada una por si las dudas:

• WP_HOME y WP_SITEURL: fijan la dirección del sitio y la de WordPress. Mandan sobre lo que haya guardado en la base de datos, y por eso en los ajustes generales esos dos campos salen en gris.
• FORCE_SSL_ADMIN: obliga a usar https en el escritorio y en el acceso. WordPress la activa solo cuando la dirección de WordPress empieza por https, así que, si ya la tienes así, ponerla a mano no cambia nada.
• FORCE_SSL_LOGIN: está obsoleta desde WordPress 4.0 y hoy hace exactamente lo mismo que la anterior. Si tienes las dos, sobra una.

Lo de WP_HOME y WP_SITEURL tiene una cara B que casi nadie cuenta. Como mandan sobre la base de datos, también esconden lo que hay en ella. Si algo te cambia a http las direcciones guardadas, Ajustes > Generales te seguirá enseñando https y no te enterarás. Las constantes protegen la dirección del sitio, no los enlaces de tus entradas.

Y luego está el fragmento que se recomienda cuando hay un proxy delante que no le cuenta a PHP que la visita era segura:

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
	$_SERVER['HTTPS'] = 'on';
}

Hace que WordPress dé la visita por segura cuando el proxy dice que lo era. Funciona, pero esa cabecera la puede mandar cualquiera que llegue a tu servidor saltándose el proxy, así que úsala para esto y para nada más. Con Cloudflare en «Completo (Estricto)» ni siquiera te hace falta.

La base de datos: las direcciones que ya tienes escritas

Una cosa es por dónde llegan las visitas y otra lo que tienes escrito dentro. En la base de datos están las dos direcciones del sitio (las de los ajustes generales de WordPress) y, sobre todo, miles de enlaces dentro de tus contenidos, como imágenes de las entradas, botones, menús, datos de los maquetadores…

Si la web nació en http y la pasaste a https, esos enlaces siguen diciendo http:// hasta que alguien los cambie. Para eso está el buscar y reemplazar, con WP-CLI (wp search-replace) o con un plugin que respete los datos serializados (la forma en que WordPress guarda listas y ajustes, que se rompen si les cambias la longitud a lo bruto con una consulta SQL).

Esto se hace una vez, con copia de seguridad antes, y a otra cosa, no es algo que tenga que estar «activado».

Los plugins de rendimiento y seguridad: esos vecinos metomentodo

Aquí es donde más se mezcla todo, porque bajo la misma etiqueta de «forzar HTTPS» los plugins hacen cosas muy distintas. Cuatro, para ser exactos:

• Redirigir desde PHP. Cuando WordPress arranca, el plugin mira si la visita es por http y la manda a https. Es lo que hace, por ejemplo, Vigilante, y por eso no toca el .htaccess, no le hace falta.
• Reescribir los enlaces al vuelo. Antes de enviar la página, cambia los http:// de tu dominio por https://. Arregla el contenido mixto sin tocar la base de datos, pero lo hace en cada página que sirve.
• Enviar cabeceras al navegador. Sobre todo HSTS y upgrade-insecure-requests, que veremos en el último punto.
• Tocar el .htaccess o la base de datos al activar o desactivar una opción. Ponen la regla del servidor por ti, o cambian las direcciones guardadas.

Lo primero tiene sus límites, y conviene saberlos. Una redirección desde PHP solo cubre lo que llega a WordPress. Una imagen o una hoja de estilos se sirven sin pasar por PHP, y una página que tu plugin de caché ya tiene guardada, muchas veces también.

Además, para saber si la visita es segura, WordPress mira lo que le cuenta el servidor (la función is_ssl()), no la cabecera de Cloudflare. O sea, que una redirección en PHP detrás de Cloudflare en Flexible también se mete en la puerta giratoria, igual que la del servidor sin su tercera línea.

Lo de reescribir al vuelo es un parche, viene de maravilla justo después de migrar, cuando todavía quedan enlaces viejos, pero lo suyo es arreglar la base de datos una vez y quitarlo.

Y lo último, lo de tocar cosas al activar y desactivar, merece apartado propio.

Forzar no es migrar (y dejar de forzar no debería ser desmigrar)

Hay plugins de optimización cuyo «forzar HTTPS» hace bastante más que poner una regla. Al activarlo cambian http:// por https:// en toda la base de datos, y hasta ahí, bien, pero al desactivarlo hacen lo contrario, cambian todos los https:// de tu dominio por http://.

Y si una de las dos cosas sale mal, el chiste se completa. Me llegó un caso hace nada: la regla había desaparecido del .htaccess, el cambio de direcciones no había llegado a hacerse y la casilla seguía marcada, así que el plugin volvía a intentarlo cada vez que alguien iniciaba sesión.

Forzar HTTPS es poner un cartel en la puerta vieja que dice «ahora se entra por la de al lado», ,igrar es cambiar la dirección en tus tarjetas, tus facturas y tu buzón. Un interruptor que, al quitar el cartel, te reimprime todas las tarjetas con la dirección vieja está mezclando dos cosas que no tienen nada que ver. Y la segunda no tiene vuelta atrás limpia, porque también te pasa a http los enlaces que ya estaban en https antes de que activaras nada.

De aquí salen dos lecciones que valen para cualquier plugin. La primera es que una casilla marcada te dice lo que hay guardado, no lo que está pasando, y la segunda que antes de desactivar una opción de HTTPS conviene saber qué hace al desactivarse, no solo al activarse.

El navegador: lo que se queda en casa del visitante

La última capa no está en tu servidor sino en el navegador de cada visitante, y tiene dos protagonistas.

HSTS (HTTP Strict Transport Security) es el cartel de la espalda del principio, una cabecera que le dice al navegador «a esta web, durante tanto tiempo, solo por https». A partir de ahí el navegador ni intenta el http, lo cambia él solo antes de salir de casa.

Es estupendo, pero es un compromiso, porque si un día tu certificado caduca o deja de funcionar, los navegadores que recibieron esa cabecera no dejarán entrar a tus visitantes hasta que pase el plazo, que ni siquiera podrán saltarse el aviso, y desde tu web no lo puedes deshacer. Por eso se empieza con un plazo corto (un día, una semana) y se sube cuando todo va bien.

Con una sola capa que la envíe tienes bastante. Y si la pones en Cloudflare, piénsatelo dos veces antes de quitar Cloudflare, porque el compromiso sigue vivo en los navegadores y a partir de ese momento el certificado que cuenta es el de tu servidor.

El otro protagonista es el contenido mixto, una página en https que pide algo por http. Los navegadores actuales intentan cargar por https las imágenes, el audio y el vídeo, y si no pueden, no los cargan. Los scripts y los iframes que van por http los bloquean directamente.

Para eso existe la directiva upgrade-insecure-requests (va dentro de la CSP, la cabecera de política de seguridad de contenidos), que le pide al navegador que lo pida todo por https, también lo que está en otros dominios.

Es muy útil cuando todo lo que usas existe en https, y un desastre cuando no, porque lo que no tenga https deja de cargarse, por eso Vigilante no la incluye en su CSP mientras la dirección del sitio empiece por http.

Cómo saber quién te está redirigiendo

Vale, pero en tu web, ¿quién está empujando la puerta? Pues no hace falta adivinarlo, te lo dicen las cabeceras de la respuesta. Desde un terminal:

curl -I http://tudominio.com/

Y te fijas en lo que acompaña al 301:

• Aparecen server: cloudflare y un cf-ray: te ha redirigido Cloudflare.
• Aparece X-Redirect-By (casi siempre con el valor WordPress, a veces con el nombre de un plugin): te ha redirigido WordPress, o un plugin, desde PHP.
• Ni lo uno ni lo otro, y en Server pone Apache, nginx o LiteSpeed: lo ha hecho el servidor (el .htaccess, nginx o el panel del hosting).

Si tienes Cloudflare con «Siempre usar HTTPS» siempre verás la primera, y es lo normal, porque el portero no deja pasar a nadie por la puerta vieja.

Si no te apañas con el terminal, el navegador te da lo mismo. Abre las herramientas de desarrollo, ve a la pestaña Red, marca «Conservar registro» (para que no se borre al redirigir), carga la dirección con http y mira las cabeceras de la primera petición.

Y fíjate en que esto mide lo que llega, no lo que tienes marcado. Lo que cuenta es la respuesta de tu web, no la casilla del plugin.

Qué dejar activado según tu caso (con una basta)

Que sí, que tenerlo en tres sitios a la vez no suele romper nada, siempre que ninguno se meta en la puerta giratoria. Pero tampoco añade seguridad, porque la primera capa que redirige se lleva la visita y las demás se quedan mirando. Mi consejo, el mismo que doy cuando me lo preguntan en los foros, es forzarlo cuanto antes y en un solo sitio.

Si tienes Cloudflare (o una CDN parecida) delante

• Modo Completo (Estricto) y «Siempre usar HTTPS» activado.
• En el servidor, la regla con su línea de X-Forwarded-Proto solo si quieres un respaldo para quien llegue directo a tu hosting.
• En los plugins, nada más. Como mucho, la redirección en PHP como red de seguridad.

Si no tienes CDN pero tu hosting lo ofrece

• Actívalo en el panel del hosting o con la regla del .htaccess.
• La redirección en PHP de tu plugin sobra, aunque puedes dejarla de respaldo porque no molesta.

Si no tienes ni CDN ni opción en el hosting

• Pon tú la regla en el .htaccess, si tu servidor es Apache o LiteSpeed.
• Si no puedes tocarlo, la redirección en PHP de un plugin cumple, sabiendo que no cubre ficheros estáticos ni páginas en caché.

En todos los casos

1. Las dos direcciones de «Ajustes > Generales» (o las constantes del wp-config.php) en https.
2. Un buscar y reemplazar en la base de datos, una sola vez, con copia antes.
3. HSTS lo último, cuando todo lo demás funciona, y con un plazo corto al principio.
4. Un ojo puesto en la renovación del certificado, sobre todo si has activado HSTS.

¿Y Vigilante qué pinta en todo esto?

Pues sí, también podría estar liándola, así que te cuento cómo lo hace Vigilante. Su sección HTTPS, en la pestaña de cabeceras, empieza diciendo que no te va a imponer HTTPS, sus cuatro opciones vienen desactivadas por defecto.

• Redirigir de HTTP a HTTPS. Desde PHP, sin tocar el .htaccess. Solo actúa si la dirección del sitio ya empieza por https, así que no te puede dejar fuera de tu propia web. No cubre ficheros estáticos ni páginas en caché, y detrás de Cloudflare necesita el modo Full o Full (strict), como cualquier redirección en PHP.
• Corregir contenido mixto. Reescribe al vuelo los enlaces http de tu propio dominio, y solo cuando la visita ya va por https. No toca recursos de otros dominios, así que no te los puede romper.
• Actualizar las solicitudes inseguras. Es la directiva upgrade-insecure-requests, separada a propósito porque afecta también a recursos de otros sitios. Actívala cuando sepas que todo lo que usas existe en https.
• Cambiar dirección del sitio al activarse. Pasa a https las dos direcciones de Ajustes > Generales al activar el plugin, y solo si el sitio contesta por https. No toca los enlaces de tus contenidos, y desactivar Vigilante no lo deshace, o sea, que al desactivarlo no te devuelve a http.

HSTS va aparte, en su propia sección, y no te deja activarlo mientras la dirección del sitio empiece por http.

Por cierto, Vigilante envía sus cabeceras desde el .htaccess, y no todos los servidores las aplican. Por eso su análisis de seguridad no puntúa lo que tienes marcado sino lo que de verdad le llega al navegador, y si una cabecera activada no llega, te lo dice.

Moraleja

El HTTPS dejó de ser opcional hace años, y forzarlo es de lo más sencillo que puedes hacer por tu web. Lo complicado no es activarlo, es que cada capa te ofrece su propia casilla y nadie te explica que solo necesitas una.

Así que asegúrate de tener solo una puerta, un portero, las direcciones bien escritas en la base de datos y HSTS cuando estés seguro. El resto, como mucho, de respaldo.

Ahora te toca a ti. Si tienes el forzado repartido en tres sitios, ya sabes cómo averiguar cuál trabaja y cuáles sobran. Y si alguna vez ves a una visita dando vueltas en la puerta giratoria, ya sabes por dónde empezar a mirar. Para todo lo demás, me tienes ahí abajo, en la sección de comentarios.

Así que, por si tenías aún alguna duda, la oferta de Navidad, tal y como la plantean la mayoría de las tiendas, o baja del precio de Black Friday o no se puede anunciar como rebaja.

Y te lo digo con conocimiento de causa, porque en diciembre de 2025 publiqué aquí mismo un ejemplo para programar cuatro ofertas seguidas en WooCommerce y, tal y como las anunciaba, tres de las cuatro no cumplían la regla de los 30 días (sí, lo he dicho yo).

Así que vamos a verlo pasito a pasito, con un calendario de verdad y con números, que el Black Friday es el 27 de noviembre y es ahora cuando estás decidiendo cómo encadenas tus ofertas.

¿Cómo se tienen que mostrar las ofertas? … legalmente

La norma viene de la Directiva (UE) 2019/2161, la famosa Ómnibus, que añadió el artículo 6 bis a la Directiva 98/6/CE, y en España está en el artículo 20.1 de la Ley de Ordenación del Comercio Minorista desde mayo de 2022. Te lo conté con detalle en el artículo sobre la directiva Ómnibus en WooCommerce, así que aquí vamos al grano:

Cuando anuncias una rebaja tienes que indicar el precio anterior, y el precio anterior es el más bajo que aplicaste a ese producto en los 30 días previos a la rebaja.

Fíjate en que no dice «tu precio habitual», dice el más bajo de esos 30 días, sea por el motivo que sea. Y lo que mucha gente no tiene claro es qué cuenta como «anunciar una rebaja», pues casi todo lo que tu tienda pone alrededor del precio:

• El precio tachado, que es el anuncio de rebaja por excelencia.
• La etiqueta de «¡Oferta!» que WooCommerce y tu tema ponen sobre la foto.
• El porcentaje, tipo «-30 %», en la etiqueta o en el texto.
• Los banners y los textos de campaña, del estilo de «Black Friday: hasta un 50 % de descuento».

Lo del porcentaje no es una interpretación mía. El 26 de septiembre de 2024 el Tribunal de Justicia de la UE resolvió el asunto C-330/23, el de Aldi en Alemania, y dejó claro que un descuento anunciado en porcentaje o con un mensaje promocional se calcula sobre el precio anterior, no sobre el precio que a ti te parezca más bonito.

Precios encadenados, la película

Vamos con un caso sencillito, vender una camiseta a 29,99 € y planificamos tres campañas:

• Black Friday, del 27 al 30 de noviembre, a 19,99 €.
• Navidad, del 18 al 26 de diciembre, con un 30 % de descuento, o sea, a 20,99 €.
• Rebajas de enero, del 7 al 20 de enero, con 12 € menos, a 17,99 €.

Tiene toda la lógica comercial del mundo, ¿verdad? Pues mira lo que pasa cuando le aplicas la regla de los 30 días a cada una:

Ahí lo tienes, Navidad no se puede anunciar como rebaja, porque dentro de sus 30 días está el Black Friday a 19,99 €, y tu «30 % de descuento» en realidad es una subida de un euro. Y las rebajas de enero sí son rebaja, pero de un 14 %, porque la referencia ya no son los 29,99 € de siempre, es el precio de Navidad.

Ojo, que puedes vender la camiseta a 20,99 € en Navidad, faltaría más, lo que no puedes es tacharle los 29,99 € al lado ni ponerle la etiqueta de «-30 %».

¿Y mi precio habitual?

Pues cuando el precio más bajo sale de la franja de ofertas, ni un día antes. El Black Friday termina el 30 de noviembre, así que hasta el 31 de diciembre los 19,99 € siguen dentro de los 30 días de cualquier oferta nueva. Una Navidad anunciada contra los 29,99 € de siempre tendría que empezar el 31 de diciembre… y para entonces ya no es Navidad, es Nochevieja.

Con las rebajas de enero pasa lo mismo, pero con el precio de Navidad, si empiezan antes del 26 de enero, la referencia son los 20,99 €.

Cómo hacer bien una programación de ofertas de precio

1. Que cada rebaja baje de la anterior: Si en Navidad la dejas a 17,99 € sí puedes anunciarla, eso sí, «antes 19,99 €» y con un 10 % menos, no un 40 %.
2. Vender sin anunciar rebaja: La pones a 20,99 €, sin tachado, sin etiqueta de oferta y sin porcentaje. Es un precio, no una rebaja, y no tienes nada que justificar.
3. Separar las campañas más de 30 días: Es la única forma de que tu precio normal vuelva a ser la referencia y normalmente entre noviembre y enero no da.

Hay una cuarta que sale mucho en foros, la de las rebajas progresivas (bajar el precio por escalones dentro de una misma campaña sin que suba en ningún momento). La directiva deja que cada país mantenga como referencia el precio de antes de toda la campaña, pero como ya te conté, no he encontrado que España lo haya transpuesto de forma explícita, así que mi consejo sigue siendo el mismo: aplica siempre la regla de los 30 días y no te fíes del atajo.

WooCommerce ni te va a avisar (ni se le espera)

WooCommerce tacha siempre el precio habitual, el que pones en «Precio normal», sin mirar qué pasó antes. No sabe nada de la directiva Ómnibus, ni de tus campañas anteriores, ni de los 30 días. Si programas la Navidad a 20,99 € con el precio rebajado de toda la vida, te pinta un precioso 29,99 € tachado y tú a pagar multas.

Así que tienes dos caminos:

• A mano, con una hoja de cálculo con tus campañas, sus fechas y el precio anterior de cada una, revisada antes de programar nada. Funciona, pero con un catálogo grande es una tortura.
• Con un plugin que guarde el historial de precios, como los que te recomendé en el artículo de la directiva Ómnibus, que guardan el precio más bajo y lo muestran en la ficha. Cumplen, pero solo saben lo que ya ha pasado, así que te enteras del problema de la Navidad cuando ya está publicada.

Y para eso tienes el plugin Ofertas programadas, descuentos e historial de precios Omnibus para WooCommerce (mío, gratis como todos), que programa las ofertas y, como sabe qué precios vienen, te avisa en el editor del producto de que la Navidad no baja del Black Friday cuando todavía estás a tiempo de cambiarla.

En la tienda tacha el precio anterior en lugar del normal, y si una oferta no es rebaja la enseña como un precio más, sin tachado ni etiqueta.

Con la camiseta del ejemplo, para que te hagas una idea de lo que ves:

• En el editor del producto, debajo de la oferta de Navidad te sale un aviso: 20,99 € no baja de 19,99 €, el precio más bajo de los 30 días anteriores, así que no se puede anunciar como rebaja. Y debajo de la de enero, una línea que te dice que su precio anterior será 20,99 €, no 29,99 €.
• Mientras creas una oferta nueva, según pones la fecha de inicio y el precio te dice cuál será su precio anterior, antes de guardar nada.

• En la tienda durante el Black Friday ves lo de siempre, 29,99 € tachado y 19,99 €, porque ahí el precio normal sí es la referencia.
• En Navidad la camiseta sale a 20,99 € sin tachar y sin la etiqueta de oferta, porque no es una rebaja.
• En enero sale tachado 20,99 € al lado de los 17,99 €, con una nota debajo que indica el precio anterior.

Si usas productos variables con el plugin con el que mostrar solo los precios más bajos en productos variables de WooCommerce para mostrar el «Desde», ese precio también sigue la misma regla, porque los dos plugins se comunican entre sí, son hermanitos (hijos del mismo padre, un servidor).

Lo que tienes que revisar antes del 27 de noviembre (de 2026, o sea ya)

Si ya te has aclarado, apunta:

1. Apunta tus campañas de aquí a enero, con sus fechas y sus precios.
2. Para cada una mira el precio más bajo de los 30 días anteriores a su inicio. Ese es su precio anterior.
3. Si la oferta no baja de ese precio, no la anuncies como rebaja o bájala un poco más.
4. Calcula los porcentajes contra el precio anterior, no contra el precio normal, y revisa las etiquetas «-X %» de tu tema (si usas Divi, tengo un código para mostrar el porcentaje que ya lo calcula bien).
5. Revisa los banners y los textos de campaña, porque «hasta un 50 %» también es anunciar una rebaja.
6. Guarda el historial de precios por si alguien te lo pide. No he encontrado un plazo legal para conservarlo, pero las reclamaciones llegan después de la campaña, no durante.

No te voy a decir que planificar así sea cómodo, porque no lo es, pero es mucho más barato revisar el calendario ahora que explicar en febrero por qué tu Navidad estaba «rebajada». Las multas, como te conté en el artículo de la directiva Ómnibus, no son de broma.

Ahora te toca a ti decidir cómo montas tu temporada. Si tienes dudas con un caso concreto me tienes ahí abajo, en los comentarios. Y ya estás corriendo, que el viernes negro está a la vuelta de la esquina.

A estos parches se les conoce como PHP2Shell (CVE-2026-109618 y CVE-2026-109619, con una puntuación de 9,2 sobre 10 según el aviso oficial de PHP) y lo que los hace especiales para quienes usamos WordPress es que el fallo no está en WordPress ni en tus plugins, sino en el propio PHP.

Y no, no tiene nada que ver con wp2shell, el fallo de julio que sí estaba en el núcleo de WordPress. Te cuento…

Mira qué versión de PHP tienes

Entra en «Herramientas > Salud del sitio», abre la pestaña «Información» y despliega la sección «Servidor», ahí aparece la versión de PHP con la que funciona tu web.

Estas son las versiones que ya llevan la corrección:

• PHP 8.5: la 8.5.12 o posterior.
• PHP 8.4: la 8.4.27 o posterior.
• PHP 8.3: la 8.3.36 o posterior.
• PHP 8.2: la 8.2.35 o posterior (esta rama deja de recibir soporte el 31 de diciembre de 2026).

Si tu número es inferior, no saques conclusiones todavía, porque hay empresas de hosting que corrigen el fallo sin cambiarlo.

Las distribuciones de Linux como Debian o Ubuntu aplican el parche sobre la versión que ya llevaban y solo suben la revisión del paquete, así que el número que ves en la ventana de salud del sitio no demuestra por sí solo que estés protegido ni que no lo estés. La única forma segura de saberlo es preguntárselo a tu hosting.

Con PHP 8.1 o anterior la cosa se complica, porque el proyecto PHP no publica una versión oficial con el parche (solo ha dejado parches mínimos de código fuente para 7.4, 8.0 y 8.1, pensados para quien compila a mano). Dependes de que tu hosting aplique los parches retroportados de su proveedor y, si no te lo confirma, lo prudente es cambiar a una rama con soporte.

Si prefieres que lo compare WordPress por ti, he preparado un plugin gratuito y muy pequeño, WordPress PHP2Shell Check. Añade una prueba a la pantalla de salud del sitio que coteja la versión de PHP con la que está funcionando tu web con las que llevan la corrección, y solo lee, no envía nada fuera, no guarda nada y no tiene ajustes.

Si tu versión es inferior no te dice que estés en peligro, porque ya has visto que no se puede saber desde dentro, sino que te lo explica y te da el mensaje para tu hosting con tu versión ya puesta. Ni detecta ataques ni sustituye a preguntarle a tu hosting.

Qué puedes hacer tú y qué solo puede hacer tu hosting

Lo que sí está en tu mano es cambiar la versión de PHP desde el panel de tu hosting, si te deja, y comprobar después en la pantalla de salud del sitio que el cambio se ha aplicado. Y ojo, que elegir una rama en el panel no garantiza que ya lleve el parche, porque eso depende de que tu hosting la haya actualizado.

Lo demás no depende de ti. Las medidas de PHP para quien no puede actualizar se aplican en el php.ini o en la configuración del servidor, y para la del progreso de subida el propio PHP avisa de que ni ini_set() ni un archivo .user.ini sirven porque llegan tarde. En un hosting compartido eso solo lo puede tocar soporte, así que escríbeles algo como esto:

Hola, ¿habéis aplicado ya en vuestros servidores los parches de PHP para CVE-2026-109618 y CVE-2026-109619 (PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 o su equivalente retroportado)? ¿Podéis confirmarme qué versión o paquete usa mi sitio y si se han reiniciado los procesos de PHP después de actualizar?

Si el servidor es tuyo y no puedes actualizar todavía, contra el segundo fallo PHP recomienda desactivar el seguimiento del progreso de subida de sesiones y reiniciar todos los procesos de PHP:

; php.ini
session.upload_progress.enabled = 0

; pool de PHP-FPM
php_admin_value[session.upload_progress.enabled] = 0

Eso reduce la exposición, pero no hace segura la instalación, así que no sustituye a actualizar. En el aviso oficial tienes también las medidas contra el primer fallo, que tienen que ver con límites de memoria y de tamaño de las peticiones.

Escáneres de GitHub: no los lances contra tu web

Si buscas «php2shell» en GitHub vas a encontrar una docena de «escáneres», casi todos de los últimos días y con muy pocas estrellas. No lances ninguno contra tu web.

Los que miran la versión desde fuera no ven nada si el hosting oculta la cabecera o corrige el fallo sin cambiar el número, y los que sondean de verdad intentan provocar el error de memoria en un servidor que no controlas (los autores de uno de ellos admiten que es arriesgado, y otro escribe datos en las sesiones del servidor que escanea).

A eso súmale que ejecutar código ajeno recién publicado, sin apenas revisión externa y en plena fiebre por un fallo crítico, ya es mala idea por sí solo, ¿o no hemos aprendido nada últimamente?.

Tu comprobación sigue siendo la herramienta de salud del sitio de WordPress, y la pregunta a tu hosting. Y si administras tu propio servidor, mira directamente la versión del paquete instalado y la configuración de PHP, que es más fiable que cualquier sonda desde fuera.

Por qué ningún plugin te protege de esto

Un plugin de seguridad es código PHP que se ejecuta dentro de PHP, así que pedirle que arregle un fallo del propio PHP es como poco contradictorio, y te lo digo yo, que hago plugins de seguridad.

Además, en Apache con mod_php el ataque puede dispararse antes de que se ejecute una sola línea de código de WordPress, según el propio aviso de PHP. Lo que arregla esto es actualizar PHP, no instalar nada.

Y hay un tercer fallo todavía sin parche

El 23 de octubre PHP publicó un aviso informativo sobre otro, el CVE-2026-115560, que describe como una posible ejecución remota de código poco probable. Para que se dé, la aplicación tiene que cambiar en tiempo de ejecución el manejador con el que PHP serializa las sesiones y, además, seguir activo el seguimiento del progreso de subida.

A fecha de hoy no hay versión corregida y la medida es la misma de antes, desactivar session.upload_progress.enabled si tu hosting puede. Que dependa del código de cada aplicación lo hace menos probable, no inexistente, así que conviene aplicar la medida si está a tu alcance y estar atento a la próxima versión de PHP que lo corrija.

Cuánto hay que preocuparse de verdad

Que nadie lea esto como un «no pasa nada», porque es un fallo serio, con ejecución remota de código y sin iniciar sesión. Pero los parches existen desde el 21 de octubre y lo razonable es mirar la versión hoy y escribir a tu hosting, no entrar en pánico.

En cuanto a los ataques reales, watchTowr dice haberlos visto en sus sistemas trampa desde el 21 de octubre y Cloudflare asegura, según BleepingComputer, que ya notaba ataques antes de los parches, pero ninguna de las dos aporta datos que se puedan comprobar y el equipo de PHP no lo confirma.

El Centro Canadiense de Ciberseguridad tampoco ha identificado explotación activa por el momento, aunque avisa de que eso puede cambiar rápido. Y sobre todo desconfía de los titulares que cifran en porcentajes enormes los sitios en peligro, porque el que PHP esté en muchísimos sitios no significa que todos estén sin parche.

Si sospechas que se te han colado

Actualiza PHP y revisa después lo que recomienda el aviso canadiense, que son los registros del servidor web y cualquier proceso, archivo, cuenta o conexión saliente inusual. En WordPress eso se traduce en buscar usuarios administradores que no reconoces, archivos PHP nuevos en wp-content/uploads y cambios en wp-config.php o en .htaccess.

Para esa búsqueda te puede ayudar Vigilante, mi plugin de seguridad gratuito, que compara el núcleo, los plugins y los temas con las copias oficiales, busca PHP en la carpeta de subidas, vigila wp-config.php y .htaccess y guarda un registro de actividad con los cambios en cuentas de usuario.

Además, hace nada incluí la comprobación de tu versión de PHP frente a las conocidas como vulnerables, para que te sea más fácil, o por si no quieres instalar el mini plugin que te he comentado antes, lo que prefieras.

También revisa el estado de fin de vida útil de tu versión de PHP, aunque que una rama tenga soporte no significa que ya lleve el parche de estos fallos. Eso sí, sirve para buscar rastros después, no para evitar el fallo, que como ya sabes se arregla actualizando PHP.

Mira tu versión hoy y escribe a tu hosting, que es lo que de verdad está en tu mano. Si te contesta algo raro (o no te contesta), me tienes ahí abajo, en la sección de comentarios. Y si quieres repasar lo básico de seguridad, tienes montones de artículos y guías sobre seguridad WordPress.

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 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 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 sus experimentos «may change significantly or be removed in any release», o sea, que pueden cambiar mucho o desaparecer en cualquier versión, y recomienda probarlos 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 de Performance Lab dice «Performance plugin from the WordPress Performance Team» (que suena más a garantía que a aviso), y las de Speculative Loading o Modern Image Formats no dan ninguna pista. Gutenberg se presenta como «development plugin», Optimization Detective, Image Prioritizer y Embed Optimizer llevan un «-beta» en el número de versión y, desde la versión 1.5.0, el plugin AI avisa en la suya de que sus experimentos pueden cambiar o desaparecer.
    • Dentro del propio plugin: en los de rendimiento, quitando el «(experimental)» de View Transitions en la pantalla de Performance Lab, no hay nada que te avise. El plugin AI ha empezado a hacerlo en su versión 1.5.0, y más abajo te cuento cómo.

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.

En la versión 1.5.0 del plugin AI hay un caso curioso. El experimento MCP Access, al activarlo, te instala y activa otro plugin experimental, MCP Adapter, directamente desde WordPress.org, y deja que los agentes de IA autorizados usen por defecto las funciones del plugin que tengas activas. Lo dice en su descripción, eso sí, pero es un experimento que te instala otro experimento.

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.

Lo de las versiones mayores, eso sí, es más una intención que una norma. La 1.5.0, que es una versión menor, ha cambiado de forma incompatible tres de las abilities del plugin (las acciones que deja usar a otras herramientas de IA) y ha dejado de servir la dirección /feed/markdown/ de cada entrada, que ahora da un error 404. Lo explican en el registro de cambios, y lo justifican porque tenían que igualarse con lo que llega al núcleo, pero el registro de cambios es otra de esas cosas que no lee nadie.

Un ejemplo reciente. 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

Hasta la versión 1.4.0 del plugin AI, cada función que no habías activado nunca costaba una consulta a la base de datos en cada visita, también en la parte pública, en webs sin caché de objetos persistente (tipo Redis o Memcached). Lo he medido en una instalación de pruebas con WordPress 7.1.3, sin caché de objetos y sin ningún experimento activado: sin el plugin, cada carga hacía 8 consultas; con la 1.4.0, 38.

En la 1.5.0 lo han arreglado, y bien, porque se quedan en 9. Aun así, es un buen ejemplo de que tener un experimento activo sin usarlo no sale gratis, y de paso te deja dos widgets en el escritorio.

Y ojo, porque hasta la 1.4.0 su propia FAQ aseguraba que sus funciones «require manual triggering – nothing happens automatically without your approval», o sea, que solo se ponían en marcha si tú lo pedías. 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 viaja a tu proveedor de IA y puede costarte tokens.

Todo hay que decirlo, a raíz de la incidencia que abrí lo corrigieron en la 1.5.0, y la FAQ avisa ahora de que esa moderación hace una petición por cada comentario nuevo, incluido el spam que se le escape a tu antispam.

Todo hay que decirlo, a raíz de la incidencia que abrí lo han corregido para la versión 1.5.0, que mientras escribo esto todavía no ha salido: la FAQ avisa de que esa moderación hace una petición por cada comentario nuevo, y en los ajustes los experimentos que se ejecutan solos llevan su propia etiqueta.

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.

Y el propio equipo de rendimiento lo hizo bien con Fetchpriority: en cuanto su función entró en WordPress 6.3, el plugin mostraba un aviso pidiendo que lo desactivaras, y en junio de 2024 lo cerraron.

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 hoy 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 que ú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. Que lo digan el nombre y la descripción del plugin: «(beta)» en el nombre y, en la descripción de la lista de plugins y en la del directorio, qué añade a lo que ya trae WordPress. Sin avisos en el escritorio, que de esos ya vamos sobrados, y a la vista de todo el mundo, también antes de instalarlo.
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 además pedía que cada experimento dijera si se ejecuta solo, qué envía al proveedor de IA y cuántas peticiones hace.

El equipo del plugin AI se lo tomó en serio y en dos semanas estaba hecho. En la versión 1.5.0, que salió el 29 de octubre, la descripción de la lista de plugins ya avisa de lo que es, los experimentos que se ejecutan solos llevan una etiqueta en los ajustes y cada uno tiene un icono que te cuenta cuándo se ejecuta, qué envía y cuántas peticiones hace. Y sin meter ni uno de esos avisos que salen arriba en todas las pantallas.

En el equipo de rendimiento la cosa va más despacio. Están abiertos a dejar más claro qué aporta cada plugin además de lo que ya trae WordPress, a uno de sus miembros no le convencen los avisos en el escritorio (y razón no le falta, que hay demasiados) y está sobre la mesa añadir «(beta)» al nombre de los plugins.

Si estás de acuerdo, pásate por la incidencia 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 o poder cambiar la configuración desde Ajustes > Lectura (WordPress no trae esos ajustes), 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: actualízalo a la 1.5.0, que además corrige dos vulnerabilidades de gravedad media que solo puede aprovechar alguien con cuenta en tu web y rol de colaborador o superior. Y si lo usas en producción, revisa qué experimentos tienes activos en «Ajustes > IA» y fíjate en los que se ejecutan solos.
  • 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 ejemplo:

add_filter( 'ayudawp_test_plugins', function ( $plugins ) {
	$plugins['carpeta-del-plugin'] = array();
	return $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. Con el plugin AI ya ha empezado a pasar.

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.