Boloop-made explanatory illustration: a dedicated image path exposes only images referenced by eligible public publications.
One Boloop guide already had a relevant illustration: it opened in the browser, had the expected dimensions and showed no broken image on the page. Looking only at the reading experience, it seemed ready to pass.
During a structured-data recheck on the afternoon of October 22, 2026, we followed the actual image URL and found it still used the general attachment endpoint. The response was 200, but /api/ was restricted by robots rules, and the image response carried X-Robots-Tag: noindex, follow. Displaying an image and allowing search engines to discover and use it were different questions.
Check the image and every place that references it
The check started with the guide’s actual img. We then compared BlogPosting.image and og:image; all three referenced the same attachment URL.
That mattered. Changing just one reference would give readers, structured-data consumers and sharing crawlers different entry points, making the problem easy to conceal temporarily. Before moving an image URL, find every public caller rather than patching only the field mentioned by one test.
Next came four checks: a complete GET really returned image bytes; the MIME type matched the actual file format; anonymous access did not depend on an administrator session; and crawl rules and response headers allowed the intended use. HEAD can quickly inspect status and headers, but cannot replace checking the complete image content.
Simply checking whether an image displays does not answer the anonymous-access and crawl-rule questions.
robots and noindex impose different restrictions
robots.txt tells crawlers whether they may crawl a path. A noindex response tells a crawler that has obtained the response not to index it. If the path itself is blocked, the crawler may never get the chance to read that header.
Changing one restriction to allow access does not automatically remove the other. Nor does a browser successfully displaying an image without following crawler rules establish what a search engine can do.
Google’s image guidance explains that images need to be discoverable as well as meeting search’s technical conditions. An image behind a restricted endpoint was the specific mechanism we needed to address. Whether the image would ultimately be indexed remained a later result.
Publication state should determine public access
An obvious shortcut is to add a crawl exception for the entire attachment directory. Boloop’s attachments also serve drafts, private content and non-public previews, however. One public article needing an image does not make every file in the same directory eligible.
We had already created a dedicated public path for work screenshots. Rather than copying files to a static directory, each request checks whether the image is still referenced by eligible, published, public, non-demo work; whether the resource and image remain in permitted states; and whether the file is a supported image type.
We applied the same approach to original-guide lead images with a dedicated /article-images/ entry point. The visible body, article structured data and sharing image reference it together. This entry point serves only eligible public original-article lead images, not every article attachment. The general attachment route retains its own rules instead of becoming an arbitrary public file outlet through an SEO fix.
Public discovery therefore needs the same publication facts as the CMS. Uploading a file in the editor, or allowing an administrator to preview it, is not publication to anonymous visitors.
Keep security headers and withdrawal behavior
A publicly crawlable image does not need every protection removed. We retained the image sandbox, nosniff, existing access budgets, and avoided reusable shared snapshots of publication eligibility.
Here, private, no-store prevents shared caches from retaining stale visibility decisions. HTTP caching and search indexing are different concerns. The presence of the word private alone does not make a public image inaccessible.
If an article is withdrawn, or an image is no longer referenced by eligible content, a new request should check eligibility again. Copies already downloaded by others cannot be recalled this way. An unguessable filename is not a substitute for permission checks either.
Production is not the place to repeatedly unpublish a real article just to demonstrate withdrawal. State changes are tested with isolated data; live checks then cover already-public resources and rejection controls. The two kinds of evidence retain their separate scope.
What the fix established
A read-only check at 15:13 Beijing time on October 22, 2026 found that the guide HTML referenced the new article-image path. An anonymous GET of the same image returned 200, the correct PNG MIME type and an index-allowing header. The new entry point was serving the image in production, beyond a local code change.
The release’s Google Rich Results Test records covered the English, Simplified Chinese and Traditional Chinese guides. All three recognized valid Article and Breadcrumb items and included the new image URL. Their fetch times that day were 15:12:43, 15:12:56 and 15:13:02 Beijing time respectively.
That adds actual fetch evidence beyond a browser displaying the image. It still does not prove that image search indexed or displayed it. The earlier green test could not erase the old restrictions, and the repaired green test cannot replace later indexing observations.
If your own images are visible but absent from search, follow this path: extract the real URL from the live page, inspect the complete response and crawl rules, find references in the body, Schema and sharing metadata, then verify public eligibility and withdrawal behavior. Finding the layer that restricts the image is more useful than repeatedly uploading another file.