Angular is becoming an increasingly popular framework being used on websites, including many eCommerce sites that we work with. To ensure your Angular application works in organic search, there are certain precautions you may want to heed to ensure it is crawlable and discoverable.
Angular Benefits for eCommerce
There have been studies to show that page speed can have a significant impact on both bounce rate and conversion rate, with faster websites lowering the former and increasing the latter. Therefore this is a massive advantage when it comes to Angular based eCommerce sites.
Crawling & Angular eCommerce SEO Issues
However, to convert people on your site, they need to reach your site in the first place. For many websites organic traffic via search engines is a fundamental way for them to discover a site. An eCommerce site built from scratch in Angular can have difficulty being discovered by Google – the reasons for which we will describe.
How does a search engine crawler see Angular websites?
Google identifies websites and website content in two phases:
- Crawling the HTML (Source code)
A fantastic guide to this process and the differences can be found here.
Angular by default is client side rendered, which means that Googlebot will not be able to see any content that requires rendering. Since almost all Angular will require rendering, this means that Google may not be able to crawl your site at all, unless utilising server side rendering or some sort of dynamic rendering solution.
If using one of these solutions, Googlebot will see very little of the site on the initial crawl of the HTML; and Angular sites will still have to rely heavily on Google’s rendering engine (Google Caffeine) to identify URLs on the site, as most of the content and page information requires rendering before it can be ready. (which Googlebot does not execute).
SEO issues with Angular
Due to this, there are some issues with Angular that may impact SEO if not properly configured:
- Content can take longer to be discovered
Since rendering requires more resource and is the second step in website discoverability it can take longer to discover new pages or not content on a site.
- Updated content can take longer to get noticed
Similarly, content that has been updated must again be rendered before the changes are noticed. This means that changes and updates you make may not seen for a while after you make them.
- Content deep in the site may not be crawled as frequently (if at all).
Just as Google has a limit to the number of URLs it will crawl in one go (ie the crawl budget), it also has a limit on the number of pages it will render at one time (ie the render budget). Since an Angular site relies solely on Google Caffeine’s rendering stage this can mean that pages deeper in the site (for example older blog posts) are crawled far less frequently, if at all.
This can mean that fantastic, relevant content is not given the weighting it deserves in the SERPs; resulting in lower rankings and less traffic despite well optimised content.
Optimising Angular eCommerce Sites
Ensure every page has its own URL
At a very basic level for SEO, every page must exist on its own URL, which won’t necessarily be the case if running an Angular SPA.
You need to ensure you are using the HistoryAPI to generate URLs for every page on your site, and then optimise these pages.
It’s important to ensure that products have their own URLs, and that these are linked to internally. Even if your site is utilising something like a modal to generate these URLs.
You can use this as a “Quick Buy” option for usability, with the internal link to the specific product URL as a more complete and informative product information page.
As with any page, for SEO purposes, an page in Angular should have a distinct page title and associated meta data (ie description). In Angular this is possible using the Title service.
Server Side Rendering with Angular Universal
Server side rendering ecommerce websites built in Angular is the best solution from an SEO perspective. This allows all content to be easily crawled by search engines since it can be requested directly from the server.
Angular Universal (part of Angular 2) allows the application to execute on the server, which also makes the site crawlable. Server side rendering is therefore included with Angular Universal.
However, developers can be hesitant about implementing server side rendering, since it takes a lot of work to implement and can have less of an “app” feel.
Dynamic rendering involves a service discriminating between search engine crawlers and human users. When it detects a search engine crawler such as Googlebot or Bingbot, it will serve them the fully rendered site HTML (sat on the dynamic rendering service’s server), so content and internal links can be easily crawled and discovered.
However, when it detects a human visitor, it will serve the the single page application straight up, allowing the UX benefits of the Angular site. This can be a useful workaround for websites running Angular 1.0, which doesn’t have the default option of server side rendering using Angular Universal.
Common dynamic rendering services include:
Angular dynamic rendering disadvantages
eCommerce site’s that are highly dynamic may not be suitable for dynamic rendering, since it requires the rendered HTML to be cached on the dynamic rendering service’s server. Therefore, this server will only store one version of the site’s content.
If this is the only version being served to search engines, this may mean that search engines do not fully understand the capabilities of the site.
Pages returning mixed status responses
A problem that has recurred with a couple of our clients using Angular is that a URL may return a different status code if navigated to directly, vs if navigated to via another page on the site.
This can cause problems for SEO as you may be returning mixed signals to crawlers (and visitors) depending on how they access the site.
The Angular application must be correctly configured to handle this, as is described in the following section of the Angular guide:
This can be problematic as this is the response search engines crawlers will receive when they crawl the site. It can therefore give confusing and contradictory signals to search engines (since they will not be redirected when rendering the page.)
What if you can’t server side render?
If you’re looking to use Angular with a headless CMS – check out our guide on SEO for headless eCommerce websites.
Dan is the Delivery Director at NOVOS. A former neuroscientist, Dan entered the world of SEO by working with one of the top SEO agencies in the country and has architectured several award-winning SEO campaigns since then. Dan joined NOVOS as an SEO manager and his vast knowledge of tech SEO has helped NOVOS execute even the most complicated eCommerce SEO plans. He is phenomenal at solving client problems and knowing exactly the high standards we want to deliver which is why he is now our Delivery Director.
- How to Build a Business Case for SEO | Selling SEO Internally Series Part I
- Post-Conversion – the most untapped stage of the customer journey | In collaboration with Yotpo
- Data-led: When to use a Pivot Table
- How To Add Schema Markup Using Google Tag Manager
- 6 SEO recommendations every international eCom website should implement
Worried Angular is limiting your SEO?
We're eCommerce specialists for a reason, get in touch with us today and find out more.