How to promote PWA: SEO, indexing, and installation

When you publish a native app, the user journey is simple: they open the App Store or Google Play, enter the name or query, and click "Install." The store itself acts as a search engine, storefront, payment system, and update channel.

With PWAs, it's different. There's no self-contained directory. The user must first learn that the product exists, then find it in search, follow a link, or get a QR code, and only then consider installation. All of this falls on the developer, and this article is about that.

I launched a PWA in the Kazki AI project (a service for generating children's fairy tales), configured push notifications for a psychologist's blog, and am now integrating a PWA into another project. At the start, it was important for me not only to make the service accessible via a link but also to explain to potential users what it offers and what problem it solves. That's why I view PWAs not just as a technology but also as a product that needs a clear public page to attract an audience. If you're still choosing between PWA and native, read PWA vs. Native in 2026: Comparison, Choice Scenarios, and a Real Case first.

📚 Table of Contents

• 📌 How PWA Discoverability Differs from Native Apps
• 📌 How to Make a PWA Visible in Google
• 📌 Rendering, Routing, Indexing: Why PWAs Are "Invisible"
• 📌 Core Web Vitals for PWAs
• 📌 How Users Find PWAs by Name
• 💼 Web App Directories
• 💼 Google Play, App Store, Microsoft Store
• 💼 Promotion Beyond Search
• 💼 From Visitor to Installation
• 💼 Push Notifications: How to Bring Users Back
• 💼 How to Measure Results
• 💼 Is SoftwareApplication Markup Needed?
• ✅ PWA SEO and Distribution Checklist
• ❓ Frequently Asked Questions (FAQ)

🎯 Section 1. How PWA Discoverability Differs from Native Apps

Short answer: For a native app, search, trust, and installation are concentrated in one place (the store), while a PWA is distributed across the web. Each channel that works "out of the box" in the store must be built separately for a PWA.

In the app store, a user enters a name or category, sees results, ratings, and screenshots, and installs the app with one button. This path doesn't exist for PWAs. They can be found on Google by a query about a task, received via a link from a friend, accessed from an article or directory, or by scanning a QR code. Each of these sources needs to be prepared separately.

Discoverability Channels: What Works for Native vs. PWA

When Absence from the Store is a Problem, and When It's Not

I recommend considering the product type and audience behavior. Absence from the store is critical for mass consumer apps where a significant portion of users are accustomed to searching "name + App Store." For SaaS, tools, content, and B2B products, where users come from Google searching for a solution or follow a direct link, this is usually sufficient. At the same time, I don't advise treating this as a universal rule: first, check your own analytics to see where users come from, and then decide if presence in the stores is necessary.

🎯 Section 2. How to Make a PWA Visible in Google

A Google user searches not for "PWA" but for a solution to their problem: "app for generating fairy tales," "online task planner." If the only entry point to your product is a login screen, there's nothing for search to latch onto. In my experience, there are projects where clients demand mandatory authorization, leaving most pages closed to search engine bots. In such cases, I recommend creating separate public pages describing the product, its features, and use cases so that potential users can find it through Google even before registering.

What Should Be on a Public Page

• A separate URL for each important "screen": homepage, features, pricing, articles. Not one URL for the entire application.
• Real content in HTML: product description, features, images with alt text, a clear call to action.
• Unique title and meta description on each page. Google may rewrite them in search results, and description is not a ranking factor, but it affects whether users click on the snippet.
• Standard <a href> links. Googlebot follows links with the href attribute, not JavaScript click handlers.
• sitemap.xml: helps find pages but doesn't guarantee indexing.
• Do not block scripts and styles in robots.txt that are needed for page rendering.

<head>
  <title>Kazki AI — AI-powered children's fairy tale generator</title>
  <meta name="description" content="Create personalized fairy tales for children in seconds.">
  <link rel="canonical" href="https://example.com/">
  <link rel="manifest" href="/manifest.json">
</head>

Search Console: Verification Instead of Assumptions

If you're new to this, I recommend starting with Google Search Console. Register your site and use the "URL Inspection" tool. It shows whether the page is indexed, what HTML Google saw after rendering, and what the page screenshot looks like. For a PWA, this is the fastest way to find out what the search bot actually sees, not just what you see in your browser. The "Page Indexing" report will help you understand why individual URLs didn't get indexed. If you encounter difficulties with setup or indexing checks, write to me – I'll help you figure it out.

Bing and IndexNow

I recommend not ignoring Bing just because of its smaller market share compared to Google. In some countries and among certain audiences, it's used more frequently, so you should consider the geography of your traffic. Add your site to Bing Webmaster Tools and set up IndexNow to notify supported search engines about new and updated URLs. This is an additional channel for page discovery that is easy to set up. Even if most visitors currently come from Google, I consider this integration worthwhile: it expands search visibility capabilities without needing to change your core SEO strategy. However, IndexNow does not guarantee page indexing. Google does not use this protocol, so for it, continue to work with sitemaps and Google Search Console.

Queries About Tasks, Not Technology

Users rarely search for "PWA." Frame your pages around what a person wants to do, and save the word "PWA" for articles for developers. We'll look at examples and action steps for a new brand in Section 5.

Next is the most important technical section for PWAs: why an app that works great in the browser might appear empty to Google.

🔗 Read Also

• PWA vs. Native in 2026: Comparison and Real Case
• 8 Critical Mistakes When Integrating a PWA: Scenarios, Causes, and Code Solutions

🎯 Section 3. Rendering, Routing, Indexing: Why PWAs Are "Invisible"

In my experience, most PWA search visibility issues are related to technical implementation. Content may only appear after JavaScript execution, all internal pages might use a single URL, and non-existent addresses might return a 200 status instead of a 404. The manifest or Service Worker alone doesn't solve these problems: it's crucial to correctly configure routing, HTTP statuses, and content accessibility for search bots.

Google processes JavaScript pages in three stages: crawling, rendering, and indexing. Rendering uses the latest version of Chromium, but it works in a queue, so content that appears only after script execution may be indexed later than regular HTML. Furthermore, the bot doesn't click, scroll, or log in. Anything that appears only after user action won't be indexed. [Google: JavaScript SEO]

Problem 1. Client-Side Rendering (CSR)

In a classic SPA, the server sends an empty shell, and content appears after scripts load. There are three approaches, and the choice should depend on the page type:

From my experience, I recommend separating the public and private parts of a PWA. Landing pages, feature pages, pricing, and articles should be served as ready HTML, while the interface for an authorized application can remain client-side. In my projects, I also consider a separate DTO for centralized SEO data and sitemap generation: public URLs, update dates, and other necessary metadata. This simplifies index management but doesn't replace proper HTML generation, HTTP status configuration, and page accessibility for search bots. Google previously described dynamic rendering—providing a separate page version to bots—as a workaround but doesn't recommend it as a long-term solution.

Problem 2. One URL for the Entire Application

If sections switch without changing the address, or the address looks like /#/pricing, it's one page for Google. The fragment after the # is not considered a separate URL. Use the History API so that each public section has a clean address:

// Clean URLs instead of hash routes
history.pushState({}, '', '/pricing');

// In React Router: BrowserRouter, not HashRouter
// In Vue Router: createWebHistory(), not createWebHashHistory()

The server must be able to serve the correct page for a direct request to /pricing, not just after the SPA loads.

Problem 3. "Soft" 404s

A typical SPA trap: the server returns index.html with a 200 status for any unknown path, and the "Page Not Found" message is displayed by JavaScript. For a search engine, such an address might appear as a successfully loaded page, not a 404 error, creating a risk of non-existent URLs appearing in the index. Solution: at the server level, return a true 404 status for non-existent routes, and for deleted pages, use 410 or 301 to a relevant current address. From my experience, I recommend checking this not only from an SEO perspective but also in the context of GEO: correct routing helps systems receive correct server responses, although it doesn't guarantee mentions or citations in AI responses by itself.

Problem 4. Meta-data and Links from JavaScript

• It's better to serve title, description, and canonical directly in the server's HTML, rather than injecting them with a script after loading.
• Navigation should use standard <a href="/path"> links, not onclick without href.
• Content that loads only after a click or scroll will not be seen by the bot.

What Manifest and Service Worker Provide for SEO, and What They Don't

A word on Service Worker: aggressive HTML caching can serve users outdated pages, and errors in fetch handling break routing. I discussed common errors and fixes in the article 8 Critical Mistakes When Integrating a PWA. The main rule for SEO is: what needs to be indexed, the server should serve as is, regardless of what the Service Worker does.

How to Check What Google Sees

1. I open the "URL Inspection" section in Google Search Console and run a live check of the public page.
2. I review the rendered HTML and screenshot. If the page is empty or the HTML lacks key text, I check if rendering is working correctly.
3. I compare the initial server response (curl -s https://example.com/) with what the browser shows. If the curl result lacks the main content, it means it might depend on JavaScript execution.
4. In the "Page Indexing" report, I check the statuses "Discovered, currently not indexed" and "Soft 404 error" to understand why pages are not being indexed.

🎯 Section 4. Core Web Vitals for PWA

Short answer: speed is twice as important for PWA – as a page quality signal for Google and as part of the product itself. But it's a supporting factor, not a replacement for relevant content. In my practice, I recommend considering not only loading speed but also how it affects user interaction with the site. I discuss this in more detail in the article Core Web Vitals: Three Metrics That Affect Site Conversion.

Google uses Core Web Vitals to assess user experience. Key metrics and "Good" thresholds:

• LCP (Largest Contentful Paint): up to 2.5 s;
• INP (Interaction to Next Paint): up to 200 ms;
• CLS (Cumulative Layout Shift): up to 0.1.

PWAs have specific risks. A heavy JavaScript bundle delays LCP, especially when content is generated on the client side. Service Workers can speed up repeat visits but don't necessarily help on the first open. Therefore, I recommend optimizing the initial load: splitting JavaScript bundles, deferring the loading of secondary scripts, specifying image dimensions to reduce CLS, and not blocking page rendering with heavy resources.

I check real performance metrics in the Core Web Vitals report in Google Search Console and PageSpeed Insights. If a site has enough field data, PageSpeed Insights shows real-user data from the past 28 days. Lighthouse lab data is useful for diagnostics but doesn't replace field data. I explain how to check speed and optimize step-by-step in the article Google PageSpeed Insights: How to Achieve 90 Points.

🎯 Section 5. How Users Find PWA by Name

Short answer: in a store, searching by name works on its own. On the web, only a product that Google already "knows about" will be found by name, and this is not guaranteed for a new brand without mentions.

Someone hears a name from a friend and types it into Google, not a store. If the name is new or coincides with a common word, other sites will appear in the search results. Meta tags won't help here, as they don't guarantee the top position by name.

What Helps, Why It's Important, and What Happens If You Neglect It

• Unique Name. Check search results for it before launching. If other products occupy the top positions, consider changing the name or adding a clarification ("Name + Category").

  Why it's important: search engines show results by relevance, and if the name coincides with a common word or another product, the query becomes ambiguous. Your site competes not only within your niche but with everyone who has a similar name.

  If neglected: a person who heard the name from a friend will end up on someone else's site, and you will lose your most qualified visitors. Changing the name after launch is expensive: you'll have to transfer the domain, links, mentions, and profiles, and the accumulated mentions under the old name will be partially lost.

• Consistent Spelling Everywhere: domain, title, name in the manifest, social media profiles, and directories.

  Why it's important: consistent spelling helps both search engines and people understand that it's the same product. The name in the manifest, moreover, is displayed under the icon on the home screen and in the installation prompt, so it's part of brand recognition.

  If neglected: mentions are scattered across variations ("Kazki AI," "KazkiAI," "Казки AI"), and it becomes harder for Google to associate them with a single site. Users type in different spellings and don't always find the product, and a discrepancy between the name on the site and the icon undermines trust in the app.

• Public Product Page with the exact name in the heading and text.

  Why it's important: this is the page that can appear for a branded search query. The private part of the app, accessible only after login, is not indexed, so without a public page, Google won't show anything.

  If neglected: search results for the product name will only show third-party pages (directories, social media, reviews) or nothing relevant at all. The user won't be able to quickly verify that the product exists and that it's the official site, and some visitors will leave.

• Mentions on Other Sites: articles, directories, discussions. External links and mentions help Google understand that the brand exists.

  Why it's important: for a new brand, this is one of the few external signals that the product is real and that it's not just the owners talking about it. Quality mentions also bring in real visitors.

  If neglected: you remain the sole source of information about yourself, and it becomes harder to "establish" a new brand in search results. There's also a reverse risk: profiles in third-party directories might outrank your site for a branded query if your own pages are weak.

• Site Name Markup (WebSite with name) helps Google display the name correctly in search results, but it doesn't affect rankings for branded queries.

  Why it's important: it's a hint for Google about which name to show above the snippet. It's inexpensive to implement and especially useful when the name is complex or the domain doesn't match the brand.

  If neglected: Google will choose the name itself based on other signals (headings, title, mentions), and the domain or an incorrect spelling might appear in search results. This doesn't harm rankings but spoils the first impression of the snippet. Markup provides no guarantees, and Google may show a different name.

Summary: none of these points individually "promote" a brand to the top. Together, they reduce the likelihood that someone searching for your product will find someone else's instead. For a new brand without demand, these steps won't bring quick traffic, but they lay the foundation on which branded search can grow later.

New Brand vs. Brand with Demand

When I work on promoting a new product, I recommend focusing on user tasks at the beginning, not just the brand name. For example, instead of relying on search queries with the new service's name, it's worth addressing queries like "app for bedtime stories." At the start, people might not know about the product yet, so it's important to give potential users the opportunity to find it through a specific need. Brand demand may emerge as the product spreads, but this is not a guaranteed stage for every project.

In the Kazki AI project, I also focused on the practical application of the service – generating children's fairy tales, not just its name. This is one approach I recommend considering for a new brand, but not a universal rule: the strategy depends on the niche, audience, and existing demand. To assess the results, I advise monitoring branded queries in Google Search Console. When users start searching for the product by name, it can indicate growing recognition.

💼 Section 6. Web Application Directories

Short answer: directories can bring in the first users and mentions, but mass listing "for links" doesn't work. Choose platforms based on a relevant audience, not quantity.

Directories are of two types, and their purpose is different:

• User Sources: launch platforms (like Product Hunt), thematic SaaS and tool directories where people actually look for new products.
• Link and Mention Sources: directories that help Google associate the name with your site. Many directories use nofollow on links, so don't expect SEO benefits from them.

How to Evaluate a Directory

Add your product to a few truly relevant directories, not hundreds of random ones. Use a separate UTM tag for each to see in analytics which channel brought traffic, not just "referral."

💼 Section 7. Google Play, App Store, Microsoft Store

Short answer: PWAs can be published in stores, but it doesn't happen automatically or without modifications. Each store has its own wrapper and requirements, and Apple is the strictest with "just websites in wrappers."

Is It Worth Doing

Publishing in a store adds another channel for discoverability and trust, but it also comes with commissions, moderation, and maintenance of a separate package. If your audience comes from Google for a specific task, a store might be unnecessary. If users are accustomed to searching for apps in stores, it's an option worth considering. Keep in mind that for the App Store, native value beyond the website is likely needed, such as push notifications, system integration, or offline features, and factor in time for this.

Read about when a native approach is justified in the article PWA vs. Native in 2026.

💼 Section 8. Promotion Beyond Search

Short answer: search brings people who are already looking for solutions. You need to find the rest yourself through communities, content, partnerships, and direct links.

For PWAs, a link is a full entry into the product, without the intermediate step of "going to the store." This is convenient for most channels. Group them by purpose:

A QR code leading to a PWA is especially convenient when the product is used in a specific location: a person scans it and immediately opens the app without a store. Use UTM tags for all channels, otherwise, everything will merge into "direct" in analytics.

💼 Section 9. From Visitor to Installation

Short answer: first visit, installation, and regular use are three different events. Installation is not a goal in itself; its purpose is user retention.

Android and Desktop (Chromium)

Chrome and other Chromium browsers support the beforeinstallprompt event. You can intercept it and show your own "Install" button at the right moment, not immediately upon entry:

let deferredPrompt;

window.addEventListener('beforeinstallprompt', (e) => {
  e.preventDefault();          // don't show the default banner immediately
  deferredPrompt = e;
  showInstallButton();         // show our button
});

installBtn.addEventListener('click', async () => {
  if (!deferredPrompt) return;
  deferredPrompt.prompt();
  const { outcome } = await deferredPrompt.userChoice; // 'accepted' | 'dismissed'
  deferredPrompt = null;
  hideInstallButton();
});

window.addEventListener('appinstalled', () => {
  // installation event, only in supported browsers
});

This event is not available in all browsers: for example, it's not in iOS Safari. Therefore, it's not suitable as the sole way to show a prompt.

iOS

There is no automatic installation prompt on iPhones. The user must manually go through "Share → Add to Home Screen." Therefore, you need to show the prompt yourself: a short instruction with a screenshot at the moment when the person has already seen the product's value. Since iOS 16.4, "Add to Home Screen" can also be offered by third-party browsers, but the availability of the option depends on the browser, so it's more reliable to write the universal path in the instructions. Why this is important for push notifications, I discussed in the article PWA Push Notifications on iOS in 2026: What Really Works: without installation on the home screen on iOS, you cannot subscribe to push notifications.

When to Offer Installation

• After the first useful action (created a story, saved settings), not on the first page load.
• With an explanation of the benefits: faster launch, notifications, home screen icon. Not "Install our app," but what exactly the user will get.
• Don't show the prompt if the app is already open in standalone mode, and don't pester those who dismissed it: remember their choice for a few days.

💼 Section 10. Push: How to Bring Back Users

Short answer: search brings a person once, and push helps bring them back. Therefore, for PWAs, it's part of the engagement strategy, not an add-on feature.

A user comes from Google, looks at the product, and closes the tab. Without a return channel, you lose them. Push solves this: "a new story is ready" brings the person back to the app without a store and without a newsletter.

What I've Set Up in Practice

In Kazki AI, push notifications informed users about new stories and reminded them about subscriptions. For a practicing psychologist's blog, notifications informed subscribers about new courses and publications. Both projects showed that for informational notifications, the technology works reliably enough, and critical messages are better duplicated by email. Details with code (subscription, manifest, Service Worker, push handler, 7 reasons why pushes don't arrive) are in the article PWA Push Notifications on iOS in 2026: What Really Works.

What's Important for Discoverability and Retention

• Ask for permission after providing value, not on the first load. On iOS, the request is only possible with a button click.
• Don't rely solely on push. On iOS, subscriptions can become invalid, and some users simply won't install the PWA. Add email, an in-app feed, and a badge counter on the icon.
• Service or Own Backend. If the scenario is simple, your own sending is sufficient. If segmentation and campaigns are needed, consider ready-made services. Comparison: Push Services for PWA: OneSignal, FCM, Pushwoosh, WonderPush, and Braze.

💼 Section 11. How to Measure Results

Build a funnel from search impression to repeat visit, but don't expect uniform installation metrics across all browsers. Take search metrics and product metrics from different tools.

The funnel looks like this:

1. Search Impression (Search Console: impressions, average position);
2. Click (Search Console: clicks; analytics: sessions by source);
3. First Launch (analytics: first target action event);
4. Installation, if measurable;
5. Repeat Visits (analytics: 7/30-day retention);
6. Target Action (registration, purchase, subscription).

What Can Be Measured and What Cannot

A practical way to distinguish sessions of an installed app from regular tabs:

const isStandalone =
  window.matchMedia('(display-mode: standalone)').matches ||
  window.navigator.standalone === true;

// Example for GA4: pass the mode as an event parameter
gtag('event', 'app_open', {
  display_mode: isStandalone ? 'standalone' : 'browser'
});

window.addEventListener('appinstalled', () => {
  gtag('event', 'pwa_installed');
});

To see the display_mode parameter in GA4 reports, register it as a custom dimension. Another trick: add a tag to the start_url in the manifest (e.g., /?source=pwa) so that launches from the home screen are visible in traffic sources.

Analyze not only the number of installations. It's more important whether those who installed return and whether users come for the queries you actually wanted to establish.

💼 Section 12. Is SoftwareApplication Markup Needed

Short answer: markup helps search engines understand the page but is not a condition for indexing and doesn't improve rankings. Google shows special results for apps only if its requirements are met, and there are no guarantees.

I recommend considering the use of SoftwareApplication or WebApplication from Schema.org for the public product page. Such markup helps search engines better understand what the service offers. At the same time, its implementation is not a mandatory condition for indexing or page visibility in search. If you want to get rich results for an app in Google, check the current requirements in the official documentation: they may change. It's important that the markup corresponds to the actual content of the page. Do not add fictitious prices, ratings, or reviews – this violates Google's rules and can lead to the loss of rich results.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebApplication",
  "name": "App Name",
  "applicationCategory": "BusinessApplication",
  "operatingSystem": "Web",
  "url": "https://example.com/",
  "offers": { "@type": "Offer", "price": "0", "priceCurrency": "USD" }
}
</script>

This is a minimal example. Add ratings (aggregateRating) only when you have real reviews visible on the page. Markup is needed for clarity, not as a promotion method, so focus on sections 2-5.

✅ Section 13. PWA SEO and Distribution Checklist

The order of actions depends on whether the product has a recognizable brand. Below are two scenarios and a plan for the first seven days.

Scenario A. New product without a brand

• Public product page with content in HTML (SSG/SSR/prerendering).
• Clean URLs, correct 404/410 statuses, no hash routes.
• Unique title and description, sitemap.xml, robots.txt without blocking scripts and styles.
• Search Console and Bing Webmaster Tools, live URL check.
• Pages for user task queries, not for names.
• 2-3 relevant directories and thematic communities with UTM tags.
• Install button (Chromium), prompt for iOS, push after the first value.
• Analytics with the display_mode parameter and the appinstalled event.

Scenario B. Existing product with established demand

• Check brand queries in Search Console and their snippets (title, site name).
• Rendering audit and "soft" 404s for pages that already have impressions.
• Core Web Vitals for pages with the highest traffic.
• Consider publishing in stores if the audience is looking for the app there.
• Push and email to bring back existing users.

Plan for the first 7 days after release

This is an action plan, not a growth forecast. Indexing and positions depend on many factors, and a result in seven days is not guaranteed.

❓ Frequently Asked Questions (FAQ)

Can PWA be found in the App Store?

Only if it's published in the store through a native wrapper. A regular PWA does not appear in the App Store: users find it through search, links, or directories, and on iPhones, they add it to the home screen manually.

How does Google index PWA?

Google crawls public URLs, renders them in Chromium, and adds them to the index. Content that appears only after JavaScript execution may be indexed with a delay, and content protected by authorization is not indexed at all. It's more reliable to serve public pages as ready HTML (SSG, SSR, or prerendering).

Does PWA need a separate website?

PWA is a website, but the public part (landing page, features, prices, articles) should be made into separate indexed pages. The private part of the application behind a login will not appear in search results.

Can PWA rank in Google?

Yes, if its public pages are available for indexing, have unique content, and match the user's query. The fact that it's a PWA does not affect its position: the manifest and Service Worker are not ranking factors.

Can PWA be published in Google Play?

Yes, through Trusted Web Activity: PWA is packaged into an Android package, and the domain association is confirmed. Check the Play Console for current requirements for developer accounts and apps, as they change.

How to install PWA on iPhone?

Open the site in Safari (or another browser that has this option), tap "Share," and select "Add to Home Screen." There is no automatic installation prompt in iOS, so you need to show a prompt in the interface. Push notifications on iPhone are only available for apps added to the home screen.

✅ Conclusions

A native app is found in the store, while a PWA has to be "distributed" by yourself. Search, proper rendering, directories, re-engagement through push notifications, and measurement form a single system, and each link is necessary.

• Technical foundation: public pages as ready HTML, clean URLs, correct statuses.
• Discoverability: queries about the task at the start, brand demand later.
• Distribution: 2-3 relevant directories, communities, stores if needed.
• Re-engagement: push + email + in-app, considering iOS limitations.
• Measurement: funnel from impression to repeat visit.

🔗 Read also

• PWA vs Native in 2026: comparison, choice scenarios, and a real case
• PWA Push Notifications on iOS in 2026: what really works
• 8 critical mistakes when integrating PWA: scenarios, causes, and solutions with code
• Push services for PWA: OneSignal, FCM, Pushwoosh, WonderPush, and Braze

📖 Sources

• Google Search Central: JavaScript SEO basics
• Google Search Central: Make your links crawlable
• Google Search Central: Build and submit a sitemap
• Google Search Central: Software app structured data
• web.dev: Web Vitals
• web.dev: Customize the install experience
• Chrome for Developers: Trusted Web Activity
• Apple: App Store Review Guidelines (section 4.2)
• PWABuilder
• IndexNow