Indexación de aplicaciones (enlaces profundos de apps para la búsqueda)

TL;DR — «App Indexing» era una antigua función de Google que extraía contenido de tu app y lo mostraba en los resultados de búsqueda. Google la cerró. Lo que se utiliza ahora se llama enlaces profundos de apps: enlaces que, si ya tienes instalada una app, abren un resultado de búsqueda dentro de la app en vez de hacerlo en el navegador del teléfono. Lo importante es que esto no te ayuda a posicionar mejor. Google sigue posicionando tu sitio web; los enlaces profundos solo cambian dónde aterriza el toque.

Qué era «App Indexing»

Hace años, Google permitía conectar el sitio web con la app móvil nativa para mostrar en los resultados de búsqueda el contenido de la app y enlaces que llevaran directamente a ella. Ese sistema se llamaba App Indexing (y más tarde Firebase App Indexing). Si buscabas algo y tenías instalada la app correspondiente, Google podía enviarte a la app en lugar de a una página web.

Si estás leyendo esto porque encontraste «App Indexing» en una lista de comprobación SEO antigua, en la documentación de un desarrollador o en la configuración de un plugin, esta es la respuesta breve: está obsoleto. Google lo desactivó. No necesitas configurarlo y, si un tutorial te lo indica, ese tutorial está desactualizado.

Qué lo sustituyó

La versión moderna de «abrir mi app desde un resultado de búsqueda» se llama enlaces profundos de apps, y cada plataforma tiene su propio nombre:

• Android los llama App Links.
• iOS los llama Universal Links.

Ambos hacen el mismo trabajo: cuando alguien toca un enlace a tu sitio —desde un resultado de Google, otro sitio web o una app— y ya tiene instalada tu app, el teléfono abre ese contenido dentro de la app. Si no tiene la app, el mismo enlace se abre en el navegador como de costumbre.

El error más habitual

Los enlaces profundos de apps no ayudan a posicionar. Este es el mito que hay que desaprender. Algunos artículos antiguos afirman que «indexar tu app» mejora el posicionamiento. Google ha dicho claramente que no: Search sigue utilizando el contenido de tu página web para decidir tu posición. Los enlaces profundos solo cambian la experiencia después de que alguien haga clic, para quienes tienen tu app. Son una función de comodidad, no un truco de posicionamiento.

Si los configuras, hay una regla real: la pantalla de la app a la que enlazas debe mostrar el mismo contenido que la página web. Google crea el fragmento de búsqueda a partir de tu página web, así que, si la app muestra algo diferente, has inducido a error a la persona que hizo clic.

¿Quieres conocer toda la historia, los archivos y pasos exactos para Android e iOS y cómo medirlo en Search Console? Cambia a la pestaña Advanced.

TL;DR — Google App Indexing (2013) → Firebase App Indexing (2016, además de un experimento breve de «app streaming») → obsoleto hacia 2021. Su sucesor son los enlaces profundos de apps: Android App Links (verificados con un archivo Digital Asset Links en /.well-known/assetlinks.json más filtros de intent android:autoVerify) y Universal Links de iOS (verificados con un archivo apple-app-site-association más el entitlement Associated Domains). Según la guía de Google de mayo de 2025, los enlaces profundos no cambian la indexación ni el posicionamiento —Search sigue posicionando la página web— y el destino del enlace profundo debe corresponder al contenido de la URL web. Mide el comportamiento de los enlaces de apps con analítica de la plataforma y de la aplicación, en lugar de suponer que existe un informe específico en Search Console.

Tres épocas, un nombre confuso

La razón por la que «App Indexing» genera tanta confusión es que la misma idea tuvo tres nombres distintos durante una década, y la última transición fue una obsolescencia que muchos contenidos antiguos nunca llegaron a reflejar.

2013–2016 — Google App Indexing. En octubre de 2013 Google anunció que “Googlebot can now index content in your Android app,” (traducción) «Googlebot ya puede indexar contenido de tu app Android», y que mostraría enlaces profundos a la app “straight in our search results when we think they’re relevant… and if the user has the app installed.” (traducción) «directamente en nuestros resultados de búsqueda cuando pensemos que son relevantes… y si la persona tiene instalada la app». Se declaraba el contenido de la app mediante el sitemap existente y Webmaster Tools. Era Google rastreando dentro de las apps, igual que rastrea las páginas web.

2016–~2021 — Firebase App Indexing. Tras la adquisición de Firebase por parte de Google en 2014, App Indexing pasó a llamarse Firebase App Indexing alrededor de Google I/O 2016. Añadió compatibilidad con iOS y, durante un tiempo, un experimento llamado app streaming: un botón «Try Now» que permitía ejecutar durante unos minutos en el navegador una app no instalada, directamente desde un resultado de búsqueda. App streaming fue un experimento limitado de 2015–2016 y desapareció hace mucho; no diseñes nada basándote en él.

~2021–presente — obsoleto. La interfaz AppIndexApi aparece como obsoleta en la documentación de referencia de Android de Google. La documentación actual de Firebase indica que Firebase App Indexing “is no longer the recommended way of indexing content for display as suggested results in Google Search App,” (traducción) «ya no es la forma recomendada de indexar contenido para mostrarlo como resultados sugeridos en Google Search App», y advierte explícitamente que “the Google Search App for Android no longer uses local content indexed via Firebase App Indexing to provide results to users.” (traducción) «la aplicación Google Search para Android ya no utiliza contenido local indexado mediante Firebase App Indexing para proporcionar resultados a los usuarios». Firebase te dirige ahora a App Links y Universal Links como ruta recomendada. (El cambio se produjo en 2021: el aviso de obsolescencia aparece en una instantánea archivada de octubre de 2022, pero no en la de octubre de 2020).

Qué sustituyó a App Indexing: enlaces profundos de apps

Los enlaces profundos son, en palabras de Google, “special URIs that take users beyond your mobile app’s homepage, leading them directly to specific in-app content.” (traducción) «URI especiales que llevan a las personas más allá de la página de inicio de la app móvil, directamente a contenido específico dentro de la app». El cambio de modelo mental respecto al sistema antiguo es clave: esto es verificación y enrutamiento, gestionados en el nivel del sistema operativo y del navegador, no una canalización de indexación ejecutada por Google. Aquí no se «envía nada a un índice».

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

Android App Links son, según 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.” (traducción) «una capacidad avanzada de enlaces profundos que verifica los enlaces profundos a tu propio sitio mediante una asociación de confianza entre tu app y tu sitio. Una vez verificados, los enlaces profundos a tu sitio pueden abrir inmediatamente el contenido correspondiente en tu app, sin que la persona tenga que seleccionar tu app en un diálogo de desambiguación». App Links es compatible con Android 6 y posteriores, y Google lo considera «un enfoque recomendado» para los enlaces profundos a tu propio sitio.

El intercambio de verificación utiliza un archivo Digital Asset Links. Cuando colocas android:autoVerify="true" en un filtro de intent y la app está instalada, “Android queries the corresponding websites for the Digital Asset Links file at https://hostname/.well-known/assetlinks.json.” (traducción) «Android consulta los sitios web correspondientes en busca del archivo Digital Asset Links en https://hostname/.well-known/assetlinks.json». Ese archivo JSON enumera qué paquete de app y qué huella del certificado de firma tienen permiso para gestionar los enlaces de tu dominio. Android 15 añade Dynamic App Links, que permite ajustar el comportamiento de coincidencia de URL sin publicar una nueva versión de la app.

Aquí importan dos límites de versión y firma. Primero, Dynamic App Links amplía la asociación subyacente del manifiesto en lugar de sustituirla: en versiones de Android anteriores a 15, la verificación sigue ejecutándose únicamente con la coincidencia estándar entre el manifiesto y assetlinks.json. Segundo, la verificación falla por completo, no de forma parcial, si la huella del certificado de firma incluida en assetlinks.json no coincide exactamente con la identidad de firma real de la compilación instalada: una compilación de depuración firmada con otra clave nunca se verificará, aunque todos los demás campos sean correctos.

Conviene mantener clara esta distinción: un enlace profundo básico de Android utiliza filtros de intent, pero puede activar el diálogo de desambiguación «¿con qué app quieres abrirlo?». App Links añade la verificación de Digital Asset Links para que un dominio verificado se abra directamente en tu app, sin diálogo.

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

El equivalente de Apple son los Universal Links. Apple explica: “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.” (traducción) «Cuando las personas tocan o hacen clic en un enlace universal, el sistema redirige el enlace directamente a tu app sin pasar por el navegador web predeterminado de la persona ni por tu sitio web… como los enlaces universales son enlaces HTTP o HTTPS estándar, una URL funciona tanto para tu sitio web como para tu app. Si la persona no ha instalado tu app, el sistema abre la URL en su navegador web predeterminado».

El archivo de verificación es apple-app-site-association, alojado en tu 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.” (traducción) «Cuando alguien instala tu app, el sistema comprueba un archivo almacenado en tu servidor web para verificar que tu sitio permite que tu app abra URL en su nombre». En la app necesitas el entitlement Associated Domains, cuyos dominios deben coincidir con los del archivo. Es el mismo principio que en Android: un intercambio de confianza entre el sitio y la app, comprobado por el dispositivo, no una señal de posicionamiento.

Un archivo apple-app-site-association válido y un entitlement correctamente coincidente tampoco garantizan que cada toque abra la app. Apple documenta casos reales en los que un Universal Link sigue abriendo Safari pese a que la asociación funciona: por ejemplo, cuando el enlace se toca dentro del propio Safari mientras ya se está navegando por el mismo dominio, o cuando la persona eligió anteriormente seguir abriendo los enlaces de ese dominio en el navegador. Y cuando la app no está instalada o la asociación no coincide, un enlace HTTP(S) estándar debe abrirse en el navegador en lugar de terminar en un esquema personalizado roto: ese fallback es el sistema funcionando como debe, no un error que haya que perseguir.

Las dos plataformas son compatibles con Google Search como destinos de enlaces profundos.

¿Los enlaces profundos de apps afectan al posicionamiento? (No; aquí está la cita exacta)

Esta es la corrección más importante de todo el tema, porque las páginas sobre posicionamiento todavía se equivocan. Encontrarás artículos que afirman cosas como «App Indexing influirá en el posicionamiento… tengas o no instalada la app» o «Google utilizará el contenido de tu app como señal de posicionamiento». Esas afirmaciones son falsas, y la publicación de Google de mayo de 2025 lo dice directamente:

“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.” (traducción) «Añadir enlaces profundos a tu sitio conecta las URL del sitio con las páginas correspondientes de la app. No cambia cómo Google Search muestra tu contenido; Search sigue utilizando el contenido de tus páginas web para indexar y posicionar. Los enlaces profundos permiten que las personas pasen directamente de los resultados de Search a la página correspondiente de la app (si está instalada), lo que produce una mejor experiencia de usuario».

Léelo con atención: lo que se indexa y posiciona es la página web. El enlace profundo es una capa de enrutamiento posterior al clic que solo se activa para quienes ya tienen instalada la app. Es una mejora de UX, no una palanca de visibilidad. Si alguien te dice que configurar assetlinks.json mejorará tu posicionamiento, se equivoca.

El único requisito real: paridad de contenido

Solo hay una regla sustantiva, y trata de la honestidad con la persona usuaria. 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.” (traducción) «Como Search utiliza el contenido de tu página web para indexar y posicionar, solo debes añadir enlaces profundos cuando la página de la app contenga el mismo contenido que la página web correspondiente. De lo contrario, el título y el fragmento mostrados para la página en Google Search podrían inducir a error sobre el contenido que verán después de hacer clic. Las diferencias de diseño u otras diferencias de UX entre las páginas de la app y las páginas web correspondientes están bien, siempre que el contenido coincida.»

Por tanto: una pantalla nativa, más bonita y con una distribución distinta está bien. Una pantalla cuyo contenido sea diferente al de la página web no, porque el fragmento que la persona tocó se construyó a partir de la página web y ahora ha aterrizado en un lugar que no coincide. La paridad se refiere al contenido, no al aspecto.

Cómo implementarlo hoy

Android: utiliza App Links. Asocia la app con el sitio web en el manifiesto de la app (filtros de intent con android:autoVerify="true") y publica /.well-known/assetlinks.json en tu sitio con el nombre del paquete y la huella del certificado de firma de la app. Android verifica la asociación al instalar. El App Links Assistant de Android Studio y la página Deep Links de Play Console ayudan a generar y validar la configuración.

iOS: implementa Universal Links. Publica un archivo apple-app-site-association en tu servidor web que describa qué rutas corresponden a tu app y añade el entitlement Associated Domains en la app para los dominios coincidentes. La guía de depuración de Universal Links de Apple explica fallos habituales (tipo de contenido incorrecto del archivo, entitlement ausente o asociación en caché).

Ninguno de los dos archivos se rastrea en un «índice de búsqueda» como sugería App Indexing: son intercambios de confianza que comprueba el dispositivo. Si los configuras mal, los enlaces vuelven al navegador; si los configuras bien, las personas que tienen instalada la app entran en ella.

Comprobación mínima de los archivos de asociación

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

Los dos endpoints deben devolver 200 sin redireccionar y exponer la respuesta JSON esperada. La lente Scripts contiene las comprobaciones ampliadas de tipo de contenido, redirecciones, PowerShell, DevTools y bookmarklet.

Cómo medirlo: el filtro de app Android de Search Console

Google expone de forma nativa el rendimiento de los enlaces profundos de apps: «Search Console incluye el rendimiento de los enlaces profundos de apps de tu sitio para Android. En el informe de rendimiento puedes utilizar el filtro de apariencia de búsqueda Android App para ver cuándo se encuentran y muestran a las personas tus enlaces profundos de Android». Eso proporciona clics, impresiones, CTR y posición de los resultados en los que apareció el enlace profundo Android: la forma concreta y actual de comprobar si esto sirve para algo. (El filtro se añadió en 2019 y sigue siendo la herramienta vigente según la publicación de Google de 2025).

Pero separa las dos tareas. El filtro de Search Console es un informe de tráfico/apariencia: solo para Android, depende de que Google muestre realmente el tratamiento de enlace profundo para una consulta concreta y no demuestra por sí mismo que algo esté indexado o posicione. Confirmar que un enlace profundo funciona técnicamente es otra tarea: recupera los archivos de asociación y prueba el recorrido del toque en dispositivos reales (consulta las pestañas Scripts y Validation Tests). No interpretes un informe silencioso de Search Console como prueba de que tu configuración está rota, ni interpretes sus clics como una señal SEO: informa del volumen de enrutamiento, no del posicionamiento.

Bing y los enlaces profundos de apps

No des por supuesta la paridad entre Google y Bing. Bing ejecutó desde abril de 2014 un programa de «app linking» centrado en Windows, dirigido a Windows 8,1 y Windows Phone, pero esas páginas ya no existen (la URL de desarrollo devuelve 404 y las entradas del blog redirigen a la página de inicio genérica); además, Windows Phone se descontinuó. No existe un equivalente actual publicado por Bing de la guía de Google de 2025 sobre enlaces profundos de apps. En la práctica, App Links y Universal Links siguen funcionando en Bing/Edge móvil porque son estándares del sistema operativo y del navegador, no algo que un buscador deba adoptar; por eso se implementan igual. Simplemente no hay un documento de Bing que citar.

Cosas antiguas que todavía verás por ahí

Un par de técnicas cercanas generan confusión; nómbralas y sigue adelante:

• Marcado schema.org potentialAction / ViewAction con un destino de enlace profundo android-app://. Es una técnica antigua vinculada a la época de App Indexing. Todavía puedes encontrarla en bases de código y en el vocabulario de acciones de schema.org, pero la recomendación actual de Google es configurar App Links / Universal Links, no este marcado. Trátalo como algo que «todavía puedes ver», no como una recomendación.
• Firebase Dynamic Links es un producto distinto y obsoleto por separado de Firebase: un servicio de acortamiento de URL y enlaces profundos diferidos para atribución de marketing, no el sistema de contenido de App Indexing. También se está retirando, y su guía de migración dirige a App Links y Universal Links. No confundas ambas obsolescencias.

El modelo claro que debes conservar es: (1) el sistema antiguo de rastreo y streaming de Google App Indexing / Firebase App Indexing = muerto; (2) los enlaces profundos App Links / Universal Links = vigentes, solo de enrutamiento/UX y sin efecto en el posicionamiento; (3) el antiguo programa de enlaces de apps de Bing para Windows = también muerto y sin sustituto documentado.

Resumen de IA

Una síntesis de la versión Avanzada:

• App Indexing está obsoleto. Google App Indexing (2013) → Firebase App Indexing (2016) → obsoleto hacia 2021. AppIndexApi aparece como obsoleto en la documentación de Google y la aplicación Google Search ya no utiliza contenido de Firebase App Indexing.
• Qué lo sustituyó: enlaces profundos de apps — Android App Links (verificados mediante un archivo Digital Asset Links en /.well-known/assetlinks.json más filtros de intent android:autoVerify) y Universal Links de iOS (verificados mediante apple-app-site-association más el entitlement Associated Domains). Son verificación y enrutamiento a nivel del sistema operativo y del navegador, no un índice gestionado por Google.
• Los enlaces profundos NO afectan al posicionamiento. Según la publicación de Google de mayo 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.” (traducción) «no cambian cómo Google Search muestra tu contenido; Search sigue utilizando el contenido de tus páginas web para indexar y posicionar». Solo dirigen a las personas que tienen la app instalada hacia ella después del clic.
• La única regla real es la paridad de contenido: enlaza profundamente solo una pantalla de la app que muestre el mismo contenido que la página web (las diferencias de diseño/UX están bien).
• Mídelo con el filtro de apariencia de búsqueda Android app de Search Console, pero recuerda que es un informe de tráfico, no una prueba de que la asociación técnica funcione ni de que algo posicione de otra manera; verifica la asociación con pruebas en archivos y dispositivos.
• Ninguna plataforma garantiza que cada toque verificado abra la app. La verificación de Android falla por completo si no coincide el certificado de firma (Dynamic App Links en Android 15 amplía la coincidencia del manifiesto, no la sustituye); iOS documenta casos legítimos —navegación de Safari en el mismo dominio y elección previa de la persona— en los que un Universal Link sigue abriendo el navegador pese a una asociación funcional.
• Bing no tiene una guía equivalente actual; su programa de la época de Windows está muerto, aunque App Links y Universal Links siguen funcionando en Edge porque son estándares del sistema operativo.
• No confundas App Indexing con Firebase Dynamic Links (un producto distinto y obsoleto por separado), ni trates el marcado potentialAction/ViewAction como una práctica recomendada actual.

Documentación oficial

Documentación de fuentes primarias de Google, Android y Apple.

Google: guía actual

• Enlaces profundos de apps: conectar tu sitio web y tu app (2 de mayo de 2025) — la explicación autorizada actual: qué hacen los enlaces profundos, la ausencia de efecto en el posicionamiento, la paridad de contenido y el filtro de Search Console.
• Firebase App Indexing — la página activa que contiene el aviso de obsolescencia y dirige a App Links / Universal Links.

Google: historia (para entender qué quedó obsoleto)

• Indexing apps just like websites (31 de octubre de 2013) — el anuncio original de App Indexing.

Android

• About deep links — enlaces profundos, App Links y el modelo de verificación (actualizado el 18 de junio de 2026).
• Verify Android App Links — android:autoVerify y el requisito de Digital Asset Links / assetlinks.json.

Apple

• Permitir que las apps y los sitios web enlacen con tu contenido — descripción general de Universal Links y el modelo de verificación mediante archivo del servidor.
• Admitir dominios asociados — el archivo apple-app-site-association y el entitlement Associated Domains.

Estándar del sector (no específico de Google)

• ViewAction / Actions (schema.org) — vocabulario heredado potentialAction/ViewAction; contexto útil, no una recomendación actual de Google.

Citas de la fuente

Declaraciones registradas de Google, Android y Apple. Cada enlace de Google o Android es un enlace profundo que salta al pasaje citado en la página de origen.

Google: el anuncio original de 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.” (traducción) «Al igual que rastrea e indexa sitios web, Googlebot ahora puede indexar contenido de tu app Android… Si tanto la página web como el contenido de la app se indexan correctamente, Google intentará mostrar enlaces profundos a tu app directamente en nuestros resultados de búsqueda cuando pensemos que son relevantes para la consulta de la persona y si tiene instalada la app». — Lawrence Chang, Product Manager de Google. Ir a la cita

Google: Firebase App Indexing está obsoleto (documentación activa)

• “Firebase App Indexing is no longer the recommended way of indexing content for display as suggested results in Google Search App.” (traducción) «Firebase App Indexing ya no es la forma recomendada de indexar contenido para mostrarlo como resultados sugeridos en Google Search App». Ir a la cita

Google: los enlaces profundos no cambian el posicionamiento (mayo 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.” (traducción) «No cambia cómo Google Search muestra tu contenido; Search sigue utilizando el contenido de tus páginas web para indexar y posicionar». — John Mueller (Google Search Relations) y Sabs (Android Developer Relations). Ir a la cita
• “You should only add deep links in cases where the app page contains the same content as the corresponding web page.” (traducción) «Solo debes añadir enlaces profundos cuando la página de la app contenga el mismo contenido que la página web correspondiente». Ir a la cita

Android: App Links y el archivo de verificación

• “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.” (traducción) «Android App Links es una capacidad avanzada de enlaces profundos que verifica los enlaces profundos a tu propio sitio mediante una asociación de confianza entre tu app y tu sitio». — Android Developers. Ir a la cita
• “Android queries the corresponding websites for the Digital Asset Links file at https://hostname/.well-known/assetlinks.json.” (traducción) «Android consulta los sitios web correspondientes en busca del archivo Digital Asset Links en https://hostname/.well-known/assetlinks.json». Ir a la cita

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.” (traducción) «Cuando las personas tocan o hacen clic en un enlace universal, el sistema redirige el enlace directamente a tu app sin pasar por el navegador web predeterminado de la persona ni por tu sitio web… Si la persona no ha instalado tu app, el sistema abre la URL en su navegador web predeterminado». — Documentación para desarrolladores de Apple, «Permitir que las apps y los sitios web enlacen con tu contenido».

¿Deberías configurar enlaces profundos de apps?

Un recorrido rápido por la pregunta «¿realmente lo necesito?», porque para muchos sitios la respuesta honesta es «no».

1. ¿Tienes una app móvil nativa que refleje el contenido de tu sitio web?

• No hay app → Detente. No hay nada que enlazar profundamente. App Indexing y los enlaces profundos no son relevantes para ti. (Y si encontraste «App Indexing» en una lista de comprobación, elimina esa línea: está obsoleto).
• Sí → continúa.

2. ¿Lo haces para mejorar el posicionamiento?

• Sí → Detente y vuelve a leer. Los enlaces profundos no afectan a la indexación ni al posicionamiento. Si el objetivo es la visibilidad SEO, invierte en la página web móvil, no en la infraestructura de enlaces profundos.
• No; quiero dirigir a las personas con la app instalada a la aplicación → continúa.

3. ¿La pantalla de la app muestra el mismo contenido que la página web correspondiente?

• No (contenido diferente) → No enlaces profundamente esa URL. La discrepancia induce a error porque el fragmento se creó a partir de la página web. Corrige primero la paridad (las diferencias de diseño/UX están bien; las de contenido no).
• Sí → continúa.

4. ¿Qué plataforma o plataformas?

• Android → App Links: filtros de intent android:autoVerify y un archivo Digital Asset Links en /.well-known/assetlinks.json.
• iOS → Universal Links: apple-app-site-association en tu servidor y el entitlement Associated Domains.
• Ambas → configura las dos; son independientes.

5. ¿Cómo sabrás que funciona?

• Comprueba el filtro de apariencia de búsqueda Android app de Search Console para Android.
• Prueba el recorrido real del toque en dispositivos y valida los archivos de asociación (App Links Assistant en Android y la depuración de Universal Links de Apple en iOS).

Regla práctica: los enlaces profundos son una mejora de UX y enrutamiento para sitios con una app real cuyo contenido coincide; no son un proyecto de posicionamiento SEO ni algo que añadir solo porque una guía antigua mencionara «App Indexing».

Lista de comprobación para configurar enlaces profundos de apps

Solo es relevante si tienes una app nativa que refleja el contenido de tu sitio web:

• Confirmaste que no esperas una mejora de posicionamiento: los enlaces profundos cambian el enrutamiento, no el posicionamiento.
• Verificaste la paridad de contenido: cada pantalla de app enlazada profundamente muestra el mismo contenido que su página web correspondiente (las diferencias de diseño/UX están bien).
• Android: los filtros de intent utilizan android:autoVerify="true" para tu dominio.
• Android: publicaste /.well-known/assetlinks.json, se sirve mediante HTTPS con el tipo de contenido correcto e incluye el nombre del paquete y la huella del certificado de firma de tu app.
• iOS: publicaste apple-app-site-association en tu servidor (tipo de contenido correcto y sin redirecciones), con los patrones de ruta adecuados.
• iOS: añadiste el entitlement Associated Domains en la app, con los mismos dominios que el archivo de asociación.
• Probaste recorridos reales del toque en dispositivos físicos Android e iOS (con la app instalada y sin instalar).
• Revisaste el filtro de apariencia Android app de Search Console para comprobar impresiones y clics una vez publicado.
• Eliminaste las referencias obsoletas: etiquetas de sitemap de App Indexing antiguas, llamadas al SDK de Firebase App Indexing o marcado potentialAction/android-app:// que utilizaras como mecanismo principal.

Antipatrones que debes evitar

• Tratar App Indexing como algo vigente. AppIndexApi está obsoleto y la aplicación Google Search ya no utiliza contenido de Firebase App Indexing. Si una guía, plugin o lista de comprobación te dice que «actives App Indexing», está desactualizada.
• Esperar un aumento del posicionamiento. El mito más repetido en las páginas antiguas sobre posicionamiento es «indexar tu app influye en el posicionamiento». Google dice lo contrario: Search posiciona la página web y los enlaces profundos no cambian eso.
• Enlazar profundamente a contenido que no coincide. Envías a una persona que tocó un fragmento de página web a una pantalla de app con contenido diferente. Google advierte expresamente de que eso induce a error. La paridad es de contenido, no de aspecto.
• Perseguir «app streaming». La función «Try Now» para previsualizar una app no instalada fue un experimento de 2015–2016 y desapareció. No diseñes nada basándote en ella.
• Confundir Firebase App Indexing con Firebase Dynamic Links. Son productos diferentes y ambos están obsoletos, pero resuelven problemas distintos (indexación de contenido frente a acortamiento de URL/atribución). Los dos dirigen ahora a App Links / Universal Links.
• Dar por supuesta la paridad con Bing. El antiguo programa de enlaces de apps de Bing para la era Windows está muerto y no tiene sustituto documentado. App Links y Universal Links siguen funcionando en Edge porque son estándares del sistema operativo, pero no existe una guía de Bing que seguir.
• Saltarse la verificación y preguntarse por qué «no funciona». Un tipo de contenido incorrecto, una redirección en el archivo de asociación o un entitlement ausente hacen que vuelvas silenciosamente al navegador. Los archivos son un intercambio estricto, no una sugerencia.

Fallos habituales de los enlaces profundos de apps

Un enlace web sigue abriéndose en el navegador en Android

Síntoma: una app instalada no reclama una URL HTTPS coincidente. Causa probable: la verificación del dominio falló porque el host del manifiesto, el nombre del paquete, la huella del certificado de firma o la respuesta de assetlinks.json no coinciden. Solución: comprueba la identidad de firma de la compilación instalada, recupera el archivo de asociación directamente y vuelve a ejecutar la verificación de enlaces de Android antes de probar otra vez el toque.

Un Universal Link abre Safari en lugar de la app de iOS

Síntoma: la misma URL HTTPS funciona en la web, pero evita la app instalada. Causa probable: el entitlement Associated Domains o las rutas de apple-app-site-association no autorizan la URL; pero comprueba primero los casos documentados que no son fallos: la guía de Apple describe los enlaces tocados dentro de Safari en el mismo dominio, o un dominio que la persona eligió anteriormente seguir abriendo en el navegador, como aperturas esperadas en el navegador y no como fallos de verificación. Solución: confirma el entitlement del dominio, la disponibilidad del archivo y las reglas de ruta; después vuelve a probar tras reinstalar o actualizar el estado de asociación del dispositivo y descarta el comportamiento del mismo dominio o de una elección previa antes de asumir que la asociación está rota.

La app abre la pantalla equivocada

Síntoma: la verificación funciona, pero la app llega a una página de inicio o a contenido que no coincide. Causa probable: la asociación del sistema operativo es correcta, pero el mapeo de rutas de la app está incompleto. Solución: asigna la ruta y sus parámetros a la pantalla correspondiente, conserva un fallback web seguro y compara el contenido de la app con la página web que proporcionó el fragmento de búsqueda.

Enlaces profundos de apps: hoja resumen

Antes y ahora

Archivos de verificación

Datos rápidos

• Los enlaces profundos cambian el enrutamiento después del clic, no la indexación ni el posicionamiento.
• Enlaza profundamente solo pantallas de la app cuyo contenido coincida con el de la página web.
• Android necesita filtros de intent android:autoVerify="true".
• iOS necesita el entitlement Associated Domains.
• Mídelo con el filtro de apariencia Android app de GSC.
• Bing: no hay una guía equivalente actual; los estándares siguen funcionando en Edge.

Comprueba tus archivos de asociación

Los enlaces profundos fallan silenciosamente, así que el paso de depuración más rápido es confirmar que los dos archivos de verificación existen, devuelven 200 y sirven el tipo de contenido correcto.

macOS / Linux: recupera e inspecciona los archivos

# 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

Consola de Browser DevTools: comprobación rápida de accesibilidad

// 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: comprobación con un clic en el sitio actual

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 archivo no se encuentra, redirige o sirve un tipo de contenido incorrecto, el sistema operativo no verificará la asociación y los enlaces volverán silenciosamente al navegador en lugar de abrir la app.

Herramientas para configurar y depurar enlaces profundos

• Android Studio — App Links Assistant: genera filtros de intent, crea y valida tus Digital Asset Links (assetlinks.json) y prueba la gestión de enlaces.
• Google Play Console — página Deep Links: muestra el estado de los enlaces profundos y su verificación.
• Validación de Digital Asset Links: verifica que tu assetlinks.json publicado asocia correctamente el dominio con el paquete y la huella de la app.
• Depuración de Universal Links de Apple: guía de Apple para diagnosticar por qué un Universal Link abre el navegador en lugar de la app (tipo de contenido del archivo de asociación, entitlement y caché).
• Google Search Console — informe de rendimiento: el filtro de apariencia Android app muestra impresiones, clics, CTR y posición de los resultados en los que apareció tu enlace profundo de Android.
• curl / DevTools / bookmarklet: la comprobación inicial más rápida de que los dos archivos de asociación devuelven 200, tienen el tipo de contenido correcto y no redirigen (consulta la pestaña Scripts).

Recursos que merecen tu tiempo

Lo que he escrito

• La indexación mobile-first pasa a ser solo para móviles: concepto relacionado pero distinto sobre qué versión de una página indexa Google; no lo confundas con los enlaces profundos de apps.
• Guía de SEO técnico para principiantes: el lugar que ocupan los temas móviles y adyacentes a las apps dentro del panorama más amplio de rastreo, indexación y posicionamiento.

Mis charlas

• Cómo funciona la búsqueda (SlideShare): mi explicación del rastreo, renderizado, indexación y posicionamiento, incluido el rastreo de Googlebot como smartphone. (Aviso permanente: «Esta es mi comprensión de los sistemas… no va a ser 100 % completa ni exacta»).

Del sector

• Enlaces profundos de apps: cómo conectar tu sitio web y tu app (Google): guía autorizada actual y fuente de las afirmaciones sobre la ausencia de efecto en el posicionamiento y la paridad de contenido.
• Firebase App Indexing (Google/Firebase): aviso de obsolescencia activo que dirige a App Links / Universal Links.
• Sobre los enlaces profundos (Android): App Links y el modelo de verificación.
• Verificar Android App Links (Android): requisito de assetlinks.json.
• Permitir que las apps y los sitios web enlacen con tu contenido (Apple): Universal Links y apple-app-site-association.
• App Indexing se convierte en Firebase App Indexing (Search Engine Land): cobertura de Barry Schwartz del cambio de marca de 2016 en Google I/O.

Estadísticas que merece la pena citar

• Los enlaces profundos de apps no cambian la indexación ni el posicionamiento: la afirmación de Google de mayo de 2025 dice que Search «sigue utilizando el contenido de tus páginas web para indexar y posicionar». Es el hecho más importante y más tergiversado del tema. Fuente
• Firebase App Indexing está obsoleto: la aplicación Google Search para Android «ya no utiliza contenido local indexado mediante Firebase App Indexing», según la documentación activa de Firebase. La transición se produjo en 2021 (aparece en un archivo de octubre de 2022 y no en uno de octubre de 2020). Fuente
• App Links es compatible con Android 6+: Google lo considera «un enfoque recomendado» para enlaces profundos a tu propio sitio, verificado mediante el archivo Digital Asset Links en /.well-known/assetlinks.json. Fuente

Prompts para el control de calidad de enlaces profundos de apps

Revisa los datos de asociación de 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]

Crea una matriz de pruebas de paridad de contenido

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]

Valida una publicación de enlaces profundos de apps

Prueba los archivos de asociación públicos

Prueba que debes ejecutar: recupera ambos endpoints de asociación conocidos sin cookies ni autenticación y valida su JSON. Resultado esperado: las respuestas correctas contienen los identificadores de producción de la app, las huellas y las reglas de ruta previstas. Interpretación del fallo: los dispositivos no pueden verificar la relación entre el sitio y la app. Ventana de monitorización: inmediatamente después del despliegue y después de cambios de certificado. Disparador de rollback: cualquiera de los archivos falla, redirige inesperadamente o autoriza una identidad de producción incorrecta.

Prueba el comportamiento con y sin la app instalada

Prueba que debes ejecutar: toca enlaces HTTPS representativos en dispositivos Android e iOS reales con la app instalada y después sin ella. Resultado esperado: las personas con la app instalada llegan a la pantalla correspondiente; las demás llegan a la misma URL web. Interpretación del fallo: la verificación, el enrutamiento o el fallback están incompletos. Ventana de monitorización: inmediatamente en cada publicación de la app. Disparador de rollback: los enlaces terminan en un callejón sin salida, abren la pantalla equivocada o no pueden volver a la web.

Prueba la paridad de contenido

Prueba que debes ejecutar: compara el contenido rastreable de cada resultado web con su destino en la app. Resultado esperado: el tema y el contenido sustantivo coinciden aunque el diseño sea distinto. Interpretación del fallo: el enlace profundo puede inducir a error porque Search indexa la página web. Ventana de monitorización: antes de asignar una ruta y después de cambios importantes en la plantilla de contenido. Disparador de rollback: el destino de la app deja de cumplir el título y el fragmento del resultado web.

Mide la salud de los enlaces profundos de apps

Apariencia de búsqueda Android app

Métrica: impresiones y clics de la apariencia de búsqueda Android App. Qué te dice: con qué frecuencia Google mostró resultados con un tratamiento de enlace profundo Android y cuánto tráfico utilizó esos enlaces. Cómo obtenerla: Search Console Performance, filtrado por la apariencia Android App. Referencia o rango realista: establece una línea base por consulta y página; la aptitud depende de la adopción de la app y de la relevancia de los resultados, así que no existe un objetivo universal. Periodicidad: mensual, con anotaciones de las publicaciones.

Tasa de aperturas de ruta correctas

Métrica: aperturas válidas de enlaces profundos divididas entre los intentos de enlace de app. Qué te dice: si los enlaces verificados llegan a la pantalla prevista en lugar de a un fallback o un error. Cómo obtenerla: eventos de analítica de la app al recibir el enlace y al renderizar el destino, excluyendo parámetros URL sensibles. Referencia o rango realista: utiliza tu propia línea base por plataforma y versión; investiga una regresión sostenida después de una publicación. Periodicidad: semanal y en cada publicación de la app.

Número de excepciones de paridad

Métrica: URL web asignadas cuyo destino en la app ya no contiene contenido equivalente. Qué te dice: si el enrutamiento sigue cumpliendo el requisito central de paridad de contenido. Cómo obtenerla: inventario mantenido de URL y pantallas más control de calidad de cada publicación. Referencia o rango realista: cero excepciones conocidas es el objetivo adecuado. Periodicidad: en cada publicación y después de cambios importantes en la arquitectura de información web o de la app.

Ponte a prueba: App Indexing

Cinco preguntas rápidas sobre qué era App Indexing, qué lo sustituyó y qué hace realmente por el SEO. Elige una respuesta para cada pregunta y comprueba el resultado.

Registro de cambios