Photo by Patrick Perkins on Unsplash
Does that mean SPAs are bad for SEO? No, they aren’t if done right. A lot of SPA pages are ranking high on Google and look good when referred to in socials. Yours can too. Our article and single-page app SEO tips from Pavel, Frontend Developer at Proxify, will help you avoid common missteps and get your project on top of search results.
Let’s start with cold hard facts about SPA SEO
The way SPAs operate enhances user experience however results in several bottlenecks that are critical for your project's SEO performance:
To rank on search, each view of your app should have an individual clean URL despite being rendered on a single HTML page.
Search engine and social media bots should get metadata in the static HTML to index your pages or show previews when the pages get linked to on socials.
Now let’s zoom in on each of those facts to see why they are an issue and how you can make your web app perform fine in terms of SEO.
How Googlebot crawls, renders, and indexes SPAs
SEO pitfalls of client-side rendering
Because of the extra stage needed for rendering, it takes longer for SPA content to appear or update in search compared to static HTML pages. The risk of indexing errors also goes up. You may face the following challenges:
The above concerns have been proved by independent single-page application SEO experiments. The results showed that Googlebot always indexes the content generated immediately after a SPA page loads. They also proved the content that is supposed to render on-demand (as users scroll or take actions on the page) or after a long delay (content coming from external resources or animated text) doesn’t always get indexed because of the limited render budget.
“For SEO it's important to have small JS code for fast initial page load. It concerns both SPAs with client-side rendering and with server-side rendering. The implementation of lazy loading solves the problem of slow web apps very well.” – Pavel, Frontend Developer
2. URLs and internal linking should be SEO-friendly
You might want different views of your app to be indexed as standalone pages and rank in search. For this, you should help Googlebot find all of your URLs and navigate through your app architecture. Beware that crawlers are sensitive to the way you implement routing between different views of your web app.
SPAs rely on routers that keep their UI and content in sync with the changing URLs without refreshing the page. When it comes to SPA routing modes, you have two options: hash-based routing and History API routing. Only the latter is SEO-friendly.
SEO pitfalls of SPA URLs
If your router works in the hash mode, it will add #hash fragments added to your home page URL to generate unique URLs for different pieces of your SPA content. Crawlers always ignore hashed URLs as they indicate parts of the same page. They won’t index different app views as separate pages if you use hash-based routing.
If your router works in history mode (uses History API), crawlers will get a unique normal URL for every separate piece of content. However, all these URLs won’t exist on your app’s server, which may cause 404 errors when a user tries to directly access a non-existent URL.
Having unique URLs is enough for indexing but not for ranking high on search. To make your URLs competitive, you’ll have to provide them with unique titles, descriptions, and preview images. Moreover, if you want them to be picked up not only by Googlebot but also other agents, you’ll need them in static HTML.
“Make sure you create an XML sitemap for your project. It is submitted to Google, Bing and other search engines to help them crawl your website better.” – Pavel, Frontend Developer
3. Meta tags should be unique for each URL
The header of your SPA belongs to the static HTML part of your app. It contains by-default meta tags that don't change when different page content is rendered. However, you want titles and descriptions that clarify to both users and bots what information they’ll find on each of your URLs.
To make your metadata accessible for all bots, you should send it with the initial HTML when your page loads. The way around it is in switching from client-side rendering for your SPA to its alternatives.
Can all the single-page app SEO issues be solved at once?
Both pre-rendering and SSR add complexity to your SPA and require hiring more experienced developers. Those methods also require extending your app tech stack and raising requirements to your servers. Therefore, before you opt for either option, you should decide if the expected benefits are worth the extra development and maintenance cost.
How pre-rendering improves SEO for single-page apps
Pre-rendering is a simpler and lighter solution. It will work well if you have just a handful of marketing pages to optimize. If that's your case, all you need is to pre-render static HTML files for specific routes of your app at build time. This way you'll keep your marketing assets in the form of a static website that’s easy for bots to consume.
How dynamic rendering makes single-page apps SEO friendly
Dynamic rendering builds upon the pre-rendering method and is recommended by Google. This approach allows serving the same content to users and bots differently. Your users will continue to enjoy client-side rendering, while bots will get redirected to a dynamic renderer that serves them pre-rendered HTML.
To set it up, you’ll need your webserver to distinguish between crawlers and users by checking the user agent. You’ll have a list of agents that should get your static HTML, such as Bingbot, Googlebot, Linkedinbot, etc. Your server will redirect requests from the listed crawlers to your dynamic renderer that will send them cached HTML pages.
Switching between client-side rendered and pre-rendered content will allow your app to take the best of both worlds. You’ll deliver as much content to bots as possible without any harm to the user experience.
The limitation of pre-rendering is that it doesn’t work well for large apps with frequent content updates. It may take just too much resource to pre-render and cache each route in your SPA. For such cases, you might want to use server-side rendering instead.
How SSR boosts SEO for single-page applications
Server-side rendering is more difficult to implement. However, if you plan to have an online store or app with countless dynamic pages to be indexed by search engines, choosing SSR will be more than reasonable.
To make the SSR implementation easier you can use out-of-the-box solutions for building isomorphic apps – Nuxt.js for Vue.js framework or Next.js for React.js library. Read more in our posts about how to make Angular, Vue, and React SEO-friendly.
“SSR brings in problems with performance. Because the server will render a particular route of your SPA instead of just sending an HTML page to a user. Your app will require a more powerful infrastructure to handle loads.” – Pavel, Frontend Developer
Quick SPA SEO Q&A
You ask, we answer.
Are single-page applications SEO-friendly?
A lot of SPA pages rank high on Google. Still, single-page apps require their creators some additional effort to make them SEO-friendly. Developers should be experienced and skilled enough to structure and build a SPA with SEO in mind. They should choose an optimal rendering type for the app, use additional tools to treat metadata and URLs correctly, and apply special techniques (caching, lazy loading, etc.) to optimize the app for performance.
What type of HTML rendering is the most SEO-friendly?
When optimizing a SPA for SEO you’ll have to choose between CSR (client-side rendering), SSR (server-side rendering), and pre-rendering. Your choice will depend on the type and size of your app. CSR is the least recommended option. SSR is the most complex but is a go-to for large apps with content that changes often. Pre-rendering is optimal for apps that need a small bunch of static pages to rank on Google.
Why single-page applications are the future?
The quality of user experience becomes more and more important for good ranking. In contrast to static websites, SPAs are built using modern web frameworks that evolve fast. Those technologies provide the interactivity and design you need to meet both users’ expectations and search engines’ technical requirements.