Języki

PWA i SEO

SEO dla progresywnych aplikacji internetowych — dlaczego "przejście na PWA" nie poprawia pozycji w wynikach wyszukiwania, dlaczego manifest.json jest nieistotny dla SEO, jak źle skonfigurowany service worker może serwować Googlebotowi nieaktualną pamięć podręczną oraz gdzie Core Web Vitals i HTTPS faktycznie (i nie) pokrywają się z SEO.

Opublikowano po raz pierwszy: 3 lip 2026 · Ostatnia aktualizacja: 3 sie 2026 · Zaawansowane
AIAutor:AI v2

PWA to strona internetowa wzbogacona o manifest i service workera — dla Google to nadal zwykła (zwykle JavaScript/SPA) strona, bez żadnej wrodzonej przewagi w rankingu. manifest.json jest nieistotny dla SEO (kontroluje instalowalność, nie indeksowanie). Jedynym realnym ryzykiem specyficznym dla PWA jest service worker: renderer Google nie uruchamia service workerów podczas indeksowania, więc strategia cache-first dla HTML może dostarczyć Googlebotowi nieaktualną lub offline'ową stronę. Rozwiąż to za pomocą network-first dla HTML, a reszta to zwykłe SEO dla JS/SPA.

TL;DR — PWA to manifest + service worker nałożone na to, co prawie zawsze jest stroną JS/SPA — więc zasady renderowania z SEO dla JavaScript/SPA obowiązują bez zmian, plus dwie kwestie specyficzne dla PWA. Google nie daje PWA żadnej przewagi w rankingu (Mueller). manifest.json reguluje instalowalność, a nie indeksowanie, i nie ma dowodów, że systemy rankingowe go czytają. Service worker to realne ryzyko: renderer Google nie uruchamia service workerów podczas indeksowania, więc strategia HTML cache-first może zaindeksować nieaktualną lub offline’ową powłokę — użyj network-first dla HTML, cache-first dla zasobów statycznych. HTTPS to twardy wymóg dla service workerów oraz osobno mały sygnał rankingowy; nie łącz tych w “PWA lepiej pozycjonują.” Core Web Vitals to jedyne uzasadnione nakładanie się, i to kwestia inżynierii, a nie etykiety PWA.

Dowód potwierdzający to twierdzenie A progressive web app is still a web application; installability features do not replace indexable HTML and URLs. Zakres: Current official or standards documentation. Poziom ufności: wysoki · Zweryfikowano: web.dev: Progressive web apps Dowód potwierdzający to twierdzenie JavaScript applications must expose crawlable links, meaningful content, metadata, and status behavior to Google. Zakres: Current official or standards documentation. Poziom ufności: wysoki · Zweryfikowano: Google: JavaScript SEO basics

PWA to przede wszystkim strona internetowa

Najbardziej użyteczna perspektywa: Progressive Web App to normalna strona internetowa z dwiema rzeczami dodanymi na wierzch. Według definicji Google, PWA “to aplikacje webowe zbudowane i ulepszone za pomocą nowoczesnych API, aby zapewnić rozszerzone możliwości, jednocześnie docierając do każdego użytkownika sieci na dowolnym urządzeniu z jednej bazy kodu.” Trzy filary, które wymienia Google, to Capable, Reliable i Installable — zauważ, że żaden z tych trzech nie jest “rankable”.

Architektonicznie ten kod to prawie zawsze framework JavaScript działający w wzorcu single-page application. Co oznacza: wszystko, co rządzi indeksowalnością JS/SPA, rządzi indeksowalnością PWA, bez żadnych modyfikacji. Prawdziwe linki <a href> i routing oparty na History API (nie fragmenty hash) dla adresowalności; renderowanie po stronie serwera lub prerenderowanie dla dostępności treści; kanoniczne, tytuł i meta dla każdej trasy w wyrenderowanym DOM. Jeśli czytałeś materiały o SEO dla JavaScript i SEO dla SPA, znasz już 90% SEO dla PWA — szczególnie tryb awarii app-shell, który Google wprost dokumentuje: “Some JavaScript sites may use the app shell model where the initial HTML does not contain the actual content and Google needs to execute JavaScript before being able to see the actual page content that JavaScript generates.” (tłumaczenie) „Niektóre strony JavaScript mogą używać modelu app shell, gdzie początkowy HTML nie zawiera rzeczywistej treści, a Google musi wykonać JavaScript, zanim będzie w stanie zobaczyć rzeczywistą treść strony generowaną przez JavaScript.” PWA, które wysyła pustą powłokę bez SSR/prerenderowania, dziedziczy ten problem bezpośrednio.

Więc uczciwy zakres artykułu o SEO specyficznego dla PWA jest mały: manifest i service worker. Wszystko inne to SEO dla JS/SPA w manifeście.

Główny mit: „przejście na PWA” nie poprawia pozycji w wynikach wyszukiwania

To jest nagłówek. Google był w tej kwestii niezwykle bezpośredni. John Mueller, podczas sesji pytań i odpowiedzi w Search Central, powiedział, że PWA “currently don’t have any advantage in Google Search, and as far as I know, there are no plans to change this,” (tłumaczenie) „obecnie nie mają żadnej przewagi w Google Search i o ile mi wiadomo, nie ma planów, aby to zmienić” — a zapytany, czy konwersja na PWA pomoże — “By default, saying going to a PWA will make your rankings better — I don’t think that is the case.” (tłumaczenie) „Domyślnie, mówienie, że przejście na PWA poprawi twoje pozycje — nie sądzę, żeby tak było.”

Uprzedził też zwykły kontrargument, że „nasz konkurent przeszedł na PWA i ich pozycje wzrosły.” Jego odpowiedź: “So just the fact that one of your competitors has moved from one framework to another, and has seen an improvement in search, that framework change from my point of view wouldn’t be responsible for that.” (tłumaczenie) „Sam fakt, że jeden z twoich konkurentów przeszedł z jednego frameworka na inny i zauważył poprawę w wyszukiwaniu, ta zmiana frameworka z mojego punktu widzenia nie byłaby za to odpowiedzialna.” A dlaczego: “These are essentially different ways of making a website… for the most part, we see these as normal HTML pages.” (tłumaczenie) „To są zasadniczo różne sposoby tworzenia strony internetowej… w większości przypadków postrzegamy je jako normalne strony HTML.”

Tam, gdzie ponowne uruchomienie PWA faktycznie koreluje ze wzrostem pozycji, winne są czynniki zakłócające, które towarzyszą każdej dużej przebudowie: zmodernizowane linkowanie wewnętrzne, odświeżona i rozszerzona treść, rzeczywista poprawa szybkości i zwykle kampania marketingowa związana z ponownym uruchomieniem. Żadne z tego nie wymaga etykiety PWA. Jeśli przebudowujesz 10–15-letnią organicznie rozwijaną stronę, zmieniasz kilkanaście rzeczy naraz — przypisywanie wyniku „PWA” to błąd korelacji.

Wypowiedzi Muellera z godzin biurowych powyżej są przekazane przez Search Engine Journal i niezależnie przez Search Engine Roundtable, relacjonujące tę samą sesję z listopada 2021; nie odtworzyłem oryginalnego wideo, więc traktuj je jako oficjalnie przekazane.

Manifest.json: instalowalność ≠ indeksowalność

Plik manifest.json istnieje po to, aby uczynić Twoją aplikację instalowalną. Jego pola — name, short_name, icons, start_url, display, theme_color — sterują monitem instalacji, ikoną na ekranie głównym, ekranem powitalnym oraz tym, czy aplikacja otwiera się samodzielnie, czy w karcie przeglądarki. To całe zadanie.

Nie ma dowodów na to, że systemy rankingu lub indeksowania Google czytają manifest jako sygnał. Najczystszym zewnętrznym potwierdzeniem jest własna lista kontrolna PWA Google, która wymienia “Is installable” (tłumaczenie) „Czy jest instalowalna” i “Discoverable in search” (tłumaczenie) „Czy jest wykrywalna w wyszukiwarce” jako dwie oddzielne, niezależne kategorie na liście kontrolnej — gdzie wykrywalność jest zdefiniowana jako zwykłe podstawy SEO: “Enable search engine discovery through unique URLs, descriptive titles, meta descriptions, and structured data.” (tłumaczenie) „Umożliw wykrywanie przez wyszukiwarki dzięki unikalnym adresom URL, opisowym tytułom, meta opisom i danym strukturalnym.” Instalowalność (sterowana manifestem) i wykrywalność (klasyczne SEO) są traktowane jako równoległe kwestie, a nie jedna zasilająca drugą. Więc: zachowaj ważny manifest, bo to on sprawia, że aplikacja jest instalowalna — po prostu nie klasyfikuj go jako SEO.

Google nie publikuje strony, która wprost stwierdza, że manifest.json jest wykluczony z rankingu; jest to dobrze uzasadniony wniosek wynikający ze stwierdzenia o „braku przewagi”, rozdzielenia tych dwóch kategorii na liście kontrolnej oraz całkowitego braku manifestu w dokumentacji Google dotyczącej czynników rankingowych — sformułuj to jako „brak dowodów, że jest odczytywany”, a nie „potwierdzone ignorowanie”.

Service workery: jedyne realne ryzyko SEO specyficzne dla PWA

Oto fakt, który ma największe znaczenie i jest specyficzny dla PWA: usługa renderowania Google nie uruchamia Twojego service workera, gdy renderuje stronę do indeksowania. Rozumowanie, według Martina Splitta: “As we have to assume that someone clicking on your page from a SERP is a first-time visitor, running a service worker is usually not going to do much good.” (tłumaczenie) „Ponieważ musimy założyć, że ktoś klikający Twoją stronę z SERP jest gościem odwiedzającym ją po raz pierwszy, uruchomienie service workera zwykle nie przyniesie wiele dobrego”. Cały sens service workera polega na przyspieszaniu powtórnych wizyt z pamięci podręcznej — a Googlebot jest z założenia zawsze traktowany jak gość odwiedzający po raz pierwszy, więc nie ma czego przyspieszać. Splitt ponownie: “We’re not supporting that because users clicking onto your page from the search result might never have been there beforehand.” (tłumaczenie) „Nie wspieramy tego, ponieważ użytkownicy klikający na Twoją stronę z wyniku wyszukiwania mogli nigdy wcześniej na niej nie być”. Mueller potwierdził, że jest to stabilna polityka, a nie stan przejściowy: “I wouldn’t expect it to change — it’s computationally expensive to run service-workers in the background like this for indexing.” (tłumaczenie) „Nie spodziewałbym się, że to się zmieni — uruchamianie service workerów w tle w ten sposób do celów indeksowania jest kosztowne obliczeniowo”.

Te trzy wypowiedzi są przekazane przez SearchViu (Splitt na Google I/O 2019/2020; Mueller cytowany w lipcu 2023); potwierdziłem cytaty Splitta i Muellera jako dokładne podciągi na tej stronie, ale jest to przekaz strony trzeciej, a nie adres URL należący do Google. Zauważ też, że „nigdy nie uruchamia” jest nieco zbyt absolutne — Splitt z Google wskazał, że web workery mogą czasami być wykonywane; bezpieczne sformułowanie to “the rendering service doesn’t run service workers by design,” (tłumaczenie) „usługa renderowania z założenia nie uruchamia service workerów”, a nie „w żadnych okolicznościach”.

Dlaczego więc to ryzyko? Ponieważ Twój service worker działa w przeglądarkach prawdziwych użytkowników, a jeśli kazałeś mu serwować HTML w trybie cache-first — zwróć zapisaną kopię, pomiń sieć — to prawdziwy powracający gość zobaczy szybką stronę z pamięci podręcznej, ale jest to strategia, której Googlebot nigdy nie wykonuje. Zagrożenie jest w odwrotnym przypadku: wzorzec buforowania, który w dowolnym stanie błędu lub awarii zwraca nieaktualny dokument lub stronę offline-fallback. Ponieważ renderowanie jest bezstanowe, a WRS traktuje każde pobranie jako świeże, źle skonfigurowana strategia buforowania to sposób, w jaki PWA kończy z Googlebotem indeksującym nieaktualną lub pustą powłokę offline zamiast aktualnych treści.

Zasada kciuka strategii buforowania:

  • Dokumenty HTML → network-first (lub stale-while-revalidate z krótkim TTL). Pobierz aktualną stronę; używaj pamięci podręcznej tylko jako fallbacku offline i upewnij się, że ten fallback nigdy nie jest tym, co świeże przeszukiwanie by zaindeksowało.
  • Statyczne zasoby (JS, CSS, obrazy, czcionki) → cache-first jest w porządku i pożądane — nie zmieniają się przy każdym żądaniu i nie są dokumentem podlegającym indeksowaniu.

Jak to audytować: porównaj to, co widzi Googlebot, z tym, co przeglądarka powracającego gościa serwuje z pamięci podręcznej. Użyj URL Inspection w Search Console (test na żywo), aby zobaczyć wyrenderowany HTML, który Google faktycznie otrzymuje, i porównaj go z aktualną stroną. Jeśli się różnią, Twój service worker lub konfiguracja SSR jest pierwszym podejrzanym. Zwróć też uwagę na limity czasu renderowania w konfiguracjach hybrydowych — jak zauważył Hamlet Batista z epoki dynamicznego renderowania, “Rendering services won’t wait forever for a page to finish loading.” (tłumaczenie) „Usługi renderowania nie będą czekać w nieskończoność, aż strona zakończy ładowanie”. (Ten konkretny artykuł dotyczy dynamicznego renderowania, które Google obecnie odradza na rzecz SSR — cytuj zasadę limitu czasu, a nie wzorzec.)

HTTPS: wymóg dla service workerów i osobno mały sygnał rankingowy

Zobaczysz, że posty o SEO dla PWA sugerują: „PWA wymagają HTTPS, a HTTPS poprawia rankingi, więc PWA są bardziej przyjazne SEO.” Dwa prawdziwe fakty, błędnie połączone.

Fakt pierwszy: service workery działają tylko w bezpiecznym kontekście. Według MDN: “Service workers are only available in secure contexts: this means that their document is served over HTTPS, although browsers also treat http://localhost as a secure context, to facilitate local development.” (tłumaczenie) „Service workery są dostępne tylko w bezpiecznych kontekstach: oznacza to, że ich dokument jest serwowany przez HTTPS, chociaż przeglądarki traktują również http://localhost jako bezpieczny kontekst, aby ułatwić lokalne programowanie.” To reguła platformy przeglądarki, a nie taktyka SEO — bez HTTPS nie ma service workera, kropka.

Fakt drugi: HTTPS to realny sygnał rankingowy Google, ale bardzo mały. Ogłoszenie Google z 2014 roku: “we’re starting to use HTTPS as a ranking signal. For now it’s only a very lightweight signal — affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content.” (tłumaczenie) „zaczynamy używać HTTPS jako sygnału rankingowego. Na razie to tylko bardzo lekki sygnał — wpływający na mniej niż 1 % globalnych zapytań i mający mniejszą wagę niż inne sygnały, takie jak treści wysokiej jakości.”

Sedno: każda strona z HTTPS dostaje ten sam mały sygnał — niezależnie od tego, czy jest PWA, czy nie. PWA nie dostaje dodatkowego kredytu SEO za HTTPS; po prostu nie może bez niego działać. Nie sprzedawaj HTTPS jako korzyści SEO z PWA.

Core Web Vitals: jedyne uzasadnione nakładanie się

Jeśli istnieje realne miejsce, gdzie „dobre PWA” i „dobre SEO” się spotykają, to jest to wydajność. Wytyczne Google dotyczące PWA zaczynają się od niezawodności — “A reliable Progressive Web App feels fast and dependable regardless of the network” (tłumaczenie) „Niezawodna progresywna aplikacja internetowa działa szybko i pewnie niezależnie od sieci” — a Core Web Vitals to potwierdzony (choć skromny) czynnik rankingowy. Dobrze zaprojektowane PWA, które ładuje się szybko i pozostaje responsywne, będzie zwykle dobrze wypadać w Vitals.

Ale przeczytaj uważnie związek przyczynowy: to inżynieria, a nie bycie PWA. Rozdmuchane PWA — ogromny pakiet JS, renderowanie blokujące renderowanie, zbyt gorliwy service worker — może łatwo osiągnąć gorsze wyniki Core Web Vitals niż zwykła strona renderowana po stronie serwera. Zwycięstwo w Vitals wynika z dobrego wykonania pracy nad wydajnością, co można zrobić z manifestem lub bez. Bycie PWA ani nie gwarantuje dobrych wyników Vitals, ani nie daje do nich skrótu.

Funkcje przypominające aplikacje to UX, a nie czynniki rankingowe

Dodawanie do ekranu głównego, tryb offline, powiadomienia push, nawigacja przypominająca aplikację — wszystkie to prawdziwe, wartościowe korzyści PWA i wszystkie to funkcje zaangażowania/utrzymania, a nie czynniki indeksowania czy rankingu. Lista kontrolna PWA Google wyraźnie pokazuje ten podział, umieszczając „installable” i „discoverable in search” w osobnych kategoriach.

Nie traktuj też „installable” jako jednej, uniwersalnej możliwości — różni się ona w zależności od przeglądarki i systemu operacyjnego, co jest kolejnym powodem, dla którego nie może być sygnałem SEO (Google nie miałby spójnego, międzyprzeglądarkowego zachowania do nagradzania). Zdarzenie beforeinstallprompt, które pozwala PWA pokazać własny niestandardowy interfejs instalacji, to mechanizm tylko w Chromium; według przewodnika instalowalności PWA od MDN jest ono “not supported on iOS.” (tłumaczenie) „nieobsługiwane na iOS.” W iOS Safari instalacja odbywa się tylko przez ręczny przepływ Share → Add to Home Screen (rozszerzony na Chrome, Edge, Firefox i Orion w iOS 16.4+, które wszystkie używają wymaganego przez Apple silnika WebKit na iOS i dlatego mają to samo ograniczenie), a nie przez automatyczny monit. Żadne z tych nie zmienia obrazu SEO — oznacza to po prostu, że „czy moje PWA jest instalowalne” nie jest faktem typu tak/nie niezależnym od tego, w jakiej przeglądarce i systemie operacyjnym jest odwiedzający.

Twitter Lite to studium przypadku, po które wszyscy sięgają jako „dowód, że PWA pomaga SEO” — a jego udokumentowane wyniki są realne (wzrost o 65 % liczby stron na sesję, wzrost o 75 % liczby wysłanych tweetów, spadek o 20 % współczynnika odrzuceń) — ale każdy z nich to metryka zaangażowania. Własne studium przypadku Google nigdy nie wspomina o SEO, wyszukiwaniu organicznym ani rankingach. Świetny wynik; zła kolumna.

Sklepy ecommerce PWA: krótka uwaga

Sklepy PWA dodają kilka zmarszczek, które warto wymienić, ponieważ pogłębiają ryzyka SPA. Routing po stronie klienta plus nawigacja fasetowa mogą generować adresy URL wyglądające na indeksowalne, które wszystkie prowadzą do tej samej powłoki, lub eksplozję adresów URL z parametrami. Stan koszyka i kasy żyje po stronie klienta i nigdy nie powinien blokować indeksowalnej treści produktu. A każda strona produktu musi niezależnie zwracać prawdziwy, unikalny HTML — pułapka powłoki aplikacji jest najdroższa dokładnie tam, gdzie masz najwięcej stron. Rozwiązania są te same co w SEO ecommerce i nawigacji fasetowej; warstwa PWA ich nie zmienia, po prostu czyni dyscyplinę SSR/prerenderowania ważniejszą.

Bing i PWA

Warto dodać: Bing nie opublikował żadnych wytycznych dotyczących rankingu ani indeksowania specyficznych dla PWA. Jego wytyczne dla webmasterów są niezależne od PWA (ogólna możliwość indeksowania, sitemapy, robots.txt, IndexNow), a obszerne dokumenty Microsoftu dotyczące PWA dotyczą wyłącznie monitów instalacyjnych w Edge, PWABuilder i pakowania w Microsoft Store — dystrybucji i instalacji, czyli osobnego toru od indeksowania w wyszukiwarce. Dlatego w przypadku Binga stosuj standardowe wytyczne dotyczące indeksowania renderowania JS; nie ma żadnego wyjątku PWA, którego trzeba się uczyć.

Najważniejszy wniosek

SEO dla PWA to SEO dla JavaScript/SPA plus dokładnie dwa dodatki: zignoruj manifest jako element SEO (służy do instalowalności) i skonfiguruj service workera tak, aby nigdy nie uwięził Googlebota w nieaktualnej lub offline’owej pamięci podręcznej. Jeśli to zrobisz, PWA będzie indeksowane dokładnie jak każda inna dobrze zbudowana strona — bez bonusu, bez kary, tylko te same zasady.

Dodaj notatkę eksperta

Przypnij cytat eksperta

Nowa osoba? Najpierw utwórz jej nieprzejęty profil na /admin/experts/ → Przypnij cytat eksperta .