Structured data and technical entity clarity
Why structured data
JSON-LD structured data (schema.org vocabulary) states facts about an entity explicitly, instead of leaving a machine to infer them from prose. It doesn't guarantee any particular ranking or citation outcome — see /methodology — but it does remove ambiguity a system would otherwise have to guess at.
What Metryn publishes about itself
| Type | Rendered where | Notable field |
|---|---|---|
Organization | Every page (root layout) | logo: https://getmetryn.com/icon |
WebSite | Every page (root layout) | publisher: {"@id": "https://getmetryn.com/#organization"} |
SoftwareApplication | Homepage only | applicationCategory: BusinessApplication |
None of the three includes a rating, a review, a customer count, or a founder/team claim — none of those are established facts Metryn can currently publish. Smaller and true beats complete and disputable.
What Metryn checks on scanned sites
A scan looks for <script type="application/ld+json"> blocks, confirms they parse as valid JSON with a @context and @type, and checks whether at least one node declares an organization-level entity (Organization, LocalBusiness, or WebSite). Invalid JSON-LD is flagged distinctly from JSON-LD that's simply absent — a syntax error is a confirmed defect, while absence is a recommendation to add one.
Validating your own
An independent validator — for example validator.schema.org — parses your JSON-LD without relying on Metryn's own scanner, which is a useful cross-check on any finding.