Czym są progresywne aplikacje webowe (PWA) i jak wpływają na pozycjonowanie?

Progresywna aplikacja webowa (PWA) to strona internetowa, którą można zainstalować na telefonie albo komputerze i używać jak aplikacji, także przy słabym połączeniu. Sama technologia nie podnosi pozycji w Google. Może pomóc albo zaszkodzić zależnie od tego, czy robot Google widzi treść Twojej aplikacji.

Czym jest progresywna aplikacja webowa (PWA)?

PWA (ang. Progressive Web App) to strona internetowa zbudowana tak, żeby zachowywała się jak aplikacja: można dodać ją do ekranu głównego, uruchomić w osobnym oknie i korzystać z niej bez stałego zasięgu. Działa w przeglądarce, ma zwykły adres URL i jeden kod dla telefonu oraz komputera.

Za tym zachowaniem stoją trzy elementy:

• manifest aplikacji: plik z nazwą, ikonami i sposobem wyświetlania, z którego przeglądarka bierze dane do instalacji;
• service worker: skrypt działający w tle, który zapisuje pliki na urządzeniu, obsługuje tryb offline i powiadomienia push;
• HTTPS: service worker działa wyłącznie przy szyfrowanym połączeniu (wyjątkiem jest lokalny adres do testów).

Słowo „progresywna” oznacza, że strona działa w każdej przeglądarce, a funkcje aplikacji (instalacja, praca offline, powiadomienia) włączają się tam, gdzie urządzenie je obsługuje. Przykład: sklep, który klient dodaje do ekranu telefonu i otwiera jednym dotknięciem, a nowy klient znajduje w Google pod zwykłym adresem.

Czym PWA różni się od zwykłej strony i aplikacji mobilnej?

PWA leży pośrodku: indeksuje się jak strona, a w użyciu przypomina aplikację. Tabela pokazuje różnice, które mają znaczenie przy wyborze technologii.

Cecha	Zwykła strona	PWA	Aplikacja natywna
Skąd ją bierze klient	wyszukiwarka, link	wyszukiwarka, link, ikona na ekranie	App Store, Google Play
Instalacja	brak	z przeglądarki, bez sklepu z aplikacjami	ze sklepu z aplikacjami
Działanie bez sieci	zwykle nie	w zakresie, który zapisał service worker	tak
Powiadomienia push	nie	tam, gdzie przeglądarka je obsługuje	tak
Widoczność w Google	tak	tak, jeśli robot widzi treść	potrzebna osobna strona WWW
Kod i utrzymanie	jeden kod	jeden kod	osobno iOS i Android albo framework wieloplatformowy

Dla SEO najważniejszy jest wiersz o widoczności. Aplikacja natywna nie zastąpi strony w wynikach Google.

PWA może ją zastąpić, pod warunkiem że każdy widok ma własny adres i treść, którą robot odczyta.

Czy PWA wpływa na pozycjonowanie?

Nie bezpośrednio. Google nie nagradza strony za to, że jest PWA. Ocenia przede wszystkim treść i jej trafność, a według dokumentacji o page experience pokazuje najtrafniejszy wynik nawet wtedy, gdy wygoda korzystania ze strony jest słaba.

Pośrednio PWA może pomóc na dwa sposoby:

• Szybkość. Core Web Vitals są używane przez systemy rankingowe Google, ale dobry wynik w raporcie nie gwarantuje miejsca na górze wyników. Nie ma też jednego sygnału „wygody strony”.
• Powroty klientów. Klient, który otwiera sklep ikoną z ekranu, nie musi szukać go w Google ani pamiętać adresu. To korzyść dla sprzedaży, nie dla pozycji.

PWA może też zaszkodzić. Google do indeksowania i ustalania pozycji używa wersji mobilnej strony, pobranej robotem dla smartfonów (więcej w haśle Mobile First Index). Jeśli aplikacja pokazuje treść dopiero po skrypcie albo po kliknięciu, robot może jej nie zobaczyć.

W modelu Search Ecosystem™ PWA łączy dwa obszary. W Google Search liczy się to, co zobaczy robot. W User Experience liczy się wygoda klienta.

Jak Google indeksuje progresywną aplikację webową?

Google przetwarza aplikacje oparte na JavaScripcie w trzech krokach: pobiera stronę, renderuje ją (wykonuje skrypty) i dopiero wtedy indeksuje. Tak opisuje to dokumentacja Google o podstawach SEO w JavaScripcie.

Renderowanie odbywa się w kolejce. Strona może czekać na nie kilka sekund albo dłużej, zależnie od zasobów Google. W PWA zbudowanej w modelu powłoki aplikacji (app shell) serwer wysyła najpierw pusty szkielet, a treść dochodzi skryptem. Googlebot zobaczy ją więc dopiero po wyrenderowaniu.

Dlatego Google zaleca renderowanie po stronie serwera (SSR), renderowanie statyczne albo hydratację: przeglądarka dostaje gotowy HTML, który potem ożywia JavaScript. Renderowanie dynamiczne, czyli osobną wersję tylko dla robotów, Google nazywa obejściem, a nie zalecanym rozwiązaniem. Jak sprawdzić stronę oczami robota, opisujemy we wpisie o renderowaniu witryny.

Gotowy HTML z serwera ma jeszcze jedną zaletę. Google sam zaznacza, że nie każdy robot wykonuje JavaScript. Treść dostępną bez skryptów odczytają też roboty, które JavaScriptu nie wykonują. To może ułatwić dostęp do niej innym wyszukiwarkom i narzędziom, z których korzystają asystenci AI.

Jakie błędy SEO najczęściej psują PWA?

Większość problemów bierze się z tego, że PWA projektuje się jak aplikację, a Google czyta ją jak stronę. Poniższe pułapki opisuje dokumentacja Google o problemach z JavaScriptem.

• Adresy ze znakiem #. Na fragmentach adresu nie można polegać w Google. Widoki aplikacji powinny zmieniać adres przez History API przeglądarki.
• Przejścia bez zwykłych linków. Google odkrywa linki tylko wtedy, gdy są elementem a z atrybutem href. Przejście obsłużone samym skryptem po kliknięciu w przycisk robot pominie.
• Miękkie błędy 404. Przy routingu w przeglądarce nieistniejący produkt często zwraca kod 200 i pusty widok. Google radzi przekierować na adres, który zwraca 404, albo dodać do takiego widoku meta tag noindex.
• Treść po interakcji. Google nie wczytuje treści, która pojawia się dopiero po przesunięciu, kliknięciu albo wpisaniu czegoś.
• Treść zależna od pamięci urządzenia. Robot czyści Local Storage, Session Storage i ciasteczka między wczytaniami stron. Widok oparty na danych zapisanych wcześniej zobaczy pusty.
• Funkcje wymagające zgody i stałego połączenia. Dostęp do kamery i podobne uprawnienia nie mają sensu dla robota, który nie obsługuje też połączeń WebSocket ani WebRTC. Treść nie może od nich zależeć.
• Stare pliki w pamięci robota. Google mocno buforuje pliki JavaScript i CSS i może pomijać nagłówki pamięci podręcznej. Pomaga skrót treści w nazwie pliku, np. main.2bb85551.js.

Kiedy PWA ma sens dla Twojej firmy?

PWA opłaca się wtedy, gdy klienci wracają do Ciebie często z telefonu, a aplikacja natywna byłaby zbyt droga w budowie albo zbyt rzadko pobierana. Najczęściej to sklepy z powtarzalnymi zakupami, serwisy z treściami czytanymi codziennie i narzędzia, z których klient korzysta w terenie.

Gdy strona ma głównie informować, jak strona firmy usługowej albo blog, instalacja i tryb offline niewiele dają. Ważniejsze są szybkość, czytelność na telefonie i dobra treść. Ten efekt zwykle osiągniesz dobrą optymalizacją strony pod urządzenia mobilne, bez przebudowy na aplikację.

Publikowane historie wdrożeń PWA dotyczą zwykle zaangażowania i sprzedaży na telefonach, a nie pozycji w Google. Traktuj je jako dowód, że PWA może poprawić korzystanie ze strony na telefonie, a nie jako obietnicę wzrostu ruchu z wyszukiwarki.

Przed decyzją odpowiedz na trzy pytania:

• Czy klienci wracają do Ciebie regularnie z telefonu?
• Czy praca offline albo powiadomienia dają im realną korzyść?
• Czy zespół, który zbuduje PWA, zapewni HTML z serwera i osobny adres dla każdego widoku?

Jak sprawdzić, czy Google widzi treść Twojej PWA?

Wystarczy Google Search Console i przeglądarka. Sprawdź kilka typów stron: stronę główną, kategorię, produkt albo artykuł.

1. W Search Console otwórz narzędzie do sprawdzania adresów URL i uruchom test na żywo. Zobaczysz zrzut ekranu wyrenderowanej strony i jej HTML tak, jak widzi je robot Google.
2. Porównaj wyrenderowany HTML z tym, co widzi klient: tytuł, opis, cenę, treść i linki do innych stron.
3. Otwórz kod źródłowy strony (Ctrl+U). Jeśli treści nie ma w kodzie z serwera, strona w całości zależy od renderowania.
4. Przejdź przez kilka widoków aplikacji i sprawdź, czy adres w pasku zmienia się za każdym razem i nie zawiera znaku #.
5. Wpisz adres nieistniejącego produktu. W narzędziach deweloperskich przeglądarki sprawdź, czy serwer zwraca kod 404 albo widok ma noindex.
6. W raporcie podstawowych wskaźników internetowych (Core Web Vitals) w Search Console sprawdź, jak wypadają adresy w wersji mobilnej.

Najważniejsze wnioski.

PWA to sposób budowy strony, a nie czynnik rankingowy. Google oceni ją jak każdą inną stronę: po treści widocznej po wyrenderowaniu i po wygodzie korzystania na telefonie.

Jeśli rozważasz PWA, zacznij od pytania, czy Twoi klienci potrzebują instalacji i trybu offline. Jeśli tak, wpisz do wymagań projektu HTML z serwera, osobny adres dla każdego widoku i poprawne kody odpowiedzi.

Co dalej: jeśli PWA już działa, przetestuj kilka kluczowych podstron w Search Console, zanim zaczniesz szukać przyczyn spadków ruchu gdzie indziej.

Najczęstsze pytania.

Czy PWA wymaga osobnej domeny albo subdomeny?

Nie. PWA działa pod adresem Twojej strony i najlepiej, żeby na nim została. Przeniesienie aplikacji na subdomenę, np. app., oznacza dla Google nowe adresy i wymaga przekierowań 301.

Czy PWA można opublikować w Google Play?

Tak. PWA można opakować w aplikację na Androida technologią Trusted Web Activity i opublikować w Google Play. Dokumentacja Chrome opisuje do tego narzędzie Bubblewrap. Strona nadal działa pod swoim adresem i indeksuje się w Google jak wcześniej.

Czy PWA działa na iPhonie?

Tak, w Safari można dodać PWA do ekranu początkowego. Od iOS i iPadOS 16.4 tak dodane aplikacje mogą prosić o zgodę na powiadomienia push, jeśli mają manifest z trybem wyświetlania standalone albo fullscreen. Część funkcji działa na iOS inaczej niż na Androidzie, dlatego PWA testuje się na obu systemach.