SEO per PWA

TL;DR — Una PWA (Progressive Web App) è un normale sito web con due extra aggiunti: un manifest che permette alle persone di installarla nella schermata home, e un service worker che può farla funzionare offline. Per Google è comunque solo un sito web — diventare PWA non migliora il tuo posizionamento. L’unica cosa che può davvero danneggiarti è un service worker configurato male che mostra a Google una pagina vecchia e in cache invece di quella live.

Cos’è realmente una PWA

Una Progressive Web App è un sito web potenziato per sembrare più un’app nativa. Due elementi la rendono una PWA:

• Un web app manifest (manifest.json) — un piccolo file che dice al browser il nome, le icone e i colori della tua app, così un visitatore può toccare “Aggiungi alla schermata Home” e ottenere un’icona in stile app e una schermata di avvio.
• Un service worker — un po’ di JavaScript che gira in background e può mettere in cache i file così il sito si carica velocemente nelle visite successive e funziona anche offline.

Tutto qui. Sotto, una PWA è quasi sempre un normale sito web JavaScript (React, Vue, Angular, e così via). È un sito normale travestito da app.

Il grande mito da sfatare

La cosa più comune che la gente crede è: “Se trasformiamo il nostro sito in una PWA, ci classificheremo meglio.” Google ha detto chiaramente che non è vero. John Mueller di Google lo ha detto direttamente: le PWA “attualmente non hanno alcun vantaggio nella Ricerca Google.” Non c’è alcun “bonus PWA” nei sistemi di ranking.

Il file manifest non aiuta nemmeno la SEO. Controlla come l’app si installa — l’icona, il nome, la schermata di avvio — nessuno di questi elementi viene letto da Google quando decide come classificarti.

L’unica cosa che può davvero danneggiare

Il service worker è la parte con cui stare attenti. Poiché può servire una copia in cache (salvata) delle tue pagine, una configurazione sbagliata può finire per mostrare a Google una versione obsoleta o addirittura vuota “sei offline” di una pagina invece di quella reale e aggiornata. Ecco come una PWA perde traffico dopo il lancio — non perché “è diventata una PWA,” ma perché la cache era puntata nella direzione sbagliata.

Cosa fare realmente

• Assicurati che il contenuto reale delle tue pagine venga caricato per i motori di ricerca, non solo un guscio vuoto che si riempie con JavaScript dopo.
• Configura il tuo service worker in modo che recuperi prima l’HTML fresco dalla rete, e solo in caso di necessità ripieghi sulla cache per velocizzare elementi come immagini e fogli di stile.
• Mantieni le basi giuste: URL reali e unici; un buon title e una buona meta description su ogni pagina; un’esperienza veloce e affidabile.

Essere una PWA è fantastico per i tuoi utenti — installabile, veloce, amica dell’offline. Solo non ti aspettare che ti faccia salire su Google, e non lasciare che il service worker dia a Google la pagina sbagliata. La scheda Avanzate ha i meccanismi, le strategie di caching e le citazioni.

TL;DR — Una PWA è un manifest + un service worker sovrapposti a ciò che è quasi sempre un sito JS/SPA — quindi le regole di rendering da JavaScript/SPA SEO si applicano invariate, più due preoccupazioni specifiche delle PWA. Google non dà alle PWA nessun vantaggio di ranking (Mueller). Il manifest.json governa l’installabilità, non l’indicizzazione, e non ci sono prove che i sistemi di ranking lo leggano. Il service worker è il vero rischio: il renderer di Google non esegue i service worker durante l’indicizzazione, quindi una strategia HTML cache-first può indicizzare una shell obsoleta o offline — usa network-first per l’HTML, cache-first per gli asset statici. HTTPS è un requisito rigido per i service worker e separatamente un piccolo segnale di ranking; non concatenare questi in “le PWA si classificano meglio.” Core Web Vitals è l’unica sovrapposizione legittima, ed è l’ingegneria, non l’etichetta PWA.

Una PWA è prima di tutto un sito web

La cornice più utile: una Progressive Web App è un normale sito web con due cose aggiunte sopra. Secondo la definizione di Google, le PWA “sono app web costruite e potenziate con API moderne per fornire capacità avanzate pur raggiungendo qualsiasi utente web su qualsiasi dispositivo con un’unica base di codice.” I tre pilastri che Google nomina sono Capable, Reliable e Installable — nota che nessuno dei tre è “rankable.”

Architetturalmente, quel codebase è quasi sempre un framework JavaScript che esegue un pattern di applicazione a pagina singola. Il che significa: tutto ciò che governa l’indicizzabilità JS/SPA governa l’indicizzabilità PWA, senza modifiche. Link reali <a href> e routing con History-API (non frammenti hash) per l’addressability; rendering lato server o prerendering per la disponibilità dei contenuti; canonical, title e meta per rotta nel DOM renderizzato. Se hai letto il materiale su JavaScript SEO e SPA SEO, conosci già il 90% della PWA SEO — il failure mode dell’app shell, in particolare, è uno che Google documenta esplicitamente: “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.” (traduzione) «Alcuni siti JavaScript possono usare il modello app shell in cui l’HTML iniziale non contiene il contenuto effettivo e Google deve eseguire JavaScript prima di poter vedere il contenuto effettivo della pagina che JavaScript genera.» Una PWA che fornisce una shell vuota senza SSR/prerender eredita direttamente quel problema.

Quindi l’ambito onesto di un articolo specifico per PWA SEO è piccolo: il manifest e il service worker. Tutto il resto è JS/SPA SEO con un manifest.

Il mito centrale: “diventare PWA” non migliora il posizionamento

Questo è il titolo principale. Google è stato insolitamente diretto al riguardo. John Mueller, in una sessione di office-hours di Search Central, ha detto che le PWA “currently don’t have any advantage in Google Search, and as far as I know, there are no plans to change this,” e — alla domanda se convertire in PWA avrebbe aiutato — “By default, saying going to a PWA will make your rankings better — I don’t think that is the case.” (traduzione) «Attualmente non hanno alcun vantaggio nella Ricerca Google e, per quanto ne so, non ci sono piani per cambiare questo» e «Per impostazione predefinita, dire che passare a una PWA migliorerà il tuo posizionamento — non credo che sia il caso.»

Ha anche prevenuto la solita contro-argomentazione, cioè che “il nostro concorrente è passato a PWA e il loro posizionamento è balzato in alto.” La sua risposta: “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.” (traduzione) «Quindi solo il fatto che uno dei tuoi concorrenti sia passato da un framework all’altro e abbia visto un miglioramento nella ricerca, quel cambiamento di framework dal mio punto di vista non sarebbe responsabile di ciò.» E sul perché: “These are essentially different ways of making a website… for the most part, we see these as normal HTML pages.” (traduzione) «Questi sono essenzialmente modi diversi di creare un sito web… per la maggior parte, li vediamo come normali pagine HTML.»

Dove i rilanci PWA correlano con miglioramenti del posizionamento, sono i confondenti che accompagnano qualsiasi grande ricostruzione: linking interno modernizzato, contenuti aggiornati ed espansi, miglioramenti reali della velocità e di solito una spinta di marketing legata al rilancio. Niente di tutto ciò richiede l’etichetta PWA. Se ricostruisci un sito cresciuto organicamente di 10-15 anni, cambi una dozzina di cose contemporaneamente — attribuire il risultato a “PWA” è un errore di correlazione.

Manifest.json: installabilità ≠ indicizzabilità

Il file manifest.json esiste per rendere la tua app installabile. I suoi campi — name, short_name, icons, start_url, display, theme_color — guidano il prompt di installazione, l’icona della schermata home, la splash screen e se l’app si apre standalone o in una scheda del browser. Questo è l’intero lavoro.

Non ci sono prove che i sistemi di ranking o indicizzazione di Google leggano il manifest come segnale. La conferma esterna più chiara è la checklist PWA di Google stessa, che elenca “Is installable” e “Discoverable in search” come due categorie di checklist separate e indipendenti — dove la discoverability è definita come fondamentali SEO ordinari: “Enable search engine discovery through unique URLs, descriptive titles, meta descriptions, and structured data.” (traduzione) «Abilita la scoperta da parte dei motori di ricerca tramite URL unici, titoli descrittivi, meta description e dati strutturati.» Installabilità (guidata dal manifest) e discoverability (SEO classica) sono trattate come preoccupazioni parallele, non una che alimenta l’altra. Quindi: mantieni un manifest valido perché è ciò che rende l’app installabile — semplicemente non metterlo sotto SEO.

Service worker: l’unico vero rischio SEO specifico delle PWA

Ecco il fatto più importante, ed è specifico delle PWA: il servizio di rendering di Google non esegue il tuo service worker quando renderizza una pagina per l’indicizzazione. Il ragionamento, da Martin Splitt: “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.” (traduzione) «Dato che dobbiamo presumere che chi clicca sulla tua pagina da una SERP sia un visitatore alla prima visita, eseguire un service worker di solito non servirà a molto.» Lo scopo di un service worker è accelerare le visite ripetute da una cache — e Googlebot è, per progettazione, sempre trattato come un visitatore alla prima visita, quindi non c’è nulla da accelerare. Splitt di nuovo: “We’re not supporting that because users clicking onto your page from the search result might never have been there beforehand.” (traduzione) «Non lo supportiamo perché gli utenti che cliccano sulla tua pagina dal risultato di ricerca potrebbero non esserci mai stati prima.» Mueller ha confermato che questa è una politica stabile, non uno stato temporaneo: “I wouldn’t expect it to change — it’s computationally expensive to run service-workers in the background like this for indexing.” (traduzione) «Non mi aspetterei che cambi — è computazionalmente costoso eseguire service worker in background in questo modo per l’indicizzazione.»

Allora perché è un rischio? Perché il tuo service worker viene eseguito nei browser degli utenti reali, e se gli hai detto di servire HTML cache-first — restituisci la copia salvata, salta la rete — allora un visitatore ripetuto reale vede una pagina cache veloce, ma è una strategia che Googlebot non esegue mai. Il pericolo è il caso inverso: un pattern di caching che, in qualsiasi condizione di errore o fallback, restituisce un documento obsoleto o la pagina di fallback offline. Poiché il rendering è stateless e il WRS tratta ogni fetch come nuovo, una strategia di caching mal configurata è il modo in cui una PWA finisce con Googlebot che indicizza una shell offline obsoleta o vuota invece del contenuto live.

La regola pratica per la strategia di caching:

• Documenti HTML → network-first (o stale-while-revalidate con TTL breve). Ottieni la pagina live; usa la cache solo come fallback offline e assicurati che quel fallback non sia mai ciò che una scansione fresca indicizzerebbe.
• Asset statici (JS, CSS, immagini, font) → cache-first è giusto e desiderabile — non cambiano per richiesta e non sono il documento indicizzabile.

Come verificarlo: confronta ciò che Googlebot vede con ciò che il browser di un visitatore ripetuto serve dalla cache. Usa URL Inspection in Search Console (test live) per vedere l’HTML renderizzato che Google riceve effettivamente e confrontalo con la pagina live. Se divergono, il tuo service worker o la configurazione SSR è il primo sospetto. E osserva i timeout di rendering su configurazioni ibride — come ha notato Hamlet Batista dall’era del dynamic rendering, “Rendering services won’t wait forever for a page to finish loading.” (traduzione) «I servizi di rendering non aspetteranno per sempre che una pagina finisca di caricarsi.» (Quell’articolo specifico riguarda il dynamic rendering, che Google ora sconsiglia a favore di SSR — cita il principio del timeout, non il pattern.)

HTTPS: un requisito per i service worker e, separatamente, un segnale di ranking minimo

Vedrai post SEO sulle PWA implicare “le PWA richiedono HTTPS, e HTTPS migliora il ranking, quindi le PWA sono più SEO-friendly.” Due fatti veri, collegati in modo errato.

Fatto uno: i service worker funzionano solo in un contesto sicuro. Secondo 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.” (traduzione) «I service worker sono disponibili solo in contesti sicuri: ciò significa che il loro documento è servito su HTTPS, sebbene i browser trattino anche http://localhost come un contesto sicuro, per facilitare lo sviluppo locale.» Questa è una regola della piattaforma browser, non una tattica SEO — niente HTTPS, niente service worker, punto.

Fatto due: HTTPS è un vero segnale di ranking di Google, ma minuscolo. L’annuncio del 2014 di Google: “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.” (traduzione) «Stiamo iniziando a usare HTTPS come segnale di ranking. Per ora è solo un segnale molto leggero — che influisce su meno dell’1% delle query globali e ha meno peso di altri segnali come i contenuti di alta qualità.»

Il punto: qualsiasi sito HTTPS riceve lo stesso minuscolo segnale — PWA o no. Una PWA non ottiene credito SEO extra per HTTPS; semplicemente non può funzionare senza. Non vendere HTTPS come un beneficio SEO delle PWA.

Core Web Vitals: l’unica sovrapposizione legittima

Se c’è un posto reale dove “buona PWA” e “buona SEO” si incontrano, è la performance. La guida PWA di Google inizia con l’affidabilità — “A reliable Progressive Web App feels fast and dependable regardless of the network” (traduzione) «Una Progressive Web App affidabile risulta veloce e affidabile indipendentemente dalla rete» — e i Core Web Vitals sono un fattore di ranking confermato (seppur modesto). Una PWA ben ingegnerizzata che si carica velocemente e rimane reattiva tenderà a ottenere buoni punteggi sui Vitals.

Ma leggi la causalità con attenzione: è l’ingegneria, non l’essere PWA. Una PWA gonfia — bundle JS enorme, hydration che blocca il rendering, un service worker troppo zelante — può facilmente ottenere Core Web Vitals peggiori di una semplice pagina renderizzata lato server. Il vantaggio sui Vitals deriva dal fare bene il lavoro di performance, cosa che potresti fare con o senza un manifest. Essere una PWA non garantisce buoni Vitals né concede una scorciatoia per ottenerli.

Le funzionalità simili alle app sono UX, non fattori di ranking

Aggiunta alla schermata home, modalità offline, notifiche push, navigazione simile alle app — tutti benefici PWA genuini e preziosi, e tutte funzionalità di coinvolgimento/fidelizzazione, non input per l’indicizzazione o il ranking. La checklist PWA di Google rende esplicita la divisione mettendo “installabile” e “scopribile nella ricerca” in categorie separate.

Non trattare “installabile” come una capacità singola e universale — varia a seconda del browser e del sistema operativo, il che è un altro motivo per cui non può essere un segnale SEO (Google non avrebbe un comportamento coerente e cross-browser da premiare). L’evento beforeinstallprompt che permette a una PWA di mostrare la propria UI di installazione personalizzata è un meccanismo solo per Chromium; secondo la guida all’installabilità PWA di MDN, è “not supported on iOS.” (traduzione) «non supportato su iOS.» Su iOS Safari, l’installazione avviene solo tramite il flusso manuale Condividi → Aggiungi alla schermata Home (esteso a Chrome, Edge, Firefox e Orion su iOS 16.4+, tutti usano il motore WebKit richiesto da Apple su iOS e quindi condividono questa limitazione), non un prompt automatico. Nulla di tutto ciò cambia il quadro SEO — significa solo che “la mia PWA è installabile” non è un fatto sì/no indipendente dal browser e dal sistema operativo su cui si trova il visitatore.

Twitter Lite è il caso di studio a cui tutti ricorrono come “prova che le PWA aiutano la SEO” — e i suoi risultati documentati sono reali (un aumento del 65% delle pagine per sessione, aumento del 75% dei Tweet inviati, diminuzione del 20% della frequenza di rimbalzo) — ma ognuno di questi è una metrica di coinvolgimento. Il caso di studio di Google su di esso non menziona mai SEO, ricerca organica o ranking. Ottimo risultato; colonna sbagliata.

Storefront ecommerce PWA: una breve nota

Gli storefront PWA aggiungono alcune complicazioni degne di nota, perché amplificano i rischi delle SPA. Il routing lato client combinato con la navigazione a faccette può generare URL che sembrano crawlable ma che risolvono tutti allo stesso shell, o un’esplosione di URL con parametri. Lo stato del carrello e del checkout vive lato client e non dovrebbe mai bloccare i contenuti di prodotto indicizzabili. E ogni pagina prodotto deve restituire in modo indipendente HTML reale e unico — la trappola dell’app-shell è più costosa proprio dove hai più pagine. Le soluzioni sono le stesse della SEO per ecommerce e navigazione a faccette; il livello PWA non le cambia, rende solo più importante la disciplina di SSR/prerender.

Bing e le PWA

Vale una riga: Bing non ha pubblicato nessuna guida specifica per PWA su ranking o indicizzazione. Le sue linee guida per i webmaster sono agnostiche rispetto alle PWA (crawlability generale, sitemap, robots.txt, IndexNow), e l’ampia documentazione PWA di Microsoft riguarda interamente i prompt di installazione di Edge, PWABuilder e il packaging per Microsoft Store — distribuzione e installazione, un percorso separato dall’indicizzazione nella ricerca web. Quindi per Bing, attieniti alle normali linee guida di crawlability per il rendering JavaScript; non c’è alcuna eccezione PWA da imparare.

Il punto fondamentale

La SEO per PWA è la SEO per JavaScript/SPA più esattamente due aggiunte: ignora il manifest come input SEO (serve per l’installabilità) e configura il service worker in modo che non intrappoli mai Googlebot in una cache obsoleta o offline. Se fai queste cose correttamente, una PWA viene indicizzata esattamente come qualsiasi altro sito ben costruito — nessun bonus, nessuna penalità, solo le stesse regole.

Riepilogo AI

Una sintesi della versione Advanced:

• Una PWA è prima di tutto un sito web. È un manifest.json (installabilità) + un service worker (offline/caching) sovrapposti a ciò che è quasi sempre un sito JS/SPA. Tutte le regole SEO per JavaScript/SPA si applicano senza modifiche.
• Nessun vantaggio di ranking. John Mueller di Google: le PWA “attualmente non hanno alcun vantaggio nella Ricerca Google.” “Diventare PWA” non migliora il ranking.
• Manifest.json è irrilevante per la SEO. Controlla i prompt di installazione, le icone, start_url, display — non ci sono prove che i sistemi di ranking lo leggano. La checklist PWA di Google elenca “installabile” e “rilevabile nella ricerca” come categorie separate.
• L’unico rischio reale è il service worker. Il renderer di Google non esegue i service worker durante l’indicizzazione (tratta ogni crawl come una prima visita), quindi una strategia HTML cache-first può indicizzare una shell obsoleta o offline. Usa network-first per l’HTML, cache-first per gli asset statici.
• HTTPS ≠ un vantaggio SEO per PWA. È un requisito rigido per i service worker (contesto sicuro) e separatamente un segnale di ranking “molto leggero” che ogni sito HTTPS riceve. Non collegare le due cose.
• Core Web Vitals è l’unica sovrapposizione legittima — ed è l’ingegneria delle prestazioni, non l’etichetta PWA. Una PWA gonfia può ottenere un punteggio peggiore.
• Le funzionalità simili alle app (installazione, offline, push) sono coinvolgimento, non ranking. I famosi guadagni di Twitter Lite sono metriche di coinvolgimento; quel case study non menziona mai la SEO. L’installabilità stessa varia a seconda del browser/OS (iOS Safari non ha beforeinstallprompt, solo l’aggiunta manuale alla schermata Home) — un altro motivo per cui non può essere un segnale di ranking.
• Bing non ha linee guida specifiche per PWA; attieniti alla normale crawlability JavaScript.

Documentazione ufficiale

Materiale di fonte primaria su PWA, rendering e i fatti su cui si basa questo articolo.

Google / web.dev

• Cosa sono le Progressive Web App? — La definizione di Google e i tre pilastri (Capable, Reliable, Installable).
• Cosa rende buona una Progressive Web App? (Checklist PWA) — separa “È installabile” da “Rilevabile nella ricerca” come categorie distinte.
• Service worker (Impara PWA) — strategie di caching e ciclo di vita del service worker.
• Comprendi le basi della SEO JavaScript — la modalità di errore dell’app shell documentata da Google.
• Costruire Progressive Web App indicizzabili (2016) — il post originale di Google sull’indicizzabilità delle PWA.
• Case study Twitter Lite — le metriche di coinvolgimento (nota: nessuna affermazione SEO/organica in tutto il documento).
• HTTPS come segnale di ranking (2014) — la dichiarazione del “segnale molto leggero”.

MDN / piattaforma

• API Service Worker — il requisito del contesto sicuro (HTTPS).
• Rendere installabili le PWA — differenze di installabilità tra browser/OS, incluso perché beforeinstallprompt non è supportato su iOS.

Bing / Microsoft (non esiste una guida specifica per il ranking delle PWA — questi sono documenti di installazione/distribuzione)

• Linee guida per i webmaster di Bing — crawlability generale; indipendente dalle PWA.
• Panoramica delle Progressive Web Apps (PWA) — focus su installazione e distribuzione in Edge.

Citazioni dalla fonte

Dichiarazioni pubbliche. Quando una citazione è riportata da una terza parte anziché da un URL di proprietà di Google, la nota lo specifica.

Google — nessun vantaggio di ranking per le PWA

• “PWAs currently don’t have any advantage in Google Search, and as far as I know, there are no plans to change this.” (traduzione) «Le PWA attualmente non hanno alcun vantaggio nella Ricerca Google e, per quanto ne so, non ci sono piani per cambiare questa cosa.» — John Mueller, Google, orari d’ufficio di Search Central (novembre 2021). Leggi la copertura
• “By default, saying going to a PWA will make your rankings better — I don’t think that is the case.” (traduzione) «Di default, dire che passare a una PWA migliorerà il tuo ranking — non credo che sia così.» — John Mueller, stessa sessione. Leggi la copertura
• “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.” (traduzione) «Quindi il semplice fatto che uno dei tuoi concorrenti sia passato da un framework a un altro e abbia visto un miglioramento nella ricerca, quel cambio di framework dal mio punto di vista non ne sarebbe responsabile.» — John Mueller, stessa sessione. Leggi la copertura

Google — cos’è una PWA e il rischio dell’app shell

• “Progressive Web Apps (PWA) are web apps built and enhanced with modern APIs to provide enhanced capabilities while still reaching any web user on any device with a single codebase.” (traduzione) «Le Progressive Web Apps (PWA) sono applicazioni web costruite e potenziate con API moderne per offrire capacità avanzate raggiungendo comunque qualsiasi utente web su qualsiasi dispositivo con un’unica base di codice.» — web.dev. Vai alla citazione
• “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.” (traduzione) «Alcuni siti JavaScript possono usare il modello app shell in cui l’HTML iniziale non contiene il contenuto effettivo e Google deve eseguire JavaScript prima di poter vedere il contenuto reale della pagina che JavaScript genera.» — Google Search Central. Vai alla citazione
• “Enable search engine discovery through unique URLs, descriptive titles, meta descriptions, and structured data.” (traduzione) «Abilita la scoperta da parte dei motori di ricerca tramite URL univoci, titoli descrittivi, meta description e dati strutturati.» — checklist PWA di web.dev, “Rintracciabile nella ricerca.” Vai alla citazione

Google — service worker e indicizzazione (riportato)

• “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.” (traduzione) «Poiché dobbiamo presumere che chi clicca sulla tua pagina da una SERP sia un visitatore alla prima visita, eseguire un service worker di solito non servirà a molto.» — Martin Splitt, Google. Leggi la copertura
• “We’re not supporting that because users clicking onto your page from the search result might never have been there beforehand.” (traduzione) «Non lo supportiamo perché gli utenti che cliccano sulla tua pagina dal risultato di ricerca potrebbero non esserci mai stati prima.» — Martin Splitt, Google (Google I/O 2019). Leggi la copertura
• “I wouldn’t expect it to change — it’s computationally expensive to run service-workers in the background like this for indexing.” (traduzione) «Non mi aspetto che cambi — è computazionalmente costoso eseguire service worker in background in questo modo per l’indicizzazione.» — John Mueller, Google (riportato a luglio 2023). Leggi la copertura

HTTPS: requisito di piattaforma vs. segnale di ranking

• “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.” (traduzione) «I service worker sono disponibili solo in contesti sicuri: ciò significa che il loro documento è servito su HTTPS, sebbene i browser trattino anche http://localhost come contesto sicuro, per facilitare lo sviluppo locale.» — MDN, Service Worker API. Vai alla citazione
• “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.” (traduzione) «stiamo iniziando a usare HTTPS come segnale di ranking. Per ora è solo un segnale molto leggero — che influisce su meno dell’1% delle query globali e ha meno peso di altri segnali come i contenuti di alta qualità.» — Google, “HTTPS as a ranking signal” (2014). Vai alla citazione

L’installabilità varia in base a browser/OS

• “This is not supported on iOS.” (traduzione) «Questo non è supportato su iOS.» — MDN, sull’evento beforeinstallprompt per il prompt di installazione personalizzato. Vai alla citazione

Sui timeout di rendering (contesto datato)

• “Rendering services won’t wait forever for a page to finish loading.” (traduzione) «I servizi di rendering non aspetteranno per sempre che una pagina finisca di caricarsi.» — Hamlet Batista, Search Engine Land. Leggi l’articolo

Dovrei passare alla PWA — e cosa farà per la SEO?

Una rapida panoramica delle domande che le persone portano realmente su questo argomento.

“Stiamo considerando una PWA. Aiuterà la nostra SEO?”

• Nessun beneficio intrinseco di ranking — Google dice che le PWA non ottengono alcun vantaggio nella Ricerca. → Costruisci una PWA per i benefici utente (installabile, offline, ricariche rapide), non per i ranking. → Non danneggerà nemmeno la SEO, purché il tuo rendering e il service worker siano configurati correttamente (continua sotto).

“Stiamo costruendo/abbiamo una PWA. Il mio contenuto è effettivamente indicizzabile?”

• L’HTML iniziale contiene il contenuto reale (SSR/prerender), o è un guscio app vuoto riempito da JS?
  • Guscio vuoto, senza SSR → questa è la trappola del guscio app. Aggiungi SSR o prerendering prima di preoccuparti di qualsiasi cosa specifica della PWA. (Stessa soluzione di qualsiasi SPA.)
  • SSR/prerender in atto → bene; passa al service worker.

“Come dovrebbe il mio service worker memorizzare nella cache le pagine?”

• Documenti HTML → network-first (o stale-while-revalidate, TTL breve). Mai cache-first per HTML.
• Asset statici (JS/CSS/immagini/font) → cache-first va bene ed è buono.
• Pagina di fallback offline → assicurati che non possa mai essere la versione che una scansione fresca indicizza.

“La mia PWA ha perso ranking/traffico dopo il lancio. Dove guardo?”

1. Esegui URL Inspection (test live) in Search Console — Google vede la pagina reale o una stantia/offline/vuota?
2. Se stantia o vuota → sospetta la strategia di caching del service worker (HTML cache-first) o un passaggio SSR mancante.
3. Se il contenuto c’è ma i ranking sono comunque calati → guarda cos’altro la ricostruzione ha cambiato: link interni, contenuti, redirect, velocità. L’etichetta PWA è raramente la causa.

“Devo fare qualcosa di speciale con il manifest per la SEO?”

• No. Mantienilo valido per l’installabilità; non ha alcun ruolo SEO. Investi gli sforzi su URL, titoli, meta, dati strutturati e Core Web Vitals.

Checklist SEO per PWA

Passaggio scansionabile per mantenere una Progressive Web App indicizzabile e scansionabile:

• Il contenuto reale è renderizzato lato server o prerenderizzato — non un guscio app vuoto riempito da JavaScript dopo il caricamento.
• Ogni rotta ha un URL reale e unico tramite l’API History (niente routing hash/#!).
• Ogni rotta restituisce il proprio canonical, title e meta description nel DOM renderizzato.
• Il service worker serve HTML network-first (o stale-while-revalidate, TTL breve) — mai cache-first per i documenti HTML.
• Gli asset statici (JS/CSS/immagini/font) possono essere cache-first; va bene.
• La pagina di fallback offline non può mai essere ciò che una scansione fresca indicizza.
• URL Inspection (test live) mostra a Google la pagina reale e corrente — confrontata con la pagina live.
• Il manifest è valido per l’installabilità, ma non lo tratti come una leva SEO.
• L’installabilità è testata per browser/OS, non assunta universale (iOS Safari non ha beforeinstallprompt; è manuale Aggiungi a Home Screen) — e nessuna di queste variazioni è trattata come un problema SEO.
• Servito su HTTPS (richiesto comunque per i service worker).
• Core Web Vitals sono sani — verifica che il bundle JS e l’idratazione non stiano trascinando LCP/INP.
• Ecommerce: le pagine prodotto restituiscono ciascuna HTML unico reale; la navigazione a faccette/routing client non sta generando URL solo-guscio o URL con parametri infiniti.

PWA SEO — cheat sheet

Influisce sulla SEO?

Caching del service worker per tipo di risorsa

Fatti rapidi

• Google non dà alle PWA nessun vantaggio di ranking (Mueller).
• Il renderer di Google non esegue i service worker durante l’indicizzazione.
• Segnale di ranking HTTPS: “fewer than 1% of global queries” (traduzione) «meno dell’1% delle query globali» (Google, 2014).
• Bing: nessuna guida specifica per PWA — trattala come qualsiasi sito JS.

Playbook per incidenti: il traffico di ricerca è calato dopo un rilascio PWA

1. Congela il percorso di rilascio. Interrompi ulteriori deployment di service worker e routing mentre preservi lo stato di produzione non funzionante e gli identificatori di rilascio.
2. Conferma l’ambito. Segmenta il calo per template, directory, dispositivo e tempo di deployment. Un guasto a livello di PWA non dovrebbe essere ipotizzato da una singola rotta rotta.
3. Confronta tre risposte. Salva la risposta HTTP grezza, una pagina appena renderizzata con storage cancellato e una pagina di utente di ritorno controllata dal service worker. Controlla il titolo, il canonical, le direttive robots, il contenuto principale, i link e il comportamento di stato.
4. Ispeziona la registrazione e la politica di cache. In DevTools Application, identifica il worker attivo, il suo scope, le versioni in attesa, i nomi delle cache e il gestore di navigazione. Conferma che le navigazioni HTML non siano intrappolate dietro una vecchia risposta cache-first.
5. Bypassa il worker. Disregistralo o usa l’opzione di bypass di DevTools, ricarica e ripeti la rotta interessata. Se il difetto scompare, il worker o la sua cache è il confine probabile; se rimane, continua come un normale incidente SEO JavaScript.
6. Ripristina un percorso di navigazione sicuro. Ripristina il worker o cambia le richieste di documenti a network-first con un fallback offline esplicito. Non eliminare tutte le cache alla cieca se gli utenti dipendono dai dati offline.
7. Valida e monitora. Testa un browser pulito, un browser in aggiornamento e un browser offline. Poi ispeziona URL rappresentativi e osserva le prestazioni di ricerca attraverso la normale finestra di re-crawl.

Trattare il manifest come un file SEO

Riempire di parole chiave name, short_name o metadati delle icone non rende le pagine più indicizzabili. Usa il manifest per il comportamento di installazione e metti il contenuto rilevante per la ricerca in HTML crawlabile con titoli, link e canonical ordinari.

Mettere in cache l’HTML per sempre

Una regola cache-first che tratta le navigazioni come asset immutabili può mantenere in vita vecchie copie, canonical o direttive robots dopo un rilascio. Metti in cache in modo aggressivo JS, CSS e immagini versionati; dai all’HTML una strategia di aggiornamento consapevole della rete.

Restituire la shell offline come pagina di successo

Servire la stessa shell dell’app offline per ogni URL non disponibile può sembrare che molti URL diversi restituiscano contenuto sottile identico. Mantieni l’esperienza offline chiaramente separata dalla navigazione normale e non fingere che un documento mancante sia la pagina richiesta.

Nascondere la navigazione dietro controlli non-link

Un pulsante che cambia lo stato del client può funzionare nell’app senza fornire un percorso <a href> crawlabile verso la destinazione. Usa link reali per le rotte che i motori di ricerca e gli utenti devono seguire, poi migliora la transizione con JavaScript.

Testare solo come utente di ritorno con cache calda

Un browser di sviluppo con un worker installato e cache popolata può mascherare una prima visita rotta. Testa storage pulito, un aggiornamento dal worker precedente e una visita di ritorno. Questi sono stati PWA distinti.

Esempio: la cache degli asset e la cache dei documenti richiedono regole diverse

La seguente logica semplificata del service worker mostra il confine. Gli asset con hash possono essere cache-first; le navigazioni dei documenti dovrebbero provare la rete prima di cadere in fallback.

self.addEventListener('fetch', event => {
  const request = event.request;

  if (request.mode === 'navigate') {
    event.respondWith(
      fetch(request).catch(() => caches.match('/offline/'))
    );
    return;
  }

  if (['script', 'style', 'image', 'font'].includes(request.destination)) {
    event.respondWith(
      caches.match(request).then(cached => cached || fetch(request))
    );
  }
});

La politica di produzione esatta dipende dai requisiti di aggiornamento e offline, ma la lezione SEO è stabile: l’HTML non è lo stesso tipo di asset immutabile di un bundle con fingerprint.

Esempio: rotta crawlabile versus stato solo-app

<!-- Search engines and users get a real destination. -->
<a href="/products/running-shoes/">Running shoes</a>

<!-- This changes app state but exposes no destination URL. -->
<button onclick="showCategory('running-shoes')">Running shoes</button>

Una PWA può intercettare il link per una transizione simile a un’app senza rimuovere il suo URL crawlabile.

Prompt: rivedi una strategia di caching del service worker

Incolla il sorgente del worker e un inventario delle rotte. Non includere segreti o risposte API private.

Audit this service worker for search and freshness risks. Classify each fetch route as
document navigation, versioned static asset, API response, media, or offline fallback.
For each route, state the current strategy, the stale-content failure mode, and a safer
strategy. Pay special attention to HTML served cache-first, redirect handling, offline
shells returned for real URLs, cache-version cleanup, and worker scope. Quote the exact
code that creates each finding. Do not claim that PWA features provide a ranking boost.

Route inventory:
[PASTE ROUTES AND CONTENT TYPES]

Service worker:
[PASTE SOURCE]

Prompt: costruisci una matrice QA di rilascio PWA

Create a release QA matrix for this PWA. Cover a clean first visit, a returning visit
with the current worker, an upgrade from the previous worker, offline navigation, and a
worker-bypassed visit. For each state, list how to reproduce it and what to compare in
the raw response and rendered page: status behavior, title, canonical, robots, primary
content, internal links, and freshness. Use only the routes and requirements I provide;
flag missing evidence instead of inventing expected results.

Routes and requirements:
[PASTE ROUTE | EXPECTED CONTENT | OFFLINE REQUIREMENT | RELEASE CHANGE]

Il framework SHELL per le revisioni SEO delle PWA

• S: Risposta del server. Una prima risposta utilizzabile, o una strategia di rendering deliberata, deve esporre la pagina piuttosto che solo un guscio applicativo vuoto.
• H: Href. Le rotte importanti utilizzano link crawlabili con URL stabili, non controlli che esistono solo come stato lato client.
• E: Metadati attesi. Titoli, canonical, direttive robots e dati strutturati rimangono corretti negli stati grezzi e renderizzati.
• L: Documenti live. Le richieste di navigazione hanno una politica di freschezza appropriata per HTML; i documenti cache obsoleti non sopravvivono silenziosamente alle release.
• L: Test del ciclo di vita. Il QA copre installazione, attivazione, aggiornamento, worker in attesa, offline, e stati di bypass invece di una singola sessione di sviluppo a caldo.

Il framework mantiene la revisione specifica PWA ristretta. Se tutti e cinque passano, la maggior parte del lavoro rimanente è normale JavaScript, prestazioni e QA di indicizzabilità.

Console DevTools: ispeziona il worker attivo e le cache

Esegui questo nella console DevTools del browser sulla PWA. Riporta le registrazioni e i nomi delle cache senza modificarli.

const registrations = await navigator.serviceWorker.getRegistrations();
console.table(registrations.map(r => ({
  scope: r.scope,
  active: r.active?.scriptURL || '',
  waiting: r.waiting?.scriptURL || '',
  installing: r.installing?.scriptURL || ''
})));
console.log('Caches:', await caches.keys());

Console DevTools: confronta una richiesta di rete con una risposta cache

const path = location.pathname;
const network = await fetch(path, { cache: 'no-store' });
const cached = await caches.match(path);
console.table({
  network: { status: network.status, type: network.type },
  cache: { found: Boolean(cached), status: cached?.status ?? '' }
});

Il risultato dimostra che una risposta esiste in una cache; non dimostra quale gestore di fetch vincerà per ogni navigazione. Conferma il routing nel codice sorgente del worker e nel pannello Network.

Regex: trova gestori di navigazione cache-first rischiosi

Usa questo come ausilio di revisione, non come parser. Cerca una condizione di navigazione seguita vicino da una ricerca in cache.

request\.mode\s*===?\s*['"]navigate['"][\s\S]{0,500}caches\.(?:match|open)\s*\(

Valida una release SEO PWA

Mettiti alla prova: SEO PWA

Cinque domande rapide su come le Progressive Web App interagiscono con la ricerca. Scegli una risposta per ciascuna, poi controlla.

Risorse che meritano il tuo tempo

I miei scritti correlati

• Problemi e migliori pratiche SEO JavaScript — la base di rendering su cui ogni PWA si basa; app-shell, SSR e cosa fa e non fa il renderer di Google.
• La guida per principianti alla SEO tecnica — dove rendering e crawlabilità si inseriscono nel quadro più ampio.

I miei interventi

• Come funziona la ricerca (SlideShare) — la mia spiegazione di crawling, rendering, indicizzazione e ranking, il percorso che una PWA deve attraversare. (Disclaimer permanente: “This is my understanding of systems… not going to be 100% complete or accurate.” (traduzione) «Questa è la mia comprensione dei sistemi… non sarà completa o accurata al 100%.»)

Dal settore

• Google: le Progressive Web App non si posizionano meglio dei siti normali (Search Engine Journal) — la copertura delle office hours di Mueller che fa da base alla sfatatura del mito.
• Google dice che le Progressive Web App (PWA) non hanno alcun vantaggio nella ricerca (Search Engine Roundtable) — resoconto indipendente della stessa sessione.
• Service Worker – cosa devono sapere gli SEO (SearchViu) — le dichiarazioni di Splitt/Mueller sul motivo per cui il renderer salta i service worker.
• Comprendi le basi della SEO JavaScript (Google) — la modalità di errore dell’app shell, documentata alla fonte.
• Cosa rende una buona Progressive Web App? (checklist PWA) (web.dev) — installabilità e rilevabilità come categorie separate.
• Caso di studio Twitter Lite (web.dev) — i numeri reali di coinvolgimento e la prova che non riguardavano mai la SEO.

Video

• Google Search Central (YouTube) — gli explainer di Martin Splitt su JavaScript SEO e rendering coprono l’esatto pipeline (crawl → render → index) da cui dipende una PWA, incluso come il renderer stateless gestisce il JS. Canale

Cronologia modifiche