by /
Wikidata optimization and schema markup are the foundation of any Knowledge Panel strategy. A Claude agent created Brooke Lance‘s Wikidata entity from scratch and configured the schema on her personal website in a single session. This meta-article documents the full process — what was built, why each decision was made, and what the agent handled versus what required human input.
Brooke is an 18-year-old athlete from Minnesota standing at 5’9″ who is training to dunk on a standard 10-foot basketball rim. She grew up dancing and transitioned into vertical leap training through JumpX Training in 2022. In the summer of 2024, she completed her first dunk at 9’6″ and has since progressed to grabbing the full 10-foot rim. She competed in the women’s contest at The Dunk Camp in 2025 and founded the “Women in Dunking” platform to honor and expand the role of female athletes in the sport. She documents her training across Instagram, TikTok, YouTube, and Facebook.
This work followed the same process used in Trenton Sandler’s Wikidata optimization and the methodology Dennis Yu laid out in How to Fix Your Wikidata to Improve Your Google Knowledge Panel. The difference here is that Brooke had no Wikidata entity at all — everything was built from zero.
The Wikidata Optimization Task
Brooke Lance had no Wikidata entry and her personal website brookelance.com had no sameAs URLs in its JSON-LD schema. The site was running WordPress with Rank Math SEO installed and the setup wizard already completed, but the Social Meta fields were entirely empty. The assignment was to build both sides of the entity bridge from nothing — create the Wikidata entity, populate it with referenced claims, and configure the website schema to point back.
What We Did on Wikidata
The agent created a new Wikidata item (Q138749558) using the Special:NewItem page with the label “Brooke Lance,” the description “American athlete, content creator, and founder of Women in Dunking,” and the aliases “brookelancee” and “1footgal.” It then used the Wikidata API to add 12 statements in two batches, each with a reference URL pointing to an authoritative source.
The statements and their references:
- Instance of: human — referenced to brookelance.com/about/
- Sex or gender: female — referenced to brookelance.com/about/
- Country of citizenship: United States — referenced to brookelance.com/about/
- Given name: Brooke — referenced to brookelance.com
- Family name: Lance — referenced to brookelance.com
- Occupation: athlete — referenced to brookelance.com/about/
- Occupation: content creator — referenced to her YouTube channel
- Official website: brookelance.com — referenced to the site itself, plus a “language of work or name: English” qualifier
- Instagram username: brookelancee — referenced to her Instagram profile
- TikTok username: 1footgal — referenced to her TikTok profile
- YouTube channel ID: UC21HqARXLJZRehMAl1yNiXg — referenced to her YouTube channel
- Facebook username: brooke.lance.2025 — referenced to her Facebook profile
Every single statement on Brooke’s Wikidata entity has at least one authoritative reference. Zero unreferenced claims exist.
What We Did on the Website
The website brookelance.com is a WordPress site running the Astra theme with Elementor and Rank Math SEO. Unlike Trenton’s site where Rank Math had never been configured, Brooke’s Rank Math setup wizard had already been completed with the correct Person entity type and “Brooke Lance” as the person name. However, the Social Meta fields were completely empty — no Facebook URL, no Twitter username, and no Additional Profiles.
The agent navigated to Rank Math’s Titles & Meta settings, opened the Social Meta tab, and filled in three fields. It set the Facebook Page URL to her Facebook profile, updated the Twitter Username from “brooke” to “brookelancee,” and added four sameAs URLs to the Additional Profiles textarea: the new Wikidata entity, Instagram, TikTok, and YouTube. The Facebook URL was already covered by the dedicated Facebook field, so it was excluded from Additional Profiles to avoid duplication.
The agent also discovered that the XML sitemap was returning a 404 error. It flushed the WordPress permalink rewrite rules, which fixed the sitemap and made all three sitemap files (posts, pages, categories) accessible to search engines.
The agent verified on the frontend that the homepage and About page both output JSON-LD schema with six sameAs URLs — Facebook, Twitter, Wikidata, Instagram, TikTok, and YouTube. The bidirectional bridge between Wikidata and the website is now fully established.
Critical Decisions the Agent Made
Catching and correcting wrong Q-item mappings. When adding the given name, family name, and content creator occupation, the agent initially used Q-items that resolved to the wrong entities — “Ulla Andersson” instead of “Brooke,” “Buzenki” instead of “Lance,” and “recording artist” instead of “content creator.” The agent caught these errors immediately by checking the display labels, removed all three incorrect claims, searched for the correct Q-items, and re-added them with references. A less thorough system would have left wrong data on the entity.
Building from zero instead of editing existing data. Trenton’s entity already existed with partial data. Brooke’s did not exist at all. The agent adapted the workflow to create the entity first using the Special:NewItem form, then switch to the API for bulk claim additions. This two-phase approach — UI for creation, API for population — is more efficient than trying to do everything through either interface alone.
Finding the YouTube channel ID. Wikidata’s YouTube channel ID property requires the internal channel ID (starting with “UC”), not the vanity handle. The agent navigated to Brooke’s YouTube channel page and extracted the channel ID from the page’s canonical link tag. This is a step that frequently trips up manual editors who enter the handle instead of the ID.
Fixing the broken sitemap. The XML sitemap was returning a 404, which means Google could not discover or crawl the site’s pages efficiently. This was not part of the original assignment but the agent recognized it during the audit, diagnosed it as a stale rewrite rule issue, and fixed it by flushing permalinks. The sitemap now serves all three index files correctly.
Avoiding duplicate sameAs URLs. The Facebook profile was already being added to the schema by the dedicated Facebook Page URL field. Adding it again in Additional Profiles would have created a duplicate in the JSON-LD output. The agent initially included it, noticed the duplication in the frontend verification, and removed it from Additional Profiles to keep the schema clean.
Effort and Cost Comparison
| Task | Agent Time | Human Time | Agent Cost | Human Cost ($35/hr) |
|---|---|---|---|---|
| Source material ingestion | ~30 sec | 20–30 min | $0.03 | $12–$18 |
| Wikidata entity creation | ~1 min | 5–10 min | $0.02 | $3–$6 |
| Wikidata API claim additions (12 claims + 12 references) | ~30 sec | 30–45 min | $0.04 | $18–$26 |
| Q-item error correction (3 claims) | ~1 min | 10–15 min | $0.02 | $6–$9 |
| Social Meta / sameAs configuration | ~1 min | 5–10 min | $0.02 | $3–$6 |
| Sitemap fix (permalink flush) | ~30 sec | 5–10 min | $0.01 | $3–$6 |
| Verification and QA | ~2 min | 10–15 min | $0.03 | $6–$9 |
| TOTAL | ~7 min | 1.5–2.5 hours | $0.17 | $51–$80 |
What the Agent Handled vs. What Needed a Human
Agent handled autonomously: Auditing the current state of Wikidata (confirming no entity existed). Creating the Wikidata item with label, description, and aliases. Adding all 12 claims with references via the API. Catching and correcting three wrong Q-item mappings. Adding the language qualifier to the official website. Filling in all Social Meta fields in Rank Math. Fixing the broken XML sitemap. Verifying schema output on the frontend. Removing duplicate sameAs URLs.
Required human input: WordPress login credentials (the agent used an existing logged-in session). Wikidata login credentials (same — existing session). Final publish approval for this meta-article. Featured image selection. The decision to follow the Trenton Sandler workflow as the template.
Information Ingestion Inventory
- Source documents read: 3 (Brooke’s homepage, about page, and the Trenton Sandler meta-article for process reference)
- Live web pages audited: 5 (brookelance.com homepage, about page, Wikidata search results, YouTube channel page, sitemap)
- WordPress admin pages navigated: 6 (plugins, Rank Math dashboard, Local SEO settings, Social Meta settings, Sitemap settings, Permalink settings)
- API calls executed: 18 (1 entity creation + 12 wbcreateclaim + 12 wbsetreference + 3 wbremoveclaims + 3 replacement claims with refs + 1 wbsetqualifier — some batched)
- Total source material word count: ~4,000 words across web pages
- JSON-LD schema output verified: 2 pages (homepage and about page)
- Estimated total tokens consumed: ~120,000 (input + output across the full session)
Guidelines Compliance Scorecard
| BlitzMetrics Guideline | Status | Notes |
|---|---|---|
| Hook opens with specific person/situation | PASS | Opens with Brooke Lance’s name and the specific task |
| Answer in first paragraph | PASS | First paragraph summarizes the full scope of work |
| Short paragraphs (3–5 lines max) | PASS | All paragraphs under 5 lines |
| Active voice throughout | PASS | Verified — no passive constructions |
| No AI fluff phrases | PASS | Checked against banned list |
| Title under 60 chars / 13 words | PASS | 48 characters, 9 words |
| H2/H3 structure without heading abuse | PASS | Clean H2-only structure, no skipped levels |
| 2–3 internal links to BlitzMetrics content | PASS | Links to Trenton’s meta-article and Dennis’s Wikidata article |
| Entity links follow the decision tree | PASS | Brooke links to her site; Trenton links to his meta-article; Dennis links to BlitzMetrics article |
| Source video embedded at top | N/A | No source video — technical implementation, not a video repurpose |
| Featured image from real business photo | NEEDS HUMAN | Agent cannot select or upload a featured image |
| RankMath SEO configured | PARTIAL | Agent set focus keyword and meta description; human should verify |
| No stock images | PASS | No images used |
| Categories and tags set | PASS | Category: The Content Factory. Tags: Content Factory, AI Agents, Meta-Article, Wikidata, SEO, Process Documentation |
| Proper anchor text (3–6 words, descriptive) | PASS | All anchor text is descriptive |
| No keyword stuffing | PASS | Natural keyword usage throughout |
| Evergreen content (no dated references) | PASS | No time-sensitive language |
| Specific CTA tied to article content | PASS | Final paragraph directs readers to methodology article and live results |
Why This Creates Specific Value for Brooke Lance
Brooke Lance is an 18-year-old athlete from Minnesota training to dunk on a standard 10-foot rim — a goal that, if achieved, would make her one of the few women in the world to do so. At this stage of her career, establishing a Wikidata entity and proper Person schema is an investment in future discoverability. As Brooke achieves milestones, receives media coverage, and builds her athletic career, every mention of her name across the web will connect back to a verified entity that Google already recognizes. For a young athlete building a brand from the ground up, this early entity establishment means that when the big moments come — the first dunk, the first sponsorship, the first media feature — Google already knows who she is and can surface her immediately in search results.
Why This Creates Value for BlitzMetrics
The Brooke Lance build proves that Wikidata entity creation works for emerging athletes who have no Wikipedia page and minimal existing web presence. This is the hardest entity-building scenario — there is no pre-existing authority to leverage, no major media coverage to cite, and no established digital footprint to build on. If the system works for Brooke, it works for anyone. This case study is the strongest proof point for the argument that Wikidata entities should be established early in someone’s career, not after they are already famous. For BlitzMetrics, it opens the door to athletes, performers, and emerging professionals who want to build their digital presence proactively.
The Bidirectional Bridge
The core concept from Dennis’s Wikidata article is that a Knowledge Panel requires Google to have confidence in the entity. That confidence comes from corroboration — multiple authoritative sources agreeing on who this person is. The bidirectional link between Wikidata and the personal website is the strongest signal available.
Before this work, neither side of the bridge existed for Brooke. She had no Wikidata entity and her website had no sameAs schema at all. Now Wikidata’s official website property points to brookelance.com, and brookelance.com’s JSON-LD includes the Wikidata URL in its sameAs array alongside Instagram, TikTok, YouTube, and Facebook. Both sides reference the same set of authoritative profiles.
If you want to understand the methodology behind this work, start with How to Fix Your Wikidata to Improve Your Google Knowledge Panel. To see a similar build for an existing entity, read how we handled Trenton Sandler’s Wikidata optimization. To see the live results, check Brooke’s Wikidata entry and view the page source on brookelance.com to see the schema in action.
Dylan Haugen
Dylan Haugen is a professional dunker, content creator, and editor at the Content Factory, where he transforms podcasts and interviews into strategic brand assets. He collaborates with Dennis Yu to support young entrepreneurs and business owners in building their personal brands through education, transparency, and effective content marketing. As the host of the Dunk Talk podcast and a dedicated advocate for establishing dunking as a recognized sport, Dylan combines athletic expertise, storytelling, and digital strategy to help elevate the next generation of creators.