Limit für IP-Ausschlüsse in Google Ads: die 500er-Grenze, CIDR und was sich nicht blockieren lässt

Sie haben ein Klickprotokoll. Ein paar Adressen tauchen immer wieder auf, das Ausschlussfeld fasst 500 Einträge, und Sie fragen sich, was passiert, wenn es voll ist. Suchen Sie nach dem Limit, stammt fast jede Seite, die Ihnen antwortet, von einem Anbieter für Klickbetrugsschutz, und fast jede Antwort endet gleich: Unser Tool rotiert die Liste für Sie.

Wir halten das für die falsche Frage. Die API-Dokumentation von Google zählt das Limit in „IP-Blöcken“, ein Eintrag kann also einen ganzen Bereich abdecken, und die sinnvolle Frage lautet dann, welche Bereiche einen Platz verdienen. Unsere Position ist einfach. Eine Ausschlussliste ist für beständige Störenfriede gedacht, etwa Ihr eigenes Büro oder einen Hosting-Block, der immer wieder auftaucht, nicht für Betrug. Google gibt an, ungültige Klicks bereits auf seiner Seite zu filtern, und wir zitieren die entsprechende Seite gegen Ende.

Im Folgenden nennen wir beide Limits in Googles eigenen Worten, zeigen, wie Sie einen Bereich in der Oberfläche und als CIDR über die API eingeben, prüfen sechs reale Adressen mit unserer API, um zu entscheiden, welche einen Platz verdienen, und listen auf, was kein Ausschluss verhindern kann. Die grundsätzliche Argumentation dafür, jeden Klick zu bewerten, statt ihn zu sperren, finden Sie in unserem Leitfaden zu Klickbetrug.

Limit für IP-Ausschlüsse in Google Ads: Wie viele Adressen können Sie ausschließen?

Sie können 500 IP-Einträge pro Kampagne und 500 pro Konto ausschließen. Die beiden Zahlen stehen auf unterschiedlichen Google-Seiten, und deshalb geben so viele Artikel die zweite falsch an.

Wir haben jede in diesem Beitrag zitierte Google-Seite am 14. Oktober 2026 um 06:12 UTC aufgerufen. Die Grenze pro Kampagne steht auf Googles Hilfeseite IP-Adressen ausschließen:

„Sie können bis zu 500 IP-Adressen pro Kampagne ausschließen.“

Für die Kontoebene nennt die Hilfeseite keine Zahl. Die Grenze pro Konto steht in der Referenz der Google Ads API zu CustomerNegativeCriterion, der Ressource für Ausschlüsse auf Kontoebene. Ihr Feld ip_block lautet: „Immutable. IpBlock. You can exclude up to 500 IP addresses per account.“ (Unveränderlich. IpBlock. Sie können bis zu 500 IP-Adressen pro Konto ausschließen.) Manche gut rankenden Seiten übersehen das. Der Beitrag von Lunio zum 500er-Limit, den wir zur selben Zeit aufgerufen haben, schreibt: „Das 500-IP-Ausschlusslimit gilt pro Kampagne, nicht pro Konto.“ Laut Googles Referenz hat die Kontoliste eine eigene Grenze von 500.

Die Einheit ist wichtiger als die Zahl. Die Tabelle der API-Systemlimits von Google führt die Zeile als „Excluded IP blocks per campaign“ (ausgeschlossene IP-Blöcke pro Kampagne), Wert „500“, Fehler ResourceCountLimitExceededError.CAMPAIGN_LIMIT. Pro Adresse oder pro CIDR-Block wird ein Kriterium angelegt, ein einmal eingegebenes /24 ist laut Googles API-Dokumentation also ein Eintrag. In einem echten Konto haben wir das nicht getestet. Deshalb sprechen wir von 500 Plätzen, nicht von 500 Adressen.

Wenn auf beiden Ebenen Einträge vorhanden sind, werden die Listen laut Googles Hilfeseite zusammengeführt:

„Wenn Sie unter derselben Kundennummer IP-Ausschlüsse sowohl auf Konto- als auch auf Kampagnenebene eingerichtet haben, führt Google Ads die Ausschlusslisten zusammen. Das bedeutet, dass alle auf einer der beiden Ebenen ausgeschlossenen IP-Adressen für diese Kampagne Ihre Anzeigen nicht sehen.“

Googles eigenes Beispiel: „Angenommen, Sie schließen die IP-Adressen 1, 2 und 3 auf Kampagnenebene aus (Kampagne A). Dann schließen Sie die IP-Adressen 4 und 5 auf Kontoebene aus. Für die eingerichtete Kampagne (Kampagne A) blockiert Google Ads effektiv die IP-Adressen 1, 2, 3, 4 und 5.“ Mehr sagt Google nicht darüber, wie die beiden Grenzen zusammenspielen, also tun wir es auch nicht.

Konto- oder Kampagnenebene: Wo Sie IP-Ausschlüsse hinzufügen

Fügen Sie einen Ausschluss auf Kontoebene hinzu, wenn er überall gelten soll, und auf Kampagnenebene nur, wenn eine einzelne Kampagne ein eigenes Problem hat. Googles eigenes Beispiel für einen guten Ausschluss sind Ihre eigenen Mitarbeitenden: „Sie beschließen, die IP-Adresse des Netzwerks Ihres Unternehmens auszuschließen.“ Diese Adresse gehört auf die Kontoebene.

Das sind Googles Schritte für die Kontoebene, von derselben Hilfeseite:

1. Klicken Sie in Ihrem Google-Ads-Konto auf das Symbol Verwaltung.
2. Klicken Sie auf Kontoeinstellungen.
3. Wechseln Sie zum Abschnitt „IP-Ausschlüsse“.
4. Geben Sie die IP-Adressen ein, denen Ihre Anzeigen nicht gezeigt werden sollen.
5. Klicken Sie auf Speichern.

Und für eine einzelne Kampagne:

1. Klicken Sie in Ihrem Google-Ads-Konto auf das Symbol Kampagnen.
2. Klicken Sie im Abschnittsmenü auf das Drop-down-Menü Kampagnen.
3. Klicken Sie auf Kampagnen und dann auf Einstellungen.
4. Wählen Sie die Kampagne aus, für die Sie IP-Adressen ausschließen möchten.
5. Klicken Sie auf der Seite „Einstellungen“ auf Weitere Einstellungen.
6. Klappen Sie den Abschnitt „IP-Ausschlüsse“ auf, geben Sie die Adressen ein und klicken Sie auf Speichern.

Das Entfernen eines Eintrags funktioniert auf beiden Ebenen über denselben Weg. Laut Google folgen Sie den obigen Schritten, „entfernen alle IP-Adressausschlüsse, die nicht mehr gelten sollen“, und klicken auf Speichern. Eine Falle gibt es: „Ausschlüsse auf Kontoebene können nicht innerhalb der einzelnen Kampagnen bearbeitet oder entfernt werden.“ Wenn ein Eintrag in einer Kampagne festzustecken scheint, sehen Sie in den Kontoeinstellungen nach.

Gute Einträge auf Kontoebene sind Ihr Büro, das Büro Ihrer Agentur und ein bestätigter Hosting-Block, der immer wieder klickt. Auch der feste Büro-Adressbereich eines Wettbewerbers ist ein vertretbarer Platz auf Kampagnenebene. Geht es Ihnen eigentlich um Geografie, verweist Google auf einen anderen Weg: „Wenn Sie verhindern möchten, dass Ihre Anzeigen an bestimmten geografischen Standorten ausgeliefert werden, schließen Sie statt IP-Adressen besser einen geografischen Standort aus.“

Welche Kampagnentypen können keine IP-Ausschlüsse auf Kampagnenebene nutzen?

Video-, Hotel-, App-, Performance-Max- und Smart-Display-Kampagnen akzeptieren keine IP-Ausschlüsse auf Kampagnenebene. Googles Hilfeseite fasst das in einem Hinweis zusammen:

„Hinweis: IP-Ausschlüsse sind für Videokampagnen, Hotelkampagnen, App-Kampagnen, Performance Max-Kampagnen und Smart-Display-Kampagnen nicht verfügbar.“

Die Kontoebene reicht weiter. Laut Google können Sie sie nutzen, „um bestimmte IP-Adressen in allen Kampagnen Ihres Kontos von der Anzeigenauslieferung auszuschließen, einschließlich Performance Max, Demand Gen, Suche, Shopping, Display, Discover und YouTube“. Performance Max akzeptiert IP-Ausschlüsse also nur auf Kontoebene, und diese Liste umfasst dieselben 500 Einträge, die sich alle anderen Kampagnen teilen.

Die Seiten von Anbietern widersprechen sich bei dieser Liste, teils weil sich auch Googles eigene Seiten unterscheiden. Die ältere Hilfeseite von Search Ads 360 nennt Video-, App-, Smart-Display- und Discovery-Kampagnen. Wir verwenden nur die fünf Typen von der aktuellen Google-Ads-Seite.

So schließen Sie einen IP-Bereich aus: Sternchen, CIDR und IPv6

In der Oberfläche ist die dokumentierte Form für einen Bereich ein Sternchen im letzten Oktett. Über die API ist jeder IPv4- oder IPv6-CIDR-Block ein Eintrag.

Googles Hilfeseite sagt: „Sie können bestimmte IP-Adressen eingeben oder ein Sternchen (*) verwenden, um die letzten 3 Ziffern zu ersetzen, wenn Sie einen Adressblock ausschließen möchten.“ Mit den letzten drei Ziffern ist das letzte Oktett gemeint: 198.51.100.* umfasst 256 Adressen, genauso viele wie ein /24. Google dokumentiert ein Sternchen an genau dieser Stelle und nichts anderes. Formen mit zwei Sternchen oder einem Sternchen am Anfang tauchen auf manchen gut rankenden Seiten auf, aber Google dokumentiert keine solche Syntax. Verlassen Sie sich also nicht darauf.

Die API ist flexibler. Googles IpBlockInfo-Referenz sagt: „Wir unterstützen den Ausschluss einzelner IP-Adressen oder CIDR-Blöcke. Erstellen Sie ein IpBlockInfo-Kriterium für jede einzelne IP-Adresse oder jeden CIDR-Block, den Sie ausschließen möchten.“ Die Beispiele dort sind 192.168.0.0/24 und eine einzelne Adresse als 192.168.0.1/32 für IPv4 sowie 2001:db8::/48 und 2001:db8:a0b:12f0::1/128 für IPv6.

Die Oberfläche dokumentiert einzelne Adressen und das Sternchen. CIDR- und IPv6-Blöcke sind für die API dokumentiert. Was die Oberfläche mit einem CIDR- oder IPv6-Eintrag macht, haben wir nicht getestet, also behaupten wir auch nicht, dass es funktioniert.

Bei der Rechnung mit den Plätzen zahlt sich CIDR aus. Nehmen Sie einen Bereich von 194.83.41.0 bis 194.83.47.255, das Beispiel, das eine britische Agentur auf WebSuccess Insights verwendet. Wir haben ihn mit Pythons ipaddress.summarize_address_range verarbeitet:

Googles IPv6-Beispiel ist ein /48, das 65.536 /64-Subnetze enthält. Das Netz eines einzelnen Geräts ist meist ein /64, während ISPs einem Haushalt häufig ein /56 oder ein /48 zuweisen. Ein /48-Eintrag kann also einen ganzen Kundenstandort abdecken. Wir erklären in unserem IPv6-Beitrag, was ein /48 im Vergleich zu einem /64 abdeckt.

Google fügt noch einen Satz hinzu: „IP-Adressen können in verschiedenen Versionen vorkommen. Achten Sie also darauf, alle Versionen der IP-Adresse zu verwenden, die Sie ausschließen möchten.“ Das heißt: Ein Büro oder Server mit einer IPv4- und einer IPv6-Adresse braucht beide Einträge.

IP-Ausschlüsse in großer Zahl über die Google Ads API hinzufügen

Über die API ist ein Ausschluss auf Kampagnenebene ein negatives CampaignCriterion mit einem ip_block, und ein Ausschluss auf Kontoebene ist ein CustomerNegativeCriterion mit einem ip_block. Googles Tabelle der Kriterien führt den IP-Block als nur ausschließbar auf Kampagnen- und Kundenebene.

Bevor Sie etwas hochladen, verkleinern Sie die Liste. Dieses Skript macht aus Kandidatenadressen und -blöcken die geringstmögliche Zahl von CIDR-Einträgen, die sie abdecken, die aktivsten zuerst, begrenzt auf 500. Es ist genau der Code, den wir am 14. Oktober ausgeführt haben, mit Python 3.9.6 und nur der Standardbibliothek:

Wir haben keine echten Klickprotokolle, die wir veröffentlichen könnten, also haben wir das Skript mit einer synthetischen Stichprobe gefüttert, die nur aus Adressbereichen für Dokumentationszwecke besteht. Das sind keine echten Klicks, und sie wurden nie abgefragt:

Der Aufruf python3 -I build_exclusions.py < synthetic_clicks.txt gab Folgendes aus:

Aus acht Zeilen wurden vier Einträge. Außerdem haben wir 600 nicht benachbarte synthetische /32 aus 198.18.0.0/15 eingegeben: Das Skript behielt die 500 aktivsten und meldete 100 über dem Limit.

Drei Dinge tut das Skript bewusst nicht:

• Es erweitert nie eine Adresse. collapse_addresses führt nur Blöcke zusammen, die aneinandergrenzen oder sich überschneiden. Aus einer Adresse ihr /24 zu machen, ist eine Entscheidung, die Sie nach einer RDAP-Abfrage treffen, nicht etwas, das Code raten sollte.
• Die Syntax der Oberfläche ist ihm egal. Ein /31 oder ein /48 ist für die API in Ordnung. In der Oberfläche würden Sie das /31 als zwei Adressen eingeben, und für IPv6 dokumentiert Google dort keine Bereichsform.
• Es filtert keine geteilten Adressen heraus. Führen Sie es erst aus, nachdem die Regel aus den nächsten Abschnitten Relay- und Carrier-NAT-Adressen entfernt hat.

Es ruft auch nie unsere API auf. Wenn Sie einen Abfrageschritt ergänzen, ist das ein GET pro Adresse, mit der IP im Pfad und Ihrem Schlüssel im Header x-api-key, wie die API-Referenz zeigt. Einen Batch-Aufruf gibt es nicht. Setzen Sie bei Pythons urllib einen expliziten User-Agent, denn unsere API antwortet auf den Standard-User-Agent von urllib derzeit mit 403.

So sieht das Hochladen eines Eintrags aus. Wir haben es anhand von Googles Referenz zu IpBlockInfo und CampaignCriterion geschrieben, die am 14. Oktober v25 zeigte, mit der Namensgebung der Python-Clientbibliothek. Gegen ein echtes Konto haben wir es nicht ausgeführt.

Google dokumentiert den Fehler nur für die Grenze pro Kampagne. Für die Grenze pro Konto haben wir keinen dokumentierten Fehlercode gefunden, also nennen wir keinen. Die Versionshinweise zu Google Ads Editor 2.11 enthalten die Überschrift „Account-level placement and IP exclusions“ (Placement- und IP-Ausschlüsse auf Kontoebene), aber den Editor haben wir nicht getestet, daher geben wir keine Schritte für den Editor an.

Warum 500 Einträge kein Hosting-Netzwerk fassen

Fünfhundert Einträge reichen für keinen großen Cloud-Anbieter, denn Google dokumentiert keine Möglichkeit, ein Netzwerk über seine ASN auszuschließen, und ein großer Anbieter kündigt Tausende von Präfixen an. Wir haben am 14. Oktober um 06:14 UTC gezählt:

Die Zählungen von RIPEstat enthalten sich überschneidende spezifischere Präfixe und alles, was im Zweiwochenzeitraum zu sehen war. Betrachten Sie sie daher als Obergrenze für Einträge, nicht als eindeutigen Adressraum. Sie ändern sich täglich. Trotzdem braucht allein Amazon ein Vielfaches mehr Einträge, als Ihre beiden Listen zusammen fassen.

Die Hosting-Frage lautet also nicht „Kann ich die Cloud ausschließen?“. Das können Sie nicht. Sie lautet: „Welche Hosting-Blöcke tauchen in meinem eigenen Protokoll immer wieder auf?“ Wir erklären separat, was eine Adresse zu einer Rechenzentrums-IP macht. Unsere API erkennt Hosting anhand von 853 kuratierten Hosting-ASNs sowie offiziellen Bereichen von 10 Cloud-Anbietern, und Sie können eine einzelne Adresse im kostenlosen Datacenter-IP-Check testen.

Eine Warnung, bevor Sie eine Regel auf dieses Flag stützen. Hosting-Traffic ist die erste Kategorie von General Invalid Traffic im MRC-Standard, aber derselbe Standard nimmt legitimes VPN-Routing und das Surfen über virtuelle Maschinen ausdrücklich davon aus. Das erläutern wir in GIVT vs. SIVT: Googles Kategorien für ungültigen Traffic. Hosting allein ergibt absichtlich einen niedrigen Score: 45.33.32.156 weiter unten liefert detection.is_hosting: true und einen Score von 10, allow. Ob Hosting-Traffic Ihre Anzeigen sehen soll, ist bei bezahlten Klicks Ihre Regel, nicht die des Scores.

Welche Adressen einen Ihrer 500 Plätze verdienen

Ein Platz sollte an einen stabilen Bereich gehen, den niemand sonst nutzt und den Sie in Ihrem eigenen Klickprotokoll gesehen haben. Um zu zeigen, wie das aussieht, haben wir am 14. Oktober um 06:12 UTC sechs öffentliche Adressen mit einem anonymen GET https://api.geoiphub.com/v1/lookup/{ip} abgefragt. Alle sechs lieferten HTTP 200. Keine davon hat auf irgendjemandes Anzeige geklickt. Sie stehen stellvertretend für die Arten von Adressen, die ein Klickprotokoll enthält.

Unsere Antwort enthält kein Präfixfeld, deshalb haben wir den registrierten Block jeder Adresse um 06:14 UTC per RDAP über rdap.org ermittelt, das an ARIN und RIPE weiterleitete.

Zwei Zeilen brauchen eine Anmerkung. Der VPN-Name bei 45.83.220.7 stammt aus unserer Tabelle der VPN-Hosting-Netzwerke mit Konfidenz 85, nicht aus Mullvads eigener Serverliste, die diese Adresse bei unserer Prüfung am 13. Oktober nicht enthielt. Und 104.28.46.99 liegt innerhalb des registrierten /12 von Cloudflare, aber außerhalb der Bereiche, die Cloudflare für sein eigenes Netzwerk veröffentlicht. „Den Block von Cloudflare ausschließen“ würde also Nutzer von Apples Relay treffen, nicht Server von Cloudflare.

Eine Adresse von Anfang bis Ende

Verfolgen Sie 185.220.101.1 vom Klick bis zum Eintrag. Bei aktivierter automatischer Tag-Kennzeichnung fügt Google eine GCLID an Ihre Landingpage-URL an, in Googles Beispiel „www.example.com/?gclid=123xyz“. Protokollieren Sie auf Ihrer Landingpage die Client-IP neben dieser gclid, denn erst diese Kombination verknüpft eine Adresse mit einem bezahlten Klick.

Fragen Sie die Adresse dann ab. Das ist eine gekürzte Kopie unserer Antwort von 06:12 UTC, Verschachtelung beibehalten, Werte unverändert:

detection.is_tor ist true, der Score beträgt 100, und vier separate Methoden haben angeschlagen. Die Antwort nennt das registrierte Netzwerk, aber nicht seine Größe, also haben wir RDAP gefragt: 185.220.101.0 bis 185.220.101.31, ein /27. Dieser Block wird über die API zu einem Eintrag, 185.220.101.0/27. Er kostet einen von 500 Plätzen und deckt 32 Adressen ab, die ein einziger Tor-Betreiber betreibt. Das ist ein guter Tausch.

Die Regel, der wir folgen würden

1. Vergeben Sie Plätze nur an stabile, nicht geteilte Bereiche, die Sie in Ihrem eigenen Klickprotokoll gesehen haben: Hosting-Blöcke mit is_relay: false und Blöcke von Tor-Betreibern.
2. Vergeben Sie nie einen Platz an eine Adresse, bei der detection.is_relay oder threat.is_cgnat true ist, unabhängig vom Score.
3. Bewerten Sie alles andere pro Klick auf der Landingpage, VPNs eingeschlossen, denn ein VPN-Betreiber erzielte bei zwei seiner Adressen 46 und 100.
4. Entnehmen Sie den Block aus RDAP oder der eigenen Bereichsdatei des Anbieters, nicht aus unserer Antwort.

Die Score-Bereiche hinter diesen Aktionen sind allow bis 25, review bis 50, step_up bis 75 und block über 75. Wie die Bereiche des Risikoscores funktionieren, erklären wir in einem separaten Beitrag, und Sie können eine Adresse im kostenlosen IP-Fraud-Score-Checker prüfen, bevor Sie einen Platz dafür vergeben.

Vergeben Sie nie einen Platz an eine geteilte Adresse: Carrier-NAT und Private Relay

Über Carrier-NAT- und iCloud-Private-Relay-Adressen sind viele echte Menschen gleichzeitig unterwegs. Wenn Sie eine davon ausschließen, verbergen Sie Ihre Anzeigen vor allen. Daran ändert kein Score und keine Klickzahl etwas.

Beginnen wir mit Private Relay. Viele Apple-Nutzer teilen sich jede Ausgangsadresse, und unser Scoring deckelt ein Relay bei 60, sodass eine Private-Relay-IP nie block erreichen kann. Die Falle steckt in der Tabelle oben. 172.224.226.1 steht auf Apples Relay-Liste und liefert trotzdem detection.is_hosting: true, weil sie in Rechenzentren von Akamai läuft. Eine Regel wie „jeden Hosting-Block ausschließen“ würde Apple-Nutzer ausschließen. Prüfen Sie is_relay vor allem anderen, wie wir es in Relay- und VPN-Nutzer durchlassen erklären.

Carrier-NAT ist die mobile Variante desselben Problems. Wir haben keine unbedenkliche Mobilfunkadresse, die wir Ihnen zeigen könnten, denn wir fragen keine Adressen von Privatpersonen ab und veröffentlichen keine. Dieser Teil bleibt daher reiner Text. threat.is_cgnat kennzeichnet Adressen, die sich viele Mobilfunkkunden teilen, und unser Scoring hat eine Carrier-NAT-Obergrenze von 50. Eine geteilte Mobilfunkadresse, gegen die sonst nichts spricht, bleibt also unter step_up. Der Bereich aus RFC 6598, 100.64.0.0/10, ist die interne Seite des Netzbetreibers und erscheint nie als Klick-IP. Sie sehen stattdessen die öffentliche Adresse des Netzbetreibers.

Was ein Fehler hier kostet, wurde schon vor Jahren aufgeschrieben. RFC 6269 warnt, dass bei geteilten Adressen „ein Nutzer, der eine Reihe von Anmeldeversuchen nicht besteht, andere Nutzer aussperren kann, die zuvor keine Versuche unternommen haben, nun aber schon beim ersten Versuch scheitern“. Ersetzen Sie Anmeldeversuche durch Anzeigenklicks, und Sie haben das Ausschlussproblem. In unserem Hub-Beitrag erklären wir ausführlicher, warum das Sperren einer geteilten Adresse echte Kunden trifft.

Was ein IP-Ausschluss nicht blockieren kann

Ein IP-Ausschluss kann nicht jeden Klick von einer Adresse verhindern, kann kein Netzwerk benennen und hat keinen Einfluss auf Klicks, die Sie bereits bezahlt haben. Den ersten Teil sagt Google selbst, auf der Seite Warum erhalte ich Klicks von ausgeschlossenen IP-Adressen?:

„Wenn Sie das Tool für IP-Ausschlüsse (Internet Protocol) verwenden, können Klicks von ausgeschlossenen IP-Adressen trotzdem in Ihren Webprotokollen erscheinen.“

Google nennt drei Gründe:

• Rotation. „Einige Internetanbieter rotieren die IP-Adressen ihrer Nutzer fortlaufend.“ Die Anzeige wird einer Adresse gezeigt, und der Klick kommt von einer anderen.
• Fehlende Daten. „Einige Websites im Google-Werbenetzwerk stellen keine IP-Informationen bereit. Nutzer mit Ihren ausgeschlossenen IP-Adressen sehen Ihre Anzeige auf diesen Websites daher möglicherweise. Wir können nicht garantieren, dass es keine Klicks von einer bestimmten IP-Adresse gibt.“
• Organische Klicks. „Die Referrer-URL eines Klicks auf die organischen Google-Suchergebnisse und auf eine Anzeige ist dieselbe. Da der IP-Ausschluss nur für Anzeigen gilt, ist es möglich, dass der Klick, den Sie sehen, tatsächlich aus unseren Suchergebnissen stammt.“

Und dann folgt der Satz, der unsere gesamte Position prägt:

„Google filtert ungültige Klicks automatisch und proaktiv aus Ihrem Konto. Sie müssen nichts tun, um diesen Schutz zu erhalten. Mit dem Tool für IP-Adressausschlüsse können Sie jedoch zusätzlich steuern, wo Ihre Anzeigen ausgeliefert werden.“

Steuerung der Auslieferung, in Googles Worten, keine Betrugsabwehr. Google dokumentiert außerdem keine Einstellung für Ausschlüsse nach ASN, ISP, VPN, Proxy oder Rechenzentrum, und ein Ausschluss bringt Ihnen kein Geld für bereits berechnete Klicks zurück.

Auch auf unserer Seite gibt es Grenzen. Unsere API klassifiziert eine IP, die Sie ihr übergeben. Ihre Google-Ads-Klicks oder GCLIDs kann sie nicht sehen; die stammen nur aus Ihrem eigenen Landingpage-Protokoll. Sie liefert kein Präfix, der Block kommt also immer aus RDAP. Und Abfrageergebnisse ändern sich: Bis zum 13. Oktober verwendete unser Leitfaden zu Klickbetrug 45.83.220.7 als einfaches Hosting-Beispiel, und heute benennt die API sie als Netzwerk von Mullvad. Versehen Sie jedes Ergebnis, auf dessen Grundlage Sie handeln, mit einem Datum.

Was Sie mit welcher Art von Adresse tun:

Zwei Prüfungen für Ihre eigene Ausschlussliste in dieser Woche:

• Verkleinern Sie sie. Exportieren Sie Ihre aktuellen Einträge und lassen Sie sie durch das Skript oben laufen. Zusammengeführte Einträge machen Plätze frei. Zählen Sie also, was übrig bleibt, bevor Sie etwas Neues hinzufügen.
• Entfernen Sie geteilte Adressen. Fragen Sie pro Eintrag eine Adresse im Fraud-Score-Checker ab. Löschen Sie jeden Eintrag, bei dem is_relay oder is_cgnat true zurückgibt.

Häufig gestellte Fragen

Wie viele IP-Adressen kann man in Google Ads ausschließen?

Bis zu 500 pro Kampagne, und die API-Referenz von Google setzt dieselbe Grenze von 500 auch für Ausschlüsse auf Kontoebene. Die Kontoliste ist kein größerer Pool.

Kann man CIDR oder IPv6 für IP-Ausschlüsse in Google Ads verwenden?

Über die Google Ads API ja: Jeder IPv4- oder IPv6-CIDR-Block zählt als ein Eintrag. Die Hilfeseite von Google dokumentiert für die Oberfläche nur einzelne Adressen und ein Sternchen für das letzte Oktett.

Kann man IP-Adressen aus Performance Max ausschließen?

Nur auf Kontoebene. IP-Ausschlüsse auf Kampagnenebene sind für Video-, Hotel-, App-, Performance-Max- und Smart-Display-Kampagnen nicht verfügbar.

Warum kommen trotzdem Klicks von ausgeschlossenen IP-Adressen?

Google nennt drei Gründe: Manche ISPs rotieren die Adressen ihrer Nutzer, manche Websites im Google-Werbenetzwerk liefern keine IP-Informationen, und organische und bezahlte Klicks haben denselben Referrer.

Erstattet ein IP-Ausschluss bereits bezahlte Klicks?

Nein. Ein Ausschluss verhindert nur, dass Ihre Anzeigen dieser Adresse ab jetzt gezeigt werden. Gutschriften für ungültige Klicks sind ein separater Vorgang.

Sollte man eine IP eines Mobilfunkanbieters oder von iCloud Private Relay ausschließen?

Nein. Hinter jeder dieser Adressen stehen viele echte Menschen. Bewerten Sie also den Klick, statt einen Platz dafür zu verschwenden.