I will provide tons of additional tips and recommendations, too. We have a lot to cover, so get yourself a cup of coffee (or two) and let’s get started.

In this article, I will guide you through why it’s happening and how to fix it. You’ll learn:

However, many JavaScript websites – despite its popularity – underperform in Google because they don’t do JavaScript SEO properly.

JavaScript is extremely popular. Based on my research, as much as 80% of the popular eCommerce stores in the USA use JavaScript for generating main content or links to similar products.

JavaScript brings interactivity and dynamism to the web that’s built on the static foundation of HTML markup. This guide covers everything you need to know to make sure using JavaScript doesn’t impair your rankings or your User Experience.

chapter 1 What is JavaScript and How is it Used? In 2020, there’s no doubt: JavaScript is the future of the web. Of course, HTML and CSS are the foundation. But virtually every modern web developer is expected to code in JavaScript too. But what can JavaScript do, exactly? And how can you check which elements of your website are using it? Read on and you’ll find out.

JavaScript is an extremely popular programming language. It’s used by developers to make websites interactive. JavaScript has the unique ability to dynamically update the content of a page. For instance, it’s used by Forex and CFD trading platforms to continually update the exchange rates in real-time. Now, imagine a website like Forex.com without JavaScript. Without JavaScript, users would have to manually refresh the website to see the current exchange rates. JavaScript simply makes their lives much easier. In other words, you can build a website using only HTML and CSS, but JavaScript is what makes it dynamic and interactive. HTML defines the actual content of a page (body/frame of a car).

CSS defines the look of the page (colors, style).

JavaScript adds interactivity to the page. It can easily control and alter HTML (engine + wheel + gas pedals). Which website elements are commonly generated by JavaScript? The types of content that are commonly generated by JavaScript can be basically put into six categories: Pagination

Internal links

Top products

Reviews

Comments

Main content (rarely) How do I know if my website is using JavaScript? 1. Use WWJD To make it easy for you to check if your website relies on JavaScript, we created WWJD – What Would JavaScript Do- which is just one of our FREE tools. Simply go to WWJD and type the URL of your website into the console. Then look at the screenshots that the tool generates and compare the two versions of your page – the one with JavaScript enabled and the one with JavaScript disabled. 2. Use a browser plugin Using our tool is not the only way to check your website’s JavaScript dependency. You can also use a browser plugin like Quick JavaScript Switcher on Chrome, or JavaScript Switch on Firefox. When you use the plugin, the page you’re currently on will be reloaded with JavaScript disabled. If some of the elements on the page disappear, it means that they were generated by JavaScript. An important tip: if you decide to use a browser plugin instead of WWJD, make sure you also take a look at the page source and the DOM (Document Object Model) and pay attention to your canonical tags and links. It often happens that JavaScript doesn’t change much visually and you wouldn’t notice that it’s even there. However, it can change your metadata under the hood, which can potentially lead to serious issues. Important: “view source” is not enough when auditing JS websites You may hear that investigating what’s inside the source code of your web pages is one of the most important things in an SEO audit. However, with JavaScript in the picture, it gets more complicated. HTML is a file that represents just the raw information used by the browser to parse the page. It contains some markup representing paragraphs, images, links, and references to JS and CSS files. You can see the initial HTML of your page by simply right-clicking -> View page source. However, by viewing the page source you will not see any of the dynamic content updated by JavaScript. With JavaScript websites, you should look at the DOM instead. You can do it by right-clicking -> Inspect element. Here’s how I would describe the difference between the initial HTML and the DOM: The initial HTML (right-click -> View page source) is just a cooking recipe. It provides information about what ingredients you should use to bake a cake. It contains a set of instructions. But it’s not the actual cake. DOM (right-click -> inspect element) is the actual cake. In the beginning, it’s just a recipe (an HTML document) and then, after some time it gains a form and then it’s baked (page fully loaded). Note: If Google can’t fully render your page, it can still index just the initial HTML (which doesn’t contain dynamically updated content). Now that you’re sure what elements of your page depend on JavaScript, it’s time to find out if Google can properly deal with your JavaScript content.

chapter 2 Can Google Index JavaScript? JavaScript makes the web truly dynamic and interactive, and that’s something that users love. But what about Google and other search engines? Can they easily deal with JavaScript, or is it more of a love-hate relationship? As a leading technical SEO agency, we’re constantly doing research to look for Google’s strengths and weaknesses. And when it comes to JavaScript, it’s sort of a mixed bag…

Indexing JavaScript content by Google is never guaranteed. We recently investigated multiple websites that are using JavaScript. It turned out that on average, their JavaScript content was not indexed by Google in 25% of the cases. That’s one out of four times. Here are some examples of the tested websites: tell me more! tell me more! Tomek covered this topic before! Read Tomek’s “ JavaScript is More Popular Than You Think ” for the full story. → Read more On the other hand, some of the websites we tested did very well: As you can see, Google can index JavaScript content on some websites much better than others. This means that these issues are self-induced and can be avoided. Keep reading to learn how. It’s also important to know that indexing content isn’t guaranteed even in the case of HTML websites. JavaScript simply adds more complexity, as there are a couple more things that could go wrong. Why Google (and other search engines) may have difficulties with JavaScript I. The complexity of JavaScript crawling In the case of crawling traditional HTML websites, everything is easy and straightforward, and the whole process is lightning fast: Googlebot downloads an HTML file. Googlebot extracts the links from the source code and can visit them simultaneously. Googlebot downloads the CSS files. Googlebot sends all the downloaded resources to Google’s Indexer (Caffeine). The indexer (Caffeine) indexes the page. For Google, things get complicated when it comes to crawling a JavaScript-based website: Googlebot downloads an HTML file. Googlebot finds no links in the source code as they are only injected after executing JavaScript. Googlebot downloads the CSS and JS files. Googlebot has to use the Google Web Rendering Service (a part of the Caffeine Indexer) to parse, compile and execute JavaScript. WRS fetches the data from external APIs, from the database, etc. The indexer can index the content. Google can discover new links and add them to the Googlebot’s crawling queue. In the case of the HTML website, that’s the second step. In the meantime, there are many things that can go wrong with rendering and indexing JavaScript. As you can see, the whole process is much more complicated with JavaScript involved. The following things should be taken into account: Parsing, compiling and running JavaScript files is very time-consuming – both for users and Google. Think of your users! I bet anywhere between 20-50% of your website’s users view it on their mobile phone. Do you know how long it takes to parse 1 MB of JavaScript on a mobile device? According to Sam Saccone from Google : Samsung Galaxy S7 can do it in ~850ms and Nexus 5 in ~1700ms. After parsing JavaScript, it has to be compiled and executed, which takes additional time. Every second counts.

In the case of a JavaScript-rich website, Google can’t usually index the content until the website is fully rendered.

The rendering process is not the only thing that is slower. It also refers to the process of discovering new links. With JavaScript-rich websites, it’s common that Google cannot discover any links on a page before the page is rendered.

The number of pages Googlebot wants to & can crawl is called the crawl budget. Unfortunately, it’s limited, which is important for medium to large websites in particular. If you want to know more about the crawl budget, I advise you to read the Ultimate Guide to the Crawler Budget Optimization by Artur Bowsza, Onely’s SEO Specialist. Also, I recommend reading Barry Adams’ article “ JavaScript and SEO: The Difference Between Crawling and Indexing ” (the JavaScript = Inefficiency and Good SEO is Efficiency sections, in particular, are must-haves for every SEO who deals with JavaScript). II. Googlebot Doesn’t Act Like a Real Browser It’s time to go deeper into the topic of the Web Rendering Service. As you may know, Googlebot is based on the newest version of Chrome. That means that Googlebot is using the current version of the browser for rendering pages. But it’s not exactly the same. Googlebot visits web pages just like a user would when using a browser. However, Googlebot is not a typical Chrome browser. Googlebot declines user permission requests (i.e. Googlebot will deny video auto-play requests).

Cookies, local, and session storage are cleared across page loads. If your content relies on cookies or other stored data, Google won’t pick it up.

Browsers always download all the resources – Googlebot may choose not to. When you surf the internet, your browser (Chrome, Firefox, Opera, whatever) downloads all the resources (such as images, scripts, stylesheets) that a website consists of and puts it all together for you. However, since Googlebot acts differently than your browser, its purpose is to crawl the entire internet and grab valuable resources. The World Wide Web is huge though, so Google optimizes its crawlers for performance. This is why Googlebot sometimes doesn’t load all the resources from the server. Not only that, Googlebot doesn’t even visit all the pages that it encounters. Google’s algorithms try to detect if a given resource is necessary from a rendering point of view. If it isn’t, it may not be fetched by Googlebot. Google warns webmasters about this in the official documentation. Googlebot and its Web Rendering Service (WRS) component continuously analyze and identify resources that don’t contribute essential page content and may not fetch such resources. source: Google's Official Documentation Because Googlebot doesn’t act like a real browser, Google may not pick some of your JavaScript files. The reason might be that its algorithms decided it’s not necessary from a rendering point of view, or simply due to performance issues (i.e. it took too long to execute a script). Additionally, as confirmed by Martin Splitt, a Webmaster Trends Analyst at Google, Google might decide that a page doesn’t change much after rendering (after executing JS) so they won’t render it in the future. Also, rendering JavaScript by Google is still delayed (however, it is much better than in 2017-2018, when we commonly had to wait weeks till Google rendered JavaScript). If your content requires Google to click, scroll, or perform any other action in order for it to appear, it won‘t be indexed. Last but not least: Google’s renderer has timeouts. If it takes too long to render your script, Google may simply skip it.

chapter 3 The Foundations for Successful JavaScript SEO You now know that JavaScript makes Google’s job a little more complicated. And because of that, there are additional steps that you should take to make your JavaScript website do well in Google. JavaScript SEO may seem intimidating at first, but don’t worry! This chapter will help you diagnose potential problems on your website and get the basics right.

There are three factors at play here: 1) crawlability (Google should be able to crawl your website with a proper structure and discover all the valuable resources); 2) renderability (Google should be able to render your website); 3) crawl budget (how much time it will take for Google to crawl and render your website). Rendering JavaScript can affect your crawl budget and delay Google’s indexing of your pages. tell me more! tell me more! The Ultimate Guide to the Crawler Budget Optimization You can read more about the crawl budget in our “ Ultimate Guide to the Crawler Budget Optimization “. → Read more Is your JavaScript content search engine-friendly? Here’s a checklist that you can use to check if Google and other search engines are able to index your JavaScript content. I. Check if Google can technically render your website. As a developer, website owner, or SEO, you should always make sure that Google can technically render your JavaScript content. It simply isn’t enough to open Chrome and see if it’s OK. Instead, use the Live Test in Google’s URL Inspection Tool, available through the Search Console. It allows you to see a screenshot of how exactly Googlebot would render the JavaScript content on your page. Inspect the screenshot and ask yourself the following questions: Is the main content visible?

Can Google access areas like similar articles and products?

Can Google see other crucial elements of your page? If you want to dive deeper, you can also take a look at the HTML tab within the generated report. Here, you can see the DOM – the rendered code, which represents the state of your page after rendering. What if Google cannot render your page properly? It may happen that Google renders your page in an unexpected way. Looking at the image above, you can see that there’s a significant difference between how the page looks to the user compared to how Google renders it. There are a few possible reasons for that: Google encountered timeouts while rendering.

Some errors occurred while rendering.

You blocked crucial JavaScript files from Googlebot. By clicking on the More info tab, you can easily check if any JavaScript errors occurred while Google was trying to render your content. Important note: making sure Google can properly render your website is a necessity. However, it doesn’t guarantee your content will be indexed. Which brings us to the second point. II. Check if your content is indexed in Google. There are two ways of checking if your JavaScript content is really indexed in Google. Using the “site” command – the quickest method. Checking Google Search Console – the most accurate method. As a quick note: you shouldn’t rely on checking Google Cache as a way of ensuring Google indexed your JavaScript content. Even though many SEOs still use it, it’s a bad idea to rely on Google Cache. You can find out more by reading “Why Google Cache Lies to You and What To Do” by Maria Cieślak, Onely’s Head of SEO. The “Site” Command In 2020, one of the best options for checking if your content is indexed by Google is the “site” command. You can do it in two simple steps. 1. Check if the page itself is in Google’s index. First, you have to ensure that the URL itself is in Google’s index. To do that, just type “site:URL” in Google (where the URL is the URL address of a page you want to check). Now, when you know that the URL is in fact in Google’s database, you can: 2. Check if Google really indexed your JavaScript content. It’s very easy, too. Knowing which fragments of your page depend on JavaScript after using our tool, WWJD, just copy a text fragment from your page and type the following command in Google: site:{your website} “{fragment}”. If a snippet with your fragment shows up, that means your content is indexed in Google. I encourage you to check the “site” command across various types of JS-generated content. My personal recommendation: perform a “site:” query with a fragment in incognito mode. Google Search Console A more precise, albeit slower, method of checking if your content is indexed by Google is using the Google Search Console. Type the URL in question into the URL Inspection Tool. Then click View crawled page. This will show you the code of your page that is indexed in Google. Just Ctrl+F to make sure if the crucial fragments of your content generated by JavaScript are here. I recommend repeating this process for a random sample of URLs to see if Google properly indexed your content. Don’t stop at just one page; check a reasonable number of pages. What if Google doesn’t index my JavaScript content? As I mentioned before, the problems that some websites have with getting their JavaScript content indexed are largely self-induced. If you happen to struggle with that problem, you should find out why it might be happening in the first place. There are multiple reasons why your JavaScript content wasn’t picked up by Google. To name a few: Google encounters timeouts . Are you sure you aren’t forcing Googlebot and users to wait many seconds until they are able to see the content?

Google had rendering issues . Did you check the URL Inspection tool to see if Google can render it?

Google decided to skip some resources (i.e. JavaScript files) .

Google decided the content is of low quality.

It may also happen that Google will index JavaScript content with a delay .

. Google simply wasn’t able to discover this page. Are you sure it’s accessible via the sitemap and the internal structure?

chapter 4 Different Ways of Presenting JavaScript Content for Google There are several ways of serving your web pages to both users and search engines. And understanding them is crucial when we are talking about SEO, not exclusively in the context of JavaScript. What’s right for your website: Client-side rendering (CSR), Server-side rendering (SSR), or perhaps something more complex? In this chapter, we’ll make sure you know which solution suits your needs.

As we discuss whether Google can crawl, render and index JavaScript, we need to address two very important concepts: Server-side rendering and Client-side rendering. It’s necessary for every SEO who deals with JavaScript to understand them. In the traditional approach (server-side rendering), a browser or Googlebot receives an HTML file that completely describes the page. The content copy is already there. Usually, search engines do not have any issues with server-side rendered JavaScript content. The increasingly popular client-side rendering approach is a little different and search engines sometimes struggle with it. With this approach, it’s pretty common that a browser or Googlebot gets a blank HTML page (with little to no content copy) in the initial load. Then the magic happens: JavaScript asynchronously downloads the content copy from the server and updates your screen. Remember our baking analogy? It’s valid here as well: Client side-rendering is like a cooking recipe. Google gets the cake recipe that needs to be baked and collected.

Server-side rendering – Google gets the cake ready to consume. No need for baking. On the web, you’ll see a mix of these two approaches. 1. Server-Side Rendering When, for some reason, Google cannot index your JavaScript content, one of the solutions is to implement server-side rendering. Websites like Netflix, Marvel, Staples, Nike, Hulu, Expedia, Argos, and Booking.com take advantage of server-side rendering. There is one problem though: a lot of developers struggle with implementing server-side rendering (however, the situation is getting better and better!). There are some tools that can make implementing SSR faster: Framework Solution React Next.js, Gatsby Angular Angular Universal Vue.js Nuxt.js My tip for developers: If you want your website to be server-side rendered, you should avoid using functions operating directly in the DOM. Let me quote Wassim Chegham, a developer expert at Google: “One of THE MOST IMPORTANT best practices I’d recommend following is: Never touch the DOM.” 2. Dynamic rendering Another viable solution is called dynamic rendering. In this approach, you serve users a fully-featured JavaScript website. At the same time, your server will send Googlebot (and/or other bots) a static version of your website. Dynamic rendering is an approach officially supported by Google. You can use these tools/services to implement dynamic rendering on your website: Prerender.io

Puppeteer

Rendertron Google also provides a handy guide explaining how to successfully implement dynamic rendering. As of 2020, Google recommends using dynamic rendering in two cases: For indexable JS-generated content that changes rapidly. Content that used JS features that aren’t supported by crawlers. Can Twitter, Facebook and other social media deal with JavaScript? Unfortunately, social media sites don’t process the JavaScript their crawlers find on websites. To reiterate, social media like Facebook, Twitter, or LinkedIn don’t run JavaScript. What does that mean for you? You must include Twitter Cards, as well as Facebook Open Graph markup in the initial HTML. Otherwise, when people share your content on social media, it won’t be properly displayed. Not convinced? Let’s see how links to Angular.io and Vue.js look when you share them on Twitter: Angular.io is the second most popular JavaScript framework. Unfortunately for them, Twitter doesn’t render JavaScript, and therefore it can’t pick up the Twitter cards markup that are generated by JavaScript. Would you click on that link? Probably not. Now contrast that with a link to Vue.js – the Twitter card looks much better with the custom image and an informative description! Takeaway: If you care about traffic from social media, make sure that you place the Twitter card and Facebook Open Graph markup in the initial HTML!

chapter 5 Common Pitfalls with JS Websites At this point, you should have a decent understanding of how JavaScript is processed by Google and other search engines. With these foundations in place, you are set for success. There’s just a couple of caveats to JavaScript SEO that are hard to spot, and I want to help you avoid them. Now that we’ve covered most of the basics, let’s look at some of the common mistakes that SEOs and webmasters make when optimizing their JavaScript-based websites.

BLOCKING JS AND CSS FILES FOR GOOGLEBOT Since Googlebot is able to crawl and render JavaScript content, there is no reason to block it from accessing any internal or external resources required for rendering. IMPLEMENT PAGINATION CORRECTLY Many popular websites use pagination as a way of fragmenting large amounts of content. Unfortunately, it’s very common that these websites only allow Googlebot to visit the first page of pagination. As a result, Google isn’t able to easily discover large amounts of valuable URLs. For example, when it comes to eCommerce websites, Googlebot would only be able to reach 20-30 products per category on paginated category pages. As a consequence, Googlebot most likely cannot access all the product pages. How does this happen? Many websites improperly implement pagination by not using a proper <a href> link. Instead, they use pagination that depends on a user action – a click. In other words, Googlebot would have to click on a button (View more items) to get to the consecutive pages. Unfortunately, Googlebot doesn’t scroll or click the buttons. The only way to let Google see the second page of pagination is to use proper <a href> links. If you still are not sure if Google can pick up your links, check out this slide from the Google I/O conference in 2018: Important note: Having links hidden under link rel=”next” doesn’t help either. Google announced in March 2019 that they no longer use this markup: Spring cleaning! As we evaluated our indexing signals, we decided to retire rel=prev/next.

Studies show that users love single-page content, aim for that when possible, but multi-part is also fine for Google Search. Know and do what's best for *your* users! #springiscoming pic.twitter.com/hCODPoKgKp — Google Webmasters (@googlewmc) March 21, 2019 To sum up, ALWAYS USE PROPER LINKS! tell me more! tell me more! How do you implement pagination correctly? For the answer, you should read my article “ Popular Websites that May Fail in Mobile-First Indexing “. → Read more USING HASHES IN URLs It’s still common that many JavaScript websites generate URLs with a hash. There is a real danger that such URLs may not be crawled by Googlebot: Bad URL: example.com/#/crisis-center/

Bad URL: example.com#crisis-center

Good URL: example.com/crisis-center/ You may think that a single additional character in the URL can’t do you any harm. On the contrary, it can be very damaging. For us, if we see the kind of a hash there, then that means the rest there is probably irrelevant . For the most part, we will drop that when we try to index the content (…). When you want to make that content actually visible in search, it’s important that you use the more static-looking URLs.

source: John Mueller That’s why you need to remember to always make sure your URL doesn’t look like this: example.com/resource#dsfsd Angular 1 uses hashtag-based URLs by default so be careful if your website is built using that framework! You can fix it by configuring $locationProvider (here is a tutorial on how to do that!). Fortunately, the newer versions of the Angular framework use Google-friendly URLs by default.

chapter 6 FAQ - BONUS CHAPTER! As we wind down here, you probably have a few questions. And that’s great! I put together the most common questions readers have asked me about JavaScript SEO over the years, including questions about the two waves of indexing, PWAs, serving Googlebot a pre-rendered version of your website, the future of JavaScript SEO itself, and more! But there is one small catch…

Want to read CHAPTER 6: FAQ? Want to read CHAPTER 6: FAQ? Then sign up and get instant access.





I consent to Onely using my contact data for newsletter purposes.

Takeaways As we’ve reached the end of the article, I want to take a moment and address a problem that could affect even the best SEOs. It’s important to remember that JavaScript SEO is done on top of traditional SEO, and it’s impossible to be successful at the former without taking care of the latter. Sometimes when you encounter an SEO problem, your first instinct might be that it’s related to JavaScript, when in fact, it’s related to traditional SEO. Apply the principles of SEO well and be very careful before you start blaming JavaScript. Being able to quickly diagnose the source of the problem will save you lots of time. Here are some other takeaways: Google’s rendering service is based on the most recent version of Chrome. However, it has many limitations (may not fetch all the resources, some features are disabled). Google algorithms try to detect if a resource is necessary from a rendering point of view. If not, it probably won’t be fetched by Googlebot.

Usually, it’s not enough to analyze just the source page (HTML) of your website. Instead, you should analyze the DOM (Right-click -> Inspect tool).

You can use tools like Onely’s WWJD What Would JavaScript Do ) or browser add-ons to check which elements are generated by JavaScript.

When you have a JavaScript website and care about traffic from social media, check what your social shares look like (whether they have pictures and custom descriptions).

You shouldn’t use Google cache to check how Google is indexing your JavaScript content. It only tells you how YOUR browser interpreted the HTML collected by Googlebot. It’s totally unrelated to how Google rendered and indexed your content.

JavaScript is very error-prone. A single error in your JavaScript code can cause Google to be unable to render your page.

Use the URL Inspection tool often. It will tell you if Google was able to properly render and index your JavaScript content.

To make sure Google is able to index your JavaScript you have to take web performance into consideration. Do it for the sake of your users and getting indexed by search engines

If Google can’t render your page, it can pick up the raw HTML for indexing. This can break your Single-Page Application (SPA), because Google may index a blank page with no actual content.