An authenticated diagnostic agent, not a crawler. It requests a site only when that site’s own administrator has installed the BoltAudit plugin and started an audit — and it requests from one fixed IP address, every time.
Machine-readable address list: boltaudit.com/ips.json
BoltAudit has no crawl frontier and no seed list. There is exactly one way for it to reach a site, and it always starts with the site’s own administrator.
The BoltAudit plugin is installed from the WordPress.org directory by someone with administrator rights on that site.
The plugin generates a signed credential on that server and registers the site. BoltAudit cannot mint one for a site that has not opted in.
From their own dashboard, or on a schedule they set. Nothing runs on a site whose owner has not asked for it.
Each call carries that credential. The plugin rejects anything unsigned, so a blocked request is never an unauthenticated one.
Deactivate or delete the BoltAudit plugin, or remove the site from the BoltAudit dashboard, and the requests stop immediately. There is no separate opt-out list to join and nothing to email us about first.
A User-Agent header is a claim, not proof — anyone can send BoltAudit/1.0. The IP address is the part that cannot be forged, so check that.
63.142.251.204That is the whole list today. Read it programmatically from /ips.json rather than hard-coding it, and we will not break your allowlist when we add capacity.
$ dig +short -x 63.142.251.204
proxy.boltaudit.com.
$ dig +short proxy.boltaudit.com
63.142.251.204The PTR resolves to a hostname under boltaudit.com, and that hostname resolves back to the same address. This is the same verification Google and Bing publish for their own crawlers, and it survives us changing addresses.
If your firewall is blocking audits, allow the egress IP. Every rule below does the same thing in a different product’s language.
Security → WAF → Custom rules → Create rule, action Skip (select all remaining custom rules, rate limiting, managed rules, and Super Bot Fight Mode). Then place it above your other rules.
(ip.src eq 63.142.251.204 and http.request.uri.path contains "/wp-json/boltaudit/")On the Free plan a Skip rule can bypass custom rules and Super Bot Fight Mode; Managed Rules skipping needs Pro or above. If Bot Fight Mode (not Super) is what is challenging the request, it cannot be skipped per-rule — turn it off, or upgrade to Super Bot Fight Mode, which can.
Wordfence → Firewall → Blocking → check Allowlisted IP addresses under Firewall Options, and add 63.142.251.204. Also clear the address from Live Traffic if it was already rate-limit blocked.
Each has an allowlist under its lockout or brute-force settings. Add 63.142.251.204 there, and if the plugin keeps a separate “404 lockout” or “bot protection” list, add it to that one too.
Look for “Allowlist IP”, “Trusted IPs”, or “Site Shield” in the security panel and add 63.142.251.204. On SiteGround it is Site Tools → Security → Site Shield.
# Apache 2.4
<Location "/wp-json/boltaudit/">
Require ip 63.142.251.204
</Location>
# ModSecurity
SecRule REMOTE_ADDR "@ipMatch 63.142.251.204" \
"id:1000001,phase:1,nolog,allow,ctl:ruleEngine=Off"WP Rocket, LiteSpeed Cache, and most CDNs will happily serve a cached HTML page in place of a JSON response. Exclude /wp-json/boltaudit/* from caching and from HTML optimisation. A cached page returned to an API call reads as a firewall block but is not one.
Public fetches honour robots.txt. When BoltAudit reads a page the way a search engine would — to check what a crawler can see — it fetches and obeys /robots.txt first, and skips paths that disallow it.
Authenticated plugin endpoints are not crawling. Calls to /wp-json/boltaudit/* carry the site owner’s own signed credential and read their own instrumentation. They are the site’s own diagnostics reporting back, in the same sense that an uptime monitor or a backup service the owner installed is not gated by robots.txt.
You can block it in robots.txt anyway. If you want the public fetches to stop while keeping the plugin installed, this works:
User-agent: BoltAudit
Disallow: /Doing that will make several checks report as unavailable rather than passing — the audit cannot measure a page it is not allowed to load.
Two things do not come from the static address above. We would rather you learn that here than from a log.
Anyone can enter a URL at boltaudit.com/free-audit and get a read-only report without installing anything. That is a handful of requests to public pages, sent with BoltAudit/1.0, from Cloudflare Workers egress addresses rather than from our static IP. It honours robots.txt, and it is rate-limited per target.
One optional, off-by-default check answers “would GPTBot or ClaudeBot actually be able to read this page?” by requesting the site owner’s own homepage once per crawler, carrying that crawler’s published User-Agent string. In a log this looks like GPTBot arriving from an address that is not OpenAI’s — because it is us, testing on the owner’s behalf.
It runs only when the site owner enables it, only against their own verified site, and never from the static egress address, so it can never be mistaken for our authenticated agent. The report says plainly that the result is indicative: a bot-management product that verifies crawlers by IP or reverse DNS will treat the real crawler differently than it treats this probe.
If traffic claiming to be BoltAudit is hitting paths that are not listed here, or arriving from an address that is not in /ips.json, it is not us — and we want the log line.
hello@boltaudit.comThis page is the canonical description of BoltAudit’s automated traffic. It is kept current; changes to the address list appear in /ips.json first.