Why can I see my product image while Google reports a broken image link?

Inspect the actual feed URL

Copy the current image_link value from the affected product or source record, not the image address you remember uploading. Record the final host, file path and any redirects. A preview URL, signed link or link to an HTML download screen can work for the editor and fail for a crawler. Confirm that the response is the intended image rather than a login page with a successful page status.

Use a fresh anonymous browser window and ask your technical colleague to inspect a normal request and the relevant server access log. This is a delivery diagnosis, not permission to disable authentication across your website. Private source photographs should stay private; publish only the approved delivery copy.

For one authorized delivery copy, retain the literal submitted URL privately, the inspection time, redirect destinations, response status and content type, and which picture the returned bytes contain. A 200 response containing an HTML sign-in page is a failed image delivery. A private browsing check demonstrates that browser request only; it does not prove Google made the same request or reached the same edge server.

Distinguish the failure point

These observations narrow an investigation; a 403 alone does not identify which security rule caused it. Do not expose account storage or allow unrestricted access merely to remove an error.

Keep two columns in the incident record: observed fact and hypothesis. “The approved public image path returned 403 at the recorded time” is a fact. “A particular firewall rule blocked Google” requires matching authorized log evidence. A user-agent string alone is not authenticated crawler identity, so have the administrator use the host’s supported verification procedure rather than trusting a caller-supplied name.

Run a small controlled repair

Suppose a fictional bag image is hosted at an expiring task download. Export the approved asset to the store’s ordinary public media hosting, update only the corresponding feed image URL, and retain the old value in your change record. Recheck the public resource and the platform’s subsequent fetch. Keep the product ID and factual attributes unchanged unless their own evidence requires a correction.

Fictional before/after: the feed points to a signed preview that redirects to sign-in; a separately published, approved bag image returns the intended picture anonymously. Update only the feed reference through the authorized workflow, then record whether the processed record actually adopts it. Keep the first response and the later platform observation as separate evidence; neither an uploaded local file nor a successful ordinary browser request certifies a later crawler result.

Close with delivery evidence

Record the submitted URL, public response type, inspection time and later Merchant Center status. Never include a signed URL containing a credential in a public help post. When access is fixed but an image policy issue remains, evaluate the fetched picture separately. CartVisual generation does not configure your CDN, feed connector or firewall. Use the linked Google documentation to check the destination’s current image requirements.

Remove secret query values before sharing incident evidence. If delivery now succeeds but a policy issue remains, hand off the exact fetched version to the image-content review. Resolve one failure class at a time and retain any remaining unknowns.