Indexação de apps (deep linking para pesquisa)

TL;DR — “App Indexing” foi um recurso antigo do Google que retirava conteúdo do seu app de celular e o mostrava nos resultados de pesquisa. O Google o encerrou. O que se usa hoje são deep links de apps — links que, se você já tem o app instalado, abrem um resultado de pesquisa dentro do app em vez de no navegador do celular. O ponto importante: isso não ajuda a ranquear mais alto. O Google continua ranqueando seu site; deep links apenas mudam onde o toque termina.

O que era o “App Indexing”

Anos atrás, o Google permitia conectar seu site ao seu app móvel nativo para mostrar o conteúdo do app — e links diretos para ele — nos resultados de pesquisa. Esse sistema se chamava App Indexing (e depois Firebase App Indexing). Se você pesquisasse algo e tivesse o app correspondente instalado, o Google poderia levá-lo para dentro do app em vez de para uma página web.

Se você está lendo isto porque encontrou “App Indexing” em um checklist antigo de SEO, em uma documentação de desenvolvimento ou em uma configuração de plugin, a resposta curta é: está deprecated. O Google o desligou. Você não precisa configurá-lo e, se um tutorial disser que precisa, o tutorial está desatualizado.

O que o substituiu

A versão moderna de “abrir meu app a partir de um resultado de pesquisa” se chama deep links de apps, e cada plataforma tem seu próprio nome:

• O Android chama isso de App Links.
• O iOS chama isso de Universal Links.

Ambos fazem o mesmo trabalho: quando alguém toca em um link para seu site — vindo de um resultado do Google, de outro site ou de um app — e já tem seu app instalado, o celular abre esse conteúdo dentro do app. Se a pessoa não tem o app, o mesmo link abre o navegador normalmente.

O erro que a maioria comete

Deep links de apps não ajudam você a ranquear. Esse é o mito a desaprender. Artigos antigos afirmam que “indexar seu app” aumenta seu ranqueamento. O Google disse claramente que não — a Pesquisa continua usando o conteúdo da sua página web para decidir o ranqueamento. Deep links apenas mudam a experiência depois que alguém clica, para quem tem o app. São um recurso de conveniência, não um truque de ranqueamento.

Há uma regra real se você configurá-los: a tela do app para a qual você cria o link deve mostrar o mesmo conteúdo da página web. O Google monta o snippet de pesquisa a partir da página web; se o app mostra algo diferente, você enganou a pessoa que tocou.

Quer a história completa, os arquivos e passos exatos para Android e iOS e como medir isso no Search Console? Mude para a aba Advanced.

TL;DR — Google App Indexing (2013) → Firebase App Indexing (2016, além de um experimento curto de “app streaming”) → deprecated por volta de 2021. O sucessor são os deep links de apps: Android App Links (verificados com um arquivo Digital Asset Links em /.well-known/assetlinks.json e filtros de intent android:autoVerify) e iOS Universal Links (verificados com um arquivo apple-app-site-association e a autorização Associated Domains). Segundo a orientação do Google de maio de 2025, deep links não mudam a indexação nem o ranqueamento — a Pesquisa continua ranqueando a página web — e o destino do deep link deve corresponder ao conteúdo da URL web. Meça o comportamento dos app links com analytics da plataforma e do app, em vez de presumir que existe um relatório dedicado no Search Console.

Três eras, um nome confuso

O motivo de “App Indexing” causar tanta confusão é que a mesma ideia usou três nomes diferentes em uma década, e a última transição foi uma descontinuação que muito conteúdo antigo nunca incorporou.

2013–2016 — Google App Indexing. Em outubro de 2013, o Google anunciou que “Googlebot can now index content in your Android app” (tradução) «o Googlebot agora pode indexar conteúdo no seu app Android», exibindo deep links para o app “straight in our search results when we think they’re relevant… and if the user has the app installed” (tradução) «diretamente nos nossos resultados de pesquisa quando considerarmos que são relevantes… e se o usuário tiver o app instalado». Você declarava o conteúdo do app por meio do sitemap existente e do Webmaster Tools. Era o Google rastreando dentro de apps, como rastreia páginas web.

2016–~2021 — Firebase App Indexing. Depois da aquisição do Firebase pelo Google em 2014, o App Indexing foi rebatizado de Firebase App Indexing por volta do Google I/O de 2016. Ele adicionou suporte a iOS e, por um tempo, um experimento chamado app streaming — um botão “Try Now” que permitia executar um app não instalado no navegador por alguns minutos, direto de um resultado de pesquisa. O app streaming foi um experimento limitado da era 2015–2016 e desapareceu há muito; não planeje nada em torno dele.

~2021–presente — deprecated. A interface AppIndexApi está marcada como deprecated na documentação Android do Google. A documentação ativa do Firebase agora afirma que o Firebase App Indexing “is no longer the recommended way of indexing content for display as suggested results in Google Search App,” (tradução) «não é mais a maneira recomendada de indexar conteúdo para exibição como resultados sugeridos no aplicativo de Busca do Google», com o alerta explícito de que “the Google Search App for Android no longer uses local content indexed via Firebase App Indexing to provide results to users.” (tradução) «o aplicativo de Busca do Google para Android deixou de usar conteúdo local indexado pelo Firebase App Indexing para fornecer resultados aos usuários». O Firebase agora aponta para App Links e Universal Links como o caminho recomendado. (A virada ocorreu em 2021 — o aviso de descontinuação aparece em um snapshot de arquivo de outubro de 2022, mas não no de outubro de 2020.)

O que substituiu o App Indexing: deep links de apps

Deep links são, nas palavras do Google, “special URIs that take users beyond your mobile app’s homepage, leading them directly to specific in-app content” (tradução) «URIs especiais que levam os usuários além da página inicial do seu app móvel, conduzindo-os diretamente a conteúdo específico dentro do app». A mudança de mentalidade em relação ao modelo antigo é essencial: isto é verificação e roteamento, tratados no nível do sistema operacional e do navegador — não um pipeline de indexação operado pelo Google. Nada aqui é “enviado para um índice”.

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

Os Android App Links são, segundo o 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.” (tradução) «uma capacidade aprimorada de deep linking que verifica deep links para seu próprio site ao estabelecer uma associação confiável entre seu app e seu site. Depois de verificados, deep links para seu site podem abrir imediatamente o conteúdo correspondente no app, sem exigir que o usuário selecione o app em um diálogo de desambiguação». O App Links é compatível com Android 6 em diante, e o Google o chama de “a recommended approach” (tradução) «uma abordagem recomendada» para deep links para seu próprio site.

O handshake de verificação é um arquivo Digital Asset Links. Quando você coloca android:autoVerify="true" em um filtro de intent e o app está instalado, “Android queries the corresponding websites for the Digital Asset Links file at https://hostname/.well-known/assetlinks.json” (tradução) «o Android consulta os sites correspondentes em busca do arquivo Digital Asset Links em https://hostname/.well-known/assetlinks.json». Esse JSON lista qual pacote de app (e qual fingerprint do certificado de assinatura) tem permissão para lidar com os links do seu domínio. O Android 15 adiciona Dynamic App Links, permitindo refinar o comportamento de correspondência de URLs sem enviar uma nova versão do app.

Duas fronteiras de versão/assinatura importam aqui. Primeiro, Dynamic App Links estendem a associação subjacente do manifesto, em vez de substituí-la — em versões do Android anteriores à 15, a verificação ainda roda somente pela correspondência padrão entre manifesto e assetlinks.json. Segundo, a verificação falha por completo, não parcialmente, se o fingerprint do certificado de assinatura listado em assetlinks.json não corresponder exatamente à identidade de assinatura real da build instalada — uma build de debug assinada com uma chave diferente da entrada em assetlinks.json jamais será verificada, mesmo que todos os outros campos estejam corretos.

A distinção que vale manter clara é esta: um deep link Android básico usa filtros de intent, mas pode abrir o diálogo “qual app você quer usar para abrir isto?”. O App Links adiciona a verificação Digital Asset Links para que um domínio verificado abra diretamente no app, sem diálogo.

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

O equivalente da Apple são os Universal Links. A Apple diz: “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.” (tradução) «quando os usuários tocam ou clicam em um universal link, o sistema redireciona o link diretamente para o app sem passar pelo navegador web padrão da pessoa ou pelo seu site… como universal links são links HTTP ou HTTPS padrão, uma URL funciona para seu site e seu app. Se a pessoa não instalou o app, o sistema abre a URL no navegador web padrão».

O arquivo de verificação aqui é apple-app-site-association, hospedado no seu servidor 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.” (tradução) «quando alguém instala seu app, o sistema verifica um arquivo armazenado no seu servidor web para confirmar que seu site permite que o app abra URLs em seu nome». No lado do app, você precisa da autorização Associated Domains correspondente aos domínios desse arquivo. O princípio é o mesmo do Android — um handshake de confiança entre site e app, conferido pelo dispositivo, não um sinal de ranqueamento.

Um arquivo apple-app-site-association válido e uma autorização correspondente correta não garantem que todo toque abrirá o app. A Apple documenta casos reais em que um Universal Link ainda abre no Safari apesar de uma associação funcionando — por exemplo, quando o link é tocado dentro do próprio Safari enquanto a pessoa já navega no mesmo domínio, ou quando ela escolheu anteriormente continuar abrindo os links desse domínio no navegador. E quando o app realmente não está instalado, ou a associação não corresponde, um link HTTP(S) padrão deve voltar a abrir no navegador em vez de terminar em um esquema customizado quebrado — esse fallback é o sistema funcionando como projetado, não um bug a perseguir.

As duas plataformas são compatíveis com o Google Search como destinos de deep link.

Deep links de apps afetam o ranqueamento? (Não — e aqui está a citação exata)

Esta é a correção mais importante de todo o tema, porque páginas de ranqueamento ainda erram nisso. Você encontrará artigos afirmando coisas como “App Indexing will influence ranking… whether or not the user has your app installed” (tradução) «o App Indexing influenciará o ranqueamento… tenha ou não o usuário o app instalado» ou “Google will use the content within your app as a signal in ranking” (tradução) «o Google usará o conteúdo do seu app como sinal de ranqueamento». Essas afirmações são falsas, e a publicação do Google de maio de 2025 diz isso diretamente:

“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.” (tradução) «adicionar deep links ao seu site conecta as URLs do site às páginas correspondentes do app. Isso não muda como o Google Search mostra seu conteúdo; a Pesquisa continua usando o conteúdo das suas páginas web para indexação e ranqueamento. Deep links de apps permitem que usuários passem dos resultados da Pesquisa diretamente para a página correspondente do app (se instalado), proporcionando uma experiência melhor.»

Leia com atenção: a página web é o que é indexado e ranqueado. O deep link é uma camada de roteamento pós-clique que só entra em ação para usuários que já têm o app. É uma melhoria de UX, não uma alavanca de visibilidade. Se alguém disser que configurar assetlinks.json elevará seu ranqueamento, essa pessoa está errada.

O único requisito real: paridade de conteúdo

Existe exatamente uma regra substantiva, e ela trata de honestidade com o usuário. O 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.” (tradução) «como a Pesquisa usa o conteúdo da sua página web para indexação e ranqueamento, você só deve adicionar deep links quando a página do app contiver o mesmo conteúdo da página web correspondente. Caso contrário, o título e o snippet mostrados para a página no Google Search poderiam enganar os usuários sobre o conteúdo que verão depois do clique. Diferenças de layout ou de outra UX entre páginas de app e páginas web correspondentes são aceitáveis, desde que o conteúdo corresponda.»

Portanto: uma tela nativa, mais bonita e com layout diferente é aceitável. Uma tela que mostra conteúdo diferente da página web não é — porque o snippet tocado pelo usuário foi construído a partir da página web, e agora ele chegou a um lugar que não corresponde. Paridade trata de conteúdo, não de aparência.

Como implementar hoje

Android: use App Links. Associe seu app ao site no manifesto do app (filtros de intent com android:autoVerify="true") e publique /.well-known/assetlinks.json no site, listando o nome do pacote do app e o fingerprint do certificado de assinatura. O Android verifica a associação na instalação. O App Links Assistant do Android Studio e a página Deep Links do Play Console ajudam a gerar e validar a configuração.

iOS: implemente Universal Links. Publique um arquivo apple-app-site-association no servidor web, descrevendo quais caminhos mapeiam para o app, e adicione a autorização Associated Domains no app para os domínios correspondentes. A documentação de depuração de Universal Links da Apple percorre falhas comuns (content-type errado no arquivo, autorização ausente, associação em cache).

Nenhum dos dois arquivos é rastreado para um “índice de pesquisa” como o App Indexing sugeria — são handshakes de confiança conferidos pelo dispositivo. Se estiverem errados, os links simplesmente voltam ao navegador; se estiverem certos, usuários com o app instalado são encaminhados para dentro dele.

Verificação mínima do arquivo de associação

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

Os dois endpoints devem retornar 200 sem redirecionamento e expor a resposta JSON esperada. A lente Scripts traz verificações ampliadas de content-type, redirecionamento, PowerShell, DevTools e bookmarklet.

Como medir: filtro Android app do Search Console

O Google expõe o desempenho de deep links de apps de forma nativa: “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.” (tradução) «o Search Console inclui o desempenho dos deep links de apps do seu site para Android. No relatório de desempenho, você pode usar o filtro de aparência de pesquisa Android App para ver quando os deep links do seu app Android são encontrados e exibidos aos usuários». Isso fornece cliques, impressões, CTR e posição dos resultados em que o deep link Android apareceu — o meio concreto e atual de ver se tudo isso faz alguma diferença. (Esse filtro foi adicionado em 2019; continua sendo a ferramenta atual segundo a publicação do Google de 2025.)

Separe os dois trabalhos, porém. O filtro do Search Console é um relatório de tráfego/aparência — somente Android, dependente de o Google realmente mostrar o tratamento de app-deep-link para uma consulta, e não prova por si só que algo está indexado ou ranqueando. Confirmar que um deep link funciona tecnicamente é outro exercício: busque os arquivos de associação e teste o toque em dispositivos reais (veja as abas Scripts e Validation Tests). Não trate um relatório silencioso no Search Console como evidência de que sua configuração está quebrada, nem trate cliques no relatório como sinal de SEO — ele informa volume de roteamento, não ranqueamento.

Bing e deep links de apps

Não presuma paridade entre Google e Bing. O Bing executou um programa de “app linking” centrado no Windows a partir de abril de 2014, voltado a Windows 8,1 e Windows Phone — mas aquelas páginas morreram (a URL de desenvolvimento retorna 404, as publicações do blog redirecionam para a página inicial genérica), e o próprio Windows Phone foi descontinuado. Não existe um equivalente atual, publicado pelo Bing, da orientação do Google de 2025 sobre deep links de apps. Na prática, App Links e Universal Links continuam funcionando no Bing/Edge móvel porque são padrões no nível do sistema operacional e do navegador, não algo que um mecanismo de busca precise habilitar — portanto você os implementa da mesma maneira. Só não há documentação do Bing para indicar.

Coisas legadas que você ainda verá por aí

Algumas técnicas adjacentes causam confusão; dê nome a elas e siga em frente:

• Marcação schema.org potentialAction / ViewAction com um destino de deep link android-app://. É uma técnica legada ligada à era antiga do App Indexing. Você ainda pode encontrá-la em bases de código e no vocabulário de ações do schema.org, mas a recomendação atual do Google é configurar App Links / Universal Links, não usar essa marcação. Trate-a como “você ainda pode ver isto”, não como recomendação.
• Firebase Dynamic Links é um produto Firebase diferente e também descontinuado — um serviço de encurtamento de URLs / deep linking adiado para atribuição de marketing, não o sistema de indexação de conteúdo do App Indexing. Ele também está sendo encerrado, e sua própria orientação de migração aponta para App Links e Universal Links. Não confunda as duas descontinuações.

O modelo limpo para levar daqui é: (1) sistema antigo de rastreamento e streaming do Google App Indexing / Firebase App Indexing = morto; (2) deep linking com App Links / Universal Links = atual, somente roteamento/UX, sem efeito no ranqueamento; (3) o antigo app linking do Bing na era Windows = também morto, sem substituto documentado.

Resumo de IA

Uma versão condensada da versão Advanced:

• App Indexing está deprecated. Google App Indexing (2013) → Firebase App Indexing (2016) → deprecated por volta de 2021. A interface AppIndexApi está marcada como deprecated na documentação do Google; o app Google Search não usa mais conteúdo do Firebase App Indexing.
• O que o substituiu: deep links de apps — Android App Links (verificados por um arquivo Digital Asset Links em /.well-known/assetlinks.json + filtros de intent android:autoVerify) e iOS Universal Links (verificados por apple-app-site-association + a autorização Associated Domains). São verificação e roteamento no nível do SO/navegador, não um índice operado pelo Google.
• Deep links NÃO afetam o ranqueamento. Segundo a publicação do Google de maio de 2025: “don’t change how Google Search shows your content; Search continues to use the content of your web pages for indexing and ranking” (tradução) «não mudam como o Google Search mostra seu conteúdo; a Pesquisa continua usando o conteúdo das suas páginas web para indexação e ranqueamento». Eles apenas encaminham usuários com o app instalado para dentro dele depois do clique.
• A única regra real é a paridade de conteúdo: crie deep link apenas para uma tela de app que mostra o mesmo conteúdo da página web (diferenças de layout/UX são aceitáveis).
• Meça isso com o filtro de aparência de pesquisa Android app do Search Console — mas esse é um relatório de tráfego, não prova de que a associação técnica funciona ou de que algo ranqueia de modo diferente; verifique a associação com testes de arquivo/dispositivo.
• Nenhuma plataforma garante que todo toque verificado abrirá o app. A verificação Android falha completamente quando há divergência de fingerprint do certificado (Dynamic App Links no Android 15 estendem, não substituem, a correspondência do manifesto); o iOS documenta casos legítimos — navegação no Safari no mesmo domínio e escolha anterior do usuário — em que um Universal Link ainda abre no navegador apesar de uma associação funcionando.
• O Bing não tem orientação equivalente atual; seu programa da era Windows morreu, mas App Links/Universal Links continuam funcionando no Edge porque são padrões do sistema operacional.
• Não confunda App Indexing com Firebase Dynamic Links (produto diferente e também descontinuado), nem trate marcação potentialAction/ViewAction como prática recomendada atual.

Documentação oficial

Documentação de fonte primária do Google, Android e Apple.

Google — orientação atual

• Deep links de apps: conectando seu site e seu app (2 de maio de 2025) — a explicação atual e autorizada: o que deep links fazem, a afirmação de que não afetam o ranqueamento, a paridade de conteúdo e o filtro do Search Console.
• Firebase App Indexing — a página ativa com o aviso de descontinuação e o apontamento para App Links / Universal Links.

Google — histórico (para contextualizar o que foi descontinuado)

• Indexando apps como sites (31 de outubro de 2013) — o anúncio original do App Indexing.

Android

• Sobre deep links — deep links, App Links e o modelo de verificação (atualizado em 18/06/2026).
• Verificar Android App Links — android:autoVerify e o requisito Digital Asset Links / assetlinks.json.

Apple

• Permitir que apps e sites apontem para seu conteúdo — visão geral dos Universal Links e do modelo de verificação por arquivo no servidor.
• Compatibilidade com domínios associados — o arquivo apple-app-site-association e a autorização Associated Domains.

Padrão do setor (não específico do Google)

• ViewAction / Actions (schema.org) — o vocabulário legado potentialAction/ViewAction; contexto útil, não recomendação atual do Google.

Citações da fonte

Declarações registradas do Google, Android e Apple. Cada link do Google/Android é um deep link que salta para a passagem citada na página-fonte.

Google — o anúncio original do 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.” (tradução) «assim como rastreia e indexa sites, o Googlebot agora pode indexar conteúdo no seu app Android… se tanto a página web quanto o conteúdo do app forem indexados com sucesso, o Google tentará mostrar deep links para seu app diretamente nos resultados de pesquisa quando considerar que são relevantes para a consulta do usuário e se o usuário tiver o app instalado». — Lawrence Chang, gerente de produto, Google. Ir para a citação

Google — Firebase App Indexing está deprecated (documentação ativa)

• “Firebase App Indexing is no longer the recommended way of indexing content for display as suggested results in Google Search App.” (tradução) «o Firebase App Indexing não é mais a maneira recomendada de indexar conteúdo para exibição como resultados sugeridos no Google Search App». Ir para a citação

Google — deep links não mudam o ranqueamento (maio de 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.” (tradução) «isso não muda como o Google Search mostra seu conteúdo; a Pesquisa continua usando o conteúdo das suas páginas web para indexação e ranqueamento». — John Mueller (Google Search Relations) e Sabs (Android Developer Relations). Ir para a citação
• “You should only add deep links in cases where the app page contains the same content as the corresponding web page.” (tradução) «você só deve adicionar deep links quando a página do app contiver o mesmo conteúdo da página web correspondente». Ir para a citação

Android — App Links e o arquivo de verificação

• “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.” (tradução) «Android App Links é uma capacidade aprimorada de deep linking que verifica deep links para seu próprio site ao estabelecer uma associação confiável entre seu app e seu site». — Android Developers. Ir para a citação
• “Android queries the corresponding websites for the Digital Asset Links file at https://hostname/.well-known/assetlinks.json.” (tradução) «o Android consulta os sites correspondentes em busca do arquivo Digital Asset Links em https://hostname/.well-known/assetlinks.json». Ir para a citação

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.” (tradução) «quando os usuários tocam ou clicam em um universal link, o sistema redireciona o link diretamente para o app sem passar pelo navegador web padrão da pessoa ou pelo seu site… se a pessoa não instalou o app, o sistema abre a URL no navegador web padrão». — documentação para desenvolvedores da Apple, “Permitir que apps e sites apontem para seu conteúdo”.

Você deve configurar deep links de apps?

Um caminho rápido pela pergunta “eu sequer preciso disto?” — porque, para muitos sites, a resposta honesta é “não”.

1. Você tem um app móvel nativo que espelha o conteúdo do seu site?

• Não há app → pare. Não há nada para criar deep link. App Indexing / deep links são irrelevantes para você. (E, se você encontrou “App Indexing” em um checklist, apague essa linha — está deprecated.)
• Sim → continue.

2. Você está fazendo isto por causa de ranqueamento?

• Sim → pare e releia. Deep links não afetam indexação nem ranqueamento. Se a meta é visibilidade de SEO, invista na sua página web móvel, não na infraestrutura de deep links.
• Não — quero encaminhar usuários com o app instalado para dentro dele → continue.

3. A tela do app mostra o mesmo conteúdo da página web correspondente?

• Não (conteúdo diferente) → não crie deep link para essa URL. Uma divergência engana usuários, porque o snippet foi construído a partir da página web. Corrija a paridade primeiro (diferenças de layout/UX são aceitáveis — diferenças de conteúdo não).
• Sim → continue.

4. Qual(is) plataforma(s)?

• Android → App Links: filtros de intent android:autoVerify + um arquivo Digital Asset Links em /.well-known/assetlinks.json.
• iOS → Universal Links: apple-app-site-association no seu servidor + a autorização Associated Domains.
• Ambos → faça os dois; são independentes.

5. Como você saberá se está funcionando?

• Confira o filtro de aparência Android app do Search Console para Android.
• Teste o toque real em dispositivos reais e valide os arquivos de associação (App Links Assistant no Android; depuração de Universal Links da Apple no iOS).

Regra prática: deep links são uma melhoria de UX/roteamento para sites com um app real que corresponde ao conteúdo — não um projeto de ranqueamento SEO e não algo para instalar só porque um guia antigo mencionou “App Indexing”.

Checklist de configuração de deep links de apps

Só é relevante se você tem um app nativo que espelha seu conteúdo web:

• Confirmado que você não espera um ganho de ranqueamento — deep links mudam roteamento, não ranqueamento.
• Paridade de conteúdo verificada: cada tela do app com deep link mostra o mesmo conteúdo da página web correspondente (diferenças de layout/UX são aceitáveis).
• Android: filtros de intent usam android:autoVerify="true" para seu domínio.
• Android: /.well-known/assetlinks.json publicado, servido por HTTPS com o content-type correto, listando o nome do pacote do app e o fingerprint do certificado de assinatura.
• iOS: apple-app-site-association publicado no servidor (content-type correto, sem redirecionamentos), com os padrões de caminho certos.
• iOS: autorização Associated Domains adicionada ao app, correspondendo aos domínios do arquivo de associação.
• Toques reais testados em dispositivos físicos Android e iOS (casos instalado e não instalado).
• Filtro de aparência Android app do Search Console revisado quanto a impressões/cliques depois de entrar no ar.
• Referências deprecated removidas — tags de sitemap do antigo App Indexing, chamadas do SDK Firebase App Indexing ou marcação potentialAction/android-app:// que você usava como “o” mecanismo.

Antipadrões a evitar

• Tratar App Indexing como atual. A AppIndexApi está deprecated e o app Google Search não usa mais conteúdo do Firebase App Indexing. Se um guia, plugin ou checklist mandar “habilitar App Indexing”, está desatualizado.
• Esperar um ganho de ranqueamento. O mito mais repetido nas páginas antigas de ranqueamento é: “indexar seu app influencia o ranqueamento”. O Google diz o oposto — a Pesquisa ranqueia a página web; deep links não mudam isso.
• Criar deep link para conteúdo incompatível. Enviar quem tocou em um snippet de página web para uma tela de app com conteúdo diferente. O Google avisa explicitamente que isso engana usuários. Paridade trata de conteúdo, não de aparência.
• Perseguir “app streaming”. O recurso de prévia “Try Now” de um app não instalado foi um experimento de 2015–2016 e desapareceu. Não projete nada em torno dele.
• Confundir Firebase App Indexing com Firebase Dynamic Links. São produtos diferentes, ambos descontinuados, que resolviam problemas diferentes (indexação de conteúdo vs. encurtamento/atribuição de URLs). Ambos agora apontam para App Links / Universal Links.
• Presumir paridade com o Bing. O antigo programa de app linking do Bing na era Windows morreu, sem substituto documentado. App Links/Universal Links continuam funcionando no Edge porque são padrões no nível do SO — mas não há documentação do Bing para seguir.
• Pular a verificação e perguntar por que “não funciona”. Um content-type errado, um redirecionamento no arquivo de associação ou uma autorização ausente fazem você voltar silenciosamente ao navegador. Os arquivos são um handshake estrito, não uma sugestão.

Falhas comuns de deep links de apps

Um link web ainda abre no navegador no Android

Sintoma: um app instalado não reivindica uma URL HTTPS correspondente. Causa provável: a verificação do domínio falhou porque o host do manifesto, o nome do pacote, o fingerprint do certificado de assinatura ou a resposta de assetlinks.json não corresponde. Correção: confira a identidade de assinatura da build instalada, busque o arquivo de associação diretamente e execute novamente a verificação de links do Android antes de testar o toque.

Um Universal Link abre o Safari em vez do app iOS

Sintoma: a mesma URL HTTPS funciona na web, mas contorna o app instalado. Causa provável: a autorização Associated Domains ou os caminhos de apple-app-site-association não autorizam a URL — mas confira primeiro os casos documentados que não são falhas: a orientação da Apple descreve links tocados dentro do Safari no mesmo domínio, ou em um domínio que a pessoa escolheu anteriormente continuar abrindo no navegador, como aberturas esperadas no navegador, não falhas de verificação. Correção: confirme a autorização do domínio, a disponibilidade do arquivo e as regras de caminho; depois teste novamente após reinstalar o app ou atualizar o estado de associação do dispositivo — e descarte comportamento de mesmo domínio ou escolha anterior do usuário antes de presumir que a associação está quebrada.

O app abre a tela errada

Sintoma: a verificação é bem-sucedida, mas o app chega à página inicial ou a conteúdo incompatível. Causa provável: a associação do SO está correta, enquanto o mapeamento de rotas do app está incompleto. Correção: mapeie o caminho e os parâmetros recebidos para a tela correspondente, preserve um fallback web seguro e compare o conteúdo do app com a página web que forneceu o snippet de pesquisa.

Deep links de apps — resumo rápido

Antes vs. agora

Arquivos de verificação

Fatos rápidos

• Deep links mudam o roteamento depois do clique, não a indexação nem o ranqueamento.
• Crie deep link apenas para telas de app com conteúdo correspondente ao da página web.
• Android precisa de filtros de intent android:autoVerify="true".
• iOS precisa da autorização Associated Domains.
• Meça com o filtro de aparência Android app do GSC.
• Bing: não há orientação equivalente atual; os padrões continuam funcionando no Edge.

Confira seus arquivos de associação

Deep links falham silenciosamente, portanto o passo de depuração mais rápido é confirmar que os dois arquivos de verificação existem, retornam 200 e servem o content-type correto.

macOS / Linux — busque e inspecione os arquivos

# 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 do Browser DevTools — verificação rápida de alcançabilidade

// 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 — verificação em um clique no site atual

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 um arquivo retornar um erro de página, redirecionar ou servir o content-type errado, o SO não verificará a associação — e os links voltarão silenciosamente ao navegador em vez de abrir o app.

Ferramentas para configurar e depurar deep links

• Android Studio — App Links Assistant — gera filtros de intent, cria e valida seu Digital Asset Links (assetlinks.json) e testa o tratamento de links.
• Google Play Console — página Deep Links — exibe o status dos deep links e da verificação do app.
• Validação de Digital Asset Links — verifica se o assetlinks.json publicado associa corretamente seu domínio e o pacote/fingerprint do app.
• Depuração de Universal Links da Apple — orientação da Apple para diagnosticar por que um Universal Link abre o navegador em vez do app (content-type do arquivo de associação, autorização e cache).
• Google Search Console — relatório de desempenho — o filtro de aparência Android app mostra impressões, cliques, CTR e posição dos resultados em que o deep link Android do seu app apareceu.
• curl / DevTools / bookmarklet — a primeira verificação mais rápida de que os dois arquivos de associação retornam 200 com o content-type correto e sem redirecionamentos (veja a aba Scripts).

Recursos que valem seu tempo

Meus textos

• A indexação mobile-first passa a usar somente dispositivos móveis — o conceito relacionado, mas distinto, de qual versão da página o Google indexa (não o confunda com deep linking de apps).
• Guia de SEO técnico para iniciantes — onde temas móveis e adjacentes a apps entram no quadro maior de rastreamento, indexação e ranqueamento.

Minha palestra

• Como a busca funciona (SlideShare) — minha explicação de rastreamento, renderização, indexação e ranqueamento, incluindo como o Googlebot rastreia como smartphone. (Aviso permanente: “Esta é minha compreensão dos sistemas… não será 100% completa ou precisa”.)

Do setor

• Deep links de apps: conectando seu site e seu app (Google) — a orientação atual e autorizada, fonte das afirmações sobre ausência de efeito no ranqueamento e paridade de conteúdo.
• Firebase App Indexing (Google/Firebase) — o aviso de descontinuação ativo que aponta para App Links / Universal Links.
• Sobre deep links (Android) — App Links e o modelo de verificação.
• Verificar Android App Links (Android) — o requisito assetlinks.json.
• Permitir que apps e sites apontem para seu conteúdo (Apple) — Universal Links e apple-app-site-association.
• Google App Indexing Becomes Firebase App Indexing (Search Engine Land) — cobertura de Barry Schwartz sobre o rebranding de 2016 no Google I/O.

Estatísticas dignas de citação

• Deep links de apps não mudam indexação nem ranqueamento — a declaração do próprio Google em maio de 2025: a Pesquisa “continues to use the content of your web pages for indexing and ranking” (tradução) «continua usando o conteúdo das suas páginas web para indexação e ranqueamento». O fato mais importante e mais mal relatado sobre o tema. Fonte
• Firebase App Indexing está deprecated — o app Google Search para Android “no longer uses local content indexed via Firebase App Indexing” (tradução) «não usa mais conteúdo local indexado pelo Firebase App Indexing», segundo a documentação ativa do Firebase. A transição ocorreu em 2021 (presente em um arquivo de outubro de 2022, ausente do de outubro de 2020). Fonte
• App Links compatível com Android 6+ — o Google chama App Links de “a recommended approach” (tradução) «uma abordagem recomendada» para deep links para seu próprio site, verificados por meio do arquivo Digital Asset Links em /.well-known/assetlinks.json. Fonte

Prompts para QA de deep links de apps

Revise os dados de associação do 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]

Crie uma matriz de teste de paridade de conteúdo

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]

Valide uma versão de deep links de apps

Teste os arquivos de associação públicos

Teste a executar: busque os dois endpoints de associação conhecidos sem cookies nem autenticação e valide o JSON. Resultado esperado: as respostas bem-sucedidas contêm os identificadores do app de produção, fingerprints e regras de caminho pretendidas. Interpretação da falha: os dispositivos não conseguem verificar a relação site-app. Janela de monitoramento: imediatamente após a publicação e depois de mudanças de certificado. Gatilho de rollback: qualquer arquivo apresenta erro, redireciona inesperadamente ou autoriza a identidade de produção errada.

Teste o comportamento instalado e não instalado

Teste a executar: toque em links HTTPS representativos em dispositivos Android e iOS reais com o app instalado e depois sem ele. Resultado esperado: usuários com o app chegam à tela correspondente; os demais chegam à mesma URL web. Interpretação da falha: a verificação, o roteamento ou o comportamento de fallback está incompleto. Janela de monitoramento: imediata em toda versão do app. Gatilho de rollback: os links terminam sem destino, abrem a tela errada ou não conseguem voltar para a web.

Teste a paridade de conteúdo

Teste a executar: compare o conteúdo pesquisável de cada resultado web com seu destino no app. Resultado esperado: o assunto e o conteúdo substantivo correspondem, mesmo que o layout seja diferente. Interpretação da falha: o deep link pode enganar usuários porque a Pesquisa indexa a página web. Janela de monitoramento: antes de mapear uma rota e depois de mudanças importantes no template de conteúdo. Gatilho de rollback: o destino no app já não atende ao título e ao snippet do resultado web.

Meça a saúde dos deep links de apps

Aparência de pesquisa do app Android

Métrica: impressões e cliques para a aparência de pesquisa Android App. O que informa: com que frequência o Google exibiu resultados com tratamento de deep link Android e quanto tráfego os usou. Como obter: desempenho do Search Console, filtrado pela aparência de pesquisa Android App. Benchmark / faixa realista: estabeleça uma linha de base por consulta e página; a elegibilidade depende da adoção do app e de resultados relevantes, portanto não há um alvo universal. Cadência: mensal, com anotações de versões.

Taxa de abertura de rota bem-sucedida

Métrica: aberturas válidas de deep link divididas pelas tentativas de app link. O que informa: se links verificados chegam à tela pretendida, em vez de cair em fallback ou erro. Como obter: eventos de analytics do app no recebimento do link e na renderização do destino, excluindo parâmetros de URL sensíveis. Benchmark / faixa realista: use sua própria linha de base de plataforma e versão; investigue regressão sustentada depois de uma versão. Cadência: semanal e em cada versão do app.

Contagem de exceções de paridade

Métrica: URLs web mapeadas cujo destino no app já não contém conteúdo equivalente. O que informa: se o roteamento ainda atende ao requisito central de paridade de conteúdo. Como obter: inventário mantido de URL para tela mais QA de versão. Benchmark / faixa realista: zero exceções conhecidas é o alvo apropriado. Cadência: em cada versão e depois de mudanças importantes na arquitetura de informação web ou do app.

Teste seus conhecimentos: App Indexing

Cinco perguntas rápidas sobre o que era o App Indexing, o que o substituiu e o que ele realmente faz para SEO. Escolha uma resposta para cada uma e depois confira.

Registro de alterações