PAGUP Agent ControlAccès WordPress pour les assistants IA
Essayer gratuitement

Une incohérence entre l’adresse web de WordPress et l’adresse du site bloque les connexions IA

L’adresse web de WordPress et l’adresse du site utilisent des schémas, hôtes ou chemins différents.

Comparez l’adresse web de WordPress, l’adresse du site, l’hôte canonique public et l’adresse de base REST.

Causes probables

  • L’adresse web de WordPress et l’adresse du site utilisent des schémas, hôtes ou chemins différents.
  • Une redirection change le schéma, l’hôte ou le chemin et peut aussi supprimer les en-têtes d’authentification.
  • Le navigateur utilise HTTPS, mais WordPress ne considère pas la requête reçue à l’origine comme sécurisée.
  • Le client appelle le mauvais domaine, chemin de base, point de terminaison REST ou point de terminaison MCP.
  • La configuration des permaliens ou des réécritures empêche la résolution du chemin de base REST attendu.

Séquence de diagnostic

  1. Comparez l’adresse web de WordPress, l’adresse du site, l’hôte canonique public et l’adresse de base REST.
  2. Suivez chaque redirection et vérifiez la conservation du schéma, de l’hôte, du chemin et de l’en-tête Authorization.
  3. Confirmez que WordPress lui-même considère la requête comme HTTPS, et pas seulement le navigateur.
  4. Interrogez l’index REST WordPress et confirmez la présence des espaces de noms et des métadonnées d’authentification attendus.
  5. Confirmez le schéma, l’hôte, le chemin de base et le point de terminaison exacts configurés dans le client.
  6. Consignez les versions de WordPress, de l’extension, du client, du connecteur et du serveur avant toute modification.

Appliquer le correctif minimal

  1. Alignez l’adresse web de WordPress, l’adresse du site, l’hôte public, le schéma HTTPS et l’adresse de base REST.
  2. Supprimez ou corrigez la redirection qui modifie la requête authentifiée de manière inattendue.
  3. Corrigez la gestion du proxy approuvé et de l’origine afin que WordPress reconnaisse fiablement la requête HTTPS initiale.
  4. Rétablissez la route REST ou la disponibilité requise tout en conservant l’authentification et les contrôles de permission.
  5. Corrigez le point de terminaison, le transport, le nom d’outil ou la référence d’identifiant sans élargir les permissions WordPress.

Vérifier le résultat

  • La requête authentifiée atteint le point de terminaison canonique sans redirection inattendue.
  • L’index REST répond depuis l’URL HTTPS canonique et expose les espaces de noms attendus.
  • La requête authentifiée correspond à l’utilisateur WordPress dédié prévu.
  • La lecture étroite approuvée réussit avec une réponse reproductible.

Ce qu’il ne faut pas faire

  • Ne modifiez pas le cœur de WordPress ou les fichiers d’une extension tierce comme première étape de diagnostic.
  • N’ajoutez pas un contournement permanent et non vérifié du proxy avant de confirmer le chemin approuvé de la requête.
  • N’accordez pas un accès administrateur uniquement pour réussir un test de connexion.
  • Ne désactivez pas globalement le WAF ou l’extension de sécurité pour contourner une seule requête.
  • Ne placez jamais un mot de passe d’application, un en-tête Authorization, un jeton ou un témoin dans une invite, un billet, un extrait de journal ou une capture.

Guides connexes

Sources et vérification

Cette page a été vérifiée à partir des sources primaires suivantes. Dernière révision des sources: .