Cara Audit Schema Relationship Antar-Page

Schema audit sering berhenti di halaman.

Homepage valid.

Article valid.

Product valid.

Author page valid.

About page valid.

Semua terlihat aman.

Masalah baru muncul ketika kita melihat hubungan antarhalaman.

Article mengatakan publisher adalah Organization A.

About page mendefinisikan Organization B.

Person page mengatakan worksFor Organization C.

Product page mengatakan manufacturer Organization D.

Semua nama terlihat mirip.

Semua script valid.

Tetapi graph site secara keseluruhan tidak punya satu identity yang konsisten.

Ini reason schema relationship audit harus melampaui page-by-page validation.

Website besar bukan kumpulan JSON-LD independen.

Ia jaringan object.

WebPage.

Article.

Person.

Organization.

Brand.

Product.

Dataset.

Report.

LocalBusiness.

Relationships antar-node itulah yang membuat graph bisa dibaca sebagai satu sistem.

Kalau node benar tetapi edges salah, graph tetap salah.

Mulai dari Relationship yang Paling Penting

Jangan audit semua property sekaligus.

Mulai core.

Article → author → Person/Organization.

Article → publisher → Organization.

WebPage → mainEntity → primary entity.

Thing → mainEntityOfPage → canonical page.

Person → worksFor → Organization.

Product → brand → Brand.

Product → manufacturer/provider → Organization.

Organization → parentOrganization/subOrganization.

Dataset → creator/publisher.

Report → author/publisher.

Breadcrumb → page hierarchy.

These relationships define site identity.

If wrong, impact luas.

A `mentions` edge yang kurang mungkin low priority.

Publisher wrong:
high.

Entity relationship audit should use risk.

`mainEntity` dan `mainEntityOfPage` Harus Masuk Akal Dua Arah

Schema.org defines `mainEntity` as the primary entity described in a page or other CreativeWork.

`mainEntityOfPage` is inverse relationship indicating a page for which a Thing is the main entity described.

Example:

About page:
WebPage mainEntity Organization X.

Organization X:
mainEntityOfPage About URL.

Conceptually coherent.

Product page:
WebPage mainEntity Product Y.

Article:
Article mainEntityOfPage article URL, depending modeling style.

Problems:

Page A says mainEntity Organization X.

Organization X says mainEntityOfPage Page B.

Could be okay if B canonical entity page and A is another page about it, but if A claims primary/canonical relationship while B claims another, need review.

The goal isn't force every inverse property pair.

The goal is no contradictory canonical identity.

Ask:
Which page is primary representation of this entity?

Then relationships should reflect.

Publisher Must Be Same Organization Across Editorial Pages

Publisher relation is frequent source of fragmentation.

Article 1:
publisher @id `/#organization`.

Article 2:
publisher @id `/about/#organization`.

Report:
publisher name “GEO Indonesia”.

Homepage:
Organization name “GEO.or.id”.

Is this same Organization?

If yes:
one canonical ID.

Different visible labels can be alternate/correct naming, but identity should align.

If different publishers truly exist:
separate.

Maybe journal section published by Research Institute, while parent website by Association.

Then graph should say so.

Audit shouldn't merge everything mechanically.

Relationship truth first.

Author Relationship Needs Cross-Page Verification

Article says author Person A.

Click author URL.

Profile page mainEntity Person B.

Names similar.

Wrong.

Or Article:
author URL points `/author/admin/`.

Profile:
Organization.

Or multi-author article schema has one Person only.

Audit:

Byline visible.

Article author node.

Author URL.

Profile main entity.

sameAs.

worksFor.

All should agree.

Google's Article guidance recommends using author `url` or `sameAs` to help identify the author.

So cross-page identity is meaningful.

Don't create author URLs that resolve to unrelated profile.

Person Entity Could Work for Multiple Organizations

Audit must avoid simplistic rule:

“worksFor must equal publisher.”

Freelancer writes for publisher.

Author worksFor another university.

Guest expert.

Fine.

Article publisher:
GEO.or.id.

Author:
Person A.

Person worksFor:
University B.

No conflict.

The relationship graph describes reality.

Do not force Person worksFor publisher just to create tighter graph.

Schema shouldn't invent employment.

Cross-page audit needs semantic judgment.

Product → Brand → Organization

Product page:

brand Brand X.

Brand hub:

mainEntity Brand Y.

Organization page:

owns/operates Brand X in visible content.

If Product references Brand X ID but Brand hub defines Brand X with another ID:
duplicate.

If Product schema says brand Organization because plugin lacks Brand model:
maybe semantically weaker but common.

Audit objective:
understand actual relationship.

Brand is not automatically Organization.

Product manufacturer/provider can be Organization.

Brand can have owner/operator Organization.

Don't compress.

Entity graph needs node boundaries.

LocalBusiness Relationship to Parent

Branch page:
LocalBusiness Kemang.

Parent:
Organization X.

Another branch:
LocalBusiness Senopati.

Parent:
Organization Y with same name.

Potential duplicate parent.

Audit:

Are X/Y same organization?

If yes:
canonical ID.

If franchise:
maybe operators differ.

Don't merge.

Visible branch page should explain.

Entity relationship audit is where franchise vs company-owned structure surfaces.

This is why schema cannot be audited by validator alone.

Dataset and Report Relationship

Research page may have:

Report.

Dataset.

Organization.

If Report and Dataset both have creator Organization X:
good.

If dataset says creator Person A, Report says creator Organization B:
could be true.

Need method.

Relationship may be:
Person collected data.
Organization published.
Report authored by team.

Don't force identical roles.

Audit role semantics:

creator.

author.

publisher.

provider.

sponsor.

Each means different thing.

“Same names everywhere” is not consistency if roles differ.

Consistency is compatible truth.

Cross-Page `@id` Inventory

Create table.

`@id` | Type | Pages found | Name | Role

Example:

`https://site.id/#organization`
Organization
homepage, articles, product
GEO.or.id
publisher/provider

`https://site.id/about/#organization`
Organization
About only
GEO.or.id
main entity

Potential duplicate.

Then decide.

Maybe About node should use global Organization ID and WebPage own ID separately.

Once fixed, graph consolidates.

This inventory is one of highest-value audit outputs.

Because duplicates become obvious.

Without table, each page looks fine.

Relationship Graph Visualization Bisa Membantu, tapi Table Lebih Penting

Graph visualization looks cool.

Nodes.

Edges.

Colors.

Useful for spotting islands.

But auditors need details.

Table:

Source node.

Predicate.

Target node.

Source page.

Target page.

Evidence.

Status.

Example:

Article 123
publisher
Organization X
/article-123/
/
PASS

Person A
worksFor
Organization X
/author/a/
/
PASS

Product B
brand
Brand C
/product/b/
/brand/c/
PASS

Product D
brand
Organization X
/product/d/
/
REVIEW

Now action clear.

Visualization is secondary.

Auditability first.

Orphan Entity Node

Entity exists in schema but no canonical page or relationship.

Example:
Person node embedded in Article with no URL.

Could be okay for one-off author if enough identity fields.

But if same Person authors 100 articles:
canonical profile may help.

Organization node appears on Product but no Organization page.
Maybe site doesn't need separate page?
At least official URL.

Audit doesn't mean every node needs page.

Ask:
Does entity require canonical identity page?

Important recurring entities often benefit.

Minor entities can remain embedded.

Avoid thin-page explosion.

Broken Relationship Target

Article.publisher `@id` points URI that never appears anywhere.

Not necessarily invalid if URI is identifier only.

But if policy says canonical IDs should resolve to entity pages, then broken.

Need internal contract.

Don't assume every `@id` must be clickable URL according to Schema.org.

`@id` is identifier URI.

However using stable web URLs/URIs is common practical pattern.

Your audit must follow chosen policy.

Document:
resolvable or non-resolvable IDs?

Then test accordingly.

No shifting standards mid-audit.

Canonical URL Relationship Is Critical

Page canonical:
URL A.

WebPage `@id`:
URL B#webpage.

Article `mainEntityOfPage`:
URL C.

Breadcrumb last item:
URL D.

If A/B/C/D represent variants:
www.
non-www.
HTTP.
HTTPS.
trailing slash.
parameters.

Graph looks fragmented.

Article 270 goes deeper.

For relationship audit:
normalize and compare.

Canonical mismatch is one of first checks.

Google defines canonical URL as representative URL among duplicate pages.

If structured references point duplicate variants inconsistently, site sends mixed signals.

Fix canonical strategy.

`about`, `mentions`, `subjectOf`: Don't Use as Generic Link Labels

Custom schema often uses these as “connected content” fields.

But semantics matter.

`about`:
subject matter.

`mentions`:
mentions entity.

`subjectOf`:
CreativeWork/Event where thing is subject.

Don't use all interchangeably.

Example:
Article primarily about Organization A:
`about` Organization A.

Article only briefly mentions Partner B:
`mentions` Partner B.

Organization A has press article about it:
could be `subjectOf` where appropriate.

If every linked page is marked `about`, graph overstates relevance.

Relationship audit should sample.

Ask:
Does edge describe actual content relation?

Not:
“Is URL linked?”

Hyperlink and semantic relation different.

`isPartOf` / `hasPart` Needs Hierarchy Truth

WebPage isPartOf WebSite:
common.

Report chapter isPartOf Report:
possible.

Page isPartOf Category?
Depends model.

Don't use `isPartOf` as internal-link replacement.

If every page isPartOf 12 entities, hierarchy loses meaning.

Audit:

What is container?

What is component?

Direction?

Example:
Article isPartOf Publication series.

Series hasPart Article.

Clean.

Category navigation alone may not constitute semantic part-whole relation depending architecture.

Use carefully.

Breadcrumb is better for navigation hierarchy.

Page Graph vs Entity Graph

Separate audit layers.

Page graph:
WebPage.
Article.
Breadcrumb.
URLs.
canonical.
isPartOf.

Entity graph:
Organization.
Person.
Brand.
Product.
Place.

Bridge relationships:
mainEntity.
about.
author.
publisher.
provider.
brand.

This separation makes debugging easier.

If page graph clean but entity wrong:
identity problem.

If entity clean but URLs inconsistent:
page/canonical problem.

Without layers, audit becomes one giant list.

Practical Relationship Audit Pipeline

1. Crawl indexable pages.

2. Extract all JSON-LD.

3. Flatten graph nodes.

4. Normalize `@id`.

5. Record type/name/URL.

6. Record relationships.

7. Group identical IDs.

8. Detect same name/type with multiple IDs.

9. Detect one ID with conflicting type/name.

10. Validate target nodes.

11. Compare visible content.

12. Compare canonical.

13. Assign severity.

Automate first 10.

Human review 11 and semantic conflicts.

Large site manageable.

Severity Framework

Critical:
Wrong legal entity.
Wrong price/offer.
Wrong author in regulated content.
Wrong parent/subsidiary.
Privacy leak.

High:
Duplicate Organization IDs sitewide.
Broken publisher.
Wrong mainEntity.
Canonical mismatch.

Medium:
Missing Person URL.
Weak about/mentions semantics.
Duplicate Breadcrumb.

Low:
Optional relation missing.

This prioritizes.

Don't fix cosmetic before identity.

Cross-Template Regression

Once relationships fixed, tests.

Article publisher ID must equal canonical Organization ID.

Author URL must resolve to ProfilePage/Person identity.

Product brand ID must exist in Brand registry.

LocalBusiness parent must exist.

WebPage mainEntity ID must exist on page/registry.

Canonical URL must match WebPage identity policy.

Automated assertions.

When theme/plugin updates:
run.

This turns relationship audit into governance.

One-time audit without regression becomes stale.

Cross-Domain Relationship

Corporate domain and product domain.

Article publisher on product domain may reference corporate Organization.

Good if true.

But internal crawler sees external `@id`.

Don't flag as broken merely because different domain.

Check official relationship.

Canonical entity registry supports multi-domain.

Similarly local country sites.

Parent Organization global.

Local Organization separate.

Relationships need market/legal accuracy.

Cross-domain audit is harder but more important.

Don't collapse organizations by name alone.

Human Conversation that Should Happen

Developer:
“Graph says Product A provider Organization X.”

Product:
“Actually subsidiary Y provides it.”

Legal:
“Brand X is owned by parent but contracts come from Y.”

SEO:
“Which one should schema say?”

Answer depends what property means.

Don't choose based on desired authority.

Choose business truth.

Maybe:
brand X.
provider Y.
parent X group relation separately.

Schema audit can reveal company governance complexity.

That's useful.

It is not an inconvenience to hide.

AI Visibility Impact Is Secondary

If relationship cleanup reduces duplicate entity mapping, great.

Could AI answers become more accurate?

Reasonable hypothesis.

Will citations rise?
Unknown.

Measure.

Primary acceptance:
graph consistency.

Correct IDs.

Correct roles.

No conflicts.

Visible truth.

Canonical stability.

This is controlled.

External AI behavior remains observation.

Don't promise.

A Site-Wide Schema Graph Should Answer Simple Questions

Who publishes this article?

Who wrote it?

What organization does this profile represent?

Which brand owns this product?

Which company operates this branch?

Which dataset supports this report?

Which page is canonical for this entity?

If answers change depending which URL you open, relationship audit is needed.

Schema quality isn't page-local.

It is network quality.

A validator can tell you whether one node is formed correctly.

Only a relationship audit can tell you whether the website is telling one coherent story across hundreds of nodes.

And at scale, coherence is the part that matters most.