既存サイトを診断し、修正順序を決める
公開URL一覧と実際の応答を照合し、アクセス・本文・URL・事実の誤りを探す。修正前の記録を残し、原因の位置と期待結果を定めてから実装する。
公開範囲とURL一覧を確定する
検索にないページをすべて同じ方法で直すと、原因が残る場合がある。リンクがなく発見されない記事には発見経路、noindexのある記事には指示の修正、本文に答えがない記事には内容補強が必要だ。まず同じURLの実際の応答と検索処理記録を比較し、どの段階で資料が抜けたか探す。
運用担当者と公開・検索対象の範囲を先に決める。全公開コンテンツを検索許可する方針なら、記事・告知・紹介・写真説明という種類だけでnoindexを追加しない。ログイン資料、下書き、公開予約前、撤回記事は別状態にする。検索除外とアクセス制限は別設定なので、非公開資料は認証・権限で保護する。
コンテンツストアやCMSから公開URLを抽出し、サイトマップと実際のメニュー・本文リンクから見つけたURLと照合する。サイトマップだけでは、そこから抜けた記事を発見できない。一覧・詳細・ページ分割・画像・添付といった経路の種類も記す。本文リンクにもサイトマップにもない公開記事は、接続追加の候補になる。
URLごとにコンテンツID、種類、公開状態、期待コード、代表URL、公開日・実質更新日、関連質問を記録する。各テンプレートの代表URLから標本検査を始め、最後は対象全件に照合を適用する。下書き・撤回・不存在URLも別標本にし、公開記事と混ざらないか確認する。
デプロイ前の基準値と観測表を作る
観測開始前に対象URLと質問を固定する。デプロイ前記録があれば同じ集合で比較し、なければ最初の観測を基準にする。URL追加や質問変更は版を分け、追加分を示す。総数だけでは新規コンテンツの増加と既存ページ改善を区別しにくい。
技術記録にはサイトの実応答、検索記録には検索エンジンの最新処理状態、AI記録には質問への答えと引用を残す。同じURLでも3記録の時刻は異なり得るため、各原文を観測時刻とともに保つ。以下は最初の図書館エラーを記録する架空例だ。
デプロイ直後は、新本文と代表URLが応答に反映されたか確認する。その後の検索・AI観測では最新クロール日と引用文書の日付を読む。旧資料が残るかに応じ、再クロールを待つか文書の期間説明をさらに直すか決める。
初期構築・改修・新機能追加の範囲を分ける
初期構築では公開URLと基本本文、ページ別タイトル・説明・代表URL、robots、サイトマップ、検索プロパティ登録を用意する。改修では旧URLの移転・保存方法、現在と過去の情報の区別、新しいデータ取得の公開条件も調べる。
新メニューや画面領域を追加する場合は、何をどこから読み、どう詳細につなぐかを先に記す。初期応答に本文・タイトル・詳細リンク・画像・原文出典があるか確認する。タブ・カルーセル・スクロール後にだけ現れる資料は、ブラウザー動作とクロール可能な経路を併せて見る。
サーバー応答とブラウザー画面を一緒に集める
以下はmacOS・Linuxシェルで行う読み取り専用調査例だ。example.comは説明用ドメインなので対象に置き換え、ページには公開詳細記事を1つ指定する。Cookieや管理者認証を付けずに始める。
AUDIT_ORIGIN='https://example.com'
AUDIT_PAGE="$AUDIT_ORIGIN/guides/opening-hours"
mkdir -p seo-audit
curl -sS -D seo-audit/page.headers -o seo-audit/page.html "$AUDIT_PAGE"
curl -sS "$AUDIT_ORIGIN/robots.txt" -o seo-audit/robots.txt
curl -sS "$AUDIT_ORIGIN/sitemap.xml" -o seo-audit/sitemap.xml
最初の要求では転送を自動追跡していない。ヘッダーファイルでコード・Location・X-Robots-Tag・Content-Typeを読む。3xxなら次のコマンドで最終URLと転送回数も記録する。正常な代表URLはログイン画面ではなく意図した公開本文を返す必要がある。
curl -sS -L -o /dev/null -w 'status=%{http_code} redirects=%{num_redirects} final=%{url_effective}\n' "$AUDIT_PAGE"
rg -n -i 'noindex|canonical|<title|application/ld\+json' seo-audit/page.html
rgはファイル内の文字列検索コマンドだ。結果から設定位置を探す。1行HTMLやJavaScript文字列も拾うため、実際のタグと本文を区別して読む。新しい未ログイン画面で同じURLを開き、本文・写真・リンクを確認する。HTMLに答えがなくローディングだけなら、レンダリング構成のデータ取得手順をたどり、どの段階で入るか調べる。GoogleのJavaScript処理ガイドも参照する。
保存HTMLに休館日がなくブラウザーにはあるなら、その間のJavaScript実行とデータ要求を調べられる。両方にないなら原稿かサーバークエリを直す。この差を確かめれば、検索露出の少なさだけでフレームワークから変えることを減らせる。
静的写真とCMS写真を1枚ずつ選び、同じ画面幅で開く。静的写真は幅付き変換URL、CMS写真は元URLを要求するなら、CMSフィールドからimg.srcまで追う。CSS幅だけでは送信バイト数は分からない。CMS画像実習の元画像表示と派生画像表示は同じ資料・配置を使うため、配信方式を比較できる。
症状を修正位置につなぐ
リポジトリでは以下の検索で設定生成位置を探す。パスはプロジェクト構造に合わせる。既定値だけでなくページ別上書き、ヘッダー、デプロイ環境まで追う。同じnoindexがHTMLとHTTPヘッダーに重複する場合がある。
rg -n 'noindex|X-Robots-Tag|generateMetadata|canonical' src app public
rg -n 'sitemap|robots|dateModified|datePublished|application/ld\+json' src app public
rg -n 'published|visibility|deletedAt|publishedAt' src app
外部ピアレビューがあれば、対象URL・時点・条件・観測値をまず転記する。実応答とコードで再現して修正位置につなぐ。修正済み、未解決、運用方針と合わず不採用の提案を分ける。性能指摘は同じページ・機器・ネットワーク条件で前後を測定する。
写真が遅い原因は要求時点でも変わる。HTMLにURLが遅く現れるならレンダリング・データ取得、早く現れるがダウンロードが長いなら容量・接続を見る。受信後の表示が遅いならメインスレッドとデコードを確認する。この順に絞れば、フレームワーク全体を変える前に修正位置を探せる。
修正順序と判断根拠を決める
まず非公開露出、公開記事へのアクセス失敗、広範囲の誤noindex・代表URLなど、対象全体への問題を処理する。次に本文欠落・切れたリンク・日付と事実の誤りを直す。タイトル・要約・表・画像説明は答えを見つけにくいページから改善する。外部回答は修正前の基準を一度記録し、公開後に同条件で続ける。
課題は「URL／症状／原応答または画面／原因位置／修正／合格条件／再観測質問」で記録する。共通レイアウトのnoindexが公開詳細に来る場合、既定値と公開ページ上書きを直し、正常記事・下書き・不存在URLを一緒に確認する。根拠のない推測は調査項目として残し、修正課題と分ける。
Googleの生成型検索は基本的な検索品質と技術要件を使う。公開本文・アクセス・出典を先に直す。llms.txtを読む別ツールを運用するなら、渡す内容と更新時点を定める。生成型検索最適化ガイド
次の段階へ渡す資料
診断後は質問–URL一覧、公開状態表、応答・画面記録、優先順位付き修正一覧を残す。担当者がコード位置と合格条件を直接見つけられる形にする。外部報告にアクセスできなければ、参照可能と未観測を記録する。空欄の理由も次の観測者に伝わるよう書く。
診断各項目を修正ファイル・設定・内容と期待応答につなぐ。レンダリング変更は更新頻度と公開条件、URL問題は代表URLと旧URL対応表を先に定める。修正後は同じURLと質問で再確認する。
架空図書館の3症状を修正課題にする
開館時間詳細URLを未ログインで要求し本文を保存する。ローディングだけなら取得時点を調べ、canonicalがホームなら詳細メタデータ生成位置を探す。旧時間割を現在の質問に使えるか、日付と適用期間を照合する。
次の表は図書館の3誤りと修正位置をつなぐ。応答HTML、canonical、過去案内本文を並べて読むと必要な変更を区別できる。
技術欠陥と内容欠陥の根拠を分ける
同じ「検索流入が少ない」でも原因は異なる。応答に本文がなければ配信経路、申込条件がなければ原稿、申込ボタン後のエラーならコンバージョン経路を調べる。キーワード調査と実際の問い合わせから質問を診断表に入れ、各ページが答えるか確認する。
基準には質問・URL・公開版・適用期間・観測時刻を併記する。今の画面と1か月前の検索報告を直接比較せず、どの原稿が実際に出た可能性があるか確認する。検索意図別マップの文書役割を基準に不足を探す。
インデックス済みでも生成型回答に出ない場合を絞る
架空の開館案内がURL検査で登録済みでも、回答から休館条件が抜ける場合がある。まず実際の引用URLを保存する。現案内なら本文の例外とnosnippet・data-nosnippetによる除外を読む。過去記録なら期間と現案内リンクを照合する。引用なしならSearch generative AIの参加設定と質問に合う内容を確認する。
診断表に質問と引用URLを併記し、URL検査の最新クロール日とスニペット指示も添える。2025年案内の引用なら、その期間と現案内リンクを先に見る。現案内を引用しつつ休館日を落としたなら、その文と例外説明を照合する。
例えば最終クロールが10月20日で休館条件を24日に追加した場合、20日資料の回答には新条件がないかもしれない。24日以降の資料でも例外を落とすなら、答えと条件の配置、引用箇所、質問解釈を再確認する。クロール日比較は修正が未配信の場合と、届いた内容の誤使用を分けるためだ。