Google Search Console Database Errors: Real Fixes

So you're staring at a Search Console error that says something about a database, and your first instinct is to SSH into the box and check MySQL. Stop. Don't do that yet.

The phrase "database error" in Search Console is almost always Google's database, not yours. Google runs crawled pages through an internal pipeline — Bigtable, Spanner, proprietary stuff — and when that pipeline has a hiccup, you get a generic error kicked back to the UI. Nine times out of ten, nothing on your end is broken. But there's a real ten percent where it is, and you need to know which one you're looking at.

Here's the breakdown, ordered by how often I've seen each one in 14 years of running web infra.

Cause 1: Google's Internal Crawl Pipeline Is Having a Bad Day

This is the one. If you're seeing intermittent database errors across multiple properties at the same time, it's not you. Google's crawler writes into a distributed database, and when a shard gets hot or a region fails over, the error surfaces in Search Console as a generic "internal error" or "database error" message. I've watched this happen three times in the last two years, and each time it resolved itself within 6-48 hours.

How to confirm it's them and not you:

1. Check status.cloud.google.com and the Google Workspace status dashboard. Search Console rides on the same infrastructure.
2. Open Search Console in an incognito window. If the error persists across sessions and browsers, it's server-side.
3. Fire a curl at the Search Console API directly. If it returns 500 or 503 with a Google-side trace, you've got your answer.

curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  "https://searchconsole.googleapis.com/webmasters/v3/sites" \
  -w "\nHTTP: %{http_code}\n"

A 500 here means Google's having issues. A 401 or 403 means it's your auth. A 200 means the API is fine and the error you saw was transient.

What to do: nothing. Wait. Set a reminder for 24 hours. If it's still broken after two days, then it's probably Cause 2. Do not submit reconsideration requests or start changing things — you'll make it worse and you'll confuse the historical data.

Cause 2: Your Sitemap or Robots.txt Is Feeding Google Garbage

This is the one that actually bites people. If your sitemap references URLs that 500 out of your own database, Googlebot will try to fetch them, get a DB error from your server, and Search Console will report it back to you as a database error — because from Google's perspective, the database on the other end failed.

Classic triggers I've seen:

• An e-commerce site where the sitemap generator queries a products table that gets locked during nightly backups. Googlebot hits it at 3 AM, gets a connection timeout, logs a database error.
• A WordPress site with a broken plugin that rebuilds sitemap.xml on every hit, hammering the DB until it refuses connections.
• A stale sitemap pointing at URLs that were deleted six months ago, so every fetch is a 500 from a missing row lookup.

Open your sitemap in a browser. Open it with curl too — see what the raw response looks like without your browser caching anything:

curl -sI https://example.com/sitemap.xml
curl -s https://example.com/sitemap.xml | head -20

If you get anything other than 200, or the XML is truncated, that's your problem. Regenerate the sitemap, and cache it static. Don't dynamically generate it. On a WordPress site, install a plugin that writes sitemap.xml to disk once an hour instead of on every request. On custom stacks, use a cron job to build the sitemap and let nginx serve the static file.

Also check your robots.txt. A stray Disallow: / combined with a sitemap that still lists everything creates a weird state where Googlebot tries, fails, and reports DB errors instead of a clean 403.

Cause 3: Your Own Database Is Actually Timing Out Under Googlebot Load

This is the 10% case. Googlebot crawls faster than you think — on a site with 50,000 URLs, it can easily hit 30 requests per second sustained. If your backend does a DB query per page load and you haven't indexed anything since 2019, you're going to fall over.

Symptoms: your monitoring shows a spike in MySQL slow queries coinciding with Googlebot hits in your access logs. SHOW PROCESSLIST shows queries stuck in "Sending data" for 10+ seconds. The Threads_connected metric spikes and then you get Too many connections errors, which Google reports as a database error.

The fix isn't to throttle Googlebot, it's to make the pages Googlebot fetches not hit your DB so hard.

1. Cache the HTML. Full-page cache at the edge (Cloudflare, Fastly) or in nginx with fastcgi_cache. Googlebot hits cache, cache hits memcached, DB never sees it.
2. Index your queries. Run EXPLAIN on the slow queries and fix the missing indexes. On a WordPress site with 100k posts, adding an index on wp_postmeta.meta_key can cut page load from 4 seconds to 200ms.
3. Set a proper max_connections. The default of 151 is way too low for any site getting crawled. Bump it to 500 and tune innodb_buffer_pool_size to about 70% of available RAM.

# In my.cnf or /etc/mysql/mysql.conf.d/mysqld.cnf
max_connections = 500
innodb_buffer_pool_size = 4G
innodb_read_io_threads = 8
innodb_write_io_threads = 8

While you're in there, add a rate limit on the origin. Not on Googlebot specifically — that's against their guidelines and can hurt your crawl budget — but a general connection cap so a runaway crawler can't take the whole DB down.

If your DB is buckling under Googlebot, it's buckling under real users too. You just haven't noticed because you have real users in the dozens, not the thousands. Fix the DB, don't blame the crawler.

Quick Reference

One last thing. Don't chase every Search Console error. Google surfaces a lot of noise. If your organic traffic is stable and your Core Web Vitals are fine, a handful of database errors on individual URLs probably doesn't matter. Fix the systemic issues, ignore the one-offs. That's the job.