That’s the reason for this post. On this page, you’ll learn how to optimize a particular type of JS content — single-page applications (SPAs) — for SEO. I’ll also share with you some of the best practices for doing so.
But let’s begin by understanding what a single-page application is, and how this technology affects SEO.
What is a Single-Page Application?
As its name might suggest, a single-page application is a JS-based application that loads all of its content from a single page.
Unlike a traditional website, a single-page app does not store individual pages as separate HTML files. Instead, it uses a single page as a template to render relevant content using AJAX calls.
The easiest way to imagine an SPA is as a big and empty placeholder populated with user requests when interacting with a website.
What’s important to understand about it from the search engine optimization point of view is that the placeholder gets loaded only once. It’s the content within it that changes, depending on the information a user requests.
Single-Page Apps Versus Websites
This is opposite to the way traditional websites work. Whenever a user clicks a button on a typical website, a new page gets loaded in the browser’s window. This results in at least some waiting time for the page to load.
With SPAs, the placeholder gets loaded only once. It remains open in the browser, and only its contents change when a user clicks on a navigation button.
Gmail is a well-known example of a single-page app. Notice how, whenever you interact with your inbox, the sidebar and the header remain untouched throughout the process.
Twitter is another popular SPA. So are Instagram and Jira.
Many SaaS companies have adopted SPAs to create dashboards and build form-intensive applications.
As a result, using SPAs offers incredible benefits:
- Since pages do not have to reload with every user’s request, the content loads faster.
- SPAs do not send any extra queries to the server, which frees server resources in the process.
- SPAs simplify web development, since a web dev team needs to develop and maintain only a single page (the container).
- The above also result in fewer technical SEO and code errors.
- SPAs offer much simpler mobile adaptability as well and faster caching.
Unfortunately, single-page apps also present some challenges for SEOs.
Challenges With Optimizing Single-Page Applications for SEO
I admit that the technology behind SPAs is amazing. Unfortunately, it’s also challenging for SEO.
For one, the SPA contains only the basic page structure in its code. All the content and individual page elements are called out through a dynamic API call. This means that all the content loads on the client-side in the browser, but is only to shown to the individual users who request it.
Enter, Googlebot. For Google to rank your content, the search engine must first discover a page, render it, crawl and understand its content, and finally, index it.
But since SPAs contain no content a Googlebot can easily access, the crawler only sees an empty container.
Let me illustrate that with an example. Here’s a SPA page, as any user would see it:
From the search engine’s point of view, all the content that you see above isn’t there. Here’s what Googlebot would see when accessing the page:
So, what can you do to avoid it?
Well, luckily, you have three different options.
Three Ways to Optimize a Single-Page Application for SEO
#1. Pre-Rendering the Content
When pre-rendering the content, you run the single-page app with a headless browser. You then take a snapshot of the page and substitute HTML files with that snapshot in the server’s response. The Google Mobile Friendly Testing tool is a headless browser to test how your app is rendered in HTML.
With this method, the pre-rendering takes place in pre-development and not on a live server.
The result is a static page that can be accessed, crawled, and indexed by Googlebot.
Unfortunately, the method has its drawbacks.
First of all, because you create a static snapshot of the page, the method isn’t ideal for content with changing data.
It does not work well for user-specific content such as pages displaying user’s details for similar reasons.
Finally, because of how pre-rendering the content works, the method also requires enormous resources on large websites.
#2. Dynamically-Rendering the Content
Dynamic rendering creates a separate, flat, HTML-based version of the single-page application used to crawl and render by Google.
In this method, the version of the site rendered depends on the detected user-agent accessing the content. If the detected agent is a bot, the server will deliver static, flat, HTML content. However, if the detected agent is a human, the browser will display the single-page application.
However, a major drawback to the method is that Google can deprecate its support for dynamic rendering, leaving the site without a working indexable version.
#3. Server-Side Rendering
The final method is by far the most popular as well.
With server-side rendering, a page is rendered by the web server as part of the server request/response cycle. When server-side rendering, the SPA is rendered against a virtual DOM. In turn, that gets converted to an HTML string, which gets included in the page before it’s displayed for the user.
This method has its drawbacks, too.
Best Practices for Optimizing SPAs
Let me close off by sharing some best practices that will help you optimize your single-page applications for SEO.
#1. Load the Content Immediately
As you’ve seen above, the challenge with SPAs is that only the framework (or the container) gets loaded into the browser. Users can do whatever they need with it — find information, access information, and so on.
However, Google can’t. As I’ve shown you on the screenshots above, the framework remains empty to the search engine.
Loading the content immediately through either of the three rendering methods I’ve explained above gives the search engine something to crawl and index when it accesses the page.
#2. Break Long SPAs with Distinct URLs
SPAs often feature long-running sections of content. Many of those pages can be easily broken into separate pages that Google could index individually, increasing the site’s search visibility.
Using distinct URLs on those sections will result in users still experiencing the same user experience — scrolling through a long page. On the other hand, the search engine will see those URLs as separate entities and index them accordingly.
This step involves leveraging the History API to create the distinct URLs.
#3. Output Links as <a>, Not JS onclick
#4. Always Include the Navigation in the Source Code
When creating an SPA, you may be tempted to include the navigation outside of the framework. However, that would result in those links being called out through the AJAX call, rather than rendered in HTML right away.
The benefit of navigation in the framework’s source code is that the search engine will immediately access it, regardless of the method you choose to render the actual page’s content.
When it comes to SPAs, specifically, there are three main methods to ensure that this content can get rendered, crawled, and indexed by the search engine:
- Pre-rendering the content that displays a snapshot of the content for Google to crawl and index.
- Dynamic rendering detects a user-agent and displays either a SPA or a static HTML, depending on who is accessing the site.
- Server-side rendering that pre-renders the content as part of the server’s request and response cycle.