Si te dedicas al desarrollo con WordPress o gestionas webs de clientes las contraseñas de aplicación te van a interesar. Y si no las usas para nada también te interesa saber que están ahí activadas por defecto, con algunas implicaciones de seguridad que merece la pena conocer.

Esta guía cubre todo lo que necesitas saber sobre las contraseñas de aplicación de WordPress: qué son, cómo funcionan, para qué sirven, cómo crearlas (desde el panel, con PHP y con WP-CLI) y, sobre todo, los riesgos que tienen y cómo controlarlos.

Qué son las contraseñas de aplicación

Una contraseña de aplicación es una credencial que WordPress genera para que aplicaciones, scripts o servicios externos se identifique a través de la REST API (y también contra XML-RPC, aunque no debería) sin necesitar la contraseña real del usuario.

Lo más relevante:

• Son contraseñas de 24 caracteres (letras y números) que WordPress muestra agrupadas en bloques de 4 para que sean más legibles. Los espacios se ignoran al validarlas.
• Están vinculadas a un usuario concreto y heredan sus permisos. Si la crea un administrador la aplicación tendrá acceso de administrador.
• No sirven para entrar en wp-admin, solo funcionan para peticiones a la API.
• Se almacenan como hash en la tabla usermeta, no en texto plano.
• Solo se muestran una vez, en el momento de crearlas. Si la pierdes toca generar una nueva.
• Puedes crear varias para un mismo usuario, una por cada aplicación que necesite acceso.
• Se pueden anular individualmente.
• Por defecto solo funcionan con HTTPS.

Vienen incluidas en el núcleo de WordPress, no hace falta instalar nada. Si tu sitio funciona con WordPress 5.6 o superior (es decir, prácticamente cualquier instalación actualizada) ya las tienes disponibles.

Cómo funcionan por dentro

Cuando una aplicación hace una petición a la REST API envía las credenciales mediante HTTP Basic Authentication (RFC 7617). La cabecera Authorization lleva el nombre de usuario y la contraseña de aplicación codificados en Base64.

WordPress recibe esa petición, detecta que viene por una ruta de API y comprueba la contraseña contra los hashes almacenados en usermeta. Si coincide verifica la petición con los permisos del usuario asociado.

Un detalle importante a tener en cuenta es que WordPress solo intenta validar contraseñas de aplicación en contextos que considera «de aplicación«, que por defecto son la REST API y XML-RPC. Si una petición llega por otra vía no se procesan. Los desarrolladores pueden ampliar esto con el filtro application_password_is_api_request.

¿Sirven para algo?

Pues sí, de hecho si eres desarrollador o trabajas en una agencia que gestiona varias webs WordPress aquí es donde las contraseñas de aplicación empiezan a tener sentido.

Despliegues y automatización (CI/CD)

Scripts que publican contenido, limpian transients o gestionan plugins tras un despliegue se pueden identificar contra la REST API con una contraseña de aplicación en lugar de forzar en el código credenciales de usuario. Si trabajas con flujos de integración y despliegue continuo esto simplifica mucho la gestión de accesos.

Paneles de gestión para agencias

Si administras decenas de sitios de clientes puedes construir un panel propio que consulte el estado de cada web, lance actualizaciones o gestione usuarios en bloque, todo identificado con contraseñas de aplicación específicas para cada sitio.

Sincronización entre sitios

Mover contenido entre un entorno de staging y producción o sincronizar posts entre varios WordPress de una red, sin compartir contraseñas de usuario reales.

WordPress headless

Cuando usas WordPress como backend y el frontend va con Next.js, Nuxt u otro framework, las peticiones identificadas a la REST API necesitan credenciales. Las contraseñas de aplicación son la forma nativa de resolverlo.

Integraciones WooCommerce a medida

Sincronizar inventario con un ERP propio, gestionar pedidos desde herramientas internas o conectar sistemas de facturación. Cada integración puede tener su propia contraseña con acceso limitado al perfil necesario.

Scripts de mantenimiento

Limpieza de revisiones, comprobación de salud del sitio, informes periódicos automatizados, todo lo que un script necesita hacer de forma programada contra la API.

Apps móviles propias

Si desarrollas una app para que los clientes de una agencia publiquen contenido o gestionen sus webs sin entrar en wp-admin, la identificación con contraseñas de aplicación es la solución nativa.

Testing automatizado

Son muy prácticas para pruebas contra la REST API en entornos de desarrollo, sin tener que  arriesgar con credenciales reales. También funcionan para conectar servicios externos como Zapier o Make, o para hacer pruebas con Postman, pero esos son casos más puntuales.

La ventaja común a todos estos escenarios es triple:

1. No compartes tu contraseña real
2. Puedes anular el acceso de un script concreto sin tocar nada más
3. La automatización no se bloquea por el 2FA

Cómo crear y gestionar contraseñas de aplicación

Hay tres formas, desde el panel de administración, con PHP y con WP-CLI.

Desde el perfil de usuario (wp-admin)

Es la forma más directa y la que usará cualquier usuario que necesite crear una.

1. Entra en Usuarios → Perfil (o edita el perfil de otro usuario si eres administrador).
2. Baja hasta la sección Contraseñas de aplicación.
3. Escribe un nombre descriptivo para identificar la aplicación (por ejemplo: «Script para producción», «Panel de agencia», «Aplicación móvil»).
4. Pulsa en «Añadir nueva contraseña de aplicación»
5. Copia la contraseña inmediatamente porque no se vuelve a mostrar.

En esa misma sección puedes ver las contraseñas creadas, cuándo se usaron por última vez, desde qué IP y anularlas individualmente.

Con PHP

Desde WordPress 5.6 tienes la clase WP_Application_Passwords para gestionar contraseñas de aplicación por código. Esto es lo que usarías en un plugin o en un mu-plugin para automatizar la creación.

// Crear una contraseña de aplicación para el usuario con ID 1
$user_id = 1;
$app_name = 'Mi script de despliegue';

$result = WP_Application_Passwords::create_new_application_password(
    $user_id,
    array( 'name' => $app_name )
);

if ( is_wp_error( $result ) ) {
    // Error al crear la contraseña
    error_log( $result->get_error_message() );
} else {
    // $result[0] = la contraseña en texto plano (solo ahora)
    // $result[1] = array con los datos almacenados (uuid, name, etc.)
    $password = $result[0];
    $app_data = $result[1];
    
    // Guarda $password de forma segura, no se puede recuperar después
}

Para listar las contraseñas de un usuario:

// Obtener todas las contraseñas de aplicación de un usuario
$passwords = WP_Application_Passwords::get_user_application_passwords( $user_id );

foreach ( $passwords as $app_pass ) {
    // $app_pass['name'] = nombre de la aplicación
    // $app_pass['uuid'] = identificador único
    // $app_pass['created'] = timestamp de creación
    // $app_pass['last_used'] = timestamp del último uso
    // $app_pass['last_ip'] = última IP que la usó
}

Para anular una contraseña concreta por su UUID:

// Anular una contraseña de aplicación específica
$uuid = 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx';
$deleted = WP_Application_Passwords::delete_application_password( $user_id, $uuid );

if ( is_wp_error( $deleted ) ) {
    error_log( 'No se pudo anular: ' . $deleted->get_error_message() );
}

Y para anular todas las de un usuario de golpe:

// Anular todas las contraseñas de aplicación de un usuario
WP_Application_Passwords::delete_all_application_passwords( $user_id );

Con WP-CLI

Si gestionas el servidor por SSH, WP-CLI te permite hacer lo mismo desde el terminal:

# Crear una contraseña para el usuario con ID 1
wp user application-password create 1 "Script de despliegue"

# Crear y mostrar solo la contraseña (útil para scripts)
wp user application-password create 1 "Script CI" --porcelain

# Listar contraseñas con detalle
wp user application-password list 1 --fields=uuid,name,created,last_used,last_ip

# Anular una contraseña por UUID
wp user application-password delete 1 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

La documentación completa está en la referencia de WP-CLI.

Ejemplo práctico: autenticación con la REST API

Una vez que tienes una contraseña de aplicación usarla es sencillo. Las peticiones van con HTTP Basic Auth, pasando el nombre de usuario y la contraseña de aplicación.

Leer datos del usuario autenticado

curl --user "tuusuario:xxxx xxxx xxxx xxxx xxxx xxxx" \
  https://tusitio.com/wp-json/wp/v2/users/me

Crear una entrada nueva

curl --user "tuusuario:xxxx xxxx xxxx xxxx xxxx xxxx" \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"title":"Entrada de prueba","content":"Creada desde la API","status":"draft"}' \
  https://tusitio.com/wp-json/wp/v2/posts

Listar los ajustes del sitio

curl --user "tuusuario:xxxx xxxx xxxx xxxx xxxx xxxx" \
  https://tusitio.com/wp-json/wp/v2/settings

Los espacios en la contraseña se pueden incluir o no, WordPress los elimina antes de validar. Si usas la contraseña en un script, es más práctico quitarlos.

Lo mismo con PHP

Si prefieres hacerlo desde PHP con la HTTP API de WordPress (por ejemplo, desde otro WordPress o desde un script):

// Petición identificada a la REST API de otro sitio WordPress
$response = wp_remote_get(
    'https://otrowp.com/wp-json/wp/v2/posts',
    array(
        'headers' => array(
            'Authorization' => 'Basic ' . base64_encode( 'usuario:xxxxxxxxxxxxxxxxxxxxxx' ),
        ),
        'timeout' => 10,
    )
);

if ( ! is_wp_error( $response ) && 200 === wp_remote_retrieve_response_code( $response ) ) {
    $posts = json_decode( wp_remote_retrieve_body( $response ), true );
    // Procesar los posts
}

Riesgos de usar las contraseñas de aplicación de WordPress

Las contraseñas de aplicación son una buena solución para la identificación programática, pero tienen algunos puntos chungos que conviene que tengas claros.

Se saltan el 2FA, los CAPTCHA y los límites de login

Este es el más gordo. Cuando WordPress detecta que una petición viene por la API con una contraseña de aplicación la identifica directamente, la da por buena. No pide doble verificación, no muestra CAPTCHA y no aplica los límites de intentos de acceso que tengas configurados. Es lógico, porque una máquina no puede resolver un CAPTCHA, pero significa que si alguien consigue una contraseña de aplicación tiene acceso directo y no le afecta ninguna medida de seguridad para el inicio de sesión.

Todos los usuarios pueden crearlas

Por defecto, cualquier usuario registrado puede generar contraseñas de aplicación desde su perfil, incluidos los suscriptores. En la mayoría de los sitios los suscriptores no necesitan acceso a la API, así que dejarles crear credenciales persistentes para ello es dejar abierta una posible vía de ataque innecesaria.

No caducan

Una contraseña de aplicación es válida hasta que alguien la revoque manualmente. No hay caducidad automática ni recordatorios de renovación. Si creas una, la usas tres meses para un proyecto y luego te olvidas de ella, seguirá funcionando indefinidamente.

No tienen permisos selectivos

La contraseña hereda los permisos completos del usuario que la crea. No puedes limitar una contraseña de aplicación para que solo pueda leer entradas pero no crearlas, o para que solo acceda a ciertos endpoints. Si la crea un administrador tiene acceso de administrador a toda la API.

Fuerza bruta contra la API

Aunque las contraseñas son largas (24 caracteres alfanuméricos) la protección contra fuerza bruta depende de lo que tengas configurado a nivel de servidor o de plugin de seguridad. WordPress por defecto no limita los intentos de identificación en la REST API de la misma forma que limita los intentos de login en wp-login.php.

Funcionan también sobre XML-RPC

Las contraseñas de aplicación no solo autentican peticiones a la REST API, también sirven para XML-RPC. Y XML-RPC es un protocolo que arrastra problemas de seguridad desde hace años: permite ataques de fuerza bruta amplificados (con system.multicall puedes probar cientos de contraseñas en una sola petición), es vector habitual de ataques DDoS y ofrece una superficie de ataque que la REST API ya cubre con más control.

La mayoría de los sitios WordPress actuales no necesitan XML-RPC para nada. Tenía sentido cuando se usaban clientes de escritorio como Windows Live Writer o la app móvil antigua, pero hoy la REST API lo sustituye en todos los escenarios. Sin embargo, XML-RPC sigue activado por defecto en WordPress, y las contraseñas de aplicación le dan una vía de identificación adicional.

Si no usas XML-RPC (y casi seguro que no lo usas) lo más sensato es desactivarlo. Plugins como Vigilant lo bloquean por defecto nada más activarlo, sin que tengas que configurar nada. También puedes hacerlo manualmente añadiendo add_filter( 'xmlrpc_enabled', '__return_false' ); a un mu-plugin.

Entonces, ¿son un riesgo real?

Depende del contexto. Algunos plugins de seguridad como Shield Security argumentan que si nunca creas una contraseña de aplicación el sistema no intenta validar por esa vía, así que el riesgo sería mínimo. Y tienen razón en parte, porque si no las usas no añaden posibilidad de ataque.

Pero el problema es que están activadas por defecto para todos los usuarios, y no todo el mundo sabe qué son ni qué implicaciones tiene crearlas. Para un sitio con pocos usuarios de confianza no supone un drama, para uno con registro abierto y cientos de suscriptores es un punto que vale la pena controlar.

Buenas prácticas de seguridad

Si vas a usar contraseñas de aplicación sigue estas pautas:

• Una contraseña por aplicación: Así puedes anular el acceso de una integración sin afectar a las demás.
• Mínimo privilegio: No crees la contraseña desde una cuenta de administrador si la aplicación solo necesita leer o editar posts. Usa un usuario con perfil de editor o autor.
• Revisa periódicamente: Comprueba las contraseñas activas de cada usuario y revoca las que ya no se usen.
• Guarda las contraseñas de forma segura: Trátalas como cualquier otra credencial sensible: gestor de contraseñas, variables de entorno, nunca en el código fuente.
• Monitoriza el uso: WordPress registra la fecha y la IP del último uso de cada contraseña. Si ves algo raro, revoca.
• Limita quién puede crearlas: Si tus usuarios no necesitan acceso a la API, desactívalas para sus perfiles.

Cómo desactivar o controlar las contraseñas de aplicación

Si has decidido que no las necesitas, o que quieres limitar quién puede usarlas, tienes varias opciones.

Desactivarlas para todo el sitio (PHP)

Con una línea en un mu-plugin o en functions.php puedes desactivar la funcionalidad por completo:

// Desactivar las contraseñas de aplicación en todo el sitio
add_filter( 'wp_is_application_passwords_available', '__return_false' );

Esto hace que desaparezca la sección del perfil de usuario y que las contraseñas existentes dejen de funcionar.

Limitarlas por perfil de usuario (PHP)

Si quieres que solo los administradores puedan crearlas y usarlas, puedes filtrar por usuario:

// Solo permitir contraseñas de aplicación a administradores
add_filter( 'wp_is_application_passwords_available_for_user', 'ayudawp_limitar_app_passwords', 10, 2 );
function ayudawp_limitar_app_passwords( $available, $user ) {
    // Solo administradores pueden crear y usar contraseñas de aplicación
    if ( ! user_can( $user, 'manage_options' ) ) {
        return false;
    }
    return $available;
}

Esto es lo más recomendable en la mayoría de los sitios: mantener la funcionalidad disponible para quienes realmente la necesitan y cerrarla para el resto.

Forzar su funcionamiento sin HTTPS (solo para desarrollo)

Por defecto, las contraseñas de aplicación solo se procesan en conexiones HTTPS. Si estás en un entorno de desarrollo local sin certificado SSL, puedes forzar su disponibilidad:

// Permitir contraseñas de aplicación sin HTTPS (solo en local)
add_filter( 'wp_is_application_passwords_available', '__return_true' );

No uses esto en producción. Las credenciales viajan en texto plano por HTTP y cualquiera que intercepte el tráfico puede leerlas.

Con plugins

Si prefieres no tocar código hay plugins que te lo resuelven con un clic. El plugin Vigilant (gratuito) incluye la opción de desactivar las contraseñas de aplicación desde su módulo de seguridad en el acceso. También existe Disable Application Passwords que hace solo eso, es una sola función, lo activas y listo. Otros plugins como WP Cerber o Advanced Access Manager ofrecen control más detallado por perfiles si es algo que necesitas de manera específica.

Filtros y ganchos disponibles para desarrolladores

Si estás desarrollando un plugin que interactúa con las contraseñas de aplicación estos son los filtros que te interesan:

• wp_is_application_passwords_available: Controla si la funcionalidad está disponible en el sitio (true/false).
• wp_is_application_passwords_available_for_user: Controla si un usuario concreto puede crear y usar contraseñas de aplicación.
• application_password_is_api_request: Permite marcar peticiones que no sean REST API ni XML-RPC como «peticiones de aplicación» para que WordPress valide contraseñas de aplicación en ellas.
• wp_is_application_passwords_supported: Comprueba si el entorno admite la funcionalidad (requiere HTTPS por defecto).

La clase principal es WP_Application_Passwords y los endpoints REST están en /wp/v2/users/<user_id>/application-passwords. La guía de integración original del equipo de WordPress Core sigue siendo la referencia técnica más completa.

Preguntas frecuentes

¿Se pueden usar para entrar en wp-admin?

No. Las contraseñas de aplicación solo funcionan para autenticar peticiones a la REST API y XML-RPC. Si intentas iniciar sesión en wp-login.php con una contraseña de aplicación, WordPress la rechazará.

Si cambio mi contraseña de WordPress, ¿dejan de funcionar?

No. Las contraseñas de aplicación son independientes de la contraseña del usuario. Cambiar una no afecta a la otra. Para invalidar una contraseña de aplicación tienes que anularla explícitamente.

¿Funcionan sin HTTPS?

Por defecto, no. WordPress las desactiva en conexiones HTTP para evitar que las credenciales viajen en texto plano. Se puede forzar con un filtro, pero solo tiene sentido en desarrollo local.

¿Puedo limitar lo que puede hacer cada contraseña?

No directamente. La contraseña hereda los permisos del usuario que la creó. No hay un sistema nativo de scopes o permisos por contraseña. La forma de limitar es crear la contraseña desde un usuario con el perfil mínimo necesario.

¿Son compatibles con plugins de seguridad?

Depende del plugin. Algunos como Wordfence, Shield Security o WP Cerber tienen compatibilidad específica para contraseñas de aplicación, otros pueden bloquearlas o interferir con la verificación de la API. Si usas un plugin de seguridad y las contraseñas de aplicación no te funcionan revisa sus ajustes de API y autenticación.

¿Cuántas puedo crear por usuario?

No hay límite definido por WordPress. Puedes crear tantas como necesites, aunque lo sensato es tener una por cada integración y anular las que ya no uses.

¿Qué pasa con las contraseñas existentes si desactivo la funcionalidad?

Si desactivas las contraseñas de aplicación con el filtro wp_is_application_passwords_available o un plugin de seguridad o rendimiento las contraseñas existentes dejan de funcionar. No se borran de la base de datos, pero WordPress no las valida. Si vuelves a activar la funcionalidad seguirán ahí y volverán a funcionar.

Documentación oficial y referencias

• Application Passwords – Advanced Administration Handbook (WordPress.org).
• Application Passwords: Integration Guide (Make WordPress Core).
• wp user application-password (referencia WP-CLI).
• Repositorio original en GitHub (el plugin que se integró en el core).

Algunos se ven directamente en pantalla tal cual, con sus corchetes y todo, otros no se ven porque WordPress los ignora en silencio, pero siguen ocupando espacio, ensuciando el HTML que ve Google y ralentizando las consultas a la base de datos. En los casos más extremos, como cuando usabas un maquetador visual basado en shortcodes, pueden dejar páginas enteras completamente ilegibles.

Este artículo cubre absolutamente todo lo que necesitas saber sobre los shortcodes huérfanos, qué son exactamente, por qué aparecen, dónde se esconden (en más sitios de los que crees), cómo encontrarlos con diferentes herramientas y todos los métodos disponibles para eliminarlos o neutralizarlos, desde el más sencillo hasta el más avanzado, para todos los niveles, con código listo para usar.

Qué es un shortcode y por qué se queda huérfano

Un shortcode es ese fragmento entre corchetes que WordPress interpreta y convierte en algo concreto, ya sea un formulario de contacto, un slider, una galería de imágenes, un botón, un bloque de contenido, una restricción de acceso. Lo registra el plugin o el tema que lo utiliza a través de la función add_shortcode(), y mientras ese plugin o tema está activo, WordPress sabe exactamente qué hacer con él.

El problema llega cuando ese plugin ya no está. Si desinstalaste el plugin, cambiaste de tema o simplemente lo desactivaste sin limpiar el contenido antes, los shortcodes se quedan ahí, huérfanos, sin nadie que los interprete. A partir de ese momento pueden pasar dos cosas:

1. Que WordPress los ignore y no muestre nada, que es el comportamiento más habitual en versiones modernas de WordPress. El shortcode está en la base de datos pero no se procesa, así que en pantalla no aparece nada donde antes había algo.
2. Que WordPress los muestre literalmente en pantalla, tal cual, con sus corchetes. Esto depende de cómo está configurado WordPress y de si hay algún filtro interviniendo.

Lo segundo es lo peor porque tus visitantes ven algo así en medio del texto de una página que debería tener un formulario de contacto:

[contact-form-7 id="48" title="Formulario de contacto"]

O algo bastante más caótico si era de un maquetador visual:

[et_pb_section fb_built="1" _builder_version="4.16.0"][et_pb_row _builder_version="4.16.0"][et_pb_column type="4_4" _builder_version="4.16.0"][et_pb_text _builder_version="4.16.0"]Tu contenido de aquí[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]

Ninguna de las dos situaciones es buena. Aunque no se vean hay razones suficientes para limpiarlos.

Nota: Revisa manualmente los códigos de ejemplos para Contact Form 7, no los apliques directamente porque como yo lo uso y se rompería la página al tratar de mostrarlos les he añadido un espacio entre el primer corchete ([) y el identificador contact-form-7).

El impacto en SEO, rendimiento y base de datos de los shortcodes huérfanos

El argumento de que los shortcodes no afectan al SEO porque Google solo ve el HTML es verdad a medias.

Si el plugin está activo y el shortcode se procesa correctamente Google ve el HTML resultante, hasta aquí bien. Pero si el shortcode está huérfano y aparece en pantalla como texto en crudo, Google lo ve exactamente igual que un visitante humano, como texto basura que no aporta nada al contenido de la página.

Incluso cuando no se muestran en pantalla, los shortcodes de maquetadores generan un volumen de código en la base de datos que puede ser enorme. Una sola página construida con el viejo Visual Composer puede tener KBs de shortcodes almacenados en post_content.

Ese contenido tiene que viajar de la base de datos al servidor con cada carga de página, procesarse y descartarse. En webs con muchas páginas eso es un montón.

En cuanto al rendimiento, cada shortcode que aparece en el contenido pasa por el sistema de procesado de shortcodes de WordPress aunque devuelva vacío. No es dramático en una web pequeña pero en una instalación grande con cientos de entradas heredadas puede tener un impacto alto en los tiempos de respuesta.

Y luego está la cuestión de mantenimiento, porque una base de datos limpia es más fácil de auditar, de migrar y de depurar cuando algo falla.

¿De quién es la culpa de que haya shortcodes huérfanos?

Antes de ponerse a buscar y eliminar, conviene tener claro de dónde viene el problema en tu caso concreto. Los orígenes más habituales son los que te cuento a continuación, habrá más (o no) pero estos están seguro.

Maquetadores visuales

Son los mayores generadores de shortcodes huérfanos por volumen. Divi, WP Bakery (antes Visual Composer), Beaver Builder, King Composer, SiteOrigin y otros. Todos ellos (o al menos sus versiones más antiguas) almacenan el contenido de tus páginas como shortcodes en la base de datos. Cuando cambias de maquetador o de tema sin migrar el contenido primero, lo que queda puede ser cientos o miles de líneas de shortcodes en cada página.

Plugins de formularios

Este es el caso que más se pasa por alto y que más shortcodes huérfanos genera en todo tipo de webs. Contact Form 7 es el plugin de WordPress más instalado del mundo, y su shortcode [ contact-form-7 id="X" ] aparece literalmente en millones de páginas de contacto, páginas de presupuesto, pies de página y widgets.

Cuando alguien migra a otro plugin de formularios (Gravity Forms, WPForms, Fluent Forms) o simplemente desinstala CF7, esos shortcodes se quedan ahí donde estuvieran, sin uso ni beneficio.

Gravity Forms ([gravityform id="1"]), WPForms ([wpforms id="52"]), Ninja Forms ([ninja_form id="1"]), Formidable Forms ([formidable id="2"]) y prácticamente cualquier plugin de formularios tiene exactamente el mismo problema.

Plugins de sliders y galerías

Elige tu diversión. Revolution Slider, Meta Slider, Soliloquy, Smart Slider 3, Nivo Slider, Envira Gallery, FooGallery, y prácticamente todos los carruseles de contenido o imágenes usan shortcodes para incrustar su contenido en páginas y entradas. Si en algún momento cambiaste de plugin de sliders o galerías sin limpiar el contenido, esos shortcodes siguen ahí.

Plugins de membresía y restricción de contenido

MemberPress, Restrict Content Pro, s2Member, LearnDash y similares usan shortcodes para proteger fragmentos de contenido o mostrar mensajes según el nivel de acceso del usuario. Son especialmente delicados cuando quedan huérfanos porque pueden ocultar partes del contenido o mostrar mensajes de acceso denegado sin sentido.

Plugins de redes sociales, botones de compartir, incrustados

Muchos plugins de generaciones anteriores insertaban sus botones de compartir mediante shortcodes en el contenido, y si usaste shortcodes para insertar vídeos seguro que también viste Mazinger Z o cera le andas. Si los usaste hace años y luego los cambiaste por soluciones más modernas esos shortcodes pueden seguir en tus entradas más antiguas.

WooCommerce y sus extensiones

WooCommerce incluye sus propios shortcodes nativos ([products], [woocommerce_cart], [woocommerce_checkout], [woocommerce_my_account]) que se registran mientras el plugin esté activo. Pero el problema mayor viene de las extensiones de WooCommerce, como filtros de productos, comparadores, listas de deseos, tabs de producto con contenido personalizado.

Si desinstalaste alguna de estas extensiones sin limpiar el contenido sus shortcodes siguen en páginas y en las descripciones de productos.

Temas mutipropósito premium con shortcodes propios

Muchos temas de sitios como ThemeForest y otros marketplaces llevan incorporados sus propios shortcodes para crear elementos de diseño como cajas de información, iconos, columnas, botones, secciones destacadas.

Cuando cambias de tema o plugin todo eso se convierte en texto inútil.

Dónde se esconden

El error más habitual cuando alguien busca y elimina shortcodes es hacerlo solo en el contenido de entradas y páginas. Eso es quedarse muy a medias. Los shortcodes pueden estar en muchos más sitios, y si no los limpias todos, el problema persiste.

• Contenido de entradas y páginas: la tabla wp_posts, columna post_content. Es el sitio más obvio.
• Extractos: la columna post_excerpt de la misma tabla y se olvida con mucha frecuencia. Si pusiste un shortcode en el extracto de una entrada para mostrar algo en las páginas de archivo o en el feed ese shortcode puede seguir ahí.
• Tipos de contenido personalizados: también en wp_posts pero con diferentes valores en post_type. Si usas CPTs (productos de WooCommerce, portfolios, cursos, propiedades), sus contenidos también pueden tener shortcodes.
• Metadatos de entradas y campos personalizados: la tabla wp_postmeta. Muchos plugins guardan contenido con shortcodes en campos personalizados. ACF en particular puede tener campos de tipo textarea o contenido WYSIWYG llenos de ellos. Las descripciones cortas de productos de WooCommerce (_woocommerce_short_description) también van aquí.
• Widgets: los widgets de texto clásicos, los widgets del editor de bloques y los de cualquier plugin de widgets personalizados se guardan en wp_options con la clave widget_text o similares. Si usabas un shortcode de formulario en la barra lateral y desinstalaste el plugin, ese widget sigue teniendo el shortcode.
• Opciones del tema y del personalizador: también en wp_options. Algunos temas permiten insertar shortcodes en campos de texto del personalizador, en el pie de página, cabeceras fijas, avisos legales, textos de copyright, etc. Estos son especialmente difíciles de encontrar porque no hay una clave estándar para buscarlos.
• Menús de navegación: algunos plugins añaden shortcodes en los títulos o en el CSS de los elementos de menú. Raro, pero existe.
• Plantillas de correo electrónico personalizadas: si usas WooCommerce o algún plugin de email marketing con plantillas editables desde el escritorio, esas plantillas pueden tener shortcodes. Al cambiar de plugin, los shortcodes quedan en las plantillas guardadas.
• Bloques del editor de bloques (Gutenberg): cuando importas o migras contenido clásico a Gutenberg, los shortcodes a veces acaban dentro de bloques de párrafo o bloques clásicos. Gutenberg tiene un bloque específico llamado shortcode para procesarlos, pero si están dentro de un bloque de párrafo normal no se procesan.
• Opciones de SEO y meta descriptions: plugins como Yoast SEO o Rank Math permiten personalizar los snippets de SEO, y algunos usuarios han introducido shortcodes ahí. Si el plugin que generaba ese shortcode ya no está el texto puede aparecer raro en las etiquetas meta.

¿Donde puedes encontrar los shortcodes huérfanos?

Antes de eliminar nada hay que saber qué tienes y dónde están. Lanzarse a borrar sin localizar primero puede dejarte con contenido roto o con shortcodes que crees que has eliminado pero siguen apareciendo en algún widget olvidado, y como acabamos de ver antes pueden estar en montones de sitios, algunos nada obvios.

Con un shortcode de diagnóstico temporal

Una técnica elegante para localizar shortcodes concretos en el contenido de entradas y páginas sin instalar ningún plugin es crear un shortcode de diagnóstico temporal, sí otro. ¿A que es algo casi poético empezar la eliminación de shortcodes creando uno nuevo?

Lo añades al functions.php del tema hijo o a un plugin de snippets, usas el shortcode en una página nueva para obtener el listado y luego lo eliminas.

/* Shortcode de diagnóstico temporal: encuentra entradas que contienen un shortcode concreto */
// Uso: [ayudawp_buscar_shortcode find="nombre-del-shortcode"]
// Ejemplo: [ayudawp_buscar_shortcode find="contact-form-7"]
// IMPORTANTE: elimina este código una vez usado
add_shortcode( 'ayudawp_buscar_shortcode', 'ayudawp_shortcode_finder' );
function ayudawp_shortcode_finder( $atts ) {
    // Solo accesible para administradores
    if ( ! current_user_can( 'manage_options' ) ) {
        return '';
    }

    $atts = shortcode_atts( array(
        'find' => '',
    ), $atts );

    if ( empty( $atts['find'] ) ) {
        return '<p>Indica el shortcode a buscar con el atributo find="nombre".</p>';
    }

    // Busca en entradas, páginas y cualquier CPT publicado
    $args = array(
        's'              => $atts['find'],
        'posts_per_page' => -1,
        'post_type'      => 'any',
        'post_status'    => array( 'publish', 'draft', 'private' ),
    );

    $query = new WP_Query( $args );

    if ( ! $query->have_posts() ) {
        return '<p>No se han encontrado entradas con ese shortcode.</p>';
    }

    $output  = '<p><strong>Entradas que contienen [' . esc_html( $atts['find'] ) . ']:</strong></p>';
    $output .= '<ul>';
    while ( $query->have_posts() ) {
        $query->the_post();
        $output .= '<li><a href="' . esc_url( get_edit_post_link() ) . '">';
        $output .= esc_html( get_the_title() ) . ' (' . esc_html( get_post_type() ) . ')</a></li>';
    }
    $output .= '</ul>';
    wp_reset_postdata();

    return $output;
}

Una vez añadido el código, crea una página nueva (en borrador, no hace falta que la publiques) y escribe en su contenido:

[ayudawp_buscar_shortcode find="contact-form-7"]

Al previsualizar la página verás un listado de todas las entradas y páginas donde aparece ese shortcode, con enlace directo al editor (Dato curioso: también verás la actual).

Cuando termines elimina el código del functions.php.

Ten en cuenta que este método busca en el contenido (post_content) mediante la búsqueda nativa de WordPress, que no siempre indexa todo perfectamente.

Con un plugin

La opción más mencionada históricamente para localizar shortcodes ha sido el plugin Shortcodes in Use. Y sí, permite buscar shortcodes concretos en el contenido de tus entradas filtrando por tipo de contenido (páginas, entradas, CPTs, widgets), pero tiene un problema, que lleva varios años sin actualizarse y su compatibilidad con versiones modernas de WordPress no está garantizada. Puedes probarlo pero ojito.

Para sustituir Shortcodes in Use he encontrado Shortcodes Finder, que hace lo mismo y mucho más porque encuentra todos los shortcodes por tipo de contenido, muestra los huérfanos sin usar y permite desactivarlos con un clic desde el panel. Es el sustituto natural.

Con consultas SQL

Esta es la manera más directa y completa de saber qué shortcodes tienes y dónde. Accede a tu base de datos desde phpMyAdmin (en tu panel de hosting), Adminer o cualquier cliente SQL que uses.

Antes de ejecutar nada, un par de notas importantes:

• Sustituye siempre wp_ por el prefijo real de tu base de datos (puedes verlo en tu archivo wp-config.php)
• Ejecuta primero las consultas SELECT para ver los resultados antes de hacer ningún UPDATE.

Para buscar un shortcode concreto en el contenido de entradas y páginas:

SELECT ID, post_title, post_type, post_status
FROM wp_posts
WHERE post_content LIKE '%[contact-form-7]+)[^\]]*\]/', $post->post_content, $matches );

    if ( empty( $matches[1] ) ) {
        return;
    }

    foreach ( array_unique( $matches[1] ) as $tag ) {
        if ( ! array_key_exists( $tag, $shortcode_tags ) ) {
            add_shortcode( $tag, '__return_empty_string' );
        }
    }
}

Función strip_shortcodes() y filtros sobre the_content

WordPress incluye de serie la función strip_shortcodes() que elimina los shortcodes del texto que procesa. La diferencia con el método anterior es que actúa en el filtro de salida del contenido, así que los shortcodes no se procesan, simplemente se eliminan del HTML antes de mostrarlo al visitante.

La forma más sencilla de usarlo es aplicarlo al filtro the_content:

// Elimina todos los shortcodes no reconocidos del contenido antes de mostrarlo.
// Atención: strip_shortcodes() elimina TODOS los shortcodes no registrados.
add_filter( 'the_content', 'ayudawp_strip_orphan_shortcodes', 5 );
function ayudawp_strip_orphan_shortcodes( $content ) {
    global $shortcode_tags;
    $registered = array_keys( $shortcode_tags );

    // Buscamos shortcodes en el contenido
    preg_match_all( '/\[([a-zA-Z_\-]+)[^\]]*\]/', $content, $matches );

    if ( empty( $matches[1] ) ) {
        return $content;
    }

    foreach ( array_unique( $matches[1] ) as $tag ) {
        // Solo eliminamos los que no están registrados
        if ( ! in_array( $tag, $registered, true ) ) {
            // Elimina la etiqueta de apertura con cualquier combinación de atributos
            $content = preg_replace(
                '/\[' . preg_quote( $tag, '/' ) . '(?:\s[^\]]*)?\/?\]/',
                '',
                $content
            );
            // Elimina la etiqueta de cierre si existe
            $content = preg_replace(
                '/\[\/' . preg_quote( $tag, '/' ) . '\]/',
                '',
                $content
            );
        }
    }

    return $content;
}

La prioridad 5 hace que se ejecute antes que el procesado normal de shortcodes de WordPress (prioridad 11), lo correcto en este tipo de acciones.

La limitación importante de este enfoque con expresiones regulares básicas es que no maneja bien los shortcodes con etiqueta de cierre que envuelven contenido, como [shortcode]contenido envuelto[/shortcode]. Si eliminas solo las etiquetas el contenido interior puede quedar suelto en el HTML de forma inesperada.

Eliminar shortcodes con etiqueta de cierre y contenido anidado

Los shortcodes más complejos, especialmente los de maquetadores visuales como Divi o WP Bakery, tienen estructura de apertura y cierre, y además se anidan unos dentro de otros:

[et_pb_section][et_pb_row][et_pb_column]contenido[/et_pb_column][/et_pb_row][/et_pb_section]

Para estos casos necesitas una estrategia diferente que elimine tanto las etiquetas como el contenido que envuelven.

El siguiente código hace justamente eso:

// Elimina shortcodes con estructura de apertura y cierre (y su contenido interior).
// Especialmente útil para maquetadores como Divi o WP Bakery.
add_filter( 'the_content', 'ayudawp_strip_wrapping_orphan_shortcodes', 5 );
function ayudawp_strip_wrapping_orphan_shortcodes( $content ) {
    global $shortcode_tags;

    // Patrón que captura shortcodes con cierre: [tag atributos]...contenido...[/tag]
    // El modificador 's' hace que el punto también coincida con saltos de línea
    $pattern = '/\[([a-zA-Z_\-]+)(?:\s[^\]]*)?\](.*?)\[\/\1\]/s';

    preg_match_all( $pattern, $content, $matches, PREG_SET_ORDER );

    if ( empty( $matches ) ) {
        return $content;
    }

    foreach ( $matches as $match ) {
        $tag = $match[1];
        // Solo actúa si el shortcode no está registrado
        if ( ! array_key_exists( $tag, $shortcode_tags ) ) {
            // Elimina el bloque completo: apertura + contenido + cierre
            $content = str_replace( $match[0], '', $content );
        }
    }

    return $content;
}

Si en lugar de eliminar el contenido interior prefieres conservarlo (quitando solo las etiquetas del shortcode pero manteniendo lo que había dentro) cambia str_replace( $match[0], '', $content ) por str_replace( $match[0], $match[2], $content ).

Para una limpieza completa de maquetadores como Divi o WP Bakery lo más efectivo es combinar este código con el método de buscar y reemplazar en base de datos que veremos enseguida. El código resuelve el problema de visualización de forma inmediata, el reemplazo en base de datos lo resuelve de forma permanente.

Buscar y reemplazar en la base de datos

Este es el método que elimina los shortcodes de verdad, borrándolos de la base de datos. Los resultados son permanentes así que la regla de oro es siempre hacer una copia de seguridad completa antes de ejecutar nada, sin excepciones.

Con Better Search Replace

Better Search Replace es el plugin de referencia para esto. Gratuito, bien mantenido y con una interfaz clara. Permite buscar un texto concreto en cualquier tabla de la base de datos y reemplazarlo por otro (o por nada).

El flujo de trabajo correcto es este: instala y activa el plugin, ve a Herramientas › Better Search Replace, introduce el shortcode exacto en el campo «Buscar», deja «Reemplazar por» vacío para eliminarlo, selecciona las tablas donde quieres buscar (wp_posts y wp_options como mínimo, todas si no estás seguro) y marca «Ejecutar como prueba» la primera vez. Eso te mostrará cuántos reemplazos haría sin ejecutarlos realmente. Si el número tiene sentido, repite sin la opción de prueba.

El límite de este plugin es que trabaja con texto literal. Si el shortcode tiene atributos variables (como un ID diferente en cada uso), necesitas hacerlo con expresiones regulares, lo que requiere WP-CLI o SQL directo.

Con WP-CLI

WP-CLI incluye el comando search-replace que admite expresiones regulares, lo que lo convierte en la herramienta perfecta para shortcodes con atributos variables. Siempre empieza con --dry-run para ver qué va a pasar antes de ejecutar de verdad:

Para un shortcode con texto exacto:

wp search-replace '[ contact-form-7 id="48" title="Formulario de contacto 1"]' '' wp_posts --dry-run

Para un shortcode con cualquier combinación de atributos (usando regex):

wp search-replace '\[ contact-form-7[^\]]*\]' '' wp_posts --regex --dry-run

Para limpiar shortcodes de Divi (prefijo et_pb_) en todo el contenido:

wp search-replace '\[/?et_pb_[^\]]*\]' '' wp_posts --regex --dry-run

Para WP Bakery (prefijo vc_):

wp search-replace '\[/?vc_[^\]]*\]' '' wp_posts --regex --dry-run

Cuando el resultado del dry-run es el esperado, ejecuta sin esa opción. El flujo completo recomendado, que hace copia de seguridad, ejecuta el reemplazo y limpia la caché:

wp db export backup-antes-limpieza-shortcodes.sql && wp search-replace '\[contact-form-7]]*\]' '' wp_posts --regex --report-changed-only && wp cache flush

Si el shortcode afecta también a metadatos o a opciones, añade las tablas correspondientes al comando:

wp search-replace '\[ contact-form-7[^\]]*\]' '' wp_posts wp_postmeta wp_options --regex --report-changed-only

Con SQL directo en phpMyAdmin

Para shortcodes con texto exacto e idéntico en todos los usos, la función REPLACE de MySQL es directa:

-- Primero comprueba cuántas filas afectaría
SELECT COUNT(*) FROM wp_posts
WHERE post_content LIKE '%[ contact-form-7 id="48" title="Formulario de contacto 1"]%';

-- Si el resultado es el esperado, ejecuta el reemplazo
UPDATE wp_posts
SET post_content = REPLACE(
    post_content,
    '[ contact-form-7 id="48" title="Formulario de contacto 1"]',
    ''
)
WHERE post_content LIKE '%contact-form-7%';

Para shortcodes con atributos variables necesitas REGEXP_REPLACE, disponible desde MySQL 8.x o MariaDB 10.x (comprueba la versión de tu servidor antes de usarlo):

-- Elimina todas las variantes del shortcode independientemente de sus atributos
UPDATE wp_posts
SET post_content = REGEXP_REPLACE(
    post_content,
    '\\[ contact-form-7[^\\]]*\\]',
    ''
)
WHERE post_content REGEXP '\\[contact-form-7]+[^\\]]*\\].*?\\[/et_pb_[a-z_]+\\]',
    ''
)
WHERE post_content REGEXP '\\[et_pb_';

Con este último mucho cuidado, si el contenido que está dentro de las etiquetas del maquetador lo quieres conservar de alguna forma esta consulta lo borra todo. Úsalo cuando las páginas van a ser reconstruidas de cero con el nuevo tema o maquetador.

Ejecutar un script PHP de limpieza masiva con WP_Query

Una alternativa intermedia entre editar a mano y hacer un reemplazo global en la base de datos es usar un script PHP que recorra todas las entradas afectadas y limpie cada una individualmente, con más control sobre qué se elimina. Esto es muy útil cuando quieres eliminar shortcodes de apertura y cierre pero conservar el contenido interior.

El siguiente script busca todas las entradas que contienen un shortcode concreto y elimina solo las etiquetas (apertura y cierre), conservando el texto que había dentro:

<?php
/**
 * Plugin Name: Limpiador de shortcodes huérfanos (ejecutar una vez)
 * Description: Elimina las etiquetas de shortcodes huérfanos conservando el contenido interior.
 *              IMPORTANTE: desactivar y eliminar este plugin después de usarlo.
 * Version:     1.0
 * Author:      Fernando Tellado
 */

// Solo se ejecuta cuando un administrador accede al escritorio
add_action( 'admin_init', 'ayudawp_limpiar_shortcodes_una_vez' );
function ayudawp_limpiar_shortcodes_una_vez() {
    // Comprobación de seguridad: solo administradores
    if ( ! current_user_can( 'manage_options' ) ) {
        return;
    }

    // Evita ejecuciones múltiples usando una opción de control
    if ( get_option( 'ayudawp_limpieza_shortcodes_ejecutada' ) ) {
        return;
    }

    // Lista de shortcodes a limpiar (solo las etiquetas, el contenido interior se conserva)
    $shortcodes_a_limpiar = array(
        'custom_shortcode',
        'clima_semanal',
        'privado',
        // Añade aquí los shortcodes que quieras limpiar
    );

    // Construye el patrón regex para todos los shortcodes de la lista
    $tags_patron = implode( '|', array_map( 'preg_quote', $shortcodes_a_limpiar ) );

    // Patrón para etiqueta de apertura (con o sin atributos) y etiqueta de cierre
    $patron_apertura = '/\[(?:' . $tags_patron . ')(?:\s[^\]]*)?\]/';
    $patron_cierre   = '/\[\/(?:' . $tags_patron . ')\]/';

    // Obtiene todas las entradas publicadas (y borradores) de cualquier tipo
    $args = array(
        'posts_per_page' => -1,
        'post_type'      => 'any',
        'post_status'    => array( 'publish', 'draft', 'private' ),
        'fields'         => 'ids',
    );

    $posts = get_posts( $args );
    $contador = 0;

    foreach ( $posts as $post_id ) {
        $post = get_post( $post_id );
        $contenido_original = $post->post_content;

        // Aplica la limpieza
        $contenido_limpio = preg_replace( $patron_apertura, '', $contenido_original );
        $contenido_limpio = preg_replace( $patron_cierre, '', $contenido_limpio );

        // Solo actualiza si ha habido cambios reales
        if ( $contenido_limpio !== $contenido_original ) {
            wp_update_post( array(
                'ID'           => $post_id,
                'post_content' => $contenido_limpio,
            ) );
            $contador++;
        }
    }

    // Marca la limpieza como ejecutada para no repetirla
    update_option( 'ayudawp_limpieza_shortcodes_ejecutada', true );

    // Registra un mensaje en el log para confirmación
    error_log( 'AyudaWP: Limpieza de shortcodes completada. Entradas modificadas: ' . $contador );
}

Este script se ejecuta una sola vez (gracias al control mediante get_option). Después de que se ejecute desactívalo y elimínalo. Si quieres reiniciarlo para volver a ejecutarlo (por ejemplo, con una lista diferente de shortcodes), elimina la opción de control desde el escritorio de WordPress o con WP-CLI:

wp option delete ayudawp_limpieza_shortcodes_ejecutada

Casos especiales: maquetadores y plugins populares

Los shortcodes huérfanos más habituales no vienen de plugins raros, vienen de herramientas muy extendidas que la gente usa durante años y luego cambia o abandona. Aquí están los casos que más aparecen y cómo tratarlos.

Contact Form 7

Conviene dedicarle un apartado propio porque el volumen de webs afectadas es enorme. Contact Form 7 es el plugin de WordPress más instalado del mundo y su shortcode aparece en prácticamente cualquier página de contacto, y más sitios.

Cuando alguien migra a otro plugin de formularios o simplemente desinstala CF7 sin limpiar, ese shortcode queda por todas partes.

La particularidad de CF7 es que el ID del formulario varía en cada instalación y en cada uso, así que no sirve hacer un reemplazo de texto literal. Necesitas regex:

-- Busca todas las entradas con shortcodes de CF7
SELECT ID, post_title FROM wp_posts
WHERE post_content REGEXP '\\[ contact-form-7[^\\]]*\\]'
  AND post_status NOT IN ('auto-draft', 'trash');

Con WP-CLI para eliminarlos:

wp search-replace '\[ contact-form-7[^\]]*\]' '' wp_posts --regex --dry-run

Si migras a WPForms, Gravity Forms u otro plugin, el proceso es el mismo: localiza los shortcodes del plugin anterior, elimínalos de la base de datos e inserta manualmente los nuevos shortcodes en las páginas correspondientes.

Gravity Forms, WPForms, Ninja Forms y Formidable

Mismo patrón que CF7 pero con diferentes nombres de shortcode. Para localizarlos y eliminarlos:

-- Gravity Forms: [gravityform id="X" title="false"]
SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%[gravityform%' AND post_status NOT IN ('auto-draft','trash');

-- WPForms: [wpforms id="X"]
SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%[wpforms%' AND post_status NOT IN ('auto-draft','trash');

-- Ninja Forms: [ninja_form id="X"]
SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%[ninja_form%' AND post_status NOT IN ('auto-draft','trash');

Divi (versiones anteriores a Divi 5)

Divi es el caso más extremo de dependencia de shortcodes y el que más desastres causa cuando alguien cambia de tema sin preparar el terreno. Hasta la versión 4.x, absolutamente todo el contenido generado con su maquetador visual estaba almacenado como shortcodes anidados en la base de datos. Una sola página podía tener cientos de líneas así:

[et_pb_section fb_built="1" _builder_version="4.21.0" _module_preset="default"]
[et_pb_row _builder_version="4.21.0" _module_preset="default"]
[et_pb_column type="4_4" _builder_version="4.21.0" _module_preset="default"]
[et_pb_text _builder_version="4.21.0" _module_preset="default"]
Aquí el contenido real de la página
[/et_pb_text]
[/et_pb_column]
[/et_pb_row]
[/et_pb_section]

Si cambias de tema sin convertir ese contenido primero lo que te queda en las entradas es un muro de shortcodes absolutamente ilegible. Y no es un problema pequeño pues en algunas instalaciones con Divi el volumen de shortcodes en la base de datos es tal que la diferencia de tamaño de wp_posts antes y después de la limpieza puede ser de varios megas.

Opción 1: migrar a Divi 5 

Divi 5 ya está disponible y ha reescrito el framework desde cero. Lo más importante para el asunto del que estamos hablando es que Divi 5 abandona completamente los shortcodes y pasa a un sistema basado en bloques, similar en concepto a Gutenberg, pero con su propio motor.

El contenido de Divi ya no se almacena como shortcodes en post_content, sino en una estructura mucho más limpia y portable.

Al migrar de Divi 4.x a Divi 5 el propio proceso de migración convierte el contenido al nuevo formato, eliminando los shortcodes de la base de datos. Puedes leer los detalles en el esta guía de migración a Divi 5. Migrar a Divi 5 es la solución más limpia y con más futuro a largo plazo.

Opción 2: limpiar los shortcodes con buscar y reemplazar

Si cambias a otro tema o maquetador y necesitas limpiar los shortcodes de Divi, el prefijo et_pb_ es tu punto de partida. Con WP-CLI:

-- Primero, comprueba cuántas entradas tienen shortcodes de Divi
wp db query "SELECT COUNT(*) FROM wp_posts WHERE post_content LIKE '%[et_pb_%' AND post_status NOT IN ('auto-draft','trash');"

-- Dry-run para ver qué pasaría
wp search-replace '\[/?et_pb_[^\]]*\]' '' wp_posts --regex --dry-run

-- Si el resultado es correcto, ejecuta sin dry-run
wp search-replace '\[/?et_pb_[^\]]*\]' '' wp_posts --regex --report-changed-only

Ten en cuenta que esto elimina todo el contenido que estaba dentro de los módulos de Divi. Si las páginas tienen texto real que quieres conservar, necesitas extraerlo antes de limpiar los shortcodes. Una estrategia posible es exportar el contenido de cada página a un archivo de texto, copiar solo el texto relevante y reconstruir la página con el nuevo maquetador.

Opción 3: neutralizar temporalmente mientras reconstruyes

Si el volumen de páginas es grande y necesitas tiempo para reconstruirlas, el código de neutralización es lo más recomendable. Lo activas, los shortcodes dejan de mostrarse en pantalla y puedes reconstruir las páginas a tu ritmo sin que los visitantes vean el caos.

WP Bakery Page Builder (Visual Composer)

El otro gran generador de shortcodes masivos. WP Bakery usa prefijos como vc_row, vc_column, vc_column_text, vc_section y muchos más. El impacto es similar a Divi, o sea, páginas construidas íntegramente con WP Bakery pueden tener cientos de shortcodes anidados.

Para localizar el alcance del problema:

SELECT ID, post_title, post_type
FROM wp_posts
WHERE post_content LIKE '%[vc_%'
  AND post_status NOT IN ('auto-draft', 'trash')
ORDER BY post_type, ID;

Para limpiar con WP-CLI:

-- Elimina todas las etiquetas de WP Bakery (apertura y cierre)
wp search-replace '\[/?vc_[a-z_]+[^\]]*\]' '' wp_posts --regex --dry-run

Un detalle importante de WP Bakery es que también puede dejar rastro en el metadato _wpb_vc_js_status y en algunas opciones propias. Después de limpiar wp_posts, vale la pena hacer una búsqueda en wp_postmeta:

SELECT post_id, meta_key FROM wp_postmeta
WHERE meta_key LIKE '_wpb_%' OR meta_key LIKE '_vc_%';

Beaver Builder

Beaver Builder gestiona el contenido de forma diferente a Divi y WP Bakery, lo que hace que el impacto de dejarlo sea menor en cuanto a shortcodes visibles. En lugar de guardar todo como shortcodes en post_content, guarda la configuración de los módulos en metadatos (wp_postmeta) y el shortcode que aparece en post_content suele ser simplemente [fl_builder_insert_layout] o similar.

Esto significa que si dejas de usar Beaver Builder, el impacto visible en el contenido es mucho menor. Pero sigue quedando basura en la base de datos en forma de metadatos. Para limpiarla tienes esta consulta SQL:

-- Encuentra los metadatos de Beaver Builder
SELECT post_id, meta_key
FROM wp_postmeta
WHERE meta_key LIKE '_fl_builder%'
ORDER BY post_id;

-- Si quieres eliminarlos (con cuidado)
DELETE FROM wp_postmeta WHERE meta_key LIKE '_fl_builder%';

Y para el shortcode que puede quedar en el contenido, con WP-CLI:

wp search-replace '\[fl_builder_insert_layout[^\]]*\]' '' wp_posts --regex --dry-run

Elementor y sus extensiones

Elementor en sí mismo no usa shortcodes para almacenar el contenido, guarda todo en JSON en wp_postmeta con la clave _elementor_data. Esto es una ventaja importante en términos de portabilidad respecto a maquetadores más antiguos.

Sin embargo, muchas extensiones de Elementor (packs de widgets de terceros como Essential Addons, Ultimate Addons, JetElements, etc.) sí generan shortcodes que se insertan dentro de los widgets de texto de Elementor o en otras partes del contenido. Si usaste alguna de estas extensiones y lo desinstalaste esos shortcodes pueden aparecer dentro del contenido JSON de Elementor o en los widgets de texto de la barra lateral.

Para buscarlos, la consulta en wp_postmeta con el shortcode concreto es el punto de partida:

SELECT pm.post_id, p.post_title, LEFT(pm.meta_value, 300) AS fragmento
FROM wp_postmeta pm
JOIN wp_posts p ON p.ID = pm.post_id
WHERE pm.meta_key = '_elementor_data'
  AND pm.meta_value LIKE '%nombre-del-shortcode%';

Revolution Slider, Meta Slider y similares

Revolution Slider es uno de los más habituales. Su shortcode tiene la forma [rev_slider alias="nombre-del-slider"]. Si cambias de plugin de sliders sin limpiar primero, ese shortcode queda en todas las páginas donde tenías un slider.

Para localizarlos:

SELECT ID, post_title FROM wp_posts
WHERE post_content LIKE '%[rev_slider%'
  AND post_status NOT IN ('auto-draft', 'trash');

Y para limpiarlos con WP-CLI:

wp search-replace '\[rev_slider[^\]]*\]' '' wp_posts --regex --dry-run

Meta Slider ([metaslider id="X"]), Smart Slider 3 ([smartslider3 slider="X"]) y el resto siguen el mismo patrón.

Plugins de membresía, cursos y restricción de contenido

MemberPress, Restrict Content Pro, s2Member, LearnDash, Sensei y similares usan shortcodes para proteger fragmentos de contenido o mostrar elementos propios. Son especialmente problemáticos cuando quedan huérfanos porque pueden ocultar partes del contenido que deberían ser visibles o mostrar mensajes de acceso denegado sin sentido. Hay que localizarlos y limpiarlos con especial cuidado porque el contenido interior puede ser relevante.

En estos casos el método que conserva el contenido interior (eliminar solo las etiquetas del shortcode, no lo que hay dentro) suele ser el más apropiado.

Eliminar shortcodes de los resultados de la API REST

Si tu WordPress alimenta una aplicación externa, un marketplace, una app móvil o cualquier integración que consuma datos vía API REST de WordPress, los shortcodes huérfanos son un problema específicamente feo: en lugar de procesar el shortcode, la API devuelve el texto tal cual, y el sistema receptor lo muestra literalmente al usuario final.

Este problema es muy habitual cuando se conecta una tienda WooCommerce con marketplaces como Amazon, Miravia u otros, o cuando se construye una app sobre un WordPress que tiene contenido generado con maquetadores. El plugin del marketplace usa la API REST para leer las descripciones de los productos, y si esas descripciones están llenas de shortcodes de Divi o de WP Bakery, eso es exactamente lo que recibe y muestra.

La solución es filtrar la salida de la API para procesar o eliminar los shortcodes antes de que se envíen en la respuesta. Para el contenido general de entradas y páginas mediante la API REST estándar de WordPress:

// Elimina shortcodes no registrados del contenido que devuelve la API REST de entradas.
add_filter( 'rest_prepare_post', 'ayudawp_clean_shortcodes_rest_api', 10, 3 );
function ayudawp_clean_shortcodes_rest_api( $response, $post, $request ) {
    if ( isset( $response->data['content']['raw'] ) ) {
        // Procesamos el raw: eliminamos shortcodes no registrados y procesamos los registrados
        $content = strip_shortcodes( $response->data['content']['raw'] );
        $response->data['content']['rendered'] = apply_filters( 'the_content', $content );
    }
    return $response;
}

Para páginas, el hook es rest_prepare_page, para tipos de contenido personalizados, rest_prepare_{post_type}.

Para el caso específico de productos de WooCommerce en su API REST:

// Elimina shortcodes de la descripción de productos en la API REST de WooCommerce.
add_filter( 'woocommerce_rest_prepare_product_object', 'ayudawp_clean_shortcodes_woo_rest', 10, 3 );
function ayudawp_clean_shortcodes_woo_rest( $response, $product, $request ) {
    $post_object = get_post( $product->get_id() );
    if ( ! $post_object ) {
        return $response;
    }

    // Elimina todos los shortcodes del contenido (descripción larga)
    $content = preg_replace( '/\[[^\]]+\]/', '', $post_object->post_content );
    $response->data['description'] = apply_filters( 'the_content', $content );

    // Hace lo mismo con la descripción corta si la hay
    if ( ! empty( $response->data['short_description'] ) ) {
        $short = preg_replace( '/\[[^\]]+\]/', '', $product->get_short_description() );
        $response->data['short_description'] = apply_filters( 'the_content', $short );
    }

    return $response;
}

Si en lugar de eliminar los shortcodes quieres que se procesen (para que la API devuelva el HTML resultante en lugar del shortcode en crudo), sustituye el preg_replace que elimina shortcodes por do_shortcode. Tiene sentido cuando el plugin que genera el shortcode sigue activo pero la API no lo procesa por defecto.

Eliminar shortcodes del feed RSS

El feed RSS de WordPress es otro lugar donde los shortcodes huérfanos causan problemas. Los lectores de feeds y los agregadores de contenido muestran el shortcode en texto plano, lo que da muy mala imagen.

Y si tienes configurada alguna integración de email marketing que consume el feed automáticamente para enviar newsletters (algo habitual en plataformas como Mailchimp, MailerLite o ConvertKit con la opción RSS-to-email), ese shortcode en crudo llega directamente a la bandeja de entrada de tus suscriptores.

La solución es limpiar el contenido antes de que se vuelque en el feed. El código actúa sobre dos filtros: the_content_feed para el contenido completo de las entradas en el feed, y the_excerpt_rss para los extractos:

// Elimina shortcodes del contenido que aparece en el feed RSS.
// Afecta solo al feed, no al contenido visible en la web.
add_filter( 'the_content_feed', 'ayudawp_strip_shortcodes_rss' );
add_filter( 'the_excerpt_rss', 'ayudawp_strip_shortcodes_rss' );
function ayudawp_strip_shortcodes_rss( $content ) {
    // strip_shortcodes() elimina todos los shortcodes no registrados
    // do_shortcode() procesa los que sí están registrados antes de eliminar los huérfanos
    return strip_shortcodes( do_shortcode( $content ) );
}

El orden importa aquí: primero se procesan con do_shortcode los que tienen un plugin activo que los gestiona (convirtiendo esos shortcodes en HTML correcto), y luego strip_shortcodes elimina los que han quedado sin procesar porque no tienen plugin que los gestione.

Si prefieres eliminar absolutamente todos los shortcodes del feed, incluyendo los que sí están registrados, simplifica el snippet a solo return strip_shortcodes( $content );.

Cómo no volver a estar en esta situación

Arreglar el problema está bien. No volver a tenerlo está mucho mejor. Estas son las costumbres que marcan la diferencia a largo plazo.

• Limpia antes de desinstalar: Cuando vayas a eliminar un plugin que usa shortcodes, búscalos primero (con cualquiera de los métodos de localización que hemos visto) y reemplázalos por el contenido real o elimínalos antes de desactivar el plugin. Una vez desactivado, pierdes la referencia de qué shortcodes usaba, así que es mucho más difícil localizarlos.
• Instala el plugin sustituto antes de desinstalar el anterior: Si cambias de plugin de formularios, de sliders o de cualquier otra herramienta que use shortcodes, activa el nuevo plugin antes de desactivar el anterior. Así tienes tiempo de migrar el contenido con ambos activos y puedes verificar que todo funciona antes de hacer la transición definitiva.
• Documenta qué shortcodes usa cada plugin activo: En webs con mucho contenido o en webs de clientes, tener un registro de qué plugin gestiona cada shortcode que aparece en el contenido puede ahorrarte horas de investigación en el futuro. No hace falta nada sofisticado: una nota en el bloc o un documento compartido con el cliente es suficiente.
• Haz auditorías periódicas: Una vez al año, o cada vez que hagas una ronda de limpieza de plugins, ejecuta las consultas SQL de localización para ver si hay shortcodes sin procesar en el contenido. Con la práctica tarda cinco minutos y puede evitar problemas mayores.
• Prioriza herramientas que no creen dependencia de shortcodes: El ecosistema WordPress ha evolucionado mucho en este sentido. Gutenberg y los maquetadores modernos guardan el contenido en formatos más portátiles. Elementor guarda en JSON, Gutenberg en HTML con atributos de bloque, Divi 5 también ha abandonado los shortcodes. Si vas a empezar un proyecto nuevo o a rediseñar uno existente, ten en cuenta la portabilidad del contenido: qué pasa con lo que has construido si dentro de tres años cambias de herramienta.
• Para formularios, usa bloques Gutenberg cuando puedas: Plugins modernos como WPForms, Gravity Forms o Fluent Forms ofrecen tanto shortcode como bloque de Gutenberg. Si usas el bloque de Gutenberg para insertar el formulario, el contenido es mucho más portable y no te deja shortcodes huérfanos si cambias de plugin: simplemente el bloque dejará de procesarse.

¿Qué método deberías usar según el caso?

Con tantas opciones, puede ser útil tener claro cuándo usar cada una. La elección depende del volumen de shortcodes afectados, de si quieres eliminarlos de la base de datos o solo evitar que se muestren, y de tu nivel de comodidad técnica.

• Si tienes pocos shortcodes en pocas páginas, edítalas a mano. Es lo más limpio, tienes control total y no hay riesgo de romper nada.
• Si tienes muchos shortcodes y necesitas una solución inmediata sin tocar la base de datos, el códigio de neutralización con add_shortcode devolviendo vacío es tu primer paso. Los shortcodes desaparecen de pantalla en segundos. Después planifica la limpieza definitiva.
• Si los shortcodes son todos exactamente iguales (mismo texto en todos los usos), Better Search Replace o un UPDATE directo de SQL lo resuelve en minutos.
• Si los shortcodes tienen atributos variables (IDs diferentes en cada uso, como es el caso de todos los formularios y sliders), necesitas expresiones regulares. WP-CLI con --regex o REGEXP_REPLACE de MySQL son las herramientas adecuadas.
• Si los shortcodes tienen etiqueta de cierre y envuelven contenido que quieres conservar, el script PHP de limpieza masiva (método 6) es el más apropiado: elimina las etiquetas pero mantiene el texto interior.
• Si el problema está en la API REST o en el feed RSS, los filtros específicos de esos apartados resuelven el problema de forma aislada sin tocar el contenido de la base de datos ni afectar a la web visible.
• Si el origen del problema es Divi 4.x la migración a Divi 5 es la solución que resuelve el problema de los shortcodes de raíz y de paso te da acceso a un maquetador más moderno y más rápido.

Si aún te quedan dudas me preguntas en los comentarios.

Si ayer te llegó un email de GitHub con un tono muy amable hablándote de «mejoras en la asistencia de IA» y «prácticas habituales en la industria«, que sepas que lo que te están diciendo, en plata, es que a partir del 24 de abril van a usar todo lo que hagas con Copilot para entrenar los modelos de inteligencia artificial de Microsoft.

Tu código, tus conversaciones con Copilot, la estructura de tus proyectos, los nombres de tus archivos, tus comentarios en el código, todo. Y lo peor es que si no entras en los ajustes y lo desactivas tú, es posible que ya estés dentro. Esto es lo que se llama un modelo opt-out, es decir, que cuentan contigo salvo que digas expresamente que no.

Vamos a ver qué hay detrás de este cambio, qué implica para los que desarrollamos con WordPress y cómo protegerte si no te hace gracia.

¿Qué ha cambiado exactamente?

El 25 de marzo de 2026 GitHub publicó una actualización de su política de datos de interacción con Copilot junto con cambios en su política de privacidad y condiciones de servicio. El cambio principal es que los datos de interacción con GitHub Copilot de los usuarios de los planes Free, Pro y Pro+ se van a utilizar para entrenar y mejorar modelos de IA, salvo que el usuario se niegue.

La fecha límite es el 24 de abril de 2026. A partir de ese día, si no has tocado nada en tus ajustes, tus datos entran en el saco del entrenamiento.

Los usuarios de Copilot Business y Enterprise no se ven afectados, sus acuerdos prohíben usar esos datos para entrenamiento, los estudiantes y profesores con acceso gratuito a Copilot Pro tampoco, pero si pagas tu suscripción individual o usas el plan gratuito sí te afecta.

¿Qué datos recogen?

El alcance es bastante amplio. Cuando tienes la opción activada (que es como viene por defecto salvo una excepción que te cuento luego), GitHub puede recoger y usar para entrenamiento:

• Las sugerencias de código que aceptas o modificas.
• Lo que envías a Copilot, incluidos los fragmentos de código que ve el modelo.
• El contexto de código alrededor de tu cursor.
• Comentarios y documentación que escribas.
• Nombres de archivos, estructura de repositorios y patrones de navegación.
• Tus interacciones con las funciones de Copilot (chat, sugerencias inline, etc.).
• Tus valoraciones (pulgar arriba o abajo).

Es decir, prácticamente todo lo que haces mientras Copilot está activo.

Hay un detalle que pasa desapercibido y es importante, y es que GitHub distingue entre el código de tus repositorios privados «en reposo» (que dicen que no usan) y el código que Copilot procesa activamente cuando lo estás usando. Ese segundo caso sí entra en el entrenamiento.

Lo dicen ellos mismos en el anuncio, con las palabras exactas «at rest«, para dejar claro que mientras trabajas con Copilot en un repo privado, ese código sí puede acabar en el dataset.

¿Con quién comparten tus datos?

GitHub dice que estos datos se comparten con sus «afiliados», que en la práctica significa Microsoft y sus filiales. Personal de GitHub y Microsoft que trabaja en desarrollo de modelos de IA puede acceder a ellos, y también pueden contratar proveedores de servicios para ayudar con el entrenamiento, aunque bajo contrato.

Lo que dicen que no hacen es compartir estos datos con proveedores de modelos de IA de terceros ni venderlos. Eso sí, que los datos acaben en Microsoft, la empresa matriz que controla GitHub, y casualmente también accionista mayoritaria de OpenAI, no es exactamente que se queden «en casa».

Puedes consultar la FAQ oficial de GitHub con todas las preguntas frecuentes sobre este cambio.

El problema del opt-out en Europa

Desde el punto de vista legal, GitHub justifica el uso de datos de usuarios europeos apelando al «interés legítimo» como base legal bajo el RGPD. Es la misma estrategia que han usado Meta con los datos de Instagram y Facebook, y LinkedIn con los datos de sus usuarios para entrenar sus modelos.

El Comité Europeo de Protección de Datos (EDPB) reconoció en su dictamen de diciembre de 2024 que el interés legítimo puede servir como base para entrenar modelos de IA, pero con condiciones estrictas, vamos, que hay que demostrar que es necesario, hacer un análisis de proporcionalidad y tener en cuenta las «expectativas razonables» de los usuarios. Ofrecer un mecanismo de opt-out incondicional cuenta como medida positiva, y GitHub lo ofrece.

Pero la cosa no está tan clara como parece.

La autoridad italiana de protección de datos multó a OpenAI con 15 millones de euros en diciembre de 2024 por fallos en la evaluación del interés legítimo y en la transparencia al entrenar ChatGPT. Y NOYB, la organización de Max Schrems, ha presentado denuncias contra Meta en 11 países de la UE y contra X en 9 jurisdicciones por usar datos personales para entrenamiento de IA sin consentimiento explícito. Su posición es que el opt-out (aceptación implícita) no basta, debería ser opt-in (aceptación explícita).

Contra GitHub no hay denuncia todavía pero el patrón es idéntico al de Meta y X así que no sería raro que llegue.

Para los que vivimos en España la clave es que el RGPD exige que el consentimiento sea libre, específico, informado e inequívoco.

email con 30 días de aviso diciendo «si no haces nada, entendemos que aceptas» encaja mal con esa definición. Otra cosa es que GitHub pueda argumentar que no necesita consentimiento sino que se apoya en interés legítimo, pero esa base legal está siendo cuestionada en toda Europa para estos casos.

Lo que afecta a los desarrolladores WordPress

Aquí viene la parte que más nos toca. Si eres desarrollador WordPress y usas Copilot mientras trabajas en proyectos de clientes, piénsalo dos veces.

Cuando usas Copilot, el modelo tiene acceso al contexto de tu código, el archivo en el que estás, los archivos relacionados, los nombres de funciones, la estructura del proyecto. Si estás trabajando en el tema personalizado de un cliente, en un plugin con lógica de negocio específica o en cualquier código que no sea tuyo, fragmentos de ese trabajo pueden acabar en el dataset de entrenamiento de Microsoft.

Esto tiene implicaciones de confidencialidad serias.

Si tienes un contrato con tu cliente que incluye cláusulas de confidencialidad o de propiedad intelectual (y si no lo tienes, deberías), el hecho de que partes de su código puedan acabar alimentando un modelo de IA de una tercera empresa es, como mínimo, un problema contractual.

Y si tu cliente está en la UE y su código contiene datos personales (nombres en bases de datos, emails en configuraciones, etc.), también es un problema de RGPD.

La solución más directa es desactivar el entrenamiento en tus ajustes de Copilot. Puedes seguir usando Copilot con normalidad, simplemente tus datos no se envían para entrenar modelos.

Y para el proyecto WordPress en GitHub, ¿qué pasa?

El desarrollo de WordPress depende cada vez más de GitHub. La organización WordPress en GitHub tiene 191 repositorios públicos, siendo los más importantes Gutenberg (el editor de bloques, con más de 11.500 estrellas), wordpress-develop (el repo de desarrollo del core), WordPress Playground (WordPress en el navegador), Openverse (búsqueda de medios con licencia libre) y uno bastante goloso que se llama agent-skills, que proporciona conocimiento sobre WordPress a asistentes de código con IA.

El core de WordPress se sigue gestionando con Subversion como fuente canónica, y los repos de GitHub son espejos de solo lectura, pero Gutenberg se desarrolla de forma nativa en GitHub, con issues, pull requests y toda la infraestructura de CI/CD integrada. Incluso si quieres avisar de un fallo en el editor de WordPress en el Trac de WordPress te lo cierran y te mandan a GitHub.

Un matiz importante es que WordPress en GitHub no opera como una organización de pago con las protecciones de Copilot Business o Enterprise. Eso significa que la exención de entrenamiento para organizaciones de pago no se le aplican al proyecto.

Si un contribuidor a WordPress usa Copilot con su cuenta personal mientras trabaja en Gutenberg y no ha desactivado el entrenamiento, sus datos de interacción (que incluyen el contexto del código de Gutenberg) pueden acabar en el dataset.

Y lo más llamativo es que WordPress publicó en febrero de 2026 unas directrices de IA para contribuidores que dicen expresamente que se puede usar Copilot para contribuir al proyecto, siempre que se declare el uso, el resultado sea compatible con la GPL v2 y se revise todo, pero esas directrices se escribieron antes de este cambio de política. No dicen nada sobre el entrenamiento de datos, porque cuando se redactaron, este cambio no existía.

Tampoco hay ningún mecanismo a nivel de repositorio para impedir que los datos se usen. Un contribuidor del hilo de la FAQ de GitHub lo preguntó directamente, y GitHub confirmó que no hay opt-out por repositorio. Copilot funciona a nivel de cuenta individual, y la configuración del repositorio no puede anular la del usuario.

Comparado con otros proyectos de código abierto, la postura de WordPress es bastante permisiva con la IA. Gentoo Linux, por ejemplo, empezó a migrar de GitHub a Codeberg en febrero de 2026 precisamente por la presión de Copilot, y prohíbe directamente las contribuciones generadas con IA. La Software Freedom Conservancy abandonó GitHub en 2022 y lanzó una campaña de «Give Up GitHub» por los mismos motivos.

WordPress ha ido en la dirección contraria: repositiorio de agent-skills, archivos AGENTS.md en Gutenberg para dar contexto a los asistentes de código, Matt Mullenweg hablando con entusiasmo de que Claude Code y herramientas similares van a generar la mayoría de contribuciones en unos años. E

s una apuesta clara por la IA como herramienta de desarrollo, pero este nuevo cambio de GitHub plantea una pregunta que nadie ha respondido aún, y es que ¿debería el proyecto WordPress actualizar sus directrices para recomendar a sus contribuidores que desactiven el entrenamiento de datos cuando trabajan en repositorios del proyecto?

La cuestión de la GPL

WordPress usa la licencia GPL v2, y hay un debate legal abierto sobre si entrenar una IA con código GPL obliga a que el modelo resultante también sea GPL. A día de hoy ningún tribunal ha dictaminado eso. La GPL se escribió pensando en código fuente legible por humanos y en programas que «contienen» o «enlazan» código GPL, no en matrices de parámetros estadísticos que codifican patrones extraídos de millones de líneas de código.

Donde sí hay un problema real es en la salida. GitHub reconoce que aproximadamente un 1% de las sugerencias de Copilot pueden contener fragmentos de más de 150 caracteres que coinciden con el código de entrenamiento. Si Copilot reproduce código GPL tal cual, sin atribución ni aviso de licencia, eso es una violación práctica de la licencia aunque la teoría sobre el modelo en sí no esté resuelta.

El caso legal más relevante es Doe v. GitHub, la demanda colectiva presentada en noviembre de 2022 que acusa a Copilot de haberse entrenado con miles de millones de líneas de código sin respetar las licencias de código abierto. El tribunal desestimó las reclamaciones de copyright y DMCA, pero las de incumplimiento de contrato y violación de licencias open source siguen adelante. El caso está ahora en el noveno circuito de apelaciones y podría tener sentencia en 2026. Si sale a favor de los demandantes cambia las reglas para todo el sector.

Cómo desactivar el entrenamiento de la IA de Microsoft

El proceso es sencillo y no afecta al funcionamiento de Copilot. Sigues recibiendo sugerencias con normalidad, lo único que cambia es que tus datos dejan de alimentar los modelos.

1. Ve a github.com/settings/copilot.
2. Busca la sección de Privacy (Privacidad).
3. Desactiva la opción que permite a GitHub usar tus datos para entrenamiento de modelos de IA.
4. Guarda los cambios.

Si ya tenías desactivada la opción anterior de recopilación de datos para mejoras del producto, tu configuración se ha mantenido y no necesitas hacer nada.

Mi consejo es que lo desactives, especialmente si trabajas con código de clientes o contribuyes a proyectos de código abierto. No pierdes nada en la experiencia de uso de Copilot y te ahorras posibles problemas de confidencialidad y de cumplimiento normativo.

¿Y ahora qué?

Este cambio de GitHub no es un caso aislado ni de lejos, es la misma jugada que ya hemos visto con Meta, LinkedIn, X y Adobe de cambiar las condiciones por defecto, confiar en que la mayoría de usuarios no va a leerse el email ni cambiar nada, y usar esa inercia como base de datos de entrenamiento gratuita.

La diferencia con GitHub es que aquí no hablamos de fotos de vacaciones o publicaciones en redes sociales, hablamos de código. En GitHub subes código de trabajo, código de clientes, código de proyectos de código abierto con licencias específicas. El impacto potencial es más técnico, más contractual y más difícil de deshacer.

Mientras tanto, el caso Doe v. GitHub sigue su curso en apelación, las autoridades europeas de protección de datos siguen cuestionando los modelos de aceptación explícita (opt-out) para entrenamiento de IA, y la comunidad de código abierto sigue dividida entre los que abrazan la IA como herramienta de desarrollo y los que ven cómo su trabajo acaba alimentando modelos propietarios sin contrapartida.

Yo no estoy ni en un extremo ni en otro, sino en lo que creo que es lo más lógico, además de legítimo: abrazo la IA como herramienta, pero no admito que las empresas que venden la herramienta se apropien de mi contenido, creado con la herramienta o no.

Lo que sí puedes hacer ya mismo es entrar en tus ajustes de Copilot en GitHub y decidir por tu cuenta si quieres que tu código sirva para entrenar la IA de Microsoft. Eso no te lo puede decidir nadie más.

Con la inteligencia artificial conversacional puedes crear un plugin de WordPress completo, funcional, seguro y hasta publicable en el repositorio oficial de WordPress.org sin escribir ni una sola línea de código tú mismo. Se le llama vibe coding y, como ya te conté en detalle, consiste en describir lo que quieres a una IA y dejar que ella genere el código por ti.

Pero ojo, que no sea magia no significa que no requiera trabajo. La IA escribe el código, sí, pero tú tienes que saber qué pedirle, cómo probarlo y cómo asegurarte de que lo que te ha dado funciona de verdad y no es un desastre que va a romper tu web. Eso es exactamente lo que vamos a hacer en este tutorial.

Vamos a crear juntos, paso a paso, un plugin de barra de progreso de lectura con tiempo estimado. Un plugin real, útil, con página de ajustes, permisos por rol, selección de tipos de contenido, personalización de colores y posición. Al final del tutorial lo tendrás funcionando en tu WordPress de prueba y, si quieres, publicado en tu web, GitHub o incluso en el repositorio oficial de WordPress.org, esto ya lo decides al final.

Si quieres contexto sobre por qué es bueno que más gente cree plugins con IA o prefieres valorar los argumentos en contra y a favor antes de empezar, ahí tienes los artículos. Aquí vamos directos a la práctica.

Lo que necesitas antes de empezar

No necesitas saber programar, pero sí tener unas cuantas herramientas preparadas. Sin ellas el tutorial no funciona.

Un sitio WordPress de prueba: Esto es innegociable: nunca pruebes un plugin nuevo en tu web en producción. Necesitas un WordPress local o un staging donde puedas romper cosas sin consecuencias. Si no tienes uno montado, sigue esta guía de entornos de desarrollo local y vuelve aquí cuando lo tengas listo.

Un editor de texto/código: Te recomiendo Visual Studio Code, que es gratuito, funciona en todos los sistemas operativos y es el que usa casi todo el mundo. No vas a escribir código en él, pero lo necesitas para organizar los archivos del plugin y copiar lo que te dé la IA en cada archivo correspondiente.

Acceso a una IA conversacional: No voy a recomendar ninguna en concreto. Hay varias buenas para generar código (Claude, ChatGPT, Gemini, Copilot…) y cada una tiene sus ventajas. Lo que sí te digo es que para generar código de plugins las versiones de pago suelen dar resultados bastante mejores que las gratuitas, y lo ideal es una que permita conversaciones largas y adjuntar archivos. Si quieres ahorrar costes, también puedes usar IA en local, aunque los resultados para código complejo suelen ser inferiores a los de los modelos grandes.

Plugin Check (PCP): Instálalo en tu WordPress de prueba. Es el plugin oficial del equipo de revisión de WordPress.org y analiza tu plugin buscando problemas de seguridad, rendimiento y cumplimiento de estándares. Vas a usarlo bastante.

Query Monitor: Otro plugin imprescindible para el WordPress de prueba. Query Monitor te muestra indicadores visuales de si algo va mal: consultas lentas a la base de datos, errores de PHP, problemas de rendimiento… No necesitas entender el código para ver que hay alertas rojas donde no debería haberlas.

WP Crontrol: También obligatorio, y no solo como desarrollador. Este plugin sirva para crontrolar lo que hacen las tareas en segundo plano que se ejecutan en WordPress, de plugins, temas, del mismo WordPress. A los efectos de desarrollo muchas veces te va a ayudar a parar procesos, ejecutarlos anticipadamente para comprobar si funcionan, montones de cosas que cuando las necesites me entenderás.

Kit de emergencia anti-caché: ¿A que no quieres tener que andar vaciando cachés cada vez que hagas un cambio? Pues instala este plugin, lo creé justo para no pelearte con la caché en entornos de desarrollo, y Vibe Coder o no, estás en modo desarrollo ¿o no te habías dado cuenta?

Download Plugin: Este plugin no hace falta que lo tengas siempre instalado, pero conviene para después de hacer las pruebas, para descargarte el zip finalizado de la instalación de desarrollo. Cuando lo activas añade un enlace en la pantalla de plugins para descargarlo fácilmente.

Activar el modo debug: Tienes dos opciones. La sencilla es instalar un plugin como Debug Log Manager, que te permita activar y desactivar las constantes de depuración de WordPress directamente desde el escritorio, sin tocar archivos, y que además incluye un visor del registro de errores integrado.

La manual pasa por abrir el archivo wp-config.php de tu instalación (está en la carpeta raíz de WordPress) y añadir estas líneas justo antes de donde dice /* That's all, stop editing! */:

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

Con esto WordPress guardará todos los errores en un archivo llamado debug.log dentro de la carpeta wp-content. Si estás en local cualquiera de las dos opciones te vale, si estás en un staging online el plugin es más cómodo.

Para una visión completa de todas las herramientas disponibles para desarrollo WordPress tienes este artículo con todas las imprescindibles.

Antes de pedirle nada a la IA, piensa y planifica

Este es el paso que separa un plugin decente de un engendro con 47 errores, y también es un paso previo que a la larga te va a ahorrar una enorme pérdida de tiempo posterior. Hazme caso, aprende de mis errores y antes de abrir la IA, siéntate y piensa.

¿Hace falta tu plugin?

Antes de dedicar tiempo a crearlo, comprueba lo más obvio:

• Busca en el directorio de plugins de WordPress.org con diferentes términos. ¿Existe ya algo que hace exactamente lo mismo?
• Si hay varios que hacen algo parecido, ¿el tuyo aporta algo diferente? ¿Lo resuelve de otra forma, es más sencillo, más ligero, tiene un enfoque distinto?
• ¿Resuelve un problema real que tenga suficiente gente, o es un capricho personal que no le interesa a nadie más?

Si la respuesta honesta es «ya hay cinco que lo hacen igual de bien», ahórrate el tiempo y usa uno de esos. No pasa nada, la idea es crear cosas que aporten, no duplicar por duplicar.

Ten muy claro qué es lo que quieres

Esto es lo que va a convertirse en tu prompt, así que cuanto más claro lo tengas aquí, mejor será el resultado. Tienes obligatoriamente que hacerte estas preguntas:

• ¿Qué hace el plugin exactamente? Funcionalidad concreta, nada de ideas vagas tipo «algo para mejorar la experiencia de lectura».
• ¿Dónde aparece? ¿Solo en el frontend, solo en el panel de administración, en ambos?
• ¿Qué opciones puede configurar el usuario?
• ¿Quién puede configurarlo? ¿Solo el administrador, también los editores?
• ¿En qué tipos de contenido funciona? ¿Entradas, páginas, custom post types?
• ¿Qué NO debe hacer? Limitar el alcance es tan importante como definir lo que sí hace.

Para nuestro plugin de ejemplo, la especificación quedaría así:

• Qué hace: muestra una barra de progreso de lectura que avanza según el usuario hace scroll, y el tiempo estimado de lectura del contenido.
• Dónde aparece: la barra en el frontend (parte superior o inferior de la ventana), el tiempo estimado dentro del contenido. Los ajustes en el panel de administración.
• Opciones configurables: color de la barra, posición (arriba o abajo), altura de la barra, mostrar u ocultar el tiempo estimado, velocidad de lectura en palabras por minuto, en qué tipos de contenido aparece.
• Quién lo configura: solo usuarios con rol de administrador.
• En qué contenido: entradas por defecto, pero configurable para incluir páginas u otros tipos de contenido.
• Qué NO hace: no guarda datos de los visitantes, no añade analytics, no se conecta a servicios externos, no modifica el contenido del post.

Dale habilidades a la IA: skills para WordPress

Antes de pedirle que genere código hay algo que marca la diferencia entre un resultado mediocre y uno profesional, y es ni más ni menos algo que habrás leído por ahí que es un nivel avanzado, pero que resulta que es muy sencillo de aplicar. Me refiero a darle a la IA conocimiento especializado sobre cómo se programa bien en WordPress.

Las skills o instrucciones especializadas son archivos de texto que enseñan a la IA las buenas prácticas, los patrones correctos y los errores más comunes, en este caso en el desarrollo de plugins. Sin ellas, la IA tiende a generar código anticuado, con fallos de seguridad o que no pasaría la revisión del directorio de plugins de WordPress.org, que debe ser nuestro estándar a conseguir, lo vayamos a publicar o no.

¿Y por qué te importa esto si no sabes programar? Porque tú no puedes revisar si el código sigue los estándares de WordPress, pero si la IA tiene instrucciones claras sobre esos estándares antes de empezar, las probabilidades de que lo haga bien suben mucho.

Dónde conseguir skills de IA:

• Las skills de AyudaWP están enfocadas específicamente a desarrollo de plugins, seguridad y rendimiento en WordPress. Son las que yo uso y las que te recomiendo como punto de partida.
• El repositorio oficial de WordPress (agent-skills) tiene un conjunto más amplio que cubre también bloques, temas y la API REST.
• Tanto Anthropic como OpenAI tienen sus propios repositorios de skills con instrucciones genéricas y específicas para distintos tipos de desarrollo.

Cómo usar skills de IA:

Cada IA tiene su forma de cargar este tipo de instrucciones. Algunas permiten adjuntar archivos al inicio de la conversación, otras tienen carpetas de configuración donde las detectan automáticamente, y otras aceptan que pegues las instrucciones directamente en el primer mensaje. Lo importante es que la IA las tenga disponibles antes de pedirle que genere código, no después.

Si quieres profundizar en cómo configurar cada IA concreta (Claude, ChatGPT, Copilot, Cursor…) para que cargue estas instrucciones de forma permanente, tienes esta guía completa sobre cómo configurar las IAs para programar WordPress.

El prompt: unas buenas instrucciones definen la calidad del resultado

No pidas todo de golpe

Este es probablemente el consejo más importante de todo este tutorial. La tentación es describir el plugin entero en un mensaje enorme del tipo «quiero una barra de lectura con ajustes de color, posición, tiempo estimado, permisos por rol, selector de tipos de contenido…».

El problema con las IAs, y en general en la vida, es que cuantas más cosas metes en un solo prompt, más probabilidades hay de que algo falle. Y cuando falla no sabes si el error está en la barra, en los ajustes, en los permisos o en la interacción entre todos ellos.

El enfoque que funciona es hacer peticiones por versiones, de manera que empieces con la versión más básica que haga algo visible y funcional, y una vez eso funcione y esté probado, añades la siguiente pieza, y así paso a paso hasta completar el plugin.

Para nuestro ejemplo, como yo abordaría las versiones sería así:

• Versión 1: solo la barra de progreso, con un color fijo, que aparezca en todas las entradas. Sin ajustes, sin extras. Lo mínimo para ver que funciona.
• Versión 2: página de ajustes con selector de color, posición de la barra (arriba/abajo), altura y selector de tipos de contenido.
• Versión 3: cálculo y visualización del tiempo estimado de lectura, con opción de activarlo o desactivarlo y configurar las palabras por minuto.
• Versión 4: permisos por rol para acceder a la página de ajustes.

Cómo escribir un buen prompt para un plugin de WordPress

La estructura que mejor funciona tiene estas partes:

1. Rol y contexto: dile a la IA quién es y para qué trabaja.
2. Qué tiene que hacer esta versión concreta: solo la funcionalidad de esta versión, nada más.
3. Requisitos técnicos no negociables: estándares de WordPress, seguridad, compatibilidad PHP, archivos separados para CSS y JS, funciones con prefijo propio, preparado para traducción.
4. Estructura de archivos esperada: que sepa de antemano cómo organizar el código.
5. Lo que NO quieres: que no añada nada que no hayas pedido, que no proponga extras, que no sugiera mejoras.

Aquí tienes el prompt real para la versión 1 de nuestro plugin de ejemplo. Puedes copiarlo tal cual y/o adaptarlo a tu propio plugin:

Eres un desarrollador WordPress senior especializado en creación de plugins para el repositorio oficial de WordPress.org.

TAREA:
Crea la versión 1.0.0 de un plugin llamado "Reading Time Progress Bar Pro" con el slug "reading-time-progress-bar-pro" y el prefijo "rpb_" para todas las funciones, clases, constantes y handles.

FUNCIONALIDAD DE ESTA VERSIÓN (solo esto, nada más):
- Muestra una barra de progreso horizontal fija en la parte superior de la ventana del navegador.
- La barra avanza de 0% a 100% según el usuario hace scroll por el contenido del post.
- Solo aparece en entradas individuales (single posts).
- Color fijo: #2563eb (azul).
- Altura fija: 4px.
- La barra debe estar por encima de cualquier otro elemento (z-index alto).

REQUISITOS TÉCNICOS OBLIGATORIOS:
- Cumplir los WordPress Coding Standards.
- Compatible con PHP 7.4 hasta PHP 8.3.
- Todo el CSS en un archivo externo en /assets/css/, cargado con wp_enqueue_style().
- Todo el JavaScript en un archivo externo en /assets/js/, cargado con wp_enqueue_script().
- NUNCA imprimir etiquetas script o style directamente con PHP.
- Todas las cadenas de texto preparadas para traducción con el text domain 'reading-time-progress-bar-pro'.
- Escapar todo el output.
- Incluir archivo readme.txt válido para WordPress.org.
- El archivo PHP principal solo debe contener la cabecera del plugin, constantes y la carga de los archivos de /includes/.
- Cada funcionalidad en su archivo separado dentro de /includes/.
- Entrega todo en un archivo comprimido ZIP, listo para instalar.

ESTRUCTURA DE ARCHIVOS:
reading-time-progress-bar-pro/
├── reading-time-progress-bar-pro.php (archivo principal, solo bootstrap)
├── readme.txt
├── assets/
│   ├── css/
│   │   └── frontend.css
│   └── js/
│       └── frontend.js
└── includes/
    └── class-rpb-frontend.php

NO QUIERO:
- Nada de página de ajustes en esta versión.
- Nada de opciones configurables.
- Nada de funcionalidades extra que no haya descrito.
- Nada de sugerencias de mejoras futuras.
- Nada de explicaciones largas, solo el código de cada archivo.

Optimiza el prompt antes de enviarlo

Si quieres asegurarte de que el prompt tiene buena estructura y no te falta nada importante, puedes pasarlo por el optimizador de prompts de AyudaWP.

Selecciona la plantilla de «Desarrollo de código WordPress», pega tu instrucción principal, ajusta el rol a desarrollador senior, marca las restricciones que apliquen (WordPress Coding Standards, sin anglicismos, código comentado) y genera la versión optimizada. Muchas veces añade contexto que se te había pasado por alto.

Ajustes que te recomiendo si usas el optimizador de prompts para esta tarea:

1. Plantilla inicial – Utiliza la de desarrollador de código WordPress, te ahorra clics en todos estos ajustes:
   • Rol e identidad de la IA.
   • Contexto y audiencia.
   • Formato de salida.
2. Restricciones y lo que debe evitar – Unos pequeños ajustes te quitarán ruido a la respuesta y aportan mejoras:
   • No repetir información básica obvia
   • Código siempre comentado
   • Seguir WordPress Coding Standards
3. Técnicas avanzadas – Te ayudarán y mucho:
   • Usar etiquetas XML para estructurar
   • Permitir preguntas de aclaración
   • Incluir ejemplo de entrada/salida (few-shot)

Lo mejor de usar el optimizador de prompts es que puedes descargarte los prompts mejorados y tener varias versiones, guardarlos para uso futuro, tener el historial. Vamos, imprescindible.

Bola extra: Proyectos y tareas

Si tu IA favorita lo permite organiza tus tareas usando proyectos, carpetas o como lo llame. Este tipo de herramienta facilita cosas muy importantes:

1. Tener tu trabajo organizado
2. Ajustes personalizados para cada tarea, distintos de las preferencias generales
3. Mantener contexto entre distintos prompts del mismo trabajo
4. Memoria contextual del trabajo al estar todo en un mismo entorno

¿Te había dicho ya que en el trabajo con IAs generativas el contexto lo es todo? Pues es así, y usando proyectos, tareas o carpetas, como se estructure tu IA, es el modo más efectivo.

Gestionar la conversación con la IA

Antes de ver el proceso versión por versión, tres reglas que aplican a cada interacción con la IA durante todo el desarrollo del plugin:

• La IA va a preguntar, y eso es normal: Si has hecho bien el prompt, las preguntas serán pocas y concretas: «¿quieres que el z-index sea 9999 o prefieres otro valor?», «¿el color hexadecimal incluye transparencia?». Responde solo a lo que pregunte, sin añadir ideas nuevas. Cada cosa que añadas fuera de plan es una puerta abierta a complicaciones.
• Frena la verborrea: Hay IAs que por cada línea de código te sueltan tres párrafos explicando por qué han tomado esa decisión, qué alternativas había y qué podrías mejorar en el futuro. Si te pasa, córtala: «Genera solo el código tal como lo he descrito. Sin explicaciones adicionales, sin alternativas, sin sugerencias. Solo los archivos con su código.»
• La trampa de las sugerencias infinitas: Esto es especialmente común con GPT, aunque todas lo hacen en mayor o menor medida. No hace más que de darte el código y enseguida te va a soltar cosas como, «¿quieres que añada también un modo oscuro? ¿lo integramos con Google Analytics? ¿quieres que sea compatible con AMP?». La respuesta es siempre NO. Si no estaba en la especificación que preparaste no entra. Anota las ideas que te parezcan buenas para futuras versiones, pero sigue con lo que tenías planeado, no te dejes engatusar.

Si caes en esa espiral de «sí, ponle eso también», en dos horas tienes un engendro con 15 funcionalidades a medio hacer, errores que se cruzan entre sí y ninguna posibilidad real de arreglarlo que no sea empezar de cero.

Dicho esto, pasamos a la acción… ¿no?

Versión 1: Tu primer plugin funcional

Esta es la versión más importante de todo el proceso. Y no lo es porque sea la más completa (es la más básica), sino porque es donde aprendes el ciclo completo: pedir, montar, probar, corregir, auditar. Cuando domines este ciclo con la V1, repetirlo con las demás versiones es más mecánico.

Paso 1: Enviar el prompt

Toma el prompt que preparaste en la sección anterior (o adáptalo a tu propio plugin) y suéltaselo a la IA. Si has cargado las skills de WordPress previamente mejor, si no, al menos pégalas en este primer mensaje o adjúntalas como archivo.

Recuerda que este prompt es solo para la versión 1.  Aquí solo queremos la barra de progreso con color fijo, sin ajustes, sin extras.

Es tentador añadir «y ya que estás, ponle también los ajustes» pero no lo hagas. Queremos algo pequeño, que podamos probar por completo y asegurarnos de que funciona antes de añadir nada más.

Regálate pequeños triunfos, no una tarea enorme desde el principio.

Paso 2: Evaluar lo que te devuelve

La IA te debería dar un zip con todos los archivos, y si por algún motivo no puede (limitaciones de su sistema) te entregará los archivos por separado con indicaciones de cómo organizarlos en carpetas. En cualquier caso, y siempre antes de instalar tu recién y flamante nuevo plugin versión 1.0, haz una comprobación rápida:

¿Te ha dado todos los archivos que pediste?

Revisa que estén todos los de la estructura que indicaste en el prompt. En nuestro ejemplo deberían ser cinco: reading-time-progress-bar-pro.php, readme.txt, includes/class-rpb-frontend.php, assets/css/frontend.css y assets/js/frontend.js.

Si falta alguno, pídeselo:

Falta el archivo assets/js/frontend.js. Genéralo siguiendo las mismas instrucciones del prompt original.

¿Ha añadido algo que no pediste?

Mira por encima si hay archivos extra, si ha metido una página de ajustes que no tocaba, o si ha añadido funcionalidades que no estaban en el prompt. Si es así, díselo claramente:

Has añadido una página de ajustes y un selector de color. No los he pedido en esta versión. Elimínalos y dame solo lo que indicaba el prompt: la barra básica con color fijo, sin opciones.

¿Ha empezado a hacer preguntas o sugerencias en vez de darte el código?

Esto pasa bastante. La IA te responde con «Antes de empezar, tengo algunas preguntas sobre la implementación…» seguido de diez preguntas sobre cosas que ya estaban claras en el prompt. Si el prompt estaba bien hecho y las preguntas no aportan nada, responde:

Toda la información necesaria está en el prompt. Genera el código tal como lo he descrito.

Si alguna pregunta es realmente necesaria (algo que se te olvidó especificar) respóndela de forma escueta y pídele que genere el código.

Paso 3: Instalar, activar y primera comprobación

Ve a la pantalla de plugins en el escritorio de WordPress y haz clic en «Añadir nuevo > Subir», esto ya sabes hacerlo, sube el zip y tras subirlo actívalo. Tu plugin debería aparecer en la lista con el nombre «Reading Time Progress Bar Pro», la descripción y los datos de versión que indicaste en el prompt.

Si por lo que sea no aparece comprueba que la carpeta está dentro de wp-content/plugins/, que el archivo PHP principal tiene la cabecera correcta y que no has dejado la carpeta del plugin metida dentro de otra carpeta extra (un error muy habitual al descomprimir ZIPs: plugins/reading-time-progress-bar-pro/reading-time-progress-bar-pro/).

Si aparece actívalo, y pueden pasar tres cosas:

• Se activa sin problema: Perfecto, pasa al siguiente paso.
• Aparece un mensaje de error pero el sitio sigue funcionando: Copia el mensaje de error exacto. Lo vas a necesitar.
• Pantalla blanca o error grave: No te asustes. Accede a tu carpeta de plugins por FTP o gestor de archivos y cambia el nombre de la carpeta del plugin (por ejemplo, de reading-time-progress-bar-pro a reading-time-progress-bar-pro-OFF). Esto lo desactiva inmediatamente. Luego abre el debug log (wp-content/debug.log) y copia el último error que aparezca.

Si has tenido un error salta directamente al paso 7 (corrección). Si todo ha ido bien sigue a continuación con el paso 5.

Paso 4: Probar que funciona de verdad

¿A que da como gustirrinín? No me negarás que es un subidón que se active tu primer plugin hecho con IA ¿verdad?

Pero, ah, el hecho de que se haya activado sin errores no significa que funcione. Ahora toca comprobarlo en la web.

Visita una entrada de tu blog de prueba y comprueba:

• ¿Se ve la barra azul en la parte superior de la ventana del navegador?
• ¿La barra avanza según haces scroll hacia abajo?
• ¿Llega al 100% cuando llegas al final del contenido?
• ¿Se restablece a 0% cuando vuelves arriba del todo?

Ahora comprueba donde no debería aparecer:

• Visita la página de inicio o el archivo del blog. ¿Sale la barra? No debería.
• Visita una página (no una entrada). ¿Sale? No debería en esta versión.
• Entra en el panel de administración. ¿Sale? No debería aparecer nunca ahí.

Prueba también en otro navegador (si usas Chrome, prueba en Firefox o al revés) y en el móvil (o usando el modo responsive de las herramientas de desarrollo del navegador, pulsando F12 y el icono de dispositivo).

Si algo no funciona como debería anota exactamente qué falla para luego decírselo a la IA: «la barra aparece pero no se mueve al hacer scroll», «la barra no aparece en ningún sitio», «la barra aparece también en páginas y no debería». Cuanto más preciso seas más fácil será para la IA corregirlo.

Paso 5: El documento resumen (tu mapa del plugin)

Antes de seguir adelante, pídele a la IA un documento que te explique en lenguaje normal qué hace cada archivo del plugin y cómo se conectan entre sí:

Te adjunto todos los archivos de mi plugin Reading Time Progress Bar Pro versión 1. Necesito un documento resumen en español que explique:

1. Qué hace cada archivo y cuál es su función dentro del plugin.
2. Cómo se conectan los archivos entre sí (qué archivo carga a cuál).
3. Qué hace cada sección o función principal, explicado para alguien que no sabe programar.
4. Dónde está la lógica del frontend (lo que ve el visitante).

El documento es para mi uso interno, para poder hablar contigo sobre el plugin sabiendo a qué parte me refiero.

Este documento es tu salvavidas. Cuando algo falle más adelante, necesitas poder decirle a la IA «el problema está en la función que calcula el porcentaje de scroll» en vez de «no funciona». Guárdalo junto al código del plugin como oro en paño, expórtalo, adjúntalo al proyecto, copiapega en un Word, lo que te sea más cómodo.

Paso 6: Comprobaciones de seguridad y calidad

Incluso si todo parece funcionar hay cosas que no se ven a simple vista. Estas herramientas las detectan por ti:

Plugin Check (PCP): ve a Herramientas → Comprobar plugins en tu escritorio de WordPress, selecciona tu plugin, activa todas las casillas y ejecuta el análisis, te dará una lista de resultados:

• Errores: hay que corregirlos sí o sí. Son problemas de seguridad, funciones mal usadas o incumplimientos graves de los estándares.
• Advertencias: recomendaciones que conviene atender. No son graves pero pueden dar problemas en la revisión de WordPress.org.
• Recomendaciones: mejoras a tener en cuenta, casi siempre de rendimiento.

Si tienes errores no los ignores. Copia cada mensaje de error exacto (el texto completo, con la ruta del archivo y el número de línea), o exporta el listado completo usando los botones que ofrece Plugin Check porque los vas a necesitar en el paso siguiente.

Si dudas qué formato elegir descárgalo en formato markdown, es muy ligero y a las IA les encanta.

Debug Log: abre la pantalla del plugin Debug Log Viewer y mira el visor del log, o abre directamente wp-content/debug.log con VS Code, lo que prefieras. Busca líneas que contengan el nombre de tu plugin o sus archivos. Los «Fatal error» y «Error» son problemas graves, los «Warning» y «Notice» son menores pero conviene corregirlos. Copia todo lo que encuentres y luego se lo cascas a la IA.

Query Monitor: mira su panel en la barra de administración mientras visitas una entrada con la barra activa. Fíjate en dos cosas, si la pestaña de errores PHP muestra algo en rojo y si la pestaña de consultas a la base de datos tiene números inusualmente altos o alertas (suele ponerse en rojo). Para una versión 1 tan sencilla no debería haber consultas a la base de datos propias del plugin, si las hay es señal de que algo no está bien.

Paso 7: Correcciones y cambios – El segundo prompt casi siempre es el más importante

Si las pruebas o las comprobaciones han detectado problemas toca corregir. La forma en que le describes el error a la IA es casi tan importante como el prompt original. No vale con decir «no funciona». Necesitas darle toda la información:

El plugin Reading Time Progress Bar Pro versión 1 tiene los siguientes problemas.

PROBLEMA 1 - Error en el debug log:
[pega aquí el mensaje de error exacto, incluyendo archivo y número de línea]

PROBLEMA 2 - Error de Plugin Check:
[pega aquí el mensaje de PCP exacto]

PROBLEMA 3 - Funcional:
La barra aparece correctamente en las entradas pero también aparece en las páginas, y en esta versión solo debería mostrarse en entradas individuales.

Corrige estos tres problemas. No cambies nada más del código, no añadas funcionalidades nuevas, no hagas mejoras que no te haya pedido.

Fíjate en lo último: «no cambies nada más». Esto es importante porque muchas IAs aprovechan una corrección para «mejorar» otras cosas que no les habías pedido, y eso puede romper lo que antes funcionaba. Tú ni caso, aunque insista.

Una vez te dé las correcciones, aplícalas y vuelve al paso 5, probando todo desde el principio. No solo lo que se ha corregido, sino también lo que antes funcionaba, porque una corrección puede romper otra cosa.

Regla de los tres intentos: si llevas tres o cuatro rondas para el mismo problema y la IA no lo resuelve, para. Borra esa parte y pídesela de nuevo desde cero en un mensaje nuevo y más claro. Es más rápido que seguir apilando parches.

Paso 8: Mejorar y auditar

Cuando todo funciona y las comprobaciones salen limpias, quedan dos pasadas finales antes de dar la versión 1 por cerrada.

Pasada de mejora: «Mejóralo»

Pídele a la IA que revise su propio código:

Te adjunto el código completo del plugin Reading Time Progress Bar Pro versión 1. Funciona correctamente y pasa Plugin Check sin errores.

Revisa todo el código buscando:
1. Problemas de seguridad que se te hayan pasado (sanitización, escapado, comprobaciones).
2. Problemas de rendimiento (assets cargándose donde no deben, código ejecutándose en cada petición innecesariamente).
3. Incumplimientos de los WordPress Coding Standards.

Dame solo las correcciones necesarias, sin añadir funcionalidades nuevas.

Casi siempre encuentra algo. A veces un esc_html() que falta, a veces un archivo CSS cargándose también en el admin cuando solo debería cargarse en la web. Aplica las correcciones y vuelve a probar desde el principio.

Pasada de auditoría cruzada: Coge todo el código y dáselo a la misma IA en una conversación nueva (sin contexto previo, sin historial de cómo se generó), o mejor aún, a una IA diferente:

Eres un auditor de seguridad y calidad de plugins de WordPress. Te adjunto el código completo de un plugin llamado Reading Time Progress Bar Pro.

Analiza todo el código buscando:
1. Vulnerabilidades de seguridad (XSS, CSRF, inyección SQL, falta de sanitización o escapado).
2. Problemas de rendimiento.
3. Incumplimientos de los WordPress Coding Standards y de las directrices del repositorio de WordPress.org.
4. Errores lógicos o bugs potenciales.

Sé riguroso. Lista cada problema encontrado con su ubicación exacta (archivo y sección) y la corrección propuesta.

La conversación nueva o con una IA diferente son importantes pues al no tener el contexto de cómo se generó el código, lo analiza con ojos frescos y podría detectar cosas que en la conversación original se pasaron por alto.

Aplica las correcciones relevantes, prueba una última vez, y la versión 1 está lista.

Versión 2: Añadir la página de ajustes

Con la versión 1 funcionando y auditada, es hora de empezar a hacer un plugin ya algo más pro, añadirle la funcionalidad de que el usuario pueda configurar el plugin sin tocar código.

El prompt

El prompt para cada nueva versión siempre empieza adjuntando el código completo de la versión anterior. La IA necesita saber qué hay hecho para construir encima:

Te adjunto el código completo y funcional del plugin Reading Time Progress Bar Pro versión 1.0.0.

TAREA:
Actualiza el plugin a la versión 2.0.0 añadiendo SOLO lo siguiente:

PÁGINA DE AJUSTES:
- Añadir una página de ajustes dentro del menú Ajustes de WordPress (Settings API).
- Solo los usuarios con la capacidad manage_options pueden acceder.
- Los ajustes se almacenan en una única opción en la base de datos (no una opción por cada ajuste).

OPCIONES DE LA BARRA:
- Color de la barra: campo de tipo color con valor por defecto #2563eb.
- Posición: selector con dos opciones, arriba o abajo de la ventana. Por defecto arriba.
- Altura: campo numérico en píxeles, por defecto 4, mínimo 1, máximo 20.

OPCIONES DE CONTENIDO:
- Checkboxes para seleccionar en qué tipos de contenido aparece la barra. Listar todos los post types públicos del sitio dinámicamente.
- Por defecto solo 'post' (entradas) activado.

IMPLEMENTACIÓN:
- El frontend ahora debe leer los ajustes guardados en vez de usar valores fijos.
- El CSS dinámico (color, altura, posición) debe aplicarse con wp_add_inline_style(), no con estilos inline en el HTML.
- Crear un nuevo archivo includes/class-rpb-admin.php para toda la lógica de administración.
- Crear un nuevo archivo assets/css/admin.css para los estilos de la página de ajustes.
- Actualizar el readme.txt con la nueva funcionalidad.

REQUISITOS TÉCNICOS:
[los mismos que en la versión 1: WordPress Coding Standards, PHP 7.4+, archivos separados, prefijo rpb_, translation-ready, escapar todo]

NO QUIERO:
- Nada de tiempo estimado de lectura en esta versión.
- Nada de permisos por rol más allá de manage_options.
- Nada de preview en vivo de los ajustes.
- Nada de funcionalidades extra.
- Nada de sugerencias de mejoras.

¡Revisa todo!

Cuando la IA te devuelva el código comprueba que los archivos originales de la V1 se han actualizado (no reemplazado por completo con algo diferente) y que los archivos nuevos (class-rpb-admin.php, admin.css) están incluidos.

A veces la IA te da solo los archivos nuevos y te dice «el resto queda igual», si es así pídele todos los archivos completos:

Dame todos los archivos del plugin completos, incluidos los que no han cambiado. No quiero tener que adivinar cuáles se han modificado y cuáles no

Monta los archivos igual que con la V1 si fuese necesario, o sea, sustituye los que han cambiado, añade los nuevos y revisa la estructura de carpetas.

Probar la versión 2

Primero, repite todas las pruebas de la versión 1. La barra tiene que seguir funcionando exactamente igual que antes en la web, pues si algo se ha roto al añadir los ajustes necesitas detectarlo ahora.

Luego, las pruebas específicas de los ajustes:

• Ve a Ajustes en el menú del escritorio. ¿Aparece la opción del plugin?
• Entra en la página de ajustes. ¿Se ven todos los campos (color, posición, altura, tipos de contenido)?
• ¿Los valores por defecto son correctos sin haber guardado nada? (Azul, arriba, 4px, solo entradas marcado.)
• Cambia el color a rojo, la posición a abajo, la altura a 8px, quita la marca de entradas y cámbialo a páginas. Guarda. ¿Sale el mensaje de confirmación de WordPress?
• Recarga la página de ajustes. ¿Los valores se han guardado correctamente?
• Ve a la web y visita una página. ¿La barra ahora es roja, de 8px y está abajo?
• Visita ahora una entrada y comprueba que no se ve ninguna barra de progreso.

1. Prueba de permisos: si tienes un usuario con perfil de editor o autor en tu WordPress de prueba, inicia sesión con ese usuario o cambia al usuario tras activar el plugin User Switching. ¿Puede ver la opción de ajustes del plugin en el menú? No debería, y si puede acceder es un problema de seguridad que hay que corregir.
2. Plugin Check, Debug Log y Query Monitor: ejecútalos igual que con la V1. Ahora que hay ajustes guardados en la base de datos Query Monitor debería mostrar las consultas correspondientes, pero no deberían ser excesivas (una o dos como mucho para leer las opciones).

Si hay problemas corrígelos con el mismo patrón del paso 8 de la V1: error exacto, qué esperabas, qué pasa, código adjunto.

Cuando todo esté limpio haz las dos pasadas de mejora y auditoría con los mismos prompts adaptados a la versión 2 y pasa a la siguiente.

Versión 3: Tiempo estimado de lectura

Esta versión añade la funcionalidad que convierte el plugin de algo «útil» a un plugin «completo», que muestra al visitante cuánto tardará en leer el contenido.

El prompt

Te adjunto el código completo y funcional del plugin Reading Time Progress Bar Pro versión 2.0.0.

TAREA:
Actualiza el plugin a la versión 3.0.0 añadiendo SOLO lo siguiente:

TIEMPO ESTIMADO DE LECTURA:
- Calcular el tiempo estimado de lectura del contenido del post actual en PHP.
- Mostrar el tiempo estimado en el frontend, justo antes del contenido del post, con el formato "X min de lectura".
- El cálculo se basa en las palabras del contenido divididas entre las palabras por minuto configuradas.
- Usar el filtro the_content para insertar el tiempo estimado. No modificar plantillas del tema.

NUEVOS AJUSTES (añadir a la página existente):
- Activar/desactivar la visualización del tiempo estimado (checkbox, activado por defecto).
- Palabras por minuto: campo numérico, por defecto 200, mínimo 100, máximo 400.

IMPLEMENTACIÓN:
- Crear un nuevo archivo includes/class-rpb-reading-time.php para la lógica de cálculo e inserción.
- El HTML del tiempo estimado debe tener una clase CSS propia para que el usuario pueda personalizarlo con CSS del tema si quiere.
- Actualizar el readme.txt.

REQUISITOS TÉCNICOS:
[los mismos de siempre]

NO QUIERO:
- Nada de permisos por rol adicionales en esta versión.
- Nada de shortcodes ni bloques de Gutenberg.
- Nada de analytics ni seguimiento.
- Nada de funcionalidades extra.

Probar la versión 3

Lo de siempre primero, todas las pruebas de las versiones anteriores. La barra y los ajustes tienen que seguir funcionando exactamente igual.

Pruebas específicas del tiempo de lectura:

• Visita una página o entrada, lo que tuvieses antes activado en los ajustes. ¿Aparece el texto «X min de lectura» encima del contenido?
• ¿El número es razonable? Si la entrada tiene unas 1.000 palabras y está configurado a 200 palabras por minuto, debería decir «5 min de lectura». Si dice 0 o un número absurdamente alto, algo falla en el cálculo.
• Cambia las palabras por minuto en ajustes (ponlas a 100, por ejemplo). ¿El tiempo estimado cambia acorde (ahora debería decir 10 min para la misma entrada)?
• Desactiva el tiempo estimado en ajustes. ¿Desaparece? ¿La barra de progreso sigue funcionando?
• ¿El tiempo estimado aparece solo en los tipos de contenido seleccionados, igual que la barra?
• Si la entrada tiene poco texto (por ejemplo, una frase), ¿muestra «1 min read» o algo raro como «0 min»?

Pasa como siempre Plugin Check, Debug Log, Query Monitor y corrige si hace falta. Las dos pasadas de mejora y auditoría, ya conoces la retahíla.

Advertencia: No te saltes ningún paso de comprobación en ninguna versión, y especialmente en las más avanzadas, no te confíes, que luego vienen los disgustos.

Versión 4: Permisos por perfil de usuario

La última pieza es permitir que el administrador decida qué perfiles (roles) de usuario pueden acceder a los ajustes del plugin.

El prompt

Te adjunto el código completo y funcional del plugin Reading Time Progress Bar Pro versión 3.0.0.

TAREA:
Actualiza el plugin a la versión 4.0.0 añadiendo SOLO lo siguiente:

PERMISOS POR ROL:
- En la página de ajustes, añadir una nueva sección "Permisos".
- Checkboxes con los roles de WordPress que pueden acceder a la página de ajustes del plugin.
- Por defecto solo el administrador tiene acceso.
- El control de acceso debe usar las capacidades de WordPress (capabilities), no comparar nombres de rol directamente.
- Si un rol deja de tener acceso y hay un usuario de ese rol en la página de ajustes, al recargar debe ver un mensaje de permisos insuficientes.

IMPLEMENTACIÓN:
- Modificar la comprobación de permisos existente para usar la nueva configuración.
- Los ajustes de permisos solo los puede modificar un administrador (manage_options), independientemente de qué otros roles tengan acceso a los ajustes del plugin.
- Actualizar el readme.txt con la nueva funcionalidad y subir la versión a 4.0.0.
- Actualizar el changelog en el readme.txt con los cambios de cada versión (1.0.0, 2.0.0, 3.0.0 y 4.0.0).

REQUISITOS TÉCNICOS:
[los mismos de siempre]

NO QUIERO:
- Nada de capacidades personalizadas (custom capabilities).
- Nada de interfaz de gestión de roles.
- Nada de funcionalidades extra.

Probar la versión 4

Las pruebas de permisos requieren un poco más de trabajo porque necesitas usuarios de prueba con diferentes roles. Si no los tienes en tu WordPress de prueba créalos, uno con perfil de editor y otro con el de autor es más que suficiente.

• Con el de administrador: ve a ajustes del plugin, sección permisos. ¿Aparecen los perfiles de WordPress con casillas?
• Marca «Editor» además de «Administrador» y guarda.
• Inicia sesión como editor (o usa de nuevo User Switching). ¿El editor ve la opción de ajustes del plugin? ¿Puede cambiar el color y la posición?
• ¿El editor puede modificar los permisos de quién accede? No debería poder. Esa sección solo debe ser visible para administradores.
• Vuelve al administrador. Desmarca «Editor». Guarda.
• Vuelve a iniciar sesión como editor. ¿Ya no ve la opción de ajustes?
• Inicia sesión como autor. ¿Puede acceder a los ajustes? No debería, no lo has marcado.

Después de las pruebas funcionales, el ciclo completo: Plugin Check, Debug Log, Query Monitor, las dos pasadas de mejora y auditoría.

La auditoría final de todo el plugin

Con las cuatro versiones terminadas, haz una última auditoría cruzada de todo el código completo. Esta vez el prompt debe reflejar que es la revisión final antes de publicar:

Eres un auditor de seguridad y calidad especializado en plugins de WordPress para el repositorio oficial de WordPress.org. Te adjunto el código completo del plugin Reading Progress Bar versión 4.0.0.

Este plugin va a enviarse a WordPress.org para revisión. Necesito que lo analices como si fueras parte del equipo de revisión del directorio de plugins.

Analiza todo el código buscando:
1. Vulnerabilidades de seguridad (XSS, CSRF, inyección SQL, falta de sanitización, escapado o comprobación de permisos).
2. Incumplimientos de las directrices del directorio de plugins de WordPress.org.
3. Problemas de rendimiento.
4. Incumplimientos de los WordPress Coding Standards.
5. Problemas de internacionalización (cadenas sin preparar para traducción, text domain incorrecto).
6. Problemas en el readme.txt (formato, campos obligatorios, longitud de descripción).
7. Limpieza en la desinstalación (¿se eliminan las opciones de la base de datos al desinstalar?).

Sé exhaustivo. Lista cada problema con su archivo, ubicación exacta y corrección propuesta.

Aplica las correcciones, prueba una última vez, y el plugin está listo para compartirlo (si quieres).

Preparar el plugin para compartirlo

Cuando todas las versiones están terminadas, probadas y auditadas, toca preparar el plugin para que otros puedan usarlo.

1. Revisión final con Plugin Check: Ejecuta PCP una (pen)última vez. Tiene que salir limpio, sin errores. Los avisos menores puedes valorarlos, pero los errores tienen que estar resueltos.
2. Debug log limpio: Usa el plugin un rato con el debug activado y comprueba que no aparece nada nuevo en el log relacionado con tu plugin.
3. Revisa el readme.txt: Asegúrate de que tiene todas las secciones necesarias (descripción, instalación, FAQ, changelog), que la descripción corta no supera los 150 caracteres y que los datos de versión, compatibilidad y tags son correctos. Puedes validarlo con el validador oficial de readme.txt de WordPress.
4. Crear el ZIP: La estructura dentro del ZIP importa: la carpeta raíz tiene que llamarse exactamente como el slug del plugin. Para nuestro ejemplo, el ZIP debe contener una carpeta reading-time-progress-bar/ con todo dentro. Si comprimes los archivos sueltos sin la carpeta contenedora, WordPress no lo instalará bien.
5. Probarlo en otro WordPress: Instala el plugin desde el ZIP en una instalación de WordPress diferente a la de desarrollo, preferiblemente limpia (sin otros plugins extra, con un tema por defecto). Repite las pruebas básicas de funcionamiento. Si algo falla aquí que no fallaba en tu entorno de desarrollo, probablemente hay alguna dependencia que no habías detectado.
6. Compartirlo (o no): Elige si quieres distribuir tu plugin y cómo hacerlo, si es que tenías pensado hacerlo. Nada te lo impide, incluso si has detectado una necesidad podrías venderlo.

Subirlo al repositorio oficial de WordPress.org

Si quieres que tu plugin esté disponible para cualquier usuario de WordPress directamente desde el panel de administración, puedes enviarlo al repositorio oficial. Es un proceso que lleva su tiempo pero merece la pena por múltiples motivos, también para ti.

Requisitos previos:

• Una cuenta en wordpress.org (gratis).
• Que el plugin cumpla las directrices del directorio de plugins (si has seguido el tutorial prácticamente es lo que hemos estado haciendo, aplicando los estándares más exigentes).

Comprobaciones antes de enviar:

• PCP limpio, sin errores.
• Licencia GPL-2.0-or-later (o compatible).
• Sin código ofuscado ni minimizado que no se pueda leer.
• Sin llamadas a servicios externos que no estén declaradas y justificadas.
• Que el nombre del plugin no contenga marcas registradas (no puedes llamarlo «WordPress Progress Bar Pro» ni «WooCommerce Time Reader»).

El proceso:

1. Ve a la página de envío de plugins y sube el ZIP.
2. Espera. El equipo de revisión tarda entre unos días y varias semanas dependiendo de la cola. No envíes mensajes preguntando cuánto falta.
3. Recibirás un email con el resultado. Lo más habitual es que, tras pasar un mínimo de una semana, te pidan correcciones en la primera revisión.

Lo que suelen pedir que corrijas:

Las correcciones más frecuentes son siempre las mismas: escapar correctamente todo el output con funciones como esc_html() o esc_attr(), usar nonces en todos los formularios, sanitizar todos los datos de entrada, y comprobar permisos del usuario antes de ejecutar acciones. Si la IA ha usado las skills de WordPress al generar el código, muchas de estas cosas ya estarán bien, pero el equipo de revisión es muy minucioso.

Cuando te pidan correcciones, copia los comentarios del revisor y dáselos a la IA junto con el código completo del plugin para que aplique los cambios.

Una vez aprobado:

WordPress te dará acceso a un repositorio SVN donde subir el código. SVN es un sistema de control de versiones diferente a Git. Los pasos básicos son:

1. Instala SVN en tu ordenador (viene preinstalado en macOS y la mayoría de distribuciones Linux; en Windows puedes instalar TortoiseSVN).
2. Descarga tu repositorio: svn co https://plugins.svn.wordpress.org/tu-plugin
3. Copia los archivos del plugin dentro de la carpeta trunk/.
4. Copia los assets (banner, icono, capturas) en la carpeta assets/.
5. Sube los cambios: svn add * --force y luego svn ci -m "Primera versión"

Si SVN te parece demasiado, hay plugins y scripts que permiten sincronizar desde GitHub, pero eso ya es para otro tutorial.

Aprovecha lo aprendido para tus próximos plugins

Lo que acabas de hacer no sirve solo para este plugin. Has aprendido un proceso que puedes repetir con cualquier idea. Para que la próxima vez sea más fácil y rápida:

Configura tu IA: La mayoría de herramientas de IA permiten guardar preferencias o instrucciones que se aplican a todas las conversaciones. Configura ahí tus requisitos técnicos de WordPress (estándares, prefijos, estructura de archivos, seguridad) para no tener que repetirlos en cada prompt. Tienes todos los detalles de cómo hacerlo en cada plataforma en esta guía de configuración de IAs para WordPress.

Usa la memoria: Si tu IA tiene memoria entre conversaciones, aprovéchala. Dile que recuerde tus preferencias de desarrollo, tus reglas de código, el tipo de plugins que sueles crear. Cada conversación irá mejor que la anterior porque la IA ya conoce tu contexto.

Crea tus propias skills sencillas: No necesitas ser programador para escribir una skill. Es un archivo de texto con instrucciones claras. Si siempre quieres que tus plugins tengan cierta estructura, ciertos estándares o cierto estilo de código, escríbelo en un documento y adjúntalo al inicio de cada conversación. Con el tiempo lo irás refinando y los resultados serán cada vez mejores.

Sigue aprendiendo. Este tutorial cubre el proceso completo de vibe coding para plugins, pero hay mucho más por explorar:

• Si quieres entender a fondo qué son el vibe coding y el agentic coding y cómo funcionan: Programar con IA en WordPress – Vibe Coding y Agentic Coding.
• Si quieres crear un plugin que integre inteligencia artificial (un plugin con IA, no un plugin hecho con IA): Crear tu propio plugin de IA básico para WordPress.
• Si quieres configurar instrucciones permanentes en cada plataforma de IA: Cómo configurar las IAs para programar WordPress.
• Todas las herramientas de desarrollo para WordPress en un solo sitio: Herramientas de desarrollo WordPress imprescindibles.

Y recuerda que la IA es tu herramienta, no tu jefa. Tú decides qué se construye, cómo se prueba y cuándo se para.

He creado esta calculadora precisamente para quitarte esa duda. Metes tus gastos reales, tus horas facturables, lo que quieres ganar, y te dice con números claros cuál es tu tarifa mínima y la recomendada. Además tiene un segundo modo para evaluar proyectos concretos antes de aceptarlos.

Calcula tu tarifa hora de desarrollo web con datos reales

La mayoría de calculadoras de tarifas que encuentras por ahí son genéricas, pensadas para freelances de cualquier sector y normalmente con datos de Estados Unidos o Globales. Esta está hecha con cifras reales de España, con las cuotas de autónomos actualizadas, los rangos de mercado de desarrolladores WordPress y los gastos que un profesional del sector maneja de verdad.

La calculadora tiene en cuenta todo lo que normalmente olvidas al hacer números con una hoja de cálculo rápida, desde la cuota de autónomos (con la tabla de tramos de 2026 incluida) hasta la amortización del hardware, el software, la formación, la gestoría y el IRPF. Porque una cosa es lo que facturas y otra bastante distinta lo que te queda en el bolsillo.

Los resultados se actualizan en tiempo real mientras cambias los campos, así que puedes ir probando diferentes situaciones sin esperar ni pulsar botones. Además muestra tres posibles escenarios de un vistazo (tarifa mínima, recomendada y ambiciosa) con el neto anual que te quedaría en cada caso, un gráfico de distribución para que veas a dónde va cada euro que facturas, y una comparativa visual con los rangos de mercado en España.

Calculadora para programadores WordPress

Mete tus números y mira a ver qué te sale. Los valores por defecto son razonables para un autónomo en España pero cámbialos por los tuyos si vives en otro país para que el resultado sea preciso o que al menos te sirva de referencia. Siempre es mejor un cálculo aproximado que ningún cálculo.

Si prefieres usarla a pantalla completa la tienes también en las herramientas gratuitas de AyudaWP.

Evalua si un proyecto WordPress es rentable

Calcular tu tarifa está muy bien, pero el momento de verdad llega cuando te cae un proyecto encima y tienes que decidir si aceptarlo o no. La pestaña «Evaluar proyecto» de la calculadora sirve para eso.

Funciona de forma muy sencilla.

1. Introduces el presupuesto que te ofrecen (o el que vas a pedir) y las horas que estimas para el proyecto completo, contando desarrollo, pruebas, comunicación con el cliente y revisiones.
2. La calculadora cruza esos datos con tu tarifa base y te dice si el proyecto es viable, cuánto te quedaría limpio después de impuestos y gastos, y el neto por hora trabajada.
3. Si no es viable, te sugiere el presupuesto mínimo y el recomendado para que puedas negociar con cifras en la mano.

Es el tipo de cálculo que muchos hacemos de cabeza o con una cuenta rápida en el móvil, pero que conviene hacer bien antes de comprometerte con semanas de trabajo.

Cuánto cobrar por un proyecto WordPress

Si lo que necesitas no es tanto la calculadora sino entender qué tarifas se manejan en el mercado, qué gastos reales tiene un autónomo en España y cómo calcular tu tarifa paso a paso con explicaciones detalladas, tengo un artículo bastante completo sobre qué cobrar como desarrollador WordPress que actualizo periódicamente con datos de mercado, salarios de referencia y rangos por nivel de experiencia.

La calculadora nació como complemento de ese artículo, de hecho está integrada dentro de él, pero tiene vida propia porque es el tipo de herramienta que usas cada vez que preparas un presupuesto, no solo cuando te planteas tu tarifa por primera vez.

Copia el resumen de tus cálculos

Un último detalle práctico es que la calculadora tiene un botón para copiar los resultados en formato Markdown, que puedes pegar directamente en tus notas, en Notion, en Obsidian o donde guardes tus cosas. Incluye las tarifas calculadas, el desglose de gastos, la distribución de la facturación y tu posición en el mercado. Así no tienes que hacer capturas de pantalla ni apuntar números a mano cada vez que lo uses.

Por supuesto, cualquier duda o mejora que se te ocurra déjala abajo en los comentarios.

La solución habitual es recurrir a trucos como meter espacios dentro de los corchetes, usar entidades HTML ([ y ]) o escapar con bloques de código. Funcionan, a veces, pero hay un método nativo de WordPress mucho más limpio que casi nadie conoce.

El truco del doble corchete

Para que WordPress muestre un shortcode como texto sin ejecutarlo solo tienes que envolverlo con dobles corchetes:

[[gallery]]

WordPress lo muestra como [gallery] en el HTML de la página, pero no lo procesa. El shortcode se muestra tal cual, como texto plano.

Si el shortcode tiene atributos, funciona igual:

[[gallery ids="1,2,3" columns="3"]]

Y si es un shortcode con contenido encerrado, necesitas dobles corchetes en ambas etiquetas:

[[shortcode]Contenido que se muestra como texto[/shortcode]]

Dónde usarlo y dónde no hace falta

Este truco es tanto para el contenido normal de tus entradas y páginas, es decir, el texto que va fuera de bloques de código como si escribes el shortcode dentro de una etiqueta <pre> o <code>. En teoría WordPress no lo ejecuta, pero la realidad es que es una lotería, depende de muuuchas cosas.

Donde más lo vas a agradecer es en tutoriales y guías donde explicas cómo usar un shortcode concreto. En vez de inventar trucos raros para que no se ejecute, le pones dobles corchetes y te olvidas.

Cómo funciona por dentro

Cuando WordPress procesa el contenido de una entrada, la Shortcode API busca patrones con la forma [nombre]. Si encuentra dobles corchetes ([[nombre]]), elimina los corchetes exteriores y devuelve el contenido con los corchetes simples, pero sin ejecutar el shortcode.

Es un comportamiento documentado en la Shortcode API de WordPress, pero está tan poco visible que la mayoría de desarrolladores no lo conocen. Lleva disponible desde WordPress 2.5, que fue la versión que introdujo los shortcodes allá por 2008.

Ejemplo práctico

Imagina que tienes el plugin Contact Form 7 activo y quieres explicar a tus lectores cómo insertar un formulario. Si en tu entrada escribes:

Para insertar el formulario usa [[contact-form-7 id="123" title="Contacto"]]

WordPress mostrará en la página:

Para insertar el formulario usa [contact-form-7 id="123" title="Contacto"]

Sin ejecutar el formulario, sin HTML raro, todo majete.

La próxima vez que necesites mostrar un shortcode como ejemplo en tu contenido acuérdate de esto antes de liarte con entidades HTML o espacios fantasma. Dos corchetes y listo.

Pero ojo, no siempre es cuestión de que tengas la base de datos «sucia» o llena de basura acumulada. Eso es una parte del problema, pero hay otra que es igual de importante o más, las consultas SQL que se ejecutan contra esa base de datos.

Hay tres tipos de consultas problemáticas, y cada una machaca tu servidor de una forma distinta:

• Consultas lentas: tardan demasiado en ejecutarse porque escanean tablas enormes sin índices, usan búsquedas con comodines o hacen JOINs pesados entre varias tablas. Una sola consulta lenta puede bloquear todo lo demás.
• Consultas agresivas: puede que no tarden tanto en ejecutarse, pero devuelven cantidades enormes de datos a la memoria RAM del servidor. Piensa en un plugin que hace SELECT * sobre una tabla con millones de filas sin poner un LIMIT, o una precarga de caché que lanza consultas masivas de golpe.
• Consultas excesivas o frecuentes: individualmente son rápidas, pero se disparan tantas veces por cada carga de página que el efecto acumulado revienta el servidor. El típico caso de un tema o plugin que hace una consulta por cada entrada dentro de un bucle, en vez de traer todo de una sola vez.

Muchas veces el problema es una combinación de las tres, o sea, una consulta que es lenta, se ejecuta muchas veces y además devuelve más datos de los que necesita. Ahí es donde la web se cae pero ya, sin avisar, y luego todo son lloros .

En este tutorial quiero ayudarte a ver cómo identificar exactamente qué consultas están causando problemas en tu base de datos, cómo entender por qué son problemáticas y cómo solucionarlas. Te daré varias opciones según el acceso que tengas a tu servidor, desde un simple plugin hasta comandos por SSH, pasando por phpMyAdmin y códigos PHP que puedes usar sin depender de nadie.

Importante: antes de tocar nada en tu base de datos, haz siempre una copia de seguridad completa. Cualquier operación que hagas directamente sobre la base de datos puede ser irreversible si algo sale mal.

Herramientas para encontrar las consultas problemáticas

Lo primero es lo primero, y antes de arreglar nada necesitas saber qué está pasando exactamente. No vale con suponer que «será tal plugin» o «será que tengo muchas revisiones», necesitas datos concretos.

Dependiendo del nivel de acceso que tengas a tu servidor, tienes varias opciones, así que vamos de menos a más acceso.

Con plugin: Query Monitor

Si solo puedes instalar plugins y no tienes acceso al servidor, Query Monitor es tu mejor aliado. Es gratuito, está en el repositorio oficial y te da una cantidad brutal de información sobre lo que pasa por debajo cada vez que se carga una página.

Instálalo, actívalo y recarga la página que va lenta. Verás una barra nueva en la parte superior del admin con datos de rendimiento. Haz clic en ella y ve directamente a la pestaña Queries.

Lo que tienes que mirar para cada tipo de problema:

• Para encontrar consultas lentas: ordena la lista por la columna de tiempo (duración). Las que estén por encima de 0,05 segundos ya merecen atención. Las que superen 0,5 segundos son un problema serio. Query Monitor las marca en un color distinto para que las veas rápido.
• Para encontrar consultas excesivas: mira el número total de consultas arriba del todo. Un WordPress limpio puede hacer entre 20 y 40 consultas por página. Si ves más de 100, algo va mal. Ve a Queries by Component para ver cuántas hace cada plugin, el tema y el núcleo de WordPress. Así pillas al responsable enseguida. Mira también la pestaña Duplicate Queries, que te muestra consultas que se repiten exactamente iguales, lo que indica que algún componente está pidiendo los mismos datos varias veces sin necesidad.
• Para encontrar consultas agresivas: fíjate en las que devuelven un número muy alto de filas (columna Rows). Una consulta que devuelve miles de filas cuando la página solo necesita mostrar 10 resultados es una señal clara de que algo no está bien optimizado.

Detalle importante: Query Monitor solo te muestra lo que pasa en la carga de página actual. Si el problema ocurre con picos de tráfico, con el cron de WordPress o con procesos en segundo plano, no lo vas a ver aquí. Para eso necesitas las otras herramientas.

Con PHP: detecta consultas lentas sin acceso SSH

Si no tienes acceso SSH y quieres algo más permanente que Query Monitor, que solo te muestra datos de la página actual, puedes usar un mu-plugin que registre automáticamente las consultas problemáticas en un archivo de registro (log).

Lo primero es activar SAVEQUERIES en tu archivo wp-config.php. Añade esta línea antes de donde dice "That's all, stop editing!":

define( 'SAVEQUERIES', true );

Esto hace que WordPress guarde en memoria todas las consultas SQL que ejecuta, junto con el tiempo que tarda cada una y la función que la ha llamado. Pero por sí solo no hace nada visible, necesitas algo que lea esos datos y registre los problemáticos.

Crea un archivo llamado ayudawp-log-slow-queries.php y súbelo a la carpeta /wp-content/mu-plugins/ de tu instalación de WordPress (si la carpeta no existe, créala).

Este es el código:

<?php
/**
 * AyudaWP - Log de consultas SQL lentas, agresivas o excesivas.
 *
 * Registra en un archivo de log las consultas que superen
 * el umbral de tiempo definido y alerta cuando el número
 * total de consultas por página es excesivo.
 *
 * Personalizable: ajusta los umbrales según tu caso.
 * Uso temporal: desactívalo cuando termines de diagnosticar.
 *
 * @package AyudaWP
 */

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

// Solo registrar si SAVEQUERIES está activo.
if ( ! defined( 'SAVEQUERIES' ) || ! SAVEQUERIES ) {
    return;
}

/**
 * Umbral en segundos para considerar una consulta como lenta.
 * Ajústalo según tu caso. 0.05 es un buen punto de partida.
 */
define( 'AYUDAWP_SLOW_QUERY_THRESHOLD', 0.05 );

/**
 * Número máximo de consultas por página antes de alertar.
 * Un WordPress normal no debería superar las 80-100.
 */
define( 'AYUDAWP_MAX_QUERIES_ALERT', 100 );

/**
 * Registra las consultas problemáticas al finalizar la carga.
 */
function ayudawp_log_slow_queries() {
    global $wpdb;

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

    $log_file    = WP_CONTENT_DIR . '/ayudawp-slow-queries.log';
    $total       = count( $wpdb->queries );
    $slow        = array();
    $total_time  = 0;
    $request_uri = isset( $_SERVER['REQUEST_URI'] )
        ? sanitize_text_field( wp_unslash( $_SERVER['REQUEST_URI'] ) )
        : 'unknown';

    foreach ( $wpdb->queries as $query_data ) {
        $sql      = $query_data[0];
        $time     = $query_data[1];
        $caller   = $query_data[2];
        $total_time += $time;

        if ( $time >= AYUDAWP_SLOW_QUERY_THRESHOLD ) {
            $slow[] = array(
                'sql'    => trim( $sql ),
                'time'   => round( $time, 4 ),
                'caller' => $caller,
            );
        }
    }

    // Si no hay consultas lentas y el total no supera el umbral, no registrar.
    if ( empty( $slow ) && $total < AYUDAWP_MAX_QUERIES_ALERT ) {
        return;
    }

    $log_entry  = "\n" . str_repeat( '=', 70 ) . "\n";
    $log_entry .= gmdate( 'Y-m-d H:i:s' ) . ' | URL: ' . $request_uri . "\n";
    $log_entry .= 'Total consultas: ' . $total
        . ' | Tiempo total DB: ' . round( $total_time, 4 ) . "s\n";

    if ( $total >= AYUDAWP_MAX_QUERIES_ALERT ) {
        $log_entry .= '** ALERTA: Numero excesivo de consultas (' . $total . ") **\n";
    }

    if ( ! empty( $slow ) ) {
        $log_entry .= 'Consultas lentas encontradas: ' . count( $slow ) . "\n";
        $log_entry .= str_repeat( '-', 70 ) . "\n";

        foreach ( $slow as $index => $q ) {
            $log_entry .= '[' . ( $index + 1 ) . '] Tiempo: '
                . $q['time'] . "s\n";
            $log_entry .= 'SQL: ' . $q['sql'] . "\n";
            $log_entry .= 'Llamada: ' . $q['caller'] . "\n\n";
        }
    }

    // phpcs:ignore WordPress.WP.AlternativeFunctions.file_system_operations_file_put_contents
    file_put_contents( $log_file, $log_entry, FILE_APPEND | LOCK_EX );
}
add_action( 'shutdown', 'ayudawp_log_slow_queries' );

El registro se guardará en /wp-content/ayudawp-slow-queries.log. Navega por tu web durante un rato, especialmente por las páginas que van lentas, y luego descarga el archivo para analizarlo.

Cada entrada del log te dice la URL que se estaba cargando, el número total de consultas, el tiempo total invertido en la base de datos, y el detalle de cada consulta lenta con la función exacta que la ha disparado. Con eso tienes suficiente para saber dónde buscar.

Dato muy importante: esto es para diagnóstico temporal. SAVEQUERIES hace que WordPress almacene en memoria un registro de todas las consultas, lo que consume recursos adicionales. Cuando termines de diagnosticar, elimina el mu-plugin y quita la línea de SAVEQUERIES del wp-config.php. No lo dejes activado en producción.

Con phpMyAdmin: ver qué pasa en tiempo real

Si tienes acceso a phpMyAdmin a través del panel de tu hosting (cPanel, Plesk, Site Tools o similar), puedes ver directamente qué está haciendo la base de datos en cada momento.

SHOW PROCESSLIST — Ver consultas en tiempo real:

Ve a la pestaña SQL de tu base de datos y ejecuta:

SHOW FULL PROCESSLIST;

Esto te muestra todas las consultas que se están ejecutando en ese instante. Las columnas importantes son:

• Time: cuántos segundos lleva ejecutándose esa consulta. Si ves valores altos (más de 2 o 3 segundos) tienes un problema.
• State: en qué fase está la consulta. Valores como Sending data, Sorting result o Creating tmp table durante mucho tiempo indican problemas.
• Info: la consulta SQL completa. Aquí ves exactamente qué se está ejecutando.

El truco es ejecutar SHOW FULL PROCESSLIST varias veces seguidas mientras la web está lenta. Si ves la misma consulta apareciendo una y otra vez, o una consulta que lleva muchos segundos ejecutándose, ya tienes al culpable.

SHOW TABLE STATUS — Estado y tamaño de las tablas:

SHOW TABLE STATUS;

Esto te da una visión general de todas las tablas: cuántas filas tienen, cuánto espacio ocupan los datos, cuánto ocupan los índices y si hay fragmentación. Fíjate especialmente en:

• Tablas con un número de filas desproporcionado (wp_postmeta y wp_options suelen ser las que más crecen).
• La columna Data_free, que indica espacio desperdiciado por fragmentación.
• El Engine: si ves alguna tabla con MyISAM en vez de InnoDB, eso puede ser parte del problema (lo vemos más adelante).

Con SSH y WP-CLI: diagnóstico avanzado

Si tienes acceso por SSH a tu servidor, tienes las herramientas más potentes a tu disposición.

WP-CLI Profile — Perfilar tiempos de carga:

Primero instala el paquete de perfilado:

wp package install wp-cli/profile-command

Luego, desde la carpeta de tu instalación de WordPress, ejecuta:

wp profile stage --fields=stage,time,cache_ratio,query_time,query_count --spotlight

Esto te muestra cuánto tiempo se invierte en cada etapa de la carga de WordPress (bootstrap, carga de plugins, tema, consulta principal, plantilla), cuántas consultas hace cada una y cuánto tiempo se gasta en la base de datos. Si ves que bootstrap tarda mucho y tiene muchas consultas, el problema está en los plugins o en la configuración.

Para profundizar en los plugins concretos:

wp profile hook plugins_loaded --fields=callback,time,location --spotlight

Y para ver todos los hooks y su impacto:

wp profile hook --fields=hook,time,cache_ratio,query_count --spotlight

El parámetro --spotlight oculta los valores a cero para que solo veas lo relevante.

WP-CLI Doctor — Diagnóstico rápido:

Instala el paquete:

wp package install wp-cli/doctor-command

Y ejecuta todas las comprobaciones:

wp doctor check --all

Esto te avisa automáticamente de problemas como opciones con autoload que superan los 900 KB, si SAVEQUERIES está activado en producción (no debería), si el cron tiene tareas duplicadas o excesivas, y otras cosas que afectan al rendimiento de la base de datos.

Slow query log de MySQL — El registro definitivo:

El slow_query_log es un registro que genera el propio servidor MySQL/MariaDB con todas las consultas que superan un tiempo determinado. Es lo más fiable que existe porque registra absolutamente todo lo que pasa en la base de datos, no solo lo que WordPress te deja ver.

Si administras tu propio servidor, actívalo añadiendo esto a la configuración de MySQL (my.cnf o my.ini):

[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql-slow.log
long_query_time = 1
log_queries_not_using_indexes = 1

El parámetro long_query_time define el umbral en segundos. Un valor de 1 es razonable para empezar, luego puedes bajarlo a 0.5 si quieres más detalle. La opción log_queries_not_using_indexes es muy útil porque registra también las consultas que no utilizan ningún índice, aunque sean rápidas, ya que cuando la tabla crezca se convertirán en un problema.

Si estás en un hosting compartido, no podrás editar la configuración de MySQL directamente. Pero muchos hostings pueden activar el slow_query_log si se lo pides. Manda un ticket de soporte con algo así:

"Estoy diagnosticando problemas de rendimiento en mi base de datos. ¿Podéis activar el slow query log con un umbral de 1 segundo y facilitarme los resultados? También me sería útil que activaseis log_queries_not_using_indexes."

Algunos hosting como SiteGround, Raiola o Webempresa suelen colaborar con este tipo de peticiones sin problema.

Interpretar lo que encuentras: EXPLAIN

Ya tienes identificada la consulta sospechosa, ahora necesitas entender por qué es lenta o por qué consume tantos recursos. Para eso existe EXPLAIN, un comando de MySQL que te dice exactamente cómo se ejecuta una consulta internamente.

Simplemente pon EXPLAIN delante de cualquier consulta SELECT y ejecútala en phpMyAdmin o en la consola de MySQL.

Por ejemplo:

EXPLAIN SELECT * FROM wp_postmeta WHERE meta_key = '_price';

El resultado es una tabla con varias columnas.

Las que te interesan para diagnosticar problemas son:

type — Cómo accede MySQL a la tabla. De mejor a peor:

• system / const: perfecto, accede a un solo registro por clave primaria.
• eq_ref / ref: bien, usa un índice para encontrar las filas.
• range: aceptable, escanea un rango de filas usando un índice.
• index: regular, escanea todo el índice (mejor que escanear toda la tabla, pero no ideal).
• ALL: malo. Escaneo completo de tabla. Si ves esto en una tabla con miles de filas, ahí está tu problema.

key — Qué índice usa MySQL para la consulta. Si ves NULL significa que no usa ningún índice, lo que suele ser sinónimo de consulta lenta en tablas grandes.

rows — Cuántas filas estima MySQL que necesita examinar. Si este número es enorme comparado con las filas que realmente necesitas, la consulta está haciendo mucho más trabajo del necesario.

Extra — Información adicional sobre cómo se ejecuta. Valores que indican problemas:

• Using filesort: MySQL tiene que ordenar los resultados sin poder usar un índice. Lento en tablas grandes.
• Using temporary: MySQL crea una tabla temporal para procesar la consulta. Consume memoria y disco.
• Using where: filtra filas después de leerlas, lo que no es malo por sí solo pero combinado con type: ALL significa que lee toda la tabla y luego descarta lo que no necesita.

Para un diagnóstico aún más detallado, puedes usar el formato JSON:

EXPLAIN FORMAT=JSON SELECT * FROM wp_postmeta WHERE meta_key = '_price';

El formato JSON te da información adicional como el coste estimado de la consulta, que es útil para comparar antes y después de aplicar una optimización.

Si usas MySQL Workbench (puedes conectarte remotamente si tu hosting lo permite o activando la opción de MySQL remoto en cPanel), la vista gráfica de EXPLAIN te marca en rojo los pasos lentos, en naranja los que se pueden mejorar y en verde los que están bien. Muy visual y práctico para entender de un vistazo dónde está el cuello de botella.

Los culpables habituales

Con las herramientas anteriores vas a encontrar las consultas problemáticas. Pero para que sepas qué estás buscando, estos son los patrones que se repiten una y otra vez en instalaciones de WordPress con problemas de rendimiento en la base de datos.

Consultas lentas

wp_options con autoload descontrolado:

Cada vez que se carga una página, WordPress ejecuta una consulta que trae de golpe todas las opciones de la tabla wp_options que tienen el campo autoload con valor yes. En una instalación recién hecha esto no es problema, pero con el tiempo y con plugins que van añadiendo opciones con autoload activado, esa consulta inicial puede tener que cargar varios megabytes de datos en cada petición.

Lo peor es que muchas de esas opciones con autoload ni siquiera se necesitan en cada página. Son configuraciones de plugins que solo se usan en contextos específicos, pero que se cargan siempre por defecto.

Si quieres profundizar en este tema concreto, tengo un artículo detallado sobre cómo identificar y optimizar las tablas lentas de la base de datos con índices.

meta_query sobre wp_postmeta sin índices:

Este es el clásico de WooCommerce con catálogos grandes, pero también afecta a cualquier web que use campos personalizados (custom fields) de forma intensiva. La tabla wp_postmeta no tiene un índice compuesto sobre meta_key y meta_value, así que cuando haces una meta_query buscando productos por precio, por atributo o por cualquier campo personalizado, MySQL tiene que recorrer una tabla que puede tener cientos de miles o millones de filas.

Haz EXPLAIN de una consulta típica de filtrado por meta y verás type: ALL o type: ref con un número de filas absurdo.

Búsqueda interna con LIKE sobre tablas grandes:

La búsqueda nativa de WordPress usa LIKE '%término%' para buscar en títulos y contenido. El problema del comodín al principio (%) es que impide usar cualquier índice, así que MySQL se ve obligado a leer cada fila de wp_posts para buscar coincidencias. En una web con miles de entradas, esto es muy lento.

Consultas con múltiples JOIN pesados:

Cuando un plugin o un tema necesita combinar datos de varias tablas (posts + postmeta + terms + termmeta), el número de filas que MySQL tiene que procesar se multiplica. Si además alguna de esas tablas no tiene los índices adecuados, el resultado es una consulta que tarda segundos en ejecutarse.

Consultas agresivas (alto consumo de recursos)

Precarga o precalentamiento de caché que lanza consultas masivas:

Algunos plugins de caché tienen opciones para precalentar la caché generando todas las páginas de golpe. Lo que hacen internamente es lanzar una consulta para obtener todas las URLs del sitio y luego empezar a visitarlas una detrás de otra (o incluso varias a la vez). Cada visita genera su propio conjunto de consultas a la base de datos, y si se ejecutan muchas a la vez, la base de datos se satura.

También pasa con plugins de sitemap que generan el mapa del sitio consultando toda la base de datos de golpe en vez de ir por partes.

Plugins que hacen SELECT * sin LIMIT:

Hay plugins que necesitan procesar datos en lote (exportaciones, generación de informes, envío masivo de correos) y que no implementan paginación. Hacen un SELECT * sobre la tabla completa, cargan todo en la memoria PHP y luego lo procesan. Si la tabla tiene 100.000 filas, meten 100.000 filas en la RAM de golpe.

Importaciones y exportaciones sin procesamiento por lotes:

Importar miles de productos en WooCommerce o miles de entradas con un plugin que no procesa por lotes puede colapsar la base de datos. Cada inserción o actualización dispara sus propias consultas, y si no se hacen por lotes, el servidor no da abasto.

Consultas excesivas o frecuentes

Consultas N+1 en bucle:

Este es uno de los problemas más comunes y más difíciles de detectar si no sabes qué buscar. Ocurre cuando un tema o plugin ejecuta una consulta por cada elemento de un listado, en vez de traer todos los datos de una sola vez.

El ejemplo típico: un tema que muestra 20 entradas en una página de archivo y, dentro del bucle, hace get_post_meta() para cada entrada individualmente. Resultado: 1 consulta para traer las 20 entradas + 20 consultas adicionales para los meta de cada una. Si además pide datos de taxonomías, autor y miniatura, fácilmente llegas a 100+ consultas solo para un listado.

WordPress tiene mecanismos para precargar los meta y las taxonomías de golpe (update_post_meta_cache y update_post_term_cache), pero muchos temas y plugins los desactivan o no los aprovechan.

Heartbeat API haciendo polling continuo:

La Heartbeat API de WordPress envía una petición AJAX al servidor cada 15-60 segundos (dependiendo del contexto) para comprobar cosas como el autoguardado, las notificaciones y si alguien más está editando el mismo contenido. Cada una de esas peticiones ejecuta varias consultas a la base de datos.

Si tienes varios usuarios trabajando en el admin a la vez, cada uno está generando estas peticiones periódicas, y el efecto acumulado puede ser considerable. En un WordPress con 10 usuarios conectados al admin simultáneamente, el Heartbeat puede estar generando cientos de consultas por minuto sin que nadie sea consciente.

Consultas duplicadas:

Es más común de lo que parece. Un tema carga ciertas opciones con get_option(), y un plugin pide exactamente las mismas opciones por su cuenta. O dos plugins distintos ejecutan la misma consulta para obtener la misma información. WordPress tiene su propia caché de objetos en memoria para una sola petición, pero no siempre funciona si los plugins hacen consultas directas con $wpdb en vez de usar las funciones estándar de WordPress.

WP-Cron con tareas acumuladas:

WordPress simula un cron mediante una comprobación en cada carga de página. Si hay plugins mal diseñados que programan tareas y nunca las limpian, o que programan la misma tarea varias veces, puedes acabar con cientos de tareas programadas que se ejecutan todas de golpe cuando les toca, saturando la base de datos en ese momento.

Esto es especialmente problemático en webs con poco tráfico, porque las tareas se acumulan y cuando finalmente llega una visita, se disparan todas a la vez.

Tabla resumen

Consultas de diagnóstico

Antes de pasar a las soluciones, necesitas datos concretos de tu instalación. Para cada consulta de diagnóstico te doy tres formas de ejecutarla:

• Directamente como SQL (en phpMyAdmin o cualquier cliente de base de datos).
• Como código PHP (un mu-plugin temporal que puedes subir si no tienes otro acceso).
• Por WP-CLI si tienes SSH. Usa la que te venga mejor según tu situación.

Tamaño total de datos con autoload

SQL:

SELECT SUM(LENGTH(option_value)) AS autoload_size_bytes,
ROUND(SUM(LENGTH(option_value)) / 1024 / 1024, 2) AS autoload_size_mb
FROM wp_options
WHERE autoload = 'yes';

PHP (mu-plugin temporal en /wp-content/mu-plugins/ayudawp-diagnostico.php):

<?php
/**
 * AyudaWP - Diagnóstico: tamaño de autoload.
 * Muestra el resultado como aviso en el admin.
 * Eliminar después de usar.
 */
if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

function ayudawp_diag_autoload_size() {
    if ( ! current_user_can( 'manage_options' ) ) {
        return;
    }
    global $wpdb;
    $result = $wpdb->get_row(
        "SELECT SUM(LENGTH(option_value)) AS total_bytes
        FROM {$wpdb->options}
        WHERE autoload = 'yes'"
    );
    $mb = round( $result->total_bytes / 1024 / 1024, 2 );
    $class = $result->total_bytes > 1000000 ? 'notice-error' : 'notice-info';
    echo '<div class="notice ' . esc_attr( $class ) . '"><p>';
    echo 'AyudaWP Diagnostico: Autoload total = '
        . esc_html( number_format( $result->total_bytes, 0, ',', '.' ) )
        . ' bytes (' . esc_html( $mb ) . ' MB).';
    if ( $result->total_bytes > 1000000 ) {
        echo ' <strong>Supera 1 MB, conviene revisarlo.</strong>';
    }
    echo '</p></div>';
}
add_action( 'admin_notices', 'ayudawp_diag_autoload_size' );

WP-CLI:

wp db query "SELECT SUM(LENGTH(option_value)) AS autoload_bytes, ROUND(SUM(LENGTH(option_value)) / 1024 / 1024, 2) AS autoload_mb FROM $(wp db prefix)options WHERE autoload = 'yes';"

Las 30 opciones con autoload más pesadas

SQL:

SELECT option_name,
LENGTH(option_value) AS size_bytes,
ROUND(LENGTH(option_value) / 1024, 2) AS size_kb
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size_bytes DESC
LIMIT 30;

PHP (añadir al mismo mu-plugin de diagnóstico):

function ayudawp_diag_top_autoload() {
    if ( ! current_user_can( 'manage_options' ) ) {
        return;
    }
    global $wpdb;
    $results = $wpdb->get_results(
        "SELECT option_name, LENGTH(option_value) AS size_bytes
        FROM {$wpdb->options}
        WHERE autoload = 'yes'
        ORDER BY size_bytes DESC
        LIMIT 30"
    );
    echo '<div class="notice notice-info"><p><strong>AyudaWP - Top 30 autoload:</strong></p><ol>';
    foreach ( $results as $row ) {
        $kb = round( $row->size_bytes / 1024, 2 );
        echo '<li>' . esc_html( $row->option_name )
            . ' - ' . esc_html( $kb ) . ' KB</li>';
    }
    echo '</ol></div>';
}
add_action( 'admin_notices', 'ayudawp_diag_top_autoload' );

WP-CLI:

wp db query "SELECT option_name, LENGTH(option_value) AS size_bytes, ROUND(LENGTH(option_value) / 1024, 2) AS size_kb FROM $(wp db prefix)options WHERE autoload = 'yes' ORDER BY size_bytes DESC LIMIT 30;"

Tablas con más filas y mayor tamaño

SQL:

SELECT TABLE_NAME,
TABLE_ROWS,
ROUND(DATA_LENGTH / 1024 / 1024, 2) AS data_mb,
ROUND(INDEX_LENGTH / 1024 / 1024, 2) AS index_mb,
ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024, 2) AS total_mb,
ROUND(DATA_FREE / 1024 / 1024, 2) AS fragmented_mb,
ENGINE
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'nombre_de_tu_base_de_datos'
ORDER BY (DATA_LENGTH + INDEX_LENGTH) DESC;

PHP:

function ayudawp_diag_table_sizes() {
    if ( ! current_user_can( 'manage_options' ) ) {
        return;
    }
    global $wpdb;
    $db_name = DB_NAME;
    $results = $wpdb->get_results(
        $wpdb->prepare(
            "SELECT TABLE_NAME, TABLE_ROWS,
            ROUND(DATA_LENGTH / 1024 / 1024, 2) AS data_mb,
            ROUND(INDEX_LENGTH / 1024 / 1024, 2) AS index_mb,
            ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024, 2) AS total_mb,
            ENGINE
            FROM information_schema.TABLES
            WHERE TABLE_SCHEMA = %s
            ORDER BY (DATA_LENGTH + INDEX_LENGTH) DESC",
            $db_name
        )
    );
    echo '<div class="notice notice-info">';
    echo '<p><strong>AyudaWP - Tablas por tamaño:</strong></p>';
    echo '<table style="border-collapse:collapse;width:100%">';
    echo '<tr><th style="text-align:left;padding:4px;border-bottom:1px solid #ccc">Tabla</th>';
    echo '<th style="text-align:right;padding:4px;border-bottom:1px solid #ccc">Filas</th>';
    echo '<th style="text-align:right;padding:4px;border-bottom:1px solid #ccc">Total MB</th>';
    echo '<th style="text-align:left;padding:4px;border-bottom:1px solid #ccc">Motor</th></tr>';
    foreach ( $results as $row ) {
        echo '<tr><td style="padding:4px">' . esc_html( $row->TABLE_NAME ) . '</td>';
        echo '<td style="text-align:right;padding:4px">' . esc_html( number_format( $row->TABLE_ROWS, 0, ',', '.' ) ) . '</td>';
        echo '<td style="text-align:right;padding:4px">' . esc_html( $row->total_mb ) . '</td>';
        echo '<td style="padding:4px">' . esc_html( $row->ENGINE ) . '</td></tr>';
    }
    echo '</table></div>';
}
add_action( 'admin_notices', 'ayudawp_diag_table_sizes' );

WP-CLI:

wp db query "SELECT TABLE_NAME, TABLE_ROWS, ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024, 2) AS total_mb, ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = DATABASE() ORDER BY (DATA_LENGTH + INDEX_LENGTH) DESC;" --table

postmeta huérfano (sin ninguna entrada asociada)

SQL:

SELECT COUNT(*) AS orphaned_postmeta
FROM wp_postmeta
WHERE post_id NOT IN (SELECT ID FROM wp_posts);

PHP:

function ayudawp_diag_orphaned_postmeta() {
    if ( ! current_user_can( 'manage_options' ) ) {
        return;
    }
    global $wpdb;
    $count = $wpdb->get_var(
        "SELECT COUNT(*) FROM {$wpdb->postmeta}
        WHERE post_id NOT IN (SELECT ID FROM {$wpdb->posts})"
    );
    $class = $count > 1000 ? 'notice-warning' : 'notice-info';
    echo '<div class="notice ' . esc_attr( $class ) . '"><p>';
    echo 'AyudaWP: Postmeta huerfano = '
        . esc_html( number_format( $count, 0, ',', '.' ) ) . ' registros.';
    if ( $count > 1000 ) {
        echo ' <strong>Conviene limpiarlo.</strong>';
    }
    echo '</p></div>';
}
add_action( 'admin_notices', 'ayudawp_diag_orphaned_postmeta' );

WP-CLI:

wp db query "SELECT COUNT(*) AS orphaned FROM $(wp db prefix)postmeta WHERE post_id NOT IN (SELECT ID FROM $(wp db prefix)posts);"

commentmeta huérfano (sin ningún comentario asociado)

SQL:

SELECT COUNT(*) AS orphaned_commentmeta
FROM wp_commentmeta
WHERE comment_id NOT IN (SELECT comment_ID FROM wp_comments);

PHP:

function ayudawp_diag_orphaned_commentmeta() {
    if ( ! current_user_can( 'manage_options' ) ) {
        return;
    }
    global $wpdb;
    $count = $wpdb->get_var(
        "SELECT COUNT(*) FROM {$wpdb->commentmeta}
        WHERE comment_id NOT IN (SELECT comment_ID FROM {$wpdb->comments})"
    );
    echo '<div class="notice notice-info"><p>';
    echo 'AyudaWP: Commentmeta huerfano = '
        . esc_html( number_format( $count, 0, ',', '.' ) ) . ' registros.';
    echo '</p></div>';
}
add_action( 'admin_notices', 'ayudawp_diag_orphaned_commentmeta' );

WP-CLI:

wp db query "SELECT COUNT(*) AS orphaned FROM $(wp db prefix)commentmeta WHERE comment_id NOT IN (SELECT comment_ID FROM $(wp db prefix)comments);"

Transients caducados pendientes de limpiar

SQL:

SELECT COUNT(*) AS expired_transients
FROM wp_options
WHERE option_name LIKE '%_transient_timeout_%'
AND option_value < UNIX_TIMESTAMP();

PHP:

function ayudawp_diag_expired_transients() {
    if ( ! current_user_can( 'manage_options' ) ) {
        return;
    }
    global $wpdb;
    $count = $wpdb->get_var(
        "SELECT COUNT(*) FROM {$wpdb->options}
        WHERE option_name LIKE '%_transient_timeout_%'
        AND option_value < UNIX_TIMESTAMP()"
    );
    echo '<div class="notice notice-info"><p>';
    echo 'AyudaWP: Transients caducados = '
        . esc_html( number_format( $count, 0, ',', '.' ) ) . '.';
    echo '</p></div>';
}
add_action( 'admin_notices', 'ayudawp_diag_expired_transients' );

WP-CLI:

wp transient delete --expired

En WP-CLI el comando directamente los borra. Si solo quieres ver cuántos hay sin eliminarlos, usa la consulta SQL con wp db query.

Las 20 entradas con más revisiones

SQL:

SELECT p.post_title,
p.ID AS post_id,
COUNT(r.ID) AS revision_count
FROM wp_posts p
INNER JOIN wp_posts r ON r.post_parent = p.ID AND r.post_type = 'revision'
WHERE p.post_type NOT IN ('revision', 'auto-draft')
GROUP BY p.ID
ORDER BY revision_count DESC
LIMIT 20;

PHP:

function ayudawp_diag_top_revisions() {
    if ( ! current_user_can( 'manage_options' ) ) {
        return;
    }
    global $wpdb;
    $results = $wpdb->get_results(
        "SELECT p.post_title, p.ID, COUNT(r.ID) AS rev_count
        FROM {$wpdb->posts} p
        INNER JOIN {$wpdb->posts} r ON r.post_parent = p.ID AND r.post_type = 'revision'
        WHERE p.post_type NOT IN ('revision', 'auto-draft')
        GROUP BY p.ID
        ORDER BY rev_count DESC
        LIMIT 20"
    );
    echo '<div class="notice notice-info">';
    echo '<p><strong>AyudaWP - Top 20 entradas con mas revisiones:</strong></p><ol>';
    foreach ( $results as $row ) {
        echo '<li>' . esc_html( $row->post_title )
            . ' (ID ' . intval( $row->ID ) . ') - '
            . intval( $row->rev_count ) . ' revisiones</li>';
    }
    echo '</ol></div>';
}
add_action( 'admin_notices', 'ayudawp_diag_top_revisions' );

WP-CLI:

wp db query "SELECT p.post_title, p.ID, COUNT(r.ID) AS rev_count FROM $(wp db prefix)posts p INNER JOIN $(wp db prefix)posts r ON r.post_parent = p.ID AND r.post_type = 'revision' WHERE p.post_type NOT IN ('revision', 'auto-draft') GROUP BY p.ID ORDER BY rev_count DESC LIMIT 20;"

Tablas que no son del core de WordPress

Útil para detectar tablas huérfanas de plugins que ya no tienes instalados.

SQL:

SELECT TABLE_NAME,
TABLE_ROWS,
ROUND(((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024), 2) AS size_mb
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'nombre_de_tu_base_de_datos'
AND TABLE_NAME NOT IN (
    'wp_commentmeta', 'wp_comments', 'wp_links',
    'wp_options', 'wp_postmeta', 'wp_posts',
    'wp_termmeta', 'wp_terms', 'wp_term_relationships',
    'wp_term_taxonomy', 'wp_usermeta', 'wp_users'
)
ORDER BY (DATA_LENGTH + INDEX_LENGTH) DESC;

PHP:

function ayudawp_diag_non_core_tables() {
    if ( ! current_user_can( 'manage_options' ) ) {
        return;
    }
    global $wpdb;
    $prefix = $wpdb->prefix;
    $core   = array(
        $prefix . 'commentmeta', $prefix . 'comments', $prefix . 'links',
        $prefix . 'options', $prefix . 'postmeta', $prefix . 'posts',
        $prefix . 'termmeta', $prefix . 'terms', $prefix . 'term_relationships',
        $prefix . 'term_taxonomy', $prefix . 'usermeta', $prefix . 'users',
    );
    $placeholders = implode( ',', array_fill( 0, count( $core ), '%s' ) );
    $results = $wpdb->get_results(
        $wpdb->prepare(
            "SELECT TABLE_NAME, TABLE_ROWS,
            ROUND(((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024), 2) AS size_mb
            FROM information_schema.TABLES
            WHERE TABLE_SCHEMA = %s
            AND TABLE_NAME NOT IN ($placeholders)
            ORDER BY (DATA_LENGTH + INDEX_LENGTH) DESC",
            array_merge( array( DB_NAME ), $core )
        )
    );
    if ( empty( $results ) ) {
        echo '<div class="notice notice-success"><p>AyudaWP: No hay tablas fuera del core.</p></div>';
        return;
    }
    echo '<div class="notice notice-warning">';
    echo '<p><strong>AyudaWP - Tablas fuera del core de WordPress:</strong></p><ol>';
    foreach ( $results as $row ) {
        echo '<li>' . esc_html( $row->TABLE_NAME )
            . ' - ' . esc_html( number_format( $row->TABLE_ROWS, 0, ',', '.' ) )
            . ' filas - ' . esc_html( $row->size_mb ) . ' MB</li>';
    }
    echo '</ol></div>';
}
add_action( 'admin_notices', 'ayudawp_diag_non_core_tables' );

WP-CLI:

wp db query "SELECT TABLE_NAME, TABLE_ROWS, ROUND(((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024), 2) AS size_mb FROM information_schema.TABLES WHERE TABLE_SCHEMA = DATABASE() AND TABLE_NAME NOT LIKE '$(wp db prefix)comment%' ORDER BY (DATA_LENGTH + INDEX_LENGTH) DESC;" --table

Nota: En WP-CLI este es un caso donde la consulta SQL completa con todas las exclusiones es más precisa. El comando de arriba es una aproximación rápida; para el listado exacto de tablas core, usa la consulta SQL completa con wp db query.

Índices existentes en una tabla

Antes de crear un índice, comprueba si ya existe.

SQL:

SHOW INDEX FROM wp_postmeta;

PHP:

function ayudawp_diag_show_indexes() {
    if ( ! current_user_can( 'manage_options' ) ) {
        return;
    }
    global $wpdb;
    // Cambia la tabla a revisar.
    $table   = $wpdb->postmeta;
    $results = $wpdb->get_results( "SHOW INDEX FROM {$table}" );
    echo '<div class="notice notice-info">';
    echo '<p><strong>AyudaWP - Indices de ' . esc_html( $table ) . ':</strong></p><ul>';
    foreach ( $results as $row ) {
        echo '<li>' . esc_html( $row->Key_name )
            . ' (' . esc_html( $row->Column_name ) . ')</li>';
    }
    echo '</ul></div>';
}
add_action( 'admin_notices', 'ayudawp_diag_show_indexes' );

WP-CLI:

wp db query "SHOW INDEX FROM $(wp db prefix)postmeta;"

Motor de almacenamiento de cada tabla (detectar MyISAM)

SQL:

SELECT TABLE_NAME, ENGINE
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'nombre_de_tu_base_de_datos'
ORDER BY TABLE_NAME;

PHP: esta información ya la muestra la consulta de tamaño de tablas que vimos antes, que incluye la columna ENGINE.

WP-CLI:

wp db query "SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = DATABASE() ORDER BY TABLE_NAME;"

Soluciones según el tipo de problema

Ahora que tienes diagnosticado qué pasa y los datos concretos de tu instalación, vamos con las soluciones. De nuevo, para cada una te doy las opciones según tu nivel de acceso.

Soluciones para consultas lentas

Crear índices donde faltan:

Los índices son la solución más directa para consultas lentas. Un índice permite a MySQL encontrar las filas que necesita sin tener que recorrer toda la tabla.

El caso más típico es el índice de autoload en wp_options:

SQL:

CREATE INDEX idx_autoload ON wp_options(autoload);

PHP:

function ayudawp_create_autoload_index() {
    global $wpdb;
    // Comprobar si el índice ya existe.
    $indexes = $wpdb->get_results( "SHOW INDEX FROM {$wpdb->options} WHERE Key_name = 'idx_autoload'" );
    if ( ! empty( $indexes ) ) {
        return; // Ya existe.
    }
    $wpdb->query( "CREATE INDEX idx_autoload ON {$wpdb->options}(autoload)" );
}
// Ejecutar una sola vez.
add_action( 'admin_init', 'ayudawp_create_autoload_index' );

WP-CLI:

wp db query "CREATE INDEX idx_autoload ON $(wp db prefix)options(autoload);"

Para wp_postmeta, si haces muchas búsquedas por meta_key y meta_value (típico de WooCommerce):

SQL:

CREATE INDEX idx_meta_key_value ON wp_postmeta(meta_key(191), meta_value(100));

PHP:

function ayudawp_create_postmeta_index() {
    global $wpdb;
    $indexes = $wpdb->get_results(
        "SHOW INDEX FROM {$wpdb->postmeta} WHERE Key_name = 'idx_meta_key_value'"
    );
    if ( ! empty( $indexes ) ) {
        return;
    }
    $wpdb->query(
        "CREATE INDEX idx_meta_key_value ON {$wpdb->postmeta}(meta_key(191), meta_value(100))"
    );
}
add_action( 'admin_init', 'ayudawp_create_postmeta_index' );

WP-CLI:

wp db query "CREATE INDEX idx_meta_key_value ON $(wp db prefix)postmeta(meta_key(191), meta_value(100));"

Cambia wp_options y wp_postmeta por el nombre real de tus tablas si usas un prefijo distinto a wp_. En las versiones PHP, al usar $wpdb->options y $wpdb->postmeta, WordPress ya aplica el prefijo correcto automáticamente.

• Precauciones con los índices: los índices aceleran las lecturas pero ralentizan ligeramente las escrituras (INSERT, UPDATE, DELETE) porque MySQL tiene que actualizar el índice cada vez. En la mayoría de los WordPress, las lecturas superan ampliamente a las escrituras, así que el beneficio compensa. Pero no te dediques a crear índices a lo loco sin antes confirmar con EXPLAIN que la consulta realmente los necesita y los va a usar.
• Limpia autoloads innecesarios: cuando hayas identificado las consultas de diagnóstico qué opciones ocupan más y no necesitan cargarse en cada petición cámbialas a no:

SQL:

UPDATE wp_options SET autoload = 'no' WHERE option_name = 'nombre_de_la_opcion';

PHP:

// Cambiar autoload de una opción concreta.
// Sustituye 'nombre_de_la_opcion' por la que quieras cambiar.
function ayudawp_fix_autoload() {
    global $wpdb;
    $wpdb->update(
        $wpdb->options,
        array( 'autoload' => 'no' ),
        array( 'option_name' => 'nombre_de_la_opcion' ),
        array( '%s' ),
        array( '%s' )
    );
}
add_action( 'admin_init', 'ayudawp_fix_autoload' );

WP-CLI:

wp db query "UPDATE $(wp db prefix)options SET autoload = 'no' WHERE option_name = 'nombre_de_la_opcion';"

Cuidado: no cambies el autoload de opciones del núcleo de WordPress ni de opciones que no sepas para qué sirven. Investiga antes qué hace cada opción. Las más seguras de cambiar suelen ser las de plugins de estadísticas, logs, caché de datos temporales y configuraciones de plugins que solo se usan en el admin.

Sustituir la búsqueda interna:

Si la búsqueda nativa de WordPress está generando consultas lentas con LIKE, la solución más efectiva es usar un plugin de búsqueda que utilice su propio sistema de indexación, como SearchWP o Relevanssi. Estos plugins crean sus propios índices optimizados para búsqueda, evitando las consultas LIKE sobre wp_posts. En este caso no hay alternativa SQL o PHP directa, ya que el problema es estructural: la búsqueda nativa de WordPress funciona así por diseño y no se puede resolver con un simple cambio en la base de datos.

Soluciones para consultas agresivas

Controlar la precarga de caché:

Si usas un plugin de caché con opción de precalentamiento, revisa su configuración. Busca opciones para limitar cuántas páginas precarga a la vez (concurrencia) y para añadir una pausa entre peticiones. Si no ofrece estas opciones, valora si realmente necesitas el precalentamiento o si es mejor dejar que la caché se genere bajo demanda conforme los visitantes van entrando. Esto es cuestión de configuración del plugin, no hay consulta SQL ni snippet PHP que lo resuelva.

Limitar resultados en consultas personalizadas:

Si desarrollas o mantienes código personalizado en tu web, asegúrate de que todas las consultas a tablas grandes incluyan LIMIT. Nunca hagas SELECT * FROM tabla_enorme sin limitar los resultados. Si necesitas procesar muchos registros, hazlo por lotes:

// Mal: traer todo de golpe.
$results = $wpdb->get_results( "SELECT * FROM {$wpdb->postmeta}" );

// Bien: procesar por lotes de 500.
$offset = 0;
$batch  = 500;
do {
    $results = $wpdb->get_results(
        $wpdb->prepare(
            "SELECT * FROM {$wpdb->postmeta} LIMIT %d OFFSET %d",
            $batch,
            $offset
        )
    );
    // Procesar $results aquí.
    $offset += $batch;
} while ( ! empty( $results ) );

Soluciones para consultas excesivas o frecuentes

Usar transients para consultas costosas que se repiten:

Si tienes una consulta que se ejecuta en cada carga de página y los datos no cambian constantemente (por ejemplo, un listado de los productos más vendidos, los artículos más populares o un menú generado dinámicamente), almacena el resultado con la API de transients de WordPress:

function ayudawp_get_popular_posts() {
    // Intentar obtener el resultado cacheado.
    $cached = get_transient( 'ayudawp_popular_posts' );

    if ( false !== $cached ) {
        return $cached;
    }

    // Si no hay cache, ejecutar la consulta.
    $posts = new WP_Query( array(
        'posts_per_page'         => 10,
        'orderby'                => 'comment_count',
        'order'                  => 'DESC',
        'no_found_rows'          => true,
        'update_post_meta_cache' => false,
        'update_post_term_cache' => false,
    ) );

    // Guardar en cache durante 12 horas.
    set_transient( 'ayudawp_popular_posts', $posts->posts, 12 * HOUR_IN_SECONDS );

    return $posts->posts;
}

La próxima vez que se cargue la página, en vez de ejecutar la consulta pesada, WordPress simplemente lee el resultado desde wp_options, que es una lectura mucho más rápida. El transient se renueva automáticamente cuando caduca.

Optimizar WP_Query para evitar consultas innecesarias:

Cada vez que haces una WP_Query, WordPress ejecuta internamente varias consultas adicionales (paginación, caché de meta, caché de taxonomías). Si no las necesitas, desactívalas:

$query = new WP_Query( array(
    'posts_per_page'         => 10,
    'post_type'              => 'post',
    // No calcular el total para paginación si no la necesitas.
    'no_found_rows'          => true,
    // No precargar meta si no los vas a usar.
    'update_post_meta_cache' => false,
    // No precargar taxonomías si no las vas a usar.
    'update_post_term_cache' => false,
    // Traer solo los campos que necesites.
    'fields'                 => 'ids',
) );

Cada uno de estos parámetros te ahorra una o más consultas. En un listado donde solo necesitas los IDs para luego procesarlos tú, puedes pasar de 5 consultas por WP_Query a solo 1.

Controlar la Heartbeat API:

Puedes reducir la frecuencia del Heartbeat o desactivarlo donde no lo necesites añadiendo un mu-plugin:

<?php
/**
 * AyudaWP - Controlar la frecuencia del Heartbeat API.
 *
 * Reduce la frecuencia en el admin y lo desactiva
 * en el front-end donde no es necesario.
 */

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

/**
 * Ajustar la frecuencia del Heartbeat.
 *
 * @param array $settings Configuración del Heartbeat.
 * @return array
 */
function ayudawp_heartbeat_settings( $settings ) {
    // Aumentar el intervalo a 60 segundos (por defecto son 15-30).
    $settings['interval'] = 60;
    return $settings;
}
add_filter( 'heartbeat_settings', 'ayudawp_heartbeat_settings' );

/**
 * Desactivar Heartbeat en el front-end.
 */
function ayudawp_disable_heartbeat_frontend() {
    if ( ! is_admin() ) {
        wp_deregister_script( 'heartbeat' );
    }
}
add_action( 'init', 'ayudawp_disable_heartbeat_frontend', 1 );

Esto es solo PHP/mu-plugin. No hay equivalente SQL porque el Heartbeat es un proceso de WordPress, no de la base de datos. En WP-CLI no tiene sentido porque el Heartbeat solo funciona cuando hay usuarios conectados al navegador.

Limpiar tareas de WP-Cron duplicadas o huérfanas:

WP-CLI (el método más directo):

# Ver todas las tareas programadas.
wp cron event list

# Borrar tareas de un hook concreto.
wp cron event delete nombre_del_hook

Plugin: si no tienes SSH, instala temporalmente WP Crontrol para ver y gestionar las tareas desde el admin. Busca tareas duplicadas (la misma tarea programada varias veces a la misma hora) y elimina las sobrantes.

SQL: Las tareas de cron se guardan en la opción cron de wp_options como un array serializado. No se recomienda editarlas directamente con SQL porque corromper un array serializado dejaría el cron roto. Usa WP-CLI o WP Crontrol para este caso.

Otras optimizaciones que ayudan SIEMPRE

Limpiar postmeta huérfano:

SQL:

DELETE FROM wp_postmeta
WHERE post_id NOT IN (SELECT ID FROM wp_posts);

PHP:

function ayudawp_clean_orphaned_postmeta() {
    global $wpdb;
    $deleted = $wpdb->query(
        "DELETE FROM {$wpdb->postmeta}
        WHERE post_id NOT IN (SELECT ID FROM {$wpdb->posts})"
    );
    return $deleted;
}
// Llamar manualmente o desde un hook puntual.

WP-CLI:

wp db query "DELETE FROM $(wp db prefix)postmeta WHERE post_id NOT IN (SELECT ID FROM $(wp db prefix)posts);"

Lo mismo para commentmeta y term_relationships huérfanas:

SQL:

DELETE FROM wp_commentmeta
WHERE comment_id NOT IN (SELECT comment_ID FROM wp_comments);

DELETE FROM wp_term_relationships
WHERE object_id NOT IN (SELECT ID FROM wp_posts);

PHP:

function ayudawp_clean_orphaned_commentmeta() {
    global $wpdb;
    $wpdb->query(
        "DELETE FROM {$wpdb->commentmeta}
        WHERE comment_id NOT IN (SELECT comment_ID FROM {$wpdb->comments})"
    );
}

function ayudawp_clean_orphaned_term_relationships() {
    global $wpdb;
    $wpdb->query(
        "DELETE FROM {$wpdb->term_relationships}
        WHERE object_id NOT IN (SELECT ID FROM {$wpdb->posts})"
    );
}

WP-CLI:

wp db query "DELETE FROM $(wp db prefix)commentmeta WHERE comment_id NOT IN (SELECT comment_ID FROM $(wp db prefix)comments);"
wp db query "DELETE FROM $(wp db prefix)term_relationships WHERE object_id NOT IN (SELECT ID FROM $(wp db prefix)posts);"

Limitar revisiones:

Añade esto a tu wp-config.php:

define( 'WP_POST_REVISIONS', 5 );

Esto mantiene un máximo de 5 revisiones por entrada. Es una constante de WordPress que solo funciona desde wp-config.php, no se puede configurar con SQL ni con un código PHP normal.

Si ya tienes miles de revisiones acumuladas, elimínalas:

SQL:

DELETE p, pm, tr
FROM wp_posts p
LEFT JOIN wp_postmeta pm ON pm.post_id = p.ID
LEFT JOIN wp_term_relationships tr ON tr.object_id = p.ID
WHERE p.post_type = 'revision';

PHP:

function ayudawp_delete_all_revisions() {
    global $wpdb;
    $wpdb->query(
        "DELETE p, pm, tr
        FROM {$wpdb->posts} p
        LEFT JOIN {$wpdb->postmeta} pm ON pm.post_id = p.ID
        LEFT JOIN {$wpdb->term_relationships} tr ON tr.object_id = p.ID
        WHERE p.post_type = 'revision'"
    );
}

WP-CLI:

# Listar cuántas revisiones hay.
wp post list --post_type=revision --format=count

# Borrar todas las revisiones.
wp post delete $(wp post list --post_type=revision --format=ids) --force

Eliminar transients caducados:

SQL:

DELETE FROM wp_options
WHERE option_name LIKE '%_transient_timeout_%'
AND option_value < UNIX_TIMESTAMP();

DELETE FROM wp_options
WHERE option_name LIKE '%_transient_%'
AND option_name NOT LIKE '%_transient_timeout_%'
AND option_name NOT IN (
    SELECT REPLACE(option_name, '_timeout', '')
    FROM (
        SELECT option_name FROM wp_options
        WHERE option_name LIKE '%_transient_timeout_%'
    ) AS t
);

PHP:

function ayudawp_delete_expired_transients() {
    global $wpdb;
    // Borrar timeouts caducados.
    $wpdb->query(
        "DELETE FROM {$wpdb->options}
        WHERE option_name LIKE '%_transient_timeout_%'
        AND option_value < UNIX_TIMESTAMP()"
    );
    // Borrar transients huerfanos (sin timeout asociado).
    $wpdb->query(
        "DELETE FROM {$wpdb->options}
        WHERE option_name LIKE '%_transient_%'
        AND option_name NOT LIKE '%_transient_timeout_%'
        AND option_name NOT IN (
            SELECT REPLACE(option_name, '_timeout', '')
            FROM (
                SELECT option_name FROM {$wpdb->options}
                WHERE option_name LIKE '%_transient_timeout_%'
            ) AS t
        )"
    );
}

WP-CLI:

wp transient delete --expired

WP-CLI tiene este comando nativo que lo hace directamente, sin necesidad de consultas SQL.

Convertir tablas MyISAM a InnoDB:

Si tu WordPress lleva muchos años funcionando o se migró desde una instalación antigua, es posible que algunas tablas todavía usen el motor MyISAM en vez de InnoDB. MyISAM bloquea la tabla completa cuando se escribe en ella, lo que en una web con tráfico significa que las lecturas se quedan esperando mientras se procesa cualquier escritura.

SQL (tabla por tabla):

ALTER TABLE wp_nombre_tabla ENGINE = InnoDB;

PHP:

function ayudawp_convert_myisam_to_innodb() {
    global $wpdb;
    $tables = $wpdb->get_results(
        $wpdb->prepare(
            "SELECT TABLE_NAME
            FROM information_schema.TABLES
            WHERE TABLE_SCHEMA = %s
            AND ENGINE = 'MyISAM'",
            DB_NAME
        )
    );
    foreach ( $tables as $table ) {
        // Usar esc_sql para el nombre de tabla en consulta directa.
        $table_name = esc_sql( $table->TABLE_NAME );
        $wpdb->query( "ALTER TABLE `{$table_name}` ENGINE = InnoDB" );
    }
}

WP-CLI:

# Primero ver qué tablas usan MyISAM.
wp db query "SELECT TABLE_NAME FROM information_schema.TABLES WHERE TABLE_SCHEMA = DATABASE() AND ENGINE = 'MyISAM';"

# Convertir una tabla concreta.
wp db query "ALTER TABLE $(wp db prefix)nombre_tabla ENGINE = InnoDB;"

Haz esto tabla por tabla y comprueba después que todo funciona correctamente.

OPTIMIZE TABLE:

Este comando reorganiza el almacenamiento físico de una tabla y recupera el espacio desperdiciado por fragmentación. Es útil después de haber hecho borrados masivos (revisiones, transients, postmeta huérfano):

SQL:

OPTIMIZE TABLE wp_options, wp_postmeta, wp_posts, wp_comments, wp_commentmeta;

PHP:

function ayudawp_optimize_core_tables() {
    global $wpdb;
    $tables = array(
        $wpdb->options,
        $wpdb->postmeta,
        $wpdb->posts,
        $wpdb->comments,
        $wpdb->commentmeta,
    );
    $table_list = implode( ', ', $tables );
    $wpdb->query( "OPTIMIZE TABLE {$table_list}" );
}

WP-CLI:

wp db optimize

El comando wp db optimize optimiza todas las tablas de la base de datos de una vez.

Conviene saber que OPTIMIZE TABLE no mejora la velocidad de las consultas por sí solo. Si una consulta es lenta porque le falta un índice, optimizar la tabla no va a cambiar nada. Es una operación de mantenimiento para después de limpiar datos, no una solución milagrosa.

Prevención y vigilancia

Arreglar las consultas problemáticas es solo la mitad del trabajo, la otra mitad es evitar que el problema vuelva a aparecer, así que toma nota, por favor:

• Limitar revisiones desde el principio: Configura WP_POST_REVISIONS en el wp-config.php de todas tus instalaciones. Es una de esas cosas que deberían venir por defecto.
• Evaluar plugins antes de instalarlos: Antes de instalar un plugin nuevo, activa Query Monitor y compara cuántas consultas hace tu web antes y después de activarlo. Si un plugin añade 30 consultas extra por carga de página, piénsatelo dos veces.
• Revisar la base de datos periódicamente: No hace falta hacerlo cada semana, pero una vez al mes o cada dos meses, echa un vistazo al tamaño de las tablas, al autoload de wp_options, a los transients acumulados y a las tareas de cron. Cinco minutos de comprobación te pueden ahorrar horas de diagnóstico cuando algo va mal.

Qué pedirle a tu hosting cuando ya has hecho todo lo que podías

Si has optimizado consultas, creado índices, limpiado tablas y tu web sigue lenta, el siguiente paso es hablar con tu hosting. Pídeles que revisen los parámetros de configuración de MySQL/MariaDB, especialmente los buffers de caché de consultas, el innodb_buffer_pool_size y los límites de conexiones simultáneas. También pídeles acceso al slow query log si no lo tienes ya. Un buen hosting colaborará contigo en esto sin problemas.

Para terminar

La base de datos es una de esas partes de WordPress que mucha gente ignora hasta que da problemas. Cuando los da, suele ser porque lleva meses o años acumulando consultas innecesarias, datos huérfanos y configuraciones que nadie revisó.

Lo bueno es que, como has visto, no necesitas ser un experto en MySQL ni tener acceso de administrador al servidor para diagnosticar y solucionar la mayoría de estos problemas. Con un plugin como Query Monitor, un par de snippets PHP y las consultas de diagnóstico que hemos visto, puedes hacer un análisis bastante completo de tu base de datos sin depender de nadie.

Un par de consejos finales basados en la experiencia:

• No optimices a ciegas: Diagnostica primero, arregla después. Crear índices, borrar datos o cambiar configuraciones sin saber qué consultas están fallando es como tomar medicinas sin saber qué enfermedad tienes. Puede funcionar por suerte, pero probablemente no.
• Haz copia de seguridad antes de cada cambio: Sé que ya lo he dicho, pero no me canso de repetirlo. Un DELETE mal ejecutado en la base de datos no tiene botón de deshacer.
• Empieza por lo que más impacto tenga. Si tu autoload pesa 5 MB y tienes 200.000 registros de postmeta huérfano, arreglar esas dos cosas probablemente mejore más el rendimiento que todas las demás optimizaciones juntas.
• No dejes herramientas de diagnóstico en producción: Ni SAVEQUERIES, ni el mu-plugin de registro, ni Query Monitor activo permanentemente. Son herramientas temporales para diagnosticar, no para dejar instaladas. Cada una consume recursos adicionales que no necesitas en el día a día.
• Si un plugin es el culpable, empieza a pensar en cambiarlo: A veces la solución no es optimizar la consulta del plugin, sino buscar una alternativa que haga lo mismo sin machacar la base de datos. No tiene sentido parchear las consecuencias si puedes eliminar la causa.

Lo cierto es que el panorama ha cambiado porque hay decenas de nuevas herramientas que prometen crear tu web en minutos con inteligencia artificial. Algunas cumplen lo que prometen, otras no tanto, y la mayoría sirven para cosas muy concretas que conviene entender antes de tomar decisiones.

Este artículo no va a ser un ladrillo de los míos, pretende ser una guía de consulta rápida. Así que si te estás planteando si alguna de estas alternativas puede sustituir a WordPress para tu proyecto aquí vas a encontrar qué hace cada una, para qué sirve de verdad, para qué no, y qué riesgos tiene, si los hubiera.

Y sí, sabes que vivo por, para y de WordPress, pero también que soy sincero y que siempre digo lo que pienso, soy fan pero no adicto ni sectario.

Los de siempre, ahora con IA

Antes de entrar en las herramientas nuevas un apunte rápido sobre las plataformas que llevan años compitiendo con WordPress y que ahora han incorporado asistentes de IA en sus editores. Ninguna sorpresa ¿verdad?, si hasta los ventiladores se anuncian «… con IA«.

Wix, Squarespace, Webflow y Shopify no necesitan presentación, creo, son plataformas cerradas que tienen planes de suscripción mensual, que ahora te permiten generar diseños iniciales y textos con IA.

Pero la IA no cambia sus limitaciones de siempre, como la dependencia total de la plataforma, personalización limitada a lo que el sistema permita, costes que suben según crece tu proyecto, y datos que no son del todo tuyos. Lo que sí hace la IA es acelerar la creación inicial, algo que para proyectos sencillos puede ser más que de sobra.

Shopify merece mención aparte porque sí funciona bien para tiendas online sencillas y medianas, eso es verdad, pero ¿te he dicho ya que es un ecosistema cerrado con comisiones por transacción?, y para tiendas con necesidades avanzadas acaba siendo caro y limitado frente a WooCommerce.

Los nuevos creadores de webs con IA

Aquí empieza lo bueno, y supongo que por lo que te ha causado interés este artículo, y es que hay una nueva generación de herramientas que usan IA generativa para crear webs y aplicaciones a partir de prompts en lenguaje natural.

La mayoría de estas aplicaciones web nacieron entre 2023 y 2025, y funcionan bajo el concepto de «vibe coding«, o sea, describes lo que quieres en tus propias palabras y la IA genera el código.

Suenan genial en la teoría, aunque en la práctica cada una tiene su sitio y sus límites, cómo no.

Bolt.new

• Qué es: Un entorno de desarrollo completo en el navegador creado por el equipo de StackBlitz. Escribes un prompt y genera aplicaciones web completas (frontend y backend) con vista previa en tiempo real y despliegue con un clic.
• Para qué sirve: Prototipos rápidos, MVPs, pruebas de concepto, herramientas internas sencillas. Va bien para proyectos con menos de 15 o 20 componentes.
• Para qué no: Webs de contenido con gestión editorial, tiendas online, proyectos que necesiten SEO de verdad, cualquier cosa que requiera mantenimiento a largo plazo. El código generado pierde calidad a medida que el proyecto crece en complejidad, y el sistema de tokens hace que los costes sean difíciles de predecir.
• Precio: Gratis con límites muy ajustados (1M tokens/mes). Plan Pro desde 25 $/mes con 10M tokens. El consumo de tokens es variable y puede agotarse rápido en proyectos medianos.
• Código abierto: No. Plataforma propietaria. Puedes exportar tu código pero el entorno de desarrollo depende de ellos.

Lovable

• Qué es: Otro generador de aplicaciones web con IA, centrado en crear interfaces con React y TypeScript. Genera código limpio que se sincroniza con GitHub, lo que te da cierta propiedad del código resultante.
• Para qué sirve: Prototipos con buen acabado visual, MVPs para presentar a inversores o clientes, aplicaciones tipo CRUD sencillas. El código exportable a GitHub es un punto a favor frente a otras opciones.
• Para qué no: Solo genera SPAs (aplicaciones de página única) lo que limita el SEO inicialmente. El backend depende de Supabase, así que si necesitas otra infraestructura vas a tener problemas. No sirve para webs de contenido ni tiendas online.
• Precio: Gratis con 5 créditos diarios (muy poco). Pro desde 25 $/mes con 100 créditos/mes. Los créditos se gastan rápido si estás refinando y corrigiendo.
• Código abierto: No. Plataforma propietaria, pero al menos con exportación a GitHub.

v0 de Vercel

• Qué es: Un generador de componentes de interfaz creado por Vercel (los mismos de Next.js). Escribes lo que quieres y genera componentes React con Tailwind CSS listos para usar.
• Para qué sirve: Generar piezas de interfaz sueltas como botones, formularios, tablas de datos, paneles de navegación. Ideal si eres desarrollador y quieres acelerar la parte visual de un proyecto o simplemente no es lo tuyo.
• Para qué no: No genera aplicaciones completas ni backend. Es un acelerador de frontend no un creador de webs. Necesitas saber programar para integrar lo que genera en un proyecto real.
• Precio: Gratis con 5 $ en créditos/mes (da para 7-15 generaciones). Premium 20 $/mes. Muy atado al ecosistema Vercel/Next.js.
• Código abierto: No. Propiedad de Vercel.

Coderick de SiteGround

• Qué es: La apuesta de SiteGround por el vibe coding. Describes lo que quieres y genera una web o aplicación que se publica directamente en su infraestructura de alojamiento. La gracia es que construir, publicar y alojar ocurre todo en el mismo sitio.
• Para qué sirve: Proyectos que necesitan estar online rápido sin preocuparse de la infraestructura. La integración con el hosting de SiteGround simplifica mucho la parte técnica.
• Para qué no: Es una plataforma joven y en evolución. Para proyectos que necesiten un CMS completo con gestión de contenido, roles de usuario o funcionalidades avanzadas WordPress sigue siendo más adecuado. Eso sí, es de las pocas opciones de este tipo que vienen con hosting incluido.
• Precio: Incluido en planes de SiteGround.
• Código abierto: No. Plataforma propietaria de SiteGround.

Base44

• Qué es: Generador de aplicaciones web completas con IA. Genera frontend, backend, base de datos, autenticación y roles de usuario a partir de un prompt. Incluye hosting y dominio propio.
• Para qué sirve: Herramientas internas, paneles de gestión, aplicaciones de productividad, MVPs funcionales. Va más allá de una web estática porque incluye lógica de backend real.
• Para qué no: No es para webs de contenido, blogs ni tiendas online. Es más una herramienta para crear aplicaciones tipo SaaS sencillas que para hacer páginas web convencionales.
• Precio: Plan gratuito disponible. Planes de pago desde unos 20 $/mes.
• Código abierto: No. Plataforma propietaria.

Astro

• Qué es: Este en caso aparte en esta lista porque no es un creador con IA sino un framework de desarrollo web. Lo incluyo porque la comparación «Astro o WordPress» aparece cada vez más en foros y redes, y merece una aclaración especial. Astro genera sitios estáticos (HTML puro) a partir de código, lo que se traduce en velocidad tremenda, seguridad de base (sin base de datos que atacar) y costes de alojamiento casi nulos.
• Para qué sirve: Blogs técnicos, webs corporativas, porfolios, documentación, landings de producto. El rendimiento es difícil de igualar con cualquier CMS dinámico.
• Para qué no: Necesitas saber programar o contratar a alguien que sepa. No tiene panel de administración como WordPress (salvo que le conectes un CMS headless tipo Contentful o Sanity, lo que añade complejidad y coste). Los usuarios no técnicos no pueden actualizar contenido fácilmente. No es para tiendas online ni aplicaciones dinámicas complejas.
• Precio: El framework es gratuito y open source. El coste es el desarrollo (necesitas un programador o saber tú programar) y el hosting, que puede ser gratuito en Cloudflare Pages o Netlify.
• Código abierto: Sí. Totalmente. Y se puede usar WordPress como CMS headless para alimentar de contenido un sitio hecho con Astro, lo cual es una combinación interesante que da lo mejor de ambos mundos.

Tabla resumen de herramientas de creación de webs con IA

Otras herramientas que merece la pena conocer

Además de las anteriores hay otras que aparecen en las búsquedas y que conviene mencionar, aunque sea brevemente.

• NxCode y Manus son plataformas de vibe coding similares a Bolt y Lovable, con la misma propuesta de generar apps desde prompts. NxCode destaca por su arquitectura multiagente (diferentes IAs para frontend, backend y base de datos). Manus, recientemente adquirida por Meta, se orienta más a aplicaciones web. Ambas son muy recientes y con ecosistemas todavía inmaduros.
• ChilledSites se presenta como un creador de webs con IA orientado a resultados rápidos y sencillos. Más limitado que los anteriores, pensado para landings y micrositios sin complicaciones.
• Figma AI (el generador de sitios web de Figma) y CodeDesign van en la misma línea de ser apps para pasar de diseño a código. Parten de un diseño visual y generan código exportable. Son aceleradores del proceso de diseño, no sustitutos de un CMS ni de un sistema de gestión de contenido.

Híbridos: IAs que crean webs WordPress

Otro animal nuevo son las herramientas como el AI Website Builder de WordPress.com o el creador con IA de Hostinger. Estas usan IA para generar sitios, pero el resultado final es un WordPress. No son alternativas a WordPress, son WordPress con un asistente de IA para la creación inicial. Una vez generado el sitio, todo el mantenimiento, las actualizaciones y la gestión se hacen exactamente igual que con cualquier otro WordPress.

Tabla resumen: otras herramientas y herramientas híbridas

¿Y las tiendas online?

Olvídate, ninguna de las herramientas de vibe coding puro sirve para montar una tienda online de verdad.

Puedes generar una interfaz que parezca una tienda con Bolt o Lovable, e incluso conectar Stripe para aceptar pagos, pero una tienda online real necesita gestión de inventario, variaciones de producto, cálculo de impuestos por zona, métodos de envío, pasarelas de pago con sus regulaciones, facturas, devoluciones, cupones, informes de ventas, y cumplimiento legal (RGPD, ley de consumidores, accesibilidad).

Nada de eso viene de serie con estas herramientas, y crearlo a base de prompts sería un acto de fe.

Para tiendas online las opciones reales siguen siendo WooCommerce (si quieres control total y propiedad de los datos) o Shopify (si prefieres una solución alojada y no te importa pagar comisiones y perder flexibilidad). Los creadores con IA pueden servir como mucho para generar un prototipo visual de cómo quieres que se vea tu tienda, pero de ahí a tener una tienda funcional y legal hay un abismo.

Pedirle tu web directamente a ChatGPT, Claude o Codex

Hay una opción más que no suele aparecer en las comparativas y que sin embargo funciona sorprendentemente bien para ciertos casos, y es pedirle directamente a un modelo de IA que te genere el código de tu web.

Con herramientas como Claude Code, ChatGPT o Codex puedes generar sitios web estáticos completos con HTML, CSS, JavaScript, todo listo para subir a cualquier hosting. No estás atado a ninguna plataforma, el código es tuyo al 100% y lo alojas donde quieras.

Funciona especialmente bien para webs estáticas tipo landing de producto, web corporativa sencilla o página de presentación de un servicio. De hecho, webs como vigia.dev, vigilante.works o bisnis.es están hechas exactamente así, con Claude Code, y son webs profesionales, rápidas, seguras y con coste de alojamiento prácticamente cero.

La ventaja es el control absoluto, sin dependencias de plataformas de terceros, sin suscripciones mensuales, sin sistema de tokens ni créditos que se agotan. El código resultante es tuyo, lo puedes modificar, alojar donde quieras y migrar cuando te dé la gana.

La pega es que necesitas saber qué pedir y cómo pedirlo a la IA (o al menos tener criterio para evaluar lo que recibes), y cualquier cambio futuro requiere volver a hablar con la IA o editar el código a mano. No hay panel de administración ni editor visual. Para una web que se actualiza poco, esto no es un problema, para un blog con publicaciones semanales o una web con contenido dinámico, necesitas algo más.

«Cositas» que no te cuentan

No voy a extenderme mucho aquí porque ya he tratado el tema en profundidad en otro artículo, pero hay algunos puntos que conviene tener presentes antes de decidir.

• Dependencia y efecto lock-in: La mayoría de estas herramientas son plataformas cerradas, tu proyecto vive dentro de su ecosistema, y sacarlo puede ser complicado o directamente imposible. Con WordPress, si un día tu hosting no te gusta lo migras a otro en una tarde. Con muchas de estas herramientas, si la empresa cierra o sube los precios, tienes un problema serio.
• Startups sin recorrido: Muchas de estas plataformas no llevan ni dos años en el mercado. Bolt pasó de 0 a 4 millones de dólares anuales en 30 días, lo cual suena impresionante, pero también significa que su modelo de negocio no ha pasado aún la prueba del tiempo. WordPress lleva más de 20 años y alimenta más del 45% de toda la web.
• Seguridad: Según datos recientes alrededor del 45% del código generado por IA contiene vulnerabilidades de seguridad. Esto no es un problema exclusivo de una herramienta concreta, es una limitación actual de la generación de código con IA en general. Un WordPress bien mantenido, con actualizaciones regulares y buenas prácticas de seguridad, sigue siendo una opción más probada.
• SEO/GEO de verdad: Generar una página bonita es fácil, posicionarla es otra historia. La mayoría de estas herramientas generan SPAs o sitios con montón de JavaScript, algo que no se lleva bien con el SEO. WordPress, con sus 20 años de ecosistema SEO (plugins, esquemas, sitemaps, control total del HTML), sigue siendo difícil de superar para quien necesite tráfico orgánico (si es que eso aún existe).
• El mantenimiento no desaparece: En realidad solo cambia de forma. En vez de actualizar plugins y temas, estarás quemando créditos para corregir errores generados por la IA, peleándote con código que no entiendes del todo, o dependiendo de una plataforma que puede cambiar sus precios o condiciones cuando quiera.

¿Cuándo tiene sentido usar una alternativa a WordPress?

Después de revisar todo esto, la respuesta corta es … depende del proyecto.

Estas herramientas pueden funcionar bien si:

• Necesitas una landing page o un micrositio que se actualiza poco o nada.
• Estás creando un prototipo o MVP para validar una idea antes de invertir en desarrollo.
• Quieres una web estática tipo portfolio o página corporativa sencilla (y sabes algo de código o tienes a alguien que sepa).
• Necesitas una herramienta interna o un panel de gestión rápido para tu equipo.
• Tu proyecto es temporal: un evento, una campaña, una promoción puntual.

WordPress sigue siendo la mejor opción si:

• Necesitas gestionar contenido regularmente (blog, revista, portal de noticias).
• Quieres una tienda online con todas las de la ley.
• Necesitas que personas no técnicas puedan editar y publicar contenido.
• Tu proyecto va a crecer con el tiempo y necesitas flexibilidad para añadir funcionalidades.
• Te importa la propiedad de tus datos y la independencia del proveedor.
• Necesitas multiidioma, roles de usuario, integraciones con terceros, formularios avanzados o cualquier funcionalidad que vaya más allá de mostrar información estática.
• El SEO es una parte central de tu estrategia.
• Quieres TODOS esos plugins que nos hacen la vida más sencilla.

El camino de vuelta: WPConvert.ai

Para cerrar, una curiosidad que dice mucho sobre cómo están las cosas. Existe una herramienta llamada WPConvert.ai que hace justo lo contrario de todo lo que hemos visto, pues convierte cualquier web generada con IA en tema WordPress con un clic.

Es decir, hay un mercado suficiente de gente que generó su web con IA, se dio cuenta de que necesitaba las funcionalidades de gestión de WordPress, y ahora quiere volver. Que exista una herramienta dedicada a resolver ese problema específico te da una pista bastante clara de hacia dónde acaban muchos de estos experimentos.

Las herramientas de creación con IA son útiles para lo que son, crear rápido cosas concretas. Cuando un proyecto necesita crecer, gestionarse, posicionarse, venderse y mantenerse a largo plazo, la conversación suele terminar en el mismo sitio de siempre.

¡Ah! ¿qué dónde?

Pues en WordPress, ¿dónde va a ser?

En este otro tutorial vimos cómo borrar acciones programadas de golpe, ya sea con consultas SQL, desde phpMyAdmin o con un plugin. Pero hay un problema que no resolvía esa guía, y es ni más ni menos ¿qué pasa cuando al cabo de unas semanas o meses vuelves a tener la base de datos llena de basura?

Pues eso, que vuelves a estar igual, y si tienes una tienda online con movimiento o una web con varios plugins que usan el programador de acciones, la acumulación de registros inútiles es inevitable.

Hoy vamos a aprender a programar esa limpieza del puñetero Action Scheduler para que se haga sola, sin que tengas que acordarte ni tocar nada.

Por qué la limpieza manual no es suficiente

Limpiar una vez está bien, lo haces, liberas espacio, tu base de datos se alivia y todo va más rápido.

El problema es que las tablas wp_actionscheduler_actions y wp_actionscheduler_logs se vuelven a llenar porque es lo que hacen, almacenar registros de cada acción que ejecutan WooCommerce, plugins de membresía, de formularios, de automatizaciones y un enorme etcétera.

Si tu web tiene actividad constante en cuestión de semanas puedes volver a acumular cientos de miles de registros de acciones completadas, fallidas, canceladas y registros de log que no sirven absolutamente para nada más que para ocupar espacio.

La única solución real es que la limpieza se haga de forma automática y periódica.

Qué registros se pueden limpiar automáticamente

Antes de configurar nada conviene tener claro qué se limpia y qué no. Esto ya lo expliqué en detalle en el tutorial de borrado de acciones programadas pero te hago un resumen rápido:

Lo que se puede (y se debe) limpiar:

• Acciones completadas: ya se ejecutaron, no sirven para nada.
• Acciones fallidas: dieron error y ahí se quedaron.
• Acciones canceladas: alguien las canceló manualmente.
• Acciones vencidas: no se ejecutaron a tiempo, se les pasó el arroz.
• Acciones pendientes antiguas: llevan semanas esperando y nadie las va a ejecutar.
• Registros del log: el historial detallado de cada ejecución, que puede crecer de forma desproporcionada.

Lo que NO se tocan:

• Acciones pendientes recientes y las que están en ejecución: se quedan siempre intactas, porque esas las necesita tu web para funcionar correctamente.

Cómo configurar la limpieza automática paso a paso

Para esto vamos a usar Easy Actions Scheduler Cleaner, que desde su versión 1.1.0 incorpora la posibilidad de programar limpiezas automáticas con un sistema bastante completo.

Si ya tienes el plugin instalado, ve a «Herramientas → Easy Actions Scheduler Cleaner». Si no lo tienes, instálalo desde el el instalador de plugins de tu WordPress, es totalmente gratuito, actívalo y te llevará directamente a su página de ajustes.

Verás que ahora hay dos pestañas: Limpieza manual (la limpieza de siempre) y Limpieza programada, que es la que nos interesa hoy.

Activar la limpieza programada

Al entrar en la pestaña de limpieza programada lo primero que verás es una casilla para activar el sistema de programación de limpieza de registros. Mientras no lo actives no se programa nada.

Elegir la frecuencia

Justo debajo de la casilla hay un selector de frecuencia con cuatro opciones:

• Diaria: para sitios con mucha actividad (tiendas grandes, webs con miles de transacciones diarias).
• Semanal: la opción recomendada para la mayoría de sitios.
• Quincenal: para sitios con actividad moderada.
• Mensual: para blogs o webs con pocos plugins que usen el programador de acciones.

La primera ejecución se programa después de que pase el intervalo completo que elijas. Es decir, si seleccionas semanal la primera limpieza se hará una semana después de guardar los ajustes, no inmediatamente.

Configurar qué tipos de registros limpiar

Esto es casi lo mejor, porque en la tabla de tipos de acción puedes activar o desactivar la limpieza de cada tipo de registro de forma independiente. Para cada uno hay tres columnas que son importantes:

• Limpiar (casilla): si quieres que se limpie ese tipo o no.
• Registros mínimos (umbral): el número mínimo de registros que tiene que haber para que se ejecute la limpieza de ese tipo.
• Recuento actual: cuántos registros de ese tipo tienes ahora mismo.

Para las acciones pendientes antiguas hay un campo adicional donde puedes indicar a partir de cuántos días se consideran antiguas (por defecto 30, configurable de 7 a 365 días).

Cuando el recuento actual supere el umbral que has configurado verás una marca verde (✓) junto al número, indicando que ese tipo de acción se limpiará en la próxima ejecución.

Dale al botón de guardar ajustes y ya está, el plugin se encarga de registrar el evento en el cron de WordPress y se ejecutará automáticamente según la frecuencia que hayas elegido.

Si todo ha ido bien debajo del interruptor verás un mensaje indicando cuándo será la próxima ejecución programada.

Sistema de umbrales para limpiar solo cuando hace falta

Esta es la parte que más me gusta del sistema de limpieza programada, porque evita ejecuciones innecesarias.

Pongamos un ejemplo, que tienes configurado el umbral de acciones completadas en 100 y solo hay 35 registros, la limpieza programada se ejecutará, comprobará ese número y dirá «aquí no hay nada que hacer» y pasará al siguiente tipo.

Solo cuando los registros superen el umbral que tú has definido se procede al borrado.

Esto tiene tres ventajas obvias:

• No desperdicia recursos del servidor: Si no hay nada que limpiar, no se hacen operaciones de borrado innecesarias en la base de datos.
• Puedes dejarlo activo sin preocuparte: No va a borrar cuatro registros cada vez que se ejecute. Espera a que realmente se acumule una cantidad que merezca la pena limpiar.
• Sabes lo que va a pasar: Desde la misma pantalla de configuración puedes ver en todo momento cuántos registros hay de cada tipo y si superan o no el umbral. Sin sorpresas.

Cómo saber qué pasó en la última limpieza

Cada vez que se ejecuta la limpieza programada el plugin guarda un registro del resultado que se muestra en la parte superior de la pestaña de programación.

Puedes ver tres estados:

• Verde: se ejecutó correctamente y te muestra cuántos registros se borraron de cada tipo.
• Azul: se ejecutó pero no había nada que limpiar (ningún tipo superó su umbral).
• Rojo: hubo un error (por ejemplo, que las tablas del programador de acciones no existan).

Así puedes verificar que todo funciona sin tener que andar adivinando.

Qué configuración te recomiendo según tu caso

No todas las webs necesitan la misma configuración. Aquí van algunas orientaciones:

• Tienda WooCommerce con bastante movimiento: frecuencia semanal, umbrales bajos (50-100 para acciones, 200-500 para logs), días de pendientes antiguas en 15-30. Son las que más basura generan.
• Web con membresías o suscripciones: frecuencia semanal o quincenal, umbrales medios (100-200), días de pendientes antiguas en 30.
• Blog con WooCommerce de baja actividad: frecuencia mensual, umbrales altos (200-500), días de pendientes antiguas en 60. No genera tanta basura pero conviene tenerlo controlado.
• Web sin WooCommerce pero con plugins que usan Action Scheduler: frecuencia mensual, umbrales altos (200-500). Plugins como formularios, automatizaciones o incluso algunos de SEO pueden usar el programador de acciones.

Lo importante es que no te compliques. Los valores por defecto del plugin ya están pensados para un uso general razonable. Si no tienes claro qué poner déjalos como están y ajusta solo la frecuencia.

Una nota sobre el cron de WordPress

La limpieza programada usa WP-Cron, que es el sistema de tareas programadas de WordPress.

Esto funciona bien en la mayoría de sitios, pero tiene una particularidad, y es que WP-Cron se ejecuta cuando alguien visita la web, de modo que si tu sitio tiene muy poco tráfico, es posible que la limpieza se retrase un poco respecto a la hora programada.

Si tienes configurado un cron manual del sistema esto no será un problema porque el cron se dispara de forma puntual independientemente de las visitas.

Combina limpieza manual y programada

Mi recomendación es la misma que sigo con los sitios de nuestros clientes del servicio de mantenimiento web:

1. Haz una limpieza manual para dejar la base de datos limpia. Esto es especialmente importante si llevas tiempo sin limpiar y tienes miles o millones de registros acumulados (aquí tienes el tutorial completo para hacerlo).
2. Activa la limpieza programada para que se mantenga limpia automáticamente. Así no vuelves a tener el problema de siempre.

La combinación de ambas es lo que realmente funciona.

Y ya sabes, el plugin es gratuito y está en WordPress.org: Easy Actions Scheduler Cleaner o en tu instalador de plugins. Si te resulta útil, que seguro que sí, te agradezco que le dejes una valoración de 5 estrellas, que ayuda mucho a que lo encuentre más gente.

Igual que hace 15 años aprendimos a optimizar nuestras webs para Google, ahora toca hacer lo mismo para las IAs. Pero hay una pregunta que mucha gente se hace y pocos saben responder con datos concretos: ¿cómo de preparada está mi web para ser visible ante las IAs?

A esto se le llama «visibilidad IA«, «AI readiness«, «AI visibility» o, si quieres ponerte fino, GEO (Generative Engine Optimization). Hay muchos nombres para lo que en el fondo es una evolución natural del SEO de toda la vida, con algunos matices nuevos que merece la pena entender. Y alrededor de este tema ha surgido toda una industria de herramientas, auditorías y consultorías que conviene conocer antes de abrir la cartera.

En este artículo te explico qué señales componen la visibilidad IA, qué herramientas existen para medirla (la mayoría de pago), cómo interpretar los resultados y cómo puedes implementar y comprobar todo esto en WordPress sin gastar un euro.

Visibilidad IA: qué es (y qué no es)

Vamos a ser claritos desde el principio, el GEO no es una disciplina nueva aparte del SEO, Es el mismo SEO de siempre con algunos añadidos específicos para que los modelos de lenguaje entiendan mejor tu contenido y lo puedan usar como fuente. Si quieres profundizar en esto te recomiendo la guía de SEO para IA donde lo desarrollo en detalle.

Los fundamentos siguen siendo los mismos: contenido de calidad, estructura clara, datos estructurados, rendimiento, autoridad. Lo que cambia es que ahora, además de los algoritmos clásicos de Google, hay otros «lectores» de tu web (los rastreadores de IA) que procesan la información de manera diferente y que valoran algunas señales adicionales.

¿Han cambiado cosas? Sí, claro. Las metas (título y descripción) tienen menos importancia porque los chatbots y los AI Overviews no muestran snippets con título y descripción, muestran respuestas completas elaboradas a partir de varios contenidos.

Los nuevos resultados de búsqueda ya no ofrecen fragmentos, ofrecen respuestas. Pero esas respuestas las extraen de contenidos reales, de gente que sabe de lo que ha preguntado el usuario y que ha tenido a bien compartirlo.

O sea que la base sigue siendo la misma, crear buen contenido, bien estructurado, sobre temas que dominas.

Pero hay una diferencia fundamental que conviene entender, y es que Google lleva más de 20 años rastreando la web, tiene tu mapa del sitio, tu robots.txt, y su sistema de indexación masivo, así que cuando publicas algo, tarde o temprano Googlebot pasa, lo indexa y lo clasifica. Las IAs funcionan de otra manera.

Cuando alguien le hace una pregunta a ChatGPT o a Perplexity el sistema busca información en tiempo real, tirando de lo que puede encontrar y procesar rápidamente. Si tu contenido más valioso está enterrado entre menús de navegación, barras laterales, scripts de JavaScript y banners de cookies, es muy probable que se lo salte o lo malinterprete.

El resultado es que tu web puede ser perfectamente visible en Google y completamente invisible para las IAs. O peor aún, que sea visible pero la interpreten mal.

Las señales que determinan tu visibilidad IA

La buena noticia es que hay un conjunto de mecanismos, algunos ya consolidados y otros emergentes, que funcionan como señales para que las IAs encuentren, entiendan y utilicen correctamente tu contenido. Son las señales que las herramientas de medición analizan, y las que tú puedes activar para mejorar tu puntuación. Vamos a verlas una a una.

robots.txt: la primera línea de comunicación

El archivo robots.txt es el veterano del grupo, lleva décadas diciéndole a los bots qué pueden y qué no pueden rastrear. Pero con la llegada de las IAs ha cobrado una nueva dimensión.

Ahora no solo tienes que gestionar Googlebot o Bingbot, sino también GPTBot, ClaudeBot, PerplexityBot, Google-Extended, Bytespider y más de 50 bots de IA que pueden estar pasando por tu web ahora mismo.

La diferencia entre permitir o bloquear cada uno es algo que conviene pensar con calma, porque no todos hacen lo mismo. Hay IAs que rastrean para entrenar sus modelos (como GPTBot), otras que rastrean para responder búsquedas en directo (como PerplexityBot o OAI-SearchBot) y otras que hacen ambas cosas. Unas te interesan porque te citan como fuente y te generan tráfico, otras simplemente se llevan tu contenido para entrenar un modelo del que nunca verás beneficio alguno.

Un robots.txt bien configurado para IAs te permite establecer reglas diferenciadas: permitir a los bots de búsqueda IA, bloquear a los de entrenamiento puro, y monitorizar quién respeta tus reglas y quién las ignora.

Sitemap XML: lo que los bots de IA buscan primero

Después de haber monitorizado decenas de miles de visitas de rastreadores de IA con VigIA, te puedo decir que el mapa del sitio es prácticamente lo primero que buscan en tu web. Tiran de sitemap a la brava y a partir de ahí van recorriendo contenidos, los devoran.

Así que tener un sitemap limpio, actualizado y sin páginas que no deberían estar ahí (carrito, pago, mi cuenta, etiquetas vacías…) no es un detalle, es una prioridad. Para eso hice Native Sitemap Customizer, precisamente para tener control total sobre qué páginas incluyes en el mapa del sitio nativo de WordPress sin depender de un plugin de SEO para ello.

¿Prefieres usar un plugin de SEO para eso? pues nada, hay montones, pero todos tienen el mismo problema, que no aprovechan recursos nativos que ya tienes, el mapa del sitio que genera WordPress, que además es el más ligero y limpio.

llms.txt: la teoría frente a la realidad

El archivo llms.txt es un estándar propuesto en 2024 que está ganando adopción rápidamente. A día de hoy miles de webs relevantes ya lo han adoptado, incluyendo Anthropic, Cloudflare, Stripe, Perplexity, Hugging Face, Zapier, incluso Ayuda WordPress.

Es un archivo en formato Markdown que se coloca en la raíz de tu dominio (tusitio.com/llms.txt) y que ofrece a las IAs un mapa seleccionado de tus contenidos más importantes.

Mientras que el sitemap.xml tiene como función incluir todas las URLs, en el llms.txt seleccionas solo las que realmente quieres destacar, para decirle a la IA algo como «si vas a consultar mi web, empieza por aquí».

Existe también el llms-full.txt, que incluye el contenido completo de las páginas seleccionadas para que la IA ni siquiera necesite rastrearlas individualmente.

Sobre el papel es una buena idea, en la práctica, y esto te lo digo por experiencia propia monitorizando bots con VigIA, los bots de IA no buscan ni leen los archivos llms.txt.

Los rastreadores de las IAs van directos al sitemap, localizan los contenidos y se los comen uno tras otro. Google lo incluyó en su protocolo Agents to Agents (A2A) y hay datos de que los crawlers de Microsoft, OpenAI y otros rastrean e indexan estos archivos de forma bastante consistente, pero el impacto directo ya te digo que no está demostrado.

¿Significa que no debas tenerlo? Créalo, no cuesta nada (con VigIA lo generas en dos clics), pero no esperes que te cambie la visibilidad o un empujón de tráfico, hoy en día nada te lo da, esto menos, pero al menos el coste de implementarlo es mínimo y ya lo tienes para cuando la adopción sea generalizada.

Markdown para agentes (esto sí)

Este es uno de los mecanismos más interesantes y probablemente el que más impacto real tiene de todas las señales nuevas, y esto te lo digo por experiencia propia, porque cuando un bot de IA tiene disponible una versión Markdown de tu contenido, la prefiere al HTML. La diferencia ha sido inmediata en mis pruebas, fue activarlos y ese mismo día ya los estaban leyendo.

Markdown para agentes es un estándar impulsado por Cloudflare que permite servir cualquier página de tu web en formato Markdown optimizado para agentes de IA. Cada entrada o página puede tener una versión alternativa accesible de dos formas: añadiendo .md a la URL (por ejemplo, tusitio.com/mi-articulo.md) o mediante negociación de contenido (cuando un agente envía la cabecera Accept: text/markdown).

¿Qué consigues con esto?

Cuando un agente de IA accede a tu web normal se encuentra con el HTML completo, los menús, áreas de widgets, scripts, CSS, anuncios, formularios, un montón de ruido alrededor del contenido real.

Con Markdown para agentes la IA recibe directamente el contenido limpio, estructurado, con metadatos ricos en formato YAML (título, autor, fecha, categorías, etiquetas) y sin una sola línea de código innecesario.

Además, cada respuesta incluye la cabecera X-Markdown-Tokens que indica el número de tokens del contenido, algo muy útil para que los agentes gestionen su ventana de contexto.

Es como la diferencia entre darle a alguien un libro con la portada, el índice y los capítulos limpios, o darle un montón de folios sueltos mezclados con publicidad.

Por si te quedaba alguna duda, en las webs de WordPress.org ya se ha adoptado globalmente y se están sirviendo sus contenidos también en Markdown.

JSON-LD con señales AI Discovery

Esto no es nada nuevo, los datos estructurados en formato JSON-LD llevan años siendo fundamentales para el SEO tradicional.

Gracias a ellos consigues los rich snippets en Google, esas estrellas de valoración, precios de productos, preguntas frecuentes, datos de la empresa, etc.

Lo que sí es nuevo es que JSON-LD tiene ahora otra función igual de importante: ayudar a las IAs a entender quién eres y dónde está tu contenido preparado para ellas.

Mediante el marcado de schema.org puedes generar datos estructurados que incluyan la identidad de tu sitio (WebSite + Organization o Person, con perfiles sociales mediante sameAs) y señales de AI Discovery como acciones de tipo ReadAction que apuntan directamente a tus archivos llms.txt, llms-full.txt y a tus endpoints de Markdown para agentes.

Esto es como decirle a la IA en su propio idioma «oye, tengo contenido optimizado para ti, y está aquí, aquí y aquí».

Microsoft ha confirmado que Bing usa schema.org para sus modelos de IA (Copilot incluido), Google muestra comportamientos en AI Overviews que claramente demuestran que lo usa, y OpenAI procesa HTML estático, por lo que el JSON-LD incrustado en la página es fácilmente procesable por GPTBot.

Al combinar la identidad del sitio con los punteros a tus recursos AI-ready, creas un ecosistema de datos estructurados que conecta todo el sistema de señales IA.

Los plugins de SEO no generan estas señales de AI Discovery (de momento), pero es algo que ya se puede implementar. Si no tienes claro qué es JSON-LD o cómo funciona, tienes aquí una guía de JSON-LD donde te lo explico ampliamente pero de manera sencilla.

También entran en juego en esta categoría los Open Graph y Twitter Cards (metadatos para compartir en redes que las IAs también procesan), la meta description (con menos peso que antes, como comentaba, pero sigue siendo un resumen útil del contenido), la URL canónica y la declaración de idioma de la página.

Compartir contenido en IAs

Las señales anteriores son pasivas, porque tú las configuras y esperas a que las IAs vengan a por ellas. Pero hay una que es activa y que depende de tus propios visitantes.

¿Qué pasaría si tus lectores pudieran compartir tu contenido directamente con ChatGPT, Claude, Gemini, Grok o Perplexity con un solo clic?

No me refiero copiar y pegar el texto (perdiendo toda atribución), sino abrir la IA con un prompt optimizado que incluye tu URL como fuente.

Esto es exactamente lo que hace el plugin de compartir y resumir en IA, que ya deberías conocer, añadir botones de compartir y resumir no solo para las redes sociales clásicas (Twitter/X, Facebook, LinkedIn, WhatsApp, Telegram, email) sino también para las principales IAs.

Cada vez que un visitante comparte tu artículo con una IA está alimentando a ese modelo para que conozca tu web y tu contenido como fuente autorizada. El prompt que se envía automáticamente incluye la URL, lo que genera enlaces entrantes naturales desde las plataformas de IA más importantes del mundo.

Tus lectores iban a compartir el contenido con las IAs de todas maneras, pero así al menos estás entrenando a la IA a que conozca, cite y enlace a tus contenidos como fuente de información. De paso, te permite monitorizar cuántos clics genera cada botón para saber qué plataformas usan tus lectores.

Señales de contenido para IA

Hay una señal más que completa el kit, la posibilidad de especificar en tu robots.txt no solo si una IA puede rastrear o no, sino para qué puede usar tu contenido. ¿Solo para búsqueda? ¿Solo para entrenamiento? ¿Para ambos?

El plugin AI Content Signals implementa una propuesta respaldada por Cloudflare que permite añadir estas directivas. Es otra capa de comunicación con las IAs que complementa al resto de señales.

Estructura del contenido y legibilidad

Esto es SEO clásico puro, pero con un matiz, que las IAs son especialmente sensibles a la estructura porque procesan el contenido de forma secuencial y jerárquica.

Un artículo con buena jerarquía de encabezados, HTML semántico y contenido bien organizado es mucho más fácil de procesar para una IA que un bloque de texto sin estructura.

Revisan la presencia del H1 y que solo haya uno, la jerarquía de encabezados (que se respete el orden H1 → H2 → H3 sin saltos), el uso de HTML5 semántico (etiquetas como <article>, <section>, <main>), el texto alternativo en imágenes (ahora más importante que nunca porque las IAs lo usan para entender el contenido visual), el ratio contenido/HTML y la independencia de JavaScript.

Este último punto merece una explicación adicional, y es que los rastreadores de IA normalmente no ejecutan JavaScript, leen el HTML que tu servidor envía directamente.

Si tu contenido se carga dinámicamente con JavaScript después de que la página cargue es posible que las IAs no lo vean. Si desactivas JavaScript en tu navegador y tu contenido desaparece tienes un problema.

TTFB

La velocidad es importante para todos los visitantes, humanos e IAs. Los rastreadores de IA tienen tiempos de espera limitados y si tu servidor tarda mucho en responder pueden abandonar la solicitud antes de procesar tu contenido.

Debes vigilar especialmente el TTFB (Time to First Byte), ese parámetro que mide cuánto tarda tu servidor en empezar a enviar la respuesta.

Por debajo de 200 ms es excelente, entre 200 y 500 ms es bueno, de 500 ms a 1 segundo necesita mejora, y por encima de 1 segundo es un problema serio.

Las herramientas para «medir» la visibilidad IA

Ya conoces las señales, ahora la pregunta sería cómo saber si tu web las tiene bien implementadas, y aquí es donde entran las herramientas de medición, y donde el panorama se pone interesante (y un poco chungo a veces).

Antes de entrar en cada una, una aclaración importante, y es que existen dos tipos de herramientas que se llaman «AI visibility» pero que miden cosas muy diferentes.

Analizadores técnicos de AI Readiness

Escanean tu web y comprueban si tienes las señales técnicas correctas (Schema, JSON-LD, estructura, rendimiento, etc.). Te dicen si tu web está preparada para ser procesada por IAs, y son las que nos interesan.

Monitores de visibilidad de marca en IAs

Estas herramientas preguntan directamente a ChatGPT, Gemini, Perplexity, etc. sobre tu marca y comprueban si la IA te menciona en sus respuestas.

Te dicen, en teoría, si ya apareces, no si estás preparado para aparecer, podríamos decir que son complementarias. Si te interesan, las más conocidas son SEO Review Tools AI Brand Visibility (gratis), GoVISIBLE, Visalytica y el AI Visibility Overview de Wix.

Pero ahora mi consejo: ¡no las uses, mucho menos pagues por ellas!

¿Por qué lo digo?, pues porque las IAs son tremendamente inconsistentes en las respuestas y, no solo en distintas sesiones o a distintos usuarios, en la misma conversación dan respuestas totalmente diferentes, incluso con el mismo prompt, y sino me crees pregúntale a Natzir.

Dicho esto, vamos con los analizadores técnicos, que son los que sí te pueden ayudar a mejorar, no solo para las IAs, en general, y de paso siempre aprendes algo, a mi al menos me han servido y mucho para recuperar casi todo el tráfico que perdí tras la aparición de los chatbots de IA, esos otros buscadores.

AIO Checker

Web: aiochecker.vercel.app
Precio: Escaneo básico gratis, informe completo 4,99 $ por URL

Puntuación de 0 a 100 con 7 métricas: presencia de llms.txt, Schema/JSON-LD, meta tags y frescura del contenido, estructura y densidad, renderizado del servidor, calidad del sitemap y más.

Es rápido y el precio del informe completo es razonable para un análisis puntual, pero solo analiza una URL por consulta, no tiene contexto de tu CMS (no sabe qué plugins tienes ni qué funcionalidades están activas) y las recomendaciones son genéricas.

LLMClicks.ai

Web: llmclicks.ai/ai-readiness-analyzer/
Precio: Auditoría gratuita con PDF de 9 páginas, servicios de consultoría de pago

Auditoría de 9 puntos centrada en entidades, densidad de esquema y eficiencia de tokens. Analiza varias páginas (homepage, servicios, about, blog) y genera un PDF bien presentado. El enfoque en entidades es interesante.

Lo mejorable: es claramente un embudo comercial hacia sus servicios de consultoría. Las recomendaciones te llevan sí o sí a contratar su servicio de optimización.

SEOptimer (checks GEO)

Web: seoptimer.com
Precio: Auditoría básica gratis, planes desde 19 $/mes

Herramienta de auditoría SEO de toda la vida que recientemente ha añadido tres checks de GEO: presencia de llms.txt, contenido renderizado (si las IAs pueden leer tu contenido sin JavaScript) y schema de identidad (Organization, Person, LocalBusiness).

Si ya usas SEOptimer, tener los checks GEO integrados es práctico, pero solo tres checks de GEO es quedarse muy corto. No comprueba Markdown para agentes, Content Signals, directivas específicas para bots de IA, feed RSS ni la mayoría de señales que realmente merecen la pena y sirven de algo.

Trustworthy Digital AI Readiness Tool

Web: trustworthydigital.com/ai-readiness-tool/
Precio: Análisis gratuito de 10 páginas

Evalúa cuatro dimensiones: extractabilidad del contenido, estructura legible para máquinas, señales de autoridad y frescura. El enfoque en «extractabilidad» es acertado y el hecho de que analice varias páginas en vez de una sola es un punto a favor.

No comprueba llms.txt, Markdown for Agents ni señales técnicas específicas de IA. Es más un análisis de calidad de contenido general que una auditoría técnica de AI readiness.

AI Visibility Tool (extensión de Chrome)

Web: Chrome Web Store
Precio: Gratis

Extensión que escanea cualquier página desde el navegador con desglose por categorías: rastreabilidad para bots de IA, datos estructurados, visibilidad LLM, contenido orientado a respuestas y encabezados. Es rápido, cómodo y puedes exportar los informes.

Solo analiza la página que estás viendo, sin contexto del backend. No puede saber si tienes funcionalidades configuradas pero sin activar, ni detectar conflictos entre plugins.

ResultFirst AI Visibility Analysis

Web: resultfirst.com/tools/ai-visibility-analysis/
Precio: Análisis básico gratis, servicios de optimización de pago

Combina el análisis técnico con la comprobación de presencia en IAs: escanea tu web y además comprueba si apareces en respuestas de ChatGPT, Gemini y Perplexity. El enfoque combinado es interesante, pero como todas las herramientas web, no tiene acceso al backend y el objetivo final es venderte su servicio de optimización.

VigIA (plugin para WordPress)

Web: VigIA en WordPress.org
Precio: Gratis, sin límites

VigIA incluye un analizador de visibilidad IA con un sistema de 100 puntos, 20 comprobaciones y notas de A+ a F. A diferencia de todas las anteriores funciona desde dentro de WordPress, lo que le da una ventaja que ninguna herramienta externa puede igualar.

Al estar instalado en tu sitio sabe qué plugins tienes activos, detecta conflictos de Schema (si tu tema, tu plugin SEO y WooCommerce están generando el mismo Schema por triplicado, te avisa), sabe si tienes funcionalidades configuradas pero sin activar, y puede enlazarte directamente a la pantalla donde corregir cada problema.

Las recomendaciones se organizan en 4 niveles:

1. Funcionalidades del propio VigIA que puedes activar con un clic (llms.txt, Markdown para agentes, JSON-LD).
2. Plugins complementarios gratuitos que puedes instalar directamente (como AI Share & Summarize o AI Content Signals).
3. Plugins que ya tienes instalados pero desactivados.
4. Plugins de terceros con enlace de instalación, de SEO por ejemplo.

Todo sin salir de WordPress.

Además del analizador, VigIA es un kit de herramientas IA completo:

• Monitoriza más de 50 rastreadores de IA (quién visita tu web, con qué frecuencia, qué páginas).
• Permite bloquear rastreadores vía PHP (más efectivo que robots.txt porque es obligatorio, no consultivo).
• Genera llms.txt y llms-full.txt automáticamente.
• Sirve Markdown for Agents, genera JSON-LD con AI Discovery.
• Envía informes por email.

Puedes analizar cualquier página de tu sitio con un campo de URL con autocompletado (escribe el título y te sugiere entradas, páginas y CPTs). Los resultados se cachean 24 horas, con opción de forzar un re-análisis cuando hagas cambios.

La desventaja obvia es que solo funciona en WordPress. Si tu web está en otro CMS las herramientas externas son tu opción, pero también te contaré sorpresas a este respecto.

¡Ah! ¿Te he dicho que es 100% gratis, del todo?

¿Repasamos o lo tienes claro?

Comparativa general

Extra

Además de estas herramientas que hemos visto, aunque no es tan efectivo como el medidor incluido en VigIA, también he añadido la herramienta de medición de visibilidad en IA gratis en la web de códigos, medidores y herramientas, la tienes con el nombre tan poco intuitivo de Visibilidad IA.

Es muy útil, te da mediciones útiles, y buenos consejos, pero ¿por qué digo que no es tan efectiva como VigIA?, pues porque ve las webs desde fuera, no sabe lo que tienes instalado o no, no ve partes de la estructura, analiza lo que se ve, no lo que hay.

Es para los que no queráis instalar VigIA aún o queráis curiosear las webs de otros (con las precauciones debidas de saber que no es tan precisa la medición como desde dentro), o para aprender, que nunca está de más.

Cómo implementar todo el kit de visibilidad IA en WordPress

Ahora vamos a lo práctico…

Todo lo que he descrito puede sonar complejo pero la realidad es que al usar WordPress puedes tener todas las señales funcionando en cuestión de minutos con tres plugins gratuitos.

VigIA: el centro de control

VigIA gestiona la mayoría de las señales desde un único plugin:

• Analítica de rastreadores: Te dice exactamente qué IAs pasan por tu web, cuándo, con qué frecuencia y qué páginas visitan. Panel de estadísticas con visitas totales, rastreadores únicos, gráfico temporal con desglose diario, distribución por categorías (entrenamiento, búsqueda, asistente, recopiladores de datos), los rastreadores más activos y las páginas más visitadas. Esta información te permite tomar decisiones fundamentadas sobre tu estrategia.
• Analizador de visibilidad IA: El sistema de 100 puntos y 20 comprobaciones. Analiza tu homepage o cualquier página individual, te da la nota, el desglose por categorías y las recomendaciones con enlaces directos a la solución.
• robots.txt para IAs: Desde la pestaña Extras puedes añadir reglas para cualquiera de los más de 50 crawlers que monitoriza. Un panel visual te permite ver tu robots.txt y detecta qué crawlers ignoran tus reglas.
• Bloqueo de rastreadores: Además del robots.txt (que es consultivo), VigIA permite bloquear mediante PHP, que devuelve un error 403 e impide el acceso realmente, respete o no las reglas el bot.
• Generador de llms.txt: Selecciona qué tipos de contenido incluir, filtra por categorías o etiquetas, incluye o excluye contenido manualmente, y genera automáticamente los archivos llms.txt y llms-full.txt. Si usas Yoast SEO, Rank Math, AIOSEO, SEOPress o The SEO Framework, detecta automáticamente el contenido marcado como noindex y lo excluye. Puedes configurar regeneración automática diaria, semanal o mensual.
• Markdown for Agents: Actívalo y cada entrada y página de tu web tendrá automáticamente su endpoint .md. Admite negociación de contenido, respeta las reglas de bloqueo (los crawlers bloqueados reciben un 403) y las exclusiones del llms.txt. Sigue el estándar de Cloudflare y la descubribilidad se gestiona mediante cabeceras link y etiquetas <link rel="alternate"> en el HTML.
• JSON-LD con AI Discovery: Genera el marcado de identidad del sitio (WebSite + Organization o Person con perfiles sociales) y las señales AI Discovery con ReadAction apuntando a tus llms.txt y endpoints Markdown. Incluye detección de conflictos con plugins SEO, selector de página de salida y vista previa en tiempo real del JSON-LD generado.
• Alertas por email: Informes diarios, semanales o mensuales con resumen de actividad de rastreadores.

Y un detalle extra muy interesante es que si también tienes AI Share & Summarize instalado puedes ver en la analítica de VigIA cuántos clics recibe cada página desde los botones de compartir, cruzando los datos con los de rastreo de IAs.

Son datos cruzados de plugins que se complementan para ayudarte a tener control sobre este mundo (hasta ahora más lleno de lagunas que de certezas) de la visibilidad en las IAs.

AI Share & Summarize: entrena TÚ a la IA

AI Share & Summarize cubre la señal activa, los botones de compartir con IAs. Instálalo, elige qué botones mostrar y dónde, y ya está.

Tus visitantes podrán compartir y resumir tu contenido con ChatGPT, Claude, Gemini, Grok, Perplexity y más IAs, además de las redes sociales habituales.

Tienes control total sobre la posición (antes del contenido, después, ambas), qué botones mostrar, en qué tipos de contenido aparecen, y un shortcode para colocación manual si lo prefieres.

AI Content Signals

AI Content Signals añade las directivas de uso por parte de IAs en robots.txt. Instálalo, elige si permites el uso de tu contenido para entrenamiento, para búsqueda, o para ambos, y el plugin se encarga de añadir las directivas correspondientes.

Los tres son gratuitos, están en WordPress.org, y juntos cubren todos los mecanismos disponibles a día de hoy para que tu web WordPress sea lo más visible posible para las inteligencias artificiales.

Cómo interpretar la puntuación

Independientemente de la herramienta que uses, la mayoría te dará una puntuación numérica, lo importante es saber qué hacer con ella.

No te obsesiones con llegar a 100 o a la nota perfecta, lo que importa es tener bien cubiertas las áreas de más peso, me refiero al acceso y descubrimiento IA, y los datos estructurados. Si esas dos están bien ya llevas más de la mitad del camino.

Si tu puntuación está por debajo del 50% lo más probable es que te falten cosas básicas como un robots.txt sin configurar para bots de IA, sin schema JSON-LD, sin sitemap o con un sitemap que incluye páginas que no deberían estar (carrito, checkout, cuenta de usuario…). Son cosas que se arreglan rápido y que suben la nota de golpe.

Si estás entre 50 y 75, los fundamentos los tienes pero te faltan las señales más específicas, probablemente no tienes Markdown para agentes, ni botones de compartir y resumir, ni el JSON-LD optimizado para descubrimiento IA. Son un a más.

Si estás por encima de 75, ya estás bastante bien. Las mejoras a partir de aquí son de afinación, como optimizar el TTFB, revisar que todos los textos alternativos de las imágenes sean descriptivos, comprobar que no haya Schema duplicado, etc.

Un consejo que vale para cualquier herramienta es que analices tanto tu página de inicio como las páginas de contenidos individuales, sean artículos, productos o lo que sea que realmente sea de relevancia en tu web. La puntuación puede variar mucho entre una y otra porque las señales que aplican son diferentes.

Consejos para ir ganando visibilidad

• Empieza por saber dónde estás: Pasa cualquiera de las herramientas que hemos visto, apunta tu puntuación y lee las recomendaciones. No intentes arreglarlo todo a la vez, prioriza lo que más impacto te va a dar con menos esfuerzo: normalmente es la configuración de robots.txt, el schema básico y el sitemap.
• Vigila quién te visita: Tener monitorización de rastreadores de IA activa desde el primer día te va a dar datos muy útiles. Saber que PerplexityBot pasa tres veces al día por tus tutoriales pero ignora tu tienda, por ejemplo, te dice mucho sobre qué contenido reforzar.
• No bloquees a ciegas: Antes de bloquear rastreadores, observa unas semanas. Hay diferencia entre bots que rastrean para citarte (los de búsqueda, como ChatGPT-User o PerplexityBot) y los que rastrean para entrenar sus modelos (GPTBot, ClaudeBot, Google-Extended). Los primeros te convienen, los segundos ya decides tú.
• Prioriza Markdown para Agents sobre el llms.txt: Si tienes que elegir por dónde empezar con las señales nuevas, Markdown for Agents es la que más impacto real tiene. Los bots de IA, cuando tienen disponible un endpoint Markdown, lo prefieren al HTML completo. Es algo que he comprobado de primera mano: el cambio es inmediato. El llms.txt créalo también, no cuesta nada, pero el que de verdad mueve la aguja es el Markdown.
• Las «cápsulas de respuesta» funcionan: Las primeras 50 a 70 palabras de cada artículo o página importante deberían responder directamente a la consulta que se supone que responden. Las IAs extraen principalmente las primeras líneas. Nada de párrafos de introducción vacíos antes de llegar al grano, responde primero, desarrolla después.
• Revisa tu Schema con regularidad: Instalar un plugin de SEO y olvidarte no es suficiente. Valida periódicamente con la herramienta de resultados enriquecidos de Google que no tengas errores, duplicados ni ningún Schema que no coincida con el contenido visible.
• Vuelve a analizar después de cada cambio importante: Cambio de tema, actualización de plugin SEO, reestructuración de contenido, migración de hosting, etc. Cualquier cambio gordo merece una comprobación para asegurarte de que no has roto nada.
• Combina herramientas si puedes: Un analizador técnico te dice si estás preparado, un monitor de marca te dice si ya apareces, son complementarios. Usa el analizador para mejorar tu web y, de vez en cuando, comprueba con un monitor de marca si tus esfuerzos están dando frutos en las respuestas de ChatGPT, Gemini o Perplexity.

Antes de pagar prueba lo que tienes gratis

Quiero terminar con algo que me parece importante y que va más allá de herramientas y puntuaciones. Hazme caso o no, pero si tienes que leer algo de todo este tocho que sea este último.

Llevo años viendo cómo el tráfico orgánico se desploma para mucha gente. Amigos, clientes, o simples conocidos que llevan años creando contenido, que dependen de ese tráfico para sacar adelante su negocio, su proyecto, sus facturas.

Eso no es cosa de broma, y me da mucha rabia que desde el minuto cero haya gente queriendo sacar dinero a su costa con técnicas que no están del todo probadas, vendiendo auditorías y consultorías sobre algo que todavía estamos todos aprendiendo.

Esa rabia es precisamente lo que me llevó a crear VigIA (y también AI Share & Summarize y toda esta batería de plugins para IA) y a compartirlos gratis.

Los hice primero para mí, para entender qué estaba pasando en mis propias webs, para ver de verdad qué bots me visitaban, qué contenidos les interesaban, si respetaban mi robots.txt o no. Y cuando vi que funcionaba y que me daba respuestas útiles, pensé que lo mínimo que podía hacer era compartirlo para que otros pudieran hacer lo mismo sin tener que pagar nada.

Cada funcionalidad nueva que añado a VigIA es algo que otros cobran. El generador de llms.txt, el Markdown para agentes, el JSON-LD con AI Discovery, el analizador de visibilidad, todas son de pago en otras herramientas.

Yo lo ofrezco gratis porque creo que la gente merece poder entender lo que está pasando con su web antes de abrir la cartera. Igual es que yo soy muy pesetero, o que tengo conciencia de freelance autónomo, pero es como pienso.

Mi consejo, y no me importa ser pesado en esto, es que antes de pagar por cualquier servicio de «optimización para IA» instales las herramientas gratuitas y mires los datos.

Instala VigIA, revisa qué bots te visitan, qué páginas les interesan, cuál es tu puntuación de visibilidad. Instala AI Share & Summarize y mira los clics que generan los botones para saber qué plataformas usan tus lectores. Revisa las estadísticas, entiende lo que está pasando en tu web, y entonces, ya con datos de verdad, decide si necesitas pagar por algo más o si con lo que ya tienes puedes ir avanzando.

Lo que he aprendido después de meses monitorizando bots de IA es que, al final, lo que quieren es bastante sencillo, ho hay en realidad grandes cambios. Entrega un sitemap limpio para encontrar tu contenido, acceso sin trabas a las páginas que les interesan, una versión Markdown si la tienes (les encanta).

Sobre todo no olvides lo fundamental, que es el contenido que ni Google ni las IAs tienen, han tenido ni tendrán nunca, escrito por alguien que sabe de lo que habla en carne propia. No hay fórmula mágica de GEO ni servicio premium que sustituya eso.

El mundo de la búsqueda ha cambiado a toda hostia.

Millones de personas ya usan ChatGPT, Perplexity, Claude o Gemini como alternativa a Google para buscar información, y los que usan Google hace mucho que ya no hacen clics, Que tu web esté preparada para esa realidad no es algo que puedas dejar para mañana.

Tu verás, pero yo creo que no pierdes nada si pruebas VigIa, lo tienes en WordPress.org o en tu instalador de plugins, y empieza por conocer tu puntuación y a saber qué está pasando en tu web en lo que se refiere a las IAs.