Web3 Technical SEO Guide 2026: dApps, Core Web Vitals and JS Rendering

Core Web Vitals on dApps

Web3 sites consistently fail Core Web Vitals because of wallet-connect SDKs, live price tickers and image-heavy dApp UIs. The targets are non-negotiable.

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.

JS rendering: SSR, SSG and CSR

Most dApps use client-side rendering and lose 60-80% of crawlable content as a result. Pick rendering strategy by page type.

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. Compare to your visible content. Gaps reveal CSR problems.

Wallet SDK performance

Wallet-connect SDKs are the single biggest INP killer on dApp marketing sites. Most teams ship them on every page even when not needed.

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.

IPFS, Arweave and CDN strategy

Decentralized storage is great for content permanence and bad for SEO crawl performance. The fix is dual hosting.

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 for Web3

Google's mobile-first index uses a budget Android phone profile. Most Web3 sites are tested on dev laptops. The mismatch causes ranking issues.

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.

Indexation control

Most Web3 sites have indexation bloat. Search Console shows 4,000 pages indexed when 200 are useful. Wastes crawl budget.

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.

Sitemap 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.

Sitemap strategy for Web3 sites

Sitemap.xml is the single most-overlooked technical SEO control. Most Web3 sites have one but never submit it.

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 > Sitemaps > Add new sitemap. Bing Webmaster Tools > Sitemaps > Submit sitemap. About 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 "Sitemap: https://example.com/sitemap.xml" line to robots.txt. Helps 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.

Redirects and migration patterns

Web3 projects rebrand and migrate often. Bad redirects destroy ranking. Good redirects preserve it.

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 technical SEO mistakes

Recurring patterns from Web3 audits.

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: Sitemap 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.

Tools for Web3 technical SEO

What I actually use.

Crawlux Technical SEO 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.

How Crawlux fits in technical SEO

Technical SEO module covers the patterns above.

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.

Sitemap and robots.txt validation: ensures both are correctly configured and submitted.

Free tier: Technical SEO module on one domain. Module details.

60-day technical SEO action plan

Sequenced.

Days 1-7: Audit baseline. Run Crawlux Technical SEO 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.

From the TG3 client roster

Audit your site against this guide

The Crawlux audit modules below test specific patterns from this guide on your site automatically.

About AB

Compare specific technical seo pairs

Detailed head-to-head comparisons for the protocols, projects and tools covered in this guide.

Sources and methodology

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

This guide is for informational purposes. The crypto SEO landscape changes quickly. Re-run audits quarterly.

Got feedback or a different take?

Drop your perspective below. We read every comment.