公開2025.08.04更新2026.09.27 SEO

PLP（優先ランディングページ）とは？SEOでの意味と決め方・狙ったページが出ないときの直し方

SEOでいうPLP（Preferred Landing Page／優先ランディングページ）は、対策キーワードごとに「検索結果にはこのページを出したい」と運営者が決めた自社の1ページです。PLPは順位計測ツールの設定項目などで使われる呼び名で、Googleに希望の表示URLを登録する機能ではありません。PLPを決める意味は、実際に検索結果へ出ているページと突き合わせて、ずれを見つけて直せるようになる点にあります。

この記事では、PLPの意味とEC用語のPLP（商品一覧ページ）との違い、PLP台帳の作り方、狙ったページが出ないときの原因別の直し方、Search Console APIで一致を定期点検するコードまでを順に説明します。

まとめ：PLPはクエリ1つに1URLを決め、実際の着地ページとのずれを直す運用

PLPは「このクエリにはこのURL」という運営者側の指定です。Dragon Metricsのヘルプは、1つのキーワードに設定できるPLPは1つだけで、1つのURLが複数キーワードのPLPになるのは構わないと定義しています。
決め方は、Search Consoleでクエリごとに実際に表示されているページを洗い出し、検索意図に最も合うページを1本選んで台帳に書くことです。
狙ったページが出ない原因は大きく3つです。別の自社ページが強い、PLPが正規URLとして選ばれていない、ほぼ同じページが重複している。直し方はそれぞれ違います。
正規URLの伝え方はGoogle公式が効果の高い順に「リダイレクト、rel=”canonical”、サイトマップ」と並べています。サイト内の代表ページ選びにnoindexを使う方法は勧めていません。
表示回数が少ないクエリや、2ページがそろって1ページ目に載っているクエリは、PLPを決めても無理に直さないほうが安全です。

PLPの意味：SEOのPreferred Landing PageとECのProduct Listing Page

順位計測ツールの設定項目として使われてきた「優先ランディングページ」

海外の順位計測ツールDragon Metricsのヘルプ記事「Preferred Landing Page」は、PLPを「そのキーワードを狙うのに使っているURL、またはそのキーワードで最も上位に出したいURL」と定義しています。キーワードに付けられる任意項目の1つで、1キーワードにつき1つだけ設定でき、1つのURLを複数キーワードのPLPにすることはできます。順位レポートでは、実際に順位が付いたURLとPLPを比べて一致かどうかを表示し、PLPのtitle・メタディスクリプション・URL・H1・本文にキーワードが入っているかも点検します。

国内でもこの考え方はツールの機能名として定着しています。Nobilistaは「優先URL機能（PLP）」を持ち、2024年6月13日の公式告知で、PLPと実際に検索結果に表示されるページが一致している割合を「PLP一致率」として描画する機能の搭載を案内しています。Gyro-n SEOにもPLPを設定して検索結果と照合する機能があります。

つまりPLPはGoogleに登録する設定ではなく、運営者が自分の管理表やツールに書き込む「狙い」です。Googleは、title・本文・内部リンク・正規URLの指定などを手がかりに、ページの内容や関連性を判断します。

EC用語のPLP（商品一覧ページ）・PDPとの違い

同じPLPでも、ECサイトの設計ではProduct Listing Page（商品一覧ページ）を指します。検索画面に「PLPとPDPとは何ですか？」という質問が並ぶのはこの意味で、PDP（Product Detail Page）は商品詳細ページです。半導体の分野ではパネルレベルパッケージ（Panel Level Packaging）の略としても使われます。文脈がSEOの運用なら優先ランディングページ、ECサイトの画面設計なら商品一覧ページと読み分けてください。

略語	正式名	意味	使われる場面
PLP	Preferred Landing Page	クエリごとに出したい自社ページ	SEOの順位管理
PLP	Product Listing Page	商品一覧・カテゴリページ	ECサイトの設計
PDP	Product Detail Page	個々の商品の詳細ページ	ECサイトの設計
LP	Landing Page	訪問者が最初に着地するページ	広告・SEO全般

LP（ランディングページ）は「最初に着地したページ」全般を指し、広告用の縦長ページだけを意味するわけではありません。PLPはその中から、クエリごとに「ここに着地してほしい」と1本を指名したものです。LPそのものの構成や制作の進め方はランディングページ（LP）とは？LP制作の流れ・構成・費用と外注の判断基準を解説で扱っています。

PLPを決める理由：着地ページのずれが成果を落とす仕組み

Googleは、運営者がどのページで成果を取りたいかを知りません。検索意図に近いと判断したページを出すだけです。そのため「料金」を調べた人がサービス紹介ではなく古いブログ記事に着地したり、比較検討中の人が用語解説に着地したりします。順位が付いていても、着地したページに問い合わせ導線や答えが無ければ成果にはつながりません。

もう1つの問題は、同じクエリに自社の複数ページが代わる代わる表示される状態です。どのページを強化すればよいかが決まらず、title変更や内部リンクの効果も測れなくなります。PLPを決めておけば「狙ったページが出ているか」を毎月同じ基準で確認でき、ずれたときにどのページを直すかがすぐ決まります。複数ページが同じクエリで競合する状態そのものの見分け方と、統合するか分けたままにするかの判断はキーワードカニバリゼーションとは？発見手順と統合・分離の判断基準を解説で詳しく扱っています。

PLPの決め方：クエリと1URLを対応させる台帳づくり

Search Consoleによるクエリ別URLの確認

最初に、対策クエリで実際に表示されているページを調べます。Search Consoleの検索パフォーマンスで、クエリを「次を含むクエリ」ではなく完全一致で絞り、「ページ」タブを開くと、そのクエリの表示回数がURL別に出ます。ただし、データの多くはGoogleが選んだ正規URLに集約されるため、検索結果に表示されたURLや実際の着地先と常に一致するわけではありません。期間は直近3か月程度にし、1ページだけでも検索意図や成果への導線が合っているかを確認します。2ページ以上に表示が割れている場合は、意図の違いや合計クリック数も確認してPLP調整の必要性を判断します。Search Consoleの基本的な画面の見方はサーチコンソールとは？できること・設定手順とSEO改善への使い方【2026年時点】を参照してください。

対策クエリが数十を超えると、画面で1つずつ確認するのは現実的ではありません。検索パフォーマンスの表は1,000行までしか表示されず、画面からのエクスポートも最大1,000行です。後述のSearch Console APIで、クエリとページの組み合わせを一括で取り出します。

PLPに選ぶページの判断基準

候補が複数あるときは、検索意図との一致を優先し、成果への導線と既存の検索実績も確認して決めます。検索実績はSearch Consoleの表示回数・クリック数・平均掲載順位で比較します。

検索意図との一致：クエリが「とは」なら定義を答えるページ、「料金」「比較」なら検討材料が載ったページです。意図と違うページは、いま順位が高くてもPLPにしません。
成果への導線：問い合わせ・資料請求・購入など、そのクエリで取りたい行動にページ内から進めるかどうか。
いまの評価：上記の検索実績に加え、外部からのリンク。意図と導線が同等なら、すでに評価されているページを選ぶほうが早く安定します。

判断に迷うクエリは、検索結果の上位10件を実際に見てください。上位が定義記事ばかりなら、自社のサービスページをPLPにしても上がりにくいと考えるべきです。

PLP台帳に書く項目

決めた内容は表にまとめ、月1回の点検で「現在の着地ページ」「PLPの表示シェア」「一致」「次の対応」を更新します。Search Consoleで比較した期間も記録してください。

項目	記入例
対策クエリ	plp seo
検索意図	用語の意味と対策方法
PLP（URL）	/column/plp/
現在の着地ページ	/column/lp/
PLPの表示シェア	29%
一致	不一致
次の対応	非PLP側のtitleから対策語を外す

1つのクエリにPLPは1本です。「どちらでもよい」と2本書くと、点検のたびに一致とも不一致とも言えなくなります。

狙ったPLPが表示されないときの原因別の直し方

非PLPが上位表示される場合の内容と内部リンクの調整

PLPも非PLPもインデックスされていて、非PLPの方が上に出ている状態です。Googleがそのクエリに対して非PLPの方が合っていると判断しているので、両方のページを調整します。

PLP側：titleとH1に対策クエリの語を入れ、検索意図への答えを冒頭に置きます。サイト内の関連ページから、対策クエリを含む具体的なアンカーテキストでPLPへリンクします。Google公式のリンクに関するドキュメントも、アンカーテキストはリンク先の内容をユーザーとGoogleに伝えるものだと説明しています。
非PLP側：対策クエリの語がページ本来の内容と合っていない場合に限り、titleや見出しを修正します。他のクエリからの流入や成果も確認し、必要な語は残します。本文でその話題に触れる箇所からは、PLPへリンクして詳しい説明を任せます。
サイト内リンクの向き：グローバルメニューやパンくず、関連記事で、対策クエリの語を含むリンクが非PLPを向いていないか確認します。

調整後は、クロールと再評価を待つ必要があります。翌週だけで成否を決めず、まず1か月程度を点検の目安にしてください。再クロールの有無と表示回数を確認し、データが少なければ観察期間を延ばします。

PLPとGoogle選択の正規URLの照合

PLPがそもそも検索結果に出てこないときは、Search ConsoleのURL検査でPLPのURLを調べます。確認するのは「ページのインデックス登録」内の「ユーザーが指定した正規 URL」と「Google が選択した正規 URL」の2項目です。後者が別のURLになっていれば、GoogleはPLPを重複ページの1つとみなし、別のURLを代表として検索結果に出しています。Googleのヘルプによれば、この正規URLはインデックス登録されたデータからだけ確認でき、ライブテストでは判定できません。

ページのインデックス登録レポートでは、次の2つの理由として現れます。

「重複しています。Google により、ユーザーがマークしたページとは異なるページが正規ページとして選択されました」：PLPに自己参照のcanonicalを付けているのに、Googleが別URLを正規とした状態です。
「重複していますが、ユーザーが正規ページとして選択していません」：canonicalの指定が無く、Googleが別のページを正規に選んだ状態です。

canonicalで正規URLを指定しても、Googleは「正規化の希望を伝えることはできますが、確実ではありません」と説明しており、別のURLを選ぶことがあります。どちらの理由も、GoogleがPLPを別URLと重複していると判断した状態です。そのURLは同じサイト内にあるとは限らず、別ドメインの場合もあります。2ページの内容が実際に大きく違うなら差をはっきりさせ、ほぼ同じなら次の統合を検討します。

重複ページの統合と正規化手段の選択

同じテーマの記事が年ごとに作られている、パラメータ付きURLが別ページとして出ている、といった重複は、PLPへ集約するのが根本の対処です。Googleの正規化ドキュメントは、正規URLを伝える方法を効果の高い順に次のように並べています。

方法	Google公式の位置づけ	向いている場面
301リダイレクト	強いシグナル	非PLPを残す必要がない
rel=”canonical”	強いシグナル	非PLPを閲覧用に残したい
サイトマップに含める	弱いシグナル	他の方法の補強

同じドキュメントは、1つのサイト内で正規ページの選択を妨げる目的でnoindexを使うことを、そのページがGoogle検索から完全にブロックされるため勧めていません。非PLPにnoindexを付けてPLPを浮かせる方法は取らないでください。リダイレクトを重ねるとチェーンになるので、統合のたびに古いリダイレクトの行き先も更新します（リダイレクトチェーンとは？Googleは10ホップまで・推奨3個以下の根拠と解消手順）。

Search Console APIでPLPの一致を定期点検するコード

対策クエリが増えると、画面での確認は続きません。Search Console APIのsearchanalytics.queryで、ディメンションを「query」と「page」にしてデータを取り出せば、クエリごとにどのページが何回表示されたかが一度にわかります。次のPythonは、取得できた行の範囲でPLP台帳と照合し、最多表示のページとPLPの表示シェアを出します。APIは全行の取得を保証せず、ページングしても欠落は解消されないため、結果は点検候補の抽出に使ってください。

from google.oauth2 import service_account
from googleapiclient.discovery import build

SITE = "sc-domain:example.com"
PLP = {  # 対策クエリ -> 優先ランディングページ（PLP台帳）
    "plp seo": "https://example.com/column/plp/",
    "カニバリ 対策": "https://example.com/column/cannibal/",
}

def fetch_rows(sc, start, end):
    rows, start_row = [], 0
    while True:
        body = {"startDate": start, "endDate": end,
                "dimensions": ["query", "page"],
                "rowLimit": 25000, "startRow": start_row}
        res = sc.searchanalytics().query(siteUrl=SITE, body=body).execute()
        batch = res.get("rows", [])
        rows.extend(batch)
        if len(batch) < 25000:
            return rows
        start_row += 25000

def audit(rows):
    by_query = {}
    for r in rows:
        query, page = r["keys"]
        page = page.split("#")[0]  # ページ内リンク付きURLは本体URLへ寄せる
        pages = by_query.setdefault(query, {})
        pages[page] = pages.get(page, 0) + r["impressions"]
    for query, plp in PLP.items():
        pages = by_query.get(query, {})
        total = sum(pages.values())
        if total == 0:
            print(f"{query}\t取得データなし（表示ゼロとは限りません）")
            continue
        highest = max(pages.values())
        leaders = [page for page, count in pages.items() if count == highest]
        if len(leaders) != 1:
            print(f"{query}\t同率最多・判定保留\t候補={','.join(sorted(leaders))}")
            continue
        top = leaders[0]
        share = pages.get(plp, 0) / total
        status = "一致" if top == plp else "不一致"
        print(f"{query}\t{status}\tPLPの表示シェア{share:.0%}\t最多={top}")

if __name__ == "__main__":
    creds = service_account.Credentials.from_service_account_file(
        "key.json",
        scopes=["https://www.googleapis.com/auth/webmasters.readonly"])
    sc = build("searchconsole", "v1", credentials=creds)
    audit(fetch_rows(sc, "2026-06-01", "2026-08-31"))

google-api-python-clientとgoogle-authが必要です。Google CloudでSearch Console APIを有効にし、サービスアカウントのJSON鍵をkey.jsonとして用意してください。SITE・PLP・取得期間は自社のプロパティと点検対象に置き換えます。サービスアカウントのメールアドレスをSearch Consoleのプロパティにユーザーとして追加しておかないと、権限エラーで止まります。

rowLimitは1回あたり1〜25,000行です。25,000行ちょうど返ってきたら、startRowをずらして続きを取ります。ただしAPIの説明によれば、公開されるのは検索タイプごとに1日あたり最大5万行で、ページやクエリでグループ化すると一部のデータが削除されることがあります。大規模サイトでは全量ではなく上位の行を見ていると考えてください。
ページ内リンク（#付き）のURLが別の行として返ることがあるため、#以降を落として本体URLに合算しています。
クエリとページを組み合わせると、1回の検索で複数ページが表示された場合にそれぞれ1回と数えられます。表示回数の合計はサイト全体の数字より大きくなるので、ここでは割合（表示シェア）で比べます。
台帳のクエリは、Search Consoleに表示される文字列と表記をそろえてください。「plp seo」と「plpseo」は別のクエリとして集計されます。

出力はクエリごとに1行で、「一致／不一致」「PLPの表示シェア」「最多表示のページ」がタブ区切りで並びます。最多表示のページが同率で複数ある場合は「判定保留」として候補URLを出します。不一致の行と、一致していてもシェアが半分を切る行が、その月に手を入れる候補になります。

PLPを決めても無理に直さないほうがよい場面

PLPの一致率を上げること自体を目標にすると、かえって流入を減らします。次の場面では、不一致のまま様子を見るか、PLPの方を見直してください。

表示回数が月に数十回以下のクエリ：少数の表示だけでは、どのページが安定して表示されるかを判断しにくくなります。数か月分をまとめても傾向が出ないクエリは、台帳から外して手間を割きません。
PLPと非PLPがそろって1ページ目に載り、合計のクリックが増えているクエリ：2枠を取れているなら、片方を弱める調整は損になり得ます。
Googleが選んだページの方が検索意図に合っているクエリ：上位の競合が定義記事ばかりなのに自社のサービスページをPLPにしている場合、直すべきはPLPの選び方です。台帳の側を書き換えます。
クエリに意味が2つあるとき：「plp」のように、SEOの優先ランディングページとECの商品一覧ページが混ざる語は、1本に寄せず、それぞれの意味に答えるページを残して冒頭で読み分けを示します。

一致していてもクリックが来ないクエリもあります。検索結果の上部にAI Overviewが出る語では、PLPが上位に出ていてもクリック率が伸びないことがあります。PLPの一致はあくまで「狙ったページに評価が集まっているか」の確認で、成果の最終指標はクリックとその後の行動です。着地した後の改善はLPOとは？LP改善で最初に触る要素と検証の順序・効かない場面の見極めの範囲になります。