Expiring CDN Product Image URLs and Google Image SEO: A Delivery Design and Response-Check Guide

A public product gallery that loads signed, time-limited CDN image URLs can render correctly for visitors while individual images fail for Googlebot-Image, because the signature may be valid at browser-fetch time but expired at crawler-fetch time. This guide separates four states that are usually conflated — a stable discoverable image address, an expired image request, crawl permission, and private media — and maps each to documented Google behavior. It then recommends a public image delivery design (stable unsigned addresses for indexable product images, signed URLs reserved for private media, CDN domain verified in Search Console, image sitemap coverage) and a per-image response-check sequence that records HTTP status, signature validity, robots.txt access, and sitemap presence. No Google image refresh interval is asserted; the supplied documentation does not state one, and a stable URL is not a guarantee of indexing or ranking.

The problem: a product gallery that looks fine in a browser but may fail for Googlebot-Image

A product gallery can look perfect to every human visitor and still leave Googlebot-Image with nothing usable. One possible cause is a timing mismatch: the image address works when issued but is rejected after expiry. Markup and other access faults must still be checked.

When a gallery embeds product images through signed, time-limited CDN URLs, the HTML contains an image address that carries an expiry. A visitor’s browser requests the image within seconds of the page loading, while the signature is still valid, and the image appears. A crawler may request the same address much later — after the signature has expired. The page can be fully indexed while several of its images are not, and you cannot detect that by checking the page alone.

This is why "the gallery looks fine" is not evidence that image delivery works. It only proves the browser path works.

Four states get conflated in this situation, and they need to be separated before any fix is chosen:

• Stable discoverable address. The image URL is present in the HTML or an image sitemap and does not change or expire, so a crawler can find it and re-fetch it later.
• Expired image request. The URL is present, but the signature is no longer valid when the request arrives, so the server returns an error status instead of the image.
• Crawl permission. The image path or CDN domain is allowed by robots.txt and is not otherwise blocked. A fetchable URL that is disallowed is still not usable.
• Private media. The asset is access-controlled and should not be indexed at all. This is a deliberate exclusion, not a failure.

A gallery can be in all four states at once: some images stable and public, some expired, some blocked, some private. Treating them as one problem leads to the wrong fix — for example, rewriting alt text when the real issue is that the image URL returns an error status.

As a hypothetical illustration (not a real client, test, or observed outcome): imagine a gallery whose HTML embeds signed image URLs that expire quickly. A visitor loads the page and sees every product photo. A crawler arrives after the signatures have lapsed and receives error responses for those image addresses. The page itself may still be indexed, so nothing looks broken in a page-level report — yet the images are not being served to the crawler at all. The rest of this article treats that scenario as a design problem to be diagnosed, not as a measured case.

What Google actually needs from an image URL: discovery, fetchability, and a stable address

Before diagnosing expiry, it helps to separate two conditions that are often merged into one: discovery and fetchability.

Discovery is how a crawler learns the image URL exists. Google can find images in the src attribute of an <img> element, even when it is a child of other elements such as <picture>. Google does not index CSS images, so a background-image URL is not a discovery path. You can also provide the URL of images Google might not have otherwise discovered by submitting an image sitemap. Unlike regular sitemaps, image sitemaps can include URLs from other domains in the <image:loc> elements, which lets you use CDNs to host images.

Fetchability is whether the image URL returns usable content when the crawler requests it. This is where expiring URLs break. A signed URL is still a URL in the src attribute, so discovery is possible if the URL is present in the HTML or sitemap at crawl time. But the signed URL must be valid when Googlebot-Image actually fetches it. If the signature has expired by then, the fetch fails regardless of how clean the markup is.

A third condition is often assumed but not guaranteed: a successful response. Google states that for Google Search, an HTTP 2xx (success) status code does not guarantee indexing. So even a stable, fetchable, publicly accessible image URL is a candidate for indexing, not a promise of it.

Put together, the minimum conditions for an image to be considered are:

1. The image URL is discoverable — present in an <img src>, a srcset candidate, a <picture> source, or an image sitemap.
2. The URL is fetchable at the moment the crawler requests it — it returns content, not an error.
3. The URL is permitted — robots.txt does not block the image path or the CDN domain.
4. The hosting page is indexable, since the page’s content and metadata influence how and where the image may appear.

Expiring signed URLs satisfy condition 1 at publish time and can fail condition 2 at crawl time. That gap is the whole problem.

For a broader walkthrough of the discovery-to-indexing chain for images, see Google Image SEO: Discovery, Indexing, Context, and Performance Checks.

Official references: 1, 2.

What happens when a signed URL expires: 4xx, 5xx, and the difference it makes

The consequence of an expired signed URL depends on which status code the server returns. Google documents different outcomes for different status families, so the distinction matters.

4xx (client errors). Google does not use the content from URLs that return 4xx status codes. If a URL was previously used but is now returning a 4xx status code, Google systems will stop using the URL over time. In the case of Google Search, Google does not index URLs that return a 4xx status code, and URLs that are already indexed and return a 4xx status code are removed from the index. An expired signature that produces a 403 or 404 therefore does not just fail one fetch — it can remove an image that was previously indexed.

5xx and 429 (server errors). These prompt Google’s crawlers to temporarily slow down with crawling. For Google Search, already indexed URLs are preserved in the index, but eventually dropped. A CDN that returns a 5xx for an expired or malformed signature is a different failure mode from a 4xx: the documented processing differs from a missing-content response, but persistent server errors can still lead to removal. Do not infer a precise removal time from either status family.

Redirects. If an expired URL is configured to redirect somewhere, note that by default Google’s crawlers follow up to 10 redirect hops, and specific products’ crawlers may have different limits. A redirect chain that exceeds the limit is not followed to a usable image.

The exact status code returned by an expired signed URL depends on the CDN configuration, and should be checked against the CDN’s configuration and actual response. That is precisely why the response check in a later section records the actual status code rather than assuming one. The practical point is that "expired" is not one outcome: a 4xx path can remove an indexed image, while a 5xx path preserves it temporarily but degrades crawling.

If your concern is broader indexation loss rather than images specifically, How to Fix Declining Indexation: URLs, Canonicals and Sitemaps covers the page-level version of this diagnosis.

Official references: 1.

Designing a public image delivery scheme that survives expiry

The design principle follows directly from the failure analysis: separate public product images from private or access-controlled media, and give each the URL behavior it needs.

Public product images should have stable, unsigned URLs that do not expire. These are the images you want discoverable and indexable. A non-expiring public address removes signature expiry as one cause of failure. Successful retrieval still depends on the server, permissions and request-time response; stability alone does not guarantee availability. This is the single most important change if your gallery currently serves public product photos through signed URLs.

Signed URLs are appropriate for private media that should not be indexed. If an asset is access-controlled, a time-limited signature is a reasonable way to gate it — but it must not be exposed in public HTML or in an image sitemap. Publishing a signed URL exposes a discoverable address that may remain usable until it expires. It is neither guaranteed to fail every crawler request nor safe to treat as private simply because it contains a signature.

If a CDN is used, verify the CDN domain in Search Console. Google encourages verifying ownership of the CDN’s domain name in Search Console so that Google can inform you of any crawl errors it may find. Without that verification, CDN-side image failures may not surface in the reports you monitor.

Use image sitemaps to expose CDN-hosted image URLs. Image sitemaps can include URLs from other domains in the <image:loc> elements, which lets you use CDNs to host images. This is the supported route for making CDN-hosted images discoverable. Note the interaction with expiry: if a sitemap lists a signed URL, the sitemap entry becomes a dead URL once the signature lapses, so sitemap entries should point at stable addresses.

A simple decision split:

Asset type	URL behavior	In public HTML / sitemap?
Public product image	Stable, unsigned, non-expiring	Yes
Private / access-controlled media	Signed, time-limited	No

No specific expiry duration or CDN configuration is asserted here as universally correct. The right expiry for private media depends on your access model, and the cited Google guidance does not prescribe one. The design rule is about which assets get stable public addresses, not about a particular signing scheme.

For a related per-URL decision on whether two artifacts should both remain discoverable, Google SEO for PDF Product Datasheets and HTML Product Pages applies the same "same task or different task" reasoning to a different pair of URLs.

Official references: 1.

Concrete response checks for a product gallery with expiring image URLs

These checks turn the design principle into a repeatable per-image procedure. Record results per image, not per page, because a page can pass while individual images fail.

1. Fetch the raw HTML response, not the rendered DOM. List every image URL present in <img src>, srcset candidates, and <picture> <source> elements. Google can find images in the src attribute of <img>, even when it is a child of other elements such as <picture>, and it does not index CSS images — so a background-image URL will not appear in this list and is not a discovery path.

1. For each image URL, fetch it directly and record the HTTP status code and response headers. This is the fetchability check. A 4xx means Google does not use the content and previously indexed URLs are removed from the index over time; a 5xx or 429 means crawling slows and indexed URLs are eventually dropped. Record the actual code rather than assuming which one an expired signature produces.

1. Check whether the URL is signed and whether the signature is still valid at fetch time. If the URL carries an expiry parameter, note it. A URL that is valid now may be expired when a crawler returns later, which is the core failure mode.

1. Verify that robots.txt does not block the image path or the CDN domain. A fetchable URL that is disallowed is still not usable. Check both the path and the host.

1. Check whether the image URL appears in an image sitemap and whether that entry is still valid. Image sitemaps can include URLs from other domains in the <image:loc> elements, which lets you use CDNs to host images — but a sitemap entry pointing at a signed URL becomes a dead URL once the signature lapses.

1. Record results per image, not per page. A single row per image with columns for discovery source, HTTP status, signature status, robots.txt access, and sitemap presence gives you a record you can re-run after any delivery change.

These are method steps derived from documented crawler and image-discovery behavior. They are not a guarantee that a passing image will be indexed — Google states that for Google Search, an HTTP 2xx (success) status code does not guarantee indexing. The checks tell you whether the image is discoverable and fetchable; they do not predict indexing or ranking.

If the failure you find is at the page level rather than the image level, Google Not Indexing Pages: Diagnose One Exact URL by Index-Status Stage walks through the equivalent stage-by-stage diagnosis for pages.

Official references: 1, 2.

What this article does not claim: refresh timing, ranking outcomes, and private media exposure

Resolving an expired address removes a delivery fault, not every possible cause of low image visibility. Keep the following conclusions separate.

No specific Google image refresh interval is asserted. There is no fixed refresh interval asserted here. The checks tell you the current state of an image URL; they do not tell you when Google will next look at it.

A stable URL does not guarantee indexing or ranking. Google states that for Google Search, an HTTP 2xx (success) status code does not guarantee indexing. Moving public product images to stable, unsigned addresses removes a fetchability failure; it does not promise that those images will be indexed or will rank.

Image preview selection is automated. Google’s selection of an image preview is completely automated and takes into account a number of different sources to select which image on a given page is shown on Google. You can influence it through metadata, but you cannot control it directly, and a stable URL is not a lever on that selection.

Private media should not be exposed in public HTML or sitemaps regardless of signing. A signed URL in public markup may be discoverable and usable while valid, then fail after expiry. Keeping private assets out of public HTML and out of image sitemaps is the design requirement; the signing scheme is a separate access-control decision.

A cached browser view is not a fresh response test. To diagnose this specific fault, make a direct request to the same captured image address and record its time and response. Do not infer crawler success merely from a product photo already visible in your own browser.

What remains is a decision you can act on: give public product images stable, non-expiring addresses; keep signed URLs for private media and out of public markup; verify the CDN domain in Search Console; cover CDN-hosted images with an image sitemap; and re-run the per-image response checks after any delivery change. That is a design and verification method, not a ranking promise.

Official references: 1, 2.