Search Console flags failed page resources that logs show loaded

A WooCommerce site owner reported in a r/bigseo thread that Search Console’s URL Inspection keeps listing images, fonts and other static files under “Page resources couldn’t be loaded” with the reason “Other error”. The server logs show Google fetching the same files with 200 OK. The site had dropped heavily for its main keywords since around mid-April.

The owner ruled out most of the usual suspects. They disabled plugins, switched the theme, turned off Elementor Pro, and confirmed Cloudflare was set to DNS only, so no CDN proxy sat between Google and the server. They then built a static HTML page outside WordPress with a test image outside /wp-content. Search Console still marked that image as failed, while the logs showed Googlebot-Image requesting it and getting 200 OK. The failure was not old data either: after new image files were uploaded, Search Console updated the failed URLs to the new ones. The host confirmed there was no Googlebot block and no firewall or rate limit on Googlebot, and no 403, 429 or 5xx response on the tested image requests.

The owner did report two server problems. CPU spiked to 100% at times, and GPTBot, OpenAI’s training crawler, had been driving high CPU until the host rate-limited it.

The 200 and the failure may be different fetches

The likelier explanation is that the log line and the report describe different requests. Googlebot-Image is Google’s image crawler. A 200 served to it proves the file was reachable at that moment. It does not prove that the fetch made while rendering the page succeeded, and intermittent CPU spikes are exactly the kind of fault a single clean log check misses.

Replies in the thread point the same way:

• Test limits. One commenter says the URL Inspection tool does not have the same level of resources as Googlebot, so live fetches often show failures. The same commenter still calls it the best view of what Google sees.
• Cache headers. Another says they saw this when their servers sent revalidate or no-cache on every JavaScript file, image and font, which told Google to fetch everything fresh on every page load.
• Scale. A third reports a homepage where 40 of 52 resources showed “Other error” while all returned 200.

None of these replies is confirmed by Google, and nothing in the thread shows the resource warning caused the ranking drop. A warning that commenters describe as common is a weak explanation for a mid-April traffic loss.

What to do

1. Open the rendered HTML and screenshot in URL Inspection. If the main content and product images are present, the failed-resource list is probably the test’s limits, and the traffic drop needs a different explanation. The page should still work if scripts and secondary files fail to load.
2. Check Cache-Control on static assets. If every file says no-cache or forces revalidation, give versioned files a long lifetime instead, for example Cache-Control: public, max-age=31536000, immutable.
3. Open the Crawl Stats report under Settings in Search Console and compare how much crawling goes to resources against HTML, as the commenter who raised cache headers suggests.
4. Match log timestamps to the CPU spikes. Failures during overload will not show up in a log sampled at a quiet moment. Confirm the requests are really Google with a reverse DNS lookup, as described in Google’s guide to verifying Googlebot, since anyone can fake a user agent.
5. When rate-limiting AI crawlers for load, limit the right one. GPTBot collects training data, while OAI-SearchBot feeds ChatGPT search, so throttling the search bot costs visibility there. Botify found OpenAI’s search bot now crawls more than its training bot.