Service workers and SEO: What developers should know

Developers working on websites, as compared to native apps, were long at a disadvantage because they were limited to using web technologies like HTML, CSS and JavaScript. But that’s changing as these technologies are being adapted to deliver more app-like experiences. In this column, I’ll look at service workers and explain how they should be employed for the best result in terms of SEO.

The original idea for service workers is to allow programmers the ability to create native-like apps using only Web technology. This JavaScript API is being brought to standard with contributions made by Chrome developers and (Firefox) Mozilla. The draft specification — which is effectively authoritative —  is now published at W3C (World Wide Web Consortium) so Edge, Opera, and Apple Safari have also added support.

Native app UX

Previously, creating a native app for a desktop meant programmers might use C++ on Windows, or Objective C on a Mac. These aren’t really Web technologies. On the Web, you’re largely restricted to using HTML, CSS, and JavaScript, but the world of websites has been progressing so quickly that the UX (User Experience) has already become very app-like. It’s only natural that browser makers want to extend new web technologies to new user devices.

Static vs. dynamic

Although you can already write a basic website on your desktop to open in a browser and you might even transfer files to a phone, the result has always been very static.

For example, with your basic site open in a browser, you can write a notification. But if you don’t have the website open in a browser, it won’t work. To have a remote website trigger a notification when your local website is not running in a browser, you need a service worker. Service workers let you do that, which is very powerful.

Magical features

Think of the service worker as the magic that lets the SEO-savvy developer create a website with features that communicate to users who “install” an app. Users can install as much as a PWA (Progressive Web App), or, at minimum, some representation of the website onto their computers, tablets, and phones. Communication capabilities are then augmented with features like push notifications and dynamic content on the device.

Purpose

Before you ask your developers to implement something like this, make sure that whatever you want to build, you are building for the right reasons. The decision tree begins with: What website are you considering adding service worker capabilities to, and why? Will just a simple notification service suffice or should you really build a whole downloadable web app? What devices are you targeting and what UX do you expect? Do you want to retrieve time-sensitive information such as sports scores or stock prices?

Personally, I have someone in mind when I consider the audience that would benefit from a PWA. She often hikes to heights where there is no cell service and she wants an app which works offline. As explained above, she wouldn’t need service workers for a basic website. For that, I could write files and transfer them to her device. But that wouldn’t allow for any updates or more dynamic features. Service workers have been designed explicitly to enable the creation of a PWA that would work both online and off. I don’t have to transfer updates to her files by hand to update the site on her device? Brilliant.

With a PWA, I can store app “shell” files (think of them as layout files) on the device, and a global cache object lets me load local content or retrieve the latest dynamic content, depending on the circumstances. I can write logic using the service workers API to load the app in the fastest possible manner whether online or off. That totally rivals what most native apps do, and I don’t have to submit it to be approved for a store’s walled garden. I can use my own pay mechanism, too.

SEO implications

How do service workers affect SEO? In a small, indirect way they do, but you’re not going to be able to write some service worker hack to raise all your rankings.

Security awareness by browser makers restricts the API to employing only the vital methods required to implement the desired feature capability, including TLS (SSL or what you might know as HTTPS) to operate. There’s not much to know about here when it comes to general SEO, but SEO developers and technical SEO practitioners may derive some benefits.

SEO developers

What you may be able to take advantage of is that Google is crawling to index websites and can thereby recognize when a website has a PWA offering. Perhaps they’ll put an icon for direct install in their SERPs. It probably won’t be anytime soon, because of major trust issues, but it’s possible they might otherwise indicate that a website has a PWA offering in their SERPs. But remember, you must still do SEO for the source website so that your PWA is discoverable in the first place.

Technical SEO

One implication for using service workers in a wider SEO context is the ability to build a way to use JavaScript injection techniques to dynamically and intelligently adapt your website content to search engine rankings. I’m mentioning this possibility as a bit of a thought experiment because there are far better ways to do this. But the hint of an idea is out there in reference to service workers for “search and replace” on Cloudflare.

Close to the edge

“Edge SEO” — defined by Dan Taylor, who coined the term, as “using edge computing technologies to create new SEO implementation, testing, and research processes” — is an exciting possibility on the horizon for Technical SEO practitioners, but replacing content in order to manipulate rankings can be perilous. According to Taylor, “With service workers, you’re modifying the DOM response. Google renders the changes within the HTML it sees.”

Therefore it is important to proceed cautiously and retain control. Edge SEO is an incredibly powerful approach when you can’t implement Technical SEO that should otherwise be repaired at the core.