Regex no Search Console: o filtro que o relatório esconde

No relatório de desempenho do Search Console, os filtros padrão são "Contém", "Não contém" e "Correspondência exata". Eles resolvem a maioria dos casos, mas travam exatamente onde a análise fica interessante: separar perguntas de navegação, marca de não-marca dentro do mesmo termo, cauda longa de cauda curta, ou um grupo de URLs que segue um padrão e não uma lista fixa. Para esses casos existe uma quarta opção, no mesmo menu: "Personalizado (regex)" e seu par "Personalizado (não regex)".

O guia padrão do Search Console explica o que cada métrica do relatório significa — cliques, impressões, CTR, posição — mas não explica como filtrar esse relatório com expressões regulares, nem onde a sintaxe difere do regex que você já conhece de outra linguagem. Este texto cobre essa lacuna: o motor por trás do filtro, como isolar queries de pergunta, como separar marca de não-marca sem manter duas listas, como aproximar cauda longa por contagem de palavras, como agrupar URLs por padrão de caminho, e onde a sintaxe do Search Console rejeita algo que funcionaria em outro lugar.

O motor por trás do filtro: RE2, não PCRE

O campo de regex do Search Console não usa PCRE, o dialeto de PHP, Python ou dos editores de texto mais comuns. Ele usa RE2, a biblioteca de expressões regulares do Google, também usada no BigQuery. A diferença não é cosmética: RE2 garante tempo de execução linear em relação ao tamanho da entrada, e para isso recusa deliberadamente alguns recursos que existem em PCRE.

Na prática, um padrão copiado de outra ferramenta pode simplesmente não funcionar aqui, e o erro que a interface mostra — "expressão regular inválida" — não diz qual parte está errada. Vale conhecer o que RE2 aceita antes de escrever o padrão, não depois de ver o erro.

• Aceito: classes de caracteres [a-z0-9], quantificadores {n,m}, alternância com |, âncoras ^ e $, quantificadores não-gulosos *? e +?, fronteira de palavra \b e \B, classes Unicode como \p{L}.
• Não aceito: retrorreferências (\1, \2), lookahead (?=...) e (?!...), lookbehind (?<=...) e (?<!...), quantificadores possessivos, grupos condicionais.
• Consequência prática: não dá para escrever "a palavra X, mas só se não vier antes de Y" com lookahead — a alternativa é reformular o padrão ou aceitar um resultado mais amplo e refinar depois de exportar.

Isolando queries de pergunta

Queries em formato de pergunta ("como recuperar senha", "o que é core web vitals", "por que meu site caiu no google") indicam intenção informacional e costumam ter CTR e posição diferentes do restante do inventário. "Contém" resolve uma palavra por vez — testar dez palavras interrogativas com dez filtros separados é o tipo de trabalho que regex existe para eliminar.

A alternância resolve isso em um único filtro, ancorado no início da string para evitar falso positivo no meio da frase (uma query como "isso é como funciona" contém "como", mas não começa por ela):

• ^(o que|como|por ?que|quando|onde|qual|quais|quem|quanto|quantos?|quantas?)\b
• O \b depois do grupo evita casar "comor" ou "ondear" como se fossem a palavra completa.
• Sem a âncora ^, o mesmo padrão passa a capturar qualquer query que contenha uma dessas palavras em qualquer posição — útil para o universo mais amplo, não só perguntas diretas.

Essa lista não é exaustiva por design: comece com as palavras mais frequentes no seu nicho e adicione variações conforme aparecerem nas queries reais.

Marca vs. não-marca sem manter duas listas

Separar tráfego de marca do restante costuma usar um "Contém" o nome da marca e um "Não contém" o mesmo termo — funciona enquanto a marca é uma palavra sem variação. Quebra quando há abreviação, erro de digitação comum, ou grafia com e sem espaço (marca fictícia "Auroria": as queries reais trazem "auroria", "auroria br", "auroria brasil" e, por erro de teclado, "aroria", sem o "u").

Um único padrão de alternância cobre as variantes de uma vez, e o inverso do mesmo padrão isola o não-marca sem escrever uma segunda expressão:

• Marca: \bauroria\b para casar o termo em qualquer posição da query.
• Não-marca: o mesmo padrão aplicado com "Personalizado (não regex)" em vez de "Personalizado (regex)" — não é preciso negar dentro da expressão.
• Variações: \b(auroria|auroria br|auroriabr)\b, somando cada grafia observada ao grupo de alternância.

O ponto de atenção é o \b nas duas pontas: sem ele, "auroria" também casaria com uma URL de coincidência como "auroriabrasileira", que não é tráfego de marca — é substring. A fronteira de palavra delimita onde a palavra começa e termina, não onde a substring aparece.

Aproximando cauda longa por contagem de tokens

Regex não sabe o que é "cauda longa" — é um conceito de distribuição e de intenção, não de sintaxe. O que regex faz é aproximar por número de palavras, o que na prática correlaciona bem: queries de três palavras ou menos tendem a ser mais genéricas, de cinco ou mais tendem a ser mais específicas.

O padrão para "pelo menos N palavras" usa um grupo repetido de "sequência de não-espaços seguida de espaço":

• ^(\S+\s+){4,}\S+$ casa queries com cinco palavras ou mais.
• Para "no máximo N palavras", aplique o padrão de "N+1 ou mais" com "Personalizado (não regex)" — RE2 não tem uma forma direta de expressar "no máximo" sem contar o total antes.
• Trocar o número entre chaves muda o corte: {2,} para três palavras ou mais, {6,} para sete ou mais.

A ressalva importa: o padrão conta tokens separados por espaço, não sílabas, e uma palavra muito longa isolada ainda conta como um token só. Trate isso como aproximação para cortar por tamanho, não como métrica de especificidade — olhar as queries reais que o filtro retorna continua necessário.

Agrupando URLs por padrão de caminho

A dimensão Página aceita o mesmo "Personalizado (regex)" da dimensão Consulta, e é onde o filtro rende mais quando o site tem estrutura de URL previsível. Em vez de comparar página por página, um padrão de caminho agrupa uma seção inteira do site em um único filtro.

Padrões que cobrem casos comuns de agrupamento:

• ^https://[^/]+/blog/ — todo o conteúdo dentro de /blog/, independente das subpastas depois dela.
• ^https://[^/]+/produto/[^/]+/?$ — páginas de produto de primeiro nível, excluindo categoria ou listagem com mais segmentos.
• \?.*utm_ — qualquer URL com parâmetro de campanha, separando tráfego de link com parâmetro do tráfego para a URL limpa.
• /(pt|pt-br)/|/en/ — comparar duas versões de idioma do mesmo conteúdo, quando a estrutura usa subpastas de idioma.
• /page/[0-9]+/?$ — páginas de paginação de blog ou categoria, que em geral vale excluir de uma análise de conteúdo principal.

O mesmo cuidado se aplica aqui: um padrão sem ancoragem no início casa com a substring em qualquer posição da URL — às vezes é o que você quer, às vezes produz falso positivo, como um parâmetro que contém "produto" por coincidência sem ser uma página de produto real.

Limites de sintaxe e como combinar filtros

Além dos recursos que RE2 não aceita, há limites de comportamento que pegam quem já usou regex em outro contexto. O primeiro: o Search Console combina filtros de dimensões diferentes sempre com E lógico — um filtro de Consulta mais um de Página retorna a interseção, nunca a união. Não existe, na interface, uma forma de dizer "esta consulta OU esta página".

Dentro de uma mesma dimensão, a interface permite só um filtro de regex por vez — mas a alternância dentro do próprio padrão (o | usado nas seções anteriores) já cobre o caso de "isto ou aquilo" sem precisar de um segundo filtro.

• A correspondência é parcial por padrão, então um padrão sem ^ ou $ funciona como "contém em algum lugar" — equivalente a .* nas duas pontas em outros motores, só que aqui já é o padrão.
• O filtro não diferencia maiúsculas de minúsculas — evita ter que escrever [Aa]uroria, mas também significa que não há como restringir a um caso específico de capitalização.
• Padrões muito longos, principalmente alternâncias com muitas variantes, podem ser rejeitados sem uma mensagem específica sobre o motivo. Divida em dois filtros aplicados em momentos diferentes em vez de insistir numa expressão gigante.

Acentos, maiúsculas e outras pegadinhas do português

O Search Console ignora a diferença entre maiúsculas e minúsculas, mas não ignora acentos. "nao" e "não" são strings diferentes para o motor, e um padrão que cobre só uma das duas grafias perde parte real do inventário — porque uma fração relevante das pessoas digita sem acento, seja por teclado, autocomplete do celular ou hábito.

Isso pesa mais em português do que em inglês, e é o tipo de detalhe que passa direto para quem aprendeu regex num contexto que não precisava lidar com isso. A correção é manual: escrever uma classe de caracteres que aceite a letra com e sem acento onde isso é esperado.

Sinal rápido de alerta: se um padrão retorna um número de queries visivelmente menor do que a intuição sugere, a primeira suspeita é acento ou cedilha faltando na expressão, não um problema com o RE2.

• Em vez de \bnão\b, usar \bn[aã]o\b para casar as duas grafias.
• Para uma palavra com vogal acentuada, como "página", a classe cresce: p[áa]gina.
• O mesmo vale para cedilha e til: "promocao" vs "promoção", "manutencao" vs "manutenção" — revise qualquer padrão de marca ou categoria com essas letras antes de confiar no volume que ele retorna.

Um fluxo de trabalho para não reescrever o padrão a cada vez

O caminho mais eficiente não é abrir direto no regex. Comece com os filtros simples — "Contém" para um recorte rápido — e suba para regex só quando a fronteira entre dois grupos for ambígua o suficiente para "Contém" produzir falso positivo ou perder casos reais. É o sinal mais confiável de que vale a complexidade extra.

Depois de montar o filtro de regex que isola o grupo desejado, combine com um segundo filtro de dimensão diferente para cruzar as duas perguntas — por exemplo, queries de pergunta (Consulta) restritas a um grupo de URL específico (Página), lembrando que a combinação é sempre E lógico entre dimensões diferentes.

Duas limitações valem ter em mente antes de tirar conclusões de volume: a tabela do relatório não expõe o inventário completo quando o site tem volume grande, mesmo com o filtro certo aplicado — parte real do total nunca aparece na tela. E não existe forma nativa de salvar um padrão de regex como reutilizável entre relatórios; cada sessão de análise recomeça do filtro em branco. Quando a complexidade ultrapassa o que a interface entrega — cruzar três dimensões ao mesmo tempo, ou trabalhar sobre o histórico completo sem o corte de linhas — a rota é a exportação de dados do Search Console para o BigQuery, que devolve os mesmos dados no nível de consulta sem a amostragem da interface, e onde RE2 continua sendo o motor de regex disponível nas consultas, preservando os mesmos padrões escritos para a interface.