App Indexing は、Google のモバイル検索の結果をタップしたときに、ブラウザではなくインストール済みのアプリの該当画面を開かせる仕組みです。ただし日本語の解説の多くは2015年から2019年ごろの Firebase App Indexing を前提に書かれており、その中心部分は現在の公式ドキュメントでは推奨されていません。いま何が動いていて、何を設定すれば検索結果からアプリが開くのかを、Google と Apple の現行ドキュメントの記述だけで整理します。
なお「インデクシング」は索引付け全般を指す一般語でもあり、文献データベースの索引作業やデータベースのインデックス構築も同じ言葉で呼ばれます。クロールしたWebページを検索用データベースに登録するSEO文脈の「インデックス」とも別です。この記事で扱うのは、アプリ内の画面を検索結果の遷移先にする App Indexing に限定します。
まとめ：App Indexingの現在地と着手する順序
- Firebase App Indexing は推奨されなくなりました。Firebase の FAQ は「Firebase App Indexing is no longer the recommended way of indexing content for display as suggested results in Google Search App」と書き、さらに Android 版 Google 検索アプリが端末内にインデックスした内容を結果に使わなくなったことを注意書きで明示しています。
- いま App Indexing という名前で残っているのは、Google Play ストアのアプリと Search Console プロパティを結ぶ関連付け機能です。Search Console のヘルプは、この関連付けの効果を「検索結果が関連アプリへのディープリンクを表示する」ことと説明しています。
- 実装の本体は Android App Links（assetlinks.json）と iOS の Universal Links（apple-app-site-association）です。どちらもドメイン側にファイルを置き、そのドメインのリンクを処理してよいアプリを宣言して、端末に関連付けを検証させます。
- Android 15 以降は assetlinks.json 側でパスやクエリ単位の出し分けができます。アプリを再リリースせずにリンクの挙動を変えられるようになりました。
- 期待してよい効果は「検索結果からアプリが開く」ところまでです。Google 検索セントラルは2025年5月2日の記事で、ディープリンクを足してもコンテンツの見せ方は変わらず、インデックス登録とランキングにはWebページの内容を使い続けると明言しています。
- 反映後の確認は Search Console のパフォーマンスレポートと、Play Console のディープリンクのページで行います。
App Indexingの定義と対象になるユーザー
Google Play Console のヘルプ「App Indexing on Google Search」は App Indexing を「アプリをインストール済みのユーザーが、Google のモバイル検索のリンクをアプリで直接開けるようにするもの」と定義しています（原文は With App Indexing, users who installed your app can open links from Google mobile search directly in your app）。定義の時点でインストール済みユーザーに限定されている点が重要で、未インストールのユーザーをストアへ誘導する施策とは別の話です。
同じヘルプは、App Indexing を有効にする前提として先にディープリンクを設定しておくことを求めています。つまり App Indexing は単独の機能ではなく、アプリ側のディープリンク対応が終わっている状態に、Google 側の関連付けを重ねる構成になります。ディープリンクの種類やURLスキームとの違いはディープリンクとは？種類とユニバーサルリンク・URLスキームの違いで扱っています。
Firebase App Indexingの非推奨化と、いま残っている関連付け
Firebase App Indexingが推奨から外れるまでの経緯
かつて App Indexing の解説記事が前提にしていたのは、アプリに SDK を組み込んで画面の内容を端末内のインデックスに登録する Firebase App Indexing でした。2026年9月時点で、そのドキュメントURL（firebase.google.com/docs/app-indexing）は Firebase の FAQ の該当項目へ転送されます。転送先の見出しは「What happened to Firebase App Indexing?」で、本文は次の2点を明示しています。
- Firebase App Indexing は、Google 検索アプリのサジェスト結果に表示させるためのコンテンツのインデックス方法として、もはや推奨されない。
- Android 版 Google 検索アプリは、Firebase App Indexing で端末内にインデックスされたコンテンツを結果の提供に使わなくなった。
代替として FAQ が挙げているのは、Apple プラットフォームでは Universal Links、Android では Android App Links です。端末内検索が目的なら AppSearch、音声からの起動なら App Actions、ショートカットなら Android Shortcuts と、用途別に別の製品へ振り分けられています。
SDK 側の後始末も済んでいます。Firebase Android BoM は2022年10月12日公開のバージョン31.0.0で、firebase-appindexing を firebase-core・firebase-iid とともに BoM から除外しました。リリースノートには BREAKING CHANGE として記載されています。BoM のバージョンを古いまま固定しているプロジェクトでは、この依存が残ったままになっている可能性があります。
リンクの中継基盤だった Firebase Dynamic Links も2025年8月25日に停止しました。カスタムドメインで配信していたリンクも page.link サブドメインのリンクも動作しなくなり、新規作成もできなくなる、というのが FAQ の記述です。停止の条件はFirebase Dynamic Links の FAQにまとまっています。移行時に残る作業はFirebase Dynamic Linksの終了と移行｜停止後に残る作業とUniversal Links／App Linksへの移行手順【2026年8月時点】で扱っています。
現在のApp Indexing＝Play ConsoleとSearch Consoleの関連付け
一方で、App Indexing という名称そのものは Google のヘルプに現役です。Search Console ヘルプの「Associations」のページは、関連付けの効果の例として「an Android Play Store app association enables app indexing (when Google Search shows deep links into the associated app)」と記述しています。Play ストアのアプリと Search Console のプロパティを結ぶと App Indexing が有効になる、という説明です。
Android 側のドキュメントも同じ構図で書かれています。自分が所有するWebページに対応するアプリのコンテンツであれば、App Links とサイトの関連付けを設定することで、Google がサイトの関連付けを介してアプリのコンテンツをクロールし、モバイル端末の検索結果からアプリへ誘導できる、という説明です。所有権の確認手段としては Digital Asset Links と Google Search Console の2つが挙げられています。
| 観点 | Firebase App Indexing（旧） | 現在の App Indexing |
|---|---|---|
| 実体 | アプリ組み込みのSDK | Play Console と Search Console の関連付け |
| インデックス先 | 端末内とクラウド | サイト側のURL（App Links／Universal Links） |
| 設定場所 | アプリのコード | Play Console と各ドメインの well-known |
| 公式の位置づけ | 推奨されない | ヘルプに現行機能として記載 |
Play Consoleでのサイト関連付けと反映後の確認
Play ConsoleからSearch Consoleへ送る関連付け申請と承認
関連付けの申請は Play Console 側から行い、承認は Search Console 側の所有者が行います。ヘルプに記載されている手順は次のとおりです。
- Play Console にサインインし、All apps から対象アプリを選ぶ。
- 左メニューの Setup から Advanced settings を開く。
- App indexing の項目で Add website をクリックする。
- サイトのトップページのURLを入力する。ヘルプはプロトコル（http または https）を省いてドメイン名だけを書くことを推奨しています。
- Send verification request を押す。
申請は Search Console のプロパティ所有者へ届きます。Play Console と Search Console のアカウントが同一であれば、その場で自動承認されることがあります。別アカウントなら所有者の承認待ちです。
プロトコルを省いて申請した場合の挙動には注意が必要です。同じサイトについて http と https の両方の Search Console プロパティが存在すると、Google Play がどちらか一方を選んで関連付けます。意図したプロパティに紐づいているかは、関連付け後に Search Console の設定画面で確認してください。解除は Play Console の App Indexing タブからでも、Search Console の関連付け一覧からでも行えます（どちらか一方で十分です）。
Search ConsoleのパフォーマンスレポートとPlay Consoleのディープリンクページでの確認
設定が効いているかは2か所から確認できます。Google 検索セントラルは、Search Console のパフォーマンスレポートで検索での見え方のフィルタに Android App を指定すると、Android アプリのディープリンクが検出されて表示された状況を確認できると案内しています。もう1つが Play Console のディープリンクのページで、既存の設定の一覧に加えて、ディープリンクが設定されていない広告URLのレポートと、アプリを新しくリリースせずにディープリンクの修正を反映する機能を提供します。パフォーマンスレポートの読み方そのものはサーチコンソールとは？できること・設定手順とSEO改善への使い方【2026年時点】にまとめています。
設定そのものの検証には Android Studio の App Links Assistant（Tools メニュー）も使えます。既存のディープリンクとその検証状態の一覧、リンクごとの設定不備の内訳、設定の自動修正までを扱います。
Android App Linksの実装要件と検証結果の読み方
intent-filterとassetlinks.jsonの必須項目
Android のドキュメントは、通常のディープリンクと App Links を明確に区別しています。前者はすべての Android バージョンで使える代わりにアプリ選択ダイアログの対象になり、後者はサイトとの信頼関係を検証したうえでダイアログを挟まずにアプリを開きます。App Links が使えるのは Android 6 以降で、かつ Google のサービスが入っている端末です。
自動検証の対象になるのは、VIEW アクション、BROWSABLE と DEFAULT の両カテゴリ、http または https のスキームを備えた intent-filter です。DEFAULT が抜けているとリンクをタップしてもアプリが起動しません。
<activity android:name=".ProductActivity" android:exported="true">
<intent-filter android:autoVerify="true">
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme="https" android:host="example.com" />
</intent-filter>
</activity>サイト側には Digital Asset Links のファイルを置きます。配置先は https://ドメイン名/.well-known/assetlinks.json で、content-type を application/json にすること、HTTPS で配信すること、301 や 302 のリダイレクトを挟まないことがDigital Asset Links ファイルの設定ドキュメントで明示されています。複数のホストを扱うなら、ホストごとに同じファイルを置く必要があります。
次は設定例です。package_name は実際のアプリIDへ、sha256_cert_fingerprints は省略のない SHA-256 フィンガープリントへ置き換えてください。後述する apple-app-site-association の appIDs も同様に、実際の Application Identifier Prefix と Bundle Identifier に置き換えます。
[{
"relation": ["delegate_permission/common.handle_all_urls"],
"target": {
"namespace": "android_app",
"package_name": "com.example.app",
"sha256_cert_fingerprints": ["14:6D:E9:83:...:44:E5"]
}
}]App Links検証の実行と状態値の読み方
アプリをインストールすると検証は非同期で走ります。ドキュメントは完了まで20秒以上待つよう指示しています。Android 12 以降は検証を手動で実行できるため、検証端末での確認はこちらが確実です。対象が Android 12 以上のアプリなら更新版の検証処理が自動で使われますが、それ未満を対象にしているアプリでは互換フラグを先に有効化します。
adb shell am compat enable 175408749 com.example.app
adb shell pm set-app-links --package com.example.app 0 all
adb shell pm verify-app-links --re-verify com.example.app
adb shell pm get-app-links com.example.app1行目は Android 12 未満を対象にしたアプリだけに必要です。3行目を実行したら、検証エージェントの通信が終わるまで数分置いてから4行目を実行してください。最後のコマンドがドメインごとの状態を返します。verified なら検証済みです。none は検証がまだ終わっていない可能性があるため数分待って再実行します。legacy_failure や数値コードが返る場合は、assetlinks.json の到達性か、フィンガープリントの不一致を疑ってください。Android 11 以下では、マニフェストに書いたすべてのホストで一致するファイルが見つからないとアプリが既定のハンドラになりません。ホストを1つ追加したまま assetlinks.json を置き忘れると、それまで動いていたリンクごと開かなくなります。
検証が通っていない状態は、症状としては分かりにくい形で出ます。Android 12（API レベル31）以降、汎用的な Web intent は対象ドメインについてアプリが承認されている場合にだけアプリの Activity へ解決され、承認されていなければユーザーの既定のブラウザへ解決されます。アプリ選択ダイアログが出るのではなく、黙ってブラウザで開くということです。ユーザー側の救済手段としては、端末の設定でアプリにドメインを関連付ける操作が残されています。
Play App Signing利用時のフィンガープリント取り違え
検証が通らないときに最初に確認したいのが署名証明書です。Play App Signing を使っている場合、手元で keytool を実行して得たフィンガープリントは、ユーザーの端末にある証明書のものとたいてい一致しません。正しい値は Play Console の Release から Setup、App signing のページに、そのまま貼れる Digital Asset Links の JSON として掲載されています。デバッグビルドと本番ビルドの両方でリンクを試すなら、sha256_cert_fingerprints は配列なので両方の値を並べて記述します。
iOSのUniversal Linksで必要な設定
iOS 側は apple-app-site-association というファイル名（拡張子なし）で、https://対象ドメイン/.well-known/apple-app-site-association に配置します。Apple の関連ドメインのドキュメントは、有効な証明書の HTTPS で配信し、リダイレクトを挟まないことを要件として挙げています。アプリ側は Xcode の Signing & Capabilities で Associated Domains を追加し、applinks: に続けてドメインを指定します。
実務で抜けやすいのがサブドメインの扱いです。example.com と www.example.com と support.example.com を使い分けているなら、それぞれに個別のエントリが必要で、かつそれぞれが自身の apple-app-site-association を配信しなければなりません。www の有無で挙動が変わるときは、対象のサブドメインについて entitlement のエントリと配信ファイルの両方が揃っているかを確認してください。
{
"applinks": {
"details": [{
"appIDs": ["ABCDE12345.com.example.app"],
"components": [
{ "#": "no_universal_links", "exclude": true },
{ "/": "/buy/*" },
{ "/": "/help/*", "?": { "articleNumber": "????" } }
]
}]
}
}更新したのに反映されないときは、ファイルの取得経路を疑ってください。macOS 11 と iOS 14 以降、アプリは apple-app-site-association を Web サーバーから直接ではなく、Apple が運用する関連ドメイン専用の CDN から取得します。CDN が古い版しか持っていない場合も、コピーをまだ持っていない場合も、CDN 側が Web サーバーへ最新版を取りに行きます。裏を返せば、更新直後に CDN が古い版を配っている間は反映されません。公開インターネットから到達できない開発用サーバーで試したい場合は、entitlement のドメインに ?mode=developer を付けて CDN を迂回させます。この指定が効くのは開発者モードの端末と、開発用プロファイルで署名したアプリに限られ、さらに利用する端末ごとにユーザーがオプトインする必要があります。
components はパス（"/"）、クエリ（"?"）、フラグメント（"#"）の単位で対象を絞り込み、exclude を付けたパターンはアプリで開かせません。書いた順序がそのまま評価順序になり、最初に一致したものが採用されます。除外したいパターンを配列の後ろに置くと、先に並んだ許可ルールで一致が確定してしまい除外が効きません。上の例で除外ルールを先頭に置いているのはそのためです。Apple は Universal Links を攻撃経路になりうるものとして扱い、URL のパラメータをすべて検証して不正な URL を破棄すること、ユーザーのデータを危険に晒す操作をリンク経由で実行させないことを求めています。リンクから直接削除処理を呼ぶような設計は避けてください。
Android 15のDynamic App Linksによるサーバー側でのパス出し分け
dynamic_app_link_componentsで指定できる照合パターン
Android 15（API レベル35）で Dynamic App Links が加わりました。Android 15 以降かつ Google のサービスが入った端末は assetlinks.json を定期的に取得し直し、そこに書かれたルールをアプリのマニフェストの静的な設定とマージします。アプリを再リリースせずにリンクの対象パスを変えられるのが利点です。Android 14 以下の端末はこの拡張フィールドを無視するため、ファイルは同じもので共存できます。ただし挙動までは揃いません。マニフェストをホスト単位の広い宣言にしている場合、動的ルールで除外したパスも Android 14 以下ではアプリへ渡ります。除外をどの端末でも効かせたいなら、マニフェスト側でもパスを絞る必要があります。
ルールは relation_extensions の下の dynamic_app_link_components に配列で書きます。パス（"/"）、フラグメント（"#"）、クエリパラメータ（"?"）のパターン照合と、exclude による除外指定が使えます。クエリの照合は辞書で書き、順序は問われません。辞書に書いた組がすべて見つかれば一致で、URL 側に余分なパラメータがあっても構いません。ワイルドカードは * が0文字以上、? が任意の1文字、?* が1文字以上です。
"relation_extensions": {
"delegate_permission/common.handle_all_urls": {
"dynamic_app_link_components": [
{ "/": "/products/*" },
{ "/": "/shoes", "?": { "in_app": "true" } },
{ "/": "*", "exclude": true }
]
}
}ルールの評価順序と、範囲を広げられない制約
順序の扱いが直感に反します。Android はルールを上から順に評価し、最初に一致したところで判断を確定させます。先頭にすべてを除外するルール（"/" が "*" で exclude が true）を置くと、その下に書いた許可ルールは一度も評価されません。逆に、どのルールにも一致しなかった URL はアプリで開かれません。特定のパスだけを除外して残りは従来どおり開きたいのなら、除外ルールの後ろに "*" を許可するルールを明示的に足す必要があります。
制約もあります。動的ルールはマニフェストで宣言したホストの範囲内にしか書けず、静的な設定より対象を広げることはできません。そのためドキュメントは、マニフェスト側はスキームとドメインだけの広い宣言に留め、パス単位の制御は assetlinks.json に任せる構成を推奨しています。dynamic_app_link_components は同じサイト・同じ relation・同じアプリについて1つだけ宣言します。複数あるとどれが使われるか保証されません。フィールドに不正や空があった場合は動的ルールを破棄してマニフェストの設定に戻るため、配信前の JSON の検証は必須です。
なお iOS の apple-app-site-association は以前から components でパスやクエリを出し分けられました。Android はここで iOS に追い付いた形になります。両OSに同じ出し分けを実装するなら、パスの設計をどちらか一方に寄せず、先にURL設計として決めてから両方のファイルに落とすほうが破綻しません。
App Indexingが向かない場面と、期待してはいけない効果
順位改善を目的に着手するのであれば、やめたほうがよい施策です。Google 検索セントラルは2025年5月2日の app deep links の記事で、Webサイトにディープリンクを足してもGoogle 検索でのコンテンツの見せ方は変わらず、インデックス登録とランキングには引き続きWebページの内容を使うと書いています（原文は It doesn’t change how Google Search shows your content; Search continues to use the content of your web pages for indexing and ranking）。App Indexing をランキング要因として紹介する日本語の解説も残っていますが、現行の公式ドキュメントに同じ記述はありません。スマートフォンでの順位を動かしたいなら、スマホのSEO対策｜順位を決める要素と確認の順序【2026年時点】で扱っている表示速度やモバイル向けの実装を先に見るほうが確実です。
同じ記事は、アプリ側のページが対応するWebページと同じ内容である場合にだけディープリンクを足すべきだとも書いています。内容が食い違うと、検索結果に出ているタイトルとスニペットが、タップ後に表示される画面と合わなくなるためです。レイアウトや操作性の違いは、内容が一致している限り問題にならないとされています。Webとアプリで扱う情報が別物なら、関連付けは見送るのが筋です。
効果の範囲もインストール済みユーザーに限られます。まだアプリを入れていない層の獲得はストア側の施策やWebページの役割で、App Indexing は担いません。加えて、Web の URL とアプリの画面が1対1で対応しないサービス（ログイン後にしか意味のない業務アプリ、会員専用ツールなど）は、関連付けても開かせる画面がないため投資に見合いません。
インストール直後に元のコンテンツへ復帰させる、いわゆる遅延ディープリンクも、OS 標準の App Links と Universal Links の守備範囲外です。Firebase Dynamic Links の停止後にこの体験が必要なら、計測基盤を提供する外部サービスを別途選定することになります。そもそもネイティブアプリを持たない構成で検討しているなら、PWAとは？Service Workerとマニフェストの実装手順・ネイティブアプリとの使い分けと採用判断を解説で扱う選択肢のほうが、維持する対象が1つで済みます。
よくある質問
App Indexingは2026年現在も使えますか？
使えます。ただし中身は当時と違います。Play Console の Advanced settings にある App indexing からサイトの関連付けを申請し、Search Console 側で承認する機能として提供されています。アプリに SDK を組み込む方式ではありません。
Firebase App IndexingのSDKは使い続けてよいですか？
新規の実装には向きません。Firebase の FAQ が推奨しない旨を明記しており、Android 版 Google 検索アプリは Firebase App Indexing で端末内にインデックスされた内容を結果に使わなくなっています。既存アプリに残っている場合は、Android App Links と Universal Links への移行を前提に棚卸ししてください。
「インデクシング」と検索エンジンの「インデックス」は同じ意味ですか？
重なりますが同じではありません。インデクシングは索引付け全般を指す語で、文献データベースの索引作業やデータベースのインデックス構築も含みます。SEO で言うインデックスはクロール済みのWebページを検索用データベースに登録することを指し、App Indexing はアプリ内の画面を検索結果の遷移先にする別の仕組みです。
App Indexingを設定すると検索順位は上がりますか？
上がりません。Google 検索セントラルは2025年5月2日の記事で、ディープリンクを足してもGoogle 検索でのコンテンツの見せ方は変わらず、インデックス登録とランキングには引き続きWebページの内容を使うと書いています。順位ではなく、検索から流入したユーザーの遷移先を変える施策と考えてください。
検索結果をタップしてもアプリが開きません。どこから確認しますか？
Android なら adb shell pm get-app-links にパッケージ名を渡し、対象ドメインの状態が verified になっているかを見ます。verified でなければ、assetlinks.json が HTTPS でリダイレクトなしに取得でき、content-type が application/json になっているか、sha256_cert_fingerprints が Play App Signing の値と一致しているかを順に確認します。iOS なら apple-app-site-association がサブドメインごとに配信されているか、Associated Domains の applinks: の指定と一致しているかを確認します。
