WordPress REST API 2026: Endpoints, Auth & Headless WordPress
/wp-json/wp/v2/. Application Passwords sind 2026 Standard für die Authentifizierung. Sicherheit ist kritisch: Endpoint-Härtung gegen User-Enumeration ist Pflicht, sonst leakt jeder WordPress-Shop seine Login-Namen.Die REST API gehört seit WordPress 4.7 zum Core und ist 2026 erwachsen geworden. Headless-Setups laufen produktiv, Mobile-Apps koppeln sich nativ an WordPress, und Frameworks wie Next.js holen Inhalte über REST oder den GraphQL-Aufsatz WPGraphQL. Wer 2026 ein Projekt mit getrennten Frontend- und Backend-Schichten plant, kommt an dieser API nicht vorbei. Dieser Guide deckt alles ab: Endpoint-Struktur, Authentifizierung, Custom Endpoints, Headless-Architektur und die wichtigsten Sicherheits-Hebel.
Was ist die WordPress REST API überhaupt?
Die WordPress REST API ist eine HTTP-Schnittstelle, die WordPress-Inhalte als JSON nach außen gibt und Schreibvorgänge entgegennimmt. Sie folgt den klassischen REST-Prinzipien: jede Ressource hat eine eindeutige URL, HTTP-Verben (GET, POST, PUT, DELETE) bestimmen die Aktion, der Server bleibt zustandslos. Basis-Pfad ist immer /wp-json/, gefolgt vom Namespace (wp/v2 für Core) und dem Ressourcen-Namen.
Konkret: Ein GET-Request auf https://ihre-domain.de/wp-json/wp/v2/posts liefert die 10 neuesten Blog-Beiträge als JSON-Array. Jeder Post enthält ID, Title, Content, Datum, Featured-Image-Link, Kategorien, Tags und Custom Fields (sofern registriert). Diese Daten lassen sich in jedem Frontend rendern: React, Vue, Svelte, Flutter-App, Custom-PHP-Site oder einfach ein anderes WordPress.
📊 REST-API-Diagnose Schnelltest
Tippen Sie ihre-domain.de/wp-json/ in den Browser. Sehen Sie ein JSON-Objekt mit „name“, „description“ und „routes“, läuft die API. Bekommen Sie 404 oder Redirect, blockiert ein Plugin oder die .htaccess. Status 200 mit leerem Body bedeutet meistens Permalink-Problem — Permalinks unter Einstellungen einmal neu speichern reicht oft.
Standard-Endpoints im Überblick
WordPress liefert 2026 im Core-Namespace wp/v2 rund 40 Endpoints aus. Die wichtigsten decken 90 Prozent aller Use Cases.
Praktische Beispiele mit curl aus der Konsole:
curl https://ihre-domain.de/wp-json/wp/v2/posts?per_page=5
curl https://ihre-domain.de/wp-json/wp/v2/pages/42
curl https://ihre-domain.de/wp-json/wp/v2/posts?categories=12&_embed
curl https://ihre-domain.de/wp-json/wp/v2/search?search=woocommerce
Jeder Endpoint unterstützt Query-Parameter wie per_page (max. 100), page, orderby, order, search, after (ISO-Datum) und _fields für Feld-Selektion. Der Parameter _embed ist Gold wert: er hängt verknüpfte Ressourcen wie Featured Images, Autor-Daten und Taxonomien direkt an die Antwort an und spart so weitere Requests.
API-Zugriff aktivieren und Sicherheits-Grundlagen 2026
Die REST API ist seit WordPress 4.7 standardmäßig aktiv. Sie zu deaktivieren ist 2026 in den meisten Fällen die falsche Entscheidung, weil der Block-Editor (Gutenberg) selbst über REST mit dem Backend spricht. Die richtige Strategie heißt: API laufen lassen, aber sensible Endpoints härten.
⚠️ User-Enumeration: Das größte API-Sicherheitsloch
Der Endpoint /wp-json/wp/v2/users liefert standardmäßig alle Autoren-Logins zurück. Ein Angreifer ruft den Endpoint auf, kennt damit alle Usernames und startet Brute-Force-Login. Lösung: Endpoint per Filter für nicht-eingeloggte Nutzer sperren. Code-Snippet weiter unten.
Drei Sicherheits-Grundregeln für die REST API 2026:
User-Endpoint für anonyme Zugriffe schließen.
?author=1 in Permalinks blockieren über die .htaccess oder Security-Plugin.Wenn nur ein Headless-Frontend liest, freigegebene Endpoints explizit definieren. Alles andere wirft 401.
Niemals
__return_true als Permission-Callback, immer Nutzer-Capabilities prüfen.Authentication 2026: Welche Methode für welchen Use Case?
Authentifizierung ist 2026 der Bereich, in dem die REST API am stärksten gereift ist. Vier Methoden existieren, drei davon sind produktionsreif.
Application Passwords sind 2026 die Standardlösung. Seit WordPress 5.6 im Core, kein Plugin nötig, jeder User kann sich im Profil bis zu 10 anwendungsspezifische Passwörter erzeugen. Diese Passwörter sind 24 Zeichen lang, lesen sich wie xxxx xxxx xxxx xxxx xxxx xxxx und werden per HTTP-Basic-Header übertragen — funktioniert aber NUR über HTTPS, weil sonst alles im Klartext geht.
curl -X POST https://ihre-domain.de/wp-json/wp/v2/posts \
-u „username:xxxx xxxx xxxx xxxx xxxx xxxx“ \
-H „Content-Type: application/json“ \
-d ‚{„title“:“Neuer Beitrag“,“status“:“publish“,“content“:“Hallo“}‘
JWT über das Plugin „JWT Authentication for WP-API“ lohnt sich, wenn das Frontend User-Logins braucht (z.B. Member-Bereich in Next.js). Workflow: User schickt Username + Passwort an /wp-json/jwt-auth/v1/token, bekommt Token zurück, schickt den Token bei jeder weiteren Anfrage im Authorization: Bearer ... Header.
⚠️ Basic Auth in Produktion: Nein
Das Plugin „Basic Auth“ funktioniert mit echtem WordPress-Login-Passwort. Wer das aktiviert, sendet das Master-Passwort des Users bei jeder Anfrage. Wird HTTPS irgendwann versehentlich deaktiviert oder gibt es einen Man-in-the-Middle, ist der ganze Account weg. Nur für lokale Tests einsetzen.
Daten lesen — GET-Requests in der Praxis
Lesen ist der häufigste API-Vorgang. Vier Parameter steigern die Performance dramatisch.
Pflicht-Parameter für effiziente GET-Requests
per_page — Anzahl Ergebnisse, max. 100. Default 10. Bei Listen-Views ruhig 50 setzen, spart Pagination-Roundtrips.
_fields — Komma-getrennte Liste von Feldern, die zurückgegeben werden. _fields=id,title,slug,date reduziert die Response von 8 KB auf 0,4 KB.
_embed — Verknüpfte Daten einbinden. Featured Image, Autor, Kategorien kommen mit. Spart 3–5 Folge-Requests.
orderby + order — Sortierung. orderby=menu_order&order=asc für manuelle Reihenfolge.
ACF-Felder per API: Advanced Custom Fields sind nicht automatisch in der REST-Antwort. Zwei Wege: das Plugin „ACF to REST API“ installieren (hängt ein acf-Objekt an jeden Post) oder Felder per register_rest_field selbst registrieren. Letzteres ist robuster, weil keine Plugin-Abhängigkeit entsteht.
add_action(‚rest_api_init‘, function() {
register_rest_field(‚post‘, ‚preis_info‘, [
‚get_callback‘ => function($post) {
return get_field(‚preis_info‘, $post[‚id‘]);
},
’schema‘ => [‚type‘ => ’string‘],
]);
});
Daten schreiben — POST, PUT und DELETE
Schreibvorgänge brauchen Authentifizierung und einen JSON-Body. Drei HTTP-Verben decken alle Schreibfälle.
Pflicht-Header für jeden Schreibvorgang: Content-Type: application/json und Authentifizierung. Der Body enthält die Felder, die gesetzt werden sollen. Felder, die nicht im Body stehen, bleiben unverändert (bei PUT). Bei POST gelten Default-Werte aus der WordPress-Konfiguration.
curl -X PUT https://ihre-domain.de/wp-json/wp/v2/posts/42 \
-u „username:APP_PASSWORD“ \
-H „Content-Type: application/json“ \
-d ‚{„title“:“Neuer Titel“,“status“:“publish“}‘
curl -X DELETE https://ihre-domain.de/wp-json/wp/v2/posts/42 \
-u „username:APP_PASSWORD“
curl -X DELETE https://ihre-domain.de/wp-json/wp/v2/posts/42?force=true \
-u „username:APP_PASSWORD“
Error-Handling: Bei Fehlern liefert WordPress JSON mit code, message und HTTP-Status. 401 = nicht authentifiziert, 403 = keine Berechtigung, 404 = Ressource nicht gefunden, 400 = Validation-Fehler, 500 = Server-Fehler. Im Code immer den HTTP-Status auswerten, nicht nur den Response-Body.
Custom Endpoints registrieren
Wenn die Core-Endpoints nicht reichen, baut man eigene. Drei Bestandteile: Route registrieren, Callback definieren, Permission-Check setzen. Code gehört in ein eigenes Plugin oder in functions.php des Child-Themes.
add_action(‚rest_api_init‘, function() {
register_rest_route(‚wlbatch/v1‘, ‚/stats‘, [
‚methods‘ => ‚GET‘,
‚callback‘ => ‚wlbatch_get_stats‘,
‚permission_callback‘ => function() {
return current_user_can(‚edit_posts‘);
},
‚args‘ => [
‚period‘ => [
‚required‘ => false,
‚default‘ => ’30‘,
‚validate_callback‘ => ‚is_numeric‘,
],
],
]);
});
function wlbatch_get_stats($request) {
$period = $request->get_param(‚period‘);
return rest_ensure_response([
‚posts‘ => wp_count_posts()->publish,
‚period_days‘ => (int)$period,
]);
}
Vier Kernpunkte beim Custom Endpoint:
Nie in
wp/v2 registrieren. Pflicht: eigenes vendor/version-Schema wie meinplugin/v1.Niemals weglassen.
__return_true nur in Ausnahmen mit klarer Begründung — z.B. öffentliche Suche, die ohnehin nichts Sensibles ausgibt.validate_callback und sanitize_callback für jeden User-Input. Sonst direkter SQL-Injection-Vektor.Für komplexere Endpoints ein Schema mitliefern. WordPress nutzt es für OPTIONS-Requests und für die automatische Doku.
Headless WordPress 2026: Next.js, Nuxt, Gatsby
Headless heißt: WordPress liefert nur Daten, das Rendering passiert in einem separaten Frontend-Framework. 2026 ist der Ansatz erwachsen, aber auch nicht der heilige Gral. Wer Headless wählt, muss wissen, was er aufgibt — und was er gewinnt.
Frontend-Stack-Vergleich 2026:
SEO-Auswirkungen: Headless ist 2026 SEO-neutral, wenn das Frontend Server-Side-Rendering oder Static-Generation nutzt. Pure Client-Side-React (CSR) ist hingegen für SEO weiterhin Risiko, weil Googlebot nur eingeschränkt JavaScript rendert. Next.js und Nuxt liefern out-of-the-box SSR — damit ist der SEO-Pflichtteil abgedeckt. Hreflang, Sitemaps und strukturierte Daten müssen aber ins Frontend wandern, weil das WordPress-Yoast-Plugin im Headless-Modus nichts mehr ausspielt.
Wann lohnt sich Headless? Wenn das Projekt eines oder mehrere dieser Kriterien erfüllt: Multi-Channel (Web + Mobile-App + Smart-TV), hohe Performance-Anforderungen (über 1 Mio. Pageviews/Monat), Frontend-Team mit React/Vue-Expertise, Sicherheits-Anforderungen, die ein öffentliches WordPress ausschließen. Sonst klassisches WordPress mit Cache. Bei uns aus Landau starten Headless-Projekte ab rund 6.500 Euro, klassische WordPress-Seiten ab 759 Euro Festpreis. Der Faktor 8 spricht Bände.
Performance und Caching der REST API
Eine unoptimierte REST-API-Antwort braucht 300 bis 1.200 Millisekunden. Mit Cache fallen die Antwortzeiten auf 20 bis 80 Millisekunden. Drei Cache-Schichten arbeiten parallel.
Redis als persistenter Object-Cache reduziert Datenbank-Queries dramatisch. Pflicht ab 50.000 Pageviews/Monat. Plugin: „Redis Object Cache“ von Till Krüss.
„WP REST Cache“ oder „WP Engine Smart Plugin Manager“ cachen fertige JSON-Responses. Default-TTL 5 Minuten, bei statischen Inhalten ruhig 1 Stunde.
Cloudflare-Page-Rule für
/wp-json/wp/v2/posts* mit Edge-TTL 5 Minuten. Spart 80 Prozent der Origin-Requests. Beim Update der Inhalte API-Cache per Hook invalidieren.Performance-Faustregel 2026
„Wenn die REST-API-Antwort über 200 ms liegt und der Endpoint nicht stark personalisiert ist, fehlt eine Cache-Schicht. Redis-Object-Cache plus 5-Minuten-Edge-Cache holen 95 Prozent der möglichen Beschleunigung mit minimalem Aufwand.“
Cache-Busting bei Schreibvorgängen: Wenn ein Post aktualisiert wird, müssen alle gecachten Listen-Antworten, die diesen Post enthalten könnten, invalidiert werden. Cloudflare-API per save_post-Hook ansprechen und gezielt Pfade purgen. WP Rocket erledigt das beim WP-Frontend automatisch, beim REST-Cache muss man selbst Hand anlegen.
Sicherheits-Härtung der REST API
Sieben Hebel, die 2026 jede produktive REST-API-Installation aktivieren sollte.
⚠️ Hebel 1: User-Endpoint für Anonyme sperren
Der wichtigste Anti-Enumeration-Move. Code in functions.php:
if (!is_user_logged_in()) {
unset($endpoints[‚/wp/v2/users‘]);
unset($endpoints[‚/wp/v2/users/(?P<id>[\d]+)‘]);
}
return $endpoints;
});
Hebel 2: ?author=N blockieren — leakt User-Slugs über Redirect. Per .htaccess-Regel oder Plugin abfangen.
Hebel 3: xmlrpc.php deaktivieren, wenn keine externe App es nutzt. Filter add_filter('xmlrpc_enabled', '__return_false');. Alter Brute-Force-Vektor, der 2026 immer noch aktiv ausgenutzt wird.
Hebel 4: Rate-Limiting auf API-Routen. Plugin „WP REST API Rate Limit“ oder per Cloudflare Rate-Limiting-Regel: max. 60 Requests pro Minute pro IP. Stoppt Scraper und Brute-Force-Versuche.
Hebel 5: Application Passwords ausschließlich über HTTPS akzeptieren. Per .htaccess Mixed-Content komplett verbieten, HSTS-Header setzen.
Hebel 6: REST-API komplett für Anonyme dichtmachen, wenn nur ein internes Backend sie nutzt. Code-Snippet:
if (!empty($result)) return $result;
if (!is_user_logged_in()) {
return new WP_Error(‚rest_not_logged_in‘,
‚Nur fuer eingeloggte Nutzer.‘, [’status‘ => 401]);
}
return $result;
});
Hebel 7: Logging und Monitoring. „WP Activity Log“ plus Server-Access-Logs auswerten. Verdächtige Muster: viele 401-Antworten auf /wp-json/jwt-auth/v1/token deuten auf Brute-Force. Mit Fail2Ban oder Cloudflare-WAF blocken.
Empfehlung 2026
Aktivieren Sie mindestens die Hebel 1, 3, 4 und 5 auf jeder produktiven Installation. Hebel 6 nur, wenn definitiv kein öffentliches Headless-Frontend dranhängt. Bei uns aus Landau ist diese Härtung Teil jedes Wartungs-Onboardings ab 29,99 Euro/Monat.
Ihre Website ab 759 Euro
Festpreis, REST-API-Härtung inklusive, Application Passwords vorkonfiguriert und 12 Monate Support.
Häufige Fragen zur WordPress REST API
Fazit
Die WordPress REST API ist 2026 die unsichtbare Infrastruktur hinter Headless-Projekten, Mobile-Apps und Drittsystem-Integrationen. Wer ihre Endpoint-Struktur versteht, Application Passwords sauber einsetzt und die Sicherheits-Hebel gegen User-Enumeration aktiviert, hat 90 Prozent der typischen Einsatzszenarien im Griff. Headless lohnt sich für die obersten 10 Prozent der Projekte — der Rest fährt mit klassischem WordPress plus REST-Cache schneller, günstiger und ohne doppelte Wartungsflächen.
Unsere Erfahrung aus über 80 betreuten WordPress-Projekten: Die häufigsten Fehler liegen nie im API-Code, sondern in der fehlenden Härtung und im fehlenden Cache. Beides ist mit zwei Stunden Setup erledigt, sobald man weiß, wo die Hebel sitzen. Beratung kostenlos und ohne Vertrag unter +49 176 21 776099 oder direkt zum Angebot ab 759 Euro Festpreis.