Understand the vocabulary before writing the code
Schema.org defines types such as Organization and WebPage and properties such as name, url and about. A type identifies the kind of thing being described. A property supplies a fact or a relationship. JSON-LD expresses those statements in a JSON object that a website can publish in a script element.
The @context identifies the vocabulary. The @type identifies the entity type. The @id is an identifier that lets another statement refer to the same entity. An @graph groups several nodes. These are descriptive connections; they are not instructions to a search engine to recommend a business.
Start with the visible page and the verified business record. Choose the types that fit those facts. Do not begin with a long list of schema types and invent content to fill them.
A small connected example
Fictional example: a page called “About Example Home Services” describes a made-up organisation named Example Home Services. The URLs below use the reserved example.com domain for illustration. The page and organisation are different entities, connected by the page’s about property.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Example Home Services",
"url": "https://example.com/"
},
{
"@type": "WebPage",
"@id": "https://example.com/about/#webpage",
"url": "https://example.com/about/",
"name": "About Example Home Services",
"about": {"@id": "https://example.com/#organization"}
}
]
}The repeated organisation identifier connects the nodes without creating a second organisation. On a real site, retain a stable identifier for the same business and use the real canonical URLs. Coordinate this with any SEO plugin that already emits organisation or page markup.
This example is a learning graph, not a complete implementation for every business and not a declaration of eligibility for a particular Google feature.
How to ask ChatGPT to draft schema
Provide the visible page text, its canonical URL, the verified business facts and any existing markup. State which part of the graph the task covers. Ask for a factual mapping before requesting the final code: which supplied fact supports each proposed property?
Using only the supplied page and business facts, propose suitable Schema.org types and explain their purpose. Reuse the existing organisation @id. Do not add ratings, reviews, credentials, prices or locations unless the inputs support them. List missing facts separately. Then produce JSON-LD and a checklist for vocabulary, entity references, visible-content consistency and deployment verification. Do not claim that a validation tool was run unless you actually used it.Review the proposal before inserting it into a live website. If the platform or SEO plugin already owns a node, decide whether to extend that graph or change its configuration. Adding a second disconnected graph can create conflicting names, URLs or business details.
Validate syntax, meaning and implementation separately
- Parse the JSON. Fix invalid quotes, commas and braces. Valid JSON establishes syntax only.
- Check the vocabulary. Confirm types and properties against Schema.org and inspect references to shared IDs.
- Check factual consistency. Compare every business statement with the supplied facts and the visible page.
- Check supported search features. Use Google’s feature-specific documentation and Rich Results Test where a supported feature applies. That test is not a complete verdict on every Schema.org type.
- Check the deployed page. Inspect the actual output, confirm the intended canonical URL and look for duplicates or conflicting plugin markup.
Record which checks were performed, the tested URL and date, and any remaining limitation. A clean test does not prove that Google indexed the page or that an AI assistant will cite it.
Connect schema to A.S.A.P. and AI discovery
Authority supplies the evidence behind the statement. Semantics establishes the meaning of the entity and its relationships. Architecture publishes that meaning coherently through pages, links and markup. Performance checks what happens after implementation. Schema supports part of this system; it does not replace the others.
For Google AI features, helpful visible content and normal search eligibility remain foundational. There is no special schema type that guarantees inclusion. A useful page must still be accessible, understandable and relevant to the question being answered.
Continue with the prompting workflow to improve the input brief, or return to the AI SEO skills map. Approved staff use the private programme for the full schema activities and assessment.
Two practice checks
Consider each question before opening the explanation. These public checks are practice; graded staff assessments are inside the private portal.
A JSON-LD block parses successfully. Has its factual accuracy been established?
No. Parsing checks JSON syntax. The entities, vocabulary, page references, business facts and rendered implementation still need separate checks.
Can a trainee add five-star ratings to strengthen AI recommendations when no reviews were supplied?
No. Structured data must reflect supported information. Remove the invented rating rather than treating markup as a substitute for evidence.
Sources & further reading
Use primary documentation to verify technical details. Click2Flow’s framework reference describes the agency’s own method.
Build understanding into a repeatable skill.
Explore another public guide, or sign in to the assessed staff programme if your employee account and browser are approved.
The Training Centre is part of Click2Flow, the AI SEO engineering agency.