JSON-LD Structured Data in Astro
Du hast eine gut strukturierte Astro-Website gebaut. Die Inhalte sind durchdacht, die Seiten laden schnell, das Design ist barrierefrei. Doch wenn Google deine Seiten crawlt, sieht es nur Text und HTML-Elemente. Es versteht nicht automatisch, dass dein FAQ-Bereich Fragen und Antworten enthalt, dass deine Leistungsseite Services beschreibt oder dass dein Unternehmen an einem bestimmten Standort operiert. Genau hier kommen strukturierte Daten ins Spiel.
JSON-LD (JavaScript Object Notation for Linked Data) ist Googles bevorzugtes Format, um Maschinen mitzuteilen, was der Inhalt einer Seite bedeutet — nicht nur, was er darstellt. Ein unsichtbares <script>-Tag im HTML-Head liefert Suchmaschinen einen strukturierten Datensatz, der direkt zu Rich Results in den Suchergebnissen fuhrt: aufklappbare FAQ-Antworten, Sternebewertungen, Breadcrumb-Pfade und Visitenkarten mit Adresse und Offnungszeiten.
Google verwendet strukturierte Daten, um den Inhalt einer Seite zu verstehen und diesen Inhalt in einem visuell ansprechenderen Format in den Suchergebnissen darzustellen — als sogenannte Rich Results.
Warum strukturierte Daten entscheidend sind
Rich Results heben deine Seite visuell aus der Masse der Suchergebnisse hervor. Wahrend normale Ergebnisse nur Titel, URL und Meta-Description zeigen, können Seiten mit strukturierten Daten aufklappbare FAQ-Sektionen, Sternebewertungen, Breadcrumb-Navigation, Preistabellen und Unternehmensdetails direkt in der SERP anzeigen. Das bedeutet mehr Fläche, mehr Aufmerksamkeit und deutlich hohere Klickraten.
Strukturierte Daten sind dabei kein Ranking-Faktor im engeren Sinne — sie helfen Google aber, den Kontext deiner Inhalte besser zu verstehen. Und indirekt verbessern hohere Klickraten, niedrigere Absprungraten und eine bessere Nutzerinteraktion dein Ranking sehr wohl.
Was ist JSON-LD?
JSON-LD steht für JavaScript Object Notation for Linked Data. Es ist ein standardisiertes Format, das semantische Informationen in einem <script>-Tag im HTML-Dokument einbettet. Suchmaschinen lesen dieses Tag, Nutzer sehen es nicht.
<!-- Unsichtbar für Nutzer, maschinenlesbar für Google -->
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "WebPage",
"name": "Meine Seite",
"description": "Eine Beschreibung der Seite"
}
</script>Das Entscheidende: JSON-LD wird nicht gerendert. Es liegt als unsichtbares Skript im <head> oder am Ende des <body>. Es blockiert weder das Rendering noch verlangsamt es den Seitenaufbau. Es ist reines Metadaten-Markup — Google liest es, der Browser ignoriert es.
Die vier Schema-Typen im Überblick
In diesem Portfolio verwenden wir vier Schema.org-Typen, die gemeinsam ein vollstandiges semantisches Bild der Website für Suchmaschinen erzeugen.
Erfasst Frage-Antwort-Paare semantisch, damit Suchmaschinen und KI-Systeme (Google AI Overviews, ChatGPT, Perplexity) deine Antworten aufgreifen können. Hinweis: Seit August 2023 zeigt Google FAQ-Rich-Results nur noch für autoritative Websites aus dem Behörden- und Gesundheitsbereich. Allgemeine Websites profitieren weiterhin von der semantischen Klarheit für AI-Grounding und den Knowledge Graph — das expandierbare SERP-Element entfällt jedoch.
Teilt Google mit, welche Dienstleistungen du anbietest, inklusive Name, Beschreibung und Anbieter-Informationen. Besonders relevant für Freelancer und Agenturen, deren Service-Seiten in den Suchergebnissen mit zusatzlichen Details angezeigt werden können. In Kombination mit LocalBusiness entsteht ein umfassendes Bild deines Angebots.
Erzeugt einen Navigationspfad in den Suchergebnissen (Home > Leistungen > Webentwicklung). Google ersetzt die nackte URL durch eine lesbare Pfadstruktur. Das verbessert die Orientierung für Nutzer direkt in der SERP und signalisiert Google eine klare Website-Hierarchie. Wird auf jeder Seite über die Breadcrumbs-Komponente generiert.
Enthalt Firmenname, Adresse, Geo-Koordinaten und Kontaktdaten. Essentiell für lokales SEO -- Google nutzt diese Daten für den Knowledge Graph, Google Maps-Einblendungen und die lokale Suche. Wird seitenweit über die SEO-Komponente ausgegeben und bezieht Daten direkt aus der zentralen SITE-Konfiguration.
FAQPage-Schema Implementierung
Das FAQPage-Schema erfasst Frage-Antwort-Paare semantisch. Die Implementierung in Astro nutzt die vorhandene FAQ-Datenstruktur und generiert das JSON-LD automatisch.
---
/* FAQPage JSON-LD Generierung aus dem FAQ-Daten-Array */
interface FaqItem {
question: string;
answer: string;
}
interface Props {
items: FaqItem[];
}
const { items } = Astro.props;
/* Schema.org FAQPage strukturierte Daten */
const faqSchema = {
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": items.map((item) => ({
"@type": "Question",
"name": item.question,
"acceptedAnswer": {
"@type": "Answer",
"text": item.answer,
},
})),
};
---
<!-- Sichtbares Accordion für Nutzer -->
<section id="faq" class="faq">
{items.map((item) => (
<details class="faq__item">
<summary class="faq__question">{item.question}</summary>
<p class="faq__answer">{item.answer}</p>
</details>
))}
</section>
<!-- Unsichtbares JSON-LD für Suchmaschinen -->
<script
type="application/ld+json"
set:html={JSON.stringify(faqSchema)}
/>{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Welche Technologien verwenden Sie?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Wir arbeiten mit Astro, React, TypeScript und modernen CSS-Techniken. Alle Projekte folgen der Atomic-Design-Methodik."
}
},
{
"@type": "Question",
"name": "Wie lange dauert ein typisches Projekt?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Je nach Umfang zwischen 2 und 8 Wochen. Ein Portfolio-Relaunch dauert typischerweise 3-4 Wochen."
}
},
{
"@type": "Question",
"name": "Bieten Sie auch Wartung an?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Ja, wir bieten laufende Wartung, Sicherheitsupdates und Performance-Monitoring als monatlichen Service an."
}
}
]
}Google-Suchergebnisse mit FAQPage Rich Result:
┌─────────────────────────────────────────────────┐
│ Arnold Wender — Webentwickler & Creator │
│ https://arnoldwender.com │
│ Modernes Webdesign mit Astro, React und... │
│ │
│ ▸ Welche Technologien verwenden Sie? │
│ ▸ Wie lange dauert ein typisches Projekt? │
│ ▸ Bieten Sie auch Wartung an? │
└─────────────────────────────────────────────────┘
Jede Frage ist klickbar und expandiert die Antwort
direkt in den Suchergebnissen — ohne die Seite
besuchen zu müssen. Das verdreifacht die sichtbare
Fläche deines Suchergebnisses.Service-Schema für die Leistungsseite
Das Service-Schema kommuniziert Google, welche Dienstleistungen angeboten werden. Jeder Service wird einzeln mit Name, Beschreibung und Anbieter-Referenz erfasst.
---
/* Service-Schema für die Leistungsseite */
import { SITE } from '../../lib/constants';
const services = [
{
name: 'Webentwicklung',
description: 'Individuelle Websites mit Astro, React und modernem CSS.',
},
{
name: 'UI/UX Design',
description: 'Benutzerzentriertes Design mit Atomic-Design-Methodik.',
},
{
name: 'SEO-Optimierung',
description: 'Technisches SEO, strukturierte Daten und Performance.',
},
];
/* Jeder Service wird als eigenes Schema-Objekt erfasst */
const serviceSchemas = services.map((service) => ({
"@context": "https://schema.org",
"@type": "Service",
"name": service.name,
"description": service.description,
"provider": {
"@type": "Person",
"name": SITE.author,
"url": SITE.url,
},
}));
---
{serviceSchemas.map((schema) => (
<script
type="application/ld+json"
set:html={JSON.stringify(schema)}
/>
))}[
{
"@context": "https://schema.org",
"@type": "Service",
"name": "Webentwicklung",
"description": "Individuelle Websites mit Astro, React und modernem CSS. Performant, barrierefrei und SEO-optimiert.",
"provider": {
"@type": "Person",
"name": "Arnold Wender",
"url": "https://arnoldwender.com"
}
},
{
"@context": "https://schema.org",
"@type": "Service",
"name": "UI/UX Design",
"description": "Benutzerzentriertes Design mit Atomic-Design-Methodik. Wireframes, Prototypen und Design-Systeme.",
"provider": {
"@type": "Person",
"name": "Arnold Wender",
"url": "https://arnoldwender.com"
}
},
{
"@context": "https://schema.org",
"@type": "Service",
"name": "SEO-Optimierung",
"description": "Technisches SEO, strukturierte Daten und Core Web Vitals Performance-Optimierung.",
"provider": {
"@type": "Person",
"name": "Arnold Wender",
"url": "https://arnoldwender.com"
}
}
]BreadcrumbList in Astro
Die BreadcrumbList ist das Schema, das auf jeder einzelnen Seite generiert wird. Es beschreibt den Navigationspfad von der Startseite bis zur aktuellen Seite. In Astro fliesst diese Information über eine elegante Prop-Kette von der Seite über das Layout bis zur Breadcrumbs-Komponente.
Datenfluss der Breadcrumbs
- Breadcrumbs in der Seite definieren
Jede Astro-Seite definiert ihre Breadcrumbs als Array von Objekten mit label und optionalem href. Die letzte Stufe hat keinen Link -- sie reprasentiert die aktuelle Seite.
- An BaseLayout ubergeben
Die Seite ubergibt das Breadcrumbs-Array als Prop an das BaseLayout. BlogLayout und PortfolioLayout leiten diese Prop automatisch an BaseLayout weiter.
- Breadcrumbs-Komponente rendert HTML und JSON-LD
Die Breadcrumbs-Molekul-Komponente rendert sowohl die sichtbare Navigation als HTML-Liste als auch das unsichtbare BreadcrumbList-Schema als JSON-LD-Script.
- Google zeigt den Pfad in der SERP
Statt der nackten URL (arnoldwender.com/blog/json-ld) zeigt Google den lesbaren Pfad: Home > Blog > JSON-LD Strukturierte Daten. Das verbessert die Klickrate und Nutzerorientierung.
---
/* src/pages/leistungen.astro — Breadcrumbs für die Leistungsseite */
import BaseLayout from '../layouts/BaseLayout.astro';
const breadcrumbs = [
{ label: 'Home', href: '/' },
{ label: 'Leistungen' }, /* Kein href = aktuelle Seite */
];
---
<BaseLayout
seo={{ title: 'Leistungen', description: '...' }}
breadcrumbs={breadcrumbs}
>
<section id="leistungen">
<!-- Seiteninhalt -->
</section>
</BaseLayout>---
/* src/components/molecules/Breadcrumbs.astro */
import type { BreadcrumbItem } from '../../types';
interface Props {
items: BreadcrumbItem[];
}
const { items } = Astro.props;
/* BreadcrumbList-Schema generieren */
const breadcrumbSchema = {
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": items.map((item, index) => ({
"@type": "ListItem",
"position": index + 1,
"name": item.label,
...(item.href && { "item": `${Astro.site}${item.href}` }),
})),
};
---
<!-- Sichtbare Breadcrumb-Navigation -->
<nav aria-label="Breadcrumb" class="breadcrumbs">
<ol class="breadcrumbs__list">
{items.map((item, i) => (
<li class="breadcrumbs__item">
{item.href
? <a href={item.href}>{item.label}</a>
: <span aria-current="page">{item.label}</span>
}
</li>
))}
</ol>
</nav>
<!-- Strukturierte Daten für Google -->
<script
type="application/ld+json"
set:html={JSON.stringify(breadcrumbSchema)}
/>{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Home",
"item": "https://arnoldwender.com/"
},
{
"@type": "ListItem",
"position": 2,
"name": "Blog",
"item": "https://arnoldwender.com/blog"
},
{
"@type": "ListItem",
"position": 3,
"name": "JSON-LD Strukturierte Daten"
}
]
}LocalBusiness für Geo-Targeting
Das LocalBusiness-Schema ist essentiell für jedes Unternehmen, das Kunden in einer bestimmten Region bedient. Es enthalt Firmenname, Adresse, Geo-Koordinaten und Kontaktdaten. Google nutzt diese Informationen für den Knowledge Graph, lokale Suchergebnisse und Google-Maps-Einblendungen.
In diesem Portfolio werden die Geo-Daten zentral in der SITE-Konfiguration gepflegt und automatisch in das LocalBusiness-Schema ubertragen.
/* src/lib/constants.ts — Zentrale Konfiguration */
export const SITE: SiteConfig = {
name: 'Arnold Wender',
description: 'Webentwickler & Digitaler Creator',
url: 'https://arnoldwender.com',
locale: 'de',
author: 'Arnold Wender',
geo: {
latitude: 51.4818,
longitude: 11.9689,
placeName: 'Halle (Saale), Germany',
region: 'ST',
},
};{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "Arnold Wender — Webentwicklung",
"description": "Webentwickler & Digitaler Creator",
"url": "https://arnoldwender.com",
"telephone": "+49-XXX-XXXXXXX",
"address": {
"@type": "PostalAddress",
"addressLocality": "Halle (Saale)",
"addressRegion": "ST",
"addressCountry": "DE"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 51.4818,
"longitude": 11.9689
},
"areaServed": {
"@type": "GeoCircle",
"geoMidpoint": {
"@type": "GeoCoordinates",
"latitude": 51.4818,
"longitude": 11.9689
},
"geoRadius": "50000"
}
}---
/* src/components/seo/SEO.astro — Auszug */
import { SITE } from '../../lib/constants';
/* LocalBusiness nur auf der Startseite */
const isHomepage = Astro.url.pathname === '/';
const localBusinessSchema = isHomepage && SITE.geo ? {
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": SITE.name,
"description": SITE.description,
"url": SITE.url,
"address": {
"@type": "PostalAddress",
"addressLocality": SITE.geo.placeName,
"addressRegion": SITE.geo.region,
"addressCountry": "DE",
},
"geo": {
"@type": "GeoCoordinates",
"latitude": SITE.geo.latitude,
"longitude": SITE.geo.longitude,
},
} : null;
---
{localBusinessSchema && (
<script
type="application/ld+json"
set:html={JSON.stringify(localBusinessSchema)}
/>
)}Mehrsprachige strukturierte Daten
Bei mehrsprachigen Websites muss jede Sprachversion ihre eigenen strukturierten Daten generieren. Das bedeutet: Die deutsche Seite liefert deutsches JSON-LD, die englische Seite englisches JSON-LD, die spanische Seite spanisches JSON-LD. Suchmaschinen ordnen die strukturierten Daten der jeweiligen Sprachversion zu.
In Astro werden mehrsprachige Seiten über die Ordnerstruktur (/de/, /en/, /es/) oder über Content Collections mit einem locale-Feld verwaltet. Jede Sprachversion der Seite rendert ihr eigenes <script type="application/ld+json"> mit den ubersetzten Inhalten. Die Schema-Struktur (@type, @context) bleibt identisch — nur die menschenlesbaren Felder (name, description, text) werden ubersetzt.
Die Implementierung nutzt die Locale-Information aus dem Frontmatter oder der URL. FAQ-Fragen, Service-Beschreibungen und Breadcrumb-Labels kommen aus sprachspezifischen Daten-Dateien. Das Schema wird zur Build-Zeit für jede Sprache separat generiert — es gibt keine dynamische Sprachumschaltung im JSON-LD.
Der haufigste Fehler ist das Mischen von Sprachen innerhalb eines JSON-LD-Blocks. Wenn die Seite auf Deutsch ist, müssen alle Texte im Schema ebenfalls Deutsch sein. Ein zweiter Fehler: vergessen, die inLanguage-Property zu setzen. Dritter Fehler: identische strukturierte Daten auf allen Sprachversionen — Google erkennt das als Duplikat.
Testen und Validieren
Strukturierte Daten zu implementieren ist nur die halbe Arbeit. Ohne systematisches Testen kannst du nicht sicher sein, dass Google deine Schemas korrekt interpretiert. Es gibt vier Werkzeuge, die du in deinem Workflow verwenden solltest.
Validierungs-Workflow
- Google Rich Results Test
Das offizielle Google-Tool unter search.google.com/test/rich-results. Gib deine URL ein oder fuge HTML-Code ein. Es zeigt dir genau, welche Rich Results Google aus deinen strukturierten Daten erzeugen kann -- und meldet Fehler oder Warnungen.
- Schema.org Validator
Unter validator.schema.org kannst du dein JSON-LD gegen die Schema.org-Spezifikation validieren. Dieses Tool ist strenger als Googles Test und pruft auch Felder, die Google selbst ignoriert. Ideal für vollstandige Konformitat.
- Chrome DevTools Inspektion
Offne die DevTools (F12), gehe zu Elements und suche nach <script type="application/ld+json">. Hier siehst du den tatsachlichen JSON-LD-Output deiner Seite. Prufe, ob die Daten korrekt sind, alle Felder vorhanden sind und keine JavaScript-Fehler die Generierung storen.
- Google Search Console
Nach dem Deployment uberwachst du im Bereich "Verbesserungen" > "Rich Results" den Status deiner strukturierten Daten über die Zeit. Google zeigt dir, welche Seiten Rich-Result-fahig sind, welche Fehler haben und wie sich die Impressionen entwickeln.
Haufige Fehler vermeiden
Die korrekte Implementierung strukturierter Daten erfordert Prazision. Kleine Fehler können dazu fuhren, dass Google dein Schema komplett ignoriert. Hier sind die haufigsten Stolperfallen und wie du sie vermeidest.
| Aspekt | Richtig Recommended | Falsch |
|---|---|---|
| Schema pro Seite | Ein FAQPage-Schema mit allen Fragen | Mehrere FAQPage-Schemas auf derselben Seite |
| Pflichtfelder | Alle required-Felder laut Schema.org | Felder weglassen und hoffen, dass Google es akzeptiert |
| @type Schreibweise | @type: "FAQPage" (exakt) | @type: "faqpage" oder @type: "FAQ" |
| Inhalts-Ubereinstimmung | JSON-LD-Text = sichtbarer Seiteninhalt | Andere Texte im Schema als auf der Seite |
| Verschachtelung | Fläche Struktur, saubere @type-Zuweisungen | Ubertiefe Verschachtelung ohne klare Hierarchie |
| Mehrere Schemas | Separate <script>-Tags für jeden Typ | Alle Schemas in ein einzelnes <script>-Tag packen |
| Sprache | inLanguage passend zur Seitensprache | Kein inLanguage oder falsche Sprache angegeben |
Sitemap-Integration
Strukturierte Daten und die Sitemap arbeiten Hand in Hand. Seiten mit reichhaltigen Schema-Auszeichnungen verdienen eine hohere Crawl-Prioritat, weil sie potenziell mehr Informationen für den Google-Index liefern. In der Astro-Konfiguration wird dies über ein abgestuftes Prioritaten-System umgesetzt.
Die Startseite enthalt Organization- und LocalBusiness-Schema. Hochste Crawl-Prioritat und tagliche Crawl-Frequenz.
Leistungen, Über uns, Kontakt -- Seiten mit Service- und ContactPage-Schemas. Wochentliche Crawl-Frequenz.
Jeder Artikel hat ein Article-Schema mit Autor, Datum und Tags. Monatliche Crawl-Frequenz für altere Posts.
Projektseiten mit CreativeWork-Schema. Werden seltener aktualisiert, aber sind wichtig für die Gesamtstruktur.
Tag- und Kategorie-Seiten mit CollectionPage-Schema. Helfen Google, die Taxonomie zu verstehen.
Suchseiten und Paginierung. Niedrige Prioritat, werden aber für vollstandige Indexierung benotigt.
Haufig gestellte Fragen
Frequently Asked Questions
Nein, JSON-LD hat praktisch keinen Einfluss auf die Performance. Die Script-Tags sind typischerweise nur wenige Kilobyte gross und werden vom Browser nicht gerendert oder ausgefuhrt. Sie blockieren weder das Parsing noch das Rendering der Seite. Im Gegensatz zu Microdata, das ins HTML eingebettet wird, ist JSON-LD vollstandig vom visuellen DOM getrennt.
Es gibt kein technisches Limit. Google empfiehlt, alle relevanten Schema-Typen zu verwenden, solange sie den tatsachlichen Seiteninhalt beschreiben. Eine typische Seite könnte WebPage, BreadcrumbList und ein inhaltsspezifisches Schema (FAQPage, Service, Article) kombinieren. Wichtig ist, dass jeder Schema-Typ in einem eigenen <script>-Tag steht.
Technisch ja, aber Google empfiehlt JSON-LD explizit als bevorzugtes Format. Microdata wird direkt in HTML-Attribute eingebettet, was den Code schwerer wartbar macht und in komponentenbasierten Frameworks wie Astro oder React zu Problemen fuhren kann. JSON-LD trennt strukturierte Daten vollstandig vom Markup -- sauberer, einfacher zu debuggen und einfacher zu aktualisieren.
Zwischen einigen Tagen und mehreren Wochen. Nachdem Google deine Seite mit den neuen strukturierten Daten gecrawlt hat, muss das Schema validiert und die Rich Results generiert werden. Du kannst den Prozess beschleunigen, indem du die URL über die Google Search Console zur Neuindexierung einreichst. Uberwache den Fortschritt im Rich-Results-Bericht der Search Console.
Google ignoriert fehlerhaftes Schema stillschweigend -- es gibt keine Penalty. Allerdings werden keine Rich Results generiert. Verwende den Google Rich Results Test, um Fehler vor dem Deployment zu finden. Haufige Fehler: fehlende Pflichtfelder, falsche @type-Werte und Inhalte im Schema, die nicht mit dem sichtbaren Seiteninhalt ubereinstimmen.
Wenn dein JSON-LD dynamisch aus den Seitendaten generiert wird (wie in diesem Astro-Setup), aktualisiert es sich automatisch bei jedem Build. Andern sich FAQ-Fragen, Services oder Breadcrumbs, spiegelt sich das automatisch in den strukturierten Daten wider. Bei statischen JSON-LD-Blocken musst du manuell auf Konsistenz achten.
Zusammenfassung
Strukturierte Daten mit JSON-LD sind kein optionaler SEO-Bonus — sie sind ein fundamentaler Bestandteil moderner Web-Entwicklung. Sie kosten keine Performance, erfordern keinen Framework-Wechsel und können in Astro elegant in die bestehende Komponentenarchitektur integriert werden. Vier Schema-Typen — FAQPage, Service, BreadcrumbList und LocalBusiness — decken die wichtigsten Anwendungsfalle für ein Portfolio oder eine Unternehmenswebsite ab.
Der Schlüssel liegt in der Automatisierung: Strukturierte Daten sollten nicht manuell gepflegt werden, sondern sich aus den gleichen Datenquellen speisen wie die sichtbaren Inhalte. In Astro bedeutet das: Props und Content Collections fliessen in Komponenten, die sowohl das visuelle HTML als auch das unsichtbare JSON-LD rendern. Eine einzige Quelle der Wahrheit für Mensch und Maschine.