redirect-manager

/digital-marketing-pro:redirect-manager

スクリプトの場所。 ホストで ${CLAUDE_PLUGIN_ROOT} が設定されていない場合、スクリプトは skills/ と同じ階層にあるこのプラグインの scripts/ フォルダー内にあります。Python 3.10 以降で実行してください。python を使用するか、python が見つからない場合（macOS、多くの Linux システム）は python3 を使用します。

目的

ウェブサイト全体の URL リダイレクトを管理します。新しい 301／302 リダイレクトの作成、既存リダイレクトのチェーンやループの監査、壊れたリダイレクト経路の修正、接続済み CMS MCP を介した変更のデプロイを行います。サイト移行、URL 構造の変更、継続的なリダイレクトのメンテナンスに対応します。リダイレクトの管理不備は、SEO トラフィック損失の最も一般的な原因の 1 つです。チェーンはリンクエクイティを低下させ、ループはクロールエラーを引き起こし、壊れたリダイレクトは、以前インデックスされていた URL に対して 404 を返します。このコマンドは、作成から監査、修復まで、リダイレクトのライフサイクルを体系的に管理します。

実行ゲート（必須 — 省略不可）

1. ライブのルールに触れる前に、作成／更新／削除するすべてのリダイレクトについて、現在の状態と提案する状態、およびサイト全体への影響範囲を含む完全なプレビューを 実行サマリー として提示してください。
2. ユーザーは yes（または同等の明示的な承認）を入力する必要があります。それ以外の入力（曖昧な入力、暗黙の承認、部分的な承認、または承認なし）の場合は、実行をキャンセルします。
3. 曖昧な入力に基づいて処理を進めてはいけません。失敗した実行を自動で再試行してはいけません。再実行の前に、人による確認が必要です。
4. ユーザーが yes を入力した後に限り、次のコマンドを実行して記録します。python "${CLAUDE_PLUGIN_ROOT}/scripts/approval-manager.py" --brand {slug} --action create-approval --data '{"type":"redirect-manager","platform":"<platform>","content_summary":"<one line from the Execution Summary>","risk_level":"<tier>"}' の後に、python "${CLAUDE_PLUGIN_ROOT}/scripts/approval-manager.py" --brand {slug} --action approve --id {approval_id} を実行します。どちらかのコマンドでエラーが発生した場合は、停止してエラーを報告してください。別のツールで回避してはいけません。この記録は、この操作について承認手順が実行されたことを証明しますが、誰が yes を入力したかは証明できません。
5. 実行します。connector_executor.py を介して送信する書き込みには --approval-id が必要で、一致する未使用かつ有効期限内の記録がある場合にのみ実行されます（/digital-marketing-pro:execute-action を参照）。接続済み MCP サーバーツールを介した書き込みは、このコードによるチェックの対象外です。入力された yes と、ホストの権限確認プロンプトに依存します。その後、python "${CLAUDE_PLUGIN_ROOT}/scripts/approval-manager.py" --brand {slug} --action mark-executed --id {approval_id} --data '{"execution_result":"success"}'（または failure）を実行します。

必要な入力

ユーザーは次の情報を提供する必要があります（または入力を求められます）。

• リダイレクト操作：実行する操作です。create（新しいリダイレクトを設定）、audit（既存のすべてのリダイレクトをスキャンして問題を検出）、fix（監査で見つかったチェーン、ループ、壊れたターゲットを解決）、または bulk-import（移行用の CSV または Google Sheet からリダイレクトマップをインポート）を指定します。複数の操作を連続して実行できます（例：audit の後に fix）
• ソース URL：create と bulk-import では、リダイレクト元の URL を指定します。完全一致の URL、ワイルドカードを含む URL パターン（例：/old-blog/* から /blog/*）、または複雑なマッチング用の正規表現パターンを指定できます。audit と fix では、ソース URL が CMS から自動的に検出されます
• ターゲット URL：create と bulk-import では、ユーザーと検索エンジンの転送先 URL を指定します。200 ステータスコードを返す、有効でアクセス可能な URL でなければなりません。bulk-import では、インポートファイル内でソースとターゲットのペアとして指定します
• リダイレクトの種類：301（恒久的。恒久的な URL 変更、ドメイン移行、HTTPS へのアップグレード、URL 構造の変更に使用）または 302（一時的。A/B テスト、季節限定コンテンツ、メンテナンスページ、地域別リダイレクトに使用）を指定します。指定がない場合のデフォルトは 301 です
• CMS プラットフォーム：wordpress または webflow を指定します。対応する CMS MCP サーバーが接続されている必要があります。WordPress の場合は、リダイレクト管理方法として Redirection プラグイン、RankMath redirects、Yoast Premium redirects、または .htaccess による直接設定を指定します。Webflow では、標準のリダイレクト API が使用されます

Process

1. ブランドのコンテキストを読み込む：アクティブなスラッグを確認するため、~/.claude-marketing/brands/_active-brand.json を読み込み、その後 ~/.claude-marketing/brands/{slug}/profile.json を読み込みます。ブランドのトーン、対象市場のコンプライアンスルール（skills/context-engine/compliance-rules.md）、業界のコンテキストを適用します。また、~/.claude-marketing/brands/{slug}/guidelines/_manifest.json にガイドラインがあるか確認し、存在する場合は制限事項を読み込みます。~/.claude-marketing/sops/ に代理店の SOP があるかも確認します。ブランドが存在しない場合は、「先にブランドを設定しますか（/digital-marketing-pro:brand-setup）？」と尋ねるか、デフォルト設定で進めます。
2. 作成時：ソース URL とターゲット URL を検証する：ソース URL が存在するか、以前にインデックス登録されているかを確認します（過去のデータについて GSC を確認します）。ターゲット URL が有効で、ステータスコード 200 を返すことを検証し、重複を避けるため、ソース URL に既存のリダイレクトが設定されていないか確認します。また、提案されたリダイレクトがチェーンを作成しないか（ソースが中間 URL にリダイレクトされ、その URL も別の場所へリダイレクトされる状態）を確認します。一括インポートの場合は、インポートファイル内のすべてのソースとターゲットの組み合わせを検証し、進行前に問題を報告します。
3. 監査時：既存のリダイレクトをすべてクロールする：CMS API に問い合わせ、設定済みのリダイレクトルールをすべて取得します。各リダイレクトについて、最終的な転送先までたどり、リダイレクト経路全体をテストします。チェーン（1 ホップを超えるもの。例：A が B にリダイレクトされ、B が C にリダイレクトされる）、ループ（A が B にリダイレクトされ、B が A にリダイレクトされるなどの循環経路）、4xx または 5xx エラーページを指すリダイレクト、クロールバジェットを浪費するリダイレクトから別のリダイレクトへのパターン、プロトコルが混在するリダイレクト（HTTP から HTTPS を経て HTTP へ戻るもの）、クエリパラメーターを過剰に処理するリダイレクトを検出します。
4. 修正時：検出した問題を解決する：チェーンの場合は、最初のリダイレクトが中間ホップを経由せず、最終的な転送先 URL を直接指すように更新します。ループの場合は、正しい最終的な転送先を特定し、ループしているルールを更新または削除して循環を断ちます。リンク切れのターゲットの場合は、URL の変更、アーカイブ済みコンテンツ、差し替えページを確認して、適切な有効な転送先を特定し、リダイレクトを更新します。明確な転送先がない場合は、手動確認のために報告します。重複の場合は、最も新しく作成されたルール、または最も具体的に一致するルールを残し、冗長なルールを削除します。
5. 承認ゲートを作成する：提案するすべてのリダイレクト変更について、現在の状態と提案する状態を提示します。新規作成するリダイレクト（ソース、ターゲット、種類）、チェーンの修正（現在の経路と、ホップ削減数を示した簡略化後の経路）、ループの解消（循環を断ち切る新しいターゲット）、リンク切れターゲットの更新（古い無効なターゲットと新しい有効なターゲット）を含めます。リスクを評価します。個別のリダイレクト作成や小規模な修正（変更 10 件未満）は medium、一括インポート、移行規模の変更（リダイレクト 10 件超）、または既存のリダイレクトルールの削除は high とします。
6. CMS MCP 経由で実行する：承認後、接続された CMS MCP を通じてリダイレクトの変更を適用します。WordPress の場合は、Redirection プラグインの REST API（ログ記録とモニタリングのため推奨）、RankMath のリダイレクトモジュール、Yoast Premium のリダイレクトマネージャー、または .htaccess の直接編集（バックアップを取ったうえでの最終手段）を使ってルールを作成または更新します。Webflow の場合は、移行時に一括処理をサポートするネイティブの 301 リダイレクト API を使います。Webflow の 301 のみという制約、WordPress プラグインごとのルール形式、パターンマッチング構文の違いなど、CMS 固有の制約に対応します。
7. デプロイ後に検証する：作成または変更したすべてのリダイレクトについて、ソース URL に HTTP リクエストを送信し、レスポンスコード（301 または 302）と最終的な転送先が仕様と一致することを確認します。チェーンの修正では、リダイレクトが 1 ホップで解決されることを検証します。ループの修正では、リダイレクトが 200 のページに到達することを検証します。検証に失敗した場合は、直ちに調査できるよう報告します。
8. seo-executor.py を使ってすべての変更を記録する：すべてのリダイレクト変更について、タイムスタンプ、アクションの種類（作成、更新、削除）、ソース URL、ターゲット URL、リダイレクトの種類、（更新や修正の場合は）変更前の状態、使用した CMS プラットフォームと方法、検証結果、ロールバック手順を記録します。一括操作では、必要に応じて完全にロールバックできるよう、変更前のリダイレクト状態をすべて保存します。

出力

以下を含む、構造化されたリダイレクト管理レポートです。

• リダイレクト変更の確認：作成、更新、削除されたすべてのリダイレクトについて、ソース URL、ターゲット URL、リダイレクトタイプ（301/302）、実行した操作（新規、チェーン修正、ループ解消、ターゲット更新）、および変更時の変更前と変更後の状態を表示します
• 監査レポート：スキャンしたリダイレクトの合計数、検出されたチェーン（ホップ数と完全なパスを含む）、検出されたループ（循環パスを含む）、検出されたリンク切れのターゲット（HTTP ステータスコードを含む）、検出された重複、および正常な単一ホップリダイレクトの割合をパーセンテージで示した全体的なリダイレクト健全性スコア
• 検証結果：デプロイされたすべてのリダイレクトに対する HTTP レスポンステスト。確認済みのソース URL、受信したレスポンスコード（301/302）、到達した最終目的地 URL、ホップ数、合否ステータスを記録します。失敗があれば、診断の詳細を強調表示します
• 実行ログエントリ：完全なリダイレクト変更メタデータ、CMS API の応答、ロールバックに備えた変更前の状態のスナップショット、承認参照、および監査証跡用の検証結果を含むタイムスタンプ付きの記録

使用するエージェント

• seo-specialist — チェーン検出、ループの特定、リンク切れターゲットの診断を含むリダイレクト分析、GSC の過去データと現在のステータスチェックに基づく URL 検証、一括リダイレクト操作の移行計画、用途に応じたリダイレクトタイプ（301 と 302）の推奨、およびリダイレクト統合時のリンクエクイティ維持戦略
• execution-coordinator — WordPress（Redirection プラグイン API、RankMath redirects、Yoast Premium redirects、.htaccess 管理）および Webflow（ネイティブのリダイレクト API と一括処理のサポート）向けの CMS MCP 実行、リダイレクトの量と変更タイプに応じてリスク評価を行う承認ワークフロー、ロールバックに備えた変更前の状態の取得、HTTP 検証テスト、完全な監査証跡を伴う実行ログの記録