Your China-based production partner has delivered the new product photo. Your store shows it. A Google product ad still shows the earlier angle. Before requesting another export, find out which handoff has actually happened: approving the photograph, submitting its address or observing its adoption by the channel.
These are different deliverables. For an overseas brand buying recurring imagery from Chinese suppliers, defining them separately makes a photography quote easier to compare and a replacement easier to troubleshoot.
Keep a version stable; give a replacement its own address
Checked November 9, 2026, Google Merchant Center Help’s Image link specification recommends stable URLs rather than changing timestamps or session parameters on each product-data submission.
Its broken image link guidance says replacing image content at the same URL can take up to six weeks to be detected and crawled, and recommends changing the filename and URL when changing the image.
ONCE’s interpretation is simple: keep each approved version stable, and submit a distinct address for an actual replacement. Stability does not require overwriting one file forever. Versioning does not require inventing a fresh URL every time a feed runs.
This is guidance about Google product-data images, not a rule for every advertising platform. The stated delay is a possibility, not a mandatory wait or a guarantee that a new URL will produce immediate display. This article is evergreen procurement analysis, not a report of a newly announced policy today.
ONCE’s three-stage image acceptance record
Approve the picture, hand off its address, then check the channel. A team may buy only the first stage or add the others, but one completed stage should not silently stand in for all three.
| Stage | What is accepted? | What is recorded? |
|---|---|---|
| Creative approval | The agreed product view, retouching and crop | Product identifier, image purpose, approved file version and approver |
| Hosting and product-data handoff | The hosted replacement is mapped to the intended product field | Actual image URL, item identifier, submission time and owner |
| Channel check | Processing state and observable display have been reviewed | Check date, observed version, unresolved issue and next owner |
This is ONCE’s proposed delivery record, not a native Google report. It also defines responsibility. A studio without product-data access can deliver approved files and an accurate manifest; it should not claim to have changed a channel record it cannot access.
Test the address and inspect the submission separately
Open the handed-over image address directly and confirm the intended image appears rather than a preview page, old file or login screen. Have the commerce operator inspect the image address actually submitted for the item. A changed store page is not proof that the submitted product data changed with it.
Then inspect the merchant account’s processing state and record any channel display you can observe. A browser check establishes what that access path returned at that moment; it does not establish Google crawler access. A submission record establishes what was sent, not that the channel has adopted the image.
Keeping these observations separate is more useful than asking three teams whether the update is “done.” It gives the photographer, site team and media operator a specific next action.
Locate the break before buying more photography
Consider a hypothetical homeware brand replacing a product’s hero image with a clearer angle of the same item in the same color. If the operator still submits the old URL, repair that mapping. If the replacement address does not open directly, resolve hosting or access first. If the submission is correct and the account still reports processing, follow the actual state rather than commissioning an unsupported reshoot.
Return to creative production when the picture itself is wrong: the product, crop or relevant information needs correction. If the sales variant, color or included components also changed, the product owner must recheck image-to-offer accuracy. Do not alter attributes inaccurately just to make an update move faster.
For unchanged approved assets, retain traceable stable addresses. For an approved replacement, record which new address supersedes which earlier version. Decide retention of earlier files with their other uses and hosting agreement in mind; uploading a new image is not, by itself, a reason to delete every old asset.
Compare scope, not just the per-image rate
ONCE proposes three purchasing categories: image production and approval; hosting and product-data mapping; post-submission checking and exception follow-up. This is a scope model, not a rate card or a claim that every project needs all three services.
A file-delivery job can end with approved images and a product-purpose manifest. An implementation job can add old-to-new address mapping and submission records. A monitoring service should specify frequency, duration, item coverage and escalation. It purchases agreed checks and corrective work, not an immediate-display promise outside the supplier’s control.
Before scaling a catalog update, take one real replacement through the file-to-submission handoff. Extend the approach to work using the same data source and hosting method. Different stores, connectors or operators need their own confirmation; one successful item does not certify an entire catalog. No account test or measured saving is asserted here.
The durable asset is the relationship between versions
A folder called “final” cannot tell the next operator which approved picture belongs to an item, where it is hosted, which channels were checked or what remains pending. A maintained record of those relationships can.
For ONCE, that suggests a practical step from one-off photography toward managed product content: reuse a clear handoff record and assign exceptions explicitly. Whether this improves margins or reduces rework needs real project evidence. It is a service-design judgment, not a reported business result.
Explore ONCE’s video and commerce content research for related planning questions. When briefing ONCE, bring the product list, actual channels and replacement owners so the proposal can state which stage is included and what completion means.
Source notes
- Google Merchant Center Help, Image link [image_link], current documentation checked November 9, 2026; used for stable URLs and avoiding changing submission parameters.
- Google Merchant Center Help, How to fix: Broken image link, current documentation checked November 9, 2026; used for replacement-image filenames, URLs and possible detection delay.
The example and acceptance record are proposed methods. No client account, publication outcome or performance lift was tested.
