# Structuring Person Schema for a Pseudonymous Web3 Author (ENS + PropertyValue, No Overclaiming) > Source: > Published: 2026-09-09 01:23:59+00:00 I wrote a full guide to Web3 SEO that includes a section on structuring `Person` schema for pseudonymous or wallet-first authors. That section got long enough, and technical enough, that it made sense to pull it out and expand it for a developer audience instead of burying it in a marketing-focused pillar page. This piece covers one narrow problem: how do you give Google and AI answer engines a machine-readable way to verify who wrote something, when the author's primary identity artifact is a wallet address instead of a name on a masthead? And how do you do that without making claims the markup can't back up? The short version: use `identifier` as a `PropertyValue` array for the on-chain data, keep `Person` as the primary type keyed to the human, and reserve `hasCredential` for things that are actually independently verifiable credentials, never for the wallet data itself. Here's the full implementation, including a real credential I added after first writing this piece. `Person` as the primary entity type. Wallet data is metadata, not the identity itself.`identifier` with `PropertyValue` objects for ENS names and wallet addresses, not bare strings.`sameAs` to point at a resolved identity profile (web3.bio or equivalent), not a raw block explorer page.`hasCredential` only for something independently verifiable through a link you don't control, never for a self-issued EAS attestation or for the wallet/ENS data itself. Google's quality rater guidelines weight Experience, Expertise, Authoritativeness, and Trustworthiness (E-E-A-T) heavily for what it calls YMYL content, "your money or your life." Most crypto and DeFi content qualifies, because it touches financial decisions. A pseudonymous protocol team, or a solo operator publishing under a handle instead of a legal name, starts at a structural disadvantage on the trust axis. There's no author bio page with a verifiable history, no LinkedIn cross-reference, no publication track record a search engine's entity graph can anchor to. The fix isn't to fake a corporate identity. It's to substitute a different kind of verifiable signal: on-chain identity data that's cryptographically checkable by anyone, cross-linked the same way you'd cross-link a Twitter or GitHub profile. I use `mangabeira.eth`, which resolves to `0xc2268753E724bcE4A20B413ADD6359abF14D5154` on Ethereum mainnet. It's cross-linked through web3.bio to my site, GitHub, and X profile, and I also hold `mangabeira.lens` on Lens Protocol as a secondary identity anchor on a different stack. Here's the schema.org `Person` block, structured to add that data without letting it take over the entity type: ``` { "@context": "https://schema.org", "@type": "Person", "name": "Gabriel Mangabeira", "url": "https://mangabeira.net", "sameAs": [ "https://x.com/manga82", "https://github.com/gmangabeira", "https://web3.bio/mangabeira.eth" ], "identifier": [ { "@type": "PropertyValue", "propertyID": "ens_domain", "value": "mangabeira.eth" }, { "@type": "PropertyValue", "propertyID": "ethereum_address", "value": "0xc2268753E724bcE4A20B413ADD6359abF14D5154" } ] } ``` Three decisions in that block matter more than the syntax: **1. `Person` stays the primary type, keyed to the name.** The wallet data is metadata about the person, not a replacement identity. I've seen implementations that try to make the wallet address itself the primary entity. That inverts the actual relationship: readers and search engines need to resolve "who is this," and a hex string doesn't answer that question on its own. **2. `identifier` uses `PropertyValue`, not a bare string.** Schema.org's `identifier` property accepts either a plain string/URL or a `PropertyValue` object. Use the object form here because it lets you label what kind of identifier you're providing (`propertyID`) alongside the value. A bare `"identifier": "0xc226..."` gives a crawler no way to know it's an Ethereum address rather than an arbitrary ID string. **3. `sameAs` gets the ENS resolver profile, not a raw explorer link.** I point to the web3.bio resolved profile rather than an Etherscan address page. web3.bio aggregates the ENS name, any linked social profiles, and avatar/bio data in one crawlable page, which is closer to what `sameAs` is designed for (linking to another canonical profile representation of the same entity) than a block explorer's raw transaction list. Schema.org's `Person` type supports a `hasCredential` property, meant for things like degrees, licenses, or certifications the person holds. Use it only when you have something that's actually independently verifiable in the same way a credential is, never for the wallet or ENS data itself. Here's the cautionary example that shaped this rule. A developer built an ENS-plus-schema.org identity setup similar to this one and publicly claimed it produced an "85% Knowledge Panel probability" for their entity. They later retracted that specific claim, stating it had no empirical grounding. The ENS and schema.org implementation itself held up. The overclaimed statistic attached to it did not. The lesson isn't "don't use structured data." It's "don't attach a fabricated confidence number to a real, verifiable technical artifact." I earned a real one since first writing this piece: a Marketing Engineering certification from Profound University, with a public diploma record I don't control the wording of, verifiable at Profound's own site, not mine. That's a legitimate use of `hasCredential`. A self-asserted claim with no independent verification link is not, no matter how the JSON is formatted. Here's the extended block: ``` { "@type": "Person", "name": "Gabriel Mangabeira", "sameAs": ["https://x.com/manga82", "https://github.com/gmangabeira", "https://web3.bio/mangabeira.eth"], "identifier": [ {"@type": "PropertyValue", "propertyID": "ens_domain", "value": "mangabeira.eth"}, {"@type": "PropertyValue", "propertyID": "ethereum_address", "value": "0xc2268753E724bcE4A20B413ADD6359abF14D5154"} ], "hasCredential": [ { "@type": "EducationalOccupationalCredential", "name": "Marketing Engineering", "recognizedBy": { "@type": "Organization", "name": "Profound University" }, "url": "https://university.tryprofound.com/diplomas/344379c2-41f7-4829-a136-1d38e90837fe" } ] } ``` Notice what `hasCredential` points to and what it doesn't. It points to the diploma, verifiable independently of me. It does not point to the ENS name or the wallet address, those stay in `identifier`. Treating a wallet as if it were a credential is the exact category error the retracted "85% Knowledge Panel" claim made. Three checks, in order of how often people skip them: `app.ens.domains` or an `eth_call` against the ENS registry) and confirm it actually points to the address you've hardcoded in the JSON-LD. ENS resolution can change if you migrate wallets. A stale Running this exact page through Google's Rich Results Test right now: Two valid items detected: the Article markup and the BreadcrumbList. Worth saying plainly: this page failed that same test until a few days ago. Its final breadcrumb entry was missing the required `item` field and still carried an old page title from before a rewrite. Running the actual validator, not just eyeballing the JSON, is what caught it. To be direct about what this markup does and doesn't do: there is no confirmed evidence that Google's ranking algorithm or entity-verification graph consumes blockchain data at all. Google's known entity-verification anchors are things like Wikidata, Wikipedia, LinkedIn, and ORCID. ENS and Ethereum addresses aren't part of that confirmed set. What this markup does is give any system, human or machine, a structured, checkable way to verify a specific claim: "the person publishing this content controls this on-chain identity." That's a verification-consistency signal, not a ranking lever. AI answer engines that weigh cross-source agreement and consistent identity signals across a person's public footprint get one more consistent data point. Whether that measurably changes citation rates is untested and I'm not claiming it does. If your goal is "trick Google into a Knowledge Panel," this isn't that, and nothing publicly documented in 2026 is. If your goal is "give a reader or a crawler a way to independently verify a specific identity claim instead of just trusting text on a page," this is a working, low-effort implementation of that. Ethereum Attestation Service (EAS) lets a third party issue a signed, on-chain (or off-chain, still cryptographically verifiable) claim about you, like "this wallet delivered a specific piece of work" or "this address is confirmed to have interacted with a named protocol in a specific way." That would be a meaningfully stronger signal than a self-asserted `identifier` block, because it's independent validation rather than self-published claims, which is the pattern that AI answer engines are documented to weight more heavily. I looked into building one for myself and decided against it. EAS's own documentation is explicit that an attestation's value comes from the attester's reputation, not the subject's. A self-issued attestation about myself would just be a self-published claim wearing cryptographic packaging, the exact pattern this whole piece warns against. If a real third party, a client, a protocol I've done verifiable work for, ever has a reason to attest something about me, that's the legitimate version of this. Building my own isn't. Full context on the broader Web3 SEO and AEO strategy this section came from is in my [guide to Web3 SEO](https://mangabeira.net/publications/definitive-guide-web3-seo).