Two things get said about 3D websites and search, usually by people selling the opposite thing. The first is that Google cannot rank a WebGL site, so an immersive build costs you your search traffic. The second is that Google runs JavaScript now, so none of it matters. Both are wrong in the same way: they treat the canvas as the page.
A canvas is paint. Nothing rendered inside it is text, a heading, a link or an image with an alt attribute. What Google indexes is whatever exists around the canvas in the document, and whether that exists before or after JavaScript runs decides how reliably it gets there. We build 3D sites, so we measured our own two against that rule. One passes cleanly. The other, we found while writing this, does not, and the fix is below.
What Google actually does with a JavaScript-heavy page
Google's own documentation describes three phases: crawling, rendering and indexing. The crawler fetches the HTML and reads the links in it. Then the page waits: in Google's words, "the page may stay on this queue for a few seconds, but it can take longer than that. Once Google's resources allow, a headless Chromium renders the page." Only then is the rendered result indexed.
So content that only appears after your script runs does get indexed. It gets indexed later, in a second pass, on a budget you do not control. Google's own recommendation is blunt: "server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript." Google does not name the other bots. Anything that reads the first pass only sees what the HTML contains.
Three more lines from the same documentation decide most 3D builds:
- "Google Search does not interact with your page." It does not scroll and it does not click. A scroll-driven story where each scene's copy is created as the camera reaches it is invisible to a crawler that never scrolls. The lazy-loading guidance is that content must load "whenever it is visible in the viewport", not on a user action, and the safe version for copy is simpler still: have it in the document from the start.
- "Don't use URL fragments to load different content." A gallery where every piece lives at
#project-namehas one URL as far as Google is concerned. The scheme that once let fragments be crawled has been deprecated since 2015. If a piece of work should rank, it needs its own address. - "Ensure that your application uses feature detection for all critical APIs" and provide a fallback. Google does not document whether its renderer has a GPU, so the honest position is to treat WebGL as a feature that may be absent. The fallback you show when it is absent is a page Google may be reading. If that fallback is a polite message, the message is your page.
One more, because 3D builds love to do it: setting the title and description from JavaScript once the scene knows where it is. Google's guidance on meta tags says to "avoid using JavaScript to inject or change meta tags whenever possible, and if you must use it, test your implementations thoroughly." Put them in the HTML.
The rule: the HTML is the page, the scene is a layer on it
Everything above reduces to one discipline. Every state of the page you want found must exist as markup before the renderer boots:
- The title, description and canonical in the static
<head>. - An H1 and real copy in the document at load, not typed in, decoded, or revealed by a scroll position.
- Every project, product or service as a real
<a href>to a real URL. Not a fragment, not a click handler. - Structured data in the initial HTML.
- Images that matter as
<img>elements with alt text, outside the canvas, or a static poster of the scene. - A fallback for no-WebGL that is the same page with the decoration removed, not an apology.
The canvas then sits on top of a page that was already complete. That is not a compromise on the experience. It is the same architecture the best immersive sites use, and it is why they rank. If you are still deciding whether the scene is worth building at all, why immersive design wins is the case for it; this article is the condition attached.
Measured on our own site
We loaded both of our 3D pages in headless Chrome twice, once with JavaScript disabled and once with it enabled and the scene fully booted, and counted what a reader could see: visible words, links, headings and structured data. The counts are exact for 11 September 2026 and for that method. They describe what the two indexing passes have available; they are not a claim about what Google's index holds.
The homepage. With JavaScript off: 1,113 words, 37 links, one H1, eleven H2s and the structured data block. With JavaScript on: 1,121 words and the same 37 links. Rendering added eight words, which is the Dubai clock. The 3D hero, the glass logo and the tunnel of project cards are a layer over a page that is complete before a single script runs. This is the rule working.
The gallery. With JavaScript off: 27 words and 21 links, all of them navigation and footer. With JavaScript on: 939 words, 70 links, and 51 project titles. The whole portfolio index exists only after a script builds it, and once built it is hidden from sighted visitors, present for screen readers and crawlers. It works, in the sense that the page is indexed on its title, description, heading and structured data, and Google does render JavaScript. But 912 of its 939 words are second-pass content, and the 51 pieces are reached through fragment links that Google treats as one URL. The titles carry less weight than they should, and no individual piece can rank, because none of them has an address.
We did not know that until we counted. The fix is mechanical: the index is a list, a list does not need a script, so it is being baked into the HTML at build time, and the fragment links stay as a convenience rather than the only way in. The general lesson is the useful part: you cannot see this by looking at the page. The gallery looks complete. It has to be measured with the script turned off.
Performance is the other half of the same rule
Google says good Core Web Vitals, "along with other page experience aspects, aligns with what our core ranking systems seek to reward." A 3D page is where those numbers go wrong first: a multi-megabyte scene that blocks the largest paint, and a render loop that keeps the main thread busy so every tap waits. We have written up what actually slows a 3D site down, with numbers from our own build, and why INP fails pages that passed every other test. The short version: the copy must paint before the scene, the scene must never hold the main thread, and quality must adapt to the device rather than assume a desktop GPU.
What this means for AI search
Google's guidance on AI features says there are "no additional requirements to appear in AI Overviews or AI Mode." Those features issue many searches for one question and then show "a wider and more diverse set of helpful links" than a classic result page. The links they pick from are the ones the crawler could read. A 3D site that keeps its substance in the HTML layer is eligible in exactly the same way as any other page; one that keeps it in the canvas is not in the pool. We covered the wider point in why there is no "AI SEO".
Check your own site in ten minutes
- Turn JavaScript off and reload. What survives is the first pass. If your headline, your copy and your links are gone, so is most of your page for any crawler that stops there.
- Inspect the rendered version. Google's advice for JavaScript sites is to "use the Rich Results Test or the URL Inspection Tool in Search Console" to see the page as it renders it. Compare it to what you meant to publish.
- Count the URLs. Every piece of work you want found should have its own path. Anything after a
#does not count. - Break WebGL on purpose, or load the page on a machine without it. Is the fallback a page or a message?
- Read the Core Web Vitals report in Search Console for the 3D pages specifically, on mobile. That is where the ranking cost of a heavy scene shows up.
The short version
- Google indexes the HTML around a canvas, never the canvas. Rendering adds JavaScript-built content later, on Google's budget.
- Copy, links, headings, meta and structured data belong in the static HTML. The scene is a layer on a finished page.
- Fragments are not URLs. Scrolling and clicking never happen. Feature-detect WebGL and make the fallback the real page.
- Our homepage passes the test. Our gallery kept its 51-piece index in a script, and now will not.
Building something immersive and want it found as well as remembered? That is the exact brief of our immersive 3D work, and the gallery is what it looks like in practice. Send us the project and we will tell you what needs to exist in the HTML before the scene ever loads.