App Indexing (linki głębokie aplikacji w wyszukiwaniu)

TL;DR — „App Indexing” było dawną funkcją Google, która pobierała treści z aplikacji w telefonie i wyświetlała je w wynikach wyszukiwania. Google ją wyłączył. Dziś używa się określenia linki głębokie aplikacji — linki, które przy zainstalowanej aplikacji otwierają wynik wyszukiwania w aplikacji, zamiast w przeglądarce telefonu. Najważniejsze: nie pomaga to zdobyć wyższej pozycji. Google nadal szereguje Twoją witrynę; linki głębokie tylko zmieniają miejsce, w które trafia kliknięcie.

Czym było „App Indexing”

Kiedyś Google pozwalał połączyć witrynę z natywną aplikacją mobilną, aby wyświetlać treści aplikacji — i prowadzące do nich linki — w wynikach wyszukiwania. Ten system nazywał się App Indexing, a później Firebase App Indexing. Gdy ktoś szukał czegoś i miał zainstalowaną pasującą aplikację, Google mógł skierować go do aplikacji zamiast do strony internetowej.

Jeśli czytasz ten tekst, bo znalazłeś „App Indexing” w starej checkliście SEO, dokumentacji dla deweloperów albo ustawieniach wtyczki, krótka odpowiedź brzmi: ta funkcja jest wycofana. Google ją wyłączył. Nie musisz jej konfigurować, a poradnik, który Ci to zaleca, jest nieaktualny.

Co ją zastąpiło

Współczesna wersja funkcji „otwórz moją aplikację z wyniku wyszukiwania” nazywa się linkami głębokimi aplikacji, a każda platforma ma dla niej własną nazwę:

• Android nazywa je App Links.
• iOS nazywa je Universal Links.

Oba rozwiązania robią to samo: gdy ktoś kliknie link do Twojej witryny — z wyniku Google, innej strony albo aplikacji — i ma już zainstalowaną aplikację, telefon otworzy tę treść w aplikacji. Jeśli aplikacji nie ma, ten sam link zwyczajnie otworzy się w przeglądarce.

Co większość osób rozumie błędnie

Linki głębokie aplikacji nie pomagają w zdobywaniu pozycji. To mit, którego trzeba się oduczyć. Starsze artykuły twierdzą, że „indeksowanie aplikacji” poprawia rankingi. Google jasno powiedział, że tak nie jest — wyszukiwarka nadal korzysta z treści strony internetowej, aby ustalić jej pozycję. Linki głębokie zmieniają tylko doświadczenie po kliknięciu, gdy użytkownik ma Twoją aplikację. To wygoda, nie trik rankingowy.

Jest jedna rzeczywista zasada: ekran aplikacji, do którego prowadzi link, powinien wyświetlać tę samą treść co strona internetowa. Google buduje fragment wyniku na podstawie strony, więc jeśli aplikacja pokazuje coś innego, wprowadzasz w błąd osobę, która kliknęła.

Chcesz poznać pełną historię, dokładne pliki i kroki dla Androida oraz iOS, a także dowiedzieć się, jak mierzyć to w Search Console? Przejdź do karty Advanced.

TL;DR — Google App Indexing (2013) → Firebase App Indexing (2016, a także krótkotrwały eksperyment „app streaming”) → wycofanie około 2021 roku. Następcą są linki głębokie aplikacji: Android App Links (weryfikowane plikiem Digital Asset Links w /.well-known/assetlinks.json oraz filtrami intencji android:autoVerify) i iOS Universal Links (weryfikowane plikiem apple-app-site-association oraz uprawnieniem Associated Domains). Zgodnie z wytycznymi Google z maja 2025 roku linki głębokie nie zmieniają indeksowania ani rankingu — wyszukiwarka nadal szereguje stronę internetową — a miejsce docelowe powinno odpowiadać treści adresu webowego. Zachowanie linków mierz za pomocą analityki platformy i aplikacji, zamiast zakładać, że istnieje dedykowany raport Search Console.

Trzy epoki, jedna myląca nazwa

Powodem zamieszania wokół „App Indexing” jest to, że ta sama idea miała przez dekadę trzy różne nazwy, a ostatnie przejście oznaczało wycofanie funkcji, za którym wiele starszych treści nie nadążyło.

2013–2016 — Google App Indexing. W październiku 2013 roku Google ogłosił, że “Googlebot can now index content in your Android app,” (tłumaczenie) „Googlebot może teraz indeksować treści w Twojej aplikacji na Androida”, pokazując linki głębokie do aplikacji “straight in our search results when we think they’re relevant… and if the user has the app installed.” (tłumaczenie) „bezpośrednio w naszych wynikach wyszukiwania, gdy uznamy je za istotne i gdy użytkownik ma zainstalowaną aplikację”. Treści aplikacji zgłaszało się przez istniejącą mapę witryny i Webmaster Tools. Było to crawlowanie wewnątrz aplikacji na wzór crawlowania stron internetowych.

2016–około 2021 — Firebase App Indexing. Po przejęciu Firebase przez Google w 2014 roku App Indexing przemianowano około Google I/O 2016 na Firebase App Indexing. Dodano obsługę iOS, a przez pewien czas także eksperyment app streaming — przycisk „Try Now”, który pozwalał uruchomić niezainstalowaną aplikację w przeglądarce na kilka minut, bezpośrednio z wyniku wyszukiwania. App streaming był ograniczonym eksperymentem z lat 2015–2016 i dawno zniknął; nie planuj działań w oparciu o tę funkcję.

Około 2021–obecnie — wycofane. Interfejs AppIndexApi jest oznaczony jako deprecated we własnej dokumentacji referencyjnej Google dla Androida. Aktualna dokumentacja Firebase stwierdza, że Firebase App Indexing “is no longer the recommended way of indexing content for display as suggested results in Google Search App,” (tłumaczenie) „nie jest już zalecaną metodą indeksowania treści w celu wyświetlania jej jako sugerowanych wyników w aplikacji Google Search”, a także wyraźnie ostrzega, że “the Google Search App for Android no longer uses local content indexed via Firebase App Indexing to provide results to users.” (tłumaczenie) „aplikacja Google Search na Androida nie korzysta już z lokalnych treści zaindeksowanych przez Firebase App Indexing do dostarczania użytkownikom wyników”. Firebase wskazuje teraz App Links i Universal Links jako zalecaną ścieżkę. (Przejście nastąpiło w 2021 roku — informacja o wycofaniu jest obecna w archiwalnym zrzucie z października 2022 roku, ale nie ma jej w zrzucie z października 2020 roku).

Co zastąpiło App Indexing: linki głębokie aplikacji

Linki głębokie to, według Google, “special URIs that take users beyond your mobile app’s homepage, leading them directly to specific in-app content.” (tłumaczenie) „specjalne identyfikatory URI, które przenoszą użytkowników poza stronę główną aplikacji mobilnej i prowadzą ich bezpośrednio do określonej treści w aplikacji”. Najważniejsza zmiana względem starego modelu: chodzi o weryfikację i routing na poziomie systemu operacyjnego oraz przeglądarki — nie o prowadzony przez Google proces indeksowania. Niczego tutaj „nie zgłasza się do indeksu”.

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

Android App Links to według 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.” (tłumaczenie) „rozszerzona możliwość tworzenia linków głębokich, która weryfikuje linki do własnej witryny przez ustanowienie zaufanego powiązania między aplikacją a witryną. Po weryfikacji linki do witryny mogą od razu otwierać odpowiadającą im treść w aplikacji bez wymagania od użytkownika wyboru aplikacji w oknie rozstrzygania”. App Links są obsługiwane od Androida 6, a Google nazywa je „a recommended approach” (tłumaczenie) „zalecanym podejściem” do linków głębokich do własnej witryny.

Plikiem weryfikacyjnym jest Digital Asset Links. Gdy w filtrze intencji ustawisz android:autoVerify="true", a aplikacja jest zainstalowana, “Android queries the corresponding websites for the Digital Asset Links file at https://hostname/.well-known/assetlinks.json.” (tłumaczenie) „Android odpytuje odpowiadające witryny o plik Digital Asset Links pod adresem https://hostname/.well-known/assetlinks.json”. Ten plik JSON zawiera informacje o tym, który pakiet aplikacji i odcisk certyfikatu podpisującego może obsługiwać linki do domeny. Android 15 dodaje Dynamic App Links, które pozwalają doprecyzować zasady dopasowania adresów bez publikowania nowej wersji aplikacji.

Ważne są dwie granice związane z wersją i podpisem. Po pierwsze, Dynamic App Links rozszerzają podstawowe powiązanie w manifeście, a nie je zastępują — na wersjach Androida starszych niż 15 weryfikacja nadal opiera się wyłącznie na standardowym dopasowaniu manifestu i assetlinks.json. Po drugie, weryfikacja kończy się niepowodzeniem w całości, a nie częściowo, jeśli odcisk certyfikatu podpisującego w assetlinks.json nie odpowiada dokładnie rzeczywistej tożsamości zainstalowanej kompilacji — kompilacja debugowa podpisana innym kluczem niż wpis w assetlinks.json nigdy się nie zweryfikuje, nawet gdy wszystkie pozostałe pola są poprawne.

Warto zachować jasne rozróżnienie: zwykły link głęboki Androida korzysta z filtrów intencji, ale może wywołać okno „którą aplikacją chcesz to otworzyć?”. App Links dodają weryfikację Digital Asset Links, dzięki czemu zweryfikowana domena otwiera się bezpośrednio w aplikacji, bez okna wyboru.

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

Odpowiednikiem Apple są Universal Links. Apple opisuje je tak: “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.” (tłumaczenie) „gdy użytkownicy stukają lub klikają uniwersalny link, system kieruje go bezpośrednio do aplikacji, bez przechodzenia przez domyślną przeglądarkę użytkownika ani witrynę; ponieważ uniwersalne linki są standardowymi linkami HTTP lub HTTPS, jeden adres działa zarówno dla witryny, jak i aplikacji. Jeśli użytkownik nie ma zainstalowanej aplikacji, system otwiera adres w domyślnej przeglądarce”.

Plikiem weryfikacyjnym jest apple-app-site-association, hostowany na serwerze WWW: “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.” (tłumaczenie) „gdy ktoś instaluje aplikację, system sprawdza plik zapisany na serwerze WWW, aby zweryfikować, czy witryna pozwala aplikacji otwierać adresy w jej imieniu”. Po stronie aplikacji potrzebujesz uprawnienia Associated Domains odpowiadającego domenom w tym pliku. Zasada jest taka sama jak na Androidzie — to sprawdzane przez urządzenie zaufane powiązanie witryny z aplikacją, a nie sygnał rankingu w wyszukiwarce.

Prawidłowy plik apple-app-site-association i poprawnie dopasowane uprawnienie nie gwarantują jednak, że każde stuknięcie otworzy aplikację. Apple opisuje przypadki, w których Universal Link mimo działającego powiązania nadal otwiera się w Safari — na przykład gdy link kliknięto w samym Safari podczas przeglądania tej samej domeny albo gdy użytkownik wcześniej wybrał otwieranie linków tej domeny w przeglądarce. Gdy aplikacja rzeczywiście nie jest zainstalowana lub powiązanie nie pasuje, standardowy link HTTP(S) powinien przejść do przeglądarki, a nie kończyć się błędnym własnym schematem — taki fallback oznacza prawidłowe działanie systemu, a nie błąd do naprawienia.

Obie platformy są obsługiwane przez Google Search jako miejsca docelowe linków głębokich.

Czy linki głębokie aplikacji wpływają na rankingi? (Nie — oto dokładny cytat)

To najważniejsze sprostowanie w całym temacie, bo strony o rankingach nadal często się mylą. Możesz znaleźć artykuły twierdzące, że “App Indexing will influence ranking… whether or not the user has your app installed” (tłumaczenie) „App Indexing wpłynie na ranking, niezależnie od tego, czy użytkownik ma zainstalowaną aplikację” albo że “Google will use the content within your app as a signal in ranking.” (tłumaczenie) „Google użyje treści aplikacji jako sygnału rankingowego”. To nieprawda, a własny wpis Google z maja 2025 roku mówi o tym wprost:

“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.” (tłumaczenie) „Dodanie linków głębokich do witryny łączy adresy URL witryny z odpowiednimi stronami aplikacji. Nie zmienia to sposobu wyświetlania treści przez Google Search; wyszukiwarka nadal korzysta z treści stron internetowych przy indeksowaniu i ustalaniu rankingu. Linki głębokie pozwalają użytkownikom przejść z wyników wyszukiwania bezpośrednio do odpowiedniej strony aplikacji (jeśli jest zainstalowana), zapewniając lepsze doświadczenie.”

Przeczytaj to uważnie: indeksowana i szeregowane jest strona internetowa. Link głęboki to warstwa routingu po kliknięciu, która działa tylko dla osób mających już aplikację. To poprawa UX, a nie dźwignia widoczności. Jeśli ktoś mówi, że skonfigurowanie assetlinks.json podniesie rankingi, myli się.

Jedyny rzeczywisty wymóg: zgodność treści

Istnieje dokładnie jedna istotna zasada, związana z uczciwością wobec użytkownika. Google mówi:

*“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.” (tłumaczenie) „Ponieważ wyszukiwarka korzysta z treści strony internetowej przy indeksowaniu i ustalaniu rankingu, linki głębokie dodawaj tylko wtedy, gdy strona aplikacji zawiera tę samą treść co odpowiadająca jej strona WWW. W przeciwnym razie tytuł i fragment wyświetlonej w Google Search strony mogą wprowadzić użytkowników w błąd co do treści, którą zobaczą po kliknięciu. Różnice w układzie lub innym UX między stroną aplikacji a odpowiadającą jej stroną WWW są w porządku, o ile treść się zgadza.”

Natywny, ładniejszy i inaczej ułożony ekran aplikacji jest więc w porządku. Ekran z inną treścią niż strona WWW — nie, bo fragment, który użytkownik kliknął, powstał na podstawie strony internetowej, a teraz trafił on w miejsce, które się z nim nie zgadza. Zgodność dotyczy treści, nie wyglądu.

Jak wdrożyć to dziś

Android: użyj App Links. Powiąż aplikację z witryną w manifeście aplikacji (filtry intencji z android:autoVerify="true"), a następnie opublikuj na stronie /.well-known/assetlinks.json z nazwą pakietu aplikacji i odciskiem certyfikatu podpisującego. Android weryfikuje powiązanie podczas instalacji. Android Studio App Links Assistant i strona Deep Links w Play Console pomagają wygenerować oraz zweryfikować konfigurację.

iOS: wdroż Universal Links. Opublikuj na serwerze WWW plik apple-app-site-association opisujący ścieżki mapowane do aplikacji i dodaj w aplikacji uprawnienie Associated Domains dla pasujących domen. Dokumentacja debugowania Universal Links od Apple omawia typowe problemy (nieprawidłowy content-type pliku, brak uprawnienia, pamięć podręczna powiązania).

Żaden z tych plików nie jest crawlowany do „indeksu wyszukiwania” tak, jak sugerowało App Indexing — są to zaufane powiązania sprawdzane przez urządzenie. Błąd w konfiguracji powoduje zwykły powrót linku do przeglądarki; poprawna konfiguracja kieruje użytkownika z zainstalowaną aplikacją do aplikacji.

Minimalna kontrola plików powiązania

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

Oba endpointy powinny zwracać 200 bez przekierowania i udostępniać oczekiwaną odpowiedź JSON. Karta Scripts zawiera rozszerzone kontrole content-type, przekierowań, PowerShella, DevTools i bookmarkletu.

Jak to mierzyć: filtr aplikacji Android w Search Console

Google udostępnia natywny pomiar wydajności linków głębokich aplikacji: “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.” (tłumaczenie) „Search Console uwzględnia wydajność linków głębokich aplikacji witryny dla Androida. W raporcie skuteczności możesz użyć filtra wyglądu w wyszukiwarce Android App, aby sprawdzić, kiedy linki głębokie aplikacji na Androida są znajdowane i wyświetlane użytkownikom.” Otrzymasz kliknięcia, wyświetlenia, CTR i pozycję dla wyników, w których pojawił się link głęboki Androida — to konkretny i aktualny sposób sprawdzenia, czy rozwiązanie coś daje. (Filtr dodano w 2019 roku i pozostaje aktualnym narzędziem według wpisu Google z 2025 roku).

Rozdziel jednak te dwa zadania. Filtr Search Console to raport ruchu i wyglądu — tylko dla Androida, zależny od tego, czy Google pokaże dany wariant linku głębokiego dla konkretnego zapytania; sam w sobie nie dowodzi indeksowania ani rankingu. Techniczne sprawdzenie działania linku to osobne ćwiczenie: pobierz pliki powiązania i przetestuj przejście po stuknięciu na prawdziwych urządzeniach (zobacz karty Scripts i Validation Tests). Cichy raport Search Console nie oznacza, że konfiguracja jest zepsuta, a kliknięcia w raporcie nie są sygnałem SEO — mówią o skali routingu, nie o rankingu.

Bing i linki głębokie aplikacji

Nie zakładaj zgodności Google i Binga. Bing prowadził skoncentrowany na Windowsie program „app linking” od kwietnia 2014 roku, skierowany do Windows 8,1 i Windows Phone, ale te strony już nie działają (adres deweloperski zwraca 404, a wpisy na blogu przekierowują do ogólnej strony bloga), a sam Windows Phone wycofano. Nie istnieje obecnie opublikowany przez Bing odpowiednik wytycznych Google dotyczących linków głębokich aplikacji z 2025 roku. W praktyce App Links i Universal Links nadal działają w Bing/Edge na urządzeniach mobilnych, bo są standardami na poziomie systemu operacyjnego i przeglądarki, a nie funkcją, którą wyszukiwarka musi aktywować — wdrażasz je więc tak samo niezależnie od wyszukiwarki. Nie ma tylko dokumentacji Binga, do której można się odwołać.

Dziedzictwo, które nadal spotkasz w praktyce

Kilka sąsiednich technik powoduje zamieszanie, więc je nazwijmy i idźmy dalej:

• Znaczniki schema.org potentialAction / ViewAction z miejscem docelowym linku głębokiego android-app://. To technika odziedziczona po epoce App Indexing. Możesz ją jeszcze znaleźć w bazach kodu i słowniku działań schema.org, ale obecne zalecenie Google to konfiguracja App Links / Universal Links, nie te znaczniki. Traktuj je jako „coś, co możesz jeszcze zobaczyć”, a nie rekomendację.
• Firebase Dynamic Links to inny, osobno wycofywany produkt Firebase — usługa skracania URL-i i odroczonych linków głębokich do atrybucji marketingowej, a nie system treści App Indexing. On również jest wygaszany, a własne wskazówki migracji kierują do App Links i Universal Links. Nie mieszaj tych dwóch procesów wycofania.

Najprostszy model, który warto zapamiętać: (1) stary system crawlowania i streamingu Google App Indexing / Firebase App Indexing = martwy; (2) linkowanie głębokie App Links / Universal Links = aktualne, tylko routing/UX, bez wpływu na ranking; (3) stare windowsowe linkowanie aplikacji Binga = również martwe, bez udokumentowanego następcy.

Podsumowanie AI

Skondensowana wersja karty Advanced:

• App Indexing jest wycofane. Google App Indexing (2013) → Firebase App Indexing (2016) → wycofanie około 2021 roku. AppIndexApi jest oznaczone jako wycofane w dokumentacji Google, a aplikacja Google Search nie korzysta już z treści Firebase App Indexing.
• Co je zastąpiło: linki głębokie aplikacji — Android App Links (weryfikowane plikiem Digital Asset Links w /.well-known/assetlinks.json oraz filtrami intencji android:autoVerify) i iOS Universal Links (weryfikowane przez apple-app-site-association oraz uprawnienie Associated Domains). To weryfikacja i routing na poziomie systemu operacyjnego oraz przeglądarki, a nie prowadzony przez Google indeks.
• Linki głębokie NIE wpływają na ranking. Zgodnie z wpisem Google z maja 2025 roku “don’t change how Google Search shows your content; Search continues to use the content of your web pages for indexing and ranking.” (tłumaczenie) „nie zmieniają sposobu wyświetlania treści przez Google Search; wyszukiwarka nadal korzysta z treści stron internetowych przy indeksowaniu i ustalaniu rankingu”. Po kliknięciu kierują tylko użytkowników z zainstalowaną aplikacją do aplikacji.
• Jedyną rzeczywistą zasadą jest zgodność treści: linkiem głębokim obejmuj tylko ekran aplikacji pokazujący tę samą treść co strona internetowa (różnice układu/UX są dopuszczalne).
• Mierz działanie za pomocą filtra wyglądu w wyszukiwarce Android app w Search Console, ale traktuj go jako raport ruchu, a nie dowód poprawnego powiązania technicznego ani innego rankingu; samo powiązanie sprawdzaj testami plików i urządzeń.
• Żadna platforma nie gwarantuje, że każde zweryfikowane stuknięcie otworzy aplikację. Android całkowicie odrzuca weryfikację przy niezgodności certyfikatu podpisującego (Dynamic App Links w Androidzie 15 rozszerzają, a nie zastępują dopasowanie manifestu); iOS opisuje prawidłowe przypadki — przeglądanie tej samej domeny w Safari i wcześniejszy wybór użytkownika — gdy Universal Link mimo działającego powiązania otwiera się w przeglądarce.
• Bing nie ma obecnie równoważnych wytycznych; jego windowsowy program umarł, ale App Links i Universal Links nadal działają w Edge, bo są standardami systemu operacyjnego.
• Nie myl App Indexing z Firebase Dynamic Links (osobnym, również wycofywanym produktem) i nie traktuj znaczników potentialAction/ViewAction jako aktualnej najlepszej praktyki.

Dokumentacja oficjalna

Dokumentacja źródłowa Google, Androida i Apple.

Google — aktualne wytyczne

• Linki głębokie aplikacji: łączenie witryny z aplikacją (2 maja 2025 r.) — aktualne, autorytatywne wyjaśnienie: działanie linków głębokich, brak wpływu na ranking, zgodność treści i filtr Search Console.
• Firebase App Indexing — aktualna strona z informacją o wycofaniu i odsyłaczem do App Links / Universal Links.

Google — materiały historyczne (kontekst wycofania)

• Indeksowanie aplikacji tak jak stron (31 października 2013 r.) — pierwotne ogłoszenie App Indexing.

Android

• Informacje o linkach głębokich — linki głębokie, App Links i model weryfikacji (aktualizacja z 18 czerwca 2026 r.).
• Weryfikacja Android App Links — android:autoVerify oraz wymóg Digital Asset Links / assetlinks.json.

Apple

• Łączenie aplikacji i witryn z treścią — przegląd Universal Links i modelu weryfikacji pliku na serwerze.
• Obsługa powiązanych domen — plik apple-app-site-association i uprawnienie Associated Domains.

Standard branżowy (niezwiązany wyłącznie z Google)

• ViewAction / Actions (schema.org) — starszy słownik potentialAction/ViewAction; przydatny jako kontekst, ale nie jest aktualnym zaleceniem Google.

Cytaty ze źródeł

Wypowiedzi Google, Androida i Apple z dokumentacji. Każdy link Google/Android prowadzi bezpośrednio do cytowanego fragmentu na stronie źródłowej.

Google — pierwotne ogłoszenie 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.” (tłumaczenie) „Tak jak crawluje i indeksuje witryny, Googlebot może teraz indeksować treści w Twojej aplikacji na Androida… Jeśli zarówno strona internetowa, jak i treści aplikacji zostaną pomyślnie zaindeksowane, Google spróbuje pokazać linki głębokie do aplikacji bezpośrednio w wynikach wyszukiwania, gdy uzna je za istotne dla zapytania użytkownika i gdy użytkownik ma zainstalowaną aplikację.” — Lawrence Chang, Product Manager, Google. Przejdź do cytatu

Google — Firebase App Indexing jest wycofane (aktualna dokumentacja)

• “Firebase App Indexing is no longer the recommended way of indexing content for display as suggested results in Google Search App.” (tłumaczenie) „Firebase App Indexing nie jest już zalecaną metodą indeksowania treści w celu wyświetlania jej jako sugerowanych wyników w aplikacji Google Search.” Przejdź do cytatu

Google — linki głębokie nie zmieniają rankingu (maj 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.” (tłumaczenie) „Nie zmienia to sposobu wyświetlania treści przez Google Search; wyszukiwarka nadal korzysta z treści stron internetowych przy indeksowaniu i ustalaniu rankingu.” — John Mueller (Google Search Relations) i Sabs (Android Developer Relations). Przejdź do cytatu
• “You should only add deep links in cases where the app page contains the same content as the corresponding web page.” (tłumaczenie) „Linki głębokie należy dodawać tylko wtedy, gdy strona aplikacji zawiera tę samą treść co odpowiadająca jej strona internetowa.” Przejdź do cytatu

Android — App Links i plik weryfikacyjny

• “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.” (tłumaczenie) „Android App Links to rozszerzona możliwość tworzenia linków głębokich, która weryfikuje linki do własnej witryny przez ustanowienie zaufanego powiązania między aplikacją a witryną.” — Android Developers. Przejdź do cytatu
• “Android queries the corresponding websites for the Digital Asset Links file at https://hostname/.well-known/assetlinks.json.” (tłumaczenie) „Android odpytuje odpowiadające witryny o plik Digital Asset Links pod adresem https://hostname/.well-known/assetlinks.json.” Przejdź do cytatu

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.” (tłumaczenie) „Gdy użytkownicy stukają lub klikają uniwersalny link, system kieruje go bezpośrednio do aplikacji, bez przechodzenia przez domyślną przeglądarkę użytkownika ani witrynę; jeśli użytkownik nie ma zainstalowanej aplikacji, system otwiera adres w domyślnej przeglądarce.” — Apple Developer Documentation, “Allowing apps and websites to link to your content.” (tłumaczenie) „Łączenie aplikacji i witryn z treścią”.

Czy powinieneś konfigurować linki głębokie aplikacji?

Krótka ścieżka przez pytanie „czy w ogóle tego potrzebuję?” — bo w przypadku wielu witryn uczciwa odpowiedź brzmi „nie”.

1. Czy masz natywną aplikację mobilną, która odwzorowuje treść witryny?

• Nie mam aplikacji → Stop. Nie ma czego łączyć głębokim linkiem. App Indexing / linki głębokie Cię nie dotyczą. (Jeśli znalazłeś „App Indexing” w checkliście, usuń ten punkt — funkcja jest wycofana).
• Tak → idź dalej.

2. Czy robisz to dla rankingów?

• Tak → Stop i przeczytaj ponownie. Linki głębokie nie wpływają na indeksowanie ani ranking. Jeśli celem jest widoczność SEO, inwestuj w mobilną stronę WWW, a nie w infrastrukturę linków głębokich.
• Nie — chcę kierować użytkowników z aplikacją do aplikacji → idź dalej.

3. Czy ekran aplikacji pokazuje tę samą treść co odpowiadająca mu strona WWW?

• Nie (inna treść) → Nie twórz głębokiego linku do tego adresu. Niezgodność wprowadza użytkowników w błąd, bo fragment powstał na podstawie strony WWW. Najpierw popraw zgodność (różnice układu/UX są w porządku, różnice treści — nie).
• Tak → idź dalej.

4. Która platforma lub platformy?

• Android → App Links: filtry intencji android:autoVerify + plik Digital Asset Links w /.well-known/assetlinks.json.
• iOS → Universal Links: apple-app-site-association na serwerze + uprawnienie Associated Domains.
• Obie → skonfiguruj oba rozwiązania; działają niezależnie.

5. Skąd będziesz wiedzieć, że działa?

• Sprawdzaj filtr wyglądu w wyszukiwarce Android app w Search Console dla Androida.
• Testuj rzeczywiste przejście po stuknięciu na urządzeniach i weryfikuj pliki powiązania (App Links Assistant na Androidzie, debugowanie Universal Links Apple na iOS).

Praktyczna zasada: linki głębokie to ulepszenie UX/routingu dla witryn mających rzeczywistą aplikację z treścią zgodną ze stroną — nie projekt SEO nastawiony na ranking i nie coś, co należy doklejać tylko dlatego, że stary poradnik wspomniał „App Indexing”.

Checklista wdrożenia linków głębokich aplikacji

Dotyczy tylko sytuacji, gdy masz natywną aplikację odwzorowującą treść witryny:

• Potwierdzono, że nie oczekujesz wzrostu rankingu — linki głębokie zmieniają routing, nie ranking.
• Zweryfikowano zgodność treści: każdy ekran aplikacji objęty linkiem głębokim pokazuje tę samą treść co odpowiadająca strona WWW (różnice układu/UX są w porządku).
• Android: filtry intencji używają android:autoVerify="true" dla Twojej domeny.
• Android: opublikowano /.well-known/assetlinks.json przez HTTPS, z właściwym typem treści, nazwą pakietu aplikacji i odciskiem certyfikatu podpisującego.
• iOS: opublikowano apple-app-site-association na serwerze (właściwy typ treści, bez przekierowań) z odpowiednimi wzorcami ścieżek.
• iOS: dodano w aplikacji uprawnienie Associated Domains zgodne z domenami w pliku powiązania.
• Przetestowano rzeczywiste przejście po stuknięciu na fizycznych urządzeniach z Androidem i iOS (przypadki z aplikacją i bez niej).
• Po uruchomieniu przejrzano filtr wyglądu w wyszukiwarce Android app w Search Console pod kątem wyświetleń i kliknięć.
• Usunięto przestarzałe odwołania — stare znaczniki mapy witryny App Indexing, wywołania Firebase App Indexing SDK oraz znaczniki potentialAction/android-app://, na których polegano jako na „właściwym” mechanizmie.

Antywzorce, których należy unikać

• Traktowanie App Indexing jako aktualnej funkcji. AppIndexApi jest wycofane, a aplikacja Google Search nie korzysta już z treści Firebase App Indexing. Jeśli poradnik, wtyczka lub checklista mówi, aby „włączyć App Indexing”, jest nieaktualna.
• Oczekiwanie wzrostu rankingu. Najczęściej powtarzany mit ze starych stron o rankingach brzmi: „indeksowanie aplikacji wpływa na ranking”. Google mówi odwrotnie — wyszukiwarka szereguje stronę WWW, a linki głębokie tego nie zmieniają.
• Linkowanie głębokie do niezgodnej treści. Użytkownik, który kliknął fragment strony WWW, trafia do ekranu aplikacji z inną treścią. Google wyraźnie ostrzega, że to wprowadza w błąd. Zgodność dotyczy treści, nie wyglądu.
• Pogoń za „app streaming”. Funkcja „Try Now”, pozwalająca wyświetlić podgląd niezainstalowanej aplikacji, była eksperymentem z lat 2015–2016 i już nie istnieje. Nie projektuj pod nią rozwiązania.
• Mylenie Firebase App Indexing z Firebase Dynamic Links. To różne produkty, oba wycofywane, rozwiązujące różne problemy (indeksowanie treści kontra skracanie URL-i i atrybucja). Oba wskazują dziś App Links / Universal Links.
• Zakładanie zgodności z Bingiem. Stary windowsowy program linkowania aplikacji Binga umarł i nie ma udokumentowanego następcy. App Links/Universal Links nadal działają w Edge jako standardy systemu operacyjnego, ale nie ma dokumentacji Binga, za którą można podążać.
• Pomijanie weryfikacji i zastanawianie się, dlaczego „nie działa”. Nieprawidłowy typ treści, przekierowanie pliku powiązania albo brak uprawnienia po cichu kierują z powrotem do przeglądarki. Pliki są ścisłym handshake’em, a nie sugestią.

Typowe awarie linków głębokich aplikacji

Link WWW nadal otwiera się w przeglądarce na Androidzie

Objaw: Zainstalowana aplikacja nie przejmuje pasującego adresu HTTPS. Prawdopodobna przyczyna: Weryfikacja domeny nie powiodła się, bo host w manifeście, nazwa pakietu, odcisk certyfikatu podpisującego albo odpowiedź assetlinks.json nie pasują. Naprawa: sprawdź tożsamość podpisu zainstalowanej kompilacji, pobierz plik powiązania bezpośrednio i ponownie uruchom weryfikację linków Androida przed kolejnym testem stuknięcia.

Universal Link otwiera Safari zamiast aplikacji iOS

Objaw: Ten sam adres HTTPS działa w WWW, ale omija zainstalowaną aplikację. Prawdopodobna przyczyna: Uprawnienie Associated Domains lub ścieżki w apple-app-site-association nie zezwalają na ten adres — najpierw sprawdź jednak udokumentowane przypadki, które nie są awarią: własne wytyczne Apple opisują linki kliknięte w Safari na tej samej domenie oraz domenę, której linki użytkownik wcześniej wybrał do otwierania w przeglądarce, jako oczekiwane otwarcie w przeglądarce, a nie błąd weryfikacji. Naprawa: potwierdź domenę w uprawnieniu, dostępność pliku i reguły ścieżek, następnie przetestuj ponownie po reinstalacji lub odświeżeniu stanu powiązania urządzenia — i wyklucz zachowanie tej samej domeny oraz wcześniejszy wybór użytkownika, zanim uznasz powiązanie za uszkodzone.

Aplikacja otwiera niewłaściwy ekran

Objaw: Weryfikacja się udaje, ale aplikacja otwiera stronę główną albo treść, która nie pasuje. Prawdopodobna przyczyna: Powiązanie systemu operacyjnego jest poprawne, lecz mapowanie tras w aplikacji jest niepełne. Naprawa: zmapuj przychodzącą ścieżkę i parametry na odpowiedni ekran, zachowaj bezpieczny fallback do WWW i porównaj treść aplikacji ze stroną internetową, z której pochodził fragment wyniku wyszukiwania.

Linki głębokie aplikacji — ściąga

Wtedy i dziś

Pliki weryfikacyjne

Najważniejsze fakty

• Linki głębokie zmieniają routing po kliknięciu, a nie indeksowanie ani ranking.
• Twórz linki głębokie tylko do ekranów aplikacji z treścią zgodną ze stroną WWW.
• Android wymaga filtrów intencji android:autoVerify="true".
• iOS wymaga uprawnienia Associated Domains.
• Mierz działanie filtrem wyglądu w wyszukiwarce Android app w GSC.
• Bing: brak aktualnych równoważnych wytycznych; standardy nadal działają w Edge.

Sprawdzanie plików powiązania

Linki głębokie zawodzą po cichu, więc najszybszym krokiem debugowania jest potwierdzenie, że oba pliki weryfikacyjne istnieją, zwracają 200 i udostępniają właściwy typ treści.

macOS / Linux — pobieranie i inspekcja plików

# 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

Konsola Browser DevTools — szybki test dostępności

// 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 — test jednym kliknięciem na bieżącej stronie

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

Jeśli plik zwraca 404s, przekierowuje albo udostępnia niewłaściwy typ treści, system operacyjny nie zweryfikuje powiązania, a linki po cichu wrócą do przeglądarki zamiast otworzyć aplikację.

Narzędzia do wdrażania i debugowania linków głębokich

• Android Studio — App Links Assistant — generuje filtry intencji, tworzy i weryfikuje Digital Asset Links (assetlinks.json) oraz testuje obsługę linków.
• Google Play Console — strona Deep Links — pokazuje stan linków głębokich aplikacji i ich weryfikacji.
• Weryfikacja Digital Asset Links — sprawdź, czy opublikowany assetlinks.json prawidłowo łączy domenę z pakietem aplikacji i odciskiem.
• Debugowanie Apple Universal Links — wytyczne Apple dotyczące diagnozowania, dlaczego Universal Link otwiera przeglądarkę zamiast aplikacji (typ treści pliku powiązania, uprawnienie, pamięć podręczna).
• Google Search Console — raport skuteczności — filtr wyglądu w wyszukiwarce Android app pokazuje wyświetlenia, kliknięcia, CTR i pozycję wyników, w których pojawił się link głęboki aplikacji Android.
• curl / DevTools / bookmarklet — najszybszy pierwszy test, czy oba pliki powiązania zwracają 200, właściwy typ treści i nie przekierowują (zobacz kartę Scripts).

Zasoby warte uwagi

Moje teksty

• Indeksowanie mobile-first przechodzi w mobile-only — powiązana, lecz odrębna kwestia tego, którą wersję strony indeksuje Google (nie myl jej z linkowaniem głębokim aplikacji).
• Przewodnik dla początkujących po technicznym SEO — miejsce tematów mobilnych i okołoaaplikacyjnych w szerszym obrazie crawlowania, indeksowania i rankingu.

Moje wystąpienia

• Jak działa wyszukiwanie (SlideShare) — moje omówienie crawlowania, renderowania, indeksowania i rankingu, w tym tego, jak Googlebot crawluje jako smartfon. (Stałe zastrzeżenie: „To moje rozumienie systemów… nie będzie w 100% kompletne ani dokładne”).

Z branży

• Linki głębokie aplikacji: łączenie witryny z aplikacją (Google) — aktualne, autorytatywne wytyczne i źródło twierdzeń o braku wpływu na ranking oraz o zgodności treści.
• Firebase App Indexing (Google/Firebase) — aktualna informacja o wycofaniu, wskazująca App Links / Universal Links.
• O linkach głębokich (Android) — App Links i model weryfikacji.
• Weryfikacja Android App Links (Android) — wymóg assetlinks.json.
• Łączenie aplikacji i witryn z treścią (Apple) — Universal Links i apple-app-site-association.
• Google App Indexing staje się Firebase App Indexing (Search Engine Land) — omówienie przez Barry’ego Schwartza zmiany nazwy podczas Google I/O 2016.

Statystyki warte cytowania

• Linki głębokie aplikacji nie zmieniają indeksowania ani rankingu — własne stwierdzenie Google z maja 2025 roku: Search “continues to use the content of your web pages for indexing and ranking.” (tłumaczenie) „nadal korzysta z treści stron internetowych przy indeksowaniu i ustalaniu rankingu”. Najważniejszy i najczęściej błędnie przedstawiany fakt w tym temacie. Źródło
• Firebase App Indexing jest wycofane — aplikacja Google Search na Androida „no longer uses local content indexed via Firebase App Indexing”, zgodnie z aktualną dokumentacją Firebase (tłumaczenie) „nie korzysta już z lokalnych treści zaindeksowanych przez Firebase App Indexing”. Przejście nastąpiło w 2021 roku (jest obecne w archiwum z października 2022 roku, ale nie w archiwum z października 2020 roku). Źródło
• App Links są obsługiwane od Androida 6 — Google nazywa App Links “a recommended approach” (tłumaczenie) „zalecanym podejściem” do linków głębokich do własnej witryny; rozwiązanie jest weryfikowane przez plik Digital Asset Links w /.well-known/assetlinks.json. Źródło

Prompty do kontroli jakości linków głębokich aplikacji

Przegląd danych powiązania Androida

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]

Budowa macierzy testów zgodności treści

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]

Walidacja wydania z linkami głębokimi aplikacji

Testowanie publicznych plików powiązania

Test do wykonania: pobierz oba endpointy plików powiązania bez ciasteczek i uwierzytelniania oraz zweryfikuj ich JSON. Oczekiwany wynik: poprawne odpowiedzi zawierają produkcyjne identyfikatory aplikacji, odciski i zamierzone reguły ścieżek. Interpretacja niepowodzenia: urządzenia nie mogą zweryfikować relacji witryna– aplikacja. Okno monitorowania: natychmiast po wdrożeniu i po zmianach certyfikatu. Wyzwalacz wycofania: którykolwiek plik zwraca błąd, nieoczekiwanie przekierowuje albo autoryzuje niewłaściwą tożsamość produkcyjną.

Testowanie zachowania z zainstalowaną i niezainstalowaną aplikacją

Test do wykonania: stuknij reprezentatywne linki HTTPS na prawdziwych urządzeniach z Androidem i iOS, najpierw z aplikacją zainstalowaną, a następnie bez niej. Oczekiwany wynik: użytkownicy z aplikacją trafiają do właściwego ekranu, a pozostali do tego samego adresu WWW. Interpretacja niepowodzenia: weryfikacja, routing albo fallback są niekompletne. Okno monitorowania: natychmiast przy każdym wydaniu aplikacji. Wyzwalacz wycofania: linki kończą się błędem, otwierają zły ekran albo nie mogą wrócić do WWW.

Testowanie zgodności treści

Test do wykonania: porównaj treść możliwą do wyszukania w każdym wyniku WWW z miejscem docelowym w aplikacji. Oczekiwany wynik: temat i istotna treść są zgodne, nawet jeśli układ się różni. Interpretacja niepowodzenia: link głęboki może wprowadzać użytkowników w błąd, bo wyszukiwarka indeksuje stronę WWW. Okno monitorowania: przed zmapowaniem trasy i po dużych zmianach szablonu treści. Wyzwalacz wycofania: miejsce docelowe aplikacji przestaje spełniać obietnicę tytułu i fragmentu wyniku WWW.

Pomiar kondycji linków głębokich aplikacji

Wygląd Android app w wyszukiwarce

Metryka: wyświetlenia i kliknięcia dla wyglądu Android app w wyszukiwarce. Co mówi: jak często Google pokazywał wyniki z wariantem linku głębokiego Androida i ile ruchu z niego skorzystało. Jak pobrać: Performance w Search Console, przefiltrowane do wyglądu Android app w wyszukiwarce. Benchmark / realistyczny zakres: ustal punkt odniesienia według zapytania i strony; kwalifikacja zależy od adopcji aplikacji i trafnych wyników, więc nie ma uniwersalnego celu. Częstotliwość: co miesiąc, z adnotacjami wydań.

Współczynnik pomyślnego otwarcia trasy

Metryka: poprawne otwarcia linków głębokich podzielone przez próby otwarcia linku aplikacji. Co mówi: czy zweryfikowane linki prowadzą do zamierzonego ekranu, zamiast do fallbacku lub błędu. Jak pobrać: zdarzenia analityczne aplikacji przy odebraniu linku i renderowaniu miejsca docelowego, z pominięciem wrażliwych parametrów URL. Benchmark / realistyczny zakres: korzystaj z własnego punktu odniesienia platformy i wersji; badaj utrzymujący się spadek po wydaniu. Częstotliwość: co tydzień i przy każdym wydaniu aplikacji.

Liczba wyjątków zgodności

Metryka: zmapowane adresy WWW, których miejsce docelowe w aplikacji nie zawiera już równoważnej treści. Co mówi: czy routing nadal spełnia centralny wymóg zgodności treści. Jak pobrać: utrzymywana lista adresów URL i ekranów oraz QA wydań. Benchmark / realistyczny zakres: właściwym celem jest zero znanych wyjątków. Częstotliwość: przy każdym wydaniu i po dużych zmianach architektury informacji w witrynie lub aplikacji.

Sprawdź się: App Indexing

Pięć krótkich pytań o to, czym było App Indexing, co je zastąpiło i co faktycznie robi dla SEO. Wybierz odpowiedź na każde pytanie, a potem sprawdź wynik.

Dziennik zmian