Websites have been around for decades and have always used internal links using HTML to navigate to different pages of the site. On most websites, there is a lot of repeating content across pages. Each time a user clicks an internal link within the site’s navigation, the entire page will load again. Even if the header, footer, navigation and general template are the same as the previous page, the website will load it again. In some instances, thousands of lines of code and images are reloaded just to change a small amount of copy in the middle of the page.
Thanks to their speed and superior UX, SPAs are becoming increasingly popular with online applications such as Gmail, Trello and Facebook utilizing the technology. More recently, many business and personal websites have joined the SPA ranks, with Moneypenny, Whitelabel PR and the beautifully named Mama Joyce Peppa Sauce using JS frameworks to provide a better UX.
What about SPAs?
Single Page Applications or “SPAs” tend to be more efficient than a standard HTML website. When a user interacts with a SPA, only the content that is needed is pulled into the page.
Google calls the template that a SPA uses – “The Application Shell Model.” This model is the template of the website and usually includes the header, footer and navigation. The template remains static once loaded, and only the page’s unique content is loaded upon navigation. So if the homepage has the same header, footer and navigation as the “about us” page, then only the copy and imagery unique to the “about-us” page will need to be loaded.
The result of all this JS and shell model technology is a seamless UX. This speed is important, as if a page takes longer than a couple of seconds to load, a significant number of users will leave a given website.
SPAs & SEO
Out of the box – SPAs do not perform well on search engines. A number of modifications and best practices need to be adhered to for Google to understand and rank a SPA website in a way that’s on par with standard HTML & CSS websites.
SEO problems include:
– URL in the browser address bar doesn’t change
– JS Links – Googlebot can’t follow internal links
– Untracked pageviews etc. in Google Analytics
– General tracking parameter problems
– Soft 404s – as apps are handled client-side
– Heavy code on the first load
– No Opengraph tags for social sharing
– Crawler traps – infinite loops of internal links can occur for Googlebot
– Duplicate content – if content is rendered using JS
– Inconsistent URLs
– No XML sitemaps by default
Thankfully, as SPAs are becoming more popular, Google and other search engines provide solutions to help SPAs perform well on the search engine results pages.
The History API can be used, for example, to change the URL in the user’s browser. This change is essential for UX, but it also means that Googlebot can read and understand that the website consists of more than just one page.
Tracking can also be fixed relatively easily. To begin with, the developer and the people who work in analytics will need to determine if each click is a pageview or an interaction. You can find more information on tracking in Google Analytics here on Google’s official documentation for developers.
Tracking with Google Tag Manager is slightly different. There are a few ways to enable tracking, including using the GA4 Enhanced Measurement found in Tag Manager and the History Change trigger. For more information on tracking in Tag Manager, please see this excellent YouTube tutorial.
As pages and interactions are handled at the client-side level, and a 404 is a server-side HTML status code, by default, a SPA won’t return a 404 status code when the page is not rendering correctly. A SPA, by default, returns a “200 status code,” telling Google that everything is good and loaded correctly, when instead of a “404 status code” should be generated, telling Google that the page has not been found.
A solution is to configure the server to redirect any pages that are not found to a URL containing “not-found” in it. The server can then also be configured so that whenever a user or a bot lands on the “not-found” URL, a 404 status code is generated.
When using JS and creating apps, there are lots of different ways of creating links. However, Google can only read HTML markup in relation to links. It is essential, therefore that developers are aware that the links must use the standard HTML markup for links:
<a href=”URL”>link text</a>
Heavy First Load
While SPAs are incredibly fast in terms of subsequent pages loads and navigation, the entry page that the user comes to your website via can be relatively slow.
Be sure to monitor the page load speed using Google Lighthouse and ideally a Real User Monitoring tool such as Dynatrace.
To improve the speed, there are several solutions which include:
– Lazy rendering of below the fold content
– Lazy data fetching
– Use a Content Delivery Network (CDN)
Mix & Match
A website can be split up so that some of it runs as a SPA, and the rest functions as a traditional HTML-based website.
For example, some takeaway and restaurant websites use traditional HTML & CSS for the main website and SPA technology for the menus.
If the website contains pages that don’t require a lot of data and memory to be downloaded from the server, then a SPA, at this time, might not be worth the investment in terms of time and effort. However, if the same website contains interactive pages that users will want to load seamlessly – such as a menu, then a SPA, alongside an HTML & CSS website may be a great combination.
If you are responsible for developing or optimizing a SPA for SEO, then a list is always helpful:
– Use consistent, readable URLs
– Use consistent trailing slashes
– Use consistent case (usually lowercase is best)
– Use canonical tags correctly
– Avoid parameters in URLs that you want to be indexed
– Add Opengraph HTML
– Ensure unique meta titles & descriptions are used
– Test SPAs with a crawling tool to identify redirect loops
– Test SPAs with a crawling tool with JS turn on, then JS off
– Use canonical URLs and tags correctly
– Ensure tracking is set up correctly
– Use XML sitemaps and submit to Search Console
– XML sitemap, Internal Links & Canonical URLs should match
– Test SPAs with Mobile-Friendly Tool by Google
– Test SPAs with Structured Data Tool
– Use the History API so user and Google can find URLs
– Use Lazy below the fold rendering and a CDN to speed up the initial page load speed