Case Study
Bluehost blocked Googlebot: how a 403 took a site from 45 search clicks a day to 2, and how we found it
The site loaded fine for every visitor. Google was being turned away at the door.
In July 2026, one of the websites we manage was on course for its best month in Google Search. Within a week, daily clicks fell from the mid-40s to about two.
The site was Freshly Folded, a laundry pickup and delivery business in the San Diego area. Nothing had changed on it. Pages loaded normally, forms worked, and customers noticed nothing. The problem only existed for one visitor: Google's crawler.
The growth before the drop
Through June and early July, Search Console recorded a new rolling 28-day click milestone almost every week: 500 clicks on June 5, 600 on June 14, 700 on June 22, 800 on July 1 and 900 on July 10. At that pace, 1,000 looked close.
By July 18, daily clicks were down to about two. By July 24, the rolling 28-day total had fallen to 767. A rolling total drops slowly, because each strong day leaving the window is replaced by a weak one. That is why the total keeps falling for a while even after the cause is fixed.
The clue that didn't fit
When traffic falls this fast, the usual suspects are a Google update, a manual action or a ranking collapse. One number didn't fit that story. Average position was 10.9 on July 22 and 11.0 on July 24. Clicks and impressions had nearly vanished, but the average barely moved.
Average position is only calculated from the impressions that still happen. If some pages drop out of search entirely, the ones that remain can keep the average looking steady. So a stable average position doesn't prove rankings are fine. Here it was a hint that the issue might be access rather than ranking. Google's own guidance on debugging traffic drops recommends looking at clicks, impressions, pages, queries and technical problems together for this reason.
What URL Inspection showed
We inspected several important pages in Search Console. The affected ones returned the same message: Page is not indexed: Blocked due to access forbidden (403). Google's most recent attempt to fetch them had failed. One location page's crawl on July 14 was refused with a 403.
A 403 means the server understood the request and refused it. Google's documentation is direct about what follows: content from a URL returning a 4xx status is ignored, and a URL that was previously indexed is removed from the index.
The Page indexing report also listed more than 200 non-indexed URLs spread across several categories. Those labels were misleading. The URLs had been hit by the same 403, whatever category Search Console put them in.
What the host found
We sent Bluehost support the affected URLs, the dates of the failed crawls and the screenshots. According to Bluehost, a web application firewall rule, ID 900934, had produced a false positive and was returning 403 responses to legitimate Googlebot requests across the site. The affected pages were a broad mix of page types, not one section.
Bluehost excluded that rule. The rest of the firewall stayed in place.
A 403 to Google isn't always a hosting firewall. It can come from a CDN or bot-management rule, a WordPress security plugin, IP or country restrictions, file permissions or server configuration. The 403 tells you access was refused. Only the logs tell you why.
How to check your own site
- Compare clicks, impressions and average position over the same period, then look at pages and queries to see whether the drop is sitewide.
- Inspect a spread of URLs, not only the homepage: a service page, a location page, a recent article, one page that still gets traffic and one that lost it.
- Run Test Live URL. The standard inspection result shows Google's last crawl. The live test shows whether Google can fetch the page now.
- Give your host evidence: two or three affected URLs, the failed crawl times, screenshots and the date the drop began. Ask for the rule ID and the reason each request was denied.
- Verify it's really Google before allowing it. Google documents two methods: a reverse DNS lookup followed by a forward lookup, or matching the IP against its published crawler ranges. A user agent that says Googlebot can be faked, so don't allowlist on that alone.
- Ask for the narrowest fix. Exclude the confirmed false positive rather than turning off the firewall.
- Request recrawls for a few priority URLs, then wait. Google says crawling can take a few days to a few weeks, and requesting the same URL repeatedly doesn't speed it up.
What happened next
After the rule was excluded, the affected pages passed the live tests we repeated. On July 21 the site recorded 25 clicks and more than 1,500 impressions, up from close to zero. We treated that as the start of recovery, not proof that every page was back.
The practical lesson for anyone who owns a website: when search traffic drops sharply and nothing on the site changed, check whether Google can fetch the pages before rewriting them. A site can look completely healthy to customers while a security layer sends a crawler away.
Where this fits in our work
Crawl monitoring is part of how we look after the sites we manage, and it's how this one surfaced. Ongoing search and site support is covered by our digital growth services. For the broader crawl and indexing checks, see our technical SEO guide, and to check index status across many pages at once, our guide to checking indexing with the Search Console API. The booking work behind the site is in the Freshly Folded case study.
If your search traffic fell and the cause isn't obvious, book a call and bring a Search Console screenshot of the drop.
Sources
- Google Search Central, Debugging drops in Google Search traffic.
- Google for Developers, How HTTP status codes affect Google's crawlers.
- Google for Developers, Verifying requests from Google's crawlers.
- Google Search Central, Ask Google to recrawl your URLs.
Explore our related services.