SSM - Einheitlicher Standard für Metadaten

Definitionen

Der SSM-Standard legt Anforderungen an die Semantik, die Barrierefreiheit und die Funktionslogik von Metadaten fest.

Struktur und Semantik

Seitentitel und Beschreibung

• Jede indexierbare Seite erhält einen eindeutigen und zutreffenden <title>. Er beschreibt den Hauptinhalt knapp und wird nicht durch den Website-Namen oder einen allgemeinen Vorlagentext ersetzt.
• Jede indexierbare Seite erhält eine eindeutige, aussagekräftige Beschreibung. Sie muss dem sichtbaren Inhalt entsprechen und darf nicht aus einer Liste von Schlüsselwörtern bestehen.
• Für <title> und Beschreibung gibt es keine allgemeingültige Zeichenbegrenzung. Eine Suchmaschine kann den Titel kürzen oder Titel und Snippet aus anderen Teilen der Seite erzeugen.
• Die Seitenbeschreibung kann für ein Such-Snippet verwendet werden; eine Suchmaschine kann jedoch einen anderen Textausschnitt auswählen. Titel und Beschreibung garantieren weder Klicks noch Positionen in den Suchergebnissen.

Kanonische URL

• Für eine Gruppe doppelter oder sehr ähnlicher URLs wird die bevorzugte kanonische Adresse mit rel="canonical" oder einem geeigneten Mechanismus in der HTTP-Antwort angegeben.
• Die kanonische Adresse muss auf eine zugängliche Seite mit gleichwertigem Hauptinhalt verweisen. Üblicherweise werden eine stabile absolute HTTPS-URL und ein selbstreferenzieller Canonical-Verweis auf der bevorzugten Version verwendet.
• Ein Canonical ist ein Signal an eine Suchmaschine, kein uneingeschränkter Befehl. Er hilft, die bevorzugte URL zu bestimmen und Signale ähnlicher Seiten zusammenzuführen. Er ist jedoch weder ein Mittel zum Verbergen einer Seite noch ein Schutz vor einer automatischen „Duplicate-Content-Strafe“.
• Verschiedene Sprachversionen mit übersetztem Hauptinhalt dürfen nicht auf eine einzige Canonical-URL zusammengeführt werden. Jede Version erhält ihre eigene kanonische URL und wird über hreflang verknüpft.

Indexierung und Crawling

• Indexierung und Crawling sind unterschiedliche Vorgänge. robots.txt steuert den Zugriff kompatibler Crawler auf URLs und Ressourcen, ist aber allein kein zuverlässiges Mittel, eine URL aus den Suchergebnissen auszuschließen.
• Um eine zugängliche Seite aus dem Index auszuschließen, wird eine unterstützte noindex-Direktive in den Seitenmetadaten oder im HTTP-Header X-Robots-Tag verwendet. Der Crawler muss die Seite abrufen können, um die Direktive zu verarbeiten.
• Eine in robots.txt gesperrte URL kann einer Suchmaschine weiterhin durch externe Links bekannt sein, auch wenn der Crawler ihren Inhalt nicht abrufen kann. robots.txt ist daher kein Vertraulichkeitsschutz.
• index und follow sind üblicherweise das Standardverhalten und müssen nicht ohne konkreten Grund angegeben werden. Die Direktivenwerte und ihre Unterstützung sind für die jeweiligen Suchmaschinen zu prüfen.
• Beschränkte oder vertrauliche Inhalte werden durch Authentifizierung und Zugriffskontrollen geschützt, nicht allein durch Metadaten oder Crawling-Regeln.
• Zugängliche Seiten müssen den passenden HTTP-Status zurückgeben. Für verschobene Ressourcen wird eine Weiterleitung eingerichtet, für entfernte Ressourcen der entsprechende Nichtverfügbar-Status. Eine XML-Sitemap hilft Crawlern, bevorzugte URLs zu entdecken, garantiert aber weder Crawling noch Indexierung.

Beispiel einer Direktive zum Ausschluss einer Seite aus dem Index:

<meta name="robots" content="noindex">

Der Crawler kann diese Direktive nur beim Abruf der Seite lesen. Wird die URL gleichzeitig in robots.txt gesperrt, erhält der Crawler die noindex-Direktive möglicherweise nicht.

Bereitstellung der Metadaten

• Kritische Metadaten müssen für die vorgesehenen Crawler und Plattformen verfügbar sein. Ist unklar oder eingeschränkt, ob ein Empfänger JavaScript verarbeitet, werden die Metadaten in die ursprüngliche HTML-Antwort oder in HTTP-Header aufgenommen.
• Bei clientseitiger Erzeugung werden das fertig gerenderte Dokument und die tatsächliche HTTP-Antwort geprüft. Änderungen während der Hydrierung dürfen weder widersprüchliche Werte noch mehrere verschiedene Canonical-URLs hinterlassen.

Lokalisierung und Sprachversionen

• Sind Übersetzungen unter eigenen URLs verfügbar, erhält jede Sprachversion eine eigene dauerhafte Adresse und eine kanonische URL, die auf die Version in derselben Sprache mit dem entsprechenden Inhalt verweist.
• Äquivalente Seiten werden mit rel="alternate" und gültigen hreflang-Werten verknüpft. Jede Version führt sich selbst und die übrigen verfügbaren Versionen auf; die Verweise müssen wechselseitig sein und die Zielseiten müssen crawlbar und indexierbar sein.
• In hreflang werden gültige Sprachcodes und bei Bedarf Regionscodes verwendet. x-default kann für eine Standardseite eingesetzt werden, die für Nutzer ohne passende Sprachversion vorgesehen ist.
• Die Hauptsprache des Dokuments wird über das Attribut lang angegeben. Es hilft assistiven Technologien und Benutzeragenten, die Inhaltssprache zu erkennen, ersetzt aber hreflang nicht.
• og:locale gibt die Open-Graph-Lokalisierung im Format Sprache_REGION an, zum Beispiel de_DE. Wiederholte og:locale:alternate-Eigenschaften listen weitere Sprachen auf, in denen die Seite verfügbar ist.
• og:locale:alternate verknüpft keine Übersetzungs-URLs und ersetzt hreflang nicht. Die Liste alternativer Lokalisierungen muss den tatsächlich verfügbaren Übersetzungen entsprechen.

Beispiel für die Verknüpfung lokalisierter URLs:

<html lang="de">
<head>
  <link rel="alternate" hreflang="ru" href="https://example.com/ru/article">
  <link rel="alternate" hreflang="en" href="https://example.com/en/article">
  <link rel="alternate" hreflang="de" href="https://example.com/de/article">
  <link rel="alternate" hreflang="ja" href="https://example.com/ja/article">
  <link rel="alternate" hreflang="x-default" href="https://example.com/article">
</head>
</html>

Dieselbe vollständige Menge wechselseitiger Verweise wird auf jeder Sprachversion mit dem jeweils passenden lang-Wert verwendet.

Metadaten für geteilte Links

Open Graph

• Für eine Open-Graph-Vorschau werden og:title, og:type, og:image und og:url angegeben — die grundlegenden Eigenschaften des Protokolls.
• og:description beschreibt die konkrete Seite knapp. Für ein Bild wird og:image:alt empfohlen; der Wert beschreibt den Bildinhalt und ist keine Bildunterschrift für den Beitrag.
• Die Bild-URL und og:url müssen absolute, öffentlich erreichbare Adressen sein. Für Bilder ist HTTPS vorzuziehen; die Ressource muss ohne Authentifizierung abrufbar sein und darf nicht für Plattform-Crawler gesperrt werden.
• Open-Graph-Werte müssen die konkret geteilte Seite beschreiben. og:url muss mit der bevorzugten dauerhaften Adresse der Seite übereinstimmen.
• og:locale und og:locale:alternate übermitteln Lokalisierungsinformationen zum Objekt, garantieren aber keine lokalisierte Vorschau auf einer sozialen Plattform.

X Cards

• Für eine Karte in X können twitter:*-Eigenschaften gesetzt werden, darunter twitter:card="summary_large_image", sofern dieses Format für den jeweiligen Beitragstyp unterstützt wird.
• summary_large_image legt ein Kartenlayout mit großem Bild fest. Es garantiert weder maximale Reichweite oder CTR noch eine bevorzugte Platzierung im Feed.
• X-Metadaten gelten nicht universell für alle sozialen Netzwerke. Unterstützung, Priorisierung und Zwischenspeicherung der Vorschauen unterscheiden sich je nach Plattform und können sich ändern.
• Titel, Beschreibung und Bild der Karte müssen dem Seiteninhalt entsprechen. Manche Plattformen verwenden ersatzweise Open-Graph-Werte, wenn keine eigenen Angaben vorhanden sind; dieses Verhalten ist auf der Zielplattform zu prüfen.

Website- und Web-App-Icons

Website-Icons

• Ein oder mehrere Website-Icons werden über die Link-Relation rel="icon" angegeben. Unterstützte Formate und Größen hängen vom Browser und vom jeweiligen Anzeigekontext ab.
• SVG eignet sich für ein skalierbares Icon, sollte aber nicht als einziges universell unterstütztes Format betrachtet werden. ICO- oder Rastervarianten werden ergänzt, wenn sie für die Kompatibilität mit den Zielbrowsern und Umgebungen erforderlich sind.
• Ein Favicon muss quadratisch, öffentlich abrufbar und unter einer stabilen URL verfügbar sein. Größen wie 16×16, 32×32 und 48×48 sind Optionen, keine verbindliche vollständige Liste.
• Das Icon für einen Browser-Tab oder ein Suchergebnis kann anders festgelegt werden als die Icons einer installierbaren Web-App.

Web-App-Manifest und Mobilplattformen

• site.webmanifest wird eingebunden, wenn die Website eine Web-App-Konfiguration benötigt. Das Manifest kann Name, Start-URL, Anzeigemodus, Theme und Icon-Satz festlegen.
• Manifest-Icons erhalten korrekte Angaben zu Format, Größe und Verwendungszweck, soweit diese für die Dateiauswahl erforderlich sind. Ein Satz mit 192×192 und 512×512 wird häufig für die Kompatibilität mit bestimmten Installationsumgebungen verwendet, ist aber keine allgemeine Pflicht für jede Website oder jedes Gerät.
• Ein Manifest allein macht eine Website nicht zu einer installierten App und garantiert keine Installierbarkeit. Unterstützung und Installationskriterien hängen von Browser, Betriebssystem und Website-Funktionen ab.
• theme_color im Manifest oder das entsprechende Metadaten-Element kann die Farben der Browser- oder App-Oberfläche beeinflussen. Unterstützung und visuelle Wirkung unterscheiden sich je nach Plattform.
• apple-touch-icon und apple-mobile-web-app-capable betreffen das Hinzufügen einer Website zum Home-Bildschirm und ihren Start in einem separaten Fenster auf Apple-Geräten. Diese plattformspezifischen Einstellungen werden nur verwendet, wenn dieses Szenario unterstützt werden soll; für eine gewöhnliche Website sind sie nicht erforderlich.
• Ein Manifest und separate Apple-Icons können bei der Auswahl der Datei miteinander konkurrieren. Das tatsächlich verwendete Icon ist in den unterstützten Betriebssystem- und Browserversionen zu prüfen.

Strukturierte Daten

• Strukturierte Daten werden nur ergänzt, wenn sie den sichtbaren Seiteninhalt korrekt beschreiben und zum Inhaltstyp passen.
• JSON-LD ist eines der Formate für strukturierte Daten und das in der Google-Dokumentation bevorzugte Format. Schema und Eigenschaften werden anhand der aktuellen Schema.org-Dokumentation und der Anforderungen des jeweiligen Empfängers ausgewählt.
• Eine Auszeichnung kann eine Seite für bestimmte Rich Results qualifizieren, garantiert deren Anzeige aber nicht und ersetzt keine hochwertigen Inhalte.
• Bewertungen, Preise, Produktverfügbarkeit und andere veränderliche Angaben müssen korrekt, aktuell und für Nutzer sichtbar sein. Syntaktisch gültige, aber irreführende Auszeichnungen erfüllen nicht den Zweck strukturierter Daten.

Beispiel für JSON-LD zu Inhalten des Typs Article:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Artikeltitel",
  "image": "https://example.com/de/images/article.webp",
  "datePublished": "2026-09-26",
  "dateModified": "2026-09-26"
}
</script>

Die Beispielwerte werden durch die tatsächlichen Seitendaten ersetzt. Für andere Inhalte sind der passende Typ und die passenden Eigenschaften zu verwenden; optionale Felder dürfen nicht mit erfundenen Werten befüllt werden.

Prüfung

• Für jede indexierbare Seite werden ein eindeutiger <title> und eine Beschreibung geprüft, die dem tatsächlichen Inhalt entsprechen.
• Geprüft werden HTTP-Status, Crawling-Zugriff und mögliche Konflikte zwischen robots.txt, noindex, Weiterleitungen und Canonical-URLs.
• Geprüft wird, ob die Canonical-URL auf die vorgesehene Sprachversion verweist und mit internen Links, Sitemap und og:url übereinstimmt.
• Erreichbarkeit der Sitemap und Korrektheit ihrer URLs werden geprüft. Ein URL-Eintrag in der Sitemap bestätigt keine Indexierung.
• Bei mehrsprachigen Seiten werden lang, alle hreflang-Verweise, deren Gegenseitigkeit und die Erreichbarkeit jeder Version geprüft.
• Vorschauen werden auf den Zielplattformen geprüft, einschließlich absoluter URLs, Bildabruf, Titel, Beschreibung, Lokalisierung und Cache-Verhalten.
• Darstellung von Favicon, Manifest-Icons und Web-App-Modus werden in den angegebenen Browsern und Betriebssystemen geprüft.
• Strukturierte Daten werden mit dem Schema.org-Validator und mit Tests für Rich Results geprüft, sofern diese den gewählten Typ unterstützen. Gültigkeit garantiert kein Rich Result.

SSM-Checkliste

Vollständiges Metadatenbeispiel

Dieses Beispiel zeigt einen Ausschnitt des fertigen Dokuments. Metadaten können durch ein CMS, ein Template, serverseitiges Rendering, einen Generator für statische Websites oder ein anderes Werkzeug erzeugt werden. Die Anforderungen beziehen sich auf das resultierende Dokument und die Antwort, nicht auf eine plattformspezifische API.

<html lang="de">
<head>
  <title>Seitentitel</title>
  <meta name="description" content="Eine kurze Beschreibung des Seiteninhalts.">
  <link rel="canonical" href="https://example.com/de/article">
  <link rel="alternate" hreflang="ru" href="https://example.com/ru/article">
  <link rel="alternate" hreflang="en" href="https://example.com/en/article">
  <link rel="alternate" hreflang="de" href="https://example.com/de/article">
  <link rel="alternate" hreflang="ja" href="https://example.com/ja/article">
  <link rel="alternate" hreflang="x-default" href="https://example.com/article">

  <meta property="og:title" content="Seitentitel">
  <meta property="og:type" content="article">
  <meta property="og:url" content="https://example.com/de/article">
  <meta property="og:image" content="https://example.com/de/images/article-share.webp">
  <meta property="og:image:alt" content="Illustration zum Artikel">
  <meta property="og:locale" content="de_DE">
  <meta property="og:locale:alternate" content="ru_RU">
  <meta property="og:locale:alternate" content="en_US">
  <meta property="og:locale:alternate" content="ja_JP">

  <meta name="twitter:card" content="summary_large_image">
  <link rel="icon" href="/favicon.svg" type="image/svg+xml">
  <link rel="icon" href="/favicon.ico">
  <link rel="manifest" href="/site.webmanifest">
  <meta name="theme-color" content="#ffffff">
</head>
</html>