Buscas una imagen que subiste hace tres meses, no recuerdas el nombre del archivo, te plantas delante de un mosaico interminable y empiezas a hacer scroll y clics hasta encontrarla … o desistir.

Esto pasa porque la gestión de medios de WordPress en general, y la biblioteca en particular, a estas alturas, sigue sin tener un modo de organización decente, ni clasificación por carpetas de forma nativa, ni siquiera un buscador instantáneo decente , y parece ser que esto sí que alguien ha decidido que sea territorio plugins, o no se, buscarte la vida.

Total, que vamos a ver qué opciones tenemos de organizar ese desastre que es la (no) organización de medios en WordPress, que haberlas haylas.

Empezaremos repasando los plugins más interesantes, y luego te cuento algún apaño más.

Ojito con esto: carpetas virtuales y carpetas físicas

Antes de elegir plugin tienes que entender una cosa que no te cuentan bien, porque hay dos formas de organizar la biblioteca con carpetas, y casi no se suele decir, y es importante, al menos yo creo que lo es.

Carpetas virtuales

El plugin no toca tus archivos, lo que hace es crear una taxonomía o estructura interna en la base de datos que asocia cada imagen con una «carpeta».

En el servidor todo sigue en /wp-content/uploads/2026/04/ como siempre, ordenado por año y mes. Si miras por FTP, ahí no hay carpetas que valgan, solo cambia lo que ves en el escritorio de WordPress.

Carpetas físicas

El plugin mueve los archivos de verdad, de modo que si creas una carpeta «catálogo» y metes una imagen, el archivo se traslada a /wp-content/uploads/catalogo/imagen.jpg.

La URL del archivo cambia, y por tanto el plugin tiene que reescribir todas las referencias en la base de datos para que nada se rompa.

Cada enfoque tiene ventajas y problemas:

• Las virtuales son más seguras, rápidas y no rompen nada al activarlas, pero te atan al plugin de por vida (luego vemos por qué).
• Las físicas son más limpias, mejores para SEO y FTP, pero el proceso de migración es delicado y puede dejar enlaces rotos si algo va mal.

¿Qué pasa con las carpetas virtuales cuando desactivas el plugin?

Aquí está la trampa principal y donde se nota la diferencia entre plugins. Si todas tus carpetas son virtuales y un día decides desactivar o cambiar de plugin, esto es lo que pasa:

• Los archivos siguen en el servidor, en sus carpetas /uploads/año/mes/ de toda la vida, sin cambios. Eso es lo bueno.
• La estructura de carpetas que habías montado durante meses o años desaparece de la vista en cuanto desactivas. La biblioteca vuelve a ser ese mosaico infinito de antes.
• Si te pasas a otro plugin de carpetas virtuales, la mayoría tienen herramienta de importación, así que se puede migrar. Pero solo si el otro plugin sigue mantenido y tiene importador para el tuyo.
• Si el plugin muere o el desarrollador desaparece, dependes de que otro plugin meta soporte para importar desde él, y eso no siempre pasa.

O sea, con carpetas virtuales te casas con el plugin. Tu organización de medios deja de ser tuya, pasa a vivir en la base de datos del plugin que tengas instalado. No es un problema todos los días, pero el día que toca cambiar, si cambias, lo es.

Con carpetas físicas pasa lo contrario, pues si desinstalas el plugin los archivos siguen organizados en el servidor como los habías dejado.

La biblioteca de WordPress los seguirá viendo, porque la URL de cada imagen está guardada en su tabla de adjuntos. Pierdes la interfaz cómoda de carpetas en el escritorio, pero no pierdes la organización.

¿Lo tienes claro? pues empezamos, y si ya has tomado alguna decisión te saltas la parte que no te interesa.

Plugins para organizar la biblioteca de medios

Dicho lo anterior, para que te sea más fácil decidirte, te ordeno los plugins bajo este criterio, así sabes por dónde te andas.

Plugins que usan el sistema de carpetas virtuales

Son la mayoría, y funcionan a base de taxonomía personalizada para adjuntos.

FileBird

El más popular con diferencia, con más de 200.000 instalaciones activas en WordPress.org. Tiene versión gratuita generosa (carpetas ilimitadas, drag and drop, búsqueda) y Pro desde 25 USD con licencia de por vida para un sitio.

Importa la estructura de prácticamente todos los demás, es compatible con Elementor, Divi, Gutenberg, WPBakery, WooCommerce, WPML y Polylang.

Tiene un punto débil, y es que en los últimos años se le han reportado y parcheado varias vulnerabilidades de seguridad, así que mantenlo actualizado siempre.

HappyFiles (Pro)

Este es de lo más limpio y rápido del mercado, pero retiró la versión gratuita en 2022 y actualmente solo se vende Pro a 59 USD de pago único para sitios ilimitados, con devolución de 60 días.

La gran ventaja sobre los demás es que organiza también entradas, páginas, productos de WooCommerce y cualquier tipo de contenido personalizado, no solo medios, así que si vas a tener carpetas para todo el escritorio, este es el que tiene más sentido.

Folders

También está gratis en WordPress.org  y tiene versión Pro de pago. Organiza medios, páginas y entradas, importa desde FileBird, Real Media Library, WP Media Folder, HappyFiles y otros.

Tiene una interfaz sencilla, buen punto de entrada para quien empieza.

Real Media Library (Lite)

Tiene versión Lite gratis con carpetas principales ilimitadas, y Pro desde 17 USD que añade subcarpetas, accesos directos en varias carpetas a la vez y más.

Es de los plugins mejor mantenidos del grupo y la curiosidad es que es un modelo mixto, porque su versión básica es virtual, pero si necesitas carpetas reales tiene una extensión que sí las mueve (lo vemos en la siguiente familia).

CatFolders

El recién llegado al sector, con una interfaz moderna, rendimiento decente, buen ajuste con Gutenberg. Va ganando cuota poco a poco.

Si te gusta probar lo nuevo o no te han convencido los otros plugins échale un ojo.

Plugins que usan el sistema de carpetas físicas

Si prefieres tener todo organizado como en tu ordenador, en directorios de verdad, estos son los que merece la pena probar.

WP Media Folder

Funciona por defecto con carpetas virtuales, pero en sus ajustes hay una opción que se llama justamente «Physical Folders» que las convierte en reales.

El propio fabricante avisa en su documentación de que activarla es delicado, porque desactiva algunas funciones del propio plugin y porque la migración toca muchas tablas.

Es el plugin más caro de la lista (desde 69 USD anuales con add-ons), pero también el único que integra sincronización con Google Drive, Dropbox, OneDrive y S3 de serie.

Real Media Library + Real Physical Media

Instalas Real Media Library de antes, para tener el árbol de carpetas, y encima la extensión Real Physical Media reflejada esa estructura en el servidor.

Cuando mueves un archivo se mueve de verdad, físicamente, con redirecciones 301 automáticas para que nada quede roto. Tiene cola en segundo plano para no tumbar el servidor con muchos archivos.

Es la opción más profesional para quien quiere de verdad carpetas físicas con SEO bien resuelto.

Media Library Folders

Este plugin de Max Foundry esta disponible gratis en WordPress.org y con versión Pro. Crea carpetas reales en el servidor desde el primer momento.

No hay modo virtual ni nada que activar, las carpetas que ves son carpetas de verdad, y lo bueno es la simplicidad conceptual, pues lo que ves es lo que hay.

Lo malo es que para sitios grandes con muchos enlaces internos a imágenes, la reorganización inicial puede ser dura.

Comparativa rápida

¿Y no se puede hacer algo sin plugins? ¡Taxonomías al rescate!

WordPress permite asignar taxonomías a los adjuntos, por si no lo sabías. Es en realidad lo mismo que usan por dentro casi todos los plugins virtuales.

Así que si te animas te olvidas de los plugins, y con unas líneas de código puedes registrar una taxonomía «carpeta» y empezar a clasificar tus imágenes desde la propia ficha de cada archivo.

Ya te aviso antes de empezar que esto no te va a dar interfaz de arrastrar y soltar, ni árbol de carpetas en la biblioteca. Lo que te ofrece son categorías que puedes asignar a cada imagen una a una, y filtros para luego encontrarlas y mostrarlas.

Si tienes la biblioteca a base de cientos de archivos y quieres organización rápida con clics, esto no es lo que necesitas, pero si lo tuyo es bibliotecas pequeñas o eres desarrollador y prefieres no depender de un plugin más, te sirve más que de sobra.

<?php
/**
* Plugin Name: Carpetas para organizar la biblioteca de medios
* Plugin URI: https://servicios.ayudawp.com
* Description: Organización ligera y todo con funciones nativas para crear y organizar medios usando carpetas mediante una taxonomía personanlizada.
* Version: 1.0
* Author: Fernando Tellado
* Author URI: https://tellado.es
* License: GPL-2.0-or-later
* Text Domain: ayudawp
*/

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

/**
* Registro de la taxonomía media_folder para los adjuntos.
*/
function ayudawp_register_media_folders_taxonomy() {

$labels = array(
'name' => 'Carpetas de medios',
'singular_name' => 'Carpeta de medios',
'search_items' => 'Buscar carpetas',
'all_items' => 'Todas las carpetas',
'parent_item' => 'Carpeta principal',
'parent_item_colon' => 'Carpeta principal:',
'edit_item' => 'Editar carpeta',
'update_item' => 'Actualizar carpeta',
'add_new_item' => 'Añadir nueva carpeta',
'new_item_name' => 'Nombre de la nueva carpeta',
'menu_name' => 'Carpetas',
);

$args = array(
'hierarchical' => true,
'labels' => $labels,
'public' => true,
'publicly_queryable' => false,
'show_ui' => true,
'show_in_menu' => true,
'show_admin_column' => true,
'show_in_rest' => true,
'query_var' => true,
'rewrite' => false,
);

register_taxonomy( 'media_folder', array( 'attachment' ), $args );
}
add_action( 'init', 'ayudawp_register_media_folders_taxonomy' );

/**
* Reemplazar la entrada de texto por defecto para media_folder en la pantalla de edición de adjuntos
* y la ventana emergente de medios con un menú desplegable.
*
* Usamos los slugs de los términos como valores de opción porque el núcleo de WordPress procesa
* las taxonomías de adjuntos como cadenas separadas por comas después de que se ejecute este filtro.
* Si pasamos IDs numéricos de términos, el núcleo intentará encontrar un slug que coincida con ese
* número y, si falla eso, crear un nuevo término con ese nombre.
*/
function ayudawp_replace_folder_field_in_modal( $form_fields, $post ) {

$taxonomy = 'media_folder';

if ( ! isset( $form_fields[ $taxonomy ] ) ) {
return $form_fields;
}

$terms = get_terms(
array(
'taxonomy' => $taxonomy,
'hide_empty' => false,
'orderby' => 'name',
'order' => 'ASC',
)
);

if ( is_wp_error( $terms ) || empty( $terms ) ) {
$form_fields[ $taxonomy ]['input'] = 'html';
$form_fields[ $taxonomy ]['html'] = '<em>Primero crea carpetas en Medios &gt; Carpetas.</em>';
return $form_fields;
}

$assigned = wp_get_object_terms( $post->ID, $taxonomy, array( 'fields' => 'slugs' ) );
$assigned = is_wp_error( $assigned ) ? array() : $assigned;

$name = 'attachments[' . absint( $post->ID ) . '][' . $taxonomy . ']';
$id = 'attachments-' . absint( $post->ID ) . '-' . $taxonomy;

$html = '<select name="' . esc_attr( $name ) . '" id="' . esc_attr( $id ) . '" style="min-width:200px;">';
$html .= '<option value="">(none)</option>';

foreach ( $terms as $term ) {
$selected = in_array( $term->slug, $assigned, true ) ? ' selected' : '';
$html .= '<option value="' . esc_attr( $term->slug ) . '"' . $selected . '>' . esc_html( $term->name ) . '</option>';
}

$html .= '</select>';

$form_fields[ $taxonomy ]['input'] = 'html';
$form_fields[ $taxonomy ]['html'] = $html;

return $form_fields;
}
add_filter( 'attachment_fields_to_edit', 'ayudawp_replace_folder_field_in_modal', 20, 2 );

/**
* Añade un menú desplegable de filtro de carpetas a la vista de lista de la biblioteca de medios.
*/
function ayudawp_add_folder_filter_to_media_list( $post_type ) {

if ( 'attachment' !== $post_type ) {
return;
}

$taxonomy = 'media_folder';
$terms = get_terms(
array(
'taxonomy' => $taxonomy,
'hide_empty' => false,
)
);

if ( is_wp_error( $terms ) || empty( $terms ) ) {
return;
}

$current = isset( $_GET[ $taxonomy ] ) ? sanitize_key( wp_unslash( $_GET[ $taxonomy ] ) ) : '';

echo '<select name="' . esc_attr( $taxonomy ) . '">';
echo '<option value="">Todas las carpetas</option>';

foreach ( $terms as $term ) {
echo '<option value="' . esc_attr( $term->slug ) . '" ' . selected( $current, $term->slug, false ) . '>' . esc_html( $term->name ) . '</option>';
}

echo '</select>';
}
add_action( 'restrict_manage_posts', 'ayudawp_add_folder_filter_to_media_list' );

/**
* Añade un menú desplegable de filtro de carpetas a la vista de cuadrícula de la biblioteca de medios y a la ventana emergente,
* usando wp_add_inline_script adjunto al manejador media-views.
*/
function ayudawp_add_folder_filter_to_grid_view() {

$terms = get_terms(
array(
'taxonomy' => 'media_folder',
'hide_empty' => false,
'orderby' => 'name',
'order' => 'ASC',
)
);

if ( is_wp_error( $terms ) || empty( $terms ) ) {
return;
}

$folders = array();
foreach ( $terms as $term ) {
$folders[] = array(
'slug' => $term->slug,
'name' => $term->name,
);
}

$js = '(function() {
if ( typeof wp === "undefined" || ! wp.media || ! wp.media.view || ! wp.media.view.AttachmentFilters ) {
return;
}
var folders = ' . wp_json_encode( $folders ) . ';
var FolderFilter = wp.media.view.AttachmentFilters.extend({
id: "media-attachment-folder-filter",
createFilters: function() {
var filters = {};
filters.all = {
text: "Todas las carpetas",
props: { media_folder: "" },
priority: 10
};
folders.forEach(function(folder, index) {
filters["folder_" + folder.slug] = {
text: folder.name,
props: { media_folder: folder.slug },
priority: 20 + index
};
});
this.filters = filters;
}
});
var originalCreateToolbar = wp.media.view.AttachmentsBrowser.prototype.createToolbar;
wp.media.view.AttachmentsBrowser.prototype.createToolbar = function() {
originalCreateToolbar.call( this );
this.toolbar.set( "mediaFolderFilter", new FolderFilter({
controller: this.controller,
model: this.collection.props,
priority: -75
}).render() );
};
})();';

wp_add_inline_script( 'media-views', $js );
}
add_action( 'admin_enqueue_scripts', 'ayudawp_add_folder_filter_to_grid_view' );

/**
* Filtra la consulta de adjuntos AJAX para que la vista de cuadrícula y la ventana emergente de medios
* respeten la carpeta seleccionada.
*/
function ayudawp_filter_attachments_query( $args ) {

if ( empty( $_REQUEST['query']['media_folder'] ) ) {
return $args;
}

$slug = sanitize_key( wp_unslash( $_REQUEST['query']['media_folder'] ) );

if ( '' === $slug ) {
return $args;
}

$args['tax_query'] = array(
array(
'taxonomy' => 'media_folder',
'field' => 'slug',
'terms' => $slug,
),
);

return $args;
}
add_filter( 'ajax_query_attachments_args', 'ayudawp_filter_attachments_query' );

Pega este código en un plugin propio o en un mu-plugin, no lo metas en el functions.php del tema porque el día que cambies de tema te quedas sin carpetas y sin selector.

Si lo guardas como /wp-content/mu-plugins/ayudawp-media-folders.php se activa solo, que es lo más cómodo para uso personal.

Al activarlo te encuentras esto:

• En el menú de medios aparece «Carpetas» para crear y gestionar las carpetas como si fueran categorías, con jerarquía padre-hijo incluida.
• En la ficha de edición de cada adjunto sale la caja meta de carpetas a la derecha, con casillas de selección.
• En la ventana emergente de insertar imagen aparece el campo «Carpetas» con un desplegable.
• En el listado de medios en vista de lista hay una columna nueva «Carpeta» y un filtro.
• En la vista de cuadrícula de la biblioteca y en el modal de medios aparece también un filtro de carpetas en la barra de herramientas superior.

Algunas pequeñas limitaciones

• Solo permite una carpeta por archivo en el selector de la ventana emergente. La caja meta de la ficha permite varias por ser de tipo checkbox. Si quieres consistencia ajusta uno de los dos.
• No hay arrastrar y soltar, ni árbol al estilo Finder, esto son selectores y desplegables. Para interfaz más cómoda, plugin al canto.
• El filtro de la vista de cuadrícula aparece también en la ventana emergente de insertar imagen en el editor de entradas y páginas, pues ambos usan el mismo componente de WordPress. Si te molesta en la ventana emergente hay forma de limitarlo solo a la pantalla principal de la biblioteca pero alarga el código.
• Si tienes muchas carpetas (más de veinte o treinta), el desplegable se hace incómodo. Cualquier plugin profesional resuelve esto con un árbol lateral, aquí no lo tienes.

Aun con esas limitaciones, hace su trabajo y te deja la organización guardada en tablas estándar de WordPress (wp_terms, wp_term_taxonomy, wp_term_relationships), sin dependencia de un plugin de terceros que pueda desaparecer mañana.

Si un día decides instalar FileBird o cualquier otro, la mayoría tienen importador de taxonomías estándar y pueden recuperar la organización sin que tengas que reasignar las imágenes a mano.

Y entonces ¿cuál elijo?

Respuesta corta y al grano:

• Si quieres lo más sencillo, gratis y popular: FileBird. Manténlo actualizado siempre por las vulnerabilidades pasadas.
• Si llevas una agencia o varias webs y vas a usar carpetas para entradas, páginas y productos además de medios: HappyFiles.
• Si te importa el SEO de las imágenes, quieres URLs limpias y descriptivas y no te asusta el proceso de migración: Real Media Library con el add-on Real Physical Media.
• Si combinas WordPress con Google Drive, Dropbox o almacenamiento en la nube: WP Media Folder.
• Si quieres carpetas físicas reales sin complicarte con add-ons: Media Library Folders de Max Foundry.
• Si eres desarrollador o prefieres montar tu propio sistema mínimo sin atarte: taxonomía personalizada con el código de arriba.

Sea cual sea tu elección, antes de instalar pregúntate si podrías vivir si esE plugin desaparece mañana. Si la respuesta es que no, estás eligiendo mal, o estás eligiendo bien pero asumiendo el riesgo conscientemente, que también vale.

Y sobre todo, antes de tocar la biblioteca de medios de una web en producción, haz copia de seguridad, y si vas a migrar a carpetas físicas, prueba primero en un staging.

Estas operaciones tocan miles de archivos y registros, y un fallo a mitad puede dejarte la biblioteca con imágenes huérfanas y enlaces rotos en posts antiguos.

No fue un fallo de programación ni una vulnerabilidad clásica de las que se publican en una base de datos y se parchean en dos semanas, fue otra cosa.

Alguien con dinero compró el catálogo entero de plugins de un desarrollador conocido, heredó sus permisos de WordPress.org y subió una actualización envenenada que llegó a cientos de miles de webs como si fuera una mejora más.

Aviso por si te suena lejano, la misma semana cayó otro plugin con 800.000 instalaciones, y un par más al poco tiempo. Esto va a más, y conviene que sepas cómo defenderte.

Los 3 casos que la liaron parda

No es un caso aislado, es un patrón. En muy poco tiempo se descubrieron al menos tres ataques con el mismo guion, aunque el tipo de amenaza fue diferente.

Essential Plugin: el catálogo de plugins comprado en Flippa

Un comprador con perfil en SEO, criptomonedas y marketing de juego online adquirió en Flippa el catálogo completo de Essential Plugin (que antes se llamaba WP Online Support) por una cifra de seis dígitos a principios de 2025.

Eran más de treinta plugins con años de desarrollo legítimo y unas 400.000 instalaciones declaradas entre todos.

El 8 de agosto de 2025, en la versión 2.6.7 de los plugins, el nuevo dueño subió una actualización con un registro de cambios tan inocente que daba pereza leerlo, como tantos otros: «Check compatibility with WordPress version 6.8.2».

Detrás de ese texto venían 191 líneas extra de PHP con una puerta trasera de deserialización, que estuvo durmiente ocho meses.

El 5 de abril de 2026, el atacante activó la puerta trasera desde su servidor (analytics.essentialplugin.com) y las webs infectadas empezaron a servir spam SEO camuflado solo para Googlebot.

Los visitantes humanos veían la web normal, el propietario de la web veía el escritorio normal, pero Google veía una web llena de enlaces a chiringuitos de apuestas.

Patchstack y Anchor Hosting destaparon la liada y el 7 de abril WordPress.org cerró los 31 plugins de golpe.

Smart Slider 3 Pro: el servidor de actualizaciones comprometido

La misma semana el plugin Smart Slider 3 Pro (800.000 instalaciones) cayó por otra vía. Aquí no hubo compra del plugin, pero alguien consiguió acceso al servidor desde el que se distribuyen las actualizaciones premium y metió código malicioso en una versión normal.

El efecto para el usuario final fue el mismo, o sea, instalas una actualización oficial firmada por el autor de siempre y te llevas malware de regalo.

Widget Logic, Countdown Timer Ultimate y los que vendrán

El mismo patrón se ha visto en Widget Logic y Countdown Timer Ultimate, descubiertos en las semanas siguientes, y más que vendrán mientras no se le ponga algún tipo de freno.

El método es demasiado rentable como para que algún joputa no lo repita, porque no necesitas saber explotar una vulnerabilidad, ni buscarla, ni pelearte con un cortafuegos, compras la confianza ya forjada por otro y la usas contra los usuarios.

Cómo lo llaman a esta putada en inglés … y qué es exactamente

En la prensa especializada anglosajona lo llaman supply chain attack (ataque a la cadena de suministro), que no se tú, pero a mi no me dice nada, suena como a tomarse un te macha en una terraza de verano o poco más.

Y ya lo entiendo, que realmente no está mal traído, pues el término viene de la idea de que tu plugin no es solo el código que ves, es también el desarrollador, el repositorio, el servidor de actualizaciones y todos los eslabones intermedios.

Trata de definir que si uno de esos eslabones se corrompe, el código que tú instalas en tu web ya no es el que tú creías que era, aunque venga por el canal oficial.

La diferencia con un ataque tradicional es importante, porque en un ataque clásico los malos buscan un fallo en tu plugin para colarse. Aquí no necesitan buscar nada porque el plugin viene ya envenenado de origen.

La actualización que rompe tu web no es un exploit, es una versión oficial firmada por el autor original, distribuida por WordPress.org, instalada por tu sistema de actualizaciones automáticas como ha hecho mil veces antes. Por eso es tan difícil de parar.

Venga, acepto el nombre, pero a mi me pega más algo como cabronada, plugins envenenados o burra vieja, no se, ya me entiendes, soy más de andar por casa.

Por qué WordPress es el caldo de cultivo perfecto

Esto no pasa solo en WordPress, pero en WordPress pasa con especial facilidad por varias razones que conviene tener claras.

Los plugins se compran y se venden como cualquier otro activo digital

En marketplaces como Flippa puedes encontrar plugins en venta con sus 50.000, 100.000 o 400.000 instalaciones activas.

El comprador, sea quien sea y tenga las intenciones que tenga, hereda el acceso SVN al repositorio de WordPress.org y puede subir actualizaciones desde el minuto uno.

No hay un proceso de revisión del nuevo dueño, ni un aviso público en el escritorio del usuario diciendo «este plugin ha cambiado de manos, revisa antes de actualizar», nada.

Las actualizaciones automáticas funcionan en tu contra cuando esto pasa

Si tienes las activadas las actualizaciones automáticas para todos los plugins, que es la recomendación habitual razonable, recibes la versión envenenada sin enterarte.

De hecho muchos hosting incluso fuerzan las actualizaciones automáticas por defecto, por buena intención, pero aquí te das de bruces contra una putada que pervierte una buena idea original.

WordPress.org no firma el código

Otros ecosistemas como Debian, Microsoft Store o iOS exigen firma criptográfica para que el software que ejecutas pueda comprobarse contra una clave del autor original.

En WordPress eso no existe, si alguien hereda los permisos del autor puede subir lo que quiera sin que nadie compare nada contra nada.

No se tú, llámame loco, pero esto debería revisarse en las directrices del directorio de plugins, no es complicado de implementar, no es algo raro, y nos quitaría de mucho cabronazo malintencionado de estos.

El modelo de negocio del plugin gratuito empuja a vender

Mantener un plugin con miles de instalaciones es caro en tiempo, en soporte y en mantenimiento, y si no monetizas con versión premium ni con servicios llega un momento en el que abandonas o vendes.

Los compradores con intenciones limpias existen, la mayoría lo hacen por ese digno objetivo de ganar dinero lícitamente, pero también están los otros, que prefieren hacerse ricos a tu costa, y sin tu consentimiento.

¿He dicho ya que me cago en todos sus muertos?, por si acaso.

Cómo saber si tu web está infectada con plugins envenenados

Si tienes las actualizaciones automáticas activadas y alguno de los plugins comprometidos estaba instalado entre agosto de 2025 y abril de 2026, posiblemente tu sitio sirvió contenido manipulado durante un tiempo.

Estos son los indicadores que tienes que mirar ahora mismo.

Busca en wp-config.php

La puerta trasera de Essential Plugin se inyectaba en wp-config.php justo en la misma línea que el require_once ABSPATH . 'wp-settings.php';.

No estaba en una línea aparte, en la misma, para que sea fácil pasarlo por alto si revisas el archivo a ojo.

Abre tu wp-config.php por SFTP o desde el gestor de archivos del hosting y busca esa línea. Si ves cualquier cosa pegada a continuación o el archivo es notablemente más grande de lo normal (la inyección añade unos 6 KB), tienes un problema.

Busca el archivo wp-comments-posts.php

El payload activado creaba un archivo llamado wp-comments-posts.php en la raíz del WordPress. Si lo ves ahí no es tuyo, no es de una instalación normal, WordPress no tiene ningún archivo con ese nombre por defecto.

Revisa el listado de plugins cerrados

Entra en tu listado de plugins instalados, abre los detalles de cada uno y mira si aparece el aviso de «cerrado», o algo más claro en la página del plugin, pero tampoco para tirar cohetes.

Si lo ves lo desinstalas inmediatamente, no lo dejes ahí «por si lo reabren» o «por si arreglan algo». Los archivos siguen ejecutándose mientras estén ahí, aunque el plugin esté desactivado en WordPress.

Plugins de Essential Plugin

Si no recuerdas todos los plugins que tienes (o tenías), la lista completa de los 31 plugins de Essential Plugin afectados la mantienen actualizada en el análisis de Anchor Hosting.

Compara con tu lista de plugins instalados, incluso si están desactivados.

Mira los logs de Cloudflare o del hosting

Si tienes Cloudflare o cualquier CDN delante, revisa el tráfico saliente hacia analytics.essentialplugin.com en los últimos meses.

Si tu hosting te deja acceder a los logs de salida (no todos lo hacen), busca peticiones a ese dominio, es un indicador casi infalible.

Cómo te defiendes para el próximo ataque

Porque va a haber uno, no te quepa duda. La defensa contra este tipo de ataques no es una sola medida, son varias capas que tienen que trabajar juntas, te las cuento por orden de prioridad.

Detección de plugins cerrados

Cuando WordPress.org cierra un plugin (por vulnerabilidad grave, por código malicioso o por incumplir las normas del repositorio), no te avisa de manera clara.

Se marca el aviso en el listado de plugins, pero si no entras a esa pantalla a diario y miras los detalles de los plugins, te puedes pasar semanas con el plugin comprometido instalado sin enterarte. Esto es lo primero que tienes que automatizar.

Dos opciones para esto, estas:

• Wordfence detecta plugins cerrados y abandonados desde 2017. Es la opción más conocida, pero lo hace dentro de su escaneo de malware general, que la gente programa cada semana. Si el plugin se cierra el lunes y tu escaneo es el viernes, tienes cuatro días de margen.
• El plugin Vigilante tiene esta función, con un par de detalles que ayudan bastante. Por un lado, lanza una consulta diaria a la API de WordPress.org para cada plugin instalado (activado o no) y avisa el mismo día con un email crítico. Por otro, recuerda qué plugins estaban vivos antes, y si la API empieza a devolver 404 para un plugin que ayer respondía, lo trata como cierre con la misma gravedad que un cierre explícito (algunos cierres por motivos graves esconden la metadata del plugin entera, y si solo miras lo que devuelve la API te lo puedes perder). Además, los plugins cerrados aparecen en el escritorio como recomendación crítica con enlace directo, en la auditoría de seguridad como evento, y se siguen mostrando en cada email de resumen hasta que los desinstalas o los marcas como ignorados de forma explícita.

Cualquiera de las dos opciones es mejor que nada. Si ya tienes Wordfence lo dejas, si quieres detección más rápida y dedicada o no quieres meter Wordfence por su peso prueba con Vigilante.

Integridad de archivos

La inyección de la puerta trasera cambia archivos en el plugin y a veces en el wp-config.php. Un escáner de integridad de archivos que compare lo que hay en tu instalación con las sumas de comprobación oficiales de WordPress.org detecta cambios sospechosos.

Esto lo hacen Kadence Security, Vigilante y otros. Lo activas, lo programas cada día, y recibes un email cuando hay un archivo modificado que no esperabas. El truco está en no ignorar los avisos.

Cuando WordPress se actualiza, también te llegan avisos de archivos modificados (porque efectivamente se modifican), y la mayoría de nosotros nos acostumbramos a marcarlos como leídos sin mirar, y no, no lo hagas.

Si un email te avisa de cambios en plugins que no has actualizado, abre y mira.

Auditoría y registro de actividad

Tener un registro que te diga quién instala, activa, actualiza o desactiva plugins en tu web es un seguro barato, de hecho gratis.

Si alguien con acceso al admin de WordPress mete un plugin envenenado o activa uno que ya estaba desactivado queda registrado.

Lo incluyen casi todos los plugins de seguridad medianamente serios (como Vigilante), y sino también hay plugins específicos que son solo para esto.

Actualizaciones automáticas selectivas

Aquí va a ir contra lo que has leído mil veces, pero hay matices, porque sí, las actualizaciones automáticas son buena idea para plugins pequeños y/o bien mantenidos, especialmente si no son críticos para tu negocio.

Pero para plugins que tocan dinero o datos sensibles (WooCommerce, pasarelas de pago, formularios que recogen tarjetas, plugins de membresía, plugins de email transaccional) la actualización automática es una muy mala idea.

Te bajas la actualización a staging, miras el registro de cambios, esperas 48 horas a ver si alguien grita en los foros, y entonces actualizas a producción.

El caso Essential Plugin se distribuyó precisamente gracias a las actualizaciones automáticas. Quien las tenía desactivadas y revisaba los registros de cambios se salvó, aunque fuese por suerte o casualidad.

Protegiendo la comarca

Afortunadamente, el 5 de junio, coincidiendo con WordCamp Europe, se anunció que WordPress está poniendo en la nevera las actualizaciones de plugins durante 24 horas, para precisamente evitar cosas como lo que estamos hablando, para dar tiempo al equipo de plugins a revisar todas las actualizaciones, por supuesto ayudados de una IA especializada, a la que han llamado Gandalf, para que tenga de todo.

De momento son eso, 24 horas de espera, pero se irán reduciendo los tiempos a medida que se mejore el sistema.

Es una buenísima noticia, sí, pero no exime a nadie de responsabilidades, tampoco a ti.

Lo que no hace ningún plugin por ti

Ningún plugin de seguridad te salva de todo, hay cosas que tienes que hacer tú, con tu equipo o contratando a alguien que se ocupe por ti, y no hay automatización que las sustituya.

Revisar el registro de cambios antes de actualizar plugins críticos es una de ellas. Un changelog que dice «Check compatibility with WordPress version 6.8.2» y la actualización pesa 6 KB más, debería levantarte la ceja. No siempre se nota tan claro, pero a veces sí, y conviene mirar.

Suscribirte a feeds de bases de datos de vulnerabilidades es otra. Patchstack, WPScan y Wordfence Intelligence publican avisos a diario. No necesitas leerlos todos, pero suscribirte a sus newsletters semanales te da una visión general del panorama sin esfuerzo.

Seguir el foro de soporte de los plugins que usas en webs importantes también ayuda. Si un plugin con muchas instalaciones se ha vuelto raro, los foros se llenan de quejas a las pocas horas, y tener cinco o seis plugins críticos en favoritos del foro de WordPress.org no cuesta nada.

Desconfiar de cualquier plugin que cambie de dueño y desinstalarlo si puedes vivir sin él es la medida más radical, pero también la más segura. Si te enteras de que un plugin que usas ha sido vendido te tomas un par de horas para evaluar alternativas y mantenerte preparado por si la cosa va mal. No siempre va mal, pero cuando va ya no hay tiempo.

Y mantener backups, sí, otra vez. Copias de seguridad de verdad, fuera de tu servidor, probados, recientes y restaurables en menos de una hora.

Si te ha pasado lo de Essential Plugin y no quieres pelearte con la limpieza, lo más rápido suele ser restaurar a antes de la infección y aplicar lo aprendido para no caer otra vez.

Lista de tareas para ya

Si has llegado hasta aquí, dedica un rato hoy mismo a hacer esto. No te lleva más de una hora, dependiendo del tamaño de tu web.

• Revisa el listado de plugins instalados (incluso los desactivados) y comprueba si aparece alguno con el aviso de «cerrado». Si lo hay, desinstálalo.
• Cruza tu listado contra el de lo 31 plugins de Essential Plugin del enlace de Anchor Hosting que te he puesto más arriba. Si te coincide alguno, asume que tu web estuvo comprometida y empieza la limpieza desde wp-config.php.
• Abre tu wp-config.php por SFTP y busca código extraño junto a la línea de require_once ABSPATH . 'wp-settings.php';. Si lo ves, restaura el archivo desde un backup limpio.
• Comprueba si existe un archivo wp-comments-posts.php en la raíz de tu WordPress. Si está lo borras sin piedad.
• Instala y activa un plugin de seguridad que tenga detector de plugins cerrados. Wordfence o Vigilante, el que prefieras.
• Activa el escáner de integridad de archivos con email diario del plugin de seguridad, y si no tiene esa herramienta cambia de plugin de seguridad.
• Activa también la auditoría de registro de actividad para saber quién toca qué.
• Desactiva las actualizaciones automáticas en los plugins que tocan dinero o datos sensibles. Planifica un proceso manual de revisión semanal.
• Suscríbete al boletín de Patchstack o Wordfence Intelligence. Cinco minutos a la semana leyendo te ahorra muchos disgustos.
• Si gestionas webs de clientes, comprueba estos mismos puntos en todas las que mantienes. Si tienes diez webs, una hora por web es un día de trabajo bien invertido.

Lo del software libre que confías a desconocidos por defecto va a seguir pasando.

Mientras WordPress.org no obligue a firmar el código y a auditar las transferencias de propiedad (que no parece que vaya a pasar pronto), la mejor defensa eres tú.

Aplícate al cuento, sigue estos consejos que te he dado, no pasa nada por ser un poco paranoico con los plugins críticos, dormirás más tranquilo, es mucho peor ser confiado con las cosas del comer.

Pues bien, ahora tengo que decirte algo que incluso me cuesta un poquito, y es que la mayoría de lo que hacen los plugins de SEO ya no te sirve de nada.

No es que sean malos plugins, algunos son muy buenos, el problema es que fueron diseñados para un mundo donde Google mostraba diez enlaces azules y tú competías por estar entre los tres primeros, ese mundo se está acabando.

Las AI Overviews responden directamente en la página de resultados, ChatGPT y Perplexity dan respuestas sin que nadie visite tu web, y el tráfico orgánico lleva meses cayendo en casi todos los sectores. Se le ha llamado el gran desacoplamiento, y si aún no lo has notado en tu Search Console dale tiempo.

La pregunta que hay que hacerse no es si tu plugin de SEO funciona bien, la pregunta es si lo que hace tu plugin de SEO sigue siendo relevante.

Vamos a repasar función por función, sin ánimo de hacer leña de nadie, pero también sin andarme con jilipolleces o medias tintas.

Las funciones de los plugins de SEO que ya no pintan (casi) nada

Vamos a ver juntos, funcionalidad a funcionalidad (casi todas) las herramientas que ofrecen los plugins de SEO que a día de hoy tiene poco o ningún sentido utilizar.

Focus keyword y densidad de keywords

Qué te ofrecen

Escribes una «palabra clave objetivo» y el plugin analiza tu contenido para decirte si la has usado suficientes veces, si aparece en el título, en el primer párrafo, en algún H2, en el texto alternativo de una imagen.

Es una de las funciones más reconocibles de cualquier plugin de SEO, es la base de los famosos semáforos.

Por qué ya no tiene sentido

Los motores de búsqueda con IA no cuentan cuántas veces aparece una palabra en tu texto, entienden de qué va tu contenido por contexto semántico. Puedes escribir un artículo completo sobre «cómo migrar WordPress a otro hosting» sin usar esa frase exacta ni una sola vez, y tanto Google como ChatGPT van a entender perfectamente de qué hablas.

La keyword density fue una métrica útil cuando los algoritmos de búsqueda eran básicos y necesitaban pistas explícitas. Los LLMs (modelos grandes de lenguaje) procesan el significado, no la repetición. De hecho, un texto donde se fuerza la keyword suena peor, se lee peor y probablemente la IA lo descarte antes que uno escrito con naturalidad.

El concepto mismo de «optimizar para una keyword» se ha quedado viejo. Ahora se trata de responder a una intención, de cubrir un tema con profundidad, y eso no se mide contando palabras.

¿Sirve aún de algo?

Como recordatorio de que tu contenido debe tener un enfoque claro, sí, como herramienta de optimización real, no.

Si necesitas un plugin para saber si tu artículo trata sobre lo que se supone que trata, el problema no es de SEO, es de redacción.

Plantillas de title y description

Qué te ofrecen

Patrones automáticos para generar el title tag de tus entradas y páginas: %%title%% | %%sitename%%, %%title%% - %%category%% | %%sitename%%, etc.

Por qué ya no tiene sentido

La meta tag title sigue existiendo y Google sigue usándolo, pero cada vez lo reescribe más. Google modifica la tag title en más del 60% de los resultados de búsqueda, y para las IAs que procesan tu contenido el title es un dato más dentro de la página, no la señal principal que determina si te van a citar o no.

La idea de que un patrón como «Keyword | Marca» te daba ventaja competitiva ya no se sostiene. Lo que importa es que el título sea descriptivo y realista, y eso lo puedes escribir tú directamente en WordPress sin plantillas de por medio.

¿Sirve aún de algo?

Para sitios grandes con cientos o miles de páginas donde poner títulos coherentes a mano sería inviable (tiendas online, directorios) las plantillas siguen siendo prácticas. Para un blog o web de contenidos donde escribes cada título individualmente no aportan nada.

Yo mismo hace más de 2 años que no lo uso.

Optimización de title y description

Qué te ofrecen

Un campo para escribir las metas title y description de cada entrada y página, con un contador de caracteres y sugerencias para hacerlas atractivas y que el usuario haga clic en tu resultado.

Por qué ya no tiene sentido

Dos razones principalmente.

La primera es que Google reescribe los title y description cuando le da la gana, y cada vez lo hace con más frecuencia. Ignora las que tú escribes más de la mitad de las veces y genera otras a partir del título y contenido de la página, así que gran parte del tiempo estás escribiendo para nadie.

La segunda, más gorda, pues resulta que si una AI Overview responde a la búsqueda directamente, el usuario ni siquiera llega a ver tu snippet. No hay clic que optimizar si no hay resultado que mostrar, tu title y tu meta description perfectamente redactadas se quedab ahí, invisibles, mientras la IA le da al usuario lo que busca sin que puedas hacer nada ni por impedirlo ni por modificar ese resultado.

¿Sirve aún de algo?

Para las búsquedas donde aún no aparecen AI Overviews (que todavía las hay, más en español) siguen teniendo cierta utilidad. Pero el tiempo que dedicas a escribir etiquetas title y  meta descriptions personalizadas para cada artículo tiene un retorno cada vez menor.

Si escribes mucho contenido probablemente no merece la pena hacerlo a mano para cada entrada. Un título de tu publicación bien elegido y una meta description decente generada automáticamente a partir de tu extracto o primer párrafo, sobre todo si los defines conscientemente de su valor, suelen ser más que suficiente.

Puntuaciones de legibilidad

Qué te ofrecen

Análisis del texto con métricas tipo Flesch-Kincaid, que miden la longitud de frases, uso de voces pasivas, variedad de conectores, complejidad de vocabulario, etc. El típico semáforo que te dice si tu texto es «fácil de leer» o no.

Por qué ya no tiene sentido

Estas puntuaciones miden la legibilidad mecánica no la calidad del contenido. Un artículo técnico sobre configuración de servidores puede tener frases largas y vocabulario especializado y ser exactamente lo que tanto un lector experto como una IA necesitan.

La IA no penaliza las frases largas, la IA no busca textos «fáciles» busca textos que respondan bien a una pregunta, con autoridad y precisión.

Además, estas métricas de legibilidad se diseñaron para textos educativos en inglés. Su aplicación al español siempre ha sido discutible, y en el contexto de optimización para IAs es directamente irrelevante.

¿Sirve aún de algo?

Escribir claro siempre es buena idea pero no necesitas un plugin que te ponga un semáforo para eso. Si llevas tiempo escribiendo en la web ya sabes cuándo un párrafo es demasiado denso. Fíate más de tu criterio y de la respuesta de tus lectores que de una fórmula matemática pensada para otro idioma y otra época.

Mapas del sitio XML de los plugins SEO

Qué te ofrecen

Generación de sitemaps XML personalizados, con opciones para incluir o excluir tipos de contenido, establecer prioridades y frecuencias de actualización.

Por qué ya no tiene sentido

WordPress genera mapas del sitio nativos desde la versión 5.5. Funcionan bien, Google los lee sin problemas y, lo más importante ahora, los bots de IA también los devoran. Si miras los logs de tu servidor con VigIA verás que los crawlers de ChatGPT, Claude, Perplexity y compañía van directos a tu sitemap para saber qué contenido tienes y por dónde empezar a rastrear.

Los plugins de SEO lo primero que hacen es desactivar los sitemaps nativos de WordPress y sustituirlos por los suyos. ¿Por qué?, pues porque así te crean una dependencia, para que si desactivas el plugin te quedes sin mapa del sitio (en teoría).

Para la inmensa mayoría de sitios WordPress el mapa del sitio nativo de WordPress es más que suficiente.

¿Sirve aún de algo?

Si necesitas personalizar el mapa del sitio que ya crea WordPress (excluir ciertas taxonomías, ajustar qué se incluye, añadir tipos de contenido personalizados), puedes hacerlo sin un plugin de SEO enorme. Native Sitemap Customizer te permite configurar los sitemaps nativos de WordPress sin desactivarlos ni sustituirlos por otros, que es justo lo que tiene sentido ahora que los bots de IA dependen tanto de ellos.

Editor de robots.txt

Qué te ofrecen

Una interfaz para editar el archivo robots.txt desde el panel de WordPress, con reglas para permitir o bloquear el acceso de bots a distintas partes de tu sitio.

Por qué ya no nunca tiene sentido

WordPress genera un robots.txt virtual (accesible en /?robots=1) que para la mayoría de sitios es suficiente. Los plugins de SEO te ofrecen un editor gráfico que parece más complejo de lo necesario, pero sobre todo es que ¡es un puñetero archivo de texto!.

Estoy aún esperando que alguien me explique qué sentido tiene usar un plugin para algo que no cambia a diario, ni todas las semanas, ni todos los meses, algo que normalmente configuras una vez y lo repasas cada mucho tiempo.

Pero la cosa es aún peor, porque hay plugins de SEO que, ahora, tratan de justificar su inclusión bajo el pretexto de que así puedes bloquear a los bots de IA que no quieras, a GPTBot, ClaudeBot, PerplexityBot, Bytespider, CCBot y otros crawlers de IA.

Pues no, resulta que los disallow en el robots.txt son meramente declarativos, y no es que los bots de IA no los hagan caso, es que ni Google los tiene en cuenta.

¿No te lo crees? Instala y activa VigIA, dale a bloquear mediante robots.txt a cualquier rastreador, vas a descubrir (también tiene una utilidad para ver eso) que pasan totalmente, que lo único que los detiene es bloquearlos mediante PHP.

¿Sirve aún de algo?

El editor en sí es una comodidad menor, para algo que no hace falta. Lo que de verdad necesitas es informarte sobre qué crawlers de IA existen y cuáles quieres permitir, y eso es una decisión estratégica que ningún plugin puede tomar por ti. Un simple fichero robots.txt editado a mano o con un plugin ligero cubre cualquier necesidad que pienses que necesitas más que de sobra.

Etiquetas canónicas

Qué te ofrecen

Gestión automática de la etiqueta rel="canonical" para evitar problemas de contenido duplicado, con opción de personalizar la URL canónica de cada entrada.

Por qué ya no tiene sentido

WordPress genera etiquetas canónicas de forma nativa desde casi siempre y para el 90% de los sitios la canónica automática que pone WordPress es correcta. Los casos donde necesitas personalizar la canónica manualmente (contenido sindicado, variaciones de URL con parámetros, contenido duplicado entre dominios) son bastante específicos y no justifican un plugin de SEO completo.

Además, a los LLMs la etiqueta canónica les da bastante igual. Procesan el contenido que encuentran, no las instrucciones de indexación pensadas para Googlebot.

¿Sirve aún de algo?

Si tienes un sitio con problemas reales de contenido duplicado (tienda con productos en varias categorías, contenido publicado en varios dominios), sí puede ser útil. Para un blog o web de contenidos normal, lo que hace WordPress solo es suficiente.

Meta tags para redes sociales (Open Graph, Twitter Cards)

Qué te ofrecen

Generación automática de las etiquetas Open Graph y Twitter Cards para que cuando alguien comparta tu contenido en redes sociales aparezca con título, descripción e imagen correctos.

Por qué ya no tiene sentido

El tráfico desde redes sociales también va en caída libre para la mayoría de webs, nos empeñamos, pero la realidad es que la gente lee lo que pones en su red, y raramente visitan tu web para saber más que lo que les ofrece el titular, ¿no te has dado cuenta de que la gente comenta tus contenidos en sus redes, no en tu web?

Facebook reduce el alcance orgánico cada trimestre, Twitter/X es un caos algorítmico, y las plataformas donde sí se comparte contenido (LinkedIn, Threads) cada vez priorizan más el contenido nativo sobre los enlaces externos.

Que tu enlace se vea bonito cuando alguien lo comparte está bien, pero el impacto real en tráfico es mínimo para la mayoría de sitios.

¿Sirve aún de algo?

Si las redes sociales son una fuente de tráfico importante para ti sí merece la pena tenerlo. Pero muchos temas WordPress ya generan Open Graph básico sin necesidad de un plugin de SEO aparte.

Y si no compartes activamente en redes o tu audiencia no llega por ahí, es una función que ocupa espacio en tu base de datos, aumentan el peso de tu HTML y no te aporta nada.

Marcado Schema automático

Qué te ofrecen

Generación automática de datos estructurados (Schema.org) para artículos, páginas, breadcrumbs, organización, autor, etc. Los plugins más avanzados añaden tipos como FAQ, HowTo, productos, recetas, eventos.

Por qué ya no tiene sentido

Bueno, esta función sí tiene sentido, pero no como la implementan la mayoría de plugins de SEO por un par de motivos, a saber:

1. El Schema que añaden por defecto (Article, BreadcrumbList, Organization) es tan básico que apenas aporta diferenciación. Google ya es capaz de entender que un artículo es un artículo sin que se lo digas con JSON-LD.
2. El Schema que de verdad te puede ayudar a aparecer en AI Overviews y en respuestas de IAs (FAQ, HowTo, datos de producto con precio e inventario, reseñas con puntuación, datos con fuentes citadas) requiere un trabajo manual y específico que los plugins de SEO automatizan mal o directamente no ofrecen en sus versiones gratuitas.

¿Sirve aún de algo?

Los datos estructurados siguen siendo importantes, quizá más que nunca, pero la forma de implementarlos tiene que cambiar.

Necesitas JSON-LD bien pensado y específico para tu contenido, no el Schema genérico que un plugin genera automáticamente para todos tus artículos o páginas.

Los tipos de datos que interesan a las IAs son los que aportan información práctica verificable, como precios, fechas, pasos de un proceso, respuestas a preguntas concretas.

Auditorías y puntuaciones SEO

Qué te ofrecen

Un panel con una puntuación global de tu SEO, alertas sobre «problemas» (entradas sin meta description, títulos demasiado largos, imágenes sin texto alternativo, enlaces rotos) y recomendaciones para mejorar.

Por qué ya no tiene sentido

Estas auditorías miden lo que era importante en 2018. Te dicen que tienes 47 entradas sin meta description y tú sales corriendo a escribirlas todas, pero ninguna de esas métricas tiene correlación con que aparezcas o no en una AI Overview, ni con que ChatGPT te cite como fuente.

Que sí, que nos seguimos empeñando, que los hábitos no se curan en unos meses, pero en serio, pasa ya de eso, no sirve de nada, solo te hace perder tiempo y vida.

Lo que no te dice ninguna auditoría de plugin SEO:

• Si los bots de IA están rastreando tu sitio (y cuáles).
• Si tu contenido aparece citado en respuestas de IAs.
• Si tu Schema es el adecuado para los formatos de respuesta de AI Overviews.
• Si tu sitemap está siendo consumido correctamente por los crawlers de IA.
• Si la estructura de tu contenido facilita que una IA extraiga una respuesta directa.

Básicamente, te auditan para un juego que se está terminando y te ignoran el que está empezando.

¿Sirve aún de algo?

Como lista de revisión de higiene técnica básica, como imágenes sin alt, enlaces rotos o títulos duplicados sigue siendo útil, pero no necesitas un plugin de SEO para eso.

Hay plugins específicos más ligeros para cada una de esas tareas, y la mayoría se pueden comprobar con herramientas externas gratuitas.

SEO automático con IA integrada en el plugin

Qué te ofrecen

Los plugins de SEO más recientes han añadido funciones de IA para generar metas, títulos, esquemas de contenido e incluso artículos completos desde el propio editor de WordPress.

Por qué ya no tiene sentido

Aquí la cosa tiene miga, porque usar una IA para generar contenido que luego va a ser evaluado por otra IA es, como mínimo, un círculo un poco absurdo. Pero el problema no es ese, que también, hay más, lo peor.

El problema es que estas funciones de IA integradas en plugins de SEO son básicamente un formulario de conexión para la API de OpenAI o de otro proveedor, con un prompt predefinido.

Hacen lo mismo que podrías hacer directamente en ChatGPT, Claude o cualquier otro asistente, pero con menos control y normalmente con un coste adicional (créditos de IA incluidos en el plan premium del plugin).

Además, el contenido generado masivamente por IA sin edición humana es exactamente el tipo de contenido que Google está penalizando y que las IAs van a ignorar como fuente.

Si generas 50 artículos con la IA de tu plugin de SEO y los publicas tal cual, no estás haciendo SEO, estás haciendo ruido, publicando basura y tratando de engañar a los algoritmos (imposible) y a tus lectores (imperdonable).

¿Sirve aún de algo?

Como ayuda puntual para generar borradores o ideas sí, pero para eso ya tienes herramientas de IA dedicadas que son mucho más potentes y flexibles.

Pagar un plan premium de un plugin de SEO para acceder a una IA limitada no tiene ningún sentido cuando puedes usar directamente cualquier LLM con prompts bien hechos.

Sugerencias de enlazado interno

Qué te ofrecen

Análisis de tu contenido para sugerirte enlaces internos a otras entradas relacionadas, normalmente basándose en coincidencias de palabras clave encontradas en el texto.

Por qué ya no tiene sentido

El enlazado interno sigue siendo útil para que los usuarios naveguen por tu sitio y que los bots descubran contenido. Eso no ha cambiado, lo que sí ha cambiado es la lógica de estas sugerencias.

Los plugins te sugieren enlazar a posts que contienen la misma keyword, pero las IAs no procesan tu sitio siguiendo enlaces como hacía Googlebot.

Los bots de IA van al mapa del sitio, lo devoran página a página, identifican las URLs que les interesan y rastrean cada una de forma independiente.

El «link juice» que se distribuía por enlaces internos pierde relevancia en un modelo donde el bot no navega tu sitio, se lo descarga prácticamente.

¿Sirve aún de algo?

Para la experiencia del usuario humano enlazar bien sigue siendo una buena práctica, pero las sugerencias automáticas basadas en keywords son demasiado simplistas.

Un buen enlazado interno se hace pensando en el lector, no en un algoritmo, y eso es trabajo editorial que ningún plugin puede sustituir.

Lo que sí tiene sentido ahora (con o sin plugins de SEO)

Después de habernos puesto serios con lo que ya no funciona, sería injusto no hablar de lo que sí marca la diferencia a día de hoy (no sé mañana).

Algunas cosas las puedes hacer con plugins específicos, otras con el propio WordPress, y otras son pura estrategia y redacción.

Mapas del sitio bien configurados

Si hay algo que los bots de IA hacen nada más llegar a tu sitio es ir al Sitemap XML, es su mapa del tesoro, el índice de todo lo que tienes.

Si tu sitemap está inflado con páginas irrelevantes, taxonomías vacías o contenido que no quieres que rastreen, les estás complicando la vida. Igualmente, si olvidas incluir tus mejores contenidos igual ni los descubren, en serio, no pierden el tiempo.

WordPress genera un buen mapa del sitio sin necesidad de plugins, limpio, completo, que no tienes que mantener ni depende de otros. Luego con Native Sitemap Customizer puedes ajustar exactamente qué se incluye y qué no sin necesidad de instalar un plugin de SEO que sustituya el sitemap que ya tienes gratis por el suyo.

Esto es algo que ahora mismo poca gente tiene en cuenta y que tiene un impacto directo en cómo las IAs descubren y priorizan tu contenido.

Monitorizar qué hacen las IAs con tu contenido

¿Cómo sabes si las IAs están rastreando tu sitio, cuáles lo hacen, con qué frecuencia y qué contenido se llevan?

Tu plugin de SEO no te lo dice, Google Analytics tampoco las identifica al detalle, Search Console te cuenta lo de Google, pero no lo de ChatGPT, Claude, Perplexity ni el resto. El único que te muestra algo es Bing.

Para eso necesitas algo como VigIA, que monitoriza los bots de IA que visitan tu WordPress, te muestra cuáles rastrean, cuándo, qué URLs se llevan y cómo se comportan. Es gratis, te da una información valiosísima y muchas herramientas que te ayudan a reforzar tu visibilidad para este nuevo modo en el que ya funciona Internet.

Sin esta información estás completamente a ciegas, es como hacer SEO clásico sin Search Console, impensable. Pues lo mismo, pero para el nuevo escenario.

La cápsula de respuesta

Esto no lo hace ningún plugin, es pura redacción, y es probablemente lo que más impacta en si apareces o no en una AI Overview.

Las IAs generativas, cuando buscan una fuente para responder a una pregunta, tienden a extraer la respuesta de las primeras frases de un contenido que la responda de forma directa y concisa.

Si tu artículo empieza con tres párrafos de contexto antes de ir al grano la IA se va a otro sitio.

La técnica es sencilla, simplemente empieza cada artículo con una respuesta directa a la pregunta que el artículo responde, en las primeras 50 a 70 palabras. Luego desarrolla todo lo que quieras. Esa «cápsula» es lo que la IA puede extraer como respuesta, y es una de las señales que más peso tienen para aparecer en AI Overviews.

E-E-A-T real, no de formulario

Los plugins de SEO te ponen un campo para rellenar el nombre del autor y poco más. Ahora bien, las señales de Experience (Experiencia), Expertise (Especialización), Authoritativeness (Autoridad) y Trustworthiness (Fiabilidad) que Google y las IAs buscan no se configuran en un campo de texto.

Se construyen con contenido que demuestre experiencia real (datos propios, ejemplos de primera mano, capturas de tu propio trabajo), con una presencia de marca coherente en la web, con menciones y citas en otros sitios, con autoría verificable y con un historial de contenido de calidad mantenido en el tiempo.

Ningún plugin te da E-E-A-T, es algo que se gana publicando buen contenido durante años, y eso no hay atajo que lo sustituya.

JSON-LD con intención, no por defecto

Ya he mencionado que el Schema genérico que añaden los plugins de SEO aporta poco.

Lo que sí funciona es implementar JSON-LD específico y pensado para tu contenido, con preguntas frecuentes con respuestas directas, pasos de un proceso con tiempos y herramientas, datos de producto con precio, disponibilidad y valoraciones, información de organización con datos de contacto verificables.

Este tipo de datos estructurados es lo que las IAs pueden interpretar directamente como información basada en hechos y verificable, y lo que marca la diferencia entre ser citado como fuente o ser ignorado.

Gestión de bots de IA

Decidir qué crawlers de IA pueden acceder a tu contenido y cuáles no es una decisión estratégica que ahora mismo los plugins de SEO ni mencionan.

Cada rastreador de IA funciona de manera diferente, y tú tienes que decidir si quieres que rastreen tu contenido (y potencialmente te citen como fuente) o si prefieres bloquearlo.

Esto te dirán que se gestina desde robots.txt, pero es mentira, no sirve de nada, no le hacen ni caso como ya te he comentado. Solo se les puede poner freno desde las cabeceras HTTP de tu web/servidor, si de verdad quieres bloquearlos, no desde un plugin de SEO.

Si quieres hacerlo fácil en VigIA puedes bloquear los que tú decidas a golpe de clic, y además después de haber podido analizar qué rastrean y cómo lo hacen, que es el modo correcto, actuando con información.

Visibilidad ante las IAs

El SEO tradicional medía posiciones en Google, El nuevo SEO, el GEO que le llaman ahora, debería medir si las IAs te conocen, si te citan y si te recomiendan. Esto es lo que llamo visibilidad IA, y es un terreno donde casi todo está por hacer.

Herramientas como VigIA te dan el primer paso (saber qué bots te rastrean), y plugins como AI Share & Summarize te ayudan a facilitar que se compartan tus contenidos y, además, también a medir la interacción real de los usuarios con tu contenido más allá del clic tradicional.

La métrica definitiva de «¿me citan las IAs?» aún está en pañales y es algo que ningún plugin de SEO aborda, y si te dicen que lo hace sospecha, y si te quieren cobrar por ello además te quieren robar.

Entonces, ¿desinstalo mi plugin de SEO?

No necesariamente, pero sí tienes que aplicar sentido común y ser realista sobre qué parte del plugin usas realmente y qué parte es realmente innecesaria.

Si lo único que usas de tu plugin de SEO es el campo de meta description, el semáforo de keywords y la puntuación de legibilidad, pues sí, probablemente puedes quitarlo y no va a pasar nada malo. WordPress hace lo básico solo, y lo que de verdad necesitas ahora no viene de ahí.

Si usas funciones más avanzadas como redirecciones, Schema personalizado o gestión de contenido duplicado en un sitio grande, quizá te compense mantenerlo, pero siendo consciente de que estás usando un 10% de lo que ofrece y el otro 90% es grasa. De hecho, si solo quieres las redirecciones, mejor usa Redirection, es mejor que cualquier herramienta de los plugins de SEO, es gratis, es ligero, es perfecto.

Lo que seguro que no tiene sentido es pagar por un plan premium de un plugin de SEO solo para acceder a la generación de contenido por IA o a funciones de «SEO Score» que miden parámetros que ya no determinan tu visibilidad.

Y, por cierto, igual estás pensando que te estoy hablando de sustituir un solo plugin de SEO por varios plugins, y si no es mejor tener un único plugin que varios, pues no, el problema nunca es la cantidad de plugins, el problema es sobrecargar tu web con código que no necesitas.

Es mejor tener 5 plugins pequeños que cada uno hace lo suyo y bien que un monstruo que carga montones de recursos, scripts y estilos de los que solo sirven de algo un pequeño porcentaje.

El juego ha cambiado y las reglas son otras. La herramienta que necesitas ya no es un plugin que te ponga semáforos en verde, sino una estrategia clara de contenido, datos estructurados bien pensados, sitemaps limpios y la capacidad de saber qué están haciendo las IAs con tu web.

Si quieres profundizar en cómo preparar tu WordPress para este nuevo escenario, te recomiendo empezar por la guía de SEO para IAs generativas y por el artículo sobre cómo posicionar en AI Overviews. Ahí está lo que de verdad te puede ayudar en algo a seguir en el bisnes, tener presencia, existir en Internet.

Para una web grande con flujo editorial, una tienda con productos que se agotan o un sitio con tipos de contenido personalizados, esa información por defecto se queda corta enseguida.

La buena noticia es que se puede personalizar mucho más de lo que parece, y se me ocurren hasta cuatro formas de hacerlo, de la menos invasiva a la más completa, y cada una sirve para un caso distinto. Vamos a verlas todas con código que puedes copiar y pegar.

Antes de empezar: lo que el widget muestra por defecto

Si abres el escritorio de WordPress de cualquier instalación ahí lo tienes, es esa caja que pone «Actividad» y muestra tres bloques bien diferenciados:

• Próximas publicaciones, con las cinco siguientes entradas programadas, ordenadas por fecha de salida.
• Publicaciones recientes, con las cinco últimas entradas que ya están en la web.
• Comentarios recientes, con los últimos cinco recibidos, da igual su estado (aprobados, pendientes, spam).

En una web personal con poco movimiento sirve para hacerse una idea rápida, pero en cuanto tienes un flujo editorial activo varios autores escribiendo o una tienda online, esa información se queda corta, o larga, o no del todo útil, según tu necesidad.

Igual quieres ver solo lo que va a salir esta semana, solo los comentarios pendientes de moderar, los productos que se han quedado sin stock o las entradas que están pendientes de revisión. Cada caso pide algo distinto.

Para personalizarlo te planteo cuatro formas de abordarlo como te decía, de más sencilla a más completa.

La primera solo cambia las entradas que aparecen y se monta con tres líneas, la segunda reescribe el contenido del widget original sin tocar la caja, la tercera quita el widget y mete uno tuyo de cero, y la última un formulario para que el propio usuario lo configure desde el escritorio.

Al final del artículo también verás plugins que hacen lo mismo sin código, por si no te apetece pelearte con el editor de código.

Método 1: Cambiar las entradas que muestra el widget

Si lo único que quieres es ajustar las entradas que aparecen (cambiar el número, ocultar las publicadas o las programadas, incluir productos o páginas, o que cada autor solo vea las suyas), este es el camino más corto.

No reemplazas nada, no tocas el HTML, solo le dices a WordPress qué entradas quieres ver.

Lo hacemos con un filtro que que tiene WordPress desde la versión 4.2 (dashboard_recent_posts_query_args). Pega cualquiera de los siguientes snippets en un mu-plugin o en el functions.php del tema hijo y ya está.

Como detalle a tener en cuenta, el filtro se ejecuta dos veces, una para las entradas programadas (post_status => 'future') y otra para las publicadas (post_status => 'publish'), así que mirando el estado puedes tratar cada bloque por separado.

Cambiar el número de entradas mostradas

Por defecto son cinco de cada tipo. Si quieres diez:

/* Mostrar 10 entradas en el widget de actividad del escritorio en vez de 5 */
add_filter( 'dashboard_recent_posts_query_args', 'ayudawp_dashboard_activity_posts_per_page' );
function ayudawp_dashboard_activity_posts_per_page( $query_args ) {
    $query_args['posts_per_page'] = 10;
    return $query_args;
}

El filtro afecta tanto a publicadas como a programadas. Si quieres números distintos para cada bloque, comprueba el estado dentro de la función y aplica el valor que toque.

Ocultar las entradas publicadas y dejar solo las programadas

En sitios con flujo editorial activo, lo que interesa es ver lo que está por publicar, no lo que ya salió. Poniendo posts_per_page a cero en el bloque de publicadas, esa sección desaparece sin tocar el resto:

/* Mostrar solo entradas programadas en el widget de actividad */
add_filter( 'dashboard_recent_posts_query_args', 'ayudawp_hide_published_in_activity' );
function ayudawp_hide_published_in_activity( $query_args ) {
if ( 'publish' === $query_args['post_status'] ) {
$query_args['post__in'] = array( 0 );
}
return $query_args;
}

Funciona también al revés: cambia 'publish' por 'future' y desaparecen las programadas. La función wp_dashboard_recent_posts() devuelve sin pintar nada si la consulta no tiene resultados.

Incluir tipos de contenido personalizados

Por defecto el widget solo muestra entradas estándar (post). Si tienes páginas, productos de WooCommerce o un CPT propio, puedes incluirlos así:

/* Mostrar también productos y páginas en widget de actividad del escritorio */
add_filter( 'dashboard_recent_posts_query_args', 'ayudawp_include_cpts_in_activity' );
function ayudawp_include_cpts_in_activity( $query_args ) {
    $query_args['post_type'] = array( 'post', 'page', 'product' );
    return $query_args;
}

Si lo quieres a lo bestia y mostrar cualquier tipo de contenido, pasa 'any' en lugar del array.

Filtrar por autor

En un sitio con varios redactores, igual quieres que cada editor solo vea sus propias entradas en el widget. Los administradores ven todo, los demás solo lo suyo:

/* Mostrar solo entradas propias (salvo admins) en widget de actividad del escritorio */
add_filter( 'dashboard_recent_posts_query_args', 'ayudawp_activity_filter_by_author' );
function ayudawp_activity_filter_by_author( $query_args ) {
    if ( ! current_user_can( 'manage_options' ) ) {
        $query_args['author'] = get_current_user_id();
    }
    return $query_args;
}

Y los comentarios, ¿qué?

El filtro dashboard_recent_posts_query_args solo toca entradas. Para los comentarios no hay un filtro equivalente, de modo que si lo único que quieres es ocultar la sección de comentarios entera, hay un apaño rápido con CSS:

/* Ocultar comentarios en widget de actividad del escritorio */
add_action( 'admin_enqueue_scripts', 'ayudawp_hide_dashboard_comments_css' );
function ayudawp_hide_dashboard_comments_css( $hook ) {
    if ( 'index.php' !== $hook ) {
        return;
    }
    $css = '#latest-comments { display: none; }';
    wp_add_inline_style( 'dashboard', $css );
}

Para cambiar qué comentarios se muestran (solo pendientes, solo aprobados) o reorganizar las secciones, hace falta saltar al método 2 y reemplazar el callback del widget.

Es la limitación natural de este enfoque, que el filtro te da control sobre la consulta de entradas, pero no sobre el resto del widget.

Detalles técnicos: La función wp_dashboard_site_activity() llama a wp_dashboard_recent_posts() dos veces pasándole un array de argumentos. Antes de ejecutar WP_Query con esos argumentos, aplica el filtro dashboard_recent_posts_query_args, que te permite modificarlos. Es un patrón muy típico de WordPress y la forma idiomática de tocar consultas internas sin reemplazar funciones del core.

Método 2: Reescribir el contenido del widget original

Si necesitas controlar también los comentarios, cambiar el aspecto del widget o reorganizar las secciones, el método 1 se queda corto.

La siguiente opción menos invasiva es reemplazar el callback del widget original (la función PHP que dibuja el contenido). Mantienes el meta box (con su ID, su posición y los ajustes de visibilidad que tenga cada usuario) pero reescribes lo que se pinta dentro.

Plantilla base

Este es el esqueleto. Muestra entradas programadas y comentarios pendientes de moderación, dos secciones que suelen ser las más útiles en un flujo de trabajo real:

/**
* Sustituir el contenido del widget de actividad del escritorio con contenido propio
*/
add_action( 'wp_dashboard_setup', 'ayudawp_replace_activity_callback', 999 );
function ayudawp_replace_activity_callback() {
global $wp_meta_boxes;
if ( isset( $wp_meta_boxes['dashboard']['normal']['core']['dashboard_activity'] ) ) {
$wp_meta_boxes['dashboard']['normal']['core']['dashboard_activity']['callback'] = 'ayudawp_render_activity_widget';
}
}

/* Mostrar un widget de actividad personalizada: solo entradas programadas y comentarios pendientes */
function ayudawp_render_activity_widget() {
if ( ! current_user_can( 'edit_posts' ) ) {
return;
}

// Entradas programadas
$scheduled = new WP_Query( array(
'post_type' => 'post',
'post_status' => 'future',
'posts_per_page' => 5,
'orderby' => 'date',
'order' => 'ASC',
'no_found_rows' => true,
) );

if ( $scheduled->have_posts() ) {
echo '<div class="activity-block">';
echo '<h3>' . esc_html__( 'Próximas publicaciones', 'ayudawp' ) . '</h3>';
echo '<ul>';
while ( $scheduled->have_posts() ) {
$scheduled->the_post();
printf(
'<li><a href="%1$s">%2$s</a> — %3$s</li>',
esc_url( get_edit_post_link() ),
esc_html( get_the_title() ),
esc_html( get_the_date( 'd/m/Y H:i' ) )
);
}
echo '</ul>';
echo '</div>';
wp_reset_postdata();
}

// Solo comentarios pendientes (con acciones AJAX nativas: aprobar, responder, editar, spam, papelera)
$pending = get_comments( array(
'status' => 'hold',
'number' => 5,
) );

if ( ! empty( $pending ) ) {
echo '<div class="activity-block">';
echo '<h3>' . esc_html__( 'Comentarios pendientes de moderación', 'ayudawp' ) . '</h3>';
echo '<ul id="the-comment-list" data-wp-lists="list:comment">';
foreach ( $pending as $comment ) {
_wp_dashboard_recent_comments_row( $comment );
}
echo '</ul>';
echo '</div>';
}
}

Variación: cambiar qué comentarios se muestran

El bloque de comentarios usa get_comments() con un argumento status. Cambiándolo cambias el filtro. Los valores aceptados son:

• 'hold': solo comentarios pendientes de moderación (lo que tiene la plantilla base).
• 'approve': solo comentarios aprobados.
• 'spam': comentarios marcados como spam.
• 'trash': comentarios en la papelera.
• 'all': todos, sin filtrar por estado.

También puedes filtrar comentarios por entrada concreta, por usuario, por rango de fechas o por tipo (incluyendo o excluyendo pingbacks y trackbacks). La documentación de WP_Comment_Query recoge todas las opciones.

Variación: quitar la sección de comentarios entera

Si no quieres comentarios en el widget, borra el bloque // Pending comments only entero del callback. Tan sencillo como eso. El widget mostrará solo las entradas programadas.

Variación: añadir las entradas publicadas recientemente

La plantilla base solo muestra programadas, pero si quieres recuperar también las publicadas (al estilo del widget original), añade este bloque antes o después del de programadas:

// Entradas publicadas recientes
$recent = new WP_Query( array(
    'post_type'      => 'post',
    'post_status'    => 'publish',
    'posts_per_page' => 5,
    'orderby'        => 'date',
    'order'          => 'DESC',
    'no_found_rows'  => true,
) );

if ( $recent->have_posts() ) {
    echo '<div class="activity-block">';
    echo '<h3>' . esc_html__( 'Publicado recientemente', 'ayudawp' ) . '</h3>';
    echo '<ul>';
    while ( $recent->have_posts() ) {
        $recent->the_post();
        printf(
            '<li><a href="%1$s">%2$s</a> — %3$s</li>',
            esc_url( get_edit_post_link() ),
            esc_html( get_the_title() ),
            esc_html( get_the_date( 'd/m/Y H:i' ) )
        );
    }
    echo '</ul>';
    echo '</div>';
    wp_reset_postdata();
}

Variación: añadir borradores en revisión

Otro bloque útil para flujos editoriales son los borradores con estado pending (pendientes de revisión por un editor):

// Entradas pendientes de revisión
$pending_posts = new WP_Query( array(
    'post_type'      => 'post',
    'post_status'    => 'pending',
    'posts_per_page' => 5,
    'orderby'        => 'modified',
    'order'          => 'DESC',
    'no_found_rows'  => true,
) );

if ( $pending_posts->have_posts() ) {
    echo '<div class="activity-block">';
    echo '<h3>' . esc_html__( 'Pendientes de revisión', 'ayudawp' ) . '</h3>';
    echo '<ul>';
    while ( $pending_posts->have_posts() ) {
        $pending_posts->the_post();
        printf(
            '<li><a href="%1$s">%2$s</a> — %3$s</li>',
            esc_url( get_edit_post_link() ),
            esc_html( get_the_title() ),
            esc_html( get_the_author() )
        );
    }
    echo '</ul>';
    echo '</div>';
    wp_reset_postdata();
}

Variación: productos WooCommerce sin existencias

Para una tienda WooCommerce, ver productos agotados de un vistazo te ahorra dolores de cabeza, así que igual es una utilidad candidata para aprovechar el widget de actividad.

Mucha gente sigue tirando de WP_Query con meta_query sobre _stock_status, pero esa ya no es la forma recomendada por WooCommerce. La función wc_get_products() es más rápida porque usa la tabla wc_product_meta_lookup y es compatible con HPOS:

// Productos sin existencias (WooCommerce)
if ( function_exists( 'wc_get_products' ) ) {
    $products = wc_get_products( array(
        'stock_status' => 'outofstock',
        'status'       => 'publish',
        'limit'        => 5,
        'orderby'      => 'date',
        'order'        => 'DESC',
    ) );

    if ( ! empty( $products ) ) {
        echo '<div class="activity-block">';
        echo '<h3>' . esc_html__( 'Productos sin stock', 'ayudawp' ) . '</h3>';
        echo '<ul>';
        foreach ( $products as $product ) {
            printf(
                '<li><a href="%1$s">%2$s</a></li>',
                esc_url( get_edit_post_link( $product->get_id() ) ),
                esc_html( $product->get_name() )
            );
        }
        echo '</ul>';
        echo '</div>';
    }
}

Detalles técnicos: El array global $wp_meta_boxes guarda todas las meta cajas registradas en el escritorio. Cada widget tiene su ID, su contexto (normal o side) y su callback. Reasignando la propiedad callback, le decimos a WordPress que cuando vaya a pintar ese widget concreto ejecute nuestra función en lugar de la del core. El meta box sigue ahí, los ajustes del usuario también, pero el contenido lo controlamos nosotros. La prioridad 999 en wp_dashboard_setup nos asegura que corremos después de que el core haya registrado el widget original.

Método 3: Quitar el widget original y crear uno propio

Cuando lo que quieres es darle al escritorio un aire totalmente distinto (un «Panel editorial» con tu flujo, un «Panel de la tienda» para WooCommerce, o un «Resumen del cliente» en una web a medida), olvídate del widget de actividad y monta uno tuyo.

Aquí lo eliminas del escritorio y registras otro nuevo con su propio título, contenido e identidad. Es un widget completamente nuevo, no una reescritura del de actividad.

La pega frente al método anterior es que los usuarios pierden los ajustes que tuvieran (posición, colapsado, etc.) porque cambia el ID del meta box. La ventaja es que el resultado es mucho más limpio y reutilizable.

Las funciones que entran en juego son remove_meta_box() para quitar el original y wp_add_dashboard_widget() para registrar el nuevo.

Ejemplo 1: Panel editorial completo

Esta pequeña-gran virguería muestra un panel editorial, mucho mejor que el habitual widget de actividad ¿no?…

/* Widget de actividad personalizado para panel editorial */
add_action( 'wp_dashboard_setup', 'ayudawp_register_editorial_widget' );
function ayudawp_register_editorial_widget() {
// Quitamos el widget de actividad original
remove_meta_box( 'dashboard_activity', 'dashboard', 'normal' );
// Registramos el propio
wp_add_dashboard_widget(
'ayudawp_editorial_widget',
__( 'Panel editorial', 'ayudawp' ),
'ayudawp_editorial_widget_render'
);
}

/* Estilos del panel editorial */
add_action( 'admin_enqueue_scripts', 'ayudawp_editorial_widget_styles' );
function ayudawp_editorial_widget_styles( $hook ) {
if ( 'index.php' !== $hook ) {
return;
}
$css = '
.ayudawp-editorial-stats { display: flex; flex-wrap: wrap; gap: 10px; margin: 0 0 15px; }
.ayudawp-editorial-stats > div { flex: 1; min-width: 90px; background: #f6f7f7; padding: 10px; border-left: 4px solid #2271b1; }
.ayudawp-editorial-stats a { text-decoration: none; color: inherit; display: block; }
.ayudawp-editorial-stats strong { font-size: 22px; display: block; line-height: 1.2; }
.ayudawp-editorial-stats .label { font-size: 12px; color: #50575e; }
';
wp_add_inline_style( 'dashboard', $css );
}

/* Renderizado del widget */
function ayudawp_editorial_widget_render() {
if ( ! current_user_can( 'edit_posts' ) ) {
return;
}

// Cabecera con métricas en una sola consulta cacheada por el core
$counts = wp_count_posts( 'post' );

$stats = array(
'draft' => array( __( 'Borradores', 'ayudawp' ), (int) $counts->draft ),
'pending' => array( __( 'En revisión', 'ayudawp' ), (int) $counts->pending ),
'future' => array( __( 'Programadas', 'ayudawp' ), (int) $counts->future ),
'publish' => array( __( 'Publicadas', 'ayudawp' ), (int) $counts->publish ),
);

echo '<div class="ayudawp-editorial-stats">';
foreach ( $stats as $status => $data ) {
printf(
'<div><a href="%1$s"><strong>%2$d</strong><span class="label">%3$s</span></a></div>',
esc_url( admin_url( 'edit.php?post_status=' . $status . '&post_type=post' ) ),
$data[1],
esc_html( $data[0] )
);
}
echo '</div>';

// Próximas publicaciones programadas
$scheduled = new WP_Query( array(
'post_type' => 'post',
'post_status' => 'future',
'posts_per_page' => 5,
'orderby' => 'date',
'order' => 'ASC',
'no_found_rows' => true,
) );
if ( $scheduled->have_posts() ) {
echo '<div class="activity-block">';
echo '<h3>' . esc_html__( 'Próximas publicaciones', 'ayudawp' ) . '</h3>';
echo '<ul>';
while ( $scheduled->have_posts() ) {
$scheduled->the_post();
printf(
'<li><a href="%1$s">%2$s</a> — %3$s (%4$s)</li>',
esc_url( get_edit_post_link() ),
esc_html( get_the_title() ),
esc_html( get_the_date( 'd/m/Y H:i' ) ),
esc_html( get_the_author() )
);
}
echo '</ul>';
echo '</div>';
wp_reset_postdata();
}

// Entradas pendientes de revisión
$pending_review = new WP_Query( array(
'post_type' => 'post',
'post_status' => 'pending',
'posts_per_page' => 5,
'orderby' => 'modified',
'order' => 'DESC',
'no_found_rows' => true,
) );
if ( $pending_review->have_posts() ) {
echo '<div class="activity-block">';
echo '<h3>' . esc_html__( 'Pendientes de revisión', 'ayudawp' ) . '</h3>';
echo '<ul>';
while ( $pending_review->have_posts() ) {
$pending_review->the_post();
printf(
'<li><a href="%1$s">%2$s</a> — %3$s</li>',
esc_url( get_edit_post_link() ),
esc_html( get_the_title() ),
esc_html( get_the_author() )
);
}
echo '</ul>';
echo '</div>';
wp_reset_postdata();
}

// Comentarios pendientes de moderación con acciones AJAX nativas
$pending_comments = get_comments( array(
'status' => 'hold',
'number' => 5,
) );
if ( ! empty( $pending_comments ) ) {
echo '<div class="activity-block">';
echo '<h3>' . esc_html__( 'Comentarios pendientes', 'ayudawp' ) . '</h3>';
echo '<ul id="the-comment-list" data-wp-lists="list:comment">';
foreach ( $pending_comments as $comment ) {
_wp_dashboard_recent_comments_row( $comment );
}
echo '</ul>';
echo '</div>';
}
}

Ejemplo 2: Panel de tienda WooCommerce

Para una tienda, lo más útil es ver de un vistazo productos sin stock y pedidos pendientes:

/* Widget de actividad personalizado para panel de tienda WooCommerce */
add_action( 'wp_dashboard_setup', 'ayudawp_register_shop_widget' );
function ayudawp_register_shop_widget() {
// Solo si WooCommerce está activo
if ( ! function_exists( 'wc_get_products' ) ) {
return;
}
// Quitamos el widget de actividad original
remove_meta_box( 'dashboard_activity', 'dashboard', 'normal' );
// Registramos el propio
wp_add_dashboard_widget(
'ayudawp_shop_widget',
__( 'Panel de la tienda', 'ayudawp' ),
'ayudawp_shop_dashboard_widget_render'
);
}

/* Estilos del panel de tienda */
add_action( 'admin_enqueue_scripts', 'ayudawp_shop_widget_styles' );
function ayudawp_shop_widget_styles( $hook ) {
if ( 'index.php' !== $hook ) {
return;
}
$css = '
.ayudawp-shop-stats { display: flex; flex-wrap: wrap; gap: 10px; margin: 0 0 15px; }
.ayudawp-shop-stats > div { flex: 1; min-width: 90px; background: #f6f7f7; padding: 10px; border-left: 4px solid #674399; }
.ayudawp-shop-stats strong { font-size: 22px; display: block; line-height: 1.2; }
.ayudawp-shop-stats .label { font-size: 12px; color: #50575e; }
';
wp_add_inline_style( 'dashboard', $css );
}

/* Renderizado del widget */
function ayudawp_shop_dashboard_widget_render() {
if ( ! current_user_can( 'manage_woocommerce' ) ) {
return;
}

// Métricas de pedidos por estado
$stats = array(
__( 'Pendientes', 'ayudawp' ) => wc_orders_count( 'pending' ),
__( 'En proceso', 'ayudawp' ) => wc_orders_count( 'processing' ),
__( 'En espera', 'ayudawp' ) => wc_orders_count( 'on-hold' ),
__( 'Completados', 'ayudawp' ) => wc_orders_count( 'completed' ),
);

echo '<div class="ayudawp-shop-stats">';
foreach ( $stats as $label => $count ) {
printf(
'<div><strong>%1$d</strong><span class="label">%2$s</span></div>',
(int) $count,
esc_html( $label )
);
}
echo '</div>';

// Productos sin stock
$out_of_stock = wc_get_products( array(
'stock_status' => 'outofstock',
'status' => 'publish',
'limit' => 5,
) );
if ( ! empty( $out_of_stock ) ) {
echo '<div class="activity-block">';
echo '<h3>' . esc_html__( 'Productos sin stock', 'ayudawp' ) . '</h3>';
echo '<ul>';
foreach ( $out_of_stock as $product ) {
printf(
'<li><a href="%1$s">%2$s</a></li>',
esc_url( get_edit_post_link( $product->get_id() ) ),
esc_html( $product->get_name() )
);
}
echo '</ul>';
echo '</div>';
}

// Pedidos por atender (pendientes y en espera)
$orders = wc_get_orders( array(
'status' => array( 'pending', 'on-hold' ),
'limit' => 5,
'orderby' => 'date',
'order' => 'DESC',
) );
if ( ! empty( $orders ) ) {
echo '<div class="activity-block">';
echo '<h3>' . esc_html__( 'Pedidos por atender', 'ayudawp' ) . '</h3>';
echo '<ul>';
foreach ( $orders as $order ) {
printf(
'<li><a href="%1$s">#%2$s — %3$s</a> — %4$s</li>',
esc_url( $order->get_edit_order_url() ),
esc_html( $order->get_order_number() ),
esc_html( $order->get_formatted_billing_full_name() ),
wp_kses_post( wc_price( $order->get_total() ) )
);
}
echo '</ul>';
echo '</div>';
}
}

Para registrarlo, igual que antes: cambia la llamada a wp_add_dashboard_widget() con el nuevo callback. Y restringe la visibilidad a usuarios con la capacidad manage_woocommerce.

Ejemplo 3: Panel de eventos próximos

Si gestionas reservas, eventos o un tipo de contenido con una fecha guardada, esta versión lista los próximos ordenados por la fecha del evento, no por la fecha de publicación:

/* Widget de actividad personalizado para panel de eventos */
function ayudawp_events_widget_render() {
    if ( ! current_user_can( 'edit_posts' ) ) {
        return;
    }

    $upcoming = new WP_Query( array(
        'post_type'      => 'evento',
        'post_status'    => 'publish',
        'posts_per_page' => 5,
        'meta_key'       => 'fecha_del_evento',
        'orderby'        => 'meta_value',
        'order'          => 'ASC',
        'meta_query'     => array(
            array(
                'key'     => 'fecha_del_evento',
                'value'   => current_time( 'Y-m-d' ),
                'compare' => '>=',
                'type'    => 'DATE',
            ),
        ),
        'no_found_rows'  => true,
    ) );

    if ( ! $upcoming->have_posts() ) {
        echo '<p>' . esc_html__( 'No hay eventos próximos.', 'ayudawp' ) . '</p>';
        return;
    }

    echo '<ul>';
    while ( $upcoming->have_posts() ) {
        $upcoming->the_post();
        $event_date = get_post_meta( get_the_ID(), 'fecha_del_evento', true );
        printf(
            '<li><a href="%1$s">%2$s</a> — %3$s</li>',
            esc_url( get_edit_post_link() ),
            esc_html( get_the_title() ),
            esc_html( $event_date )
        );
    }
    echo '</ul>';
    wp_reset_postdata();
}

Si el sitio tiene muchos eventos, mete los resultados en un transient de unos minutos para no machacar la base de datos cada vez que alguien entra al escritorio.

Detalles técnicos: remove_meta_box() elimina la entrada del array $wp_meta_boxes, así que el widget original deja de existir para WordPress. wp_add_dashboard_widget() registra uno nuevo con su propio ID, título y callback. Como es un meta box nuevo, los ajustes del usuario (posición, colapsado, oculto) no se heredan del anterior. Es un widget partido de cero.

Método 4: Widget con opciones configurables desde el escritorio

Cuando montas algo para un cliente o quieres aplicar la misma personalización en varios sitios, lo suyo es que el propio usuario pueda elegir cuántas entradas mostrar, si quiere ver comentarios o no, o si solo quiere ver lo suyo.

En lugar de dejar cada cosa fijada en el código, le añades un pequeño formulario de configuración que aparece al pulsar en el enlace «Configurar» del widget, ahí cada uno decide.

WordPress lo admite de fábrica, al registrar el widget con wp_add_dashboard_widget(), pasas un cuarto parámetro (el llamado control callback) que se encarga tanto de pintar el formulario como de guardar los valores cuando el usuario lo envía.

El nonce y la verificación de permisos los gestiona el propio core, así que tú solo te ocupas de leer la opción guardada y aplicarla cuando se pinta el widget.

Widget configurable con opciones configurables

Esta es una versión más completa que el típico «número de entradas». Permite configurar cuántas entradas programadas mostrar, si incluir comentarios pendientes, si filtrar por autor (cada editor solo ve lo suyo) y mucho más:

/**
* Widget de actividad configurable mediante panel de ajustes propio
*/
class AyudaWP_Configurable_Activity_Widget {

const OPTION_NAME = 'ayudawp_activity_widget_settings';
const WIDGET_ID = 'ayudawp_configurable_activity';

public function __construct() {
add_action( 'wp_dashboard_setup', array( $this, 'register_widget' ) );
add_action( 'admin_enqueue_scripts', array( $this, 'enqueue_styles' ) );
}

public function register_widget() {
wp_add_dashboard_widget(
self::WIDGET_ID,
__( 'Actividad editorial configurable', 'ayudawp' ),
array( $this, 'render_widget' ),
array( $this, 'render_form' )
);
}

public function enqueue_styles( $hook ) {
if ( 'index.php' !== $hook ) {
return;
}
$css = '
.ayudawp-editorial-stats { display: flex; flex-wrap: wrap; gap: 10px; margin: 0 0 15px; }
.ayudawp-editorial-stats > div { flex: 1; min-width: 90px; background: #f6f7f7; padding: 10px; border-left: 4px solid #2271b1; }
.ayudawp-editorial-stats a { text-decoration: none; color: inherit; display: block; }
.ayudawp-editorial-stats strong { font-size: 22px; display: block; line-height: 1.2; }
.ayudawp-editorial-stats .label { font-size: 12px; color: #50575e; }
';
wp_add_inline_style( 'dashboard', $css );
}

public function render_widget() {
if ( ! current_user_can( 'edit_posts' ) ) {
return;
}

$settings = $this->get_settings();
$limit = (int) $settings['limit'];
$author = ! empty( $settings['only_mine'] ) ? get_current_user_id() : 0;

if ( ! empty( $settings['show_stats'] ) ) {
$this->render_stats();
}

if ( ! empty( $settings['show_scheduled'] ) ) {
$this->render_posts_block(
'future',
'ASC',
'date',
__( 'Próximas publicaciones', 'ayudawp' ),
__( 'No hay entradas programadas.', 'ayudawp' ),
$limit,
$author,
'date'
);
}

if ( ! empty( $settings['show_pending_review'] ) ) {
$this->render_posts_block(
'pending',
'DESC',
'modified',
__( 'Pendientes de revisión', 'ayudawp' ),
__( 'Sin entradas pendientes de revisión.', 'ayudawp' ),
$limit,
$author,
'author'
);
}

if ( ! empty( $settings['show_recent'] ) ) {
$this->render_posts_block(
'publish',
'DESC',
'date',
__( 'Publicado recientemente', 'ayudawp' ),
__( 'Sin publicaciones recientes.', 'ayudawp' ),
$limit,
$author,
'date'
);
}

if ( ! empty( $settings['show_comments'] ) ) {
$this->render_comments_block( $limit );
}
}

private function render_stats() {
$counts = wp_count_posts( 'post' );
$stats = array(
'draft' => array( __( 'Borradores', 'ayudawp' ), (int) $counts->draft ),
'pending' => array( __( 'En revisión', 'ayudawp' ), (int) $counts->pending ),
'future' => array( __( 'Programadas', 'ayudawp' ), (int) $counts->future ),
'publish' => array( __( 'Publicadas', 'ayudawp' ), (int) $counts->publish ),
);

echo '<div class="ayudawp-editorial-stats">';
foreach ( $stats as $status => $data ) {
printf(
'<div><a href="%1$s"><strong>%2$d</strong><span class="label">%3$s</span></a></div>',
esc_url( admin_url( 'edit.php?post_status=' . $status . '&post_type=post' ) ),
$data[1],
esc_html( $data[0] )
);
}
echo '</div>';
}

private function render_posts_block( $status, $order, $orderby, $title, $empty_msg, $limit, $author, $meta ) {
$query_args = array(
'post_type' => 'post',
'post_status' => $status,
'posts_per_page' => $limit,
'orderby' => $orderby,
'order' => $order,
'no_found_rows' => true,
);

if ( $author ) {
$query_args['author'] = $author;
}

$query = new WP_Query( $query_args );

echo '<div class="activity-block">';
echo '<h3>' . esc_html( $title ) . '</h3>';

if ( $query->have_posts() ) {
echo '<ul>';
while ( $query->have_posts() ) {
$query->the_post();
$extra = ( 'date' === $meta )
? esc_html( get_the_date( 'd/m/Y H:i' ) )
: esc_html( get_the_author() );
printf(
'<li><a href="%1$s">%2$s</a> — %3$s</li>',
esc_url( get_edit_post_link() ),
esc_html( get_the_title() ),
$extra
);
}
echo '</ul>';
wp_reset_postdata();
} else {
echo '<p>' . esc_html( $empty_msg ) . '</p>';
}
echo '</div>';
}

private function render_comments_block( $limit ) {
$pending = get_comments( array(
'status' => 'hold',
'number' => $limit,
) );

echo '<div class="activity-block">';
echo '<h3>' . esc_html__( 'Comentarios pendientes', 'ayudawp' ) . '</h3>';

if ( ! empty( $pending ) ) {
// Estructura nativa para que el JS del core enganche las acciones AJAX
echo '<ul id="the-comment-list" data-wp-lists="list:comment">';
foreach ( $pending as $comment ) {
_wp_dashboard_recent_comments_row( $comment );
}
echo '</ul>';
} else {
echo '<p>' . esc_html__( 'Sin comentarios pendientes.', 'ayudawp' ) . '</p>';
}
echo '</div>';
}

public function render_form() {
// Procesar envío del formulario. El nonce ya lo verifica WP
if ( 'POST' === $_SERVER['REQUEST_METHOD']
&& isset( $_POST['widget_id'] )
&& self::WIDGET_ID === $_POST['widget_id']
&& current_user_can( 'edit_dashboard' ) ) {

$limit = isset( $_POST['ayudawp_limit'] )
? absint( wp_unslash( $_POST['ayudawp_limit'] ) )
: 5;

update_option( self::OPTION_NAME, array(
'limit' => max( 1, min( 20, $limit ) ),
'show_stats' => ! empty( $_POST['ayudawp_show_stats'] ),
'show_scheduled' => ! empty( $_POST['ayudawp_show_scheduled'] ),
'show_pending_review' => ! empty( $_POST['ayudawp_show_pending_review'] ),
'show_recent' => ! empty( $_POST['ayudawp_show_recent'] ),
'show_comments' => ! empty( $_POST['ayudawp_show_comments'] ),
'only_mine' => ! empty( $_POST['ayudawp_only_mine'] ),
) );
}

$settings = $this->get_settings();
?>
<p>
<label for="ayudawp_limit">
<?php esc_html_e( 'Cantidad de elementos por sección:', 'ayudawp' ); ?>
</label>
<input class="small-text"
id="ayudawp_limit"
name="ayudawp_limit"
type="number"
min="1"
max="20"
value="<?php echo esc_attr( $settings['limit'] ); ?>">
</p>

<p><strong><?php esc_html_e( 'Secciones a mostrar:', 'ayudawp' ); ?></strong></p>

<p>
<label>
<input type="checkbox" name="ayudawp_show_stats" value="1" <?php checked( ! empty( $settings['show_stats'] ) ); ?>>
<?php esc_html_e( 'Resumen de cifras (borradores, en revisión, programadas, publicadas)', 'ayudawp' ); ?>
</label>
</p>
<p>
<label>
<input type="checkbox" name="ayudawp_show_scheduled" value="1" <?php checked( ! empty( $settings['show_scheduled'] ) ); ?>>
<?php esc_html_e( 'Próximas publicaciones programadas', 'ayudawp' ); ?>
</label>
</p>
<p>
<label>
<input type="checkbox" name="ayudawp_show_pending_review" value="1" <?php checked( ! empty( $settings['show_pending_review'] ) ); ?>>
<?php esc_html_e( 'Entradas pendientes de revisión', 'ayudawp' ); ?>
</label>
</p>
<p>
<label>
<input type="checkbox" name="ayudawp_show_recent" value="1" <?php checked( ! empty( $settings['show_recent'] ) ); ?>>
<?php esc_html_e( 'Publicaciones recientes', 'ayudawp' ); ?>
</label>
</p>
<p>
<label>
<input type="checkbox" name="ayudawp_show_comments" value="1" <?php checked( ! empty( $settings['show_comments'] ) ); ?>>
<?php esc_html_e( 'Comentarios pendientes de moderación', 'ayudawp' ); ?>
</label>
</p>

<p><strong><?php esc_html_e( 'Filtros:', 'ayudawp' ); ?></strong></p>

<p>
<label>
<input type="checkbox" name="ayudawp_only_mine" value="1" <?php checked( ! empty( $settings['only_mine'] ) ); ?>>
<?php esc_html_e( 'Mostrar solo mis entradas (no las de otros autores)', 'ayudawp' ); ?>
</label>
</p>
<?php
}

private function get_settings() {
$defaults = array(
'limit' => 5,
'show_stats' => true,
'show_scheduled' => true,
'show_pending_review' => true,
'show_recent' => false,
'show_comments' => true,
'only_mine' => false,
);
$saved = get_option( self::OPTION_NAME, array() );
return wp_parse_args( $saved, $defaults );
}
}

new AyudaWP_Configurable_Activity_Widget();

Con esto, al pasar el ratón por el título del widget aparece el enlace «Configurar», y al hacer clic se despliega el formulario con las opciones disponibles, ejemplo de lo que hemos estado viendo, pero ya a golpe de clic.

Al guardar, los valores se persisten en la opción ayudawp_activity_widget_settings y se aplican al renderizado del widget.

Si quieres añadir más controles solo tienes que añadir más campos al formulario, ampliar los valores por defecto en get_settings() y leerlos en render_widget(), la estructura ya está montada.

Detalles técnicos: wp_add_dashboard_widget() acepta hasta cuatro parámetros principales: ID, título, callback de renderizado y callback de configuración. Si pasas el cuarto, WordPress añade automáticamente el enlace «Configurar» en el título del widget. Cuando el usuario guarda el formulario, WordPress se encarga del nonce (lo verifica con check_admin_referer( 'edit-dashboard-widget_' . $widget_id, 'dashboard-widget-nonce' )) antes de llamar al control callback. Por eso dentro del callback solo necesitamos comprobar capacidad y procesar los datos. El formulario se envía a la misma página del escritorio y se procesa en el mismo callback que lo pinta.

Mostrar el widget solo a ciertos perfiles de usuario

En muchos casos no quieres que un autor o colaborador vea actividad del resto del sitio, o que un editor vea productos de la tienda. Combinando remove_meta_box() con current_user_can() filtras con una línea:

/* Mostrar widget de actividad solo a ciertos usuarios */
add_action( 'wp_dashboard_setup', 'ayudawp_hide_activity_for_non_editors', 100 );
function ayudawp_hide_activity_for_non_editors() {
    if ( ! current_user_can( 'edit_others_posts' ) ) {
        remove_meta_box( 'dashboard_activity', 'dashboard', 'normal' );
    }
}

El widget desaparece para todo el mundo salvo editores y administradores. Cambia la capacidad por la que necesites según el caso: manage_woocommerce, manage_options, publish_posts, etc.

Plugins alternativos si prefieres no tocar código

Si no quieres meter mano al código, hay tres plugins que cubren bien el caso:

• Ultimate Dashboard, de David Vongries. Desactiva los widgets nativos de un clic y permite crear los tuyos con texto, HTML o iconos. La versión pro añade restricciones por rol y limpieza de widgets de otros plugins.
• Admin Menu Editor, de Janis Elsts. Aunque está pensado para el menú lateral, también permite reordenar y dar permisos por rol al panel de control. Más de 400.000 instalaciones activas y mantenimiento constante.
• Dashboard Directory Size, de Pete Nelson. Añade un widget que muestra el tamaño en disco de las carpetas de WordPress y de la base de datos. Útil para sitios donde controlar el crecimiento del almacenamiento importa.

Si lo que te interesa es ver actividad de bots de IA en el panel (un caso cada vez más habitual con ChatGPT, Claude o Perplexity rastreando tu sitio), echa un vistazo a VigIA, que añade su propio widget de analítica de crawlers de IA al escritorio.

Dónde poner cada bloque de código

Cualquiera de estos snippets puede ir en tres sitios:

• El functions.php de un tema hijo. La opción más rápida pero también la más frágil, porque si cambias de tema pierdes los cambios.
• Un mu-plugin en wp-content/mu-plugins/. Es la forma que prefiero para personalizaciones del escritorio porque se mantienen activas pase lo que pase con temas y plugins. Si todavía no usas mu-plugins, tengo una serie de artículos sobre ellos que te puede ayudar.
• Un plugin propio. La opción más profesional si vas a empaquetar varias personalizaciones del admin y compartirlas entre sitios.

Si combinas varios métodos, ojo con el orden. El filtro dashboard_recent_posts_query_args (método 1) no tiene sentido si reemplazas el widget entero (métodos 2, 3 o 4), porque ya no se ejecuta la función que lo dispara. Elige uno según lo lejos que necesites llegar y ya está.

Mi consejo, así en general, es que empieces por el método 1, que es el más limpio, y si te quedas corto pasa al 2.

Solo monta el 4 si necesitas que el propio usuario configure el widget desde el panel, que cuanto menos toques el comportamiento del core menos cosas se romperán cuando WordPress se actualice.

Para todo lo demás, aquí me tienes.

Si llevas años con tu web y has subido 800 imágenes, tienes 800 URLs que Google puede rastrear, indexar y mostrar en los resultados de búsqueda, y la mayoría de esas páginas no tienen prácticamente nada de contenido.

Eso tiene impacto (no bueno precisamente) en el SEO y es más fácil de solucionar de lo que parece.

Qué es una página de adjunto y por qué existe tal cosa

Cuando subes una imagen a WordPress, el sistema hace dos cosas. Por un lado guarda el archivo en /wp-content/uploads/, y además crea una entrada en la base de datos de tipo attachment. Esa entrada tiene su propia URL, su propio título y, si tienes instalado el tema por defecto, la propia página con la imagen y poco más.

La URL suele tener este aspecto:

https://tudominio.com/nombre-del-archivo/

O si la imagen está adjunta a una entrada concreta:

https://tudominio.com/nombre-de-la-entrada/nombre-del-archivo/

WordPress las creó así porque en los primeros tiempos era una plataforma de blogging pura y tenía sentido que los adjuntos fueran un tipo de contenido con entidad propia. Hoy la mayoría de los sitios no las necesita para nada, pero siguen ahí.

El problema de SEO, que lo es

Abre Google Search Console, ve a Indexación > Páginas y fíjate en las razones por las que Google no indexa algunas URLs. Hay muchas posibilidades de que veas un grupo grande en categorías como «El contenido duplicado es el contenido enviado» o «Rastreada, actualmente sin indexar». Si echas un vistazo a esas URLs, es probable que muchas sean páginas de adjuntos.

El problema tiene varias caras. Por un lado, estas páginas tienen muy poco contenido, porque solo tienen la imagen, quizá el título que le pusiste al subir el archivo y nada más, y Google las ve como páginas de baja calidad, el tristemente famoso thin content.

Por otro lado, si subes una imagen para ilustrar un artículo sobre WordPress, esa página de adjunto va a competir en los resultados de búsqueda con el artículo original, que es donde está todo el contenido de verdad.

No es algo que vaya a hundir tu web de golpe, pero sí consume presupuesto de rastreo, diluye la autoridad y ensucia los informes de Search Console con URLs que no aportan nada.

Cómo solucionarlo con plugins

Hay varias maneras de abordar este problema con plugins, y decidir cuál usar depende mucho de lo que busques y cómo quieras tratar las páginas de adjuntos.

Los plugins de SEO más usados en WordPress incluyen alguna opción, aunque cada uno la pone en un sitio distinto, lo trata de distinta forma y con un nombre diferente.

• Yoast SEO: ve a SEO > Apariencia en el buscador > Medios. Encontrarás una opción para redirigir las URLs de adjuntos. Ojo con el nombre porque lleva a confusión: lo que hace Yoast es redirigir al archivo de imagen directamente, no al post al que pertenece. Así que si alguien llega a tudominio.com/foto-de-portada/, lo que ve es la imagen cruda en el navegador. Desde la versión 20.x aproximadamente la opción se muestra algo más clara y en algunos casos ofrece también redirigir al post padre, pero la interfaz ha cambiado varias veces así que comprueba qué tienes delante.
• Rank Math: está en Rank Math > Ajustes generales > Medios, bajo el nombre «Redirección de adjuntos». Por defecto también redirige al archivo de imagen, pero incluye una opción para redirigir al post padre cuando la imagen está adjunta a uno, que es más útil desde el punto de vista del SEO.
• SEOPress: lo tienes en SEO > Ajustes > Avanzado > Adjuntos. La opción se llama «Redirigir páginas de adjunto» y redirige al post padre si existe o a la home si la imagen no está adjunta a ningún contenido, que es el comportamiento más sensato de los tres.

Además de estos, tienes Attachment Pages Redirect, que genera automáticamente redirecciones 301, 302 o incluso 404, dependiendo del resultado que quieras ofrecer.

Y luego está el enfoque de NoIndexer, que propone una solución sencilla, pero igual de efectiva, y es simplemente añadir la etiqueta meta noindex a todas las páginas de adjuntos, de manera que simplemente los buscadores no indexen estas URLs. Es perfectamente válido para webs nuevas, pero no para sitios con estas URLs ya indexadas.

Soluciones con código, sin depender de un plugin de SEO

Si no usas plugins de SEO, o simplemente prefieres no depender de ningún plugin para esto, puedes resolverlo con código. Hay tres opciones según lo que quieras conseguir.

Opción 1: redirigir al contenido

Esta es la opción más recomendable cuando la imagen está adjunta a una entrada o página. El visitante llega a una URL con contenido que merece la pena, que tiene eso, contenido, y Google entiende la relación entre la imagen y el texto.

Añade esto al functions.php de tu tema hijo o a un plugin de funciones:

add_action( 'template_redirect', 'ayudawp_redirect_attachment_pages' );
function ayudawp_redirect_attachment_pages() {
    if ( ! is_attachment() ) {
        return;
    }

    $post_parent = wp_get_post_parent_id( get_queried_object_id() );

    if ( $post_parent ) {
        // Redirige al post padre si existe
        wp_safe_redirect( get_permalink( $post_parent ), 301 );
    } else {
        // Si no hay post padre, redirige a la home
        wp_safe_redirect( home_url(), 301 );
    }

    exit;
}

Opción 2: redirigir al archivo de imagen

Si prefieres que la URL de adjunto lleve directamente a la imagen en lugar de a la publicación usa esto:

add_action( 'template_redirect', 'ayudawp_redirect_attachment_to_file' );
function ayudawp_redirect_attachment_to_file() {
    if ( ! is_attachment() ) {
        return;
    }

    $attachment_url = wp_get_attachment_url( get_queried_object_id() );

    if ( $attachment_url ) {
        wp_safe_redirect( $attachment_url, 301 );
        exit;
    }
}

Opción 3: devolver un 404

La tercera opción es decirle a Google directamente que esas páginas no existen. Es la más agresiva y hace que el rastreador deje de visitarlas del todo. Funciona bien si llevas tiempo con la web y ya tienes muchas páginas de adjunto indexadas que quieres eliminar del índice rápido.

add_action( 'template_redirect', 'ayudawp_404_attachment_pages' );
function ayudawp_404_attachment_pages() {
    if ( ! is_attachment() ) {
        return;
    }

    global $wp_query;
    $wp_query->set_404();
    status_header( 404 );
    nocache_headers();
}

Qué elegir según tu caso

• Si tienes un blog o web de contenidos donde las imágenes siempre van dentro de artículos, redirigir a la publicación de donde partía es lo más limpio. El usuario llega a donde tiene que llegar y no pierdes nada.
• Si tienes una web con muchas imágenes que no están adjuntas a ningún contenido (galerías libres, páginas de porfolio subidas sueltas), redirigir al archivo puede tener sentido. También si usas las páginas de adjunto para algo concreto, como mostrar fichas de productos fotográficos, aunque ese caso es muy raro.
• El 404 es útil si llevas mucho tiempo con la web, tienes cientos o miles de páginas de adjunto ya indexadas y quieres limpiar eso cuanto antes. Google las elimina del índice con más rapidez cuando devuelven 404 que cuando simplemente no las enlazas a nada.

Lo que no tiene ningún sentido es no hacer nada. Si abres Search Console y ves decenas o cientos de páginas de adjunto en el informe de indexación, estás dejando que el rastreador gaste presupuesto en páginas que no te aportan nada.

Un par de cosas antes de aplicarlo

S ya tienes páginas de adjunto indexadas y las redirigirás con un 301, debes saber que Google tardará un tiempo en procesar los cambios. No esperes que Search Console se limpie de un día para otro, puede tardar semanas dependiendo de con qué frecuencia rastree tu web.

También debes comprobar que ninguna parte de tu web enlaza directamente a páginas de adjunto. A veces los maquetadores o algunos plugins de galerías enlazan a la URL del adjunto en lugar de al archivo de imagen directamente. Si rediriges esas URLs asegúrate de que los enlaces dentro de tu web también estén actualizados para no crear cadenas de redirecciones innecesarias.

Por último, si usas plugins de SEO no combines su opción de redirección con los códigos que hemos visto. Elige uno u otro o tendrás redirecciones en bucle.

Me refiero a Twenty20 Image Before-After, y cualquier autor o colaborador con permisos para escribir puede dejarte un JavaScript malicioso guardado en una entrada esperando a que la abra el primer visitante, así que si lo tienes activo ahora mismo eres vulnerable.

No es un caso raro ni aislado, porque los ataques XSS (Cross-Site Scripting) están entre las vulnerabilidades más reportadas en aplicaciones web según el OWASP Top 10.

WordPress, por su naturaleza de CMS abierto con miles de plugins y temas de terceros que nadie audita en profundidad, acaba siendo objetivo recurrente, y Patchstack publica cientos de vulnerabilidades XSS al año solo en plugins WordPress, y muchas afectan a webs con decenas de miles de instalaciones activas que siguen sin parchear.

La buena noticia es que defenderse de XSS no requiere ser pentester ni gastar dinero en plugins premium, basta con entender qué es un XSS, cómo aterriza en una web WordPress y dónde te conviene frenarlo.

En esta guía te lo cuento aplicando la misma estrategia por capas que en la guía de defensa contra ataques de fuerza bruta, porque al final cualquier defensa que se precie se monta así, de fuera hacia dentro.

Pero primero…

Qué es un ataque XSS y por qué WordPress es objetivo recurrente

Un XSS es un ataque que consigue meter código JavaScript donde no debería, y que el navegador del visitante ejecuta como si fuera parte legítima de tu web.

Lo curioso del asunto es que el atacante no toca tu servidor, no roba contraseñas de admin ni tiene que saltar tu cortafuegos, le basta con que tu web pinte en pantalla algo que un usuario haya escrito sin filtrarlo bien. El daño potencial es enorme y va por dentro, no por fuera.

Un XSS bien colocado puede robar la cookie de sesión de un administrador para entrar en su nombre, redirigir a tus visitantes a una web falsa que parece la tuya, recolectar datos de formularios antes de que se envíen, convertir el navegador del visitante en parte de una botnet o desfigurar la web con propaganda.

Lo peor es que todo eso pasa en el navegador del visitante, así que tu servidor sigue funcionando como si nada y muchas veces ni te enteras de que estás comprometido.

WordPress es objetivo principal por dos razones que se refuerzan entre sí.

1. La cuota de mercado, que ronda el 42% de las webs del planeta, así que si vas a atacar webs en serie atacas WordPress y multiplicas resultados.
2. El modelo de plugins y temas, donde cualquiera puede subir código al repositorio o vender un tema en un marketplace y meterlo en miles de webs sin que nadie haga auditoría a fondo.

El núcleo de WordPress está bastante controlado, los plugins y temas son el coladero habitual y sino echa un vistazo a los resúmenes de actualidad WordPress que hago cada lunes para comprobarlo.

Los tres tipos de XSS, con ejemplos aplicados a WordPress

No todos los XSS funcionan igual, hay tres tipos clásicos y cada uno se cuela por una rendija distinta de tu WordPress. Saber distinguirlos te ayuda a saber dónde mirar cuando algo huele mal.

XSS reflejado

Es el más sencillo y el menos peligroso de los tres, aunque tampoco te confíes porque sigue haciendo daño. El código malicioso viaja en la URL y se ejecuta en cuanto el visitante hace clic en un enlace manipulado.

El escenario típico en WordPress es un plugin que muestra el parámetro de búsqueda en pantalla sin escaparlo, así que si el plugin recibe ?s=zapatillas y pinta «No hay resultados para zapatillas», un atacante puede preparar un enlace tipo tudominio.com/?s=<script>alert(1)</script> y mandárselo a la víctima por email, redes o un comentario en un foro.

Cuando la víctima hace clic, el navegador interpreta el <script> como código de tu web y lo ejecuta, y si en vez de un alert inofensivo lleva código que roba la cookie de sesión, el atacante puede entrar como ese usuario.

Otro ataque típico es el parámetro de mensaje de error o de notificación, esos ?msg=usuario+creado, ?error=... o ?notice=... que muchos plugins pintan tal cual, y donde cabe lo que quieras meter si no hay algún tipo de filtrado.

XSS almacenado

Este es el malo de la película, porque el código malicioso se queda guardado en tu base de datos y se ejecuta cada vez que alguien visita la página afectada.

Aquí no hace falta engañar a nadie con un enlace, basta con que la víctima entre a leer un artículo, un comentario o una ficha de producto y ya tiene el regalo servido.

El caso del plugin Twenty20 que abre este artículo es exactamente este, porque el plugin tenía un shortcode [twenty20] con varios atributos (img1, img2, before, after, offset, orientation) que no se filtraban antes de pintarse en pantalla, así que cualquier usuario con permisos para escribir contenido podía dejar guardado en una entrada algo así:

[twenty20 img1="javascript:alert(1)" img2="..." before="<script>alert(1)</script>"]

A partir de ese momento, cada visitante que abriese la entrada ejecutaba ese JavaScript, y si en vez de un alert hubiese un script que recopila cookies de admin o redirige al banco falso, el daño se multiplica por cada visita que reciba la entrada.

El XSS almacenado se cuela por sitios donde WordPress acepta que los usuarios introduzcan información, y la guarda para enseñarla luego.

Los candidatos típicos son:

• Comentarios mal filtrados.
• Descripciones de productos en WooCommerce con HTML permitido sin filtrar.
• Formularios de contacto que muestran el último envío en el panel del admin.
• Campos personalizados que una plantilla custom pinta en el frontend sin pasar por esc_html()
• Perfiles de autor con biografía editable.
• Ociones de plugins que se muestran en el escritorio sin escapar.

Donde algo entra y luego sale sin filtrar hay candidato a XSS almacenado.

XSS basado en DOM

El más moderno de los tres y el que peor cubren los WAF tradicionales, porque el ataque ocurre íntegramente en el navegador y tu servidor ni se entera de que ha pasado.

El JavaScript de tu propia web lee algo del URL o del almacenamiento local del navegador y lo pinta en pantalla, y si no filtra bien lo que ha leído, el atacante consigue meter su código.

En WordPress aparece sobre todo en carruseles, maquetadores, bloques personalizados y plugins de calculadoras o formularios, cualquier cosa que use mucho JavaScript en en la parte pública de la web.

Un caso típico es el carrusel que lee el hash de la URL (#slide=3) y pinta el contenido correspondiente, o el plugin de búsqueda con autocompletado que muestra el término que el usuario está tecleando en tiempo real.

El XSS DOM es engañoso porque no aparece en los logs del servidor, no lo detectan los escáneres clásicos y muchos plugins de seguridad lo dejan pasar al no encontrar nada raro en la petición HTTP, ya que lo malicioso está íntegramente en el JavaScript del cliente.

Errores fáciles de detectar aunque no seas técnico

No hace falta saber programar para descubrir si tu WordPress tiene problemas evidentes, hay tres pruebas tontas que puede hacer cualquiera en cinco minutos y que te dan pistas de sobra para saber si tienes que ponerte serio con la defensa.

1. HTML básico: Consiste en escribir <b>probando</b> en el formulario de comentarios o en cualquier campo de texto que se vaya a mostrar después, y enviarlo. Si al ver el resultado aparece la palabra «probando» en negrita, tienes un problema, porque tu web está aceptando HTML donde no debería, y aunque eso no es XSS en sí, sí es por donde se pueden colar. Si acepta <b> es muy probable que acepte <script>.
2. La prueba del parámetro reflejado: Añade a la URL de tu web un parámetro inventado con un valor distintivo, tipo ?test=hola12345, recorre la página y mira el código fuente con botón derecho buscando «hola12345». Si aparece tal cual, sin escapar, tienes un XSS reflejado en potencia porque algún plugin o el tema está pintando ese parámetro en algún sitio sin filtrarlo.
3. La prueba del campo personalizado: Esta consiste en editar cualquier campo que tu tema o plugin pinte en el frontend (una biografía de autor, un campo personalizado, un campo de perfil), meterle <b>negrita</b>, guardar y recargar. Si sale en negrita en la parte pública de la web es que se pueden colar más cosas.

Estas pruebas no son pentesting, son sentido común aplicado en segundos, y si alguna falla sabes que tienes que ponerte las pilas con las capas que vienen a continuación.

Cómo saber si tu WordPress es vulnerable a ataques XSS

Las pruebas anteriores te dicen si hay agujeros evidentes, pero no te dan la foto completa, para eso necesitas herramientas que escaneen de verdad. Hay 4 gratuitas que van bien y son las que uso yo.

La primera es el analizador de seguridad que tienes en las herramientas WordPress, que hace más de 30 comprobaciones sin tener siquiera que entrar a tu web y revisa cabeceras de seguridad, exposición de información, scripts sospechosos y archivos sensibles. No te dice si tienes XSS concretos, pero sí si tu web está bien armada contra esa clase de ataques.

Si tienes acceso a la web, o simplemente es la tuya, una versión mejor de la anterior es el analizador incluido en el plugin gratuito Vigilante, que ya sí analiza además las tripas de tu WordPress, desde dentro con lo que el escaneo es más profundo, y efectivo.

Las otras dos son las bases públicas de vulnerabilidades de plugins y temas WPScan y Patchstack. Busca por nombre cada uno de tus plugins activos y mira si tienen XSS reportados sin parchear, y si alguno está como «closed for download» o lleva meses sin que el autor responda en los foros, plantéate sustituirlo, porque las vulnerabilidades no se arreglan solas.

Si quieres una pista rápida sin instalar nada, abre tu web en el navegador, pulsa F12 y mira la consola, porque cuando aparecen mensajes con palabras tipo «Refused to execute», «Content Security Policy violation» o referencias a scripts de dominios que no reconoces, algo está pasando que merece la pena investigar.

Dónde frenes el XSS lo cambia todo

Igual que pasa con la fuerza bruta, no es lo mismo frenar un XSS a tres calles de tu casa que frenarlo cuando ya ha llegado al portal, y con XSS hay una diferencia que pesa todavía más, que es el daño potencial.

Un XSS que llega a ejecutarse en el navegador de un visitante puede robar su cookie de sesión y mandársela al atacante en milisegundos, y si ese visitante era un administrador, el atacante tiene admin de tu WordPress sin haber pasado nunca por wp-login.

Una vez dentro te instala una puerta trasera, modifica plugins, mete malware en archivos del tema y vienen los disgustos de verdad, así que cuanto más lejos del navegador del visitante frenes el ataque, mejor para todos.

La defensa funciona como tres filtros encadenados, cada uno más fino que el anterior. Lo que se le escapa al primero lo retiene el segundo, lo que pasa el segundo lo pilla el tercero, y si los tienes los tres bien puestos llega muy poca cosa al fondo.

• La CDN es el filtro más grueso, el que frena los patrones XSS conocidos antes de que la petición toque tu servidor, y desde donde puedes inyectar cabeceras de seguridad que mitigan el daño aunque el XSS exista.
• El hosting es el filtro intermedio, el que bloquea peticiones maliciosas que han pasado la CDN, mantiene PHP actualizado para tapar agujeros conocidos a nivel servidor y aísla tu cuenta del resto.
• WordPress es el filtro fino, donde se mantiene todo el ecosistema actualizado, se gestionan cabeceras y CSP, se filtran entradas y se escapa la salida cuando tocas código.

Ninguno de los tres sustituye a los otros, así que si uno falla los demás siguen filtrando. Vamos a por cada uno.

Filtro 1: la CDN como primer barrido

Una CDN seria delante de tu WordPress es la mejor inversión gratuita que puedes hacer en seguridad.

En los ejemplos uso, como siempre, Cloudflare porque es el que utilizo y tiene plan gratuito de sobra, pero Bunny Shield, KeyCDN o Sucuri Firewall ofrecen funciones equivalentes y los conceptos que vienen valen para cualquiera.

WAF gestionado contra patrones XSS

• Qué consigues: Que las peticiones con payloads XSS conocidos no lleguen ni siquiera a tu servidor, porque el filtrado ocurre en el borde de la red de Cloudflare a miles de kilómetros de tu hosting.
• Cómo funciona: El WAF aplica reglas basadas en el OWASP Core Rule Set que detectan patrones típicos de XSS como <script> en parámetros de URL, javascript: en valores donde se espera un URL, onerror= y compañía, y las peticiones que coinciden con esos patrones se bloquean o reciben un desafío automático.
• Cómo se hace en Cloudflare: El plan gratuito ya trae el OWASP Core Rule Set activado y lo encuentras en la sección de seguridad, en las llamadas «Conjunto de reglas administradas de Cloudflare» donde solo tienes que comprobar que esté en «On» y con nivel «Medium» o «High», porque con «Low» se cuelan demasiadas cosas. El plan Pro añade reglas gestionadas afinadas para WordPress.
• Pros: El filtrado lo gestiona Cloudflare con un equipo dedicado que actualiza las firmas constantemente y tú no tocas nada, los patrones nuevos se aplican solos.
• Contras: Ningún WAF gestionado pilla todo, sobre todo los XSS basados en DOM, porque el patrón malicioso no viaja en la petición HTTP, y los XSS específicos de un plugin concreto pueden no entrar en las firmas genéricas. Esto te quita un 80% del ruido, el otro 20% lo tiene que parar otra cosa.

Reglas personalizadas para tu caso

Las reglas gestionadas funcionan bien para lo común, pero si has detectado un patrón de ataque específico contra tu web te merece la pena crear reglas a medida en Seguridad → Reglas de seguridad, que se aplican antes que las gestionadas.

Una regla útil de partida es bloquear cualquier petición cuya cadena de consulta (query string) contenga las cadenas más típicas de inyección, algo así:

(http.request.uri.query contains "<script") or 
(http.request.uri.query contains "javascript:") or 
(http.request.uri.query contains "onerror=") or 
(http.request.uri.query contains "onload=")

La acción puede ser Block directo o Managed Challenge si prefieres dar opción a falsos positivos.

La gracia de estas reglas es que filtran lo que de verdad te ataca a ti, pero el coste es que tienes que revisar los logs cada cierto tiempo para detectar patrones nuevos y ajustar.

Cabeceras de seguridad desde la CDN

Esta es la jugada que casi nadie aprovecha y que es canela fina, porque puedes añadir o reescribir cabeceras de seguridad desde Cloudflare sin tocar tu servidor ni tu WordPress, y eso te viene de maravilla si tu hosting no te deja modificar cabeceras o quieres aplicar la misma política a varias webs de golpe.

En Cloudflare lo configuras en Reglas → Configuración → Encabezados de respuestas HTTP y activas las cabeceras que te interesen.

La más importante contra XSS es Content-Security-Policy, que le dice al navegador qué scripts puede ejecutar y desde dónde, de manera que aunque un atacante consiga meter un <script> en tu web, si viene de un dominio que no está en tu CSP el navegador se niega a ejecutarlo.

Las complementarias son X-Content-Type-Options con valor nosniff para evitar que el navegador interprete archivos de un tipo distinto del declarado, y Referrer-Policy con strict-origin-when-cross-origin para reducir la información que se filtra a sitios externos.

Si quieres montarte la CSP a medida sin pelearte con la sintaxis, tienes el generador de cabeceras de seguridad de Ayuda WordPress para sacar la cadena correcta con interfaz visual, y una vez la tengas la pegas en la regla de Cloudflare y listo.

La pega de la CSP es que configurarla bien lleva su tiempo, porque si te pasas de estricta rompes Google Analytics, Tag Manager, captchas y la mitad de los plugins que cargan recursos externos.

La estrategia que funciona es empezar con Content-Security-Policy-Report-Only durante una semana o dos, ver qué se rompería en producción real, ajustar y solo entonces pasar a la modalidad de bloqueo.

Modo Bot Fight

La mayoría de los ataques XSS son oportunistas, no dirigidos, y los lanza un bot que prueba miles de URLs con payloads conocidos a ver si pillan algo, así que filtrar bots ya te quita parte del ruido sin afectar a nadie real.

Lo activas en Seguridad → Configuración → Tráfico de bots → Modo Bot Fight y va solo, aunque conviene comprobar que tus servicios automatizados legítimos (monitorización, backups externos, y sobre todo pasarelas de pago) siguen funcionando bien después.

Filtro 2: el hosting como malla intermedia

El hosting tiene un papel en la defensa contra XSS que la mayoría subestima, porque no es donde se filtran las peticiones HTTP (de eso ya se ocupa la CDN) sino donde se cierran los huecos que permiten que un XSS escale a algo peor.

Sigo con SiteGround en los ejemplos porque es el hosting que uso y conozco a fondo, pero los hosting serios para WordPress traen funciones equivalentes en sus paneles.

WAF a nivel servidor

Los hosting de calidad traen mod_security con el OWASP Core Rule Set o un WAF propio que filtra ataques antes de que la petición llegue a PHP, y esto no es algo que tú configures, viene activado por defecto. Lo mejor es que preguntes a tu hosting, y si duda malo, empieza a buscar alteranativas.

SiteGround tiene un WAF propio con reglas escritas por su equipo de seguridad según van apareciendo vulnerabilidades nuevas en el ecosistema WordPress, y casi todos los buenos hosting ofrecen capas equivalentes.

Si tu hosting no te garantiza un WAF a nivel servidor, lo que tienes es un problema de hosting más que de WordPress.

Mantén PHP actualizado

Suena obvio pero te sorprendería saber cuántas webs hay funcionando todavía en PHP 7.2, 7.0 o incluso 5.6, y las versiones antiguas de PHP no reciben parches de seguridad.

La mayoría de XSS son problema de la aplicación y no del lenguaje, pero hay funciones de PHP relacionadas con el manejo de cadenas, la codificación de URLs y el filtrado de entrada que han recibido mejoras en cada versión, así que ejecutar la última versión te ahorra dolores de cabeza y disgustos.

WordPress recomienda PHP 8.3 o superior, y si estás por debajo cambia ya, que en la mayoría de hosting se hace desde el panel en dos clics.

Aislamiento entre cuentas

En hosting compartidos malos una web vulnerable puede contaminar a las vecinas en el mismo servidor, así que los hosting profesionales aíslan cada cuenta para que un compromiso en una web no afecte al resto.

SiteGround y otros lo llaman aislamiento de cuentas, y otros tienen nombres parecidos. No tienes que configurar nada, solo comprobar que tu hosting lo ofrece, y si no es razón suficiente para cambiarte.

El plugin de seguridad del hosting

Algunos hosting tienen su propio plugin de seguridad para WordPress, SiteGround tiene Security Optimizer, que se puede usar en cualquier hosting y no solo en SiteGround, otros no lo sé, pero pregunta.

Este tiene 2FA, URL de login personalizada, registro de actividad y ocultación de la versión de WordPress, aunque no incluye WAF de aplicación propio, así que conviene combinarlo con un plugin que sí lo traiga o con un WAF en CDN.

Y como siempre, si ya usas otro plugin de seguridad con WAF no instales dos a la vez, porque suelen pelearse.

Filtro 3: WordPress, el colador más fino

Esta es la capa donde más control tienes y la que más afecta a la defensa contra XSS específicos de WordPress, porque las capas anteriores frenan el ruido y los patrones conocidos, pero los XSS específicos de un plugin o un tema concreto solo los frenas desde aquí.

Mantén todo actualizado, esta es la regla número uno

La gran mayoría de XSS que afectan a WordPress vienen de plugins o temas con vulnerabilidades conocidas, parcheadas en versiones posteriores, en webs donde nadie actualiza desde hace meses. Si llevas las actualizaciones al día te ahorras el 80% del problema antes de que exista.

El plan es sencillo y se resume en tener actualizaciones automáticas activadas para todo, core, plugins y temas, sustituir cualquier plugin que lleve más de seis meses sin actualizar, y prescindir sí o sí de los que llevan más de un año o cuyo autor no responde en el foro de soporte.

El caso de Twenty20 es exactamente esto, un plugin abandonado con una vulnerabilidad reportada en WPScan desde hace tiempo, que solo se puede usar parchándolo por tu cuenta o sustituyéndolo por otro.

Lo que mucha gente no sabe es que ni siquiera los plugins de seguridad más populares son inmunes a estos problemas. Wordfence, con 5 millones de instalaciones activas, tiene 13 vulnerabilidades reportadas en WPScan, varias de XSS en su propio código en 2014, 2018 y 2022.

Las han ido parcheando en cada versión, pero si no actualizas el plugin de seguridad, ni el propio plugin de seguridad te protege, así que la actualización no es opcional ni accesoria, es la base de todo lo demás.

Plugin de seguridad con WAF de aplicación

Un plugin de seguridad con cortafuegos dentro de WordPress es la última red para todo lo que se cuela por las capas anteriores. Cuando entras en este terreno hay varias opciones gratuitas decentes, y la elección depende menos de cuál es mejor en abstracto y más de qué encaja con tu caso.

• All-In-One Security (AIOS) es muy completo, con reglas PHP firewall específicas contra XSS, las reglas 6G de Perishable Press, 2FA con integración nativa para WooCommerce, Elementor Pro y bbPress, smart 404 y audit log. Su cortafuegos depende mucho de .htaccess y en Nginx pierde parte de su fuerza, así que tenlo en cuenta si tu hosting es Nginx puro.
• Wordfence es el más popular, y trae WAF con base de firmas amplia gestionada por su equipo, que además es CNA y asigna identificadores CVE. En la versión gratuita las firmas nuevas se aplican con 30 días de retraso respecto a la Premium, ese es el modelo de negocio, pero como cortafuegos gratuito sigue cumpliendo relativamente bien. Yo tengo una mala opinión por otras cosas, pero tú decides.
• Vigilante es 100% gratis sin opciones de pago, con WAF de aplicación que filtra patrones XSS, SQLi y LFI, CSP visual, 2FA por correo y aplicación, escáner de integridad de archivos, modo bajo ataque y registro de auditoría de actividad. Es el que yo desarrollo y mantengo activamente, y que utilizo en todas mis. webs y las de mis clientes, está pensado para tener todo en un solo plugin sin pagar por nada. Como es nuevo todavía tiene poca base instalada, ese es su único pero (de momento).

Los tres bloquean payloads XSS conocidos a nivel de aplicación, y cuál elegir depende de si quieres todo en uno sin pagar (Vigilante o AIOS), si prefieres la base de firmas más amplia aceptando pagar por tenerla al día (Wordfence Premium), o si tu hosting es Apache y quieres aprovechar a tope las reglas .htaccess (AIOS).

Cabeceras de seguridad y Content Security Policy

La CSP es la cabecera que más frena los XSS con diferencia, porque aunque un atacante consiga meter un <script> en tu base de datos, si tu CSP solo permite scripts de tu propio dominio ese script externo no se ejecuta.

Si ya configuras las cabeceras desde Cloudflare en el filtro 1 no hace falta repetirlas aquí, sería duplicar trabajo, pero si no usas CDN o tu CDN no te deja tocar cabeceras, gestiónalas desde el plugin de seguridad.

Vigilante trae ajustes precisos para CSP, AIOS también gestiona cabeceras, y Security Optimizer las trae configuradas por defecto con valores razonables.

El generador de cabeceras de Ayuda WordPress te vale igual para sacar la cadena CSP a medida y pegarla donde te convenga, sea en el plugin, en el .htaccess o en una regla de Cloudflare.

2FA en todas las cuentas con permisos

Esta es defensa en profundidad pura, porque si un XSS consigue robar la cookie de sesión de un administrador, el atacante todavía no podrá iniciar sesión nueva en otro dispositivo sin el segundo factor, así que el daño queda limitado a la sesión activa que pueda exprimir antes de que la víctima cierre el navegador.

Activa la identificación en dos pasos para administradores, editores y autores, que es la gente con permisos suficientes para meterte un disgusto.

La mayoría de plugins de seguridad la traen integrada, pero si prefieres un plugin específico el más completo gratuito es Two-Factor.

HTML controlado en comentarios y formularios

WordPress filtra los comentarios por defecto con wp_kses, pero algunos plugins de comentarios o formularios desactivan ese filtrado para permitir formato enriquecido, y esto es mala idea casi siempre.

Si tienes que permitir HTML en comentarios, restringe las etiquetas a las imprescindibles (<p>, <a>, <b>, <i>) y no permitas nunca <script>, <iframe> ni <object>.

Y en plugins de formularios de contacto o captura de leads, comprueba que los datos del usuario se filtran antes de mostrarse en el panel de admin, porque si tu CRM o tu plugin de formularios pinta el último envío con un avance en el escritorio sin filtrar, ahí entra perfectamente un XSS almacenado dirigido contra ti.

Si tocas código hay tres reglas básicas

Si desarrollas plugins, temas personalizados o snippets que pegas en functions.php, tienes responsabilidad directa en la defensa contra ataques XSS, y las reglas son las mismas que pone la documentación oficial de WordPress.

1. Validar todo lo que entra, comprobando antes de hacer nada que el dato del usuario tiene el formato esperado, así que si esperas un número validas que es número, si esperas un email validas el email, y si esperas un valor de una lista cerrada (por ejemplo horizontal o vertical) rechazas cualquier otra cosa que no esté en la lista.
2. Sanear todo lo que guardas, pasando los datos por la función adecuada según el tipo, con sanitize_text_field() para texto plano, sanitize_email() para emails, esc_url_raw() para URLs que van a la base de datos, y wp_kses_post() o wp_kses() con una lista blanca de etiquetas cuando necesitas permitir algo de HTML.
3. Escapar todo lo que sacas, en cada sitio donde pintas algo en pantalla, usando la función adecuada según el contexto, con esc_html() para texto dentro de etiquetas, esc_attr() para valores de atributos, esc_url() para URLs y esc_js() para datos dentro de JavaScript inline.

El parche que escribí para el plugin Twenty20 abandonado, de nuevo, es el ejemplo perfecto de cómo aplicar las tres reglas en un caso real, porque el shortcode no validaba ni saneaba sus atributos y enganché un hook que los procesa antes de pasarlos al plugin original. Quedaba así:

// IDs de imagen: solo números o URLs válidas
$atts['img1'] = is_numeric( $atts['img1'] ) 
    ? absint( $atts['img1'] ) 
    : esc_url_raw( $atts['img1'] );

// Offset: decimal entre 0 y 1
$atts['offset'] = max( 0, min( 1, floatval( $atts['offset'] ) ) );

// Orientación: solo valores permitidos
$atts['orientation'] = in_array( $atts['orientation'], array( 'horizontal', 'vertical' ), true )
    ? $atts['orientation']
    : 'horizontal';

// Textos: saneados como texto plano
$atts['before_label'] = sanitize_text_field( $atts['before_label'] );
$atts['after_label']  = sanitize_text_field( $atts['after_label'] );

Cada atributo se valida según lo que se espera de él, así que los IDs van como números, el offset como decimal entre 0 y 1, la orientación como uno de dos valores fijos, y los textos pasan por el saneador estándar de WordPress.

Eso convierte un payload tipo before="<script>alert(1)</script>" en texto plano inofensivo. Tienes el parche completo en el artículo dedicado y el código en mi repositorio de GitHub por si te interesa curiosear.

Qué hago si ya están explotando un XSS en mi web

Si has detectado un XSS activo porque ves JavaScript raro en el código fuente, Google te ha marcado la web como peligrosa o algún visitante te ha avisado de que la web le redirige a sitios extraños, esto es lo que tienes que hacer, en orden, desde fuera hacia dentro.

Primero activa el modo bajo ataque en la CDN, que en Cloudflare lo tienes en el panel principal del dominio. Cualquier visitante pasa un desafío JavaScript antes de cargar la web y el ataque deja de propagarse mientras tú investigas. No es agradable para los visitantes legítimos, pero priorizas contener el daño.

A continuación localiza el origen del XSS. Si es reflejado viene por algún parámetro de URL, así que mira los logs del hosting buscando peticiones con cadenas raras, y si es almacenado está en tu base de datos, y en este caso busca en las tablas wp_posts, wp_postmeta, wp_options y wp_comments cualquier ocurrencia de <script, javascript:, onerror= u onload=. Donde encuentres algo en un campo que no debería tener HTML, ese es tu XSS.

Una vez localizado el origen, sea un plugin que no escapaba un parámetro o un tema personalizado que pintaba un custom field sin filtrar, desactiva al culpable desde el panel o renombrando la carpeta por FTP si te bloquea el acceso.

El tercer paso solo aplica si era XSS almacenado, y consiste en limpiar la base de datos, porque parchear el plugin no basta, el JavaScript malicioso sigue guardado y se ejecutará la próxima vez. Con WP-CLI lo haces así, primero en seco para ver qué afecta y luego en serio:

wp search-replace '<script>...código malicioso...</script>' '' --all-tables --dry-run

Cuando estés seguro de lo que va a cambiar quita el --dry-run y ejecútalo de verdad. Si no te apañas WP-CLI, lo mismo se hace con phpMyAdmin buscando el patrón en cada tabla afectada.

Primero localizas dónde está el patrón con la pestaña «Buscar» al nivel de base de datos (no de tabla). Entras en tu base de datos, pulsas en Buscar, pegas el código malicioso en el campo de búsqueda, marcas la frase exacta y seleccionas todas las tablas. Esto te dice en qué tablas y cuántas filas están afectadas sin tocar nada todavía.

Cuando ya sabes qué tablas tienen el problema, haces una copia de seguridad de la base de datos y pasas a la pestaña SQL para ejecutar el reemplazo real con la función REPLACE de MySQL. Las tablas habituales donde se aloja XSS almacenado son wp_posts, wp_postmeta, wp_options y wp_comments (ojo si tu prefijo no es wp_).

Para contenido de entradas y páginas:

UPDATE wp_posts
SET post_content = REPLACE(post_content, '<script>...código malicioso...</script>', '')
WHERE post_content LIKE '%<script>...código malicioso...%';

Para comentarios:

UPDATE wp_comments
SET comment_content = REPLACE(comment_content, '<script>...código malicioso...</script>', '')
WHERE comment_content LIKE '%<script>...%';

El WHERE no es imprescindible pero limita el UPDATE a las filas que realmente contienen el patrón, así evitas reescribir toda la tabla sin necesidad. phpMyAdmin te mostrará cuántas filas se han modificado al ejecutar la consulta, que es lo más parecido a la confirmación que da WP-CLI.

Precaución importante con los datos serializados: Las tablas wp_options (campo option_value) y wp_postmeta (campo meta_value) suelen contener arrays serializados de PHP, donde la longitud de cada string forma parte del propio dato. Si haces un REPLACE directo y el script malicioso está dentro de un valor serializado, vas a romper la serialización y dejar la opción o el meta inservibles. Aquí WP-CLI gana por goleada porque sabe deserializar y volver a serializar al vuelo. Si el patrón aparece en wp_options o wp_postmeta y no puedes usar WP-CLI, lo más seguro es editar manualmente cada fila afectada desde phpMyAdmin ajustando el contenido sin romper la estructura.

Un detalle con las comillas es que si el JavaScript malicioso tiene comillas simples dentro, escápalas con barra invertida (\') o cambia los delimitadores de la cadena SQL a comillas dobles.

El cuarto paso es forzar el restablecimiento de contraseñas de todos los administradores, porque si el XSS pudo robar cookies de sesión tienes que asumir que tu sesión está comprometida.

La mayoría de plugins de seguridad  (los buenos) traen una herramienta de restablecer contraseñas para todos los usuarios que invalida sesiones activas y obliga a iniciar sesión de nuevo, y aprovecha el momento para activar 2FA si no lo tenías.

Para finalizar revisa los logs y aprende del incidente. Mira el registro de actividad de tu plugin de seguridad para entender cuándo se metió el XSS, qué usuario o IP lo coló y qué pasó después, porque esa información te sirve para crear reglas nuevas en la CDN y reforzar la defensa contra el siguiente intento.

Errores típicos que cometemos todos al tratar con ataques XSS

Te lo digo desde la experiencia (mala), que es de lo que mejor se aprende, luego tú decides:

• Confiar solo en el plugin de seguridad, que es la última capa y no la primera, porque si todo el peso recae en él cada ataque consume recursos de PHP antes de que pueda filtrarlo.
• No usar CDN con WAF, cuando Cloudflare gratuito ya filtra patrones XSS conocidos y es la inversión cero más rentable que existe en seguridad WordPress.
• No mantener todo actualizado, porque la mayoría de XSS que afectan a WordPress vienen de plugins desactualizados con vulnerabilidades parcheadas en versiones posteriores, así que actualizar te ahorra el 80% del problema.
• Usar plugins abandonados, como el caso Twenty20, porque si el autor no actualiza no hay parches y las vulnerabilidades persisten para siempre. Busca alternativas o aplica parches comunitarios.
• Permitir HTML libre en comentarios o formularios, cuando casi nunca lo necesitas y siempre puedes restringir las etiquetas con wp_kses a las imprescindibles.
• No filtrar campos personalizados en plantillas a medida, porque si tu tema imprime un campo personalizado en la parte pública de la web sin pasar por esc_html() cualquiera con permisos para editar ese campo puede meterte scripts.
• Asumir que muchas instalaciones equivale a seguridad, cuando plugins con cientos de miles de instalaciones aparecen en WPScan con XSS reportados todos los meses y la popularidad no es garantía de nada.
• Configurar mal la CSP, porque una CSP demasiado laxa con unsafe-inline o unsafe-eval no defiende contra XSS y solo da sensación de hacerlo, mientras que una demasiado estricta rompe la web. La estrategia que funciona es empezar en modo Report-Only y refinar antes de poner en bloqueo.
• No tener copias de seguridad, porque si todo falla y un XSS escala a compromiso total del WordPress, una copia limpia es lo único que te salva.

El plan completo en plan chuleta

Aquí tienes el resumen aplicable de todo lo visto, de fuera hacia dentro, para que lo configures en orden y en una tarde.

Capa 1: CDN

Capa 2: Hosting

Capa 3: WordPress

Seguridad continua

Todo lo que ves aquí lo puedes configurar en poco rato, sin gastar dinero en plugins premium ni servicios de pago, porque la diferencia entre una web con XSS explotables y una web protegida no está en cuánto te gastes sino en si tienes los tres filtros montados y trabajando juntos. Si uno falla los otros siguen filtrando, esa es toda la gracia del asunto.

Si llevas tiempo sin revisar la seguridad de tu web empieza pasando el analizador de seguridad de Ayuda WordPress para ver qué tienes expuesto, busca tus plugins activos en WPScan, y monta los tres filtros siguiendo las tablas de arriba.

Cuando termines vuelve a pasar el analizador y verás la diferencia. Y, recuerda, por terminar por donde empecé, si tienes Twenty20 instalado, instálale el parche o sustitúyelo cuanto antes por otro plugin del tipo antes-después de los muchos que hay, que no es el único.

¿Dudas, abrazos, insultos? lo que quieras ahí abajo, en los comentarios.

Es raro porque, por si no lo sabías, WordPress sí crea automáticamente la etiqueta meta <title> a partir de, adivina, sí, a partir del título de la publicación (entrada, página, incluso el título del sitio), pero sin embargo no aprovecha el resto de lo que ya genera para hacer lo mismo para crear las meta description.

¡Oye!, ¿qué es eso de la meta description?

¡Ah, perdona!

La meta description es ese trozo de texto que Google muestra debajo del título en los resultados de búsqueda o que utiliza para los resúmenes que genera para las vistas creadas con IA. No afecta al posicionamiento directamente pero sí al CTR, que es lo que luego te trae visitas.

Si tienes un plugin SEO como Yoast o Rank Math ya se ocupan ellos, pero si no lo usas, o lo has quitado porque solo necesitas esta función concreta.

WordPress ya tiene los campos para generar una meta description decente, solo hay que aprovechar el dato correcto en cada tipo de página.

En este tutorial te dejo cuatro fragmentos de código, uno por cada caso de uso, los copias al functions.php del tema hijo, los pegas como mu-plugin o metes solo los que te interesen.

Al final del tutorial tienes también el combinado si lo prefieres todo en un archivo.

Qué campos nativos vamos a aprovechar

La idea es no reinventar nada, porque WordPress ya tiene sitios donde guardar descripciones y casi nadie los usa:

• La descripción corta del sitio (Ajustes → Generales) para la portada.
• El extracto de cada entrada y página.
• La descripción de cada categoría, etiqueta o taxonomía personalizada.
• La información biográfica del perfil de cada autor.

Si rellenas estos campos ya tienes las meta description únicas en cada tipo de página sin depender de ningún plugin. Y por supuesto, si no rellenas nada o no saldrá nada o saldrá cualquier cosa.

Un detalle importante, la prioridad

Los cuatro snippets de código enganchan con add_action( 'wp_head', ..., 1 ). La prioridad 1 coloca la etiqueta <meta name="description"> justo debajo del <title>, que es donde la esperan los bots y donde la ponen los plugins SEO serios.

Si dejas la prioridad por defecto (10), la meta aparece muy abajo en el <head>, mezclada con scripts y hojas de estilo. Funcionar, funciona igual, pero queda más limpio arriba.

Añadir automáticamente la meta description de la portada a partir la descripción corta

Lo primero es lo primero. La portada usa la descripción corta que tengas en Ajustes → Generales → Descripción corta.

Pero ojo, si ahí sigue poniendo «Just another WordPress site» o «Otro sitio WordPress«, eso es lo que va a ver Google, así que antes de nada cámbialo.

Este código contempla también el caso de que tengas una página estática como portada y otra página aparte asignada como blog (en Ajustes → Lectura). Para la página del blog usa su propio extracto, y si está vacío, se queda con la descripción corta del sitio.

/* Meta Description automática en portada a partir de la descripción corta */
add_action( 'wp_head', function() {
	$description = '';

	if ( is_front_page() ) {
		// Front page: tagline from Settings → General
		$description = get_bloginfo( 'description' );
	} elseif ( is_home() ) {
		// Blog page assigned to a separate page: excerpt of that page
		$blog_page_id = (int) get_option( 'page_for_posts' );
		if ( $blog_page_id ) {
			$description = get_post_field( 'post_excerpt', $blog_page_id );
		}
		// Fallback to the tagline if the blog page has no excerpt
		if ( empty( $description ) ) {
			$description = get_bloginfo( 'description' );
		}
	} else {
		return;
	}

	$description = trim( wp_strip_all_tags( $description ) );
	if ( ! empty( $description ) ) {
		echo '<meta name="description" content="' . esc_attr( $description ) . '">' . "\n";
	}
}, 1 );

Añadir automáticamente la meta description a entradas y páginas a partir del extracto

Para las entradas y páginas tira del campo de extracto que tienes en la barra lateral del editor (o debajo del contenido en el editor clásico).

Si has escrito uno a mano se usa tal cual, y si lo has dejado en blanco el código corta las primeras líneas del contenido hasta los 155 caracteres, que es lo que suele entrar en el resultado de Google.

Antes de cortar quita lo que no debería aparecer como texto plano, como los bloques de Gutenberg que no son texto (galerías, embeds, vídeos) y los shortcodes, para que no te salga [shortcode loquesea] en medio de la meta description.

El corte se hace en el último espacio antes del límite, así no dejas palabras partidas.

Un consejo que te doy es que si quieres usar el campo de extracto en las páginas (por defecto WordPress no lo muestra en páginas), añadas add_post_type_support( 'page', 'excerpt' ); a tu functions.php.

/* Meta description a partir del extracto de entradas o páginas */
add_action( 'wp_head', function() {
	if ( ! is_singular() ) {
		return;
	}

	$post = get_queried_object();
	if ( ! $post instanceof WP_Post ) {
		return;
	}

	// First try the manual excerpt
	$description = $post->post_excerpt;

	// Fallback: trim the content to 155 characters at the last space
	if ( empty( $description ) ) {
		$content = $post->post_content;

		// Remove Gutenberg blocks not meant for excerpts (when available)
		if ( function_exists( 'excerpt_remove_blocks' ) ) {
			$content = excerpt_remove_blocks( $content );
		}

		// Remove shortcodes so they don't leak into the description
		$content = strip_shortcodes( $content );

		// Strip all HTML and normalize whitespace
		$content = wp_strip_all_tags( $content );
		$content = trim( preg_replace( '/\s+/', ' ', $content ) );

		if ( mb_strlen( $content ) > 155 ) {
			$cut        = mb_substr( $content, 0, 155 );
			$last_space = mb_strrpos( $cut, ' ' );
			if ( false !== $last_space ) {
				$cut = mb_substr( $cut, 0, $last_space );
			}
			$description = $cut . '...';
		} else {
			$description = $content;
		}
	}

	$description = trim( wp_strip_all_tags( $description ) );
	if ( ! empty( $description ) ) {
		echo '<meta name="description" content="' . esc_attr( $description ) . '">' . "\n";
	}
}, 1 );

Añadir automáticamente la meta description para categorías, etiquetas y taxonomías personalizadas

Las categorías y etiquetas tienen un campo de descripción que casi nadie rellena y que es oro puro para el SEO. Lo tienes al editar cualquier categoría, en Entradas → Categorías → Editar → Descripción.

Lo mismo para etiquetas y para taxonomías personalizadas que hayas creado con algún plugin o tu tema.

Si rellenas ese campo este código lo usa como meta description del archivo de esa categoría o etiqueta. Si no lo has rellenado no hace nada, para no colar una meta description vacía o repetida.

*/ Añadir automáticamente meta description a taxonomías */
add_action( 'wp_head', function() {
	if ( ! ( is_category() || is_tag() || is_tax() ) ) {
		return;
	}

	$description = trim( wp_strip_all_tags( term_description() ) );
	if ( ! empty( $description ) ) {
		echo '<meta name="description" content="' . esc_attr( $description ) . '">' . "\n";
	}
}, 1 );

Añadir automáticamente la meta description para archivos de autor a partir de la biografía

Los archivos de autor son páginas que casi siempre se dejan sin meta description, y eso que tienen un campo clarísimo para rellenarla, el campo de información biográfica del perfil del usuario. Lo encuentras en Usuarios → Tu perfil.

Rellenar esa biografía con los datos reales del autor, experiencia, especialidad, formación, no solo te da una meta description automática.

Esta información también es una señal de E-E-A-T que Google y las IA que rastrean la web valoran cada vez más para saber quién escribe qué.

*/ Añadir automáticamente meta description al archivo de autor usando la bio */
add_action( 'wp_head', function() {
	if ( ! is_author() ) {
		return;
	}

	$description = trim( wp_strip_all_tags( get_the_author_meta( 'description' ) ) );
	if ( ! empty( $description ) ) {
		echo '<meta name="description" content="' . esc_attr( $description ) . '">' . "\n";
	}
}, 1 );

Cómo comprobar que funciona

Visita cualquier página de tu sitio con clic derecho → Ver código fuente, y busca meta name="description". Debe aparecer debajo del <title>, con el contenido que toque según el tipo de página que estés viendo.

Si usas un plugin SEO al mismo tiempo, vas a ver dos meta description, una del plugin y otra de estos snippets, y no es buena idea. En ese caso, o quitas el snippet o desactivas la meta description del plugin SEO, no tiene sentido que convivan ambos.

Si lo quieres todo en un solo archivo

Los cuatro fragmentos de código los tienes unificados en un mu-plugin listo para usar. Lo pegas en wp-content/mu-plugins/ (si no existe la carpeta, la creas) y se activa solo.

El código completo y los snippets sueltos que hemos visto antes también los tienes en el repositorio de GitHub por si prefieres copiarlos o descargarlos desde ahí.

Demasiados códigos para mi ¿no hay un plugin para eso?

Como me lo imaginaba, porque no todos somos de códigos, he preparado un plugin exactamente para esto, para aprovechar todo eso que ya tiene WordPress y generar las meta title ydescription sin que tengas que depender de un enorme y lleno de funcionalidades de todo pelaje plugin de SEO mega enorme.

Lo he llamado Native SEO Meta Tags, porque es eso, hacer SEO con las etiquetas meta, pero sin tener ni que pensar, generadas a partir de lo que ya tienes, de tu contenido.

Lo instalas, lo activas y listo, hace todo lo que hemos estado hablando. ¿Que prefieres aún definir manualmente alguna meta title o description?, pues también añade la típica cajita al editor de WordPress para que las personalices, pero es totalmente opcional.

Y ya estaría, con estos cuatro códigos tienes cubiertas las meta description de un sitio WordPress sin necesitar ningún enorme SEO, todo a partir de lo que ya genera WordPress a partir de tus contenidos.

Si luego quieres escalarlo y añadir también automáticamente las etiquetas Open Graph y Twitter Cards, ya es otra historia, pero la base la tienes montada con los campos de toda la vida.

No siempre se hace la llamada HTTP entera, pero sí comprueba el transient, y si ha pasado el tiempo que él considera oportuno, dispara la petición.

Lo hace con tres frecuencias distintas según la página que estás cargando:

• En Escritorio → Actualizaciones (update-core.php), cada minuto.
• En la pantalla de Plugins (plugins.php), cada hora.
• En el resto del wp-admin, cada 12 horas.

La primera es la peor, pues basta con que entres y salgas un par de veces en pocos minutos para que WordPress haga tres llamadas HTTP a WordPress.org (una para core, otra para plugins, otra para temas) solo por consultar algo que ya consultó hace cuarenta segundos.

En servidores justos, o con conexión saliente lenta, se nota y mucho, así que vamos a poner un poco de orden en estas cosas que se hacen sin tu permiso, para que consuman menos recursos, pero sin dejar de mantener segura tu web.

Qué dispara cada llamada

El mecanismo real son tres acciones enganchadas al hook admin_init:

• _maybe_update_core, que llama a wp_version_check().
• _maybe_update_plugins, que llama a wp_update_plugins().
• _maybe_update_themes, que llama a wp_update_themes().

Cada una mira el transient correspondiente y, si ha caducado, hace la llamada HTTP.

Si las quitas del admin_init el exceso de comprobaciones desaparece y solo queda el cron programado, que se lanza por defecto dos veces al día sin molestar a nadie.

El snippet para quitarlo

En un mu-plugin preferentemente:

/* Frenar comprobaciones de actualizaciones en cada carga de wp-admin
* WP-Cron sigue ejecutándose dos veces al día como siempre
*/
function ayudawp_remove_admin_update_checks() {
    remove_action( 'admin_init', '_maybe_update_core' );
    remove_action( 'admin_init', '_maybe_update_plugins' );
    remove_action( 'admin_init', '_maybe_update_themes' );
}
add_action( 'init', 'ayudawp_remove_admin_update_checks' );

Con esto se dejan de hacer esas llamadas fantasma en los logs de peticiones salientes y el escritorio carga más rápido, sobre todo si tienes muchos plugins instalados.

Lo que sigue funcionando

Sigues teniendo actualizaciones, no te preocupes. WP-Cron mantiene tres tareas programadas (wp_version_check, wp_update_plugins y wp_update_themes) que se ejecutan cada 12 horas y dejan el transient fresco.

Cuando entres al admin, las notificaciones del tipo hay una nueva versión aparecerán igual, solo que con datos cacheados hasta como mucho medio día, mucho más frecuente de lo que la mayoría de la gente suele actualizar.

Si alguna vez quieres forzar una comprobación manual, vas a Escritorio → Actualizaciones y pulsas Comprobar de nuevo. El enlace llama a wp_version_check() directamente y se salta todos los aplazamientos definidos.

Aviso importante con wp-cron desactivado

Este truco solo funciona bien si tu cron está activo. Si tienes DISABLE_WP_CRON en true en wp-config.php y no has configurado un cron de verdad en el servidor que llame a wp-cron.php, te quedas sin comprobaciones nunca, y eso sí es un problema de seguridad.

Comprueba con WP Crontrol que los tres hooks de actualizaciones están programados y ejecutándose, y si no lo están, soluciona primero el cron antes de aplicar este código.

Si te ha servido este truco tienes uno parecido para bajarle el ritmo al widget de salud del sitio y a su cron semanal que ejecuta en segundo plano.

Lo publiqué hace poco en la categoría de WPO del blog y van en la misma línea de ir metiendo tijera a todas esas tareas de fondo que ejecuta WordPress y que no aportan nada en el día a día.

Lo que pasa es que Weglot maneja el SEO multilenguaje de una forma distinta a otros plugins de traducción, y los sitemaps son el ejemplo más claro de esa diferencia.

Antes de meterte a cambiar nada, conviene saber qué hace Weglot por defecto, qué no hace, y si de verdad necesitas tocar algo o no. Y si vas a tocarlo, hay que saber con qué plugin de SEO lo combinas, porque cada uno se comporta diferente.

Cómo gestiona Weglot el SEO multilenguaje en WordPress

Lo primero es entender la lógica, porque Weglot no guarda las traducciones en tu base de datos como hacen WPML, Polylang o TranslatePress, las guarda en sus propios servidores y las inyecta en el código fuente de cada página cuando alguien visita la versión traducida.

En lo que afecta al SEO, hace cuatro cosas:

• Crea una URL única para cada idioma con un subdirectorio del tipo /es/, /fr/, /de/ a partir del código de dos letras del idioma.
• Añade automáticamente las etiquetas hreflang en el <head> del HTML, declarando todas las versiones de cada página.
• Traduce los meta tags (title, meta description, atributos alt) en el código fuente, no por JavaScript, así que Google los ve perfectamente.
• Marca las URLs traducidas con sus canonical correctos, apuntando a sí mismas.

Hasta aquí, todo bien, el problema viene con el mapa del sitio.

La realidad sobre los sitemaps multilenguaje de Weglot

Esto es lo que dice la documentación técnica oficial de Weglot, palabras textuales del centro de ayuda en su artículo sobre cómo editar el sitemap:

«Si quieres un sitemap multilenguaje igualmente, Weglot lo gestiona por ti. Sin embargo, esta funcionalidad solo está disponible bajo la integración por subdirectorios. Esta opción no está disponible para proyectos WordPress.»

O sea, que en WordPress, Weglot no genera un mapa del sitio multilenguaje propio ni añade las URLs traducidas a ningún sitemap existente. Su integración multilingüe de mapas del sitio existe, pero solo para webs con su proxy en subdirectorios, que es como funciona en otras plataformas, no la integración nativa de WordPress.

Llama la atención que el blog de marketing de Weglot diga lo contrario, hablando de que «genera sitemaps XML multilenguaje» como si fuera una característica más del plugin de WordPress. La documentación técnica desmiente esto, así que me lo explique, oiga.

La diferencia con WPML, Polylang y TranslatePress

La razón por la que Weglot tiene este problema y los demás no es importante para entenderlo antes de seguir.

WPML, Polylang y TranslatePress guardan las traducciones en la base de datos de tu WordPress como contenido real, y cada traducción es un post o un campo dentro del post, según el plugin. Eso significa que cualquier plugin de SEO que recorra los posts del sistema (que es como funcionan todos) las ve sin problema y las incluye en el mapa del sitio automáticamente.

Weglot guarda las traducciones en sus servidores remotos, y  cuando un visitante pide la versión en francés Weglot intercepta la respuesta y traduce el HTML al vuelo. Las traducciones nunca tocan tu base de datos, por tanto, cuando Yoast o Rank Math generan el mapa del sitio recorriendo tus posts no encuentran las versiones traducidas porque, técnicamente, no existen como contenido propio.

Esto tiene una ventaja, que es la que te cuenta Weglot, y es que tu base de datos no engorda con las traducciones. Pero también un inconveniente, el que estamos viendo, que las herramientas de tu web, de WordPress, no saben que existen.

¿Necesitas un sitemap multilenguaje si ya tienes hreflang?

Aquí es donde Weglot tiene su argumento, y no es un locurón, tiene lógica, pues Google permite declarar las versiones de idioma de una página de tres formas, y con cualquiera basta:

• Etiquetas hreflang en el <head> de cada página HTML.
• Cabecera HTTP hreflang.
• Etiquetas xhtml:link dentro del sitemap XML.

Como Weglot ya inyecta los hreflang en el head, técnicamente con eso le vale a Google. Así que según eso tendrían razón en argumentar que el mapa del sitio multilenguaje es redundante, si tu objetivo es Google.

El problema es que no todo el mundo posiciona solo en Google, y aunque sea tu caso, hay matices que conviene tener en mente:

• Bing tira más de mapas del sitio que Google y le viene bien tener todas las URLs declaradas, traducidas incluidas.
• Baidu, si te interesa el mercado chino, prácticamente exige sitemap dedicado por idioma para indexar bien.
• Si algo tengo comprobado es que los bots de IA lo primero que miran y devoran es el mapa del sitio.
• En sitios grandes con muchas URLs, un mapa del sitio completo acelera el descubrimiento de páginas nuevas. Si dejas las traducciones fuera Google las encontrará por enlaces internos pero más lento.
• Search Console permite seguir métricas por mapa del sitio, así que tener uno por idioma facilita ver problemas de indexación específicos de un mercado. Esto se puede compensar dando de alta cada subcarpeta como propiedad, pero implica más trabajo.

Vamos, por no enrollarme más, que si solo te importa Google y la web no es enorme, los hreflang en el head te valen. Ahora bien, si vendes en mercados con buscadores diferentes, si la web es grande, si te importa el tráfico que te pueda llegar de IAs, o si quieres tener Search Console limpio por idioma, te conviene tener las URLs traducidas en el mapa del sitio.

Qué hace Weglot con cada plugin de SEO o de sitemaps XML

El comportamiento por defecto, sin tocar código, es siempre el mismo, el sitemap solo lleva URLs del idioma original. Pero hay diferencias importantes según el plugin que uses, sobre todo a la hora de poder añadir las traducidas, así que vamos uno a uno.

Sitemap nativo de WordPress (wp-sitemap.xml)

Desde WordPress 5.5 hay un mapa del sitio nativo por defecto en wp-sitemap.xml. Si no usas ningún plugin de SEO ni de sitemaps XML y dejas que WordPress lo genere solo Weglot no lo toca.

El mapa del sitio nativo te muestra esto:

<urlset>
  <url>
    <loc>https://midominio.com/articulo-ejemplo/</loc>
  </url>
  <url>
    <loc>https://midominio.com/contacto/</loc>
  </url>
</urlset>

Las versiones /fr/articulo-ejemplo/, /de/articulo-ejemplo/ y demás traducciones no aparecen y no hay forma sencilla de añadirlas sin código. Tendrías que pelearte con los filtros wp_sitemaps_posts_entry o wp_sitemaps_index_entry de WordPress, y Weglot no proporciona snippet oficial para esto.

Yoast SEO

Yoast desactiva el mapa del sitio nativo de WordPress y genera el suyo propio en /sitemap_index.xml. Por defecto, instalando Weglot encima, el sitemap de Yoast sigue mostrando solo las URLs del idioma original. Si no haces nada al respecto las traducidas no aparecen.

Existe un apaño validado por un usuario del propio plugin Weglot en el foro oficial, y es usando el filtro wpseo_sitemap_url. No es solución oficial de Weglot pero funciona. Te lo enseño más abajo.

Rank Math

Aquí es donde Weglot sí ha hecho los deberes. Tiene una página específica en developers.weglot.com con un código oficial usando el filtro rank_math/sitemap/index. La pega es que ese snippet obliga a listar a mano las URLs de los sub-mapas que quieres traducir y desactiva el caché del sitemap, lo que en webs grandes puede pesar en rendimiento.

All in One SEO (AIOSEO)

AIOSEO menciona compatibilidad con Weglot pero no hay tutorial específico ni código oficial. El comportamiento es el mismo que con Yoast, solo URLs del idioma original. La buena noticia es que tiene dos filtros bien documentados que sirven para añadir URLs traducidas:

• aioseo_sitemap_additional_pages permite añadir URLs personalizadas a un sub-sitemap dedicado en addl-sitemap.xml. Para que funcione hay que activar la opción «Additional Pages» en los ajustes de AIOSEO.
• aioseo_sitemap_indexes permite añadir sub-mapas al índice general.

Hay que combinar uno de los dos con la API de Weglot para inyectar las traducciones. Enseguida lo vemos.

SEOPress

En octubre de 2025 Weglot y SEOPress anunciaron una colaboración comercial. A nivel de marketing está vendido como «la solución completa para SEO multilenguaje en WordPress»

Pero a nivel técnico, lo que SEOPress detecta automáticamente para sitemaps multilenguaje es WPML, Polylang, TranslatePress y Weglot, pero solo a efectos de NO duplicar URLs entre idiomas, no para incluir las traducidas que Weglot guarda en sus servidores.

El mapa del sitio de SEOPress (sitemaps.xml) sigue sin ver las URLs traducidas de Weglot.

SEOPress tiene varios filtros oficiales que se pueden aprovechar, sobre todo:

• seopress_sitemaps_single_url que filtra cada URL del sitemap de un post type concreto (existe desde SEOPress 5.3).
• seopress_sitemaps_urlset que filtra el bloque urlset entero antes de imprimirse.

El primero es el equivalente al wpseo_sitemap_url de Yoast, así que la lógica del código del foro de Weglot se puede adaptar a SEOPress sin demasiado problema. De nuevo, lo vemos en un momentito.

Google XML Sitemaps

Este es uno de los plugins de maps del sitio más veteranos y aún muy instalado. Por defecto genera su sitemap en /sitemap.xml sin tocar el de WordPress, y como el resto, no ve las URLs traducidas de Weglot.

La buena noticia es que tiene una API oficial documentada para que otros plugins añadan URLs al sitemap. Se basa en el hook sm_buildmap y el método AddUrl de la clase GoogleSitemapGenerator. Esto es lo más limpio que vas a encontrar en cuanto a integración.

Además tiene una opción de «Páginas adicionales» para añadir URLs sueltas a mano, que puede ser inabarcable cuando tienes que meter cientos de URLs traducidas, pero tenerlo lo tienes.

XML Sitemap & Google News

Otro plugin muy popular, sobre todo entre quien quiere control fino del mapa del sitio sin la mochila de un plugin SEO completo. El plugin de RavanH tiene la peculiaridad de ser uno de los más completos para añadir URLs personalizadas sin código.

Desde la versión 5.4 incluye una opción nativa en sus ajustes para «URLs personalizadas en el mapa del sitio» (añadir URLs sueltas a mano) y otra para «mapas del sitio externos». Esto último es útil si Weglot generase un sitemap externo para WordPress, pero ya hemos visto que no lo hace, así que esa segunda opción no nos sirve directamente para Weglot.

El plugin tiene un filtro pensado exactamente para este uso, xmlsf_custom_urls, que filtra el array de URLs personalizadas antes de que el mapa del sitio las procese. Es la forma limpia de añadir URLs traducidas sin tocar la opción almacenada en la base de datos. Lo veremos abajo, porque tiene un par de detalles importantes.

Soluciones con código para añadir las URLs traducidas

Aquí tienes todos los snippets ordenados por plugin. Pruébalos en staging antes de meterlos en producción, sobre todo los que no son oficiales de Weglot. Donde el snippet venga de fuente oficial te lo indico claramente.

Para Yoast SEO

Este viene del foro oficial del plugin Weglot en WordPress.org, escrito por un usuario y bendecido por un desarrollador del plugin. Funciona en versiones recientes de Yoast y Weglot pero no es código oficial de Weglot, tenlo en cuenta.

Usa el filtro wpseo_sitemap_url de Yoast para inyectar las URLs traducidas dentro del sitemap original, en lugar de duplicar sitemaps. Es el enfoque correcto según las directrices de Google:

add_filter( 'wpseo_sitemap_url', 'weglot_sitemap', 10, 2 );

function weglot_sitemap( $output, $url ) {

    $date = null;

    if ( ! empty( $url['mod'] ) ) {
        $date = date( 'c', strtotime( $url['mod'] ) );
    }

    $languages = weglot_get_destination_languages();
    $language_services = weglot_get_service( 'Language_Service_Weglot' );
    $request_url_services = weglot_get_service( 'Request_Url_Service_Weglot' );

    foreach ( $languages as $language ) {

        $wg_url = $request_url_services->create_url_object( $url['loc'] );
        $lang = $language_services->get_language_from_internal( $language['language_to'] );

        $output .= "\t<url>\n";
        $output .= "\t\t<loc>" . $wg_url->getForLanguage( $lang ) . "</loc>\n";
        $output .= empty( $date ) ? '' : "\t\t<lastmod>" . htmlspecialchars( $date ) . "</lastmod>\n";

        $images = '';
        if ( isset( $url['images'] ) && is_array( $url['images'] ) ) {
            foreach ( $url['images'] as $image ) {
                $images .= "<image:image><image:loc>{$image['src']}</image:loc></image:image>\n";
            }
            $output .= $images;
        }

        $output .= "\t</url>\n";

    }

    return $output;

}

Cómo queda el sitemap después de aplicar este snippet:

<urlset>
  <url>
    <loc>https://midominio.com/articulo-ejemplo/</loc>
    <lastmod>2026-04-15T10:30:00+00:00</lastmod>
  </url>
  <url>
    <loc>https://midominio.com/fr/articulo-ejemplo/</loc>
    <lastmod>2026-04-15T10:30:00+00:00</lastmod>
  </url>
  <url>
    <loc>https://midominio.com/de/articulo-ejemplo/</loc>
    <lastmod>2026-04-15T10:30:00+00:00</lastmod>
  </url>
</urlset>

Cada URL original aparece seguida de sus versiones traducidas, todo dentro del mismo sitemap. Si quieres excluir alguna URL de la traducción, el desarrollador de Weglot recomienda cambiar getForLanguage( $lang ) por getForLanguage( $lang, true ).

Para Rank Math

Sacado de la documentación para desarrolladores de Weglot. Dos códigos, uno para desactivar el caché del sitemap (necesario para que se actualice con tus cambios) y otro para añadir las URLs traducidas al índice del sitemap.

El primero, para desactivar el caché:

/**
 * Filter if XML sitemap transient cache is enabled.
 *
 * @param boolean $unsigned Enable cache or not, defaults to true
 */
add_filter( 'rank_math/sitemap/enable_caching', '__return_false' );

El segundo, para añadir las URLs traducidas. Tienes que editar el array $urls con las URLs reales de tus sub-sitemaps:

add_filter( 'rank_math/sitemap/index', function( $xml ) {
    // Fetch Weglot services
    $language_services = weglot_get_service( 'Language_Service_Weglot' );
    $request_url_services = weglot_get_service( 'Request_Url_Service_Weglot' );

    // List of URLs to be translated
    $urls = [
        "https://midominio.com/post-sitemap.xml",
        "https://midominio.com/page-sitemap.xml",
        "https://midominio.com/category-sitemap.xml",
    ];

    $destination_languages = weglot_get_destination_languages();
    foreach ( $urls as $url ) {
        $wg_url = $request_url_services->create_url_object( $url );

        // Iterate over each destination language
        foreach ( $destination_languages as $language_code ) {
            $language = $language_services->get_language_from_internal( $language_code['language_to'] );

            $translated_url = $wg_url->getForLanguage( $language );

            $xml .= '
                <sitemap>
                    <loc>' . esc_url( $translated_url ) . '</loc>
                    <lastmod>' . esc_html( date( 'c' ) ) . '</lastmod>
                </sitemap>';
        }
    }

    return $xml;
}, 999 );

Cómo queda el índice de sitemaps de Rank Math después:

<sitemapindex>
  <sitemap>
    <loc>https://midominio.com/post-sitemap.xml</loc>
    <lastmod>2026-04-15T10:30:00+00:00</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://midominio.com/page-sitemap.xml</loc>
    <lastmod>2026-04-15T10:30:00+00:00</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://midominio.com/fr/post-sitemap.xml</loc>
    <lastmod>2026-04-15T10:30:00+00:00</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://midominio.com/fr/page-sitemap.xml</loc>
    <lastmod>2026-04-15T10:30:00+00:00</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://midominio.com/de/post-sitemap.xml</loc>
    <lastmod>2026-04-15T10:30:00+00:00</lastmod>
  </sitemap>
</sitemapindex>

Limitación importante: hay que listar las URLs a mano. Si añades un nuevo tipo de contenido o Rank Math empieza a generar otro sub-sitemap, tendrás que actualizar el array. No es automático del todo.

Para SEOPress

Este código no viene de Weglot ni de SEOPress, lo he montado yo mismo adaptando la lógica del código de Yoast al filtro seopress_sitemaps_single_url de SEOPress, que está documentado oficialmente. Pruébalo bien antes de pasarlo a producción:

add_filter( 'seopress_sitemaps_single_url', 'ayudawp_seopress_weglot_sitemap', 10, 2 );

function ayudawp_seopress_weglot_sitemap( $url_xml, $url_data ) {

    if ( ! function_exists( 'weglot_get_destination_languages' ) ) {
        return $url_xml;
    }

    $original_url = isset( $url_data['loc'] ) ? $url_data['loc'] : '';
    $lastmod = isset( $url_data['lastmod'] ) ? $url_data['lastmod'] : '';

    if ( empty( $original_url ) ) {
        return $url_xml;
    }

    $languages = weglot_get_destination_languages();
    $language_services = weglot_get_service( 'Language_Service_Weglot' );
    $request_url_services = weglot_get_service( 'Request_Url_Service_Weglot' );

    foreach ( $languages as $language ) {

        $wg_url = $request_url_services->create_url_object( $original_url );
        $lang = $language_services->get_language_from_internal( $language['language_to'] );
        $translated_url = $wg_url->getForLanguage( $lang );

        $url_xml .= "<url>\n";
        $url_xml .= "\t<loc>" . esc_url( $translated_url ) . "</loc>\n";
        if ( ! empty( $lastmod ) ) {
            $url_xml .= "\t<lastmod>" . esc_html( $lastmod ) . "</lastmod>\n";
        }
        $url_xml .= "</url>\n";
    }

    return $url_xml;
}

El resultado es equivalente al de Yoast, las URLs traducidas se inyectan dentro del mismo sitemap, justo después de cada URL original. Si SEOPress te genera por ejemplo post-sitemap.xml, este filtro afecta a todas sus entradas.

Para AIOSEO

AIOSEO permite dos caminos, pero te dejo el más limpio, que usa el filtro aioseo_sitemap_additional_pages para crear un sub-mapa específico para las traducciones.

Primero, requisito imprescindible: ve a AIOSEO > Mapas del sitio > Páginas adicionales y activa la funcionalidad. Sin ese paso el filtro no se ejecuta, te pasa una página vacía con error si no lo activas.

Después añades este código usando tu método favorito:

add_filter( 'aioseo_sitemap_additional_pages', 'ayudawp_aioseo_weglot_additional_pages' );

function ayudawp_aioseo_weglot_additional_pages( $pages ) {

    if ( ! function_exists( 'weglot_get_destination_languages' ) ) {
        return $pages;
    }

    // URLs base que quieres traducir. Adáptalo a tus sub-sitemaps.
    $base_urls = array(
        home_url( '/' ),
        // Añade aquí las URLs que quieras incluir
    );

    $languages = weglot_get_destination_languages();
    $language_services = weglot_get_service( 'Language_Service_Weglot' );
    $request_url_services = weglot_get_service( 'Request_Url_Service_Weglot' );

    foreach ( $base_urls as $base_url ) {

        $wg_url = $request_url_services->create_url_object( $base_url );

        foreach ( $languages as $language ) {

            $lang = $language_services->get_language_from_internal( $language['language_to'] );
            $translated_url = $wg_url->getForLanguage( $lang );

            $pages[] = (object) array(
                'loc'        => $translated_url,
                'lastmod'    => gmdate( 'c' ),
                'changefreq' => 'weekly',
                'priority'   => 0.8,
            );
        }
    }

    return $pages;
}

Cómo queda el índice de AIOSEO:

<sitemapindex>
  <sitemap>
    <loc>https://midominio.com/post-sitemap.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://midominio.com/page-sitemap.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://midominio.com/addl-sitemap.xml</loc>
  </sitemap>
</sitemapindex>

Y dentro de addl-sitemap.xml aparecen las URLs traducidas que has añadido con el filtro. La pega es que es un sub-mapa aparte, no se mezclan con las originales como en Yoast o SEOPress, pero a ojos de Google es perfectamente válido.

Para Google XML Sitemaps

El plugin tiene una API oficial documentada en el archivo de documentación que se incluye con el plugin, basada en el hook sm_buildmap.

Esta es la forma correcta de añadir URLs externas:

add_action( 'sm_buildmap', 'ayudawp_google_xml_sitemaps_weglot' );

function ayudawp_google_xml_sitemaps_weglot() {

    if ( ! class_exists( 'GoogleSitemapGenerator' ) ) {
        return;
    }

    if ( ! function_exists( 'weglot_get_destination_languages' ) ) {
        return;
    }

    $generator = GoogleSitemapGenerator::GetInstance();

    if ( $generator === null ) {
        return;
    }

    // URLs originales que quieres traducir
    $original_urls = array(
        home_url( '/' ),
        // Añade aquí las URLs que quieras incluir
    );

    $languages = weglot_get_destination_languages();
    $language_services = weglot_get_service( 'Language_Service_Weglot' );
    $request_url_services = weglot_get_service( 'Request_Url_Service_Weglot' );

    foreach ( $original_urls as $original_url ) {

        $wg_url = $request_url_services->create_url_object( $original_url );

        foreach ( $languages as $language ) {

            $lang = $language_services->get_language_from_internal( $language['language_to'] );
            $translated_url = $wg_url->getForLanguage( $lang );

            // Parámetros: URL, lastmod (timestamp), changefreq, priority
            $generator->AddUrl( $translated_url, time(), 'weekly', 0.8 );
        }
    }
}

Cómo queda el sitemap, todo en un único archivo sitemap.xml mezclando originales y traducidas:

<urlset>
  <url>
    <loc>https://midominio.com/</loc>
    <changefreq>daily</changefreq>
    <priority>1.0</priority>
  </url>
  <url>
    <loc>https://midominio.com/articulo-ejemplo/</loc>
    <changefreq>weekly</changefreq>
    <priority>0.6</priority>
  </url>
  <url>
    <loc>https://midominio.com/fr/</loc>
    <changefreq>weekly</changefreq>
    <priority>0.8</priority>
  </url>
  <url>
    <loc>https://midominio.com/de/</loc>
    <changefreq>weekly</changefreq>
    <priority>0.8</priority>
  </url>
</urlset>

Tiene una limitación parecida a la de Rank Math, y es que hay que listar las URLs originales que quieres traducir. Si tienes pocas URLs base de las que cuelga todo, esto te vale, si tienes cientos de entradas y quieres todos traducidos, vas a tener que iterar dinámicamente sobre tus posts publicados, cosa que requiere más código.

XML Sitemap & Google News

El plugin tiene un filtro específico para esto, xmlsf_custom_urls, que es la forma documentada de inyectar URLs personalizadas sin tocar la base de datos. He revisado el código actual del plugin (versión 5.7.4) y este es el filtro correcto.

Hay dos peculiaridades que conviene saber antes:

• El plugin tiene dos modos de servidor de sitemap:
  1. «WordPress core» (delega en el sitemap nativo de WP) y «Plugin» (genera el sitemap propio). Se elige en Ajustes > XML Sitemap.
  2. El filtro xmlsf_custom_urls funciona en ambos, pero con un matiz que veremos.
• El formato del array que espera el plugin no son claves asociativas tipo Yoast/AIOSEO. Cada entrada es un array indexado donde el primer elemento es la URL: array( $url ) o array( $url, $priority ). El plugin lee $data[0] directamente.

Aquí va el snippet:

add_filter( 'xmlsf_custom_urls', 'ayudawp_xmlsf_weglot_custom_urls' );

function ayudawp_xmlsf_weglot_custom_urls( $custom_urls ) {

    if ( ! function_exists( 'weglot_get_destination_languages' ) ) {
        return $custom_urls;
    }

    if ( ! is_array( $custom_urls ) ) {
        $custom_urls = array();
    }

    // URLs originales que quieres traducir
    $original_urls = array(
        home_url( '/' ),
        // Añadir aquí más URLs base
    );

    $languages = weglot_get_destination_languages();
    $language_services = weglot_get_service( 'Language_Service_Weglot' );
    $request_url_services = weglot_get_service( 'Request_Url_Service_Weglot' );

    foreach ( $original_urls as $original_url ) {

        $wg_url = $request_url_services->create_url_object( $original_url );

        foreach ( $languages as $language ) {

            $lang = $language_services->get_language_from_internal( $language['language_to'] );
            $translated_url = $wg_url->getForLanguage( $lang );

            // Formato: array indexado, no asociativo. El plugin lee $data[0].
            $custom_urls[] = array( $translated_url );
        }
    }

    return $custom_urls;
}

Ahora viene el matiz importante, porque en modo «Plugin» del servidor de mapa del sitio este filtro se ejecuta directamente. Pero en modo «WordPress core» el provider de URLs personalizadas solo se registra si la opción xmlsf_urls ya tiene algún valor guardado en la base de datos. Es una comprobación que hace el plugin internamente:

// Línea 193 de inc/class-sitemap-core.php (versión 5.7.4)
if ( get_option( 'xmlsf_urls' ) ) {
    wp_register_sitemap_provider( 'custom', new Sitemaps_Provider_Custom() );
}

Dicho de otro modo, si nunca has añadido una URL manualmente desde el admin del plugin, en modo WordPress core el snippet de arriba no se va a ejecutar nunca, porque el provider ni siquiera está registrado.

Hay dos formas de solucionarlo:

• Manual: ve a Ajustes > XML Sitemap, sección de URLs pesonalizadas, y añade cualquier URL como placeholder (la página de inicio, por ejemplo). Con eso la opción ya tiene valor en la base de datos, el provider se registra y tu filtro empieza a funcionar.
• Automática: añade también un filtro a option_xmlsf_urls que devuelva un array no vacío cuando la opción esté vacía, así forzamos el registro. Hay que tener cuidado con la pantalla de admin para que no se contamine con URLs falsas.

La forma manual es perfectamente razonable, porque con una sola URL real añadida una vez resuelves el problema sin código adicional.

Cómo queda el índice del sitemap después de aplicar el código:

<sitemapindex>
  <sitemap>
    <loc>https://midominio.com/wp-sitemap-posts-post-1.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://midominio.com/wp-sitemap-posts-page-1.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://midominio.com/wp-sitemap-custom-1.xml</loc>
  </sitemap>
</sitemapindex>

Las URLs traducidas aparecen dentro del sub-mapa wp-sitemap-custom-1.xml (en modo WordPress core) o sitemap-custom.xml (en modo Plugin). Si prefieres que las traducidas se mezclen con las originales en su sub-mapa correspondiente no es viable con este plugin sin reescribir bastante de la lógica de generación.

Cuándo merece la pena este jaleo y cuándo no

Después de probarlo en varios sitios a las conclusiones que llego, por si te ahorra algún dolor de cabeza, son estas:

• Si tu web es pequeña, posicionas solo en Google y los hreflang están bien puestos, mejor no tocar nada. Weglot tiene razón en que es redundante.
• Si tu web es grande, con cientos o miles de URLs traducidas, mete el código que se ajuste a tu instalación. La indexación de las versiones nuevas será más rápida y tendrás Search Console más limpio.
• Si te interesa Bing, cualquier buscador que no sea Google o posicionar en IAs, mete el código sin pensarlo. Estos bots leen menos los hreflang y más los mapas del sitio.
• Si vas a dar de alta cada subcarpeta como propiedad separada en Search Console (que es buena práctica para multilenguaje), mete el código también, porque cada propiedad querrá su mapa del sitio específico.

Antes de pelearte con código, dale unas semanas a Search Console y mira si las URLs traducidas se están indexando bien por sí solas. Si lo están haciendo gracias a los hreflang y los enlaces internos del cambiador de idioma, no necesitas hacer nada.

Si ves que Google ignora los idiomas secundarios o que tarda mucho en encontrarlos, ahí es donde el mapa del sitio traducido empieza a justificarse por sí solo.

¿Que no te llega, que usas plugins SEO distintos a los seis que he cubierto aquí?, abre un ticket directamente al soporte de Weglot pidiendo el código adaptado, hasta donde he comprobado, suelen responder bastante bien. Y, por supuesto, aquí me tienes, pregunta lo que quieras abajo en los comentarios, como siempre.

La pregunta es otra, es una que no se hacen muchos y deberían, y es esa de … ¿deberías hacer tú ese plugin con IA, en tu caso concreto, para lo que tú quieres?

Y la respuesta no es la misma para todo el mundo. Depende de tres cosas que puedes responder en treinta segundos, y son qué tipo de plugin necesitas, qué nivel de programación tienes y qué riesgo asumes si algo falla.

A partir de ahí vamos a ver dónde tiene sentido tirar de IA y dónde es una mala idea.

Cuándo sí tiene sentido hacerte un plugin con IA

Hay un tipo de plugin que es justo lo que la IA hace mejor, y casualmente es el que más necesita la mayoría de la gente que tiene un WordPress.

Me refiero a los plugins pequeños y específicos, esos que resuelven un problema concreto tuyo y que jamás vas a publicar en wordpress.org porque a (casi) nadie más le sirven.

Por ejemplo:

• Un mu-plugin que añade una columna en el listado de entradas con un dato concreto que te interesa.
• Un fragmento que cambia el comportamiento del editor para tu flujo de trabajo.
• Una automatización interna que cruza datos entre dos plugins que ya tienes instalados.
• Un widget de escritorio personalizado para vigilar algo de tu web.
• Un shortcode a medida que te ahorra copiar y pegar el mismo HTML en cien lugares.

En estos casos la IA te resuelve en quince minutos lo que antes te costaba un día buscando códigos en internet y adaptándolos. Y como el código va a vivir en tu web y lo usas tú y nadie más, los riesgos son muy controlables.

También funciona bien para prototipos y proyectos. Si tienes una idea de plugin pero no sabes si va a funcionar comercialmente, montar una versión mínima con IA te permite validarla antes de invertir tiempo o dinero en hacer la versión seria.

La probabilidad de que ese prototipo acabe siendo el plugin definitivo es baja, pero como herramienta para validar el concepto es de lo mejor que hemos tenido en décadas.

Y queda otro caso del que poco he leído por ahí, que es aprender a programar con la IA. Le pides que te genere algo sencillo, le preguntas el porqué de cada decisión, y vas entendiendo el código.

La IA no te hace el trabajo, te lo explica mientras lo hace, y es una forma de las más rápidas de aprender desarrollo WordPress que he visto, no es un curso avanzado de programación profesional, pero ayuda mucho.

Cuándo no te lo recomiendo en absoluto

Hay otras situaciones donde tirar de IA para crear un plugin es la antesala del desastre. No porque la IA sea mala, sino porque el contexto pide cosas que la IA hoy en día no garantiza.

1. Cualquier plugin que vayas a publicar en el repositorio de wordpress.org sin revisar el código línea a línea. La gente que descarga un plugin desde el directorio oficial confía en que detrás hay alguien que entiende lo que hace. Si lo único que hay detrás eres tú con un prompt bien afinado, no tienes ese conocimiento, y un fallo de seguridad tuyo lo van a sufrir miles de instalaciones.
2. Cualquier plugin que toque pagos, datos bancarios, datos personales sensibles o el proceso de pago de una tienda. El riesto de ataque es enorme, las consecuencias de un fallo son legales además de técnicas, y aquí no vale el «lo he probado y va«.
3. El tercero es irónico pero pasa, y mucho, y me refiero a los plugins de seguridad. Si pides a una IA que te haga un plugin para mejorar la seguridad de tu WordPress, es probable que el propio plugin sea inseguro. He visto código generado con IA que añadía cabeceras de seguridad, sí, pero por el camino dejaba un endpoint REST sin permission_callback que daba acceso a cualquiera. Lo bueno tapado por lo malo. Y sí, yo tengo un plugin de seguridad, pero le pongo el doble o triple de revisión que a cualquier otra cosa que hago, me hago responsable, y llevo años desarrollando código para WordPress.
4. Plugins que vayas a usar en webs de clientes o vender como producto comercial sin auditar. El día que falle no estás solo tú en juego, está tu reputación profesional. Y si el cliente pregunta por qué pasó algo y la respuesta es «es que ese trozo lo hizo Claude«, la conversación va a ser jodida.

Lo que la IA hace mal cuando crea plugins

Pues sí, no todo son alegrías, porque hay problemas técnicos que aparecen una y otra vez en código generado por IA, sin importar cuál uses, ni siquiera cómo la uses.

Te lo cuento desde la experiencia de revisar mucho código generado y desde lo que recogen las propias guías de seguridad y rendimiento de WordPress.

• Saneado a medias: Las IAs casi siempre se acuerdan de sanitizar lo que reciben, pero a veces eligen la función equivocada. Te ponen sanitize_text_field() cuando deberían usar sanitize_email(), o esc_html() donde tocaba wp_kses_post(). El plugin no falla, pero o se carga datos legítimos o deja pasar cosas que no debería.
• Se te olvidan los nonces: En formularios sencillos suelen estar. En endpoints AJAX a veces sí. En endpoints REST casi nunca. Y si el plugin tiene una función de borrado o de modificación masiva, ahí tienes una vulnerabilidad CSRF de manual.
• Queries sin preparar: Cuando el código mete consultas SQL directas con $wpdb, hay una probabilidad muy alta de que falte el $wpdb->prepare(). Le has dicho a la IA que haga una consulta y la ha hecho, pero la concatenación de variables es la receta clásica de la inyección SQL.
• Capacidades sin comprobar: Los current_user_can() que faltan son uno de los fallos más típicos. La IA pone la lógica de la funcionalidad, pero se olvida de comprobar si el usuario que la está ejecutando tiene permiso. Y el resultado es que cualquier suscriptor llamando al endpoint puede hacer cosas que solo un administrador debería poder hacer.
• Faltan escapes: Imprimir variables sin esc_html(), sin esc_attr() o sin esc_url() es la base del XSS. La IA escapa los datos obvios pero se le escapan los menos obvios, sobre todo los que vienen de la base de datos, que ella asume seguros pero pueden no serlo si llegaron ahí desde otro sitio.
• Rendimiento desastroso: Queries dentro de bucles, posts_per_page a -1 sin pensárselo, transients dinámicos que llenan la tabla de opciones, scripts cargados en todas las páginas en lugar de solo donde hacen falta. Funciona en una web vacía, pero en una con tráfico real tumba el servidor.

Todo esto es solucionable, pero arreglarlo requiere saber identificarlo, y para identificarlo hace falta saber programar.

Si no sabes qué es un nonce o por qué es importante el permission_callback la IA puede generarte un plugin que parece perfecto y que en realidad es un coladero.

Y luego está el otro problema, el del día de mañana.

¿Quién mantiene ese plugin que has generado hoy cuando la IA del momento ya no esté disponible o haya cambiado tanto que ni entienda su propio código de hace dos años?

Si te interesa el lado del mantenimiento a largo plazo echa un vistazo a este artículo, ahí lo desarrollo a fondo.

Cinco preguntas para saber si TÚ deberías hacer plugins con IA

Antes de pedirle a la IA que te genere ese plugin, contéstate estas preguntas con sinceridad. Si la mayoría son positivas adelante, si tienes varias que como que no, pues mejor pensártelo dos veces.

¿Sabrías interpretar este código si la IA desapareciera mañana?

Si la respuesta es que no lo que tienes no es un plugin sino una caja negra que vas a tener que mantener a ciegas.

Para uso personal puede ir bien y aceptas el coste.  Ahora bien, para cualquier otro escenario es un problema, porque el día que algo falle y la IA del momento no sirva o cueste tres veces más, te toca pelear con código que nunca fue tuyo del todo.

¿Lo va a usar alguien más que tú?

Si la respuesta es no el riesgo está controlado, si te peta te jodes tú y punto.

Pero si la respuesta es que sí (clientes, usuarios del repositorio, miembros de tu comunidad), las consecuencias de un fallo se multiplican y la exigencia de calidad sube mucho.

La IA por sí sola no llega a ese nivel,  hace falta alguien que SEPA revisar y mejorar el código.

¿Toca dinero, datos personales o identificaciones?

Si la respuesta es sí ya tienes media decisión tomada. O lo escribes tú con la IA como copiloto y revisas cada línea entendiendo lo que hace, o se lo encargas a alguien que sepa.

Generar y publicar sin más es buscarse problemas serios.

¿Tendrías capacidad de auditar el código antes de ponerlo en producción?

Auditar no es leer y decir «parece que funciona», es comprobar punto por punto que la sanitización es correcta, los nonces están en su sitio, las capacidades se verifican, las queries están preparadas y los escapes de salida son los adecuados.

Si tienes ese conocimiento la IA es un turbo acojonante, pero si no lo tienes mejor empieza por aprender lo básico antes de montar cosas que no entiendes.

¿Aceptas la idea de que el plugin sea desechable?

A veces la respuesta correcta es que sí, que lo montas rápido, lo usas unos meses y cuando deje de servirte lo tiras y haces otro. En ese caso la IA encaja como anillo al dedo.

Pero si lo que quieres es montar algo que dure años y que evolucione la cosa es muy distinta.

Por dónde seguir

Si después de leer todo esto sigues teniendo claro que quieres hacerte tu plugin con IA, en el blog tienes casi de todo para hacerlo bien.

Empezando por la base teórica y subiendo nivel:

• Crear plugins con IA y crear un plugin con IA para los fundamentos.
• Vibe coding aplicado a plugins WordPress y vibe coding y agentic coding para entender los dos enfoques principales.
• IA para crear contenidos y código y el original sobre inteligencia artificial para crear contenidos y código para el contexto más amplio.

Yo mismo he hecho varios plugins con este tipo de procesos. VigIA, ese plugin de control y analítica de bots de IA del que tanto hablo, salió de horas de trabajo con asistencia de IA, igual que algunos de mis otros plugins.

La diferencia entre que esos plugins funcionen bien y los que ves circulando con fallos de seguridad básicos está exactamente en lo que te he contado en el apartado de los problemas técnicos.

Hay que revisar cada línea entendiendo lo que hace, no tragar con lo primero que sale y aplicar de manera sistemática las prácticas de seguridad y rendimiento que WordPress lleva años publicando.

La IA es una herramienta excelente para esto, pero como cualquier herramienta el resultado depende mucho menos de la herramienta y mucho más de quien la usa.