The 2026 Web3 Evidence Checklist for dApp SEO

Web3 control: Core dApp landing pages expose search-critical information before wallet connection. Evidence required: rendered HTML, crawl output, page templates, wallet-gated states, internal links, and Search Console inspection.

Pass/fail condition: pass when users and crawlers can reach the core value proposition, supported workflows, and documentation without a mandatory wallet interaction; fail when meaningful information exists only after application state loads or client-only rendering succeeds.

Severity: critical. Owner: front-end engineering with SEO validation. Corrective action: provide reliable server-rendered, static, pre-rendered, or otherwise crawlable content where the observed implementation requires it. Validation: re-crawl priority routes and compare the rendered output with the user-visible page.

Web3 control: Structured data describes only visible, supportable application information. Evidence required: rendered content, JSON-LD output, validation results, and the actual product attributes represented by the markup.

Pass/fail condition: pass when the chosen vocabulary matches visible facts; fail when markup invents unsupported properties, ratings, metrics, availability, or capabilities. Severity: medium. Owner: SEO and engineering with product review.

Corrective action: use applicable vocabulary only where it accurately describes the page, and do not present markup as a guaranteed ranking or rich-result mechanism. Validation: validate the output and reconcile every property with visible content.

Control: Search intent maps to real protocol problems and workflows. Evidence required: query data, product documentation, support questions, and protocol use cases involving Layer 2 workflows where relevant.

Pass/fail condition: pass when landing pages answer a specific problem, workflow, comparison, integration, or decision; fail when content primarily targets speculative attention unrelated to product use.

Severity: high. Owner: product marketing and SEO. Corrective action: build a problem-solution query map tied to features the dApp actually supports. Validation: compare query relevance, qualified landing-page behavior, and product actions.

Control: Promotional claims remain supportable. Evidence required: claims inventory, product facts, and legal or compliance review where applicable. Pass/fail condition: pass when performance, yield, safety, or return claims are accurate, qualified, and supported; fail when the page uses unsupported guarantees or '100x gains' language.

Severity: critical. Owner: product marketing with legal or compliance review where required. Corrective action: remove unsupported claims, state material limitations, and separate factual product information from promotional interpretation.

Use Web3 failure examples in /guides/web3-seo-mistakes where relevant. Validation: re-review each material claim against the evidence.

Control: Documentation resolves real user tasks. Evidence required: documentation index, internal links, developer queries, onboarding paths, and support tickets. Pass/fail condition: pass when setup, integration, security, transaction, and troubleshooting information can be found from search entry points; fail when essential instructions are fragmented, gated, or inaccessible.

Severity: high. Owner: documentation or developer-relations team with SEO support. Corrective action: consolidate and internally link documentation around real user tasks. Validation: test representative journeys from search entry to task completion.

Web3 control: Team, contributor, and protocol ownership information is accurate and inspectable. Evidence required: public team information, repositories, governance documentation, and any credentials the project elects to publish.

Pass/fail condition: pass when identity and responsibility information is accurate and consistent; fail when pages invent credentials, obscure responsibility for material claims, or imply verification that has not occurred.

Severity: high. Owner: leadership, protocol team, and editorial. Corrective action: publish only verifiable information and describe anonymous or pseudonymous governance accurately where relevant. Validation: reconcile public pages with project records.

Web3 control: Security audit references remain current and scoped. Evidence required: audit reports, report dates, scope, affected contracts, and current deployment. Pass/fail condition: pass when security pages accurately state what was reviewed and link to the underlying evidence; fail when 'audited' appears without scope, source, or current applicability.

Severity: critical. Owner: security or protocol engineering. Corrective action: link the actual report, explain scope and limitations, and update references after material contract changes. Validation: match the published claim to the report and deployed contracts.

Web3 control: Risk and financial statements are reviewed for accuracy and qualification. Evidence required: claims inventory, product mechanics, risk disclosures, and responsible legal or compliance review where applicable.

Pass/fail condition: pass when material risks and limitations are clear and promotional claims are supportable; fail when a disclaimer is used to excuse an otherwise misleading statement. Severity: critical.

Owner: legal or compliance with product and editorial support. Corrective action: qualify or remove unsupported claims and use examples such as a 4-8% range only when the source and context genuinely support them. Validation: reconcile every material financial or risk statement with its evidence.

Web3 control: Regional promotion rules are mapped to the actual product and intended audience. Evidence required: target jurisdictions, distribution channels, product classification, and current legal guidance from responsible reviewers.

Pass/fail condition: pass when the publishing workflow identifies which statements require review in each relevant market; fail when generic templates are treated as universal compliance. Severity: critical.

Owner: legal or compliance. Corrective action: maintain jurisdiction-specific review requirements and remove statements the team cannot substantiate or lawfully publish. Validation: record reviewer approval and re-check after material product or regulatory changes.

Fix broken internal links to core protocol documentation. - High - 1-2 hours Evidence required: crawl report and destination review. Pass/fail condition: pass when priority documentation has valid internal paths and no important link ends at a dead destination.

Owner: documentation and web engineering. Corrective action: repair, redirect, or replace broken links based on the intended resource. Validation: re-crawl affected paths.

Update meta descriptions so calls to action describe utility instead of speculative outcomes. - Medium - 2-3 hours Evidence required: current metadata, page purpose, and supported product action. Pass/fail condition: pass when the description accurately summarizes the page without guarantees or misleading claims.

Owner: SEO or editorial. Corrective action: rewrite for relevance and clarity without treating metadata as a guaranteed ranking factor. Validation: re-crawl metadata and review search appearance over time.

Review any publication-logo section before using it as trust evidence. - High - 2 hours Evidence required: actual coverage or relationship for each displayed logo. Pass/fail condition: pass when every logo is authorized and corresponds to a real, supportable reference.

Owner: communications and legal or brand review. Corrective action: remove unsupported logos and link to genuine coverage where appropriate. Validation: verify each displayed reference.

• Community-only discovery: Evidence required: acquisition mix and search landing pages. Pass when Discord and Twitter support rather than replace durable searchable resources. Severity: medium. Owner: growth and content. Corrective action: publish durable pages for recurring questions. Validation: compare search discovery with community referrals.
• Unexplained jargon: The source says technical language can alienate 90% of potential users, but no supporting URL is provided. Treat that figure as historical source material. Pass when important terms are defined at the point of need. Severity: medium. Owner: editorial and product. Corrective action: add concise definitions and contextual links. Validation: test onboarding and documentation journeys.
• Thin project identity: Evidence required: About, governance, team, repository, and security pages where relevant. Pass when users can understand who operates or governs the project and what evidence supports material claims. Severity: high. Owner: leadership and editorial. Corrective action: publish accurate, supportable identity and responsibility information. Validation: compare public statements with project records.
• Over-optimized internal anchors: Evidence required: internal-link crawl and anchor distribution. Pass when anchors describe destination context naturally. Severity: low. Owner: SEO and editorial. Corrective action: replace repetitive exact-match anchors where they reduce clarity. Validation: re-crawl internal links.