Schema dan Canonical URL: Kesalahan Kecil yang Bikin Graph Tidak Konsisten

Ada bug yang kelihatannya receh.

Canonical page:
`https://example.id/artikel/geo/`

WebPage `@id`:
`https://www.example.id/artikel/geo#webpage`

Article `mainEntityOfPage`:
`http://example.id/artikel/geo/`

Breadcrumb:
`https://example.id/artikel/geo?ref=nav`

Satu content.

Empat URL.

Browser mungkin redirect.

User tidak peduli.

Graph peduli.

Search engine juga harus memilih representative URL di antara duplicates.

Google mendefinisikan canonicalization sebagai proses memilih URL representative dari content yang duplicate atau sangat mirip. Google bisa memilih canonical berdasarkan berbagai signals, dan `rel="canonical"` adalah salah satu signal kuat yang publisher gunakan untuk menyatakan preference.

Structured data tidak menggantikan canonicalization.

Tetapi jika structured node terus menunjuk URL variants yang berbeda, website menciptakan identity noise.

Ini bukan berarti satu mismatch otomatis menghancurkan ranking.

Jangan dramatis.

Tapi pada website besar, “kesalahan kecil” dikali 50.000 page menjadi graph inconsistency yang nyata.

Canonical URL Adalah Page Identity, Bukan Entity Identity

Kita perlu membedakan.

Canonical URL:
representative URL untuk web page/content.

Entity `@id`:
identifier untuk Thing dalam graph.

Kadang entity `@id` memakai URI berbasis canonical URL.

Kadang tidak.

Contoh:

WebPage:
`https://example.id/about/#webpage`

Organization:
`https://example.id/#organization`

Canonical page:
`https://example.id/about/`

Good.

Organization is not the page.

Page describes Organization.

Do not make Organization `@id` change every time page slug changes if policy intends stable entity URI.

Canonical URL policy and entity ID policy interact.

They are not identical.

This distinction prevents many migration bugs.

Google's Canonical Decision Can Differ from Yours

You set:

`rel="canonical"` → URL A.

Google may select URL B if other signals conflict.

Google Search Console can show user-declared vs Google-selected canonical in URL Inspection.

Why could differ?

Redirects.

Internal links.

Sitemap.

Content.

HTTPS.

Duplicate variants.

Canonical annotations.

Google chooses representative.

So structured data audit should not assume declared canonical is always selected.

For critical templates, inspect Google-selected canonical.

If consistently different, fix canonical signals.

Don't simply force JSON-LD to whichever URL you want and ignore Search canonicalization.

Canonical governance needs whole site.

Trailing Slash Inconsistency

These look almost same:

`/about`
`/about/`

Server may return both 200.

If canonical uses slash but WebPage ID no slash:
two URIs.

If server redirects:
less severe, but still noisy.

Pick convention.

Apply:

rel canonical.

sitemap.

internal links.

structured data URLs.

hreflang.

Open Graph if appropriate.

redirects.

Consistency.

Don't generate links from different utilities with different slash rule.

Route helper should centralize.

www vs non-www

Classic.

Canonical:
non-www.

Schema:
www.

sameAs:
non-www.

Logo URL:
www CDN maybe fine for asset.

Page URL identity should follow canonical host.

If Organization official URL uses canonical domain:
consistent.

If www redirects, not fatal.

But why keep old host in structured page identity?

Migration maybe.

Clean.

One host policy.

Sitemap and structured output should use canonical host.

HTTP vs HTTPS

If site fully HTTPS:

Do not keep `http://` in canonical page IDs.

Redirect works, but identity URI differs string-wise.

Search canonicalization can consolidate.

Graph consumer may not.

Use HTTPS current URLs.

Audit legacy plugin settings.

Especially custom code written pre-migration.

A single hardcoded constant can leak HTTP across thousands pages.

Easy fix.

Huge consistency gain.

Parameters

Tracking:
`?utm_source=`

Sorting.

Session.

Referral.

Product variant.

Pagination.

Some parameter URLs are duplicates.

Some represent different state/content.

Canonical strategy decides.

Structured data should usually reference the page's canonical identity, not transient tracking URL.

If JSON-LD generated from `window.location.href`, user arriving through campaign may output UTM variant as page URL.

Bad.

Generate server-side canonical URL.

Not request URL blindly.

This is common JavaScript bug.

Dynamic canonical identity should be deliberate.

Article mainEntityOfPage

Schema.org defines `mainEntityOfPage` as page or CreativeWork for which a Thing is the main entity described.

For an Article object, commonly used to connect it to the page that primarily represents it.

If Article `mainEntityOfPage` points noncanonical variant while WebPage canonical points another, graph says primary page is duplicate variant.

Fix.

Use canonical page URI according to site policy.

Don't cargo-cult exact code examples without understanding.

The relationship should express your actual page identity.

WebPage `url` vs `@id`

`url`:
URL of item.

`@id`:
identifier in JSON-LD graph.

Common pattern:

WebPage @id = canonical#webpage.
WebPage url = canonical.

Article @id = canonical#article.
Article mainEntityOfPage = WebPage ID or canonical.

This pattern is coherent.

Not universal requirement.

But if adopted, use everywhere.

Problem isn't which fragment.

Problem is random variation:

#webpage.
#WebPage.
#/webpage.
?schema=page.

All from different plugins.

One policy.

Canonical Page Changes after Slug Migration

Old:
`/ai-search/`

New:
`/guides/ai-search/`

301 old → new.

rel canonical new.

What about:

Article `@id`?

WebPage `@id`?

Entity hub `@id`?

Need migration rule.

For page/work identity, using new canonical-based IDs may be appropriate if IDs are derived from URL.

But references from other pages need update.

If Organization identity was based on old About URL:
more risky.

Stable entity ID should perhaps not depend on movable content slug.

This is why entity ID policy matters before migration.

Do not decide during redirect incident.

Versioning article 266 covers contract.

Canonical migration must update graph relationships.

Dataset Canonical Shows the Principle

Google Dataset documentation explicitly recommends adding structured data about a dataset to the canonical pages. If structured data appears on multiple copies, Google recommends using `sameAs` to link to the canonical page.

This is a clear case where canonical identity and structured data should align.

Dataset repositories often have:

landing page.

search listing.

mirror.

download.

Don't make every listing new Dataset identity.

Canonical page anchors.

The same general discipline is useful elsewhere even if exact property guidance differs.

One content/entity, intentional canonical representation.

Duplicate Pages Can Carry Same Structured Data

Google's general structured-data guidelines say that if duplicate pages have the same content, Google recommends placing the same structured data on all duplicates, not only canonical.

This surprises some teams.

“Kalau canonical, kenapa duplicate ada schema?”

Because duplicate page still describes same content.

But structured data must remain consistent.

This doesn't mean create different IDs per duplicate.

If content same:
same representation.

Canonicalization still tells representative URL.

Structured data doesn't replace canonical.

Again:
separate layers.

Canonical Tag Jangan Dipakai untuk Entity Merge

Parent company page.

Subsidiary page.

Similar description.

Don't canonical subsidiary to parent just to “combine entity.”

Product page.

Brand page.

Don't canonical Product to Brand.

Founder profile.

Organization page.

Don't.

`rel="canonical"` is for duplicate/similar page URL representative selection.

It is not a knowledge-graph equivalence instruction.

Entity relationships need proper content/schema.

Misusing canonical can remove distinct pages from Search representation.

Technical SEO and entity strategy must stay separate.

Pagination and Multi-Part Content

Google Article documentation has technical guidance for multi-part articles: canonical should point to each individual page or a view-all page, rather than automatically pointing every part to page 1.

Why mention here?

Because canonical shortcuts often seem neat but change content identity.

If article part 2 has unique content, canonicaling to part 1 can misrepresent.

Schema Article on part 2 then points one thing while canonical says another.

Follow current Google pagination/content guidance.

Don't use canonical as hierarchy.

Breadcrumb handles hierarchy.

Canonical handles representative duplicate URL.

Hreflang also Different

Indonesian page.

English page.

Same topic.

Not duplicate language content for canonical merging by default.

Use hreflang architecture when appropriate.

Each language usually self-canonical in standard international SEO patterns.

Structured data should use local page URLs and language-appropriate visible content.

Shared Organization entity may remain same.

Article work might be translation relation.

Don't canonical English to Indonesian just because same subject.

Canonical URL is not translation relation.

Different layer.

Cross-Domain Canonicals Require Care

Google supports cross-domain canonical.

Useful for syndicated duplicate content.

But it is strong signal.

If partner republishes full article:
cross-domain canonical can point original if arrangement.

If article merely similar:
don't.

Structured data publisher/author must still reflect page publication truth.

Syndicated copy may have publisher relation to syndicator or original depending editorial structure, but content attribution needs accurate modeling.

Don't create false publisher identity because canonical points elsewhere.

Canonical doesn't transfer Organization identity.

One URL signal shouldn't rewrite whole graph.

Canonical Mismatch Audit

For every indexable page collect:

Final URL.

HTTP status.

rel canonical.

Google-selected canonical if available/sample.

Sitemap URL.

Internal link preferred URL.

WebPage `url`.

WebPage `@id`.

Article/Product `@id`.

mainEntityOfPage.

Breadcrumb last URL.

Open Graph URL maybe.

hreflang self-reference where relevant.

Normalize.

Compare.

Status:

PASS:
all compatible.

WARN:
redirected variant referenced.

FAIL:
different content/entity URL.

Then fix generator.

This table makes canonical bugs obvious.

Don't manually inspect source one by one at 10k pages.

Pattern detection.

Plugin Collision

SEO plugin sets canonical.

Custom runtime computes `@id`.

Theme creates breadcrumb.

They use different URL helpers.

One strips trailing slash.

One keeps.

One uses request host.

One uses WordPress home URL.

Root cause:
three canonicalization functions.

Create one site canonical URL service/helper.

All consumers use.

Schema.

Breadcrumb.

Sitemap.

Internal links.

Open Graph.

This is engineering hygiene.

Not SEO magic.

Migration Should Have Canonical Contract

Before changing domain/slugs:

Old URL.

New URL.

Redirect.

Canonical.

Sitemap.

Internal links.

Schema IDs.

Entity IDs.

Hreflang.

Feeds.

External high-value profiles.

After migration:
crawl.

Check redirect chains.

Check Google-selected canonical over time.

Check schema relationship.

If structured graph left old URLs indefinitely, identity fragmentation can persist.

Don't wait for random audit.

Canonical migration includes JSON-LD.

Canonical and AI Search

Could consistent canonical URLs help downstream AI systems find the intended source?

Plausible indirectly through cleaner Search/index representation.

But exact AI retrieval behavior varies.

Don't claim:

“Canonical schema alignment raises ChatGPT citations.”

What we can say:

Google uses canonicalization to select representative URLs for duplicate content.

Structured-data references should not contradict site URL identity.

A clean graph reduces internal inconsistency.

Then measure AI citation/source selection separately.

No overclaim needed.

Small Errors Multiply

One article with:
www mismatch.

No crisis.

50,000 articles:
publisher references multiple host forms.
WebPage IDs split.
Breadcrumb paths vary.
Dataset duplicates.

Now graph analysis sees multiple node identities.

Data warehouse sees duplicate URLs.

Internal link reports fragment.

Search canonicalization does more cleanup work.

External consumers receive noisy data.

That's why “small URL normalization” matters at scale.

The site should make its preferred reality obvious.

One Preferred Page, One Consistent Graph

Canonicalization says:
This is the representative URL.

Structured data should say:
This page and its main entity are represented consistently.

Internal links should say:
Go here.

Sitemap should say:
This URL matters.

Redirects should say:
Old variants move here.

When all layers align, website stops arguing with itself.

That's the goal.

Not ranking magic.

Not AI trick.

Just identity hygiene.

And in any graph system, identity hygiene is what prevents one thing from accidentally becoming four.