商品ページをリライトする方法｜Search Consoleを使った改善手順
目次
商品ページのリライトは、文章を長く書き直す作業ではありません。検索データ、商品情報、問い合わせ、在庫や販売状況を確認し、検索した人の期待とページ内容のずれを直します。
Search Consoleは改善候補を探す材料になりますが、平均掲載順位やCTRだけで優先順位を決めないことが大切です。売上、利益、在庫、商品ライフサイクルも合わせます。
リライトの目的を決める
目的には、検索意図とのずれを直す、商品情報を追加する、古い仕様を更新する、比較しやすくするなどがあります。最初に問題を一つか二つに絞ります。
目的が曖昧なまま全要素を変えると、何を確認すべきか分かりません。誤情報の修正は優先し、それ以外は記録を残して進めます。
対象商品を選ぶ
表示回数があるのにクリックが少ない商品、具体的な検索語で表示されている商品、問い合わせが多い商品などが候補です。売上の大きい商品や在庫を安定確保できる商品も優先します。
4位から10位は候補を探す目安として使われますが、必ず改善すべき順位帯ではありません。検索意図とページの役割を確認します。
Search Consoleでページを絞る
検索パフォーマンスで対象URLを指定し、クエリ、クリック、表示回数、CTR、平均掲載順位を見ます。期間を変えるときは、季節性やセールの有無を確認します。
平均掲載順位は、地域、端末、検索条件などを含む平均です。一つの検索結果画面の固定順位ではありません。数値の小さな変化だけで判断しないようにします。
検索クエリを意図ごとに分ける
商品名・型番、用途、比較、使い方、トラブルなどに分類します。商品ページが答えるべき語と、記事やFAQへ分けるべき語を判断します。
たとえば「AB-100 取扱説明書」は購入ページよりサポート情報が答えになる場合があります。すべてを商品説明へ詰め込まないようにします。
現在のページを棚卸しする
商品名、title、description、見出し、説明、仕様、画像、FAQ、在庫、配送、内部リンク、構造化データを確認します。検索語があるかだけでなく、購入判断に必要な情報が見つかるかを見ます。
スマートフォンでの配置も確認します。重要仕様が長い販促文の後ろへ隠れていないかを見ます。
商品事実を更新する
型番、素材、サイズ、対応機種、付属品、価格、在庫を公式資料と商品マスタで確認します。古い仕様を残したまま文章だけ整えないでください。
不明な値を競合ページから推測しないようにします。確認できない内容はメーカーや仕入れ担当へ問い合わせます。
冒頭で商品の全体像を伝える
最初の段落で、何の商品か、誰がどの場面で使うか、主な違いを示します。「おすすめの商品です」のような抽象文だけで始めないようにします。
検索キーワードを不自然な順番で入れず、商品を説明する自然な文章にします。
説明と仕様の役割を分ける
説明文では利用場面と特徴の意味を伝え、仕様表では数値や規格を比較しやすく示します。同じ情報を何度も繰り返す必要はありません。
安全上の注意、対応外条件、返品に関わる情報は、見落とされない位置へ置きます。
titleとdescriptionを見直す
titleは商品を固有に識別できる内容にし、descriptionは用途や重要仕様を簡潔にまとめます。設定した文言が検索結果で書き換えられる場合があります。
meta情報だけでサイト全体の評価が必ず上がるとは言えません。ページ本文との整合性を優先します。
内部リンクを整える
カテゴリ、特集、記事、関連商品から対象商品へたどれるかを確認します。商品に合わなかった人が比較へ戻れるリンクも用意します。
販売終了商品や無関係な商品へのリンクを整理します。主要リンクは通常のhrefで実装します。
構造化データを照合する
ProductやOfferを使っている場合は、商品名、価格、在庫、評価が画面と一致するか確認します。文章変更時に古い値が残っていないかを見ます。
テスト合格やリッチリザルト表示は順位や売上を保証しません。正確な商品情報を伝える手段として扱います。
変更履歴を残す
変更日、対象URL、変更項目、理由、担当者を記録します。title、説明、画像を同時に変えた場合は、そのまとまりを残します。
セール、広告、在庫切れも記録すると、後の数値変化を解釈しやすくなります。
公開後の確認
HTMLで変更が反映され、noindexやcanonicalが意図せず変わっていないかを確認します。必要に応じてURL検査を使いますが、クロール依頼は即時反映を保証しません。
一定期間後に表示回数、クリック、クエリ、商品閲覧、カート追加、問い合わせを確認します。CTRだけで順位が上がるとは断定しません。
具体例
「軽量 リュック 20L」で表示される商品に重量と容量の説明がないなら、公式仕様を確認して本文と表へ追加します。単に検索語をtitleへ足すだけでは不足です。
「AB-100 対応機種」が多いなら、対応一覧を本文へ置き、誤購入を防ぐ注意も追加します。情報量が多ければサポートページへの導線を整えます。
よくある間違い
- 順位だけで対象を選ぶ
- 検索語を文章へ詰め込む
- 競合の説明を言い換える
- meta情報だけを変更する
- 在庫や仕様を確認しない
- 変更履歴を残さない
- 短期間で元に戻す
リライト手順
- 商品価値と検索データから対象を選ぶ
- クエリを検索意図ごとに分類する
- 商品事実とページ要素を棚卸しする
- 不足情報と導線を改善する
- 変更履歴を残して公開する
- 検索とECの指標を合わせて確認する
チェック項目
- リライトの目的が明確か
- 検索意図と商品内容が一致するか
- 商品仕様が最新か
- 自然な文章になっているか
- 内部リンクと構造化データを確認したか
- 変更前後の条件を記録したか
変更範囲を小さく始める
同じテンプレートを使う全商品へ一括反映する前に、商品タイプの異なる数ページで確認します。通常商品、在庫切れ、バリエーション、予約商品などを含めると、想定外の表示を見つけやすくなります。
文章だけの変更に見えても、title生成、構造化データ、商品フィードが同じ項目を参照していることがあります。影響範囲を開発担当者と確認します。
元に戻す基準を決める
誤情報、表示崩れ、購入不能など重大な問題はすぐに戻せるよう、変更前の内容を保存します。検索順位の短期的な上下だけで即座に戻すのではなく、判断期間と確認指標を事前に決めます。
変更を戻した場合も、理由と影響を記録します。同じ失敗を別カテゴリで繰り返さないように、リライトの手順と確認項目へ反映してください。
関係部署の確認を組み込む
商品ページのリライトは、SEO担当者だけでは確認できない内容があります。仕様と在庫は商品担当、保証と返品はカスタマーサポート、表示と構造化データは開発担当が関係します。
すべてを毎回大人数で確認するのではなく、変更内容ごとに必要な承認を決めます。誤情報の修正は迅速に行い、表現変更は公開前に担当者が確認できる流れにします。
ページ単位とテンプレート単位を分ける
一商品だけ説明不足なら個別に直せますが、全商品で送料が見つけにくい場合はテンプレートの問題です。個別リライトを繰り返す前に、共通原因かを確認します。
テンプレート変更では影響範囲が大きいため、代表商品でテストし、例外商品を確認します。個別上書きが消えないかも見てください。
まとめ
商品ページのリライトは、検索データから候補を見つけ、商品事実と購入者の疑問を照合して不足を直す作業です。文章量だけを増やさないようにします。
Search Consoleの数値は平均値であり、単独で結論を出せません。売上、在庫、問い合わせも合わせ、重要商品から変更と検証を積み重ねてください。
