Por volta de setembro de 2025, várias ferramentas de SEO e scripts personalizados começaram a quebrar sem muito alarde. O motivo? O Google deixou de respeitar de forma confiável o parâmetro num=100, que durante anos permitiu aos usuários avançados carregar 100 resultados por página. Não houve aviso formal de descontinuação — só um porta-voz dizendo ao Search Engine Land que o parâmetro “não era oficialmente suportado”. No mesmo período, o Google passou a introduzir mais modos udm além dos antigos verticais tbm, anunciou que os domínios de código de país fariam redirecionamento gradual para google.com e informou que os AI Overviews já alcançavam mais de 2,5 bilhões de usuários mensais.
Se você vem montando URLs de busca, acompanhando rankings ou automatizando pesquisas com os parâmetros da URL do Google, é bem provável que alguns fluxos estejam sendo afetados sem você perceber. Na Thunderbit, revisamos a documentação atual do Google, anúncios recentes de mudanças, referências obtidas por engenharia reversa e testes práticos para separar controles estáveis de parâmetros mais contextuais. O resultado é um guia atualizado e validado em testes para os parâmetros da URL da Pesquisa Google que importam em 2026, incluindo mapeamentos tbm/udm, a fórmula de codificação uule para geolocalização em nível de cidade e conflitos de parâmetros que podem economizar horas de depuração.
O que são os parâmetros da URL da Pesquisa Google?

Os parâmetros da URL da Pesquisa Google são os pares chave=valor que aparecem depois do ? em uma URL de busca. Eles controlam desde o que você está pesquisando até de qual país vêm os resultados, além de definir se você verá imagens, notícias ou os tradicionais links azuis.
Uma URL típica da Pesquisa Google se divide assim:
https://www.google.com/search?q=best+crm+software&hl=en&gl=us&tbs=qdr:m
- URL base:
https://www.google.com/search ?inicia a string de consultaq=best+crm+softwareé a busca em si (espaços codificados como+)&separa cada parâmetrohl=endefine o idioma da interface como inglêsgl=usdiz ao Google para exibir resultados como se você estivesse nos EUAtbs=qdr:mfiltra para resultados do último mês
Vale uma distinção importante: operadores de pesquisa como site:, filetype: e intitle: vão dentro do valor de q=. Eles fazem parte da consulta. Já os parâmetros da URL como gl, hl e tbs são chaves separadas na URL que controlam como o Google processa e exibe os resultados. Ambos importam e funcionam em conjunto — mas não são a mesma coisa.
O Google nunca publicou uma especificação única e versionada desses parâmetros. Alguns vêm do formulário de Pesquisa Avançada, outros da API Custom Search, e outros foram descobertos por engenharia reversa observando as próprias URLs do Google. Isso significa que o artigo que você está lendo se baseia em testes reais e comportamento documentado, não em um contrato oficial de API.
Por que os parâmetros da URL da Pesquisa Google importam em 2026
Parâmetros de URL não são preocupação só de desenvolvedor. Qualquer pessoa de SEO, marketing, vendas, operações ou produto que precise entender o que o Google mostra para uma consulta específica, em um mercado específico, em um momento específico — esses parâmetros são sua caixa de ferramentas.
Resumo rápido de quem se beneficia e como:
| Caso de uso | Quem se beneficia | Parâmetros-chave |
|---|---|---|
| Acompanhamento de rankings de SEO por país | Equipes de SEO e Marketing | gl, hl, uule, pws |
| Monitoramento de concorrentes por data | Equipes de Estratégia e Operações | tbs, q com site: |
| Monitoramento de anúncios em mercados específicos | Equipes de mídia paga | gl, hl, udm |
| Auditorias de SEO local (nível de cidade) | Donos de negócios locais | uule, gl |
| Pesquisa de conteúdo / acompanhamento de tendências | Equipes de conteúdo | tbs (filtros de data), lr |
| Alimentar dados de busca em apps de IA/LLM | Equipes de Produto e Dados | Vários parâmetros + extração estruturada |
Três mudanças grandes tornam 2026 bem diferente:
num=100já não é confiável. O antigo truque de resultados por página parou de funcionar de forma consistente em setembro de 2025. O Google não o descontinuou formalmente; um porta-voz disse que ele nunca foi oficialmente suportado.- Redirecionamentos de ccTLD estão em migração, não concluídos. O Google anunciou em abril de 2025 que domínios de código de país (google.co.uk, google.de etc.) migrariam gradualmente para google.com. O Google não publicou um aviso de conclusão, então não presuma que todos os locais se comportem de forma idêntica ainda.
- Os AI Overviews mudaram a SERP. O Google afirma que os AI Overviews alcançaram mais de 2,5 bilhões de usuários mensais e mais de 200 países e territórios. Modos
udmobtidos por engenharia reversa podem alterar a superfície de resultados em alguns contextos, mas não são uma chave garantida para ativar AI Overviews.
Se seus fluxos não foram atualizados para essas mudanças, há grandes chances de você estar recebendo resultados degradados ou enganosos sem perceber.
Guia rápido dos parâmetros da URL da Pesquisa Google (2026)
Antes de mergulhar a fundo, a tabela de referência abaixo é a lista mais atual que consegui montar. Salve nos favoritos.
| Parâmetro | O que faz | Exemplo de valor | Status |
|---|---|---|---|
q | Consulta de pesquisa (suporta operadores dentro dela) | q=best+crm+software | ✅ Ativo |
hl | Idioma da interface | hl=en, hl=ja | ✅ Ativo |
gl | Contexto de país/mercado | gl=us, gl=jp | ✅ Ativo |
lr | Restringe resultados a um idioma de conteúdo | lr=lang_en | ✅ Ativo |
cr | Restringe resultados a um país de hospedagem | cr=countryUS | ✅ Ativo |
start | Paginação / offset | start=10 (página 2) | ✅ Ativo |
num | Resultados por página (antes) | num=100 | ⚠️ Não oficialmente suportado; instável desde set/2025 |
udm | Modo de conteúdo contextual | udm=14 (web clássico) | ⚠️ Obtido por engenharia reversa; varia conforme o contexto |
tbm | Vertical de pesquisa | tbm=isch (imagens) | ⚠️ Ainda observado; teste junto com udm |
tbs | Filtros de tempo, ordenação, modo literal | tbs=qdr:w | ✅ Ativo |
safe | Controle do SafeSearch | safe=active | ✅ Ativo |
filter | Filtro de resultados duplicados | filter=0 | ✅ Ativo (observado) |
nfpr | Desativa autocorreção | nfpr=1 | ✅ Ativo (observado) |
pws | Desativa personalização | pws=0 | ✅ Ativo |
uule | Geolocalização em nível de cidade/DMA | uule=w+CAIQICI... | ✅ Ativo (engenharia reversa) |
as_q, as_epq, as_eq, etc. | Campos do formulário de Pesquisa Avançada | Vários | ✅ Ativo |
as_sitesearch | Restringe a um domínio (Pesquisa Avançada) | as_sitesearch=example.com | ✅ Ativo |
as_filetype | Restringe a um tipo de arquivo (Pesquisa Avançada) | as_filetype=pdf | ✅ Ativo |
ie, oe | Codificação de entrada/saída | ie=UTF-8 | ✅ Ativo (raramente necessário) |
kgmid, si, ibp | Entidade do Knowledge Graph / visualização de recursos | Vários | ⚠️ Contextual (não para uso geral) |
ei, ved, sxsrf, sclient | Sessão/rastreamento/telemetria | Vários | 🔒 Interno (ignore) |
gbv | Visualização HTML básica (antes) | gbv=1 | ❌ Inconfiável em 2026 |
Remova ei, ved, sxsrf e sclient de qualquer URL que você salve ou compartilhe. Eles são estado de sessão e telemetria que o Google adiciona automaticamente — irrelevantes para construir URLs de busca.
Parâmetros principais da Pesquisa Google que ainda funcionam
Testei cada um deles ao vivo em meados de 2026. São os que você mais vai usar.
q — Sua consulta de pesquisa
O parâmetro q carrega os termos da sua busca. Os espaços são codificados como + ou %20. É aqui que vivem os operadores de pesquisa documentados pelo Google — eles entram dentro do valor de q, e não como parâmetros separados da URL.
Alguns exemplos:
- Frase exata:
q=%22google+search+url+parameters%22 - Restrito a um site:
q=site%3Aexample.com+pricing - Tipo de arquivo:
q=filetype%3Apdf+annual+report+2026 - Combinado:
q=site%3Acompetitor.com+intitle%3Apricing+after%3A2026%2F01%2F01
Sempre codifique toda a consulta na URL. Aspas, dois-pontos e barras precisam de codificação correta para não corromper a URL.
hl — Idioma da interface
hl controla o idioma da interface do Google (botões, rótulos, títulos de “As pessoas também perguntam”) e influencia quais resultados o Google prioriza. Ele usa códigos ISO 639-1 como en, fr, de, ja, ou tags BCP 47 como en-gb ou pt-br.
hl não força todos os documentos de resultado para esse idioma. É um sinal forte, mas o Google ainda pode exibir conteúdos em outros idiomas se forem muito relevantes. Para restringir pelo idioma do conteúdo, use lr.
gl — País / geolocalização
gl simula o país de onde você está pesquisando, usando códigos ISO 3166-1 alpha-2 (us, gb, jp, de). Com os ccTLDs migrando gradualmente para google.com, gl virou a principal forma de obter resultados específicos de país.
A mesma consulta com valores diferentes de gl pode retornar resultados, snippets em destaque e pacotes locais totalmente distintos. Por exemplo, q=best+bank&gl=us e q=best+bank&gl=jp vão mostrar bancos bem diferentes.
Dica: sempre combine gl com hl para obter resultados localizados com precisão. Usar gl=jp com hl=en mostra resultados do mercado japonês com interface em inglês — útil para auditorias internacionais de SEO.
lr e cr — restrição por idioma e por país
Esses dois parâmetros são constantemente confundidos. A diferença importa:
lr=lang_enrestringe os resultados a páginas escritas em inglês (idioma do conteúdo)cr=countryUSrestringe os resultados a páginas hospedadas nos Estados Unidos (localização do servidor / associação de país)gl=ussimula a busca a partir dos Estados Unidos (afeta ranking, resultados locais e anúncios)
Tanto lr quanto cr estão disponíveis no formulário de Pesquisa Avançada. Cuidado ao combiná-los — lr=lang_en + cr=countryJP significa “somente páginas em inglês hospedadas no Japão”, um conjunto bem restrito. Falaremos mais sobre isso na seção de conflitos.
start — Paginação
start=10 solicita resultados a partir da posição 11 (página 2), start=20 para a página 3 e assim por diante. Como num=100 já não é confiável, aumentar start em 10 é a opção mais segura por padrão — mas o Google ainda pode reescrever ou limitar a paginação.
O antigo truque num=100&start=0 para puxar uma página completa com 100 resultados não funciona mais. Se seus scripts ainda usam num, remova-o — ele está sendo ignorado silenciosamente.
pws — Desativar personalização
pws=0 solicita que o Google desligue a personalização baseada na conta. Isso é essencial para acompanhamento de rankings em SEO, quando você quer resultados que não sejam distorcidos pelo seu próprio histórico de buscas, cliques anteriores ou preferências da conta.
Um alerta: pws=0 reduz a personalização, mas não elimina todos os fatores contextuais. O Google diz que os resultados ainda podem variar conforme tempo, localização, idioma e dispositivo. Não existe uma SERP do Google realmente “neutra”.
safe e filter — SafeSearch e filtro de duplicados
safe=activeativa o SafeSearch;safe=offo desativa. Observe que configurações da conta, políticas de administrador, configurações de rede ou leis regionais podem sobrepor esse parâmetro.filter=0desativa o filtro de resultados duplicados do Google. Útil quando você quer ver todos os resultados que o Google tem, incluindo quase duplicados que normalmente seriam consolidados.
nfpr — Desativar autocorreção
nfpr=1 impede que o Google reescreva sua consulta à força quando acha que há um erro de digitação. Isso é útil para acompanhar termos de marca com grafias incomuns, jargões técnicos ou consultas com erros propositalmente usados por concorrentes.
Observe que nfpr=1 apenas bloqueia a reescrita forçada. Para um controle mais amplo — desativar expansão por sinônimos, correções ortográficas e outras modificações automáticas — use tbs=li:1 (modo literal), que explico na seção de tbs abaixo.
A migração de tbm para udm: o que mudou e o que usar agora
Essa é uma das maiores mudanças de parâmetros dos últimos anos — e uma das mais fáceis de exagerar.
tbm há muito tempo é uma forma comum de alternar entre verticais de busca do Google — imagens, notícias, vídeo, compras — há mais de uma década. O Google também introduziu um sistema numérico udm com modos sobrepostos e adicionais. Como o Google não publicou um registro estável para consumidores, trate isso como um mapeamento contextual, e não como uma substituição limpa e concluída.
Tabela completa de mapeamento de tbm para udm
Os mapeamentos abaixo combinam o comportamento observado da interface e testes ao vivo datados de 12 de agosto de 2026. Vários valores foram removidos ou reescritos em solicitações anônimas, então cada linha deve ser testada na conta, região e cliente em que será usada:
| Parâmetro antigo | Valor antigo | Novo parâmetro | Novo valor | Status |
|---|---|---|---|---|
tbm=lcl | Locais / mapas | udm=1 | Locais / mapas | ⚠️ Contextual |
tbm=isch | Imagens | udm=2 | Imagens | ⚠️ Contextual |
tbm=vid | Vídeos | udm=7 | Vídeos | ⚠️ Contextual |
tbm=nws | Notícias | udm=12 | Notícias | ⚠️ Contextual |
| — | — | udm=14 | Web clássico (sem AI Overviews) | 🆕 Novo, sem equivalente em tbm |
| — | — | udm=18 | Fóruns | 🆕 Novo, sem equivalente em tbm |
tbm=shop | Compras | udm=28 | Compras | ⚠️ Contextual |
tbm=bks | Livros | udm=36 | Livros | ⚠️ Contextual |
| — | — | udm=39 | Vídeos curtos | 🆕 Novo, sem equivalente em tbm |
| — | — | udm=50 | Modo AI Overview | 🆕 Novo, sem equivalente em tbm |
O Google não publicou um registro estável de udm — e isso é uma ressalva importante. Esses valores foram obtidos por engenharia reversa observando o comportamento da própria interface do Google. A aceitação da URL varia conforme conta, região, cliente, cookies e grupo de experimento. Nos testes que fiz, alguns valores de udm foram removidos em requisições HTTP anônimas, mas funcionaram bem em sessões interativas no navegador. Não presuma que todos os valores funcionem universalmente.
O que o udm=14 faz (e por que os SEOs adoram)
udm=14 virou quase um favorito de culto na comunidade de SEO. A Android Central descreveu isso como uma forma de pedir uma superfície clássica de resultados web sem AI Overviews. Em muitas sessões, ele produz uma SERP tradicional com links azuis, mas isso não é uma garantia oficial nem universal.
Por que isso importa? Se você faz acompanhamento de rankings ou auditorias de SEO, os AI Overviews podem empurrar resultados orgânicos para baixo da dobra e dificultar a avaliação das posições. udm=14 pode oferecer uma visão mais limpa quando o Google o respeita.
Ainda assim, udm=14 não é garantido em todos os contextos. Em verificações ao vivo de 12 de agosto de 2026, o Google às vezes removia ou reescrevia valores de udm dependendo do contexto da solicitação. O resultado varia conforme sessão, conta, região, cliente e grupo de experimento.
udm=50 foi observado em contextos de AI Mode/resultados de IA, mas não deve ser descrito como uma forma garantida de forçar um AI Overview para qualquer consulta.
O que fazer: atualizar seus fluxos de tbm para udm
Minha recomendação:
- Novas implementações: trate
udmcomo entrada experimental/contextual e crie fallbacks. - Fluxos existentes: suporte e teste tanto
tbmquantoudmonde fizer sentido, em vez de assumir que a migração está concluída. - Nunca combine os dois: quando
tbmeudmaparecem juntos na mesma URL, o comportamento fica imprevisível. Nos meus testes, às vezes o Google removia ambos e retornava uma consulta comum. Mais sobre isso na seção de conflitos.
A sintaxe completa de tbs: intervalos de data personalizados, ordenação por data e modo literal
tbs é um dos parâmetros mais poderosos do arsenal de URLs da Pesquisa Google, e a maioria dos guias mal chega na superfície. Ele lida com filtro temporal, ordenação por data, modo literal e muito mais — tudo em um único valor separado por vírgulas.
Filtros de tempo padrão
Valor de tbs | Significado | Exemplo de trecho da URL |
|---|---|---|
qdr:h | Última hora | &tbs=qdr:h |
qdr:d | Últimas 24 horas | &tbs=qdr:d |
qdr:w | Última semana | &tbs=qdr:w |
qdr:m | Último mês | &tbs=qdr:m |
qdr:y | Último ano | &tbs=qdr:y |
Esses são os básicos que a maioria dos guias cobre. Mas tbs pode fazer muito mais.
Intervalos de data personalizados
Precisa de resultados de uma janela temporal específica? Use a sintaxe cdr:1,cd_min:MM/DD/YYYY,cd_max:MM/DD/YYYY:
&tbs=cdr:1,cd_min:01/01/2026,cd_max:06/01/2026
Isso filtra os resultados para aqueles que o Google associa a datas entre 1º de janeiro e 1º de junho de 2026. É extremamente útil para pesquisa competitiva — por exemplo, “o que os concorrentes publicaram sobre preços no 1º trimestre de 2026?” Só lembre de codificar a URL completa, já que dois-pontos e barras precisam de codificação.
Observação prática: a associação de datas do Google nem sempre é precisa. A data mostrada nos resultados é a melhor estimativa do Google, não necessariamente a data real de publicação. Sempre confira a data na página de destino.
Ordenar por data e modo literal
Aqui entramos em um território que nenhum artigo concorrente cobre.
sbd:1 ordena os resultados por data (mais recentes primeiro). Sozinho, isso é útil, mas nada de extraordinário. O truque é que você pode combiná-lo com filtros de período em um único valor de tbs:
&tbs=qdr:m,sbd:1
Isso traz resultados do último mês, ordenados por data — do mais recente para o mais antigo. É a forma mais rápida de encontrar o que acabou de ser publicado sobre um tema. Eu uso essa combinação o tempo todo ao monitorar conteúdo de concorrentes.
li:1 ativa o modo literal — o equivalente na URL a clicar na ferramenta “Verbatim” da interface de busca do Google. O modo literal desativa autocorreção, expansão por sinônimos, mudanças ortográficas e outras modificações automáticas da consulta.
A diferença entre li:1 e nfpr=1 está no escopo:
nfpr=1: só suprime a reescrita forçada de ortografia/consulta (por exemplo, impede o Google de trocar “teh” por “the”)tbs=li:1: desativa todas as modificações automáticas — ortografia, sinônimos, termos relacionados, ajustes de personalização
Você pode até empilhar vários valores de tbs. Por exemplo, tbs=qdr:m,sbd:1,li:1 fornece resultados do último mês, ordenados por data, com correspondência literal. Nos meus testes, essa combinação funciona, embora eu recomende validar com suas consultas específicas, já que tbs é uma sintaxe não documentada.
Como criar um código uule para geolocalização em nível de cidade
Se gl é uma lente de nível país, uule é um microscópio de nível cidade. Para SEO local — checar como sua empresa aparece em Denver vs. Dallas, ou o que um usuário no distrito de Shibuya, em Tóquio, vê — gl sozinho não basta.
Nenhum artigo bem ranqueado explica de fato como construir um código uule — eles mencionam que o parâmetro existe e seguem em frente. A explicação completa vem a seguir.
Quando usar gl vs. uule vs. cr
| Parâmetro | Granularidade | Caso de uso típico | Precisa de codificação? |
|---|---|---|---|
gl=us | Nível de país | Simulação rápida de país | Não |
cr=countryUS | Nível de país (restrição) | Filtrar por país de hospedagem | Não |
uule=w+CAIQICI... | Nível cidade/DMA | Verificação de ranking local | Sim |
O algoritmo de codificação do uule (passo a passo)
O parâmetro uule usa um sinal codificado de local nomeado. A construção foi obtida por engenharia reversa, não documentada oficialmente pelo Google, mas amplamente validada pela comunidade de SEO.
A abordagem mais segura é codificar um pequeno payload em Protocol Buffers em vez de confiar no atalho mais copiado por aí (que pode falhar com caracteres não ASCII). Veja o processo:
- Obtenha o nome canônico da localidade no Google. O Google publica alvos geográficos com nomes canônicos por meio dos dados geográficos da Google Ads API. Exemplo:
New York,New York,United States - Codifique o nome em bytes UTF-8.
- Monte um pequeno payload protobuf com o nome e seu comprimento em bytes.
- Codifique o payload em base64url e adicione o prefixo
w+.
Aqui vai um trecho em Python que faz isso:
import base64
def encode_varint(value: int) -> bytes:
out = bytearray()
while True:
byte = value & 0x7F
value >>= 7
if value:
out.append(byte | 0x80)
else:
out.append(byte)
return bytes(out)
def build_uule(canonical_name: str) -> str:
name = canonical_name.encode("utf-8")
payload = b"\x08\x02\x10\x20\x12" + encode_varint(len(name)) + name
encoded = base64.urlsafe_b64encode(payload).decode().rstrip("=")
return "w+" + encoded
#Exemplo
print(build_uule("New York,New York,United States"))
#Saída: w+CAIQICIeTmV3IFlvcmssTmV3IFlvcmssVW5pdGVkIFN0YXRlcw
Ao colocar isso numa URL, garanta que o + literal em w+ seja corretamente codificado como %2B pela sua biblioteca de URL. A maioria das implementações de URLSearchParams ou urllib.parse.urlencode faz isso automaticamente.
Um uule construído corretamente ainda é apenas um sinal de localização. Ele não substitui IP, configurações da conta, dispositivo ou grupo de experimento. Use-o para verificações orientativas de SEO local, não como garantia de ranking exato em nível de cidade.
Quando os parâmetros da URL da Pesquisa Google entram em conflito silenciosamente

Combinações de parâmetros podem falhar sem aviso: o Google pode ignorar uma entrada, reescrever a URL ou retornar uma superfície diferente. Vale a pena incluir as checagens de conflito abaixo em todo fluxo de links de busca.
Nenhum artigo concorrente cobre interações entre parâmetros. Mas se você monta URLs de busca com vários parâmetros — e provavelmente monta — precisa saber quais combinações funcionam bem e quais brigam entre si.
gl + uule: qual vence?
Quando ambos estão presentes, uule fornece um sinal de localização mais específico do que gl. Se você definir gl=uk e um uule apontando para Tóquio, receberá resultados influenciados por Tóquio, não do Reino Unido.
Recomendação: se estiver usando uule, omita gl completamente ou defina gl para o país que contém a cidade do seu uule. Não envie sinais contraditórios.
tbm + udm: não use os dois
Nos meus testes, quando tbm e udm aparecem juntos na mesma URL, às vezes o Google remove os dois e retorna uma pesquisa web comum. O comportamento é inconsistente entre sessões e contas.
Recomendação: use apenas udm em novas implementações. Se precisar dar suporte a fluxos legados, use um ou outro — nunca ambos.
lr + cr: a filtragem dupla pode zerar os resultados
Essa é uma armadilha sutil. lr=lang_en restringe a conteúdo em inglês. cr=countryJP restringe a páginas hospedadas no Japão. Combine os dois e você estará pedindo “páginas em inglês hospedadas no Japão” — um subconjunto muito pequeno da web.
Recomendação: use um ou outro, a menos que você realmente precise da interseção. Se combinar, espere um número bem menor de resultados.
num + start: paginação quebrada
Scripts antigos que usam num=100&start=0 agora retornam silenciosamente apenas cerca de 10 resultados. O parâmetro num não é mais respeitado, mas não gera erro — ele simplesmente é ignorado.
Recomendação: remova num de todas as URLs. Faça a paginação usando start em incrementos de 10 e elimine duplicados entre páginas.
Referência rápida de conflitos
| Combinação | O que acontece | Recomendação |
|---|---|---|
gl + uule | uule fornece o sinal mais específico | Alinhe país e cidade, ou omita gl |
tbm + udm | Imprevisível — ambos podem ser removidos | Use apenas udm |
lr + cr | Redução agressiva, muitas vezes quase zero resultados | Use um ou outro |
num + start | num ignorado, apenas ~10 resultados retornados | Remova num, pagine com start |
nfpr=1 + tbs=li:1 | Controles relacionados, mas não idênticos | Teste sua consulta específica |
hl + lr | Idioma da interface ≠ restrição de idioma do conteúdo | Use com intenção; hl não é filtro de conteúdo |
Dos parâmetros da URL da Pesquisa Google à extração estruturada de dados

Até aqui você já tem uma URL precisa da Pesquisa Google — a consulta certa, o país certo, o intervalo de datas certo, resultados web clássicos. O próximo passo é extrair dados estruturados dos resultados.
Seja para criar um rastreador de rankings, monitorar concorrentes ou alimentar um fluxo de pesquisa com dados de busca, ver os resultados certos é só metade do trabalho. Você precisa de títulos, URLs, snippets, posições e datas em uma planilha ou banco de dados.
Montando uma URL de busca do Google bem direcionada (juntando tudo)
Um exemplo completo combinando vários parâmetros:
https://www.google.com/search?q=site%3Acompetitor.com+intitle%3Apricing&hl=en&gl=us&tbs=qdr:m,sbd:1&udm=14&pws=0
Desmembrando:
q=site%3Acompetitor.com+intitle%3Apricing— páginas em competitor.com com “pricing” no títulohl=en— interface em inglêsgl=us— contexto de mercado dos EUAtbs=qdr:m,sbd:1— último mês, ordenado por dataudm=14— resultados web clássicos (sem AI Overviews)pws=0— personalização desligada
Você pode montar isso programaticamente com curl:
curl -L -G 'https://www.google.com/search' \
--data-urlencode 'q=site:competitor.com intitle:pricing' \
--data-urlencode 'hl=en' \
--data-urlencode 'gl=us' \
--data-urlencode 'tbs=qdr:m,sbd:1' \
--data-urlencode 'udm=14' \
--data-urlencode 'pws=0' \
-H 'User-Agent: Mozilla/5.0'
Ou com Python:
import requests
params = {
"q": "site:competitor.com intitle:pricing",
"hl": "en",
"gl": "us",
"tbs": "qdr:m,sbd:1",
"udm": "14",
"pws": "0",
}
response = requests.get(
"https://www.google.com/search",
params=params,
headers={"User-Agent": "Mozilla/5.0"},
timeout=20,
)
print(response.url)
Requisições HTTP anônimas ao Google muitas vezes retornam shells JavaScript sem resultados renderizados no servidor, ou avisos de tráfego incomum — exatamente onde a extração via navegador leva vantagem.
Extraindo dados da SERP sem escrever um parser
Fazer parsing do HTML do Google é um trabalho frágil. A estrutura do DOM muda com frequência, os nomes das classes são ofuscados e o que você vê no navegador nem sempre é o mesmo que recebe em uma resposta HTTP bruta.
Uma abordagem mais simples para não desenvolvedores: abra sua URL de busca cuidadosamente montada no Chrome e depois use uma ferramenta de extração baseada no navegador para puxar os dados estruturados da página visível. Na Thunderbit, criamos nossa extensão do Chrome exatamente para esse tipo de fluxo — você pode usar o AI Suggest Fields para identificar colunas como título do resultado, URL de destino, texto do snippet e posição visível, e então extrair tudo para uma planilha sem escrever um parser.
Essa não é a única opção. Abordagens baseadas em código também funcionam, especialmente se você precisa lidar com extrações em grande escala ou repetidas. Mas, para pesquisas ad hoc, auditorias e análises competitivas pontuais, a extração via navegador evita completamente a fragilidade do parsing de HTML.
Quando usar uma API oficial em vez disso
Aqui vai o aviso de uso responsável — e ele importa.
Os Termos de Serviço do Google proíbem acesso automatizado que contorne medidas de proteção, e a Ajuda da Pesquisa Google classifica explicitamente scrapers de busca e softwares que enviam consultas automatizadas para medir ranking como tráfego automatizado. Rodar um scraper do Google em escala de produção coloca você em risco de bloqueios de IP, CAPTCHAs e possíveis problemas legais.
Para necessidades de dados de busca em escala de produção e alto volume, o melhor caminho é uma API oficial. A Custom Search JSON API do Google está fechando para novos clientes — usuários existentes têm até 1º de janeiro de 2027 para migrar, com 100 consultas gratuitas por dia e $5 por 1.000 consultas depois disso. O Google recomenda o Vertex AI Search para buscas em sites controlados daqui em diante.
Para sites que você administra, a Search Analytics API do Search Console é a fonte primária para cliques, impressões, CTR e posição média — sem necessidade de scraping.
Pense no conhecimento sobre parâmetros de URL como uma ferramenta de diagnóstico e pesquisa: ótima para montar links de busca precisos, fazer auditorias manuais e entender o que o Google mostra. Não é substituta de APIs oficiais em escala.
Operadores de pesquisa do Google: os parâmetros dentro da sua consulta
Os operadores de pesquisa vivem dentro do parâmetro q=, mas são companheiros essenciais dos parâmetros de URL. A tabela abaixo cobre os que o Google atualmente documenta, além de alguns que ainda funcionam na prática:
| Operador | O que faz | Exemplo |
|---|---|---|
site: | Restringe a um domínio | q=site:example.com+SEO |
filetype: | Restringe a um tipo de arquivo | q=filetype:pdf+annual+report |
intitle: | A palavra precisa aparecer no título | q=intitle:pricing+SaaS |
inurl: | A palavra precisa aparecer na URL | q=inurl:blog+marketing |
- | Exclui um termo | q=apple+-fruit |
"" | Correspondência de frase exata | q=%22google+search+url+parameters%22 |
OR | Um termo ou outro | q=scraping+OR+crawling |
before: | Resultados anteriores a uma data | q=AI+before:2026-01-01 |
after: | Resultados posteriores a uma data | q=AI+after:2025-06-01 |
related: | Sites semelhantes | q=related:hubspot.com |
O verdadeiro poder vem de combinar operadores dentro de q com parâmetros de URL fora dele:
q=site:competitor.com+intitle:pricing+after:2026/01/01&tbs=sbd:1&gl=us&udm=14
Isso encontra páginas em competitor.com com “pricing” no título, publicadas depois de janeiro de 2026, ordenadas por data, no mercado dos EUA, com resultados web clássicos. É uma consulta de inteligência competitiva bem precisa, construída inteiramente com parâmetros de URL e operadores.
O Google diz que os resultados de site: não são garantidamente completos — não trate uma consulta site: como um inventário exaustivo de páginas indexadas.
Uso responsável: Termos de Serviço do Google e limites de taxa
Contexto breve, mas importante.
Os Termos de Serviço do Google proíbem acesso abusivo e a tentativa de contornar medidas de proteção. A Ajuda da Pesquisa Google cita especificamente scrapers de busca e softwares automatizados de ranking como exemplos de tráfego automatizado. Violar esses termos pode resultar em bloqueios de IP, CAPTCHAs, restrições de conta e até medidas legais.
O conhecimento sobre parâmetros de URL é melhor usado para: construir manualmente URLs de busca precisas, criar links de pesquisa compartilháveis para sua equipe, fazer auditorias pequenas no navegador e entender como a interface de busca do Google funciona. Para automação em escala de produção, use as APIs oficiais do Google — ou um provedor licenciado de dados de busca de terceiros, como a Brave Search API.
Na Thunderbit, nossa extensão de navegador foi criada para extração iniciada pelo usuário e com a página visível — não para consultas automatizadas de alto volume ao Google. Essa é uma distinção importante.
Principais conclusões: sua caixa de ferramentas de parâmetros da URL da Pesquisa Google em 2026
A versão resumida:
- Use
gl+hlpara sinais de localização e não dependa apenas dos ccTLDs durante a migração de redirecionamento do Google - Teste
udmetbmquando fizer sentido — nenhum dos dois é uma API estável e versionada para consumidores udm=14pode solicitar resultados web clássicos sem AI Overviews, mas o Google pode removê-lo ou reescrevê-lo- Use
uulepara geolocalização em nível de cidade com a fórmula de codificação protobuf acima - Domine
tbspara filtro preciso por data (cdr:1,cd_min:...,cd_max:...), ordenação por data (sbd:1) e busca literal (li:1) - Fique atento a conflitos de parâmetros:
glvs.uule,tbmvs.udm,lrvs.cr num=100é instável e nunca foi oficialmente suportado — usestartem incrementos de 10 como padrão mais seguro- Para dados estruturados da SERP, use ferramentas baseadas no navegador como a Thunderbit para trabalhos pontuais, ou APIs oficiais para produção em escala
- Respeite os Termos de Serviço do Google — parâmetros de URL são uma ferramenta de pesquisa, não uma licença para scraping
O Google continua alterando parâmetros sem aviso. Vou manter esta referência atualizada conforme as mudanças acontecem — salve nos favoritos e volte sempre.
Saiba mais
- 9 melhores APIs de SEO para 2026 (com dados reais de custo por requisição)
- Como dominar o scraping de mecanismos de busca: um guia completo
- 27 melhores ferramentas para analisar e monitorar rankings de sites
- Como usar paginação em Web Scraper para uma extração eficiente
- O que é automação de busca? Benefícios, ferramentas e estratégias
FAQs
O que o udm=14 faz em uma URL da Pesquisa Google?
udm=14 pode solicitar uma superfície clássica de resultados web sem AI Overviews, por isso é tão popular entre profissionais de SEO. Ele foi obtido por engenharia reversa, não é um contrato oficialmente documentado do Google, e o Google pode removê-lo ou reescrevê-lo dependendo da sessão, conta, região, cliente e grupo de experimento.
O parâmetro num ainda funciona em 2026?
Não conte com ele. O Google deixou de respeitar de forma confiável o num=100 em setembro de 2025, e um porta-voz disse que o parâmetro nunca foi oficialmente suportado. Use start em incrementos de 10 como padrão mais seguro para paginação e verifique a contagem retornada, porque o Google ainda pode reescrever ou limitar a resposta.
Como simulo uma busca do Google a partir de uma cidade específica?
Use o parâmetro uule com um nome de cidade codificado. A seção de codificação acima traz o algoritmo baseado em protobuf e um exemplo em Python. Você precisará do nome canônico da localidade no Google (disponível nos dados de geotargeting da Google Ads), que você codifica em um valor uule como uule=w+CAIQICIeNew+York,New+York,United+States.
Qual é a diferença entre gl, lr e cr?
Esses três parâmetros controlam aspectos diferentes de geolocalização e idioma. gl simula sua localização de busca em nível de país (afeta ranking e resultados locais). lr restringe resultados a páginas escritas em um idioma específico. cr restringe resultados a páginas hospedadas em um país específico. Eles podem ser combinados, mas combinações contraditórias (como lr=lang_en + cr=countryJP) vão reduzir drasticamente os resultados.
Posso combinar vários valores de tbs em uma única URL?
Sim — separe-os com vírgulas dentro de um único parâmetro tbs. Por exemplo, tbs=qdr:m,sbd:1 filtra para o último mês e ordena por data (mais recentes primeiro). Você também pode adicionar li:1 para modo literal: tbs=qdr:m,sbd:1,li:1. A sintaxe de tbs não é documentada, então teste suas combinações específicas para confirmar que funcionam como esperado.


