GEOを語る人間のブログは何点だったのか ── 自己診断と改善の記録

自分のサイトを自分のツールで測る

ここまでの一連の記事で、WebサイトがAIに読まれる状態かを診断する6つの観点と、その背景にある技術的な事実を書いてきた。AIクローラーはJavaScriptを実行しない、構造化データでエンティティを明示すべき、といった話だ。

では、その記事を載せているこのブログ自体は、何点なのか。

GEOについて偉そうに書いておきながら、自分のサイトが低スコアだったら笑い話だ。だが逆に、診断から改善までの過程をそのまま見せれば、ツールが何を測り、改善で何が変わるのかの一番わかりやすい実例になる。そう考えて、自作の診断ツールを自分のブログに向けた。結果は、隠さず全部書く。

本記事は、その診断・改善・再診断の記録である。

対象サイトの構成

このブログは Astro で構築し、Cloudflare Pages にデプロイしている。静的サイトジェネレータなので、ビルド時にHTMLが生成され、配信時にはJavaScriptに依存せず本文が読める ── はずだ。その「はず」を含めて測定する。

診断は2種類のページに対して行った。トップページと、個別の記事ページだ。後述するが、この2つを分けたことが思わぬ気づきにつながった。

初回診断:トップページ 76点

まずトップページを診断した結果が以下である。

項目	スコア	状態
AIボットのアクセス可否	100	良好
JavaScript依存度	100	良好(JS依存率 0%)
セマンティックHTML	100	良好
構造化データ	0	重大
llms.txt	60	要改善
鮮度シグナル	70	要改善
総合	76

予想通りだった点と、そうでない点がある。

予想通り:JS依存度が満点。Astroの静的生成が効いている。JavaScript実行前後でテキスト量が変わらず(991文字→991文字)、JS依存率は0%。AIクローラーがJavaScriptを実行しないという問題に対して、構造的に強い。GEOを論じる記事を載せるサイトとしては、ここで落第していたら洒落にならなかった。

予想外:構造化データが0点。JSON-LDを一切入れていなかった。記事を書くことばかり考えて、機械可読なメタ情報の整備が完全に抜けていた。

llms.txtは設置していたが形式不備(H1見出しとリンクが規定の形式でない)で60点、鮮度シグナルは公開日マークアップがなく70点。

改善1:構造化データ(0 → 90)

最もスコアが低く、上げ幅が大きい構造化データから着手した。

サイト全体のレイアウトに WebSite 型のJSON-LDを、個別記事ページに BlogPosting 型のJSON-LDを追加した。重要なのは、記事ごとにベタ書きするのではなく、Astroのフロントマター(各記事のタイトル・説明・公開日・著者)から動的に生成するようにしたことだ。これで記事を増やすたびに自動で構造化データが付く。

結果、構造化データは0点から90点へ。検出されるSchema.orgタイプが「WebSite, BlogPosting」となった。残る10点は著者・発行者の詳細プロパティを充実させる余地だが、実用上は十分なレベルだ。

改善2:llms.txt(60 → 100)

llms.txtの形式を仕様に沿って整えた。先頭にH1見出し、本文に主要ページへのリンクを - [名前](URL) 形式で記述。あわせて全文を結合した llms-full.txt も設置した。

正直に書いておくと、llms.txtの効果は現時点で限定的だ(別記事で詳述した通り、主要AIクローラーが積極的に参照している証拠は乏しい)。これは「効くから直した」のではなく「低コストで完成度を上げられるから直した」項目だ。診断項目に含めてはいるが、ウェイトは低く設定している。効果を過大評価しない、という姿勢はここでも変えない。

改善3:鮮度シグナル(70 → 100)

記事ページに公開日・更新日のマークアップを追加した。article:published_time のメタタグ、可視の <time datetime> 要素、そして改善1で追加したBlogPostingの datePublished ── これらをフロントマターの日付から一貫して生成するようにした。

これで記事ページの鮮度シグナルは100点になった。

ここで気づいたこと:ページ種別で診断結果が違う

改善後にもう一度トップページを診断したところ、鮮度シグナルが70点のままだった。一瞬「実装が漏れたか」と焦ったが、原因はすぐにわかった。

トップページには記事の公開日が存在しない。日付マークアップを入れたのは個別記事ページであり、トップページに記事の公開日がないのは当然だ。同様に、トップページで検出される構造化データは WebSite のみで、BlogPosting は記事ページにしか現れない。

つまり、ページの種別によって最適な構造化データも、あるべきメタ情報も異なる。トップページは「サイト全体を表す情報(WebSite)」を持ち、記事ページは「記事固有の情報(BlogPosting、公開日)」を持つ。単一のURLだけを診断すると、サイト全体の状態を見誤る。

これは自分でツールを作って、自分のサイトに当てて初めて体感した教訓だった。診断は代表的なページ種別ごとに行うべきだ。

想定外のバグ:自分のサイトにh1が2つあった

記事ページを診断すると、セマンティックHTMLが100点から85点に下がった。理由は「h1見出しが2個ある」。

調べると、サイト名(ロゴ)がh1、記事タイトルもh1になっていた。h1はページに1つだけ置くのがHTMLの仕様で、複数あるとAIがページの主題を誤認識しうる。GEOについて記事を書いているサイトの本体に、基本的な構造の不備があったわけだ。

これは少し恥ずかしい発見だが、同時に診断ツールの価値を最もよく示す瞬間でもあった。人間の目視では見落とす類の問題を、機械的なチェックは確実に拾う。サイト名側をh1から通常の要素に変更し、記事タイトルだけを唯一のh1にした。

最終結果

修正をすべて適用し、記事ページを再診断した最終結果が以下である。

項目	初回	最終
AIボットのアクセス可否	100	100
JavaScript依存度	100	100
セマンティックHTML	100	100
構造化データ	0	90
llms.txt	60	100
鮮度シグナル	70	100
総合	76	98

トップページは76点から93点、記事ページは98点まで改善した。

作業時間としては大したことはない。すべて自分で対応できる範囲(構造化データの追加、メタタグ、llms.txtの整形、h1の修正)で、サーバー構成の変更やSSR化のような大掛かりな作業は不要だった。元のサイトが静的生成でJS依存度の問題を抱えていなかったため、残りは「読まれる土台に、機械可読なメタ情報を足す」作業に集中できた。

この記録からの学び

3つにまとめる。

第一に、JS依存度のような重い問題がなければ、AI可読性の改善は意外と軽い作業で済む。構造化データもメタタグもllms.txtも、フロントマターから動的生成する仕組みを一度作れば、あとは自動で付いてくる。逆に言えば、JS依存度の問題を抱えたサイトは、ここが重くなる。土台が効いてくる。

第二に、診断はページ種別ごとに行うべきだ。トップと記事では持つべき情報が違う。単一URLの診断はサイトの一面しか見ていない。

第三に、機械的な診断は人間の見落としを拾う。h1の重複は、目視では気づきにくい。GEOを論じている当人のサイトにすら不備があったのだから、診断の自動化には意味がある。

そして繰り返しになるが、これは「AIに引用される土台が整った」という話であって、「AIに引用される」という結果の保証ではない。スコアが98点になっても、それは必要条件を満たしただけだ。引用されるかどうかは、コンテンツの中身と、別記事で触れた引用実測の領域の話になる。

土台を整える作業は、地味で、効果が測りやすく、再現性がある。まずここからだ ── その実例として、自分のサイトを使った記録だった。

---

本記事の診断は、筆者が開発したAI可読性診断ツールによるもの。診断項目の詳細は別記事のシリーズで解説している。