What is AJAX?
AJAX is quite an old term, it’s been around since 1999. I think it’s a bit of a backronym really, because AJAX is a Greek mythological hero – geeks like us probably just wanted to sound cool. But, it means Asynchronous JavaScript And XML in our context – basically covering any situation where a page’s content is updated after the HML page has loaded, using data from an end point (a different URL).
It’s mostly used when data changes a lot on a webpage and needs to be updated. The biggest example where people really started to notice it being used, was Gmail by Google. It launched in 2004 and is a widely known example where, when you click on things, they update automatically without the whole page reloading . You could drag and drop emails and the server knows what you’re doing and can update its records accordingly.
Why are JavaScript frameworks becoming trendy?
I think mobile apps are really the big driving force behind it. Customers want to experience websites a lot like how they experience the mobile apps of those brands that they use a lot. And I think users get frustrated with clicking on something and waiting for a whole new page to load. JavaScript frameworks are designed to fix that issue by only loading certain elements of content within the page, which the user is interested in. So it’s a way of standardising dynamic websites.
It means that everyone uses the same code base to build their dynamic websites, saving a lot of development time. It also makes it easier when new people get involved in developing a website. The fact that they know the JavaScript framework already. It allows for new technology to be built on top of it, such as creating mobile apps, even using the JavaScript frameworks.
It’s also led by a trend called single page apps or SPAs, which load the JavaScript framework and HTML scaffolding at the very beginning and then change the content of that page without really updating the URLs too much. It gives a mobile app feel.
What are the most popular JavaScript frameworks?
I think the two biggest frameworks are React and Angular – they’re kind of fighting against each other in a way, because React is maintained by Facebook and Angular is maintained by Google. Two big powerhouses of the internet.
There are some smaller frameworks as well. Things like Emberand Vue. Vue is actually quite popular within the PHP community, so you tend to see it more on Magento websites and ecommerce websites that use a PHP based ecommerce store.
Are JavaScript frameworks SEO friendly?
Well, none of them are really 100% SEO friendly, unfortunately. Search engines save time and money by basically requesting just the HTML of a website. That’s where the content usually is. And by creating these JavaScript driven websites, you’re often removing the content from the initial HTML, loading that content in dynamically afterwards.
Now Google’s adapted to support these kinds of websites by loading websites using Google Chrome. So they basically try and load a web page just like someone would in a browser, but this doesn’t happen straight away. Google actually takes the static version of the web page first and then renders it later on, if it’s got time to do so. It prioritises the bigger and the faster websites when doing this. So there’s no guarantees that Google will see your dynamic content underneath.
And Google also has quite low timeout settings. If your JavaScript requests are slow, the content can take a lot of time to get loaded into the browser. Then Google might not see it at all.
And of course, Google only has a huge market share in certain countries, mostly the English speaking countries. There’s lots of other countries where Google isn’t king and most other search engines really haven’t perfected the whole technique of loading web pages like they’re in a browser. So if you have a look at websites which are dynamic in a search engine such as Bing or Yandex or Baidu or DuckDuckGo, then you’ll see a very different set of content compared to what Google sees, just because they’re not able to handle those dynamic websites as well.
How can I make a JavaScript driven website more SEO friendly?
I think there’s three big things to do.
The first is to make sure that all of your metadata for SEO and all the text-based content is loaded in the HTML. So when someone first requests a webpage, it isn’t loaded in dynamically using the JavaScript. This means that all search engines are able to see the important information, that you need to rank for SEO.
The second thing is to make sure is that the dynamic content gets loaded very quickly. Ideally using something like a CDN, which is a (Content Distribution Network). Some, such as AWSand StackPath, even work with dynamic content requests. Or just make sure that no matter where someone is in the world, that information gets loaded very quickly and that the search engines don’t timeout before they can actually load and render that content.
The third, and probably most important point, is to use a “Prerendering” or “Dynamic Rendering” technology, to (almost) guarantee that the search engines can read your website.
What is Prerendering?
It’s software (or a service / SaaS) that renders your pages using a virtual web browser and then serves that rendered version to search engines. So when a search engine visits your page, they actually see a static web page, rather than the dynamic page.
There are services out there such as Prerender.io and SEO4AJAX, which are Software as a Service solutions. You basically allow them to handle the whole process of rendering the page for you, then serving that to the search engines.
And Google is actually offering their own free solutions as well, which you can install on your own servers. There’s something called Puppeteer and Rendertron, which are two services you can install yourself. You don’t have to use any third party service then. It basically detects if a search engine is visiting the page and if it is, it serves the static HTML rendered version of that page.
So prerendering basically caches the HTML that appears after all of the JavaScript has loaded and turns single page apps into static websites for search engines. It saves them a lot of work in having to render that content themselves. And it can also cope with any slow loading JavaScript that you might have. So if you do have content which takes a while to load, your prerendering service can load that slowly in the background and then send the fast static copy to the search engines.
There are some cases where prerendering services render the page “live” though, which can result in very slow pages. This is because you have to wait for the prerendering service to load your slow page and then after it’s loaded, send the HTML to the search engines. You also have situations where a website visit triggers the rendering of a page as well, which can also result in a very slow experience.
You basically need to cache pages wherever possible, to make sure that website crawlers and visitors don’t have to render that code and information themselves or wait for it all to be loaded.
So JavaScript frameworks shouldn’t be used for Ecommerce websites?
I’d say that JavaScript frameworks and single page apps are developing faster than search engines can cope with. It’s probably the future, but you want the traffic and the SEO revenue now, you don’t want it later on, once search engines have created a solution which allows them to index this content a lot easier.
I tell my ecommerce clients to avoid using JavaScript heavy frameworks wherever possible. Although it’s not always possible because sometimes the decision is made higher up and before the marketing team gets involved. So sometimes you just have to go ahead with it.
So I’d say, save the fancy JavaScript and the web apps that hide content, for things which are behind a login screen. These frameworks were developed for creating data visualisation dashboards and control panels. They’re not really designed for loading your PLPs (Product Listing Pages) and PDPs (product detail pages).
When websites are transitioning to JavaScript frontends, they often see a traffic drop from SEO, unless their previous website was a lot, lot worse for SEO. And websites using JavaScript frameworks tend to be slow on the first visit. They can cause URL issues, especially if the URL format is changing. Also the URL, or the service which is serving the content in the background – if that goes down, your webpage just becomes a blank page and doesn’t serve anything at all.
Would you ever recommend a JavaScript framework?
I certainly would recommend it if you’re building something like Twitter. But then there’s different ways to actually handle it, so that search engines can see that information at first. Then give the dynamic features later on to the user. I don’t think there’s a case in ecommerce where you can really justify going fully AJAX and not loading a static HTML page to the user on the first visit.
Does an AJAX website have any hope in ranking well in Google?
It’s definitely possible. I would say that if you’re in a competitive industry, it gets a lot harder because not only do you have the off-page issue of making sure you’ve got better and more links than your competitors, you’ve also got the on-page issues. What if Google decides one day not to render your very important landing page and as a result, you have no on-page SEO ranking factors at all and therefore dropout of the rankings for those keywords.
And it takes a lot of resource internally to develop a solution that’s perfect for SEO. In terms of rendering the page and testing it, plus optimising the page speed.
I’d say to try and take Twitter’s lead though, if you find yourself in this situation. They’re going through a process, which is called isomorphic rendering, which is basically where you load all of the HTML and page content when a person first visits the page. Then, if they have JavaScript enabled functionality, they can click on things and it changes the content dynamically. Whereas search engines will create a new session on every request. So they always get the static version. So that’s one approach which you can take.
In Summary
First of all, avoid using AJAX if you can. There’s a reason why they don’t use it by default on the major ecommerce platforms, outside of the basket and checkout. You usually end up having to put a new frontend or a theme on top of the platform, in order to get this kind of functionality. I don’t think it’s really appropriate for ecommerce sites at this time – not for product, category or information pages.
If you are having to go down this approach, then make sure that you serve a fully rendered static HML page. At least to search engines, but potentially to all visitors, so that they can actually see the content and links without JavaScript. So have a look at the rendering solutions that we mentioned earlier.
And the third tip is to always cache, when you are using prerendering technology. Plus, make sure that your server is the one which refreshes the cache – don’t make real page visitors refresh the cache. You don’t want your visitors to be the guinea pigs that create that cache. You want it ready to go, instantly available and served just as quickly as a static HTML page.
Please Note: The content above is a semi-automated transcription of the podcast episode. We recommend listening (and subscribing) to the podcast, in case any of the content above in unclear.
