Comment créer un inventaire d’URL WordPress avec l’IA

Un inventaire d’URL constitue le socle factuel de la plupart des travaux de SEO et de migration WordPress. L’IA peut normaliser des exportations et classer des tendances, mais elle ne peut pas déduire un site complet à partir de la première page d’une réponse d’API ou d’un seul plan de site. Construisez l’inventaire à partir de plusieurs sources nommées et préservez les divergences.

L’analyse SEO n’est fiable qu’à la hauteur des éléments probants fournis. Un modèle de langage ne connaît pas indépendamment l’état d’exploration, l’indexation, les classements, la sélection canonique ou la performance des pages. Traitez-le comme un organisateur de preuves et un générateur d’hypothèses, puis vérifiez chaque constat dans le système source approprié.

En une phrase : créez une ligne stable par URL découverte, conservez chaque source qui l’a signalée et indiquez les conflits au lieu de choisir silencieusement une valeur.

Ce que ce guide vous aide à accomplir

Le résultat doit fournir une vue traçable des URL publiques, privées, redirigées et manquantes, avec les ID WordPress lorsqu’ils sont disponibles. Il doit soutenir les audits ultérieurs sans prétendre qu’une seule source de données représente l’ensemble du site.

Un résultat utile ne se limite pas à une réponse soignée. Il doit montrer quels enregistrements ou pages ont été examinés, quelles preuves n’étaient pas disponibles, ce que l’assistant a déduit, ce qu’un humain doit décider et quelles actions demeurent interdites.

Ce qu’un résultat réussi doit contenir

• Un enregistrement d’URL normalisée avec toutes les variantes source observées.
• L’ID de contenu WordPress, le type, l’état, la langue et les dates lorsqu’ils sont disponibles.
• Les preuves HTTP, canoniques, de plan de site et de politique d’indexation lorsqu’elles sont fournies.
• Des indicateurs de présence source montrant où chaque URL a été découverte.
• Des champs de conflit et de données manquantes.
• Une portée d’inventaire et une date d’extraction clairement définies.

Preuves et intrants à préparer

WordPress, les plans de site, les explorateurs et les systèmes d’analytique répondent à des questions différentes. Joignez-les sans effacer les différences.

• Des exportations complètes et paginées des articles, pages et types de contenu personnalisés de WordPress.
• Tous les plans de site XML et index de plans de site.
• Une exportation d’exploration avec l’URL finale, l’état et les champs canoniques.
• Une carte de redirections ou des données serveur lorsqu’elles sont disponibles.
• Des exportations de pages de Search Console et d’analytique lorsqu’elles sont pertinentes.
• Des correspondances de langue, de section du site et de responsable du contenu.
• Des règles de normalisation d’URL approuvées pour le projet.

Consignez la date, la source, la portée et les omissions connues pour chaque intrant. Retirez les identifiants, les renseignements personnels et les données clients qui ne sont pas nécessaires à la tâche.

Conservez les sources de découverte comme preuves distinctes

Une URL dans WordPress mais absente du plan de site n’est pas automatiquement une erreur. Une URL dans les données d’analytique mais absente de WordPress peut être redirigée, externe, historique ou générée. Conservez des indicateurs comme in_wordpress, in_sitemap, in_crawl et in_search_data avant de les interpréter.

Normalisez sans masquer les différences

La normalisation de la casse, de la barre oblique finale, du protocole, de l’hôte et des paramètres de requête peut empêcher les doubles comptes. Conservez à la fois la valeur brute et la clé normalisée afin que les réviseurs puissent examiner ce qui a été modifié. Ne supprimez pas les paramètres avant de connaître leur fonction.

Un flux de travail sûr

1. Déclarez les hôtes, protocoles, langues et types de contenu inclus.
2. Exportez chaque source avec les dates et les preuves de pagination.
3. Stockez les URL brutes avant d’appliquer les règles de normalisation.
4. Créez une clé d’URL normalisée et des indicateurs de présence source.
5. Joignez les ID WordPress, les états, les résultats HTTP, les canoniques et les preuves de plan de site.
6. Demandez à l’assistant de classer les conflits et les champs manquants.
7. Examinez manuellement les écarts à fort impact.
8. Figez l’instantané de l’inventaire pour les travaux en aval.
9. Créez des tâches distinctes pour les redirections, les canoniques ou les changements de contenu.

Le flux de travail sépare intentionnellement l’analyse de l’implémentation. Une étape ultérieure de changement devrait référer au résultat approuvé plutôt que d’élargir discrètement les permissions de l’identité analytique.

Modèle de prompt

Avant d’utiliser ce prompt, remplacez chaque valeur entre crochets. Ne collez pas de mots de passe, de clés API, de dossiers clients privés ni de renseignements personnels sans rapport dans l’instruction.

Créez un inventaire d’URL WordPress normalisé à partir des fichiers sources fournis.

Retournez une ligne par URL normalisée avec :
- URL normalisée et toutes les variantes brutes
- Hôte, chemin, requête et langue
- ID WordPress, type de contenu et état
- Dates de publication et de modification
- Présence dans WordPress, le plan de site, l’exploration, Search Console, l’analytique et la carte de redirections
- État HTTP et URL finale lorsqu’ils sont fournis
- Canonique déclarée lorsqu’elle est fournie
- Classe de conflit et preuves manquantes
- Priorité de révision et justification

Règles :
1. Ne supposez pas qu’une source est complète.
2. Préservez les valeurs brutes et les dates sources.
3. Ne supprimez pas les paramètres sans règle approuvée.
4. N’inventez pas de données HTTP, canoniques ou d’indexation.
5. Ne modifiez pas WordPress, les redirections ou les plans de site.

Pourquoi ce prompt est structuré ainsi

Le modèle de présence source crée une jointure vérifiable au lieu d’une feuille de calcul plate qui masque les contradictions. Les variantes brutes et les clés normalisées permettent de contester la déduplication.

Limite d’accès recommandée

Utilisez une identité Read Only. L’assistant peut inspecter les enregistrements WordPress inclus dans la portée, mais les tentatives de créer, modifier, supprimer ou publier du contenu doivent être refusées.

Le flux de travail recommandé présente un faible risque lorsque les données source sont délimitées et qu’aucune permission d’écriture n’est accordée. Un faible risque ne signifie pas une absence de révision.

Ce qui doit rester hors de cette tâche

• Aucune redirection, aucun changement canonique, noindex ou aucune suppression.
• Aucune affirmation que l’absence d’un plan de site signifie une désindexation.
• Aucune hypothèse que la pagination de l’API est complète sans preuves.
• Aucune suppression de paramètres de requête avant que leur rôle soit connu.
• Aucun état HTTP ou URL finale déduit.

Le niveau d’accès est une recommandation de départ, et non une permission universelle. Les capacités exactes disponibles pour une identité doivent provenir de la version de produit installée et de sa couverture publiée.

Comment WP Agent Control s’intègre

Ce guide décrit un travail général dans WordPress, sans promettre qu’Agent Control peut modifier chaque objet ou intégration abordé. Dans le parcours guidé, commencez par les pages publiques. Les opérations sur les plugins, thèmes, utilisateurs, réglages, fichiers, suppressions, WooCommerce, ACF et constructeurs ne sont pas des tâches guidées natives. Utilisez des outils et permissions qualifiés séparément au besoin.

Obtenez des informations structurées sur le site et examinez des pages publiées après la connexion. Cette lecture publique ne nécessite aucune tâche temporaire. Vous pouvez aussi consulter les pages publiques sans le plugin ; Agent Control ajoute un accès structuré et la continuité vers du travail WordPress autorisé.

Connecter votre IA : docs first profile · Voir les fonctions et la compatibilité : coverage

Liste de vérification

• ☐ Chaque source a une date et une portée.
• ☐ L’achèvement de la pagination est documenté.
• ☐ Les valeurs d’URL brutes et normalisées sont toutes deux conservées.
• ☐ Les conflits entre sources restent visibles.
• ☐ Les ID WordPress sont conservés lorsqu’ils sont disponibles.
• ☐ Aucun état d’URL n’a changé durant la création de l’inventaire.

Modes de défaillance courants

• Plan de site égal au site : l’inventaire exclut des URL valides qui ne figurent pas dans le plan de site.
• Exportation de la première page d’API : la pagination est omise et le résultat est faussement déclaré complet.
• Normalisation destructive : des paramètres ou des différences de chemin sont écartés avant révision.
• Effacement des conflits : une source remplace silencieusement une autre.

Note avancée

Utilisez des instantanés d’inventaire immuables avec des ID d’URL stables. Les explorations ultérieures et les cartes de migration peuvent référer à la même identité, ce qui permet à l’équipe d’observer les transitions d’état sans réécrire les preuves historiques.

Guides connexes

• Comment inventorier le contenu WordPress avec l’IA
• Comment réaliser un audit SEO WordPress en lecture seule avec l’IA
• Comment trouver des pages WordPress orphelines avec l’IA
• Comment trouver du contenu WordPress dupliqué ou qui se chevauche avec l’IA

Prochaine étape

Utilisez l’inventaire figé pour l’analyse des pages orphelines, la révision des recouvrements et l’audit SEO plus large.