Key answer: a scroll-driven 3D website ranks when its meaning lives in crawlable HTML and the WebGL is a decorative layer on top. Search engines render and index the DOM; they do not read pixels inside a canvas. So keep every heading, paragraph, price and link as real, server-rendered HTML, mark the canvas aria-hidden, add Article, Product or FAQ structured data, and make sure the page reads completely with JavaScript disabled. The scroll animation should enhance a document that already communicates fully without it. This guide gives the SEO architecture: the semantic layer, server rendering, structured data, canonical and metadata, and the fast HTML-first loading order that keeps a cinematic page indexable.
Table of contents
- The one rule of 3D SEO
- Why canvas content is invisible to crawlers
- The semantic HTML layer
- Server-render the content
- Structured data for 3D pages
- Metadata, canonical and Open Graph
- HTML-first loading order
- Core Web Vitals with WebGL
- Testing what Google sees
- Accessibility and SEO overlap
- How AETumi builds indexable 3D
- Technical proof on GitHub
- FAQ
- Related resources
- Conclusion
The one rule of 3D SEO
There is one rule that governs SEO for scroll-driven 3D, and everything else follows from it: the meaning of the page must exist in HTML, and the 3D must be enhancement. If a search engine can read your headings, copy, prices and links without executing a single line of WebGL, your 3D scroll site can rank as well as any static page. If the meaning is trapped in the canvas, it cannot.
This is the founding principle of the 3D scroll hub and the reason a cinematic site does not have to sacrifice traffic. The spectacle and the indexability are not in tension; they live in two different layers of the same page.
Why canvas content is invisible to crawlers
A WebGL canvas is a bitmap. Whatever text, product name or price you render inside it is pixels, not markup — there is no DOM node for a crawler to read, no text to extract, no link to follow. Modern search engines execute JavaScript and can see DOM the scene creates, but they cannot read what is painted into a canvas any more than they can read text inside a photograph.
That is the technical fact behind the one rule. Anything that must be found — a product name, a specification, a call to action — cannot live only in the Three.js scene. It has to have a real HTML counterpart, or it does not exist as far as search is concerned.
The semantic HTML layer
Build the page as a complete, semantic HTML document first, then layer the canvas over it. The document should make full sense on its own — proper heading hierarchy, real paragraphs, real links.
<section class="stage">
<canvas id="scene" aria-hidden="true"></canvas>
<div class="content">
<h1>AESPORT carbon running shoe</h1>
<p>A 184-gram racing shoe with a full-length carbon plate. $189.</p>
<a href="/product/aesport">View full specifications</a>
</div>
</section>The canvas is aria-hidden and purely presentational; the heading, description and link are the indexable substance. This separation is the whole architecture — decorative WebGL over a document that stands on its own, exactly how every SEO-conscious 3D component is structured.
Server-render the content
Client-only rendering delays your content behind a JavaScript bundle and, at worst, hides it from crawlers that render inconsistently. Server-render or statically generate the semantic layer so the meaningful HTML is in the initial response, before any WebGL loads.
On a Next.js site this means the headings, copy and product data ship in the server-rendered markup, while the Three.js scene hydrates and mounts the canvas afterward as an enhancement. The crawler — and the human on a slow connection — gets the full content immediately, and the 3D arrives when it is ready. Server rendering the content layer is the single most reliable way to guarantee a 3D page is indexed for what it says.
Structured data for 3D pages
Structured data tells search engines what the page is regardless of how it is presented. A scroll-driven product page should carry Product structured data; an article carries Article; a page with common questions carries FAQPage. This is layer-agnostic — it describes the content, not the canvas.
<script type="application/ld+json">
{ "@context":"https://schema.org", "@type":"Product",
"name":"AESPORT carbon running shoe", "offers":{"@type":"Offer","price":"189","priceCurrency":"USD"} }
</script>Structured data earns rich results and reinforces the semantic layer, and because it lives in the HTML head it is entirely independent of the WebGL. Adding it is a pure win for a 3D page that already keeps its meaning in the DOM, and it composes with the same schema used across interactive websites.
Metadata, canonical and Open Graph
The head metadata does the same job on a 3D page as anywhere: a descriptive title and meta description, a canonical URL to prevent duplication, and Open Graph tags with a real static preview image — because a social crawler cannot screenshot your WebGL. Provide a representative still of the scene as the og:image so shares look right. None of this depends on the 3D; it is the standard SEO surface, and getting it correct matters exactly as much on a cinematic page as on a plain one.
HTML-first loading order
The order things load is an SEO and performance decision. Ship the semantic HTML first so it paints and is parseable immediately, then load the WebGL scene without blocking that content. The heavy Three.js bundle and models should be deferred or lazy-loaded below the initial view, never in the critical path.
<script type="module" src="/scene.js" defer></script> <!-- never blocks the HTML -->An HTML-first order means the page is indexable and readable the instant the server response arrives, with the 3D enhancing progressively. This is also what protects Core Web Vitals, since the content is not waiting on the scene, a discipline enforced on every build delivered for agencies.
Core Web Vitals with WebGL
WebGL can threaten Core Web Vitals if the scene is in the critical path. Keep the largest contentful paint an HTML element — a heading or a static hero image — not the canvas. Reserve space for the canvas so it does not shift layout when it mounts, protecting cumulative layout shift. Defer the scene so it does not compete with content for main-thread time during load. Handled this way, a 3D scroll page can hold green vitals because the metrics measure the fast HTML the visitor sees first, not the enhancement that follows.
Testing what Google sees
Never assume — verify what a crawler actually receives. Use the URL Inspection tool in Search Console to see the rendered HTML and confirm your headings, copy and structured data are present. Disable JavaScript in the browser and reload: the page should still show its complete content. View the server-rendered source to confirm the semantic layer ships before any script. If the content survives all three checks, the WebGL is safely decorative and the page will index for what it says.
Accessibility and SEO overlap
Accessibility and SEO reward the same architecture. An aria-hidden canvas over real HTML is both crawlable and screen-reader friendly; content that never hides behind an animation is both indexable and usable under reduced motion.
if (matchMedia('(prefers-reduced-motion: reduce)').matches) {
renderer.render(scene, camera) // final frame, content already in DOM
}Building the semantic layer for crawlers gives you the accessible baseline for free, and vice versa. The two concerns converge on the same page structure, which is why treating them together is more efficient than chasing either alone.
How AETumi builds indexable 3D
AETumi is an AI-native 3D web platform for production Three.js and WebGL sites, React and Next.js components, and MCP workflows for assistants such as Claude Code. Every AETumi 3D page is built HTML-first: server-rendered semantic content, aria-hidden canvas, structured data, correct metadata, and a deferred scene. Because the pattern is standardized, an indexable 3D page can be scaffolded through an MCP workflow with the SEO architecture in place from the start rather than bolted on after the animation is done.
Technical proof on GitHub
The AETumiApp/threejs-scroll-animation repository shows the aria-hidden canvas layered over a real HTML content block, the concrete shape of the semantic layer this article describes. Use it for the runnable structure and this guide for the full SEO architecture around it.
FAQ
Does a 3D or WebGL website hurt SEO? Not if the meaning stays in HTML. Search engines index the DOM, not pixels in a canvas, so keep headings, copy, prices and links as real server-rendered HTML and mark the canvas aria-hidden. The 3D is decorative and does not affect indexing.
Can search engines read text inside a Three.js canvas? No. A canvas is a bitmap with no DOM nodes, so any text rendered into it is invisible to crawlers, just like text inside an image. Anything that must be found needs a real HTML counterpart.
Should a 3D scroll site be server-rendered? Yes for the content layer. Server-render or statically generate the semantic HTML so it ships in the initial response before any WebGL, guaranteeing crawlers and slow connections get the full content immediately.
What structured data does a 3D product page need? Product structured data with name and offer for a product page, Article for a guide, FAQPage where relevant. It lives in the HTML head, describes the content not the canvas, and earns rich results independent of the 3D.
How do I check what Google sees on my 3D page? Use Search Console URL Inspection to view the rendered HTML, reload with JavaScript disabled to confirm the content still appears, and view server source to confirm the semantic layer ships first. If content survives all three, the WebGL is safely decorative.
Related resources
Continue with the 3D scroll hub, Three.js, React Three Fiber, reusable 3D components, interactive websites, the MCP workflow, and options for agencies.
Conclusion
SEO for a scroll-driven 3D website comes down to one architecture: meaning in server-rendered HTML, spectacle in a decorative canvas. Keep every heading, price and link crawlable, mark the canvas aria-hidden, add structured data, load HTML first, and verify what the crawler sees. Do that and the cinematic page indexes as well as any static one — because search reads the honest document underneath, and the WebGL is simply the layer on top.
More from the AETumi library
Real, production-ready assets — preview the motion, grab the source.