SEO監査ツールを自作して自社サイトを診断したら、97点でも直すところが7つあった

こんにちは、マサシです。

千葉でWeb制作をしています（スタジオについて）。

自分のサイトのSEO、たぶん大丈夫だと思っていました。

構造化データも入れてるし、サイトマップもあるし、表示も速いし。

で、自分で作ったSEO監査ツールに自社サイトのドメインを入れてみたんです。

97点。

悪くない。

悪くないんですが、中身を開いたら見出しの階層が23ページ全部で飛んでいて、人である記事の著者が「組織」として誤って定義されていて、トップの画像49枚のうち46枚に寸法指定がありませんでした。

「大丈夫だと思っていた」の中身は、だいたいこういうことです。

先に、この記事で確認できたこと・できていないこと

大事なところなので最初に書きます。

	内容
確認できたこと	自作ツールの監査スコアが 97点 → 99点（構造化データ +7 / 表示速度 +7 / オンページ 100点）
確認できていないこと	検索順位・検索流入・実測CLSの変化（反映直後のため追跡中。数字が出たら追記します）
対象	mstudio-web-create.com（Next.js製・23ページ巡回・80項目）
診断日	2026年7月14日（改善前13:00 / 改善後14:13・同一条件）
作業時間	調べる時間を含めて約2時間

つまりこの記事は「技術的な不備を見つけて直した記録」であって、「順位が上がりました」という話ではありません。

順位や流入は、これから Search Console で追いかけます。

そこは正直に分けて書きます。

診断結果：97点。でも改善キューは7件

ツールに mstudio-web-create.com と入れて待つだけ。

サイト内を23ページ巡回して、80項目を採点します（技術SEO・オンページ・構造化データ・AI検索対策・表示速度の5カテゴリ）。

出てきたのがこれです。

点数は高いのに、直すところが7件出ている。

この「点は高いのに課題は残ってる」状態が、いちばん見落とされるやつだと思います。

上から3つを見ていきます。

課題1：見出しの階層が、23ページ全部で飛んでいた

指摘はこうでした。

見出し階層に飛びがあるページ 23件

見出しというのは h1 h2 h3 のことです。

レベルを下げるときに飛ばさない（h2 の次に h4 を置かない）のが、正しい構造とされています。

逆に、h4 から次の章の h2 に戻るのは問題ありません。

うちのサイトは、こうなっていました。

h1 サイトの見出し
h2 できることは、ぜんぶ。
h3 速い
...
h4 Services   ← ここ。h2 から h4 へ飛んでいる
h4 Studio

犯人はフッターでした。

フッターの「Services」「Studio」という小見出しを h4 にしていたんです。

見た目を小さくしたかったから、という理由で。

でもフッターは全ページにあるので、23ページ全部で階層が飛んでいたことになります。

見出しの階層は、検索順位に影響するの？

正直に書きます。

見出しレベルの飛びは、Googleが公表している順位要因ではありません。

直したのは、主に2つの理由からです。

・スクリーンリーダーを使う人は、見出しを目次のようにジャンプして読む。階層が壊れていると迷子になる（W3C WAI の見出しガイド）
・検索エンジンやAIがページ構造を読むときに、階層は「どこが主題で、どこが補足か」の手がかりになる

順位のためというより、読む側（人も機械も）に親切かどうかの話ですね。

直し方はこれだけです。

// Before
<h4>Services</h4>

// After
<h2>Services</h2>

見た目が変わらないように、CSSのセレクタを先に両対応にしてから移行しました。

/* 先に h2 でも h3 でも同じ見た目になるようにしてから、HTML を変える */
.sectionTitle h2,
.sectionTitle h3 {
  font-size: 30px;
}

この順番でやると、途中でレイアウトが崩れません。

なお、フッターのリンク見出しを h2 にするのが唯一の正解ではありません。

本文と同格の章でないなら、見出し要素を使わずにスタイルだけで見せる手もあります。

うちは「サービス一覧」「スタジオ情報」という意味のまとまりだと考えて h2 にしました。

カテゴリページも h1 の次がいきなり h3 だったので、同じように直しています。

結果、23ページの飛びが 0件になりました。

課題2：人である著者を、「組織」として書いてしまっていた

これは自分でもゾッとした指摘でした。

Organization系の name がページによって異なる（2種類）＝エンティティが割れる
・Mstudio
・マサシ

構造化データ（JSON-LD）という、ページの意味を機械に伝えるデータがあります。

うちのブログ記事は、著者情報をこう書いていました。

// Before ── これがまずかった
author: {
  "@type": "Organization",   // ← 「組織」として宣言している
  name: author || "Mstudio", // ← ここに記事の著者名「マサシ」が入る
  url: SITE_ORIGIN,
}

記事の frontmatter に author: "マサシ" と書いてあると、「マサシ」という名前の"組織"がもう1つ生まれてしまう構造でした。

サイト全体では「Mstudio」という組織を宣言しているのに、記事ページでは「マサシ」という別の組織が著者になっている。

人物を書くべきところに、組織の型を当てていた。

型の付け間違いです。

著者の型がずれていると、何が問題なの？

人であるはずのマサシを、機械に「組織」として伝えてしまいます。

schema.org では、記事の author に Person（人）か Organization（組織）を指定できます（Google の Article 構造化データ ドキュメント）。

人が書いた記事なら Person を使い、その人がどこに所属しているかは worksFor で組織に紐づける。

そう書けば「Mstudio という組織に所属するマサシという人が書いた記事」という関係が、機械にそのまま伝わります。

直したのがこれです。

// After ── 人は Person、組織は @id で「既にあるあれ」を参照
author: author
  ? {
      "@type": "Person",     // 著者は「人」として宣言
      name: author,
      worksFor: { "@id": `${SITE_ORIGIN}/#organization` }, // 所属を組織へ紐づけ
    }
  : { "@id": `${SITE_ORIGIN}/#organization` },             // 著者未指定なら組織そのもの

@id は「新しく作るのではなく、すでに宣言してあるあの組織のことです」という参照です。

これで組織は「Mstudio」ひとつ、著者は「マサシ」という人、という関係になりました。

構造化データのスコアは 90 → 97 に上がっています。

ちなみに、この整理が「AIに引用されやすくなる」ことを保証するものではありません。

各AIサービスが何を根拠に引用元を選ぶかは公表されていないので。

ただ、発信者の情報が矛盾なく書かれている状態は、機械が解釈しやすい。

そこは間違いないので、やる価値はあると考えています。

課題3：画像49枚のうち46枚に、寸法が書いていなかった

width/height 未指定の画像が多い（46/49枚）＝読込中にレイアウトがずれる（CLS悪化）

CLSというのは、ページを読み込んでいる最中にコンテンツがガタッと動く現象のことです。

押そうとしたボタンが、画像の読み込みで下にズレて、違うところを押してしまう。

あれです。

原因は単純で、<img> に width と height を書いていないと、ブラウザは画像が届くまで「そこに何ピクセルの箱が入るか」が分からないからです。

ほかに場所を予約する指定がなければ、最初は高さ0で描画して、画像が届いた瞬間に押し広げることになります。

それがガタッの正体でした。

ここでよくある誤解がひとつあります。

CSSで width: 100% と書いていても、それだけでは高さを予約できません。

width と height 属性を書いておくと、ブラウザはそこから縦横比を計算して、画像が届く前に場所を空けておいてくれます（web.dev の CLS 解説）。

CSSの aspect-ratio でも同じことはできるので、寸法属性が唯一の方法というわけではありません。

ただ、いちばん手数が少なくて確実なのがこれでした。

うちは画像をデータから動的に出している箇所が多かったので、データ側に実寸を持たせました。

// top-data.ts ── 画像の実寸をデータに持たせる
export type Service = {
  emu: string;
  emuW: number;  // 実寸（CLS対策）
  emuH: number;
  // ...
};

export const services: Service[] = [
  {
    emu: "/images/mascot/emu-web.webp",
    emuW: 718,   // 実ファイルを測った値
    emuH: 914,
    // ...
  },
];

// 呼び出す側
<img src={s.emu} width={s.emuW} height={s.emuH} alt="" />

実寸は目分量ではなく、コマンドで全部測りました（Macなら sips が最初から入っています）。

sips -g pixelWidth -g pixelHeight public/images/mascot/emu-web.webp

ここでハマりどころがひとつ。

作業実績の詳細画像19枚のうち、19番だけ縦横比が違いました（他は1000×666、19番だけ1000×625）。

「たぶん全部同じ」で固定値を書いていたら、その1枚だけ間違った比率で場所を予約することになる。

1枚ずつ測ってデータに持たせたのは、これがあったからです。

結果、49枚すべてに寸法がつき、表示速度・モバイルのスコアは 90 → 97 になりました。

なお、寸法をつけてもCSSの書き方次第ではズレが残ることがあります。

実測は PageSpeed Insights や Search Console の Core Web Vitals レポートで見るのが確実です。

うちも数字が出たら追記します。

再診断：97点 → 99点

直したものを本番に反映して、同じ条件でもう一度診断しました。

カテゴリ	重み	改善前	改善後	差
総合	—	97	99	+2
技術SEO	0.25	99	99	±0
オンページ	0.25	99	100	+1
構造化データ	0.20	90	97	+7
AI検索対策（GEO）	0.20	100	100	±0
表示速度・モバイル	0.10	90	97	+7

派手な施策は何ひとつしていません。

見出しのタグを変えて、JSON-LDの型を直して、画像に数字を書き足しただけです。

総合が「+2点」しか上がらないのは、少なくない？

そのとおりで、もともと97点だったからです。

90点台後半からの2点は、伸びしろの少ないところを絞り出した2点になります。

カテゴリ別に見ると、構造化データと表示速度がそれぞれ +7 動いているので、直した箇所の効果はスコア上には出ています。

そしてこのスコアは、あくまで自作ツールの採点式による点数です。

Googleの評価そのものではありません。

そこは混ぜないようにしています。

残った5件は何なの？

改善キューは7件から5件に減りました。

今回直した3つのうち、キューに載っていたのは見出しと画像寸法の2件です。

著者の型は「エンティティが割れている」という別の指摘として出ていました。

直さなかったものも書いておきます。

・構造化データの推奨プロパティ（電話番号・営業時間など。リッチリザルトの表示は保証されないので優先度は低い）
・サーバー応答時間（TTFB）の短縮（ホスティング構成の話になるので別途）
・URL設計（既存URLの変更はリダイレクトが要るので慎重に）
・HTMLの肥大（インラインSVG等）
・スクリプトの本数（62本）

このあたりは「影響 × 直しやすさ」で下位に並んだので、今回は見送りました。

ツールは全部を直せとは言いません。

順番だけ出します。

おまけ：ツールが、ツール自身のバグを4つ見つけた

これは正直に書いておきたい話です。

最初に自社サイトを診断したとき、出た点数は 92点 でした。

でも結果をよく読んだら、指摘の中身がおかしいものが混ざっていたんです。

・alt が138枚不足 → 調べたら、そのうち137枚は alt="" と書いてあった。これは「装飾画像です」と伝えるW3C の書き方で、不足ではない
・記事に Article 構造化データが無い → 実際は入っている。ツールが本文を数える前にスクリプトタグを削除してしまい、<body> 側にある構造化データを見落としていた
・ページタイトルが「矢印」 → SVGアイコンの中の <title>（アイコンの読み上げ名）を、ページのタイトルとして拾っていた
・日本語URLに「大文字が入っている」判定 → /blog/category/%E5%9C%B0%E5%9F%9F... のような日本語URLのエンコード部分を、普通のパス文字と区別せずに「大文字あり」と数えていた（エンコード部分は判定から外すべきだった）

1つ目の138枚というのは、23ページ分の延べ枚数です。

トップ1ページで見ると37枚あり、中身はすべてマスコットとイラストでした。

どれも文章側に同じ情報があって、消しても意味が変わらないもの。

実績画像やロゴには、空のaltは付いていませんでした。

4件とも、ツール側の誤検出でした。

直して測り直したら、素点は 92 ではなく 97 だった、というのが本当のところです。

自分のサイトで試さなければ、たぶんずっと気づかなかったと思います。

作ったツールは、まず自分の一番大事なもので試す。

これに尽きるなと思いました。

AI検索対策（GEO）を、別カテゴリで見ている理由

このツールは、5カテゴリのひとつに「AI検索対策（GEO）」を置いています。

ChatGPTやPerplexityのようなAIが、サイトの内容を理解して引用できる状態かどうかを見る項目です。

具体的に見ているのは、こういうところです。

・llms.txt があるか（AIにサイト概要を伝えるファイル。ただしこれはコミュニティ発の提案であって、公式標準でも引用の保証でもありません。対応するかは各AIサービス次第です）
・AIのクローラー（GPTBot・ClaudeBot・PerplexityBot・CCBotなど）を robots.txt でブロックしていないか。※クローラーは「AI検索の回答用」「モデル学習用」「ユーザーが指示したときの取得用」で目的が違うので、ツールでは一律に扱わず、目的つきで一覧表示しています
・発信者が誰なのか、機械が矛盾なく辿れる形になっているか（さっきの著者の型の話です）
・質問に答える形（疑問形の見出し → 直後に端的な答え）で書かれているか

ここで正直に線を引いておきます。

GEOが100点でも、AIに引用されることは保証されません。

各AIがどう引用元を選ぶかは公開されていないからです。

このカテゴリが測っているのは、引用や理解の妨げになりそうな技術的状態がないかという、うちのツールが独自に定義したチェック項目です。

「これを満たせば引用される」という要件ではありません。

ただ、AIの回答が検索の入口のひとつになりつつあると考えているので、順位の話とは別枠で測っています。

この診断、あなたのサイトでもやります

自社サイトでやったのと同じ監査を、そのまま他のサイトにもかけられます。

・サイト全体を巡回して、80項目を採点（ログイン不要・公開情報だけを見ます）
・「何が」「どのページで」「なぜ問題か」を証拠つきで出す
・直す順番を、影響の大きさ × 直しやすさで並べる
・AI検索対策（GEO）も別枠で診断

診断だけでもいいですし、この記事のように直すところまでやることもできます。

「うちのサイト、たぶん大丈夫だと思うんですけど」という方こそ、いちど測ってみると面白いです。

自分がそうだったので。

お問い合わせから「SEO診断」とだけ書いて送ってもらえれば、こちらから返信します。

サイトの制作や改修そのものは Web制作 と 修正・改修 に、AI検索対策だけを切り出したサービスは AI検索対策（LLMO） に書いています。

技術的な失敗と解決の記録は、ブログにほかにも置いています。