Ich habe kürzlich eine WordPress-Website mit über 3.000 Beiträgen überprüft. Der Kunde wollte seinen Content in ein KI-Tool einspeisen, um Zusammenfassungen zu generieren und eine Empfehlungs-Engine anzutreiben. Sollte unkompliziert sein, richtig? Content exportieren, weiterleiten, fertig.

Nur war es das nicht. Jeder einzelne Beitrag war ein verworrenes Durcheinander von HTML -- Shortcodes von Plugins, die es nicht mehr gab, Inline-Styles aus dem Classic Editor, Gutenberg-Block-Kommentare, die wie Landminen verstreut waren, und kodierte Entities, die Parser zum Ersticken brachten. Das Feld "Content" in der Datenbank war überhaupt kein Content. Es war ein Rendering-Anweisungssatz, den nur WordPress selbst interpretieren konnte. Das KI-Modell produzierte Müll. Der Kunde war wütend. Und ich musste etwas erklären, das mehr Teams hören müssen: Die Art, wie Sie Ihren Content speichern, bestimmt, was Sie damit tun können -- nicht nur heute, sondern für jeden Use Case, den Sie sich noch nicht überlegt haben.

Das ist die Geschichte von strukturiertem Content vs. HTML-Blobs, warum es 2025 wichtiger ist als je zuvor, und wie der Migrationspfad tatsächlich aussieht.

Inhaltsverzeichnis

Was sind HTML-Blobs und warum nutzt WordPress sie

Öffnen Sie phpMyAdmin auf einer beliebigen WordPress-Website und schauen Sie sich die Tabelle wp_posts an. Suchen Sie die Spalte post_content. Was Sie sehen werden, ist ein einzelnes Textfeld, das alles enthält -- Überschriften, Absätze, Bilder, Einbettungen, Shortcodes, Block-Markup, Inline-CSS -- alles in einen langen String gequetscht.

So sieht ein typischer Gutenberg-Beitrag in der Datenbank aus:

<!-- wp:heading {"level":2} -->
<h2 class="wp-block-heading">Unsere Dienstleistungen</h2>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>Wir bieten <strong>Premium-Beratung</strong> für Unternehmen an.</p>
<!-- /wp:paragraph -->

<!-- wp:shortcode -->
[contact-form-7 id="1234" title="Kontakt"]
<!-- /wp:shortcode -->

<!-- wp:image {"id":5678,"sizeSlug":"large"} -->
<figure class="wp-block-image size-large">
<img src="/wp-content/uploads/2024/03/hero.jpg" alt="" class="wp-image-5678"/>
</figure>
<!-- /wp:image -->

Das ist ein HTML-Blob. Es ist Präsentation und Content vermischt. Die Datenbank weiß nicht, dass "Unsere Dienstleistungen" eine Überschrift ist, dass das Bild ein Hero-Image ist, oder dass das Kontaktformular eine CTA-Komponente ist. Es ist einfach ... Text in einem Feld.

WordPress macht das, weil es 2003 als Blogging-Plattform entwickelt wurde. Das mentale Modell war einfach: Ein Beitrag hat einen Titel und einen Body. Der Body ist HTML. Sie schreiben es, WordPress rendert es. Dieses Modell funktionierte wunderbar für Blogs. Es bricht katastrophal zusammen bei modernen Content-Operationen.

Die Gutenberg-Verbesserung, die gar keine war

Gutenberg (der Block-Editor) sollte das beheben. Und ehrlich gesagt, es hat etwas Struktur hinzugefügt -- diese HTML-Kommentare kodieren Block-Typen und Attribute als JSON. Aber hier ist das kritische Versagen: Diese Struktur lebt innerhalb des HTML-Blobs selbst. Sie ist nicht abfragbar. Sie ist nicht typisiert. Sie ist nicht validiert. Sie können nicht die Datenbank fragen "Gib mir alle Beiträge, wo das Hero-Image X ist" oder "Finde jeden Beitrag, der einen Pricing-Table-Block enthält."

Die Block-Daten sind im Grunde Metadaten, die als Kommentare innerhalb eines Textfeldes kodiert sind. Das ist keine Struktur. Das ist ein Hack.

Was strukturierter Content wirklich bedeutet

Strukturierter Content trennt was etwas ist von wie es aussieht. Statt einen HTML-Blob zu speichern, definieren Sie ein Content-Modell mit diskreten, typisierten Feldern.

Hier ist derselbe Content als strukturierte Daten in einem Headless CMS wie Sanity:

{
  "_type": "servicePage",
  "title": "Unsere Dienstleistungen",
  "heroImage": {
    "_type": "image",
    "asset": { "_ref": "image-abc123" },
    "alt": "Team arbeitet an einem Projekt zusammen"
  },
  "sections": [
    {
      "_type": "textBlock",
      "heading": "Premium-Beratung",
      "body": [
        {
          "_type": "block",
          "children": [
            { "_type": "span", "text": "Wir bieten " },
            { "_type": "span", "text": "Premium-Beratung", "marks": ["strong"] },
            { "_type": "span", "text": " für Unternehmen an." }
          ]
        }
      ]
    },
    {
      "_type": "ctaForm",
      "formType": "contact",
      "placement": "inline"
    }
  ]
}

Bemerken Sie den Unterschied. Jedes Content-Element hat einen Typ. Das Bild hat expliziten Alt-Text als erforderliches Feld. Rich Text wird als portables Format gespeichert -- nicht HTML -- das in jeden Output gerendert werden kann. Das CTA-Formular ist eine typisierte Referenz, kein Shortcode-String, der bricht, wenn Sie ein Plugin deaktivieren.

Das ist das, was Headless-CMS-Plattformen wie Sanity, Contentful, Storyblok und Strapi bieten. Und das ist der Grund, warum sie existieren.

Der Portable-Text-Vorteil

Sanitys Portable-Text-Format (und ähnliche Ansätze in anderen Headless-CMSs) speichert Rich Text als ein Array von typisierten Objekten. Das bedeutet, dass Sie es können:

  • Als HTML für das Web rendern
  • Als Markdown für Dokumentation rendern
  • Als Klartext für KI-Verarbeitung rendern
  • Als JSX für React-Komponenten rendern
  • Als SSML für Voice Assistants rendern

Ein HTML-Blob gibt Ihnen ein Output-Format: HTML. Und nicht mal sauberes HTML -- WordPress-geschmacktes HTML mit all seinen Eigenheiten.

Warum KI Ihren WordPress-Content nicht lesen kann

Das ist der Teil, der 2025 dringend wird. KI-gestützte Tools -- von ChatGPT und Claude bis zu Googles AI Overviews und internen RAG-Systemen (Retrieval-Augmented Generation) -- alle müssen Ihren Content semantisch verstehen. Sie müssen wissen, was Dinge sind, nicht nur wie sie im Browser aussehen.

Das Parsing-Problem

Wenn Sie versuchen, sinnvolle Inhalte aus einem WordPress-HTML-Blob zu extrahieren, treffen Sie sofort auf diese Probleme:

  1. Shortcodes werden außerhalb von WordPress zu nichts. [gallery ids="1,2,3"] ist bedeutungslos ohne die PHP-Funktion, die es expandiert.
  2. Block-Kommentare sind nicht standard. <!-- wp:columns --> ist kein Web-Standard. KI-Parser wissen nicht, was sie damit anfangen sollen.
  3. Inline-Styles und Klassen haben keine semantische Bedeutung. Ein <div class="wp-block-group has-background"> sagt Ihnen nichts über den Zweck des Contents.
  4. Verschachtelte HTML-Strukturen sind mehrdeutig. Ist dieses verschachtelte Div eine Seitenleiste? Ein Callout? Ein Layout-Container? Es gibt keine Möglichkeit, das programmatisch zu wissen.
  5. Plugin-generiertes Markup ist unvorhersehbar. Jedes Plugin injiziert seine eigenen HTML-Muster, oft konfliktreich mit anderen.

Was das für AI Overviews und LLMs bedeutet

Googles AI Overviews (die KI-generierten Zusammenfassungen am Anfang der Suchergebnisse) pulen Content von Seiten, die einfach zu parsen und zu verstehen sind. Laut Recherche von Authoritas Anfang 2025 werden Seiten mit klaren Content-Hierarchien und Schema-Markup 2-3x häufiger in AI Overviews zitiert als Seiten mit äquivalenter Content-Qualität aber schlechter Struktur.

LLMs verarbeiten Ihren Content besser, wenn er sauber ist. Punkt. Wenn Ihr Content in Markup-Suppe begraben ist, sinkt das Signal-zu-Rausch-Verhältnis. Das Modell muss raten, was Content und was Dekoration ist. Manchmal rät es falsch.

RAG-Systeme und interne KI-Tools

Viele Unternehmen 2025 bauen interne KI-Tools, die ihren eigenen Content aufnehmen müssen -- Knowledge Bases, Produktdokumentation, Marketing-Copy. Wenn dieser Content in WordPress lebt, sieht die Extraction-Pipeline so aus:

  1. WordPress REST API oder Datenbank abfragen
  2. HTML-Blobs zurück bekommen
  3. HTML-Tags entfernen (alle Struktur verlieren)
  4. Oder HTML parsen (Rauschen mit Signal vermischt)
  5. Text für Embeddings chunken
  6. Hoffen, dass es gut geht

Mit strukturiertem Content von einem Headless CMS ist es:

  1. API abfragen
  2. Typisiertes, strukturiertes JSON zurück bekommen
  3. Genau die Felder auswählen, die Sie brauchen
  4. Sauber nach Content-Typ chunken
  5. Hochwertige Embeddings generieren

Der Unterschied in der Output-Qualität ist dramatisch. Ich habe RAG-Genauigkeit um 30-40% verbessert, nur durch den Wechsel von HTML-extrahiertem Content zu strukturiertem Content als Quelle.

Die echten Kosten unstrukturierten Contents

Lassen Sie uns über die Kosten sprechen, die auf keiner Rechnung auftauchen, aber Ihr Budget über Zeit absolut zerstören.

Kostenfaktor WordPress HTML-Blobs Strukturierter Content (Headless CMS)
Content-Wiederverwendung über Kanäle Manuelles Kopieren, Umformatierung API-gesteuert, automatisch
KI/ML Content-Verarbeitung Erfordert Parsing-Pipeline, fehleranfällig Direkte JSON-Konsumption
Redesign-/Umplattformungs-Aufwand Content an Theme gebunden, hoher Aufwand Content entkoppelt, Frontends frei austauschbar
Multi-Sprachen-Unterstützung Plugin-abhängig, fragil Integriert, Feld-Level-Lokalisierung
Content-Governance Limitierte Feld-Validierung Schema-durchgesetzte Content-Typen
Mobile-App-Content REST API gibt HTML-Strings zurück Sauberes JSON, nativ-ready
Developer-Onboarding-Zeit Theme + Plugin-Ökosystem Lernkurve API-Docs + Content-Schema
Content-Migration zur neuen Plattform Schmerzhaftes HTML-Parsing Strukturiertes JSON exportieren

Jede Reihe in dieser Tabelle repräsentiert echte Stunden und echtes Geld. Ich habe an WordPress-to-Headless-Migrationen gearbeitet, bei denen 60% des Projektbudgets zur Content-Transformation ging -- nicht weil das neue System schwierig war, sondern weil das Extrahieren von Bedeutung aus den alten HTML-Blobs qualvoll war.

Headless CMS vs WordPress: Ein ehrlicher Vergleich

Ich werde so tun, als wäre WordPress bei allem schlecht. Das ist nicht so. Lassen Sie uns ehrlich darüber sprechen, was jeder Ansatz gut macht.

Wo WordPress noch gewinnt

  • Ökosystem-Größe. 60.000+ Plugins. Es gibt ein Plugin für alles. Die Qualität variiert stark, aber der Umfang ist unvergleichlich.
  • Vertrautheit von nicht-technischen Editoren. Die meisten Content-Editoren haben WordPress benutzt. Die Lernkurve für grundlegende Aufgaben ist praktisch null.
  • All-in-One-Einfachheit. Für eine einfache Broschüren-Website oder einen Blog bringt Sie WordPress von Null zu veröffentlicht schneller als alles andere.
  • Kostenlos Eintritt. Shared Hosting für 5 $/Monat, ein kostenloses Theme, und Sie sind live.

Wo Headless CMS gewinnt

  • Content-Struktur und -Modellierung. Das ist der ganze Punkt dieses Artikels. Headless CMSs lassen Sie genau definieren, wie Ihr Content als Daten aussieht.
  • API-first-Lieferung. Content geht zu Websites, Apps, Kiosken, Voice Assistants -- überall, wo ein HTTP-Request gemacht werden kann.
  • Leistung. In Kombination mit einem Framework wie Next.js oder Astro bekommen Sie statische Generierung, Edge-Caching und Sub-Sekunden-Ladezeiten.
  • Sicherheit. Keine PHP-Ausführung im Frontend. Kein wp-login.php zum Brute-Force. Die Angriffsfläche schrumpft dramatisch.
  • KI-Bereitschaft. Strukturierter Content ist nativ konsumierbar durch KI-Tools, Suchmaschinen und Automations-Pipelines.
  • Developer Experience. Modernes Tooling, TypeScript-Unterstützung, Echtzeit-Zusammenarbeit, Versionskontrolle auf Content.

Die Nuance, die die meisten Artikel übersehen

WordPress kann über WPGraphQL oder die REST API als Headless CMS verwendet werden. Einige Teams machen das. Aber Sie speichern immer noch HTML-Blobs -- Sie servieren sie einfach über eine API statt sie mit PHP zu rendern. Das Grundproblem hat sich nicht geändert. Ihr Content ist immer noch unstrukturiert.

WordPress mit ACF (Advanced Custom Fields) kommt strukturiertem Content näher. Sie können typisierte und abfragbare benutzerdefinierte Felder erstellen. Aber ACF ist ein Plugin, das auf ein System aufgeklebt ist, das nicht dafür entworfen wurde. Die Content-Modellierungs-UX ist umständlich, die Leistung verschlechtert sich mit komplexen Feldgruppen, und Sie sind immer noch abhängig vom WordPress-Ökosystem für Hosting, Updates und Sicherheit.

WordPress-Einschränkungen, die sich mit der Zeit verschärfen

Das sind keine theoretischen Probleme. Es sind Dinge, die ich auf echten Projekten kaputt gehen sah.

Plugin-Abhängigkeitshölle

Eine typische WordPress-Website verwendet 20-40 Plugins. Jeder kann mit anderen in Konflikt geraten. Jeder muss aktualisiert werden. Jeder ist eine potenzielle Sicherheitslücke. Wenn ein Plugin aufgegeben wird (was ständig passiert), sind Sie mit Shortcodes in Ihrem Content festgefahren, der als Literal-Text rendert.

Ich überprüfte letzte Jahr eine Website mit [tabs] Shortcodes in 800 Beiträgen. Das Tabs-Plugin war seit 2021 nicht aktualisiert worden. Der Content war durch toten Code als Geisel genommen.

Die monolithische Architektur-Steuer

WordPress handhabt Routing, Rendering, Content-Speicherung, Authentifizierung, Medienverwaltung und Plugin-Ausführung in einem einzelnen PHP-Prozess. Das bedeutet:

  • Sie können die Content-API nicht unabhängig von der Admin-Schnittstelle skalieren
  • Ein Spitzenwert im Traffic trifft denselben Server, der Editor-Sitzungen handhabt
  • Datenbankabfragen für Content-Abruf konkurrieren mit Plugin-Operationen
  • Sie können Frontend-Änderungen nicht bereitstellen ohne den WordPress-Server zu berühren

Moderne Headless-CMS-Architekturen trennen diese Bedenken vollständig. Die Content-API skaliert unabhängig. Das Frontend wird auf Edge-Netzwerke bereitgestellt. Editoren arbeiten in einem dedizierten Studio, das keine Ressourcen mit öffentlichem Traffic teilt.

Content-Lock-In, über das niemand spricht

Hier ist das schmutzige Geheimnis: WordPress-Content ist theoretisch portierbar, aber praktisch gesperrt. Sicher, Sie können XML exportieren. Aber dieses XML enthält HTML-Blobs mit Shortcodes, Plugin-spezifischem Markup und WordPress-internen Referenzen. Der Wechsel zu einem anderen System erfordert eine Parsing- und Transformations-Anstrengung, die linear mit Content-Volumen und Komplexität skaliert.

Strukturierter Content in einem Headless CMS wird als JSON exportiert. Sauberes, typisiertes, vorhersehbares JSON. Der Wechsel von Sanity zu Contentful (oder umgekehrt) erfordert das Mapping von Content-Typen, nicht das Parsing von HTML.

Der Migrationspfad: Von Blobs zur Struktur

Wenn Sie auf einer WordPress-Website sitzen und dieser Artikel macht Sie unbequem, gut. Lassen Sie uns darüber sprechen, was zu tun ist.

Schritt 1: Überprüfen Sie Ihren Content

Bevor Sie etwas berühren, verstehen Sie, was Sie haben. Führen Sie Abfragen gegen Ihre Datenbank:

-- Finde alle Shortcodes in Gebrauch
SELECT DISTINCT
  REGEXP_SUBSTR(post_content, '\\[[a-zA-Z_-]+') AS shortcode,
  COUNT(*) AS usage_count
FROM wp_posts
WHERE post_status = 'publish'
  AND post_content REGEXP '\\[[a-zA-Z]'
GROUP BY shortcode
ORDER BY usage_count DESC;

Dokumentieren Sie jeden Shortcode, jeden benutzerdefinierten Block, jeden ACF-Feldgruppe. Diese Inventur steuert Ihre Content-Modell-Design.

Schritt 2: Designen Sie Ihr Content-Modell zuerst

Wählen Sie nicht ein CMS und erarbeiten Sie dann Ihr Modell. Designen Sie das Modell basierend auf Ihren Content-Bedürfnissen, wählen Sie dann das CMS, das es am besten unterstützt.

Stellen Sie diese Fragen:

  • Was sind die unterschiedlichen Content-Typen? (Blog-Beitrag, Fallstudie, Produktseite, Teammitglied...)
  • Welche Felder braucht jeder Typ?
  • Was sind die Beziehungen zwischen Typen?
  • Wer muss was bearbeiten?
  • Wo muss dieser Content erscheinen? (Web, App, Email, KI-Tools...)

Schritt 3: Bauen Sie die Transformations-Pipeline

Hier passiert die echte Arbeit. Sie müssen HTML-Blobs in strukturierte Daten umwandeln. Tools, die helfen:

  • Benutzerdefinierte Node.js-Skripte mit cheerio oder unified/rehype für HTML-Parsing
  • Sanitys Migrations-Tools für Import strukturierter Contents
  • Contentfuls Migrations-CLI für programmatische Content-Erstellung
  • OpenAI oder Claude APIs für KI-unterstützte Content-Klassifikation (ernsthaft -- verwenden Sie KI, um Ihren Content während der Migration zu taggen und zu kategorisieren)
// Beispiel: Konvertieren von WordPress HTML zu Portable Text
import { htmlToBlocks } from '@sanity/block-tools'
import { Schema } from '@sanity/schema'

const defaultSchema = Schema.compile({ /* Ihr Schema */ })
const blockContentType = defaultSchema
  .get('post')
  .fields.find(field => field.name === 'body').type

const blocks = htmlToBlocks(
  '<p>Ihr <strong>WordPress</strong> HTML hier</p>',
  blockContentType
)

Schritt 4: Laufen Sie parallel

Machen Sie keine Big-Bang-Migration. Führen Sie WordPress und Ihr neues Headless CMS parallel aus. Migrieren Sie Content in Chargen. Validieren Sie jede Charge. Bauen Sie das neue Frontend gegen die Headless-CMS-API, während die alte Website live bleibt.

Das ist der Ansatz, den wir bei unseren Headless-CMS-Projekten nehmen. Es ist zu Beginn mehr Arbeit, reduziert aber das Risiko dramatisch.

Schritt 5: Umleiten und Außerbetrieb nehmen

Sobald die neue Website live und validiert ist, richten Sie 301-Umleitungen ein, überwachen Sie auf 404s, und fahren Sie WordPress herunter. Behalten Sie ein Datenbank-Backup für immer -- Sie wissen nie, wann Sie alte Inhalte referenzieren müssen.

Das richtige Headless CMS auswählen

Der Markt hat sich erheblich reife. Hier ist, wie die Hauptakteure 2025 gestapelt sind:

CMS Content-Modellierung Preis (Anfang) Beste für KI-Features
Sanity Ausgezeichnet -- Code-definierte Schemas Kostenlos, dann 99 $/Mo (Growth) Benutzerdefinierte Content-Modelle, Developer-Teams Sanity AI Assist integriert
Contentful Stark -- UI-basierte Modellierung Kostenlos, dann 300 $/Mo (Team) Enterprise Content-Operationen KI Content-Generierung Add-on
Storyblok Gut -- Visuell-Bearbeitungs-Fokus Kostenlos, dann €106/Mo (Business) Marketing-Teams brauchen visuelle Vorschau KI-getriebene Content-Erstellung
Strapi Gut -- Self-Hosted-Flexibilität Kostenlos (Self-Hosted), Cloud ab 29 $/Mo Teams brauchen volle Kontrolle Erweiterbar via Plugins
Payload CMS Ausgezeichnet -- Code-first, TypeScript-native Kostenlos (Self-Hosted), Cloud kommt 2025 Developer-schwere Teams, Next.js-Projekte Erweiterbar via Plugins

Es gibt keine universelle beste Wahl. Es hängt von Ihrem Team, Ihrer Content-Komplexität und Ihrem Budget ab. Wenn Sie Hilfe beim Evaluieren von Optionen möchten, wir haben diese Analyse für Dutzende von Teams gemacht.

FAQ

Was ist strukturierter Content und warum ist es für SEO wichtig?

Strukturierter Content speichert Informationen als typisierte, beschriftete Datenfelder statt Roh-HTML. Für SEO ist das wichtig, weil Suchmaschinen -- besonders Googles KI-gestützte Systeme -- strukturierten Content genauer verstehen und zitieren können. Seiten, die aus strukturiertem Content gebaut sind, haben tendenziell sauberes HTML-Output, richtige Überschriften-Hierarchien und konsistenteres Schema-Markup, all das sind Ranking-Signale 2025.

Kann WordPress als Headless CMS verwendet werden?

Technisch ja. WordPress hat eine REST API und kann mit WPGraphQL erweitert werden. Aber das Kernproblem bleibt: Ihr Content ist immer noch als HTML-Blobs in der Datenbank gespeichert. WordPress headless verwenden gibt Ihnen API-Zugang zu unstrukturiertem Content. Sie bekommen die Headless-Architektur-Vorteile (Frontend-Flexibilität, bessere Leistung) ohne die strukturierten-Content-Vorteile. Für einige Teams ist das ein akzeptabler Tradeoff. Für die meisten nicht.

Wie viel kostet es, von WordPress zu einem Headless CMS zu migrieren?

Es variiert enorm basierend auf Content-Volumen und Komplexität. Eine kleine Website mit 50-100 Seiten sauberen Contents könnte 2-4 Wochen Entwicklungs-Aufwand nehmen. Eine große Website mit Tausenden von Beiträgen, benutzerdefinierten Post-Typen, ACF-Feldern und Shortcode-schwererem Content kann 2-4 Monate nehmen. Die Content-Transformations-Arbeit -- Konvertieren von HTML-Blobs zu strukturierten Daten -- ist typischerweise 40-60% des Gesamt-Aufwands. Schauen Sie unsere Preisseite für Ballpark-Schätzungen bei Headless-CMS-Projekten.

Werden AI Overviews meine WordPress-Website niedriger ranken?

Nicht direkt -- Google bestraft WordPress-Sites nicht. Aber AI Overviews und ähnliche Features bevorzugen Content, der einfach zu parsen und zu verstehen ist. Sites mit saubererem, wohlstrukturiertem HTML (was strukturierter Content natürlich produziert) werden tendenziell häufiger zitiert. Eine messy WordPress-Seite mit Plugin-generiertem Markup, Inline-Styles und kaputten Shortcodes ist für jedes KI-System schwieriger zuverlässig zu verarbeiten.

Was passiert mit meinem WordPress-Content, wenn ich ein Plugin deaktiviere?

Alle Shortcodes aus diesem Plugin werden als Literal-Text in Ihren Beiträgen gerendert. Zum Beispiel, wenn Sie ein Gallery-Plugin deaktivieren, werden Ihre Besucher [gallery ids="1,2,3"] als Klartext auf der Seite sehen. Block-basierte Plugins können hinter sich kaputtes HTML oder leere Container lassen. Das ist eines der häufigsten -- und frustrierendsten -- WordPress-Content-Probleme. Strukturierter Content in einem Headless CMS hat dieses Problem nicht, weil Content und Präsentation vollständig getrennt sind.

Ist Gutenberg (der WordPress-Block-Editor) strukturierter Content?

Es ist ein Schritt Richtung Struktur, aber es fällt kurz. Gutenberg-Blöcke kodieren Typinformationen in HTML-Kommentaren innerhalb des post_content-Blobs. Diese Metadaten sind nicht in separaten Datenbankfeldern gespeichert, sind nicht über SQL abfragbar, und sind nicht gegen ein Schema validiert. Es ist strukturierter als der klassische Editor, aber grundsätzlich unterschiedlich von echtem strukturiertem Content wie in Headless CMSs wie Sanity oder Contentful implementiert.

Welches Headless CMS ist am besten für Next.js-Projekte?

Sanity und Payload CMS sind die stärksten Optionen für Next.js-Entwicklung 2025. Sanity bietet ausgezeichnete Echtzeit-Vorschau-Fähigkeiten und ein reifes Ökosystem. Payload CMS ist besonders interessant, weil es TypeScript-native ist und innerhalb einer Next.js-Anwendung selbst laufen kann. Contentful und Storyblok haben auch solide Next.js-Integrationen. Die "beste" Wahl hängt davon ab, ob Sie Content-Modellierungs-Flexibilität, visuelle Bearbeitung, Self-Hosting oder Enterprise-Features priorisieren.

Wie mache ich meinen Content KI-ready ohne volle Migration?

Wenn eine volle Migration gerade nicht machbar ist, können Sie inkrementelle Schritte unternehmen. Fügen Sie JSON-LD strukturierte Daten zu Ihren WordPress-Seiten mit einem Plugin wie Yoast oder RankMath. Bereinigen Sie Shortcode-Verwendung -- ersetzen Sie sie mit nativen Gutenberg-Blöcken, wo möglich. Erstellen Sie eine Content-API-Schicht mit ACF und WPGraphQL, die Schlüsselfelder als strukturierte Daten exposiert. Diese Schritte geben Ihnen keinen echten strukturierten Content, aber sie verbessern die KI-Lesbarkeit, während Sie eine richtige Migration planen.