Technical SEO for Progressive Web Apps (PWA)

Have you seen the buzz about the future of the web being Progressive Web Apps (PWAs)?

The dream is that just like responsive design enabled us to ditch those separate mobile pages and serve both mobile and desktop visitors the same URL, a progressive web app means we can serve that same page in place of a mobile app as well.

Awesome, right? No more resources spent on building a separate mobile app. No more lost or diluted value signals that would otherwise help your web site rank well in search engines. No more confusion for visitors engaging with multiple properties with different set ups.

And the Google page about progress web apps certainly makes it sound like a dream come true:

Flipkart, India’s largest e-commerce site, decided to combine their web presence and native app into a Progressive Web Application that has resulted in a 70% increase in conversions. “We know that everyone needs to build mobile-first experiences. With Flipkart Lite, we’ve developed a powerful, technically-advanced web app that performs as well as our native app. We now feel we have the best of both worlds.”

What could possibly go wrong?

Well, beyond the core issue that the technology isn’t supported by all browsers (at least not yet), which means you can’t actually ditch everything but the PWA pages (notably, PWA doesn’t yet work on Safari, so therefore it doesn’t work on iPhone), the pages might not be indexable by Google.

It’s easy (and tempting) to assume that because Google is launching or actively supporting something, it’s search-friendly by default. But the reality is that Google is a big company. The team working on PWA isn’t the same team that works on search. I wrote about the disconnect between teams at Google and the need for Google products to be search-friendly out of the box back in 2009. But that disconnect continues today (as the company is bigger today than ever).

Technical SEO Issues with Progressive Web Apps (PWA)

The URL structure may not be crawlable

Take a look at the Washington Post’s implementation of PWA. URLs look like this:

https://www.washingtonpost.com/pwa/#https://www.washingtonpost.com/politics/next-for-democrats-a-delicate-dance-to-broker-peace-between-clinton-and-sanders/2016/06/08/34000b6c-2cbd-11e6-9b37-42985f6a265c_story.html

Search engines drop everything in the URL beginning with the #, so all PWA URLs are seen as this:

https://www.washingtonpost.com/pwa/

Google’s John Mueller recently posted this URL structure on Google+:

Avoid using “#” in URLs. Googlebot rarely indexes URLs with “#” in them. Use “normal” URLs with path/filename/query-parameters instead, consider using the History API for navigation.

I asked John specifically about this implementation and he said:

yes, if they replaced the existing site with that, it would probably break their crawling & indexing. Some PWAs implement URLs more “traditionally,” which could work with our crawling & indexing. At this point, it’s more about figuring the browser part out first, which can be hard enough on its own, and then working out the full picture over time.

A part of why I made this post was to encourage PWA-makers to use “traditional” URL structures, so that they don’t need to do too much more for SEO should they decide to move their existing site over at some point. There are ways to both have a PWA & keep the SEO side working, it’s not always easy, but a good opportunity for smart technical SEOs who like to stay ahead of the curve & work with hot modern technologies.

So if you want the PWA URLs to be indexable, implement the URL structure in a way that’s indexable, as I described in that JavaScript article way back in 2009.

The content may not be crawlable by Googlebot

John notes in his Google+ post that while Googlebot supports some JavaScript, it doesn’t support Service Workers.

And as Google’s documentation notes:

Service workers are a key technology needed for your app.

The pages are not (yet) “mobile first, serve to everyone” (and don’t work at all for iPhone)

The biggest draw of the Flipkart case study may be that the web presence and native app are combined. But that certainly isn’t what’s happening with the Washington Post. When I access a PWA URL on a desktop browser, I see this:

Washington Post PWA Example

But OK, that’s just a beta. What happens with Flipkart?

Apparently PWA is also a separate site for Flipcart as the app is only supported for Android (as PWA is only supported by Chrome and Opera, and not by Safari).

As Flipkart notes in their announcement blog post:

Flipkart Lite is currently compatible on select browsers. Presently available on Chrome – Version 42 & above and Opera – Versions 33 & above

And indeed, if you go to the Flipkart web site on a desktop browser (even Chrome) or iPhone, you get the standard site.

If you want SEO benefit, treat the pages like mobile-only URLs

Since for now, PWA pages are separate from the standard site, they could end up hurting SEO if you don’t take steps to prevent that. Separate URLs with the same  content lead to duplicate content issues, lost or diluted value signals like PageRank, and potentially a negative user experience (for instance, if a desktop visitor ends up on a mobile page or an iPhone visitor ends up on a non-supported page).

My recommendations for handling separate mobile pages apply here.

If you implement PWA, you have a couple of options if you’re thinking about SEO:

  • Go ahead and use those # URLs, like the Washington Post does – with this option, you won’t have to worry about duplicate content or multiple URLs that point at the same page. However, any value signals that those URLs accumulate (like external links, which accrue PageRank to those URLs) will be lost.
  • Create a search-friendly URL structure and follow the recommendations for search-friendly mobile URLs – this option is more work, but  any value signals the PWA URLs accumulate will be consolidated with the regular (canonical) version of the URL. This option includes:
    • Implementing the aforementioned search-friendly URL structure (no #).
    • Redirecting desktop users from the PWA URL to the canonical (desktop) URL.
    • Including a canonical attribute on the PWA URLs with value of the desktop URL.
    • Using the Vary header (optional, but recommended to reduce the possibly of confusion during crawling)

As John notes in his Google+ post, use progressive enhancement techniques for any JavaScript or AJAX implementation and make sure you aren’t blocking any resources required to build the pages.

While sites should definitely always continue to take advantage of advances in web technology and improved user experiences, we also have to make sure that as we implement these advances, we don’t inadvertently degrade the user experience for large numbers of visitors or hinder the site’s ability to show up for potential audiences (in places like major search engines).

Monitor the SEO Impact of Technical Site Changes with Keylime Toolbox

With Keylime Toolbox’s Crawl Analytics, which generates SEO-focused reports from your site’s server logs, you can see exactly what URL are being crawled and can monitor both the number of URLs crawled and the number of errors.

Googlebot Crawl Logs

This data lets you see not only if critical issues have been introduced that impact crawling and indexing, but also whether the URLs you expect are being crawled actually are.

Top Crawled URLs

With Keylime Toolbox’s Query Analytics, you can monitor a number of SEO metrics that can provide insight on the impact of technical changes (both positive and negative). For example:

Provided Queries

Google Ranking Trends

CTR Benchmark

Sign up for a free trial to check out the data for yourself.

3 thoughts on “Technical SEO for Progressive Web Apps (PWA)

Leave a comment to Edward Sturm Cancel reply

Your email address will not be published. Required fields are marked *