가명 Web3 작성자를 위한 개인 스키마 구조화(ENS + PropertyValue, 중복 청구 없음)

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.

Summary

• Keep Person as the primary entity type. Wallet data is metadata, not the identity itself.
• Use identifier with PropertyValue objects for ENS names and wallet addresses, not bare strings.
• Use sameAs to point at a resolved identity profile (web3.bio or equivalent), not a raw block explorer page.
• Use 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.
• Validate with Google's Rich Results Test, schema.org's validator, and a manual resolver check, in that order. Actually run the test, don't just assume the JSON is right.
• Don't claim this affects rankings. It doesn't have confirmed evidence behind that claim either way. Frame it as verification, not SEO.

The problem: YMYL content with no name on it

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.

What I actually built for my own author markup

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.

When to actually use hasCredential

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.

Validating the markup before you ship it

Three checks, in order of how often people skip them:

1. Google's Rich Results Test. Paste the page URL or raw JSON-LD. It validates syntax and tells you which rich result types (if any) it's eligible for. Person markup on its own doesn't unlock a rich result by itself in most contexts, it's a supporting entity signal, not a SERP feature trigger.
2. Schema.org's own validator. Checks the JSON-LD against the current vocabulary. Useful specifically for catching property misuse, like using hasCredential on something that isn't actually a credential.
3. Manual resolver check. Independently resolve the ENS name yourself (via 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 identifier block that no longer resolves to your current address is worse than no block at all, because it's now a false claim instead of a missing one.

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.

Why the wallet identity block doesn't move rankings by itself

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.

What about EAS attestations?

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.

For further actions, you may consider blocking this person and/or reporting abuse