Indexation des applications (liens profonds d’application pour la recherche)

TL;DR — « App Indexing » était une ancienne fonctionnalité de Google qui extrayait du contenu de votre application mobile pour l’afficher dans les résultats de recherche. Google l’a arrêtée. Ce que l’on utilise aujourd’hui s’appelle les liens profonds d’application : si l’application est déjà installée, un lien ouvre le résultat de recherche dans l’application plutôt que dans le navigateur du téléphone. L’essentiel : cela ne vous aide pas à mieux vous classer. Google classe toujours votre site Web ; les liens profonds changent seulement la destination du clic.

Ce qu’était « App Indexing »

Il y a plusieurs années, Google permettait de relier votre site à votre application mobile native afin d’afficher le contenu de l’application — et des liens qui y menaient directement — dans les résultats de recherche. Ce système s’appelait App Indexing, puis Firebase App Indexing. Si vous recherchiez quelque chose et que l’application correspondante était installée, Google pouvait vous diriger vers l’application plutôt que vers une page Web.

Si vous lisez ceci parce que vous avez trouvé « App Indexing » dans une ancienne checklist SEO, une documentation de développeur ou un réglage de plugin, la réponse courte est : c’est obsolète. Google l’a désactivé. Vous n’avez pas besoin de le configurer ; si un tutoriel vous le demande, ce tutoriel n’est plus à jour.

Ce qui l’a remplacée

La version moderne de « ouvrir mon application depuis un résultat de recherche » s’appelle les liens profonds d’application, et chaque plateforme leur donne son propre nom :

• Android les appelle App Links.
• iOS les appelle Universal Links.

Les deux ont le même rôle : lorsqu’une personne touche un lien vers votre site — depuis un résultat Google, un autre site ou une application — et que votre application est déjà installée, le téléphone ouvre ce contenu dans l’application. Si l’application n’est pas installée, le même lien s’ouvre simplement dans le navigateur, comme d’habitude.

L’erreur que font la plupart des gens

Les liens profonds d’application ne vous aident pas à vous classer. C’est le mythe à désapprendre. De vieux articles affirment que « l’indexation de votre application » améliore vos classements. Google a déclaré clairement que ce n’est pas le cas : Search utilise toujours le contenu de votre page Web pour décider de votre classement. Les liens profonds ne changent l’expérience qu’après le clic, pour les personnes qui ont votre application. C’est une fonction de confort, pas une astuce de classement.

Si vous les configurez, il existe une règle réelle : l’écran de l’application vers lequel vous dirigez l’utilisateur doit afficher le même contenu que la page Web. Google construit l’extrait à partir de votre page Web ; si l’application affiche autre chose, vous avez induit en erreur la personne qui a cliqué.

Vous voulez l’historique complet, les fichiers et étapes exacts pour Android et iOS, ainsi que la façon de mesurer le résultat dans Search Console ? Passez à l’onglet Advanced.

TL;DR — Google App Indexing (2013) → Firebase App Indexing (2016, avec une courte expérience d’« app streaming ») → obsolète vers ~2021. Son successeur est constitué des liens profonds d’application : Android App Links (vérifiés par un fichier Digital Asset Links situé à /.well-known/assetlinks.json et par des filtres d’intention android:autoVerify) et iOS Universal Links (vérifiés par un fichier apple-app-site-association et l’entitlement Associated Domains). Selon les indications de Google de mai 2025, les liens profonds ne changent ni l’indexation ni le classement — Search classe toujours la page Web — et leur destination doit correspondre au contenu de l’URL Web. Mesurez leur comportement avec les outils de la plateforme et les analyses de l’application, sans supposer l’existence d’un rapport Search Console dédié.

Trois ères, un nom confus

La raison pour laquelle « App Indexing » prête autant à confusion est que la même idée a porté trois noms différents en une décennie, et que la dernière transition était une dépréciation que beaucoup d’anciens contenus n’ont jamais intégrée.

2013–2016 — Google App Indexing. En octobre 2013, Google annonçait que “Googlebot can now index content in your Android app,” (traduction) « Googlebot peut désormais indexer le contenu de votre application Android », et qu’il pouvait afficher des liens profonds vers l’application “straight in our search results when we think they’re relevant… and if the user has the app installed.” (traduction) « directement dans nos résultats de recherche lorsque nous les jugeons pertinents… et si l’utilisateur a installé l’application. » Vous déclariez le contenu de l’application via votre sitemap existant et Webmaster Tools. Google explorait alors à l’intérieur des applications comme il explore les pages Web.

2016–~2021 — Firebase App Indexing. Après l’acquisition de Firebase par Google en 2014, App Indexing a été rebaptisé Firebase App Indexing autour de Google I/O 2016. Le système a ajouté la prise en charge d’iOS et, pendant un temps, une expérience appelée app streaming — un bouton « Try Now » qui permettait d’exécuter dans le navigateur une application non installée pendant quelques minutes, directement depuis un résultat de recherche. App streaming était une expérience limitée de 2015–2016 et a disparu depuis longtemps ; ne construisez rien autour.

~2021–aujourd’hui — obsolète. L’interface AppIndexApi est marquée deprecated dans la documentation de référence Android de Google. La documentation Firebase en ligne indique désormais que “Firebase App Indexing is no longer the recommended way of indexing content for display as suggested results in Google Search App,” (traduction) « Firebase App Indexing n’est plus la méthode recommandée pour indexer du contenu destiné à être affiché comme résultats suggérés dans Google Search App. » La mise en garde explicite ajoute que “the Google Search App for Android no longer uses local content indexed via Firebase App Indexing to provide results to users.” (traduction) « l’application Google Search pour Android n’utilise plus le contenu local indexé par Firebase App Indexing pour fournir des résultats aux utilisateurs. » Firebase vous oriente maintenant vers App Links et Universal Links. (Le basculement a eu lieu en 2021 : l’avis de dépréciation apparaît dans une archive d’octobre 2022, mais pas dans celle d’octobre 2020.)

Ce qui a remplacé App Indexing : les liens profonds d’application

Les liens profonds sont, selon Google, “special URIs that take users beyond your mobile app’s homepage, leading them directly to specific in-app content.” (traduction) « URI spéciales qui emmènent les utilisateurs au-delà de l’accueil de votre application mobile, directement vers un contenu précis dans l’application. » Le changement mental essentiel par rapport à l’ancien modèle est le suivant : il s’agit de vérification et de routage, gérés au niveau du système d’exploitation et du navigateur — pas d’un pipeline d’indexation géré par Google. Rien ici n’est « envoyé dans un index ».

Android App Links (Digital Asset Links / assetlinks.json)

Les Android App Links sont, selon Google, “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.” (traduction) « une capacité avancée de liens profonds qui vérifie les liens profonds vers votre propre site en établissant une association de confiance entre votre application et votre site. Une fois vérifiés, les liens profonds vers votre site peuvent ouvrir immédiatement le contenu correspondant dans votre application, sans demander à l’utilisateur de sélectionner votre application dans une boîte de dialogue de désambiguïsation. » App Links est pris en charge à partir d’Android 6, et Google le qualifie d’« approche recommandée » pour les liens profonds vers votre propre site.

La poignée de main de vérification repose sur un fichier Digital Asset Links. Lorsque vous ajoutez android:autoVerify="true" à un filtre d’intention et que l’application est installée, “Android queries the corresponding websites for the Digital Asset Links file at https://hostname/.well-known/assetlinks.json.” (traduction) « Android interroge les sites correspondants pour trouver le fichier Digital Asset Links à l’adresse indiquée. » Ce fichier JSON liste le paquet de l’application et l’empreinte du certificat de signature autorisés à gérer les liens de votre domaine. Android 15 ajoute les Dynamic App Links, qui permettent d’affiner le comportement de correspondance des URL sans publier une nouvelle version de l’application.

Deux limites de version et de signature comptent ici. Premièrement, les Dynamic App Links étendent l’association sous-jacente du manifeste au lieu de la remplacer : sur les versions d’Android antérieures à 15, la vérification repose toujours uniquement sur la correspondance standard manifeste/assetlinks.json. Deuxièmement, la vérification échoue entièrement, et non partiellement, si l’empreinte du certificat de signature listée dans assetlinks.json ne correspond pas exactement à l’identité de signature du build installé : un build de débogage signé avec une autre clé que celle de l’entrée assetlinks.json ne sera jamais vérifié, même si tous les autres champs sont corrects.

La distinction à garder en tête est simple : un lien profond Android de base utilise des filtres d’intention, mais peut afficher la boîte de dialogue « avec quelle application voulez-vous ouvrir ce lien ? ». Les App Links ajoutent la vérification Digital Asset Links afin qu’un domaine vérifié s’ouvre directement dans votre application, sans dialogue.

iOS Universal Links (apple-app-site-association)

L’équivalent Apple est Universal Links. Apple explique : “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.” (traduction) « Lorsque les utilisateurs touchent ou cliquent sur un lien universel, le système redirige directement le lien vers votre application sans passer par le navigateur Web par défaut de la personne ni par votre site… comme les liens universels sont des liens HTTP ou HTTPS standard, une seule URL fonctionne pour votre site et votre application. Si la personne n’a pas installé votre application, le système ouvre l’URL dans son navigateur Web par défaut. »

Le fichier de vérification est ici apple-app-site-association, hébergé sur votre serveur Web : “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.” (traduction) « Lorsqu’une personne installe votre application, le système vérifie un fichier stocké sur votre serveur Web pour confirmer que votre site autorise votre application à ouvrir des URL en son nom. » Côté application, vous devez ajouter l’entitlement Associated Domains correspondant aux domaines du fichier. Le principe est le même que sur Android : une poignée de main de confiance entre le site et l’application, vérifiée par l’appareil, et non un signal de classement.

Un fichier apple-app-site-association valide et un entitlement correctement correspondant ne garantissent toutefois pas que chaque clic ouvrira l’application. Apple documente des cas réels où un Universal Link ouvre quand même Safari malgré une association fonctionnelle — par exemple lorsque le lien est touché dans Safari alors que la personne consulte déjà le même domaine, ou lorsqu’elle a précédemment choisi de continuer à ouvrir les liens de ce domaine dans le navigateur. Et si l’application n’est réellement pas installée, ou si l’association ne correspond pas, un lien HTTP(S) standard doit s’ouvrir dans le navigateur plutôt que d’échouer sur un schéma personnalisé inopérant : ce repli est le fonctionnement prévu du système, pas un bug à traquer.

Les deux plateformes sont prises en charge par Google Search comme cibles de liens profonds.

Les liens profonds d’application influencent-ils les classements ? (Non — citation exacte)

C’est la correction la plus importante de tout ce sujet, car des pages de classement continuent de se tromper. Vous trouverez des articles affirmant que “App Indexing will influence ranking… whether or not the user has your app installed” (traduction) « App Indexing influencera le classement… que l’utilisateur ait ou non votre application installée » ou que “Google will use the content within your app as a signal in ranking.” (traduction) « Google utilisera le contenu de votre application comme signal de classement. » Ces affirmations sont fausses, et le billet de Google de mai 2025 le dit directement :

“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.” (traduction) « Ajouter des liens profonds à votre site relie les URL du site aux pages correspondantes de l’application. Cela ne change pas la manière dont Google Search affiche votre contenu ; Search continue d’utiliser le contenu de vos pages Web pour l’indexation et le classement. Les liens profonds permettent aux utilisateurs de passer directement des résultats Search à la page correspondante de l’application, si elle est installée, ce qui améliore l’expérience utilisateur. »

Lisez attentivement : c’est la page Web qui est indexée et classée. Le lien profond est une couche de routage après le clic qui ne s’active que pour les utilisateurs ayant déjà l’application. C’est une amélioration de l’expérience, pas un levier de visibilité. Si quelqu’un vous dit que configurer assetlinks.json fera monter vos classements, il se trompe.

L’exigence réelle : la parité du contenu

Il existe exactement une règle substantielle, et elle concerne l’honnêteté envers l’utilisateur. Google dit :

“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.” (traduction) « Comme Search utilise le contenu de votre page Web pour l’indexation et le classement, vous ne devriez ajouter des liens profonds que lorsque la page de l’application contient le même contenu que la page Web correspondante. Sinon, le titre et l’extrait affichés pour la page dans Google Search pourraient induire les utilisateurs en erreur sur le contenu qu’ils verront après leur clic. Les différences de mise en page ou d’expérience entre les pages de l’application et les pages Web correspondantes sont acceptables, tant que le contenu correspond. »

Ainsi, un écran natif plus élégant, avec une mise en page différente, convient parfaitement. Un écran qui affiche un contenu différent de la page Web ne convient pas : l’extrait touché par l’utilisateur venait de la page Web, et l’utilisateur arrive maintenant quelque part qui ne correspond pas. La parité concerne le contenu, pas l’apparence.

Comment l’implémenter aujourd’hui

Android : utilisez App Links. Associez votre application à votre site dans le manifeste (filtres d’intention avec android:autoVerify="true"), puis publiez /.well-known/assetlinks.json sur votre site en y listant le nom du paquet et l’empreinte du certificat de signature de l’application. Android vérifie l’association lors de l’installation. L’App Links Assistant d’Android Studio et la page Deep Links de la Play Console vous aident à générer et valider la configuration.

iOS : implémentez Universal Links. Publiez un fichier apple-app-site-association sur votre serveur Web pour décrire les chemins associés à l’application, puis ajoutez l’entitlement Associated Domains pour les domaines correspondants. Le guide de débogage Universal Links d’Apple présente les problèmes courants : mauvais type de contenu, entitlement manquant ou association mise en cache.

Aucun des deux fichiers n’est exploré comme un « index de recherche » au sens d’App Indexing : ce sont des poignées de main de confiance vérifiées par l’appareil. Si elles sont incorrectes, les liens reviennent simplement au navigateur ; si elles sont correctes, les utilisateurs ayant l’application sont dirigés vers celle-ci.

Contrôle minimal des fichiers d’association

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

Les deux endpoints doivent renvoyer 200, sans redirection, et exposer la réponse JSON attendue. La lens Scripts contient les contrôles détaillés du type de contenu, des redirections, de PowerShell, de DevTools et du bookmarklet.

Comment le mesurer : le filtre d’application Android de Search Console

Google expose nativement les performances des liens profonds d’application : « 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. » (traduction) « Search Console inclut les performances des liens profonds Android de votre site. Dans le rapport Performances, vous pouvez utiliser le filtre d’apparence Search Android App pour voir quand vos liens profonds Android sont trouvés et affichés aux utilisateurs. » Cela fournit les clics, les impressions, le CTR et la position pour les résultats où le lien profond Android est apparu — le moyen actuel de vérifier concrètement si le mécanisme produit quelque chose. (Ce filtre a été ajouté en 2019 ; il reste l’outil actuel selon le billet de Google de 2025.)

Gardez toutefois les deux tâches séparées. Le filtre Search Console est un rapport de trafic et d’apparition — limité à Android, dépendant du fait que Google affiche réellement le traitement par lien profond pour une requête donnée, et ne prouvant pas à lui seul qu’un contenu est indexé ou classé. Confirmer qu’un lien profond fonctionne techniquement est un autre exercice : récupérez les fichiers d’association et testez le parcours après clic sur de vrais appareils (voir les lenses Scripts et Validation Tests). Ne prenez pas un rapport Search Console silencieux comme preuve que votre configuration est défaillante, et ne prenez pas les clics du rapport pour un signal SEO : ils indiquent un volume de routage, pas un classement.

Bing et les liens profonds d’application

Ne supposez pas que Google et Bing se comportent de la même manière. Bing avait lancé en avril 2014 un programme de « app linking » centré sur Windows, destiné à Windows 8,1 et Windows Phone — mais ces pages sont désormais mortes (l’URL développeur renvoie 404, les articles de blog redirigent vers la page d’accueil générique), et Windows Phone a lui-même été abandonné. Il n’existe pas d’équivalent actuel publié par Bing aux recommandations Google de 2025 sur les liens profonds. En pratique, App Links et Universal Links fonctionnent toujours dans Bing/Edge sur mobile, car ce sont des standards du système d’exploitation et du navigateur, pas une capacité à laquelle un moteur de recherche doit choisir d’adhérer : implémentez-les de la même façon. Il n’existe simplement aucune documentation Bing à citer.

Les anciennes techniques que vous verrez encore

Quelques techniques voisines créent de la confusion ; nommez-les puis passez à autre chose :

• Le balisage schema.org potentialAction / ViewAction avec une cible de lien profond android-app://. C’est une technique héritée de l’époque App Indexing. Vous la trouverez encore dans des bases de code et dans le vocabulaire des actions de schema.org, mais la recommandation actuelle de Google est la configuration App Links / Universal Links, pas ce balisage. Traitez-le comme « vous pouvez encore le voir », pas comme une recommandation.
• Firebase Dynamic Links est un autre produit Firebase, distinct et lui aussi obsolète — un service de raccourcissement d’URL et de liens profonds différés pour l’attribution marketing, pas le système d’indexation de contenu App Indexing. Il est également retiré progressivement, et ses propres conseils de migration renvoient à App Links et Universal Links. Ne confondez pas ces deux dépréciations.

Le modèle à retenir est net : (1) l’ancien système d’exploration et de diffusion Google App Indexing / Firebase App Indexing = mort ; (2) les liens profonds App Links / Universal Links = actuels, réservés au routage et à l’UX, sans effet de classement ; (3) l’ancien programme de liens Bing de l’ère Windows = également mort, sans remplacement documenté.

Résumé IA

Voici une synthèse de la version Advanced :

• App Indexing est obsolète. Google App Indexing (2013) → Firebase App Indexing (2016) → obsolète vers 2021. AppIndexApi est marqué deprecated dans la documentation de Google ; l’application Google Search n’utilise plus le contenu Firebase App Indexing.
• Ce qui l’a remplacé : les liens profonds d’application — Android App Links (vérifiés par un fichier Digital Asset Links à /.well-known/assetlinks.json et des filtres d’intention android:autoVerify) et iOS Universal Links (vérifiés par apple-app-site-association et l’entitlement Associated Domains). Il s’agit de vérification et de routage au niveau du système et du navigateur, pas d’un index géré par Google.
• Les liens profonds ne modifient PAS le classement. Selon le billet Google de mai 2025 : ils « ne changent pas la manière dont Google Search affiche votre contenu ; Search continue d’utiliser le contenu de vos pages Web pour l’indexation et le classement ». Ils dirigent simplement les utilisateurs ayant installé l’application vers celle-ci après un clic.
• La seule règle réelle est la parité du contenu : ne créez un lien profond que vers un écran d’application qui affiche le même contenu que la page Web (les différences de mise en page et d’UX sont acceptables).
• Mesurez le résultat avec le filtre d’apparence Search Android app de Search Console — mais ce n’est qu’un rapport de trafic, pas une preuve que l’association technique fonctionne ou qu’un contenu est mieux classé ; vérifiez l’association elle-même sur l’appareil et dans les fichiers.
• Aucune plateforme ne garantit que chaque clic vérifié ouvre l’application. Android échoue entièrement lorsque le certificat de signature ne correspond pas (les Dynamic App Links sur Android 15 étendent le manifeste sans le remplacer) ; iOS documente des cas légitimes — navigation Safari sur le même domaine et choix antérieur de l’utilisateur — où un Universal Link ouvre encore le navigateur malgré une association valide.
• Bing n’a pas de recommandation équivalente actuelle ; son programme de l’ère Windows est mort, mais App Links et Universal Links continuent de fonctionner dans Edge car ce sont des standards OS.
• Ne confondez pas App Indexing avec Firebase Dynamic Links (produit distinct et lui aussi obsolète), ni le balisage potentialAction/ViewAction avec une bonne pratique actuelle.

Documentation officielle

Documentation primaire de Google, Android et Apple.

Google — recommandations actuelles

• Liens profonds d’application : relier votre site et votre application (2 mai 2025) — explication de référence : rôle des liens profonds, absence d’effet sur le classement, parité de contenu et filtre Search Console.
• Firebase App Indexing — page actuelle contenant l’avis de dépréciation et le renvoi vers App Links / Universal Links.

Google — historique (pour comprendre ce qui est obsolète)

• Indexer les applications comme les sites Web (31 octobre 2013) — annonce originale d’App Indexing.

Android

• À propos des liens profonds — liens profonds, App Links et modèle de vérification (mis à jour le 18 juin 2026).
• Vérifier les Android App Links — android:autoVerify et l’exigence Digital Asset Links / assetlinks.json.

Apple

• Autoriser les applications et les sites Web à créer des liens vers votre contenu — présentation des Universal Links et modèle de vérification du fichier serveur.
• Prendre en charge les domaines associés — fichier apple-app-site-association et entitlement Associated Domains.

Standard du secteur (pas propre à Google)

• ViewAction / Actions (schema.org) — vocabulaire historique potentialAction/ViewAction ; contexte utile, mais pas une recommandation actuelle de Google.

Citations des sources

Déclarations officielles de Google, Android et Apple. Chaque lien Google/Android est un lien profond qui renvoie directement au passage cité sur la page source.

Google — annonce originale d’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.” (traduction) « Tout comme il explore et indexe les sites Web, Googlebot peut désormais indexer le contenu de votre application Android… Si la page Web et le contenu de l’application sont indexés avec succès, Google essaiera alors d’afficher des liens profonds vers votre application directement dans nos résultats de recherche lorsque nous les jugeons pertinents pour la requête de l’utilisateur et si celui-ci a installé l’application. » — Lawrence Chang, Product Manager, Google. Aller à la citation

Google — Firebase App Indexing est obsolète (documentation actuelle)

• “Firebase App Indexing is no longer the recommended way of indexing content for display as suggested results in Google Search App.” (traduction) « Firebase App Indexing n’est plus la méthode recommandée pour indexer du contenu destiné à être affiché comme résultats suggérés dans Google Search App. » Aller à la citation

Google — les liens profonds ne changent pas le classement (mai 2025)

• “It doesn’t change how Google Search shows your content; Search continues to use the content of your web pages for indexing and ranking.” (traduction) « Cela ne change pas la manière dont Google Search affiche votre contenu ; Search continue d’utiliser le contenu de vos pages Web pour l’indexation et le classement. » — John Mueller (Google Search Relations) et Sabs (Android Developer Relations). Aller à la citation
• “You should only add deep links in cases where the app page contains the same content as the corresponding web page.” (traduction) « Vous ne devriez ajouter des liens profonds que lorsque la page de l’application contient le même contenu que la page Web correspondante. » Aller à la citation

Android — App Links et fichier de vérification

• “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.” (traduction) « Android App Links est une capacité avancée de liens profonds qui vérifie les liens profonds vers votre propre site en établissant une association de confiance entre votre application et votre site. » — Android Developers. Aller à la citation
• “Android queries the corresponding websites for the Digital Asset Links file at https://hostname/.well-known/assetlinks.json.” (traduction) « Android interroge les sites correspondants pour trouver le fichier Digital Asset Links à l’adresse indiquée. » Aller à la citation

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.” (traduction) « Lorsque les utilisateurs touchent ou cliquent sur un lien universel, le système redirige directement le lien vers votre application sans passer par le navigateur Web par défaut de la personne ni par votre site… Si la personne n’a pas installé votre application, le système ouvre l’URL dans son navigateur Web par défaut. » — Documentation développeur Apple, « Autoriser les applications et les sites Web à créer des liens vers votre contenu ».

Faut-il configurer des liens profonds d’application ?

Un parcours rapide pour répondre à « en ai-je vraiment besoin ? » — car, pour beaucoup de sites, la réponse honnête est « non ».

1. Avez-vous une application mobile native qui reproduit le contenu de votre site ?

• Pas d’application → Arrêtez-vous. Il n’y a rien vers quoi créer un lien profond. App Indexing / les liens profonds ne vous concernent pas. (Et si vous avez trouvé « App Indexing » dans une checklist, supprimez cette ligne : c’est obsolète.)
• Oui → continuez.

2. Faites-vous cela pour les classements ?

• Oui → Arrêtez-vous et relisez. Les liens profonds n’affectent ni l’indexation ni le classement. Si la visibilité SEO est l’objectif, investissez dans votre page Web mobile, pas dans le câblage des liens profonds.
• Non — je veux diriger vers l’application les utilisateurs qui l’ont installée → continuez.

3. L’écran de l’application affiche-t-il le même contenu que la page Web correspondante ?

• Non (contenu différent) → Ne créez pas de lien profond vers cette URL. Une différence induit l’utilisateur en erreur, car l’extrait venait de la page Web. Corrigez la parité d’abord (les différences de mise en page et d’UX sont acceptables ; les différences de contenu ne le sont pas).
• Oui → continuez.

4. Quelle(s) plateforme(s) ?

• Android → App Links : filtres d’intention android:autoVerify + fichier Digital Asset Links à /.well-known/assetlinks.json.
• iOS → Universal Links : apple-app-site-association sur votre serveur + entitlement Associated Domains.
• Les deux → faites les deux ; ils sont indépendants.

5. Comment saurez-vous que cela fonctionne ?

• Consultez le filtre d’apparence Search Android app de Search Console pour Android.
• Testez le parcours après clic sur de vrais appareils et validez les fichiers d’association (App Links Assistant sur Android ; débogage Universal Links d’Apple sur iOS).

Règle pratique : les liens profonds sont une amélioration de l’UX et du routage pour les sites qui ont une vraie application dont le contenu correspond — pas un projet de classement SEO et pas quelque chose à ajouter uniquement parce qu’un ancien guide mentionnait « App Indexing ».

Checklist de configuration des liens profonds d’application

Pertinente uniquement si vous avez une application native qui reproduit le contenu de votre site :

• Vous avez confirmé que vous n’attendez pas de hausse de classement — les liens profonds changent le routage, pas le classement.
• Parité du contenu vérifiée : chaque écran d’application lié en profondeur affiche le même contenu que sa page Web correspondante (les différences de mise en page et d’UX sont acceptables).
• Android : les filtres d’intention utilisent android:autoVerify="true" pour votre domaine.
• Android : /.well-known/assetlinks.json est publié sur HTTPS avec le bon type de contenu et contient le nom du paquet de l’application et l’empreinte du certificat de signature.
• iOS : apple-app-site-association est publié sur votre serveur (bon type de contenu, sans redirection) avec les bons motifs de chemin.
• iOS : l’entitlement Associated Domains est ajouté à l’application et correspond aux domaines du fichier d’association.
• Vous avez testé de vrais parcours après clic sur des appareils Android et iOS physiques, avec et sans application installée.
• Le filtre d’apparence Search Android app de Search Console est consulté pour les impressions et clics une fois la fonctionnalité en production.
• Vous avez supprimé les références obsolètes — balises sitemap App Indexing, appels au SDK Firebase App Indexing ou balisage potentialAction/android-app:// utilisé comme mécanisme principal.

Anti-patterns à éviter

• Traiter App Indexing comme une technologie actuelle. AppIndexApi est deprecated et l’application Google Search n’utilise plus le contenu Firebase App Indexing. Si un guide, un plugin ou une checklist vous demande d’« activer App Indexing », il n’est plus à jour.
• S’attendre à un gain de classement. Le mythe le plus répandu dans les anciennes pages de classement est que « l’indexation de l’application influence le classement ». Google dit le contraire : Search classe la page Web ; les liens profonds ne changent rien à cela.
• Créer un lien profond vers un contenu différent. Envoyer quelqu’un qui a touché l’extrait d’une page Web vers un écran d’application au contenu différent. Google avertit explicitement que cela induit les utilisateurs en erreur. La parité concerne le contenu, pas l’apparence.
• Poursuivre l’app streaming. L’aperçu « Try Now » d’une application non installée était une expérience de 2015–2016 et a disparu. Ne construisez rien autour.
• Confondre Firebase App Indexing et Firebase Dynamic Links. Ce sont deux produits différents, tous deux obsolètes, qui résolvaient des problèmes distincts (indexation de contenu contre raccourcissement d’URL et attribution). Tous deux renvoient maintenant vers App Links / Universal Links.
• Supposer la parité avec Bing. L’ancien programme de liens d’application de Bing pour Windows est mort et n’a pas de remplacement documenté. App Links et Universal Links fonctionnent toujours dans Edge parce que ce sont des standards du système d’exploitation, mais il n’existe aucune documentation Bing à suivre.
• Sauter la vérification puis se demander pourquoi cela « ne fonctionne pas ». Un mauvais type de contenu, une redirection du fichier d’association ou un entitlement manquant vous renvoie silencieusement au navigateur. Les fichiers forment une poignée de main stricte, pas une suggestion.

Échecs courants des liens profonds d’application

Un lien Web s’ouvre encore dans le navigateur sur Android

Symptôme : une application installée ne revendique pas une URL HTTPS correspondante. Cause probable : la vérification du domaine a échoué parce que l’hôte du manifeste, le nom du paquet, l’empreinte du certificat de signature ou la réponse assetlinks.json ne correspond pas. À faire : vérifiez l’identité de signature du build installé, récupérez directement le fichier d’association et relancez la vérification des liens Android avant de tester à nouveau le clic.

Un Universal Link ouvre Safari au lieu de l’application iOS

Symptôme : la même URL HTTPS fonctionne sur le Web mais contourne l’application installée. Cause probable : l’entitlement Associated Domains ou les chemins de apple-app-site-association n’autorisent pas l’URL — mais vérifiez d’abord les cas documentés qui ne sont pas des pannes : Apple décrit les liens touchés dans Safari sur le même domaine, ou un domaine que la personne a précédemment choisi de continuer à ouvrir dans le navigateur, comme des ouvertures normales dans le navigateur et non comme des échecs de vérification. À faire : confirmez l’entitlement du domaine, la disponibilité du fichier et les règles de chemin, puis retestez après réinstallation ou actualisation de l’état d’association de l’appareil — en écartant le comportement du même domaine ou le choix antérieur de l’utilisateur avant de conclure que l’association est cassée.

L’application ouvre le mauvais écran

Symptôme : la vérification réussit mais l’application arrive sur une page d’accueil ou un contenu qui ne correspond pas. Cause probable : l’association du système est correcte, mais le mappage des routes de l’application est incomplet. À faire : mappez le chemin entrant et ses paramètres vers l’écran correspondant, conservez un repli Web sûr et comparez le contenu de l’application à la page Web qui a fourni l’extrait de recherche.

Liens profonds d’application — fiche mémo

Avant et maintenant

Fichiers de vérification

Faits rapides

• Les liens profonds changent le routage après un clic, pas l’indexation ni le classement.
• Créez des liens profonds uniquement vers des écrans dont le contenu correspond à la page Web.
• Android nécessite des filtres d’intention android:autoVerify="true".
• iOS nécessite l’entitlement Associated Domains.
• Mesurez avec le filtre d’apparence Search Android app de GSC.
• Bing : aucune recommandation équivalente actuelle ; les standards fonctionnent toujours dans Edge.

Vérifier vos fichiers d’association

Les liens profonds échouent silencieusement ; l’étape de débogage la plus rapide consiste donc à confirmer que les deux fichiers de vérification existent, renvoient 200 et servent le bon type de contenu.

macOS / Linux — récupérer et inspecter les fichiers

# 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

Console Browser DevTools — contrôle rapide de disponibilité

// 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"));
  });

Bookmarklet — contrôle en un clic sur le site actuel

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);}}})();

Si un fichier renvoie 404s, redirige ou sert un mauvais type de contenu, le système d’exploitation ne vérifiera pas l’association et les liens reviendront discrètement au navigateur au lieu d’ouvrir l’application.

Outils pour configurer et déboguer les liens profonds

• Android Studio — App Links Assistant — génère les filtres d’intention, crée et valide vos Digital Asset Links (assetlinks.json) et teste la gestion des liens.
• Google Play Console — page Deep Links — expose l’état de vos liens profonds et de leur vérification.
• Validation Digital Asset Links — vérifiez que votre assetlinks.json publié associe correctement votre domaine au paquet et à l’empreinte de votre application.
• Débogage Apple Universal Links — documentation Apple pour diagnostiquer l’ouverture d’un Universal Link dans le navigateur plutôt que dans l’application (type du fichier, entitlement, cache).
• Google Search Console — rapport Performances — le filtre d’apparence Search Android app affiche les impressions, clics, CTR et positions des résultats où votre lien profond Android est apparu.
• curl / DevTools / bookmarklet — premier contrôle le plus rapide pour vérifier que les deux fichiers d’association renvoient 200, le bon type de contenu et aucune redirection (voir Scripts).

Ressources utiles

Mes articles

• L’indexation mobile-first devient mobile-only — concept voisin mais distinct : quelle version de votre page Google indexe (ne le confondez pas avec les liens profonds d’application).
• Guide du débutant sur le SEO technique — place des sujets mobiles et liés aux applications dans le paysage plus large de l’exploration, de l’indexation et du classement.

Mes conférences

• How Search Works (SlideShare) — mon parcours de l’exploration, du rendu, de l’indexation et du classement, notamment la façon dont Googlebot explore comme un smartphone. (Avertissement permanent : « This is my understanding of systems… not going to be 100% complete or accurate. » (traduction) « C’est ma compréhension des systèmes… elle ne sera pas complète ou exacte à 100 %. »)

Dans le secteur

• Liens profonds d’application : relier votre site et votre application (Google) — recommandations actuelles et source des déclarations sur l’absence d’effet de classement et la parité de contenu.
• Firebase App Indexing (Google/Firebase) — avis de dépréciation actuel renvoyant vers App Links / Universal Links.
• À propos des liens profonds (Android) — App Links et modèle de vérification.
• Vérifier les Android App Links (Android) — exigence assetlinks.json.
• Autoriser les applications et les sites Web à créer des liens vers votre contenu (Apple) — Universal Links et apple-app-site-association.
• Google App Indexing devient Firebase App Indexing (Search Engine Land) — article de Barry Schwartz sur le rebranding de 2016 lors de Google I/O.

Statistiques à citer

• Les liens profonds d’application ne changent ni l’indexation ni le classement — déclaration de Google en mai 2025 : Search « continue d’utiliser le contenu de vos pages Web pour l’indexation et le classement ». Le fait le plus important et le plus souvent mal rapporté de ce sujet. Source
• Firebase App Indexing est obsolète — l’application Google Search pour Android « no longer uses local content indexed via Firebase App Indexing » (traduction) « n’utilise plus le contenu local indexé via Firebase App Indexing », selon la documentation Firebase actuelle. La transition a eu lieu en 2021 (présente dans une archive d’octobre 2022, absente d’octobre 2020). Source
• App Links est pris en charge à partir d’Android 6 — Google qualifie App Links d’« approche recommandée » pour les liens profonds vers votre site, vérifiés par le fichier Digital Asset Links situé à /.well-known/assetlinks.json. Source

Prompts pour l’assurance qualité des liens profonds d’application

Examiner les données d’association 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]

Construire une matrice de test de parité du contenu

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]

Valider une mise en production de liens profonds

Tester les fichiers d’association publics

Test à exécuter : récupérez les deux endpoints d’association bien connus sans cookies ni authentification et validez leur JSON. Résultat attendu : les réponses réussies contiennent les identifiants de production de l’application, les empreintes et les règles de chemin prévues. Interprétation d’un échec : les appareils ne peuvent pas vérifier la relation site-application. Fenêtre de surveillance : immédiatement après le déploiement et après chaque changement de certificat. Déclencheur de retour arrière : l’un ou l’autre fichier échoue, redirige de manière inattendue ou autorise une mauvaise identité de production.

Tester les comportements avec et sans application installée

Test à exécuter : touchez des liens HTTPS représentatifs sur de vrais appareils Android et iOS, avec l’application installée puis sans elle. Résultat attendu : les utilisateurs installés atteignent l’écran correspondant ; les autres atteignent la même URL Web. Interprétation d’un échec : la vérification, le routage ou le repli est incomplet. Fenêtre de surveillance : immédiatement pour chaque version de l’application. Déclencheur de retour arrière : les liens échouent, ouvrent le mauvais écran ou ne peuvent pas revenir au Web.

Tester la parité du contenu

Test à exécuter : comparez le contenu explorable de chaque résultat Web à sa destination dans l’application. Résultat attendu : le sujet et le contenu substantiel correspondent, même si la mise en page diffère. Interprétation d’un échec : le lien profond peut induire l’utilisateur en erreur, car Search indexe la page Web. Fenêtre de surveillance : avant d’associer une route et après les changements importants de modèle de contenu. Déclencheur de retour arrière : la destination ne remplit plus le titre et l’extrait du résultat Web.

Mesurer la santé des liens profonds d’application

Apparition de l’application Android dans Search

Métrique : impressions et clics pour l’apparition Android App. Ce qu’elle indique : la fréquence à laquelle Google a affiché des résultats avec un traitement de lien profond Android et le volume de trafic qui les a utilisés. Comment l’extraire : Performances de Search Console, filtrées sur l’apparition Android App. Référence / plage réaliste : établissez une base par requête et par page ; l’éligibilité dépend de l’adoption de l’application et de la pertinence des résultats, il n’existe donc pas de cible universelle. Cadence : mensuelle, avec annotations de version.

Taux d’ouverture de route réussie

Métrique : ouvertures de liens profonds valides divisées par les tentatives de liens d’application. Ce qu’elle indique : si les liens vérifiés atteignent l’écran prévu plutôt qu’un repli ou une erreur. Comment l’extraire : événements d’analyse de l’application lors de la réception du lien et du rendu de destination, en excluant les paramètres d’URL sensibles. Référence / plage réaliste : utilisez votre base de référence de plateforme et de version ; recherchez une régression persistante après une version. Cadence : chaque semaine et à chaque version de l’application.

Nombre d’exceptions de parité

Métrique : URL Web mappées dont la destination applicative ne contient plus un contenu équivalent. Ce qu’elle indique : si le routage respecte encore l’exigence centrale de parité du contenu. Comment l’extraire : inventaire URL-écran maintenu et assurance qualité à chaque version. Référence / plage réaliste : zéro exception connue est la cible appropriée. Cadence : à chaque version et après les changements importants de contenu ou d’architecture de l’information Web.

Testez vos connaissances : App Indexing

Cinq questions rapides sur ce qu’était App Indexing, ce qui l’a remplacé et son fonctionnement SEO réel. Choisissez une réponse à chaque fois, puis vérifiez.

Journal des modifications