Schema Graph vs Schema Terpisah: Mana yang Lebih Mudah Dikelola

Satu halaman punya lima script JSON-LD.

Organization dari theme.

WebSite dari SEO plugin.

Article dari plugin lain.

Breadcrumb dari theme.

Person author dari custom code.

Semuanya valid sendiri-sendiri.

Masalah muncul ketika Organization pertama bilang nama A, Organization kedua nama B, Article menunjuk publisher dengan ID C, dan Person author punya worksFor ke Organization D.

Secara syntax, mungkin tidak ada error besar.

Secara graph, website sedang menceritakan empat versi realitas.

Lalu developer berkata:

“Biar rapi, gabungkan semuanya jadi satu `@graph`.”

Apakah itu solusi?

Bisa.

Tetapi `@graph` bukan obat otomatis.

Schema graph dan schema terpisah adalah dua cara packaging data. Yang lebih penting adalah apakah entity IDs, relationships, source of truth, dan ownership implementation konsisten.

Google structured-data guidelines menjelaskan bahwa multiple items pada page dapat ditulis sebagai individual items atau dihubungkan/nested, dan `@id` dapat membantu menghubungkan items yang related.

Jadi pertanyaannya bukan:

“Google lebih suka satu graph atau banyak script?”

Pertanyaan operasional:

“Arsitektur mana yang paling mudah dijaga benar oleh tim kita?”

Apa Itu “Schema Graph”?

Dalam JSON-LD, tim sering memakai satu script:

`@context`

`@graph`

Lalu array objects:

Organization.

WebSite.

WebPage.

Article.

Person.

BreadcrumbList.

ImageObject.

Each has `@id`.

Relationships reference IDs.

Example conceptually:

Article.publisher → Organization ID.

Article.author → Person ID.

WebPage.mainEntity → Article ID.

Article.isPartOf → WebSite ID.

This creates a connected graph.

Benefits:

Relationships are visible in one structure.

Duplicate entity definitions can be reduced.

Central governance becomes easier.

But graph can also become giant and brittle if every plugin touches it.

Apa Itu Schema Terpisah?

Multiple JSON-LD scripts or individual top-level objects.

Script 1:
Organization.

Script 2:
Article.

Script 3:
Breadcrumb.

Script 4:
Video.

They can still refer to same `@id`.

Separate scripts do not inherently mean separate entities.

If Organization always has canonical `@id`, Article can reference it even in different script.

So separate packaging can still form conceptual graph.

The problem isn't number of script tags.

The problem is inconsistent identity.

One Script Tidak Menjamin One Truth

Developer merges all into `@graph`.

Great.

But data sources:

Organization name hardcoded in theme.

Address from plugin.

Logo from option table.

Author from post meta.

Publisher ID generated from current URL.

Now one script contains conflict less visibly, but architecture still fragile.

Central graph is only as good as source mapping.

Need:

Entity registry.

Canonical IDs.

Template rules.

Data ownership.

Validation.

`@graph` doesn't create governance.

It just packages.

Multiple Script Tidak Berarti Salah

Google can understand multiple structured-data items on a page.

Documentation explicitly allows multiple items, nested or individual.

Example page may have Recipe, Video, Breadcrumb.

So don't rewrite site solely because “multiple scripts are bad.”

Audit first.

Are duplicate types conflicting?

Do IDs match?

Does content match visible page?

If scripts independent but coherent, maybe fine.

Large migration creates risk.

Solve actual issue.

The Real Enemy: Duplicate Organization Nodes

Common WordPress stack.

SEO plugin:
`https://site.com/#organization`

Theme:
`https://site.com/#org`

Custom runtime:
`https://site.com/about/#organization`

WooCommerce:
blank Organization object.

Same company.

Four IDs.

Now Article.publisher points one.

Product.seller another.

WebSite.publisher another.

This fragments machine representation.

Whether scripts separate or one graph, fix ID.

Canonical Organization ID is first priority.

Graph architecture begins with identity registry.

Not script consolidation.

Second Enemy: Contradictory Properties

Organization A:
name = PT X.

Organization B:
name = Brand Y.

Maybe actually Organization vs Brand.

If both use Organization type because plugin limitation, semantics wrong.

Merging into graph doesn't solve.

Need model:

Organization:
PT X.

Brand:
Brand Y.

Relationship.

Visible page.

Then map plugins or disable duplicate output.

Schema cleanup often means deleting, not combining.

Dialogue di Engineering Channel

SEO:
“Rich Results Test shows two Organizations.”

Developer:
“One from Rank Math, one from theme.”

Brand:
“Which one correct?”

Developer:
“Both use same logo.”

Legal:
“One uses brand name, one legal company.”

SEO:
“Can we merge?”

Entity architect:
“First decide whether they’re actually the same entity.”

That's the right sequence.

Packaging after semantics.

Single Graph Advantage: Centralized Relationships

For custom-managed site, one graph has clear benefits.

1. Easy to inspect.

2. Canonical IDs controlled.

3. Relationships explicit.

4. Duplicate output reduced.

5. Versioning easier.

6. One generator can use shared data.

7. QA can validate graph consistency.

8. Entity registry maps cleanly.

Example WordPress custom runtime:

Generate Organization once.

WebSite once.

WebPage.

Article based on post.

Breadcrumb.

Person based on author.

All reference shared IDs.

This is robust if one team owns it.

But it may conflict with plugins.

Need disable overlapping plugin schema.

Don't output both.

Single Graph Disadvantage: Blast Radius

One generator bug can break all markup.

If JSON encoding fails, everything gone.

If Organization source wrong, all pages wrong.

If deploy bad, sitewide impact.

Monolithic graph may be harder for teams with independent systems.

Article team.

Commerce team.

Events.

Recruiting.

Each has different data lifecycle.

One central runtime can become bottleneck.

Architecture must match org.

Not ideology.

Separate Schema Advantage: Modular Ownership

Commerce platform generates Product/Offer.

Editorial CMS generates Article.

Corporate shell generates Organization/WebSite.

Event system generates Event.

Each system owns its data.

Separate scripts can be cleaner because source ownership matches.

As long as shared identities are standardized.

Example:

Corporate config defines Organization canonical ID.

Editorial Article references it.

Commerce Product brand/provider references appropriate IDs.

No duplicate definition needed everywhere.

Module boundaries.

This can scale.

Separate Schema Disadvantage: Plugin Collision

If teams don't coordinate:

Each defines Organization.

Each defines Breadcrumb.

Each defines WebSite.

IDs differ.

Dates conflict.

Canonical URLs differ.

This is common.

Separate architecture requires schema contract.

Which module owns which type?

Who may reference?

Which IDs?

Without contract, entropy.

Use Ownership Matrix

Create table:

Type | Owner | Source | Canonical ID | Templates

Organization | Corporate runtime | entity registry | /#organization | sitewide reference.

WebSite | Core SEO | config | /#website | sitewide.

WebPage | Page runtime | URL | page#webpage | every indexable page.

Article | Editorial | post/CMS | article#article | editorial posts.

Person | People registry | profile | profile#person | author/team.

Product | Commerce | PIM | product#product | product.

Breadcrumb | navigation | routing | page#breadcrumb | applicable.

Now no ambiguity.

Separate or graph becomes implementation choice.

This matrix is the real governance.

`@id` Is the Glue

Google guidelines mention using `@id` to link items where relationship matters.

Schema.org/JSON-LD also treats IDs as identifiers for nodes.

If Organization canonical ID stable:

Article publisher can reference.

WebPage about can reference.

Person worksFor.

Product manufacturer.

Multiple scripts still connect conceptually.

No need redefine Organization property block in every script if consumer can resolve reference within page/data context, though implementation should be tested for target consumer.

Within one page, including core entity definition plus references can be practical.

The key:
same ID means same node.

Don't generate ID from plugin-specific naming.

Schema Graph Should Reflect Visible Page, Not Internal Database Entirely

One temptation:

“We have entity registry, dump all entities into `@graph` on every page.”

No.

Page about Product A doesn't need 300 Organization subsidiaries.

Google says structured data should apply to page content.

Keep graph page-relevant.

Global entities:

Organization.

WebSite.

Maybe Brand.

Page entities:

WebPage.

Article/Product.

Author.

Breadcrumb.

Relevant evidence/media.

Don't make JSON-LD sitemap.

Graph size should follow page semantics.

Central Graph Can Still Be Modular Internally

Good architecture:

Modules return nodes.

Organization module.

WebSite module.

Article module.

Breadcrumb module.

Person module.

Assembler merges by `@id`.

Deduplicates.

Validates.

Outputs one `@graph`.

This gives centralized output with modular code.

Best of both.

But custom engineering needed.

For WordPress sites with many plugins, this can be worth it.

Especially if schema is strategic.

However don't rebuild stable stack only for aesthetics.

Measure maintenance benefit.

Graph Deduplication Rules

When two modules return same `@id`:

Merge compatible properties.

Reject conflict.

Example:

Organization name same.

Logo same.

Good.

One says address Jakarta, one Bandung.

Flag.

Do not silently choose last write.

Conflict should fail QA.

This makes graph a truth validator.

If assembler simply overwrites, data errors hidden.

Schema runtime should surface conflicts.

Separate scripts also need equivalent audit.

Testing Needs Two Levels

Level 1:
Syntax/feature validation.

Rich Results Test.

Schema Markup Validator.

Search Console reports.

Level 2:
Graph semantics.

Duplicate IDs?

Same entity multiple IDs?

Conflicting types?

Wrong relations?

Canonical URL?

Visible content?

Current data?

Multiple scripts can pass Level 1 but fail Level 2.

Single graph can too.

Build semantic linter.

Even spreadsheet QA helps.

Plugin Strategy

If custom graph is authoritative, disable overlapping plugin schema outputs where possible.

Don't leave:

Plugin Organization.

Custom Organization.

Theme LocalBusiness.

Commerce seller.

All representing same entity differently.

But don't disable plugin feature without understanding dependency.

Maybe WooCommerce Product markup is robust and maintained.

Keep.

Custom graph references.

Maybe SEO plugin Breadcrumb useful.

Keep.

The goal isn't “custom everything.”

The goal is one owner per concept.

Use best source.

Avoid duplicate ownership.

Schema Separate untuk High-Change Data Bisa Lebih Aman

Product price changes often.

Article metadata stable.

Organization stable.

If one graph cached aggressively, product price might stale.

Modular commerce script can update faster.

Architecture should consider cache/lifecycle.

One output can still be dynamic per module, but complexity grows.

Data freshness > aesthetic unity.

Don't sacrifice current Offer for pretty graph.

Schema Graph untuk Institutional Site Biasanya Enak

GEO.or.id-style institutional site:

Organization.

WebSite.

WebPage.

Article/TechArticle/Report.

Person.

Breadcrumb.

Dataset occasionally.

Evidence.

No huge commerce.

A centralized graph can be manageable.

Canonical IDs matter.

Editorial types controlled.

Versioning easier.

But only if CMS workflow and team support.

If site relies heavily on plugins, a schema ownership audit may be first.

Don't jump to rewrite.

Which Is Easier?

Small site with one custom developer:
Single graph often easier.

Large modular platform:
Separate outputs with strong ID contract may be easier.

WordPress with many plugins:
Either simplify to one authoritative system or create clear ownership boundaries.

Enterprise microservices:
Modular schema generation likely natural, with central entity registry.

No universal winner.

"One `@graph` is better for SEO" is too simplistic. There is no general ranking guarantee from packaging style.

Choose maintainability.

Debugging Experience Matters

Single graph:
One place to inspect.

But one invalid comma can affect whole script.

Separate:
Easy isolate Product vs Article.

But cross-script conflicts harder to notice.

Choose tooling.

Build automated tests.

Sample pages.

Snapshot expected JSON-LD.

Diff on deploy.

If Organization ID unexpectedly changes, fail CI.

This is mature schema governance.

Versioning

Store schema generator version.

Example:
SCHEMA-RUNTIME-3.4.

When structure changes:

Changelog.

Test fixtures.

Rollback.

Don't edit PHP production ad hoc.

For separate modules, version each.

Commerce 2.1.

Editorial 4.0.

Core entity 1.8.

Then incident debugging knows what changed.

Schema is code.

Treat like code.

The Most Important Question: Can a Human Explain the Graph?

Pick page.

Ask:

What nodes?

Why?

Who owns each?

How linked?

Where data comes from?

If answer clear, architecture works.

If developer says:

“Plugin emits it, nggak tahu.”

Governance weak.

Whether one graph or separate doesn't matter.

Human auditability is quality signal.

Recommendation Praktis

Don't migrate for style. Audit first.

Step 1:
Inventory all JSON-LD scripts.

Step 2:
List node types and `@id`.

Step 3:
Detect duplicate entities.

Step 4:
Detect property conflicts.

Step 5:
Assign owners.

Step 6:
Choose canonical IDs.

Step 7:
Decide packaging.

Step 8:
Disable redundant generators.

Step 9:
Validate syntax + semantics.

Step 10:
Monitor after release.

Packaging is step 7.

Not step 1.

Schema Graph yang Bagus Terasa Seperti Satu Percakapan

Organization says who publisher is.

Article references same Organization.

Author references correct Person.

WebPage knows main content.

Breadcrumb follows real hierarchy.

Product references real Brand.

No one contradicts.

Whether that conversation is stored in one script or four scripts is secondary.

What matters is that all speakers agree on the same world.

If one `@graph` makes that easier for your team, use it.

If modular scripts with shared IDs are easier, use those.

The best schema architecture isn't the one with the prettiest JSON.

It is the one your organization can keep correct after the next redesign, plugin update, rebrand, employee change, and product launch.