Should you be worried about 'other error' issues with images in the Search Console?

Why does the Search Console report these errors if they are normal?

Is this statement consistent with field observations?

Yes, and it is confirmed by years of technical audits. We regularly see perfectly indexed and well-ranked sites with hundreds of 'other error' messages on secondary resources. As long as the main HTML content loads correctly and the JavaScript rendering does not block access to critical elements, Google doesn't care about failed Facebook pixels or AdSense ads.

However, there is an important nuance: if an 'other error' concerns a CSS or JavaScript file essential for rendering the main content (navigation menu, text container displayed via JS, poorly implemented lazy-loading), that’s when it becomes problematic. Google will not see the content, and indexing will suffer. The issue is therefore not the error itself but the nature of the blocked resource.

What nuances should be added to this statement?

Martin Splitt simplifies intentionally for a broad audience, but two scenarios deserve attention. First scenario: images critical for image SEO. If you are actively optimizing your visuals for Google Images (e-commerce, portfolios, galleries), persistent errors on image files may prevent their indexing in Google Images — even if the text page remains indexed in Search.

Second scenario: Core Web Vitals. A resource generating repeated 'other error' messages can also cause timeouts, slow down rendering, or degrade LCP (Largest Contentful Paint) if it blocks the loading of a visible element. Here, the impact is no longer direct on indexing but indirect via user experience and performance signals.

In what cases should you still fix these errors?

Three situations justify action. First, if the error concerns a critical JavaScript or CSS file needed to display the main content — test by disabling the resource in DevTools to check the impact on rendering.

Second, if you are focusing on image SEO and the errors affect your strategic visuals — ensure that Google Images can crawl your files and that the alt, title, and ImageObject structured data attributes are in place. Third, if the errors degrade your Core Web Vitals (timeout, blocking time, slowed LCP) — audit third-party scripts, switch to async/defer, or consider a server-side GTM for the pixels.

What should you do with these errors in the Search Console?

First step: identify the nature of the erroneous resource. Open the URL inspection tool, go to the 'More info' tab, section 'Page Resources', and locate the 'other error' lines. Note the affected URLs — are they images, third-party scripts (analytics, ads), or critical CSS/JS files?

If they are tracking pixels, ads, or non-strategic images, ignore them. Google makes it clear: these errors are normal and have no impact. However, if a critical resource (navigation JS, layout CSS, hero image in LCP) shows as erroneous, then it's necessary to investigate — check HTTP headers, robots.txt rules, server timeouts, and test loading from different user agents.

What errors should be avoided when handling these reports?

Classic mistake number one: panicking and wanting to fix everything at all costs. Hundreds of 'other error' messages on Facebook pixels or AdSense scripts do not deserve an hour of debugging — your time is better spent elsewhere (internal linking, content optimization, loading speed).

Second mistake: blocking third-party resources via robots.txt to 'clean' the reports. It’s pointless — Google will continue to detect loading attempts, and you risk breaking rendering if these scripts affect the content display. Third mistake: ignoring errors on critical files just because 'Google said it's normal'. Be nuanced — the statement concerns non-essential resources, not structuring files.

How to check that my site remains indexable despite these errors?

Use the URL inspection tool to compare Googlebot's rendering with user rendering. If the main content (H1 titles, paragraphs, internal links) appears well in the Googlebot screenshot, you’re good — 'other error' messages on secondary resources do not pose a problem.

Also, check the Core Web Vitals metrics in PageSpeed Insights. If errors on third-party scripts degrade your LCP or Total Blocking Time, consider cleaning up: switch to async/defer, lazy-load pixels, or implement server-side GTM to reduce third-party requests on the client side. Finally, for image SEO, test the indexing of your strategic visuals through a site:yourdomain.com search in Google Images — if your key images do not appear, then, yes, errors merit investigation.

• Identify the nature of erroneous resources (critical vs. secondary) via the URL inspection tool
• Ignore 'other error' messages on tracking pixels, ads, and non-strategic images
• Check Googlebot's rendering to ensure the main content displays correctly
• Audit Core Web Vitals if third-party scripts degrade performance (LCP, TBT)
• Test Google Images indexing for strategic visuals (e-commerce, portfolios)
• Never block third-party resources via robots.txt to 'clean' reports — it doesn’t work