Introduction

Single-page applications are the easiest and the most effective way to build web applications in recent years. As the trend of javascript has progressed SPAs also found their recognition and have been adopted by most of the web developers around the world. Whilst they are easy, quick to create and scalable there are few challenges that cannot be solved by single-page applications. The most important issue being the SEO of the application.

Depending on the type of the project it becomes important to focus on the SEO of that application.

Ex: If you build a web application which is a dashboard to manage your todo list i.e example monday.com. Then building a single page application using Angular, React or Vue is probably the most effective and efficient way to do it. But if you are building a marketplace like an eCommerce store where SEO increases your sales by attracting organic traffic, then SEO plays a very important role in your product. Hence SPAs might not be the best way to address this issue.

Performing SEO for a SPA through prerendering technique

Before writing this blog I have tried this solution myself i.e. trying to apply the technique of prerendering for the SPA. Applying prerendering is one of the best ways to solve the SEO issue of a SPA. If you want to learn how I did it, you can read my blog here.

But unfortunately, after using this technique for over 8 months I have realised the following disadvantages.

1. The prerender.io service gets expensive at scale.
2. Creating your own prerender service is an expensive way of solving it with respect to both time and money.
3. It is not a long term solution due to its maintenance.

While we configure a prerender middleware it is important to list the name of the bots in the web server configuration file to allow the bots to crawl the website. Finding and updating the list of bots is very challenging, but at the same time allowing all bots is also not a viable solution. So I had to consider migrating away from a prerender solution to a server-side rendering option.

Performing SEO by migrating into SSR application

As the prerendering was complex and not efficient, I considered migrating the Vue single page application into a Nuxt server-side rendered application, and it was not too complex.

The migration hardly took a 3 to 4 days. The main changes were only made in the folder structure and most of the code remained the same. There were some libraries that had to be updated as they were only compatible with vue and not nuxt.

Once they were migrated the SEO took off to a great start and solved the problem for me. But SSR needs more resources on the server, but it is cheaper than buying a prerender middleware service or making your own at scale. Both these techniques only work for really small projects or websites.

Here is the step by step migration of my vue project into a nuxt SSR project.

The package.json migration

The below file shows the package.json with scripts section in vue which is further changed to nuxt in the one below it respectively.

The folder structure migration

The folder structure change was slightly different in vue. The main workable folders were all placed inside the src folder, then the main pages were all placed inside a folder called views, as vue comes with a default naming of views. But in a nuxt project all the workable folders are at the first hierarchy and then views are termed as pages.

The vue config vs nuxt config

The vue config looks as follows.

The nuxt config looks as follows.

The nuxt config has additional parameters and the routes can be configured in the nuxt config. Nuxt mostly uses vue plugins but some of them are specifically made for nuxt. Additionally a sitemap is generated automatically in the nuxt project depending on the routes, while in vue thy might have to be done manually by writing an additional config. For more sitemap generation techniques in vue check here.