Strukturierte Daten: Der komplette Leitfaden (2026)

Strukturierte Daten sind der günstigste SEO-Hebel, den die meisten Sites nie shippen. Du packst einen JSON-Block in den Head einer Seite, bekommst reichere Google-Ergebnisse, klarere KI-Zitierungen und einen Entitäts-Graph, der Suchmaschinen genau sagt, wer was wann geschrieben hat. Ein gelöstes Problem mit einem freien offenen Vokabular auf schema.org. Und trotzdem: Als ich Luminas Schema Validator gegen die 5 top-rankenden deutschen Guides für strukturierte daten auf Google laufen ließ, war das Bild ernüchternd. Nur eine Site shipped FAQPage-Schema überhaupt (ithelps-digital) — und diese eine Site hat gar keinen sichtbaren FAQ-Bereich im HTML, also orphan Schema. Zwei von fünf shippen gar keinen Article- oder BlogPosting-Typ auf einem Blog-Artikel. Zwei haben überhaupt kein dateModified.

Dieser Leitfaden ist die komplette Evergreen-Referenz zu strukturierten Daten 2026. Was das Vokabular ist, welche Formate Google wirklich will, die acht Typen, die 95% aller Sites abdecken, wie du Schema per Hand und über WordPress einbaust, wie du es validierst, welche Typen Google still beerdigt hat, und die fünf Fehler, die ich jede Woche in Kunden-Audits sehe. Code-Beispiele durchgehend. Kein Fluff. Wenn du den engeren KI-Suche-Winkel willst, lies Schema Markup für KI-Suche. Dieser hier deckt alles ab.

Was strukturierte Daten wirklich sind

Strukturierte Daten sind ein gemeinsames Vokabular dafür, worum es auf einer Seite geht. Das Projekt wurde 2011 ins Leben gerufen und wird heute von schema.org verwaltet, gegründet von Google, Microsoft, Yahoo und Yandex, seit 2015 über die W3C Schema.org Community Group koordiniert. Das Vokabular definiert inzwischen mehr als 800 Typen und 1.500 Eigenschaften für Artikel, Produkte, Events, Personen, Organisationen, Rezepte, Bewertungen, Software, Kurse, medizinische Zustände und mehr.

Das Vokabular selbst ist nur eine Taxonomie. Der Markup-Teil ist, wie du es in eine HTML-Seite einbaust, damit Crawler es lesen können. In 2026 heißt das JSON-LD: ein kleiner Script-Block im Head der Seite, der Entitäten und ihre Beziehungen deklariert.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Schema Markup: The Complete Guide",
  "author": { "@type": "Person", "name": "Julien El-Bahy" },
  "datePublished": "2026-04-21"
}
</script>

Dieser achtzeilige Block sagt jeder Suchmaschine und jedem KI-Retriever im Web: Diese Seite ist ein Artikel, hier ist die Headline, hier ist der Autor, hier ist das Veröffentlichungsdatum. Ohne den Block liest Google deine Seite als HTML-Blob und muss sich die Antworten aus dem Body-Text zusammenraten. Mit dem Block sind die Antworten explizit. Die Mehrdeutigkeit ist weg.

Strukturierte Daten sind kein Rankingfaktor im klassischen Sinn von "einbauen und 3 Positionen hochrutschen". Das Search-Central-Team von Google hat das wiederholt auf Record gesagt, besonders hartnäckig über John Mueller in Search-Off-the-Record-Episoden und den SEO-Office-Hours. Was Schema leistet: Du wirst für Rich Results qualifiziert (die angereicherten SERP-Blöcke mit Sternen, FAQs, Preisen, Breadcrumbs, Video-Thumbnails) und lieferst KI-Retrievern wie ChatGPT Search, Perplexity, Claude, Gemini und Google AI Overviews eindeutige Entitäten. Höhere Klickrate auf derselben SERP-Position ist auf dem Papier kein Ranking-Sprung, aber der Traffic sieht identisch aus.

JSON-LD vs Microdata vs RDFa

Drei Formate existieren. Eins davon ist die Antwort für 2026.

JSON-LD (JavaScript Object Notation for Linked Data) lebt in einem <script type="application/ld+json">-Block im Head. Es ist vom sichtbaren HTML getrennt, was heißt, du kannst es hinzufügen, bearbeiten und validieren ohne den Rest der Seite anzufassen. Die Search-Central-Docs von Google empfehlen JSON-LD ausdrücklich als bevorzugtes Format. Jeder größere KI-Retriever parst es zuverlässig.

Microdata verteilt Attribute direkt im sichtbaren HTML: itemscope, itemtype, itemprop. Funktioniert, macht aber das Markup unübersichtlich und Diffs schwer lesbar. Alte CMS-Plugins generieren es noch. Lass sie in Ruhe wenn sie laufen; packe JSON-LD obendrauf, die zwei koexistieren.

RDFa ist das W3C-native Format. Gültig, selten, hauptsächlich in akademischen Publikationen und Government-Datenportalen verwendet. Falls dein Stack es schon ausgibt, okay. Wenn du 2026 neu anfängst, nimmst du es nicht.

Die Schema-Typen, die wirklich zählen

Schema.org definiert 823 Typen. Die Top acht decken 95% aller echten Websites ab. Ordne sie danach, was deine Seite wirklich ist, nicht danach, was in einem Validator beeindruckend aussieht.

1. Article / BlogPosting

Redaktionelle Inhalte. Blogartikel, News, Guides. Sagt Crawlern: Das ist kein Produkt, keine Landingpage, sondern ein Stück Text mit Byline und Datum. Pflichtfelder laut Google: keine. Empfohlen: headline, author, datePublished, dateModified, image, publisher. Das meistgenutzte Schema im Web nach Organization.

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Schema Markup: The Complete Guide",
  "datePublished": "2026-04-21",
  "dateModified": "2026-04-21",
  "author": { "@id": "https://your-site.com/#founder" },
  "publisher": { "@id": "https://your-site.com/#organization" }
}

2. Product

Alles, was verkauft wird. Google belohnt das mit Preis, Verfügbarkeit und Sternebewertung im SERP. Pflicht: name plus eines von review, aggregateRating oder offers. Auf einer Produktseite weglassen ist auf eigene Gefahr: Der CTR-Lift durch Sterne-Snippets ist real und messbar.

3. LocalBusiness

Jedes Unternehmen mit physischer Adresse. Treibt das Google Knowledge Panel, den Maps-Pack und die Öffnungszeitenanzeige. Pflicht: name und address. Empfohlen: telephone, openingHoursSpecification, geo, image, priceRange. Das wirkungsstärkste einzelne Schema für jedes Unternehmen mit Ladenlokal.

4. FAQPage

Frage-Antwort-Blöcke. Die Eligibility wurde 2023 verschärft. Google zeigt das FAQ-Rich-Result in den meisten Märkten inzwischen nur noch für autoritative Regierungs- und Gesundheitsseiten. Aber KI-Retriever zitieren FAQPage-Text nach wie vor direkt, wenn sie User-Queries beantworten. Die strikte Regel: Der Schema-Text von Frage und Antwort muss wortwörtlich mit dem sichtbaren HTML übereinstimmen. Drift kassiert das Rich Result.

5. BreadcrumbList

Hierarchische Navigation. Zeigt Breadcrumbs im SERP statt der rohen URL. Kleine visuelle Verbesserung, nicht verhandelbar auf Seiten mit tiefer Struktur (E-Commerce, große Content-Hubs). Pflicht: Ein itemListElement-Array mit position, name und item pro Eintrag.

6. Organization

Deine Marken-Identität. Logo, URL, Social Profile via sameAs, Firmenname, Gründungsdatum. Einmal auf der Homepage unter /#organization deklariert, überall sonst via @id referenziert. Das sameAs-Array ist, wie KI-Modelle deine Marke mit dem Wikidata-Eintrag und dem weiteren Entitäts-Graph verbinden.

7. Person

Die Autoren-Byline. Einmal auf /about/#founder oder ähnlich deklariert, auf jedem Artikel referenziert. Empfohlen: jobTitle, knowsAbout, sameAs zu LinkedIn, GitHub, Twitter. So entscheidet die KI, ob die Byline wirklich Expertise zum Thema hat.

8. Event

Alles mit einem Startdatum und einem Ort: Webinar, Konzert, Konferenz, Sale. Pflicht: name, startDate, location. Empfohlen: endDate, eventStatus, eventAttendanceMode (online / offline / mixed), offers für bezahlte Events.

Nischen-Typen, die sich trotzdem lohnen

• Recipe. Kochinhalte. Starke Rich-Result-Unterstützung mit Zubereitungszeit, Kalorien, Sternen.
• HowTo. Schritt-für-Schritt-Tutorials. Google hat das Rich Result im September 2023 eingestellt, aber Perplexity, Claude und ChatGPT lesen es weiter für die Extraktion der Schritte. Auf Tutorials drin lassen.
• VideoObject. Jede Seite, auf der ein Video der Hauptinhalt ist. Treibt das Video-Thumbnail in der Google-Suche.
• SoftwareApplication / WebApplication. Apps und Tools. Luminas Tool-Seiten nutzen WebApplication.
• Review / AggregateRating. Nutzerbewertungen für alles Bewertbare. Üblicherweise in Product oder LocalBusiness eingebettet statt standalone.
• Course. Google hat ein "Course info"-Rich-Result Ende 2023 dokumentiert, das bis heute unterstützt wird. Nicht deprecated, auch wenn manche älteren Guides das noch behaupten.
• JobPosting. Stellenausschreibungen. Treibt Google for Jobs.

Was du nicht shippen solltest: Schema-Typen, die nicht beschreiben, was deine Seite wirklich ist. Ein Dataset-Block auf einem Blogartikel, ein Vehicle-Block auf einer Homepage, ein MedicalCondition-Block auf einer Marketing-Seite. Irrelevante Typen fressen Bytes und provozieren, dass Google dein Markup als irreführend flaggt.

Wie du strukturierte Daten einbaust

Drei übliche Wege. Nimm den, der zu deinem Stack passt.

Plain HTML: einfügen und shippen

Wenn du das HTML direkt kontrollierst (statische Site, handcodierte Seite, Framework-Template), setze den JSON-LD-Block ans Ende des <head>. Ein Block pro Seite, ein @graph der alle Entitäten umschließt, separate Blöcke für FAQPage falls vorhanden:

<head>
  <!-- ...other head tags... -->
  <script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@graph": [
      {
        "@type": "BlogPosting",
        "@id": "https://your-site.com/blog/post/#article",
        "headline": "...",
        "author": { "@id": "https://your-site.com/#founder" },
        "publisher": { "@id": "https://your-site.com/#organization" },
        "datePublished": "2026-04-21",
        "dateModified": "2026-04-21"
      },
      {
        "@type": "Person",
        "@id": "https://your-site.com/#founder",
        "name": "Author Name",
        "jobTitle": "Title",
        "sameAs": ["https://www.linkedin.com/in/..."]
      },
      {
        "@type": "Organization",
        "@id": "https://your-site.com/#organization",
        "name": "Your Brand",
        "url": "https://your-site.com",
        "logo": "https://your-site.com/logo.png"
      }
    ]
  }
  </script>
</head>

Dieser eine Block deckt eine komplette Artikelseite ab. Person und Organization werden einmal deklariert, via @id auf jedem anderen Artikel referenziert. Keine Duplikate.

WordPress: Plugin oder Theme

Wenn du WordPress nutzt, ist Schema mit ziemlicher Sicherheit schon halb eingerichtet. Yoast SEO, Rank Math und The SEO Framework liefern alle Baseline-Schema für Article, Organization, WebSite und BreadcrumbList out of the box. Rank Math und Yoast shippen beide dedizierte FAQPage- und HowTo-Blöcke im Gutenberg-Editor.

Der Haken: Das Default-Schema der Plugins ist generisch. Organization.sameAs bleibt leer, bis du in den Plugin-Einstellungen die Social-URLs einträgst. Autoren-Bios shippen oft als nackte Person nur mit Name, kein jobTitle, kein sameAs. Der Fix ist die Schema-Settings-Seite im jeweiligen Plugin, nicht Custom-Code. Einmal pro Site setzen, überall erben.

Für komplexes Schema, das Plugins nicht abdecken (LocalBusiness mit mehreren Standorten, Produktvarianten mit ProductGroup, Event-Serien), nimmst du ein Custom-Fields-Plugin plus einen add_action('wp_head', ...)-Hook in einem Child-Theme und injizierst handgeschriebenes JSON-LD. Kämpf nicht gegen das Plugin; leg deinen Code daneben.

Next.js, React, Vue, Astro: Framework-Patterns

Jedes moderne Framework hat ein Primitive fürs Head-Injecting. Next.js: next/head oder die Metadata-API des App-Routers mit einem <Script> vom Typ application/ld+json. React mit React Helmet: <Helmet><script type="application/ld+json">{JSON.stringify(schema)}</script></Helmet>. Vue Nuxt: useHead-Composable mit einem script-Eintrag. Astro: plain <script>-Tag im Component-Head, wobei Astro den Framework-Overhead entfernt und das Markup als statisches HTML ausspielt.

Typischer Fehler über alle Frameworks hinweg: dangerouslySetInnerHTML mit einem JSON-String, der doppelt-stringified wurde, sodass escaped Quotes im Output landen und der Block ungültig wird. Immer ein normales Objekt genau einmal durch JSON.stringify() jagen, nie zweimal. Wenn im gerenderten HTML " auftaucht, hast du irgendwo doppelt encoded.

Helfen strukturierte Daten 2026 noch im SEO?

Direkte Antwort: Deine Blue-Link-Position bewegen sie nicht. Drei andere Dinge tun sie, die weiterhin zählen.

Rich Results. Qualifizierende Schema-Typen schalten angereicherte SERP-Blöcke frei: Sterne bei Produkten, Preise bei Offers, FAQ-Akkordeons auf Regierungs- und Gesundheitsseiten, Rezeptkarten mit Zubereitungszeit und Kalorien, Breadcrumb-Pfade statt roher URL, Video-Thumbnails für VideoObject. Die CTR auf Rich-Result-Listings liegt über jeder Third-Party-Studie, die ich gesehen habe (Ahrefs, SISTRIX, Backlinko, Rockdove unter anderem), messbar über einfachen Blue Links derselben Position. Der genaue Lift variiert je nach Rich-Result-Typ und Branche, die Richtung ist konsistent.

KI-Zitierung. ChatGPT, Claude, Perplexity und Gemini parsen alle JSON-LD, wenn sie Seiten einlesen. Je klarer dein Entitäts-Graph, desto wahrscheinlicher wird deine Marke in KI-Antworten namentlich zitiert statt anonym zusammengefasst. Eine öffentliche Studie, die das quantifiziert, gibt es noch nicht. KI-Referral-Traffic in GA4 ist für die meisten Sites noch ein einstelliger Prozentsatz, aber was zählt, ist die Trendlinie, nicht der aktuelle Monat. In Luminas eigenem GEO Readiness Checker machen Schema-Signale rund 35% des 42-Check-Audit-Scores aus: JSON-LD-Präsenz (Gewicht 10), Organization-Schema (8), absolutes @id (5), WebSite-Schema (3), Person-Schema (3), sameAs-Array (3), FAQPage (3).

Knowledge Graph. Organization- und Person-Schema mit einem starken sameAs-Array (LinkedIn, Wikidata, GitHub, Crunchbase, Twitter, Branchenverzeichnisse) ist, wie Google deine Marke mit einer Knowledge-Graph-Entität verknüpft. Sobald du eine Entität hast, bekommst du das Blue-Check-Brand-Panel im SERP, dein Logo erscheint in Answer-Cards, dein Name wird ohne Rückfrage aufgelöst.

Was Schema nicht macht: Es fixt keinen dünnen Content, keine kaputten internen Links, keine langsamen Seiten, keine nicht-crawlbare Site. Wenn die Grundlage schwach ist, rettet kein JSON-LD-Block sie.

Abgekündigte & gesunsete Schema-Typen

Google hat eine Handvoll Schema-Typen still abgekündigt. Guides aus 2022 listen sie noch als aktuell. Luminas Schema Validator führt sieben davon in der DEPRECATED_TYPES-Liste, plus ClaimReview als Sonderfall. Vier Kategorien decken jeden Zustand ab, in dem ein Schema-Typ sein kann:

Aktiv und voll unterstützt. Die großen acht von oben (Article, Product, LocalBusiness, FAQPage, BreadcrumbList, Organization, Person, Event) plus Recipe, VideoObject, Review, AggregateRating, Course, JobPosting, QAPage, DiscussionForumPosting, ProfilePage, MathSolver, ProductGroup. Alle qualifizieren für aktuelle Rich Results. Weiterhin shippen.

Aktiv aber mit Eligibility-Einschränkungen. Das FAQPage-Rich-Result ist in den meisten Märkten inzwischen auf autoritative Regierungs- und Gesundheitsseiten beschränkt. Das Schema bleibt für jede Site gültig; das SERP-Akkordeon taucht für die meisten nur einfach nicht mehr auf. Das HowTo-Rich-Result wurde von Google am 14. September 2023 eingestellt; das Schema bleibt gültig und Perplexity, Claude und ChatGPT lesen es weiter für die Schritt-Extraktion. ClaimReview wird aus der Google-Suchanzeige ausgephast, bleibt aber von Googles Fact Check Explorer Tool unterstützt.

Vollständig aus Google Search verschwunden. Die exakte Liste in Luminas Schema Validator Stand 2026-04-21: HowTo, EducationalOccupationalCredential, Vehicle, PracticeProblems, SpecialAnnouncement, EstimatedSalary, LearningVideo. Alle sieben sind gültiges schema.org-Markup, manche helfen KI-Retrievern noch beim Entity-Verständnis, aber keiner triggert noch ein dediziertes Google-Rich-Result. Wenn dein CMS noch SpecialAnnouncement-Blöcke aus der COVID-Ära shipped, beim nächsten Touch rausräumen.

Oft fälschlich als deprecated einsortiert. Zwei stolpert man über. Course ist der große. Google hat ein "Course info"-Rich-Result Ende 2023 dokumentiert, das bis heute unterstützt wird, und Coursera, edX und MIT OpenCourseWare ranken damit aktuell. Manche Guides aus 2022 listen es noch als deprecated; falsch. QAPage ist der andere: Das Rich Result ist kleiner als früher, aber der Typ wird weiter unterstützt (ich hatte ihn fälschlich in der DEPRECATED_TYPES-Liste meines eigenen Schema Validators, bis ein externes URL-Audit es am 2026-04-12 aufgedeckt hat). Wenn ein Validator einen der beiden 2026 als deprecated flaggt, ist der Validator veraltet.

Die häufigsten Schema-Fehler

Ich habe über hundert Kunden-Sites auditiert und Luminas Schema Validator gegen 72 interne und 21 externe Seiten getestet, quer durch Rezepte, News, Shopping, Tutorials, Reviews und Referenz-Content. Fünf Muster erzeugen die meisten Production-Fehler.

1. FAQ-Drift. Das Schema deklariert fünf Fragen; das sichtbare HTML hat sechs. Oder der acceptedAnswer.text des Schemas ist eine Zusammenfassung der sichtbaren Antwort statt des exakten Texts. Google zieht die FAQ-Rich-Result-Eligibility bei sowas zurück. Ihr Validator erzwingt wortwörtlichen Textabgleich. Ein einziges editiertes Wort im HTML ohne parallelen Edit im Schema reicht, um das zu brechen. Der Fix ist Prozess, nicht Code: Strict-Sync von Schema und HTML im selben Commit, Verify-Script vor jedem Deploy.

2. Waisen-Person oder -Organization. Du deklarierst einen Person-Block mit Autoren-Metadaten, verlinkst ihn aber nie via @id aus Article.author. Oder der Article.author ist inline als {"@type":"Person","name":"Autor"}, während ein separater Person-Block mit dem echten sameAs-Array unverbunden auf derselben Seite hängt. KI-Retriever behandeln die Inline-Byline und den Waisen-Block als zwei verschiedene Personen. Entity-Signal fragmentiert. Der Fix: Eine kanonische Person-Deklaration, via @id von jedem Artikel referenziert.

3. Veraltetes dateModified. Zwei Spiegelbild-Bugs. Version A: Der Content ändert sich, dateModified nicht. KI-Retriever und Google nutzen dateModified beide als Freshness-Signal und vergleichen es mit dem tatsächlichen Edit-Zeitpunkt aus ihrer Crawl-History. Ein Schema das "modified 2023" sagt auf einer Seite, die sichtbar 2026 rewritten wurde, ist ein Mismatch. Version B, genauso schlimm: dateModified bumped bei jedem Touch. CSS-only-Änderungen, Typo-Fixes in HTML-Kommentaren, Nav-Menu-Updates. Google lernt, dass dein Freshness-Signal unzuverlässig ist, und ignoriert es ganz. Fix: dateModified nur bei echten Content-Änderungen bumpen.

4. Erfundene Felder. applicationArea existiert nicht auf schema.org. targetAudience auf Article auch nicht. coverImage auch nicht. Erfundene Felder werfen in den meisten Validatoren keinen Fehler (sie ignorieren unbekannte Properties still), aber Googles Rich Results Test flaggt sie und strikte KI-Parser-Pipelines werten den ganzen Block ab. Nur auf schema.org-dokumentierte Felder setzen. Im Zweifel: Vokabular-Seite des jeweiligen Typs aufschlagen.

5. Schema-Breite ohne Schema-Relevanz. Du shippst 14 Schema-Typen auf einem Blogartikel. Article, BlogPosting, WebPage, WebSite, Organization, Person, ImageObject, BreadcrumbList, ListItem, PropertyValue, DefinedTerm, ReadAction, EntryPoint, SearchAction. Die Hälfte davon beschreibt nicht, was die Seite ist. Es sind Absicherungen. Einen DefinedTerm-Block anzuhängen, wenn die Seite keinen Begriff definiert, signalisiert Google, dass dein Markup Padding ist, nicht Beschreibung. Ship 3-5 gut verknüpfte Entitäten, nicht 14 Drive-by-Blöcke.

Wie du strukturierte Daten validierst

Drei Tools, drei unterschiedliche Jobs. Jeder Schema-Commit sollte durch alle drei durch, weil sie unterschiedliche Fehlerklassen fangen.

• Google Rich Results Test. Die Google-spezifische Source of Truth. Nimmt eine URL oder ein Code-Snippet, meldet, für welche Rich-Result-Typen du qualifizierst, und flaggt fehlende Pflichtfelder. Das ist, was Googles Crawler tatsächlich sieht. Auf jeden Production-Commit der Schema anfasst anwenden.
• Schema.org Validator. Die Vokabular-Source-of-Truth. Meldet Syntaxfehler, ungültige Felder und mehrdeutige Typ-Referenzen gegen das volle 823-Typen-Vokabular. Fängt "erfundene Felder" schneller als der Google-Tester.
• Lumina Schema Validator. Kostenlos, kein Signup, Bulk-Mode, und drei Checks die die anderen nicht fahren. Aufschlüsselung gleich.

Luminas Schema Validator existiert, weil die anderen zwei drei Production-Fehlerklassen verpassen, die mir in Kunden-Audits immer wieder begegnet sind:

• FAQPage-Strict-Sync gegen sichtbares HTML. Der Validator extrahiert sowohl das JSON-LD als auch jedes sichtbare .faq-item auf der Seite und vergleicht sie Frage für Frage, Antwort für Antwort. Googles Tester lässt Schema durch, das nicht mit dem sichtbaren Text übereinstimmt; Google Search widerruft das Rich Result dann Wochen später still. Luminas Tool fängt den Mismatch vor dem Deploy.
• Cross-Page-@id-Auflösung. Wenn der author deines Artikels {"@id":"https://deine-site.com/#founder"} ist (das kanonische Muster), folgt der Validator dieser Referenz zur tatsächlichen Deklaration auf deiner Homepage oder About-Seite und validiert die aufgelöste Person-Entität. Googles Tester validiert jede Seite isoliert und verpasst das komplett.
• Aktueller Deprecation-Katalog. Gebaut aus Googles aktuellen Structured-Data-Docs, nicht aus generischer schema.org-Theorie. Flaggt HowTo als gesunset, ClaimReview als ausphasend, warnt vor erfundenen Feldern wie applicationArea. Flaggt Course oder QAPage nicht fälschlich als deprecated (das habe ich in meinem eigenen Schema-Validator-Sweep am 2026-04-12 gefixt).

Der Workflow: Beim Schreiben des Blocks mit Schema.org validieren, vor dem Ship mit Google Rich Results Test spotchecken, nach dem Deploy Luminas Schema Validator auf die Live-URL jagen. Bulk-Audits über eine ganze Site laufen immer über Luminas Tool, weil keins der anderen Batches unterstützt.

FAQ

Wo du anfängst

Fünf Schritte in dieser Reihenfolge. Unter 90 Minuten Arbeit für eine kleine Site, zwei bis drei Stunden für eine mittlere: