散らかったサイトを直そうとすると、最初に「どこから手をつけるか」で迷います。目についた記事からリライトを始めると、あとで統合して消す記事を磨いていた、ということが起きます。
結論から書きます。修正は規模で3つに分け、大規模 → 中規模 → 小規模の順に進めます。
- 大規模修正：サイトの構造の問題。重複記事、孤立したURL、パーマリンクの衝突、カテゴリの設計ミス、テーマ移行の残骸など
- 中規模修正：記事同士の関係の問題。同じ検索クエリで自分の記事同士が競合するカニバリ、どのまとまりにも属さない記事、内部リンクの不足
- 小規模修正：1記事の中の問題。タイトル、メタディスクリプション、FAQ、構造化データ、alt、読みやすさ
順番に理由があります。小さな修正から始めると、構造を直すときに消える記事や統合される記事にまで手間をかけることになります。だから構造から先に直します。
この記事は、散らかったサイトをAIで作り変えるマニュアルの「診断」のまとめの作業です。
目次
この作業で決まること
この作業が終わると、自分のサイトがどの規模の修正から始めるべきかと、各規模で直す対象の一覧が決まります。
診断はAIに任せられます。大半はプログラムで数えられる構造のチェックで、文章を書かせる必要はありません。私のサイトの診断も、記事のHTMLの構造を機械でチェックする方式で、AIの文章生成は使っていません。
よくある失敗：監査ツールの警告件数をそのまま作業リストにすること。件数は「異常の量」であって「問題の重さ」ではありません（後述）。
前提：この記事の前に必要なもの
- AIに渡す4つの前提（戦略・今のデータ・判断基準・禁止事項）
- 全記事の一覧をライブで取れること
- Search Console のデータ（ページ×クエリ）をAIが読めること
AIに渡すもの
- 全記事の一覧：URL・タイトル・カテゴリ・公開日・本文（ライブのもの）
- Search Console のページ×クエリのデータ：カニバリの判定に使う
- 診断の基準：何をもって「大規模」「中規模」「小規模」とするか（下の手順）
- やってはいけないこと：診断の段階では記事を書き換えない
手順
- 構造をチェックする（大規模の判定）
重複している記事（同じテーマで複数のURL）、どこからもリンクされていない孤立URL、パーマリンクの衝突、意図せずインデックスされない設定（noindex）、テーマ移行で残った不要なコードを洗い出します。1つでも見つかれば、大規模修正から始めます。
- カニバリをチェックする（中規模の判定）
Search Console で、同じクエリに自分の記事が2本以上表示されているものを探します。推測ではなく、データで判定します。
- 記事ごとに減点採点する（小規模の判定）
私は記事を7つの項目で採点しています。サイト設計（どのまとまりに属するか）、SEOタイトル、メタディスクリプション、AI検索向けの構造（結論が先にあるか・FAQがあるか）、技術的なSEO（見出しの階層・alt）、内部リンク、読みやすさです。欠けている点を合計し、大きい記事ほど優先します。
- 各項目に「機械で直せるか」の印を付ける
メタやalt、内部リンクの不足は毎日自動で直せます。タイトルや構成の問題は、週1回、性能の高いモデルで判断します。
- 磨く前に需要を測る
本格的に直す前に、その記事のテーマに検索需要があるかを数値で確認します。需要が枯れているテーマは、磨かずに保留または統合の候補にします。
- 大規模 → 中規模 → 小規模の順に、作業の一覧を作る
完了条件
- ☐ 大規模・中規模・小規模のそれぞれについて、対象の一覧がある
- ☐ 各対象に「機械で直せる／判断が要る」の印が付いている
- ☐ 本格的に直す対象について、検索需要を数値で確認している
- ☐ 監査ツールの警告は、中身を開いて重さを確かめてから一覧に入れている
実際に起きた失敗
一番件数の多い警告は、ほぼ空振りだった
勤務先のサイトで、SEO監査ツールを使ってクロールしたときのことです。最大の警告は「メタディスクリプションが空」でした。普通ならここから着手します。
中身を開くと、ほとんどがタグのアーカイブやページ送りのページで、管理画面に入力欄すら無いページでした。実際に手を入れる価値があったのは、ごく一部でした。
一方、ツールが「リンク切れ1件」という軽い扱いで出した項目の裏に、一番重い問題がありました。販売を終了した商品の構造化データが生きていて、Googleに「在庫あり」と申告し続けていました。リンク先は404でした。
ツールは機械的に数えられることしか数えません。メタディスクリプションが空かどうかは数えられますが、そのページに価値があるかは数えられません。ツールの出力は入口であって、作業リストではありません。
データがあるからインデックスされていると思い込んだ
自分のサイトで、Search Console に数字が出ているカテゴリページを「説明文を強化する」作業の対象にしていました。実際にはそのカテゴリページは noindex で、インデックスされていませんでした。Search Console に過去のデータが残っていただけでした。
さらに「ベストプラクティスはインデックスさせること」という調査結果に引っ張られ、サイト固有の構造を見落としかけました。そのサイトでは、まとめ記事がすでに集客の中心として機能していました。カテゴリページはインデックスさせず、まとめ記事を中心にする方針に落ち着きました。
構造の修正を提案する前に、今の設定（noindex など）を実際に確かめることが診断の最初の手順です。
需要を測らずに15本を磨いた
インデックスされていない古い下書き15本を、「資産になりそう」という理由だけで磨いて公開に回したことがあります。あとで Search Console で照らし合わせると、大半は需要がほぼゼロの古いテーマでした。それ以来、本格的に直す前に需要を数値で確認する手順を必須にしています。
よくある質問
Q. 大規模修正が見つからなければ、どこから始めますか？
A. カニバリのチェックに進み、それも無ければ記事ごとの減点採点で上位の記事から小規模修正を始めます。
Q. 診断は毎回全部やる必要がありますか？
A. 構造のチェックとカニバリのチェックは定期的に（私は週1回）回し、記事ごとの採点は毎日の自動処理が読む形にしています。初回だけは全部を通して行います。
Q. 監査ツールは使わないほうがいいですか？
A. 使ってかまいません。ただし件数の多い順に着手せず、中身を開いて問題の重さを確かめてから一覧に入れます。
関連記事
次の作業
- カテゴリと分類を作り直す（大規模修正）
- カニバリを検出して、統合・差別化を判定する（中規模修正）
- 1記事のリライトを外科手術に分解する（小規模修正）
