記事とサービスページをどうつなぐか - 内部リンク設計の基本

記事を増やしたのに問い合わせにつながらない。 その原因は、記事の内容よりも、記事からサービスページへ戻る道が弱いことにある場合が多いです。

内部リンクの役割は、回遊導線にとどまりません。 読者にとっては「次に読むべき場所」であり、Google にとってはページ同士の関係を理解する手がかりです。Google も、クロール可能なリンクと文脈のあるアンカーテキストを重要視しています。¹

KomuraSoft の Web制作・SEOトピック のような記事ハブは、記事とサービスページを往復しやすくするためにあります。 その前提があると、ホームページ制作 への導線も作りやすくなります。

この記事で使う言葉

「ピラーページ（テーマの中心となるハブページ）」「記事ハブ」は、呼び方が書き手によって揺れる言葉です。この記事では次の意味で使います。

ピラーページと記事ハブは役割が違います。 ピラーページは 読ませるページ、記事ハブは 選ばせるページ です。 サイトの規模が小さいうちは、ピラーページが記事ハブを兼ねていても構いません。

全体の構造

3 つの関係を図にすると、こうなります。

flowchart LR
    H["記事ハブ<br/>テーマの記事一覧"]
    A["記事<br/>個別の疑問に答える"]
    S["サービスページ<br/>何を頼めるか"]
    P["ピラーページ<br/>テーマ全体の受け皿"]
    Q["問い合わせページ"]

    H --> A
    A --> H
    A --> S
    S --> A
    S --> P
    P --> S
    S --> Q

図1: 記事ハブ・記事・サービスページ・ピラーページ・問い合わせをつなぐ全体構造。ほとんどの矢印が両方向にある。

大事なのは矢印の数ではなく、ほとんどの矢印が両方向にあることです。 片方向しかない場所が、あとで「行き止まり」になります。

1. 内部リンクの目的は、回遊ではなく理解です

内部リンクというと、関連記事を並べて回遊数を増やす話に見えがちです。 でも本質は、このページ群は何のテーマを扱っているのかを伝えること です。

たとえば、

• 記事からサービスページへ戻る
• サービスページからピラーページへ戻る
• 会社情報や問い合わせから相談導線へ進む

この往復ができると、ページは単発ではなくテーマの塊として見えます。

flowchart TB
    accTitle: 内部リンクの目的は理解
    accDescr: 内部リンクの本質は関連記事を並べて回遊数を増やすことではなく、このページ群は何のテーマを扱っているのかを伝えることであり、記事からサービスページへ、サービスページからピラーページへという往復ができるとページが単発ではなくテーマの塊として見えることを示す図。
    a0["内部リンクの目的"] -.->|"本質ではない"| a1["回遊数を増やす"]
    a0 -->|"本質"| a2["何のテーマの ページ群かを伝える"]
    a2 --> a3["記事とサービスページ・ ピラーページの往復を作る"]
    a3 --> a4["単発ではなくテーマの塊 として見える"]

図2: リンクは回遊の道具ではなく、テーマのまとまりを伝える設計。

この記事の知識マップ

内部リンクの本質は回遊数を増やすことではなく、記事・記事ハブ・サービスページ・ピラーページ・問い合わせページというページ群が何のテーマを扱っているかを伝えることにある。記事はサービスページへ、サービスページはピラーページと問い合わせページへ戻れる往復構造が重要で、アンカーテキストは「詳しくはこちら」のような一般的な言い回しを避け、リンク先の役割がそのまま分かる説明的な文言にする。実装面では、リンクはa要素とhref属性でクロール可能な形にし、内部リンクへのnofollow付与は避け、外部リンクにはsponsored・ugc・nofollowを用途に応じて使い分ける。パンくずリストやサイトマップも内部リンクを補う仕組みで、効果はSearch Consoleのリンクレポートで確認できる。

flowchart LR
    accTitle: 内部リンク設計の知識マップ
    accDescr: 記事・記事ハブ・サービスページ・ピラーページ・問い合わせページが往復する内部リンク構造、説明的なアンカーテキストの推奨、クロール可能なリンクやrel属性など実装上の注意点、パンくずリストやサイトマップとの関係を示す図
    internal_link["内部リンク"]
    service_page["サービスページ"]
    blog_article["記事"]
    pillar_page["ピラーページ"]
    contact_page["問い合わせページ"]
    article_hub["記事ハブ"]
    descriptive_anchor_text["説明的なアンカーテキスト"]
    generic_anchor_text["一般的な言い回しのアンカーテキスト"]
    crawlable_link["クロール可能なリンク"]
    rel_nofollow["rel=#quot;nofollow#quot;属性"]
    breadcrumb["パンくずリスト"]
    xml_sitemap["サイトマップ"]
    isolated_page["孤立したページ"]
    search_console["Google Search Console"]
    rel_sponsored["rel=#quot;sponsored#quot;属性"]
    outbound_link["外部リンク"]
    rel_ugc["rel=#quot;ugc#quot;属性"]
    blog_article -.->|"前提とする"| service_page
    service_page -.->|"前提とする"| pillar_page
    pillar_page -.->|"前提とする"| service_page
    service_page -.->|"前提とする"| contact_page
    article_hub -.->|"前提とする"| blog_article
    blog_article -.->|"前提とする"| article_hub
    descriptive_anchor_text -->|"推奨される対応"| internal_link
    generic_anchor_text -->|"用いるのは非推奨"| internal_link
    internal_link -->|"前提とする"| crawlable_link
    rel_nofollow -->|"用いるのは非推奨"| internal_link
    breadcrumb -->|"利用する"| internal_link
    xml_sitemap -.->|"軽減する"| isolated_page
    internal_link -->|"防止する"| isolated_page
    internal_link -->|"で確認できる"| search_console
    rel_sponsored -->|"推奨される対応"| outbound_link
    rel_ugc -->|"推奨される対応"| outbound_link
    rel_nofollow -->|"推奨される対応"| outbound_link

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全17件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. アンカーテキストは、リンク先の役割をそのまま書く

内部リンクで一番やりがちな失敗は、詳しくはこちら や こちら に逃げることです。 これだと、リンク先が何のページか分かりません。

良いアンカーテキストは、リンク先の役割がそのまま分かります。

Google は、リンクのテキストをページ理解の手がかりとして使います。 だからこそ、ホームページ制作 のように、リンク先の名前をそのまま置くほうが伝わります。²³ Google 自身も、良いアンカーテキストは「説明的で、ほどよく簡潔で、リンク元のページとリンク先のページの両方に関係している」ものだとし、click here のような一般的な言い回しを避けるよう案内しています。¹

flowchart TB
    accTitle: アンカーテキストの良し悪し
    accDescr: 「詳しくはこちら」のような文言ではリンク先が何のページか分からず、Googleはリンクのテキストをページ理解の手がかりとして使うため、説明的でほどよく簡潔、リンク元とリンク先の両方に関係する文言にし、リンク先の役割をそのまま書くほうが読者にも検索エンジンにも伝わることを示す図。
    b0{"アンカーテキストは"}
    b0 -.->|"こちら・詳しくはこちら"| b1["リンク先が何のページか 分からない"]
    b0 -->|"リンク先の役割を そのまま書く"| b2["読者にも検索エンジン にも伝わる"]
    b2 -.-> b3["判定: 文字だけ抜き出して 行き先が分かるか"]

図3: リンクの文字だけを抜き出して行き先が分かるかが、唯一の判定基準。

2.1 別の業種で書くとどうなるか

自社の言葉に置き換えやすいように、業種を変えた例も並べます。 リンクとして貼っていない、文言そのものの比較です。

判定はひとつだけです。 リンクの文字だけを抜き出して並べたときに、どこへ行くページか分かるか。 「詳しくはこちら」「実績紹介」だけが並ぶサイトは、この時点で判別できません。

3. 記事からサービスページへ戻す 3 つの動線

記事とサービスページは、少なくとも 3 か所でつながっていると強いです。

1. 記事の本文中
2. 記事の末尾の関連記事
3. サービスページの関連記事

この 3 つが揃うと、読者は記事を読んだあとに自然に次へ進めます。 たとえば、この記事からは ホームページ制作 に戻るのが自然です。

flowchart TB
    accTitle: 記事とサービスページをつなぐ3つの動線
    accDescr: 記事とサービスページは、記事の本文中、記事の末尾の関連記事、サービスページ側の関連記事の少なくとも3か所に導線を設けると移動しやすくなり、この3つが揃うと読者は記事を読んだあとに自然に次へ進めることを示す図。
    c1["1. 記事の本文中の リンク"] --> c4["3か所が揃う"]
    c2["2. 記事末尾の 関連記事"] --> c4
    c3["3. サービスページ側の 関連記事"] --> c4
    c4 --> c5["読んだあとに自然に 次へ進める"]

図4: つなぎ目は1か所ではなく、本文・記事末尾・サービスページ側の3か所。

4. サービスページからピラーページへ戻す

サービスページ側からも、ピラーページへ戻れる導線が必要です。 特に、単体サービスとピラーページが分かれている場合は、そこを行き来できることが大切です。

KomuraSoft では、ホームページ制作 を Web 側の相談入口として置き、そこから制作内容、SEO、問い合わせ導線の話に分ける構成にしています。 この形にしておくと、記事から来た人も、サービスページから来た人も、同じ相談の入口に集めやすくなります。

5. よくある失敗

内部リンクでよくある失敗はこのあたりです。

• どのページも同じ「詳しくはこちら」になっている
• 記事にだけリンクがあり、サービスページから戻れない
• ピラーページがあるのに、そこへ戻す導線がない
• 問い合わせページだけが孤立している

この状態だと、記事を読んだ人がどこへ進めばよいか分からなくなります。 孤立したページは、サイトマップを送信すればクロール自体は助けられますが、それはページの存在を検索エンジンに知らせる補助であって、読者が次に進む道の代わりにはなりません。⁴ 内部リンクは、数よりも 各記事から主要なハブ／サービスページへの戻り先が明確になっているか が大事です。

flowchart TB
    accTitle: よくある失敗と共通の症状
    accDescr: どのページも同じ「詳しくはこちら」になっている、記事にだけリンクがありサービスページから戻れない、ピラーページへ戻す導線がない、問い合わせページだけが孤立しているという失敗はいずれも、記事を読んだ人がどこへ進めばよいか分からなくなる症状につながり、大事なのは数より各記事から主要なハブ／サービスページへの戻り先が明確になっているかであることを示す図。
    d1["全部「詳しくはこちら」"] -.-> d5["進み先が分からない"]
    d2["サービスから戻れない"] -.-> d5
    d3["ピラーページへ戻す導線がない"] -.-> d5
    d4["問い合わせが孤立"] -.-> d5
    d5 --> d6["数より戻り先の明確さ"]

図5: 4つの失敗はどれも「戻る場所が決まっていない」ことに行き着く。

6. 実装で気をつけること

設計が正しくても、リンクの書き方によっては検索エンジンがたどれません。 Google は、a 要素に href 属性が付いている形でなければクロールできない と明記しています。¹

そのため、実装では次の 3 点を確認します。

JavaScript でリンクを動的に差し込むこと自体は問題になりません。 Google も、上記の HTML の形になっているならクロールできると案内しています。¹

rel 属性については、sponsored が広告や有料掲載、ugc が投稿・コメント由来のリンク、nofollow がそれ以外で関連付けたくない場合、という使い分けが案内されています。⁵ いずれも外部リンクを修飾するためのもので、自サイト内のページを検索エンジンに見せたくない場合は robots.txt の disallow ルールを使うよう案内されています。⁵ つまり、内部リンクに nofollow を付けて回るのは、設計としてまず間違いです。

flowchart TB
    accTitle: クロールできるリンクの形
    accDescr: Googleはa要素にhref属性が付いている形でなければクロールできないと明記しており、JavaScriptで挿入する場合も最終的にaとhrefの形になっていれば問題なく、rel属性は外部リンクを修飾するためのもので、内部リンクにnofollowを付けて回るのは設計として間違いであることを示す図。
    e1{"リンクの実装は"}
    e1 -->|"a要素+href属性"| e2["クロールできる （JS挿入でも最終形がこれならOK）"]
    e1 -.->|"spanやdivにクリック イベントだけ"| e3["検索エンジンが たどれない"]
    e2 -.-> e4["relの修飾は外部リンク用。 内部リンクにnofollowは間違い"]

図6: 設計が正しくても、a+hrefの形になっていなければたどられない。

7. サイト構造とパンくずリスト

内部リンクは本文中のリンクだけではありません。 パンくずリストは、そのページがサイト階層のどこにあるかを示す常設の内部リンクです。Google は、パンくずリストがサイトの理解と回遊を助けると説明しており、構造化データで示せば検索結果側にも反映されることがあります。⁶

階層設計は、次の 2 つを守れば大きく崩れません。

1. 1 テーマにピラーページは 1 つだけ置く。 似たピラーページが 2 つあると、記事の戻り先が毎回ぶれます。
2. どの記事からも、2 クリック以内でピラーページかサービスページに着く。 記事から記事へ延々とつながるだけの状態を作らないという意味です。

flowchart TB
    accTitle: 崩れない階層設計の2ルール
    accDescr: 1テーマにピラーページは1つだけ置くこと、どの記事からも2クリック以内でピラーページかサービスページに着くことの2つを守れば階層設計は大きく崩れず、似たピラーページが2つあると記事の戻り先が毎回ぶれ、記事から記事へ延々とつながるだけの状態も避けられることを示す図。
    f1["ルール1: ピラーページは 1テーマ1つ"] --> f3["階層は大きく崩れない"]
    f2["ルール2: 2クリックで ピラーページへ"] --> f3
    f1 -.-> f4["ピラーページが2つだと 戻り先がぶれる"]
    f2 -.-> f5["記事だけの連鎖を防ぐ"]

図7: 階層は2つのルールを守るだけで、戻り先がぶれなくなる。

なお、Google の案内はリンクをクロールできる形にすることとアンカーテキストを説明的にすることであって、1 ページあたりのリンク数の上限ではありません。¹ 数を目標にするより、自分たちで運用ルールを決めておくほうが実務的です。たとえばこう決めます。

• 同じリンク先を、1 つの段落の中で 2 回以上貼らない
• 本文中のリンクは、その段落を読む手が止まらない範囲にとどめる
• 記事末尾の関連記事は件数を先に決めて固定する。並び順にも意味を持たせる

8. 自分のサイトに当てはめる手順

ここまでの内容を、そのまま作業手順にすると次の 4 段階になります。 記事がある程度たまっているサイトなら、最初の 2 段階だけでも整理が進みます。

8.1 記事の棚卸し

まず、表を 1 枚だけ作ります。凝ったツールは要りません。

「戻り先」が空欄の行が、そのまま直す対象です。

8.2 ピラーページと記事ハブを決める

テーマ列を集計すると、記事が多く集まっているテーマが見えます。 そのテーマごとに、ピラーページを 1 つ決めます。既存のサービスページをピラーページとして使い回して構いません。

このとき、テーマが「なし」の記事が 3 本以上あるなら、それは新しいピラーページの候補です。 逆に 1 本しかないテーマは、無理にピラーページを作らず既存のピラーページに寄せます。

8.3 リンク配置の優先順位

全部を一度に直す必要はありません。効きやすい順に並べるとこうなります。

1. アクセスが多い記事から、サービスページへ戻す。 ここが一番早く効きます
2. サービスページから、その記事へ戻す。 片方向を往復に変えます
3. 記事ハブを整え、そこから各記事へつなぐ
4. ピラーページとサービスページを相互にリンクする
5. 残りの記事を上から順に処理する

8.4 逆向きを必ず作る

3 の手順まで来たら、8.1 の表に「戻り先」を書き足しながら進めます。 片方向のリンクを足しただけで終わると、5 章の「記事にだけリンクがあり、サービスページから戻れない」状態が再生産されます。

flowchart TB
    accTitle: 自分のサイトに当てはめる4段階
    accDescr: 記事の棚卸しの表を作り、テーマ集計からピラーページと記事ハブを決め、アクセスの多い記事から効きやすい順にリンクを配置し、最後に必ず逆向きのリンクを作って往復にするという4段階の作業手順を示す図。
    g1["8.1 記事の棚卸し表を作る （戻り先の空欄を見つける）"] --> g2["8.2 テーマ集計から ピラーページと記事ハブを決める"]
    g2 --> g3["8.3 効きやすい順に リンクを配置する"]
    g3 --> g4["8.4 逆向きを必ず作り 往復にする"]
    g4 -.-> g5["片方向で終えると失敗が 再生産される"]

図8: 手順は棚卸し→ピラーページの決定→配置→逆向きの4段階で、往復まで作って完了。

9. 効果をどう見るか

内部リンクの効果は、順位よりも先に 構造として意図どおりになっているか で確認できます。

Search Console のリンクレポートでは、サイト内リンクが多いページや、リンク元のテキストを確認できます。⁷ ここで見るのは次の 2 点です。

• ピラーページとサービスページが、サイト内リンクの多いページの上位に来ているか。来ていなければ、設計した戻り先に実際は貼れていません
• リンク元テキストとして「こちら」「詳細」ばかりが並んでいないか

そのうえで、直したページの表示回数とクリック数を、直す前と後で 同じ長さの期間 で比べます。 どのくらい動くかはサイトの規模と競合状況で変わるので、目安の数字を他社から借りてこないほうがよいです。

flowchart TB
    accTitle: 内部リンクの効果の見方
    accDescr: 効果は順位より先に構造として意図どおりかで確認し、Search Consoleのリンクレポートでピラーページとサービスページがサイト内リンクの上位に来ているか、リンク元テキストに「こちら」ばかり並んでいないかを見て、そのうえで表示回数とクリック数を直す前後で同じ長さの期間で比べることを示す図。
    h1["リンクレポートで構造を 確認する"] --> h2["ピラーページとサービスページが 上位に来ているか"]
    h2 --> h3["リンク元テキストが 「こちら」ばかりでないか"]
    h3 --> h4["表示・クリックを直す前後 で同じ期間で比べる"]
    h4 -.-> h5["目安の数字は他社から 借りない"]

図9: 順位より先に、構造が意図どおりかをリンクレポートで確かめる。

まとめ

内部リンク設計の基本は、記事を増やすことではなく、記事、サービスページ、ピラーページの往復を作ること です。 まずは Web制作・SEOトピック から ホームページ制作 に戻し、必要に応じて問い合わせ導線や記事設計の相談へ分岐する流れを作ると、導線が安定します。

記事のリンク先が迷いなく選べるようになると、検索にも読者にも優しいサイトになります。

関連記事

• 問い合わせが来ないサイトで、先に直すべき3つの場所
• サービスページをどう作るか - 技術系・B2B向けの整理手順
• Web制作・SEOトピック
• ホームページ制作

参考資料

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

関連する事例

実際の整理や改善の進め方が近い事例ページです。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

記事を増やしたのに問い合わせにつながらないのはなぜですか？

記事の内容よりも、記事からサービスページへ戻る道が弱いことが原因である場合が多いです。内部リンクの本質は回遊数を増やすことではなく、このページ群は何のテーマを扱っているのかを伝えることです。記事からサービスページへ、サービスページからピラーページ（テーマの中心となるハブページ）へ、という往復ができると、ページは単発ではなくテーマの塊として見えます。

内部リンクのアンカーテキストはどう書けばよいですか？

リンク先の役割がそのまま分かる文言にします。一番やりがちな失敗は「詳しくはこちら」や「こちら」に逃げることで、これだとリンク先が何のページか分かりません。Googleはリンクのテキストをページ理解の手がかりとして使うため、「ホームページ制作の進め方を見る」のように、リンク先の名前をそのまま置くほうが読者にも検索エンジンにも伝わります。

記事とサービスページはどこでつなぐべきですか？

少なくとも3か所に導線を設けると、記事からサービスページへ移動しやすくなります。記事の本文中、記事の末尾の関連記事、サービスページ側の関連記事です。この3つが揃うと、読者は記事を読んだあとに自然に次へ進めます。記事側にだけリンクがあってサービスページから戻れない状態は、よくある失敗の1つです。

内部リンクでよくある失敗は何ですか？

どのページも同じ「詳しくはこちら」になっている、記事にだけリンクがありサービスページから戻れない、ピラーページがあるのにそこへ戻す導線がない、問い合わせページだけが孤立している、の4つが典型です。この状態だと記事を読んだ人がどこへ進めばよいか分からなくなります。内部リンクは数よりも、各記事から主要なハブ／サービスページへの戻り先が明確になっているかが大事です。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。