Disallowed Image: When Blocking Images in robots.txt Hurts You

What this means

Your robots.txt file tells crawlers which URLs they may and may not request. A "Disallowed Image" flag fires when an image URL on your pages matches a Disallow rule in robots.txt. The image still loads for human visitors (robots.txt does not block browsers), but compliant crawlers such as Googlebot and Googlebot-Image will not fetch it. Because the file is never retrieved, search engines cannot read its content, store it, or serve it in image results.

This is different from a broken or missing image. The file exists and works; a rule in your own configuration is simply telling crawlers to stay away.

Why it matters

Three practical reasons to care:

• No Google Images visibility. A blocked image cannot be indexed in Google Images. For recipe sites, product catalogs, portfolios, and publishers, image search can be a meaningful traffic channel that a robots.txt rule quietly removes.
• Weaker content understanding. Google uses images, along with their alt text and surrounding context, to understand what a page is about. If a key product shot, diagram, or hero image is off-limits, you lose a signal that supports relevance.
• Core Web Vitals risk. If the blocked file is your LCP element (often a large hero or feature image), blocking it can complicate how Google renders and evaluates the page. Pair this fix with a healthy LCP, since the main visual of the page should be both fast and crawlable.

How it gets flagged

Sitebulb raises this as the "Disallowed Image" Hint under Indexability. It triggers for any internal URL whose content type is an image where the path is blocked by a Disallow rule, and Sitebulb marks it Critical, meaning it can have a serious adverse impact on organic search traffic and should be treated as high priority.

Screaming Frog surfaces the same problem through the "Blocked by Robots.txt" filter in the Response Codes tab. The "Matched Robots.txt Line" column tells you exactly which directive is blocking each URL, which makes the offending rule easy to isolate. When JavaScript rendering is enabled, blocked image resources also appear under "JavaScript > Pages with Blocked Resources." Google Search Console will likewise report affected image URLs as "Blocked by robots.txt."

How to fix it

Work through these steps:

1. Confirm the image should be public and indexable. If yes, continue.
2. Open your robots.txt (at https://yourdomain.com/robots.txt) and find the rule matching the image path. The tool's matched-line column points you straight to it.
3. Remove the rule, or narrow it so it no longer catches your real images. A common culprit is a broad block on an uploads or media directory, or a wildcard on a file extension.

Example of an overly broad block and a corrected version that keeps a private folder closed while letting the main image directory through:

# Before: blocks every image under the uploads folder
User-agent: *
Disallow: /wp-content/uploads/

# After: keep crawlers out of a private subfolder only
User-agent: *
Disallow: /wp-content/uploads/private/

# Optional: explicitly allow a path inside a blocked folder
User-agent: *
Disallow: /wp-content/uploads/private/
Allow: /wp-content/uploads/private/public-banner.jpg

After editing, re-test the image URL in Google Search Console's robots.txt tester or recrawl in your audit tool to confirm the rule no longer matches. For the full syntax of Disallow, Allow, wildcards, and user-agent groups, see our robots.txt complete reference. To make sure unblocked images also carry strong filenames and alt text, review our image SEO guide, and if a hero image is your main visual, confirm it is crawlable and fast in our LCP complete guide.

When it is intentional

Not every disallowed image is a mistake. The block is correct and the flag is a false positive when the image is something you never want in search:

• Tracking and analytics pixels (often 1x1 transparent images).
• Private, gated, or member-only assets.
• Internal admin, staging, or system graphics.
• Watermarked previews where you deliberately keep crawlers out.

In these cases, leave the rule in place. You can mark the item as handled in your audit tool so it stops appearing as an open issue. The point of the check is to make the decision deliberate, not to force every image open.

FAQ