WebPage, Article, TechArticle, atau Report: Kapan Pakai yang Mana

Satu halaman bisa membuat empat orang memilih empat schema type berbeda.

Editor:
“Ini Article.”

Developer:
“Semua URL kan WebPage.”

Technical writer:
“Isinya troubleshooting, berarti TechArticle.”

Research lead:
“Ini laporan audit. Report.”

Menariknya, semuanya bisa punya sebagian alasan yang benar.

Masalahnya muncul ketika kita menganggap schema type seperti kategori WordPress: harus memilih satu label, selesai.

Schema.org adalah model semantik. Satu halaman web adalah WebPage, tetapi halaman tersebut bisa memuat atau merepresentasikan CreativeWork lain seperti Article, TechArticle, atau Report.

Jadi pertanyaannya bukan sekadar:

“Page ini tipe apa?”

Pertanyaan yang lebih berguna:

“Apa object utama yang sedang diterbitkan di page ini, dan Search feature apa yang benar-benar kita targetkan?”

Dua pertanyaan itu perlu dipisahkan.

WebPage adalah Container Web

Schema.org mendefinisikan WebPage secara sangat straightforward: sebuah web page.

Secara konseptual, hampir semua halaman website adalah WebPage.

Homepage.

About.

Contact.

Service.

Article URL.

Report landing page.

Product page.

Tetapi jika page punya object utama yang lebih spesifik, kita biasanya ingin memodelkan object tersebut juga.

Contoh:

URL:
`/riset/ai-search-indonesia-2026/`

Page itself:
WebPage.

Main creative work:
Report.

Publisher:
Organization.

Author:
Person/Organization.

Dataset:
maybe related if real dataset exists.

Breadcrumb:
navigation.

Schema graph bisa menghubungkan semuanya.

Jadi memilih Report tidak berarti WebPage berhenti ada.

WebPage menjelaskan container.

Report menjelaskan karya.

Ini distinction yang membersihkan banyak schema architecture.

Kapan Cukup WebPage?

Gunakan WebPage ketika page memang generic webpage dan tidak ada CreativeWork yang lebih specific yang perlu dimodelkan.

Contoh:

About page.

Contact page.

Service overview.

Pricing page.

Terms.

Landing page.

Entity hub.

Dashboard public.

Tool page.

WebPage juga punya subtype seperti AboutPage, ContactPage, ProfilePage, CollectionPage dan lain-lain dalam Schema.org.

Jadi service landing page tidak perlu dipaksa menjadi Article hanya karena punya 1.500 kata.

Panjang bukan penentu Article.

Format editorial dan purpose yang menentukan.

Kalau page menjual atau menjelaskan service sebagai canonical commercial page, Article mungkin bukan object utama.

WebPage plus Service entity bisa lebih tepat.

Article untuk Karya Editorial

Schema.org Article adalah article seperti news article atau investigative report secara broad.

Google Search punya dokumentasi Article structured data untuk news, blog, dan sports article pages. Untuk Google Article Search feature, dokumentasi current menyebut Article object harus berbasis salah satu dari:

Article.

NewsArticle.

BlogPosting.

Ini penting.

Schema.org taxonomy lebih luas daripada Google Search feature support.

Sebuah TechArticle atau Report secara Schema.org merupakan subtype Article, tetapi jangan otomatis mengasumsikan Google memperlakukannya identik untuk Article rich result. Kalau target kita Google Search feature, ikuti documented types dan test implementation.

Untuk editorial blog biasa:

BlogPosting masuk akal.

Untuk article institusional:

Article.

Untuk news reporting:
NewsArticle jika benar-benar news.

Jangan memilih NewsArticle karena terdengar lebih powerful.

Type harus match content.

TechArticle untuk Materi Teknis yang Memang Teknis

Schema.org mendefinisikan TechArticle sebagai technical article, dengan contoh how-to task topics, step-by-step, procedural troubleshooting, specifications, dan sejenisnya.

Ini cocok untuk:

Developer documentation article.

Troubleshooting guide.

Technical procedure.

Implementation tutorial.

Protocol explanation.

Specification analysis.

Engineering note.

Contoh GEO.or.id:

“Cara Audit Log Server untuk Melihat Aktivitas AI Crawler.”

Jika isinya benar-benar procedural:

where logs are.

fields.

user-agent.

IP verification.

commands.

failure modes.

TechArticle semantically reasonable.

Tetapi jika judul technical tetapi isi mostly opinion:

“Kenapa AI Crawler Penting untuk Masa Depan Brand.”

Itu mungkin Article biasa.

TechArticle bukan badge “lebih teknis”.

It must actually be technical article.

Report untuk Karya yang Memang Laporan

Schema.org Report adalah Report yang dihasilkan organization governmental atau non-governmental.

Report punya semantic flavor berbeda.

Usually:

Defined scope.

Method.

Period.

Findings.

Data.

Analysis.

Limitations.

Maybe report number.

Institutional publisher.

Example:

“GEO.or.id AI Search Visibility Report Indonesia Q3 2026.”

Contains:

Methodology.

Query sample.

Platforms.

Measurement dates.

Findings.

Confidence.

Limitations.

Appendix.

This is a Report.

Not merely Article with many charts.

A blog post summarizing report remains Article.

The underlying downloadable/public report is Report.

This distinction is useful.

One URL can contain both:

WebPage.

Article summary.

Report object/download.

But don't duplicate objects without reason.

Skenario yang Membongkar Salah Type

Content lead:
“Artikel ini 2.000 kata dan ada data, pakai Report ya.”

Researcher:
“Method-nya apa?”

“Enggak ada. Ini opini.”

“Period?”

“Enggak.”

“Dataset?”

“Enggak.”

“Findings?”

“Ya kesimpulan penulis.”

Then it's not Report just because it sounds serious.

Another example:

Developer:
“Ini TechArticle karena topiknya schema.”

Editor:
“Isinya sejarah schema dan opini industri, tidak ada procedure.”

Then Article may fit better.

Schema type is semantic classification.

Not prestige ladder.

WebPage + mainEntity Pattern

A clean graph can separate page and content.

Example conceptually:

WebPage:
URL.
breadcrumb.
publisher context.
mainEntity.

Article:
headline.
author.
datePublished.
dateModified.
image.
publisher.

Organization:
canonical ID.

Person:
canonical ID.

Now Article is main entity described by WebPage.

This avoids forcing page-level properties into Article or vice versa.

But implementation doesn't need graph complexity if CMS handles one clear Article object well.

Architecture should match scale.

Small site:
simple.

Large site:
explicit graph useful.

Google Article Support vs Schema.org Semantics

This distinction should be written on the wall.

Schema.org asks:
“What is this thing?”

Google Search documentation asks:
“What markup does this Search feature support?”

Those are related but not identical.

TechArticle is valid Schema.org.

Report is valid Schema.org.

But Google Article documentation specifically lists Article, NewsArticle, BlogPosting for its Article objects.

So what should developer do?

If semantically TechArticle:

Could model TechArticle in broader knowledge graph while ensuring Google-targeted structured data follows current Search documentation.

But don't improvise unsupported multi-typing without testing.

If targeting Google rich results, use current Google docs as constraint.

If targeting general semantic interoperability, use Schema.org semantics.

One implementation can satisfy both, but it needs deliberate design.

Do not assume subtype inheritance is interpreted identically by every consumer.

Testing matters.

Jangan Multi-Type Hanya karena Bingung

Some teams write:

`@type`: ["WebPage","Article","TechArticle","Report"]

Done.

This is not sophistication.

It is indecision encoded.

Can an object legitimately have multiple types?

Linked-data models can allow multiple types.

But ask whether same object truly is all types.

A report can be Article subclass semantically.

A TechArticle can be Article subclass.

But WebPage container and Report work may be distinct objects.

Using separate nodes can be clearer than making one object everything.

Model actual reality.

Don't use array of types as “cover all possibilities.”

Machine consumers may have different expectations.

Satu Page Bisa Punya Banyak Objects

Recipe page:

WebPage.

Recipe.

Video.

Breadcrumb.

Organization.

Google guidelines explicitly discuss multiple items on a page and say they can be nested or specified individually, with `@id` helping link items when useful.

Same logic applies conceptually to institutional content.

Report landing:

WebPage.

Report.

Organization publisher.

Person author.

Dataset maybe.

ImageObject.

Breadcrumb.

But mark only user-visible/relevant objects.

Don't create hidden universe.

Schema graph should stay readable.

Article Summary of Report

Common pattern:

Page has 1,500-word editorial summary.

Embedded PDF full report.

What is main content?

Depends page.

If page primarily publishes report:
Report can be mainEntity.

Article summary could be supporting.

If blog article discusses third-party report:
Article is main.

Report is about/citation/subject.

Do not label article itself Report just because it mentions one.

Relationship semantics matter.

Report vs Dataset

Report explains/analyzes.

Dataset is structured collection of data.

A report may be based on dataset.

They are not same.

Don't mark PDF report as Dataset unless it actually contains dataset and satisfies definition.

Upcoming article 257 will go deeper.

For 254, rule simple:

Report tells findings.

Dataset is data resource.

Article communicates narrative/editorial content.

Page hosts/presents.

TechArticle communicates technical procedure/content.

Author and Publisher Should Follow Work Type

Article:
author Person/Organization.

Report:
publishing organization, authors/research team.

TechArticle:
technical author/reviewer.

WebPage:
publisher/site context.

Avoid fake author.

If Report produced by Organization, don't invent CEO as author for E-E-A-T.

If TechArticle written by engineering team, say team/Organization if accurate.

Authorship is factual relationship.

Not schema decoration.

DatePublished and dateModified

For Article/TechArticle/Report, dates matter.

Publish date:
when work first published.

Modified:
material revision.

Don't auto-update dateModified every request because theme rendered.

Don't rewrite datePublished on every update.

Report period is separate from publication date.

Example:

Measurement period:
July 2026.

Report published:
August 9, 2026.

These are different.

Visible page should make temporal context clear.

Search and AI users need it.

Technical Content Is Not Automatically TechArticle

“Schema 2026: Trends dan Kesalahan Umum.”

Technical topic.

But could be editorial Article.

“Cara Implement ProductGroup JSON-LD pada Variant Page.”

Procedure.

TechArticle stronger fit.

“HTTP Cache-Control Reference.”

Technical reference, maybe TechArticle.

“Kenapa CTO Harus Peduli AI Crawler.”

Business analysis, Article.

Subject is not type.

Format/purpose is type.

Report Is Not Automatically More Authoritative

Teams sometimes choose Report to signal seriousness.

Don't.

Authority comes from:

Method.

Evidence.

Publisher.

Data.

Transparency.

Review.

Report schema cannot upgrade opinion into research.

If page has no method, calling it Report is semantic inflation.

Same as calling blog post Dataset.

Labels don't create evidence.

Content first.

Schema follows.

Decision Tree Praktis

Ask:

Is this mainly a webpage interface/landing/service/contact?
→ WebPage or suitable WebPage subtype.

Is this a published editorial piece?
→ Article / BlogPosting / NewsArticle depending format.

Is this specifically technical procedural/specification content?
→ TechArticle semantically, while considering consumer support requirements.

Is this a formal institutional report with defined scope/findings?
→ Report.

Is it more than one?
→ Model WebPage container + appropriate main entity/entities.

Then ask:

What does Google Search currently support for the feature we target?

Don't assume Schema.org validity equals rich-result eligibility.

This second check is mandatory.

Example GEO.or.id

1. `/about/`
WebPage/AboutPage + Organization.

2. `/blog/apa-itu-geo/`
Article or BlogPosting.

3. `/guides/verifikasi-oai-searchbot-log-server/`
TechArticle semantically.

4. `/research/ai-visibility-indonesia-2026/`
Report if real methodology/findings exist.

5. `/research/ai-visibility-indonesia-2026-summary/`
Article summarizing Report.

Now architecture has meaning.

No need put Report on all research-looking pages.

Validator Tidak Menentukan Type untuk Anda

Validator can say syntax valid.

It doesn't know business intent deeply.

It cannot decide whether your “report” is actually a report.

Human semantic review remains.

Ask editorial owner.

Research lead.

Product.

Legal when relevant.

Schema architecture isn't purely technical.

It translates editorial reality into machine language.

Wrong editorial classification becomes wrong structured data.

A Simple Rule: Type Should Survive Removing the Schema

Imagine JSON-LD deleted.

Read page.

Would you still call this:

Article?

Technical article?

Report?

Generic webpage?

If answer yes, type likely makes sense.

If answer only becomes “Report” because schema says Report, wrong direction.

Markup should describe.

Not redefine.

Untuk Google, Follow Current Docs. Untuk Semantics, Follow Reality.

Those two principles solve most confusion.

Google Search can change supported features.

Schema.org evolves.

Your content also evolves.

Don't hardcode 2026 assumptions forever.

Version schema governance.

Review current docs.

Keep page type mapping.

When Google removes/supports feature, update technical layer.

The actual entity/work identity may remain.

This separation makes architecture resilient.

WebPage, Article, TechArticle, dan Report bukan empat tingkat kualitas.

Mereka empat cara menjelaskan different things.

Pilih yang menggambarkan karya nyata.

Bukan yang terdengar paling powerful.