El miércoles no hubo Doctor WordPress porque estaba en el WordPress Agency Forum de Madrid, así que esta semana te dejo el resumen de las Crónicas solamente. La semana que viene vuelvo con las dos sesiones.

Crónicas WordPress: dos semanas de noticias en un solo directo

WordPress 7.1.2, de las actualizaciones que no se pueden dejar para mañana

Empecé por lo más serio. WordPress 7.1.2 salió el 22 de septiembre y corrige un único fallo, pero de los gordos, con una puntuación CVSS de 9,2 (el estándar con el que se mide la gravedad de las vulnerabilidades). Permitía a un atacante conseguir que WordPress incluyera un archivo PHP de su elección desde fuera de la carpeta del tema y, a partir de ahí, ejecutar código en remoto.

Hacía falta que el tema activo cumpliera cierta condición en su estructura de carpetas, algo que se da en un montón de temas muy usados. Se informó el 20 de julio y se arregló con divulgación responsable, en secreto, como debe ser. El problema es que ya había gente aprovechando la vulnerabilidad, hasta el punto de que se avisó a agencias gubernamentales de Estados Unidos. Si todavía no estás en la 7.1.2, ya estás tardando.

Un malware que se reconstruye solo y 50.000 credenciales robadas

Sucuri ha detectado un malware para WordPress que da un poquito de miedo. Se esconde en el .user.ini, en los drop-ins de caché como advanced-cache.php, en el functions.php de un tema falso o como plugin obligatorio (mu-plugin). Se instala en ocho sitios distintos y cada copia es capaz de reconstruir a las demás, así que borras una y otra la vuelve a escribir, como un bicho de muchas cabezas.

Casi siempre entra por temas y plugins «gratis» de procedencia dudosa. Te ahorras 60 dólares al año en un negocio con el que se supone que vas a ganar dinero y acabas regalando tu web para que mine criptomonedas. Tú verás.

También comenté el caso de un kit de herramientas que, a gran escala, ha robado unas 50.000 credenciales de acceso buscando copias de seguridad olvidadas, como un wp-config.php.bak, un debug.log o las contraseñas que guardan algunos plugins de correo SMTP. Ojito con lo que dejas tirado en el servidor.

Aproveché para hablar de Vigilante 3.0.0, que ahora intenta autoprotegerse. No es invulnerable (nada lo es, y el propio plugin tuvo su vulnerabilidad, de la que aprendí bastante y que os contaré en el blog), pero se trata de ponerle al campo todas las puertas que puedas.

Elementor y un clic que crea administradores

Elementor ha tenido una semana movidita. Patchstack publicó el 25 de septiembre una vulnerabilidad CSRF (falsificación de peticiones entre sitios) en las versiones 4.3.0 y 4.3.1, con un CVSS de 8,8. Un administrador con la sesión abierta que hiciera clic en un enlace manipulado podía crear, sin enterarse, otra cuenta de administrador para el atacante. Está corregida desde la 4.3.2, y con los millones de webs que lo usan todavía queda muchísima gente sin actualizar.

Ya que hablábamos de actualizar, os enseñé mi guía sobre por qué WordPress se actualiza sin tu permiso aunque hayas desactivado las actualizaciones automáticas. Muchos hostings tienen su propio sistema, que trabaja en un plano donde lo que pongas en WordPress les da igual, y en la guía repaso los tres casos (alojamiento gestionado, compartido con autoinstalador y servidor propio) y cómo controlar cuándo se actualiza. Mi consejo sigue siendo actualizar, y si tu hosting lo hace por ti y encima hace copia antes, te está haciendo un favor.

Comunidad: WordPress al frente de la Open Website Alliance y adiós a Meetup

La parte alegre. WordPress, a través de la WordPress Foundation, ha asumido la presidencia rotatoria de la Open Website Alliance, la coalición que agrupa a las organizaciones detrás de WordPress, Drupal, Joomla, TYPO3 y compañía. Se anunció el 25 de septiembre y una de sus líneas de trabajo es la Ley de Ciberresiliencia europea, sobre la que firmaron un informe en agosto. Las normativas europeas tienen su parte buena, siempre que no se vayan de olla y no frenen la innovación con la excusa de protegernos.

La otra noticia chula es events.wordpress.org: la comunidad va a dejar Meetup.com para usar un sistema propio integrado en WordPress.org. Ya se ha hecho formación para organizadores y el piloto está en marcha. El punto débil es que, por privacidad, probablemente no se migren las listas de asistentes y haya que animar a la gente a registrarse de nuevo. Si organizas un meetup en España o en cualquier país hispanohablante, te animo a apuntarte al programa piloto desde el equipo de comunidad en make.wordpress.org/community.

Y octubre viene animadísimo:

• WordPress Agency Forum, el 7 de octubre en Madrid, un evento para profesionales con mucho trabajo en grupo y aforo muy limitado.
• WordPress Accessibility Day, el 7 y 8 de octubre, online y gratuito, desde las 17:00 (hora peninsular) y con el responsable de accesibilidad de GitHub abriendo el programa.
• Meetups en Palma, Collado Villalba y León, entre otros.
• Meetup de A Coruña el 15 de octubre, donde daré una charla sobre seguridad en WordPress con presupuesto cero.
• WordCamp Galicia, el 16 de octubre en A Coruña, donde daré un curso gratuito de WordPress a primera hora.
• WordCamp Valencia, el 31 de octubre, donde también tendré la suerte de dar una charla.

WooCommerce 11.2 y las nuevas obligaciones europeas

WooCommerce 11.2 tenía que salir el 6 de octubre con estas novedades:

• Correos configurables para el derecho de desistimiento.
• Campos de fecha en la API de pago con el selector nativo del navegador, útiles para fechas de nacimiento o de entrega.
• Un importador CSV que por fin encuentra productos por GTIN, UPC, EAN o ISBN cuando no hay ID ni SKU.

Lo del checkout basado en agentes de IA se ha aparcado, así que eso no romperá nada. Lo que sí conviene revisar con tu desarrollador son los filtros de fecha si tienes algún desarrollo a medida.

Hablando de obligaciones de la UE, he actualizado mi plugin de derecho de desistimiento para que también muestre la etiqueta de garantía legal, obligatoria desde el 27 de septiembre para quien venda bienes físicos en la Unión Europea. Revisé los plugins que había, ninguno lo daba todo gratis, así que se lo añadí al mío en una mañana. En el artículo os comparo las opciones y elegís vosotros.

Lo último que he publicado en el blog

También repasé algunos artículos recientes de Ayuda WordPress que creo que os pueden venir bien:

• Las zonas, clases y métodos de envío de WooCommerce, de lo más raro que tiene el plugin desde siempre y de lo que más me preguntan los clientes.
• Cómo servir actualizaciones automáticas de tus propios plugins y temas desde tu web, con el sistema nativo de WordPress y sin obligar al cliente a instalar nada extra. Es lo que uso con plugins premium como Intelimerce.
• Dónde poner el código que comparto: functions.php solo para lo que depende del tema, un plugin propio para lo demás y ojo con abusar de los mu-plugins.

Multisitio, robots.txt y un usuario que me hace trabajar

Saludé a Albert Calzada, un usuario de Vigilante con una red multisitio que me ha ido avisando de cosas mejorables, y gracias a él Vigilante 3.1 se lleva bastante mejor con multisitio. Yo recomiendo multisitio para muy pocos casos (él lo usa para webs multilingües, uno de los pocos donde tiene sentido), y por eso casi ningún plugin está bien preparado para él.

Un ejemplo práctico: en una red multisitio con dominios mapeados, si tienes un robots.txt físico en el sitio principal, todos los sitios comparten ese mismo archivo. La solución es tirar del robots.txt virtual que WordPress genera de serie y que mi plugin SEO Visibility permite editar por sitio, igual que el llms.txt. Así lo resolví con un cliente que quería bloquear los PDF en el sitio principal pero no en los subsitios.

WordPress e IA: Novamira, Presence API y un invento raro de Automattic

Novamira es un plugin que conecta agentes de IA con WordPress mediante un servidor MCP (que, para entendernos, funciona como una API para agentes). Da acceso a ejecución de PHP, sistema de archivos, base de datos, WP-CLI y Gutenberg, se configura con abilities, skills en Markdown y políticas propias, y tiene versión gratuita y una Pro por 49 al año. Me han pedido compatibilidad con SEO Visibility y lo más probable es que le añada la Abilities API (Vigía ya la tiene). Casi todos los consejos de un chatbot sobre WordPress fallan porque no sabe qué hay en tu web, y con este tipo de integración sí lo sabe.

También comenté la Presence API, presentada en abril, que muestra en la barra de administración una etiqueta cuando un agente de IA está editando por API o MCP.

Y lo que más me sorprendió: Automattic ha lanzado sin hacer ruido una plataforma que convierte lo que genera un agente de IA en una web con su propia dirección, al estilo de Astro o Next.js. Lo que no entiendo es que, cuando en Twitter le preguntaron a Matt qué iba a hacer WordPress para competir con este tipo de herramientas, enlazara esto. Con todo lo que tiene WordPress ahora mismo (MCP, Abilities API, Presence API), promocionar otra cosa me parece un tiro en el pie.

SEO: Google, cada vez más peaje y menos tráfico

Las AI Overviews ya aparecen en el 80 % de las búsquedas de marca, y sus enlaces ni siquiera llevan a la web de la marca, sino al modo IA. Además, Merchant Center ha activado automáticamente el checkout nativo en el modo IA y en Gemini para las tiendas compatibles con UCP (un protocolo parecido a MCP pero para comercio electrónico). Puedes vender ahí, sí, pero es como Amazon: al final vas a pagar un peaje.

Google ya ha empezado a pagar a unos 100 medios por usar su contenido en las vistas creadas con IA, en un programa piloto que supone en torno al 0,1 % de sus ingresos publicitarios. Migajas, pero algo es algo. Y mientras tanto sus directrices piden revisar a mano todo el contenido hecho con IA y dicen que el bueno es el humano, justo el que se está quedando sin incentivos porque ni le dan tráfico, ni enlaces, ni dinero. Pone normas como si fuera la Unión Europea, pero no hace nada por devolver el tráfico.

Un hackeo con spam japonés y por qué un 410 lo arregló

Os conté el caso que explico en mi artículo sobre redirecciones 301, errores 404 y 410. A un cliente le hackearon la web y le llenaron Google de URLs con spam en japonés que desplazaron sus resultados de toda la vida (con los maravillosos filtros antispam de Google mirando para otro lado). Después de limpiar la web, marcar esas URLs con un 410 hizo que en pocos días desaparecieran del índice y volvieran a salir las buenas. Lo hice con SEO Visibility, que para eso lo tengo.

También os enseñé el nuevo apartado de «navegación agéntica» que aparece en PageSpeed Insights, que incluso mira el llms.txt, a pesar de que Google dice que pasa de él. En un artículo os explico qué mide y si tenéis que hacer algo, porque vuestros clientes os lo van a preguntar. Para medir estas señales tenéis mi analizador de visibilidad y una auditoría SEO automática más completa, y si no os llega os ofrezco una personalizada.

Respondiendo a un comentario sobre si ayuda mandar traducciones de plugins a WordPress.org: ayuda muchísimo, aunque yo no pueda aprobarlas, porque hace que el plugin llegue a más gente en su idioma. Y aproveché para soltar una opinión mía: tengo la sensación de que en el directorio se confía menos en los desarrolladores con apellidos que no suenan anglosajones, algo que comentan mucho los desarrolladores de la India. Llámame loco, pero se nota.

Vídeo completo: Crónicas WordPress del 5 de octubre en YouTube

Si quieres asistir en directo y participar con tus preguntas, suscríbete al canal de Ayuda WordPress en YouTube.

Las dudas que me llegan son casi siempre estas, y las trataré de contestar todas a lo largo del artículo:

• Mi aviso legal y mi política de privacidad, ¿los pongo en Disallow, en noindex o en las dos cosas?
• ¿Los dejo en el mapa del sitio o los quito?
• ¿Por qué Google Search Console me dice que una página está indexada si yo la había bloqueado?
• ¿Qué hago con la página de agradecimiento, con los filtros de mi tienda o con esa entrada del blog que no pega con el resto?

Si lo tienes claro no sé que haces leyendo aún, sino pues tira, que aquí se viene a aprender, y un poco a discutir también…

Tres herramientas, tres preguntas distintas

La forma más fácil de recordarlo es pensar en un edificio de oficinas, o un centro comercial de varias plantas, lo que mejor te encaje o apetezca.

Digamos que el Disallow es el portero, que decide quién pasa a qué plantas o departamentos.  Luego estaría el noindex, que sería como un cartel dentro que dice algo como «Zona privada: prohibido el paso», y terminaríamos con el mapa del sitio, que sería el directorio de secciones o departamentos, de cada planta, que no muestra todo lo que hay, sino solo lo que quieres facilitar el acceso.

Otro modo de explicarlo, ya el de verdad, sería así:

• Disallow (en robots.txt): responde a «¿Puede pasar por aquí el rastreador/crawler?». Google explica en su documentación sobre el robots.txt que sirve sobre todo para no saturar tu web de peticiones y que no es un mecanismo para mantener una página fuera de Google, porque si otra web enlaza esa URL Google puede indexarla igualmente, aunque no haya podido leerla.
• Noindex (en el código fuente): responde a «¿Debe salir salir esta URL en los resultados de búsqueda?». Google entra, lee la página, encuentra la etiqueta (o la cabecera HTTP equivalente) y, según su guía del noindex, la saca por completo de los resultados, aunque otras webs la enlacen.
• Mapa del sitio (archivo wp-sitemap.xml o similar en la raíz del sitio): responde a «¿Quieres que pase a ver esta URL?». Es la lista de contenidos que te gustaría que aparezcan en las SERP, y así lo plantea la guía de Google para crear un sitemap. Que una URL esté en la lista no garantiza que se indexe, ojo, es solo tu forma de decirle cuáles prefieres.

El error más habitual: Disallow y noindex a la vez

Si bloqueas una URL con Disallow y además le pones noindex, el noindex no sirve de nada, porque el rastreador no llega a entrar para leerlo. Es el cartel de la oficina con el portero delante, y nadie llega a verlo.

Lo dice la propia guía del noindex de Google, y es que para que funcione la página no puede estar en Disallow en el robots.txt, porque si lo está el rastreador nunca verá la regla y la página puede seguir apareciendo en los resultados si otras páginas la enlazan.

En Search Console lo vas a ver como el aviso «Se ha indexado aunque un archivo robots.txt la tenía bloqueada», dentro del informe de indexación de páginas.

Google explica ahí que la página se ha indexado a pesar del bloqueo porque ha encontrado un enlace a ella en otra web, y que al estar bloqueada los snippets que salen en los resultados suelen ser muy limitados.

Pasa lo mismo al revés. Si quieres que Google sepa que una URL es noindex y no le dejas rastrearla, no se va a enterar. Lo que toca es dejar el noindex y quitar el Disallow, esperar a que Google vuelva a pasar y, cuando la URL ya haya salido de los resultados, decidir si además quieres ahorrarte el rastreo.

Qué usar en cada caso

Esta tabla resume los casos más habituales, y debajo explico los que necesitan algún matiz.

Los filtros y la ordenación de una tienda

Los filtros de WooCommerce (color, talla, precio…) generan una URL distinta por cada combinación, con parámetros como filter_, min_price, max_price u orderby.

En su guía sobre navegación por facetas Google recomienda que si no necesitas esas URLs indexadas bloquees su rastreo con el robots.txt, y del canonical y del nofollow dice que suelen ser menos efectivos a largo plazo. Un ejemplo sencillo sería este:

User-agent: *
Disallow: /*?*filter_
Disallow: /*?*min_price=
Disallow: /*?*max_price=
Disallow: /*?*orderby=

Si esas URLs ya están indexadas el Disallow no las va a sacar de Google, así que primero se pone el noindex , y cuando han desaparecido se bloquea. Y pruébalo siempre antes, que un patrón mal escrito puede llevarse por delante más URLs de las que querías.

El validador de robots.txt comprueba la sintaxis, y después conviene vigilar el informe de indexación de páginas de Search Console por si empiezan a aparecer URLs bloqueadas que no esperabas.

Ofertas, sorteos y empleos que ya han caducado

Si la página tiene enlaces o visitas, lo normal es redirigirla a la oferta vigente o a la categoría, y si no tiene nada que aportar, borrarla y dejar que dé un 410 o un 404.

Aquí el noindex solo tiene sentido si la página debe seguir existiendo para quien ya la conoce, como el histórico de ganadores de un sorteo. Lo tienes explicado con detalle en el artículo sobre qué hacer con la URL de un contenido borrado.

La entrada de blog que no tiene mucho que ver con el resto de tu web

Este es el caso más discutible, y lo siguiente es mi opinión y no una regla o algoritmo de Google. De hecho ya te anticipo que, que yo sepa, Google no dice en ningún sitio que una entrada totalmente ajena a la temática habitual perjudique al resto de tu web, lo que sí pregunta en su guía de contenido útil es si tu sitio tiene un propósito o un enfoque principal.

Tampoco te hagas ilusiones con borrar, porque esa misma guía avisa de que quitar mucho contenido antiguo para que el sitio parezca más fresco no funciona.

Mi criterio es que, si la entrada enseña de verdad a las personas del equipo, cuenta cómo trabajáis o qué os importa, funciona como una extensión de tu página de «Quiénes somos», así que lo dejaría indexable y, solo que si no quieres tampoco reforzarla, la dejes fuera del mapa del sitio.

Si es una entrada de blog puramente de relleno con tres fotos y dos líneas, la mejoraría, la fusionaría con otra o le pondría noindex y arreando. Y si al final la borras, pues que vaya con redirección o un bonito 410.

Contenido duplicado con canonical a otra URL

Cuando la misma página existe en dos URLs (un artículo que re-publicas en otro sitio, una variante de una landing), en el mapa del sitio va la URL que prefieres y no la otra.

Google lo recuerda en su guía de canonicalización, donde pide no indicar una URL en el mapa del sitio y otra distinta como canónica para la misma página. Y para elegir la canónica tampoco uses noindex, porque según esa misma guía bloquearía la página por completo en la búsqueda.

Si tu plugin de SEO no saca solo del mapa del sitio las páginas con canonical a otra URL (no todos lo hacen), sácala tú a mano.

¿Y qué hacemos con la mierda esa de las páginas legales, las indexamos o no?

Para empezar, ninguna norma te obliga a indexar el aviso legal, la política de privacidad o la de cookies, pero tampoco nada te lo prohíbe, lo que piden las legislaciones y reglamentos es que el usuario las vea fácilmente, que no las ocultes.

La LSSI, en su artículo 10, pide que los datos del titular de la web estén disponibles «de forma permanente, fácil, directa y gratuita», y la página oficial de la ley aclara que basta con que sean accesibles mediante enlaces visibles con títulos claros, como el típico «quiénes somos».

Con el RGPD pasa algo parecido, y la Agencia Española de Protección de Datos habla en su informe sobre políticas de privacidad de información de fácil acceso, con enlaces en el pie de página y al final de los formularios.

Ni la ley ni el informe de la AEPD mencionan a los buscadores. Eso sí, yo no soy abogado, así que si tu caso tiene alguna particularidad consúltalo con quien te lleve lo legal.

¿Y Google? En su documentación no he encontrado ninguna regla específica para las páginas legales, así que aquí no hay una verdad oficial a la que agarrarse y toca razonarlo con lo que hace cada herramienta.

• Disallow: no sirve para nada, porque no las saca de Google (si alguien las enlaza se pueden indexar igualmente) y encima impediría leer un noindex.
• noindex: las quitaría de los resultados, pero tus visitantes las seguirían encontrando en el enlace del pie, que es lo que pide la ley. Puedes hacerlo sin incumplir nada de lo que he leído, aunque tampoco ganas nada.
• Mapa del sitio: si las dejas indexables, van como cualquier otra página normal.

Mi consejo, y es solo eso, un consejo, es ni Disallow ni noindex, y si las tienes ahora mismo en noindex tampoco es ningún drama, de hecho yo mi me acordaba y las tenía así de siempre.

Queda el argumento del E-E-A-T, que es el otro que se oye mucho. Google dice en su guía de contenido útil que el E-E-A-T en sí mismo no es un factor de posicionamiento concreto, y cuando habla de lo que ayuda a fiarse de un sitio cita las páginas de autor y la de «Acerca de», sin nombrar las legales.

Lo que sí suma es que se vea quién está detrás de la web y, en una tienda, cómo son sus envíos y sus devoluciones, y por eso esas páginas van indexables en la tabla.

Aplicarlo en WordPress, a mano o con plugin

El Disallow va en el robots.txt. WordPress genera uno virtual que solo bloquea /wp-admin/ (dejando pasar el admin-ajax.php).

Puedes ampliarlo desde un plugin de SEO, y varios traen editor para ello (Visibility, el mejor mío incluido), o subiendo tú un archivo robots.txt real a la raíz de tu web.

Si no quieres escribirlo a mano, el generador de esa misma herramienta te crea uno con las carpetas y los bots que elijas.

Ah, y ojo con la opción «Pedir a los motores de búsqueda que no indexen este sitio» de los ajustes de lectura de tu WordPress, porque mucha gente cree que mete un Disallow: / y lo que hace desde WordPress 5.3 es poner noindex a todo el sitio, como conté en su día.

El noindex se pone por página, y para ello Yoast SEO, Rank Math, All in One SEO, SEOPress y Visibility tienen una casilla en el editor de cada entrada o página.

Si prefieres hacerlo a mano este código se lo añade a las páginas que le indiques:

// Añadir noindex a páginas específicas
add_filter( 'wp_robots', 'ayudawp_noindex_paginas_concretas' );

function ayudawp_noindex_paginas_concretas( $robots ) {
    // Reemplaza los slugs con las páginas que quieras dejar fuera de los resultados
    if ( is_page( array( 'gracias', 'pedido-recibido' ) ) ) {
        $robots['noindex'] = true;
    }

    return $robots;
}

Y con el mapa del sitio hay que ir con más cuidado, porque el nativo de WordPress no sabe nada de noindex y lista todas las páginas publicadas (salvo que uses Visibility, que se integra con él y te deja personalizar eso y más cosas).

Por lo que se ve en el código, WooCommerce pone noindex al carrito, al pago y a mi cuenta, pero no las quita del mapa del sitio, eso sería cosa tuya, así que compruébalo abriendo /wp-sitemap-posts-page-1.xml en tu web.

Los plugins de SEO (Yoast SEO, Rank Math, All in One SEO, SEOPress y Visibility) pueden quitar del mapa del sitio lo que marcas como noindex. Para sacar páginas concretas sin ponerles noindex, Rank Math y All in One SEO tienen una lista de exclusión, Visibility una casilla en cada entrada (la puedes ve en la captura de más arriba, y Yoast solo lo permite por código.

Con el mapa nativo, a mano si tu plugin no lo contempla, sería así:

// Dejar fuera del mapa del sitio de WordPress páginas específicas
add_filter( 'wp_sitemaps_posts_query_args', 'ayudawp_excluir_paginas_del_sitemap', 10, 2 );

function ayudawp_excluir_paginas_del_sitemap( $args, $post_type ) {
    if ( 'page' !== $post_type ) {
        return $args;
    }

    // Reemplaza lo siguiente con los IDs de las páginas que quieras dejar fuera
    $excluded = array( 123, 456 );

    $args['post__not_in'] = array_merge( (array) ( $args['post__not_in'] ?? array() ), $excluded );

    return $args;
}

Si dudas de dónde meter estos fragmentos, lo tienes explicado en el artículo sobre dónde pegar códigos PHP, JS y CSS en WordPress.

Comprobarlo en Search Console

Con la herramienta de inspección de URLs ves cómo ha rastreado e indexado Google una página concreta, y en el informe de indexación de páginas te salen los avisos que más te interesan aquí.

• «Se ha indexado aunque un archivo robots.txt la tenía bloqueada»: es el error de Disallow más noindex del que hablábamos, y se arregla quitando el Disallow.
• «Página alternativa con etiqueta canónica adecuada»: es lo normal en las páginas que apuntan con su canonical a otra, y lo que quieres ver.
• «Duplicada: Google ha elegido una versión canónica diferente a la del usuario»: Google no ha hecho caso a tu canonical, así que revisa que el mapa del sitio, tus enlaces internos y la propia etiqueta apunten todos a la misma URL.

Tres preguntas antes de tocar nada

Cuando dudes con una página, hazte estas preguntas en este orden.

1. ¿Quiero que Google pueda entrar a verla? Si no, Disallow, pero solo si no necesitas que lea un noindex.
2. ¿Quiero que la enseñe en los resultados? Si no, noindex, y con la puerta abierta para que pueda leerlo.
3. ¿Quiero recomendársela? Si sí, al mapa del sitio y con la URL que prefieres.

Si tienes alguna página que no sabes en cuál de estos casos encaja, me tienes ahí abajo, en los comentarios, y la miramos.

Si lo que te preocupa es la web al completo pásala por la auditoría SEO gratuita, que revisa entre otras cosas el robots.txt, los mapas del sitio y la indexación, y si después te siguen quedando dudas puedes pedirme un análisis más completo al final del informe, también gratis.

Por si quieres seguir con el tema, tengo más escrito sobre los archivos por fecha y los archivos de autor, sobre cómo configurar el mapa del sitio nativo, sobre el robots.txt en multisitio y sobre si te conviene bloquear a los bots de IA.

Para todo lo demás, me preguntas ahí abajo en los comentarios.

El histórico de instalaciones, la posición de tu plugin en el buscador o lo que hace la competencia lo tienes que guardar tú, o pagar a alguien que lo guarde por ti.

Y te reconozco que el asunto me toca de cerca, porque tengo más de 20 plugins publicados, todos gratis, y como cualquier autor me gustaría saber cómo les va. Por todo esto llevo meses siguiendo un ticket de Trac abierto hace cuatro años, que ya pasa de 180 comentarios y en el que no se ha movido nada.

Vamos a ver qué te da el directorio si publicas plugins o temas en WordPress.org, por qué no te da más y qué alternativas tienes hoy, gratis y de pago.

Lo que te da WordPress.org hoy (que no es mucho)

Vamos a hacer un poco de leña del árbol caído, y es que esto da bastante penita, pero es lo que hay de momento.

La vista «avanzada»

La ficha pública de cualquier plugin te enseña las instalaciones activas, la valoración con su desglose por estrellas, los hilos de soporte resueltos en los dos últimos meses y hasta qué versión de WordPress se ha probado. Lo que te da es únicamente la foto del momento, sin evolución.

Si entras en la pestaña de la «Vista avanzada» de un plugin tienes algo más, tres gráficos que se llaman «Versiones activas» (qué versiones de tu plugin se usan), «Descargas por día» y el «Historial de descargas».

Los temas no tienen una pestaña equivalente ni de lejos, así que ahí vas todavía más a ciegas, y también por eso verás que este artículo se centra sobre todo en plugins, los desarrolladores de temas, por mucho que nos quejemos los de plugins, van aún peor.

No es algo exclusivo del autor del plugin, puedes verlo tú, cualquier usuario, pero vamos, que tampoco es un locurón de información.

Lo que te da la API pública de WordPress.org

Detrás de WordPress.org hay una API pública que no pide cuenta ni clave, y es lo que leen todas las herramientas que vamos a ver luego. La he probado muchas veces, pero para tener una visión más actualizada, la he revisado recientemente por si había cambiado algo (a septiembre de 2026) y esto es lo que da:

• Descargas diarias: api.wordpress.org/stats/plugin/1.0/downloads.php?slug=tu-plugin&limit=730 te devuelve 729 días de descargas. Ojo con esto, porque si pides más de 730 no da error, te devuelve solo los últimos 179 días y se queda tan ancha. Para temas el equivalente es stats/themes/1.0/downloads.php.
• Instalaciones activas: solo la cifra de hoy y redondeada, en el campo active_installs de la API de información de plugins y temas.
• Histórico de instalaciones: no existe. El endpoint que alimentaba el antiguo gráfico de crecimiento, active-installs.php, contesta con un 404.
• Versiones en uso: stats/plugin/1.0/tu-plugin te da el porcentaje de sitios que usan cada versión de tu plugin. Para temas no hay nada parecido.
• Búsquedas: la API de búsquedas devuelve los resultados en el mismo orden que el buscador de la web, así que se puede medir en qué puesto sale tu plugin para una búsqueda concreta. Eso sí, la medición la tienes que hacer tú cada día, porque nadie la guarda.

Resumiendo, todo lo que no sea la foto de hoy o las descargas de los dos últimos años, WordPress.org no lo guarda para ti. Y lo que no guardes por tu cuenta no lo vas a tener de ningún modo, al menos no tirando de la API oficial.

Lo que no está en ningún sitio y me/nos gustaría saber

Para que te hagas una idea de lo que falta, estas son las preguntas que cualquier desarrollador se hace y que el directorio no responde:

• ¿Mis instalaciones suben o bajan, y desde cuándo?
• ¿Cuántas instalaciones tengo de verdad dentro de ese «10.000+»?
• ¿En qué puesto salgo cuando alguien busca «formulario de contacto» (o lo que sea que haga tu plugin)?
• ¿Quién me ha adelantado esta semana?
• ¿Cuánta gente desinstala mi plugin y en qué versión de PHP o de WordPress está?

La última ni siquiera la pueden responder las herramientas externas que leen la API, solo las que meten código de telemetría en tu plugin.

¿Qué significa de verdad «10.000+ instalaciones activas»?

Es la típica cifra de instalaciones que ves en WordPress.org, y la respuesta corta es que tu plugin está activo en algún número de sitios entre 10.000 y 19.999, ahí es nada.

No hay más detalle público ni privado (que sepamos), y la cifra ni siquiera es exacta de origen.

Cómo se cuentan las instalaciones activas

Cada instalación de WordPress comprueba si hay actualizaciones dos veces al día (es un evento programado de WordPress, wp_update_plugins, que se ejecuta cada doce horas), y en esa comprobación manda a api.wordpress.org la lista de plugins que tiene instalados y cuáles están activos, con los temas pasa lo mismo.

De ahí sale la cifra de instalaciones activas, que cuenta los sitios con tu plugin activado, no los que lo tienen instalado y apagado.

Lo que no está documentado en ningún sitio público es cómo agrega WordPress.org esas comprobaciones (qué ventana de tiempo usa, cómo descarta duplicados…).

Lo más parecido a una explicación oficial es lo que escribió Dion Hulse (dd32), del equipo de WordPress.org, en el ticket del que te hablo más abajo, en marzo de 2023: «WordPress.org no comparte la cifra exacta, salvo los tramos redondeados que se muestran públicamente», porque las instalaciones activas son un dato «estadísticamente quizá no correcto al 100 %, y por eso las redondeamos como lo hacemos».

Luego, en 2021, a raíz de unas estadísticas infladas a propósito, Samuel Wood (Otto) explicaba en el blog del equipo de plugins que no guardan esos datos en bruto más de dos días.

O sea, que hasta la cifra que ves es una estimación, y además redondeada. Súmale que un sitio que bloquea las peticiones externas o que no puede comunicarse por lo que sea con WordPress.org no cuenta, así de simple.

Cómo se redondean las instalaciones activas

Aquí hay mucha confusión, así que he ido directamente al código del directorio (la función sanitize_active_installs() del plugin que mueve WordPress.org).

Y lo que he visto es que la cifra se redondea siempre hacia abajo, quedándose solo con la primera cifra significativa:

Es como una báscula que solo mira la primera cifra, pesas 79 kilos y marca 70, engordas ocho y sigue marcando 70.

Seguro que has leído, porque circula mucho, que «10.000+» puede significar cualquier cosa hasta 49.999. Lo dice por ejemplo Matt Cromwell en su artículo sobre qué significan las instalaciones activas (actualizado en agosto de 2025), y tiene toda la razón en lo de fondo, que es un tramo y no una cifra.

Ahora bien, con el código actual el tramo de «10.000+» acaba en 19.999, no en 49.999, y en la API ves tramos intermedios como 2.000, 4.000 o 9.000 que con la otra lectura no existirían.

Lo que sí es cierto es que el error puede ser enorme, pues un plugin que marca «10.000+» puede tener casi el doble de usuarios, y entre «1+ million» y «2+ million» caben un millón de sitios.

El resultado de toda esta inconsistencia y falta de datos reales es que si tu plugin está en la parte alta de un tramo puedes crecer durante meses sin que la ficha se mueva ni un número.

Cuatro años de ticket: por qué quitaron el gráfico y qué ha pasado desde entonces

Hagamos recopilación de la (triste) historia de esta queja constante de los desarrolladores de plugins y temas.

2022: el gráfico desaparece

Hasta septiembre de 2022 la pestaña de la vista avanzada tenía un gráfico de crecimiento de instalaciones activas. No daba cifras exactas, pero te decía si ibas para arriba o para abajo, que para un desarrollador es importante.

El 29 de septiembre de 2022 Scott Reilly lo retiró con el changeset 12097, con un mensaje que dice que se quitaba «por una ofuscación insuficiente de los datos», o sea, que con ese gráfico se podía deducir lo que el redondeo pretendía esconder.

Al día siguiente Mark Zahra abrió el ticket #6511, que empezó pidiendo que volviera el gráfico y que semanas después cambió su título a «Provide helpful plugin stats and insights» (dadnos estadísticas útiles, vaya).

Matt Mullenweg explicó en el ticket que había «servicios comerciales y gratuitos de terceros extrayendo estos datos de forma masiva» y que sí veía posible enseñar más estadísticas a cada autor sobre sus propios plugins, algo que «llevará trabajo, pero se puede hacer».

En WP Tavern (Sarah Gooding, 4 de octubre de 2022) Joost de Valk lo resumía así: «Los datos reales existen. Automattic es una de las empresas que compran plugins y tiene acceso a los datos exactos, y ahora más que antes, los demás no».

2023: los devs contraatacan

En septiembre de 2023 WP Tavern volvió sobre el tema (Sarah Gooding, 12 de septiembre de 2023). Samuel Wood explicaba en un podcast que el gráfico estaba dando «básicamente basura» y que «dar cifras de instalaciones activas que están mal es más dañino que no darlas», y que había un plan para sustituirlo, pero no para sustituirlo de inmediato.

En el mismo artículo Jason Coleman (Paid Memberships Pro) presentaba un borrador de propuesta con cuatro peticiones (cifras de instalaciones más precisas, lo mismo para las versiones, descargas separadas por tipo y la posibilidad de registrar eventos propios), aunque solo las pudiera ver cada autor de sus plugins.

No he encontrado ninguna respuesta oficial a esa propuesta ni ninguna entrada en make.wordpress.org/meta ni en make.wordpress.org/plugins sobre recuperar las estadísticas entre 2023 y hoy.

2024: el ticket se cierra y se reabre en un día

El 3 de octubre de 2024 Sybre Waaijer (Cybr, autor de The SEO Framework) cerró el ticket como «wontfix» (no se arreglará) en señal de protesta, porque mantenerlo abierto «solo crea falsas esperanzas».

Al día siguiente Alex Shiels (tellyworth) lo reabrió y explicó que Matt le había pedido trabajar en indicadores de compatibilidad, y que «el principal obstáculo es la carga de la base de datos», porque las bases de datos de estadísticas nunca se diseñaron para esas consultas.

Tres días después publicó una prueba de concepto con el porcentaje de sitios en la última versión y la distribución de versiones de WordPress y PHP. Esos indicadores no han llegado al directorio.

2026: Matt Mullenweg contesta … o algo así

En mayo de 2026 Jean Galea propuso que el crecimiento lo vieran solo los que tienen acceso de escritura al plugin (sus committers), de modo que nadie pudiera rascar los datos de los demás, y la idea tuvo bastantes apoyos en el hilo, como es lógico: problema ilógico, solución sencilla y rápida.

El 17 de julio Matt volvió a escribir en el ticket después de casi cuatro años, y lo hizo para decir que «aquí hay varios intereses en juego» y que hay que tener en cuenta «los incentivos a largo plazo de los plugins comerciales frente a los comunitarios».

Una semana después añadía que él puede ver esos datos, igual que algunas personas de sistemas y de WordPress.org, y que este año la seguridad se va a llevar la mayor parte del tiempo.

La lectura que hizo de esto Jean Galea fue que el motivo había pasado de ser técnico (la ofuscación de 2022) a ser «una decisión política».

Mientras tanto se han abierto tickets relacionados, como el #7648 (mayo de 2024, que pide que las instalaciones pesen menos en el buscador), el #8298 (junio de 2026, que propone ponerles tope) y el #8369 (julio de 2026, una sección voluntaria de estadísticas en los perfiles), y ninguno se ha resuelto.

Yo también dejé mi comentario en el #6511 en septiembre de 2026. Como la cosa no se mueve, conté que he metido en un plugin gratuito todo lo que se puede sacar de las API oficiales, que es la alternativa que te enseño más abajo, porque no se tú, pero a mi me jode pagar por cosas que deberían ser gratis, sobre todo si ya están ahí, pero esa es otra historia. Sigo…

La parte de razón que tiene el criterio actual WordPress.org

Vamos a empezar por lo que tiene sentido, porque lo tiene. El dato de instalaciones no es exacto, y enseñar decimales falsos a la gente es peor que no enseñarlos.

Tampoco es una paranoia lo del abuso, porque el buscador del directorio lleva años premiando las instalaciones por encima de casi todo y hay quien lo aprovecha, como explica Jean Galea en cómo se amaña el buscador de plugins (julio de 2026).

Y además, rehacer las bases de datos de estadísticas cuesta tiempo y dinero a una organización que tira de voluntarios y de empresas que ceden personal.

Dicho esto, el redondeo ya esconde la cifra exacta, así que un gráfico de tendencia basado en esos mismos tramos no destapa nada que no se sepa ya.

Los datos públicos tienen que ser públicos (o eso pienso yo al menos)

Aquí te tengo que reconocer una cosa, y es que la propia API, y mi propio plugin que se basa en ella, le quita un poco la razón a la propuesta de Galea.

Con el plugin Contributor Résumé and Insights cualquiera puede escribir el usuario de otro autor y ver todo lo que da la API de sus plugins y temas, así que eso de que solo lo vean los committers protege más bien poco.

Mi opinión es que los datos públicos tienen que ser públicos, sin que nadie tenga que montarse herramientas por su cuenta ni depender de las de otros, y eso incluye a Contributor Résumé and Insights.

Todas las alternativas que vas a ver más abajo, la mía también, han nacido de una necesidad, y eso ya dice bastante de cómo está el asunto.

Tampoco me convence lo de los intereses en juego. Las herramientas nunca son el problema, lo es el uso que se haga de ellas. Es casi como decir que, como habrá gente que use WordPress para difundir bulos, no deberíamos dejar que se use abiertamente (y no creo que nadie en la comunidad firmase algo así).

Y luego está lo que reconoce el propio Matt, que él puede ver esos datos. ¿Y los demás, qué? Que unos vean los datos y los autores de los plugins no, ni es justo ni es juego limpio.

Las alternativas a las (no) estadísticas de WordPress.org para plugins y temas

Casi todas las herramientas que hay hacen lo mismo por debajo, leen cada día (o cada semana) la API pública de WordPress.org y guardan una foto, y con esas fotos te pintan el histórico que el directorio no tiene. Las diferencias están en qué guardan, desde cuándo, dónde se quedan los datos y si se atreven a estimar la cifra dentro del tramo.

StatWP, WP-Rankings, WP Analyze, WP Stats, Repoevo o PluginTracker (el .dev) te dan un número más fino que «10.000+», calculado a partir de los cambios de tramo y de las descargas, y hay que reconocerles que lo avisan (el creador de WP-Rankings lo decía al presentarlo en el ticket, «nada de esto es exacto, son estimaciones»). Para ver tendencias van de maravilla, como cifra exacta no están pensadas para ello.

La única forma de tener el número real es la otra familia, la de los SDK de telemetría (como Freemius o Appsero), que meten código en tu plugin y cuentan los sitios que dan su consentimiento. Esos no entran en las tablas, luego te cuento por qué.

Comparativa de servicios de estadísticas de plugins y temas

He juntado 21 herramientas (el propio directorio incluido) en una hoja de cálculo con 46 funcionalidades y todos sus planes, y aquí te dejo cuatro vistazos parciales de esa hoja para que no tengas que tragarte una tabla de más de 40 columnas.

Los datos se comprobaron entre el 27 y el 29 de septiembre de 2026 en la web de cada servicio, en su ficha de WordPress.org los que la tienen y, cuando no con una cuenta gratuita o de prueba en los servicios externos.

Cada fila muestra el plan gratis de la herramienta (o el más barato, si no tiene gratis), con lo que añaden los planes de pago entre paréntesis.

Herramientas, precios y detalles

Instalaciones y descargas

WhoKnew Directory SEO, la extensión WP Ranking y los plugins para mostrar cifras no guardan histórico de instalaciones ni de descargas, no es lo suyo.

Posición en las búsquedas y competidores

Avisos, informes y muestreo de datos

Cuando ves todas las tablas juntas se ve claro que nadie tiene todo, y que lo que más cambia de una a otra no son las gráficas sino dónde acaban tus datos y lo que pasa si el servicio cierra.

Lo que cuestan los planes de pago

Precios del 27 y el 28 de septiembre de 2026, en la moneda de cada servicio y sin impuestos. Cambian a menudo, así que compruébalos antes de pagar nada.

Detalles que conviene saber antes de elegir

• Hay dos PluginTracker: plugintracker.io y plugintracker.dev son servicios distintos, con precios y funciones distintos. El .dev, además, ofrece un SDK de telemetría opcional aparte del rastreador, y aunque sigue teniendo publicada una página de planes de por vida, su FAQ dice que ahora no los vende. Lo he probado con su prueba gratuita y, sin el SDK, el rastreador se queda bastante corto (el gráfico de descargas no marca las versiones, las keywords enseñan su evolución pero no quién está por encima, y no aparece la alerta «version behind» que anuncia su web). Lo que te propone para casi todo es añadir la telemetría, de pago.
• WP-Rankings: hoy es gratis y solo cubre plugins, no temas. Puedes reclamar todos tus plugins (sin límite, verificando que son tuyos), y para ver tus keywords tienes que hacerlo. Dicen tener más de cuatro años de fotos diarias, y el plan Premium está anunciado, pendiente de una votación de usuarios, sin fecha ni precio. Según The Repository tuvo 72.000 visitantes únicos en las primeras 24 horas tras su relanzamiento en julio de 2026.
• WP Analyze: gratis, y la búsqueda y las fichas no piden cuenta. Las alertas por correo que tiene son de vulnerabilidades, no de estadísticas.
• WPMonitor: gratis y sin registro. Ya te lo presenté en su día en wpmonitor.dev, estadísticas de plugins y temas WordPress (casi) como deberían ser.
• WP.MD: es de Pavel Ciorici (el fundador de WPZOOM), gratis y sin registro. Sigue el puesto de cada plugin y tema en la lista «Popular» del directorio, y en temas tiene histórico desde septiembre de 2024, que para quien publica temas es bastante más de lo que hay en otros sitios.
• PluginScout: gratis y sin registro, de FS Code (los de Booknetic y FS Poster). Organiza el directorio en 80 clasificaciones por categoría con alternativas y comparativas ya hechas. Arrancó el 4 de septiembre de 2026, así que su histórico empieza ese día.
• PluginPulse: lee el directorio cada semana y enseña el histórico de cualquier plugin sin cuenta. Con cuenta gratis sigues un plugin (la portada habla de tres) y recibes un resumen semanal por correo, y el plan de pago está anunciado, pero todavía no se puede contratar.
• wpMetrics: tiene plan gratis para un plugin o tema y planes de pago desde 3,99 USD al mes, aunque los precios no están en su web, salen de su propia aplicación. La última novedad que ha publicado es de octubre de 2022, pero sigue funcionando con datos al día, y el histórico de instalaciones es de pago.
• WP Stats: sigue plugins y temas (lo confirma su FAQ), tiene prueba de 14 días sin tarjeta y, además de las cuotas, un pago único de por vida desde 149 USD. Te sugiere competidores solo, sin que los añadas, y te da una cifra concreta de instalaciones (331 donde WordPress.org dice 300+) incluso sin plan de pago. Eso sí, su gráfica de «next milestone» queda muy bien pero no aporta más, solo marca la siguiente cifra redonda.
• Repoevo: es un plugin que instalas en tu WordPress, pero los datos se guardan en el servidor del proveedor (en Alemania) y necesitas registrarte. Al darte de alta te regala unos días de uso del plan Pro, sin tarjeta.
• WhoKnew Directory SEO: el plugin es solo la interfaz, el trabajo lo hace el servicio de whoknew.io. Mide tu posición por keyword cuando tú lanzas el escaneo (no a diario), cada escaneo gasta un crédito, y además revisa si la keyword aparece en los campos de tu ficha que cuentan para el buscador. Los datos se quedan en tu WordPress.
• PluginRadar: es una aplicación (Node.js y React) de WPBean que instalas en tu propio servidor. Los 99 USD son más impuestos.
• WP Ranking: extensión de Chrome gratuita para mirar en qué puesto sales para varias keywords en un momento dado, sin guardar histórico. Su última versión es de junio de 2024, pero la lógica que usa sigue funcionando con el buscador actual.
• WP Plugin Info Card: sirve para mostrar tarjetas de plugins y temas en tu web, no para analizar. Su empresa, DLX Plugins, anunció que cierra el 1 de octubre de 2026 y el plugin busca nuevo responsable.
• WP Themes & Plugins Stats: shortcodes para mostrar en tu web las cifras de un plugin o tema concreto. Si vas a usar los totales por autor, pruébalo antes con tu versión de PHP.

Fuera de la comparativa se han quedado las que no funcionan. AutomagicWP tenía el certificado caducado y todo daba 404, Easy Plugin Stats está cerrado en el directorio desde agosto de 2025 a petición de su autor, y pluginrank.com y wpstats.me ya no responden.

Lo de pluginrank.com, que fue uno de los servicios de referencia hace años, sirve de aviso. En el propio ticket uno de los creadores de WP-Rankings recordaba que proyectos parecidos cerraron porque casi nadie pagaba por ellos, y cuando un servicio cierra, tu histórico se va con él.

Las tablas anteriores son un resumen, si quieres el detalle completo de todas estas herramientas, con las 46 funciones, todos los planes, las notas de cada celda y las fuentes, te puedes descargar la hoja completa en Excel o en PDF.

Los SDK de telemetría, datos reales a cambio de código

Si te preguntas por servicios como Freemius y Appsero y por qué no están en la comparativa es debido a que juegan en otra liga, y por eso no están en las tablas. Son plataformas para vender y gestionar licencias de plugins y temas que, de paso, te dan analítica.

En lugar de leer la API de WordPress.org meten un SDK (un paquete de código) dentro de tu plugin o tema, que informa desde cada sitio que da su permiso. Así tienes instalaciones y desinstalaciones reales, versiones de PHP y de WordPress y, si vendes, licencias y ventas.

El precio no es solo dinero (Freemius Insights y Appsero Free Forever son gratis), es código de terceros dentro de tu plugin y, sobre todo, consentimiento, porque la directriz 7 del directorio es clara, «los plugins no pueden rastrear a los usuarios sin su consentimiento».

En la práctica eso significa el típico aviso de «¿nos dejas recoger datos anónimos?», así que la cifra que ves es la de quienes dijeron que sí.

Si tu plugin es gratis y no quieres meterle nada, estás limitado a lo que da la API pública, y a partir de ahí todo es guardar fotos fijas o hacer estimaciones.

Contributor Résumé and Insights

Contributor Résumé and Insights es un plugin que tengo publicado, gratis, sin planes de pago, sin cuenta y sin claves de API, y los datos se guardan en la base de datos de tu propio WordPress, no en un servidor ajeno, como todos los míos.

¿Que por qué lo hice? pues por dos motivos.

Primero por lo que conté en el ticket del Trac, que como aquello no avanza decidí meter en un plugin gratuito todo lo que se puede sacar de las API oficiales de WordPress.org.

Y luego que quería tener una opción gratis para mí y para cualquier otro desarrollador que publique en el directorio, sin cuotas ni servicios de por medio.

Nació inicialmente para montar una página con tu currículum de contribuidor de WordPress.org, y desde la versión 1.4.0 le incorporé una pestaña de estadísticas que, si publicas plugins o temas, se convierte en tu propio panel de analítica. Esto es lo que te da (de momento):

• Descargas diarias: dos años hacia atrás desde el primer día, y el histórico sigue creciendo.
• Instalaciones activas y versiones en uso: una lectura al día desde que activas las estadísticas (lo de las versiones, solo en plugins, porque WordPress.org no lo da para temas).
• Posición en el buscador: hasta 10 búsquedas por plugin o tema, cada día, con el top 10 de cada búsqueda para que veas quién tienes por encima.
• Etiquetas: en qué puesto y en qué página sale cada plugin en sus etiquetas del directorio.
• Reputación y soporte: valoración con desglose por estrellas, las 10 últimas reseñas y los hilos de soporte abiertos y resueltos.
• Traducciones: paquetes de idioma y traducciones a medias.
• Avisos en el panel: hilos sin responder, nuevas versiones, cambios fuertes de descargas, reseñas nuevas y plugins sin probar con la última versión de WordPress.
• Salida de datos: exportación en CSV de cada vista, un widget de escritorio que cada usuario configura a su gusto y comandos de WP-CLI.
• Vistazo a otros autores: hasta tres al día, para que no te vicies.
• Alertas y resúmenes por correo electrónico: a diario, semanal o mensual, solo alertas o todo incluido, con detalle sobre subidas y bajadas.

Los límites actuales son 50 plugins o temas y 10 búsquedas por cada uno, pero se pueden cambiar usando un filtro.

Y ahora lo que no hace (aún):

• El histórico de instalaciones y de posiciones empieza el día que lo activas, porque WordPress.org no guarda el pasado y yo no me lo puedo inventar.
• Si necesitas ver cómo te ha ido en los últimos años, WP-Rankings, con sus fotos desde 2022, te lo cuenta mejor, y en temas lo tienes en WP.MD.
• Tampoco estima la cifra dentro del tramo (de momento), no compara con competidores (todavía), no manda alertas por correo (aún).
• No rastrea vulnerabilidades y no tiene telemetría, solo lee datos públicos.

En la lista de tareas tengo varias cosas previstas y otras en estudio, sin fechas y sujetas a cambios.

• Añadir un bloque y shortcode propios para enseñar tus estadísticas en público (solo si quieres, y con el nivel de detalle que decidas como administrador de la web).
• La comparación con los competidores que elija cada usuario, las sugerencias de competidores a partir del top 10 de tus búsquedas y el aviso cuando alguien te adelanta.
• En estudio me ando pensando cómo afinar la estimación de instalaciones, marcar los lanzamientos de versiones en las gráficas y un análisis de reseñas con la IA del propio sitio.

¿Qué herramienta es mejor para ver estadísticas de mis desarrollos?

Depende de lo que quieras saber y de dónde quieras que vivan tus datos:

• Solo quieres echar un vistazo de vez en cuando: WPMonitor, WP Analyze, WP-Rankings, WP.MD, PluginScout o PluginPulse, todas gratis y sin cuenta para consultar. No instalas nada.
• Quieres ver tu pasado, de antes de hoy: WP-Rankings para plugins, por esos años de fotos diarias, y WP.MD para temas. Ninguna herramienta que empieces a usar hoy te devolverá lo que no guardó nadie.
• Quieres los datos sin salir casa, sin cuentas ni servicios de terceros: Contributor Résumé and Insights si no quieres pagar, o PluginRadar si prefieres una aplicación aparte en tu servidor con competidores y alertas ya desde ahora mismo.
• Quieres keywords, competidores y alertas por correo desde ya, y no te importa pagar: PluginTracker (.io o .dev), WP Stats o StatWP, según cuántos plugins tengas y cuánto histórico necesites.
• Solo quieres comprobar tu posición de vez en cuando, o trabajar el readme: la extensión WP Ranking para una consulta rápida, o WhoKnew Directory SEO, que con sus créditos gratis te da para unos cuantos escaneos al mes y te revisa la ficha.
• Quieres la cifra real y más datos de uso: un SDK como Freemius o Appsero, con el consentimiento de por medio y asumiendo lo que eso supone.
• Solo quieres enseñar tus cifras en tu web: Plugin Stats View y Theme Stats View, WP Themes & Plugins Stats o WP Plugin Info Card (teniendo en cuenta lo del cierre de su empresa).

Y sobre todo ningunos son excluyentes. Nada te impide usar una herramienta gratis para el día a día y otra para mirar el histórico de hace años.

¿Tengo que hacer algo ya mismo?

Pues sí, al menos una cosa, porque todo lo que no guardes hoy lo pierdes, así que:

1. Empieza a guardar datos hoy: Da igual la herramienta, pero las instalaciones y las posiciones que no se registren esta semana no las vas a recuperar nunca, y las descargas solo llegan dos años atrás.
2. Piensa dónde quieres que estén tus datos: En tu base de datos, en tu servidor o en un servicio ajeno, cada opción tiene sus pros y sus contras.
3. Exporta de vez en cuando: Un CSV guardado en tu disco sobrevive al cierre de cualquier servicio, incluido el mío.
4. Trata las estimaciones como lo que son: Sirven para ver tendencias, no para anunciar que tienes 19.400 usuarios.
5. Si vas a comentar en el ticket del Trac, aporta algo: Ya hay decenas de «+1» pero una propuesta concreta pesa más.

Hasta aquí mucha información y un poco de mi opinión, ahora te toca a ti decidir qué te conviene. Si usas alguna herramienta que no esté en la lista, o no estás de acuerdo con cómo la he descrito, me tienes ahí abajo, en la sección de comentarios.

Y si estás empezando con tu primer plugin en el directorio, igual te interesa también cómo conseguir más usuarios para tu plugin en WordPress.org, con algunos consejos, y también errores que he cometido para que no los cometas tú.

En fin, nada más, salvo lo que quieras aportar abajo en los comentarios, ojalá este artículo se quede viejo pronto porque WordPress.org nos devuelva las estadísticas. Mientras tanto ya sabes, a guardar fotos fijas o herramientas que otros han ido aportando (yo incluido) para cubrir ese hueco.

Fuentes

Todas consultadas en septiembre de 2026 salvo que se indique otra cosa.

WordPress.org y Trac

• Ticket #6511, «Provide helpful plugin stats and insights», abierto el 30 de septiembre de 2022 por markzahra; 184 comentarios a 27 de septiembre de 2026. Comentarios citados:
  • 3 y 5 de octubre de 2022 (matt);
  • 31 de marzo de 2023 (dd32, comentario 129);
  • 3 y 4 de octubre de 2024 (Cybr, comentario 146; tellyworth, comentarios 147 y 148; prueba de concepto el 7 de octubre);
  • 12 de mayo de 2026 (jeangalea);
  • 17 y 23 de julio de 2026 (matt, comentarios 176 y 181);
  • 27 de septiembre de 2026 (fernandot, comentario 184).
• Changeset 12097, 29 de septiembre de 2022, coffee2code (Scott Reilly).
• Tickets relacionados:
  • #7648, 21 de mayo de 2024;
  • #8298, 11 de junio de 2026;
  • #8369, 18 de julio de 2026.
• Código del directorio: class-template.php del plugin plugin-directory, funciones sanitize_active_installs() y format_active_installs_for_display().
• Código de WordPress: wp-includes/update.php (comprobación de actualizaciones cada doce horas, envío de plugins instalados y activos).
• API pública de estadísticas (comprobada el 25 y el 27 de septiembre de 2026):
  • api.wordpress.org/stats/plugin/1.0/downloads.php;
  • api.wordpress.org/stats/themes/1.0/downloads.php;
  • api.wordpress.org/stats/plugin/1.0/{slug};
  • api.wordpress.org/stats/plugin/1.0/active-installs.php (404).
• Inaccurate stats have been corrected, Make Plugins, 27 de agosto de 2021.
• Detailed Plugin Guidelines, directriz 7.

Prensa y opiniones

• WordPress.org Removes Active Install Growth Data for Plugins, Sarah Gooding, WP Tavern, 4 de octubre de 2022.
• WordPress.org Plugin Developers Renew Demands for Better Plugin Metrics, Sarah Gooding, WP Tavern, 12 de septiembre de 2023.
• Matt Mullenweg responds to active install growth data ticket for first time in four years, Rae Morey, The Repository, 22 de julio de 2026.
• How WordPress.org Plugin Search Gets Gamed, Jean Galea, 16 de julio de 2026.
• What does «active installs» mean in the WordPress plugin directory?, Matt Cromwell, actualizado el 22 de agosto de 2025.
• wpmonitor.dev: estadísticas de plugins y temas WordPress (casi) como deberían ser, Ayuda WordPress, 16 de diciembre de 2025.

Herramientas (servicios, herramientas y plugins varios)

• statwp.com
• wp-rankings.com
• wpanalyze.com
• wpmonitor.dev
• wpmetrics.dev
• plugintracker.io
• plugintracker.dev/pricing y plugintracker.dev/lifetime
• wpstats.dev
• repoevo.com/pricing
• PluginRadar
• wp.md/wordpress-plugin-stats y wp.md/about
• pluginscout.io y pluginscout.io/how-rankings-work
• thepluginpulse.com/pricing
• whoknew.io/whoknew-directory-seo y sus términos
• Extensión WP Ranking en la Chrome Web Store
• wphive.com
• Anuncio de cierre de DLX Plugins (publicado el 5 de julio de 2026)
• Plugins en WordPress.org:
  • contributor-resume
  • repoevo
  • wp-plugin-info-card (busca quien lo adopte)
  • plugin-stats-view
  • theme-stats-view
  • whoknew-directory-seo
  • wp-themes-plugins-stats
  • easy-plugin-stats (cerrado, fuera de la comparativa)

Es de las preguntas que más me llegan últimamente, así que te adelanto mi respuesta breve, y es que en la mayoría de los casos no es urgente, y lo único que puedes tocar con tranquilidad es aquello que sabes de quién es.

Ya he escrito antes sobre el autoload, tanto sobre índices en la tabla de opciones como sobre cómo detectar qué opciones necesitan cargarse automática, pero hoy va de otra cosa. Nada de índices, sino de saber qué significa realmente el aviso, qué puedes quitar y qué no, y de hacerlo de manera que puedas deshacerlo si algo se tuerce.

Empezamos…

¿Tiene importancia el aviso de salud del sitio de opciones cargadas automáticamente?

Primero conviene saber qué mide exactamente ¿no?. Te cuento…

WordPress suma lo que ocupan todas las opciones de la tabla wp_options que se cargan en cada petición (las que tienen el autoload activo) y, si pasan de 800.000 bytes, te lanza el aviso como error crítico.

El umbral se puede cambiar con el filtro site_status_autoloaded_options_size_limit. Un detalle que despista a veces, por cierto, es que la herramienta de salud del sitio te muestra el tamaño en KB de 1.024 bytes, así que el aviso salta cuando ves unos 781 KB, no 800. Si tienes 790 KB y te sale el aviso, no es un fallo, es la conversión que hace.

Ahora bien, lo importante es que eso es una medida de tamaño, no una prueba de velocidad. WordPress no ha medido que tu web vaya lenta, solo que carga muchos datos de opciones en cada visita, y eso puede notarse o no según el caso.

Cuándo NO te debería preocupar

Si estás rozando el umbral, por ejemplo entre 800 KB y 1 MB, con un alojamiento decente y la web respondiendo bien, no pasa nada grave, sigue a lo tuyo. Unos cuantos KB de más no cambian nada que notes, y meterte a toquetear la base de datos para que desaparezca un aviso de rendimiento tiene más riesgo que beneficio.

Cuándo SÍ merece tu atención

Hay situaciones en las que el aviso sí podría apuntar a un problema real:

• Varios MB de opciones cargadas automáticamente: ahí ya hay algo que no cuadra, normalmente un plugin guardando registros, estadísticas o cachés en la tabla de opciones.
• Alojamiento compartido sin caché de objetos: cada visita que no sirve la caché de página lee y procesa todo ese bloque desde la base de datos.
• Un tamaño que crece semana a semana: si limpias y a los pocos días vuelves a estar igual, hay algo escribiendo sin control y el problema está en ese algo, no en el autoload.
• Caché de objetos con Memcached y un autoload muy grande: te lo explico ahora, que esto si tiene su aquél.

WordPress guarda todas las opciones cargadas automáticamente en la caché de objetos como un único elemento, y Memcached, por defecto, no admite elementos de más de 1 MB. Si ese bloque no cabe, no se guarda en caché, y cada página paga la consulta completa más una llamada inútil a Memcached.

Eso sí, no te asustes antes de tiempo, porque la extensión memcached de PHP comprime por defecto los valores de más de 2.000 bytes, y el límite cuenta sobre el tamaño ya comprimido, así que con 1,2 MB en salud del sitio lo normal es que siga cabiendo sin problema. Con Redis en esto no hay problema porque admite valores de hasta 512 MB.

¿Y si subo el umbral con el filtro?

Puedes hacerlo, pero solo sirve para que desaparezca el aviso, WordPress sigue cargando exactamente lo mismo. Yo solo lo haría, si acaso, después de revisar la tabla y decidir que lo que hay es lo que tiene que haber, y ni siquiera así es recomendable, porque la base de datos no es algo fijo, y si empeora el problema no te enterarías.

Quitar el autoload no es borrar

Un par de cosas que tienes que tener claro antes de tocar nada:

• Cuando una opción tiene el autoload activo, WordPress la carga junto con todas las demás al principio de cada petición, en una sola consulta.
• Cuando lo desactivas, la opción sigue en su sitio con su valor intacto, y si algún plugin la pide, WordPress hace una consulta para ir a buscarla. Te cuesta, como mucho, una consulta más en las páginas donde se use.

El riesgo de verdad no está en desactivar el autoload sino en borrar opciones. Si borras la opción de un plugin activo lo normal es que la vuelva a crear con los valores por defecto y pierdas sus ajustes, y si es de algo que no sabías que se usaba te enteras cuando ya ha dejado de funcionar.

Lo importante es medir bien las opciones cargadas automáticamente

Casi todos los tutoriales (los míos incluidos, que conste) usan consultas con WHERE autoload='yes', y desde WordPress 6.6 eso ya no es así (del todo). Las opciones de WordPress ya no se guardan con yes y no, sino con cinco valores nuevos:

• on: el plugin pidió expresamente que se cargue automáticamente.
• off: el plugin pidió expresamente que no se cargue automáticamente.
• auto: el plugin no dijo nada y WordPress decide, que hoy por hoy es cargarla automáticamente.
• auto-on: WordPress decidió cargarla automáticamente.
• auto-off: WordPress decidió no cargarla automáticamente (pasa con las opciones nuevas de más de 150.000 bytes).

Las filas antiguas conservan su yes o no, y WordPress las trata como on y off. Por resumir, se cargan automáticamente las que tienen yes, on, auto-on y auto, así que si solo buscas yes te dejas fuera todo lo que se haya guardado en los dos últimos años.

Una cosita más, lo de no cargar automáticamente opciones grandes solo se aplica al guardar opciones nuevas o actualizadas, no limpia lo que ya tenías en la base de datos. Y ya que estamos, no necesitas crear ningún índice sobre la columna autoload, porque WordPress trae uno de serie desde la versión 5.3, no es de ayer.

Antes de nada, siempre haz diagnóstico de lo que tienes

Estas tres consultas que te pongo a continuación son de solo lectura, así que puedes ejecutarlas en phpMyAdmin sin ningún riesgo. Cambia wp_ por el prefijo de tus tablas si usas otro.

Tamaño total y número de opciones cargadas automáticamente (lo mismo que mide salud del sitio):

SELECT COUNT(*) AS opciones, ROUND(SUM(LENGTH(option_value)) / 1024) AS kb
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');

Las 30 opciones cargadas automáticamente más pesadas:

SELECT option_name, autoload, ROUND(LENGTH(option_value) / 1024, 1) AS kb
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY LENGTH(option_value) DESC
LIMIT 30;

Qué plugin o tema consume más recursos (agrupados por prefijo):

SELECT SUBSTRING_INDEX(option_name, '_', 1) AS prefijo, COUNT(*) AS opciones,
ROUND(SUM(LENGTH(option_value)) / 1024, 1) AS kb
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
GROUP BY prefijo
ORDER BY kb DESC
LIMIT 20;

Los transitorios empiezan por guion bajo (_transient_...), así que en esta última te aparecen agrupados con el prefijo vacío.

Qué opciones puedes pasar a off y cuáles no

Esto no es algo del manual, es una regla mía, la que aplico en todas las webs que mantengo, pero eso sí, es muy sencilla:

Si no sabes al 100% de qué es algo en la base de datos no lo toques. Has vivido con ello hasta ahora, seguro que puedes seguir viviendo con ello.

Y no lo digo por decir, cuando reviso la base de datos de un cliente lo hago con él delante, porque es el único que sabe qué tiene y qué ha tenido instalado, y aun así hay tablas y opciones que ni por el nombre ni por su contenido te dejan adivinar de dónde vienen. Ningún plugin ni ninguna consulta te lo va a resolver, vemos algo más de detalle luego.

Lo que NO deberías tocar nunca

Las opciones del núcleo de WordPress. Se leen en todas las peticiones, así que quitarles el autoload no ahorra nada y añade consultas.

Algunas de las más habituales en la lista de pesadas son siteurl, home, active_plugins, template, stylesheet, cron, rewrite_rules, wp_user_roles, sidebars_widgets y todas las que empiezan por widget_ o theme_mods_.

Si cron o rewrite_rules pesan una barbaridad, el autoload no es el problema, es el síntoma. Un cron enorme suele indicar tareas programadas que se acumulan sin ejecutarse, y unas reglas de rewrite gigantes, algún plugin que las regenera sin parar. Eso se arregla en el origen, no manoseando la base de datos.

Lo que SÍ puedes pasar a off

• Opciones de plugins o temas que SABES que ya no usas: si recuerdas perfectamente haber desinstalado un plugin de formularios hace dos años y ves sus opciones en la lista, fuera autoload, que no las necesita nadie.
• Datos grandes de plugins activos que solo se usan en el escritorio: registros de actividad, estadísticas, informes o cachés internas de un plugin que conoces, y que no hacen falta para mostrar tu web a los visitantes.
• Transitorios cargados automáticamente: los datos transitorios con caducidad ya se guardan sin autoload, así que los que te salgan cargados automáticamente son transitorios sin caducidad. Pasarlos a off es inofensivo, como mucho añade un par de consultas donde se usen.

Todo lo que no encaje en esa lista se queda como está. Te lo repito porque es lo que evita disgustos, ante la duda no lo toques.

Cómo hacer limpieza (segura) de opciones cargadas automáticamente con SQL

Hacer una copia de seguridad completa de la base de datos antes de cada mínimo cambio, comprobar exhaustivamente y pasar al siguiente es lo que te dirá todo el mundo, y en la práctica no lo hace nadie, porque es inviable, imagina ese proceso multiplicado por decenas o centenares de opciones. ¡Que sí, que es lo recomendable, lo más seguro, pero no te mientas, no lo vas a hacer!

Así que vamos a hacerlo de otra manera, razonable, viable, sencilla.

La cosa es hacer una copia completa al principio, y una tabla pequeña con los valores originales que te permite deshacer cada cambio en una sola consulta. Antes de nada haz esa copia de seguridad de la base de datos completa, es tu red por si todo lo demás falla.

Guarda el valor original de las opciones que vas a cambiar

Sustituye opcion_1 y opcion_2 por los nombres de las opciones que hayas decidido pasar a off:

CREATE TABLE wp_autoload_copia AS
SELECT option_name, autoload
FROM wp_options
WHERE option_name IN ('opcion_1', 'opcion_2');

Si más adelante haces una segunda tanda, la tabla ya existe y la consulta anterior te dará error. En ese caso añade las nuevas así:

INSERT INTO wp_autoload_copia (option_name, autoload)
SELECT option_name, autoload
FROM wp_options
WHERE option_name IN ('opcion_3');

Desactiva el autoload (donde querías llegar)

UPDATE wp_options
SET autoload = 'off'
WHERE option_name IN ('opcion_1', 'opcion_2');

Uso off y no no porque es el valor que usa WordPress actualmente.

Vacía la caché de objetos si la tienes (extra)

Si tu web usa caché de objetos persistente (Redis o Memcached), las opciones cargarla automáticamente están guardadas ahí y el cambio no se nota hasta que la vacíes. Hazlo desde el plugin de caché que uses o desde el panel de tu alojamiento. Si no tienes caché de objetos persistente te ahorras este paso.

Si algo falla da marcha atrás

Para deshacer todos los cambios de golpe:

UPDATE wp_options o
JOIN wp_autoload_copia c ON o.option_name = c.option_name
SET o.autoload = c.autoload;

Y si solo quieres restaurar una, añade al final WHERE c.option_name = 'opcion_1'. Después, vuelve a vaciar la caché de objetos si la tienes.

Cuando todo esté estable borra la copia (el paso final)

Pasadas unas semanas, días como mínimo y solo si es un sitio pequeño, borra la copia que hiciste al principio, sin problemas, ya no la necesitas:

DROP TABLE wp_autoload_copia;

Lo mismo, pero con un plugin de usar y tirar

Si prefieres no tocar phpMyAdmin te he preparado un pequeño plugin que hace lo mismo desde el escritorio de WordPress, y además se encarga de vaciar la caché de objetos por ti, porque usa la función del núcleo wp_set_option_autoload_values(), que cambia solo el autoload sin tocar el valor de la opción.

¿Que por qué un plugin normal y no un mu-plugin (esos que van en wp-content/mu-plugins y se cargan siempre)? Pues porque un mu-plugin no aparece en la lista de plugins de siempre ni se puede desactivar, y es facilísimo olvidarse de que está ahí. Esto es una herramienta para usarla y luego borrarla, así que mejor algo que ves en Plugins cada vez que entras y que desactivas y borras con dos clics cuando acabas.

Esto es lo que hace:

• Antes de dejarte tocar nada, te obliga a descargar una copia completa de la base de datos en un archivo .sql. Hasta que no la descargas, las opciones no se pueden seleccionar. Si tu base de datos es muy grande y la descarga falla, puedes hacer la copia desde phpMyAdmin o desde el panel de tu alojamiento y confirmarlo en el propio plugin.
• Te muestra el tamaño total del autoload y las 50 opciones cargadas automáticamente más pesadas, que es donde está el peso, con un enlace para verlas todas si lo necesitas.
• Bloquea las opciones del núcleo, así que no puedes desactivarlas aunque te despistes.
• Antes de cambiar nada, guarda el valor original de cada opción en una opción propia que no se carga automáticamente.
• Te enseña las opciones que has cambiado, con su valor anterior y el actual, y te avisa si alguna ha vuelto a cargarse automáticamente sola.
• Te permite deshacer los cambios de las que quieras.
• Solo lo pueden usar los administradores, y todas las acciones llevan su comprobación de seguridad.

Necesita WordPress 6.6 o superior, y montarlo es muy fácil:

1. Crea un archivo llamado ayudawp-desactivar-autoload.php, pega dentro el código.
2. Guárdalo en tu ordenador en una carpeta llamada ayudawp-desactivar-autoload.
3. Comprime la carpeta en un zip y súbelo desde «Plugins > Añadir nuevo plugin > Subir plugin», como cualquier otro plugin.

<?php
/**
 * Plugin Name:       Desactivar opciones en autoload (temporal - borrar tras utilizarlo)
 * Description:       Herramienta temporal para revisar las opciones de la tabla wp_options que se cargan en cada visita (autoload) y desactivar la carga automática de las que elijas, sin borrarlas. Antes de tocar nada obliga a descargar una copia completa de la base de datos, guarda el valor original de cada opción que cambias y te permite deshacer cada cambio. Las opciones del núcleo de WordPress están bloqueadas. Úsala desde Herramientas y, cuando termines, desactívala y bórrala.
 * Version:           1.0.0
 * Requires at least: 6.6
 * Requires PHP:      7.4
 * Author:            Fernando Tellado
 * Author URI:        https://ayudawp.com
 * License:           GPL-2.0-or-later
 * Text Domain:       ayudawp-desactivar-autoload
 */

defined( 'ABSPATH' ) || exit;

// Option that stores the original autoload value of every option we change.
const AYUDAWP_DESACTIVAR_AUTOLOAD_BACKUP = 'ayudawp_desactivar_autoload_backup';

// Option that stores when the last full database backup was downloaded or confirmed.
const AYUDAWP_DESACTIVAR_AUTOLOAD_DB_COPY = 'ayudawp_desactivar_autoload_db_copy';

// How long a backup counts as recent before the tool asks for a new one.
const AYUDAWP_DESACTIVAR_AUTOLOAD_DB_COPY_TTL = DAY_IN_SECONDS;

// Register the uninstall callback only once, on activation.
register_activation_hook(
	__FILE__,
	function () {
		register_uninstall_hook( __FILE__, 'ayudawp_desactivar_autoload_uninstall' );
	}
);

/**
 * Remove the plugin options when the plugin is deleted.
 */
function ayudawp_desactivar_autoload_uninstall() {
	delete_option( AYUDAWP_DESACTIVAR_AUTOLOAD_BACKUP );
	delete_option( AYUDAWP_DESACTIVAR_AUTOLOAD_DB_COPY );
}

add_action( 'admin_menu', 'ayudawp_desactivar_autoload_menu' );

/**
 * Add the tool under Tools.
 */
function ayudawp_desactivar_autoload_menu() {
	$hook = add_management_page(
		__( 'Desactivar opciones en autoload (temporal - borrar tras utilizarlo)', 'ayudawp-desactivar-autoload' ),
		__( 'Desactivar autoload', 'ayudawp-desactivar-autoload' ),
		'manage_options',
		'ayudawp-desactivar-autoload',
		'ayudawp_desactivar_autoload_page'
	);

	if ( $hook ) {
		add_action( 'load-' . $hook, 'ayudawp_desactivar_autoload_handle' );
	}
}

/**
 * URL of the tool page.
 *
 * @param array $args Extra query args.
 * @return string
 */
function ayudawp_desactivar_autoload_url( $args = array() ) {
	return add_query_arg( array_merge( array( 'page' => 'ayudawp-desactivar-autoload' ), $args ), admin_url( 'tools.php' ) );
}

/**
 * Whether a full database backup was downloaded or confirmed recently.
 *
 * @return bool
 */
function ayudawp_desactivar_autoload_has_recent_copy() {
	$time = (int) get_option( AYUDAWP_DESACTIVAR_AUTOLOAD_DB_COPY, 0 );
	return $time && ( time() - $time ) < AYUDAWP_DESACTIVAR_AUTOLOAD_DB_COPY_TTL;
}

/**
 * Core options we never touch, plus widget and theme_mods prefixes.
 *
 * @param string $name Option name.
 * @return bool
 */
function ayudawp_desactivar_autoload_is_protected( $name ) {
	global $wpdb;

	$core = array(
		'siteurl', 'home', 'blogname', 'blogdescription', 'admin_email', 'active_plugins',
		'template', 'stylesheet', 'current_theme', 'cron', 'rewrite_rules', 'permalink_structure',
		'category_base', 'tag_base', 'blog_charset', 'html_type', 'WPLANG', 'timezone_string',
		'gmt_offset', 'date_format', 'time_format', 'start_of_week', 'show_on_front',
		'page_on_front', 'page_for_posts', 'posts_per_page', 'blog_public', 'default_role',
		'users_can_register', 'db_version', 'initial_db_version', 'sidebars_widgets',
		'sticky_posts', 'uninstall_plugins', 'recently_activated', 'can_compress_scripts',
		'upload_path', 'upload_url_path', 'uploads_use_yearmonth_folders', 'site_icon',
		'thumbnail_size_w', 'thumbnail_size_h', 'thumbnail_crop', 'medium_size_w',
		'medium_size_h', 'medium_large_size_w', 'medium_large_size_h', 'large_size_w',
		'large_size_h', 'wp_page_for_privacy_policy', 'recovery_keys', 'fresh_site',
		'auto_update_plugins', 'auto_update_themes', 'wp_force_deactivated_plugins',
		$wpdb->prefix . 'user_roles',
	);

	if ( in_array( $name, $core, true ) ) {
		return true;
	}

	foreach ( array( 'widget_', 'theme_mods_' ) as $prefix ) {
		if ( 0 === strpos( $name, $prefix ) ) {
			return true;
		}
	}

	return false;
}

/**
 * Process downloads and forms, then redirect (post/redirect/get).
 */
function ayudawp_desactivar_autoload_handle() {
	if ( ! current_user_can( 'manage_options' ) ) {
		return;
	}

	// Full database download.
	if ( isset( $_GET['ayudawp_desactivar_autoload_download'] ) ) {
		check_admin_referer( 'ayudawp_desactivar_autoload_download' );
		ayudawp_desactivar_autoload_download_database();
		exit;
	}

	if ( ! isset( $_POST['ayudawp_desactivar_autoload_action'] ) || ! function_exists( 'wp_autoload_values_to_autoload' ) ) {
		return;
	}

	check_admin_referer( 'ayudawp_desactivar_autoload' );

	global $wpdb;

	$action   = sanitize_key( wp_unslash( $_POST['ayudawp_desactivar_autoload_action'] ) );
	$names    = isset( $_POST['ayudawp_desactivar_autoload_options'] ) ? array_map( 'sanitize_text_field', (array) wp_unslash( $_POST['ayudawp_desactivar_autoload_options'] ) ) : array();
	$backup   = get_option( AYUDAWP_DESACTIVAR_AUTOLOAD_BACKUP, array() );
	$backup   = is_array( $backup ) ? $backup : array();
	$autoload = wp_autoload_values_to_autoload();
	$changes  = array();

	// Backup made by other means (phpMyAdmin, hosting panel...).
	if ( 'confirm_copy' === $action ) {
		if ( ! empty( $_POST['ayudawp_desactivar_autoload_confirm'] ) ) {
			update_option( AYUDAWP_DESACTIVAR_AUTOLOAD_DB_COPY, time(), false );
		}
		wp_safe_redirect( ayudawp_desactivar_autoload_url() );
		exit;
	}

	if ( 'disable' === $action ) {
		// No changes without a recent full backup.
		if ( ! ayudawp_desactivar_autoload_has_recent_copy() ) {
			wp_safe_redirect( ayudawp_desactivar_autoload_url( array( 'ayudawp_done' => 'nocopy' ) ) );
			exit;
		}

		foreach ( $names as $name ) {
			if ( ayudawp_desactivar_autoload_is_protected( $name ) ) {
				continue;
			}

			// phpcs:ignore WordPress.DB.DirectDatabaseQuery
			$current = $wpdb->get_var( $wpdb->prepare( "SELECT autoload FROM {$wpdb->options} WHERE option_name = %s", $name ) );

			if ( null === $current || ! in_array( $current, $autoload, true ) ) {
				continue;
			}

			// Keep the very first original value if the option was changed before.
			if ( ! isset( $backup[ $name ] ) ) {
				$backup[ $name ] = $current;
			}

			$changes[ $name ] = false;
		}

		// Save the original values before touching anything.
		update_option( AYUDAWP_DESACTIVAR_AUTOLOAD_BACKUP, $backup, false );
	}

	if ( 'restore' === $action ) {
		foreach ( $names as $name ) {
			if ( ! isset( $backup[ $name ] ) ) {
				continue;
			}

			$changes[ $name ] = in_array( $backup[ $name ], $autoload, true );
			unset( $backup[ $name ] );
		}
	}

	if ( $changes ) {
		// Core function (WP 6.4+): changes autoload only and clears the options cache.
		wp_set_option_autoload_values( $changes );
	}

	if ( 'restore' === $action ) {
		if ( $backup ) {
			update_option( AYUDAWP_DESACTIVAR_AUTOLOAD_BACKUP, $backup, false );
		} else {
			delete_option( AYUDAWP_DESACTIVAR_AUTOLOAD_BACKUP );
		}
	}

	wp_safe_redirect(
		ayudawp_desactivar_autoload_url(
			array(
				'ayudawp_done'  => $action,
				'ayudawp_count' => count( $changes ),
			)
		)
	);
	exit;
}

/**
 * Stream a full SQL dump of every WordPress table in the database.
 */
function ayudawp_desactivar_autoload_download_database() {
	global $wpdb;

	if ( function_exists( 'set_time_limit' ) ) {
		@set_time_limit( 0 ); // phpcs:ignore WordPress.PHP.NoSilencedErrors
	}

	// phpcs:disable WordPress.DB.DirectDatabaseQuery, WordPress.DB.PreparedSQL.InterpolatedNotPrepared, WordPress.Security.EscapeOutput.OutputNotEscaped
	$tables = $wpdb->get_col(
		$wpdb->prepare( 'SHOW FULL TABLES WHERE Table_type = %s', 'BASE TABLE' )
	);

	// Only the tables of this WordPress install (all sites in a network).
	$prefix = $wpdb->base_prefix;
	$tables = array_values(
		array_filter(
			$tables,
			function ( $table ) use ( $prefix ) {
				return 0 === strpos( $table, $prefix );
			}
		)
	);

	// Record the backup before sending anything.
	update_option( AYUDAWP_DESACTIVAR_AUTOLOAD_DB_COPY, time(), false );

	while ( ob_get_level() ) {
		ob_end_clean();
	}

	$filename = sanitize_file_name( DB_NAME . '-' . gmdate( 'Y-m-d-His' ) . '.sql' );

	nocache_headers();
	header( 'Content-Type: application/sql; charset=utf-8' );
	header( 'Content-Disposition: attachment; filename="' . $filename . '"' );

	echo "-- Copia completa de la base de datos\n";
	echo '-- Sitio: ' . home_url() . "\n";
	echo '-- Fecha (UTC): ' . gmdate( 'Y-m-d H:i:s' ) . "\n\n";
	echo "SET NAMES utf8mb4;\nSET FOREIGN_KEY_CHECKS = 0;\nSET SQL_MODE = 'NO_AUTO_VALUE_ON_ZERO';\n\n";

	foreach ( $tables as $table ) {
		$create = $wpdb->get_row( "SHOW CREATE TABLE `{$table}`", ARRAY_N );

		if ( empty( $create[1] ) ) {
			continue;
		}

		echo "DROP TABLE IF EXISTS `{$table}`;\n" . $create[1] . ";\n\n";

		$batch  = 500;
		$offset = 0;

		do {
			$rows = $wpdb->get_results( $wpdb->prepare( "SELECT * FROM `{$table}` LIMIT %d OFFSET %d", $batch, $offset ), ARRAY_A );

			if ( $rows ) {
				$columns = '`' . implode( '`, `', array_keys( $rows[0] ) ) . '`';
				$values  = array();

				foreach ( $rows as $row ) {
					$fields = array();
					foreach ( $row as $value ) {
						$fields[] = null === $value
							? 'NULL'
							: "'" . $wpdb->remove_placeholder_escape( $wpdb->_real_escape( $value ) ) . "'";
					}
					$values[] = '(' . implode( ', ', $fields ) . ')';
				}

				echo "INSERT INTO `{$table}` ({$columns}) VALUES\n" . implode( ",\n", $values ) . ";\n";
				flush();
			}

			$offset += $batch;
			$wpdb->flush();
		} while ( count( $rows ) === $batch );

		echo "\n";
	}

	echo "SET FOREIGN_KEY_CHECKS = 1;\n";
	// phpcs:enable
}

/**
 * Render the tool page.
 */
function ayudawp_desactivar_autoload_page() {
	if ( ! current_user_can( 'manage_options' ) ) {
		return;
	}

	echo '<div class="wrap"><h1>' . esc_html__( 'Desactivar opciones en autoload (temporal - borrar tras utilizarlo)', 'ayudawp-desactivar-autoload' ) . '</h1>';

	if ( ! function_exists( 'wp_autoload_values_to_autoload' ) ) {
		echo '<div class="notice notice-error"><p>' . esc_html__( 'Esta herramienta necesita WordPress 6.6 o superior.', 'ayudawp-desactivar-autoload' ) . '</p></div></div>';
		return;
	}

	global $wpdb;

	// phpcs:disable WordPress.Security.NonceVerification.Recommended
	if ( isset( $_GET['ayudawp_done'] ) ) {
		$done  = sanitize_key( wp_unslash( $_GET['ayudawp_done'] ) );
		$count = isset( $_GET['ayudawp_count'] ) ? absint( $_GET['ayudawp_count'] ) : 0;

		if ( 'nocopy' === $done ) {
			echo '<div class="notice notice-error is-dismissible"><p>' . esc_html__( 'No se ha cambiado nada. Antes tienes que descargar una copia completa de la base de datos.', 'ayudawp-desactivar-autoload' ) . '</p></div>';
		} else {
			$text = 'restore' === $done
				/* translators: %d: number of options */
				? sprintf( __( 'Autoload restaurado en %d opciones.', 'ayudawp-desactivar-autoload' ), $count )
				/* translators: %d: number of options */
				: sprintf( __( 'Autoload desactivado en %d opciones.', 'ayudawp-desactivar-autoload' ), $count );
			echo '<div class="notice notice-success is-dismissible"><p>' . esc_html( $text ) . '</p></div>';
		}
	}

	$show_all = isset( $_GET['ayudawp_ver'] ) && 'todas' === sanitize_key( wp_unslash( $_GET['ayudawp_ver'] ) );
	// phpcs:enable

	$has_copy = ayudawp_desactivar_autoload_has_recent_copy();

	// Section 1: mandatory full database backup.
	echo '<h2>' . esc_html__( '1. Descarga una copia completa de la base de datos (obligatorio)', 'ayudawp-desactivar-autoload' ) . '</h2>';
	echo '<p>' . esc_html__( 'Hasta que no descargues una copia completa de la base de datos no podrás desactivar el autoload de ninguna opción. La copia es válida durante 24 horas. Guarda el archivo .sql en tu ordenador, que es lo que te permite restaurarlo todo si algo sale mal.', 'ayudawp-desactivar-autoload' ) . '</p>';

	if ( $has_copy ) {
		$time = (int) get_option( AYUDAWP_DESACTIVAR_AUTOLOAD_DB_COPY, 0 );
		printf(
			'<p><strong>%s</strong></p>',
			esc_html(
				sprintf(
					/* translators: %s: date and time */
					__( 'Última copia: %s. Ya puedes seguir con el paso 2.', 'ayudawp-desactivar-autoload' ),
					wp_date( get_option( 'date_format' ) . ' ' . get_option( 'time_format' ), $time )
				)
			)
		);
	}

	printf(
		'<p><a href="%1$s" class="button button-primary">%2$s</a></p>',
		esc_url( wp_nonce_url( ayudawp_desactivar_autoload_url( array( 'ayudawp_desactivar_autoload_download' => 1 ) ), 'ayudawp_desactivar_autoload_download' ) ),
		esc_html__( 'Descargar la base de datos completa (.sql)', 'ayudawp-desactivar-autoload' )
	);

	echo '<p class="description">' . esc_html__( 'Tras pulsar el botón, recarga esta página para continuar. Si tu base de datos es muy grande y la descarga falla, haz la copia desde phpMyAdmin o desde el panel de tu alojamiento y confírmalo aquí:', 'ayudawp-desactivar-autoload' ) . '</p>';
	echo '<form method="post">';
	wp_nonce_field( 'ayudawp_desactivar_autoload' );
	echo '<input type="hidden" name="ayudawp_desactivar_autoload_action" value="confirm_copy">';
	echo '<label><input type="checkbox" name="ayudawp_desactivar_autoload_confirm" value="1" required> ' . esc_html__( 'He hecho una copia completa de la base de datos por otro medio y la tengo guardada.', 'ayudawp-desactivar-autoload' ) . '</label> ';
	submit_button( __( 'Confirmar', 'ayudawp-desactivar-autoload' ), 'secondary', 'submit', false );
	echo '</form>';

	// Section 2: autoloaded options.
	$autoload     = wp_autoload_values_to_autoload();
	$placeholders = implode( ',', array_fill( 0, count( $autoload ), '%s' ) );
	$limit_sql    = $show_all ? '' : ' LIMIT 50';

	// phpcs:disable WordPress.DB.DirectDatabaseQuery, WordPress.DB.PreparedSQLPlaceholders, WordPress.DB.PreparedSQL.InterpolatedNotPrepared
	$totals = $wpdb->get_row(
		$wpdb->prepare( "SELECT COUNT(*) AS total, SUM(LENGTH(option_value)) AS size FROM {$wpdb->options} WHERE autoload IN ($placeholders)", $autoload )
	);

	$rows = $wpdb->get_results(
		$wpdb->prepare(
			"SELECT option_name, autoload, LENGTH(option_value) AS size FROM {$wpdb->options} WHERE autoload IN ($placeholders) ORDER BY size DESC{$limit_sql}",
			$autoload
		)
	);
	// phpcs:enable

	echo '<h2>' . esc_html__( '2. Opciones cargadas automáticamente', 'ayudawp-desactivar-autoload' ) . '</h2>';

	printf(
		'<p>%s</p>',
		esc_html(
			sprintf(
				/* translators: 1: number of options, 2: total size */
				__( 'Opciones cargadas automáticamente: %1$d, con un tamaño total de %2$s.', 'ayudawp-desactivar-autoload' ),
				(int) $totals->total,
				size_format( (int) $totals->size, 1 )
			)
		)
	);

	printf(
		'<p>%1$s <a href="%2$s">%3$s</a></p>',
		esc_html(
			$show_all
				? __( 'Estás viendo todas las opciones cargadas automáticamente, de la más pesada a la más ligera.', 'ayudawp-desactivar-autoload' )
				: __( 'Estás viendo las 50 opciones cargadas automáticamente más pesadas.', 'ayudawp-desactivar-autoload' )
		),
		esc_url( $show_all ? ayudawp_desactivar_autoload_url() : ayudawp_desactivar_autoload_url( array( 'ayudawp_ver' => 'todas' ) ) ),
		esc_html( $show_all ? __( 'Ver solo las 50 más pesadas', 'ayudawp-desactivar-autoload' ) : __( 'Ver todas', 'ayudawp-desactivar-autoload' ) )
	);

	echo '<p>' . esc_html__( 'Marca solo las opciones que sepas con seguridad de qué plugin o tema son. Las del núcleo de WordPress están bloqueadas. Desactivar el autoload no borra la opción, solo hace que no se cargue en cada visita.', 'ayudawp-desactivar-autoload' ) . '</p>';

	if ( ! $has_copy ) {
		echo '<div class="notice notice-warning inline"><p>' . esc_html__( 'Descarga primero la copia completa de la base de datos (paso 1) para poder desactivar el autoload.', 'ayudawp-desactivar-autoload' ) . '</p></div>';
	}

	echo '<form method="post">';
	wp_nonce_field( 'ayudawp_desactivar_autoload' );
	echo '<input type="hidden" name="ayudawp_desactivar_autoload_action" value="disable">';
	echo '<table class="widefat striped"><thead><tr><th></th><th>' . esc_html__( 'Opción', 'ayudawp-desactivar-autoload' ) . '</th><th>autoload</th><th>' . esc_html__( 'Tamaño', 'ayudawp-desactivar-autoload' ) . '</th></tr></thead><tbody>';

	foreach ( $rows as $row ) {
		$protected = ayudawp_desactivar_autoload_is_protected( $row->option_name );
		printf(
			'<tr><td>%1$s</td><td><code>%2$s</code></td><td>%3$s</td><td>%4$s</td></tr>',
			$protected
				? esc_html__( 'Núcleo', 'ayudawp-desactivar-autoload' )
				: '<input type="checkbox" name="ayudawp_desactivar_autoload_options[]" value="' . esc_attr( $row->option_name ) . '"' . disabled( $has_copy, false, false ) . '>',
			esc_html( $row->option_name ),
			esc_html( $row->autoload ),
			esc_html( size_format( (int) $row->size, 1 ) )
		);
	}

	echo '</tbody></table>';
	submit_button( __( 'Desactivar autoload de las seleccionadas', 'ayudawp-desactivar-autoload' ), 'primary', 'submit', true, $has_copy ? null : array( 'disabled' => 'disabled' ) );
	echo '</form>';

	// Section 3: changed options and undo.
	$backup = get_option( AYUDAWP_DESACTIVAR_AUTOLOAD_BACKUP, array() );

	echo '<h2>' . esc_html__( '3. Opciones modificadas', 'ayudawp-desactivar-autoload' ) . '</h2>';
	echo '<p>' . esc_html__( 'Cada vez que desactivas el autoload de una opción, aparece en esta tabla con el valor que tenía antes y el que tiene ahora. Desde aquí puedes deshacer el cambio de las que quieras. Si una opción aparece como «Ha vuelto a cargarse automáticamente», es que su plugin la guarda forzando el autoload y no merece la pena insistir. Ojo, al borrar este plugin se borra también esta lista, así que deshaz lo que quieras deshacer antes de borrarlo.', 'ayudawp-desactivar-autoload' ) . '</p>';

	if ( empty( $backup ) || ! is_array( $backup ) ) {
		echo '<p><em>' . esc_html__( 'Todavía no has modificado ninguna opción.', 'ayudawp-desactivar-autoload' ) . '</em></p></div>';
		return;
	}

	$names = array_keys( $backup );
	$in    = implode( ',', array_fill( 0, count( $names ), '%s' ) );

	// phpcs:disable WordPress.DB.DirectDatabaseQuery, WordPress.DB.PreparedSQLPlaceholders, WordPress.DB.PreparedSQL.InterpolatedNotPrepared
	$current = $wpdb->get_results(
		$wpdb->prepare( "SELECT option_name, autoload FROM {$wpdb->options} WHERE option_name IN ($in)", $names ),
		OBJECT_K
	);
	// phpcs:enable

	echo '<form method="post">';
	wp_nonce_field( 'ayudawp_desactivar_autoload' );
	echo '<input type="hidden" name="ayudawp_desactivar_autoload_action" value="restore">';
	echo '<table class="widefat striped"><thead><tr><th></th><th>' . esc_html__( 'Opción', 'ayudawp-desactivar-autoload' ) . '</th><th>' . esc_html__( 'Antes', 'ayudawp-desactivar-autoload' ) . '</th><th>' . esc_html__( 'Ahora', 'ayudawp-desactivar-autoload' ) . '</th><th>' . esc_html__( 'Aviso', 'ayudawp-desactivar-autoload' ) . '</th></tr></thead><tbody>';

	foreach ( $backup as $name => $original ) {
		$now  = isset( $current[ $name ] ) ? $current[ $name ]->autoload : '';
		$note = '';

		if ( '' === $now ) {
			$note = __( 'Ya no existe', 'ayudawp-desactivar-autoload' );
		} elseif ( in_array( $now, $autoload, true ) ) {
			$note = __( 'Ha vuelto a cargarse automáticamente', 'ayudawp-desactivar-autoload' );
		}

		printf(
			'<tr><td><input type="checkbox" name="ayudawp_desactivar_autoload_options[]" value="%1$s"></td><td><code>%2$s</code></td><td>%3$s</td><td>%4$s</td><td>%5$s</td></tr>',
			esc_attr( $name ),
			esc_html( $name ),
			esc_html( $original ),
			esc_html( $now ),
			esc_html( $note )
		);
	}

	echo '</tbody></table>';
	submit_button( __( 'Deshacer los cambios de las seleccionadas', 'ayudawp-desactivar-autoload' ), 'secondary' );
	echo '</form></div>';
}

Una vez activado lo tienes en «Herramientas > Desactivar autoload». Lo primero que te pide es descargar la copia de la base de datos, y cuando la tienes guardada, marcas las opciones que sabes de quién son, haces clic en «Desactivar autoload de las seleccionadas» y listo.

Un aviso importante, al borrar el plugin se borra también la copia de los valores originales, y los cambios que hayas hecho se quedan como están. Si quieres deshacer algo, hazlo antes de borrarlo. El archivo .sql que descargaste, en cambio, sigue en tu ordenador, y es tu red si algo sale mal.

Truco: Si no te apañas con montar el plugin aquí te lo dejo ya en un zip listo para descarga, para que solo tengas que subirlo como expliqué arriba.

Comprueba que no hayas empeorado nada

Desactivar el autoload de una opción que en realidad se usa en todas las páginas no rompe nada, pero te sale el tiro por la culata, porque cambias una opción dentro de la carga común por una consulta extra en cada visita. Así que toca comprobarlo.

La forma más fácil es con Query Monitor. Navega por la parte pública de tu web, abre el panel de consultas y filtra por la función que las hace, get_option(). Verás consultas sueltas como esta:

SELECT option_value FROM wp_options WHERE option_name = 'opcion_1' LIMIT 1

Si una de las opciones que has cambiado aparece así en todas las páginas, devuélvele el autoload, que ahí sí pintaba algo.

Deja pasar también unos días y mira si algún plugin ha vuelto a activar el autoload por su cuenta. Con el plugin de usar y tirar lo ves en la tabla de opciones cambiadas, y con SQL así:

SELECT c.option_name, c.autoload AS antes, o.autoload AS ahora
FROM wp_autoload_copia c
JOIN wp_options o ON o.option_name = c.option_name
WHERE o.autoload IN ('yes', 'on', 'auto-on', 'auto');

Si alguna vuelve a estar cargada automáticamente, ese plugin la guarda forzando el autoload cada vez que la actualiza, y no merece la pena pelearse con él.

Y por último, vuelve a «Herramientas > Salud del sitio» para ver cómo ha quedado.

¿Se pueden desactivar opciones en autoload con plugins?

Si prefieres un plugin de los que hay disponibles te cuento cómo lo hacen los tres que te vas a encontrar, porque los he revisado y probado, y no todos hacen lo mismo aunque lo parezca. Los criterios son los de todo el artículo, que sea reversible, que vacíe la caché de objetos al cambiar el autoload y que no te deje tocar las opciones del núcleo.

Antes de nada un aviso que me sale de la experiencia, y es que ningún plugin sabe con garantías de quién es cada opción. Tengo la versión Premium de Advanced Database Cleaner pagada desde hace años, que es prácticamente un estándar, y no la uso para esto, porque como todos los de su estilo confunde opciones huérfanas con opciones del núcleo, o del tema con las de un plugin, y cosas así.

La regla del 100% sigue en pie uses lo que uses, no toques nada que no sepas EXACTAMENTE de qué es.

Advanced Database Cleaner

Advanced Database Cleaner es el que mejor resuelve lo del autoload. Cambia el valor con los actuales on y off, vacía la caché de opciones justo después y, por defecto, no te deja cambiar el autoload de las opciones del núcleo. Te enseña además el tamaño total con el mismo umbral que Salud del sitio, y volver atrás es cuestión de un clic.

Las pegas son que no sabe si una opción se usa o no (igual que las consultas SQL), y que es un plugin enorme para lo que necesitas aquí. Mi consejo es instalarlo, hacer el cambio y desinstalarlo.

AAA Option Optimizer

AAA Option Optimizer es el único que mide qué opciones se usan de verdad mientras navegas por la web, y como detector no tiene rival, por eso te lo recomendé en su día, y lo sigo haciendo (para eso). Como herramienta para aplicar los cambios ya no es tan majete.

Para cambiar el autoload borra la opción y la vuelve a crear, en lugar de cambiar solo el campo autoload, y eso tiene consecuencias. Se disparan las acciones de borrado de opciones, a las que algunos plugins reaccionan, y si la creación falla después del borrado, la opción se queda borrada. Tampoco he encontrado en su código ningún bloqueo para las opciones del núcleo.

Y hay un botón que yo no pulsaría, el de crear con valor false las opciones que se piden y no existen. Sin caché de objetos persistente no te ahorra ni una consulta, y además cambia lo que recibe el plugin que la pide, que pasa a encontrarse un valor vacío en lugar del valor por defecto que esperaba.

Así que úsalo para lo que es bueno. Déjalo unos días, apunta lo que aparece en No utilizada pero cargada automáticamente y haz los cambios con el método manual, con el plugin de usar y tirar o con Advanced Database Cleaner.

Autoload Optimizer

Autoload Optimizer guarda la lista de opciones que ha desactivado para poder revertirlas, y eso está bien, pero no lo recomendaría. Cambia el autoload con los valores antiguos, no vacía la caché de objetos (con Redis o Memcached no verás el cambio hasta que alguien la vacíe) y no protege las opciones del núcleo.

Tiene además un botón que pasa a no de golpe todos los transitorios cargados automáticamente, algo inofensivo en sí mismo pero que no te deja revisar qué estás cambiando.

¿No las puedo borrar directamente y ya?

Borrar una opción solo tiene sentido si se cumplen dos cosas a la vez.

1. Sabes al 100% que es de algo que ya no está instalado.
2. Lleva semanas con el autoload desactivado sin que nada haya dejado de funcionar.

Si se cumplen estas dos reglas haz una copia de seguridad de la base de datos (en serio, son unos segundos) y borra las que sobren. Tienes más detalles sobre esto en mi artículo sobre cómo limpiar la tabla wp_options. Si no cumples las dos condiciones las opciones se quedan, en off, que ni molestan ni piden pan.

Extra: WordPress multisitio

En una red multisitio cada sitio tiene su propia tabla de opciones (wp_options para el principal, wp_2_options, wp_3_options y así sucesivamente), y cada una se mide por separado. El aviso de salud del sitio es de cada sitio, no de la red.

Para ver qué tablas de opciones tienes:

SELECT table_name
FROM information_schema.tables
WHERE table_schema = DATABASE()
AND table_name LIKE 'wp\_%options';

Después repites el diagnóstico y la prueba reversible cambiando wp_options por la tabla de cada sitio, y si usas la tabla de copia, crea una por sitio para no mezclar (wp_2_autoload_copia, por ejemplo).

El plugin de usar y tirar funciona igual en cada sitio. Actívalo en el sitio que quieras revisar o actívalo en toda la red, y lo tendrás en Herramientas de cada uno, trabajando solo sobre la tabla de ese sitio.

Las opciones de la red, las de la tabla wp_sitemeta, no tienen columna de autoload, así que no entran en todo esto.

¿Me resumes qué hacer con el aviso de error de opciones cargadas automáticamente?

Esto es un resumen, pero no explica todo lo que tienes que leer (obligatoriamente) ahí arriba, que es gratis e imprescindible, y luego todo son lloros. Dicho esto, este sería el orden que yo seguiría:

1. Mira el tamaño. Si estás cerca del umbral y la web va bien, no tienes que hacer nada.
2. Si está muy por encima, ejecuta las consultas de diagnóstico y localiza qué plugin o tema se lleva el grueso.
3. Pasa a off solo lo que sepas de quién es, guardando antes los valores originales, con SQL o con el plugin de usar y tirar.
4. Comprueba con Query Monitor que no has añadido consultas en todas las páginas.
5. Deja pasar unas semanas antes de pensar siquiera en borrar algo, y solo si tienes el 100% de seguridad.

Y si lo que crece es un plugin concreto que no para de meter datos en la tabla de opciones, el problema es el plugin, así que plantéate si lo necesitas o si hay alternativas que no lo hagan.

Si te surge alguna duda o te encuentras una opción rara que no sabes de dónde sale, me tienes ahí abajo en los comentarios.

Y es que una limpieza en condiciones son dos o tres días de trabajo, y puede que más, porque si toca, la de que Google quite el aviso de web peligrosa, y que los antivirus dejen de marcarla como infectada, se cuenta en semanas, y es fácil que se te pase algo.

Así que he decidido compartir la hoja de seguimiento con la que llevo trabajando años y te la puedes descargar para tus cosas.

Son, total nada, solo 77 comprobaciones repartidas en 8 fases, en una hoja de cálculo que rellenas y que te va diciendo en qué punto estás.

Gratis, sin registro y sin dejar el correo en ninguna parte, es una hoja de cálculo, la descargas en tu ordenador y la usas como y para lo que quieras.

No sustituye a una guía de limpieza ni al trabajo que supone, la acompaña, es una ayuda. Ya mismo te cuento qué tiene dentro y, sobre todo, los cuatro errores que podrías cometer si te saltas el orden y lo que te ahorra, que son los típicos fallos bobos que hacen que una limpieza haya que repetirla entera.

Esto no es otra guía de limpieza, es para que sepas por dónde vas

La guía completa la tengo publicada desde hace años y la voy actualizando, la tienes en cómo limpiar y recuperar un WordPress hackeado o infectado. Ahí está el procedimiento entero, paso por paso.

Lo que no cabe en un artículo, por largo que sea, es el seguimiento. Un tutorial te lo lees de una sentada, pero el trabajo dura días, y entre medias te llaman por teléfono, cierras el portátil, vuelves al día siguiente y ya no sabes si llegaste a mirar la carpeta mu-plugins o te quedaste en los drop-ins.

La guía te explica como se hace, pero necesitas una lista de tareas para no entregar como limpia una web en la que te dejaste varios pasos sin terminar.

Seguramente hay trabajos en web que no requieran este tipo de seguimiento, yo no los conozco, pero no dudo que tú sepas alguno, pero sí te aseguro que en seguridad no sobra ningún paso, y también tengo claro que el orden en tareas de limpieza de malware y virus importa y mucho.

Qué tiene dentro la hoja de seguimiento

Son 8 pestañas, cada una con su función:

• Portada: escribes tu dominio, tienes los avisos de lo que puede salir mal y un contador de avance por fases que se actualiza solo.
• Antes de empezar: los accesos y la información que conviene tener a mano antes de tocar nada, que si no acabas parando la limpieza a media faena para buscar una contraseña.
• Checklist: las 77 comprobaciones con su estado, su fecha y un hueco para notas.
• Diagnóstico: 27 comprobaciones de las que delatan una infección, cada una con cómo se mira desde fuera sin instalar nada.
• Comprobaciones online: 20 escáneres y servicios públicos, con el enlace de tu dominio si lo añadiste en la portada.
• Reputación y retiradas: dónde se mira cada aviso y, más importante, dónde se pide que te lo quiten.
• Patrones de código: 20 patrones que buscar en los ficheros y qué significa cada uno si aparece.
• No volver a pasar: las diez medidas de después, con el porqué de cada una.

El detalle que vas a agradecer es el del dominio, lo escribes una vez en la portada y los enlaces de los escáneres salen construidos con tu web dentro, así que no tienes que ir copiando y pegando en veinte formularios distintos mientras estás a tope de tareas.

Cada comprobación viene marcada con su nivel de riesgo, porque no es lo mismo mirar un archivo que borrarlo, y las que pueden dejarte la web fuera de servicio salen en rojo.

Los cuatro errores de orden que te va a evitar

Esto es lo que de verdad separa una limpieza que termina bien de una que hay que repetir, y sobre todo, la diferencia de entregar una web limpia a una que tirará por tierra tu reputación como profesional por haberte dejado cosas a medias o sin hacer.

No son nunca errores de conocimiento, son errores de orden, y nos pasa a todos si no tenemos consistencia en los procesos, o una hoja de seguimiento.

1. Pedir la revisión de seguridad a Google con la web aún no limpia del todo: Es lo primero que hace todo el mundo, porque el aviso rojo de Chrome aprieta, estamos todos deseando que desaparezca, tu cliente el primero. Si la pides antes de tiempo gastas el intento, Google vuelve a mirar, lo vuelve a encontrar y la siguiente revisión tarda más. En la hoja esa comprobación está en la fase 7, la última, y no por capricho. Lo tienes explicado en cómo quitar una web WordPress de la lista negra de Google.
2. Pedir la salida de las listas negras de correo con el servidor todavía enviando spam: Mismo problema que con el punto anterior, pero además generas trabajo improductivo de marketing, con una newsletter que sigue fallando y emails que no llegan a nadie por apresurarte.
3. Dar el trabajo por terminado el mismo día: Una web limpia el martes y reinfectada el jueves no estaba limpia, es que quedaba una puerta trasera o el agujero por el que entraron sigue abierto. Por eso hay una comprobación que consiste literalmente en esperar 72 horas y volver a mirar. En mi experiencia es casi el punto más importante de todo el listado, y además tiene connotaciones legales (lo detallo más abajo).
4. Dejarte el modo mantenimiento puesto: Quitas la página de aviso, te olvidas de la regla del .htaccess y tu portada sigue devolviendo un 503 a Google durante una semana. La web está perfecta pero perdiendo posicionamiento sin enterarte. En serio, pasa.

Si tu web guarda datos personales tienes 72 horas

Esta parte se salta casi siempre y es la única que tiene plazo legal. Si en la web hay clientes, pedidos, suscriptores o formularios guardados, y alguien ha podido acceder a eso, hay 72 horas para notificar la brecha a la Agencia Española de Protección de Datos, contadas desde que te enteras, no desde que terminas de limpiar.

Que una web sea pequeña, o tuya, no quita la obligación, porque el responsable del tratamiento ahora mismo eres tú. Eso sí, tampoco te vayas al otro extremo, porque en la mayoría de webs pequeñas la cosa se resuelve valorando el alcance y documentando la valoración, se notifique o no. Lo que no vale es no haber pensado en ello.

En la hoja son tres comprobaciones y están en la fase 0, antes de tocar un solo fichero, precisamente porque el plazo corre mientras limpias.

La descarga y los primeros cinco minutos

Aquí la tienes para descargarla gratis, en formato .xlsx, que se abre en Excel, en Numbers, en LibreOffice y en Google Sheets:

Tres cosas para empezar con buen pie:

• Escribe tu dominio arriba del todo de la hoja de portada, sin www y sin https, que de ahí salen todos los enlaces de otras hojas.
• Filtra la columna «Aplica si» y marca «No aplica» en lo que no sea tu caso, que si no tienes tienda te sobran unas cuantas comprobaciones.
• No empieces la fase 3 sin haber terminado la copia de la fase 1. Esa copia es tu red de seguridad y es la que te permite equivocarte.

Y guárdala aunque no la necesites hoy. El día que la necesites vas a tener otras cosas en la cabeza.

Hasta dónde llega la hoja de seguimiento

Para que no haya malentendidos, porque esto no es un folleto, la hoja no te encuentra por dónde te entraron a una web, eso lo tienes que averiguar tú, y sin saber por dónde entraron limpiar sirve solo de momento, porque volverán por el mismo sitio.

Hay tres situaciones en las que yo no seguiría sin ayuda:

• Si es una tienda y ha podido haber captura de datos de pago.
• Si el hosting ya te ha suspendido la cuenta.
• Si vas por la segunda reinfección. Ahí ya no hablamos de seguir una lista, hablamos de un trabajo de varios días con herramientas que no se improvisan y con un informe detrás.

Si estás en ese punto déjaselo a otros y tú sigue a tus tareas. Pero si prefieres intentarlo tú para eso tienes la hoja de seguimiento ¡a por ello!

Para que no haya una segunda vez

La última pestaña son diez medidas, pero si solo te llevas cuatro que sean estas: doble factor para todos los administradores, nada de plugins ni temas nulled, copias automáticas que hayas restaurado alguna vez de verdad, y vigilancia de cambios en archivos para enterarte tú antes que Google.

Para lo último tienes Vigilante, que ya sabes que es un plugin gratuito y hace justo eso, avisarte cuando un fichero cambia y cuando aparece una vulnerabilidad en algo que tienes instalado. Si prefieres no volver a pensar en esto nunca más, pues para eso está el servicio de mantenimiento, que es literalmente esto mismo hecho cada mes por alguien que no se olvida.

Y si ahora mismo solo quieres saber cómo está tu web, pásala por el análisis de seguridad, que tarda un minuto y no instala nada.

Si quieres profundizar en la parte de prevención tienes 15 maneras de proteger WordPress contra el malware, y si lo que te está pasando es que Google te devuelve resultados raros en japonés o de venta de relojes, eso tiene nombre y lo cuento en este otro artículo sobre spam SEO inyectado.

Úsala, rómpela y dime qué te ha faltado. La hoja la genero desde mi propio catálogo de comprobaciones, así que añadir lo que me digáis y sacar una versión nueva me cuesta cinco minutos. Me tienes ahí abajo, en la sección de comentarios.

Pues bien, yo creo que merece la pena pararse, porque una de las tres cosas que audita es justo el archivo que el propio equipo de Search de Google lleva año y medio diciendo, sin cortarse un pelo, que no sirve para nada.

Vamos a ver qué mide esa pestaña de verdad, por qué Google se contradice a sí mismo (más o menos), y qué necesita tu WordPress para aprobar esa puntuación agéntica, y ver qué hacen los plugins, que para eso están.

Qué es eso de «navegación agéntica» que ahora mide Google

La categoría llamada navegación agéntica o agentic browsing nació en Lighthouse, la herramienta de auditoría de Chrome, como algo experimental. Dejó de serlo en mayo de 2026, con la versión 13.3, cuando pasó a la configuración por defecto. Semanas después, PageSpeed Insights la heredó, así que ahora mismo cualquiera que meta una URL ahí la ve, sin haber activado nada.

Mide si un agente de inteligencia artificial que actúa en tu nombre puede entender tu web sin perderse. Es algo así como el Project Mariner de Google o cualquier asistente que compare precios, rellene un formulario o resuma una página por ti dentro de una sesión de navegador. No es SEO, no es una nota de posicionamiento, es una comprobación de si el agente se va a hacer un lío con tu HTML.

Y aquí ya hay algo que llama la atención, porque no hay ni siquera una media, solo un ratio de aprobados (algo como 2 de 3). La propia documentación de Chrome lo explica como que los estándares para este tipo de navegación todavía se están formando, así que de momento cuentan cuántas comprobaciones apruebas y punto, sin pretender siquiera que eso sea algo parecido a una nota fiable.

Las tres cosas que mira (nada nuevo bajo el sol)

Por defecto son tres, aunque hay una cuarta familia de comprobaciones, las de WebMCP, que dejo para el final porque no le va a tocar a casi nadie.

• El árbol de accesibilidad: Lighthouse no inventa nada nuevo aquí: filtra un subconjunto de las auditorías de accesibilidad que ya existían de toda la vida (nombres programáticos en los elementos interactivos, integridad del árbol de roles, visibilidad de lo que es clicable), porque un agente lee la misma estructura que usa un lector de pantalla. Traducción: si tu web ya saca buena nota en la categoría clásica de Accesibilidad de Lighthouse, lo más probable es que esto ya lo apruebes sin tocar nada.
• La estabilidad del diseño: Es el CLS (Cumulative Layout Shift, la métrica que mide los saltos de maquetación mientras carga la página) con el mismo umbral de siempre, el de Core Web Vitals desde hace años. Aquí no hay ni una coma de novedad técnica, solo lo han metido bajo otra etiqueta.
• El archivo llms.txt: Raro ¿verdad?. La comprobación es generosa porque si el archivo no existe, ni siquiera te penaliza, lo marca como «no aplicable». Si existe pero el servidor da error al servirlo, ahí sí da fallo. El detalle es que el fallo típico no suele ser «no tener el archivo», sino tenerlo mal formateado, o sea, enlaces sueltos en vez de la sintaxis Markdown [nombre](url) que exige la especificación de llmstxt.org. Un detalle tonto que puede hacer suspender aunque el archivo esté ahí desde hace meses. Esto pasa mucho, todo hay que decirlo, porque igual te crees que el generador llms.txt de Yoast y otros tantos que hay por ahí son válidos, pero no, ahora mismo solo VigIA y Vigilante entregan llms.txt con especificación estándar y formatos válidos v2.

Y sobre WebMCP, la parte que deja registrar formularios y botones (añadir al carrito, reservar, enviar) como herramientas que un agente puede invocar directamente, no forma parte de las tres comprobaciones por defecto, hace falta apuntarse a un origin trial de Chrome para que se audite.

Es un estándar que existe, con el W3C Web Machine Learning Community Group detrás y Microsoft co-desarrollándolo, no el DevTrial roto que parecía hace unos meses, pero para el 99 % de las webs WordPress, sobre todo blogs y sitios editoriales, esto no sirve aún de nada.

El único sitio donde empieza a tener sentido a medio plazo es una tienda WooCommerce, con el carrito y el pago como acciones invocables. Pero no es algo ni para hoy ni para el próximo trimestre, así que lo dejo aquí y sigo.

¿Google contra Google?

Aquí viene la parte que más me ha llamado la atención a mí también, porque el equipo de Search de Google lleva metiendo caña contra el llms.txt desde mediados de 2025. Gary Illyes llegó a decir en un directo, en un Search Central Live que Google no da soporte al archivo y no tiene planes de dárselo.

John Mueller fue todavía más lejos y lo comparó con la vieja meta etiqueta keywords, esa que rellenaba el propio sitio y que por eso mismo no servía de nada, al ser manipulable por principios (por mucho que Google haya vivido de ella durante años).

Y no es solo opinión de sus portavoces, los datos de campo respaldan la postura, eso es cierto. Kai Spriestersbach registró 62.100 peticiones de bots de IA en 90 días sobre un dominio de prueba, y solo 84 tocaron el llms.txt, un 0,1 % del tráfico de rastreo.

Un análisis de SE Ranking sobre 300.000 dominios no encontró correlación ninguna entre tener el archivo y aparecer citado en respuestas de IA. Con esos números entiendo perfectamente que Search diga que no sirve. Yo mismo aún estoy por ver que los rastreadores de IA busquen los llms.txt, es cierto que empiezo a ver con la analítica de VigIA que los leen, pero no los buscan, los encuentran si lo indicas en el código fuente.

Pero ahora resulta que el equipo de Chrome, de la misma empresa, te lo audita en una herramienta que lleva el sello de Google en la cabecera. No es que se estén mintiendo el uno al otro, seamos justos, hablan de casos de uso distintos.

Search piensa en indexación y ranking, Chrome piensa en un agente que opera dentro de una sesión de navegador, en tu nombre, y para el que un resumen rápido en la raíz del dominio sí ahorra tiempo de rastreo puntual, sea o no el mismo archivo que ignoran los buscadores.

Pero que tenga una explicación de arquitectura no lo salva de ser un desastre de comunicación externa, que es justo lo que me indigna del asunto. Es como el padre que dice una cosa y la madre la contraria, y el crío (el pobre SEO de turno, en este caso) sin saber a quién hacer caso.

Google publica en su propio sitio para desarrolladores una auditoría que premia justo lo que otro equipo de la misma casa lleva describiendo como inútil, y eso echa más leña al bucle de desinformación que ya generaba el llms.txt por su cuenta.

Lo que tenemos son herramientas SEO que lo marcan como problema, gente que se pone nerviosa, y la ansiedad alimentando la sensación de que hace falta cuando los datos dicen lo contrario. Esto solo sería un debate friki si no fuese porque hay millones de negocios a los que la aparición de las IAs generativas les han hecho mucho daño, y todos estamos queriendo saber cómo sobrevivir en este nuevo escenario, y esto no ayuda, solo confunde.

¿Hago algo en mi WordPress?

Vamos al grano, que para eso estamos aquí, yo no sé si esto al final irá a algún lado pero ya sabes que lo intento, y lo comparto con vosotros. Sin ir más lejos, con los plugins que he ido creando para ayudarme/nos a entender y seguir peleando por existir en este mundo extraño, el reparto real de estas tres comprobaciones de la navegación agéntica que mide PageSpeed queda así:

• Archivo llms.txt: Visibility genera llms.txt y llms-full.txt, sirve Markdown para agentes y edita el robots.txt con bloqueo de rastreadores de IA. Si en vez de Visibility tienes solo VigIA, también lo genera él, y si tienes los dos a la vez, VigIA se aparta y deja que emita Visibility, para no duplicar el archivo entre dos plugins tuyos. En mi propia web de mantenimiento la última auditoría que le pasé de visibilidad en IA confirma que hay una sola fuente de esquemas activa, el grafo de Visibility, un plan perfecto.
• Estabilidad del diseño: DietPress reduce los saltos de maquetación con dimensiones automáticas de imagen y carga diferida correcta, que es justo lo que evita el problema de raíz. No existe ningún plugin de la familia que te enseñe tu CLS en una pantalla al instante y gratis; para eso está PageSpeed Insights directamente, que es gratuito y de Google. Si quieres algo más completo, con el CLS real medido vía API de PSI junto a otras 90 y pico comprobaciones técnicas, tengo un servicio de auditoría bajo petición en la herramienta de auditoría SEO, pero ojo, no es una herramienta de autoservicio instantánea como las otras que menciono aquí, es una auditoría que se solicita y que llega en forma de informe completo. En mi web, con DietPress activo, el CLS de laboratorio salió en 0,02, muy por debajo del umbral de necesidad de mejora.
• Árbol de accesibilidad: La comprobación de Lighthouse es un subconjunto pequeño de auditorías de accesibilidad. El analizador de accesibilidad que tengo publicado va bastante más allá, con WCAG 2.1 AA completo, con más de 22 criterios en seis categorías, comprobaciones específicas de WordPress (tema accessibility-ready, constructores visuales) y hasta la parte legal española, la Ley 11/2023 y el RD 1112/2018. Quien pasa esa herramienta aprueba de sobra, y la comprobación de Lighthouse es algo casi de broma.

¿Quieres probar con otros plugins y soluciones, incluso de pago?, tú verás, yo creé estas herramientas porque me empezaba a mosquear tanta repentina herramienta de visibilidad IA premium para cosas que están aún en barbecho. Yo te las ofrezco gratis, pero vale, entiendo que hay gente que no se fía de lo gratis, paga por ahí y luego me cuentas.

¿Tienes que hacer algo ya mismo?

Con todo lo anterior, el plan de choque es breve y gratis:

1. Si aún no tienes Visibility ni VigIA (mal) instala uno de los dos y revisa el modo del llms.txt, prueba a ver si entrega lo correcto, y sino ponlo en manual y elige tú las páginas, no dejes que lo decida un recuento automático de enlaces.
2. Si te preocupa el CLS, comprueba que las imágenes tienen carga diferida y dimensiones declaradas (DietPress lo hace por defecto) y mira el resultado real en PageSpeed Insights, no necesitas nada más para verlo.
3. Pasa tu web por el analizador de accesibilidad y corrige lo que salga en rojo antes que lo amarillo.
4. De WebMCP olvídate por ahora, salvo que tengas una tienda WooCommerce y quieras ir por delante de algo que todavía está en pañales y nadie mira ni usa.

Lo que no haría es perseguir esta pestaña como si fuera el nuevo indicador que decide tu vida en Google, porque no lo es y los propios datos de Search lo confirman. Pero tampoco la ignoraría del todo, porque ya es visible por defecto para cualquiera que abra PageSpeed Insights, y dentro de poco te va a tocar explicársela a algún cliente con cara de susto. Mejor tenerla estudiada antes de que llegue esa pregunta.

¿Tú qué opinas, te parece que Google debería unificar el mensaje entre sus equipos antes de sacar auditorías así, o te da igual mientras tu web quede bien parada? Te leo y tal, me encanta escuchar y aprender, y yo en esto también soy nuevo, como todos, pero lo intento.

Aquí tienes qué hace cada parte, en qué orden conviene configurarlas y dónde está el fallo cuando el cliente no ve las tarifas que le tocan.

La base del tutorial cubre lo que necesita cualquier tienda que envíe dentro de España, y al final hay un bloque de casos especiales por si envías a Canarias o fuera de la Unión Europea.

Antes de nada, decide adónde vas a enviar

Hay un ajuste previo que condiciona todo lo demás y que está en otra pantalla, en «WooCommerce > Ajustes > General». Ahí tienes el desplegable de «Ubicación(es) de envío», con opciones para enviar a todos los países a los que vendes, solo a algunos que elijas, o directamente desactivar los envíos.

Esa última posibilidad es más útil de lo que parece. Si tu negocio es una tienda física que solo hace recogida en el local, o si vendes exclusivamente productos digitales, desactivar los envíos te ahorra montar zonas que no vas a usar y le quita al cliente campos de dirección que no pintan nada.

Y ese otro ajuste del que usted me habla, que es el que más guerra da

En esa misma pantalla, un poco más abajo, tienes «Ubicación del cliente por defecto», y es el que más incidencias raras provoca en los envíos precisamente porque casi nadie lo relaciona con ellos.

El motivo es sencillo. Para saber qué zona de envío le toca a alguien, WooCommerce necesita saber dónde está ese alguien, pero mientras el visitante curiosea productos o acaba de llegar al carrito todavía no ha escrito ninguna dirección. Así que tiene que partir de una suposición, y esa suposición se decide aquí, no en los ajustes de envío.

Las cuatro opciones y lo que provoca cada una:

• Sin ubicación por defecto: no supone nada, con lo que hasta que el cliente no escriba una dirección no hay zona que valga y no se le puede calcular ningún envío.
• País/region de la tienda: da por hecho que está donde estás tú. Es la que menos sorpresas da si vendes sobre todo en España, porque desde el primer momento hay una zona con la que trabajar.
• Geolocalizar: detecta el país por la IP del visitante. Suena estupendo hasta que te acuerdas de que tienes caché de página, porque el servidor puede estar sirviendo la misma página guardada a todo el mundo con la zona que le tocó al primero que pasó por ahí.
• Geolocalizar (compatible con de caché de página): lo mismo pero resolviendo la detección por otra vía para que la caché no se la coma. Si quieres geolocalizar esta es la que tienes que usar, porque caché vas a tener seguro.

Para una tienda española que vende sobre todo aquí, la opción cómoda es País/región de la tienda. Y si vendes a varios países con tarifas muy distintas, geolocalizar compatible con caché, nunca la otra.

El síntoma clásico de tener esto mal puesto es que el cliente vea un coste de envío en el carrito y otro distinto al finalizar la compra. Lo que ha pasado es que la zona que WooCommerce estaba suponiendo no era la que le correspondía de verdad, y al escribir su dirección se recalculó todo.

Hay un detalle más que explica otra confusión habitual, y es que si tienes métodos de envío metidos en la zona de resto del mundo (la de más abajo, que te cuento en un momento), el cliente verá esos métodos nada más llegar en vez del aviso de que introduzca su dirección. No está roto, es que ha encajado en esa zona por descarte.

Este mismo ajuste condiciona también cómo se calculan los impuestos, y ahí tiene su propia ración de rarezas que te cuento en la guía de impuestos en WooCommerce.

Zonas, regiones y métodos, las tres piezas del puzle

Toda la configuración de envíos de WooCommerce se apoya en tres conceptos que encajan uno dentro de otro, y entenderlos bien de entrada te ahorra la mitad de los problemas.

Una zona de envío es un área geográfica. Esa área se define con una o varias regiones, que pueden ser un continente, un país, una provincia o una lista de códigos postales, y dentro de cada zona metes los métodos de envío, que son las opciones que el cliente verá y con las que se le cobrará.

La regla que hay que tener clara desde el principio, porque explica muchos comportamientos raros, es que cada cliente encaja en una sola zona, la primera que coincida mirando la lista de arriba abajo. WooCommerce no acumula zonas ni las suma, encuentra la primera que le vale y deja de buscar.

Las zonas se crean en «WooCommerce > Ajustes > Envío», con el botón de añadir zona de envío. Le pones nombre, eliges las regiones y ya puedes empezar a meterle métodos.

Sobre los códigos postales, que dan bastante juego cuando quieres afinar, puedes poner varios separados por punto y coma, usar comodines con un asterisco al final (28* coge todos los que empiecen por 28) o definir rangos numéricos con tres puntos (28000...28999).

Lo que no funciona es mezclar las dos técnicas, así que un comodín dentro de un rango numérico no te va a servir de nada y tienes que elegir una de las dos.

La zona «Resto del mundo»

Al final de la lista siempre hay una zona especial que WooCommerce crea por su cuenta y que recoge a todos los clientes que no encajan en ninguna de las tuyas.

Esta zona tiene sus particularidades, y es que no la puedes mover de sitio, ni renombrar, ni eliminar. Ahí se queda, siempre la última, haciendo de red de seguridad.

Meterle métodos es opcional. Si le pones alguno, cualquier cliente del mundo podrá comprarte con esas condiciones, y si la dejas vacía, esos clientes verán un mensaje diciendo que no hay envío disponible para su dirección, que es una forma perfectamente válida de decir que ahí no llegas.

El orden de las zonas es importante, y seguro que esto te ha pasado

Como cada cliente se queda con la primera zona que coincide, el orden en el que las tengas colocadas decide qué tarifas ve cada uno. La regla es sencilla de enunciar, de la más específica a la más general, aunque cuesta acordarse cuando llevas seis zonas montadas.

El ejemplo que mejor lo ilustra es el clásico de las islas. Imagina que tienes una zona llamada España con todo el país y unas tarifas normales, y luego creas otra para Baleares con un recargo, porque allí el transporte te sale más caro. Si la zona de España queda por encima de la de Baleares en la lista ningún cliente balear va a ver nunca las tarifas de su zona, porque encaja antes en la de España y WooCommerce ya no sigue mirando.

La colocación correcta sería primero Baleares, después España y al final la de resto del mundo. Se reordena arrastrando y soltando con el icono de las rayitas que aparece a la izquierda de cada zona. De todos modos, el mismo WooCommerce te avisa si pasa esto, animándote a cambiar el orden si hay coincidencias, algo muy común también.

Este es, con diferencia, el fallo de configuración de envíos que más veces me he encontrado, y lo peor es que no da ningún error, simplemente el cliente ve un precio que no le tocaba.

Los métodos de envío por defecto

WooCommerce viene con tres métodos y ninguno más. Si en el desplegable te aparecen otros es porque tienes alguna extensión instalada que los añade.

• Precio fijo: cobras un importe que tú defines, con la posibilidad de complicarlo bastante mediante fórmulas y clases de envío.
• Envío gratuito: no cobras nada, con la opción de exigir condiciones para que aparezca.
• Recogida local: el cliente pasa a recoger, y tiene dos versiones distintas que veremos más abajo porque se prestan a bastante confusión.

Dentro de una zona puedes tener varios métodos activos a la vez y el cliente elige. Cada uno se puede activar o desactivar con un interruptor sin necesidad de borrarlo, lo que viene muy bien para probar cosas o para tarifas de temporada.

El orden de los métodos dentro de una zona también cuenta

Igual que pasa con las zonas, los métodos dentro de cada zona se pueden reordenar arrastrando, y no es solo estética. El primer método activo de la lista es el que aparece ya marcado por defecto cuando el cliente llega a la pantalla de pago.

Eso tiene su punto comercial. Si tienes envío gratuito a partir de cierto importe y también un precio fijo, colocar arriba el que te interesa que vea primero cambia lo que el cliente percibe, porque mucha gente no toca la opción que viene preseleccionada.

Crear un método de envío paso a paso (aquí también hay trampa)

Añadir un método a una zona es un asistente de dos pasos, y conviene no ir con el piloto automático porque en el segundo es donde se decide lo que vas a cobrar.

1. Entras en la zona, creándola nueva o pinchando en una que ya tengas.
2. Pulsas en el botón de añadir método de envío.
3. En el paso 1 eliges qué tipo de método quieres, entre precio fijo, envío gratuito y recogida local.
4. Pulsas en seguir y pasas al paso 2, que es donde se configura de verdad. Si te has equivocado de tipo, el botón de volver te devuelve al paso anterior sin perder nada.

En ese paso 2 te vas a encontrar estos campos:

• Nombre: viene relleno con el nombre genérico del tipo de método y es lo que verá el cliente durante el pago, así que cámbialo por algo que le diga algo, tipo «Envío estándar 48 h» o directamente el nombre de tu transportista.
• Estado del impuesto: si el coste del envío va sujeto a impuestos o no. Lo normal es dejarlo en sujeto, que es como viene.
• Coste: aquí está la miga y viene a 0,00 € de fábrica. Admite un importe fijo o una fórmula de las que te cuento en la sección de precio fijo.
• Costes de la clase de envío: un campo por cada clase que tengas creada, más otro para los productos que no lleven ninguna. Si aquí no ves ningún campo es que todavía no has creado clases, y ese es justo el motivo por el que te decía antes que las clases van primero.

Y la trampa, que sigue ahí aunque ahora te pregunten las cosas de frente. Si te limitas a pulsar el botón de guardar sin tocar el campo de coste, acabas de crear un método de envío gratis, porque el cero viene puesto y no te avisa nadie.

Advertencia: un método guardado con el coste a 0,00 € existe, se muestra en tu tienda y no cobra ni un euro.

Y aunque el asistente te lo ponga ahora más fácil, merece la pena hacer siempre un pedido de prueba después de tocar esto, aunque solo sea llegando hasta la pantalla de pago sin pagar, para ver con tus ojos que el importe que sale es el que querías.

El método de precio fijo de envíos a fondo

Es el método que más juego da y el que vas a usar casi siempre, así que merece explicación detallada.

La configuración básica

Al entrar en un método de precio fijo o tarifa plana, como prefieras llamarlo, te encuentras tres campos, el nombre que verá el cliente en la pantalla de pago, el estado del impuesto para decidir si ese coste lleva impuesto o va exento, y el coste, que es el importe que se cobra por el pedido entero.

Dejar el coste a 0,00 € es perfectamente válido y no es ninguna chapuza. Es justo lo que se hace cuando vas a cobrar solo en función de las clases de envío, que es lo que viene ahora.

Los costes por clase de envío

En cuanto tengas creada al menos una clase de envío, al entrar en un método de precio fijo te aparecen campos nuevos que antes no estaban, uno por cada clase que tengas más otro para los productos que no tengan ninguna asignada.

Y con ellos aparece un desplegable con dos formas de calcular cuando el carrito lleva productos de varias clases mezcladas, que dan resultados bien distintos:

• Por clase: se suma el coste de cada clase presente en el carrito. Con un coste base de 0 €, una clase pesada a 10 € y otra pequeña a 1 €, un pedido que lleve las dos paga 11 €.
• Por pedido: se cobra solo la clase más cara de las que haya. En ese mismo pedido, se cobran 10 € y se ignora la de 1 €.

La elección depende de cómo embales. Si cada tipo de producto va en su propio bulto, tiene sentido sumar. Si lo metes todo junto en una caja, cobrar solo el más caro se ajusta mejor a lo que te cuesta de verdad.

Fórmulas para cobrar por cantidad o por porcentaje

El campo de coste no admite solo un número fijo, también acepta fórmulas sencillas con dos comodines:

• [qty] es el número de artículos que lleva el carrito. Así que una fórmula como 10 + (2 * [qty]) cobra 10 € fijos más 2 € por cada artículo, lo que se traduce en 12 € con un artículo, 14 € con dos y 16 € con tres.
• [fee percent="10"] añade un porcentaje del importe que se va a enviar. Con 10 + [fee percent="10"], un pedido de 20 € paga 12 € de envío y uno de 30 € paga 13 €.

Ese comodín de porcentaje admite además dos parámetros opcionales para ponerle suelo y techo, min_fee y max_fee. Con 10 + [fee percent="10" min_fee="4"] te aseguras de que la parte porcentual nunca baja de 4 €, por muy pequeño que sea el pedido.

Con esto se cubre bastante terreno, pero conviene saber dónde está el límite. No hay ningún comodín para el peso, así que por aquí no vas a poder calcular envíos por kilos, y lo cuento más abajo porque es una de las preguntas más repetidas.

Un caso completo, envío gratis para unos productos y de pago para otros

Este montaje resuelve de golpe un montón de dudas y merece verlo entero. La idea es que en tu catálogo hay cosas que quieres enviar gratis y otras que no.

1. Creas tres clases de envío, por ejemplo Envío gratis, envío normal y envío urgente.
2. Asignas cada producto a la clase que le toque.
3. En el método de precio fijo pones el coste base a 0,00 €.
4. Dejas vacío el coste de la clase Envío gratis, y pones 3 € en la normal y 7 € en la urgente.
5. Eliges el cálculo por clase para que se sumen de forma independiente.

El resultado es que un pedido que solo lleve productos de la clase gratis no paga nada, uno que mezcle gratis y normal paga 3 €, y uno que lleve de todo paga 10 €. Todo con el método nativo y sin tocar una línea de código.

Envío gratuito a fondo

Parece el método más tonto de los tres y resulta que es el que más matices tiene.

Las cinco condiciones posibles

Al entrar en el método te encuentras un desplegable con cinco posibilidades, y la diferencia entre las dos últimas se le escapa a casi todo el mundo:

• Ninguno: envío gratis para todo el mundo que esté en esa zona, sin condiciones.
• Un cupón válido de envío gratuito: solo aparece si el cliente ha metido un cupón que lo permita.
• Una cantidad mínima de pedido: aparece a partir del importe que tú digas.
• Una cantidad mínima de pedido O un cupón: vale con cumplir cualquiera de las dos.
• Una cantidad mínima de pedido Y un cupón: hacen falta las dos cosas a la vez.

El detalle del importe mínimo cuando hay descuentos de por medio

Si eliges alguna opción con importe mínimo te aparece debajo una casilla que dice algo así como aplicar la regla del importe mínimo antes de los descuentos de cupón, y esa casilla decide bastante dinero.

Con un pedido de 30 € y un cupón de descuento de 10 €:

• Casilla sin marcar: WooCommerce mira el importe después de aplicar el cupón, o sea 20 €. Si tu mínimo para envío gratis eran 25 €, este cliente paga el envío.
• Casilla marcada: mira el importe antes del descuento, o sea 30 €. Ese mismo cliente tiene el envío gratis.

Aquí es donde un cupón agresivo te puede tumbar sin querer todo el sistema de envío gratis, o al revés, donde te puedes encontrar regalando envíos en pedidos que después del descuento se han quedado en nada. Decídelo a propósito y no por descarte.

Los cupones que permiten envío gratuito

Para que un cupón sirva como llave del envío gratis no basta con que exista, tiene que estar marcado para ello. Se hace en «WooCommerce > Marketing > Cupones», en la pestaña de restricciones de uso del cupón, marcando la casilla de permitir envío gratuito.

Anúncialo pronto o no sirve de nada

Los gastos de envío que aparecen tarde, ya con el cliente en la pantalla de pago, son de los motivos más habituales de carritos abandonados en cualquier estudio que mires. Si has montado un mínimo para envío gratis y el cliente se entera al final del proceso, te has perdido casi todo el efecto.

Merece la pena que la condición se vea antes, con un aviso en la ficha de producto, una barra de progreso en el carrito o simplemente una línea en la cabecera de la tienda. Eso ya no es configuración de envíos, pero sin ello lo que acabas de configurar rinde la mitad.

Las clases de envío (con ejemplos)

Las clases de envío son el concepto que más cuesta pillar de toda la configuración, y sobre todo porque la mayoría de la gente espera que hagan algo que no hacen.

Qué son y qué no son las clases de envío

Una clase de envío es una etiqueta, y nada más. Sirve para agrupar productos que comparten alguna característica de transporte, y punto.

Una clase de envío por sí sola no cobra ni un céntimo, porque el coste de una no se configura en la clase de envío sino en el método de envío de cada zona.

Se crean en «WooCommerce > Ajustes > Envío > Clases de envío» y tienen tres campos, el nombre, el slug (que si lo dejas vacío se genera solo) y una descripción que solo ves tú en el escritorio.

¿Qué tiene que pasar para que una clase de envío sirva para cambiar un precio?

Para que una clase acabe cobrando algo tienen que darse cuatro pasos encadenados, y si falta uno no pasa nada de nada:

1. Creas la clase.
2. Se la asignas a los productos que correspondan, desde la pestaña de envío de los datos de cada producto.
3. Entras en el método de precio fijo de cada zona y le pones el coste a esa clase.
4. El cliente llega al carrito y ve el resultado calculado según el tipo de cálculo que elegiste.

El paso tres es el que se suele olvidar, y entonces llega la pregunta de por qué he creado las clases y no se cobra nada, porque a las clases hay que darles un precio zona a zona, y eso hay que hacerlo a mano en cada una, un peñazo tremendo.

Consejo importante: crea antes las clases de envío que los métodos de envío

Este es un consejo que te ahorra paseos de ida y vuelta, que me agradecerás eternamente: crea siempre primero las clases de envío, y solo después ponte con los métodos de precio fijo, porque si lo haces al revés te va a tocar modificar tooodos los métodos de precio fijo.

El orden perfecto sería crear las clases, asignarlas a los productos y entonces ir a cada zona a ponerles precio, con los campos ya visibles, justo como te he especificado antes en los 4 pasos.

Cómo se asignan a los productos

En un producto simple la clase se elige en la pestaña de envío de los datos del producto, y solo puede tener una.

En un producto variable la cosa se pone interesante, porque el producto padre tiene su clase y además cada variación puede llevar una clase distinta. Eso te permite, por ejemplo, que la talla pequeña de algo vaya en una clase barata y la grande en otra más cara, o que una variación en formato digital no lleve clase ninguna.

Si tienes que cambiar la clase de muchos productos a la vez, en el listado de productos puedes seleccionarlos, elegir la edición en lote y cambiarles la clase de envío de golpe.

Cuatro ejemplos prácticos del potencial de las clases de envío

Aquí van cuatro situaciones bien distintas para que veas el alcance real que tienen.

• Por tamaño: Clases pequeño, mediano y voluminoso, con costes crecientes. Es el caso típico de una tienda de muebles o electrodomésticos, donde lo que encarece el porte no es el peso sino el volumen que ocupa en el camión.
• Por fragilidad: Una clase Frágil con un recargo fijo que cubre el embalaje reforzado, para cristalería, cerámica o cualquier cosa que te vayan a devolver rota si la mandas en una caja normal. Conviene usarla con el cálculo por clase, para que ese recargo se sume al coste que ya tuviera el pedido.
• Por tramos de peso: Clases del tipo Hasta 1 kg, De 1 a 5 kg y Más de 5 kg, cada una con el precio que te cobra tu transportista en ese tramo. Es la manera nativa de acercarse al envío por peso, y tiene sus limitaciones, que te cuento en el punto siguiente.
• Para separar el catálogo gratis del de pago: Una clase con coste vacío conviviendo con otras que sí lo tienen, que es exactamente el montaje completo que te he detallado antes en la sección de precio fijo.

Básicamente cualquier peculiaridad de un producto que encarezca su envío.

El envío por peso y las falsas expectativas

Esta es probablemente la pregunta más repetida sobre envíos en WooCommerce y la respuesta es sencilla: no, WooCommerce no calcula el coste de envío según el peso del pedido, y no hay ningún ajuste escondido que lo haga.

El campo de peso de los productos existe, pero no para calcular nada, se usa para pasarle el dato a otras cosas, no para que el núcleo calcule tarifas. Las fórmulas del precio fijo solo entienden de cantidad de artículos y de porcentaje del importe, como has visto arriba.

Lo que sí puedes hacer de forma nativa es una aproximación a lo que buscas usando clases por tramos de peso, como en el tercer ejemplo de la sección anterior.

Pero este apaño tiene dos pegas que conviene conocer antes de montarlo, y es que, para empezar, tienes que asignar a mano cada producto a su tramo, y luego está el hecho de que el tramo se aplica por producto y no por el peso total sumado del carrito, así que un pedido con cinco artículos de menos de un kilo se seguirá cobrando como si cada uno fuera de su tramo, no como un bulto de cinco kilos.

Para un cálculo real sobre el peso total del pedido hay que salirse de lo nativo, usando plugins, y eso no toca en esta guía.

El destino del envío y qué cambia en la pantalla de pago

En «WooCommerce > Ajustes > Envío > Ajustes de envíos» hay un ajuste llamado destino del envío que decide qué campos de dirección ve el cliente, y las tres opciones dan experiencias bastante distintas.

• Por defecto a la dirección de envío del cliente: la pantalla de pago muestra la dirección de facturación y deja disponible la casilla para enviar a una dirección distinta, que el cliente marca si la necesita.
• Por defecto a la dirección de facturación del cliente: se usa la de facturación como dirección de envío, y el cliente puede cambiarla si quiere, pero de entrada no se le piden dos direcciones.
• Forzar el envío a la dirección de facturación del cliente: desaparece del todo la sección de dirección de envío, y el cliente no puede pedir que se le mande a otro sitio ni queriendo.

Para una tienda normal las dos primeras son las razonables, porque en cuanto alguien quiera hacer un regalo o mandar algo a su oficina va a necesitar poner otra dirección.

Mi recomendación es que uses la dirección de facturación del cliente siempre, porque das todas las opciones pero al no mostrarse inicialmente abierto el campo de otra dirección no parece que obligas a rellenar lo mismo dos veces, quedando la dirección de envío como una dirección de envío distinta a la de facturación, que es en realidad para lo que es.

La tercera opción solo tiene sentido en negocios muy concretos, y a cambio de simplificar el formulario te limita posibles ventas.

La calculadora del carrito y por qué a veces no la puedes activar

En esa misma pantalla de opciones hay una casilla para activar la calculadora de gastos de envío en la página del carrito, que es ese formulario donde el cliente mete su país y su código postal para ver cuánto le va a costar el porte antes de meterse en el proceso de pago.

Si te encuentras esa casilla en gris, sin poder marcarla es porque la tienda está usando el bloque de carrito en vez del carrito clásico, y en ese caso WooCommerce inactiva la opción y te avisa de que la función no está disponible con los bloques y de que el envío se calculará en la pantalla de pago. No es un fallo ni un plugin que interfiera, es el comportamiento previsto, y el propio WooCommerce te lo indica con un texto pequeñito justo debajo de la casilla.

Sobre si merece la pena activarla cuando sí puedes, la respuesta depende de tu catálogo. Si tus tarifas varían mucho según el destino, dejar que el cliente lo compruebe en el carrito le evita la sorpresa al final y a ti te evita abandonos. Si cobras lo mismo a todo el mundo la calculadora aporta poco y encima añade un formulario más a una página que interesa tener limpia.

Justo debajo tienes otra casilla emparentada con esta, la de ocultar los gastos de envío hasta que se introduzca una dirección. Sirve para no enseñar una estimación que después va a cambiar, y va bien en tiendas con tarifas muy dispares por destino.

Recogida(s) local(es) ¿hay más de un método en WooCommerce?

La recogida local tiene dos implementaciones distintas conviviendo en Woocommerce, que funcionan de manera diferente y ni siquiera están en el mismo sitio del escritorio de tu WordPress, así que merece la pena ver las dos antes de decidirte por una de las dos.

La versión de siempre, dentro de la zona

Es un método más, que se añade dentro de una zona igual que el precio fijo. Como vive dentro de una zona, puedes restringir a qué clientes se les ofrece, que es justo lo que quieres si solo tiene sentido que pasen a recoger los de tu ciudad.

Su particularidad fiscal es que los impuestos de ese pedido se calculan según la dirección de tu tienda, no según dónde viva el cliente, cosa que tiene toda la lógica porque la entrega se produce en tu local.

La versión nueva, en su propia pestaña de los ajustes de envío

La otra vive en una pestaña propia llamada, para ayudar y tal, pues eso Recogida local, dentro de los ajustes de envío, y no está dentro de ninguna zona. Lo que trae de bueno es que admite varios puntos de recogida, cada uno con su nombre, su dirección completa y sus notas de acceso, algo imposible con la versión clásica.

Y ahora la parte que explica por qué mucha gente ni sabe que esto existe. Si en tus ajustes de envío solo ves las pestañas de zonas de envío, ajustes de envíos y clases de envío, es que en tu tienda esta versión no está disponible, y no es que te falte ningún plugin ni que tengas WooCommerce viejo.

El motivo es que esta pestaña solo aparece si tu página de Finalizar compra usa el bloque de Pago. Si esa página sigue con el shortcode de toda la vida, la pestaña sencillamente no existe. Para salir de dudas edita tu página de finalizar compra y mira qué lleva dentro, si el [woocommerce_checkout] de siempre o el bloque.

Si quieres tenerla, la secuencia es esta:

1. Editas la página de Finalizar compra y sustituyes el shortcode por el bloque de Pago.
2. Vuelves a «WooCommerce > Ajustes > Envío» y ahí ya te aparece la pestaña de Recogida local.
3. Marcas la casilla para activar la recogida local.
4. Das de alta al menos una ubicación de recogida, porque sin ninguna la opción no se le muestra al cliente por mucho que la tengas activada.

Y eso no es una decisión menor, porque cambiar al pago por bloques puede romperte plugins que estuvieran enganchados al pago clásico. Piénsatelo antes, no lo actives solo por probar la recogida local.

Hay además un efecto secundario que conviene conocer antes de activarla, y enlaza con el ajuste de ubicación del cliente por defecto del principio del artículo. Cuando el pago por bloques no tiene ninguna dirección con la que trabajar, cosa que pasa si dejaste la ubicación por defecto sin poner, si la geolocalización no acierta con el país o si todas tus zonas van filtradas por código postal, el selector de envío o recogida le aparece al cliente ya marcado en recogida.

La lógica de WooCommerce es que siempre tiene que haber un método seleccionado, y como la recogida es el único que no necesita dirección, gana por descarte. El resultado es que alguien que iba a pedir un envío a casa se encuentra la recogida puesta, y o se da cuenta a tiempo o te acaba haciendo un pedido para recoger sin quererlo.

No existe ningún ajuste para forzar que salga marcado el envío, así que la única forma de evitarlo a día de hoy es la que ya te recomendaba arriba, dejar la ubicación del cliente por defecto en País/región de la tienda para que siempre haya una zona con la que trabajar.

Diferencias entre recogida local clásica y «nueva»

Un aviso para terminar con esto. Si activas las dos versiones a la vez, WooCommerce te lo advierte en pantalla, y con razón, porque el cliente se encuentra dos opciones de recogida que parecen lo mismo y no lo son. Elige una y desactiva la otra.

Transportistas habituales en España

Esto no es configuración, es contexto para que sepas cómo llamar a tus métodos y qué esperar de cada uno. Las opciones de mensajería que se usan habitualmente aquí son Correos, SEUR, MRW, GLS y Correos Express, cada una con sus plazos y sus zonas donde va mejor o peor.

Con los métodos nativos lo que vas a hacer es crear precios fijos con el nombre del transportista y el precio que hayas acordado con él, y luego generar las etiquetas por tu cuenta en la web de la agencia.

Conectar tarifas en tiempo real o generar etiquetas desde el propio WooCommerce ya requiere salir de lo nativo.

Repaso rápido para no dejarte nada

El orden en el que conviene montar todo esto:

1. Decidir en los ajustes generales adónde vas a enviar y qué ubicación del cliente por defecto usas.
2. Crear las clases de envío que vayas a necesitar, antes de tocar ninguna tarifa.
3. Asignar las clases a los productos y a las variaciones.
4. Crear las zonas, de la más específica a la más general.
5. Comprobar el orden de las zonas y arrastrarlas si hace falta.
6. Añadir los métodos a cada zona, completando el paso 2 del asistente sin dejarte el coste a cero.
7. Ordenar los métodos dentro de cada zona según cuál quieres que salga preseleccionado.
8. Ajustar el destino de envío y la calculadora en las opciones de envío.
9. Decidir qué versión de recogida local usas, si es que usas alguna.
10. Hacer un pedido de prueba desde cada zona que hayas creado.

Y los fallos que más se repiten:

• Poner una zona genérica por encima de otra específica, de modo que la específica no la ve nadie.
• Dejar la ubicación del cliente por defecto sin poner, y no entender por qué el envío cambia de precio entre el carrito y la pantalla de pago.
• Guardar un método sin tocar el campo de coste, que viene a 0,00 €, y quedarte regalando los envíos sin enterarte.
• Crear las clases de envío después de haber montado los métodos, y no encontrarte los campos de coste por clase al crearlos.
• Esperar que el precio fijo calcule por peso real sin haber montado los tramos con clases.
• Tener activadas las dos versiones de recogida local a la vez sin haberse dado cuenta.
• Recibir pedidos para recoger de gente que quería envío a casa, por tener la recogida por bloques puesta sin una ubicación por defecto que la contrarreste.
• Volverse loco con la calculadora del carrito en gris sin saber que es por el bloque de Carrito.

Para ir más allá, los casos especiales

Envías a Canarias, Ceuta o Melilla

A efectos de envío puedes montarlo como una zona más, con los códigos de provincia correspondientes, y ponerle las tarifas que te cobre el transportista, que suelen ser bastante más altas y con plazos más largos.

Lo que no puedes es tratarlo como una venta nacional cualquiera, porque fiscalmente es una exportación exenta y los impuestos de destino los liquida el cliente al recibir el paquete. Eso te lo cuento con detalle en la guía de impuestos en WooCommerce, y conviene que lo tengas claro antes de abrir la venta a estos destinos.

Si prefieres no meterte en ese jardín, la alternativa es excluir esas provincias de tus zonas de envío y decirlo con claridad en las condiciones de la tienda, que es una decisión perfectamente legítima y mucha gente la toma.

Envías fuera de la Unión Europea

Aquí entran en juego los aranceles y los trámites de aduana, que no existen dentro de la Unión Europea, y lo que tienes que decidir antes de vender es quién paga esos costes, si el comprador al recibir el paquete o tú por adelantado.

Sea cual sea tu decisión, déjala escrita en las condiciones de venta antes de abrir el mercado, porque el disgusto de un cliente al que le reclaman en la puerta de casa un importe que no esperaba se convierte en una devolución y en una reseña mala.

La parte fiscal de las ventas fuera de España, incluida la ventanilla única para la Unión Europea, la tienes en la guía de impuestos que te enlazaba arriba.

Yo llevo más de veinte años con esa pregunta cada vez que tengo un código delante, y la respuesta es que «depende», lo sé, no te saca de dudas, pero es que acertar o no tiene consecuencias, como personalizaciones que desaparecen de un día para otro, plugins que nadie sabe mantener, código de terceros con más permisos de los que deberías darle.

Dicho esto, vamos al grano, uno por uno. Ya toqué el debate clásico entre plugin o functions.php, y también dejé unas primeras pinceladas de las cuatro vías en cómo y dónde pegar código PHP, JS y CSS. Aquí quiero ir más allá y revisar las cuatro opciones juntas, con los riesgos y ventajas cada una.

El archivo functions.php del tema

Es el sitio de toda la vida. Cada tema, o tema hijo, trae su propio functions.php, y lo que metas ahí se ejecuta mientras ese tema esté activo, sin instalar nada nuevo ni añadir peso extra a la web.

Te conviene cuando el código está relacionado de verdad con el diseño, como un filtro que cambia el extracto, un ajuste de los tamaños de imagen, algo que solo tiene sentido mientras uses ese tema en concreto.

Su principal problema es que si cambias de tema, o actualizas el que tienes sin que sea un tema hijo, pierdes todo sin previo aviso, nadie te va a avisar de que acabas de borrar tres años de personalizaciones. Es la pega de siempre y sigue siendo la más gorda, ya la conté con más detalle en cómo sería el functions.php perfecto.

Un plugin personalizado de funciones

No te vengas arriba, no hablo de encargarle a la IA el próximo Jetpack, me refiero a un plugin mínimo, casi sin interfaz, solo para meter tus funciones. Sobrevive a cualquier cambio de tema porque no depende de ninguno.

Te conviene para todo lo que sea independiente del diseño, como cambios en WooCommerce, ajustes del propio WordPress, integraciones con otros plugins. Si tiene que sobrevivir a un cambio de tema, va en un plugin, no en el functions.php.

Y ojo, el hecho de que sea «tu» plugin no significa que puedas montarlo con cuatro líneas sueltas y sin cabecera, ni calvo ni tres pelucas. Sin control de versiones ni backups, acaba siendo tan frágil como el functions.php, pero con un paso más de complicación.

Esto no contradice lo que siempre digo, que el problema nunca es la cantidad de plugins sino sobrecargar tu web con código que no necesitas, y un plugin de funciones bien hecho no pesa más que el código suelto, simplemente es algo mejor organizado.

Y si te da un poco de respeto crear tu primer plugin, no te preocupes, no hace falta ser programador para hacerlo bien (yo tampoco lo soy, aunque programe cosas). Tienes la forma manual en crea un plugin para liberar el fichero functions.php, y la forma fácil, sin tocar FTP, en crea tu plugin de funciones desde el escritorio de WordPress.

El mu-plugin imprescindible y a prueba de curiosos

Los mu-plugins viven en su propia carpeta, wp-content/mu-plugins, y WordPress los carga siempre. No aparecen en el listado normal de plugins, así que nadie los puede desactivar con un clic, ni siquiera sin querer.

El mu-plugin es como el cableado eléctrico de una casa, no lo ves ni sale en el catálogo de muebles, pero como falle no hay lámpara que valga. Resérvalo para lo verdaderamente crítico, lo que tiene que ejecutarse sí o sí, y de regalo va con prioridad a los demás.

Hace poco tuve un caso así con un cliente. Unas 7.000 suscripciones heredadas de WooCommerce estaban cobrando mal el impuesto en cada renovación, y la solución no podía depender de que alguien, sin querer, desactivara un plugin cualquiera un día cualquiera.

Pues monté un mu-plugin que intercepta cada renovación y recalcula el precio, sin excusas y sin margen para el despiste. Lo comenté también al hilo del minimizado en cómo minimizar HTML, CSS y JavaScript sin plugins, y la regla es que cuando la funcionalidad es esencial y ajena al tema, el mu-plugin es la opción más sólida que tienes.

Ahora bien, precisamente esa invisibilidad, si trabajas con más gente en la web, o simplemente se te olvida a ti mismo con el tiempo, un mu-plugin se convierte en una caja negra que nadie recuerda que existe. Resérvalo para pocas cosas, y documenta bien qué hace y por qué.

Los plugins de snippets esos que deberían estar prohibidos

Supongo que los conoces, me refiero a plugins que te dan una interfaz para pegar código PHP, CSS o JS sin tocar ningún archivo físico, con un interruptor para activarlo o desactivarlo cuando quieras.

Son prácticos si no te manejas con FTP, si no tienes acceso al editor de archivos, o si quieres poder desactivar algo puntual sin liarte. También van bien para pruebas rápidas, antes de decidir si ese código merece pasar a un plugin propio.

Pero no soy nada fan, porque le estás dando a un plugin de terceros permiso para ejecutar cualquier cosa en tu web. Si ese plugin sufre una vulnerabilidad, todo lo que hayas metido ahí queda expuesto de golpe, no solo el propio plugin de snippets.

Ya comparé las opciones en plugins de fragmentos de código, ¿cuál es el mejor?, por si necesitas decidir entre WPCode y Code Snippets, por ejemplo, porque aquí no es la cuestión.

Comparativa rápida de las 4 opciones

Por si andas cansino y no te apetece leer (y mira que las explicaciones buenas buenas están arriba, en serio, deberías leerlas, vale ya lo dejo) aquí tienes un resumen:

Cuando ves las cuatro opciones juntas en la misma tabla, la decisión deja de parecer tan complicada ¿a que sí?.

Mi recomendación

Si me preguntas, con las webs que llevo yo y con lo que me consultan a diario en mantenimiento la regla que uso es esta:

• ¿Depende del tema?: Al functions.php del tema activo. Cero dudas.
• ¿Es crítico y no puede fallar nunca?: MU-plugin y apunto en el calendario o lista de tareas que está ahí.
• ¿Todo lo demás? Plugin propio. No pasa nada por tener siete plugins pequeños cada uno para una cosa, pero a la vista.

No hay una opción mejor en abstracto, hay una opción mejor para cada línea de código que escribes, y la decisión, al final, es tuya.

Los plugins de snippets de código los reservo solo para pruebas rápidas o para quien de verdad no quiere o más bien no puede tocar código a mano, no son una solución viable ni recomendable en un sitio activo real.

Si tienes un caso raro que no encaja en ninguna de las cuatro, cuéntamelo en los comentarios, que seguro que no eres el único con esa duda.

Si has puesto las constantes en tu wp-config.php para frenar las actualizaciones automáticas de WordPress y tu web se actualiza igual, la configuración no está mal aplicada. Hay proveedores de alojamiento en los que el wp-config.php no interviene en esto, porque quien actualiza tu WordPress no es WordPress, es una capa externa que ni llega a leer tu archivo de configuración.

Lo que sigue es el mecanismo por el que ocurre, los tres escenarios posibles según dónde tengas alojada la web, un método poco conocido que documentó el propio equipo de WordPress en 2013, y una prueba que hice el 7 de agosto de 2026 para comprobar hasta dónde llega ese método.

El control de actualizaciones que WordPress tiene por defecto

Desde WordPress 3.7, en octubre de 2013, el núcleo se actualiza solo para versiones de mantenimiento y seguridad. Junto a esa función llegó el juego completo de controles, que sigue siendo el mismo hoy.

Tienes las constantes de wp-config.php, con AUTOMATIC_UPDATER_DISABLED para detenerlo todo y WP_AUTO_UPDATE_CORE para decidir qué tipo de versiones entran. Tienes los filtros auto_update_core, auto_update_plugin y auto_update_theme para afinar por elemento.

Además, desde WordPress 5.5 tienes las casillas de la propia administración para plugins y temas, más la opción de versiones mayores en la pantalla de actualizaciones desde la 5.6.

Todo eso está explicado a fondo en la guía de actualizaciones automáticas en segundo plano y sigue siendo válido punto por punto. El problema no es que esos controles estén mal documentados, es que solo gobiernan a WordPress.

Por qué esos controles pueden quedarse sin efecto

Las constantes y los filtros los consulta el código de WordPress cuando el propio WordPress va a actualizarse. La clase que decide es WP_Automatic_Updater, y todas las comprobaciones que conoces viven dentro de su método should_update().

Cuando la actualización la ejecuta una capa externa, esa clase no llega a instanciarse. El resultado en tu instalación es indistinguible de que alguien hubiera pulsado «Actualizar ahora» en tu escritorio, y ese botón nunca ha consultado las constantes ni tiene por qué hacerlo. No es que el proveedor ignore tu configuración a propósito, es que su sistema opera en un plano donde tu configuración no existe.

De ahí se deduce algo que conviene tener claro antes de seguir probando cosas. DISALLOW_FILE_MODS, la constante que bloquea toda modificación de archivos desde WordPress, tampoco sirve para esto, y por el mismo motivo. Solo la comprueban las clases internas de WordPress cuando van a modificar algo, así que si los archivos los reemplaza un proceso externo esa constante ni se evalúa.

Tres posibles escenarios según tu proveedor

Aquí es donde conviene dejar de generalizar, porque el comportamiento varía bastante y no todos los alojamientos gestionados hacen lo mismo.

Plataformas con sistema propio de actualización del núcleo

Son las que mantienen su propia infraestructura de actualización, con calendario, copias previas y notificaciones al margen de WordPress. WP Engine documenta que no actualizan durante la fase beta ni inmediatamente después de publicarse una versión, sino que su equipo de seguridad la analiza, ajustan la plataforma y entonces empiezan a actualizar las webs de forma automática, con pruebas de humo antes y después de cada actualización.

Ofrecen aplazamiento, pero solo para versiones mayores, no para las de seguridad.

En el mismo aviso añaden que antes de cada actualización automática realizan una copia de seguridad completa restaurable, un detalle con consecuencias prácticas sobre las que volveré.

Alojamientos con instalador automático de aplicaciones

Es el escenario más extendido en hosting compartido y el que menos gente tiene presente. Los autoinstaladores que vienen integrados en cPanel, Plesk o DirectAdmin no se limitan a instalar WordPress, guardan una ficha de cada instalación y pueden actualizarla por su cuenta con ajustes propios, completamente independientes de los de WordPress.

Installatron, uno de los más habituales, incluye entre sus funciones la actualización automática de núcleo, plugins y temas. En la ficha de cada instalación tiene una pestaña de actualización automática con tres opciones para el núcleo, actualizar a cualquier versión, limitarse a versiones menores y de seguridad, o desactivarlo por completo, además de una pestaña aparte para la copia de seguridad previa con restauración si la actualización falla.

Y hay un detalle que explica bastantes casos. En su documentación describen un comando que activa la actualización automática de golpe para todas las aplicaciones instaladas en un servidor, con la variante de limitarlo a versiones menores y de seguridad. Un proveedor puede aplicarlo a nivel de servidor sin que tú intervengas, y desde ese momento tus instalaciones se actualizan al margen de lo que diga tu wp-config.php.

Si tu hosting instaló WordPress por ti desde el panel, revisa esos ajustes antes que ninguna otra cosa. Suele haber ahí un desplegable de actualizaciones del núcleo que casi nadie ha abierto nunca.

Proveedores que no gestionan las actualizaciones de WordPress

No todos entran en el reparto. Kinsta declara en su alcance de soporte que no proporcionan actualizaciones del núcleo de WordPress y recomiendan hacer copia antes de actualizar. Su herramienta de actualizaciones automáticas es un complemento de pago centrado en plugins y temas, con pruebas visuales de regresión y reversión automática si detectan cambios.

En este escenario, y también en cualquier VPS o servidor sin capa de gestión, los controles de WordPress mandan sin discusión, porque no hay nadie por encima ejecutando nada.

La detección de control de versiones

Queda un método nativo que apenas aparece en la documentación en español. Lo describió Andrew Nacin en la guía oficial de desactivación de actualizaciones automáticas publicada en make.wordpress.org con la salida de WordPress 3.7, y sigue vigente en el código actual.

WordPress comprueba, antes de actualizarse, si la instalación está bajo control de versiones. Si detecta que sí se detiene y no modifica nada, con la intención de no sobrescribir archivos a quien despliega mediante Git o Subversion.

La comprobación la realiza el método is_vcs_checkout(), que recorre el sistema de archivos hacia arriba hasta la raíz del disco buscando directorios llamados .git, .svn, .hg o .bzr. La comprobación es un simple is_dir(), por lo que no valida que exista un repositorio real. Una carpeta vacía llamada .git, sin ningún archivo dentro, activa la detección igual que un repositorio completo.

Tres precisiones antes de aplicarlo:

• Tiene que ser una carpeta, no un archivo. Un fichero suelto llamado .git no produce ningún efecto, porque is_dir() devuelve falso.
• Va en la raíz de WordPress, al mismo nivel que el wp-config.php, y desde ahí cubre núcleo, plugins, temas y traducciones.
• No necesita ser accesible por HTTP, porque WordPress solo consulta el sistema de archivos. Es un detalle relevante, ya que un .git real y expuesto por web sí constituye una vulnerabilidad grave.

El bloqueo no admite excepciones desde la configuración. Ni siquiera define('WP_AUTO_UPDATE_CORE', true) lo anula, algo que se reportó como fallo en el ticket 52279 de Trac y se cerró como comportamiento previsto. La única vía oficial para desactivarlo es el filtro automatic_updates_is_vcs_checkout devolviendo falso.

Comprobación previa en tu instalación

Antes de dar nada por hecho conviene verificar que WordPress está detectando la carpeta. Sin recurrir a WP-CLI se puede hacer con un script PHP que subes por FTP o por el gestor de archivos, visitas una vez conectado como administrador y borras inmediatamente después.

<?php
/**
 * Comprobación temporal de detección de control de versiones.
 * Subir a la raíz de WordPress, visitarlo una vez y BORRARLO.
 */
require_once __DIR__ . '/wp-load.php';

if ( ! current_user_can( 'manage_options' ) ) {
	wp_die( 'Solo administradores.' );
}

echo '<pre>';

echo "1. ¿La carpeta .git existe y es un directorio real?\n";
var_dump( is_dir( ABSPATH . '.git' ) );

echo "\n2. ¿Hay algo forzando el filtro a ignorar la detección?\n";
var_dump( apply_filters( 'automatic_updates_is_vcs_checkout', true, ABSPATH ) );

echo "\n3. ¿Qué devuelve WordPress al comprobarlo de verdad?\n";
if ( ! class_exists( 'WP_Automatic_Updater' ) ) {
	require_once ABSPATH . 'wp-admin/includes/class-wp-automatic-updater.php';
}
var_dump( ( new WP_Automatic_Updater() )->is_vcs_checkout( ABSPATH ) );

echo '</pre>';

Si las tres comprobaciones devuelven true, el actualizador nativo de WordPress tiene prohibido modificar la instalación. La segunda es la más informativa, porque al filtro se le pasa true de forma deliberada, así que un false indicaría que algún plugin o el propio hosting tiene un gancho ahí anulando la detección.

Hasta dónde llega el método, con una prueba real

Leer el código dice lo que hace WordPress. No dice lo que hará la capa de tu proveedor, así que monté una prueba para averiguarlo en un caso concreto.

Instalación de pruebas en SiteGround, en aulawp.com/seguridad, con su sistema de actualizaciones automáticas en la configuración por defecto. Creé una carpeta .git vacía en la raíz y ejecuté el script anterior. Las tres comprobaciones devolvieron true, de modo que WordPress detectaba el control de versiones, nadie interceptaba el filtro y el actualizador nativo quedaba bloqueado.

El 6 de agosto de 2026 se publicó WordPress 7.0.3, una versión de seguridad que corregía, entre otros fallos, un XSS reflejado sin autenticación en la pantalla de acceso con potencial de derivar en ejecución de código PHP.

Hay un detalle que condiciona la interpretación, pues en la 7.0.2 de julio el equipo de WordPress.org activó actualizaciones forzadas por la gravedad del fallo y lo indicó expresamente en el anuncio. En la 7.0.3 no lo hicieron, y el anuncio recurre a la fórmula habitual de que los sitios con actualizaciones en segundo plano comenzarán a actualizarse en breve. Eso descarta que el propio WordPress sorteara el bloqueo por la vía del forzado, que era el único cabo suelto de la prueba.

El 7 de agosto a las 21:36, veinticuatro horas después de la publicación, SiteGround realizó su copia de seguridad completa y actualizó el sitio a la 7.0.3. Veinticuatro horas es exactamente el intervalo que tenía configurado para lanzamientos menores, así que su sistema actuó según su calendario previsto.

Volví a ejecutar el script a las 23:34, casi dos horas después. Las tres comprobaciones seguían devolviendo true, la carpeta continuaba en su sitio y WordPress seguía determinando que no debía actualizarse. La capa externa actualizó igualmente.

La conclusión que saco de esto tiene dos partes. El método descrito por Nacin sigue funcionando contra el actualizador nativo trece años después, y no tiene ningún efecto sobre un sistema de plataforma. Lo he verificado en SiteGround y no puedo extenderlo a otros proveedores sin probarlos, aunque el mecanismo hace previsible el mismo resultado allí donde exista una capa similar.

Averiguar en qué escenario estás

Tres comprobaciones que puedes hacer en unos minutos:

• Busca en el panel de tu hosting una sección de WordPress con ajustes de actualizaciones, y si no la hay, busca el autoinstalador y localiza la ficha de tu instalación.
• Ejecuta el script de comprobación para saber si el actualizador nativo está operativo o bloqueado.
• Revisa tu correo. Las actualizaciones nativas de WordPress llegan desde la dirección de tu propio sitio, mientras que las de plataforma suelen avisar desde el dominio del proveedor. El remitente te dice quién actualizó.

Si el panel tiene ajustes de actualización del núcleo, ese es el sitio donde decides. En SiteGround están en Site Tools > WordPress > Actualizaciones automáticas de WordPress, con retrasos independientes para lanzamientos mayores y menores y un interruptor aparte para los plugins.

Revertir en lugar de prevenir

Cuando existe una capa externa que no puedes desactivar, el planteamiento operativo cambia. La red de seguridad deja de estar en frenar la actualización y pasa a estar en poder deshacerla.

Tanto los sistemas de plataforma como los autoinstaladores suelen generar una copia inmediatamente antes de actualizar, y ahí tienes el punto de retorno con su fecha y hora. No es lo que buscabas si querías controlar el momento, pero funciona como red siempre que sepas que existe, sepas dónde está el botón y lo incorpores a tu procedimiento. El trabajo pasa de impedir el cambio a detectarlo rápido y tener claro el camino de vuelta.

El diagnóstico de salud del sitio

En «Herramientas > Salud del sitio» WordPress ejecuta una serie de comprobaciones internas que indican si las actualizaciones en segundo plano pueden funcionar. Verifica si WP_AUTO_UPDATE_CORE tiene un valor válido, si algún plugin ha desactivado la comprobación de versión, si hay filtros interceptando el proceso, si detecta control de versiones, si los permisos de archivo permiten escritura y si va a requerir credenciales de FTP, entre otras.

Una de ellas merece atención especial. Si una actualización automática falló en algún momento de forma grave, WordPress se autobloquea y no vuelve a intentarlo hasta que entres y pulses «Actualizar ahora» manualmente una vez. Es posible llevar meses sin actualizaciones automáticas por un fallo puntual antiguo sin haberlo detectado.

Si esa pantalla te resulta excesiva tengo publicado cómo desactivar comprobaciones concretas de la salud del sitio y también cómo reducir su carga sin renunciar a ella, aunque conviene tener presente que ocultar un aviso no equivale a resolverlo.

Vigilancia de cambios en el wp-config.php

Todo esto gira alrededor de un archivo y de quién decide su contenido efectivo, así que resulta útil enterarse cuando cambia.

Wordfence lleva años ofreciendo verificación de integridad de archivos del núcleo y cumple perfectamente esa función. Si además quieres vigilancia específica de los archivos de configuración, en mi plugin Vigilante el módulo de integridad de archivos compara wp-config.php y .htaccess contra una base de referencia y muestra las diferencias línea a línea, con aprobación individual de cada cambio. Sirve para detectar que un plugin, una actualización o alguien con acceso ha modificado las constantes. Es gratuito y convive sin conflictos con Wordfence o con el plugin de seguridad que ya tengas instalado.

¿Y de qué me sirve a mi todo esto?

La regla que se deduce de todo lo anterior es sencilla. Antes de escribir una línea en tu wp-config.php, averigua si hay algo por encima que vaya a decidir por ti. Si no lo hay, los controles de WordPress funcionan exactamente como están documentados, incluida la detección de control de versiones. Si lo hay, tu configuración vive en el panel del proveedor y tu red de seguridad está en las copias previas.

Lo que he verificado directamente es el comportamiento de SiteGround, con fecha y capturas. El resto de proveedores citados aparecen con su propia documentación, no con pruebas mías, y lo señalo porque cada plataforma puede cambiar su funcionamiento sin avisar.

Si mantienes webs de clientes y esto afecta a tu procedimiento, o si has probado la detección de control de versiones en otro proveedor con un resultado distinto, te agradezco que lo cuentes en los comentarios, porque me interesa recopilar el comportamiento de otros hosting.

Te lo resumo todo aquí, por si no pudiste verlo en directo o prefieres leerlo con un café.

Crónicas WordPress: WordPress 7.1.1, el lío de Rank Math y Google pisando el acelerador hacia el abismo

Seguridad: WordPress 7.1.1 y una semana de agujeros gordos

WordPress 7.1.1 salió el 17 de septiembre y es, sobre todo, una versión de seguridad. Corrige 11 vulnerabilidades, además de 17 fallos en el núcleo y casi 20 en Gutenberg, entre ellos un XSS almacenado bastante serio. Si todavía no has actualizado, ya estás tardando.

Me hizo gracia que Anthropic, la empresa de Claude, aparezca acreditada en dos de esas 11 vulnerabilidades. Ya empieza a ser lo normal, y hasta en GitHub queda reflejado cuando ha participado una IA en encontrar o arreglar algo.

En esta versión entra también un arreglo que reporté yo. El mapa del sitio nativo de WordPress devolvía un error 404 en las webs que no tienen entradas (solo páginas, productos y esas cosas, sin blog), cuando debería devolver un 200. Lo avisé, lo arreglaron y ha colado en la 7.1.1. Yo creo que merecía una versión grande, pero oye, entró.

Lo más gordo de la actualización es el cierre de Click to Shell, una cadena de ejecución remota de código. Parece un titular exagerado de web de seguridad, pero aquí es literal, porque con un solo clic en un enlace que parecía inofensivo te podían comprometer la web entera, sin necesidad de tener cuenta de usuario.

Y luego está lo de Rank Math, el plugin de SEO con más de 4 millones de instalaciones. Generaba automáticamente una contraseña de aplicación que les daba acceso al administrador de tu web, sin preguntarte, la enviaba a los servidores de la empresa (la misma que está detrás de WP Rocket) y no había forma de desactivarlo ni desde el propio plugin. Se denunció y lo han retirado.

Matt Mullenweg se ha cabreado, y esta vez con razón, así que ha pedido auditorías de seguridad obligatorias para cualquier plugin que pida acceso de administrador. Ya se está viendo cómo implementarlo. Quien dio la voz de alarma en agosto fue el desarrollador de The SEO Framework, que es competencia directa y lo que tú quieras, pero tiene razón y hay que dársela.

Mi opinión, aunque a nadie le importe. No puede ser que estemos hablando de un agujero que con un clic te compromete la web y que encima un plugin de SEO te abra la puerta de atrás por su cuenta. Para mí Rank Math se ha terminado. Les tenía cierto criterio como plugin de SEO, pero esto no se lo perdono ni medio.

Hubo más sustos:

• The Events Calendar: el plugin de eventos más conocido, con unas 600.000 instalaciones, tenía tres vulnerabilidades de nivel 9,8 (de lo más tocho que hay) por un vector muy poco corriente, los comentarios con bloques de Gutenberg mal saneados. El atacante podía restablecer la contraseña del administrador y quedarse con tu web. Si tienes una versión anterior a la 6.17.4.1, actualiza ya.
• WooCommerce Wholesale Lead Capture: un plugin para mayoristas con unas 6.000 instalaciones que, hasta la versión 2.0.3.1, permitía subir archivos sin validar mediante AJAX y sin identificarse. Son pocas instalaciones, pero ya se han detectado muchos intentos de explotarlo, y eso sí es grave.

Cerré la sección con una noticia mía, el lanzamiento de Vigilante 3.0. La novedad gorda es que el plugin se autoprotege, porque ¿qué hay peor que te ataquen con un plugin cualquiera? Pues que te ataquen a través del propio plugin de seguridad, que se supone que está para evitarlo. Como el miércoles dediqué el directo entero a esto, te lo cuento más abajo.

Comunidad: GatherPress sustituye a Meetup, formación para periodistas y un mercado de negocios WordPress

GatherPress nació en 2018, en un viaje de vuelta de una WordCamp de esos de un montón de horas, cuando alguien se preguntó por qué WordPress dependía de un servicio comercial como Meetup.com. Se subió como plugin al directorio oficial, se ha ido probando con grupos de varios países y este verano la Fundación WordPress lo ha anunciado como sustituto oficial de Meetup. Ya está en fase de pruebas en events.wordpress.org, y la fundación se ahorrará unos 200.000 dólares al año, que se dice pronto. La idea me parece cojonuda, lo que no me lo parece tanto es lo que se ha tardado en hacerle caso.

El Colegio Profesional de Periodistas de Andalucía ha lanzado más de 100 horas de formación para sus colegiados, y he tenido el gusto de que me incluyan. Me toca impartir el bloque de inteligencia artificial para WordPress, porque WordPress sigue siendo imprescindible, pero con IA se puede mejorar muchísimo. Si eres periodista y estás colegiado en Andalucía, apúntate, que creo que para vosotros es gratis.

También ha aparecido WP Acquire, un mercado para comprar y vender negocios basados en WordPress (plugins, temas, tiendas o webs). Publicar el anuncio cuesta 50 dólares, no cobran comisión y el vendedor se queda con el 100 % de la venta. Lo veo como un síntoma de madurez del sector, así que si te planteas vender algo, échale un ojo.

Desarrollo: lo que trae WordPress 7.2 y WooCommerce subiendo el listón de PHP

WordPress 7.2 está previsto para diciembre de 2026, así que será la última versión del año. En seguridad trae bastante:

• Una especie de modo sudo (para los que venís de Linux) que te pide volver a identificarte para las acciones sensibles.
• Una API de secretos, la Secrets API.
• Un refuerzo de las contraseñas de aplicación, que llevaban tiempo en barbecho (y a la vista de lo de Rank Math, falta hacía).

Además, el editor del sitio se podrá ampliar desde plugins con DataViews y DataForms, de lo que vamos a hablar mucho pronto. El bloque de tabla de contenidos pasa a estable, llega algún bloque nuevo que ya veremos en directo con calma y los Dashicons de toda la vida dejan paso a iconos SVG. No es para volverse loco, es una renovación, pero ya hay gente quejándose del icono nuevo, porque somos así de tocapelotas.

Y ojo, que nos despedimos de los temas «Twenty» después de 16 años. El nuevo tema por defecto se llamará Ipsum (como el Lorem Ipsum) y ya se puede descargar desde GitHub, que ahora todo va a GitHub (a mí no me gusta nada, pero a todo el mundo le encanta). Es minimalista, pensado para blogs, muy centrado en la accesibilidad y con varias tipografías y variaciones de estilo. Aparte saldrá otro tema, Metis, bastante más vistoso, que no vendrá integrado.

También se ha abierto la llamada a pruebas de DataForms para las pantallas de ajustes. Algo se va a notar a la vista, pero la mejora de verdad está en el rendimiento.

WooCommerce, por su parte, resucita Purple, su tema de bloques, en beta pública. Lo quitaron en julio de 2025 y ahora vuelve con muchas funciones que normalmente pedirían plugins, ya integradas en bloques. En WordPress.com ya es el tema por defecto, y no creo que tarde mucho en sustituir a Storefront como el tema que te sugiere WooCommerce al instalarlo.

La noticia de WooCommerce que más me preocupa es otra, porque va a subir el mínimo de PHP de la 7.4 a la 8.1, y poco después a la 8.3. Conozco montones de tiendas que siguen en PHP 7.4, no por WooCommerce ni por WordPress, sino por algún plugin concreto que casca en cuanto subes de versión. La 7.4 ya no tiene soporte ni actualizaciones de seguridad, así que o pones al día esos plugins o te quedas sin poder actualizar WooCommerce. Yo apuntaría como mínimo a la 8.2, y lo ideal sería la 8.3.

Y ya que hablamos de WooCommerce, me pidió mi amigo Jordan Suárez un tutorial sobre impuestos, que es de lo más cansino y raro que tiene WooCommerce, y resulta que no lo tenía. Pues ya la tienes, la guía para configurar los impuestos en WooCommerce. Son unos 30 minutos de lectura, así que no es para leerla de un tirón, es para guardarla y tirar de ella cuando te surja una duda. Gratis, como siempre, y sin publicidad que moleste.

IA: un curso gratis de Learn WordPress

Esta semana había muchas noticias de IA en WordPress, pero casi todo me pareció relleno, y si a mí me aburre, a ti ni te cuento. Me quedo con una. En Learn WordPress han publicado un curso gratuito de unas 9 horas sobre la IA integrada en WordPress desde la 7.0. Tiene cuatro módulos, casi todos sobre gestión de contenidos y la integración con Claude y ChatGPT. No es nada técnico, es online y lo haces cuando quieras, así que no tiene pega.

SEO: Google, sujétame el cubata

Google ha descubierto, llámame loco, que si sus vistas previas con IA siguen resumiendo el contenido sin mandar clics, se puede quedar sin contenido original. Porque las IA no crean contenido original, reciclan, hacen refritos y resúmenes de lo que ya existe. Así que ahora plantea pagar a los editores cuando su contenido alimenta esas respuestas, con un programa piloto que empezará, cómo no, en Estados Unidos. Donde más sentido tendría es entre los pequeños y medianos editores, los blogueros, que somos los que de verdad alimentamos todo esto. Que paguen por el trabajo bien hecho, no con subvenciones.

Luego vienen las alegrías de siempre:

• Fichas de empresa en las vistas previas con IA: los perfiles de Google Business empiezan a mostrarse ahí, con un «mostrar más» que abre una conversación con más datos del negocio. O sea, que nadie visita ya ni tu ficha ni Google Maps, todo se queda dentro del modo IA. Si con las preguntas relacionadas ya se cargaban el SEO normal, ahora le toca al SEO local.
• Anuncios camuflados en el modo IA: anuncios de texto metidos entre las respuestas con una etiqueta de patrocinado. Justo lo que necesitaba el buscador para que los usuarios terminen de perderle la confianza.
• Un botón de modo IA en la página de resultados: para empujarte a salir de la búsqueda clásica, que ya tienen asumido que es un desastre.

OpenAI también ha movido ficha con los agentes patrocinados de ChatGPT, conversaciones con un agente de la marca cuando ves un anuncio. Aquí voy a ser justo, porque sobre el papel van a estar bien separados de las respuestas normales y, si de verdad no mezclan lo patrocinado con lo neutral, me parece bastante más transparente que lo de Google. Hasta una buena idea, fíjate.

Llevo 25 años en esto y no me explico cómo Google se está cargando su propio producto. La IA no ha llegado a internet, se lo ha cargado, y Google le ha metido el turbo a la carrera hacia el abismo.

Europa y la EU Kids Act

Para rematar, la Unión Europea está preparando la EU Kids Act, que prohibiría las redes sociales (Instagram, TikTok, YouTube) a menores de 13 años, permitiría el acceso entre los 13 y los 15 solo con supervisión de los padres, funciones limitadas y control horario, y vetaría hasta el scroll infinito.

Ya sé que mucha gente lo ve bien, porque hay que proteger a los niños y las plataformas abusan, y en eso no les falta razón. Pero esta es una opinión de las intensas, así que te la cuento tal cual. Las instituciones están para servirnos, no para sustituirnos. Si aceptamos que decidan a partir de qué edad y cómo usan nuestros hijos las redes, les estamos dejando hacer nuestro papel de padres, primero en esto y luego en lo que les dé la gana. Lo que hay que hacer es formar a los padres para que sean conscientes y responsables de cómo usan sus hijos las redes y la IA.

En el chat, Mel Gómez apuntó algo con lo que estoy muy de acuerdo, que al final la gente dejará de fiarse de la IA y pedirá referencias. Creo que volveremos a lo único que da confianza de verdad, saber quién ha escrito qué. Yo me hago responsable de lo que digo, aun a riesgo de equivocarme, y si mañana tengo que rectificar, rectifico. Por eso se está volviendo tanto a los foros y a las comunidades de nicho, y no me extrañaría que volviéramos a los blogs enlazándose entre ellos, como con aquellos blogrings de antes.

Ver el directo completo de Crónicas WordPress en YouTube

Doctor WordPress: cómo funciona la autoprotección de Vigilante 3.0

Me habíais preguntado bastante por la autoprotección de Vigilante 3.0, así que le dediqué el directo entero. La idea llevaba meses rondándome la cabeza, porque si no te puedes fiar de tu plugin de seguridad, no te puedes fiar de nada de lo que te diga. Un plugin de seguridad te protege de otros plugins y de inyecciones, pero ¿quién lo protege a él?

La cerradura, la caja fuerte y la fábrica

Piensa en tu web como en tu casa. Un ladrón listo no revienta la puerta, que hace mucho ruido. Lo que hace es cambiarte el bombín por uno que abre con tu llave y también con la suya, como hacen con los cajeros y las tarjetas. Tú sigues entrando como siempre, no notas nada, y él entra cuando quiere. Eso es lo que tiene que detectar la autoprotección, que alguien ha tocado tu cerradura.

Para eso Vigilante se comprueba contra tres referencias:

• El manifiesto: un archivo que va con el plugin y que es distinto en cada instalación. Sería la ficha grabada en el propio bombín.
• La huella en la base de datos: la tarjeta que te dio el cerrajero y que guardas en la caja fuerte. Para falsificarla no basta con entrar en casa, también hay que abrir la caja fuerte. Y cada vez que el cerrajero (el actualizador de WordPress) te cambia el bombín, te da una tarjeta nueva.
• Las sumas de verificación de WordPress.org: el registro del fabricante, que está en la fábrica y no en tu casa, así que aunque te hayan reventado la caja fuerte, eso no lo pueden tocar. Eso sí, cuando sale una versión nueva, WordPress.org tarda unas horas en actualizar ese registro.

Para engañar al plugin harían falta las tres llaves, y la tercera ni siquiera está en tu casa. En el escritorio de Vigilante lo ves como «Autoprotección de Vigilante», con el número de archivos verificados y «3 de 3 referencias» si todo está bien.

Los casos que te puedes encontrar

En el directo fui forzando cada situación con un mu-plugin de pruebas en mi instalación local (la que rompo casi a diario). Te resumo qué verías y qué hacer en cada caso:

• Todo correcto: tres de tres referencias, en verde, y a otra cosa.
• Verificado, pero sin sumas de WordPress.org: pasa justo después de una actualización, mientras el registro del fabricante se pone al día. Lo da por bueno y te lo explica en la comprobación de seguridad.
• Dos de tres referencias: el indicador pasa a gris. No es grave, pero te avisa.
• Una hoja de estilos, un script o una imagen modificados: aparece un aviso, porque ya no es solo una referencia, hay un archivo tocado. Muchas veces es cosa de un plugin de caché u optimización que minifica los archivos, así que excluye la carpeta de Vigilante. Si no usas ninguno, pulsa «Reparar Vigilante», que descarga una copia limpia desde WordPress.org y sustituye los archivos en un clic.
• Versión cambiada sin confirmar: el manifiesto no coincide, por ejemplo porque has actualizado a mano por FTP sin pasar por el actualizador. Si has sido tú, lo aceptas, y si no, reparas.
• Versión anterior instalada: alguien ha sustituido Vigilante por una versión más antigua, que puede tener vulnerabilidades ya corregidas. Si no has sido tú, reparar.
• Archivo de código modificado: aquí ya estamos en la zona crítica. El aviso sale en rojo en todas las pantallas importantes del administrador (menos en el editor), no se puede cerrar y la puntuación de seguridad deja de ser fiable. En el ejemplo te decía qué archivos habían tocado, el del cortafuegos y el del acceso, así que ya no te puedes fiar ni de uno ni de otro. Reparar, inmediatamente.
• Archivo inyectado: alguien ha metido un archivo nuevo en la carpeta del plugin. En la prueba se llamaba «puerta-trasera.php», pero ningún atacante lo va a llamar así, le pondrá un nombre que parezca legítimo para que no lo borres. Pide a tu hosting que mire cuándo llegó ese archivo, repara y vuelve a analizar. Y revisa la auditoría de seguridad, que es donde queda todo registrado.
• Manifiesto sustituido, borrado o dañado: han manipulado una de las llaves. Quedan las otras dos referencias, pero lo rápido es reparar desde WordPress.org, que siempre va a estar mucho mejor protegido que tu web (y que la mía).
• Tareas programadas eliminadas: este es de los más retorcidos. Vigilante hace sus comprobaciones con el cron de WordPress (la tarea de mantenimiento diario), y si alguien se las carga, el plugin sigue ahí pero no hace nada, sin análisis ni alertas. Revisa con WP Crontrol que estén las tareas que empiezan por «vigilante_» y, si faltan, haz un análisis de seguridad completo.
• Autoprotección desactivada por código: es el último aviso que vas a recibir, porque a partir de ahí nada comprueba nada. Por lo menos te dice qué archivo lo ha desactivado, como una especie de memoria de quién te mató. Si no has sido tú, trátalo como una intrusión, borra o desactiva ese archivo (renombrarlo a .off, por ejemplo) y vuelve a comprobar.
• Todavía sin comprobar: lo normal justo después de instalar, o tras una instalación por FTP. Lanza un análisis desde la pestaña de integridad de archivos y listo.

Plugins hechos con IA: el problema son las instrucciones que no das

Iván San José comentó en el chat que está creando plugins para uso propio con agentes de IA y que no hay límites. Sí que los hay, y el límite eres tú, porque luego hay que mantenerlos, actualizarlos y someterlos a revisiones que, si las haces tú solo, nunca van a ser suficientes.

Lo veo a diario con los clientes de mi servicio de mantenimiento. He pasado de que me pidan código a que me lo pasen, plugins hechos por alguien de marketing con ChatGPT o Claude que no sabe programar y lo da por bueno. Ninguno pasa mis comprobaciones de seguridad y de estándares de código. Y yo, que tengo mis skills bien afinadas y hago pruebas en instalaciones de test, también cometo errores.

Hace nada me pasaron un plugin que ya había pasado por mis skills de seguridad y aun así duplicaba pedidos en producción, porque nadie había cerrado un bucle. La IA sabe mucho de código, pero también hace cosas que no le has pedido. Si le dices que se asegure al 100 % de que un email llega, igual te lo manda por SMTP, por PHP mail y por un tercer sistema. El problema de los plugins hechos con IA no suelen ser las instrucciones que le das, sino las que no le das. Para jugar o para algo interno, adelante, pero si va a una web abierta al público, que lo revise alguien más y usa modelos buenos, de pago.

Nada es invulnerable

¿Significa todo esto que Vigilante es invulnerable? Ni de coña. La seguridad al 100 % no existe, y quien te diga lo contrario te está mintiendo. Vigilante, igual que otros dos plugins míos, ha tenido vulnerabilidades, unas las encontré yo y otras los usuarios. Las arreglo esa misma tarde y lo cuento, pero pasan.

La mayoría de los hackeos no vienen de fallos desconocidos, sino de vulnerabilidades conocidas que alguien no ha parcheado. Hay muchísimos escáneres, cada vez más con IA, tirando de bases de datos de vulnerabilidades y buscando webs con la versión afectada de un plugin. Hasta un reloj parado acierta dos veces al día. Lo bueno del código abierto es que todo es transparente y las vulnerabilidades se conocen cuando ya están corregidas. El problema es cuando se publica el parche y tú no actualizas, porque el atacante sí se ha enterado.

Así que lo de siempre, que es lo que más se nos olvida. Ten todo actualizado, y si puedes, Vigilante instalado, al día, con la autoprotección activa y la configuración de seguridad al máximo.

Ver el directo completo de Doctor WordPress en YouTube

Nos vemos en el próximo directo

Y hasta aquí la semana. Ya lo sabes, los lunes toca Crónicas WordPress y los miércoles, Doctor WordPress, a las 19:30 (hora peninsular) en el canal de Ayuda WordPress. Por cierto, admito invitados, así que si tienes algo interesante que contar, dímelo. Y si tienes cualquier duda de lo que he contado, o me quieres corregir en algo, te leo ahí abajo en los comentarios.