C2PA und das WordPress-Thumbnail-Problem

Kurz: von selbst bleibt sie nicht erhalten. WordPress erzeugt beim Upload mehrere Bildgrößen neu, und die dafür zuständigen Bibliotheken GD und Imagick übernehmen C2PA-Manifeste dabei nicht. Wer die KI-Kennzeichnung retten will, muss in die Erzeugung der Zwischengrößen eingreifen und die maschinenlesbare Information – in der Praxis als XMP/IPTC-Marker – in jede Variante zurückschreiben, die im Frontend landet.

Das Original auf dem Server ist selten das Problem. Das Problem ist alles, was WordPress daraus macht.

Wie WordPress Bildgrößen erzeugt

Beim Upload eines Bildes ruft WordPress wp_generate_attachment_metadata() auf. Diese Funktion legt die registrierten Zwischengrößen an – thumbnail, medium, medium_large, large, dazu jede Größe, die ein Theme oder Plugin über add_image_size() angemeldet hat. Ist das Original größer als big_image_size_threshold (Standard: 2560 px), erzeugt WordPress zusätzlich eine herunterskalierte -scaled-Fassung und behandelt sie als neue „Originaldatei“. Seit WordPress 5.8 kann der Core außerdem WebP-Ausgaben mitgenerieren; AVIF kommt über Plugins oder eigene Editoren dazu.

Jede dieser Dateien ist eine Neukodierung. Und jede Neukodierung ist eine Gelegenheit, Metadaten zu verlieren.

Warum GD und Imagick die Manifeste nicht übernehmen

WordPress delegiert die Bildbearbeitung an eine von zwei Editor-Klassen: WP_Image_Editor_Imagick oder WP_Image_Editor_GD. Beide sind auf Pixel ausgelegt, nicht auf Provenienz.

GD liest und schreibt praktisch keine Metadaten jenseits eines Minimums – EXIF, IPTC, XMP und ein eingebettetes C2PA-Manifest fallen bei imagejpeg() oder imagewebp() weg. Imagick ist etwas besser, überträgt Profile und einige Metadaten-Container, kennt C2PA aber nicht als eigenständiges Konstrukt und behält es bei einer Format- oder Größenänderung nicht zuverlässig bei. In beiden Fällen gilt: Was die Bibliothek nicht ausdrücklich mitnimmt, ist nach dem resize weg.

Dazu kommt die Natur von C2PA selbst. Ein Content-Credential ist ein kryptografisch signiertes Manifest, das sich auf den exakten Byte-Inhalt der Datei bezieht. Sobald ihr die Pixel neu kodiert, passt die Signatur nicht mehr – selbst wenn ihr das Manifest mitkopiert, ist es gegen die neue Datei ungültig. Eine bit-genaue Weitergabe über alle Zwischengrößen ist also gar nicht das Ziel.

Warum im Frontend die unmarkierte Variante ankommt

Weil WordPress im Frontend fast nie das Original ausliefert. wp_get_attachment_image() und der Block-Editor schreiben ein srcset mit den Zwischengrößen, und der Browser wählt daraus die passende – bei einem typischen Content-Bild also medium oder large, nicht die hochgeladene Datei. Wenn die Kennzeichnung nur im Original steckt, sieht sie keine Maschine, die die ausgelieferte Seite prüft.

Das Verhalten ist in der WordPress-Entwicklung als offenes Thema dokumentiert und bis heute nicht im Core gelöst.

Lösungsansätze

Die realistische Lösung auf WordPress-Ebene ist nicht, das signierte C2PA-Manifest zu rekonstruieren, sondern die entscheidende Aussage – „dieses Bild ist KI-generiert“ – als leichtgewichtigen, maschinenlesbaren Marker in jede ausgelieferte Variante zu schreiben. In der Praxis über XMP beziehungsweise den IPTC-Wert digitalSourceType (trainedAlgorithmicMedia). Das ist das Format, das Prüf-Tools und Plattformen auch dann noch auswerten, wenn die Signatur längst gebrochen ist.

Drei Ansatzpunkte:

In die Sub-Size-Erzeugung einhängen. Der Filter wp_generate_attachment_metadata läuft, nachdem alle Größen geschrieben sind – hier könnt ihr über die zurückgegebene Größen-Liste iterieren und den Marker pro Datei nachtragen. Feiner steuerbar ist image_make_intermediate_size, das euch jede einzelne erzeugte Datei direkt nach dem Schreiben übergibt.

Einen eigenen Image-Editor unterschieben. Über wp_image_editors könnt ihr eine Subklasse von WP_Image_Editor_Imagick registrieren, die nach jedem save() die relevanten Metadaten aus der Quelldatei in das Ergebnis zurückschreibt. Vorteil: greift auch bei Zuschnitten und bei den zusätzlichen WebP-/AVIF-Ausgaben, die über image_editor_output_format entstehen.

Formatunabhängig arbeiten. JPEG, PNG und WebP nehmen XMP/IPTC über etablierte Wege auf. AVIF ist der Sonderfall: ein ISOBMFF-Container wie bei modernen Video-Codecs, für den ein eigener Schreibpfad nötig ist – und der sollte ohne die Imagick-AVIF-Delegation auskommen, weil die auf vielen Hostings nicht verfügbar ist.

Genau diesen Weg – Marker ins Original und in jede von WordPress erzeugte Größe, inklusive WebP und AVIF, hostingunabhängig – haben wir in einem Plugin gebaut. Die Umsetzung im Detail steht hier: KI-Bilder in WordPress kennzeichnen: C2PA, Thumbnails und der EU AI Act. Warum Kennzeichnung und Bildoptimierung dafür in denselben Verarbeitungsschritt gehören, hier: WebP, AVIF und KI-Kennzeichnung für WordPress. Wenn eine Standardlösung an so einer Stelle nicht reicht, entwickeln wir gezielt nach: WordPress-Plugin-Entwicklung.

Was ihr prüfen solltet

Ladet ein KI-Bild mit Content Credentials hoch, öffnet die im Frontend ausgelieferte srcset-Variante und lest die Metadaten aus – exiftool oder die Content-Credentials-Prüfung reichen. Steht dort nichts, habt ihr das Problem. Es liegt nicht an eurem Setup. Es liegt daran, dass WordPress Bilder als Pixel behandelt und nicht als Herkunft. Ein Beispiel für ein größeres Muster: technische Zusatzpflichten, die im Alltag leicht durchs Raster fallen – unsere Praxis-Checkliste dazu: BFSG-Praxisleitfaden für WordPress.

Zuletzt geprüft: 04.09.2026. Hook-Namen und Core-Verhalten beziehen sich auf WordPress 6.x.

Beitragsbild: Alexander Sinn / Unsplash