O sea, que si le cierro el paso a los rastreadores de inteligencia artificial que me entran en la web, ¿me estoy protegiendo o  pegando un tiro en el pie con el SEO y con mi visibilidad en las propias IA?

Es una pregunta de las buenas, y casi todo el mundo la responde mal por dos motivos.

El primero es porque confunde declarar con bloquear, que no es lo mismo, una cosa es pedirle al bot que no lo haga y otra impedírselo de verdad, y luego está el hecho de que se decide a la brava, sin pararse a pensar qué le cuesta eso al posicionamiento.

Vamos a ponerlo en orden, con datos, y en mi opinión (y experiencia) son cuatro pasos:

1. Analizar qué puedes hacer y cómo se aplica cada cosa
2. Saber (realmente) a qué hacen caso las IA y a qué no.
3. Lo más importante, razonar si a ti te conviene para el SEO y en qué casos.
4. Y al final, con toda la información en la mano, decidir qué haces con tu web.

Vamos a verlo con calma.

Ah ¿pero se puede bloquear a las IAs?

Antes de decidir conviene saber qué tienes disponible, porque es más de lo que crees y no todo hace lo mismo. Y hay una línea que lo separa todo, porque unas acciones declaran tu voluntad (solo surten efecto si el bot decide respetarlas) y otras bloquean de verdad (impiden el acceso, lo respete o no).

Con esa idea clara esto es lo que hay.

Señales declarativas (piden, no obligan)

¿En serio hace falta que recuerde esto? Ah ¿que sí?, pues nada, uy perdón …

• El Disallow del robots.txt: Le dices a un bot, por su nombre, que no rastree tu web o ciertas partes. Aquí dentro entra también el Google-Extended, que no es más que un Disallow para el token con el que Google controla el entrenamiento de Gemini.
• El noai y el noimageai: Dos etiquetas en la cabecera de tu web que declaran «no me uses para entrenar, ni el texto ni las imágenes».
• Las Content Signals: Una técnica distinta y más fina, que va en el robots.txt y que en vez de bloquear a un bot separa para qué autorizas tu contenido y para qué no, y que además puede llevar respaldo legal. La vemos aparte, que tiene lo suyo.

Bloqueo real y efectivo (impide de verdad)

Aquí quería llegar yo…

• El 403. Le devuelves al bot un «prohibido» desde PHP, desde el .htaccess o desde un firewall, y no ve absolutamente nada. Esto no pide, esto impide.

Espera que hay más

Y dos caminos más que no son ni bloquear ni dejar pasar, y que mucha gente ni se plantea:

• Cobrar por el acceso, con la cabecera 402 y el protocolo x402.
• Adelantarte, asegurándote de que, cuando te compartan con una IA, tu web vaya siempre como fuente.

¿Le damos ya?, que esto era solo la lista, la chicha de cada cosa la explico ahora.

Cómo se bloquea a las IAs

A las manos en la masa. El «cómo» de cada cosa, con código si te va lo artesano y con plugin si prefieres no tocar nada. Y sí, varios plugins son míos, porque los hice justo para esto, así que perdona el autobombo, pero es que vienen al pelo.

El Disallow en el robots.txt (con el Google-Extended dentro)

A mano, en tu robots.txt:

User-agent: GPTBot
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Google-Extended
Disallow: /

Fíjate en que el Google-Extended es un Disallow más, solo que especial, porque bloquearlo evita que Google te use para entrenar Gemini sin sacarte de las búsquedas, sigues apareciendo igual.

Lo anterior, por supuesto, es solo un ejemplo, aquí tienes una lista bastante más completa de bots de IA a los que hacer Disallow (o no)

Si no te quieres pelear con el fichero, tanto mi plugin Visibility como VigIA te añaden el Disallow a los principales bots de IA con un par de clics.

Las metas noai y el noimageai

En la cabecera de tu web, así:

<meta name="robots" content="noai, noimageai">

Es una declaración de intenciones contra el entrenamiento de las IAs, nacida en DeviantArt en 2022, que no es un estándar oficial de nada, así que vale para el bot que quiera respetarla y para nada frente al que no.

El plugin AI Content Signals las añade (si quieres) sin tocar código ni complicarte.

Las Content Signals (y su respaldo legal)

Las Content Signals también van en el robots.txt, pero en vez de decirle a un bot que no entre, declaran para qué usos autorizas tu contenido y para cuáles no, separando tres cosas distintas:

• search: construir un índice de búsqueda y mostrar resultados (enlaces y extractos cortos), sin incluir los resúmenes generados por IA.
• ai-input: meter tu contenido en modelos de IA en tiempo real, lo que se llama RAG o grounding, las respuestas de búsqueda con IA.
• ai-train: entrenar o afinar los modelos.

Un ejemplo de «buscar sí, entrenar no» quedaría así:

User-agent: *
Content-Signal: search=yes, ai-train=no

¿Y dónde está la gracia de verdad? Pues en que esto no es solo una petición, es una reserva expresa de derechos con base legal.

El plugin AI Content Signals que te comenté en el apartado anterior añade además al robots.txt una declaración que ampara esas señales en el artículo 4 de la Directiva europea 2019/790 de derechos de autor, la que permite a los autores reservarse su contenido frente a la minería de textos y datos, que es, ni más ni menos, lo que hace el entrenamiento de las IA.

O sea, que ya no solo le pides al bot que se porte, le recuerdas que hay una ley europea detrás que protege tu contenido. Te lo conté a fondo en mi artículo sobre las Content Signals, por si quieres seguir informándote de esto.

El bloqueo con 403 por .htaccess o por PHP

Cuando la declaración no basta toca el bloqueo de verdad, cortando por User-agent desde .htaccess:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (Bytespider|PerplexityBot|CCBot) [NC]
RewriteRule .* - [F,L]

O desde PHP, en tu propio plugin o como suelas añadir códigos a tu web:

function ayudawp_bloquear_bots_ia() {
    $ua = isset( $_SERVER['HTTP_USER_AGENT'] ) ? $_SERVER['HTTP_USER_AGENT'] : '';
    if ( $ua && preg_match( '#Bytespider|PerplexityBot|CCBot#i', $ua ) ) {
        status_header( 403 );
        exit;
    }
}
add_action( 'init', 'ayudawp_bloquear_bots_ia' );

Y aquí, de nuevo, VigIA te lo da hecho, porque bloquea de verdad por PHP a los bots que tú elijas, por IP o por User-agent.

Lo mejor de todo es que te da todas las capas, así que puedes probar con el Disallow, y cuando compruebes que no le hacen ni caso, además de aprender en carne propia, con un clic puedes bloquearlos, y también ahí comprobar que eso sí funciona (garantizado).

Para lo más bruto y lejos de tu web de todo, un cortafuegos (un WAF, como el de Cloudflare), que es el único que frena hasta a los que maquillan el User-agent o cambian dinámicamente de IP.

Y en vez de bloquear a las IA ¿puedo cobrarles o alguna otra cosa?

Pues sí ,es posible, y quizás son las que más interesante de cara al futuro.

Cobrar por el acceso: 402 y x402

Existe una cabecera HTTP, la 402 Payment Required, que llevaba décadas casi de adorno y que ahora empieza a cobrar sentido, pues en vez de decirle a la IA que no, le dices «sírvete, pero pagando».

Sobre esa idea se está montando el protocolo x402, para que los bots paguen por rastrearte de forma automática, y Cloudflare ya está levantando su mercado de pago por rastreo.

No es ciencia ficción, te lo he contado en detalle en mis artículos sobre la cabecera 402 y sobre x402, porque es, hoy o mañana, otra opción real para el dueño de una web que no quiere ni regalar su contenido ni renunciar del todo a las IA.

Adelantarte a veces es inevitable, ya puestos que te lleven siempre de fuente

Esta sería la forma más proactiva de todas, porque en vez de solo defenderte juegas al ataque. La gente va a compartir tu contenido con las IA quieras o no, así que al menos que lo haga citando tu web como fuente.

Eso es justo lo que hace el plugin AI Share & Summarize, que añade botones para resumir y compartir tu contenido en ChatGPT, Claude, Perplexity y demás IAs, y cada vez que un lector los usa, el mensaje que se manda a la IA lleva tu URL como origen.

También va un paso más allá y te permite usar la IA para que los usuarios no abandonen tu web para usar la IA ¿flipas verdad?

Básicamente puedes ofrecer resúmenes de tu contenido para, a modo de extracto, generado con tu IA favorita, así les animas a seguir leyendo, sin que dejen de sentir ese calorcito especial que da la IA.

De paso te da analítica de esos clics, que no viene nada mal, lo tienes explicado en mi artículo sobre los resúmenes con IA integrados.

¿A qué hacen caso las IA y a qué no?

Por resumir, recuerda que las señales (el Disallow, el noai, las Content Signals) declaran, y solo surten efecto si el bot decide respetarlas, el 403 bloquea de verdad, lo respete o no.

Los hay que hacen caso, que conste. Sin ir más lejos, esta semana le pedí a mi IA de cabecera (sí, es Claude Code) que me leyera un artículo de ZDNet para recopilar documentarme para los vídeos que hago en YouTube y me dijo que no podía, que ese dominio estaba vetado en su herramienta ¿mande?

Pues resulta que quien opera estas herramientas mantiene una lista de webs que no rastrea, casi siempre por motivos legales, para respetar a editores que han restringido el acceso de las IA o que están directamente en pleitos con ellas.

Y casualmente ZDNet es de Ziff Davis, que demandó a OpenAI en abril de 2025 justo por usar su contenido para entrenar y para alimentar respuestas, así que encaja como un guante.

No tengo acceso a la lista ni al motivo exacto de cada web, pero la idea es esa, y conviene saberla, que a veces la IA no te lee porque legalmente no puede.

El bot más activo de ChatGPT (ChatGPT-User) también se porta razonablemente bien, lee tu robots.txt y para si le dices que no.

El problema son todos los demás.

En agosto de 2025 Cloudflare pilló a Perplexity saltándose las señales a base de cambiar de identidad, rotar direcciones IP y disfrazarse de un navegador normal para colarse en webs que le habían dicho que no. Y yo que tenía en un altar a Perplexity, ¡qué decepción!

Y el Bytespider de ByteDance ignora el robots.txt cuando le da la gana, vamos, siempre. Resumiendo, que fiarte solo de las señales es fiarte de la buena voluntad de cada bot, uno por uno, y ya ves que no todos la tienen.

¿Y cómo sabes tú en cuál de los dos grupos está cada bicho que te visita? Aquí es donde VigIA tiene algo que decir, porque trae una herramienta hecha justo para esto: comprueba si los bots respetan de verdad el Disallow que les has puesto.

Si pillas a una IA pasando de ti, con el mismo VigIA le aplicas el bloqueo por PHP. Declarar, comprobar y, solo si hace falta, bloquear, todo en el mismo sitio y sin adivinar, con datos reales, que de esto falta mucho en todo este tema de las IAs, hay mucho iluminado pero los negocios viven/vivimos de realidades ¿o no?.

¿Y a ti te conviene bloquear? el SEO y AEO

Vale, ya sabes qué puedes hacer y a qué hacen caso. Ahora lo que de verdad nos quita el sueño, que es de donde viene la duda de si conviene bloquear a las IA para el SEO, o nos estamos cerrando una puerta que no deberíamos cerrar.

La pregunta buena no es ¿bloqueo las IA, sí o no?, es más fina, sería algo más como ¿quieres seguir saliendo en los buscadores y en las respuestas de las IA, pero a la vez impedir que usen tu contenido para entrenar sus modelos?

Parece rebuscado, algunos pensarán que imposible, pero no, porque eso, hoy, se puede separar, y ahí está casi toda la chicha, donde podemos poner un poco de orden y control en todo este mejunje.

La clave para entenderlo es que el AEO y el GEO, eso de posicionarte en las respuestas de la IA, siguen siendo SEO. No lo digo yo, lo dice la propia guía de optimización para IA de Google, pues las AI Overviews y el AI Mode se apoyan en su mismo sistema de posicionamiento y calidad de siempre.

O sea, que las mismas señales que te hacen posicionar son las que hacen que te citen en las respuestas con IA. Y ahora ata cabos, que si le impides el paso a los bots que recuperan tu contenido para buscar y citar, dejas de salir en esas respuestas, y el hueco lo ocupa tu competencia.

Y esto no es una teoría mía, ya hay datos. Alrededor del 80 % de los grandes medios de noticias ya bloquean al menos un bot de entrenamiento, y un 70 % bloquea también los bots que recuperan contenido para citar en las IA.

¿El resultado? Pues varios estudios apuntan a que esos mismos medios se están quedando fuera de las respuestas de la IA y perdiendo visibilidad justo por bloquear a la brava. Se protegen de una cosa y se disparan en el pie con la otra, así que la cosa está en saber qué y cuándo bloquear.

Cuándo bloquear SÍ tiene sentido

Que quede claro que no todo es dejar pasar. Bloquear compensa, y mucho, cuando proteger tu contenido pesa más que la visibilidad. Ejemplos de esto:

• Contenido propietario o sensible, eso que te diferencia de verdad de la competencia.
• Contenido de pago, para miembros, cursos o zonas privadas.
• Datos únicos que son tu negocio, como los precios o las fichas de una tienda que no quieres que acaben en el buscador de otro.
• Sitios con obligaciones de cumplimiento estrictas.
• Y el caso de los editores que, sencillamente, no quieren regalar su trabajo para entrenar modelos y prefieren pelear por que les paguen, ahí es donde entra lo del 402 y el x402 de antes.

Cuándo bloquear sería un grave error

Y al revés, si tu web vive de que te encuentren y te citen, impedir el paso a los bots de búsqueda de IA es de las peores ideas que puedes tener.

Hablo de blogs, webs de empresa, guías, contenido informativo, marca personal, todo eso que se alimenta de visibilidad y autoridad.

Ahí cada cita en una IA es un ladrillo más de tu reputación, y cerrarles el paso es quedarte fuera del escaparate donde ahora busca la gente. Y para que te citen bien, el contenido tiene que merecer la cita, que es el E-E-A-T de toda la vida.

Hay un motivo aparte, eso sí, que vale para cualquiera, y me refiero al coste de rastreo.

Estos bots rastrean a lo bestia, y según datos de Cloudflare hay rastreadores de IA que piden decenas de miles de páginas de tu web por cada mísera visita que te devuelven.

Eso es factura de servidor, así que si uno te está reventando el hosting tienes todo el derecho a pararlo aunque el SEO te diga otra cosa.

¿Y surte efecto bloquear? Pues depende de a quién.

Los bots decentes que respetan las señales pararán en cuanto se lo pidas, los que ignoran el robots.txt necesitan el 403. Y a los que se disfrazan, como vimos con Perplexity, ni el bloqueo por user-agent los para del todo, ahí solo un firewall en condiciones les corta el acceso de verdad.

El método tiene que estar adaptado al bot, no hay una bala de plata.

La decisión, con todo en la mano

Con todo esto ya puedes decidir sin agobios, y el orden sensato es este, justo al revés de lo que hace casi todo el mundo:

1. Primero mide: Con VigIA (o con los logs de tu servidor), mira quién te rastrea, si respeta tus señales y cuánto te cuesta. Sin este paso vas a ciegas.
2. Clasifica según el bot y según tu contenido: A los de búsqueda y cita, déjalos pasar si vives de la visibilidad. A los de entrenamiento, ponles la señal. A los que te sangran el servidor o pasan de ti, bloqueo.
3. Aplica el nivel justo: Declaración para el que la respeta, bloqueo para el que no. Y valora si, en vez de bloquear, te compensa cobrar o adelantarte con la atribución.
4. Revisa tu estrategia a menudo: Que esto cambia a toda velocidad, y el bot que hoy no te aporta nada, mañana puede ser tu principal fuente de visitas.

«Bueno, vale, ¿pero qué hago?»

Te veo venir, porque es justo donde te quedas después de tragarte todo esto: «vale, Fernando, ya sé cómo decirle a la IA que no me lea, de varias maneras, y sé qué funciona y qué no, pero yo, con mi web, ¿qué hago?».

Pues para ayudarte a poner orden en la decisión, te lo dejo en una tabla, y luego mi consejo.

Si miras la tabla entera, la lógica salta sola, pues casi todo lo que de verdad quieres (que no te entrenen) lo consigues con señales que no tocan tu SEO, y el bloqueo efectivo lo guardas para los que ignoran tus normas o solo consumen recursos del servidor.

Lo único que te cuesta visibilidad de verdad es impedir el paso a los bots de búsqueda, así que ese error no lo cometas sin querer.

Mi consejo, por si te sirve

Para la web típica, la de contenido, servicios o marca, mi posición es deja pasar a los bots de búsqueda (search) y de cita (assistant), que te interesa muchísimo que las IA te lean y te nombren.

Además, declarar con las Content Signals y el noai que no te entrenen, medir con VigIA quién te respeta, y bloquear de verdad solo a los que ignoran tus normas o te ponen a prueba el hosting.

Además, estoy muy a favor de limitarte solo en defenderte, a ir a por la atribución, que las IA te van a leer igual y más vale que te lleven de fuente.

Si en cambio tu negocio es contenido propietario, de pago o datos únicos, ahí sí, bloquea lo que haga falta y con menos remordimientos, o plantéate cobrar por el acceso.

Porque al final esto va de lo de siempre, de que hemos pasado de ser dueños de nuestro contenido a andar negociando quién lo lee, para qué y a cambio de qué.

Tu web es tuya y la decisión también, faltaría más, pero tómala con los datos delante y sabiendo qué es una declaración y qué es un bloqueo efectivo, que es justo lo que casi nadie te cuenta.

Si quieres seguir tirando del hilo, tengo más escrito sobre visibilidad en las IA, sobre el llms.txt y sobre cómo posicionar en las AI Overviews de Google, donde seguro que atas algún cabo más.

Y si lo ves de otra manera, o me quieres contar cómo lo llevas en tu web, me tienes ahí abajo, en la sección de comentarios, que para eso están.

Pues bien, resulta que ahí tienes el problema delante y no lo estás viendo, porque el tiempo no siempre se va en la base de datos.

Que conste, la mayoría de las veces que algo va lento la culpable sí es la base de datos, en eso llevas razón y por eso conviene empezar por ahí con la guía para optimizar las consultas SQL.

Pero cuando las consultas están limpias y la cosa se sigue arrastrando el tiempo de carga se te está yendo en otro sitio, en PHP puro, en un plugin que hace un bucle a lo bestia, en una llamada a una API externa metida dentro de un hook, en un render que se atasca.

Y no, eso en las consultas no sale.

Para medirlo con detalle existe el comando wp profile, que reparte el tiempo de carga por fases, pero necesita SSH y línea de comandos, y en un alojamiento compartido normal ni lo tienes ni te dejan tocarlo.

Así que aquí va la versión casera, un mu-plugin que te dice, al final de cada página, cuánto tiempo se ha ido en cada tramo de la carga. Sin consola, y solo lo ves solo tú.

Midiendo los tiempos de carga de una página web por fases

La carga de WordPress no es un bloque, son fases encadenadas, primero se cargan los plugins, luego arranca el tema, después se dispara init, viene la consulta principal y al final el render de la página.

La idea es poner un cronómetro en cada uno de esos pasos para ver en cuál se atasca la cosa.

Crea un archivo, por ejemplo ayudawp-phase-timer.php, y súbelo a la carpeta /wp-content/mu-plugins/ (si no existe la creas tú, es una carpeta normal y corriente).

Los mu-plugins ya sabrás se ejecutan solos y antes que todo lo demás, que es justo lo que necesitamos para cronometrar desde el arranque.

En fin, que este es el nene:

<?php
/**
* Plugin Name: Load Phase Timer
* Plugin URI: https://ayudawp.com/
* Description: Solo para admins: muestra los momentos en los que el tiempo real se solapa con el ciclo de carga de WordPress. Herramienta de diagnóstico, eliminar tras su uso.
* Version: 1.0.0
* Author: Fernando Tellado
* Author URI: https://tellado.es
 */

// Evitar el acceso directo
defined( 'ABSPATH' ) || exit;

// Solo se ejecuta cuando se activa explícitamente, para evitar una sobrecarga en el uso habitual
// Activar definiendo AYUDAWP_PHASE_TIMER como true in wp-config.php
if ( ! defined( 'AYUDAWP_PHASE_TIMER' ) || ! AYUDAWP_PHASE_TIMER ) {
	return;
}

// Una marca temporal por cada paso del ciclo
$GLOBALS['ayudawp_phase_marks'] = array();

// Ancla al inicio de la solicitud real, definida por PHP incluso antes de que se cargue WordPress
$GLOBALS['ayudawp_phase_marks']['request_start'] = isset( $_SERVER['REQUEST_TIME_FLOAT'] )
	? (float) $_SERVER['REQUEST_TIME_FLOAT']
	: microtime( true );

// Momento en que este mu-plugin empieza a ejecutarse
$GLOBALS['ayudawp_phase_marks']['muplugins_start'] = microtime( true );

/**
 * Registra el tiempo real de cada paso
 */
function ayudawp_mark_phase( $name ) {
	$GLOBALS['ayudawp_phase_marks'][ $name ] = microtime( true );
}

// Marca temporal de cada paso del ciclo de carga, en orden
add_action( 'muplugins_loaded',  function () { ayudawp_mark_phase( 'muplugins_loaded' ); },  0 );
add_action( 'plugins_loaded',    function () { ayudawp_mark_phase( 'plugins_loaded' ); },    0 );
add_action( 'after_setup_theme', function () { ayudawp_mark_phase( 'after_setup_theme' ); }, 0 );
add_action( 'init',              function () { ayudawp_mark_phase( 'init' ); },              0 );
add_action( 'wp_loaded',         function () { ayudawp_mark_phase( 'wp_loaded' ); },         0 );
add_action( 'template_redirect', function () { ayudawp_mark_phase( 'template_redirect' ); }, 0 );

// Al final de la solicitud muestra el informe (solo admins)
add_action( 'shutdown', 'ayudawp_print_phase_report', PHP_INT_MAX );

/**
 * Genera y muestra el desglose por fases como comentario HTML, solo para admins
 */
function ayudawp_print_phase_report() {

	// Nunca expone tiempos internos a visitantes
	if ( ! function_exists( 'current_user_can' ) || ! current_user_can( 'manage_options' ) ) {
		return;
	}

	ayudawp_mark_phase( 'shutdown' );
	$marks = $GLOBALS['ayudawp_phase_marks'];

	// Etiqueta para humanos => [ from milestone, to milestone ]. Cadena contigua
	$phases = array(
		'Antes de WordPress (arranque PHP)' => array( 'request_start', 'muplugins_start' ),
		'Carga de mu-plugins'               => array( 'muplugins_start', 'muplugins_loaded' ),
		'Carga de plugins'                  => array( 'muplugins_loaded', 'plugins_loaded' ),
		'Arranque del tema'                 => array( 'plugins_loaded', 'after_setup_theme' ),
		'Hasta init'                        => array( 'after_setup_theme', 'init' ),
		'De init a wp_loaded'               => array( 'init', 'wp_loaded' ),
		'Consulta principal'                => array( 'wp_loaded', 'template_redirect' ),
		'Render y salida'                   => array( 'template_redirect', 'shutdown' ),
	);

	$total = ( $marks['shutdown'] - $marks['request_start'] ) * 1000;

	$lines   = array();
	$lines[] = 'AyudaWP Load Phase Timer';
	$lines[] = 'URL: ' . ( isset( $_SERVER['REQUEST_URI'] ) ? esc_html( wp_unslash( $_SERVER['REQUEST_URI'] ) ) : 'n/a' );
	$lines[] = str_repeat( '-', 52 );

	foreach ( $phases as $label => $pair ) {
		list( $from, $to ) = $pair;

		// Omite fases cuyos pasos no se hayan activado (p.ej. template_redirect en wp-admin)
		if ( ! isset( $marks[ $from ], $marks[ $to ] ) ) {
			continue;
		}

		$ms  = ( $marks[ $to ] - $marks[ $from ] ) * 1000;
		$pct = $total > 0 ? ( $ms / $total ) * 100 : 0;
		$lines[] = sprintf( '%-38s %8.1f ms  %5.1f%%', $label, $ms, $pct );
	}

	$lines[] = str_repeat( '-', 52 );
	$lines[] = sprintf( '%-38s %8.1f ms', 'TOTAL', $total );

	$output = implode( "\n", $lines );

	// Red de seguridad: no dejar que el contenido salga del comentario HTML
	$output = str_replace( '-->', '--&gt;', $output );

	echo "\n<!--\n" . $output . "\n-->\n"; // phpcs:ignore WordPress.Security.EscapeOutput
}

Para que no te consuma nada en el día a día, el cronómetro solo se enciende cuando tú quieres. Añade esta línea a tu wp-config.php mientras diagnosticas y la quitas al terminar:

// Activa el temporizador de fase de AyudaWP para medir el tiempo de carga de las páginas
define( 'AYUDAWP_PHASE_TIMER', true );

Interpretar el reparto de tiempos

Abre como administrador la página que va lenta, mira el código fuente (botón derecho, Ver código fuente de la página) y busca al final del todo un comentario de código con el reparto de tiempos, verás algo así:

<!--
AyudaWP Load Phase Timer
URL: /mi-pagina-lentorra/
----------------------------------------------------
Antes de WordPress (arranque PHP) 37.8 ms 23.9%
Carga de mu-plugins 0.1 ms 0.1%
Carga de plugins 17.9 ms 11.3%
Arranque del tema 8.4 ms 5.3%
Hasta init 3.9 ms 2.5%
De init a wp_loaded 18.0 ms 11.4%
Consulta principal 8.1 ms 5.1%
Render y salida 63.8 ms 40.4%
----------------------------------------------------
TOTAL 158.1 ms
-->

La fase con más milisegundos es donde se te está yendo el tiempo. A partir de ahí:

• Si se concentra en Carga de plugins o en Hasta init, tienes demasiados plugins o alguno hace trabajo pesado al arrancar, así que toca revisar cuáles son y desactivar los que no aporten.
• Si el tiempo está en Consulta principal y las consultas estaban limpias, mira el bucle principal, las WP_Query mal montadas o los relacionados, y vuelve a esa guía de consultas SQL.
• Si el grueso está en Render y salida, el problema es de la plantilla, de shortcodes pesados o de scripts, no de la base de datos.

Ojo, esto es para direcciones de la parte visible de la web, en el escritorio (wp-admin) algunas fases no aparecen porque no llegan a dispararse, y es lo normal.

Y que quede claro, esto es un primer vistazo y no sustituye a nada. Cuando ya sepas donde se atasca la cosa y quieras al culpable concreto Query Monitor te atribuye cada consulta, cada llamada HTTP y cada hook al plugin que lo provoca. Y si tienes SSH, wp profile te da todo esto y bastante más.

Una última cosa, que luego todo son sustos, esto es una herramienta de diagnóstico y no se queda puesta. Cuando termines quita la línea del wp-config.php o borra directamente el archivo, que un cronómetro corriendo en cada carga, por ligero que sea, no pinta nada en producción.

¿Te ha salido disparada una fase que no te esperabas? Cuéntamelo aquí abajo en los comentarios, que seguro que no eres el único al que le pasa.

Las áreas habituales no son pocas, rondan la decena: entorno y servidor, núcleo de WordPress, tema, plugins, seguridad, rendimiento, SEO técnico, visibilidad IA y RGPD, más tienda online y multisitio si los hay.

Pues bien, hoy quiero compartir contigo cómo lo hacemos en mi servicio de mantenimiento de webs WordPress, y espero que te sea útil, no solo si también ofreces ese tipo de servicio, sino en otras posibles situaciones:

1. Asumes el mantenimiento de una web que no conoces y quieres saber dónde te metes antes de firmar, porque lo que no detectes hoy será tu problema mañana.
2. Te contratan una consultoría y necesitas diagnosticar el estado real de la web antes de recomendar nada.
3. Te encargan mejorar o rediseñar una web existente, o valorar una que tu cliente quiere comprar, y toca saber sobre qué base estás pisando.
4. Quieres analizar tu propia web para saber qué está bien, qué no, y cómo mejorarla de manera generalizada.

Igual que en la guía de auditoría de temas WordPress a medida, el artículo va en dos velocidades. Si prefieres no usar código cada bloque te dice qué puedes comprobar con herramientas visuales y qué pedirle a una IA, y si eres el técnico del proyecto tienes los comandos y el detalle que completan el trabajo.

Y aunque no tengas acceso por SSH ni por FTP, tranquilo, que en cada bloque te doy la manera de comprobar lo mismo desde el escritorio de WordPress, el panel del hosting o una herramienta, para que la falta de un acceso no te deje ningún bloque sin revisar.

Cada bloque de esta propuesta de estructura de auditoría clasifica los hallazgos en tres niveles, los mismos que luego usarás para priorizar el trabajo:

• Crítico (se corrige antes de cualquier otra cosa)
• Importante (se planifica en la próxima actuación)
• Menor (se documenta y se resuelve cuando toque pasar por ahí).

Vamos a verlo con calma.

Antes de tocar nada: accesos, contexto y red de seguridad

Una auditoría sin accesos completos es una auditoría a medias, así que lo primero es pedirle al cliente todo esto, y pedirlo por escrito, que luego las cosas se olvidan:

• Administrador de WordPress: un usuario propio para ti, nuevo, no el que se comparte media empresa por WhatsApp.
• Panel del hosting: sin él no puedes configurar versiones de PHP, base de datos, copias de seguridad con garantías ni logs del servidor.
• FTP/SFTP, WP-CLI o SSH: imprescindible para la velocidad técnica, y tu salvavidas si algo se rompe durante la revisión.
• Gestión del dominio y DNS: a veces está en un registrador distinto del hosting y nadie recuerda la contraseña, mejor descubrirlo ahora que durante una migración.
• Licencias de plugins y temas de pago: cuáles hay, quién las paga y desde qué cuenta se renuevan.
• Google Search Console, Bing Webmasters y Analytics: si existen, pide acceso; si no existen, ya tienes el primer hallazgo del informe.

Pide también contexto, que no todo son contraseñas: quién hizo la web, quién la ha tocado desde entonces, qué problemas recuerdan y si hay algo «que no se puede tocar porque se rompe». Esa última frase, cuando aparece, señala exactamente el sitio donde más falta hace la auditoría.

Y antes de nada, la red de seguridad: copia de seguridad completa, verificada y descargada fuera del servidor. La auditoría en sí no debería romper nada porque es observación, pero posiblemente vayas a activar plugins de diagnóstico y a hurgar en ajustes, y si algo falla quieres poder volver atrás sin depender de la copia (quizás inexistente, ya lo verás en el bloque de seguridad) del hosting.

Todo lo que sea intervención de verdad, en staging (una copia de pruebas de la web), nunca en producción.

Herramientas básicas

Para la velocidad sin código usa el modo depuración de WordPress con registro en archivo, el plugin oficial Health Check & Troubleshooting y la pantalla salud del sitio, que ya viene de serie en la pantalla de herramientas, y es el mejor punto de partida que regala WordPress. Con eso y tu IA de confianza cubres la mayor parte del recorrido.

Para todo lo que normalmente pedirías por FTP, el gestor de archivos del hosting (cPanel, Plesk, las Site Tools de SiteGround o prácticamente cualquier panel) te deja ver y editar ficheros y revisar permisos sin instalar nada ni abrir una consola, que es tu puente para casi todo lo que aquí resuelvo por línea de comandos.

Para la parte más técnica te recomiendo tener Query Monitor instalado durante la auditoría (y desinstalado después), WP-CLI por SSH para los comandos que irán apareciendo, y una hoja de cálculo o herramienta donde ir anotando hallazgos con su gravedad, porque una auditoría que no se documenta sobre la marcha es una auditoría que toca repetir.

Y si la caché no te deja ver el estado real de la web mientras investigas, el plugin Anti-Cache Kit vacía y desactiva de golpe los plugins de caché, activa el modo depuración y lo revierte todo al desactivarlo, con la misma regla que Query Monitor de activo mientras dura la auditoría, fuera al terminar.

Qué puedes auditar sin tener acceso ni una triste contraseña de nada

Mientras esperas los accesos (en la vida real tardan días, ya lo verás) puedes ir adelantando trabajo, porque una parte sorprendentemente amplia de la auditoría se puede hacer desde fuera, con la web pública y cuatro herramientas gratuitas.

La forma rápida de barrer casi todo este bloque es el análisis de seguridad WordPress de las herramientas gratuitas, que hace más de 30 comprobaciones externas de seguridad de una tacada, entre las que están algunas tan importantes como las cabeceras HTTP, certificado SSL, exposición de archivos, listas negras y bastantes más.

Lo anterior lo complementas con PageSpeed Insights para las métricas de experiencia real de usuarios, SSL Labs para el certificado a fondo y MXToolbox para DNS, listas negras y la salud del correo del dominio.

Lo del correo casi nadie lo mete en una auditoría web y luego pasa lo que pasa, y hay cosas que revisar, como los registros SPF, DKIM y DMARC (las firmas DNS que autorizan quién puede enviar correo en nombre del dominio), que determinan si los emails de la web (pedidos, formularios, recuperación de contraseña) llegan a la bandeja de entrada o mueren en spam.

De todo esto ya nos saldrá información que podemos empezar a clasificar.

Crítico

• Certificado SSL caducado, mal instalado o con la cadena incompleta: además del susto del navegador, invalida de facto todo lo demás.
• Dominio o IP en listas negras de spam o malware: hay que averiguar el porqué antes de seguir, puede ser herencia de una infección pasada o señal de una activa.
• Contenido mixto (recursos HTTP dentro de páginas HTTPS): candado roto, avisos al visitante y datos viajando sin cifrar.
• Sin SPF ni DMARC en un dominio que envía correo transaccional: entregabilidad a la ruleta y suplantación del dominio servida en bandeja.

Importante

• Cabeceras de seguridad ausentes (HSTS, X-Content-Type-Options o Referrer-Policy, entre otras): se resuelven en el bloque de seguridad, aquí solo se anotan.
• Métricas Web Principales no superadas en datos de campo: LCP por encima de 2,5 segundos o INP por encima de 200 ms en móvil apuntan maneras para el bloque de rendimiento.
• Versión de WordPress visible en el meta generator y archivos como readme.html accesibles: información regalada a cualquier escáner automático.

Menor

• Sin archivo security.txt (el estándar para que investigadores de seguridad sepan a quién avisar si encuentran algo).
• TTFB (el tiempo que tarda el servidor en empezar a responder) por encima de 800 ms desde ubicaciones cercanas al público del sitio: no es sentencia, pero es la primera pista de un hosting justito.

Entorno y servidor

Con los accesos ya en la mano, lo primero es analizar los cimientos de la web, porque ninguna optimización posterior compensa un servidor por debajo de mínimos. La pantalla de información de la salud del sitio te da casi todo el inventario sin salir de WordPress, y el panel del hosting completa el resto.

Para el técnico, wp cli info, wp core check-update y un vistazo a phpinfo() temporal (que borrarás al terminar, no como los que verás en el bloque de seguridad) cierran la foto.

Lo que hay que inventariar es el hosting y tipo de servidor (Apache, Nginx, LiteSpeed), versión de PHP y sus límites de memoria y ejecución, versión de MySQL o MariaDB, protocolo HTTP, compresión activa, sistema de copias del hosting, CDN si la hay y cómo está gestionado el cron.

Las referencias contra las que comparar las tienes siempre al día en la página oficial de requisitos de WordPress, que son versiones de PHP y base de datos mínimos y recomendados del momento. La regla que nunca caduca es que una versión de PHP sin soporte de seguridad es siempre un mal comienzo, aunque WordPress todavía la acepte, así que un servidor anclado en versiones viejas acumula papeletas más deprisa de lo que su dueño se imagina.

El cron merece párrafo propio, pues WordPress tiene su propio planificador de tareas (wp-cron) que se ejecuta cuando alguien visita la web, lo que significa que en webs con poco tráfico las tareas programadas se retrasan y en webs con mucho tráfico se dispara más de la cuenta.

La configuración sana en producción es desactivarlo con define( 'DISABLE_WP_CRON', true ); y sustituirlo por un cron real del servidor cada pocos minutos. Si encuentras publicaciones programadas que no se publicaron ya sabes por dónde empezar.

Crítico

• Versión de PHP sin soporte de seguridad (que el hosting te la ofrezca no la convierte en segura): sin parches ante vulnerabilidades nuevas, es la primera actualización a planificar, en staging y con calma.
• Sin copias de seguridad del hosting, o existentes pero jamás restauradas: una copia que nunca se ha probado a restaurar es una esperanza, no una copia.
• Correo transaccional saliente sin authentication por PHP con la función mail() en un dominio con SPF estricto: los correos de la web no llegan, y nadie se ha dado cuenta porque nadie los echa de menos hasta que hacen falta.

Importante

• Límite de memoria PHP por debajo de 256 MB en webs con WooCommerce o page builders: errores intermitentes difíciles de reproducir que desaparecen «solos».
• Función wp-cron sin sustituir por cron de sistema en webs de tráfico alto o muy bajo.
• Servidor sin HTTP/2 (ya ni hablamos de HTTP/3) o sin compresión Brotli/GZIP activa: rendimiento regalado que no cuesta dinero activar.
• Base de datos en MySQL 5.7 o MariaDB antiguas: funcionan, pero sin soporte y perdiendo mejoras de rendimiento considerables.

Menor

• Sin CDN en webs con público geográficamente disperso: mejora disponible, no urgencia.
• Espacio en disco o inodos cerca del límite del plan: hoy anécdota, el día que la web no pueda escribir ni una imagen, drama.
• Logs de error del servidor inaccesibles o desactivados: sin ellos, el próximo diagnóstico será a ciegas.

El núcleo de WordPress y ajustes que nadie revisa

Aquí se audita el WordPress en sí, o sea, la versión, integridad del sistema, configuración y usuarios. Es el bloque más rápido de revisar y donde aparecen algunos de los hallazgos más incómodos de explicar al cliente, porque casi todos se arreglaban con un clic que nadie hizo en su momento.

Sin necesidad de código, la herramienta de salud del sitio te dice versión, actualizaciones pendientes y problemas de configuración, y en los ajustes de lectura está la casilla más peligrosa de WordPress, la de disuadir a los motores de búsqueda, que en más de una web estrenada lleva años marcada sin que nadie sepa por qué el SEO no despega.

Repasa también los usuarios para saber cuántos administradores hay, si siguen en la empresa y si alguno se llama admin, que a estas alturas ya es casi una declaración de intenciones.

Con código, la comprobación estrella es la integridad del núcleo:

wp core verify-checksums
wp plugin verify-checksums --all

El primer comando compara cada archivo del núcleo con el original de WordPress.org y delata cualquier archivo modificado o añadido, que es una de las formas más rápidas de detectar una infección. El segundo hace lo mismo con los plugins del repositorio oficial.

Para realizar este tipo de comprobación si no tienes acceso a la interfaz de comandos puedes usar el scanner de integridad de archivos y la auditoría de seguridad del plugin de seguridad Vigilante.

En wp-config.php revisa que las claves y salts de seguridad existan y no sean las de ejemplo, que WP_DEBUG no esté activo en producción y si hay constantes útiles como DISALLOW_FILE_EDIT (desactiva el editor de código del admin, un clásico de la post-explotación).

Crítico

• Núcleo de WordPress varias versiones mayores por detrás: no es solo funcionalidad, cada versión sin aplicar es una lista pública de vulnerabilidades corregidas que la web sigue teniendo.
• Detectar con verify-checksums con archivos modificados o desconocidos en el núcleo: tratar como incidente de seguridad hasta demostrar lo contrario.
• Administradores que ya no trabajan en el proyecto con la cuenta activa, o cuentas compartidas entre varias personas: cada admin de más es una puerta de entrada más.
• Constantes WP_DEBUG con WP_DEBUG_DISPLAY activo en producción: rutas, consultas y errores del servidor impresos en pantalla para quien pase por allí.

Importante

• Actualizaciones automáticas del núcleo desactivadas del todo, sin proceso alternativo que las cubra: las menores de seguridad deberían estar siempre activas.
• Salts de seguridad de wp-config.php sin regenerar desde el año de la instalación, o iguales entre el sitio de producción y copias de staging que andan por ahí.
• Prefijo de tablas wp_ con usuarios y contraseñas heredados de instaladores automáticos antiguos: el prefijo en sí no es la muralla que algunos venden, pero el combo delata una instalación nunca revisada.
• Zona horaria, idioma o ajustes de comentarios sin configurar (bien): spam entrando a manta por comentarios abiertos sin moderación en entradas de hace cinco años, pingbacks y trackbacks activos, emails innecesarios.

Menor

• Etiqueta meta generator con la versión de WordPress en el HTML: información innecesaria de cara al exterior.
• Página «Hola mundo», página de ejemplo y temas de prueba aún publicados: cosmética, pero cosmética que retrata el nivel de mantenimiento que ha tenido la web.

El tema WordPress y sus personalizaciones

Al tema le dediqué una guía completa de auditoría de temas a medida, con análisis de código, seguridad, rendimiento y SEO bloque a bloque, así que no voy a repetirla aquí. Lo que sí forma parte de esta auditoría general es lo que el tema cuenta de sí mismo a nivel de instalación, sin abrir un solo archivo.

En Apariencia → Temas lo razonable a revisar es el tema activo, su tema padre si es un tema hijo, y un tema de respaldo reciente de los de WordPress (el Twenty Twenty-algo de turno) para pruebas y emergencias.

Todo lo demás sobra, y no por manía, pues cada tema instalado es código presente en el servidor que hay que mantener actualizado aunque esté inactivo, porque un tema desactivado también es explotable si tiene una vulnerabilidad.

Crítico

• Tema activo sin actualizaciones disponibles porque el desarrollador desapareció o la licencia caducó: la web funciona sobre código congelado y sin parches, decisión estratégica a poner sobre la mesa del cliente cuanto antes.
• Tema padre modificado directamente, sin tema hijo: la próxima actualización del padre borra los cambios sin avisar.

Importante

• Licencia del tema de pago sin saber quién la paga ni desde qué cuenta: mientras nadie lo aclare, las actualizaciones dependen de una renovación que quizás ya no existe.
• Media docena de temas instalados por si acaso: superficie de ataque y peso de mantenimiento sin beneficio alguno.
• Tema hijo con cambios sustanciales sin documentar: funciona, pero nadie sabe qué se tocó ni por qué, y eso en la práctica es deuda técnica heredada.

Menor

• Tema hijo con cabecera incompleta o style.css vacío: señal de creación con prisas, revisar que al menos esté bien construido.

Si el tema es a medida o hay mucho que revisar, ahí sí, guía completa de auditoría de temas que te comenté antes, y la herramienta gratuita de auditoría de temas WordPress para documentar los hallazgos y generar el informe.

Los plugins

Este es el bloque estrella de la auditoría, y no lo digo por decir, pues la inmensa mayoría de las vulnerabilidades que se descubren en el ecosistema WordPress están en los plugins, casi todo el resto en los temas y un puñado testimonial en el núcleo, año tras año en cada informe del sector.

La seguridad, el rendimiento y buena parte de los problemas raros de una web WordPress viven en su lista de plugins, así que aquí conviene ir despacio.

Lo primero es el inventario. Sin necesidad de código puedes revisar la pantalla de plugins con sus contadores, con código esta línea te da la foto completa lista para pegar en el informe:

wp plugin list --fields=name,status,version,update,auto_update

Y ahora, las preguntas que hay que hacerle a esa lista, una por una:

• ¿Cuántos hay y cuántos están activos?: Los inactivos son código explotable en el servidor. Se verifica que no hagan falta, se borran (no solo desactivar) y listo.
• ¿Cuáles están abandonados?: En la ficha de WordPress.org hay que mirar última actualización hace más de dos años, sin probar en las últimas tres versiones mayores o con el aviso naranja del repositorio. Un plugin abandonado no avisa, simplemente un día deja de funcionar o se convierte en el agujero por el que entran. Si tienes un plugin como Worfence o Vigilante te avisan en su scanner de plugins cerrados y abandonados.
• ¿Hay duplicidades funcionales?: Dos plugins de caché, dos de SEO, tres de seguridad pisándose las reglas entre sí. Pasa muchísimo más de lo que parece, y el resultado nunca es doble protección, es doble carga y conflictos.
• ¿Hay plugins de pago sin licencia?: Versiones pro que no se actualizan desde tiempos inmemoriales, o instaladas desde «clubs GPL» de dudosa procedencia. Además del riesgo legal que el cliente debe conocer, un plugin de pago sin licencia es un plugin sin actualizaciones, y sin actualizaciones no hay parches de seguridad.
• ¿Tiene alguno vulnerabilidades conocidas?: Se busca cada plugin con su versión exacta en Patchstack o WPScan. Si aparece con vulnerabilidad sin parchear, al primer puesto de la lista de acciones.
• ¿Cuánto cuesta cada uno en rendimiento?: Con Query Monitor ves qué plugin mete más consultas y más tiempo en cada carga. No se trata del número de plugins, que ese debate está más que visto y el problema nunca es la cantidad de plugis, es sobrecargar la web con código que no necesita. Cinco plugins bien programados y realmente necesarios pesan menos que un todo-en-uno hinchado.
• ¿Qué hay en mu-plugins y en los drop-ins?: La carpeta mu-plugins (plugins de activación obligatoria que no aparecen en la lista normal) y los drop-ins como object-cache.php o advanced-cache.php son los rincones que nadie mira, donde lo mismo vive una integración legítima del hosting que un regalo de un atacante con acceso pasado. En Plugins → Imprescindibles se listan los mu-plugins y, si hay plugins dependientes (drop-ins), aparece también su pestaña, y por consola los sacan wp plugin list --status=must-use y wp plugin list --status=dropin. Para asomarte a lo que hay dentro de esos archivos sin SSH, tira del gestor de archivos del hosting, que es justo el sitio donde un atacante esconde lo que no quiere que veas.
• ¿Qué dejaron los plugins desinstalados?: Tablas huérfanas en la base de datos, opciones con autoload y tareas cron que siguen ejecutándose contra nada. Lo retomamos en el bloque de rendimiento, pero se detecta aquí, comparando la lista de plugins con lo que hay en la base de datos.

Para algo rápido sin código hay truco, y es pegar la lista completa de plugins (nombre y versión) en tu IA de confianza con este prompt:

Esta es la lista de plugins de una instalación WordPress con sus versiones. Dime: 1) cuáles parecen abandonados o con mala reputación de mantenimiento; 2) qué duplicidades funcionales detectas; 3) cuáles tienen vulnerabilidades conocidas en esas versiones; 4) qué preguntas debería hacerle al propietario sobre licencias. Preséntalo como tabla con nivel de prioridad.

La respuesta no sustituye la comprobación en Patchstack o WPScan (la IA puede no conocer lo de esta semana), pero como primer barrido y detector de duplicidades funciona de maravilla.

Crítico

• Plugins con vulnerabilidades conocidas sin parchear en la versión instalada: actualización o retirada inmediata, antes de terminar la auditoría siquiera.
• Plugins nulled o de procedencia desconocida: retirada y sustitución, sin matices. Nunca sabes qué llevan dentro, y lo que llevan dentro a veces se llama puerta trasera.
• Plugins abandonados ocupando funciones primordial de la web (formularios, tienda, membresías): planificar sustitución ya, no cuando falle.

Importante

• Plugins inactivos acumulados sin verificar ni borrar.
• Duplicidades funcionales activas (especialmente caché y SEO): elegir uno, configurar bien y retirar el resto.
• Licencias de pago sin titular claro: documentar quién paga qué, cuánto y hasta cuándo, en el informe.
• Actualizaciones automáticas sin criterio: ni todo activado a lo loco en una web crítica sin staging, ni todo desactivado y sin nadie que actualice a mano. Lo importante es que haya una decisión consciente, no una casilla olvidada.

Menor

• Plugins de un solo uso puntual (un import de hace años, un generador de algo) que siguen instalados: fuera con ellos.
• Restos menores de plugins desinstalados en base de datos: se limpian en la fase de optimización, con copia previa.

La SEGURIDAD

Instalar un plugin de seguridad y darse por protegido es como comprar un extintor para tu casa y dejarlo en el maletero del coche, porque de algo servirá, pero no es un plan. Lo que se audita aquí es cuántas capas reales de protección tiene la web y cuántas cree tener, que suelen ser números distintos.

Sin tener que tirar de código, el barrido externo ya lo hiciste con el análisis de seguridad del bloque sin accesos, y ahora toca la parte interna, que es probar a mano si responden URLs que jamás deberían responder, como /debug.log, /.env, /phpinfo.php, el listado de directorios en /wp-content/uploads/ o copias de seguridad sueltas tipo backup.zip en la raíz.

Cada una de esas URLs respondiendo contenido es un hallazgo directo al informe, y más habitual de lo que te gustaría creer.

Pero hay un hallazgo que no está en ninguna URL suelta pero aparece más de lo que parece, como una copia de staging, de pre-producción o un clon viejo del sitio accesible al público, que Google indexa y un atacante estudia a placer para colarse por la de verdad.

Si das con una, hasta que decidas si la migras o la borras, lo suyo es cerrarla con acceso obligatorio, y para eso te vale un plugin como Gozer, que deja la web entera detrás del acceso con un clic.

Con código, además de los checksums que ya pasaste en el bloque del núcleo, toca comprobar permisos de archivos (directorios en 755, archivos en 644 y wp-config.php más restrictivo), probar xmlrpc.php (si responde y nadie lo usa para nada, se cierra), consultar /wp-json/wp/v2/users a ver si la web muestra la lista de usuarios a cualquiera (enumeración vía REST API), y revisar a fondo las cabeceras de seguridad que anotaste en el barrido externo.

Si no tienes consola no te preocupes que este bloque de auditoría no se te queda a medias, la propia comprobación de seguridad que trae el plugin Vigilante corre más de 40 chequeos desde dentro de WordPress, incluidos decenas que no se pueden hacer desde fuera, como los permisos de los archivos, los salts por defecto, el prefijo wp_, si hay algún administrador sin 2FA o si tu versión de PHP ya está fuera de soporte.

Así que buena parte de lo que sacarías por SSH lo tienes en una sola pantalla. Los permisos concretos también los ves y los cambias desde el gestor de archivos del hosting, y las URLs que no deberían responder las pruebas tú mismo en el navegador, que para eso no hace falta ni herramienta.

El modelo mental para el informe son 3 niveles de cortafuegos:

• CDN/perímetro (Cloudflare o similar por delante del servidor).
• Servidor (lo que ponga el hosting)
• Aplicación (plugin de seguridad bien configurado)

No son obligatorios los tres en toda web, pero hay que saber cuáles hay, y si la respuesta es «ninguno», eso es un problema, no una opinión.

Y la joya de la corona, las copias de seguridad, donde la regla razonable es la 3-2-1 (tres copias, en dos soportes, una fuera del servidor). La copia de seguridad del hosting cuenta como una, no como el plan entero, porque si el servidor arde o la cuenta se suspende, se llevan la web y la copia en el mismo incendio.

Crítico

• Malware o código inyectado detectado: se acabó la auditoría normal, toca protocolo de limpieza, y si el sitio es un tema a medida revisa la guía de detección de código malicioso antes de tocar nada.
• Archivos debug.log, .env o phpinfo.php accesibles públicamente: exposición directa de rutas, errores, credenciales o configuración del servidor.
• Sin identificación en dos pasos (2FA) en cuentas de administrador, combinado con login sin límite de intentos: la puerta principal abierta a fuerza bruta con toda la paciencia del mundo.
• Copias de seguridad inexistentes, solo en el propio servidor o nunca restauradas de prueba.
• Enumeración de usuarios abierta vía REST API o archivos de autor, con nombres de usuario que coinciden con los del login, con lo que la mitad del trabajo del atacante ya se la das hecha.

Importante

• Cabeceras de seguridad ausentes o incompletas (HSTS, CSP aunque sea básica, X-Frame-Options, Referrer-Policy).
• xmlrpc.php activo sin uso que lo justifique.
• Sin cortafuegos de aplicación ni plugin de seguridad configurado, o instalado con los ajustes de fábrica sin adaptar.
• Listado de directorios activo en uploads o directorios sensibles.
• Sin monitorización de cambios en archivos: para esto Vigilante es fundamental, es un plugin gratuito, escanea los archivos y te avisa si alguien modifica algo sin que lo sepas, que es exactamente lo que hace un atacante cuando planta una puerta trasera en un archivo que ya existía. La auditoría te dice cómo está la web hoy, Vigilante te avisa si deja de estarlo mañana.

Menor

• URL de acceso sin enmascarar: medida cosmética que reduce ruido de bots, no sustituye a nada de lo anterior, pero como higiene vale.
• Meta generator, readme.html y versiones visibles: ya anotado en el barrido externo, se resuelve junto al resto.
• Endpoint de Application Passwords activo sin uso conocido: revisar y cerrar si nadie lo necesita.

Rendimiento y velocidad de carga

Antes de tocar nada conviene separar dos mundos que se confunden constantemente. Me refiero a los datos de campo (lo que experimentan los usuarios reales, que es lo que Google usa para valorar la web) y, por otro lado, a los datos de laboratorio (la simulación que hace la herramienta de turno para diagnosticar).

El informe se abre con los de campo, que salen en PageSpeed Insights si la web tiene tráfico suficiente, y las referencias son las métricas web principales: LCP hasta 2,5 segundos, INP hasta 200 ms y CLS hasta 0,1. El laboratorio viene después, para averiguar el porqué de cada suspenso.

La revisión interna va por capas de caché, que en una web sana son varias y coordinadas:

• Caché de página (el plugin de turno o la del hosting, uno solo y bien configurado)
• Caché de objetos (Redis o Memcached si el hosting la ofrece, imprescindible para tiendas y membresías),
• OPcache de PHP y caché de navegador con sus caducidades.

Como auditor tu misión no es saber si hay un plugin de caché, la cuestión adecuada es más bien cuántas capas hay, si se solapan y con qué criterio se han configurado.

Después, la base de datos, esa gran olvidada. Con código, esta línea te dice cuántos KB de opciones se cargan en memoria en cada petición (autoload):

wp option list --autoload=on --format=total_bytes

Por debajo de 1 MB vas bien, y a partir de ahí cada MB extra es lastre que se carga en todas y cada una de las visitas. El desglose de culpables te lo da AAA Option Optimizer, que además identifica opciones huérfanas de plugins ya desinstalados.

Completa el repaso con revisiones acumuladas por miles, transients caducados y tablas huérfanas, todo ello con copia de seguridad previa antes de limpiar nada.

Quedan los sospechosos habituales, que son las imágenes sin optimizar (formatos modernos WebP o AVIF, tamaños acordes a lo que se muestra, carga diferida nativa).

También cuentan las fuentes cargadas desde Google en vez de alojadas en local (doble motivo para cambiarlo, el segundo te espera en el bloque RGPD), el Heartbeat de WordPress a su ritmo por defecto en el admin, y JavaScript y CSS sin minimizar ni combinar con criterio.

Crítico

• Métricas web principales suspensas en campo en móvil: afectan hoy mismo a usuarios y posicionamiento.
• Sin ninguna caché de página activa en una web con tráfico: cada visita cocina la página desde cero, con el servidor pagando la fiesta.
• Autoload de opciones desbocado (varios MB): impuesto invisible en cada petición, incluidas las del admin.
• Dos o más plugins de caché u optimización activos a la vez: no suman, se pisan, y los efectos son de los que vuelven loco a cualquiera («a veces va lento, a veces no»).

Importante

• Sin caché de objetos disponible o disponible pero sin activar en webs con WooCommerce o membresías.
• Imágenes a pelo: sin formatos modernos, sin dimensionar y sin comprimir. Suele ser la mejora más visible por esfuerzo invertido.
• Fuentes externas de Google sin alojar en local.
• Base de datos sin mantenimiento: revisiones infinitas, transients caducados, restos de plugins.
• Heartbeat sin controlar en webs con muchos usuarios simultáneos en el admin.

Menor

• Minimizado de JS/CSS sin aplicar: mejora real pero modesta, y siempre después de tener el resto en orden.
• Recursos (assets) que cargan en páginas donde no se usan: afinado fino, planificable.

SEO / AEO técnico

Aquí no se audita el contenido ni las palabras clave, se audita la fontanería, las tripas, que lo que debe indexarse se pueda indexar, que lo que no deba no se indexe, y que ninguna configuración esté saboteando el trabajo de nadie. Es un bloque donde los hallazgos críticos suelen ser pocos pero de los que hacen polvo el negocio del cliente.

Empieza por lo que ya viste en el núcleo (la casilla de visibilidad) y sigue con el plugin SEO, y no es complicado, básicamente que haya uno, que sea uno solo y que esté bien configurado, adaptado al sitio, no instalado y ya.

Aquí cada maestrillo tiene su librillo, y yo en mis webs uso Visibility, plugin de SEO nativo y ligero pensado justo para sustituir suites hinchadas, pero lo que se audita no es la marca del plugin sino que la herramienta esté bien elegida y mejor configurada.

Después el robots.txt (que no bloquee CSS ni JavaScript y que no arrastre un Disallow: / heredado de staging), el mapa del sitio (accesible, declarado en robots.txt, enviado a Search Console y Bing, y sin URLs que no deberían estar).

Las redirecciones (una sola cadena de www/no-www y HTTP a HTTPS, sin saltos encadenados) y el estado de indexación real en Search Console Bing Webmasters, que para eso pediste el acceso al principio.

Del lado del código fuente toca ver si el canonical es correcto, que haya un solo H1 por página y jerarquía de encabezados sin saltos (el detalle fino lo tienes en la guía de auditoría de temas), schema sin duplicar entre tema y plugin SEO, y hreflang si hay idiomas.

Para saber en qué se está gastando Google el rastreo de la web, mi analizador de límites de rastreo te da la foto del crawl budget (el presupuesto de rastreo que Google dedica al sitio) sin instalar nada.

Crítico

• Casilla de disuadir buscadores activa, meta robots noindex global o Disallow: / en robots.txt en una web en producción: la web está pidiendo por escrito que no la encuentren.
• Dos plugins SEO activos o schema y metas duplicados entre tema y plugin: dos fuentes contándole a Google cosas distintas sobre la misma página.
• Acciones manuales o problemas de seguridad notificados en Search Console que nadie ha leído: pasa, y más de lo que parece, porque nadie mira el buzón.
• Redirecciones en cadena o bucles entre versiones www/no-www y HTTP/HTTPS.

Importante

• Mapa del sitio con URLs noindex, archivos adjuntos o taxonomías vacías, que son ruido que gasta rastreo.
• Errores 404 en enlaces internos y sin sistema de redirecciones para URLs que cambiaron.
• Enlaces externos dofollow donde deberían ser nofollow (patrocinados, afiliados sin marcar, iconos sociales, páginas legales).
• Imágenes sin texto alternativo de forma sistemática, lo que supone accesibilidad y SEO de imágenes a la vez.

Menor

• Relación texto/código muy baja en páginas clave es señal de plantillas sobrecargadas, se anota para la fase de mejoras.
• Migas de pan ausentes o sin schema correspondiente.

Visibilidad IA

Cada vez más gente pregunta directamente a ChatGPT, Claude, Perplexity y compañía, y Google responde con IA antes de mostrar el primer resultado clásico.

Eso convierte en revisión de auditoría algo que hace tres años no existía, saber si pueden las IAs descubrir, entender y citar el contenido de esta web Y otra duda igual de legítima, si quiere el propietario que puedan.

Porque este bloque tiene una particularidad que no tiene ningún otro, que el resultado correcto depende de una decisión de negocio del cliente.

Hay quien quiere aparecer en cada respuesta de IA y hay quien no quiere ceder ni una coma para entrenamiento. Decidirlo no te toca a ti, tu trabajo es documentar el estado actual y sus consecuencias, que casi siempre son involuntarias, pues la mayoría de las webs ni bloquean ni facilitan, simplemente nadie ha mirado.

Hay mucho que revisar, como las directivas para bots de IA en robots.txt, con el matiz de que el robots.txt es orientativo, quien de verdad quiera bloquear necesita hacerlo por PHP con respuesta 403), archivos llms.txt y llms-full.txt, Content Signals en robots.txt (definido por Cloudflare para declarar qué usos permites de búsqueda, asistentes y entrenamiento de IA), datos estructurados JSON-LD de identidad, etiquetas Open Graph y Twitter Cards, HTML5 semántico, feed RSS accesible, contenido legible sin ejecutar JavaScript y, en el extremo más avanzado, contenido en Markdown para agentes de IA.

Mucho que revisar ¿verdad? No te preocupes, hay ayudas para todo.

Para el diagnóstico externo tienes el analizador de visibilidad IA puntúa la web sobre 100 en cinco categorías y te dice exactamente qué falta. Sencillo, completo y gratis.

Y para implantar y vigilar desde dentro usa VigIA, esa joya de plugin, también gratuito, que monitoriza más de 55 rastreadores de IA con analítica de cuáles pasan y qué leen, genera los llms.txt, sirve el contenido como Markdown para agentes, añade el JSON-LD de identidad y bloquea por PHP a los bots que decidas, todo en uno y de paso midiendo qué rastreadores ignoran tu robots.txt.

Crítico

• Contenido invisible sin JavaScript en una web que vive de ser encontrada: si el HTML llega vacío, para buena parte de los rastreadores de IA la web no existe.
• Bloqueos involuntarios heredados (reglas anti-bots del hosting o CDN que nadie configuró a propósito) en una web cuyo negocio es la visibilidad.

Importante

• Sin decisión documentada sobre bots de IA: ni directivas, ni señales, ni criterio. El hallazgo que apuntas al informe ahí se llama «nadie ha decidido nada».
• Sin datos estructurados de identidad (WebSite/Organization) ni Open Graph: las IAs pueden leer la web pero no saben de quién es ni cómo citarla.
• Feed RSS desactivado o roto: sigue siendo una de las vías favoritas de descubrimiento de contenido, también para las IAs.

Menor

• Sin llms.txt ni Markdown para agentes en una web que sí quiere visibilidad IA: mejora incremental, fácil de añadir con VigIA.
• Sin Content Signals en robots.txt: el estándar es joven, pero declarar intenciones cuesta un minuto.

Legalidad técnica y funcional

Aviso antes de empezar, para que quede claro, no soy abogado y esto no es asesoramiento jurídico. Lo que sí puedo contarte es qué comprueba un técnico en una auditoría para saber si la web tiene los deberes hechos o está coleccionando papeletas para una sanción, y con eso tu cliente ya puede ir a su asesor con datos en vez de con vaguedades.

La comprobación principal se hace con las DevTools del navegador en una ventana de incógnito. Para ello abre la pestaña de red y la de cookies antes de aceptar nada en el banner y mira qué se carga. Si ya hay cookies de analítica o marketing, o peticiones saliendo hacia Google, Meta y compañía antes del consentimiento, el banner es decorativo, y un banner decorativo es peor que no tenerlo, porque documenta que sabías que tenías que pedir permiso.

El criterio vigente de la AEPD añade otra comprobación de primero de RGPD: rechazar tiene que ser tan fácil como aceptar, mismo nivel, mismo número de clics.

Las fuentes de Google cargadas en remoto son el segundo clásico. Un tribunal alemán ya sentenció que enviar la IP del visitante a Google sin consentimiento por cargar una fuente es sancionable, y de aquella sentencia llovieron reclamaciones por media Europa. Se detectan en la pestaña de red (peticiones a fonts.googleapis.com o fonts.gstatic.com).

El mismo repaso vale para vídeos de YouTube incrustados sin modo de privacidad mejorada, mapas y cualquier recurso de terceros que se cargue antes de consentir.

Completa el bloque lo de siempre que casi nunca está, como formularios y su primera capa informativa y casilla de aceptación sin activar por defecto, textos legales que describan lo que la web hace de verdad (no la plantilla de otra web con el buscar-y-reemplazar a medias, que hay por ahí cada política de privacidad con el nombre de otra empresa dentro que asusta), y si hay productos de Google en juego, Consent Mode v2 funcionando, obligatorio para audiencias del Espacio Económico Europeo.

Hasta aquí las cookies, pero hay otro consentimiento que casi nadie audita y que no tiene nada que ver con el banner. Una cosa es ePrivacy, lo del banner de cookies, y otra el consentimiento al que se refiere el artículo 7.1 del RGPD, el de aceptar tus condiciones o tu privacidad en un formulario, en el registro o en el pago.

La mayoría de webs tienen la casilla marcada pero no guardan ninguna prueba de que se marcó, y el 7.1 no pide la casilla, pide que puedas demostrar el consentimiento: cuándo se dio, desde qué IP, y qué texto y qué versión se aceptaron. Sin ese registro una casilla marcada no vale de nada el día que alguien reclama.

Hay plugins de cookies que incluyen algún registro suelto, pero para dejar esa prueba sellada y a prueba de manipulación tienes Terms & Conditions Consent Log, que guarda fecha, IP, agente de usuario, versión y el texto exacto con un hash SHA-256, y funciona con WooCommerce, Contact Form 7, WPForms, Gravity Forms, Fluent Forms y hasta los comentarios y el registro de WordPress.

Y si la web es una tienda (o sitio corporativo de una física), apunta otra obligación que no estaba hace nada, y que desde el 19 de junio de 2026 está en vigor en toda la UE el desistimiento digital, la Directiva 2023/2673, que exige que el cliente pueda desistir de su compra tan fácil como la hizo, con un botón o formulario claro, respetando los 14 días y con las exclusiones del artículo 16 bien marcadas, que es lo que por ley no admite devolución.

Comprobar que ese mecanismo existe y que funciona es tan parte de la auditoría legal como el banner de cookies, y lo verás de verdad al hacer el pedido de prueba del bloque de tienda. Te lo cuento a fondo en la guía del derecho de desistimiento en WooCommerce.

Para cumplirlo ya hay varios plugins de botón de desistimiento en el repositorio, pero ninguna cumplía del todo así que preparé uno que sí, gratis como siempre, EU Withdrawal Compliance, que añade la función de desistimiento, guarda un recibo con hash SHA-256, incluye el formulario modelo del anexo I.B y te deja marcar las exclusiones del artículo 16 por producto y por categoría, con o sin WooCommerce.

La accesibilidad tampoco es ya cosa de buenos samaritanos, la Ley Europea de Accesibilidad está en vigor desde junio de 2025 y obliga a la mayoría de webs comerciales, así que en una auditoría de 2026 hay que mirarla, aunque sea por encima.

No toca hacer aquí una auditoría WCAG completa, pero sí un primer barrido de lo fundamental, o sea contraste suficiente, textos alternativos en las imágenes, que se pueda navegar con el teclado, formularios con sus etiquetas y que no haya barreras evidentes.

Para ese primer barrido tienes el analizador de accesibilidad web de mis herramientas, que revisa la web según las pautas WCAG y te dice qué falla.

Eso sí, ninguna herramienta automática detecta más que una parte de los problemas de accesibilidad, así que lo que salga limpio ahí todavía necesita una revisión a mano, igual que pasa con cualquier análisis automático frente a una auditoría manual.

Y una última de tienda, fundamental si ofreces rebajas, descuentos, ofertas o como lo llames. Me refiero a la directiva Omnibus, que obliga a mostrar el precio más bajo de los últimos 30 días junto al precio rebajado. El clásico «antes 50 €, ahora 30 €» sin ese dato incumple, y es sancionable.

Crítico

• Cookies y rastreadores cargando antes del consentimiento: el hallazgo RGPD más frecuente y el más fácil de demostrar por cualquiera que reclame.
• Sin textos legales, o textos de otra web con nombres de empresa ajenos aún dentro.
• Formularios que recogen datos personales sin información ni aceptación alguna.

Importante

• Banner sin opción de rechazo al mismo nivel que la aceptación.
• Fuentes de Google y recursos de terceros cargando en remoto sin consentimiento.
• Consent Mode v2 ausente usando Google Analytics o Ads con público europeo.
• Nadie sabe qué encargados del tratamiento hay (hosting, CDN, email marketing) ni dónde se firmaron los contratos de encargo.
• Formularios, registro o pago sin prueba del consentimiento: la casilla marcada, pero sin el registro con fecha, IP, texto y versión que exige el artículo 7.1 para poder demostrarlo.
• Tienda sin mecanismo de desistimiento accesible, o sin las exclusiones del artículo 16 marcadas, con la obligación de la Directiva 2023/2673 ya en vigor.
• Barreras de accesibilidad que incumplen la Ley Europea de Accesibilidad: contraste insuficiente, imágenes sin texto alternativo, navegación imposible con teclado o formularios sin etiquetas.

Menor

• Política de cookies desactualizada respecto a las cookies que la web pone en realidad: toca inventario y puesta al día.
• Solicitudes de permisos del navegador (geolocalización, notificaciones) disparadas nada más cargar la página: además de molestas, difíciles de justificar.
• Rebajas sin mostrar el precio más bajo de los últimos 30 días que exige la directiva Omnibus.

Tienda online

Si no hay tienda salta este bloque, y si la hay redobla la atención, porque aquí ya no auditas una web, auditas una caja registradora, y cada fallo tiene un coste que se mide en pedidos perdidos, no en puntuaciones de herramienta.

La primera revisión es el estado de WooCommerce Estado (WooCommerce → Estado), que por sí solo te dice la versión y base de datos de WooCommerce, plantillas sobreescritas obsoletas (lo vimos a fondo en la guía de temas) y el estado de HPOS, el almacenamiento de pedidos en tablas propias que ya es el modo por defecto en instalaciones nuevas.

Si la tienda sigue en modo antiguo, o peor, en modo compatibilidad con sincronización eterna, hay que averiguar qué plugin lo está impidiendo y valorar la migración con calma y en staging.

La segunda revisión obligatoria es hacer una compra, de verdad, del principio al final, probando el modo sandbox de la pasarela o producto de prueba de un céntimo, pero completa.

Esta es la única forma de saber si el checkout funciona, si hay errores de JavaScript en consola a mitad de proceso, si los impuestos cuadran y, atención a esta, si los correos del pedido llegan al cliente y a la tienda, que enlaza con el SPF y el SMTP que auditaste en el bloque de servidor.

Y ya que estás dentro del proceso, comprueba también si hay mecanismo de desistimiento como vimos antes en el bloque de legalidad, porque es aquí, con la compra hecha, donde se ve de verdad si el cliente puede ejercer su derecho con la misma facilidad con la que ha pagado.

Aprovecha para revisar las pasarelas de pago, con las claves de producción donde haga falta y que no haya ningún modo de pruebas olvidado desde el lanzamiento, que haberlos haylos.

Y la tercera es el programador de acciones (la cola de tareas internas de WooCommerce), que se revisa en WooCommerce → Estado → Acciones programadas. Te puedes encontrar con decenas de miles de acciones fallidas o pendientes acumuladas, que pueden ser síntoma de algo roto por debajo, pero siempre son lastre para la base de datos. Si se desmadra (que lo hará) ten siempre a mano el plugin para limpiar las acciones programadas innecesarias.

Crítico

• Pasarela en modo de pruebas en producción, o claves de test y producción mezcladas: pedidos que parecen cobrados y no lo están.
• Correos transaccionales que no llegan: pedidos a ciegas para el cliente y para la tienda.
• Pago con errores de JavaScript o pasos rotos en móvil: dinero saliéndose por el desagüe cada día que pasa.
• Plugins clave de la tienda incompatibles con HPOS consultando pedidos a la antigua: roturas silenciosas ya o en la próxima actualización.

Importante

• Plantillas de WooCommerce sobreescritas varias versiones por detrás.
• Programador de acciones con miles de tareas fallidas o pendientes sin explicación.
• Impuestos mal configurados o precios sin coherencia entre ficha, carrito y checkout.
• Webhooks de integraciones (ERP, email marketing, envíos) fallando en silencio.

Menor

• Checkout con campos innecesarios y distracciones: mejora de conversión a proponer, no urgencia técnica.
• Pedidos de prueba y datos de desarrollo aún en la base de datos de producción.

Para terminar, repasa la sección anterior sobre legalidad, porque en tiendas la cosa está cargadita, y las sanciones son tremendas.

Multisitio: auditar una red no es auditar una web

Si el sitio es una instalación normal sáltate este bloque. Y si es una red multisitio, prepárate, porque una red no es un área más que auditar, es un modo que cambia cómo auditas todo lo anterior.

Aquí varios sitios comparten una sola instalación de WordPress, la misma base de datos, los mismos archivos de plugins y temas y, muchas veces los mismos usuarios, así que un fallo en un rincón puede llevarse la red entera por delante.

Lo primero es tener claro qué está compartido, porque ahí viven casi todos los riesgos.

El código es común, o sea que una vulnerabilidad en un plugin o un tema no afecta a un sitio, afecta a todos a la vez. Los usuarios también son comunes, porque la tabla wp_users es única para toda la red, y una inyección SQL en el sitio más tonto puede exponer los usuarios y las contraseñas de todos, superadministradores incluidos.

Las subidas van a una carpeta compartida, /wp-content/uploads/sites/ID/, donde un archivo malicioso colado en un sitio vive pared con pared con el resto. El caso de manual que se repite es justo ese, un PHP colado en uploads, la tabla de usuarios volcada, una contraseña débil de superadmin reventada y puerta trasera en toda la red en una tarde.

Por encima de todo está el superadministrador, que en una red es el modo dios, pues crea y borra sitios, instala plugins y temas para todos y gestiona a cualquier usuario.

Así que la primera pregunta de la auditoría es cuántos superadmins hay (lo razonable son tres o menos), si alguno es en realidad un cliente que no debería serlo, si todos tienen 2FA y si sigue en el proyecto la gente que aparece en esa lista.

Sin tocar código, casi todo esto lo tienes en el escritorio de red, en Mis sitios → Administrar red. Ahí está la lista de sitios con su estado, los usuarios de toda la red, los plugins y temas disponibles y la pantalla de actualizaciones.

Con eso auditas la red sin abrir una consola. Con WP-CLI, wp site list te saca todos los sitios con su ID y su URL, wp user list --network los usuarios, y para actuar sobre un sitio concreto le añades --url= a cualquier comando. Tras actualizar el núcleo, no olvides wp core update-db --network, que pone al día la base de datos de todos los sitios de golpe.

Dos cosas más que la red cambia respecto a un sitio suelto. Una es que una actualización toca todos los sitios a la vez, así que el staging deja de ser recomendable y pasa a ser obligatorio, porque una incompatibilidad no rompe un sitio, rompe la red.

La otra es que los recursos del servidor son compartidos, de modo que un pico de tráfico o un plugin desbocado en un solo sitio degrada a todos los demás, que es justo lo del bloque de picos de tráfico pero multiplicado.

En lo relativo a la seguridad en redes multisitio la regla de oro es activar en red solo lo imprescindible, porque cada plugin activado en red se ejecuta en todos los sitios en cada carga, y lo demás actívalo sitio a sitio.

Lo que pongas de seguridad, o sea cortafuegos, bloqueo de ejecución de PHP en uploads, escaneo de integridad y registro de actividad, compruébalo antes en un plugin que sea compatible con multisitio, que muchos no lo son.

Vigilante, por ejemplo, funciona en red, aunque con ajustes independientes por sitio y sin un panel único que lo gobierne todo de golpe, así que aseguras cada sitio pero lo configuras uno a uno. Hay modos de hacerlo desde un panel único pero mi consejo es que mientras sea manejable gestiones la seguridad sitio a sitio.

Crítico

• Superadmins de más, alguno que es un cliente, o cuentas de superadmin activas de gente que ya no está: en una red, cada una es la llave maestra de todo.
• Ejecución de PHP habilitada en la carpeta de subidas compartida: la vía más habitual para plantar una puerta trasera que afecta a toda la red desde un solo sitio.
• Un plugin o un tema con vulnerabilidad conocida activo en la red: no es un sitio en riesgo, son todos a la vez.

Importante

• Plugins activados en red que solo usa un sitio: peso y superficie de ataque en todos los demás sin ningún motivo.
• Prefijo de tablas wp_ por defecto y un único usuario de base de datos con permisos de sobra: facilita el salto de un sitio comprometido al resto.
• Sin registro de actividad en los sitios de la red: aunque casi ningún plugin ofrezca todavía un panel único para toda la red, cada sitio debería al menos registrar su actividad para saber qué pasó y quién lo hizo.
• Actualizaciones de red aplicadas sin staging previo.

Menor

• Sitios de la red archivados, marcados como spam o de prueba que nadie ha limpiado: ruido que conviene revisar y retirar.
• Copias de seguridad por sitio en lugar de una copia de toda la red: en multisitio se respalda la instalación completa, no las tablas de un sitio suelto.

El informe

Una auditoría que termina en una lista de 200 problemas (o más) sin orden ni contexto no sirve para nada, o peor, sirve para asustar al cliente y que no contrate ninguna solución.

El valor de una auditoría web no está en encontrar fallos sino en convertirlos en un plan que alguien pueda aprobar, y para eso el informe necesita tres cosas: prioridades, evidencias y separación clara entre lo urgente y lo deseable.

Las prioridades ya las traes hechas, porque los tres niveles de cada bloque trasladan directos al plan de trabajo:

• Lo crítico se corrige antes de cualquier otra cosa (y si asumes el mantenimiento, antes de considerar la web «bajo tu responsabilidad»)
• Lo importante se planifica en la próxima actuación o antes de la siguiente versión mayor de WordPress o PHP
• Lo menor se documenta para resolverlo cuando se pase por ese código o esa configuración por otra razón.

Deja evidencia de todo, con capturas de cada hallazgo (en lo posible), su dato o su URL. No por desconfianza, sino porque dentro de seis meses nadie recordará por qué se decidió algo, y el informe es la memoria del proyecto.

Este esquema, por cierto, no me lo he inventado para el artículo, es el mismo que uso en los informes iniciales cuando asumo el mantenimiento de una web, con la situación previa área por área y las soluciones en dos listas separadas, las inmediatas que se aplican de oficio (copia de seguridad, monitorización, actualizaciones seguras) y las propuestas que requieren aprobación o presupuesto.

Y una recomendación de cierre para el documento es que escribas la parte de conclusiones en el idioma del cliente, no en el tuyo. «El autoload de wp_options pesa 9 MB» no significa nada para quien firma las facturas, pero «tu web carga en cada visita varios megas de imágenes, y tus clientes pueden abandonar la web si tarda más de 3 segundos» sí.

Herramientas gratuitas

Las herramientas de diagnóstico que han ido apareciendo por el artículo, y más, las tienes en herramientas.ayudawp.com: el análisis de seguridad externo, el analizador de visibilidad IA, el de límites de rastreo, el analizador de accesibilidad web y la auditoría de temas para documentar hallazgos e imprimir el informe.

Allí tienes también unos cuantos generadores que te vendrán genial cuando toque corregir lo encontrado, como el de cabeceras de seguridad, el de wp-config.php, el de .htaccess, el de robots.txt o el de security.txt, además del optimizador de imágenes, pero eso ya es otra fase y otro artículo. Son gratuitas, en español, sin registro y funcionando en tu navegador.

Además, luego tienes plugins que considero imprescindibles, y te resumo:

• Seguridad: Vigilante o All in one security
• SEO: Visibility o The SEO Framework
• Visibilidad IA: VigIA, AI Share & Summarize, AI Content Signals, Visibility
• Rendimiento y velocidad de carga: DietPress, Query Monitor, WP Crontrol
• Tienda online: Easy Action Scheduler Cleaner
• RGPD / Legal: EU Withdrawal Compliance, Terms & Conditions Consent Log, un buen plugin de gestión de cookies

Prompts de IA útiles en auditorías

La IA no sustituye las comprobaciones en tiempo real ni las herramientas especializadas, pero traduce y prioriza a una velocidad que compensa usarla en cada auditoría.

Para traducir la salud del sitio (pega el texto del informe que genera WordPress en «Herramientas → Salud del sitio → Información», botón de copiar al portapapeles):

Este es el informe de Salud del sitio de un WordPress. Explícame en términos simples qué problemas hay, cuáles son graves y en qué orden los resolverías. No asumas que sé de servidores.

Para las cabeceras de seguridad (pega la respuesta de curl -I https://laweb.com o las cabeceras que muestra cualquier herramienta externa):

Estas son las cabeceras HTTP de una web WordPress. Dime qué cabeceras de seguridad faltan, cuáles están mal configuradas y qué riesgo real supone cada ausencia. Ordena por importancia.

Para el borrador del informe al cliente (pega tu lista de hallazgos técnicos):

Estos son los hallazgos técnicos de una auditoría WordPress clasificados en Crítico, Importante y Menor. Redacta un resumen ejecutivo de una página para un cliente sin conocimientos técnicos: qué pasa, qué riesgo tiene y qué propongo hacer, sin tecnicismos y sin dramatismo.

Para profundizar aún más pasa Claude Code sobre la carpeta wp-content con una instrucción inicial que le pida clasificar hallazgos por gravedad te da un primer mapa priorizado del código en minutos. Con la misma limitación de siempre, que conviene no olvidar, y es que la IA analiza código estático, no ejecución, así que Query Monitor, los logs y las compras de prueba siguen siendo insustituibles.

¿Cada cuánto repetir todo esto?

La auditoría es una foto, y las webs se mueven. La cadencia que a mí me funciona con las webs que mantengo:

• Completa: al asumir una web nueva, siempre, y después una vez al año, porque lo que era Menor el año pasado puede haberse convertido en Crítico si el ecosistema avanzó y la web no.
• Seguridad: revisión mensual apoyada en alertas automáticas de vulnerabilidades para los plugins instalados, con Vigilante avisando de cambios en archivos entre revisión y revisión.
• Rendimiento: tras cualquier cambio grande (tema nuevo, migración, campaña con tráfico fuerte) y un vistazo trimestral a los datos de campo.
• Con cada versión mayor de WordPress o PHP: repaso de compatibilidad en staging antes de actualizar producción.

Y si todo esto te parece sensato pero no tienes cuándo hacerlo, te viene grande o prefieres derivar responsabilidades, para eso existe mi servicio de mantenimiento web, donde la auditoría inicial, las revisiones y el informe mensual van de serie, es literalmente lo que hacemos cada día.

Si haces tu primera auditoría con esta guía me encantará saber cómo te ha ido, qué te has encontrado y qué echas en falta, y si auditas webs a menudo seguro que tienes revisiones propias que aquí no están, para todo eso, incluso para debatir, me tienes ahí abajo, en la sección de comentarios.

La próxima web que te llegue sin documentación ya no te va a pillar a ciegas, pero sobre todo tendrás una lista de por dónde empezar, por lo menos.

Vamos a verlo, porque tiene más miga de la que parece.

Para empezar ¿qué es eso del unfiltered_html y qué hace?

WordPress filtra el HTML que guardas en las entradas con una función llamada wp_kses, que viene a ser el segurata que decide qué tags pasan y cuáles no, y por eso un suscriptor o un colaborador no puede colarte un <script> ni un <iframe> raro. Hasta ahí bien.

El problema es quién se puede saltar esa medida de seguridad. En una instalación normal, de un solo sitio, los administradores y los editores tienen la capacidad unfiltered_html, que les deja escribir el HTML que les dé la gana, sin filtrar ninguno. Lo que teclean va directo a la base de datos tal cual, scripts incluidos.

Si tienes una red multisitio con WordPress la cosa cambia, porque ahí solo los superadministradores la tienen, ni siquiera los administradores de cada subsitio. Así que este truco va sobre todo para las webs de un solo sitio, que son la mayoría.

¿Que esto es teórico? Ni de lejos. Ya conté en su día una vulnerabilidad en Divi, Extra y Divi Builder por la que usuarios de perfil bajo, como un simple autor, podían usar HTML sin filtrar en el contenido cuando editaban con el maquetador, justo lo que se supone que solo pueden hacer los administradores, lo que sería un escalado de privilegios de manual.

Por qué es un problema de seguridad, y no de confianza

El riesgo no es que tu editor sea mala gente, es que alguien se haga con su cuenta. Una contraseña reutilizada que aparece en una filtración, un phishing bien montado o un plugin comprometido que escala permisos, y de repente alguien tiene entre manos una cuenta con unfiltered_html.

Con esa cuenta no necesita romper nada, le basta con editar una entrada, pegar un <script> que robe cookies de sesión o redirija a los visitantes, guardar y a correr. Es XSS almacenado, del que se queda en tu base de datos y se ejecuta en el navegador de cada persona que abre esa página, tú incluido cuando entras al escritorio.

Mira qué fácil es impedir el unfiltered_html

La parte buena de todo esto es que el problema, que lo puede ser, se arregla simplemente definiendo una constante en el wp-config.php. Ábrelo por FTP o desde el gestor de archivos de tu hosting y añade esta línea antes de la que dice /* That's all, stop editing! Happy publishing. */:

define( 'DISALLOW_UNFILTERED_HTML', true );

Y ya está. A partir de ahí WordPress le quita la capacidad a todo el mundo, administradores y superadministradores incluidos, y todo lo que se guarde pasa por el filtro wp_kses como si lo escribiera un colaborador cualquiera. Ya no puedes meter una etiqueta <script>.

Para comprobar que funciona entra como administrador, mete un bloque de HTML personalizado con un <script>alert(1)</script> dentro, guarda y recarga. Si la constante está bien puesta, el script habrá desaparecido solo.

¿Se rompe algo si quito el unfiltered_html?

Esto no es gratis del todo,porque al capar el HTML sin filtrar WordPress también va a vaciar cosas seguramente normales que metas a mano como código, como un <iframe> de un mapa pegado en un bloque de HTML personalizado, un incrustado manual, un script de seguimiento que colabas en una entrada concreta, o ciertos atributos que wp_kses no admite por defecto.

Y luego hay otro efecto colateral, y es que desaparece también la opción de CSS adicional del personalizador. WordPress usa la capacidad edit_css para ese cuadro donde escribes CSS, y esa capacidad está enganchada por dentro a unfiltered_html, así que al desactivar una te llevas la otra por delante.

Lo mismo pasa con el CSS personalizado del editor de sitio en los temas de bloques. Si metes tus estilos por ahí tenlo claro antes de activar la constante.

Entonces, ¿cuándo la activo?

• Sí, sin pensarlo, si tienes varios redactores, editores o autores, o si mantienes webs de clientes donde no controlas quién toca qué. El riesgo de una cuenta comprometida pesa mucho más que la comodidad de pegar un iframe de vez en cuando.
• Con cuidado, o mejor no, si eres el único que edita, metes HTML crudo por el editor a menudo o dependes del CSS adicional del personalizador. En ese caso tienes salidas más finas.

Sí, hay otras maneras de protegerte sin hacerlo a la brava, para este segundo caso. Una es que en vez de capárselo a todos con la constante, quites la capacidad solo a los perfiles que no la necesitan, como editores y autores, con un filtro sobre map_meta_cap, y dejársela a los administradores. Solo tendrías que añadir un código como este:

/* Filtrar el HTML sin filtrar solo a los que no son administradores */
add_filter( 'map_meta_cap', 'ayudawp_limitar_unfiltered_html', 10, 3 );
 
function ayudawp_limitar_unfiltered_html( $caps, $cap, $user_id ) {
 
	// Solo actuamos sobre la capacidad de HTML sin filtrar
	if ( 'unfiltered_html' === $cap ) {
 
		// Leemos los datos del usuario directamente para no provocar
		// una llamada recursiva a este mismo filtro, como pasaría con user_can()
		$user = get_userdata( $user_id );
 
		// Si no es administrador (no tiene manage_options), se la denegamos
		if ( ! $user || empty( $user->allcaps['manage_options'] ) ) {
			$caps = array( 'do_not_allow' );
		}
	}
 
	return $caps;
}

Con esto los administradores siguen metiendo el HTML que quieran y a los editores se les filtra igual que a un colaborador, sin tocar el wp-config.php ni llevarte por delante el CSS adicional del personalizador. Y si lo que buscas es que tus redactores no puedan ni acercarse al HTML a mano, tienes el otro camino, desactivar el editor de código del editor de bloques. Depende de cómo trabajéis.

No te relajes que eso no es todo, aun te pueden colar código

La constante cierra la puerta del editor, que es la más grande, pero no es la única. Un plugin con una vulnerabilidad de XSS, un comentario mal filtrado o un formulario pueden colar un script por otro lado, y ahí esta línea no llega.

Para eso está la cabecera Content-Security-Policy (CSP), que es la que de verdad frena que un script se ejecute aunque haya conseguido meterse en tu base de datos.

Si tu política solo permite ejecutar JavaScript de tu propio dominio, el <script> del atacante que apunta fuera se queda mirando. Es la defensa con más rentabilidad contra el XSS, como ya expliqué en la guía de protección contra XSS.

Cabeceras CSP las gestionan muchos plugins de seguridad, pero el más completo en este sentido es Vigilante, que incluye incluso un comprobador de cabeceras. La idea es tener las dos capas trabajando juntas, la constante para que el script no entre por el editor y la CSP para que no se ejecute si entra por otro sitio.

¿En qué quedamos, impido el unfiltered_html o no?

Si en tu web publica más gente que tú, o llevas webs de clientes, la respuesta corta es sí. añade la línea al wp-config.php y te quitas de encima uno de los vectores de XSS más tontos y más habituales que hay. Pero administras y alimentas la web solo tú y usas el CSS adicional del personalizador o pegas iframes a mano, valora antes la alternativa de capárselo solo a ciertos perfiles.

Tienes más contexto en la lista completa de constantes de WordPress por si quieres seguir apretando tuercas en el wp-config.php, y en la guía de XSS para montar la parte de la CSP como es debido.

¿Tú la tenías capada o acabas de descubrir que tus editores podían hacer esto? Me lo cuentas ahí abajo, en los comentarios … o no.

El lunes tocaron unas Crónicas WordPress cargadas hasta arriba de noticias, con la IA comiéndose el tráfico de Google como tema estrella. Y el miércoles vino un Doctor WordPress dedicado a algo que me preguntáis un montón, cómo hacer que te vean los buscadores y las IAs sin pagar un duro, tirando de lo que ya trae WordPress de serie. Te cuento.

Crónicas WordPress: la semana en que la IA se comió el tráfico (y Elementor le echó la culpa)

Abrí pidiendo disculpas, todo hay que decirlo, porque el miércoles anterior me salté el Doctor WordPress. ¿La razón? Pues el verano, que me fui a dar un baño y cuando quise darme cuenta eran las ocho y media y se me había pasado la hora. Cosas que pasan. Aclarado esto, vamos a la ronda de titulares, que hubo tela.

Seguridad

En el frente de siempre, semana movidita:

• Wordfence cerró la semana con casi 200 vulnerabilidades nuevas, para que te hagas una idea del ritmo al que va esto.
• El fallo crítico de UpdraftPlus (CVE-2026-10795) se sigue explotando en 3 millones de webs, y menos mal que los hostings buenos ya están parcheando y avisando.
• Y una que me encantó, la de un desarrollador que tumbó un ataque de spam de registro con un filtro hecho con ayuda de Claude y Codex. El spam de registro es de lo más pesado que hay, así que ver a alguien resolverlo con IA y buen criterio me alegró el lunes.

Comunidad

La bomba de la semana fue Elementor, que ha echado al 30 % de su plantilla y le echa la culpa a la IA. A ver, la IA será lo que quieras, pero la decisión de despedir la toman ellos, no ChatGPT. Echarle la culpa a la máquina queda muy moderno, pero es su decisión y su responsabilidad.

Más cosas de comunidad que comenté:

• Marina Broca, que sabe un rato de la parte legal y es buena amiga, publicó en el blog de WordPress.com un artículo estupendo sobre el botón de desistimiento para tiendas, esa directiva europea que ya está en vigor. Y mira tú por dónde, ahí recomiendan mi plugin gratuito para cumplir con ello, cosa que me hizo ilusión.
• Salió el informe «State of WordPress Agencies 2026», sobre cómo trabajan de verdad las agencias, muy enfocado al mercado anglosajón pero con lecturas interesantes.
• Y el informe sobre el estado de los temas, que deja una brecha curiosa, los desarrolladores se han pasado a los bloques y los usuarios ni de lejos.
• WPBakery sacó su versión 9.0 en beta, por si todavía tiras de él.
• Y hablé de Dismissed, ese muro de la vergüenza de los avisos que los plugins te clavan en el escritorio.

IA, SEO y el tema gordo del tráfico

Aquí es donde la cosa se pone interesante de verdad. Un estudio ha desmontado el discurso de Google sobre las AI Overviews, hablamos de un 39,8 % menos de clics, y encima los que se pierden no eran de peor calidad, como quería vender Google. Te lo resumo en que esas respuestas de IA ya saltan en más del 40 % de las búsquedas, y eso se traduce en una pérdida de tráfico brutal, no solo informacional, también transaccional, gente que compraría y que ya no llega nunca a tu web.

¿Quieres una pista de lo gordo que es esto? Fíjate en la de anuncios de empresas financieras online que ves últimamente. Están compensando con publicidad la caída enorme de tráfico orgánico. Para que luego digan que la IA no le cambia el negocio a nadie.

Otras de IA y buscadores que toqué:

• El modo Thinking de ChatGPT cita marcas distintas según cómo lo uses, lo que me sirve para repetir una de mis manías, no pagues por nada que mida tus menciones en las IAs, porque son de lo más aleatorio, hasta el mismo modelo te recomienda cosas distintas de una vez a otra.
• Cloudflare ya te deja bloquear a los bots de IA, aunque ojo con no cerrarle la puerta de paso a Googlebot.
• Lo enlacé con la pregunta del millón, ¿bloqueo los crawlers de IA o mido primero su valor? Que tiene más miga de la que parece, y de ahí sale medio Doctor de esta semana.
• Y hablé de los nuevos estándares ARD y OKF, y de si de verdad tienes que implementarlos ya en tu WordPress (con calma, que no cunda el pánico).

Tienes todos los titulares con sus enlaces en la descripción del vídeo, que los dejo siempre ordenaditos.

Aquí tienes las Crónicas WordPress completas: Nuevos estándares IA: ARD, OKF, valor de las menciones de IA y bajada tremenda de tráfico desde Google.

Doctor WordPress: SEO, AEO, GEO y cómo ser visible en las IAs gratis con WordPress

Este fue el último Doctor antes del verano, y lo dediqué a lo que os había prometido, cómo posicionar hoy, cuando ya no vale solo con salir en Google. Ahora hay que aparecer también en las IAs, que más que buscadores son respondedores, te sueltan la respuesta y listo. De ahí lo del SEO de siempre más el AEO y el GEO, las siglas de moda para una misma idea, que te encuentren y te citen.

La buena noticia, y el motivo del directo, es que puedes hacer muchísimo gratis con lo que WordPress ya trae de serie, sin pagar por un plugin de SEO monstruoso:

• WordPress genera su propio mapa del sitio en wp-sitemap.xml. Los plugins de SEO no inventan nada nuevo, solo le cambian la ruta, cada uno la suya.
• La etiqueta de título sale del propio título del documento, que controlas desde los ajustes generales y desde cada contenido.
• Y las metaetiquetas y los datos estructurados también los puedes gestionar sin cargarte la web de código que no necesitas.

Para enseñarlo tiré de un plugin mío, Visibility (más info en visibility.quest), que forma parte de esa familia de plugins gratuitos que voy soltando, como el Vigilante. ¿Que por qué me meto en el jardín de hacer un plugin de SEO? Pues justo por esto, porque está montado sobre las funciones que ya existen en WordPress (el manejo de robots, los sitemaps, los metadatos, los canonical nativos) en lugar de duplicarlas como hacen otros. Menos grasa y más músculo.

Y una perla práctica que engancha con lo de Cloudflare de las Crónicas: no bloquees a lo loco a todos los bots de IA. A los de entrenamiento sí les puedes cerrar la puerta, que consumen recursos a lo bestia y no te devuelven nada. Pero a los de asistente y búsqueda ni se te ocurra, porque son justo los que te citan y te enlazan en tiempo real, y esos sí te traen visitas. Saber distinguir unos de otros es media batalla.

El resto del directo fue lo de siempre en el Doctor, vuestras preguntas de WordPress, SEO, IA y de casi cualquier cosa, que para eso está la consulta abierta.

Aquí tienes el Doctor WordPress completo: SEO, AEO, GEO y Visibilidad en IAs gratis en WordPress.

Nos vemos después del verano

Con estos dos directos me despido (de vídeos) hasta la vuelta, que toca desconectar unas semanas. Si te quedan ganas de WordPress para el verano, tienes las dos sesiones enteras ahí arriba para verlas con calma, y de paso puedes cacharrear con lo de la visibilidad gratis, que es buen plan para una tarde de estas sin prisa.

Y si te surge cualquier duda o te apetece debatir algo de lo que conté, me tienes en los comentarios. Buen verano, y a la vuelta más.

La respuesta corta es que no pintan gran cosa, pero no anticipemos tanto, que si no quieres seguir leyendo ya tenías los resúmenes con IA, aquí hemos venido a aprender ¿o no?

Qué son y por qué casi siempre sobran

WordPress crea de forma automática un archivo por cada año y cada mes en los que has publicado, un listado que agrupa las entradas por su fecha.

El problema es que la fecha no es un criterio por el que busque nadie, la gente busca por temas, no por «lo que publicaste en noviembre de 2025».

Así que esas páginas no le sirven de nada al visitante y, de paso, se llevan parte del rastreo que Google podría dedicar a tu contenido bueno.

A diferencia del archivo de autor, que tiene su miga porque ancla tu autoridad y ahí la decisión no es tan obvia, los archivos de fechas no aportan ninguna señal que te interese conservar. Fácil ¿verdad?

Qué hacer con los archivos por fecha de cara a SEO

Tienes dos opciones razonables, y las dos sirven:

• Desindexarlos con noindex, follow: La página desaparece de Google, pero este sigue los enlaces hacia tus entradas. Es lo mínimo y lo más seguro.
• Desactivarlos del todo: Que la URL de fecha ni exista. La mayoría de plugins permiten desactivarlos con un clic.

Y lo que no debes hacer, igual que con cualquier archivo, es ni bloquearlos por robots.txt (Google no leería el noindex y podría acabar indexando la URL igual) ni poner su URL canonical apuntando a la portada.

Pero eso ya lo sabías, porque eres un fiel lector y estás suscrito a la newsletter de Ayuda WordPress para no perderte nada ¿a que sí?

Cómo deshacer SEO con los archivos de fecha

Como siempre, para todos los gustos, con códigos y con plugins.

Por código

Si no quieres instalar nada, un mu-plugin en la carpeta /wp-content/mu-plugins/ con este contenido deja los archivos por fecha en noindex, follow:

<?php
/**
 * Plugin Name: Noindex para archivos por fechas
 * Description: Añade noindex, follow a los archivos de fechas.
 * Author: Fernando Tellado
 */

add_filter( 'wp_robots', 'ayudawp_noindex_date_archives' );

function ayudawp_noindex_date_archives( $robots ) {
	if ( is_date() ) {
		$robots['noindex'] = true;
		$robots['follow']  = true;
	}
	return $robots;
}

Funciona desde WordPress 5.7, que es cuando llegó el filtro wp_robots, que es el que usa el código.

Por ajustes y plugins

• Yoast SEO los desactiva del todo desde SEO > Apariencia en el buscador > Archivos.
• Rank Math y All in One SEO te dejan desindexarlos desde sus ajustes de apariencia en el buscador.
• Visibility te permite añadir el noindex, follow nativo, lo que hemos visto antes, con una casilla, a un clic, sin tablas en la base de datos ni código.

Lo que yo haría

Con los archivos por fecha no hay mucho que debatir, desindéxalos con noindex follow o desactívalos, da igual el tamaño de tu web.

Donde sí tienes que pararte a pensar es en el archivo de autor, que ahí entra en juego tu E-E-A-T y la cosa cambia.

¿Dudas? Te leo en los comentarios.

En mi artículo sobre precarga de recursos, prefetch y prerender significan una cosa, luego, en cuando escribí sobre carga especulativa nativa de WordPress, las mismas dos palabras significan otra completamente distinta y, para seguir enredando, luego está eso de la bfcache, que no precarga nada de nada, va al revés.

Son cuatro técnicas con nombres que se pisan, y cada una vive en su propia capa del navegador, con sus propias reglas, así que se me ha ocurrido que igual no está de más ponerlas en orden para que dejemos de mezclarlas.

Si lo que buscas es la otra caché, la que guarda resultados ya generados para no repetir trabajo (página, objetos, base de datos, OPcache, CDN), esa la tienes entera en la guía de tipos de caché en WordPress.  Hoy toca hablar de la familia de cachés que adelanta o conserva trabajo del navegador, no del servidor, que es un asunto distinto aunque también se llame caché en algún sitio.

Resource hints: precarga recurso a recurso

Esta es la que lleva más tiempo en el navegador y la que seguramente ya conoces, aunque no la llames así. Son cuatro etiquetas <link> distintas, cada una con un trabajo muy concreto sobre un recurso suelto, nunca sobre una página entera.

• dns-prefetch: resuelve el nombre de dominio de un origen externo antes de que haga falta, así cuando llegue el recurso de verdad esa parte ya está hecha.
• preconnect: hace lo mismo que dns-prefetch y además abre la conexión TCP y negocia el TLS, así que cuando el recurso llega de verdad el navegador no tiene que esperar nada de eso.
• prefetch: descarga un recurso suelto entero, un documento o un recurso cualquiera, con prioridad baja, para tenerlo ya en caché cuando se necesite.
• preload: igual que prefetch pero con prioridad alta y de obligado cumplimiento, el navegador no puede ignorarlo. Se usa para lo que sabes seguro que vas a necesitar ya, como la fuente del título o la imagen del LCP.

Los cuatro se controlan recurso a recurso, dominio a dominio, decisión que tomas tú o que automatizas con plugins como DietPress, a golpe de clic, sin que escribas una sola línea de código.

WordPress trae de serie el filtro wp_resource_hints desde la versión 4.6 para añadir dns-prefetch y preconnect sin tocar el <head> a mano, aunque mucha gente, este blog incluido en su día, sigue escribiendo el echo directo en wp_head en vez de usarlo.

Si quieres un tutorial con el código y las herramientas para aplicarlo en la guía de prefetch, preload, preconnect y prerender en WordPress.

Un apunte para no liar (aún más) el tema es lo relativo al atributo fetchpriority, que suena de la misma familia, y a veces se mete en el mismo saco, pero hace algo distinto. No anticipa nada que el navegador no fuese a pedir igualmente, solo le dice con qué prioridad pedirlo, no es un resource hint en sentido estricto, es una instrucción de orden. Si quieres ampliar información puedes ver la guía de fetchpriority.

El prerender de siempre ya no hace nada

De las etiquetas de arriba hay una que solía acompañarlas, <link rel="prerender">, y que merece su propio apartado porque hoy no sirve absolutamente para nada. Chrome la abandonó hace años, sustituida por la tecnología de la siguiente sección, y cualquier navegador actual la ignora sin más.

No pasa nada por tenerlo, simplemente no aporta nada.

Speculation Rules: prefetch y prerender nativos de WordPress

Desde WordPress 6.8, trae de serie la carga especulativa, creada sobre la Speculation Rules API del navegador. Y aquí empieza el lío, porque esta tecnología también tiene su propio prefetch y su propio prerender, con los mismos nombres que los de la primera sección, pero que no funcionan igual ni a la misma escala.

Un resource hint clásico es como pedir que te dejen ya el cubierto puesto en la mesa. Speculation Rules es como si la cocina empezara a prepararte el plato entero en cuanto te ve mirar el menú, antes de que hayas pedido nada, o sea, precarga la página completa, con su HTML, su CSS y su JavaScript, no un recurso suelto.

Se declara en JSON dentro de un <script type="speculationrules">, es automático, y WordPress lo activa de serie solo para visitantes que no están conectados y solo si usas enlaces permanentes bonitos. Hay tres niveles de anticipación, la conservadora espera al clic, la moderada se dispara al pasar el cursor y la ansiosa salta con solo acercarte.

La compatibilidad con navegadores es la otra pieza importante para decidir si te conviene. Funciona en Chrome, Edge y el resto de navegadores con motor Chromium, que es la inmensa mayoría del tráfico mundial, Safari la incluye desde la versión 26.2 pero la trae desactivada por defecto, como función experimental, y Firefox de momento no la ha implementado, aunque sí se ha posicionado a favor de la parte de prefetch para más adelante.

Puedes excluir URLs concretas con el filtro plsr_speculation_rules_href_exclude_paths, o apagarla entera con wp_speculation_rules_configuration. Tienes el desarrollo completo, con el código y los pros y contras, en qué es y cómo funciona la carga especulativa nativa y en si te conviene desactivarla.

bfcache: la única caché que no anticipa nada, conserva lo que ya tenías

Las tres técnicas anteriores miran hacia delante, adivinan qué vas a necesitar y se adelantan. Sin embargo bfcache (back/forward cache) hace justo lo contrario y mira hacia atrás. Cuando sales de una página el navegador la congela en memoria tal cual estaba, y si pulsas atrás te la devuelve al instante en lugar de pedirla otra vez al servidor.

Es una optimización nativa de los navegadores desde hace años, no necesita ningún código tuyo para existir, pero WordPress la bloquea por su cuenta para usuarios conectados al enviar la directiva no-store en la cabecera de respuesta. Quitar esa directiva con el filtro wp_headers, o con el plugin Instant Back/Forward, es lo que la reactiva.

No tiene relación de competencia con ninguna de las tres anteriores, todo lo contrario, se complementan, porque bfcache acelera las páginas que ya visitaste, Speculation Rules acelera las que aún no has visto.

Las cuatro juntas y ordenadas, por aclarar

Qué tienes activado ahora mismo en tu web

No hace falta que lo adivines, las herramientas de desarrollador de Chrome te lo dicen directamente:

• Resource hints clásicos: mira el código fuente de tu web y busca en el <head> etiquetas <link rel="dns-prefetch">, <link rel="preconnect"> o <link rel="preload">.
• Speculation Rules: abre DevTools, pestaña Application, apartado Speculative loads, sección Speculations. Pasa el cursor por algún enlace de tu web y mira si aparece algo en la lista.
• bfcache: misma pestaña Application, apartado Background services, sección Back/forward cache, botón Run test. Te dice si la página entraría en bfcache o el motivo exacto por el que no.

Si en los tres casos sale en blanco, ya sabes a cuál de los artículos enlazados más arriba acudir para arreglarlo. Por dónde empezar depende de tu web. Si tienes un blog que actualiza poco, el bfcache es la ganancia más rápida y casi sin pegas, actívalo primero.

Si llevas una tienda con WooCommerce, revisa antes las exclusiones de Speculation Rules en el carrito y en finalizar compra, y prueba bien bfcache con un pedido real antes de darlo por bueno, que ahí sí hay estado que cuidar.

Si todavía no has tocado nada de esto, abre las DevTools del apartado anterior antes de instalar ningún plugin nuevo, para saber de qué punto partes. Y si después de mirarlo te queda alguna duda sobre cuál de las cuatro te conviene en tu caso, ya sabes dónde encontrarme, en los comentarios.

Hay tres posibles situaciones en las que se me ocurre que este artículo te va a resultar útil:

1. Has encargado que te desarrollen un tema a medida y quieres saber si lo que te han entregado es sólido antes de que llegue tráfico real.
2. Tu equipo asume el mantenimiento de una web que no conoce, y el tema a medida es ese territorio sin documentar donde se concentran los apaños, los atajos y los retoques de todo el que ha pasado por el proyecto antes que tú.
3. Te encargan mejorar, actualizar o rediseñar un tema existente, y antes de escribir una sola línea nueva necesitas saber sobre qué base estás trabajando.

En los tres casos la revisión es la misma, lo que cambia es el momento en que la haces y lo que puedes decidir con los resultados.

El artículo va en dos velocidades, de manera que si no te manejas con código cada bloque te indica qué puedes detectar con herramientas visuales y qué pedirle a una IA, y por otro lado, si eres el técnico del proyecto, encontrarás el análisis estático, los comandos y el nivel de detalle que completan el trabajo.

Pretende ser una guía para todo tipo de perfiles, aunque no te veas del todo en los propuestos, lo importante es que nadie se quede sin información útil, incluso si simplemente quieres leerlo para aprender o pillar ideas.

Entorno y herramientas

Antes de revisar una sola línea de código conviene tener preparado lo que vas a necesitar. No es mucho, pero todo imprescindible.

Si no te manejas con código

Lo primero es activar el modo depuración de WordPress. Abre el archivo wp-config.php de tu instalación de pruebas (nunca en producción) y añade estas tres líneas antes de la que dice «That’s all, stop editing!»:

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

Con esto WordPress empezará a registrar en un archivo debug.log cualquier función obsoleta, aviso de compatibilidad o error que aparezca al navegar por la web. Para leer ese archivo sin salir del administrador instala Debug Log Manager. Luego instala también el plugin oficial Health Check & Troubleshooting, que entre otras cosas te muestra la versión de PHP activa y el estado general de la instalación.

Con esas dos herramientas y una IA (Claude o cualquier otra) ya puedes revisar la mayor parte de lo que este artículo cubre.

Si eres el técnico del proyecto

La combinación que cubre la mayor parte del análisis estático son PHP CodeSniffer con los WordPress Coding Standards y el paquete PHPCompatibility. Con esa combinación puedes detectar problemas de compatibilidad PHP, funciones obsoletas y violaciones de los estándares de WordPress sin ejecutar el código, solo analizando los archivos.

Para análisis en tiempo real mientras navegas la instalación, Query Monitor es la referencia. Y WP-CLI para los comandos que se mencionan a lo largo del artículo.

Si quieres una auditoría asistida por IA de toda la carpeta del tema de una vez, Claude Code con la instrucción inicial sobre el directorio completo es la forma más rápida de tener un primer mapa de problemas priorizado.

Compatibilidad con PHP

Un tema con funciones eliminadas en PHP 8.x no da aviso: da error crítico. Es el tipo de problema que aparece el día que el hosting actualiza la versión de PHP, que es exactamente lo que van a hacer tarde o temprano.

Sin código, WP_DEBUG + Debug Log te avisa de las funciones obsoletas en cuanto navegas por la web con el tema activo. Health Check te muestra la versión de PHP que tienes y si el tema declara una versión mínima compatible.

Con código, PHP CodeSniffer + PHPCompatibility analiza el tema completo sin ejecutarlo, incluyendo archivos que quizás no se llaman en ninguna URL de prueba.

Para el nivel sin código también puedes pegar el contenido de functions.php en una IA con el prompt: «Eres revisor de código PHP. Identifica funciones PHP eliminadas o incompatibles con PHP 8.x en este código de tema WordPress. Para cada caso dime el nombre de función, el número de línea y la alternativa recomendada.»

Crítico

• Uso de funciones eliminadas en PHP 8.x: ereg(), ereg_replace(), mysql_*, create_function(), each(), split(). Si aparecen en el código, el tema puede dejar de funcionar en cualquier actualización de PHP.
• Operador @ usado de forma sistemática para suprimir errores: oculta fallos reales y puede romper el comportamiento en PHP 8 sin aviso ninguno.

Importante

• Comparaciones con == en contextos donde PHP 8 cambia el comportamiento (cadenas numéricas, comparaciones con null): el código parece funcionar pero produce resultados incorrectos en determinadas condiciones.
• Versión PHP mínima declarada en la cabecera del tema muy por debajo de la que el código realmente necesita. Si el tema dice Requires PHP: 5.6 pero usa sintaxis de PHP 7.4, la declaración es incorrecta y puede inducir a error al gestor del hosting.

Menor

• Sintaxis PHP 7.0-7.3 que funciona en 8.x pero no aprovecha las mejoras disponibles: planificable para la próxima iteración, no urgente.
• Ausencia de typed properties o tipado de parámetros: no es un error, es una omisión de buenas prácticas.

Nota importante para WordPress 7.x: el núcleo sube el mínimo a PHP 7.4. Cualquier tema que declare una versión inferior necesita actualizar esa cabecera y revisar el código si usaba sintaxis más antigua.

Funciones de WordPress obsoletas

Una función obsoleta no rompe hoy, pero romperá cuando WordPress decida eliminarla. Y eso pasa en cada versión mayor. La diferencia entre una función obsoleta y una eliminada es solo tiempo.

WP_DEBUG registra los avisos de obsolescencia en el log cada vez que el tema llama a una función que ya no debería usar. Con eso y el log ya tienes la lista. Para el perfil técnico, PHP CodeSniffer con WPCS detecta las funciones obsoletas sin necesidad de ejecutar el tema.

Crítico

• Funciones de WordPress eliminadas del todo (no solo obsoletas): si aparecen en el código, el tema puede dar un error crítico en la próxima actualización del núcleo.
• Modificaciones directas de archivos de wp-includes o wp-admin desde el tema: raro en proyectos modernos, pero ocurre en temas muy antiguos que «parchearon» algo del núcleo directamente.

Importante

• Funciones obsoletas con aviso pero que siguen funcionando: wp_title() (obsoleta desde WP 4.4), get_currentuserinfo(), the_attachment_link(). Funcionan hoy, pero hay que planificar la sustitución.
• Código que asume que el directorio wp-content está en su ruta por defecto usando rutas absolutas literales, en lugar de las constantes WP_CONTENT_DIR o WP_CONTENT_URL.
• Hooks que fueron renombrados pero los originales siguen como alias: el alias puede desaparecer en una versión mayor sin previo aviso adicional.

Menor

• Widgets registrados solo con la API clásica sin compatibilidad con el editor de bloques: funcional hoy, pero visible como deuda si el cliente trabaja con Gutenberg.
• Template files que no usan get_template_part() donde deberían, con código de plantilla duplicado en varios archivos.

Hay una señal que merece párrafo aparte porque no rompe nada hoy pero crea un problema real el día que el cliente quiera cambiar de tema: funcionalidades de plugin metidas dentro del tema. CPTs, shortcodes globales, taxonomías personalizadas dentro de functions.php. Si el cliente cambia de tema, desaparece su contenido. Es Importante a corto plazo y Crítico como estado permanente de un proyecto.

Seguridad del código

Este bloque tiene solapamiento con el artículo sobre temas WordPress con código malicioso. Lo que cubre aquel artículo es código ofuscado, backdoors y malware. Lo que cubre este bloque son los problemas de seguridad que un desarrollador descuidado introduce sin mala intención: variables sin escapar, SQL sin preparar, ausencia de nonces. Son igual de peligrosos y mucho más frecuentes.

PHP CodeSniffer con WPCS detecta automáticamente la mayor parte de los problemas de escapado y sanitización. Para el nivel sin código, el prompt de IA más útil para este bloque es: «Identifica en este código PHP de un tema WordPress variables impresas sin escapar, datos de usuario sin sanitizar y consultas SQL sin usar $wpdb->prepare(). Explica cada caso en términos simples.»

Crítico

• Variables de $_GET, $_POST o $_REQUEST impresas directamente en el HTML sin sanitizar ni escapar: XSS directo.
• $wpdb->query(), $wpdb->get_results() o cualquier otra función de base de datos con interpolación directa de variables sin $wpdb->prepare(): inyección SQL activa.
• Formularios que procesan datos sin verificar nonce con check_admin_referer() o check_ajax_referer().
• Acciones de administración o procesamiento de datos sin current_user_can(): cualquier usuario puede ejecutar esas acciones.
• Uso de eval(), base64_decode() aplicado a variables externas, system() o exec(): señal de alerta máxima. Saltar directamente al artículo de código malicioso para saber qué hacer.

Importante

• echo get_the_title() sin esc_html(): XSS potencial en contextos concretos, no siempre explotable de forma inmediata, pero hay que corregirlo.
• Llamadas a APIs de terceros que envían datos de usuarios sin opción de desactivar y sin mención en la política de privacidad.
• Ausencia de sanitización en campos del Customizer que no se imprimen directamente en el front: riesgo no inmediato, pero es deuda documentada.

Menor

• Fuentes de Google cargadas desde fonts.googleapis.com sin opción de desactivar: problema de cumplimiento del RGPD, no de seguridad activa, pero requiere solución.
• Nonces ausentes en formularios de solo lectura que no modifican datos: bajo riesgo real, pero incumple los estándares de WordPress.

Rendimiento

Los problemas de rendimiento de un tema a medida no siempre aparecen en el desarrollo. Aparecen cuando la web tiene contenido real, con cientos de entradas y miles de visitas. Un N+1 que pasa desapercibido en desarrollo puede tumbar un servidor con tráfico real.

Query Monitor es la herramienta para ambos perfiles: se instala como plugin, no necesita configuración y muestra en tiempo real las queries que ejecuta cada carga de página, cuánto tarda cada una y de dónde viene. Para el resultado agregado, PageSpeed Insights da la imagen completa del impacto en el usuario.

Crítico

• WP_Query o get_posts() dentro de un bucle de posts: el N+1 clásico. Si tienes 50 entradas en un listado y cada una dispara su propia query adicional, son 51 queries donde debería haber 1 o 2.
• wp_remote_get() o llamadas curl en cada carga de página sin ninguna caché con transients: cada visita hace una petición HTTP a un servicio externo que puede tardar segundos o estar caído.
• jQuery propio incluido en la carpeta del tema cargando en paralelo al de WordPress: doble carga y conflictos de versión garantizados.

Importante

• Scripts y estilos encolados en todas las páginas sin condición cuando solo hacen falta en plantillas concretas: un slider de JavaScript cargando en cada entrada del blog aunque el slider solo esté en la portada.
• WP_Query sin 'no_found_rows' => true en consultas que no paginarán nunca: WordPress hace un COUNT(*) adicional innecesario. Coste medible con tráfico real.
• Opciones guardadas en wp_options con autoload=yes cuando no hacen falta en cada carga de página: se suman al peso de la consulta de opciones que WordPress ejecuta en cada petición.
• CSS crítico no inline, haciendo que el navegador espere una hoja de estilos externa antes de renderizar nada visible.

Menor

• Scripts encolados en el header que podrían ir al pie con el quinto parámetro a true en wp_enqueue_script().
• Imágenes del tema sin loading="lazy" donde procede.

Malas prácticas y estándares heredados

Este bloque cubre los problemas que no rompen nada hoy pero que hacen el mantenimiento difícil y el comportamiento impredecible. Son los que aparecen cuando hay que cambiar el dominio, migrar el proyecto a un nuevo servidor o simplemente actualizar algo que estaba «atado con alambres».

Crítico

• Funciones sin prefijo o con prefijo genérico: get_menu(), init(), setup(). Si en algún momento se activa un plugin que declara una función con el mismo nombre, el conflicto es un error fatal.
• IDs de páginas o entradas hardcodeados en la lógica del tema: if ( $post->ID === 42 ). Ese ID 42 no existe en el servidor de desarrollo, ni en el staging, ni en el siguiente proyecto que use el mismo tema base.
• Slugs de categorías o taxonomías hardcodeados en condicionales: mismo problema exacto que los IDs.
• URLs absolutas hardcodeadas al dominio de producción o de desarrollo: si el dominio cambia, el tema queda roto en silencio. Buscar cualquier cadena con https:// o http:// dentro del código PHP y las plantillas.

Importante

• Rutas absolutas de servidor hardcodeadas como /var/www/html/wp-content/themes/... en lugar de get_template_directory() o get_stylesheet_directory().
• Colores, dimensiones o configuraciones hardcodeadas en JavaScript que deberían venir de variables CSS o de opciones del Customizer: cuando el cliente quiere cambiar el color corporativo, toca editar código.
• Archivos de desarrollo dentro de la carpeta del tema: node_modules, .git, archivos .log, copias .bak, .DS_Store. Ninguno de esos tiene que llegar a producción.
• die() o exit() donde debería usarse wp_die(): WordPress pierde el control de la ejecución y el usuario recibe un pantallazo en blanco sin contexto.

Menor

• Cadenas de texto no envueltas en funciones de traducción (__(), _e()): el tema no es internacionalizable, pero no rompe nada. Planificable si el proyecto va a necesitar varios idiomas.
• functions.php de varios miles de líneas sin estructura de includes ni documentación: no rompe nada, pero hace el mantenimiento muy difícil.
• Comentarios en el código en el idioma del desarrollador original cuando no es el del equipo que hereda el proyecto.
• Código comentado con funcionalidades a medias o parches rápidos sin explicación.

Dependencias y servidumbres

Un tema a medida acumula dependencias que no siempre son visibles en el código. Algunas son técnicas, otras son contractuales. El momento de descubrirlas no es cuando algo deja de funcionar, sino antes de comprometerte a mantener el proyecto.

Crítico

• Plugins bundled (empaquetados) dentro de la carpeta del tema sin los cuales el tema da error crítico: si ese plugin falla, se desactiva o deja de existir en WordPress.org, la web se cae. Los plugins son plugins, van en su carpeta, no dentro del tema.
• Código que llama a is_plugin_active() sin manejar el caso de que el plugin no esté activo: en el momento en que alguien desactiva ese plugin por lo que sea, el tema da un error fatal.
• Librerías JavaScript o CSS de terceros copiadas dentro del tema con versiones que tienen vulnerabilidades conocidas. Buscar en Patchstack o WPScan las versiones incluidas.

Importante

• Dependencia de un page builder integrado en el tema de forma que desinstalarlo afecta al contenido existente: es una decisión de arquitectura que hay que documentar y comunicar al cliente.
• APIs de terceros integradas sin fallback: si la API no responde, ¿la página da error o simplemente no muestra esa sección? Hay que saberlo antes de que le pase al usuario.

Menor

• Fuentes de Adobe Fonts, Typekit u otros servicios de pago integrados sin documentar la licencia activa ni quién la controla: funciona mientras la licencia esté vigente, pero hay que saber quién paga eso.
• Tema hijo de un tema padre comercial (Divi, Avada, Genesis): la dependencia de la licencia del padre hay que documentarla y saber quién la controla.

SEO y estructura semántica

Aquí es donde más destrozos se acumulan en temas a medida y donde menos gente mira. Un tema puede pasar todos los controles anteriores y seguir siendo un problema grave para el posicionamiento y para los lectores de pantalla. La estructura semántica incorrecta no da error ninguno, pero Google y los motores de búsqueda la leen y la valoran cada vez que rastrean la página.

Para el propietario sin código, las herramientas más útiles aquí son el inspector del navegador (clic derecho > Ver código fuente para el HTML completo) y la extensión Headings Map para Chrome o Firefox, que visualiza el árbol completo de encabezados de una página de un vistazo. Lighthouse en DevTools detecta imágenes sin alt y otros problemas de accesibilidad. Para el análisis semántico asistido por IA, pegar el código fuente HTML completo de la página con el prompt: «Analiza la estructura de encabezados de este HTML. Dime cuántos H1 hay, si hay saltos de jerarquía y si algún encabezado está en un lugar estructuralmente incorrecto.»

Crítico

• Múltiples etiquetas <h1> en la misma página: el logotipo, el nombre del sitio y el título de la entrada con el mismo nivel de importancia. Google espera un solo <h1> por página.
• <h1> ausente en páginas de contenido o colocado en elementos decorativos sin contenido relevante.
• El tema genera su propia etiqueta <title> hardcodeada ignorando WordPress y el plugin SEO activo: el resultado es dos etiquetas <title> en el HTML.
• Meta description o canonical generados por el tema en paralelo a los del plugin SEO: conflicto directo entre dos fuentes que dicen cosas distintas.
• Etiquetas Open Graph (og:title, og:image, og:description) hardcodeadas en el tema: invalida completamente lo que configuren tanto el cliente como el plugin SEO.
• Schema markup emitido por el tema en paralelo al del plugin SEO: datos estructurados duplicados o contradictorios que Google puede ignorar o interpretar mal.
• Meta robots hardcodeado en el tema: puede estar bloqueando la indexación de páginas enteras sin que nadie lo sepa.

Importante

• Saltos de jerarquía de encabezados: pasar de <h1> a <h4> directamente porque visualmente quedaba mejor así.
• Encabezados <h2> o <h3> usados en menús de navegación, sidebars o footer por razones de estilo: rompen la jerarquía del contenido de cada página.
• Paginación implementada con JavaScript sin etiquetas <a href> reales: Google no puede rastrear el contenido paginado si no hay URLs enlazables.
• Botones de acción o elementos de navegación implementados con onclick o <div> sin href real: invisibles para Google y para el teclado.
• Imágenes sin atributo alt, incluso las decorativas que deberían llevar alt="": problema de accesibilidad y de SEO de imágenes.
• Links sin texto visible (solo icono sin aria-label): los motores de búsqueda no saben qué enlaza ese elemento.
• Microdata (itemscope, itemtype) incompleta o mezclada con JSON-LD del plugin SEO: la fuente única de schema debería ser el plugin SEO, no el tema.

Menor

• Imágenes con alt que contiene el nombre de archivo literal (IMG_4582.jpg): no aporta nada y el buscador lo sabe.
• Elementos semánticos HTML5 (<article>, <main>, <nav>, <footer>) ausentes o usados de forma incorrecta: impacto principalmente en accesibilidad, menor en SEO directo.
• Múltiples elementos <nav> sin aria-label que los distinga: los lectores de pantalla no pueden diferenciarlos.
• Atributos target="_blank" en links externos sin rel="noopener".
• Texto oculto con display:none o visibility:hidden sobre contenido con palabras clave: puede interpretarse como intento de manipulación aunque no lo sea.

Estructura general del código

Antes de tocar nada conviene saber exactamente qué tienes entre manos. No para arreglarlo de inmediato, sino para no romper algo que no sabías que existía.

Crítico

• Tema que es en realidad un tema padre comercial modificado directamente (Divi, Avada, Elementor Hello con cambios en los archivos del padre): en la próxima actualización del padre, los cambios desaparecen sin dejar rastro.
• Ausencia total de tema hijo cuando se trabaja sobre un tema padre: cualquier actualización borra las personalizaciones sin aviso.
• Código del tema que escribe o modifica archivos del servidor en tiempo de ejecución fuera de la carpeta de uploads: señal de alerta que puede ser un mecanismo de persistencia.

Importante

• functions.php monolítico de varios miles de líneas sin estructura de includes ni organización visible: funciona, pero el mantenimiento es costoso y el riesgo de romper algo al editar es alto.
• Mezcla de lógica de tema y lógica de negocio en los mismos archivos: hace difícil separar qué es el tema y qué es personalización específica del proyecto.

Menor

• Ausencia de changelog o historial de cambios, aunque sea en comentarios: no rompe nada, pero hace imposible saber qué se tocó y cuándo.
• Tema hijo con un style.css vacío o con cabecera incorrecta o incompleta: técnicamente funcional, pero señal de que se creó con prisas.

Tiendas online

Si no hay WooCommerce en la instalación, este bloque no aplica y puedes saltarlo. Si la hay, es igual de importante que cualquiera de los anteriores.

Plantillas de WooCommerce

Cuando un tema a medida copia plantillas de WooCommerce a su propia carpeta woocommerce/, esas plantillas quedan congeladas en la versión de WC que había cuando se programó el tema. Cada actualización de WooCommerce puede cambiar esas plantillas, y si el tema no las actualiza al mismo ritmo, la tienda empieza a comportarse de formas inesperadas y a veces invisibles hasta que el cliente llama.

WooCommerce avisa en WooCommerce > Estado > Herramientas si hay plantillas obsoletas, con la versión de la plantilla original y la que tiene el tema. Si hay plantillas en esa lista, hay trabajo pendiente.

Schema y breadcrumbs de WooCommerce

Si el tema emite su propio schema de producto (JSON-LD o microdata) en las páginas de producto de WooCommerce, entra en conflicto con el que genera el plugin SEO. Uno de los dos debe ganar, y lo razonable es que sea el plugin SEO, no el tema. Revisar el código fuente de una página de producto y buscar bloques <script type="application/ld+json">: si hay más de uno, hay un problema.

Lo mismo con las migas de pan: si el tema tiene los suyos y los de WooCommerce también están activos, el resultado puede ser dos migas de pan en la misma página o ninguna en las páginas de producto.

Crítico

• Acceso directo a pedidos mediante wp_posts o wp_postmeta con post_type='shop_order': desde WooCommerce 7.1, HPOS (High Performance Order Storage) mueve los pedidos a tablas propias. Si el tema consulta pedidos de la forma antigua, falla en cualquier instalación con HPOS activo.
• Uso de $woocommerce->cart, $woocommerce->session u otros accesos directos al global $woocommerce: reemplazados por WC()->cart, WC()->session hace años. Funcionan en instalaciones antiguas, rompen en las nuevas.
• Funciones de WooCommerce eliminadas en versiones recientes: igual que con las funciones de WordPress, si aparecen en el código el tema puede dar error crítico en la próxima actualización mayor de WC.
• Código que llama a funciones de WooCommerce sin comprobar previamente si WC está activo: si WC se desactiva aunque sea temporalmente, el tema da error fatal en lugar de degradar con gracia.

Importante

• Plantillas de WooCommerce sobreescritas con versiones muy por detrás de la actual: el riesgo de rotura es proporcional a la diferencia de versiones.
• Hooks de WooCommerce obsoletos con alias activos: funcionan, pero el alias puede desaparecer en una actualización mayor. Planificar sustitución.
• Assets de WooCommerce desactivados globalmente en el tema cuando solo deberían desactivarse fuera de las páginas de tienda: puede producir carrito roto o checkout sin estilos en algún caso concreto.

Menor

• Plantillas sobreescritas con una o dos versiones de diferencia y sin cambios funcionales conocidos en esas versiones: bajo riesgo inmediato, pero hay que revisarlas en la próxima actualización de WC.

Por dónde empezar

Los tres niveles del artículo trasladan directamente a la priorización del trabajo:

Crítico: corregir antes de entregar, publicar o tocar nada más

No hay entrega válida con críticos abiertos. Si el encargo es asumir el mantenimiento de un proyecto heredado, los críticos se resuelven antes de cualquier otra tarea.

• Vulnerabilidades de seguridad activas: SQL sin preparar, variables sin escapar impresas, ausencia de nonces en formularios que modifican datos.
• Incompatibilidades PHP que pueden dar error crítico con la próxima actualización del servidor.
• Funciones de WordPress o WooCommerce eliminadas del todo.
• Conflictos SEO activos: doble etiqueta <title>, metas duplicadas, meta robots hardcodeado.
• N+1 queries en producción con tráfico real.
• Tema padre comercial modificado directamente sin tema hijo.

Importante: planificar en la próxima actuación

Antes de la siguiente actualización mayor de WordPress o PHP.

• Funciones WP o PHP obsoletas con sustitución conocida.
• Scripts y estilos sin condición que cargan en todas las páginas.
• IDs, slugs y URLs hardcodeados en la lógica del tema.
• APIs de terceros sin fallback documentado.
• Plantillas WooCommerce con varias versiones de diferencia.
• Saltos de jerarquía de encabezados y paginación sin links reales.

Menor: documentar y corregir

Cuando se pase por ese código por otra razón.

• Estilo de código y cumplimiento de estándares de WordPress.
• Cadenas sin traducir, comentarios en el idioma incorrecto, archivos sobrantes.
• Scripts que podrían ir al pie, imágenes sin lazy load.
• Alt de imagen con nombre de archivo, elementos semánticos HTML5 ausentes.

Una vez el tema está limpio y en producción, el escáner de cambios de archivos de Vigilante avisa si alguien modifica un archivo del tema sin que lo sepas, que es exactamente lo que ocurre cuando un ataque planta un backdoor en un archivo que ya existía. No te libra de hacer la auditoría, pero cierra la puerta después de haberla hecho.

Compatibilidad futura

La auditoría que acabas de hacer es una foto del tema en este momento. Un tema bien hecho hoy puede dejar de funcionar en seis meses si nadie vigila lo que viene. Este bloque no es sobre arreglar nada: es sobre no tener que volver a arreglar las mismas cosas en la siguiente revisión porque nadie las anticipó.

PHP

El patrón de PHP es siempre el mismo: lo que hoy es un aviso de obsolescencia, en la siguiente versión mayor desaparece sin más. La lista de lo que PHP 9 va a eliminar ya existe hoy, en forma de avisos de obsolescencia en PHP 8.x. Eso significa que si el tema genera avisos de obsolescencia con PHP 8.5 o con la 8.6 que llega a finales de 2026, esos avisos son exactamente lo que va a romper cuando llegue PHP 9.

PHP 9 no tiene fecha oficial todavía, pero eso no cambia la lógica: las obsolescencias actuales son las eliminaciones futuras. PHPCompatibility te permite pasar como parámetro una versión objetivo futura para que analice el código contra lo que sabe que vendrá. Si aún no tienes configurado PHP CodeSniffer con PHPCompatibility, este es el argumento más práctico para hacerlo.

Para seguir el roadmap de PHP sin tener que buscar manualmente, PHP.Watch mantiene una lista actualizada de todas las versiones en desarrollo, con las obsolescencias y eliminaciones previstas para cada una. Suscribirse a su feed RSS o newsletter es el método más directo de no perderse nada relevante antes de que llegue al servidor.

Lo que hay que comprobar con PHPCompatibility al auditar un tema a medida no es solo la versión de PHP actual del servidor, sino también las siguientes:

• PHP 8.5 (estable desde noviembre de 2025): la versión que muchos hostings tienen como recomendada para 2026.
• PHP 8.6 (prevista para finales de 2026): ya tiene calendario oficial y los primeros RFCs de obsolescencias aprobados.
• PHP 9.x (sin fecha oficial): usar PHPCompatibility en modo --runtime-version=9.0 avisa de lo que ya está marcado como candidato a eliminación en los milestones públicos de php-src.

WordPress

WordPress avisa con antelación de todo lo que deja obsoleto y de todo lo que planea eliminar. El problema es saber dónde mirarlo. Estos son los canales que importan si mantienes un tema a medida:

• Make WordPress Core: el blog de desarrollo del núcleo. Aquí se publican las agendas de los dev chats semanales, los field guides de cada versión y las propuestas de cambios que afectarán a temas y plugins. Si solo sigues un canal, que sea este.
• WordPress Developer Blog: el canal oficial para desarrolladores de plugins y temas. Las dev notes de cada versión se publican aquí con el detalle de qué cambia, qué queda obsoleto y qué hay que actualizar antes de la siguiente mayor.
• Make WordPress Security: el blog del equipo de seguridad. Publica las notas de los problemas resueltos en cada versión puntual y las iniciativas de seguridad del ecosistema.

Ambos blogs tienen feed RSS. Añadirlos al lector de feeds del equipo es suficiente. No hace falta revisar Make Core a diario: las entradas importantes son fáciles de identificar por las etiquetas dev-notes y field-guide.

Para el perfil técnico, el comando wp core check-update de WP-CLI comprueba si hay actualizaciones pendientes del núcleo. Y revisar periódicamente con PHP CodeSniffer + WPCS las funciones del tema contra la versión de WPCS actualizada detecta lo que el equipo de WordPress Core ya ha marcado como deprecated en el estándar, aunque el tema aún funcione hoy sin avisos visibles.

Seguridad

Un tema a medida no está en ninguna base de datos de vulnerabilidades públicas, así que las alertas que importan aquí son las de las librerías de terceros que incluya y las del ecosistema general de WordPress. El 91% de las vulnerabilidades reportadas en WordPress en 2025 estaban en plugins y temas de terceros, no en el núcleo.

Si el tema incluye librerías JavaScript o PHP copiadas en su carpeta, esas librerías sí pueden aparecer en las bases de datos.

Las fuentes que conviene tener activas:

• Patchstack Database: base de datos gratuita de vulnerabilidades en plugins, temas y el núcleo de WordPress. El plan gratuito incluye alertas por email con hasta 48 horas de antelación sobre nuevas vulnerabilidades reportadas. Útil tanto para los plugins de la instalación como para identificar si alguna librería incluida en el tema tiene CVE conocido.
• WPScan Vulnerability Database: base de datos pública con vulnerabilidades de WordPress clasificadas por severidad. Tiene API gratuita para consultas automatizadas y se puede integrar en pipelines de CI/CD.
• WordPress.org Security: las notas oficiales de cada versión de seguridad del núcleo. Feed RSS disponible. Las versiones menores de WordPress (las que tienen tres números, como x.x.1) suelen ser parches de seguridad, y el equipo de WordPress las publica con descripción de lo que corrigen.
• Wordfence Intelligence: el blog de inteligencia de amenazas de Wordfence publica análisis de vulnerabilidades activas, con descripción técnica y estado de explotación. Especialmente útil cuando una vulnerabilidad está siendo explotada masivamente y el tema puede incluir el componente afectado.

WooCommerce

WooCommerce sigue un ciclo de lanzamientos propio, independiente del de WordPress, con versiones mayores que introducen cambios de API y obsolescencia propias. Para mantenerse al día conviene seguir el WooCommerce Developer Blog y revisar el changelog de cada versión mayor antes de actualizar en producción. Las plantillas sobreescritas que ya revisaste en el bloque anterior son exactamente el tipo de deuda que se acumula cuando el mantenedor no sigue ese ritmo.

Periodicidad mínima de revisión

Todo lo anterior tiene sentido si se convierte en un hábito, no en una tarea puntual. Esta es la cadencia mínima razonable para un tema a medida en producción:

• Mensual: revisar las alertas de Patchstack o WPScan para los componentes que incluye el tema. Aplicar las actualizaciones de seguridad pendientes del núcleo y los plugins.
• Con cada versión mayor de WordPress: ejecutar PHP CodeSniffer + WPCS actualizado sobre el tema para detectar lo que la nueva versión ha dejado obsoleto. Revisar las dev notes del Developer Blog antes de actualizar en producción.
• Con cada versión mayor de PHP disponible en el hosting: ejecutar PHPCompatibility contra esa versión en staging antes de cambiarla en producción.
• Anual: repetir la auditoría completa de este artículo. Lo que era Menor el año pasado puede haberse convertido en Crítico si el ecosistema ha avanzado y el tema no.

La IA como herramienta de auditoría: los prompts que más uso

Estos son los prompts prácticos para las revisiones más habituales. No sustituyen al análisis en tiempo de ejecución (Query Monitor, el log de errores) pero cubren gran parte del análisis estático sin instalar nada.

Para el propietario sin código (pegar el contenido de functions.php):

Lee este archivo functions.php y dime en términos simples si hay algo peligroso, algo obsoleto y algo que podría dar problemas de rendimiento. No asumas que sé programar.

Para el análisis SEO (pegar el código fuente HTML completo de la página):

Analiza la estructura de encabezados de este HTML. Dime cuántos H1 hay, si hay saltos de jerarquía y si algún encabezado está en un lugar estructuralmente incorrecto. Busca también si hay más de una etiqueta title o más de una meta description.

Para el técnico (Claude Code sobre la carpeta completa del tema):

Audita este tema WordPress a medida. Busca: 1) vulnerabilidades de seguridad (XSS, SQL injection, ausencia de nonces y de comprobaciones de capacidades); 2) funciones PHP eliminadas o incompatibles con PHP 8.x; 3) funciones WordPress obsoletas; 4) N+1 queries; 5) scripts encolados sin condición en todas las páginas. Clasifica los hallazgos en Crítico, Importante y Menor, y dame el archivo y la línea de cada uno.

Una limitación que hay que tener clara es que la IA detecta problemas en el código estático, no en la ejecución, no rastrea el comportamiento en tiempo real, no ejecuta el tema ni simula una carga real. Es complementaria a Query Monitor y al log de errores, no los reemplaza.

Un regalo para terminar

Y ya que has llegado hasta aquí, para no tener que documentar la auditoría en un Excel improvisado ni en un bloc de notas, hay una herramienta gratuita, la auditoría de temas WordPress, que he creado exactamente para esto.

La abres al lado de lo que estés revisando, vas añadiendo hallazgos con el bloque, la descripción, la gravedad y la acción propuesta, y cuando terminas un botón genera el informe completo listo para exportar, descargar en PDf, imprimir o enviar al cliente. Sin cuenta, sin IA, sin conexión necesaria, todo en tu navegador.

Si tienes dudas sobre lo que encuentres, o quieres apoyo en el mantenimiento continuo de la web una vez resuelta la auditoría, en mi servicio de mantenimiento web tienes la opción de delegar eso. Y para cualquier cosa que no quede clara me tienes en los comentarios.

A eso se le llama spam SEO inyectado, y no persigue tumbar tu web ni robarte datos, lo que busca es aprovechar la autoridad que llevas años construyendo para posicionar webs basura de farmacias ilegales, tiendas de imitaciones de lujo o casinos online. Usan tu dominio como trampolín, y mientras ellos cobrando las comisiones de afiliados.

El informe State of WordPress Security de Patchstack recoge datos de Sucuri que cifran en más de 422.000 los incidentes de spam SEO detectados en 2024, con el spam japonés como la variante más extendida, responsable del 27,77% de todos los casos. No es un problema marginal ni de lejos.

Vamos a ver qué formas tiene este ataque de inyección de spam, cómo detectarlo y cómo cerrarlo, desde lo más básico hasta lo más potente.

Tres tipos de spam SEO, tres niveles de problema

No todos los ataques de spam SEO son iguales ni entran por el mismo sitio ni se detectan igual. Conviene distinguirlos antes de ponerse a tapar agujeros a ciegas.

El más visible: spam en los comentarios

El atacante (o casi siempre un bot automatizado) publica comentarios que incluyen enlaces a las webs que quieren posicionar. Google rastrea esos enlaces cuando visita tu web y les transfiere autoridad, el resultado es que tu web contribuye al SEO de una farmacia sin receta, una tienda de relojes falsificados o cualquier otra web de mierda.

Es el nivel básico, es feo, molesto y contraproducente para tu propio perfil de enlazado, pero por otro lado es fácil de detectar porque lo ves tú mismo en la sección de comentarios.

El nivel medio: inyección de enlaces en la base de datos

Aquí ya el atacante ha conseguido entrar en tu instalación, pues en lugar de dejar un comentario, inyecta enlaces directamente en el contenido de tus entradas o páginas, en campos de la base de datos como wp_options o wp_postmeta, o en el código del tema. Los enlaces pueden ir con CSS que los oculta visualmente a los visitantes humanos, pero que los rastreadores de los buscadores leen perfectamente.

No lo ves navegando tu web, pero lo puedes ver revisando el código fuente de la página o auditando la base de datos.

El más peligroso: el pharma hack y el spam japonés con cloaking

Este es el nivel que da más guerra, nunca mejor dicho, pues el atacante instala en tus archivos o en la base de datos un código que comprueba quién está visitando la página antes de decidir qué contenido servir.

Si detecta que es un rastreador de Google, Bing o Yandex, sirve páginas llenas de palabras clave farmacéuticas o texto en japonés, si detecta a un visitante humano normal, muestra tu contenido de siempre. Podríamos decir que es hackeo inteligente.

El resultado es que tú entras a tu web y ves todo perfecto, pero ve un catálogo de medicamentos sin receta con miles de páginas generadas automáticamente.

Esta técnica se llama cloaking (camuflaje), y es deliberada porque los atacantes no quieren que lo descubras. Cuanto más tiempo lleve activo, más autoridad de tu dominio han aprovechado, y cuanto más tarde en detectarse, más difícil es la recuperación del SEO después.

El truco que hace invisible la infección

Para entender por qué no lo ves desde el escritorio de WordPress hay que entender cómo funciona el cloaking.

El código malicioso, que puede vivir en tu .htaccess, en tu wp-config.php, en el functions.php del tema o en archivos de plugins, lee la cabecera User-Agent de cada petición que llega al servidor. Esa cabecera identifica quién hace la petición: si es Chrome, Firefox, Safari o un bot de Google.

Si el User-Agent es Googlebot, Bingbot, baiduspider o cualquier rastreador conocido, el código conecta con el servidor del atacante, descarga el contenido de spam del momento y lo sirve. Si eres tú entrando desde el navegador, con tu sesión de WordPress activa o simplemente con un User-Agent de navegador normal, ves tu web tal cual.

Este mecanismo explica por qué muchos propietarios de WordPress llevan meses o incluso años con la infección activa sin saber nada. Y explica también por qué la primera señal de alarma suele venir de fuera, como de un aviso de Google Search Console, un cliente que lo vio en Google, o una caída inexplicable del tráfico orgánico.

El código malicioso se esconde habitualmente en estos sitios:

• Las primeras o últimas líneas del wp-config.php, camuflado como comentario o como código de configuración aparentemente legítimo.
• El archivo .htaccess, con reglas de redirección condicionales.
• El functions.php del tema activo, aprovechando que se ejecuta en cada carga.
• La carpeta mu-plugins/ (de must-use plugins), que se ejecuta automáticamente en cada carga de página y no aparece en la lista de plugins del escritorio, lo que la convierte en el escondite preferido para la persistencia después del hackeo.
• La carpeta uploads/, donde a veces aparecen archivos .php disfrazados de imágenes.
• Opciones de la base de datos en wp_options, codificadas en base64 para dificultar la detección.

Y sobre la cadena de suministro como vector de entrada, si no leíste el artículo de los ataques a la cadena de suministro en WordPress que publiqué hace unas semanas, te lo resumo en que el caso Essential Plugin fue exactamente esto, una puerta trasera que servía spam SEO camuflado solo a los rastreadores, invisible para los propietarios. El ataque más sofisticado posible a través del canal oficial de actualización de plugins.

Cómo saber si te han inyectado spam SEO antes de enterarte por Google

No esperes al aviso de Search Console. Para cuando Google te manda la alerta, la infección lleva semanas o meses activa y el daño al SEO ya está hecho, es mucho mejor buscarlo activamente ¿a que sí?.

La búsqueda más directa

Ve a Google y escribe site:tudominio.com, revisa los resultados que aparecen, y si ves páginas con caracteres japoneses, títulos sobre medicamentos, casinos o productos que no tienen nada que ver con tu contenido real, date por inyectado.

También puedes añadir términos sospechosos: site:tudominio.com viagra, site:tudominio.com casino. Si aparece algo ya tienes la confirmación.

Google Search Console

En la sección de seguridad y acciones manuales aparecerán los avisos si Google ya ha detectado el problema. Pero no esperes solo a eso, en el inspector de URLs puedes comparar cómo procesa Google una URL concreta de tu web frente a cómo la ves tú. Si el contenido que ve Google no coincide con el que ves tú, ¡te han cloakeado!

Ojo también con los usuarios que tienen acceso a tu Search Console. Una técnica habitual es añadir un usuario del atacante como propietario o delegado para poder manipular el sitemap e indexar las páginas de spam. Revísalo en Ajustes → Usuarios y permisos.

Herramientas de escáner externo

El escáner gratuito Sucuri SiteCheck analiza tu web desde fuera, como lo haría un motor de búsqueda, y detecta código malicioso, listas negras y redirecciones sospechosas. No necesitas instalar nada.

También la base de datos de WPScan te permite comprobar si alguno de tus plugins tiene vulnerabilidades conocidas activas.

Lo que puedes ver desde el escritorio de WordPress

Ve a Usuarios → Todos los usuarios y filtra por el perfil de administrador. ¿Los reconoces todos? Una práctica habitual tras un hackeo es crear usuarios administradores falsos para mantener el acceso aunque limpies los archivos. Borra sin piedad cualquier usuario que no reconozcas.

WP-CLI si tienes acceso por SSH

Si tienes acceso al servidor, estos tres comandos te dan una imagen rápida del estado:

wp core verify-checksums
wp plugin verify-checksums --all
wp user list --role=administrator --format=table

El primero compara los archivos del núcleo de WordPress con los oficiales y te dice si alguno ha sido modificado, el segundo hace lo mismo con los plugins que tienen checksums en WordPress.org (esto mismo puedes hacerlo con Vigilante), y el último lista todos los administradores para que compruebes quién está ahí.

Para buscar código sospechoso en PHP lanza esto en la raíz de tu instalación:

grep -ri "base64_decode\|eval(" wp-content/ --include="*.php" -l
find wp-content/uploads -name "*.php" -ls

El primer comando busca los patrones de ofuscación más comunes, el segundo lista todos los archivos PHP que hay en uploads/, donde no debería haber ninguno.

De lo más básico a lo más serio: así cierras la puerta

Ninguna medida por sí sola es suficiente. La defensa funciona por capas, y cada capa tapa los agujeros que la anterior deja sin cubrir.

Capa básica: comentarios y acceso público

La primera y más sencilla. No protege contra el pharma hack ni el spam japonés, pero sí contra el spam de comentarios y contra que atacantes anónimos inyecten contenido.

• Cierra los comentarios en entradas antiguas: En Ajustes → Comentarios, activa «Cerrar automáticamente los comentarios de entradas con más de X días de antigüedad». Los bots de spam atacan preferentemente entradas viejas porque suelen tener menos supervisión.
• Modera todos los comentarios antes de publicarlos: En el mismo panel, activa «El comentario debe aprobarse manualmente». Ningún enlace de spam se publica sin que tú lo veas primero.
• Instala un filtro de spam: Akismet sigue siendo la referencia, aunque requiere clave de API. Alternatives gratuitas como Antispam Bee o CleanTalk funcionan bien en la mayoría de casos.
• Desactiva los pingbacks: En Ajustes → Comentarios, desmarca «Permitir avisos de enlace de otros blogs». Los pingbacks tienen un uso muy limitado en 2026 y son un vector de abuso.
• Desactiva el registro de usuarios si no es imprescindible: En Ajustes → Generales, desmarca «Cualquiera puede registrarse». Si tu web no necesita que los visitantes tengan cuenta, no hay razón para exponerlo.

Capa media: archivos, permisos y credenciales

Aquí va el grueso de la protección contra los ataques más sofisticados. Patchstack registró en 2025 la cifra de 11.334 vulnerabilidades en el ecosistema WordPress, con un tiempo medio de apenas 5 horas desde que se publica la vulnerabilidad hasta que los bots la explotan. Mantener todo actualizado no es opcional, es la primera línea de defensa real.

• • Actualiza siempre y cuanto antes: WordPress, plugins y temas. El 91% de las vulnerabilidades de 2025 estaban en plugins, no en el núcleo. Cada plugin sin actualizar es una puerta potencialmente abierta.
  • Permisos de archivos correctos: Los archivos deben estar a 644 y los directorios a 755. El wp-config.php puede ir a 440 o 400 si tu servidor lo permite.
  • Protege los archivos sensibles desde el servidor: Añade esto por encima del bloque # BEGIN WordPress:

# Proteger wp-config.php
<Files wp-config.php>
  Order Allow,Deny
  Deny from all
</Files>

# Proteger .htaccess
<Files .htaccess>
  Order Allow,Deny
  Deny from all
</Files>

# Bloquear ejecución de PHP en uploads
<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteRule ^wp-content/uploads/.*\.php$ - [F,L]
</IfModule>

# Deshabilitar listado de directorios
Options -Indexes

• Bloquea la ejecución de PHP en la carpeta uploads/: Esta carpeta tiene que poder recibir archivos subidos, pero nunca ejecutar PHP. Es uno de los vectores de acceso más habituales una vez que un atacante ha conseguido subir un archivo malicioso.
• Contraseñas fuertes y únicas para todos los administradores: Si tienes varios usuarios con rol de Administrador, cada uno con su propia contraseña segura. Un gestor de contraseñas como Bitwarden lo hace fácil y gratuito.
• Elimina el usuario admin si todavía lo tienes: Es el primer nombre de usuario que prueban todos los ataques automatizados.
• Elimina temas y plugins nulled o piratas: Esto no lo negocies: los temas y plugins de fuentes no oficiales son el vector de infección más rápido y más evitable. Si los tienes, quítalos.
• Desactiva XML-RPC si no lo usas: La mayoría de webs WordPress no lo necesitan actualmente y es un vector de ataque muy usado para inyectar contenido de forma remota.

Capa avanzada: monitorización activa

Llegamos al punto donde la defensa deja de ser reactiva y se vuelve proactiva. No solo cerramos puertas sino que detectamos cuando alguien intenta abrirlas.

El archivo .htaccess y wp-config.php son los primeros objetivos de cualquier atacante que consiga acceso a tu servidor. Si esos archivos cambian sin que tú hayas tocado nada, tienes una infección activa. El problema es que nadie mira esos archivos todos los días.

Puedes usar Vigilante para monitorizar ambos archivos contra su línea base original, muestra un diff línea a línea de cualquier cambio y manda un aviso por correo en el momento en que detecta la modificación. En vez de enterarte semanas después porque Google te manda un aviso de acción manual, te enteras cuando el atacante toca el archivo. Eso es la diferencia entre limpiar una infección de horas y limpiar meses de daño en el SEO.

Más allá de eso, un escáner periódico de integridad de archivos compara los archivos de tu instalación con los oficiales de WordPress.org y detecta modificaciones, archivos añadidos o código sospechoso en temas y plugins. Lo ideal es que esto corra de forma automática y te mande el informe.

Otras medidas avanzadas:

• Activa la identificación en dos pasos (2FA) para todos los administradores: Si las credenciales quedan expuestas en una filtración, el 2FA es lo que evita que sirvan de algo.
• Registra toda la actividad con un log de auditoría: Logins, cambios de contraseña, activaciones de plugins, modificaciones de entradas, así todo queda registrado y con alerta si algo parece raro. Si un atacante crea un usuario administrador o activa un plugin que no reconoces, necesitas saberlo en el momento.
• Revisa la carpeta mu-plugins/ periódicamente: Los archivos que hay ahí se ejecutan en cada carga de página sin aparecer en la lista de plugins. Si encuentras algo que no pusiste tú, bórralo.
• Usa un cortafuegos a nivel de aplicación: Cloudflare como primera capa (gratis en su plan básico) más un plugin de seguridad con WAF dentro de WordPress bloquea la mayor parte del tráfico malicioso antes de que llegue a intentar explotar nada.
• Activa la detección de plugins cerrados: WordPress.org cierra plugins cuando se descubren problemas de seguridad. Si tienes uno instalado y lo cierran, necesitas saberlo ese mismo día, no cuando busques en Google por qué tu web se comporta raro. Esto lo tiene Vigilante, nadie más.

Para completar la defensa contra fuerza bruta, tienes una guía específica en el plan de batalla contra ataques de fuerza bruta con el detalle de cómo montar la protección por capas desde Cloudflare hasta el plugin.

Ya lo tengo ¿qué hago?

Si llegas a este punto con la confirmación de que tu web está infectada, para. No borres nada todavía. El orden importa porque si limpias sin cerrar el vector de entrada, la infección vuelve en horas.

1. Haz una copia de seguridad completa ahora mismo, incluyendo archivos y base de datos. Incluso de la versión infectada. La necesitarás como referencia para saber exactamente qué cambió y para no perder el contenido legítimo si algo sale mal durante la limpieza.
2. Pon el sitio en modo mantenimiento para que los visitantes no lleguen a las páginas infectadas mientras limpias.
3. Ejecuta un escáner completo (Wordfence, Sucuri o Vigilante) y guarda el informe completo antes de tocar nada. Necesitas la lista de todo lo afectado antes de empezar a limpiar.
4. Limpia el núcleo de WordPress. Descarga la versión exacta que tienes de wordpress.org y sustituye las carpetas wp-admin/ y wp-includes/ por las originales. No toques wp-content/ ni wp-config.php en este paso.
5. Elimina todos los plugins y temas y reinstálalos desde cero. Descarga versiones limpias desde WordPress.org o de sus fuentes oficiales. No reactivar los plugins nulled.
6. Revisa wp-config.php buscando código inyectado al principio o al final del archivo, y revisa .htaccess buscando redirecciones condicionales que no pusiste tú. Si usas Vigilante y tenías el monitoreo activado, el diff te muestra exactamente qué líneas cambiaron.
7. Audita la carpeta mu-plugins/ y la carpeta uploads/ buscando archivos PHP que no deberían estar ahí.
8. Limpia la base de datos. Revisa wp_posts buscando contenido con enlaces ocultos o contenido que no reconoces. Revisa wp_options buscando valores codificados en base64. Busca en wp_users usuarios administradores que no reconoces.
9. Elimina todos los usuarios administrador que no reconozcas y cambia las contraseñas de todos los que sí reconozcas.
10. Cambia las credenciales de todo: WordPress, base de datos, FTP y cuenta de hosting. Si la contraseña que usaban para entrar sigue activa, vuelven.
11. Actualiza WordPress, todos los plugins y todos los temas a la última versión disponible.
12. Ejecuta un segundo escáner completo para verificar que la limpieza ha sido efectiva antes de quitar el modo mantenimiento.

Si después de limpiar la infección vuelve en horas o días, hay algún punto de re-entrada que no has cerrado: un plugin vulnerable que no actualizaste, un usuario comprometido que no eliminaste, o una puerta trasera en mu-plugins/ o en uploads/ que te has dejado. Vuelve al escáner y revisa esos puntos específicamente.

Si el proceso te supera o si el sitio tiene un volumen de páginas infectadas que hace que la limpieza manual sea inviable, el servicio de recuperación de web hackeada existe exactamente para esto.

Recuperar el SEO después del golpe

Limpiar la infección es la mitad del trabajo, la otra es convencer a Google de que ya no hay problema.

Si Google emitió una acción manual contra tu sitio, aparecerá en Search Console → Seguridad y acciones manuales → Acciones manuales. Una vez limpias la web, puedes solicitar revisión desde esa misma pantalla. El equipo de calidad de Google suele responder en unos días en los casos más claros.

Si no hay acción manual sino penalización algorítmica (tu tráfico cayó pero no hay aviso explícito), el proceso es más lento porque Google necesita volver a rastrear las páginas afectadas y procesar que el contenido ya no está. Puedes acelerar esto enviando tu mapa del sitio actualizado desde Search Console y usando la herramienta de inspección de URLs para solicitar la indexación de tus páginas principales.

Las páginas de spam que Google tenía indexadas (los miles de URLs con contenido japonés o farmacéutico) irán desapareciendo del índice a medida que Google las reindexe y confirme que el contenido ya no está. Este proceso puede tardar semanas, no es inmediato, pero sí progresivo.

Monitoriza desde Search Console el número de páginas indexadas de tu dominio durante las semanas siguientes a la limpieza. Si vas bien, verás cómo esas URLs spam van desapareciendo del recuento.

Una última cosa

El spam SEO inyectado no es un ataque de película que requiere un hacker sofisticado persiguiendo tu web específicamente. Son ataques automatizados que explotan vulnerabilidades conocidas a escala industrial. El destino del ataque no eres tú, es el plugin sin actualizar que tienes instalado, y hay bots que escanean millones de webs buscando exactamente eso.

La buena noticia es que la defensa tampoco es complicada, se basa en mantener todo actualizado, cerrar los comentarios donde no hacen falta, monitorizar los archivos que más se tocan en un hackeo (wp-config.php y .htaccess) y tener un escáner que avise cuando algo cambia cubre la inmensa mayoría de los casos. Para eso desarrollé Vigilante, para que no tengas que pagar por todas esas funcionalidades des seguridad imprescindibles.

El trabajo hay que hacerlo antes de que llegue el problema, no después. Cuando Google te manda el aviso el daño ya lleva semanas hecho.

Si tienes dudas o has pasado por esto y quieres compartir cómo fue el proceso, me tienes ahí abajo en los comentarios.

Crónicas WordPress: la actualidad de la semana, sin anestesia

El lunes toca Crónicas WordPress, mi repaso a la actualidad con opinión incluida, que para eso es mi casa. Y esta semana la seguridad se llevó el protagonismo, y no precisamente para bien.

Seguridad: semana movidita

Arrancamos fuerte con la Operación EndGame, el operativo internacional que ha desmantelado una red enorme de malware, con un montón de webs infectadas de por medio. De ahí saltamos a los sospechosos habituales del jardín WordPress, que no dieron tregua:

• Gravity SMTP: una vulnerabilidad ha dejado las claves de correo a la intemperie, con millones de intentos de ataque aprovechando el agujero. Si lo tienes instalado, actualiza ya mismo.
• Avada Builder: fallo crítico que permitía borrar archivos sin ni siquiera estar autenticado, o sea, cualquiera desde fuera. De los que quitan el sueño.
• Secuestro de cookies de sesión: te conté cómo alguien puede colarse en tu WordPress sin contraseña ni 2FA (el doble factor de autenticación), robándote la sesión, y qué hacer para taparlo. Lo tienes con calma en mi artículo sobre la seguridad de las cookies de sesión.

El «congelador» de 24 horas y la rebelión de los desarrolladores

WordPress.org ha decidido retrasar 24 horas la publicación de las actualizaciones de plugins para poder revisarlas antes de que lleguen a tu web. La idea, sobre el papel, tiene sentido. El problema es que los desarrolladores se le han rebelado en bloque, y hay razones para las dos posturas. Le dediqué el último Doctor entero, así que te lo cuento un poco más abajo.

Comunidad: dos WordCamps, un adiós y culebrón judicial

• WordCamp Costa Rica 2026: los días 18 y 19 de septiembre en San José.
• WordCamp Galicia 2026: 17 y 18 de octubre en A Coruña, y las entradas ya están a la venta, así que ya sabes.
• Om Malik: nos ha dejado a los 59 años uno de los primerísimos usuarios de WordPress. Un recuerdo desde aquí.
• Automattic contra WP Engine: el culebrón judicial sigue su curso y Automattic se ha apuntado un tanto en la pelea por los mensajes de Slack. A río revuelto…
• Panel de contribuciones: estrena escalas personalizables, un detalle majo para quien echa una mano al proyecto.

Versiones y producto: WordPress 7.0.1, 7.1 y compañía

En el frente del desarrollo también hubo tela que cortar:

• WordPress 7.0.1 viene de camino, con su candidata a versión final y lanzamiento a la vuelta de la esquina.
• WordPress 7.1 va a esconder el bloque Clásico del insertor. Que no eliminarlo, ojo, que aquí nadie se toca nada todavía.
• WooCommerce 10.9 llega con registro de emails transaccionales y mejoras de interfaz.
• IA en el propio core: el equipo de inteligencia artificial propone meter wp_knowledge en WordPress. El melón está abierto.

IA y SEO ¡ya está liada!

Y cerramos por donde más se mueve el suelo últimamente, la IA y el SEO. Los plugins se están poniendo las pilas: SEOPress 10 se abre a los agentes de IA, trae asistente en el editor y compatibilidad con la Abilities API, mientras que Visibility mete SEO, AEO y GEO (el posicionamiento de toda la vida más el de los buscadores y las respuestas de IA) en un mismo plugin. Sobre si te puedes fiar de los plugins hechos con IA, ya te di mi opinión con matices en este artículo.

En el lado de Google, la actualización de spam de junio de 2026 se completó en tiempo récord, y como muestra del terremoto conté el caso de WPBeginner, que ha pasado de 2,6 millones a 27.000 clics mensuales. Ahí es nada. Si te preguntas qué pintas tú en todo esto, la respuesta pasa por el E-E-A-T, que te expliqué en esta guía.

Ver el directo completo de Crónicas WordPress en YouTube.

Y ya está, porque esta semana no pude hacer el Doctor WordPress por temas de agenda, y ya que lo siento.

Nos vemos en el próximo directo

Y hasta aquí el repaso de la semana. Si te ha quedado alguna duda de cualquiera de los temas, o quieres soltarme tu opinión sobre lo del congelador de plugins (que seguro que tienes la tuya), me tienes ahí abajo, en los comentarios.

Recuerda que hago directo dos veces por semana: Crónicas los lunes y Doctor los miércoles, a partir de las 19:30, en el canal de Ayuda WordPress. Si te suscribes y le das a la campanita, no se te escapará ninguno.