Seguro que lo has sufrido como usuario, como cuando estás leyendo un artículo y de repente carga una imagen o un anuncio por encima del texto, todo se desplaza hacia abajo de golpe y acabas pulsando justo donde no querías. Eso es el CLS.

Es de esas métricas que casi todo el mundo nombra y pocos entienden realmente, empezando por su propio nombre, que despista bastante.

Así que vamos a verlo con calma para saber qué es, qué mide exactamente, cómo se mide y, sobre todo, qué cosas concretas de tu WordPress te pueden estar bajando la nota y, en consecuencia, la experiencia de navegación de tus visitantes, que es lo importante.

Qué es el CLS

CLS son las siglas de Cumulative Layout Shift, en español algo como cambio de diseño acumulativo. O como yo lo entiendo, cuánto se mueve y baila el contenido de tu página sin que tú hayas hecho nada para provocarlo.

Forma parte de las Core Web Vitals (las métricas esenciales de experiencia web que usa Google), que son tres y miden cosas muy distintas.

El LCP mide lo que tarda en aparecer el contenido principal, el INP mide cómo de rápido responde tu web cuando interactúas con ella, y el CLS mide la estabilidad visual, o sea, que las cosas se queden quietas en su sitio.

El CLS no tiene nada que ver con la velocidad de carga, mide que tu web no dé bandazos.

¿Y por qué le da Google tanta importancia?

Pues porque un salto en mal momento es de las cosas que más fastidian al navegar, te hace perder el punto de lectura o pulsar un botón que no querías, y encima la estabilidad visual es uno de los factores que Google tiene en cuenta para posicionar.

Qué mide exactamente y cómo se calcula

Un «cambio de diseño» (en inglés layout shift) ocurre cuando un elemento visible cambia de posición de un fotograma al siguiente sin que tú lo hayas pedido.

Fíjate en lo de «sin que tú lo hayas pedido», porque es clave, pues los movimientos que provocas tú, como pulsar un botón y que se despliegue un menú, no cuentan.

El CLS solo penaliza los saltos inesperados, los que el usuario no ve venir.

Cada salto puntúa según dos cosas:

• Cuánta pantalla ocupa el elemento que se mueve.
• Cuánto se mueve respecto a la zona visible.

Cuanto más grande sea lo que se menea y más lejos lo haga peor nota. Un banner enorme que empuja media página puntúa muchísimo más que un iconito que se desplaza dos píxeles.

Y aquí está la trampa del nombre, porque eso de «acumulativo» te hace pensar que se suma todo lo que se mueve en la página de principio a fin, y desde 2021 ya no es así. Lo que hace Google es agrupar los saltos en ventanas de tiempo.

Una ventana se abre con el primer salto y se cierra cuando pasa un segundo sin que se mueva nada, con un tope de cinco segundos. Tu CLS no es la suma de todas las ventanas, es el de la peor.

Piénsalo como un camarero algo torpe que durante la comida te da varios golpes a la mesa. La nota no suma todos los meneos de toda la comida, agrupa los que pasan casi seguidos y se queda con el peor momento, esa racha en la que todo bailó a la vez.

El CLS mide tu peor racha de saltos, no el total de la página.

¿Qué nota está bien? Un CLS de 0,1 o menos es bueno, entre 0,1 y 0,25 es mejorable, y por encima de 0,25 es malo y toca ponerse. Tienes el detalle fino del cálculo en la documentación oficial de Google, pero con esto te haces una idea de sobra.

Dónde te recomiendo que midas el CLS

El CLS que cuenta para Google es el de tus usuarios reales. Se recoge de la gente que navega por tu web con Chrome, se promedia a lo largo de 28 días y se mira el percentil 75 (o sea, que de cada 100 visitas 75 tienen que ir bien para que apruebes).

El CLS que importa es el que sufren tus visitantes de carne y hueso, no cálculos o estimaciones de laboratorio o con herramientas de medición genéricas.

El sitio más directo para verlo es en la Search Console, en el informe de Core Web Vitals, que te dice si tienes problema y, mejor aún, en qué páginas concretas.

Ese dato real incluye toda la visita, no solo el momento de la carga.

Tus visitantes hacen scroll, y los saltos que pasan al bajar por la página cuentan exactamente igual, como una imagen que aparece más abajo y empuja, una cabecera fija que se encoge al desplazarte o un anuncio que se carga cuando llegas a su altura.

El CLS recoge también todo lo que se mueve mientras el usuario baja por la página, no solo lo que pasa al abrirla.

Por eso tu web puede parecer estable al abrirla y arrastrar igualmente un CLS malo, porque los saltos llegan más abajo, cuando el usuario hace scroll.

Un aviso para que no te agobies es que ese dato de campo va con retraso, tarda hasta 28 días en reflejar tus arreglos. Si haces cambios hoy no esperes ver la nota bajar mañana.

Los culpables: qué le hace un destrozo al CLS en WordPress

La buena noticia es que las causas son casi siempre las mismas cuatro o cinco, y la mayoría se arreglan con la misma idea de fondo.

Reservarle el sitio a cada elemento antes de que cargue es el 90% del trabajo contra el CLS.

Si el navegador ya sabe cuánto va a ocupar algo, no tiene que empujar el resto cuando aparece. Vamos con los sospechosos habituales.

Imágenes sin dimensiones

La número uno, con diferencia, y es que cuando una imagen carga sin que el navegador sepa de antemano su tamaño, aparece de golpe y empuja todo lo que tiene debajo.

Si tus imágenes no llevan sus dimensiones, ahí tienes la mitad de tu CLS.

WordPress ya añade el ancho y el alto a las imágenes que insertas, que es justo lo que el navegador necesita para reservarles el hueco, eso hay que reconocerlo.

El problema viene en los casos donde eso falla, como imágenes metidas por shortcode, insertadas por algunos maquetadores visuales, o con la carga diferida (lazy load) mal configurada.

Si reservar todos esos huecos a mano te da pereza, parte se puede automatizar.

Mi plugin gratuito DietPress añade automáticamente las dimensiones que les falten a tus imágenes, que es justo la causa número uno del CLS, y de paso pone las fuentes de Google en display=swap.

Lo que no te va a tocar son los banners de cookies, los anuncios ni lo que inyecta el JavaScript por su cuenta, así que eso sigue siendo cosa tuya. Pero la parte más gorda, la de las imágenes, te la quita de encima sin que hagas nada.

Fuentes web (FOIT y FOUT)

El navegador necesita un rato para descargar las fuentes de tu web, y mientras tanto tiene dos opciones, las dos con su problema.

• O no enseña el texto hasta que la fuente está lista (lo que se llama FOIT, texto invisible un instante).
• O lo enseña con una fuente del sistema y lo cambia cuando llega la tuya (FOUT).

El problema del segundo caso es que, si la fuente provisional y la tuya tienen tamaños distintos, el texto se reajusta y empuja lo que tiene alrededor.

Banners de cookies, avisos y anuncios

El segundo gran culpable después de las imágenes, el típico banner de cookies que aparece un segundo después de cargar la página y lo empuja todo hacia abajo, o el bloque de anuncios que reserva su hueco tarde.

Como aparecen después del primer pintado mueven el contenido que ya estabas mirando.

Elementos que se inyectan tarde con JavaScript

Carruseles, bloques de «productos relacionados», widgets, barras de aviso en la parte de arriba. Todo lo que un script añade a la página después de que se haya pintado por primera vez es candidato a empujar el contenido.

Pasa mucho también con los embeds. la inserción en el contenido de vídeos de YouTube o de publicaciones de redes sociales, cuando no van dentro de un contenedor con una proporción fija.

WooCommerce, si tienes tienda

Las tiendas tienen sus propios saltos, como las variaciones de producto que cambian el precio y mueven el botón de comprar justo cuando vas a pulsarlo, o el panel lateral del carrito que aparece y desplaza la página.

En una ficha de producto un salto a destiempo te puede costar una venta.

¿Es difícil saber qué está jodiendo mi CLS?

Saber que tienes CLS está bien, pero lo que necesitas es saber qué elemento es el que baila. Search Console te da las páginas con problema, que es la mitad del camino.

Para encontrar el elemento concreto, pega el siguiente código en la consola del navegador (en Chrome o similares, que es donde mide Google). haz scroll por toda la página de arriba abajo y luego escribe clsReport().

Te dirá el CLS real de tu visita y, lo importante, el elemento que más ha saltado.

(function () {
  let cls = 0;             // peor ventana hasta ahora
  let sessionValue = 0;    // ventana actual
  let sessionEntries = []; // saltos de la ventana actual
  let worstShift = null;   // el salto individual más grande
 
  const observer = new PerformanceObserver(function (list) {
    for (const entry of list.getEntries()) {
      // Los saltos que provoca el usuario (medio segundo tras pulsar) no cuentan
      if (entry.hadRecentInput) continue;
 
      const first = sessionEntries[0];
      const last = sessionEntries[sessionEntries.length - 1];
 
      // Misma ventana: menos de 1 s desde el último salto y menos de 5 s desde el primero
      if (sessionValue &&
          entry.startTime - last.startTime < 1000 &&
          entry.startTime - first.startTime < 5000) {
        sessionValue += entry.value;
        sessionEntries.push(entry);
      } else {
        sessionValue = entry.value;
        sessionEntries = [entry];
      }
 
      // El CLS es el de la peor ventana, no la suma de todas
      if (sessionValue > cls) cls = sessionValue;
 
      // Guardamos el salto más grande para señalar al culpable
      if (!worstShift || entry.value > worstShift.value) worstShift = entry;
    }
  });
 
  observer.observe({ type: 'layout-shift', buffered: true });
 
  // Llama a clsReport() cuando hayas hecho scroll por toda la página
  window.clsReport = function () {
    console.log('CLS de esta visita:', cls.toFixed(4));
    if (worstShift && worstShift.sources && worstShift.sources.length) {
      console.log('Elemento que más ha saltado:', worstShift.sources[0].node);
    } else {
      console.log('No se ha podido identificar el elemento.');
    }
  };
 
  console.log('Midiendo CLS. Haz scroll por toda la página y escribe clsReport()');
})();

Hace la misma cuenta de ventanas de sesión que usa Google, así que el número se parece bastante al que verás en Search Console. La diferencia es que aquí te señala el elemento culpable al momento.

Si te manejas con las herramientas de desarrollo del navegador el panel de rendimiento también te marca los saltos, pero con esto lo tienes en un par de líneas y sin andar rebuscando.

Por dónde empezar

Si te lo quieres tomar en serio sin ir a lo loco, este es el orden que yo sigo, por si te vale, y te fías:

1. Entra en Search Console y mira el informe de Core Web Vitals para saber si tienes problema y en qué páginas.
2. Revisa primero las imágenes sin dimensiones, que suelen ser la mitad del problema casi siempre.
3. Sigue con las fuentes y con el banner de cookies.
4. Revisa lo que carga tarde por JavaScript y lo que se mueve al hacer scroll.
5. Si tienes tienda repasa los puntos concretos de WooCommerce.
6. Vuelve a mirar la nota a las cuatro semanas, que el dato real ya te he comentado que va con retraso.

Por experiencia de mantener unas cuantas webs te digo que el CLS es de esas cosas que dan mucho miedo de lejos y poco de cerca.

Una vez entiendes que casi todo se reduce a reservarle el sitio a cada cosa antes de que cargue, dejas de perseguir saltos a ciegas.

Si quieres seguir aprendiendo cosas relacionadas igual te gusta un artículo que publiqué sobre la propiedad CSS content-visibility, que va justo de esto, de reservarle el hueco a lo que aún no se ve.

Y si te atascas con alguna de las causas concretas, o te surge alguna duda, me tienes ahí abajo en los comentarios.

No necesita tu contraseña, no necesita saltarse tu doble verificación, ni siquiera necesita tocar tu servidor, le basta con copiar la cookie que demuestra que has iniciado sesión y pegarla en otro navegador, y ya está dentro, como tú, con tus permisos.

Hace un par de años te conté que, según un estudio sobre más de 4,3 millones de webs hackeadas, el robo de cookies de sesión era el principal vector de infección de WordPress, por delante de los plugins y temas vulnerables.

Aquel artículo iba del dato y de la sorpresa, en este nos metemos en las tripas de ese secuestro, para saber cómo funciona la sesión de WordPress por dentro, por qué tu 2FA no te salva y qué puedes hacer hoy mismo para reforzar tu web todo lo posible.

Qué es el secuestro de sesión, y por qué el 2FA no te salva

Cuando entras en tu WordPress el sistema comprueba quién eres con tu usuario, tu contraseña y, si la tienes activa, la verificación en dos pasos. Una vez superado ese control te deja una cookie en el navegador que viene a decir «este es fulanito y ya ha pasado por caja».

A partir de ahí, en cada página que visitas, WordPress mira esa cookie en lugar de pedirte la contraseña otra vez, muy cómodo para ti, pero igual de cómodo para quien te robe la cookie.

Piénsalo como la pulsera de un festival, de heavy por ejemplo, que es lo que a mi me pone…

El de seguridad de la entrada te mira el DNI y la entrada, y si todo cuadra te pone la pulsera en la muñeca, una vez has entrado ya no te vuelve a pedir nada nadie, solo miran que lleves la pulsera. Si alguien te quita la pulsera y se la pone, entra en la zona VIP sin pasar por el control de la puerta, y el de seguridad ni se entera. Tu doble verificación es el de la puerta, la cookie es la pulsera.

Por eso, cuando te roban una cookie de sesión válida da exactamente igual que tengas doble verificación o incluso las modernísimas passkeys, toda esa protección vive en el momento del acceso, y la cookie robada ya está al otro lado de esa puerta.

El atacante no inicia sesión, no le hace falta, simplemente reutiliza tu pulsera cookie. A esto se le llama «pasar la cookie» (en inglés, pass the cookie), y es de lo más cabrón que hay, porque no deja casi rastro.

Y ojo, que esto no es un ataque de fuerza bruta, la fuerza bruta prueba contraseñas a saco contra tu login, y eso ya te lo explique´ aquí, el pase de cookie ni siquiera roza tu pantalla de acceso, es más sutil, e incluso más eficiente y rentable para el hacker.

Cómo funciona la sesión de WordPress por dentro

Aquí va un poco de fontanería, la justa para que entiendas por qué unas defensas sirven y otras no. WordPress no utilizla sesiones de PHP clásicas sino cookies firmadas. La prueba de que tú eres tú viaja en la propia cookie, no en un fichero de sesión guardado en el servidor.

Cuando inicias sesión WordPress te coloca un par de cookies:

• Una te identifica como usuario conectado en toda la web, la que empieza por wordpress_logged_in_
• Otra más restringida que solo viaja al escritorio y solo por HTTPS, la wordpress_sec_

Si abres la consola de tu navegador ahora mismo en tu WordPress no las vas a ver, y enseguida te explico por qué.

¿Qué llevan dentro esas cookies?

Tres cosas:

1. Tu nombre de usuario en texto plano
2. Una fecha de caducidad
3. Un identificador de sesión (un token) y una firma.

La firma se calcula con las claves salt de tu wp-config.php y con un trocito del hash de tu contraseña, y de ahí salen dos cosas que te valen luego.

Por un lado, sin esas claves salt nadie puede crearte una cookie válida de la nada., y por otro, como la firma depende de tu contraseña, en cuanto la cambias, las cookies viejas dejan de servir.

Desde WordPress 4.0, además, cada sesión tiene su propio token guardado en la base de datos. Eso es lo que te permite cerrar la sesión de un dispositivo concreto sin echar a los demás, y lo que hay detrás del botón «Cerrar sesión en el resto de sitios» de tu perfil de usuario (apúntate ese botón, que lo vamos a usar).

Por último, la caducidad, y es que por defecto una sesión de WordPress dura 2 días, o 14 días si marcas la casilla «Recuérdame» al entrar.

Cuanto más dura la sesión, más tiempo le sirve la cookie a quien te la robe, y catorce días es un mundo para un atacante.

Para colmo, con una cookie aún válida el hacker puede ir refrescándola para alargarle la vida otros tantos días.

El mito del XSS que te roba la cookie

Llegamos al detalle que te decía, y sobre el que incluso yo tenía malentendidos. Me refiero a eso que leemos tantas veces de que «un ataque XSS roba tu cookie de sesión y se la manda al atacante».

Como afirmación general sobre cookies vale, pero con las cookies de autenticación de WordPress no es exactamente lo que parece decir, no es literal.

Esas cookies llevan el atributo HttpOnly desde WordPress 2.7, y HttpOnly significa una cosa muy concreta, que el JavaScript del navegador no puede leer esas cookies.

Compruébalo tú mismo, que es de las pocas cosas de seguridad que puedes verificar en diez segundos. Entra en tu WordPress, abre la consola del navegador, escribe document.cookie y dale a INTRO.

No vas a ver ni rastro de las cookies de sesión, y si un script no las puede leer, no las puede robar por esa vía.

¿Quiere eso decir que un XSS es inofensivo en WordPress? Ni de coña. Lo que pasa es que el daño de un XSS no viene de leer tu cookie, viene de actuar montado sobre tu sesión ya abierta.

Si un script malintencionado se ejecuta en el navegador de un administrador puede crear un usuario administrador nuevo, instalar un plugin o colar una puerta trasera haciendo peticiones en tu nombre, sin necesidad de ver la cookie para nada. Es igual de grave, solo que el mecanismo es otro.

Si quieres entender el XSS a fondo y cómo frenarlo, tienes la guía completa aquí.

Así que el XSS no es por donde te roban la cookie en WordPress. ¿Por dónde entonces? pues por donde menos miras.

Entonces, ¿cómo leches te roban la cookie?

El sitio del robo casi nunca es tu web, sino el equipo desde el que administras tu WordPress. Estas son las vías reales, de la más común a la más tonta.

Malware ladrón de información en tu ordenador

Los llamados infostealer (programas cuyo único trabajo es robar información) leen directamente la base de datos de cookies de tu navegador y se llevan de golpe todas las sesiones que tengas abiertas, la de tu WordPress, la del banco y la del correo.

Familias como Lumma, RedLine o Vidar hacen justo esto, y aquí el HttpOnly no te protege de nada, porque no hay JavaScript, hay un programa leyendo ficheros en tu disco.

En los últimos meses esto se ha disparado, y se manejan cifras de miles de millones de cookies robadas de esta manera.

Proxies de phishing que se ponen en medio

Te llega un enlace, entras en una página que es un calco de tu login, metes tus datos y tu doble factor tan tranquilo, y resulta que esa página hacía de intermediario entre tú y tu web de verdad.

Tú entras, sí, pero por el camino el atacante se queda con la cookie ya válida. Hay herramientas que automatizan esto, y por eso el 2FA no las para.

Conexión sin HTTPS

Si tu web, o aunque solo sea tu login, no fuerza HTTPS, la cookie viaja en texto plano y cualquiera en la misma red wifi la puede pescar.

Esto era el pan nuestro de cada día hace años, hoy mucho menos, pero todavía hay webs por ahí sin HTTPS forzado.

Acceso físico al equipo

El más tonto y, a la vez, de los más frecuentes en oficinas, el ordenador sin bloquear mientras te vas a por un café.

Treinta segundos dan de sobra para copiar una cookie.

Cómo saber si te han secuestrado la sesión

Mala noticia, es difícil, porque para WordPress esa cookie es legítima, la firmó él mismo. No vas a tener un cartel rojo avisándote, pero hay señales a las que prestar atención:

• Sesiones o dispositivos activos que no reconoces, si tu herramienta de seguridad te los muestra.
• En el registro de actividad, accesos a horas raras, desde IPs o países que no son los tuyos, o acciones que tú no has hecho, como un plugin recién instalado o un usuario nuevo.
• Cambios que aparecen en la web sin que nadie los haya hecho por las vías normales.

Por eso un registro de actividad es lo que te da la foto de lo que pasa en tu web. Sin él vas a ciegas.

Cómo protegerse del secuestro de cookies

No te pienses que hay una solución mágica, ni rápida, aquí no hay bala de plata, porque el robo casi siempre ocurre fuera de WordPress, en tu equipo o en una página de phishing.

Lo que sí está en tu mano es reducir la ventana de tiempo y la superficie de ataque, capa a capa.

Fuerza HTTPS en toda la web, sin excepciones

Es lo más básico y es lo que cierra de golpe el robo por red. Cualquier hosting decente te da el certificado gratis, así que no tienes excusa.

Acorta la vida de la sesión y olvídate de «Recuérdame»

Con el filtro auth_cookie_expiration bajas la caducidad de la cookie, y cuanto menos dure, menos le sirve al que te la roba.

Por ejemplo, para dejarla en un día:

// Acortar duración de sesión de login a 1 día
function ayudawp_short_auth_cookie( $expiration, $user_id, $remember ) {
    return DAY_IN_SECONDS; // 1 día en segundos.
}
add_filter( 'auth_cookie_expiration', 'ayudawp_short_auth_cookie', 10, 3 );

Cierra la sesión cuando termines

Cerrar la pestaña del navegador no cierra la sesión, la cookie sigue viva y coleando. Acostúmbrate a darle a «Cerrar sesión» en tu WordPress, sobre todo en equipos que no son solo tuyos.

Echa a los inactivos y a las sesiones viejas

Desde tu perfil tienes el botón «Cerrar sesión en el resto de sitios» que te decía antes. Y si gestionas una web con varios usuarios, puedes forzar la desconexión de los usuarios inactivos cada cierto tiempo.

Cambia la contraseña para matar las cookies robadas

Como la firma de la cookie lleva un trozo del hash de tu contraseña, en cuanto la cambias, las cookies viejas dejan de valer.

Es de las poquísimas cosas que invalidan una cookie que ya te han robado, así que si sospechas algo, cambia la contraseña.

Rota las claves salt cuando sospeches

Cambiar las salt de tu wp-config.php cierra todas las sesiones de golpe, también la del intruso. Que quede claro, esto no evita el robo, es el interruptor de emergencia para echar a todo el mundo en un segundo.

Te conté cómo automatizarlo aquí.

Cuida el equipo desde el que administras, que es el eslabón de verdad

Antivirus al día, nada de instalar extensiones de navegador de dudosa procedencia, y ni se te ocurra administrar tu WordPress desde un ordenador público o compartido.

El infostealer entra por ahí, y mientras no limpies el equipo te van a robar la cookie las veces que haga falta.

Bloquea por IP y por user agent lo que no tenga sentido

Si a tu zona de administración solo entráis tú y dos personas más desde España, no hay motivo para permitir accesos desde medio mundo.

Limitar el acceso por IP ayuda, y bloquear agentes de usuario sospechosos suele ser todavía más eficaz.

Pon las cabeceras de seguridad y, si puedes, el atributo SameSite

Esto protege más contra el CSRF que contra el robo por infostealer, pero suma a la defensa general.

WordPress no pone el atributo SameSite en las cookies por defecto, lo tienes que añadir tú con un plugin, en el servidor o en tu CDN.

Para el resto de cabeceras tienes en analizador de seguridad con generador de cabeceras.

Pon verificación en dos pasos 2FA

Ya te he dicho que no te salva del pase de cookie, pero corta en seco el otro vector del estudio, el de las credenciales robadas, que era alrededor de siete de cada cien infecciones.

Tenlo activo, pero siendo consciente de qué cubre y qué no.

¿Y los plugins?

Para la gestión de sesiones Wordfence, Shield Security y Kadence Security tienen funciones específicas para esto.

En mi propio plugin gratuito, Vigilante, lo que te sirve aquí es el registro de actividad para cazar sesiones raras, la doble verificación, la URL de acceso personalizada y las reglas por IP para que cueste más robarte las credenciales, y la protección de la REST API para limitar lo que una sesión secuestrada puede tocar.

Lo que no hace WordPress, ni de serie ni la mayoría de plugins, es validar la sesión contra tu IP o tu dispositivo en cada visita.

El dato está ahí (desde WordPress 4.0 cada sesión guarda la IP y el navegador con que entraste, y los ves en plugins como Vigilante), pero en el núcleo de WordPress se decició no usarlo para cerrar sesiones, porque las IP cambian sin parar (móvil, VPN, IPv6) y acabaría echando a gente legítima a todas horas.

Ya me ha pasado, ¿qué hago ahora mismo?

Si tienes señales de que te han secuestrado la sesión, esto es lo que yo haría, en orden y sin perder tiempo:

1. Rota las claves salt ya mismo: Echas a todo el mundo de golpe, incluido el intruso, así que es lo primero, porque corta el acceso al instante.
2. Cambia las contraseñas de todos los administradores: Refuerza lo anterior e invalida cualquier cookie que siguiera viva.
3. Busca usuarios administradores que no hayas creado tú y bórralos: Es lo primero que suelen dejar plantado.
4. Pasa un escáner de integridad de archivos: Por si te han dejado una puerta trasera, y repasa el registro de actividad para saber qué tocaron y cuándo.
5. Revisa el equipo desde el que administras: Si fue un infostealer, mientras no lo limpies te van a robar la cookie nueva en cuanto vuelvas a entrar.

Si te supera, que no pasa nada, hay por ahí profesionales especializados en limpiar y reforzar webs WordPress.

Si hoy solo vas a hacer 3 cosas que sean estas: forzar HTTPS en toda la web, acostumbrarte a cerrar sesión de verdad al terminar y dejar de marcar «Recuérdame» en las webs que administras.

Con eso solo ya le quitas al ladrón de cookies la mitad del negocio, el resto, capa a capa, cuando vayas pudiendo. Lo demás ya es cosa tuya.

¿Te ha pasado alguna vez, o te queda alguna duda rondando? Me tienes aquí abajo, en los comentarios.

e aviso ya de una cosa: este miércoles no hubo Doctor WordPress, tuve que atender un asunto personal (nada grave, tranquilo), así que lo retomamos la semana que viene. Vamos al lío con lo que dio de sí el lunes, que fue un rato.

Seguridad: tus claves de IA al aire, WPScan de vuelta y actualizaciones a fuego lento

Empiezo por lo que más me hizo levantar la ceja. Con WordPress 7 llegó la pantalla de conectores, esa donde metes tu clave API de OpenAI, de Anthropic o de Google para enchufar la IA. Pues bien, desde Patchstack avisan de que esas claves se guardan en la base de datos tal cual, sin cifrar ni ofuscar ni nada. Si alguien entra en tu base de datos, se lleva tus claves y, con ellas, tus tokens, o sea, tu dinero.

Tampoco quiero meterte el miedo en el cuerpo: para llegar a tu base de datos hay que currárselo, no es algo que pase todos los días. Pero las claves de IA van a ser el nuevo botín que persigan los hackers, así que ojo. Mi apuesta es que esto lo arreglan pronto, seguro que ya están en ello.

Buenas noticias por el otro lado: WPScan está de vuelta con su versión 4.0.0. Para quien no lo conozca, WPScan es un escáner de seguridad gratuito, una especie de estándar del pen testing (los análisis de seguridad de toda la vida), que revisa tu WordPress, los plugins y demás en busca de agujeros. Llevaba parado un tiempo y vuelve con el escaneo mejorado y, sobre todo, como puerta para que los investigadores de seguridad reporten lo que encuentran. Te lo digo por experiencia propia: a mí me avisaron por ahí de una posible vulnerabilidad en uno de mis plugins, una tontería con un shortcode que casi no uso y por eso se me coló, y la arreglé en cuestión de segundos. Funciona, y funciona bien.

Y la tercera de seguridad, que es gorda: el «Protect the Shire» (proteger la comarca, sí, lo de Tolkien). Ahora, cuando un plugin sube una actualización, las actualizaciones automáticas no se aplican al momento, sino que la dejan enfriar 24 horas en cuarentena. ¿Para qué? Pues para dar tiempo a escanearla y revisarla, que es la mejor defensa contra los ataques a la cadena de suministro (el supply chain attack, cuando te cuelan código malo en un plugin legítimo). Lo enseñé en directo con mis propios plugins, que tenía un par recién subidos esperando su turno. Si fuera un parche de seguridad urgente se puede avisar a WordPress.org para que lo suelte ya, que no cunda el pánico. De todo esto te he escrito largo y tendido, tienes por qué ya no puedes fiarte ni de los plugins de WordPress.org y un tutorial bien completo sobre cómo proteger WordPress de los ataques XSS, que es el más popular contra webs WordPress.

Comunidad: el CERN se pasa a WordPress y el culebrón de WP Engine no afloja

WordPress estrena extensión oficial para el navegador y andan buscando testers para la 1.0. De momento está en GitHub, no la encontrarás todavía en las tiendas. La he probado y va fina: editar entradas, mostrar u ocultar la barra de admin, vaciar la caché de página, vista previa en móvil… La mayoría de cosas que ya hago con un par de extensiones sueltas, así que en cuanto salga la versión final las jubilo y me quedo con esta, que además es de código abierto y ampliable, como todo lo bueno de WordPress.

También han revivido la bolsa de empleo de WordPress.org, que llevaba 20 años muerta de asco. La han renovado entera y ahora se integra con tu perfil de WordPress.org, donde puedes marcarte como «abierto a oportunidades» para que te encuentren. Lo trasteé en directo y le veo una pega clara: le falta un buscador, navegar entre 191 páginas de candidatos no es serio. Ya tengo queja que mandar.

La noticia que más me gustó: el CERN, la cuna de la web, se pasa a WordPress. Hablamos de casi 600 webs que tenían en Drupal y que, tras meses de evaluación, migran a WordPress. Lo contaron en la WordCamp Europe en una sesión que se llama «Two Worlds Collide» y te la recomiendo, porque es el mejor gancho que vas a tener para convencer a un cliente dudoso. El sitio donde nació internet usa WordPress, con eso te lo he dicho todo.

Del FAIR Package Manager te cuento poco y con sinceridad. La idea de un repositorio descentralizado de plugins y temas, para no depender de WordPress.org, me parece de las que siempre molan, que descentralizar es bueno. Pero los dos fundadores lo dejaron por falta de financiación, ahora sigue otra gente, y yo no le veo mucho futuro, sobre todo por cómo ha nacido, que es de un cabreo. Y cuando estás cabreado, mejor no tomar decisiones.

Hablando de cabreos, el culebrón de WP Engine sigue su curso. El tribunal ha ordenado a WP Engine que revele esa parte del «strategy deck» de la que tanto se habla, y de paso le ha afeado a Matt Mullenweg que anda evadiendo respuestas en su declaración. Te lo resumo como lo veo: aquí no hay ganadores, solo perdedores, y los perdedores somos toda la comunidad WordPress por tener que gastar tiempo y energía en estas peleas. Ganadores no va a haber ninguno, ya te lo digo.

Desarrollo: Gutenberg 23.3, WooCommerce recoge cable y arranca WordPress 7.1

En el frente de desarrollo, Gutenberg ya va por la 23.3. Trae el escritorio personalizable (esto lo veremos con calma en el próximo Doctor WordPress) y, lo que más me gusta, el editor y el cargador de imágenes pasan a abrirse en una ventanita emergente, mucho más práctica que la pantalla gigante de antes. Recuerda siempre lo mismo: Gutenberg es para enredar y ver por dónde van los tiros, nunca lo instales en una web de verdad.

WooCommerce, por su parte, se carga el editor de productos basado en bloques, que desaparece en la versión 11. Lo avisaron hace tiempo y a mí me parece una recogida de cable como Dios manda. La lección, que la repito hasta cansarme: no uses jamás funciones beta de WooCommerce en producción, ni el editor de bloques, ni el TPV, ni las plantillas nuevas de email, porque un día te las quitan y te dejan el carrito o la página de pago colgando de un pincel.

Y ya ha arrancado el desarrollo de WordPress 7.1. Asoman el editor de medios emergente que acabamos de ver en Gutenberg, el procesamiento de medios dentro del propio servidor (hasta ahora tiraba de recursos externos) y, como plato fuerte, la edición colaborativa en tiempo real, que es justo lo que se cayó de la 7.0. Un detalle de cocina: venían con React 19 y han tenido que volver a la 18 porque cascaba. Si quieres ponerte al día con dos cosas que sí puedes tocar hoy mismo, te dejé cómo organizar la biblioteca de medios de una vez por todas y cómo personalizar el widget de actividad del escritorio para que muestre lo que de verdad te interesa.

WordPress e IA: el lío de SiteGround y el plugin oficial llega a la 1.0

Vamos con un drama de los que te gustan. El plugin de IA de SiteGround la lió, y te lo cuento yo, que colaboro con ellos desde hace 10 años y estoy encantado. A alguien se le ocurrió instalar el plugin en webs que no lo tenían sin avisar como toca, con una comunicación regular tirando a mala, y la gente se quejó, con toda la razón, hasta dejarlo en un 1,1 de valoración.

Estuvo mal hecho y lo digo bien claro, ahora bien, que quede claro también lo otro, y es que el plugin en sí es buenísimo, te da un montón de tokens de IA gratis por estar en SiteGround y te deja pedirle cosas a tu WordPress en lenguaje normal, del tipo «súbeme un 5% el precio de los productos variables de esta categoría entre tal día y tal otro», y te lo hace. El fallo fue de comunicación, no de producto.

En paralelo, el plugin oficial de IA de WordPress ha llegado a la 1.0, de momento en pruebas, y ha cambiado la dirección del equipo. Si andas dándole vueltas a la IA en tu sitio, te dejé dos chuletas: una sobre los resúmenes generados con IA en tus artículos (yo los genero con mi propio plugin y, mira, llevo decenas de posts y me he gastado 50 céntimos, una ridiculez) y otra sobre si merece la pena hacerte un plugin con IA, que depende del tipo de plugin, de cuánto sepas programar y del riesgo que estés dispuesto a asumir.

Aviso: la IA se deja la seguridad y se olvida de los nonces más de lo que te imaginas.

IA y SEO: Google se queda con tu tráfico y no lo va a devolver

Cierro con el panorama del tráfico, que está de capa caída y nadie le pone remedio. Las vistas previas con IA de Google, los AI Overviews, te están comiendo entre un 15% y casi un 50% de los clics orgánicos. Y lo peor no es el dato, es la tendencia: cada vez que sale una cifra nueva es a peor, nunca a mejor.

Así que no te montes la película de que el tráfico de Google ya volverá, porque no va a volver. Es como en Amazon, que lo primero que haces al comprar es filtrar por cuatro estrellas o más, ¿a que sí? Pues con la IA hacemos lo mismo todos, y todos significa todos.

En lo demás, Gemini 3.5 Flash se queda como modelo por defecto en el modo IA, y Google ha empezado a desplegar en Search Console unos informes de rendimiento de IA de los que, de momento, me fío entre cero y nada. Para ir tomando posiciones te conté cómo entrar entre las fuentes preferidas de noticias de Google y abrí el melón de si los plugins de SEO sirven de algo a estas alturas, que es mi siguiente batalla.

Te animo a leerlo, pero sobre todo a replanteártelo todo, porque el mundo ha cambiado delante de nuestras narices, y yo creo que para bien.

El vídeo completo, aquí

Hasta aquí el resumen, pero en el directo hay matices, capturas y algún que otro comentario que no cabe en un post, así que si te interesa cualquiera de estos temas te lo ves entero, que para eso lo grabo. Y si tienes dudas sobre SEO, IA o lo que sea, me tienes abajo en los comentarios, que para eso estamos.

La semana que viene volvemos con las Crónicas y, ahora sí, recupero el Doctor WordPress para enseñarte el escritorio personalizable que llega con WordPress 7.1. Te dejo el vídeo de esta semana:

#CrónicasWordPress – Noticias y opinión sobre WordPress con Fernando Tellado (15 de junio de 2026)

En serio, hay algunos plugins que son una maravilla pero otros pueden ser un coladero, y aparentemente no se distinguen, y no hay manera de saber si son buenos, malos o regulinchis.

La pantalla de descarga o instalación de plugins de WordPress no te cuenta si detrás hay alguien que controla lo que ha publicado o si es código soltado tal cual salió del primer prompt.

Pero antes de seguir creo que conviene separar dos cosas bien diferentes, te cuento…

Un plugin hecho por una IA, generado y subido sin que nadie lo revise, no tiene nada que ver con uno hecho con IA, donde una persona la usa de herramienta pero entiende, prueba y mantiene lo que sale.

Yo mismo uso Claude Code para casi todo, y no lo escondo, pero el papel principal lo llevo yo, estoy al mando, la IA es una herramienta más, y tampoco toma decisiones.

El problema no es que haya IA por medio, el problema está cuando no hay nadie al volante.

Si tú instalas plugins pero no los programas este artículo es para ti. No vamos a detectar si un plugin lo ha hecho una IA, eso ya lo conté en otro artículo, y además da bastante igual.

Lo que vamos a ver es cómo decidir si te puedes fiar de un plugin para meterlo en tu web, o en la de un cliente, da igual si detrás hay una persona, una IA, o las dos cosas a la vez.

«¿Lo ha hecho una IA?» ya no vale de filtro

A estas alturas la IA está metida en buena parte del código nuevo que se publica, así que saber que un plugin se hizo con IA no te dice nada sobre si es bueno o mediopensionista.

Hay código generado con IA y revisado a conciencia que es mejor que mucho código escrito a mano y mal programado, y también al revés.

Lo que de verdad cuenta es que haya detrás alguien competente que entiende lo que ha publicado, lo prueba, lo mantiene y responde cuando algo se tuerce, la herramienta es lo de menos.

Por eso lo que tienes que preguntarte es si te puedes fiar de quien hay detrás, y como tú no vas a leer el PHP o JavaScript línea a línea, esa confianza la vas a construir con señales que sí puedes ver desde fuera, más alguna comprobación que puedes hacer sin saber programar.

Vamos por partes.

Quién hay detrás es tu mejor pista si no eres programador

Cuando no puedes auditar el código la persona que lo mantiene es tu mejor garantía. No puedes o no sabes valorar si la programación está bien hecha, pero puedes evaluar a quien está detrás.

Quien entiende su plugin lo arregla cuando aparece un fallo, contesta las dudas con criterio y no desaparece al primer problema, pero quien ha escupido código que no entiende hace lo contrario, y eso se nota desde fuera mucho antes de instalar nada.

Esto es lo que miraría, más o menos por orden de importancia:

• Cómo responde en el foro de soporte, que es la prueba de fuego. Y no me refiero a que conteste rápido, sino a si contesta con cabeza. Entra en la pestaña de soporte del plugin en WordPress.org y lee las últimas consultas, porque si ante un «¿por qué tu plugin hace esto?» el autor explica el porqué, controla su código, y si suelta respuestas genéricas o no aparece es mala señal, ya que quien no sabe explicar su propio plugin tampoco suele saber leerlo, y menos mantenerlo.
• Si conoce en profundidad la solución para la que está diseñado el plugin. Cuando es de seguridad, que se le note que sabe de seguridad, porque es justo lo que le permite cazar lo que la IA hace mal. Un plugin de seguridad escrito por alguien que no controla de seguridad es de los inventos más peligrosos que te puedes echar a la cara.
• Su historial como desarrollador. Mira si tiene más plugins, pre-IA y post-IA, desde cuándo publica y qué reputación tiene fuera del repositorio, porque un nombre con recorrido y cara visible da bastante más tranquilidad que una cuenta recién creada con un único plugin y sin rastro de quién está detrás.
• Cómo reacciona ante un fallo de seguridad o errores graves, que es de lo más revelador. Busca si alguna vez le han reportado un problema serio y fíjate en cuánto tardó en sacar la corrección, porque un autor que parchea rápido y avisa a sus usuarios es justo lo que quieres, y uno que ignora el aviso durante meses no merece entrar tu web.
• Qué pasaría si desaparece el plugin. Pregúntate si el plugin sobrevive a que su autor se canse, porque uno de una sola persona sin nadie más detrás es bastante más frágil que uno con una empresa o una comunidad que pueda seguir manteniéndolo.
• Si no oculta el uso de IA, aunque con matices. Que el developer reconozca que la usa está bien como muestra de transparencia, pero no te fíes solo de eso, que reconocerlo ya es lo normal y lo hace igual quien trabaja bien y quien suelta basura. Lo que no se puede fingir es ser capaz de mantener y arreglar lo que has publicado.

Señales que cualquiera puede ver sin tocar el código

Antes incluso de mirar el código, la propia ficha del plugin te cuenta bastante si sabes dónde fijarte. Esto lo ve cualquiera desde la página del plugin en WordPress.org.

• Instalaciones activas y cómo evolucionan: No es lo mismo un plugin con 30 instalaciones que uno con 30.000, pero no te quedes solo con el número, porque un plugin que sube poco a poco indica que la gente lo instala y lo deja puesto, que es la mejor reseña que hay.
• Última versión compatible: Comprueba que esté probado con la última versión de WordPress o una muy cercana, porque si pone que se probó hace cuatro versiones, o está abandonado o el autor no lo sigue, y en ambos casos es un aviso.
• Registro de cambios: Échale un ojo al changelog, que si cada versión explica qué se ha arreglado con un mínimo de detalle hay alguien pendiente, y si son entradas genéricas tipo «mejoras varias y corrección de errores» repetidas una y otra vez, huele a volcado sin nadie revisando.
• Lee las reseñas, no solo la puntuación: No te quedes con la media de estrellas, vete a las de una y dos estrellas, que ahí es donde se ve si el plugin rompe webs, si el soporte pasa de la gente o si hay un problema recurrente que el autor no resuelve.
• Lo que promete frente a lo que pide: Desconfía de un plugin sencillo que pide permisos o accesos que no le pegan, o que promete mil funciones imposibles de mantener por una sola persona, porque cuanto más abarca algo hecho deprisa, más sitios hay para que algo se rompa o quede a medias.
• Si aparece en las bases de vulnerabilidades: Busca el nombre del plugin en Patchstack y en WPScan, que llevan el registro de fallos conocidos en plugins de WordPress. Que aparezca no es necesariamente malo, lo importante es que se corrigiera rápido, pero que tenga vulnerabilidades sin parchear sí es para salir corriendo.

Revisa el código aunque no sepas programar

Y ahora la parte más útil, porque puedes revisar el código de un plugin sin entender ni una línea de PHP, solo ayudándote en herramientas que lo leen por ti. Sí, sé lo que estás pensando, tú sigue leyendo…

Nada de esto es una auditoría de seguridad en condiciones, ojo, eso ya es otra liga, pero te sirve de sobra para oler problemas antes de meter el plugin en tu web.

Pásale el Plugin Check

El Plugin Check es el plugin oficial del equipo de revisión de WordPress.org, el mismo que se usa para revisar los plugins antes de aceptarlos en el repositorio.

Lo instalas en una web de pruebas, lo pasas sobre el plugin que estás evaluando y te muestra un informe con los problemas de seguridad, rendimiento y estándares que encuentra.

Tú no lees el código, lees el veredicto, así que si sale lleno de errores en rojo ya sabes lo que hay. Yo lo uso al crear mis plugins, pero funciona igual de bien para revisar el de otro.

Mira las alertas de Query Monitor

El Query Monitor es otro imprescindible para la web de pruebas. Con el plugin activado navega por tu web y fíjate en si aparecen alertas en rojo, como consultas lentas a la base de datos, errores de PHP o llamadas que tardan demasiado.

No necesitas entender qué pasa por dentro para ver que hay banderas rojas donde no debería haberlas.

Abre el archivo principal y busca señales gordas

Aunque no sepas programar puedes abrir el archivo principal del plugin con cualquier editor de texto y cazar algunas cosas a ojo:

• Que tenga una cabecera en condiciones con el nombre del autor, la versión y la compatibilidad.
• Que no haya claves de API escritas a pelo en mitad del código.
• Que no aparezcan bloques larguísimos de texto ilegible, lo que se llama código ofuscado y que casi siempre sirve para esconder algo, ni funciones con nombres como eval o base64_decode repartidas por todos lados.
• Que no llame a direcciones web externas raras que no pinten nada ahí.

Es posible, más que probable, que no entiendas la lógica, pero estas señales saltan a la vista.

Pídele a una IA que te lo audite

Acertaste, y sí,  aquí está el giro divertido, usar la IA para vigilar un plugin que probablemente se hizo con IA.

Descarga el plugin, sube el archivo o el zip a Claude Code o Codex de OpenAI  y pídele que te lo revise con un prompt directo, a la yugular, algo así:

Revisa este plugin WordPress y dime si tiene problemas de seguridad, qué datos envía a servidores externos y si sigue las buenas prácticas de WordPress

En un par de minutos te señala los puntos flojos que tú no sabrías ni por dónde mirar. Eso sí, la IA tampoco es infalible auditando, te da pistas muy buenas pero no un certificado, así que tómatelo como una opinión (documentada) más y no como la última palabra.

Y siempre, pruébalo en un sitio de pruebas

Esto vale para cualquier plugin, lo haya tocado una IA o no, nunca pruebes uno nuevo directamente en tu web en producción.

Móntalo primero en un WordPress local o en un staging donde puedas romper cosas sin consecuencias, actívalo, dale caña y comprueba que hace lo que dice sin romper nada más.

Si supera esa prueba y ha aguantado las comprobaciones anteriores, ya te puedes plantear ponerlo en serio.

Repaso rápido antes de instalar

Para que no se te olvide nada, este es el repaso que yo haría antes de meter un plugin en una web que me importe algo:

• Leer las últimas respuestas del autor en el foro de soporte y ver si contesta con criterio.
• Comprobar que está probado con la versión actual de WordPress o muy cercana.
• Mirar el registro de cambios y descartar los que solo ponen «correcciones varias» versión tras versión.
• Leer las reseñas de una y dos estrellas, no solo la media.
• Buscar el plugin en Patchstack y WPScan por si tiene vulnerabilidades sin corregir.
• Pasarle el Plugin Check en una web de pruebas y revisar el informe.
• Pedirle a una IA que le eche un vistazo al código y avise de lo que huela raro.
• Probarlo en local o en staging antes de tocar producción.

Y si quieres una chuleta de un vistazo con lo que te debe dar buen o mal rollo, pues nada, a mandar:

Un ejemplo que puedes comprobar tú mismo

Todo esto suena muy bien en teoría, así que aplícalo con cualquier plugin que te plantees instalar, los míos incluidos.

Pilla VigIA o cualquiera de mis otros plugins, que salieron de muchas horas de trabajo, con ayuda de IA por supuesto, no lo escondo, y pásales la lista.

Entra en sus foros, mira quién contesta las dudas (este aquí presente casi siempre), revisa el registro de cambios, comprueba con qué versión están probados, pásales el Plugin Check.

Lo que tienes que buscar es justo eso, que haya alguien dando la cara y manteniendo el invento, dé igual que el código lo escribiera a mano o con una IA al lado.

Esa es la idea con cualquier plugin que vayas a instalar. Olvídate de si lo ha hecho una máquina o una persona y fíjate en si hay alguien competente detrás que responde cuando algo se tuerce.

Y si te pica el gusanillo de entender qué falla cuando la IA programa sola, o de hacerte tú tus propios plugins, en el blog tienes cuándo merece la pena crear un plugin con IA y la guía completa de programar WordPress con IA para seguir aprendiendo.

El texto alternativo es lo que hace que tus imágenes se entiendan cuando no se ven, sobre todo para las personas que navegan con un lector de pantalla. Si lo pones bien ayudas a quien no puede ver la imagen y de paso le das a Google algo que entender. Si no lo pones, o lo pones mal, no le sirve a nadie.

En este tutorial vamos a ver que es el texto alternativo, para qué sirve, en qué se diferencia del título, la leyenda y la descripción, qué imágenes hay que describir y cuáles van vacías, cómo escribir un alt que sea útil, y cómo te puede echar una mano la IA sin que te la líe. Y sí, de camino te pones a bien con la accesibilidad, que cada vez es menos opcional.

Qué es el texto alternativo o alt y para qué sirve

El texto alternativo, o atributo alt, es la descripción que le pones a una imagen para cuando esa imagen no se puede ver. Y es eso, un atributo de la etiqueta de imagen, no una etiqueta en sí misma, que esto lo confunde muchísima gente. En el código se ve así:<img src="logo.png" alt="Logo de Ayuda WordPress">.

Sirve para tres cosas, y el orden es importante.

1. La primera, y la que justifica su existencia, es lo que un lector de pantalla le lee en voz alta a una persona ciega o con baja visión. Si la imagen aporta información y no tiene alt, a esa persona la pierdes como lector (o cliente).
2. El navegador muestra si la imagen no carga, porque el servidor falla o la conexión va a pedales.
3. Es una señal que Google usa para entender de qué va la imagen y colocarla en su buscador de imágenes.

Te lo apunto aquí porque es el origen de muchos malentendidos … y errores:

El alt es, primero accesibilidad, y luego, SEO, no al revés.

Cuando rellenas el alt pensando solo en meter la palabra clave, le estás colgando un cartel a alguien que no lo puede leer. No le aporta nada, y encima a Google hace años que no le cuela.

En los estándares esto es el criterio 1.1.1 de las WCAG, «Contenido no textual», y es de nivel A, o sea el suelo, el requisito de accesibilidad más básico que existe. Si no cumples ese, no cumples ninguno.

Alt, título, leyenda y descripción, para qué sirve cada uno

Cuando subes una imagen a WordPress te encuentras con cuatro campos para rellenar, y aquí empieza el jaleo, porque cada uno se guarda en un sitio distinto, acaba en un lugar distinto y se comporta de forma distinta.

Por resumirte, el único que de verdad importa para accesibilidad es el texto alternativo. El resto son … otra cosa.

Y ahora unas cuantas mentiras que conviene ir aparcando, porque llevan años circulando, y alguna la conté yo mismo hace siglos, todo hay que decirlo, que algo he aprendido 20 años después y si la cago la cago.

• WordPress no te rellena el alt con el nombre del archivo. Lo que autocompleta a partir del nombre del archivo es el campo título, no el alt, que sale vacío y lo tienes que escribir tú.
• El atributo título no es obligatorio ni hace falta para «cumplir el W3C», nunca lo fue. El navegador lo enseña como un globito al pasar el ratón por encima, en el móvil ni se ve, y los lectores de pantalla no lo leen de forma fiable. No te vale como sustituto del alt.
• El campo «Descripción» no es el atributo título. Son cosas distintas que van a sitios distintos.

Sobre la pregunta de siempre, la de si el título de la imagen ayuda al SEO, pues resulta que no, el alt sí, el título prácticamente nada. Si tienes que dedicarle tiempo a algo dedícaselo al alt.

¿Las imágenes decorativas necesitan alt?

No todas las imágenes hay que describirlas. Las que son puro adorno, una línea separadora, un fondo, un icono decorativo que no aporta información, tienen su propia regla, y es justo la que más se incumple.

Para una imagen decorativa el alt va vacío del todo. Así: alt="".

Con eso le dices al lector de pantalla que se salte la imagen, que no hace falta que la narre. Es como el hilo musical del ascensor, está bien que esté, pero no necesitas que nadie te lo vaya cantando.

Hay tres maneras de hacerlo y solo una es correcta:

• alt="" vacío del todo: correcto. El lector de pantalla la ignora y a otra cosa.
• Sin atributo alt: mal. Algunos lectores de pantalla, al no encontrar alt, leen el nombre del archivo o sueltan un «imagen» a secas, que es ruido.
• alt="-", un asterisco, un espacio o «lo que te apetezca»: mal, mal y mal. Eso es contenido, y el lector de pantalla lo lee. Le estás metiendo basura en los oídos a quien intenta navegar.

Para saber si una imagen es decorativa hay un truco sencillo, quítala mentalmente. Si al quitarla no se pierde nada de información, es decorativa y va con el alt vacío. Si se pierde algo, hay que describirla.

Y si quieres afinar caso por caso hay dos herramientas que vienen de perlas.

• El árbol de decisión del W3C, que te va preguntando por el tipo y la función de la imagen hasta decirte qué poner.
• El mapa de decisión en español de Olga Carreras, que es de lo mejor que hay sobre esto en nuestro idioma.

Cómo escribir un alt útil

El alt describe la función de la imagen en esa página, no solo lo que se ve en ella. Esa es la idea fundamental, porque la misma foto puede necesitar un alt distinto según para qué la has puesto.

Unas zapatillas en un artículo sobre running se describen de una forma, y esas mismas zapatillas en la ficha de producto de tu tienda, de otra.

Con eso claro, cuatro reglas sencillas:

• Describe lo importante, no todo: Ve a lo que aporta la imagen en ese contexto.
• No te repitas empezando con cosas como «imagen de» o «foto de»: El lector de pantalla ya avisa de que es una imagen, así que se lo estarías diciendo dos veces.
• Sé breve: Como referencia, unos 125 caracteres suelen bastar, pero sin obsesionarse, que lo que importa es que sea útil.
• Mete la palabra clave solo si encaja de forma natural: Si tienes que forzarla con calzador, fuera.

No te lo cuento, te lo muestro con ejemplos, que se entiende mucho mejor.

• Una foto informativa:
  • Mal: alt="foto".
  • Peor: alt="zapatillas running comprar mejores zapatillas baratas".
  • Bien: alt="Zapatillas de running azules con suela de espuma, vistas de perfil".
• Una captura de pantalla: Describe lo relevante de la captura, no pongas «captura de pantalla».
  • Bien: alt="Ajustes de Medios de WordPress con la opción de organizar por carpetas activada".
• Una imagen que es un enlace o un botón: El alt describe a dónde lleva o qué hace, no cómo es.
  • Para un logo que enlaza al inicio: alt="Ayuda WordPress, ir al inicio", no alt="logo".
• Una gráfica o una infografía: Resume el dato principal en el alt, y si lleva mucha chicha, pon el detalle en el texto de al lado o enlaza a una versión larga.

¿Vale generar el alt automáticamente?, con IA por ejemplo

Sí, es posible, y no es ni siquiera mala idea. WordPress no te genera el alt por su cuenta, así que necesitas un plugin, y hay dos formas de hacerlo automático que conviene no confundir, porque dan resultados muy distintos.

Usando plantillas, sin IA

Varios plugins de SEO rellenan el alt a partir de datos que ya tienes, el título de publicación, el nombre del archivo o la palabra clave.

• AIOSEO, por ejemplo, con su función de SEO para imágenes, te deja montar una plantilla con sus tags y aplicarla a toda la biblioteca de una tacada.
  El problema es que el alt o sale genérico y casi siempre repetido, porque todas las imágenes de un artículo acaban con el mismo texto, y para alguien con un lector de pantalla eso es casi tan inútil como no tener nada.
• SEOPress, por su parte, hace algo parecido, creando el alt a partir del nombre del archivo, así que depende de ti subirlos en nombres descriptivos.
  En este caso la dependencia eres tú, o los redactores, que no suban las imágenes como las captura la cámara, tipo DSC22999W.JPG o parecido.

La ventaja de estos sistemas, de ambos es que son automáticos, baratos y no te cuestan nada por imagen. Te sirven de red de seguridad para que ninguna imagen quede pelada, no para tener un alt bueno.

Con IA

La segunda es con modelos IA, plugins y servicios que de verdad miran la imagen y la describen.

Aquí entran incluso el propio WordPress, que tiene un plugin oficial de experimentos IA que también lo hace, pero eso sí, vale para trastear en entornos de pruebas, no para tenerlo en producción.

Da igual el que elijas, hay muchos, tienes que conectar tu clave de un proveedor como OpenAI, Google o Anthropic, y todos te cobran por uso.

Un aviso para los del editor clásico, que sois somos unos cuantos, casi todas estas funciones están pensadas para el editor de bloques, así que igual ni ves los botones, aunque la generación en lote desde la biblioteca suele funcionar igual.

Y tanto por plantilla como con IA, hay un techo que conviene tener clarísimo.

La IA describe lo que ve en la imagen, pero no sabe para qué la has puesto tú en esa página, ni cuándo una imagen es solo decoración.

Es como pedirle el pie de foto a alguien que no ha leído tu artículo, te describe la foto de maravilla, pero no tiene ni idea de qué pinta ahí. Te va a poner un alt a todo, incluida la línea separadora que debería ir vacía, y a la imagen que en realidad es un botón le describe el dibujito en lugar de decir a dónde lleva.

Incluso el plugin oficial intenta seguir el árbol de decisión del W3C que te enseñé antes, y aun así arrastra fallos con las imágenes decorativas.

Así que lo automático, sea plantilla o IA, úsalo como punto de partida para no tener miles de imágenes a cero, y repasa tú a mano las que importen de verdad.

Las decorativas, a vaciarles el alt, las que son enlaces o botones, a describir la acción, y las que cumplen una función concreta en el artículo, a comprobar que se entienden.

Lo automático te quita el ochenta por ciento del trabajo, pero el veinte por ciento que decide si cumples o no lo pones tú.

¿Y la accesibilidad? La regulación EAA

Y ya que hablamos de hacer las cosas bien, va un plus que quizá no tenías en la cabeza, y es que desde el 28 de junio de 2025 poner bien el texto alternativo, además de ser lo suyo, ahora también te lo pide la ley.

La European Accessibility Act, que en España se traspone con la Ley 11/2023, es de obligado cumplimiento desde esa fecha, y esta vez con sanciones de las que duelen, no como las recomendaciones de antes que no cumplía ni el tato.

La buena noticia, y va en serio, es que el alt es de los requisitos más fáciles de cumplir de toda la normativa.

La técnica de referencia es la norma EN 301 549, apoyada en las WCAG a nivel AA, y dentro de eso el alt, ese criterio 1.1.1 de antes, es nivel A, el básico.

También es de los más fáciles de auditar, porque un validador de accesibilidad te canta en segundos qué imágenes se han quedado sin alt.

¿Te afecta?, pues depende

Las microempresas que prestan servicios, menos de 10 trabajadores y menos de 2 millones de euros de facturación o de balance, están exentas de parte de los requisitos, aunque ojo, que la exención hay que poder justificarla si te la vienen a mirar, no es un «como soy pequeño paso de todo».

Y, por supuesto, si tienes una tienda online, vendes a consumidores o prestas según qué servicios, lo más probable es que sí estés dentro.

No voy a entrar en un análisis jurídico sobre EEA, ni de lejos, no es lo mío ni procede, de momento quédate con lo práctico, pon bien el alt de tus imágenes y este requisito, el más visible y el más fácil de comprobar, lo tienes cubierto.

Por cierto, si quieres ver cómo queda esto por escrito, tienes mi propia declaración de accesibilidad como ejemplo. Y si tienes una web con la que te juegas algo y prefieres que alguien le eche un vistazo serio a la accesibilidad, para eso está mi consultoría.

¿Y las imágenes que ya tengo sin texto alternativo?

Si llevas años publicando, tendrás un buen montón de imágenes sin alt, y ponerte al día es parte del trabajo. La cosa tiene dos fases, encontrarlas y arreglarlas.

Para encontrarlas tienes herramientas de accesibilidad como WAVE o la extensión axe DevTools, que te marcan en la propia página qué imágenes van sin alt, y el informe de accesibilidad de Lighthouse, dentro de las herramientas de desarrollo de Chrome, que te lista los fallos de una URL.

Y más visual, mi analizador de accesibilidad online y gratis.

Para una entrada suelta, a veces basta con abrir el código fuente y buscar las etiquetas de imagen sin alt, para arreglarlas en lote valen los mismos dos enfoques de antes (plantilla, automatismos, con o sin IA)

Una cosa muy chula que poca gente sabe es que el plugin oficial de pruebas de WordPress trae hasta un comando de consola, wp ai alt-text generate, para lanzarlo por WP-CLI.

Sea como sea prioriza con sentido común y lógica de equilibrio entre esfuerzo y resultados. Primero ponte con las imágenes que aportan información en tus artículos más visitados, que son las que más gente con lector de pantalla se va a encontrar. Las decorativas las vacías, y para el resto, lo automático como red y el repaso a mano de las que son importantes.

Preguntas rápidas

¿Pongo el título o el alt cuando la imagen es un enlace?

Lo que importa es el alt, y debe describir a dónde lleva el enlace o qué hace el botón, no cómo es la imagen. El título del enlace aporta poco y no te hace falta.

Lo importante es que quien no ve la imagen entienda qué va a pasar si hace clic.

¿Puedo poner el mismo alt en varias imágenes?

Si son la misma imagen cumpliendo la misma función se puede repetir sin problema.

Lo que no tiene sentido es copiar y pegar el mismo altTu código aquí en imágenes distintas por pereza, porque cada una muestra algo diferente y merece su propia descripción.

¿Cambia algo en las imágenes de productos de WooCommerce?

El criterio es el mismo, pero en una ficha de producto el alt de la imagen principal debería describir el producto de forma útil, con el modelo, el color o algún detalle que lo identifique, que además es justo lo que te ayuda a aparecer en Google Imágenes. Nada de rellenar con la palabra clave repetida una y otra vez.

¿Hago algo ya mismo?

Si quieres terminar el día habiendo hecho algo de provecho esto es lo mínimo:

1. Abre tus 5 entradas más visitadas y revísalas imagen por imagen.
2. La que no tenga alt, o tenga el nombre del archivo metido como alt, arréglala ahora describiendo su función en ese artículo.
3. La que sea pura decoración déjale el alt vacío.

En diez minutos le has arreglado el día a alguien que navega con lector de pantalla, y de paso le has dado a Google algo mejor que entender.

Lo demás, la auditoría completa, el repaso de toda la biblioteca, dejarlo automático con IA, lo puedes ir haciendo con calma. Pero ese primer paso dalo ya hoy.

Si te ha quedado alguna duda, o no ves claro si una imagen va con alt o sin él, me tienes ahí abajo en los comentarios. Cuéntamelo y lo vemos.

Es en realidad el mismo plugin, mismo sitio en el repositorio, en parte la misma filosofía de optimizar WordPress con el mínimo esfuerzo, pero con un cambio de fondo que llevabais tiempo pidiéndome muchos.

Si lo que buscas es la optimización que te daría un WP Rocket pero sin conexiones a servicios externos ni dependencias de terceros, todo funcionando en tu propio servidor y gratis, este es el camino que ha tomado el plugin.

No es un plugin de caché de página, de eso ya se encarga tu hosting, sino todo lo demás, y sin que nada salga de tu servidor.

Te cuento de dónde viene el cambio, qué tienes que hacer si ya lo tenías (prácticamente nada) y todo lo que trae de nuevo.

El viaje de WPO Tweaks a DietPress

WPO Tweaks es uno de mis plugins más veteranos, de casi 10 años, que nació con una idea muy simple, activarlo y olvidarte.

Quita de un plumazo todo lo que WordPress carga por defecto y que la mayoría de webs no necesita, los emojis, los Dashicons en la parte pública, un montón de líneas de la cabecera, esas cosas que no aportan nada pero suman peticiones y milisegundos.

Con el tiempo fue creciendo y dejó de ser solo un limpiador para convertirse en un plugin de rendimiento de verdad, con CSS crítico, defer de JavaScript, optimización de imágenes para mejorar el CLS, resource hints, y reglas de caché de navegador, GZIP y Brotli en el .htaccess.

En la versión 2 le cambié el nombre a Zero Config Performance Optimization, porque ya hacía mucho más que cuatro retoques. Y ahí estaba el problema, del que no me daba cuenta del todo.

Justo por no dejarte configurar nada, el plugin se había quedado estancado.

Mucha gente quería elegir qué activar y qué no, y alguna optimización podía chocar con un tema o un maquetador concreto. Sin un interruptor para apagar solo esa, la única salida era desactivar el plugin entero, que es una pena cuando el resto te funciona de maravilla.

Mientras tanto, yo tenía otro plugin rondando que se llamaba precisamente DietPress (su nombre interno era core-diet).

Salió de mi guía sobre todas las funcionalidades de WordPress que puedes desactivar y planteaba justo lo contrario, una interfaz completa de ajustes organizada por nivel de riesgo, con unas setenta opciones de optimización, todas desactivadas por defecto.

Buena interfaz, una idea chula, funcionamiento perfecto, y además potente, pero poca gente lo usaba.

Así que la jugada estaba clara, juntarlos, tomar el esqueleto configurable de DietPress y montarle encima el motor de rendimiento de WPO Tweaks. Un solo plugin, con lo mejor de los dos.

Si ya tenías WPO Tweaks, no tienes que hacer nada

Esto es importante, porque un cambio así puede dar respeto, pero no hay de qué preocupase pues todas las optimizaciones que el plugin aplicaba hasta ahora siguen activas por defecto cuando actualizas, así que tu web se va a comportar inicialmente exactamente igual que antes.

La única diferencia es que ahora cada una de esas optimizaciones es una opción que puedes afinar o apagar si te hace falta.

Hay algún detalle que además mejora respecto a antes. Me refiero a la parte del CSS crítico que a veces provocaba un parpadeo raro al cargar (el típico flash sin estilos) ahora es una opción aparte, marcada como experimental y desactivada por defecto.

La parte segura, el CSS crítico en línea, se queda activa, y si alguna vez notaste ese parpadeo, ya no lo vas a tener salvo que lo actives a propósito.

Y si eres de los que personaliza el plugin con código, los filtros para desarrolladores han cambiado al prefijo dietpress_. Los antiguos siguen funcionando para no romperte nada, pero quedan marcados como obsoletos, así que cuando puedas pásate a los nuevos.

Si tenías el DietPress antiguo (core-diet)

Y si lo que tenías era el otro, ese DietPress, queda retirado, con honores. Dentro de nada lo cierro en el repositorio de WordPress, así que dejará de poder descargarse y de recibir actualizaciones.

Si lo tienes instalado no se va a romper nada, pero conviene que te pases al nuevo, y es muy fácil:

• Instala y activa el nuevo DietPress desde su página en WordPress.org o el instalador de plugins de tu web.
• Tus ajustes se conservan sin hacer nada, porque los dos plugins los guardan en el mismo sitio, y el core-diet antiguo se desactiva automáticamente para que no haya conflictos.
• Con el nuevo DietPress ya activo, puedes borrar tranquilamente el plugin viejo desde tu pantalla de plugins.

Lo único importante es instalar el nuevo antes de borrar el viejo, así no pierdes la configuración. Y si no haces nada el plugin antiguo seguirá funcionando, pero sin actualizaciones ni soporte.

¿En qué se ha convertido WPO Tweaks… perdón, DietPress?

La fusión toma las optimizaciones de rendimiento de WPO Tweaks, la configurabilidad de DietPress y, de paso, el nombre y la interfaz del segundo, que es más simpática y deja más claro el concepto, poner tu WordPress una dieta y quitarle todo lo que le sobra.

Ahora el plugin tiene su propio menú en la administración, DietPress, y el montón de opciones (decenas) están repartidas por nivel de riesgo, igual que en mi guía de funcionalidades.

Tienes las que puedes quitar sin pensártelo, las que conviene valorar antes según tu web y las más específicas de cada caso. Cada opción te explica qué hace y qué podrías perder, para que decidas con criterio y no a ciegas.

Me tomé mucho tiempo en redactar textos para cada ajuste, para que sepas qué pasa exactamente si lo activas, así que de paso es casi un tutorial de optimización WordPress.

La pantalla de inicio funciona como una báscula (de hecho se llama así), y te muestra de un vistazo lo que estás ahorrando (peticiones que quitas, CSS y JavaScript de los que te libras, consultas a la base de datos que evitas) y trae un par de cosas que vienen muy bien.

Tienes perfiles rápidos para aplicar de golpe una configuración pensada para blog personal, tienda WooCommerce, página de aterrizaje o limpieza máxima.

También incorpora un analizador que mira tu web y tus plugins activos y te sugiere qué tiene sentido desactivar en tu caso concreto.

Por último (de momento) si gestionas varias webs, puedes exportar tu configuración a un archivo y aplicarla igual en las demás, sin ir opción por opción.

Ya no hay ajustes de seguridad, lógico

Hay una decisión de diseño que quiero explicarte, porque si vienes de mi guía de funcionalidades te puede chirriar, pero la lógica nos dice que un plugin de rendimiento y dieta no debería andar tocando la seguridad de tu web.

Por eso DietPress no incluye las opciones de seguridad que tenía core-diet, como ocultar la versión de WordPress, desactivar XML-RPC, bloquear las contraseñas de aplicación o esconder los errores de inicio de sesión.

Todo eso es terreno de Vigilante, mi plugin de seguridad, que es su lugar natural.

En la guía de desactivar funcionalidades sí tienes el código para hacer esos cambios a mano, pero dentro de un plugin lo lógico es separar responsabilidades, DietPress adelgaza y optimiza, Vigilante protege. Cada uno a lo suyo y los dos gratis.

Un optimizador gratis y con todo bajo control

La diferencia de fondo con un plugin de pago como WP Rocket está en que todo lo que hace DietPress ocurre en tu propio servidor sin servicios externos, ni cuenta que crear, ni cuota mensual, ni tu CSS o tus métricas viajando a la nube de nadie.

Es software libre, gratis 100%, y lo que pasa en tu web se queda en tu web.

Eso tiene un límite, como lo que te comenté de que no hace caché de página, pero si tienes un alojamiento decente ya la tienes funcionando a nivel de servidor.

Hay además cosas que necesitan sí o sí infraestructura externa para ir bien, como analizar página por página para quitar el CSS que no se usa, y eso no está en el plugin a propósito, porque hacerlo bien exige servidores dedicados y hacerlo mal te rompe la web.

DietPress hace todo lo que se puede hacer bien en local y lo deja ahí.

Así que si lo que buscabas era esa optimización a lo WP Rocket pero sin ataduras ni dependencias de terceros, por ahí van los tiros.

Hacia dónde va

Esto es solo el primer paso de DietPress, pero se avecinan montones de mejoras que lo van a convertir poco a poco en un imprescindible para quien quiera optimizar WordPress a tope y gratis.

Pronto vendrá, por ejemplo, una pestaña para controlar todos los correos automáticos que WordPress envía por su cuenta, los avisos de actualización, los de comentarios, los de usuarios nuevos y compañía, que sé que a más de uno le saturan la bandeja.

La base la expliqué en mi guía de los emails de WordPress, y pronto lo vas a poder hacer desde DietPress con un clic.

También tengo pensado incorporar la carga selectiva, para que WooCommerce, Contact Form 7 o los bloques de Gutenberg no carguen sus archivos en las páginas donde no se usan.

Algo que va a entrar seguro es  el alojamiento local de las fuentes de Google, que mejora la privacidad, te quita una dependencia externa más y cumple el RGPD sin despeinarte.

La filosofía no cambia, quitar lo que sobra y optimizar todo lo que se pueda, en tu servidor y gratis.

Y poco más, DietPress ya está en el repositorio, listo para instalar o actualizar.

Si te va más tocar cada cosa a mano con código, tienes la guía completa con todos los snippets, pero si prefieres todo eso a base de clics, más las optimizaciones de rendimiento y sin complicarte, instala DietPress y a volar.

Ya me cuentas, si eso, qué te parece el cambio/evolución, estoy deseando leerte (abajo, en los comentarios, que las redes se las lleva el viento)

¡De nada!

Y es que resulta que cuando cambias el slug de una entrada en WordPress, la URL antigua sigue funcionando con una redirección a la nueva, eso lo hace una función nativa, del core, que se llama wp_old_slug_redirect().

Ni plugin ni nada, esta joyita viene de serie, pero casi nadie sabe que está ahí, ni que se puede incluso tocar para que haga lo que tú quieras.

Te cuento cómo funciona por dentro, dónde están sus límites (las páginas, sobre todo) y cómo personalizarla para que haga lo que necesites.

Cómo funciona la redirección automática de slugs antiguos

Cuando editas el slug de una entrada ya publicada, por ejemplo cambias /mi-articulo/ por /articulo-definitivo/, WordPress no se limita a cambiar la URL.

Lo que hace es guardar el slug antiguo en la tabla wp_postmeta con la clave _wp_old_slug asociada a esa entrada. De eso se encarga la función wp_check_for_changed_slugs(), que compara el slug nuevo con el anterior cada vez que actualizas algo.

A partir de esoe moment entra en juego wp_old_slug_redirect(), enganchada al hook template_redirect.

Cuando alguien llega por la URL antigua, en vez de entregar un feo error 404, esta función busca si ese slug está guardado en algún _wp_old_slug y, si lo encuentra, hace un 301 permanente a la URL actual con wp_redirect( $link, 301 ).

Así la URL vieja sigue viva, no rompes los enlaces que apuntan desde fuera y el SEO no se resiente, porque el 301 traspasa la autoridad de enlaces.

Un par de detalles más que conviene que sepas.

• Guarda todos los slugs antiguos, no solo el último. Si le cambias el slug tres veces a una entrada, las tres URLs viejas siguen redirigiendo bien a la actual.
• También cubre los cambios en enlaces permanentes con estructura de fecha. Si tu URL lleva año y mes y cambias la fecha de publicación, el core guarda un _wp_old_date y la redirección lo tiene en cuenta igual.

Cómo personalizar el comportamiento

WordPress ofrece dos filtros para tocar estas redirecciones sin reescribir nada, y para lo que no cubren puedes montarte tu propia versión.

Cambiar la URL de destino

El filtro old_slug_redirect_url (disponible desde WordPress 4.4) te deja modificar la URL de destino a la que se redirige, justo antes de que se ejecute el 301.

Es perfecto si quieres añadir parámetros de seguimiento, o mandar el tráfico de las URLs viejas a otro sitio. Aquí tienes un ejemplo:

/**
 * Modifica la URL de destino usada para redirecciones de slugs antiguos
 *
 * @param string $link La URL a la que va a redirigir WordPress
 * @return string La (posiblemente modificada) URL de destino
 */
add_filter( 'old_slug_redirect_url', 'ayudawp_old_slug_redirect_url' );
function ayudawp_old_slug_redirect_url( $link ) {

	// Ejemplo: etiqueta las URLs viejas para poderles rastrearlas en Google Analytics
	return add_query_arg( 'utm_source', 'old-slug', $link );
}

Si devuelves una cadena vacía o false cancelas la redirección para esa petición y dejas que WordPress siga su curso, que normalmente acaba en el 404.

Decidir a qué entrada apunta

El otro filtro, old_slug_redirect_post_id (desde WordPress 4.9.3), actúa un paso antes y cambia el ID de la entrada que WordPress ha localizado a partir del slug antiguo.

Lo normal es usarlo para casos puntuales, como redirigir el slug antiguo de una entrada que has borrado hacia otra que la sustituye. Si devuelves 0 desactivas la redirección para esa petición.

/**
 * Cambia qué entrada resuelve un slug antiguo antes de que salte la redirección
 *
 * @param int $id El ID de la entrada asignado al antiguo slug
 * @return int E ID de la entrada a la que redirigir (devuelve 0 para cancelar la redirección)
 */
add_filter( 'old_slug_redirect_post_id', 'ayudawp_old_slug_redirect_post_id' ); 
function ayudawp_old_slug_redirect_post_id( $id ) {

	// Devuelve 0 para cancelar la redirección o a un ID distitno para apuntar a otro sitio.
	return $id;
}

Desactivar completamente la redirección

Si prefieres que WordPress no haga ninguna de estas redirecciones automáticas, porque las gestionas con un plugin o porque te han dado guerra, basta con quitar la función del hook.

// Desactivar las redirecciones automáticas de WordPress de antiguos slugs en todo el sitio 
remove_action( 'template_redirect', 'wp_old_slug_redirect' );

Ponlo en un mu-plugin para que no dependas del tema o de un plugin de códigos. A partir de este momento los _wp_old_slug que ya tengas guardados dejan de redirigir, aunque siguen ocupando sitio en la base de datos hasta que los borres.

Eso con las entradas ¿funciona también con páginas?

Esto es un poco putada. Todo lo anterior funciona con entradas y con tipos de contenido personalizados sin jerarquía, pero no con las páginas.

Si cambias el slug de una página WordPress ni siquiera guarda el _wp_old_slug, así que la URL vieja te devuelve un 404 a pelo.

No es un despiste de WordPress, está hecho aposta.

La función wp_check_for_changed_slugs() descarta los tipos de contenido jerárquicos, y wp_old_slug_redirect() hace lo mismo con un if ( is_post_type_hierarchical( $post_type ) ) return;.

El motivo es por rendimiento, porque en las páginas la URL se crea con la jerarquía de las superiores (si las hay), así que cambiar el slug de una página madre o superior afectaría a las URLs de todas sus hijas, y resolver eso bien obligaría a una búsqueda por árbol que el core prefiere ahorrarse.

Pero…

… puedes hacer que funcione también con páginas

Como el core pasa de las páginas, si las necesitas cubiertas con redirecciones automáticas te toca hacer dos cosas por tu cuenta, guardar el slug antiguo cuando cambie y montar después la redirección.

Lo primero es guardar el slug antiguo de la página al actualizarla, que es justo lo que el core no hace.

/**
 * Almacena el slug antiguo de las páginas que WordPress evitaba hacer al ser
 * las páginas un tipo de contenido jerárquico
 *
 * @param int     $post_id     El ID de la página
 * @param WP_Post $post_after  La página después de actualizar
 * @param WP_Post $post_before La página antes de actualizar
 */
add_action( 'post_updated', 'ayudawp_save_old_page_slug', 10, 3 ); 
function ayudawp_save_old_page_slug( $post_id, $post_after, $post_before ) {

	// Solo páginas publicadas cuyo slug haya cambiado
	if ( 'page' !== $post_after->post_type || 'publish' !== $post_after->post_status ) {
		return;
	}

	if ( '' === $post_before->post_name || $post_after->post_name === $post_before->post_name ) {
		return;
	}

	// Almacena el slug anterior, evitando duplicados
	$old_slugs = (array) get_post_meta( $post_id, '_wp_old_slug' );

	if ( ! in_array( $post_before->post_name, $old_slugs, true ) ) {
		add_post_meta( $post_id, '_wp_old_slug', $post_before->post_name );
	}
}

Y lo segundo es la redirección en sí, que solo salta en los 404 para no cargar el resto de páginas.

/**
 * Redirect an old page slug to its current permalink.
 * WordPress core only does this for non-hierarchical post types.
 */
add_action( 'template_redirect', 'ayudawp_old_page_slug_redirect' ); 
function ayudawp_old_page_slug_redirect() {

	// Actúa solo en los 404 en los que se solicitó una ruta de página
	if ( ! is_404() || '' === get_query_var( 'pagename' ) ) {
		return;
	}

	// Usa el último segmento de ruta como el slug donde buscar
	$parts = explode( '/', untrailingslashit( get_query_var( 'pagename' ) ) );
	$slug  = end( $parts );

	$pages = get_posts(
		array(
			'post_type'   => 'page',
			'post_status' => 'publish',
			'numberposts' => 1,
			'meta_key'    => '_wp_old_slug',
			'meta_value'  => $slug,
		)
	);

	if ( ! empty( $pages ) ) {
		wp_safe_redirect( get_permalink( $pages[0]->ID ), 301 );
		exit;
	}
}

Con esto cubres el caso normal, que es cambiar el slug de una página concreta.

Lo que no resuelve es cuando cambias el slug de una página superior y quieres que redirijan también las URLs antiguas de sus hijas, porque ahí entra el lío del árbol de jerarquías del que se libra el core.

Y como aquí el código de estado lo controlas tú, si quieres un 302 temporal en vez del 301, solo tienes que cambiar el número en el código.

Cuidado con los plugins de redirecciones

Si tienes instalado un plugin de redirecciones del tipo Redirection o las herramientas para redirecciones de los plugins de SEO como Rank Math, porque pueden pisar el sistema nativo.

A más de uno le ha pasado que tras instalarlo los _wp_old_slug que WordPress había guardado dejan de redirigir y las URLs antiguas acaban en un 404.

No pasa siempre ni con todos los plugins pero si cambias un slug y la redirección automática no salta como esperabas, revisa si algún plugin está interceptando antes el template_redirect.

Cómo limpiar los _wp_old_slug que se acumulan

Cada cambio de slug deja un registro nuevo en wp_postmeta, y eso en una web con muchos años y muchos cambios se va acumulando, y aunque no es nada grave, si quieres hacer limpieza o te encuentras con una redirección rara que apunta donde no debe, puedes borrarlos.

La forma más directa es por SQL, y como siempre, antes haz una copia de seguridad, porque esto elimina de golpe todas las redirecciones de slug que tengas en marcha. Cambia wp_ por el prefijo real de tu instalación.

DELETE FROM wp_postmeta WHERE meta_key = '_wp_old_slug';

Si usas WP-CLI lo lanzas con wp db query, y si solo quieres limpiar una página o entrada concreta puedes usar wp post meta delete con el ID de esa entrada y la clave _wp_old_slug, sin tocar el resto.

¿Redirección nativa o plugin?

Para que lo tengas como resumen, esto es lo que cubre el sistema nativo y cuándo igual es mejor usar otra cosa.

Mi consejo es que no instales un plugin de redirecciones solo porque has cambiado un par de slugs de entradas, que para eso WordPress ya se apaña solo.

Guárdate el plugin para cuando de verdad lo necesites, como cambios masivos de estructura o migraciones, y para las páginas tira del código de aquí arriba, te lo deja resuelto sin cargar el sitio con otro plugin más.

Crónicas WordPress: WordCamp Europe, seguridad y novedades del core

Lo más gordo de la semana ha sido la WordCamp Europe en Cracovia, y por eso me salté un par de citas las semanas anteriores, que no era por vaguería. Pasaron por allí más de 2.400 entradas, con un Contributor Day en el que estuve desde el primer día revisando plugins y traduciendo, charlas muy chulas sobre desarrollo y futuro de WordPress, y sobre todo mucho conocer gente, que al final es lo que más mola.

En la sesión de preguntas no estuvo Matt Mullenweg, pero sí Mary Hubbard, Matías Ventura y Rich Tabor. De Matías no tengo más que buenas palabras, atiende a todo el mundo con una educación que da gusto. Yo además di un taller sobre SEO el último día.

Una de las charlas que más me gustó fue la primera, sobre que el CERN, sí, el de Suiza donde investigan el origen del universo, ha elegido WordPress para su web después de evaluar varios gestores. Ahí lo dejo. Y apunta esto en la agenda, que la WordCamp Europe de 2027 será en Málaga, del 27 al 29 de mayo. Si puedes ir, ve, y si te animas a colaborar en la organización, mejor todavía. Reserva hotel pronto, que Málaga llena todo el año.

En cuota de mercado WordPress ha bajado un pelín, alrededor de un punto, así que tampoco nos volvamos locos. Lo que sube de verdad es la categoría de webs sin CMS, esos HTML estáticos que ahora mucha gente genera con IA para cosas que, siendo sinceros, tampoco necesitaban un WordPress entero. Wix, Shopify y compañía suben miajas.

La vulnerabilidad gorda de la semana fue la de Kirki, esa biblioteca que usan un montón de temas. Un fallo crítico, 9,8 sobre 10, que permitía colarse y escalar privilegios por el mecanismo de restablecer la contraseña. Ya está parcheado en la 6.0.7 y se resolvió antes de la WordCamp. Quien lo encontró se llevó 6.400 dólares del programa de recompensas de Wordfence. Lo bueno de WordPress es justo esto, que las vulnerabilidades se conocen, se publican y se arreglan en el minuto cero.

A mí mismo un investigador me avisó hace poco de una posibilidad en un shortcode de uno de mis plugins, y lo dejé arreglado esa misma tarde antes de que nadie corriera peligro.

Y vamos con la noticia de seguridad más importante en años. A partir de ahora las actualizaciones de plugins también pasan revisión antes de distribuirse. Hasta hace nada solo se revisaban los plugins nuevos, así que alguien podía subir un plugin limpio de 20 KB y colar malware en la siguiente actualización.

Eso se acabó. Lo han llamado Protect the Shire, con su Wapuu Gandalf y todo, y refuerza muchísimo la seguridad de WordPress.

En WordPress.org han renovado un par de cosas más. La bolsa de empleo (jobs.wordpress.net) estrena cara para publicar ofertas y ofrecerte como candidato, y los perfiles han cambiado por completo, con medallas por código, comunidad o traducciones y una medición del impacto de tus contribuciones. La métrica está todavía verde, que a mí las revisiones de traducciones, que son las que más hago, me las puntúa flojas, pero la idea está bien.

De Gutenberg 23.3 te digo lo de siempre, que mola mucho pero no lo instales en producción. Es un plugin de pruebas y todo lo que trae acaba llegando a WordPress tarde o temprano. Lo más llamativo es el nuevo escritorio personalizable, que enseño en el Doctor del miércoles, el editor de medios en ventana emergente y la colaboración en tiempo real, que se retrasa de la 7.0 a la 7.1. Esa función la pedimos todos y no la va a usar casi nadie, pero hay que sacarla para llegar por fin a la fase 4, el multiidioma, que es lo que de verdad necesitamos fuera del mundo anglosajón.

También soy muy fan de la paleta de comandos (Comando + K en el escritorio), que tiene una pinta estupenda como interfaz para la IA dentro de WordPress, y cualquiera que haga plugins puede añadirle sus propios comandos con dos archivos. En Vigilante ya le he metido alguno.

En el blog he publicado bastante sobre seguridad estos días. Por ejemplo, cómo proteger WordPress de ataques XSS, un glosario interactivo de términos de seguridad y un tutorial para personalizar el widget de actividad del escritorio. Y ahí va el recordatorio de siempre, que no me canso de repetir.

El código que pongo en Ayuda WordPress está probado y con capturas, no es un copia y pega de ChatGPT. Sobre hacer plugins con IA, que me preguntáis mucho, monté unas preguntas frecuentes. La clave es contestarte con sinceridad a unas cuantas preguntas antes de lanzarte, y la más importante es si sabrías entender, actualizar y arreglar ese código el día que te quedes sin IA. Si la respuesta es no, malo. Y ojo si hay dinero, datos personales o identificaciones de por medio, que ahí te metes en un jardín de responsabilidades.

Del SEO, o AEO, o como queramos llamarlo ahora, Google ha sacado un informe de rendimiento para las búsquedas con IA, con las impresiones, en qué consultas apareces, desde qué países y demás. Tráfico, lo que se dice tráfico, trae bien poco. Enlazado con el taller de la WordCamp, publiqué también una reflexión sobre si los plugins de SEO siguen sirviendo de algo, qué funciones ya no tienen sentido y cuáles puedes resolver con un plugin ligerito o directamente con código.

Dos apuntes caseros para cerrar. Mi plugin de seguridad, Vigilante, ya ha pasado las 1.000 instalaciones activas y las 12.000 descargas, y eso que lo lancé a mediados de febrero. En la 2.6 he metido detección de plugins cerrados y más refuerzos en el cortafuegos. Y si no la conoces, échale un vistazo a la página de herramientas gratis de Ayuda WordPress: generadores de código, analizador de seguridad, optimizador de imágenes (que uso a diario) y hasta una calculadora para freelances.

Tienes la sesión completa en el vídeo de las Crónicas WordPress de esta semana.

Doctor WordPress: cómo cumplir gratis con el derecho de desistimiento de la UE

El miércoles me salté un poco el guion porque me había surgido la necesidad. Desde el 19 de junio de 2026, una directiva europea (la 2023/2673) obliga a todos los comercios online de la UE, o que vendan a clientes de la UE, a ofrecer una función de desistimiento digital que sea como mínimo tan fácil de usar como el propio proceso de compra. Y me tocó la moral ver que a varios clientes les estaban ofreciendo por email soluciones de pago que no cumplían ni la mitad de lo que pide la ley. Así que me informé bien, consulté con abogados especializados en derecho del consumidor y me hice un plugin.

Se llama EU Withdrawal Compliance, es 100% gratis y funciona tengas WooCommerce o no. Lo subí a mediados de mayo y en menos de un mes ya pasa de las 1.000 instalaciones. Esto es, por encima, lo que hace:

• Crea automáticamente la página de desistimiento con su formulario, y también puedes colocarlo donde quieras con un shortcode.
• Confirmación en dos pasos y acuse de recibo en soporte duradero, descargable en PDF y con un hash de verificación.
• Registro a prueba de manipulaciones: queda guardado cualquier cambio, lo haga el cliente o la propia tienda, por si surgen disputas.
• Formulario de desistimiento según el anexo I-B de la directiva, incluida una versión imprimible para quien lo prefiera en papel.
• Doble consentimiento en la página de pago y aviso público de los productos excluidos, los del artículo 16, como los servicios ya iniciados, los perecederos, los hechos a medida o los precintados por higiene, por categoría o producto a producto.
• Columna de desistimientos en los pedidos, exportación a CSV, acciones por lotes y trazabilidad completa de cada solicitud.
• Integración con las herramientas de privacidad de WordPress, para exportar y borrar datos personales.

Voy ampliándolo según me lo pedís en el foro: un widget de escritorio con contadores de solicitudes pendientes, exclusión de clientes B2B, un campo para el IBAN, filtros de búsqueda para tiendas grandes y emails un poco más monos. Si lo pruebas y te sirve, se agradecen las reseñas, y si tienes dudas al foro, que contesto a todo.

Como siempre, el directo se fue por las ramas para bien. Comentamos que Wordfence acaba de poner de pago la verificación en dos pasos que antes era gratis, repasé la comparativa de plugins de seguridad (cada vez quedan menos opciones decentes y gratis, y por eso sigo ampliando Vigilante) y caímos otra vez en la IA, el tema de moda últimamente. Te resumo mi postura. WordPress va a seguir siendo clave, no hay nada tan compatible con todo, y menos para una tienda online. La IA es una herramienta estupenda y quien no la use se quedará atrás, pero no te vuelvas loco gastando IA de pago en tareas que resuelves en dos clics desde el escritorio. Para lo demás ya integro Abilities API y MCP en mis plugins (Vigilante tiene su propio MCP), y así le pides las cosas a Claude directamente.

Tienes el Doctor WordPress completo, con la demo del plugin paso a paso, en el vídeo Derecho de desistimiento de la UE.

Y hasta aquí la semana. Nos vemos en directo el lunes en las Crónicas y el miércoles en el Doctor, en el canal de Ayuda WordPress. Si te pasas pregunta lo que quieras, que para eso estamos.

Es una duda razonable, así que vale la pena resolverla antes de tocar ningún ajuste, porque de poco sirve el cómo si no tienes claro el porqué.

Un resumen no te quita lectores, retiene a los que ya se iban

Quien aterriza en tu entrada y no tiene treinta segundos de paciencia se va a marchar igual, le pongas resumen o no. La diferencia es que con un resumen breve se lleva al menos la idea principal y tu marca en la cabeza, en vez de volver a Google y meterse en el blog de al lado.

Ese resumen compite con el botón de atrás del navegador, que es por donde se te escapa la gente, no con tu artículo.

Además, puede ir plegado por defecto, así que el que viene a leerse el texto entero ni lo abre ni le estorba. Solo lo despliega quien tenía prisa y quería el atajo, con lo que no le restas nada al lector de fondo y le das una salida al que iba a rebotar.

Hay otra razón que pesa más cada día, y es que ya no escribes solo para personas. Las IAs rastrean y resumen tu contenido quieras o no, y unas veces lo hacen bien y otras se inventan media historia. Si publicas tu propio resumen, con un enlace a tu fuente y bien marcado para los buscadores, pones tu versión por delante, en lugar de dejar que la máquina improvise la suya.

Y luego está lo de siempre, que la gente escanea antes de comprometerse a leer nada largo. Los estudios de usabilidad del Nielsen Norman Group llevan años midiéndolo, y un visitante medio lee solo entre un 20 y un 28% de lo que hay en una página. Un resumen es justo para ese visitante que está decidiendo si tu artículo le merece la pena, que casualmente es el que más rebota.

Eso sí, un resumen no hace milagros, porque si la entrada es corta no merece la pena, porque resumir algo que se lee en un minuto no aporta. Y cuando lo genera una máquina a veces sale flojo, así que los artículos que de verdad te importan conviene repasarlos y retocarlos a mano.

Con el SEO ándate con cuidado, porque un resumen no te va a subir puestos por sí solo, y mal planteado hasta puede competir con tu propio artículo en Google. Luego vemos cómo evitarlo.

Generar el resumen: con IA, sin IA o tirando del chatbot del lector

Antes de mirar plugins conviene que sepas que hay tres maneras distintas de ofrecer resúmenes, y no dan el mismo resultado ni cuestan lo mismo.

1. Generar el resumen con IA en tu propio sitio: Un proveedor como OpenAI, Anthropic o Google redacta el resumen en frases nuevas y se guarda en la entrada. Es la opción de más calidad, porque redacta de verdad, pero el consumo lo pagas tú.
2. Generarlo sin IA, por extracción: Aquí no hay ningún proveedor de por medio, el propio plugin analiza tu texto y se queda con las frases más representativas. Sale más básico, porque recorta y pega en vez de redactar, pero es gratis y funciona en cualquier WordPress.
3. No generar nada en tu web, mandar al lector al chatbot: El botón abre ChatGPT, Claude o el que sea con tu contenido, y el resumen se genera allí con la cuenta del propio lector. No te cuesta nada, pero el resumen no queda guardado en tu sitio ni lo ven los buscadores, es cosa de cada visitante.

Según la vía cambian tres cosas, quién paga el consumo, si el resumen queda guardado en tu web y si necesitas WordPress 7.0. Tenlo presente, porque es justo lo que diferencia a unos plugins de otros.

Qué plugins hay para generar resúmenes de contenidos y en qué se diferencian

Antes de enseñarte el que uso yo, conviene separar el grano de la paja, porque aquí se mezclan cosas que no son lo mismo.

Unos plugins generan un resumen y lo dejan en tu web, y otros solo ponen un botón que manda a tu lector a un chatbot. Lo segundo está bien, pero es lo que ya hace cualquier botón de compartir, no un resumen en tu sitio.

Dicho esto, vamos a ver qué tenemos por ahí.

Plugins que generan el resumen en tu web

• SummarAIze genera las cinco ideas clave de cada entrada con IA y las muestra en la página, arriba, abajo o en una ventana emergente. El plugin es gratis pero la IA funciona con tu propia clave de OpenAI o Gemini metida en su panel, no con los conectores de WordPress, así que el consumo lo pagas tú directamente a OpenAI o a Google, no al plugin. Solo admite esos dos proveedores, y el resumen lo generas tú desde el editor o en lote, no hay botón para que lo lance el visitante.
  Un detalle es que alega que sus resúmenes están preparados para posicionar por sí mismos, o sea que no hace nada por evitar que compitan con tu artículo en Google. Esto sinceramente no lo entiendo, o soy nuevo en Internet o la idea debería ser justo la contraria.
• TLDRWP es más parecido a lo que estamos hablando, porque lo genera con IA en tu sitio, guarda el resumen y deja que el visitante lo pida desde la entrada, pagando tú el consumo.
  La diferencia es que se apoya en otro plugin (AI Services) para conectar con la IA, no tiene vía gratis sin IA ni usa los conectores de WordPress y, de momento, está en GitHub y no en el directorio oficial de WordPress.
• AI Share & Summarize genera el resumen de las dos maneras, con IA si tienes un conector de WordPress configurado y, si no, con un sistema de extracción en PHP que funciona gratis.
  Lo muestra dentro de la entrada, en un bloque plegable que el lector despliega cuando quiere. Y además de resumir, pone botones para compartir en redes sociales y en los principales asistentes de IA, y lleva su propia analítica de clics para que veas qué se comparte y por dónde. Como es el que uso para el tutorial, todo esto lo explico en detalle luego.

Plugins que solo mandan al lector a un chatbot

• Sumtics no genera ningún resumen en tu web. Pone un botón, flotante o dentro del contenido, que abre el asistente que elija el lector (ChatGPT, Gemini, Claude, Grok o Perplexity) para que el resumen se haga allí, con la cuenta del propio lector. Es gratis para ti y no te cuesta consumo, pero el resumen no queda en tu sitio. Su ficha lo vende como generación automática de resúmenes, pero no es verdad, son botones de enviar a IA, el mecanismo es ese.
• AI Post Summarizer hace lo mismo que Sumtics, aunque su ficha hable de resúmenes TLDR. Su propio readme aclara que el botón abre ChatGPT o Google AI en una pestaña nueva con tu contenido, que todo pasa en el navegador del lector y que no se guarda nada. La versión gratis se queda en esos dos asistentes, y la Pro, de pago, añade Claude, Gemini, Perplexity, Grok y DeepSeek, más un motor de diseño, analítica y ajustes por entrada, pero sigue siendo un botón que abre el chatbot, no un resumen en tu web.

Comparativa rápida de plugins para generar resúmenes con IA

¿Me lo «resumes»? ¿cuál es mejor?

Si lo que quieres es un botón que mande a tu lector a su chatbot, Sumtics o AI Post Summarizer te valen, también AI Share & Summarize, y no consumen tokens de IA, pero eso ya lo hace cualquier botón de compartir y el resumen no queda en tu web.

Si lo que buscas es un resumen de verdad, integrado, sin salir de la web, guardado en la entrada y visible para lectores y buscadores, los que compiten son SummarAIze, TLDRWP y AI Share & Summarize, que además este último es el único que genera también sin IA y el único que funciona gratis sin pagar a ninguna IA, sin necesitar siquiera WordPress 7.0.

Y ya que el que mejor encaja es AI Share & Summarize, sí, el mío, te cuento cómo va. Es gratis del todo, sin versión premium ni sorpresas. Si le falta algo, me lo pides y lo añado, que actualizo mis plugins casi cada semana y me paso por los foros de soporte a diario. Yo mismo lo uso, porque los plugins los hago para que me convenzan a mí antes que a nadie, y te aseguro que más quisquilloso y exigente que yo no hay en todo el directorio, ni en el resto del universo conocido, hasta donde se sabe.

Ahora que ya lo he dejado claro, te explico cómo hacer esta cosa de los resúmenes, con AI Share & Summarize, que ya te habrás dado cuenta de que es el más completo.

Cómo activar los resúmenes paso a paso

Si todavía no lo tienes, instala AI Share & Summarize desde Plugins > Añadir nuevo, busca su nombre, instálalo y actívalo. Si ya lo usabas para los botones de compartir, te basta con actualizarlo a la versión 2.0.0 o superior.

Vete a Ajustes > AI Share & Summarize > Ajustes y haz clic en la sección Resumen con IA. Si tienes WordPress 7.0 o superior con un conector configurado verás un aviso en verde que confirma que el cliente de IA está disponible. Si no aparece, no pasa nada, o lo conectas y activas un proveedor IA, o podrás. usar eel sistema por extracción mediante PHP, sin nada que configurar.

Marca la casilla Generar y mostrar resúmenes con IA para activar la funcionalidad. A partir de ese momento, cada vez que publiques o actualices una entrada se genera el resumen automáticamente en segundo plano, sin que el editor se quede esperando a la IA, y los usuarios podrán ver el resumen en tu web.

Configurar cómo y dónde aparece el resumen

Justo debajo tienes el resto de ajustes para dejarlo a tu gusto:

• Resúmenes por tipo de contenido: Eliges en qué tipos se generan, entradas, páginas o cualquiera que tengas registrado. Es independiente de dónde muestras los botones de compartir, así que puedes tener resumen en sitios donde no haya botones y al revés.
• Posición del resumen: Decides dónde sale, justo antes de los botones de compartir, justo después, antes del contenido, o que no se muestre pero se genere igual, opción útil si solo lo quieres para el shortcode o para las IAs.
• Plegado por defecto: Si lo dejas marcado, el resumen aparece plegado y el visitante lo despliega cuando quiere. Si lo desmarcas, sale abierto nada más cargar la página.
• Contador de frases del resumen: De una a cinco frases. Este número se le pasa a la IA como parte de la instrucción, y el sistema por extracción lo usa como tope máximo. Por defecto son tres, que es un buen punto de partida.

Resúmenes automáticos con IA

Si quieres el mejor resultado posible lo ideal con diferencia es el resumen redactado con IA. El paso clave está fuera del plugin, en la pantalla de conectores que trae WordPress a partir de la versión 7.0. Entra en Ajustes > Conectores, elige tu proveedor, mete la clave de API de tu cuenta y guarda. Con eso hecho, el plugin detecta la conexión y empieza a usarla para los resúmenes.

La ventaja es que la clave la pones una vez en el núcleo de WordPress y vale para todos los plugins compatibles, no tienes que ir dándola plugin por plugin. Si quieres entender bien cómo funcionan los conectores y la nueva capa de IA de WordPress 7.0 te lo conté en este artículo.

Nota: Si la generación falla, por ejemplo porque la clave está mal o el proveedor se ha quedado sin saldo, el plugin guarda el último error y te lo enseña en su propia página de ajustes, así que no necesitas activar el modo de depuración para enterarte de qué ha pasado.

Resúmenes automáticos sin IA

Si no tienes WordPress 7.0 o superior, o no quieres pagar por una API, deja marcada la casilla Usar el alternativo por extracción. Con eso el plugin genera el resumen analizando tu propio texto, se queda con las frases que mejor lo representan y descarta las que se repiten.

No esperes la misma calidad que con la IA, porque aquí no hay redacción, son frases tuyas recortadas y unidas lo mejor posible mediante unos algoritmos predefinidos, y luego usa PHP para generar el texto.

Para muchos artículos cumple de sobra, sobre todo si escribes con frases claras y bien rematadas, porque entonces las que elige el sistema ya tienen sentido por sí solas. Si tus párrafos son muy enrevesados el resultado se resiente, puede quedar raro a veces.

¿Añadimos resúmenes a las entradas antiguas?

La generación automática salta al publicar o actualizar, así que tus entradas anteriores a la instalación del plugin se quedan sin resumen hasta que las vuelvas a guardar.

Para no reeditar cientos de entradas, y para no generar automáticamente cientos o miles de publicaciones, con el consiguiente y enorme gasto en IA, el plugin puede mostrar a los visitantes un botón de Generar resumen con IA en las que todavía no lo tienen. El primer visitante que lo pulse genera el resumen y queda guardado para los siguientes.

Aquí hay una decisión que conviene que tomes con la calculadora delante. El ajuste de La parte pública solo usa el generado por extracción hace que ese botón use únicamente el resumen por extracción, que no cuesta nada.

Si desactivas este ajuste, cada clic de un visitante puede lanzar una llamada de pago a tu proveedor de IA, así que piénsatelo bien si tienes mucho tráfico y/o contenidos previos. Eso sí, al menos el botón solo admite una generación por IP y minuto, para que nadie se dedique a aporrearlo y te arruine a base de clics.

Esto es más que relevante, porque los conectores de IA de WordPress es que no traen un tope de gasto propio, ni siquiera visualización, y ya ha habido avisos en la comunidad de que varios plugins que comparten una misma clave pueden disparar la factura en cuestión de minutos. Dejando el botón en solo extracción te curas en salud.

Oye, y sino prueba, desactiva esa casilla (por defecto viene activa para que no te arruines sin saberlo), vigila el gasto de tokens, y si lo consideras razonable pues nada, lo dejas.

Cómo editar o rehacer un resumen a mano

El resumen automático está bien para salir del paso, pero los artículos más importantes agradecerán un repaso. Tienes dos formas según el editor que uses.

Si utilizas el editor de bloques, en la barra lateral aparece un panel del plugin donde ves el resumen actual, lo puedes editar a mano y lanzar una regeneración al momento. Ojo con un detalle, en cuanto editas un resumen a mano queda bloqueado, es decir, ya no se regenera solo cuando actualices la entrada, para que no te machaque tus cambios.

Si usas el editor clásico, tienes una caja meta que hace lo mismo, ves el resumen, lo editas y puedes forzar que se rehaga en el próximo guardado. Si la generación con IA da algún error, ahí mismo te sale un aviso explicando qué ha fallado.

El ajuste de SEO para no competir contigo mismo

Esto requiere un momento de atención, porque hay algún plugin por ahí que lo hace fatal.

Cuando pones un resumen de tu artículo en la propia página, corres el riesgo de que Google lo coja como fragmento destacado y acabe enseñando tu resumen en los resultados en lugar de tu artículo. O sea, que tu propio resumen te robaría el sitio en las búsquedas.

Para evitarlo, el plugin (AI Share & Summarize, que este sí lo hace bien) marca el bloque del resumen con el atributo data-nosnippet, que le dice a Google que no use ese trozo como fragmento en los resultados. De paso le añade microdatos de Schema.org (CreativeWork y abstract) para que buscadores e IAs entiendan que eso es un resumen derivado de tu contenido, no el contenido en sí.

Es un detalle pequeño, pero te ahorra un problema de canibalización que puede hacer polvo tu estrategia de posicionamiento de contenidos si te descuidas y usas cualquier otra cosa.

Insertar el resumen donde quieras con un shortcode

Si no quieres que el resumen salga de forma automática y prefieres colocar el resumen tú a mano en un lugar concreto, tienes un shortcode:

[ayudawp_aiss_summary]

Lo pegas donde quieras dentro de una entrada y ahí aparece su resumen. Y si necesitas mostrar el resumen de otra entrada distinta, le pasas su identificador:

[ayudawp_aiss_summary post_id="123"]

Y de paso, controla qué hacen las IAs con tu contenido

Los resúmenes son una pata de un asunto más grande, el de controlar qué hacen las IAs con lo que publicas. La otra pata es saber qué rastreadores entran en tu web y qué se llevan, y para eso tengo otro plugin gratuito, VigIA, que registra el paso de GPTBot, ClaudeBot, PerplexityBot y compañía.

Si tienes los dos activos, AI Share & Summarize cruza sus datos de clics con las visitas de esos rastreadores que detecta VigIA, así ves de un vistazo si el interés de las IAs por un artículo va en paralelo con lo que hace tu audiencia.

Una última cosa, si has llegado hasta aquí abajo, este artículo no te hacía falta resumido, pero fíjate que ahí abajo tiene su propio resumen, generado con el mismo plugin del que te he hablado.

Despliégalo y mira cómo queda en una entrada de verdad, y si te ha quedado cualquier duda, déjamela en los comentarios y la vemos.

La idea es sencilla, el lector marca las webs en las que confía y a partir de ahí las ve más a menudo cuando busca.

La novedad es que ya no afecta solo al carrusel de noticias, sino también a lo que la gente ve cuando le pregunta a la IA de Google.

Vamos a ver qué son, si tu web puede salir en las fuentes preferidas de Google (te enseño la mía, que sale) y cómo conseguir que tus lectores te elijan como fuente preferida.

Y te aviso de algo desde el principio para que no pierdas el tiempo, no hay nada que instalar ni configurar en WordPress, esto depende de los ajustes de Google de cada usuario, para bien y para … no tan bien. Pero no anticipemos, te cuento…

Qué son las fuentes preferidas de Google

Cuando buscas algo de actualidad, a veces, aparece el bloque con las noticias destacadas.

Pues bien, al lado de ese bloque hay un icono con forma de estrella, si lo pulsas, puedes buscar y marcar las webs que quieres ver más, y al recargar los resultados esas webs salen con más frecuencia cuando publican algo nuevo sobre lo que buscas.

No desaparece el resto, los demás sitios siguen apareciendo, así que no te encierras en ninguna burbuja, es una personalización de fuentes de información de las que te fías.

Puedes marcar tantas fuentes como quieras y cambiarlas cuando te apetezca. Si prefieres gestionarlas todas de golpe sin esperar a encontrarte el icono, tienes la herramienta en google.com/preferences/source.

Si es algo que ya existía ¿por qué ese interés renovado?

Hasta hace nada las fuentes preferidas existían solo en los resultados normales, pero desde mayo del 26 también aparecen en las vistas creadas con IA y en el modo IA, con una insignia de «Preferido» que destaca tus webs marcadas dentro de la respuesta.

Aquí está el matiz que igual deberías tener en cuenta, y es que hoy esa insignia solo sale cuando tu web ya aparece por sí misma en la respuesta de la IA.

No te hace aparecer más, pero Google ya ha dicho que está trabajando en usar las fuentes preferidas como señal de posicionamiento en sus funciones de IA, para que lo que el usuario marca salga más a menudo, pero eso todavía no está activo.

Dicho de otra forma, hoy es un distintivo pero mañana podría ser un empujón de tráfico, a pesar de las respuestas creadas con IA.

Eso sí, también ten en cuenta que si montas tu estrategia de tráfico dando por hecho lo segundo te puedes a llevar un chasco.

En el mismo anuncio Google metió algunas cosas más que pueden ser interesantes. Por un lado está un carrusel que resalta fuentes para preguntas sobre temas en desarrollo, y también ha anunciado una insignia para señalar las fuentes más citadas, lo que en inglés han llamado «Highly Cited».

Para que te hagas una idea del tamaño del asunto, la gente ya ha seleccionado más de 345.000 fuentes distintas.

Por qué te interesa aunque no tengas un medio de noticias

Si buscas guías sobre esto por ahí, la mayoría en ingles, verás que todas lo plantean como cosa de periódicos y portales de noticias, y te empujan a meter el schema NewsArticle y a optimizar para las noticias destacadas.

Pero ahí hay un malentendido que podemos aprovechar en nuestro beneficio. Sin ir más lejos, este blog, Ayuda WordPress (ayudwp.com), no es un medio de noticias, no usa NewsArticle, y aun así aparece en la herramienta de fuentes.

Cualquier blog temático que publique con constancia también entra en las posibilidades de ser fuente preferida de noticias. Lo que cambia es de dónde te llega el beneficio.

Para un blog de tutoriales como este salir en las noticias destacadas es raro, porque ese bloque va de noticias calientes, de tendencias, y por mucho que nos guste, nuestros nichos tienen su público, pero de ahí a ser noticias relevantes o que abran portadas como que no.

El retorno realista está más en Google Discover y en las vistas creadas con IA, que es justo donde tus lectores fieles se encontrarán de manera habitual con tu contenido.

Eso sí, sé realista con lo que da de sí, esto no es un grifo de tráfico, solo te ayuda con quien ya te ha marcado como fuente preferida y cuando tienes algo reciente y relevante para esa búsqueda.

El único dato que ha soltado Google es para cogerlo con pinzas, pues dicen que la gente hace clic el doble de veces en una web después de marcarla como fuente preferida, pero lo dijeron sin explicar cómo lo miden, así que tómalo como una señal de que la cosa funciona, no como una promesa de duplicar visitas.

¿Comprobamos si tu web puede ser fuente preferida?

Antes de prometerle nada a nadie mira si tu web aparece. Con tu sesión de Google iniciada, entra en esta dirección cambiando el dominio por el tuyo: https://google.com/preferences/source?q=tudominio.com

Si tu web sale en la lista, ya puedes pedir que te marquen. En mi caso aparece sin problema:

Dos cosas que conviene saber:

1. Solo valen los dominios y subdominios, no las subcarpetas, así que tudominio.com o blog.tudominio.com sirven, pero tudominio.com/blog no.
2. Las webs que no se actualizan con regularidad pueden no estar disponibles, o sea que publicar a menudo no es opcional para esto.

¿Y cómo consigo que me añadan como fuente preferida?

Aquí está el cambio de mentalidad que tienes que hacer. Con el SEO de toda la vida intentas gustarle al algoritmo, pero esto va de gustarle a las personas hasta el punto de que te añadan manualmente.

No hay nada técnico que puedas tocar en WordPress para forzarlo, solo te queda pedírselo a tu audiencia y, sobre todo, merecértelo. Esto es lo más importante, porque es más cómodo enseñarte a poner un botón que a ganarte la confianza de tu gente.

Lo divido en tres frentes, de menos a más importante, el enlace y el botón, dónde los colocas y, lo que sirve de algo de verdad, la estrategia de contenidos.

El enlace directo y el botón, lo básico que ofrece Google

Lo primero que ofrece Google en la página de información sobre esto de las fuentes preferidas es un enlace directo que lleva al lector a la herramienta de añadir como fuente de preferencia, lo que hemos visto antes, con este formato cambiando mi dominio por el tuyo:

https://google.com/preferences/source?q=ayudawp.com

El lector solo tiene que pulsar y marcar la casilla que aparece junto a tu nombre. Es lo más cómodo que le puedes dar y funciona en cualquier sitio donde pongas un enlace.

Otro recurso que ofrece es una especie de botón oficial que Google te deja descargar en un ZIP desde su centro de ayuda para editores, o pillarlos de aquí, son los mismos:

Lo que pasa es que son botones muy básicos, por eso muchos medios, en vez de usar el botón tal cual, lo recrean con su propio diseño y lo enlazan al enlace directo de antes.

Mi consejo, y esto ya es criterio mío de andar por casa, no algo que diga Google, es que para tus lectores un botón propio, con tu mensaje personalizado convierte mejor que uno genérico aunque te cueste cinco minutos más prepararlo.

Dónde colocar la llamada a la acción

El botón o el enlace por sí solos no hacen magia si los entierras en una esquina. Estas son las ubicaciones que más sentido tienen, y el porqué de cada una.

• La caja de autor al final de cada artículo, junto a tus iconos sociales. Es el sitio natural, el lector acaba de leerte y es cuando más predispuesto está a seguirte.
• El final del propio contenido, después de la última idea útil. Si le ha gustado lo que ha leído, ahí lo tienes receptivo.
• La barra lateral o el pie de la web, para que esté siempre a mano sin depender de un artículo concreto.
• La newsletter, que es donde tienes a la gente que ya te ha dado su confianza. Esos son justo los que más fácil te van a marcar.

La estrategia de contenidos para ser fuente preferida

Muchos medios han publicado un artículo entero dedicado a pedirle a sus lectores que los añadan como fuente preferida, con su paso a paso y su enlace directo. No es una rareza, es ya una táctica habitual, y la puedes copiar adaptándola a tu estilo.

La idea es escribir un artículo breve explicando qué son las fuentes preferidas, por qué le viene bien al lector añadirte (que no se entere de que el favor te lo hace a ti, sino de lo que gana él, no perderse tus publicaciones) y cómo hacerlo en dos pasos con tu enlace. Lo dejas fijado o lo enlazas desde la newsletter y desde tus redes. Sí, algo parecido a esto mismo, pero menos útil, muucho menos.

Eso sí, hazlo con cabeza, que aquí es fácil pasarse de frenada. Te propongo un par de criterios que te ahorran quedar como un plasta:

• Pídelo de vez en cuando, no en cada artículo ni cada semana. Si machacas con ello, cansas y consigues el efecto contrario.
• Aprovecha el momento, que ahora mismo la funcionalidad es novedad y eso te da una excusa natural para contarlo sin que parezca que mendigas.
• Céntralo en lo que gana el lector, no en lo que ganas tú. «Así no te pierdes nada de lo que publico» funciona mejor que «Ayúdame a crecer».
• Ponle un par de capturas del proceso para que no tenga ni que pensar. Cuanto más fácil se lo pongas, más gente lo hará.

Con todo la parte más incómoda de toda esta estrategia es la que ninguno queremos oír, y es que ningún botón ni ningún artículo de «añádeme» va a salvarte si tu contenido no merece que te añadan.

La funcionalidad de fuentes preferidas premia a quien publica con constancia y aporta algo, y de hecho el propio Google avisa de que las fuentes que no se actualizan con regularidad pueden ni siquiera aparecer en la herramienta.

La mejor estrategia para que te marquen como fuente preferida es la misma de siempre, publicar bien y a menudo. El botón es una posible ayuda, no es el truco secreto para ganar tráfico desde búsquedas y respuestas creadas con IA.

Qué puedes medir y qué no

Otra alegría para el cuerpo. No hay panel ni informe de fuentes preferidas, Google no nos da ningún dato de cuánta gente ha marcado nuestra web como preferida ni de cuánto nos aporta.

Lo más que puedes hacer es aproximarte mirando en Search Console cómo evolucionan Discover y las noticias destacadas, preguntar a tu audiencia cómo te ha encontrado y, si pones el enlace o el botón, medir cuántos clics se lleva. De momento es lo que hay, o sea nada.

Pues ya estaría ¿no?

Si te ha parecido útil esta cosa que te he contado, ya sabes lo que toca, marcar este maravilloso blog como fuente preferida en Google desde este enlace y así me leerás más (sí, es posible leerme más) cuando busques cosas interesantes, únicas, tope relevantes de WordPress.

Y si quieres seguir trabajando tu visibilidad de cara a las IAs échale un vistazo a cómo posicionar en las AI Overviews de Google y a cómo saber si las IAs te recomiendan. También te pueden ayudar mis plugins (graaatis) de compartir y resumir en IAs o de optimizar y analizar la visibilidad en IAs.