SiteGround Is Blocking mySites.guru Again, and Its Support Can't Agree Why

Since 21:09 UTC on Wednesday 21 October 2026, SiteGround’s Anti-Bot AI has been serving its captcha page to the one address mySites.guru connects to your site from. Audits, backups and connection checks against SiteGround-hosted sites fail, the dashboard shows them as disconnected, and the same sites load perfectly in a browser the whole time. This has happened before, and the mechanism has not changed since July.

Nothing is wrong with your site and nothing has changed at our end. The block is a decision SiteGround’s system made about our published IP address, on SiteGround’s servers, and only SiteGround can undo it. What has changed since July is how much of it we can now show, and how many different explanations SiteGround’s support team has given our shared customers in a single week.

What Changed on 21 October

Our audit log records the first captcha served to our worker IP, 178.62.5.35, at 21:09 UTC on Wednesday 21 October. On the Monday and Tuesday before it, not one audit of a SiteGround-hosted site received a captcha. By Saturday morning most of them did.

Every one of those captchas named the same address. The challenge is a redirect to /.well-known/sgcaptcha/ whose query string includes ipr:178.62.5.35 or ipc:178.62.5.35, so SiteGround’s own response says which address it is judging. Between 09:55 and 10:02 UTC on Saturday we requested the same sites, in the same minute, from our uptime IP (165.227.239.229), from 178.62.5.35, and from a home broadband connection: only the requests from 178.62.5.35 were challenged. Sending a Chrome browser User-Agent from 178.62.5.35 was challenged as well, and sites that were challenged stayed challenged on every request in repeated tests minutes apart. SiteGround is judging the address, and it does so on shared hosting in the US, UK/EU and Asia and on its cloud servers alike.

Currently known hostnames that are blocking us at the time of writing this post

These are the SiteGround servers whose most recent answer to our worker, at the time of writing, was the captcha instead of the site. If your site is on one of them, it is affected. Hostnames are listed, not sites or customers. A server drops off this list as soon as SiteGround exempts our address on it, so treat it as a snapshot, not a permanent record.

What SiteGround Support Has Told Customers This Week

Customers have been writing to us all week, one of them with more than 50 sites showing as disconnected, and some of them had already asked SiteGround first. The answers they brought back differ from agent to agent, and in two cases contradict each other within the same week. Here is each one, set against what our logs, our live tests and SiteGround’s own ticket replies show.

Two of those answers cannot both be true. On 23 October an agent wrote that “the IP 178.62.5.35 is currently restricted within our firewall due to suspicious requests submitted to other websites hosted on our end”, and pasted our challenged requests from SiteGround’s logs to show it. On 24 October another agent wrote “Since I am not seeing these requests in our logs at the moment, it would be best to check directly with the mysites.guru support team”, and asked the customer to come to us for a list of IP addresses and our User-Agent string. One agent could see the requests and was restricting them. The next could not see them and sent the customer away. Both were describing the same address.

How to Recognise mySites.guru Traffic

The request to come to us for a list of IP addresses and a User-Agent string is odd, because mySites.guru may be the easiest automated client on the internet to identify. Every connection to a customer site, whether it is an audit, a backup, an update, a snapshot or a connection check, leaves through one egress proxy at 178.62.5.35, whichever internal server raised it. Uptime checks come from one second address, 165.227.239.229. Both are published in plain text at manage.mysites.guru/ips and have not changed in over a decade.

Every request says who sent it. Connector traffic and uptime checks both identify themselves as mySites/6.0 (+https://mysites.guru/bot/), which points at a page that explains every request we make and how to verify it. SiteGround’s own log lines quoted our User-Agent back to the customer, so it was in front of the agent who asked for it. Every request also includes the header X-Questions: Please email phil@phil-taylor.com, so anyone reading a server log can reach a human with a question in one step. Connector requests are also signed with Web Bot Auth, with Signature-Agent: sig1="https://manage.mysites.guru", so a firewall that checks signatures can verify them against our public key. SiteGround does not check signatures today, so this does not change the block.

Hosts have a page of their own, too. manage.mysites.guru/info-for-webhosts is written for the people who run firewalls: the two addresses, the User-Agents to look for in an access log, the connector paths that must stay reachable, and what to do if an account blocks by country. Server firewalls are not the only thing that can close those paths: Akeeba Admin Tools’ .htaccess Maker does it too, unless the connector has an exception. It needs no login, contains no customer data, and is safe to paste into any ticket. When a support agent asks you for “a full list of all IP addresses or CIDR ranges” and “the exact User-Agent string”, that page is the answer.

The traffic is also gentle by design. Audits run one at a time per server: mySites.guru never runs two audits against the same server at once, so a server with many connected sites sees one audit, then the next. The request SiteGround quoted as suspicious was a POST to /plugins/system/bfnetwork/bfnetwork/bfPing.php on a Joomla site (on WordPress the same file is /wp-content/plugins/mywpguru/bfnetwork/bfPing.php), which is the connector’s connection check, the request we make to confirm we can still reach a site. It is one of many: audits, backups, updates and snapshots each call other files in the connector’s folder (plugins/system/bfnetwork/ on Joomla, wp-content/plugins/mywpguru/ on WordPress), so an exemption for that one URL leaves everything else blocked. A connection check, from a published address, with a named User-Agent and a contact email in its headers, to a connector the site owner installed, is the least suspicious thing in any server log. SiteGround is not the first host to misread our connector: OVH once flagged one of its files as malware.

The noindex Problem Should Worry Every SiteGround Customer

Set mySites.guru aside for a moment, because the captcha response itself should concern anyone with a site on SiteGround. This is what it looks like:

HTTP/2 202
server: nginx
content-type: text/html
content-length: 166
sg-captcha: challenge
x-robots-tag: noindex
cache-control: no-store,no-cache,max-age=0

The body is a tiny HTML page with a meta refresh to /.well-known/sgcaptcha/. The sg-captcha: challenge header names the system. The x-robots-tag: noindex header is the problem. Google’s documentation says what that header means: when Googlebot crawls a page and extracts a noindex tag or header, “Google will drop that page entirely from Google Search results”, and that applies to the X-Robots-Tag header exactly as it does to the meta tag.

The captcha page therefore tells Google to remove the URL it was served for. Whether that ever happens depends on whether SiteGround’s Anti-Bot AI ever decides Googlebot is a bot. On SiteGround’s own Anti-Bot AI launch post, a staff member wrote in May 2017 that “The Google Bot will never be challenged with a captcha page by our system”, and another wrote in December 2019 that “Currently, you cannot opt-out of it”. The first is a promise about an automated judgement, and the second says the customer cannot step outside it. This week that judgement decided a fixed, published, decade-old service IP was suspicious.

It did not have to be a guessing game. Google publishes Googlebot’s IP ranges as JSON files precisely so that hosts and firewalls can recognise it automatically rather than infer it from behaviour. We have no evidence that Googlebot is being challenged today. The risk is that the same system that decided our address was suspicious this week answers with noindex, and the only thing between a SiteGround customer and a de-indexed site is that system never making the same call about Google. What a crawler is served is what Google believes your site is.

What Happened to Vocational Media in 2024

Jon Payne, founder of Vocational Media Group, wrote up the whole episode in March 2024, and at the start none of it looked like a hosting problem. One of his WordPress sites, with a domain authority in the mid-30s and usually 1,000 to 2,000 visits a day, had been losing traffic and rankings for a while. He put it down to Google’s Helpful Content update until he noticed, by chance, that its homepage was not in Google at all.

Search Console showed the indexed-page count falling over the preceding weeks and the “crawled, not indexed” count rising to match. URL Inspection on the homepage said it was excluded because of a robots noindex directive. The page source had none: RankMath was outputting an explicit index directive, and robots.txt was clean. The page was asking to be indexed, and Google was reporting that it had asked not to be.

The second clue was in the list of pages under “Excluded by noindex tag”. Most of the site was there, not just the homepage, and mixed in among them were URLs of the form /.well-known/sgcaptcha/?r=/page-url-here&y=ipc:.... He worked out that “sg” stood for SiteGround, and then remembered that a couple of months earlier he had occasionally seen a SiteGround “verifying you are human” screen when he visited his own site. It flashed up for a second or less before the site loaded, so he had dismissed it.

That redirect is also why he could not simply view the captcha page’s source. The only other account of the problem he could find was a thread on SlickStack, where someone had posted the captcha page’s code, and it “HAS A META NOINDEX TAG IN IT” (his capitals): a meta robots noindex, nofollow. That explained the mechanism. Googlebot requested a page, SiteGround’s Anti-Bot AI decided it was a bot and served the captcha page instead, and Google took that page, noindex and all, as the real one and dropped the URL. The homepage and the most popular pages went first because Google crawls them most often; quieter pages stayed indexed until their turn came round.

His Search Console performance report shows what that did to the traffic. Daily clicks held at around 1,000 to 1,500 through January and into mid-February, slid to about 600 by the start of March, recovered briefly, then fell to between roughly 100 and 300 a day for the second half of March, about a tenth of where they started.

Why the filter fired at Googlebot on his sites, when as far as he could tell it does not on most SiteGround sites, he never established. His theory was that it happens when a SiteGround site also sits behind Cloudflare, or runs Ezoic ads, or both, and that the way those services route traffic trips SiteGround’s brute-force detection. SiteGround support thought it was Ezoic. He did not know which, and said so. A second site of his turned out to have the same problem.

The fix had to come from SiteGround. Its support team disabled the Anti-Bot AI on his hosting account; he then cleared the SiteGround and Ezoic caches and asked Google to recrawl the homepage and four other top pages, which came back indexed. The indexed-page count tells the rest: 270 pages on 27 December 2023, 227 on 27 January, 96 on 27 February and 62 on 27 March 2024, then, with the fix applied on 28 March, 296 pages the next day and 401 by 3 April. He does not know how long the site had been in that state before December, because Search Console only shows three months. One site lost most of its Google presence for about a quarter of a year, possibly longer, and he wrote that he would not sleep well knowing one manually disabled setting, if switched back on, would do it again. The same captcha page had also been making Google Analytics report organic visits as direct traffic, and disabling it fixed that too.

What tripped the filter on Vocational Media’s sites is Jon Payne’s best guess, and this week’s target is a published service address rather than Googlebot, but the same system made both decisions, and the customer still has no switch of their own for it.

How to Get the Block Lifted

The fix is a ticket to SiteGround support asking for both mySites.guru addresses to be exempted from the Anti-Bot AI on every site in your account. There is no self-service route: SiteGround’s Block Traffic tool in Site Tools can block IPs, ranges or countries, and has no allow option at all, so nothing you can do in Site Tools will stop the captcha. Use the Copy button and paste this into the ticket:

Ask for the addresses to be exempted, not a URL. An agent may offer to allow only the address in the log extract, usually bfPing.php, but that file is only the connection check; audits, backups and updates use other files in the same connector folder and would still get the captcha.

If you manage sites in more than one SiteGround account, send one ticket from each, because SiteGround will not act across accounts from a single ticket. List all the domains in that account in the ticket. How many tickets you then need depends on who answers: on 24 October a SiteGround agent told one of our customers that domains under the same hosting plan can go in one ticket and be whitelisted together in one pass, and on 25 October a Technical Support Supervisor told a customer to “open a separate support inquiry for each affected site”. Start with one ticket per account, and if an agent insists on one per site, send those too. Once applied, the exemption works. On 24 October SiteGround pasted its access logs for a customer’s site and both our addresses were getting HTTP 200, and on 25 October the supervisor confirmed both addresses “are whitelisted in the AntiBot CAPTCHA protection” for the site, so that “even if our system flags these IPs as suspicious in the future, their requests to this specific website will not be challenged.”

If an agent asks you to “confirm the security threats the website might be exposed to” before whitelisting, as one did this week, the answer is short. The only thing being exempted is two published addresses of a service you chose to connect to your own site, whose every request identifies itself and includes a contact email. Nothing else changes, and the Anti-Bot AI keeps judging every other visitor exactly as before.

SiteGround Could Fix This Once, for Everyone

None of this needs a ticket at all, because the thing SiteGround’s agent called impossible is a standard feature of other security products, and one of them already does it for us. Imunify360 keeps a global whitelist of known services as one plain-text file per service in a public directory at files.imunify360.com/static/whitelist/v2/. At the time of writing there are 131 of them, covering search engines, CDNs, payment gateways and uptime monitors: Cloudflare, Fastly, Google, Bing, Braintree, Adyen, Better Uptime and HetrixTools among them. mySites.guru has its own file, mysitesguru.txt. Its first line is # https://manage.mysites.guru/ips, naming our published page as its source, and it was last regenerated at 14:09 UTC on 23 October 2026, the same day a SiteGround agent told a customer that whitelisting had to be done site by site. Imunify360 builds its trusted list from these files automatically and rebuilds it when the lists update, as its support team explained to one of our customers in October 2026.

Imunify360 is not alone. Fetching an allow list from a URL and refreshing it on a timer is a documented feature of firewalls and bot filters across the industry:

pfSense

Its URL Table aliases are firewall rules fed from a remote text file: "URL Table type aliases contain one or more URLs which return a plain text a list of entries, plus an update interval which indicates how frequently the firewall should re-fetch the URL contents."

OPNsense

Its URL Table alias is defined in its manual as "A table of IP addresses that are fetched on regular intervals."

CSF firewall

Its GLOBAL_ALLOW setting will "download a centralized copy of an IP ALLOW, DENY, or IGNORE list from a URL", and the default config suggests 3600 seconds, once an hour, for the LF_GLOBAL refresh interval.

Cloudflare verified bots

Cloudflare's anti-bot system recognises a legitimate service from the service's own published list: "The bot owner can host a public list of IP ranges ... Cloudflare fetches and uses this list directly for validation."

Wordfence

The WordPress firewall allowlists known external services out of the box: "To avoid unintentional blocking of some external services such as Facebook, Wordfence allows these services." and "Some services are allowlisted by default." The list itself is sent to each site from Wordfence's servers, as the plugin source shows. Plugin authors get a hook for exactly our situation too: they can add their server addresses through a filter "if they have an external server, for example, that needs to communicate with their plugin. This prevents any unintended blocking that could prevent their plugin from operating normally."

Microsoft Azure service tags

A service tag stands in for a service's address ranges in a firewall rule, and "Microsoft manages the address prefixes encompassed by the service tag and automatically updates the service tag as addresses change."

AWS WAF

Amazon's own security blog "describes how to automatically update AWS WAF IP sets with the most recent AWS IP ranges for AWS services."

Google Cloud Armor

Its named IP lists allowed CDN providers by their published ranges: "Cloud Armor automatically synchronizes information from CDN providers on a daily basis." Google has since deprecated the feature, which makes it evidence that the pattern is established rather than a recommendation.

The pattern has two sides, and the services being allowlisted hold up their end. They publish their addresses for exactly this purpose, and most of them say so in the same breath:

Google crawlers

Google publishes Googlebot's ranges as JSON so that "you can identify Googlebot by IP address by matching the crawler's IP address to the lists of Google crawlers' and fetchers' IP ranges".

Bing

Bingbot's address ranges, published as JSON at a fixed URL.

Stripe

Stripe publishes the addresses its webhooks come from and notes that "these IP lists are available in other formats for import into iptables or similar tools".

GitHub

GitHub documents its addresses for firewall rules: "You can retrieve a list of the IP addresses for your GitHub environment from the meta API endpoint."

UptimeRobot

An uptime monitor, like ours, that invites you to "Download all IPs for allow-listing in .txt , JSON or directly from DNS".

Pingdom

Publishes its probe servers as a feed and says why: "You can use the IP numbers to open up for them in your firewall."

mySites.guru

Our two addresses in plain text, at the same URL, unchanged in over a decade.

Both sides already exist for mySites.guru: the list is published, and at least one security suite reads it. A single entry in SiteGround’s Anti-Bot AI, read from manage.mysites.guru/ips, would end this for every SiteGround customer who uses mySites.guru, with no tickets and no customer asked to confirm security threats they are not creating. Per-site, per-account allowlisting is a limit SiteGround has chosen.

We are not the only service on the wrong side of that choice. Other management and monitoring platforms have been hit by the same 202 captcha and told the same thing: ask SiteGround to whitelist your IP. Each of them connects from a known address, and their customers end up writing the same ticket, one site at a time, to lift a block that a published list would have prevented. SiteGround built the Anti-Bot AI to protect its customers from bots. Right now it stands between those customers and the services they chose to protect their sites with, and only SiteGround can change that.

SiteGround Knows Exactly Who We Are

This is not a dispute between strangers. In June 2012, in mySites.guru’s first year, SiteGround’s affiliate team asked me to recommend their hosting. I told them a lot of SiteGround customers were already coming to us to fix hacked Joomla sites on their servers, and the next morning SiteGround’s then CTO wrote to me, asking for more detail about the sites we were seeing and to exchange ideas. SiteGround then became a paying mySites.guru subscriber itself, through its own company accounts, for more than six years:

In those early years SiteGround’s founders were among the people we worked with to make our audits run well on mass-market shared hosting, which is a large part of why mySites.guru behaves the way it does on shared servers today.

The captcha is not new either. In July 2025 SiteGround’s support told us the challenge was down to email sent from customers’ sites, then confirmed after several days of monitoring that our IP “has not entered our WAF a single time”. It came back in July 2026, which is the earlier post, and again on 21 October. Each time it is the same address, the same service, and a host that has known both for over a decade.

Where This Leaves Us

The block is a SiteGround decision, made by SiteGround’s Anti-Bot AI on SiteGround’s servers, and only SiteGround can reverse it. mySites.guru has run out of things to change at our end. We connect from two fixed addresses that have not moved in over a decade and publish them in plain text at manage.mysites.guru/ips. Our requests name the service in their User-Agent and include a contact email in their headers, connector requests are signed with Web Bot Auth, and we run one audit per server at a time. Imunify360 already reads that published list and allowlists us globally. Over the years we have also tried to arrange a standing allowlist with SiteGround directly, without success.

mySites.guru protects more than 90,000 sites and makes well over a million connections to them a day, all from those two published addresses, all on behalf of site owners who connected their own sites. That is the record of a well-behaved automated service, the kind a bot filter should recognise from a published list rather than challenge. Until SiteGround makes that change, the only route is the ticket above, sent one account at a time, by customers who did nothing wrong, to unblock a service that did nothing wrong either.

Update, 24 October: We Solved the Captcha Ourselves

One of the answers SiteGround’s support gave customers this week was that mySites.guru should solve the captcha. So we did. Working through SiteGround’s challenge script with Claude, Anthropic’s AI model, we reverse engineered the proof-of-work behind the captcha page and built a solver into mySites.guru.

The challenge is simpler than the robot on the page suggests. A challenged request gets HTTP 202 and a page that refreshes to /.well-known/sgcaptcha/. That page gives the browser a challenge string and a difficulty, currently 21 bits. Eight background workers in the browser append a counter to the string and hash it with SHA-1 until the first 21 bits of the hash are zero, which takes about two million attempts on average. The browser sends the winning string back and receives an _I_ cookie, valid for 30 days across the whole domain and tied to the IP address that did the work.

mySites.guru now does the same work on its own servers, in PHP, in about a second, then keeps that cookie and sends it with every request to the site until it expires. We proved it end to end today from our production network, on a SiteGround site that had been showing as disconnected all week. It reaches every connection with our next release, and from then on audits, backups and updates on SiteGround-hosted sites reconnect without a support ticket.

Each site’s challenge is solved once, with only a handful of solves running at any moment across all of our servers, so the work cannot pile up on SiteGround’s machines or ours. If SiteGround makes the puzzle harder or changes it, our connections fall back to the same error you see today, and we can switch the solver off in seconds.

What we asked of SiteGround above still stands. A captcha that answers with noindex is a risk to your search rankings whoever it challenges, and a host that has known our address for over a decade should not need a puzzle to recognise it. The ticket is no longer needed to reconnect your sites, but it is still how you get our two addresses exempted for good.

Update, 25 October: Now It’s the Test Email

On 25 October a SiteGround Technical Support Supervisor gave one of our customers a fourth explanation this week. On 23 October the IP was “restricted … due to suspicious requests submitted to other websites”. On 24 October another agent was “not seeing these requests in our logs”. The supervisor’s version: “The IP address 178.62.5.35 was previously blocked there because it triggered emails from more than 15 different websites in a very short time. This activity pattern resembled contact form abuse, which triggered the protective block.” Which websites, the supervisor could not say, “as they are not managed by you”.

We can make a good guess at which emails those were, because they come to us. At the start of every audit, the site being audited sends one short test message, through its own mail settings, to our address AuditMailerTest@myjoomla.io, so the audit can report whether the site can send email at all. We wrote about that test in 2022. It is one email per site per audit, addressed to us and no one else. No contact form is involved, and audits run one at a time per server. A customer with 15 or so sites on SiteGround whose audits run across one evening produces 15 or so of these emails, one from each site, which matches the pattern the supervisor described. SiteGround also gave this explanation in July 2025, when it blamed “the intense usage of source=phpmail” and then, after several days of monitoring, confirmed our IP “has not entered our WAF a single time”.

If this is what tripped the block, then by SiteGround’s own definition ordinary behaviour gets you banned. Someone who buys from a few shops hosted at SiteGround in one evening gets an order confirmation from each one: emails from many sites, triggered by one IP, in a short time. An agency owner who logs in to several of their own sites, each running the Akeeba Admin Tools Joomla extension, gets a login alert from every one of them, all triggered from the same home IP, and that is now the address on the block list. Websites send emails when requests arrive. That is what they are for.

We have changed our product anyway. mySites.guru no longer asks sites on SiteGround servers to send the test email at all (the Email Configuration result was already hidden for SiteGround sites). We should not have to, because the email goes to us, from a site its owner connected. But of this week’s four explanations it is the only one with anything of ours to remove, so we have removed it.

The same reply ended with a request that contradicts the day before. On 24 October an agent said all the domains under one hosting plan could go in one ticket and be whitelisted together. On 25 October the supervisor wrote: “If you experience this issue on any of the other websites you manage, please open a separate support inquiry for each affected site, and we will whitelist the IPs there as well.” Both answers came from SiteGround about the same address within a day of each other, and the customer is left to guess which process is the real one.