結論：最低でも「iPhone + Safari」「Android + Chrome」「主要SNS内ブラウザ」「対象アプリあり/なし」を分けます。Universal Links/App Linksは各OSの公式検証方法も使います。
最初に元のHTTPS URLを確認する
変換後リンクだけをテストせず、元URLが目的ページを開くことを先に確認します。元URLが削除済み、ログイン必須、地域制限、短縮URLの解決失敗などであればdeep link側だけ直しても解決しません。
iPhoneのUniversal Links
AppleのTN3155では、リンクをメモなどへ貼り付けて長押しし、アプリで開く/Safariで開く選択肢を確認する方法が案内されています。SafariのアドレスバーへURLを直接入力する操作はUniversal Linkの通常タップテストにはなりません。
Android App Links
Android DevelopersはApp Linksの検証・テスト手順を公開しています。対象host、intent filter、assetlinks.json、検証状態を確認し、必要に応じてADBやAndroid StudioのApp Linksツールを使います。
QRコードで実端末へ渡す
PC上で用意したURLをスマートフォンへ渡すにはQRコードが便利です。Google Adsのdeep-link validatorでも、実端末確認のためQRコードを使う流れが案内されています。
QRコード自体がdeep linkを改善するわけではありません。入力されているURLが同じなら、QRは「別端末へ簡単に渡す手段」です。
アプリあり/なしを両方試す
| 状態 | 確認すること |
|---|---|
| 対象アプリあり | 目的画面へ到達するか、ホーム画面へ落ちないか。 |
| 対象アプリなし | Web、ストア、エラーのどこへ進むか。 |
| ログアウト | ログイン後も目的コンテンツへ到達できるか。 |
| SNS内ブラウザ | 外部アプリ遷移が通常ブラウザと違わないか。 |
サービス別schemeは更新後に再テストする
第三者アプリ向けのcustom schemeやIntentは、対象アプリのアップデートで挙動が変わる可能性があります。公開時だけでなく、主要アプリ/OS更新後にも代表リンクを再確認する運用が必要です。
公開前チェックリスト
- 元HTTPS URL。
- iPhone + Safari。
- Android + Chrome。
- 主要SNS内ブラウザ。
- 対象アプリ未導入。
- 対象アプリ導入済み。
- Web fallback。
- 目的画面が正しい。
- 短縮/redirectを使う場合は最終URL。