テンプレート由来のリンクが、サイト全体を巻き込む ── 発リンクを点検する12項目（サイドバー404の実例つき）

01 いま何が起きているか — テンプレート由来のリンクは、全ページに効く

当サイトのサイドバーに、1年以上気づかれなかった404があった

2026年8月16日、当サイトのサイドバーに表示しているリンク集の中に、実際にはHTTP 404を返す外部リンクが1本見つかりました。freeformatter.com/html-escape.htmlというHTMLエスケープ変換ツールへのリンクです。この記事を書いている時点で改めて確認しても、依然として404のままです。

このリンクは、1つのファイルから全ページへ配信されていた

見つかったこと自体よりも重要なのは、このリンクがどこに書かれていたかです。当サイトのサイドバー領域は、サイドバーのリンク集をまとめた1つの共通テンプレートにまとめられており、これをサイト全体で共通利用するレイアウトファイルが読み込んでいます。つまり、1つのファイルに書かれた1本のリンクが、それを読み込む全ページに同時に配信されている状態です。記事を1本ずつ点検していては、この種の問題には気づけません。

個人ブログでも、同種の観測が報告されている

この種の問題は、当サイトだけの特殊な話ではありません。個人が運営するSEO観測ブログの記事(2026年公開)では、「同一のSEOテンプレート内で、インデックス更新されたURLからの発リンクが、内部リンク全体に影響を与える」という仮説が、自サイトのクロール状況の推移を追跡することで示されています。この記事は個人による観測であり、Google公式の見解ではありません。ただし、「テンプレートを共有するページ群は、リンク構造の面でも運命を共にする」という着眼点自体は、当サイトの実例とも重なる方向性です。この記事では、Google公式のドキュメントで裏づけられる範囲に絞って、具体的な確認手順を扱います。

02 なぜ・背景 — 内部リンクの発見と、クロールバジェットの関係

Googleは、リンクを辿って新しいページを見つける

Google Search Centralの公式ドキュメントLinks and Google Search(訳: リンクとGoogle検索)は、"Google uses links as a signal when determining the relevancy of pages and to find new pages to crawl."

(訳: Googleはページの関連性を判断し、クロールすべき新しいページを見つけるために、リンクをシグナルとして使用します。)と説明しています。同じドキュメントは"Every page you care about should have a link from at least one other page on your site."(訳: 大切にしているすべてのページには、サイト内の少なくとも他の1ページからのリンクがあるべきです。)とも述べています。つまり、テンプレートに埋め込まれたナビゲーション・パンくずリスト・サイドバーは、単なる見た目の装飾ではなく、Googleがサイトの構造を理解するための経路そのものです。

大規模サイトでは、クロールバジェットが有限資源になる

Google Search CentralのManage your crawl budget for large sites(訳: 大規模サイトのクロールバジェットを管理する)は、"soft 404 pages will continue to be crawled, and waste your budget."(訳: ソフト404のページはクロールされ続け、クロールバジェットを浪費します。)と警告しています。同ドキュメントはさらに、"If Google spends too much time crawling URLs that it shouldn't, Google's crawlers might not explore the rest of your site."

(訳: Googleが本来クロールすべきでないURLに時間を使いすぎると、クローラーがサイトの残りの部分を探索できなくなる可能性があります。)とも述べています。テンプレート由来の内部リンクが壊れていると、その壊れたリンクへ、全ページ分のクロールが繰り返し発生することになります。

内部リンクと外部リンクでは、影響の種類が違う

ここで区別しておく必要があるのが、自サイト内へのリンク(内部リンク)と他サイトへのリンク(外部リンク)の違いです。内部リンクが壊れていると、上で見たとおり自サイトのクロールバジェットに直接影響します。一方、01章で見たfreeformatter.comのような外部リンクが壊れていても、Googleが自サイトをクロールする効率そのものには直接影響しません。ただし、外部リンクにも別の問題があります。読者が実際にクリックして404に遭遇するという、体験としての壊れ方は、内部・外部を問わず同じです。

テンプレートが「同じ運命」を作る

01章で紹介した個人ブログの観測が着目していたのも、この「同じテンプレートを共有するページ群が、リンク構造の面でも同じ状態を共有してしまう」という構造です。1つのテンプレートファイルに書かれたリンクは、それを読み込む全ページに一律に配信されます。個別記事の本文中のリンクなら1本の被害で済むものが、テンプレート由来だとページ数倍に膨れ上がる、という違いを押さえておく必要があります。

03 この記事で出てくる用語

テンプレート由来リンクとクロールバジェット

404・410・301・308の違い

rel="nofollow" / "sponsored" / "ugc"の使い分け

01章で見たとおり、今回のリンクにはnofollowが付いていました。Google Search CentralのQualify your outbound links to Google(訳: Googleへの発リンクを適格化する)は、広告・有料掲載リンクにはsponsored、コメント欄などユーザー生成コンテンツへのリンクにはugcを使うべきだとしたうえで、"Use the nofollow value when other values don't apply."(訳: 他の値が当てはまらない場合は nofollow 値を使用してください。)と説明しています。nofollowは「リンク評価を渡さない」という指示であり、「壊れていても構わない」という意味ではありません。この区別は、次章のチェックリストでも扱います。

ソフト404

04 何が確認でき、何がまだ確認できないか

🄰 適用範囲 — どの規模のサイトで重要になるか

02章で扱ったクロールバジェットの話は、Google自身が「大規模サイト向け」のドキュメントとして公開しているものです。ページ数が少ないサイトでは、クロールバジェットが不足して機会損失が起きる可能性は相対的に低いとされています。ただし、テンプレート由来のリンクが全ページに配信されるという構造そのものは、サイト規模に関係なく成り立ちます。読者の体験としての壊れたリンクは、ページ数が1桁でも100桁でも同じように起きます。

🄱 この記事が測っていないこと

01章で紹介した個人ブログの観測は、あくまで1つのサイトにおける、ある期間の推移の観測です。Googleのアルゴリズムがどう内部処理しているかを保証するものではなく、他のサイトで同じ現象が同じ強さで再現される保証もありません。また、この記事のチェックリストはリンク切れの発見と分類を扱うものであり、リンク切れを修正した結果として順位やクロール頻度がどう変化するかまでは、個別に検証しないと分かりません。

🄲 手順 — Search Consoleで内部リンクの状態を確認する

Search Consoleの「クロール統計情報」レポートでは、直近のクロール履歴をHTTPステータスコード別に確認できます。Crawl Stats report(訳: クロール統計情報レポート)のヘルプページによれば、4XX(クライアントエラー)の割合が確認でき、404の発生源を個別に特定する手がかりになります。ただしこのレポートは"advanced users"(上級者)向けとされており、数値の読み方には一定の慣れが必要です。

ソフト404は、ステータスコードだけでは見つからない

03章で触れたソフト404は、HTTPステータスコード自体は200を返すため、単純なステータスチェックでは検出できません。実際にページを開いて内容を目視するか、Search Consoleの「ページ」レポートで「ソフト404」として分類されているURLを確認する必要があります。テンプレート由来のリンクがソフト404のページを指している場合、この見落としは特に発見しにくくなります。

05 自分のサイトで確認するチェックリスト

12項目の観点

ここまでの内容を、今日から自分の手で確認できる動作に翻訳しました。観点は大きく3つです。ひとつはテンプレート由来のリンクを洗い出して点検すること、ふたつめはSearch Console側の数字で裏づけを取ること、みっつめは見つかったリンク切れをどう直すか判断することです。チェックの状態はブラウザ内にのみ保存され、サーバーには送信されません。

• サイトのヘッダー・フッター・サイドバーで使われているテンプレートファイルを一覧化し、そこに含まれる発リンクの本数を数える
• その発リンクを1本ずつ開き、HTTPステータスが200であることを確認する
• 404を見つけたら、そのリンクが何個のテンプレートファイルに書かれているかを特定する
• 同じリンクが複数のページから表示される場合、修正が1ファイルの編集で全ページに反映されるかを確認する
• Search Consoleの「クロール統計情報」レポートを開き、直近3か月の4xxレスポンスの割合を書き出す
• サイトマップに含まれるURLを5件サンプリングし、実際にクロールされ200で応答するか確認する
• 主要ページを1つ選び、そのページのHTMLソースを開いて外部発リンクをすべて書き出す
• 書き出した外部発リンクに rel="nofollow" が付いているか、付いていないかを確認する
• 直近1年以内に更新していないページを5件選び、そこからの発リンクが今も生きているか確認する
• 見つかったリンク切れについて、恒久的に消えたページなら404のまま残すか、移転先があるなら301を設定するかを判断して書き出す
• 当サイトのリンクチェックツールでサイト全体を1回スキャンし、リンク切れの総数を記録する
• Search Consoleの「ページ」レポートで「ソフト404」に分類されているURLの件数を確認する

手を動かす順番の目安

最初の4項目はテンプレート由来リンクの洗い出しと影響範囲の特定、5番目から6番目はSearch Console側の裏づけ、7番目から9番目は外部リンクの点検、最後の3項目は修正判断とツールでの総点検です。すべてに30分程度かかります。まずはサイトのヘッダー・フッター・サイドバーという、最も配信範囲が広い3箇所から始めることをおすすめします。

06 リンク切れを点検する方法の比較

4つの点検手段、それぞれの向き不向き

05章のチェックリストで使った点検方法を、確認できることとできないことで整理すると、以下のようになります。

方法	確認できること	確認できないこと
手動での 目視確認	実際の見た目・ソフト404の発見	サイト全体を短時間で網羅すること
クロール統計情報 Search Console	4xx・5xxの割合、サイト全体の傾向	どのリンクが原因かの個別特定
当サイトの (🔧 リンク漏れ・チェックツール・無料)	サイト全体のリンク切れを一括スキャン	クロール頻度への実際の影響度
ブラウザの 開発者ツール	1ページ単位でのリクエスト内訳	サイト全体の一括把握

それぞれの方法が測っていないこと

4つを組み合わせても埋まらない空白があります。手動での目視確認は、ソフト404のような「ステータスコードでは分からない壊れ方」を見つけられる一方、サイト全体を短時間で網羅するのには向きません。Search Consoleのクロール統計情報は、サイト全体の傾向をつかめても、どのテンプレートファイルが原因かまでは教えてくれません。当サイトの🔧 リンク漏れ・チェックツールは、サイト全体のリンク切れを一括でスキャンできますが、そのリンク切れが実際のクロール頻度にどれだけ影響しているかまでは示しません。

点検の頻度についての考え方

02章で確認したとおり、外部サイトのページは運営者の都合で予告なくURLが変わったり閉鎖されたりします。一度点検して終わりにするのではなく、四半期に1回など、定期的な点検のサイクルに組み込むことをおすすめします。特にテンプレート由来のリンクは影響範囲が広いため、点検の優先順位を本文中のリンクより高く置くのが合理的です。

07 リンク切れを直すときの確認先

まずリンク元を直す、リダイレクトはその次

04章で触れたとおり、リンク切れを見つけたときの基本はリンク元(テンプレートまたは本文)を直接書き換えることです。移転先のURLが分かっている場合は、そちらへリンク先を差し替えれば済みます。移転先が分からず、恒久的に削除されたと判断できる場合は、Redirects and Google Search(訳: リダイレクトとGoogle検索)が説明するとおり、自サイト内のページであれば301リダイレクトで受け皿を用意することもできます。外部サイトのリンク切れは、自分でリダイレクトを設定できないため、リンクを削除するか、代替の情報源に差し替えるほかありません。

404にするか410にするかの判断

03章で確認したとおり、404と410はどちらも「存在しない」ことを伝えるコードです。Common HTTP network error codes and Google Search(訳: 一般的なHTTPネットワークエラーコードとGoogle検索)は"All 4xx errors, except 429, are treated the same: Google crawlers inform the next processing system that the content doesn't exist."(訳: 429を除くすべての4xxエラーは同じように扱われます。Googleのクローラーは、コンテンツが存在しないことを次の処理システムに伝えます。)と説明しており、Googleの扱いという意味では404と410に大きな差はありません。自サイトのページを恒久的に削除する場合は、どちらを使っても実務上の支障は小さいと考えられます。

サイトマップとの整合も確認する

Google Search CentralのBuild and submit a sitemap(訳: サイトマップの構築と送信)は、"サイトマップ送信は単なるヒントであり、Googleがクロールを保証するものではない"としたうえで、「サイトマップにはGoogleの検索結果に表示させたいURLを含めるべきだ」という方針を示しています。リンク切れの修正と合わせて、そのURLがサイトマップに含まれているか、削除したページが誤ってサイトマップに残っていないかも確認しておくと、内部リンクとサイトマップの整合が取れた状態を保てます。

定期点検をルーチンに組み込む

06章で触れたとおり、外部リンクは自サイトの都合とは無関係に壊れていきます。GoogleのSEOスターターガイドが「新しいページをGoogleが発見する最も一般的な方法はリンクを通じてである」と説明しているとおり、リンク構造はサイトの発見可能性そのものに関わります。テンプレート由来のリンクを優先し、四半期ごとなど無理のない頻度で、点検のサイクルを回し続けることをおすすめします。

08 このテーマの、これまで

テンプレート1行の配置ミスが、1153記事に及んだ回

テンプレートの1行が全ページに影響する構造は、当サイトが過去に実際に踏んだ事故としても記録しています(archives/43)。この回では、HTTP 200が返っているのに実際には配置ミスが起きていたケースを、24時間越しに自分で発見した経緯を扱いました。本記事01章の「1つのファイルが全ページに配信される」という構造は、この回で踏んだ事故と同じ土台に立っています。

sitemap・canonical・内部リンク・末尾スラッシュの整合を確認した回

内部リンクを含む4つの要素の整合性を、curl 3行で確認する手順を記録した回があります(archives/39)。本記事07章で触れたサイトマップとの整合確認は、この回で扱った手順の一部です。

内部リンク設計とトピカルマップを扱った回

内部リンクを記事同士のつながりとして設計する考え方を、トピカルマップの実践とともにまとめた回があります(archives/6)。本記事はテンプレート由来のリンクを扱いましたが、この回は本文中の内部リンクを扱っており、両方を組み合わせて初めて、サイト全体のリンク構造が見えてくるという関係にあります。

「指定した場所は死んでいて、指定しなかった場所が生きていた」回

自分が想定した場所とは別の場所が、実際には効いていた・使われていたという実測を記録した回があります(archives/131)。本記事01章のサイドバーの実例も、記事本文ではなく誰も個別には点検していなかったテンプレートで見つかったという点で、同じ構造の落とし穴でした。

重複記事をタイトルと元記事、2つの方法で確かめた回

自サイト内の重複を、タイトルの一致と元記事のURLの一致という2つの方法で確認し、結果が3倍近く違った実測を記録した回もあります(archives/129)。1つの確認方法だけに頼らないという姿勢は、本記事06章で「4つの点検方法を組み合わせる」と述べた考え方と同じです。