Sitio web 3D SEO: haz que Google lea tu web con Three.js
El canvas es invisible para Google: lo que posiciona es el HTML que acompaña a tu 3D. Cómo construirlo, cargar el 3D y auditarlo en cuatro pruebas.
PorSergio Jáuregui
8 min de lectura
En este artículo
- Por qué Google no ve tu canvas
- Cómo es un sitio web 3D SEO que Google puede leer
- Carga el 3D sin romper los Core Web Vitals
- Accesibilidad: el canvas también se usa sin verlo
- Cuándo no pondría 3D en una portada
- Cómo auditar un sitio 3D en cuatro pruebas
- Lista de comprobación de ocho puntos para tu web con Three.js
- Empieza por el HTML y añade el 3D después
El sitio web 3D SEO se juega fuera del canvas: Google no lee tu escena Three.js, lee el HTML que la acompaña. Si ese HTML tiene texto real, encabezados y enlaces, el 3D suma; si la página es solo un lienzo, nace casi invisible para el buscador. Esta guía explica cómo construir esa capa de contenido, cómo cargar el 3D sin penalizar la página y cómo auditar el resultado en cuatro pruebas.
Una nota honesta: no hay datos universales sobre el efecto del 3D en el posicionamiento. Lo que sigue es método y criterio técnico, con una fuente externa citada y matizada.
Por qué Google no ve tu canvas
Un canvas WebGL es un mapa de píxeles pintado por la GPU. Para el rastreador no hay párrafos, encabezados ni enlaces dentro de ese rectángulo. Si el mensaje principal de una portada vive solo en la escena 3D, el rastreador ve una página vacía.
La guía de Utsubo sobre SEO para sitios Three.js lo formula sin rodeos: el canvas no ofrece nada legible al rastreador y el bundle suele reventar los presupuestos de Core Web Vitals. Es contenido de un proveedor con interés comercial; se toma como método razonable, no como verdad medida.
El segundo problema es el coste del hilo principal. Los bucles de render, la compilación de sombreadores y el procesado de modelos compiten con la interacción por el mismo hilo. Utsubo señala que el cuello de botella rara vez es la red. De ahí la regla: texto, encabezados y enlaces en HTML de servidor, y el 3D como complemento diferido y con degradación.
Sobre las herramientas, conviene aclararlo: según la documentación de React Three Fiber, el rendimiento depende de Three.js y de la GPU, sin sobrecoste propio del binding. Lo que decide es cómo se carga la escena y cuántos fotogramas se piden por segundo.
Cómo es un sitio web 3D SEO que Google puede leer
La capa de contenido es la que posiciona, así que se diseña primero y el 3D después. Debe incluir un único h1 con el mensaje principal, uno o dos párrafos que digan quién eres y qué ofreces, enlaces internos reales, metadatos por idioma y datos estructurados. Todo tiene que llegar en el HTML del servidor, sin depender de clics ni de carga en el cliente.
Las piezas concretas son conocidas: metadatos con título y descripción, Open Graph, un sitemap con las URL de cada idioma y un robots.txt que permita el rastreo y declare ese sitemap. Cada versión idiomática declara su canónica y sus alternos, y el artículo sobre hreflang en Next.js desarrolla esa parte con detalle.
Un error muy habitual es poner el texto dentro de modales, pestañas o componentes que solo se renderizan al interactuar. Lo mismo pasa con las etiquetas de los botones que se rellenan al montar el componente en el cliente. Para un rastreador sin interacción, una página así es metadatos, un h1 y poco más: una puerta de marca, no una página de contenido.
Carga el 3D sin romper los Core Web Vitals
El bundle 3D es el invitado caro: Three.js, su binding y el modelo pesan, y cada kilobyte compite con el primer pintado. Una estrategia en tres capas funciona bien.
La primera es diferir la carga del módulo: importación dinámica sin renderizado en servidor y un indicador mientras tanto. El HTML llega primero y la escena se monta después.
La segunda es renderizar bajo demanda. Un lienzo que dibuja fotogramas en bucle continuo consume batería y CPU aunque nadie lo mire. Conviene pedir fotogramas solo cuando hay movimiento, una animación de entrada o un evento, y limitar la tasa de renderizado.
La tercera es ofrecer un modo de bajo rendimiento que reduzca la resolución, desactive el antialiasado y los efectos costosos, y pida a la GPU un consumo más bajo. Ese modo no es un fallo: es la versión que merece quien navega con un teléfono modesto.
El resto es disciplina. El 3D nunca debe bloquear la lectura, de modo que contenido y navegación existan antes de que la escena termine. Si la escena llega vacía, un respaldo sencillo evita un hueco negro.
Es frecuente que una web 3D se quede a medio camino en dos puntos: no difiere nada más allá del primer pintado y no ofrecen una imagen estática para móvil, que Utsubo también recomienda. Son mejoras reales; conviene anotarlas como pendientes en lugar de darlas por hechas.
Accesibilidad: el canvas también se usa sin verlo
El 3D decorativo tiene una ventaja: como no aporta información única, puede ser opcional siempre que el resto de la web funcione sin él. Ninguna acción debería vivir solo dentro del lienzo. La navegación son botones HTML, y los modales son diálogos con el foco gestionado, cierre con Escape y devolución del foco al elemento que los abrió.
El movimiento necesita control del usuario. Conviene leer la preferencia de movimiento reducido del sistema, reaccionar en vivo a su cambio y desactivar animaciones y partículas cuando está activa, sin obligar a recargar. Un lector de pantalla que lee el HTML sin JavaScript debe encontrar botones con nombre: si las etiquetas aparecen solo tras el montaje, el fallo es el mismo de renderizado en servidor, visto desde la accesibilidad.
Cuándo no pondría 3D en una portada
El 3D resta cuando la página debe convencer con texto: una landing, una página de precios o un artículo no ganan nada con un lienzo pesado. También resta con audiencias en teléfonos modestos o redes lentas. Regla práctica: si quitar el 3D deja la página igual de clara, sobra; si la deja sin carácter pero igual de usable, puede quedarse como complemento diferido.
Cómo auditar un sitio 3D en cuatro pruebas
Antes de decidir qué arreglar, pasa cuatro pruebas sencillas.
La primera es el HTML sin JavaScript. Desactiva JavaScript en el navegador y recarga. Si el titular, los párrafos, los enlaces y los encabezados siguen ahí, la capa de contenido existe. Si la página queda en blanco o solo muestra el lienzo, ese es el problema.
La segunda es la carga diferida. Observa cuándo aparece el contenido y cuándo se monta la escena. Después mide con datos de campo cómo se comportan LCP e INP antes y después de cada cambio, en lugar de fiarte de una sola prueba de laboratorio.
La tercera es el móvil de verdad. Prueba en un teléfono real, con una red modesta, y comprueba que la experiencia se degrada con elegancia: la página debe ser legible y navegable aunque el 3D tarde o no cargue.
La cuarta es la accesibilidad. Navega solo con teclado, con el movimiento reducido activado y con un lector de pantalla. Cada botón necesita un nombre accesible ya en el primer HTML.
Como referencia, sergioja.com usa una cara 3D como puerta de marca, y sus pendientes están justo en estos puntos: texto en el HTML inicial y un diferido más fino. Lo que cuenta es tenerlo identificado. La implementación de referencia recoge el proyecto completo.
Lista de comprobación de ocho puntos para tu web con Three.js
Antes de publicar una web con Three.js, verifica estos ocho puntos.
- El
h1y los párrafos llegan en el HTML del servidor, sin interacción ni espera al 3D. - Cada idioma tiene su URL, su canónica autorreferente y sus alternos, con
x-defaultcuando corresponda. - El modelo se carga con importación dinámica sin renderizado en servidor, y la página se sirve antes de que la escena termine.
- El lienzo renderiza bajo demanda o con una tasa limitada, nunca en un bucle continuo a máxima resolución.
- Existe un modo de bajo rendimiento que reduce resolución y efectos, y respeta el movimiento reducido del sistema.
- En móvil hay una ruta ligera, idealmente una imagen estática en lugar de la animación.
- Toda acción se alcanza sin el canvas, por teclado y con lector de pantalla, con nombres accesibles desde el primer HTML.
- Se mide con datos de campo antes y después de cada cambio, porque los Core Web Vitals del 3D se miden, no se opinan.
Si fallas en más de dos puntos, tu web aún no está lista para posicionar: vuelve al HTML antes de pulir la escena.
Empieza por el HTML y añade el 3D después
El orden de trabajo decide el resultado. Escribe primero la página como si el 3D no existiera: titular, texto, enlaces, metadatos y datos estructurados, todo en el servidor. Después añade la escena como complemento diferido, con degradación para dispositivos débiles y respeto al movimiento reducido. Ese orden da una página que posiciona aunque el 3D falle, y una experiencia memorable cuando funciona.
El criterio visual detrás de una puerta 3D está en el artículo sobre diseño web disruptivo: forma valiente, camino a la acción claro. Y si quieres una portada así para tu proyecto, escríbeme desde la página de contacto.
¿Tienes un proyecto en mente?
Soy Sergio Jáuregui, desarrollador Full Stack. Si te ha gustado este artículo, mira mi trabajo o escríbeme y lo hablamos.
Seguir leyendo
Ingeniería y rendimientoGuía
Next.js revalidateTag: invalida solo lo que cambia en tu caché ISR
El revalidate por tiempo es un suelo, no una estrategia: con etiquetas y revalidación bajo demanda actualizas solo lo que cambió. Flujo, código de referencia y trampas.
Ingeniería y rendimientoGuía
Miniaturas WebP con sharp: caché LRU y el coste de la BD
Guardar imágenes en la BD simplifica la operación si el JSON no las arrastra: variantes WebP bajo demanda con caché LRU. Diseño con sharp, límites y costes.
Actualizado el 15 oct 2026
Volver arriba