How to Build a Client Entity Graph in 90 Minutes and Reuse It Across Domains

Question 1

What do I need and what will I ship from the 90-minute entity graph build?

Accepted Answer

The article recommends setting aside roughly 90 minutes for the first domain. Before starting, it lists a blank spreadsheet, access to the client CMS header settings, the legal name, street address, phone number, principal profiles, official social and registry URLs, and the live pages that describe people and services. At the end, the article says you will have a JSON-LD @graph with connected Organization, Person, Service and WebSite nodes, a sameAs array of only checked profiles, and a reusable variable-based template and QA routine.

Question 2

What should go in the entity inventory before writing JSON-LD?

Accepted Answer

The article recommends creating an inventory sheet with columns for Entity_Type, Internal_ID, Canonical_URL, Legal_Name, Description, profile URLs, and Parent_Relationship. The expected result is one Organization row, the WebSite row, one or two real principals if the site identifies them, and roughly three to five core services, each with a permanent URL where the site describes that entity. The article advises leaving out blog categories, campaigns and landing-page variations without a durable page or operational identity.

Question 3

How should Person, Service and WebSite nodes be connected to the Organization?

Accepted Answer

The article recommends defining the organization once in a single @graph array with an absolute @id such as https://example.com/#organization. Later Person, Service and WebSite nodes then point to that same string with worksFor, provider and publisher, and each service URL identifies its own page. The article warns against using "@id": "#organization" alone and against pasting a full new Organization object into every provider or worksFor field.

Question 4

How should I choose sameAs links for the Organization?

Accepted Answer

According to groas, sameAs is an identity assertion, not a list of articles about the business. The article recommends adding a short array of independently identifiable profiles, noting four to six may be available for one client and fewer for another, and checking that each URL lands on this business rather than a similarly named firm, category or mention. The article warns against adding 30 scraped directory listings to look substantial and against publishing an empty string for a missing optional entry.

Question 5

How do I validate the entity graph before putting it in the HTML?

Accepted Answer

The article recommends testing the complete JSON before wrapping it for HTML, using one check for structured-data validity and a separate check for rich-result eligibility. A message that no rich results were detected is not, by itself, a failure for this entity graph. The article advises fixing JSON errors and parsing errors but not removing valid entity markup to chase a visual search feature.

Question 6

How do I turn the first graph into a template for 15 domains?

Accepted Answer

The article recommends keeping the first live payload structure and replacing client-specific strings with tokens for domain, legal and brand names, address parts, phone, verified sameAs array, founder and service details, building the organization @id from the canonical domain. Generation can take under ten minutes for a 15-domain batch, while review and deployment remain separate work. For each payload, the article requires checking that @ids use the right canonical domain, comparing names, address and phone against visible site text and profiles, and confirming the live response contains application/ld+json before re-testing the live URL.