自社サービスのブログで、記事を書き続けているのに検索からの流入がほとんど増えない時期がありました。2026年7月に原因が分かって、そのとき公開していた65本のうち40本が、数か月にわたって検索結果に出ていない状態だったと判明しました。
原因は canonical でした。技術的には単純な話ですが、気づくまでに時間がかかった理由の方に学びがあったので、そこを中心に書きます。
何が起きていたか
各ページの <link rel="canonical"> が指していた URL と、実際にサイトが配信されているホストがずれていました。canonical が指す URL にアクセスすると、リダイレクトが返る状態です。
検索エンジンから見ると、こうなります。ページを取得する。canonical を読む。「正規版はこちらだ」と言われた URL を取りに行く。するとリダイレクトが返る。正規版がどこにあるのか確定できない。
この状態のページは、インデックスの判断が保留されます。エラーとしては扱われないので、Search Console に赤い警告が出るわけでもありません。「検出 - インデックス未登録」という、見過ごしやすい分類に入っていきます。
ずれた原因も単純でした。正規ドメインの定義が、canonical・og:url・sitemap・構造化データでそれぞれ別の場所に書かれていて、片方だけ更新されたまま揃わなくなっていた。
なぜ数か月気づかなかったのか
3つ重なっていました。
1. 検索流入がゼロではなかった
65本のうち25本は正常にインデックスされていて、そこからの流入がありました。数字は少ないながら伸びていたので、「まだ育っていないだけ」と解釈してしまった。完全に止まっていれば、もっと早く疑ったはずです。
2. 公開直後のページだけ見ていた
新しい記事を出したあと、Search Console の URL 検査で1本だけ確認する習慣はありました。ただ、確認していたのは常に最新の1本で、過去の記事がどうなっているかを見ていませんでした。
URL 検査は1本ずつしか見られません。65本を毎回確認するのは現実的ではないので、結果として全体像を持たないまま運用していました。
3. 記事を書くことが指標になっていた
これが一番大きい。公開本数が積み上がっていくと、進捗している感覚が出ます。実際には、出した記事の6割が検索エンジンから見えていなかった。
出力の量を見ていて、結果を見ていなかった。 コンテンツ運用でいちばん陥りやすい状態だと思います。
どこを見れば分かったか
後から振り返ると、Search Console の「ページ」レポートで気づけました。
インデックス登録されているページ数と、公開している記事数を並べるだけです。65本出しているのに登録が25本なら、そこで異常が分かります。個別の URL 検査ではなく、総数の突き合わせです。
もう1つは、canonical が返すステータスコードの確認です。ページを取得して canonical の URL を抜き出し、その URL に対してリダイレクトを追わずにリクエストする。200 以外が返ってきたら異常。1行のコマンドで確認できます。
curl -sI "$(curl -s https://example.com/ | grep -o '<link[^>]*canonical[^>]*>' | grep -o 'https://[^"]*')" | head -1どう直したか
canonical を正しい値に直すのは1箇所の修正で終わります。時間がかかったのは、同じことを二度と起こさない形にするところでした。
正規ドメインの定義を1箇所に集約した
canonical、og:url、sitemap、robots、構造化データ、llms.txt。絶対URLを出力する場所すべてが、1つの定数を参照するようにしました。この定数を書き換えれば全部が同時に変わり、片方だけ古いという状態が作れなくなります。
このサイトでも同じ構造にしています。正規のドメインを1箇所の定数で持ち、他のどこにも書かないルールにしました。canonical、OG、sitemap、構造化データは全部その1箇所から出ます。
本番に対する自動チェックを入れた
定義を集約しても、配信側の設定が変われば同じことが起きます。実際、www から apex へのリダイレクトはホスティングのダッシュボード側にあって、リポジトリには存在しません。 コードを読んでも分からない設定が、canonical の正しさを左右します。
そこで、本番の URL に対して外から確認するスクリプトを毎日走らせています。見ているのは4つです。
- 主要ページが 200 を返し、リダイレクトを挟まないこと
- canonical が自分自身を指し、そのURLがリダイレクトを返さないこと
- sitemap に載っている URL が実在すること
- 計測タグが生きていること
依存パッケージなしで動く短いスクリプトで、異常があれば Issue が立ちます。コードを直すのではなく、壊れたことに翌日気づける状態にするのが目的です。
インデックスされない他の理由
canonical 以外にも、記事が検索結果に出ない原因はいくつかあります。今回の調査で一緒に確認した項目を挙げます。症状が同じなので、canonical だと決め打ちしない方がいいという意味でも役に立ちます。
sitemap に載っていない
記事を追加しても sitemap が更新されていない、という単純な見落としです。Nue の場合、sitemap は自動生成していましたが、Search Console 側の「最終読み込み日」が数か月前のまま止まっていました。 送信しただけでは再取得されないことがあります。
いまは記事を追加したタイミングで sitemap を再送信する処理を入れています。
sitemap の URL がリダイレクトを返す
canonical と同じ問題が sitemap でも起きます。sitemap に書かれた URL にアクセスしてリダイレクトが返ると、そのエントリは信用されにくくなります。sitemap の中身を1件ずつ叩いてステータスを確認する処理を、監視に入れました。
JavaScript でしか本文が出ない
クライアント側で描画する構成だと、取得はできても本文が読まれないことがあります。今回は静的配信だったので該当しませんでしたが、SPA 構成のサイトでは最初に疑う項目です。
確認方法は単純で、curl でHTMLを取得して本文が入っているかを見るだけです。
内容がほぼ同じ記事が複数ある
検索意図が重なる記事が2本あると、片方が検索結果から落ちます。Nue でも別途2組で起きていて、これは canonical とは無関係な、企画側の問題でした。
新しい記事の企画を作る前に、既存記事のタイトルと見出しを照合する工程を入れています。
監視で実際に見ているもの
毎日走らせているスクリプトは、依存パッケージなしの短いものです。中身はこれだけです。
- 主要ページに対してリダイレクトを追わずにリクエストし、300番台が返らないこと
- HTMLから canonical を抜き出し、それが自サイトのオリジンで始まること
- その canonical URL 自体にリクエストして、200 が返ること
- sitemap.xml / robots.txt / llms.txt が取得でき、中身が想定どおりであること
- sitemap に載っている URL（先頭20件）がリダイレクトを返さないこと
- 計測タグと、問い合わせフォームのスクリプトが読み込まれていること
異常があれば Issue が立ちます。直すのは人がやる。 自動で修正しようとすると、誤検知のときに壊す方向に動くので、検知までを自動化の範囲にしています。
実行に必要なのは Node だけです。認証情報も外部サービスも要らないので、どのサイトにもすぐ適用できます。
回復までにかかった時間
canonical を直したあと、インデックスは自動では戻りません。sitemap を再送信し、主要な記事を URL 検査から手動でリクエストして、少しずつ拾われるのを待つことになります。
ここは正直に書くと、まだ全部は戻っていません。 数か月インデックスされていなかったページは、再登録されても順位の立ち上がりが遅い。事故の影響は、直した時点では終わらないということです。
同じことを避けるために
技術的な結論は「正規ドメインを1箇所に集約する」で終わりですが、運用としての結論は別にあります。
公開本数を進捗の指標にしない。 月に1度でいいので、公開した記事数とインデックス登録数を並べて見る。この2つの数字が離れていないかだけを確認します。5分で終わります。
コンテンツを増やす仕組みは作りやすく、結果を見る仕組みは後回しになりがちです。Nue もそうでした。LLMOの記事でも書きましたが、効果の測り方が決まっていない施策は、成果を確認する手段がないまま走り続けることになります。
サイトの構造やインデックスまわりの相談はLLMO対策で受けています。既存サイトを見せていただければ、同じ状態になっていないかを確認できます。