What is AJAX?
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.
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 Ember and 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.
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 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.
I think there’s three big things to do.
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 AWS and 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.
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.
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.
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.
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.