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

  1. Vergleichen Sie Home URL, Site URL, öffentlichen kanonischen Host und REST-Basisadresse.
  2. Verfolgen Sie jede Weiterleitung und prüfen Sie Schema, Host, Pfad und Authorization.
  3. Prüfen Sie, ob WordPress selbst die Anfrage als HTTPS erkennt, nicht nur der Browser.
  4. Rufen Sie den REST-Index ab und prüfen Sie erwartete Namespaces und Authentifizierungsmetadaten.
  5. Bestätigen Sie Schema, Host, Basispfad und Endpunkt in der Client-Konfiguration.
  6. Dokumentieren Sie WordPress-, Plugin-, Client-, Connector- und Serverversionen vor jeder Änderung.

Die kleinste passende Korrektur anwenden

  1. Richten Sie Home URL, Site URL, öffentlichen Host, HTTPS-Schema und REST-Basis aus.
  2. Entfernen oder korrigieren Sie die unerwartet verändernde Weiterleitung.
  3. Korrigieren Sie vertrauenswürdige Proxy- und Origin-Verarbeitung, damit WordPress die ursprüngliche HTTPS-Anfrage erkennt.
  4. Stellen Sie erforderliche REST-Route oder Verfügbarkeit mit Authentifizierung und Permission Callbacks wieder her.
  5. 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

Quellen und Überprüfung

Diese Seite wurde anhand der folgenden Primärquellen überprüft. Letzte Quellenprüfung: .