A structured-data image or video address cannot be fetched
In the reportMarkup references an asset that could not be fetched
structured_data_asset_url_unfetchable · Issue
Read the recorded verdict for the declared address and the markup on every page that references it. An HTTP error, original DNS NXDOMAIN or a robots.txt disallow each needs a different correction.
Severity: Medium. Correct the address or the robots.txt rule in the templates that emit the markup. Read the recorded verdict first, because the corrections differ.
Why it matters
Structured data points to the image or video file that represents the marked-up content. An address that does not serve the file, or that Googlebot is not allowed to request, cannot supply it.
What to do
- Read the recorded property, the declared address, the verdict and the list of declaring pages.
- For HTTP 404 or 410, restore the file or update the markup on every declaring page to a working address.
- For DNS NXDOMAIN, check the declared host and any CNAME target. Correct the address or repair the DNS chain.
- For a robots.txt disallow, review the matched rule on the host that serves the file and decide whether Googlebot should be allowed to request it.
When to leave it as it is: A robots.txt rule that blocks a file can be deliberate. Keep it if the block is intended, and decide whether the markup should still name that file.
What we read
We read image, logo, thumbnailUrl, contentUrl and embedUrl values from typed schema.org items in the page's original JSON-LD, Microdata or RDFa. An image, logo or thumbnailUrl value can be a URL or an object with contentUrl or url.
A missing-file verdict needs an original unconditional GET response of 404/410 and a complete clear challenge check. DNS NXDOMAIN needs the original bounded A/AAAA acquisition to establish that outcome. The robots verdict uses the already captured robots.txt for the requested asset origin, evaluated for Googlebot; the audit reader’s own permission is separate.
The host-name and robots verdicts do not depend on an HTTP response to the file. Pages that declare the same normalized address form one group, identified by the originally declared address.
Example & evidence
Illustrative example — one VideoObject, a robots.txt rule and a recorded response, not a live audit.
{
"@context": "https://schema.org",
"@type": "VideoObject",
"name": "Decorating a layered cake",
"thumbnailUrl": "https://media.bakery.example/thumbs/cake.jpg",
"contentUrl": "https://media.bakery.example/video/cake.mp4"
}User-agent: Googlebot
Disallow: /video/If the robots.txt captured for media.bakery.example contains this rule, the contentUrl is reported as disallowed for Googlebot, whatever the file itself answers. If the recorded GET request for the thumbnail answers HTTP 404 with no challenge marker, that address is reported separately as missing.
A possible correction: allow Googlebot to request the video path or name a file it may request, and restore the thumbnail or update its address on every declaring page. Passing this check shows that the address answered and is not disallowed; it does not establish a rich result.
Confirm & check again
Check for yourself: Open the declared address directly. Look up its host name with a DNS tool, and read the robots.txt on the host that serves the file for rules that apply to Googlebot.
Check again: Full audit — Run a new full audit after the change is live. A retained reference needs a complete clean comparison using the same original asset address, confirmed DNS, known Googlebot permission and a qualified HTTP 200 response, across every previously recorded page. Completely read markup that no longer names the original address can also close the problem. Missing pages, partial sources, unread markup, uncertain DNS or robots.txt and unclear responses cannot prove a fix.
Limits & sources
HTTP 401/403/429, unconfirmed server errors, other inconclusive responses, timeouts, unresolved challenges and partial responses do not prove that the file was removed. Known HTTP 404/410, DNS NXDOMAIN or Googlebot disallow evidence can still produce a problem while an independent observation remains unconfirmed.
A robots.txt that answers 404 or 410 means no restriction for that host. One that is partial, oversized, answered with an error or cannot be decoded leaves Googlebot's permission unknown. The audit crawler's own permission is never used in place of Googlebot's.
We check recorded address availability and Googlebot permission. We do not validate the media format or play the file, and the result does not establish a rich result, indexing or ranking.
Untyped items, ambiguous references, markup added by JavaScript and markup beyond the audit's reading limits remain unconfirmed and prevent a complete fix comparison. A known problem can be reported while another declaration on the same page stays unconfirmed.
If an earlier audit could not record every declaring page, a later partial list cannot close the item.
Confidence: High Each verdict is bound to a recorded response, DNS answer or captured robots.txt from the audit. An unclear source is left unconfirmed, not reported.
Sources
- Google Search Central, Video structured data (VideoObject, Clip, BroadcastEvent) — Describes video markup and access to its referenced thumbnail and video content. Passing this audit check alone does not establish eligibility or display in search. Checked 11 October 2026.
Editorial review: 2 November 2026