App Indexing（検索のためのアプリディープリンク）

TL;DR — 「App Indexing」は、スマートフォンアプリからコンテンツを取り出して検索結果に表示していた、かつてのGoogleの機能です。Googleはこれを終了しました。現在使われているのはアプリディープリンクと呼ばれる仕組みです。アプリをすでにインストールしていれば、検索結果をスマートフォンのブラウザーではなくアプリ内で開くリンクです。重要なのは、これで順位が上がるわけではないことです。Googleが順位を決めるのは今もウェブサイトであり、ディープリンクはタップ後の行き先を変えるだけです。

「App Indexing」とは何だったのか

以前、Googleではウェブサイトとネイティブモバイルアプリを接続し、アプリのコンテンツと、アプリへ直接入るリンクを検索結果に表示できました。この仕組みはApp Indexing（後のFirebase App Indexing）と呼ばれていました。何かを検索したとき、対応するアプリがインストール済みなら、ウェブページではなくアプリへ送ることができたのです。

古いSEOチェックリスト、開発者ドキュメント、プラグイン設定で「App Indexing」を見つけたためにこの記事を読んでいるなら、短い答えはこうです。廃止されています。 Googleは停止しました。設定する必要はなく、設定を勧めるチュートリアルは古い情報です。

何に置き換わったのか

検索結果から「自分のアプリを開く」現代的な仕組みはアプリディープリンクと呼ばれ、プラットフォームごとに独自の名称があります。

• AndroidではApp Linksと呼びます。
• iOSではUniversal Linksと呼びます。

どちらも役割は同じです。Googleの結果、別のウェブサイト、アプリなどからサイトへのリンクをタップした人が、すでにアプリをインストールしていれば、そのコンテンツをアプリ内で開きます。アプリがなければ、同じリンクが通常どおりブラウザーで開くだけです。

多くの人が誤解していること

アプリディープリンクは順位に影響しません。 これは忘れるべき神話です。古い記事には「アプリをインデックス登録すると順位が上がる」と書かれています。Googleは、そうではないと明確に述べています。検索で順位を決めるのは今もウェブページのコンテンツです。ディープリンクが変えるのは、アプリを持っている人がクリックした後の体験だけです。順位を操作する仕組みではなく、利便性のための機能です。

設定する場合の本当のルールは1つです。リンク先のアプリ画面には、ウェブページと同じコンテンツを表示してください。Googleはウェブページから検索スニペットを作るため、アプリに別の内容を表示すると、タップした人を誤解させることになります。

詳しい歴史、AndroidとiOSの正確なファイルや手順、Search Consoleでの測定方法を知りたい場合は、Advancedタブに切り替えてください。

TL;DR — Google App Indexing（2013年）→ Firebase App Indexing（2016年、「app streaming」の短期間の実験を含む）→ 2021年ごろに廃止。後継はアプリディープリンクです。Android App Links（/.well-known/assetlinks.jsonのDigital Asset Linksファイルとandroid:autoVerifyのintent filterで検証）と、iOS Universal Links（apple-app-site-associationファイルとAssociated Domains entitlementで検証）があります。Googleの2025年5月の指針によれば、ディープリンクはインデックス登録や順位を変えません。検索で順位付けされるのは今もウェブページであり、ディープリンク先はウェブURLのコンテンツに対応させる必要があります。専用のSearch Consoleレポートがあると決めつけず、プラットフォームとアプリの分析でアプリリンクの動作を測定してください。

1つの紛らわしい名前に3つの時代

「App Indexing」が混乱を招くのは、同じ考え方が10年の間に3つの名前を使い、最後の移行が廃止だったのに、古いコンテンツの多くが追いついていないからです。

2013〜2016年 — Google App Indexing。 2013年10月、Googleは “Googlebot can now index content in your Android app,” (翻訳)「GooglebotはAndroidアプリのコンテンツをインデックス登録できるようになった」と発表し、アプリへのディープリンクを “straight in our search results when we think they’re relevant… and if the user has the app installed.” (翻訳)「ユーザーのクエリに関連し、アプリをインストールしている場合には、検索結果に直接表示する」と説明しました。アプリのコンテンツは既存のサイトマップとWebmaster Toolsを通じて申告しました。これはGoogleがウェブページをクロールするのと同じように、アプリの内部をクロールする仕組みでした。

2016〜2021年ごろ — Firebase App Indexing。 Googleが2014年にFirebaseを買収した後、App Indexingは2016年のGoogle I/O前後にFirebase App Indexingへ改称されました。iOS対応が追加され、しばらくはapp streamingという実験もありました。「Try Now」ボタンから、未インストールのアプリを検索結果からブラウザー内で数分間実行できる機能です。app streamingは2015〜2016年ごろの限定的な実験で、現在は存在しません。これを前提に計画しないでください。

2021年ごろ〜現在 — 廃止。 AppIndexApiインターフェースはGoogle自身のAndroidリファレンスドキュメントでdeprecatedと記されています。Firebaseの現行ドキュメントには、Firebase App Indexingは “is no longer the recommended way of indexing content for display as suggested results in Google Search App,” (翻訳)「Google Search Appで候補結果として表示するコンテンツのインデックス登録に推奨される方法ではなくなった」と明記され、さらに “the Google Search App for Android no longer uses local content indexed via Firebase App Indexing to provide results to users.” (翻訳)「Android版Google Searchアプリは、Firebase App Indexingでインデックス登録されたローカルコンテンツを結果の提供に使用しなくなった」と注意書きがあります。Firebaseは現在、推奨する方法としてApp LinksとUniversal Linksを案内しています。（移行は2021年に行われました。廃止の注意書きは2022年10月のアーカイブにはありますが、2020年10月にはありません。）

App Indexingの後継：アプリディープリンク

ディープリンクとは、Googleの言葉では “special URIs that take users beyond your mobile app’s homepage, leading them directly to specific in-app content.” (翻訳)「モバイルアプリのホーム画面より先へ進み、アプリ内の特定コンテンツへ直接導く特別なURI」です。古いモデルからの重要な考え方の転換は、これは検証とルーティングであり、OSとブラウザーのレベルで処理されることです。Googleが運用するインデックス登録パイプラインではありません。ここで何かを「インデックスに送信」するわけではありません。

Android App Links（Digital Asset Links / assetlinks.json）

Googleによれば、Android App Linksは “an enhanced deep linking capability that verifies deep links to your own website by establishing a trusted association between your app and your website. After they are verified, deep links to your website can immediately open corresponding content in your app, without requiring the user to select your app from a disambiguation dialog.” (翻訳)「アプリとウェブサイトの信頼できる関連付けを確立して自分のウェブサイトへのディープリンクを検証する、強化されたディープリンク機能」です。検証されると、ウェブサイトへのディープリンクは、ユーザーがアプリを選ぶ曖昧性解消ダイアログを必要とせず、対応するコンテンツをすぐにアプリで開けます。App LinksはAndroid 6以降でサポートされ、Googleは自分のサイトへのディープリンクに対する “a recommended approach” (翻訳)「推奨される方法」としています。

検証の握手を担うのがDigital Asset Linksファイルです。intent filterにandroid:autoVerify="true"を設定してアプリをインストールすると、“Android queries the corresponding websites for the Digital Asset Links file at https://hostname/.well-known/assetlinks.json.” (翻訳)「Androidは対応するウェブサイトにあるDigital Asset Linksファイルを確認します」。このJSONファイルには、ドメインのリンクを処理できるアプリのパッケージ（および署名証明書のフィンガープリント）が記載されます。Android 15ではDynamic App Linksが追加され、新しいアプリバージョンを配布せずにURLマッチングの動作を細かく調整できます。

ここではバージョンと署名に関する2つの境界が重要です。第一に、Dynamic App Linksは基礎となるマニフェストの関連付けを置き換えるのではなく拡張します。Android 15未満では、標準のマニフェストとassetlinks.jsonの一致だけで検証が行われます。第二に、assetlinks.jsonに記載した署名証明書のフィンガープリントがインストール済みビルドの実際の署名IDと完全に一致しなければ、検証は部分的ではなく完全に失敗します。assetlinks.jsonとは別の鍵で署名したデバッグビルドは、他の項目が正しくても検証されません。

区別を明確にしておきましょう。基本的なAndroidディープリンクはintent filterを使いますが、“which app do you want to open this with?” (翻訳)「どのアプリで開きますか」という曖昧性解消ダイアログが表示されることがあります。App LinksはDigital Asset Linksの検証を追加するため、検証済みドメインはダイアログなしでアプリを直接開きます。

iOS Universal Links（apple-app-site-association）

Appleに相当する仕組みがUniversal Linksです。Appleは “When users tap or click a universal link, the system redirects the link directly to your app without routing through the person’s default web browser or your website… because universal links are standard HTTP or HTTPS links, one URL works for both your website and your app. If the person hasn’t installed your app, the system opens the URL in their default web browser.” (翻訳)「ユニバーサルリンクをタップまたはクリックすると、通常のウェブブラウザーやウェブサイトを経由せずアプリへ直接移動します。ユニバーサルリンクは標準のHTTPまたはHTTPSリンクなので、ウェブサイトとアプリの両方に1つのURLを使えます。アプリがインストールされていなければ、URLは通常のウェブブラウザーで開きます」と説明しています。

ここで使う検証ファイルは、ウェブサーバーでホストする**apple-app-site-associationです。“When someone installs your app, the system checks a file stored on your web server to verify that your website allows your app to open URLs on its behalf.” (翻訳)「アプリをインストールすると、システムはウェブサーバー上のファイルを確認し、ウェブサイトがアプリによるURLの代理オープンを許可しているか検証します」。アプリ側では、そのファイルのドメインに一致するAssociated Domains** entitlementが必要です。Androidと同じく、これはサイトとアプリの信頼の握手であり、検索順位のシグナルではなくデバイスが確認します。

有効なapple-app-site-associationファイルと正しく一致するentitlementがあっても、すべてのタップがアプリを開くとは限りません。Appleは、関連付けが機能していてもUniversal LinkがSafariで開く実例を文書化しています。たとえば、Safari内ですでに同じドメインを閲覧中にリンクをタップした場合や、そのドメインのリンクをブラウザーで開き続けることを以前に選択した場合です。また、アプリが本当にインストールされていない場合や関連付けが一致しない場合、標準のHTTP(S)リンクは壊れたカスタムスキームで行き止まりになるのではなく、ブラウザーで開くようフォールバックするのが仕様です。これは追いかけるべきバグではなく、システムが設計どおり動いている状態です。

両プラットフォームは、ディープリンクのリンク先としてGoogle Searchに対応しています。

アプリディープリンクは順位に影響するのか？（いいえ — 正確な引用）

これはテーマ全体で最も重要な訂正です。順位を扱うページでさえ、今も間違えているからです。“App Indexing will influence ranking… whether or not the user has your app installed” (翻訳)「アプリをインストールしているかどうかにかかわらず、App Indexingが順位に影響する」や、“Google will use the content within your app as a signal in ranking” (翻訳)「Googleはアプリ内のコンテンツを順位付けのシグナルとして使う」と主張する記事があります。これらは誤りで、Google自身の2025年5月の投稿は次のように明言しています。

“Adding deep links to your website connects the website’s URLs with the relevant app pages. 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 deep links enable users to go from Search results directly to the corresponding app page (if installed), resulting in a better user experience.” (翻訳)「ウェブサイトにディープリンクを追加すると、そのURLと対応するアプリページが結び付きます。Google Searchでのコンテンツの表示方法は変わらず、Searchはインデックス登録と順位付けにウェブページのコンテンツを使い続けます。ディープリンクは、アプリがインストール済みなら検索結果から対応するアプリページへ直接移動できるため、ユーザー体験が向上します。」 + Evidence for this claim Google says adding app deep links does not change how Search indexes or ranks content; the corresponding web page remains the indexing and ranking source. Scope: public web Confidence: high · Verified: 2026-07-18 App deep links: connecting your website and app

ここは注意深く読んでください。インデックス登録と順位付けの対象はウェブページです。ディープリンクは、アプリをすでに持っているユーザーに対してクリック後にだけ働くルーティング層です。表示を改善するUXであり、可視性を上げる仕組みではありません。assetlinks.jsonを設定すれば順位が上がると言う人がいたら、それは間違いです。

1つだけある本当の要件：コンテンツの同等性

実質的なルールは1つだけで、ユーザーへの誠実さに関するものです。Googleは次のように述べています。

“Because Search uses your web page content for indexing and ranking, you should only add deep links in cases where the app page contains the same content as the corresponding web page. Otherwise, the title and snippet shown for the page in Google Search could mislead users about the content they will see after they click. Layout or other UX differences between app pages and the corresponding web pages are OK, as long as the content matches.” (翻訳)「Searchはインデックス登録と順位付けにウェブページのコンテンツを使うため、アプリページが対応するウェブページと同じコンテンツを含む場合にだけディープリンクを追加してください。そうしないと、Google Searchに表示されるtitleとスニペットが、クリック後に見るコンテンツについてユーザーを誤解させる可能性があります。アプリページと対応するウェブページのレイアウトやその他のUXが違っていても、コンテンツが一致していれば問題ありません。」

つまり、ネイティブで見た目がよく、レイアウトが異なるアプリ画面は問題ありません。ウェブページと異なるコンテンツを表示する画面は問題です。ユーザーがタップしたスニペットはウェブページから作られ、そこから一致しない場所へ移動することになるからです。同等性で重要なのは見た目ではなくコンテンツです。

現在の実装方法

Android： App Linksを使います。アプリのマニフェストでandroid:autoVerify="true"を含むintent filterを設定してアプリとウェブサイトを関連付け、サイトの/.well-known/assetlinks.jsonにアプリのパッケージ名と署名証明書フィンガープリントを記載して公開します。Androidはインストール時に関連付けを検証します。Android StudioのApp Links Assistantと、Play ConsoleのDeep Linksページは設定の生成と検証に役立ちます。

iOS： Universal Linksを実装します。ウェブサーバーにapple-app-site-associationファイルを公開し、アプリに対応するパスを記述します。さらに、対応するドメインをアプリのAssociated Domains entitlementに追加します。AppleのUniversal Linksデバッグガイドでは、ファイルの誤ったcontent-type、entitlementの欠落、キャッシュされた関連付けなど、よくある失敗を確認できます。

どちらのファイルも、App Indexingが示唆したような「検索インデックス」にクロールされるものではありません。デバイスが確認する信頼の握手です。間違っていればリンクはブラウザーへフォールバックし、正しければインストール済みユーザーはアプリへ移動します。

最小限の関連付けファイルチェック

curl -sI https://example.com/.well-known/assetlinks.json
curl -sI https://example.com/.well-known/apple-app-site-association

両方のエンドポイントはリダイレクトせずに200を返し、想定されるJSONレスポンスを公開する必要があります。Scriptsタブには、content-type、リダイレクト、PowerShell、DevTools、ブックマークレットによる拡張チェックがあります。

測定方法：Search ConsoleのAndroidアプリフィルター

Googleはアプリディープリンクのパフォーマンスをネイティブに提供しています。“Search Console includes performance of your site’s app deep links for Android. In the Performance report, you can use the Android App Search appearance filter to see when your Android app deep links are found and shown to users.” (翻訳)「Search ConsoleではサイトのAndroid向けアプリディープリンクのパフォーマンスを確認できます。Performanceレポートでは、Android App検索での表示フィルターを使い、Androidアプリのディープリンクが見つかってユーザーに表示された時点を確認できます。」これにより、Androidアプリのディープリンクが表示された結果のクリック数、表示回数、CTR、掲載順位を確認できます。何が起きているかを見るための、具体的で現行の方法です。（このフィルターは2019年に追加され、Googleの2025年の投稿でも現在のツールです。）

ただし、2つの役割は分けて考えてください。Search Consoleのフィルターはトラフィック／表示レポートです。Androidのみで、特定のクエリに対してGoogleがアプリディープリンク表示を実際に出すかどうかに左右され、技術的にインデックス登録や順位付けが行われた証拠そのものではありません。ディープリンクが技術的に動くことの確認は別の作業です。関連付けファイルを取得し、実機でタップからの遷移をテストしてください（ScriptsタブとValidation Testsタブを参照）。Search Consoleのレポートが静かなことを設定不良の証拠と見なさず、レポートのクリックをSEOシグナルと見なさないでください。レポートが示すのは順位ではなくルーティング量です。

Bingとアプリディープリンク

ここでGoogleとBingが同じだと仮定しないでください。Bingは2014年4月からWindows中心の「app linking」プログラムを実施し、Windows 8,1とWindows Phoneを対象にしていました。しかし、そのページは現在消滅しています（開発者URLは404を返し、ブログ記事は一般的なブログホームへリダイレクトします）。Windows Phone自体も終了しました。Googleの2025年のアプリディープリンク指針に相当する、現在のBing公式文書はありません。 実務上は、App LinksとUniversal LinksがOSとブラウザーのレベルの標準であるため、検索エンジンが対応を選ぶ仕組みではなく、モバイルのBing／Edgeでも機能します。Bingを指し示すドキュメントがないだけです。

今も見かけるレガシーなもの

隣接する技術がいくつか混乱を招くため、名前を確認して先へ進みます。

• potentialAction／ViewActionのschema.orgマークアップと、android-app://のディープリンク先。これは古いApp Indexing時代に結び付いたレガシー技術です。コードベースやschema.orgのaction語彙で今も見かけることがありますが、Googleの現行推奨はこのマークアップではなくApp Links／Universal Linksの設定です。「まだ見かけるかもしれないもの」であり、推奨事項とは考えないでください。
• Firebase Dynamic Linksは、別の、個別に廃止されたFirebase製品です。マーケティングのアトリビューション向けのURL短縮／遅延ディープリンクサービスであり、App Indexingのコンテンツシステムではありません。これも終了予定で、移行ガイダンスはApp LinksとUniversal Linksを案内しています。2つの廃止を混同しないでください。

覚えておくべきモデルは明快です。(1) 旧Google App Indexing／Firebase App Indexingのクロールとストリーミングのシステム = 終了。(2) App Links／Universal Linksのディープリンク = 現行、ルーティング／UXのみで順位への影響なし。(3) Bingの古いWindows時代のアプリリンク = こちらも終了し、文書化された後継なし。

AIによる要約

Advanced版を簡潔にまとめると、次のとおりです。

• App Indexingは廃止。 Google App Indexing（2013年）→ Firebase App Indexing（2016年）→ 2021年ごろに廃止。 AppIndexApiはGoogleのドキュメントでdeprecatedと記され、Google SearchアプリはFirebase App Indexingのコンテンツを使用しなくなりました。
• 後継はアプリディープリンク。 Android App Links（/.well-known/assetlinks.jsonのDigital Asset Linksファイルとandroid:autoVerifyのintent filterで検証）と、iOS Universal Links（apple-app-site-associationとAssociated Domains entitlementで検証）です。Googleが運用するインデックスではなく、OS／ブラウザーのレベルで検証とルーティングを行います。
• ディープリンクは順位に影響しません。 Googleの2025年5月の投稿によれば、“don’t change how Google Search shows your content; Search continues to use the content of your web pages for indexing and ranking.” (翻訳)「Google Searchでのコンテンツの表示方法を変えず、Searchはインデックス登録と順位付けにウェブページのコンテンツを使い続けます」。クリック後、インストール済みユーザーをアプリへ移動させるだけです。
• 本当のルールはコンテンツの同等性。 ウェブページと同じコンテンツを表示するアプリ画面にだけディープリンクしてください（レイアウト／UXの違いは問題ありません）。
• 測定する。 Search ConsoleのAndroid app検索での表示フィルターを使います。ただしこれはトラフィックレポートであり、技術的な関連付けが機能することや、順位が変わったことの証明ではありません。関連付け自体は実機とファイルのテストで確認します。
• 検証済みでも、すべてのタップがアプリを開くとは限りません。 Androidでは署名証明書の不一致で検証が完全に失敗します（Android 15のDynamic App Linksはマニフェストの一致を拡張しますが、置き換えません）。iOSでも、同じドメインをSafariで閲覧中の場合や、以前にブラウザーで開くことを選んだ場合など、関連付けが機能していてもUniversal Linkがブラウザーで開く正当なケースをAppleが説明しています。
• Bing。 現在の同等の指針はありません。Windows時代のプログラムは終了していますが、App Links／Universal LinksはOSレベルの標準なのでEdgeでは機能します。
• 混同しない。 App IndexingとFirebase Dynamic Links（別の、個別に廃止された製品）を混同しないでください。また、potentialAction／ViewActionマークアップを現行のベストプラクティスと扱わないでください。

公式ドキュメント

Google、Android、Appleによる一次資料のドキュメントです。

Google — 現在の指針

• ウェブサイトとアプリをつなぐアプリディープリンク（2025年5月2日）— 現在の権威ある解説。ディープリンクの役割、順位に影響しないという説明、コンテンツの同等性、Search Consoleのフィルターを扱います。
• Firebase App Indexing — 廃止の注意書きと、App Links／Universal Linksへの案内を掲載する現行ページ。

Google — 歴史（何が廃止されたかを理解するため）

• ウェブサイトと同じようにアプリをインデックス登録する（2013年10月31日）— App Indexingの最初の発表。

Android

• ディープリンクについて — ディープリンク、App Links、検証モデル（2026年6月18日更新）。
• Android App Linksを検証する — android:autoVerifyとDigital Asset Links／assetlinks.jsonの要件。

Apple

• アプリとウェブサイトによるコンテンツへのリンクを許可する — Universal Linksの概要とサーバーファイルによる検証モデル。
• 関連ドメインをサポートする — apple-app-site-associationファイルとAssociated Domains entitlement。

業界標準（Google固有ではない）

• ViewAction／Actions（schema.org）— レガシーなpotentialAction／ViewAction語彙の説明。現在のGoogle推奨ではなく、背景情報として役立ちます。

出典からの引用

Google、Android、Appleによる記録に残る発言です。Google／Androidの各リンクは、出典ページの引用箇所へ移動するディープリンクです。

Google — App Indexingの最初の発表（2013年）

• “Just like it crawls and indexes websites, Googlebot can now index content in your Android app… If both the webpage and the app contents are successfully indexed, Google will then try to show deep links to your app straight in our search results when we think they’re relevant for the user’s query and if the user has the app installed.” (翻訳)「Googlebotはウェブサイトをクロールしてインデックス登録するのと同じように、Androidアプリのコンテンツもインデックス登録できます。ウェブページとアプリのコンテンツが正常にインデックス登録されると、ユーザーのクエリに関連し、アプリをインストールしている場合に、アプリへのディープリンクを検索結果へ直接表示します。」 — Googleのプロダクトマネージャー、Lawrence Chang。 引用へ移動

Google — Firebase App Indexingは廃止（現行ドキュメント）

• “Firebase App Indexing is no longer the recommended way of indexing content for display as suggested results in Google Search App.” (翻訳)「Firebase App Indexingは、Google Search Appで候補結果として表示するコンテンツのインデックス登録に推奨される方法ではなくなりました。」 引用へ移動

Google — ディープリンクは順位を変えない（2025年5月）

• “It doesn’t change how Google Search shows your content; Search continues to use the content of your web pages for indexing and ranking.” (翻訳)「Google Searchでのコンテンツの表示方法は変わらず、Searchはインデックス登録と順位付けにウェブページのコンテンツを使い続けます。」 — Google Search RelationsのJohn MuellerとAndroid Developer RelationsのSabs。 引用へ移動
• “You should only add deep links in cases where the app page contains the same content as the corresponding web page.” (翻訳)「アプリページが対応するウェブページと同じコンテンツを含む場合にだけ、ディープリンクを追加してください。」 引用へ移動

Android — App Linksと検証ファイル

• “Android App Links is an enhanced deep linking capability that verifies deep links to your own website by establishing a trusted association between your app and your website.” (翻訳)「Android App Linksは、アプリとウェブサイトの信頼できる関連付けを確立して、自分のウェブサイトへのディープリンクを検証する強化された機能です。」 — Android Developers。 引用へ移動
• “Android queries the corresponding websites for the Digital Asset Links file at https://hostname/.well-known/assetlinks.json.” (翻訳)「Androidは対応するウェブサイトにあるDigital Asset Linksファイルを確認します。」 引用へ移動

Apple — Universal Links

• “When users tap or click a universal link, the system redirects the link directly to your app without routing through the person’s default web browser or your website… If the person hasn’t installed your app, the system opens the URL in their default web browser.” (翻訳)「ユニバーサルリンクをタップまたはクリックすると、通常のウェブブラウザーやウェブサイトを経由せずアプリへ直接移動します。アプリがインストールされていなければ、URLは通常のウェブブラウザーで開きます。」 — Apple Developer Documentation, “Allowing apps and websites to link to your content.” (翻訳)「アプリとウェブサイトによるコンテンツへのリンクを許可する」。

アプリディープリンクを設定すべきか？

「そもそも必要なのか」という問いを、簡単にたどる手順です。多くのサイトでは、正直な答えが「いいえ」だからです。

1. ウェブサイトのコンテンツを再現するネイティブモバイルアプリがありますか？

• アプリがない → 停止。ディープリンクするものがありません。App Indexing／ディープリンクは関係ありません。（チェックリストで「App Indexing」を見つけたなら、その行を削除してください。廃止されています。）
• ある → 続けます。

2. 順位のために実施していますか？

• はい → 停止して読み直してください。ディープリンクはインデックス登録や順位に影響しません。SEOの可視性が目的なら、ディープリンクの配管ではなくモバイルウェブページに投資します。
• いいえ — インストール済みユーザーをアプリへ移動させたい → 続けます。

3. アプリ画面は対応するウェブページと同じコンテンツを表示しますか？

• いいえ（内容が異なる） → そのURLにはディープリンクしないでください。スニペットはウェブページから作られるため、不一致はユーザーを誤解させます。まず同等性を直してください（レイアウト／UXの違いは問題ありません。コンテンツの違いは問題です）。
• はい → 続けます。

4. どのプラットフォームですか？

• Android → App Links：android:autoVerifyのintent filterと、/.well-known/assetlinks.jsonのDigital Asset Linksファイル。
• iOS → Universal Links：サーバー上のapple-app-site-associationとAssociated Domains entitlement。
• 両方 → 両方を実施します。互いに独立しています。

5. 動作しているとどう判断しますか？

• Androidでは、Search ConsoleのAndroid app検索での表示フィルターを確認します。
• 実機で実際のタップ遷移をテストし、関連付けファイルを検証します（AndroidではApp Links Assistant、iOSではAppleのUniversal Linksデバッグ）。

判断の目安： ディープリンクは、本物のコンテンツ一致アプリを持つサイトのUX／ルーティングを改善するものです。SEO順位プロジェクトではなく、古いガイドに「App Indexing」と書かれていたから追加するものでもありません。

アプリディープリンク設定チェックリスト

ウェブコンテンツを再現するネイティブアプリがある場合に限り関係します。

• 順位上昇を期待していないことを確認した — ディープリンクはルーティングを変えるのであって、順位を変えるものではない。
  • コンテンツの同等性を確認した：ディープリンク先の各アプリ画面が、対応するウェブページと同じコンテンツを表示する（レイアウト／UXの違いは問題ない）。
  • Android： ドメインのintent filterでandroid:autoVerify="true"を使っている。
  • Android： /.well-known/assetlinks.jsonをHTTPSで公開し、正しいcontent-typeで配信し、アプリのパッケージ名と署名証明書フィンガープリントを記載した。
  • iOS： サーバー上にapple-app-site-associationを公開した（正しいcontent-type、リダイレクトなし、正しいパスパターン）。
  • iOS： アプリにAssociated Domains entitlementを追加し、関連付けファイルのドメインと一致させた。
  • AndroidとiOSの実機で、インストール済みと未インストールのケースのタップ遷移をテストした。
  • 公開後、Search ConsoleのAndroid app検索での表示フィルターで表示回数／クリック数を確認した。
  • 廃止された参照を削除した — 古いApp Indexingサイトマップタグ、Firebase App Indexing SDKの呼び出し、「主要な仕組み」として頼っていたpotentialAction／android-app://マークアップ。

避けるべきアンチパターン

• App Indexingを現行の仕組みとして扱う。 AppIndexApiは廃止され、Google SearchアプリはFirebase App Indexingのコンテンツを使用しません。「App Indexingを有効にする」と指示するガイド、プラグイン、チェックリストは古い情報です。
• 順位上昇を期待する。 古い順位ページで最も繰り返される神話は「アプリのインデックス登録が順位に影響する」です。Googleは逆のことを述べています。検索で順位付けされるのはウェブページであり、ディープリンクは変えません。
• 内容の異なる画面へディープリンクする。 ウェブページのスニペットをタップしたユーザーを、別のコンテンツのアプリ画面へ送ることです。Googleはこれがユーザーを誤解させると明確に警告しています。同等性で重要なのは見た目ではなくコンテンツです。
• 「app streaming」を追いかける。 未インストールアプリをプレビューする「Try Now」機能は2015〜2016年の実験で、終了しています。これを前提に設計しないでください。
• Firebase App IndexingとFirebase Dynamic Linksを混同する。 別の製品で、どちらも廃止され、異なる問題（コンテンツのインデックス登録とURL短縮／アトリビューション）を解決します。現在はどちらもApp Links／Universal Linksを案内しています。
• Bingも同じだと考える。 Bingの古いWindows時代のアプリリンクプログラムは、文書化された後継なしに終了しました。App Links／Universal LinksはOSレベルの標準なのでEdgeでは機能しますが、従うべきBingドキュメントはありません。
• 検証を省き、「なぜ動かないのか」と悩む。 間違ったcontent-type、関連付けファイルのリダイレクト、entitlementの欠落があると、静かにブラウザーへ戻ります。ファイルは提案ではなく、厳密な握手です。

よくあるアプリディープリンクの失敗

Androidでウェブリンクがブラウザーで開き続ける

症状： インストール済みアプリが対応するHTTPS URLを処理しません。考えられる原因： マニフェストのホスト、パッケージ名、署名証明書フィンガープリント、またはassetlinks.jsonのレスポンスが一致せず、ドメイン検証に失敗しています。修正： インストール済みビルドの署名IDを確認し、関連付けファイルを直接取得してから、タップを再テストする前にAndroidのリンク検証を再実行します。

Universal LinkがiOSアプリではなくSafariで開く

症状： 同じHTTPS URLはウェブでは動くのに、インストール済みアプリを迂回します。考えられる原因： Associated Domains entitlementまたはapple-app-site-associationのパスがURLを許可していません。ただし、壊れていないケースを先に確認してください。Apple自身の指針では、同じドメインのSafari内でタップしたリンクや、以前にブラウザーで開くことを選んだドメインは、検証失敗ではなく想定されたブラウザー表示です。修正： ドメインのentitlement、ファイルの可用性、パスのルールを確認し、再インストールまたはデバイスの関連付け状態を更新してから再テストします。関連付けが壊れていると決めつける前に、同一ドメインや以前のユーザー選択による動作を除外してください。

アプリが間違った画面を開く

症状： 検証は成功するのに、アプリがホームページや内容の異なる画面を開きます。考えられる原因： OSの関連付けは正しい一方、アプリのルートマッピングが不完全です。修正： 受け取ったパスとパラメーターを対応する画面へマッピングし、安全なウェブフォールバックを残します。さらに、検索スニペットを提供したウェブページとアプリのコンテンツを比較します。

アプリディープリンク — チートシート

過去と現在

検証ファイル

要点

• ディープリンクが変えるのはクリック後のルーティングであり、インデックス登録や順位ではない。
• ウェブページとコンテンツが一致するアプリ画面だけにディープリンクする。
• Androidにはandroid:autoVerify="true"のintent filterが必要。
• iOSにはAssociated Domains entitlementが必要。
• GSCのAndroid app検索での表示フィルターで測定する。
• Bing：現在の同等の指針はないが、標準はEdgeでも機能する。

関連付けファイルを確認する

ディープリンクは静かに失敗するため、最速のデバッグ手順は、2つの検証ファイルが存在し、200を返し、正しいcontent-typeで配信されていることを確認することです。

macOS / Linux — ファイルを取得して確認する

# Android — Digital Asset Links. Expect HTTP 200 and application/json.
curl -sI https://example.com/.well-known/assetlinks.json | grep -iE "HTTP/|content-type"
curl -s https://example.com/.well-known/assetlinks.json | head

# iOS — apple-app-site-association. Must be 200, JSON, and NOT redirected.
# -L follows redirects; if the final URL differs, that's a problem for iOS.
curl -sIL -o /dev/null -w "final: %{url_effective}  code: %{http_code}\n" \
  https://example.com/.well-known/apple-app-site-association

Windows (PowerShell)

# Android
(Invoke-WebRequest -Uri "https://example.com/.well-known/assetlinks.json").Headers["Content-Type"]

# iOS — confirm status and that it isn't redirecting away
Invoke-WebRequest -Uri "https://example.com/.well-known/apple-app-site-association" -MaximumRedirection 0

ブラウザーのDevToolsコンソール — 到達性を簡単に確認する

// Paste in the console on your own domain. Both should log ok:true.
["/.well-known/assetlinks.json", "/.well-known/apple-app-site-association"]
  .forEach(async p => {
    const r = await fetch(p, { redirect: "manual" });
    console.log(p, "ok:", r.ok, "type:", r.headers.get("content-type"));
  });

ブックマークレット — 現在のサイトをワンクリックで確認する

javascript:(async()=>{for(const p of["/.well-known/assetlinks.json","/.well-known/apple-app-site-association"]){try{const r=await fetch(p,{redirect:"manual"});alert(p+"\nstatus: "+r.status+"\ntype: "+(r.headers.get("content-type")||"—"));}catch(e){alert(p+" — fetch failed: "+e.message);}}})();

ファイルが見つからない応答を返す、リダイレクトする、または誤ったcontent-typeで配信されると、OSは関連付けを検証できません。リンクはアプリを開かず、静かにブラウザーへフォールバックします。

ディープリンクの設定とデバッグに使うツール

• Android Studio — App Links Assistant — intent filterを生成し、Digital Asset Links（assetlinks.json）を作成・検証し、リンク処理をテストします。
• Google Play Console — Deep Linksページ — アプリのディープリンクと検証の状態を表示します。
• Digital Asset Linksの検証 — 公開したassetlinks.jsonがドメインとアプリのパッケージ／フィンガープリントを正しく関連付けることを確認します。
• Apple Universal Linksのデバッグ — Universal Linkがアプリではなくブラウザーで開く理由を診断するAppleの指針です（関連付けファイルのcontent-type、entitlement、キャッシュ）。
• Google Search Console — Performanceレポート — Android app検索での表示フィルターに、Androidアプリのディープリンクが表示された結果の表示回数、クリック数、CTR、掲載順位が出ます。
• curl／DevTools／ブックマークレット — 両方の関連付けファイルが正しいcontent-typeでリダイレクトなしに200を返すことを最初に確認する最速の方法です（Scriptsタブを参照）。

時間をかける価値のあるリソース

私の執筆

• Mobile-First Indexing Goes Mobile-Only — 関連しますが別の概念です。Googleがページのどのバージョンをインデックス登録するかを扱うもので、アプリのディープリンクと混同しないでください。
• The Beginner’s Guide to Technical SEO — モバイルやアプリに隣接するテーマが、クロール／インデックス／順位という大きな文脈のどこに位置するかを説明します。

私の講演

• 検索の仕組み（SlideShare）— Googlebotがスマートフォンとしてクロールすることを含め、クロール、レンダリング、インデックス登録、順位付けを解説しています。（恒常的な免責：“This is my understanding of systems… not going to be 100% complete or accurate.” (翻訳)「これはシステムに関する私の理解であり、完全または正確とは限りません。」）

業界の資料

• ウェブサイトとアプリをつなぐアプリディープリンク（Google）— 現在の権威ある指針で、順位に影響しないこととコンテンツの同等性に関する記述の出典です。
• Firebase App Indexing（Google／Firebase）— App Links／Universal Linksを案内する現行の廃止通知。
• ディープリンクについて（Android）— App Linksと検証モデル。
• Android App Linksを検証する（Android）— assetlinks.jsonの要件。
• アプリとウェブサイトによるコンテンツへのリンクを許可する（Apple）— Universal Linksとapple-app-site-association。
• Google App Indexing Becomes Firebase App Indexing（Search Engine Land）— Google I/Oでの2016年の改称に関するBarry Schwartzの報道。

引用する価値のある統計

• アプリディープリンクはインデックス登録や順位を変えない — Google自身の2025年5月の記述：“Search continues to use the content of your web pages for indexing and ranking.” (翻訳)「Searchはインデックス登録と順位付けにウェブページのコンテンツを使い続けます」。このテーマで最も重要で、最も誤って伝えられている事実です。 出典
• Firebase App Indexingは廃止 — Firebaseの現行ドキュメントによれば、“the Google Search App for Android no longer uses local content indexed via Firebase App Indexing to provide results to users.” (翻訳)「Android版Google Searchアプリは、Firebase App Indexingでインデックス登録されたローカルコンテンツを結果の提供に使用しなくなりました」。移行は2021年に行われました（2022年10月のアーカイブにはあり、2020年10月にはありません）。 出典
• App LinksはAndroid 6以降でサポート — GoogleはApp Linksを自分のウェブサイトへのディープリンクに対する “a recommended approach” (翻訳)「推奨される方法」とし、/.well-known/assetlinks.jsonのDigital Asset Linksファイルで検証します。 出典

アプリディープリンクQA用のプロンプト

Androidの関連付けデータを確認する

Review this Android intent-filter and assetlinks.json together. Check host/path
coverage, android:autoVerify, package name, relation value, and certificate
fingerprints for internal consistency. Return: definite mismatches, items that require
device verification, affected URL patterns, and exact tests to run. Do not assume an
unshown signing certificate or redirect behavior.

MANIFEST:
[paste]

ASSETLINKS_JSON:
[paste]

コンテンツ同等性テストマトリクスを作成する

Turn this list of web URLs and intended app destinations into a QA matrix. For each
row include web content identity, Android destination, iOS destination, installed-app
behavior, no-app fallback, and a pass/fail content-parity check. Flag rows where the
app screen's content appears different from the web page; do not treat layout changes
as content mismatches.

[paste URL-to-screen mapping]

アプリディープリンクのリリースを検証する

公開された関連付けファイルをテストする

実行するテスト： Cookieや認証なしで、2つのwell-known関連付けエンドポイントを取得し、JSONを検証します。期待する結果： 成功したレスポンスに本番アプリの識別子、フィンガープリント、意図したパスのルールが含まれます。失敗の解釈： デバイスがサイトとアプリの関係を検証できません。監視期間： デプロイ直後と証明書変更後。ロールバックのトリガー： いずれかのファイルがエラーになった、予期せずリダイレクトした、または誤った本番IDを認可した場合。

インストール済みと未インストールの動作をテストする

実行するテスト： 実機のAndroidとiOSで代表的なHTTPSリンクを、アプリがインストールされた状態と、ない状態の両方でタップします。期待する結果： インストール済みユーザーは対応するアプリ画面に到達し、それ以外のユーザーは同じウェブURLに到達します。失敗の解釈： 検証、ルーティング、またはフォールバックの動作が不完全です。監視期間： アプリのリリースごとに直ちに。ロールバックのトリガー： リンクが行き止まりになる、誤った画面を開く、またはウェブへフォールバックできない場合。

コンテンツの同等性をテストする

実行するテスト： 各ウェブ検索結果の検索可能なコンテンツと、アプリのリンク先を比較します。期待する結果： レイアウトが異なっていても、主題と実質的なコンテンツが一致します。失敗の解釈： Searchがウェブページをインデックス登録するため、ディープリンクがユーザーを誤解させる可能性があります。監視期間： ルートをマッピングする前と、コンテンツテンプレートを大きく変更した後。ロールバックのトリガー： アプリのリンク先が、ウェブ検索結果のtitleとスニペットを満たさなくなった場合。

アプリディープリンクの健全性を測定する

Androidアプリの検索での表示

指標： Android Appの検索での表示における表示回数とクリック数。わかること： GoogleがAndroidのディープリンク表示を付けた結果をどの程度表示し、そのうちどの程度のトラフィックが利用したか。取得方法： Search ConsoleのPerformanceで、Android Appの検索での表示に絞り込みます。ベンチマーク／現実的な範囲： クエリとページごとに基準値を作ります。対象になるかどうかはアプリの普及と関連する結果に左右されるため、普遍的な目標はありません。頻度： リリース注記を付けて毎月。

成功したルートオープン率

指標： 有効なディープリンクのオープン数を、アプリリンクの試行数で割った値。わかること： 検証済みリンクがフォールバックやエラーではなく、意図した画面に到達するか。取得方法： 機密性のあるURLパラメーターを除外し、リンク受信とリンク先の描画でアプリ分析イベントを記録します。ベンチマーク／現実的な範囲： 自分のプラットフォームとバージョンの基準値を使い、リリース後に継続する低下を調査します。頻度： 毎週およびアプリのリリースごと。

同等性の例外件数

指標： マッピングしたウェブURLのうち、アプリのリンク先に同等のコンテンツがなくなったもの。わかること： ルーティングが中心要件であるコンテンツの同等性を満たし続けているか。取得方法： 維持しているURLと画面の一覧にリリースQAを組み合わせます。ベンチマーク／現実的な範囲： 既知の例外ゼロが適切な目標です。頻度： 各リリースと、ウェブまたはアプリの情報アーキテクチャを大きく変更した後。

確認テスト：App Indexing

App Indexingとは何だったのか、何に置き換わったのか、SEOに対して実際に何をするのかを問う5つの短い質問です。それぞれ回答を選んでから、確認してください。

変更履歴