JSON-LD @graph Guide: @id, Schema & WordPress

What @graph and @id actually mean

The W3C JSON-LD 1.1 specification defines @graph as a JSON-LD keyword for expressing a graph and @id as the identifier for a node. “The @graph method” is an informal implementation label, not a proprietary Schema.org or Google feature.

Is one @graph block better than multiple JSON-LD scripts?

Not automatically. Google’s general structured data guidelines say Google can understand multiple items whether they are nested or specified individually. A single connected graph can still be the cleaner engineering choice when several page entities share the same Organization, Person, WebSite or WebPage.

The goal is not “one script at any cost.” The goal is one coherent set of facts. Two blocks that reference the same stable node can be valid; one graph containing contradictory names, URLs or authors is not.

When a connected schema graph is useful

• Publishing sites: connect BlogPosting → WebPage → WebSite and link author/publisher nodes.
• Personal brands: keep one Person identifier across the homepage, author pages and articles when the same real person is described.
• Companies: use one Organization identity and reference it from WebSite, Article, Product or Service nodes where the relationship is true.
• Ecommerce: connect Product, Brand, Offer, Review and page entities while following Google’s product-specific requirements.
• Multilingual sites: keep the business/person identity stable while page and article identifiers follow each locale’s canonical URL.

A graph is overkill when a page has one simple item, the CMS already emits correct markup, or the extra nodes describe facts that are not visible or supported on the page.

A valid Article graph with reusable nodes

This example connects five nodes with absolute, stable identifiers. Replace every value with facts visible on the real page and follow the current Google documentation for any rich-result feature you target.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Studio",
      "url": "https://example.com/",
      "logo": {
        "@type": "ImageObject",
        "url": "https://example.com/images/logo.png"
      }
    },
    {
      "@type": "Person",
      "@id": "https://example.com/about/#person",
      "name": "Jane Doe",
      "url": "https://example.com/about/",
      "worksFor": {
        "@id": "https://example.com/#organization"
      }
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "name": "Example Studio",
      "publisher": {
        "@id": "https://example.com/#organization"
      }
    },
    {
      "@type": "WebPage",
      "@id": "https://example.com/guides/json-ld/#webpage",
      "url": "https://example.com/guides/json-ld/",
      "name": "JSON-LD Graph Guide",
      "isPartOf": {
        "@id": "https://example.com/#website"
      }
    },
    {
      "@type": "BlogPosting",
      "@id": "https://example.com/guides/json-ld/#article",
      "headline": "JSON-LD Graph Guide",
      "image": "https://example.com/images/json-ld-guide.jpg",
      "datePublished": "2026-08-01",
      "dateModified": "2026-08-20",
      "author": {
        "@id": "https://example.com/about/#person"
      },
      "publisher": {
        "@id": "https://example.com/#organization"
      },
      "mainEntityOfPage": {
        "@id": "https://example.com/guides/json-ld/#webpage"
      },
      "isPartOf": {
        "@id": "https://example.com/guides/json-ld/#webpage"
      }
    }
  ]
}

The identifiers do not need to be separate public pages for every fragment, but they should be stable IRIs under a domain you control. Do not change #organization to #business on one template and #brand on another if all three are meant to identify the same organization.

How to choose stable @id values

sameAs is not a general citation list. Use it for URLs that clearly identify the same person or organization. A relevant article, directory category or partner page is not automatically “the same entity.”

Choose schema types by page purpose

Start with the page’s real visible purpose and the current platform documentation—not a list of types marketed as “AI schema.”

• Article or blog post: Article/BlogPosting plus accurate author, publisher, dates and page relationship.
• Product page: Product and the required/recommended properties for the Google product feature you target.
• Service page: Service can describe the offer, but it does not create a guaranteed Google rich result.
• FAQ content: only mark up questions and answers visible on the page. Google currently limits regular FAQ rich-result visibility mainly to authoritative government and health sites.
• How-to content: only use HowTo when the page genuinely contains an instructional process and after checking current feature support.
• Breadcrumbs: reflect the visible/canonical hierarchy rather than an invented keyword path.

Google’s structured data introduction treats its own feature documentation as definitive for Google Search behaviour. Schema.org includes many valid types and properties that do not correspond to a Google rich result.

WordPress: let one system own the base graph

The most common WordPress failure is not “too many script tags.” It is several systems describing the same entity differently: the theme outputs Organization, the SEO plugin outputs Person, a schema plugin outputs another WebSite, and a page builder adds a second Article.

1. Inventory every application/ld+json block in the rendered page.
2. Choose one owner for WebSite, WebPage, Organization/Person, Article and BreadcrumbList.
3. Disable overlapping theme or plugin output where possible.
4. Add page-specific types through the owner’s supported extension mechanism instead of pasting a second base graph into the editor.
5. Reuse the existing node IDs when a custom node references the same person, company, site or page.
6. Clear all caches and validate the rendered public HTML—not only the editor preview.

On maksut.net, MiniSEO owns the live graph. This article currently renders one JSON-LD block containing WebSite, WebPage, BlogPosting, BreadcrumbList and Person nodes. Adding the example above as executable markup would create competing identities, so the code remains a visible teaching example only.

Does schema markup improve AI citations?

Structured data provides explicit, machine-readable facts to systems that choose to parse it. However, there is no public OpenAI or Perplexity rule promising a citation increase from @graph, and no supported “2–3× citation multiplier.” Treat AI citation impact as a hypothesis to test, not a property of JSON-LD syntax.

For discoverability, the page still needs accessible HTML, useful and supported claims, a canonical URL, internal/external evidence and appropriate crawler access. Use the ChatGPT backlinks and citation guide for authority questions and the AI traffic guide for measurement.

Validate a JSON-LD graph in seven steps

1. Parse the JSON: catch commas, quoting and encoding failures before schema validation.
2. Use the Schema Markup Validator: check Schema.org syntax, types and properties.
3. Use Google’s Rich Results Test: check eligibility and feature-specific warnings for Google-supported types.
4. Compare with visible content: names, author, price, availability, dates, reviews and questions must be true and visible where required.
5. Check identity and URL consistency: canonical, @id, url, breadcrumbs and language must not conflict.
6. Inspect the rendered page: confirm production contains the expected graph once, after plugin and cache processing.
7. Monitor after deployment: use Search Console enhancement reports where available and sample templates after releases.

Use the Schema Markup Validator for the full Schema.org vocabulary and the Rich Results Test for Google-specific support. A green validator confirms syntax and supported requirements; it does not guarantee ranking, a rich result or an AI citation.

Multilingual graph rules

• Use each page’s real canonical URL for WebPage and Article identifiers.
• Set inLanguage to the content language; do not label English copy as Turkish because the site supports Turkish elsewhere.
• Keep the same Organization or Person @id across languages when it is the same real entity.
• Translate visible names and descriptions where appropriate, but do not translate Schema.org keywords such as @type or publisher.
• Do not publish hreflang relationships until a real, canonical translation pair exists.

US and UK pages can share the same business node while using market-specific page URLs, spelling, offers and evidence. Turkish pages need native page copy and locale-specific WebPage/Article identifiers, not a literal translation pasted onto the English canonical.

Common JSON-LD graph mistakes

• Claiming @graph is required: Google supports nested and individually specified items too.
• Adding every possible type: irrelevant or invisible markup can violate quality guidelines.
• Creating several IDs for one entity: inconsistent fragments split what should be one reusable node.
• Reusing one ID for different entities: two products, people or localized pages must not collapse into one node.
• Using sameAs as a source list: it should identify the same entity, not every relevant mention.
• Letting plugins compete: duplicate base entities often come from the theme, SEO plugin, builder and custom code together.
• Marking up hidden or invented content: structured data must represent what users can verify on the page.
• Assuming validation guarantees performance: eligibility and visibility are separate outcomes.
• Building JSON by unsafe string concatenation: use platform serializers such as WordPress wp_json_encode() and test escaping.

Build a maintainable schema system

A useful graph starts with template ownership and real entities, then connects only relationships the page can substantiate. Maksut.net’s AI SEO and search visibility service audits WordPress schema ownership, maps stable IDs, removes conflicts and validates commercial templates without creating duplicate JSON-LD.