SEO para PWA

TL;DR — Uma PWA (Progressive Web App) é um site normal com dois extras adicionados: um manifest que permite que as pessoas a instalem na tela inicial e um service worker que pode fazê-la funcionar offline. Para o Google, ela continua sendo apenas um site — tornar-se PWA não melhora seu ranqueamento. A única coisa que pode realmente prejudicá-lo é um service worker mal configurado que mostra ao Google uma página antiga em cache em vez da sua página ao vivo.

O que é uma PWA de verdade

Uma Progressive Web App é um site aprimorado para parecer mais com um app nativo. Dois elementos a tornam uma PWA:

• Um manifesto de aplicativo web (manifest.json) — um pequeno arquivo que informa ao navegador o nome, os ícones e as cores do seu aplicativo, para que um visitante possa tocar em “Adicionar à tela inicial” e obter um ícone e uma tela de abertura no estilo de app.
• Um service worker — um pouco de JavaScript que roda em segundo plano e pode armazenar em cache arquivos para que o site carregue rapidamente em visitas repetidas e até funcione offline.

É isso. Por baixo, uma PWA é quase sempre um site JavaScript comum (React, Vue, Angular e assim por diante). É um site normal vestindo uma fantasia de app.

O grande mito a desmascarar

A crença mais comum é: “Se transformarmos nosso site em uma PWA, vamos ranquear melhor.” O Google já disse claramente que isso não é verdade. John Mueller, do Google, foi direto: PWAs “currently don’t have any advantage in Google Search.” (tradução) «atualmente não têm nenhuma vantagem na Pesquisa Google». Não existe “bônus de PWA” nos sistemas de ranqueamento.

O arquivo de manifesto também não ajuda no SEO. Ele controla como o app instala — o ícone, o nome, a tela de abertura — nada disso é lido pelo Google ao decidir como ranquear você.

A única coisa que pode realmente prejudicar

O service worker é a parte com a qual é preciso ter cuidado. Como ele pode servir uma cópia em cache (salva) das suas páginas, uma configuração ruim pode acabar mostrando ao Google uma versão desatualizada ou até em branco de “você está offline” de uma página em vez da versão real e atualizada. É assim que uma PWA perde tráfego após o lançamento — não porque “virou uma PWA”, mas porque o cache estava apontado na direção errada.

O que fazer na prática

• Garanta que o conteúdo real da sua página carregue para os mecanismos de busca, não apenas um shell vazio que é preenchido com JavaScript depois.
• Configure seu service worker para buscar HTML fresco da rede primeiro e só recorrer ao cache para velocidade em coisas como imagens e folhas de estilo.
• Mantenha o básico certo: URLs reais e únicas; um bom título e meta description em cada página; uma experiência rápida e confiável.

Ser uma PWA é ótimo para seus usuários — instalável, rápida, amigável para offline. Só não espere que isso o mova para cima no Google, e não deixe o service worker alimentar o Google com a página errada. A aba Avançado tem os mecanismos, as estratégias de cache e as citações.

TL;DR — Uma PWA é um manifesto + um service worker sobrepostos ao que é quase sempre um site JS/SPA — portanto, as regras de renderização do SEO de JavaScript/SPA se aplicam inalteradas, mais duas preocupações específicas de PWA. O Google dá às PWAs nenhuma vantagem de ranqueamento (Mueller). O manifest.json governa a instalabilidade, não a indexação, e não há evidências de que os sistemas de ranqueamento o leiam. O service worker é o risco real: o renderizador do Google não executa service workers ao indexar, então uma estratégia de HTML com cache-first pode indexar um shell desatualizado ou offline — use network-first para HTML, cache-first para ativos estáticos. HTTPS é um requisito rígido para service workers e separadamente um pequeno sinal de ranqueamento; não encadeie isso em “PWAs ranqueiam melhor.” Core Web Vitals é a única sobreposição legítima, e é a engenharia, não o rótulo de PWA.

Uma PWA é um site antes de tudo

O enquadramento mais útil é este: uma Progressive Web App é um site normal com dois recursos adicionais. Pela definição do próprio Google, PWAs “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.” (tradução) «são aplicativos web criados e aprimorados com APIs modernas para oferecer recursos avançados e, ao mesmo tempo, alcançar qualquer usuário da web, em qualquer dispositivo, com uma única base de código». Os três pilares citados pelo Google são Capable, Reliable e Installable — nenhum deles é “ranqueável”.

Arquiteturalmente, esse código é quase sempre um framework JavaScript executando um padrão de aplicação de página única. O que significa: tudo o que governa a indexabilidade de JS/SPA governa a indexabilidade de PWA, sem modificação. Links reais <a href> e roteamento via History API (não fragmentos de hash) para endereçabilidade; renderização no servidor ou pré-renderização para disponibilidade de conteúdo; canonical, título e meta por rota no DOM renderizado. Se você já leu o material de SEO para JavaScript e SEO para SPA, você já conhece 90% do SEO para PWA — o modo de falha do app shell, em particular, é um que o Google documenta explicitamente: “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.” (tradução) «Alguns sites JavaScript podem usar o modelo de app shell em que o HTML inicial não contém o conteúdo real e o Google precisa executar JavaScript antes de conseguir ver o conteúdo real da página que o JavaScript gera.» Um PWA que envia um shell vazio sem SSR/pré-renderização herda esse problema diretamente.

Portanto, o escopo honesto de um artigo de SEO específico para PWA é pequeno: o manifesto e o service worker. Todo o resto é SEO de JS/SPA vestindo um manifesto.

O mito central: “tornar-se PWA” não melhora o ranqueamento

Este é o ponto central. O Google foi incomumente direto sobre o assunto. Em uma sessão de atendimento do Search Central, John Mueller disse que PWAs “currently don’t have any advantage in Google Search, and as far as I know, there are no plans to change this,” (tradução) «atualmente não têm nenhuma vantagem na Pesquisa Google e, pelo que sei, não há planos para mudar isso»; quando perguntaram se converter um site em PWA ajudaria, respondeu: “By default, saying going to a PWA will make your rankings better — I don’t think that is the case.” (tradução) «Por padrão, dizer que adotar uma PWA melhorará seu ranqueamento — não acho que seja esse o caso».

Ele também antecipou o contra-argumento habitual: “nosso concorrente adotou PWA e seu ranqueamento disparou”. A resposta foi: “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.” (tradução) «Só o fato de um concorrente ter migrado de um framework para outro e obtido uma melhora na busca não significa, do meu ponto de vista, que a mudança de framework tenha sido responsável por ela». E explicou: “These are essentially different ways of making a website… for the most part, we see these as normal HTML pages.” (tradução) «Essas são, essencialmente, maneiras diferentes de criar um site… na maior parte dos casos, nós as vemos como páginas HTML normais».

Onde relançamentos de PWA de fato se correlacionam com ganhos de ranqueamento, são os fatores de confusão que acompanham qualquer grande reformulação: linkagem interna modernizada, conteúdo atualizado e expandido, melhorias genuínas de velocidade e, geralmente, um impulso de marketing ligado ao relançamento. Nada disso exige o rótulo de PWA. Se você reconstruir um site de 10 a 15 anos crescidos organicamente, você muda uma dúzia de coisas ao mesmo tempo — atribuir o resultado a “PWA” é um erro de correlação.

Manifest.json: instalabilidade ≠ indexabilidade

O arquivo manifest.json existe para tornar seu aplicativo instalável. Seus campos — name, short_name, icons, start_url, display, theme_color — controlam o prompt de instalação, o ícone da tela inicial, a tela de abertura e se o aplicativo abre em modo autônomo ou em uma aba do navegador. Esse é o trabalho inteiro.

Não há evidência de que os sistemas de ranqueamento ou indexação do Google leiam o manifesto como um sinal. A confirmação externa mais clara é a própria lista de verificação de PWA do Google, que lista “Is installable” (tradução) «É instalável» e “Discoverable in search” (tradução) «Pode ser encontrado na busca» como duas categorias separadas e independentes. Nela, a capacidade de descoberta é definida pelos fundamentos comuns de SEO: “Enable search engine discovery through unique URLs, descriptive titles, meta descriptions, and structured data.” (tradução) «Permita a descoberta pelos mecanismos de busca com URLs exclusivas, títulos descritivos, meta descriptions e dados estruturados». Instalabilidade (orientada pelo manifesto) e descoberta (SEO clássico) são tratadas como preocupações paralelas, não uma alimentando a outra. Portanto, mantenha um manifesto válido porque é ele que torna o aplicativo instalável; apenas não o classifique como um recurso de SEO.

Service workers: o único risco real de SEO específico de PWA

Aqui está o fato que mais importa, e é específico de PWA: o serviço de renderização do Google não executa o seu service worker quando renderiza uma página para indexação. A justificativa, de 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.” (tradução) «Como temos que presumir que alguém que clica na sua página a partir de uma SERP é um visitante de primeira viagem, executar um service worker geralmente não vai trazer muito benefício.» O objetivo principal de um service worker é acelerar visitas repetidas a partir de um cache — e o Googlebot é, por design, sempre tratado como um visitante de primeira viagem, então não há nada para acelerar. Splitt novamente: “We’re not supporting that because users clicking onto your page from the search result might never have been there beforehand.” (tradução) «Não estamos oferecendo suporte a isso porque os usuários que clicam na sua página a partir do resultado de pesquisa podem nunca ter estado lá antes.» Mueller confirmou que esta é uma política estável, não um estado temporário: “I wouldn’t expect it to change — it’s computationally expensive to run service-workers in the background like this for indexing.” (tradução) «Não esperaria que mudasse — é computacionalmente caro executar service workers em segundo plano assim para indexação.»

Então por que isso é um risco? Porque o seu service worker executa nos navegadores dos usuários reais, e se você o configurou para servir HTML cache-first — retornar a cópia salva, pular a rede — então um visitante repetido real vê uma página em cache rápida, mas essa é uma estratégia que o Googlebot nunca executa. O perigo é o caso inverso: um padrão de cache que, sob qualquer condição de erro ou fallback, devolve um documento desatualizado ou a página de fallback offline. Como a renderização é stateless e o WRS trata cada busca como nova, uma estratégia de cache mal configurada é como um PWA acaba com o Googlebot indexando um shell offline desatualizado ou vazio em vez de conteúdo ao vivo.

A regra prática da estratégia de cache:

• Documentos HTML → network-first (ou stale-while-revalidate com TTL curto). Obtenha a página ao vivo; use o cache apenas como fallback offline e certifique-se de que esse fallback nunca seja o que um rastreamento novo indexaria.
• Ativos estáticos (JS, CSS, imagens, fontes) → cache-first é aceitável e desejável — eles não mudam por solicitação e não são o documento indexável.

Como auditar: compare o que o Googlebot vê com o que o navegador de um visitante repetido serve do cache. Use a URL Inspection no Search Console (teste ao vivo) para ver o HTML renderizado que o Google realmente obtém e verifique-o em relação à página ao vivo. Se divergirem, seu service worker ou configuração de SSR é o primeiro suspeito. E observe os timeouts de renderização em configurações híbridas — como Hamlet Batista observou na era da renderização dinâmica, “Rendering services won’t wait forever for a page to finish loading.” (tradução) «Os serviços de renderização não esperarão para sempre uma página terminar de carregar.» (Esse artigo específico é sobre renderização dinâmica, que o Google agora desencoraja em favor de SSR — cite o princípio do timeout, não o padrão.)

HTTPS: um requisito de service worker e, separadamente, um pequeno sinal de ranqueamento

Você verá posts de SEO para PWA implicando que “PWAs precisam de HTTPS, e HTTPS melhora o ranqueamento, portanto PWAs são mais amigáveis para SEO.” Dois fatos verdadeiros, encadeados incorretamente.

Fato um: service workers só funcionam em um contexto seguro. Segundo a 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.” (tradução) «Service workers só estão disponíveis em contextos seguros: isso significa que o documento deles é servido via HTTPS, embora os navegadores também tratem http://localhost como um contexto seguro, para facilitar o desenvolvimento local.» Essa é uma regra da plataforma do navegador, não uma tática de SEO — sem HTTPS, sem service worker, ponto final.

Fato dois: HTTPS é um sinal real de ranqueamento do Google, mas minúsculo. O anúncio de 2014 do próprio 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.” (tradução) «estamos começando a usar HTTPS como um sinal de ranqueamento. Por enquanto é apenas um sinal muito leve — afetando menos de 1% das consultas globais e tendo menos peso do que outros sinais, como conteúdo de alta qualidade.»

O ponto: qualquer site com HTTPS recebe esse mesmo sinal minúsculo — PWA ou não. Um PWA não recebe crédito extra de SEO por HTTPS; ele simplesmente não funciona sem isso. Não venda HTTPS como um benefício de SEO para PWA.

Core Web Vitals: a única sobreposição legítima

Se existe um lugar real onde “bom PWA” e “bom SEO” se encontram, é o desempenho. A orientação de PWA do Google começa com confiabilidade — “A reliable Progressive Web App feels fast and dependable regardless of the network” (tradução) «Um Progressive Web App confiável parece rápido e confiável independentemente da rede» — e as Core Web Vitals são um fator de ranqueamento confirmado (embora modesto). Um PWA bem projetado que carrega rápido e permanece responsivo tende a ter pontuações boas nas Vitals.

Mas leia a causalidade com cuidado: é a engenharia, não o fato de ser PWA. Um PWA inchado — pacote JS enorme, hidratação que bloqueia a renderização, um service worker excessivamente zeloso — pode facilmente apresentar Core Web Vitals piores do que uma página simples renderizada no servidor. A vitória nas Vitals vem de fazer o trabalho de desempenho bem, o que você poderia fazer com ou sem um manifesto. Ser um PWA não garante boas Vitals nem concede um atalho para elas.

Recursos semelhantes a apps são UX, não fatores de ranqueamento

Adicionar à tela inicial, modo offline, notificações push, navegação semelhante a apps — todos benefícios genuiínos e valiosos de PWA, e todos recursos de engajamento/retenção, não entradas de indexação ou ranqueamento. A lista de verificação de PWA do Google torna a divisão explícita ao colocar “instalável” e “detectável na busca” em categorias separadas.

Não trate “instalável” como uma capacidade única e universal também — ela varia por navegador e sistema operacional, o que é mais um motivo para não poder ser um sinal de SEO (o Google não teria um comportamento consistente entre navegadores para recompensar). O evento beforeinstallprompt que permite que um PWA mostre sua própria interface de instalação personalizada é um mecanismo exclusivo do Chromium; de acordo com o guia de instalabilidade de PWA da MDN, ele é “not supported on iOS.” (tradução) «não suportado no iOS.» No Safari do iOS, a instalação acontece apenas pelo fluxo manual Compartilhar → Adicionar à Tela de Início (estendido para Chrome, Edge, Firefox e Orion no iOS 16.4+, todos usando o mecanismo WebKit exigido pela Apple no iOS e, portanto, compartilhando essa limitação), não por um prompt automático. Nada disso muda o cenário de SEO — apenas significa que “meu PWA é instalável” não é um fato sim/não independente de qual navegador e sistema operacional o visitante está usando.

O Twitter Lite é o estudo de caso que todos usam como “prova de que PWAs ajudam no SEO” — e os resultados documentados são reais (um aumento de 65% nas páginas por sessão, aumento de 75% nos Tweets enviados, diminuição de 20% na taxa de rejeição) — mas cada um deles é uma métrica de engajamento. O estudo de caso do próprio Google sobre ele nunca menciona SEO, busca orgânica ou ranqueamentos. Ótimo resultado; coluna errada.

Vitrines de ecommerce PWA: um breve destaque

Vitrines PWA adicionam algumas complicações que valem a pena mencionar, porque elas agravam os riscos de SPA. Roteamento no lado do cliente combinado com navegação facetada pode gerar URLs que parecem rastreáveis, mas que todas resolvem para o mesmo shell, ou uma explosão de URLs com parâmetros. O estado do carrinho e do checkout vive no lado do cliente e nunca deve bloquear o conteúdo indexável do produto. E cada página de produto deve retornar HTML real e exclusivo de forma independente — a armadilha do app-shell é mais cara exatamente onde você tem mais páginas. As correções são as mesmas do SEO de ecommerce e de navegação facetada; a camada PWA não as muda, apenas torna a disciplina de SSR/prerender mais importante.

Bing e PWAs

Vale uma linha: o Bing não publicou nenhuma orientação específica de ranking ou indexação para PWA. Suas diretrizes para webmasters são agnósticas em relação a PWA (crawlability geral, sitemaps, robots.txt, IndexNow), e a extensa documentação de PWA da Microsoft é inteiramente sobre prompts de instalação no Edge, PWABuilder e empacotamento na Microsoft Store — distribuição e instalação, uma trilha separada da indexação em buscas na web. Portanto, para o Bing, use as orientações comuns de crawlability para renderização de JavaScript; não há exceção de PWA a aprender.

A conclusão

SEO para PWA é SEO para JavaScript/SPA com exatamente duas adições: ignore o manifest como entrada de SEO (ele é para instalabilidade) e configure o service worker para que ele nunca prenda o Googlebot em um cache obsoleto ou offline. Acertando isso, um PWA é indexado exatamente como qualquer outro site bem construído — sem bônus, sem penalidade, apenas as mesmas regras.

Resumo de IA

Uma visão condensada da versão Avançada:

• Um PWA é um site antes de tudo. É um manifest.json (instalabilidade) + um service worker (offline/cache) sobreposto ao que é quase sempre um site JS/SPA. Todas as regras de SEO para JavaScript/SPA se aplicam sem alterações.
• Nenhuma vantagem de ranqueamento. John Mueller, do Google: PWAs “currently don’t have any advantage in Google Search.” (tradução) «atualmente não têm nenhuma vantagem na Pesquisa Google». Adotar uma PWA não melhora o ranqueamento.
• Manifest.json é irrelevante para SEO. Ele controla prompts de instalação, ícones, start_url, display — não há evidência de que os sistemas de ranking o leiam. A lista de verificação de PWA do Google lista “instalável” e “descobrível na busca” como categorias separadas.
• O único risco real é o service worker. O renderizador do Google não executa service workers ao indexar (ele trata cada rastreamento como uma primeira visita), então uma estratégia de HTML cache-first pode indexar um shell obsoleto ou offline. Use network-first para HTML, cache-first para ativos estáticos.
• HTTPS ≠ um benefício de SEO para PWA. É um requisito rígido para service workers (contexto seguro) e separadamente um sinal de ranking “muito leve” que todo site com HTTPS recebe. Não encadeie os dois.
• Core Web Vitals é a única sobreposição legítima — e é a engenharia de desempenho, não o rótulo de PWA. Um PWA inchado pode pontuar pior.
• Recursos semelhantes a apps (instalação, offline, push) são engajamento, não ranking. Os famosos ganhos do Twitter Lite são métricas de engajamento; esse estudo de caso nunca menciona SEO. A instalabilidade em si varia por navegador/SO (o Safari no iOS não tem beforeinstallprompt, apenas Adicionar à Tela de Início manual) — mais um motivo para não poder ser um sinal de ranking.
• Bing não tem orientação específica para PWA; use a crawlability comum de JS.

Documentação oficial

Material de fonte primária sobre PWAs, renderização e os fatos nos quais este artigo se baseia.

Google / web.dev

• O que são Progressive Web Apps? — a definição do Google e os três pilares (Capaz, Confiável, Instalável).
• O que torna uma boa Progressive Web App? (lista de verificação de PWA) — separa “É instalável” de “Descobrível na busca” como categorias distintas.
• Service workers (Aprenda PWA) — estratégias de cache e o ciclo de vida do service worker.
• Entenda os fundamentos de SEO para JavaScript — o modo de falha do app shell que o Google documenta.
• Construindo Progressive Web Apps indexáveis (2016) — o post original do Google sobre indexabilidade de PWA.
• Estudo de caso do Twitter Lite — as métricas de engajamento (observe: nenhuma alegação de SEO/orgânico em qualquer lugar).
• HTTPS como sinal de ranking (2014) — a declaração do “sinal muito leve”.

MDN / plataforma

• Service Worker API — o requisito de contexto seguro (HTTPS).
• Tornando PWAs instaláveis — diferenças de instalabilidade entre navegadores/sistemas operacionais, incluindo por que beforeinstallprompt não é suportado no iOS.

Bing / Microsoft (não há orientação específica de ranqueamento para PWA — estes são documentos de instalação/distribuição)

• Diretrizes do Bing para webmasters — rastreabilidade geral; agnóstico em relação a PWA.
• Visão geral dos Progressive Web Apps (PWAs) — foco em instalação e distribuição no Edge.

Citações da fonte

Declarações registradas. Quando uma citação é transmitida por terceiros em vez de uma URL de propriedade do Google, a ressalva informa isso.

Google — nenhuma vantagem de ranqueamento para PWA

• “PWAs currently don’t have any advantage in Google Search, and as far as I know, there are no plans to change this.” (tradução) «PWAs atualmente não têm nenhuma vantagem na Pesquisa Google e, pelo que sei, não há planos para mudar isso.» — John Mueller, Google, horário de expediente do Search Central (nov. 2021). Leia a cobertura
• “By default, saying going to a PWA will make your rankings better — I don’t think that is the case.” (tradução) «Por padrão, dizer que usar um PWA melhorará seu ranqueamento — não acho que seja o caso.» — John Mueller, mesma sessão. Leia a cobertura
• “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.” (tradução) «Então, só o fato de um de seus concorrentes ter migrado de um framework para outro e ter visto uma melhora na busca — essa mudança de framework, do meu ponto de vista, não seria responsável por isso.» — John Mueller, mesma sessão. Leia a cobertura

Google — o que é um PWA e o risco do 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.” (tradução) «Progressive Web Apps (PWA) são aplicativos web criados e aprimorados com APIs modernas para fornecer capacidades aprimoradas, alcançando qualquer usuário da web em qualquer dispositivo com uma única base de código.» — web.dev. Ir para a citação
• “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.” (tradução) «Alguns sites JavaScript podem usar o modelo de app shell, onde o HTML inicial não contém o conteúdo real e o Google precisa executar JavaScript antes de conseguir ver o conteúdo real da página que o JavaScript gera.» — Google Search Central. Ir para a citação
• “Enable search engine discovery through unique URLs, descriptive titles, meta descriptions, and structured data.” (tradução) «Habilite a descoberta por mecanismos de busca por meio de URLs exclusivas, títulos descritivos, meta descrições e dados estruturados.» — checklist de PWA do web.dev, “Discoverable in search.” Ir para a citação

Google — service workers e indexação (transmitido)

• “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.” (tradução) «Como temos que supor que alguém clicando na sua página a partir de uma SERP é um visitante de primeira viagem, executar um service worker geralmente não vai trazer muito benefício.» — Martin Splitt, Google. Leia a cobertura
• “We’re not supporting that because users clicking onto your page from the search result might never have been there beforehand.” (tradução) «Não estamos apoiando isso porque usuários que clicam na sua página a partir do resultado de busca podem nunca ter estado lá antes.» — Martin Splitt, Google (Google I/O 2019). Leia a cobertura
• “I wouldn’t expect it to change — it’s computationally expensive to run service-workers in the background like this for indexing.” (tradução) «Não esperaria que mudasse — é computacionalmente caro executar service workers em segundo plano assim para indexação.» — John Mueller, Google (relatado em jul. 2023). Leia a cobertura

HTTPS: requisito de plataforma vs. sinal de ranqueamento

• “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.” (tradução) «A API de service workers só está disponível em contextos seguros: o documento precisa ser servido por HTTPS, embora os navegadores também considerem http://localhost um contexto seguro para facilitar o desenvolvimento local.» — MDN, Service Worker API. Ir para a citação
• “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.” (tradução) «Começamos a usar HTTPS como sinal de ranqueamento. Por enquanto, ele é muito leve — afeta menos de 1% das consultas globais e tem peso menor que outros sinais, como conteúdo de alta qualidade.» — Google, “HTTPS as a ranking signal” (2014). Ir para a citação

A instalabilidade varia por navegador/SO

• “This is not supported on iOS.” (tradução) «Isso não é suportado no iOS.» — MDN, sobre o evento de prompt de instalação personalizado beforeinstallprompt. Ir para a citação

Sobre timeouts de renderização (contexto datado)

• “Rendering services won’t wait forever for a page to finish loading.” (tradução) «Os serviços de renderização não vão esperar para sempre uma página terminar de carregar.» — Hamlet Batista, Search Engine Land. Leia o artigo

Devo usar PWA — e o que isso fará pelo SEO?

Uma rápida passagem pelas perguntas que as pessoas realmente trazem para este tópico.

“Estamos considerando um PWA. Isso vai ajudar nosso SEO?”

• Nenhum benefício inerente de ranqueamento — o Google diz que PWAs não têm vantagem na Pesquisa. → Construa um PWA pelos benefícios para o usuário (instalável, offline, carregamentos rápidos repetidos), não para ranqueamento. → Também não vai prejudicar o SEO, desde que sua renderização e service worker estejam configurados corretamente (continue abaixo).

“Estamos construindo/temos um PWA. Meu conteúdo está realmente indexável?”

• O HTML inicial contém o conteúdo real (SSR/prerender) ou é um app shell vazio preenchido por JS?
  • Shell vazio, sem SSR → esta é a armadilha do app shell. Adicione SSR ou pré-renderização antes de se preocupar com qualquer coisa específica de PWA. (Mesma correção que qualquer SPA.)
  • SSR/prerender no lugar → bom; vá para o service worker.

“Como meu service worker deve armazenar páginas em cache?”

• Documentos HTML → network-first (ou stale-while-revalidate, TTL curto). Nunca cache-first para HTML.
• Ativos estáticos (JS/CSS/imagens/fontes) → cache-first é bom e adequado.
• Página de fallback offline → certifique-se de que ela nunca possa ser a versão que um rastreamento novo indexa.

“Meu PWA perdeu ranqueamento/tráfego após o lançamento. Onde devo olhar?”

1. Execute a URL Inspection (teste ao vivo) no Search Console — o Google está vendo a página real ou uma desatualizada/offline/vazia?
2. Se desatualizada ou vazia → suspeite da estratégia de cache do service worker (HTML cache-first) ou de uma etapa de SSR ausente.
3. Se o conteúdo está lá, mas o ranqueamento ainda caiu → veja o que mais a reconstrução mudou: links internos, conteúdo, redirecionamentos, velocidade. O rótulo PWA raramente é a causa.

“Preciso fazer algo especial com o manifest para SEO?”

• Não. Mantenha-o válido para instalabilidade; ele não tem papel em SEO. Gaste o esforço em URLs, títulos, meta, dados estruturados e Core Web Vitals.

Checklist de SEO para PWA

Passagem escaneável para manter um Progressive Web App rastreável e indexável:

• O conteúdo real é renderizado no servidor ou pré-renderizado — não um shell de aplicativo vazio preenchido por JavaScript após o carregamento.
• Cada rota tem uma URL real e única via History API (sem roteamento por hash/#!).
• Cada rota retorna seu próprio canonical, título e meta description no DOM renderizado.
• O service worker serve HTML network-first (ou stale-while-revalidate, com TTL curto) — nunca cache-first para documentos HTML.
• Ativos estáticos (JS/CSS/imagens/fontes) podem ser cache-first; isso é aceitável.
• A página de fallback offline nunca pode ser o que um rastreamento novo indexa.
• URL Inspection (teste ao vivo) mostra ao Google a página real e atual — comparada com a página ao vivo.
• O manifest é válido para instalabilidade, mas você não o trata como uma alavanca de SEO.
• A instalabilidade é testada por navegador/SO, não assumida como universal (o Safari do iOS não tem beforeinstallprompt; é Adicionar à Tela de Início manual) — e nenhuma dessa variação é tratada como um problema de SEO.
• Servido via HTTPS (obrigatório para service workers de qualquer forma).
• Core Web Vitals estão saudáveis — verifique se o bundle JS e a hidratação não estão arrastando LCP/INP para baixo.
• Ecommerce: cada página de produto retorna HTML único real; navegação facetada/roteamento no cliente não está gerando URLs de shell ou parâmetros infinitos.

PWA SEO — folha de referência

Isso afeta o SEO?

Cache do service worker por tipo de recurso

Fatos rápidos

• O Google dá nenhuma vantagem de ranqueamento a PWAs (Mueller).
• O renderizador do Google não executa service workers ao indexar.
• Sinal de ranqueamento HTTPS: “fewer than 1% of global queries” (tradução) «menos de 1% das consultas globais» (Google, 2014).
• Bing: nenhuma orientação específica para PWA — trate como qualquer site JS.

Manual de incidentes: o tráfego de pesquisa caiu após um lançamento de PWA

1. Congele o caminho de lançamento. Pare novas implantações de service worker e roteamento enquanto preserva o estado de produção com falha e os identificadores de lançamento.
2. Confirme o escopo. Segmente a queda por modelo, diretório, dispositivo e horário de implantação. Uma falha em todo o PWA não deve ser presumida a partir de uma única rota quebrada.
3. Compare três respostas. Salve a resposta HTTP bruta, uma página recém-renderizada com armazenamento limpo e uma página de usuário recorrente controlada pelo service worker. Verifique o título, canonical, diretivas de robots, conteúdo principal, links e comportamento de status.
4. Inspecione o registro e a política de cache. No DevTools Application, identifique o worker ativo, seu escopo, versões em espera, nomes de cache e manipulador de navegação. Confirme que as navegações de HTML não estão presas atrás de uma resposta antiga de cache-first.
5. Ignore o worker. Cancele o registro dele ou use a opção de ignorar do DevTools, recarregue e repita a rota afetada. Se o defeito desaparecer, o worker ou seu cache é o provável limite; se permanecer, continue como um incidente comum de SEO JavaScript.
6. Restaure um caminho de navegação seguro. Reverta o worker ou altere as solicitações de documentos para network-first com um fallback offline explícito. Não exclua todos os caches cegamente se os usuários dependem de dados offline.
7. Valide e monitore. Teste um navegador limpo, um navegador em atualização e um navegador offline. Em seguida, inspecione URLs representativas e observe o desempenho de pesquisa durante a janela normal de recrawling.

Tratando o manifesto como um arquivo de SEO

Inserir palavras-chave em name, short_name ou metadados de ícones não torna as páginas mais indexáveis. Use o manifesto para o comportamento de instalação e coloque conteúdo relevante para pesquisa em HTML rastreável com títulos, links e canonicals comuns.

Armazenando HTML em cache para sempre

Uma regra de cache-first que trata navegações como ativos imutáveis pode manter cópias antigas, canonicals ou diretivas de robots ativas após um lançamento. Armazene em cache JS, CSS e imagens versionados agressivamente; dê ao HTML uma estratégia de atualização ciente da rede.

Retornando o shell offline como uma página de sucesso

Servir o mesmo shell de aplicativo offline para cada URL indisponível pode parecer que muitas URLs diferentes retornam conteúdo fino idêntico. Mantenha a experiência offline claramente separada da navegação normal e não finja que um documento ausente é a página solicitada.

Escondendo a navegação atrás de controles que não são links

Um botão que altera o estado do cliente pode funcionar no aplicativo sem fornecer um caminho rastreável <a href> para o destino. Use links reais para rotas que mecanismos de pesquisa e usuários precisam seguir e, em seguida, aprimore a transição com JavaScript.

Testando apenas como um usuário recorrente aquecido

Um navegador de desenvolvedor com um worker instalado e cache populado pode mascarar uma primeira visita quebrada. Teste armazenamento limpo, uma atualização do worker anterior e uma visita recorrente. Esses são estados distintos de PWA.

Exemplo: cache de ativos e cache de documentos precisam de regras diferentes

A seguinte lógica simplificada de service worker mostra o limite. Ativos com hash podem ser cache-first; navegações de documentos devem tentar a rede antes de cair no 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))
    );
  }
});

A política exata de produção depende de requisitos de atualização e offline, mas a lição de SEO é estável: HTML não é o mesmo tipo de ativo imutável que um bundle com fingerprint.

Exemplo: rota rastreável versus estado somente do aplicativo

<!-- 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>

Um PWA pode interceptar o link para uma transição semelhante a um aplicativo sem remover sua URL rastreável.

Prompt: revise uma estratégia de cache de service worker

Cole o código-fonte do worker e um inventário de rotas. Não inclua segredos ou respostas privadas de API.

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: crie uma matriz de QA de lançamento de 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]

O framework SHELL para revisões de SEO de PWA

• S: Resposta do servidor. Uma primeira resposta utilizável, ou uma estratégia de renderização deliberada, deve expor a página em vez de apenas um shell de aplicativo vazio.
• H: Hrefs. Rotas importantes usam links rastreáveis com URLs estáveis, não controles que existem apenas como estado no lado do cliente.
• E: Metadados esperados. Títulos, canonicals, diretivas de robots e dados estruturados permanecem corretos nos estados bruto e renderizado.
• L: Documentos vivos. Solicitações de navegação têm uma política de frescor apropriada para HTML; documentos em cache desatualizados não sobrevivem silenciosamente aos lançamentos.
• L: Testes de ciclo de vida. QA cobre instalação, ativação, atualização, waiting-worker, offline, e estados de bypass em vez de uma única sessão de desenvolvedor aquecida.

O framework mantém a revisão específica de PWA restrita. Se todos os cinco passarem, a maior parte do trabalho restante é QA comum de JavaScript, desempenho e indexabilidade.

Console do DevTools: inspecione o worker ativo e os caches

Execute isto no Console do DevTools do navegador no PWA. Ele relata registros e nomes de cache sem alterar nenhum dos dois.

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 do DevTools: compare uma busca de rede com uma resposta em 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 ?? '' }
});

O resultado prova que uma resposta existe em um cache; não prova qual handler de fetch vencerá para cada navegação. Confirme o roteamento no código-fonte do worker e no painel Network.

Regex: encontre handlers de navegação cache-first arriscados

Use isto como auxílio de revisão, não como parser. Ele procura por uma condição de navegação seguida por uma consulta de cache nas proximidades.

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

Valide um lançamento de SEO para PWA

Teste-se: SEO para PWA

Cinco perguntas rápidas sobre como Progressive Web Apps interagem com a busca. Escolha uma resposta para cada uma e depois confira.

Recursos que valem seu tempo

Meus escritos relacionados

• Problemas e Melhores Práticas de JavaScript SEO — a base de renderização sobre a qual todo PWA se apoia; app-shell, SSR e o que o renderizador do Google faz e não faz.
• Guia para Iniciantes em SEO Técnico — onde renderização e rastreabilidade se encaixam no panorama geral.

Minhas palestras

• Como a Busca Funciona (SlideShare) — minha explicação sobre rastreamento, renderização, indexação e ranqueamento, o pipeline pelo qual uma PWA precisa passar. Aviso permanente: “This is my understanding of systems… not going to be 100% complete or accurate.” (tradução) «Este é o meu entendimento dos sistemas… ele não será 100% completo nem exato».

De toda a indústria

• Google: Progressive Web Apps Don’t Rank Better Than Regular Sites (Search Engine Journal) — a cobertura do office hours do Mueller que ancora a desmistificação.
• Google Says Progressive Web Apps (PWAs) Have No Advantage In Search (Search Engine Roundtable) — matéria independente sobre a mesma sessão.
• Service Worker – What SEOs Need to Know (SearchViu) — as declarações de Splitt/Mueller sobre por que o renderizador ignora service workers.
• Understand JavaScript SEO Basics (Google) — o modo de falha do app shell, documentado na fonte.
• What makes a good Progressive Web App? (PWA checklist) (web.dev) — instalabilidade e descobribilidade como categorias separadas.
• Twitter Lite case study (web.dev) — os números reais de engajamento e a prova de que nunca foram sobre SEO.

Vídeos

• Google Search Central (YouTube) — os explicadores de JavaScript SEO e renderização de Martin Splitt cobrem exatamente o pipeline (crawl → render → index) do qual uma PWA depende, incluindo como o renderizador sem estado lida com JS. Canal

Registro de alterações