Someone Is Using Your Images: How to Find Out and What to Actually Do

The discovery usually happens sideways. You are looking at a competitor's site for an unrelated reason and there is your photograph — the one your own photographer took, in your own workshop, on their services page.

The reflex response is to look up how to file a takedown. Which skips three questions that decide whether a takedown is even the right instrument: what harm is this actually doing, can you demonstrate the image is yours, and is the cheapest effective fix technical rather than legal?

Finding the copies

Three tools, three different indexes, and you want all three for anything you care about.

Google Images and Lens — drag the file in, or use Lens on a live page. Broadest coverage and best at identifying the subject as well as the file, which is useful and occasionally noisy. The mechanics of how visual matching behaves are covered in Google Lens and visual search.

Bing visual search — a separate index, so it genuinely surfaces different results rather than duplicating Google's.

TinEye — purpose-built for finding copies rather than similar things, with useful sorting by oldest and most-changed. Often the one that finds the version somebody cropped.

Two limitations to hold onto. They only match what has been crawled, so a copy on an obscure or blocked site is invisible. And meaningful edits break matching — a crop, a recolour, an overlay, sometimes just a heavy re-compression is enough. A clean result set is weak evidence that nothing is out there.

Which means the sane cadence is not "monitor everything". It is: pick the twenty images that actually matter — the ones with genuine commercial value, the distinctive photography, the images your brand is recognised by — and check those quarterly. Attempting continuous monitoring across four thousand files is how this task gets abandoned entirely.

Triage before response

Every result looks the same in the tool and means something different.

What you found	Real harm	Proportionate response
Hotlinked from your server	Your bandwidth, their page	Technical fix, no contact needed
Copied, credited, non-competitor	Usually none	Leave it, or say thank you
Copied, uncredited, direct competitor	Real, commercial	Contact, then escalate if needed
Copied onto a scraper or aggregator	Negligible	Ignore
Your generated image, reused generically	Usually negligible	Ignore
Your distinctive photography, sold on	Substantial	Take seriously, get advice

The rows worth dwelling on are the first and the last two.

Hotlinking is a bandwidth problem, not a theft problem

If another site embeds your image with your URL, they have not taken a copy. Their page loads the file from your server, which means you pay the transfer and you retain complete control — you could replace the file tomorrow and their page would display whatever you replaced it with.

The technical fix is referrer-based blocking, and there is a well-documented trap in it. The naive rule rejects any request that does not carry a referrer from your own domain. Search engine image crawlers do not send a referrer from your domain. Implement the naive rule and you have quietly excluded your images from image search — which is exactly the failure diagnosed from the other side in why images stop appearing in Google Images, where hotlink protection returning 403 to crawlers is one of the standard causes.

So: allow the legitimate image crawlers explicitly, and after deploying any such rule, verify your images are still being fetched and still appearing. Where your images live determines where this configuration belongs and which controls you even have — the reason the choice between same-origin, a CDN and a third-party host is worth making deliberately rather than inheriting.

Evidence, before enforcement

If you intend to ask anyone to do anything, you need to be able to show the image is yours. This is less automatic than people assume, because the evidence tends to live in the copy you no longer have.

Embedded creator, copyright and date fields inside the original file are the natural artefact — and they are routinely stripped from your published copies during upload and resizing, which is why the private archive matters more than the live site. Keep masters. Keep the generation or capture records. The publication date of the page that first displayed the image is often the most robust single fact available, because it is independently verifiable.

Populating those fields in the first place is worth doing even knowing they may not survive republication, and which fields carry weight is covered in what EXIF metadata does for SEO. Verify after upload rather than assuming, since most platforms discard them by default.

The response ladder

Escalate only as far as the harm justifies.

1. Do nothing. Genuinely the correct answer for scrapers, unrelated aggregators and generic imagery. Attention spent here is attention not spent on the site.
2. Ask for attribution. Frequently the reuse was thoughtless rather than malicious, and a short polite message produces a credit link. That is sometimes a better outcome than removal.
3. Request removal. Direct, specific, dated, with the original URL and evidence of your prior publication.
4. Use the platform's process. Hosts, CMS platforms and search engines all have reporting routes, and they are the effective channel when the site owner is unreachable.
5. Get professional advice. For genuinely valuable work and repeat infringement. Everything above this line you can do yourself; this line is where you should stop improvising.

None of the above is legal advice, and jurisdictions differ substantially on the detail.

The awkward part: is it yours?

Here is the question that reframes this whole subject for most modern sites.

If your page imagery is AI-generated, your ownership claim is genuinely less settled than it would be over a photograph you commissioned. The position varies by jurisdiction and in several turns on how much human authorship went into the result. That is not an argument for ignoring reuse; it is an argument for calibrating effort honestly. The details and the commercial-use implications are set out in copyright and commercial use of AI-generated images.

There is a second, more practical asymmetry. A generic generated image of a tidy workshop is not scarce. Someone else can produce an equivalent one in thirty seconds for a fraction of a cent. The harm from its reuse is close to zero, because its value was never in exclusivity — it was in being the right image for that page. Spending an afternoon chasing it is a poor trade.

Which produces a clear posture: protect the genuinely distinctive material — the real photography of your real work, your people, your premises — and let the generic generated imagery circulate without concern. That also means the near-duplicate problem runs in the other direction too, since generic imagery reused across many sites contributes to exactly the sort of duplicate and near-duplicate image clutter that makes any single copy less distinguishable.

What a removal request should contain

If you get to step three, the quality of the request determines whether it takes one exchange or five. Vague indignation produces nothing; specificity produces action, because the person receiving it usually has to justify the removal internally.

Include:

• The exact URL of the page using the image, and the exact URL of the image file itself. Not "your services page".
• The URL of your original, plus the publication date of the page where it first appeared.
• A statement of what you are asking for — removal, or attribution, or a licence conversation. Pick one. A message that lists three possible outcomes invites a reply choosing none.
• A deadline that is reasonable and that you are actually prepared to act on.
• Your contact details, so a cooperative recipient can resolve it in one reply.

Two tonal notes that materially change response rates. Assume inadvertence first — a large share of reuse is a contractor who pulled an image from a search results page without thinking about where it came from, and an accusatory opening converts a five-minute fix into a defensive exchange. And address it to a person where you can find one, because a generic contact form is where these messages go to expire.

Keep a copy of everything, including the page as it appeared. If the image comes down, your evidence of the original state comes down with it unless you captured it.

Monitoring without it becoming a job

The quarterly manual check is adequate for most businesses and it is also the thing most likely to be forgotten. Two ways to make it stick:

Attach it to something you already do. Fold the top-twenty reverse-image check into whatever periodic sweep already exists — the same pass that catches missing alt text and stripped metadata across the library, described in running a bulk metadata pass. A task inside an existing routine survives; a standalone quarterly reminder does not.

Paid monitoring exists, and is worth it rarely. Services will crawl for matches continuously and alert you. The honest assessment is that this earns its cost for professional photographers, stock licensors and brands with genuinely distinctive proprietary imagery — businesses where reuse has a direct revenue consequence. For a company whose site images are generated, it is spending money to be told about something that does not matter.

Prevention that does not ruin the image

Given all of the above, the preventative stack worth running is unglamorous and cheap:

• Embed credit and copyright fields in the master, and verify they survive publication where possible.
• Declare the licence in structured data. ImageObject with licence and acquire-licence properties gives a machine-readable statement of terms and can surface a licensable indicator in Google Images — the sanctioned route, covered in ImageObject schema and licensable images.
• Add a visible credit in the caption, which costs nothing and is read by humans.
• Configure hotlink protection carefully, allowing crawlers.
• Check your top twenty images quarterly.

And the thing not on the list, deliberately: a watermark across the frame, which costs clicks on every legitimate viewer to inconvenience an illegitimate one who will crop it anyway. The full trade-off, including the narrow cases where a mark genuinely is correct, is in do watermarks hurt image SEO.

As of September 2026 the tooling for finding copies is mature and the legal landscape around generated imagery is not. That combination argues for exactly the posture above: cheap detection, honest triage, real effort reserved for the images that are genuinely yours and genuinely valuable.

---

SEOpix writes creator, copyright and keyword metadata into every generated image at source, so attribution exists in the file from the moment it is created. See the metadata fields or start on the free plan.