関連記事ウィジェットは内部SEOではない｜本文内部リンクの棚卸し手順

内部リンクの棚卸しとは、グローバルナビ・パンくず・関連記事ウィジェットのようなテンプレート由来のリンクを除外したうえで、各ページが「本文の中から」何本リンクされているかを数える作業です。目的は本数を増やすことではなく、1本も張られていない孤立ページと、同じ集団の内側だけでリンクが循環しているリンクの島を見つけることにあります。

この作業が抜け落ちる理由ははっきりしています。多くの現場で「関連記事ウィジェットを入れてある」＝「内部リンクは対応済み」として処理されているからです。ウィジェットはリンクとして機能はします。ただし、どのページからどのページへ張るかとアンカーテキストに何と書くかだけは、置いた本人にも制御できません。

この記事では、Google公式が実際に書いていることだけを根拠に判定基準を組み立て、Python標準ライブラリだけで動く走査スクリプトと合否ラインを示します。あわせて、この手順を筆者自身のサイト（363記事）に実際に回した結果も開示します。結果は、本文由来の被リンクが0本の記事が40本、そしていま読んでいるこのページ自身が、被リンク6本を持ちながら90日間の検索表示0でした。

関連記事ウィジェットを置くことは、内部リンク設計ではない

先に、よくある言い方をひとつ否定しておきます。「関連記事ウィジェットにSEO効果はない」という説明は不正確です。ウィジェットが出力するのも通常の <a href> であり、クローラはそこを辿ります。問題は効果の有無ではなく、制御できる範囲がどこまでかにあります。

ウィジェットが効く部分と、制御できない部分

Googleは「リンクは発見経路である」と明言しています。SEOスターターガイドには “In fact, the vast majority of the new pages Google finds every day are through links”（Googleが毎日見つける新規ページの大半はリンク経由である）とあります。ウィジェットのリンクもこの「リンク」に含まれるため、発見経路としては確かに機能します。

一方、アンカーテキストについてGoogleは条件を示しています。“Good anchor text is descriptive, reasonably concise, and relevant to the page that it’s on and to the page it links to.”（良いアンカーテキストとは、説明的で、適度に簡潔で、そのリンクが置かれているページとリンク先ページの両方に関連しているもの）。悪い例として Bad (too generic)（「詳しくはこちら」「続きを読む」）と Bad (weirdly long)（1文まるごとをリンクにしたもの）の2種類が挙げられています。

自動ウィジェットの出力は、ほぼ必ずこの2つの悪い例のどちらかに落ちます。記事タイトルをそのまま出せば「長すぎる」側に、「関連記事」「あわせて読みたい」だけを出せば「一般的すぎる」側に寄るためです。整理すると次のようになります。

つまりウィジェットは「リンクを増やす装置」ではあっても、「どこに集めるかを決める装置」ではありません。この違いを埋めるのが棚卸しです。

「評価基準を持たない」とは、具体的に何が起きることか

ウィジェットを入れた時点で、進行管理上は「内部リンク対応済み」というステータスが立ちます。ここで止まる原因は知識不足というより、合否ラインが存在しないことにあります。「何本あればよいのか」「どのページが足りていないのか」を数字で言えない限り、対応済みという報告を誰も反証できません。

これはWeb業界に固有の話ではありません。自動車業界でも保険代理店業でも、肩書きだけで役割を担う人が増えると全体の成長が止まる、という同じ構図を見てきました。共通しているのは、評価する側が「何をもって合格とするか」を数字で持っていないことです。逆に言えば、合否ラインさえ数字で置ければ、実装経験の有無にかかわらず判定はできます。制作側を評価する立場の線引きそのものについては制作スキルの有無で分けるディレクションとディレクターの違いで扱っています。

内部リンクの棚卸しとは何か

棚卸しで測るのは2つだけです。①各URLが本文中から何本リンクされているか（本文由来の被リンク数）と、②そのリンク元が何種類の集団に散っているか。この2つ以外は見ません。

Googleが実際に言っていること／言っていないこと

内部リンクの話には、公式にどこにも書かれていない前提が数多く混ざっています。判定基準を作る前に、公式の記述だけを切り出しておきます。

ここから引き出せる結論は明快です。本数の正解は公式には存在しない。ただし「0本」だけは、公式が明示的に外れていると言える唯一の状態です。だから棚卸しの一次的な出力は「何本あるか」ではなく「0本のURLはどれか」になります。

なお、見出し階層を整える理由はアクセシビリティと可読性であって順位施策ではありません。ここを取り違えると、順位が動かないときに見出しを触り続けることになります。

なぜテンプレート由来のリンクを外すのか

テンプレート由来のリンクを数に入れると、判定そのものが死にます。グローバルナビは全ページに同じリンクを出すため、ナビに載っているURLは自動的に「被リンク数＝全ページ数」になり、載っていないURLとの差が極端に開くだけで、記事同士のつながりの有無が一切見えなくなります。

除外すべきなのは次の6種類です。いずれも「書き手が意図して張ったのではないリンク」という一点で共通します。

• グローバルナビ・ドロワーメニュー
• パンくずリスト
• 前の記事／次の記事ナビ
• 関連記事ウィジェット・人気記事ランキング
• サイドバー（カテゴリ一覧・最近の投稿など）
• フッター

6種類を個別に除外する必要はありません。本文コンテナの内側にある <a href> だけを見るという1つのルールで、6種類とも自動的に外れます。この判定は、どのページにどの記事を配置するかという上流の設計とは別レイヤーの作業です。上流側はページ洗い出しから階層を組み立てるサイト構造の設計手順にまとめています。

本文由来の被リンクを数える手順

必要なのは Python 3 だけです。外部ライブラリもクローリングツールの契約も要りません。手順は3つに分かれます。

手順1｜sitemapから母集団を作る

母集団はsitemapから作ります。sitemapは「自分が検索に出したいと宣言したURLの集合」であり、棚卸しの対象範囲としてこれ以上に妥当なものがないためです。まず自分のsitemapの形を確認します。

# WordPress標準は /wp-sitemap.xml、Yoast等のプラグイン利用時は /sitemap_index.xml
curl -sSL https://example.com/sitemap.xml | grep -o '<loc>[^<]*</loc>' | wc -l

返ってきた数が数件しかない場合、それはsitemapインデックス（子sitemapの一覧）です。WordPress標準では投稿・固定ページ・カテゴリ・タグ・著者などが子sitemapに分かれているため、走査対象は投稿と固定ページの子sitemapに絞ります。カテゴリやタグのアーカイブは本文を持たないので、被リンクを数える対象には向きません。

この段階でURL表記が揺れていると、同じページが2行に割れて集計が壊れます。www の有無・末尾スラッシュの有無・パラメータ付きURLが混在していないかを先に確認してください。URLの決め方そのものに不安がある場合はSEO観点で失敗しないURL設計・ディレクトリ構造の決め方を先に読むほうが早いはずです。

手順2｜本文コンテナのclass名を特定する

次に、本文全体を囲んでいる要素のclass名を調べます。ブラウザで記事を開き、本文の任意の場所を右クリックして「検証」を選び、本文全体を包んでいる div のclassを読み取ります。コマンドで候補を洗い出すこともできます。

curl -sSL https://example.com/記事のURL/ | grep -o 'class="[^"]*content[^"]*"' | sort -u

候補は複数返ります。実際にこのサイトで実行すると footer-content / main-contents / mobile-drawer-content / post-content / site-content の5つが出ました。この中から選ぶ基準は「その要素の直後に本文の最初の見出しが来るか」です。ここでは post-content が該当します。WordPressの一般的なテーマでは entry-content であることが多く、テーマによって名前は変わります。

注意点が2つあります。1つ目は、正規表現で本文コンテナを切り出そうとしないことです。本文の中には div が入れ子で何層も入っており、最初に見つかった </div> で切ると本文が途中で切れます。HTMLパーサで開始タグと終了タグの深さを数える方法をとります。

2つ目は、同じclass名がページ内の別の場所でも使われていることがあるという点です。これは筆者が実際に踏み抜きました。このサイトのサイドバーにある「月間人気記事」ウィジェットが、記事タイトルを包む要素に本文と同じ post-content を使っていたため、全ページのサイドバーに並ぶ10本のリンクが本文由来として集計されていたのです。次のコマンドで出現回数を数えれば事前に気づけます。

curl -sSL https://example.com/記事のURL/ | grep -o 'class="post-content"' | wc -l

返り値が1なら安全です。2以上なら本文以外でも使われています。対処は簡単で、最初に見つかった1つだけを本文とみなし、それが閉じたあとは見ないようにします。次のスクリプトはこの処理を入れてあります。

手順3｜スクリプトを走らせて集計する

集計時に落とすものは3種類です。

以下が全体のスクリプトです。先頭4行を自分のサイトに合わせて書き換えるだけで動きます。WAIT は自分のサーバーへの負荷を抑えるための待機秒数です。

import re, sys, time, urllib.request, urllib.parse
from html.parser import HTMLParser

SITEMAP    = "https://example.com/wp-sitemap.xml"   # 自分のサイトのsitemap
BODY_CLASS = "post-content"                          # 手順2で特定したclass名
CHILD      = ("posts-post", "posts-page")            # 走査する子sitemap
WAIT       = 0.5                                     # 1リクエストごとの待機秒数

def get(url):
    req = urllib.request.Request(url, headers={"User-Agent": "inlink-audit/1.0"})
    with urllib.request.urlopen(req, timeout=30) as r:
        return r.read().decode("utf-8", "replace")

def sitemap_urls(url):
    xml  = get(url)
    locs = re.findall(r"<loc>(.*?)</loc>", xml)
    if "<sitemapindex" in xml:
        return [u for c in locs if any(k in c for k in CHILD) for u in sitemap_urls(c)]
    return locs

class BodyLinks(HTMLParser):
    """最初に現れた本文コンテナの内側にある a href だけを拾う"""
    def __init__(self):
        super().__init__(); self.depth = 0; self.done = False; self.links = []
    def handle_starttag(self, tag, attrs):
        d = dict(attrs)
        if tag == "div":
            if self.depth:                                     self.depth += 1
            elif not self.done and BODY_CLASS in (d.get("class") or "").split():
                self.depth = 1
        elif tag == "a" and self.depth and d.get("href"):
            self.links.append(d["href"])
    def handle_endtag(self, tag):
        if tag == "div" and self.depth:
            self.depth -= 1
            if self.depth == 0: self.done = True   # 本文はここで終わり。以降は見ない

def to_path(href, base):
    if href.startswith(("#", "mailto:", "tel:", "javascript:")):
        return None
    p = urllib.parse.urlsplit(urllib.parse.urljoin(base, href))
    if p.scheme not in ("http", "https") or p.netloc != urllib.parse.urlsplit(base).netloc:
        return None                                # 外部サイトは数えない
    return re.sub(r"/+$", "", p.path) + "/"        # 末尾スラッシュに正規化

urls    = sitemap_urls(SITEMAP)
inbound = {to_path(u, u): set() for u in urls}
selfref = []
print(f"母集団: {len(urls)} URL", file=sys.stderr)

for i, url in enumerate(urls, 1):
    me = to_path(url, url)
    try:
        page = BodyLinks(); page.feed(get(url))
    except Exception as e:
        print(f"SKIP {url} ({e})", file=sys.stderr); continue
    for href in page.links:
        t = to_path(href, url)
        if t is None: continue
        if t == me:   selfref.append(me); continue    # 自己リンクは数えない
        inbound.setdefault(t, set()).add(me)
    time.sleep(WAIT)
    if i % 50 == 0: print(f"  {i}/{len(urls)}", file=sys.stderr)

print("被リンク数\tURL\tリンク元")
for path in sorted(inbound, key=lambda p: (len(inbound[p]), p)):
    print(f"{len(inbound[path])}\t{path}\t{','.join(sorted(inbound[path]))}")
print(f"\n自己リンク: {len(selfref)}件 {sorted(set(selfref))}", file=sys.stderr)

実行するとタブ区切りで結果が出ます。被リンク数の少ない順に並ぶので、先頭が孤立ページです。

python3 inlinks.py > inlinks.tsv

# 孤立ページ（被リンク0本）だけを取り出す
awk -F'\t' '$1 == 0' inlinks.tsv

結果はページ数ぶんのリクエストを伴います。363記事のサイトで待機0.5秒を入れて実行し、5分弱で完了しました。棚卸しの結果をサイト構成図の側へ反映したい場合はフォルダ構成を図にするディレクトリマップの作り方を併用すると、どの階層にリンクが集まっていないかが見えるようになります。

【検証】自分のサイトの孤立ページとリンクの島を判定する

出力が手に入ったら、次の基準で1行ずつ判定します。判定に使うのは被リンク数と、リンク元の広がりの2つだけです。ここでいう「クラスタ」とは、同じ連載・同じカテゴリ・同じ商品ラインなど、読者から見て一続きに見えるページの集まりを指します。

合否ラインと次の一手

最後の行が、本数だけを見ていると必ず取りこぼすケースです。本数は基準を満たしているのに、リンク元がひとかたまりに閉じているという状態があり得ます。次章では、この状態が実際にどう見えるかを筆者のサイトの数字で示します。なお、同じクラスタ内で似たテーマのページが増えすぎている場合は、リンク不足ではなくページ同士の食い合いが起きている可能性もあります。その切り分けは自分のサイト同士で検索順位を食い合うカニバリゼーションの解説のほうが適しています。

数字が合わないときに疑うこと

最後の行は特に重要です。Search Consoleに載っていない＝被リンク0本、という判定はできません。 同じヘルプには、非インデックスページなどの理由でURLが省略されうることも書かれています。母集団は自分のsitemapとHTMLから作り、Search Consoleは「外部サイトからのリンク」を見る補助として使うのが正しい順序です。

効果の確認は2週間後に1回だけ

リンクを張ったら、2週間後に同じスクリプトをもう一度回して、対象URLの被リンク数が意図どおり増えたかだけを確認します。順位が上がったか、流入が増えたかまでは、この検証では追いません。リンクの効果が出るまでの期間が読めないうえ、同じ期間に加えた他の変更と切り分けられないためです。

ここで止めるのは手抜きではなく、検証を成立させるための線引きです。「リンクを1本張った」という原因に対して観測できる結果は「被リンク数が1増えた」までで、その先は他の変数が混ざります。順位を見たくなったら、それは別の検証として設計し直してください。

実例｜被リンク6本で90日0表示だった、このページの失敗

ここまでの手順を、筆者自身のサイト（記事363本＋固定ページ4本）に実際に回しました。2026年8月2日時点の結果です。

• 本文由来の被リンクが0本の記事：40本（363本中・約11%）
• 被リンク1本の記事：84本／2本：57本／3本以上：182本
• 検出された自己リンク：1件（このページ自身）
• いま読んでいるこのページの被リンク：6本

付け加えると、この数字は1回目の走査では出ていません。1回目は前述のサイドバー混入があり、本文由来の内部リンク総数が4,792本と表示されました。class名の重複を直したあとの実数は1,242本です。差の3,550本、集計の74%がサイドバーのウィジェット由来でした。除外しなければ判定が成立しないというのは、この差のことです。

前章の表に当てはめると、被リンク6本は「3本以上」の行に入ります。本数だけを見れば合格です。それでもこのページの検索表示は、90日間（2026年5月4日〜7月31日）で0でした。

6本のリンク元が、ほぼ1つの島に閉じていた

リンク元6ページのSearch Console実測（同90日）が次の表です。

6本のうち5本が同じ連載の内部でした。しかもその連載は、6記事の90日合計表示が5回しかありません。外から人もクローラも入ってこない閉路の内側で、リンクだけが循環していたことになります。合否ラインの表で「本数は足りているが同一クラスタ」を要注意に置いているのは、この実測が根拠です。

同じリストを貼り合い、自分自身へのリンクまで含んでいた

島ができた原因も、走査結果からそのまま読み取れました。連載の各記事が末尾に同一のリンクリストを貼っていたのです。しかもそのリストは連載の全記事を並べたものだったため、自分自身へのリンクが1本混ざったままになっていました。サイト全体で検出された自己リンクは1件、それがこのページでした。

これは、この記事が批判している症状そのものです。ウィジェットではなく手貼りのリストでしたが、「一覧を機械的に貼れば内部リンク対応は済む」という発想は同じで、結果も同じでした。アンカーテキストは記事タイトル丸ごと（前掲の weirdly long に該当）、リンク先の選定は「同じ連載だから」という機械的条件、そして誰も本数を数えていなかったため自分自身への参照にも気づいていませんでした。数えるまで気づけない、というのが唯一かつ最大の教訓です。

何を直すか

合否ラインに沿った次の一手は3つです。いずれも「本数を増やす」ではなく「リンク元の性質を変える」施策になります。

1. 自己リンクを削除する（被リンクではないため、数えるだけ無駄になる）
2. 末尾の一括リストをやめ、本文中の該当箇所から文脈つきで張り直す。アンカーはリンク先を説明する語にする
3. 島の外にある、検索表示が実際にあるページの本文から1本引き込む

3つ目が要点です。同じ島の中でリンクを7本、8本と増やしても、島全体の表示が5回である限り状況は変わりません。引き込むべきは本数ではなく、外部からの流入がある経路です。そして2週間後に同じスクリプトを回し、被リンク数とリンク元のクラスタが意図どおり変わったかだけを確認します。

その後｜3つとも実行した

ここまでが走査当日（2026年8月2日）の記録です。処方箋を書いて終わりにしないため、同じ日のうちに3つとも実行しました。結果は次のとおりです。

数字が動いたのはリンクの構造だけで、検索表示はまだ0のままです。ここで効果を判定することはできません。判定できるのは2週間後に同じスクリプトを回したときで、しかも見るのは順位ではなく「リンク元のクラスタが島の外へ広がったか」の一点です。順位が動くかどうかはGoogleが決めることですが、リンク元が島の内側に閉じているかどうかは、自分で数えれば当日わかります。この記事で示したかったのはその区別です。

なお、あなたが同じスクリプトをこのサイトに対して回した場合、自己リンクは0件、このページの被リンクは7本になります。上の表は是正前の状態を記録したものです。

記事数を数えるのをやめ、リンク元を数える

「記事を増やせば検索に強くなる」という前提は、Google公式の記述と噛み合いません。コンテンツの長さ自体は順位に関係しないとされ、目標文字数についても “Are you writing to a particular word count because you’ve heard or read that Google has a preferred word count? (No, we don’t.)”（Googleに好ましい文字数があると聞いたから特定の文字数を狙って書いていないか？　そんなものはない）と否定されています。多くのトピックで量産して当たりを狙う行為は品質の警告サインに挙げられ、順位操作を主目的とした大量生成はスパムポリシーの Scaled content abuse に該当します。

一方で公式が本数について唯一断言しているのは、リンクの側でした。「大切にしているページはすべて、サイト内の他のページから最低1本のリンクを受けているべき」。数えるべき対象は、納品した記事の本数ではなく、各ページが受け取っているリンクの本数とその出どころだということです。

そして本記事の実例が示したのは、その本数さえも単独では判定材料にならないということでした。被リンク6本で90日0表示という状態は実在します。見るべきは本数とリンク元の広がりの2つで、どちらもスクリプト1本で数えられます。関連記事ウィジェットは外す必要はありません。ただし、ウィジェットが出したリンクを数に入れている限り、孤立ページは永久に検出できないという一点だけは押さえておいてください。

棚卸しで孤立ページを洗い出したあと、サイト全体としてどこを強化するかを決める段階では基礎からAI検索時代の最新手法までのSEO対策ガイドが全体像の地図になります。個別ページの技術的な状態をまとめて確認したい場合は、下記の診断ツールが使えます。

参照した一次ソースは以下のとおりです（いずれも英語版・2026年8月2日取得）。

• Google Search Central｜Make your links crawlable（最終更新 2025-12-10）— アンカーテキストの条件、リンク本数、内部リンクの考え方
• Google Search Central｜SEO Starter Guide（最終更新 2025-12-10）— リンクが発見経路であること、見出しの順序と数、コンテンツの長さ
• Google Search Central｜Creating helpful, reliable, people-first content（最終更新 2025-12-10）— 多トピック量産の警告サイン、文字数目標の否定
• Google Search Central｜Spam policies for Google web search（最終更新 2026-05-15）— Scaled content abuse の定義
• Google Search Console ヘルプ｜Links report— レポートが網羅ではなくサンプルであること

よくある質問（FAQ）

Q. 関連記事ウィジェットを置けば内部リンク対策になりますか？

発見経路としては機能します。Googleは「毎日見つける新規ページの大半はリンク経由」と明記しており、ウィジェットが出力するリンクもクロールされるためです。ただしウィジェットでは、どのページからどのページへ張るかと、アンカーテキストに何と書くかを人が決められません。Googleはアンカーテキストに「説明的で、適度に簡潔で、リンク元とリンク先の両方に関連していること」を求めているため、この2点を制御できないことが限界になります。

Q. 内部リンクは何本張れば十分ですか？

本数の正解はありません。Googleは「1ページが含むべきリンクの理想的な数は存在しない」と明記しています。公式が本数について断言しているのは「大切にしているページはすべて、サイト内の他のページから最低1本のリンクを受けているべき」という下限だけです。したがって判断すべきは本数ではなくリンク元の広がりで、本文由来の被リンクが3本以上あり、かつリンク元が2つ以上のクラスタに散っていれば合格ラインとしています。

Q. 孤立ページはSearch Consoleで見つけられますか？

補助にはなりますが、単独では判定できません。公式ヘルプに「このレポートはサイト上の全リンクの網羅的な一覧ではなく、サンプルを表示するものであり、非インデックスページなどの理由でURLが省略されることがある」と明記されているためです。レポートに載っていないことは被リンク0本の証拠になりません。母集団は自分のsitemapとHTMLから作り、Search Consoleは外部サイトからのリンクを確認する補助として使ってください。

Q. 記事の見出し階層を正しくすると検索順位は上がりますか？

上がりません。Googleは「見出しをセマンティックな順序にすることはスクリーンリーダーには非常に有効だが、Google検索の観点では順序どおりでなくても問題にならない」「理想的な見出しの数というものも存在しない」と公式に述べています。見出し階層を整える理由はHTMLとしての妥当性とアクセシビリティ、そして読者にとっての可読性であって、順位施策ではありません。

Q. 記事数を増やせばサイト全体のSEOは強くなりますか？

なりません。Googleは「コンテンツの長さ自体は順位に関係しない（魔法の文字数目標は存在しない）」とし、多くのトピックで量産して当たりを狙う行為を品質の警告サインに挙げています。さらに、順位操作を主目的とした大量生成はスパムポリシーの Scaled content abuse に該当します。増やすかどうかより、いま持っているページが他のページから見つけられる状態にあるかを先に確認してください。

Q. リンクを張り替えたあと、効果はいつ確認すればよいですか？

張った直後ではなく、2週間ほど置いてから同じ棚卸しを回し直し、対象URLの被リンク数とリンク元のクラスタが意図どおり変わったかだけを確認してください。順位や流入の変化は、リンク以外の変更やアルゴリズム側の変動と切り分けられないため、この段階では判定材料にしません。順位を見るのであれば、別の検証として設計し直す必要があります。

Q. 内部リンクの設計はライターとディレクターのどちらが担当すべきですか？

担当範囲を決めるのは体制側の仕事ですが、実務としてはリンク先の候補を書き手が出し、サイト全体を見る側が採否を決める分担が現実的です。どの記述からどのページへ渡すべきかは、記事の文脈を最もよく知る書き手にしか判断できないためです。最も避けるべきなのは、ウィジェットを置いたことで「対応済み」となり、誰も本数を数えていない状態です。孤立ページはその状態から生まれます。