Optimizing a single page for multiple search engine keywords and phrases is no small feat, and that’s why there’s no denying that SEO and Single Page Applications (SPAs) don’t mix particularly well.
But that isn’t deterring the likes of Google, Netflix, and LinkedIn from developing SPAs to meet the needs and expectations of the end consumer—expectations like lightning load speeds and minimal page refreshes. Additional benefits of single page applications, like the fact that they’re relatively easy to build and require significantly fewer ongoing server requests, make them tempting for companies looking to offer cutting-edge digital experiences efficiently.
With that being said, there is a trade-off at play. By betting on single page application architecture for your next project, you will—for now at least—have to sacrifice some of your search engine optimization success.
In this article, we explain why SEO and SPAs don’t mix, what companies can do to search engine optimize an SPA, and what to do if this trade-off seems too costly.
SEO and Single Page Apps: What are the Challenges?
By their very nature, single page applications aren’t search engine friendly. For one, SPAs are developed on JavaScript frameworks such as Angular.js or Vue.js, and it’s common knowledge that most search engines don’t particularly like Javascript.
Search engine crawlers like Googlebot and Bingbot are designed to index web pages through a process known as “spidering” or “crawling”, where they download the page’s HTML file(s). This is why it is easier to index and rank a static HTML-based web page.
Another critical point is that search engines rank pages, not websites. Each individual web page on your website has a chance to rank highly for a keyword or phrase if it ticks all the right boxes. With a single page application, you’re combing your pages into one application, which means you can’t separate content our and rank it as an individual page, like you would with a traditional website.
When it comes to indexing JavaScript-based SPAs, things get a little complicated. Since a high proportion of the internal links are not part of the HTML source code, the crawler may only find a limited number of URLs.
To gain deeper access to the URLs, an extra step is involved that requires some heavy-lifting by the indexer which requires executing the JavaScript to retrieve the links which are then passed back to the crawler. This extra step causes a delay and more work for search engines.
Google is willing to do this extra heavy lifting. In 2014, Google announced that their Googlebot will attempt to render JavaScript before it commences crawling. They also provided webmasters with the Fetch As Google tool to assist with debugging any rendering issues of a JavaScript-modified page.
But before we jump to any conclusions that revolve around Googlebot being able to render all JavaScript flawlessly, there is no guarantee. In fact, Google made this very clear in their 2014 announcement, although it appears many developers have overlooked it.
And another thing that I’d like to point out is that just because a page can be indexed, that doesn’t necessarily mean that it will rank well, and as I mentioned earlier, ranking for specific keywords with a single page application will be far more difficult than ranking for keywords through a range of web pages.
Finally, because every interaction happens on a single page, studying the analytics data for your SPAs will also be a challenge.
What Are The Best SEO Practices for Single Page Applications?
Fortunately, there are a number of best SEO practices that you can implement to help you achieve your desired outcome with your SPA. We’ve outlined these best practices below:
Server-Side Rendering
The process of server-side rendering, or SSR, consists of getting a web page rendered as part of the server request/response cycle. To run SSR on a JavaScript framework, the SPA needs to be executed against a virtual DOM.
The virtual DOM is then converted to an HTML string, which is then injected into the page before it gets sent to the end-user. When the page reaches the end user's browser, the SPA will run the JavaScript and will then seamlessly replace the existing content.
SSR helps to make your page search engine crawler friendly regardless of whether the crawler runs JavaScript.
However, SSR does have its downsides:
The coding you use for your SPA must be universal. In other words, it must work in both the browser and in a server-based JavaScript environment.
Implementing SSR is time-consuming and often complicated. This means you’ll require more development hours and resources.
Your SPA will have to run more requests to the server, leading to additional load time and slower response. Caching can provide a partial relief to this.
SSR only works with a Node.js backend. Although SSR can be achieved with non-Node backends via a PHP extension, however, these solutions have limited availability.
Pre-Rendering
If you’re not able to apply SSR for any of the above-mentioned reasons, there is another option: pre-rendering.
With pre-rendering, you run your SPA on a headless browser, like Chrome, Firefox, or PhantomJS, in your development environment. You then take a snapshot of your page output, and then you substitute the HTML files with this snapshot in the response to the server request.
Pre-rendering is similar to SSR, except the rendering takes place during pre-deployment and not on a live server. This rendering process can also be incorporated into a build flow with Gulp, Webpack, and more.
The main advantage to using pre-rendering is that it does not require a Node.js production server and neither does it add any unwanted load to your production server.
That said, pre-rendering also has its drawbacks:
It is not compatible with pages that display dynamically changing data such as news websites
Pre-rendering is not suitable for pages that contain information specific to a user, for example, a user account page that contains personal details. But these types of pages are less critical for SEO since you wouldn’t want to index these pages anyway.
Each route in the SPA will have to be pre-rendered individually. This could take a large amount of time if the SPA is very large.
SEO Friendly URLs
Speaking at dotCMS' annual conference, Bootcamp ’18, Associate Team Director John Hartley of DYNAMIT advised pushing your SPA to two output lengths, an ID URL and a slug URL. Below is an example of how the two URL types look like (as provided by Hartley at Bootcamp ’18):
ID URL*: http://localhost:8082/recipes/3fdc86d5-76fe-48c2-9ed9-24dba3c7c78b
Slug URL*: http://localhost:8082/recipe/fiery-chipotle
Please Note: Both URLs are sample URLs
The ID URL contains the unique IDs associated with each fragment of content that is going to be presented on the page. The purpose of this URL is to enable your router to pull out the relevant content type(s) and utilize it in your component.
As for the Slug URL, it contains actual words separated by hyphens which makes it easier for your end-user to read and share. For the purposes of SEO, it is critical that your slug URL contains the relevant keywords, and each page should be linked to a unique URL with a 200 OK status.
All slug URLs should be clean, flat and have no fragments (hashtags). Google recently announced that the use of hashtags is no longer recommended. If for any reason you URL does contain a hashtag, there are many ways around this using your router.
Meta Tags
Meta tags such as page title, meta description, canonical tags, and HREFLANG, should be rendered directly into the source code of the page, as a supplement to the server side or pre-rendering functionality.
Internal Links
To enable efficient crawling of web content, all internal links must be embedded with the link <a> tags in the source code as opposed to JavaScript onclick events. Also, we highly recommend that all core navigational elements are directly outputted within the source code.
XML Sitemap
A well-formatted XML Sitemap, which is submitted to the Google Search Console, can enable search engine crawlers to get a deeper level access to website content.
Concerned about SEO? Consider a Multi-page Application or Hybrid Application Instead
While the tips and tricks above will help, opting for a single page application means you’ll almost certainly lose out on some SEO juice along the way. But as large brands are proving, sometimes the customer experience is more important.
However, if SEO is still a concern, there are ways around the issue of SEO and single page applications. Firstly, you could consider building a multi-page application that utilizes static content, which is easier for search engines to crawl (but sacrifices the customer experience). Or, you could build a hybrid application that combines multiple SPAs together.
Alternatively, you can use static pages for your landing pages and SEO campaigns, which in turn link visitors to your single page application.