Jan 08, 2019
By: Alexandra Barcelona
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.
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.
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.
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:
However, SSR does have its downsides:
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:
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 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.
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.
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.
SPAs aren’t the best fit in every situation, but when it comes to developing lightning fast user experiences within a single page, or building Progressive Web Apps (PWAs), or creating offline experiences, using a single page application is a no brainer.Download
Enterprise SEO is the practice of optimizing a large website, which consists of thousands or even millions of web pages while navigating through the internal politics of an organization to make sure a...
The new dotCMS Lightweight Endpoints feature will allow front-end developers and webmasters to create their own custom REST endpoints using only lightweight Velocity code.
Here’s everything you need to know about Single Page Applications (SPAs).