About our cookie scanner bot

GetTermsCookieScanner

GetTermsCookieScanner is the crawler we use to find and categorize the cookies on a website, so its owner can publish an accurate cookie policy and configure a consent banner that matches what the site actually sets. It runs against a site only when that site’s owner asks for a scan from inside their GetTerms account.

If you’re a site owner, a host, or a security vendor who has seen this bot in your logs, this page covers how to identify it, how to confirm the traffic is really ours, and how to let it through your firewall.

About GetTerms

GetTerms is an all-in-one privacy compliance platform: a consent management platform and lawyer-drafted policy generation in one subscription. The cookie scanner exists to keep the cookie policies and consent banners we generate accurate to what a site actually does.

What the scanner does

The scanner requests pages on a single domain the way a browser would, loads the scripts those pages load, and records the cookies and trackers that get set. It then categorizes what it found so the customer can review it in their dashboard.

It doesn’t index content for search, scrape data, or store page content beyond what it needs to identify trackers. It doesn’t attempt to log in, submit forms, or reach pages behind authentication or a cart. Anything sitting behind a login is invisible to it, which is why our support docs tell customers to add those cookies manually.

When it runs

Only on request, and only against a domain registered to the account making the request. A scan is triggered when a customer sets up a site in GetTerms, when they run a rescan from the dashboard, or on a recurring schedule they’ve configured for their own site. We don’t crawl the open web, and we don’t scan domains nobody has registered with us.

Crawl etiquette

The scanner keeps to a maximum of 8 requests per second against any single origin, and stays on the origin it was pointed at. It follows internal links only; off-site links are recorded, not fetched. It respects robots.txt  and standard crawl directives, and it backs off when an origin returns rate-limiting or error responses.

A typical scan is short. If you’re seeing sustained traffic from our addresses that doesn’t match this description, tell us using the contact details below and we’ll investigate it.

How to identify the scanner

Every request the scanner makes carries both the user agent and the X-GetTerms-Scanner  header, and originates from one of the published addresses above.

A user agent string is trivial to copy, so treat it as a hint rather than proof. If you’re making a security decision, verify the address instead.

Verify it’s really us

Our addresses are forward-confirmed reverse DNS (FCrDNS) verifiable, the same method Google documents for Googlebot. A reverse lookup on the address returns a hostname under getterms.io , and a forward lookup on that hostname returns the address you started with. A spoofer copying our user agent can’t produce both.

Run the reverse lookup first:

dig +short -x 45.55.125.144

You should get a hostname ending in .getterms.io . Then resolve that hostname back:

dig +short <hostname>.getterms.io

The result must be the address you looked up. If both steps match, the request came from us. If the reverse lookup returns anything that isn’t a getterms.io  hostname, or the forward lookup returns a different address, it isn’t our scanner and you should block it.

host  works just as well if you prefer it:

host 45.55.125.144
host <hostname>.getterms.io

Checking the address against the published list at /bot/ips.json  is also sufficient on its own. The FCrDNS check is there for anyone who’d rather not depend on a fetched file.

Machine-readable IP list

The current addresses are published in JSON at a stable path, in the same shape Google uses for googlebot.json :

https://getterms.io/bot/ips.json

{
  "prefixes": [
    { "ipv4Prefix": "45.55.125.144/32" },
    { "ipv4Prefix": "170.64.255.139/32" }
  ]
}

This file is generated from the same source of truth our scanner uses to route its outbound traffic, so it can’t drift out of date. If you’re building automated allowlisting, read it from there rather than hard-coding the addresses from this page.

How to allowlist the scanner

Most scan failures we see come from a firewall or security plugin blocking the crawler before it reaches the site. Allowlisting our two addresses fixes it. Here’s how in the tools we run into most often.

A note on scope: allowlist the two addresses, not the user agent. A user agent rule will also let through anything pretending to be us.

CleanTalk

Go to Security → FireWall → Allowed IPs, add 45.55.125.144  and 170.64.255.139  as separate entries, and save. Changes apply to new requests immediately.

Wordfence

In WordPress, go to Wordfence → All Options → Allowlisted IP Addresses, add both addresses (comma-separated), and save. If the scanner has already been locked out, clear it under Wordfence → Blocking before rescanning.

Cloudflare

Either approach works:

• IP Access Rules: under Security → WAF → Tools, add each address with the action set to Allow, scoped to the zone you’re scanning.
• WAF custom rule: create a rule matching ip.src in {45.55.125.144 170.64.255.139}  with the action set to Skip, and select the security products you want skipped.

If you’re using Bot Fight Mode or a managed challenge on the whole zone, a Skip rule is the more reliable of the two, because it can bypass the bot products as well as the WAF.

Any other firewall

Allow inbound HTTP and HTTPS requests from 45.55.125.144/32  and 170.64.255.139/32 . Both addresses are ours alone and are used only for cookie scanning, so allowing them doesn’t open a path to anything else. If your tool supports it, you can add a secondary condition on the X-GetTerms-Scanner  header to narrow the rule further.

After allowlisting, run the scan again from your GetTerms dashboard. If it still fails, the block is somewhere else in the chain: check your host’s own firewall, any CDN in front of the origin, and any rate limiting on the server.

Report a problem

For general questions or if our scanner has caused a problem on your site, or you believe someone is using our name or user agent without authorization, contact us at  support [at] getterms [dot] io or through the GetTerms Support Centre. We’ll look into it right away!

Please include the timestamps, the source address, and a sample of the log lines if you have them.