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.

Ya está aquí el repaso de la semana, que entre el lunes y el miércoles ha dado para rato. El lunes toca #CrónicasWordPress, para ponernos al día de la actualidad y mojarme un poco, y el miércoles le llegó el turno al consultorio, que esta vez fue más de trucos que de dudas. Si te perdiste alguno de los dos directos, aquí te lo dejo masticado y con el enlace al vídeo entero al final de cada bloque.

Crónicas del lunes: seguridad para echarse a temblar y la IA a lo suyo

Empecé por seguridad, como casi siempre últimamente, porque la cosa no da tregua. Salieron a relucir varias vulnerabilidades en plugins muy instalados, de esos que tienes tú y tiene medio WordPress del planeta, así que ya sabes lo que toca, actualizar cuanto antes y no dejarlo para mañana.

Comenté el caso de un plugin de migración y copias de seguridad con un agujero de los serios, y los intentos de ataque que se están frenando estos días contra webs con Elementor. Si usas cualquiera de estos, para un momento y comprueba que estás en la última versión.

Y hubo un tema que me tocó la moral, y es que un plugin bastante conocido se dedicaba a generar contraseñas de aplicación por su cuenta, sin pedirte permiso, para mandarlas a sus servidores. Lo acabaron retirando, pero el susto queda. Eso no es un despiste, es meterte la mano en el bolsillo mientras miras para otro lado.

Después nos fuimos a las novedades, que también las hay. WordPress 7 sigue su camino con nuevas versiones a la vista y mejoras que van cayendo en el editor de bloques. No te suelto aquí cada número de versión porque para eso está el vídeo, pero la idea es que el proyecto se mueve y conviene tenerlo controlado.

Y llegamos al asunto del que no me canso de avisar, y es que la IA se está comiendo el tráfico de Google. Cada vez más búsquedas se resuelven con el resumen que sale arriba del todo y el usuario ni llega a pinchar en tu web. No es que Google se vaya a acabar mañana, seamos serios, pero si vives de las visitas de las búsquedas, esto va contigo y toca espabilar.

Lo comento con calma en el directo, con lo que yo estoy haciendo al respecto. También repasé alguna cosa más de la comunidad y un par de eventos que vienen, pero para no hacer esto eterno te remito al vídeo.

Aquí tienes la crónica completa, con todos los detalles, los enlaces y mi opinión sin filtro.

Ver las #CrónicasWordPress del lunes en YouTube

Doctor WordPress del miércoles: mis trucos favoritos del editor de bloques

El miércoles me lié la manta a la cabeza y, en lugar del consultorio de siempre, monté una sesión con los trucos del editor de bloques que más uso yo en el día a día. Nada de teoría rara, cosas que te ahorran tiempo desde el minuto uno. Estos fueron los que enseñé:

• El resumen del documento: el panel que te muestra el esquema con la lista de bloques, el número de palabras y el tiempo de lectura de un vistazo.
• La barra y el Markdown: escribes «/» para insertar cualquier bloque al vuelo, y trucos de Markdown como «##» para un encabezado o «>» para una cita, sin soltar el teclado.
• La vista de lista: tenerla abierta para moverte entre bloques anidados y reordenarlos sin volverte loco ni romper nada.
• La visibilidad por dispositivo: mostrar u ocultar un bloque en móvil, tablet o escritorio según te interese.
• Buscar y reemplazar dentro de los bloques: para cambiar un texto en toda la entrada de una vez, sin ir bloque por bloque a mano.

Y ya puestos, enseñé un par de plugins que uso para rizar el rizo, uno para controlar dónde se ve cada contenido y otro para alternar entre el editor clásico y el de bloques cuando la ocasión lo pide. Esta vez cayeron menos preguntas del público que otras semanas, así que quedó una sesión bien cargadita de práctica.

Tienes el directo entero, con las demostraciones paso a paso, aquí:

Ver el #DoctorWordPress del miércoles en YouTube

Nos vemos en el próximo directo

Y hasta aquí la semana. Te recuerdo que los directos son en abierto, los lunes las crónicas y los miércoles el consultorio, así que si tienes cualquier duda de WordPress, SEO, IA o casi de lo que sea, te vienes y preguntas sin cortarte. Nos leemos en los comentarios, aquí abajo, y no te pierdas ningún directo suscribiéndote al canal oficial de Ayuda WordPress en YouTube.

Así que me recogí la coleta, pillé ocho plugins, The SEO Framework, Visibility, SureRank, Slim SEO, SEOPress, Yoast SEO, AIOSEO y Rank Math, además de Visibility, los instalé uno por uno en la misma instalación de WordPress y medí memoria, consultas a la base de datos, tiempo de generación y peso de archivos, siempre con el mismo contenido exacto.

Si quieres el detalle completo de cómo lo hice, lo tienes al final del artículo, primero vamos a ver los números, tabla por tabla, luego me cuentas…

Lo que le cuesta a tu web servir una sola entrada

Esto es lo que añade cada plugin sobre una instalación sin ningún ajuste SEO activo, que en una entrada suelta se queda en 10,83 MB de memoria, 58 consultas y 25,6 ms. Cada fila es la diferencia contra esa base.

Cuando ves la tabla entera pasan dos cosas que no esperaba…

1. Hay dos plugins, Visibility y The SEO Framework, con los que WordPress hace menos consultas a la base de datos que si no tuvieras ningún plugin de SEO instalado, consultas negativas de verdad, no es un error de la tabla. Lo que pasa es que ambos desactivan consultas que WordPress lanza por defecto y que ninguno de los dos necesita, eso ya es hilar fino.
2. Y luego está la sorpresa para muchos, porque resulta que Rank Math añade trece veces más memoria que los más ligeros para servir exactamente la misma página, con el mismo contenido y el mismo tema. En un hosting compartido con la memoria justa, o en una web con tráfico importante, esa diferencia se multiplica por cada visita simultánea, no es un número que se quede solo en la tabla, y me parece una burrada.

Si te fijas en el orden de la tabla no es aleatorio. Los tres plugins que menos añaden, The SEO Framework, Visibility y Slim SEO, son también los tres que menos hacen por su cuenta, sin asistente de configuración, sin paneles de análisis en tiempo real, sin llamadas a servicios externos.

Los que más consumen, Rank Math y AIOSEO, son también los que más funciones traen activadas por defecto. Pesar más no sale gratis, y tampoco es casualidad.

El editor de bloques también se resiente, y bastante

Publicar y editar también es rendimiento, aunque solo lo note quien escribe. Con esa misma entrada abierta en el editor de bloques, esto es lo que añade cada plugin:

Fíjate en AIOSEO, 85 consultas más solo por tener la entrada abierta en el editor, y en Rank Math, que suma 7,21 MB y casi 60 milisegundos por carga.

Los dos comparten algo, un panel lateral que analiza el contenido mientras escribes y recalcula una puntuación con cada pulsación. Ese análisis en directo es justo lo que más memoria y consultas consume, y es opcional lo mires como lo mires.

Si publicas cuatro entradas al año no lo vas a notar nunca. Ahora bien, si en tu web escriben varios autores a diario, o si ya te has preguntado alguna vez por qué el editor va lento cada vez que pulsas una tecla, esta tabla es la respuesta más clara que vas a encontrar.

Visibility y The SEO Framework son los dos únicos que además cargan el editor más rápido que sin ningún plugin de SEO activo, y eso solo tiene una explicación, que ninguno de los dos monta ese panel de análisis en directo. Si lo echas de menos, esto no es para ti, y si nunca lo has usado acabas de ahorrarte varios megas por sesión de escritura sin perder nada.

Lo que se queda instalado en tu WordPress … para siempre

Lo que un plugin deja en tu instalación en cuanto lo activas, tablas propias, eventos de cron, opciones que se leen en cada petición aunque no tengan nada que ver con el SEO, es otra letra pequeña que casi nadie mira antes de instalar.

Slim SEO y Visibility son los dos plugins más ligeros en disco de los ocho, y comparten algo más importante todavía, que ni uno ni otro crea una tabla ni un evento de cron.

La diferencia, y la razón por la que Visibility puede decir que es el único de los ocho sin ninguna llamada a un servidor externo, no sale en esta tabla, sale al mirar el código, que también he publicado para quien quiera comprobarlo por su cuenta.

Las opciones con autoload son la columna que menos se mira y la que más pesa de verdad, porque WordPress las lee enteras en cada petición a tu web, tenga que ver con el SEO o no.

Rank Math pone en carga automática 10,4 KB repartidos en 15 opciones distintas, y eso se lee igual en tu portada, en tu tienda o en la página de contacto, aunque ninguna tenga una palabra clave que analizar.

Y luego está el cron. Cada evento programado depende de que alguien visite la web para dispararse, lo que en una web con poco tráfico puede acumular tareas pendientes sin que nadie se entere.

Rank Math programa 3 eventos propios, Yoast 2 y SureRank 1. Los otros cinco, Visibility incluido, no programan ninguno.

Pesar menos solo vale la pena si haces lo mismo o casi. Sobre esa misma entrada que generé para las pruebas, los ocho emiten etiquetas Open Graph, marcado JSON-LD, url canonical y meta description, aunque con dos excepciones que merece la pena anotar.

SEOPress no publica JSON-LD con los ajustes por defecto (este ha sido una de mis mayores decepciones recientes), y Yoast no escribe meta description si no se la escribes tú a mano o lo configuras la plantilla de extracto automático.

El resto va prácticamente empatado en lo que entrega, así que en esta tabla no hay nada que justifique tanta diferencia de peso entre unos y otros. Lo que hace cada uno es casi lo mismo, lo que cuesta hacerlo no.

Dónde no gana Visibility (cachislamar) y me lo apunto como tareas de mejora

Me toca reconocerlo, qué le vamos a hacer, que los datos son para eso, y aquí no hay maquillaje ni cocina. En memoria de portada y de entrada individual, The SEO Framework queda por debajo de Visibility. Slim SEO ocupa algo menos en disco (892 KB frente a 971 KB) y autocarga muchísimo menos (7 bytes frente a 3,3 KB).

Pero vamos, que ya me conoces, ya le estoy pasando la lija, poniendo a dieta y en nada esas tablas van a cambiar y mucho. Lo que más me gusta de ponerme a prueba es precisamente eso, que son retos, y me encanta aprender para mejorar.

¿Y con esto qué hago si voy a instalar un plugin de SEO? ¿me fío? ¿sirve de algo?

Aquí no te voy a decir que instales Visibility porque lo haya desarrollado yo, para eso ya tienes el enlace de descarga un poco más abajo si te apetece probarlo.

Te digo lo de siempre, lo que llevo defendiendo más de 20 años, que el problema nunca es cuántos plugins metes en tu WordPress, el problema es meter código que no vas a usar.

Si tu plugin actual te resuelve lo que necesitas y no te está comiendo media instalación no tienes ningún motivo para cambiar. Si en cambio llevas tiempo notando que el editor va a pedales o que tu hosting anda canino de memoria, ya sabes en qué tabla mirar antes de decidir.

Y luego está ese otro debate del que usted me habla, el de que si sirven de algo actualmente los plugins de SEO, por si te apetece seguir con la juerga.

Metodología de la comparativa de rendimiento de plugins SEO

Todo esto sale de un plugin propio que solo se instala para hacer las mediciones, nunca en una web real, y que expone varios pasos protegidos por una clave para que nadie más pueda tocarlo.

Antes de cada tanda genera la entrada de prueba siempre igual (1.169 palabras, extracto escrito a mano, imagen destacada, encabezados, una lista y un bloque de detalles), para que el contenido nunca sea la variable que cambia entre un plugin y otro.

Después cambia el plugin activo, desactiva los otros siete y activa solo el que toca, dejando que sus rutinas de instalación se ejecuten como en cualquier instalación nueva, con sus tablas, sus opciones y su configuración de fábrica. Nada de activaciones silenciosas que se salten esos pasos, porque eso habría falseado buena parte de lo que has leído más arriba.

Es todo un bicho, y actúa prácticamente sin intervención humana (tienes las instrucciones en el zip que te he puesto abajo), más o menos, por resumirte, funciona así:

• Con el plugin activo pide la portada, la entrada y el editor las veces que corresponda, y en cada carga anota memory_get_peak_usage() para la memoria, get_num_queries() para las consultas y un cronómetro para el tiempo.
• Para saber qué código PHP entra a ejecutarse de verdad, compara get_included_files() antes y después de cada petición, así que la cifra de PHP cargado no es lo que el plugin ocupa en el disco, es lo que tu servidor ha tenido que leer para servir esa página en concreto.
• Para la huella que deja instalado mira SHOW TABLES para las tablas propias de cada plugin, _get_cron_array() para sus eventos de cron y las opciones autocargadas con su peso en bytes.
• Para el peso del editor y de la portada, suma lo que cada plugin encola con wp_scripts() y wp_styles(). Cada petición queda anotada en un registro en bruto, y de ahí sale la mediana que ves en las tablas, no la mejor marca ni una media que un solo pico podría desviar.

Entorno y procedimiento

• WordPress 7.0.2, PHP 8.5.3, MySQL 8.4, tema GeneratePress, límite de memoria de 256 MB y sin caché de objetos externa. Instalación local, con WooCommerce activo y cuatro plugins pequeños más, los mismos en los ocho escenarios, para que ningún plugin de SEO compitiera contra una instalación desnuda que no representa una web real. Medido el 29 de julio de 2026.
• Portada y entrada individual pedidas 10 veces como visitante anónimo, mediante peticiones que el propio servidor se hace a sí mismo, descartando antes una carga de calentamiento. El editor de bloques, que solo se puede abrir con sesión de administrador, se abrió 4 veces con esa entrada cargada.

Dos plugins necesitaron un empujón antes de arrancar, todo hay que decirlo, y es que Rank Math y SEOPress no publican nada hasta completar sus rutinas de instalación, y Rank Math ni siquiera pinta una etiqueta hasta que terminas su asistente. Lo completé aceptando todos los valores que traía por defecto, sin conectar ninguna cuenta ni importar nada de otro plugin.

El contraste con Query Monitor, y el susto de AIOSEO

Todo lo anterior está medido sin Query Monitor, porque este plugin, por otra parte encantador, tiene una pega, y es que guarda cada consulta que registra y eso también consume memoria.

Con sesión de administrador y Query Monitor activo los números suben para todos por igual, y la instalación sin ningún plugin de SEO pasa de 10,83 MB y 58 consultas a 13,7 MB y 72. El orden entre plugins no cambia, así que las cifras de las tablas anteriores se tomaron sin él.

Uso Query Monitor aquí a propósito, porque no es mío ni de nadie del sector. Es la herramienta que cualquier desarrollador de WordPress usa para diagnosticar estos mismos números, así que si desconfías del medidor propio, tienes el mismo resultado visto con otro instrumento.

Con Query Monitor activo, Visibility genera la página en 0,05 segundos, más rápido que la instalación sin ningún plugin de SEO, que tarda 0,08 s

Y el contraste tiene su propio susto, porque en esa misma situación AIOSEO tarda 0,31 segundos, seis veces más que Visibility y casi cuatro veces más que no tener ningún plugin de SEO instalado.

Compruébalo por tu cuenta: datos abiertos ¿se decía así no?

Todo lo que has leído sale de 216 mediciones concretas, no de una sensación. Puedes descargar el medidor que las ha tomado, con el registro completo y el CSV agregado de mis pruebas, lo tienes en visibility.quest/assets/bench/ayudawp-bench.zip, para no tener que fiarte de mi palabra ni de la de nadie.

La comparativa completa, con las cuatro tablas y el contraste con Query Monitor, está en visibility.quest/es/comparison.html.

Si usas alguno de los otros ocho plugins, ya tienes tus números ahí, para bien o para mal. Y si te apetece debatirlo, o contarme cuál usas tú y por qué, me tienes ahí abajo, en la sección de comentarios.

Pero, eso sí, que mientras tanto el que llegue de Google se encuentre una página de espera decente, y no una tienda a medias con tres productos de prueba con textos Lorem Ipsum.

Pues no necesitas ningún plugin para eso, WooCommerce lo trae de serie desde hace tiempo y casi nadie sabe que está ahí.

Y lo que menos gente sabe todavía es que la página de espera que te enseña por defecto puedes cambiarla entera por la tuya.

Vamos a verlo, que se hace en un par de minutos.

Dónde cambiar la visibilidad de WooCommerce

En el escritorio, «WooCommerce → Ajustes → Visibilidad del sitio». Es una pestaña más, al lado de las de siempre, y tiene dos opciones:

• Visible: la tienda está abierta, lo habitual.
• Próximamente: quien no tenga permisos ve una página de espera.

Debajo hay una casilla para restringirlo solo a las páginas de la tienda, y un interruptor para generar un enlace con clave y poder enseñar el sitio a quien tú quieras, ahora vemos las dos cosas.

Por cierto, si acabas de instalar WooCommerce y te está pasando que en la parte visible enseña una página de «próximamente» aunque tu tema esté perfecto, no te vuelvas loco revisando plantillas, las tiendas nuevas vienen con esto activado por defecto.

Es esa pantalla, no tu tema, y es de esas cosas que te hacen perder una tarde buscando el fallo donde no está.

Quién ve la tienda y quién ve el cartel de próximamente

La regla es simple, ve la tienda quien tenga la capacidad manage_woocommerce, o sea, administradores y gestores de tienda. Todos los demás ven la página de espera, incluidos tus suscriptores y tus clientes registrados.

Eso es útil para que tú y el cliente entréis con vuestro usuario y veáis la web como va quedando, sin trucos ni URLs raras.

¿Y si quieres enseñársela a alguien que no tiene usuario? Pues para eso está el enlace para compartir de esa misma pantalla.

Genera una URL con una clave al final, del tipo tudominio.com/page_id=8804&woo-share=laclave, y quien la abra deja de ver la página de espera durante noventa días, porque WooCommerce le pone una cookie.

Muy práctico para el diseñador, el fotógrafo o tu socio, que no tienen por qué tener cuenta en la tienda.

Si la clave se te va de las manos y acaba circulando por ahí, la cambias en esa misma pantalla y las cookies antiguas dejan de valer.

Toda la web o solo la tienda

La casilla de restringir a las páginas de la tienda hace exactamente lo que dice, y la diferencia importa más de lo que parece:

• Sin marcar: se tapa el sitio entero, portada incluida. Es lo que quieres cuando estás montando la web desde cero.
• Marcada: el blog, el «quiénes somos» y el resto de páginas siguen visibles, y solo se tapan la tienda, las fichas de producto, el carrito y el pago. Es lo que quieres cuando ya tienes una web viva y le estás añadiendo la parte de tienda, o cuando cierras la venta unos días por vacaciones y no te apetece apagar la web.

Cómo cambiar la pantalla de próximamente de WooCommerce

Aquí viene lo bueno, porque resulta que la página que enseña WooCommerce por defecto está bien para salir del paso, pero es genérica. ¿Y eso es bueno? … esperaaaa, que ahora viene…

Por dentro, WooCommerce no genera nada inamovible, simplemente carga la plantilla coming-soon con la función de WordPress get_query_template(), y eso lo genera tu tema.

Si usas un tema de bloques creas el archivo templates/coming-soon.html dentro de la carpeta del tema (o del tema hijo). Con eso ya lo tienes, aparece en «Apariencia → Editor → Plantillas» y se edita con bloques, como cualquier otra.

Ahí puedes poner tu logotipo, tu tipografía, tus colores, la foto de tu local, el mapa, el formulario de avisos, lo que quieras.

Si usas un tema clásico el archivo es coming-soon.php en la raíz del tema, y ahí mandas tú con PHP.

Por cierto, los archivos .html de las plantillas de un tema de bloques no ejecutan PHP.

Si tu página de espera necesita PHP (sacar el logotipo de los ajustes, pintar iconos SVG, leer una opción), el contenido va en un patrón, dentro de patterns/, y la plantilla se limita a llamarlo:

<!-- wp:pattern {"slug":"tutema/proximamente"} /-->

Los patrones sí son PHP y sí se ejecutan. La plantilla queda en una línea y el contenido se puede editar igual desde el editor.

Dónde se almacenan los ajustes de visibilidad de la tienda de WooCommerce

Para quien mire la base de datos o tenga que migrar la tienda de sitio, esto son cuatro opciones en la tabla de opciones:

• woocommerce_coming_soon: yes o no, el interruptor principal.
• woocommerce_store_pages_only: la casilla de restringir a la tienda.
• woocommerce_private_link: si el enlace para compartir está activo.
• woocommerce_share_key: la clave de ese enlace.

Te lo cuento sobre todo porque si migras una tienda y de repente el sitio nuevo aparece cerrado, mira esas opciones antes de ponerte a revisar el tema.

Otros ajustes a vigilar con la tienda en estado de próximamente

No es un 503, es un 200. La página de espera se sirve como una respuesta normal, con una cabecera de caché corta de un minuto.

Eso está bien pensado para una tienda que va a abrir (no quieres que Google entienda que tu web se ha caído), pero significa que si dejas la web en «próximamente» meses, Google puede indexar esa página de espera.

Mientras estés montando la tienda deja también marcado el «Pedir a los motores de búsqueda que no indexen este sitio» de «Ajustes → Lectura», y lo quitas también el día de la apertura.

Y si tienes caché de página en el hosting, tu plugin de optimizaciones, o un CDN por delante, puede darse el caso de que un visitante reciba la versión cacheada de la tienda, o que tú, con tu sesión abierta, sigas viendo la página de espera.

Cada vez que enciendas o apagues esto, vacía la caché y compruébalo en una ventana de incógnito. Es la única forma de ver lo que ve un visitante de verdad.

Los correos y los pedidos siguen funcionando, porque estos ajustes de visibilidad tapan el escaparate, no apagan la tienda. Así que si tienes pedidos antiguos, suscripciones o tareas programadas, siguen funcionando de fondo. No es un cierre técnico, es una cortina.

Para qué NO sirven los ajustes de visibilidad de WooCommerce

Si lo que necesitas no es tapar el escaparate sino cerrar de verdad (una migración, restaurar una copia, un cambio de dominio, esas dos horas en las que no quieres que nadie compre ni te mande un formulario), esto no es lo tuyo, porque la web sigue funcionando entera por detrás.

Para eso está el archivo .maintenance de WordPress, que corta la ejecución antes de cargar nada y devuelve un 503 honesto. Lo tengo contado con las mejoras que le faltan al método clásico en este otro artículo.

Para recordar…

1. WooCommerce → Ajustes → Visibilidad del sitio, marcas «Próximamente» y guardas.
2. Decides si tapas el sitio entero o solo la tienda con la casilla de debajo.
3. Si alguien de fuera tiene que verlo, activas el enlace para compartir y le pasas esa URL.
4. Creas templates/coming-soon.html en tu tema (o coming-soon.php si es clásico) y montas la página de espera que quieras.
5. Marcas «Pedir a los motores de búsqueda que no indexen este sitio» en Ajustes → Lectura mientras dure la tarea.
6. Vacía cachés y lo miras en incógnito.

El día que abras, deshaces los pasos 1 y 5 en ese orden, compruebas que la tienda responde y a correr.

Si lo has montado de otra forma, o has hecho algo curioso con la plantilla coming-soon de tu tema, cuéntamelo en los comentarios, que estas páginas de espera dan mucho juego y casi siempre se despachan con un logotipo centrado y poco más.

Pues bien, he publicado una actualización que cambia ese comportamiento por completo, incluso la filosofía. Y voy a ser sincero contigo, el cambio no es solo del plugin, es mío.

Qué (me) ha cambiado, con fechas y todo

El plugin, desde la versión 2.2.0, añade una pantalla de ajustes completa en «Ajustes > No Gutenberg», con un interruptor maestro para quien quiera el comportamiento de siempre.

Pero hay novedades, porque si desactivas el interruptor principal, debajo asoman reglas independientes por tipo de contenido, por perfil de usuario, por plantilla de página y por entradas concretas.

También añade el cambio de editor entrada por entrada, un panel de estado que resume qué está pasando de verdad en tu sitio, y tres constantes de wp-config para fijar toda la configuración por código, algo que ya te conté con detalle en la guía del editor clásico en multisitio que publico junto a este artículo.

Ahí también hay algo más pequeño pero, para mí, más importante: protección automática del contenido que ya está construido con bloques. Una entrada que ya tiene bloques conserva el editor de bloques pase lo que pase con tus reglas, salvo que marques explícitamente lo contrario.

De paso, la lista de entradas del escritorio ahora indica qué editor usa cada una, con un enlace para ver solo las que ya están construidas con bloques. Ah, también te permite (re)activar los widgets clásicos, por si te quieres ahorrar otro plugin, y tal.

Y si te preguntas si esto te va a romper algo al actualizar, la respuesta es que no, los ajustes por defecto reproducen el comportamiento de siempre, así que ninguna instalación existente cambia de comportamiento sin que tú lo decidas.

Lo que de verdad me hizo cambiar de idea

Aquí viene la parte que no sale en el registro. Si activabas No Gutenberg antes de la 2.3.0 en un sitio que ya tenía entradas montadas con bloques, esas entradas se mandaban igualmente, a la brava, al editor clásico.

Con el puñetero código de los bloques a la vista, sin maquetación, hecho un desastre. El plugin no distinguía entre «esta entrada nunca ha visto un bloque» y «esta entrada es un bloque detrás de otro con cuidado», y las trataba igual.

Ahí es donde caí en la cuenta de que llevaba años resolviendo mi propio problema y dando por hecho que era también el tuyo.

Mi problema era que no quería ver el editor de bloques. El tuyo, si tenías contenido ya creado con blouqes, era no perder ese trabajo por instalar mi plugin.

Son dos problemas distintos, y durante ocho años los traté como si fueran el mismo, total nada, desde 2018.

Mi queja nunca fue Gutenberg o los bloques, era no poder elegir

Y aquí toca hacer autocrítica, más o menos.

Llevo años criticando el editor de bloques con dureza, y sigo pensando que buena parte de esa crítica está justificada. Pero en realidad, si me conoces ya sabrás que mi queja de fondo nunca fue que el editor de bloques existiera, sino que no había forma sencilla de decidir dónde sí y dónde no.

Te lo digo yo, que también llevo defendiendo años el uso el editor de bloques como maquetador siempre que puedo, a pesar de que todavía le faltan cosas para estar a la altura de un Divi o un Elementor.

Y lo uso a propósito, no a pesar de mi postura sobre Gutenberg, sino precisamente por ella. Es la pieza más cercana que tiene WordPress hoy a ese maquetador nativo que llevo años pidiendo, para no depender de un plugin de terceros solo para maquetar una portada o una landing.

Lo que nunca he defendido es que ese mismo maquetador sea la herramienta obligatoria para escribir una entrada de blog. Ahí no hace falta maquetar nada, hace falta escribir, y son dos trabajos distintos que llevan mal metidos en la misma pantalla desde 2018.

No Gutenberg, durante un montón de años ha resuelto eso a su manera, cerrando la cocina entera del restaurante porque había un plato del menú que no me convencía. Lo lógico siempre fue quitar ese plato, no echar el cierre a todo el local.

También aplica exactamente esta misma lógica a WooCommerce, que hasta ahora era otro interruptor de todo o nada dentro del propio plugin.

Páginas y sitio sí, entradas no, o mejor dicho, que cada cual elija

Esta distinción no es solo una manía mía. Está en la propia arquitectura de WordPress. Las plantillas de un tema de bloques, las que usa el editor del sitio para maquetar toda la web, ni siquiera pasan por la pantalla clásica de editar entradas, tienen su propia aplicación, separada, pensada de raíz para maquetar.

WordPress ya sabe que maquetar un sitio y escribir una entrada son tareas distintas. Lo que nunca ha ofrecido es una forma cómoda de aplicar ese criterio también a las entradas y páginas normales sin tocar código.

Eso es exactamente lo que hace ahora No Gutenberg: bloques para páginas y para el sitio, si quieres, y editor clásico para entradas, si es lo que prefieres, sin que sea una decisión de todo o nada para todo el contenido a la vez.

Por qué esto es importante sobre todo a agencias y redacciones

Si trabajas solo esta discusión es casi filosófica, activas lo que te apetezca y ya está, pero si gestionas una web con varios redactores, o llevas clientes desde una agencia, la falta de elección deja de ser una molestia personal y se convierte en un problema real de flujo de trabajo.

Un redactor que solo quiere escribir y publicar no necesita ver patrones, columnas ni estilos globales, necesita un cuadro de texto que no se interponga.

Y un diseñador o un administrador maquetando la home sí necesita todo eso. Antes tenías que elegir un único comportamiento para todo el mundo y todo el contenido.

Ahora puedes decir si editor clásico para el perfil de redactor, bloques disponibles para administrador y editor, y bloques siempre en páginas, con las reglas por perfil y por tipo de contenido.

Es la diferencia entre imponer una preferencia y ofrecer una herramienta.

Qué no cambia si ya usas el plugin

Si ya tenías No Gutenberg activo actualizar no te va a cambiar nada lo que ya tenías. El interruptor maestro sigue ahí, y con la configuración por defecto el plugin se comporta exactamente igual que antes de la 2.2.0.

Lo único nuevo es que, si quieres, ahora puedes afinar. No hay letra pequeña ni cambio de comportamiento silencioso, y si algo he defendido siempre es que las novedades se cuenten así de claras, sin meterte prisa ni miedo para que actualices.

Para quién es este cambio, y para quién no

Si administras un solo sitio para ti, para tu propio uso, y tienes clarísimo que no quieres ver un bloque en tu vida, el interruptor maestro sigue a un clic de distancia, exactamente igual que en la versión anterior (no, no te va a caer ninguna notificación insistiendo para que cambies nada). Este cambio no te obliga a nada.

Es para quien administra contenido de otros, para clientes, redactores, equipos completos, y necesitaba desde hace tiempo algo más fino que un único interruptor para todo el sitio.

Si esa eres tú, la pantalla de ajustes nueva es motivo suficiente para actualizar hoy mismo.

Y ahora, la parte que te toca a ti

Si administras un solo sitio y quieres perfilar quién ve qué editor, la nueva pantalla de ajustes de No Gutenberg? es el sitio por el que empezar. Si administras una red completa, tienes un tutorial de cómo usar el editor clásico en multisitio con las tres formas que funcionan de verdad, plugin, código y constantes de wp-config incluidas.

Y si después de leer esto sigues pensando que lo mío es una excusa para no reconocer que el editor de bloques está bien como está, para todo y para todos, no estamos de acuerdo, y ahora ya sabes por qué. Pero vamos, que lo debatimos por ahí abajo, en los comentarios.

A mí me llegó hace unos días, haciendo referencia a mantenimiento.ayudawp.com, y mi primera reacción fue la típica, pensar que era publicidad de servicios de seguridad disfrazada de aviso técnico.

Y el caso es que no vendía nada, y venía de un Gmail corriente, sin firma de empresa ni nada que oliera a comercial.

Llevo como 20 años metido en seguridad de WordPress, y aun así el correo me hizo dudar un segundo.

Vamos a ver qué me encontré, porque la cosa tiene su miga, y es que el aviso tenía razón en lo técnico y aun así era una encerrona.

Esto es lo que decía el correo

El asunto decía, tal cual, «Security Advisory: Deprecated TLS Protocol & Weak Ciphers Enabled on …». Si te ha llegado uno con ese mismo patrón, con tu dominio en vez del mío, es la misma plantilla.

Va dirigido a un altisonante «Security Team», lo firma un no menos rimbombante «Security Research Team» (que suena a mucho y no tiene porqué ser nada), y apunta directo a mantenimiento.ayudawp.com:443. Esto es, resumido y sin la parafernalia de separadores que traía de verdad, lo que contaba:

Finding: weak-cipher-suites:tls-1.0, severidad low según su propia herramienta.

Impacto según ellos: ataques de hombre en el medio con caída de protocolo (citaban POODLE y BEAST), robo de cookies de sesión por los cifrados CBC, e incumplimiento de PCI-DSS 3.2.1.
Cómo comprobarlo: openssl s_client -connect mantenimiento.ayudawp.com:443 -tls1
Solución que proponían: bloques de configuración para Nginx y Apache forzando TLS 1.2 y 1.3.
Firmado, cómo no, «Security Research Team».

Ni una empresa detrás, ni un nombre, ni una vía de contacto que no fuera ese mismo Gmail.

Con esto ya tenía motivos de sobra para desconfiar, pero antes de mandarlo a la papelera quise comprobar si lo técnico se sostenía.

Cómo comprobarlo sin fiarte de nadie

Lo primero que hice fue lo que proponía el propio email, lanzar el comando que te copio arriba, y me dio un error de No protocols available, como si el servidor hubiera colgado la llamada.

Aquí viene la primera trampa, y le puede pasar a cualquiera que use OpenSSL 3, que es la versión que trae cualquier Linux o Mac reciente.

Por defecto OpenSSL bloquea TLS 1.0 antes de intentar siquiera la conexión. Ese error solo dice que tu OpenSSL ha decidido no probarlo, y no aporta ningún dato real sobre el servidor.

Para forzar la prueba real hay que añadir -cipher 'ALL:@SECLEVEL=0', que baja el nivel de seguridad exigido por la librería, solo entonces la respuesta viene de verdad del otro lado.

Y hay una segunda trampa, más traicionera todavía si le pides el favor a una IA. Muchos entornos con salida a internet, ya sea un proxy corporativo o el sandbox de un asistente, interceptan el TLS y sirven su propio certificado en vez del tuyo, si la comprobación te sale limpia a la primera, desconfía, porque puede que estés midiendo ese proxy y no tu web de verdad.

La forma fiable de comprobarlo sin estos líos es un escáner externo, y el de referencia es el de Qualys, SSL Labs. Y ahí el resultado fue claro, nota B, con TLS 1.0 y 1.1 activos de la mano de 1.2 y 1.3, y el cifrado exacto que citaba el correo, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, en eso no mentían.

Lo real y lo inflado

El remitente, por muy oportunista que sea, en lo técnico del correo todo era cierto. Tu web puede tener TLS 1.0 abierto ahora mismo y tú sin enterarte, así que no lo despaches solo por venir de un Gmail sin firma. Pero el resto del correo estaba inflado a base de bien.

No hay riesgo real de POODLE (el ataque de 2014 que explota los cifrados en bloque antiguos), ni en su variante clásica ni en la variante para TLS, porque el escáner lo marca expresamente como no vulnerable en ambos casos.

Tampoco hay downgrade posible, porque el servidor tenía activo TLS_FALLBACK_SCSV, que es justo el mecanismo pensado para impedir que un atacante fuerce la caída a un protocolo antiguo. El correo describía un ataque que su propio hallazgo desmentía.

BEAST sale marcado, sí, pero es un ataque de 2011 contra el navegador, no contra el servidor, y todos los navegadores actuales lo mitigan desde hace más de una década. Ningún visitante con Chrome, Firefox, Safari o Edge de este siglo lo va a sufrir.

Y la referencia a PCI-DSS 3.2.1 es, directamente, una plantilla vieja. esa versión se retiró el 31 de marzo de 2024, y el estándar vigente desde entonces es la 4.0.1.

Nada de RC4, nada de Heartbleed, nada de Logjam, y forward secrecy completa. El único motivo real de la nota B era tener TLS 1.0 y 1.1 abiertos, y punto.

Qué es un Beg Bounty (y por qué WordPress es el blanco favorito)

Esto tiene nombre y lleva ya varios años documentado en el sector, pues es un fenómeno que le pasa hasta a las webs más pequeñas. Se llama Beg Bounty, algo así como pedir recompensa.

El término lo acuñaron Michael Argast y Chester Wisniewski, de Sophos, después de toparse con un aluvión de correos parecidos.

Quien más lo popularizó fue Troy Hunt, el creador de Have I Been Pwned, que describe el método como seleccionar tu dominio, pasarlo por herramientas gratuitas de apuntar y disparar como SSL Labs, dmarcian o Security Headers, y pegar lo que sueltan en una plantilla de aviso «grave».

Todo hay que decirlo, el término se puede usar en sentido peyorativo, como te acabo de comentar, o como estrategia buscada, pues hay empresas que incluso promueven esto del Beg Bounty, pero al estilo de recompensas a hackers éticos por informar (responsablemente y sin alarmismo) de problemas de seguridad reales, y en realidad se le llama Bug Bounty, casi lo mismo.

¿Y por qué le toca precisamente a WordPress? Pues porque es uno de los CMS más escaneados del planeta, gracias a su cuota de mercado.

Cualquier bot que rastree direcciones IP se topa antes o después con un wp-login.php o un wp-json, y eso ya delata el CMS y activa el aviso automático.

Y aquí llega el detalle que más rabia me dio, todo hay que decirlo, y es que las IP que contestaban en el escaneo eran de Cloudflare.

El TLS se corta en su servicio, no en mi hosting, que es tanto como decir que quien te abre el portal del edificio no es quien vive en el piso, así que los bloques de configuración para Nginx y Apache que me mandaban de regalo no servían para nada, porque ahí no hay ningún puñetero Nginx mío que tocar.

Y hay una ironía todavía mayor, y es que Cloudflare fija TLS 1.0 como mínimo por defecto para todos sus clientes con cifrado por certificado. Este descubrimiento, sin saberlo, lo cumplen millones de webs que usan Cloudflare y nunca han tocado ese ajuste.

Lo que te van a encontrar sí o sí

Si mantienes webs WordPress esto te va a sonar, es casi siempre el mismo puñado de hallazgos, y vale una misma plantilla:

Fíjate en la última fila, un DMARC flojo (el registro que evita que cualquiera pueda enviar correos fingiendo ser tu dominio) sí permite que alguien mande phishing haciéndose pasar por ti, con tu reputación de por medio.

Todo lo demás de la tabla es ruido de fondo que cualquier escáner automático encuentra en la inmensa mayoría de las webs con WordPress, tengan la seguridad que tengan.

Y si quieres una prueba de que ni el propio proyecto WordPress se toma en serio media lista, tienes el programa de recompensas de WordPress en HackerOne.

Descarta de entrada cualquier fallo con una puntuación CVSS (la escala que mide la gravedad de una vulnerabilidad, de 0 a 10) por debajo de 4, y rechaza de forma explícita los avisos sobre disponibilidad de XML-RPC que no vengan acompañados de una prueba de impacto real.

Cómo distinguir un aviso real de un intento de sablazo

La mayoría de estos correos son escaneos que alguien pega tal cual en una plantilla, sin más ánimo que cobrarte por algo que podrías haber mirado tú mismo con las mismas herramientas gratuitas. La mala fe empieza cuando de por medio hay presión de pago sin pruebas, o urgencia prefabricada.

Señales de que el aviso va en serio:

• Viene de una empresa identificable, no de un correo personal random.
• Incluye una prueba que demuestra impacto real, no solo la salida en bruto de una herramienta.
• No pide dinero por adelantado ni condiciona los detalles a que pagues antes.
• Ofrece coordinar la publicación con calma, sin plazos inventados.

Señales de que van a por tu cartera:

• Gmail u Outlook personal, sin dominio propio ni nombre real detrás.
• Saludo genérico tipo «Dear Security Team», firmado por un remitente igual de genérico.
• El hallazgo es justo el que su propia herramienta etiqueta como low, mientras el texto habla de robo de sesiones y normativas incumplidas.
• Meten prisa con plazos de 24 o 48 horas, o piden pasar por caja antes de contarte nada más.

El mío pecaba en tres de las cuatro señales malas, y no tenía ni una de las buenas.

¿Tienes que hacer algo ya mismo?

Aunque el correo sea un sablazo disfrazado, el ajuste de fondo conviene hacerlo, y si usas Cloudflare te lleva literalmente medio minuto:

1. Entra en el panel de Cloudflare, en tu dominio.
2. Ve a SSL/TLS → Edge Certificates → Minimum TLS Version.
3. Súbelo a TLS 1.2. La propia documentación de Cloudflare desaconseja ir más allá, porque a partir de ahí empiezan los problemas con rastreadores y navegadores viejos.

Además conviene activar el HSTS en ese mismo panel, que obliga al navegador a usar siempre HTTPS y protege contra un ataque bastante más real que el BEAST que te van a citar, el SSL stripping.

Y si lo que te llega es más extorsión que aviso, la respuesta correcta es ninguna respuesta. Contestar solo confirma que la dirección está viva, y lo normal es que el segundo correo ya venga con la tarifa por delante.

Que esto lo vigile un plugin, no un Gmail cualquiera

Todo lo que hemos repasado (TLS al día, HSTS activo, cabeceras de seguridad, certificado sin caducar) se puede vigilar antes de que a nadie se le ocurra escanearte y venderte el hallazgo por correo.

Para eso tienes gratis Vigilante, ¿te suena?, es un maravilloso plugin de seguridad para WordPress, que te deja activar HTTPS y HSTS desde el propio panel de administración, y trae un análisis que avisa si el certificado está a punto de caducar o si faltan cabeceras de seguridad importantes.

No es la única forma de hacerlo, hay otros plugins de seguridad que cubren parte de esto. Pero si prefieres tenerlo controlado desde dentro de WordPress, en vez de depender de acordarte de entrar en el panel de Cloudflare de vez en cuando, ahí tienes una forma de que te avise tu propia web antes que un desconocido.

La decisión de qué hacer con el próximo correo de este tipo que te llegue es tuya. Si mantienes webs de clientes, guárdate esta tabla, porque te va a servir más de una vez.

Para todo lo demás, incluida tu propia colección de correos de este estilo, me tienes ahí abajo, en la sección de comentarios.

Ojalá al próximo «Security Research Team» que te escriba se le note el chasco.