Deep linking delle app per la ricerca (App Indexing)

TL;DR — «App Indexing» era una vecchia funzione di Google che estraeva contenuti dalla tua app mobile e li mostrava nei risultati di ricerca. Google l’ha dismessa. Oggi si parla di deep link delle app: se hai già installato un’app, un risultato di ricerca può aprirsi nell’app invece che nel browser del telefono. La cosa importante è che non aiuta il ranking. Google continua a posizionare il tuo sito; i deep link cambiano solo la destinazione dopo il tap.

Che cos’era «App Indexing»

Anni fa Google permetteva di collegare il sito web alla tua app mobile nativa, così da mostrare nei risultati di ricerca i contenuti dell’app e link diretti al suo interno. Il sistema si chiamava App Indexing (poi Firebase App Indexing). Se cercavi qualcosa e avevi installato l’app corrispondente, Google poteva portarti nell’app invece che in una pagina web.

Se stai leggendo perché hai trovato «App Indexing» in una vecchia checklist SEO, in una documentazione per sviluppatori o nelle impostazioni di un plugin, la risposta breve è: è deprecato. Google l’ha disattivato. Non devi configurarlo e, se un tutorial te lo chiede, quel tutorial è obsoleto.

Che cosa lo ha sostituito

La versione moderna di «apri la mia app da un risultato di ricerca» si chiama deep link delle app e ogni piattaforma ha il proprio nome:

• Android li chiama App Links.
• iOS li chiama Universal Links.

Entrambi svolgono lo stesso compito: quando qualcuno tocca un link al tuo sito, da un risultato Google, da un altro sito o da un’app, e ha già installato la tua app, il telefono apre quel contenuto nell’app. Se l’app non è installata, lo stesso link si apre normalmente nel browser.

L’errore più comune

I deep link delle app non aiutano il ranking. È il mito da disimparare. Gli articoli più vecchi sostengono che «indicizzare la tua app» aumenti il posizionamento. Google ha detto chiaramente il contrario: la Ricerca usa ancora i contenuti della pagina web per decidere il ranking. I deep link cambiano solo l’esperienza dopo il clic, per chi ha l’app. Sono una funzione di comodità, non un trucco per il ranking.

C’è una regola sostanziale se li configuri: la schermata dell’app a cui rimandi deve mostrare lo stesso contenuto della pagina web. Google costruisce lo snippet dalla pagina web; se l’app mostra qualcosa di diverso, hai ingannato la persona che ha toccato il risultato.

Vuoi la storia completa, i file e i passaggi esatti per Android e iOS e le modalità di misurazione in Search Console? Passa alla scheda Advanced.

TL;DR — Google App Indexing (2013) → Firebase App Indexing (2016, oltre a un breve esperimento di «app streaming») → deprecato verso il 2021. Il successore sono i deep link: Android App Links (verificati con un file Digital Asset Links in /.well-known/assetlinks.json e filtri intent android:autoVerify) e iOS Universal Links (verificati con un file apple-app-site-association e l’entitlement Associated Domains). Secondo le indicazioni di Google di maggio 2025, i deep link non cambiano indicizzazione o ranking: la Ricerca continua a posizionare la pagina web e la destinazione del deep link dovrebbe corrispondere al contenuto dell’URL web. Misura il comportamento dei link con le analisi della piattaforma e dell’app, senza presumere che esista un rapporto dedicato in Search Console.

Tre epoche, un nome che confonde

Il motivo per cui «App Indexing» crea tanta confusione è che la stessa idea ha avuto tre nomi diversi in un decennio e l’ultima transizione è stata una deprecazione a cui molti contenuti vecchi non si sono mai adeguati.

2013–2016 — Google App Indexing. Nell’ottobre 2013 Google annunciò: “Googlebot can now index content in your Android app,” (traduzione) «Googlebot ora può indicizzare i contenuti della tua app Android», mostrando deep link all’app “straight in our search results when we think they’re relevant… and if the user has the app installed.” (traduzione) «direttamente nei risultati di ricerca quando riteniamo che siano pertinenti e se l’utente ha installato l’app». Dichiaravi i contenuti dell’app tramite la sitemap esistente e Webmaster Tools. Era Google che eseguiva il crawl dentro le app, come fa con le pagine web.

2016–~2021 — Firebase App Indexing. Dopo l’acquisizione di Firebase da parte di Google nel 2014, App Indexing è stato rinominato Firebase App Indexing intorno a Google I/O 2016. Ha aggiunto il supporto a iOS e, per un periodo, un esperimento chiamato app streaming: un pulsante «Prova ora» che permetteva di usare nel browser un’app non installata per alcuni minuti, direttamente da un risultato di ricerca. App streaming era un esperimento limitato del 2015–2016 ed è scomparso da tempo; non progettare nulla intorno a esso.

~2021–oggi — deprecato. L’interfaccia AppIndexApi è contrassegnata come deprecata nella documentazione di riferimento Android di Google. La documentazione live di Firebase ora afferma che Firebase App Indexing “is no longer the recommended way of indexing content for display as suggested results in Google Search App,” (traduzione) «non è più il metodo consigliato per indicizzare contenuti da mostrare come risultati suggeriti nell’app Google Search», con l’avvertenza esplicita che “the Google Search App for Android no longer uses local content indexed via Firebase App Indexing to provide results to users.” (traduzione) «l’app Google Search per Android non usa più i contenuti locali indicizzati tramite Firebase App Indexing per fornire risultati agli utenti». Firebase indirizza ora verso App Links e Universal Links. Il passaggio è avvenuto nel 2021: l’avviso di deprecazione è presente in un archivio dell’ottobre 2022 ma assente in quello dell’ottobre 2020.

Che cosa ha sostituito App Indexing: i deep link delle app

I deep link sono, nelle parole di Google, “special URIs that take users beyond your mobile app’s homepage, leading them directly to specific in-app content.” (traduzione) «URI speciali che portano gli utenti oltre la pagina iniziale dell’app mobile, direttamente a specifici contenuti interni». Il cambio di prospettiva rispetto al vecchio modello è fondamentale: si tratta di verifica e routing, gestiti dal sistema operativo e dal browser, non da una pipeline di indicizzazione gestita da Google. Nulla di tutto questo viene «inviato a un indice».

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

Android App Links sono, secondo 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.” (traduzione) «una funzionalità avanzata di deep linking che verifica i link al tuo sito stabilendo un’associazione attendibile tra app e sito; dopo la verifica, i link possono aprire subito il contenuto corrispondente nell’app senza chiedere all’utente di scegliere un’app». App Links è supportato da Android 6 in poi e Google lo definisce “a recommended approach” (traduzione) «un approccio consigliato» per i deep link verso il proprio sito.

Il collegamento di verifica è un file Digital Asset Links. Quando inserisci android:autoVerify="true" in un filtro intent e l’app è installata, “Android queries the corresponding websites for the Digital Asset Links file at https://hostname/.well-known/assetlinks.json.” (traduzione) «Android interroga i siti corrispondenti per trovare il file Digital Asset Links all’indirizzo indicato». Quel file JSON elenca quale pacchetto app (e quale impronta del certificato di firma) può gestire i link del dominio. Android 15 aggiunge Dynamic App Links, che permettono di affinare il comportamento di corrispondenza degli URL senza pubblicare una nuova versione dell’app.

Qui contano due confini di versione e firma. Primo: Dynamic App Links estende l’associazione sottostante del manifest, non la sostituisce; sulle versioni Android precedenti alla 15, la verifica continua a basarsi solo sulla corrispondenza standard tra manifest e assetlinks.json. Secondo: la verifica fallisce del tutto, non parzialmente, se l’impronta del certificato di firma in assetlinks.json non corrisponde esattamente all’identità di firma effettiva della build installata. Una build di debug firmata con una chiave diversa da quella dell’elemento assetlinks.json non verrà mai verificata, anche se ogni altro campo è corretto.

La distinzione da tenere a mente è questa: un deep link Android di base usa i filtri intent ma può mostrare la finestra di disambiguazione «con quale app vuoi aprire questo link?». App Links aggiunge la verifica Digital Asset Links, così un dominio verificato si apre direttamente nell’app, senza finestra.

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

L’equivalente Apple sono i Universal Links. Apple spiega: “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.” (traduzione) «Quando una persona tocca un Universal Link, il sistema apre direttamente l’app senza passare dal browser; poiché si tratta di normali link HTTP o HTTPS, lo stesso URL funziona per sito e app, mentre in assenza dell’app si apre nel browser predefinito».

Il file di verifica è apple-app-site-association, ospitato sul server 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.” (traduzione) «Quando qualcuno installa l’app, il sistema controlla un file sul server web per verificare che il sito autorizzi l’app ad aprire URL per suo conto». Sul lato app serve l’entitlement Associated Domains, che deve corrispondere ai domini del file. È lo stesso principio di Android: un handshake di fiducia tra sito e app, verificato dal dispositivo, non un segnale di ranking nella ricerca.

Un file apple-app-site-association valido e un entitlement corrispondente correttamente non garantiscono però che ogni tap apra l’app. Apple documenta casi reali in cui un Universal Link apre comunque Safari nonostante l’associazione funzionante: per esempio quando il link viene toccato dentro Safari mentre si sta già visitando lo stesso dominio o quando la persona ha scelto in precedenza di continuare ad aprire nel browser i link di quel dominio. Quando l’app non è installata o l’associazione non corrisponde, un link HTTP(S) standard deve ricadere nel browser invece di terminare su uno schema personalizzato rotto: è il sistema che funziona come progettato, non un bug da inseguire.

Entrambe le piattaforme sono supportate da Google Search come destinazioni di deep link.

I deep link delle app influenzano il ranking? (No: ecco la citazione esatta)

Questa è la correzione più importante dell’intero argomento, perché ancora oggi pagine dedicate al ranking lo spiegano male. Troverai articoli che sostengono erroneamente che App Indexing influenzi il ranking anche senza l’app installata o che Google usi i contenuti dell’app come segnale di ranking. Sono affermazioni false e il post di Google di maggio 2025 lo dice direttamente:

“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.” (traduzione) «Aggiungere deep link collega gli URL del sito alle pagine pertinenti dell’app. Non cambia il modo in cui la Ricerca Google mostra i contenuti: per indicizzazione e ranking continua a usare le pagine web. I deep link portano gli utenti dai risultati alla pagina corrispondente nell’app installata, migliorando l’esperienza.»

Leggilo con attenzione: è la pagina web a essere indicizzata e posizionata. Il deep link è un livello di routing post-clic che si attiva solo per utenti che hanno già l’app. È un miglioramento UX, non una leva di visibilità. Se qualcuno ti dice che configurare assetlinks.json farà salire il ranking, si sbaglia.

L’unico requisito reale: la parità dei contenuti

C’è una sola regola sostanziale, e riguarda l’onestà verso l’utente. Google dice:

“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.” (traduzione) «Poiché la Ricerca usa i contenuti della pagina web per indicizzazione e ranking, aggiungi deep link solo quando la pagina dell’app contiene gli stessi contenuti della pagina web corrispondente. Altrimenti titolo e snippet possono fuorviare chi fa clic. Differenze di layout o esperienza utente vanno bene, purché i contenuti coincidano.»

Quindi: una schermata nativa, più bella e con un layout diverso va bene. Non va bene una schermata che mostra contenuti diversi dalla pagina web, perché lo snippet toccato dall’utente è stato costruito dalla pagina web e ora l’utente è atterrato in un posto che non corrisponde. La parità riguarda il contenuto, non l’aspetto.

Come implementarlo oggi

Android: usa App Links. Associa l’app al sito nel manifest (filtri intent con android:autoVerify="true"), poi pubblica /.well-known/assetlinks.json sul sito con il nome del pacchetto e l’impronta del certificato di firma. Android verifica l’associazione durante l’installazione. App Links Assistant di Android Studio e la pagina Deep Links di Play Console aiutano a generare e convalidare la configurazione.

iOS: implementa Universal Links. Pubblica un file apple-app-site-association sul server web indicando quali percorsi corrispondono all’app e aggiungi l’entitlement Associated Domains per i domini corretti. La guida Apple al debugging dei Universal Links descrive i problemi comuni (tipo di contenuto errato del file, entitlement mancante, associazione in cache).

Nessuno dei due file viene sottoposto a crawl in un «indice di ricerca» come lasciava intendere App Indexing: sono handshake di fiducia verificati dal dispositivo. Se li sbagli, i link ricadono semplicemente nel browser; se li configuri bene, gli utenti con l’app installata vengono indirizzati nell’app.

Controllo minimo dei file di associazione

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

Entrambi gli endpoint dovrebbero restituire 200 senza redirect e fornire la risposta JSON prevista. La lente Scripts contiene i controlli estesi su tipo di contenuto, redirect, PowerShell, DevTools e bookmarklet.

Come misurarlo: il filtro Android app di Search Console

Google espone nativamente le prestazioni dei deep link delle app: “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.” (traduzione) «Search Console include il rendimento dei deep link Android del sito; nel rapporto Rendimento puoi usare il filtro di aspetto nella ricerca Android App per vedere quando vengono trovati e mostrati agli utenti». Questo fornisce clic, impressioni, CTR e posizione per i risultati in cui è comparso il deep link Android: il modo concreto e attuale per capire se sta producendo qualcosa. Il filtro è stato aggiunto nel 2019 ed è ancora lo strumento corrente secondo il post di Google del 2025.

Tieni però separati i due lavori. Il filtro Search Console è un rapporto sul traffico e sulla visualizzazione, solo per Android, dipendente dal fatto che Google mostri davvero il trattamento da deep link per una determinata query; non dimostra da solo che qualcosa sia indicizzato o posizionato. Verificare tecnicamente un deep link è un esercizio diverso: recupera i file di associazione e prova il tap-through su dispositivi reali (vedi le schede Scripts e Validation Tests). Non interpretare un rapporto Search Console vuoto come prova che la configurazione sia rotta e non interpretare i clic come un segnale SEO: misurano il volume del routing, non il ranking.

Bing e i deep link delle app

Non presumere la parità tra Google e Bing. Bing aveva un programma di «app linking» incentrato su Windows a partire dall’aprile 2014, rivolto a Windows 8,1 e Windows Phone, ma quelle pagine non esistono più (l’URL dev restituisce 404 e i post del blog reindirizzano alla home generica) e Windows Phone è stato dismesso. Non esiste oggi un equivalente pubblicato da Bing della guida di Google del 2025 sui deep link delle app. In pratica, App Links e Universal Links funzionano ancora su Bing/Edge mobile perché sono standard a livello di sistema operativo e browser, non qualcosa a cui un motore di ricerca debba aderire: li implementi allo stesso modo comunque. Semplicemente non esiste una documentazione Bing da citare.

Tecniche legacy che troverai ancora in giro

Alcune tecniche vicine generano confusione: chiamale per nome e vai oltre:

• Il markup schema.org potentialAction / ViewAction con una destinazione deep link android-app://. È una tecnica legacy legata alla vecchia epoca di App Indexing. Puoi ancora trovarla nei codebase e nel vocabolario delle action di schema.org, ma la raccomandazione attuale di Google è configurare App Links / Universal Links, non usare questo markup. Trattalo come qualcosa che «potresti ancora vedere», non come una raccomandazione.
• Firebase Dynamic Links è un prodotto Firebase diverso e deprecato separatamente: un servizio di abbreviazione URL e deferred deep linking per l’attribuzione marketing, non il sistema di contenuti App Indexing. Anche questo servizio è in fase di ritiro e la sua guida di migrazione rimanda ad App Links e Universal Links. Non confondere le due deprecazioni.

Il modello da ricordare è questo: (1) il vecchio sistema di crawl e streaming Google App Indexing / Firebase App Indexing = morto; (2) deep linking App Links / Universal Links = attuale, solo routing/UX, nessun effetto sul ranking; (3) l’app linking di Bing dell’epoca Windows = anch’esso morto, senza sostituto documentato.

Riepilogo AI

Una sintesi della versione Advanced:

• App Indexing è deprecato. Google App Indexing (2013) → Firebase App Indexing (2016) → deprecato verso il 2021. AppIndexApi è contrassegnato come deprecato nella documentazione Google; l’app Google Search non usa più i contenuti di Firebase App Indexing.
• Che cosa lo ha sostituito: i deep link delle app — Android App Links (verificati con un file Digital Asset Links in /.well-known/assetlinks.json + filtri intent android:autoVerify) e iOS Universal Links (verificati con apple-app-site-association + l’entitlement Associated Domains). Sono verifica e routing a livello di sistema operativo/browser, non un indice gestito da Google.
• I deep link NON influenzano il ranking. Secondo il post di Google di maggio 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.” (traduzione) «Non cambia il modo in cui la Ricerca Google mostra i contenuti: per indicizzazione e ranking continua a usare i contenuti delle pagine web». Indirizzano nell’app gli utenti che l’hanno installata, dopo il clic.
• L’unica regola reale è la parità dei contenuti: crea un deep link solo verso una schermata dell’app che mostri lo stesso contenuto della pagina web; differenze di layout/UX vanno bene.
• Misurazione: usa il filtro Android app di Search Console, ma è un rapporto sul traffico, non la prova che l’associazione tecnica funzioni o che il ranking sia cambiato; verifica l’associazione con test sui file e sui dispositivi.
• Nessuna piattaforma garantisce che ogni tap verificato apra l’app. Android fallisce completamente se l’impronta del certificato non coincide (Dynamic App Links su Android 15 estende, non sostituisce, la corrispondenza del manifest); iOS documenta casi legittimi, come navigazione Safari sullo stesso dominio o scelta precedente dell’utente, in cui il Universal Link apre comunque il browser.
• Bing non ha una guida equivalente aggiornata; il programma dell’epoca Windows è morto, ma App Links/Universal Links funzionano in Edge perché sono standard del sistema operativo.
• Non confondere App Indexing con Firebase Dynamic Links, prodotto separato e deprecato separatamente, né considerare il markup potentialAction/ViewAction una best practice attuale.

Documentazione ufficiale

Documentazione primaria di Google, Android e Apple.

Google — guida corrente

• Deep link delle app: collegare sito web e app (2 maggio 2025) — la guida autorevole corrente: che cosa fanno i deep link, l’assenza di effetto sul ranking, la parità dei contenuti e il filtro Search Console.
• Firebase App Indexing — la pagina live con l’avviso di deprecazione e il riferimento ad App Links / Universal Links.

Google — storico (per contesto sulla deprecazione)

• Indicizzare le app come i siti web (31 ottobre 2013) — l’annuncio originale di App Indexing.

Android

• Informazioni sui deep link — deep link, App Links e modello di verifica (aggiornato il 18 giugno 2026).
• Verificare gli Android App Links — android:autoVerify e il requisito Digital Asset Links / assetlinks.json.

Apple

• Consentire ad app e siti web di collegarsi ai tuoi contenuti — panoramica dei Universal Links e modello di verifica tramite file sul server.
• Supportare i domini associati — il file apple-app-site-association e l’entitlement Associated Domains.

Standard di settore (non specifico di Google)

• ViewAction / Actions (schema.org) — il vocabolario legacy potentialAction/ViewAction; contesto utile, non una raccomandazione Google attuale.

Citazioni dalla fonte

Dichiarazioni riportate da Google, Android e Apple. Ogni link Google/Android è un deep link che porta al passaggio citato nella pagina di origine.

Google — l’annuncio originale di 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.” (traduzione) «Proprio come esegue il crawl e indicizza i siti web, Googlebot ora può indicizzare i contenuti dell’app Android; se pagina web e contenuti dell’app sono indicizzati correttamente, Google proverà a mostrare nei risultati deep link pertinenti agli utenti che hanno installato l’app». — Lawrence Chang, Product Manager, Google. Vai alla citazione

Google — Firebase App Indexing è deprecato (documentazione live)

• “Firebase App Indexing is no longer the recommended way of indexing content for display as suggested results in Google Search App.” (traduzione) «Firebase App Indexing non è più il metodo consigliato per indicizzare contenuti da mostrare come risultati suggeriti nell’app Google Search». Vai alla citazione

Google — i deep link non cambiano il ranking (maggio 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.” (traduzione) «Non cambia il modo in cui la Ricerca Google mostra i contenuti: per indicizzazione e ranking continua a usare i contenuti delle pagine web». — John Mueller (Google Search Relations) e Sabs (Android Developer Relations). Vai alla citazione
• “You should only add deep links in cases where the app page contains the same content as the corresponding web page.” (traduzione) «Dovresti aggiungere deep link solo quando la pagina dell’app contiene gli stessi contenuti della pagina web corrispondente». Vai alla citazione

Android — App Links e file di verifica

• “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.” (traduzione) «Android App Links è una funzionalità avanzata di deep linking che verifica i link al tuo sito stabilendo un’associazione attendibile tra app e sito». — Android Developers. Vai alla citazione
• “Android queries the corresponding websites for the Digital Asset Links file at https://hostname/.well-known/assetlinks.json.” (traduzione) «Android interroga i siti corrispondenti per trovare il file Digital Asset Links all’indirizzo indicato». Vai alla citazione

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.” (traduzione) «Quando una persona tocca o seleziona un collegamento universale, il sistema lo indirizza direttamente all’app senza passare dal browser o dal sito; se l’app non è installata, apre l’indirizzo nel browser predefinito». — Documentazione Apple Developer, «Consentire ad app e siti web di collegarsi ai tuoi contenuti».

Conviene configurare i deep link delle app?

Un percorso rapido per rispondere alla domanda «ne ho davvero bisogno?», perché per molti siti la risposta onesta è «no».

1. Hai un’app mobile nativa che rispecchia i contenuti del sito?

• No, nessuna app → fermati. Non c’è nulla a cui collegarsi. App Indexing e deep link non ti riguardano. Se hai trovato «App Indexing» in una checklist, elimina quella riga: è deprecata.
• Sì → continua.

2. Lo fai per il ranking?

• Sì → fermati e rileggi. I deep link non influenzano indicizzazione o ranking. Se l’obiettivo è la visibilità SEO, investi nella pagina web mobile, non nell’infrastruttura dei deep link.
• No: voglio indirizzare nell’app gli utenti che l’hanno installata → continua.

3. La schermata dell’app mostra lo stesso contenuto della pagina web corrispondente?

• No (contenuto diverso) → non creare il deep link per quell’URL. La differenza inganna gli utenti, perché lo snippet è stato costruito dalla pagina web. Correggi prima la parità (le differenze di layout/UX vanno bene; quelle di contenuto no).
• Sì → continua.

4. Quale piattaforma o quali piattaforme?

• Android → App Links: filtri intent android:autoVerify + file Digital Asset Links in /.well-known/assetlinks.json.
• iOS → Universal Links: apple-app-site-association sul server + entitlement Associated Domains.
• Entrambe → fai entrambe le configurazioni: sono indipendenti.

5. Come saprai che funziona?

• Controlla il filtro Android app di Search Console nella ricerca per aspetto.
• Prova il tap-through su dispositivi reali e convalida i file di associazione (App Links Assistant su Android e debugging dei Universal Links su iOS).

Regola pratica: i deep link sono un miglioramento UX/routing per siti con un’app reale e contenuti corrispondenti, non un progetto SEO per il ranking e non qualcosa da aggiungere solo perché una vecchia guida citava «App Indexing».

Checklist per configurare i deep link delle app

Rilevante solo se hai un’app nativa che rispecchia i contenuti del sito:

• Hai verificato di non aspettarti un aumento del ranking: i deep link cambiano il routing, non il ranking.
• Parità dei contenuti verificata: ogni schermata dell’app collegata mostra lo stesso contenuto della pagina web corrispondente (le differenze di layout/UX vanno bene).
• Android: i filtri intent usano android:autoVerify="true" per il dominio.
• Android: /.well-known/assetlinks.json è pubblicato, servito via HTTPS con il tipo di contenuto corretto e contiene nome del pacchetto e impronta del certificato.
• iOS: apple-app-site-association è pubblicato sul server (tipo di contenuto corretto, senza redirect) con i pattern di percorso corretti.
• iOS: l’entitlement Associated Domains è stato aggiunto all’app e corrisponde ai domini nel file di associazione.
• Hai provato il tap-through reale su dispositivi Android e iOS fisici, con app installata e non installata.
• Hai controllato il filtro Android app di Search Console per impressioni e clic una volta online.
• Hai rimosso i riferimenti deprecati: vecchi tag sitemap App Indexing, chiamate SDK Firebase App Indexing o markup potentialAction/android-app:// che usavi come meccanismo principale.

Anti-pattern da evitare

• Trattare App Indexing come attuale. AppIndexApi è deprecato e l’app Google Search non usa più i contenuti di Firebase App Indexing. Se una guida, un plugin o una checklist ti dice di «abilitare App Indexing», è obsoleta.
• Aspettarsi un boost al ranking. Il mito più ripetuto nelle vecchie pagine sul ranking è che «indicizzare la tua app influenza il ranking». Google dice il contrario: la Ricerca posiziona la pagina web; i deep link non cambiano questo fatto.
• Creare deep link verso contenuti non corrispondenti. Mandare chi ha toccato lo snippet di una pagina web verso una schermata dell’app con contenuti diversi. Google avverte esplicitamente che questo inganna gli utenti. La parità riguarda il contenuto, non l’aspetto.
• Inseguire l’«app streaming». La funzione «Prova ora» per visualizzare un’app non installata era un esperimento del 2015–2016 ed è scomparsa. Non progettarci sopra.
• Confondere Firebase App Indexing e Firebase Dynamic Links. Sono prodotti diversi, entrambi deprecati, che risolvono problemi diversi (indicizzazione dei contenuti contro abbreviazione URL/attribuzione). Entrambi rimandano oggi ad App Links / Universal Links.
• Presumere la parità con Bing. Il vecchio programma di app linking di Bing per l’epoca Windows è morto e non ha un sostituto documentato. App Links/Universal Links funzionano ancora in Edge perché sono standard del sistema operativo, ma non c’è una guida Bing da seguire.
• Saltare la verifica e chiedersi perché «non funziona». Un tipo di contenuto errato, un redirect sul file di associazione o un entitlement mancante riportano silenziosamente al browser. I file sono un handshake rigoroso, non un suggerimento.

Errori comuni dei deep link delle app

Un link web continua ad aprirsi nel browser su Android

Sintomo: un’app installata non rivendica un URL HTTPS corrispondente. Causa probabile: la verifica del dominio è fallita perché host nel manifest, nome del pacchetto, impronta del certificato o risposta di assetlinks.json non corrispondono. Correzione: controlla l’identità di firma della build installata, recupera direttamente il file di associazione e ripeti la verifica dei link Android prima di provare di nuovo il tap.

Un Universal Link apre Safari invece dell’app iOS

Sintomo: lo stesso URL HTTPS funziona sul web ma evita l’app installata. Causa probabile: l’entitlement Associated Domains o i percorsi di apple-app-site-association non autorizzano l’URL; controlla però prima i casi documentati non anomali. La guida Apple descrive i link toccati dentro Safari sullo stesso dominio, o un dominio che la persona ha scelto in precedenza di continuare ad aprire nel browser, come aperture previste nel browser, non come errori di verifica. Correzione: conferma entitlement, disponibilità del file e regole dei percorsi, poi riprova dopo reinstallazione o aggiornamento dello stato di associazione del dispositivo; escludi il comportamento sullo stesso dominio o dovuto alla scelta precedente prima di concludere che l’associazione sia rotta.

L’app apre la schermata sbagliata

Sintomo: la verifica riesce, ma l’app arriva alla home o a contenuti non corrispondenti. Causa probabile: l’associazione del sistema operativo è corretta, ma il mapping della route dell’app è incompleto. Correzione: mappa percorso e parametri alla schermata corrispondente, conserva un fallback web sicuro e confronta il contenuto dell’app con la pagina web che ha fornito lo snippet di ricerca.

Deep link delle app — cheat sheet

Prima e adesso

File di verifica

Fatti rapidi

• I deep link cambiano il routing dopo il clic, non indicizzazione o ranking.
• Crea deep link solo verso schermate dell’app con contenuti corrispondenti alla pagina web.
• Android richiede filtri intent android:autoVerify="true".
• iOS richiede l’entitlement Associated Domains.
• Misura con il filtro Search Console Android app nella ricerca per aspetto.
• Bing: nessuna guida equivalente attuale; gli standard funzionano comunque in Edge.

Controlla i file di associazione

I deep link falliscono in modo silenzioso, quindi il debug più rapido è verificare che i due file di verifica esistano, restituiscano 200 e servano il tipo di contenuto corretto.

macOS / Linux — recuperare e ispezionare i file

# 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 DevTools del browser — controllo rapido della raggiungibilità

// 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 — controllo con un clic sul sito corrente

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

Se un file restituisce 404s, fa redirect o serve il tipo di contenuto sbagliato, il sistema operativo non verificherà l’associazione e i link ricadranno silenziosamente nel browser invece di aprire l’app.

Strumenti per configurare e fare debug dei deep link

• Android Studio — App Links Assistant — genera i filtri intent, crea e convalida i tuoi Digital Asset Links (assetlinks.json) e testa la gestione dei link.
• Google Play Console — pagina Deep Links — mostra lo stato dei deep link dell’app e della verifica.
• Convalida Digital Asset Links — verifica che il file assetlinks.json pubblicato associ correttamente dominio, pacchetto e impronta dell’app.
• Debugging dei Universal Links Apple — guida Apple per diagnosticare perché un Universal Link apre il browser invece dell’app (tipo di contenuto del file di associazione, entitlement, cache).
• Google Search Console — rapporto Performance — il filtro Search appearance Android app mostra impressioni, clic, CTR e posizione dei risultati in cui è comparso il tuo deep link Android.
• curl / DevTools / bookmarklet — il primo controllo più rapido per verificare che entrambi i file restituiscano 200, il tipo di contenuto corretto e nessun redirect (vedi la scheda Scripts).

Risorse che vale la pena leggere

I miei articoli

• L’indicizzazione mobile-first diventa solo mobile — il concetto correlato ma distinto della versione della pagina che Google indicizza: non confonderlo con il deep linking delle app.
• Guida introduttiva alla SEO tecnica — dove gli argomenti mobile e affini alle app si inseriscono nel quadro più ampio di crawl, indice e ranking.

I miei interventi

• Come funziona la ricerca (SlideShare) — la mia panoramica di crawling, rendering, indicizzazione e ranking, compreso il modo in cui Googlebot esegue il crawl come smartphone. (Avvertenza permanente: “This is my understanding of systems… not going to be 100% complete or accurate.” (traduzione) «Questa è la mia comprensione dei sistemi e non sarà completa o accurata al cento per cento».)

Dal settore

• Deep link delle app: collegare sito web e app (Google) — guida autorevole corrente e fonte delle affermazioni su assenza di effetto sul ranking e parità dei contenuti.
• Firebase App Indexing (Google/Firebase) — avviso live di deprecazione che rimanda ad App Links / Universal Links.
• Informazioni sui deep link (Android) — App Links e modello di verifica.
• Verificare gli Android App Links (Android) — requisito assetlinks.json.
• Consentire ad app e siti web di collegarsi ai tuoi contenuti (Apple) — Universal Links e apple-app-site-association.
• Google App Indexing diventa Firebase App Indexing (Search Engine Land) — la copertura di Barry Schwartz sul rebranding del 2016 a Google I/O.

Statistiche da citare

• I deep link delle app non cambiano indicizzazione o ranking — la dichiarazione di Google di maggio 2025: “Search continues to use the content of your web pages for indexing and ranking.” (traduzione) «La Ricerca continua a usare i contenuti delle pagine web per indicizzazione e ranking». È il fatto più importante e più spesso riportato male su questo argomento. Fonte
• Firebase App Indexing è deprecato — l’app Google Search per Android “no longer uses local content indexed via Firebase App Indexing” (traduzione) «non usa più i contenuti locali indicizzati tramite Firebase App Indexing», secondo la documentazione live di Firebase. Il passaggio è avvenuto nel 2021 (presente in un archivio di ottobre 2022, assente in quello di ottobre 2020). Fonte
• App Links è supportato da Android 6+ — Google definisce App Links “a recommended approach” (traduzione) «un approccio consigliato» per i deep link al proprio sito, verificati tramite il file Digital Asset Links in /.well-known/assetlinks.json. Fonte

Prompt per il QA dei deep link delle app

Rivedere i dati di associazione 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]

Creare una matrice di test per la parità dei contenuti

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]

Convalidare un rilascio di deep link delle app

Testare i file di associazione pubblici

Test da eseguire: recupera entrambi gli endpoint di associazione noti senza cookie o autenticazione e convalida il loro JSON. Risultato atteso: le risposte riuscite contengono identificatori dell’app di produzione, impronte e regole dei percorsi previsti. Interpretazione del fallimento: i dispositivi non possono verificare il rapporto sito-app. Finestra di monitoraggio: immediata dopo il deploy e dopo modifiche al certificato. Trigger di rollback: uno dei due file restituisce errori, fa redirect inaspettatamente o autorizza l’identità di produzione sbagliata.

Testare il comportamento con app installata e non installata

Test da eseguire: tocca link HTTPS rappresentativi su dispositivi Android e iOS reali, prima con l’app installata e poi senza. Risultato atteso: chi ha l’app installata raggiunge la schermata corrispondente; gli altri raggiungono lo stesso URL web. Interpretazione del fallimento: verifica, routing o fallback sono incompleti. Finestra di monitoraggio: immediata per ogni rilascio dell’app. Trigger di rollback: i link terminano, aprono la schermata sbagliata o non ricadono sul web.

Testare la parità dei contenuti

Test da eseguire: confronta il contenuto ricercabile di ogni risultato web con la sua destinazione nell’app. Risultato atteso: soggetto e contenuto sostanziale corrispondono, anche se il layout differisce. Interpretazione del fallimento: il deep link può ingannare gli utenti perché Search indicizza la pagina web. Finestra di monitoraggio: prima di mappare una route e dopo modifiche importanti ai template dei contenuti. Trigger di rollback: la destinazione dell’app non soddisfa più il titolo e lo snippet del risultato web.

Misurare la salute dei deep link delle app

Visualizzazioni Android app nella ricerca

Metrica: impressioni e clic per la visualizzazione Android App. Che cosa indica: con quale frequenza Google ha mostrato risultati con un trattamento da deep link Android e quanto traffico li ha usati. Come estrarla: Performance di Search Console, filtrata per la visualizzazione Android App. Benchmark / intervallo realistico: stabilisci una baseline per query e pagina; l’idoneità dipende dall’adozione dell’app e dai risultati pertinenti, quindi non esiste un obiettivo universale. Cadenza: mensile, con annotazioni dei rilasci.

Tasso di apertura delle route riuscite

Metrica: aperture di deep link valide divise per i tentativi di app link. Che cosa indica: se i link verificati raggiungono la schermata prevista invece di un fallback o di un errore. Come estrarla: eventi di analisi dell’app alla ricezione del link e al rendering della destinazione, escludendo parametri URL sensibili. Benchmark / intervallo realistico: usa la baseline della tua piattaforma e versione; indaga regressioni persistenti dopo un rilascio. Cadenza: settimanale e a ogni rilascio dell’app.

Numero di eccezioni di parità

Metrica: URL web mappati la cui destinazione nell’app non contiene più contenuti equivalenti. Che cosa indica: se il routing rispetta ancora il requisito centrale di parità dei contenuti. Come estrarla: inventario mantenuto URL-schermata più QA a ogni rilascio. Benchmark / intervallo realistico: zero eccezioni note è l’obiettivo corretto. Cadenza: a ogni rilascio e dopo modifiche importanti all’architettura informativa web o app.

Mettiti alla prova: App Indexing

Cinque domande rapide su che cos’era App Indexing, che cosa lo ha sostituito e che cosa fa davvero per la SEO. Scegli una risposta per ciascuna, poi controlla.

Cronologia modifiche