• #Chrome DevTools MCP
  • #autoConnect
  • #Search Console
  • #SEO
  • #リダイレクト
  • #noindex
  • #canonical
開発mdx-playgroundメモ

Chrome DevTools MCP autoConnect設定とSearch Console 404対策

午前中はChrome DevTools MCPの接続方法を見直し、午後はSearch Consoleの404エラー317件を潰した。どちらも「動いているつもりで放置していた」設定が原因で、ログを開いて初めて問題の規模に気づいた。

Chrome DevTools MCP: autoConnectへの移行

背景: テスト専用プロファイルの限界

これまでChrome DevTools MCPは --user-data-dir で専用プロファイルを起動し、ポート9223で接続していた。動くが、普段使いのChrome拡張（SSボタン等）が入っていない。拡張の操作を自動化したいなら、普段のGWS（Google Workspace）プロファイルのChromeに接続する必要がある。

試行1: --browserUrl で既存Chromeに接続（失敗）

普段のChromeはポート9222でリモートデバッグを有効にしている。--browserUrl http://localhost:9222 で接続できるはず――と設定を書いた。

{
  "command": "npx",
  "args": [
    "@anthropic-ai/chrome-devtools-mcp@latest",
    "--browserUrl", "http://localhost:9222"
  ]
}

MCP serverは起動するが、ページ一覧の取得でエラーが出る。Chrome DevTools Protocol（CDP）のバージョン不整合か、WebSocket接続のハンドシェイクで詰まっているようだった。ログを睨んだが原因を特定できず、別のアプローチに切り替えた。

試行2: --autoConnect オプション（成功）

Chrome DevTools MCPのリポジトリを確認すると、--autoConnect というオプションが追加されていた。Chrome M144以上で使える。手元のChromeはバージョン146。条件を満たしている。

{
  "command": "npx",
  "args": [
    "@anthropic-ai/chrome-devtools-mcp@latest",
    "--autoConnect"
  ]
}

このオプションはCDP WebSocket経由ではなく、Chrome DevTools Protocolのpipe接続を使う。ポート番号の指定が不要になり、既に起動中のChromeインスタンスに自動接続する。

結果: 普段のGWSプロファイルのChromeに接続でき、SSボタン（Chrome拡張）のDOM操作にも成功した。

落とし穴: プロジェクトレベル設定がグローバルを上書きする

グローバルの ~/.claude/settings.json に --autoConnect を追加して安心していたら、特定プロジェクトで古い --browserUrl 設定が残っていた。プロジェクトの .claude/settings.local.json がグローバル設定を上書きするため、--autoConnect が効かない。

対処: プロジェクトレベルのMCP設定を削除し、グローバル設定に一本化した。

最終構成: 2つのMCP設定をグローバルに配置

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["@anthropic-ai/chrome-devtools-mcp@latest", "--autoConnect"]
    },
    "chrome-devtools-test": {
      "command": "npx",
      "args": [
        "@anthropic-ai/chrome-devtools-mcp@latest",
        "--browserUrl", "http://localhost:9223"
      ]
    }
  }
}
  • chrome-devtools: 普段使いのChromeに --autoConnect で接続。拡張の操作もできる
  • chrome-devtools-test: テスト用の別プロファイル（ポート9223）。クリーンな環境が必要なとき用

Search Console 404対策

現状把握: 404が317件

Search Consoleを開いたら、404エラーが317件積み上がっていた。原因を辿ると、_redirects ファイルが2026年1月1日から更新されていなかった。その間に追加・移動した記事のURLが全てリダイレクトなしで404を返していた。

リダイレクト再生成

generate-redirects.mjs を実行し、リダイレクトルールを1,567件に再生成した。手動で実行を忘れないよう、ビルドプロセスの postgenerate フックに組み込んだ。

{
  "scripts": {
    "postgenerate": "node generate-redirects.mjs"
  }
}

これで nuxt generate を実行するたびにリダイレクトが自動生成される。1月からの3ヶ月間、手動実行を忘れ続けていた問題が再発しなくなる。

ソフト404対策: レスポンスステータスの修正

存在しないURLに対して200ステータスで空コンテンツを返していた（ソフト404）。[...slug].vue にステータスコード設定を追加した。

// [...slug].vue
if (!page.value) {
  setResponseStatus(event, 404)
}

Googleはソフト404を検出するとクロールバジェットを浪費するため、正しい404を返すことでクロール効率が改善する。

テスト用・空コンテンツの削除

Search Consoleの404リストを見ていくと、テスト用に作って放置していたファイルが4件見つかった。

  • aaa.md
  • test.md
  • 他2件の空コンテンツ

いずれも中身がないか、テスト文字列だけのファイル。削除した。

TODOページ99件にnoindex設定

TODO（active/done/canceled）のステータスがついた記事が99ページあった。これらは内部的な作業管理用で、検索結果に出ても読者の役に立たない。

対応:

  • 該当ページに <meta name="robots" content="noindex"> を設定
  • sitemap.xml の生成対象から除外

検索インデックスから段階的に消えるはず。

canonical タグの実装

同一コンテンツが複数URLで到達可能なケースがあった（日付パス付きと日付パスなし等）。<link rel="canonical"> を全ページに追加し、正規URLを明示した。

リマインダー登録

対策の効果を確認するため、Google Calendarにリマインダーを2件登録した。

  • 4月14日: Search Consoleで404件数の減少を確認
  • 5月1日: noindex設定したTODOページがインデックスから消えているか確認

振り返り

午前のautoConnect設定は、--browserUrl で30分ほど接続エラーのログを読み続けた末に --autoConnect に切り替えたら一発で繋がった。ドキュメントを先に読むべきだった。

午後のSearch Console対策は、3ヶ月間放置していた _redirects 未更新が根本原因。postgenerate に組み込んだことで、今後は「デプロイしたのにリダイレクトが古い」という事態が起きなくなる。

1日で2つの「放置していた問題」を片付けた。どちらも、仕組みに組み込む（autoConnectでポート管理不要にする、postgenerateで自動実行する）ことで再発を防いでいる。