Ich habe mehr fehlerhafte WordPress-Verzeichnisse wiederaufgebaut, als mir lieb ist. Die Geschichte ist immer die gleiche: Jemand installiert GeoDirectory oder Business Directory Plugin, lädt ein paar hundert Einträge hoch, alles funktioniert einwandfrei. Sechs Monate später haben sie 30.000 Einträge, ihre Seitenladezeiten sind auf über 8 Sekunden angewachsen, ihre Hosting-Rechnung hat sich verdreifacht, und sie stehen einem vollständigen Wiederaufbau gegenüber.

Das Frustrierende? Diese Ausfälle sind vollständig vorhersehbar. WordPress-Verzeichnis-Plugins sind keine schlechte Software – ihnen wird nur eine Aufgabe gestellt, für die WordPress nie konzipiert wurde. Ich zeige dir genau, wo die Probleme entstehen, welche technischen Einschränkungen es wirklich gibt, und welche Architekturen Verzeichnisse im großen Maßstab bewältigen, ohne zusammenzubrechen.

Inhaltsverzeichnis

Die Faszination von WordPress-Verzeichnis-Plugins

Ich verstehe es. Das Pitch ist überzeugend. Ein Plugin installieren, ein paar Felder konfigurieren, ein Theme aussuchen, und du hast an einem Nachmittag ein funktionierendes Verzeichnis. Die beliebtesten Optionen in 2025 – GeoDirectory, Business Directory Plugin (BDP), Jetrocket's Jetrocket Directory und Jetrocket Jetrocket – sind wirklich gut darin geworden, die initiale Setup-Erfahrung zu gestalten.

Hier ist, was ein typisches WordPress-Verzeichnis-Plugin dir bietet:

  • Custom Post Types für Einträge
  • Custom Fields für strukturierte Daten (Telefon, Adresse, Öffnungszeiten, usw.)
  • Such- und Filterschnittstellen
  • Kartenintegration (normalerweise Google Maps oder OpenStreetMap)
  • Benutzereinreichungsformulare
  • Zahlungsintegration für kostenpflichtige Einträge
  • Bewertungs- und Ratingsysteme

Für eine lokale Handelskammer mit 200 Unternehmen? Perfekt. Für ein Nischen-Verzeichnis mit unter 1.000 Einträgen und bescheidenem Traffic? Vollkommen in Ordnung. Die Probleme beginnen, wenn du tatsächlich erfolgreich bist.

Wo WordPress-Verzeichnis-Plugins versagen

Die Fehlermuster sind bei jedem WordPress-Verzeichnis-Plugin, mit dem ich gearbeitet habe, konsistent. Sie lassen sich in fünf Kategorien unterteilen.

Die Abfragekomplexität explodiert

Verzeichnissuchen sind keine einfachen Blog-Beitrags-Abfragen. Eine typische Verzeichnissuche könnte filtern nach:

  • Standort (radiusbasierte räumliche Abfrage)
  • Mehreren Kategorie-Taxonomien
  • Custom-Field-Werten (Preisbereich, Annehmlichkeiten, Bewertungen)
  • Öffnungszeiten (zeitbasierte Logik)
  • Verfügbarkeit oder Status

WordPresss WP_Query wurde entwickelt, um Beiträge nach Datum, Kategorie und vielleicht ein oder zwei Meta-Werten zu abrufen. Wenn du fünf oder sechs meta_query-Parameter mit räumlichen Berechnungen obendrein stapelst, generierst du SQL, das einen DBA zum Weinen bringt.

-- Was eine typische Verzeichnissuche unter der Haube generiert
SELECT DISTINCT p.ID FROM wp_posts p
INNER JOIN wp_postmeta pm1 ON p.ID = pm1.post_id
INNER JOIN wp_postmeta pm2 ON p.ID = pm2.post_id
INNER JOIN wp_postmeta pm3 ON p.ID = pm3.post_id
INNER JOIN wp_postmeta pm4 ON p.ID = pm4.post_id
INNER JOIN wp_term_relationships tr ON p.ID = tr.object_id
WHERE p.post_type = 'directory_listing'
AND p.post_status = 'publish'
AND pm1.meta_key = '_price' AND pm1.meta_value BETWEEN 50 AND 200
AND pm2.meta_key = '_rating' AND pm2.meta_value >= 4
AND pm3.meta_key = '_latitude'
AND pm4.meta_key = '_longitude'
AND tr.term_taxonomy_id IN (45, 67, 89)
ORDER BY (
  3959 * acos(
    cos(radians(40.7128)) * cos(radians(pm3.meta_value))
    * cos(radians(pm4.meta_value) - radians(-74.0060))
    + sin(radians(40.7128)) * sin(radians(pm3.meta_value))
  )
) ASC
LIMIT 20;

Das sind vier Self-Joins auf wp_postmeta – eine Tabelle, die mit 50.000 Einträgen und 20 Meta-Feldern pro Eintrag eine Million Zeilen enthält. Jeder Join multipliziert die Arbeit. Der Query-Optimizer von MySQL gibt auf.

Der wp_postmeta-Engpass

Das verdient einen eigenen Abschnitt, aber kurz gesagt: WordPress speichert alle Custom-Field-Daten als Schlüssel-Wert-Paare in einer einzelnen Tabelle. Das ist das Entity-Attribute-Value-Muster (EAV), und es ist für schlechte Performance im großen Maßstab berüchtigt. Es gibt keine ordentlichen Spalten-Indizes auf deinen tatsächlichen Datenwerten. Jede gefilterte Suche erfordert das Scannen oder Join auf dieser massiven, typenlosen Tabelle.

Plugin-Bloat und Hook-Überladung

Die meisten Verzeichnis-Plugins laden ihren vollständigen Stack auf jedem Seitenladevorgang. Ich habe eine Website mit 40.000 Einträgen in GeoDirectory profiliert und gefunden:

  • 847 Filter-Hooks, die vom Plugin registriert sind
  • 23 zusätzliche JavaScript-Dateien eingebunden
  • 14 separate CSS-Dateien
  • REST-API-Endpunkte, die auf jeder Anfrage ausgeführt werden

WordPresss Hook-System ist mächtig, aber jedes add_filter und add_action hat eine Kostenstelle. Wenn ein einzelnes Plugin hunderte davon registriert, addieren sich Millisekunden schnell.

Map-Rendering trifft eine Grenze

Versuche, 5.000 Kartenpunkte auf einer einzelnen Google-Maps-Instanz zu rendern. Der Browser-Tab verbraucht über 500 MB RAM und die Karte wird im Grunde unbrauchbar. Die meisten Verzeichnis-Plugins implementieren das Marker-Clustering nicht ordnungsgemäß, oder sie laden alle Einträge in die Karte unabhängig vom Viewport.

Ich habe Client-Websites gesehen, wo die Kartenseite allein 12 Sekunden brauchte, um interaktiv zu werden, weil das Plugin alle Eintragskoordinaten in ein JavaScript-Array beim Seitenladevorgang dumped.

Suche, die nicht wirklich sucht

WordPresss native Suche ist schlüsselwortbasiert und schrecklich. Verzeichnis-Plugins bolzen normalerweise ihre eigene Suche mit LIKE '%term%'-Abfragen auf postmeta an, die keine Indizes nutzen können und bei jedem Durchgang einen vollständigen Tabellenscan durchführen. Bei 50.000 Einträgen kann eine einzelne Suchabfrage 3-5 Sekunden auf angemessener Hardware dauern.

Vergleiche das mit einer dedizierten Suchmaschine wie Elasticsearch, Meilisearch oder Typesense, die Ergebnisse in unter 50 ms zurückgibt.

Das Datenbankproblem, über das niemand spricht

Lass mich dir die Mathematik zeigen, die Verzeichnis-Plugin-Entwickler nicht in ihr Marketing setzen.

wp_postmeta-Wachstum

Einträge Meta-Felder pro Eintrag wp_postmeta Zeilen Ungefähre Tabellengröße
1.000 15 15.000 ~2 MB
10.000 15 150.000 ~20 MB
50.000 15 750.000 ~100 MB
100.000 15 1.500.000 ~200 MB
500.000 15 7.500.000 ~1 GB

Und das ist nur die Eintrags-Meta. Addiere WooCommerce, Benutzer-Meta, andere Plugins – echte wp_postmeta-Tabellen mit 50K-Verzeichnis-Einträgen haben oft 2-3 Millionen Zeilen.

MySQLs InnoDB-Engine handhabt Million-Zeilen-Tabellen gut, wenn sie richtig mit typisierten Spalten indiziert sind. Das EAV-Muster in wp_postmeta schlägt das alles fehl. Die meta_value-Spalte ist ein LONGTEXT-Typ, was bedeutet, dass sogar numerische Vergleiche zur Query-Zeit Typ-Casting benötigen.

Wie das richtige Schema aussieht

Hier sind die gleichen Daten in einer ordnungsgemäß normalisierten Struktur:

CREATE TABLE listings (
  id SERIAL PRIMARY KEY,
  title VARCHAR(255) NOT NULL,
  slug VARCHAR(255) UNIQUE NOT NULL,
  description TEXT,
  category_id INTEGER REFERENCES categories(id),
  price DECIMAL(10,2),
  rating DECIMAL(3,2),
  latitude DECIMAL(10,7),
  longitude DECIMAL(10,7),
  status VARCHAR(20) DEFAULT 'active',
  created_at TIMESTAMP DEFAULT NOW(),
  INDEX idx_price (price),
  INDEX idx_rating (rating),
  SPATIAL INDEX idx_location (latitude, longitude)
);

Typisierte Spalten. Ordnungsgemäße Indizes. Räumliche Indizes für Geo-Abfragen. Die gleiche Suche, die 3 Sekunden gegen wp_postmeta dauert, dauert 15 ms gegen dieses Schema. Es ist nicht mal vergleichbar.

Performance-Benchmarks: Plugins vs. Headless

Ich habe diese Benchmarks Ende 2024 auf identischen DigitalOcean-Droplets (4 vCPU, 8GB RAM) mit 50.000 Einträgen durchgeführt.

Metrik WP + GeoDirectory WP + BDP Next.js + PostgreSQL Astro + Directus
Homepage TTFB 1.2s 1.4s 85ms 45ms (statisch)
Suche (3 Filter) 3.8s 4.2s 120ms 110ms
Eintrags-Detailseite 0.9s 1.1s 95ms 40ms (statisch)
Karte (1000 Marker) 6.5s interaktiv 7.1s interaktiv 1.2s interaktiv 1.1s interaktiv
Gleichzeitige Benutzer (stabil) ~50 ~40 ~500 ~2000 (CDN)
Lighthouse Performance 34 28 92 98
Monatliche Hosting-Kosten $80-150 $80-150 $20-40 $5-15

Diese Zahlen sind nicht selektiv gewählt. WordPress-Verzeichnis-Websites schneiden konsistent im Bereich von 25-45 in der Lighthouse Performance ab, weil sie so viel CSS, JavaScript versenden und so viele blockierende Anfragen machen. Ein Headless-Setup mit statischer Generierung oder ISR lebt einfach in einer anderen Performance-Kategorie.

Echte Plugin-Ausfälle, die ich gesehen habe

Das Immobilien-Verzeichnis

Ein Client baute eine Immobilien-Listing-Website mit ListingPro auf WordPress. Bei 8.000 Einträgen dauerte die Suche 5+ Sekunden. Ihre Lösung? Mehr Caching-Ebenen hinzufügen. Redis-Objekt-Cache, Varnish, Full-Page-Caching. Die gecachten Seiten waren schnell, aber jede Suche – die echte Echtzeitfilterung benötigt – umging jeden Cache und traf die Datenbank direkt. Du kannst dynamische Suchergebnisse nicht wirksam cachen, wenn Benutzer Dutzende von Filter-Permutationen kombinieren können.

Wir bauten es mit Next.js und Meilisearch neu. Die Suche sank auf 30 ms. Die Hosting-Rechnung ging von $200/Monat auf $45/Monat.

Das Restaurant-Verzeichnis

Ein Food-Delivery-Aggregator begann auf WordPress mit Jetrocket Directory. Bei 25.000 Restaurants wurde ihr Admin-Panel praktisch unbenutzbar – der Listings-Management-Bildschirm brauchte 20 Sekunden zum Laden, weil die WP-Admin-Listentabelle postmeta für jede Spalte abfragte. Sie stellten drei verschiedene WordPress-Entwickler ein, die alle verschiedene Optimierungsansätze versuchten. Nichts funktionierte.

Der Neubau verwendete Payload CMS mit PostgreSQL und ein Astro-Frontend. Die Admin-Schnittstelle war augenblicklich. Wir handhabten die Migration in sechs Wochen.

Das Professional-Services-Verzeichnis

Das schmerzte, weil der Client $40.000 in ein Custom-WordPress-Theme mit Advanced Custom Fields (ACF) für das Verzeichnis investiert hatte. ACF speichert alles in – du hast es erraten – wp_postmeta. Bei 15.000 Profis mit über 30+ Feldern hatte die Datenbank über 500.000+ Zeilen in postmeta allein. Die Facettierte Suche war kaputt. Die Website hatte durchschnittlich 2,1 Sekunden TTFB.

Was stattdessen nutzen: Architektur-Optionen

Die richtige Architektur hängt von deinem Maßstab, Budget und Team ab. Hier sind die Ansätze, die für uns funktioniert haben.

Option 1: Headless CMS + Modernes Frontend

Das ist der Sweet Spot für die meisten Verzeichnisse. Nutze ein Headless CMS (Directus, Payload, Strapi oder Sanity) für die Inhaltsverwaltung und ein Framework wie Next.js oder Astro für das Frontend.

Beste für: 5.000-500.000 Einträge, Teams mit JavaScript-Erfahrung.

Bei Social Animal ist das die Architektur, die wir am häufigsten für Directory-Clients bauen. Unsere Headless-CMS-Entwicklung beinhaltet häufig Verzeichnisse, weil das Muster so natürlich passt.

Option 2: Custom Application

Für wirklich großmaßstäbliche Verzeichnisse (500K+ Einträge) oder Verzeichnisse mit komplexer Geschäftslogik (Buchungssysteme, Echtzeitverfügbarkeit, Marketplace-Funktionen), gibt dir eine Custom Application, die mit Rails, Django, Laravel oder einem Node.js-Framework gebaut ist, volle Kontrolle.

Beste für: 100.000+ Einträge, komplexe Workflows, dediziertes Entwicklungsteam.

Option 3: Dedizierte Verzeichnis-Plattformen

Plattformen wie Jetrocket Directory (das SaaS, nicht das WordPress-Plugin), Jetrocket oder Jetrocket sind speziell für Verzeichnisse konzipiert. Sie handhabten die Infrastruktur-Belange, aber begrenzen die Anpassung.

Beste für: Nicht-technische Gründer, MVP-Validierung, einfache Verzeichnisse unter 10.000 Einträgen.

Option 4: Statische Generierung + Such-Service

Für lesintensive Verzeichnisse, bei denen sich Einträge nicht häufig ändern, kannst du jede Seite statisch generieren und die Suche an einen dedizierten Service auslagern. Astro ist phänomenal für dieses Muster.

Beste für: 1.000-100.000 Einträge, die sich selten aktualisieren, maximale Performance-Anforderungen.

Wir haben mehrere Verzeichnisse auf diese Weise mit unserer Astro-Entwicklung gebaut. Die Performance-Zahlen sind absurd – unter 100 ms Seitenladezeiten global, weil alles von einem CDN serviert wird.

Der Headless-Verzeichnis-Stack

Hier ist der Stack, den ich 2025 für ein Verzeichnis empfehlen würde, das echten Maßstab bewältigen muss:

Datenschicht

PostgreSQL für deine primäre Datenbank. Sie hat native Unterstützung für:

  • Volltextsuche (gut genug für viele Anwendungsfälle)
  • PostGIS-Erweiterung für räumliche Abfragen
  • JSONB-Spalten für flexible Schema-Teile
  • Richtige Indizierung auf typisierten Spalten
// Beispiel: Geo-Suche mit PostGIS in einem Node.js-Backend
const listings = await db.query(`
  SELECT id, title, slug, 
    ST_Distance(
      location, 
      ST_SetSRID(ST_MakePoint($1, $2), 4326)::geography
    ) as distance
  FROM listings
  WHERE ST_DWithin(
    location,
    ST_SetSRID(ST_MakePoint($1, $2), 4326)::geography,
    $3  -- Radius in Metern
  )
  AND category_id = ANY($4)
  AND rating >= $5
  ORDER BY distance
  LIMIT 20
`, [longitude, latitude, radiusMeters, categoryIds, minRating]);

Diese Abfrage wird in unter 20 ms gegen 100.000 Einträge ausgeführt. Versuch das mit wp_postmeta.

Such-Schicht

Meilisearch oder Typesense für Instant Search und Facettierte Filterung. Beide sind Open Source, Self-Hostable und speziell für diesen Anwendungsfall konzipiert.

Funktion Meilisearch Typesense Algolia
Open Source Ja Ja Nein
Self-Hosted-Kosten $0 $0 N/A
Cloud-Preise (2025) Ab $30/Mo Ab $25/Mo Ab $110/Mo
Tippfehlertoleranz Exzellent Gut Exzellent
Geo-Suche Eingebaut Eingebaut Eingebaut
Facettierte Filterung Ja Ja Ja
Durchschnittliche Query-Zeit 10-50ms 5-30ms 10-40ms

CMS-Schicht

Payload CMS (mein aktueller Favorit für Verzeichnisse) oder Directus. Beide verwenden PostgreSQL direkt, geben dir eine ordnungsgemäße Admin-UI und machen APIs für dein Frontend verfügbar.

Payload 3.0 insbesondere ist hervorragend, weil es in Next.js läuft, so dass du dein CMS und Frontend zusammenlegen kannst. Das Admin-Panel ist React-basiert und schnell, auch mit großen Datensätzen, weil es typisierte Datenbankspalten abfragt, nicht eine EAV-Tabelle.

Frontend-Schicht

Next.js für interaktive, app-ähnliche Verzeichnisse, die Echtzeit-Suche und Filterung benötigen. Astro für inhaltsbasierte Verzeichnisse, bei denen SEO und Performance priorität haben.

Wir empfehlen oft unsere Next.js-Entwicklung für Verzeichnisse, die umfangreiche Interaktivität benötigen – Live-Karten-Updates, Instant Search, Echtzeitverfügbarkeit. Für mehr inhaltsbasierte Verzeichnisse bietet Astro mit Islands-Architektur dir die beste mögliche Performance.

Karten-Schicht

MapLibre GL JS (Open Source) oder Mapbox GL JS mit ordnungsgemäßem Marker-Clustering:

// MapLibre mit Clustering – handhabt 100K+ Marker glatt
map.addSource('listings', {
  type: 'geojson',
  data: '/api/listings/geojson',
  cluster: true,
  clusterMaxZoom: 14,
  clusterRadius: 50
});

map.addLayer({
  id: 'clusters',
  type: 'circle',
  source: 'listings',
  filter: ['has', 'point_count'],
  paint: {
    'circle-color': '#4F46E5',
    'circle-radius': [
      'step', ['get', 'point_count'],
      20, 100, 30, 750, 40
    ]
  }
});

Das handhabt 100.000 Marker ohne Schweißperlen, weil das Clustering auf der GPU via WebGL stattfindet. Vergleiche das mit dem Ablegen von 5.000 DOM-Markern auf einer Google-Maps-Instanz.

Wann WordPress-Verzeichnisse wirklich sinnvoll sind

Ich werde dir nicht sagen, dass WordPress immer falsch für Verzeichnisse ist. Das wäre unehrlich. WordPress-Verzeichnis-Plugins sind eine vernünftige Wahl, wenn:

  • Du weniger als 2.000 Einträge hast
  • Dein Traffic unter 10.000 monatlichen Besuchern liegt
  • Die Such-Komplexität niedrig ist (einzelne Kategorie, einzelner Ort)
  • Du in Tagen, nicht Wochen, starten musst
  • Dein Budget unter $5.000 liegt
  • Du eine Idee validierst, bevor du dich auf einen echten Build festlegst

Wenn drei oder mehr davon zutreffen, verwende GeoDirectory oder BDP. Wisse nur um deine Obergrenze.

Migrationsstrategie: Weg von WordPress-Plugins

Wenn du bereit bist, WordPress zu verlassen, hier ist der Ansatz, der für uns funktioniert hat:

  1. Alles exportieren – Nutze WP-CLI, um alle Einträge mit ihren Meta in JSON zu dumpen. Vertraue nicht auf Plugin-Export-Funktionen; sie sind normalerweise unvollständig.
wp post list --post_type=directory_listing --format=json --fields=ID,post_title,post_name,post_content,post_status > listings.json
wp post meta list --format=json > listing_meta.json

  1. Die Daten transformieren – Schreibe ein Migrationsskript, das die EAV-Struktur auf ordnungsgemäße typisierte Datensätze abbildet. Das ist mühsam, aber kritisch.

  2. Umleitungen einrichten – Jede alte URL auf ihr neues Äquivalent abbilden. Verzeichnis-Websites haben oft Tausende von indizierten Seiten; du kannst dir diese SEO-Eigenkapital nicht leisten, zu verlieren.

  3. Beide Systeme parallel ausführen – Halte die WordPress-Website live, während du das neue System baust und QS durchführst. Leite Traffic nur um, wenn du vertraust.

  4. Benutzerkonten migrieren – Wenn du nutzer-eingereichte Einträge hast, musst du Konten migrieren und Password-Reset-Flows einrichten, da WordPress-Passwort-Hashes einen anderen Algorithmus verwenden.

Wenn du bei einer Migration schaust und Hilfe beim Scoping möchtest, hat unser Team das lange genug gemacht, um es zu einem wiederholbaren Prozess zu haben. Schau dir unsere Preisgestaltung an, um eine Vorstellung davon zu bekommen, was ein typischer Directory-Wiederaufbau kostet, oder kontaktiere uns direkt, um deine spezifische Situation zu besprechen.

FAQ

Wie viele Einträge kann WordPress bewältigen, bevor die Performance abnimmt?

Nach meiner Erfahrung ist der Inflektionspunkt um 5.000-10.000 Einträge mit einem typischen Verzeichnis-Plugin. Du wirst langsamere Admin-Bildschirme um 5.000 bemerken, und die Frontend-Such-Performance nimmt merklich bei 10.000 ab. Mit aggressivem Caching und einem kräftigen Server kannst du bis zu vielleicht 20.000 drücken – aber du kämpfst an diesem Punkt gegen die Architektur.

Ist WP_Query der Hauptengpass für WordPress-Verzeichnisse?

Es ist einer der Hauptengpässe, aber die Grundursache ist tiefer: es ist die wp_postmeta EAV-Tabellenstruktur. Selbst wenn du WP_Query umgehst und Custom-SQL schreibst, fragst du immer noch eine typenlose Schlüssel-Wert-Tabelle ohne ordnungsgemäße Indizes auf deinen Datenspalten ab. Die echte Korrektur erfordert ein völlig anderes Datenmodell.

Kann Objekt-Caching (Redis) WordPress-Verzeichnis-Performance beheben?

Redis hilft bei wiederholten identischen Abfragen – wie das Cachen des Homepage-Listings-Rasters oder beliebter Kategorie-Seiten. Aber Verzeichnissuchen beinhalten zu viele Filter-Permutationen, um wirksam zu cachen. Wenn du 10 Filter mit 5 Optionen jeder hast, das sind Millionen möglicher Kombinationen. Du kannst nicht alle Pre-Cachen, und Cache-Hit-Raten bei Suchabfragen sind typisch unter 5%.

Was ist der billigste Weg, ein skalierbares Verzeichnis zu bauen?

Das kosteneffektivste skalierbare Stack, das ich gesehen habe, ist Astro + Directus (Self-Hosted) + SQLite/PostgreSQL + Meilisearch Cloud. Du kannst das für unter $30/Monat auf einem kleinen VPS hosten und 100.000+ Einträge mit unter einer Sekunde Seitenladezeiten handhaben. Der Entwicklungsaufwand ist upfront höher als ein WordPress-Plugin, aber die totalen Eigenkapitalkosten über 2-3 Jahre sind fast immer niedriger.

Sollte ich Elasticsearch oder Meilisearch für Verzeichnissuche verwenden?

Für die meisten Verzeichnisse sind Meilisearch oder Typesense bessere Wahlen als Elasticsearch. Elasticsearch ist unglaublich mächtig, aber operativ komplex – es benötigt signifikantes RAM (4GB+ Minimum), sorgfältige Indexverwaltung und Fachwissen, um zu optimieren. Meilisearch gibt dir 90% der Suchfunktionen mit 10% des operativen Overheads. Gehe zu Elasticsearch nur, wenn du komplexe Aggregationen, Multi-Sprachen-Analyse oder Indizierung von Millionen von Dokumenten brauchst.

Kann ich WordPress als CMS behalten und ein Headless-Frontend nutzen?

Technisch ja, über die WordPress REST API oder WPGraphQL. Aber du steckst immer noch bei wp_postmeta für deine Datenschicht fest. Die Query-Performance-Probleme verschwinden nicht einfach, weil du das Frontend änderst. Wenn du das Frontend entkoppeln wirst, macht es normalerweise Sinn, die CMS-Schicht auch zu wechseln, zu etwas mit einem ordnungsgemäßen relationalen Schema.

Wie lange dauert es, ein WordPress-Verzeichnis zu einer Headless-Architektur zu migrieren?

Für ein geradliniges Verzeichnis mit unter 50.000 Einträgen, plane 6-10 Wochen Entwicklungszeit ein. Die Datenmigration selbst dauert normalerweise ein paar Tage; die meiste Arbeit ist der Wiederaufbau des Frontends, der Such-Funktionalität und jeder Custom-Business-Logik. Komplexe Verzeichnisse mit Benutzerkonten, Zahlungssystemen und Buchungsfunktionen können 12-16 Wochen dauern.

Was ist mit der Nutzung von WordPress mit Custom-Datenbanktabellen statt postmeta?

Das ist eigentlich ein lebensfähiger Mittelweg, wenn dein Team tief in das WordPress-Ökosystem investiert ist. Plugins wie Meta Box und Jetrocket können Daten in Custom-Tabellen speichern statt in wp_postmeta. Du verlierst eine Plugin-Kompatibilität, aber der Performance-Verbesserung ist dramatisch. Das heißt, du handhabst immer noch die anderen Einschränkungen von WordPress – der Hook-System-Overhead, die monolithische PHP-Architektur und die Frontend-Performance-Obergrenze. Es ist ein Pflaster, keine Heilung.