Single Page Application Websites & SEO – Is there a Trade Off?
Single Page Applications (SPAs) have been around for years and are used to create platforms and websites such as Facebook, Gmail and Netflix. More recently, however, SPAs are being used to build company websites, with the likes of HealthX, Ebow and Moneypenny utilizing the technology to produce fast and fluid sites that provide a superior user experience.
What is a Single Page Application?
As the name suggests, a SPA is an entire web application that functions and resides on a single page. You do not navigate to separate URLs to access different parts of a SPA website, even if the URL in your browser address changes. Instead, SPA websites use “views” rather than pages.
Because SPAs only use one page, the experience is high-speed and fluid. When navigating to different pages or “views” of a SPA, they load instantly, acting like a native application that you would download to your desktop. Rather than loading each new page in a SPA website, navigation shows and hides different elements of the site.
A good way to experience the difference in performance between a SPA and a more traditional multiple-page website is to use them one after another. So, for example, the AngularJS Wikipedia page is a multiple-page website. If you click on any sidebar links or other navigation items, you will see it usually takes a few seconds to load the new URL. In contrast, the website AngularJS.org is a SPA site, and if you visit the tutorial homepage and click on any navigation links, you will see how fast it loads the new “page” or “view.”
SPAs will often use an “application shell” model, whereby the constant features of the website, such as footers and headers are loaded and remain static, while JS populates the different views’ unique content upon navigation.
Speed is crucial when it comes to having a high performing and high-ranking website. Shoppers on eCommerce stores, for example, expect a very fast experience and if a page takes 5 seconds to load, the probability that a user will leave the website increases by around 90%.
With this in mind, you should consider using a SPA website if:
- Speed is crucial to your site’s performance
- When user experience is of primary importance
- When you want to reuse the backend server-side code & API for a mobile app
SPAs can also be easier to debug for developers and the caching process tends to be a lot more efficient. With SPAs you can also more easily separate front and back end development which makes project management of a new build easier.
Single Page Applications & SEO
One of the current downsides or cons of using a SPA website is that it can make on-page SEO more complicated.
A good way to initially test a SPA website or begin an SEO audit on a SPA website is to run it through the Google Mobile-Friendly Test. You can then view if Google is able to render the page properly and visit the JS console messages to check for any errors.
For example, you may find that you have used a feature or API that Google does not support. In the case of requesting geolocation, it is important that there is a backup option or path in the code so that if the location request is denied, for example by Googlebot, there is default content that can be loaded. If there is no default option and the location request is denied, then the user or Googlebot will not see or crawl the website.
Pages & Views
A common issue with the SPA website in regards to SEO and user experience is that by default, the URL shown in the address bar of a browser will remain static, even when navigating to different “views” of a SPA website using the navigation.
If this is not rectified, Googlebot will only index a single page, usually the homepage. This is relatively easy to rectify, however, using the history API and proper HTML “ahref” link markup.
The “views” on a SPA website can also create duplicate meta tags such as meta descriptions and titles for each page that is indexed by Google, the backend developer will have to add some additional JS to ensure that individual meta titles and descriptions can be added to each view or page.
Error handling is also set up differently with SPAs compared to multiple page websites. With a SPA the server does not do the error handling anymore and can return incorrect HTTP status codes which in turn can cause problems with SEO.
Additional JS can be used to read the URL and fetch the relevant data. If the fetch fails, it will display an error message. The server can then be configured to return a certain status code when a specific URL is shown. So you can configure the server to display a URL ending with “not-found/” if a 404 error occurs. For more information on the code to use and how to set this up, please see this YouTube video tutorial from Google Search Central.
Single-page applications are becoming more popular, as user experience is becoming more important in terms of search and conversion rate optimization. Although additional expertise is often required in order to optimize a SPA for search, individual URLs can be tested with the URL inspection tool in Search Console and the Mobile-Friendly Test without any high level of skill. All the normal technical SEO best practices should be adhered to with SPA websites, including the use of a robots.txt file and an XML sitemap. It’s also important to use canonical URLs correctly and internal linking markup must be correct. Finally, campaign and URL tracking can be more complicated with SPA websites. For information on how to set up tracking on SPA websites please see this YouTube tutorial.
(Devdiscourse’s journalists were not involved in the production of this article. The facts and opinions appearing in the article do not reflect the views of Devdiscourse and Devdiscourse does not claim any responsibility for the same.)
Credit: Source link