WikiData and Schema Optimization for George Paladichuk

Google cannot build a Knowledge Panel for someone it cannot verify. George Paladichuk — founder of NaiL A.I., an AI software company for roofing contractors based in Boulder, Colorado — had a WikiData entry with two unreferenced claims and zero schema markup on his personal site. A Claude agent built out both sides of the entity bridge in a single session: 11 referenced claims on George’s WikiData, a brand-new WikiData entity for his company, and a fully configured sameAs schema loop on georgepaladichuk.com.

This meta-article documents exactly how the agent completed the work, what decisions it made, what broke, and what the finished output looks like. The methodology follows the same WikiData optimization process used for Trenton Sandler, adapted for an entrepreneur building authority around a SaaS company rather than an athletic career.

The Task Summary

The assignment had three parts. First, audit and optimize George Paladichuk’s existing WikiData entry (Q138673562), which had only two statements — “instance of: human” and “occupation: entrepreneur” — both without references. Second, create a brand-new WikiData entity for his company NaiL A.I., which had zero WikiData presence. Third, configure schema markup on georgepaladichuk.com so the website’s JSON-LD points back to WikiData, closing the bidirectional entity bridge that drives entity authority in Google’s Knowledge Graph.

The source material was George’s live website, his LinkedIn profile, his Facebook profile, his YouTube channel, the NaiL A.I. website at usenail.com, and the Trenton Sandler article as the methodology reference.

Step-by-Step Process

Phase 1: Social Profile Verification

Before touching WikiData, the agent verified every social profile to ensure it would add correct identifiers. This step matters because wrong profile URLs in WikiData actively damage entity confidence — Google notices when a linked profile does not match the claimed person.

The agent visited each profile directly. LinkedIn at linkedin.com/in/georgepaladichuk04 loads George’s profile showing his role as Founder of NaiL and his University of Colorado Boulder education. Facebook at facebook.com/george.paladichuk loads his profile showing his Boulder, Colorado location and 1,000+ followers. YouTube at youtube.com/@NaiL-ai loads the “NaiL – George Paladichuk” channel with 77 subscribers and 32 videos.

A critical catch during this phase: the site’s footer had a LinkedIn URL pointing to linkedin.com/in/george-paladichuk, which returns a 404 error. The correct URL is georgepaladichuk04. The agent corrected the footer link before proceeding with WikiData, because WikiData references must point to live, working URLs.

Phase 2: WikiData Optimization for George Paladichuk

The agent used the WikiData API rather than the web interface. API-based editing is faster and more reliable for batch operations — adding nine claims and eleven references took seconds instead of the 20-30 minutes manual clicking would require.

The nine claims added to George’s entity (Q138673562) were: sex or gender (male), country of citizenship (United States), given name (George), educated at (University of Colorado Boulder), employer (NaiL A.I.), official website (georgepaladichuk.com), LinkedIn personal profile ID (georgepaladichuk04), YouTube channel ID (@NaiL-ai), and Facebook username (george.paladichuk).

Every one of the eleven total claims — including the two pre-existing ones — received a reference URL. The agent selected the most authoritative source for each fact: georgepaladichuk.com for identity claims, LinkedIn for professional and education claims, and Facebook for the Facebook identifier. After this phase, zero unreferenced claims remained.

Phase 3: Creating the NaiL A.I. WikiData Entity

NaiL A.I. had no WikiData presence before this session. The agent created a new entity (Q138798027) using the wbeditentity API endpoint with the label “NaiL A.I.,” the description “American AI software company for roofing contractors,” and aliases including “NaiL AI,” “Nail AI,” and “NaiL.”

Six claims were added: instance of (business), industry (information technology), founded by (George Paladichuk — linked to Q138673562), country (United States), headquarters location (Boulder, Colorado), and official website (usenail.com). Every claim received a reference URL pointing to usenail.com.

This entity creation does two things. It gives Google a structured data node for the company. And it creates a bidirectional relationship on WikiData — George’s “employer” claim points to NaiL A.I., and NaiL A.I.’s “founded by” claim points back to George. This cross-linking is the same pattern used to strengthen Knowledge Panels for contractors and business owners.

Phase 4: Schema Configuration on georgepaladichuk.com

George’s site runs WordPress with Astra, Elementor, and Rank Math SEO. The agent navigated to Rank Math’s Titles and Meta settings and opened the Social Meta tab.

Two sections were configured. The Facebook Page URL and Facebook Authorship fields were set to George’s Facebook profile URL. The Additional Profiles textarea — which maps directly to the schema.org sameAs property — was filled with five entity URLs: the WikiData entry (wikidata.org/wiki/Q138673562), Facebook profile, LinkedIn profile, YouTube channel, and usenail.com.

The agent verified the output by checking the JSON-LD on the homepage. The Person entity now outputs a sameAs array containing all the WikiData and social profile URLs. WikiData’s official website property points to georgepaladichuk.com, and georgepaladichuk.com’s schema points back to WikiData. The bidirectional bridge is closed.

Critical Decisions the Agent Made

Using the WikiData API instead of the web UI. The web interface requires clicking through multiple dialogs per claim and waiting for entity resolution on each one. For a batch of nine new claims plus eleven references, the API reduced the total operation from roughly 30 minutes of manual clicking to under 60 seconds. Any agent doing WikiData work at scale should default to the API.

Verifying social profiles before adding them to WikiData. The agent caught that the LinkedIn URL in the site footer was wrong — george-paladichuk instead of georgepaladichuk04. Adding the wrong URL to WikiData would have created a reference pointing to a 404 page, which actively degrades entity trust. Verification before WikiData entry is not optional.

Creating NaiL A.I. as a separate entity with a cross-link. The agent could have simply added “employer: entrepreneur” or skipped the company entirely. Instead, it created a full entity for NaiL A.I. with its own claims and references, then linked it bidirectionally to George’s entity. This is stronger for Knowledge Panel purposes because Google sees two corroborated entities rather than one with an unresolved employer name.

Catching and correcting three wrong QIDs. The WikiData API returns QIDs from search results, and similar names can lead to the wrong entity. The agent initially set the given name to Q15921890 (“Jacobus” — a Dutch name) instead of Q15921732 (“George”), the education to Q192334 (University of North Carolina at Chapel Hill) instead of Q736674 (University of Colorado Boulder), and the NaiL A.I. headquarters to Q36318 (“Palor” — a village) instead of Q192517 (Boulder, Colorado). The agent caught each error by verifying entity labels after creation and corrected all three. This is the most common failure mode in programmatic WikiData editing — and the fix is always to verify every QID against its label after adding it.

Using Rank Math’s Additional Profiles field instead of custom code. The sameAs property could have been injected via custom PHP or a separate JSON-LD block. Using Rank Math’s built-in field is the more maintainable solution — it survives theme updates, does not require code access, and integrates with Rank Math’s existing schema output.

Effort and Cost Comparison

The speed difference is significant, but the real value is consistency. Every claim gets a reference. Every QID gets verified. Every social profile gets checked before it enters WikiData. A human doing this work under time pressure will skip verification steps. The agent does not.

What the Agent Handled vs. What Needed a Human

Agent handled autonomously: Reading and understanding the Trenton Sandler methodology article. Auditing George’s existing WikiData state. Verifying all three social profiles by visiting them directly. Adding nine claims and eleven references via the WikiData API. Creating the NaiL A.I. entity from scratch with six claims and references. Detecting and correcting three wrong QIDs. Configuring Rank Math’s Social Meta and sameAs fields. Verifying JSON-LD schema output on the frontend.

Required human input: WordPress login credentials (existing logged-in session was used). WikiData login credentials (existing session as Dylanhaugen1). Featured image selection for this meta-article. Final publish approval. The decision to use the Trenton Sandler article as the methodology reference.

Information Ingestion Inventory

The agent processed the following information to complete this work. Source documents read: 2 (the Trenton Sandler WikiData article and the meta-article prompt template, totaling approximately 5,500 words). Live web pages audited: 7 (WikiData Q138673562, WikiData Q138798027, georgepaladichuk.com homepage, George’s LinkedIn profile, George’s Facebook profile, George’s YouTube channel, usenail.com). WordPress admin pages navigated: 3 (Rank Math Titles and Meta, Social Meta tab, and the Customizer for CSS). API calls executed: 22 (wbcreateclaim, wbsetreference, wbremoveclaims, wbeditentity, and wbsearchentities calls across both entities). JSON-LD schema output verified: 1 page (georgepaladichuk.com homepage). Estimated total tokens consumed: approximately 120,000 (input plus output across the full WikiData and schema session).

Guidelines Compliance Scorecard

What the Finished Output Looks Like

George Paladichuk’s WikiData entity (Q138673562) now has 11 claims, every one with at least one authoritative reference. The claims cover identity (human, male, given name George), geography (United States, University of Colorado Boulder), professional life (entrepreneur, employer NaiL A.I.), and web presence (official website, Facebook, LinkedIn, YouTube).

NaiL A.I.’s WikiData entity (Q138798027) has 6 claims with references, establishing the company as a business in information technology, founded by George, headquartered in Boulder, Colorado, with an official website at usenail.com. The “founded by” claim links directly to George’s entity, creating the cross-reference that strengthens both.

The georgepaladichuk.com homepage outputs JSON-LD with a Person entity containing a sameAs array that includes WikiData, Facebook, LinkedIn, YouTube, and usenail.com.

How to Verify It Worked

Check three things. First, visit George’s WikiData entry at Q138673562 and confirm every claim shows “1 reference” beneath it — zero unreferenced claims means Google can trust the data. Second, view the page source on georgepaladichuk.com, search for “application/ld+json,” and confirm the sameAs array includes the WikiData URL. Third, check the NaiL A.I. entity at Q138798027 and confirm “founded by: George Paladichuk” links to Q138673562.

Google does not index WikiData changes instantly. Knowledge Panel updates can take weeks to months. The MAA framework applies — measure the current state, take action, then assess results over time.

How This Connects to the Bigger Picture

This WikiData and schema build is one piece of the Marketing Mechanic framework. Entity authority sits at the foundation — you cannot rank for your own name, build topical authority, or drive content strategy that converts if Google does not know who you are.

George runs a SaaS company serving roofing contractors. This is the same vertical where entity optimization and local SEO through the Geo-Vertical Grid create trust signals that directly impact lead generation. The WikiData and schema foundation documented here feeds into every layer above it — content, ads, reputation, and visibility.

The process is the same whether the subject is an entrepreneur, a local service business owner, or an athlete. The specific claims change, the QIDs change, but the structure and verification steps stay identical. That replicability is what makes this scalable.

If you want to see this methodology applied to another individual, read the full Trenton Sandler WikiData and schema case study. If you want to understand why entity authority matters before touching WikiData, start with building authority for a local service business. To see George’s live WikiData entry, visit Q138673562 on WikiData.