結論から：公開して2週間の自社メディアを1日かけて点検したところ、検索結果に出ている237ページのうち96ページ（32%）が404でした。ほかに、写真が合計40MBあったこと、記事とニュース832ページすべてに問い合わせ導線が一つも無かったこと、よくある質問のページが別メディアの内容のままだったことが分かりました。ページを開いて「表示される」ことと、正しく機能していることは別物です。
このサイト（AIの鬼）は2026年7月19日に公開しました。記事を積み、ニュースを毎日集める仕組みは動いています。ただ、公開したあと「本当に想定どおり動いているか」を外から測ったことがありませんでした。8月1日、それをやりました。
何が見つかったか
測った順ではなく、深刻な順に並べます。
| 見つかったこと | 実測値 | なぜ問題か |
|---|---|---|
| 検索結果のページが404 | 237ページ中96ページ | クリックしても存在しない。実際に4クリックが404に落ちていた |
| 問い合わせ導線が無い | 記事213本・ニュース619本の全て | 読み終えた人が取れる行動が「一覧へ戻る」だけ |
| 記事に内部リンクが無い | 207本中204本 | 次に読むものへ移動できない |
| 写真が重い | 348枚40.2MB（中央値169KB） | 表示が始まるまでの待ち時間に直結する |
| 検索用データが肥大 | 1,020KB（gzip後330KB） | サイト内検索を開くたびに全部ダウンロードされる |
| よくある質問が別メディアの内容 | 12問すべて | 何のサイトか伝わらない |
| ページ送りの見出しが全部同じ | 9ページ | 検索結果に同じ文字が並ぶ |
| 見出しの階層が飛ぶ | 検査した全ページ | 読み上げで構造が壊れる |
一番大きかったのは、消えるページだった
404の原因は、ニュースの保持件数の設定でした。
集めたニュースは新しい順に一定件数だけ保持し、古いものはデータごと捨てる設計にしていました。捨てられた記事は、次にサイトを作り直したときにページごと消えます。
問題はタイミングです。Googleがページを見つけて検索結果に載せるのは、公開から2〜4週間後。一方、1日30件集めて600件までしか持たない設定では、20日で押し出されます。つまり「検索結果に載った頃には、そのページはもう無い」という状態が、ずっと続いていました。
実際、「kimi k3 使い方」という検索語で掲載順位2位・表示22回を獲得していたページが404でした。せっかく上位に出ていたのに、クリックした人は存在しないページに着いていたことになります。
保持件数を約100日分に増やして止めました。
直した順番と、その理由
1日で全部は直せないので、順番を決めました。
| 順 | 直したこと | 決め手 |
|---|---|---|
| 1 | 消えるページを止めた | 検索結果の3割が壊れている。他の何より先 |
| 2 | 問い合わせ導線を付けた | 読まれても相談が発生しない状態だった。集客より受け皿が先 |
| 3 | 関連記事を出すようにした | 読み終えた人が次に行く先を作る |
| 4 | 写真を軽くした | 40.2MB → 14.9MB（63%減）。1枚193KB → 79KB |
| 5 | よくある質問を書き直した | 中身が別メディアのままだった |
| 6 | 検索用データを絞った | 1,020KB → 407KB（60%減） |
2番目を集客より先に置いたのは意図的です。 読んだ人が次に取れる行動が用意されていないサイトは、アクセスが増えても何も起きません。穴の空いたバケツに水を足しても溜まらないのと同じで、先に穴を塞ぎました。
思い込みが外れたこと
点検の途中で、間違っていた仮説もいくつかありました。これも書いておきます。
- 「記事がGoogleに登録されていないのでは」 → 208本を1本ずつ調べたところ、200本（96%）が登録済みでした。登録はされていて、順位が付いていないだけです。原因が違えば打ち手も違うので、これを確かめたのは無駄ではありませんでした
- 「他の記事からリンクされていない記事は検索に出ないのでは」 → リンクのある記事の表示率38%、無い記事32%で、ほぼ差がありませんでした
- 「出典リンクが切れているのでは」 → 154本のうち生きていたのは153本。健全でした
- 「更新が3日止まっている」 → これは私の測り方の間違いでした。一覧の先頭3件だけを見たのですが、先頭は注目記事で新着順ではなく、たまたま古い日付が並んでいただけです。実際は正常に更新されていました
最後のものは、点検そのものの失敗です。測り方を間違えると、無い問題を「見つけて」しまいます。
中小企業が自社サイトでできる点検
専門的な道具は要りません。ブラウザとメモがあればできるものを挙げます。
- 検索結果に出ている自社ページを、実際にクリックして開く。 検索窓に
site:自社ドメインと入れると、検索エンジンが把握しているページの一覧が出ます。上から順に開いて、404が出ないか確かめる - 記事を1本読み終えて、次に何ができるか見る。 問い合わせボタンも、関連記事も無ければ、読者はそこで離脱します
- スマホで開いて、表示が始まるまで数える。 3秒かかるなら写真が重すぎる可能性が高い
- 会社概要・よくある質問など、めったに触らないページを開く。 古い情報や、別の用途で作った文章が残っていることがあります
- 同じタイトルのページが複数ないか確かめる。 検索結果に同じ文字が並ぶと、どれを開けばいいか分からなくなります
このうち1と4は、実際に今回いちばん大きな問題が見つかった場所です。普段見ないページほど壊れています。
効果はこれから
正直に書くと、直した効果はまだ数字に出ていません。 検索順位もアクセスも、変更してすぐ動くものではありません。
分かっているのは、壊れていた箇所が実際に壊れていて、それを直したという事実だけです。効果は追って測り、動かなければそれも書きます。
同じ日にやった別の点検——AI検索で自社がどう見えているか——の結果はAI検索対策を売る会社が自社を測ったら10点だったに書きました。運用中の自動化がどれだけ動いているかを数えた記録は毎朝動いているはずのAI自動化41本を5.3日ぶん数えたらにあります。
まとめ
- 公開2週間のサイトを外から点検したら、検索結果に出ている237ページ中96ページが404だった
- 原因はニュースの保持件数。インデックスされる前にページが消える設定になっていた
- 記事213本・ニュース619本のすべてに問い合わせ導線が無く、読者が次に取れる行動が「戻る」だけだった
- 写真40.2MB→14.9MB、検索用データ1,020KB→407KBに削減した
- よくある質問が別メディアの内容のまま公開されていた。普段見ないページほど壊れている
- 「登録されていないのでは」「リンクが無いからでは」という仮説は3つとも外れた。測って確かめる価値はそこにある
- 更新停止を「見つけた」のは測り方の間違いだった。誤った測定は、無い問題を作り出す
この記事の実測条件 - 点検日: 2026年8月1日 - 対象: ai-oni.com（2026年7月19日公開） - 使った道具: Search Console API（表示・順位・URL検査）、curl、ブラウザの開発者ツール - 記事208本・ニュース個別2,761ページ・sitemap 685件
