Search Console効果測定で未登録5,030件の主因を特定し、デプロイエラーまで片付けた日

開発mdx-playground

Search Console効果測定で未登録5,030件の主因を特定し、デプロイエラーまで片付けた日

朝イチ、昨日の積み残しが何だったか思い出せなかったので、作業ディレクトリを見てもらうところから始めた。答えは「作業自体はほぼ完了、ただし未コミットのまま一式残っている」。今日はこの棚卸しから始まって、Search Consoleの効果測定、デプロイエラーの対応まで、リポジトリまわりを一気に片付けた。

朝イチの棚卸しとワーキングツリーの整理

昨日の成果物の状態を確認してもらうと、最大の積み残しは未コミットの変更が一式残っていることだった。作業自体は終わっているのに、コミットされていないせいで「何が終わって何が残っているのか」がgit statusから読めない状態になっていた。

「意味がある粒度でコミットして、ワーキングツリーをきれいにしてほしい」と頼み、/commit スキルで機能・日付・カテゴリごとに分割してもらった。5コミットとtmpファイルの掃除でツリーは空になった。あわせて、残っていた積み残しの一覧ももう一度出してもらい、今日やるべきことの輪郭がはっきりした。

pushでマージを要求されてブランチを整理した

きれいになったところでpushしようとしたら、見慣れないマージの画面が出て手が止まった。リモートとローカルが分岐していたらしい。

自分で解きほぐすのはやめて、「ブランチもきれいにして、マスターにすべて反映してほしい」と丸ごと任せた。途中、状態確認のコマンドが長すぎて通らず、1つずつ分けて実行し直す場面もあった。残っていたブランチはPRの状態を個別に確認したうえで、マージの衝突を解消してmasterをプッシュし、マージ済みブランチ5本を削除するところまでやってもらった。ワーキングツリーはきれいなまま、origin/masterと完全に同期した状態に戻った。

このタイミングで、直前のデプロイが失敗していた原因も判明した。マージ未解決のツリーでビルドが走ったというタイミング問題で、ブランチ整理と同時に解消していた。

Search Console効果測定 — 未登録5,030件の内訳

3月末に打ったインデックス改善施策の効果測定として、Search Consoleのドメインプロパティを横断確認した。比較の土台として、memo/ に残していた2026-03-31の改善計画と2026-04-14の404フォローアップも掘り出してもらった。過去の自分が何をどこまでやったかは、記憶ではなくmemoが答えてくれる。

インデックス登録状況・サイトマップ・リンク・ウェブに関する主な指標・検索パフォーマンスを一通り見て回った所見はこうだ。

  • 登録済みページ4,400件に対して、未登録ページが5,030件。発見済みURLの半数以上がインデックスされていない
  • 未登録の内訳は「ページにリダイレクトがある」が2,526件と突出。404が864件、リダイレクトエラーが258件
  • リンクレポートを見ると、タグページが末尾スラッシュあり・なしの両方(/tags/日記/tags/日記/)で別URLとして大量に内部リンクされている。これがリダイレクトと重複URLを量産している主因候補

この所見をもとに効果測定レポートを memo/2026-07-04/ にHTMLで作らせた。あわせて根本原因側の修正も、エージェント3体を並列で走らせて進めてもらった。

  • 内部リンクのURL統一: app/utils/canonical-url.ts を新設し、対象17ファイルを修正。テスト9件パス、カバレッジ100%
  • _redirects の再設計: 5,945行を677行まで圧縮し、検証は全パス
  • prerenderルートの追加: 321ルートを追加。sitemapはdistをスキャンする方式なので、prerenderに入れるだけで321件が自動的にsitemapにも載ることが分かった

prerender対応の過程では、useRequestURL() がcomputed内で呼ばれている潜在的なSSR 500バグまで見つかった。放っておくとprerenderが静かに失敗するところで、先回りで直すことになった。

レポートをブラウザで確認、「上限に達した」の解消方法

レポートはブラウザで見たかったので、memo/2026-07-04/ に小さな静的サーバーを同梱してもらい、localhost:8899で表示確認した。施策前後のKPIを並べた図表入りで、追加してもらった対比表のセクションまでレンダリングを確かめた。途中、特殊なスラッシュ文字が1箇所混入していたので直してもらった。

気になっていたのが、以前Search Consoleで「上限に達した」となっていた件。これはCloudflare Pagesの _redirects が2,000行上限を超えていた問題で、ワイルドカード圧縮と不要ルールの削除で5,945行から677行まで縮めて解消したとのこと。ローカルでは全ルール有効になったが、デプロイするまで本番は超過状態のまま、という整理だった。

GitHub Actionsの手動トリガー化を振り返って削除

ビルドを眺めているうちに、ふと思い出した。GitHub Actionsを手動トリガー化した経緯があったはずだが、あれは今使っていないのでは。

調べてもらうと、SSGのメモリ問題対応で自動デプロイをやめて手動トリガー化した名残で、現在のデプロイフロー(ローカルビルド→wrangler直接デプロイ)では出番がなかった。使っていないなら消す方向で、deploy.ymlを削除してもらった。

デプロイエラーを記事化して、再実行で成功

pnpm generate がexit 134で落ちた。ログの末尾を確認してもらうと、Node.jsのヒープメモリ上限到達によるOOMだった。あわせて、検証スクリプトが失敗を見逃す偽陽性も見つかった。途中、issueに未検証の完了記述が紛れ込んでいるのが見つかり、事実ベースの記述に直してもらう一幕もあった。再実行していないものが「完了」と書かれていると、後で読んだ自分が騙される。

このエラーは自分の中だけに留めず、「ログとして公開記事でドキュメントにまとめておいて」と頼んだ。generate OOMとverify偽陽性の2件を記事化させて、後で同じエラーに当たったとき検索で引けるようにした。

改善を入れたあと、デプロイコマンドは自分でもう一回叩いた。今度は通った。「成功したっぽい」で終わらせず、レポートに書いておいたデプロイ直後のcurl確認を本番に対して実行してもらった。Beforeのままの項目が1つでもあれば即調査、全部Afterなら寝かせられる、という判定で、結果は全項目クリア。Search Console側では「修正を検証」を3件(リダイレクト・404・リダイレクトエラー)とも開始した。ここから先は検証結果を待つしかないので、一旦様子見とした。

今日の到達点

  • ワーキングツリーを空にして、origin/masterと同期
  • マージ済みブランチ5本を削除
  • Search Console効果測定レポートを memo/2026-07-04/ にHTMLで作成、ブラウザで表示確認
  • 根本原因3点の修正(canonical統一・_redirects 圧縮・prerender 321ルート追加)
  • 使っていないGitHub Actionsワークフローを削除
  • デプロイエラー2件(generate OOM・verify偽陽性)を公開記事化
  • デプロイ再実行で成功、本番curl確認は全項目クリア
  • Search Consoleの「修正を検証」3件は結果待ち

締め

最後に「コミットしといて。あのサーバーは閉じていい」と頼んで、レポート表示用のサーバーを停止し、13コミットを積んで、残タスクは計画書に落として1日を閉じた。

コミット後のセキュリティレビューで、レポート閲覧用の簡易サーバーにパストラバーサルの穴があると指摘された。decodeURIComponent%2e%2e.. に復号するせいで、ルートの外のファイルを読み出せる状態だったらしい。使い捨てのローカルサーバーとはいえ、リポジトリにコミットした以上は後日再利用されうるので、これも直してコミットした。

学び

  • pushでマージを要求されたら、自分で無理に解かず「ブランチ整理してmasterに全部反映」と丸ごと任せたほうが早い。衝突解消からブランチ5本の削除まで一続きで片付いた
  • インデックス未登録は件数だけ見ても動けない。内訳(リダイレクト2,526件・404が864件)とリンクレポートを突き合わせて初めて「末尾スラッシュの不統一」という直せる原因に落ちた
  • 「上限に達した」系のエラーは、上限を上げるのではなく中身を圧縮する方向で解ける。_redirects は5,945行→677行まで縮んだ
  • 使っていない自動化(手動トリガー化したGitHub Actions)は、経緯を思い出したタイミングで消す。残しておくと次に見たとき、また同じ調査をすることになる
  • デプロイエラーは直すだけでなく公開記事に残す。exit 134の数字は、次に見たとき記事が答えてくれる
  • 効果測定は過去のmemoとの突き合わせで初めて成立する。3月末の改善計画を残していなかったら、今日の数字が良いのか悪いのか判断できなかった
  • 「デプロイ成功したっぽい」を確定に変えるのは、直後のcurl確認。判定基準(Before残りがあれば即調査)を先にレポートへ書いておいたのが効いた