SEO for Single Page Applications- Things to consider

Single page applications or SPAs have been around for a while, but it is only now that they are gaining widespread popularity. As its name suggests, a single page application is a web application that loads a single HTML page, and all the changes to that page are dynamically updated as the user interacts with it. In other words, a user is accessing a page that updates and rewrites itself without reloading or loading new pages from a server. The most obvious benefit from this is the seamless quality of user experience. SPA looks a lot like a desktop application.

You may not know this, but you use single page applications every day! Facebook, Twitter, Instagram, Gmail, Google Maps and GitHub are famous examples of single page applications.

So how does SEO for single page applications work? To build such uninterrupted user experiences, SPAs typically use AJAX and HTML5. In a single page application development, a page ‘shell’ is given to the browser. This ‘shell’ doesn’t have any content. We use AJAX to load the content from the server, on demand, and JavaScript adds it to the page. When it comes to single page application development, ASP.NET may not be the right choice, but developers can use many open source JavaScript frameworks that are at their disposal.

SEO and Single Page Applications

One of the challenges for a SPA developer is to handle single page applications and SEO (search engine optimization.) When it comes to regular pages and websites, Googlebot and other search engine crawlers’ index web pages and they download the HTML file of the page. This is called ‘crawling,’ and search engines find it easier to rank or index HTML pages because they are static. SPAs are developed on JavaScript frameworks and apart from Google, not all search engine are as friendly to JavaScript. Also, search engine bots rank pages and not entire websites, and as we know, SPAs don’t have individual pages.

So how can a SPA developer make the SPA SEO-friendly? The developer should find out if the SPA’s content can be indexed and ranked by a search engine. Search engine crawlers can run JavaScript and wait for AJAX calls to complete before the process of ‘crawling’ begins.

In 2014, Googlebot announced that it had started to ‘render and understand your web pages like modern browsers’ as long as the developer was not blocking Googlebot from crawling the site’s CSS or JS files.

The problem occurs when internal links crop up because these are not part of the HTML source code and the crawler may not access them all. This puts some extra load on the indexer, which can negatively impact the speed but bots like Google’s are designed to handle this problem, specifically with Google’s Fetch as Google Tool. The developer can also use an XML sitemap to help the crawlers to access more site content.

Server-Side Rendering

Server-Side Rendering (SSA) is when a SPA is rendered as part of the server response cycle. A fully rendered page is then sent to the client, whose JavaScript bundle takes over and the SPA continues to work normally. SSR is a popular technique, but it can come with its problems. It takes time and work, and with SSR increasing the load on the server, this reduces load and response time. Caching can temporarily solve this problem, but a slower load time does defeat the purpose of a SPA in a sense. Also, for SSA, you need a Node.js production server. A solution to this could be pre-rendering.

SSR is more suitable for occasionally used content and user-specific content.

Pre-rendering

With pre-rendering, you run the SPA on a browser without a graphical user interface (or a headless browser) like Firefox, PhantomJS or Chrome but you don’t run it on a live server. You run your app, take a snapshot of the page output and replace your HTML files with this snapshot as a response to the server request. Unlike SSR, you don’t need a Node.js backend for pre-rendering and your load time is not affected. Pre-rendering does have its share of problems. It does not work well for pages that are constantly changing and should be loaded dynamically at load time.

Other ways to help SEO

There are various other off-page and on-page SEO tools that can be used for single page applications and SEO. SEO-friendly URLs solve the problem significantly, and the developer can also optimize meta descriptions, page titles and more, which can be rendered into the page’s source code. This is a good add-on to SSR or pre-rendering. Isomorphic React can help by detecting automatically if the client side has disabled JavaScript and if it is disabled, then the Isomorphic JS runs on the server-side, which means that the client side gets the content. Another idea is to include multiple H1 tags on the content, so that it is nicely separated and demarcated, making it more readable and search-friendly!

There are other hacks that developers can use. For example, for SPAs, the initial load is critical as it takes the longest time, so it’s a good idea not to have long-running scripts for the initial content. Also, make sure that you configure your backlinks correctly so that deep linking is possible and there are no broken links.

Recently, Google’s John Mueller was asked about SEO for SPAs and how Googlebot handles crawling and indexing of SPAs. Mueller said developers should test continuously with Fetch as Google to see what Google picks explicitly up. However, they should also dive deeper into the code and do some client-side rendering.

With a combination of tools, technologies, intuition, and creativity, a developer can resolve the SEO problem on single page applications. For example, never forget that even with SPAs, content is king.
Every Internet giant, including Netflix, uses SPAs and it is only a matter of time before it catches on as the standard in the industry.