SEO para PWA

TL;DR — Una PWA (Progressive Web App) es un sitio web normal con dos añadidos encima: un manifest que permite instalarla en la pantalla de inicio y un service worker que puede hacer que funcione sin conexión. Para Google sigue siendo simplemente un sitio web: pasar a PWA no mejora el posicionamiento. Lo único que realmente puede perjudicar es un service worker mal configurado que muestre a Google una página antigua, guardada en caché, en lugar de la versión en vivo.

Qué es realmente una PWA

Una Progressive Web App es un sitio web al que se han añadido mejoras para que se parezca más a una aplicación nativa. Dos piezas la convierten en PWA:

• Un manifiesto de aplicación web (manifest.json): un archivo pequeño que indica al navegador el nombre, los iconos y los colores de la aplicación, de modo que un visitante pueda pulsar “Add to Home Screen” (traducción) «Añadir a pantalla de inicio» y obtener un icono con aspecto de aplicación y una pantalla de bienvenida.
• Un service worker: un fragmento de JavaScript que se ejecuta en segundo plano y puede guardar archivos en caché para que el sitio cargue rápido en las visitas repetidas e incluso funcione sin conexión.

Eso es todo. Por debajo, una PWA es casi siempre un sitio web de JavaScript convencional (React, Vue, Angular, etc.). Es un sitio normal disfrazado de aplicación.

El gran mito que hay que derribar

Lo que más gente cree es: “Si convertimos nuestro sitio en una PWA, posicionaremos mejor.” Google ha dicho con claridad que no es así. John Mueller, de Google, lo expresó de forma directa: las PWA “currently don’t have any advantage in Google Search.” (traducción) «actualmente no tienen ninguna ventaja en la Búsqueda de Google». No existe ninguna «bonificación por ser PWA» en los sistemas de posicionamiento.

El archivo manifest tampoco ayuda al SEO. Controla cómo se instala la aplicación —el icono, el nombre, la pantalla de bienvenida—, y Google no lee nada de eso al decidir cómo posicionar el sitio.

Lo único que realmente puede perjudicar

El service worker es la parte con la que hay que tener cuidado. Como puede servir una copia en caché (guardada) de las páginas, una mala configuración puede acabar mostrando a Google una versión obsoleta o incluso una versión en blanco de “no hay conexión” de una página, en lugar de la real y actualizada. Así es como una PWA pierde tráfico tras el lanzamiento: no porque “se convirtiera en PWA”, sino porque la caché estaba orientada en la dirección equivocada.

Qué hacer en la práctica

• Asegúrese de que el contenido real de la página se carga para los motores de búsqueda, y no solo un armazón vacío que se rellena después con JavaScript.
• Configure el service worker para que obtenga primero de la red el HTML actualizado y solo recurra a la caché, por velocidad, en cosas como imágenes y hojas de estilo.
• Mantenga lo básico en orden: URLs reales y únicas; un buen título y una buena metadescripción en cada página; una experiencia rápida y fiable.

Ser una PWA es excelente para los usuarios: instalable, rápida, apta para uso sin conexión. Solo hay que no esperar que le haga subir en Google y no dejar que el service worker entregue a Google la página equivocada. La pestaña Avanzado contiene la mecánica, las estrategias de caché y las citas.

TL;DR — Una PWA es un manifest + un service worker superpuestos a lo que casi siempre es un sitio JS/SPA, así que las reglas de renderizado del SEO en JavaScript/SPA se aplican sin cambios, más dos preocupaciones específicas de las PWA. Google no concede a las PWA ninguna ventaja de posicionamiento (Mueller). El manifest.json rige la instalabilidad, no la indexación, y no hay evidencia de que los sistemas de posicionamiento lo lean. El service worker es el riesgo real: el renderizador de Google no ejecuta service workers al indexar, así que una estrategia de HTML cache-first puede indexar un armazón obsoleto o sin conexión; use network-first para el HTML y cache-first para los recursos estáticos. HTTPS es un requisito ineludible para los service workers y, por separado, una señal de posicionamiento mínima; no encadene ambas cosas para llegar a “las PWA posicionan mejor”. Core Web Vitals (Métricas web esenciales) es el único solapamiento legítimo, y lo que cuenta es la ingeniería, no la etiqueta de PWA.

Una PWA es, antes que nada, un sitio web

El marco mental más útil: una Progressive Web App es un sitio web normal con dos cosas añadidas encima. Según la propia definición de Google, las 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.” (traducción) «son aplicaciones web creadas y mejoradas con APIs modernas para ofrecer capacidades avanzadas sin dejar de llegar a cualquier usuario web en cualquier dispositivo con una sola base de código». Los tres pilares que Google enumera son Capable, Reliable e Installable (capaz, fiable e instalable): conviene notar que ninguno de los tres es “rankable” (posicionable).

Desde el punto de vista arquitectónico, esa base de código es casi siempre un framework de JavaScript que ejecuta un patrón de aplicación de una sola página (SPA). Lo que significa: todo lo que rige la indexabilidad de JS/SPA rige la indexabilidad de una PWA, sin ninguna modificación. Enlaces <a href> reales y enrutamiento con la History API (no fragmentos hash) para la direccionabilidad; renderizado en el servidor o prerrenderizado para la disponibilidad del contenido; canonical, título y metaetiquetas por ruta en el DOM renderizado. Si ha leído el material sobre SEO en JavaScript y SEO para SPA, ya conoce el 90 % del SEO para PWA: el modo de fallo del app shell, en particular, es uno que Google documenta explícitamente: “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.” (traducción) «Algunos sitios con JavaScript pueden usar el modelo de app shell, en el que el HTML inicial no contiene el contenido real y Google necesita ejecutar JavaScript para poder ver el contenido real de la página que genera JavaScript». Una PWA que publica un armazón vacío sin SSR/prerrenderizado hereda ese problema directamente.

Así que el alcance honesto de un artículo de SEO específico de las PWA es reducido: el manifest y el service worker. Todo lo demás es SEO en JavaScript/SPA con un manifest puesto.

El mito central: “pasar a PWA” no mejora el posicionamiento

Este es el titular. Google ha sido inusualmente directo al respecto. John Mueller, en una sesión de office-hours de Search Central, dijo que las PWA “currently don’t have any advantage in Google Search, and as far as I know, there are no plans to change this,” (traducción) «actualmente no tienen ninguna ventaja en la Búsqueda de Google y, por lo que sé, no hay planes de cambiarlo», y —preguntado sobre si convertir un sitio en PWA ayudaría— “By default, saying going to a PWA will make your rankings better — I don’t think that is the case.” (traducción) «Por defecto, decir que pasar a una PWA mejorará tu posicionamiento: no creo que sea así».

También se anticipó al contraargumento habitual, el de “nuestro competidor pasó a PWA y su posicionamiento subió”. Su respuesta: “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.” (traducción) «Así que el simple hecho de que uno de sus competidores haya pasado de un framework a otro y haya visto una mejora en la búsqueda: ese cambio de framework, desde mi punto de vista, no sería el responsable». Y sobre el motivo: “These are essentially different ways of making a website… for the most part, we see these as normal HTML pages.” (traducción) «Son esencialmente formas distintas de hacer un sitio web… en su mayor parte, las vemos como páginas HTML normales».

Cuando los relanzamientos de PWA sí se correlacionan con subidas de posicionamiento, son los factores de confusión que acompañan a cualquier reconstrucción grande: enlazado interno modernizado, contenido actualizado y ampliado, mejoras reales de velocidad y, normalmente, un empujón de marketing ligado al relanzamiento. Nada de eso requiere la etiqueta de PWA. Si se reconstruye un sitio de 10 a 15 años crecido de forma orgánica, se cambian una docena de cosas a la vez: atribuir el resultado a la “PWA” es un error de correlación.

Manifest.json: instalabilidad ≠ indexabilidad

El archivo manifest.json existe para que la aplicación sea instalable. Sus campos —name, short_name, icons, start_url, display, theme_color— determinan el mensaje de instalación, el icono de la pantalla de inicio, la pantalla de bienvenida y si la aplicación se abre de forma independiente o en una pestaña del navegador. Ese es todo su cometido.

No hay evidencia de que los sistemas de posicionamiento o de indexación de Google lean el manifest como señal. La confirmación externa más limpia es la propia lista de comprobación de PWA de Google, que enumera “Is installable” («Es instalable») y “Discoverable in search” («Se puede descubrir en la búsqueda») como dos categorías de la lista separadas e independientes, donde la descubribilidad se define como los fundamentos habituales del SEO: “Enable search engine discovery through unique URLs, descriptive titles, meta descriptions, and structured data.” (traducción) «Facilita la detección por parte de los motores de búsqueda mediante URLs únicas, títulos descriptivos, metadescripciones y datos estructurados». La instalabilidad (gobernada por el manifest) y la descubribilidad (SEO clásico) se tratan como preocupaciones paralelas, no como que una alimente a la otra. Así que: mantenga un manifest válido porque es lo que hace que la aplicación sea instalable, pero no lo archive bajo SEO.

Service workers: el único riesgo de SEO realmente específico de las PWA

Este es el hecho que más importa, y es específico de las PWA: el servicio de renderizado de Google no ejecuta el service worker cuando renderiza una página para indexarla. El razonamiento, 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.” (traducción) «Como tenemos que asumir que quien hace clic en tu página desde una SERP es un visitante que llega por primera vez, ejecutar un service worker normalmente no va a servir de mucho». Todo el sentido de un service worker es acelerar las visitas repetidas desde una caché, y Googlebot, por diseño, se trata siempre como un visitante que llega por primera vez, así que no hay nada que acelerar. De nuevo Splitt: “We’re not supporting that because users clicking onto your page from the search result might never have been there beforehand.” (traducción) «No lo admitimos porque los usuarios que hacen clic en tu página desde el resultado de búsqueda puede que nunca hayan estado allí antes». Mueller ha confirmado que es una política estable, no un estado temporal: “I wouldn’t expect it to change — it’s computationally expensive to run service-workers in the background like this for indexing.” (traducción) «No esperaría que cambie: es computacionalmente costoso ejecutar service workers en segundo plano de esta manera para la indexación».

¿Y por qué es eso un riesgo? Porque el service worker sí se ejecuta en los navegadores de los usuarios reales y, si se le indicó servir el HTML con cache-first —devolver la copia guardada y saltarse la red—, un visitante real que repite ve una página rápida desde la caché, pero es una estrategia que Googlebot nunca ejecuta. El peligro es el caso inverso: un patrón de caché que, ante cualquier error o condición de reserva, devuelva un documento obsoleto o la página de reserva sin conexión. Como el renderizado no mantiene estado y el WRS trata cada petición como nueva, una estrategia de caché mal configurada es la vía por la que una PWA acaba con Googlebot indexando contenido desactualizado o un armazón vacío sin conexión en lugar del contenido en vivo.

Regla general para la estrategia de caché:

• Documentos HTML → network-first (o stale-while-revalidate con un TTL corto). Obtenga la página en vivo; use la caché solo como reserva sin conexión y asegúrese de que esa reserva nunca sea lo que indexaría un rastreo nuevo.
• Recursos estáticos (JS, CSS, imágenes, fuentes) → cache-first está bien y es deseable: no cambian en cada petición y no son el documento indexable.

Cómo auditarlo: compare lo que ve Googlebot con lo que el navegador de un visitante que repite sirve desde la caché. Use URL Inspection (herramienta de inspección de URLs) en Search Console con la prueba en vivo para ver el HTML renderizado que Google obtiene realmente y compárelo con la página en vivo. Si divergen, el primer sospechoso es el service worker o la configuración de SSR. Y vigile los tiempos de espera de renderizado en configuraciones híbridas: como señaló Hamlet Batista en la época del renderizado dinámico, “Rendering services won’t wait forever for a page to finish loading.” (traducción) «Los servicios de renderizado no esperarán indefinidamente a que una página termine de cargar». (Ese artículo concreto trata del renderizado dinámico, que Google ahora desaconseja en favor del SSR: cite el principio del tiempo de espera, no el patrón.)

HTTPS: un requisito de los service workers y, por separado, una señal de posicionamiento mínima

Verá artículos de SEO para PWA que insinúan: “las PWA necesitan HTTPS y HTTPS mejora el posicionamiento; por tanto, las PWA son más favorables al SEO”. Dos hechos verdaderos, mal encadenados.

Hecho uno: los service workers solo se ejecutan en un contexto seguro. Según 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.” (traducción) «Los service workers solo están disponibles en contextos seguros: esto significa que su documento se sirve mediante HTTPS, aunque los navegadores también tratan http://localhost como un contexto seguro para facilitar el desarrollo local». Es una regla de la plataforma del navegador, no una táctica de SEO: sin HTTPS, no hay service worker, y punto.

Hecho dos: HTTPS es una señal de posicionamiento real de Google, pero minúscula. El propio anuncio de Google de 2014: “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.” (traducción) «estamos empezando a usar HTTPS como señal de posicionamiento. Por ahora es solo una señal muy ligera: afecta a menos del 1 % de las consultas globales y tiene menos peso que otras señales, como el contenido de alta calidad».

La cuestión: cualquier sitio con HTTPS recibe esa misma señal mínima, sea PWA o no. Una PWA no obtiene crédito de SEO extra por HTTPS; simplemente no puede funcionar sin él. No venda HTTPS como un beneficio de SEO de las PWA.

Core Web Vitals (Métricas web esenciales): el único solapamiento legítimo

Si hay un lugar real donde se encuentran “buena PWA” y “buen SEO”, es el rendimiento. La guía de PWA de Google empieza por la fiabilidad —“A reliable Progressive Web App feels fast and dependable regardless of the network” (traducción) «Una Progressive Web App fiable se percibe rápida y de confianza independientemente de la red»— y las Core Web Vitals son un factor de posicionamiento confirmado (aunque modesto). Una PWA bien construida que cargue rápido y se mantenga receptiva tenderá a puntuar bien en las Vitals.

Pero lea la causalidad con cuidado: lo que cuenta es la ingeniería, no el hecho de ser PWA. Una PWA hinchada —un bundle de JS enorme, hidratación que bloquea el renderizado, un service worker demasiado agresivo— puede registrar fácilmente peores Core Web Vitals que una página sencilla renderizada en el servidor. La ganancia en Vitals viene de hacer bien el trabajo de rendimiento, algo que se puede hacer con manifest o sin él. Ser una PWA no garantiza buenas Vitals ni concede un atajo hacia ellas.

Las funciones tipo app son UX, no factores de posicionamiento

Añadir a la pantalla de inicio, modo sin conexión, notificaciones push, navegación tipo app: todos son beneficios reales y valiosos de las PWA, y todos son funciones de interacción/retención, no entradas de indexación ni de posicionamiento. La lista de comprobación de PWA de Google hace explícita la separación al poner “installable” (traducción) «instalable» y “discoverable in search” (traducción) «localizable en la búsqueda» en bloques distintos.

Tampoco trate “instalable” como una capacidad única y universal: varía según el navegador y el sistema operativo, lo cual es una razón más por la que no puede ser una señal de SEO (Google no tendría un comportamiento consistente entre navegadores que premiar). El evento beforeinstallprompt, que permite a una PWA mostrar su propia interfaz de instalación personalizada, es un mecanismo exclusivo de Chromium; según la guía de instalabilidad de PWA de MDN, “not supported on iOS.” (traducción) «no se admite en iOS». En iOS Safari, la instalación ocurre únicamente mediante el flujo manual Share → Add to Home Screen (traducción) «Compartir → Añadir a pantalla de inicio» (extendido a Chrome, Edge, Firefox y Orion en iOS 16.4+, todos los cuales usan el motor WebKit que Apple exige en iOS y por tanto comparten esa limitación), no mediante un mensaje automático. Nada de eso cambia el panorama de SEO: solo significa que “¿es instalable mi PWA?” no es un hecho de sí o no independiente del navegador y del sistema operativo del visitante.

Twitter Lite es el caso de estudio al que todo el mundo recurre como “prueba de que las PWA ayudan al SEO” —y sus resultados documentados son reales (un aumento del 65 % en páginas por sesión, un aumento del 75 % en tweets enviados, una reducción del 20 % en la tasa de rebote)—, pero cada una de esas cifras es una métrica de interacción. El propio caso de estudio de Google no menciona en ningún momento el SEO, la búsqueda orgánica ni el posicionamiento. Gran resultado; columna equivocada.

Escaparates de ecommerce en PWA: una nota breve

Los escaparates PWA añaden algunos matices que merece la pena nombrar, porque agravan los riesgos de las SPA. El enrutamiento en el cliente más la navegación por facetas pueden generar URLs con aspecto rastreable que resuelven todas al mismo armazón, o una explosión de URLs con parámetros. El estado del carrito y del checkout vive en el cliente y nunca debería condicionar el contenido de producto indexable. Y cada página de producto debe devolver de forma independiente HTML real y único: la trampa del app shell sale más cara justo donde hay más páginas. Las soluciones son las mismas del SEO para ecommerce y del SEO de navegación por facetas; la capa PWA no las cambia, solo hace más importante la disciplina de SSR/prerrenderizado.

Bing y las PWA

Merece una línea: Bing no ha publicado ninguna guía de posicionamiento o indexación específica para PWA. Sus directrices para webmasters son agnósticas respecto a las PWA (rastreabilidad general, sitemaps, robots.txt, IndexNow), y la extensa documentación de PWA de Microsoft trata por completo de los mensajes de instalación de Edge, PWABuilder y el empaquetado para Microsoft Store: distribución e instalación, una vía separada de la indexación en la búsqueda web. Así que, para Bing, aplique por defecto la guía habitual de rastreabilidad con renderizado de JavaScript; no hay ninguna excepción PWA que aprender.

La conclusión

El SEO para PWA es SEO en JavaScript/SPA más exactamente dos añadidos: ignorar el manifest como entrada de SEO (es para la instalabilidad) y configurar el service worker para que nunca atrape a Googlebot en una caché obsoleta o sin conexión. Si se acierta en eso, una PWA se indexa exactamente igual que cualquier otro sitio bien construido: sin bonificación, sin penalización y con las mismas reglas.

Resumen con IA

Una síntesis condensada de la versión Avanzado:

• Una PWA es, antes que nada, un sitio web. Es un manifest.json (instalabilidad) + un service worker (uso sin conexión y caché) superpuestos a lo que casi siempre es un sitio JS/SPA. Todas las reglas del SEO en JavaScript/SPA se aplican sin cambios.
• Ninguna ventaja de posicionamiento. John Mueller, de Google: las PWA “currently don’t have any advantage in Google Search.” (traducción) «actualmente no tienen ninguna ventaja en la Búsqueda de Google». “Pasar a PWA” no mejora el posicionamiento.
• Manifest.json es irrelevante para el SEO. Controla los mensajes de instalación, los iconos, start_url, display: no hay evidencia de que los sistemas de posicionamiento lo lean. La lista de comprobación de PWA de Google incluso enumera “installable” (traducción) «instalable» y “discoverable in search” (traducción) «localizable en la búsqueda» como categorías separadas.
• El único riesgo real es el service worker. El renderizador de Google no ejecuta service workers al indexar (trata cada rastreo como una primera visita), así que una estrategia de HTML cache-first puede indexar un armazón obsoleto o sin conexión. Use network-first para el HTML y cache-first para los recursos estáticos.
• HTTPS ≠ una ventaja de SEO de las PWA. Es un requisito ineludible para los service workers (contexto seguro) y, por separado, una señal de posicionamiento “muy ligera” que recibe cualquier sitio con HTTPS. No encadene ambas cosas.
• Core Web Vitals (Métricas web esenciales) es el único solapamiento legítimo, y lo que cuenta es la ingeniería de rendimiento, no la etiqueta de PWA. Una PWA hinchada puede puntuar peor.
• Las funciones tipo app (instalación, uso sin conexión, push) son interacción, no posicionamiento. Las famosas mejoras de Twitter Lite son métricas de interacción; ese caso de estudio nunca menciona el SEO. La instalabilidad misma varía según navegador y sistema operativo (iOS Safari no tiene beforeinstallprompt, solo el uso manual de «Añadir a pantalla de inicio»): una razón más por la que no puede ser una señal de posicionamiento.
• Bing no tiene ninguna guía específica para PWA; aplique por defecto la rastreabilidad habitual de JavaScript.

Documentación oficial

Material de fuente primaria sobre las PWA, el renderizado y los hechos en los que se apoya este artículo.

Google / web.dev

• ¿Qué son las Progressive Web Apps? — la definición de Google y los tres pilares (capaz, fiable e instalable).
• ¿Qué hace buena a una Progressive Web App? (lista de comprobación de PWA) — separa «Es instalable» de «Se puede descubrir en la búsqueda» como categorías distintas.
• Service workers (Aprende PWA) — estrategias de caché y ciclo de vida del service worker.
• Fundamentos del SEO para JavaScript — el modo de fallo del app shell que documenta Google.
• Cómo crear Progressive Web Apps indexables (2016) — la publicación original de Google sobre indexabilidad de PWA.
• Caso práctico de Twitter Lite — las métricas de interacción (nota: no contiene ninguna afirmación sobre SEO ni tráfico orgánico).
• HTTPS como señal de posicionamiento (2014) — la declaración de la «señal muy ligera».

MDN / plataforma

• API de Service Worker — el requisito de contexto seguro (HTTPS).
• Cómo hacer instalables las PWA — diferencias de instalabilidad según navegador y sistema operativo, incluido por qué beforeinstallprompt no se admite en iOS.

Bing / Microsoft (no existe guía de posicionamiento específica para PWA; estas son documentaciones de instalación y distribución)

• Directrices para webmasters de Bing — rastreabilidad general; agnóstico respecto a las PWA.
• Descripción general de las Progressive Web Apps (PWA) — centrado en la instalación y la distribución en Edge.

Citas de la fuente

Declaraciones oficiales. Cuando una cita la relata un tercero en lugar de una URL propiedad de Google, la advertencia lo indica.

Google — ninguna ventaja de posicionamiento por ser PWA

• “PWAs currently don’t have any advantage in Google Search, and as far as I know, there are no plans to change this.” (traducción) «Las PWA actualmente no tienen ninguna ventaja en la Búsqueda de Google y, por lo que sé, no hay planes de cambiarlo». — John Mueller, Google, sesión de consultas de Search Central (noviembre de 2021). Leer la cobertura
• “By default, saying going to a PWA will make your rankings better — I don’t think that is the case.” (traducción) «Por defecto, decir que pasar a una PWA mejorará tu posicionamiento: no creo que sea así». — John Mueller, misma sesión. Leer la 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.” (traducción) «Así que el simple hecho de que uno de sus competidores haya pasado de un framework a otro y haya visto una mejora en la búsqueda: ese cambio de framework, desde mi punto de vista, no sería el responsable». — John Mueller, misma sesión. Leer la cobertura

Google — qué es una PWA y el riesgo del 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.” (traducción) «Las Progressive Web Apps (PWA) son aplicaciones web creadas y mejoradas con APIs modernas para ofrecer capacidades avanzadas sin dejar de llegar a cualquier usuario web en cualquier dispositivo con una sola base de código». — web.dev. Ir a la cita
• “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.” (traducción) «Algunos sitios con JavaScript pueden usar el modelo de app shell, en el que el HTML inicial no contiene el contenido real y Google necesita ejecutar JavaScript para poder ver el contenido real de la página que genera JavaScript». — Google Search Central. Ir a la cita
• “Enable search engine discovery through unique URLs, descriptive titles, meta descriptions, and structured data.” (traducción) «Facilita la detección por parte de los motores de búsqueda mediante URLs únicas, títulos descriptivos, metadescripciones y datos estructurados». — lista de comprobación de PWA de web.dev, “Discoverable in search” (traducción) «Localizable en la búsqueda». Ir a la cita

Google — service workers e indexación (relatado)

• “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.” (traducción) «Como tenemos que asumir que quien hace clic en tu página desde una SERP es un visitante que llega por primera vez, ejecutar un service worker normalmente no va a servir de mucho». — Martin Splitt, Google. Leer la cobertura
• “We’re not supporting that because users clicking onto your page from the search result might never have been there beforehand.” (traducción) «No lo admitimos porque los usuarios que hacen clic en tu página desde el resultado de búsqueda puede que nunca hayan estado allí antes». — Martin Splitt, Google (Google I/O 2019). Leer la cobertura
• “I wouldn’t expect it to change — it’s computationally expensive to run service-workers in the background like this for indexing.” (traducción) «No esperaría que cambie: es computacionalmente costoso ejecutar service workers en segundo plano de esta manera para la indexación». — John Mueller, Google (según se informó en julio de 2023). Leer la cobertura

HTTPS: requisito de la plataforma frente a señal de posicionamiento

• “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.” (traducción) «Los service workers solo están disponibles en contextos seguros: esto significa que su documento se sirve mediante HTTPS, aunque los navegadores también tratan http://localhost como un contexto seguro para facilitar el desarrollo local». — MDN, Service Worker API. Ir a la cita
• “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.” (traducción) «hemos empezado a utilizar HTTPS como señal de posicionamiento. De momento es una señal muy leve: afecta a menos del 1 % de las consultas mundiales y pesa menos que otras señales, como ofrecer contenido de alta calidad». — Google, “HTTPS as a ranking signal” (2014). Ir a la cita

La instalabilidad varía según el navegador y el sistema operativo

• “This is not supported on iOS.” (traducción) «Esto no se admite en iOS». — MDN, sobre el evento beforeinstallprompt de mensaje de instalación personalizado. Ir a la cita

Sobre los tiempos de espera de renderizado (contexto fechado)

• “Rendering services won’t wait forever for a page to finish loading.” (traducción) «Los servicios de renderizado no esperarán indefinidamente a que una página termine de cargar». — Hamlet Batista, Search Engine Land. Leer el artículo

¿Debería pasar a PWA? ¿Y qué hará por el SEO?

Un recorrido rápido por las preguntas que la gente trae realmente sobre este tema.

“Estamos valorando una PWA. ¿Ayudará a nuestro SEO?”

• Ningún beneficio de posicionamiento inherente: Google dice que las PWA no obtienen ninguna ventaja en la Búsqueda. → Construya una PWA por los beneficios para el usuario (instalable, sin conexión, cargas repetidas rápidas), no por el posicionamiento. → Tampoco perjudicará al SEO, siempre que el renderizado y el service worker estén bien configurados (continúe más abajo).

“Estamos construyendo (o ya tenemos) una PWA. ¿Es mi contenido realmente indexable?”

• ¿El HTML inicial contiene el contenido real (SSR/prerrenderizado) o es un app shell vacío que rellena el JS?
  • Armazón vacío, sin SSR → esta es la trampa del app shell. Añada SSR o prerrenderizado antes de preocuparse por cualquier cosa específica de las PWA. (La misma solución que en cualquier SPA.)
  • SSR/prerrenderizado ya en marcha → bien; pase al service worker.

“¿Cómo debería mi service worker guardar las páginas en caché?”

• Documentos HTML → network-first (o stale-while-revalidate, con TTL corto). Nunca cache-first para el HTML.
• Recursos estáticos (JS/CSS/imágenes/fuentes) → cache-first está bien y es recomendable.
• Página de reserva sin conexión → asegúrese de que nunca pueda ser la versión que indexe un rastreo nuevo.

“Mi PWA perdió posiciones o tráfico tras el lanzamiento. ¿Dónde miro?”

1. Ejecute URL Inspection (herramienta de inspección de URLs) en Search Console con la prueba en vivo: ¿Google está viendo la página real o una obsoleta, sin conexión o vacía?
2. Si está obsoleta o vacía → sospeche de la estrategia de caché del service worker (HTML cache-first) o de un paso de SSR ausente.
3. Si el contenido está ahí y el posicionamiento aun así cayó → mire qué más cambió la reconstrucción: enlaces internos, contenido, redirecciones, velocidad. La etiqueta de PWA rara vez es la causa.

“¿Tengo que hacer algo especial con el manifest para el SEO?”

• No. Manténgalo válido para la instalabilidad; no tiene ningún papel en el SEO. Dedique el esfuerzo a las URLs, los títulos, las metaetiquetas, los datos estructurados y las Core Web Vitals.

Checklist de SEO para PWA

Repaso rápido para mantener una Progressive Web App rastreable e indexable:

• El contenido real se renderiza en el servidor o se prerrenderiza, y no es un app shell vacío que rellena JavaScript después de la carga.
• Cada ruta tiene una URL real y única mediante la History API (sin enrutamiento por hash ni #!).
• Cada ruta devuelve su propio canonical, título y metadescripción en el DOM renderizado.
• El service worker sirve el HTML con network-first (o stale-while-revalidate, TTL corto); nunca cache-first para documentos HTML.
• Los recursos estáticos (JS/CSS/imágenes/fuentes) pueden ser cache-first; eso está bien.
• La página de reserva sin conexión nunca puede ser lo que indexe un rastreo nuevo.
• URL Inspection (herramienta de inspección de URLs) con la prueba en vivo muestra a Google la página real y actual, comparada con la página en vivo.
• El manifest es válido para la instalabilidad, pero no se trata como una palanca de SEO.
• La instalabilidad se prueba por navegador y sistema operativo, no se da por universal (iOS Safari no tiene beforeinstallprompt; se usa «Añadir a pantalla de inicio» manual), y nada de esa variación se trata como un problema de SEO.
• Se sirve mediante HTTPS (requisito de los service workers en cualquier caso).
• Las Core Web Vitals están sanas: verifique que el bundle de JS y la hidratación no estén lastrando LCP/INP.
• Ecommerce: cada página de producto devuelve HTML real y único; la navegación por facetas y el enrutamiento en el cliente no generan URLs con solo el armazón ni una cantidad infinita de URLs con parámetros.

SEO para PWA — hoja de referencia rápida

¿Afecta al SEO?

Caché del service worker por tipo de recurso

Datos rápidos

• Google no concede a las PWA ninguna ventaja de posicionamiento (Mueller).
• El renderizador de Google no ejecuta service workers al indexar.
• Señal de posicionamiento de HTTPS: “fewer than 1% of global queries” (traducción) «menos del 1 % de las consultas globales» (Google, 2014).
• Bing: ninguna guía específica para PWA; trátela como cualquier sitio con JavaScript.

Playbook de incidentes: el tráfico de búsqueda cayó tras un lanzamiento de PWA

1. Congele la vía de lanzamiento. Detenga nuevos despliegues del service worker y del enrutamiento mientras conserva el estado de producción que falla y los identificadores de la versión.
2. Confirme el alcance. Segmente la caída por plantilla, directorio, dispositivo y momento del despliegue. No se debe dar por supuesto un fallo en toda la PWA a partir de una sola ruta rota.
3. Compare tres respuestas. Guarde la respuesta HTTP en bruto, una página renderizada nueva con el almacenamiento vaciado y una página de usuario recurrente controlada por el service worker. Revise el título, el canonical, las directivas para robots, el texto principal, los enlaces y el comportamiento del código de estado.
4. Inspeccione el registro y la política de caché. En el panel Application de DevTools, identifique el worker activo, su ámbito (scope), las versiones en espera, los nombres de caché y el manejador de navegación. Confirme que las navegaciones HTML no están atrapadas detrás de una respuesta antigua servida con cache-first.
5. Puentee el worker. Anule su registro o use la opción de omisión de DevTools, recargue y repita la ruta afectada. Si el defecto desaparece, el worker o su caché es el límite probable; si persiste, continúe como un incidente ordinario de SEO en JavaScript.
6. Restablezca una vía de navegación segura. Revierta el worker o cambie las peticiones de documento a network-first con una reserva sin conexión explícita. No borre todas las cachés a ciegas si los usuarios dependen de datos sin conexión.
7. Valide y monitorice. Pruebe con un navegador limpio, con un navegador que se está actualizando y con un navegador sin conexión. Después inspeccione URLs representativas y observe el rendimiento en búsqueda durante la ventana habitual de nuevo rastreo.

Tratar el manifest como un archivo de SEO

Meter palabras clave a presión en name, short_name o los metadatos de los iconos no hace que las páginas sean más indexables. Use el manifest para el comportamiento de instalación y ponga el contenido relevante para la búsqueda en HTML rastreable, con títulos, enlaces y canonicals ordinarios.

Guardar el HTML en caché para siempre

Una regla cache-first que trata las navegaciones como recursos inmutables puede mantener vivos textos, canonicals o directivas para robots antiguos después de un lanzamiento. Guarde en caché de forma agresiva el JS, el CSS y las imágenes versionados; dé al HTML una estrategia de actualización que tenga en cuenta la red.

Devolver el armazón sin conexión como si fuera una página correcta

Servir el mismo app shell sin conexión para cada URL no disponible puede parecer que muchas URLs distintas devuelven contenido escaso e idéntico. Mantenga la experiencia sin conexión claramente separada de la navegación normal y no finja que un documento ausente es la página solicitada.

Esconder la navegación detrás de controles que no son enlaces

Un botón que cambia el estado en el cliente puede funcionar dentro de la aplicación sin ofrecer ninguna ruta <a href> rastreable hacia el destino. Use enlaces reales para las rutas que los motores de búsqueda y los usuarios necesitan seguir, y después mejore la transición con JavaScript.

Probar solo como usuario recurrente “en caliente”

Un navegador de desarrollo con un worker instalado y la caché poblada puede ocultar una primera visita rota. Pruebe con almacenamiento limpio, con una actualización desde el worker anterior y con una visita recurrente. Son estados distintos de una PWA.

Ejemplo: la caché de recursos y la de documentos necesitan reglas distintas

La siguiente lógica simplificada de service worker muestra el límite. Los recursos con hash pueden ir con cache-first; las navegaciones de documento deberían intentar la red antes de recurrir a la reserva.

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 política exacta en producción depende de los requisitos de actualización y de uso sin conexión, pero la lección de SEO es estable: el HTML no es el mismo tipo de recurso inmutable que un bundle con huella digital.

Ejemplo: ruta rastreable frente a estado exclusivo de la aplicación

<!-- 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 puede interceptar el enlace para lograr una transición tipo app sin eliminar su URL rastreable.

Prompt: revisar una estrategia de caché de service worker

Pegue el código fuente del worker y un inventario de rutas. No incluya secretos ni respuestas de API privadas.

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: crear una matriz de QA para un lanzamiento 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]

El marco SHELL para revisiones de SEO en PWA

• S: Server response (respuesta del servidor). Una primera respuesta utilizable, o una estrategia de renderizado deliberada, debe exponer la página y no solo un app shell vacío.
• H: Hrefs (enlaces). Las rutas importantes usan enlaces rastreables con URLs estables, no controles que existen únicamente como estado en el cliente.
• E: Expected metadata (metadatos esperados). Los títulos, los canonicals, las directivas para robots y los datos estructurados siguen siendo correctos tanto en bruto como renderizados.
• L: Live documents (documentos en vivo). Las peticiones de navegación tienen una política de frescura apropiada para el HTML; los documentos obsoletos en caché no sobreviven en silencio a los lanzamientos.
• L: Lifecycle tests (pruebas del ciclo de vida). El QA cubre los estados de instalación, activación, actualización, worker en espera, sin conexión y omisión, en lugar de una única sesión “en caliente” de desarrollo.

El marco mantiene acotada la revisión específica de PWA. Si los cinco puntos pasan, la mayor parte del trabajo restante es QA ordinario de JavaScript, rendimiento e indexabilidad.

Consola de DevTools: inspeccionar el worker activo y las cachés

Ejecute esto en la consola de DevTools del navegador, sobre la PWA. Informa de los registros y de los nombres de caché sin modificar ninguno de los dos.

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

Consola de DevTools: comparar una petición de red con una respuesta en caché

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 ?? '' }
});

El resultado demuestra que existe una respuesta en una caché; no demuestra qué manejador de fetch ganará en cada navegación. Confirme el enrutamiento en el código fuente del worker y en el panel Network.

Regex: encontrar manejadores de navegación cache-first riesgosos

Úselo como apoyo para la revisión, no como analizador sintáctico. Busca una condición de navegación seguida, poco después, de una consulta a la caché.

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

Validar un lanzamiento de SEO para PWA

Ponga a prueba sus conocimientos: SEO para PWA

Cinco preguntas rápidas sobre cómo interactúan las Progressive Web Apps con la búsqueda. Elija una respuesta para cada una y después compruébelo.

Recursos que valen su tiempo

Mis textos relacionados

• Problemas y buenas prácticas del SEO para JavaScript — la base de renderizado sobre la que se asienta cualquier PWA; app shell, SSR y lo que el renderizador de Google hace y no hace.
• Guía para principiantes sobre SEO técnico — dónde encajan el renderizado y la rastreabilidad en el cuadro general.

Mis charlas

• Cómo funciona la búsqueda (SlideShare) — mi recorrido por el rastreo, el renderizado, la indexación y el posicionamiento: el proceso por el que tiene que pasar una PWA. (Advertencia permanente: “This is my understanding of systems… not going to be 100% complete or accurate.” (traducción) «Esta es mi comprensión de los sistemas… no va a ser 100 % completa ni precisa».)

De la industria en general

• Google: las Progressive Web Apps no posicionan mejor que los sitios normales (Search Engine Journal) — la cobertura de la sesión de consultas de Mueller que sostiene la desmitificación.
• Google afirma que las Progressive Web Apps (PWA) no tienen ventaja en la búsqueda (Search Engine Roundtable) — reseña independiente de la misma sesión.
• Service Worker: lo que los profesionales de SEO deben saber (SearchViu) — las declaraciones de Splitt y Mueller sobre por qué el renderizador se salta los service workers.
• Fundamentos del SEO para JavaScript (Google) — el modo de fallo del app shell, documentado en la fuente.
• ¿Qué hace buena a una Progressive Web App? (lista de comprobación de PWA) (web.dev) — instalabilidad y descubribilidad como categorías separadas.
• Caso práctico de Twitter Lite (web.dev) — las cifras reales de interacción, y la prueba de que nunca fueron sobre SEO.

Vídeos

• Google Search Central (YouTube) — las explicaciones de Martin Splitt sobre SEO en JavaScript y renderizado cubren exactamente el proceso (rastreo → renderizado → indexación) del que depende una PWA, incluido cómo el renderizador sin estado maneja el JS. Canal

Registro de cambios