Bedeutung und Umfang
Der Schema.org-Typ WebSite kann Name, URL und verwandte Angaben einer Website in strukturierten Daten ausdrücken. Er ist ein Vokabular und kein Versprechen, dass eine Suchmaschine ein bestimmtes Feature anzeigt. Google entscheidet selbst, wie, wann und ob strukturierte Daten in der Suchdarstellung verwendet werden, und kann die Unterstützung einzelner Features im Lauf der Zeit ändern.
Praktischer Ablauf
Modellieren Sie nur Fakten, die stabil und sichtbar oder anderweitig überprüfbar sind. Verwenden Sie die kanonische URL der Startseite, den Namen, den Nutzer sehen, und Beziehungen zu einer Organisation nur dann, wenn sie genau dieselbe öffentliche Entität beschreiben. JSON-LD ist ein verbreitetes Übertragungsformat, doch ein syntaktisch gültiger Graph kann irreführend sein, wenn er Fakten verschiedener Websites oder veraltete Einstellungen kombiniert.
Was Sie prüfen sollten
Prüfen Sie den gerenderten Seitenquelltext und parsen Sie den Graphen nach dem Deployment. Bestätigen Sie, dass Identifikatoren wie erwartet aufgelöst werden, dass Werte mit der sichtbaren Identität der Website übereinstimmen und dass es keinen doppelten oder widersprüchlichen Graphen auf Site-Ebene gibt. Validieren Sie Vokabular und Syntax und prüfen Sie den aktuellen Feature-Support anschließend in der einschlägigen Google-Dokumentation, statt sich auf alte Tutorials zu verlassen.
Grenzen und typische Fehler
Fügen Sie SearchAction nicht hinzu, um ein eingestelltes oder nicht unterstütztes Anzeigefeature zu erreichen. Erfinden Sie auch keine alternativen Namen, Herausgeberbeziehungen oder Suchendpunkte. Strukturierte Daten sollen vorhandene Fakten verdeutlichen; sie können schwachen Content, nicht erreichbare Seiten oder eine unklare Canonical-Einrichtung nicht reparieren.
Die WebSite-Entität sorgfältig modellieren
Beginnen Sie mit der Startseite, die Nutzer und Crawler nach Weiterleitungen tatsächlich erreichen. Halten Sie ihre finale kanonische URL, den sichtbaren Seitennamen, einen eventuell sichtbaren alternativen Namen und die Beziehung zur Organisation fest – aber nur, wenn beide dieselbe öffentliche Entität beschreiben. Ein WebSite-Graph sollte keinen anderen Host, keinen Staging-Namen und keine alte Rechtsidentität wiederholen, nur weil diese Werte noch in einer CMS-Einstellung stehen. Stabile Identifikatoren sind nützlicher als ein großer Graph mit widersprüchlichen Knoten.
{ "@context": "https://schema.org", "@type": "WebSite", "name": "Example", "url": "https://example.test/" }Prüfen Sie das gerenderte HTML statt einer Editor-Vorschau. Parsen Sie jedes JSON-LD-Script und listen Sie @id, @type, name, url, alternateName sowie die Verbindungen zu Organisation- oder WebPage-Knoten auf. Vergleichen Sie diese Felder dann mit den sichtbaren Fakten der Seite. Validierungstools erkennen Syntax- oder Vokabularfehler, können aber nicht wissen, ob ein alter Seitenname, eine veraltete URL oder ein nicht unterstütztes Versprechen die tatsächlichen Verhältnisse des Unternehmens widerspiegelt.
Testen Sie den Graphen auf Startseite, Sprachvarianten und wichtigen Templates. Markup auf Site-Ebene wird oft global eingebunden, daher kann eine Änderung einen Knoten duplizieren oder jeder Sprachversion eine widersprüchliche URL zuweisen. Wenn regionale oder sprachliche Websites eigenständige Entitäten sind, dokumentieren Sie die Beziehung bewusst, statt eine WebSite-Deklaration unverändert zu kopieren. Prüfen Sie, dass die kanonischen URLs im Graphen direkt und einheitlich aufrufbar sind.
Fügen Sie kein Property nur deshalb hinzu, weil ein altes Tutorial behauptet, es löse eine Suchfunktion aus. Schema.org definiert das Vokabular, während Google getrennt dokumentiert, welche strukturierten Daten-Features aktuell unterstützt werden und sich ändern können. Eine gültige WebSite-Entität kann die maschinenlesbare Konsistenz verbessern, garantiert aber keinen angezeigten Seitennamen, keine Sitelinks und keine andere Suchfunktion.