How to Exclude IP Addresses in Google Ads (And Why It Is Only Part of the Answer)

Google Ads provides a built-in IP exclusion tool inside campaign settings. It does not stop a click from arriving — the click lands, the budget is spent — but it prevents that IP from being shown your ads again after exclusion takes effect.

Follow these steps to add an exclusion:

1. Sign in to your Google Ads account and navigate to Campaigns. 2. Select the campaign you want to protect. 3. In the left-hand menu, click Settings, then scroll down to Additional settings. 4. Expand the IP exclusions section. 5. Click Add IP exclusion and enter the address or range. 6. Click Save.

Google Ads accepts both single IPv4 addresses (e.g. `203.0.113.45`) and classless inter-domain routing (CIDR) ranges (e.g. `203.0.113.0/24`). IPv6 exclusions are not supported as of this writing, which is a meaningful gap given how many residential ISPs now assign IPv6 addresses.

Exclusions propagate within a few hours. They apply at the campaign level, so if you run multiple campaigns, you must repeat the process for each one. There is no account-level bulk exclusion interface — a limitation worth knowing before you begin.

If you manage exclusions at scale, the Google Ads API (`CampaignCriterion` with a negative IP criterion) allows programmatic updates, but this requires developer access and API credentials.

The IP exclusion feature has several constraints that matter in practice:

• Volume cap. Google Ads allows roughly 500 IP exclusions per campaign. For most advertisers running a single campaign with occasional abuse, this ceiling is sufficient. For anyone dealing with a coordinated source of invalid traffic (IVT) across many subnets, 500 entries fills up fast.
• IPv4 only. IPv6 is not supported. Traffic arriving over IPv6 cannot be excluded through this tool, regardless of how suspicious it looks.
• CIDR ranges are awkward. You can enter a /24 or /16 range, but Google's interface does not show you how many individual addresses a range covers, and entering overlapping ranges can cause errors. The broader the range, the higher the risk of excluding legitimate users who share an ISP block.
• Campaign-level scope. Exclusions do not carry over between campaigns. If you run Search, Display, and Performance Max campaigns, each needs its own exclusion list maintained independently.
• No account-level list. Unlike negative keywords, there is no shared exclusion library for IPs across the account.
• Processing delay. Exclusions are not instant. Clicks from an excluded IP can still occur in the window between adding the exclusion and its full propagation.

These limits are not fatal flaws — the feature does what it says. The problem is that modern invalid traffic does not cooperate with the assumptions the feature was designed around.

The core assumption behind IP exclusion is that bad actors use the same IP address repeatedly. That assumption was reasonable a decade ago. It is much less reliable today for two reasons.

Rotating datacenter IPs. Bot operators run click farms across cloud infrastructure — AWS, Google Cloud, Azure, DigitalOcean, Vultr, and dozens of smaller providers. These environments offer thousands of IP addresses, and automated click scripts rotate through them rapidly. By the time you identify one IP as suspicious, add it to your exclusion list, and wait for propagation, the traffic has already moved to the next address in the rotation.

Residential proxies. A more serious problem is residential proxy networks. These services route traffic through IP addresses that belong to real home internet connections — ISPs like Comcast, BT, or Turkcell. From Google's perspective, and from your exclusion list's perspective, the IP looks like an ordinary household. Banning it risks excluding a real potential customer who happens to share an ISP block with a proxy endpoint. Residential proxy networks can cycle through tens of thousands of unique IPs, making address-level blocking practically useless.

Sub-source diversity. For advertisers on Google Display Network or search partners, invalid traffic often originates from a specific publisher site, placement, or sub-source within the network — not a single IP. The right exclusion is at the placement level (via placement exclusions in Google Ads), not at the IP level. IP exclusion treats a symptom while leaving the root cause running.

None of this means you should skip IP exclusion. It is still worth using for known persistent offenders — a server-farm range that sends consistently bad traffic from a predictable block, for example. The issue is trusting it as a complete defense rather than a single tool in a broader workflow.

The practical problem with IP exclusion is not the exclusion step itself — it is knowing which IPs and sources actually warrant exclusion. Acting on gut feel or Google's own filtered impression counts leaves most invalid traffic unaddressed.

ValidVisit approaches this differently. Once a click reaches your landing page, ValidVisit weighs it against more than 100 independent data points — drawn from the network it came through, the device sitting behind it, and the way the visitor actually behaves — and folds them into a single 0–100 quality score. Real people clear that bar comfortably; automated and low-quality traffic stands apart. The score is built from several broad layers:

• Network and origin signals that describe where the click really came from — whether it traces back to ordinary consumer connectivity or to infrastructure typically associated with server farms, proxies and VPNs that bad actors operate behind.
• Device and environment signals that describe the machine on the other end and whether it looks like a normal, fully featured browser a human would use, rather than something automated and stripped down.
• Behavioral signals that describe how the visit unfolds — how quickly the interaction happens, whether there is any natural movement or scrolling after a paid click, and how long the session genuinely lasts.
• Coverage for clients that load the page but never behave like a real browser — a common pattern among scrapers and automated crawlers that quietly inflate click counts.

Each click ends up with one quality score and a plain-language explanation of why it scored the way it did. Just as important, every event is attributed to the full campaign hierarchy: campaign, ad group, creative, publisher, placement, and sub-ID — using Google Ads' own tracking tokens (`gclid`, `campaign_id`, `placement`, `adgroup_id`) passed through ValidVisit's token library.

This means the dashboard does not just show you a suspicious IP — it shows you that placement `1234567` on the Display Network sent 430 clicks over three days, 87% of which scored below 50, with low-quality network origin and an absence of any natural on-page interaction as the dominant explanations. That is an actionable finding. You exclude the placement in Google Ads' placement exclusion tool, and you also note the IP range to add to your exclusion list.

Because scoring happens post-arrival — ValidVisit's script runs on your landing page, not in the click path — there is no extra hop, no added latency to the click, and no risk of accidentally breaking your landing page funnel. ValidVisit reports; it never blocks a click and never auto-excludes anything. Flagged events are held for your review, and you retain full control over what to exclude and where.

The most effective approach to reducing invalid traffic in Google Ads is to treat IP exclusion as the output of a detection process, not the process itself.

A working workflow looks like this:

1. Install the detection pixel. Add ValidVisit's script to your landing pages. It begins scoring every click immediately, attributing quality signals to your UTM parameters and Google Ads tracking tokens. 2. Review the suspicious traffic report. After a few days of data, open the publisher/placement report and the traffic quality report. Sort by IVT rate. Look for placements, sub-IDs, or network origins where bad or suspicious scores dominate. 3. Exclude high-IVT placements first. For Display and search partner traffic, placement exclusions are often more effective than IP exclusions because they address the source. Go to Content > Exclusions in Google Ads and add the worst-performing placements. 4. Add persistent datacenter IP ranges to your exclusion list. If ValidVisit's report consistently shows traffic from a specific IP or /24 range scoring low and tracing back to server-farm infrastructure rather than a real household, add that range to campaign IP exclusions. These are the cases where IP exclusion actually helps — the IP is not rotating, and it is not a residential ISP. 5. Request an invalid click credit where eligible. Google Ads automatically filters some invalid clicks and offers credits for others. Documenting your IVT evidence through a third-party tool strengthens the case if you contact Google Ads support about a specific pattern. 6. Repeat on a weekly cadence. Invalid traffic sources shift. A placement that was clean last month may deteriorate. Review the quality data regularly and update your exclusion lists accordingly.

This workflow does not eliminate all invalid traffic — no tool does. But it focuses your 500-exclusion budget on the addresses most likely to matter, and it surfaces placement-level and sub-source problems that IP exclusion cannot touch. The goal is not to stop every bot click before it arrives — it is to stop invalid traffic from polluting your conversion data, skewing your campaign optimization, and inflating your cost-per-acquisition.