En agosto en la playa, en Navidad entre turrones, en ese puente que llevas esperando desde marzo, o un martes cualquiera si eres freelance y lo llevas todo tú solo, tu WordPress sigue ahí, abierto al mundo, recibiendo visitas de personas y de bots a partes iguales (y estoy siendo generoso con las personas).

Los ataques a WordPress son automáticos en su inmensa mayoría, scripts que escanean millones de webs buscando la misma vulnerabilidad conocida, sin descanso, sin vacaciones y sin cogerse el puente de diciembre, así que la defensa también puede, y debe, ser automática.

Y esa es la buena noticia que vengo a contarte, que la seguridad de un WordPress no necesita que estés delante, necesita que la dejes bien montada.

Copias que se hacen y se comprueban solas, actualizaciones con red de seguridad, vigilancia que escanea sin que se lo pidas y alertas que solo te escriben cuando pasa algo de verdad, a eso es a lo que le llamo yo poner la seguridad en piloto automático.

Y ojo, que esto no va solo de vacaciones, va de cualquier web desatendida, y desatendida es toda web cuyo dueño tiene una vida, un trabajo, clientes o las tres cosas a la vez.

Si eres autónomo y no tienes a nadie detrás revisando registros de actividad (nadie revisa registros a diario, tranquilo, ni yo), este artículo es para ti los 365 días del año, no solo cuando haces la maleta.

Vamos a verlo de a poquito, en modo fácil, que ya sabes que soy cortito y explico las cosas como si fuesen para mi. Al final, por si no te apetece leer (ni aprender, tú verás) te dejo la lista de comprobación completa, la de cerrar la casa antes de irte de viaje.

Qué puedes automatizar, qué puedes delegar y qué te toca a ti

Cada tarea de seguridad de esta guía acaba en uno de tres sitios. O la haces tú una sola vez y se queda hecha, o la hace una máquina por ti cada día, o la hace otra persona por ti. Lo que no puede ser es que la seguridad de tu web dependa de que tú te acuerdes, porque no te vas a acordar, yo tampoco, y me dedico a esto.

¿Y quién es esa otra persona en la que delegar?

Pues según el caso, tu hosting, que si lo eliges bien hace bastante más de lo que crees, un buen plugin de seguridad bien configurado, o directamente un servicio de mantenimiento profesional como el que ofrecemos en mantenimiento.ayudawp.com, que viene a ser el vecino de confianza al que le dejas una copia de las llaves, solo que este sabe de WordPress y no tienes que traerle imanes de nevera a la vuelta.

Para que no te pierdas, cada sección termina con dos líneas, lo que se automatiza y lo que se puede delegar, y en quién. Empezamos por donde hay que empezar siempre.

Lo primero, siempre: copias de seguridad automáticas

Antes de tocar un solo ajuste, antes de actualizar nada, antes incluso de seguir leyendo, asegúrate de esto, porque la copia de seguridad es el paso previo de cualquier cambio y la última red cuando todo lo demás falla.

Si el cortafuegos no para el ataque, si una actualización rompe la web, si borras lo que no debías, un backup es lo que te devuelve el negocio a su sitio.

La regla de oro se llama 3-2-1, tres copias de tus datos, en dos soportes distintos y al menos una fuera del servidor de tu web, porque si tu única copia vive en el mismo servidor que la web y el servidor revienta, te quedas sin web y sin copia a la vez, bonito plan.

Sobre todo es importante que la copia sea completa, con todos los archivos imprescindibles y la base de datos, que he visto más de una «copia» que solo guardaba los archivos y dejaba fuera la base de datos, donde viven tus entradas, tus pedidos y tus usuarios, o sea, todo lo que importa, todo eso que no puedes descargar ni encargárselo a una IA.

Cómo se automatizan las copias de seguridad fácil y (casi) gratis:

1. Las copias diarias de tu hosting, que los buenos las hacen sin que se lo pidas y te dejan además lanzar copias adicionales a mano antes de un cambio gordo.
2. Al menos otra copia externa programada con un plugin de backups hacia otro sitio, tu Google Drive, un Dropbox, un almacenamiento S3, donde quieras, pero fuera del servidor.

Con esas dos patas la ejecución queda resuelta sin que muevas un dedo, y la frecuencia la marca tu web, semanal para una web que apenas cambia, diaria como mínimo para un blog activo. En una tienda con pedidos entrando piénsate incluso algo más frecuente para la base de datos, que cada hora de diferencia son pedidos que podrías perder en una restauración.

Lo único que no se automatiza del todo es comprobar que la copia sirve de algo si la necesitases. Un backup que nunca has probado si se restaura bien es una promesa, pero aún no sabes si es una copia de seguridad.

Antes de relajarte restaura una en un entorno de pruebas o en local, cronométralo y apunta los pasos, porque cuando la necesites de verdad no querrás estar aprendiendo a restaurar con la web caída y el móvil al 12% de batería.

Tengo publicada una guía completa de copias de seguridad en WordPress con métodos y herramientas para cada caso, así que aquí no me extiendo más.

• En piloto automático: las copias diarias del hosting y una copia externa programada fuera del servidor.
• Delegable: en tu hosting la ejecución diaria, y en un servicio de mantenimiento que además verifique las copias y haga restauraciones de prueba de vez en cuando.

Accesos: menos llaves repartidas y mejores cerraduras

Piensa en cuánta gente tiene llaves de tu casa y desde cuándo, pues con tu WordPress pasa igual, pero peor, porque las llaves digitales no caducan solas. Ahí siguen el usuario del diseñador que pasó por la web en 2019, el de aquella agencia que probaste tres meses y el admin2 que ya ni recuerdas quién creó.

Cada usuario es una puerta abierta, y cada puerta con privilegios de administrador es una puerta blindada con la llave puesta por dentro si la contraseña es mala. La limpieza es manual pero de una sola vez.

Entra en la pantalla de gestión de usuarios de tu WordPress, borra los que no reconozcas o no se usen (WordPress te preguntará a quién reasignar sus contenidos, así que no pierdes nada) y baja privilegios a todo el que no necesite ser administrador, que un editor publica y edita perfectamente sin poder instalar plugins ni tocar ajustes.

El resto sí se queda funcionando en automático, a saber:

• Contraseñas únicas y largas guardadas en un gestor de contraseñas
• Identificación en dos pasos activada y a poder ser forzada para todos los que acceden (el famoso 2FA, ese código del móvil que hace que aunque te roben la contraseña no puedan entrar sin tu teléfono)
• Protección contra fuerza bruta que bloquee sola las IPs que prueban contraseñas en cadena.

Todo eso lo hace gratis cualquier plugin de seguridad serio, y una vez configurado no vuelve a pedirte nada.

Y ya que estás con la limpieza, aplícala también al código. Los plugins desactivados y los temas antiguos que guardas «por si acaso» siguen siendo archivos presentes en tu servidor, y algunos agujeros se explotan aunque el plugin esté desactivado.

Menos código instalado es menos superficie de ataque, así que borra lo que no uses y deja un solo tema de reserva de los oficiales, por si toca descartar problemas algún día.

• En piloto automático: el bloqueo de fuerza bruta, el 2FA forzado y las políticas de contraseñas.
• Delegable: la auditoría de usuarios, permisos y plugins sobrantes, que es de lo primero que se revisa en cualquier puesta a punto profesional.

Ajustes de una sola vez que trabajan para siempre

Hay una parte de la seguridad WordPress que es puro «configurar y olvidarte», el famoso hardening (refuerzo, vaya), y es la más agradecida para una web desatendida porque no genera avisos, ni mantenimiento, ni nada, lo activas y ya está.

Lo esencial cabe en cuatro acciones:

1. Desactivar la edición de archivos desde el escritorio de WordPress, para que si alguien entra con una cuenta robada no pueda reescribirte el tema desde dentro, que es una línea en wp-config.php y listo.
2. Cerrar xmlrpc.php si no lo usas, un protocolo de acceso remoto de otra época que hoy casi nadie necesita y que los bots adoran.
3. Añadir cabeceras de seguridad, unas instrucciones que tu servidor manda al navegador para evitar cosas feas, como que otra web meta la tuya en un marco invisible para robarle los clics a tus visitantes.
4. Proteger de miradas ajenas los archivos sensibles de la instalación.

¿Quieres hacerlo a mano y gratis? En las herramientas gratuitas para WordPress tienes generadores de wp-config.php, de .htaccess y de cabeceras de seguridad que te montan el código marcando opciones, copiar, pegar y hasta luego maricarmen.

¿Prefieres que lo haga un plugin? Pues aquí presento al que va a salir varias veces en lo que queda de artículo, Vigilante, ese pedazo de plugin de seguridad, gratuito del todo y sin versión de pago, que aplica todo este refuerzo de manera sencilla y casi por defecto.

Y con un detalle especialmente importante para el que va a dejar la web sola, y es que antes de tocar wp-config.php, .htaccess o robots.txt el plugin hace copia de los archivos originales con verificación de integridad, y si un día lo desactivas lo restaura todo como estaba.

Más majo él, hasta cuando tú decides no darle el cariño que merece te cuida, y luego tú criticando.

Cualquier plugin de seguridad serio bien configurado te cubre buena parte de esta guía, y tienes una comparativa función a función de los plugins de seguridad más conocidos por si quieres elegir con datos, casi sin opiniones.

• En piloto automático: todo, esa es la gracia. Se configura una vez y las reglas se mantienen solas.
• Delegable: en un profesional para una puesta a punto única, un par de horas de trabajo que se quedan hechas para siempre.

Actualizaciones automáticas, sí, no te quejes, que es gratis

Aquí llega el debate más bobo del mundo WordPress, entre el «actualiza siempre al momento» y el «si no está roto no lo toques». Ambps dos bandos tienen (algo de) razón, pero ninguno la tiene del todo.

Lo que WordPress trae de serie

Desde la versión 3.7, allá por 2013, seguro que ni te acuerdas, WordPress se actualiza solo en las versiones menores, las de seguridad y mantenimiento, y eso déjalo como está, que ha salvado muchas más webs de las que ha roto.

Y desde la versiób 5.5 puedes activar además actualizaciones automáticas por cada plugin y cada tema desde el propio escritorio, con su enlace al lado de cada uno en el listado.

El problema de la vía nativa es que actualiza a pelo, sin copia previa, sin comprobar después si la web sigue viva, sin marcha atrás si algo peta. De este modo, si un plugin rompe tu web un sábado a las tres de la madrugada, te enteras el lunes por un cliente, o no te enteras, que es peor.

Los pros y los contras

A favor de automatizar hay un dato que lo aplasta casi todo, y es que la inmensa mayoría de los hackeos de WordPress explotan vulnerabilidades conocidas que ya tenían arreglo publicado.

Nada de hazañas de película ni ataques dirigidos a tu web en concreto, sino puertas que llevaban semanas con el parche disponible sin que nadie lo aplicara. Una web sin actualizar durante un mes de vacaciones es exactamente eso, un escaparate de puertas conocidas con el cartel de «pasen y vean».

En contra, lo que ya sabes si llevas tiempo en esto. Una actualización puede romper la web, por incompatibilidades entre plugins, por un tema que no sigue el ritmo, por lo que sea, y romperla sin nadie delante para enterarse. Además los plugins premium comprados fuera del directorio oficial van por libre, cada uno con su sistema de licencias, así que la automatización nativa ni los ve.

Si eres del bando manual tienes más razón que un santo en una cosa, actualizar a ciegas y sin red es jugar a la ruleta. Pero la conclusión correcta es otra: automatizar sí, pero con red.

Automatizar con red, lo que hace un buen hosting

La red existe y la ponen algunos hosting, yo te cuento cómo lo hace SiteGround, que es el que uso y recomiendo desde hace años, con su herramienta de actualización automática de las Site Tools, pero seguramente habrá más que también lo hacen bien.

Antes de cada actualización hace una copia de seguridad, después comprueba automáticamente que la web funciona y, si detecta un problema, revierte los cambios y te avisa. Puedes decidir con qué margen se aplican las versiones mayores y las menores, y además también actualizar los plugins del directorio oficial que tengas desactualizados.

O sea, que el escenario de pesadilla del bando manual, la web rota un mes entero sin que nadie se entere, con este sistema se convierte en un email que viene a decir «lo intenté, algo no cuadraba y lo he dejado como estaba». Así la cosa cambia del todo, ahora sí hay red de seguridad.

Y si quieres el control fino, el entorno de pruebas (el staging de toda la vida) te deja ensayar las actualizaciones gordas en una copia de la web antes de aplicarlas en la real. Es la opción de matrícula de honor para antes de un parón largo, actualizas todo en el entorno de pruebas, compruebas que nada se rompe y lo pasas a producción.

Qué y cómo actualizar según el tipo de web

Esto, como todo, es mi opinión, pero también como todo, basado en mi experiencia, yo te lo cuento y tú decides.

En un blog o web corporativa no veo problema alguno para tener actualizaciones automáticas con red para todo y a disfrutar de la vida.

En una tienda online, con WooCommerce, las menores y las de seguridad automáticas siempre, pero las versiones mayores de WooCommerce, de la pasarela de pago y del tema, mejor con entorno de pruebas o a mano en horario controlado.

Y es que una tienda caída o rota no son visitas perdidas, son pedidos que vuelan, dinero que no entra, y el proceso de compra tiene demasiadas piezas delicadas como para actualizarlo a ciegas en mitad de una campaña.

Por resumir:

• En piloto automático: las actualizaciones menores de WordPress (seguridad y manteniento) siempre, y todo lo demás con un sistema que haga copia previa, verificación y marcha atrás.
• Delegable: en tu hosting si tiene actualización inteligente, o en un servicio de mantenimiento, que además se ocupa de lo que la automatización no cubre, como los plugins premium y las versiones mayores con su entorno de pruebas.

Un vigilante no se coge vacaciones

Con la casa cerrada y las actualizaciones con red, falta el sistema de alarma, la parte que mira cuando tú no miras. Y aquí es donde el piloto automático se luce de verdad, porque casi todo lo importante de la vigilancia moderna funciona solo.

La seguridad que funciona es la que se revisa sola, sin esperar a que tú te acuerdes.

El cortafuegos y el bloqueo de fuerza bruta deben funcionar sin ti por defecto, filtrando peticiones maliciosas y bloqueando IPs a cualquier hora, da igual el sistema que apliques (CDN, plugin, hosting, todos a. la vez).

Ahora bien, la vigilancia que a mí me deja dormir tranquilo es otra, la de integridad, porque el malware moderno no se ve desde fuera.

Me refiero a la situación en que la web carga normal, el escritorio parece normal, y mientras tanto hay un archivo PHP colado en tu carpeta de subidas haciendo cosas raras, o una puerta trasera escondida en un plugin.

La única forma fiable de pillarlo es comparar, y comparar es justo lo que las máquinas hacen mejor que nosotros, comprobar el núcleo de WordPress contra las sumas de verificación oficiales, revisar los archivos de plugins y temas, y escanear la carpeta uploads buscando PHP donde solo debería haber imágenes.

Otra bomba de relojería silenciosa de la web desatendida son los plugins cerrados o abandonados, esos que WordPress.org retira del directorio por una vulnerabilidad sin arreglar o por abandono del autor, y que en tu web siguen instalados y activos tan campantes, porque nadie te avisa. Salvo que algo te avise, claro.

Esto último lo añadí a Vigilante justo después de que nos enterásemos de que alguien había colado puertas falsas en decenas de plugins en el directorio oficial. Gracias, o por culpa de eso, detecta los plugins cerrados y te dice además el motivo del cierre, que no es lo mismo «el autor lo dejó» que «tiene un agujero de seguridad sin parche».

Y el ejemplo que mejor resume la filosofía de todo este artículo es el analizador de seguridad de Vigilante, más de 40 comprobaciones con una puntuación de 0 a 100 que se ejecuta sola cada semana y únicamente te manda un email si la puntuación baja de verdad.

Ni resúmenes diarios que acabas ignorando, ni silencio absoluto, un vigilante que solo te llama si hay algo que contar, así se hace el piloto automático bien hecho.

El registro de actividad completa el arsenal, y no para que lo leas cada día (no lo vas a leer, y no pasa nada), sino para que a la vuelta puedas reconstruir qué ha pasado, quién entró, qué se instaló, qué cambió y cuándo.

Antes de que te relajes, por si no te has dado cuenta, los escáneres de seguridad están incorporando inteligencia artificial para detectar comportamientos anómalos en lugar de limitarse a firmas conocidas, un salto interesante que ya conté a fondo en mi artículo sobre seguridad WordPress con inteligencia artificial.

Otra amenaza que conviene vigilar también desde fuera, y para eso tienes dos opciones gratuitas, el análisis de seguridad WordPress online, que pasa más de 30 comprobaciones externas a tu web sin instalar nada (hazlo antes de irte, guarda la puntuación y repítelo a la vuelta), y un servicio de monitorización de disponibilidad tipo UptimeRobot, que te avisa al momento si la web se cae, que es lo primero que notarías si estuvieras delante y lo último que descubres si no lo estás.

• En piloto automático: cortafuegos, escaneos de integridad y malware, detección de plugins cerrados, análisis semanal con aviso solo si empeora, y monitorización de disponibilidad.
• Delegable: la interpretación y la reacción. Que las alertas las reciba y las resuelva un servicio de mantenimiento, y a ti te llegue solo el resumen.

Alertas: pocas y claras

La trampa clásica del que monta todo esto con ganas es activar todas las notificaciones de todos los sistemas. El resultado son veinte emails a la semana de cosas irrelevantes, tu cerebro los archiva como ruido y el día que llega el importante ni lo abres.

Si todo avisa, nada avisa, es el cuento de Pedro y el lobo, versión bandeja de entrada.

Mi recomendación es quedarte con cuatro alertas de verdad y mandar a resumen semanal, o directamente silenciar, todo lo demás. La caída de la web, una actualización automática que ha fallado y se ha revertido, la bajada de la puntuación del análisis semanal de seguridad, y cualquier detección de malware o cambio de integridad en archivos.

Y haz pruebas de todo antes de relajarte. Provoca un aviso de prueba o comprueba en el histórico que los emails llegan y no acaban en la carpeta de spam, que sería el colmo, el vigilante gritando y tú con los cascos puestos.

• En piloto automático: el filtrado. Se configura una vez qué avisa y qué calla.
• Delegable: el buzón entero. En un servicio de mantenimiento las alertas las recibe quien las va a resolver, y a ti solo te llega lo que necesita tu decisión.

Recomendaciones de seguridad que valen poquito

Hay medidas que se venden mucho y protegen poco, y en una web desatendida cada pieza de más es una pieza que puede fallar sola.

La primera, no apiles plugins de seguridad «por si acaso». Duplican reglas de cortafuegos, bloqueos de acceso y cabeceras, y el resultado suelen ser falsos positivos, avisos por duplicado y webs rotas, justo lo contrario de lo que buscas cuando no vas a estar delante. Elige uno que tenga de todo y bueno, configúralo bien y a otra cosa.

La segunda, ocultar la versión de WordPress es más cosmética que otra cosa. Los bots no leen tu número de versión y deciden educadamente si atacar, prueban el exploit directamente contra millones de webs y a ver cuál cae. Lo que te protege es actualizar y no tener la vulnerabilidad, por mucho cartel que escondas.

Y la tercera, la más importante, no tomes decisiones de seguridad por miedo, ni por el email alarmista de turno ni por el vendedor que te asegura que sin su suscripción premium tu web está condenada.

Lo que de verdad para los ataques es aburridísimo (copias, actualizaciones, accesos limpios y vigilancia automática, todo lo que llevamos visto) pero lo mejor es que es casi todo gratis o viene incluido en un buen hosting.

Plan B, por si aun así pasa algo

Todo lo anterior reduce muchísimo la probabilidad de sustos, pero el riesgo cero no existe, así que deja preparado el plan B, que consiste en poder reaccionar desde donde sea y cuándo haga falta, sin tener que acordarte de nada de memoria.

Tres escenarios más que probables:

• Si la web se cae entra en el panel de tu hosting, desde el navegador del móvil si no tienes otra cosa, y restaura la última copia buena, que para eso practicaste la restauración y apuntaste los pasos.
• Si ves un ataque en curso, con intentos de acceso masivos o tráfico raro, activa el modo «bajo ataque» de tu plugin de seguridad o de Cloudflare, que refuerza temporalmente los accesos mientras dura la tormenta.
• Si confirmas un hackeo, restaura la copia anterior al desastre, cambia todas las contraseñas y abre ticket con el soporte de tu hosting, que para eso pagas y además saben seguro más que tú y yo juntos, porque ellos ven estas cosas a diario.

Para que todo eso sea posible desde cualquier parte, deja apuntado antes de confiarte, en tu gestor de contraseñas, el acceso al panel del hosting, dónde están las copias y cómo se restauran, el canal de soporte y el teléfono de la persona a la que llamarás si prefieres no tocar nada.

Volvemos al vecino con la copia de las llaves, y si ese vecino no existe, para eso están los servicios de mantenimiento, que en el fondo son eso, el teléfono al que llamas para no tener que ser tú quien apague el fuego o al menos no hacerlo a solas. No es su función principal, que es más la prevención, pero también cuando hay problemas deben demostrar que elegiste bien.

• En piloto automático: nada, esta parte es tuya, pero se deja preparada en diez minutos.
• Delegable: entera. Tener mantenimiento contratado es exactamente esto, que el plan B sea el teléfono de otro.

Lista de comprobación de seguridad en piloto automático

Cuando sales de viaje cierras la llave del gas, bajas las persianas, pones alguna luz con temporizador, conectas la alarma y le dejas las llaves a alguien de confianza. Pues con tu web, exactamente igual.

Aquí tienes la lista completa, pensada para hacerla en una tarde. Imprímela, guárdala o pásala a tu gestor de tareas, pero repásala entera antes de cada parón, y una vez al trimestre aunque no te vayas a ningún sitio, que como decíamos al principio, la web desatendida no entiende de calendarios.

Previsión obligatoria antes del piloto automático de seguridad:

• Restaura una copia de seguridad de prueba y apunta los pasos y el tiempo que te llevó.
• Comprueba que la copia externa programada existe, es completa (archivos y base de datos) y se guarda fuera del servidor.
• Borra los usuarios que no se usen y baja privilegios a quien no necesite ser administrador.
• Activa la identificación en dos pasos para todos los que acceden a la web.
• Borra los plugins desactivados y los temas que no uses, dejando solo uno oficial de reserva.
• Aplica el refuerzo: edición de archivos desactivada, XML-RPC cerrado si no lo usas y cabeceras de seguridad puestas.
• Actualiza todo a mano una última vez, núcleo, plugins, temas y traducciones.
• Configura las actualizaciones automáticas con red, copia previa, comprobación posterior y marcha atrás.
• Pasa el análisis de seguridad externo, corrige lo que salga en rojo y guarda la puntuación para comparar a la vuelta.
• Revisa las notificaciones, deja sonando solo las cuatro importantes y mándate un aviso de prueba.

Las medidas de seguridad imprescindibles en piloto automático:

• Copias diarias del hosting más la copia externa programada.
• Actualizaciones automáticas con copia previa y reversión si algo falla.
• Cortafuegos y bloqueo de fuerza bruta.
• Escaneo de integridad de archivos y detección de malware.
• Detección de plugins cerrados o abandonados.
• Análisis semanal de seguridad con aviso solo si la puntuación baja.
• Monitorización de disponibilidad con aviso al móvil.

Notas de rescate:

• Acceso al panel del hosting.
• Donde están las copias y los pasos para restaurarlas.
• Canal de soporte del hosting.
• A quién llamar si necesitas ayuda.

Y ahora sí, cierra la puerta con dos vueltas

Si me preguntas como profesional que mantiene decenas de webs de clientes, mi posición es clara, mía, pero te la cuento. El piloto automático no es un apaño para vacaciones, es como debería estar montada la seguridad de cualquier web todo el año, porque eso de «yo lo reviso a mano cada día» dura dos semanas, como los propósitos de enero, y lo que queda después es una web que no revisa nadie.

¿Que ni siquiera quieres montarlo? Vale, es una decisión respetable, que para eso está la opción de delegarlo todo, y ahí te espero en mi servicio de mantenimiento WordPress.

¿Que gestionas webs de clientes y esta guía se te queda corta? Tengo publicada una guía de seguridad WordPress para empresas y agencias que sigue justo donde esta lo deja, y sino tienes toda una lista enorme de tutoriales de seguridad para WordPress.

Para dudas, matices o contarme tu propia lista de cerrar la casa, me tienes ahí abajo (que mis vacaciones son siempre teóricas), en la sección de comentarios.

Buen viaje, que la web queda en buenas manos. Las tuyas suyas.

Esta ley no pide enseñar el precio habitual, pide enseñar el precio más bajo que ese producto haya tenido en los últimos 30 días, y esa diferencia lleva aplicándose desde hace tiempo sin que casi nadie repare en ella.

No es una norma nueva ni un borrador pendiente, está muy vigente, así que vamos a ver exactamente qué exige, qué te juegas si no la cumples y cómo resolverlo sin volverte loco con el catálogo.

Lo que exige la directiva Ómnibus en cada rebaja de precios

La norma viene de la Directiva (UE) 2019/2161, conocida como directiva Ómnibus, que añadió el artículo 6 bis a la Directiva 98/6/CE de indicación de precios.

España la transpuso a través del artículo 20.1 de la Ley de Ordenación del Comercio Minorista, redactado por el Real Decreto-ley 24/2021, en vigor desde el 28 de mayo de 2022.

La regla en sí se explica en una frase y se cumple mal en la mayoría de tiendas:

Toda reducción de precio debe mostrar, junto al precio rebajado, el precio anterior.

Y ojo, porque «precio anterior» no es lo que la mayoría cree. No es el precio habitual del producto, es el precio más bajo que haya tenido en los 30 días previos a la rebaja, sea cual sea el motivo por el que estuvo a ese precio.

Aquí tienes los requisitos por la vía rápida, para que no digas que me hago esperar:

A qué te arriesgas si no cumples la directiva Ómnibus

Esto no es una recomendación de buenas prácticas, es una infracción tipificada, un delito, no es broma y las multas son tremendas.

El artículo 49 del texto refundido de la Ley General para la Defensa de los Consumidores y Usuarios clasifica las sanciones en tres niveles.

• Leves, que van de 150 a 10.000 €.
• Graves de 10.001 a 100.000 € (con posibilidad de superar esa cifra hasta 4 o 6 veces el beneficio ilícito obtenido).
• Muy graves llegan de 100.001 € hasta 1.000.000 €.

Y no es solo sobre el papel, ni de lejos, ya se han estrenado y con honores, el Ministerio de Derechos Sociales, Consumo y Agenda 2030 sancionó a siete empresas por subir el precio de varios productos justo antes del Black Friday para bajarlo después a su valor original y presentarlo como oferta.

El conjunto de las multas rondó los 350.000 € y una de las empresas recurrentes tuvo que depositar un aval de 110.000 € mientras se resuelve su recurso. Imagino que no te sobra el dinero ¿verdad?

Para detectarlo, la Dirección General de Consumo usó la Price Reduction Tool, una herramienta de la propia Comisión Europea que monitoriza precios en tiempo real durante campañas como esta.

Por si te lo estás planteando, la propia Comisión Europea ya avisó de que subir el precio antes de bajarlo no cuela, ni presentándolo como «precio futuro».

El precio anterior sigue siendo el más bajo real de los últimos 30 días, ponga lo que ponga en el cartel de la oferta.

Y ya que estamos una aclaración rápida, porque el nombre podría llevar a confusión, y es que esto no tiene nada que ver con el Digital Omnibus del que tanto se oye hablar últimamente, ese paquete que tiene que ver con el RGPD y las cookies. Ese otro Omnibus sigue paseándose por Bruselas, aún sin texto definitivo. La directiva Ómnibus de precios de la que te hablo aquí lleva aplicándose desde hace tiempo y no tiene nada pendiente de aprobar, está de un vigente que asusta.

Por qué el precio tachado de WooCommerce no te libra de nada

Siento decirlo, pero no, eso de los precios tachados no sirve de nada, ni de lejos, te lo explico.

Como sabes, WooCommerce tacha el precio habitual del producto y muestra al lado el precio de oferta, así que parece que ya cumples, per va a ser que no.

La realidad es que el precio habitual solo coincide con el precio anterior legal si no has tocado ese precio ni hecho ninguna promoción en los últimos 30 días. Si encadenas rebajas, el tachado de WooCommerce deja de servir como prueba de nada.

Es exactamente el truco que le costó el expediente a esas siete empresas del punto anterior, subir el precio unos días antes para que el descuento posterior parezca mayor de lo que es en realidad.

WooCommerce te deja hacerlo sin ningún aviso, porque el plugin no sabe nada de la directiva Ómnibus, solo compara el precio habitual con el de oferta rebajado que tú le pongas.

Plugins que ayudan con a cumplir la directiva Ómnibus de precios

Aquí no hace falta reinventar nada, hay opciones ya disponibles, solo te queda elegir con cabeza:

• Omnibus — show the lowest price, de iWorks (gratuito): Con más de 10.000 instalaciones activas, aunque sin cambios funcionales desde marzo de 2024 (la actualización de 2025 solo tocó el módulo de valoraciones), probado hasta WordPress 6.8.5 y sin traducción al español. Ojo con esto, pues varias reseñas señalan que en el primer descuento de un producto sin histórico previo, el plugin muestra el propio precio rebajado como si fuera el anterior, justo el fallo que no te puedes permitir, pruébalo antes de dejarlo activo pensando que cumple.
• WP Desk Omnibus for WooCommerce (de pago): Actualizado el 28 de mayo de 2026, con interpretación configurable según el país y soporte activo, buena opción si prefieres pagar por tranquilidad.
• FleekCode Omnibus Price Tracker (gratuito): Con tabla propia en base de datos en lugar de postmeta y base de instalación todavía pequeña. Pruébalo antes de pagar por el anterior, igual sin necesidad.

Con cualquiera de los tres cumples suficientemente, salvo que se confirme lo de WP Desk, en cuyo caso habría que descartar ese. Revísalos en una tienda de pruebas que tenga de todo antes de instalar nada definitivamente, porque el panorama de plugins cambia con el tiempo y lo que te cuento aquí tiene fecha de caducidad.

Un apaño con código si tu caso es de los sencillos

Si vendes solamente productos simples, nada de variables, y no te apetece meter un plugin enorme más para esto, aquí tienes un código que hace lo imprescindible.

Además, para que no creas que es una birria, tiene una salvaguarda que muchos plugins comerciales no tienen, y es que nunca inventa un precio anterior, si no hay 30 días reales de histórico no muestra nada:

<?php

/***
 * Plugin Name: Registro de precios mínimos según la Directiva Ómnibus de la UE
 * Plugin URI: https://servicios.ayudawp.com/
 * Description: Muestra un precio anterior solo si hay un historial real de al menos 30 días. Nunca inventa ni calcula un precio anterior. Solo para productos simples.
 * Version: 1.0
 * Author: Fernando Tellado
 * Author URI: https://ayudawp.com/
 * License: GPL2
 * License URI: https://www.gnu.org/licenses/gpl-2.0.html
 * Text Domain: registro-precios-omnibus
 * Domain Path: /languages
*/

/**
 * Registro de precios mínimos previsto en la Directiva Ómnibus de la UE (Directiva (UE) 2019/2161)
 * Solo muestra un precio anterior cuando hay un historial real registrado de al menos 30 días
 * Nunca inventa ni calcula un precio anterior. Solo para productos simples
 */

// Registra el precio cada vez que se guarde un producto, solo si ha cambiado
add_action( 'woocommerce_update_product', 'ayudawp_omnibus_log_price', 20, 2 );
function ayudawp_omnibus_log_price( $product_id, $product ) {

if ( ! $product || ! $product->is_type( 'simple' ) ) {
return; // Variable products need a dedicated plugin, not this snippet.
}

$current_price = $product->get_regular_price();

if ( '' === $current_price ) {
return;
}

$log        = get_post_meta( $product_id, '_ayudawp_omnibus_price_log', true );
$log        = is_array( $log ) ? $log : array();
$last_entry = end( $log );

if ( ! $last_entry || (float) $last_entry['price'] !== (float) $current_price ) {
$log[] = array(
'price' => (float) $current_price,
'date'  => current_time( 'timestamp' ),
);
}

// Eliminar las entradas con más de 45 días de antigüedad (el plazo legal de 30 días más un margen de seguridad)
$cutoff = current_time( 'timestamp' ) - ( 45 * DAY_IN_SECONDS );
$log    = array_values( array_filter( $log, function( $entry ) use ( $cutoff ) {
return $entry['date'] >= $cutoff;
} ) );

update_post_meta( $product_id, '_ayudawp_omnibus_price_log', $log );
}

// Mostrar únicamente el precio anterior con un historial acumulado de al menos 30 días reales
add_action( 'woocommerce_single_product_summary', 'ayudawp_omnibus_display_prior_price', 11 );
function ayudawp_omnibus_display_prior_price() {

global $product;

if ( ! $product || ! $product->is_type( 'simple' ) || ! $product->is_on_sale() ) {
return;
}

$log = get_post_meta( $product->get_id(), '_ayudawp_omnibus_price_log', true );
$log = is_array( $log ) ? $log : array();

if ( empty( $log ) ) {
return; // No history yet: show nothing rather than guessing.
}

$days_of_history = ( current_time( 'timestamp' ) - $log[0]['date'] ) / DAY_IN_SECONDS;

if ( $days_of_history < 30 ) {
return; // Core safeguard: never show a prior price without a real 30-day track record.
}

$window_start = current_time( 'timestamp' ) - ( 30 * DAY_IN_SECONDS );
$in_window    = array_filter( $log, function( $entry ) use ( $window_start ) {
return $entry['date'] >= $window_start;
} );

if ( empty( $in_window ) ) {
return;
}

$lowest_price = min( wp_list_pluck( $in_window, 'price' ) );

if ( $lowest_price <= (float) $product->get_sale_price() ) {
return; // Nunca muestra un precio anterior que no sea realmente inferior al precio rebajado
}

echo '<p class="ayudawp-omnibus-prior-price">' .
esc_html__( 'Precio anterior: ', 'ayudawp' ) .
wp_kses_post( wc_price( $lowest_price ) ) .
'</p>';
}

Este código registra el precio cada vez que guardas el producto, solo si ha cambiado, y purga las entradas de más de 45 días (30 de la ley más un margen de seguridad). En la parte visible de la web solo pinta el precio anterior cuando ya hay al menos 30 días reales de histórico acumulado, nunca antes.

Y para que no te lleves un susto, solo funciona con productos simples, no cuenta los cambios hechos por edición rápida, importación masiva o la API REST, y no sustituye a un plugin dedicado si tu catálogo es grande o vendes productos variables.

El código te lo dejo preparado como plugin, por si quieres subirlo como plugin o a mu-plugins, lo que prefieras. Si eres más de añadirlo como código quítale toda la cabecera que lo identifica como plugin, eso te sobra, y el <?php inicial, o no funcionará.

Si quieres más para eso están las opciones del punto anterior de los plugins.

Rebajas encadenadas, el caso donde más se la juegan las tiendas

Este es el escenario que más dudas genera, y por suerte la propia Comisión Europea lo aclaró bastante detallado en una comunicación publicada en el Diario Oficial de la UE en diciembre de 2021.

Hay dos situaciones muy distintas, y conviene no confundirlas:

• Campañas separadas con el precio subiendo entre medias (Black Friday, luego Navidad, luego rebajas de enero): Se aplica la norma general sin excepciones. El precio anterior de cada nueva rebaja tiene que ser el más bajo de, como mínimo, los últimos 30 días, y eso incluye el precio de la promoción anterior. Si bajaste un producto a 80 € en el Black Friday, dos semanas después no puedes anunciarlo «rebajado» tomando como referencia los 100 € de precio normal: tu referencia sigue siendo 80 €.
• Reducción progresiva dentro de una misma campaña, sin interrupción y sin que el precio suba en ningún momento: Aquí sí se puede mantener el precio previo a toda la campaña como referencia constante en cada escalón. Es la excepción que prevé el propio artículo 6 bis, aunque no he encontrado que España la haya transpuesto de forma explícita, así que el mensaje práctico y seguro es aplicar siempre la regla general de los 30 días, sin dar el atajo por hecho.

Si programas varias campañas con esa joya de plugin llamado Multiple Sale Prices Scheduler, ten en cuenta que el plugin programa los cambios de precio, no calcula el precio anterior legal por ti. Combínalo con alguna de las opciones de este artículo si vas a encadenar promociones.

Lo demás que trae la directiva Ómnibus y no tiene que ver con precios

El artículo 6 bis es la pieza que más te afecta si vendes con descuentos, pero la directiva Ómnibus trae más obligaciones que quizá también te toca cumplir.

Me refiero a cosas como verificar que las reseñas de tus productos vienen de compradores reales, dar una información mínima al consumidor antes de la compra, identificar con claridad la publicidad de influencers, y reconocer que los servicios «gratuitos» pagados con datos personales también generan derechos para el consumidor.

Cada una de estas otras cuestiones a tener en cuenta da para su propio artículo, así que aquí me quedo solo con el aviso, para que tengas en cuenta que esto es mucho más que solo precios.

Listado rápido para cumplir la directiva Ómnibus de precios

Si vendes con descuentos en WooCommerce, sí, y aquí te dejo el resumen para revisar tu tienda de un vistazo:

Nada más por ahora, dale una vuelta a tu catálogo antes de la próxima campaña que actives, sea cual sea. Si te ha quedado alguna duda sobre tu caso concreto, ya sabes dónde encontrarme, en los comentarios aquí abajo.

Todo eso se puede comprobar, sí, pero queda repartido en media docena de sitios que casi nadie visita (tu perfil de wordpress.org, translate.wordpress.org, los foros de soporte, la API de reconocimientos del núcleo, el directorio de fotos), y cada uno cuenta solo un trocito de tu historia, nunca la historia entera.

Así que me he hecho un regalo, y de paso os lo hago a todos los que contribuís de alguna forma a este proyecto llamado WordPress. Se llama Contributor Résumé, un plugin gratuito que coge todo ese trabajo disperso y lo convierte en un currículum bonito, siempre actualizado, que puedes publicar en tu propia web con un solo bloque.

Vamos a ver qué tiene dentro, cómo lo pones en marcha y por qué para mí esto no es un plugin más.

Un currículum de verdad para quien nos regala su tiempo y conocimiento

La idea es tan sencilla que casi da vergüenza no haberla hecho antes, pues escribes tu nombre de usuario de WordPress.org, compruebas lo que ha encontrado el plugin y publicas tu página. Nada de IDs numéricos, nada de tokens, nada de código. Esto vale igual si traduces, si respondes en el foro, si organizas meetups o si simplemente haces fotos para el directorio, no solo si publicas plugins.

Un único bloque, o el shortcode [contributor_resume] si trabajas con un tema clásico, agrupa decenas de secciones distintas, todas opcionales. Estas son algunas de las que más se van a usar:

• Perfil destacado: tu avatar, tus distinciones reales de wordpress.org y los enlaces a tu web, GitHub y Slack.
• Impacto reciente: tus contribuciones de los últimos 30, 90 y 365 días, con puntuación incluida.
• Eventos: las WordCamps y meetups en las que hablas, organizas o asistes.
• Traducciones: tus idiomas, tus permisos y el número de proyectos en cada uno.
• Soporte: los hilos que has abierto y las respuestas que has dado en los foros.
• Reconocimientos del núcleo: las versiones de WordPress en cuyos créditos aparece tu nombre.
• Plugins y temas: los que has publicado, con sus estadísticas, y los que tienes marcados como favoritos.
• GitHub: tu perfil y tus repositorios con más estrellas, sin necesitar ningún token para verlo.

Y quedan más, porque también incluye fotos del directorio de WordPress con su propia caja de luz, tu compromiso de horas semanales, la biografía con tu historia de origen, los equipos e idiomas de tu comunidad de contribución, y alguna sección más. Decenas de proyectos, cada uno reordenable arrastrando y soltando, y activable o no según lo que quieras enseñar. No está mal ¿no?

Además, que es el único currículum de WordPress real que hay.

¡Es taaan mooonoooo!

Si es que encima es bonito y para (casi) todos los gustos. Tienes tres estilos, uno moderno, uno clásico con aspecto de currículum impreso de toda la vida y uno monoespaciado que parece sacado de una terminal, para quien quiera presumir de friki con estilo.

A eso le sumas claro, oscuro o automático según lo que prefiera quien visita tu web, color de realce propio o heredado del tema, radio de esquinas, sombra, columnas de la cuadrícula y un diseño compacto si prefieres ir al grano. Las estadísticas se animan con un contador que sube según entran en pantalla, y se paran en seco si el visitante tiene activada la reducción de movimiento.

Puedes arrastrar las secciones para reordenarlas, elegir cuántos elementos muestra cada cuadrícula, y probarlo todo con una vista previa en directo, en escritorio y en móvil, sin salir de los ajustes. Y si con eso no tienes bastante, cada plantilla se puede copiar a tu tema y editarla a mano, con variables CSS documentadas bajo el prefijo --cvr-.

Solo tus datos, y ni uno de quien te visita

El plugin lee tus datos públicos de contribución en las URLs oficiales de WordPress.org (y, si añades tu usuario, también en la API pública de GitHub), y nunca recoge ni envía nada de quien entra en tu página. Las páginas públicas no hacen ninguna petición externa, y los avatares y las fotos los carga el navegador de tu visitante directamente desde WordPress.org, Gravatar o GitHub, igual que hace WordPress toda la vida con los avatares de los comentarios.

El único dato que sale de tu servidor es tu nombre de usuario, y solo cuando generas o actualizas el currículum en segundo plano. Si añades un token de acceso de GitHub (opcional, solo para subir el límite de peticiones a su API), se queda guardado en tu web y no se muestra jamás en la parte pública.

Cómo lo pones en marcha en un par de minutos

1. Instala y activa el plugin.
2. Abre «Contributor Résumé» desde el menú de tu cuenta en la barra de admin superior, o desde el enlace de ajustes que aparece junto al plugin en la pantalla de plugins.
3. Escribe tu nombre de usuario de WordPress.org (y, si quieres, el de GitHub) y pulsa «Comprobar y crear mi currículum».
4. Pulsa «Crea mi página de currículum», o añade el bloque (o el shortcode [contributor_resume]) a cualquier página que ya tengas.

Funciona igual de bien con el editor de bloques que con un tema clásico, y si administras varias instalaciones o trabajas con entornos de prueba, wp cresume refresh, wp cresume status y wp cresume clear-cache te dejan gestionar la caché entera desde WP-CLI.

¿Quieres verlo ya?

Tengo mi propio currículum publicado en esta misma web, con casi todas las secciones activadas, así que puedes verlo en marcha antes de instalar nada. Ahí aparecen mis 24 plugins publicados, mis traducciones a 23 idiomas repartidas en 3.416 proyectos, mis 134 hilos abiertos y 856 respuestas en los foros de soporte, y las WordCamps en las que he hablado solo en lo que llevamos de 2026.

Lo mejor es ver cómo suben solos los contadores de «Impacto reciente» mientras cargas la página, en vez de una foto de perfil de 2015 congelada para siempre. Los datos se actualizan sin que yo tenga que tocar nada.

Si lo prefieres, en la página del plugin puedes lanzar una vista previa en directo y WordPress.org te monta una web con el plugin activo para que pruebes con tu propio perfil.

Por qué esto no es un plugin más, es un regalo

Todos mis plugins resuelven un problema técnico, ya sea de seguridad, de rendimiento, de SEO o de cumplimiento normativo. Este no, este es diferente, este está dedicado a ti, que contribuyes a que todos podamos disfrutar de WordPress.

Es un plugin para quien traduce cadenas a las tres de la mañana, para quien modera un hilo de soporte enrevesado, quien organiza una WordCamp sin cobrar un euro, o quien hace fotos para el directorio de WordPress, porque todas esas personas, casi siempre anónimas, se merecen algo más que una insignia enterrada en un perfil que casi nadie mira. E

s gratis, sin letra pequeña ni versión de pago escondida detrás de las funciones buenas, porque la comunidad que me ha dado casi 20 años de carrera no me debe nada a mí, se lo debo yo a ella. Ya escribí en su día sobre por qué es importante tanto el software libre, así que no me voy a repetir aquí.

Si contribuyes de cualquier forma (código, traducciones, soporte, fotos, eventos, lo que sea), instálalo en tu web, crea tu página, y enséñale al mundo lo que llevas currado todo este tiempo. Y si todavía no contribuyes a nada, esto también vale como excusa estupenda para empezar a contribuir a WordPress, porque ya sabes dónde vas a poder enseñarlo después.

Puedes incluso traducirlo tú mismo a tu idioma, porque de momento solo está en español e inglés (dentro de nada en italiano), y a un plugin que celebra a quien traduce le vendría de perlas que también lo traduzcan.

Como dice el pie de página de wordpress.org, «el código es poesía». Pues ahora, además, tienes dónde publicar el tuyo. Si te lo instalas, cuéntame en los comentarios cómo te ha quedado o qué sección echas en falta.

Te lo adelanto ya, pero en plan básico: para una entrada normal de blog, BlogPosting o el valor por defecto, para una página corriente, WebPage, y entre los subtipos de la familia Article la elección apenas cambia nada en los resultados de Google, aunque sí en cómo te leen los asistentes de IA.

Sí, para empezar vale, como resumen cojonudo, pero si quieres hacerlo bien no te puedes quedar ahí, que la cosa tiene su miga, y lo mejor de todo es que de paso te va a servir aunque uses Yoast, Rank Math, el mismo Visibilty o cualquier otro plugin SEO, porque la etiqueta final es la misma.

Vamos a verlo de a pasito que dirían en mi pueblo.

Qué es eso del «tipo de schema»

Cualquier plugin de SEO, Visibility, Yoast, Rank Math el que sea, añade al código de cada página que publicas un bloque de JSON-LD, que son datos estructurados en formato JSON, invisibles para el visitante pero que las máquinas leen sin problema.

Dentro de ese bloque JSON-LD hay una propiedad llamada @type que dice qué es esa página, si un artículo, una noticia, una página de contacto o un perfil.

El tipo de schema es la etiqueta de una caja de mudanza, donde todas las cajas son iguales por fuera, y lo que cambia cómo las tratan los transportistas es que ponga libros o vajilla. Si marcas como vajilla una caja llena de libros no pasa nada grave, pero el que la abra esperando platos dejará de fiarse de tus etiquetas.

Con Google pasa lo mismo, una etiqueta que no se corresponde con el contenido no te penaliza de entrada, pero deja de servir para algo, y si encima es engañosa a propósito hay una acción manual esperándote en Search Console con el nombre de «marcado estructurado con spam».

Dónde se elige el tipo de Schema en tu plugin SEO

Cada plugin tiene sus manías, por ejemplo, en Visibility te deja fijarlo en dos niveles, por un lado, en los ajustes del módulo de descubrimiento eliges el tipo por defecto para cada tipo de contenido, uno para las entradas, otro para las páginas y así con cada tipo personalizado que tengas.

Luego, en la barra lateral del editor, entrada por entrada, puedes sustituir ese valor cuando una publicación concreta consideres que requiera otro Schema. Esto también lo tienen otros plugins, como Rank Math o Yoast.

La opción «Por defecto (Article)» del desplegable de Visibility y otros plugins significa justo eso, que se aplique lo que hayas configurado para ese tipo de contenido, así que si no tienes un motivo concreto para cambiarlo, déjalo en «Por defecto» y a otra cosa.

Si vienes de otro plugin SEO la lógica es muy parecida, Yoast lo llama «Page type» y «Article type» en su pestaña de schema, Rank Math lo llama «Schema Type» y SEOPress tiene su equivalente en los datos estructurados.

Todo lo que cuento en este artículo te sirve igual con cualquier plugin de SEO. Si te pasas a Visibility el importador de un clic se trae también estos valores desde Yoast, Rank Math y All in One SEO, junto con el resto de tus metadatos, al contrario no te prometo lo mismo.

La familia Article: seis etiquetas para casi lo mismo

El primer grupo del selector lo forman los subtipos de artículo, pensados para contenido editorial con autor y fecha:

• Article: el genérico, válido para cualquier contenido editorial y la elección segura cuando dudas.
• BlogPosting: la entrada de blog clásica, con voz y firma. Si tu web es un blog es tu etiqueta natural.
• NewsArticle: noticias y actualidad, contenido pegado a un hecho con fecha. Si cubres la actualidad de tu sector, este.
• TechArticle: tutoriales, guías paso a paso y documentación técnica. En un blog de tutoriales como este es el que más sentido tiene.
• ScholarlyArticle: estudios y trabajos con metodología, más propio de webs académicas o de investigación.
• Report: informes y análisis con datos, tipo estudio anual o comparativa documentada.

Pues bien, la documentación de Google solo contempla tres de ellos para su función de artículo, Article, NewsArticle y BlogPosting, y los trata como intercambiables. Los otros tres son subtipos válidos de schema.org que Google ni siquiera menciona.

O sea, que elegir entre BlogPosting y NewsArticle no va a cambiar cómo te muestra Google, y elegir TechArticle no te da nada extra en sus resultados.

¿Entonces para qué molestarse?, pues porque Google no es el único que lee esa etiqueta, los asistentes de IA y los motores de respuesta leen el @type tal cual, sin interpretarlo, igual que cualquier agente que rastree tu web.

Para un asistente de IA un TechArticle le dice que lo que tiene delante es un tutorial técnico, y que lo entregue cuando alguien pregunte cómo hacer algo, y de un NewsArticle  le dice que es una noticia, y que tenga muy en cuenta la fecha.

Ser preciso te cuesta un clic y aporta contexto a todo lo que no es Google.

Para Google, BlogPosting y NewsArticle son la misma etiqueta con distinto nombre, pero para un asistente de IA son dos cosas distintas.

Eso sí, sin venirte arriba, que Google ha dicho por escrito que sus funciones de IA no requieren ningún schema especial. La etiqueta correcta evita que las máquinas tengan que adivinar qué es tu contenido, y ahí se acaba su potencial.

La familia WebPage: sus apellidos

El segundo grupo es para páginas, contenido sin la lógica de autor y fecha de un artículo. La estructura se repite, con un tipo genérico y varios subtipos que lo afinan:

• WebPage: la página genérica, tu elección por defecto para páginas y la correcta en el 90% de los casos.
• AboutPage: la página «sobre mí» o «sobre nosotros». Refuerza la identidad del sitio, que es de lo que hablamos un poco más abajo.
• ContactPage: la página de contacto, una señal de transparencia que a las máquinas les viene de perlas para saber cómo localizarte.
• ProfilePage: el perfil de una persona o entidad. Es el único de este grupo con función propia documentada por Google desde noviembre de 2023, y el propio Google recomienda usarlo en las páginas de autor que enlaza el schema ATu código aquírticle, pura señal E-E-A-T (experiencia, conocimiento, autoridad y confianza, su mantra de calidad).
• CollectionPage: páginas que recopilan otras cosas, como un directorio de recursos o un listado de herramientas.
• ItemPage: una página dedicada a un único elemento concreto, la ficha de algo que no está a la venta.

Ninguno de estos tipos te va a pintar estrellitas en Google, y no pasa nada. Su trabajo es de identidad, decirle a quien rastrea tu web qué es cada página dentro del conjunto, que es lo que un asistente necesita para citarte bien.

Los que no suelen estar en el selector de Schema, y casi mejor

Faltan los famosos Product, Recipe, Event, VideoObject y LocalBusiness y si no los he incluido en Visibility no ha sido por despiste, es una decisión que tiene sus motivos.

El motivo principal para no incluir en un plugin de SEO por defecto este montón de tipos de Schema es que todos esos tipos tienen propiedades obligatorias que tu contenido no lleva (normalmente) de serie.

Un Product exige precio, moneda y disponibilidad, un Recipe quiere ingredientes y tiempos, un Event pide fechas y lugar, para que nos entendamos rápido.

Generar esas etiquetas sin sus propiedades te genera errores en Search Console, y un schema con errores es peor que no tener schema, porque le estás enseñando a Google cajas que prometen un contenido pero que al abrirlas están vacías.

Hay una segunda razón de peso, y es que quien de verdad posee ese dato ya genera ese schema. Un ejemplo que conocerás de sobras es WooCommerce, que ya genera el Product con el precio y el inventario reales.

Plugins muy conocidos, como por ejemplo The Events Calendar, genera el Event con sus fechas, y los plugins de recetas tipo WP Recipe Maker hacen lo propio con el Recipe.

Si Visibility, u otro plugin de SEO, te dejase elegir Product en el desplegable de una entrada, estaría duplicando o, peor todavía, contradiciendo al plugin que tiene los datos buenos, y de serie.

También hay que decirlo, los plugins de SEO que ofrecen estos tipos mediante un constructor de campos manuales de datos estructurados lo hacen bien si te molestas en rellenarlos, y si es así al menos tienes la oportunidad de hacerlo bien.

El problema es el desplegable alegre que te deja marcar cualquier cosa sin pedirte los datos, que de esos también hay. Si algún día estos tipos decido meterlos en Visibility será con un constructor de campos en condiciones, que lo último que te hace falta es una casilla que te anime a mentirle a Google.

El cementerio de los resultados enriquecidos

Google lleva años haciendo poda de resultados enriquecidos, y ese recorte explica por qué tampoco verás FAQ ni HowTo en el selector de tipos de Schema.

La lista de bajas impresiona (que en paz descansen):

• HowTo: limitado primero en móvil y eliminado del todo en septiembre de 2023. Los pasos con fotos en los resultados son historia.
• FAQ: restringido en agosto de 2023 a webs gubernamentales y de salud, y rematado para todo el mundo el 7 de mayo de 2026. Los desplegables de preguntas bajo tu resultado ya no existen para nadie, y en junio de 2026 desaparecieron también del informe de Search Console y de la prueba de resultados enriquecidos.
• La masacre de junio de 2025: Course Info, Claim Review, Estimated Salary, Learning Video, Special Announcement y Vehicle Listing, todos fuera por poco uso.
• La segunda tanda de noviembre de 2025: más funciones retiradas, entre ellas los problemas de práctica (practice problems) desde enero de 2026.

La razón, en el caso del FAQ es, para variar, el abuso por parte de los SEO y usuarios demasiado comprometidos, que se marcaron preguntas de relleno a mansalva para ocupar más sitio en los resultados hasta convertirlo en spam con acordeón. En el resto de casos Google simplifica su página de resultados para dejar hueco a sus propia funciones de IA.

Así que el marcado FAQPage sigue siendo schema.org válido y otros sistemas pueden leerlo, pero como truco para ganar espacio en Google está muerto, y si un tutorial de 2022 te anima a marcar FAQ para conseguir los desplegables, ya sabes de qué año es esa información.

La identidad del sitio: Organization, Person y el baile de los @id

Queda un tipo de schema que no aparece en los desplegables, y es debido a que no es de página, es de sitio. Tu web entera tiene una identidad, una Organization si eres una empresa o un proyecto, una Person si eres tú a título personal, y esa identidad debe declararse una sola vez, en la portada, con todos sus datos.

Aquí entra el baile de los @id, porque cada nodo de schema puede llevar un @id, que viene a ser su DNI, una URL única que permite que otros schemas lo referencien en vez de repetirlo.

Si usas VigIA, que emite el JSON-LD de identidad del sitio en la portada, Visibility detecta ese nodo y hace que el publisher de cada artículo apunte al mismo @id en lugar de crear una Organization duplicada.

Dos fichas de la misma entidad con datos distintos confunden a cualquier máquina, y la gracia de coordinar los @id es que todo tu sitio dice lo mismo sobre quién eres, lo mire quien lo mire.

Lo bueno de usar este conjunto es que se complementan sin pisarse, la ventaja de coordinar plugins, en principio para usos diferentes, pero al final todo tiene algo de relación, como es el caso.

Cómo comprobar si lo has hecho bien

Tres pruebas rápidas y gratis:

1. Abre el código fuente de una entrada (clic derecho en la página) y busca application/ld+json. Ahí verás el bloque con el @type que has elegido, junto al BreadcrumbList (las migas de pan) que Visibility añade por su cuenta.
2. Pasa la URL por la prueba de resultados enriquecidos de Google para ver qué funciones detecta. Ojo, solo te enseñará las que Google mantiene vivas.
3. Pasa la misma URL por el validador de schema.org, que comprueba si el marcado es válido aunque Google no pinte nada con él. Para los tipos que Google ignora, este es tu árbitro.

Chuleta rápida para casi ni pensar

Si después de la tabla sigues con dudas, déjalo en «Por defecto», que para eso está y no te vas a equivocar. Lo importante es no mentir con la etiqueta, el subtipo perfecto es secundario.

Si quieres seguir tirando del hilo de cómo leen tu web los asistentes de IA, tengo unas cuantas guías publicadas sobre el tema de visibilidad en IAs.

Para dudas concretas sobre tu caso, que seguro que las hay porque este tema las genera solas, me tienes ahí abajo, en la sección de comentarios.

Quieres que un sitio tenga unas reglas en el robots.txt y otro las suyas, normal ¿no?, porque no todos necesitan lo mismo, y resulta que WordPress te sirve el mismo robots.txt para todos. Y encima, si abres el de cualquiera de los dominios, ves uno que no has puesto tú.

Me lo trajo hace poco un cliente del servicio de mantenimiento, con un multisitio de varios dominios, que me pidió tocarle los robots.txt de cada web.

Cuando me puse a mirarlo resulta que el problema no era suyo ni de su configuración, era de cómo funciona WordPress por dentro con los ficheros en una red multisitio.

Así que aprovecho para contártelo con calma, porque tiene más miga de la que parece. Y sí, ya te lo adelanto, se puede tener un robots.txt distinto por sitio en una red multisitio de WordPress, pero antes hay que darle una pensada, porque todo tiene sus matices.

¿Por qué en cada dominio de WordPress multisitio hay dos archivos para robots?

Primero, un apunte rápido para quien llegue nuevo. WordPress no crea un fichero robots.txt de verdad en el disco, lo genera dinámicamente cada vez que alguien lo pide, lo que se llama un robots.txt virtual. Puedes verlo y modificarlo, pero eso ya te lo conté al detalle en el post sobre el robots.txt virtual de WordPress, con el truco de verlo tecleando ?robots=1 y el filtro para cambiarlo.

El caso de mi cliente era que en su multisitio hay un robots.txt físico, un fichero de verdad, en la raíz del dominio principal, el que aloja la red y desde el que se instalan los plugins y el tema.

Y como toda la red comparte esa misma carpeta raíz, ese fichero se sirve igual para todos los dominios, así que tecleas otro-dominio.com/robots.txt y sale el del principal, no el del subsitio, porque no tiene un robots.txt físico, no es posible.

¿Y el virtual de cada sitio, el que tú crees que estás editando con tu plugin de SEO? Ahí sigue, pero solo aparece si lo fuerzas a mano con otro-dominio.com/?robots=1.

Los rastreadores piden siempre /robots.txt, así que se meriendan el físico compartido y nunca ven las reglas propias de cada web. De ahí la sensación de tener dos, el que sirven los bots y el que gestiona el plugin, cada uno con sus reglas y sin enterarse el uno del otro.

¿Y por qué gana el físico? Pues porque cuando existe uno en la raíz, lo entrega el servidor web antes de que WordPress ni siquiera arranque, así que el virtual y el filtro se quedan sin pintar nada para esa dirección.

Subdominios, dominios mapeados y subcarpetas

El estándar del robots.txt, recogido en el RFC 9309 que es la norma oficial, dice que el archivo vive en la raíz de cada host, o sea de cada dominio o subdominio, y de ahí salen tres escenarios muy distintos según cómo tengas montada la red.

• Red por subdominios (es.tudominio.com, en.tudominio.com): cada sitio es un host distinto, así que cada uno puede y debe tener su propio robots.txt. Aquí lo de «uno por sitio» tiene todo el sentido.
• Red por dominios mapeados (dominio.com, domain.com): igual que el anterior, cada dominio es un host, así que cada uno lleva el suyo.
• Red por subcarpetas (dominio.com/es, dominio.com/en): todos comparten el mismo host, así que solo hay un robots.txt que cuente, el de la raíz del dominio, y manda el sitio principal. Un subsitio en subcarpeta no puede servir el suyo a los rastreadores por mucho plugin que le pongas.

Y ojo, que lo de las subcarpetas no es una carencia de WordPress, es el propio estándar.

El robots.txt va en la raíz del host y punto, así que si tu red es por subcarpetas, lo máximo que puedes hacer es meter todas las reglas que necesites, conjuntas, en el robots.txt del dominio principal, teniendo cuidado de no meter reglas que solo sirvan para el dominio o una carpeta concreta, todas generales.

¿Qué hago con el robots.txt del sitio principal?

Da igual la vía que elijas luego, con código o con plugin, si hay un robots.txt físico en la raíz y quieres reglas por subsitio quítalo, porque carga antes que WordPress y ningún plugin o PHP se lo puede saltar.

Mientras ese fichero siga ahí los bots seguirán leyéndolo a él y las reglas por sitio no llegarán a ninguna parte.

Pero, si es el caso, con quitarlo no basta, además tienes que asegurarte de que ningún plugin te lo vuelve a crear. El editor de ficheros de Yoast, por ejemplo, escribe un robots.txt físico si le das al botón, y en una red ese fichero se te cuela para todos. Así que bórralo, comprueba por FTP que no reaparece, desactiva la edición de archivos dentro de WordPress, y solo entonces pasamos al siguiente paso.

Una vez fuera  el archivo físico WordPress ya sirve el virtual de cada sitio por su cuenta, y ahí sí puedes empezar a configurar en cada web el suyo. En subdominios y dominios mapeados esto funciona tal cual, cada host sirve el suyo. En subcarpetas no hay manera, se siente, solo cuenta el del dominio principal.

Cómo darle reglas propias de robots a cada subsitio de una red multisitio (con código)

Si no quieres depender de ningún plugin de SEO para esto, WordPress trae un filtro, robots_txt, que te deja modificar el robots.txt virtual, y combinándolo con get_current_blog_id() (la función que te dice en qué sitio de la red estás) puedes dar reglas distintas según la web. La idea, que he ido ampliando y actualizando, me la dio Florian Brinkmann, en un post de hace ya unos pocos años.

Lo que hay que hacer es meter el siguiente código en un mu-plugin que se activa en toda la red. Lo subes por FTP a la carpeta wp-content/mu-plugins y listo:

/**
 * Plugin Name: Archivo robots.txt por sitio en WordPress Multisitio
 * Plugin URI: https://ayudawp.com/
 * Description: Permite definir reglas de robots.txt diferentes para cada sitio en una red multisitio de WordPress.
 * Version: 1.0
 * Author: Fernando Tellado
 * Author URI: https://tellado.es
 */

// Añade reglas por sitio al archivo robots.txt virtual de cada sitio a través de la red
add_filter( 'robots_txt', 'ayudawp_multisite_robots_txt', 20, 2 );

function ayudawp_multisite_robots_txt( $output, $public ) {

// Solo funciona si es multisitio
if ( ! is_multisite() ) {
return $output;
}

// Reglas por sitio asignadas por ID de blog (tienes el ID en Administrador de la red > Sitios)
switch ( get_current_blog_id() ) {

// Sitio con ID 2: tienda online
case 2:
$output .= "Disallow: /carrito/\n";
$output .= "Disallow: /finalizar-compra/\n";
$output .= "Disallow: /mi-cuenta/\n";
break;

// Sitio con ID 3: blog
case 3:
$output .= "Disallow: /?s=\n";
$output .= "Disallow: /descargas/\n";
$output .= "Disallow: /gracias/\n";
break;
}

return $output;
}

Cambias los ID (case x)  y las reglas por las tuyas, y cada web servirá las suyas.

El código tiene sus límites, como que es obvio que lo mantienes tú a mano cada vez que cambien las necesidades, y luego claro está, no se puede aplicar a otros archivos, como el llms.txt, que arrastra el mismo problema. Y por supuesto, te recuerdo de nuevo que en una red en subcarpetas no hay milagro que valga.

¿Afecta esto también al llms.txt?

Ya que estás con el robots.txt, los archivos llms.txt sufren del mismo problema.

Es un fichero que sirve de índice en Markdown de tu web para los agentes de IA, y en una red cada sitio querría el suyo. Mismo patrón que el robots.txt, por sitio si lo sirves dinámico, y compartido y roto si escribes un físico en la raíz. La diferencia con el robots.txt es que aquí ni el filtro tienes.

WordPress no genera archivos llms.txt ni trae ninguna función para tocarlo, así que el mu-plugin de arriba no sirve y por código te quedas sin un atajo como el del robots.txt. Para tenerlo por sitio en una red la vía práctica es un plugin que lo genere dinámico por sitio, y de eso va lo que viene ahora.

Cómo darle reglas propias de robots a cada sitio (con plugins)

Si lo de mantener un mu-plugin no te apetece, o también quieres que el llms.txt sea configurable en cada sitio, esto lo resuelven algunos plugins.

De pago te lo ofrece AIOSEO, que tiene un editor de robots.txt de red que te deja tocar el de cada subsitio, pero solo en redes por subdominios, no por subcarpetas (lo dicen ellos en su documentación), y en su versión Pro. SEOPress anuncia edición de robots.txt para multisitio y multidominio, y luego hay plugins dedicados solo a esto, como Multisite Robots.txt Manager. De las subcarpetas nos seguimos olvidando, porque ya sabes que ahí manda el estándar.

Y luego está Visibility, plugin gratuito de SEO que sirve el robots.txt y también el llms.txt de cada sitio de la red por su cuenta, sin que tengas que tocar nada.

Entrega por una única URL, la de siempre, /robots.txt, y de paso arregla ese lío del ?robots=1 y los 404 en instalaciones en subcarpeta. Además, está pensado para no repetir el problema, porque en una red no escribe un físico compartido, solo lo escribe donde de verdad es del sitio, en una instalación normal o en el sitio principal de una red por subcarpetas.

Visibility sustituye a tu plugin de SEO, no convive con él, así que si vienes de Yoast u otro plugin, esto supone cambiar el que tuvieses por Visibility, no añadir uno más, que siempre es mala idea. Pero no es algo preocupante, no pierdes nada importante, tiene lo que los demás, y algunas cosas (casi todas) las hace mejor.

Ah, y da igual la elección, aunque uses Visibility el robots.txt físico de la raíz hay que quitarlo igual, porque un fichero que sirve el servidor no lo salta nadie. Eso sí, si Visibility detecta un físico compartido tapando el virtual, te avisa en su pestaña de descubrimiento para que sepas que está ahí y lo quites.

Y, por si no lo sabías Visibility, además de hacer lo que todos los demás plugins de SEO, redirecciones incluidas, también emite las señales por sitio (robots.txt, llms.txt y el schema), y si además quieres medir, tienes VigIA, que ofrece analítica de qué rastreadores de IA entran de verdad en cada web y puede bloquearlos, y puedes complementar el pack IA con AI Content Signals, que añade las directivas de IA de Cloudflare.

Resumiendo: Qué hacer con los ficheros robots.txt en multisitio según el tipo de red

En un par de líneas, por si ya estás con algo de lío:

• Si tu red es por subdominios o por dominios mapeados: quita el físico de la raíz y luego das las reglas por sitio con el mu-plugin del filtro robots_txt, o dejas que lo haga tu plugin de SEO (o Visibility) por ti. Cada dominio servirá el suyo.
• Si tu red es por subcarpetas: solo hay un robots.txt, el del dominio principal, así que mete ahí todas las reglas que necesites para los distintos subsitios. Es el único sitio donde los bots las van a leer.

¡Te toca decidir!

Antes de tocar nada, échale un vistazo a tu red y mira si tienes el problema. Pide el robots.txt de cada dominio y compáralos, y si todos te devuelven exactamente el mismo, tienes un físico compartido mandando sobre todos.

Desde el terminal es tan fácil como teclear la URL tipo https://dominio.com/robots.txt cambiando el dominio o subdominio, y comparar lo que sale. Y si quieres ver el virtual la URL es añadir ?robots=1 al dominio o subdominio.

Con eso claro decides si quitar el físico y tirar de código, o quitar el físico y dejar que un plugin te sirva el de cada sitio. Lo que no funciona es dejar el robots.txt físico compartido ahí, porque se antepone en toda la red y, salvo que uses las mismas reglas para todos los subsitios, puedes estar creándote un problema de rastreo.

Si tienes una red montada de una forma rara, o te topas con algún caso que no encaja con esto, me tienes en los comentarios aquí abajo, que estos temas de multisitio siempre traen su cosilla, y no lo usa muchísima gente.

Y el problema es que la mayoría de la información disponible sobre el tema está mezclada, sin querer, entre el aplazamiento de las obligaciones de alto riesgo y lo que de verdad te toca a ti con un sitio WordPress. Vamos a separarlo con calma, caso por caso, sin dar nada por hecho, a ver si soy capaz de explicártelo como yo lo he entendido, y como lo aplico.

Quién es quién ante la norma: proveedor y responsable del despliegue

El reglamento reparte las obligaciones entre dos papeles distintos, y confundirlos es la fuente de la mitad de los problemas que te puedes buscar sin ayuda de nadie.

• El proveedor es quien construye y comercializa el sistema de IA, Anthropic con Claude, OpenAI con ChatGPT, Google con Gemini.
• El responsable del despliegue es quien usa esa herramienta ya hecha para su propio contenido, o sea, tú con tu WordPress.

Piénsalo como la diferencia entre quien fabrica un coche y quien lo conduce. Al fabricante le tocan las revisiones técnicas del motor, la homologación, que las piezas cumplan norma, al conductor le toca circular con las luces encendidas de noche y llevar el cinturón puesto. Son obligaciones distintas sobre el mismo vehículo, y confundir una con otra no libra a nadie de la suya.

En la práctica casi todo lo que te afecta a ti como propietario de un WordPress cae del lado del responsable del despliegue. El marcado técnico invisible del contenido, ese que debe ser legible por una máquina, corresponde al proveedor del modelo, no a ti. Lo que sí te toca es el aviso visible al usuario, y ahí es donde vamos a entrar ahora.

¿Y si no estás en España, o ni siquiera en la Unión Europea?

Aquí conviene hacerse una pregunta que va más allá de dónde vive tu empresa o dónde tienes contratado el hosting. El reglamento europeo tiene alcance extraterritorial, igual que el RGPD con el que ya convives si tienes un formulario de contacto en tu web. Se aplica también a proveedores y responsables del despliegue establecidos en un tercer país cuando el resultado que produce el sistema de IA se usa dentro de la Unión Europea.

Vamos, en lo que nos afecta, si tu web la lee gente en algún país de la Unión Europea, algo que le pasa a prácticamente cualquier blog público con un mínimo de tráfico, el reglamento entra en juego aunque tú estés en México, Argentina o al otro lado del mundo. No hace falta que factures en euros ni que tengas oficina en Europa.

Dicho esto, y como pasa siempre que se habla de normativa, esto es información general para que entiendas el criterio, no una sentencia sobre tu caso concreto. Si tienes dudas serias porque tu negocio tiene peso real en la Unión Europea, consulta con un abogado especializado, que para eso están.

Los tres casos que de verdad te afectan en un WordPress

El artículo 50 del reglamento, que es el que regula la transparencia, cubre varios supuestos, pero solo tres tienen encaje real en un sitio WordPress «normal».

Un chatbot o asistente que habla con tus visitantes

Si tienes un chatbot de atención al cliente, la norma exige que quien interactúa con él sepa que está hablando con una máquina, salvo que sea tan obvio que no haga falta decirlo, un bot con nombre «Asistente IA» y avatar de robot no necesita cartel adicional. La excepción de la obviedad no es una puerta trasera para no avisar, es sentido común aplicado a los casos donde nadie en su sano juicio pensaría que habla con una persona.

Una imagen, audio o vídeo que sea un deepfake

Aquí está el mito más extendido de todos, la idea de que toda imagen generada con IA necesita aviso, y no es así. La obligación solo se activa con deepfakes, y la propia norma define el término con precisión, pues se refiere únicamente a contenido de imagen, audio o vídeo creado o modificado por IA que imita a personas, objetos, lugares, entidades o hechos reales de forma que pudiera hacer creer a alguien que es genuino.

Una ilustración abstracta para acompañar un artículo de seguridad, un fondo decorativo, una infografía inventada, nada de eso es deepfake, porque no simula que algo real haya ocurrido. Donde sí entras en el supuesto es si generas una imagen que aparenta ser una captura real de un evento que nunca pasó, o que hace pasar por auténtica la imagen de una persona real en una situación inventada.

Un texto sobre un asunto de interés público

Este es el que caso que tiene más matices de los tres. De lo que se trata es que si usas IA para generar o manipular texto que se publica con el fin de informar sobre asuntos de interés público, tienes que avisar de que es artificial, salvo que ese texto haya pasado por una revisión editorial sustantiva y haya una persona, física o jurídica, que asuma la responsabilidad editorial de lo publicado.

El matiz más relevante es que las directrices de la Comisión Europea interpretan esa excepción de forma estricta. No vale una revisión superficial ni un visto bueno de trámite, tiene que haber un examen deliberado del fondo del contenido por alguien con criterio suficiente para hacerlo. Corregir la ortografía o dar el visto bueno sin leerte el texto entero no cuenta.

Para la inmensa mayoría de tutoriales técnicos, el supuesto ni siquiera se activa, porque explicar cómo desactivar un widget no es informar de un asunto de interés público en el sentido que persigue la norma. Pero un artículo sobre una vulnerabilidad que afecta a un millón de webs, o sobre este mismo reglamento, empieza a acercarse a esa categoría, así que conviene tenerlo presente cuando el tema es importante.

Cuando lo ves así, en una tabla, el titular de «hay que etiquetar todo lo que hagas con IA» se cae solo.

Mitos sobre AI Act

Antes de seguir, cinco ideas que circulan por ahí y que no ayudan nada.

• «Se ha retrasado el AI Act»: Cierto a medias, y la parte cierta es justo la que no te afecta. La Unión Europea sí ha aplazado las obligaciones de los sistemas de alto riesgo, empleo, biometría, infraestructuras críticas, hasta diciembre de 2027 y agosto de 2028. Pero las obligaciones de transparencia del artículo 50, las que trata este artículo, no se han tocado y siguen entrando en vigor el 2 de agosto de 2026. Quien lea «se retrasa el AI Act» y deje de prepararse por completo se va a llevar un disgusto.
• «Tengo que etiquetar cada imagen que hago con IA»: Ya lo hemos visto arriba, y solo los deepfakes necesitan aviso, y la mayoría de las imágenes ilustrativas de un blog no lo son ni de lejos.
• «Como la ley española no está en el BOE, tengo tiempo»: El proyecto de ley española, que ya está en el Congreso, no inaugura estas obligaciones, las adapta con maquinaria propia de sanción en España. El reglamento europeo es de aplicación directa, con ley española o sin ella, así que el reloj corre igual.
• «Me pueden caer 35 millones de euros por no avisar»: Esa cifra corresponde a las prácticas prohibidas del artículo 5, cosas como la manipulación subliminal o la valoración social, no al incumplimiento del artículo 50. Lo que arriesgas aquí son multas de hasta 15 millones de euros o el 3 % de la facturación mundial, según lo que sea mayor, que tampoco es una broma, pero conviene tener la cifra correcta.
• «Tengo que revisar y etiquetar todo lo que ya he publicado»: No. La obligación se aplica a partir del 2 de agosto de 2026, el contenido que ya llevaba tiempo circulando antes de esa fecha no necesita marcado retroactivo. Lo que sí entra en juego es todo lo que generes o publiques a partir de ese día.

El caso de los resúmenes generados con IA

Vamos a bajarlo a un ejemplo real, que es más útil que quedarse en la teoría. Cada vez hay más plugins, el mío incluido con Share Buttons & AI-powered Summaries, que generan un resumen automático de la entrada con un proveedor de IA externo. ¿Ese resumen necesita aviso?

Pues bien, las directrices de la Comisión, al desarrollar el artículo 50.2, ponen a los resúmenes generados por IA en la lista de cambios sustantivos, junto a las traducciones o la eliminación de objetos de una imagen, frente a la edición estándar que sí queda exenta, como corregir ortografía o ajustar el color.

Esa parte concreta de la norma habla del marcado técnico que corresponde al proveedor del modelo, no directamente de tu aviso al lector, pero deja clara una cosa, que un resumen no es una tontería formal, es contenido nuevo con entidad propia.

La pregunta que de verdad te afecta como responsable del despliegue es si ese resumen entra en el supuesto de texto sobre un asunto de interés público y si ha pasado por esa revisión editorial de la que hablábamos antes. Y ojo, revisar el artículo del que sale el resumen no es lo mismo que revisar el resumen en sí, que suele generarse solo, en cada visita o en cada publicación, sin que nadie le eche un vistazo concreto a esa pieza de texto en particular.

Por suerte la salida práctica no depende de resolver ese debate. Share Buttons & AI-powered Summaries ya muestra por defecto la etiqueta «Resumen generado con IA» encima de cada resumen, así que si usas el plugin sin tocar ese ajuste, este supuesto no te da ningún quebradero de cabeza.

El matiz es que el texto de la etiqueta es configurable, y si lo cambias por algo que no mencione la IA, o lo quitas directamente, la responsabilidad de que el aviso siga ahí es tuya, no del plugin. La herramienta te pone el camino fácil, no te lo puede recorrer por ti.

Esto vale igual si generas el resumen con cualquier otro plugin o a mano con tu proveedor de IA favorito.  La etiqueta de una línea, «resumen generado con inteligencia artificial» o similar, resuelve el debate entero sin necesidad de elucubrare si tu web informa o no de un asunto de interés público.

Textos alternativos e imágenes generadas con IA

WordPress 7 trae de serie una pantalla de conectores de IA donde guardas tu clave de Anthropic, OpenAI o Gemini para que cualquier plugin compatible la use. Si la usas para generar texto alternativo de tus imágenes o para crear una ilustración con la que acompañar un artículo, ¿entras en el supuesto de aviso?

Con el texto alternativo la respuesta corta es que no, y aquí no hay una directriz de la Comisión que lo diga con esas palabras exactas, así que es mi lectura razonada del propósito de la norma, no una cita textual de nadie. El alt describe una imagen para quien usa lector de pantalla, no informa al público de ningún asunto, ni siquiera lo ve quien navega con la vista, así que se queda fuera del espíritu del artículo 50.4 igual que se quedaría fuera un pie de foto meramente descriptivo.

Con las imágenes ilustrativas aplica exactamente lo que vimos antes, pues si no simula un hecho, una persona o un lugar real de forma creíble, no es deepfake y no necesita aviso.

Y para quien se pregunte quién marca técnicamente qué cuando usa el conector, el proveedor del modelo que hayas conectado, Anthropic, OpenAI o Google, es quien responde del marcado legible por máquina del artículo 50.2. Tú, como responsable del despliegue, respondes de lo que ya hemos visto, el aviso visible cuando el contenido lo requiere. Usar el conector nativo no te añade ninguna obligación nueva que no tuvieras ya generando el mismo contenido por otra vía.

Qué deberías tener listo desde ya

Con todo lo anterior ya tienes el criterio. Esto es lo concreto que conviene dejar hecho:

• Revisa si tienes chatbot o asistente de IA en la web, y confirma que el visitante sabe que habla con una máquina.
• Si generas imágenes con IA plantéate en cada caso si podría confundirse con algo real, no solo si «se ve muy realista».
• Si usas resúmenes generados con IA mejor con la etiqueta visible que sin ella, cuesta una línea de HTML y te ahorra la inquietud y un posible susto.
• No toques lo ya publicado antes del 2 de agosto de 2026 solo por esto, la obligación mira hacia delante.
• Si tu contenido tiene peso en asuntos de interés público, documenta que lo revisas tú antes de publicar, no hace falta un proceso complicado, basta con que sea real y puedas explicarlo si alguien pregunta.

Con la tabla de más arriba ya tienes el criterio completo caso por caso. Y si quieres el aviso de una línea listo para pegar en cualquier resumen o texto generado con IA, aquí lo tienes:

<div style="border-left: 4px solid #8a8a8a; background: #f5f5f5; padding: 10px 16px; margin: 16px 0; font-size: 0.9em; line-height: 1.5;">
  <strong>Aviso:</strong> este resumen ha sido generado con inteligencia artificial.
</div>

La Unión Europea también ha publicado un conjunto de iconos oficiales pensado para este etiquetado, por si prefieres un icono en vez de texto.

España y la capa nacional: AESIA

Todo lo anterior aplica ya, por el reglamento europeo, tengas o no ley española, pero si estás en España tenemos espía nuevo, gracias a esos políticos que siempre están pensando en nosotros.

El Gobierno español aprobó el proyecto de ley orgánica para el buen uso y la gobernanza de la inteligencia artificial el 26 de mayo de 2026 y lo envió al Congreso, donde sigue su trámite parlamentario con paso por el Senado antes de publicarse en el BOE.

Esa ley no inventa las obligaciones que has leído en este artículo, las aplica con maquinaria sancionadora propia y designa a la Agencia Española de Supervisión de la Inteligencia Artificial, la AESIA, como autoridad principal para vigilar y sancionar. Mientras el texto sigue su trámite, este artículo se actualiza en cuanto haya novedad publicada en el BOE, así que no hace falta que vayas comprobándolo tú.

Resumen rápido

Si te quedas con una sola idea de todo esto, que sea esta: la norma no castiga usar IA, castiga hacerlo pasar por algo que no es.

Un chatbot que se presenta como humano, una imagen que finge ser una foto real, un texto que informa de algo serio sin que nadie se haya hecho responsable de su contenido, eso es lo que persigue el reglamento. Un resumen con su etiqueta, una ilustración decorativa, un texto alternativo bien escrito, ninguno de esos tres necesita que te compliques la vida.

Este artículo es información general para que entiendas el criterio y actúes con cabeza, no asesoría legal sobre tu caso concreto, así que si tu situación tiene matices importantes, consulta con un profesional. Y si detectas algo que ha cambiado, ley española publicada, directrices finales de la Comisión distintas de lo que cuento aquí, dímelo en los comentarios y actualizo el artículo.

Si quieres profundizar en la parte legal más amplia, tengo también la guía de registro de consentimientos.

Me refiero a lo que Google mide como LCP (el tiempo que tarda en aparecer el bloque más grande de tu pantalla), y cuanto antes aparezca, mejor.

El problema es que WordPress tiene que adivinar cuál es esa imagen sin haberte visto navegar, y esa adivinanza falla más de lo que te gustaría.

La buena noticia es que ya existe una forma de que WordPress deje de adivinar el elemento inicial más pesado de tu página y lo sepa de verdad, a partir de datos reales de tus propios visitantes.

En este artículo te cuento qué es, qué gana tu web con ello, qué pegas tiene todavía, y qué hacer si prefieres quedarte con algo más probado mientras tanto.

Optimization Detective e Image Prioritizer

El núcleo de WordPress lleva desde la versión 6.3 detectando de forma automática cuál es probablemente la imagen del LCP, casi siempre la destacada, y le añade el atributo fetchpriority="high" sin que hagas nada.

El límite de esa detección automática es que se basa en heurísticas desde el servidor, reglas fijas que no saben cómo se ve realmente tu web en un móvil, en una tablet o con una ventana pequeña de escritorio.

Esas heurísticas aciertan la imagen correcta en torno a la mitad de las veces, mientras que la otra mitad, el navegador, recibe la orden de prioridad equivocada. Optimization Detective nace para resolver justo eso.

Es un plugin del equipo de rendimiento de WordPress que no optimiza nada por sí solo, es un framework que recoge datos reales de tus visitantes (o RUM, siglas de Real User Monitoring, monitorización de usuarios reales) sobre qué elemento se pinta primero en cada tipo de dispositivo.

No tiene pantalla de ajustes ni la va a tener, funciona solo, en segundo plano. El que hace algo con esos datos es Image Prioritizer, el plugin que depende de Optimization Detective para funcionar.

Con la información real de tus visitas, añade fetchpriority="high" a la imagen que de verdad es el LCP en cada punto de ruptura, ajusta la carga diferida para que no se quede vacío justo lo que sí se ve al entrar, y reduce el peso del fotograma inicial de los vídeos que hacen de LCP.

Anteriormente, Image Prioritizer también calculaba el atributo sizes de las imágenes responsive, pero ya no, esa función se quitó por un problema, y hoy ese trabajo lo hace otro plugin del mismo equipo, Enhanced Responsive Images.

¿Para cuándo estará esto en WordPress?

El equipo de rendimiento suele probar la funcionalidad completa en un plugin independiente, la validan con tráfico real de decenas de miles de webs, y cuando por fin entra en el núcleo, suele hacerlo con ajustes más prudentes que los que tenía el plugin original.

Ya te conté ese proceso con la carga especulativa nativa, que también nació como plugin, se probó en más de 50.000 sitios, con una mejora media del 1,9% en LCP en los que lo llevaban activado, y aterrizó en WordPress 6.8 con el modo prefetch y la anticipación más conservadora en vez del prerender y la anticipación moderada que traía el plugin.

El cálculo del atributo sizes para imágenes con carga diferida siguió un camino parecido hasta la versión 6.7.

Dicho esto, no hay fecha para Optimization Detective ni para Image Prioritizer. Ninguno de los dos aparece nombrado de momento en planes de futuras versiones, solo Enhanced Responsive Images y View Transitions figuran como trabajo del equipo de rendimiento en marcha hacia alguna versión de WordPress de las próximas.

Esa cosa es cojonuda ¿no? … pues no del todo

Antes de que instales los dos plugins unos cuantos peros que conviene que conozcas:

• Los dos siguen en beta: Optimization Detective en la 1.0.0-beta5 e Image Prioritizer en la 1.0.0-beta3, y ninguno tiene pantalla de ajustes.
• No deberías usar plugins canonical en webs en producción: Como cualquier plugin de este tipo su misión es terminar en el núcleo de WordPress y, aunque te corroa la impaciencia, no deberías usarlos como si fuesen plugins normales, nunca, ni estos ni ningún otro.
• Necesitas la API REST abierta a visitantes anónimos: Así es como se recogen los datos de cada visita. El propio plugin trae un aviso en Salud del sitio que te avisa si la tiene bloqueada, así que no te vas a quedar a ciegas. Si usas Vigilante con el modo de protección de la API REST más restrictivo, revisa que no le esté cerrando el paso a este plugin en concreto, o nunca vas a ver ninguna optimización aplicada sin saber por qué.
• No optimiza nada para ti como administrador: Hace falta que sean visitantes normales, así que no esperes ver cambios nada más activarlo, necesitas que pase tráfico real primero, para móvil y para escritorio.

¿Hago algo ya?

No hay una respuesta única, depende de cuánto te guste ir por delante y de cuánto tiempo le quieras dedicar, pero sobre todo teniendo en cuenta que si pruebas este tipo de plugins debe ser únicamente como experimentación.

Si no te importa que algo esté en beta y tienes tráfico suficiente para que se llenen de datos las visitas en pocos días, con todas las precauciones, instala Optimization Detective y Image Prioritizer, revisa el código fuente de tu web a los pocos días y compara.

Si prefieres no depender de tráfico acumulado ni de tener la API REST abierta a cualquiera, y quieres algo que ya lleva tiempo funcionando sin sorpresas hay plugins que sí puedes usar ya para optimizar WordPress.

¿De qué plugin estás hablando?

Sabes que hay muchos plugins de optimización, pero yo solo uso uno gratuito, DietPress, y este ya pone fetchpriority="low" a todas las imágenes menos la primera, sin mirar visitas ni dispositivos, una regla fija que sigue siendo mejor que lo que hace el núcleo por su cuenta con el resto de imágenes de la página, que es no hacer nada.

Pero esa regla fija y la lógica de Image Prioritizer, que decide con visitas reales por punto de ruptura, no siempre van a estar de acuerdo. Si en el móvil la imagen importante no es la primera del HTML, más habitual de lo que parece con maquetadores y avisos que se cuelan antes del contenido, tu plugin le estaría bajando la prioridad justo a la imagen a la que el otro se la quiere subir.

Lo tengo controlado, en cuanto Image Prioritizer deje la beta adaptaré DietPress para que no se pisen cuando se incorpore en WordPress, todavía no sé si apartándose cuando lo detecte o afinando la regla, pero se adapta, eso seguro.

Y si prefieres no tocar nada de esto todavía, tampoco pasa nada. Por el patrón que te contaba antes, es candidato real a acabar en el núcleo tarde o temprano, y cuando lo haga no vas a tener que instalar ni configurar nada, como pasó con la carga especulativa.

Elijas lo que elijas, tu web no tiene por qué seguir dependiendo de una adivinanza para saber cuál es su imagen más importante, y eso tarde o temprano juega a tu favor.

Si acabas probando alguno de los dos plugins, cuéntame qué tal te ha ido, aquí abajo en los comentarios tienes hueco.

Usar el software más extendido del planeta significa compartir también sus vulnerabilidades conocidas con la mitad de tus competidores.

Y esto no es solo un problema técnico, pues una brecha que exponga datos de clientes activa obligaciones legales concretas (en España, informar a la Agencia Española de Protección de Datos en un plazo de 72 horas), además de los costes de reputación y de recuperación del propio incidente.

Esta guía está organizada teniendo en cuenta por donde entran los distintos posibles ataques, que son cuatro grandes puertas, y en cada una encontrarás cómo entra el ataque, qué lo cierra (con soluciones gratuitas siempre que existen, que es casi siempre) y cómo comprobar que la puerta quedó cerrada.

Después encontrarás tres bloques transversales de distinta afectación, como son los riesgos propios de vender con WooCommerce, lo que te exige la ley aunque nadie te ataque, y el protocolo si ya han entrado.

Dicho todo esto, empezamos.

Puerta 1 – Las extensiones: por donde entra la inmensa mayoría de los ataques

El ataque típico contra un WordPress de empresa no lo lanza una persona contra tu web, lo lanza un bot contra millones de webs a la vez. El proceso es siempre parecido:

1. El bot rastrea internet buscando versiones concretas de plugins con vulnerabilidades publicadas.
2. Identifica la tuya por la huella que deja en el código fuente.
3. Explota el fallo (para el que suele existir exploit automatizado desde el mismo día del aviso).
4. Sube un pequeño archivo PHP a la carpeta de uploads que le da control remoto.
5. Crea un administrador con nombre discreto y empieza a inyectar redirecciones o spam SEO.

Tú no ves nada hasta que Google marca la web como comprometida o un cliente pregunta por qué al hacer clic en tu enlace acaba en una tienda de medicamentos que no es la tuya. Entre la infección y el descubrimiento pasan normalmente semanas.

Los números explican por qué esta puerta es la primera, y es que de todas las vulnerabilidades nuevas de WordPress la mayoría son del tipo XSS, que permite colar scripts ajenos en el navegador de tus visitantes.

Muy típico es el caso de los plugins abandonados, que no dejan de funcionar de golpe, siguen activos, y cada mes sin actualizarse acumulan más probabilidades de tener un fallo conocido que ya nadie va a parchear.

Y hay un agravante que es que WordPress.org cierra o retira plugins del repositorio con cierta regularidad por malware o vulnerabilidades sin corregir, y ese cierre no desinstala nada de tu servidor. El código sigue ahí, ejecutándose, y el aviso no te llega a ningún sitio salvo que lo busques activamente.

Esto mismo le pasó a un cliente mío con un plugin sencillo, una utilidad para mostrar imágenes del antes y el después, pero con una vulnerabilidad enorme, para la que me tocó preparar un parche, ante el abandono del plugin original.

Qué cierra esta puerta:

• Una política de actualizaciones por escrito: gratis y más eficaz que cualquier herramienta, con actualizaciones automáticas para versiones menores y plugins de confianza, prueba en staging para versiones mayores y plugins críticos (pasarela de pago, formularios, membresías), y cobertura semanal fija con copia de seguridad previa para todo lo demás.
• Una auditoría periódica de todo lo instalado: quién mantiene cada plugin y tema, cuándo se actualizó por última vez, si tiene vulnerabilidades conocidas en tu versión (consúltalo gratis en WPScan o Patchstack antes de instalar nada nuevo) y qué duplicidades funcionales puedes eliminar.
• Tolerancia cero con lo nulled o de procedencia desconocida, y decisión inmediata sobre cualquier extensión activa sin actualizaciones disponibles porque el desarrollador desapareció o la licencia caducó, pues eso es código congelado y sin parches, una decisión estratégica y no un detalle técnico.
• Desinstalar lo que no se usa, incluidos los temas de repuesto que se quedan «por si acaso», porque un tema desactivado sigue siendo código explotable presente en el servidor.
• Vigilancia diaria de los cierres del repositorio: Esta detección automática es, hoy por hoy, casi exclusiva de Vigilante, que consulta la API de wordpress.org cada día por cada plugin instalado, activo o no, y avisa con fecha y motivo si alguno ha sido cerrado o retirado.
• Un cortafuegos de aplicación como red de contención, activo desde el primer día aunque sea con la configuración por defecto, con esto bloqueas los patrones de explotación más comunes y la ejecución de PHP en la carpeta de uploads, de modo que frena el ataque incluso cuando el plugin vulnerable siga instalado.
• Ponérselo más difícil al escaneo automatizado: ocultar la versión de WordPress del código fuente, los feeds y las URL de scripts, y eliminar los readme.html y license.txt de la raíz, que la revelan a cualquiera.
• Si el tema es a medida, comprobar que usa tema hijo (un padre modificado directamente pierde los cambios en la próxima actualización) y que está claro quién paga y renueva cada licencia, además, documenta esa revisión con un informe como el que genera la auditoría de temas, te da la referencia para la siguiente.

Cómo comprobar que está cerrada:

• Abre el código fuente de tu portada y busca generator y ver=: si aparece tu versión exacta de WordPress, sigue visible.
• Sube un archivo PHP de prueba a la carpeta uploads por el medio que uses habitualmente e intenta ejecutarlo desde el navegador, debería devolver un error, no ejecutarse.
• Fecha de la última auditoría de extensiones y número de plugins desinstalados en ella: si la respuesta es «nunca» y «cero», ahí tienes el primer hueco.
• Comprueba que tu escáner de integridad tiene programada una exploración automática y cuándo fue la última.

Puerta 2 – Las personas y sus credenciales

La segunda puerta ni siquiera necesita una vulnerabilidad y es que WordPress regala por defecto la lista de nombres de usuario, puesto que su misma API REST responde en tudominio.com/wp-json/wp/v2/users a cualquiera que pregunte, y las URL del tipo ?author=1, ?author=2 redirigen al archivo público de cada autor.

Con esa lista y las colecciones de contraseñas filtradas que circulan por internet, un bot solo tiene que probar combinaciones en tu formulario de acceso, y si XML-RPC está activo puede probar cientos por petición gracias a su método system.multicall.

La otra variante ni siquiera requiere bots. Es el típico caso de la agencia de hace dos años que conserva un acceso de administrador, la cuenta compartida entre tres personas, el ex-compañero al que nadie dio de baja. El error humano, no un ataque brillante, es la causa más habitual de una brecha.

Qué cierra esta puerta:

• Identificación en dos pasos (2FA) obligatoria para todos los perfiles de editor para arriba, con aplicación de verificación (TOTP) o código por email, exigible por perfil desde tu plugin de seguridad.
• Mínimas capacidades con los perfiles por defecto (administrador, editor, autor, colaborador, suscriptor), creando un perfil a medida antes que subir a nadie a administrador por comodidad.
• Caducidad de contraseñas con historial que impida reutilizar las últimas, sobre todo en administradores, y límite de sesiones simultáneas por usuario si trabajas con externos que entran y salen de proyectos.
• Cierre de la enumeración y del XML-RPC desde tu plugin de seguridad o con código, y URL de acceso personalizada en lugar de /wp-login.php, que elimina la mayoría del tráfico automatizado contra el formulario.
• Un gestor de contraseñas con espacios compartidos por equipos (Bitwarden, por ejemplo, tiene versión gratuita para empezar y planes de equipo económicos), que acaba con las contraseñas en hojas de cálculo y en hilos de correo.
• Una lista de bajas para cuando alguien deja la empresa o termina un proyecto, donde reflejar quién tiene/tenía acceso a WordPress, panel del hosting, registrador del dominio, CDN, Search Console y cualquier servicio conectado. Un usuario por persona, con nombre real, o esta lista será imposible de aplicar.
• Un registro de auditoría que capture accesos, cambios de usuarios y activación de plugins, filtrable y exportable. Esto es lo que convierte «alguien tocó algo» en «este usuario hizo esto a esta hora».
• Formación básica del equipo: no reutilizar contraseñas, desconfiar de enlaces y adjuntos inesperados, saber a quién avisar ante algo raro, es gratis, y más rentable que cualquier herramienta.

Cómo comprobar que está cerrada:

• Visita por tu cuenta dominio.com/wp-json/wp/v2/users y dominio.com/?author=1: ninguna de las dos debería revelar nombres de usuario.
• Cuenta cuántos administradores hay y asegúrate, uno a uno, que de verdad lo necesitan.
• Busca cuentas sin acceso en los últimos seis meses y accesos de proyectos ya cerrados.
• Haz el simulacro de baja: si una persona concreta se fuera mañana, ¿cuántos servicios habría que tocar y tienes la lista?

Puerta 3 – El alojamiento y el servidor

La tercera puerta está fuera de WordPress. Aquí hablamos de que, por ejemplo, una versión de PHP al final de su vida útil deja de recibir parches de seguridad aunque todo lo demás esté al día.

Muy típico es también utilizar un hosting compartido sin aislamiento entre cuentas, lo que convierte el ataque al vecino en un ataque a tu web.

Otro caso habitual es un listado de directorios abierto, lo que permite a cualquiera pasearse por /wp-content/uploads/ y descargar lo que encuentre, y lo mismo pasa con permisos de archivo demasiado generosos, que dejan que un proceso comprometido escriba en wp-config.php o .htaccess, los dos archivos donde una sola línea inyectada sobrevive incluso a reinstalar WordPress.

Y hay un problema más en esta puerta, la disponibilidad, porque una caída también es un incidente y cuesta dinero. Según los cálculos que hice para una conferencia que di en GoDigital de Valencia en 2025, un e-commerce pequeño pierde entre 50 y 200 € por minuto caído, una web corporativa entre 20 y 50 contactos comerciales por hora, y un restaurante sin sistema de reservas entre 500 y 1.500 € por noche.

El día que tu web salga en televisión o una campaña funcione de verdad, la diferencia entre un hosting que escala y uno que se cae es facturación directa.

Qué cierra esta puerta:

• Un hosting que cumpla los mínimos exigibles: HTTP/2 o HTTP/3, versiones de PHP y MySQL o MariaDB actualizadas y cambiables por ti sin tiques de soporte, configuración de seguridad específica para WordPress, aislamiento real de cuentas incluso en planes compartidos, soporte técnico especializado en WordPress, recuperación automática ante caídas y capacidad de absorber picos de tráfico. Si el tuyo no los cumple cambiar de hosting es la medida de seguridad más rentable de esta sección.
• Tres constantes en wp-config.php (primer bloque de código más abajo): desactivan el editor de archivos, fuerzan HTTPS en el escritorio y evitan que los errores de PHP se muestren a los visitantes.
• HTTPS en todo el sitio con HSTS (segundo bloque de código de abajo), para que el navegador ni siquiera intente la conexión sin cifrar la próxima vez.
• El resto de cabeceras de seguridad (Content Security Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy), que puedes generar listas para Apache, Nginx o PHP con este generador de cabeceras gratuito.
• Permisos de archivo correctos: 644 para archivos, 755 para directorios, y 440 o 400 para wp-config.php si el hosting lo permite sin romper nada, además de Options -Indexes en el .htaccess para cerrar el listado de directorios.
• Un security.txt en /.well-known/ siguiendo el estándar RFC 9116, para que un investigador que encuentre un fallo sepa cómo avisarte de forma responsable en vez de publicarlo.
• Vigilancia de integridad de wp-config.php y .htaccess: tu plugin de seguridad debería guardar una copia de referencia con suma de verificación y avisarte con un diff línea a línea si algo cambia sin que hayas sido tú.
• Copias de seguridad verificadas y fuera del servidor: restaura una de prueba en un entorno aparte antes de necesitarla en serio, porque una copia alojada en la misma máquina que protege no vale nada el día que esa máquina falle.
• Monitorización de disponibilidad externa, para enterarte tú antes que tus clientes: servicios gratuitos como UptimeRobot comprueban la web cada cinco minutos y avisan por correo en cuanto deja de responder.

// Desactivar el editor nativo de plugins y temas
define( 'DISALLOW_FILE_EDIT', true );
 
// Forzar HTTPS en wp-admin
define( 'FORCE_SSL_ADMIN', true );
 
// Nunca mostrar errores a visitantes, solo registrarlos
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>
 
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

El reparto de responsabilidad con tu hosting conviene confirmarlo por escrito, porque la letra pequeña cambia mucho de un proveedor a otro:

Cómo comprobar que está cerrada:

• Pasa un análisis externo de cabeceras y exposición: el análisis de seguridad hace más de 30 comprobaciones gratis y al instante, sin instalar nada.
• Pregunta a tu hosting, por escrito, qué versión de PHP ejecutas y hasta cuándo recibe parches de seguridad.
• Restaura un backup de prueba en un entorno aparte al menos una vez por semestre y anota cuánto tardaste y si todo se restauró perfecto.
• Recuerda la última caída: ¿te avisó tu monitorización o te avisó un cliente?

Puerta 4 – El perímetro: dominio, correo y proveedores

La cuenta del registrador del dominio sin identificación en dos pasos es el secuestro perfecto pues quien la controle cambia las DNS y se lleva tu web, tu correo y tu marca a otro servidor, con tu WordPress intacto y perfectamente asegurado en el hosting de siempre.

El correo del dominio es la variante silenciosa ya que WordPress y WooCommerce envían correos transaccionales a diario, y un dominio sin DMARC puede ser suplantado por cualquiera para hacer phishing a tus propios clientes con tu remitente y tu marca, sin tocar un solo archivo tuyo.

Los proveedores externos (la agencia, el desarrollador puntual, el servicio conectado por API) son accesos más que habituales que rara vez están inventariados.

Qué cierra esta puerta:

• 2FA y bloqueo de transferencia en el registrador del dominio, hoy mismo: es la cuenta más valiosa de toda tu infraestructura y suele ser la menos protegida.
• Inventario de quién controla qué: dominio, zonas DNS, correo y cada servicio conectado, con un responsable con nombre por fila. Vale una hoja de cálculo, lo que no vale es que la respuesta sea «creo que lo llevaba el informático anterior».
• SPF, DKIM y DMARC en el dominio: el SPF declara qué servidores pueden enviar correo en tu nombre, el DKIM firma cada mensaje (lo genera tu proveedor de correo desde su panel, no es un registro que puedas copiar de una guía) y el DMARC dicta qué hacer con lo que no pase esas comprobaciones. Empieza con el DMARC en modo observación y endurece cuando los informes vengan limpios; tienes los registros de ejemplo más abajo.
• Registro de licencias con titular y fecha de renovación de cada tema y plugin de pago: una licencia que caduca sin que nadie lo sepa es código congelado, y eso te devuelve directo a la puerta 1.
• Acceso de proveedores por escrito: qué puede tocar cada uno, con qué cuenta y hasta cuándo, revocable el día que termina el proyecto. Esto además conecta con el contrato de encargo de tratamiento del bloque legal.

Registros de ejemplo, adaptando dominio y proveedor de correo a los tuyos:

; SPF: declara quien puede enviar correo por ti
; (el include depende de tu proveedor: este es el de Google Workspace)
tudominio.com.  TXT  "v=spf1 include:_spf.google.com ~all"
 
; DMARC, fase 1: solo observar, nada se bloquea todavia
; (recibiras informes de quien envia correo usando tu dominio)
_dmarc.tudominio.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@tudominio.com"
 
; DMARC, fase final tras unas semanas de informes limpios
; (p=quarantine como paso intermedio si prefieres endurecer poco a poco)
_dmarc.tudominio.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@tudominio.com"

Cómo comprobar que está cerrada:

• Consulta tu registro DMARC con cualquier comprobador gratuito (MXToolbox o dmarcian, por ejemplo): si no existe es que tu dominio es suplantable desde ayer.
• Entra en la cuenta del registrador y verifica dos cosas: que pide segundo factor y que el bloqueo de transferencia está activo.
• Abre el inventario de accesos y licencias: si no existe, esa es la tarea urgente de esta semana.

Tiendas online con WordPress – Riesgos específicos de WooCommerce

El ataque más frecuente contra un WooCommerce pequeño no busca robarte, busca usarte. Me refiero a bots que prueban tarjetas robadas en tu pasarela de pago (lo que se conoce como card testing) haciendo cientos de micropedidos que a ti te generan comisiones por transacción fallida, disputas y, si se acumulan, la suspensión de la cuenta en la pasarela.

La segunda variante es el registro masivo de cuentas falsas, que ensucia tu base de clientes y prepara fraudes posteriores.

Y la tercera no es un ataque sino una acumulación. Cada pedido guarda datos personales, y una base con años de pedidos completos es superficie expuesta el día de una brecha y responsabilidad directa ante el RGPD.

Qué lo cierra, todo gratis:

• Verificación antibots en el pago y el registro: Cloudflare Turnstile es gratuito y menos molesto que un captcha clásico, y la mayoría de plugins de formularios y de seguridad lo integran.
• Límite de intentos de pago por IP y por sesión, desde el cortafuegos de tu plugin de seguridad o desde la propia pasarela, que suele incluir reglas antifraude configurables sin coste.
• Revisión semanal de patrones de fraude: rachas de pedidos fallidos de importe mínimo, muchas cuentas nuevas sin compra asociada, picos de registro a horas extrañas.
• Retención de datos con caducidad: WooCommerce trae herramientas de limpieza y anonimizado en «Ajustes → Cuentas y privacidad». Configúralas y deja de acumular pedidos identificables de hace cinco años que ya no necesitas.

Cómo comprobar que está cerrada:

• Consulta en el panel de tu pasarela la proporción de transacciones rechazadas del último mes: si supera con claridad a la de meses anteriores, ya te están usando.
• Cuenta las cuentas de cliente creadas en los últimos 30 días sin ningún pedido asociado.
• Abre un pedido de hace tres años y mira qué datos personales sigue guardando.

Obligaciones legales y de privacidad siempre aplicables

Si tu WordPress recoge datos personales de clientes, usuarios registrados o simples visitantes que rellenan un formulario, estás sujeto al RGPD y a la Ley Orgánica de Protección de Datos, con independencia del tamaño de la empresa.

El RGPD exige aplicar medidas de seguridad adecuadas al riesgo, así que una brecha de seguridad es casi siempre también una brecha de protección de datos, con plazos y sanciones concretos.

La notificación a la AEPD debe hacerse en un máximo de 72 horas, con multas de hasta 10 millones de euros o el 2 % de la facturación para las infracciones graves (entre ellas, no notificar a tiempo) y de hasta 20 millones o el 4 % para las más graves.

Las sanciones a autónomos y pymes suelen moverse en varios miles de euros, lejos de los titulares millonarios pero suficientes para hacerte un agujero importante.

Qué hacer:

• Documenta cualquier incidente de seguridad, aunque decidas no notificarlo: el RGPD exige registrar internamente el análisis que llevó a esa decisión, precisamente para poder demostrarlo si la AEPD pregunta.
• Deja por escrito, en un contrato de encargo de tratamiento, quién es el responsable y quién el encargado cuando trabajas con una agencia o un servicio externo.
• Aplica minimización de datos: no guardes en formularios ni en la base de datos más datos personales de los estrictamente necesarios, porque cada campo de más es superficie expuesta de más el día que algo falle.
• Revisa avisos de cookies y política de privacidad con regularidad: están entre los motivos más frecuentes de sanción a pequeños negocios, haya habido o no una brecha técnica.
• Interioriza el plazo de las 72 horas antes de que ocurra un incidente, no durante: es la diferencia entre reaccionar con un protocolo decidido o improvisar bajo presión legal además de técnica.

Nada de esto sustituye el asesoramiento de un abogado especializado si la empresa maneja datos sensibles o de gran volumen.

Si ya te han entrado – Protocolo de las primeras horas

Aun con las cuatro puertas cerradas, un incidente sigue siendo posible, y cómo se reaccione en las primeras horas determina si se queda en un susto contenido o se convierte en una crisis larga.

Las señales de que algo va mal serían estas:

• Contenido, páginas o redirecciones que nadie de tu equipo ha creado.
• Picos de tráfico extraños, sobre todo dirigidos al login o al área de administración.
• Usuarios, plugins o temas nuevos que no reconoces.
• Entradas de registro anómalas: intentos de acceso repetidos, direcciones IP desconocidas, archivos modificados sin explicación.
• Avisos del navegador, de Google Search Console o de tu propio hosting marcando el sitio como inseguro o con malware.

Si aparece cualquiera de esas señales, el orden es importante:

1. Aísla el sitio: Activa el modo mantenimiento o restringe el acceso público mientras investigas, y si tu plugin de seguridad incluye un modo de emergencia con desafío para visitantes, es el momento de activarlo. El objetivo es frenar el daño sin perder lo que necesitarás analizar después.
2. Comunica con transparencia: en paralelo a la parte técnica, a quien pueda verse afectado. Tener el mensaje redactado de antemano evita improvisar bajo presión; en esta recopilación de recursos gratuitos tienes plantillas de comunicación de crisis, una lista de comprobaciones de acción inmediata y la calculadora de coste de caída con la que salen las cifras de la puerta 3 que te contaba antes.
3. Conserva una copia del estado comprometido antes de tocar nada, útil tanto para el análisis técnico como para una eventual denuncia o parte al seguro.
4. Restaura desde la copia de seguridad limpia más reciente, verificada y anterior al momento de la brecha.
5. Cambia todas las credenciales: contraseñas de todos los usuarios, no solo del administrador, además de las claves de la base de datos, las de API de servicios conectados y las de acceso al hosting y al registrador.
6. Ejecuta un escaneo completo de malware e integridad de archivos para confirmar que no queda ningún resto: puertas traseras, archivos añadidos o código inyectado que la restauración no haya eliminado.
7. Identifica y corrige la causa raíz (el plugin desactualizado, la contraseña débil, el permiso mal configurado) antes de volver a publicar, o el ataque se repetirá en cuanto el sitio vuelva a estar visible.
8. Evalúa la obligación de notificar a la AEPD y a los afectados si hay datos personales comprometidos, dentro del plazo de 72 horas.

Si la gestión del incidente supera la capacidad del equipo, o si el sitio maneja datos sensibles o pagos, merece la pena contar con apoyo externo especializado en recuperación de webs hackeadas, sea el mío, el de Sucuri como referencia internacional de pago o el equipo de seguridad de tu propio hosting si lo tiene, porque el tiempo que se ahorra evitando errores en caliente suele compensar el coste del servicio.

Con qué aplicarlo – Plugins y servicios recomendados

A lo largo de la guía he escrito varias veces «tu plugin de seguridad» sin concretar cuál, y toca hacerlo. Las opciones serias del mercado gratuito son Vigilante, Wordfence, Kadence Security y SG Security, que comparé función a función en este análisis de plugins de seguridad.

Vigilante es mío y lo uso en mis webs y en las de mis clientes, así que ya conoces el sesgo y puedes descontarlo, aunque cualquiera de los otros cumple razonablemente si se configura bien y se revisa a conciencia.

Además, te recomiendo llevar un registro de todo consentimiento que se haga en tu web, y como para esta necesidad no había nada suficientemente completo creé estos plugins, que como todos están disponibles gratis en WordPress.org o tu instalador de plugins:

• Registro de consentimientos de términos y condiciones: para llevar un registro legal de todos los consentimientos que pides en tu web, totalmente integrado con los ajustes de privacidad de WordPress.
• Cumplimiento del derecho de desistimiento de la UE: todo lo que necesitas, con tienda o sin ella, para registrar y cumplir con el derecho a desistimiento.

La otra decisión es quién aplica todo esto, si alguien de dentro o un servicio externo. Si decides delegarlo, sea en una agencia de confianza, en el plan de cuidado de algunos hostings gestionados o en un servicio de mantenimiento especializado como el que ofrezco yo mismo, exige que cubra como mínimo:

• La política de actualizaciones de la puerta 1, con prueba en staging y copia previa.
• Copias de seguridad verificadas, con restauración de prueba periódica y almacenadas fuera del servidor.
• Monitorización de disponibilidad e integridad con avisos, no solo un informe mensual.
• Revisión periódica de accesos, usuarios y extensiones instaladas.
• Protocolo de incidentes por escrito, con tiempos de respuesta comprometidos.

Con esa lista delante puedes evaluar cualquier presupuesto, incluido el mío. Un servicio que no restaura copias de prueba ni revisa accesos no está manteniendo tu web por mucho que actualice plugins.

Plan de arranque – Por dónde empezar

Si no tienes ninguna pieza de esta guía montada todavía, no intentes cerrarlo todo el mismo día. Este orden da más protección por minuto invertido:

1. Activa 2FA en WordPress para administradores y editores, y en la cuenta del registrador del dominio.
2. Fuerza contraseñas largas con caducidad, elimina usuarios del tipo admin o test, y pon en marcha el gestor de contraseñas de equipo.
3. Cierra la enumeración de usuarios, cambia la URL de acceso y desactiva XML-RPC si no lo usas.
4. Activa cortafuegos y escáner de integridad, aunque sea con la configuración por defecto del primer día.
5. Audita plugins y temas, desinstala lo que sobre y deja por escrito la política de actualizaciones.
6. Fuerza HTTPS en todo el sitio, revisa permisos de archivo y publica un security.txt.
7. Restaura un backup de prueba y saca las copias del servidor.
8. Publica DMARC en modo observación y comprueba tu SPF.
9. Verifica que tu hosting cumple los mínimos de la puerta 3 y activa la monitorización externa.
10. Documenta el protocolo de brechas (con las 72 horas de la AEPD dentro), prepara la plantilla de comunicación y forma al equipo en lo básico.

Y una advertencia final, nada de esta lista es tarea para realizar una sola vez. Agenda las revisiones (trimestral para accesos y extensiones, semestral para restaurar un backup de prueba) y trata la seguridad como lo que es, mantenimiento continuo y no un proyecto con fecha de fin.

O sea, que si le cierro el paso a los rastreadores de inteligencia artificial que me entran en la web, ¿me estoy protegiendo o  pegando un tiro en el pie con el SEO y con mi visibilidad en las propias IA?

Es una pregunta de las buenas, y casi todo el mundo la responde mal por dos motivos.

El primero es porque confunde declarar con bloquear, que no es lo mismo, una cosa es pedirle al bot que no lo haga y otra impedírselo de verdad, y luego está el hecho de que se decide a la brava, sin pararse a pensar qué le cuesta eso al posicionamiento.

Vamos a ponerlo en orden, con datos, y en mi opinión (y experiencia) son cuatro pasos:

1. Analizar qué puedes hacer y cómo se aplica cada cosa
2. Saber (realmente) a qué hacen caso las IA y a qué no.
3. Lo más importante, razonar si a ti te conviene para el SEO y en qué casos.
4. Y al final, con toda la información en la mano, decidir qué haces con tu web.

Vamos a verlo con calma.

Ah ¿pero se puede bloquear a las IAs?

Antes de decidir conviene saber qué tienes disponible, porque es más de lo que crees y no todo hace lo mismo. Y hay una línea que lo separa todo, porque unas acciones declaran tu voluntad (solo surten efecto si el bot decide respetarlas) y otras bloquean de verdad (impiden el acceso, lo respete o no).

Con esa idea clara esto es lo que hay.

Señales declarativas (piden, no obligan)

¿En serio hace falta que recuerde esto? Ah ¿que sí?, pues nada, uy perdón …

• El Disallow del robots.txt: Le dices a un bot, por su nombre, que no rastree tu web o ciertas partes. Aquí dentro entra también el Google-Extended, que no es más que un Disallow para el token con el que Google controla el entrenamiento de Gemini.
• El noai y el noimageai: Dos etiquetas en la cabecera de tu web que declaran «no me uses para entrenar, ni el texto ni las imágenes».
• Las Content Signals: Una técnica distinta y más fina, que va en el robots.txt y que en vez de bloquear a un bot separa para qué autorizas tu contenido y para qué no, y que además puede llevar respaldo legal. La vemos aparte, que tiene lo suyo.

Bloqueo real y efectivo (impide de verdad)

Aquí quería llegar yo…

• El 403. Le devuelves al bot un «prohibido» desde PHP, desde el .htaccess o desde un firewall, y no ve absolutamente nada. Esto no pide, esto impide.

Espera que hay más

Y dos caminos más que no son ni bloquear ni dejar pasar, y que mucha gente ni se plantea:

• Cobrar por el acceso, con la cabecera 402 y el protocolo x402.
• Adelantarte, asegurándote de que, cuando te compartan con una IA, tu web vaya siempre como fuente.

¿Le damos ya?, que esto era solo la lista, la chicha de cada cosa la explico ahora.

Cómo se bloquea a las IAs

A las manos en la masa. El «cómo» de cada cosa, con código si te va lo artesano y con plugin si prefieres no tocar nada. Y sí, varios plugins son míos, porque los hice justo para esto, así que perdona el autobombo, pero es que vienen al pelo.

El Disallow en el robots.txt (con el Google-Extended dentro)

A mano, en tu robots.txt:

User-agent: GPTBot
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Google-Extended
Disallow: /

Fíjate en que el Google-Extended es un Disallow más, solo que especial, porque bloquearlo evita que Google te use para entrenar Gemini sin sacarte de las búsquedas, sigues apareciendo igual.

Lo anterior, por supuesto, es solo un ejemplo, aquí tienes una lista bastante más completa de bots de IA a los que hacer Disallow (o no)

Si no te quieres pelear con el fichero, tanto mi plugin Visibility como VigIA te añaden el Disallow a los principales bots de IA con un par de clics.

Las metas noai y el noimageai

En la cabecera de tu web, así:

<meta name="robots" content="noai, noimageai">

Es una declaración de intenciones contra el entrenamiento de las IAs, nacida en DeviantArt en 2022, que no es un estándar oficial de nada, así que vale para el bot que quiera respetarla y para nada frente al que no.

El plugin AI Content Signals las añade (si quieres) sin tocar código ni complicarte.

Las Content Signals (y su respaldo legal)

Las Content Signals también van en el robots.txt, pero en vez de decirle a un bot que no entre, declaran para qué usos autorizas tu contenido y para cuáles no, separando tres cosas distintas:

• search: construir un índice de búsqueda y mostrar resultados (enlaces y extractos cortos), sin incluir los resúmenes generados por IA.
• ai-input: meter tu contenido en modelos de IA en tiempo real, lo que se llama RAG o grounding, las respuestas de búsqueda con IA.
• ai-train: entrenar o afinar los modelos.

Un ejemplo de «buscar sí, entrenar no» quedaría así:

User-agent: *
Content-Signal: search=yes, ai-train=no

¿Y dónde está la gracia de verdad? Pues en que esto no es solo una petición, es una reserva expresa de derechos con base legal.

El plugin AI Content Signals que te comenté en el apartado anterior añade además al robots.txt una declaración que ampara esas señales en el artículo 4 de la Directiva europea 2019/790 de derechos de autor, la que permite a los autores reservarse su contenido frente a la minería de textos y datos, que es, ni más ni menos, lo que hace el entrenamiento de las IA.

O sea, que ya no solo le pides al bot que se porte, le recuerdas que hay una ley europea detrás que protege tu contenido. Te lo conté a fondo en mi artículo sobre las Content Signals, por si quieres seguir informándote de esto.

El bloqueo con 403 por .htaccess o por PHP

Cuando la declaración no basta toca el bloqueo de verdad, cortando por User-agent desde .htaccess:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (Bytespider|PerplexityBot|CCBot) [NC]
RewriteRule .* - [F,L]

O desde PHP, en tu propio plugin o como suelas añadir códigos a tu web:

function ayudawp_bloquear_bots_ia() {
    $ua = isset( $_SERVER['HTTP_USER_AGENT'] ) ? $_SERVER['HTTP_USER_AGENT'] : '';
    if ( $ua && preg_match( '#Bytespider|PerplexityBot|CCBot#i', $ua ) ) {
        status_header( 403 );
        exit;
    }
}
add_action( 'init', 'ayudawp_bloquear_bots_ia' );

Y aquí, de nuevo, VigIA te lo da hecho, porque bloquea de verdad por PHP a los bots que tú elijas, por IP o por User-agent.

Lo mejor de todo es que te da todas las capas, así que puedes probar con el Disallow, y cuando compruebes que no le hacen ni caso, además de aprender en carne propia, con un clic puedes bloquearlos, y también ahí comprobar que eso sí funciona (garantizado).

Para lo más bruto y lejos de tu web de todo, un cortafuegos (un WAF, como el de Cloudflare), que es el único que frena hasta a los que maquillan el User-agent o cambian dinámicamente de IP.

Y en vez de bloquear a las IA ¿puedo cobrarles o alguna otra cosa?

Pues sí ,es posible, y quizás son las que más interesante de cara al futuro.

Cobrar por el acceso: 402 y x402

Existe una cabecera HTTP, la 402 Payment Required, que llevaba décadas casi de adorno y que ahora empieza a cobrar sentido, pues en vez de decirle a la IA que no, le dices «sírvete, pero pagando».

Sobre esa idea se está montando el protocolo x402, para que los bots paguen por rastrearte de forma automática, y Cloudflare ya está levantando su mercado de pago por rastreo.

No es ciencia ficción, te lo he contado en detalle en mis artículos sobre la cabecera 402 y sobre x402, porque es, hoy o mañana, otra opción real para el dueño de una web que no quiere ni regalar su contenido ni renunciar del todo a las IA.

Adelantarte a veces es inevitable, ya puestos que te lleven siempre de fuente

Esta sería la forma más proactiva de todas, porque en vez de solo defenderte juegas al ataque. La gente va a compartir tu contenido con las IA quieras o no, así que al menos que lo haga citando tu web como fuente.

Eso es justo lo que hace el plugin AI Share & Summarize, que añade botones para resumir y compartir tu contenido en ChatGPT, Claude, Perplexity y demás IAs, y cada vez que un lector los usa, el mensaje que se manda a la IA lleva tu URL como origen.

También va un paso más allá y te permite usar la IA para que los usuarios no abandonen tu web para usar la IA ¿flipas verdad?

Básicamente puedes ofrecer resúmenes de tu contenido para, a modo de extracto, generado con tu IA favorita, así les animas a seguir leyendo, sin que dejen de sentir ese calorcito especial que da la IA.

De paso te da analítica de esos clics, que no viene nada mal, lo tienes explicado en mi artículo sobre los resúmenes con IA integrados.

¿A qué hacen caso las IA y a qué no?

Por resumir, recuerda que las señales (el Disallow, el noai, las Content Signals) declaran, y solo surten efecto si el bot decide respetarlas, el 403 bloquea de verdad, lo respete o no.

Los hay que hacen caso, que conste. Sin ir más lejos, esta semana le pedí a mi IA de cabecera (sí, es Claude Code) que me leyera un artículo de ZDNet para recopilar documentarme para los vídeos que hago en YouTube y me dijo que no podía, que ese dominio estaba vetado en su herramienta ¿mande?

Pues resulta que quien opera estas herramientas mantiene una lista de webs que no rastrea, casi siempre por motivos legales, para respetar a editores que han restringido el acceso de las IA o que están directamente en pleitos con ellas.

Y casualmente ZDNet es de Ziff Davis, que demandó a OpenAI en abril de 2025 justo por usar su contenido para entrenar y para alimentar respuestas, así que encaja como un guante.

No tengo acceso a la lista ni al motivo exacto de cada web, pero la idea es esa, y conviene saberla, que a veces la IA no te lee porque legalmente no puede.

El bot más activo de ChatGPT (ChatGPT-User) también se porta razonablemente bien, lee tu robots.txt y para si le dices que no.

El problema son todos los demás.

En agosto de 2025 Cloudflare pilló a Perplexity saltándose las señales a base de cambiar de identidad, rotar direcciones IP y disfrazarse de un navegador normal para colarse en webs que le habían dicho que no. Y yo que tenía en un altar a Perplexity, ¡qué decepción!

Y el Bytespider de ByteDance ignora el robots.txt cuando le da la gana, vamos, siempre. Resumiendo, que fiarte solo de las señales es fiarte de la buena voluntad de cada bot, uno por uno, y ya ves que no todos la tienen.

¿Y cómo sabes tú en cuál de los dos grupos está cada bicho que te visita? Aquí es donde VigIA tiene algo que decir, porque trae una herramienta hecha justo para esto: comprueba si los bots respetan de verdad el Disallow que les has puesto.

Si pillas a una IA pasando de ti, con el mismo VigIA le aplicas el bloqueo por PHP. Declarar, comprobar y, solo si hace falta, bloquear, todo en el mismo sitio y sin adivinar, con datos reales, que de esto falta mucho en todo este tema de las IAs, hay mucho iluminado pero los negocios viven/vivimos de realidades ¿o no?.

¿Y a ti te conviene bloquear? el SEO y AEO

Vale, ya sabes qué puedes hacer y a qué hacen caso. Ahora lo que de verdad nos quita el sueño, que es de donde viene la duda de si conviene bloquear a las IA para el SEO, o nos estamos cerrando una puerta que no deberíamos cerrar.

La pregunta buena no es ¿bloqueo las IA, sí o no?, es más fina, sería algo más como ¿quieres seguir saliendo en los buscadores y en las respuestas de las IA, pero a la vez impedir que usen tu contenido para entrenar sus modelos?

Parece rebuscado, algunos pensarán que imposible, pero no, porque eso, hoy, se puede separar, y ahí está casi toda la chicha, donde podemos poner un poco de orden y control en todo este mejunje.

La clave para entenderlo es que el AEO y el GEO, eso de posicionarte en las respuestas de la IA, siguen siendo SEO. No lo digo yo, lo dice la propia guía de optimización para IA de Google, pues las AI Overviews y el AI Mode se apoyan en su mismo sistema de posicionamiento y calidad de siempre.

O sea, que las mismas señales que te hacen posicionar son las que hacen que te citen en las respuestas con IA. Y ahora ata cabos, que si le impides el paso a los bots que recuperan tu contenido para buscar y citar, dejas de salir en esas respuestas, y el hueco lo ocupa tu competencia.

Y esto no es una teoría mía, ya hay datos. Alrededor del 80 % de los grandes medios de noticias ya bloquean al menos un bot de entrenamiento, y un 70 % bloquea también los bots que recuperan contenido para citar en las IA.

¿El resultado? Pues varios estudios apuntan a que esos mismos medios se están quedando fuera de las respuestas de la IA y perdiendo visibilidad justo por bloquear a la brava. Se protegen de una cosa y se disparan en el pie con la otra, así que la cosa está en saber qué y cuándo bloquear.

Cuándo bloquear SÍ tiene sentido

Que quede claro que no todo es dejar pasar. Bloquear compensa, y mucho, cuando proteger tu contenido pesa más que la visibilidad. Ejemplos de esto:

• Contenido propietario o sensible, eso que te diferencia de verdad de la competencia.
• Contenido de pago, para miembros, cursos o zonas privadas.
• Datos únicos que son tu negocio, como los precios o las fichas de una tienda que no quieres que acaben en el buscador de otro.
• Sitios con obligaciones de cumplimiento estrictas.
• Y el caso de los editores que, sencillamente, no quieren regalar su trabajo para entrenar modelos y prefieren pelear por que les paguen, ahí es donde entra lo del 402 y el x402 de antes.

Cuándo bloquear sería un grave error

Y al revés, si tu web vive de que te encuentren y te citen, impedir el paso a los bots de búsqueda de IA es de las peores ideas que puedes tener.

Hablo de blogs, webs de empresa, guías, contenido informativo, marca personal, todo eso que se alimenta de visibilidad y autoridad.

Ahí cada cita en una IA es un ladrillo más de tu reputación, y cerrarles el paso es quedarte fuera del escaparate donde ahora busca la gente. Y para que te citen bien, el contenido tiene que merecer la cita, que es el E-E-A-T de toda la vida.

Hay un motivo aparte, eso sí, que vale para cualquiera, y me refiero al coste de rastreo.

Estos bots rastrean a lo bestia, y según datos de Cloudflare hay rastreadores de IA que piden decenas de miles de páginas de tu web por cada mísera visita que te devuelven.

Eso es factura de servidor, así que si uno te está reventando el hosting tienes todo el derecho a pararlo aunque el SEO te diga otra cosa.

¿Y surte efecto bloquear? Pues depende de a quién.

Los bots decentes que respetan las señales pararán en cuanto se lo pidas, los que ignoran el robots.txt necesitan el 403. Y a los que se disfrazan, como vimos con Perplexity, ni el bloqueo por user-agent los para del todo, ahí solo un firewall en condiciones les corta el acceso de verdad.

El método tiene que estar adaptado al bot, no hay una bala de plata.

La decisión, con todo en la mano

Con todo esto ya puedes decidir sin agobios, y el orden sensato es este, justo al revés de lo que hace casi todo el mundo:

1. Primero mide: Con VigIA (o con los logs de tu servidor), mira quién te rastrea, si respeta tus señales y cuánto te cuesta. Sin este paso vas a ciegas.
2. Clasifica según el bot y según tu contenido: A los de búsqueda y cita, déjalos pasar si vives de la visibilidad. A los de entrenamiento, ponles la señal. A los que te sangran el servidor o pasan de ti, bloqueo.
3. Aplica el nivel justo: Declaración para el que la respeta, bloqueo para el que no. Y valora si, en vez de bloquear, te compensa cobrar o adelantarte con la atribución.
4. Revisa tu estrategia a menudo: Que esto cambia a toda velocidad, y el bot que hoy no te aporta nada, mañana puede ser tu principal fuente de visitas.

«Bueno, vale, ¿pero qué hago?»

Te veo venir, porque es justo donde te quedas después de tragarte todo esto: «vale, Fernando, ya sé cómo decirle a la IA que no me lea, de varias maneras, y sé qué funciona y qué no, pero yo, con mi web, ¿qué hago?».

Pues para ayudarte a poner orden en la decisión, te lo dejo en una tabla, y luego mi consejo.

Si miras la tabla entera, la lógica salta sola, pues casi todo lo que de verdad quieres (que no te entrenen) lo consigues con señales que no tocan tu SEO, y el bloqueo efectivo lo guardas para los que ignoran tus normas o solo consumen recursos del servidor.

Lo único que te cuesta visibilidad de verdad es impedir el paso a los bots de búsqueda, así que ese error no lo cometas sin querer.

Mi consejo, por si te sirve

Para la web típica, la de contenido, servicios o marca, mi posición es deja pasar a los bots de búsqueda (search) y de cita (assistant), que te interesa muchísimo que las IA te lean y te nombren.

Además, declarar con las Content Signals y el noai que no te entrenen, medir con VigIA quién te respeta, y bloquear de verdad solo a los que ignoran tus normas o te ponen a prueba el hosting.

Además, estoy muy a favor de limitarte solo en defenderte, a ir a por la atribución, que las IA te van a leer igual y más vale que te lleven de fuente.

Si en cambio tu negocio es contenido propietario, de pago o datos únicos, ahí sí, bloquea lo que haga falta y con menos remordimientos, o plantéate cobrar por el acceso.

Porque al final esto va de lo de siempre, de que hemos pasado de ser dueños de nuestro contenido a andar negociando quién lo lee, para qué y a cambio de qué.

Tu web es tuya y la decisión también, faltaría más, pero tómala con los datos delante y sabiendo qué es una declaración y qué es un bloqueo efectivo, que es justo lo que casi nadie te cuenta.

Si quieres seguir tirando del hilo, tengo más escrito sobre visibilidad en las IA, sobre el llms.txt y sobre cómo posicionar en las AI Overviews de Google, donde seguro que atas algún cabo más.

Y si lo ves de otra manera, o me quieres contar cómo lo llevas en tu web, me tienes ahí abajo, en la sección de comentarios, que para eso están.

Pues bien, resulta que ahí tienes el problema delante y no lo estás viendo, porque el tiempo no siempre se va en la base de datos.

Que conste, la mayoría de las veces que algo va lento la culpable sí es la base de datos, en eso llevas razón y por eso conviene empezar por ahí con la guía para optimizar las consultas SQL.

Pero cuando las consultas están limpias y la cosa se sigue arrastrando el tiempo de carga se te está yendo en otro sitio, en PHP puro, en un plugin que hace un bucle a lo bestia, en una llamada a una API externa metida dentro de un hook, en un render que se atasca.

Y no, eso en las consultas no sale.

Para medirlo con detalle existe el comando wp profile, que reparte el tiempo de carga por fases, pero necesita SSH y línea de comandos, y en un alojamiento compartido normal ni lo tienes ni te dejan tocarlo.

Así que aquí va la versión casera, un mu-plugin que te dice, al final de cada página, cuánto tiempo se ha ido en cada tramo de la carga. Sin consola, y solo lo ves solo tú.

Midiendo los tiempos de carga de una página web por fases

La carga de WordPress no es un bloque, son fases encadenadas, primero se cargan los plugins, luego arranca el tema, después se dispara init, viene la consulta principal y al final el render de la página.

La idea es poner un cronómetro en cada uno de esos pasos para ver en cuál se atasca la cosa.

Crea un archivo, por ejemplo ayudawp-phase-timer.php, y súbelo a la carpeta /wp-content/mu-plugins/ (si no existe la creas tú, es una carpeta normal y corriente).

Los mu-plugins ya sabrás se ejecutan solos y antes que todo lo demás, que es justo lo que necesitamos para cronometrar desde el arranque.

En fin, que este es el nene:

<?php
/**
* Plugin Name: Load Phase Timer
* Plugin URI: https://ayudawp.com/
* Description: Solo para admins: muestra los momentos en los que el tiempo real se solapa con el ciclo de carga de WordPress. Herramienta de diagnóstico, eliminar tras su uso.
* Version: 1.0.0
* Author: Fernando Tellado
* Author URI: https://tellado.es
 */

// Evitar el acceso directo
defined( 'ABSPATH' ) || exit;

// Solo se ejecuta cuando se activa explícitamente, para evitar una sobrecarga en el uso habitual
// Activar definiendo AYUDAWP_PHASE_TIMER como true in wp-config.php
if ( ! defined( 'AYUDAWP_PHASE_TIMER' ) || ! AYUDAWP_PHASE_TIMER ) {
	return;
}

// Una marca temporal por cada paso del ciclo
$GLOBALS['ayudawp_phase_marks'] = array();

// Ancla al inicio de la solicitud real, definida por PHP incluso antes de que se cargue WordPress
$GLOBALS['ayudawp_phase_marks']['request_start'] = isset( $_SERVER['REQUEST_TIME_FLOAT'] )
	? (float) $_SERVER['REQUEST_TIME_FLOAT']
	: microtime( true );

// Momento en que este mu-plugin empieza a ejecutarse
$GLOBALS['ayudawp_phase_marks']['muplugins_start'] = microtime( true );

/**
 * Registra el tiempo real de cada paso
 */
function ayudawp_mark_phase( $name ) {
	$GLOBALS['ayudawp_phase_marks'][ $name ] = microtime( true );
}

// Marca temporal de cada paso del ciclo de carga, en orden
add_action( 'muplugins_loaded',  function () { ayudawp_mark_phase( 'muplugins_loaded' ); },  0 );
add_action( 'plugins_loaded',    function () { ayudawp_mark_phase( 'plugins_loaded' ); },    0 );
add_action( 'after_setup_theme', function () { ayudawp_mark_phase( 'after_setup_theme' ); }, 0 );
add_action( 'init',              function () { ayudawp_mark_phase( 'init' ); },              0 );
add_action( 'wp_loaded',         function () { ayudawp_mark_phase( 'wp_loaded' ); },         0 );
add_action( 'template_redirect', function () { ayudawp_mark_phase( 'template_redirect' ); }, 0 );

// Al final de la solicitud muestra el informe (solo admins)
add_action( 'shutdown', 'ayudawp_print_phase_report', PHP_INT_MAX );

/**
 * Genera y muestra el desglose por fases como comentario HTML, solo para admins
 */
function ayudawp_print_phase_report() {

	// Nunca expone tiempos internos a visitantes
	if ( ! function_exists( 'current_user_can' ) || ! current_user_can( 'manage_options' ) ) {
		return;
	}

	ayudawp_mark_phase( 'shutdown' );
	$marks = $GLOBALS['ayudawp_phase_marks'];

	// Etiqueta para humanos => [ from milestone, to milestone ]. Cadena contigua
	$phases = array(
		'Antes de WordPress (arranque PHP)' => array( 'request_start', 'muplugins_start' ),
		'Carga de mu-plugins'               => array( 'muplugins_start', 'muplugins_loaded' ),
		'Carga de plugins'                  => array( 'muplugins_loaded', 'plugins_loaded' ),
		'Arranque del tema'                 => array( 'plugins_loaded', 'after_setup_theme' ),
		'Hasta init'                        => array( 'after_setup_theme', 'init' ),
		'De init a wp_loaded'               => array( 'init', 'wp_loaded' ),
		'Consulta principal'                => array( 'wp_loaded', 'template_redirect' ),
		'Render y salida'                   => array( 'template_redirect', 'shutdown' ),
	);

	$total = ( $marks['shutdown'] - $marks['request_start'] ) * 1000;

	$lines   = array();
	$lines[] = 'AyudaWP Load Phase Timer';
	$lines[] = 'URL: ' . ( isset( $_SERVER['REQUEST_URI'] ) ? esc_html( wp_unslash( $_SERVER['REQUEST_URI'] ) ) : 'n/a' );
	$lines[] = str_repeat( '-', 52 );

	foreach ( $phases as $label => $pair ) {
		list( $from, $to ) = $pair;

		// Omite fases cuyos pasos no se hayan activado (p.ej. template_redirect en wp-admin)
		if ( ! isset( $marks[ $from ], $marks[ $to ] ) ) {
			continue;
		}

		$ms  = ( $marks[ $to ] - $marks[ $from ] ) * 1000;
		$pct = $total > 0 ? ( $ms / $total ) * 100 : 0;
		$lines[] = sprintf( '%-38s %8.1f ms  %5.1f%%', $label, $ms, $pct );
	}

	$lines[] = str_repeat( '-', 52 );
	$lines[] = sprintf( '%-38s %8.1f ms', 'TOTAL', $total );

	$output = implode( "\n", $lines );

	// Red de seguridad: no dejar que el contenido salga del comentario HTML
	$output = str_replace( '-->', '--&gt;', $output );

	echo "\n<!--\n" . $output . "\n-->\n"; // phpcs:ignore WordPress.Security.EscapeOutput
}

Para que no te consuma nada en el día a día, el cronómetro solo se enciende cuando tú quieres. Añade esta línea a tu wp-config.php mientras diagnosticas y la quitas al terminar:

// Activa el temporizador de fase de AyudaWP para medir el tiempo de carga de las páginas
define( 'AYUDAWP_PHASE_TIMER', true );

Interpretar el reparto de tiempos

Abre como administrador la página que va lenta, mira el código fuente (botón derecho, Ver código fuente de la página) y busca al final del todo un comentario de código con el reparto de tiempos, verás algo así:

<!--
AyudaWP Load Phase Timer
URL: /mi-pagina-lentorra/
----------------------------------------------------
Antes de WordPress (arranque PHP) 37.8 ms 23.9%
Carga de mu-plugins 0.1 ms 0.1%
Carga de plugins 17.9 ms 11.3%
Arranque del tema 8.4 ms 5.3%
Hasta init 3.9 ms 2.5%
De init a wp_loaded 18.0 ms 11.4%
Consulta principal 8.1 ms 5.1%
Render y salida 63.8 ms 40.4%
----------------------------------------------------
TOTAL 158.1 ms
-->

La fase con más milisegundos es donde se te está yendo el tiempo. A partir de ahí:

• Si se concentra en Carga de plugins o en Hasta init, tienes demasiados plugins o alguno hace trabajo pesado al arrancar, así que toca revisar cuáles son y desactivar los que no aporten.
• Si el tiempo está en Consulta principal y las consultas estaban limpias, mira el bucle principal, las WP_Query mal montadas o los relacionados, y vuelve a esa guía de consultas SQL.
• Si el grueso está en Render y salida, el problema es de la plantilla, de shortcodes pesados o de scripts, no de la base de datos.

Ojo, esto es para direcciones de la parte visible de la web, en el escritorio (wp-admin) algunas fases no aparecen porque no llegan a dispararse, y es lo normal.

Y que quede claro, esto es un primer vistazo y no sustituye a nada. Cuando ya sepas donde se atasca la cosa y quieras al culpable concreto Query Monitor te atribuye cada consulta, cada llamada HTTP y cada hook al plugin que lo provoca. Y si tienes SSH, wp profile te da todo esto y bastante más.

Una última cosa, que luego todo son sustos, esto es una herramienta de diagnóstico y no se queda puesta. Cuando termines quita la línea del wp-config.php o borra directamente el archivo, que un cronómetro corriendo en cada carga, por ligero que sea, no pinta nada en producción.

¿Te ha salido disparada una fase que no te esperabas? Cuéntamelo aquí abajo en los comentarios, que seguro que no eres el único al que le pasa.