"Site Down or Unavailable": The AdSense Rejection You Can Often Fix in Minutes

01What "site down or unavailable" points to

Google's public AdSense documentation is consistent on one prerequisite: the site you submit has to be live and reachable when it is reviewed. If the review fetch cannot retrieve your pages, there is nothing to evaluate, so the application closes on availability rather than on the quality of your content.

This is good news in one narrow sense. Unlike a content rejection, this one is usually mechanical — a setting, a certificate, or a rule somewhere between Google and your server — and mechanical problems tend to be findable.

It also means the timing matters. You do not control when the review fetch happens, so the site needs to stay reachable across the whole review window, not only when you happen to be looking at it.

02Why your site works for you but not for the reviewer

"My site works" and "my site is reachable from anywhere, by any visitor, right now" are different claims. Your own browser is close to the least reliable way to tell them apart. These are signals worth reviewing — any one of them may or may not apply to your site:

• A recent domain or nameserver change: your computer may still hold a cached address while the rest of the world does not resolve the domain yet.
• Country or IP-level blocking in a firewall or CDN rule — a reviewer's request may arrive from a country you have blocked.
• Bot protection serving an interstitial challenge page ("checking your browser") instead of your content to non-standard visitors.
• Shared hosting resource limits returning 5xx errors during traffic spikes, nightly backups, or plugin updates.
• An expired or mismatched SSL certificate — a tag that secures the connection — which stops the page from loading before any content is served.
• A maintenance-mode or "coming soon" plugin still enabled for logged-out visitors, while you see the real site because you are logged in.
• A password wall, staging protection, or age gate standing in front of the main content.
• A www / non-www mismatch: one version resolves, the other does not, and the URL you submitted is the one that does not.

03robots.txt and the crawler you may have blocked

Google publishes the list of user agents it crawls with, including a separate one used for AdSense ("Mediapartners-Google"). A rule that blocks unknown or non-browser user agents — often added by a security plugin with the best of intentions — can block that fetch along with the scrapers it was aimed at.

The same applies to robots.txt, the small text file at the root of your site that tells crawlers what they may request. A broad disallow rule left over from a staging setup is a common find.

Worth reviewing: whether /robots.txt disallows crawling of your homepage, whether your security plugin or CDN has a rule that filters by user agent, and whether your firewall logs show requests from Google being challenged or refused.

04The mistake we see most often

A pattern we see regularly across the blogs we review is checking the site from the one place least likely to reveal the problem: the same browser, on the same network, already logged in. The publisher concludes the rejection was a mistake and reapplies with nothing changed.

The second version of this is a sequence. Someone reads that they should secure the site before applying, switches the firewall to its strictest mode, and applies the same week — so the review fetch meets a challenge page that a normal reader in a normal browser never sees.

It is worth testing from outside your own setup before concluding the site was reachable.

05How to check your site the way a reviewer would

The aim is to reproduce an ordinary outside visit — a different network, no session, no cache — and to confirm it stays that way for more than a moment.

• Open the exact URL you submitted in a private window, on mobile data rather than your home or office network.
• Confirm both the www and non-www versions load, and that one redirects to the other consistently.
• Check that the SSL certificate is valid and not expired, on both versions of the domain.
• Request /robots.txt directly and review whether anything there disallows your homepage.
• Review firewall or CDN rules for country blocks and strict challenge modes, and check the logs for refused requests from Google's crawlers.
• Disable maintenance-mode or "coming soon" plugins, then confirm a logged-out visitor sees the real content.
• Review your host's uptime and error logs for 5xx responses around the days your application was under review.
• Reapply only once the URL has loaded reliably for outside visitors over a sustained period, rather than immediately after one successful test.