Otimização de pesquisa por voz: Schema para liderar em 2026

A pesquisa por voz deixou de ser uma funcionalidade experimental e passou a ser mais um canal de descoberta: colunas inteligentes no escritório, assistentes no automóvel e auriculares ligados ao telemóvel. O utilizador faz uma pergunta e ouve uma resposta, sem lista de ligações para percorrer.

Para quem gere plataformas WordPress empresariais, a mudança é estrutural. Em vez de competir apenas pela primeira página visual, o objetivo passa a ser a resposta curta que um assistente consegue ler em voz alta. Esse objetivo tem limites concretos, documentados por Google, Apple e Amazon, e este guia separa o que essas plataformas prometem por escrito daquilo que é apenas boa prática editorial.

Conheça em detalhe os nossos serviços de SEO e GEO orientados para motores de resposta e assistentes de inteligência artificial.

#Como os agentes de IA mudaram a pesquisa por voz

A primeira geração de assistentes limitava-se a pesquisar uma palavra-chave e a ler o primeiro resultado. Hoje, vários produtos funcionam como agentes conversacionais apoiados em modelos de linguagem:

• Síntese contextual: o agente não lê parágrafos inteiros; analisa documentos e extrai a resposta mais concisa e verificável.
• Atribuição da fonte: no único caso documentado pela Google (Speakable para notícias), o assistente identifica a fonte quando lê o excerto e envia o URL completo do artigo para o telemóvel do utilizador. Fora desse caso, nenhuma plataforma promete uma menção sonora à sua marca.
• Diversidade de dispositivos: consumo em veículos, wearables e domótica, onde o utilizador não navega listas de hiperligações.

#Porque é que já não é possível criar uma ação própria para o Google Assistant

Durante alguns anos, a forma de “estar” no Google Assistant era construir uma Conversational Action, uma aplicação de voz com intents, cenas e webhooks. Essa via fechou: a documentação da Google para programadores indica que as Conversational Actions foram descontinuadas a 13 de junho de 2023. Qualquer artigo que ainda recomende criar uma ação de voz para o Assistant está desatualizado.

Na prática, sobram três caminhos para um site WordPress: ser uma fonte que os sistemas de pesquisa conseguem rastrear e citar, marcar excertos com Speakable onde a Google o suporta, e publicar conteúdo em formatos que um assistente consome diretamente, como o feed de flash briefing da Alexa descrito mais abaixo. Um endpoint REST próprio “para assistentes de voz” não tem hoje nenhum consumidor documentado, por isso não o recomendamos como investimento.

#O que a Google promete realmente com Speakable

A propriedade speakable é a peça mais citada em guias de pesquisa por voz e também a mais mal descrita. A página oficial Speakable (Article, WebPage) structured data é curta e clara:

• Está em beta. A Google avisa que requisitos e diretrizes podem mudar.
• Funciona num só mercado. A documentação diz que a propriedade funciona para utilizadores nos EUA com dispositivos Google Home configurados em inglês, e para editores que publicam conteúdo em inglês.
• Serve notícias. O Google Assistant usa Speakable para responder a consultas sobre notícias de atualidade em colunas inteligentes, devolvendo até três artigos de diferentes publicações.
• Atribui e reencaminha. Quando lê uma secção marcada, o Assistant identifica a fonte e envia o URL completo do artigo para o telemóvel do utilizador através da app Google Assistant.

“Para uma experiência de áudio ideal, recomendamos cerca de 20 a 30 segundos de conteúdo por secção de dados estruturados speakable, ou aproximadamente duas a três frases.”

Google Search Central, documentação Speakable (tradução própria)

As diretrizes técnicas acrescentam pormenores que quase nenhum tutorial menciona. Não marque datelines (o local onde a notícia foi escrita), legendas de fotografias nem atribuições de fonte, porque soam confusos em áudio. Use cssSelector ou xPath, nunca os dois na mesma especificação. E, como em todos os dados estruturados, a Google não garante que a funcionalidade apareça.

Consequência prática para um site em português: Speakable não produz hoje nenhum resultado de voz para páginas em pt-PT nem para utilizadores em Portugal. Marcar um resumo não prejudica, mas não o trate como interruptor de “voz SEO” nem prometa a um cliente resultados de voz com base nele. O que transfere para outros mercados e assistentes é a disciplina editorial que a Google pede: resumos curtos, frases autónomas, nada que dependa de uma imagem para fazer sentido.

#Como implementar Speakable schema no WordPress

A Google documenta speakable como dados estruturados para Article e WebPage. A propriedade aponta seletores CSS (ou XPath) para fragmentos candidatos a leitura em voz. A definição de referência está em schema.org/SpeakableSpecification.

#Quando usar Speakable schema e quando evitar

Use Speakable com cautela:

• Útil em artigos noticiosos em inglês com um resumo curto, factual e estável, marcado com um ID único (#resumo-executivo).
• Pouco útil se marcar a página inteira, blocos longos, CTAs comerciais ou texto que muda a cada deploy.
• Limitado por mercado e idioma: fora dos EUA e do inglês, a marcação não tem efeito documentado.
• Complementar, não substituto: a qualidade da resposta sob o H2 importa mais do que o JSON-LD sozinho.

#Exemplo de JSON-LD com Speakable

<!-- Exemplo de JSON-LD com Speakable Schema para WordPress -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "headline": "Otimização de pesquisa por voz: Schema para liderar em 2026",
  "url": "https://wppoland.com/pt-pt/voice-search-seo-wordpress-guide-2026-pt-pt/",
  "inLanguage": "pt-PT",
  "speakable": {
    "@type": "SpeakableSpecification",
    "cssSelector": [
      "#resumo-executivo",
      ".faq-answer"
    ]
  },
  "author": {
    "@type": "Organization",
    "name": "WPPoland",
    "url": "https://wppoland.com"
  }
}
</script>

#Como adicionar Speakable via functions.php sem plugin

Para não depender de plugins pesados, pode adicionar speakable no cabeçalho com o hook wp_head:

add_action('wp_head', 'adicionar_speakable_schema_personalizado');

function adicionar_speakable_schema_personalizado() {
    if (!is_singular('post')) {
        return;
    }

    $post_id = get_the_ID();
    $permalink = get_permalink($post_id);
    $titulo = get_the_title($post_id);

    $schema = [
        '@context'    => 'https://schema.org',
        '@type'       => 'Article',
        'headline'    => esc_html($titulo),
        'url'         => esc_url($permalink),
        'inLanguage'  => 'pt-PT',
        'speakable'   => [
            '@type'       => 'SpeakableSpecification',
            'cssSelector' => ['#introduction', '.resposta-direta-voz'],
        ],
    ];

    echo '<script type="application/ld+json">' . wp_json_encode($schema, JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE) . '</script>' . "\n";
}

Notas práticas no WordPress: garanta que os seletores existem no HTML renderizado (Gutenberg, blocos reutilizáveis ou o tema) e escape sempre a saída. O teste de resultados avançados da Google não lista Speakable entre os tipos que reporta, por isso valide a sintaxe no Schema Markup Validator. Se um plugin SEO já emite Article, funda speakable nesse nó em vez de duplicar @type Article na mesma página.

#Que tipos de intenção existem nas pesquisas por voz

A diferença decisiva não é o microfone: é a intenção. Quem digita “cache wordpress redis” está a explorar. Quem diz “como configuro object cache Redis no WordPress sem partilhar sessão entre lojas” quer um procedimento agora.

Três padrões de intenção falada merecem tratamento editorial distinto:

1. Procedimental (“como…”, “quais os passos…”): responde com um bloco curto e passos numerados visíveis.
2. Definição ou comparação (“o que é…”, “qual a diferença entre…”): um parágrafo factual de duas ou três frases, sem preâmbulo.
3. Local ou operacional (“perto de mim”, “em Lisboa”, “hoje”): depende de NAP consistente e de schema de negócio local, não só de um artigo longo.

No Search Console, filtre consultas que começam por “como”, “o que”, “qual”, “onde” e “quando”. Essas séries aproximam o vocabulário falado melhor do que uma lista de keywords de duas palavras. Depois, reescreva H2 e H3 com a pergunta real e coloque a resposta útil na primeira frase.

#O que mudou nos rich results FAQ e HowTo desde 2023

FAQ e HowTo continuam a ser formatos naturais para intenção falada no texto da página, mas os resultados visuais da Google mudaram. A 8 de agosto de 2023, a Google anunciou no blogue Search Central alterações aos rich results HowTo e FAQ:

• FAQ: os rich results de FAQPage passaram a aparecer apenas para sites governamentais e de saúde conhecidos e com autoridade. Para os restantes sites deixaram de ser mostrados regularmente.
• HowTo: primeiro ficaram limitados ao desktop; a 13 de setembro de 2023 a Google deixou também de os mostrar no desktop e declarou o tipo descontinuado.
• Marcação existente: a Google diz que não é preciso remover os dados estruturados, porque marcação não utilizada não causa problemas, mas também não tem efeito visível na pesquisa.

O critério seguro passa a ser editorial: escreva perguntas e passos no corpo da página porque respondem ao leitor e ao assistente que extrai texto, não porque esperam um enriquecimento visual. Se mantiver JSON-LD de FAQ ou HowTo, ele tem de espelhar o conteúdo visível, sem perguntas que a página não responde.

• Perguntas frequentes: um H2 ou H3 com a pergunta exata e uma resposta curta no DOM. Ideal para “o que é”, “quando usar”, “qual a diferença”.
• Procedimentos: passos numerados visíveis, ferramentas e tempo realistas. Ideal para “como ativar object cache”.
• Evite: FAQs geradas só para markup, respostas vazias, ou procedimentos com um único passo genérico.

#Como otimizar featured snippets para respostas por voz

Os featured snippets da Google invertem o formato habitual do resultado: mostram primeiro o excerto descritivo e depois a ligação. A lógica editorial é a mesma que serve um assistente: pergunta no título, resposta direta no primeiro parágrafo, aprofundamento a seguir. Não existe marcação para pedir um featured snippet; a Google escolhe o excerto a partir do texto.

Padrão recomendado por secção:

1. H2 formulado como a pergunta falada.
2. Parágrafo de 40 a 60 palavras com sujeito, verbo e conclusão clara.
3. Lista, tabela ou procedimento para quem continua a ler no ecrã.

Não force snippets com truques de formatação. O texto tem de ser correto e citável; um excerto errado danifica a marca quando é lido em voz alta.

#Como controlar o que os assistentes podem citar

O outro lado da otimização é decidir o que não deve ser lido. A documentação da Google sobre a meta tag robots e o atributo data-nosnippet define três controlos que se aplicam também a superfícies de voz e de IA:

• nosnippet impede qualquer excerto de texto da página nos resultados. A Google indica que isto abrange pesquisa web, Imagens, Discover, AI Overviews e AI Mode, e que o conteúdo deixa de servir de entrada direta para AI Overviews e AI Mode.
• max-snippet:[número] limita o excerto a um número de caracteres. A lista de superfícies abrangidas inclui o Assistant, e o limite também restringe quanto texto pode entrar diretamente em AI Overviews e AI Mode.
• data-nosnippet é um atributo HTML aplicado a elementos span, div ou section para excluir partes concretas da página dos excertos.

Num site WordPress, isto resolve casos reais. Uma tabela de condições comerciais que muda todas as semanas, um aviso jurídico ou um bloco de exemplo propositadamente errado (“não faça assim”) podem ficar dentro de data-nosnippet, enquanto o parágrafo de resposta fica disponível. Atenção à hierarquia: se a página tiver nosnippet e data-nosnippet ao mesmo tempo, nosnippet prevalece e não há excerto nenhum. Um max-snippet demasiado baixo também afasta a página dos featured snippets, por isso use-o só onde perder esse formato é aceitável.

#Como estruturar conteúdo para pesquisa por voz

O sistema de síntese procura respostas com precisão sintática. Aplique a pirâmide invertida em cada secção:

#Como escrever títulos H2 e H3 em forma de pergunta

Em vez de “Metodologias de caching”, use formulações que um profissional coloca ao assistente:

• “Como funciona o Object Cache no WordPress”
• “Qual é a diferença entre Redis e Memcached para WooCommerce”

#Como escrever a resposta logo abaixo do título

Imediatamente a seguir ao título, um parágrafo conciso, sem rodeios.

• Exemplo recomendado: “O Object Cache no WordPress guarda o resultado de consultas repetidas à base de dados em memória, através de Redis ou Memcached. Isto reduz o tempo de geração de página em sites com muito tráfego dinâmico, desde que a sessão e o cache de objetos estejam corretamente isolados.”
• O que evitar: “Neste artigo vamos explorar as várias formas de analisar este tópico.” Os assistentes ignoram preâmbulos sem factos.

#O que escrever depois da resposta curta

Depois da resposta curta, desenvolva nuances, exceções e configuração. No caso Speakable, a Google envia o URL do artigo para o telemóvel; noutros casos o utilizador abre a página mais tarde. Em ambos, a página completa tem de servir quem quer o detalhe.

#Como a Siri encontra conteúdo da web

A Apple não publica um equivalente ao Speakable. O que documenta é o seu rastreador. Segundo a página de suporte About Applebot, os dados recolhidos pelo Applebot alimentam várias funcionalidades da Apple, entre elas a Siri, o Spotlight e o Safari. Para um site WordPress, isto traduz-se em quatro regras verificáveis:

1. Não bloqueie o Applebot sem querer. O Applebot respeita diretivas do robots.txt dirigidas a ele. Se o ficheiro não tiver regras para o Applebot mas tiver regras para o Googlebot, o Applebot segue as do Googlebot. Um bloqueio pensado só para o Google pode afastar o site da Siri.
2. Crawl-delay não funciona com o Applebot. Se precisa de limitar a carga, faça-o no servidor ou na CDN.
3. Applebot-Extended não é um rastreador. Serve apenas para indicar se o conteúdo recolhido pelo Applebot pode ser usado para treinar os modelos de fundação da Apple. Páginas que bloqueiam o Applebot-Extended continuam elegíveis para resultados de pesquisa, e a Apple diz que essas regras não contam para o ranking.
4. Recusar treino não retira o site da Siri. Mesmo com Applebot-Extended bloqueado e nosnippet aplicado, a Apple afirma que o conteúdo continua a poder ser descoberto através do Spotlight, da Siri e do Safari.

Antes de editar o robots.txt num plugin SEO, confirme no ficheiro servido em produção (não apenas no ecrã de configuração) que o Applebot tem o acesso que pretende.

#Como publicar um flash briefing da Alexa a partir do WordPress

A Amazon oferece um caminho que não depende de rankings: o Flash Briefing Skill API. Segundo a documentação da Amazon, um flash briefing entrega aos clientes da Alexa títulos de notícias e outros conteúdos curtos, em texto ou áudio, a partir de um feed HTTPS em RSS ou JSON. O conteúdo pode ser atualizado no máximo a cada 15 minutos e tem de ser atualizado pelo menos uma vez por dia.

A referência do feed fixa regras que um editor WordPress tem de respeitar:

• Texto lido por síntese de voz: o campo mainText (ou description em RSS) é o texto que a Alexa lê ao cliente.
• Menos de 4500 caracteres por item: acima disso, o texto é cortado na frase mais próxima abaixo do limite.
• Só texto simples: sem SSML, HTML ou XML. Conteúdo de um post WordPress tem de passar por wp_strip_all_tags().
• Pontuação controla as pausas: vírgulas e pontos e vírgulas dão pausas curtas; pontos, pontos de interrogação e de exclamação dão pausas longas. A Amazon desaconselha pontuação fora do padrão.
• Frescura: a Alexa ignora itens com data anterior a 7 dias, e os itens devem estar ordenados do mais recente para o mais antigo.
• Ligação “Read More”: redirectionUrl aponta para o artigo na app Alexa.

Um endpoint REST mínimo que gera o feed JSON a partir dos últimos posts:

add_action('rest_api_init', function () {
    register_rest_route('briefing/v1', '/feed', [
        'methods'             => 'GET',
        'callback'            => 'wppoland_alexa_briefing_feed',
        'permission_callback' => '__return_true',
    ]);
});

function wppoland_alexa_briefing_feed() {
    $items = [];
    foreach (get_posts(['numberposts' => 5, 'date_query' => [['after' => '7 days ago']]]) as $post) {
        $items[] = [
            'uid'            => 'urn:wp:post:' . $post->ID,
            'updateDate'     => get_post_modified_time('Y-m-d\TH:i:s\Z', true, $post),
            'titleText'      => get_the_title($post),
            'mainText'       => mb_substr(wp_strip_all_tags(get_the_excerpt($post)), 0, 4400),
            'redirectionUrl' => get_permalink($post),
        ];
    }
    return rest_ensure_response($items);
}

O excerto manual de cada post passa a ser o texto falado, por isso vale a pena escrevê-lo como as secções Speakable: duas ou três frases autónomas, sem abreviaturas que a síntese de voz leia letra a letra.

#Como melhorar o TTFB no WordPress para pesquisa por voz

Um assistente em diálogo contínuo não tem a paciência de um utilizador a olhar para um indicador de carregamento, e uma página lenta também atrasa quem abre o URL no telemóvel depois da resposta. Nenhuma plataforma de voz publica um limite de TTFB para escolher fontes, por isso use a referência pública: o artigo Time to First Byte do web.dev indica, como guia aproximado, que um TTFB bom é de 0,8 segundos ou menos e que valores acima de 1,8 segundos são fracos. O mesmo artigo lembra que o TTFB não é uma métrica Core Web Vitals.

#Checklist para reduzir o TTFB no WordPress

A documentação de performance no WordPress cobre caching, object cache e higiene de plugins. Checklist operacional:

1. Cache de página na edge (Cloudflare ou equivalente) para HTML público estável.
2. Object cache (Redis ou Memcached) para consultas repetidas; isole sessões WooCommerce.
3. HTML semântico leve: menos nós desnecessários, menos JS bloqueante na rota crítica.
4. CDN de assets e imagens modernas (AVIF ou WebP) para quem abre a página no telemóvel.
5. Medição: WebPageTest ou dados CrUX para o TTFB por região (Portugal e mercados onde a audiência fala consigo).

Meça o seu stack contra esses limiares e compare com os concorrentes que já aparecem como resposta no seu nicho, em vez de perseguir números sem fonte.

#Como otimizar o SEO local para pesquisa por voz

Muitas consultas faladas em telemóvel são geográficas (“onde encontrar uma agência de desenvolvimento WordPress perto de mim”, “suporte WordPress em Lisboa”).

Para estas intenções:

• Alinhe Nome, Morada e Contacto (NAP) com o Perfil de Empresa da Google, o Apple Maps e outros mapas relevantes.
• Use LocalBusiness (ou tipo mais específico) com geo e openingHoursSpecification coerentes com a realidade.
• Páginas de localização com referências urbanas úteis aos assistentes de navegação, sem inventar filiais.

#Como medir resultados da pesquisa por voz

A voz quase não aparece como canal limpo no analytics. Proxies úteis:

• Featured snippets e People Also Ask no Search Console para as perguntas-alvo.
• Consultas em forma de pergunta filtradas no relatório de desempenho.
• Presença em motores de resposta: testes manuais regulares a um conjunto fixo de perguntas do nicho.
• Pedidos ao feed de flash briefing nos logs do servidor, se publicar um.
• Tráfego de marca direto após campanhas: correlacione com datas, sem atribuir causa sem evidência.

#Conclusão

Ao conjugar respostas diretas, schema honesto (Speakable só onde a Google o suporta, FAQ e procedimentos alinhados ao DOM), controlo de excertos e TTFB medido, a instalação WordPress fica preparada para ser citada, no ecrã e em áudio.

Priorize um conjunto pequeno de páginas âncora (guias técnicos e respostas do produto) antes de marcar o arquivo inteiro. Valide seletores, teste as perguntas-alvo em voz real no telemóvel e só depois escale o padrão ao resto do site.