3D website SEO: how to build a Three.js site Google can read
The canvas is invisible to Google: what ranks is the HTML around your 3D. How to build it, load the 3D and audit it in four tests.
BySergio Jáuregui
8 min read
In this article
- Why Google cannot see your canvas
- What a 3D website SEO setup needs in the HTML
- Load the 3D without breaking Core Web Vitals
- Accessibility: the canvas must work unseen too
- When I would skip 3D on a page
- How to audit a 3D site in four tests
- An eight-point checklist for your Three.js website
- Start with the HTML, add the 3D afterwards
3D website SEO is won outside the canvas: Google does not read your Three.js scene, it reads the HTML around it. If that HTML carries real text, headings and links, the 3D adds to the page; if the page is only a canvas, it is born nearly invisible to search. This guide explains how to build that content layer, how to load the 3D without penalizing the page and how to audit the result in four tests.
A word of honesty: there is no universal data on how 3D affects rankings. What follows is method and technical judgment, with one external source cited and qualified.
Why Google cannot see your canvas
A WebGL canvas is a map of pixels painted by the GPU. For the crawler there are no paragraphs, headings or links inside that rectangle. If the main message of a homepage lives only in the 3D scene, the crawler sees an empty page.
The Utsubo guide on SEO for Three.js sites puts it bluntly: the canvas offers nothing readable to the crawler, and the bundle tends to blow through Core Web Vitals budgets. It is vendor content with a commercial interest, so treat it as sensible method rather than measured truth.
The second problem is main-thread cost. Render loops, shader compilation and model parsing all compete with interaction on the same thread. Utsubo notes that the bottleneck is rarely the network. Hence the rule: text, headings and links in server-rendered HTML, and the 3D as a deferred complement with graceful degradation.
On tooling, one clarification: according to the React Three Fiber documentation, performance depends on Three.js and the GPU, with no overhead of its own from the binding. What decides the outcome is how you load the scene and how many frames per second you ask for.
What a 3D website SEO setup needs in the HTML
The content layer is the part that ranks, so you design it first and the 3D second. It should include a single h1 with the main message, one or two paragraphs saying who you are and what you offer, real internal links, metadata per language and structured data. All of it has to arrive in the server HTML, without depending on clicks or client-side loading.
The concrete pieces are well known: metadata with title and description, Open Graph tags, a sitemap listing the URLs of every language and a robots.txt that allows crawling and declares that sitemap. Each language version declares its canonical and its alternates, and the article on hreflang in Next.js covers that part in detail.
A very common mistake is putting text inside modals, tabs or components that only render on interaction. The same goes for button labels that fill in after the component mounts on the client. For a crawler that never interacts, such a page amounts to metadata, one h1 and little else: a brand door, not a content page.
Load the 3D without breaking Core Web Vitals
The 3D bundle is the expensive guest: Three.js, its binding and the model all weigh something, and every kilobyte competes with the first paint. A three-layer strategy works well.
The first layer is deferring the module load: a dynamic import with no server rendering and a loading indicator in the meantime. The HTML arrives first and the scene mounts afterwards.
The second is rendering on demand. A canvas that draws frames in a continuous loop burns battery and CPU even when nobody is watching. Request frames only when something moves, an entrance animation plays or an event fires, and cap the render rate.
The third is offering a low-performance mode that lowers resolution, turns off antialiasing and expensive effects, and asks the GPU for lower power use. That mode is not a failure: it is the version a visitor on a modest phone deserves.
The rest is discipline. The 3D must never block reading, so content and navigation exist before the scene finishes mounting. If the scene arrives empty, a simple fallback avoids a black hole.
It is common for a 3D site to stall at two points: it defers nothing beyond the first paint, and it offers no static image on mobile, which Utsubo also recommends. These are real improvements. Log them as open items rather than counting them as done.
Accessibility: the canvas must work unseen too
Decorative 3D has one advantage: since it carries no unique information, it can be optional as long as the rest of the page works without it. No action should live only inside the canvas. Navigation should be HTML buttons, and modals should be dialogs with managed focus, Escape to close and focus returned to the element that opened them.
Motion needs user control. Read the system reduced-motion preference, react live when it changes and switch off animations and particles while it is active, without forcing a reload. A screen reader reading the HTML without JavaScript should find named buttons: if labels only appear after mounting, the failure is the same server-rendering gap, seen through accessibility.
When I would skip 3D on a page
3D subtracts when a page must persuade with text: a landing page, a pricing page or an article gains nothing from a heavy canvas. It also subtracts for audiences on modest phones or slow networks. A practical rule: if removing the 3D leaves the page just as clear, it goes; if it leaves the page characterless but just as usable, it can stay as a deferred complement.
How to audit a 3D site in four tests
Before deciding what to fix, run four simple tests.
The first is HTML without JavaScript. Turn JavaScript off in the browser and reload. If the headline, the paragraphs, the links and the headings are still there, the content layer exists. If the page is blank or shows only the canvas, that is the problem.
The second is deferred loading. Watch when the content appears and when the scene mounts. Then measure LCP and INP with field data before and after each change, rather than trusting a single lab run.
The third is a real mobile device. Test on an actual phone over a modest connection, and check that the experience degrades gracefully: the page must be readable and navigable even if the 3D is slow or never loads.
The fourth is accessibility. Navigate by keyboard only, with reduced motion turned on, and with a screen reader. Every button needs an accessible name already in the first HTML.
For reference, sergioja.com uses a 3D face as a brand door, and its open items sit exactly on these points: text in the initial HTML and finer deferred loading. What matters is having them identified. The reference implementation covers the whole project.
An eight-point checklist for your Three.js website
Before publishing a Three.js website, check these eight points.
- Your
h1and paragraphs arrive in the server HTML, with no interaction and no wait for the 3D. - Each language has its own URL, a self-referencing canonical and its alternates, with
x-defaultwhere it applies. - The model loads through a dynamic import with no server rendering, and the page serves before the scene finishes.
- The canvas renders on demand or at a capped rate, never in a continuous loop at full resolution.
- A low-performance mode cuts resolution and effects, and it honours the system reduced-motion setting.
- Mobile gets a light path, ideally a static image in place of the animation.
- Every action is reachable without the canvas, by keyboard and screen reader, with accessible names in the first HTML.
- You measure with field data before and after each change, because 3D Core Web Vitals are measured, not opined.
If you miss more than two points, your site is not ready to rank yet: go back to the HTML before polishing the scene.
Start with the HTML, add the 3D afterwards
Working order decides the result. Write the page first as if the 3D did not exist: headline, copy, links, metadata and structured data, all on the server. Then add the scene as a deferred complement, with degradation for weak devices and respect for reduced motion. That order gives you a page that ranks even if the 3D fails, and a memorable experience when it works.
The visual reasoning behind a 3D front door is covered in the article on disruptive web design: a bold form, a clear path to action. And if you want a homepage like this for your project, write to me through the contact page.
Have a project in mind?
I'm Sergio Jáuregui, a Full Stack developer. If you enjoyed this article, take a look at my work or drop me a line.
Keep reading
Engineering and performanceGuide
Next.js revalidateTag: invalidate only what changed in your ISR cache
Time-based revalidate is a floor, not a strategy: tags plus on-demand revalidation refresh only what changed. A working flow, reference code and the traps.
Engineering and performanceGuide
WebP thumbnails with sharp: LRU cache and database trade-offs
Storing images in the database works when the JSON never carries them: on-demand WebP variants with an LRU cache. Sharp design, limits and costs.
Updated on Oct 15, 2026
Back to top