Die kurze Antwort

Bei einer aktuellen WordPress-Installation müssen Sie die REST API normalerweise nicht eigens aktivieren. Sie gehört zum WordPress Core. Rufen Sie zuerst https://ihre-domain.de/wp-json/ auf. Erscheint eine JSON-Antwort mit Routen und Namespaces, arbeitet die API grundsätzlich.

Ein Fehler bedeutet deshalb nicht automatisch, dass die gesamte REST API abgeschaltet ist. Ein öffentliches Leseziel kann mit Status 200 antworten, während ein geschützter Endpunkt ohne Anmeldung korrekt 401 oder 403 liefert. Prüfen Sie zuerst Statuscode, Antwortformat und betroffene Route. Ändern Sie erst danach Permalinks, Plugins oder Serverregeln.

Wenn eine individuelle Route, Berechtigungslogik oder externe Anbindung fehlt, hilft eine sauber gekapselte WordPress Plugin Entwicklung. Für einen bestehenden Shop oder eine produktive Website sollte die Diagnose zuerst in einer Testumgebung erfolgen.

REST API in zwei Minuten prüfen

Testen Sie zuerst die API-Wurzel und danach genau die Route, die Ihre Anwendung verwendet. Der Browser genügt für einen ersten Blick. Mit curl sehen Sie zusätzlich den HTTP-Status und den Content-Type.

Basischeck im Terminal
curl -i https://ihre-domain.de/wp-json/
curl -i 'https://ihre-domain.de/?rest_route=/'
curl -i https://ihre-domain.de/wp-json/wp/v2/posts
  • 200 und application/json: Die geprüfte Route ist erreichbar.
  • 401 oder 403 mit JSON: Die Route existiert, verlangt aber wahrscheinlich Anmeldung oder eine passende Berechtigung.
  • 404 auf /wp-json/, aber 200 auf ?rest_route=/: Die API läuft. Die Rewrite-Regeln für sprechende URLs sind die wahrscheinlichere Ursache.
  • 404 mit dem Code rest_no_route: Der Namespace, die Route oder die HTTP-Methode passt nicht.
  • 500 oder eine HTML-Fehlerseite: Prüfen Sie PHP-Fehler, Plugin-Konflikte, Proxy und Web Application Firewall.

Devvibe-Praxischeck: drei Antworten richtig einordnen

Wir haben den Ablauf am 29. September 2026 von unserer Testumgebung aus gegen die öffentliche WordPress-News-Installation reproduziert. Der Test verändert keine Daten und verwendet keine Zugangsdaten.

Die API-Wurzel /news/wp-json/ antwortete mit 200 und application/json. Derselbe Server lieferte für /wp-json/wp/v2/types/post?context=edit ohne Anmeldung 401 mit rest_forbidden_context. Eine absichtlich nicht vorhandene Route antwortete mit 404 und rest_no_route. Damit ist belegt: 401 und 404 sind allein kein Nachweis für eine abgeschaltete API. Entscheidend sind Route, Kontext und Fehlercode.

Reproduzierbarer Lesecheck
curl -sS -o /dev/null -w '%{http_code} %{content_type}
' https://wordpress.org/news/wp-json/
curl -sS -o /dev/null -w '%{http_code} %{content_type}
' 'https://wordpress.org/news/wp-json/wp/v2/types/post?context=edit'
curl -sS -o /dev/null -w '%{http_code} %{content_type}
' https://wordpress.org/news/wp-json/devvibe-check/v1/missing
  • Beobachtet: 200 application/json für die API-Wurzel.
  • Beobachtet: 401 application/json für den geschützten Bearbeitungskontext.
  • Beobachtet: 404 application/json für die absichtlich fehlende Route.
  • Testumgebung: Linux, curl, anonymer GET-Request, keine Cookies, keine Schreiboperation.

Wenn ?rest_route=/ funktioniert, /wp-json/ aber nicht, erreicht die Anfrage WordPress nicht über die erwartete Rewrite-Regel. Öffnen Sie Einstellungen, Permalinks und speichern Sie die vorhandene Struktur erneut. Auf einer verwalteten Umgebung kann der gleiche Schritt kontrolliert mit WP-CLI erfolgen.

Prüfen Sie danach beide URLs erneut. Bleibt nur /wp-json/ fehlerhaft, untersuchen Sie die Webserver-Konfiguration, vorgeschaltete Proxys und Weiterleitungen. Überschreiben Sie keine Serverdatei blind. Vergleichen Sie die aktive Konfiguration mit einer funktionierenden Testumgebung und sichern Sie den vorherigen Stand.

Rewrite-Regeln mit WP-CLI neu erzeugen
wp rewrite flush

Wiederkehrende Rewrite-, Update- oder Pluginfehler gehören in eine planbare WordPress Wartung, nicht in spontane Änderungen am Livesystem.

Fehler 401 oder 403: Authentifizierung von Blockade trennen

Ein 401- oder 403-Status kann korrekt sein. WordPress prüft für geschützte Aktionen Anmeldung und Benutzerrechte. Testen Sie deshalb zusätzlich einen öffentlichen Endpunkt. Funktioniert die API-Wurzel, aber nicht der Bearbeitungskontext, prüfen Sie Authentifizierung, Capability und Nonce statt die REST API global freizuschalten.

Für Anfragen innerhalb von WordPress verwendet die REST API Cookie-Authentifizierung und Nonces. Externe Integrationen brauchen ein dafür vorgesehenes Verfahren über HTTPS. Übergeben Sie keine Passwörter in URLs und protokollieren Sie keine geheimen Header. Eine Firewall darf verdächtige Anfragen blockieren, sollte aber nicht pauschal alle REST-Routen sperren.

  • Prüfen Sie, ob nur Schreibzugriffe oder auch öffentliche GET-Anfragen betroffen sind.
  • Vergleichen Sie die Benutzerrolle mit der benötigten Capability.
  • Kontrollieren Sie Nonce, Authorization-Header und HTTPS bis zum WordPress-Prozess.
  • Suchen Sie in Security-Plugins, CDN und WAF nach einer konkreten Regel für /wp-json/.
  • Legen Sie eine enge Ausnahme nur für die benötigte Route und Methode an.

Fehler 500 oder HTML statt JSON: Konflikt sauber isolieren

Ein 500-Status weist auf einen Fehler während der Verarbeitung hin. Eine HTML-Antwort kann zusätzlich zeigen, dass ein Proxy, eine Firewall oder eine Fehlerseite vor WordPress antwortet. Halten Sie Zeitpunkt, URL, Methode, Status und Request-ID fest. Prüfen Sie dann PHP-Log, WordPress-Debug-Log und Serverlog für genau diesen Aufruf.

Deaktivieren Sie Plugins nicht ungeplant auf der Live-Website. Reproduzieren Sie den Fehler in einer Staging-Umgebung, wechseln Sie dort auf ein Standard-Theme und aktivieren Sie Erweiterungen schrittweise. So bleibt erkennbar, welche Änderung den Fehler verursacht. Nach dem Test werden Debug-Ausgabe und zusätzliche Protokollierung wieder deaktiviert.

Mehr technische Entscheidungs- und Fehlerleitfäden sammeln wir im Devvibe Magazin.

Eigene REST-Routen korrekt registrieren

Für eine eigene Integration registrieren Sie die Route am Hook rest_api_init, verwenden einen eindeutigen Namespace und definieren die erlaubten Methoden. Jede Route braucht eine permission_callback. Der Callback entscheidet anhand von Anmeldung und Capabilities, nicht anhand eines leicht fälschbaren Parameters.

Validieren und bereinigen Sie Eingaben, bevor Sie Daten verarbeiten. Antworten Sie mit passenden HTTP-Statuscodes und einem stabilen Fehlercode. Das macht die Integration testbar und verhindert, dass Frontend, App oder Drittsystem auf wechselnde Fehlermeldungen reagieren müssen.

Minimales Beispiel im Plugin
add_action( 'rest_api_init', function () {
  register_rest_route( 'devvibe/v1', '/status', [
    'methods'  => 'GET',
    'callback' => 'devvibe_status_response',
    'permission_callback' => '__return_true',
  ] );
} );

Wenn die API Teil eines größeren Produkts ist, sollte sie gemeinsam mit Datenmodell, Oberfläche und Betrieb als Software oder MVP geplant werden.

Reihenfolge für eine sichere Fehlerbehebung

Beginnen Sie mit einer anonymen Leseanfrage. Prüfen Sie danach die konkrete Route, Authentifizierung und Berechtigung. Erst wenn der Status eingeordnet ist, ändern Sie Permalinks, Plugin-Konfiguration oder Serverregeln. Nach jeder Änderung wiederholen Sie denselben Request. So bleibt die Ursache nachvollziehbar.

  • API-Wurzel und Fallback-URL testen.
  • Statuscode, Content-Type und WordPress-Fehlercode notieren.
  • Öffentlichen und geschützten Endpunkt unterscheiden.
  • Änderung zuerst in Staging durchführen und einzeln testen.
  • Nur die betroffene Route, Methode oder Regel korrigieren.
  • Nach erfolgreichem Test Logs sichern und Debug-Modus beenden.

Die gleiche Systemfrage entscheidet oft auch bei Shops über den richtigen Betrieb. Der Beitrag Shopify vs. WooCommerce vergleicht dabei Kontrolle und Wartungsaufwand.

Offizielle Quellen

Die folgenden Primärquellen beschreiben die REST API, ihre Authentifizierung, eigene Endpunkte und das kontrollierte Leeren von Rewrite-Regeln. Prüfen Sie bei sicherheitsrelevanten Änderungen immer die Dokumentation Ihrer eingesetzten WordPress-Version und Ihrer Hosting-Umgebung.

WordPress Developer Resources: REST API Handbook

WordPress Developer Resources: Authentication

WordPress Developer Resources: Adding Custom Endpoints

WordPress Developer Resources: wp rewrite flush