A Non-Technical Guide to Diagnosing JavaScript SEO Issues

This audit process aims to uncover instances where SEO-critical page content like headings, body copy, internal links, and other elements are rendered by JavaScript.

Here are the tools you’ll need to follow along:

• Screaming Frog

• Google Search Console

• View Rendered Source extension for Chrome

Step 1: Mimic how searchbots crawl your website using Screaming Frog

Before deep diving into anything, I crawl the website like a searchbot. If Screaming Frog can’t find the pages I want to index, it’s a sign of internal linking problems that could be JavaScript-related.

In Screaming Frog, navigate to Configuration > Crawl Config and mirror my setup:

In the Spider > Crawl tab, follow this configuration. It’s essential to deselect JavaScript and provide your XML sitemap.

Any good SEO knows it’s not productive to point out issues without offering solutions. So, let’s look at the options we can bring to web developers to improve our JavaScript SEO.

The feasibility of these solutions depends on your website’s tech stack. Hence, laying out a good/better/best approach is important.

Ideal solution: Make critical content available in the raw HTML

As SEOs, we can sleep soundly at night knowing that our website’s internal links, page headings, body copy, and more are available to Google in our raw HTML. Searchbots can crawl and index our critical content efficiently without risking errors or delays associated with Google’s rendering service.

Ensure you highlight to developers the critical SEO elements currently absent from the raw HTML and explore the feasibility of making those updates.

Next best solution: Implement a server-side rendering (SSR) solution

Before we go into this solution, let’s understand server-side rendering (SSR) vs. client-side rendering (CSR):

• Server-Side Rendering: The initial page load delivers all content to the browser via HTML.

• Client-Side Rendering: Content from JavaScript files is downloaded to the browser after the initial page load.

Issues with indexing JavaScript-rendered content come from its client-side rendering. You know when you switch off JavaScript in your browser, and some parts of the page vanish? That’s the issue visualized right there.

I regularly use this analogy from Onely to explain the difference: “CSR is like a cooking recipe. Google gets the cake recipe that needs to be baked and collected. SSR – Google gets the cake ready to consume. No need for baking.”

So, the essential question for our devs is, “Could we lean on SSR instead of CSR to deliver content during the initial page load?”

And here’s a pro tip: If you’re familiar with your website’s JavaScript framework, many offer handy tools to integrate SSR smoothly.

Last-ditch solution: Implement dynamic rendering

Dynamic rendering is a hybrid solution where your users experience your website’s client-side rendering while search engine bots are served a separate, static HTML version.

Wouldn’t it be great if developers dropped everything whenever you came forward with an SEO issue to fix? Unfortunately, the world doesn’t revolve around SEO priorities. But you can rally resources to your side if you present a compelling case.

Connect SEO to organizational priorities

If you’ve found that JavaScript rendering harms SEO performance, your goal is to make a business case so non-SEOs care about the problem:

• Tie the opportunity to organizational goals: For example, if building brand awareness is a marketing priority, explain how JavaScript-related indexing issues prevent potential customers from discovering your brand through organic search.

• Forecast the performance impact: Implementing your fixes comes with a cost, so mitigate those concerns by showing business gains.

Make it easy for developers to implement your recommendations

While SEOs and developers benefit from working together, you must pull your weight. Do the upfront legwork so it’s easy for your engineering team to take your recommendations to the finish line.

Here’s how:

• Present solutions instead of pointing out issues. You’ll encounter less friction if you come to the table ready to converse rather than deliver a mandate.

• Provide clear technical requirements, screenshots, and links to relevant documentation. If possible, refer to examples from similar websites or competitors with similar tech stacks.