DEV Community: JSVisible

I Scanned 5 Popular JavaScript Sites for SEO Issues — Here's What I Found

JSVisible — Sun, 29 Mar 2026 22:07:53 +0000

Everyone assumes big tech companies have flawless SEO. I decided to test that. I scanned five well-known JavaScript-heavy sites — react.dev, vercel.com, stripe.com/docs, linear.app, and shopify.com — running 19 SEO health checks across 10 pages each.

Every single site had issues. Some had a lot of them.

The Scores

react.dev — 74/100 (Best of the group)
vercel.com — 71/100 (Solid but sloppy on details)
stripe.com/docs — 60/100 (Surprising for Stripe)
linear.app — 57/100 (Heavy SPA showing its seams)
shopify.com — 39/100 (The biggest surprise)

react.dev — 74/100

React's docs scored highest. Strong internal linking (3.5 avg links/page, zero orphan pages), all pages indexable, proper canonicals and OG tags.

Weak spots: zero structured data on every page, meta descriptions too short on 9/10 pages, and a JavaScript file that failed to load on /versions. The irony of React's docs having a broken JS file is hard to ignore.

vercel.com — 71/100

The Next.js creators get SSR right — all pages indexable, good content depth, OG tags everywhere. But the details slip: missing meta description on /abuse, missing canonical on /academy, missing H1 on a subpage, and 9 orphan pages out of 10 scanned.

Internal linking was surprisingly weak — 0.0 average links per page in the scanned set.

stripe.com/docs — 60/100

I expected Stripe to ace this. They nail the fundamentals — titles, meta descriptions, H1s, canonicals, OG tags, proper heading hierarchy. Zero orphan pages.

But: zero structured data on all 10 pages (huge missed opportunity for docs), 7/10 pages missing image alt text, 8/10 pages loading over 3 seconds, and API requests failed on every single page. That last one means some content may not be loading for crawlers.

linear.app — 57/100

Beautiful product, but SEO tells a different story. Zero structured data, every meta description too short, 8/10 titles too short, all 10 pages slow to load, 4 orphan pages.

The internal link average was just 0.5/page — the SPA architecture isn't generating proper crawlable links between pages. JS console errors on 2 pages, failed API requests on 2 more.

shopify.com — 39/100

The lowest score and the biggest company. The crawler landed on their Dutch locale pages, revealing issues you'd miss checking only the English site.

8/10 pages orphaned. Failed API requests on 7/10 pages. Missing H1s on 2 pages. No structured data on 8/10 pages. Even Shopify has SEO gaps.

Key Patterns Across All 5 Sites

Structured data is universally neglected. 4 out of 5 sites had zero Schema.org markup on every page scanned. This is free real estate for rich snippets that everyone leaves on the table.

Meta descriptions are an afterthought. Short, generic, or missing. These directly affect click-through rates from search results.

Image alt text is consistently missing. Every site had pages with images lacking alt text. Easy 2-minute fix per image with high accessibility and SEO impact.

Internal linking is weak on SPAs. Linear and Shopify had most pages orphaned. Server-rendered sites (Stripe, React) did better because links exist in the initial HTML.

Page speed is a universal problem. Most pages across all sites took over 3 seconds to load. JavaScript-heavy sites consistently struggle here.

AI crawlers see even less. These scores reflect what Googlebot sees after JS rendering. AI crawlers from ChatGPT and Perplexity don't render JS at all — they only see raw HTML. Sites using client-side rendering are invisible to AI search.

What You Can Do

Check your page source. Right-click → View Page Source. If your content isn't in the raw HTML, crawlers aren't seeing it.
Add structured data. 20-30 minutes per page type, huge ROI for rich snippets.
Write proper meta descriptions. 150-160 characters, unique per page.
Add alt text to every image. 2 minutes per image.
Fix internal linking. Every important page needs 2-3 internal links. Use real <a href> tags, not JS click handlers.
Use SSR for important pages. Critical now that AI crawlers don't render JavaScript.

Note: these are 10-page scans — a snapshot, not a full audit. But the patterns are consistent and verifiable by viewing page source on any of these sites.

I built JSVisible to automate these checks — it renders pages as both a user and Googlebot and compares the results. Free tier available if you want to try it on your own site.

Why AI Crawlers Can't See Your React App

JSVisible — Wed, 04 Mar 2026 18:47:11 +0000

Google has been rendering JavaScript since 2019. It's not perfect, but it works. So if you're building with React, Vue, or Next.js, you might assume search engines can see your content just fine.

That assumption is about to cost you traffic.

Because Google isn't the only crawler that matters anymore. AI-powered search engines are growing fast — ChatGPT, Perplexity, Google's AI Overviews, Microsoft Copilot. They're changing how people find information online. And almost none of their crawlers render JavaScript.

How AI Crawlers Actually Work

When GPTBot (OpenAI's crawler), PerplexityBot, or ClaudeBot visit your site, they don't fire up a headless browser. They don't execute your JavaScript. They don't wait for your React components to mount or your API calls to resolve.

They send a simple HTTP request, download whatever HTML your server returns, and move on.

If your server returns a fully rendered page with all your content in the HTML, great — the AI crawler sees everything. If your server returns an empty shell with a script tag that loads your app, the AI crawler sees nothing.

There's no rendering queue. There's no second pass. What your server sends in that first response is all they'll ever see.

Why This Is Different from Google

Google's approach to JavaScript has three steps. First, Googlebot fetches your raw HTML and extracts whatever it can. Second, it puts your page in a rendering queue. Third, Google's Web Rendering Service executes your JavaScript in a headless Chromium browser and indexes the final result.

It's not instant — that rendering queue can take hours or days — but eventually Google sees your fully rendered page.

AI crawlers skip steps two and three entirely. They only do step one. Fetch the HTML, read it, done.

This means a client-side rendered React app that Google eventually indexes correctly might be completely invisible to every AI crawler on the internet.

The Traffic Impact Is Real

AI-powered search is growing fast. Perplexity reports millions of daily queries. ChatGPT's browsing feature is used by hundreds of millions of users. Google's own AI Overviews now appear on a significant percentage of search results.

When these tools answer questions, they pull from content their crawlers have indexed. If your content isn't in their index because their crawlers couldn't see it, you won't be cited. You won't be recommended. You won't get that traffic.

This isn't a future problem. It's happening right now.

Which Frameworks Are Affected

Not all JavaScript apps have this problem. It depends on how your framework renders pages.

Client-side rendering is the most affected. This is the default for Create React App and vanilla single-page applications. The server sends an empty HTML shell, and the browser builds the page entirely with JavaScript. AI crawlers see nothing but an empty div and a script tag.

Server-side rendering is safe. Frameworks like Next.js (with getServerSideProps or Server Components), Nuxt.js, and SvelteKit can render your pages on the server before sending them to the browser. The AI crawler gets a fully rendered HTML page on the first request.

Static site generation is also safe. If you pre-build your pages at deploy time (Next.js static export, Astro, Gatsby), the HTML files already contain all your content. No JavaScript execution needed.

The tricky case is hybrid rendering. Many Next.js and Nuxt apps use a mix — some pages are server-rendered, others are client-rendered. You might have SSR on your landing page but client-side rendering on your blog or product pages. This creates a situation where some pages are visible to AI crawlers and others aren't, which is hard to diagnose without testing each page individually.

How to Check If You're Affected

The fastest test takes 30 seconds. Open your site in Chrome, right-click anywhere, and select "View Page Source" — not "Inspect Element." View Page Source shows you the raw HTML your server sends before any JavaScript executes. This is exactly what AI crawlers see.

If your main content, headings, meta descriptions, and navigation links are all in that source HTML, you're fine. If you see mostly empty divs, script tags, and a loading spinner, AI crawlers are seeing the same empty page.

For a more thorough check, you can compare how your page looks to a regular user versus how it looks to different crawlers. Tools like JSVisible render your pages from multiple perspectives — user browser, Googlebot, and raw HTML — so you can see exactly what each crawler sees and where the gaps are.

How to Fix It

If you're on a framework that supports server-side rendering, the fix is straightforward. Switch your critical pages from client-side to server-side rendering. In Next.js, this means using Server Components (the default in the App Router) or getServerSideProps in the Pages Router. In Nuxt, it means using universal rendering mode.

You don't have to server-render everything. Focus on the pages that matter for discovery — your homepage, landing pages, blog posts, product pages, and any page you want search engines and AI tools to find.

If you can't switch to SSR, prioritize getting critical SEO elements into your server-rendered HTML at minimum. Your page title, meta description, canonical URL, and H1 heading should all be in the initial HTML response, not injected by JavaScript after the page loads. Many frameworks have head management utilities that handle this even in client-rendered apps.

For internal links, always use proper anchor tags with href attributes instead of JavaScript click handlers. AI crawlers follow links by reading href values from the HTML. If your navigation uses onClick handlers or client-side routing without real anchor tags, crawlers can't discover your other pages.

The Bottom Line

The web runs on JavaScript, but AI crawlers don't. Google's ability to render JavaScript gave developers a false sense of security. The new generation of AI-powered search tools has exposed a gap that was always there — the gap between what a browser sees and what a simple HTTP request returns.

If your content depends on JavaScript to appear, you're visible to Google (eventually) but invisible to the fastest-growing discovery channel on the internet. The fix isn't complicated. Server-side render your important pages, put critical SEO elements in your initial HTML, and use real links.

The first step is knowing whether you have a problem. Check your page source. If it's empty, so is your presence in AI search.

What Google Actually Sees on Your JavaScript Site (And Why It Might Surprise You)

JSVisible — Mon, 02 Mar 2026 18:30:35 +0000

You spent months building your React app. The design is polished, the content is solid, and your pages load fast in the browser. But here's the thing — what you see in Chrome is not necessarily what Google sees when it crawls your site.

If your site relies on JavaScript to render content, there's a gap between the user experience and the search engine experience. Sometimes it's small. Sometimes your entire page content is invisible to Google. And in 2026, the problem just got worse — because AI crawlers like ChatGPT and Perplexity can't render JavaScript at all.

This post explains what's actually happening under the hood, how to check if your site is affected, and what to do about it.

How Google processes JavaScript sites

When Googlebot visits a URL, it doesn't work like your browser. It processes pages in two phases. First, it fetches the raw HTML — the source code before any JavaScript runs. At this point, it extracts links and basic content from whatever is in that initial HTML response. Second, it puts the page into a rendering queue. Eventually, Google's Web Rendering Service fires up a headless Chromium browser, executes your JavaScript, and captures the final rendered page.

The key word there is "eventually." That rendering queue isn't instant. It can take seconds, hours, or even days depending on Google's resource availability and how many pages it needs to process. During that gap, Google is working with whatever was in your raw HTML — which for many JavaScript apps is essentially an empty shell.
If you're using a framework like React with client-side rendering, your initial HTML might look something like this:

<div id="root"></div>
<script src="/static/js/bundle.js"></script>

That's what Google sees on the first pass. No content, no meta tags, no internal links — just an empty div and a script reference. Everything meaningful only appears after JavaScript executes in the second phase.

Where things go wrong

The rendering gap creates several common problems that are surprisingly hard to detect because everything looks perfect in your browser.

Meta tags are the most frequent casualty. If your page title and meta description are set by JavaScript after page load, Google might index your fallback text instead. Ever searched for your site and seen "React App" as the title or "Loading..." as the description? That's this problem in action.

Internal links are another blind spot. Single-page applications often use JavaScript click handlers for navigation instead of proper anchor tags with href attributes. Google can't follow onClick handlers during the initial HTML crawl — it needs real links to discover your pages. If your navigation is JavaScript-driven, entire sections of your site might not get crawled at all.

Dynamic content that loads from APIs is particularly vulnerable. Product listings, blog posts, user reviews — anything fetched from an API after page load might not exist in Google's initial view. And even after rendering, if the API call is slow or fails, that content stays invisible.

The AI crawler problem

Here's what makes this urgent in 2026: it's not just about Google anymore.
AI crawlers — GPTBot (OpenAI), ClaudeBot (Anthropic), PerplexityBot, and others — are now indexing the web to power AI search results, chatbot answers, and content recommendations. Unlike Google, these crawlers don't render JavaScript at all. They fetch your raw HTML and that's it. No rendering queue, no second pass, no JavaScript execution.

If your content only exists after JavaScript runs, you're completely invisible to AI-powered search. And with AI search growing rapidly, that's an increasingly large chunk of how people discover content online.

Server-side rendering isn't just a Google optimization anymore. It's becoming a requirement for visibility across an entire ecosystem of crawlers and AI tools.

How to check what Google actually sees

The simplest test is to view your page source (not Inspect Element — actual page source). Right-click your page in Chrome and select "View Page Source." This shows you the raw HTML before JavaScript runs. If your main content, titles, and navigation links aren't there, Google is relying on JavaScript rendering to see them.
You can also disable JavaScript in Chrome DevTools to simulate the first-pass experience. Open DevTools, press Ctrl+Shift+P (or Cmd+Shift+P on Mac), type "Disable JavaScript," and reload the page. If your content disappears, that's exactly what crawlers see before rendering.

Google Search Console's URL Inspection tool gives you the rendered version, which is useful for confirming what Google eventually sees after the rendering queue. But it doesn't tell you about the delay or show you the first-pass experience.

For a more thorough check, tools that compare user rendering vs. Googlebot rendering side by side can reveal gaps you'd never catch manually — especially across dozens or hundreds of pages. This is exactly the kind of analysis JSVisible was built for. It renders each page as both a regular user and as Googlebot, captures screenshots from both perspectives, and flags differences automatically across 35+ SEO checks.

What to do about it

If your site has JavaScript rendering issues, the fix depends on your framework and how much you can change.

The gold standard is server-side rendering or static site generation. Frameworks like Next.js, Nuxt, and SvelteKit make this relatively straightforward. With SSR, your server sends fully-rendered HTML on every request — no waiting for JavaScript to execute. Google gets your complete content on the first pass, and AI crawlers see everything too.

If you can't move to SSR, prioritize getting your critical SEO elements into the initial HTML. At minimum, your page title, meta description, canonical URL, and H1 heading should be in the server-rendered HTML — not injected by JavaScript. Many frameworks offer head management utilities that can handle this even in client-side rendered apps.

For internal links, always use proper anchor tags with href attributes instead of JavaScript click handlers. This ensures Google discovers your links during the HTML crawling phase, not just after rendering.

Finally, test regularly. Your site changes over time as you add features and update content. A page that renders correctly for Google today might break after the next deployment. Automated scanning that checks rendering differences on a schedule catches regressions before they hurt your rankings.

The bottom line

The web has moved to JavaScript-heavy applications, but crawlers haven't fully caught up — and AI crawlers haven't caught up at all. The gap between what your users see and what search engines see is where SEO problems hide. The first step to fixing it is knowing the gap exists.

If you want to see exactly what Google sees on your JavaScript site, try a free scan at jsvisible.com. It takes 30 seconds and might surprise you.