JSON-LD Markup: Describe One Page with Consistent Entities

Describe the page rather than the testing tool

JSON-LD markup expresses linked data using JSON syntax. On a website, it can describe the article, person or organization associated with a page. The useful starting point is the page's real content and identity, not a list of fields copied from an unrelated rich-result example.

The W3C JSON-LD 1.1 recommendation defines the format. A context explains how terms are interpreted, a type names what an entity is, and an identifier can let multiple descriptions refer to the same entity. These ideas are broader than any one search engine's supported display features.

Build a minimal fictional article description

This example names a fictional article and its author. The example.com URLs are placeholders for illustration. The author fragment should resolve to the actual author section or identity page in a real implementation.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "https://example.com/guides/map-notes/#article",
  "url": "https://example.com/guides/map-notes/",
  "headline": "Keep useful notes with a local map",
  "author": {
    "@type": "Person",
    "@id": "https://example.com/about#editor",
    "name": "Example Author",
    "url": "https://example.com/about#editor"
  }
}

Here the article's identifier is distinct from the author's identifier. Reusing the article URL as the person's identity would describe the relationship incorrectly. A stable fragment identifier can distinguish an entity from the web page that contains its description.

The headline and author name need to agree with the visible article. If the page credits an organization instead of a person, describe the real credited entity with the suitable type. Do not invent a person solely to satisfy an example's structure.

Embed data without creating executable content

A web page commonly places the serialized object in a script element whose type is application/ld+json. Its content is data, so do not write a JavaScript variable assignment around the object. JSON does not allow comments or a trailing comma after the last property.

When generating the element in an HTML template, use the framework's supported safe JSON serialization approach. The surrounding HTML parser still matters: an unescaped closing script sequence inside a string can terminate the element before the JSON parser sees it. Escaping a less-than character as a JSON Unicode escape is one way a serializer can prevent that boundary problem.

const data = {"headline": "Example </script> text"};
const serialized = JSON.stringify(data).replace(/</g, "\\u003c");
const restored = JSON.parse(serialized);
console.assert(restored.headline === data.headline);

This small example demonstrates preserving the data value while removing literal less-than characters from the serialized payload. It is not a replacement for the escaping rules of a particular template engine. Verify the final rendered HTML, especially when a title or description originates in editable content.

Keep shared entities and dates consistent

If several articles refer to the same real author, use that author's stable identity consistently. Do not create a new person identifier for each article merely because the title changed. Conversely, do not assign one identifier to two different people or to both a person and an organization.

Only include dates you can support. Preserve the original publication date and distinguish it from an actual content revision. If an image changes independently of the article body, review what your modification date represents and keep the visible editorial information truthful.

Inspect all JSON-LD blocks emitted by the page, including those supplied by a theme or plugin. Duplicate descriptions are not automatically errors, but conflicting facts about the same identified entity need resolution at their source.

Validate syntax, vocabulary and intended use

Start with a JSON parse check. Then verify the selected terms against Schema.org's Article vocabulary and inspect the relationship between the article and author. If the goal is a Google article feature, also consult the Google Article guidance and test the applicable rendered page.

The local JSON-LD Schema Markup Generator produces a basic starting object. It cannot know your real author, publication history or image rights. Review and complete the data using the visible page, and treat validation results as bounded checks rather than a promise of search visibility.

Related guides

WordPress JSON-LD: Inspect and Maintain the Rendered Markup

Find the JSON-LD WordPress already emits, choose one publishing owner, serialize content safely, and verify changes on rendered article pages.

JSON-LD vs Microdata: Keep One Consistent Article Identity

Compare equivalent JSON-LD and Microdata article examples, preserve nested author scope, and prevent conflicting markup during a migration.

FAQ JSON-LD: Model Questions Without Obsolete Search Claims

Create FAQPage JSON-LD from visible question-and-answer pairs, check pairing and escaping, and understand the retired Google FAQ search feature.