AIでWordPressのURLインベントリを作成する方法

URLインベントリは、WordPressのSEOと移行作業の大半における事実上の基盤です。AIはエクスポートを正規化し、パターンを分類できますが、API応答の最初のページやサイトマップだけから完全なサイトを推論することはできません。複数の名前付きソースからインベントリを作成し、不一致を保持してください。

SEO分析の信頼性は、提供された証拠の信頼性を超えません。言語モデルは、クロール状態、インデックス登録、順位、正規URLの選択、ページパフォーマンスを独自に把握していません。証拠の整理役と仮説の生成役として扱い、各所見を適切なソースシステムで検証してください。

一文で言うと: 発見したURLごとに安定した行を作成し、それを報告したすべてのソースを保持し、値を黙って選ぶのではなく競合を記録します。

このガイドで達成できること

出力は、公開、非公開、リダイレクト済み、欠落したURLを追跡可能に示し、利用可能な場合はWordPress IDを含める必要があります。単一のデータソースがサイト全体を表すと装わずに、その後の監査を支援する必要があります。

有用な結果は、洗練された回答だけではありません。調査したレコードやページ、利用できなかった証拠、アシスタントが推論した内容、人間が決定すべき内容、禁止されたままの操作を示す必要があります。

成功する出力に必要な内容

  • 観測したすべてのソースバリアントを含む、正規化済みURLレコード。
  • 利用可能な場合のWordPressコンテンツID、種類、状態、言語、日付。
  • 提供された場合のHTTP、正規URL、サイトマップ、インデックス登録ポリシーの証拠。
  • 各URLをどこで発見したかを示すソース存在フラグ。
  • 競合と欠落データのフィールド。
  • 明確に定義されたインベントリ範囲と抽出日。

準備する証拠と入力

WordPress、サイトマップ、クローラー、分析システムは異なる質問に答えます。違いを消さずに結合してください。

  • 完全にページネーションされたWordPress投稿、固定ページ、カスタム投稿タイプのエクスポート。
  • すべてのXMLサイトマップとサイトマップインデックス。
  • 最終URL、状態、正規URLフィールドを含むクロールエクスポート。
  • 利用可能な場合のリダイレクトマップまたはサーバーデータ。
  • 関連する場合のSearch Consoleおよび分析のページエクスポート。
  • ロケール、サイトセクション、コンテンツ所有者のマッピング。
  • プロジェクトで承認されたURL正規化ルール。

各入力について日付、ソース、範囲、既知の除外を記録してください。タスクに不要な認証情報、個人情報、顧客データは削除してください。

発見ソースを個別の証拠として保持する

WordPressにあるがサイトマップにないURLは、自動的にエラーではありません。分析データにあるがWordPressにないURLは、リダイレクト済み、外部、過去のもの、または生成されたものかもしれません。解釈する前に、in_wordpressin_sitemapin_crawlin_search_dataのようなフラグを保持してください。

違いを隠さずに正規化する

大文字小文字、末尾スラッシュ、プロトコル、ホスト、クエリの正規化は重複カウントを防げます。レビュー担当者が変更内容を確認できるよう、生の値と正規化キーの両方を保持してください。機能が分かるまでパラメータを削除しないでください。

安全なワークフロー

  1. 対象に含めるホスト、プロトコル、ロケール、コンテンツタイプを宣言します。
  2. 日付とページネーションの証拠を含めて各ソースをエクスポートします。
  3. 正規化ルールを適用する前に生のURLを保存します。
  4. 正規化URLキーとソース存在フラグを作成します。
  5. WordPress ID、状態、HTTP結果、正規URL、サイトマップ証拠を結合します。
  6. 競合と欠落フィールドの分類をアシスタントに依頼します。
  7. 影響の大きい不一致を手動でレビューします。
  8. 後続作業のためにインベントリスナップショットを固定します。
  9. リダイレクト、正規URL、コンテンツ変更には別のタスクを作成します。

このワークフローは、分析と実装を意図的に分離します。後続の変更段階は、分析用アイデンティティの権限を黙って広げるのではなく、承認済みの出力を参照する必要があります。

プロンプトのテンプレート

このプロンプトを使用する前に、角括弧内のすべての値を置き換えてください。パスワード、APIキー、非公開の顧客レコード、無関係な個人情報を指示に貼り付けないでください。

提供されたソースファイルから、正規化済みのWordPress URLインベントリを作成してください。

正規化URLごとに次を含む行を返してください:
- 正規化URLとすべての生のバリアント
- ホスト、パス、クエリ、ロケール
- WordPress ID、コンテンツタイプ、状態
- 公開日と更新日
- WordPress、サイトマップ、クロール、Search Console、分析、リダイレクトマップへの存在
- 提供された場合のHTTP状態と最終URL
- 提供された場合の宣言済み正規URL
- 競合クラスと欠落した証拠
- レビュー優先度と根拠

ルール:
1. どのソースも完全だと仮定しないでください。
2. 生の値とソース日付を保持してください。
3. 承認済みルールなしにパラメータを削除しないでください。
4. HTTP、正規URL、インデックス登録データを捏造しないでください。
5. WordPress、リダイレクト、サイトマップを変更しないでください。

このプロンプトがこの構造である理由

ソース存在モデルは、矛盾を隠す平坦なスプレッドシートではなく、監査可能な結合を作成します。生のバリアントと正規化キーにより、重複排除に異議を唱えられます。

推奨アクセス境界

Read Onlyアイデンティティを使用してください。アシスタントは範囲内のWordPressレコードを検査できますが、コンテンツの作成、編集、削除、公開の試みは拒否される必要があります。

ソースデータの範囲が限定され、書き込み権限が与えられていない場合、推奨ワークフローのリスクは低いものです。リスクが低いことは、レビューが不要であることを意味しません。

このタスクの対象外に残すもの

  • リダイレクト、正規URL、noindex変更、削除は行いません。
  • サイトマップにないことがインデックス削除を意味するという主張はしません。
  • 証拠なしにAPIページネーションが完全だと仮定しません。
  • 役割が判明する前にクエリパラメータを削除しません。
  • HTTP状態や最終URLを推論しません。

アクセスレベルは開始時の推奨であり、普遍的な権利ではありません。アイデンティティで利用可能な正確な機能は、インストール済み製品バージョンと公開済みの対象範囲から得る必要があります。

WP Agent Controlの位置付け

これはWordPressの一般的な作業手順であり、Agent Controlがここで扱うすべての対象や連携機能を編集できるという意味ではありません。ガイド付き手順では、まず公開ページから始めます。プラグイン、テーマ、ユーザー、設定、ファイル、削除、WooCommerce、ACF、ページビルダーの操作は、標準のガイド付きタスクではありません。必要に応じて、別途検証されたツールと権限を使ってください。

接続後は、サイトの構造化情報を取得し、選択した公開ページを調べられます。この公開情報の読み取りに一時タスクは不要です。公開ページはプラグインなしでも閲覧できます。Agent Control は構造化されたアクセスと、その先の許可された WordPress 作業への流れを提供します。

AI を接続する: docs first profile · 機能と対応環境を見る: coverage

検証チェックリスト

  • 各ソースに日付と範囲があります。
  • ページネーション完了が文書化されています。
  • 生のURL値と正規化URL値の両方が保持されています。
  • ソース間の競合が見える状態です。
  • 利用可能なWordPress IDが保持されています。
  • インベントリ作成中にURL状態は変更されていません。

よくある失敗モード

  • サイトマップがサイトそのもの: インベントリが、サイトマップに記載されていない有効なURLを除外します。
  • 最初のAPIページのエクスポート: ページネーションが見落とされ、結果が誤って完全と呼ばれます。
  • 破壊的な正規化: パラメータまたはパスの違いがレビュー前に破棄されます。
  • 競合の消去: 一方のソースが他方を黙って上書きします。

発展的な注記

安定したURL IDを持つ不変のインベントリスナップショットを使用してください。後続のクロールと移行マップは同じアイデンティティを参照でき、チームは履歴証拠を書き換えずに状態遷移を観察できます。

関連ガイド

次のステップ

固定したインベントリを、孤立ページ分析重複範囲レビューより広範なSEO監査に使用してください。

情報源と検証

このページは、以下の一次情報源に基づいて確認されています。 情報源の最終確認日: .