Todo eso se puede comprobar, sí, pero queda repartido en media docena de sitios que casi nadie visita (tu perfil de wordpress.org, translate.wordpress.org, los foros de soporte, la API de reconocimientos del núcleo, el directorio de fotos), y cada uno cuenta solo un trocito de tu historia, nunca la historia entera.

Así que me he hecho un regalo, y de paso os lo hago a todos los que contribuís de alguna forma a este proyecto llamado WordPress. Se llama Contributor Résumé, un plugin gratuito que coge todo ese trabajo disperso y lo convierte en un currículum bonito, siempre actualizado, que puedes publicar en tu propia web con un solo bloque.

Vamos a ver qué tiene dentro, cómo lo pones en marcha y por qué para mí esto no es un plugin más.

Un currículum de verdad para quien nos regala su tiempo y conocimiento

La idea es tan sencilla que casi da vergüenza no haberla hecho antes, pues escribes tu nombre de usuario de WordPress.org, compruebas lo que ha encontrado el plugin y publicas tu página. Nada de IDs numéricos, nada de tokens, nada de código. Esto vale igual si traduces, si respondes en el foro, si organizas meetups o si simplemente haces fotos para el directorio, no solo si publicas plugins.

Un único bloque, o el shortcode [contributor_resume] si trabajas con un tema clásico, agrupa decenas de secciones distintas, todas opcionales. Estas son algunas de las que más se van a usar:

• Perfil destacado: tu avatar, tus distinciones reales de wordpress.org y los enlaces a tu web, GitHub y Slack.
• Impacto reciente: tus contribuciones de los últimos 30, 90 y 365 días, con puntuación incluida.
• Eventos: las WordCamps y meetups en las que hablas, organizas o asistes.
• Traducciones: tus idiomas, tus permisos y el número de proyectos en cada uno.
• Soporte: los hilos que has abierto y las respuestas que has dado en los foros.
• Reconocimientos del núcleo: las versiones de WordPress en cuyos créditos aparece tu nombre.
• Plugins y temas: los que has publicado, con sus estadísticas, y los que tienes marcados como favoritos.
• GitHub: tu perfil y tus repositorios con más estrellas, sin necesitar ningún token para verlo.

Y quedan más, porque también incluye fotos del directorio de WordPress con su propia caja de luz, tu compromiso de horas semanales, la biografía con tu historia de origen, los equipos e idiomas de tu comunidad de contribución, y alguna sección más. Decenas de proyectos, cada uno reordenable arrastrando y soltando, y activable o no según lo que quieras enseñar. No está mal ¿no?

Además, que es el único currículum de WordPress real que hay.

¡Es taaan mooonoooo!

Si es que encima es bonito y para (casi) todos los gustos. Tienes tres estilos, uno moderno, uno clásico con aspecto de currículum impreso de toda la vida y uno monoespaciado que parece sacado de una terminal, para quien quiera presumir de friki con estilo.

A eso le sumas claro, oscuro o automático según lo que prefiera quien visita tu web, color de realce propio o heredado del tema, radio de esquinas, sombra, columnas de la cuadrícula y un diseño compacto si prefieres ir al grano. Las estadísticas se animan con un contador que sube según entran en pantalla, y se paran en seco si el visitante tiene activada la reducción de movimiento.

Puedes arrastrar las secciones para reordenarlas, elegir cuántos elementos muestra cada cuadrícula, y probarlo todo con una vista previa en directo, en escritorio y en móvil, sin salir de los ajustes. Y si con eso no tienes bastante, cada plantilla se puede copiar a tu tema y editarla a mano, con variables CSS documentadas bajo el prefijo --cvr-.

Solo tus datos, y ni uno de quien te visita

El plugin lee tus datos públicos de contribución en las URLs oficiales de WordPress.org (y, si añades tu usuario, también en la API pública de GitHub), y nunca recoge ni envía nada de quien entra en tu página. Las páginas públicas no hacen ninguna petición externa, y los avatares y las fotos los carga el navegador de tu visitante directamente desde WordPress.org, Gravatar o GitHub, igual que hace WordPress toda la vida con los avatares de los comentarios.

El único dato que sale de tu servidor es tu nombre de usuario, y solo cuando generas o actualizas el currículum en segundo plano. Si añades un token de acceso de GitHub (opcional, solo para subir el límite de peticiones a su API), se queda guardado en tu web y no se muestra jamás en la parte pública.

Cómo lo pones en marcha en un par de minutos

1. Instala y activa el plugin.
2. Abre «Contributor Résumé» desde el menú de tu cuenta en la barra de admin superior, o desde el enlace de ajustes que aparece junto al plugin en la pantalla de plugins.
3. Escribe tu nombre de usuario de WordPress.org (y, si quieres, el de GitHub) y pulsa «Comprobar y crear mi currículum».
4. Pulsa «Crea mi página de currículum», o añade el bloque (o el shortcode [contributor_resume]) a cualquier página que ya tengas.

Funciona igual de bien con el editor de bloques que con un tema clásico, y si administras varias instalaciones o trabajas con entornos de prueba, wp cresume refresh, wp cresume status y wp cresume clear-cache te dejan gestionar la caché entera desde WP-CLI.

¿Quieres verlo ya?

Tengo mi propio currículum publicado en esta misma web, con casi todas las secciones activadas, así que puedes verlo en marcha antes de instalar nada. Ahí aparecen mis 24 plugins publicados, mis traducciones a 23 idiomas repartidas en 3.416 proyectos, mis 134 hilos abiertos y 856 respuestas en los foros de soporte, y las WordCamps en las que he hablado solo en lo que llevamos de 2026.

Lo mejor es ver cómo suben solos los contadores de «Impacto reciente» mientras cargas la página, en vez de una foto de perfil de 2015 congelada para siempre. Los datos se actualizan sin que yo tenga que tocar nada.

Si lo prefieres, en la página del plugin puedes lanzar una vista previa en directo y WordPress.org te monta una web con el plugin activo para que pruebes con tu propio perfil.

Por qué esto no es un plugin más, es un regalo

Todos mis plugins resuelven un problema técnico, ya sea de seguridad, de rendimiento, de SEO o de cumplimiento normativo. Este no, este es diferente, este está dedicado a ti, que contribuyes a que todos podamos disfrutar de WordPress.

Es un plugin para quien traduce cadenas a las tres de la mañana, para quien modera un hilo de soporte enrevesado, quien organiza una WordCamp sin cobrar un euro, o quien hace fotos para el directorio de WordPress, porque todas esas personas, casi siempre anónimas, se merecen algo más que una insignia enterrada en un perfil que casi nadie mira. E

s gratis, sin letra pequeña ni versión de pago escondida detrás de las funciones buenas, porque la comunidad que me ha dado casi 20 años de carrera no me debe nada a mí, se lo debo yo a ella. Ya escribí en su día sobre por qué es importante tanto el software libre, así que no me voy a repetir aquí.

Si contribuyes de cualquier forma (código, traducciones, soporte, fotos, eventos, lo que sea), instálalo en tu web, crea tu página, y enséñale al mundo lo que llevas currado todo este tiempo. Y si todavía no contribuyes a nada, esto también vale como excusa estupenda para empezar a contribuir a WordPress, porque ya sabes dónde vas a poder enseñarlo después.

Puedes incluso traducirlo tú mismo a tu idioma, porque de momento solo está en español e inglés (dentro de nada en italiano), y a un plugin que celebra a quien traduce le vendría de perlas que también lo traduzcan.

Como dice el pie de página de wordpress.org, «el código es poesía». Pues ahora, además, tienes dónde publicar el tuyo. Si te lo instalas, cuéntame en los comentarios cómo te ha quedado o qué sección echas en falta.

Te lo adelanto ya, pero en plan básico: para una entrada normal de blog, BlogPosting o el valor por defecto, para una página corriente, WebPage, y entre los subtipos de la familia Article la elección apenas cambia nada en los resultados de Google, aunque sí en cómo te leen los asistentes de IA.

Sí, para empezar vale, como resumen cojonudo, pero si quieres hacerlo bien no te puedes quedar ahí, que la cosa tiene su miga, y lo mejor de todo es que de paso te va a servir aunque uses Yoast, Rank Math, el mismo Visibilty o cualquier otro plugin SEO, porque la etiqueta final es la misma.

Vamos a verlo de a pasito que dirían en mi pueblo.

Qué es eso del «tipo de schema»

Cualquier plugin de SEO, Visibility, Yoast, Rank Math el que sea, añade al código de cada página que publicas un bloque de JSON-LD, que son datos estructurados en formato JSON, invisibles para el visitante pero que las máquinas leen sin problema.

Dentro de ese bloque JSON-LD hay una propiedad llamada @type que dice qué es esa página, si un artículo, una noticia, una página de contacto o un perfil.

El tipo de schema es la etiqueta de una caja de mudanza, donde todas las cajas son iguales por fuera, y lo que cambia cómo las tratan los transportistas es que ponga libros o vajilla. Si marcas como vajilla una caja llena de libros no pasa nada grave, pero el que la abra esperando platos dejará de fiarse de tus etiquetas.

Con Google pasa lo mismo, una etiqueta que no se corresponde con el contenido no te penaliza de entrada, pero deja de servir para algo, y si encima es engañosa a propósito hay una acción manual esperándote en Search Console con el nombre de «marcado estructurado con spam».

Dónde se elige el tipo de Schema en tu plugin SEO

Cada plugin tiene sus manías, por ejemplo, en Visibility te deja fijarlo en dos niveles, por un lado, en los ajustes del módulo de descubrimiento eliges el tipo por defecto para cada tipo de contenido, uno para las entradas, otro para las páginas y así con cada tipo personalizado que tengas.

Luego, en la barra lateral del editor, entrada por entrada, puedes sustituir ese valor cuando una publicación concreta consideres que requiera otro Schema. Esto también lo tienen otros plugins, como Rank Math o Yoast.

La opción «Por defecto (Article)» del desplegable de Visibility y otros plugins significa justo eso, que se aplique lo que hayas configurado para ese tipo de contenido, así que si no tienes un motivo concreto para cambiarlo, déjalo en «Por defecto» y a otra cosa.

Si vienes de otro plugin SEO la lógica es muy parecida, Yoast lo llama «Page type» y «Article type» en su pestaña de schema, Rank Math lo llama «Schema Type» y SEOPress tiene su equivalente en los datos estructurados.

Todo lo que cuento en este artículo te sirve igual con cualquier plugin de SEO. Si te pasas a Visibility el importador de un clic se trae también estos valores desde Yoast, Rank Math y All in One SEO, junto con el resto de tus metadatos, al contrario no te prometo lo mismo.

La familia Article: seis etiquetas para casi lo mismo

El primer grupo del selector lo forman los subtipos de artículo, pensados para contenido editorial con autor y fecha:

• Article: el genérico, válido para cualquier contenido editorial y la elección segura cuando dudas.
• BlogPosting: la entrada de blog clásica, con voz y firma. Si tu web es un blog es tu etiqueta natural.
• NewsArticle: noticias y actualidad, contenido pegado a un hecho con fecha. Si cubres la actualidad de tu sector, este.
• TechArticle: tutoriales, guías paso a paso y documentación técnica. En un blog de tutoriales como este es el que más sentido tiene.
• ScholarlyArticle: estudios y trabajos con metodología, más propio de webs académicas o de investigación.
• Report: informes y análisis con datos, tipo estudio anual o comparativa documentada.

Pues bien, la documentación de Google solo contempla tres de ellos para su función de artículo, Article, NewsArticle y BlogPosting, y los trata como intercambiables. Los otros tres son subtipos válidos de schema.org que Google ni siquiera menciona.

O sea, que elegir entre BlogPosting y NewsArticle no va a cambiar cómo te muestra Google, y elegir TechArticle no te da nada extra en sus resultados.

¿Entonces para qué molestarse?, pues porque Google no es el único que lee esa etiqueta, los asistentes de IA y los motores de respuesta leen el @type tal cual, sin interpretarlo, igual que cualquier agente que rastree tu web.

Para un asistente de IA un TechArticle le dice que lo que tiene delante es un tutorial técnico, y que lo entregue cuando alguien pregunte cómo hacer algo, y de un NewsArticle  le dice que es una noticia, y que tenga muy en cuenta la fecha.

Ser preciso te cuesta un clic y aporta contexto a todo lo que no es Google.

Para Google, BlogPosting y NewsArticle son la misma etiqueta con distinto nombre, pero para un asistente de IA son dos cosas distintas.

Eso sí, sin venirte arriba, que Google ha dicho por escrito que sus funciones de IA no requieren ningún schema especial. La etiqueta correcta evita que las máquinas tengan que adivinar qué es tu contenido, y ahí se acaba su potencial.

La familia WebPage: sus apellidos

El segundo grupo es para páginas, contenido sin la lógica de autor y fecha de un artículo. La estructura se repite, con un tipo genérico y varios subtipos que lo afinan:

• WebPage: la página genérica, tu elección por defecto para páginas y la correcta en el 90% de los casos.
• AboutPage: la página «sobre mí» o «sobre nosotros». Refuerza la identidad del sitio, que es de lo que hablamos un poco más abajo.
• ContactPage: la página de contacto, una señal de transparencia que a las máquinas les viene de perlas para saber cómo localizarte.
• ProfilePage: el perfil de una persona o entidad. Es el único de este grupo con función propia documentada por Google desde noviembre de 2023, y el propio Google recomienda usarlo en las páginas de autor que enlaza el schema ATu código aquírticle, pura señal E-E-A-T (experiencia, conocimiento, autoridad y confianza, su mantra de calidad).
• CollectionPage: páginas que recopilan otras cosas, como un directorio de recursos o un listado de herramientas.
• ItemPage: una página dedicada a un único elemento concreto, la ficha de algo que no está a la venta.

Ninguno de estos tipos te va a pintar estrellitas en Google, y no pasa nada. Su trabajo es de identidad, decirle a quien rastrea tu web qué es cada página dentro del conjunto, que es lo que un asistente necesita para citarte bien.

Los que no suelen estar en el selector de Schema, y casi mejor

Faltan los famosos Product, Recipe, Event, VideoObject y LocalBusiness y si no los he incluido en Visibility no ha sido por despiste, es una decisión que tiene sus motivos.

El motivo principal para no incluir en un plugin de SEO por defecto este montón de tipos de Schema es que todos esos tipos tienen propiedades obligatorias que tu contenido no lleva (normalmente) de serie.

Un Product exige precio, moneda y disponibilidad, un Recipe quiere ingredientes y tiempos, un Event pide fechas y lugar, para que nos entendamos rápido.

Generar esas etiquetas sin sus propiedades te genera errores en Search Console, y un schema con errores es peor que no tener schema, porque le estás enseñando a Google cajas que prometen un contenido pero que al abrirlas están vacías.

Hay una segunda razón de peso, y es que quien de verdad posee ese dato ya genera ese schema. Un ejemplo que conocerás de sobras es WooCommerce, que ya genera el Product con el precio y el inventario reales.

Plugins muy conocidos, como por ejemplo The Events Calendar, genera el Event con sus fechas, y los plugins de recetas tipo WP Recipe Maker hacen lo propio con el Recipe.

Si Visibility, u otro plugin de SEO, te dejase elegir Product en el desplegable de una entrada, estaría duplicando o, peor todavía, contradiciendo al plugin que tiene los datos buenos, y de serie.

También hay que decirlo, los plugins de SEO que ofrecen estos tipos mediante un constructor de campos manuales de datos estructurados lo hacen bien si te molestas en rellenarlos, y si es así al menos tienes la oportunidad de hacerlo bien.

El problema es el desplegable alegre que te deja marcar cualquier cosa sin pedirte los datos, que de esos también hay. Si algún día estos tipos decido meterlos en Visibility será con un constructor de campos en condiciones, que lo último que te hace falta es una casilla que te anime a mentirle a Google.

El cementerio de los resultados enriquecidos

Google lleva años haciendo poda de resultados enriquecidos, y ese recorte explica por qué tampoco verás FAQ ni HowTo en el selector de tipos de Schema.

La lista de bajas impresiona (que en paz descansen):

• HowTo: limitado primero en móvil y eliminado del todo en septiembre de 2023. Los pasos con fotos en los resultados son historia.
• FAQ: restringido en agosto de 2023 a webs gubernamentales y de salud, y rematado para todo el mundo el 7 de mayo de 2026. Los desplegables de preguntas bajo tu resultado ya no existen para nadie, y en junio de 2026 desaparecieron también del informe de Search Console y de la prueba de resultados enriquecidos.
• La masacre de junio de 2025: Course Info, Claim Review, Estimated Salary, Learning Video, Special Announcement y Vehicle Listing, todos fuera por poco uso.
• La segunda tanda de noviembre de 2025: más funciones retiradas, entre ellas los problemas de práctica (practice problems) desde enero de 2026.

La razón, en el caso del FAQ es, para variar, el abuso por parte de los SEO y usuarios demasiado comprometidos, que se marcaron preguntas de relleno a mansalva para ocupar más sitio en los resultados hasta convertirlo en spam con acordeón. En el resto de casos Google simplifica su página de resultados para dejar hueco a sus propia funciones de IA.

Así que el marcado FAQPage sigue siendo schema.org válido y otros sistemas pueden leerlo, pero como truco para ganar espacio en Google está muerto, y si un tutorial de 2022 te anima a marcar FAQ para conseguir los desplegables, ya sabes de qué año es esa información.

La identidad del sitio: Organization, Person y el baile de los @id

Queda un tipo de schema que no aparece en los desplegables, y es debido a que no es de página, es de sitio. Tu web entera tiene una identidad, una Organization si eres una empresa o un proyecto, una Person si eres tú a título personal, y esa identidad debe declararse una sola vez, en la portada, con todos sus datos.

Aquí entra el baile de los @id, porque cada nodo de schema puede llevar un @id, que viene a ser su DNI, una URL única que permite que otros schemas lo referencien en vez de repetirlo.

Si usas VigIA, que emite el JSON-LD de identidad del sitio en la portada, Visibility detecta ese nodo y hace que el publisher de cada artículo apunte al mismo @id en lugar de crear una Organization duplicada.

Dos fichas de la misma entidad con datos distintos confunden a cualquier máquina, y la gracia de coordinar los @id es que todo tu sitio dice lo mismo sobre quién eres, lo mire quien lo mire.

Lo bueno de usar este conjunto es que se complementan sin pisarse, la ventaja de coordinar plugins, en principio para usos diferentes, pero al final todo tiene algo de relación, como es el caso.

Cómo comprobar si lo has hecho bien

Tres pruebas rápidas y gratis:

1. Abre el código fuente de una entrada (clic derecho en la página) y busca application/ld+json. Ahí verás el bloque con el @type que has elegido, junto al BreadcrumbList (las migas de pan) que Visibility añade por su cuenta.
2. Pasa la URL por la prueba de resultados enriquecidos de Google para ver qué funciones detecta. Ojo, solo te enseñará las que Google mantiene vivas.
3. Pasa la misma URL por el validador de schema.org, que comprueba si el marcado es válido aunque Google no pinte nada con él. Para los tipos que Google ignora, este es tu árbitro.

Chuleta rápida para casi ni pensar

Si después de la tabla sigues con dudas, déjalo en «Por defecto», que para eso está y no te vas a equivocar. Lo importante es no mentir con la etiqueta, el subtipo perfecto es secundario.

Si quieres seguir tirando del hilo de cómo leen tu web los asistentes de IA, tengo unas cuantas guías publicadas sobre el tema de visibilidad en IAs.

Para dudas concretas sobre tu caso, que seguro que las hay porque este tema las genera solas, me tienes ahí abajo, en la sección de comentarios.

Quieres que un sitio tenga unas reglas en el robots.txt y otro las suyas, normal ¿no?, porque no todos necesitan lo mismo, y resulta que WordPress te sirve el mismo robots.txt para todos. Y encima, si abres el de cualquiera de los dominios, ves uno que no has puesto tú.

Me lo trajo hace poco un cliente del servicio de mantenimiento, con un multisitio de varios dominios, que me pidió tocarle los robots.txt de cada web.

Cuando me puse a mirarlo resulta que el problema no era suyo ni de su configuración, era de cómo funciona WordPress por dentro con los ficheros en una red multisitio.

Así que aprovecho para contártelo con calma, porque tiene más miga de la que parece. Y sí, ya te lo adelanto, se puede tener un robots.txt distinto por sitio en una red multisitio de WordPress, pero antes hay que darle una pensada, porque todo tiene sus matices.

¿Por qué en cada dominio de WordPress multisitio hay dos archivos para robots?

Primero, un apunte rápido para quien llegue nuevo. WordPress no crea un fichero robots.txt de verdad en el disco, lo genera dinámicamente cada vez que alguien lo pide, lo que se llama un robots.txt virtual. Puedes verlo y modificarlo, pero eso ya te lo conté al detalle en el post sobre el robots.txt virtual de WordPress, con el truco de verlo tecleando ?robots=1 y el filtro para cambiarlo.

El caso de mi cliente era que en su multisitio hay un robots.txt físico, un fichero de verdad, en la raíz del dominio principal, el que aloja la red y desde el que se instalan los plugins y el tema.

Y como toda la red comparte esa misma carpeta raíz, ese fichero se sirve igual para todos los dominios, así que tecleas otro-dominio.com/robots.txt y sale el del principal, no el del subsitio, porque no tiene un robots.txt físico, no es posible.

¿Y el virtual de cada sitio, el que tú crees que estás editando con tu plugin de SEO? Ahí sigue, pero solo aparece si lo fuerzas a mano con otro-dominio.com/?robots=1.

Los rastreadores piden siempre /robots.txt, así que se meriendan el físico compartido y nunca ven las reglas propias de cada web. De ahí la sensación de tener dos, el que sirven los bots y el que gestiona el plugin, cada uno con sus reglas y sin enterarse el uno del otro.

¿Y por qué gana el físico? Pues porque cuando existe uno en la raíz, lo entrega el servidor web antes de que WordPress ni siquiera arranque, así que el virtual y el filtro se quedan sin pintar nada para esa dirección.

Subdominios, dominios mapeados y subcarpetas

El estándar del robots.txt, recogido en el RFC 9309 que es la norma oficial, dice que el archivo vive en la raíz de cada host, o sea de cada dominio o subdominio, y de ahí salen tres escenarios muy distintos según cómo tengas montada la red.

• Red por subdominios (es.tudominio.com, en.tudominio.com): cada sitio es un host distinto, así que cada uno puede y debe tener su propio robots.txt. Aquí lo de «uno por sitio» tiene todo el sentido.
• Red por dominios mapeados (dominio.com, domain.com): igual que el anterior, cada dominio es un host, así que cada uno lleva el suyo.
• Red por subcarpetas (dominio.com/es, dominio.com/en): todos comparten el mismo host, así que solo hay un robots.txt que cuente, el de la raíz del dominio, y manda el sitio principal. Un subsitio en subcarpeta no puede servir el suyo a los rastreadores por mucho plugin que le pongas.

Y ojo, que lo de las subcarpetas no es una carencia de WordPress, es el propio estándar.

El robots.txt va en la raíz del host y punto, así que si tu red es por subcarpetas, lo máximo que puedes hacer es meter todas las reglas que necesites, conjuntas, en el robots.txt del dominio principal, teniendo cuidado de no meter reglas que solo sirvan para el dominio o una carpeta concreta, todas generales.

¿Qué hago con el robots.txt del sitio principal?

Da igual la vía que elijas luego, con código o con plugin, si hay un robots.txt físico en la raíz y quieres reglas por subsitio quítalo, porque carga antes que WordPress y ningún plugin o PHP se lo puede saltar.

Mientras ese fichero siga ahí los bots seguirán leyéndolo a él y las reglas por sitio no llegarán a ninguna parte.

Pero, si es el caso, con quitarlo no basta, además tienes que asegurarte de que ningún plugin te lo vuelve a crear. El editor de ficheros de Yoast, por ejemplo, escribe un robots.txt físico si le das al botón, y en una red ese fichero se te cuela para todos. Así que bórralo, comprueba por FTP que no reaparece, desactiva la edición de archivos dentro de WordPress, y solo entonces pasamos al siguiente paso.

Una vez fuera  el archivo físico WordPress ya sirve el virtual de cada sitio por su cuenta, y ahí sí puedes empezar a configurar en cada web el suyo. En subdominios y dominios mapeados esto funciona tal cual, cada host sirve el suyo. En subcarpetas no hay manera, se siente, solo cuenta el del dominio principal.

Cómo darle reglas propias de robots a cada subsitio de una red multisitio (con código)

Si no quieres depender de ningún plugin de SEO para esto, WordPress trae un filtro, robots_txt, que te deja modificar el robots.txt virtual, y combinándolo con get_current_blog_id() (la función que te dice en qué sitio de la red estás) puedes dar reglas distintas según la web. La idea, que he ido ampliando y actualizando, me la dio Florian Brinkmann, en un post de hace ya unos pocos años.

Lo que hay que hacer es meter el siguiente código en un mu-plugin que se activa en toda la red. Lo subes por FTP a la carpeta wp-content/mu-plugins y listo:

/**
 * Plugin Name: Archivo robots.txt por sitio en WordPress Multisitio
 * Plugin URI: https://ayudawp.com/
 * Description: Permite definir reglas de robots.txt diferentes para cada sitio en una red multisitio de WordPress.
 * Version: 1.0
 * Author: Fernando Tellado
 * Author URI: https://tellado.es
 */

// Añade reglas por sitio al archivo robots.txt virtual de cada sitio a través de la red
add_filter( 'robots_txt', 'ayudawp_multisite_robots_txt', 20, 2 );

function ayudawp_multisite_robots_txt( $output, $public ) {

// Solo funciona si es multisitio
if ( ! is_multisite() ) {
return $output;
}

// Reglas por sitio asignadas por ID de blog (tienes el ID en Administrador de la red > Sitios)
switch ( get_current_blog_id() ) {

// Sitio con ID 2: tienda online
case 2:
$output .= "Disallow: /carrito/\n";
$output .= "Disallow: /finalizar-compra/\n";
$output .= "Disallow: /mi-cuenta/\n";
break;

// Sitio con ID 3: blog
case 3:
$output .= "Disallow: /?s=\n";
$output .= "Disallow: /descargas/\n";
$output .= "Disallow: /gracias/\n";
break;
}

return $output;
}

Cambias los ID (case x)  y las reglas por las tuyas, y cada web servirá las suyas.

El código tiene sus límites, como que es obvio que lo mantienes tú a mano cada vez que cambien las necesidades, y luego claro está, no se puede aplicar a otros archivos, como el llms.txt, que arrastra el mismo problema. Y por supuesto, te recuerdo de nuevo que en una red en subcarpetas no hay milagro que valga.

¿Afecta esto también al llms.txt?

Ya que estás con el robots.txt, los archivos llms.txt sufren del mismo problema.

Es un fichero que sirve de índice en Markdown de tu web para los agentes de IA, y en una red cada sitio querría el suyo. Mismo patrón que el robots.txt, por sitio si lo sirves dinámico, y compartido y roto si escribes un físico en la raíz. La diferencia con el robots.txt es que aquí ni el filtro tienes.

WordPress no genera archivos llms.txt ni trae ninguna función para tocarlo, así que el mu-plugin de arriba no sirve y por código te quedas sin un atajo como el del robots.txt. Para tenerlo por sitio en una red la vía práctica es un plugin que lo genere dinámico por sitio, y de eso va lo que viene ahora.

Cómo darle reglas propias de robots a cada sitio (con plugins)

Si lo de mantener un mu-plugin no te apetece, o también quieres que el llms.txt sea configurable en cada sitio, esto lo resuelven algunos plugins.

De pago te lo ofrece AIOSEO, que tiene un editor de robots.txt de red que te deja tocar el de cada subsitio, pero solo en redes por subdominios, no por subcarpetas (lo dicen ellos en su documentación), y en su versión Pro. SEOPress anuncia edición de robots.txt para multisitio y multidominio, y luego hay plugins dedicados solo a esto, como Multisite Robots.txt Manager. De las subcarpetas nos seguimos olvidando, porque ya sabes que ahí manda el estándar.

Y luego está Visibility, plugin gratuito de SEO que sirve el robots.txt y también el llms.txt de cada sitio de la red por su cuenta, sin que tengas que tocar nada.

Entrega por una única URL, la de siempre, /robots.txt, y de paso arregla ese lío del ?robots=1 y los 404 en instalaciones en subcarpeta. Además, está pensado para no repetir el problema, porque en una red no escribe un físico compartido, solo lo escribe donde de verdad es del sitio, en una instalación normal o en el sitio principal de una red por subcarpetas.

Visibility sustituye a tu plugin de SEO, no convive con él, así que si vienes de Yoast u otro plugin, esto supone cambiar el que tuvieses por Visibility, no añadir uno más, que siempre es mala idea. Pero no es algo preocupante, no pierdes nada importante, tiene lo que los demás, y algunas cosas (casi todas) las hace mejor.

Ah, y da igual la elección, aunque uses Visibility el robots.txt físico de la raíz hay que quitarlo igual, porque un fichero que sirve el servidor no lo salta nadie. Eso sí, si Visibility detecta un físico compartido tapando el virtual, te avisa en su pestaña de descubrimiento para que sepas que está ahí y lo quites.

Y, por si no lo sabías Visibility, además de hacer lo que todos los demás plugins de SEO, redirecciones incluidas, también emite las señales por sitio (robots.txt, llms.txt y el schema), y si además quieres medir, tienes VigIA, que ofrece analítica de qué rastreadores de IA entran de verdad en cada web y puede bloquearlos, y puedes complementar el pack IA con AI Content Signals, que añade las directivas de IA de Cloudflare.

Resumiendo: Qué hacer con los ficheros robots.txt en multisitio según el tipo de red

En un par de líneas, por si ya estás con algo de lío:

• Si tu red es por subdominios o por dominios mapeados: quita el físico de la raíz y luego das las reglas por sitio con el mu-plugin del filtro robots_txt, o dejas que lo haga tu plugin de SEO (o Visibility) por ti. Cada dominio servirá el suyo.
• Si tu red es por subcarpetas: solo hay un robots.txt, el del dominio principal, así que mete ahí todas las reglas que necesites para los distintos subsitios. Es el único sitio donde los bots las van a leer.

¡Te toca decidir!

Antes de tocar nada, échale un vistazo a tu red y mira si tienes el problema. Pide el robots.txt de cada dominio y compáralos, y si todos te devuelven exactamente el mismo, tienes un físico compartido mandando sobre todos.

Desde el terminal es tan fácil como teclear la URL tipo https://dominio.com/robots.txt cambiando el dominio o subdominio, y comparar lo que sale. Y si quieres ver el virtual la URL es añadir ?robots=1 al dominio o subdominio.

Con eso claro decides si quitar el físico y tirar de código, o quitar el físico y dejar que un plugin te sirva el de cada sitio. Lo que no funciona es dejar el robots.txt físico compartido ahí, porque se antepone en toda la red y, salvo que uses las mismas reglas para todos los subsitios, puedes estar creándote un problema de rastreo.

Si tienes una red montada de una forma rara, o te topas con algún caso que no encaja con esto, me tienes en los comentarios aquí abajo, que estos temas de multisitio siempre traen su cosilla, y no lo usa muchísima gente.

Y el problema es que la mayoría de la información disponible sobre el tema está mezclada, sin querer, entre el aplazamiento de las obligaciones de alto riesgo y lo que de verdad te toca a ti con un sitio WordPress. Vamos a separarlo con calma, caso por caso, sin dar nada por hecho, a ver si soy capaz de explicártelo como yo lo he entendido, y como lo aplico.

Quién es quién ante la norma: proveedor y responsable del despliegue

El reglamento reparte las obligaciones entre dos papeles distintos, y confundirlos es la fuente de la mitad de los problemas que te puedes buscar sin ayuda de nadie.

• El proveedor es quien construye y comercializa el sistema de IA, Anthropic con Claude, OpenAI con ChatGPT, Google con Gemini.
• El responsable del despliegue es quien usa esa herramienta ya hecha para su propio contenido, o sea, tú con tu WordPress.

Piénsalo como la diferencia entre quien fabrica un coche y quien lo conduce. Al fabricante le tocan las revisiones técnicas del motor, la homologación, que las piezas cumplan norma, al conductor le toca circular con las luces encendidas de noche y llevar el cinturón puesto. Son obligaciones distintas sobre el mismo vehículo, y confundir una con otra no libra a nadie de la suya.

En la práctica casi todo lo que te afecta a ti como propietario de un WordPress cae del lado del responsable del despliegue. El marcado técnico invisible del contenido, ese que debe ser legible por una máquina, corresponde al proveedor del modelo, no a ti. Lo que sí te toca es el aviso visible al usuario, y ahí es donde vamos a entrar ahora.

¿Y si no estás en España, o ni siquiera en la Unión Europea?

Aquí conviene hacerse una pregunta que va más allá de dónde vive tu empresa o dónde tienes contratado el hosting. El reglamento europeo tiene alcance extraterritorial, igual que el RGPD con el que ya convives si tienes un formulario de contacto en tu web. Se aplica también a proveedores y responsables del despliegue establecidos en un tercer país cuando el resultado que produce el sistema de IA se usa dentro de la Unión Europea.

Vamos, en lo que nos afecta, si tu web la lee gente en algún país de la Unión Europea, algo que le pasa a prácticamente cualquier blog público con un mínimo de tráfico, el reglamento entra en juego aunque tú estés en México, Argentina o al otro lado del mundo. No hace falta que factures en euros ni que tengas oficina en Europa.

Dicho esto, y como pasa siempre que se habla de normativa, esto es información general para que entiendas el criterio, no una sentencia sobre tu caso concreto. Si tienes dudas serias porque tu negocio tiene peso real en la Unión Europea, consulta con un abogado especializado, que para eso están.

Los tres casos que de verdad te afectan en un WordPress

El artículo 50 del reglamento, que es el que regula la transparencia, cubre varios supuestos, pero solo tres tienen encaje real en un sitio WordPress «normal».

Un chatbot o asistente que habla con tus visitantes

Si tienes un chatbot de atención al cliente, la norma exige que quien interactúa con él sepa que está hablando con una máquina, salvo que sea tan obvio que no haga falta decirlo, un bot con nombre «Asistente IA» y avatar de robot no necesita cartel adicional. La excepción de la obviedad no es una puerta trasera para no avisar, es sentido común aplicado a los casos donde nadie en su sano juicio pensaría que habla con una persona.

Una imagen, audio o vídeo que sea un deepfake

Aquí está el mito más extendido de todos, la idea de que toda imagen generada con IA necesita aviso, y no es así. La obligación solo se activa con deepfakes, y la propia norma define el término con precisión, pues se refiere únicamente a contenido de imagen, audio o vídeo creado o modificado por IA que imita a personas, objetos, lugares, entidades o hechos reales de forma que pudiera hacer creer a alguien que es genuino.

Una ilustración abstracta para acompañar un artículo de seguridad, un fondo decorativo, una infografía inventada, nada de eso es deepfake, porque no simula que algo real haya ocurrido. Donde sí entras en el supuesto es si generas una imagen que aparenta ser una captura real de un evento que nunca pasó, o que hace pasar por auténtica la imagen de una persona real en una situación inventada.

Un texto sobre un asunto de interés público

Este es el que caso que tiene más matices de los tres. De lo que se trata es que si usas IA para generar o manipular texto que se publica con el fin de informar sobre asuntos de interés público, tienes que avisar de que es artificial, salvo que ese texto haya pasado por una revisión editorial sustantiva y haya una persona, física o jurídica, que asuma la responsabilidad editorial de lo publicado.

El matiz más relevante es que las directrices de la Comisión Europea interpretan esa excepción de forma estricta. No vale una revisión superficial ni un visto bueno de trámite, tiene que haber un examen deliberado del fondo del contenido por alguien con criterio suficiente para hacerlo. Corregir la ortografía o dar el visto bueno sin leerte el texto entero no cuenta.

Para la inmensa mayoría de tutoriales técnicos, el supuesto ni siquiera se activa, porque explicar cómo desactivar un widget no es informar de un asunto de interés público en el sentido que persigue la norma. Pero un artículo sobre una vulnerabilidad que afecta a un millón de webs, o sobre este mismo reglamento, empieza a acercarse a esa categoría, así que conviene tenerlo presente cuando el tema es importante.

Cuando lo ves así, en una tabla, el titular de «hay que etiquetar todo lo que hagas con IA» se cae solo.

Mitos sobre AI Act

Antes de seguir, cinco ideas que circulan por ahí y que no ayudan nada.

• «Se ha retrasado el AI Act»: Cierto a medias, y la parte cierta es justo la que no te afecta. La Unión Europea sí ha aplazado las obligaciones de los sistemas de alto riesgo, empleo, biometría, infraestructuras críticas, hasta diciembre de 2027 y agosto de 2028. Pero las obligaciones de transparencia del artículo 50, las que trata este artículo, no se han tocado y siguen entrando en vigor el 2 de agosto de 2026. Quien lea «se retrasa el AI Act» y deje de prepararse por completo se va a llevar un disgusto.
• «Tengo que etiquetar cada imagen que hago con IA»: Ya lo hemos visto arriba, y solo los deepfakes necesitan aviso, y la mayoría de las imágenes ilustrativas de un blog no lo son ni de lejos.
• «Como la ley española no está en el BOE, tengo tiempo»: El proyecto de ley española, que ya está en el Congreso, no inaugura estas obligaciones, las adapta con maquinaria propia de sanción en España. El reglamento europeo es de aplicación directa, con ley española o sin ella, así que el reloj corre igual.
• «Me pueden caer 35 millones de euros por no avisar»: Esa cifra corresponde a las prácticas prohibidas del artículo 5, cosas como la manipulación subliminal o la valoración social, no al incumplimiento del artículo 50. Lo que arriesgas aquí son multas de hasta 15 millones de euros o el 3 % de la facturación mundial, según lo que sea mayor, que tampoco es una broma, pero conviene tener la cifra correcta.
• «Tengo que revisar y etiquetar todo lo que ya he publicado»: No. La obligación se aplica a partir del 2 de agosto de 2026, el contenido que ya llevaba tiempo circulando antes de esa fecha no necesita marcado retroactivo. Lo que sí entra en juego es todo lo que generes o publiques a partir de ese día.

El caso de los resúmenes generados con IA

Vamos a bajarlo a un ejemplo real, que es más útil que quedarse en la teoría. Cada vez hay más plugins, el mío incluido con Share Buttons & AI-powered Summaries, que generan un resumen automático de la entrada con un proveedor de IA externo. ¿Ese resumen necesita aviso?

Pues bien, las directrices de la Comisión, al desarrollar el artículo 50.2, ponen a los resúmenes generados por IA en la lista de cambios sustantivos, junto a las traducciones o la eliminación de objetos de una imagen, frente a la edición estándar que sí queda exenta, como corregir ortografía o ajustar el color.

Esa parte concreta de la norma habla del marcado técnico que corresponde al proveedor del modelo, no directamente de tu aviso al lector, pero deja clara una cosa, que un resumen no es una tontería formal, es contenido nuevo con entidad propia.

La pregunta que de verdad te afecta como responsable del despliegue es si ese resumen entra en el supuesto de texto sobre un asunto de interés público y si ha pasado por esa revisión editorial de la que hablábamos antes. Y ojo, revisar el artículo del que sale el resumen no es lo mismo que revisar el resumen en sí, que suele generarse solo, en cada visita o en cada publicación, sin que nadie le eche un vistazo concreto a esa pieza de texto en particular.

Por suerte la salida práctica no depende de resolver ese debate. Share Buttons & AI-powered Summaries ya muestra por defecto la etiqueta «Resumen generado con IA» encima de cada resumen, así que si usas el plugin sin tocar ese ajuste, este supuesto no te da ningún quebradero de cabeza.

El matiz es que el texto de la etiqueta es configurable, y si lo cambias por algo que no mencione la IA, o lo quitas directamente, la responsabilidad de que el aviso siga ahí es tuya, no del plugin. La herramienta te pone el camino fácil, no te lo puede recorrer por ti.

Esto vale igual si generas el resumen con cualquier otro plugin o a mano con tu proveedor de IA favorito.  La etiqueta de una línea, «resumen generado con inteligencia artificial» o similar, resuelve el debate entero sin necesidad de elucubrare si tu web informa o no de un asunto de interés público.

Textos alternativos e imágenes generadas con IA

WordPress 7 trae de serie una pantalla de conectores de IA donde guardas tu clave de Anthropic, OpenAI o Gemini para que cualquier plugin compatible la use. Si la usas para generar texto alternativo de tus imágenes o para crear una ilustración con la que acompañar un artículo, ¿entras en el supuesto de aviso?

Con el texto alternativo la respuesta corta es que no, y aquí no hay una directriz de la Comisión que lo diga con esas palabras exactas, así que es mi lectura razonada del propósito de la norma, no una cita textual de nadie. El alt describe una imagen para quien usa lector de pantalla, no informa al público de ningún asunto, ni siquiera lo ve quien navega con la vista, así que se queda fuera del espíritu del artículo 50.4 igual que se quedaría fuera un pie de foto meramente descriptivo.

Con las imágenes ilustrativas aplica exactamente lo que vimos antes, pues si no simula un hecho, una persona o un lugar real de forma creíble, no es deepfake y no necesita aviso.

Y para quien se pregunte quién marca técnicamente qué cuando usa el conector, el proveedor del modelo que hayas conectado, Anthropic, OpenAI o Google, es quien responde del marcado legible por máquina del artículo 50.2. Tú, como responsable del despliegue, respondes de lo que ya hemos visto, el aviso visible cuando el contenido lo requiere. Usar el conector nativo no te añade ninguna obligación nueva que no tuvieras ya generando el mismo contenido por otra vía.

Qué deberías tener listo desde ya

Con todo lo anterior ya tienes el criterio. Esto es lo concreto que conviene dejar hecho:

• Revisa si tienes chatbot o asistente de IA en la web, y confirma que el visitante sabe que habla con una máquina.
• Si generas imágenes con IA plantéate en cada caso si podría confundirse con algo real, no solo si «se ve muy realista».
• Si usas resúmenes generados con IA mejor con la etiqueta visible que sin ella, cuesta una línea de HTML y te ahorra la inquietud y un posible susto.
• No toques lo ya publicado antes del 2 de agosto de 2026 solo por esto, la obligación mira hacia delante.
• Si tu contenido tiene peso en asuntos de interés público, documenta que lo revisas tú antes de publicar, no hace falta un proceso complicado, basta con que sea real y puedas explicarlo si alguien pregunta.

Con la tabla de más arriba ya tienes el criterio completo caso por caso. Y si quieres el aviso de una línea listo para pegar en cualquier resumen o texto generado con IA, aquí lo tienes:

<div style="border-left: 4px solid #8a8a8a; background: #f5f5f5; padding: 10px 16px; margin: 16px 0; font-size: 0.9em; line-height: 1.5;">
  <strong>Aviso:</strong> este resumen ha sido generado con inteligencia artificial.
</div>

La Unión Europea también ha publicado un conjunto de iconos oficiales pensado para este etiquetado, por si prefieres un icono en vez de texto.

España y la capa nacional: AESIA

Todo lo anterior aplica ya, por el reglamento europeo, tengas o no ley española, pero si estás en España tenemos espía nuevo, gracias a esos políticos que siempre están pensando en nosotros.

El Gobierno español aprobó el proyecto de ley orgánica para el buen uso y la gobernanza de la inteligencia artificial el 26 de mayo de 2026 y lo envió al Congreso, donde sigue su trámite parlamentario con paso por el Senado antes de publicarse en el BOE.

Esa ley no inventa las obligaciones que has leído en este artículo, las aplica con maquinaria sancionadora propia y designa a la Agencia Española de Supervisión de la Inteligencia Artificial, la AESIA, como autoridad principal para vigilar y sancionar. Mientras el texto sigue su trámite, este artículo se actualiza en cuanto haya novedad publicada en el BOE, así que no hace falta que vayas comprobándolo tú.

Resumen rápido

Si te quedas con una sola idea de todo esto, que sea esta: la norma no castiga usar IA, castiga hacerlo pasar por algo que no es.

Un chatbot que se presenta como humano, una imagen que finge ser una foto real, un texto que informa de algo serio sin que nadie se haya hecho responsable de su contenido, eso es lo que persigue el reglamento. Un resumen con su etiqueta, una ilustración decorativa, un texto alternativo bien escrito, ninguno de esos tres necesita que te compliques la vida.

Este artículo es información general para que entiendas el criterio y actúes con cabeza, no asesoría legal sobre tu caso concreto, así que si tu situación tiene matices importantes, consulta con un profesional. Y si detectas algo que ha cambiado, ley española publicada, directrices finales de la Comisión distintas de lo que cuento aquí, dímelo en los comentarios y actualizo el artículo.

Si quieres profundizar en la parte legal más amplia, tengo también la guía de registro de consentimientos.

Me refiero a lo que Google mide como LCP (el tiempo que tarda en aparecer el bloque más grande de tu pantalla), y cuanto antes aparezca, mejor.

El problema es que WordPress tiene que adivinar cuál es esa imagen sin haberte visto navegar, y esa adivinanza falla más de lo que te gustaría.

La buena noticia es que ya existe una forma de que WordPress deje de adivinar el elemento inicial más pesado de tu página y lo sepa de verdad, a partir de datos reales de tus propios visitantes.

En este artículo te cuento qué es, qué gana tu web con ello, qué pegas tiene todavía, y qué hacer si prefieres quedarte con algo más probado mientras tanto.

Optimization Detective e Image Prioritizer

El núcleo de WordPress lleva desde la versión 6.3 detectando de forma automática cuál es probablemente la imagen del LCP, casi siempre la destacada, y le añade el atributo fetchpriority="high" sin que hagas nada.

El límite de esa detección automática es que se basa en heurísticas desde el servidor, reglas fijas que no saben cómo se ve realmente tu web en un móvil, en una tablet o con una ventana pequeña de escritorio.

Esas heurísticas aciertan la imagen correcta en torno a la mitad de las veces, mientras que la otra mitad, el navegador, recibe la orden de prioridad equivocada. Optimization Detective nace para resolver justo eso.

Es un plugin del equipo de rendimiento de WordPress que no optimiza nada por sí solo, es un framework que recoge datos reales de tus visitantes (o RUM, siglas de Real User Monitoring, monitorización de usuarios reales) sobre qué elemento se pinta primero en cada tipo de dispositivo.

No tiene pantalla de ajustes ni la va a tener, funciona solo, en segundo plano. El que hace algo con esos datos es Image Prioritizer, el plugin que depende de Optimization Detective para funcionar.

Con la información real de tus visitas, añade fetchpriority="high" a la imagen que de verdad es el LCP en cada punto de ruptura, ajusta la carga diferida para que no se quede vacío justo lo que sí se ve al entrar, y reduce el peso del fotograma inicial de los vídeos que hacen de LCP.

Anteriormente, Image Prioritizer también calculaba el atributo sizes de las imágenes responsive, pero ya no, esa función se quitó por un problema, y hoy ese trabajo lo hace otro plugin del mismo equipo, Enhanced Responsive Images.

¿Para cuándo estará esto en WordPress?

El equipo de rendimiento suele probar la funcionalidad completa en un plugin independiente, la validan con tráfico real de decenas de miles de webs, y cuando por fin entra en el núcleo, suele hacerlo con ajustes más prudentes que los que tenía el plugin original.

Ya te conté ese proceso con la carga especulativa nativa, que también nació como plugin, se probó en más de 50.000 sitios, con una mejora media del 1,9% en LCP en los que lo llevaban activado, y aterrizó en WordPress 6.8 con el modo prefetch y la anticipación más conservadora en vez del prerender y la anticipación moderada que traía el plugin.

El cálculo del atributo sizes para imágenes con carga diferida siguió un camino parecido hasta la versión 6.7.

Dicho esto, no hay fecha para Optimization Detective ni para Image Prioritizer. Ninguno de los dos aparece nombrado de momento en planes de futuras versiones, solo Enhanced Responsive Images y View Transitions figuran como trabajo del equipo de rendimiento en marcha hacia alguna versión de WordPress de las próximas.

Esa cosa es cojonuda ¿no? … pues no del todo

Antes de que instales los dos plugins unos cuantos peros que conviene que conozcas:

• Los dos siguen en beta: Optimization Detective en la 1.0.0-beta5 e Image Prioritizer en la 1.0.0-beta3, y ninguno tiene pantalla de ajustes.
• No deberías usar plugins canonical en webs en producción: Como cualquier plugin de este tipo su misión es terminar en el núcleo de WordPress y, aunque te corroa la impaciencia, no deberías usarlos como si fuesen plugins normales, nunca, ni estos ni ningún otro.
• Necesitas la API REST abierta a visitantes anónimos: Así es como se recogen los datos de cada visita. El propio plugin trae un aviso en Salud del sitio que te avisa si la tiene bloqueada, así que no te vas a quedar a ciegas. Si usas Vigilante con el modo de protección de la API REST más restrictivo, revisa que no le esté cerrando el paso a este plugin en concreto, o nunca vas a ver ninguna optimización aplicada sin saber por qué.
• No optimiza nada para ti como administrador: Hace falta que sean visitantes normales, así que no esperes ver cambios nada más activarlo, necesitas que pase tráfico real primero, para móvil y para escritorio.

¿Hago algo ya?

No hay una respuesta única, depende de cuánto te guste ir por delante y de cuánto tiempo le quieras dedicar, pero sobre todo teniendo en cuenta que si pruebas este tipo de plugins debe ser únicamente como experimentación.

Si no te importa que algo esté en beta y tienes tráfico suficiente para que se llenen de datos las visitas en pocos días, con todas las precauciones, instala Optimization Detective y Image Prioritizer, revisa el código fuente de tu web a los pocos días y compara.

Si prefieres no depender de tráfico acumulado ni de tener la API REST abierta a cualquiera, y quieres algo que ya lleva tiempo funcionando sin sorpresas hay plugins que sí puedes usar ya para optimizar WordPress.

¿De qué plugin estás hablando?

Sabes que hay muchos plugins de optimización, pero yo solo uso uno gratuito, DietPress, y este ya pone fetchpriority="low" a todas las imágenes menos la primera, sin mirar visitas ni dispositivos, una regla fija que sigue siendo mejor que lo que hace el núcleo por su cuenta con el resto de imágenes de la página, que es no hacer nada.

Pero esa regla fija y la lógica de Image Prioritizer, que decide con visitas reales por punto de ruptura, no siempre van a estar de acuerdo. Si en el móvil la imagen importante no es la primera del HTML, más habitual de lo que parece con maquetadores y avisos que se cuelan antes del contenido, tu plugin le estaría bajando la prioridad justo a la imagen a la que el otro se la quiere subir.

Lo tengo controlado, en cuanto Image Prioritizer deje la beta adaptaré DietPress para que no se pisen cuando se incorpore en WordPress, todavía no sé si apartándose cuando lo detecte o afinando la regla, pero se adapta, eso seguro.

Y si prefieres no tocar nada de esto todavía, tampoco pasa nada. Por el patrón que te contaba antes, es candidato real a acabar en el núcleo tarde o temprano, y cuando lo haga no vas a tener que instalar ni configurar nada, como pasó con la carga especulativa.

Elijas lo que elijas, tu web no tiene por qué seguir dependiendo de una adivinanza para saber cuál es su imagen más importante, y eso tarde o temprano juega a tu favor.

Si acabas probando alguno de los dos plugins, cuéntame qué tal te ha ido, aquí abajo en los comentarios tienes hueco.

Usar el software más extendido del planeta significa compartir también sus vulnerabilidades conocidas con la mitad de tus competidores.

Y esto no es solo un problema técnico, pues una brecha que exponga datos de clientes activa obligaciones legales concretas (en España, informar a la Agencia Española de Protección de Datos en un plazo de 72 horas), además de los costes de reputación y de recuperación del propio incidente.

Esta guía está organizada teniendo en cuenta por donde entran los distintos posibles ataques, que son cuatro grandes puertas, y en cada una encontrarás cómo entra el ataque, qué lo cierra (con soluciones gratuitas siempre que existen, que es casi siempre) y cómo comprobar que la puerta quedó cerrada.

Después encontrarás tres bloques transversales de distinta afectación, como son los riesgos propios de vender con WooCommerce, lo que te exige la ley aunque nadie te ataque, y el protocolo si ya han entrado.

Dicho todo esto, empezamos.

Puerta 1 – Las extensiones: por donde entra la inmensa mayoría de los ataques

El ataque típico contra un WordPress de empresa no lo lanza una persona contra tu web, lo lanza un bot contra millones de webs a la vez. El proceso es siempre parecido:

1. El bot rastrea internet buscando versiones concretas de plugins con vulnerabilidades publicadas.
2. Identifica la tuya por la huella que deja en el código fuente.
3. Explota el fallo (para el que suele existir exploit automatizado desde el mismo día del aviso).
4. Sube un pequeño archivo PHP a la carpeta de uploads que le da control remoto.
5. Crea un administrador con nombre discreto y empieza a inyectar redirecciones o spam SEO.

Tú no ves nada hasta que Google marca la web como comprometida o un cliente pregunta por qué al hacer clic en tu enlace acaba en una tienda de medicamentos que no es la tuya. Entre la infección y el descubrimiento pasan normalmente semanas.

Los números explican por qué esta puerta es la primera, y es que de todas las vulnerabilidades nuevas de WordPress la mayoría son del tipo XSS, que permite colar scripts ajenos en el navegador de tus visitantes.

Muy típico es el caso de los plugins abandonados, que no dejan de funcionar de golpe, siguen activos, y cada mes sin actualizarse acumulan más probabilidades de tener un fallo conocido que ya nadie va a parchear.

Y hay un agravante que es que WordPress.org cierra o retira plugins del repositorio con cierta regularidad por malware o vulnerabilidades sin corregir, y ese cierre no desinstala nada de tu servidor. El código sigue ahí, ejecutándose, y el aviso no te llega a ningún sitio salvo que lo busques activamente.

Esto mismo le pasó a un cliente mío con un plugin sencillo, una utilidad para mostrar imágenes del antes y el después, pero con una vulnerabilidad enorme, para la que me tocó preparar un parche, ante el abandono del plugin original.

Qué cierra esta puerta:

• Una política de actualizaciones por escrito: gratis y más eficaz que cualquier herramienta, con actualizaciones automáticas para versiones menores y plugins de confianza, prueba en staging para versiones mayores y plugins críticos (pasarela de pago, formularios, membresías), y cobertura semanal fija con copia de seguridad previa para todo lo demás.
• Una auditoría periódica de todo lo instalado: quién mantiene cada plugin y tema, cuándo se actualizó por última vez, si tiene vulnerabilidades conocidas en tu versión (consúltalo gratis en WPScan o Patchstack antes de instalar nada nuevo) y qué duplicidades funcionales puedes eliminar.
• Tolerancia cero con lo nulled o de procedencia desconocida, y decisión inmediata sobre cualquier extensión activa sin actualizaciones disponibles porque el desarrollador desapareció o la licencia caducó, pues eso es código congelado y sin parches, una decisión estratégica y no un detalle técnico.
• Desinstalar lo que no se usa, incluidos los temas de repuesto que se quedan «por si acaso», porque un tema desactivado sigue siendo código explotable presente en el servidor.
• Vigilancia diaria de los cierres del repositorio: Esta detección automática es, hoy por hoy, casi exclusiva de Vigilante, que consulta la API de wordpress.org cada día por cada plugin instalado, activo o no, y avisa con fecha y motivo si alguno ha sido cerrado o retirado.
• Un cortafuegos de aplicación como red de contención, activo desde el primer día aunque sea con la configuración por defecto, con esto bloqueas los patrones de explotación más comunes y la ejecución de PHP en la carpeta de uploads, de modo que frena el ataque incluso cuando el plugin vulnerable siga instalado.
• Ponérselo más difícil al escaneo automatizado: ocultar la versión de WordPress del código fuente, los feeds y las URL de scripts, y eliminar los readme.html y license.txt de la raíz, que la revelan a cualquiera.
• Si el tema es a medida, comprobar que usa tema hijo (un padre modificado directamente pierde los cambios en la próxima actualización) y que está claro quién paga y renueva cada licencia, además, documenta esa revisión con un informe como el que genera la auditoría de temas, te da la referencia para la siguiente.

Cómo comprobar que está cerrada:

• Abre el código fuente de tu portada y busca generator y ver=: si aparece tu versión exacta de WordPress, sigue visible.
• Sube un archivo PHP de prueba a la carpeta uploads por el medio que uses habitualmente e intenta ejecutarlo desde el navegador, debería devolver un error, no ejecutarse.
• Fecha de la última auditoría de extensiones y número de plugins desinstalados en ella: si la respuesta es «nunca» y «cero», ahí tienes el primer hueco.
• Comprueba que tu escáner de integridad tiene programada una exploración automática y cuándo fue la última.

Puerta 2 – Las personas y sus credenciales

La segunda puerta ni siquiera necesita una vulnerabilidad y es que WordPress regala por defecto la lista de nombres de usuario, puesto que su misma API REST responde en tudominio.com/wp-json/wp/v2/users a cualquiera que pregunte, y las URL del tipo ?author=1, ?author=2 redirigen al archivo público de cada autor.

Con esa lista y las colecciones de contraseñas filtradas que circulan por internet, un bot solo tiene que probar combinaciones en tu formulario de acceso, y si XML-RPC está activo puede probar cientos por petición gracias a su método system.multicall.

La otra variante ni siquiera requiere bots. Es el típico caso de la agencia de hace dos años que conserva un acceso de administrador, la cuenta compartida entre tres personas, el ex-compañero al que nadie dio de baja. El error humano, no un ataque brillante, es la causa más habitual de una brecha.

Qué cierra esta puerta:

• Identificación en dos pasos (2FA) obligatoria para todos los perfiles de editor para arriba, con aplicación de verificación (TOTP) o código por email, exigible por perfil desde tu plugin de seguridad.
• Mínimas capacidades con los perfiles por defecto (administrador, editor, autor, colaborador, suscriptor), creando un perfil a medida antes que subir a nadie a administrador por comodidad.
• Caducidad de contraseñas con historial que impida reutilizar las últimas, sobre todo en administradores, y límite de sesiones simultáneas por usuario si trabajas con externos que entran y salen de proyectos.
• Cierre de la enumeración y del XML-RPC desde tu plugin de seguridad o con código, y URL de acceso personalizada en lugar de /wp-login.php, que elimina la mayoría del tráfico automatizado contra el formulario.
• Un gestor de contraseñas con espacios compartidos por equipos (Bitwarden, por ejemplo, tiene versión gratuita para empezar y planes de equipo económicos), que acaba con las contraseñas en hojas de cálculo y en hilos de correo.
• Una lista de bajas para cuando alguien deja la empresa o termina un proyecto, donde reflejar quién tiene/tenía acceso a WordPress, panel del hosting, registrador del dominio, CDN, Search Console y cualquier servicio conectado. Un usuario por persona, con nombre real, o esta lista será imposible de aplicar.
• Un registro de auditoría que capture accesos, cambios de usuarios y activación de plugins, filtrable y exportable. Esto es lo que convierte «alguien tocó algo» en «este usuario hizo esto a esta hora».
• Formación básica del equipo: no reutilizar contraseñas, desconfiar de enlaces y adjuntos inesperados, saber a quién avisar ante algo raro, es gratis, y más rentable que cualquier herramienta.

Cómo comprobar que está cerrada:

• Visita por tu cuenta dominio.com/wp-json/wp/v2/users y dominio.com/?author=1: ninguna de las dos debería revelar nombres de usuario.
• Cuenta cuántos administradores hay y asegúrate, uno a uno, que de verdad lo necesitan.
• Busca cuentas sin acceso en los últimos seis meses y accesos de proyectos ya cerrados.
• Haz el simulacro de baja: si una persona concreta se fuera mañana, ¿cuántos servicios habría que tocar y tienes la lista?

Puerta 3 – El alojamiento y el servidor

La tercera puerta está fuera de WordPress. Aquí hablamos de que, por ejemplo, una versión de PHP al final de su vida útil deja de recibir parches de seguridad aunque todo lo demás esté al día.

Muy típico es también utilizar un hosting compartido sin aislamiento entre cuentas, lo que convierte el ataque al vecino en un ataque a tu web.

Otro caso habitual es un listado de directorios abierto, lo que permite a cualquiera pasearse por /wp-content/uploads/ y descargar lo que encuentre, y lo mismo pasa con permisos de archivo demasiado generosos, que dejan que un proceso comprometido escriba en wp-config.php o .htaccess, los dos archivos donde una sola línea inyectada sobrevive incluso a reinstalar WordPress.

Y hay un problema más en esta puerta, la disponibilidad, porque una caída también es un incidente y cuesta dinero. Según los cálculos que hice para una conferencia que di en GoDigital de Valencia en 2025, un e-commerce pequeño pierde entre 50 y 200 € por minuto caído, una web corporativa entre 20 y 50 contactos comerciales por hora, y un restaurante sin sistema de reservas entre 500 y 1.500 € por noche.

El día que tu web salga en televisión o una campaña funcione de verdad, la diferencia entre un hosting que escala y uno que se cae es facturación directa.

Qué cierra esta puerta:

• Un hosting que cumpla los mínimos exigibles: HTTP/2 o HTTP/3, versiones de PHP y MySQL o MariaDB actualizadas y cambiables por ti sin tiques de soporte, configuración de seguridad específica para WordPress, aislamiento real de cuentas incluso en planes compartidos, soporte técnico especializado en WordPress, recuperación automática ante caídas y capacidad de absorber picos de tráfico. Si el tuyo no los cumple cambiar de hosting es la medida de seguridad más rentable de esta sección.
• Tres constantes en wp-config.php (primer bloque de código más abajo): desactivan el editor de archivos, fuerzan HTTPS en el escritorio y evitan que los errores de PHP se muestren a los visitantes.
• HTTPS en todo el sitio con HSTS (segundo bloque de código de abajo), para que el navegador ni siquiera intente la conexión sin cifrar la próxima vez.
• El resto de cabeceras de seguridad (Content Security Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy), que puedes generar listas para Apache, Nginx o PHP con este generador de cabeceras gratuito.
• Permisos de archivo correctos: 644 para archivos, 755 para directorios, y 440 o 400 para wp-config.php si el hosting lo permite sin romper nada, además de Options -Indexes en el .htaccess para cerrar el listado de directorios.
• Un security.txt en /.well-known/ siguiendo el estándar RFC 9116, para que un investigador que encuentre un fallo sepa cómo avisarte de forma responsable en vez de publicarlo.
• Vigilancia de integridad de wp-config.php y .htaccess: tu plugin de seguridad debería guardar una copia de referencia con suma de verificación y avisarte con un diff línea a línea si algo cambia sin que hayas sido tú.
• Copias de seguridad verificadas y fuera del servidor: restaura una de prueba en un entorno aparte antes de necesitarla en serio, porque una copia alojada en la misma máquina que protege no vale nada el día que esa máquina falle.
• Monitorización de disponibilidad externa, para enterarte tú antes que tus clientes: servicios gratuitos como UptimeRobot comprueban la web cada cinco minutos y avisan por correo en cuanto deja de responder.

// Desactivar el editor nativo de plugins y temas
define( 'DISALLOW_FILE_EDIT', true );
 
// Forzar HTTPS en wp-admin
define( 'FORCE_SSL_ADMIN', true );
 
// Nunca mostrar errores a visitantes, solo registrarlos
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>
 
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

El reparto de responsabilidad con tu hosting conviene confirmarlo por escrito, porque la letra pequeña cambia mucho de un proveedor a otro:

Cómo comprobar que está cerrada:

• Pasa un análisis externo de cabeceras y exposición: el análisis de seguridad hace más de 30 comprobaciones gratis y al instante, sin instalar nada.
• Pregunta a tu hosting, por escrito, qué versión de PHP ejecutas y hasta cuándo recibe parches de seguridad.
• Restaura un backup de prueba en un entorno aparte al menos una vez por semestre y anota cuánto tardaste y si todo se restauró perfecto.
• Recuerda la última caída: ¿te avisó tu monitorización o te avisó un cliente?

Puerta 4 – El perímetro: dominio, correo y proveedores

La cuenta del registrador del dominio sin identificación en dos pasos es el secuestro perfecto pues quien la controle cambia las DNS y se lleva tu web, tu correo y tu marca a otro servidor, con tu WordPress intacto y perfectamente asegurado en el hosting de siempre.

El correo del dominio es la variante silenciosa ya que WordPress y WooCommerce envían correos transaccionales a diario, y un dominio sin DMARC puede ser suplantado por cualquiera para hacer phishing a tus propios clientes con tu remitente y tu marca, sin tocar un solo archivo tuyo.

Los proveedores externos (la agencia, el desarrollador puntual, el servicio conectado por API) son accesos más que habituales que rara vez están inventariados.

Qué cierra esta puerta:

• 2FA y bloqueo de transferencia en el registrador del dominio, hoy mismo: es la cuenta más valiosa de toda tu infraestructura y suele ser la menos protegida.
• Inventario de quién controla qué: dominio, zonas DNS, correo y cada servicio conectado, con un responsable con nombre por fila. Vale una hoja de cálculo, lo que no vale es que la respuesta sea «creo que lo llevaba el informático anterior».
• SPF, DKIM y DMARC en el dominio: el SPF declara qué servidores pueden enviar correo en tu nombre, el DKIM firma cada mensaje (lo genera tu proveedor de correo desde su panel, no es un registro que puedas copiar de una guía) y el DMARC dicta qué hacer con lo que no pase esas comprobaciones. Empieza con el DMARC en modo observación y endurece cuando los informes vengan limpios; tienes los registros de ejemplo más abajo.
• Registro de licencias con titular y fecha de renovación de cada tema y plugin de pago: una licencia que caduca sin que nadie lo sepa es código congelado, y eso te devuelve directo a la puerta 1.
• Acceso de proveedores por escrito: qué puede tocar cada uno, con qué cuenta y hasta cuándo, revocable el día que termina el proyecto. Esto además conecta con el contrato de encargo de tratamiento del bloque legal.

Registros de ejemplo, adaptando dominio y proveedor de correo a los tuyos:

; SPF: declara quien puede enviar correo por ti
; (el include depende de tu proveedor: este es el de Google Workspace)
tudominio.com.  TXT  "v=spf1 include:_spf.google.com ~all"
 
; DMARC, fase 1: solo observar, nada se bloquea todavia
; (recibiras informes de quien envia correo usando tu dominio)
_dmarc.tudominio.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@tudominio.com"
 
; DMARC, fase final tras unas semanas de informes limpios
; (p=quarantine como paso intermedio si prefieres endurecer poco a poco)
_dmarc.tudominio.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@tudominio.com"

Cómo comprobar que está cerrada:

• Consulta tu registro DMARC con cualquier comprobador gratuito (MXToolbox o dmarcian, por ejemplo): si no existe es que tu dominio es suplantable desde ayer.
• Entra en la cuenta del registrador y verifica dos cosas: que pide segundo factor y que el bloqueo de transferencia está activo.
• Abre el inventario de accesos y licencias: si no existe, esa es la tarea urgente de esta semana.

Tiendas online con WordPress – Riesgos específicos de WooCommerce

El ataque más frecuente contra un WooCommerce pequeño no busca robarte, busca usarte. Me refiero a bots que prueban tarjetas robadas en tu pasarela de pago (lo que se conoce como card testing) haciendo cientos de micropedidos que a ti te generan comisiones por transacción fallida, disputas y, si se acumulan, la suspensión de la cuenta en la pasarela.

La segunda variante es el registro masivo de cuentas falsas, que ensucia tu base de clientes y prepara fraudes posteriores.

Y la tercera no es un ataque sino una acumulación. Cada pedido guarda datos personales, y una base con años de pedidos completos es superficie expuesta el día de una brecha y responsabilidad directa ante el RGPD.

Qué lo cierra, todo gratis:

• Verificación antibots en el pago y el registro: Cloudflare Turnstile es gratuito y menos molesto que un captcha clásico, y la mayoría de plugins de formularios y de seguridad lo integran.
• Límite de intentos de pago por IP y por sesión, desde el cortafuegos de tu plugin de seguridad o desde la propia pasarela, que suele incluir reglas antifraude configurables sin coste.
• Revisión semanal de patrones de fraude: rachas de pedidos fallidos de importe mínimo, muchas cuentas nuevas sin compra asociada, picos de registro a horas extrañas.
• Retención de datos con caducidad: WooCommerce trae herramientas de limpieza y anonimizado en «Ajustes → Cuentas y privacidad». Configúralas y deja de acumular pedidos identificables de hace cinco años que ya no necesitas.

Cómo comprobar que está cerrada:

• Consulta en el panel de tu pasarela la proporción de transacciones rechazadas del último mes: si supera con claridad a la de meses anteriores, ya te están usando.
• Cuenta las cuentas de cliente creadas en los últimos 30 días sin ningún pedido asociado.
• Abre un pedido de hace tres años y mira qué datos personales sigue guardando.

Obligaciones legales y de privacidad siempre aplicables

Si tu WordPress recoge datos personales de clientes, usuarios registrados o simples visitantes que rellenan un formulario, estás sujeto al RGPD y a la Ley Orgánica de Protección de Datos, con independencia del tamaño de la empresa.

El RGPD exige aplicar medidas de seguridad adecuadas al riesgo, así que una brecha de seguridad es casi siempre también una brecha de protección de datos, con plazos y sanciones concretos.

La notificación a la AEPD debe hacerse en un máximo de 72 horas, con multas de hasta 10 millones de euros o el 2 % de la facturación para las infracciones graves (entre ellas, no notificar a tiempo) y de hasta 20 millones o el 4 % para las más graves.

Las sanciones a autónomos y pymes suelen moverse en varios miles de euros, lejos de los titulares millonarios pero suficientes para hacerte un agujero importante.

Qué hacer:

• Documenta cualquier incidente de seguridad, aunque decidas no notificarlo: el RGPD exige registrar internamente el análisis que llevó a esa decisión, precisamente para poder demostrarlo si la AEPD pregunta.
• Deja por escrito, en un contrato de encargo de tratamiento, quién es el responsable y quién el encargado cuando trabajas con una agencia o un servicio externo.
• Aplica minimización de datos: no guardes en formularios ni en la base de datos más datos personales de los estrictamente necesarios, porque cada campo de más es superficie expuesta de más el día que algo falle.
• Revisa avisos de cookies y política de privacidad con regularidad: están entre los motivos más frecuentes de sanción a pequeños negocios, haya habido o no una brecha técnica.
• Interioriza el plazo de las 72 horas antes de que ocurra un incidente, no durante: es la diferencia entre reaccionar con un protocolo decidido o improvisar bajo presión legal además de técnica.

Nada de esto sustituye el asesoramiento de un abogado especializado si la empresa maneja datos sensibles o de gran volumen.

Si ya te han entrado – Protocolo de las primeras horas

Aun con las cuatro puertas cerradas, un incidente sigue siendo posible, y cómo se reaccione en las primeras horas determina si se queda en un susto contenido o se convierte en una crisis larga.

Las señales de que algo va mal serían estas:

• Contenido, páginas o redirecciones que nadie de tu equipo ha creado.
• Picos de tráfico extraños, sobre todo dirigidos al login o al área de administración.
• Usuarios, plugins o temas nuevos que no reconoces.
• Entradas de registro anómalas: intentos de acceso repetidos, direcciones IP desconocidas, archivos modificados sin explicación.
• Avisos del navegador, de Google Search Console o de tu propio hosting marcando el sitio como inseguro o con malware.

Si aparece cualquiera de esas señales, el orden es importante:

1. Aísla el sitio: Activa el modo mantenimiento o restringe el acceso público mientras investigas, y si tu plugin de seguridad incluye un modo de emergencia con desafío para visitantes, es el momento de activarlo. El objetivo es frenar el daño sin perder lo que necesitarás analizar después.
2. Comunica con transparencia: en paralelo a la parte técnica, a quien pueda verse afectado. Tener el mensaje redactado de antemano evita improvisar bajo presión; en esta recopilación de recursos gratuitos tienes plantillas de comunicación de crisis, una lista de comprobaciones de acción inmediata y la calculadora de coste de caída con la que salen las cifras de la puerta 3 que te contaba antes.
3. Conserva una copia del estado comprometido antes de tocar nada, útil tanto para el análisis técnico como para una eventual denuncia o parte al seguro.
4. Restaura desde la copia de seguridad limpia más reciente, verificada y anterior al momento de la brecha.
5. Cambia todas las credenciales: contraseñas de todos los usuarios, no solo del administrador, además de las claves de la base de datos, las de API de servicios conectados y las de acceso al hosting y al registrador.
6. Ejecuta un escaneo completo de malware e integridad de archivos para confirmar que no queda ningún resto: puertas traseras, archivos añadidos o código inyectado que la restauración no haya eliminado.
7. Identifica y corrige la causa raíz (el plugin desactualizado, la contraseña débil, el permiso mal configurado) antes de volver a publicar, o el ataque se repetirá en cuanto el sitio vuelva a estar visible.
8. Evalúa la obligación de notificar a la AEPD y a los afectados si hay datos personales comprometidos, dentro del plazo de 72 horas.

Si la gestión del incidente supera la capacidad del equipo, o si el sitio maneja datos sensibles o pagos, merece la pena contar con apoyo externo especializado en recuperación de webs hackeadas, sea el mío, el de Sucuri como referencia internacional de pago o el equipo de seguridad de tu propio hosting si lo tiene, porque el tiempo que se ahorra evitando errores en caliente suele compensar el coste del servicio.

Con qué aplicarlo – Plugins y servicios recomendados

A lo largo de la guía he escrito varias veces «tu plugin de seguridad» sin concretar cuál, y toca hacerlo. Las opciones serias del mercado gratuito son Vigilante, Wordfence, Kadence Security y SG Security, que comparé función a función en este análisis de plugins de seguridad.

Vigilante es mío y lo uso en mis webs y en las de mis clientes, así que ya conoces el sesgo y puedes descontarlo, aunque cualquiera de los otros cumple razonablemente si se configura bien y se revisa a conciencia.

Además, te recomiendo llevar un registro de todo consentimiento que se haga en tu web, y como para esta necesidad no había nada suficientemente completo creé estos plugins, que como todos están disponibles gratis en WordPress.org o tu instalador de plugins:

• Registro de consentimientos de términos y condiciones: para llevar un registro legal de todos los consentimientos que pides en tu web, totalmente integrado con los ajustes de privacidad de WordPress.
• Cumplimiento del derecho de desistimiento de la UE: todo lo que necesitas, con tienda o sin ella, para registrar y cumplir con el derecho a desistimiento.

La otra decisión es quién aplica todo esto, si alguien de dentro o un servicio externo. Si decides delegarlo, sea en una agencia de confianza, en el plan de cuidado de algunos hostings gestionados o en un servicio de mantenimiento especializado como el que ofrezco yo mismo, exige que cubra como mínimo:

• La política de actualizaciones de la puerta 1, con prueba en staging y copia previa.
• Copias de seguridad verificadas, con restauración de prueba periódica y almacenadas fuera del servidor.
• Monitorización de disponibilidad e integridad con avisos, no solo un informe mensual.
• Revisión periódica de accesos, usuarios y extensiones instaladas.
• Protocolo de incidentes por escrito, con tiempos de respuesta comprometidos.

Con esa lista delante puedes evaluar cualquier presupuesto, incluido el mío. Un servicio que no restaura copias de prueba ni revisa accesos no está manteniendo tu web por mucho que actualice plugins.

Plan de arranque – Por dónde empezar

Si no tienes ninguna pieza de esta guía montada todavía, no intentes cerrarlo todo el mismo día. Este orden da más protección por minuto invertido:

1. Activa 2FA en WordPress para administradores y editores, y en la cuenta del registrador del dominio.
2. Fuerza contraseñas largas con caducidad, elimina usuarios del tipo admin o test, y pon en marcha el gestor de contraseñas de equipo.
3. Cierra la enumeración de usuarios, cambia la URL de acceso y desactiva XML-RPC si no lo usas.
4. Activa cortafuegos y escáner de integridad, aunque sea con la configuración por defecto del primer día.
5. Audita plugins y temas, desinstala lo que sobre y deja por escrito la política de actualizaciones.
6. Fuerza HTTPS en todo el sitio, revisa permisos de archivo y publica un security.txt.
7. Restaura un backup de prueba y saca las copias del servidor.
8. Publica DMARC en modo observación y comprueba tu SPF.
9. Verifica que tu hosting cumple los mínimos de la puerta 3 y activa la monitorización externa.
10. Documenta el protocolo de brechas (con las 72 horas de la AEPD dentro), prepara la plantilla de comunicación y forma al equipo en lo básico.

Y una advertencia final, nada de esta lista es tarea para realizar una sola vez. Agenda las revisiones (trimestral para accesos y extensiones, semestral para restaurar un backup de prueba) y trata la seguridad como lo que es, mantenimiento continuo y no un proyecto con fecha de fin.

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

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

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

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

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

Vamos a verlo con calma.

Ah ¿pero se puede bloquear a las IAs?

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

Con esa idea clara esto es lo que hay.

Señales declarativas (piden, no obligan)

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

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

Bloqueo real y efectivo (impide de verdad)

Aquí quería llegar yo…

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

Espera que hay más

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

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

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

Cómo se bloquea a las IAs

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

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

A mano, en tu robots.txt:

User-agent: GPTBot
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Google-Extended
Disallow: /

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

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

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

Las metas noai y el noimageai

En la cabecera de tu web, así:

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

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

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

Las Content Signals (y su respaldo legal)

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

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

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

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

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

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

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

El bloqueo con 403 por .htaccess o por PHP

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

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

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

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

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

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

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

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

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

Cobrar por el acceso: 402 y x402

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

El problema son todos los demás.

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

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

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

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

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

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

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

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

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

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

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

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

Cuándo bloquear SÍ tiene sentido

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

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

Cuándo bloquear sería un grave error

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

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

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

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

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

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

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

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

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

La decisión, con todo en la mano

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

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

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

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

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

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

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

Mi consejo, por si te sirve

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

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

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

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

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

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

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

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

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

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

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

Y no, eso en las consultas no sale.

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

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

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

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

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

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

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

En fin, que este es el nene:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Interpretar el reparto de tiempos

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Vamos a verlo con calma.

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

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

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

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

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

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

Herramientas básicas

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

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

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

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

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

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

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

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

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

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

Crítico

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

Importante

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

Menor

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

Entorno y servidor

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

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

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

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

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

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

Crítico

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

Importante

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

Menor

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

El núcleo de WordPress y ajustes que nadie revisa

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

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

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

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

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

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

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

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

Crítico

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

Importante

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

Menor

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

El tema WordPress y sus personalizaciones

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

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

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

Crítico

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

Importante

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

Menor

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

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

Los plugins

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

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

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

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

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

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

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

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

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

Crítico

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

Importante

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

Menor

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

La SEGURIDAD

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

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

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

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

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

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

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

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

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

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

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

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

Crítico

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

Importante

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

Menor

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

Rendimiento y velocidad de carga

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

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

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

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

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

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

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

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

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

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

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

Crítico

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

Importante

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

Menor

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

SEO / AEO técnico

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

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

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

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

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

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

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

Crítico

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

Importante

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

Menor

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

Visibilidad IA

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

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

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

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

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

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

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

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

Crítico

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

Importante

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

Menor

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

Legalidad técnica y funcional

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Crítico

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

Importante

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

Menor

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

Tienda online

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

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

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

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

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

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

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

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

Crítico

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

Importante

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

Menor

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

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

Multisitio: auditar una red no es auditar una web

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Crítico

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

Importante

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

Menor

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

El informe

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

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

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

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

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

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

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

Herramientas gratuitas

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

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

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

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

Prompts de IA útiles en auditorías

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

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

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

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

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

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

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

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

¿Cada cuánto repetir todo esto?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Mira qué fácil es impedir el unfiltered_html

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

define( 'DISALLOW_UNFILTERED_HTML', true );

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

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

¿Se rompe algo si quito el unfiltered_html?

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

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

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

Entonces, ¿cuándo la activo?

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

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

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

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

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

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

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

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

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

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

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

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

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