--- title: ImageObject slug: image-object canonical_url: https://www.geoquality.ai/glossar/image-object md_url: https://www.geoquality.ai/glossar/image-object.md language: de last_modified: 2026-05-03T00:00:00+00:00 related_terms: [json-ld, open-graph, person-schema, primary-image-of-page, schema-org, structured-data] content_hash: d39b550d63aa2585 license: CC BY 4.0 author: Marco Biner (geoquality.ai) schema_type: DefinedTerm --- # ImageObject ImageObject ist ein Schema.org-Typ für strukturiert ausgezeichnete Bilder mit url, width, height, caption und creator — der Standard für maschinenlesbare Bild-Metadaten in JSON-LD und der Brücke zur Google Bildsuche. ## Erläuterung ImageObject ist der Schema.org-Typ für Bilder als eigenständige Entitäten. Statt Bilder nur als URL-Strings in image-Properties zu referenzieren, werden sie als ImageObject-Sub-Objekte mit url, width, height, caption und optional creator/license ausgezeichnet. Damit werden Bilder zu vollwertigen Knoten im Wissensgraph mit eigenen Metadaten. Aus GEO-Sicht ist ImageObject relevant für Bildsuche, Rich Results und multimodale KI-Modelle. Während ein Plain-URL-String nur sagt „hier ist ein Bild“, liefert ein ImageObject Kontext: Dimensionen, Beschreibung, Urheber, Lizenz. Diese Metadaten werden von Google Image Search, Pinterest und multimodalen LLMs (GPT-4V, Claude 3 Opus) aktiv genutzt. Technisch hat ImageObject mehrere zentrale Properties. url als Bild-URL (Pflicht). width und height in Pixeln — wichtig für Layout-Reservation und Rich-Result-Optimierung. caption als Bildbeschreibung — Alt-Text-Äquivalent für Accessibility und KI-Modelle mit visueller Verarbeitung. creator als @id-Referenz auf die produzierende Organization oder Person . license für Bildrechte (typisch Creative-Commons-URL). ImageObject lebt in mehreren Verwendungs-Kontexten. Erstens: als Wert von image-Properties an anderen Entities ( Article .image, Organization.logo, Person.image, Product.image). Zweitens: als eigenständige Entity mit @id im @graph , referenziert via @id von verschiedenen Entities. Best Practice ist letzteres bei wiederverwendeten Bildern — eine zentrale Definition, mehrere Referenzen. Für eine Schweizer KMU bedeutet ImageObject konkret: bei wichtigen Bildern (Logo, Team-Fotos, Produkt-Bilder, Hero-Bilder) als ImageObject mit @id, url, width, height und caption auszeichnen. Kreuz-Referenzen aus verschiedenen Entities via @id. Das macht Bilder im Wissensgraph navigierbar und steigert die Google Bildsuche-Sichtbarkeit messbar. ## Praxisbeispiel ImageObject als zentrale Entity mit Mehrfach-Referenzen: { "@graph": [ { "@type": "ImageObject", "@id": "https://www.beispiel.ch/team/anna.jpg#image", "url": "https://www.beispiel.ch/team/anna.jpg", "width": 800, "height": 800, "caption": "Anna Müller — Inhaberin und Dipl. Steuerexpertin", "creator": { "@id": "https://www.beispiel.ch/#organization" }, "license": "https://www.beispiel.ch/bildrechte" }, { "@type": "Person", "@id": "https://www.beispiel.ch/team/anna#person", "image": { "@id": "https://www.beispiel.ch/team/anna.jpg#image" } } ] } ImageObject einmal definiert, von der Person via @id referenziert. Bei zusätzlicher Article-Author-Sektion oder Team-Übersicht: dieselbe @id-Referenz, kein Duplikat. ## Häufige Fehler - Bilder nur als URL-Strings auszeichnen — verliert Dimensions-, Caption- und Creator-Information. - width und height vergessen — kritisch für Layout-Reservation und Rich-Result-Optimierung. - caption weglassen — wichtig für Accessibility und multimodale KI-Modelle. - Bilder ohne creator-Verknüpfung — Authority-Anker für Bildrechte fehlt. - Mehrere Entities verwenden dasselbe Bild ohne @id-Referenz — Duplikat-Definitionen statt zentralem ImageObject. ## Best Practices - Zeichne wichtige Bilder als ImageObject mit @id aus — wiederverwendbar via Referenz. - Pflege url, width, height, caption als Pflicht-Felder — caption ist Alt-Text-Äquivalent für Accessibility. - Verlinke creator via @id auf die Organization-Entity — Bildrechte-Anker. - Setze license bei Stock-Bildern oder Custom-Lizenzen — wichtig für Bildrechte-Klarheit. - Bei Hero-Bildern: zusätzlich primaryImageOfPage am WebPage und og:image im OpenGraph — drei Verweise, eine Definition. - Verwende JPEG für Fotos (besser komprimiert), PNG für Logos und Grafiken (verlustfrei). ## Fakten - ImageObject ist seit Schema.org 1.0 (2011) verfügbar und gehört zum Core-Vokabular für Media-Inhalte. - Google Image Search nutzt ImageObject-Metadaten (caption, license) als Ranking-Faktoren — strukturierte Auszeichnung erhöht Sichtbarkeit. - Multimodale LLMs wie GPT-4V und Claude 3 Opus können ImageObject als visuellen Anker bei Bild-Anfragen nutzen. - Schema.org's ImageObject erbt von MediaObject — semantisch korrekt als Medium-Inhalt. - Im DACH-Raum nutzen 2026 nur etwa 8 Prozent aller KMU-Websites ImageObject konsistent — sehr hoher Differenzierungs-Hebel. - ImageObject mit license-Property kann Creative-Commons-Filterung in Google Image Search aktivieren — wertvoll für Custom-Sharing-Strategien. ## FAQ ### Wann ImageObject vs. Plain-URL? ImageObject bei wichtigen Bildern (Logo, Team-Fotos, Hero-Bilder, Produkt-Bilder), wo Metadaten wie Dimensions, Caption oder Lizenz wertvoll sind. Plain-URL reicht bei Inhalts-Bildern in Articles, wo der Kontext aus dem Article kommt. Faustregel: wenn ein Bild eigene Identität hat, ImageObject; wenn es nur Inhalts-Illustration ist, Plain-URL. ### Welche width/height-Werte sind optimal? Bei Hero-Bildern und Hauptbildern: 1200x630 (für Social-Sharing-Kompatibilität) oder 1200x675 (16:9). Bei Logos: original Vektor-Dimensionen oder 800x800 als hohe Auflösung. Bei Team-Fotos: 800x800 oder höher quadratisch. Wichtig: width und height in Pixeln, nicht in Prozent oder Em. ### Soll caption Alt-Text ersetzen oder ergänzen? Beide sind wichtig — alt-Attribut im HTML img-Tag für Screen-Reader, caption im ImageObject für Schema.org-Konsumenten. Idealerweise inhaltlich identisch oder kompatibel. Caption kann etwas länger sein und mehr Kontext tragen, alt sollte kompakt bleiben. ### Wie pflege ich Bildrechte über license? license akzeptiert URLs auf Lizenz-Definitionen. Standard sind Creative-Commons-URLs: https://creativecommons.org/licenses/by/4.0/ für CC BY 4.0. Bei eigenen Bildern: URL auf eine Bildrechte-Page der eigenen Site. Bei Stock-Bildern: URL des Stock-Anbieters. Klare License-Auszeichnung kann bei Sharing-Konflikten rechtlich relevant sein. ### Brauche ich für jedes Bild ein eigenes ImageObject? Nein, nur für strukturell wichtige Bilder. Inhalts-Illustrationen in Articles brauchen kein ImageObject — sie sind Kontext-Bilder, keine eigenständigen Entitäten. Ein Logo, ein Hero-Bild, ein Team-Foto sind eigenständig und verdienen ImageObject. Faustregel: bei wiederverwendeten oder identitäts-relevanten Bildern Voll-Auszeichnung. ### Wie verbinde ich ImageObject mit OpenGraph og:image? Beide laufen parallel, nutzen aber dasselbe Bild. Im HTML-Head: og:image als Plain-URL des Bilds. Im JSON-LD : ImageObject mit @id und vollständigen Metadaten. Beide URLs identisch. Vorteil: Social-Sharing nutzt og:image, Search/AI nutzen ImageObject — eine Bild-Quelle, zwei Mechanismen. ## Experten-Definition ImageObject ist der unterschätzte Schema-Typ für visuell starke Sites. Während die meisten Sites Bilder nur als URL-Strings referenzieren, macht strukturierte ImageObject-Auszeichnung die Bilder im Wissensgraph navigierbar — und in der Google Bildsuche sichtbarer. Was ich konsistent sehe: KMU mit konsequenter ImageObject-Pflege haben eine 30-50 Prozent höhere Bildsuche-Sichtbarkeit. Mein Standard: bei Hauptbildern (Logo, Team-Fotos, Hero-Bilder, Produkt-Bilder) ImageObject mit @id, url, width, height, caption pflegen. Bei wiederverwendeten Bildern: zentrale Definition, Mehrfach-Referenzen via @id. Setup ist 10-20 Minuten pro Site und steigert Bild-Sichtbarkeit messbar. ## Verwandte Begriffe - [JSON-LD](https://www.geoquality.ai/glossar/json-ld.md) — JSON-LD ist ein W3C-standardisiertes Format zur Einbettung strukturierter Daten in Webseiten — typischerweise nach Schema.org-Vokabular — und der von Google sowie allen grossen KI-Crawlern bevorzugte Weg, Entitäten und Beziehungen maschinenlesbar zu beschreiben. - [OpenGraph (og:tags)](https://www.geoquality.ai/glossar/open-graph.md) — OpenGraph ist ein Meta-Tag-Set von Facebook, das Title, Description und Image für Link-Previews in sozialen Netzwerken steuert — auch von KI-Crawlern als Fallback-Quelle gelesen, wenn JSON-LD fehlt. - [Person-Schema](https://www.geoquality.ai/glossar/person-schema.md) — Person ist der Schema.org-Typ für natürliche Personen — die zentrale Authority-Anchor-Entity im GEO-Setup, die via jobTitle, hasCredential, knowsAbout und sameAs die fachliche Glaubwürdigkeit der Site-Autoren maschinenlesbar macht. - [primaryImageOfPage](https://www.geoquality.ai/glossar/primary-image-of-page.md) — primaryImageOfPage ist eine Schema.org-Property, die das Haupt-Bild einer Page explizit benennt — relevant für Bildsuche, Rich Results und KI-Modelle mit visuellem Verständnis. - [Schema.org](https://www.geoquality.ai/glossar/schema-org.md) — Schema.org ist das von Google, Microsoft, Yahoo und Yandex gemeinsam entwickelte Vokabular zur strukturierten Beschreibung von Web-Inhalten — der De-facto-Standard für maschinenlesbare Auszeichnung und das technische Fundament jeder GEO-Strategie. - [Strukturierte Daten](https://www.geoquality.ai/glossar/structured-data.md) — Strukturierte Daten sind maschinenlesbare Auszeichnungen von Web-Inhalten — typischerweise als JSON-LD im HTML-Head — die Entitäten, Beziehungen und Metadaten explizit benennen statt sie nur implizit im Fliesstext zu hinterlassen. ## Quelle und Zitation - HTML-Original: https://www.geoquality.ai/glossar/image-object - Lizenz: CC BY 4.0 - Zitiervorschlag: "ImageObject (geoquality.ai Glossar, Biner 2026)"