Network identity
GrowGanic crawler and publishing IPs
Addresses last verified 2026-08-27
GrowGanic writes and publishes articles on behalf of the people who own the sites it connects to. This page exists so a hosting provider, firewall or security plugin can identify that traffic and tell it apart from everything else. If you are a customer whose host is blocking us, the request to send them is at the bottom.
IP addresses we connect from
Every request GrowGanic makes to a customer site originates from one of these four addresses. They are static. We do not rotate them, and we publish them here precisely so that they can be allowlisted.
152.55.176.240 152.55.177.181 152.55.177.193 162.220.232.251
Most control panels and support desks prefer ranges, and several cap how many entries you may add. The same four addresses as three /24 ranges:
152.55.176.0/24 152.55.177.0/24 162.220.232.0/24
Machine-readable at /crawler/ips.json.
User-Agents we send
Every identity we send to a site, CMS or endpoint a customer connected to us, including the one that does not say GrowGanic. Different jobs need different requests, so the honest answer is a list rather than a single string. Two things it does not pin byte for byte: the audit tier that renders a page in a real browser sends whatever Chrome string that browser was built with, and the comparison reads described below go out under an ordinary browser string as well. What ties all of it together is the addresses above: our traffic comes from those four, whatever it calls itself.
Browser-equivalent fetch. The first attempt at reading a connected customer's own pages for the technical part of their audit. It is a plain HTTP request carrying a current browser's header set, because a great many sites serve different markup, or a challenge page, to anything that does not look like a browser, and an audit scored against that version of the page would be wrong about the customer's own site. This one carries no GrowGanic token, which is why the addresses above are the reliable way to identify us. The Chrome version tracks current stable and changes.
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/149.0.0.0 Safari/537.36
Site fetch. The same audit read, retried under our own name after the first attempt was challenged. This is the string to allow if your firewall matches on User-Agent.
GrowGanicBot/1.0 (+https://growganic.io/crawler)
Publishing. Authenticated calls to a customer's own CMS: connection checks, article create and update, image upload. Also the availability lookup we make to the Internet Archive when an origin is unreachable.
GrowGanic/1.0 (+https://growganic.io)
Custom integration delivery. Posting a published article to the endpoint a customer entered themselves, signed with the secret they issued.
GrowGanic-Webhook/1.0 (+https://growganic.io/docs/webhooks)
Host detection. A single request, HEAD where the server allows it and a one byte ranged GET where it does not, that identifies which platform serves a customer's site so their dashboard can show the right setup snippet. Distinct from the crawler so it can be rate limited on its own.
GrowGanic-HostDetector/1.0 (+https://growganic.io)
Blog migration read. The read half of a migration a customer asked us to run: the WordPress REST index, then one request per page of posts, pages and custom post types, then one per image so the pictures can be served from our own storage. It is the busiest thing we ever send, a few hundred requests inside a few minutes, and it is all GET. Nothing is written, changed or deleted on the source site.
GrowGanicBlogImport/1.0 (+https://growganic.io/crawler)
Hosting reachability probe. One GET of /blog/growganic-ping on a customer's own domain, checking that the snippet they installed is forwarding that path to us. It repeats while their hosting settings screen is open and the path is not answering yet, so it is the string most likely to appear in a log more than once. It reads a single path, carries no credentials and changes nothing.
GrowGanic-BlogProbe/1.0 (+https://growganic.io)
What the traffic does
Publishing is authenticated, always. Requests to a CMS carry credentials the site owner issued to us themselves, such as a WordPress Application Password. Allowing our addresses through a bot challenge does not create an anonymous way in. Anything arriving from them still has to present those credentials before the CMS will accept a single word.
Nearly every fetch was asked for by the site's owner. GrowGanic is not a web-wide crawler and it builds no index of anyone's site. It reads a site because that site's owner connected it to their GrowGanic account and asked for the work: an audit of their own pages, a publish to their own CMS, a check that what we published is live. An audit stays inside the domain we were given, never follows a link off it, and reads a bounded set of pages a few times a month, one request at a time. There is one exception and it is worth stating plainly: to show a customer how their draft compares with the pages already ranking for their keyword, we read a handful of those public pages, once each, the way anyone comparing search results would. If that is how you found this page, it was a few requests rather than a crawl, and the note below on getting us to stop applies to it too.
robots.txt is not what governs the audit. That file is the contract for bulk crawling by strangers, and an audit is not that: it is an owner-requested read of the owner's own site. We fetch robots.txt on every audit and report what it says back to the owner, because a forgotten Disallow rule is one of the most common reasons their pages are missing from Google and from AI answers. We do not apply it as a limit on the audit itself: a site that blocks Googlebot still gets audited in full, which is the only way to show its owner which of their own pages Google cannot reach.
Getting us to stop. Write to hey@growganic.io, or block the addresses above. Both take effect immediately. A robots.txt rule will not do it, as the paragraph above says, so please use one of these two rather than assuming a Disallow line was enough. Either one also tells us it happened, which means we can tell the customer why their audit went quiet instead of leaving them to guess.
If we are being blocked
The usual symptom is that a security layer answers our request with a challenge page instead of passing it to the API, so publishing fails with what looks like a malformed response. Anti-bot systems on shared hosting flag us on the address, not the User-Agent, because a cloud address looks like a datacenter no matter what it calls itself. Allowing the three ranges above is what resolves it.
Send this to your host, or paste it into a support ticket:
Please add a firewall / anti-bot exception for the following IP ranges on my domain: 152.55.176.0/24 152.55.177.0/24 162.220.232.0/24 These are the published addresses of GrowGanic, a publishing tool I use. It connects to my WordPress REST API at /wp-json/wp/v2/ to post articles, and it is currently being served a security challenge page instead of the API. Every request is authenticated with a WordPress Application Password that I issued, so the exception does not create an anonymous way in. The addresses and the identifying User-Agents are published at https://growganic.io/crawler
Reaching us
If our traffic is causing a problem on your infrastructure, or you need something added to this page to write a rule against, write to hey@growganic.io and a person will answer. We would much rather hear from you than be quietly blocked.