Te lo resumo todo aquí, por si no pudiste verlo en directo o prefieres leerlo con un café.

Crónicas WordPress: WordPress 7.1.1, el lío de Rank Math y Google pisando el acelerador hacia el abismo

Seguridad: WordPress 7.1.1 y una semana de agujeros gordos

WordPress 7.1.1 salió el 17 de septiembre y es, sobre todo, una versión de seguridad. Corrige 11 vulnerabilidades, además de 17 fallos en el núcleo y casi 20 en Gutenberg, entre ellos un XSS almacenado bastante serio. Si todavía no has actualizado, ya estás tardando.

Me hizo gracia que Anthropic, la empresa de Claude, aparezca acreditada en dos de esas 11 vulnerabilidades. Ya empieza a ser lo normal, y hasta en GitHub queda reflejado cuando ha participado una IA en encontrar o arreglar algo.

En esta versión entra también un arreglo que reporté yo. El mapa del sitio nativo de WordPress devolvía un error 404 en las webs que no tienen entradas (solo páginas, productos y esas cosas, sin blog), cuando debería devolver un 200. Lo avisé, lo arreglaron y ha colado en la 7.1.1. Yo creo que merecía una versión grande, pero oye, entró.

Lo más gordo de la actualización es el cierre de Click to Shell, una cadena de ejecución remota de código. Parece un titular exagerado de web de seguridad, pero aquí es literal, porque con un solo clic en un enlace que parecía inofensivo te podían comprometer la web entera, sin necesidad de tener cuenta de usuario.

Y luego está lo de Rank Math, el plugin de SEO con más de 4 millones de instalaciones. Generaba automáticamente una contraseña de aplicación que les daba acceso al administrador de tu web, sin preguntarte, la enviaba a los servidores de la empresa (la misma que está detrás de WP Rocket) y no había forma de desactivarlo ni desde el propio plugin. Se denunció y lo han retirado.

Matt Mullenweg se ha cabreado, y esta vez con razón, así que ha pedido auditorías de seguridad obligatorias para cualquier plugin que pida acceso de administrador. Ya se está viendo cómo implementarlo. Quien dio la voz de alarma en agosto fue el desarrollador de The SEO Framework, que es competencia directa y lo que tú quieras, pero tiene razón y hay que dársela.

Mi opinión, aunque a nadie le importe. No puede ser que estemos hablando de un agujero que con un clic te compromete la web y que encima un plugin de SEO te abra la puerta de atrás por su cuenta. Para mí Rank Math se ha terminado. Les tenía cierto criterio como plugin de SEO, pero esto no se lo perdono ni medio.

Hubo más sustos:

• The Events Calendar: el plugin de eventos más conocido, con unas 600.000 instalaciones, tenía tres vulnerabilidades de nivel 9,8 (de lo más tocho que hay) por un vector muy poco corriente, los comentarios con bloques de Gutenberg mal saneados. El atacante podía restablecer la contraseña del administrador y quedarse con tu web. Si tienes una versión anterior a la 6.17.4.1, actualiza ya.
• WooCommerce Wholesale Lead Capture: un plugin para mayoristas con unas 6.000 instalaciones que, hasta la versión 2.0.3.1, permitía subir archivos sin validar mediante AJAX y sin identificarse. Son pocas instalaciones, pero ya se han detectado muchos intentos de explotarlo, y eso sí es grave.

Cerré la sección con una noticia mía, el lanzamiento de Vigilante 3.0. La novedad gorda es que el plugin se autoprotege, porque ¿qué hay peor que te ataquen con un plugin cualquiera? Pues que te ataquen a través del propio plugin de seguridad, que se supone que está para evitarlo. Como el miércoles dediqué el directo entero a esto, te lo cuento más abajo.

Comunidad: GatherPress sustituye a Meetup, formación para periodistas y un mercado de negocios WordPress

GatherPress nació en 2018, en un viaje de vuelta de una WordCamp de esos de un montón de horas, cuando alguien se preguntó por qué WordPress dependía de un servicio comercial como Meetup.com. Se subió como plugin al directorio oficial, se ha ido probando con grupos de varios países y este verano la Fundación WordPress lo ha anunciado como sustituto oficial de Meetup. Ya está en fase de pruebas en events.wordpress.org, y la fundación se ahorrará unos 200.000 dólares al año, que se dice pronto. La idea me parece cojonuda, lo que no me lo parece tanto es lo que se ha tardado en hacerle caso.

El Colegio Profesional de Periodistas de Andalucía ha lanzado más de 100 horas de formación para sus colegiados, y he tenido el gusto de que me incluyan. Me toca impartir el bloque de inteligencia artificial para WordPress, porque WordPress sigue siendo imprescindible, pero con IA se puede mejorar muchísimo. Si eres periodista y estás colegiado en Andalucía, apúntate, que creo que para vosotros es gratis.

También ha aparecido WP Acquire, un mercado para comprar y vender negocios basados en WordPress (plugins, temas, tiendas o webs). Publicar el anuncio cuesta 50 dólares, no cobran comisión y el vendedor se queda con el 100 % de la venta. Lo veo como un síntoma de madurez del sector, así que si te planteas vender algo, échale un ojo.

Desarrollo: lo que trae WordPress 7.2 y WooCommerce subiendo el listón de PHP

WordPress 7.2 está previsto para diciembre de 2026, así que será la última versión del año. En seguridad trae bastante:

• Una especie de modo sudo (para los que venís de Linux) que te pide volver a identificarte para las acciones sensibles.
• Una API de secretos, la Secrets API.
• Un refuerzo de las contraseñas de aplicación, que llevaban tiempo en barbecho (y a la vista de lo de Rank Math, falta hacía).

Además, el editor del sitio se podrá ampliar desde plugins con DataViews y DataForms, de lo que vamos a hablar mucho pronto. El bloque de tabla de contenidos pasa a estable, llega algún bloque nuevo que ya veremos en directo con calma y los Dashicons de toda la vida dejan paso a iconos SVG. No es para volverse loco, es una renovación, pero ya hay gente quejándose del icono nuevo, porque somos así de tocapelotas.

Y ojo, que nos despedimos de los temas «Twenty» después de 16 años. El nuevo tema por defecto se llamará Ipsum (como el Lorem Ipsum) y ya se puede descargar desde GitHub, que ahora todo va a GitHub (a mí no me gusta nada, pero a todo el mundo le encanta). Es minimalista, pensado para blogs, muy centrado en la accesibilidad y con varias tipografías y variaciones de estilo. Aparte saldrá otro tema, Metis, bastante más vistoso, que no vendrá integrado.

También se ha abierto la llamada a pruebas de DataForms para las pantallas de ajustes. Algo se va a notar a la vista, pero la mejora de verdad está en el rendimiento.

WooCommerce, por su parte, resucita Purple, su tema de bloques, en beta pública. Lo quitaron en julio de 2025 y ahora vuelve con muchas funciones que normalmente pedirían plugins, ya integradas en bloques. En WordPress.com ya es el tema por defecto, y no creo que tarde mucho en sustituir a Storefront como el tema que te sugiere WooCommerce al instalarlo.

La noticia de WooCommerce que más me preocupa es otra, porque va a subir el mínimo de PHP de la 7.4 a la 8.1, y poco después a la 8.3. Conozco montones de tiendas que siguen en PHP 7.4, no por WooCommerce ni por WordPress, sino por algún plugin concreto que casca en cuanto subes de versión. La 7.4 ya no tiene soporte ni actualizaciones de seguridad, así que o pones al día esos plugins o te quedas sin poder actualizar WooCommerce. Yo apuntaría como mínimo a la 8.2, y lo ideal sería la 8.3.

Y ya que hablamos de WooCommerce, me pidió mi amigo Jordan Suárez un tutorial sobre impuestos, que es de lo más cansino y raro que tiene WooCommerce, y resulta que no lo tenía. Pues ya la tienes, la guía para configurar los impuestos en WooCommerce. Son unos 30 minutos de lectura, así que no es para leerla de un tirón, es para guardarla y tirar de ella cuando te surja una duda. Gratis, como siempre, y sin publicidad que moleste.

IA: un curso gratis de Learn WordPress

Esta semana había muchas noticias de IA en WordPress, pero casi todo me pareció relleno, y si a mí me aburre, a ti ni te cuento. Me quedo con una. En Learn WordPress han publicado un curso gratuito de unas 9 horas sobre la IA integrada en WordPress desde la 7.0. Tiene cuatro módulos, casi todos sobre gestión de contenidos y la integración con Claude y ChatGPT. No es nada técnico, es online y lo haces cuando quieras, así que no tiene pega.

SEO: Google, sujétame el cubata

Google ha descubierto, llámame loco, que si sus vistas previas con IA siguen resumiendo el contenido sin mandar clics, se puede quedar sin contenido original. Porque las IA no crean contenido original, reciclan, hacen refritos y resúmenes de lo que ya existe. Así que ahora plantea pagar a los editores cuando su contenido alimenta esas respuestas, con un programa piloto que empezará, cómo no, en Estados Unidos. Donde más sentido tendría es entre los pequeños y medianos editores, los blogueros, que somos los que de verdad alimentamos todo esto. Que paguen por el trabajo bien hecho, no con subvenciones.

Luego vienen las alegrías de siempre:

• Fichas de empresa en las vistas previas con IA: los perfiles de Google Business empiezan a mostrarse ahí, con un «mostrar más» que abre una conversación con más datos del negocio. O sea, que nadie visita ya ni tu ficha ni Google Maps, todo se queda dentro del modo IA. Si con las preguntas relacionadas ya se cargaban el SEO normal, ahora le toca al SEO local.
• Anuncios camuflados en el modo IA: anuncios de texto metidos entre las respuestas con una etiqueta de patrocinado. Justo lo que necesitaba el buscador para que los usuarios terminen de perderle la confianza.
• Un botón de modo IA en la página de resultados: para empujarte a salir de la búsqueda clásica, que ya tienen asumido que es un desastre.

OpenAI también ha movido ficha con los agentes patrocinados de ChatGPT, conversaciones con un agente de la marca cuando ves un anuncio. Aquí voy a ser justo, porque sobre el papel van a estar bien separados de las respuestas normales y, si de verdad no mezclan lo patrocinado con lo neutral, me parece bastante más transparente que lo de Google. Hasta una buena idea, fíjate.

Llevo 25 años en esto y no me explico cómo Google se está cargando su propio producto. La IA no ha llegado a internet, se lo ha cargado, y Google le ha metido el turbo a la carrera hacia el abismo.

Europa y la EU Kids Act

Para rematar, la Unión Europea está preparando la EU Kids Act, que prohibiría las redes sociales (Instagram, TikTok, YouTube) a menores de 13 años, permitiría el acceso entre los 13 y los 15 solo con supervisión de los padres, funciones limitadas y control horario, y vetaría hasta el scroll infinito.

Ya sé que mucha gente lo ve bien, porque hay que proteger a los niños y las plataformas abusan, y en eso no les falta razón. Pero esta es una opinión de las intensas, así que te la cuento tal cual. Las instituciones están para servirnos, no para sustituirnos. Si aceptamos que decidan a partir de qué edad y cómo usan nuestros hijos las redes, les estamos dejando hacer nuestro papel de padres, primero en esto y luego en lo que les dé la gana. Lo que hay que hacer es formar a los padres para que sean conscientes y responsables de cómo usan sus hijos las redes y la IA.

En el chat, Mel Gómez apuntó algo con lo que estoy muy de acuerdo, que al final la gente dejará de fiarse de la IA y pedirá referencias. Creo que volveremos a lo único que da confianza de verdad, saber quién ha escrito qué. Yo me hago responsable de lo que digo, aun a riesgo de equivocarme, y si mañana tengo que rectificar, rectifico. Por eso se está volviendo tanto a los foros y a las comunidades de nicho, y no me extrañaría que volviéramos a los blogs enlazándose entre ellos, como con aquellos blogrings de antes.

Ver el directo completo de Crónicas WordPress en YouTube

Doctor WordPress: cómo funciona la autoprotección de Vigilante 3.0

Me habíais preguntado bastante por la autoprotección de Vigilante 3.0, así que le dediqué el directo entero. La idea llevaba meses rondándome la cabeza, porque si no te puedes fiar de tu plugin de seguridad, no te puedes fiar de nada de lo que te diga. Un plugin de seguridad te protege de otros plugins y de inyecciones, pero ¿quién lo protege a él?

La cerradura, la caja fuerte y la fábrica

Piensa en tu web como en tu casa. Un ladrón listo no revienta la puerta, que hace mucho ruido. Lo que hace es cambiarte el bombín por uno que abre con tu llave y también con la suya, como hacen con los cajeros y las tarjetas. Tú sigues entrando como siempre, no notas nada, y él entra cuando quiere. Eso es lo que tiene que detectar la autoprotección, que alguien ha tocado tu cerradura.

Para eso Vigilante se comprueba contra tres referencias:

• El manifiesto: un archivo que va con el plugin y que es distinto en cada instalación. Sería la ficha grabada en el propio bombín.
• La huella en la base de datos: la tarjeta que te dio el cerrajero y que guardas en la caja fuerte. Para falsificarla no basta con entrar en casa, también hay que abrir la caja fuerte. Y cada vez que el cerrajero (el actualizador de WordPress) te cambia el bombín, te da una tarjeta nueva.
• Las sumas de verificación de WordPress.org: el registro del fabricante, que está en la fábrica y no en tu casa, así que aunque te hayan reventado la caja fuerte, eso no lo pueden tocar. Eso sí, cuando sale una versión nueva, WordPress.org tarda unas horas en actualizar ese registro.

Para engañar al plugin harían falta las tres llaves, y la tercera ni siquiera está en tu casa. En el escritorio de Vigilante lo ves como «Autoprotección de Vigilante», con el número de archivos verificados y «3 de 3 referencias» si todo está bien.

Los casos que te puedes encontrar

En el directo fui forzando cada situación con un mu-plugin de pruebas en mi instalación local (la que rompo casi a diario). Te resumo qué verías y qué hacer en cada caso:

• Todo correcto: tres de tres referencias, en verde, y a otra cosa.
• Verificado, pero sin sumas de WordPress.org: pasa justo después de una actualización, mientras el registro del fabricante se pone al día. Lo da por bueno y te lo explica en la comprobación de seguridad.
• Dos de tres referencias: el indicador pasa a gris. No es grave, pero te avisa.
• Una hoja de estilos, un script o una imagen modificados: aparece un aviso, porque ya no es solo una referencia, hay un archivo tocado. Muchas veces es cosa de un plugin de caché u optimización que minifica los archivos, así que excluye la carpeta de Vigilante. Si no usas ninguno, pulsa «Reparar Vigilante», que descarga una copia limpia desde WordPress.org y sustituye los archivos en un clic.
• Versión cambiada sin confirmar: el manifiesto no coincide, por ejemplo porque has actualizado a mano por FTP sin pasar por el actualizador. Si has sido tú, lo aceptas, y si no, reparas.
• Versión anterior instalada: alguien ha sustituido Vigilante por una versión más antigua, que puede tener vulnerabilidades ya corregidas. Si no has sido tú, reparar.
• Archivo de código modificado: aquí ya estamos en la zona crítica. El aviso sale en rojo en todas las pantallas importantes del administrador (menos en el editor), no se puede cerrar y la puntuación de seguridad deja de ser fiable. En el ejemplo te decía qué archivos habían tocado, el del cortafuegos y el del acceso, así que ya no te puedes fiar ni de uno ni de otro. Reparar, inmediatamente.
• Archivo inyectado: alguien ha metido un archivo nuevo en la carpeta del plugin. En la prueba se llamaba «puerta-trasera.php», pero ningún atacante lo va a llamar así, le pondrá un nombre que parezca legítimo para que no lo borres. Pide a tu hosting que mire cuándo llegó ese archivo, repara y vuelve a analizar. Y revisa la auditoría de seguridad, que es donde queda todo registrado.
• Manifiesto sustituido, borrado o dañado: han manipulado una de las llaves. Quedan las otras dos referencias, pero lo rápido es reparar desde WordPress.org, que siempre va a estar mucho mejor protegido que tu web (y que la mía).
• Tareas programadas eliminadas: este es de los más retorcidos. Vigilante hace sus comprobaciones con el cron de WordPress (la tarea de mantenimiento diario), y si alguien se las carga, el plugin sigue ahí pero no hace nada, sin análisis ni alertas. Revisa con WP Crontrol que estén las tareas que empiezan por «vigilante_» y, si faltan, haz un análisis de seguridad completo.
• Autoprotección desactivada por código: es el último aviso que vas a recibir, porque a partir de ahí nada comprueba nada. Por lo menos te dice qué archivo lo ha desactivado, como una especie de memoria de quién te mató. Si no has sido tú, trátalo como una intrusión, borra o desactiva ese archivo (renombrarlo a .off, por ejemplo) y vuelve a comprobar.
• Todavía sin comprobar: lo normal justo después de instalar, o tras una instalación por FTP. Lanza un análisis desde la pestaña de integridad de archivos y listo.

Plugins hechos con IA: el problema son las instrucciones que no das

Iván San José comentó en el chat que está creando plugins para uso propio con agentes de IA y que no hay límites. Sí que los hay, y el límite eres tú, porque luego hay que mantenerlos, actualizarlos y someterlos a revisiones que, si las haces tú solo, nunca van a ser suficientes.

Lo veo a diario con los clientes de mi servicio de mantenimiento. He pasado de que me pidan código a que me lo pasen, plugins hechos por alguien de marketing con ChatGPT o Claude que no sabe programar y lo da por bueno. Ninguno pasa mis comprobaciones de seguridad y de estándares de código. Y yo, que tengo mis skills bien afinadas y hago pruebas en instalaciones de test, también cometo errores.

Hace nada me pasaron un plugin que ya había pasado por mis skills de seguridad y aun así duplicaba pedidos en producción, porque nadie había cerrado un bucle. La IA sabe mucho de código, pero también hace cosas que no le has pedido. Si le dices que se asegure al 100 % de que un email llega, igual te lo manda por SMTP, por PHP mail y por un tercer sistema. El problema de los plugins hechos con IA no suelen ser las instrucciones que le das, sino las que no le das. Para jugar o para algo interno, adelante, pero si va a una web abierta al público, que lo revise alguien más y usa modelos buenos, de pago.

Nada es invulnerable

¿Significa todo esto que Vigilante es invulnerable? Ni de coña. La seguridad al 100 % no existe, y quien te diga lo contrario te está mintiendo. Vigilante, igual que otros dos plugins míos, ha tenido vulnerabilidades, unas las encontré yo y otras los usuarios. Las arreglo esa misma tarde y lo cuento, pero pasan.

La mayoría de los hackeos no vienen de fallos desconocidos, sino de vulnerabilidades conocidas que alguien no ha parcheado. Hay muchísimos escáneres, cada vez más con IA, tirando de bases de datos de vulnerabilidades y buscando webs con la versión afectada de un plugin. Hasta un reloj parado acierta dos veces al día. Lo bueno del código abierto es que todo es transparente y las vulnerabilidades se conocen cuando ya están corregidas. El problema es cuando se publica el parche y tú no actualizas, porque el atacante sí se ha enterado.

Así que lo de siempre, que es lo que más se nos olvida. Ten todo actualizado, y si puedes, Vigilante instalado, al día, con la autoprotección activa y la configuración de seguridad al máximo.

Ver el directo completo de Doctor WordPress en YouTube

Nos vemos en el próximo directo

Y hasta aquí la semana. Ya lo sabes, los lunes toca Crónicas WordPress y los miércoles, Doctor WordPress, a las 19:30 (hora peninsular) en el canal de Ayuda WordPress. Por cierto, admito invitados, así que si tienes algo interesante que contar, dímelo. Y si tienes cualquier duda de lo que he contado, o me quieres corregir en algo, te leo ahí abajo en los comentarios.

Además, que esto es una deuda pendiente, pues esta respuesta la tenía pendiente desde hace tres años. En octubre de 2022, Javi dejó este comentario en la guía de Redirection, y se quedó sin contestar:

«Quiero redireccionar muchas urls antiguas a un código 410 pero me gustaría evitar sobrecargar el htaccess […] Con la opción de Importar/Exportar permite hacer redirecciones 301, pero no he sido capaz de importar en csv urls que quiero que sea 410. ¿Tienes alguna idea o sugerencia para evitar hacerlo por htaccess?»

Javi, aquí tienes la respuesta completa, y es por qué el 410 no se importa igual que el 301, cuándo te toca usarlo en vez de una redirección, y qué hacer con el resto de casos de borrado, quizás por eso incluso lo añadí a un plugin … pero no adelantemos acontecimientos.

¡Empezamos!

El borrado de contenidos tiene tres destinos posibles, no solo uno

Cuando mandas una entrada a la papelera en WordPress, la URL que deja atrás tiene tres caminos posibles:

• 301, movido permanentemente: hay un contenido real al que mandar el tráfico.
• 410, contenido eliminado: no hay ni va a haber sustituto, y quieres que los buscadores lo sepan cuanto antes.
• 404, no encontrado: la URL deja de existir sin nada detrás.

Elegir mal no es un matiz técnico menor, tiene consecuencias reales en cómo trata Google tu web,  porque un 301 mal puesto puede acabar sin pasar ningún valor, un 410 que en realidad era un cambio de URL manda a la basura enlaces y tráfico que sí querías conservar, y un 404 no deja de ser una especie de error que muestras en tu web. ¿Seguimos?

Cuándo toca una redirección 301

El 301 tiene sentido cuando existe un destino que responde a la misma intención de búsqueda que tenía la URL borrada, con lo que fusionas dos entradas parecidas en una sola, publicas una versión actualizada que sustituye la publicación vieja, o resuelves una canibalización de contenido uniendo dos piezas en una.

La condición no negociable es que el destino tiene que ser relevante de verdad, no un cajón de sastre. Redirigir en bloque decenas o cientos de URLs borradas a la portada de tu web, la salida fácil de bastantes plugins por defecto, la mayoría a la portada de la web.

Es justo el patrón que Google ha señalado repetidamente como soft 404. El motor de búsqueda detecta que el destino no tiene relación real con lo que se buscaba, deja de tratar esa redirección como un «movido permanentemente» de verdad y no pasa ninguna señal.

Esto lo hace, por ejemplo, Redirection por defecto, cuando envías algo a la papelera con la supervisión de URLs activada, creando automáticamente una redirección 301 a portada. Sirve para no dejar un 404 suelto de un día para otro, pero si vas a borrar contenido en cantidad conviene revisar esas redirecciones automáticas caso por caso, no dejarlas todas apuntando a portada ahí a lo loco.

Si lo que cambia es solo el slug o la estructura de permalinks, y no borras nada, ese caso ya lo tienes cubierto en este artículo donde explico el wp_old_slug_redirect nativo.

Cuándo toca un 410 (esto no lo esperabas, seguro)

El 410 le dice a Google algo distinto al 301, no que el contenido se ha movido, sino que ha desaparecido para siempre y no hay a dónde redirigir.

Esto es más útil de lo que imaginas, a mi pasó hace poco, cuando un cliente del servicio de recuperación de webs hackeadas llegó con decenas de entradas inyectadas con spam SEO en japonés, un patrón clásico de infección para colarse en resultados de búsqueda ajenos a la temática de la web, y por supuesto de paso cargarse el tráfico y reputación de la web en particular y de la marca en general.

No había ningún contenido legítimo al que redirigir esas URLs, así que la única opción con sentido era el 410, y funcionó a la perfección, en menos de una semana habían desaparecido del índice de Google.

Con un 301 ese plazo no hubiese sido ni de lejos tan corto, porque redirigir spam a un contenido que no tiene nada que ver no acelera nada, en el mejor de los casos, pues Google lo trata como el soft 404 del punto anterior.

La documentación oficial de Google dice que trata el 404 y el 410 de forma parecida con el tiempo, pero John Mueller ha repetido varias veces que en la práctica el 410 suele caer del índice unos días antes que el 404, y en un caso de limpieza de seguridad, esos días cuentan, y se nota mucho, sobre todo en lo rápido que funciona.

El 410, por supuesto, también sirve para otras situaciones aparte de la seguridad, como para productos descatalogados sin sustituto o campañas, ofertas ya cerradas de forma definitiva, desposicionar contenidos y muchas otras necesidades de contenido que sabes que no va a volver ni tiene sustituto natural.

¿Y si lo dejo como 404 sin más?

No todas las URLs merecen gestión, eso es cierto, más o menos. Si una entrada borrada no tiene tráfico orgánico ni enlaces entrantes de valor, revisa Search Console y tu herramienta de enlaces entrantes antes de decidir, forzar una redirección ahí es trabajo que no vuelve en forma de nada.

Un 404 limpio no penaliza tu web, es información correcta del tipo «esa URL ya no existe», otra cosa es la experiencia de cara al usuario que llega a ese punto muerto, y la imagen que puedas dar si no gestionas correctamente tu página de error 404.

Luego está el asunto de los avisos y errores de la Search Console, que te van a estar recordándote siempre que tienes ahí esas posible malas experiencias para los usuarios que lleguen a tu (desaparecido) contenido y vean ese mensaje de error.

Tú decides, pero si me pides mi (humilde pero casi siempre acertada) opinión, sería la peor opción salvo casos muy contados.

Qué herramienta usar en WordPress para cada caso

Como en todo, no hay un plugin perfecto para todo, o para todas las necesidades, tienes varias opciones, todas buenas, según tu caso e incluso gusto:

• Redirection sigue siendo la opción más completa si necesitas 301, 302, 307 o 308, con su asistente y su registro de errores 404. El límite es justo el que le tocó a Javi, que el importador CSV está pensado para redirecciones tipo 301, no para dar de alta un lote de 410 sin tocarlas una a una o editar el .htaccess a mano.
• Safe Redirect Manager sí prioriza los 410, junto al 403, pero su importación por CSV solo está disponible vía WP-CLI. Si no tienes acceso a la línea de comandos en tu hosting, no te sirve para acciones por lotes.
• Visibility, te permite resolver todas estas situaciones independientemente de tu servidor, sin tener que tocar .htaccess o similares. Genera redirecciones sugeridas cuando envías una entrada a la papelera o la borras, y puedes convertir cada una en 301 o 410 desde el propio escritorio de WordPress, con importación CSV desde Redirection y los demás plugins de SEO, para no perder lo que ya tuvieras si decides cambiarte.

Resumen para decidir rápido

• ¿Hay destino real y relevante?: 301.
• ¿No va a haber destino nunca, sea limpieza de contenido o de seguridad?: 410.
• ¿Sin tráfico ni enlaces que lo sostengan?: 404.

Si te queda alguna duda de un caso concreto, la sección de comentarios sigue abierta, y esta vez prometo no tardar tres años en contestar.

En una tienda online el cartelito tiene que ir a todo color, a la vista antes de comprar y también en el correo de confirmación del pedido, y si algún fabricante da gratis una garantía de durabilidad de más de dos años sobre todo el producto, ese producto lleva además la etiqueta GARAN.

Es otro requisito legal más, sí, pero de los sencillos, porque no cambia tus garantías, solo te obliga a contarlas con el mismo cartel que el resto de tiendas de Europa. Lo que es más peñazo es elegir cómo ponerlo en WooCommerce, porque en las últimas semanas han salido plugins como setas y he revisado a fondo el código de los principales, y ya te adelanto que ninguno lo hace todo bien.

Lo vemos enseguida, pero antes…

Qué es el aviso armonizado y qué es la etiqueta GARAN

El aviso armonizado es un cartel con el mismo diseño en toda la UE (solo cambia el idioma) que recuerda al consumidor sus derechos de garantía legal. Lo tienes que mostrar si vendes bienes, o sea, productos físicos, a consumidores. Si solo vendes a empresas, o lo tuyo son cursos, descargas o servicios, no te afecta.

Lo que dice no es nuevo para nadie que venda en España. El aviso recuerda que la garantía legal mínima en la UE es de dos años y que algunos países tienen plazos más largos, que en segunda mano puede ser menor pero nunca de menos de un año, qué puede pedir el consumidor (reparación, sustitución, rebaja o reembolso) y qué tiene que hacer si el producto le sale mal. Incluye además un código QR que abre la página de garantías de Your Europe en su idioma. Vamos, que no cambia tu garantía, cambia cómo la cuentas.

La etiqueta GARAN es otra cosa. Solo hace falta si el fabricante ofrece una garantía comercial de durabilidad gratuita, de más de dos años y que cubra el producto entero. Va producto a producto, con los años, la marca y el modelo, y la prepara el fabricante. Tú, como vendedor, solo tienes que mostrarla junto a ese producto.

Ojo, que hay garantías que se le parecen y no obligan a ponerla:

• Los tres años de garantía legal que tenemos en España, porque son la garantía legal y ya los cubre el aviso.
• Una garantía ampliada que ofrezcas tú como tienda, porque la GARAN solo va con las del fabricante.
• Las ampliaciones de garantía de pago.
• Las que solo cubren una pieza, como los típicos «10 años en el motor».

La excepción es que fabriques tú lo que vendes (los muebles de tu taller, por ejemplo), porque entonces el fabricante eres tú, y si das gratis más de dos años sobre todo el producto, la GARAN te toca a ti.

Si no vendes productos con ese tipo de garantía del fabricante, olvídate de la GARAN y céntrate en el aviso, que es lo que afecta a todo el mundo.

¿Es obligatorio en España si todavía no se ha transpuesto la directiva?

Aquí hay un matiz importante y es que la obligación sale de la Directiva (UE) 2024/825, que añadió un artículo 22 bis a la directiva de derechos de los consumidores, y el diseño exacto del aviso lo fija el Reglamento de Ejecución (UE) 2025/1960, que se aplica desde el 27 de septiembre sin necesidad de transponerlo.

Pero la obligación de mostrarlo está en la directiva, y las directivas hay que pasarlas a la ley de cada país. El plazo terminó el 27 de marzo de 2026, España no lo ha hecho y el 28 de mayo la Comisión Europea abrió procedimientos de infracción contra 20 Estados miembros por este motivo, España incluida. La ley que tiene que hacerlo, la de Consumo Sostenible, sigue en tramitación.

¿Significa eso que te lo puedes saltar? Pues yo no lo haría, porque las administraciones ya lo dan por obligatorio, y la Junta de Andalucía, sin ir más lejos, recordó el 21 de septiembre a los comercios físicos y online que desde el día 27 tienen que usarlo. Si vendes a países que sí han hecho los deberes, como Alemania, allí te aplica su ley, y además, ponerlo te lleva solo un rato.

Tampoco hace falta ponerse nervioso, eso también, pues mientras no se apruebe la ley española, cómo y cuánto se sancionaría esto en España está en el aire, y en Alemania, donde ya aprobaron su ley, de lo que se habla es de requerimientos entre competidores por competencia desleal.

Hazlo con calma y bien hecho, y si tienes dudas sobre tu caso concreto pregunta a tu asesoría, que yo de leyes sé lo justo para no meter la pata.

Y en España, ¿no eran tres años?

Sí, y lo siguen siendo. Desde 2022 el artículo 120.1 de la Ley General para la Defensa de los Consumidores y Usuarios fija tres años de responsabilidad del vendedor para los bienes nuevos, dos para los contenidos y servicios digitales y, en segunda mano, un plazo que se puede pactar más corto pero nunca por debajo de un año.

Además, durante los dos primeros años se presume que el defecto ya estaba ahí al entregar el producto (artículo 121). El aviso dice «garantía legal mínima de dos años» porque es el mínimo europeo, y aclara que algunos países tienen plazos más largos.

Lo que no puedes hacer es cambiar ese dos por un tres, porque el aviso no se puede editar en absoluto, pero lo que sí puedes hacer (y te lo recomiendo) es poner al lado, fuera del cartel, una nota del tipo «En España, la garantía legal de los bienes nuevos es de tres años desde la entrega» con un enlace a la parte de tus condiciones donde lo explicas.

Así que si lees por ahí que ahora la garantía es de dos años, no, en España sigue siendo de tres.

Qué te piden exactamente para una tienda online

La Comisión publicó en abril unas directrices prácticas con lo que hay que hacer y lo que no. Para el aviso en una web, lo básico es esto:

• Usa el archivo oficial, en color, sin recortarlo, sin cambiar colores ni tipografía y sin añadirle nada.
• Tiene que leerse bien a su tamaño normal («legible at default display size», dicen).
• Siempre tiene que haber un enlace que se pueda pulsar y que lleve al mismo sitio que el QR.
• Va «de forma destacada», como un recordatorio general en la web. Los ejemplos que ponen son una frase en la cabecera, en el catálogo o en la página de pago que abre el aviso al primer clic.
• También debe ir en el correo de confirmación del pedido.

«La GARAN» tiene que ir junto al producto en la ficha, justo antes de hacer el pedido y también en el correo de confirmación, y aquí sí se permite un formato reducido que se despliega al pulsarlo.

¿Vale un enlace que lo despliegue o tiene que verse entero?

Aquí hay debate. Las directrices de la Comisión ponen como ejemplo justo eso, una frase que abre el aviso con un clic. Pero el propio documento aclara que son opiniones preliminares de sus servicios y que solo el Tribunal de Justicia interpreta el derecho de la UE, y hay quien, como JTL, sostiene que el reglamento solo permite ese formato desplegable para la GARAN, no para el aviso.

Mi recomendación es sencilla. Si quieres ir sobre seguro, muéstralo entero y a la vista junto al botón de pedido. Si prefieres una página de pago más limpia, el desplegable es lo que la propia Comisión pone de ejemplo, y si dudas, que decida tu asesoría, porque el código que te dejo más abajo permite las dos cosas.

Dónde descargar los archivos oficiales (y cuál usar)

Todo está en la página de la Comisión, con el aviso en las 24 lenguas oficiales en PNG, JPG, PDF y SVG, y la plantilla de la GARAN. Para la web usa el PNG en color, que en español pesa 87 KB, frente a los 631 KB del SVG. El PDF (92 KB, con la versión en color y la de blanco y negro) es el que te conviene adjuntar al correo y el que puedes imprimir en A4 si también tienes tienda física.

Por cierto, el paquete de PNG no trae la versión en inglés, que solo está en SVG y PDF. Si la necesitas para la web, exporta a PNG la primera página del PDF oficial en inglés sin cambiar nada más.

Plugins disponibles – Qué hacen y qué no

Casi todos han salido entre mediados de agosto y septiembre y ninguno pasa de unas pocas decenas de instalaciones, salvo Germanized, que es un veterano del mercado alemán, y el mío, que ya existía para el desistimiento y añade el aviso desde la versión 2.3.0.

He revisado el código de cada uno en su versión de hoy, así que esto es lo que hacen, no lo que dice su ficha:

Cuando lo ves todo junto el panorama queda bastante claro, porque quitando EU Withdrawal and Legal Guarantee Compliance, ninguno pone el aviso junto al botón, lo manda en el correo y lo muestra en castellano en una web en catalán, euskera o gallego, todo a la vez.

Vamos a verlos un poco más en detalle de todos modos.

Arthur Smith’s EU Guarantee Notice and GARAN Label (el más sólido)

Arthur Smith’s EU Guarantee Notice and GARAN Label lleva los SVG oficiales idénticos byte a byte a los de la Comisión y mete la imagen del aviso dentro del propio correo, así que no depende de que el programa de correo cargue imágenes externas. Además valida con cuidado los datos de la GARAN y la dibuja con la tipografía oficial. En su código no he encontrado fallos de seguridad ni llamadas a servicios externos.

Lo que falla es la colocación y el idioma, en la página de pago pone el aviso arriba del todo, no junto al botón, y esa ubicación viene desactivada. En webs en catalán, euskera o gallego lo muestra en inglés, igual que el texto del desplegable si no lo cambias en los ajustes. Nada que no arregles en dos minutos con el complemento que te dejo más abajo.

market-it! EU Guarantee Notice for WooCommerce (el más directo)

market-it! hace poco, pero lo hace donde toca. Lleva el SVG oficial y pone el aviso justo encima del botón de pedido, tanto en el checkout clásico como en el de bloques. Es ligero y no se conecta con nada de fuera.

Eso sí, aunque anuncia las 24 lenguas solo trae cinco (alemán, español, francés, inglés y sueco), no incluye el aviso en el correo ni la GARAN y es nuevísimo, salió el 31 de agosto. Si tu web está en catalán, euskera o gallego, elige el español como idioma por defecto en sus ajustes, porque si no cae al inglés. Y para el correo puedes combinarlo con mi snippet, desactivando la parte del checkout.

EU Warranty Ready (bien en el checkout, mal en el correo)

EU Warranty Ready también usa los SVG oficiales y también coloca el aviso justo encima del botón en los dos checkouts, con un desplegable accesible bien resuelto.

El problema está en el correo. Mete el aviso como una imagen SVG alojada en tu web, y ni Gmail ni Outlook de escritorio muestran imágenes SVG en los correos, así que lo más probable es que tu cliente no vea nada. Además esa parte no se puede desactivar, el plugin carga su CSS y su JavaScript en todas las páginas de la web y en catalán, euskera o gallego muestra el aviso en inglés.

BuildsByLuke Product Guarantee Notice (la imagen más fiel, solo en la ficha)

BuildsByLuke trae una copia en PNG muy fiel del aviso y es el único que en webs en catalán, euskera o gallego muestra el aviso en castellano sin tocar nada. El código es limpio.

Pero la versión gratuita solo pone el aviso en la ficha de producto, porque el checkout, el correo y la GARAN son de pago. Trae además el SDK de Freemius, con su pantalla de alta al activarlo (te la puedes saltar), y sus imágenes tienen el fondo transparente, así que en un tema con fondo oscuro las zonas blancas del aviso se tiñen del color de tu web. Eso se arregla con una línea de CSS (.bblgg-notice img{background:#fff}).

GaranLabs (parecía el más completo, pero tiene sus cosas)

EU Legal-Guarantee Notice & GARAN Durability Label for WooCommerce, de GaranLabs, es gratis y no tiene versión de pago. Sobre el papel es el más completo, con el aviso en la ficha, en la cabecera, en el pago y en el correo (como enlace, imagen o adjunto), la GARAN y 24 idiomas.

Al revisar el código de la versión 1.9.2 me he encontrado esto:

• Si al desactivarlo rellenas el formulario de opinión, envía el texto, la dirección de tu web y el correo del administrador a un servidor externo (Supabase), sin decirlo en el formulario. Y su ficha asegura que no envía datos a ningún sitio.
• Sus imágenes del aviso no son las oficiales tal cual, porque están recortadas y tienen otro azul (#0049B6 en lugar del #034EA2 oficial). De hecho, son exactamente las mismas que las de WarrantyARK.
• En la página de pago pone el aviso arriba del todo, no junto al botón.
• La GARAN no aparece en productos variables, ni en el pago con bloques ni en los correos.
• El formato de adjunto de la GARAN en los correos llama a una función de WordPress (wp_tempnam()) sin cargar el archivo que la define, así que puede provocar un error fatal cuando el pedido se hace desde la web.
• En catalán, euskera o gallego muestra el aviso en inglés, salvo que fijes el idioma a mano.
• En su modo de ventana emergente el aviso se abre a unos 420 píxeles de ancho, con la letra muy pequeña.

El complemento del repositorio le arregla el idioma y le pone el aviso junto al botón, pero lo demás depende de que lo corrija su autor.

Germanized (solo si ya lo usas)

Germanized es el más completo de todos y es gratis. Usa el PNG oficial, adjunta el PDF al correo, genera la GARAN admitiendo medios años y tiene un bloque propio para el checkout de bloques. Pero viene desactivado, en el checkout de bloques tienes que colocar su bloque a mano, si eliges mostrarlo en el checkout clásico lo pone después de las notas del pedido y, sobre todo, es un plugin pensado para la legislación alemana que añade y cambia muchas más cosas en tu tienda. Si ya lo usas, actívalo, y si no, no lo instales solo para esto.

Los que NO te recomiendo

• WarrantyARK: sus imágenes del aviso son las mismas que las de GaranLabs, recortadas y con otro azul. En la GARAN redondea los meses, así que una garantía de 30 meses aparece como de 3 años, y si no rellenas la marca pone el nombre de tu tienda.
• StackedBoost: rehace el aviso en HTML en lugar de usar el archivo oficial y no pone nada en la página de pago.
• Merqivio EU Compliance: solo pone el aviso en la ficha de producto, en un único idioma y rodeado de un título y una insignia propios.
• CertaCart: no trae el aviso, solo te deja elegir una imagen de tu biblioteca de medios para mostrarla.

EU Withdrawal and Legal Guarantee Compliance

EU Withdrawal and Legal Guarantee Compliance (antes EU Withdrawal Compliance) nació para la función de desistimiento obligatoria de la Directiva 2023/2673, y el aviso armonizado sale de otra modificación de la misma directiva de derechos de los consumidores, así que tenía todo el sentido meterlo ahí. De hecho, en la 2.3.0 le cambié el nombre, porque el antiguo solo hablaba del desistimiento, pero si ya lo tienes instalado lo único que cambia es cómo aparece en la lista de plugins.

Desde esa versión 2.3.0 trae un módulo nuevo para el aviso que hace esto:

• Lleva dentro el PNG y el PDF oficiales en los 24 idiomas, así que no tienes que descargar ni subir nada. Como el paquete de PNG de la Comisión no trae el inglés, ese lo he convertido desde el PDF oficial, al mismo tamaño que los demás y sin tocar nada.
• Pone el aviso justo encima del botón de pedido, en el checkout clásico y en el de bloques. Puedes elegir entre verlo completo (es lo que viene por defecto), desplegable, en una ventana por encima de la página o no ponerlo en el checkout, por si prefieres colocarlo por tu cuenta.
• Lo incluye en los correos de confirmación al cliente con el PDF oficial adjunto, y si usas WPML o Polylang con WooCommerce, en el idioma del pedido.
• Usa el aviso en castellano en webs en catalán, euskera, gallego, asturiano o aragonés, y con otras lenguas sin aviso oficial hace lo mismo con el idioma oficial de su país.
• Añade la nota de los tres años con un enlace a tus condiciones cuando la tienda está en España (y la puedes forzar si vendes a España desde otro país).
• Trae dos shortcodes para montar tu propia página de garantía legal, [[ayudawp_guarantee_notice]], que pone en ella el aviso completo, y [[ayudawp_guarantee_link]], que la enlaza desde el pie o desde donde quieras.
• Solo aparece si el carrito lleva algún producto físico y deja una nota en cada pedido con el aviso que se mostró.

Si lo instalas ahora, el módulo viene activado. Si ya lo tenías, al actualizar llega apagado y te sale un aviso en el escritorio con un botón para activarlo, porque no me parece bien cambiarle a nadie la página de pago sin preguntar. Si ya lo usas para el desistimiento, con actualizar y pulsar ese botón tienes las dos cosas resueltas en el mismo sitio.

Lo que no hace, de momento, es la GARAN ni el aviso en la ficha de producto o en la cabecera, que quedan para más adelante. Si necesitas la GARAN ya, combínalo con Arthur Smith (o con Germanized, si ya lo usas) y desactiva el aviso en ese otro para que no salga dos veces.

Y ojo, que el plugin pasa de ocupar poco más de medio mega a unos 5 MB por los 48 archivos oficiales que lleva dentro. Eso es lo que ocupa en tu servidor, no lo que carga la web, que solo pide la imagen del idioma que toca y solo donde se muestra el aviso. El resto de detalles, ajuste por ajuste, los tienes en las preguntas frecuentes de su ficha.

No quiero otro plugin ¿no decías que hay un código?

Si prefieres no añadir otro plugin, o si el tuyo no cubre algo, tienes los snippets en este repositorio de GitHub, con las instrucciones completas en español y en inglés. Son tres y solo tienes que usar uno:

• El independiente (ayudawp-garantia-legal.php), que no necesita ningún plugin.
• El complemento para Arthur Smith, que usa el aviso del plugin y lo coloca junto al botón.
• El complemento para GaranLabs, que hace lo mismo y además le arregla el idioma.

El independiente hace todo esto:

• Muestra el aviso oficial justo encima del botón de pedido, en el checkout clásico y en el de bloques.
• Lo incluye en los correos de confirmación al cliente y le adjunta el PDF oficial, porque muchos programas de correo bloquean las imágenes.
• Añade debajo la nota de los tres años con un enlace a tus condiciones, solo si tu tienda está en España.
• Usa el aviso en castellano en webs en catalán, euskera o gallego, y en cualquier idioma que no tenga aviso oficial.
• Solo aparece si el carrito lleva algún producto físico.
• Deja una nota en cada pedido con el aviso que se mostró, por si algún día te lo preguntan.

Tiene tres modos de mostrarlo. El completo pone el aviso a la vista, el desplegable muestra una línea que lo abre debajo y la ventana es un botón que lo abre grande por encima de la página, con el popover nativo del navegador y sin JavaScript. Si tu tema pone el resumen del pedido en una columna estrecha, como Storefront en el checkout clásico, usa la ventana, porque el aviso completo se queda por debajo de 300 píxeles de ancho y no hay quien lo lea.

Lo que no hace tampoco es la GARAN, que depende de los datos de cada producto, así que para eso tendrás que tirar de un plugin. Si la necesitas, instala Arthur Smith, que es el que la resuelve con más cuidado, y usa su complemento en lugar del snippet independiente. Y si tu plugin ya hace una parte (market-it!, por ejemplo, pone el aviso en el checkout pero no en el correo), en los ajustes del snippet puedes apagar lo que ya tienes y quedarte con el resto.

Lo he probado con WordPress 7.1.1 y WooCommerce 11.1.1, en los dos checkouts, con los temas Twenty Twenty-Five y Storefront, con HPOS (el almacenamiento de pedidos de alto rendimiento de WooCommerce) activado y desactivado, y con la web en español, catalán, euskera, gallego, alemán e inglés. Aun así, haz un pedido de prueba y mira cómo te llega el correo antes de darlo por bueno.

Consejos para tiendas en España

• Una sección de garantía en tus condiciones: con el ancla #garantia-legal, en la que expliques los tres años para bienes nuevos, los dos para contenidos digitales, el plazo pactado en segunda mano, la presunción de dos años y cómo reclamar. Es a donde enlaza la nota del snippet.
• Una página «Garantía legal» enlazada desde el pie: con el aviso a tamaño completo, el enlace a Your Europe y el texto del aviso para quien use un lector de pantalla (el PDF oficial tiene capa de texto, así que puedes copiarlo de ahí). Con eso cubres también lo del recordatorio general en la web, y si usas mi plugin, sus dos shortcodes te ponen el aviso y el enlace.
• Catalán, euskera y gallego: no hay aviso oficial en esas lenguas, así que lo razonable es el castellano. Confírmalo con tu asesoría si tu tienda funciona sobre todo en una de ellas.
• Segunda mano: si pactas un plazo menor (nunca por debajo de un año), déjalo claro en la ficha y en tus condiciones, porque el aviso solo habla de la regla general.
• Tienda física: imprime el PDF en A4 como mínimo, en color o en blanco y negro, y ponlo en un sitio visible, por ejemplo junto a la caja.

¿Tengo que hacer algo antes de que entre en vigor?

Si vendes productos físicos a consumidores, sí, y te lleva poco rato:

1. Elige uno de los plugins que te he contado (el mio, por supuesto) o el snippet de código.
2. Descarga el PNG en color y el PDF oficiales en tu idioma.
3. Coloca el aviso junto al botón de pedido y en el correo de confirmación.
4. Añade la nota de los tres años y la sección de garantía en tus condiciones.
5. Si vendes productos con una garantía de durabilidad del fabricante gratuita, de más de dos años y que cubra todo el producto, añade la GARAN a esos productos.
6. Haz un pedido de prueba y abre el correo en Gmail y en Outlook.
7. Si tienes tienda física, imprime el cartel.

Y hasta aquí. Qué plugin usar, o si prefieres el código, lo decides tú, y si tienes dudas, o has probado alguno de estos plugins y te ha ido distinto, me tienes ahí abajo, en la sección de comentarios.

Si estás poniendo al día la parte legal de tu tienda, te interesa también repasar la función de desistimiento obligatoria en la UE, cómo guardar el registro de consentimiento de cookies, formularios y pedidos, el RGPD en WooCommerce y los errores legales y de seguridad que ponen en riesgo una tienda online.

Ojalá sea el último cartel obligatorio del año, aunque no me lo creo ni yo.

Un plugin que no está en el repositorio oficial no tiene por defecto ningún sistema de actualizaciones, y menos automático, así que cada cliente se queda para siempre en la versión que instaló y tú acabas repartiendo zips por correo o desde tu Ecommerce, uno a uno, rezando para que los suban a mano y lo hagan bien.

Llevo un tiempo distribuyendo así los plugins que distribuyo desde plugins.ayudawp.com, que es de donde salen hoy las actualizaciones de Intellimmerce y de VulgatAI, y te voy a contar el montaje entero, que se resume en una línea en la cabecera del plugin, una clase y un fichero JSON.

No hacen falta librerías de código de terceros, ni servicios de pago, ni cuotas, ni un plugin cliente que tengan que instalarse tus clientes. Es un mecanismo del propio WordPress y lleva funcionando desde la versión 5.8, o sea desde julio de 2021.

Saca papel y boli para apuntar, eso sí, que hay tres o cuatro detalles finos que, si te los saltas, hacen que el sistema falle sin que te enteres. No verías ningún error por ningún lado, simplemente no le llegará nunca una actualización a nadie, y no quieres eso ¿verdad?

¿No decías que no vendes plugins premium, que todos tus plugins son gratis?

Que ya os veo venir, y con razón, que sí, que llevo años repitiendo que mis plugins del directorio de WordPress.org son gratis del todo, sin versión pro, sin pantallas de «desbloquea esto» y sin funciones a medias, porque estoy hasta las narices de instalar plugins que resultan ser el escaparate de otro plugin, y tú también ¿no?. Pero voy y ahora te suelto un manual para cobrar por plugins. ¿En qué quedamos?

A ver, lo que me revienta no es que alguien cobre por su trabajo, faltaría más, es que te traten como el burro de la zanahoria. Subes al directorio una versión mutilada, recoges instalaciones activas y valoraciones a costa del trabajo gratis de los traductores y de la gente que se molesta en reportarte fallos, y usas todo eso de embudo para vender la versión que de verdad hace lo que promete la descripción.

Aquí no hay nada de eso, los más de veinte plugins que tengo en el directorio hacen lo que dicen que hacen y ninguno lleva una versión de pago, son 100% gratis, no hay versión premium adicional. Intellimmerce y VulgatAI (y otros) no han pisado el directorio nunca, se venden como lo que son desde el primer día y no hay una versión gratuita suya que capar, porque no existe. Son cosas distintas en sitios distintos, y por eso lo que vendo lo vendo en su tienda y lo que regalo lo regalo entero.

Y fíjate en que esto no es solo una postura, es la razón técnica de que hayas leído todo lo anterior. Si hiciera freemium no habría necesitado nada de este artículo, porque el plugin gratis del directorio se actualizaría solo desde wordpress.org y llevaría dentro la comprobación de licencia y el actualizador de la versión de pago, que es como lo hace media industria.

Todo el montaje de la cabecera, el filtro y el JSON hace falta precisamente porque los de pago no tocan el directorio. Hasta Plugin Check te lo dice a su manera dándote un error por esa cabecera. Allí dentro, o una cosa o la otra.

¡Hala ya! Entiendo que debía la explicación, pero lo importante es que aquí estamos para aprender.

Por qué no utilizo un servidor de actualizaciones

En enero te hablé aquí de Deploy Troy, el proyecto con el que montarte tu propio repositorio de plugins. Me pareció, y me sigue pareciendo, una solución muy bien pensada. Lo probé, lo monté en un subdominio con su WordPress dedicado, y lo he acabado quitando. ¿Y te preguntarás por qué?

No es porque sea malo el sistema, que no lo es, sino porque me sobra. Troy pide un WordPress independiente, PHP 8.4, MySQL 8.0.19, un tipo de contenido propio, un servidor y un plugin cliente instalado en la web de cada cliente. Todo eso para resolver algo que el core de WordPress ya resuelve con una cabecera y un filtro.

Y hay un argumento que me pesó más que los requisitos, ya me dirás si te convence, y es que quien vende plugins depende de su dominio por narices, porque ahí está la tienda, ahí está la descarga y ahí estaría cualquier validación de licencia.

Añadir el archivo (JSON) de actualizaciones a ese mismo dominio no supone problema alguno, de hecho Troy no te quita esa dependencia, te añade dos encima, la del segundo servidor y la de quien mantenga el proyecto. Puestos a depender de una sola persona, que sea de mí, que es lo único inevitable en este asunto.

Dicho todo esto, si distribuyes veinte plugins a veinte mil sitios, con dependencias entre ellos, canal beta y estadísticas de uso, Troy te va a dar todo eso hecho y lo mío se te va a quedar corto, también tienes que valorarlo ¿vale?

Seguimos… o más bien empezamos…

WordPress te permite ofrecer actualizaciones de manera nativa

Ya sabes que me encanta usar todo lo que viene de serie, y más si encima es gratis. En este caso la cosa se llama Update URI y entró en el core en mayo de 2021 (aquí la nota de desarrollo). Funciona en cuatro pasos:

1. Tu plugin declara en su cabecera de dónde vienen sus actualizaciones.
2. Como ese dominio no es wordpress.org, la API oficial deja de ofrecer actualizaciones para ese plugin, y el core dispara en su lugar un filtro cuyo nombre sale de ese dominio, por ejemplo update_plugins_plugins.ayudawp.com.
3. Tu plugin contesta a ese filtro consultando un pequeño archivo JSON en tu servidor, cacheando la respuesta y devolviéndole al core qué versión hay y de dónde bajarla.
4. El core de WordPress hace absolutamente todo lo demás: el aviso en la lista de plugins, el botón, la barra de progreso, la ventana de detalles y las actualizaciones automáticas si el cliente las tiene activadas.

Antes de que te ilusiones de más, un matiz importante es que la cabecera no impide que la web de tu cliente le hable a wordpress.org de tu plugin.

Si te vas a wp-includes/update.php y miras la función wp_update_plugins(), verás que el core manda la lista completa de plugins instalados a api.wordpress.org pase lo que pase. Lo que cambia es que la API no responde por el tuyo. O sea, wordpress.org sigue sabiendo que tu plugin existe y de en cuántas webs está (más abajo te cuento cómo taparlo, que se puede).

Que la API no responda por el tuyo tampoco hay que creérselo, que se comprueba fácil. En una instalación de pruebas elige una carpeta con el nombre de un plugin que sí esté en el directorio, ponle una versión vieja para que haya actualización disponible y lanza la comprobación dos veces, una sin la cabecera y otra con ella:

akismet/akismet.php 3.0.0, sin Update URI  → wordpress.org ofrece la 5.7.2
akismet/akismet.php 3.0.0, con Update URI  → wordpress.org no devuelve nada

La API lee la cabecera que le mandas y se quita de enmedio, que es exactamente para lo que se creó.

Antes de WordPress 5.8, si la carpeta de tu plugin tenía un nombre que nadie había registrado todavía en el directorio, cualquiera podía registrarlo allí y sus actualizaciones acababan instalándose encima del tuyo. El fallo tiene hasta identificador propio, el CVE-2021-44223, con una puntuación de 9,8 sobre 10 y calificado de crítico.

Por cierto, lo mismo existe para temas desde WordPress 6.1, con el filtro update_themes_{$hostname}. Aquí voy a hablar de plugins, pero el mecanismo es idéntico.

Ahora ya sí, de verdad, empezamos…

Cómo montar un plugin para distribuirlo con actualizaciones automáticas

Parece algo pero en realidad una vez tienes hecho el primero es tremendamente sencillo, y nada exigente técnicamente, casi sorprende que sea algo tan trivial y rápido.

La cabecera y la constante

Esta es la única parte del plugin que WordPress mira por su cuenta, sin que tú le pidas nada, así que conviene entender bien qué lee exactamente y qué se inventa tu código.

<?php
/**
 * Plugin Name: Mi Plugin
 * Plugin URI:  https://miplugin.com/
 * Version:     1.0.0
 * Author:      Fernando Tellado
 * Update URI:  https://plugins.ayudawp.com/miplugin
 */

define( 'MIPLUGIN_FILE', __FILE__ );
define( 'MIPLUGIN_PLUGIN_BASENAME', plugin_basename( __FILE__ ) );

// El mismo valor que la cabecera de arriba, y tiene que seguir siendo el mismo.
define( 'MIPLUGIN_UPDATE_URI', 'https://plugins.ayudawp.com/miplugin' );

Vamos línea por línea, que cada una está ahí por un motivo.

• La cabecera Update URI es la que enciende todo el mecanismo. Va dentro del bloque de comentario del fichero principal, con el resto de cabeceras del plugin, y no en un fichero aparte ni en un include. Si no está, WordPress no dispara ningún filtro y tu plugin se queda como cualquier plugin suelto al que nadie actualiza nunca.
• De esa URL, WordPress solo se queda con el dominio. La línea que lo hace es wp_parse_url( sanitize_url( $plugin_data['UpdateURI'] ), PHP_URL_HOST ), así que de todo lo que has escrito se guarda plugins.ayudawp.com y tira el resto. A ese dominio le pega delante el prefijo update_plugins_ y ya tiene el nombre del filtro que va a disparar, que queda update_plugins_plugins.ayudawp.com. Sí, con puntos en medio del nombre del filtro. Queda rarísimo y es correcto.
• Esa URL no tiene por qué existir, y es la parte que más despista. WordPress no la visita jamás, no descarga nada de ahí y le da igual si devuelve un 404 o si el dominio ni siquiera resuelve. Lo único que hace es sacarle el dominio y luego guardarla tal cual como identificador de la actualización. Quien decide de dónde se baja el JSON y de dónde se baja el zip es tu código, no esta línea. Dicho lo cual, ponla apuntando a la página del plugin en vez de a algo inventado, que alguien acabará copiándola del código y siguiéndola.
• El dominio tiene que ser tuyo, no wordpress.org. Si ahí pones una dirección del directorio oficial, la API de wordpress.org vuelve a hacerse cargo del plugin y todo lo que viene después sobra. Es el interruptor que decide quién manda sobre las actualizaciones de ese plugin, y solo admite un dueño.
• La constante repite el valor de la cabecera, y no es un despiste. Tu actualizador necesita ese dominio para saber a qué filtro engancharse, y sacarlo de la cabecera en tiempo de ejecución significa cargar un fichero de wp-admin y llamar a get_plugin_data() en cada arranque, que es mucho gasto para lo poco que aporta. Una constante es gratis y está disponible desde el primer momento. El precio de esa comodidad es que el mismo valor pasa a vivir en dos sitios.
• Y por eso las dos se cambian a la vez, siempre. WordPress saca el nombre del filtro de la cabecera y tu actualizador engancha ese filtro leyendo la constante. Si tocas solo una, el plugin se queda enganchado a un filtro que nadie dispara. No hay error, no hay aviso y no hay actualizaciones. Nunca más.
• Las otras dos constantes son para más adelante. MIPLUGIN_PLUGIN_BASENAME la va a usar el actualizador para comprobar que la pregunta que le llega es sobre este plugin y no sobre otro tuyo servido desde el mismo dominio, que es el fallo más caro de todo el montaje y lo veremos luego. Y MIPLUGIN_FILE le servirá para leer el nombre y el autor de su propia cabecera cuando tenga que pintar la ventana de detalles. Se definen aquí porque aquí es donde __FILE__ vale lo que tiene que valer.

Un detalle importante es que WordPress lee las cabeceras con get_file_data(), que carga solo los primeros 8 KB del fichero. Si tu plugin arranca con el texto entero de la licencia GPL en comentarios, o con un bloque de documentación kilométrico por delante, el Update URI se puede quedar fuera de esos 8 KB y WordPress no llegará a verlo.

El síntoma es idéntico al de la constante mal copiada, o sea ninguno, porque el plugin funciona, no da ni un error y no se actualiza jamás. Deja las cabeceras arriba del todo y te ahorras el disgusto.

Y avisado quedas también de que la cabecera es justo lo que hace que Plugin Check te dé un error de tipo plugin_updater_detected, porque wordpress.org no la admite en plugins alojados allí. Es correcto que lo dé, no es un fallo que arreglar, es el precio de haber elegido otro canal.

Carpetas que tienes que preparar en tu servidor

Dos carpetas en tu dominio, servidas tal cual, sin login ni nada, limpias:

/updates/
    miplugin.json
    mi-otro-plugin.json
/files/
    miplugin/
        miplugin-1.0.0.zip
        miplugin-1.1.0.zip
        miplugin-1.2.0.zip
    mi-otro-plugin/
        mi-otro-plugin-2.3.0.zip
        mi-otro-plugin-2.3.1.zip

Los JSON pueden ir todos sueltos en updates/ porque hay uno por plugin y no crecen, solo los vas sustituyendo. Los zips sí, es mejor que vayan en carpeta propia porque sí se van acumulando, uno por versión publicada, y conviene no borrar los viejos para poder volver atrás si una sale malamente.

No uses las descargas de WooCommerce

Esto es una puntualización importante, para que no trates de ahorrarte pasos, y es que el zip no puede ser un archivo descargable de WooCommerce, no cometas ese error.

Quien lo descarga es el servidor de tu cliente, sin sesión y sin cookies, así que la carpeta wp-content/uploads/woocommerce_uploads/ no vale, porque va protegida con un deny from all y devuelve un 403. Además, la URL de descarga de Woo, esa con ?download_file= y &key=, tampoco, porque es por pedido, gasta el límite de descargas del cliente y caduca.

Tienes que alojar los zip de tu plugin o tema en una carpeta normal y pública, servida como cualquier otro archivo.

Además, apunta que deberías desactivar el listado de directorios en las dos carpetas, con un Options -Indexes en el .htaccess o desde el panel de tu hosting. No es una cuestión de seguridad, que el zip es GPL, es que un listado abierto le cuenta a cualquiera tu histórico completo, o sea cuántas versiones sacas, a qué ritmo y cuándo dejaste de sacarlas. Eso es información de negocio, no de código.

Que la URL del zip sea pública no es un agujero, aunque a alguno le rechinen los dientes desde hace dos párrafos. El código es GPL de todas formas, y lo que protege una venta es el acceso a la tienda, al soporte y a las actualizaciones, no ofuscar una URL que cualquiera puede leer del JSON en dos segundos. Si algún día metes licencias, la validación irá en el endpoint, no en esconder el fichero.

El archivo JSON con la información de las actualizaciones

Este es el fichero que va en la carpeta /updates, con todos los campos recomendables, y está pensado para que en cada versión solo cambie el número de versión:

{
  "version": "1.1.0",
  "package": "https://plugins.ayudawp.com/files/miplugin/miplugin-1.1.0.zip",
  "url": "https://miplugin.com/",
  "tested": "7.1",
  "requires": "6.5",
  "requires_php": "7.4",
  "sections": {
    "description": "Lo que hace el plugin, en dos frases.",
    "changelog": "<p>Changelog completo: <a href=\"https://miplugin.com/changelog.txt\" target=\"_blank\" rel=\"noopener\">miplugin.com/changelog.txt</a></p>"
  }
}

Hay un campo más que no está en la tabla y que casi nadie usa, el translations, un array con language y package por idioma. Si repartes los ficheros de traducción por separado en vez de empaquetarlos dentro del plugin, el core también te los actualiza por esta vía. Si los llevas dentro del zip, como suele ser lo normal, ni te hace falta.

Y fíjate en tres ausencias, que son deliberadas.

• No hay slug. El slug lo sabe el propio plugin, va en una constante de su clase, y no tiene ningún sentido mandarlo desde el servidor. Ojo, que no esté en el JSON no significa que no haga falta, porque es imprescindible y ahora verás por qué.
• No hay last_updated. Es un campo que habría que actualizar a mano en cada versión y que, en cuanto te lo saltes una vez, enseña una fecha falsa. Sin él WordPress simplemente no muestra esa línea, que es bastante mejor que mostrarla mal.
• El changelog es un enlace, no una lista. Copiar aquí las notas de cada versión significa escribirlas dos veces, en tu changelog.txt y en el JSON, y a la segunda entrega ya están desincronizadas. Con el enlace, sections no se toca nunca más. El target="_blank" de ahí dentro no es decorativo: la ventana de detalles es un iframe pequeño dentro del escritorio, y sin él el fichero de texto se abriría ahí dentro, apretujado.

El actualizador automático

Se suele decir que con este sistema «no programas nada de la actualización», y es mentira, o casi. Es verdad que no programas la descarga, ni la instalación, ni la interfaz, que todo eso lo pone el core. Pero alguien tiene que escribir la clase que contesta al filtro, y esa clase tiene cuatro cosas que hacer, cada una con su truqui:

1. Engancharse al filtro que WordPress dispara para tu dominio.
2. Contestar a ese filtro diciendo qué versión hay y de dónde bajarla.
3. Servir la ventana de detalles, que el core no va a rellenar por ti.
4. Cachear la respuesta de tu servidor, para no machacarlo ni hacer esperar al cliente.

Y hay un quinto paso que no está dentro de la clase pero que decide si la clase llega a ejecutarse siquiera, que es dónde la cargas. Vamos uno por uno, y al final te dejo el fichero completo para copiarlo de una vez.

Paso 1. El enganche al filtro

Este es el arranque de la clase, con las tres constantes de configuración y el método que la conecta con WordPress. Es lo único que se ejecuta siempre, en cada carga de cada página del escritorio de tu cliente, así que tiene que ser barato.

class Miplugin_Updater {

    const ENDPOINT  = 'https://plugins.ayudawp.com/updates/miplugin.json';
    const SLUG      = 'miplugin';
    const TRANSIENT = 'miplugin_update';

    public function hooks() {
        $host = $this->host();

        // Sin host, o publicado en WordPress.org después de todo, y en los dos
        // casos esto no debe meterse en medio.
        if ( '' === $host || false !== strpos( $host, 'wordpress.org' ) ) {
            return;
        }

        add_filter( "update_plugins_{$host}", array( $this, 'check' ), 10, 3 );
        add_filter( 'plugins_api', array( $this, 'information' ), 20, 3 );
        add_action( 'upgrader_process_complete', array( $this, 'flush' ) );

        // Entrar en Escritorio > Actualizaciones es preguntar si hay algo nuevo,
        // así que ahí se tira la caché antes de que el core haga su comprobación.
        // Prioridad 5 porque el core engancha su wp_update_plugins() en la 10.
        add_action( 'load-update-core.php', array( $this, 'flush' ), 5 );
    }

    private function host() {
        if ( ! defined( 'MIPLUGIN_UPDATE_URI' ) || '' === MIPLUGIN_UPDATE_URI ) {
            return '';
        }

        $host = wp_parse_url( sanitize_url( MIPLUGIN_UPDATE_URI ), PHP_URL_HOST );

        return is_string( $host ) ? $host : '';
    }

Las constantes son las tres cosas que cambias cuando adaptes esto a tu plugin. ENDPOINT es la URL del JSON, SLUG es el nombre de la carpeta del plugin y TRANSIENT es el nombre de la opción donde guardas la respuesta cacheada.

Y hay dos detalles del método hooks() que no son adorno.

• La salida temprana si el dominio es wordpress.org. El día que decidas publicar el plugin en el directorio oficial, esto se aparta solo en vez de pelearse con el core.
• La prioridad 5 en load-update-core.php. El core engancha su wp_update_plugins() a esa misma acción con prioridad 10, y una caché que se limpia después de que te hayan preguntado no le sirve a nadie. Con el 5, la pantalla de Escritorio > Actualizaciones dice siempre la verdad, y es la que hay que abrir para comprobar si algo se ha publicado.

Paso 2. La respuesta al core

Ya estás enganchado, o sea que ahora te van a preguntar. Este método es el que WordPress llama cuando quiere saber si hay versión nueva, y el que decide lo que acaba viendo tu cliente en su listado de plugins.

    public function check( $update, $plugin_data, $plugin_file = '' ) {
        if ( ! $this->is_this_plugin( $plugin_file, $plugin_data ) ) {
            return $update;
        }

        $remote = $this->remote();
        if ( ! is_array( $remote ) || empty( $remote['version'] ) ) {
            return $update;
        }

        $answer = array(
            'slug'    => self::SLUG,
            'version' => sanitize_text_field( (string) $remote['version'] ),
        );

        // Sin paquete no hay nada que instalar, así que se avisa de la versión
        // pero no se ofrece un botón roto.
        if ( ! empty( $remote['package'] ) ) {
            $answer['package'] = esc_url_raw( (string) $remote['package'] );
        }

        // Este es el enlace que WordPress mete en el correo de aviso tras una
        // actualización automática. Sin respaldo, que mejor sin enlace que con
        // uno que no lleve a ninguna parte.
        if ( ! empty( $remote['url'] ) ) {
            $answer['url'] = esc_url_raw( (string) $remote['url'] );
        }

        foreach ( array( 'tested', 'requires', 'requires_php', 'upgrade_notice' ) as $key ) {
            if ( ! empty( $remote[ $key ] ) ) {
                $answer[ $key ] = sanitize_text_field( (string) $remote[ $key ] );
            }
        }

        return $answer;
    }

    private function is_this_plugin( $plugin_file, $plugin_data ) {
        if ( '' !== (string) $plugin_file ) {
            return MIPLUGIN_PLUGIN_BASENAME === $plugin_file;
        }

        if ( is_array( $plugin_data ) && ! empty( $plugin_data['UpdateURI'] ) ) {
            return MIPLUGIN_UPDATE_URI === $plugin_data['UpdateURI'];
        }

        return false;
    }

• Primera trampa, la más cara de todo el montaje y la más fácil de no ver hasta que ya te ha explotado. El filtro se llama por el dominio, no por el plugin. WordPress recorre todos los plugins instalados y lo dispara una vez por cada uno que declare ese dominio, así que el día que tengas dos plugins tuyos servidos desde el mismo sitio, los dos actualizadores van a recibir las preguntas de ambos. Un actualizador que conteste sin mirar por quién le preguntan le ofrecerá su propio zip al otro plugin, y la web del cliente acabará instalando el plugin equivocado encima de uno que estaba perfectamente sano, dejándolo desactivado y con dos carpetas en el listado. De ahí que lo primero que hace el método sea comprobar que la pregunta va con él.
• Segunda trampa, y es el detalle más sutil del artículo, porque se ve mirando lo que el método no hace. Fíjate en que la respuesta se devuelve siempre, haya versión nueva o no. Parece un desperdicio, ya que si el cliente tiene la última no hay nada que ofrecerle.

Pues de eso depende que tus clientes puedan usar las actualizaciones automáticas. El core hace su version_compare y, si tu versión no es mayor, mete igualmente la respuesta en el apartado no_update del transitorio. Y en wp-admin/includes/class-wp-plugins-list-table.php la columna «Actualizaciones automáticas» solo marca ese plugin como compatible si aparece en response o en no_update.

Traducido a lo que ve tu cliente, si contestas siempre, ve el enlace de «Activar actualizaciones automáticas», y si contestas solo cuando hay novedad, esa columna se le queda en blanco y pierde las automáticas sin saber por qué.

Paso 3. La ventana de detalles

Con lo anterior ya tienes el aviso, el botón y la barra de progreso. Pero te queda un enlace suelto, el de «Ver los detalles de la versión», y ese lo tienes que atender tú.

    public function information( $result, $action, $args ) {
        if ( 'plugin_information' !== $action ) {
            return $result;
        }

        if ( ! isset( $args->slug ) || self::SLUG !== $args->slug ) {
            return $result;
        }

        $remote = $this->remote();
        if ( ! is_array( $remote ) || empty( $remote['version'] ) ) {
            return $result;
        }

        if ( ! function_exists( 'get_plugin_data' ) ) {
            require_once ABSPATH . 'wp-admin/includes/plugin.php';
        }
        $headers = get_plugin_data( MIPLUGIN_FILE, false, false );

        $sections = array();
        if ( ! empty( $remote['sections'] ) && is_array( $remote['sections'] ) ) {
            foreach ( $remote['sections'] as $name => $content ) {
                $sections[ sanitize_key( $name ) ] = wp_kses_post( (string) $content );
            }
        }
        if ( empty( $sections['description'] ) ) {
            $sections['description'] = wp_kses_post( $headers['Description'] );
        }

        return (object) array(
            'name'          => $headers['Name'],
            'slug'          => self::SLUG,
            'version'       => sanitize_text_field( (string) $remote['version'] ),
            'author'        => $headers['Author'],
            'homepage'      => $headers['PluginURI'],
            'requires'      => ! empty( $remote['requires'] ) ? sanitize_text_field( (string) $remote['requires'] ) : $headers['RequiresWP'],
            'tested'        => ! empty( $remote['tested'] ) ? sanitize_text_field( (string) $remote['tested'] ) : '',
            'requires_php'  => ! empty( $remote['requires_php'] ) ? sanitize_text_field( (string) $remote['requires_php'] ) : $headers['RequiresPHP'],
            'download_link' => ! empty( $remote['package'] ) ? esc_url_raw( (string) $remote['package'] ) : '',
            'sections'      => $sections,
        );
    }

Esto no es un extra bonito, es obligatorio, y aquí es donde te la juegas si copias un tutorial a medias.

Mira lo que hace el core en wp-admin/includes/update.php. Si tu respuesta trae slug, el enlace de «Ver detalles» apunta a la pantalla interna plugin-install.php, y esa pantalla le pregunta a wordpress.org, donde tu plugin no existe. Lo que se encuentra tu cliente es un «Plugin not found» encima de una actualización que estaba perfecta.

Y no puedes escaparte quitando el slug, aunque en el listado de plugins parezca que sí. En wp-admin/update-core.php, la pantalla de «Escritorio > Actualizaciones» construye ese enlace usando $plugin_data->update->slug a pelo, sin ninguna alternativa. Sin slug, el cliente se encuentra un enlace roto justo en la pantalla donde va a mirar. Así que mandas slug y enganchas plugins_api. No hay atajo.

Fíjate también en que el nombre, el autor y la web salen de get_plugin_data(), o sea de la propia cabecera del plugin y no del servidor. Así el JSON se queda corto y no tienes dos sitios que mantener sincronizados.

Paso 4. La caché

Los dos métodos anteriores llaman a remote(), que es el único de toda la clase que habla con tu servidor. Sin caché, cada carga del escritorio de cada cliente sería una petición a tu dominio, y multiplica eso por todos los que te hayan comprado el plugin.

    private function remote() {
        $cached = get_transient( self::TRANSIENT );
        if ( is_array( $cached ) ) {
            return $cached;
        }
        if ( 'none' === $cached ) {
            return null;
        }

        $response = wp_remote_get(
            self::ENDPOINT,
            array(
                // Como el core, generoso por cron, donde nadie espera, y corto en
                // primer plano, donde hay alguien mirando una pantalla en blanco.
                'timeout' => wp_doing_cron() ? 30 : 5,
                'headers' => array( 'Accept' => 'application/json' ),
            )
        );

        $body = ( ! is_wp_error( $response ) && 200 === (int) wp_remote_retrieve_response_code( $response ) )
            ? json_decode( wp_remote_retrieve_body( $response ), true )
            : null;

        if ( ! is_array( $body ) || empty( $body['version'] ) ) {
            set_transient( self::TRANSIENT, 'none', HOUR_IN_SECONDS );
            return null;
        }

        set_transient( self::TRANSIENT, $body, 12 * HOUR_IN_SECONDS );

        return $body;
    }

    public function flush() {
        delete_transient( self::TRANSIENT );
    }
}

Hay dos duraciones distintas y las dos tienen su motivo. Doce horas cuando todo va bien, para que un escritorio muy transitado no se convierta en un servidor muy transitado. Y solo una hora cuando tu servidor no contesta, para que una caída tuya no se traduzca en una petición fallida en cada carga del escritorio de cada cliente.

Y sobre el timeout, fíjate en que no es un número fijo, y eso está copiado del core. Para su propia petición a wordpress.org, WordPress usa 3 + (int) ( count( $plugins ) / 10 ) cuando hay alguien delante, o sea cuatro o cinco segundos en una web normal, y sube a 30 cuando corre por cron. La lógica es buena y no hay razón para inventarse otra. E

n primer plano, cada segundo de más es un segundo que tu cliente se come mirando un listado de plugins que no carga, y por cron no hay nadie esperando y más vale aguantar que quedarse sin comprobar.

Paso 5. Dónde cargas la clase

La clase ya está entera, pero falta lo que decide si llega a ejecutarse. Esto va en el fichero principal del plugin y el orden importa mucho más de lo que parece.

// Antes que nada. Sobre todo, antes de cualquier comprobación de dependencias.
require_once plugin_dir_path( __FILE__ ) . 'includes/class-updater.php';
( new Miplugin_Updater() )->hooks();

// Y a partir de aquí, lo que sea que necesite tu plugin para arrancar.
if ( ! class_exists( 'WooCommerce' ) ) {
    add_action( 'admin_notices', 'miplugin_aviso_dependencia' );
    return;
}

Casi todos los plugins hacen alguna comprobación antes de arrancar del todo, sea que exista una dependencia, que la versión de PHP llegue o que la licencia valga. Y casi todos meten la carga entera dentro de esa comprobación, actualizador incluido.

El día que esa comprobación falle, y va a fallar alguna vez, tu plugin se queda activo pero deja de enganchar el filtro y no vuelve a recibir una actualización nunca. Y ese es justo el momento en el que más falta te hace poder mandar un arreglo.

El actualizador es la pieza que no puede depender de nada, así que va la primera y fuera de cualquier retorno temprano. Cuidado también con lo que use tu clase, que si tira de una función auxiliar que cargas más abajo la has liado igual, y encima con un error fatal.

La clase completa

Todo lo anterior junto, listo para pegar en includes/class-updater.php. Son 176 líneas contando comentarios y líneas en blanco, y es todo el código que vas a escribir para esto, y te lo dejo casi hecho, así que…

<?php
/**
 * Actualizaciones desde el dominio propio, sin pasar por WordPress.org.
 *
 * @package Miplugin
 */

// Sin acceso directo.
if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

class Miplugin_Updater {

    const ENDPOINT  = 'https://plugins.ayudawp.com/updates/miplugin.json';
    const SLUG      = 'miplugin';
    const TRANSIENT = 'miplugin_update';

    public function hooks() {
        $host = $this->host();

        // Sin host, o publicado en WordPress.org después de todo, y en los dos
        // casos esto no debe meterse en medio.
        if ( '' === $host || false !== strpos( $host, 'wordpress.org' ) ) {
            return;
        }

        add_filter( "update_plugins_{$host}", array( $this, 'check' ), 10, 3 );
        add_filter( 'plugins_api', array( $this, 'information' ), 20, 3 );
        add_action( 'upgrader_process_complete', array( $this, 'flush' ) );

        // Entrar en Escritorio > Actualizaciones es preguntar si hay algo nuevo,
        // así que ahí se tira la caché antes de que el core haga su comprobación.
        // Prioridad 5 porque el core engancha su wp_update_plugins() en la 10.
        add_action( 'load-update-core.php', array( $this, 'flush' ), 5 );
    }

    private function host() {
        if ( ! defined( 'MIPLUGIN_UPDATE_URI' ) || '' === MIPLUGIN_UPDATE_URI ) {
            return '';
        }

        $host = wp_parse_url( sanitize_url( MIPLUGIN_UPDATE_URI ), PHP_URL_HOST );

        return is_string( $host ) ? $host : '';
    }

    public function check( $update, $plugin_data, $plugin_file = '' ) {
        if ( ! $this->is_this_plugin( $plugin_file, $plugin_data ) ) {
            return $update;
        }

        $remote = $this->remote();
        if ( ! is_array( $remote ) || empty( $remote['version'] ) ) {
            return $update;
        }

        $answer = array(
            'slug'    => self::SLUG,
            'version' => sanitize_text_field( (string) $remote['version'] ),
        );

        // Sin paquete no hay nada que instalar, así que se avisa de la versión
        // pero no se ofrece un botón roto.
        if ( ! empty( $remote['package'] ) ) {
            $answer['package'] = esc_url_raw( (string) $remote['package'] );
        }

        // Este es el enlace que WordPress mete en el correo de aviso tras una
        // actualización automática. Sin respaldo, que mejor sin enlace que con
        // uno que no lleve a ninguna parte.
        if ( ! empty( $remote['url'] ) ) {
            $answer['url'] = esc_url_raw( (string) $remote['url'] );
        }

        foreach ( array( 'tested', 'requires', 'requires_php', 'upgrade_notice' ) as $key ) {
            if ( ! empty( $remote[ $key ] ) ) {
                $answer[ $key ] = sanitize_text_field( (string) $remote[ $key ] );
            }
        }

        return $answer;
    }

    private function is_this_plugin( $plugin_file, $plugin_data ) {
        if ( '' !== (string) $plugin_file ) {
            return MIPLUGIN_PLUGIN_BASENAME === $plugin_file;
        }

        if ( is_array( $plugin_data ) && ! empty( $plugin_data['UpdateURI'] ) ) {
            return MIPLUGIN_UPDATE_URI === $plugin_data['UpdateURI'];
        }

        return false;
    }

    public function information( $result, $action, $args ) {
        if ( 'plugin_information' !== $action ) {
            return $result;
        }

        if ( ! isset( $args->slug ) || self::SLUG !== $args->slug ) {
            return $result;
        }

        $remote = $this->remote();
        if ( ! is_array( $remote ) || empty( $remote['version'] ) ) {
            return $result;
        }

        if ( ! function_exists( 'get_plugin_data' ) ) {
            require_once ABSPATH . 'wp-admin/includes/plugin.php';
        }
        $headers = get_plugin_data( MIPLUGIN_FILE, false, false );

        $sections = array();
        if ( ! empty( $remote['sections'] ) && is_array( $remote['sections'] ) ) {
            foreach ( $remote['sections'] as $name => $content ) {
                $sections[ sanitize_key( $name ) ] = wp_kses_post( (string) $content );
            }
        }
        if ( empty( $sections['description'] ) ) {
            $sections['description'] = wp_kses_post( $headers['Description'] );
        }

        return (object) array(
            'name'          => $headers['Name'],
            'slug'          => self::SLUG,
            'version'       => sanitize_text_field( (string) $remote['version'] ),
            'author'        => $headers['Author'],
            'homepage'      => $headers['PluginURI'],
            'requires'      => ! empty( $remote['requires'] ) ? sanitize_text_field( (string) $remote['requires'] ) : $headers['RequiresWP'],
            'tested'        => ! empty( $remote['tested'] ) ? sanitize_text_field( (string) $remote['tested'] ) : '',
            'requires_php'  => ! empty( $remote['requires_php'] ) ? sanitize_text_field( (string) $remote['requires_php'] ) : $headers['RequiresPHP'],
            'download_link' => ! empty( $remote['package'] ) ? esc_url_raw( (string) $remote['package'] ) : '',
            'sections'      => $sections,
        );
    }

    private function remote() {
        $cached = get_transient( self::TRANSIENT );
        if ( is_array( $cached ) ) {
            return $cached;
        }
        if ( 'none' === $cached ) {
            return null;
        }

        $response = wp_remote_get(
            self::ENDPOINT,
            array(
                // Como el core, generoso por cron, donde nadie espera, y corto en
                // primer plano, donde hay alguien mirando una pantalla en blanco.
                'timeout' => wp_doing_cron() ? 30 : 5,
                'headers' => array( 'Accept' => 'application/json' ),
            )
        );

        $body = ( ! is_wp_error( $response ) && 200 === (int) wp_remote_retrieve_response_code( $response ) )
            ? json_decode( wp_remote_retrieve_body( $response ), true )
            : null;

        if ( ! is_array( $body ) || empty( $body['version'] ) ) {
            set_transient( self::TRANSIENT, 'none', HOUR_IN_SECONDS );
            return null;
        }

        set_transient( self::TRANSIENT, $body, 12 * HOUR_IN_SECONDS );

        return $body;
    }

    public function flush() {
        delete_transient( self::TRANSIENT );
    }
}

Y ya está. A partir de aquí, la descarga, la instalación, la barra de progreso, el correo de aviso y las actualizaciones automáticas las pone WordPress, exactamente igual que para cualquier plugin del directorio oficial.

Qué hacer en cada nueva versión

Cuatro pasos, y el orden es importante, porque si publicas el JSON antes que el zip durante unos minutos tus clientes verán una actualización que no se puede descargar. Quitando ese detalle no tiene misterios, tardas 2 minutos:

1. Empaqueta el zip, y que la carpeta de primer nivel dentro se llame como el plugin. WordPress saca el destino de la instalación del nombre de esa carpeta, no del nombre del fichero. Si comprimes tu carpeta trunk/ tal cual, la actualización se instala en wp-content/plugins/trunk/ y el cliente acaba con dos copias del plugin, la buena desactivada.
2. Nómbralo con su versión, miplugin-1.1.0.zip. A WordPress le da igual cómo se llame, pero una URL fija que se sobrescribe en cada entrega puede servirse rancia desde cualquier caché, puede pillarse a medio subir por un cron que la esté descargando justo entonces, y no te deja volver atrás si una versión sale mal.
3. Sube el zip a su carpeta, junto a los de las versiones anteriores, que no se borran.
4. Actualiza el JSON: solo version y package, que son el mismo número escrito dos veces. El resto no se toca nunca, salvo tested cuando salga un WordPress nuevo.
5. Repasa el tested en los tres sitios donde vive: la cabecera del plugin, el readme.txt y el JSON. De los dos primeros ya te avisa Plugin Check si se te van; del tercero no te avisa nadie, y es justo el que ve tu cliente en la ventana de detalles.

Con el gestor de archivos de tu hosting o por FTP, como siempre.

Cuándo lo ve el cliente

Hay dos cachés en juego y conviene conocer las dos para no diagnosticar en falso. La primera es la del core, que decide cada cuánto pregunta, y está en ese switch de wp_update_plugins():

La segunda es la tuya, las doce horas del transitorio, con la excepción de «Escritorio > Actualizaciones» que ya hemos visto. En el resto del escritorio manda tu caché.

Un matiz sobre esa excepción es que tú tiras tu caché, pero si el core ya preguntó hace menos de un minuto, se sale antes de llamar a tu filtro. O sea que recargar esa pantalla dos veces seguidas no fuerza una consulta nueva. Espera el minuto y vuelve.

Cómo puedes comprobar que funciona a simple vista

El truco clásico es subir el JSON con una version inventada muy alta, entrar en «Escritorio > Actualizaciones», ver el aviso, pulsar «Ver detalles de la versión» para comprobar que la ventana se abre con su descripción y su changelog, y devolver luego el JSON a la versión real.

Pero hay uno mejor, más rápido y que no te obliga a tocar nada. Vete al listado de plugins y mira la columna «Actualizaciones automáticas» de tu plugin. Si ves el enlace de activarlas, tu JSON se está leyendo y todo va bien. Si la columna está en blanco, tu endpoint no está contestando. Es el mismo mecanismo del no_update que te contaba antes, usado al revés, y te da el diagnóstico de un vistazo.

Cuando algo no va

Quitar la petición a wordpress.org (opcional)

Volvamos a lo de antes. La cabecera evita que wordpress.org te conteste, pero no evita que la web de tu cliente le cuente que tiene tu plugin instalado. Si eso te molesta, y a mí un poco sí, se quita con un filtro más:

    public function unlist( $args, $url ) {
        // Este filtro corre en todas las peticiones salientes, así que se sale pronto.
        if ( false === strpos( $url, '//api.wordpress.org/plugins/update-check' ) ) {
            return $args;
        }

        if ( empty( $args['body']['plugins'] ) ) {
            return $args;
        }

        $payload = json_decode( $args['body']['plugins'], true );
        if ( ! is_array( $payload ) || empty( $payload['plugins'] ) ) {
            return $args;
        }

        unset( $payload['plugins'][ MIPLUGIN_PLUGIN_BASENAME ] );

        // El basename viaja dos veces: como clave en `plugins` y otra vez en
        // `active`. Quitar solo la primera deja el nombre a la vista.
        if ( ! empty( $payload['active'] ) && is_array( $payload['active'] ) ) {
            $payload['active'] = array_values(
                array_diff( $payload['active'], array( MIPLUGIN_PLUGIN_BASENAME ) )
            );
        }

        // Una lista vacía tiene que seguir siendo objeto o json_encode la deja en `[]`.
        $payload['plugins'] = (object) $payload['plugins'];

        $args['body']['plugins'] = wp_json_encode( $payload );

        return $args;
    }

Lo enganchas con add_filter( 'http_request_args', array( $this, 'unlist' ), 10, 2 ); y listo. Fíjate en que el método sale por la puerta ante la mínima duda y devuelve $args sin tocar: estás metiendo mano en una petición que usa todo el sitio, así que aquí toca ser cobarde.

Y hay una segunda razón para hacerlo, menos evidente y bastante más interesante que la privacidad. Vuelve a mirar la línea del core que decide si te preguntan a ti: if ( ! $plugin_data['UpdateURI'] || isset( $updates->response[ $plugin_file ] ) ) { continue; }. Tu filtro solo se llama si wordpress.org se ha callado. Si el directorio contestara alguna vez por la carpeta de tu plugin, a ti ni te preguntan y tu cliente se instala encima el plugin de otro.

Antes de que te dé un vuelco: eso es justo lo que evita la cabecera, y más arriba lo tienes comprobado con la prueba del Akismet falso. Y hay una segunda red debajo, porque el equipo de revisión de plugins lleva años moderando los slugs de plugins comerciales conocidos. Pero las dos protecciones viven en el servidor de wordpress.org, no en tu código. Quitarte de la petición cierra el asunto por tu lado sin depender de la palabra de nadie. Es un cinturón encima de unos tirantes que funcionan.

Ojo con hacerlo a medias, que es lo que se ve por ahí. El core construye ese cuerpo con compact( 'plugins', 'active' ), así que el nombre de tu plugin viaja dos veces, una como clave dentro de plugins y otra como valor dentro de la lista active. Casi todas las implementaciones que he visto quitan solo la primera y dejan el nombre a la vista en la segunda.

Tres cosas más sobre esto. No pierdes absolutamente nada, porque wordpress.org no te iba a contestar de todas formas. Plugin Check no te lo marca, que he leído las expresiones que busca y http_request_args no está entre ellas. Y apúntatelo en la lista de cosas que hay que quitar el día que publiques en el directorio oficial, junto con la cabecera y la constante, porque si te lo dejas puesto wordpress.org no sabrá nunca que tienes el plugin instalado y no te llegará jamás una actualización de allí.

Lo que este sistema no hace

Y ahora la parte que suele faltar en los artículos de este tipo, que es donde te cuento lo que no vas a tener.

• No hay licencias. Cualquiera con la URL del JSON se baja el zip. Como te decía, el código es GPL y eso no lo cambia ninguna ofuscación, pero si quieres una validación de verdad, el JSON deja de ser un fichero estático y pasa a ser un script en PHP que comprueba la clave antes de responder. Cuando lo montes, hazlo bien, y si la clave no vale devuelve el JSON sin package. Así el cliente ve que hay versión nueva y que su licencia no le da derecho a bajarla, en vez de no enterarse de nada.
• Tu plugin desactivado no se actualiza jamás. El filtro lo engancha tu propio plugin, y un plugin desactivado no carga. El cliente que lo desactive un día y se olvide se queda congelado sin ningún aviso. Esto sí lo resuelve un plugin cliente siempre activo como el de Troy, todo hay que decirlo.
• No tienes estadísticas de uso. Y aquí es donde me van a decir que es una carencia grave, y no lo veo. Un plugin gratuito del directorio necesita el contador de instalaciones activas porque es su única métrica. Un plugin de pago ya tiene la métrica que importa, y está en el listado de pedidos de la tienda. Saber cuántas webs consultan tu JSON no te dice nada que no te diga mejor lo que has vendido. Si algún día quieres el dato aproximado, el log de accesos de tu servidor te lo da gratis.
• No hay marcha atrás desde la interfaz. El core solo ofrece la actualización si la versión es mayor, así que si una versión sale mal, volver a la anterior significa instalar el zip viejo a mano. Por eso los zips antiguos no se borran, y por eso vale la pena tener localizado el de la última versión que iba bien antes de publicar nada.

Y ponle renovación automática al dominio. De ese JSON sale la URL de un zip que se instala con permisos de escritura en las webs de tus clientes, así que no es un dominio cualquiera ni es sitio para experimentos.

¿Merece la pena preparar este sistema de actualizaciones?

Si vendes un plugin, o dos, o cinco, y lo que quieres es que tus clientes reciban las actualizaciones igual que las de cualquier plugin del directorio, esto te lo resuelve en una tarde y no depende de nada que no controles tú. Un fichero de texto y un zip se mudan de servidor en diez minutos y no hay que mantenerlos al día con cada versión de WordPress.

Si necesitas licencias de verdad, canal beta, dependencias entre plugins y estadísticas anónimas, no te montes todo eso a mano, que ahí Troy o un servicio comercial te van a salir mucho más baratos en horas.

Yo estoy en el primer grupo, y lo único que echo de menos es no tener que subir el zip y editar el JSON a mano en cada versión. Eso lo voy a resolver con una herramienta mía de publicación, que vivirá en mi lado y no en el de nadie más. Pero ahora mismo esto funciona con el gestor de archivos del hosting y punto.

¿No hay algo menos manual?

Estoy en ello, ya tiene hasta nombre, y lo tengo en uso, pero de momento solo para mis cosas, aún no me atrevo a liberarlo, soy muy exagerado con estas cosas, pero todo se andará. Sí te anticipo que contempla la gestión de licencias, entre otras cosas.

Pues nada, ya estaría por ahora.

Si te has montado algo parecido, o si has resuelto lo de las licencias de una forma que no se me haya ocurrido, me tienes ahí abajo en los comentarios, que de estas cosas se aprende más leyendo lo que hace el de al lado que leyendo la documentación.

Si alguien consigue tocar los archivos de tu plugin de seguridad te quedas sin nada, lo que tienes instalado ya no es un guardia, es un segurata sobornado que sigue con la gorra puesta y te sigue diciendo que todo está en orden, pero trabajando en la sombra para tus enemigos.

Con la versión 3.0.0 del plugin Vigilante esa pregunta ya tiene respuesta, pues el plugin comprueba sus propios archivos, te cuenta qué ha encontrado y qué significa, y te ofrece arreglarlo con un botón.

Es todo igual un poco técnico, pero por lo raro, por lo novedoso, y ¡qué coño! porque me he pegado una currada del catorce y creo que es algo bueno, ni te digo siendo un plugin de seguridad totalmente gratis, pues que te animo a leer esta apasionante aventura…

La idea viene de lejos

Esto no se me ocurrió ayer, la autoprotección está apuntada en la hoja de ruta de Vigilante desde las pruebas de la versión 2.4.0, en mayo de 2026,

El razonamiento de entonces sigue siendo el de ahora, que un plugin de seguridad manipulado es peor que no tener ninguno, porque no solo deja de protegerte, es que además te tranquiliza.

Piénsalo desde el lado del que ataca, Si alguien consigue escribir en tu servidor (una contraseña de FTP que se filtró, un plugin vulnerable, un hosting comprometido) y quiere quedarse a vivir lo primero que le interesa es que nadie se entere.

La forma más cómoda de que nadie se entere es dejar a ciegas al que vigila, tocando dos líneas del plugin de seguridad para que no mire donde no debe o para que no avise.

Si revisas el historial de cualquier plugin de seguridad, desde el más pequeño al más grande verás que suelen ser fuente de posibles vulnerabilidades, que alguien puede aprovechar, y sí, por si lo has pensado, también Vigilante ha tenido vulnerabilidades puntuales (pero como me conoces las arreglé la misma tarde)

Dicho esto, ya te aclaro un concepto importante, y es que la autoprotección no significa que el plugin sea impenetrable, no tiene nada que ver, la autoprotección es una capa de vigilancia adicional, no una vacuna contra cualquier posible intento de ataque.

Vamos al grano, que te cuento ya cómo se autoprotege Vigilante…

Las 3 capas de autoprotección de Vigilante

Para saber si sus archivos son los buenos, Vigilante no se fía de una sola fuente, se apoya en tres, y las compara entre sí.

Es como comprobar un contrato con tres copias, la que guarda el notario, la que va grapada al propio contrato y la foto que le hiciste con el móvil el día que lo firmaste.

• Los checksums de WordPress.org: la huella SHA-256 (una especie de huella dactilar de cada archivo, cambias una coma y cambia la huella entera) que WordPress.org publica para cada archivo de la versión que tienes instalada. Es la referencia que está fuera de tu servidor, y por eso la que más vale.
• El archivo MANIFEST.sha256: va dentro del propio plugin con la huella de cada archivo que se distribuye (63 en esta versión). Sirve para comprobar sin conexión, desde la línea de comandos y en las primeras horas de cada versión, cuando WordPress.org todavía no ha publicado sus checksums.
• Una huella del manifiesto, guardada en tu base de datos: Vigilante la toma la primera vez que ve el manifiesto y solo la renueva cuando el actualizador de WordPress instala una versión nueva o cuando WordPress.org confirma esa versión. Ni siquiera la vuelve a tomar si desactivas y reactivas el plugin.

¿Y para qué tres, si con la de WordPress.org ya valdría? Pues porque cada una tapa el agujero de las otras.

Quien quiera esconder un cambio regenerando el manifiesto se choca con la huella guardada, quien borre la huella se choca con WordPress.org, y el manifiesto cubre las horas en las que WordPress.org aún no tiene nada publicado.

Para engañar a las tres a la vez, un atacante tendría que controlar tu servidor, tu base de datos y WordPress.org, y si alguien controla WordPress.org tenemos todos un problema bastante más gordo que este.

Cuándo se hacen las comprobaciones y por qué se hacen ahí

Una comprobación que se lanza cuando le apetece no sirve de mucho, así que se ejecuta en los momentos en los que de verdad puede pasar algo:

• Al empezar cada exploración de integridad de archivos, manual o programado, antes que cualquier otra cosa. Queda fuera del límite de tiempo del escaneo y no respeta tus exclusiones, porque excluir la carpeta del plugin por error no debería dejarlo a ciegas.
• Justo después de que WordPress actualice Vigilante, en esa misma petición, también si lo actualizas subiendo el zip a mano. Es el momento en el que aparecería un archivo a medio copiar o uno cambiado por el camino.
• Cuando la versión cambia por la puerta de atrás (una subida por FTP, el gestor de archivos del hosting, un despliegue o una versión anterior), en la siguiente pantalla de administración que abra un administrador o en la tarea de mantenimiento diaria.
• Una vez al día como mínimo, si nada de lo anterior ha comprobado nada en las últimas 24 horas. Aunque tengas apagado el módulo de integridad de archivos o las exploraciones programadas, porque una comprobación que depende de un ajuste que se puede apagar no es protección, es un adorno.

Además también vigila sus propias tareas programadas, que es otra forma muy discreta de dejar sin vigilancia un WordPress. Te lo cuento luego.

¿Qué detecta la autoprotección de Vigilante?

Aquí está lo gordo de esto, de lo que me siento más orgulloso, y lo que más me apetecía contarte, porque me ha llevado meses de darle vueltas y cientos de horas de pruebas.

Cada posible caso lleva su nivel gravedad, qué significa (el propio plugin te lo explica con estas mismas palabras en pantalla) y qué te ofrece para arreglarlo. No hay ningún hallazgo que te deje con el susto y sin saber qué hacer.

Si algo modifica sus archivos

• Un archivo de código modificado (crítico): un PHP, un JavaScript o un archivo de datos que el plugin carga ya no coincide con el que publica WordPress.org. Algo con permiso de escritura en tu servidor lo ha cambiado, sea un atacante, un script o una edición a mano. Te ofrece repararlo.
• Una hoja de estilos o una imagen modificadas (aviso): casi siempre es un plugin de optimización o de caché, o tu propio hosting, que la reescribe al minificar o combinar archivos. Por eso es aviso y no alarma. Te dice que excluyas la carpeta wp-content/plugins/vigilante del optimizador y que después repares.
• Un archivo borrado (crítico): un módulo que falta deja de protegerte sin mostrar ningún error, que es justo lo peligroso. Te ofrece reponerlo reparando.
• Un archivo que no se puede leer (crítico): si no lo puede leer no lo puede comprobar, y los archivos que distribuye WordPress.org siempre se pueden leer. Reparar lo devuelve con permisos normales, y si falla te dice que se lo pidas a tu hosting.

Y lo que no te va a marcar importa tanto como lo anterior. Si tu servidor cambia los saltos de línea de un archivo de texto (cosas de servidores Windows y de algunas herramientas de sincronización), eso no es una manipulación y no sale. Un aviso que salta sin motivo acaba ignorado, y un aviso ignorado es peor que no tenerlo.

Si aparecen cosas que no son del plugin

• Un ejecutable añadido (crítico): un PHP, o cualquier archivo que el servidor web pueda ejecutar se llame como se llame (un foto.php.jpg también cuenta, y un .htaccess o un .user.ini también), que está en la carpeta del plugin y no es del plugin. Esconder archivos dentro de un plugin de seguridad es una forma habitual de dejar una puerta trasera. Ojo al consejo que da el propio plugin, que es de los que se agradecen: si quieres saber cómo llegó ahí, pide al hosting la fecha de creación del fichero antes de reparar, porque reparar lo borra y con él la pista.
• Un archivo extra que no es código (aviso): muchas veces es un error_log que escribe tu servidor, o restos de una copia de seguridad o de una sincronización. Si es un registro de errores, te sugiere abrirlo y, si los errores mencionan a Vigilant, contarlo en el foro de soporte.
• Un enlace simbólico (crítico): un archivo del plugin que en realidad es un acceso directo a otro sitio, o que apunta fuera de la carpeta. WordPress.org nunca distribuye enlaces, así que alguien lo ha puesto ahí.
• Una carpeta que no se puede revisar (crítico): no puede listar una de sus carpetas, o encuentra muchísimos más archivos de los que distribuye. Un servidor web puede ejecutar un archivo escondido en una carpeta que no se puede listar si alguien sabe su nombre, así que no se da por buena.

Si algo cambia la lista de referencia, el manifiesto

• Manifiesto sustituido, borrado o dañado sin actualizar (crítico): cambiar esa lista es justo lo que haría alguien para esconder cambios en el plugin. Aquí es donde la huella guardada en tu base de datos se gana el sueldo.
• Manifiesto que falta o no es válido: sigue comprobando contra WordPress.org, pero ha perdido una de sus tres referencias. Reparar lo restaura.
• Distinto de la copia de WordPress.org: los archivos cuadran con el manifiesto que trae el propio plugin, pero no con lo que WordPress.org distribuye para esa versión. En una copia de desarrollo es lo esperable, pero en una web en producción significa que el plugin entero, manifiesto incluido, ha salido de otro sitio. Es crítico si afecta a archivos que se pueden ejecutar y aviso en el resto.

Si cambia la versión por la puerta de atrás

• Una versión anterior instalada (aviso, con correo): alguien ha sustituido Vigilant por una versión más vieja, y las versiones viejas pueden tener fallos ya corregidos y públicos. Si no lo has hecho tú a propósito, reparar instala la versión que distribuye WordPress.org en ese momento.
• Una versión nueva que todavía no se puede confirmar (aviso, con correo): la versión ha cambiado sin pasar por el actualizador de WordPress y WordPress.org aún no ha publicado sus checksums. Si la has subido tú a mano con una copia de WordPress.org no tienes que hacer nada, porque se confirma sola en cuanto se publican (normalmente en un día). Si no has sido tú, o la copia no venía de WordPress.org, repara.

Si alguien/algo borra las tareas programadas

Vigilant funciona con cinco tareas programadas propias (el mantenimiento diario, las comprobaciones de cada hora, el análisis semanal de Security Check, la comprobación de plugins cerrados en WordPress.org y el escaneo programado de integridad). Si alguien las borra, el plugin sigue instalado, sigue activo y no hace nada, que es otra forma de dejarlo a oscuras sin tocar un solo archivo.

• Una tarea repuesta (queda en el registro): una de ellas había desaparecido y Vigilant la ha vuelto a programar. Un plugin de limpieza del cron (las tareas programadas de WordPress), restaurar una copia de la base de datos o una migración pueden provocarlo. Si no vuelve a pasar, no hay nada que hacer.
• Tareas que desaparecen una y otra vez (crítico, con correo): la misma tarea borrada de nuevo en menos de 30 días. Mientras no están no hay escaneos programados, ni comprobación diaria, ni avisos. Te sugiere buscar el plugin de limpieza que lo hace y excluir las tareas que empiezan por vigilante_ (un plugin como WP Crontrol te las enseña), y si no encuentras la causa, tratarlo como una posible intrusión y revisar los plugins instalados hace poco y las cuentas de administrador.

Las tareas que hayas apagado tú (el análisis semanal, por ejemplo) se respetan, faltaría más. Y en una red multisitio este vigilante de tareas cubre el sitio principal.

Si algo intenta apagar el plugin o que silenciarlo

Esta es la parte que más me gusta, porque es donde un atacante listo iría primero.

• Apagada por código (crítico, con correo una vez al día): no hay ninguna casilla para apagar la autoprotección (luego te cuento por qué). Lo único que la apaga es un filtro en el código, y cuando alguien lo usa Vigilant te dice en todas las pantallas qué archivos lo enganchan, con nombre y ruta. Si no lo has pedido tú, trátalo como una intrusión, porque un plugin o un fragmento de código que apaga la comprobación de un plugin de seguridad está haciendo lo primero que necesita un atacante.
• Alguien le ha quitado los enganches (crítico): código que desengancha las comprobaciones que corren tras cada actualización y en cada pantalla de administración, para que el plugin siga enseñando su último resultado como si fuera de hoy. WordPress no avisa cuando alguien quita una función de un gancho, así que aquí no se puede nombrar el archivo culpable, pero en el registro queda la lista de plugins cargados en esa petición, que es la lista corta de sospechosos. Te propone desactivarlos uno a uno hasta que deje de pasar.
• Sin comprobar desde hace más de tres días (aviso): lo que ves ya no es un resultado actual. Pasa en webs que no abre nadie y sin cron funcionando, y pasa también cuando algo ha parado la comprobación sin que se note. La pantalla nunca te enseña un verde viejo como si fuera de hoy.
• No ha podido comprobar nada: sin manifiesto y sin conexión con WordPress.org no tiene contra qué comparar. Te manda a «Herramientas > Salud del sitio» para ver si tu servidor llega a WordPress.org, y a pedírselo al hosting si no llega.

Más información que registra aunque no sea crítica

• Verificado: sus archivos cuadran con las tres referencias. Es lo normal y lo que tienes que ver casi siempre.
• Verificado con dos de tres referencias: cuadran con el manifiesto y con la huella, pero WordPress.org aún no ha publicado sus checksums, cosa normal durante unas horas tras cada versión. Si dura más de dos días, revisa que tu servidor llegue a WordPress.org.
• Comprobado justo después de actualizar: WordPress lo actualizó y se revisó en esa misma petición.
• Integridad restaurada: lo que se había reportado vuelve a coincidir con lo que distribuye WordPress.org, así que queda cerrado.
• Referencia guardada: ha guardado la huella de su manifiesto en tu base de datos, que es lo que permite detectar después un manifiesto cambiado.
• Todavía sin comprobar: recién instalado. Lanza un escaneo y listo.

¿Y yo en qué lo noto?

Si todo va bien, en casi nada, y eso es lo mejor de todo, no es un problema, todo lo contrario. Lo que notas es que el día que pase algo te enteras tú, no el que ha entrado.

Hasta ahora si alguien tocaba los archivos de tu plugin de seguridad, el plugin seguía diciendo que todo iba bien. Con Vigilante, desde la 3.0.0, eso sale en rojo y no hay que ir a buscarlo.

Esto es lo que ves, y dónde:

• Una caja propia, la primera de los resultados de la exploración de integridad de archivos: con un color por estado y una fila plegable por cada caso, con los archivos afectados, qué significa y qué hacer, la primera abierta y el resto cerradas. Si todo va bien, se queda en una línea discreta con la fecha de la última comprobación.
• Un aviso que no se puede descartar: si es crítico, en todas las pantallas del escritorio de WordPress (entradas, páginas, lo que sea), y si es un aviso, solo en las de Vigilante. En los dos casos solo lo ven los administradores, que tu editora no tiene por qué llevarse el susto.
• Un contador rojo o naranja en el menú de Vigilante y en el de la herramienta de exploración de la integridad de archivos, como el de las actualizaciones pendientes.
• Una ficha en el escritorio de Vigilante con el estado y un enlace directo a la caja correspondiente.
• Las dos notas de Vigilante bajan a E (la de configuración y la de la comprobación de seguridad) con el motivo escrito. Todo lo demás que te enseña el plugin lo calcula ese mismo código, y si ese código está tocado el plugin no puede fingir que el resto de sus resultados son de fiar. Además la comprobación de autoprotección pasa a ser la de más peso de la categoría interna de la comprobación de seguridad.
• Una entrada en en la auditoría de seguridad que, al abrir su detalle, te dice qué ha pasado con los archivos, qué significa y qué hacer, sin perder los datos de siempre.
• Un correo propio con las alertas: luego te cuento sus reglas, que tienen su intención.

Y también hay cosas que ya no ves, como por ejemplo que en los hallazgos de los archivos de Vigilante no hay botón de ignorar, ni para el administrador ni para el superadministrador de una red, porque eso no se silencia, se arregla.

Tampoco salen mezclados con los archivos sospechosos del escaneo normal, y el «todo correcto» de la exploración no aparece mientras la autoprotección esté en rojo o en ámbar.

El correo de aviso

La autoprotección tiene su propio aviso por correo, y no hay ningún ajuste que lo apague. No va dentro del correo de los resultados de la exploración de integridad de archivos ni dentro de las alertas de la auditoría de seguridad.

Esto es así porque el resto de alertas se pueden desactivar en los ajustes, y si así fuera apagar «avísame de los archivos cambiados» estaría apagando también la alarma del propio plugin, y eso no tenía ningún sentido.

• Siempre manda correo con un hallazgo crítico, lo detecte donde lo detecte (un escaneo, la comprobación tras actualizar, un cambio de versión, el vigilante de tareas, la comprobación apagada por código o los enganches quitados).
• Avisos de versiones: una versión anterior instalada y un cambio de versión que no se puede confirmar.
• El resto de avisos se quedan en pantalla. Mandar un correo en cada exploración porque un optimizador reescribe una hoja de estilos es la forma más rápida de que nadie lea los correos.
• Una vez por cada conjunto de hallazgos: si pasa lo mismo, no te escribe otra vez, y si cambia lo que encuentra, sí.
• En una red multisitio sale una sola vez, desde el sitio principal, y llega también al correo de administración de la red.
• Sin recordatorios: Esto lo decidí a propósito, porque si no haces caso al primer correo no vas a hacer caso al quinto, y mientras el problema siga ahí la pantalla te lo sigue diciendo en cada visita.

Auto-reparaciones a un clic

Dar información sin solución es media herramienta, así que cuando Vigilante encuentra sus archivos han cambiado te ofrece un botón de reparación.

Primero te pregunta, en una pantalla que dice exactamente qué versión va a descargar y qué va a cambiar, y después hace lo mismo que hace el actualizador de WordPress con cualquier plugin, que es descargar el paquete de WordPress.org y sustituir la carpeta.

• Solo cambian los archivos: los ajustes, las tablas de la base de datos y el registro se quedan como estaban, porque no se desinstala nada ni se desactiva el plugin.
• Lo que no sea de Vigilante también se elimina: así es como desaparece un archivo inyectado.
• Instala la versión que distribuye WordPress.org en ese momento, nunca la que dicen los archivos del disco y nunca una anterior a la que tu web ya había verificado. ¿Que por qué no se fía de la versión que pone el plugin? Pues porque quien puede cambiar los archivos puede escribir también esa versión, y un reparador que se fiara de ella acabaría siendo una bajada a una versión con fallos públicos.
• La dirección del paquete la construye el propio plugin con un servidor fijo y una versión que tiene que cumplir un formato estricto. Nada de lo que llega en la petición se usa para eso.
• Comprueba otra vez al terminar, contra WordPress.org y contra el manifiesto, y te enseña el resultado.

En tres casos no te ofrece el botón y te da los pasos a mano, distintos en cada uno.

Cuando la carpeta del plugin tiene otro nombre (el paquete siempre se instala como vigilante y dejarías una copia limpia al lado de la que funciona), cuando tu instalación tiene prohibido modificar archivos con DISALLOW_FILE_MODS, y cuando eres administrador de un subsitio en una red, donde eso le toca al superadmin.

Y hay algo que no te promete, y es que si quien cambió los archivos cambió también el código que los repara, ese botón es tan de fiar como el resto de la copia. La comprobación que no depende de tu servidor sigue siendo la que se hace desde fuera, y te explico cómo más abajo.

No hay interruptor, para «esos» casos

A ver, entiendo el argumento contrario, y tiene su parte de razón. Hay webs que no pueden conectarse con WordPress.org por política de su empresa, hay copias de desarrollo en las que no te apetece ver avisos, y a nadie le gusta un plugin que no le deja apagar sus cosas.

Ahora bien, piensa quién sería el usuario más fiel de una casilla que dijera «no compruebes tus propios archivos». Pues el que acaba de tocarlos.

Una autoprotección que se apaga con una casilla es una alarma de casa con el botón de apagado en la puerta de fuera. Esa casilla existió mientras desarrollaba esta versión, y la quité antes de publicarla.

Para el caso que te comentaba, el de la web que de verdad no puede hablar con WordPress.org, queda un filtro en el código, documentado en el SECURITY.md del plugin:

add_filter( 'vigilante_self_integrity_enabled', '__return_false' );

Y con él puesto Vigilante lo avisa como crítico en todas las pantallas, nombra los archivos que enganchan el filtro y lo apunta en el registro. Apagarlo se puede, apagarlo a escondidas no.

Lo mismo con el código que quita los ganchos y con la comprobación que deja de ejecutarse, que ya te conté más arriba. Nada de esto impide que un código que corre dentro de WordPress anule al plugin (eso no lo puede impedir nadie), pero sí impide que la pantalla diga «verificado» mientras pasa.

Lo que no hace la autoprotección de Vigilante

Si solo te cuento lo bueno esto sería propaganda, y ya imaginas que para el precio que cobro por el plugin (cero euros) no me da para publi.

De qué no te protege la autoprotección:

• Detecta manipulación, no fallos de programación: Si el código publicado de Vigilante tuviera un fallo, que son cosas que pasan porque nadie es perfecto, ni siquiera yo, esta comprobación no lo vería, porque los archivos serían exactamente los publicados. Eso se cubre de otra forma, con la auditoría de cada versión que te cuento al final.
• Quien puede escribir en tu base de datos puede sustituir la huella guardada, como con cualquier plugin de seguridad. Lo que ya no puede es apagar la comprobación, porque no hay ningún ajuste que la apague.
• Quien puede escribir en la carpeta del plugin puede editar también el código que comprueba. La única referencia fuera de su alcance son los checksums de WordPress.org, y por eso la comprobación de verdad es la que se hace desde fuera.
• Las primeras horas de cada versión sale con dos de tres referencias, hasta que WordPress.org publica sus checksums.
• El readme.txt y el changelog.txt no están en el manifiesto, porque WordPress.org permite actualizar el readme de una versión publicada sin sacar otra. Los checksums de WordPress.org sí los incluyen.
• En multisitio cada sitio guarda su resultado, pero el correo sale solo del sitio principal y el vigilante de tareas cubre ese sitio.
• Si despliegas con Git, Composer o una herramienta de sincronización, reparar desde WordPress.org se deshace con el siguiente commit, así que el arreglo va en tu despliegue.
• No revisa tus otros plugins ni tu tema: Eso es trabajo de la escaneo de integridad de archivos que ya tienes de siempre, no de la autoprotección.

Cómo comprobarlo por tu cuenta

Maneras con las que puedes poner a prueba la autoprotección de Vigilante:

1. En el propio WordPress: la pestaña de integridad de archivos y la comprobación «Autoprotección de Vigilante» de la auditoría de seguridad.
2. Contra el manifiesto que viaja con el plugin, desde la carpeta wp-content/plugins/vigilante: sha256sum -c --strict MANIFEST.sha256 en Linux o shasum -a 256 -c --strict MANIFEST.sha256 en macOS. Ojo, que esto no ve un archivo añadido a la carpeta.
3. Contra WordPress.org, con WP-CLI: wp plugin verify-checksums vigilante.
4. El manifiesto contra WordPress.org: php wp-content/plugins/vigilante/bin/verify-manifest.php --wporg, que además avisa de cualquier archivo añadido y devuelve un código de salida distinto para cada problema.
5. Desde fuera del servidor, que es la que de verdad vale, descargando el plugin de WordPress.org, o haz un svn export del tag de la versión, y compáralo tú.

Y te recuerdo que un servidor comprometido puede mentir sobre sus propios archivos, y lo que hay fuera de él no, por eso las 3 capas, no es infalible pero lo intenta.

Cómo se comprueba cada versión de Vigilante

Antes de publicar cualquier versión de Vigilante, el plugin pasa por un conjunto fijo de comprobaciones, y sus cifras quedan escritas en la entrada de esa versión en el changelog.txt.

Entre esas cifras están tienes todo esto:

• Prueba del escapado de JavaScript
• Inventario de cada punto de entrada con su comprobación de permisos
• Un detector de accciones peligrosas en PHP y en JavaScript
• Revisión completa de Plugin Check
• Una comprobación de coherencia de versiones y notas
• Pruebas de regresión permanentes en un sitio normal y en una red multisitio, incluida la prueba de cada vulnerabilidad ya publicada, para que no vuelva a colarse.

Para esta versión en concreto, la lógica de autoprotección pasó por diez rondas de revisión a ciegas, hechas por sesiones que no habían escrito el cambio (las seis últimas sin nada de gravedad alta ni media), y la parte que se ve en pantalla, con la reparación, por dos rondas más que encontraron un fallo de gravedad media cada una, arreglado y con su prueba.

Además, introduje a propósito 71 fallos en copias del código (una comprobación que se salta, una condición al revés, un aviso que deja de enviarse) para comprobar que las pruebas los cazan, y las pruebas los cazaron todos menos uno, que está documentado como equivalente porque no cambia nada que se pueda observar.

Y luego, el MANIFEST.sha256 se genera el último de todo, cuando lo demás está cerrado.

Por supuesto, nada de esto sustituye a que lo compruebes tú, es simplemente para que sepas todo lo que hay detrás de las cifras del registro de cambios, para quien quiera mirarlas, y por si tenías curiosidad por si me tomo esto en serio o no.

¿Tengo que hacer algo?

No, lo de siempre:

1. Actualiza a la 3.0.0 como cualquier otra versión, si no lo has hecho ya. La primera comprobación se hace sola.
2. Si usas un plugin de optimización que minimiza o combina archivos, excluye la carpeta wp-content/plugins/vigilante, que así te ahorras avisos de hojas de estilos reescritas.
3. Si tienes un plugin de limpieza del cron, excluye las tareas que empiezan por vigilante_.
4. Echa un vistazo a la pestaña de integridad de archivos. Lo normal es que diga «verificado», y si lo actualizas en las primeras horas, con dos de tres referencias hasta que WordPress.org publique sus checksums.

A partir de ahí, si encuentras un problema de seguridad en Vigilante, escribe a security@ayudawp.com y tendrás respuesta en menos de 72 horas.

El detalle completo de todo lo que te he contado, incluido lo que no cubre, está en el archivo SECURITY.md que viaja con el plugin, y Vigilante lo tienes en el directorio oficial de plugins de WordPress.org, gratis y sin versión de pago.

Si quieres profundizar en la seguridad de WordPress tienes decenas de artículos en el blog, y para lo demás, incluso para debatir si una autoprotección debería poder apagarse, me tienes ahí abajo, en la sección de comentarios.

Y ojalá no tengas que ver nunca esa caja en rojo.

Si quieres ver además cómo monté esta autoprotección aquí te dejo un vídeo que he publicado en el canal de YouTube de Ayuda WordPress donde lo explico:

Crónicas WordPress: revisiones con IA, WordPress 7.1.1 al caer y el culebrón de Automattic

Seguridad: la IA ya te revisa los plugins (y yo fui el conejillo de indias)

Lo más gordo en seguridad es que WordPress.org ha activado un sistema de revisión automática con IA y Jetpack Scan que analiza cada plugin que subes. Y ojo, porque no revisa solo cuando lo subes por primera vez, también en cada actualización.

Lo anunció David Pérez esta semana, aunque funciona desde el 5 de junio. Busca patrones de código peligroso (salidas sin escapar, falta de comprobaciones nonce, inyecciones SQL y demás), te calcula una puntuación de riesgo y, si te pasas, te bloquea la actualización y te manda un correo para que lo arregles.

Y aquí te hablo con conocimiento de causa, porque fui conejillo de indias sin comerlo ni beberlo. Justo cuando arrancó todo subí unas actualizaciones de Vigilante y me llovieron los avisos. Falsos positivos había, y alguna posible vulnerabilidad cogida con pinzas también, que un administrador abriendo una ventana de popup dispare una alarma es hilar muy fino.

El equipo de plugins, majísimos y rapidísimos atendiéndome, todo hay que decirlo. Pero me tiré un fin de semana a base de actualización tras actualización solo para contestar al automatismo, y cada respuesta me devolvía el mismo falso positivo más tres cosas nuevas.

Que quede claro, la idea me parece estupenda. Llevo años avisando de que hay muchas comprobaciones al subir un plugin y bastantes menos en las actualizaciones, que es justo por donde se cuelan los problemas, así que esto viene a tapar ese agujero. Lo único que pido es que metan estas mismas comprobaciones en el Plugin Check, la herramienta oficial que muchos pasamos antes de subir nada, para no llevarnos la sorpresa de que una te diga que está todo bien y otra, en paralelo, que está mal.

En vulnerabilidades de la semana, Wordfence detectó una inyección SQL sin autenticar en rtMedia, un plugin de galerías con miles de sitios expuestos. De estas salen todos los días, es lo normal, y en mi propio Vigilante me detectaron una que arreglé esa misma tarde. También hubo un fallo de autorización en un complemento de PixelYourSite para Easy Digital Downloads. Estos plugins que te inyectan píxeles y scripts de terceros son de los que yo prohíbo a mis clientes sin pestañear, porque te saltan capas de seguridad de tu propio WordPress.

Y te conté el caso de un «beg bounty», que no es lo mismo que un bug bounty. El bug bounty es el programa serio de recompensas por encontrar fallos, el que tienen Wordfence, Patchstack y compañía. El beg bounty es el primo pesado, alguien que te escribe directamente, sin programa que valga, para «avisarte» de una supuesta vulnerabilidad inflada y, al terminar el mensaje, pedirte una recompensa. Me llegó uno y lo desmenucé en el blog para que sepas distinguir un aviso de verdad de un sablazo con corbata.

Comunidad y desarrollo: WordPress 7.1.1 y un WooCommerce que se queda corto

En comunidad ya se ha anunciado el equipo que va a llevar WordPress 7.2, con Mullenweg otra vez como líder de versión (que da para un rato, y lo dejo para el final). Habrá tema nuevo por defecto, previsto para 2027, aunque cada vez le veo menos sentido a los temas por defecto.

Pero antes que la 7.2 llega la 7.1.1, que ya está en versión candidata y sale esta misma semana. Corrige un montón de fallos, y uno me toca de cerca porque lo reporté yo: el mapa del sitio nativo de WordPress devolvía un 404 en webs sin entradas de blog, algo que pillé con mi plugin Visibility, que gestiona justo eso. Mi ticket ya está asignado a esta versión, así que queda arreglado.

En WooCommerce 11.1 hay dos cosas. Una buena, que por fin han consolidado la galería de imágenes por variación, para que al elegir una variación te cambie la galería, algo la mar de práctico. Y una a medias, porque han metido el derecho de desistimiento electrónico pero se queda muy corto, no cubre ni de lejos lo que exige la normativa europea y ellos mismos reconocen que no garantiza el cumplimiento. No entiendo para qué se meten en ese jardín cuando ya hay plugins que lo cubren, como el mío, que es 100% gratis y lo tienes en el repositorio.

Y en mi terreno he actualizado uno de mis plugins más veteranos. El antiguo No Gutenberg pasa a llamarse Sí Gutenberg (versión 2.2.0), y no es un capricho de nombre, es un cambio de enfoque. Antes desactivaba Gutenberg del todo y ahora te deja elegir. Puedes quitar el editor de bloques solo en las entradas y dejarlo en las páginas, decidirlo por tipo de contenido o por nivel de usuario, restaurar la pantalla de widgets clásicos y alguna cosa más. Porque yo nunca he odiado el editor de bloques, por mucho que se diga. Lo que siempre he defendido es que los bloques tienen sentido como maquetador para las páginas, no como editor para las entradas de blog, que no necesitan tanto artificio.

IA y SEO: spam con IA, el cero clics y qué plugin de SEO pesa menos

Enrique Dans avisaba del spam de comentarios hecho con IA, que ya se está saltando a Akismet. Hay bots que cogen contenido y lo pasan por un modelo de lenguaje para generar comentarios que cuelan en un montón de sitios, se habla de cientos de miles de dominios atacados. A mí el volumen me da igual, lo que preocupa es la calidad, que esquiva los filtros de siempre. Y mi antispam favorito sigue siendo el que ya trae WordPress de serie, marcar en los ajustes de comentarios que cada uno se apruebe a mano. No hay otro mejor, y encima te ahorras el plugin.

En SEO, un estudio sobre 19 millones de consultas en inglés dice que el bloque de «la gente también pregunta» de Google ya lo responde la IA casi en su totalidad, un 97% la primera semana de septiembre frente al 86% de agosto. O sea, cero clics como norma, la IA te contesta ahí mismo y no queda enlace que rascar.

Y cerré con una comparativa mía bastante a lo bruto sobre qué plugin de SEO pesa menos y consume menos recursos. Te resumo lo que salió: SEO Framework es el más ligero en varias cosas, hay que ser justos; Rank Math me ha decepcionado y ahora mismo es una bestia parda en consumo; Yoast, en cambio, se ha puesto las pilas y ha aligerado bastante. Mi Visibility no mete tablas propias en la base de datos, tira de las nativas y luego limpia, y llega a hacer menos consultas que WordPress a pelo. Tienes el análisis completo, con el CSV para que lo compruebes sin trampa ni cartón.

El culebrón: apartan a Mullenweg de Automattic (y a los tres días, de vuelta)

Y llegamos al culebrón de la semana, del mes y casi del año. El consejo de administración de Automattic apartó a Matt Mullenweg como CEO y nombró en su lugar, como interino, a su director financiero, Mark Davis. Tres días después, Mullenweg anunciaba por Slack que había recuperado el control, y la cuenta del CEO interino se desactivó por arte de birlibirloque. Él apunta a que detrás de la maniobra estaría Silver Lake, el fondo que está tras WP Engine, aunque eso es una acusación suya que no ha confirmado nadie.

Lo bueno, y esto es importante, es que todo esto afecta a Automattic, la empresa, no a WordPress.org, el proyecto. De hecho, en paralelo se nombró a Mary Hubbard directora ejecutiva del proyecto WordPress, que es como debería ser. La empresa por un lado y el proyecto por otro.

¿Mi opinión, que a nadie le importa pero te la doy? Que Mullenweg no debería ser CEO, pero eso tendría que decidirlo él, dejar la empresa en otras manos y dedicarse al proyecto WordPress, hacer un Linus Torvalds. Y sobre todo, que las cosas no se hacen así, tengas o no tengas razón. Ya avisé de que esto duraría poco, como pasó con Steve Jobs o con Sam Altman en OpenAI, que al final acaban volviendo. Matt, tómate unas vacaciones de verdad, que te apreciamos, pero deja las peleas con WP Engine en casa.

Tienes las Crónicas WordPress completas aquí: Seguridad, WordPress 7.1.1, WooCommerce y el culebrón de Automattic – #CrónicasWordPress.

Doctor WordPress: qué son los llms.txt y para qué sirven (si es que sirven)

En el Doctor de esta semana me metí con una pregunta que me hacéis mucho, qué son los famosos archivos llms.txt y llms-full.txt, esos que ves por ahí y que yo llevo tiempo sirviendo en mis plugins.

Qué son y quién se los inventó

Un llms.txt es, ni más ni menos, un archivo de texto en formato Markdown que le dice a los agentes de IA cuál es el contenido de tu web y cómo está estructurado. La idea la propuso Jeremy Howard, va ya por la versión 2 (de agosto de 2026) y funciona como una especie de índice limpio de tu sitio pensado para que los modelos de lenguaje se lo lean rápido. El llms.txt es el listado, y el llms-full.txt va más allá y sirve el contenido completo de cada página, o un extracto, según lo configures.

¿Que por qué en Markdown? Pues porque es el formato que mejor leen estos modelos, muy limpio y ligero (y, por cierto, WordPress también entiende Markdown, tanto en el editor de bloques como en el clásico).

¿Sirve de algo? ¿Lo lee alguien?

Google dice que no los tiene en cuenta, que para eso está el robots.txt y el mapa del sitio. Y es verdad que el llms.txt no sustituye a ninguno de los dos, cada cosa va a lo suyo y siguen conviviendo. Pero la adopción no para de crecer, Wix genera uno para cada sitio y cada vez más plugins lo incorporan.

Te cuento lo que veo yo con datos reales, midiendo Ayuda WordPress con mi plugin Vigía. A día de hoy, la página que más visitan los bots de IA cuando descubren tu web sigue siendo el mapa del sitio, y a partir de ahí se lo leen todo, sistemáticos, página por página (más que indexar, almacenan, como bibliotecarios que lo guardan todo sin priorizar hasta que alguien pregunta). Pero últimamente ya los veo buscar y leerse el llms.txt, y si encuentran el llms-full, también. Como pesa menos y se lee más rápido que un mapa del sitio, apostaría a que esa tendencia va a más.

Cómo lo montas en WordPress sin instalar un plugin solo para esto

Aquí va mi consejo principal, el que quiero que te lleves. No instales un plugin específico solo para generar el llms.txt. Es un puñetero archivo de texto, hay cientos de plugins que hacen solo eso y no merece la pena. Lo suyo es que lo genere el plugin de SEO que ya tengas, porque muchos ya lo hacen (y alguno, como All in One SEO, te lo guardaba para la versión premium, que ya me contarás en qué cabeza cabe cobrar por un fichero de texto).

En el directo lo enseñé con mis dos plugins, los dos gratis del todo. Vigía es de analítica y control de visibilidad ante las IA, y te genera el llms.txt, te gestiona el robots.txt, te bloquea rastreadores y te da estadísticas de qué bots de IA visitan tu web y cuánto. Y Visibility es un plugin de SEO completo y gratuito. Cuando tienes los dos, se coordinan solos para no duplicarte los archivos, que Vigía se aparta y deja que Visibility lleve la voz cantante, y así no acabas con dos llms.txt peleándose.

Y quédate con esto. Si quieres un llms.txt, tira del plugin de SEO que ya uses, y si es Visibility mejor, que es gratis del todo, en vez de instalar uno específico para la tontería. Y si no lo quieres, tampoco pasa nada, que nadie te obliga. No es un estándar oficial, pero es una propuesta que se adopta cada vez más, así que no la pierdas de vista.

Tienes el Doctor WordPress completo aquí: Qué son los archivos llms.txt y llms-full.txt y cómo crearlos en WordPress – #DoctorWordPress.

Nos vemos en el próximo directo

Y hasta aquí la semana. Ya lo sabes, los lunes toca Crónicas WordPress y los miércoles, Doctor WordPress, a las 19:30 (hora peninsular) en el canal de Ayuda WordPress. Si tienes cualquier duda de lo que he contado, o me quieres corregir en algo, te leo ahí abajo en los comentarios.

Llevo años diciendo que las herramientas de auditoría SEO gratuitas que hay por ahí sirven para bien poco, pero ¿esta sirve de algo?, pues aunque no lo sepas ya estás disfrutando de ella ¿no te lo crees?, lee… que hay una historia detrás…

El cliente que echó a su empresa de SEO…

Esto empezó en una reunión de mentoría con un cliente del servicio de mantenimiento. Las hacemos con todos al entrar, y luego siempre que hagan falta, porque una de las cosas que más nos agradecen los clientes es justo esa. que no solo mantenemos webs, también echamos una mano para que la web funcione mejor, y eso incluye seguridad, rendimiento y SEO, sin coste añadido salvo tareas muy especiales.

En esa primera reunión le pasé el informe inicial que hacemos siempre, y ahí, entre las cosas a mejorar, se veía a la legua que la empresa de SEO que tenía contratada le hacía entre poco y nada. Nosotros no somos una empresa de SEO, es verdad, pero los básicos de descubrimiento e indexación los miramos igual, y ayudamos a mejorarlos, y esos básicos cantaban por sí solos, para mal. El cliente lo vio y me pidió un informe más a fondo.

No me dedico al SEO, no hago ese servicio como tal, pero llevo más de 20 años trabajando en Internet, he contratado a unos cuantos SEO para mis propias empresas, he leído una montaña de informes ajenos, he analizado un montón de webs y he hecho mucho SEO de contenidos durante años. Y creo que algo de idea tengo al respecto, de hecho llevo viviendo de ello bastante tiempo, y eso se parece a un currículum ¿no?.

Así que me puse, analicé su web al completo y le preparé un informe en profundidad. Al día siguiente echó a su empresa de SEO y me pidió que le lleváramos nosotros el servicio.

Que conste que hay empresas de SEO buenísimas y no va de eso la cosa, sino de que su empresa llevaba meses pagando sin que nadie le enseñara un informe que se sirviese de algo, ni compromiso alguno, ni trabajos que significasen algo medible, y en cuanto vio cosas que se podían hacer, explicadas, y un plan de acción, tuvo claro lo que estaba pasando.

Por supuesto, le entregué el informe para que hiciese con él lo que quisiera, incluso ofrecerlo sin restricciones a la empresa de SEO, pero parece ser que llevar meses pagando por nada le abrió un poco los ojos, y bueno, estamos en ello, ayudándole a corregir errores de años y a mejorar el descubrimiento e indexación de su web (tienda online en realidad).

Luego, como soy como soy, se me quedó la idea dando vueltas y me dije «…si un informe bien hecho vale para eso, ¿por qué no puede tenerlo cualquiera?…». Pues eso he montado y te presento hoy.

La parte que se puede automatizar, online y a voluntad para todo el mundo, y luego, la parte que exige criterio, valoración razonada, a veces incluso datos internos de la web, esa si quieres te la hago yo, también gratis y sin compromiso ninguno. La pides y encantado de la vida.

Auditoría SEO y GEO exprés: 43 comprobaciones gratis en un minuto

Metes la dirección de tu web y esperas. No hay registro, no hay correo, no hay «déjanos tu email para ver el resultado». Sale el informe y ya está, lo puedes descargar en PDF, imprimirlo, o compartirlo en tus redes sociales, mandártelo por email (con URL única y privada personalizada).

Está aquí: herramientas.ayudawp.com/auditoria-seo/

Lo que hace en un minuto o menos:

• Se lee tu robots.txt entero y te dice si hay grupos duplicados, erratas o bloqueos que se pisan con el noindex.
• Rastrea el índice de sitemaps y hasta 3.000 URLs, y te cuenta qué hay dentro, cuánto está sin fecha de modificación y cuántas direcciones no tienen ningún valor de búsqueda.
• Abre diez páginas de verdad, repartidas entre los tipos de contenido que publicas, con el agente de Googlebot, y mide lo que se encuentra el rastreador de verdad y no lo que se encuentra en la portada cacheada.
• Valida los datos estructurados de esas páginas, mira las cabeceras del servidor, comprueba las señales para agentes de IA y cronometra la respuesta.

Son 43 comprobaciones con veredicto, cada una con su explicación de qué se juega tu negocio en ella, qué hacer para arreglarla y, cuando toca, con qué plugin.

Lo que no hace la auditoría exprés

Todas las herramientas gratuitas de este tipo tienen el mismo problema, y es que te dejan con la duda. Sale una nota de 78 sobre 100 y tú te quedas mirando la pantalla pensando «vale, ¿y el 22 que falta?». Nunca te dicen si el 22 es porque tu web tiene fallos o porque la herramienta no ha mirado ahí.

Aquí no, al final de cada bloque tienes la lista de lo que esa herramienta no mira, con nombre, apellidos y por qué le importa a tu negocio.

Son 55 comprobaciones que se llaman por su nombre y se declaran fuera. Cosas como el censo de directivas de indexación de todas las URLs, el árbol completo de categorías con sus conflictos padre-hija, o el cruce con la cobertura real de tu Search Console.

No es un truco de venta, es que me niego a que la herramienta prometa cosas que no hace. Si mira diez páginas, dice que mira diez páginas, si necesita tu Search Console para responder algo, lo dice en esa misma tarjeta.

Auditoría SEO y GEO a fondo: 100 comprobaciones, también gratis

Aquí es donde la cosa se pone interesante. Debajo de cada bloque del informe exprés hay un botón para pedir la auditoría completa, y el formulario ya lleva dentro lo que se ha encontrado, así que no tienes que explicarme nada.

La a fondo son 98 comprobaciones en lugar de 43, la hago yo con las herramientas internas que usamos para nuestros clientes, y sale un informe en PDF de treinta y tantas páginas con resumen ejecutivo, hallazgos ordenados por lo que más rinde al arreglarse y anexos con las direcciones concretas.

Seguro que aquí ya me pides pasta o algo ¿no?

¡Que nooo, que ya te he dicho que ambas auditorías son gratis!

Pero ocho de esas 98 comprobaciones no se pueden hacer desde fuera ni queriendo, porque son datos que solo tienes tú:

• Informe exportado de tu Search Console, que es lo único que dice qué URLs están descubiertas sin indexar y por qué motivo exacto.
• Exportación de redirecciones del plugin Redirection, o de lo que uses para gestionar redirecciones, para repasar las cadenas y los bucles que se van acumulando solos.
• Exportación de la configuración de tu plugin SEO, sea Yoast, Rank Math, AIOSEO o SEOPress, que es donde suele estar el interruptor que lo explica todo o casi.

Si no me los das, no pasa nada, el informe sale igual y esas ocho aparecen diciendo que no se han podido comprobar. Lo que no voy a hacer nunca es rellenar un hueco con una suposición y presentártelo como un hallazgo ¿vale?.

¿Y si lo quiero arreglar yo por mi cuenta?

Claro, pues lo arreglas y ya está, que para eso cada comprobación del informe te dice qué hacer. Y donde hace falta un plugin la herramienta te recomienda los mejores, y solo te lo recomienda cuando esa comprobación te ha salido mal. Si esa parte de tu web está bien no te aparece ningún plugin, ni te lo menciono, ni te doy la brasa, solo información.

Los plugins que vas a ver que recomiendo según lo que necesites son cuatro, los cuatro desarrollados por mi, los cuatro gratis y los cuatro en el repositorio oficial de WordPress.org sin versión premium, completos:

• Visibility, para casi todo lo de descubrimiento e indexación: el sitemap nativo, el robots.txt virtual, las etiquetas Open Graph y los datos estructurados tipo por tipo de contenido, todo desde un mismo sitio.
• VigIA, para la parte de IA: te genera el llms.txt, lo mantiene al día y te enseña qué bots están pasando de verdad por tu web y qué se llevan.
• DietPress, para cuando lo que sale en rojo es el tiempo de respuesta, el peso del HTML o los cuarenta ficheros que carga la portada.
• AI Content Signals, para declarar en el robots.txt si tu contenido se puede usar para entrenar modelos, para buscar o para responder.

Y si lo que te preocupa es la parte de IA, el bloque correspondiente de la auditoría enlaza a nuestro analizador de visibilidad IA, que también es gratis y va más a fondo en eso concreto. De ahí sale la quinta recomendación, Share Buttons & AI-powered Summaries, que te pone botones para compartir tu contenido en redes y también en las IAs.

Lo segundo suena raro hasta que caes en que cada vez que alguien le pasa tu artículo a ChatGPT o a Claude estás metiendo tu web en una conversación donde antes no estabas, y de ahí salen menciones.

Y por supuesto, buena parte de lo que salga en el informe lo resuelve también el plugin SEO que ya tengas puesto, sea Yoast, Rank Math, AIOSEO o SEOPress. Si ya tienes uno mira ahí primero antes de instalar nada. Sumar plugins por sumar no arregla nada, y lo he dicho unas cuantas veces por aquí, y sí, los míos son mejores, y gratis del todo, pero vamos, que lo bueno es que hay para elegir.

En serio, ¿ por qué es gratis?

Me dedico, entre otras cosas, al mantenimiento de webs WordPress y a resolverle problemas de seguridad, rendimiento y posicionamiento a quien los tiene, que para eso está servicios.ayudawp.com.

La auditoría es lo que hago igualmente cuando entra un cliente nuevo, así que hacértela sin cobrar me cuesta un rato de trabajo y me sirve para dos cosas:

• Que puedas ver cómo trabajamos por si algún día te animas a colaborar con nosotros.
• Para que, si quieres, nos encarguemos de ejecutar el plan, y sepas exactamente qué estás delegando.

Pero eso es una posibilidad, no te comprometes a nada, como te he dicho es totalmente gratis. Si te llevas el informe y lo arreglas todo tú, me parece perfecto y no te voy a perseguir con correos.

Por otro lado, si el informe no te convence, tampoco vas a contratar, así que el filtro funciona en las dos direcciones. De paso te llevas un montón de información valiosa de tu web, y no has soltado ni un euro, .

Qué cosas tiene la vida, y es que por si no lo sabías„ esta herramienta ya te ha ayudado antes incluso de conocerla

Mientras montaba la herramienta de informes de auditoría se me quedó una comprobación en rojo en mis propios subdominios, diciendo que el mapa del sitio respondía con un 404. Y yo mirándolo en el navegador, viendo el XML perfecto, pensando que la herramienta estaba mal.

Pues no estaba mal. Resulta que WordPress sirve el sitemap nativo con código 404 cuando el sitio no tiene ninguna entrada publicada, porque pinta el XML sin fijar su propio estado y hereda el de la consulta principal. En el navegador se ve perfecto y en Search Console figura como no leído, así que a efectos de descubrimiento es como no tener sitemap.

Está reportado en el Trac de WordPress con el ticket #65945, y te lo cuento con detalle en por qué tu wp-sitemap.xml devuelve un 404 y cómo arreglarlo. No sé si la solución estará en WordPress 7.1.1 o en la 7.2, pero está en camino y arreglará un problemón de SEO que tenía WordPress y que la auditoría detectó, sin pretenderlo.

Eso es exactamente el tipo de cosa que no ves mirando tu web, que ninguna herramienta de semáforos te va a decir, y que te está costando indexación desde hace meses. Pues mira tú por donde, una auditoría SEO gratuita lo ha detectado, y es algo de lo que se van a beneficiar todos los usuarios de WordPress, antes incluso de estar disponible la herramienta.

¿Tiene algún límite la auditoría SEO exprés?

Alguno, básicamente para que no me tiren abajo el servidor y poco más, te lo resumo:

• Se pueden analizar cinco dominios distintos al día desde la misma conexión. Es para que nadie use esto de rastreador gratuito, y si necesitas más, pídeme la a fondo y listo.
• El informe exprés se guarda seis meses con un enlace propio, así que lo puedes compartir con quien lleve tu web sin que caduque a los dos días, pero tampoco lo guardes para «un año de estos», pues además ya no servirá de nada.
• La muestra que realiza la auditoría exprés son diez páginas, no es el sitio entero y en ningún momento te digo que lo sea, pero te sorprenderá lo que vas a aprender de ello.

Que recuerde nada más, eso es lo único. Bueno, y que son 43 comprobaciones, si quieres muchas más pide la auditoría a fondo, también gratis.

¿Por dónde empiezo para auditar gratis el SEO de mi web?

Pues lo que yo haría, en este orden:

1. 1. Pasar la exprés a tu web y leerte el bloque que sale abierto, que es el que tiene el problema más gordo.
   2. Arreglar por tu cuenta lo que puedas, que si hace falta plugin te dice cuál y son todos gratis.
   3. Bajar hasta el final de cada bloque y mirar la lista de lo que no se ha comprobado, porque ahí suele estar lo que llevas tiempo sin revisar.
   4. Si algo de eso te preocupa pedir la a fondo desde el mismo informe. Tardo lo que tarde, dependiendo de la demanda, pero llega.

Y si la pasas y te sale algo que no entiendes, o que crees que está mal medido, me tienes ahí abajo en los comentarios. La herramienta lleva semanas cambiando precisamente porque la he ido probando contra webs reales y me he ido encontrando fallos míos por el camino, así que cualquier cosa rara que veas me interesa de verdad, que cuantos más análisis mejor para ir mejorando los informes.

Tú prueba, que no cuesta nada, de verdad.

En esta guía he tratado de explicar de manera ordenada y sencilla qué hace cada ajuste importante, qué cambia según lo que elijas y dónde está el fallo cuando los precios no salen como esperabas.

Todo lo que tienes en este artículo es configuración de WooCommerce tal cual viene de serie, sin plugins adicionales. Y lo siento, no soy asesor fiscal, esto explica cómo funciona el software, pero no qué tienes que cobrar ni cuándo, así que para las dudas fiscales habla con tu gestoría.

El grueso del artículo cubre lo que necesita cualquier tienda española que venda a consumidor final dentro de España. Luego, al final, hay un bloque de casos especiales (recargo de equivalencia, retenciones de autónomos, Canarias, ventas a la Unión Europea, productos digitales) que solo tienes que leer si te afecta.

Activa los impuestos ¿a que se te había olvidado?

Si acabas de instalar WooCommerce puede que ni siquiera veas la pestaña de impuestos, y no es que se haya perdido. Está desactivada por defecto.

Vete a «WooCommerce > Ajustes > General», busca la sección de impuestos y marca la casilla «Activar tasas de impuestos y sus cálculos». En cuanto guardes te aparece una pestaña nueva llamada «Impuesto» arriba, junto al resto.

Parecerá una bobada pero es la duda que más se repite en los foros de soporte y se resuelve en dos clics. ¿Ya?, pues empezamos.

Precios con impuestos incluidos o sin ellos, la decisión que más cuesta deshacer

El primer ajuste de la pestaña de impuestos es también el que más te va a condicionar, porque afecta a cómo introduces todos los precios de todos tus productos.

Tienes dos opciones, o introduces los precios con los impuestos ya incluidos, y WooCommerce calcula hacia atrás cuánto de ese precio es base y cuánto impuesto, o introduces los precios sin impuestos y WooCommerce los suma luego.

Con números se ve mejor, lo vemos. Imagina un producto que quieres que le cueste al cliente 9,99 € con el IVA general del 21 % incluido.

• Si eliges precios con impuestos incluidos, escribes 9,99 € en la ficha del producto y WooCommerce descompone ese importe en 8,26 € de base imponible y 1,73 € de IVA.
• Si eliges precios sin impuestos, escribes 8,26 € en la ficha del producto y WooCommerce le suma el 21 % hasta llegar a esos mismos 9,99 €.

El resultado final es el mismo, pero el número que tú tecleas es distinto, y ahí es donde te puedes liar tú, y liar a tus clientes como te líes ¿vaya lío, no?

Si cambias esta opción cuando ya tienes el catálogo cargado, todos tus precios cambian de golpe y en la dirección contraria a la que esperas, porque los 9,99 € que habías metido pensando que llevaban IVA pasan a ser una base a la que ahora se le suma un 21 % encima, y el producto se le queda al cliente en 12,09 €.

Para una tienda que vende a consumidor final en España lo habitual es trabajar con precios con impuestos incluidos, porque es lo que el cliente espera ver y porque la ley de consumo obliga a mostrar el precio final. Si vendes a profesionales y tu catálogo va sin IVA, la otra opción tiene más sentido.

Y luego está la comodidad, la otra derivada, porque si te decides por poner en tus productos los precios con impuestos incluidos y un día el gobierno te cambia el IVA (por ejemplo) te toca modificar todos los precios uno a uno, variaciones incluidas, mientras que si elegiste crearlos con el precio antes de impuestos solo tendrías que cambiar el impuesto en los ajustes de impuestos. Valóralo también ¿vale?

Ya te dije que esto es un poco lioso, así que dale una pensada antes de decidirte, pero sobre todo haz pruebas siempre tras cualquier cambio, y hazlas como cliente, y completas.

En base a qué ubicación se calculan los impuestos

Este es el punto donde se atasca prácticamente todo el mundo, yo incluido, que lo tengo que pensar siempre un par de veces, y es que el síntoma es siempre el mismo, impuestos que no salen, o salen mal o cambian de repente.

La causa está repartida entre dos pantallas distintas que además no están ni siquiera cerca. Intuitivo ¿eh?

Las tres opciones de cálculo

En la pestaña de ajustes de impuestos (Impuesto) tienes un desplegable con tres posibilidades:

• Dirección de envío del cliente: es la opción por defecto y aplica el impuesto que corresponda al sitio adonde va el paquete.
• Dirección de facturación del cliente: aplica el impuesto del sitio que el cliente haya puesto como dirección de facturación, aunque el envío vaya a otro lado.
• Dirección base de la tienda: aplica siempre tu impuesto, el de donde tú estás, el de la dirección a la que configuraste tu tienda, sin mirar dónde está el cliente.

Las dos primeras solo funcionan bien cuando el cliente ha rellenado ese dato, con lo cual no hacen ningún cálculo mientras el visitante está mirando la tienda sin haber puesto todavía una dirección. Y ahí es donde entra la segunda pantalla de la que te hablaba antes.

Qué pasa con los impuestos antes de que el cliente diga dónde vive, y la madre que los parió a todos los que diseñan los ajustes de WooCommerce que, por supuesto, no tienen que vivir con ello

El desplegable anterior decide qué dirección usar una vez que WooCommerce la conoce, pero mientras el visitante simplemente está curioseando productos WooCommerce no tiene ni idea de dónde está, ni por supuesto qué impuestos mostrar, así que necesita partir de alguna suposición.

Esa suposición se configura en un sitio completamente distinto, en «WooCommerce > Ajustes > General > Ubicación del cliente por defecto», y es la causa real de la mayoría de los problemas de impuestos que la gente atribuye al ajuste anterior.

Las opciones que tienes ahí y qué provoca cada una:

• Sin ubicación por defecto: WooCommerce no supone nada, así que hasta que el visitante no dé una dirección es fácil que no se muestre ningún impuesto en la ficha de producto. Este es el famoso «no me sale el IVA en la tienda».
• País/región de la tienda: da por hecho que el visitante está donde estás tú hasta que diga lo contrario. Es la que menos sorpresas da si vendes sobre todo en España.
• Geolocalizar: detecta el país del visitante por su IP desde el primer momento. Ojo con esta si tienes caché de página, porque si el servidor está sirviendo la misma página guardada a todo el mundo, la detección puede no reflejarse.
• Geolocalizar (compatible con caché de página): hace lo mismo pero resolviendo la detección por otra vía para que la caché no se la coma. Es la que hay que usar si quieres geolocalizar y tienes caché, que en un hosting decente la tienes seguro.

Con esto ya puedes explicarte el síntoma más desesperante de todos, que en la ficha de producto veas un precio y al llegar al carrito o al finalizar la compra te salga otro distinto. Pasa cuando la ubicación que WooCommerce estaba suponiendo no coincide con la dirección real que el cliente acaba metiendo, y entonces recalcula.

Para la mayoría de tiendas españolas la pareja de ajustes que menos incidencias da es dejar la ubicación por defecto en País/región de la tienda y el cálculo en Dirección de envío del cliente. Con esta configuración el visitante ve desde el primer momento un precio con el IVA español, y si resulta que compra desde otro sitio, se recalcula al meter la dirección.

Clases de impuesto, una etiqueta para agrupar productos

WooCommerce trae tres clases de impuesto de fábrica, que son Estándar, Tasa reducida y Tasa cero. Cada clase tiene su propia tabla de tasas independiente, y cada producto se asigna a una de ellas desde su ficha, en la pestaña general de los datos del producto.

Puedes añadir las clases que necesites escribiéndolas en el campo correspondiente de la pantalla de opciones, una por línea. En cuanto guardes te aparecen como subpestañas nuevas en la parte de arriba, junto a las que ya había, y cada una con su tabla vacía esperando a que le metas tasas.

Para una tienda española normal no necesitas crear ninguna clase adicional, porque los tres tipos de IVA que existen encajan directamente en las tres que ya vienen. El general va en Estándar, el reducido en Tasa reducida y el superreducido lo puedes meter en Tasa cero renombrándola mentalmente, o crear una clase nueva llamada Superreducido si prefieres tenerlo claro al mirar la ficha de un producto.

La tabla de tasas de impuestos, columna por columna

Aquí es donde se define de verdad qué se cobra. Entras en cualquiera de las clases, pulsas en insertar fila y rellenas las columnas.

Las columnas de siempre

• Código de país: dos letras en mayúsculas, ES para España. Un asterisco significa todos los países.
• Código de provincia: igual, con asterisco para todas. Si solo vendes en península y Baleares, con el asterisco lo tienes resuelto.
• Código postal: admite varios separados por punto y coma, comodines con asterisco al final (07* coge todos los que empiecen por 07) y rangos numéricos con tres puntos (07000...07999). Lo que no puedes es mezclar las dos técnicas, porque un comodín dentro de un rango numérico no funciona.
• Ciudad: lista separada por punto y coma y coincidencia exacta, o sea que si el cliente escribe el nombre de otra manera no coincide. Poco fiable, mejor usar códigos postales.
• Tasa %: el número, con punto decimal si lleva decimales. Para el 21 % se escribe 21.0000.
• Nombre del impuesto: el texto que verá el cliente si tienes activado el desglose. Aquí pon IVA, o lo que toque.

¿Qué es eso de la prioridad?

La prioridad es un número que le pones a cada fila, y la forma más fácil de entenderla es pensar en turnos.

WooCommerce va por turnos empezando por el número más bajo. En cada turno mira todas las filas que llevan ese número, se queda con la primera que encaje con la venta, la cobra y pasa al turno siguiente. Cuando ya no quedan filas, se acabó.

De ahí salen las dos únicas cosas que tienes que recordar:

• Dos filas con el mismo número: compiten entre ellas y solo se cobra una.
• Dos filas con números distintos: se cobran las dos, una detrás de otra.

Y ahora los dos casos reales donde esto te va a pasar de verdad.

Cuando quieres que solo se aplique una, que es lo normal. Imagina que tienes una fila para todo el país con el IVA del 21 % y otra para Las Palmas al 0 %, porque a Canarias no le repercutes IVA. Un cliente de Las Palmas encaja con las dos, así que las dos tienen que llevar la misma prioridad, el 1. Así solo hay un turno, se cobra una sola fila y en paz.

Si por despiste le pusieras a la fila de Canarias la prioridad 2, pasaría esto: en el turno 1 se le cobra el 21 % de la fila general y en el turno 2 se le cobra el 0 % de la fila canaria, que no suma nada. Resultado, el cliente de Las Palmas paga el 21 % de IVA que precisamente querías ahorrarle, porque una fila al 0 % no anula a la anterior, simplemente no suma nada.

Cuando quieres que se apliquen las dos, que es el caso del recargo de equivalencia. Aquí es justo al revés, porque necesitas cobrar el IVA y encima el recargo. La fila del IVA al 21 % va con prioridad 1 y la del recargo al 5,2 % con prioridad 2. Sobre una base de 100 € se cobran 21 € en el primer turno y 5,20 € en el segundo, así que el cliente paga 126,20 €.

Si les pusieras a las dos la prioridad 1 competirían entre ellas, se cobraría solo la primera y te faltarían esos 5,20 € en cada pedido.

Y si tu tienda no está en ninguno de esos dos casos, o sea si solo cobras IVA español y punto, pon un 1 en todas las filas y olvídate del asunto.

¿Compuesto? Ojo con esta casilla, que cambia precios sin avisar

Esta casilla decide una sola cosa, si ese impuesto se calcula sobre el precio del producto o sobre el precio del producto con el impuesto anterior ya sumado encima. Dicho a lo bruto, marcarla es cobrar impuesto del impuesto.

Se ve clarísimo otra vez con el recargo de equivalencia, que es el único caso español en el que vas a tener dos filas conviviendo. Partimos de una base de 100 €, IVA del 21 % y recargo del 5,2 %:

• Sin compuesto, que es lo correcto: el recargo se calcula sobre los 100 € de base, o sea 5,20 €. El cliente paga 126,20 €.
• Con compuesto, que es el error: el recargo se calcula sobre 121 €, o sea 6,29 €. El cliente paga 127,29 €.

Un euro y pico de diferencia en un pedido de 100 €, que en uno de 1.000 € se convierte en casi 11 € que le estás cobrando de más a tu cliente sin que ni él ni tú os hayáis enterado. En España esta casilla se queda sin marcar, porque tanto el IVA como el recargo se calculan sobre la misma base.

La casilla de envío

Decide si esa tasa se cobra también sobre los gastos de envío, además de sobre los productos. Con un ejemplo se ve en un segundo, pedido de 100 € con 5 € de gastos de envío e IVA del 21 %:

• Casilla marcada: el 21 % se calcula sobre 105 €, o sea 22,05 € de IVA. El cliente paga 127,05 €.
• Casilla sin marcar: el 21 % se calcula solo sobre los 100 € de los productos, o sea 21 €, y el envío se va limpio. El cliente paga 126 €.

Lo normal es tenerla marcada en tus filas de IVA, porque el transporte también lleva IVA. Se deja sin marcar en casos concretos, como la fila del recargo de equivalencia, que grava el producto y no el porte.

Y aunque parezca una casilla inofensiva tiene más mala leche de la que aparenta, porque se coordina con otro ajuste que está en otra parte de la pantalla y ahí es donde se puede liar parda. Te lo cuento un poco más abajo, en su propia sección.

Los tipos de IVA que hay que dar de alta

Actualmente los tipos de IVA que hay en España son estos:

• General, 21 %: todo lo que no esté expresamente en las dos listas siguientes. Si no sabes qué tipo aplicarle a algo, casi seguro que es este.
• Reducido, 10 %: alimentación en general, hostelería, transporte de viajeros y vivienda, entre otros.
• Superreducido, 4 %: pan común, leche, huevos, frutas y verduras naturales, aceite de oliva (que se quedó aquí de forma permanente desde el 1 de enero de 2025), libros, periódicos y medicamentos de uso humano.

Hay una cuarta situación que no es un tipo sino una exención, y conviene no confundirla. La enseñanza reglada, la sanidad o algunos servicios financieros no llevan IVA porque están exentos, que no es lo mismo que estar al 0 %, y tiene consecuencias en el derecho a deducir de quien presta el servicio. Si vendes algo de esto, consúltalo con tu asesoría antes de meterlo en la tabla.

Los listados de productos por tipo se retocan de vez en cuando, así que si vendes algo que no tengas clarísimo, échale un vistazo a la web de la Agencia Tributaria antes de dar por buena una tasa.

Importar, exportar y borrar tasas

Al pie de cada tabla de tasas de impuestos tienes botones para importar y exportar en CSV, muy útiles si mantienes un entorno de pruebas y otro de producción, o si gestionas varias tiendas parecidas.

El CSV lleva diez columnas en este orden: país, estado, código postal, ciudad, tasa, nombre del impuesto, prioridad, compuesto, envío y clase de impuesto. En vez de construirlo a mano, crea una fila cualquiera desde la interfaz y exporta, así tienes la plantilla exacta y solo tienes que rellenarla.

Para borrar, seleccionas las filas que quieras (con mayúsculas o con la tecla de comando para elegir varias) y pulsas en eliminar. Si lo que quieres es empezar de cero, en WooCommerce > Estado > Herramientas tienes una herramienta para eliminar todas las tasas de impuesto de golpe. Eso sí, esa acción no se puede deshacer, así que úsala solo si vas a rehacer la configuración entera.

Los precios que ve el cliente y el aviso que sale cuando algo no cuadra

Un poco más abajo en la misma pantalla de ajustes de los impuestos hay dos desplegables que deciden qué ve el cliente, y son independientes entre sí.

• Mostrar los precios en la tienda: con impuestos incluidos o sin ellos.
• Mostrar los precios en el carrito y al finalizar la compra: lo mismo, pero puede ser distinto del anterior.

Que sean independientes tiene sentido en algunos casos, por ejemplo en una tienda para profesionales que muestra el catálogo sin IVA pero luego desglosa en el carrito. Lo que no tiene sentido es que no cuadren sin querer.

Cuando la combinación de estos dos desplegables con el ajuste de precios con impuestos incluidos no es coherente, WooCommerce te muestra un aviso en la propia pantalla advirtiendo de que esa mezcla puede provocar descuadres de céntimos por redondeo, con un botón para igualar los tres de golpe.

Si te sale ese aviso hazle caso, porque lo que viene después son clientes preguntándote por qué el total no les sale.

El impuesto de los gastos de envío, con sus casos especiales

Los gastos de envío también llevan impuesto, y decidir cuál es más enrevesado de lo que parece porque intervienen dos cosas a la vez.

El desplegable de clase de impuesto de envío

En la misma pantalla de opciones tienes un desplegable para la clase de impuesto que se aplica al envío, con estas posibilidades:

• Basado en los artículos del carrito: es la opción por defecto y hereda la clase de los productos que lleve el pedido.
• Estándar, Tasa reducida, Tasa cero o cualquier clase que hayas creado: fuerza siempre esa, pase lo que pase.

¿Y qué pasa cuando el carrito mezcla productos de clases distintas?

Aquí está la regla que hay que saberse de memoria, porque no es intuitiva que se diga. Si dejas la opción por defecto y el pedido lleva productos de varias clases, manda la clase Estándar en cuanto haya al menos un producto que la use, sea o no el tipo más alto de los que lleva el carrito. Y si no hay ningún producto en Estándar se usa la primera clase adicional que aparezca en tu lista de clases.

Un ejemplo de los que pasan todos los días. Un pedido con un libro al 4 % y una camiseta al 21 %, más 5 € de gastos de envío. Como la camiseta está en la clase Estándar, el envío tributa al 21 %, así que el cliente paga 5 € más 1,05 € de IVA por el transporte, y no los 0,20 € que saldrían si se aplicara el tipo del libro.

De esa regla sale un truco útil, y es que si necesitas que el envío tribute siempre a una clase adicional concreta cuando no haya productos estándar de por medio, esa clase tiene que ir la primera de la lista, porque es la que WooCommerce coge en ese caso.

La casilla de envío de cada tasa

Y ahora la parte que descoloca, y es que el hecho de elegir una clase en ese desplegable no basta, porque quien decide de verdad si se cobra impuesto por el envío es la casilla de envío de cada fila de la tabla de tasas.

El error típico es cuando seleccionas Tasa reducida en el desplegable pensando que así el envío irá al 10 %, pero resulta que la fila del 10 % en la tabla no tiene marcada la casilla de envío. El resultado no es que el envío vaya al 10 %, es que el envío no lleva impuesto ninguno. Las dos cosas tienen que ir coordinadas o el resultado te dará disgustos.

Para el caso normal deja el desplegable en la opción por defecto basada en los artículos del carrito y asegúrate de que la fila del IVA general tiene marcada la casilla de envío. Con eso cubres casi todas las combinaciones sin sustos.

Redondeo: cuándo es importante y cuándo da igual

Hay una casilla para redondear el impuesto a nivel de subtotal en vez de hacerlo línea a línea. Por defecto viene desmarcada, así que WooCommerce redondea el impuesto de cada línea de producto por separado y luego suma.

La diferencia solo se nota en pedidos con muchas líneas y tasas con decimales, donde cada redondeo por línea puede arrastrar medio céntimo arriba o abajo y al sumarlos todos aparece un descuadre de uno o dos céntimos frente a calcular el impuesto una sola vez sobre el total ya sumado.

Con tres artículos no vas a notar nada, pero con un pedido mayorista de cuarenta líneas puede que sí, y entonces marcar esta casilla te ahorra la conversación de los céntimos con el cliente y con la asesoría. Si tu asesoría te pide que los importes cuadren al céntimo con su programa, prueba a marcarla, porque muchos programas de contabilidad calculan sobre el subtotal.

El sufijo de precio, para enseñar los dos importes a la vez

Es un campo de texto libre que se pinta detrás del precio en toda la tienda, y acepta dos comodines que WooCommerce sustituye por el importe correspondiente.

• {price_including_tax}: el precio con impuestos.
• {price_excluding_tax}: el precio sin impuestos.

Con esto puedes montar cosas como IVA incluido a secas, o algo más completo tipo {price_excluding_tax} + IVA si tu tienda muestra precios finales pero quieres que se vea la base. La utilidad más habitual es al revés, en tiendas para profesionales que enseñan precios sin IVA y necesitan dejar claro cuál es el importe final.

Un detalle que despista, en los productos variables el sufijo no aparece hasta que el cliente elige una variación, porque hasta ese momento WooCommerce no sabe qué precio tiene que calcular.

El total de impuestos: ¿único o detallado?

El último ajuste de la pantalla decide cómo se ve el impuesto en el carrito y al finalizar la compra.

• Como un total único: una sola línea que pone «Impuestos» y suma todo lo que haya.
• Detallado: una línea por cada tasa, con el nombre que le hayas puesto en la columna correspondiente de la tabla.

Qué conviene poner

Si toda tu tienda va con un único tipo de IVA, el total único queda más limpio y es perfectamente correcto. En cuanto puedes tener dos tipos en el mismo pedido, o dos impuestos a la vez como pasa con el recargo de equivalencia, el desglosado te ahorra problemas porque el cliente ve en pantalla lo mismo que se va a encontrar luego en la factura.

¿Qué es lo obligatorio por ley?

Aquí conviene no mezclar dos cosas distintas. Este ajuste afecta a la pantalla de compra, que es experiencia de usuario, y no a la factura, que es otra historia.

La obligación de verdad está en el Reglamento de facturación, el Real Decreto 1619/2012, cuyo artículo 6 exige que la factura indique el tipo aplicado y la cuota por separado, y que cuando una misma factura tenga operaciones a distintos tipos de IVA se desglose también la base imponible que corresponde a cada uno.

Eso afecta al documento de factura, que WooCommerce por sí solo no genera, así que activar el desglose en el carrito no equivale a cumplir con Hacienda. Es una buena práctica de transparencia y evita que la pantalla de compra y la factura se contradigan, pero la factura la tendrás que emitir con tu programa de facturación o con un plugin dedicado.

Por qué a veces los ajustes de WooCommerce salen en gris, inactivos

Si abres la pantalla y la ves distinta a lo que te estoy contando, con la mitad de las opciones desactivadas y sin poder tocarlas, probablemente tengas activado el cálculo automático de impuestos.

Cuando ese cálculo automático está activo WooCommerce deja de hacerte caso a la tabla manual porque los tipos los decide un servicio externo según la dirección del cliente. Para poder seguir los pasos de esta guía tienes que desactivarlo, y entonces recuperas el control de la tabla de tasas.

Los informes de impuestos

En WooCommerce > Análisis > Impuestos tienes el resumen de lo recaudado, con filtro por fechas y desglose por cada tasa que tengas configurada.

Es lo que le vas a pasar a tu gestoría cada trimestre, y de paso es la comprobación más rápida de si la configuración está bien hecha, porque si ves tasas que no esperabas o importes raros, algo has liado en la tabla.

Repaso rápido para no dejarte nada

El orden en el que conviene tomar las decisiones, por si quieres ir marcando:

1. Activar los impuestos en los ajustes generales.
2. Decidir si introduces los precios con impuestos incluidos o sin ellos, antes de cargar el catálogo.
3. Poner la ubicación del cliente por defecto en Ajustes generales.
4. Elegir según qué dirección se calculan los impuestos.
5. Dar de alta las tasas de los tipos que necesites, con su nombre y su prioridad.
6. Coordinar la clase de impuesto del envío con la casilla de envío de la tasa que corresponda.
7. Ajustar el redondeo y cómo se muestran precios y totales.
8. Hacer un pedido de prueba y comprobar que los números salen donde tienen que salir.

Y los fallos que más se repiten, para que los tengas fichados:

• Cambiar lo de precios con impuestos incluidos cuando el catálogo ya está cargado, y no revisar qué le ha pasado al margen.
• Dejar la ubicación del cliente por defecto sin poner y volverse loco buscando por qué no sale el IVA en la tienda.
• Marcar la casilla de compuesto pensando que sirve para relacionar dos impuestos que en realidad van sobre la misma base.
• Elegir una clase de impuesto para el envío sin comprobar que esa tasa tiene marcada la casilla de envío.
• Poner la misma prioridad a dos tasas que tenían que aplicarse las dos a la vez.

Los casos especiales: IRPF, recargo de equivalencia, otros impuestos y envíos, productos digitales, etc.

Hasta aquí lo que necesita una tienda española que vende a consumidor final dentro de España. Lo que viene ahora solo te hace falta si estás en alguno de estos supuestos, así que ve directo al tuyo.

Vendes a comerciantes minoristas, recargo de equivalencia

El recargo de equivalencia es un régimen especial de IVA obligatorio para comerciantes minoristas que sean personas físicas o comunidades de bienes y que vendan productos sin transformar al consumidor final. Si tus clientes son de ese perfil, tienes que facturarles el IVA más un recargo adicional.

Lo básico:

• Los tipos vigentes en 2026 son 5,2 % para los productos que van al 21 %, 1,4 % para los que van al 10 % y 0,5 % para los del 4 %.
• En la tabla de tasas se monta con dos filas del mismo país y prioridades distintas, una para el IVA y otra para el recargo, como te contaba en la sección de prioridad.
• La fila del recargo no se marca como compuesta, porque va sobre la misma base que el IVA.
• Tampoco se le suele marcar la casilla de envío, porque el recargo grava el producto y no el transporte.
• Con el desglose de totales activado, para que en el pedido se vean el IVA y el recargo como conceptos separados.

Y aquí está el límite de lo que WooCommerce hace solo, porque la tabla de tasas funciona por zonas geográficas y no distingue qué tipo de cliente está comprando, que es justo lo que necesitas para decidir si aplicas el recargo o no. Esa parte te la conté en su momento con la solución por rol de usuario en el artículo dedicado al recargo de equivalencia en WooCommerce.

Eres autónomo y tienes que retener IRPF

Si eres autónomo dado de alta en una actividad profesional y le vendes a otros profesionales o a empresas, en esas facturas hay que restar la retención del IRPF.

Lo básico:

• El tipo general de retención es el 15 %, con un reducido del 7 % para nuevos autónomos durante el año de alta y los dos siguientes.
• Solo aplica en actividades profesionales, las de las secciones segunda y tercera del impuesto de actividades económicas, no en las empresariales de la sección primera.
• Nunca se le retiene a un particular, solo a empresas y profesionales.
• La retención se calcula sobre la base imponible, y el IVA también, así que el IVA no cambia por el hecho de que haya retención.

Esto no se puede montar solo con la tabla de tasas de WooCommerce, porque todas sus columnas son geográficas y ninguna distingue qué tipo de cliente está comprando, que es justo lo que decide si hay retención o no. Lo tienes desarrollado, con los requisitos que debe cumplir cualquier solución y las opciones que hay según tu caso, en el artículo sobre la retención de IRPF en WooCommerce.

Envías a Canarias, Ceuta o Melilla desde la península

Estos territorios están fuera del ámbito de aplicación del IVA español, así que la venta desde la península hacia allí es una exportación exenta. Y de ahí sale lo que más confunde, y es que tú no cobras absolutamente ningún impuesto en esa venta.

Ni IVA, que no aplica, ni tampoco el IGIC canario o el IPSI de Ceuta y Melilla, porque esos los liquida el cliente en destino cuando el transportista o Correos le entrega el paquete, junto con los gastos de gestión que le cobren por el trámite.

En la tabla de tasas se refleja con cuatro filas al 0 %, una por cada provincia implicada, usando los códigos de provincia que espera WooCommerce:

• ES / GC / 0.0000 para Las Palmas.
• ES / TF / 0.0000 para Santa Cruz de Tenerife.
• ES / CE / 0.0000 para Ceuta.
• ES / ML / 0.0000 para Melilla.

Si prefieres tirar de códigos postales, el equivalente es 35* y 38* para Canarias, 51* para Ceuta y 52* para Melilla. Y acuérdate de marcarles la casilla de envío, porque tampoco se repercute impuesto sobre el transporte de una operación exenta.

Hay un detalle que tienes que comprobar tú y no dar por hecho, y es que si tu fila del IVA general lleva un asterisco en la columna de provincia, esa fila también encaja con un cliente de Las Palmas, así que las dos compiten.

Como solo se aplica una tasa por prioridad, coloca las filas específicas por encima de la general arrastrándolas en la tabla y haz un pedido de prueba con una dirección canaria para ver cuál gana de verdad. Son cinco minutos y te ahorran facturar mal durante meses.

Y un aviso que va más allá de los impuestos, porque un envío a estos destinos puede llevar trámites de aduana según el producto y su valor. Eso condiciona también cómo montes las zonas de envío, y es de las cosas que conviene consultar con tu gestoría antes de abrir la venta a estos territorios.

Tu tienda está en Canarias

Aquí la película es la contraria, porque sí repercutes IGIC en tus ventas dentro del archipiélago, y no IVA. La buena noticia es que la mecánica de WooCommerce es exactamente la misma que te he contado en todo el artículo, solo cambian los números que metes en las tasas.

Los tipos vigentes en 2026 son estos:

• 0 %: pan, leche, huevos, harinas, frutas, verduras, agua, libros, periódicos, medicamentos de uso humano y vivienda de protección oficial.
• 3 %: transporte de viajeros, hostelería y reparaciones de vivienda, entre otros.
• 7 %: el tipo general, o sea todo lo que no encaje en ningún otro. Es el equivalente al 21 % peninsular.
• 9,5 %: perfumería, joyería por debajo de 400 € y embarcaciones de hasta nueve metros.
• 15 %: artículos considerados suntuarios, como vehículos de lujo, embarcaciones grandes o joyas por encima de 400 €.
• 20 %: labores del tabaco rubio.

Desde 2026 hay además un tipo específico del 1 % para el petróleo y sus derivados, así que si vendes algo de eso no lo metas en el general por costumbre.

Un matiz que despista es que el tipo cero del IGIC no es lo mismo que una operación exenta. A tipo cero repercutes un 0 % pero conservas el derecho a deducir el IGIC que hayas soportado, mientras que en una operación exenta no deduces.

Para WooCommerce da igual porque en los dos casos la fila va a cero, pero para tu modelo 420 la diferencia es grande, así que no las mezcles en la misma clase de impuesto si quieres tener los números claros al cerrar el trimestre.

Si además vendes a la península desde Canarias, esa venta es una exportación igual que en el caso anterior, así que necesitas una fila al 0 % para el resto de provincias españolas. Lo que no puedes hacer es facturarle IGIC a un cliente peninsular, que es el error más típico de quien monta la tienda desde el archipiélago.

Los tipos y qué producto va en cada uno los actualiza la Agencia Tributaria Canaria, así que consúltalo ahí antes de dar por buena ninguna tasa, que estos tipos se retocan más a menudo que los peninsulares.

Tu tienda está en Ceuta o Melilla

Aquí no hay ni IVA ni IGIC sino IPSI, con tipos que van del 0,5 % al 10 % según la actividad. La particularidad es que cada ciudad tiene su propia ordenanza fiscal, así que no existe una tabla común que te sirva para las dos y tienes que mirar la de tu ciudad para saber qué tipo le corresponde a cada cosa que vendes.

El montaje en WooCommerce no tiene misterio una vez sabes los tipos, es dar de alta las tasas en las clases correspondientes igual que en cualquier otro caso.

Vendes a particulares de otros países de la Unión Europea

Mientras tus ventas a consumidores de otros países de la Unión Europea no pasen de 10.000 € al año en conjunto (no por país, sumando todos), sigues aplicando el IVA español y lo declaras en tu modelo 303 de siempre.

Cuando pasas ese umbral cambia la película porque tienes que aplicar el IVA del país de cada cliente. Sería así:

• Te das de alta en el régimen de ventanilla única con el modelo 035 en la sede de la Agencia Tributaria.
• Declaras todas esas ventas juntas con el modelo 369 trimestral, y la Agencia reparte a cada país lo suyo.
• Una vez dado de alta, el 369 se presenta cada trimestre aunque no hayas vendido nada en ese periodo.
• Hay otro régimen distinto, la ventanilla única de importación, para mercancía que viene de fuera de la Unión Europea por debajo de 150 €. No lo confundas con el anterior.
• Si le vendes a una empresa de otro país con número de operador intracomunitario válido, la operación va sin IVA por inversión del sujeto pasivo, que es otro supuesto diferente.

Montar los tipos de veintitantos países a mano en la tabla de tasas es posible pero es un suplicio de mantener, porque los tipos cambian y te enteras tarde. Para esto sí merece la pena un plugin que traiga los tipos actualizados y te controle el umbral. La parte de darte de alta y presentar los modelos no te la quita ningún plugin, eso sigue siendo cosa tuya y de tu asesoría.

Vendes productos digitales

Descargas, cursos, software y en general cualquier servicio prestado por vía electrónica tienen su propia regla desde 2015, y es que el IVA se calcula según dónde esté el cliente, no según dónde estés tú, sin umbral que valga para los consumidores de la Unión Europea.

Cómo se monta en WooCommerce:

• Creas una clase de impuesto adicional, por ejemplo llamada Bienes digitales.
• Le cargas en esa clase los tipos de IVA de cada país miembro.
• Asignas esa clase a tus productos digitales desde la ficha de cada uno, o en lote desde el listado de productos con la edición rápida.
• Compruebas que el cálculo por dirección está en la del cliente y no en la de la tienda, porque si no, nada de esto sirve.

Y hay una obligación que no es de WooCommerce pero que te afecta, y es que tienes que conservar pruebas de dónde estaba el cliente, normalmente su dirección de facturación y la dirección IP desde la que compró. Aquí también te viene bien un plugin de los que geolocalizan y guardan esa evidencia, porque hacerlo a mano no es viable.

Y la factura, que es otra guerra

Que los impuestos salgan bien en pantalla no significa que la factura salga bien, y esto cada día se pone más serio, más con la entrada en vigor del sistema de facturación verificable, obligatorio desde enero de 2027 para sociedades y desde julio de 2027 para autónomos.

No cambia nada de lo que has configurado aquí, porque afecta a cómo se genera y se conserva la factura, no a cómo se calcula el IVA. Lo tienes explicado en la guía de Verifactu en WooCommerce.

Con los impuestos resueltos, lo siguiente que toca es configurar los envíos, que merecen su propia ración de rarezas y tienen guía aparte.

La respuesta es que sí se puede, y en realidad no es tan complicado, tiene sus cosas, pero poderse se puede, y te lo explico ya mismo, pero igual la duda esté mal planteada de origen.

En realidad eso de «sin plugin» no es tan así

El código que configura el SMTP tiene que vivir en algún sitio, y solo hay tres:

• El functions.php del tema, que es la peor opción de las tres, porque el día que cambies de tema tu web deja de mandar correos y nadie va a relacionar una cosa con la otra.
• Un plugin propio, que evidentemente es un plugin.
• Un mu-plugin, en wp-content/mu-plugins/, que también es un plugin, solo que se activa siempre y no aparece con un botón de desactivar en el escritorio.

Así que lo que en realidad estás pensando es si puedes montar el SMTP sin instalar un plugin del directorio, y eso sí, con un archivo tuyo de veinte líneas.

Que sea un mu-plugin no es un tecnicismo tonto, es precisamente la ventaja, porque no se desactiva por error ni se pierde al tocar el tema.

Pues no, resulta que no existe eso de configurar SMTP desde wp-config.php

Meter las credenciales en wp-config.php está muy bien y es lo que vas a ver en el código de un poco más abajo de este artículo, pero por sí solas esas constantes no hacen absolutamente nada, porque WordPress no las lee, nunca ha tenido ajustes SMTP nativos.

La propuesta de añadirlos existe, es el ticket 29069 de Trac, abierto en 2014 y cerrado como wontfix en 2019, con dos argumentos:

1. WordPress va de decisiones y no de opciones, y esto es territorio de plugins.
2. Como wp_mail() es una función reemplazable, si un plugin la sustituye esas constantes dejarían de hacer efecto sin que nadie se enterase, lo que sería un infierno de depurar.

Lo que hay que hacer, entonces, es engancharse donde el núcleo de WordPress sí lo permite.

Esto sí está en WordPress: PHPMailer

WordPress trae PHPMailer incluido, y esa librería sirve SMTP de serie. Lo único que falta es decirle cómo, y para eso hay cuatro puntos de enganche:

• phpmailer_init: se dispara justo después de crear el objeto PHPMailer y te lo pasa por referencia, así que puedes configurarlo a tu gusto. Existe desde WordPress 2.2.
• pre_wp_mail: cortocircuita wp_mail() entero, de modo que puedes mandar el correo como te dé la gana y devolver si salió bien. Está desde WordPress 5.7.
• wp_mail_succeeded: salta cuando el envío se ha procesado sin errores y te entrega destinatario, asunto, mensaje, cabeceras y adjuntos. Desde WordPress 5.9.
• wp_mail_failed: te entrega el objeto de error cuando el envío falla, que es la única forma de enterarte de lo que pasó.

Con el primero montas el envío,  con los dos últimos te haces tu propio registro de correos, que es lo que la mayoría de plugins te cobra.

SMTP en WordPress «sin plugins» en 2 pasos

Empezamos con las credenciales, en wp-config.php, por encima de la línea que dice que dejes de añadir cosas. Ponlas ahí y no en el mu-plugin, que luego los archivos de código acaban en un repositorio o en un correo de soporte y las contraseñas viajan con ellos.

define( 'AYUDAWP_SMTP_HOST', 'smtp.TUPROVEEDOR.com' );
define( 'AYUDAWP_SMTP_PORT', 587 );
define( 'AYUDAWP_SMTP_SECURE', 'tls' );
define( 'AYUDAWP_SMTP_USER', 'NOMBRE@TUDOMINIO' );
define( 'AYUDAWP_SMTP_PASS', 'PON_AQUI_TU_CLAVE' );
define( 'AYUDAWP_SMTP_FROM', 'NOMBRE@TUDOMINIO.com' );
define( 'AYUDAWP_SMTP_FROM_NAME', 'Nombre del remitente o de tu web' );

De dónde sale cada uno de esos valores

Lo de clave_ SMTP_ significa una cosa distinta según dónde tengas el correo:

• Correo del dominio en tu propio hosting: El servidor te lo da el panel de tu alojamiento web, normalmente algo del estilo mail.tudominio.com, el usuario es la dirección completa del buzón y la contraseña es esa misma que pusiste al crear la cuenta de correo.
• Gmail o Google Workspace: El servidor suele ser smtp.gmail.com, el usuario es tu dirección completa y la contraseña es una contraseña de aplicación de Google, normalmente de dieciséis caracteres, que se generan en la sección de seguridad de tu cuenta y que necesitan la verificación en dos pasos activada. La contraseña normal de Google no vale desde hace años.
• Un servicio transaccional: del tipo Brevo, Mailgun o SMTP2GO. Cada uno tiene su pantalla de credenciales SMTP donde te genera un usuario y una clave específicos para esto, que no son los que usas para entrar en el servicio. Ahí también te dan el servidor y el puerto a utilizar.
• Microsoft 365 u Outlook: Aquí no te doy valores porque no te lo recomiendo, que la identificación básica cada vez funciona menos, y en las cuentas personales ya ni está. Esto lo explico en otro momento.

Por cierto, importante, las contraseñas de aplicación de WordPress no sirven para esto, esas se utilizan para que una aplicación externa se identifique en la REST API o XML-RPC de tu web.

Son cosa de entrada, no de salida, y si las pegas en la constante de la contraseña el servidor de correo te va a rechazar sin contemplaciones. Si te interesa el tema lo explico en este artículo sobre las contraseñas de aplicación de WordPress.

Por ir terminando con los detalles, el hecho de que Google llame igual a las suyas es una coincidencia desafortunada que confunde a medio mundo, pero son dos cosas que no tienen nada que ver.

No me enrollo más y dicho esto ya tocaría ponernos con el mu-plugin. Creas la carpeta wp-content/mu-plugins/ si no la tienes, y dentro un archivo llamado, por ejemplo, ayudawp-smtp.php:

<?php
/**
 * Plugin Name: SMTP para WordPress
 * Plugin URI: https://plugins.ayudawp.com
 * Description: Envía los correos de WordPress usando un servidor SMTP con identificación.
 * Version: 1.0.0
 * Author: Fernando Tellado
 * Author URI: https://tellado.es 
 * License: GPL-2.0-or-later
 */

defined( 'ABSPATH' ) || exit;

/**
 * Configure PHPMailer para usar SMTP.
 * Las credenciales van como constantes en wp-config.php, no las metas aquí.
 */
function ayudawp_smtp_config( $phpmailer ) {

	// Salida silenciosa si el sitio aún no se ha configurado
	if ( ! defined( 'AYUDAWP_SMTP_HOST' ) || ! defined( 'AYUDAWP_SMTP_PASS' ) ) {
		return;
	}

	$phpmailer->isSMTP();
	$phpmailer->Host       = AYUDAWP_SMTP_HOST;
	$phpmailer->Port       = AYUDAWP_SMTP_PORT;
	$phpmailer->SMTPAuth   = true;
	$phpmailer->SMTPSecure = AYUDAWP_SMTP_SECURE;
	$phpmailer->Username   = AYUDAWP_SMTP_USER;
	$phpmailer->Password   = AYUDAWP_SMTP_PASS;

	// 30 segundos es más que suficiente. Con el valor por defecto la solicitud se quedaría bloqueada durante varios minutos
	$phpmailer->Timeout = 30;
}
add_action( 'phpmailer_init', 'ayudawp_smtp_config' );

/**
 * La dirección del remitente debe pertenecer al dominio autorizado (coincidencia SPF/DKIM)
 */
function ayudawp_smtp_from( $from ) {
	return defined( 'AYUDAWP_SMTP_FROM' ) ? AYUDAWP_SMTP_FROM : $from;
}
add_filter( 'wp_mail_from', 'ayudawp_smtp_from' );

function ayudawp_smtp_from_name( $name ) {
	return defined( 'AYUDAWP_SMTP_FROM_NAME' ) ? AYUDAWP_SMTP_FROM_NAME : $name;
}
add_filter( 'wp_mail_from_name', 'ayudawp_smtp_from_name' );

Ya está, eso es todo. En cuanto subes el archivo está activo, los mu-plugins no hace falta activarlos, y si tienes ya añadidos tus datos al wp-config.php como en el primer paso ya lo tienes.

Valores que podrían darte algo de guerra

El puerto y el cifrado se confunden constantemente porque van emparejados:

• El 587 va con tls, que arranca en claro y sube a cifrado con STARTTLS, y es el que deberías usar.
• El 465 va con ssl, cifrado desde el primer byte, y sigue funcionando en todas partes.
• El 25 no lo uses para esto, está pensado para el tráfico entre servidores y lo tiene bloqueado medio internet.

Con el remitente mejor los dos filtros del ejemplo que tocar $phpmailer->From a pelo, porque así lo respeta cualquier otro plugin que mande correos.

Y si alguna vez tienes que llamar a setFrom(), pásale false como tercer parámetro para que PHPMailer no te pise la cabecera Sender, que hay servidores que rechazan el mensaje por eso.

Todo en un archivo, si no quieres tocar wp-config.php

Hay quien no quiere andar tocando wp-config.php, y lo entiendo, que es el archivo donde un despiste te deja la web en blanco. Así que aquí tienes la misma cosa en un solo archivo, con las credenciales dentro y un bloque de ajustes arriba que es lo único que hay que editar.

Eso sí, sustituye a los dos anteriores, no los mezcles, o usas los 2 pasos de antes o este archivo completo.

<?php
/**
 * Plugin Name: SMTP para WordPress
 * Plugin URI: https://plugins.ayudawp.com
 * Description: Envía los correos de WordPress usando un servidor SMTP con identificación.
 * Version: 1.0.0
 * Author: Fernando Tellado
 * Author URI: https://tellado.es
 * License: GPL-2.0-or-later
 */

defined( 'ABSPATH' ) || exit;

/**
 * Ajustes SMTP. Este es el único bloque que tienes que modificar
 *
 * host      Servidor de correo saliente, te lo da tu proveedor de mail
 * port      587 con 'tls', o 465 con 'ssl'
 * secure    Debe coincidir con el puerto de arriba
 * user      Normalmente la dirección de email
 * pass      La contraseña SMTP de la dirección de email
 * from      Dirección de email del remitente. Debe pertenecer al dominio autorizado
 * from_name Nombre del remitente mostrado en los correos enviados
 */
function ayudawp_smtp_settings() {

	return array(
		'host'      => 'smtp.TUPROVEEDOR.com',
		'port'      => 587,
		'secure'    => 'tls',
		'user'      => 'NOMBRE@TUDOMINIO.com',
		'pass'      => 'PON_AQUI_TU_CLAVE',
		'from'      => 'NOMBRE@TUDOMINIO.com',
		'from_name' => 'Nombre del remitente o de tu web',
	);
}

/**
 * Configura PHPMailer para que use SMTP
 */
function ayudawp_smtp_config( $phpmailer ) {

	$config = ayudawp_smtp_settings();

	// No hace nada hasta que los ajustes de arriba se hayan completado
	if ( empty( $config['host'] ) || 'PON_AQUI_TU_CLAVE' === $config['pass'] ) {
		return;
	}

	$phpmailer->isSMTP();
	$phpmailer->Host       = $config['host'];
	$phpmailer->Port       = (int) $config['port'];
	$phpmailer->SMTPAuth   = true;
	$phpmailer->SMTPSecure = $config['secure'];
	$phpmailer->Username   = $config['user'];
	$phpmailer->Password   = $config['pass'];

	// 30 segundos es más que suficiente. Con el valor por defecto la solicitud se quedaría bloqueada durante varios minutos.
	$phpmailer->Timeout = 30;
}
add_action( 'phpmailer_init', 'ayudawp_smtp_config' );

/**
 * La dirección del remitente debe pertenecer al dominio autorizado (coincidencia SPF/DKIM)
 */
function ayudawp_smtp_from( $from ) {

	$config = ayudawp_smtp_settings();

	return ! empty( $config['from'] ) ? $config['from'] : $from;
}
add_filter( 'wp_mail_from', 'ayudawp_smtp_from' );

function ayudawp_smtp_from_name( $name ) {

	$config = ayudawp_smtp_settings();

	return ! empty( $config['from_name'] ) ? $config['from_name'] : $name;
}
add_filter( 'wp_mail_from_name', 'ayudawp_smtp_from_name' );

Fíjate en el condicional del principio, que no está de adorno. Mientras la clave siga siendo el texto de ejemplo, el mu-plugin no hace nada y WordPress manda como siempre, así que si subes el archivo y se te olvida rellenarlo no rompes el envío, simplemente sigue como estaba.

Y ahora un aviso, o recordatorio, como prefieras, y es que meter la clave aquí es más cómodo pero también menos seguro, por un motivo muy concreto.

Los archivos dentro de mu-plugins están dentro de wp-content, que es una carpeta pública, y el día que el servidor deje de procesar PHP por lo que sea, este archivo se sirve como texto plano con tu contraseña dentro.

Con wp-config.php puede pasar lo mismo, pero con la diferencia de que casi todos los hosting traen una regla en el servidor que bloquea ese archivo por su nombre, o incluso la puedes añadir tú usando Vigilante, y para tu mu-plugin no la trae nadie.

Si te vas por este camino dedícale un minuto a poner esa regla tú, si no la añade tu hosting o no usas Vigilante (a quién se le ocurre). Creas un archivo llamado .htaccess dentro de wp-content/mu-plugins/ con estas tres líneas:

<FilesMatch "\.php$">
Require all denied
</FilesMatch>

Con Nginx eso no vale y hay que pedírselo a tu proveedor, o mirar si su panel te deja bloquear el acceso directo a esa carpeta. Y en cualquiera de los dos casos, acuérdate de que la clave viaja en las copias de seguridad, así que si le pasas un respaldo a alguien le estás pasando también la contraseña del correo.

Tu propio registro de correos, sin base de datos ni plugins de pago

Esta es la parte que hace que merezca (más) la pena todo lo anterior, porque el registro de envíos es justo lo que casi todos los plugins de SMTP guardan para la versión de pago, y montarlo son unas pocas líneas más.

La idea es simple, enganchas wp_mail_succeeded y wp_mail_failed, y escribes una línea por envío en un archivo de texto. Nada de tablas, nada de tipos de contenido personalizados, nada que engorde la base de datos.

Eso sí, lo que te propongo lleva un par de decisiones de diseño que no son caprichos. Por un lado verás que el archivo empieza por una instrucción de salida de PHP para que nadie pueda leerlo desde el navegador aunque adivine la ruta, y no guardo el cuerpo de los mensajes, solo destinatario, asunto y resultado.

Esto lo he definido así porque un registro de correos completo es un almacén de datos personales con todo lo que eso implica en cuanto al RGPD.

/**
 * Registro minimalista de registro de correos. Sin base de datos ni pantalla de ajustes
 * Escribe una línea por mensaje a un archivo protegido dentro de wp-content
 */
function ayudawp_mail_log_file() {
	return WP_CONTENT_DIR . '/ayudawp-mail-log.php';
}

/**
 * Añade una entrada al registro, rotando el archivo cuando crezca demasiado
 * Nunca se almacenan los contenidos del mensaje, solo los metadatos
 */
function ayudawp_mail_log_write( $status, $to, $subject, $detail = '' ) {

	$file = ayudawp_mail_log_file();
	// El carácter de salida impide que el archivo se pueda leer a través de HTTP
	$header = "<?php exit; ?>\n";

	if ( ! file_exists( $file ) ) {
		file_put_contents( $file, $header );
	}

	clearstatcache( true, $file );

	// Rota cuando llegue a los 2 MB, manteniendo solo un archivo previo
	if ( filesize( $file ) > 2 * MB_IN_BYTES ) {
		rename( $file, $file . '.old' );
		file_put_contents( $file, $header );
	}

	$line = sprintf(
		"[%s] %s | para: %s | asunto: %s%s\n",
		current_time( 'mysql' ),
		$status,
		is_array( $to ) ? implode( ', ', $to ) : $to,
		$subject,
		'' !== $detail ? ' | ' . $detail : ''
	);

	file_put_contents( $file, $line, FILE_APPEND | LOCK_EX );
}

/**
 * Registra mensajes que PHPMailer procesó sin errores
 */
function ayudawp_mail_log_success( $mail_data ) {
	ayudawp_mail_log_write( 'OK  ', $mail_data['to'], $mail_data['subject'] );
}
add_action( 'wp_mail_succeeded', 'ayudawp_mail_log_success' );

/**
 * Registra juntos los fallos con el motivo que los provocó
 */
function ayudawp_mail_log_failure( $error ) {

	$data = $error->get_error_data();

	ayudawp_mail_log_write(
		'KO',
		isset( $data['to'] ) ? $data['to'] : 'desconocido',
		isset( $data['subject'] ) ? $data['subject'] : 'desconocido',
		$error->get_error_message()
	);
}
add_action( 'wp_mail_failed', 'ayudawp_mail_log_failure' );

El resultado es un archivo que puedes abrir con el gestor de archivos del hosting o un cliente FTP, y que se lee de un vistazo:

[2026-08-11 09:14:22] OK   | para: cliente@example.com | asunto: Tu pedido #1482
[2026-08-11 09:31:07] KO | para: otro@example.com | asunto: Restablecer contraseña | SMTP connect() failed.

Un par de avisos sobre este código.

• El gancho de éxito significa que el mensaje salió sin errores, no significa que haya llegado a la bandeja de nadie, eso lo avisa el propio núcleo en su documentación.
• Si algún día conviertes esto en un plugin para el directorio oficial, la escritura de archivos hay que hacerla con la API de sistema de archivos de WordPress, que aquí he ido directo para no triplicar el código de un ejemplo.

Cuando el puerto está cerrado el camino es HTTPS

Bastantes hosting bloquean las conexiones salientes por los puertos de correo, y lo hacen por un buen motivo, para que una web comprometida no acabe convertida en una máquina de spam.

Si te toca uno de esos alojamientos entonces SMTP no es una opción y no lo va a ser por mucho que insistas.

La salida es mandar por la API del proveedor, que viaja por HTTPS y no la bloquea nadie. Y aquí es donde entra pre_wp_mail, que cortocircuita el envío entero:

/**
 * Envía los correos de WordPress usando un proveedor con API HTTP en vez de SMTP
 * Devolver un valor no nulo frena wp_mail()
 */
function ayudawp_mail_via_api( $short_circuit, $atts ) {

	if ( ! defined( 'AYUDAWP_MAIL_API_KEY' ) ) {
		return $short_circuit; // Deja que WordPress lo gestione como siempre
	}

	$to = is_array( $atts['to'] ) ? $atts['to'] : array( $atts['to'] );

	$response = wp_remote_post(
		'https://api.TUPROVEEDOR.com/v1/send',
		array(
			'timeout' => 15,
			'headers' => array(
				'Authorization' => 'Bearer ' . AYUDAWP_MAIL_API_KEY,
				'Content-Type'  => 'application/json',
			),
			'body'    => wp_json_encode(
				array(
					'from'    => AYUDAWP_SMTP_FROM,
					'to'      => $to,
					'subject' => $atts['subject'],
					'html'    => $atts['message'],
				)
			),
		)
	);

	if ( is_wp_error( $response ) ) {
		ayudawp_mail_log_write( 'KO', $to, $atts['subject'], $response->get_error_message() );
		return false;
	}

	$sent = ( 200 === wp_remote_retrieve_response_code( $response ) );
	ayudawp_mail_log_write( $sent ? 'OK  ' : 'FALLO', $to, $atts['subject'] );

	return $sent;
}
add_filter( 'pre_wp_mail', 'ayudawp_mail_via_api', 10, 2 );

Ese código es una base de partida, pues cada proveedor tiene su formato, así que la estructura del cuerpo la sacas de su documentación.

Fíjate en que aquí llamo al registro a mano, porque al cortocircuitar wp_mail() los ganchos de éxito y de fallo del núcleo ya no se disparan.

Y ojo con lo demás, si cortocircuitas wp_mail() te quedas tú al mando de todo, incluidos los adjuntos, las cabeceras personalizadas y el juego de caracteres, que en el ejemplo no están contemplados.

Para una web que solo manda avisos de texto va sobrado, para una tienda con facturas adjuntas necesitas bastante más código.

¿Funciona?

No te fíes de que no salte ningún error, eso no significa nada. Pide un restablecimiento de contraseña desde la pantalla de acceso con un usuario cuyo correo esté en otro proveedor, y mira la bandeja y el spam.

Si no llega, abre el archivo de registro, que ahí tienes el motivo. Y si quieres además el detalle en el log de PHP, activa la depuración en wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Los mensajes suelen ser explícitos. Si dice que la autorización ha fallado revisa usuario y contraseña. Si dice que no puede conectar o que la conexión se ha rechazado el problema es el puerto, y ahí no hay código que valga.

Lo que sigues sin tener

Con lo de arriba tienes envío verificado y registro de correos, que es el 80% de lo que dan los plugins, pero te falta lo siguiente:

• El botón de prueba: que parece una tontería hasta que estás cambiando de proveedor un viernes por la tarde.
• La conexión de reserva: para que si el proveedor principal se cae entre el segundo sin que se pierda nada.
• Los reintentos y la cola: que evitan que un pico de envíos te ralentice la web.
• La pantalla de consulta: porque leer un archivo de texto por FTP no es lo mismo que filtrar en una tabla del escritorio.

Y hay un caso donde directamente no compensa y es si tu correo está en Gmail o en Microsoft y quieres usar OAuth, olvídate de hacerlo a mano, porque necesitas una librería externa, gestionar tokens y renovarlos. Ahí un plugin te lo resuelve con dos clics y tú tardarías muchas horas en tener algo peor.

Entonces, ¿código o plugin?

Mi criterio después de bastantes webs de cliente es que si la web la mantienes tú, va por control de versiones y el correo es de dominio propio contra un servidor que controlas, el mu-plugin es perfecto y además no te añade tablas ni panel de ajustes.

Si la web la va a tocar otra persona, si el correo va por Gmail o Microsoft, o si es una tienda donde perder un aviso de pedido cuesta dinero, instala un plugin con registro incluido en la versión gratuita. Los tienes comparados en WordPress no manda emails, y casi nunca es culpa de WordPress, que además cubre la parte de SPF, DKIM y DMARC, sin la cual todo esto sirve de poco.

Si le das una vuelta al código y lo mejoras, cuéntamelo en los comentarios, que estas cosas se afinan entre todos.

¿Suena bien, a que sí?, porque es lo único que importa de verdad de este asunto, y porque casi todo lo demás sobre passkeys se queda en lo bonito de entrar con la huella, y lo de la huella es la parte cómoda, no la parte importante.

Pero hay una segunda mitad de la historia que es la de verdad importante, que es la que te puede dejar fuera de tu propia web o darte una falsa sensación de seguridad. ¿Te animas?, es una historia apasionante, y de rabiosa actualidad.

Qué es una passkey, y sobre todo qué no es

Una passkey es un par de claves criptográficas. La privada se queda en tu dispositivo o en tu gestor de contraseñas y no sale de ahí nunca, y la pública se guarda en la web donde te identificas.

Cuando entras, la web te manda un desafío, tu dispositivo lo firma con la clave privada después de comprobar que eres tú (huella, cara o PIN), y la web verifica la firma con la clave pública que ya tenía.

Lo que se guarda en tu servidor son claves públicas, o sea, información que no sirve para entrar en ningún sitio.

Si mañana te roban la base de datos entera el atacante se lleva un puñado de claves públicas y un rato de trabajo perdido. Compara eso con lo que pasa cuando se filtra una tabla de contraseñas.

Y aquí viene la parte más confusa, donde a veces nos liamos, porque «acceso sin contraseña» se ha convertido en un cajón donde cabe cualquier cosa.

Estos son los 4 métodos de acceso sin contraseña que solemos confundir, para tenerlo claro antes de empezar:

Fíjate en la columna del dominio clonado, porque es la única en la que la passkey juega en otra liga.

El código de seis dígitos de tu aplicación de autorización es un secreto compartido que tú tecleas, así que si te lo tecleas en la web del malo, se lo has dado.

La passkey no la tecleas, la firma tu dispositivo, y tu dispositivo comprueba el dominio antes de firmar.

Si quieres repasar los otros dos métodos con calma, tengo escrito sobre la identificación de dos factores en WordPress y sobre el acceso mediante enlace mágico, que sigue teniendo sentido para lo que tiene es, para la comodidad.

El phishing se acabó

Ya te he dicho lo bueno, así que toca la letra pequeña, porque la passkey blinda la puerta, no toda la casa. Estas cosas te siguen pudiendo pasar exactamente igual:

• Que te roben la cookie de sesión una vez has entrado, con malware o con un cross-site scripting: La passkey se usa en el momento de identificarte, y a partir de ahí eres una sesión abierta como cualquier otra. Si sospechas que ha pasado, lo que echa a todo el mundo fuera de golpe es renovar las claves de seguridad del wp-config.php, tal como cuento en la guía para limpiar y recuperar un WordPress hackeado.
• Que tengas el equipo comprometido: Si el malo está dentro de tu ordenador, ya has perdido y da igual cómo entres.
• Que te ataquen por el método de respaldo: Si dejas la contraseña activa, y vas a dejarla, el phishing simplemente irá a por la contraseña, que es lo que hacen los atacantes desde siempre, ir por donde menos cuesta.
• Que te secuestren el correo y usen el «¿Has olvidado tu contraseña?», que sigue ahí, funcionando como el primer día.

Nada de esto es un argumento contra las passkeys, ojo, es un argumento contra venderlas como si fueran un campo de fuerza. Sirven para lo que sirven, y lo que hacen lo hacen mejor que ninguna otra cosa que tengamos.

Quién las usa ya, y quién ha ido más lejos

Google, Apple y Microsoft las ofrecen por defecto en sus cuentas personales, y ahí es donde la mayoría de la gente tiene ya una passkey sin haberse dado cuenta.

La FIDO Alliance, que es quien está detrás del estándar, publicó en mayo su informe anual y calcula unos 5.000 millones de passkeys en uso en el mundo, con un 75 % de personas que tienen al menos una activada y un 49 % que las usa habitualmente cuando la web se lo permite.

Un aviso de rigor sobre esas cifras es que la muestra es de diez países, y España no está entre ellos, así que sirven para ver la tendencia, no para calcular cuántos de tus clientes van a saber qué hacer cuando les salga el aviso.

El caso que mejor muestra hasta dónde llega esto es el de OpenAI, que ha sacado un modo de seguridad reforzada para las cuentas de ChatGPT en el que la contraseña se desactiva, hay que registrar dos credenciales entre passkeys y llaves físicas, y se elimina la recuperación por correo y por SMS.

La frase que hay que subrayar de su documentación es que una vez lo activas, ni siquiera su soporte puede devolverte la cuenta. No todo iba a ser bonito, las IAs, ya sabes.

Ahí tienes la ventaja y el peligro en la misma frase, y por eso este artículo dedica más espacio a la recuperación que al registro.

Y por si te queda lejos, dos ejemplos que te tocan de cerca. Tu cuenta de WordPress.org admite llaves de seguridad desde la pestaña de cuenta y seguridad de tu perfil, y WordPress.com también las admite como verificación de acceso.

O sea que el proyecto usa passkeys para proteger a la gente que hace WordPress, mientras que el núcleo de WordPress sigue sin traer nada de esto para tu web. Ni en la versión actual ni en las siguientes, que no mencionan WebAuthn por ningún lado.

Los dos modelos de Passkey ¿cuál es el que nos interesa?

Esto es quizás lo que más te va a seguir de todo lo que llevo escrito, así que céntrate un poquito, que te toca decidir.

Passkey como sistema de acceso en dos pasos

Metes usuario y contraseña como siempre, y en la pantalla siguiente, en vez del código de seis dígitos, firmas con la huella o con la llave. La contraseña sigue funcionando como red de seguridad.

Es el modo conservador, es el que menos soporte genera y es donde vas a acabar tú, casi seguro. Ganas el fin del phishing y te quitas de encima el baile del código de seis dígitos, que es lo que odia todo el mundo de la verificación en dos pasos.

Passkey como acceso completo

No hay contraseña. Pones el nombre de usuario, o ni eso, firmas y estás dentro. Es el modo que cambia de verdad el modelo de amenaza, y también el que te obliga a tener un plan de recuperación de adulto.

La mezcla perfecta

Y luego está esto, que es donde casi todo la mayoría nos equivocamos, incluido yo, por supuesto, cuando empecé a darle vueltas al asunto.

El phishing se acabó el primer día con el modo de doble verificación, pero el tener que completar credenciales no se acaba hasta que apagas la contraseña. Y esto no es porque la passkey no sea buena, sino porque mientras la contraseña siga siendo una credencial válida el atacante sigue pudiendo probar pares de usuario y contraseña contra tu web.

Aunque no se complete el acceso porque falta la passkey, obtiene lo que de verdad busca, que es confirmar que ese par funciona para ir luego a probarlo al correo de esa persona, o a su banco, o a los otros quince sitios donde repite contraseña.

Esto significa que en el modo de doble verificación en dos pasos tu web deja de ser la puerta por la que entran, pero sigue siendo quién les dice si la llave que tienen es buena o no.

Por eso la secuencia sensata es esta, y por eso el modo sin contraseña tiene que ir siempre acompañado de dos credenciales registradas y de códigos de respaldo guardados fuera del ordenador.

No es prudencia histérica, es que el día que quitas la contraseña te quedas sin alternativa.

Un paso o dos, y por qué no hace falta pedir también el código

Una passkey que exige verificación de usuario (huella, cara o PIN antes de firmar) ya son dos pasos por sí sola: algo que tienes, que es el dispositivo o la credencial, y algo que eres o que sabes, que es lo que desbloquea la firma.

Pedir además el código de seis dígitos es pedir dos veces lo mismo. Si la credencial no lleva verificación de usuario entonces sí es un solo factor y no debería contar como doble verificación.

Y ahora otro matiz que tiene consecuencias prácticas gordas.

¿Passkey sincronizada o atada al dispositivo?

Hay dos tipos de passkey:

• Sincronizada: está en tu llavero de iCloud, en el gestor de Google o en el gestor que uses, y aparece sola en todos tus dispositivos.
• Atada al dispositivo: esta nace y muere en el dispositivo donde la creaste, y ese es el caso de una llave física tipo YubiKey o de Windows Hello.

La diferencia es relevante por dos motivos. El primero es de seguridad, porque en una passkey sincronizada, el «algo que tienes» ya no es el móvil, es la cuenta que sincroniza. Quien te comprometa esa cuenta tiene tus passkeys en todas partes.

Esto tiene matices, porque las passkeys de iCloud van cifradas de extremo a extremo y sacarlas de ahí exige la cuenta más el código del dispositivo, así que el listón está bastante más alto que robar una contraseña. Pero el factor de posesión se ha desplazado del cacharro a la cuenta, y eso es un cambio de verdad.

El segundo motivo es de recuperación, y de ese hablamos más abajo porque cambia por completo el consejo que te tengo que dar.

El detalle práctico es que ni el navegador ni el sistema operativo te dicen qué tipo de passkey estás creando. La propia credencial lo declara en la ceremonia mediante dos indicadores técnicos, y esa es la única forma fiable de saberlo.

Fíjate hasta qué punto está la cosa revuelta, que a día de hoy, Windows Hello genera credenciales atadas al dispositivo mientras que la sincronización en Windows llega por el gestor del navegador, por encima del sistema de autorización del sistema.

Y hasta Chrome en Windows puede guardarte la passkey en Windows Hello aunque tú creyeras estar creando una passkey sincronizada de Google.

O sea que el usuario ni lo elige ni lo sabe. Guarda esta idea para el final del artículo, que lo vamos a repasar.

Las puertas que la passkey no cierra en WordPress

WordPress no tiene una puerta de entrada, tiene varias, y la passkey protege la pantalla de acceso, nada más. Mientras la contraseña siga siendo válida, hay dos caminos que autorizan sin pasar por esa pantalla y se saltan tu passkey del todo:

• XML-RPC: Si lo tienes activo, acepta usuario y contraseña directamente. Es la puerta que llevan años usando para los ataques de fuerza bruta masivos, precisamente porque no pasa por el formulario.
• Las contraseñas de aplicación: Son una funcionalidad del propio WordPress, muy útil, que permite autenticarse contra la API REST con una credencial que el usuario genera desde su perfil. No pasa por la pantalla de acceso, no pasa por la doble verificación y no pasa por tu passkey.

Y quedan dos caminos más que no son un fallo de nadie pero que hay que tener en la cabeza, que son el restablecimiento de contraseña por correo, que sigue siendo una vía de vuelta perfectamente válida para quien controle el buzón, y los accesos del hosting, que con el gestor de archivos o con phpMyAdmin entran sin preguntarle nada a WordPress.

La conclusión práctica, y perdona que sea pesado, es que el modo de verificación en dos pasos solo es tan fuerte como esos dos interruptores.

Si activas passkeys y dejas XML-RPC abierto y las contraseñas de aplicación campando a sus anchas, has puesto una puerta blindada en una casa con la ventana del patio abierta.

Lo bueno es que cerrarlas es fácil, porque casi todos los plugins de seguridad decentes lo traen. Wordfence tiene control de XML-RPC, y en el mío, Vigilante, tienes el bloqueo de XML-RPC y la restricción de la API REST en tres modos, además del modo bajo ataque para cuando la cosa se pone fea.

Si no usas ninguno de estos plugins de seguridad, al menos comprueba que el tuyo tanga ambas cosas antes de ponerte con las passkeys, porque el orden importa.

Sin plugin no hay passkeys, y no es por pereza

Te lo digo claro para que no pierdas la tarde buscando: no hay forma razonable de tener passkeys en WordPress sin un plugin.

Hace falta JavaScript en la pantalla de acceso para lanzar la ceremonia del navegador, dos rutas nuevas en el servidor para el registro y para la firma, una tabla donde guardar las claves públicas y sus indicadores, y la verificación criptográfica de cada firma. Todo eso junto es un plugin, lo llames como lo llames y lo pongas donde lo pongas.

Las dos alternativas que puede que encuentres por ahí o te cuente tu IA favorita no valen.

• Meterlo en el functions.php del tema es la peor idea posible, porque el día que cambies de tema te quedas fuera de tu propia web con la ceremonia a medias.
• Delegar la identificación en un proveedor externo te ata a un servicio de pago que se queda con tus usuarios, que es justo lo contrario de lo que buscas si has llegado hasta aquí.

Lo que sí puedes exigirle a un plugin es que la verificación se haga en tu servidor, sin librerías externas ni llamadas a terceros. Eso es perfectamente posible, y es lo que separa un plugin honesto de un intermediario disfrazado de plugin.

Qué plugin WordPress usar según lo que necesites

No pongo versiones ni fechas a propósito, porque esto se mueve rápido y un artículo con números concretos nace caducado. Comprueba siempre el estado actual en la ficha de cada uno.

Wordfence

Es la opción por volumen, con varios millones de instalaciones, y ha incorporado passkeys tanto en la versión gratuita como en la de pago, para cualquier perfil de usuario y con integración de WooCommerce para las pantallas de cuenta de cliente.

Su propia documentación avisa de que la compatibilidad para multisitio es limitado por ahora, y más abajo te explico por qué eso no es dejadez suya.

Si ya usas Wordfence no busques más y quédate donde ahí. Si te lo estás planteando por las passkeys, ten en cuenta que te llevas el cortafuegos y el escáner en el mismo paquete, para bien y para mal. Te reconozco que no es santo de mi devoción, y creé Vigilante precisamente por ello, pero es de justicia reconocer sus virtudes (por pocas que sean).

WP 2FA, de Melapress

Trae passkeys en la versión gratuita, con lo que a mí me parece su mejor baza, que son las políticas por perfil de usuario con periodo de gracia.

Si tienes que sacar adelante una web con quince editores y no puedes ir uno por uno pidiéndoles por favor que se configuren el acceso, esto es lo que quieres. El asistente de configuración está bien pensado para gente que no es técnica.

El plugin oficial Two Factor, y su extensión

Two Factor es el plugin de doble factor de WordPress.org, lo mantiene gente del núcleo, tiene cien mil instalaciones y es una maravilla para TOTP, correo y códigos de respaldo.

Pero no trae passkeys, es más, la compatibilidad con las llaves de seguridad antiguas la ha quitado porque los navegadores dejaron de admitir aquel estándar, así que ahora mismo va menos servido que antes en ese apartado.

Para tener passkeys necesitas instalar además el complemento WebAuthn, que es de un desarrollador externo, tiene mil instalaciones y exige una versión de PHP más alta que la que pide el propio WordPress. Funciona bien, que conste, y quien lo mantiene sabe lo que hace.

Pero que la solución oficial para passkeys en WordPress sea «instálate estos dos y cruza los dedos» dice bastante de por dónde va la prioridad del proyecto en este asunto. La propuesta de código para meter WebAuthn dentro del plugin oficial lleva años abierta.

Mi consejo es que si ya tienes Two Factor montado y funcionando, añadir el complemento es el camino menos lioso, pero si empiezas de cero hay opciones más completas y mejor resueltas.

Secure Passkeys y WP-WebAuthn

Los dos son plugins dedicados solo a esto, sin cortafuegos ni escáner ni nada más, y ahí está su gracia.

Secure Passkeys tiene el autorrelleno, que es el detalle que de verdad hace que la experiencia sea buena, porque la passkey te aparece sola al pinchar en el campo de usuario sin tener que darle a ningún botón.

WP-WebAuthn permite el acceso sin escribir siquiera el nombre de usuario, aunque su soporte para multisitio sigue estando en pruebas y necesita extensiones de PHP que no todos los alojamientos compartidos traen puestas.

Si tu web ya tiene una suite de seguridad, no metas un segundo plugin que toque el acceso.

Vigilante (próximamente)

Y ahora el mío, con el aviso por delante para que nadie se lleve un chasco, porque Vigilante (aún) no ofrece passkeys.

Ofrece verificación en dos pasos con aplicación de autenticación y con códigos por correo, con dispositivos de confianza y con obligación por perfil de usuario, así que si lo instalas ahora mismo buscando passkeys te vas a quedar con las ganas. Están apuntadas en la lista de tareas, eso sí.

Te cuento lo que va a llevar, y sobre todo por qué, porque el criterio te sirve para juzgar a los otros cuatro aunque al final acabes con cualquiera de ellos:

• En dos tiempos: Primero la passkey como segundo factor, aprovechando entero el andamiaje del doble factor que ya está montado (pantalla intermedia, gestión en el perfil, dispositivos de confianza, perfiles obligados y periodo de gracia). Después el acceso sin contraseña, que es donde está todo lo caro y lo delicado.
• Una passkey con verificación de usuario cuenta como doble factor, y no se pide el código encima: Si la credencial no lleva verificación de usuario, entonces no cuenta y sigue haciendo falta el segundo paso.
• Aviso en la propia pantalla al activar el método: Te dirá si tienes XML-RPC o las contraseñas de aplicación abiertos, que es exactamente el agujero del que hemos hablado más arriba. De poco sirve que el plugin traiga los interruptores si no te avisa de que los tienes en la posición equivocada justo cuando importa.
• Cada credencial, etiquetada como sincronizada o atada al dispositivo en la lista del perfil: Esa información viene ya en la propia ceremonia, así que enseñarla no cuesta nada y te deja decidir a ti en lugar de decidir por ti.
• La contraseña sigue activa por defecto, y el modo solo passkey es opcional: Exigiendo tener dos credenciales registradas y reutiliza los códigos de respaldo que ya conoces. El administrador único no se queda fuera, por diseño.
• Nada de servicios externos ni de cuentas de terceros: La firma se verifica en tu propio servidor, sin librerías externas ni llamadas a nadie, y lo que se guarda en tu base de datos son claves públicas.

Esto último no es un adorno, y por eso lo pongo aquí y no en la ficha del plugin. Tu verás, yo solo te aviso, si un plugin de passkeys te pide crear una cuenta en algún sitio, lo que te está vendiendo no es una passkey, es un intermediario.

Qué necesita tu web para poder usar passkeys

Seguro que cumples, pero esta es la lista, para que no te lleves decepciones.

• HTTPS, obligatorio: Y no es una recomendación mía, es que el navegador no ejecuta la ceremonia en una web sin certificado. La única excepción es localhost, para que los que desarrollamos podamos hacer pruebas.
• Un dominio estable: Las credenciales se atan al dominio, así que el día que cambies de dominio todas las passkeys registradas dejan de valer y todo el mundo tiene que registrarlas otra vez. Si tienes una migración de dominio a medio plazo, haz la migración primero y las passkeys después.
• Extensiones de PHP, según el plugin: Algunos piden extensiones concretas para la parte criptográfica, y en alojamiento compartido de gama baja no siempre están activadas. Si el plugin te da error al registrar la primera credencial, mira eso antes de volverte loco.
• Multisitio, el punto flojo: Como la credencial se ata al dominio, en una red de subdominios una passkey registrada en una web de la red no sirve en las demás. La forma de arreglarlo pasa por atar la identidad de la red al dominio padre en lugar de al de cada web, y hay plugins que ya lo hacen usando la constante COOKIE_DOMAIN si la tienes definida. En una red de subdirectorios el problema no existe porque el dominio es el mismo para todas. Si administras multisitio, prueba esto en un clon antes de tocar la red buena.

Los entornos de pruebas se comportan distinto, porque el dominio es otro. Las passkeys que registres en el clon no te valen en producción, y al revés tampoco.

Cómo añadir passkeys en WordPress de manera segura y paso a paso

El orden de estos pasos no es decorativo, cada uno depende del anterior:

1. Cierra XML-RPC y revisa las contraseñas de aplicación existentes antes de tocar nada del acceso. Si no haces esto lo demás no sirve de nada.
2. Empieza por ti y por el resto de administradores, nunca por los usuarios. Y hazlo un día laborable por la mañana, no un viernes a las ocho de la tarde.
3. Registra dos credenciales por persona desde el primer momento, no una. La segunda es la que te salva.
4. Genera los códigos de respaldo y guárdalos fuera del ordenador, en el gestor de contraseñas o en papel dentro de un cajón, que sigue siendo un sitio estupendo.
5. Prueba la recuperación de verdad, con una cuenta de prueba a la que le quites el acceso a propósito. Un plan de recuperación sin probar no es un plan, es una intención.
6. Solo entonces amplía al resto del equipo, con periodo de gracia si tu plugin lo permite.
7. Y el modo sin contraseña, al final del todo, cuando lleves semanas con lo anterior rodado y sepas que todo el mundo tiene sus dos credenciales.

Sobre las políticas más estrictas, tipo obligar a los administradores a usar solo credenciales atadas al dispositivo, mi consejo es que no lo hagas salvo que sepas muy bien lo que estás montando.

El coste de esa política no es igual para todos: quien administre desde Windows la cumple gratis con Windows Hello, y quien administre desde un Mac o un iPhone se ve obligado a comprar una llave física.

Un mismo requisito que trata distinto a dos personas del mismo equipo es un generador de tickets de soporte, no una medida de seguridad. Y como decíamos antes, una política que depende de algo que la persona no elige conscientemente genera soporte, no seguridad.

Añade que todo esto depende del comportamiento del autenticador del sistema operativo, que puede cambiar con una actualización que ni has pedido ni controlas. Atar tu política de acceso a eso es construir sobre arena.

¿Y si algo sale mal?

Y aquí es donde el tipo de passkey que tenga cada uno lo cambia todo. Hay dos planes de recuperación distintos, no uno.

• Si la passkey es sincronizada, la pérdida del móvil no es una catástrofe, porque la credencial sigue en el llavero de tu cuenta y aparecerá sola en el aparato nuevo en cuanto inicies sesión. Tu riesgo real no es perder el trasto, es perder el acceso a la cuenta que sincroniza. O sea que lo que hay que proteger con uñas y dientes es esa cuenta, no el teléfono.
• Si la passkey está atada al dispositivo, y hablo de llaves físicas o de Windows Hello, el día que se rompe el portátil o se pierde la llave esa credencial ha muerto y no vuelve. Por eso lo de registrar dos, y por eso lo de que la segunda esté en otro trasto distinto y no en el mismo.

Los tres escenarios que te puedes encontrar:

• Cambio de ecosistema, del iPhone al Android o al revés: Las passkeys sincronizadas no cruzan de un llavero a otro con la alegría que a uno le gustaría, así que planifica el cambio antes de venderte el móvil viejo.
• El editor que se marcha: Sus passkeys viven en sus dispositivos, así que tú no puedes borrárselas del bolsillo. Lo que sí puedes es eliminar las credenciales registradas desde el perfil de usuario en tu web, que es lo que corta el acceso de verdad. Ponlo en tu proceso de baja de personal, junto a lo de siempre.
• El administrador único: Si eres el único administrador de tu web, no actives nunca el modo sin contraseña sin tener dos credenciales y los códigos de respaldo comprobados. Y si aun así te quedas fuera, siempre queda desactivar el plugin renombrando su carpeta desde el gestor de archivos de tu hosting, que es la salida de emergencia de toda la vida.

Preguntas rápidas

• ¿Las passkeys sustituyen al doble factor? Si llevan verificación de usuario, sí, porque ya son dos pasos por sí solas. No hace falta pedir además el código de la aplicación.
• ¿Puedo usar passkeys y seguir teniendo contraseña? Sí, y es lo normal y lo recomendable mientras te acostumbras. Ten claro que así el relleno de credenciales contra tu web sigue siendo posible.
• ¿Funcionan en el móvil? Sí, y de hecho es donde mejor van, porque la huella o la cara están ahí mismo.
• ¿Y si mis usuarios no tienen lector de huella? Sirve el PIN del dispositivo, y sirve una llave física por USB. Nadie se queda fuera por no tener biometría.
• ¿Sirven para los clientes de mi tienda? Sí, hay plugins que las llevan a las pantallas de cuenta de WooCommerce. Piensa antes en el coste de soporte, porque tus clientes no son tu equipo y la mitad no sabe qué es un llavero de iCloud.
• ¿Y si tengo la web en un alojamiento compartido normalito? Casi seguro que funciona. Comprueba que tienes HTTPS y mira los requisitos de extensiones del plugin que elijas.
• ¿Puedo obligar a que todos los administradores usen passkeys? Sí, los plugins con políticas por perfil lo permiten. Da un periodo de gracia y avisa antes, que si no te llueven los correos.

Por dónde empezar desde ya

Antes de tocar tu web, haz el ensayo con red entrando en tu perfil de WordPress.org, ahí ve a la pestaña de cuenta y seguridad, y registra una llave de seguridad. Se tarda medio minuto, es gratis y vas a entender en la práctica todo lo que te he contado aquí mucho mejor que leyéndolo otra vez.

Después, y ya en tu web, el primer paso no es instalar nada, es ir a comprobar si tienes XML-RPC abierto y qué contraseñas de aplicación hay creadas por ahí. Eso es lo que decide si tus passkeys van a servir para algo o van a ser un adorno caro.

Y si te has quedado con ganas de más sobre cómo se defiende el acceso a tu WordPress, tengo el plan de batalla contra los ataques de fuerza bruta, que es la capa de debajo de todo esto.

Ahora te toca a ti decidir en qué modo te quedas, si en el cómodo o en el valiente. Y si te lanzas al segundo, cuéntamelo en los comentarios, que me interesa mucho saber cuánta gente se atreve a apagar la contraseña de verdad.