How We Built Local Service Spotlight’s Wikidata Entity and Schema Markup in 5 Steps

A Claude agent created Local Service Spotlight‘s Wikidata entity from scratch and configured the Organization schema on the company website in a single working session. This meta-article documents the full process, every decision made, and what the agent handled versus what required human input. The work followed the methodology Dennis Yu established in The Wikidata SOP: How We Tune Entities for Google Knowledge Panels, adapted here for a business entity rather than a person.

The Wikidata and Schema Task

Local Service Spotlight is a digital marketing and reputation management company that helps local service businesses build visibility through content, maps optimization, and structured data. The company was co-founded by Dennis Yu and Dylan Haugen. Before this work, the company had no Wikidata entity, which meant Google had no structured knowledge graph entry to anchor a potential Knowledge Panel. The website already had Organization schema through Rank Math SEO, including sameAs links to social profiles, but no Wikidata URL was present in that array.

The assignment was to build both sides of the entity bridge from scratch: create the Wikidata entity with complete claims and social identifiers, then connect the website’s existing Organization schema back to that entity through the sameAs property. A secondary issue discovered during the audit — the Organization schema’s legalName field contained an email address instead of the company name — also needed correction.

What We Did on Wikidata

The agent created Wikidata entity Q138846724 for Local Service Spotlight using the Special:NewItem form. The label was set to “Local Service Spotlight,” the description to “American digital marketing and reputation management company for local service businesses,” and the aliases to “LSS” and “localservicespotlight” to cover the abbreviation and the domain-style reference.

After creating the base entity, the agent added nine statements through the Wikidata web interface. The instance-of property was set to “enterprise” to classify it as a business entity. The official website was set to https://localservicespotlight.com. The country was set to the United States. Two founded-by statements were added — one linking to Dennis Yu (Q12246156) and one to Dylan Haugen (Q138557395). The industry was set to “digital marketing.” Four social media identifiers were added: YouTube handle (LocalServiceSpotlight), LinkedIn company ID (local-service-spotlight), Instagram username (localservicespotlight), and X/Twitter username (LocalSSpotlight).

Each statement was added individually through the web UI rather than via the Wikidata API. For a new entity with no existing claims, the web interface was the more practical choice since there were no reference-addition complexities or batch operations that would benefit from API access. The Trenton Sandler optimization used the API because it needed to add references to seven existing claims — a different situation that favored programmatic access. This build was straightforward entity creation where the web form was faster.

What We Did on the Website

The website localservicespotlight.com runs WordPress with Rank Math SEO, which was already generating Organization schema with sameAs links to Facebook, Instagram, LinkedIn, YouTube, and X/Twitter profiles. The agent navigated to Rank Math’s Titles & Meta settings, opened the Social Meta tab, and added the Wikidata URL (https://www.wikidata.org/wiki/Q138846724) to the Additional Profiles textarea. This field maps directly to the schema.org sameAs property in the Organization JSON-LD output.

The agent verified on the frontend that both the homepage and the About page now output JSON-LD Organization schema with the Wikidata URL in the sameAs array alongside all existing social profile URLs. This closes the bidirectional loop between the Wikidata entity and the website — the key trigger for Knowledge Panel confidence that Dennis describes in the Wikidata SOP.

During the schema audit, the agent discovered that the Organization schema’s legalName field was set to an email address (“dylan@yourcontentfactory.com”) instead of the company name. This was corrected in Rank Math’s Local SEO settings by replacing the email with “Local Service Spotlight.” The fix was verified on the frontend — the legalName property in the JSON-LD now correctly reads “Local Service Spotlight.”

Critical Decisions the Agent Made

Choosing “enterprise” as the instance-of value. Wikidata offers multiple options for classifying business entities — “business,” “enterprise,” “company,” and others. The agent selected “enterprise” (Q6881511) because it is the most commonly used and broadly accepted classification for commercial organizations on Wikidata, and it matched the pattern used by similar digital marketing companies already in the knowledge base.

Using the web UI instead of the API for entity creation. The Trenton Sandler build demonstrated that the Wikidata API is superior for batch reference additions on existing entities. But for creating a new entity with nine fresh statements and no references to add, the web form was the more direct path. The agent chose the tool that fit the task rather than defaulting to the more technically complex option.

Handling the React state management issue in Rank Math. When adding the Wikidata URL to the Additional Profiles textarea, the agent first tried setting the value via JavaScript. Rank Math’s React-based settings panel did not register this change — the internal component state was never updated, so the Save Changes button did not trigger a network request. The agent recognized the problem and switched to keyboard input, which properly triggered React’s onChange handler and allowed the save to succeed. A less capable system would have reported the save as successful without verifying the actual network request.

Catching and fixing the legalName error. The legalName issue was not in the original task scope. The agent noticed it during the schema audit and flagged it because an incorrect legalName actively harms entity confidence — Google cross-references structured data fields, and an email address in a company name field creates a mismatch signal. This is the same pattern seen in the Trenton Sandler case where the agent caught and fixed the incorrect Twitter username set to “admin.”

Distinguishing a business entity build from a person entity build. Previous builds in this series — Brooke Lance, Minnesota Dunk Squad, Dunk Talk Podcast, George Paladichuk — covered persons and entertainment entities. This was the first build for a commercial business, which required different Wikidata properties (founded-by, industry, LinkedIn company ID) and a different schema type (Organization instead of Person). The agent adapted the process without needing additional instruction.

Effort and Cost Comparison

The table below compares agent execution time and cost against estimated human time at $35/hour. Agent costs are calculated using standard Claude API token pricing.

What the Agent Handled vs. What Needed a Human

Agent handled autonomously: Auditing the existing schema markup on the website. Searching Wikidata to confirm no existing entity. Creating the Wikidata entity with label, description, and aliases. Adding all nine statements (instance-of, official website, country, two founded-by claims, industry, and four social media identifiers). Navigating Rank Math settings and adding the Wikidata URL to the sameAs array. Debugging the React state management issue and finding the correct input method. Discovering and fixing the legalName error. Verifying schema output on the live frontend for both the homepage and About page.

Required human input: WordPress login credentials for localservicespotlight.com (existing logged-in session was used). Wikidata login credentials (existing logged-in session was used). Confirmation that a specific team member was not a co-founder — the agent had attempted to add an incorrect founded-by statement based on the About page listing, and the human corrected this. Final publish approval for this meta-article. Featured image selection.

Information Ingestion Inventory

The agent processed the following information to complete this work. Source documents read: 1 (the Wikidata SOP definitive article at approximately 4,000 words). Live web pages audited: 5 (localservicespotlight.com homepage, About page, Wikidata search results, Dennis Yu’s Wikidata entity Q12246156, Dylan Haugen’s Wikidata entity Q138557395). WordPress admin pages navigated: 6 (Rank Math Titles & Meta, Social Meta tab, Local SEO tab, and corresponding settings pages). Wikidata editing pages used: 10+ (Special:NewItem form, entity page, and individual statement additions). Total source material word count: approximately 5,000 words across all pages. JSON-LD schema output verified: 2 pages (homepage and About page). Estimated total tokens consumed: approximately 120,000 (input and output across the full session).

Guidelines Compliance Scorecard

Why This Build Matters

This is the first business entity build in the Wikidata optimization series. The previous builds — Trenton Sandler, Brooke Lance, George Paladichuk, Dunk Talk Podcast, and Minnesota Dunk Squad — all focused on people or entertainment entities. Local Service Spotlight required a different set of Wikidata properties (founded-by, industry, LinkedIn company ID) and a different schema type on the website (Organization instead of Person). The process transfers cleanly, but the property selection and schema configuration are distinct enough to warrant their own documentation.

The legalName fix also demonstrates a pattern that appears in every build: the agent discovers and corrects issues outside the original task scope. In the Trenton Sandler case it was a Twitter username set to “admin.” Here it was an email address stored as the legal company name. These are the kinds of errors that persist for months because no one audits the raw schema output — they only check whether the plugin is “configured.”

Once your entity identity is properly declared in Wikidata and schema, the next step is ensuring your site’s internal links reflect those entity relationships — connecting pages based on real topical relevancy rather than keyword guessing. To understand the methodology behind this work, start with The Wikidata SOP. To see the live entity, check Local Service Spotlight on Wikidata (Q138846724) and view the page source on localservicespotlight.com to see the Organization schema with the complete sameAs ar