Is WebGL bad for SEO? Only if the content lives inside the canvas
WebGL isn’t bad for SEO by nature, but a WebGL site built the usual way is close to invisible to search and AI — and the reason is structural. WebGL and Three.js render their visuals on the GPU inside a <canvas> element, which holds no text a crawler can read. So if the value of your page lives inside the canvas — the product reveal, the scroll-driven story, the immersive intro — none of it gets indexed, because search engines and AI crawlers read the HTML, not the GPU’s output. On top of that, 3D ships heavy JavaScript: Three.js alone is around 600 KB before your scene, and a full experience can blow past several megabytes, wrecking your Core Web Vitals. And AI search is even less forgiving than Google, because the crawlers behind ChatGPT and Perplexity don’t run JavaScript at all, so a canvas-only site is invisible to them entirely. The fix is not to avoid WebGL but to build it dual-layer: render your real content as HTML first, with the 3D scene as a visual layer on top, so the headline, copy, links and structured data exist in the source whether or not the 3D ever loads. Done that way, an immersive site ranks fine and stays accessible. The honest question underneath is whether you need WebGL at all — many sites get a premium, tactile feel from lighter CSS textures and bold typography that cost a fraction of the weight and stay fully readable. Reserve the canvas for when the immersion is genuinely the point, and build it HTML-first even then.
Why a canvas is invisible: it renders on the GPU, not the DOM
The core issue is simple once you see it. WebGL and Three.js draw their scene on the graphics processor and paint the result onto a single <canvas> element. That canvas contains no headings, no paragraphs, no links — just a rectangle of pixels. So when a crawler fetches your page and reads the source, it finds a canvas tag and some script files where your content should be (Utsubo, 2026). If your product name, description, and calls to action live inside the 3D experience, there is quite literally nothing for a search engine to index.
This trips up teams who assume that because Google can render JavaScript, it will handle 3D. Google renders the JavaScript, but it indexes the DOM — the page’s document structure — not the GPU’s output buffer, so content that only exists as rendered 3D never makes it into the index. Flutter’s web renderer hits the identical wall: a CanvasKit page reduces to a near-empty <body> with a single canvas inside, containing zero indexable text and zero crawlable links, which makes it invisible to standard text-based indexing (Codesol, 2026). The pattern is the same whatever draws the canvas: if the words aren’t in the HTML, they don’t exist for search.
The weight problem: Three.js and the Core Web Vitals hit
Even setting indexing aside, 3D is expensive to load. Three.js core ships around 600 KB minified before you add your own scene code, and once you bring in helpers, post-processing effects and a 3D model file, you’re routinely past 3 MB before any styling (Utsubo, 2026). The result is predictable: Largest Contentful Paint blown, Interaction to Next Paint pegged, and a Lighthouse performance score in the 30s, with the bottleneck usually being the main thread rather than the network (Utsubo, 2026).
That matters because Core Web Vitals are a ranking input, so a heavy 3D site pays twice — once in the content search can’t read, and again in the speed scores that drag down what it can. None of this is unfixable: progressive loading, zone-based asset streaming, compressed model formats, and moving rendering off the main thread all help keep initial loads reasonable. But those are deliberate engineering choices, and the honest starting point is that heavy 3D and strong Core Web Vitals pull in opposite directions until you do the work to reconcile them.
AI search is even less forgiving
If Google is a demanding audience for a 3D site, AI search is a stricter one. The crawlers behind ChatGPT, Claude and Perplexity don’t execute JavaScript at all — a study of over 500 million crawler fetches found zero JavaScript execution — so where Google will at least render your scene and see the empty DOM, AI crawlers never even get that far (Averi, 2026). They also weight page speed and structured data more heavily than traditional search and prefer answers they can extract verbatim from indexable HTML (Utsubo, 2026).
Put together, that means a WebGL site without server-rendered fallback content and schema markup is often invisible to AI search entirely (Utsubo, 2026). It’s the same rendering gap that swallows JavaScript-built sites in our guides on Lovable and Weglot — a canvas is just the most extreme version of it, because there isn’t even hidden text to find. For any brand that wants to be cited when someone asks an AI assistant a question, the visual experience can’t be the only thing on the page.
The fix: dual-layer, HTML-first
The good news is that the solution is well understood and doesn’t require giving up the 3D. It’s called progressive enhancement, or a dual-layer architecture: render all your real content server-side as semantic HTML, then treat the WebGL canvas as a visual layer that sits on top of it (Utsubo, 2026). The hero copy, the H1, the product description, the links and the structured data all exist in the DOM whether the 3D ever loads or not. Search engines and AI crawlers read the content; humans experience the environment. Frameworks built for content-first output — Astro, and others with static generation or server rendering — make this the natural path rather than a fight (Codesol, 2026).
Two details make it solid. First, put a fallback inside the canvas wrapper containing the same headline, summary and call to action the 3D communicates — this doubles as your accessibility floor, since a screen reader and a crawler both benefit from the same real text. Second, if the 3D powers something functional like a configurator or interactive map, generate one indexable URL per meaningful state rather than hiding every variation behind a client-only interaction (Utsubo, 2026). Built this way, immersive sites participate fully in search and AEO — the HTML provides the signals machines need, and the canvas provides the experience people remember.
The honest question: do you even need WebGL?
Before any of that, though, the most useful question is whether the canvas earns its place at all. It’s easy to reach for 3D because it’s impressive, but it carries real, ongoing costs in performance, accessibility and engineering time, and for many sites those costs buy less than the demo suggests. A respected 3D studio put the honest version plainly: if load time and maximum device support are your highest priorities, you shouldn’t use WebGL at all — and their own JavaScript-and-WebGL-heavy site still renders without JavaScript, because they build the content layer first and add the effects second (14islands, 2022).
The 2026 design conversation has shifted toward exactly this restraint. Many studios are now producing a premium, tactile feel with far lighter techniques — CSS noise and grain that fake physical depth without the processor lag of heavy WebGL, viewport-scaled kinetic typography that carries the visual weight a hero image used to, and considered motion — all of it running on AI-readable HTML foundations (Fireart, 2026). These approaches keep pages light, which also keeps them low-carbon, a connection our guide on a website’s carbon footprint draws out: the same weight that hurts your speed and your rankings hurts the planet. Often the differentiated, memorable result doesn’t need a canvas at all.
When immersive 3D is worth it — done right
None of this is an argument against WebGL. It’s genuinely the right tool when the immersive experience is the product — a luxury launch, a spatial product configurator, an interactive story where exploration is the point — and the audience and hardware justify it. WebGL now has near-universal browser support, and the Three.js ecosystem has matured into a production-grade platform, so the technology is dependable (Digital Strategy Force, 2026). The question was never whether it works; it’s whether it’s built so the rest of the web can still read the page.
So the arbiter’s answer to “is WebGL bad for SEO” is: no, not if you build it HTML-first, and yes, badly, if you let the canvas be the page. The dividing line is architecture. A 3D site with real content in the source, schema in the head, a <noscript> fallback, and a performance budget is stunning and rankable and accessible. A 3D site that renders its meaning only on the GPU is a sealed box to every machine that reads the web. That’s the same “make it readable on purpose” discipline our pillar on being readable by AI applies to every site — the canvas just raises the stakes.
What we’d tell you
If you already have a WebGL site and traffic is thin, run the two-minute test: view your page source and disable JavaScript. If your headline, copy and links vanish, that’s exactly what search engines and AI crawlers see, and the fix is to render that content server-side with the 3D layered on top rather than as the page itself. If you’re considering an immersive build, start from the goal, not the effect: decide what the content needs to say and get it into readable HTML, then ask whether 3D genuinely serves the experience or whether lighter accessible, faster techniques get you there for a fraction of the cost.
Our bias is toward the lightest thing that achieves the goal, because a page that does less is faster, more accessible, lower-carbon and more readable to both people and machines — and where genuine immersion is the goal, we build it dual-layer so you never trade being found for being beautiful. You shouldn’t have to choose between a site that impresses a visitor and a site that a search engine or an AI can actually read. Built right, it’s the same site.
Frequently asked
- Is WebGL bad for SEO?
- Not inherently — but a WebGL site built the naive way is close to invisible to search engines and AI. The problem is that WebGL and Three.js render their visuals on the GPU inside a canvas element, which contains no text a crawler can read. If your headline, copy and product details live only inside that 3D scene, search engines and AI crawlers see an empty page. WebGL also tends to ship heavy JavaScript that wrecks your Core Web Vitals. The fix is not to avoid WebGL but to build it as a layer on top of real, server-rendered HTML, so the content is fully indexable and the 3D is an enhancement rather than the whole page. Done that way, an immersive site can rank fine; done naively, it disappears.
- Why can't Google index my Three.js or 3D site?
- Because a canvas element has zero indexable text. WebGL and Three.js paint pixels on the GPU rather than writing content into the page's HTML, so when a crawler reads your source it finds a canvas tag and script files, not your headings, paragraphs or links. Google can execute JavaScript, but even it indexes the DOM, not the GPU's output buffer, so content that exists only as rendered 3D is invisible. The solution is server-side rendering or static generation of all your real text content, with the WebGL scene layered on top — search engines index the HTML while people experience the 3D.
- Does WebGL hurt Core Web Vitals?
- Usually, yes, unless you engineer around it deliberately. Three.js core alone is around 600 KB minified before you add your scene code, models and textures, and a full 3D experience can push a page past several megabytes, which blows Largest Contentful Paint, pegs Interaction to Next Paint, and can drop a Lighthouse performance score into the 30s. The bottleneck is usually the main thread rather than the network. You can mitigate it with progressive loading, compressed models, off-main-thread rendering and a static fallback, but the honest starting point is that heavy 3D and good Core Web Vitals are in tension, and closing that gap is real engineering work.
- Is WebGL invisible to AI search too?
- More so than to Google. AI crawlers behind ChatGPT, Claude and Perplexity don't execute JavaScript at all, and they weight speed and structured data heavily while preferring content they can extract as text. A WebGL site whose content lives in the canvas, with no server-rendered fallback and no schema, is often invisible to AI search entirely — worse off than with Google, which at least renders JavaScript. If being cited in AI answers matters to you, the dual-layer approach isn't optional: your real content and structured data must exist in the HTML before any 3D loads.
- Do I even need WebGL for my site?
- Often not, and that's worth sitting with before you commit. Immersive 3D is powerful for brands competing on experience, but it carries real costs in performance, accessibility and build complexity. In 2026 many studios are getting a premium, tactile feel with far lighter techniques — CSS textures and grain, bold viewport-scaled typography, and considered motion — that cost a fraction of the weight and stay fully readable. As one respected 3D studio puts it, if load time and broad device support are your priorities, you may be better off not using WebGL at all. Reserve it for cases where the immersive experience is genuinely the point, and build it HTML-first even then.