Person-Schema

TL;DR — Das Person-Schema ist ein kleiner Codeblock, der Suchmaschinen mitteilt, über wen eine Seite handelt – normalerweise über den Autor eines Artikels. Es verwendet den schema.org Person-Typ, um einen Namen, einen Link zu einer Biografie, eine Berufsbezeichnung und Links zu weiteren Profilen dieser Person anzugeben. Seine Hauptaufgabe besteht darin, Suchmaschinen dabei zu helfen, zu erkennen, dass die „Jane Smith“ hier dieselbe Jane Smith ist wie anderswo im Web. Es führt nicht zu einem besseren Ranking und es verschafft Ihnen keine „Expertise-Punkte“.

Was das Person-Schema ist

Wenn der Name einer Person in einer Autorenzeile erscheint, wissen Sie aus dem Kontext, wer sie ist. Eine Suchmaschine sieht nur Text. Person-Schema kennzeichnet ihn im Code: Es markiert einen Namen als Person und fügt maschinenlesbare Details hinzu, wie die URL zur Biografie, die Berufsbezeichnung, den Arbeitgeber und Links zu den Social-Media-Profilen.

Es verwendet das gemeinsame schema.org-Vokabular – dasselbe, das hinter Produktpreisen, Bewertungssternen und Breadcrumbs steckt. Der spezifische Typ ist Person, und Sie fügen ihn am häufigsten als author eines Artikels hinzu. Sie können ihn auch auf einer „Über mich“- oder Biografie-Seite verwenden, um zu sagen: „Diese gesamte Seite handelt von dieser Person.“

Warum es existiert: Personen unterscheiden

Der eigentliche Grund, es hinzuzufügen, ist die Disambiguierung. Es gibt viele Menschen, die sich einen Namen teilen. Person-Schema – insbesondere die sameAs-Eigenschaft, die Ihre weiteren Profile auflistet (LinkedIn, eine persönliche Website, X) – hilft einer Suchmaschine, die Punkte zu verbinden: Der Autor hier ist dieselbe Person wie diejenige hinter diesen anderen Profilen. Diese konsistente Identität ist das, was Suchmaschinen und zunehmend auch KI-Systeme aufzubauen versuchen.

Das, was die meisten falsch verstehen

Person-Schema verbessert Ihr Ranking nicht und es erzeugt kein „E-E-A-T“. Das ist der große Mythos. Sie werden Ratgeber finden, die behaupten, dass das Hinzufügen einer jobTitle- oder einer Reihe von sameAs-Links Google dazu bringt, Ihnen mehr zu vertrauen. So funktioniert das nicht. Googles eigene Leute haben klar gesagt, dass E-E-A-T kein direkter Ranking-Faktor ist und dass jeder sich im Markup als Experte bezeichnen kann – was für sich genommen nichts bedeutet.

Worauf es Google wirklich ankommt, ist sichtbare Autorenschaft: echte Autorenzeilen und Bio- Informationen, die ein Leser tatsächlich auf der Seite sehen kann. Das Schema ist ein maschinenlesbares Spiegelbild dieser sichtbaren Autorenzeile – kein Ersatz dafür und kein magischer Vertrauens- schalter.

Zwei Anfängerregeln:

• Geben Sie nur den Namen in das Namensfeld ein. Schreiben Sie nicht „Jane Smith, Senior Editor“ – Google empfiehlt, die separate jobTitle-Eigenschaft für die Bezeichnung zu verwenden.
• Stimmen Sie das Markup mit dem Sichtbaren ab. Wenn Ihr Code eine Berufsbezeichnung oder einen Arbeitgeber angibt, der nirgendwo auf der Seite steht, ist das ein Problem, kein Bonus.

Möchten Sie die eigenschaftsgenaue Version, die Unterscheidung zwischen Article und ProfilePage und die exakten Zitate der Google-Vertreter? Wechseln Sie zum Erweitert-Tab.

TL;DR — Person-Schema (schema.org/Person) markiert eine Einzelperson – am häufigsten als author eines Artikels, manchmal als mainEntity einer ProfilePage. Seine Aufgabe ist die Entitäts-Disambiguierung, in erster Linie über sameAs: die Angleichung einer Identität über Autorenzeilen, Biografien und Profile hinweg. Es ist kein Ranking-Faktor und verleiht kein E-E-A-T – Sullivan hat gesagt, dass E-E-A-T kein direkter Ranking-Faktor ist und dass die Selbsterklärung zum Experten „nichts bedeutet“, und Mueller hat gesagt, dass strukturierte Daten eine Seite nicht besser ranken lassen. Article-Author-Person- Markup und ProfilePage-Person-Markup empfehlen unterschiedliche Eigenschaftssätze. Und das Markup muss die sichtbare Autorenzeile widerspiegeln – versteckte Angaben in JSON-LD sind das Gegenteil dessen, was Google tatsächlich fördert.

Wo das Person-Schema verwendet wird

Drei häufige Einsatzorte, die nicht austauschbar sind:

1. Artikelautor. Die author-Eigenschaft eines Article/BlogPosting, typisiert als Person. Googles eigenes Beispiel enthält name, jobTitle und url.
2. ProfilePage mainEntity. Eine dedizierte Bio-/Über-Seite, auf der die Person das primäre Subjekt ist. Googles ProfilePage-Dokumentation beschreibt sie für Websites, “where creators (either people or organizations) share first-hand perspectives.”
3. Innerhalb der Organization-Markierung – ein Gründer oder Mitarbeiter, der auf einer Unternehmensseite erwähnt wird.

Dies ist ein verwandtes Thema zur Organization-Schema (das Unternehmen selbst) und LocalBusiness-Schema (ein Unternehmen mit physischem Standort), und alle drei gehören zum breiteren Hub für Entitäten und Identität. Person ist das individuelle Puzzleteil desselben Entitätsgraphen.

Warum es existiert: Disambiguierung, nicht Ranking

Die eigentliche Funktion des Person-Schemas besteht darin, Suchmaschinen zu ermöglichen, eine Person konsistent zu identifizieren und ihre Inhalte über eine Website und das Web hinweg zu verbinden. Die verbindende Eigenschaft ist sameAs – Sie verweisen auf andere URLs, die dieselbe Person repräsentieren, und sagen damit effektiv: “das bin alles ich.”

Googles Dokumentation rahmt die Autor-URL auf dieselbe Weise. Es hat eine empfohlene author.url-Eigenschaft speziell hinzugefügt und beschreibt sie als einen Link, “that uniquely identifies the author” – eine Über-Seite, eine Bio-Seite oder ein soziales Profil. Der Punkt ist Abgleich: Wählen Sie eine kanonische Bio-Seite und verweisen Sie die author.url jedes Artikels darauf, anstatt verschiedene URLs pro Beitrag zu verstreuen. (John Mueller hat die Autorenidentifikation als eine solche Abgleichsprozess beschrieben und eine zentrale Profilseite empfohlen, obwohl ich die genaue Formulierung eher als Paraphrase aus sekundärer Berichterstattung denn als wörtliches Zitat behandeln würde.)

Der Stand: Es ist kein Ranking-Faktor und kein E-E-A-T

Das ist der Kernpunkt, denn fast jeder konkurrierende Leitfaden liegt hier falsch. Zwei getrennte, gut dokumentierte Positionen von Google:

Strukturierte Daten sind kein Ranking-Boost. John Mueller hat gesagt, dass strukturierte Daten eine Website nicht besser ranken lassen – sie dienen den in der Galerie dokumentierten Suchfunktionen, und die Verwendung für andere schema.org-Typen ist in Ordnung, führt aber wahrscheinlich zu keiner sichtbaren Änderung in der Suche. Das Hinzufügen eines Person-Blocks ist also kein Ranking-Hebel.

E-E-A-T ist kein direkter Ranking-Faktor – und selbst erklärte Expertise bedeutet nichts. Danny Sullivan, Googles Search Liaison, sagte es direkt:

“having an expert write things doesn’t magically make you rank better, because

1. anyone could self declare someone to be an expert, and that means nothing and
2. we don’t somehow try to check and say ‘Yes, that’s an expert.’” (Übersetzung) „Wenn ein Experte Dinge schreibt, führt das nicht automatisch zu besseren Rankings, denn

1. jeder könnte jemanden zum Experten erklären, und das bedeutet nichts, und
2. wir versuchen nicht irgendwie zu prüfen und zu sagen: ‚Ja, das ist ein Experte.‘“

Genau das ist das Person-Schema: eine Selbsterklärung. Das Schreiben von jobTitle: "Senior SEO Expert" und einem Stapel von sameAs-Links führt nicht dazu, dass Google “E-E-A-T-Punkte” vergibt. E-E-A-T ist ein Qualitätsbewerter-Framework, keine Markup-Checkliste.

Was Google tatsächlich fördert, ist die sichtbare Version. Seine Anleitung empfiehlt nachdrücklich, genaue Autoreninformationen wie Bylines dort hinzuzufügen, wo Leser sie erwarten würden – als Hilfe für Leser, zu verstehen, wie Inhalte erstellt wurden. Die Kernaussage: Platzieren Sie die Qualifikationen auf der Seite, wo Menschen sie sehen können; das Schema spiegelt das wider, es ersetzt es nicht.

Kerneigenschaften

Googles Leitfaden für strukturierte Daten zu Artikeln veröffentlicht überhaupt keine Tabelle mit “erforderlichen Eigenschaften” – es heißt, fügen Sie die Eigenschaften hinzu, die auf Ihre Inhalte zutreffen. Seine Tabelle mit empfohlenen Eigenschaften für author listet genau zwei auf:

• name — der Name und nur der Name. Google ist eindeutig: “In the author.name property, only specify the name of the author. Don’t add any other piece of information.” Kein “Jane Smith, Editor.”
• url — eine einzelne kanonische Seite, die den Autor eindeutig identifiziert (eine Bio- oder Über-Seite, idealerweise auf derselben Domain). Googles Best-Practices-Anleitung behandelt sameAs als akzeptierte Alternative zu url für dieselbe Disambiguierungsaufgabe.

Über diese beiden hinaus enthält Googles ausgearbeitetes Beispiel für Article-Autor auch jobTitle — aber das ist Beispielinhalt, keine separate Zeile in der Tabelle der empfohlenen Eigenschaften. Behandeln Sie diese als legitime schema.org-Eigenschaften, die es wert sind, hinzugefügt zu werden, wenn sie zutreffend und bereits auf der Seite sichtbar sind, nicht als von Google vorgeschriebene Checkliste:

• jobTitle — die Rolle, getrennt von name. Erscheint nur in Googles Beispiel.
• worksFor — ein Organization-Objekt für den Arbeitgeber. Wird in Googles Article-Dokumentation überhaupt nicht erwähnt (weder in der empfohlenen Tabelle noch im Beispiel) — dies ist schema.org-Vokabular, nützlich für den beruflichen Kontext, aber präsentieren Sie es nicht als etwas, das Google empfiehlt.
• image — ein Porträtfoto. Gleicher Status wie worksFor: schema.org-Vokabular, nicht in Googles empfohlener Tabelle für Article.
• sameAs — der Disambiguierungshebel und die eine Alternative, die Googles eigene Dokumentation neben url nennt. Prioritätskandidaten: LinkedIn, die persönliche Website, Wikipedia/Wikidata, falls vorhanden, X, GitHub für technische Autoren, ORCID für Forscher. Jeder Link muss wirklich dieselbe Person sein — ein falsches sameAs bricht die Disambiguierung, anstatt sie zu stärken.
• Optional: description, alumniOf, knowsAbout.

Article-Autor-Person vs. ProfilePage-Person

Die meisten Anleitungen vermischen diese, und das führt zu Über- oder Untermarkierung. Google dokumentiert unterschiedliche Status für die beiden Seitentypen — und kennzeichnet sogar Eigenschaften innerhalb jedes Typs unterschiedlich (erforderlich vs. empfohlen vs. nur im Beispiel):

Der Fehler ist anzunehmen, dass jede Person-Eigenschaft auf beide gehört, oder dass das Erscheinen in einem Beispiel bedeutet, dass Google es “empfiehlt”. Auf einer ProfilePage sind Googles tatsächliche erforderliche/empfohlene Eigenschaften mainEntity, name, alternateName, sameAs, description, image und die Datumsfelder — es listet nicht jobTitle/worksFor dort auf, und es listet sie auch nicht als formale Empfehlung für Article-Autoren, obwohl sie in Googles Beispiel auftauchen.

Ein minimales Beispiel für Article-Autor

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How search engines crawl the web",
  "author": {
    "@type": "Person",
    "name": "Willow Lane",
    "jobTitle": "Journalist",
    "url": "https://www.example.com/staff/willow-lane"
  }
}

Beachten Sie, dass name nur den Namen trägt und jobTitle die Rolle — das ist die Unterscheidung, auf der Googles Dokumentation besteht.

Ein vollständigeres Beispiel mit Zugehörigkeit und sameAs

{
  "@type": "Person",
  "name": "Willow Lane",
  "jobTitle": "Senior Journalist",
  "url": "https://www.example.com/staff/willow-lane",
  "image": "https://www.example.com/img/willow-lane.jpg",
  "worksFor": {
    "@type": "Organization",
    "name": "Example Media",
    "url": "https://www.example.com/"
  },
  "sameAs": [
    "https://www.linkedin.com/in/willowlane",
    "https://x.com/willowlane",
    "https://www.wikidata.org/wiki/Q00000000"
  ]
}

Jedes sameAs hier muss zu einem Profil auflösen, das tatsächlich diese Person ist. Kaputte oder falsch zugeordnete sameAs sind schlimmer als keine.

Person-Schema und Wissenspanels

sameAs ist ein Disambiguierungshinweis, kein Panel-Generator. Es garantiert kein Wissenspanel oder “beweist” Identität gegenüber einem Algorithmus — Google benötigt weiterhin Bestätigung über unabhängige, vertrauenswürdige Quellen, bevor es ein Panel erstellt oder aktualisiert. Konsistentes Person/Organization-Markup hilft bei dieser Erkennung; es erzwingt sie nicht.

Der KI-Suchwinkel — Erwartungen setzen

Das Person-Schema wird oft als Hebel dafür angepriesen, wie LLMs und KI-Suche Sie beschreiben. Seien Sie skeptisch. Ich habe mich öffentlich gegen die SEO-Gewohnheit ausgesprochen, anzunehmen, dass Schema direkt die LLM-Ausgabe beeinflusst – auf LinkedIn habe ich sinngemäß gefragt, warum SEOs glauben, Schema-Markup würde die LLM-Ausgabe beeinflussen, da aktuelle KI-Crawler nicht bestätigt sind, strukturierte Daten in ihre Antworten einzubeziehen. Das ist eine Paraphrase meines eigenen LinkedIn-Beitrags, auszugsweise, kein wörtliches Zitat. Der ehrliche Rahmen: Person-Schema ist Entitätsinfrastruktur – konsistente, maschinenlesbare Identität, die im Laufe der Zeit die Erkennung im Wissensgraphen unterstützt – kein Schalter, der ändert, was eine KI jetzt über Sie sagt.

Das Fazit

Verwenden Sie das Person-Schema, um Engines dabei zu helfen, Sie konsistent zu identifizieren und Ihre Inhalte im gesamten Web abzugleichen. Stimmen Sie es mit der sichtbaren Byline und Biografie ab. Erwarten Sie nicht, dass es Sie rankt, und verwechseln Sie es nicht mit E-E-A-T – dieser Stand ist sowohl von Sullivan als auch von Mueller klar. Siehe den Tab Anti-Patterns für die spezifischen Fehler.

KI-Zusammenfassung

Eine komprimierte Darstellung der erweiterten Version:

• Was es ist: schema.org/Person markiert eine Einzelperson – meistens den author eines Artikels, manchmal das mainEntity einer ProfilePage oder einen Gründer in Organization-Markup. Es ist das Stück Entitäts-Markup auf Einzelebene (Geschwister von Organization- und LocalBusiness-Schema).
• Echte Aufgabe – Disambiguierung: eine Identität über Bylines, Biografien und Profile hinweg verbinden. Der Hebel ist sameAs (LinkedIn, persönliche Website, Wikidata, X, GitHub, ORCID). Weisen Sie author.url auf eine kanonische Biografie-Seite – „Reconciliation“.
• KEIN Ranking-Faktor, KEIN E-E-A-T: Mueller – strukturierte Daten werden eine Website nicht besser ranken lassen. Sullivan – E-E-A-T ist kein direkter Ranking-Faktor; sich selbst als Experten zu deklarieren „bedeutet nichts“. Person-Schema ist eine Selbsterklärung, also kann es keine „Expertise“ verleihen. (Rep-Zitate stammen aus seriöser Sekundärberichterstattung; bestätigen Sie den Wortlaut anhand der Originale.)
• Was Google ermutigt: sichtbare Autorschaft – genaue Bylines und Hintergrundinformationen, die Leser sehen können, keine Referenzen, die nur im Markup versteckt sind.
• Artikel-Autor vs. ProfilePage: unterschiedlicher dokumentierter Status, keine Checkliste. Artikel-Autor: Google empfiehlt offiziell nur name und url (sameAs wird als Alternative zu url akzeptiert); jobTitle erscheint nur in Googles Beispiel, und worksFor/image sind in Googles Artikel-Dokumentation überhaupt nicht enthalten. ProfilePage: mainEntity und name sind erforderlich; alternateName, sameAs, description, image werden empfohlen. Google listet jobTitle/worksFor auch für ProfilePage nicht auf.
• name-Regel: nur der Name in name; die Rolle gehört in jobTitle („Jane Smith, Editor“ ist falsch).
• Wissenspanels: sameAs ist ein Hinweis, kein Generator; Google benötigt unabhängige Bestätigung.
• KI-Suche: Entitätsinfrastruktur, kein Schalter, der die KI-Ausgabe heute ändert.
• Stimmen Sie Markup mit sichtbarem Inhalt ab; nicht übereinstimmendes oder defektes sameAs bricht die Disambiguierung, anstatt zu helfen.

Offizielle Dokumentation

Primärquellen-Dokumentation der Suchmaschinen.

Google

• Article-Strukturierte Daten – die author-Eigenschaft (Person/Organization), die „nur Name“-Regel für author.name und die empfohlene author.url.
• Profilseite (ProfilePage) strukturierte Daten – mainEntity, name/alternateName, sameAs und description (Autorenzeile/Qualifikation).
• Hilfreiche, zuverlässige, menschenzentrierte Inhalte erstellen – Googles Leitfaden zum Hinzufügen genauer Autorenangaben, wie Autorenzeilen, wo Leser sie erwarten.
• Rich Results Test – validieren Sie Article/ProfilePage-Markup.
• Schema Markup Validator – validiert jeden schema.org-Typ, einschließlich Person, wo kein Rich Result erzeugt wird.
• schema.org – Person – die Vokabular-Referenz: jede Person-Eigenschaft.

Bing / Microsoft

• Bing Webmaster-Richtlinien – Bings Unterstützung für schema.org strukturierte Daten und JSON-LD.
• Bing Webmaster Tools – prüfen Sie, wie Bing Ihr Markup liest.

Zitate aus der Quelle

Aussagen von Google-Vertretern auf dem Record. Das einzige wörtliche Zitat unten ist das, auf das sich das Briefing mit konkreter Formulierung beziehen konnte; die übrigen Positionen der Vertreter zu diesem Thema sind paraphrasiert, da sie mich über Sekundärberichte erreichen, und ich setze keine Anführungszeichen um Formulierungen, die ich nicht auf ein Original zurückführen kann.

Danny Sullivan, Google Search Liaison – selbst erklärte Expertise

“having an expert write things doesn’t magically make you rank better, because

1. anyone could self declare someone to be an expert, and that means nothing and
2. we don’t somehow try to check and say ‘Yes, that’s an expert.’” (Übersetzung) „Wenn ein Experte Dinge schreibt, führt das nicht automatisch zu besseren Rankings, denn

1. jeder könnte jemanden zum Experten erklären, und das bedeutet nichts, und
2. wir versuchen nicht irgendwie zu prüfen und zu sagen: ‚Ja, das ist ein Experte.‘“

Danny Sullivan – E-E-A-T ist kein direkter Ranking-Faktor (Paraphrase)

• Sullivan hat gesagt, dass E-E-A-T kein Ranking-Faktor im Sinne einer einzelnen technischen Sache ist, die Google direkt misst (so wie es Geschwindigkeit messen kann); Google verwendet stattdessen eine Vielzahl von Signalen als Proxy dafür, ob Inhalte dem entsprechen, wie ein Mensch E-E-A-T bewerten würde. Paraphrasiert aus Sekundärberichten; nicht wörtlich zitiert, bis eine Primärquelle vorliegt.

John Mueller, Google – strukturierte Daten und Ranking (Paraphrase)

• Mueller hat gesagt, dass strukturierte Daten eine Website nicht besser ranken lassen – sie werden verwendet, um Seiten für die dokumentierten Suchfunktionen qualifiziert zu machen, und ihre Verwendung für andere schema.org-Zwecke ist in Ordnung, aber wahrscheinlich ohne sichtbare Änderung in der Google-Suche. Er hat die Autorenidentifikation auch als Abgleichprozess beschrieben, und empfohlen, dass die Autor-URL auf eine einzige zentrale Profilseite verweist. Paraphrasiert aus der Berichterstattung von Search Engine Journal / Search Engine Roundtable zu Muellers Bluesky/X-Beiträgen; bestätigen Sie gegen die Originale, bevor Sie als exakt zitieren.

Google-Dokumentation – die author.name-Einschränkung (aus Googles Live-Dokumentation)

• “In the author.name property, only specify the name of the author. Don’t add any other piece of information.” (Übersetzung) „Geben Sie in der Eigenschaft author.name nur den Namen des Autors an. Fügen Sie keine anderen Informationen hinzu.“ Article-Strukturierte Daten

Was Sie mit Person-Schema nicht tun sollten

Die Fehler, die immer wieder auftauchen, und warum jeder einzelne scheitert.

Erwarten, dass Person-Schema E-E-A-T oder Rankings verbessert. Dies ist der Hauptfehler. Person-Schema ist eine Selbsterklärung, und Sullivans Punkt ist, dass die Selbsterklärung eines Experten „nichts bedeutet“ für Rankings – Google prüft und zertifiziert keine Experten. Muellers Punkt ist, dass strukturierte Daten eine Seite nicht besser ranken lassen. Fügen Sie Person-Markup für Identität und Berechtigung hinzu; fügen Sie es nicht hinzu, weil Sie eine Ranking-Verbesserung oder „E-E-A-T-Punkte“ erwarten.

Autor-Markup mit sameAs-Profilverlinkung verwechseln. author (Zuordnung eines Artikels zu einer Person) und sameAs (Deklaration, welche externen Profile dieselbe Person sind) erfüllen unterschiedliche Aufgaben. sameAs ist der Disambiguierungshebel; das author-Objekt ist die Zuordnung. Sie benötigen beide, um zu erreichen, was die Leute denken, dass eines davon tut – und nicht übereinstimmende sameAs-Werte (ein Link zum Profil der falschen Person) brechen die Disambiguierung aktiv.

jobTitle/worksFor als Google-Anforderungen behandeln, statt als optionale Anreicherung. jobTitle erscheint in Googles eigenem Artikel-Beispiel; worksFor erscheint in Googles Artikel-Dokumentation überhaupt nicht. Keines ist eine Eigenschaft der empfohlenen Tabelle – Googles formale Artikel-Autor-Empfehlung ist nur name und url (oder sameAs). Das Hinzufügen genauer Zugehörigkeiten kann auf Multi-Autor-Websites helfen, auf denen zwei Autoren denselben Namen teilen, aber vermarkten Sie es nicht als etwas, das Googles Anleitung verlangt oder bewertet.

Anmeldeinformationen nur im Markup verstecken, statt in sichtbaren Bylines. Google ermutigt zu sichtbarer Autorschaft – Bylines und Hintergründe, die Leser tatsächlich sehen können. Einen Jobtitel, Arbeitgeber und Qualifikationen in JSON-LD zu stopfen, während die Seite nur einen nackten Namen zeigt, ist rückwärts. Schlimmer noch: Markup, das Dinge behauptet, die nicht im sichtbaren Inhalt vorhanden sind, verstößt gegen Googles Richtlinien für strukturierte Daten (Markup muss den sichtbaren Inhalt widerspiegeln). Setzen Sie es zuerst auf die Seite; spiegeln Sie es im Schema als Zweites.

Den Jobtitel in das name-Feld stopfen. Google ist explizit: Nur der Name gehört in author.name – „Jane Smith, Senior Editor“ ist falsch. Verwenden Sie die separate jobTitle-Eigenschaft.

Person und ProfilePage als dieselbe Checkliste behandeln. Die beiden Seitentypen haben unterschiedlichen dokumentierten Status. Artikel-Autor Person: Google empfiehlt name und url (sameAs als Alternative); jobTitle ist Beispielinhalt, keine Empfehlung. ProfilePage mainEntity Person: mainEntity und name sind erforderlich; alternateName, sameAs, description, und image werden empfohlen; jobTitle/worksFor werden dort nicht erwähnt. Wenn Sie eine Checkliste auf beide anwenden, über- oder unterbewerten Sie die Seite.

Annehmen, dass sameAs allein ein Knowledge Panel erstellt. Es ist ein Hinweis unter vielen Signalen, kein Panel-Generator oder ein Identitätsnachweis. Google benötigt unabhängige Bestätigung, bevor es ein Panel erstellt oder aktualisiert.

Erwarten, dass Person-Schema ändert, was KI/LLMs heute über Sie sagen. Aktuelle KI-Crawler sind nicht bestätigt, strukturierte Daten direkt in ihre Antworten einzubeziehen. Behandeln Sie Person-Schema als Entitätsinfrastruktur für das lange Spiel, nicht als Schalter, der KI-Ausgabe diese Woche neu schreibt.

Welches Person-Markup benötige ich?

Artikel-Autor-Markup und ProfilePage-Markup erfordern unterschiedliche Eigenschaftssätze – dies erläutert, welches zutrifft, bevor Sie JSON-LD schreiben.

Checkliste zur Implementierung des Person-Schemas

Arbeiten Sie dies durch, bevor Sie Person-Markup auf einer Autoren-Byline oder einer ProfilePage veröffentlichen.

• Das Namensfeld enthält nur den Namen. Kein „Jane Smith, Senior Editor“ – Google ist eindeutig: author.name sollte ausschließlich den Namen enthalten.
• jobTitle ist eine separate Eigenschaft und wird nur hinzugefügt, wenn diese Rolle tatsächlich auf der Seite sichtbar ist.
• author.url verweist auf eine kanonische Bio-/Über-Seite – dieselbe URL bei jedem Artikel dieses Autors, nicht ein anderer Link pro Beitrag.
• worksFor (Organization) ist gesetzt, wenn der Arbeitgeber sichtbar und für die Autorenzeile relevant ist.
• image entspricht dem tatsächlich auf der Seite gezeigten Porträt.
• sameAs listet nur Profile, die nachweislich zu dieser Person gehören (LinkedIn, persönliche Website, Wikidata, X, GitHub, ORCID, sofern zutreffend) – ein falscher Link schwächt die Disambiguierung, statt sie zu stärken.
• Jedes ausgezeichnete Detail ist auf der Seite sichtbar. Berufsbezeichnung, Arbeitgeber und Bio im Schema sollten widerspiegeln, was ein Leser tatsächlich sehen kann, und keine Qualifikationen hinzufügen, die nur in JSON-LD existieren.
• ProfilePage-Objekte verwenden den ProfilePage-Eigenschaftssatz, nicht den des Artikel-Autors: name, alternateName (Handle), sameAs, description – jobTitle/worksFor dort weglassen.
• Das Markup validiert im Rich Results Test oder im Schema Markup Validator.
• Die Erwartungen sind korrekt gesetzt: Dies ist eine Verbesserung der Identität/Berechtigung, kein Ranking- oder E-E-A-T-Hebel – messen Sie es nicht an Ranking-Änderungen.

Person-Schema-Kurzreferenz

Person-Markup disambiguiert eine Entität; es erzeugt keine Expertise, Rankings oder ein Knowledge Panel.

Testen Sie sich: Person-Schema

Fünf kurze Fragen dazu, was Person-Schema leistet – und was nicht. Wählen Sie für jede eine Antwort und prüfen Sie dann.

Änderungsprotokoll