Kostenloser Schema-Markup-Generator für JSON-LD

Schema-Markup ist eine maschinenlesbare Aussage über das, was eine Seite bereits enthält. Bei einem Artikel kann es Überschrift, Autor, Publikationsdatum, Bilder und Herausgeber benennen. Bei einer Produktseite kann der Graph Produkt, Marke, Angebot, Währung, Verfügbarkeit und eine echte aggregierte Bewertung beschreiben. Entscheidend ist bereits enthält.

JSON-LD macht aus dünnem Inhalt keine starke Seite. Es erzeugt keinen Autor, der in der sichtbaren Byline fehlt, macht keinen alten Preis aktuell und verwandelt keine Kategorieseite in ein einzelnes Produkt. Eine Suchmaschine soll die strukturierte Aussage mit der sichtbaren Seite vergleichen. Widersprechen sich beide, ist der Code keine hilfreiche Erklärung, sondern eine irreführende Behauptung.

Deshalb beginnt dieser Generator mit zwei klaren Wegen und endet mit Code. Wählen Sie KI-Unterstützung, wenn das Tool ein Profil empfehlen soll: Eine öffentliche URL liefert sichtbaren Text, Metadaten, kanonische Links und vorhandene strukturierte Daten; vor dem Launch wird eingefügter Seitentext zur Belegmenge. Wählen Sie direkt einen Schema-Typ, wenn die gewünschte Entität bereits feststeht und Sie ohne KI der geführten Formel folgen möchten. Der Startweg ändert, wie Fakten in den Entwurf gelangen; die endgültige Struktur gehört immer einem deterministischen Compiler.

Die Unterscheidung zählt im großen Maßstab. In SEOmators Audit-Panel von Januar bis Juli 2026 hatten 64,8 % der Websites mindestens einen kritischen Fehler in der Kategorie Strukturierte Daten. 47,9 % hatten auf geeigneten Seiten gar keine strukturierten Daten. Fehlendes Markup ist häufig, doch mehr Code allein ist keine Lösung. Der Code muss stimmen, gepflegt werden und zur sichtbaren Seite gehören.

Drei Fragen werden oft in einem einzigen grünen Haken zusammengefasst:

1. Lässt sich das JSON parsen? Ein JSON-Parser findet fehlende Kommata, kaputte Anführungszeichen, zusätzliche Zeichen und ungültige Objektstrukturen.
2. Ist das Vokabular in Schema.org sinnvoll? Der Schema.org Validator prüft Typen, Eigenschaften, erwartete Werteformen und Beziehungen im offenen Vokabular.
3. Ist die Seite für ein aktuelles Google-Suchfeature berechtigt? Googles Rich Results Test und die Feature-Dokumentation wenden eine kleinere, veränderliche Menge suchspezifischer Anforderungen an.

Ein Block kann die ersten beiden Prüfungen bestehen und trotzdem keine allgemeine Google-Rich-Result-Darstellung besitzen. Organization und WebSite können Entitäten beschreiben und verbinden, doch das ist nicht dasselbe wie ein Product Rich Result. HowTo bleibt gültiges Schema.org, obwohl es keine aktuelle allgemeine Rich-Result-Oberfläche besitzt. FAQPage ist gültiges Vokabular, aber Google beschränkt die sichtbare Behandlung auf einen engen Kreis autoritativer Gesundheits- und Behördenseiten.

Auch umgekehrt gilt: Ein bestandener Google-Test schafft Berechtigung, keinen Anspruch. Suchsysteme entscheiden für jede Anfrage und Seite, ob ein Feature erscheint. Seitenqualität, Richtlinien, Übereinstimmung mit sichtbarem Inhalt und die übrige Ergebnisseite zählen weiterhin.

Der Generator trennt deshalb Fehler, Warnungen und Hinweise. Ein Fehler blockiert eine sichere Produktionskopie. Eine Warnung weist auf empfohlene Felder oder Richtlinienrisiken hin. Ein Hinweis kann lediglich erklären, dass ein gültiger Typ kein aktuelles allgemeines Suchfeature besitzt.

Schema ist am klarsten, wenn der Hauptknoten dieselbe Frage beantwortet wie die Seite.

Eine Artikelseite sollte meist mit Article, BlogPosting oder NewsArticle beginnen. Eine einzelne Produktdetailseite kann Product mit einem verschachtelten oder verbundenen Offer führen. Eine konkrete Veranstaltung braucht Event, eine einzelne Stellenanzeige JobPosting. Eine Kontakt- oder Über-uns-Seite kann Organization oder LocalBusiness verwenden. BreadcrumbList beschreibt den sichtbaren Navigationspfad, ist aber gewöhnlich unterstützendes Markup und nicht die Hauptentität.

Mehr Typen sind nicht automatisch besser. Organization auf jeder URL kann Dutzende unverbundene Kopien derselben Firma erzeugen. Product auf einer Kategorieseite kann behaupten, die gesamte Sammlung sei ein einzelner kaufbarer Artikel. Zwei Überschriften mit Fragezeichen machen eine Seite noch nicht zu einer FAQ.

Der v1-Katalog unterstützt bewusst zwölf gepflegte Profile statt des gesamten Schema.org-Vokabulars. Jedes Profil hält erforderliche und empfohlene Eigenschaften, bekannte Werteformen, Google-Feature-Status, riskante Felder und das Prüfdatum der Hinweise fest. Diese engere Oberfläche lässt sich zuverlässig testen und deutlich schwerer veralten.

Enthält eine Seite wirklich mehrere Entitäten, verbinden Sie sie. Ein Article kann Autor und Herausgeber referenzieren. Ein Product kann ein Offer enthalten. Eine WebSite kann ihren Herausgeber benennen. Stabile Kennungen lassen diese Verweise auf eine Entität zeigen, statt lose Kopien zu wiederholen.

@id ist keine von Schema.org vergebene Datenbankkennung. Es ist ein URL-förmiger Name, den Sie kontrollieren. Ein vorhersehbares Muster macht die Entität über Seiten und Releases hinweg wiederverwendbar:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/ueber-uns#organization",
      "name": "Beispiel GmbH",
      "url": "https://example.com/"
    }
  ]
}

Das Fragment nach # muss kein eigenes Dokument auflösen. Es unterscheidet die Organisation von der Seiten-URL und hält die Kennung zugleich an der kanonischen Domain. Ein verwandter Knoten kann danach nur { "@id": "https://example.com/ueber-uns#organization" } verwenden, statt Name, Logo, URL und Profile erneut zu kopieren.

Konsistenz ist wertvoller als Originalität. Wählen Sie #organization, #person, #product, #software, #video oder ein anderes stabiles Fragment und bleiben Sie dabei. Vermeiden Sie Zeitstempel, Zufallswerte, Staging-Domains und URLs, die je nach Sprache oder Gerät anders weiterleiten.

Der Generator verlangt vor dem Produktionskopieren eine kanonische URL, weil stabile Kennungen und relative URLs eine Basis brauchen. Einen Textentwurf können Sie schon vor der Veröffentlichung vorbereiten. Mit der geplanten kanonischen URL wird der Graph einsetzbar.

Einige strukturierte Eigenschaften können Nutzer täuschen oder Richtlinien verletzen, obwohl ihre Syntax perfekt ist. Dieses Tool behandelt sie strenger:

• Bewertungswert und Bewertungsanzahl müssen echte, auf der Seite sichtbare Bewertungen beschreiben und gemeinsam vorkommen.
• Preis, Währung, Verfügbarkeit und Zustand müssen zum aktuellen, für Besucher erreichbaren Angebot passen.
• Publikations-, Änderungs-, Event-, Upload- und Stellendaten dürfen nicht aus dem heutigen Datum oder einem Crawl-Zeitpunkt geraten werden.
• Adressen, Koordinaten, Öffnungszeiten und Telefonnummern müssen die Entität der Seite beschreiben und nicht eine vermutete Zentrale.
• Stellengehälter und Ablaufdaten müssen echt und aktuell sein.

Ein KI-Vorschlag kann diese Angaben nicht für Sie bestätigen. Ein Modell kann einen sichtbaren Preis finden und den Ausschnitt zitieren; nur der Herausgeber weiß aber, ob der Preis aktuell ist, ob Steuern enthalten sind und ob das Angebot zum kanonischen Produkt gehört. Die Checkbox ist absichtliche Reibung: Sie schafft den Moment, in dem Feld und realer Geschäftsfakt verglichen werden.

Unbekannt ist ein gültiger Zustand. Der Compiler lässt leere optionale Eigenschaften weg, statt null, einen leeren String, das heutige Datum oder Platzhalter wie IHRE_LOGO_URL zu schreiben. So bleibt der Entwurf kleiner und fehlende redaktionelle Arbeit sichtbar.

Viele Seiten enthalten bereits Markup aus Theme, SEO-Plugin, Shop-Plattform, Tag Manager oder einer früheren Implementierung. Ein neuer Generator darf nicht so tun, als sei die Seite leer.

Der URL-Modus erfasst JSON-LD, Microdata und RDFa, bevor er ein Hauptprofil vorschlägt. Er fasst vorhandene Typen und Kennungen zusammen, damit erkennbar wird, ob Product, Organization, BreadcrumbList oder ein anderer Knoten bereits besteht. Der manuelle Validator nimmt einen vorhandenen JSON-LD-Block an und prüft Parsing, fehlenden Kontext oder Typ, doppelte Kennungen, Review- und Rating-Risiken sowie veraltete Annahmen zu FAQPage und HowTo.

Die richtige Lösung ist oft, die bereits verantwortliche Quelle zu ändern. Rendert eine Shop-Plattform Product und Offer, kann ein zweiter handgeschriebener Product-Block beim nächsten Release widersprüchliche Preise oder Kennungen erzeugen. Verwaltet ein globales Plugin Organization, verlinken Sie dessen stabile @id, statt die Entität zu wiederholen.

Prüfen Sie das gerenderte HTML, nicht nur die bearbeitete Quelldatei. Clientseitige Plugins können JSON-LD nach dem Laden hinzufügen oder ersetzen; Tag Manager können Duplikate erzeugen, die in keinem Template-Repository stehen. Googles Test und die DOM-Ansicht eines Browsers zeigen, was die Seite tatsächlich ausliefert.

Das Kopieren des Snippets ist der Beginn der Einbindung, nicht ihre Abschlussprüfung.

Platzieren Sie das JSON-LD-Script im Head oder Body, wo Framework oder CMS es zuverlässig rendert. Entschärfen Sie schließende Script-Zeichenfolgen, wenn nutzergeschriebener Text in das JSON gelangt. Halten Sie den Output auf der kanonischen Seite, die ihn sichtbar stützt. Öffnen Sie danach die bereitgestellte URL im Schema.org Validator und im Google Rich Results Test.

Validieren Sie erneut, wenn sich die Seite ändert. Commerce-Markup driftet mit Preis- und Bestandssystemen. Artikeldaten driften, wenn ein Template einen Build-Zeitpunkt als dateModified setzt. JobPosting wird irreführend, wenn eine abgelaufene Stelle live bleibt. Event-Status und Teilnahmemodus ändern sich mit Ort und Termin. Organisationsdaten driften bei Rebranding und Migration.

Legen Sie Verantwortung im Release-Prozess fest: Entscheiden Sie, ob CMS-Plugin, Framework-Komponente, Produktfeed oder Server-Template für jede Entität maßgeblich ist. Ein Besitzer pro Knoten verhindert, dass zwei Systeme unterschiedliche Fakten veröffentlichen.

Messen Sie den Erfolg schließlich nicht nur daran, ob ein ausgeschmücktes Suchergebnis erscheint. Das erste Erfolgskriterium sind korrekte maschinenlesbare Inhalte, die dauerhaft zur Seite passen. Berechtigung ist ein nützliches Ergebnis. Ein sichtbares Rich Result bleibt die Entscheidung der Suchmaschine — kein Versprechen, das ein Generator geben kann.