How To Optimize Single Page Applications For SEO
Many websites today are built using a single-page applications architecture. While this enables more powerful apps, it can also cause issues for SEO and performance.
In this article we explain how single-page apps work, why they can make search engine optimization harder, and what you can do to fix issues with them.
What are single-page applications (SPAs)?
Websites that are built as single-page applications can display new page content without loading a new HTML document from the website server. In contrast, traditionally clicking a link on a web page triggered a new page to load from scratch (though some resources may have been cached by the browser).
Single-page applications modify the document displayed by the browser instead of loading a new HTML document.
Single-page application vs multi-page application
The term multi-page application refers to the traditional way to build websites. Instead of using JavaScript to update page content, multi-page apps send visitors to a new document that the browser loads from the server.
While SPAs don't need to load a new document, they often still need to load new data to display the next page and then spend additional CPU processing time to update page contents.
SEO challenges for single-page apps
HTML is the basic language for documents on the internet. JavaScript code is an add-on that not all crawlers and search engines support.
If the Open Graph data that social media websites use to display page previews isn't part of the initial HTML document, many social media sites will fail to display it.
Single-page apps are also more resource-intensive to crawl, potentially causing problems with crawl budget.
You need to make sure the page URL updates for major UI transitions. Otherwise the new content can't be indexed by search engines.
Finally, single page applications tend to have worse web performance compared to server-rendered websites.
Single-page apps are less SEO-friendly by default and can have issues with indexability, crawl budget and performance.
Does Google run JavaScript when crawling pages?
Yes, Google's crawler loads websites using a headless Chromium instance that can run JavaScript on your page.
That means Google can index client-side rendered content on your website.
How to check if your website relies on JavaScript for rendering
You can use the free NoScript test to see if JavaScript not being available means that your website can't load correctly.
Here's an example of a website that renders correctly even when JavaScript is disabled.
Serve fully loaded page content with server-side rendering
A big factor that determines the SEO-friendliness of a single-page app is whether it uses server-side rendering.
Some SPAs serve the same initial document HTML and then client-side rendering logic runs in the browser to display the necessary content. This is not good for SEO and performance.
Instead, SPAs often use server-side rendering in addition to client-side rendering:
- The server renders the app and sends the generated HTML to the browser
- The browser displays the page contents
- The browser runs client-side JavaScript and hydrates the application
Check out our frame-work specific guides on server-side rendering with Vue/Nuxt and on optimizing Next.js performance.
Use the History API for page transitions
Each page on your website needs its own URL so that crawlers can find and index them. Displaying content dynamically without changing the page URL, or using URL fragments like many older single-page apps, can cause SEO issues.
Instead you can use the pushState function of the Browser History API. This lets you update the page URL in the browser without actually loading a new document.
Single page applications and Core Web Vitals
Google's Core Web Vitals metrics assess the user experience on your website and are a Google search ranking factor.
Each of the three metrics can be impacted by single-page applications.
How does Google measure web vitals in single-page applications?
When a website opens a single-page app they likely visit many separate pages. However, from Google's point of view, they only visit one page!
That means the data in Google's Chrome User Experience Report (CrUX) attributes all data to the original page URL, even when the URL was different when the performance data was recorded.
Largest Contentful Paint
Largest Contentful Paint measures how fast the website loads.
If your website isn't rendered on the server then this will slow down the page load. Before starting to render content, the browser first needs to download and execute a bunch of JavaScript code.
Sometimes server-sided rendered content can also be re-rendered during the hydration process. If the content is then displayed at a larger size, this can push up LCP scores.
Cumulative Layout Shift
Cumulative Layout Shift measures whether the content is stable after rendering or if it moves around on the page.
CLS can happen at any point while the page is open, so single-page apps are at a disadvantage as they remain open for longer. SPAs also are more likely to display content gradually, resulting in some content shifting when other content appears.
Interaction to Next Paint
Interaction to Next Paint measures how quickly the website responds to user interactions.
While interactions for multi-page applications tend to be handled over the network with a new document, SPA interactions are more CPU-heavy. CPU processing counts as delay time for INP, while network delays (where the browser main thread isn't blocked) don't increase INP scores.
Analytics for single-page applications
Tracking page views and performance data can be more tricky for single-page applications, as the analytics snippet needs to be notified of the page navigation.
DebugBear real user performance monitoring can measure Core Web Vitals using the same single-page approach as CrUX data.
However, when looking at individual page views you can see when soft navigations happened during the page load.
This helps you debug performance issues on your website and shows you both how the data is attributed in the Google data and where the user experience issues actually happened.
Alternatively, you can view CLS and INP score by the URL where the issue actually occurred rather than the page view it was reported for.
Once you've identified an issue you can:
- See what page elements were responsible for LCP, CLS, and INP
- Check if referrer or campaign data gives clues on what causes poor performance
- Review individual page view data to investigate page speed in depth
Conclusion
Single-page applications are not as SEO-optimized by default as traditional websites. However, you can fix these issues and optimize your website for the best user experience.
Server-side rendering for SPAs fixes most of the SEO issues you're likely to encounter. On top of that, using a web performance monitoring tool can help you identify and fix page speed issues on your website.
Monitor Page Speed & Core Web Vitals
DebugBear monitoring includes:
- In-depth Page Speed Reports
- Automated Recommendations
- Real User Analytics Data