schema.org Structured Data: How to Build a Connected Graph

On most sites structured data looks like this: a plugin adds Organization, a theme adds Article, another plugin adds Breadcrumb. None of the three knows about the others. The result is technically valid but semantically weak markup.

What does a connected graph mean?

schema.org lets you define multiple nodes in one document inside a @graph array. When you give each node a unique @id and reference that identifier from other nodes, you are telling the search engine "the publisher of this article is that organisation I defined at the top of the page".

The difference: with scattered markup the engine has to guess relationships. In a connected graph, relationships are declared explicitly.

A minimum viable graph

For a corporate site, five nodes are enough:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": ["Organization", "ProfessionalService"],
      "@id": "https://site.com/#organization",
      "name": "Brand Name",
      "url": "https://site.com/",
      "logo": { "@type": "ImageObject", "url": "https://site.com/logo.png" },
      "sameAs": ["https://linkedin.com/company/...", "https://instagram.com/..."]
    },
    {
      "@type": "WebSite",
      "@id": "https://site.com/#website",
      "url": "https://site.com/",
      "publisher": { "@id": "https://site.com/#organization" }
    },
    {
      "@type": "WebPage",
      "@id": "https://site.com/blog/post#webpage",
      "isPartOf": { "@id": "https://site.com/#website" },
      "about": { "@id": "https://site.com/#organization" }
    },
    {
      "@type": "Article",
      "@id": "https://site.com/blog/post#article",
      "mainEntityOfPage": { "@id": "https://site.com/blog/post#webpage" },
      "publisher": { "@id": "https://site.com/#organization" },
      "author": { "@type": "Person", "name": "Author Name" },
      "datePublished": "2026-07-16T09:00:00+03:00",
      "dateModified": "2026-07-16T09:00:00+03:00"
    },
    {
      "@type": "BreadcrumbList",
      "@id": "https://site.com/blog/post#breadcrumb",
      "itemListElement": []
    }
  ]
}

One thing to note: @id values need not match real URLs exactly, but they must be unique and consistent. Using a fragment (#organization) is common and recommended practice.

Common nodes and when you need them

The six most common mistakes

1. Marking up data not visible on the page. To add FAQPage schema there must be a real Q&A section on the page. Otherwise you risk a manual action.
2. Conflicting Organization definitions on one page. If a plugin and a theme both inject one, disable one of them.
3. Wrong date format. ISO 8601 with a timezone is required: 2026-07-16T09:00:00+03:00.
4. Using relative URLs. Every URL inside the schema must be absolute.
5. Inventing aggregateRating. Fabricated rating markup is penalised.
6. Auto-setting dateModified to today. Changing the date when content has not changed costs trust.

Validation workflow

• Schema Markup Validator (validator.schema.org): catches syntax and type errors.
• Google Rich Results Test: shows which rich result types you qualify for.
• Search Console > Enhancements: aggregate error tracking on the live site. This is the source to trust.

Before going live, always test three page types: the home page, a service page and a blog post. Template-level errors surface with those three samples.

Why it matters for GEO

AI systems interpret text to understand what a page is about — but where structured data exists, no interpretation is needed. Who provides this service, when was it updated, in what location is it offered: the answers are written explicitly in the graph. That clarity noticeably reduces the chance of a model summarising you incorrectly.