JSON-LD-Erklärung für persönliche Websites

 (hawksley.dev)
2 Punkte von GN⁺ 8 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Auch persönliche Websites können von strukturierten Daten profitieren: Crawler verstehen dann die Beziehungen zwischen Seiten, Personen und Beiträgen besser und können Link-Vorschauen sowie die Qualität der Suchdarstellung verbessern
  • Die Umsetzung erfolgt über <head> mit <script type="application/ld+json">, wobei @context auf Schema.org gesetzt und in @graph Knoten wie WebSite, Person und BlogPosting platziert werden
  • Wenn dieselbe @id verwendet wird, können Webcrawler Knoteneigenschaften über mehrere Seiten hinweg zusammenführen; Scraper oder LLMs, die nur eine einzelne Seite lesen, tun das jedoch nicht
  • Auf der Startseite sollten standardmäßig WebSite, ProfilePage und Person stehen; auf Blog-, Projekt- und Übersichtsseiten werden je nach Charakter der Seite Blog, BlogPosting, SoftwareApplication, CollectionPage und BreadcrumbList ergänzt
  • Die Felder sameAs bei Person, breadcrumb bei Seiten sowie image, license und Datumsfelder bei Beiträgen werden direkt für Personenidentifikation, Pfadangaben in Suchergebnissen, Beitragsvorschauen, Nutzungsbedingungen und die Einschätzung der Aktualität verwendet

Rolle und Grundstruktur von JSON-LD

  • JSON-LD steht für JSON Linked Data und ist ein Format zum Hinzufügen strukturierter Daten zu Webseiten
  • Es hilft Crawlern, die semantische Struktur einer Website zu verstehen, und kann zu reichhaltigeren Link-Vorschauen sowie potenziell besseren Suchrankings beitragen
  • Beim Einfügen in eine Seite wird im <head>-Abschnitt ein Skript in folgender Form ergänzt
    • <script type="application/ld+json"> deklariert den MIME-Typ als application/ld+json
    • Wenn dieser Typ gesetzt ist, führt die JavaScript-Engine des Browsers den Inhalt nicht aus
    • Spezielle Crawler wie Googlebot finden dieses Element und parsen seinen Inhalt

@context, @graph und Knoten-IDs

  • @context legt den Kontext fest, dem die JSON-LD-Daten folgen; Webcrawler verwenden Schema.org als Standard
  • Schema.org definiert die gültigen Schlüssel-Wert-Paare, die in JSON verwendet werden können
  • Ein JSON-LD-Dokument lässt sich als beschrifteter gerichteter Graph verstehen, wobei die Daten unter @graph gespeichert werden
  • Ein Graph kann mehrere Knoten enthalten, die durch gerichtete Verbindungen miteinander verknüpft sind
  • Jeder Knoten besteht aus den folgenden Elementen
    • @type: Gibt an, was der Knoten ist, z. B. WebSite oder SoftwareApplication
    • @id: In der Regel ein Bezeichner für den Knoten, bei dem an das Ende der URL ein eindeutiger Hash angehängt wird
    • Eigenschaften: Schlüssel-Wert-Paare, die die Merkmale des Knotens beschreiben
  • Webcrawler können Eigenschaften von Knoten mit derselben @id über mehrere Seiten hinweg zusammenführen
  • Scraper oder LLMs, die nur eine einzelne Seite lesen, führen Eigenschaften jedoch nicht zusammen; dieser Unterschied sollte berücksichtigt werden, wenn JSON-LD über mehrere Seiten hinweg wiederverwendet wird
  • Für @id wird empfohlen, einen Hash wie #website an die URL anzuhängen, um den Knoten eindeutig zu identifizieren

Knoten zur Beschreibung von Website und Seiten

  • WebSite

    • WebSite enthält die Metadaten der Website und gibt Crawlern Hinweise darauf, wie die Website dargestellt werden soll
    • Auf der Startseite kann eine ausführliche Version mit Eigenschaften wie url, name, alternateName, description, inLanguage, publisher und image verwendet werden
    • Es ist nicht nötig, auf jeder Seite den vollständigen WebSite-Knoten einzufügen
    • Für die Root-Seite lohnt sich eine ausführliche Beschreibung, während auf anderen Seiten auch eine verkürzte Version mit nur @type, @id, url und name ausreicht
    • Die verkürzte Version liefert Crawlern, die nur eine einzelne Seite lesen, den nötigen Kontext, um den Namen der Website korrekt zu erfassen

  • WebPage

    • WebPage beschreibt die aktuelle Seite selbst, also die physische HTML-Seite
    • Sie sollte von Inhaltstypen wie BlogPosting unterschieden werden; WebPage bezeichnet die Seite, die diesen Inhalt enthält
    • Beispielhafte Eigenschaften sind url, isPartOf, name, inLanguage und breadcrumb
    • ProfilePage und CollectionPage sind spezifischere Untertypen von WebPage
    • Weniger verbreitete Untertypen finden sich in der Schema.org-Definition von WebPage

Personenidentifikation und Profilseiten

  • Person

    • Es wird empfohlen, auf allen Seiten einer persönlichen Website einen Person-Knoten einzufügen
    • Person zeigt an, wem die Website gehört, und wird von Google unter anderem als Teil von Inhaltsqualitätsmerkmalen verwendet
    • Auch LLM-Crawler nutzen Person-Informationen zunehmend, um zu bestimmen, wen sie in Antworten zitieren sollen
    • Anders als WebSite ist Person ein so wichtiger Kontext, dass es auf jeder Seite enthalten sein sollte
    • Wichtige Eigenschaften sind
      • url: Verankert den Knoten, indem auf die Root-Seite verwiesen wird
      • name, givenName, familyName: Stellen den Namen eindeutig dar
      • image: Wenn möglich ein Foto der Person oder ein passendes Logo verwenden, um ein offizielles Bild zu verknüpfen
      • sameAs: Informiert Crawler über andere Profile und hilft bei der Personenidentifikation
    • sameAs ist besonders nützlich zur Unterscheidung gleichnamiger Personen und wird verwendet, um Darstellungen im Knowledge Graph über mehrere Seiten hinweg aufzubauen
    • Andere Person-Eigenschaften können zusätzliche Details liefern, sind aber nicht zwingend erforderlich; ihr Weglassen hat meist nur geringe Auswirkungen

  • ProfilePage

    • ProfilePage steht für eine Seite innerhalb der Website, die sich auf eine bestimmte Person bezieht
    • Wenn man sich auf der Startseite selbst vorstellt, kann sie dort verwendet werden; gibt es eine separate About-Seite, ist sie dort oft passender
    • Wichtig ist die Verknüpfung mit dem übergeordneten WebSite-Knoten über isPartOf
    • mainEntity teilt Crawlern mit, um wen es auf dieser Seite geht
    • dateCreated und dateModified sind als Aktualitätssignale für Crawler nützlich, aber kein großes Problem, wenn die Website sie nicht leicht bereitstellen kann

Projekte und Pfadangaben

  • SoftwareApplication

    • Wenn eine Seite Software vorstellt, ist es sinnvoll, die Metadaten dieser Software in einem SoftwareApplication-Knoten zu hinterlegen
    • Als spezifischere Typen können MobileApplication, WebApplication oder VideoGame verwendet werden
    • Die Eigenschaft url sollte auf den Ort verweisen, an dem das Projekt veröffentlicht ist
    • Ein Beispiel dafür wäre eine Distributionsseite wie crates.io
    • sameAs wird für andere mit dem Projekt verknüpfte Seiten verwendet, etwa ein Quellcode-Repository
    • Gültige Werte für applicationCategory finden sich in Googles Definition von SoftwareApplication
    • Auch bei FOSS-Projekten sollte offers enthalten sein und der Preis auf 0 gesetzt werden

  • BreadcrumbList

    • BreadcrumbList ist für fast alle Seiten außer der Startseite breit nützlich
    • Sie zeigt den Klassifizierungspfad einer Seite und muss nicht zwingend mit dem tatsächlichen URL-Pfad übereinstimmen
    • Suchmaschinen können sie verwenden, um zu steuern, wie der Pfad einer bestimmten Seite dargestellt wird
    • Wenn der Pfad der Website ohnehin schon kurz ist, ist der Nutzen dieses Knotens gering und er kann weggelassen werden
    • Bei Websites mit langen Pfaden hilft BreadcrumbList, die Pfadangabe in Suchergebnissen zu verkürzen

Übersichts-, Blog- und Artikelseiten

  • CollectionPage

    • CollectionPage ist ein Untertyp von WebPage, der vor allem für Seiten mit Listen oder Sammlungen verwendet wird
    • Beispiele sind eine /elsewhere/-Seite mit anderen Profilen oder eine /blog/-Seite mit einer Liste von Blogbeiträgen
    • Über about kann ein zugehöriger Person-Knoten verknüpft werden
    • breadcrumb sollte unbedingt mit der korrekten BreadcrumbList der aktuellen Seite verbunden sein

  • Blog

    • Ein Blog-Knoten wird auf der Index- oder Startseite eines Blogs hinzugefügt
    • Er fungiert als Zwischenknoten zwischen WebSite und einzelnen BlogPosting-Einträgen
    • dateModified ist als Aktualitätssignal nützlich, kann aber weggelassen werden, wenn es nicht leicht bereitgestellt werden kann
    • license informiert Crawler darüber, unter welchen Bedingungen Beiträge verwendet werden dürfen
    • Auf persönlichen Websites kann publisher statt auf Organization auch auf Person gesetzt werden
    • Google-Dokumentation erlaubt inzwischen auch Person ausdrücklich, was für persönliche Websites passender sein kann

  • BlogPosting

    • BlogPosting sollte in allen veröffentlichten Blogartikeln enthalten sein
    • Es liefert zusätzliche Informationen, damit Crawler den Beitrag präziser darstellen können
    • Es kann für eine genauere Platzierung in Suchergebnissen und reichhaltigere Detaildarstellungen verwendet werden
    • Auf persönlichen Websites ist es in Ordnung, wenn author und publisher auf denselben Person-Knoten verweisen
    • Die Eigenschaft image sollte idealerweise mit dem OG-Bild übereinstimmen, das bereits für Link-Vorschauen des Beitrags verwendet wird
    • license kann genutzt werden, um die Nutzungsbedingungen des Beitrags anzugeben

Minimale Umsetzung und Auswahlkriterien

  • Das für eine persönliche Website benötigte JSON-LD kann je nach Seitentyp gezielt zusammengestellt werden
  • Auch bei einer statischen Website ohne Build-Schritt lassen sich Vorteile erzielen, wenn auf der Root-Seite mindestens die folgenden Knoten ergänzt werden
    • WebSite
    • ProfilePage
    • Person
  • Wenn ein Blog vorhanden ist, können Blog und BlogPosting ergänzt werden; für Übersichtsseiten mit Beiträgen oder externen Profilen kann CollectionPage verwendet werden
  • Für Projektvorstellungsseiten kommt SoftwareApplication infrage, und für Seiten außerhalb der Startseite sollte BreadcrumbList geprüft werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 8 시간 전
Hacker-News-Kommentare

  • Um eine Analogie zu bemühen: Es fühlt sich an, als würde man den letzten Krieg noch einmal führen
    Aus Sicht meiner WWW-Seite zeigt Google inzwischen oben lieber eine lange, fehlerdurchsetzte LLM-generierte Zusammenfassung, statt Menschen zu meinen eigentlichen Texten zu schicken
    Einen hübschen Anzeigenamen statt „Breadcrumbs“ oder einer Domain zu bekommen, löst nicht die Realität, dass Google priorisiert, solche Elemente nachrangig zu behandeln, egal wie hübsch es sie aufbereitet
    Man steckt also zu viel Mühe in etwas, das Leute, die direkt auf die eigentliche Seite kommen, nie sehen, und das für Google-Nutzer schwer zu finden ist, weil es unter Googles eigener LLM-isierter Version nach unten gedrückt wird

    • Wenn wir eine Welt wollen, in der solche Daten sinnvoll sind, müssen wir zuerst den Samen säen
      Selbst wenn Google sie nicht nutzt: Wenn das gesamte Internet solche Metadaten einsetzt, entsteht ein fruchtbarer Boden dafür, dass Konkurrenten Alternativen anbieten können, ohne auf LLM-Scraping angewiesen zu sein
      Sich Google zu beugen, stärkt nur dessen Dominanz, erhöht die Markteintrittsbarrieren für Wettbewerber und drängt auch sie dazu, dieselbe Technik einzusetzen
    • Genau so ist es. Unsere Firma wird in der Google-Suche inzwischen so dargestellt:
      $STATE-basiertes IT-Unternehmen, das sich auf praktische AI-Workflows und Informationsmanagement-Lösungen für Unternehmen im Mittleren Westen spezialisiert hat. Es arbeitet mit einem agilen Festpreismodell und konzentriert sich darauf, konkrete Ergebnisse zu liefern, ohne die aufgeblähte Struktur klassischer Enterprise-Anbieter.
      Ich wusste gar nicht, dass wir jetzt praktische AI-Workflows anbieten
      Dann wirft es noch den Namen eines ähnlichen, aber eindeutig anderen Konkurrenten hinein und listet mich als Führungskraft auf. Wenigstens versteckt der Konkurrent seine Kontaktdaten hinter einem Formular zum „Beratungsgespräch buchen“, sodass nur unsere Kontaktdaten angezeigt werden
    • Inzwischen erlaube ich Google nicht einmal mehr, meine Seite zu crawlen und zu indexieren
    • Google gehört jetzt ebenfalls zu den Zielen, bei denen „ein Bot, der die Seite betritt, eine 10GB zipbomb bekommt“
      Im Moment stiftet es keinerlei Mehrwert und verursacht nur zusätzliche Probleme
    • Ja. Ich habe jahrelang massenhaft Microdata-Tags und -Attribute in Websites eingebaut, in der Hoffnung, dass sie Traffic bringen
      Am Ende habe ich damit nur Googles AI trainiert, damit die Leute Google nicht verlassen

  • Wenn man praktisch veranlagt ist, würde ich empfehlen, die Google-Dokumentation zu JSON-LD für Websites zu lesen
    https://developers.google.com/search/docs/appearance/structu...
    Dabei wird man auch sehen, dass viele Informationen nur für bestimmte Seiten relevant sind. Rotten Tomatoes kann per JSON-LD Bewertungen von Filmkritikern veröffentlichen, aber wenn ich selbst Filmkritiken schreibe, ist das für mich kaum relevant
    JSON-LD ist einfach und in Ordnung, weil Suchmaschinen es tatsächlich verwenden. Man kann damit Informationen innerhalb einer Webseite duplizieren, aber der Traum, alles perfekt so zu annotieren, dass jede Information im Dokument exakt einmal vorkommt, wirkt auf mich eher wie eine Idealisierung à la kugelförmige Kuh und masseloses Seil
    Eine Webseite zu bauen erfordert menschliche Arbeit, und ein wenig Duplizierung im Endergebnis ist in Ordnung

    • Man kann JSON-LD auch für Filmkritiken nutzen, ohne eine große Seite zu sein
      Ich verwende es auf meiner Seite für Rezensionen zu Büchern, Spielen und Filmen, und es scheint so, als würden die meisten Suchmaschinen Dinge wie Sternebewertungen anzeigen
    • 403. That’s an error.
      Es heißt, der Client habe keine Berechtigung, die URL /search/docs/appearance/structured-data/intro-structured-data auf diesem Server abzurufen
    • Aber wenn man Daten dupliziert, steigt doch der Wasserverbrauch. /s

  • Für umfangreiche Link-Vorschauen wird OpenGraph deutlich häufiger unterstützt als JSON-LD
    Wenn es um Suchmaschinenoptimierung geht, sind die von Suchmaschinen unterstützten JSON-LD-Arten sehr spezifisch und begrenzt. Es ist viel besser, die Dokumentation der jeweiligen Suchmaschine zu lesen, also Google[1] oder Bing[2], und sie genau zu befolgen; alles andere ist fast Zeitverschwendung
    Auch außerhalb von Suchmaschinen ist JSON-LD meistens nutzlos, wenn es keinen konkreten Zweck gibt. Wenn es eine spezifische Anforderung gibt, für die JSON-LD gebraucht wird, kann man die dafür nützlichen Daten einfügen; andere Daten einzufügen ist dagegen ungefähr so, als würde man ins Leere rufen
    IndieWeb[3] verwendet strukturierte Daten, betrachtet JSON-LD aber als Verstoß gegen DRY und nutzt stattdessen Microformats[4]
    0: https://ogp.me
    1: https://developers.google.com/search/docs/appearance/structu...
    2: https://www.bing.com/webmasters/help/marking-up-your-site-wi...
    3: https://indieweb.org/
    4: https://microformats.org/

  • Was man auf jeder Website eigentlich implementieren möchte, sind strukturierte Daten mit dem Schema.org-Vokabular
    JSON-LD ist nur eine Möglichkeit dafür, außerdem gibt es RDFa und Microdata
    Als ich das gelernt habe, habe ich mich an diesem Artikel orientiert, und er ist empfehlenswert: https://neilpatel.com/blog/get-started-using-schema/
    Mit diesem Tool kann man sich ansehen, welche Daten man hinzufügen kann: https://technicalseo.com/tools/schema-markup-generator/
    Die vollständige Liste gibt es auf schema.org: https://schema.org/docs/schemas.html

  • Vor ein paar Jahren habe ich erfahren, dass all die auffälligen E-Mail-Funktionen wie eingebettete Flugtickets oder sichtbare Sendungsverfolgung komplett über JSON-LD in E-Mails umgesetzt werden
    Soweit ich weiß, unterstützt das allerdings nur Gmail
    Mehr dazu: https://www.emailonacid.com/blog/article/email-development/s...

    • Outlook und iCloud unterstützen bei Tickets oder Reservierungen ebenfalls einige Funktionen

  • Ich frage mich, ob solche Eigenschaften tatsächlich bei der Sichtbarkeit in der Suche helfen oder ob sie es Suchmaschinen nur leichter machen, Nutzer auf der Suchergebnisseite zu halten

    • Nachdem ich JSON-LD hinzugefügt hatte, begann Google Unterlinks zu meiner Website anzuzeigen. Das war in Ordnung
    • Bei einer Business-Website kann JSON-LD dazu dienen, Daten an Kartenplattformen zu liefern
      Also Dinge wie Adresse, Öffnungszeiten, Telefonnummer und Speisekarte

  • Es gibt bereits semantisches HTML, und trotzdem muss man die Bedeutung einer Website noch einmal in benutzerdefiniertem, seltsamem JSON innerhalb eines script-Tags ausdrücken, das der Browser gar nicht verarbeitet

    • Ich habe JSON-LD auf meiner Website verwendet und sehe darin einen anderen Zweck als bei semantischem HTML
      Semantisches HTML legt fest, was der Browser verarbeitet, etwa Titel und Überschriften. JSON-LD-Daten sind Metadaten wie Erstellungsdatum, Änderungsdatum, Tags und Autor
      Das lässt sich innerhalb von HTML auch mit Microdata ausdrücken, aber JSON-LD ist einfacher, deshalb habe ich aufgehört, Microdata zu verwenden
      JSON-LD befülle ich aus denselben Daten, mit denen die Website erzeugt wird, und aus diesen Metadaten erstelle ich auch Indexseiten wie eine Liste der Blogbeiträge von 2024 oder alle Beiträge zu Thema X. Der Hauptabnehmer von JSON-LD sind Suchmaschinen
      Wenn man sich noch mehr darüber ärgern will, kann man daran denken, dass man auf derselben Seite zusätzlich OpenGraph-Metadaten unterbringt. Damit gibt es auf derselben Seite zwei verschiedene Metadatenformate
    • Es gibt auch Microdata, und wenn ich mich nicht irre, unterstützt es dasselbe Vokabular wie JSON-LD. schema.org ist dafür eine gute Ressource
      JSON-LD ist aber seit einiger Zeit der Standard, ähnlich wie wir REST weitgehend aufgegeben und uns RPC zugewandt haben. Ich weiß auch nicht, ob die wichtigen Parser heute alle noch Microdata unterstützen, und gerade bei Kundenprojekten wie E-Commerce-Websites, die Google-Sichtbarkeit wollen, habe ich standardmäßig LD verwendet
      Im Vergleich zu semantischem HTML gibt es noch etwas zu beachten. Semantisches HTML hilft bei der Definition der Markup-Struktur, kann aber keinen Kontext aus der realen Welt ausdrücken wie „Das ist ein Produkt zum Verkauf“ oder „Das ist ein Zugfahrplan“
    • Ich glaube, du hast den Artikel nicht ganz verstanden
      Man kann Ontologien wie Schema.org/FOAF/WikiData auch direkt in HTML verwenden, ganz ohne JSON-LD und script-Tags
    • In einer idealen Welt könnten Server und Browser Content Negotiation betreiben, und der Browser würde zuerst nur JSON-LD von einer Website anfordern und dann ein eigenes internes Renderer-Format verwenden
    • Semantisches HTML deckt nicht den Bereich ab, den JSON-LD und andere Mikroformate abdecken
      Schon anhand der Beispiele im Artikel stellt sich die Frage, welche semantischen Elemente es für Personen, Breadcrumb-Listen, Softwareanwendungen, Blogs und Blogbeiträge gibt
      Semantisches HTML soll Menschen mit Screenreadern dabei helfen, allgemeine Elemente wie „Navigation“ oder „Artikel“ zu durchlaufen

  • Ist das nicht einfach OpenGraph in JSON? Was ist der Vorteil?

  • Seit 2024 ist der Traffic auf unseren contentgetriebenen Marketingseiten um etwa 85 % eingebrochen
    Was ich nicht verstehe: Wenn es immer mehr Zero-Click-Suchergebnisseiten gibt, hätte Google dann nicht ebenfalls stark getroffen werden müssen?
    Auch die Werbeumsätze aus Suchergebnisseiten-Anzeigen, die auf Klicks basieren, hätten ähnlich drastisch sinken müssen, aber ich konnte keine öffentlichen Zahlen finden, die diese Hypothese widerlegen oder bestätigen

  • Ab einem gewissen Punkt gibt es ein feines Gleichgewicht, bei dem Symbiose in Ausbeutung umschlägt
    Die Beziehung, in der Websites mithilfe von Suchmaschinen Sichtbarkeit erhalten wollten, war lange zu einem guten Teil gegenseitig vorteilhaft
    Inzwischen entwickelt sich das aber vollständig in eine Richtung, in der Website-Betreiber nichts mehr von der Arbeit haben, in die sie Schweiß gesteckt haben