Abweichende WordPress Home URL und Site URL verhindern KI-Verbindungen
WordPress Home URL und Site URL verwenden unterschiedliche Schemata, Hosts oder Pfade.
Vergleichen Sie Home URL, Site URL, öffentlichen kanonischen Host und REST-Basisadresse.
Wahrscheinliche Ursachen
- WordPress Home URL und Site URL verwenden unterschiedliche Schemata, Hosts oder Pfade.
- Eine Weiterleitung ändert Schema, Host oder Pfad und kann Authentifizierungsheader verlieren.
- Der Browser nutzt HTTPS, aber WordPress erkennt die Anfrage am Origin nicht als sicher.
- Der Client ruft falsche Domain, Basispfad, REST-Route oder MCP-Endpunkt auf.
- Permalink- oder Rewrite-Konfiguration verhindert die Auflösung des erwarteten REST-Basispfads.
Diagnosereihenfolge
- Vergleichen Sie Home URL, Site URL, öffentlichen kanonischen Host und REST-Basisadresse.
- Verfolgen Sie jede Weiterleitung und prüfen Sie Schema, Host, Pfad und Authorization.
- Prüfen Sie, ob WordPress selbst die Anfrage als HTTPS erkennt, nicht nur der Browser.
- Rufen Sie den REST-Index ab und prüfen Sie erwartete Namespaces und Authentifizierungsmetadaten.
- Bestätigen Sie Schema, Host, Basispfad und Endpunkt in der Client-Konfiguration.
- Dokumentieren Sie WordPress-, Plugin-, Client-, Connector- und Serverversionen vor jeder Änderung.
Die kleinste passende Korrektur anwenden
- Richten Sie Home URL, Site URL, öffentlichen Host, HTTPS-Schema und REST-Basis aus.
- Entfernen oder korrigieren Sie die unerwartet verändernde Weiterleitung.
- Korrigieren Sie vertrauenswürdige Proxy- und Origin-Verarbeitung, damit WordPress die ursprüngliche HTTPS-Anfrage erkennt.
- Stellen Sie erforderliche REST-Route oder Verfügbarkeit mit Authentifizierung und Permission Callbacks wieder her.
- Korrigieren Sie Endpunkt, Transport, Toolname oder Credential-Referenz ohne Berechtigungen zu erweitern.
Ergebnis überprüfen
- Die authentifizierte Anfrage erreicht den kanonischen Endpunkt ohne unerwartete Weiterleitung.
- Der REST-Index antwortet über die kanonische HTTPS-URL und zeigt erwartete Namespaces.
- Die authentifizierte Anfrage entspricht dem vorgesehenen dedizierten Benutzer.
- Der genehmigte enge Lesezugriff liefert reproduzierbar eine Antwort.
Was Sie nicht tun sollten
- Bearbeiten Sie WordPress Core oder Drittanbieter-Plugin-Dateien nicht als ersten Diagnoseschritt.
- Fügen Sie keinen ungeprüften dauerhaften Proxy-Workaround vor Bestätigung des Vertrauenspfads hinzu.
- Vergeben Sie keinen Administratorzugriff nur damit ein Verbindungstest gelingt.
- Deaktivieren Sie WAF oder Sicherheits-Plugin nicht global für eine einzelne Anfrage.
- Teilen Sie kein Application Password, keinen Authorization-Header, Token oder Cookie in Prompt, Ticket, Log oder Screenshot.
Verwandte Leitfäden
- Weiterleitungsschleife bei einer WordPress-KI-Verbindung: HTTP, HTTPS und kanonische URL
- WordPress erkennt HTTPS hinter Cloudflare oder einem Reverse Proxy nicht
- WordPress /wp-json/ liefert 404: REST-API-Diagnose
- Warum WAP AI Assistant auf einer HTTPS-Website eine HTTPS-Warnung anzeigt
- WordPress-Anwendungspasswörter für KI-Verbindungen
Quellen und Überprüfung
Diese Seite wurde anhand der folgenden Primärquellen überprüft. Letzte Quellenprüfung: .
- home_url() · WordPress Developer Resources
- site_url() · WordPress Developer Resources
- is_ssl() · WordPress Developer Resources
- Routes and Endpoints · WordPress Developer Resources