Single Page Applications have become immensely popular over the last three years. A Single Page Application (SPA) is effectively a website that fits on a single webpage. Websites are usually accessed with a web browser. The user would type in the web address to their browser; the browser sends a request to the server that says “send me the homepage of www.thiswebsite.com.” The server then sends the homepage back to the web browser, which renders it so that the user can see and interact with it.
If the user clicks a link or an item on a standard multiple-page website’s navigation bar, another request is sent from the user’s browser to the webserver. Again a page will be sent to the browser and rendered.
Essentially, you always get a new page when you click or request a new page or URL. The page reloads each time.
It is called “single page” because it only has to load once. This method of loading the website once should provide a much quicker and more fluid user experience.
SPAs (Single Page Applications) are great for developers because they support ReSTful APIs, and SPAs are generally much easier to convert to a mobile-friendly website.
SEO Problems & Single Page Applications
While loading new web pages on the same website can dramatically speed up using SPAs, it can also create problems from an SEO’s perspective.
All the content and the page elements are loaded using dynamic API calls, making it tricky to perform an SEO audit on SPAs.
For example, it is common for developers to use code or features that may not work correctly on all web browsers and devices. Also, navigating to new pages may not cause the URL to update as it would on an HTML-based website. This would confuse Googlebot, as it would see everything as a single page, which as an SEO, we don’t want as only one page can be indexed.
There can also be problems creating unique meta titles and descriptions. If not addressed correctly, all web pages (or views) can be assigned to duplicate meta titles and descriptions.
Another common issue with SPAs is how errors and error messages are handled. For example, if an invalid URL is typed into the web browser’s address bar, a soft 404 can be created whereby the server generates a 200 status code, but the user encounters an error message.
Test SPAs with Google’s Tools
Use the mobile-friendly test and search console’s “Fetch as Google” to test your SPA. Using these two tests, you should be able to establish whether or not Google will completely and efficiently index your SPA site.
An excellent place to start testing your SPAs is to use the Google mobile-friendly test. This test is the easiest way to ensure that all the content is visible. You can use development stage URLs and live URLs – it gives you a screenshot of the above-the-fold content, and the test also provides a rendered HTML – the HTML that will be rendered for indexation by Google.
If the mobile-friendly test picks up all of your HTML, then that’s great – your site has effectively passed the first stage of SEO!
If a SPA works in the mobile-friendly test, it will also work in search.
Rendering & HTML
There is much debate around the best form of rendering for SPAs (Single Page Applications).
With server-side rendering, the HTML is prerendered on the server before it is sent to the client’s browser.
With server-side rendering, the bot crawling your SPA for indexation will receive HTML, which they crawl most efficiently.
This method requires that the server hosting your SPA has Node enabled.
For more information on server-side rendering for SPAs, please see this Medium article by Matthias Kunnen. He opted to use server-side rendering and used headless browsers for testing, along with a Node library – Puppeteer. This library allows you to extract the HTML after a SPA has finished rendering.
SPAs can be built using vanilla JS or frameworks such as Angular, React, or Vue. The best type of rendering can often be specific to the framework. The codelabs documentation from Google is an excellent place to learn more about rendering.
Meta tags such as the meta description, the meta title, and canonical URLs should be rendered directly in the actual code of the page. This direct rendering should be separate or a supplement to the rendering functionality (either pre, dynamic, or server-side rendering).
Navigation and Links
For Googlebot and Bingbot to follow and crawl the entire website, the pages must be linked with HTML, using the <a>href attribute and not the JS onclick functionality.
Views must be treated as URLs. Otherwise, search engines will see the website as one page and only index a single page.
Developers can use the history API and <a>href attribute to ensure URLs are acknowledged as individual pages and crawled as such.
Use and Update Sitemap.xml
In addition to adequately marked up internal links, an XML sitemap should be submitted to Google via Search Console to ensure that they know all of the website’s pages/views.
As previously mentioned, SPAs can have issues handling errors such as 404s. As the server does not do the error handling, a SPA will usually return a 200 status code, stating to Google that everything is okay, even if a page is broken or not found.
Unfortunately, status codes cannot be changed once the server has loaded the homepage or first page on the website. However, a developer can change the default status code for individual views/pages within the app. in the Google Webmasters video, Martin Splitt creating a view that serves a 404 code and a view for 500 errors.
Create SEO Friendly URLs
Ideally, your SPA should output an ID URL and a slug URL. Speaking at dotCMS’s conference in 2018, John Hartley advised that SPAs should push both these URL formats and gave the below examples:
ID URL*: http://localhost:8082/recipes/3fdc86d5-76fe-48c2-9ed9-24dba3c7c78b
Slug URL*: http://localhost:8082/recipe/fiery-chipotle
The ID URL is required so that a router can pull and establish the relevant content types and utilize them in a component. The ID URL contains the unique ID numbers that are associated with each fragment of content.
The slug URL contains words and hyphens, which looks better, is easier to read and share. Each page or view should have a unique slug URL that returns a 200 status code.
Use Canonical URLs
As with every standard website, SPAs must make use of canonical URLs. It is a way to tell search engine bots which URLs need to be indexed and which parameters can be ignored. It is an HTML element that also helps to prevent any issues with duplicate content. According to kruschecompany.com, if you want to use the canonical URL attribute with a SPA website, you have to generate the URLs dynamically. The canonical URL must match the relevant sitemap URL.