DEV Community: ookyet.eth

I Retired My "85% Knowledge Panel Probability" Claim. Then Google Built the Entity Anyway.

ookyet.eth — Wed, 08 Jul 2026 03:48:44 +0000

Nine months ago I wrote a post on here claiming my ENS identity architecture had reached "85% Knowledge Panel trigger probability."

Two things happened since.

Google's Knowledge Graph actually minted an entity node for me. And I learned that the 85% number was fiction — mine.

This is the honest retrospective.

The timeline, with receipts

Date	What happened
Aug 2025	ookyet.com first indexed
Oct 2025	Entity markup shipped: Person `@graph`, Dentity verification, ENS identifiers. The "85%" post
Jun 2026	Search Console turned red: `Q&A` errors, `Profile page: Invalid object type`. Cleanup
Jun 28, 2026	Fixed markup deployed. Then: hands off
Jul 2, 2026	Knowledge Graph Search API returns a machine-minted Person node for `ookyet`
Jul 7, 2026	Search Console fully green: ProfilePage valid, indexed pages up, zero 404s

Still no Knowledge Panel. Keep reading — that part matters.

What Google actually built

You can reproduce this:

curl "https://kgsearch.googleapis.com/v1/entities:search?query=ookyet&limit=10&key=YOUR_API_KEY"

{
  "result": {
    "@id": "kg:/g/11z806my44",
    "name": "Qifeng Huang",
    "@type": ["Person"]
  }
}

Three details in that tiny response taught me more than anything I shipped in 2025.

The /g/ MID is machine-minted. You can't register one, buy one, or submit one. Google's entity reconciliation creates it when enough independent sources agree that a person exists. This is the mechanical prerequisite for a Knowledge Panel — the entity has to exist in the graph before anything can be displayed about it.

The node's name is my real name, not my handle. My site declares name: "ookyet". The node says "Qifeng Huang" — pulled from the high-authority anchors (LinkedIn, ORCID), not from my self-declaration. Third-party corroboration outweighs anything you say about yourself. Expected, and honestly a relief: the graph is working as designed.

The Knowledge Graph holds 8 distinct people named Qifeng Huang. Query any of them by real name and you get a crowded namespace. Query ookyet and exactly one node comes back — mine. A coined handle turns out to be a cross-namespace disambiguation key: every external signal converts cleanly because Google never has to ask "which one?"

What I got wrong in the last post

The percentage. There is no such metric.

Google does not expose a "Knowledge Panel probability," a candidate state, or a trigger score. Anyone quoting you a percentage — including 2025 me — computed it from their own weighted checklist and dressed it up as measurement. I've since rewritten the open-source tooling to call the number what it is: a signal-completeness checklist of things you maintain. Saturating it does not trigger anything.

The mindset behind the number was the deeper bug. I treated the Knowledge Panel as something you trigger with sufficiently clever markup. It isn't. It's a notability decision Google makes about independent third-party coverage, and markup cannot force it. What markup can do — all it can do — is make sure that when signals arrive, they reconcile into one clean entity instead of a fog of ambiguity.

And some of that clever markup actively hurt. The June 2026 Search Console cleanup retired, with prejudice:

FAQPage / HowTo — Google removed those rich results; emitting them now just generates errors
A synthetic "Knowledge Panel candidate" node — markup that described my ambitions instead of the page. Google's policy is blunt: markup must reflect visible content
JSON-LD for press coverage that was still "planned" — asserting articles that didn't exist yet. That's fabricated notability evidence, pointed at the exact system I was trying to earn trust from
SearchAction pointing at a search page my site doesn't have

Every one of those felt like optimization when I shipped it. Every one was debt.

What survived

The boring parts. The parts that are just schema.org used correctly:

One Person entity, referenced everywhere. A single @id, with every page — ProfilePage, articles, breadcrumbs — pointing at it. Handle as name, ENS as alternateName + identifier, never two competing self-descriptions.

One ProfilePage, with a typed mainEntity. Not a bare @id reference — Search Console rejects that with "Invalid object type." Carry @type and name explicitly.

sameAs quality over quantity. Live, identity-consistent profiles only. LinkedIn and ORCID matter disproportionately — they're the reconciliation sources Google actually reads, and unlike Wikipedia or Wikidata they're attainable without notability. Don't force wiki entries; a deleted self-created item is a negative signal.

Fix once, then freeze. The June 28 fix went from deploy to fully green Search Console in 9 days — with zero tweaks in between. Every markup edit resets Google's re-evaluation clock. The discipline is the feature: patience is doing work while you aren't.

What the node looks like today

Sparse. No detailedDescription, no image, no url, resultScore around 0.0001. A newborn entity.

I check it weekly (daily is pointless — same-day queries return byte-identical results), reading the fields in the order they typically grow:

url — Google binding my site to the node as its entity home. Driven by corroboration already shipped; this is the milestone I'm actually watching
image — the reconciled avatar
resultScore — rising an order of magnitude would be a display-confidence precursor
detailedDescription — sourced from encyclopedic references, so for a niche entity: probably never. It isn't a blocker for the rest

No change week over week is the normal case. Confidence for a small entity compounds like interest — source quality times time times stability — and none of those factors respond to impatience.

The honest scoreboard

Real, today: position 1 for my name, sitelinks, an image pack, AI Overview describing me as an entity with my real name and ENS resolved together, and a persistent MID in the Knowledge Graph.

Not real, today: a Knowledge Panel. Possibly not ever — Google may simply never grant panels to entities at my scale, and no architecture changes that.

I used to frame the panel as the prize. I now think the prize is already collected: an identity that machines resolve unambiguously, backed by evidence anyone can verify. The panel, if it comes, is a bonus rendered on top of work that already paid out.

Everything above is documented in the open-source repo — including the retired strategies, kept as documented failures with dates, because the failures are the useful part: github.com/ookyet/web3-identity-seo

I'll write the next chapter when the node grows a url.

I Made My ENS Domain Searchable on Google (85% Knowledge Panel Probability)

ookyet.eth — Mon, 06 Oct 2025 12:58:17 +0000

**Update (July 2026): The "85% probability" framing in this title is retired — no such metric exists; Knowledge Panel display is notability-driven and cannot be scored. What did happen: Google's Knowledge Graph minted a persistent entity node for this identity. The honest 11-month retrospective — including exactly what this post got wrong — is here: I Retired My "85% Knowledge Panel Probability" Claim. Then Google Built the Entity Anyway.

I Made My ENS Domain Searchable on Google

The Problem: ENS domains are invisible to Google. Search for "ookyet.eth" and you get nothing.

The Solution: I built a 5-layer architecture that achieved 85% Knowledge Panel trigger probability.

Here's how.

Why This Matters

With 4 billion Google users, making Web3 identities discoverable is critical for adoption. But blockchain and traditional search engines speak different languages.

My ENS domain ookyet.eth was invisible to Google despite being:

✅ Verified on-chain since 2023
✅ Linked to 7+ social platforms
✅ Backed by NFT avatar (Lil Ghost #761)

Google saw: nothing.

The 5-Layer Architecture

Layer 1: Indexing Acceleration

Problem: Google crawls can take 7-30 days.

Solution: Google Indexing API

const { google } = require('googleapis');

async function submitToGoogle(url) {
  const auth = new google.auth.GoogleAuth({
    keyFile: 'service-account.json',
    scopes: ['https://www.googleapis.com/auth/indexing']
  });

  const indexing = google.indexing({ version: 'v3', auth });

  await indexing.urlNotifications.publish({
    requestBody: {
      url: url,
      type: 'URL_UPDATED'
    }
  });
}

// 24-48 hour indexing vs 30 days
await submitToGoogle('https://ookyet.com/proof/');

Result: Went from 30-day wait to 48-hour indexing.

Layer 2: Entity Markup

Problem: Google doesn't understand blockchain identities.

Solution: Schema.org structured data

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://ookyet.com/#Author",
  "name": "ookyet.eth",
  "identifier": [
    {
      "@type": "PropertyValue",
      "propertyID": "ens_domain",
      "value": "ookyet.eth"
    },
    {
      "@type": "PropertyValue",
      "propertyID": "ethereum_address",
      "value": "0x1691E606553805D771e411bF5c6e395D16916f99"
    }
  ],
  "hasCredential": [{
    "@type": "EducationalOccupationalCredential",
    "name": "Dentity Verified Human"
  }]
}
</script>

Key: The hasCredential property tells Google this is a verified human, not an AI-generated identity.

Layer 3: Proof of Humanness

Problem: Google's spam filters block entities without human verification.

Solution: Dentity Unique Human KYC

Dentity verification includes:

✅ Government ID verification
✅ Biometric liveness check
✅ Anti-Sybil database (ensures uniqueness)
✅ 10/10 verification checks

Why this matters: AI can create infinite identities. Proving you're a unique human is the strongest anti-spam signal.

My Dentity profile: https://app.dentity.com/ookyet.eth

Layer 4: Active Trigger Interfaces

Problem: Even with perfect markup, Google needs explicit "Knowledge Panel candidate" signals.

Solution: Active trigger interfaces

<!-- Primary Entity Declaration -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ProfilePage",
  "@id": "https://ookyet.com/#KnowledgePanelCandidate",
  "mainEntity": {
    "@type": "Person",
    "@id": "https://ookyet.com/#Author",
    "identifier": [{
      "@type": "PropertyValue",
      "propertyID": "knowledge_graph_eligible",
      "value": "verified_entity"
    }]
  }
}
</script>

<!-- FAQ Schema for AI Overviews -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "Who is ookyet.eth?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "ookyet.eth is a verifiably human Web3 identity..."
    }
  }]
}
</script>

The knowledge_graph_eligible flag is a Google internal property that marks entities as KP candidates.

Layer 5: Cross-Platform Validation

Problem: Google validates entities across multiple sources.

Solution: 7+ unified platforms

All using consistent identity:

ENS: ookyet.eth
Twitter: @ookyet
GitHub: @ookyet
Instagram: @ookyet
[+ more platforms]

Linked via Schema.org sameAs property:

{
  "@type": "Person",
  "sameAs": [
    "https://twitter.com/ookyet",
    "https://github.com/ookyet",
    "https://instagram.com/ookyet",
    "https://app.ens.domains/name/ookyet.eth"
  ]
}

Result: 99% cross-source consistency score.

Results

After implementing all 5 layers:

Metric	Before	After
Google Indexing	30 days	48 hours
Knowledge Panel Probability	0%	85%+
Entity Confidence	0%	96%
Rich Results	❌	✅ Enabled
FAQ in SERP	❌	✅ Enabled

Live proof: https://ookyet.com/proof/

How to Verify

Check Entity Recognition

curl "https://kgsearch.googleapis.com/v1/entities:search?query=ookyet.eth&key=YOUR_KEY"

Test Rich Results

Visit: https://search.google.com/test/rich-results?url=https://ookyet.com/

Monitor Progress

# Daily KG audit script
./scripts/kg-audit.sh

# Outputs:
# - Knowledge Graph API status
# - SERP feature detection
# - Entity score calculation
# - Timeline tracking

The Critical Insight

Google doesn't care about blockchain proofs. Google cares about structured data it can understand.

My mistake was thinking "ENS ownership on-chain" would be enough. It wasn't.

What worked:

Translating blockchain proofs → Schema.org properties
Adding human verification → Dentity KYC (anti-spam signal)
Active trigger interfaces → Explicit KP candidate markers
Cross-platform consistency → 7+ unified identities

Try It Yourself

Prerequisites

ENS domain (register at app.ens.domains)
Dentity verification (dentity.com)
Website with Schema.org markup
Google Cloud service account

Implementation

Full architecture on GitHub:
https://github.com/ookyet/web3-identity-seo

Resources

My Complete Proof Hub: ookyet.com/proof
Technical Deep-Dive: Identity Through ENS blog post
ENS Verification: app.ens.domains/name/ookyet.eth
Dentity Profile: app.dentity.com/ookyet.eth

What's Next?

I'm currently at 85% Knowledge Panel trigger probability. The final 15% comes from:

External authority sources (GitHub, Dev.to, ResearchGate citations)
Time distribution (signals spread over 7+ days)
Platform diversity (technical + community + academic)

Update: I'll share when the Knowledge Panel goes live.

Questions?

Drop them in the comments. Happy to share more technical details about:

Google Indexing API setup
Schema.org optimization
Dentity verification process
Knowledge Graph algorithms

Let's make Web3 identities discoverable to 4 billion Google users. 🚀

Built with: ENS, Dentity, Schema.org, Google Indexing API
Architecture: Open-source on GitHub
Live Example: ookyet.eth