Structured data governance
Generate and validate connected JSON-LD for nutrition entities
Contents
Build and inspect connected JSON-LD drafts that describe food records, source data, nutrition tools, and editorial trust entities.
Best use
- Generate graph drafts for food profiles, dataset pages, tools, categories, and reviewer entities.
- Check whether FDC IDs, USDA source links, authors, reviewers, and publisher nodes are connected.
- Use the output as a validation and transparency aid before production schema is approved.
Source and safety model
Outputs should stay connected to visible page content, source-backed nutrition data, clear assumptions, and educational limitations. This improves user trust while keeping the page understandable to crawlers and retrieval systems.
Semantic entity segmentation
Food graph
Connect WebPage → Food → source identifier → USDA dataset → publisher, with nutrition values only when visible on the page.
Tool graph
Connect each tool page to one SoftwareApplication node, visible FAQ content, methodology notes, and publisher identity.
Trust graph
Connect Organization and Person nodes only when the visible page accurately supports publisher, author, or reviewer claims.
Should this replace Rank Math?
No. It should merge with Rank Math safely and avoid duplicate or conflicting graph nodes.
What is the highest-value check?
Confirm that each food entity has a stable FDC ID, a real canonical page URL, and a USDA source reference.
Structured-data validation checklist
FDC identity
Food records should expose a canonical FDC ID and source URL.
Stable @id policy
Graph nodes should use stable page anchors such as #food, #nutrition, #webpage, and #software.
Rank Math bridge
Keep Organization, WebSite, and BreadcrumbList nodes while avoiding duplicate Article/WebPage conflicts.
Visible FAQ match
FAQPage schema should only exist when the questions are visible on the page.
No tool pollution
WebApplication nodes should live on tool pages, not every food profile.
Review truthfulness
Only add reviewedBy when a qualified reviewer actually reviewed the page.
Entity count verification
How broader food-entity claims should be verified
Use 7,793 SR Legacy foods as the safe public baseline until broader USDA-derived entities are batch-matched to published URLs, source records, and visible nutrition data.
Match source IDs
Each candidate entity must have a valid FDC ID or approved source identifier.
Confirm published URL
Do not count records that do not resolve to an indexable eNutritionFacts page.
Verify visible values
Nutrition values used in schema should also be visible or clearly linked on the page.
Audit freshness
Branded-food and prepared-food records need formula/date checks before broad public claims.
Claim only verified totals
After the batch passes, expose the verified count in the homepage and dataset schema.
No silent inflation
If source or URL validation fails, keep the conservative SR Legacy count in public copy.
Schema governance QA
Inspect the structured data rendered on this page
This inspector reads the JSON-LD already printed on the current page, checks for duplicate @id values, Rank Math overlap, source URL quality, and graph connectivity, then creates a local QA report. It does not send schema or page content to the server.
Click “View structured data” to generate the local schema QA report and graph map.
Nutrition Tools · RAG output fragments
Generate safe JSON-LD fragments for public nutrition examples
Safe Mode creates preview-only structured-data fragments for generic macro examples or cached-FDC meal examples. It does not auto-inject schema, does not expose private biometric fields, and should only move to production after the same result is visibly published on a stable URL and approved in Schema QA.
- No automatic production injection from private calculator output.
- Only generic public macro examples or cached-FDC meal examples are generated.
- Schema QA approval is a ledger step, not a ranking or rich-result guarantee.