Traffic and SEO

Googlebot blocked (403) in Search Console? ManteIQ now alerts you the same day

Googlebot blocked by a firewall looks like nothing from your own browser: the shop loads and orders come in. Three new alerts watch for exactly that, and for the plain case of the shop being down.

By Mantas Lukošius6 min read
  • 100pages a day checked against Google's own record of its last visit
  • 10 minbetween checks that your home page opens for a visitor
  • −30%in weekly Google impressions is enough to raise a visibility alert

Why a blocked shop looks fine from the inside

Firewalls, bot protection and security plugins decide who gets in by IP address, country and behaviour. A rule that is meant for scrapers can just as easily catch Googlebot. You open the shop, it loads, orders keep coming from returning customers, and nothing looks wrong. Meanwhile Google gets a 403 on every page it tries to recrawl.

Search Console does record it, under Page indexing, as "Blocked due to access forbidden (403)". But that report updates slowly, nobody reads it every day, and the damage arrives gradually: pages drop out one by one, impressions slide, then clicks. By the time the traffic chart makes it obvious, the block has usually been there for weeks.

The fix for a blocked Googlebot is usually one rule in a firewall. The expensive part is the time nobody knew about it.

The Google access check: what Google saw, page by page

Once a day, for every shop with Search Console connected, ManteIQ picks about 100 pages and asks Search Console's URL Inspection how Google's last visit to each one went. Thirty of them are your core pages: the home page first, then the pages that earned the most from organic search in the last 28 days. The other seventy rotate, so over a few weeks most pages that get search traffic are looked at.

When Google was refused, ManteIQ opens the page itself, as an ordinary visitor. That one extra request is what tells the causes apart.

How the check reads a page Google could not open

Causes

Refused (403) or error
ManteIQ saw
The page opens
What it means
Google only. A firewall, bot protection or CDN rule is turning Googlebot away. Look there first.
Refused (403) or error
ManteIQ saw
Refused or error too
What it means
Everyone. The page or the server is broken for visitors as well.
Blocked by robots.txt or noindex
ManteIQ saw
Not needed
What it means
Your own settings keep Google out. Sometimes on purpose, often left over from a theme or a staging copy.
Not found (404)
ManteIQ saw
Not needed
What it means
Never an alert. Shops remove products all the time, and a 404 for a removed product is the right answer.

One thing to keep in mind: URL Inspection reports Google's last crawl, not a fetch made today. A failure from a crawl older than 14 days counts as unknown, because the fix may already be live and Google simply has not come back yet.

When the Google access alert fires

Alert levels

Google access

Critical
When
A home page is blocked, or 20% or more of the core pages are
Reminder
Every 72 hours while it lasts
Alert
When
At least 3 pages and the share you set in the rule (5% by default)
Reminder
Every 72 hours while it lasts
Nothing
When
404s, or failures older than 14 days

Each alert says what Google saw (refused, server error, robots.txt, noindex), the likely cause from the table above, how many pages are hit, and how much organic revenue those pages brought in the last 28 days. That last number is what decides whether this waits until Monday.

The Google access card on the Traffic page

ManteIQ's Google access card for a demo shop: Google can't open 18 of 100 checked pages, the bars of the last 30 checks rise over the last ten days, 2 pages have recovered since the previous check, and the cause reads that the pages open fine for us, so a firewall is most likely blocking Google, with about 3,240 € of organic revenue at risk over 4 weeks.
The Google access card on the Traffic page, shown with ManteIQ's demo shop.

The alert links to a card on the Traffic page. It shows the daily history of the check, the reasons, the likely cause, the revenue at risk and the state of your sitemaps as Search Console last read them. Below that is a table of the blocked pages, ranked by what they earn, each with a link to the same page in Search Console's inspection tool.

Once the block is fixed, Google still has to come back to every page. You can speed that up with Request indexing in Search Console, about ten pages a day. Tick each page as you request it and tomorrow's list picks up where you stopped. Pages that Google revisited after your request and still could not open are marked, and pages that came back are counted as recovered. The table exports to CSV.

The recrawl table for a demo shop: blocked pages ranked by organic revenue, three ticked as requested in Search Console, one marked still blocked after the request, with filters for requested pages and errors and a CSV button.
The recrawl list: tick a page once you have pressed Request indexing, and the next day starts where you stopped.

Shop down: your home page, every 10 minutes

The second alert is simpler. Every 10 minutes ManteIQ opens your home page the way a visitor's browser would, following redirects. A server error, a broken certificate, a domain that no longer resolves or no answer within 15 seconds counts as down. Three down checks in a row, about half an hour, is an outage, and a critical alert goes out with the time it started and what the server answered.

  • One failed check is never an alert. A single timeout at 3 a.m. is a blip, not a reason to wake anyone.
  • A 401, 403 or 429 is never counted as down. It means a firewall answered, so the server is up, even if it does not like our request.
  • If half of all shops look down at the same moment, the problem is our network, not yours, and that round of checks is not recorded.

Visibility drop: the weekly safety net

The third alert watches the outcome rather than the cause. When the last finished week's Google impressions are 30% or more below the average of the four weeks before, you get an alert with the click loss and, when the access check found a block, that block named as the most likely reason. Shops under 500 impressions a week are skipped, because at that size one quiet week means nothing. It reminds you weekly while the drop lasts.

What to do when one fires

  1. Open the card and read the cause. Google only means a rule somewhere is refusing Googlebot; everyone means the site itself is broken.
  2. For Google only, check the firewall, the CDN's bot settings and any security plugin, and look for blocked IP ranges or countries. Googlebot crawls mostly from the United States.
  3. Fix it, then request indexing for the top pages in the table, about ten a day, and tick them off.
  4. Watch the next days' checks. Pages move to recovered as Google comes back.

If Search Console is not connected yet, the Search Console guide walks through the setup, and the same steps work for any platform.

Turning it on

There is nothing to set up. All three alerts are already on for every shop, on the plans that include alerts, Daily and Multi-shop on the pricing page. The Google checks need Search Console connected. Alerts go to Telegram or email, whichever you chose in Settings, and each kind can be turned off there.

Your shop being open for customers and open for Google are two different things. Now both are watched, every day.

Questions

Does the check slow my shop down?
No. The uptime check is one request to the home page every 10 minutes. The Google check asks Search Console, not your shop, and opens at most 20 of your pages itself, only the ones Google could not open.
Is this a live Googlebot test?
No. URL Inspection reports what happened on Google's last visit to each page. That is what decides indexing, so it is the record that matters, but it lags a fix by the time Google takes to come back.
My shop blocks some bots on purpose. Will it alert?
Only when Google itself is refused on pages that should be indexed. A firewall answering our own uptime request with 403 is never counted as down.
Why are 404s never an alert?
Because shops remove products every week, and a 404 for a removed product is correct. A refused or broken page is a different problem.

About the author: Mantas Lukošius

Mantas has worked in ecommerce for more than 15 years, almost all of it on PrestaShop: from his own first shop to business stores and large clients. He builds ManteIQ. Ecommerce and the data behind it are still what he enjoys most.

How we write and check what we publish

More from the blog

All posts

See your own numbers every morning

ManteIQ reads your shop, GA4, Search Console and ads, and sends one briefing a day with what changed and why.

Try it free for 30 days
ManteIQ - Sees the change. Helps you act.