The rise in mobile device applications and mobile web usage in general has greatly influenced internet user expectations as to how they want their content delivered. When you’re navigating around in your favorite iPhone or Android app, the displays usually transition smoothly. You rarely get a feeling that a given page is being “loaded” on your device. As a result, an increasing amount of web content is trying to follow suit.
A popular way for a website to emulate a device application is to load content by way of asynchronous AJAX calls, i.e., javascript injecting new content from a server into a page without the entire page needing to be reloaded in the browser.
What are the benefits of SPAs?
In addition to smoother loading, SPA sites have many more benefits (and differences) to consider when comparing to MPA sites (multi-page applications): mobile adaptability, caching, and more. See this new post on the differences between SPA and MPA sites for a more complete breakdown.
Examples of Single Page Applications
A classic example of this is posting a comment on Facebook, where your comment pops up after you submit it, but without the page being reloaded from scratch. Over the past few years this trend has been taken even further, with a notable number of websites now running as Single Page Applications, or SPAs.
Other examples include sites you probably use on a daily basis:
- Google Maps
- Wix
- Gmail
- Github
- Google Drive
In single page application websites, there is only the initial page load when you arrive at the website. From there, all the different pages within the site are loaded by javascript, commonly with React or Vue.
Looking at a few of these SPA sites or SPA pages confirms that many of these sites strive to emulate the smooth user experience of a good Android or IOS application. This is visible in the way different web pages seem to glide into view, without the laborious process of a page loading that comes with MPAs (multi-page applications).
So why aren’t more of these single page application websites being built? As a developer, I have been in the room when beautiful, single page application demo sites have been vetoed by project and account managers.
The reason why? Issues with SPA SEO – that is, “single page application SEO.”
How Twitter attempted to solve its own SPA SEO problem
Twitter, which has relied heavily on AJAX technology, came up with the idea of javascript loaded URLs to have a ‘#!’ URL segment to make the URL unique to correspond to a given tweeted comment. This became known as the “hash bang” tag and it was far from a perfect solution. Using ‘#!’ in a URL was not in accordance with World Wide Web Consortium (W3C) standards, as it didn’t truly mark the path to a real resource location.
The ‘#!’ also made things difficult for developers since they had to work with these unusual characters in backend development scenarios. Consequently, the hash bang URL was a flop — despite being initially recommended by Google as a quick fix to the SEO issues with javascript.
Duplication: an alternative to hash bangs for SPA SEO
Another more solid solution was to make sure that if a website was being built as a single page application, a complete duplicate site would be created within the same URL to make sure that Google crawlers – working in the background – would index the site pages properly. Again, this was not a viable long term solution. Creating mirror versions of a given live website gave rise to a maintenance nightmare, as code redundancy is the enemy of the web developer (web developers hate redundancy).
How to make a SPA SEO friendly with HTML pushState SEO
Push State is a feature of HTML 5’s History API. In modern browsers, the main window object now has a child history object that enables a user to programmatically move backwards or forwards in the browser history via window.history.back() or window.history.forward() giving the same behavior as if the user were clicking on a given entry in their browser’s history toolbar menu. But particularly relevant for SEO and SPA applications is one of the history API’s methods: pushState.
The pushState method takes three arguments, a data “state” object, a title string, and a url. When the pushState method is called, the url that is passed to it will appear in the browser’s url window.
An example of HTML pushState
So if you’re on https://www.mydomain.com, and call the below pushState method, the browser window will then show https://www.mydomain.com/new-page.html.
var stateObject={some_data:"some useful value"};
history.pushState(stateObject, "new-page","new-page.html");
This is why when you browse a SPA like Twitter it will still appear like you’re opening new pages in the address bar.
Up until recently, the only way that javascript could programmatically change a browser url was to change the window.location object; but this would always result in the reloading of a browser window. But with pushState, the URL magically updates without the page reloading. A pushState-fired URL change can then be followed by an AJAX call that loads new content onto the page, so we have a new URL with new content to match and get crawled and indexed by Google.
Final Considerations for Single Page SEO Applications
Note that the state object you pass into the pushState function can contain useful data that you can use on the new page. There is a limitation to the amount of data you can use in a pushState state object however, as the serialized version must be under 640k. There is also a wise limitation built into pushState that only allows new URLs that are within the current web domain – to prevent spoofing.
If you’re thinking of building the next big web app and are considering SPAs – that’s great! Just make sure you and your developer team understands how to make your SPA SEO friendly.