Category: WordPress

¿Cuándo fue la última vez que revisaste los ajustes de tu WordPress uno por uno? Casi todos damos por hecho que la configuración de fábrica estará bien. Pero son ajustes genéricos: no saben qué tipo de web tienes, qué necesita tu negocio ni cómo quieres que funcione.

En el webinar “Configuras mal WordPress” entré en el panel de control de WordPress y repasé en directo los ajustes que trae de serie, antes de instalar ningún plugin. Esto es lo que mostré: cómo configurar bien WordPress desde el principio, qué cambiar para tu seguridad, tu SEO y la privacidad de tus usuarios, y qué no tocar nunca.

¿Prefieres leer los puntos clave? Sigue abajo.

Por qué los ajustes por defecto no son los tuyos

Hablamos mucho de rendimiento, de seguridad y de IA, pero muchas veces es una chorrada que tienes ahí en tu instalación de WordPress y que no tienes bien configurada. WordPress lleva casi 25 años funcionando, y eso nos lleva a fiarnos de que todo viene bien de fábrica.

Pero los ajustes por defecto tienen que valer para la generalidad, y ninguna web lo es. No es lo mismo un blog personal que una tienda o la web de un despacho de abogados.

Ajustes generales: qué tocar y qué dejar en paz

Título y descripción corta. WordPress pone “Mi WordPress” como título y no añade descripción. Sin plugin de SEO, esas dos cajas forman el título SEO por defecto de cada página, así que conviene definirlas antes de empezar.

Dirección de WordPress y del sitio. Son para romper la web, básicamente: si cambias una barra o pones otro dominio, deja de funcionar. Solo se tocan en una migración o en casos muy especiales. Para mí es la antesala del desastre: prohibido, prohibido, prohibido tocar.

Zona horaria. Parece un ajuste visual, pero afecta a la programación de entradas: con la zona mal elegida, algo que programas para las 9 puede salir con dos horas de diferencia. En un post da igual, en una oferta con precio no. Elige tu continente y tu ciudad, y el cambio entre horario de verano e invierno se hará solo.

Registro de usuarios y rol por defecto. Si activas “cualquiera puede registrarse”, pregúntate para qué. En una tienda no hace falta, porque WooCommerce tiene su propio registro. Y si la casilla está marcada sin necesidad, desmárcala: hay bots que se registran automáticamente para buscar vulnerabilidades. El perfil por defecto, salvo casos especiales, es siempre “suscriptor” (en una tienda, “cliente”).

Ajustes de escritura y lectura

En Ajustes de escritura, olvídate de todo lo que va de “publicar por correo electrónico” hacia abajo: es una cosa vieja, caduca e inútil. Lo único útil es la categoría por defecto de las entradas: si no eliges una, WordPress usa “Sin categoría”, que queda feo. Crea antes una categoría (por ejemplo “Noticias” o “Blog”) y selecciónala aquí.

En Ajustes de lectura decides qué muestra tu portada: tus últimas entradas o una página estática que diseñes tú. Si no tienes blog, no pongas nada como página de entradas. En los listados, máximo 10 entradas por página. Y en los feeds RSS, muestra como mucho cinco y elige “extracto” en lugar de “texto completo”: así quien te lea en una app externa tiene que entrar en tu web para seguir leyendo.

El ajuste que puede sacar tu web de Google

En Ajustes de lectura hay una casilla que pide a los motores de búsqueda que no indexen tu sitio. Dice que depende de ellos atender la petición, pero te lo aseguro: lo hacen, en la práctica el 99,9 % de las veces.

Lo demostré en directo. Al marcarla, el mapa del sitio desaparece, y en el código fuente de cualquier página aparece una etiqueta meta robots con noindex, que pide a cualquier bot, de buscadores o de IA, que no indexe esa URL. Si habías declarado tu mapa del sitio en Google Search Console, ya no lo encontrará. Es un problemón.

Sirve mientras diseñas la web con contenido de demostración. Lo que hay que recordar es quitarla en cuanto termines el diseño, sin esperar a tener cien entradas. Pasa muchísimo, y a veces quien te hizo la web se la deja marcada: revísala aunque tu web lleve tiempo online.

Ajustes de comentarios: la página con más trampas

Es de las pantallas más malentendidas de WordPress, y su configuración por defecto está mal, ya lo anticipo.

Pingbacks y trackbacks

Los dos primeros ajustes (avisar a los blogs enlazados y permitir avisos de otros blogs) son un sistema antiguo: una puerta abierta de salida y otra de entrada que, si no vigilas, deja entrar lo que no esperas. Mi consejo es desactivarlos en el 100 % de los casos. Esa puerta se llama XML-RPC; desmarcar estos ajustes no la apaga del todo, pero cierra una parte. La guía de primeros pasos de SiteGround recomienda lo mismo. Y si no vas a tener comentarios, desactívalos desde aquí en lugar de ir entrada por entrada.

Aunque los tengas activos, mi recomendación es no marcar nada que no estés seguro de necesitar. Los casos más claros: no obligues a rellenar nombre y correo (no sabes quién escribe, sabes quién dice que te escribe), quita los comentarios anidados y la paginación (genera una URL por cada 50 comentarios) salvo que tengas una comunidad, y desactiva los avatares, que son una consulta externa a Gravatar y un problema de privacidad. No pienses que porque viene activo por defecto es bueno. En webs de noticias, que caducan en días, cierra además los comentarios de las entradas antiguas: el tráfico que llega semanas después suele ser spam.

Aprobar los comentarios a mano

Para ahorrarte un plugin, marca “el comentario debe aprobarse manualmente”. Todos quedan pendientes y WordPress te avisa cuando hay alguno. No necesitas ningún sistema automático de comprobación ni llamadas externas a bases de datos de spammers: menos tareas programadas, menos correos, menos consultas, mejor rendimiento.

El comentario previamente aprobado

Este es casi lo más importante de la charla. El ajuste “el autor debe tener un comentario previamente aprobado” viene activado por defecto. Lo probé en directo: un usuario deja un primer comentario, queda pendiente, el administrador lo aprueba, y el siguiente comentario de ese usuario sale publicado sin moderación. Es el hueco que se aprovecha para colar scripts que comprometen tu seguridad.

Un último detalle: si exiges registro para comentar, permite también el registro en Ajustes generales. Lo comprobé en una ventana de incógnito: si no, el visitante ve que debe conectarse para comentar pero no tiene forma de registrarse.

Medios y enlaces permanentes

Tamaños de imagen. Cada vez que subes una imagen, WordPress genera varias copias: una de 2.560 píxeles si la original es mayor, y otras tres con los tamaños por defecto (grande, medio y miniatura). Ocupan espacio en tu hosting sin que lo sepas. Si solo usas el tamaño completo o el grande, pon a cero los que no uses y dejarán de crearse. Los temas y plugins como WooCommerce añaden además los suyos.

Enlaces permanentes. En una web en marcha, aquí no se toca: cambias cómo se forman todas las direcciones, y quien tuviera enlazada la URL anterior recibirá un error 404. Lo comprobé en directo añadiendo “.html” a la estructura. Deja “Nombre de la entrada”. Y si alguien te dice que otra estructura es mejor para el SEO: llevo 25 años en internet y no he visto ninguna web que gane a otra por haber cambiado la URL. Nadie lee las URLs; la gente hacemos clics, como mucho.

Privacidad y datos personales

Te recomiendo crear siempre la página de privacidad, aunque tu legislación no te obligue, y no usar la que viene por defecto. WordPress ya está preparado para exportar y borrar datos personales (en Herramientas), pero tienes que explicar en tu página de privacidad cómo pueden pedirlo tus usuarios. Si quieres repasar qué exige la normativa, tienes la guía para cumplir con el RGPD en WordPress.

Lo que WordPress no hace es registrar todos los consentimientos: cuando alguien acepta las cookies, no guarda qué aceptó exactamente. Para eso hace falta un plugin. Yo creé uno, “Registro de consentimientos“, gratuito, que guarda cada aceptación y el texto concreto aceptado. La barra de cookies también necesita un plugin sí o sí.

Además, cada vez que actives un plugin, pásate por la pestaña “Guía de la política de privacidad”: los que recopilan datos te sugieren el texto que debes añadir (le pasa, por ejemplo, a Akismet).

Usuarios: contraseñas, admin y nombre público

WordPress no te obliga a usar contraseñas fuertes: puedes poner cualquier cosa y confirmar que usas una débil. Refuérzalo con un plugin. Y al crear un usuario:

• Evita que se llame admin. Algunos hostings lo crean por defecto y así regalas la mitad de la información para entrar. En SiteGround no pasa. Hay más medidas en 5 pasos simples para mejorar la seguridad de WordPress.
• Elige un “nombre para mostrar públicamente” distinto del nombre de acceso, que no se puede cambiar. Si son iguales, la URL de publicaciones de ese usuario muestra su nombre de acceso.

Trucos del editor

Para terminar, mi parte favorita: el editor.

• Vista de lista: te mueve y selecciona bloques mucho más rápido y sin errores. En las preferencias puedes dejarla siempre abierta.
• Esquema: muestra caracteres, palabras, tiempo de lectura y la estructura de títulos. Antes de publicar, pasa por aquí: si saltas de un H2 a un H5, la estructura no es correcta.
• Vista de móvil: cambia la previsualización de escritorio a móvil para evitar el efecto ladrillo. Un párrafo que parece pequeño en escritorio es enorme en el móvil: separa en frases más cortas.
• Extracto: el resumen que muestra el tema en la portada y que usan WordPress, los buscadores y las IA. En el título se lo presentas y en el extracto le describes de qué va todo. Los plugins de SEO lo usan además para la meta descripción.

Preguntas durante el webinar

Diez minutos para revisar tu WordPress hoy

1. Ajustes > Generales: define título y descripción corta, y comprueba la zona horaria.
2. Ajustes > Generales: no toques las direcciones y desmarca el registro abierto si no lo necesitas.
3. Ajustes > Lectura: desmarca “no indexar” y pon los feeds en extracto.
4. Ajustes > Comentarios: desmarca pingbacks y trackbacks y marca “aprobar manualmente”.
5. Ajustes > Medios: pon a cero los tamaños que no uses.
6. Ajustes > Enlaces permanentes: “Nombre de la entrada”, y no lo cambies si la web ya está en marcha.
7. Ajustes > Privacidad: revisa tu página y la guía de la política.
8. Usuarios: ningún admin y un nombre público distinto del de acceso.

En resumen

Los ajustes por defecto de WordPress valen para cualquiera, y por eso no valen del todo para ti. Dedicarles diez minutos evita quedarte sin tráfico por una casilla marcada, llenarte de spam o dejar puertas abiertas que nadie vigila.

Si quieres empezar con un buen punto de partida, SiteGround ofrece hosting WordPress con su plugin Speed Optimizer. Y si te interesa la seguridad con IA, tienes el post del webinar de seguridad de septiembre.

El 17 de julio de 2026, un investigador de seguridad cogió una instalación de WordPress totalmente limpia. Sin plugins. Sin temas de terceros. La versión estable más reciente, tal cual sale de fábrica.

Le entregó esa copia a un modelo de IA y le pidió que la auditara.

En cuestión de horas tenía una vulnerabilidad crítica de ejecución de código sin necesidad de iniciar sesión, que encadenada con un segundo fallo (hallado por otro equipo de investigadores) permitía tomar el control total del servidor. Una barbaridad, en una instalación de WordPress sin nada que la hiciera vulnerable salvo el propio núcleo.

Al día siguiente, ya había gente explotándolo.

De esto hablé el 8 de septiembre en un webinar con SiteGround y esto es lo que aprendimos.

¿Prefieres leer los puntos clave? Continúa abajo.

El WordPress limpio que cayó por unos pocos dólares

El investigador se llama Adam Kues, de la firma de seguridad Searchlight Cyber, y fue quien encontró la vulnerabilidad de ejecución de código (CVE-2026-63030). El fallo se conoce ahora como WP2Shell, y encadenado con una segunda vulnerabilidad de inyección SQL (CVE-2026-60137, hallada por otro equipo de investigadores) permitía tomar el control total de una instalación de WordPress sin plugins ni temas de por medio.

Encontrar y montar el ataque completo llevó 10 horas y 25 dólares en tokens de IA. Ya no hace falta ser especialista ni pasarse semanas de trabajo: con un poco de tiempo y una inversión ridícula, cualquiera llega al mismo sitio. Llevo más de 20 años trabajando con WordPress, y esta es la primera vez que veo algo así de bruto.

La firma de seguridad Patchstack detectó y reprodujo uno de los dos fallos a los pocos minutos de hacerse público, y publicó cifras que conviene tener en la cabeza: una vulnerabilidad grave tarda de media 5 horas en empezar a explotarse masivamente una vez que se hace pública, no días. Y el 46% de las vulnerabilidades de plugins no tienen parche del desarrollador el mismo día en que se hacen públicas.

Qué ha cambiado en seguridad WordPress (y qué no)

Lo que cambió: la velocidad

Antes, encontrar un fallo así requería a alguien con conocimiento técnico profundo y semanas de trabajo. Ahora, cualquiera con acceso a un modelo de IA y una tarde libre puede llegar al mismo sitio en horas.

Eso cambia una cosa muy concreta: el tiempo que tienes para reaccionar cuando sale un parche de seguridad. Y el matiz que más se pasa por alto es este: el aviso real es el propio parche, no el anuncio que la empresa de seguridad publica en su blog treinta días después.

En el momento en que un desarrollador publica una actualización de seguridad para su plugin, esa actualización ya es pública en WordPress.org. Cualquiera puede comparar el código antes y después y deducir qué agujero estaba tapando, sin esperar a que nadie lo anuncie. Cuanto más tardes tú en actualizar WordPress sin que se rompa nada, más tiempo pasas expuesto.

Lo que no ha cambiado: los fallos de siempre

Aquí va lo que probablemente no esperabas escuchar en un webinar sobre IA y seguridad: los fallos de código siguen siendo exactamente los mismos cuatro de siempre. Nonces (formularios que no comprueban de dónde sale la petición), capacidades (acciones de administrador al alcance de un perfil de suscriptor), escape (salida sin escapar, la puerta de entrada del cross-site scripting) y consultas (SQL montado a mano sin preparar, la inyección de toda la vida).

Como resumo en una de mis diapositivas:

“La IA ha cambiado la velocidad y la escala, no las puertas.”

Y las puertas de entrada tampoco han cambiado: plugins sin actualizar, contraseñas repetidas, administradores de más, y ausencia de copias de seguridad.

Cuando WordPress.org también se defiende: Protect the Shire y Gandalf

En abril de 2026, WordPress sufrió uno de sus peores ataques a la cadena de suministro: alguien compró un lote de 30 plugins gratuitos en Flippa, la plataforma de compraventa de software, y en la siguiente actualización les coló un troyano. Durante ocho meses, ese código funcionó sin que nadie se diera cuenta. Cuando se activó, en 6 horas y 44 minutos ya tenía control administrativo sobre miles de webs. WordPress.org acabó cerrando 31 plugins, que en conjunto sumaban más de 400.000 instalaciones activas.

La respuesta de WordPress.org llegó dos meses después, coincidiendo con WordCamp Europe en Cracovia: Matt Mullenweg anunció Protect the Shire, una iniciativa que impone una ventana de revisión obligatoria antes de que cualquier actualización de plugin o tema llegue a los sitios con actualizaciones automáticas activadas. Esa ventana empezó en 24 horas el 5 de junio y, el 16 de julio, ya se había reducido a solo 6, sin ningún anuncio público: se comunicó en un canal de Slack interno del equipo de plugins.

Durante esas horas, una herramienta de revisión asistida por IA —bautizada como Gandalf, en honor a El Señor de los Anillos— analiza los cambios de código en busca de patrones maliciosos antes de que lleguen a nadie.

Eso no convierte a las actualizaciones automáticas en un riesgo mayor: significa que ahora hay alguien (o algo) revisando el código antes de que te llegue.

Las cuatro capas de seguridad que ya tienes, aunque no lo sepas

Lo resumo en cuatro capas mínimas, y ninguna te protege por sí sola: red, servidor, WordPress y vigilancia. Esta última es distinta a las otras tres: no protege, solo te dice qué ha cambiado y desde cuándo.

Capa 1: la red y la CDN

Parar los ataques lo más lejos posible de tu web, a nivel de red. En SiteGround, la CDN se activa con un clic desde Site Tools, sin tocar servidores de nombres ni DNS. La alternativa es Cloudflare, gratuita, pero requiere cambiar el servidor de nombres. Y en España tiene un problema curioso: cada vez que hay un partido de fútbol importante, el pico de tráfico le tira la web a mucha gente que la usa.

Capa 2: el servidor y el hosting

Aislamiento de cuentas (para que lo que le pase a la web de al lado en un servidor compartido no te afecte), cortafuegos a nivel de servidor con reglas que a veces se adelantan al propio parche del plugin, escaneo diario completo de todos tus archivos, copias de seguridad diarias guardadas en un centro de datos distinto al de tu web, y un escáner antibot gestionado con IA que aprende del tráfico de toda la red de clientes: si alguien más ya sufrió un ataque, tu web se beneficia de esa detección antes de que te toque a ti. Todo esto funciona aunque no hayas entrado nunca en el panel.

Desde Site Tools puedes activar seis ajustes más, gratis: verificación en dos pasos, gestor de claves SSH, control de versión de PHP, entornos de pruebas (staging), copias de seguridad manuales y actualizaciones automáticas seguras. El primero es el que más se olvida, y es la llave maestra de todo lo demás: desde ese panel se cambian contraseñas, se toca la base de datos y se restauran copias.

Capa 3: WordPress y el plugin de seguridad

Aquí entra Security Optimizer, el plugin de seguridad instalado por defecto en SiteGround (y que funciona igual esté tu web en SiteGround o no). Viene configurado con un equilibrio pensado para no romper nada, así que hay ajustes que activaría sin pensarlo: verificación en dos pasos para administradores, límite de intentos de acceso, bloqueo de nombres de usuario comunes, editor de temas y plugins desactivado, protección contra XSS, registro de actividad, y XML-RPC bloqueado si no lo usas.

Para quien quiera ir un paso más allá, desarrollé Vigilante, un plugin más completo con comprobación en listas de spam, registro de actividad completo, auditoría de seguridad permanente, supervisión de integridad de archivos, reglas de contraseñas, cabeceras de seguridad y modo bajo ataque.

Capa 4: la vigilancia, con ayuda de IA

Los clientes de SiteGround tienen acceso a un agente de IA especializado en WordPress, sin necesidad de configurar ninguna clave API, que puede auditar la web entera: analizar carencias de seguridad, recomendar refuerzos, y valorar si los plugins y temas instalados son los adecuados. Como el resto de esta capa, no protege por sí solo: te dice qué ha cambiado y desde cuándo, para que decidas tú qué hacer.

El mito de que pagar por un plugin te hace más seguro

Hay una creencia extendida: los plugins de pago son más seguros porque su código no está expuesto públicamente como el de los gratuitos en WordPress.org. La realidad es la contraria: los plugins de pago tienen el triple de vulnerabilidades con explotación confirmada que los gratuitos, y el 76% de las que se encuentran en componentes de pago son explotables en ataques reales.

¿Por qué? Porque el código de un plugin gratuito del repositorio lo puede leer cualquiera, y de hecho lo hacen: usuarios que le pasan sus propios escáneres, plugins de seguridad, IA buscando fallos. El código de un plugin de pago, en cambio, no lo leía nadie de fuera, hasta ahora: un atacante compra la licencia por 69,99€ y se la pasa directamente a su IA. Cuantos menos ojos revisando un plugin, más tarda en aparecer el fallo, y más tiempo lleva sin corregir cuando por fin se encuentra.

Ojo con lo que le permites hacer a la IA

WordPress ya trae de serie una pantalla de conectores para enlazar agentes de IA (Anthropic, Google, OpenAI y otros) a tu web, y eso trae responsabilidades nuevas que conviene tener en la cabeza:

• Las claves quedan en la base de datos. Si te entran, ya no solo se llevan la web: se llevan también tu clave de API, y te dejan a ti pagando la factura.

• Los agentes heredan los permisos que les des. Un agente al que solo le pides que modere comentarios ya está leyendo texto escrito por cualquiera que pase por tu formulario de contacto.

• Cualquier contenido puede llevar instrucciones escondidas. Comentarios, formularios, feeds importados, descripciones de proveedores: todo eso es texto que tu IA puede leer y, sin querer, obedecer.

Cuento una anécdota que se volvió viral y resume el problema perfectamente: alguien descubrió que podía pedirle al chatbot de atención al cliente de McDonald’s que le enseñara a programar en Python mientras hacía un pedido. El bot, sencillamente, respondía.

¿Por qué funciona esto? Porque nadie le dijo explícitamente que no lo hiciera. La IA hace lo que le dices que haga, y también hace lo que no le digas que no haga. Ojo con eso.

Es la misma lógica que aplica a cualquier agente de IA que conectes a tu WordPress: definir qué puede hacer no es suficiente. Hay que ser igual de explícito sobre qué no puede hacer.

Cinco tareas para ¡ya!

Lo dejo como tarea, y ninguna te llevará más de diez minutos (aquí tienes otras tareas para reforzar la seguridad si quieres seguir después):

1. Activa la verificación en dos pasos en el panel de tu hosting.
2. Quita los administradores que sobran. Si ves a alguien que no reconoces, bórralo.
3. Comprueba que WordPress se actualiza solo. Ahí no hay riesgo de cadena de suministro: es el propio equipo de WordPress.org el que gestiona esas actualizaciones.
4. Crea y restaura una copia de staging. Una copia de seguridad no es real ni está completa hasta que no la has comprobado: crea una web nueva, hazle cualquier cambio y, al día siguiente, restaura la copia para ver si te deja la web como estaba el día anterior.
5. Elimina los plugins que no uses. Cada uno es una puerta más que vigilar.

Y si nada de esto llega a tiempo y crees que ya te han entrado, tengo una guía aparte sobre qué hacer si tu web ha sido hackeada.

El problema nunca es la herramienta:

“Utilizamos un cuchillo para matar a alguien y utilizamos un cuchillo para cortarnos un bocadillo. El problema nunca es la herramienta, es el uso que hagamos de ella. Y también tenemos la herramienta para protegernos.”

Preguntas del webinar

¿Quieres que tu WordPress tenga estas cuatro capas desde el primer día?

Security Optimizer viene instalado por defecto en todos los planes de hosting de SiteGround, junto con CDN de un clic, cortafuegos de servidor, aislamiento de cuentas y copias de seguridad diarias.

Y si prefieres repasar lo básico desde cero, aquí tienes mis 5 sencillos pasos para mejorar la seguridad WordPress.

El 30 de junio hablé con el equipo de SiteGround sobre algo que llevo tiempo queriendo decir: hay demasiado ruido alrededor del SEO con IA y muy poca chicha. Aquí va lo que de verdad funciona, sin rodeos.

El SEO no ha muerto, ha mutado

Que levante la mano quien no haya visto caer su tráfico en los últimos años. El problema no es que el SEO haya muerto: es que ya no estamos hablando de un motor de búsqueda, sino de un motor de respuestas. Google, ChatGPT, Perplexity… responden directamente. No te mandan a la web.

El contenido informacional (el típico “cómo hacer X” o “qué es Y”) está llamado a desaparecer tal como lo conocíamos. Las IAs lo responden sin mandarte a ningún sitio. Eso es una realidad desde hace más de tres años, y el que todavía no haya notado la bajada en su tráfico, o vive en un nicho muy concreto, o simplemente aún no se ha dado cuenta.

Esto no significa que el contenido ya no valga nada. Significa que hay que cambiar qué tipo de contenido creamos y cómo lo optimizamos.

📺 Si quieres ver el webinar completo, lo tienes disponible en YouTube:

Los 5 errores más habituales en WordPress (y cómo la IA los detecta en minutos)

Cuando tuve que revisar mi propio blog para entender qué había pasado con mi tráfico, identifiqué cinco errores que se repiten en casi cualquier WordPress. Los divido en dos grupos:

Errores de contenido

• Canibalización: tienes dos o más páginas compitiendo por la misma búsqueda. Los motores de respuesta no saben a cuál apuntar, así que hacen un resumen de las dos o no te citan a ninguna.
• Contenido flojo o sin estructura: sin encabezados correctos, sin jerarquía clara. Difícil de leer para humanos y para robots.
• Contenido duplicado: sin valor diferencial. Relleno que no aporta nada a nadie.

Errores técnicos

• Metadatos vacíos o copiados: las IAs, exactamente igual que los buscadores tradicionales, se organizan a base de metadatos. Tu title tag y tu meta description tienen que ser descriptivos, únicos y semánticos.
• Imágenes sin texto alternativo: si el bot no puede leerlas, no existen para él.

La buena noticia: la IA detecta todo esto en segundos. Lo que antes era una auditoría de días, ahora es una lista priorizada en minutos.

Qué puede hacer la IA por tu SEO (y qué no puede hacer)

Esto es importante porque veo mucha gente esperando que la IA haga magia.

Sí puede:

• Detectar metadatos que faltan o están duplicados
• Identificar imágenes sin alt text de forma masiva
• Auditar todas tus URLs y detectar canibalizaciones
• Analizar la estructura de encabezados
• Proponer mejoras de título y meta description a partir de datos reales
• Cruzar tu Google Search Console con tu contenido y priorizar qué mejorar primero

No puede:

• Conseguirte enlaces externos
• Saber exactamente por qué Google te posiciona donde te posiciona (cada vez es más opaco)
• Predecir el futuro algorítmico
• Reemplazar tu criterio editorial

La IA propone. Tú dispones. Siempre. Tu experiencia, tu conocimiento del mercado y lo que te da el dinerito no lo puede reemplazar ninguna máquina.

Cómo usar SiteGround AI Studio para el SEO

SiteGround tiene integrado AI Studio directamente en el panel, con tres agentes especializados: el SEO Expert, el Copywriter y el agente de WordPress. Para el SEO, este último es, en mi opinión, la herramienta más útil de las tres. Si no lo conocéis todavía, aquí tenéis el post de presentación de AI Studio.

El flujo que yo sigo:

1. Agente Experto en SEO con datos de Google Search Console: exporto mi CSV de Google Search Console, se lo paso y le pido que analice páginas con muchas impresiones pero CTR bajo, palabras clave que apuntan a la misma URL (canibalización), y URLs de competidores donde no estoy presente.

2. Agente de WordPress para la ejecución: con ese análisis en mano, le digo al agente de WordPress que trabaje directamente sobre mi web: que revise títulos, meta descriptions, que busque imágenes sin alt, que analice la estructura de encabezados. Consejo importante: no le sueltes todo de golpe. Una cosa a la vez, comprueba que está bien hecha, y luego la siguiente. La primera vez que lo ejecuté sobre mi propio blog y vi los resultados en tiempo real, pensé: esto es una ventaja injusta.

3. Medición: Google Search Console y Bing Webmaster Tools. Punto.

Una aclaración para los que no tenéis el hosting en SiteGround: podéis usar AI Studio igualmente, instalando el plugin en vuestra web externa y conectándolo con vuestra cuenta de AI Studio. No necesitáis claves de API propias: los agentes usan los tokens incluidos en vuestro plan de SiteGround, exactamente igual que si el hosting estuviera aquí. Y si usáis los conectores de IA de WordPress, sabed que están disponibles desde WordPress 7.0, que trajo los cambios más importantes de los últimos años.

AEO: optimizar para motores de respuesta

Si solo hacéis una cosa diferente después de leer este artículo, que sea esta: optimizar para los motores que responden directamente sin mandaros a ningún sitio. Ese concepto se llama Answer Engine Optimization (AEO), aunque algunos lo llaman GEO, Generative Engine Optimization. El nombre da igual. La idea es que ChatGPT, Gemini, Perplexity y el AI Overview de Google necesitan leer vuestro contenido de una manera específica para citaros.

¿Cómo se optimiza para ellos?

• Contenido bien estructurado y muy claro: encabezados semánticos, resúmenes al principio de cada artículo, secciones de preguntas frecuentes.
• Autoría reconocible: el E-E-A-T importa más que nunca. Las IAs necesitan saber que la fuente merece ser citada.
• Datos estructurados (Schema.org): el mismo estándar de siempre, pero ahora más crítico. Person, Article, FAQPage… son los datos que los bots leen antes que nada.
• llms.txt: una especie de sitemap orientado a IAs. Hace un año no lo recomendaba; ahora empieza a tener sentido implementarlo.
• Cambiar el tipo de preguntas que responde tu contenido: el “cómo hacer X” ya lo responde la IA directamente. Tienes que atacar preguntas que requieran tu opinión, tu experiencia o datos propios que la IA no tiene.

Para todo esto he desarrollado un plugin gratuito: Visibility Quest. Cubre la parte técnica de las señales que los motores de respuesta usan para citarte: datos estructurados, llms.txt, markdown alternativo para agentes… Todo gratuito, todo en WordPress.org.

También he desarrollado Vigía para monitorizar qué bots de IA visitan mi web y qué páginas leen. Las métricas de menciones en IA de herramientas de pago no son fiables (te dan listas distintas cada vez que preguntas), pero sí puedes ver tendencias.

Mi proceso de tres pasos (y por qué tiene que ser un hábito)

1. Auditoría técnica y de contenido on-page: con el agente Experto en SEO y el CSV de Google Search Console.
2. Actuar sobre los resultados: actualizar contenido flojo, fusionar páginas canibalizadas, redirigir lo que no tiene salvación, ampliar lo que está a medias.
3. Medir en Google Search Console y Bing Webmaster Tools: ver si mejoran impresiones, CTR y posición. Repetir cada mes.

El que os venda que con una acción de SEO vais a ver resultados inmediatos, os miente. Esto es constancia.

Las preguntas más interesantes del webinar

En resumen

El SEO no ha muerto. Ha cambiado tanto que parece que ha muerto, pero en realidad el juego ahora es otro: crear contenido con autoridad reconocible, técnicamente impecable, y orientado a responder preguntas que las IAs no sepan o no quieran responder directamente.

Y para eso, la IA es vuestra mejor herramienta. Sí, la misma IA que os está quitando el tráfico informacional es la que mejor puede ayudaros a optimizar lo que queda.

No paguéis por herramientas de SEO de pago hasta que tengáis los fundamentos resueltos. No déis a la IA permiso para escribir por vosotros. Y revisad todo lo que ella proponga.

La IA propone. Vosotros disponéis.

Si queréis empezar hoy mismo: exportad vuestro CSV de Google Search Console y abrid AI Studio. Es el primer paso y está en vuestro panel.

Si queréis ver cómo aplicar esto a una tienda online, tenéis también este webinar sobre cómo automatizar WooCommerce con IA que hicimos hace unas semanas. Y si os interesa el contexto más amplio de por qué la IA está cambiando cómo trabajamos, recomiendo este artículo sobre la democratización de la IA en la Academia de SiteGround.

[97]