Skip to content
Searchpedia SEO field notes Callum Bennett Callum

Site ops

JavaScript SEO

JavaScript SEO is the practice of making sure your JavaScript-powered site is actually seen by search engines. If your content, links, or metadata only appear after JS runs, you might be invisible.

Beginner5 min readUpdated 2026-07-27Notes by Callum Bennett

Start here

  • Critical content should be in the initial HTML when possible.
  • Always test what Google actually renders—don't trust your browser.
  • Use real anchor tags for links; avoid JavaScript-only navigation.
  • Don't block CSS or JavaScript files in robots.txt.
  • Structured data must be in the rendered DOM, not just in JS.

What I'd do first

  1. Open your page in a browser, view the page source (Ctrl+U), and check if your main content, title tag, meta description, and links are there. If they're only in a JavaScript bundle, you've got work to do.
  2. Use the URL Inspection tool in Google Search Console. Enter your page URL and click 'View Crawled Page'. That's what Google sees. Compare it to your browser view.
  3. Check your internal links—are they real <a href="..."> tags, or just <div onClick="...">? If the latter, Google may not follow them.
  4. Look at your robots.txt file to ensure you aren't blocking JavaScript or CSS files. Google needs those to render.
  5. If you use structured data (like JSON-LD for reviews or recipes), verify it appears in the rendered HTML, not just in your JavaScript.

Plain-English take

JavaScript SEO isn't about avoiding JavaScript—it's about being honest with yourself about how Google sees your site. Google can run JavaScript, but it's not as fast or perfect as your browser. So if your entire page is built in JavaScript (client-side rendering), there's a delay: Google has to: crawl the HTML, then fetch and execute the JS, then render the final page. Sometimes that doesn't happen at all. The core idea: make sure your critical content—headings, links, primary text—exists in the initial HTML response, or at least is reliably rendered during indexing. Test everything. Don't assume.

How it shows up

I've seen this play out more times than I can count. A client's Angular site was ranking well for a while, then dropped. I ran the URL Inspection tool—Google showed a blank page because the JavaScript failed to execute. All the content was loaded via AJAX. The fix: we moved the core content into the initial HTML (server-side rendering for the critical path) and kept the dynamic stuff for later. Traffic recovered in weeks. Another common tell: pages with # in URLs that rely on hash-based routing. Google can handle hashes now, but it's less reliable than real paths. If you see your pages in Search Console as 'Crawled - currently not indexed', that's often a JS rendering issue.

Tradeoffs

You want a fast, interactive site. JavaScript frameworks give you that. But you also want to be found in search. The tradeoff: pure client-side rendering is simpler to develop but riskier for SEO. Server-side rendering or pre-rendering adds complexity and server cost but ensures Google sees your content immediately. I've second-guessed myself a lot here—is pre-rendering worth it for a small blog? Sometimes yes, if that blog is your main traffic source. For a web app with logged-in content? Maybe not. Another tradeoff: lazy loading. Great for performance, but if you lazy-load critical content, Google may never request it. You can use lazy loading for images below the fold, but not for your H1 or primary text. There's no perfect answer; you have to pick what matters most.

What I got wrong

Early in my career, I blocked JavaScript and CSS in robots.txt thinking it would speed up crawling. Wrong. Google needed those to render the page. I ended up with a site that looked like a blank white page to Google. It took me weeks to realize. Another mistake: assuming that if the page looked right in my browser (with DevTools open and all JS loaded), Google would see the same thing. Google's renderer is different—often sparse, with slower timeouts. I also used to think that as long as my content was in the DOM eventually, it was fine. But Google may not wait for your infinite scroll or click-to-load actions. Now I test every page with Search Console's 'Live Test' before I go live.

Next step

Technical SEOBroader look at crawlability, indexation, and site health.

Quick answers

Does Google use JavaScript?

Yes, Google can process JavaScript, but it may not render all content immediately. Important content should be available in the initial HTML when possible.

Is JavaScript bad for SEO?

No, JavaScript itself is not bad for SEO. However, poor implementation—like hiding content behind JS without fallbacks—can cause indexing issues.

Where to go next

More from Site ops

A step sideways

Sources

Primary documentation is linked directly. Anything commercial is marked nofollow.

Notes from Callum Bennett.