Cada query duplicada es trabajo que la base de datos hace dos o más veces sin necesidad. Si tu página de inicio dispara la misma consulta a wp_options diez veces y tienes 5.000 visitas al día, son 50.000 queries innecesarias diarias. En hosting compartido se nota, cuando tienes picos de tráfico ya ni te cuento.

Para detectarlas no hace falta ningún plugin, basta con activar SAVEQUERIES y meter un pequeño código (que te voy a regalar) en un mu-plugin y tienes el resumen al pie de cada página. Treinta segundos de trabajo y listo. ¿Te animas?

Activar SAVEQUERIES

SAVEQUERIES es una constante de WordPress que guarda en memoria todas las queries de la petición, con el tiempo que tarda cada una. Por defecto está desactivada porque consume memoria, pero activarla es fácil, solo tiene que añadir esto a tu wp-config.php, justo antes de la línea que dice «Eso es todo, deja de editar»:

define( 'SAVEQUERIES', true );

Advertencia: debes activarla solo en local, en staging o en producción durante el rato justo del diagnóstico. Si la dejas activa en una web con tráfico real te comes la memoria del servidor sin ganar nada a cambio.

Código para mostrar queries duplicadas

Crea un archivo en /wp-content/mu-plugins/ llamado ayudawp-debug-queries.php. Si no tienes esa carpeta, créala tú y pega esto dentro:

<?php
/**
 * Plugin Name: Debug de queries duplicadas
 * Plugin URI: https://servicios.ayudawp.com
 * Description: Muestra un en el pie de página un resumen de queries duplicadas. Solo lo ven los admins y solo cuando está activo SAVEQUERIES.
 * Version: 1.0
 * Author: Fernando Tellado
 * Author URI: https://ayudawp.com
 */

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

add_action( 'wp_footer', 'ayudawp_mostrar_queries_duplicadas', 9999 );

function ayudawp_mostrar_queries_duplicadas() {

    if ( ! current_user_can( 'manage_options' ) ) {
        return;
    }

    if ( ! defined( 'SAVEQUERIES' ) || ! SAVEQUERIES ) {
        return;
    }

    global $wpdb;

    if ( empty( $wpdb->queries ) ) {
        return;
    }

    $contador = array();
    $tiempos  = array();
    // $callers = array(); // Descomenta para guardar quién dispara cada query.

    foreach ( $wpdb->queries as $query ) {

        $sql    = $query[0];
        $tiempo = $query[1];
        // $caller = isset( $query[2] ) ? $query[2] : ''; // Descomenta junto con $callers.

        // Normaliza la query para que los duplicados con distintos valores también coincidan
        $sql_norm = preg_replace( '/\d+/', 'N', $sql );
        $sql_norm = preg_replace( "/'[^']*'/", "'X'", $sql_norm );
        $sql_norm = trim( preg_replace( '/\s+/', ' ', $sql_norm ) );

        if ( ! isset( $contador[ $sql_norm ] ) ) {
            $contador[ $sql_norm ] = 0;
            $tiempos[ $sql_norm ]  = 0;
            // $callers[ $sql_norm ] = $caller;
        }

        $contador[ $sql_norm ]++;
        $tiempos[ $sql_norm ] += $tiempo;
    }

    // Mantiene solo las queries que aparecen más de una vez
    $duplicadas = array_filter(
        $contador,
        function ( $n ) {
            return $n > 1;
        }
    );

    arsort( $duplicadas );

    $total_queries = count( $wpdb->queries );
    $tiempo_bd     = round( $wpdb->timer_stop, 4 );

    if ( empty( $duplicadas ) ) {
        printf(
            '<div style="position:fixed;bottom:0;left:0;right:0;background:#0a4d1f;color:#fff;padding:10px;font:12px monospace;z-index:99999;">Sin queries duplicadas. Total: %d queries en %ss.</div>',
            (int) $total_queries,
            esc_html( $tiempo_bd )
        );
        return;
    }

    echo '<div style="position:fixed;bottom:0;left:0;right:0;max-height:50vh;overflow:auto;background:#1a1a1a;color:#fff;padding:15px;font:12px monospace;z-index:99999;border-top:3px solid #ff6b6b;">';

    printf(
        '<strong style="color:#ff6b6b;">%d tipos de queries duplicadas</strong> · Total: %d queries · Tiempo BD: %ss<br><br>',
        count( $duplicadas ),
        (int) $total_queries,
        esc_html( $tiempo_bd )
    );

    foreach ( $duplicadas as $sql => $veces ) {
        $tiempo_ms = round( $tiempos[ $sql ] * 1000, 2 );
        $sql_corta = strlen( $sql ) > 250 ? substr( $sql, 0, 250 ) . '...' : $sql;
        printf(
            '<div style="margin-bottom:8px;padding-bottom:8px;border-bottom:1px solid #333;"><span style="color:#ff6b6b;font-weight:bold;">×%d</span> <span style="color:#888;">[%sms]</span> %s</div>',
            (int) $veces,
            esc_html( $tiempo_ms ),
            esc_html( $sql_corta )
        );
    }

    echo '</div>';
}

Lo que hace ese código:

• Solo se ejecuta para usuarios con permisos de administrador (manage_options).
• Solo entra si SAVEQUERIES está activo.
• Normaliza las consultas sustituyendo números y cadenas variables por marcadores, así detecta como duplicadas las que solo cambian en los valores (un SELECT por ID 5 y otro por ID 7 cuentan como la misma).
• Imprime al pie de página de la parte visible de la web un resumen con cuántas veces se repite cada query y cuánto tiempo total se va en cada una.

Cómo interpretar el resultado

Al cargar cualquier página en portada habiéndote conectado como admin te aparece una franja al pie con algo así:

3 tipos de queries duplicadas · Total: 47 queries · Tiempo BD: 0,0234s

×6 [12,4ms] SELECT option_value FROM wp_options WHERE option_name = 'X' LIMIT N
×4 [3,2ms]  SELECT * FROM wp_postmeta WHERE post_id = N AND meta_key = 'X'
×3 [1,8ms]  SELECT post_status FROM wp_posts WHERE ID = N

Y lo que significa el ejemplo es esto:

• La consulta a wp_options repetida seis veces es casi seguro un get_option() llamado en varios hooks sin cachear el resultado en una variable estática. Plugin o tema mal hecho.
• La de postmeta repetida cuatro veces es la señal clásica del problema N+1: falta una llamada a update_post_meta_cache() antes de un bucle de posts.
• La tercera puede ser un get_post_status() o similar dentro de otro bucle.

Qué hacer cuando encuentras duplicadas

Depende de quién las dispara y de tu nivel de acceso al código:

• Si la query se repite por un plugin de terceros busca la opción que la lanza y mira si puedes desactivarla. A veces es un widget, una barra lateral o una sección de la cabecera que tampoco te aporta gran cosa.
• Si es de tu propio tema o plugin cachea el resultado en una variable estática dentro de la función, o mejor todavía en wp_cache_set() si tienes caché de objetos (Redis o Memcached).
• Para el patrón N+1 de postmeta añade update_post_meta_cache( $post_ids ) antes del bucle. Una sola query precarga toda la meta de los posts de golpe.
• Para llamadas repetidas a get_option() agrupa varias opciones en un único array, o cachéalas en memoria de la petición con wp_cache_set().

Si te aparece una query rara y no sabes de dónde viene, en el código hay dos líneas comentadas con $callers y $caller. Descoméntalas temporalmente y luego cambia el último printf para que también imprima $callers[ $sql ]. Verás el callstack completo, función por función, hasta saber exactamente quién dispara cada consulta.

Y acuérdate de quitarlo cuando termines

Cuando hayas terminado el diagnóstico, dos cosas:

1. Borra o renombra el archivo del mu-plugin.
2. Quita la línea define( 'SAVEQUERIES', true ); de wp-config.php.

Si dejas SAVEQUERIES activo en producción cada petición guarda el array completo de queries en memoria durante todo el render. En sitios con tráfico real son 200 KB extra por petición por lo menos. No te tira el sitio pero es memoria que consumes sin necesidad.

Para diagnósticos más completos (callstack siempre visible, agrupación por componente, hooks ejecutados, monitorización de AJAX y REST API) la herramienta de referencia sigue siendo Query Monitor. Pero para una revisión rápida y puntual sin instalar nada este snippet va de sobra.

Crónicas WordPress: cPanel atacado, la RTC fuera de la 7.0 y Automattic a saco con IA

El lunes empezamos por seguridad con una vulnerabilidad crítica en cPanel y WHM (CVE-2026-41940), un bypass de autenticación que ya se está explotando y que afecta a miles de hostings, así que aprovechamos para repasar otra vez el plan de batalla contra ataques de fuerza bruta, que mira que conviene tenerlo a mano viendo cómo está el patio.

En la parte de comunidad hubo varios frentes abiertos. WordCamp Europe 2026 ya tiene programa publicado y entradas a la venta para Cracovia, y desde España hay ganas de cruzar fronteras. Matt Mullenweg ha montado un equipo de confianza para reformar WordPress.org y el programa Five for the Future, el Slack de Make WordPress abre puertas a las comunidades locales (con la española incluida) y Rodolfo Melogli publica una carta abierta a WooCommerce que ha dado bastante de que hablar.

En desarrollo, la noticia gorda es WordPress 7.0 Release Candidate 3 y 4 fuera del horno, y con ella el bombazo de que la colaboración en tiempo real se queda fuera de la 7.0. Los resultados del análisis de rendimiento no fueron buenos y el equipo ha decidido retirarla, que entre la RC3 y el lanzamiento del 20 de mayo no había margen para arreglarlo. Gutenberg 23.1 trae una UI para taxonomías personalizadas que muchos llevábamos pidiendo (aunque más de uno se pregunta por qué justo ahora) y hay una novedad interesante para gestionar también los tipos de contenido desde el editor.

También comentamos el experimento WooCommerce for Claude con MCP, el Static Site Importer de Chris Hubbs, la función de desistimiento obligatoria en la Unión Europea que afecta a todas las tiendas WooCommerce a partir del 19 de junio y la última de Takayuki Miyoshi, que confirma que Contactable.io llegará como API RESTful. Y de paso desmontamos otra vez el bulo de que Contact Form 7 va a cerrar, que no, que sigue ahí. También dejé enlace a las dos guías de Ayuda WordPress para preparar webs, plugins y temas de cara a la 7.0, que ya queda nada.

Para cerrar, IA por todos lados. Automattic mete la directa con Studio Code en beta, su agente de IA dentro de Studio que ya tiene su propio changelog assistant, y repasamos el estado de la IA nativa en WordPress 7.0, con los conectores que ya trae y los riesgos de coste que puede acarrear a quien no controle bien sus llamadas.

En IA y SEO, Google ha vuelto a tocar AI Mode y AI Overviews para incluir más enlaces a foros como Reddit, opiniones de expertos y publicaciones a las que estás suscrito, pero un estudio reciente dice que Google se cita a sí mismo en el 17 % de respuestas de AI Mode (sorpresa, ninguna). Y de fondo, la idea de que en 2026 el SEO va más de reconocimiento que de ranking, con GEO y AEO comiéndole terreno al posicionamiento tradicional.

Vídeo completo: Crónicas WordPress del 11 de mayo en YouTube.

Doctor WordPress: WordPress como escritorio, el experimento que mira al futuro

El miércoles en el Doctor WordPress dediqué la sesión a un experimento ya bastante avanzado que apunta directamente hacia dónde puede tirar WordPress en los próximos años, porque la idea es usar el propio escritorio de WordPress como si fuese un sistema operativo, con sus apps, sus ventanas y casi todo lo que esperarías de un entorno de escritorio normal y corriente.

Lo probamos en directo, vimos cómo se monta, qué se puede hacer ya hoy y por dónde apunta de cara al medio plazo. Comenté también en qué escenarios puede tener sentido aunque ahora mismo nadie en producción lo vaya a usar tal cual, porque como avance de lo que se viene es bastante revelador y deja claro que la línea entre WordPress como CMS y WordPress como plataforma cada vez se borra más.

Como cada miércoles, también hubo tiempo para preguntas en directo de los asistentes sobre WordPress, SEO, IA y casi cualquier cosa que se cruzase por el camino.

Vídeo completo: Doctor WordPress del 13 de mayo en YouTube.

Si quieres asistir en directo y participar con tus preguntas, suscríbete al canal de Ayuda WordPress en YouTube.

Lo más llamativo, no obstante, no es la cifra, sino quién paga, pues el 72% de esas multas cayó sobre pymes y autónomos.

¿A que es buen modo de empezar esa guía?, así, en la frente, sin anestesia. Pues es lo que hay, lo siento.

Dentro de los motivos que más se repiten están dos que afectan a casi cualquier WordPress:

1. Usar datos sin base legal.
2. No ser capaz de demostrar el consentimiento del usuario.

El artículo 7.1 del RGPD lo deja clarito, y es que si tratas datos personales basándote en el consentimiento, tienes que poder demostrar que ese consentimiento existió.

La pelota está en tu tejado, no en el del usuario, y una casilla marcada en una base de datos no es prueba defendible de nada.

En este artículo vamos a ver qué pide la ley exactamente, qué tiene que contener un registro de consentimientos para que aguante una inspección, y qué herramientas hay disponibles en WordPress para evitarnos disgustos.

Vamos a ver opciones gratis, de pago y la combinación que mejor encaje según tu caso.

¿Se te pasó el susto?, ¿esperamos un poco a que se te pase el achuchón o empezamos a poner solución a este tema?

¿Y esto me afecta a mi?

La pregunta más común cuando alguien lee algo del RGPD es la misma: «vale, pero mi web es pequeña, ¿esto va conmigo?».

¡Sorpresa! Resulta que sí, te afecta, casi siempre.

La normativa europea no entiende de tamaños y la AEPD ha demostrado en los últimos años que tampoco le tiembla el pulso con autónomos y pymes (vuelve a mirar arriba).

El criterio que aplica el RGPD para saber si te afecta no es dónde está tu sede ni el tamaño de tu negocio, sino 2 cosas:

• Si estás establecido (oficina, sede, actividad real) en cualquier país de la Unión Europea, te aplica.
• Si estás fuera de la UE pero ofreces bienes o servicios a residentes en la UE, o monitorizas su comportamiento mediante cookies, retargeting o analítica, también te aplica.

Esto significa que un blog WordPress hecho en España con formulario de contacto tiene que cumplir, y una tienda online montada en Estados Unidos que admita pedidos de clientes españoles, también. Da igual dónde tengas el hosting o la empresa.

Algunos casos prácticos para que veas dónde encajas:

• Un blogger que vende un curso online o tiene un formulario de suscripción a newsletter.
• Un autónomo que pasa facturas y guarda contactos en WordPress.
• Una pyme con tienda WooCommerce.
• Una comunidad de vecinos con cámaras de video-vigilancia conectadas a un servidor.
• Un club deportivo con web de socios.
• Una multinacional con varios sitios WordPress (con todas las exigencias añadidas, DPO obligatorio, evaluaciones de impacto y demás).
• … suma y sigue.

Lo que queda fuera son las actividades estrictamente personales o domésticas, como un blog familiar de fotos sin afán comercial, una agenda de móvil, un grupo de WhatsApp con amigos.

En cuanto hay una mínima actividad profesional o comercial, se acabó la exención.

El mito más extendido es que las pymes están exentas, y no, no lo están/mos. El artículo 30.5 del RGPD reduce algunas obligaciones de mantenimiento de registros para empresas con menos de 250 empleados, pero solo en condiciones muy concretas.

Las obligaciones de fondo (consentimiento informado, deber de información, seguridad, derechos de los usuarios) son las mismas para una multinacional que para un autónomo con 50 visitas al mes.

Lo que dice «exactamente» la ley

Por orden de importancia y aplicación, las normas que tienes que conocer si gestionas un WordPress en España son las siguientes.

El Reglamento General de Protección de Datos (Reglamento UE 2016/679, en vigor desde mayo de 2018) es la norma de cabecera europea. Para registro de consentimientos los artículos clave son:

• Artículo 4.11, que define el consentimiento como una manifestación libre, específica, informada e inequívoca, mediante una declaración o una clara acción afirmativa.
• Artículo 6.1.a, que establece el consentimiento como base legal para el tratamiento.
• Artículo 7, el corazón del asunto: condiciones del consentimiento, obligación de demostrarlo y derecho a retirarlo.
• Artículo 8, que regula el consentimiento de menores. En España, el límite legal para que un menor pueda consentir por sí mismo es de 14 años.
• Artículo 9, que prohíbe el tratamiento de categorías especiales de datos como salud, ideología o biometría salvo excepciones tasadas.
• Artículos 13 y 14, que detallan el deber de información cuando recoges datos.
• Artículo 30, que obliga al registro de actividades de tratamiento. No es lo mismo que el registro de consentimientos, pero son piezas del mismo puzzle.
• Considerandos 32, 42 y 43, que aclaran cómo debe interpretarse el consentimiento.

A nivel español, la Ley Orgánica 3/2018 de Protección de Datos y Garantía de los Derechos Digitales (LOPDGDD) adapta el RGPD al ordenamiento español, regula los derechos digitales y define el régimen sancionador con tres niveles: leves (artículo 74), graves (artículo 73) y muy graves (artículo 72).

La Ley 34/2002 de Servicios de la Sociedad de la Información (LSSI-CE) regula específicamente las cookies, las comunicaciones electrónicas comerciales y la información que tienes que dar en una web profesional.

Por encima de las normas, las dos guías interpretativas que de verdad se usan en una inspección son las Directrices 5/2020 del Comité Europeo de Protección de Datos sobre consentimiento y las Directrices 3/2018 del mismo organismo sobre ámbito territorial. Y en cookies concretamente, la Guía de cookies de la AEPD en su última versión de 2023.

La memoria de actuación de la AEPD de 2024 cifra en 19.000 las reclamaciones recibidas, con la inteligencia artificial, los neurodatos y los espacios de datos como los retos prioritarios para los próximos años. La presión sobre el cumplimiento sube cada año.

Si quieres ir a las fuentes para profundizar, los sitios oficiales son la sección de derechos y deberes de la AEPD, las directrices del Comité Europeo de Protección de Datos (especialmente la 5/2020 sobre consentimiento), la memoria anual de actuación de la AEPD donde se ven las tendencias de sanciones, y el BOE para leer las resoluciones sancionadoras superiores a un millón de euros.

Cuánto te puede caer

No me quiero poner pesado con esto, pero es que este asunto no es broma ni de lejos, y me consta que la mayoría de las webs no cumplen, y el RGPD establece dos tramos máximos de sanción, ambos muy borricos:

• Hasta 10 millones de euros o el 2% del volumen anual global de la empresa por infracciones del primer grupo, donde entran el deber de información, el registro de actividades y la relación con encargados del tratamiento.
• Hasta 20 millones de euros o el 4% del volumen anual global por infracciones del segundo grupo, donde encaja el incumplimiento del consentimiento del artículo 7.

Siempre se aplica la cantidad mayor de las dos.

Estas son las cifras teóricas máximas, pero la AEPD valora cada caso según la naturaleza de los datos, el volumen de afectados, el beneficio económico obtenido, la cooperación durante la inspección y si la empresa tenía un sistema de cumplimiento previo.

La cuantía real para una pyme es raro que se acerque siquiera al máximo, pero las multas de cinco o seis cifras a empresas pequeñas son habituales.

Las sanciones superiores a un millón de euros impuestas a personas jurídicas se publican en el BOE con identificación del infractor y la infracción, según el artículo 76.4 de la LOPDGDD.

Eso significa publicidad pública del incumplimiento, que para muchas empresas duele más que la propia multa.

Un ejemplo claro de sanción por consentimiento mal recabado, por si tienes curiosidad, es la resolución PS/00500/2020 de la AEPD impuso 3 millones de euros a una entidad financiera por realizar perfilado de clientes basándose en un consentimiento que no era específico ni suficientemente informado.

La AEPD aplicó conjuntamente los artículos 6.1 y 7 del RGPD junto con las Directrices 5/2020 del EDPB. El mensaje de fondo fue que el consentimiento genérico para fines comerciales no vale, cada finalidad necesita su propio consentimiento, específico y demostrable.

Para tu WordPress el escenario realista es más modesto, pues nos moveríamos en sanciones de entre 500 y 30.000 euros por incumplimientos típicos, como llamadas comerciales sin consentimiento, formularios sin información clara, fotos publicadas sin permiso o no atender una solicitud de derechos en plazo.

Así que si te sobra el dinero, y no tienes respeto alguno por la privacidad de tus usuarios, nada, deja de leer, este tutorial es para pobres y profesionales con escrúpulos, como un servidor, y la mayoría de los mortales.

Si valoras cada euro que ganas, y valoras la privacidad y decisiones que los usuarios hacen/mos en la red, sigue leyendo, igual te sirve de algo lo que he preparado…

¿Qué hay que guardar?

El RGPD no dice exactamente cómo se demuestra el consentimiento, y la AEPD y el EDPB tampoco fijan un esquema técnico cerrado.

Lo que sí dejan claro es que tienes que poder reconstruir, ante una inspección, las circunstancias exactas en que cada usuario dio su consentimiento.

Un registro que aguante una inspección debería contener, como mínimo:

• Identificación del usuario: Email, identificador interno o, en el caso de cookies, un identificador anónimo de navegador.
• Acción concreta consentida: Qué se aceptó exactamente, no una etiqueta genérica del tipo «aceptó todo».
• Texto íntegro mostrado al usuario: No basta con guardar «aceptó la política de privacidad», hay que poder reproducir el texto exacto que vio en ese momento.
• Fecha y hora: Marca temporal (timestamp) con precisión, idealmente en UTC para evitar líos de zonas horarias.
• Origen: URL desde la que se dio el consentimiento (formulario, banner, checkout, comentario).
• Versión del documento: Si tu política de privacidad cambia, tienes que poder demostrar qué versión aceptó cada usuario y cuándo.
• IP y agente de usuario: Aportan trazabilidad técnica adicional. Son datos personales, así que conviene aplicar criterios de minimización.
• Mecanismo de integridad: Un hash que demuestre que el registro no se ha modificado desde el momento en que se creó. Esto es lo que más se ignora y lo que más cuenta cuando hay una disputa.

El último punto merece atención especial, pues si un cliente niega haber dado un consentimiento y tú sacas un registro de tu base de datos, lo primero que hará la otra parte es alegar que ese registro pudo modificarse después. Sin un sello criptográfico que demuestre lo contrario tu prueba pierde casi todo su valor.

Ojo también con la IP y el User-Agent, porque son datos personales según el RGPD, y si los guardas, tienes que justificar la base legal (interés legítimo en demostrar el consentimiento), informar al usuario y aplicar plazos razonables de retención. No es difícil, no pasa nada grave, pero debes tenerlo en cuenta.

Algunas implementaciones leen solo la IP del servidor (REMOTE_ADDR) e ignoran cabeceras como X-Forwarded-For, que se pueden falsear, lo que es una buena práctica salvo que tengas un proxy inverso bien configurado.

No, esto no es solo lo de las cookies

Un error muy frecuente es confundir el banner de cookies con el registro de consentimientos contractuales, y son cosas distintas, con normativas distintas, y exigen herramientas distintas.

Consentimiento de cookies y rastreo

Lo regula la directiva ePrivacy a nivel europeo y la LSSI-CE en España, y aquí entra el banner de aceptación de cookies, la categorización (necesarias, funcionales, estadísticas, marketing) y la aceptación por categorías.

Este tipo de consentimiento dura entre 6 y 12 meses según la guía de la AEPD, después hay que volver a pedirlo, y para esto hay un ecosistema enorme de plugins de tipo CMP (Consent Management Platform).

Consentimiento contractual

Cuando un usuario hace un pedido en WooCommerce, se registra en una plataforma o firma una aceptación de términos online lo que se registra es la aceptación de un acuerdo/contrato concreto, con condiciones generales, política de privacidad, términos del servicio.

La duración es la del contrato/acuerdo más los plazos legales de conservación, normalmente cinco años para acciones civiles y hasta seis para temas mercantiles.

Consentimiento de marketing y comunicaciones

La suscripción a newsletter, el alta en una lista de promociones o la autorización para recibir comunicaciones comerciales por SMS o email.

Aquí varias autoridades europeas como la CNIL francesa, la autoridad neerlandesa o la austríaca exigen explícitamente doble aceptación. La AEPD lo recomienda y considera buena práctica probatoria, y en todos los casos la revocación tiene que ser tan fácil como la suscripción.

Otros consentimientos específicos

La aceptación al dejar un comentario en un blog, al descargar un ebook, al inscribirse en un evento, al abrir una cuenta de usuario, cada uno con su contexto, su texto y su finalidad, casi siempre se gestionan con el mismo enfoque que los contractuales.

Cada tipo genera su propio rastro, va a su propio sitio en la base de datos y cumple normas ligeramente diferentes, y lo más razonable es montar herramientas distintas para cada caso, no intentar que un único plugin cubra todo.

Plugins para registrar el consentimiento de cookies

Aquí la oferta es muy amplia, pero voy a quedarme con las opciones que de verdad merece la pena tener en cuenta actualmente.

Complianz

Es probablemente la solución mejor y más sencilla ahora mismo para WordPress, por varias razones que vas a entender, hazme caso.

Y lo sé, muchas veces he recomendado otros plugins, pero también sabes que siempre tiro por lo gratis, ahora verás.

La versión gratuita incluye banner, escaneo de cookies, política de cookies generada automáticamente y bloqueo de scripts, lo que no incluye es el registro de consentimientos, reservado a Complianz Premium (89 € al año), pero…

Aquí entra una pieza del puzzle interesante, y es que hay un plugin gratuito llamado Record of Consent Extension for Complianz, hecho por davidevalerio, que añadido al Complianz Free te da exactamente eso:

• Registro individual con sello SHA-256.
• Detección multi-cabecera de IP (Cloudflare, X-Forwarded-For, Client-IP).
• Filtrado de bots y exportación.

La integridad criptográfica que ofrece supera a la del propio Complianz Premium, y todo gratis, una auténtica maravilla, que sorprende las pocas instalaciones que tiene.

Para muchos casos, esta combinación resuelve el consentimiento de cookies con registro defendible sin pagar nada.

CookieYes

Este plugin es otra opción bastante popular, con más de 1,5 millones de instalaciones activas y la versión gratuita incluye registro de consentimientos básico.

Las funciones avanzadas de geo-targeting y traducción automática están en la versión Pro, desde 10 dólares al mes.

WPConsent

La opción del equipo de WPForms y Awesome Motive. Su versión gratuita es muy decente y la Pro arranca en 49 dólares al año.

WebToffee GDPR Cookie Consent

Certificado por Google como CMP, es compatible con IAB TCF v2.3 y mantiene registro con ID de consentimiento, IP y marca temporal en la versión gratuita.

La Pro cuesta 89 dólares al año.

Moove GDPR Cookie Compliance

De este ya sabes que siempre he sido muy fan, ofrece registro de consentimientos, pero solo en la versión de pago, por unos 49 dólares.

Cookiebot

Funciona como SaaS, gratis hasta 100 páginas al mes, después 12 € al mes. Los datos se almacenan en sus servidores no en tu WordPress, y esto en sí mismo ya es un inconveniente.

Tabla resumen para que te sea más fácil valorar las distintas opciones:

Registro de la aceptación de términos y condiciones en WooCommerce

WooCommerce trae de serie un casillas para los términos y condiciones en el pago, pero solo guarda un registro booleano. Marca o no marca, punto, y eso no demuestra absolutamente nada ante una inspección.

Terms & Conditions Tracker

La opción disponible en el mercado de plugins oficial de Automattic es un plugin de pago a 79 dólares al año disponible en WooCommerce.com.

Registra marca temporal, IP, User-Agent y un hash MD5 del documento aceptado. Es compatible con checkout clásico y de bloques, compatible con HPOS y permite múltiples casillas (privacidad, marketing, verificación de edad). El registro es exportable a CSV.

Tiene un detalle técnico discutible, y es que el hash que usa el plugin oficial es MD5, un algoritmo criptográficamente roto desde 2008. Para una prueba defendible ante una inspección no es lo ideal, SHA-256 sería el estándar mínimo aceptable hoy.

Additional Terms Pro

Otra opción de pago, también en WooCommerce.com a 79 dólares al año. Este aporta lógica condicional para mostrar casillas diferentes según los productos del carrito o el día de la semana, y registra la aceptación en el pedido.

Útil para tiendas con surtido variado, donde diferentes productos requieren diferentes aceptaciones.

Terms & Conditions Consent Log

Plugin gratuito disponible en wordpress.org y el instalador de plugins de tu web, que me tocó preparar, en vista de que no había soluciones ni gratis ni completas.

Va mucho más allá de WooCommerce porque cubre también formularios, comentarios y dispone de API pública, pero centrémonos aquí en para qué sirve en tiendas online.

En el pago captura la casilla de aceptación nativa de términos y condiciones sin tener que configurar nada. Guarda marca temporal en UTC, IP, User-Agent, versión del documento, URL de origen y el texto exacto que vio el cliente.

Cada registro se sella con SHA-256 del texto aceptado, así que si alguien lo modifica en la base de datos después, la verificación de integridad lo detecta y lo marca como MANIPULADO.

Es compatible con HPOS, genera un certificado A4 imprimible de cada registro que el navegador exporta a PDF, sin librerías externas, y se integra con las herramientas de privacidad integradas en WordPress (anonimiza en lugar de eliminar al recibir una solicitud de borrado).

El registro de cada consentimiento queda enlazado al pedido y aparece como columna en el listado de pedidos y como caja meta en la pantalla de edición de cada pedido, con toda la información y enlaces al consentimiento y a un PDF exportable, por si lo pide un cliente.

En la siguiente sección te cuento todo lo que cubre fuera de WooCommerce, que es mucho.

¿Y no hay un código de copiar y pegar?

Para casos muy básicos sigue siendo válido el clásico fragmento de código que pegas en el functions.php del tema hijo o en un mu-plugin.

Es lo mínimo del mínimo, pero al menos te queda algo guardado por pedido:

// Guardar aceptación de términos en el meta del pedido (compatible con HPOS).
add_action( 'woocommerce_checkout_create_order', 'ayudawp_save_terms_acceptance', 10, 2 );
function ayudawp_save_terms_acceptance( $order, $data ) {
    if ( ! empty( $data['terms'] ) ) {
        $ip = isset( $_SERVER['REMOTE_ADDR'] )
            ? sanitize_text_field( wp_unslash( $_SERVER['REMOTE_ADDR'] ) )
            : '';
        $order->update_meta_data( '_terms_accepted', 'yes' );
        $order->update_meta_data( '_terms_accepted_date', current_time( 'mysql' ) );
        $order->update_meta_data( '_terms_accepted_ip', $ip );
    }
}

Lo que hace es guardar tres campos en cada pedido, lo que aceptó (booleano), la fecha y la IP, pero no guarda el texto que vio el cliente, ni la versión del documento, ni tiene hash de integridad, así que no es prueba defendible ante una inspección ni medio seria.

Si tu web es muy pequeña, no quieres instalar plugins y necesitas «algo» mejor que la nada absoluta de WooCommerce por defecto, este código te saca del paso, para todo lo demás vete a una solución con las garantías que se han descrito antes.

Resumen de opciones específicas para WooCommerce:

Registro de consentimiento en formularios, comentarios y el resto del WordPress

Las tiendas no son el único sitio donde se piden consentimientos. Cualquier WordPress con un poco de actividad tiene formularios de contacto, suscripciones, comentarios, descargas de ebooks, inscripciones a webinars, alta de usuarios, y cada uno de esos puntos genera un consentimiento que tienes que poder demostrar.

Lo típico es tener un plugin distinto para cada cosa. Consentimiento de cookies por un lado, registro del pago de WooCommerce por otro, registro de consentimiento de de formularios en otro, y los comentarios … ah, eso se me olvidó.

Todo repartido en tres o cuatro tablas distintas, con formatos diferentes y sin manera fácil de exportarlo todo cuando llega una reclamación. No es lo ideal, está claro.

En fin, vamos al tema, que esto hay algunas opciones, de todo tipo y pelaje…

WPForms Pro

Si ya usas WPForms en su versión Pro tienes un campo nativo llamado GDPR Agreement que añade una casilla de consentimiento al formulario.

La aceptación se guarda con cada envío junto con marca temporal y datos del usuario. Lo tienes desde 49,50 dólares al año.

La pega es que el registro queda dentro de WPForms, no en una tabla común con el resto de consentimientos del sitio, así que si combinas con otras fuentes (pago, comentarios) tendrás que exportar y cruzar a mano.

The GDPR Framework (Data443)

Plugin gratuito en wordpress.org, con extensiones de pago opcionales, que se puede integrar con Contact Form 7, Gravity Forms, Ninja Forms, Formidable Forms, WooCommerce y Easy Digital Downloads.

Además del registro de consentimiento, gestiona también solicitudes de derechos de los usuarios (DSAR), permite exportar y borrar datos, y cubre buena parte del cumplimiento RGPD básico.

No usa hash de integridad ni genera certificados, pero al cubrir muchos plugins distintos en una sola herramienta es una opción interesante para quien usa varios tipos de formulario en la misma web.

Terms & Conditions Consent Log

Como ya he comentado en la sección anterior este plugin no se queda solamente en cubrir todos los consentimientos de tiendas online WooCommerce.

Es una solución muy completa para todos los consentimientos del sitio, con una tabla única indexada (wp_tccl_consents) donde caen los registros vengan de donde vengan, no en la habitualmente ya saturada wp_postmeta.

Reconoce automáticamente cuatro fuentes de consentimiento, sin tener que configurar nada, además del pago de WooCommerce que ya vimos en la sección anterior, o sea, que son cinco.

La primera fuente aparte de WooCommerce es Contact Form 7, ya que cualquier formulario de CF7 que incluya un campo [acceptance] y que el visitante marque genera automáticamente un registro.

Sin código, sin integración manual, sin tocar functions.php, cada formulario tiene su propio consent_type con el ID del formulario, así que los registros se filtran por origen.

La segunda son los comentarios de WordPress. La casilla de aceptación de «Guarda mi nombre, correo y web…» que WordPress añade bajo el formulario de comentarios también se puede registrar.

Cada comentario con la casilla marcada queda guardado como evidencia, con el email del usuario, la URL y la fecha exacta. Útil para blogs donde los comentarios son una fuente importante de datos personales.

La tercera es el shortcode [tccl_consent_box] y su bloque Gutenberg equivalente. Lo pones donde quieras, ya sea una página, una entrada, un widget de barra lateral, un footer o el campo HTML de un plugin de formularios.

Tiene atributos para personalizar el texto, el tipo, la versión y el botón. Al enviarse se registra el consentimiento sin recargar la página. Muy útil para casos como cuando ofreces la descarga de un ebook, la inscripción a un sorteo o el alta en una lista de espera.

La cuarta es una API pública con la función tccl_save_consent() para registrar consentimientos desde cualquier sitio.

Si tu formulario está hecho con Gravity Forms, WPForms, Fluent Forms, Forminator o personalizados, puedes engancharte al hook que ese plugin exponga y dejar el consentimiento registrado con tres líneas de código. Lo mismo con altas de usuarios (user_register), variables REST propias o cualquier otro enpoint.

Todos los registros se sellan con SHA-256 del texto aceptado en el momento del consentimiento.

Si alguien modifica el texto en la base de datos después, la verificación de integridad lo marca como MANIPULADO en el listado, en el certificado y en la caja meta del pedido.

Hay certificado de cada registro de consentimiento, que puedes exportar a PDF o imprimir sin que tengas que instalar nada ni código adicional en el plugin, pues usa la funcionalidad disponible en tu navegador.

El plugin se integra con las herramientas de privacidad nativas de WordPress, así que en Herramientas > Exportar datos personales y Herramientas > Borrar datos personales aparecen los consentimientos del usuario solicitante.

El borrado anonimiza en lugar de eliminar, porque el propio registro es la base legal más que de sobra para conservar la prueba.

Otros detalles que también son importantes:

• Compatible con HPOS.
• Retención configurable con anonimizado por filtro desde la pestaña de registros.
• Exportación CSV con cabecera de metadatos.
• Opción de añadir una línea de consentimiento en los emails de WooCommerce, tanto admin como cliente.
• Por defecto no destruye datos al desinstalar, así la prueba sobrevive a la desinstalación salvo que actives explícitamente el borrado total.

Plataformas de email marketing

Si tu plataforma de email marketing es Mailchimp, Brevo, ActiveCampaign o similar hay buenas noticias porque casi todas guardan ya el registro de suscripción internamente con marca temporal, IP y origen.

Pídele a tu plataforma que te exporte el registro si tienes una reclamación o inspección. La mayoría también permite exigir doble aceptación, que es la práctica más sólida desde el punto de vista probatorio, y obligatoria en montones de países.

Comparativa de opciones para formularios, comentarios y demás necesidades de WordPress:

Por qué es tan importante eso del HASH

Imagínate que un cliente reclama haber recibido emails comerciales sin haber dado su consentimiento ¿vale?

Tú vas a tu base de datos, encuentras el registro y lo enseñas. La otra parte, lógicamente, alega que ese registro pudo añadirse o modificarse después de la queja, ¿cómo demuestras lo contrario?

Aquí entra el sello criptográfico.

Cuando se crea un registro se calcula lo que se llama un hash (una huella digital única) del contenido completo, que graba el texto aceptado, la fecha y el identificador del usuario.

Ese hash se guarda con el propio registro, y si alguien modifica cualquier cosa después, el hash deja de coincidir y la manipulación se detecta automáticamente.

Protege la decisión de consentimiento de tus usuarios o clientes, y también te protege a ti de posibles intentos de manipulación, por parte de empleados, o incluso de denuncias falsas de clientes.

El estándar de hash que se usa hoy es SHA-256, que genera huellas de 256 bits y no se ha encontrado todavía ningún ataque práctico para producir colisiones.

MD5, en cambio, está roto desde 2008, e investigadores han demostrado que se pueden generar dos contenidos diferentes con el mismo hash MD5, lo que hace que su uso para integridad probatoria sea cuestionable. SHA-1, que fue su evolución, también está abandonado desde 2017.

El plugin de pago que hay en WooCommerce.com que te he comentado antes sigue usando MD5, y Complianz Premium no aplica siquiera un hash a sus registros, que es aún peor.

Únicamente los plugins Record of Consent Extension for Complianz (mi recomendación para el registro de consentimiento de cookies) y Terms & Conditions Consent Log (para todos los demás consentimientos) usan SHA-256, lo que añade protección frente a modificaciones silenciosas.

Además del hash hay otro detalle importante, que es la posibilidad de generar un certificado por registro, con todos los datos, el texto aceptado, el hash y un código de verificación, en formato listo para imprimir o guardar como PDF, marca la diferencia entre tener una hoja de cálculo defendible y tener un dossier judicial.

Un PDF firmado con el hash dentro y una marca temporal (timestamp) clara es lo que pediría cualquier abogado para defender un caso.

Esta funcionalidad solo la incorpora el plugin Terms & Conditions Consent Log, y hace falta porque además no la cubre ningún otro plugin.

Qué hay que hacer con los registros viejos

El RGPD obliga a aplicar el principio de minimización de datos, de que guardes solo lo necesario y durante el tiempo necesario, sea lo que sea que esto signifique, dada la imprecisión. Esto crea un problemón interesante con el registro de consentimientos.

Si un cliente cancela su cuenta y pide el borrado de sus datos, ¿qué pasa con el registro de consentimiento que demuestra que en su día aceptó tus condiciones?

La interpretación más razonable es que el registro de consentimiento no se borra, se anonimiza, porque el propio registro es la base legítima para que conserves esa prueba.

Si borras el registro pierdes la capacidad de demostrar el consentimiento posteriormente, lo que vulnera el artículo 7.1.

La forma correcta de cumplir es:

• Sustituir los datos identificativos (email, IP, nombre) por valores anonimizados o hash.
• Mantener el resto del registro (fecha, texto aceptado, versión del documento, hash de integridad).
• Documentar la operación de anonimización con su propio timestamp.

Esto encaja con la política de no guardar datos personales más allá de lo necesario, y también con la rendición de cuentas, pues sigues pudiendo demostrar que en su día se obtuvo un consentimiento válido.

Las herramientas que distinguen entre borrado total y anonimización son las que mejor encajan con esta interpretación, y lo malo es que no todos los plugins cumplen con estos principios.

El plugin disponible en WooCommerce.com, por ejemplo, permite borrar registros uno a uno, sin opción de anonimización.

Las únicas opciones que sí incluyen anonimización con un clic, tanto individual como por filtro, son Record of Consent Extension for Complianz (para el consentimiento de cookies) y Terms & Conditions Consent Log (para todos los demás).

Sobre los plazos de retención no hay una cifra mágica, la AEPD recomienda aplicar plazos razonables alineados con la finalidad del tratamiento.

Para consentimientos contractuales la práctica sensata es conservarlos al menos cinco años desde la finalización del contrato (alineado con plazos de prescripción civil), para consentimientos de marketing y newsletter la mayoría aplica entre uno y tres años desde la última interacción.

Qué te conviene según tu tipo de web

No todas las webs necesitan lo mismo. Te dejo un resumen rápido para que encuentres tu sitio.

Blog informativo o de contenidos sin tienda y sin formularios complejos

Lo que necesitas es banner de cookies con registro básico y, si tienes formulario de suscripción a newsletter, doble aceptación. Con Complianz Free + Record of Consent Extension cumples el artículo 7.1 sin gastar nada.

Si tu newsletter está en Mailchimp o Brevo, el propio servicio te guarda el registro de la suscripción.

Si quieres además registrar el consentimiento de los usuarios que dejen comentarios entonces necesitas Terms & Conditions Consent Log, lo hace usando la casilla que ya incorpora WordPress, no añade nada.

Tienda WooCommerce pequeña o mediana

Aquí tienes tarea doble, pues por un lado volvemos a lo anterior, al banner de cookies (Complianz Free + extensión de davidevalerio) y además necesitas el registro potente de la casilla de términos y condiciones en el pago.

Para lo segundo solo hay dos opciones válidas, o Terms & Conditions Tracker si prefieres un plugin de pago, o Terms & Conditions Consent Log si quieres SHA-256, certificado imprimible y, ya de paso, registrar también los formularios de contacto y los comentarios sin instalar nada más, tú verás.

Si tienes newsletter, pues súmale lo suyo.

Web profesional con captación por formularios

Lo importante aquí es el registro del consentimiento del formulario.

Las opciones son estas:

• WPForms Pro con campo GDPR Agreement, si ya usas WPForms.
• The GDPR Framework de Data443 si usas Contact Form 7, Gravity, Ninja o Formidable.
• Terms & Conditions Consent Log con su integración nativa para Contact Form 7 (automática) o con su API pública si usas otro plugin de formularios.

Suma banner de cookies y newsletter si la tienes, que no se te olvide.

Plataforma con suscripción de pago, LMS o membresía

En este caso el consentimiento contractual es fundamental porque hay un contrato y dinero de por medio, así que necesitas registro con integridad criptográfica, certificado imprimible y trazabilidad total.

Aquí tienes que aplicar la combinación de banner de cookies (Complianz + extensión de davidevalerio) más registro de consentimientos contractuales (Terms & Conditions Consent Log o Terms & Conditions Tracker) y lo cubres al completo.

Multinacional o web con datos sensibles (salud, biometría, ideología, datos de menores)

Aquí no estamos en escenario de plugins, estamos en escenario de consultoría especializada y soluciones empresariales como Iubenda, OneTrust, Usercentrics o equivalentes. Y además un DPO (Delegado de Protección de Datos) profesional revisando todo.

Consejos y recomendaciones finales

El registro de consentimientos no es opcional ni una formalidad, es la prueba de que cumples el artículo 7.1 del RGPD y la herramienta que más vas a echar en falta el día que recibas una reclamación o una inspección.

La buena noticia es que el ecosistema de plugins libres y de pago en WordPress da hoy soluciones para todos los casos, y la mala es que la mayoría de webs todavía siguen confiando en una casilla sin registro, que ante cualquier disputa se queda menos que nada.

Estos son los 7 consejos que te doy para ir terminando:

• El consentimiento es una prueba, no una etiqueta: Captura el texto exacto que vio el usuario, séllalo con SHA-256 y guárdalo en un sitio donde lo puedas reproducir años después tal cual era ese día.
• No confundas cookies con consentimiento contractual: Son normas distintas, plugins distintos y registros distintos. Mezclarlos da una prueba ambigua que no aguanta una inspección seria.
• Las combinaciones gratuitas bien hechas cumplen mejor que muchas soluciones de pago: Complianz Free + Record of Consent Extension para cookies y un plugin libre con SHA-256 como Terms & Conditions Consent Log para el resto te dejan más cubierto que muchas tiendas grandes que pagan licencias caras sin hash robusto.
• Doble aceptación obligatoria para marketing: La AEPD lo recomienda y las autoridades europeas y el RGPD lo exigen. Es la práctica más sólida para defender un alta en lista de comunicaciones comerciales.
• Anonimiza, no borres: Cuando un usuario pida la supresión de sus datos, sustituye los IDs por valores anonimizados pero mantén el resto del registro y el hash. La prueba sobrevive y tú sigues cumpliendo.
• Versiona tus textos legales: Si cambias la política de privacidad o las condiciones, cambia también la versión que se guarda en el registro. Sin versión no puedes demostrar qué aceptó cada usuario.
• Documenta los plazos de retención: Define por escrito cuánto tiempo guardas cada tipo de consentimiento y por qué. La AEPD valora positivamente que tengas esto pensado y registrado.

Y este es el resumen práctico de lo mínimo y lo recomendable para una web normal:

Si tienes una web pequeña y quieres empezar bien sin gastar la receta es que instales Complianz Free + Record of Consent Extension for Complianz para cookies, y que montes un registro de consentimientos para todo lo demás (pago, formularios, comentarios, descargas) con Terms & Conditions Consent Log. Cumples más que nadie y 100% gratis.

Con eso cumples el artículo 7.1 mejor que muchas tiendas grandes. Y si tu negocio crece ya valorarás soluciones de pago con soporte profesional.

Lo importante es ponerse a ello, pues cualquier registro defendible, por básico que sea, es infinitamente mejor que un casilla de aceptación sin registro alguno del consentimiento, y cualquier hora invertida hoy en montar esto bien te ahorrará días de papeleo el día que toque defenderlo.

El problema lleva con nosotros desde febrero de 2025 y, lejos de arreglarse, en la temporada 2025/2026 ha ido a más. Así que toca dejar el lloro y pasar a la parte práctica, ver qué puedes hacer, desde ya, para que los bloqueos de LaLiga no te dejen la web fuera de servicio cuando le den a la pelotita.

Qué está pasando (legalmente, por injusto que sea)

El 18 de diciembre de 2024 el Juzgado de lo Mercantil número 6 de Barcelona dio luz verde a una resolución pedida por LaLiga y Telefónica Audiovisual que permite ordenar a las operadoras de internet españolas (Movistar, MasOrange, Vodafone, DIGI y todas sus marcas) el bloqueo de direcciones IP usadas para retransmisiones piratas de fútbol.

En marzo de 2025 ese mismo juzgado tumbó los recursos de Cloudflare y RootedCON. Desde entonces, cada jornada de LaLiga, las operadoras aplican bloqueos a rangos de IPs durante las horas de los partidos. Y el problema no está en la idea de perseguir la piratería, que es legítima, sino en cómo se ejecuta.

Cloudflare, igual que cualquier CDN o proveedor cloud moderno, asigna la misma IP a miles de clientes a la vez (las IPv4 son un recurso escaso y caro).

Cuando LaLiga señala una IP que aloja una web pirata, en esa misma IP suele haber cientos o miles de webs legítimas que no tienen nada que ver. Y todas caen a la vez.

La lista de damnificados es larga e incluye perlas como la web de la Real Academia Española, TDTChannels, parte de Vercel, GitHub, Twitch, partes de RedSys (la red de pagos con tarjeta mayoritaria en España), foros, blogs personales, tiendas online y, sí, decenas de miles de pymes que ni son piratas ni tienen nada que ver con el fútbol.

Cloudflare ha llevado el caso al gobierno de Estados Unidos en noviembre de 2025, y plataformas como BunnyCDN o Vercel han empezado a sacar nodos de España o a restringir sus servicios aquí precisamente por esto. Vamos, que como siempre dando ejemplo en España de cómo no hacer las cosas para fomentar la innovación.

Por si fuera poco, desde agosto de 2025 LaLiga ha empezado a mandar emails amenazantes a propietarios de webs que comparten IP con sitios de fútbol pirata, usando la normativa ICANN como vía.

El caso más sonado fue el del blog de Lázaro, un blog personal sobre GNU/Linux que recibió uno de estos correos. Si te llega uno, hablamos al final del artículo.

Hasta aquí los antecedentes. Si quieres más detalle puedes pasarte por laligagate.com, que documenta el desastre con calma y rigor, pero ya vamos a lo que de verdad nos interesa.

Cómo saber si tu web está siendo bloqueada

La herramienta de referencia es hayahora.futbol. La montaron entre varios ingenieros (en palabras de Tebas, «cuatro frikis») que rastrean en tiempo real qué IPs están bloqueadas en cada operador y mantienen un histórico público con sondas en conexiones reales. Tiene tres cosas que vienen muy bien:

• Un indicador grande de si hay partido y hay bloqueos ahora mismo.
• Un buscador donde metes tu dominio y te dice si tu IP está afectada.
• Unos archivos TXT y JSON públicos (https://hayahora.futbol/estado/blocked-any.txt y https://hayahora.futbol/estado/data.json) que cualquier plugin o script puede consultar.

Si tienes dudas sobre si tu web está cayendo los fines de semana por los bloqueos, lo primero es entrar ahí cuando haya partido de liga en España, y comprobarlo. Si tu IP aparece en la lista de bloqueadas o si tu dominio sale como afectado, ya tienes la respuesta.

Y si no aparece pero sigues recibiendo quejas, lo siguiente es pedirle a alguien con Movistar, Vodafone, MasOrange o DIGI que pruebe a entrar en tu web justo cuando hay partido. Si a ti, con otra red, te carga sin problema y a esa persona no, no hay misterio, te están jodiendo por obra y gracia del fútbol.

Y NO, desactivar el proxy de Cloudflare NO deja tu web indefensa

Antes de entrar en soluciones tengo que pararme aquí, porque cada vez que alguien recomienda desactivar el proxy de Cloudflare para sortear los bloqueos aparece un coro de cuentas (muchas nuevas, muchas idénticas, muchas sospechosamente activas) repitiendo la misma cantinela: «eso no es un bypass, eso es dejar tu web expuesta«, «vas a comerte un DDoS«, «estás revelando la IP de tu servidor«.

A ver, pedazo de bobos (no es para ti, es para los que dicen esas cosas), eso es una tontería, falso y, encima, es hasta un insulto a cualquiera que haya tenido una web en internet antes de 2015.

La mayoría de webs del mundo no están detrás del proxy de Cloudflare ni de ningún CDN similar, y funcionan perfectamente.

La idea de que una web «queda indefensa» sin la nubecita naranja viene de mezclar dos cosas distintas, la protección activa y los servicios añadidos.

La seguridad real de tu WordPress está en muchas capas, y no dependen de Cloudflare:

• Hosting con buena protección anti-DDoS por defecto (que casi todos los hosting españoles serios la tienen).
• El cortafuegos, también, de tu hosting (pues la mayoría tienen WAF a nivel de servidor).
• Los plugins de seguridad que uses (Wordfence, Solid Security, AIOS, Vigilante).
• Las contraseñas fuertes, el 2FA y unas claves salt de WordPress bien generadas.
• Mantener actualizado WordPress, los plugins y el tema.
• Reglas básicas de .htaccess o de Nginx para bloquear lo más obvio.

Cloudflare es un complemento muy útil que te da CDN, caché distribuida, ocultación de la IP de origen y freno temprano de ataques DDoS, pero no es la columna vertebral de tu seguridad, solo una capa recomendable. Y si lo era, tu seguridad ya tenía un problema antes de que LaLiga apareciera.

Aclarado esto, vamos a las soluciones.

Solución 1: No usar ninguna CDN

La opción más radical y, curiosamente, la que más gente lleva décadas usando sin saber que está «indefensa», ejem.

Quitas Cloudflare del medio, cambias de nuevo los NS a los de tu hosting, y tu dominio apunta directamente a la IP de tu servidor. Fin del problema con los bloqueos, tu IP ya no está en ningún rango compartido de CDN.

Lo que pierdes:

• Caché global distribuida (las visitas internacionales irán algo más lentas si tu servidor está solo en España).
• Ocultación de la IP de origen (cualquier herramienta tipo nslookup ve tu IP real).
• Mitigación de DDoS volumétricos a nivel de Cloudflare (sigues teniendo la del hosting, que para el 99% de los casos es suficiente).
• Algunos servicios de optimización como Rocket Loader, Polish, Mirage o APO.
• Reglas de seguridad de la CDN.

Lo que ganas es que tu web ya no está expuesta a los bloqueos de IPs de CDN compartida. Sigues teniendo SSL (cualquier hosting decente trae Let’s Encrypt gratis), DNS, correo y todo lo demás. Si tu web no es enorme no recibe ataques constantes y tu hosting tiene buena infraestructura, esta opción es perfectamente viable.

La gente que tiene su WordPress en un buen hosting español sin Cloudflare por delante lleva, no años, décadas funcionando sin problemas.

Si tu web es un blog personal, una web corporativa pequeña o una tienda con tráfico nacional esta opción es razonable. Pero si vas a hacerlo, hazlo bien, revisa que tu hosting tenga protección anti-DDoS básica, ten activado un plugin de seguridad serio, mantén todo actualizado y monitoriza con algo tipo UptimeRobot.

Solución 2: Cambiar de CDN (con sus matices)

La idea suena bien, porque si Cloudflare es el problema, me voy a otra CDN y ya está ¿no?. La realidad es más complicada…

Cualquier CDN o cualquier proveedor cloud con IPs compartidas puede acabar también en el punto de mira de LaLiga. Ya ha pasado con Vercel, con Akamai, con BunnyCDN. De hecho, según ha trascendido en foros como BandaAncha, BunnyCDN ha empezado a restringir sus POPs (puntos de presencia) de España a cuentas Enterprise desde diciembre de 2025, en parte por este lío.

Justo cuando más útil sería tener una alternativa europea con servidores en España, esa alternativa empieza a desaparecer.

Dicho esto, sí tienes opciones que ahora mismo están menos afectadas o que no comparten infraestructura con las webs de fútbol pirata:

• Bunny.net sigue siendo una alternativa muy buena en relación calidad-precio (a partir de 0,01 € por GB), aunque con la advertencia anterior sobre los POPs de España. Para el resto de Europa funciona de maravilla.
• KeyCDN en pago por uso, sin tarifas mensuales fijas, más barato que Cloudflare Pro para webs medianas.
• Sucuri si lo que te interesa es el paquete WAF + CDN + limpieza de malware en uno.
• QUIC.cloud si usas LiteSpeed Cache, con plan gratuito para webs pequeñas.

Migrar de CDN tampoco es trivial, pues implica cambios de DNS, reconfigurar reglas de caché, regenerar certificados, reapuntar registros. Si lo haces solo para sortear los bloqueos de LaLiga, piénsatelo bien, porque mañana puede ser ese mismo proveedor el que esté en esa lista infame.

Solución 3: Desactivar y reactivar el proxy de Cloudflare manualmente

Si quieres seguir aprovechando las ventajas de Cloudflare la mayor parte del tiempo y solo dejarlo fuera cuando hay partido, esta es tu solución, y no es difícil de aplicar.

En el panel DNS de Cloudflare cada registro tiene una nubecita, si está naranja el tráfico pasa por el proxy de Cloudflare (y por tanto por las IPs que LaLiga bloquea), si está gris Cloudflare solo resuelve el DNS y el tráfico va directo a la IP de tu servidor, sin tocar las IPs de Cloudflare.

Para activar este modo «Solo DNS» basta con entrar a Cloudflare, ir a DNS, pulsar el icono de la nube en los registros A, AAAA y CNAME de tu dominio y dejarlos en gris. El cambio es instantáneo, no afecta a la resolución del dominio y, sobre todo, saca tu web del rango de IPs que LaLiga bloquea.

Cuando termine el partido, vuelves a poner las nubes en naranja y listo. Pierdes durante un par de horas la caché de Cloudflare, la ocultación de tu IP de origen y algunos servicios derivados, pero sigues teniendo SSL, DNS y, sobre todo, una web que carga.

El inconveniente es obvio, que hay que estar pendiente del calendario y hacerlo a mano cada fin de semana. Si tienes una sola web y eres ordenado, es viable, pero si llevas varias o si simplemente no te quieres ocupar o no siempre vas a poder, pasa a la solución 4.

Apunte breve sobre ECH (y por qué no te salva)

Es probable que hayas leído sobre ECH (Encrypted Client Hello), una extensión del protocolo TLS que cifra el campo SNI, que es donde el navegador le decía a la operadora a qué dominio querías acceder. Cloudflare lo activó por primera vez en 2023, lo tuvo que desactivar un tiempo, y lo reactivó a partir de septiembre de 2024.

Desde marzo de 2026 es estándar oficial del IETF y está disponible gratis para cualquier cliente de Cloudflare, sin hacer nada por tu parte.

El detalle importante es que ECH protege contra los bloqueos basados en analizar el SNI, que son los antiguos, los bloqueos actuales de LaLiga ya no funcionan así, porque al ver que ECH les complicaba el filtrado, pasaron a bloquear directamente por IP.

Contra el bloqueo por IP, ECH no hace nada, porque la IP sigue siendo visible para la operadora antes incluso de empezar a resolver el TLS.

Está bien que ECH exista y mejora la privacidad de todos, pero no es solución a los bloqueos actuales.

Solución 4: Automatizar la desactivación del proxy con un plugin

Llegamos a la solución más cómoda y la que realmente recomiendo si quieres olvidarte del tema. Hay dos plugins de WordPress, los dos gratuitos, los dos de código abierto, los dos hijos de la misma idea. Te cuento la historia rápida porque tiene su gracia.

El planteamiento original lo publicó David Carrero en GitHub, y era un plugin que consulta hayahora.futbol cada X minutos y, si detecta bloqueos activos, llama a la API de Cloudflare para poner en gris las nubes de los registros DNS que tú elijas. Cuando los bloqueos terminan, las vuelve a poner en naranja.

Sobre esa primera versión hice una adaptación (un fork dicho en friki) en mi GitHub donde fui simplificando la interfaz, pensando más en el usuario final que en el técnico, añadiendo avisos por email, opciones de omisión manual, límite de operadores y unas cuantas mejoras más. Esas mejoras han ido pasando con el tiempo al plugin original, que ahora está publicado en el directorio de WordPress.org, así que por una cosa o por otra son prácticamente hermanos.

Así que tienes dos opciones, según prefieras:

ES Football Bypass for Cloudflare (en WordPress.org)

Es el plugin de David Carrero, instalable directamente desde Plugins → Añadir nuevo buscando «ES Football Bypass for Cloudflare».

Si te gusta tirar de directorio oficial con actualizaciones automáticas, es el camino más cómodo. Tiene dos modos de interfaz (simple y avanzado), admite Global API Key y para API Tokens de Cloudflare, diagnóstico del feed, panel de «¿Hay fútbol ahora?» para enseñarle al cliente, y notificaciones por email.

¿Hay ahora fútbol? – Bypass #LaLigaGate (en GitHub)

Es mi adaptación, disponible en github.com/fernandotellado/bypass-laligagate.

Hace exactamente lo mismo, consultar hayahora.futbol, gestionar la API de Cloudflare y automatizar el bypass. La descarga es manual (te bajas el zip y lo subes a tu WordPress) porque no está publicado en WordPress.org, y lo creé y mantengo principalmente para mis clientes del servicio de mantenimiento, pero está abierto al que quiera usarlo.

Al estar fuera del directorio oficial las actualizaciones son manuales también, así que valóralo según lo cómodo que estés con ese flujo.

¿Que por qué no lo he subido a wordpress.org?, pues porque ya estaba en ese proceso el de David, y porque esto es temporal (espero) y no me gusta subir plugins a WordPress para cosas que son temporales.

Cualquiera de los dos te resuelve el problema.

Si quieres comodidad de instalación y actualización automática vete al de WordPress.org. Si prefieres una versión que voy puliendo casi a diario, según los baches que voy encontrando con mis clientes y los usuarios que se han ido apuntando, el que tengo en GitHub funciona perfectamente, y como soy un intenso casi siempre tendrá alguna cosilla más.

Lo que tienes que tener a mano para configurarlos

Da igual cuál de los dos uses, vas a necesitar:

• El ID de zona de tu dominio en Cloudflare. Lo tienes en el panel principal del dominio, abajo a la derecha.
• Conexión con la API de Clouflare, y tienes dos posibilidades, ambas funcionan sin problema:
  • Un token de API de Cloudflare con permisos de Zone:Read, DNS:Read y DNS:Edit. Lo creas en My Profile → API Tokens → Create Token → Custom Token.
  • La Global API Key, disponible en tu perfil de Cloudflare, más sencilla de usar, porque no tienes que configurar nada, aunque es como más seguro usar el anterior, porque eliges qué permisos das y cuáles no.
• Decidir qué registros DNS quieres que se gestionen. Lo normal es activar el bypass solo en los registros del dominio principal y de www, y dejar tranquilos los de correo (MX, registros de Google Workspace, etc.) que no están afectados.

Una vez configurado el plugin (cualquiera de los dos) se encarga solo. Te puede mandar un email cuando active el bypass y otro cuando lo desactive, por si quieres tener constancia, pero es opcional. Los ajustes son casi iguales en ambos plugins también, yo soy más pijotero con la interfaz, David más puntilloso con la información técnica.

Aquí te dejo unas capturas del mío, pero se llevan poco…

Si has llegado a este artículo desde un buscador y resulta que tienes una tienda hecha con PrestaShop en vez de WordPress, también hice una versión (me la pidieron), bypass-laligagate-prestashop. Funciona todo igual, pero en vez de plugin WordPress es un módulo para Prestashop (sí, yo también fui de Prestashop).

Si recibes un email de LaLiga (sí, está pasando)

Para ir terminando, ahora que ya sabes qué hacer (o no) y cómo actuar, por si acaso, te cuento esta mierda, que lo es.

Desde agosto de 2025 LaLiga manda correos a propietarios de webs que comparten IP con sitios señalados como piratas. El correo suele venir de un email de la liga o desde Cloudflare a través del sistema de notificaciones ICANN, y te avisa de que «tu web está en una IP usada para distribuir contenido ilegal» y sugiere que pidas a Cloudflare que te asigne otra IP que no se comparta con piratas.

Si te llega uno, no te asustes:

• No es una demanda, es una notificación para presionar, y de paso lo usan de márketing propio.
• Tu web no ha hecho nada ilegal, solo comparte una IP con otra que sí. Es como si te dicen que en tu edificio vive un traficante en el 4º C y tú vives en el bajo o incluso en el portal de al lado.
• La solución técnica que LaLiga sugiere (pedir IP no compartida a Cloudflare) no es factible para clientes del plan gratuito ni del Pro. Hace falta plan Business o Enterprise para tener IPs dedicadas, y aún así no es trivial.
• La solución de verdad es la misma de la que llevamos hablando todo el artículo, o sea desactivar tu web del proxy de Cloudflare, manual o automáticamente, para que tu tráfico no pase por esas IPs durante los bloqueos y ¡a tomar por culo ya!.

Guarda el correo por si hace falta para registrarte en plataformas de afectados como afectadosporlaliga.palbin.com, que documenta estos casos.

Lo que no recomiendo (y por qué)

Hay un par de «soluciones» que circulan por ahí y que no aplican si lo que tienes es una web WordPress propia y afectada:

• Recomendar a tus visitantes que usen una VPN: Sirve para que ellos puedan saltarse el bloqueo en su navegación, pero no es práctico ni razonable pedir a tus usuarios que se instalen software adicional para entrar en tu tienda online o leer tu blog. Una VPN soluciona el lado del visitante, lo tuyo es solucionarlo en el lado del servidor.
• Cambiar de hosting: El hosting no es el problema. El problema está en el CDN delante del hosting (Cloudflare) y en el bloqueo que aplican las operadoras. Cambiar de hosting sin cambiar la configuración DNS no soluciona absolutamente nada.
• Esperar a que se arregle solo: Lleva año y pico sin arreglarse, hay una proposición no de ley (que no implica nada), está en manos del Tribunal Constitucional, Cloudflare ha tenido que ir a Estados Unidos a quejarse, pero la Comisión Europea por ahora avala a LaLiga. No esperes nada rápido.

¿Tengo que hacer algo ya mismo?

Si has llegado hasta aquí y todavía no sabes por dónde tirar, este es el plan mínimo:

1. Entra en hayahora.futbol cuando haya partido de la liga de fútbol española, mete tu dominio y comprueba si estás afectado.
2. Si lo estás y tienes Cloudflare activo, abre el panel DNS de Cloudflare y prueba a poner en gris las nubes de los registros A, AAAA y CNAME de tu dominio principal. Hazlo justo antes del próximo partido y observa qué pasa.
3. Si funciona y no quieres estar pendiente cada fin de semana, instala uno de los dos plugins de bypass que hemos visto (el de WordPress.org o el de GitHub) y configúralo con tu ID de zona y demás (mira arriba).
4. Si tu web no recibe ataques constantes ni necesita CDN global, plantéate dejar de usar de Cloudflare y apuntar al servidor.
5. Si te llega un correo de LaLiga, guárdalo, no te asustes, y aplica las soluciones técnicas. No requiere respuesta legal por tu parte.

Ojalá este artículo deje de tener sentido pronto. Mientras tanto, si tienes que mantener una web WordPress operativa los fines de semana en España, ya sabes lo que toca.

Si usas Visual Studio Code, Figma, Notion o Spotlight en Mac ya sabes cómo funciona, escribes lo que necesitas, seleccionas y listo. WordPress incorporó esta misma idea en la versión 6.3 y desde entonces la ha ido ampliando hasta convertirla en una de las herramientas más útiles del admin.

En este artículo te explico todo lo que puedes hacer con ella, con ejemplos prácticos y trucos para sacarle partido. Y si eres desarrollador y quieres añadir tus propios comandos, tendrás un artículo dedicado muy pronto.

Cómo se abre la paleta de comandos

Tienes dos formas de abrirla:

• Con el teclado: Es lo más rápido. Pulsa Cmd+K en Mac o Ctrl+K en Windows y aparece un cuadro de búsqueda centrado en la pantalla. Empieza a escribir y verás los resultados filtrarse en tiempo real.
• Con el ratón: Haciendo clic en la barra de título que aparece en la parte superior del editor del sitio o del editor de entradas. Desde WordPress 7.0 hay además un icono de búsqueda en la barra de admin que la abre directamente, sin necesidad de recordar el atajo.

Para cerrarla, da igual como la abriste, pulsa Escape o haz clic fuera del cuadro.

Dónde funciona

La paleta de comandos ha ido ganando terreno con cada versión de WordPress:

• WordPress 6.3 (agosto 2023): Primera versión. Solo disponible en el editor del sitio y en el editor de entradas/páginas.
• WordPress 6.8 (abril 2025): Se añadieron dos comandos nuevos, «Añadir nueva página» y «Abrir editor del sitio», disponibles desde el editor de entradas.
• WordPress 6.9 (diciembre 2025): Salto grande. La paleta pasó a estar disponible en todo el panel de administración, no solo en los editores. Los comandos de navegación se movieron a un paquete propio (@wordpress/core-commands) para que funcionasen en cualquier pantalla del admin.
• WordPress 7.0 (previsto para 2026): Se añade un botón visible en la barra de admin para que no dependas del atajo de teclado.

Qué puedes hacer con la paleta de comandos

Los comandos disponibles cambian según dónde estés, no ofrece lo mismo al estar editando una entrada que navegando por el panel de administración. La paleta es contextual, y eso está bien porque así no te llena de opciones que no vienen a cuento.

Comandos de navegación (disponibles en todo el admin)

Estos son los que más vas a usar. Te permiten saltar directamente a cualquier sección del admin escribiendo su nombre:

• Ir a entradas, páginas, medios, comentarios.
• Ir a plugins, temas, usuarios.
• Ir a los ajustes (generales, escritura, lectura, etc.).
• Ir a las pantallas de cualquier plugin que tenga menú en el admin (esto lo registra WordPress automáticamente).
• Añadir nueva entrada o nueva página.

Escribes el nombre de tu plugin y te salen sus submenús, super fácil y rápido.

Comandos del editor del sitio y del editor de entradas

Cuando trabajas en el editor del sitio (Apariencia → Editor) o en el editor de entradas y páginas, la paleta añade comandos específicos del contexto. Por ejemplo: resetear plantillas, abrir los estilos, activar el modo sin distracciones, cambiar de vista, editar la plantilla de la entrada actual o publicar directamente.

Búsqueda de contenido

Además de comandos, la paleta te permite buscar entradas y páginas por su título. Escribes el nombre y te aparece con la opción de ir directamente a editarla. Viene muy bien cuando tienes cientos de entradas y no quieres pasar por la lista de «Todas las entradas» para encontrar la que buscas.

Lista completa de comandos

La lista crece con cada versión de WordPress, así que para no quedarnos cortos puedes consultar la lista oficial actualizada en la documentación de WordPress.org y, si quieres ver el código fuente donde se registran, lo tienes en el repositorio de Gutenberg en GitHub. Aunque la mejor forma de descubrirlos es abrir la paleta y empezar a escribir.

Trucos para dominar la paleta de comandos de WordPress

• Escribe solo las primeras letras: No necesitas escribir el comando completo. Con «plu» ya te aparece «Ir a plugins». Con «est» te salen las opciones de estilos. La paleta filtra sobre la marcha y normalmente con dos o tres letras ya tienes lo que buscas.
• Usa las flechas del teclado para moverte: No necesitas el ratón para nada. Flechas arriba y abajo para seleccionar, Enter para ejecutar. Es la forma más rápida de trabajar.
• Aprende los cinco o seis comandos que más repites: Si todos los días creas entradas, editas páginas y revisas comentarios, esos tres saltos con Cmd+K te ahorran un montón de clics y segundos de espera entre páginas del admin.
• Combínala con los atajos de teclado del editor: La paleta de comandos va muy bien junto con los atajos del editor de bloques. Por ejemplo, puedes usar Cmd+K para saltar a una entrada, / para insertar un bloque sin tocar el insertador, y Cmd+Shift+D para duplicar un bloque. Todo sin soltar el teclado.

Limitaciones que debes tener en cuenta

La paleta de comandos es útil, pero tiene sus límites:

• No funciona en la parte visible de la web: Solo en el panel de administración. Si estás viendo tu web como visitante, el atajo no hace nada.
• Necesitas un tema de bloques para el editor del sitio: Los comandos específicos del editor del sitio (plantillas, estilos, patrones) solo aparecen si usas un tema de bloques como Twenty Twenty-Five. Con un tema clásico, la paleta funciona pero con menos opciones.
• No hay forma de personalizar los comandos sin código: Como usuario, no puedes añadir ni quitar comandos. Eso requiere la API de JavaScript, que es lo que veremos en el artículo para desarrolladores.
• Conflicto con Firefox en Mac: El atajo Cmd+K en Firefox abre la barra de búsqueda del navegador. WordPress sobreescribe este comportamiento dentro del editor, pero si estás en otra pantalla del admin puede que no funcione bien. En ese caso, haz clic en el icono de búsqueda de la barra superior o usa otro navegador.

Plugins y extensiones para hacer aún más

La paleta nativa está bien para navegar y ejecutar los comandos que trae WordPress de serie pero hay plugins que la llevan más lejos. Ojo, hay que distinguir entre los que amplían la paleta nativa y los que son alternativas independientes.

Plugins que amplían la paleta nativa

Algunos plugins ya registran sus propios comandos dentro de la paleta de WordPress. Cuando los instalas, sus opciones aparecen junto a las de serie al pulsar Cmd+K.

• Block Visibility es uno de los pocos que ya lo hace. Añade un comando para gestionar las condiciones de visibilidad directamente desde la paleta, sin tener que buscar la opción en los ajustes del bloque.
• WP Command Palette de Alley Interactive (disponible en GitHub) va un paso más allá y registra automáticamente todos los elementos del menú del admin como comandos en la paleta nativa. Es decir, cualquier opción que tengas en el menú lateral, la encuentras escribiéndola en Cmd+K.

En el artículo sobre cómo añadir comandos a la paleta veremos cómo un desarrollador puede hacer que su plugin se integre en la paleta de comandos de esta manera, con un ejemplo real usando el plugin Multiple Sale Prices Scheduler.

Alternativas independientes

Antes de que WordPress incluyera la paleta en la versión 6.3, ya existían plugins que ofrecían lo mismo (y en algunos casos más). Estos funcionan de forma independiente, con su propia interfaz:

• Turbo Admin lleva años en el repositorio de WordPress.org y funciona como plugin o como extensión de navegador. Tiene su propia paleta de comandos con búsqueda de contenido por tipo (entradas, páginas, usuarios), atajos personalizables y un modo que limpia la barra de admin ocultando lo que no necesitas. Es gratuito, pero no funciona con las últimas versiones de WordPress, no le veo mucho futuro, ni siquiera presente, una pena.
• CommandUI es una extensión de pago que funciona en el navegador sin instalar nada en WordPress. Ofrece navegación instantánea por todo el admin, integración con Elementor, Bricks y Divi (puedes abrir directamente una página en el maquetador), y un sistema de atajos contextuales.
• WPCommand es otra extensión de navegador (también de pago) que detecta automáticamente qué maquetador se usó en cada página y te deja editarla directamente desde la paleta. No instala nada en tu WordPress, funciona solo en tu navegador.

La diferencia principal es que la paleta nativa es gratuita, viene con WordPress, no necesita nada extra y seguirá mejorando con cada versión. Las alternativas tienen más funcionalidades hoy, pero apuestan a que WordPress no las alcance. Tú decides qué necesitas.

Qué nos espera en el futuro

El equipo de desarrollo de WordPress tiene bastantes planes para la paleta. En el issue de seguimiento en GitHub puedes ver un resumen de todo lo que se está trabajando. Las líneas principales son:

• Agrupación de resultados: Ahora todos los resultados de búsqueda aparecen mezclados. La idea es separarlos por categoría (comandos, entradas, páginas, plantillas) para que sea más fácil encontrar lo que buscas cuando hay muchos resultados.
• Más comandos contextuales: Que los comandos disponibles se adapten mejor a lo que estás haciendo. Si estás editando un producto de WooCommerce, que aparezcan opciones específicas de productos. Si estás en una plantilla, que aparezcan las de plantillas.
• Atajos globales: Poder ejecutar acciones frecuentes (como previsualizar o publicar) con un atajo directo, sin pasar por la paleta.
• Más adopción por parte de plugins: A día de hoy, muy pocos plugins registran comandos propios en la paleta. Esto irá cambiando a medida que la API se estabilice y más desarrolladores la conozcan.

Y luego está lo que a mi me gustaría, y es que fuese la interfaz para lanzar prompts IA a WordPress, con lo que se convertiría en la herramienta estrella sin rival, pero igual es mucho soñar. Yo de momento ya se lo tiré a uno de los desarrolladores del proyecto.

¡Ya deberías estar usándola!

Si no la has probado todavía, abre tu WordPress, pulsa Cmd+K (o Ctrl+K) y escribe lo primero que se te ocurra. Aunque sea «entradas» o «ajustes». En cuanto veas lo rápido que saltas de una pantalla a otra sin pasar por menús, no vas a querer volver a navegar como antes.

Y si eres desarrollador y quieres que tu plugin aparezca en la paleta con sus propios comandos, estate atento al próximo artículo donde te explico cómo hacerlo paso a paso, con un ejemplo real y código listo para adaptar. Mientras tanto, a lanzar comandos a la paleta, verás como mejora tu rendimiento usando WordPress.

No hace falta que seas un medio importante ni una tienda con mucha facturación para que te caiga uno encima. Los ataques automatizados no discriminan, a veces eres tú el objetivo y otras veces solo eres una IP más en una lista, pero el efecto es el mismo en cualquiera de los dos casos: tu web se arrastra o se cae del todo.

Lo bueno es que con las defensas adecuadas puedes frenar la mayoría de estos ataques, y lo que no puedas parar al 100% al menos lo vas a aguantar sin que se te venga todo abajo.

Vamos a ver cómo montar esa protección por capas, desde el DNS hasta la propia configuración de WordPress, con ejemplos que puedes adaptar a tu web.

Algunas cifras para que te hagas una idea

• Cloudflare bloqueó 20,5 millones de ataques DDoS solo en el primer trimestre de 2025, casi lo mismo que en todo 2024 junto.
• Los ataques a la capa de aplicación, que son los que más afectan a WordPress, crecieron un 118% interanual a principios de 2025.
• El 94% del tráfico de ataque ya va cifrado con HTTPS, lo que complica enormemente el filtrado.
• En sitios sin protección, el 98% de las peticiones a /wp-admin/ es tráfico de ataque y no usuarios reales.
• El 89% de los ataques duran menos de 10 minutos, menos de lo que tardas en llamar al soporte.
• Contratar un DDoS-as-a-service en la red cuesta desde unos 35 euros la hora, al alcance de cualquier aburrido con tarjeta.
• El ataque más grande registrado hasta la fecha alcanzó los 31,4 Tbps en diciembre de 2025.

Con estos números encima de la mesa, no se qué pensarás, pero yo creo que ignorar el tema no es una opción.

Qué es exactamente un ataque DDoS

DDoS son las siglas de Distributed Denial of Service, o sea, denegación de servicio distribuida.

La traducción al román paladino es bastante simple, porque lo que hace el atacante (que puede ser un tipo, un grupo o una red automatizada) es mandar tantísimas peticiones a tu web desde muchísimos sitios distintos a la vez que tu servidor no puede con todo y acaba petando, o va tan lento que es como si se hubiera caído.

La palabra clave aquí es «distribuido». Un ataque desde una sola IP lo paras con bloquear esa IP y listo, pero lo que hace peligroso al DDoS es que vienen miles o millones de peticiones desde IPs diferentes, muchas de ellas de ordenadores y dispositivos infectados sin que sus dueños lo sepan, lo que se conoce como botnets.

Qué NO es un ataque DDoS

Esto es importante que lo tengas claro desde el principio, porque se mezcla mucho. Estas cosas no son DDoS aunque los efectos a veces se parezcan:

• Un artículo tuyo que se vuelve viral y te manda miles de visitas en una hora es tráfico legítimo, por mucho que te tumbe el hosting.
• Un bot de entrenamiento de IA que pasa por tu web sacando datos a pelo es scraping agresivo, no un ataque.
• Una herramienta de SEO mal configurada que te machaca con peticiones es un bot gamberro, no un atacante.
• Un plugin con un bucle infinito que genera peticiones a wp-cron cada dos segundos es un fallo de configuración, no un DDoS.

¿Y el scraping agresivo de las IAs?

Para que te hagas una idea del lío que hay con esto, en julio de 2024 el CEO de iFixit denunció que ClaudeBot (el rastreador de Anthropic) había hecho casi un millón de peticiones a su web en 24 horas. Mucha gente lo llamó DDoS, pero técnicamente no lo era porque era un bot de entrenamiento sacando datos sin freno.

El efecto (servidores reventados y equipo corriendo a apagar el fuego) sí que recuerda mucho a un DDoS, y las defensas se solapan bastante, porque un rate limiting bien puesto te frena tanto a un atacante como a un bot chungo.

Pero no son lo mismo. Un DDoS lo lanza alguien con intención de hacerte daño, mientras que un bot de IA, aunque se pase catorce pueblos, solo quiere datos. Por eso en este tutorial me centro en los ataques con malas intenciones, que es lo que de verdad duele, aunque muchas de las soluciones te van a servir también para mantener a raya a los bots pesados.

Los 3 tipos de DDoS que existen

No todos los ataques son iguales, así que para defenderte bien tienes que saber contra qué te estás defendiendo.

Ataques volumétricos

Son los más antiguos y los más aparatosos. El atacante inunda tu conexión con una cantidad bestial de tráfico que satura el ancho de banda antes de que los datos lleguen a tu servidor, como si intentase meter el agua del mar por una manguera de jardín.

Contra esto no puedes hacer absolutamente nada desde WordPress, ni siquiera desde tu hosting.

El tráfico ya te ha petado la red antes de que tú puedas reaccionar, así que la única defensa real está en la capa CDN, que es donde Cloudflare y demás tienen infraestructura suficiente como para absorber estos volúmenes.

Ataques de protocolo

Estos van contra las debilidades de los protocolos de red, y el más conocido es el SYN flood, que manda millones de peticiones de conexión TCP sin completarlas para llenar la tabla de conexiones del servidor hasta que no puede aceptar ni una legítima.

Tampoco se paran desde WordPress, se paran en el firewall del servidor, en el hosting o en la CDN.

Ataques a la capa de aplicación (capa 7)

Los ataques de capa 7 mandan peticiones HTTP o HTTPS que parecen totalmente legítimas, no saturan tu ancho de banda ni inundan la red, sino que simplemente le piden a tu WordPress que haga cosas caras una detrás de otra sin parar, hasta que PHP y MySQL se rinden.

Los puntos más castigados en WordPress son:

• wp-login.php, para ataques de fuerza bruta disfrazados de DDoS.
• xmlrpc.php, que permite probar cientos de contraseñas en una sola petición.
• admin-ajax.php, que muchos plugins usan sin autenticación.
• La búsqueda interna, que genera consultas pesadas a la base de datos.
• La API REST, si no está bien protegida.
• wp-cron.php, si se ejecuta en cada petición.

Este es el tipo de ataque que puedes (y debes) parar desde tu propia web, tu servidor y tu CDN.

¡Pero si mi web no le importa a nadie! ¿por qué me van a atacar a mi?

Si piensas «a mí quién me va a atacar, si mi web no es nadie» estás cometiendo un error muy común, porque los ataques DDoS no siempre van contra objetivos importantes y ni siquiera tienen siempre un motivo racional.

Estas son las razones habituales, de más a menos graves:

• Extorsión: Alguien te escribe diciendo que si no le pagas X cantidad en criptomonedas te tumba la web, y si no pagas la tumba un rato para demostrar que puede. Es más habitual de lo que parece, sobre todo en tiendas online antes de eventos de venta importantes.
• Competencia desleal: Un competidor cabronazo contrata un ataque el día de tu campaña pre-navideña o el lanzamiento de un producto. Parece película, pero pasa, hay gente muy joputa por ahí.
• Hacktivismo: Si tu web tiene contenido que alguien considera ofensivo o contrario a sus ideas, te puede caer un ataque por motivos ideológicos.
• Cortina de humo: El DDoS es ruidoso y lo ve todo el mundo, así que mientras tú y tu equipo estáis apagando ese fuego, otro atacante aprovecha para meterse por la puerta de atrás sin que nadie le mire.
• Venganza personal: Un ex-empleado cabreado o un cliente insatisfecho que ha echado mano de un servicio de DDoS por horas.
• Pruebas de gilipollas aburridos: Los llamados script kiddies, niñatos con tiempo libre que prueban herramientas contra cualquier web que encuentren, sin motivo, por diversión.
• Daño colateral: Estás en un hosting compartido (de los malos) y el ataque va contra otro cliente, pero tu web se va al carajo porque comparte servidor.
• Automatización: Hay botnets que escanean internet buscando WordPress vulnerables y lanzan ataques de prueba para ver qué aguanta, y si tu web aguanta mal se centran en ti.

Con los servicios de DDoS-as-a-service por unos pocos euros la hora, la barrera de entrada para atacar a alguien es ridícula y cualquiera puede lanzar un ataque sin saber ni lo que está haciendo.

Cómo saber si estás bajo ataque

Lo primero para defenderte es darte cuenta de que estás pasando por un ataque. Estos son los síntomas más habituales:

• La web va muy lenta o directamente no carga, con errores 502 o 504.
• El panel del hosting muestra la CPU disparada o la base de datos al límite.
• Picos de tráfico enormes desde países o regiones donde no tienes audiencia.
• Miles de peticiones por minuto a una URL concreta, normalmente wp-login.php, xmlrpc.php o admin-ajax.php.
• El soporte del hosting te avisa de que estás consumiendo recursos excesivos.
• Caídas intermitentes cada pocos minutos sin motivo aparente.

Herramientas para confirmarlo

Antes de ponerte nervioso confirma que es un ataque real y no un problema tuyo. Puedes usar estas herramientas, todas gratuitas:

• Logs de acceso del hosting: Míralos directamente, cualquier panel decente te los da. Busca picos anormales y repeticiones sospechosas de la misma IP o User-Agent.
• Query Monitor: Esta joya bendita en forma de plugin de WordPress te enseña qué está pasando por dentro.
• AbuseIPDB: Para comprobar si las IPs que sospechas están reportadas por abuso.
• Sucuri SiteCheck: Escaneo rápido y gratis.
• El dashboard de Cloudflare: Si lo tienes configurado, que muestra con mucho detalle qué tipo de tráfico estás recibiendo.

Defensa por capas, que es lo que funciona

No hay una sola solución contra los DDoS, lo que funciona es montar varias capas de defensa para que cada una frene un tipo de ataque distinto. Si una falla las demás aguantan el tipo. Vamos capa por capa.

Capa 1: DNS y CDN

Esta es la primera barrera y la más importante contra los ataques volumétricos y de protocolo. Básicamente, en vez de que el tráfico llegue directamente a tu servidor, pasa primero por una red de servidores enorme que filtra lo malo antes de dejar pasar lo bueno.

Las opciones más habituales son:

• Cloudflare, que tiene un plan gratuito con protección básica contra DDoS y un WAF limitado.
• BunnyCDN, con precio asequible y buena infraestructura europea.
• QUIC.cloud, especialmente interesante si usas LiteSpeed Cache.
• Sucuri, algo más caro pero con WAF y limpieza incluida.

Si ya usas Cloudflare activa el modo «Under attack» en cuanto detectes algo raro, porque ese modo añade una página de verificación JavaScript que los bots no pasan pero los humanos sí. Tienes la guía detallada en el artículo sobre cabeceras de seguridad HTTP, que complementa muy bien esta configuración.

Capa 2: Hosting

Un buen hosting WordPress te pone el trabajo mucho más fácil, porque los hosting gestionados de calidad tienen su propio WAF, detección de anomalías, limitación de recursos por cuenta y soporte técnico que reacciona rápido si te están atacando. Los hosting compartidos de medio pelo, en cambio, te van a dejar tirado en cuanto la cosa se ponga seria.

Si buscas un hosting que se tome en serio la seguridad yo uso y recomiendo SiteGround, que incluye WAF con reglas específicas para WordPress, mitigación automática de ataques pequeños y un panel de seguridad bastante completo. Afortunadamente hay buenos hostings españoles y europeos dignos para estas cosas, en eso casi hasta tenemos suerte. ¿Fuera? todo es campo.

Capa 3: Servidor

Aquí empezamos con lo jugoso. El archivo .htaccess, si estás en Apache o LiteSpeed (que es lo más común en hosting para WordPress), te deja bloquear peticiones antes incluso de que PHP se entere de que existen. Es rapidísimo y consume pocos recursos, así que es la primera línea real de defensa dentro de tu servidor.

Todas las reglas que siguen se añaden al archivo .htaccess que tienes en la raíz de tu WordPress, antes de las reglas que ya hay de WordPress. Haz siempre una copia de seguridad del archivo antes de tocarlo.

Bloqueo por User-Agent

Muchos bots atacantes y scrapers se identifican con cadenas reconocibles, así que bloquearlos por User-Agent te quita de encima un montón de ruido.

# Bloquear bots conocidos por abusivos
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (ahrefsbot|semrushbot|mj12bot|dotbot|petalbot|megaindex) [NC]
RewriteCond %{HTTP_USER_AGENT} (seokicks|blexbot|sogou|baiduspider|yandexbot) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (zoominfobot|serpstatbot|barkrowler|dataforseobot) [NC]
RewriteRule .* - [F,L]
</IfModule>

Advertencia: esto no te sirve contra atacantes serios, que falsifican el User-Agent sin problema, pero te quita de encima mucho scraper honesto (dentro de lo que cabe) y algunos bots de SEO cansinos que te consumen recursos a saco.

Restricción de métodos HTTP

WordPress solo necesita los métodos GET, POST y HEAD para funcionar. Si tu web no tiene una API que use otros métodos bloquea el resto.

# Solo permitir métodos HTTP necesarios
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_METHOD} !^(GET|POST|HEAD)$
RewriteRule .* - [F,L]
</IfModule>

Si usas la REST API con PUT o DELETE (por ejemplo desde un plugin como WooCommerce Bookings o una app móvil), añade esos métodos a la lista.

Protección de xmlrpc.php

XML-RPC es un vector de ataque clásico. Si no lo usas (la mayoría de webs no lo necesitan hoy en día), bloquéalo del todo.

# Bloquear acceso a xmlrpc.php
<Files xmlrpc.php>
    Require all denied
</Files>

Si lo necesitas (Jetpack, por ejemplo, aunque cada vez menos), permite solo los accesos desde las IPs autorizadas, entonces mete algo así:

# Permitir xmlrpc.php solo desde IPs concretas
<Files xmlrpc.php>
    Require ip 192.0.66.0/24
    Require ip 195.234.108.0/22
</Files>

Protección de wp-cron.php

El cron de WordPress se ejecuta por defecto cada vez que alguien visita tu web, y puede ser un punto de abuso. Lo mejor es desactivar esa ejecución automática y poner un cron real del servidor, pero de paso bloquea el acceso externo directo al archivo.

# Bloquear acceso externo a wp-cron.php
<Files wp-cron.php>
    Require all denied
</Files>

Para que el cron siga funcionando añade esto a tu wp-config.php:

define( 'DISABLE_WP_CRON', true );

Y luego configura un cron real en el panel del hosting que lance wp-cron.php cada 15 minutos o cada hora, según lo que necesite tu web.

Protección reforzada de wp-login.php

El login es el objetivo número uno de los ataques de fuerza bruta disfrazados de DDoS. Esta regla limita el acceso a wp-login.php solo desde tu IP, ideal si trabajas siempre desde el mismo sitio.

# Acceso a wp-login.php solo desde IPs autorizadas
<Files wp-login.php>
    Require ip 81.123.45.67
</Files>

Nota: Cambia 81.123.45.67 por tu IP pública real. Si tienes IP dinámica esto no te vale, y en ese caso mejor usa un plugin que cambie la URL del login (lo vemos más adelante).

Limitar el tamaño de las peticiones

Algunos ataques mandan peticiones POST enormes para tumbar el servidor, así que limita el tamaño máximo.

# Limitar tamaño máximo de petición a 10 MB
LimitRequestBody 10485760

Si tu web sube archivos grandes (vídeos, por ejemplo), ajusta el valor a lo que realmente necesites, pero no lo dejes nunca sin límite.

Bloqueo de IPs concretas

Cuando identifiques IPs atacantes en tus registros bloquéalas directamente.

# Bloquear IPs concretas
<RequireAll>
    Require all granted
    Require not ip 123.45.67.89
    Require not ip 98.76.54.32
    Require not ip 10.20.30.0/24
</RequireAll>

Bloqueo de hotlinking

El hotlinking es cuando otras webs enlazan tus imágenes directamente desde sus servidores, usando tu ancho de banda. No es un DDoS, pero el efecto acumulado es parecido.

# Evitar hotlinking de imágenes
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?tudominio\.com [NC]
RewriteRule \.(jpe?g|png|gif|webp|svg)$ - [F,NC,L]
</IfModule>

Nota: Cambia tudominio.com por el tuyo, claro.

Capa 4: WordPress

Aunque tengas bien montadas las capas anteriores, desde WordPress también puedes (y debes) apretar tuercas. Estas son las configuraciones que se notan más:

• Desactivar XML-RPC si no lo usas, y además de la regla htaccess hay plugins que lo hacen con un clic.
• Ocultar la URL del login, porque si los bots no encuentran wp-login.php no pueden atacarlo.
• Proteger la REST API, restringiendo quién puede acceder a /wp-json/ y sus endpoints, que es fundamental para evitar enumeración de usuarios y abuso de endpoints. Si te interesa profundizar tienes el artículo sobre enumeración de usuarios que cubre este tema.
• Limitar intentos de login, imprescindible contra la fuerza bruta.
• Desactivar pingbacks y trackbacks, que son una vía de amplificación de ataques.
• Usar 2FA en todas las cuentas con privilegios, que no para el DDoS directamente pero evita que si una cuenta cae bajo fuerza bruta el atacante entre de verdad.

Plugins anti-DDoS para WordPress ¿los hay?

No hay un plugin que por sí solo te proteja de todo, pero sí hay plugins que implementan varias de las defensas que hemos visto y te ahorran tener que configurarlas una por una. Estos son los más completos para la parte que te interesa.

Mi recomendación de amigo es que pruebes Vigilante, que es mío, por si no lo sabías. Lo hice precisamente porque los demás tenían limitaciones en la parte de métodos HTTP y REST API, que son puntos calientes para los DDoS en WordPress, y además es gratis total, sin versión premium ni cosas de pago escondidas.

Si ya usas Wordfence, Solid Security o AIOS ninguno está mal (bueno, WF sí, lo odio bastante), y pasarse a otro solo por el cambio no suele merecer la pena. Lo que no debes hacer nunca es ejecutar dos plugins de seguridad a la vez, porque te vas a encontrar conflictos raros y vas a bajar el rendimiento sin ganar nada a cambio.

Sobre los bots de IA, el añadido de VigIA

Aunque no sean un DDoS en sentido estricto, los bots de entrenamiento de IA (GPTBot, ClaudeBot, Bytespider, PerplexityBot y compañía) pueden generar una carga bestial en tu servidor. Y aquí viene lo interesante, porque lo comprobé con mi propio plugin VigIA y de los archivos robots.txt pasan completamente, así que lo único que los para de verdad es bloquearlos por IP o por User-Agent a nivel de servidor, devolviéndoles un 403.

Si has puesto las reglas .htaccess anteriores ya estás bloqueando parte, y para rematarlo VigIA te muestra qué bots de IA están entrando, cuántas veces y qué páginas rastrean, y te deja bloquearlos con un clic. Si la carga te viene por ahí y no por un ataque real, tener VigIA instalado te ahorra el trabajo de identificar manualmente cada bot en los logs.

Qué hacer si te está pasando ahora mismo

Vale, has leído hasta aquí porque tu web está hecha mierda, medio caída o del todo, y quieres saber qué hacer ya. Este es el protocolo de crisis, paso a paso.

Paso 1: confirma que sea de verdad un DDoS

Mira los logs del hosting y tira de Query Monitor si puedes acceder al admin, y comprueba que hay un pico anormal de peticiones y que muchas vienen de IPs o patrones repetidos. Si ves tráfico normal pero la web va mal, igual es un problema de plugin o base de datos y no un ataque.

Paso 2: activa el modo bajo ataque en tu CDN

Si tienes Cloudflare mételo en modo Under Attack desde el dashboard, porque eso añade una pantalla de verificación JavaScript que filtra automáticamente a los bots. Lo notarás porque las visitas legítimas verán una pantalla de «Comprobando tu navegador» durante un par de segundos antes de acceder a tu web.

Si no tienes CDN y el ataque es serio, darte de alta en Cloudflare gratis y apuntar los DNS hacia él puede ser la solución más rápida. Tarda unas horas en propagarse, pero en cuanto lo hace el ataque se para en seco en la mayoría de los casos.

Paso 3: avisa al soporte de tu hosting

Un buen hosting tiene herramientas para identificar y bloquear ataques que tú desde fuera no tienes, así que abre un ticket, cuéntales lo que ves y pídeles que revisen. Muchas veces ellos ven patrones que tú no y pueden aplicar medidas a nivel de red.

Paso 4: bloquea lo que puedas bloquear

Si identificas IPs o rangos atacantes en los logs bloquéalas en htaccess con las reglas que hemos visto, y si el ataque viene de un país donde no tienes audiencia plantéate bloquear el país entero temporalmente (esto se hace en Cloudflare con una regla de firewall).

Paso 5: activa la página de mantenimiento si no te queda otra

Si nada de lo anterior frena el ataque, pon una página de mantenimiento estática para ganar tiempo. Una página HTML simple sin PHP ni base de datos la puede servir cualquier servidor bajo cualquier carga. No es una solución, es un parche para que al menos los usuarios que llegan vean algo en vez de un error.

Paso 6: documenta todo

Mientras pasa el ataque guarda capturas del escritorio, logs, IPs atacantes y horarios, porque lo vas a necesitar para el análisis posterior y, si llega el caso, para denunciarlo.

Después del ataque, el post-mortem

El ataque se ha acabado y tu web funciona otra vez, así que ahora toca aprender para que la próxima no te pille igual.

• Analiza los logs: ¿Qué URL fue el objetivo principal? ¿Qué IPs o User-Agent destacaron? ¿Qué hora del día fue? ¿Se nota un patrón?
• Revisa qué defensas funcionaron y cuáles no: Si tu WAF paró el 90% del tráfico, bien, pero si lo que te salvó fue activar el modo bajo ataque a lo loco, mala señal, porque la próxima vez igual no estás despierto para hacerlo.
• Ajusta las reglas: Añade las IPs atacantes a la lista negra permanente, y si el ataque fue a un endpoint concreto, refuérzalo.
• Considera si necesitas subir de plan: Si estabas en Cloudflare gratuito y el ataque casi te tumba, el plan Pro (unos 22 euros al mes) te da protección DDoS avanzada y un WAF mejor.
• Revisa si el DDoS fue cortina de humo: Comprueba logs de otros servicios, accesos al admin, usuarios nuevos y archivos modificados, para asegurarte de que mientras tú estabas apagando el incendio nadie entró por otro lado.
• Contrata ayuda profesional: Si después de todo te das cuenta de que necesitas ayuda aprende de la experiencia y no esperes al próximo desastre, déjate ayudar por alguien profesional que te ayude a protegerte, reforzar tu web y estar ahí cuando más lo necesites. Hay gente muy buena, y suele ser un servicio realmente barato si tienes en cuenta lo que obtienes frente a la (terrible) alternativa.

Lista rápida: protección anti-DDoS para WordPress

Te dejo el resumen de todo lo que hemos visto por capas, para que lo uses como guía de verificación en tu web.

Capa DNS y CDN

• Tengo Cloudflare (u otra CDN) configurado y apuntando los DNS.
• Tengo identificado cómo activar el modo bajo ataque si hiciera falta.
• Tengo reglas de firewall básicas configuradas en la CDN.

Capa hosting

• Estoy en un hosting WordPress con WAF propio y soporte 24/7.
• Tengo backups automáticos diarios.
• Tengo el número de soporte o el email a mano.

Capa servidor

• He bloqueado bots abusivos por User-Agent.
• He restringido los métodos HTTP a los necesarios.
• He protegido o bloqueado xmlrpc.php.
• He bloqueado el acceso externo a wp-cron.php y configurado cron real.
• He limitado el tamaño máximo de las peticiones.
• He protegido wp-login.php si mi IP es fija.
• He puesto reglas anti-hotlinking.

Capa WordPress

• Tengo un plugin de seguridad activo y configurado.
• Tengo 2FA activado para administradores.
• Tengo la URL del login cambiada.
• Tengo XML-RPC desactivado.
• Tengo la REST API protegida.
• Tengo límite de intentos de login configurado.
• Tengo pingbacks y trackbacks desactivados.
• Tengo WordPress, tema y todos los plugins actualizados.

Y hasta aquí

Tengo malas noticias, y es que los ataques DDoS no se evitan al 100%, y un ataque lo suficientemente grande te tumba aunque tengas todo bien configurado. Pero con las capas adecuadas la mayoría de ataques ni te enteras de que han pasado, y los que sí notas duran mucho menos y hacen mucho menos daño.

La clave está en no dejar nada a la improvisación.

Monta las defensas antes de necesitarlas, porque cuando estás bajo ataque no es el momento de ponerse a aprender cómo funciona Cloudflare o a editar .htaccess por primera vez. Empieza por las reglas básicas que he compartido, añade un buen plugin de seguridad y ten claro qué harías si mañana te pasa.

Si te surgen dudas con alguna configuración concreta déjame un comentario y lo vemos.

Crónicas WordPress: backdoors masivos, RC3 a la vista y wp-admin reinventado

El lunes empezamos por la parte fea. WordPress.org cerró Quick Page/Post Redirect tras descubrirse un backdoor que llevaba activo desde 2021, y poco después tumbaron más de 80 plugins de WPFactory por un posible backdoor en su plugin premium de IVA para WooCommerce.

El informe de WP-Firewall ya habla de más de 185 vulnerabilidades nuevas, así que herramientas como WP Beacon para vigilar la cadena de suministro se vuelven imprescindibles. Aprovechamos para repasar el plan de batalla contra ataques de fuerza bruta porque, viendo lo que está cayendo, hay que tomárselo en serio.

De ahí pasamos al culebrón de la comunidad, con un juez federal obligando a Matt Mullenweg a explicar bajo juramento los mensajes desaparecidos en el caso WP Engine, el Checkout Summit pasando a formato online y la campaña para ayudar a Lua a recuperarse de su lesión.

En la parte de desarrollo el plato fuerte es WordPress 7.0. La RC3 está agendada para el 8 de mayo, hubo una llamada urgente a hostings para probar la colaboración en tiempo real antes del día 4 y llega la Presence API en formato plugin, para ver en directo quién está editando qué en el escritorio.

También comentamos el Subscriptions Health Check de Woo, el experimento de dos ingenieros de Automattic convirtiendo wp-admin en un escritorio operativo (con tienda de apps incluida cortesía de Nick Hamze), el nuevo requisito europeo del enlace de retirada en WooCommerce y la desactivación del HPOS «sincronizar al leer» en WooCommerce 10.7.

Para cerrar, IA por todos lados. Repaso del Core AI Team, novedades del plugin AI 0.8.0 y el experimento de crear una web con IA en media hora con todo lo que vino después y nadie cuenta.

En IA y SEO, el AEO se consolida como categoría formal de servicio en abril, las AI Overviews ya aparecen en el 47 % de búsquedas en Estados Unidos y Perplexity escala a 780 millones de consultas mensuales convirtiendo once veces mejor que Google.

Y de propina, anuncio de la próxima quedada QDD WordPress sobre EmDash CMS.

Vídeo completo: Crónicas WordPress del 4 de mayo en YouTube.

Doctor WordPress: a punto para WordPress 7.0

El miércoles en el Doctor WordPress dediqué la sesión a dejar la casa lista para WordPress 7.0, que llega ya esta misma semana.

Repasamos qué hay que mirar en plugins y temas para que no salten chispas el día del despliegue, y qué tocar en webs en producción antes de actualizar: copias, entorno de pruebas, compatibilidad de código y revisión de los cambios en el editor y en la API.

Lo de siempre cuando hay versión mayor, mejor llegar con todo planchado que apagar fuegos el martes siguiente.

Como cada miércoles, también hubo tiempo para preguntas en directo de los asistentes sobre WordPress, SEO, IA y casi cualquier cosa que se cruzase por el camino.

Vídeo completo: Doctor WordPress del 6 de mayo en YouTube.

Si quieres asistir en directo y participar con tus preguntas, suscríbete al canal de Ayuda WordPress en YouTube.

Buena parte de lo que hayas leído estos días sobre la 7.0 va dirigido a desarrolladores, pero este artículo no. Aquí te cuento qué vas a notar en tu web WordPress, qué cosas se pueden romper y qué oportunidades nuevas tienes a partir de mayo.

Si desarrollas plugins o temas lo tienes en este otro artículo, específico con la parte técnica, este es para tu web.

¿Que ha pasado con las fechas?

WordPress 7.0 estaba previsto inicialmente para el 9 de abril, pero el equipo retrasó la salida unas semanas porque querían terminar de afinar la arquitectura de base de datos para la edición en tiempo real, una de las funcionalidades estrella de esta versión.

Mejor que se retrase un mes a que salga a medio hacer ¿no?, así que la fecha actual está fijada para el 20 de mayo de 2026, salvo sorpresa de última hora.

Qué novedades trae WordPress 7.0

Te pongo solo lo que vas a ver tú desde el escritorio o el editor, o que debes tener en cuenta sí o sí, sin entrar en APIs ni interioridades.

PHP 7.4 como mínimo

Si tu hosting todavía tiene PHP 7.2 o 7.3, no vas a poder actualizar a  la versión 7.0 y los sitios en esas versiones se quedan en la rama 6.9, así que esto es lo primero que tienes que comprobar.

Entra en el panel de tu hosting y mira qué versión de PHP estás usando, teniendo en cuenta que lo recomendable hoy es PHP 8.3 o superior.

Edición / colaboración en tiempo real

Varios usuarios pueden modificar una misma entrada o página al mismo tiempo, con los cambios sincronizándose en directo, parecido a Google Docs.

Es opcional y la activas desde Ajustes > Escritura, con un límite (inicialmente) de dos colaboradores simultáneos por entrada por defecto.

Nota: esta funcionalidad ha sido aplazada y no sale con WordPress 7.0, pero no deja de ser interesante que sepas cómo funciona porque más pronto que tarde estará disponible.

Pantalla nueva para tus IAs

En Ajustes > Conectores aparece una pantalla central donde configuras los proveedores de IA con tu propia clave API, e incluye OpenAI, Anthropic (Claude) y Google (Gemini) por defecto.

Una vez configurado un proveedor todos los plugins de IA compatibles pueden usar esas credenciales sin que tengas que volver a meterlas en cada plugin.

Escritorio con cara nueva

El admin estrena un rediseño visual al que han llamado darle una «mano de pintura», con tipografías unificadas, colores más coherentes (diferentes mas bien) y espaciados nuevos.

El esquema de color por defecto pasa del llamado «Fresco» al «Moderno», pero vamos, que lo cambias en tu perfil si quieres.

Cambios en los listados del editor del sitio

Las pantallas de listados del editor del sitio usan ahora una interfaz tipo aplicación, con filtros que se aplican sin recargar página y la posibilidad de elegir entre vista de tabla o de cuadrícula.

La navegación es sencilla, pero cambia el aspecto y la forma de filtrar, y hace que la navegación sea más fluida y personalizable. Es un cambio que vendrá más adelante a todos los listados de WordPress.

Bloques nuevos

Llegan los bloques nativos de migas de pan e icono, que hasta ahora dependían de plugins.

Biblioteca de fuentes

Tienes una pantalla dedicada para subir, previsualizar y aplicar fuentes personalizadas en todo el sitio y para todo tipo de temas, sin tirar de plugins ni declaraciones @font-face manuales.

Paleta de comandos

Pulsando Cmd+K en Mac o Ctrl+K en Windows abres un buscador rápido del escritorio que te lleva directo a editar una página, ir a un ajuste o instalar un plugin sin pasar por los menús.

Revisiones visuales

Cuando comparas versiones de una entrada ya no ves un diff de código en plan técnico, sino una comparación visual con los cambios resaltados.

Ocultar bloques por dispositivo

De lejos, lo que me parece un cambio más importante es poder (por fin) especificar qué bloques quieres mostrar/ocultar según el dispositivo desde el que se visite la página.

Esto dependía de plugins pero ya está en el editor de bloques nativo, que mira que les ha costado algo tan relevante y fundamental.

Lo que se puede romper al actualizar a WordPress 7.0

Aquí está la parte que más te interesa, y no es para asustar, pero conviene tenerlo claro antes de darle al botón de actualizar.

Plugins con botones desalineados o estilos rotos

El rediseño del admin trae cambios solo en CSS y no toca el HTML, lo que suena inofensivo pero no lo es tanto, porque todo plugin que use estilos propios para sus botones, tablas o avisos puede mostrarse desalineado a partir de la 7.0.

Pasa especialmente con plugins que tiraban de píxeles fijos, !important por todas partes o selectores muy agresivos.

Los plugins bien hechos, que usan las clases nativas del admin, no se ven afectados, mientras que los que llevan años sin actualizarse o los hechos a la rápida sí.

El aviso de «esta entrada usa plugins que no son compatibles con la colaboración en tiempo real»

Si activas la edición en tiempo real y abres una entrada te puede aparecer este aviso. Significa que algún plugin que tienes instalado añade una caja meta clásica a esa entrada, y las cajas meta clásicas no se sincronizan en tiempo real.

La colaboración se desactiva para esa entrada, pero todo lo demás sigue funcionando normalmente.

Sobre cómo identificar qué plugin es el culpable y qué hacer con él, lo tienes detallado en este artículo sobre plugins incompatibles con la colaboración en tiempo real.

Plugins que tocan las listas de entradas

Algunos plugins añaden columnas, filtros o acciones rápidas en las pantallas del editor del sitio.

Con eso de las DataViews, parte de esos cambios pueden mostrarse mal o directamente desaparecer hasta que el plugin se actualice para la nueva interfaz.

PHP inferior a la versión 7.4

Si tu sitio sigue en PHP 7.2 o 7.3 WordPress 7.0 ni siquiera se va a dejar instalar o actualizar. Te quedarías en la rama 6.9.x hasta que tu hosting suba la versión.

Lo mejor de WordPress 7.0 … en mi opinión

Vamos con la otra cara, que también la tiene.

Controles de visibilidad de bloques por dispositivo

Imprescindible. No tenía sentido que faltase poder decidir qué bloque se muestra o no a la hora de maquetar y diseñar una web

Una sola pantalla para todas tus IAs

Hasta ahora, cada plugin de IA tenía su propio sistema para guardar la API key. Si usabas tres plugins de IA, gestionabas tres integraciones distintas.

Con la pantalla de conectores IA metes la clave una sola vez y todos los plugins compatibles la reutilizan. Es un cambio pequeño en apariencia y enorme en la práctica.

Plugins como AI Studio, AI Engine y compañía, que tienen pantalla propia para sus conectores, son un caso aparte que voy a tratar en otro artículo dedicado.

Paleta de comandos para ir más rápido

Los atajos que te he comentado antes, Cmd+K o Ctrl+K. Lo dices una vez, lo usas siempre. Para gente que pasa horas al día en el escritorio, el ahorro de clics es la leche, yo soy muy fan, y lo sabes.

Conectores nativos que abren puertas a la IA

Más allá de la propia pantalla de conectores, lo que hay debajo es una infraestructura común de IA en el núcleo de WordPress.

Esto significa que en los próximos meses van a empezar a salir plugins que se apoyan en esa base, sin tener que reinventar la rueda cada uno por su lado.

Si te interesa entender por dónde van los tiros y qué es la Abilities API que hay detrás de todo esto lo cuento en este artículo sobre la Abilities API.

Y un apunte más, porque ya que la 7.0 mete más IA en tu WordPress, no estaría de más que vigilaras también qué bots de IA están rastreando tu sitio, con el plugin VigIA lo tienes fácil.

Cómo saber si tu web está lista para WordPress 7.0

Antes de actualizar a 7.0 comprueba estas cosas en este orden.

• Versión de PHP: Entra en tu panel de hosting o en Herramientas > Salud del sitio. Si pone 7.2 o 7.3 no sigas. Pide a tu hosting que te suba a 8.2 o superior.
• Plugins críticos: Mira la página de cada plugin importante en wordpress.org y busca el dato «Probado hasta«. Si pone 7.0 o algo posterior buena señal. Si lleva mucho tiempo sin actualizarse mala.
• Tema: Si usas Astra, GeneratePress, Kadence o cualquier tema mantenido activamente debería estar al día. Si tu tema es de hace cuatro años y nadie lo toca pruébalo antes.
• Plugins comerciales: Para plugins de pago como Yoast, Rank Math, WPML, WP Rocket, WooCommerce o Gravity Forms, mira el blog del desarrollador. Suelen anunciar la compatibilidad con WordPress 7.0 antes de que salga.
• Cajas meta de pagos, formularios o CPTs: Si tu web depende de plugins que añaden campos extra al editor (cajas meta) y quieres usar la colaboración en tiempo real, comprueba si el plugin tiene una versión compatible. Si no, la colaboración no funcionará en esos contenidos.

Si quieres ver al detalle qué plugins están registrando cajas meta instala Query Monitor. Te muestra exactamente qué componente añade cada caja.

Pasos para actualizar sin sobresaltos

Esta es la rutina que sigo yo en cualquier actualización mayor y te sirve también para la 7.0.

• Prueba WordPress 7.0 en playground sin tener que instalar nada si quieres echar un vistazo rápido e incluso probar algunos de tus plugins favoritos.
• Haz backup completo del sitio, base de datos y archivos. Sin esto no hagas absolutamente nada.
• Monta una copia real de tu web. La mayoría de hosting serios te lo dan en un clic y otros tienen algún tipo de entorno de pruebas.
  • Actualiza primero todos los plugins y el tema en el sitio de pruebas a la última versión disponible.
  • Actualiza WordPress a 7.0 en el sitio de pruebas y revisa que todo funciona inicialmente sin sorpresas.
  • Prueba las pantallas que más uses. Edita una entrada, sube una imagen, mira los pedidos si tienes tienda, prueba el formulario de contacto.
  • Mira la pantalla de salud del sitio, te avisará de cualquier aviso nuevo.
• Solo si todo va bien actualiza en producción. Pero antes de hacerlo, crea otro backup, por si acaso, siempre hay tiempo de borrar las copias más tarde, y las echas de menos cuando no las tienes y pasan cosas.

Cuándo actualizar a WordPress 7.0

No tienes obligación ninguna de actualizar el primer día, lo razonable es esperar una o dos semanas a que el ecosistema de plugins y temas saque sus actualizaciones de compatibilidad.

La excepción son los sitios pequeños sin muchas dependencias, donde puedes actualizar antes sin demasiado riesgo.

Si gestionas webs de clientes, en cambio, no tengas prisa. Mejor un cliente que tarda en estrenar WordPress 7.0 que un cliente con la web rota.

WordPress 7.0 va a estar instalado en muchas webs antes de que termine la primavera. Cuanto antes hagas las comprobaciones de arriba menos te vas a tener que apurar el día 20.

Y si te ha pillado el toro y necesitas ayuda con algo concreto, te leo en los comentarios.

WordPress 7.0 sale el 20 de mayo de 2026 tras el retraso de unas semanas que el equipo decidió para cerrar la arquitectura de la edición en tiempo real. La fase de RC ha sido más larga de lo habitual y la guía de campo está publicada con todas las dev notes individuales, así que tienes información de sobra para preparar el terreno antes de que llegue.

Vista rápida de los cambios técnicos que hay que revisar

Estos son los puntos donde WordPress 7.0 te puede afectar a desarrolladores, ordenados por probabilidad de que te toque hacer algo:

• Estilos propios del admin desalineados tras el rediseño visual del escritorio.
• Metaboxes clásicas que desactivan la edición en tiempo real en las entradas donde aparecen.
• Block API v3 y el comportamiento del editor en iframe.
• WP_List_Table sustituida por DataViews en las pantallas de listados del editor del sitio.
• PHP 7.4 mínimo en core, lo que afecta también a la compatibilidad de tus plugins y temas.

Y luego, lo que abre puertas nuevas:

• Connectors API para poder reutilizar las credenciales de IA centralizadas.
• Abilities API en core y no como experimento, lista para registrar capacidades en tu código para que cualquier IA externa pueda descubrirlas y usarlas.

PHP 7.4 mínimo

WordPress 7.0 sube el suelo a PHP 7.4 y deja atrás 7.2 y 7.3. Para ti como desarrollador esto significa dos cosas, y la primera es que la cabecera Requires PHP de tus plugins y temas debe declarar al menos 7.4, porque si dejas 7.0 o 7.2 el repositorio va a entender que tu código funciona en versiones con las que el core ya no admite.

Luego, además, te afecta el hecho de que puedes empezar a usar sintaxis que estuvo limitada hasta ahora, como arrow functions, typed properties, null coalescing assignment o spread operator en arrays asociativos.

Lo razonable es declarar la compatibilidad que hayas probado. Si tu plugin funciona desde PHP 7.4 hasta PHP 8.3, pones Requires PHP: 7.4 y compruebas en las dos puntas del rango, sin subir el mínimo a 8.0 sin necesidad, porque cerrarías la puerta a los hosting que todavía no han migrado a 8.x.

Block API v3 y el editor en iframe

Aquí hay un matiz que mucha gente está contando regular, no por mala fe, sino porque ha habido cambios. Originalmente la versión 7.0 iba a forzar el iframe en el editor de entradas para todos los bloques sin importar su apiVersion, pero en febrero el equipo del editor revisó el calendario y eligió un despliegue gradual.

Lo que pasa de verdad en WordPress 7.0 es que el editor comprueba la versión de los bloques insertados en el post, no la de los registrados en general, y si todos los bloques que hay en la entrada son v3 o superior el editor se carga en iframe, mientras que si hay alguno con v2 se queda fuera del iframe igual que ahora.

Esto significa que el iframe sigue avanzando, pero no se te va a romper la web el 20 de mayo si tu bloque está en la v2. Lo que sí toca hacer es migrar cuanto antes, porque la fase de aviso ha terminado y los próximos pasos sí van a ser obligatorios.

El cambio mínimo es trivial. En tu archivo block.json subes la apiVersion a la 3:

{
    "apiVersion": 3,
    "name": "ayudawp/mi-bloque",
    ...
}

Si tu bloque solo pinta cosas con React y no toca el DOM directamente con eso suele bastar. El problema viene cuando dentro del bloque accedes a document o window de forma directa, porque dentro del iframe esos objetos apuntan al iframe y no al admin, y ahí es donde se rompen muchas integraciones de scripts antiguos.

La forma correcta es usar el contexto del nodo del bloque mediante una referencia, accediendo a ownerDocument y defaultView:

import { useRef, useEffect } from '@wordpress/element';

export default function Edit() {
    const ref = useRef();

    useEffect( () => {
        // Acceso correcto al document que contiene el bloque
        const doc = ref.current.ownerDocument;
        const win = doc.defaultView;

        // A partir de aqui, doc y win apuntan al iframe del editor
        // y todo lo que hagas se aplica donde toca
    }, [] );

    return <div ref={ ref }>...</div>;
}

Si dependes de librerías de terceros que tiran de window global, como plugins jQuery antiguos o sliders sin namespacing, toca revisar uno por uno. La buena noticia es que un bloque que ya funciona en el editor del sitio o en el editor de plantillas está prácticamente preparado, porque esos editores llevan años funcionando en iframe.

Cajas meta clásicas y la edición en tiempo real

Aquí no hay matiz que valga. Si tu código registra una caja meta clásica con add_meta_box(), la edición en tiempo real se desactiva en las entradas donde aparece esa caja, y el editor le muestra al usuario un aviso que pone «esta entrada usa plugins que no son compatibles con la colaboración en tiempo real».

No es un fallo, es una decisión arquitectónica del equipo, porque las cajas meta clásicas guardan datos por fuera de la capa del editor de bloques y no se pueden sincronizar entre clientes en tiempo real sin riesgo de perder cambios por el camino.

El camino correcto es registrar tu caja meta con register_post_meta() y show_in_rest a true, para que esté dentro de la capa de datos del editor de bloques:

/**
 * Registra el meta del plugin de forma compatible con la colaboracion en tiempo real.
 */
function ayudawp_register_post_meta() {
    register_post_meta(
        'post',
        '_ayudawp_destacado',
        array(
            'show_in_rest'  => true,
            'single'        => true,
            'type'          => 'boolean',
            'default'       => false,
            'auth_callback' => function() {
                return current_user_can( 'edit_posts' );
            },
        )
    );
}
add_action( 'init', 'ayudawp_register_post_meta' );

A partir de aquí, en lugar de ofrecer la caja meta clásica entregas un panel en la barra lateral del editor de bloques con PluginDocumentSettingPanel y enganchas los datos del meta usando los hooks de @wordpress/data.

Si quieres ver el caso real con todo el código de migración, en este artículo enseño cómo migré la caja meta de AI Share & Summarize a un panel lateral del editor manteniendo la compatibilidad con el editor clásico, porque ambos sistemas leen y escriben en la misma clave de meta.

Si por lo que sea no puedes migrar antes del 20 de mayo no es ningún drama, ya que la caja meta clásica sigue funcionando como hasta ahora y lo único que pierde el usuario es la edición simultánea en esas entradas. Eso sí, deja claro en el changelog del plugin que la migración está en marcha, porque la gente que active la colaboración va a ver el aviso y va a buscar al culpable.

Nota: la funcionalidad de colaboración en tiempo real al final no sale con WordPress 7.0, se ha aplazado por falta de solidez de la funcionalidad

Rediseño visual del admin

El admin de WordPress 7.0 estrena lo que en el ticket #64308 de Trac llaman un «coat of paint visual reskin».

Son cambios solo en CSS y no tocan markup ni JavaScript, así que sobre el papel cualquier plugin debería seguir funcionando igual, pero en la práctica te dejan mal, porque hay muchos plugins con estilos propios para sus botones, sus tablas y sus avisos, y esos estilos chocan con los nuevos espaciados y tipografías unificadas.

El esquema por defecto pasa del fresco al moderno, los componentes del sistema de diseño están alineados con @wordpress/components y @wordpress/base-styles, y el resultado es que cualquier estilo que pelee contra el sistema queda desalineado o con dimensiones raras.

Te lo digo desde la experiencia, he tenido que repasar estilos en plugins propios y ajenos para que las pantallas de ajustes vuelvan a verse limpias, y no es algo que se solucione con un parche en cinco minutos cuando hay mucho CSS heredado.

La forma de evitar este problema, ahora y en futuras versiones, es usar las clases nativas del admin y dejar de inventar selectores propios para cosas que el core ya genera:

• Botones con button, button-primary, button-secondary y button-link en lugar de tus propias clases.
• Tablas con wp-list-table widefat fixed striped.
• Avisos con notice notice-success, notice notice-error, notice notice-warning e notice notice-info, añadiendo is-dismissible si quieres el botón de cerrar.
• Formularios con form-table y la API de Settings, que ya te da el aspecto correcto sin escribir CSS propio.

Si ya tienes hojas de estilo propias para el admin, una limpieza rápida pasa por quitar los !important innecesarios, sustituir píxeles fijos por las variables CSS del sistema de diseño y revisar selectores demasiado genéricos del tipo .button o input[type="submit"] sin contexto, encerrándolos en el contenedor de tu plugin para que no se peleen con nada del core.

DataViews en vez de WP_List_Table

Las pantallas de listados en el editor del sitio pasan a usar el sistema DataViews en lugar de la vieja WP_List_Table. Para el usuario es una mejora visible, con filtros que se aplican sin recargar y vistas configurables, y para el desarrollador es un cambio de modelo, porque los ganchos de siempre que añadían columnas, filtros o acciones rápidas no se aplican igual.

Si usas hooks como manage_posts_columns, manage_pages_columns, manage_media_columns o sus equivalentes para acciones rápidas y acciones en lote, siguen funcionando con retro-compatibilidad, pero la experiencia ya no es la misma y algunos casos avanzados se rompen.

La parte donde más he visto problemas, porque soy un bobo y me pasa de todo, es en plugins que pintaban cajas meta ocultas vinculados a columnas, o que insertaban controles personalizados directamente en el thead de la tabla.

Si tu plugin o tema necesita integrarse con estas pantallas, toca pasar por @wordpress/dataviews y registrar las vistas con la nueva API. Hay también un cambio menor pero importante en la API, el parámetro groupByField como string ha sido sustituido por un objeto groupBy con más opciones, así que si has tocado esto en versiones anteriores, ajústalo.

Para la mayoría de código, que solo añade una columna o un filtro sencillo, no hay que hacer nada urgente, pero conviene probar la pantalla en un staging con WordPress 7.0 antes de soltarlo a producción.

Connectors API: integración con la IA desde el core

Una de las novedades más interesantes para devs que tocamos IA es la pantalla nueva en Ajustes > Conectores.

Hasta ahora, cada plugin que conectaba con OpenAI, Anthropic, Gemini o cualquier otro proveedor montaba su propia pantalla de ajustes con su propio formulario para la API key, lo que provocaba que el usuario tuviera que meter la misma clave en tres sitios distintos si usaba tres plugins de IA. Con la Connectors API esto cambia.

De serie vienen tres conectores, OpenAI, Anthropic y Google, y si quieres registrar el tuyo propio o ajustar los metadatos de uno existente, lo haces a través del action wp_connectors_init:

/**
 * Registra un conector personalizado para un proveedor de IA
 */
function ayudawp_register_connector( $registry ) {
    $registry->register( 'mi-proveedor-ia', array(
        'name'              => 'Mi Proveedor IA',
        'description'       => __( 'Conector para mi servicio de IA personalizado.', 'mi-plugin' ),
        'authentication'    => 'api_key',
        'icon'              => plugins_url( 'assets/icon.svg', __FILE__ ),
        'documentation_url' => 'https://miproveedor.com/docs/',
    ) );
}
add_action( 'wp_connectors_init', 'ayudawp_register_connector' );

El registro automático genera un nombre de opción siguiendo el patrón connectors_ai_{$id}_api_key, y la API key queda disponible para cualquier plugin compatible que la quiera usar mediante wp_ai_client_prompt(). Eso significa que si tu plugin usa el AI Client del core no tienes que pedirle al usuario una clave API propia, ya está.

Un apunte importante es que en la versión 7.0 de WordPress solo los conectores con identificación de tipo api_key reciben la UI completa en la pantalla de conectores, mientras que otros métodos de identificación están aceptados por el registro PHP pero la integración visual completa llegará en la 7.1. Si tu proveedor usa OAuth conviene esperar o registrar la UI por tu cuenta de momento.

Abilities API ya de verdad en WordPress 7.0

Si solo te llevas una cosa de este artículo que sea esta. La Abilities API entra en 7.0 ya a tope en el núcleo de WordPress y no como experimento ni como propuesta, y es la pieza que va a transformar la forma en que las IAs interactúan con tu sitio.

La idea es que si tu desarrollo registra abilities concretas con un nombre, una descripción, parámetros y un callback, y esas capacidades quedan disponibles tanto vía REST como vía MCP para que cualquier IA externa las pueda descubrir y ejecutar de forma estandarizada.

Te dejo un ejemplo mínimo de registro de una ability:

/**
 * Registra una ability para que pueda ser descubierta por agentes externos.
 */
function ayudawp_register_ability() {
    wp_register_ability( 'ayudawp/contar-entradas', array(
        'label'        => __( 'Contar entradas publicadas', 'ayudawp' ),
        'description'  => __( 'Devuelve el numero de entradas publicadas en el sitio.', 'ayudawp' ),
        'input_schema' => array(
            'type'       => 'object',
            'properties' => array(
                'post_type' => array(
                    'type'        => 'string',
                    'default'     => 'post',
                    'description' => __( 'Tipo de contenido a contar.', 'ayudawp' ),
                ),
            ),
        ),
        'execute_callback' => function( $input ) {
            $post_type = isset( $input['post_type'] ) ? sanitize_key( $input['post_type'] ) : 'post';
            $count     = wp_count_posts( $post_type );

            return array(
                'count' => isset( $count->publish ) ? (int) $count->publish : 0,
            );
        },
        'permission_callback' => function() {
            return current_user_can( 'edit_posts' );
        },
    ) );
}
add_action( 'abilities_api_init', 'ayudawp_register_ability' );

A partir del momento en que tu código registra esta ability una IA con acceso al sitio puede descubrirla, leer su esquema de entrada, pedir el permiso correspondiente y ejecutarla, todo sin que tengas que escribir un endpoint REST adicional ni una integración específica con cada IA del mercado.

Si te interesa entender por qué esto cambia el panorama y qué es exactamente la Abilities API a fondo, lo cuento en este artículo introductorio, y para el caso práctico de cómo registrar abilities en tus plugins y temas tienes el detalle en este otro.

El siguiente paso natural, una vez que tienes abilities registradas, es exponerlas usando MCP para que herramientas como Claude Code, Cursor o cualquier asistente compatible con el Model Context Protocol puedan usarlas directamente. Eso es harina de otro costal y da para un artículo aparte, pero conviene que lo tengas en el radar.

Resumen de comprobaciones antes del 20 de mayo

Si tienes un plugin o tema en producción y quieres asegurarte de que no se te rompe nada con la actualización a 7.0, esta es la rutina que sigo yo:

• Comprueba la cabecera Requires PHP súbela a 7.4 si todavía está en 7.2 o 7.3.
• Sube la cabecera Tested up to a 7.0 tras probarlo de verdad, no por las buenas.
• Cambia la apiVersion de tus bloques a 3 en el block.json.
• Revisa los document y window directos en el código del bloque y sustitúyelos por ownerDocument y defaultView a través de una referencia.
• Si registras cajas meta clásicas, plantea la migración a register_post_meta() con show_in_rest a true.
• Pasa todas las pantallas de ajustes de tu plugin o tema por el navegador con WordPress 7.0 y mira si hay desalineaciones en botones, tablas o avisos.
• Si tu desarrollo manipula columnas, filtros o acciones rápidas en las pantallas de entradas, páginas o medios, prueba el comportamiento con DataViews activado.
• Si conectas con IAs de terceros, valora migrar la gestión de credenciales a la Connectors API.
• Si quieres dar un paso más allá, registra abilities concretas de tu plugin o tema para que las puedan descubrir agentes externos.
• Activa SCRIPT_DEBUG en tu entorno de pruebas y revisa la consola del navegador en busca de avisos de deprecated.

Recursos oficiales para profundizar

Para entrar al detalle técnico de cualquiera de estos cambios, los enlaces que conviene tener a mano son:

• Guía de campo de WordPress 7.0, con todas las dev notes individuales recopiladas en un único índice.
• Etiqueta dev-notes-7-0 en Make WordPress Core, donde están publicadas las notas a medida que salen.
• Guía de migración de bloques a iframe en el handbook del editor de bloques.
• Introducing the Connectors API in WordPress 7.0, dev note oficial.

Y si quieres pasar el resumen a tus clientes

Mañana publico el artículo hermano de este, dirigido a propietarios de webs hechas con WordPress, y lo escribo justo para que se lo puedas pasar a quien delegue en ti la actualización del sitio sin entrar en código. Lo enlazaré aquí en cuanto esté disponible.

Si en tus revisiones ves algún caso raro que no termina de encajar con lo que cuento, escríbeme en los comentarios. Cualquier patrón que aparezca en plugins reales y que merezca la pena cubrir lo voy añadiendo en revisiones del artículo.

Que si «feature freeze«, que si «el plugin se acaba«, que si «migra antes de que sea tarde«. La realidad es algo más aburrida y, sobre todo, mucho menos urgente de lo que te están vendiendo.

Vamos a verlo con calma.

Lo que anunció Miyoshi, sin el filtro del marketing oportunista

El 11 de abril de 2026, durante WordCamp Asia 2026 en Mumbái, Takayuki Miyoshi presentó la ponencia Schema sharing makes web forms management sustainable (disponible en WordPress.tv).

Y ahí, entre la propuesta de un sistema de esquemas compartidos para formularios web, soltó la frase que ha desencadenado el espectáculo:

Tras la version Contact Form 7 6.2, el plugin entra en congelación de funcionalidades.

Esto es lo que feature freeze significa de verdad:

• El plugin sigue publicado en WordPress.org con sus 10 millones de instalaciones activas.
• Sigue recibiendo parches de seguridad cuando hagan falta. La última versión, la 6.1.5 de febrero de 2026, fue precisamente un parche de seguridad para inyección de cabeceras de correo.
• Sigue manteniendo compatibilidad con las nuevas versiones de WordPress.
• Lo que se para de momento son las funciones nuevas, no el desarrollo en sí.
• Miyoshi sigue activo en el ecosistema WordPress, dirigiendo Rock Lobster Inc., colaborando como voluntario patrocinado por Kinsta y desarrollando otros proyectos como Bogo o la propia idea de schema sharing que presentó.

O sea, que Contact Form 7 no se cierra, no se abandona y no desaparece, se estabiliza. Es exactamente lo que pasa con software maduro que ya hace lo que tiene que hacer.

WordPress mismo lleva años discutiendo si TinyMCE, jQuery o ciertas APIs deberían estar en feature freeze, y nadie está montando funerales por ello.

El zoo de la vergüenza

Lo verdaderamente curioso es la velocidad con la que se ha montado el carnaval. Repaso lo que han publicado los competidores y los enlaces para que veas con tus ojos el nivel de exageración.

WPForms: la urgencia inventada

WPForms ha publicado «11 Reasons to Switch From Contact Form 7 to WPForms» donde el titular ya marca el tono. Que CF7 está en feature freeze, que el desarrollador «se va a otro proyecto» y que tu sitio es un riesgo de seguridad inminente.

Está bien escrita, todo hay que decirlo, y técnicamente es verdad en muchos puntos, pero el mensaje de fondo es la del pánico controlado.

La frase clave del artículo es decir que «bug fixes» y «mantener compatibilidad activa» son cosas distintas, lo cual es verdad, pero también es trampa, pues CF7 lleva veinte años manteniendo compatibilidad con WordPress y no hay ningún indicio de que eso vaya a cambiar.

Fluent Forms: el más agresivo

Fluent Forms ha sacado tres posts en cadena. La principal, «13 Reasons to Switch From Contact Form 7 to Fluent Forms», abre directamente con que el desarrollo de CF7 «se está acabando» y que «el riesgo se acumula cuanto más esperes«.

Tienen además una guía específica de migración con un clic y una comparativa donde, casualmente, todas las casillas verdes están de su lado.

El subtexto comercial es evidente, que por 79 dólares al año en cuanto pasas a la versión Pro, que es donde están el 90% de las funciones que destacan.

SureForms: la apuesta de Brainstorm Force

SureForms ha publicado su mensaje de «alternativa moderna» y una comparativa directa. Tono más comedido, pero la conclusión es la misma, que CF7 está congelado y SureForms es el futuro.

Como producto está bien hecho y la integración con bloques de Gutenberg es notable, pero llevan apenas un par de años en el mercado y todavía les falta ecosistema y rodaje.

Brainstorm Force es la gente detrás de Astra y Spectra, así que potencia comercial y de marketing tienen de sobra.

WPBeginner: amplificador estructural

WPBeginner, que es el medio anglosajón más leído sobre WordPress y que tiene relación directa con WPForms (mismo dueño, Syed Balkhi), recogió la noticia en su newsletter de abril con titular del estilo «uno de los plugins más antiguos y usados de WordPress cierra oficialmente la puerta a nuevas funciones«.

Cuando el medio que define la idea pública del ecosistema y el plugin que más se beneficia comparten propietario, la noticia tiende a sonar bastante más grave de lo que es en la realidad técnica.

El resto del coro

Everest Forms, Forminator, Gravity Forms, Bit Form, WPZOOM Forms, Ninja Forms… todos han publicado o reactualizado sus comparativas con CF7.

Todos tienen su importador «con un clic», todos te dicen que tu sitio está en riesgo y que ellos son la solución.

Cuando todo el mercado se mueve a la vez con el mismo mensaje y la misma llamada a la acción, no estamos ante un análisis técnico sino ante una campaña coordinada de captación oportunista.

Lo que tienes gratis con CF7 frente a lo que te cobran los que lo quieren enterrar ya

Esta es la parte que se les olvida, porque lo que repiten es que CF7 es básico y ellos ofrecen soluciones completas.

Pero la realidad es que CF7, junto con su enorme ecosistema de extensiones gratuitas, lleva más de una década dando funciones que sus rivales entierran detrás de muros de pago, de ahí esas prisas repentinas por enterrarlo.

Repasamos punto por punto lo que ofrece cada plugin de pago como gancho premium y dónde lo tienes en el universo Contact Form 7 sin pagar un euro:

Cuando ves la tabla entera el discurso de los competidores se desinfla solo.

La diferencia real no está en lo que CF7 ofrece, está en cómo lo ofrece, módulos sueltos en vez de una suite cerrada. Eso, dependiendo de quién seas, es ventaja o inconveniente, pero presentarlo como «carencia» es basura comercial.

Lo que ofrece de verdad cada alternativa, y lo que infla

Vamos a repasar un poco más en detalle qué hace bien y qué exagera cada una de las alternativas que más están empujando ahora mismo.

Fluent Forms

• Lo real: es un plugin sólido, ligero, con una versión gratuita generosa de verdad. Su gratuita incluye lógica condicional, formularios conversacionales y almacenamiento de entradas, cosa que ni WPForms ni Gravity Forms ofrecen sin pagar. La interfaz tipo de arrastrar y soltar está bien resuelta y el migrador desde CF7 funciona razonablemente bien.
• Lo inflado: en su comparativa pintan a CF7 como un plugin del paleolítico que casi no envía correos. Insisten en que CF7 «no almacena entradas» como si fuera un fallo escandaloso, ignorando que existe Flamingo, hecho por el mismo Miyoshi, gratis y que hace exactamente eso. El discurso del riesgo de seguridad inminente es deshonesto, pues CF7 ha tenido vulnerabilidades a lo largo de su historia y se han parcheado, igual que las ha tenido Fluent Forms y todas las demás.

WPForms

• Lo real: es la opción más cómoda para quien no quiere complicarse la vida. La curva de aprendizaje es la más suave del mercado y para webs de clientes que no tocan nada, va muy bien. La integración con email marketing es buena.
• Lo inflado: la versión Lite (gratis) está deliberadamente capada para empujarte al plan Basic en cuanto necesitas algo serio. Lo que venden como «WPForms ya hace más que CF7 gratis» es cuestionable cuando lo comparas con CF7 más sus extensiones gratuitas. Y la frase de que el desarrollador de CF7 «se va a otro proyecto» es directamente falsa, porque Miyoshi ha dicho que congela funciones, no que abandone el plugin. Hay una diferencia conceptual y comercial enorme.

SureForms

• Lo real: tiene generación de formularios por IA en lenguaje natural que está bien resuelta y la integración con bloques de Gutenberg es de las mejores del mercado. Si creas webs con Spectra y temas de bloques encaja muy natural.
• Lo inflado: es muy joven. El ecosistema de integraciones todavía está en construcción, la documentación es limitada y depende mucho del calendario de Brainstorm Force. La promesa de «el futuro de los formularios» es válida como aspiración pero hoy mismo no es lo más maduro que puedes instalar.

Forminator

• Lo real: probablemente la versión gratuita más completa del mercado en 2026. Incluye lógica condicional, pagos con Stripe, cuestionarios, encuestas y cálculos sin pagar nada. Para quien quiera salir de CF7 y no soltar un euro quizás es la opción más interesante.
• Lo inflado: pertenece al ecosistema WPMU DEV y empuja sus servicios de pago de forma a veces invasiva. Los avisos en el panel de administración son constantes.

Gravity Forms

• Lo real: sigue siendo el rey de los formularios profesionales. Estable, bien documentado, con una comunidad de desarrolladores muy madura y una API de plugin para extensiones muy bien diseñada. Para sitios serios y agencias, sigue siendo la opción de menor riesgo.
• Lo inflado: nada en particular, porque Gravity Forms casi no se ha sumado al hype del feature freeze. Han hecho lo más inteligente, que es callarse y dejar que los demás peleen por la gracia del momento.

El elefante en la habitación es la dependencia de extensiones

Una crítica que sí tiene sentido sobre el modelo de Contact Form 7 es que depende mucho de extensiones de terceros. Aquí sí hay algo a vigilar, sobre todo si tu formulario depende de:

• Conditional Fields (mantenido activamente, sin riesgo aparente).
• Multi-Step Forms (lleva sin actualizarse desde hace años, en zona de riesgo).
• CF7 Customizer (mantenimiento intermitente).
• Algún plugin de PayPal, Stripe o Redsys de terceros sin desarrollo activo.
• Integraciones con CRM viejas y abandonadas.

… entonces sí tienes un problema real, y no es por el feature freeze de CF7, sino porque tu formulario está montado sobre piezas de mantenimiento incierto. Eso ya era cierto antes del anuncio de Mumbái, y va a seguir siendo cierto independientemente de lo que haga CF7.

La solución no es necesariamente migrar de plugin de formularios, es revisar tu pila de plugins y decidir qué piezas reemplazar.

El consejo práctico aquí es hacer un inventario de extensiones CF7 en tus sitios, mirar la fecha de última actualización de cada una en WordPress.org, y reemplazar las zombi por alternativas mantenidas o por código propio si tienes habilidad.

Para el 90% de los casos eso te resuelve el problema sin tocar el plugin principal.

Cuándo migrar de verdad tiene sentido

Pese a todo lo anterior, no estoy diciendo que nadie deba migrar. Hay escenarios donde dejar CF7 es la decisión correcta y conviene reconocerlos sin disfraz:

• Si gestionas formularios complejos con cinco o seis extensiones de CF7 encadenadas, una suite todo en uno te va a simplificar el mantenimiento y la vida.
• Si tus clientes finales necesitan crear y modificar formularios por sí mismos, un constructor visual les va a costar mucho menos que enseñarles los shortcode tags de CF7.
• Si trabajas con flujos de pago serios, especialmente recurrentes, suscripciones, pasarelas múltiples y conciliación contable, una solución profesional integrada es más defendible que una caja de extensiones gratuitas montadas a piezas.
• Si necesitas almacenamiento de entradas con interfaz rica (búsqueda, etiquetado, exportación a PDF, paneles de seguimiento), la combinación de CF7 más Flamingo se queda corta. Aquí sí ganan los rivales.
• Si tienes formularios con muchísimo volumen y necesitas gestionar miles de envíos al mes con automatizaciones complejas y conexión con CRM, CF7 no es la herramienta adecuada y nunca lo ha sido.

Cuándo NO migrar (que es la mayoría de casos)

Estos son los escenarios donde el ruido del marketing está intentando empujarte a un cambio que no necesitas:

• Formulario de contacto sencillo en una web corporativa o profesional: nombre, email, mensaje, antispam y a correr. CF7 va a seguir haciendo esto perfectamente durante años. Cambiarlo es trabajo gratis para ti.
• Formularios de presupuesto con campos básicos: cinco o seis campos, condicional simple, envío a un par de direcciones. Lo tienes resuelto con CF7 más una extensión y nada justifica meterse en una migración.
• Sitios pequeños con poco volumen: si recibes diez o veinte envíos al mes, el coste-beneficio de cambiar es negativo casi seguro.
• Formularios con integraciones que ya funcionan: la regla del «si no está roto, no lo toques» se aplica especialmente aquí. Las migraciones siempre rompen algo, y la pregunta no es si va a pasar, es qué va a pasar y cuánto te va a costar arreglarlo.
• Webs con varios años de historial de formularios: si tienes un volumen importante de envíos archivados con Flamingo o algún otro sistema, cualquier migración te va a obligar a decidir qué haces con ese histórico.

Huye del oportunismo … en mi opinión

Si me preguntas como profesional que mantiene decenas de webs mi posición es clara, mía, pero te la cuento.

Para los formularios sencillos que tienen el 80% de los sitios WordPress (un contacto, un presupuesto básico, una suscripción a newsletter), Contact Form 7 sigue siendo la opción más eficiente, ligera y económica que existe.

El feature freeze no cambia eso lo más mínimo, lo único que cambia es que los nuevos juguetes (IA generadora de formularios, formularios conversacionales tipo Typeform, integraciones de moda con cada SaaS que sale) no van a llegar a CF7. Si no los necesitas no te afecta.

Para casos avanzados, complejos o con clientes finales que quieren autonomía, las alternativas modernas tienen algunas ventajas, pero la decisión debe estar guiada por tus necesidades, no por el calendario de marketing de tres plugins de pago que han visto una oportunidad.

Y si te empuja a tomar una decisión apresurada un artículo titulado «13 razones para migrar ya mismo«, recuerda quién lo ha escrito y qué vende.

Hay buenos plugins de formularios en el mercado (Fluent Forms, Forminator, Gravity Forms) y los recomiendo cuando tiene sentido recomendarlos, lo que no recomiendo nunca es decidir por miedo a una noticia que no es lo que parece.

Lo que pasará y lo que no los próximos meses

Para que tengas el panorama claro, esto es lo previsible:

• Contact Form 7 versión 6.2 saldrá en la primera mitad de 2026 con soporte para WordPress 6.9+ y PHP 8.3+ obligatorio. Si tu hosting va con PHP antiguo, este es momento de actualizar igualmente.
• El número de instalaciones activas bajará lentamente durante 2026 y 2027 a medida que algunos usuarios se vayan a otras opciones por la presión del marketing, pero la caída no será dramática.
• Algunas extensiones zombi (Multi-Step, varias de pasarelas viejas) probablemente quedarán definitivamente abandonadas. Tendrás que sustituirlas si las usas.
• Las extensiones mantenidas activamente (Conditional Fields, Flamingo, las extensiones del propio Miyoshi) seguirán funcionando perfectamente.
• Los competidores publicarán dos o tres rondas más de artículos de «migra ya» durante 2026 cada vez que CF7 saque un parche. Es marketing reciclable y barato.
• WordPress 7.0, previsto para este año, será probablemente el primer momento crítico real para CF7 si Miyoshi tarda en publicar parches de compatibilidad. Hasta entonces no hay nada urgente.

Mi consejo es que tengas preparado un plan B documentado para cada uno de tus sitios importantes (qué plugin alternativo elegirías, qué migrador usarías, qué riesgos tendrías), pero no lo ejecutes hasta que haya una razón concreta para hacerlo.

Tener el plan listo es responsable, ejecutarlo por miedo a un artículo de marketing no lo es.

Si quieres profundizar en cualquier extensión concreta para CF7 tienes decenas de artículos sobre cómo sacarle todo el partido sin pagar nada extra.

Y si después de leer todo esto sigues queriendo migrar, al menos hazlo con criterio, no porque WPForms haya decidido que tu sitio está en peligro.

Para todo lo demás, incluso debatir, me tienes ahí abajo, en la sección de comentarios.