Blog series "Proper Picture Credits": Part 4 - Remove images completely from the CMS after a warning letter

As long as the image is still available on the server, it can be reconstructed in log files and history which editor had uploaded and edited the image at which time. This data and information should be documented internally. Especially the time of the upload can be of importance later for the calculation of usage license claims by the image author.

In addition, the allegations from the warning letter should be compared with the information documented in the company image rights archive. Was there a transfer of rights that the warning party is not aware of? Did the image originate from an old clipart collection that was later bought up by a new rights user? Was the image correctly identified in principle, but a special condition (e.g. time restriction of use) was disregarded?

Under certain circumstances, clarifying the exact circumstances of the image use may therefore already invalidate the reason for the warning.

1. Does the media library or file management automatically generate its own pages for image display?
2. Is the image shown in an image gallery or image slider (e.g. on the homepage)?
3. Is there an article preview that uses the image?
4. Are there other language versions/translations of the article?
5. Is the image record linked to other pages or content elements in the CMS?
6. Does the CMS generate different image variants for "Responsive Images"?
7. Is a cache server or CDN used?
8. Was the image possibly in a versioning system and is it still accessible via older version addresses?
9. Can the image still be found on Google under its own server address?
10. Was the image used for official social media posts as a share image?

If additional versions of the image are discovered, the URL and name of all image files must be determined and listed. While it was originally sufficient to read the image address from the source code of the page, it is now better to search the finished rendered web page for the image file names. The best way to do this is to use the web developer tool that is integrated in all modern browsers. This is because some image variants may only be inserted into the page by JavaScript.

Deleting image files should not be started until the unique URL addresses of all image variants are available. With the removal of the image from the media library and the deletion of the image links from the affected pages, the majority of the found locations should quickly disappear automatically from the image list. However, problems occur especially with addresses on cache servers and CDN systems. Here, you may need the help of a system administrator or the CDN service provider to permanently delete all image mirroring.

Some time ago, it still seems to be a good solution to simply overwrite an explosive, flagged image in the CMS with a new, harmless image version. But since many CDN systems no longer update files with identical file names, we now advise against this method of image replacement.

If the critical image has been captured by Google Image Search, it can still be found there for a long time after deletion on your own CMS. In addition, the image will show up in the Google page cache for indexed pages. 

If you have verified your own website with Google Search Console, you can have the affected page or a single image hidden for 90 days. This period should usually be sufficient, since the originals of the images have been removed in parallel.

If you have not yet used Search Console for your own website, you should do so as soon as possible for such an occasion. There are no data protection problems and necessities (as with the use of Google Analytics).

The situation is more difficult if the image has been used for official social media posts of the company. Unfortunately, there is not much more you can do here than delete the affected posts from your own channels. However, you have no influence if third parties have already shared the images. The legal situation is particularly critical because the social media services were usually granted an unauthorized right to use the disputed file when the file was uploaded. At this point, it can only be pointed out once again that it is safer to only use images with positively and clearly clarified usage rights as share images.

This concludes our small series on the topic of correct image credits in the CMS. What experiences have you had with copyright and image credits? We would be pleased if you report on this in a comment.