ai

Inhaltstyp-Schema

MetricSpot prüft auf einen JSON-LD `@type`, der zu dem passt, was die Seite tatsächlich ist — Article, Product, HowTo, FAQPage usw. Ohne ihn müssen KI-Agenten raten.

Was diese Prüfung macht

Parst jeden <script type="application/ld+json">-Block auf der Seite und verifiziert, dass mindestens einer einen @type deklariert, der zum tatsächlichen Zweck der Seite passt. Ein Blogbeitrag sollte Article (oder BlogPosting / NewsArticle) deklarieren; eine Produktseite Product; eine Schritt-für-Schritt-Anleitung HowTo; eine FAQ-Seite FAQPage. Eine Seite, die nur WebPage- oder WebSite-Schema emittiert, fällt durch — diese Typen sind zu generisch, um Agenten etwas Nützliches zu sagen.

Warum es zählt

JSON-LD ist das Gerüst, mit dem KI-Agenten und Suchmaschinen eine Seite verstehen, ohne den Fließtext zu parsen. Ist @type spezifisch, wissen ChatGPT, Perplexity und Google AI Overviews, welche Felder zu extrahieren sind (headline, author, datePublished bei einem Article; price, availability, aggregateRating bei einem Product) und wie die Seite in Antworten zitiert werden kann.

Fehlt @type oder ist er generisch, fällt der Agent auf Body-Text-Heuristiken zurück — langsamer, ungenauer und viel wahrscheinlicher, deine Seite zugunsten einer besser ausgezeichneten Wettbewerberseite zu überspringen. Dieselbe Logik gilt für Googles Rich Results: Nur spezifische Typen schalten die SERP-Features frei (Bewertungssterne, Rezeptkarten, FAQ-Accordions), die die Klickrate heben.

So behebst du es

Wähle den @type, der am besten zur Seite passt, und emittiere einen vollständigen JSON-LD-Block im <head>.

Article / BlogPosting / NewsArticle — für redaktionelle Inhalte. Nutze NewsArticle für datierte Nachrichten; BlogPosting für Blogposts; schlichtes Article ist die sichere Standardwahl.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How to enable HSTS on nginx",
  "datePublished": "2026-05-11",
  "dateModified": "2026-05-11",
  "author": {
    "@type": "Person",
    "name": "Jane Doe",
    "url": "https://example.com/authors/jane-doe"
  },
  "image": "https://example.com/og/hsts.png",
  "mainEntityOfPage": "https://example.com/blog/hsts"
}
</script>

HowTo — für Schritt-für-Schritt-Anleitungen (Rezepte, Reparaturanleitungen, Setup-Tutorials). Pflichtfelder: name, step.

{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "Enable HSTS on nginx",
  "step": [
    { "@type": "HowToStep", "name": "Add the header", "text": "Add `add_header Strict-Transport-Security ...` to your server block." },
    { "@type": "HowToStep", "name": "Reload nginx", "text": "Run `nginx -t && systemctl reload nginx`." }
  ]
}

FAQPage — nur, wenn die Seite tatsächlich ein Q&A ist. Siehe FAQ-Schema für das vollständige Muster.

Product — für einzelne Produktseiten. Füge offers, aggregateRating, review hinzu, wenn du sie hast.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "MetricSpot Premium",
  "description": "Unlimited audits, scheduled monitoring, PDF reports.",
  "brand": { "@type": "Brand", "name": "MetricSpot" },
  "offers": {
    "@type": "Offer",
    "price": "29.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock"
  }
}

Next.js — injiziere via App-Router-<Script> oder einen Metadata-Helper:

import Script from "next/script";

export default function Post() {
  const schema = {
    "@context": "https://schema.org",
    "@type": "BlogPosting",
    headline: "How to enable HSTS on nginx",
    datePublished: "2026-05-11",
    author: { "@type": "Person", name: "Jane Doe" }
  };
  return (
    <Script id="ld" type="application/ld+json">
      {JSON.stringify(schema)}
    </Script>
  );
}

Astro — setze das JSON-LD in deinem Layout-<head>:

---
const schema = { "@context": "https://schema.org", "@type": "BlogPosting", /* … */ };
---
<script type="application/ld+json" set:html={JSON.stringify(schema)} />

WordPress — Yoast SEO, Rank Math und SEOPress emittieren alle automatisch Article-Schema für Beiträge. Prüfe in der gerenderten Quelle, dass @type Article / BlogPosting ist und nicht nur WebPage. Für Produktseiten emittiert WooCommerce standardmäßig Product-Schema.

Nach dem Deployment mit Googles Rich Results Test und dem Schema Markup Validator validieren. Siehe auch: JSON-LD strukturierte Daten, Organization-Schema.

Häufig gestellte Fragen

Kann eine Seite mehrere @type-Blöcke haben?

Ja — üblich und empfohlen. Ein Blogbeitrag liefert typisch Article + BreadcrumbList + Organization. Jeder gehört in seinen eigenen <script type="application/ld+json">-Block, oder du kombinierst sie in einem einzigen @graph-Array. Vermeide Konflikte (deklariere die Seite nicht gleichzeitig als Article und Product).

Soll ich Article oder BlogPosting nutzen?

BlogPosting ist eine Unterklasse von Article — etwas spezifischer, ohne Nachteile. Nutze BlogPosting für Blog-Inhalte, NewsArticle für datierte Nachrichten, Article für immergrüne redaktionelle oder technische Guides. Google behandelt sie für Rich Results gleichwertig.

Was, wenn meine Seite zu keinem Schema-Typ passt?

Generische Landing-Pages können auf WebPage bleiben — diese Prüfung markiert das als sanfte Warnung, nicht als harten Fehler. Aber die meisten “passt-nicht”-Fälle passen doch zu etwas: eine Pricing-Seite ist Product oder Service, eine About-Seite ist AboutPage, eine Kontaktseite ist ContactPage. Durchsuche schema.orgs vollständige Typenliste, bevor du auf WebPage ausweichst.

Quellen

Zuletzt aktualisiert 2026-05-11