Ayuda WordPress

Impuestos en WooCommerce: guía de cómo YO conseguí configurarlos bien

Fernando Tellado — Wed, 16 Sep 2026 06:28:14 +0000

La pantalla de impuestos de WooCommerce da más quebraderos de cabeza de los que debería, y no es por la cantidad de opciones, que tampoco son tantas, sino porque unas dependen de otras y algunas viven en pantallas distintas.

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:

Activar los impuestos en los ajustes generales.
Decidir si introduces los precios con impuestos incluidos o sin ellos, antes de cargar el catálogo.
Poner la ubicación del cliente por defecto en Ajustes generales.
Elegir según qué dirección se calculan los impuestos.
Dar de alta las tasas de los tipos que necesites, con su nombre y su prioridad.
Coordinar la clase de impuesto del envío con la casilla de envío de la tasa que corresponda.
Ajustar el redondeo y cómo se muestran precios y totales.
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.

SMTP en WordPress «sin plugins»

Fernando Tellado — Tue, 15 Sep 2026 06:28:05 +0000

¿A que lo has pensado?, reconócelo, ya tengo veinte plugins, ¿en serio necesito otro plugin solo para mandar correos desde WordPress?

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:

WordPress va de decisiones y no de opciones, y esto es territorio de plugins.
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:

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.

 '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:


Require all denied

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 = "\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.

Passkeys en WordPress

Fernando Tellado — Mon, 14 Sep 2026 06:28:16 +0000

Cuando entras en una web con una passkey, tu navegador mete el dominio dentro de lo que firma. Eso significa que una web falsa montada en otro dominio no puede reproducir esa firma ni poniéndose en medio de la conversación, y ahí se acaba el phishing, que llevamos veinte años intentando parchear con avisos, con formación a los usuarios y con esconder la pantalla de acceso.

¿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:

Método	Qué puede robarse	Si te clonan el dominio	De qué depende
Contraseña	La contraseña entera, y sirve en cualquier sitio donde la repitas	Caes	De tu memoria y de tu gestor
Enlace o código por email	El enlace o el código, mientras no caduque	Caes	De tu correo, entero
Código con aplicación (TOTP)	El código del momento, y también el secreto inicial	Caes, si te lo piden en la web falsa	De tu móvil y de tus códigos de respaldo
Passkey	Nada utilizable	No caes	De tu dispositivo o de tu cuenta de sincronización

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:

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.
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.
Registra dos credenciales por persona desde el primer momento, no una. La segunda es la que te salva.
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.
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.
Solo entonces amplía al resto del equipo, con periodo de gracia si tu plugin lo permite.
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.

Vulnerabilidades que asustan, la IA comiéndose a Google y mis trucos favoritos del editor de bloques – #CrónicasWordPress #TrucosWordPress

Fernando Tellado — Fri, 11 Sep 2026 21:15:55 +0000

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.

¿Qué plugin de SEO es más ligero y que consume menos recursos?

Fernando Tellado — Thu, 10 Sep 2026 06:28:00 +0000

Vengo recomendando plugins de SEO para WordPress desde hace casi 20 años, y hace poco me lancé a publicar el mío propio, Visibility. Así que cuando un lector que lo usa, y hasta dice que le gusta, me preguntó cuánto pesaba de verdad frente a los plugins de SEO más instalados, no me pareció justo responderle ahí, a lo loco, como padre enamorado de su bebé.

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.

Plugin	Memoria	Consultas	Tiempo	PHP cargado
The SEO Framework	+0,13 MB	−8	+1,2 ms	590 KB / 74 archivos
Visibility	+0,29 MB	−6	+2,3 ms	245 KB / 21 archivos
SureRank	+0,31 MB	+15	+12,7 ms	921 KB / 114 archivos
Slim SEO	+0,38 MB	+3	+4,7 ms	257 KB / 105 archivos
SEOPress	+0,40 MB	+1	+5,2 ms	1,5 MB / 242 archivos
Yoast SEO	+0,85 MB	+16	+4,3 ms	3,0 MB / 547 archivos
AIOSEO	+2,02 MB	+32	+22,5 ms	2,5 MB / 296 archivos
Rank Math	+3,85 MB	+7	+15,1 ms	1,5 MB / 241 archivos

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

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

Plugin	Memoria	Consultas	Tiempo	CSS + JS
The SEO Framework	+0,09 MB	−10	−3,4 ms	82 KB
Visibility	+0,47 MB	−6	−0,8 ms	68 KB
Slim SEO	+0,39 MB	+1	−4,0 ms	187 KB
SureRank	+0,98 MB	+19	+17,2 ms	2,1 MB
SEOPress	+1,03 MB	+11	+6,7 ms	289 KB
Yoast SEO	+1,92 MB	+32	+42,9 ms	4,1 MB
AIOSEO	+5,23 MB	+85	+44,0 ms	1,2 MB
Rank Math	+7,21 MB	+32	+59,5 ms	1,8 MB

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.

Plugin	En disco	Tablas propias	Cron propio	Opciones autocargadas
Slim SEO	892 KB	0	0	2 (7 B)
Visibility	971 KB	0	0	2 (3,3 KB)
The SEO Framework	2,2 MB	0	0	3 (4,9 KB)
SEOPress	8,3 MB	1 (16 KB)	0	7 (4,2 KB)
Rank Math	11,1 MB	2 (64 KB)	3	15 (10,4 KB)
Yoast SEO	16,0 MB	6 (304 KB)	2	7 (13,8 KB)
AIOSEO	16,4 MB	9 (448 KB)	0	6 (17,1 KB)
SureRank	19,8 MB	0	1	2 (54 B)

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.

Tienda WooCommerce «Visible» o «Próximamente» ¿se puede cambiar o personalizar eso?

Fernando Tellado — Wed, 09 Sep 2026 06:28:52 +0000

Estás montando una tienda con WooCommerce, quieres que el cliente vaya viendo cómo queda, que tú puedas trastear con las plantillas a plena luz del día.

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:

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…

WooCommerce → Ajustes → Visibilidad del sitio, marcas «Próximamente» y guardas.
Decides si tapas el sitio entero o solo la tienda con la casilla de debajo.
Si alguien de fuera tiene que verlo, activas el enlace para compartir y le pasas esa URL.
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.
Marcas «Pedir a los motores de búsqueda que no indexen este sitio» en Ajustes → Lectura mientras dure la tarea.
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.

¿SÍ Gutenberg?

Fernando Tellado — Tue, 08 Sep 2026 06:28:41 +0000

Seguramente conoces ya mi plugin No Gutenberg, que lleva en el repositorio de WordPress.org desde 2018, y que durante casi todo ese tiempo ha hecho una sola cosa: hacer desaparecer el editor de bloques, sin ajustes, sin preguntas, sin miramientos. Tiene miles de instalaciones activas que confían ahora mismo en ese comportamiento mientras escribo esto.

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.

¿Te llegó un email diciendo que tu web WordPress tiene una vulnerabilidad grave? ¿es un Beg Bounty bueno o un timo?

Fernando Tellado — Mon, 07 Sep 2026 06:28:54 +0000

Si te ha llegado un email diciendo que tu web WordPress tiene una vulnerabilidad grave, la respuesta corta es que puede ser cierto y un timo al mismo tiempo.

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:

Qué te van a reportar	¿Puede ser verdad?	¿Debería quitarte el sueño?
`wp-json/wp/v2/users` lista tus usuarios	Casi siempre	Poco por sí solo, aunque facilita la fuerza bruta si además usas contraseñas flojas
`xmlrpc.php` accesible	Sí, viene así por defecto	Depende de si lo usas de verdad (Jetpack, apps móviles). Si no, bloquéalo y listo
`?author=1` revela el usuario del admin	Sí	Lo mismo que el anterior, es la puerta trasera al mismo dato
Versión de WordPress visible en el código	Sí	Poco, es informativo y no un ataque en sí mismo
`readme.html` accesible	Sí	Poco, es la misma información con otro nombre
Faltan cabeceras de seguridad (CSP, X-Frame-Options)	Casi siempre	Real pero menor, ayuda a mitigar otros ataques y no es una vulnerabilidad por sí sola
SPF o DMARC flojos	Muy a menudo	El más serio de la lista, de largo

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:

Entra en el panel de Cloudflare, en tu dominio.
Ve a SSL/TLS → Edge Certificates → Minimum TLS Version.
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.

Parches urgentes, Elementor y WP Rocket en apuros, y dónde va tu código en WordPress – #CrónicasWordPress #DoctorWordPress

Fernando Tellado — Fri, 04 Sep 2026 18:54:32 +0000

Ya estamos de vuelta, y después del parón de verano retomamos los directos, y te aviso desde ya de que WordPress no ha descansado ni un día en agosto (ojalá, oye).

Esta semana han sido dos sesiones muy distintas, el lunes, actualidad a saco con las #CrónicasWordPress, y el miércoles, truco práctico en el #DoctorWordPress.

Te resumo lo que dimos en cada una y te dejo el vídeo al final por si te lo quieres ver enterito.

#CrónicasWordPress del lunes: volvemos y con un agosto de infarto en seguridad

Si tuviera que ponerle título al mes de agosto sería «el mes negro de la seguridad en WordPress», y no exagero. No ha habido semana tranquila, así que arrancamos la crónica por ahí.

Seguridad: parches, sustos y agujeros por todas partes

Lo que se movió en agosto en materia de seguridad da para no dormir tranquilo:

Dos parches de seguridad del núcleo en menos de una semana: WordPress lanzó la 7.0.3 y, casi seguida, la 7.0.4. Cuando el core saca dos correcciones tan pegadas, mala señal.
Ataque a la cadena de suministro de BdThemes: les envenenaron la API, con lo que eso implica para todas las webs que confían en sus productos.
Forminator, subida de archivos arbitraria: un fallo que dejó expuestos más de 600.000 sitios. Casi nada.
Elementor Pro, fallo crítico: con riesgo de ejecución remota de código (RCE, que es lo peor que le puede pasar a tu web) en más de 10 millones de instalaciones.
Cierre de mes por todo lo alto: cinco fallos críticos de golpe en WPMU DEV, Avada, TranslatePress, Pods y GiveWP.
El mes negro de WP Rocket: alerta de seguridad y, de propina, el post-mortem de la caída relacionada con WordPress 7.1.

Y como el propio proyecto ha visto que esto se le va de las manos, WordPress.org ha puesto en marcha la «core security initiative» para ordenar el aluvión de reportes de seguridad que le están llegando, muchos de ellos impulsados por IA.

La lectura práctica de todo esto no es asustarse, que el marketing del miedo ya vende bastante sin mi ayuda. Lo suyo es tener la seguridad en piloto automático, con actualizaciones al día, copias de seguridad de verdad y algo que vigile por ti, y de eso justamente hablé en este artículo sobre poner tu seguridad WordPress en piloto automático.

Proyecto y comunidad: Mullenweg, otra vez en el centro

En el frente del proyecto y la comunidad tuvimos tema para rato:

WordPress 7.1 «Mary Lou» ya es oficial, con los llamados «Piplets» y el resumen de la WordCamp US 2026 de fondo.
La extensión oficial de WordPress para el navegador ya está disponible, así que puedes instalártela y cacharrear.
Matt Mullenweg volvió a dar que hablar, y por partida doble. Por un lado con el equipo de accesibilidad, al que le dice que se ha extralimitado en sus funciones y le deja la iniciativa aparcada (aunque el equipo no se rinde y sigue con la documentación y con el plugin Accessibility Lab). Y por otro, dividiendo a la comunidad entre «blogueros» y «constructores» en un artículo suyo que no dejó a nadie indiferente.
Automattic responde a WP Engine con un escueto «Wrong again», que la novela por entregas sigue.
Nuevo panel de WordPress Credits para ver quién contribuye de verdad al proyecto.
WP Agency Forum, segunda edición el 7 de octubre, apúntatelo si te dedicas a esto de las webs de clientes: wpagencyforum.com.

Desarrollo: novedades, una Secrets API y transparencia con la IA

Para quien programa (o programa cosas, como yo), agosto también dejó cosillas:

El repaso de novedades para desarrolladores de agosto.
La propuesta de una Secrets API para WordPress 7.2, para dejar de tener claves y contraseñas donde no deberían estar.
El plugin oficial de IA de WordPress llega a la versión 1.3.0.
El equipo de Hosting aprueba una política de transparencia obligatoria sobre el uso de IA, que ya iba tocando saber qué te instalan y qué hace la IA en tu hosting.
La auditoría de instalaciones activas del directorio de WordPress.org y el resumen del chat de rendimiento, para los más cacharreros.

IA y SEO: Google agita el árbol otra vez

Y cerramos con el bloque que más quebraderos de cabeza da últimamente:

La actualización de spam de Google de agosto ha pegado más fuerte de lo habitual en los rankings, así que si has notado un bajón, no eres el único.
Las citas de Reddit en las búsquedas de ChatGPT se han desplomado un 86%, para que veas lo rápido que cambian las reglas del juego.
Google estrena el botón de «fuentes preferidas» para echar un cable a los editores frente a la pérdida de tráfico por la IA, y te conté cómo aprovecharlo en esta guía sobre las fuentes preferidas de Google.
Y los AI Overviews cambian de comportamiento, con interfaz generativa y expansión automática, que esto no para.

Un apunte personal fuera de WordPress, que también lo comenté: se despide «Un billete a Chattanooga» después de siete años. Una pena, la verdad.

Tienes toda la crónica, con opinión y comentarios en directo, en el vídeo completo:

Ver las #CrónicasWordPress del lunes en YouTube

#DoctorWordPress del miércoles: ¿cuál es la mejor forma de añadir código o snippets en WordPress?

Seguro que te ha pasado: lees un tutorial (a lo mejor uno mío) que te dice «añade este código a tu WordPress» y te quedas con la misma cara de siempre, ¿pero dónde lo meto yo esto? Pues de eso fue el directo del miércoles. Vimos cuatro maneras distintas de añadir fragmentos o snippets de código, cada una con sus pros y sus contras.

Plugin MU (must-use): se cargan siempre y no se pueden desactivar desde el escritorio, así que van de perlas para código que no quieres que nadie toque por error.
Plugin personalizado: tu propio plugin de snippets, que activas y desactivas cuando quieras y te llevas de una web a otra sin despeinarte.
Archivo functions.php del tema activo: lo más rápido y lo que todo el mundo usa al principio, pero ojo, que el código queda atado al tema. El día que cambies de tema o te llegue una actualización, adiós a tus apaños. Es como escribir la lista de la compra en la pizarra de la cocina y luego cambiar la cocina entera.
Plugin de fragmentos tipo Code Snippets: con su interfaz y sin tocar ni un archivo, ideal si no te manejas con el FTP ni con el editor de código.

¿Que cuál es el mejor? Pues, como casi todo en WordPress, depende de para qué y de lo mañoso que seas. Para la mayoría, un plugin de snippets o un mu-plugin te quitan más de un susto; el functions.php déjalo para cuando sepas bien lo que haces y el tema sea tuyo de verdad. Y como cada miércoles, después me quedé respondiendo en directo vuestras dudas sobre WordPress, SEO, IA y casi de todo.

Tienes el truco completo, paso a paso, en el vídeo:

Ver el #DoctorWordPress del miércoles en YouTube

Nos vemos en el próximo directo

Y hasta aquí la semana. Te recuerdo que hago directo dos veces por semana, los lunes las #CrónicasWordPress con la actualidad, la opinión y el debate, y los miércoles el #DoctorWordPress con un truco y vuestras preguntas, a partir de las 19:30, en el canal de Ayuda WordPress. Si te suscribes y le das a la campanita, no se te escapará ninguno. Si te pasas cuando estoy en directo puedes preguntar lo que quieras, que para eso está.

¿Te ha tocado de cerca alguno de estos líos de seguridad? ¿tienes tema para la próxima crónica o una duda para el doctor? Me tienes ahí abajo, en los comentarios. Nos vemos en el próximo directo.

Error 404 en el sitemap XML nativo de WordPress

Fernando Tellado — Thu, 03 Sep 2026 06:28:04 +0000

Si tu web no tiene ninguna una entrada publicada y usas el mapa nativo de WordPress (wp-sitemap.xml), deberías saber que le está contestando a Google y cualquier bot con un error 404 aunque veas el XML y, aparentemente, salga entero y perfecto.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cómo saber si mi sitemap XML da error 404

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Portada	Entradas publicadas	Páginas publicadas	/wp-sitemap.xml
Blog	1	1	200
Blog	0	1	404
Estática	1	1	200
Estática	0	1	404

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Medido por dentro, con el filtro pre_handle_404:

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

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

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

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

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

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

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

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

is_404 = false;
status_header( 200 );

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

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

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

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

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

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

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

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

Con los feeds pasó exactamente lo mismo en 2017

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

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

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

El estado en Trac ahora mismo

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

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

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

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

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

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

¿Me afecta?

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

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

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

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