In the latest Google Lightning Talks video, Martin Splitt shares tips for making single page apps discoverable by search engines.
The main difference between a regular, HTML-based, website and a single page app is the latter’s dependence on JavaScript.
JavaScript is used to create the HTML for a single page app which then creates the page.
JavaScript is required to load other content when users are navigating to different parts of a single page app.
When JavaScript loads new content it’s referred to as a “view.”
Relying on JavaScript for single page apps allows browsers to load views without doing a full reload.
JavaScript also allows for design elements such as custom transitions between different parts of the application.
Simply put – JavaScript makes single page apps function the way they do.
The Challenges of Working With Single Page Apps
JavaScript is less than ideal for search engines when it comes to crawling and indexing.
As SEOs well know, even a moderate amount of JavaScript on a page creates a whole new set of challenges.
The challenge level is kicked up a notch when all content is wrapped in a layer of JavaScript.
That’s exactly the case with single page apps.
So what are SEOs to do if they’re tasked with getting a single page app indexed and ranked?
Here’s what Google recommends.
Google’s Advice for Single Page Apps
Splitt offers four main pieces of SEO advice for single page apps:
- Cover all code paths
- Treat views as URLs
- Optimize titles and descriptions for each view
- Improve how the app deals with errors
Here’s a brief recap of each of Splitt’s main points.
Cover All Code Paths
Splitt gives an example of a single page app that appears to be functioning well enough, but Google’s mobile-friendly test cannot render the content.
In the example the problem stems from unsupported code, which is identified by the mobile-friendly test.
More specifically, the code does not take into account what the app should do if certain commands cannot be executed.
In Splitt’s example the single page app is instructed to fetch a user’s location info. But there’s no code path instructing the app on what it should do if the location information is not available.
That’s what Splitt is referring to when he says “cover all code paths.”
The reason why the page could not be loaded in the mobile-friendly test is because Googlebot declines requests for geolocation.
If there was a code path in place to deal with that scenario then the content could be rendered.
Treat Views as URLs
When navigating around a single page app, see if the URL in the address bar changes when clicking between each view.
It should change, because Googlebot uses URLs to locate different “pages” (also knows as “views”) within a single page app.
If there’s only one URL for everything then Googlebot only sees the home page and nothing else.
That leads to issues with rankings because Google cannot understand what the site is about.
Splitt advises the following:
“To fix this we can use the history API and proper link markup with href attributes to expose the views as URLs within the links.”
Titles & Descriptions
There’s nothing more fundamental to SEO than optimizing titles and descriptions of web pages.
However, this SEO fundamental is frequently overlooked when it comes to optimizing “views” for single page apps.
That results in all views having the same title and description – and you’re likely well aware of the problems that can cause.
Each view can, and should, have its own unique title and description. This can be accomplished by adding “a little extra JavaScript,” Splitt says.
Dealing With Errors
Another common problem is the way single page apps are dealing with error scenarios, such as invalid URLs.
Splitt provides an example of a single page app that displays an error message while the server shows an HTTP 200 status code.
Ideally, if there’s an error displaying content, then the server should not return a status code saying everything is OK.
That’s not an option for single page apps, however, as the server doesn’t do the error handling.
A server will always return an HTTP 200 status code for single page apps. It’s up to the JavaScript and browser to either run the code or display an error.
This should be fixed because HTTP status codes help Googlebot and browsers decide how to deal with the error response.
There’s no straightforward fix for this as HTTP status codes cannot be changed after the server loads a single page app.
What you can do is change the default status code for individual views within a single page app.
So Splitt recommends creating a view that serves a 404 code, a view that serves a 500 code, and so forth.
Then the JavaScript can be edited to direct browsers to the appropriate view when an error is encountered in the code.
For more on any of this advice, see the full video below:
