Como funciona o novo assistente do google discover e como otimizar o wordpress para feeds personalizados

#Como funciona o novo assistente do google discover e como otimizar o wordpress para feeds personalizados

O Google Discover é o feed de artigos e vídeos que a aplicação Google mostra no Android e no iOS sem que o utilizador escreva uma pesquisa. Em outubro de 2026 a palavra “concierge” começou a circular associada a ele, por isso vale a pena separar o que a Google lançou daquilo para que ainda está a contratar pessoas. A 13 de outubro de 2026 o Search Engine Roundtable noticiou um anúncio de emprego da Google para Principal, UX, Search Discover, cujo objetivo declarado é transformar o Discover numa experiência de concierge proativa e hiperpersonalizada. Trata-se de uma direção numa descrição de funções, não de um produto lançado. O que chegou de facto em 2026 foi o ajuste do feed em linguagem natural, anunciado no blogue da Google a 20 de agosto de 2026.

Para sites em WordPress e lojas WooCommerce a consequência prática é a mesma em ambos os casos. O Discover escolhe conteúdo do índice da Google por interesses, não por pesquisas, e um pequeno conjunto de condições técnicas decide se uma página pode sequer aparecer com um cartão de imagem grande. Este guia separa os factos confirmados da especulação e depois percorre o lado do WordPress: diretivas robots, imagens, feeds e WebSub, cache, marcação de entidades, dados estruturados do WooCommerce, Core Web Vitals e medição no Search Console.

#Qual e a diferenca entre o google discover concierge e o feed de notícias tradicional

O feed atual do Discover é uma superfície de recomendação. A documentação do Discover da Google descreve-o como conteúdo alinhado com aquilo que interessa a cada pessoa e nota que esses interesses mudam com o tempo. Não há pesquisa nem posição no sentido habitual: uma página é mostrada a alguém com interesses compatíveis, ou não é.

O rótulo concierge vem do anúncio no site de carreiras da Google. Segundo os excertos citados pelo Search Engine Roundtable, a função deve liderar o trabalho numa “experiência de concierge proativa e hiperpersonalizada”, “equilibrar as capacidades de IA colocando no centro as vozes e as fontes humanas” e “fazer evoluir os formatos do feed escalando formatos baseados em IA” (anúncio de emprego da Google citado pelo Search Engine Roundtable, tradução própria). Isto descreve uma intenção e um mandato de recrutamento. Não refere tipos de cartão, fontes de dados nem data de lançamento, e a Google não publicou qualquer documentação para programadores sobre um modo concierge. Qualquer texto que explique como o concierge ordena conteúdos, que sinais do Calendário ou do Maps lê ou que formatos de cartão gera está a adivinhar.

A alteração confirmada é mais pequena e já chegou aos utilizadores. Numa publicação no blogue da Google datada de 20 de agosto de 2026, Mrinalini Loew, General Manager do Google Search Ecosystem, escreveu que “nos próximos dias, na aplicação Google, será possível tocar em qualquer menu de três pontos do feed para dizer à Google, por palavras suas, exatamente que temas ou links quer ver mais (ou menos)” e que “o feed ajusta-se de imediato e lembra-se desses pedidos” (Mrinalini Loew, Google, tradução própria). Antes disso, os utilizadores orientavam o feed sobretudo com os controlos de seguir e de “não tenho interesse”.

Para os editores isto tem um significado concreto. Um leitor pode agora descrever um interesse por palavras simples, até um subtema estreito, e o feed deve respeitá-lo. Conteúdo que diz com clareza do que trata, no título, nos cabeçalhos e na imagem principal, é mais fácil de associar a esse pedido do que um título vago ou de clickbait. As diretrizes da Google para o Discover já pedem títulos de página e cabeçalhos que captem a essência do conteúdo. O controlo em linguagem natural torna esse conselho mais concreto, mas não o substitui.

#Que requisitos tecnicos deve um site wordpress cumprir para aparecer no google discover

Não existe registo para o Discover. A documentação da Google afirma que o conteúdo é automaticamente elegível para aparecer no Discover se estiver indexado pela Google e cumprir as políticas de conteúdo do Discover, que não são necessárias etiquetas especiais nem dados estruturados e que a elegibilidade não garante a apresentação. O primeiro requisito é, portanto, a indexabilidade comum: a página devolve 200, não está bloqueada no robots.txt, não tem noindex e tem um URL canónico que aponta para si própria ou para a versão que quer indexar.

O segundo requisito diz respeito às pré-visualizações grandes de imagem. A Google indica a definição robots max-image-preview:large, ou AMP, como condição para imagens grandes no Discover. Sem ela, uma página pode continuar a aparecer, mas apenas com uma miniatura pequena. A diretiva é esta:

<!-- Configuracao robots recomendada para o Google Discover na seccao head -->
<meta name="robots" content="index, follow, max-image-preview:large, max-snippet:-1, max-video-preview:-1" />

O núcleo do WordPress gera esta diretiva por predefinição desde a versão 5.7, através da função wp_robots_max_image_preview_large(), mas apenas quando a opção blog_public está ativa, ou seja, quando o site não pede aos motores de pesquisa para não o indexarem. Verifique primeiro a etiqueta <meta name="robots"> renderizada. Se um tema, um plugin de SEO ou um resto do ambiente de staging remover ou substituir o valor, um filtro em wp_robots no ficheiro functions.php do tema filho repõe-no com prioridade tardia:

<?php
/**
 * Assegurar diretivas robots para o Google Discover no WordPress
 */
function wppoland_assegurar_discover_robots_pt($robots) {
    $robots['max-image-preview'] = 'large';
    $robots['max-snippet'] = -1;
    $robots['max-video-preview'] = -1;
    return $robots;
}
add_filter('wp_robots', 'wppoland_assegurar_discover_robots_pt', 99);

O terceiro requisito é a própria imagem. A Google recomenda usar marcação schema.org ou a meta etiqueta og:image para indicar uma imagem grande, relevante e representativa da página, porque isso pode influenciar a imagem escolhida. Um og:image partido ou minúsculo não exclui por si só a página do Discover, mas tira-lhe o controlo sobre a imagem que a Google escolhe. A Google não documenta que campos Open Graph além da imagem o Discover lê, por isso a etiqueta HTML <title> e o título visível também têm de estar corretos, e não apenas as etiquetas Open Graph.

#Que conteúdos o google discover filtra e quando surgem ações manuais

O Discover tem políticas de conteúdo próprias, que se somam às políticas gerais da Pesquisa Google. A documentação enumera formatos que o Discover pode evitar mostrar: candidaturas a emprego, petições, formulários, repositórios de código e sátira sem contexto. Também filtra conteúdos que possam parecer chocantes ou inesperados a quem não os procurou. Um site WordPress que publique excertos de código como repositório, ou páginas de destino que são sobretudo formulários, não deve esperar ver esses URLs no Discover, seja qual for a sua qualidade.

As orientações sobre apresentação são concretas. A Google pede que se evite o clickbait, ou seja, usar detalhes enganadores ou exagerados na pré-visualização (título, excertos ou imagens) para aumentar o apelo, ou reter informação essencial para perceber de que trata o conteúdo. Pede também que se evite o sensacionalismo que explora a curiosidade mórbida, a provocação ou a indignação. Em alternativa, espera conteúdo oportuno face aos interesses atuais, que conte bem uma história ou traga perspetivas únicas.

Quando um site viola estas políticas, a Google indica que podem surgir ações manuais do Discover no Search Console, em Segurança e ações manuais. É o primeiro sítio a verificar se o tráfego do Discover desaparece por completo enquanto o tráfego de pesquisa se mantém estável. Uma ação manual do Discover não aparece como queda no relatório de desempenho da pesquisa na Web, por isso um site pode parecer saudável num relatório e estar excluído no outro.

Numa redação em WordPress isto traduz-se em três verificações antes de publicar: o título diz a que pergunta o artigo responde, a imagem de destaque mostra o tema em vez de um logótipo ou de uma faixa com texto, e o primeiro parágrafo cumpre o que o título promete.

#Porque são obrigatorias imagens com largura superior a 1200px e a diretiva max image preview large

O Discover é um feed visual, e a imagem decide quanto espaço ocupa um cartão. A documentação da Google indica a especificação das imagens grandes:

• Largura: pelo menos 1200 px.
• Resolução: mais de 300 000 píxeis no total.
• Proporção: 16x9.
• Definição robots: ativada por max-image-preview:large ou pelo uso de AMP.

A Google acrescenta dois avisos fáceis de ignorar em temas WordPress. Evite imagens genéricas, como o logótipo do site, na marcação schema.org ou em og:image, e é precisamente para o logótipo que muitos temas e plugins de SEO recorrem quando um artigo não tem imagem de destaque. E, para melhores resultados, evite imagens com muito texto nesses campos, o que exclui cartões de título com o cabeçalho em letra grande.

Um tamanho de imagem dedicado torna a regra dos 1200 px aplicável, em vez de depender do que cada editor carrega. O código abaixo regista um recorte de 1344 por 768, próximo de 16:9 e com cerca de 1,03 milhões de píxeis, e só gera as etiquetas de imagem Open Graph quando o ficheiro gerado chega realmente aos 1200 px:

<?php
/**
 * Registar formato de imagem dedicado ao Google Discover
 */
function wppoland_definir_tamanho_discover_pt() {
    add_image_size('discover-hero-pt', 1344, 768, true);
}
add_action('after_setup_theme', 'wppoland_definir_tamanho_discover_pt');

/**
 * Injetar imagem Open Graph com dimensoes exatas no head
 */
function wppoland_injetar_og_discover_pt() {
    if (is_singular('post')) {
        global $post;
        if (has_post_thumbnail($post->ID)) {
            $dados = wp_get_attachment_image_src(get_post_thumbnail_id($post->ID), 'discover-hero-pt');
            if ($dados && $dados[1] >= 1200) {
                echo '<meta property="og:image" content="' . esc_url($dados[0]) . '" />' . "\n";
                echo '<meta property="og:image:width" content="' . esc_attr($dados[1]) . '" />' . "\n";
                echo '<meta property="og:image:height" content="' . esc_attr($dados[2]) . '" />' . "\n";
                echo '<meta property="og:image:type" content="image/avif" />' . "\n";
            }
        }
    }
}
add_action('wp_head', 'wppoland_injetar_og_discover_pt', 5);

Duas notas práticas. O recorte só existe para imagens carregadas depois de o tamanho estar registado, por isso os artigos antigos precisam de miniaturas regeneradas, por exemplo com wp media regenerate no WP-CLI. E o WordPress não amplia uma imagem de origem mais pequena do que o recorte, razão pela qual o código verifica a largura real antes de gerar as etiquetas. Se as suas imagens não forem AVIF, altere o valor de og:image:type para o tipo real do ficheiro.

#Como implementar o protocolo websub no wordpress para indexacao em poucos segundos

A atualidade conta no Discover porque as diretrizes da Google pedem conteúdo oportuno face aos interesses atuais. Quanto mais cedo a Google souber que existe um URL novo, mais cedo o pode considerar. Os sitemaps funcionam, mas a Google obtém-nos segundo o seu próprio calendário. O WebSub é um mecanismo de envio: o editor avisa um hub de que um feed mudou, e o hub notifica os subscritores.

O WebSub, antes PubSubHubbub, é uma Recomendação W3C. A especificação define como o editor anuncia o seu hub: com cabeçalhos HTTP Link ou com elementos <link>, rel="hub" para o hub e rel="self" para o URL do próprio feed. Deixa deliberadamente em aberto a forma como o editor informa o hub. A especificação chama a esse mecanismo não especificado, e muitos hubs, incluindo o hub público da Google em https://pubsubhubbub.appspot.com/, aceitam um POST com hub.mode=publish e hub.url com o endereço do feed. A Google não documenta que um ping ao seu hub acelere a entrada de uma página no Discover, por isso trate o WebSub como forma de encurtar a descoberta do feed, e não como um interruptor do Discover.

O código abaixo envia o ping na publicação e acrescenta as ligações de descoberta ao feed Atom, sem plugin adicional:

<?php
/**
 * Notificar hub WebSub da Google na publicacao de novo artigo
 */
function wppoland_enviar_ping_websub_pt($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, // Execucao assincrona para nao atrasar a interface do editor
        '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_pt', 10, 2);

/**
 * Adicionar ligacoes do hub e self no cabecalho do feed Atom
 */
function wppoland_adicionar_ligacoes_atom_pt() {
    $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_adicionar_ligacoes_atom_pt');

Se preferir um plugin mantido, o diretório do WordPress.org inclui o WebSub (FKA. PubSubHubbub), que anuncia os hubs nos feeds e envia o ping de publicação. Não use o plugin e o código ao mesmo tempo, ou cada publicação envia dois pings.

O feed deve conter o texto completo de cada artigo, e não apenas um excerto. No WordPress isso é controlado pela opção rss_use_excerpt nas definições de leitura: com o valor 0 o feed Atom gera o texto completo no elemento <content>, e o feed RSS 2.0 usa <content:encoded>.

#Como configurar cabecalhos cache control e caching na cloudflare para feeds rss e atom

Quando hubs e robôs obtêm os feeds depois de cada publicação, cada pedido sem cache executa toda a pilha PHP do WordPress. Uma cache partilhada curta mantém o feed atualizado e protege o servidor de origem. No Nginx:

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

O mesmo cabeçalho pode ser definido a partir do WordPress:

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

Com max-age=300, uma CDN como a Cloudflare pode servir o feed durante até cinco minutos, e stale-while-revalidate=600 permite-lhe servir a cópia anterior enquanto obtém uma nova. Mantenha o TTL curto. Um feed em cache durante horas anularia o ping do WebSub, porque o hub obteria a versão desatualizada. Se guardar os feeds em cache no edge por mais tempo, limpe o URL do feed a cada publicação.

#Como construir autoridade tematica e associacao de entidades com a wikidata para personalização

O Discover associa conteúdo a interesses, e a Google descreve esses interesses em termos de temas, não de palavras-chave. A Google não publica a forma como o Discover associa páginas a temas, por isso o objetivo realista é tornar inequívoco o tema de cada página: cabeçalhos claros, terminologia coerente e dados estruturados que nomeiem as entidades principais.

Num site WordPress isso significa três coisas:

1. JSON-LD com about e mentions: ligue os temas principais a identificadores estáveis, como URLs da Wikidata ou da Wikipédia, para que “Discover” ou “WebSub” não se confundam com um termo diferente.
2. Autores como entidades Person: ligue os perfis de autor aos perfis que o autor mantém de facto, como LinkedIn ou GitHub, para que leitores e robôs vejam quem escreveu o conteúdo.
3. Clusters temáticos: publique artigos ligados sobre um tema e ligue-os entre si, para que a profundidade da cobertura fique visível.

Um exemplo de grafo:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "TechArticle",
      "@id": "https://wppoland.com/blog/como-funciona-o-novo-assistente-do-google-discover/#article",
      "isPartOf": {
        "@id": "https://wppoland.com/#website"
      },
      "headline": "Como funciona o novo assistente do google discover e como otimizar o wordpress para feeds personalizados",
      "description": "Manual tecnico sobre a arquitetura do assistente de IA do Google Discover e tecnicas de otimizacao em WordPress.",
      "inLanguage": "pt-PT",
      "mainEntityOfPage": "https://wppoland.com/blog/como-funciona-o-novo-assistente-do-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-o-novo-assistente-do-google-discover/#primaryimage",
        "url": "https://wppoland.com/images/digital-experience-platforms-dxp-vs-wordpress.avif",
        "width": 1344,
        "height": 768,
        "caption": "Otimizacao de WordPress para o 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>

Os dados estruturados não são um requisito do Discover; a Google afirma que não são necessárias etiquetas especiais. O seu valor aqui está em eliminar a ambiguidade sobre o tema da página e o seu autor.

#Como otimizar lojas woocommerce para recomendacoes proativas no google discover

A documentação do Discover não descreve cartões de produto nem qualquer funcionalidade específica do WooCommerce. O que uma loja controla é a qualidade dos dados de produto na Pesquisa Google em geral e o tipo de conteúdo que o Discover mostra de facto: artigos editoriais oportunos e úteis.

Três passos mantêm os dados de produto coerentes:

1. Preço e disponibilidade no schema: o WooCommerce gera dados estruturados do tipo Product; confirme que price, priceCurrency e availability coincidem com o que a página mostra.
2. GTIN: desde a versão 9.1 o WooCommerce tem no produto um campo para GTIN, UPC, EAN ou ISBN, e a sua classe de dados estruturados gera a propriedade gtin quando o valor é válido. A documentação da Google sobre fichas de comerciante inclui gtin entre os identificadores de produto que lê, por isso preencher este campo é melhor do que guardar o código num campo meta próprio.
3. Conteúdo editorial em torno dos produtos: guias de compra, comparações e relatos de testes encaixam nas diretrizes do Discover sobre conteúdo oportuno e com perspetiva própria. Listagens de produtos e páginas de categoria raramente encaixam.

A informação de devoluções entra na oferta através do filtro woocommerce_structured_data_product_offer. O WooCommerce guarda as ofertas como lista dentro da marcação do produto, por isso este filtro é o sítio certo para hasMerchantReturnPolicy, uma propriedade suportada pela documentação da Google sobre fichas de comerciante:

<?php
/**
 * Adicionar a política de devoluções ao schema da oferta do WooCommerce.
 * O WooCommerce 9.1+ já gera o gtin a partir do campo GTIN do produto.
 */
function wppoland_discover_return_policy($markup_offer, $product) {
    $markup_offer['hasMerchantReturnPolicy'] = [
        '@type' => 'MerchantReturnPolicy',
        'applicableCountry' => 'PT',
        '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);

Defina o país, o número de dias e os custos de acordo com as condições reais da loja. Dados estruturados que contradizem a política de devoluções visível são piores do que nenhuns.

#Que impacto tem as core web vitals e o inp inferior a 200ms na visibilidade no discover

As diretrizes do Discover pedem aos editores que ofereçam uma boa experiência de página no geral. As visitas do Discover acontecem em telemóveis, muitas vezes em rede móvel, por isso os dados de campo móveis são os que mais contam. Os limiares das Core Web Vitals publicados no web.dev são:

• LCP: 2,5 segundos ou menos.
• INP: 200 milissegundos ou menos. O INP substituiu o FID como Core Web Vital em março de 2024.
• CLS: 0,1 ou menos.

O web.dev recomenda medi-los no percentil 75 dos carregamentos de página, separando dispositivos móveis e computadores.

Num artigo do Discover, o elemento LCP é normalmente a imagem de destaque, a mesma imagem grande que o cartão mostra. Desde o WordPress 6.3 o núcleo acrescenta fetchpriority="high" à imagem que considera mais provável ser o elemento LCP e deixa de carregar em diferido as imagens acima do loop, como descrevem as notas sobre desempenho de imagens no WordPress 6.3. Em versões anteriores, ou com temas que geram a imagem de destaque fora das funções padrão, o código abaixo define os atributos de forma explícita:

<?php
/**
 * Otimizar LCP da imagem de destaque para o Google Discover
 */
function wppoland_otimizar_hero_discover_pt($content) {
    if (is_singular('post')) {
        add_filter('wp_get_attachment_image_attributes', function($attr, $attachment, $size) {
            if ($size === 'discover-hero-pt' || $size === 'post-thumbnail') {
                $attr['loading'] = 'eager';
                $attr['fetchpriority'] = 'high';
                $attr['decoding'] = 'async';
            }
            return $attr;
        }, 10, 3);
    }
    return $content;
}
add_action('wp', 'wppoland_otimizar_hero_discover_pt');

No WordPress 6.3 ou posterior, verifique o HTML renderizado antes de o adicionar: se o núcleo já marca a imagem, o filtro é redundante. No INP, as causas habituais em WordPress são scripts pesados de terceiros, sliders e faixas de consentimento que bloqueiam a thread principal durante as primeiras interações.

#Porque motivo o tráfego do google discover oscila bruscamente e como estabilizar o alcance

O tráfego do Discover costuma chegar em vagas: um artigo é mostrado amplamente durante pouco tempo e depois desvanece. A documentação da Google diz explicitamente que o tráfego do Discover é menos previsível e fiável do que as visitas da pesquisa por palavras-chave e que os editores o devem considerar complementar ao tráfego de pesquisa.

A Google aponta as razões para as variações:

• Interesses em mudança: o Discover mostra conteúdo alinhado com os interesses de cada pessoa, e esses interesses mudam.
• Tipos de conteúdo: o Discover ajustou e continua a ajustar os tipos de conteúdo que podem aparecer no feed.
• Atualizações da pesquisa: o Discover é uma extensão da Pesquisa, por isso as atualizações da pesquisa podem alterar o tráfego do Discover.
• Alterações do produto: a Google afirma que o trabalho no Discover pode provocar variações de tráfego sem relação com a qualidade nem com a frequência de publicação do conteúdo.

O último ponto corrige uma crença comum. Publicar mais artigos por semana não é uma alavanca documentada para o Discover. O que fica nas mãos do editor é o que as diretrizes da Google enumeram: conteúdo oportuno, títulos claros, boas imagens grandes e uma boa experiência de página. Atualizar um artigo intemporal com informação nova e um dateModified real é legítimo quando o conteúdo mudou de facto; mudar apenas a data não é.

No planeamento, trate um pico do Discover como um bónus acima do tráfego de pesquisa, e não como uma base para o orçamento.

#Como monitorizar o desempenho no google search console e medir conversoes do feed

O Search Console tem um relatório de desempenho do Discover próprio, em Desempenho. A Google indica que mostra impressões, cliques e CTR do conteúdo que apareceu no Discover nos últimos 16 meses, desde que os dados atinjam um limiar mínimo de impressões. A Google não publica esse limiar. O relatório inclui tráfego do Chrome e, segundo a documentação, cobre o tráfego do Discover de um site em todas as superfícies onde as pessoas usam o Discover.

O que ler no relatório:

• Páginas com impressões mas CTR baixo: compare as imagens e os títulos com as orientações acima; um logótipo ou uma imagem com muito texto é o primeiro suspeito.
• Distribuição por país: em sites multilingues, confirme que o hreflang envia cada leitor para a versão de idioma certa.
• Queda súbita para zero: verifique Segurança e ações manuais à procura de uma ação manual do Discover antes de alterar o que quer que seja no site.

O Google Analytics 4 não tem um canal predefinido para o Discover, por isso o Search Console continua a ser a referência para os cliques do Discover. Para ver se os leitores do Discover subscrevem uma newsletter ou fazem encomendas no WooCommerce, pegue nas páginas de destino do relatório Discover e compare as respetivas conversões no GA4 no mesmo período. Se precisar de ajuda com esta configuração, fale com um especialista em WordPress.