Limite de exclusão de IP do Google Ads: o teto de 500, CIDR e o que ele não bloqueia

Você tem um log de cliques. Um punhado de endereços continua voltando, a caixa de exclusões comporta 500, e você se pergunta o que acontece quando ela enche. Pesquise o limite e quase todas as páginas que respondem são de fornecedores de proteção contra fraude de cliques, e quase todas as respostas terminam do mesmo jeito: nossa ferramenta faz a rotação da lista para você.

Achamos que essa é a pergunta errada. A própria documentação da API do Google conta o limite em "blocos de IP", então uma entrada pode cobrir uma faixa inteira, e a pergunta útil passa a ser quais faixas merecem uma vaga. Nossa posição é simples. Uma lista de exclusão serve para incômodos estáveis, como o seu próprio escritório ou um bloco de hospedagem que não para de aparecer, e não para fraude. O Google diz que já filtra cliques inválidos do lado dele, e citamos essa página perto do final.

A seguir, apresentamos os dois limites nas palavras do próprio Google, mostramos como informar uma faixa na interface e como CIDR pela API, passamos seis endereços reais pela nossa API para decidir quais merecem uma vaga e listamos o que nenhuma exclusão consegue impedir. Para o argumento mais amplo a favor de pontuar cada clique em vez de bani-lo, comece pelo nosso guia sobre fraude de cliques.

Limite de exclusão de IP do Google Ads: quantos endereços você pode excluir?

Você pode excluir 500 entradas de IP por campanha e 500 por conta. Os dois números estão em páginas diferentes do Google, e é por isso que tantos textos erram o segundo.

Abrimos todas as páginas do Google citadas neste post às 06:12 UTC de 14 de outubro de 2026. O teto por campanha está na página de ajuda do Google, Excluir endereços IP:

"Você pode excluir até 500 endereços IP por campanha."

A página de ajuda não dá nenhum número para o nível da conta. O teto da conta está na referência da API do Google Ads para CustomerNegativeCriterion, o recurso que guarda as exclusões no nível da conta. Seu campo ip_block diz: "Immutable. IpBlock. You can exclude up to 500 IP addresses per account." ("Imutável. IpBlock. Você pode excluir até 500 endereços IP por conta.") Algumas páginas bem posicionadas deixam isso passar. O post da Lunio sobre o limite de 500, que abrimos no mesmo momento, diz "The 500 IP exclusion limit applies per campaign, not per account." ("O limite de 500 exclusões de IP se aplica por campanha, não por conta.") A referência do Google diz que a lista da conta tem o próprio teto de 500.

A unidade importa mais do que o número. A tabela de limites do sistema da API do Google lista a linha como "Excluded IP blocks per campaign" (blocos de IP excluídos por campanha), valor "500", erro ResourceCountLimitExceededError.CAMPAIGN_LIMIT. Um critério é criado por endereço ou por bloco CIDR, então, na documentação da API do Google, um /24 informado uma vez é uma entrada. Não testamos isso em uma conta real. É por isso que falamos em 500 vagas, e não em 500 endereços.

Quando os dois níveis têm entradas, a página de ajuda do Google diz que as listas são mescladas:

"Se você tiver exclusões de IP configuradas tanto no nível da conta quanto no nível da campanha sob o mesmo CID: o Google Ads vai mesclar as listas de exclusão. Isso significa que todos os endereços IP excluídos em qualquer um dos níveis serão impedidos de ver seus anúncios naquela campanha."

O exemplo do próprio Google: "Imagine que você exclua os endereços IP 1, 2 e 3 no nível da campanha (Campanha A). Depois, você exclui os endereços IP 4 e 5 no nível da conta. Para a campanha que você configurou (Campanha A), o Google Ads vai efetivamente bloquear os endereços IP 1, 2, 3, 4 e 5." O Google não diz mais nada sobre como os dois tetos interagem, então nós também não.

Nível da conta ou nível da campanha: onde adicionar exclusões de IP

Adicione uma exclusão no nível da conta quando ela deve valer em todo lugar, e no nível da campanha só quando uma campanha tem um problema próprio. O exemplo do próprio Google de uma boa exclusão é a sua própria equipe: "você decide excluir o endereço IP da rede da sua empresa." Esse endereço pertence ao nível da conta.

Estes são os passos do Google para o nível da conta, na mesma página de ajuda:

1. Na sua conta do Google Ads, clique no ícone Administrador.
2. Clique em Configurações da conta.
3. Vá até a seção "Exclusões de IP".
4. Informe os endereços IP que você quer impedir de ver seus anúncios.
5. Clique em Salvar.

E para uma campanha:

1. Na sua conta do Google Ads, clique no ícone Campanhas.
2. Clique no menu suspenso Campanhas no menu da seção.
3. Clique em Campanhas e depois em Configurações.
4. Selecione a campanha da qual você quer excluir endereços IP.
5. Na página "Configurações", clique em Configurações adicionais.
6. Expanda a seção "Exclusões de IP", informe os endereços e clique em Salvar.

Remover uma entrada segue o mesmo caminho em qualquer um dos níveis. As instruções do Google são seguir os passos acima, "remover as exclusões de endereço IP que você não quer aplicar" e clicar em Salvar. Uma armadilha: "Não é possível editar ou remover exclusões do nível da conta de dentro das campanhas individuais." Se uma entrada parecer presa em uma campanha, procure em Configurações da conta.

Boas entradas no nível da conta são o seu escritório, o escritório da sua agência e um bloco de hospedagem confirmado que continua clicando. A faixa fixa do escritório de um concorrente também é uma vaga razoável no nível da campanha. Se o seu objetivo real é geografia, o Google aponta outro caminho: "Se você está tentando impedir que seus anúncios sejam exibidos em determinados locais geográficos, tente excluir anúncios de um local geográfico em vez de excluir endereços IP."

Quais tipos de campanha não podem usar exclusões de IP no nível da campanha?

Campanhas de vídeo, de hotel, para apps, Performance Max e de display inteligente não aceitam exclusões de IP no nível da campanha. A página de ajuda do Google diz isso em uma nota:

"Observação: as exclusões de IP não estão disponíveis para campanhas de vídeo, campanhas de hotel, campanhas para apps, campanhas Performance Max e campanhas de display inteligente."

O nível da conta vai mais longe. O Google diz que você pode usá-lo "para impedir que endereços IP específicos vejam seus anúncios em todas as campanhas da sua conta, incluindo Performance Max, Geração de demanda, Pesquisa, Shopping, Display, Discover e YouTube." Então o Performance Max só aceita exclusões de IP no nível da conta, e essa lista é a mesma de 500 entradas que todas as outras campanhas compartilham.

As páginas de fornecedores divergem sobre essa lista, em parte porque as próprias páginas do Google divergem. A página de ajuda mais antiga do Search Ads 360 cita campanhas de vídeo, para apps, de display inteligente e Discovery. Usamos apenas os cinco tipos da página atual do Google Ads.

Como excluir uma faixa de IP: o asterisco, CIDR e IPv6

Na interface, a forma documentada de faixa é um asterisco no último octeto. Pela API, qualquer bloco CIDR IPv4 ou IPv6 é uma entrada.

A página de ajuda do Google diz: "Você pode informar endereços IP específicos ou usar um asterisco (*) para substituir os 3 últimos dígitos se quiser excluir um bloco de endereços." Os três últimos dígitos significam o último octeto: 198.51.100.* cobre 256 endereços, o mesmo que um /24. O Google documenta um asterisco nessa posição e mais nada. Formas com dois asteriscos, ou com um asterisco no início, aparecem em algumas páginas bem posicionadas, mas o Google não documenta nenhuma sintaxe assim, então não confie nelas.

A API é mais flexível. A referência de IpBlockInfo do Google diz: "We support excluding individual IP addresses or CIDR blocks. Create one IpBlockInfo criterion for each individual IP address or CIDR block you want to exclude." ("Oferecemos suporte à exclusão de endereços IP individuais ou de blocos CIDR. Crie um critério IpBlockInfo para cada endereço IP individual ou bloco CIDR que você quer excluir.") Seus exemplos são 192.168.0.0/24 e um endereço individual como 192.168.0.1/32 para IPv4, e 2001:db8::/48 e 2001:db8:a0b:12f0::1/128 para IPv6.

A interface documenta endereços individuais e o asterisco. Blocos CIDR e IPv6 são documentados para a API. Não testamos o que a interface faz com uma entrada CIDR ou IPv6, então não vamos dizer que funciona.

É na aritmética das vagas que o CIDR compensa. Pegue uma faixa de 194.83.41.0 a 194.83.47.255, o exemplo que uma agência do Reino Unido usa no WebSuccess Insights. Passamos a faixa pelo ipaddress.summarize_address_range do Python:

O exemplo de IPv6 do Google é um /48, que contém 65.536 sub-redes /64. A rede de um único dispositivo costuma ser um /64, enquanto os ISPs costumam entregar a uma residência um /56 ou um /48, então uma entrada /48 pode cobrir o local inteiro de um cliente. Explicamos o que um /48 cobre em comparação com um /64 no nosso post sobre IPv6.

O Google acrescenta mais uma linha: "Os endereços IP podem aparecer em versões diferentes, então use todas as versões do endereço IP que você quer excluir." Leia assim: um escritório ou servidor com um endereço IPv4 e um IPv6 precisa das duas entradas.

Como adicionar exclusões de IP em massa pela API do Google Ads

Pela API, uma exclusão de campanha é um CampaignCriterion negativo com um ip_block, e uma exclusão de conta é um CustomerNegativeCriterion com um ip_block. A tabela de critérios do Google lista o bloco de IP como apenas excludente, nos níveis de campanha e de cliente.

Antes de enviar qualquer coisa, encolha a lista. Este script transforma endereços e blocos candidatos no menor número de entradas CIDR que os cobre, das mais movimentadas para as menos, com teto de 500. É exatamente o código que rodamos em 14 de outubro, no Python 3.9.6, apenas com a biblioteca padrão:

Não temos logs de cliques reais para publicar, então alimentamos o script com uma amostra sintética construída apenas com faixas de endereços de documentação. Estes não são cliques reais e nunca foram consultados:

Rodar python3 -I build_exclusions.py < synthetic_clicks.txt imprimiu:

Oito linhas viraram quatro entradas. Também alimentamos o script com 600 /32 sintéticos não adjacentes de 198.18.0.0/15, e ele manteve os 500 mais movimentados e informou 100 acima do limite.

Três coisas que o script deliberadamente não faz:

• Ele nunca amplia um endereço. collapse_addresses só mescla blocos que se tocam ou se sobrepõem. Transformar um endereço no seu /24 é uma decisão que você toma depois de uma consulta RDAP, não algo que o código deva adivinhar.
• Ele não se importa com a sintaxe da interface. Um /31 ou um /48 serve para a API. Na interface, você digitaria o /31 como dois endereços, e o Google não documenta nenhuma forma de faixa IPv6 ali.
• Ele não filtra endereços compartilhados. Rode-o só depois que a regra das próximas seções tiver removido os endereços de relay e de NAT de operadora.

Ele também nunca chama a nossa API. Se você adicionar uma etapa de consulta, é um GET por endereço, com o IP no caminho e a sua chave no cabeçalho x-api-key, como mostra a referência da API. Não há chamada em lote. No urllib do Python, defina um User-Agent explícito, porque hoje a nossa API retorna 403 para o padrão do urllib.

Enviar uma entrada fica assim. Escrevemos o código a partir da referência de IpBlockInfo e CampaignCriterion do Google, que mostrava a v25 em 14 de outubro, usando a nomenclatura da biblioteca cliente em Python. Não o executamos em uma conta real.

O Google documenta o erro apenas para o teto da campanha. Não encontramos nenhum código de erro documentado para o teto da conta, então não citamos nenhum. As notas da versão 2.11 do Google Ads Editor têm um título "Account-level placement and IP exclusions" (exclusões de posicionamento e de IP no nível da conta), mas não testamos o Editor, então não damos passos para ele.

Por que 500 entradas não comportam uma rede de hospedagem

Quinhentas entradas não comportam um grande provedor de nuvem, porque o Google não documenta nenhuma forma de excluir uma rede pelo ASN, e um grande provedor anuncia milhares de prefixos. Contamos às 06:14 UTC de 14 de outubro:

As contagens do RIPEstat incluem prefixos mais específicos sobrepostos e tudo o que foi visto durante a janela de duas semanas, então trate-as como um limite superior de entradas, e não como espaço de endereços único. Elas mudam diariamente. Mesmo assim, só a Amazon precisa de muitas vezes mais entradas do que as suas duas listas comportam juntas.

Então a pergunta sobre hospedagem não é "posso excluir a nuvem?". Não pode. É "quais blocos de hospedagem continuam aparecendo no meu próprio log?". Explicamos o que faz de um endereço um IP de datacenter em outro post. Nossa API sinaliza hospedagem a partir de 853 ASNs de hospedagem selecionados mais as faixas oficiais de 10 provedores de nuvem, e você pode testar um endereço na verificação gratuita de IP de datacenter.

Uma ressalva antes de escrever uma regra com base nessa flag. O tráfego de hospedagem é a primeira categoria de General Invalid Traffic (tráfego inválido geral) no padrão do MRC, mas o mesmo padrão exclui dela o roteamento legítimo por VPN e a navegação em máquinas virtuais, o que detalhamos em GIVT vs SIVT: as categorias de tráfego inválido do Google. Hospedagem sozinha recebe uma pontuação baixa por design: o 45.33.32.156 abaixo retorna detection.is_hosting: true e uma pontuação de 10, allow. Para cliques pagos, decidir se o tráfego de hospedagem deve ver seus anúncios é uma regra que cabe a você escrever, e não à pontuação.

Quais endereços merecem uma das suas 500 vagas

Uma vaga deve ir para uma faixa estável, que ninguém mais compartilha e que você viu no seu próprio log de cliques. Para mostrar como isso fica, consultamos seis endereços públicos às 06:12 UTC de 14 de outubro com um GET https://api.geoiphub.com/v1/lookup/{ip} anônimo. Os seis retornaram HTTP 200. Nenhum deles clicou no anúncio de ninguém. Eles representam os tipos de endereço que um log de cliques contém.

Nossa resposta não tem campo de prefixo, então obtivemos cada bloco registrado pelo RDAP às 06:14 UTC, por meio do rdap.org, que redirecionou para o ARIN e o RIPE.

Duas linhas precisam de uma observação. O nome de VPN em 45.83.220.7 vem da nossa tabela de redes de hospedagem de VPN, com confiança 85, e não da lista de servidores da própria Mullvad, que não o incluía quando verificamos em 13 de outubro. E 104.28.46.99 está dentro do /12 registrado da Cloudflare, mas fora das faixas que a Cloudflare publica para a própria rede, então "excluir o bloco da Cloudflare" cortaria usuários do relay da Apple, e não servidores da Cloudflare.

Um endereço, do início ao fim

Acompanhe 185.220.101.1 do clique até a entrada. Com a codificação automática ativada, o Google adiciona um GCLID ao seu URL de destino, "www.example.com/?gclid=123xyz" no exemplo do Google. Registre o IP do cliente ao lado desse gclid na sua página de destino, porque é esse par que liga um endereço a um clique pago.

Depois, consulte o endereço. Esta é uma cópia resumida da nossa resposta das 06:12 UTC, com o aninhamento mantido e os valores sem edição:

detection.is_tor é true, a pontuação é 100 e quatro métodos distintos dispararam. A resposta nomeia a rede registrada, mas não o seu tamanho, então perguntamos ao RDAP: 185.220.101.0 a 185.220.101.31, um /27. Esse bloco vira uma entrada, 185.220.101.0/27, pela API. Ele custa uma das 500 vagas e cobre 32 endereços operados por um único operador Tor. É uma boa troca.

A regra que seguiríamos

1. Gaste vagas apenas com faixas estáveis e não compartilhadas que você viu no seu próprio log de cliques: blocos de hospedagem com is_relay: false e blocos de operadores Tor.
2. Nunca gaste uma vaga com um endereço que tenha detection.is_relay ou threat.is_cgnat true, seja qual for a pontuação.
3. Pontue todo o resto por clique na página de destino, inclusive VPNs, porque um mesmo operador de VPN pontuou 46 e 100 em dois dos seus endereços.
4. Obtenha o bloco pelo RDAP ou pelo arquivo de faixas do próprio provedor, e não pela nossa resposta.

As faixas de pontuação por trás dessas ações são allow até 25, review até 50, step_up até 75 e block acima de 75. Explicamos como funcionam as faixas da pontuação de fraude em outro post, e você pode verificar um endereço no verificador gratuito de pontuação de fraude de IP antes de gastar uma vaga com ele.

Nunca gaste uma vaga com um endereço compartilhado: NAT de operadora e Private Relay

Endereços de NAT de operadora e do iCloud Private Relay transportam muitas pessoas reais ao mesmo tempo, então excluir um deles esconde seus anúncios de todas elas. Nenhuma pontuação ou contagem de cliques muda isso.

Comece pelo Private Relay. Muitos usuários da Apple compartilham cada endereço de saída, e a nossa pontuação limita um relay a 60, então um IP do Private Relay nunca chega a block. A armadilha está na tabela acima. 172.224.226.1 está na lista de relays da Apple e mesmo assim retorna detection.is_hosting: true, porque roda nos data centers da Akamai. Uma regra que diga "excluir todo bloco de hospedagem" excluiria usuários da Apple. Verifique is_relay antes de qualquer outra coisa, como explicamos em deixar passar usuários de relay e de VPN.

O NAT de operadora é a versão móvel do mesmo problema. Não temos nenhum endereço de operadora seguro para mostrar, porque nunca consultamos nem publicamos endereços de consumidores, então esta parte é só texto. threat.is_cgnat marca endereços compartilhados por muitos assinantes da operadora, e a nossa pontuação tem um limite de 50 para NAT de operadora, então um endereço de operadora compartilhado sem mais nada contra ele fica abaixo de step_up. A faixa da RFC 6598, 100.64.0.0/10, é o lado interno da operadora e nunca aparece como IP de um clique. Em vez disso, você verá o endereço público da operadora.

O custo de errar nisso foi registrado anos atrás. A RFC 6269 alerta que, com endereços compartilhados, "um usuário que falha em várias tentativas de login pode bloquear outros usuários que não fizeram nenhuma tentativa anterior, mas que agora vão falhar na primeira tentativa." Troque tentativas de login por cliques em anúncios e você tem o problema da exclusão. Nosso post principal aborda com mais profundidade por que banir um endereço compartilhado atinge clientes reais.

O que uma exclusão de IP não consegue bloquear

Uma exclusão de IP não consegue impedir todos os cliques de um endereço, não consegue nomear uma rede e não afeta cliques que você já pagou. O próprio Google diz a primeira parte, em Por que recebo cliques de endereços IP excluídos?:

"Quando você usa a ferramenta de exclusão de protocolo de internet (IP), cliques de endereços IP excluídos ainda podem aparecer nos seus registros da web."

Ele dá três motivos:

• Rotação. "Alguns provedores de serviços de internet fazem rotação contínua dos endereços IP dos usuários." O anúncio é exibido em um endereço e o clique chega de outro.
• Dados ausentes. "Alguns sites da Rede do Google não fornecem informações de IP, então usuários com os seus endereços IP excluídos podem ver seu anúncio nesses sites. Não podemos garantir que não haverá cliques de um determinado endereço IP."
• Cliques orgânicos. "o URL referenciador de um clique tanto nos resultados orgânicos da Pesquisa Google quanto em um anúncio será o mesmo. Como a exclusão de IP se aplica apenas a anúncios, é possível que o clique que você está vendo tenha se originado, na verdade, dos nossos resultados de pesquisa."

E então vem a frase que molda toda a nossa posição:

"O Google filtra automática e proativamente os cliques inválidos da sua conta. Você não precisa fazer nada para receber essa proteção. No entanto, você pode usar a ferramenta de exclusão de endereços IP para ter mais controle sobre o posicionamento dos seus anúncios."

Controle de posicionamento, nas palavras do Google, e não defesa contra fraude. O Google também não documenta nenhuma configuração de ASN, ISP, VPN, proxy ou data center para exclusões, e uma exclusão não devolve o dinheiro de cliques já cobrados.

Do nosso lado também há limites. Nossa API classifica um IP que você fornece. Ela não consegue ver seus cliques do Google Ads nem seus GCLIDs, que vêm apenas do log da sua própria página de destino. Ela não retorna prefixo, então o bloco sempre vem do RDAP. E as consultas mudam com o tempo: até 13 de outubro, nosso guia sobre fraude de cliques usava 45.83.220.7 como um simples exemplo de hospedagem, e hoje a API o identifica como a rede da Mullvad. Registre a data de cada resultado com base no qual você age.

O que fazer com cada tipo de endereço:

Duas verificações na sua própria lista de exclusão esta semana:

• Encolha a lista. Exporte suas entradas atuais e passe-as pelo script acima. Entradas que se mesclam liberam vagas, então conte o que sobrou antes de adicionar qualquer coisa nova.
• Remova endereços compartilhados. Consulte um endereço de cada entrada no verificador de pontuação de fraude. Apague qualquer entrada em que is_relay ou is_cgnat volte como true.

Perguntas frequentes

Quantos endereços IP você pode excluir no Google Ads?

Até 500 por campanha, e a referência da API do Google define o mesmo teto de 500 para exclusões no nível da conta. A lista da conta não é um conjunto maior.

Dá para usar CIDR ou IPv6 nas exclusões de IP do Google Ads?

Pela API do Google Ads, sim: cada bloco CIDR IPv4 ou IPv6 é uma entrada. A página de ajuda do Google documenta, para a interface, apenas endereços individuais e um asterisco no último octeto.

Dá para excluir endereços IP do Performance Max?

Só no nível da conta. As exclusões de IP no nível da campanha não estão disponíveis para campanhas de vídeo, de hotel, para apps, Performance Max e de display inteligente.

Por que ainda chegam cliques de endereços IP excluídos?

O Google dá três motivos: alguns ISPs fazem rotação dos endereços dos usuários, alguns sites da Rede do Google não fornecem informações de IP, e cliques orgânicos e pagos compartilham o mesmo referenciador.

Excluir um endereço IP reembolsa cliques que você já pagou?

Não. Uma exclusão impede que seus anúncios sejam exibidos para aquele endereço dali em diante. Os créditos por cliques inválidos são um processo separado.

Você deve excluir um IP de operadora móvel ou do iCloud Private Relay?

Não. Muitas pessoas reais compartilham cada um desses endereços, então pontue o clique em vez de gastar uma vaga com ele.