Guía de SEO técnico Web3 2026: dApps, Core Web Vitals y renderizado JS

Core Web Vitals en dApps

Los sitios Web3 fallan consistentemente Core Web Vitals por los SDKs de wallet-connect, tickers de precio en vivo y UIs de dApp pesadas en imágenes. Los targets son no-negociables.

Objetivos 2026: LCP por debajo de 2,5 segundos, CLS por debajo de 0,1, INP por debajo de 200ms. Son los umbrales de Google. Los datos de campo (usuarios reales) importan más que los de laboratorio (sintéticos).

Lo que mata el LCP en Web3: hero images served from IPFS (slow gateway), large logo files (often 200KB+ SVG), heavy CSS bundles (Tailwind shipped uncompiled). Fix: cache hero images to fast CDN, optimize logo to under 20KB, compile and tree-shake CSS.

Lo que mata el CLS en Web3: modales de wallet-connect que cargan tarde y desplazan el layout, tickers de precios en vivo que se renderizan de forma asíncrona, tablas de tickers con filas de distintas alturas. Solución: reserva espacio con min-height, difiere wallet-connect hasta después del first contentful paint y usa skeleton loaders.

Lo que mata el INP en Web3: SDKs de wallet-connect (el peor culpable), desplegables pesados de selección de cadena, JS de tickers que se ejecuta en cada render. Solución: carga en diferido el SDK de la wallet, aplica debounce a los handlers de input, virtualiza listas largas y difiere el JS no crítico.

La solución específica para wallet-connect: no inicialices wallet-connect al cargar la página. Inicialízalo al hacer clic en el botón de conectar. Usa import dinámico. Ahorra 200-400ms de TBT (Total Blocking Time), lo que mejora el INP directamente.

Herramientas de datos de campo: Chrome User Experience Report (CrUX) a través de PageSpeed Insights. Datos reales de tus visitantes. Los datos de laboratorio sirven para depurar, pero Google posiciona según los datos de campo.

Renderizado JS: SSR, SSG y CSR

La mayoría de dApps usan renderizado del lado del cliente y pierden 60-80% del contenido crawleable como resultado. Elige estrategia de renderizado por tipo de página.

SSG (generación de sitios estáticos): for marketing pages, blog posts, documentation. Pre-rendered at build time. Fast, fully crawlable, easy to validate. Use Next.js, Astro, Hugo or similar.

SSR (renderizado del lado del servidor): para contenido dinámico que cambia en cada petición. Dashboards personalizados (cuando no están tras un muro de autenticación), páginas de datos en vivo. Contrapartida: TTFB más lento, pero rastreabilidad completa.

ISR (Incremental Static Regeneration): para páginas con actualizaciones periódicas (páginas de líderes por TVL que se actualizan a diario). Genera HTML estático pero lo revalida según un calendario. Lo mejor de ambos mundos para contenido que cambia cada hora o cada día.

CSR (renderizado del lado del cliente): for app UIs behind auth walls. The actual dApp interface. Google doesn't need to crawl this. Keep separate from marketing site.

The split-domain pattern: example.com as the SSG/SSR marketing site (fully crawlable), app.example.com as the CSR dApp (not crawled). Most successful Web3 projects use this split.

Qué rompe el CSR: contenido que requiere interacción del usuario para mostrarse (pestañas, acordeones en la primera carga), contenido que se carga en diferido al hacer scroll (contenido crítico bajo el pliegue), contenido que requiere JS para montarse (texto en un useEffect de React). El rastreador de Google renderiza JS, pero con retrasos e inconsistencias.

Test render output: use Google's URL Inspection tool in Search Console to see what Google sees when rendering your page. Comparar to your visible content. Gaps reveal CSR problems.

Rendimiento del SDK de wallet

Los SDKs de wallet-connect son el mayor killer de INP por sí solo en sitios de marketing de dApp. La mayoría de equipos los envían en cada página incluso cuando no son necesarios.

El error por defecto: inicializar WalletConnect, RainbowKit o wagmi al cargar la página, incluso en páginas de marketing donde los usuarios no conectarán wallets. Añade 200-400KB de JS más la sobrecarga en tiempo de ejecución.

El patrón de carga diferida: inicializa el SDK de la wallet solo cuando el usuario hace clic en el botón de conectar. Usa import dinámico: const wallet = (await import('@wagmi/core')).default. Reduce la carga inicial de JS en un 90%.

The route-based loading pattern: carga el SDK de la wallet solo en las rutas donde se necesita conexión (/app/, /dashboard/, etc.). Las páginas de marketing (/, /about/, /blog/) lo omiten por completo.

The popular SDK comparison: RainbowKit (~250KB), Web3Modal (~180KB), wagmi (~120KB), ethers.js (~90KB). All have lazy-load patterns. Use the lightest one your dApp supports.

Qué diferir: la lógica de detección de cadena, la reconexión automática de la wallet al recargar y la consulta de saldos. Nada de esto necesita ejecutarse en páginas de marketing. Difiérelo hasta la interacción del usuario o a rutas específicas.

The Web3 modal alternative: for sites that just need a single "Connect Wallet" button on landing pages, use a lightweight custom modal that lazy-loads the actual wallet provider on click. 5KB instead of 250KB.

Estrategia de IPFS, Arweave y CDN

El almacenamiento descentralizado es excelente para la permanencia de contenido y malo para el performance de crawl SEO. La corrección es hosting dual.

The IPFS problem: public gateways (ipfs.io, cf-ipfs.com) timeout for SEO crawlers about 40% of the time. Google's crawler waits ~3 seconds. IPFS often takes 5-8 seconds for first byte. Result: og:image gets discarded, image not indexed.

El patrón de doble alojamiento: primary asset on IPFS or Arweave (for permanence). Cached 1200x630 PNG version on fast CDN (Cloudflare R2, Cloudinary, Vercel Image Optimization). og:image points to CDN, on-chain references stay IPFS.

The CDN choice: Cloudflare R2 (plan gratuito, compatible con S3, CDN rápida). Cloudinary (transformaciones de imagen incluidas, plan gratuito). Vercel Image Optimization (si alojas en Vercel). Todos funcionan; elige según tu stack actual.

El patrón /assets/: sirve todas las imágenes críticas para SEO desde /assets/images/og/ en tu CDN rápida. Reserva los hashes de IPFS para el arte NFT real referenciado desde los contratos.

Arweave specifics: los gateways de Arweave son más rápidos que los de IPFS, pero siguen siendo más lentos que las CDN. Aplica el mismo patrón de doble alojamiento.

The DDoS risk: los gateways públicos de IPFS tienen fuertes límites de tasa. No dependas de ellos para tráfico de producción. Monta tu propio gateway o usa Pinata, Filebase o un servicio de pinning similar con una CDN delante.

Mobile-first para Web3

El índice mobile-first de Google usa un perfil de teléfono Android económico. La mayoría de sitios Web3 se prueban en laptops de dev. El mismatch causa problemas de ranking.

La trampa del portátil de desarrollo: your MacBook Pro M3 renders complex JS in 50ms. Google's crawler simulates a Moto G Power (Android, 4 years old). 200ms of JS on your laptop is 2 seconds on the budget phone.

Qué se rompe en móviles reales: modales de wallet-connect (a menudo diseñados solo para escritorio), desplegables de selección de cadena (no caben en viewports pequeños), tablas de tickers con demasiadas columnas, interacciones que solo funcionan con hover.

The 375px viewport test: Chrome DevTools device toolbar set to iPhone SE. Test every key page. Look for layout breaks, hidden interactions, inaccessible elements.

Pruebas en dispositivos reales: consigue un Android económico ($150 usado) para pruebas. Las redes móviles reales limitan aún más. Lo que funciona en DevTools puede fallar igualmente en un móvil real.

Tamaño de los objetivos táctiles: objetivos táctiles de mínimo 48x48px. Los modales Web3 suelen tener botones de cierre de 24px. Google lo marca como problema de accesibilidad y baja el ranking móvil.

Imágenes responsive: use srcset for different viewport sizes. Don't serve a 1200x630 hero image to a 375px viewport. Save bandwidth, improve LCP.

Control de indexación

La mayoría de sitios Web3 tienen bloat de indexación. Search Console muestra 4,000 páginas indexadas cuando 200 son útiles. Desperdicia presupuesto de crawl.

Fuentes habituales de inflación: URLs con parámetros (?ref=, ?utm_, ?show=), combinaciones de filtros (/products?category=defi&sort=tvl), paginación (page=1, page=2), páginas de resultados de búsqueda (?q=), IDs de sesión.

The robots.txt fix: bloquea los patrones de parámetros. Disallow: /*?ref= y Disallow: /*?utm_ cubren la mayoría de los parámetros de marketing. Disallow: /*?show= para los problemas habituales del tema Discy.

La corrección con la etiqueta canonical: for parameter variations of the same content (filtered views), set canonical to the parent unparameterized URL. Google consolidates ranking signals.

The noindex pattern: for thin pages that must remain accessible (filtered views with 0 results, thank-you pages), use meta robots noindex. Don't block in robots.txt because Google needs to crawl to see noindex.

Disciplina de sitemap: incluye solo las páginas que quieres indexar. Si tu sitemap tiene 4.000 URLs pero solo 200 son valiosas, Google desperdicia presupuesto de rastreo en el relleno.

Search Console diagnostics: revisa el informe de cobertura del índice. Busca "Descubierta: actualmente sin indexar" (Google la encontró pero la omitió) y "Rastreada: actualmente sin indexar" (Google la renderizó pero la omitió). Ambas señalan problemas de indexación.

Estrategia de sitemap para sitios Web3

Mapa del sitio.xml es el control de SEO técnico más pasado por alto por sí solo. La mayoría de sitios Web3 tienen uno pero nunca lo envían.

La lista obligatoria: incluye cada página que quieras indexar. Excluye URLs con parámetros, páginas de resultados de búsqueda y archivos de etiquetas con contenido escaso. Calidad antes que cantidad.

Metadatos por URL: lastmod (fecha de última modificación, ISO 8601), priority (0.0-1.0, según importancia), changefreq (daily/weekly/monthly). La mayoría de los equipos los configura mal o los omite por completo.

El paso de envío: Google Search Console > Mapa del sitios > Add new sitemap. Bing Webmaster Tools > Mapa del sitios > Submit sitemap. Sobre nosotros 30% of crypto sites have sitemap.xml but never submit. Indexation 4-6 weeks slower without explicit submission.

Multi-sitemap pattern: for sites with 1000+ URLs, split into multiple sitemaps (sitemap-pages.xml, sitemap-blog.xml, sitemap-comparisons.xml) and reference from sitemap_index.xml. Easier to maintain, faster to crawl.

The robots.txt link: add "Mapa del sitio: https://example.com/sitemap.xml" line to robots.txt. Ayudas non-Google crawlers (Bing, AI engines) find sitemap without explicit submission.

Actualízalo periódicamente: regenera el sitemap en cada deploy. Los sitemaps desactualizados, sin el contenido reciente, ralentizan la indexación de páginas nuevas.

Patrones de redirecciones y migración

Los proyectos Web3 hacen rebrand y migran frecuentemente. Los redirects malos destruyen ranking. Los redirects buenos lo preservan.

The 301 vs 302 question: 301 (permanente) para cambios reales de URL. 302 (temporal) para redirecciones de corto plazo. Usa 301 en migraciones. Los 302 no transmiten toda la señal de ranking.

Redirect chains: A → B → C kills ranking. Always redirect direct: A → C. Audit your redirects for chains and flatten them.

Domain migration playbook: 1) Configura redirecciones 1:1 de cada URL antigua → URL nueva, 2) Actualiza las etiquetas canonical en las URLs nuevas, 3) Envía el nuevo sitemap, 4) Usa la herramienta de cambio de dirección en GSC, 5) Actualiza los enlaces internos para que apunten directamente a las URLs nuevas (no vía redirecciones), 6) Espera 90 días para la migración completa.

La cuestión del www y la barra final: elige una (p. ej., https://www.example.com/page/ con barra final) y aplica 301 a todas las variantes hacia esa forma canónica. Las señales mixtas de tener /page y /page/ activas a la vez dividen el ranking.

HTTPS migration: if still on HTTP, migrate to HTTPS yesterday. 301 all HTTP URLs to HTTPS equivalents. HTTP-only sites get demoted aggressively in 2026.

5 errores de SEO técnico

Patrones recurrentes de auditorías Web3.

Error 1: SDK de wallet en todas las páginas. Inicialízalo al hacer clic. Ahorra 200-400KB.

Mistake 2: IPFS-served og:image. Los crawlers agotan el tiempo de espera. Cachea en un CDN rápido.

Error 3: sitemap no enviado. El 30% de los sitios omite esto. Indexación 4-6 semanas más lenta.

Error 4: probar móvil solo en el laptop de desarrollo. Consigue un teléfono Android económico para pruebas reales.

Error 5: mezclar http/https o www/sin www. Elige una forma canónica y haz 301 del resto.

Herramientas para SEO técnico Web3

Lo que realmente uso.

Módulo de SEO técnico de Crawlux para auditorías con conocimiento cripto.

Google Search Console + Bing Webmaster Tools para indexación y rendimiento. Gratis.

PageSpeed Insights para datos de laboratorio y de campo de Core Web Vitals. Gratis.

Screaming Frog para auditorías de rastreabilidad. Gratis hasta 500 URLs.

WebPageTest para depuración avanzada de rendimiento. Gratis.

Lighthouse CI para pruebas automáticas de regresión de CWV en cada deploy.

Cómo Crawlux encaja en SEO técnico

El módulo de SEO técnico cubre los patrones de arriba.

Core Web Vitals audit: datos de campo y de laboratorio con detección de problemas específicos de Web3 (peso del wallet SDK, rendimiento del gateway IPFS).

JS rendering check: compara el HTML renderizado en el cliente con el HTML inicial para señalar contenido solo CSR.

Indexation audit: detecta exceso de URLs con parámetros, canonicals faltantes y cadenas de redirecciones.

Mobile-first check: simula el perfil del crawler mobile-first de Google.

Validación de sitemap y robots.txt: verifica que ambos estén bien configurados y enviados.

Plan gratuito: módulo de SEO técnico en un dominio. Detalles del módulo.

Plan de acción de SEO técnico a 60 días

En orden.

Días 1-7: línea base de auditoría. Run Crawlux SEO técnico audit. Document Core Web Vitals (field data), indexation state, redirect chains.

Días 8-21: correcciones de CWV. Lazy-load wallet SDKs. Cache IPFS images to CDN. Optimize LCP elements. Reduce CSS bundle.

Días 22-35: renderizado JS. Move marketing pages to SSG/SSR. Test render output via GSC URL Inspection. Fix CSR-only content gaps.

Días 36-50: limpieza de indexación. Block parameter patterns in robots.txt. Add canonicals to filter URLs. Noindex thin pages. Regenerate sitemap and submit.

Días 51-60: móvil y validación. Test on real budget Android. Fix layout breaks. Run Lighthouse CI on key pages. Re-audit and compare to baseline.

Del roster de clientes de TG3

Audita tu sitio contra esta guía

Los módulos de auditoría de Crawlux abajo prueban patrones específicos de esta guía en tu sitio automáticamente.

Sobre AB

Compara pares específicos de SEO técnico

Comparaciones head-to-head detalladas para los protocolos, proyectos y herramientas cubiertos en esta guía.

Fuentes y metodología

Esta guía sintetiza los hallazgos de más de 200 auditorías de sitios Web3 realizadas en TG3 Agency desde 2017, además de datos públicos verificados con las fuentes indicadas abajo. Última verificación 3 de mayo de 2026.

• [01]DefiLlama · TVL, volumen y métricas de protocolos
• [02]CoinGecko · Precio de tokens, oferta y datos de mercado
• [03]Schema.org · Especificación de datos estructurados
• [04]Google Search Central · Guía de implementación de datos estructurados

Esta guía es con fines informativos. El panorama del SEO crypto cambia rápido. Vuelve a ejecutar auditorías trimestralmente.

¿Tienes feedback o una opinión distinta?

Deja tu perspectiva abajo. Leemos cada comentario.