curl -I https://ejemplo.com/wp-sitemap.xml

Si en la primera línea sale un 404 y el content-type dice application/xml, bienvenido al club, y si te sale un 403 no cantes victoria, que te ha contestado tu cortafuegos y no WordPress, un par de secciones más abajo te cuento cómo salir de esa.

Le pasa a tiendas, campus, webs de servicios, porfolios y a cualquier web sin blog, que son muchísimas y son justo las que menos lo van a notar, porque no hay ni un síntoma a la vista.

La web funciona igual de bien, el mapa del sitio se ve de maravilla en el navegador y los únicos avisos los tienes si añades el mapa del sitio a la Google Search Console o lo revisas un día por yo que sé, que te mostrará el error, y también lo verías si te da por mirar en la consola del navegador para buscar errores, eso que nunca haces salvo que aparezca rota la web.

Y esto no venía de serie, es nuevo desde WordPress 7.1, publicada el 19 de agosto de 2026, o sea que si actualizaste esta semana y tu web no tiene blog te lo has llevado puesto sin enterarte. En las versiones anteriores el mismo mapa del sitio se entregaba con código de estado normal, o sea, 200.

Además, el problema es más gordo, porque wwwwwwno se queda solo en el índice de mapas, los submapas de páginas, de productos, de categorías y de usuarios salen con código de estado de error 404 también, cada uno con todas sus URLs dentro, así que a esa web no le queda ni un mapa del sitio aprovechable.

Vamos a verlo deeespacito, primero si te toca y cómo salir del paso, y luego, para el que quiera, analizaremos la chicha, veremos qué se rompió en las tripas de WordPress.

Si usas plugins SEO que generan sus propios mapas del sitio XML no hace falta que sigas leyendo (salvo para aprender)

Los plugins de SEO grandes sirven un mapa del sitio propio, con su propia ruta distinta de la del mapa nativo, y mandan su cabecera 200 forzada , así que este asunto no les afecta.

Yoast y Rank Math (casualidad) usan sitemap_index.xml, AIOSEO crea un sitemap.xml y SEOPress sitemaps.xml, ninguno de estos aprovecha el mapa del sitio nativo que ya existe, y en este caso juega a su favor.

De hecho, si tienes uno de esos activo y visitas wp-sitemap.xml te vas a encontrar un 404 de verdad, de página no encontrada, al filtrar wp_sitemaps_enabled a false su código desactiva el sitemap nativo pero deja las reglas puestas precisamente para poder contestar ese 404. Ahí no hay nada roto, aunque tampoco es buena práctica, pero eso ya lo hemos comentado.

Ahora, si lo que usas es algo que utiliza el mapa del sitio nativo en lugar de montar el suyo, heredas el fallo entero, porque el sitemap que se sirve es el del core de WordPress con sus filtros y todo lo que lleva por defecto.

Es el caso de mi plugin de SEO, Visibility, que trabaja así a propósito, y por eso desde la versión 2.4.0 trae entre sus novedades el blindaje del estado del sitemap, y así mapa del sitio se entrega con código de estado 200 aunque la web no tenga ni una entrada publicada, y tú no tienes que tocar nada. Por ahi sin problema, sin 404 de ningún tipo, todo perfecto, ¿o lo dudabas?

Cualquier otro plugin que personalice el nativo en vez de sustituirlo te vale el arreglo que te cuento más abajo.

Cómo saber si mi sitemap XML da error 404

Lo primero que tienes que asumir es que el navegador te miente en esto. Abres la URL, ves el XML con su hoja de estilos y sus enlaces, todo precioso, y del código de estado no te dice ni mu, salvo que investigues, claro.

El que sí te lo muestra enseguida es Google, que cuando se encuentra un error 4xx al procesar el mapa del sitio te muestra el código recibido y no hay dudas.

Hay que mirar la cabecera de la respuesta, y de las tres formas de hacerlo la que nunca falla es la del navegador:

• Abre las herramientas de desarrollo con F12 y mira la pestaña Red, o directamente la consola, que te canta el 404 del documento en cuanto cargas la URL. El navegador supera cualquier protección antibots que tengas delante, así que lo que ves ahí es lo que hay.
• En Google Search Console, añadiendo o viendo el informe de Sitemaps, que es donde lo vas a ver sin duda posible porque te lo cuenta el propio Google.
• Con curl -I https://ejemplo.com/wp-sitemap.xml, que es lo más rápido si la web no tiene cortafuegos delante. Ojo con esto, que lo explico ahora mismo.

En Search Console el aviso es «No se ha podido leer el sitemap», con un «Error general de HTTP» y, desplegando, el «Error HTTP: 404».

Fíjate en el resto de la ficha, que es lo que le da la puntilla, las páginas descubiertas son cero.

Y ahí viene lo cruel del asunto, que el consejo que te da Google te manda a buscar justo donde no está el problema. Te dice que compruebes que el sitemap se encuentra en la dirección especificada y que no le tengas bloqueado el acceso.

Pues está en su dirección, se ve perfectamente y no está bloqueado. Con esas dos pistas te puedes tirar la tarde revisando el robots.txt, las reglas del cortafuegos y los permisos, sin encontrar nada, porque lo que falla es el código de estado y de eso no hay pistas visibles.

El curl desde tu ordenador se lo va a tragar el cortafuegos en la mitad de las webs decentes. Si tienes Cloudflare, el WAF del hosting o un plugin de seguridad con protección antibots, la petición ni llega a WordPress y te contesta la capa de delante con un 403, un 202 o un 503, siempre en text/html.

Yo mismo me he llevado un 403 en la primera prueba y he tardado un minuto en caer en la cuenta.

Si tienes acceso a la terminal del servidor puedes saltarte a Cloudflare pidiéndoselo al origen directamente, con la cabecera Host puesta a mano:

curl -skI https://127.0.0.1/wp-sitemap.xml -H "Host: midominio.com"

Y ahora el detalle que separa tres problemas que se confunden todo el rato. Mira el content-type que viene al lado del código de estado:

• 404 con content-type: application/xml, es este fallo. El sitemap se ha generado y se está sirviendo, solo que con el cartel de cerrado.
• 404 con content-type: text/html, no es esto. Ahí lo que pasa es que las reglas de reescritura no están puestas, la petición ni siquiera llega al sistema de sitemaps y lo que te devuelve es la página de error de tu tema. Se arregla yendo a «Ajustes > Enlaces permanentes» y dando a guardar sin tocar nada.
• 403, 202 o 503, no has llegado a WordPress. Te ha contestado la protección antibots y no has comprobado nada, así que repite por el navegador.

Una sola cabecera te dice cuál de los tres tienes, y te ahorras el rato (largo).

Si quieres profundizar en los sitemaps que no se ven, salen en blanco o dan errores raros, tengo una guía entera sobre eso que cubre los tres tipos de problema. Pero no vayas ahora, que queda mucho por ver, aprender y sobre todo hay que arreglar este problema.

Cómo hacer la prueba con una instalación limpia y cero plugins

Esto no es una sospecha ni una teoría, lo he medido en una instalación recién hecha, sin un solo plugin activo:

Borras la única entrada de una instalación nueva y el sitemap el código de estado es 404 (arriba te cuento como verlo). Publicas una y vuelve a 200.

Da igual el tipo de portada y da igual que tengas cien páginas, mil productos o los cursos del campus publicados: lo único que cuenta es que exista al menos un post, que no pinta absolutamente nada en el mapa del sitio que se va a servir.

Y hay un dato que parece un detalle y en realidad es la pista que lo explica todo: /wp-sitemap-index.xsl, la hoja de estilos que le da el aspecto bonito al XML, sí devuelve 200 en los dos casos. Guarda el dato que lo vemos enseguida. Apasionante ¿verdad? ¿o triste? Venga, que ya llegamos…

El error 404 en el sitemap es peor aún de lo que imaginas

Esto es lo que convierte el asunto en un problema serio y no en una cosa curiosa del güorpré, lo he probado en una tienda WooCommerce de pruebas sin una sola entrada de blog, con sus productos, sus páginas y sus categorías publicados, y el índice lista sus cuatro sitemaps ahí to guapos: páginas, productos, categorías de producto y usuarios.

Los cuatro muestran todas sus URLs. El de productos enseña sus veintitrés fichas con sus fechas de modificación, perfectamente formado, y ¡todos con código de estado 404!.

O sea, que a una tienda sin blog, que son legión, no tiene ni una sola URL que Google pueda extraer de sus mapas del sitio.

Ni las fichas de producto, ni las categorías, ni las páginas. Y todo esto con la tienda funcionando de maravilla, a priori, sin un error en el escritorio de WordPress ni nada que te avise.

¿Pero qué han roto en WordPress 7.1? Análisis forense…

El 8 de julio de 2026 entró en el core el changeset 62664, que añade la etiqueta condicional is_sitemap(), un añadido de lo más razonable y que mucha gente llevaba años pidiendo, para poder saber desde un plugin si la petición que estás atendiendo es la de un sitemap.

El propio mensaje del commit lo cuenta, y ahí está la frase del delito, que la marca se activa cuando existe la variable de consulta sitemap y una petición de mapa del sitio deja de tratarse como la portada.

Suena inofensivo y no lo es ni de lejos, porque de eso dependía el estado HTTP.

Para empezar, WP::handle_404() se ejecuta antes que template_redirect, o sea antes de que el sistema de sitemaps pinte nada. En una petición de sitemap la consulta principal es la consulta por defecto, la de la portada, que en una web sin entradas no devuelve ni un solo resultado.

Y handle_404() funciona de manera muy simple, si la consulta trae contenido entrega con código 200, si no trae nada mira una lista corta de excepciones, y si no está en ninguna tienes un código 404.

Esa lista de excepciones es is_author(), is_tag(), is_category(), is_tax(), is_post_type_archive(), is_home(), is_search() e is_feed().

Lo único que salvaba al sitemap era is_home(), por pura chiripa, porque una petición de sitemap se consideraba portada. Al dejar de considerarse portada se quitó el salvavidas, y en handle_404() no hay excepción para is_sitemap(), ni en la 7.1 ni inicialmente en el trunk (desarrollo) de la 7.2.

Medido por dentro, con el filtro pre_handle_404:

sin entradas:  is_404=false is_home=false is_singular=false is_archive=false is_feed=false is_paged=false posts=0  -> 404
con 1 entrada: is_404=false is_home=false is_singular=false is_archive=false is_feed=false is_paged=false posts=1  -> 200

Todas las excepciones en false, is_home() la primera. Lo único que cambia entre las dos líneas es que $wp_query->posts traiga algo, y esas entradas no tienen nada que ver con el sitemap.

Después, ya en template_redirect, WP_Sitemaps::render_sitemaps() pinta el XML y hace exit sin llamar nunca a status_header( 200 ), así que sale con el estado que se puso antes.

Y aquí encaja la pieza que te dije que ponía esto aún más apasionante, porque aa hoja de estilos se salva porque su variable de consulta es sitemap-stylesheet, no sitemap, así que is_sitemap no se activa, la petición sigue considerándose portada y contesta 200.

El fallo y la excepción salen del mismo sitio, que es lo que confirma que el diagnóstico es ese y no otro. Quedarse sin contenido no es lo mismo que no existir, y un mapa del sitio con páginas dentro existe aunque no haya un solo artículo en la web.

Cómo arreglar el problema con solo nueve líneas

Mientras esto se corrige en el core, se soluciona forzando el 200 solo en las peticiones de sitemap. Crea un archivo, llámalo ayudawp-sitemap-200.php, y súbelo por FTP o por el gestor de archivos de tu hosting a la carpeta wp-content/mu-plugins/. Si esa carpeta no existe la creas tú, WordPress la carga sola.

Lo pongo ahí y no en el functions.php del tema a propósito, porque así sobrevive a un cambio de tema y no se te queda un sitemap roto el día que decidas rediseñar:

<?php
/**
 * Plugin Name: Corregir el mapa del sitio nativo: de 404 a 200.
 * Plugin URI: https://plugins.ayudawp.com
 * Description: Fuerza código de estado 200 en peticiones del mapa del sitio nativo, en vez de 404. Borra este plugin cuando salga el arreglo nativo en WordPress.
 * Version: 1.0.0
 * Author: Fernando Tellado
 * Author URI: https://tellado.es
 * License: GPL2
 */

// Forzamos estado 200 dejando el resto como 404
function ayudawp_sitemap_force_200_status( $preempt, $wp_query ) {

$is_sitemap_request = get_query_var( 'sitemap' ) || get_query_var( 'sitemap-stylesheet' );

// Si no es petición al sitemap dejar que WordPress decida el estado
if ( ! $is_sitemap_request ) {
return $preempt;
}

$wp_query->is_404 = false;
status_header( 200 );

// Devuelve true para parar WP::handle_404() y guarda el estado de arriba
return true;
}
add_filter( 'pre_handle_404', 'ayudawp_sitemap_force_200_status', 10, 2 );

Súbelo, vuelve a pasarle el curl -I que vimos antes y deberías ver ya el código de estado 200. Sin caché que purgar ni enlaces permanentes que guardar, porque esto no toca las reglas de rewrite.

¡Que nooo, que este código no rompe nada!

Los 404 legítimos siguen intactos, que es lo que te tiene que importar antes de meter esto en una web de cliente. En una web sin entradas, /wp-sitemap-posts-post-1.xml sigue devolviendo 404, y es lo correcto, porque ese sitemap está vacío de verdad.

Lo fuerza el propio core, en render_sitemaps(), después de que nuestro filtro haya pasado. Lo mismo pasa con el 404 de cuando tienes los mapas del sitio desactivados por otro plugin de SEO.

El filtro solo actúa donde hay una variable de consulta del sitemap, y devuelve el control a WordPress en cualquier otra petición.

De regalo arregla de paso los sitemaps paginados que se iban a 404 cuando el número de página superaba al de páginas del blog, que es otro caso viejo del mismo mecanismo.

Nota: como ya habrás imaginado, una versión refinada y más sólida de este ajuste (opcional, porque no le pasa a todas las webs) está implementado en el plugin Visibility

Con los feeds pasó exactamente lo mismo en 2017

Esto, como casi todo, ya lo hemos vivido, y con el mismo desenlace, pues en WordPress 4.7 entró un cambio para que las URLs no válidas de feeds dejaran de generar RSS, y de rebote los feeds válidos pero vacíos empezaron a devolver 404.

Se avisó en el ticket 39157, se aceptó como fallo y se corrigió en la 4.7.3 revirtiendo el trozo de código que lo causaba. Lo he comprobado versión a versión, el bloque está en la 4.7.2 y ya no está en la 4.7.3.

O sea que el criterio ya está ahí desde hace nueve años. Lo que hay que decidir ahora es dónde se pone el parche esta vez, si en handle_404() con una excepción para is_sitemap(), que es el equivalente exacto de lo que hay para los feeds, o en render_sitemaps() mandando el 200 antes de pintar el XML, pero eso ya no es decision mía, yo he avisado (mira más abajo), y te ofrezco soluciones.

El estado en Trac ahora mismo

Hay dos tickets abiertos en el componente de sitemaps que te interesan:

• El 65936, anterior al mío, sobre sitemaps del core servidos con estado 404. Va con parche y está marcado para la 7.1.1, así que la corrección tiene pinta de estar en camino.
• El 65945, que he abierto yo mismo con este caso concreto, el de las webs sin entradas publicadas, los datos de la tabla de arriba y la medición del párrafo anterior. Ya se ha contemplado incluir este arreglo en WordPress 7.2.

Por debajo de los dos está el 51117, abierto desde 2020, que es la raíz de todo el asunto: las peticiones de sitemap ejecutan la consulta principal de la portada, que es una consulta que no se va a usar para nada y que además decide el estado HTTP de una página que no tiene nada que ver con ella.

El changeset de la 7.1 lo cita como referencia, pero mientras eso siga así vamos a seguir teniendo sorpresas de este tipo cada vez que alguien toque una condición.

Un apunte que debes saber es que is_sitemap() es una etiqueta condicional nueva que cambia el comportamiento de is_home() en una petición del core, y no tiene nota de desarrollo, no aparece por ninguna parte en la guía de campo de la 7.1.

Un cambio que altera un condicional que usan miles de plugins merecía su párrafo, o en mi cabeza es lo que me parece lógico, pero vaya, será que soy raro o algo.

¿Me afecta?

Si mantienes webs de clientes, y sobre todo si mantienes tiendas o webs corporativas sin blog, pásale el curl -I que vimos antes a las que ya tengan la versión 7.1 o superior antes de que Googlebot pase otra vez.

Si tienes muchas y quieres salir del paso rápido, mete el mu-plugin en las que te den 404 con XML dentro y reenvía el sitemap desde Search Console para que Google lo vuelva a leer sin esperar a su ritmo.

Si andas con ganas de cacharrear, en el artículo sobre cómo personalizar el mapa del sitio XML nativo tienes los filtros para quitar tipos de contenido, taxonomías y usuarios del sitemap, que combinan perfectamente con el arreglo de arriba, y por supuesto, no me cansaré de animarte a darle una oportunidad al mejor plugin de SEO del mundo mundial, nacido de mi (extraña) necesidad de tener un buen plugin de SEO, todo gratuito, y adaptado a las nuevas funcionalidades y cambios de rastreo por bots e IAs. Se llama Visibility, facilito.

Y si lo compruebas y te sale 404 con el XML dentro, cuéntamelo abajo en los comentarios con la versión de WordPress y si tu web tiene blog o no, que cuantos más casos reunamos más fácil es que esto se arregle cuanto antes.

Hay tres formas en el editor clásico que funciona de verdad en una red multisitio, los plugins Classic Editor y No Gutenberg? o un par de líneas de código sin depender de ningún plugin. Vamos a verlas, con lo que hace cada una en una red.

¿Qué cambia que sea una red multisitio para usar el editor clásico?

Desactivar el editor de bloques en un sitio único es instalar un plugin, activarlo y punto. En una red hay una capa más, porque un plugin se puede activar sitio a sitio o en red completa con activación para la red, y esas dos vías no siempre se comportan igual.

Y luego está la tercera vía, los mu-plugins, que ni siquiera pasan por la pantalla de plugins, que se cargan solos, en todos los sitios, sin que nadie los active. Esa diferencia es la que decide qué opción te conviene, así que vamos con las tres.

Opción 1: Plugin oficial Classic Editor

Es el plugin que mantiene el propio equipo de WordPress. En un sitio normal añade dos ajustes en «Ajustes > Escritura > Editor por defecto para todos los usuarios» (clásico o de bloques) y «Permitir a los usuarios cambiar de editor» (sí o no) ,para que cada usuario, puede además elegir su propio editor por defecto desde su perfil.

En una red la cosa cambia si lo activas en red. Al activarlo para la red aparece una sección nueva en «Administrador de la red > Ajustes», con «Editor por defecto para todos los sitios» y la casilla «Permitir a los administradores de sitios cambiar los ajustes».

O sea, que si lo activas para l a red, mandas tú y nadie más puede tocar el editor por sitio, salvo que lo permitas explícitamente desde esa pantalla de red. Si no lo activas en red entonces cada administrador de sitio decide por su cuenta.

Advertencia: esa casilla de red viene desmarcada por defecto la primera vez que el plugin toca la instalación, esté activado en red completa o solo en un sitio suelto de esa red. Así que si cada sitio activa Classic Editor por su cuenta, es fácil acabar con un ajuste de red heredado que nadie recuerda haber marcado. Revísalo en Administrador de la red antes de dar nada por hecho.

Y esta opción tiene una limitación que la descarta en bastantes casos: no funciona con temas de bloques. Lo dice la propia FAQ del plugin, «No, ya que los temas de bloques no funcionan con bloques». Si tu red usa temas FSE de edición completa del sitio, esta vía no es para ti.

Opción 2: No Gutenberg?

Aquí ya hablo de mi propio plugin, así que toca ser especialmente exigente con lo que cuento. Desde las versiones 2.2.0 y siguientes, publicadas en agosto de 2026, No Gutenberg? dejó de ser el interruptor de todo o nada que fue durante años.

Ahora tiene una pantalla de ajustes en «Ajustes > No Gutenberg?» con reglas por tipo de contenido, por perfil de usuario, por plantilla de página y por entradas concretas, además de un interruptor maestro y protección automática para que ninguna entrada ya construida con bloques pierda su editor por las reglas que pongas.

Te cuento el porqué de este cambio de rumbo con calma en otro artículo, que es de hecho la razón por la que estoy escribiendo esta guía ahora, pues fue uno de los retos con los que me encontré..

Sobre el tema de multisitio, no, no hay una pantalla de red dedicada, y no la hay porque no hace falta.

Cada sitio guarda sus ajustes como cualquier plugin normal, y para forzar el mismo criterio en toda la red de un plumazo, presente y futura, sitios que aún no existen incluidos, usas wp-config.php, que por diseño de WordPress es un único archivo compartido por toda la instalación.

Las constantes son estas tres, y son las únicas que reconoce el plugin:

• NO_GUTENBERG_OPTIONS: un array con cualquier ajuste de la pantalla. Fija esa configuración y bloquea automáticamente la pantalla de ajustes en todos los sitios.
• NO_GUTENBERG_LOCK_SETTINGS: deja la pantalla visible pero de solo lectura, para que cada administrador de sitio vea qué está pasando sin poder tocarlo.
• NO_GUTENBERG_HIDE_SETTINGS: oculta directamente la pantalla del menú.

Ejemplo real, sacado de mi propia documentación:

define( 'NO_GUTENBERG_OPTIONS', array( 'complete' => true ) );
define( 'NO_GUTENBERG_HIDE_SETTINGS', true );

Con esas dos líneas en wp-config.php, todos los sitios de la red quedan con el editor de bloques desactivado por completo y sin pantalla de ajustes que nadie pueda tocar.

Si lo que quieres son reglas más finas, solo ciertos tipos de contenido, ciertos roles, ciertas plantillas, el array admite las mismas claves que ves en el formulario de ajustes, configúralo primero en un sitio de pruebas desde la pantalla, y si quieres el nombre exacto de cada clave para replicarla en wp-config, está en includes/class-no-gutenberg-options.php, dentro del propio plugin.

Un detalle que merece mención si administras una red grande es que el interruptor «Bloquear el editor del sitio», dentro de la sección de ajustes de todo el sitio, es el único de los tres métodos de este artículo que llega a tocar la edición de plantillas de un tema de bloques. Ni el plugin Classic editor ni el código nativo de la siguiente sección llegan a tanto, como veremos.

Opción 3: Sin plugins, solo código

Si prefieres no depender de ningún plugin, ni siquiera del mío, WordPress trae de serie los filtros que necesitas. Los dos que te interesan en multisitio son use_block_editor_for_post_type, desde WordPress 5.0, que decide el editor por tipo de contenido, y use_widgets_block_editor, desde WordPress 5.8, que hace lo mismo con la pantalla de widgets.

La forma más robusta de aplicarlos en toda una red es un mu-plugin. Como ya sabrás, de guardan en wp-content/mu-plugins, una carpeta compartida por toda la instalación, así que WordPress los carga automáticamente en todos los sitios de la red sin que nadie los active ni pueda desactivarlos por error desde el escritorio.

El código sería este:

<?php
/**
 * Desactiva el editor de bloques en toda la red: entradas, páginas y widgets.
 */
add_filter( 'use_block_editor_for_post_type', '__return_false' );
add_filter( 'use_widgets_block_editor', '__return_false' );

Guarda eso como, por ejemplo, wp-content/mu-plugins/desactivar-editor-bloques.php y ya está, sin pantalla de ajustes, sin activación, sin nada que un administrador de sitio pueda cambiar sin querer.

Advertencia: WordPress solo carga los archivos que están directamente dentro de mu-plugins, no los que metas en subcarpetas. Si organizas el código en varios archivos, necesitas uno en la raíz que haga los require del resto.

Si lo que quieres es más quirúrgico, por ejemplo desactivarlo solo en entradas y dejarlo activo en páginas, el mismo filtro te sirve con un poco más de código:

add_filter( 'use_block_editor_for_post_type', function( $use_block_editor, $post_type ) {
    if ( 'post' === $post_type ) {
        return false;
    }
    return $use_block_editor;
}, 10, 2 );

Esta distinción exacta, bloques sí en páginas, bloques no en entradas, es justo el argumento de fondo por el qué he cambiado de postura con mi propio plugin. Si te ha convencido el porqué, aquí tienes el cómo hacerlo sin depender de nada.

La constante mágica en wp-config (spoiler: no existe)

Como vas a encontrarte información por ahí que habla de una supuesta constante nativa de WordPress para desactivar el editor de bloques te lo confirmo ya: no existe, nunca ha existido, y se rechazó expresamente.

En 2018 alguien pidió justo eso en el ticket 43068 de Trac, algo del estilo define('ENABLE_GUTENBERG', false). Se cerró como «wontfix», y la respuesta de un responsable de sistemas de WordPress.org lo explica mejor que yo:

«No creo que vayamos a admitir una constante para esto […] WordPress ha estado intentando dejar de usar constantes, ya que son muy difíciles de cambiar más adelante […] «Oh, quiero Gutenberg, ¿por qué está desactivado? Oh, mi plugin de SEO cualquiera (o mi ex-desarrollador) pensó que no lo querría y lo desactivó a la fuerza, genial… ahora, ¿a quién puedo pedirle que me lo arregle?.

O sea, que la rechazaron para evitarte justo el lío que estás intentando resolver con este artículo: una constante mágica en wp-config que nadie recuerda por qué está ahí.

Las únicas constantes reales para esto son las de plugins concretos, como las tres de no gutenberg que has visto arriba. Si un tutorial te dice que existe una constante nativa de WordPress para esto, está equivocado o está desactualizado.

Lo que ninguna de las tres vías modifica: el editor del sitio

Un tema de bloques de edición completa del sitio no edita sus plantillas por la pantalla clásica de entradas, sino por el Site Editor, una aplicación aparte.

Los filtros use_block_editor_for_post_type y use_block_editor_for_post solo deciden qué pasa en la pantalla de editar entradas y páginas, así que ni ellos ni el plugin Classic Editor llegan a tocar la edición de plantillas. Lo confirma la propia documentación de WordPress para temas clásicos, que «no funciona con el editor del sitio».

No Gutenberg? es la excepción parcial, con el interruptor específico para bloquear el acceso al editor del sitio que ya te he contado arriba, aunque ahí seguimos hablando de bloquear el acceso, no de convertir esas plantillas en algo editable de otra forma.

¿Qué opción elijo, cuál es mejor?

Pues, como con casi todo, dependerá de tus necesidades, te lo resumo fácil:

¿Cuál usar en una red multisitio?

Dicho todo lo anterior, mi recomendación práctica:

• Red de sitios parecidos entre sí, un único superadministrador y quieres algo simple de gestionar: plugin Classic Editor activado en red.
• Necesitas reglas distintas según el sitio, el tipo de contenido o el perfil, o te preocupa que alguna entrada ya maquetada con bloques se rompa: No Gutenberg?, configurado por sitio o forzado entero desde wp-config si quieres uniformidad total.
• Red grande y cero dependencias, control absoluto por código y ni un ajuste que nadie pueda tocar por error: mu-plugin con los filtros nativos.

Si te decides por No Gutenberg? tienes la página del plugin en wordpress.org con el resto de ajustes que no caben en este artículo centrado en multisitio.

Si tienes una red con una configuración rara que no encaja en ninguna de las tres opciones, cuéntamelo en los comentarios, que seguro que no eres el único.

Puede que lleves meses regalando tu contenido y tus datos a cualquiera que sepa hacer eso, que tampoco hace falta ser muy espabilado.

Lo probé en siete plugins, dos de ellos míos, y el resultado no me hizo ninguna gracia, solo uno pasaba limpios los tres casos que le puse por delante.

Y no, esto no va de «estos plugins están mal hechos», que sería quedarme corto y además aburrido. Va de algo más interesante, de que existe una forma correcta de hacerlo, la usaba uno solo de los siete, y resulta que WordPress ya había resuelto exactamente este mismo problema hace años en su API REST.

La solución estaba escrita, publicada y a la vista de cualquiera, y todos habíamos pasado por delante de ella sin darnos ni puta cuenta, de puro bobo que era el fallo, pero sobre todo porque no habíamos caído nadie en ello.

La buena noticia es que esto acaba bien, avisé al equipo de plugins de WordPress.org el 27 de julio, los autores reaccionaron rápido, y a día de hoy de los siete solo queda uno sin corregir, precisamente el único que lleva más de un año abandonado. Y por el camino ha salido una propuesta para mejorar las comprobaciones de Plugin Check, que es lo mejor que le podía pasar a todo esto.

Te cuento cómo lo probé, qué me encontré, lo que me pasó arreglando mis propios plugins (que no me lo esperaba, oye), qué puedes hacer tú para saber si te afecta y cómo se hace bien si desarrollas plugins.

Análisis forense

Empezamos por el diagnóstico técnico, por todo lo que puede fallar y, para variar, fallará, como reza la famosa Ley de Murphy.

En qué hemos fallado todos los que hacemos plugins de Markdown para agentes y archivos llms.txt

Un plugin que quiere servir tu contenido en Markdown para agentes de IA tiene dos maneras de construir ese .md, una mala y otra buena:

• Tomar el post_content tal cual está en la base de datos, pasarlo por los filtros de turno y convertirlo. Es la rápida, la que usa casi todo el mundo, y también la que abre el problema, pues genera una ruta paralela que se salta por completo la capa de protección de tu contenido.
• Dejar que WordPress procese la página como lo hace siempre, con toda su lógica de permisos incluida, y convertir a Markdown el HTML que ya ha salido. Es la lenta, porque generas la página entera para quedarte solo con el texto, y era la que usaba exactamente uno de los siete plugins que probé.

La clave de todo el asunto es que WordPress no tiene una API de autorización de contenido separada de la visualización, tiene post_password_required() (la función que decide si hay que pedir la contraseña antes de enseñar una entrada) para las contraseñas del propio núcleo, y las capacidades de usuario para lo demás.

Todo lo demás, LMS y plugins de membresías incluidos, se protege enganchándose al filtro the_content (el que procesa el cuerpo de una entrada justo antes de pintarlo en pantalla) o sustituyendo directamente la plantilla que se muestra.

Son capas de presentación, no de datos, por lo que si un plugin no pasa por ahí, no se entera de que existen, y las salta todas.

Dentro de la opción rápida hay además una parte que depende de una sola línea de código, y que explica por qué unos plugins protegían la mitad de los casos y otros ninguno.

Los filtros de restricción, para saber qué entrada están mirando, preguntan con get_the_ID(), y esa función lee la variable global $GLOBALS['post'].

Si el plugin que genera el Markdown no ha rellenado antes esa variable, el filtro pregunta por un post que no existe, no encuentra nada que proteger y deja pasar el contenido entero, con contraseña, con restricción de perfil de usuario o sin ninguna de las dos.

Aquí viene el matiz que genera el problema, setup_postdata(), la función que prepara las variables del loop de WordPress (título, extracto, autor…) para pintar una entrada, no rellena por sí sola $GLOBALS['post']. Hacen falta las dos cosas, asignar la variable global y llamar a la función, y quedarte solo con una de ellas es dejar la tarea a medias sin saberlo.

Y aun haciéndolo perfecto se te queda fuera cualquier plugin que proteja por plantilla en lugar de por the_content. Sensei LMS es el caso típico, porque no filtra el contenido, sustituye directamente lo que se muestra en pantalla, así que ninguna comprobación sobre the_content le va a hacer siquiera cosquillas.

Un detalle técnico que conviene tener claro es que la contraseña de WordPress y la restricción por perfil no son el mismo tipo de comprobación, aunque lo parezcan desde fuera.

La segunda suele resolverse casi sola si tu plugin usa bien current_user_can() (la función que comprueba los permisos del usuario), porque va de capacidades. La primera va por libre, con su propio mecanismo, que no tiene nada que ver con perfiles ni capacidades, así que hay que tratarla aparte, a propósito. Por eso te vas a encontrar plugins que aciertan con una cosa y fallan con la otra.

Cómo hice las pruebas de esta cagada

Instalación limpia de WordPress 7.0.2 en Local, con tres contenidos restringidos de tres formas distintas:

• Una entrada con contraseña de WordPress, el mecanismo del propio núcleo.
• Una página con restricción por perfil de usuario, usando el plugin Members 3.2.26.
• Una lección de pago de un curso de Sensei LMS 4.26.1, con inicio de sesión obligatorio.

De cada uno comprobé lo mismo, que la versión HTML normal oculta el contenido tal y como toca, y después pedí la versión Markdown de esa misma URL sin haber iniciado sesión, a ver qué me devolvía. Sin cookies, sin usuario, tal y como lo pediría cualquier agente de IA que pase por tu web.

Lo que me encontré (¡ay madre!)

Probé cinco plugins de terceros más los dos míos, VigIA y Visibility. De los siete solo uno pasaba limpios los tres casos, Markdown for AI Agents.

Esta es la foto del 27 de julio de 2026, con las versiones que había ese día, y la última columna te dice cómo está la cosa ahora:

Las dos filas de abajo son mías, y las corregí y publiqué antes de escribir a nadie, que era lo mínimo. Los «sin confirmar» de Website LLMs.txt son literales, esos dos casos no llegué a medirlos y no voy a decir que fallaban sin haberlo comprobado.

Notas por plugin, todas verificadas contra el código:

• Markdown for AI Agents es el único que no estaba afectado, y lo consigue haciendo algo distinto a todos los demás, engancha un buffer de salida sobre template_include y convierte a Markdown el HTML que WordPress ya ha renderizado. Hereda la protección entera, incluida la de Sensei, sin saber que Sensei existe. Paga más rendimiento y el Markdown le sale con restos del decorado de la página, pero en seguridad es correcto por construcción, que es lo que cuenta.
• JumpsuitAI establecía $GLOBALS['post'] y llamaba a setup_postdata() antes de aplicar los filtros, y llevaba un comentario en el código explicando que si no lo hace, los endpoints .md devuelven el cuerpo equivocado. Alguien ya se había topado con esto antes. Protegía los dos primeros casos y caía con Sensei.
• Website LLMs.txt volcaba el contenido de la página restringida por perfil en /llms.txt al activar la opción de contenido detallado. Además listaba los títulos y las URLs del contenido restringido aunque no volcara el cuerpo, lo que ya revela su existencia.
• LLMs.txt and LLMs-Full.txt Generator era el de mayor impacto. Tomaba post_content directo de la base de datos, sin pasar por the_content siquiera, y lo escribía en un fichero físico en la raíz del sitio, con los tres casos dentro. Y como es un .txt estático que sirve el servidor web sin pasar por WordPress, desactivar el plugin no impide que se siga sirviendo, y ningún otro plugin puede taparlo. En mi instalación de pruebas ese fichero ocupaba 59 KB con el contenido privado dentro.
• Markdown Mirror es el ejemplo del matiz técnico de antes, llama a setup_postdata() pero no asigna $GLOBALS['post'], y con eso ya filtra. Incluso el caso de la contraseña de WordPress, que es el más básico de todos y no necesita ningún plugin de terceros para reproducirse. La salida arrastra además el prefijo que WordPress pone a los títulos protegidos, justo encima del contenido que acaba de destapar:

# Protected: Post con contrasena
CONTENIDO BAJO CONTRASEÑA

Lo que aprendí arreglando mis propios plugins

Esta es la parte del artículo que más vale la pena (creo), y no salió de auditar nada, salió de arreglarlo.

Un plugin puede aprobar los tres casos de la tabla de arriba y aun así tener dos agujeros más, porque las tres pruebas se hacen sin haber iniciado sesión, y hay cosas que solo se ven con una sesión de administrador abierta.

La primera capa: preguntarle al usuario equivocado

El arreglo obvio, el que se te ocurre a la primera, es comprobar si el visitante que pide el Markdown puede leer esa entrada, usando la propia API del plugin de turno que la protege.

Suena razonable, ¿verdad?, pues el problema es que Sensei tiene una función, sensei_all_access(), que da acceso total a los administradores por defecto, y tiene todo el sentido del mundo para la interfaz de administración, dicho sea de paso.

Así que si le preguntas a esa función «¿puede este usuario ver la lección?» con un administrador identificado, te dice que sí, aunque la lección sea de pago y ese administrador no esté matriculado en el curso, y ese «sí» se cuela en el Markdown que generas.

Esto me pasó primero en Visibility, mientras lo probaba con sesión iniciada para otra cosa, la lección de pago salía entera por el .md mientras que la página HTML de esa misma lección me enseñaba, correctamente, el aviso de que no estaba matriculado.

Lo reproduje después en VigIA, con un administrador devolvía un 200 con el contenido dentro, y como visitante anónimo un 404. Mismo agujero en dos plugins.

Pero no tuvo la misma gravedad en los dos casos, y esto es importante:

• En VigIA se quedó en una incoherencia sin consecuencias para nadie más, porque su función que decide qué se puede guardar en caché no dejaba cachear nada generado con una sesión abierta, así que ese documento con fugas no llegó a servirse jamás a otra persona.
• En Visibility sí había fuga de verdad, porque esa misma salvaguarda existía en el Markdown por entrada, pero no en el generador de llms.txt, que cachea el archivo entero sin ningún componente de usuario. Un archivo generado una vez con mis ojos de administrador delante se podía quedar ahí, servido después a cualquiera que lo pidiera.

La pregunta correcta en estas superficies no es «¿puede leerlo quien lo pide?», es «¿puede leerlo cualquiera?», porque lo que se genera aquí se entrega igual a todo el que lo pida después, esté cacheado o no.

La solución de verdad es evaluar siempre como si fueras un visitante anónimo, con un contexto que se abre antes de decidir y se cierra después, venga quien venga a pedirlo.

La segunda capa, la peor: quién genera el fichero

Los plugins que escriben un llms.txt físico en la raíz de tu web lo generan casi siempre desde una petición de administración o desde una tarea programada, un cron.

Si la comprobación de acceso se hace con el usuario de esa petición concreta, el fichero se escribe con todo lo que ve un administrador dentro, y luego es tu propio servidor web el que sirve ese fichero a cualquiera, sin que WordPress vuelva a intervenir para nada.

Es el mismo agujero de antes, pero por una puerta que ninguna prueba en anónimo detecta jamás, porque el fichero ya está escrito de antemano.

Esta capa fue solo de Visibility, y el orden en que llegué a ella tiene su miga. VigIA no la traía resuelta de serie, su versión anterior, la 2.4.3, ni siquiera tenía una clase de control de acceso en su generador de llms.txt.

Preparé el arreglo de VigIA después de haber arreglado ya Visibility, y ese arreglo volvió con una parte que yo no había pedido para esa tarea concreta, el contexto anónimo ya integrado en el generador de LLMS de VigIA.

Al leer esa parte de más para entender qué hacía fue cuando vi que Visibility escribía su llms-full.txt desde admin_init (el momento en que WordPress arranca cualquier pantalla del escritorio), es decir, con el administrador identificado, en un fichero que después entrega el servidor web a cualquiera sin preguntar nada.

El nivel de certeza no es el mismo en las dos capas, y te lo digo tal cual para que lo sepas. La primera la medí en los dos estados, antes y después del arreglo, en los dos plugins.

La segunda la establecí leyendo el código antes de tocarlo, y la comprobé después generando el fichero como administrador con las lecciones incluidas en los tipos de contenido, cero fugas y 36 entradas legítimas dentro.

Si te sirve la moraleja, la secuencia fue arreglar Visibility, preparar el arreglo de VigIA, y recibir de vuelta una parte que no había siquiera adivinado, y descubrir con ella un agujero propio que se me había pasado.

Tener dos implementaciones distintas del mismo problema y poder compararlas es un lujo que no siempre te puedes permitir, y esta vez me vino de maravilla.

Para quien quiera auditar lo suyo: todas las comprobaciones con curl sin cookie te van a salir en verde aunque tu web esté filtrando. Hace falta repetirlas también con una sesión de administrador abierta, y comprobar después qué se ha quedado escrito en las cachés y en los ficheros.

Dos matices técnicos más

Van verificados contra el código, son de la parte densa del artículo, pero merece la pena que los conozcas si programas o mantienes plugins.

La función is_post_type_viewable() no responde lo que parece que responde. Es la función a la que uno recurre para preguntar «¿este tipo de contenido tiene una URL pública de verdad?», y la respuesta puede ser que sí cuando la realidad es que no.

Termina pasando por un filtro, is_post_type_viewable, que muchos plugins usan con toda lógica, para que el editor de bloques trate como visible un tipo de contenido interno suyo, y Sensei lo hace con sus plantillas de correo, en includes/internal/emails/class-email-post-type.php.

El resultado es que en una petición hecha desde el área de administración la función te contesta que sí, que es público, para un tipo de contenido que no tiene ninguna página pública.

Si tu plugin se apoya en esa función para decidir qué publicar en el Markdown o en el llms.txt, vas a publicar de más. Lo único que no falla es calcular la regla del núcleo a mano, publicly_queryable || ( _builtin && public ).

Y ojo, que este fallo es traicionero, porque no aparece en las comprobaciones automatizadas, solo asoma cuando se renderiza una pantalla de administración de verdad.

Los mensajes privados de un LMS son, oficialmente, un tipo de contenido público. Sensei registra su tipo de contenido sensei_message, que es la correspondencia entre alumno y profesor, con public => true y publicly_queryable => true.

Cualquier plugin que te ofrezca un selector de «elige qué tipos de contenido publicar» lo va a listar ahí, tan tranquilo, justo al lado de entradas y páginas, y como no le pongas cuidado y lo marques, acabas de publicar conversaciones privadas entre tus alumnos y tus profesores. No hace falta que nadie tenga mala intención, basta con no saber esto.

La API REST ya tenía resuelto este tipo de problema

Y este es el remate de todo el análisis, porque resulta que la API REST del propio núcleo de WordPress es exactamente el mismo tipo de superficie paralela que un endpoint de Markdown o un llms.txt, y ahí las tres pruebas salen perfectas:

GET /wp-json/wp/v2/pages/<id>   (restringida por perfil)  → content.rendered vacío
GET /wp-json/wp/v2/posts/<id>   (con contraseña)          → content.rendered vacío, protected: true
GET /wp-json/wp/v2/lesson/<id>  (lección de Sensei)       → 404, la ruta ni siquiera existe

Hay tres decisiones de diseño detrás de esto, y las tres sirven para cualquier sitio donde las apliques:

1. El controlador establece el contexto de la publicación antes de aplicar the_content, así que los plugins de restricción funcionan sin tener ni idea de que existe una API REST. No hace falta que nadie lo sepa para que funcione.
2. El caso de la contraseña está tratado de forma explícita, y se señaliza con un campo protected en la respuesta. No se limita a vaciar el contenido y ya está, te avisa de por qué está vacío.
3. Sensei directamente no expone su tipo de contenido lesson en la API REST. Cuando no puedes garantizar el control de acceso en una superficie nueva, no abres esa superficie, y punto.

Esa tercera es la lección de fondo, y va mucho más allá del Markdown para IA, que cada vez que abres una salida nueva del mismo contenido, un feed, un endpoint, un fichero estático, un .md, heredas la obligación de reimplementar los controles de acceso desde cero, y WordPress no te avisa de eso en ningún sitio.

Precedentes hay de sobra, los feeds RSS, oEmbed, AMP en su día, y el propio Sensei tuvo que parchear su feed RSS por este motivo exacto en la versión 4.24.5.

Qué hacer si usas plugins de Markdown para agentes o llms.txt

La comprobación te lleva diez segundos, y hazla con la sesión cerrada, o en una ventana de incógnito:

1. Copia la URL de cualquier contenido restringido de tu web.
2. Añádele .md al final y ábrela.
3. Mira si sale el contenido privado que no debería verse sin restricción.

De paso, abre tudominio.com/llms.txt y tudominio.com/llms-full.txt y busca ahí dentro cosas que no deberían estar.

Y ahora repite las dos comprobaciones con tu sesión de administrador abierta, que es donde aparecen los dos agujeros que te contaba antes.

Si con la sesión abierta ves contenido que en anónimo no aparecía, ese documento puede estar quedándose guardado en una caché o en un fichero, a disposición de cualquiera que pase después que tú.

Si te sale contenido que no debería verse:

• Actualiza el plugin, que si es de los de la tabla ya está corregido, salvo Markdown Mirror.
• Si no hay versión nueva, desactiva el módulo de Markdown o el plugin entero hasta que la haya.
• Comprueba si te ha quedado un fichero físico en la raíz de tu instalación, porque desactivar el plugin no lo borra, y bórralo tú a mano.
• Y si has tenido el llms-full.txt publicado un tiempo, da por hecho que alguien lo ha leído y actúa en consecuencia con lo que hubiera dentro.

Avisar al autor del plugin, mejor en privado, nunca está de más, y si no contesta ni saca parche en un tiempo razonable, cambia de plugin y listo, no merece la pena jugársela por algo que ni siquiera está tremendamente extendido.

Qué pasó cuando lo reporté

Esta parte me parece la más interesante de contar, además porque es la que no suele contarse nunca.

Lo primero fue arreglar lo mío y publicarlo, Visibility 2.1.0 y VigIA 2.4.4 salieron el 27 de julio, antes de escribir a nadie. No puedes ir señalando fallos ajenos con los tuyos sin parchear, así que eso ni se discute.

Con eso hecho escribí a plugins@wordpress.org, el equipo de plugins de WordPress.org, con el detalle técnico, los pasos de reproducción y las ubicaciones exactas en el código de cada hallazgo.

Les ofrecí ajustarme a la ventana de divulgación que ellos prefirieran, y a falta de indicación distinta me quedé con los 30 días de siempre.

Su respuesta fue breve y al grano, que gracias por el reporte, que es importante para la comunidad señalar este tipo de cosas y que ellos avisarían a los autores.

Y los autores respondieron, que es lo que quería contarte:

• JumpsuitAI corrigió el caso de Sensei en la 1.1.7.
• LLMs.txt and LLMs-Full.txt Generator, que era el de mayor impacto de todos, corrigió en la 2.1.1.
• Website LLMs.txt merece un párrafo aparte y va justo debajo.
• Markdown Mirror sigue sin corregir, y es el único. Su última actualización es de julio de 2025, no tiene soporte activo y ronda las 200 instalaciones. Si lo tienes puesto, quítalo, ni lo dudes.

Lo de Website LLMs.txt es muy buen ejemplo de reacción bien hecha, y hablamos de un plugin con unas 40.000 instalaciones activas, o sea que la decisión no era ninguna tontería para ellos.

No taparon el síntoma, fueron a la raíz. En su registro de cambios explican que el contenido que no es públicamente visible ya no entra en el fichero generado, y que si usas un plugin de membresía o de control de acceso tus entradas y páginas se quedan fuera por defecto, porque no hay forma fiable de saber desde la base de datos cuáles puede leer un visitante.

Esa última frase es exactamente el problema de fondo que yo les había descrito, asumido y convertido en decisión de producto. Prefirieron publicar de menos antes que arriesgarse a publicar de más, y añadieron un resumen en pantalla de lo que se ha quedado fuera para que el usuario pueda incluir a mano lo que quiera. Eso es hacerlo bien.

Y tiene un epílogo que me hizo mucha gracia, porque les hicieron falta tres versiones. La 8.5.4 arregló el fondo, la 8.5.5 arregló que en algunos sitios el llms.txt viejo no se llegaba a borrar durante la actualización y se seguía sirviendo, y la 8.5.6 remató lo mismo por otra vía. Justo mi segunda capa, la del fichero físico que sobrevive a todo, pasándole a otro en tiempo real.

Lo importante es que lo arreglaron.

Cómo se hace bien, si desarrollas plugins

Esto es lo que le mandé al equipo de plugins como resumen de implementación correcta, por si le sirve a alguien que esté montando algo parecido:

1. Establece $GLOBALS['post'] y llama a setup_postdata() antes de aplicar the_content, y restaura después.
2. Evalúa el acceso como visitante no identificado, nunca como el usuario actual, porque la salida es pública y se cachea sin componente de usuario.
3. Comprueba explícitamente contra los plugins de LMS y membresías que publiquen una API de acceso, y deja fuera los tipos de contenido de los que no la publiquen.
4. No publiques nunca nada de un tipo de contenido que no tenga portada propia en frontend.
5. Ofrece un filtro para que cada sitio pueda vetar una entrada por su cuenta, pensando en el plugin que nadie ha previsto.

Lo que WordPress podría hacer, y lo que ya se está moviendo

En el reporte incluí también unas observaciones sobre la plataforma, porque el núcleo no está exponiendo nada y la API REST lo hace bien, pero hay tres cosas que ponen muy fácil cometer este error.

No existe una API de autorización de contenido separada de la presentación. El núcleo ofrece post_password_required() y el modelo de capacidades, y nada más, así que todos los LMS y plugins de membresías acaban aplicando sus reglas filtrando the_content o sustituyendo la plantilla. Algo como una función is_post_content_readable( $post, $user ), filtrable, que implementaran los plugins que restringen y consultaran los que publican, convertiría este tipo de fallo en algo difícil de escribir en lugar de fácil.

is_post_type_viewable() merece al menos una nota en la documentación, y mejor todavía una función hermana no filtrable que responda de verdad a «¿este tipo tiene URL pública?».

Y el patrón de la API REST no está escrito en ninguna parte como patrón. Un apartado en el manual del desarrollador de plugins que dijera algo tan simple como «si expones contenido fuera de la plantilla, heredas estas responsabilidades» probablemente habría evitado casi todo lo que te he contado aquí.

Lo mejor de todo esto es que no se ha quedado en un correo. David Pérez, del equipo de plugins, abrió a partir del reporte una propuesta para mejorar las comprobaciones de Plugin Check, la herramienta por la que pasan todos los plugins que se suben al repositorio. Si eso sale adelante, el fallo se detecta antes de publicarse, en todos los plugins que vengan a partir de ahora, no solo en estos siete.

Que un rato de trastear con tus propios plugins acabe mejorando la seguridad de los plugins que todavía no existen es, con diferencia, la mejor parte de esta historia.

Resumiendo, revisa lo que tengas

Si tienes VigIA, asegúrate de estar en la 2.4.4 o posterior, y si tienes Visibility, en la 2.1.0 o posterior. Si usas cualquier otro plugin de los que sirven Markdown o generan tu llms.txt, actualízalo y haz la prueba de los diez segundos (arriba lo he dejado), primero sin sesión y después con ella.

Si te sale algo raro cuéntamelo en los comentarios, que entre todos se audita mejor que cada uno solo en su cueva. Y si quieres seguir aprendiendo de estas cosas tienes la guía completa de Markdown para agentes de IA y el pilar de llms.txt y llms-full.txt.

Para terminar, una reflexión que me ha surgido de todo esto, y es que las dos capas, el administrador que ve de más y el fichero que se escribe solo, han pasado sobre algo que en apariencia no podía ser más inofensivo.

Un llms.txt no es más que un listado de tus contenidos en texto plano, una especie de mapa del sitio pensado para agentes en vez de para buscadores.

Igualmente, servir tus entradas en Markdown es literalmente lo mismo que hacía AMP hace una década, ofrecer una versión ligera de tu contenido para un consumidor concreto, entonces Google, ahora un agente de IA.

Nada de esto tenía pinta de superficie de riesgo, en principio, pero resulta que la prisa por adaptarse a las nuevas exigencias de visibilidad en IA, sin pararse a comprobar que lo básico seguía funcionando, es la que acaba exponiendo datos sensibles o simplemente privados, y fíjate tú que sí, que hay que mirarlo todo, darse un momento de reflexión.

Yo he aprendido la lección, he reaccionado a tiempo, y mira que soy meticuloso probándolo todo, pero seguramente hay por ahí ahora mismo vulnerabilidades de todo tipo corriendo en tu web si alguien no ha tenido el mismo cuidado.

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 se aplican desde 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.

Y hay algo más directo todavía, porque la propia Comisión, en la página donde publica los iconos oficiales de etiquetado, incluye los resúmenes de noticias generados por IA entre los ejemplos de uso del icono de contenido totalmente generado. Ojo al matiz, que habla de resúmenes de noticias y el resumen de un tutorial de WordPress no lo es, pero deja claro por dónde va el criterio del regulador.

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 elucubrar 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.

Y hay un argumento técnico que va en la misma dirección, porque el propio Anthropic reconoce que un pasaje muy corto deja demasiado poco texto para una señal fiable, así que un alt de diez palabras se queda fuera del marcado por pura física, no solo por interpretación legal.

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.

Marcas de agua de los proveedores de IA

Aquí llega la parte más reciente, y que te afecta aunque no tengas ninguna obligación nueva por ella. Los proveedores de IA han empezado a marcar técnicamente lo que generan, y esas marcas pasan por tu WordPress.

Anthropic, por ejemplo, ha firmado el código de buenas prácticas del artículo 50.2 y ha publicado cómo va a marcar el contenido que genera Claude, con dos técnicas que conviene entender.

Por un lado, los modelos lanzados a partir del 2 de agosto de 2026 tejen una marca de agua imperceptible dentro del propio texto, que no se ve, no cambia el significado ni la legibilidad, y lo interesante, viaja con el texto cuando lo copias y lo pegas en otro sitio.

Por otra parte, los archivos que genera llevan metadatos de procedencia firmados con el estándar C2PA, el mismo que ya usan DALL·E, Firefly o Imagen.

Esto implica que si redactas con IA y pegas el resultado en el editor de WordPress, la marca se viene con el texto, así que la suposición de «esto no lo detecta nadie» ha dejado de ser cierta. No te crea ninguna obligación que no tuvieras ya, pero conviene saberlo.

Con las imágenes pasa lo contrario, y es donde está el detalle jugoso para cualquiera que tenga un WordPress.

Los metadatos C2PA se pierden en cuanto el archivo se reguarda, se convierte de formato o se le hace una captura de pantalla, y resulta que eso es exactamente lo que hace tu web todos los días.

Subes la imagen a la biblioteca de medios, WordPress genera sus miniaturas, y tu plugin de optimización, sea Smush, ShortPixel, Imagify o EWWW, borra los metadatos por defecto para ahorrar bytes. La marca del proveedor se evapora en tu propio flujo de trabajo sin que tú hayas tocado nada.

Que no cunda el pánico, porque lo que la norma persigue es la eliminación deliberada de esas marcas, no que tu optimizador de imágenes haga su trabajo de siempre.

Lo que sí saco de aquí es una conclusión práctica, y es que no puedes apoyarte en la marca técnica del proveedor como red de seguridad, porque tu propia web la borra sin querer. Tu obligación siempre fue el aviso visible, y ahí no hay atajo técnico que valga.

Por completar el panorama, ya circulan por ahí herramientas y repositorios que dicen eliminar la marca de agua del texto, y el propio Anthropic reconoce en sus limitaciones que la marca puede no detectarse si el texto se ha editado a fondo, parafraseado, traducido o mezclado con otra escritura, y que la ausencia de marca no demuestra que algo no venga de una IA.

No voy a enlazarlas, entre otras cosas porque quitar la marca a propósito es justo lo que la norma trata como incumplimiento. Y aprovecho para avisarte de lo que viene, porque en cuanto esto se sepa aparecerán plugins vendiéndote que «cumplen el AI Act preservando el C2PA», que es el marketing del miedo de toda la vida con etiqueta nueva.

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 te importa conservar la procedencia de las imágenes generadas con IA, revisa los ajustes de tu optimizador, porque casi todos borran los metadatos por defecto.
• 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, gratuitos y sin necesidad de atribución, con tres variantes según si el contenido es totalmente generado, parcialmente modificado o solo lleva IA por medio.

Tres cosas que conviene tener claras antes de usarlos:

• El icono es opcional pero el etiquetado no, y ponerlo no acredita por sí solo que cumples nada.
• La propia Comisión hizo pruebas con usuarios y el reconocimiento mejoró en todas las medidas cuando el icono iba acompañado de una etiqueta de texto, así que mejor los dos juntos que el icono a secas.
• Recomiendan que el icono sea legible por tecnologías de apoyo mediante alt o etiquetas ARIA que indiquen que el contenido es generado o manipulado por IA, algo que en WordPress te sale casi solo si rellenas el texto alternativo al subirlo.

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.