Job feed-image-url-validation-before-import · revised 11 October 2026
Check every supplier image link before products go live in your store
Each product in a named supplier feed gets an image result: working, redirected, missing, not an image, too small or unreachable. Products with bad images are held or flagged, not lost.
You might be seeing
- Product pages show a broken image or an empty box for some items after each supplier import
- An import that used to take minutes now stalls because one image host does not answer
No passwords, keys, card details or admin invites needed to start.
What usually happened
The importer stores whatever image address the supplier sends without checking that it returns an image. Addresses that redirect many times, return an error page with a success status, point at a different file type, are far too small or time out reach the store or the outgoing product feed, and one slow host can hold up the whole import.
Who it’s for: Merchant or distributor whose store, or a shopping feed, shows empty or broken product images after a supplier import.
Usually starts when: Products go live with blank image boxes, or a shopping platform rejects images, after an import, and the supplier's image links worked last month.
The result: A named feed sample passes through an image-check step that records, for each product, whether its image address returns an image, how many redirects it took, the type and size found and what happened if not. Addresses that point at non-public network destinations are refused and reported without being requested. Products with a failing image follow the agreed rule and the import finishes inside an agreed time even when a host is slow.
Check whether this job fits
Answer these without sending feeds, code or logins. Nothing is submitted unless you choose to contact us.
Checks you can run yourself
Open three addresses and read what you get
Paste three image addresses from the feed into a browser: one that shows in your store, one that is missing and one that redirects. Note what each shows.
Look for: A page that says not found but still loads as normal is the case a simple 'does it answer' check misses. A thumbnail much smaller than your store needs is another.
What you get
- A change to the import path with its tests
- The per-product image report for the agreed sample
- A note on the time limit, redirect limit, minimum size, failure rule and refused destinations agreed
- Steps to revert the change
Included
- One existing import path and one named supplier feed layout
- Add a check step that requests each public image address with a time limit and a redirect limit, records the final address, status, declared and detected type and size, and reuses one result per address within a run
- Refuse destinations that are not on the public internet: before every request and before following every redirect, resolve the address and refuse it, reporting it as refused, if it is a loopback, private-network or link-local address (including the cloud metadata address 169.254.169.254), and connect only to the address that was checked. A test-only setting, off by default, lets the local fixture server be reached
- Apply one agreed rule to a failing image: hold the product for review, or import it without an image and flag it
- Write a one-line-per-product report, and keep the request rate low enough for the supplier's host
- Add tests against a local fixture of eight image cases and four refused-destination cases
Not included
- Asking the supplier to fix its images or hosting
- Copying, re-hosting, resizing or editing supplier images
- Judging image content such as watermarks, overlays or whether the right product is shown
- Shopping-platform image policy decisions; for a Merchant Center data source, the Merchant Center jobs sort image faults by cause
- Checking image addresses in an outgoing shopping feed that has no supplier import path
- Checking hosts whose terms forbid automated requests
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Against the local fixture, each of eight image cases is classified as expected: a working image, a missing file, a permanent redirect to an image, a redirect loop, an error page returned with a success status, a file whose type does not match its extension, an image below the agreed minimum size, and a host that does not answer within the time limit.
Evidence: The fixture list with expected and recorded classification for each case.
Against the same fixture, with the test-only setting off, four refused-destination cases are each refused and reported as refused, and no request reaches the target: an address on the loopback network, an address in a private network range, a link-local address, and a public address whose redirect leads to one of those three.
Evidence: The fixture list with expected and recorded result for each case, and an empty request log from a listener on the loopback address.
The agreed 20-row sample finishes within the agreed time limit although one host never answers, and every product is imported, held or flagged exactly as the agreed rule states.
Evidence: Run duration, and a count of products in each outcome that adds up to the rows read.
The per-product report lists the original address, the final address after redirects, the status, the declared and detected type, the byte size and the action taken, one line per product.
Evidence: The report for the agreed sample.
The import's existing tests still pass with the change applied.
Evidence: Full test run output attached to the change.
Sign-off. You inspect the fixture results and the sample report and sign off in writing. Payment follows sign-off; applying the change live stays with your maintainer.
If it fails. If the agreed fixture and sample do not produce the agreed results, you do not pay for this fixed scope. We hand over what we found and agree whether to stop or re-quote; no surprise work.
When it fits, and when we stop
It fits when
- The import code is shareable through an agreed route and runs locally on synthetic data
- The supplier's image addresses are public, and the supplier's terms do not forbid automated requests for them
- You can state roughly how many products and image addresses one run holds
We stop and tell you if
- The image addresses need a login or token that would have to be handed to us
- The supplier's terms or robots file forbid automated requests for its images
- The import runs inside a hosted platform where no check step can be added
What could go wrong
Before you merge, closing the change leaves the import as it was. After merge, your maintainer can revert the named commit and the import returns to storing addresses unchecked. Products held by the check are released by the revert only if your own process does so.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A supplier feed lists an address that points at your own internal network or a cloud metadata service, so the check makes your server request something it should not (server-side request forgery). | The check refuses loopback, private-network and link-local destinations before every request and every redirect, connects only to the address it checked, and a fixture case for each is part of acceptance. |
| The check floods a supplier's image host or breaks its terms. | Requests are limited in rate, cached per address and only made to hosts you confirm allow them. |
| A HEAD request answers differently from a real fetch, so a broken image looks fine. | The check falls back to a real fetch where a host's answer to a metadata request lacks the type or size, and the fixture includes such a host. |
| Products with bad images vanish from the store without anyone noticing. | Every product is either imported, held or flagged under the agreed rule, and the report accounts for each row. |
An independent reviewer checks the fixture results, that the request rate and timeouts are bounded, that private, loopback and link-local destinations are refused including through a redirect, that no product is silently dropped, and that no credentials are used. Your maintainer reviews and applies the change.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the import path, the failure rule, the limits and the fixture cases in writing
- Build the local fixture of eight image cases and four refused-destination cases, and record how the current import treats each
- Add the check step with a time limit, a redirect limit, a per-address cache, a low request rate and the refusal of non-public destinations
- Apply the agreed failure rule and write the per-product report
- Run the fixture, the agreed sample and the existing tests, including a host that never answers
- Independent review, then hand over the change, report and revert steps for your maintainer to review and apply
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, the total price, a start window and a delivery date before you accept. Work starts only after agreed inputs, secure access and any needed permissions are in place. Hosting, supplier and platform charges are excluded unless the written quote includes them. An enquiry creates no charge or booking.
Need to keep it working?
Discuss a standing check that tests image links on every new supplier file.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Ask the supplier for a bulk image archive or a current image feed. A link check cannot create an image that the supplier no longer has.
- Check whether your store platform can hide or hold products that have no working image before building anything.
Questions
Will you copy my supplier's images to my own server?
No. This job checks addresses and reports. Copying images raises rights questions that belong with you and the supplier.
What happens to a product whose image fails?
Whatever rule we agree: held for review, or imported without an image and flagged. Nothing is dropped silently.
Does a working image address mean Google will accept the image?
No. A shopping platform judges size, content and policy. This job only shows that the address returns an image.
Send an enquiry
Send us
- Five to ten invented or redacted feed rows with image addresses of the kinds that fail, as text
- Roughly how many products and images a run holds, and how long the import takes today
- What you want to happen to a product with a bad image. No credentials, customer data or code in the first enquiry
Later, once you agree
- The import code through an agreed company-controlled route, with local run instructions
- Written agreement on time limit, redirect limit, minimum size and failure rule
- A named person who can accept the change
You keep the import code, your store and the supplier relationship. We work on a copy of the code with synthetic rows and a local fixture, and request only public image addresses that you confirm may be requested. We do not hold logins to the supplier's hosts.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “feed-image-url-validation-before-import” as the subject.