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:
Search engines drop everything in the URL beginning with the #, so all PWA URLs are seen as this:
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.
The content may not be crawlable by Googlebot
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:
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).
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)
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.
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.
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:
- the number queries that site appears for (a sharp decline may indicate a loss in the number of pages indexed)
- average ranking of a set of queries or individual queries (a decline may indicate a loss of PageRank, possibly due to diluted signals as described in this article)
- the average click through rate of a set of queries, individual queries, or all queries at a particular ranking position (a decline may indicate a loss of rich snippets or other meta data that impacts the search results display; an improvement may indicate that those newly added rich snippets are working!)
Sign up for a free trial to check out the data for yourself.