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.

2026 targets: LCP under 2.5 seconds, CLS under 0.1, INP under 200ms. Google's thresholds. Field data (real users) matters more than lab data (synthetic).

LCP killers in 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.

CLS killers in Web3: wallet-connect modals that load late and shift layout, live price tickers that render asynchronously, ticker tables that render rows with different heights. Fix: reserve space with min-height, defer wallet-connect to after first contentful paint, use skeleton loaders.

INP killers in Web3: wallet-connect SDKs (the worst offender), heavy chain-selector dropdowns, ticker JS that runs on every render. Fix: lazy-load wallet SDK, debounce input handlers, virtualize long lists, defer non-critical JS.

The wallet-connect specific fix: don't initialize wallet-connect on page load. Initialize on click of the connect button. Use dynamic import. Saves 200-400ms of TBT (Total Blocking Time) which improves INP directly.

Field data tools: Chrome User Experience Report (CrUX) via PageSpeed Insights. Real user data from your visitors. Lab data is useful for debugging but field data is what Google ranks on.

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 (Static Site Generation): 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 (Server-Side Rendering): for dynamic content that changes per-request. Personalized dashboards (when not behind auth wall), live data pages. Trade-off: slower TTFB but full crawlability.

ISR (Incremental Static Regeneration): for pages with periodic updates (TVL leader pages updating daily). Generates static HTML but revalidates on a schedule. Best of both worlds for content that changes hourly/daily.

CSR (Client-Side Rendering): 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.

What breaks CSR: content that requires user interaction to reveal (tabs, accordions on first load), content that lazy-loads on scroll (below-the-fold critical content), content that requires JS to mount (text in React useEffect). Google's crawler renders JS but with delays and inconsistencies.

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.

Performance de 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.

The default mistake: initializing WalletConnect, RainbowKit or wagmi on page load even on marketing pages where users won't connect wallets. Adds 200-400KB JS plus runtime overhead.

The lazy-load pattern: only initialize wallet SDK when user clicks the connect button. Use dynamic import: const wallet = (await import('@wagmi/core')).default. Reduces initial JS payload by 90%.

The route-based loading pattern: only load wallet SDK on routes where wallet connection is needed (/app/, /dashboard/, etc.). Marketing pages (/, /about/, /blog/) skip it entirely.

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.

What to defer: chain detection logic, wallet auto-connect on page reload, balance fetching. None of this needs to run on marketing pages. Defer to user interaction or specific routes.

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.

The dual-hosting pattern: 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 (free tier, S3-compatible, fast CDN). Cloudinary (image transformations included, free tier). Vercel Image Optimization (if hosting on Vercel). All work; pick based on existing stack.

The /assets/ pattern: serve all SEO-critical images from /assets/images/og/ on your fast CDN. Reserve IPFS hashes for actual NFT artwork referenced from contracts.

Arweave specifics: Arweave gateways are faster than IPFS gateways but still slower than CDNs. Same dual-hosting pattern applies.

The DDoS risk: public IPFS gateways are heavily rate-limited. Don't rely on them for production traffic. Run your own gateway or use Pinata, Filebase or similar pinning service with CDN front.

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.

The dev laptop trap: 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.

What breaks on real mobile: wallet-connect modals (often desktop-only design), chain-selector dropdowns (don't fit small viewports), ticker tables with too many columns, hover-only interactions.

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

Real device testing: get a budget Android phone ($150 used) for testing. Real mobile networks throttle further. What works in DevTools may still fail on actual mobile.

Touch target sizing: minimum 48x48px tap targets. Web3 modals often have 24px close buttons. Google flags this as accessibility issue and demotes mobile ranking.

Responsive images: 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.

Common bloat sources: parameterized URLs (?ref=, ?utm_, ?show=), filter combinations (/products?category=defi&sort=tvl), pagination (page=1, page=2), search result pages (?q=), session IDs.

The robots.txt fix: block parameter patterns. Disallow: /*?ref= and Disallow: /*?utm_ catch most marketing parameters. Disallow: /*?show= for common Discy theme issues.

The canonical tag fix: 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.

Mapa del sitio discipline: only include pages you want indexed. If your sitemap has 4,000 URLs but only 200 are valuable, Google wastes crawl budget on the bloat.

Search Console diagnostics: check the Index Coverage report. Look for "Discovered, currently not indexed" (Google found but skipped) and "Crawled, currently not indexed" (Google rendered but skipped). Both signal indexation issues.

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.

The mandatory list: include every page you want indexed. Exclude parameterized URLs, search result pages, tag archive pages with thin content. Quality over quantity.

Per-URL metadata: lastmod (date last modified, ISO 8601), priority (0.0-1.0, set by importance), changefreq (daily/weekly/monthly). Most teams set these wrong or skip entirely.

The submission step: 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.

Update on schedule: regenerate sitemap on every deploy. Stale sitemaps with missing recent content slow indexation of new pages.

Patrones de redirects 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 (permanent) for true URL changes. 302 (temporary) for short-term redirects. Use 301 for migrations. 302s don't pass full ranking signal.

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

Domain migration playbook: 1) Set up 1:1 redirects for every old URL → new URL, 2) Update canonical tags on new URLs, 3) Submit new sitemap, 4) Use Change of Address tool in GSC, 5) Update internal links to point to new URLs directly (not via redirects), 6) Wait 90 days for full migration.

The www and trailing slash question: pick one (e.g., https://www.example.com/page/ with trailing slash) and 301 all variants to that canonical form. Mixed signals from /page and /page/ both being live splits 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.

Mistake 1: Wallet SDK on every page. Initialize on click instead. Saves 200-400KB.

Mistake 2: IPFS-served og:image. Crawlers timeout. Cache to fast CDN.

Mistake 3: Mapa del sitio not submitted. 30% of sites skip this. 4-6 weeks slower indexation.

Mistake 4: Mobile testing only on dev laptop. Get a budget Android phone for real testing.

Mistake 5: Mixed http/https or www/non-www. Pick one canonical form, 301 the rest.

Herramientas para SEO técnico Web3

Lo que realmente uso.

Crawlux SEO técnico module for crypto-aware audits.

Google Search Console + Bing Webmaster Tools for indexation and performance. Free.

PageSpeed Insights for Core Web Vitals lab and field data. Free.

Screaming Frog for crawlability audits. Free up to 500 URLs.

WebPageTest for advanced performance debugging. Free.

Lighthouse CI for automated CWV regression testing on every 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: field and lab data with Web3-specific issue detection (wallet SDK weight, IPFS gateway performance).

JS rendering check: compares client-rendered vs initial HTML to flag CSR-only content.

Indexation audit: finds parameterized URL bloat, missing canonicals, redirect chains.

Mobile-first check: simulates Google's mobile-first crawler profile.

Mapa del sitio and robots.txt validation: ensures both are correctly configured and submitted.

Free tier: SEO técnico module on one domain. Module details.

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

Sequenced.

Days 1-7: Audit baseline. Run Crawlux SEO técnico audit. Document Core Web Vitals (field data), indexation state, redirect chains.

Days 8-21: CWV fixes. Lazy-load wallet SDKs. Cache IPFS images to CDN. Optimize LCP elements. Reduce CSS bundle.

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

Days 36-50: Indexation cleanup. Block parameter patterns in robots.txt. Add canonicals to filter URLs. Noindex thin pages. Regenerate sitemap and submit.

Days 51-60: Mobile and validation. 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

This guide synthesizes findings from 200+ Web3 site audits conducted at TG3 Agency since 2017, plus public data verified against the sources below. Last verified May 3, 2026.

• [01]DefiLlama · TVL, volume and protocol metrics
• [02]CoinGecko · Token price, supply and market data
• [03]Schema.org · Structured data specification
• [04]Google Search Central · Structured data implementation guide

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.