大規模サイトの内部リンク設計｜評価を主戦場テンプレートに集約する【2026年版】

内部リンクの相談を受けたとき、最初に聞かれるのはたいてい「1ページあたり何本貼ればいいですか」です。この問いの立て方自体が、内部リンク施策がうまくいかない理由をよく表しています。

内部リンクは総量の問題ではなく、分配の問題です。サイト全体が持っている評価は有限で、内部リンクはそれをどのページに寄せるかを決める仕組みにすぎません。10万ページのサイトで闇雲にリンクを増やしても、増えるのは薄く広がったリンクの本数だけで、順位を取りたいページに届く分は変わりません。

本記事は、データベース型サイトや大規模サイトを前提に、内部リンクを「評価をどこに集めるか」の設計問題として扱います。診断手順、テンプレートへの実装、開発チームへの依頼粒度まで書きます。前半は中規模サイトでもそのまま使える内容です。

DB型サイト全体の設計についてはデータベース型サイトのSEO完全ガイドで扱っており、本記事はその内部リンク部分の詳細版にあたります。

1. 結論:内部リンクは「増やす」ものではなく「配る」もの

先に結論を書きます。

ここで言う「配る」は比喩ではありません。あるページが受け取っている内部リンクの本数と質は、そのページがサイト内でどれくらい重要だと見なされているかのシグナルになります。トップページから1クリックで到達でき、多くのページからリンクされているページは重要だと解釈され、逆に5階層下にあってどこからもリンクされていないページは、クロールすらされないまま放置されます。

DB型サイトで内部リンクが「壊れている」典型パターン

データベース型サイトの内部リンクは、そのほとんどが画面の都合で生えたものです。グローバルナビ、サイドバーの絞り込みUI、フッターのリンク集、詳細ページ下部の「関連する◯◯」——どれもUI設計の産物であって、SEOの評価設計として置かれたものではありません。

その結果、こういう状態が常態化します。

• ページ数が最も多い詳細ページ（求人詳細、物件詳細、商品詳細）が、リンクを大量に供給できる立場にありながら、供給先が「他の詳細ページ」ばかりで一覧に戻っていない
• 流入の主戦場である掛け合わせ一覧ページ（職種×地域など）が、絞り込みUIの奥にしか存在せず、トップから4〜5クリックかかる
• 一方で、SEO的にはどうでもいい利用規約やヘルプページが、全ページ共通フッターから数十万本のリンクを受けている

評価を集めたいページには集まっておらず、集まる必要のないページに集中している。 これがDB型サイトの初期状態です。内部リンク施策とは、この分配を設計し直す作業のことです。

「増やす」発想が効かない理由

中規模の記事メディアなら、関連記事リンクを丁寧に貼る運用は有効です。母数が数百ページなので、人手で分配をコントロールできるからです。

しかし数万〜数十万ページ規模では、人手での付与は物理的に不可能です。実際に効くのはテンプレートのリンク生成ロジックを1本書き換えることであり、これは1本の改修で数十万ページのリンク分配が同時に変わることを意味します。レバレッジも事故のリスクも、同じ大きさで存在します。

2. 内部リンクが持つ3つの機能

施策を設計する前に、内部リンクが何をしているかを分解します。この3つのどれを狙うかで、打ち手はまったく変わります。

①クロール経路の提供

Googlebotは基本的にリンクを辿ってページを発見します。XMLサイトマップも発見の補助にはなりますが、サイトマップに載っているだけでどこからもリンクされていないページは、優先度が低いと判断されやすいのが実務上の感覚です。

大規模サイトでこの機能が問題になるのは、次のようなケースです。

• 新規に生成されたページが、既存のどのページからもリンクされていない（孤立ページ）
• 一覧の2ページ目以降がJavaScriptでしか出力されておらず、詳細ページに到達する経路がない
• 階層が深すぎて、クロールの優先度が実質的にゼロになっている

クロール到達そのものが怪しい場合は、内部リンク以前にクロール側の診断が必要です。この領域は「クロールバジェット最適化の実務」で扱います。

②評価の伝達

外部から獲得した被リンクの評価は、内部リンクを通じてサイト内を流れます。外部リンクを直接獲得しにくい掛け合わせ一覧ページを、トップページやカテゴリ一覧が受けた評価で押し上げる——これが大規模サイトにおける内部リンクの主目的です。

ここで重要なのは、リンクを増やせば評価の総量が増えるわけではないという点です。増えるのは経路だけで、流れるものの総量は外部からの評価で決まっています。だから「配る」なのです。

なお、リンクにnofollowを付けて評価の流れをコントロールする、いわゆるPageRankスカルプティングは現在は機能しません。Googleは2009年時点でこの手法が意図通りに働かないことを明言しており、nofollowを付けた分が他のリンクに再配分されるわけではありません。内部リンクでnofollowを使う理由は、実務上ほぼありません。

③文脈・関連性の提示

アンカーテキストと、そのリンクが置かれた周辺のテキストは、リンク先ページが何についてのページかをGoogleに伝えます。これはリンク先ページ自身のtitleやh1を補強するシグナルとして働きます。

DB型サイトでこの機能が死んでいる典型が、「詳細はこちら」「もっと見る」で埋め尽くされたテンプレートです。6章で扱います。

3. 診断:リンクがどこに集まっているかを可視化する

現状の分配を測らずに設計を始めてはいけません。診断は3つの角度から行います。

3-1. 内部被リンク数をページ単位で集計する

Screaming Frog、Sitebulb、Ahrefs Site Auditなどのクロールツールでサイトをクロールし、各URLのInlinks（内部被リンク数）を出力します。これが最も情報量の多い作業です。

見るべきは個別URLのランキングではなく、URLパターンごとの集計です。エクスポートしたCSVをURLパターンで分類し、テンプレート別に集計します。

この表を埋めると、流入シェアとリンク集中度が一致していないテンプレートが一目で分かります。流入の6割を生んでいる職種×地域一覧の平均被リンク数が、ヘルプページより少ない——大規模サイトの診断では、この種の逆転が高い確率で見つかります。

3-2. リンクを「供給している」側を数える

もう一方向、どのテンプレートが最もリンクを供給しているかも測ります。総リンク本数 = そのテンプレートのページ数 × 1ページあたりの発リンク数なので、枚数が多いテンプレートが最大の供給源になります。

DB型サイトでは、ほぼ必ず詳細ページが最大の供給源です。30万枚の詳細ページが1枚あたり10本リンクを出していれば300万本。この300万本がどこに向かっているかが、サイト全体の分配をほぼ決定します。ここを設計するのが、DB型サイトの内部リンク施策の本体です。

3-3. Search Consoleの「リンク」レポート

Search Consoleの左メニュー「リンク」→「内部リンク」で、Googleが実際に認識している内部リンクの多い順にページが並びます。

クロールツールの結果と突き合わせて使います。差分が出たら理由を追う価値があります。ツールでは大量にリンクされているのにGSCでは上位に出てこないページは、そのリンクがGoogleに認識されていない（JavaScriptでしか出力されていない、リダイレクトを経由している等）可能性があります。

3-4. 階層の深さ（クリック深度）

トップページから何クリックで到達できるかを、クロールツールの Crawl Depth で確認します。

明確な閾値が公表されているわけではありませんが、実務上は主戦場のテンプレートが3クリック以内に収まっているかを目安にしています。掛け合わせ一覧が絞り込みUIの奥にしかなく5クリック必要、という状態は改善余地が大きいサインです。

4. 設計原則:DB型サイトの内部リンク4原則

診断で分配の歪みが見えたら、次の4原則で設計し直します。

原則1:主戦場のテンプレートに集約する

まず「どのテンプレートに評価を集めるか」を1つに決めます。求人サイトなら職種×地域の一覧、不動産なら沿線×駅×条件の一覧、ECならカテゴリ×属性の一覧。流入シェアが最も大きく、かつ検索需要が確実に存在するテンプレートです。

ここを決めないまま「関連リンクを充実させる」と、リンクは全方向に均等にばらまかれ、分配は何も変わりません。集約するとは、他を相対的に減らすこととセットです。

原則2:詳細ページから一覧への還流を作る

3-2で見たとおり、詳細ページは最大のリンク供給源です。この供給を主戦場の一覧に向けます。

求人詳細ページなら、その求人が属する属性から機械的にリンクを生成します。

求人詳細ページ（/jobs/{job_id}/）に出す一覧リンク
- 「{地域}の{職種}の求人一覧」   → /jobs/{職種}/{地域}/     ← 主戦場。必ず出す
- 「{職種}の求人一覧」           → /jobs/{職種}/
- 「{地域}の求人一覧」           → /area/{地域}/

ポイントは、リンク先をデータから機械的に決めることです。詳細ページが持っている属性値をそのままURLに変換すればよく、人手の判断は入りません。これで30万枚の詳細ページすべてが、自分に対応する主戦場ページへ確実にリンクを返します。

原則3:階層を浅く保つ

主戦場テンプレートへの到達経路を、トップから3クリック以内に設計します。具体的な打ち手は2つです。

• 一覧ページに、下位の掛け合わせ一覧へのリンクブロックを置く。職種一覧ページに「営業の求人を地域から探す」として都道府県リンクを並べれば、トップ→職種一覧→職種×地域一覧の2クリックになります
• 絞り込みUIのリンクをHTMLの<a href>で出力する。JavaScriptのイベントハンドラだけで遷移するUIは、クロール経路として存在しないのと同じです

ただし、すべての掛け合わせにリンクを出すのは逆効果です。需要のない掛け合わせや結果0件のページまでリンクを出すと、クロールと評価がそこに漏れます。リンクを出す条件は、ファセット設計の閾値ルール（検索需要と結果件数）と一致させてください。この判断基準は「ファセット・絞り込みURLのインデックス制御」で詳しく扱います。

原則4:パンくずを階層通りに実装し、BreadcrumbListを併設する

パンくずリストは、内部リンクの3機能をすべて同時に満たす、費用対効果の最も高い実装です。上位階層へリンクを供給し（②）、アンカーテキストで文脈を伝え（③）、クロール経路を作ります（①）。

実装上の注意は3点です。

• 表示上の階層とURL構造を一致させる。/jobs/sales/osaka/ のパンくずが「トップ > 求人を探す > 大阪」で職種階層を飛ばしている、という不整合はよくあります
• BreadcrumbList の構造化データを併設する。検索結果のパンくず表示に使われるだけでなく、階層の意図を明示できます
• パンくずのリンクは必ず<a href>で出力する。構造化データだけあって表示上のリンクがない実装は、②の機能を果たしません

5. ハブ&スポークをDB型サイトでどう作るか

記事メディアで言うトピッククラスタ（ハブ&スポーク）の考え方は、DB型サイトにもそのまま適用できます。対応関係はこうなります。

ハブ&スポークの本質は、スポークがハブに評価を集め、ハブがスポークに文脈を与えるという双方向の関係です。DB型サイトに置き換えると次のようになります。

• 詳細ページ（スポーク）→ 一覧ページ（ハブ）:原則2の還流。数の力で評価を集める
• 一覧ページ（ハブ）→ 詳細ページ（スポーク）:一覧に表示される各詳細へのリンク。クロール経路の供給
• 記事コンテンツ（スポーク）→ 一覧ページ（ハブ）:記事から主戦場への送客とリンク供給

記事コンテンツの役割は「DBで答えられない意図を拾って、一覧にリンクを供給すること」

DB型サイトで記事を書くべきかという相談はよく受けますが、答えは「役割を限定するなら書く価値がある」です。

DBから生成されるページは、データで答えられる検索意図しか満たせません。「営業 求人 大阪」には一覧ページが答えられますが、「営業職 志望動機 書き方」「宅建 独学 期間」にはデータでは答えられません。このDBの外側にある検索意図を記事で拾い、その記事から関連する一覧ページへリンクを供給する——これが記事コンテンツの役割です。

逆に言えば、主戦場の一覧ページと同じ検索意図を狙う記事は書くべきではありません。同一サイト内で同じ意図のページが2つあると、リンクも評価も分散し、どちらも中途半端になります。記事を追加するときは、それが既存の一覧テンプレートと意図で重複していないかを必ず確認してください。

記事から一覧へのリンクは、本文中の文脈のある位置に置きます。記事末尾に「関連サービス」として機械的に並べるより、本文中で「大阪の営業求人を探す場合は」と書いた流れでリンクするほうが、③の文脈提示の機能が働きます。

6. アンカーテキストの設計

テンプレートで自動生成する内部リンクのアンカーテキストは、生成ルールとして設計します。

「詳細はこちら」の何が問題か

「詳細はこちら」「もっと見る」「一覧へ」といったアンカーテキストは、リンク先が何のページかという情報をまったく含みません。内部リンクの3機能のうち、③文脈の提示がゼロになります。

さらに実務上の問題として、同じアンカーテキストが数十万ページに存在することになり、サイト内で「詳細はこちら」というテキストがどのページを指すのかが一意に決まりません。

ボタンUIとして「詳細はこちら」を残したい場合は、ボタンの近くにテキストリンクを併設するか、ボタンのラベル自体をデータから生成します。

# アンカーテキストの生成ルール例（求人詳細 → 一覧）
NG: 「一覧へ戻る」
OK: 「{地域}の{職種}の求人一覧を見る」
    → 「大阪府の営業の求人一覧を見る」

生成ルールの設計基準

テンプレートで自動生成する場合、次の基準で設計します。

過剰最適化の避け方

内部リンクのアンカーテキストで極端な最適化をするサイトは実務上あまり見ませんが、テンプレート生成では意図せず極端になることがあります。全ページのアンカーが完全一致キーワードだけになる、という状態です。

避け方はシンプルで、自然な日本語の文型に属性値を埋め込むことです。「{地域}の{職種}求人」という素のキーワード羅列ではなく、「{地域}で{職種}の求人を探す」「{地域}の{職種}求人一覧を見る」のように、リンクの文脈に応じて文型を変えます。ユーザーが読んで自然かどうかが唯一の判断基準で、それを満たしていれば過剰最適化にはなりません。

7. やりがちな失敗7つ

失敗1:全ページ共通フッターに大量リンク

フッターに主要カテゴリを数十本並べれば全ページからリンクされる、という発想はよくありますが、効果は薄いと考えたほうが安全です。全ページに同一の内容で存在するリンクは、そのページ固有の文脈を持たないためです。

もちろんフッターリンクが無意味というわけではなく、主要ハブへの導線としては置く価値があります。問題なのは、フッターに並べたことで施策が完了したと考えてしまうことです。分配を実際に動かすのは、詳細ページから一覧への文脈のあるリンク（原則2）のほうです。

失敗2:関連リンクの自動生成が無関係

「関連する求人」「この物件を見た人はこちらも」の生成ロジックが、更新日時順や単純なランダムになっているケースは非常に多いです。この場合、リンクは③文脈提示の機能を持たず、①クロール経路としてもノイズになります。

生成ロジックは、リンク元とリンク先が共有する属性を明示的に条件に入れる設計にします。「同じ職種かつ同じ都道府県の求人を新着順で5件」なら、リンクの意味が定義されています。

失敗3:リンク先が旧URLでリダイレクト経由

サイトリニューアルやURL変更のあと、内部リンクだけが旧URLを指したまま放置されているケースです。リダイレクトは機能するのでユーザーは気づきませんが、クロールに余計な1リクエストを挟むことになり、Search Consoleの「ページにリダイレクトがあります」も積み上がります。

内部リンクは常に最終URLを直接指すのが原則です。クロールツールで内部リンクのステータスコードが200以外のものを抽出すれば、まとめて洗い出せます。URL変更を伴う改修の際は、リダイレクト設定と同時に、テンプレート側のリンク生成ロジックの更新も要件に含めてください。

失敗4:内部リンクへのnofollow

2章で触れたとおり、nofollowで評価の流れを制御することはできません。加えて2020年以降、Googleはnofollowをクロールとインデックスに関するヒントとして扱うと明言しており、リンクを辿らせない確実な手段でもなくなっています。

クロールさせたくないURLがあるなら、nofollowではなくそもそもリンクを出力しない、robots.txtで制御する、といった手段を選びます。

失敗5:JavaScriptでしか出力されないリンク

onclick によるページ遷移や、スクロールに応じて生成されるリンクは、<a href> としてHTMLに存在しない限り、クロール経路として当てにできません。Googleはレンダリングを行いますが、初回のHTML取得とは別のキューで処理されるため、確実性が下がります。

判定方法はシンプルで、view-source: で生HTMLを見て、目的のリンクが <a href="..."> として含まれているかを確認します。含まれていなければ対応が必要です。JavaScriptサイトのレンダリング判断全般は「JavaScript・SPAサイトのSEO」で扱います。

失敗6:主戦場ページの孤立

診断（3章）で最も多く見つかる問題です。掛け合わせ一覧ページが絞り込みUIの動的な結果としてしか存在せず、静的なリンクがサイト内のどこにもない、という状態です。

この場合、主戦場ページへのリンク集を明示的に作る必要があります。職種一覧ページに都道府県リンクを並べる、地域一覧ページに職種リンクを並べる、といった実装です。ここでも、リンクを出す対象は需要と件数の閾値で絞ります。

失敗7:「1ページ100リンクまで」

かつてGoogleのガイドラインには「1ページのリンクは妥当な数（100本以下）に」という記述がありましたが、これは帯域制限が厳しかった時代の推奨で、現在のガイドラインからは削除されています。今も100本を基準として運用しているなら、根拠は失われていると考えて構いません。

とはいえ、1ページから数千本のリンクを出す設計が良いわけでもありません。判断基準を本数に置くのではなく、「そのリンクがユーザーにとって意味のある導線か」「そのリンク先が評価を集めるべきページか」で考えてください。

8. 実装と運用:テンプレートに実装する

個別ページに手で貼らない

大規模サイトの内部リンク施策は、すべてテンプレートのリンク生成ロジックとして実装します。個別ページに手で貼る運用は、数万ページ規模では維持できず、担当者が変わった時点で崩壊します。

したがって内部リンク施策の成果物は、原稿ではなく開発チケットです。ここでの翻訳の粒度が、実行できるかどうかを決めます。

開発依頼の粒度:対象・条件・実装・対象外・検証

親記事でも触れた5点セットを、内部リンクの依頼に当てはめるとこうなります。

【対象】求人詳細テンプレート /jobs/{job_id}/ の本文下部
【条件】常時表示。求人データに job_category_id と prefecture_id が設定されている場合
【実装】以下3本のテキストリンクを <a href> で出力する
  1. /jobs/{job_category_slug}/{prefecture_slug}/
     アンカー: 「{都道府県名}の{職種名}の求人一覧を見る」
  2. /jobs/{job_category_slug}/
     アンカー: 「{職種名}の求人一覧を見る」
  3. /area/{prefecture_slug}/
     アンカー: 「{都道府県名}の求人一覧を見る」
  - 都道府県名・職種名はマスタの正規化済み表記を使用（表記ゆれを持ち込まない）
  - JavaScriptによる後付け描画は不可。サーバー側レンダリングでHTMLに含める

【対象外】
  - 1のリンク先ページが存在しない、または掲載件数0件の場合は1を出力しない
    （2と3は出力する）
  - 既存の「関連する求人」ブロック（詳細→詳細）は今回変更しない

【検証】
  - 職種・都道府県の組み合わせ5パターンで view-source: して <a href> を確認
  - リンク先が全て200を返すこと（リダイレクト経由でないこと）
  - ステージングでクロールツールを回し、一覧テンプレートの内部被リンク数が
    増加していることを確認してから本番反映

「対象外」を明記することが特に重要です。これがないと、開発側が善意で「件数0件のページにもリンクを出しておこう」と範囲を広げ、薄いページへリンクが漏れる事故が起きます。

段階的に展開する

テンプレートのリンク生成ロジック変更は、数十万ページのリンク分配を一度に変えます。悪化した場合の被害も同じ規模です。

可能であれば、影響範囲を限定して先行検証してください。特定の職種カテゴリだけ、特定の地域だけ、といった単位で先に適用し、クロール配分と順位の変化を確認してから全体展開する進め方が安全です。

9. 効果測定:何をどう追うか

内部リンク施策の効果は、サイト全体の折れ線グラフでは見えません。リンクを集中させたテンプレート単位で、次の4つを追います。

順序に意味があります。内部リンク施策の効果は、順位より先にクロール頻度に表れます。 リンクを集中させたテンプレートのクロール頻度が上がっていなければ、そもそもリンクがGoogleに認識されていない可能性が高く、順位を待つ前に実装を疑うべきです。

Search Consoleの検索パフォーマンスは、ページのURLフィルタで /jobs/ を含む、といった条件を指定すればテンプレート単位で分解できます。サイトマップをテンプレート別に分割送信しておくと、インデックス率も同じ粒度で読めるようになります。

そして、いつ何を変えたかの記録を必ず残してください。テンプレート改修は影響範囲が広く、複数の施策が並行していると、後から効果を切り分けられなくなります。リリース日を縦線で入れたグラフを標準の運用にすることを推奨します。

10. よくある質問(FAQ)

Q. 1ページあたり、内部リンクは何本が適切ですか? A. 適切な本数という基準はありません。かつてGoogleのガイドラインにあった「100本以下」という記述は現在削除されており、根拠として使えません。本数ではなく、「そのリンクがユーザーにとって意味のある導線か」「リンク先が評価を集めるべきページか」で判断してください。大規模サイトで実際に問題になるのは本数ではなく、リンクの向き先が主戦場に集約されているかどうかです。

Q. 内部リンクを増やせば順位は上がりますか? A. サイト全体で均等に増やしても、順位はほとんど動きません。内部リンクは評価の総量を増やすものではなく、既にサイトが持っている評価の分配を変えるものだからです。効果が出るのは、特定のテンプレートに集中させ、他を相対的に減らしたときです。総量ではなく偏りを作る施策だと考えてください。

Q. 関連記事リンクは自動生成でも効果がありますか? A. 生成ロジック次第です。更新日時順やランダムでの生成は、関連性のシグナルを持たないため効果が期待できません。リンク元とリンク先が共有する属性（同じ職種、同じ地域、同じカテゴリ）を明示的に条件に入れた生成であれば、自動生成でも十分に機能します。大規模サイトでは、そもそも手動での付与が不可能なので、ロジックの品質を上げるのが正しい方向です。

Q. 内部リンクにnofollowを付けて、評価の流れを調整すべきですか? A. 調整できません。nofollowで評価の流れをコントロールする手法は、Googleが2009年時点で意図通りに機能しないことを明言しています。さらに2020年以降、nofollowはクロール・インデックスに関するヒントとして扱われるため、リンクを辿らせない確実な手段でもありません。クロールさせたくないURLがあるなら、リンク自体を出力しない設計にしてください。

Q. パンくずリストは本当に効果がありますか? A. 内部リンクの3機能（クロール経路・評価の伝達・文脈の提示）を同時に満たすため、実装コストに対する効果は高い施策です。ただし条件があります。表示上の階層とURL構造が一致していること、リンクが<a href>で出力されていること、BreadcrumbListの構造化データが併設されていること。構造化データだけあって表示リンクがない実装は、評価伝達の機能を果たしません。

まとめ:内部リンク設計の手順

1. 3機能のどれを狙うかを決める（2章） — クロール経路／評価の伝達／文脈の提示のどれか
2. テンプレート別に、被リンク数と流入シェアの対応表を作る（3章） — 分配の歪みを可視化する
3. 主戦場テンプレートを1つ決め、そこに集約する（4章） — 集約とは他を減らすこと
4. 詳細ページから一覧への還流を実装する（4章） — 枚数が多い側が最大の供給源
5. アンカーテキストを生成ルールとして設計する（6章） — 「詳細はこちら」を残さない
6. テンプレートへの実装として開発に依頼する（8章） — 対象・条件・実装・対象外・検証の5点
7. クロール頻度 → インデックス率 → 順位の順で追う（9章） — 効果はこの順に表れる

内部リンクは、外部リンクと違って自分たちの意思だけで100%コントロールできる数少ないSEO施策です。大規模サイトほど、その分配の歪みは大きく、直したときの効果も大きくなります。

自社サイトのどのテンプレートにリンクが集まっていて、どこに集めるべきか——具体的な診断はデータベース型サイトSEOコンサルティングでも承っています。サイト全体の設計についてはデータベース型サイトのSEO完全ガイドも併せてご覧ください。ご相談は無料です。

株式会社ハウクレイジー 代表取締役 関口拓人

早稲田大学在学中に月間数千万PVのメディアをゼロから立ち上げ、株式会社ゲームエイトの創業に参画。同社執行役員として月間3億PV規模サイトのSEO・広告事業を統括。業界No.1プログラミングスクールを運営する株式会社インフラトップのCMOを経て独立し、株式会社ハウクレイジーを設立。大規模メディアからデータベース型サイトまで、累計50サイト以上のマーケティング支援を実施。

プロフィール詳細

評価をどのテンプレートに集約すべきかは、既存の内部リンク集中度を測らないと決められません。現状の可視化から無料でお手伝いします。

無料で内部リンク設計を相談する