Chrome Web Store SEOで18拡張公開後に効いた施策
目次
Chrome Web Store の検索最適化は、普通のWeb SEOより情報が少ない。
Google公式の掲載ページ作成ガイドはあるが、「何を変えると検索経由のインストールが増えたか」まではほとんど書かれていない。
DEV Community に、18個のChrome拡張を公開して6か月いじった記録が出ていた。
原典は CWS Listing SEO: What Actually Moved the Needle After Publishing 18 Extensions。
同じ著者は直前に17拡張時点のCWS SEO記事も出していて、18拡張版ではさらに「実際に数字が動いたもの」に寄せた内容になっている。
この記事の面白いところは、Chrome Web Store を検索エンジンとしてだけ見ていない点だ。
タイトルや短い説明で検索に引っかける。
スクリーンショットや長い説明でクリック後のインストール率を上げる。
レビュー導線や権限説明で離脱を減らす。
この流れを1つの掲載ページ内で扱っている。
タイトルはブランド名より検索語
原典で一番強く書かれているのはタイトルだ。
Chrome Web Store のタイトルは75文字までで、ここに主要キーワードを入れるのが最も効いたという。
これはWebページの <title> や <h1> に近い。
ただしCWSでは、作者のブランド名や洒落たプロダクト名だけだと、ストア検索から見た機能が伝わらない。
たとえば「ReadMark」だけでは何の拡張かわからない。
「Scroll Position Saver for Chrome」まで入ると、スクロール位置保存の拡張だと検索側にもユーザー側にも伝わる。
プロダクト名を捨てるというより、検索語を先に置く設計だ。
この発想は通常のSEOとも似ているが、CWSではさらに露骨に効く。
Web検索なら本文、被リンク、構造化データ、サイト全体の文脈もある。
CWSの一覧では、ユーザーが最初に見る文字列が少なく、タイトルの比重が大きくなる。
短い説明は132文字の検索本文
Chrome Web Store の短い説明は132文字まで。
原典では、ここを「検索結果に出る本文」として扱っている。
ポイントは、キーワードを詰め込むことではなく、ユーザーが検索しそうな周辺語を自然に入れることだ。
フォント検出拡張なら、font inspector、rendered font、CSS syntax、Google Fonts、Adobe Fonts、designers といった語が並ぶ。
機能説明として読める範囲で、検索語の入口を増やす。
ここで普通のWeb SEOと違うのは、Search Console のようなクエリ確認が弱いところだ。
このブログでも Google検索の4月末変動とSearch ConsoleやGA4の遅れ で書いたように、Web検索ならGSCで表示回数・クリック・クエリを後から分解できる。
Chrome Web Store は Insights ダッシュボードで流入元別の表示、クリック、インストールを見られるが、検索クエリ分析の自由度は低い。
だから、短い説明は一発で当てに行くより、変更履歴を残して差分を見るほうが現実的だ。
タイトルを変えた日、短い説明を変えた日、スクリーンショットを変えた日を分けないと、何が効いたのか混ざる。
長い説明は順位よりインストール率に効く
原典では、長い説明は個別キーワードの順位を直接押し上げる感じではなく、クリック後のインストール率に効くと見ている。
ここは納得感がある。
Chrome Web Store のユーザーは、一覧で興味を持って、詳細ページで不安を消して、インストールする。
長い説明でやるべきなのは、検索語の水増しではなく、インストール前の疑問を減らすことだ。
特に効きそうなのは、無料範囲と有料範囲を明記すること。
Chrome拡張は「入れたら何か勝手に課金されるのでは」「途中で使えなくなるのでは」という警戒が出やすい。
無料で何回使えるのか、有料で何が増えるのかが書かれているだけで、詳細ページの離脱は減る。
もうひとつは、やらないことを書くこと。
たとえば「外部サーバーに送信しない」「ローカルで処理する」といった説明は、機能説明というより不安の除去だ。
SupabaseのAPIキーが丸見えでも安全な理由とRLSの重要性 で触れたように、Chrome拡張はWebページ上の情報を読む道具にもなる。
ユーザーから見ると、便利さと同時に「この拡張は何を読んで、どこへ送るのか」が気になる。
権限警告も同じ話だ。
拡張が広い権限を要求すると、Chrome はかなり強い文言で警告を出す。
権限を減らすのが先だが、どうしても必要な権限なら掲載ページ側で理由を書くしかない。
スクリーンショットは検索順位ではなくクリック後を動かす
Google公式の Creating a great listing page でも、スクリーンショットは実際の利用体験を示し、1280×800または640×400のサイズを使うよう案内している。
少なくとも1枚、できれば最大5枚を用意するという扱いだ。
原典では、注釈付きスクリーンショットでCTRが20〜30%ほど上がったと書かれている。
この数字は著者の18拡張での観測なので、どのカテゴリにもそのまま当てはまるとは限らない。
ただ、CWSの詳細ページではスクリーンショットがほぼランディングページのファーストビューになるので、効く場所としては自然だ。
よさそうなのは、機能一覧を画像に詰めることではない。
最初の1枚で「何をクリックして、何が出るか」を見せる。
2枚目で結果や出力を見せる。
3枚目で設定や有料機能を見せる。
このくらいの順序なら、ユーザーがインストール後の操作を想像しやすい。
逆に、文字だらけのスクリーンショットは弱い。
公式ガイドも、説明用の補助はよいが、テキストを入れすぎるなと書いている。
小さい一覧やモバイル幅で見たときに読めない文字は、ほぼノイズになる。
レビュー数より最近のレビューを疑う
原典で少し慎重に読むべきなのはレビューの話だ。
著者は、直近30日のレビューが多い4.8星・15レビューの拡張が、4.9星・150レビューの拡張より上に来ることがあると見ている。
つまり総レビュー数よりレビューの新しさが効いている可能性がある。
これは公式に確認されたランキング要素ではない。
ただし、ストア検索で「最近ちゃんと使われているか」を見るのは不自然ではない。
古い高評価だけが残っている拡張より、最近もインストールされてレビューされている拡張のほうが、ユーザーにとっても安全に見える。
レビュー依頼のタイミングは、初回起動ではなく成功体験の後。
原典では、コア操作を3回完了した後にレビュー依頼を出している。
これはかなり実装寄りの話で、単に掲載ページを直すだけでは届かない。
拡張本体のイベント設計と、ストア掲載のSEOがつながっている。
効かなかったものも見る
原典では、効かなかったものとしてキーワード詰め込み、プロモ画像、動画デモが挙げられている。
キーワード詰め込みは、検索にもユーザーにも弱い。
短い説明で周辺語を自然に入れるのと、長い説明に同じ語を連打するのは別物だ。
後者は詳細ページを読んだユーザーの不信感を増やす。
プロモ画像は、通常の検索結果より特集枠で効く素材という扱い。
動画デモも、複雑なUXを説明するには役立つが、検索経由のインストール増加としては測れなかったという。
ここは拡張の種類で変わる。
操作が一瞬で伝わる拡張ならスクリーンショットで足りるし、画面遷移や自動処理が肝なら動画の意味が出る。
CWS SEOは掲載ページだけで完結しない
Chrome拡張を公開している側で見ると、掲載ページの文言だけを触っても足りない。
検索に引っかけるフェーズ、クリック後の離脱を減らすフェーズ、レビューを戻すフェーズで手を入れる場所が違う。
1回の編集で全部直すと、原因がわからなくなる。
タイトル、短い説明、スクリーンショット、レビュー依頼の変更は分けて入れる。
CWS検索がインストールの大半を占める拡張なら、特にタイトルと短い説明から触る。
外部サイトやSNSからの流入が多い拡張なら、詳細ページでの不安除去やスクリーンショットのほうが効く可能性が高い。
Manifest V2からV3で権限警告が変わる
Chrome拡張のマニフェストは、拡張がどんなAPIを使い、どんな権限を要求するかを宣言するファイルだ。
2012年にManifest V2が導入され、2021年のChrome 88からManifest V3が使えるようになった。
2024年後半にはMV2拡張の無効化が段階的に始まり、CWSでもMV2拡張には非推奨バッジが表示されている。
掲載ページのSEOを考えるうえで、マニフェストバージョンが直接効くのはインストール時の権限警告だ。
MV2では permissions に全権限をフラットに並べる。
"permissions": ["tabs", "storage", "<all_urls>"] と書くと、インストール時に「すべてのウェブサイト上にあるデータの読み取りと変更」という警告が出る。
機能的にはページ内容を読む必要があるだけでも、ユーザーから見れば「全サイトのデータを渡す」と読める。
MV3では権限が permissions と host_permissions に分かれた。
API権限（storage, alarms など）と、サイトアクセス権限（https://example.com/* など）が別枠になる。
さらに activeTab を使えば、ユーザーが拡張アイコンをクリックしたタブだけにアクセスする形にできる。
インストール時の警告がかなり穏やかになるし、ユーザーが後からサイト単位で許可を出すフローにもできる。
この差は、掲載ページで「外部に送信しない」と書いても埋められない。
Chrome本体が出す警告ダイアログの文面自体が違うからだ。
記事前半で触れた権限の話は、MV3への移行でさらに具体的になる。
webRequest で全リクエストを傍受していた拡張が declarativeNetRequest に切り替えれば、要求する権限の幅自体が減り、警告も軽くなる。
CWS検索でのMV2拡張の扱いも変わっている。
GoogleはMV2拡張に対してストア上で非推奨バッジを表示し始めた。
ユーザーが一覧でこれを見ると、いくらタイトルや短い説明を最適化していても、クリック率は落ちる。
マニフェストバージョンごとの主な違いはこのあたりだ。
| MV2（2012〜非推奨） | MV3（2021〜現行） | |
|---|---|---|
| バックグラウンド処理 | 常駐するbackground page | 必要時に起動するservice worker |
| 権限宣言 | permissions に全部入り | permissions と host_permissions を分離 |
| ネットワーク傍受 | webRequest で同期ブロック可 | declarativeNetRequest でルールベース |
| リモートコード | 外部JSの読み込み可 | 禁止。全コードを拡張パッケージに同梱 |
| ユーザー向けUI | browser_action / page_action | action に統合 |
MV3でservice workerになったことで、バックグラウンドで常駐する形の拡張は作りにくくなった。
裏を返せば、MV3拡張はリソース消費が少ないことを詳細ページでアピールできる。
「バックグラウンドで動き続けない」「使うときだけ起動する」といった説明は、長い説明やスクリーンショットの注釈に入れる値打ちがある。
移行スケジュールはGoogleが何度か延期した。
当初2023年にMV2を完全廃止する予定だったが、広告ブロッカーを筆頭に webRequest APIに依存する拡張が多く、反発が大きかった。
webRequest の同期ブロック機能は、広告ブロッカーがリクエスト単位で通信を止めるのに使っていた中核APIだ。
MV3の declarativeNetRequest はルールを事前に宣言する形式で、動的な判断がしにくい。
uBlock OriginがMV3対応の「uBlock Origin Lite」を別拡張として出したのは、MV2版と同じ挙動をMV3で再現できなかったからだ。
2024年後半から段階的にMV2拡張の無効化が進み、CWSからのMV2新規登録も受け付けなくなっている。
まだMV2で公開している拡張があるなら、掲載ページの文言を直すよりMV3移行が先だ。
非推奨バッジが消え、権限警告が穏やかになるだけで、同じ掲載ページでもインストール率は変わる。