Como funciona el nuevo asistente de google discover y como optimizar wordpress para feeds personalizados

#Como funciona el nuevo asistente de google discover y como optimizar wordpress para feeds personalizados

Google Discover es el feed de artículos y vídeos que la aplicación de Google muestra en Android e iOS sin que el usuario escriba una búsqueda. En octubre de 2026 la palabra “concierge” empezó a circular asociada a él, así que conviene separar lo que Google ha lanzado de aquello para lo que todavía está contratando personal. El 13 de octubre de 2026 Search Engine Roundtable informó de una oferta de empleo de Google para Principal, UX, Search Discover cuyo objetivo declarado es convertir Discover en una experiencia de concierge proactiva e hiperpersonalizada. Es una dirección escrita en una descripción de puesto, no un producto lanzado. Lo que sí llegó en 2026 es el ajuste del feed en lenguaje natural, anunciado en el blog de Google el 20 de agosto de 2026.

Para sitios en WordPress y tiendas WooCommerce la consecuencia práctica es la misma en ambos casos. Discover elige contenido del índice de Google por intereses, no por búsquedas, y un puñado de condiciones técnicas decide si una página puede aparecer siquiera con una tarjeta de imagen grande. Esta guía separa los hechos confirmados de la especulación y después recorre la parte de WordPress: directivas robots, imágenes, feeds y WebSub, caché, marcado de entidades, datos estructurados de WooCommerce, Core Web Vitals y medición en Search Console.

#Cual es la diferencia entre el concierge de google discover y el feed de noticias tradicional

El feed actual de Discover es una superficie de recomendación. La documentación de Discover de Google lo describe como contenido alineado con lo que interesa a cada persona y señala que esos intereses cambian con el tiempo. No hay búsqueda ni posición en el sentido habitual: una página se muestra a alguien con intereses afines, o no se muestra.

La etiqueta concierge procede de la oferta publicada en el sitio de empleo de Google. Según los fragmentos citados por Search Engine Roundtable, el puesto debe liderar el trabajo en una “experiencia de concierge proactiva e hiperpersonalizada”, “equilibrar las capacidades de IA situando en el centro las voces y las fuentes humanas” y “hacer evolucionar los formatos del feed escalando formatos basados en IA” (oferta de empleo de Google citada por Search Engine Roundtable, traducción propia). Eso describe una intención y un encargo de contratación. No menciona tipos de tarjeta, fuentes de datos ni fecha de lanzamiento, y Google no ha publicado documentación para desarrolladores sobre un modo concierge. Cualquier texto que explique cómo ordena el concierge los contenidos, qué señales de Calendar o Maps lee o qué formatos de tarjeta genera está adivinando.

El cambio confirmado es más pequeño y ya está en manos de los usuarios. En una entrada del blog de Google fechada el 20 de agosto de 2026, Mrinalini Loew, General Manager de Google Search Ecosystem, escribió que “en los próximos días, en la aplicación de Google, se podrá tocar cualquier menú de tres puntos del feed para decirle a Google, con sus propias palabras, exactamente qué temas o enlaces quiere ver más (o menos)” y que “el feed se ajustará sobre la marcha y recordará esas peticiones” (Mrinalini Loew, Google, traducción propia). Antes, los usuarios orientaban el feed sobre todo con los controles de seguir y de “no me interesa”.

Para los editores esto tiene una consecuencia concreta. Un lector puede describir ahora un interés con palabras corrientes, hasta un subtema muy concreto, y el feed debe tenerlo en cuenta. El contenido que dice con claridad de qué trata, en el título, los encabezados y la imagen principal, es más fácil de emparejar con esa petición que un titular vago o de clickbait. Las directrices de Google para Discover ya pedían títulos de página y titulares que capten la esencia del contenido. Los controles en lenguaje natural vuelven ese consejo más concreto, pero no lo sustituyen.

#Que requisitos técnicos debe cumplir un sitio wordpress para aparecer en google discover

No existe un registro para Discover. La documentación de Google afirma que el contenido es apto automáticamente para aparecer en Discover si está indexado por Google y cumple las políticas de contenido de Discover, que no se necesitan etiquetas especiales ni datos estructurados y que ser apto no garantiza aparecer. El primer requisito es, por tanto, la indexabilidad normal: la página devuelve 200, no está bloqueada en robots.txt, no lleva noindex y tiene una URL canónica que apunta a sí misma o a la versión que se quiere indexar.

El segundo requisito afecta a las vistas previas grandes de imagen. Google señala la directiva robots max-image-preview:large, o AMP, como condición para las imágenes grandes en Discover. Sin ella una página puede seguir apareciendo, pero solo con una miniatura pequeña. La directiva es esta:

<!-- Directivas robots obligatorias para Google Discover en la cabecera head -->
<meta name="robots" content="index, follow, max-image-preview:large, max-snippet:-1, max-video-preview:-1" />

El núcleo de WordPress genera esta directiva por defecto desde la versión 5.7 mediante la función wp_robots_max_image_preview_large(), pero solo cuando la opción blog_public está activa, es decir, cuando el sitio no pide a los motores de búsqueda que no lo indexen. Compruebe primero la etiqueta <meta name="robots"> renderizada. Si un tema, un plugin de SEO o un resto del entorno de staging elimina o sobrescribe el valor, un filtro sobre wp_robots en el functions.php del tema hijo lo restablece con prioridad tardía:

<?php
/**
 * Asegurar directivas robots para Google Discover en WordPress
 */
function wppoland_garantizar_discover_robots_es($robots) {
    $robots['max-image-preview'] = 'large';
    $robots['max-snippet'] = -1;
    $robots['max-video-preview'] = -1;
    return $robots;
}
add_filter('wp_robots', 'wppoland_garantizar_discover_robots_es', 99);

El tercer requisito es la propia imagen. Google recomienda usar marcado schema.org o la meta etiqueta og:image para indicar una imagen grande, relevante y representativa de la página, porque eso puede influir en la imagen elegida. Un og:image roto o diminuto no excluye por sí solo la página de Discover, pero le quita el control sobre la imagen que elige Google. Google no documenta qué campos Open Graph aparte de la imagen lee Discover, así que la etiqueta HTML <title> y el titular visible también deben ser correctos, no solo las etiquetas Open Graph.

#Que contenido filtra google discover y cuando aparecen las acciones manuales

Discover tiene políticas de contenido propias que se suman a las políticas generales de la Búsqueda de Google. La documentación enumera formatos que Discover puede evitar mostrar: solicitudes de empleo, peticiones, formularios, repositorios de código y sátira sin contexto. También filtra el contenido que podría resultar impactante o inesperado para alguien que no lo buscó. Un sitio WordPress que publique fragmentos de código como repositorio, o páginas de destino que son sobre todo formularios, no debe esperar ver esas URLs en Discover, sea cual sea su calidad.

Las pautas de presentación son concretas. Google pide evitar el clickbait, es decir, usar detalles engañosos o exagerados en la vista previa (título, fragmentos o imágenes) para aumentar el atractivo, u ocultar información esencial para entender de qué trata el contenido. Pide también evitar el sensacionalismo que juega con la curiosidad morbosa, la provocación o la indignación. En su lugar, espera contenido oportuno para los intereses actuales, que cuente bien una historia o aporte puntos de vista únicos.

Cuando un sitio infringe estas políticas, Google indica que pueden aparecer acciones manuales de Discover en Search Console, en Seguridad y acciones manuales. Es el primer lugar que hay que revisar si el tráfico de Discover desaparece por completo mientras el de búsqueda se mantiene estable. Una acción manual de Discover no se refleja como caída en el informe de rendimiento de la búsqueda web, de modo que un sitio puede parecer sano en un informe y estar excluido en el otro.

En una redacción con WordPress esto se traduce en tres comprobaciones antes de publicar: el titular dice qué pregunta responde el artículo, la imagen destacada muestra el tema en lugar de un logotipo o una banda con texto, y el primer párrafo cumple lo que promete el titular.

#Por que son obligatorias las imágenes de mas de 1200px y la directiva max image preview large

Discover es un feed visual, y la imagen decide cuánto espacio ocupa una tarjeta. La documentación de Google da la especificación de las imágenes grandes:

• Ancho: al menos 1200 px.
• Resolución: más de 300 000 píxeles en total.
• Proporción: 16x9.
• Directiva robots: activada con max-image-preview:large o mediante AMP.

Google añade dos advertencias fáciles de pasar por alto en los temas de WordPress. Evite imágenes genéricas, por ejemplo el logotipo del sitio, en el marcado schema.org o en og:image, y es justo el logotipo lo que usan muchos temas y plugins de SEO cuando una entrada no tiene imagen destacada. Además, para obtener mejores resultados, evite imágenes con mucho texto en esos campos, lo que descarta las tarjetas de título con el titular en letra grande.

Un tamaño de imagen propio hace que la regla de los 1200 px se pueda aplicar, en lugar de depender de lo que suba cada editor. El código siguiente registra un recorte de 1344 por 768, cercano a 16:9 y de unos 1,03 millones de píxeles, y solo imprime las etiquetas de imagen Open Graph cuando el archivo generado alcanza de verdad los 1200 px:

<?php
/**
 * Registrar tamaño de imagen optimizado para Google Discover
 */
function wppoland_registrar_formato_discover_es() {
    add_image_size('discover-hero-es', 1344, 768, true);
}
add_action('after_setup_theme', 'wppoland_registrar_formato_discover_es');

/**
 * Publicar etiquetas Open Graph con medidas explicitas en el head
 */
function wppoland_insertar_og_discover_es() {
    if (is_singular('post')) {
        global $post;
        if (has_post_thumbnail($post->ID)) {
            $imagen = wp_get_attachment_image_src(get_post_thumbnail_id($post->ID), 'discover-hero-es');
            if ($imagen && $imagen[1] >= 1200) {
                echo '<meta property="og:image" content="' . esc_url($imagen[0]) . '" />' . "\n";
                echo '<meta property="og:image:width" content="' . esc_attr($imagen[1]) . '" />' . "\n";
                echo '<meta property="og:image:height" content="' . esc_attr($imagen[2]) . '" />' . "\n";
                echo '<meta property="og:image:type" content="image/avif" />' . "\n";
            }
        }
    }
}
add_action('wp_head', 'wppoland_insertar_og_discover_es', 5);

Dos notas prácticas. El recorte solo existe para las imágenes subidas después de registrar el tamaño, así que las entradas antiguas necesitan regenerar sus miniaturas, por ejemplo con wp media regenerate en WP-CLI. Y WordPress no amplía una imagen de origen más pequeña que el recorte, por eso el código comprueba el ancho real antes de imprimir las etiquetas. Si sus imágenes no son AVIF, cambie el valor de og:image:type por el tipo real del archivo.

#Como implementar websub en wordpress para indexar nuevos artículos en cuestión de segundos

La actualidad importa en Discover porque las directrices de Google piden contenido oportuno para los intereses actuales. Cuanto antes sepa Google que existe una URL nueva, antes podrá tenerla en cuenta. Los sitemaps funcionan, pero Google los descarga según su propio calendario. WebSub es un mecanismo de envío: el editor avisa a un hub de que un feed ha cambiado y el hub notifica a sus suscriptores.

WebSub, antes PubSubHubbub, es una Recomendación del W3C. La especificación define cómo anuncia el editor su hub: con cabeceras HTTP Link o con elementos <link>, rel="hub" para el hub y rel="self" para la URL del propio feed. Deja abierto a propósito cómo informa el editor al hub. La especificación califica ese mecanismo de no especificado, y muchos hubs, entre ellos el hub público de Google en https://pubsubhubbub.appspot.com/, aceptan un POST con hub.mode=publish y hub.url con la dirección del feed. Google no documenta que un ping a su hub acelere la entrada de una página en Discover, así que trate WebSub como una forma de acortar el descubrimiento del feed, no como un interruptor de Discover.

El código siguiente envía el ping al publicar y añade los enlaces de descubrimiento al feed Atom, sin plugins adicionales:

<?php
/**
 * Enviar aviso WebSub al hub de Google al publicar articulos
 */
function wppoland_enviar_ping_websub_es($post_id, $post) {
    if (wp_is_post_revision($post_id) || wp_is_post_autosave($post_id)) {
        return;
    }
    
    if ($post->post_status !== 'publish' || $post->post_type !== 'post') {
        return;
    }

    $hub_url = 'https://pubsubhubbub.appspot.com/';
    $feed_url = get_feed_link('atom');

    wp_remote_post($hub_url, [
        'method'      => 'POST',
        'timeout'     => 5,
        'redirection' => 2,
        'httpversion' => '1.1',
        'blocking'    => false, // Peticion asincrona para no demorar la interfaz editorial
        'headers'     => [
            'Content-Type' => 'application/x-www-form-urlencoded; charset=utf-8',
        ],
        'body'        => [
            'hub.mode' => 'publish',
            'hub.url'  => $feed_url,
        ],
    ]);
}
add_action('publish_post', 'wppoland_enviar_ping_websub_es', 10, 2);

/**
 * Insertar enlaces de descubrimiento hub y self en el feed Atom
 */
function wppoland_insertar_enlaces_atom_es() {
    $hub_url = 'https://pubsubhubbub.appspot.com/';
    echo '<link rel="hub" href="' . esc_url($hub_url) . '" />' . "\n";
    echo '<link rel="self" href="' . esc_url(get_feed_link('atom')) . '" />' . "\n";
}
add_action('atom_head', 'wppoland_insertar_enlaces_atom_es');

Si prefiere un plugin mantenido, el directorio de WordPress.org incluye WebSub (FKA. PubSubHubbub), que anuncia los hubs en los feeds y envía el ping de publicación. No use el plugin y el código a la vez, o cada publicación enviará dos pings.

El feed debe incluir el texto completo de cada entrada, no solo un extracto. En WordPress lo controla la opción rss_use_excerpt de los ajustes de lectura: con el valor 0 el feed Atom imprime el texto completo en el elemento <content>, y el feed RSS 2.0 usa <content:encoded>.

#Como configurar cabeceras cache control y cloudflare edge caching para feeds rss y atom

Cuando hubs y rastreadores descargan los feeds después de cada publicación, cada petición sin caché ejecuta toda la pila PHP de WordPress. Una caché compartida corta mantiene el feed al día y protege el servidor de origen. En Nginx:

# Ajuste de Nginx para entrega rapida de feeds WordPress
location ~* /feed/ {
    add_header Cache-Control "public, max-age=300, stale-while-revalidate=600";
    expires 5m;
}

La misma cabecera puede definirse desde WordPress:

<?php
/**
 * Definir cabeceras de cache avanzadas para feeds RSS y Atom
 */
function wppoland_configurar_cache_feed_es() {
    if (is_feed()) {
        header_remove('Pragma');
        header('Cache-Control: public, max-age=300, stale-while-revalidate=600');
    }
}
add_action('template_redirect', 'wppoland_configurar_cache_feed_es', 1);

Con max-age=300 una CDN como Cloudflare puede servir el feed durante un máximo de cinco minutos, y stale-while-revalidate=600 le permite servir la copia anterior mientras descarga una nueva. Mantenga el TTL corto. Un feed en caché durante horas anularía el ping de WebSub, porque el hub descargaría la versión desactualizada. Si guarda los feeds en caché en el edge durante más tiempo, purgue la URL del feed en cada publicación.

#Como estructurar la autoridad temática y enlazar entidades con wikidata para personalización

Discover empareja contenido con intereses, y Google describe esos intereses en términos de temas, no de palabras clave. Google no publica cómo asigna Discover las páginas a temas, así que el objetivo realista es que el tema de cada página sea inequívoco: encabezados claros, terminología coherente y datos estructurados que nombren las entidades principales.

En un sitio WordPress eso supone tres cosas:

1. JSON-LD con about y mentions: enlace los temas principales con identificadores estables, como URLs de Wikidata o Wikipedia, para que “Discover” o “WebSub” no se confundan con otro término.
2. Autores como entidades Person: vincule los perfiles de autor con los perfiles que el autor mantiene de verdad, como LinkedIn o GitHub, para que lectores y rastreadores vean quién escribió el contenido.
3. Clústeres temáticos: publique artículos relacionados sobre un tema y enlácelos entre sí, para que la profundidad de la cobertura sea visible.

Un grafo de ejemplo:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "TechArticle",
      "@id": "https://wppoland.com/blog/como-funciona-el-nuevo-asistente-de-google-discover/#article",
      "isPartOf": {
        "@id": "https://wppoland.com/#website"
      },
      "headline": "Como funciona el nuevo asistente de google discover y como optimizar wordpress para feeds personalizados",
      "description": "Manual tecnico sobre la arquitectura del asistente de IA en Google Discover y metodos de optimizacion para WordPress.",
      "inLanguage": "es-ES",
      "mainEntityOfPage": "https://wppoland.com/blog/como-funciona-el-nuevo-asistente-de-google-discover/",
      "datePublished": "2026-10-14T08:00:00+02:00",
      "dateModified": "2026-10-14T10:30:00+02:00",
      "image": {
        "@type": "ImageObject",
        "@id": "https://wppoland.com/blog/como-funciona-el-nuevo-asistente-de-google-discover/#primaryimage",
        "url": "https://wppoland.com/images/digital-experience-platforms-dxp-vs-wordpress.avif",
        "width": 1344,
        "height": 768,
        "caption": "Optimizacion de WordPress para Google Discover"
      },
      "author": {
        "@type": "Person",
        "name": "Mariusz Szatkowski",
        "url": "https://wppoland.com/author/mariusz-szatkowski/",
        "jobTitle": "Lead WordPress Architect",
        "sameAs": [
          "https://www.linkedin.com/in/mariuszszatkowski",
          "https://github.com/wppoland"
        ]
      },
      "publisher": {
        "@type": "Organization",
        "name": "WPPoland",
        "url": "https://wppoland.com",
        "logo": {
          "@type": "ImageObject",
          "url": "https://wppoland.com/logo.png",
          "width": 512,
          "height": 512
        }
      },
      "about": [
        {
          "@type": "Thing",
          "name": "Google Discover",
          "sameAs": "https://en.wikipedia.org/wiki/Google_Discover"
        },
        {
          "@type": "SoftwareApplication",
          "name": "WordPress",
          "sameAs": "https://www.wikidata.org/wiki/Q13166"
        }
      ],
      "mentions": [
        {
          "@type": "Thing",
          "name": "Core Web Vitals",
          "sameAs": "https://en.wikipedia.org/wiki/Core_Web_Vitals"
        },
        {
          "@type": "Thing",
          "name": "WebSub",
          "sameAs": "https://en.wikipedia.org/wiki/WebSub"
        }
      ]
    }
  ]
}
</script>

Los datos estructurados no son un requisito de Discover; Google afirma que no se necesitan etiquetas especiales. Su valor aquí es eliminar la ambigüedad sobre el tema de la página y su autor.

#Como optimizar tiendas woocommerce para recomendaciones proactivas en el feed de google

La documentación de Discover no describe tarjetas de producto ni ninguna función específica de WooCommerce. Lo que una tienda controla es la calidad de sus datos de producto en la Búsqueda de Google en general y el tipo de contenido que Discover sí muestra: artículos editoriales oportunos y útiles.

Tres pasos mantienen coherentes los datos de producto:

1. Precio y disponibilidad en el schema: WooCommerce genera datos estructurados de tipo Product; compruebe que price, priceCurrency y availability coinciden con lo que muestra la página.
2. GTIN: desde la versión 9.1 WooCommerce tiene en el producto un campo para GTIN, UPC, EAN o ISBN, y su clase de datos estructurados genera la propiedad gtin cuando el valor es válido. La documentación de Google sobre fichas de comerciante incluye gtin entre los identificadores de producto que lee, así que rellenar ese campo es mejor que guardar el código en un campo meta propio.
3. Contenido editorial alrededor de los productos: guías de compra, comparativas y pruebas encajan con las directrices de Discover sobre contenido oportuno y con criterio propio. Los listados de productos y las páginas de categoría rara vez encajan.

Los datos de devolución entran en la oferta mediante el filtro woocommerce_structured_data_product_offer. WooCommerce guarda las ofertas como una lista dentro del marcado del producto, por lo que este filtro es el lugar adecuado para hasMerchantReturnPolicy, una propiedad admitida según la documentación de Google sobre fichas de comerciante:

<?php
/**
 * Añadir la política de devoluciones al schema de la oferta de WooCommerce.
 * WooCommerce 9.1+ ya genera gtin a partir del campo GTIN del producto.
 */
function wppoland_discover_return_policy($markup_offer, $product) {
    $markup_offer['hasMerchantReturnPolicy'] = [
        '@type' => 'MerchantReturnPolicy',
        'applicableCountry' => 'ES',
        'returnPolicyCategory' => 'https://schema.org/MerchantReturnFiniteReturnWindow',
        'merchantReturnDays' => 30,
        'returnMethod' => 'https://schema.org/ReturnByMail',
        'returnFees' => 'https://schema.org/FreeReturn',
    ];
    return $markup_offer;
}
add_filter('woocommerce_structured_data_product_offer', 'wppoland_discover_return_policy', 10, 2);

Ajuste el país, el número de días y los costes a las condiciones reales de la tienda. Unos datos estructurados que contradicen la política de devoluciones visible son peores que no tenerlos.

#Que impacto tienen las core web vitals y un inp menor a 200ms en google discover

Las directrices de Discover piden a los editores ofrecer una buena experiencia de página en conjunto. Las visitas de Discover se producen en teléfonos, a menudo con conexión móvil, así que los datos de campo móviles son los que más pesan. Los umbrales de Core Web Vitals publicados en web.dev son:

• LCP: 2,5 segundos o menos.
• INP: 200 milisegundos o menos. INP sustituyó a FID como Core Web Vital en marzo de 2024.
• CLS: 0,1 o menos.

web.dev recomienda medirlos en el percentil 75 de las cargas de página, separando móvil y escritorio.

En un artículo de Discover el elemento LCP suele ser la imagen destacada, la misma imagen grande que muestra la tarjeta. Desde WordPress 6.3 el núcleo añade fetchpriority="high" a la imagen que considera más probable como elemento LCP y deja de aplicar carga diferida a las imágenes situadas antes del loop, como describen las notas sobre rendimiento de imágenes en WordPress 6.3. En versiones anteriores, o con temas que imprimen la imagen destacada fuera de las funciones estándar, el código siguiente define los atributos de forma explícita:

<?php
/**
 * Optimizar el LCP de la imagen de portada para Google Discover
 */
function wppoland_optimizar_hero_discover_es($content) {
    if (is_singular('post')) {
        add_filter('wp_get_attachment_image_attributes', function($attr, $attachment, $size) {
            if ($size === 'discover-hero-es' || $size === 'post-thumbnail') {
                $attr['loading'] = 'eager';
                $attr['fetchpriority'] = 'high';
                $attr['decoding'] = 'async';
            }
            return $attr;
        }, 10, 3);
    }
    return $content;
}
add_action('wp', 'wppoland_optimizar_hero_discover_es');

En WordPress 6.3 o posterior, revise el HTML renderizado antes de añadirlo: si el núcleo ya marca la imagen, el filtro sobra. En INP, las causas habituales en WordPress son scripts pesados de terceros, sliders y banners de consentimiento que bloquean el hilo principal durante las primeras interacciones.

#Por que el tráfico de google discover sube y baja de golpe y como mantener visibilidad constante

El tráfico de Discover suele llegar en oleadas: un artículo se muestra ampliamente durante poco tiempo y luego se apaga. La documentación de Google dice de forma explícita que el tráfico de Discover es menos previsible y fiable que las visitas de la búsqueda por palabras clave y que los editores deben considerarlo complementario al tráfico de búsqueda.

Google enumera las razones de los cambios:

• Intereses cambiantes: Discover muestra contenido alineado con los intereses de cada persona, y esos intereses se desplazan.
• Tipos de contenido: Discover ha ajustado y sigue ajustando los tipos de contenido que pueden aparecer en el feed.
• Actualizaciones de la búsqueda: Discover es una extensión de la Búsqueda, así que sus actualizaciones pueden cambiar el tráfico de Discover.
• Cambios del producto: Google afirma que su trabajo en Discover puede provocar cambios de tráfico sin relación con la calidad ni con la frecuencia de publicación del contenido.

El último punto corrige una creencia extendida. Publicar más artículos por semana no es una palanca documentada para Discover. Lo que sigue en manos del editor es lo que enumeran las directrices de Google: contenido oportuno, títulos claros, buenas imágenes grandes y una buena experiencia de página. Actualizar un artículo evergreen con información nueva y un dateModified real es legítimo cuando el contenido ha cambiado de verdad; cambiar solo la fecha no lo es.

Para planificar, trate un pico de Discover como un extra sobre el tráfico de búsqueda, no como una base sobre la que presupuestar.

#Como analizar el rendimiento en google search console y medir conversiones de discover

Search Console tiene un informe de rendimiento de Discover propio, dentro de Rendimiento. Google indica que muestra impresiones, clics y CTR del contenido que apareció en Discover en los últimos 16 meses, siempre que los datos alcancen un umbral mínimo de impresiones. Google no publica ese umbral. El informe incluye el tráfico de Chrome y, según la documentación, cubre el tráfico de Discover de un sitio en todas las superficies donde la gente usa Discover.

Qué mirar en el informe:

• Páginas con impresiones pero CTR bajo: compare sus imágenes y títulos con las pautas anteriores; un logotipo o una imagen con mucho texto es el primer sospechoso.
• Reparto por países: en sitios multilingües, compruebe que hreflang lleva a cada lector a su versión de idioma.
• Caída repentina a cero: revise Seguridad y acciones manuales en busca de una acción manual de Discover antes de cambiar nada en el sitio.

Google Analytics 4 no tiene un canal predeterminado para Discover, así que Search Console sigue siendo la referencia para los clics de Discover. Para saber si los lectores de Discover se suscriben a una newsletter o hacen pedidos en WooCommerce, tome las páginas de destino del informe de Discover y compare sus conversiones en GA4 en el mismo periodo. Si necesita ayuda con esta configuración, consulte a un especialista WordPress.