Cara Membuat Baseline Sebelum Mengubah Schema dan Internal Link

Jam 16.20, developer bilang perubahan schema sudah siap.

SEO lead bilang internal link baru juga tinggal deploy.

Marketing ingin semuanya live malam itu juga.

Lalu ada satu pertanyaan yang datang terlambat:

“Baseline sebelum diubah sudah disimpan belum?”

Hening.

Ini skenario yang terlalu familiar.

Bukan karena tim tidak kompeten. Justru karena semua orang ingin bergerak cepat. Schema dibenahi. Internal link ditambah. Breadcrumb dirapikan. Canonical page diperkuat. Content diperbarui.

Masalahnya muncul sebulan kemudian ketika AI citation naik.

Semua orang ingin tahu: perubahan mana yang berhubungan dengan kenaikan?

Jawabannya tidak bisa dipisahkan karena sebelum perubahan tidak ada baseline yang cukup.

Dalam GEO, baseline bukan formalitas. Ia adalah foto kondisi awal yang membuat before-after comparison punya arti.

Tanpa baseline, perubahan teknis dan editorial hanya menghasilkan cerita “sepertinya membaik”.

Tentukan Dulu Apa yang Mau Diubah

Jangan membuat baseline generik.

Kalau perubahan utama adalah schema, baseline harus menangkap kondisi schema dan outcome yang ingin dipantau.

Kalau perubahan utama adalah internal link, baseline harus menangkap crawl/discovery architecture dan outcome terkait.

Kalau keduanya diubah bersamaan, dokumentasikan bahwa attribution akan lebih sulit.

Contoh scope:

Perubahan 1:
Organization schema dibersihkan.

Perubahan 2:
Article graph dihubungkan ke canonical entity page.

Perubahan 3:
Internal links dari 40 artikel menuju service hub ditambah.

Perubahan 4:
Anchor text diperbaiki.

Kalau semua deploy dalam satu malam, nanti kita hanya bisa mengukur combined intervention.

Bukan effect masing-masing.

Itu boleh, asal disadari sejak awal.

Baseline Level 1: Inventory Teknis

Mulai dari apa yang benar-benar ada.

Untuk schema:

Halaman mana yang punya JSON-LD?

Berapa script block?

Type apa yang digunakan?

Apakah ada duplicate output dari theme, plugin, dan custom runtime?

Apakah identifier konsisten?

Apakah URL canonical di schema sama dengan canonical HTML?

Apakah Organization, WebSite, WebPage, Article, Person, Product, atau type lain dipakai sesuai isi?

Apakah sameAs ada?

Apakah sameAs valid dan memang merujuk entity yang sama?

Apakah markup selaras dengan visible content?

Simpan snapshot.

Bukan hanya screenshot validator.

Simpan raw output JSON-LD.

Karena sebulan kemudian markup bisa sudah berubah.

Untuk internal link:

Crawl internal link graph.

Simpan jumlah inlinks per target page.

Outlinks per source.

Anchor distribution.

Depth dari homepage atau hub.

Orphan pages.

Broken internal links.

Redirect chains.

Link ke canonical destination.

Simpan data ini sebagai baseline v0.

Baseline Level 2: Search dan Indexing

Perubahan schema dan internal linking tidak boleh dievaluasi hanya dari markup.

Kita perlu tahu kondisi Search sebelum perubahan.

Simpan:

Indexed status target pages.

Search Console impressions.

Clicks.

Average position jika relevan.

Top queries.

Top pages.

Country/device jika penting.

Generative AI performance data jika property sudah mendapat report tersebut.

Ini bukan karena schema pasti mengubah ranking atau AI visibility.

Justru sebaliknya.

Kita ingin memantau apakah outcome berubah tanpa mengklaim mekanisme yang belum terbukti.

Google secara konsisten menjelaskan bahwa structured data membantu sistem memahami content dan dapat membuat page eligible untuk rich result tertentu jika memenuhi requirement, tetapi markup bukan tombol “naik ranking”.

Jadi baseline harus menghindari expectation palsu.

Baseline Level 3: AI Search Observation

Kalau tujuan perubahan adalah memperbaiki AI visibility, simpan kondisi AI sebelum deploy.

Gunakan query set yang sudah dikunci.

Misalnya 50 core queries.

Lakukan repeated runs.

Catat:

Brand mention.

Recommendation.

Owned citation.

Third-party citation.

Entity accuracy.

Critical hallucination.

Source domains.

Volatility.

Jangan hanya screenshot lima jawaban yang bagus.

Simpan row-level observation.

Contoh:

Query Q17.
Run 1.
Brand mention: yes.
Owned citation: no.
Recommendation: conditional.
Source: Media A.
Entity accuracy: correct.

Dengan format ini, sesudah deploy kita bisa mengulang protocol yang sama.

Baseline Level 4: Human Decision Context

Ini yang sering tidak masuk spreadsheet.

Kenapa perubahan dilakukan?

Apa concern tim?

Apa hypothesis?

Misalnya:

“Tim menduga canonical entity page kurang jelas karena Organization markup tersebar dan internal link menuju tiga URL berbeda.”

Itu hypothesis.

Bukan fakta.

Tulis.

Kemudian:

“Tujuan perubahan adalah membuat internal relationship dan canonical target lebih konsisten.”

Bagus.

Jangan tulis:

“Schema baru akan meningkatkan citation AI.”

Itu belum terbukti.

Baseline perlu menyimpan hypothesis agar bulan depan tim tidak mengubah cerita setelah melihat hasil.

Jangan Ubah Lima Hal lalu Mengaku Mengetes Satu

Dalam skenario ilustratif, developer bertanya:

“Sekalian gue update title, content, schema, internal link, sitemap, sama page speed ya?”

Dari sisi deployment efficiency, masuk akal.

Dari sisi experiment, nightmare.

Kalau tujuan hanya maintenance, tidak masalah.

Kalau tujuan ingin mengukur effect, perubahan perlu staged.

Contoh:

Week 0:
Baseline.

Week 1:
Schema cleanup.

Week 3:
Internal link update.

Week 5:
Content refresh.

Dengan catatan bahwa external environment tetap bisa berubah.

Staging tidak membuat causal proof sempurna.

Tetapi membuat interpretation lebih baik.

Jika operational risk menuntut semua perubahan sekaligus, lakukan.

Lalu jujur bahwa result adalah effect of package, bukan satu component.

Gunakan Control Group bila Masuk Akal

Misalnya ada 100 artikel sejenis.

50 menerima internal link update.

50 belum.

Kalau struktur dan intent cukup comparable, kelompok kedua bisa menjadi rough control.

Tetapi jangan menyebut ini randomized controlled trial kalau assignment tidak random.

Ada selection bias.

Page yang dipilih mungkin lebih penting.

Traffic berbeda.

Freshness berbeda.

Authority berbeda.

Tetap berguna sebagai comparison group, asal limitation ditulis.

Untuk schema, control bisa lebih sulit karena site-wide runtime sering mengubah banyak halaman sekaligus.

Dalam kasus itu, time-series baseline lebih realistis.

Baseline Harus Punya Tanggal dan Version

File bernama:

baseline-final.xlsx

Tidak cukup.

Buat versioning.

GEO-BL-SCHEMA-IL-2026-08-09-v1.

Catat:

Measurement window.

Query set version.

Crawler date.

Search Console export date.

Schema snapshot hash kalau perlu.

Internal link crawl date.

Model/surface condition.

Dengan versioning, team bisa kembali ke kondisi awal.

Ini penting ketika project berjalan berbulan-bulan.

Search Console Data Perlu Window yang Fair

Jangan membandingkan satu hari sebelum deploy dengan satu hari sesudah.

Noise tinggi.

Pilih window.

Misalnya 28 hari sebelum vs 28 hari sesudah.

Tetapi perhatikan seasonality.

Holiday.

Campaign.

PR.

Product launch.

Algorithm/system update.

Kalau ada event besar, beri annotation.

Untuk generative AI visibility, repeated manual observation juga perlu window yang comparable.

Jangan test baseline hari Senin pagi dan post-change hanya sekali pada Jumat malam lalu menyebut growth.

Baseline bukan angka tunggal.

Ia dataset.

Internal Link Baseline yang Benar Bukan Cuma “Jumlah Link”

Jumlah link bisa naik tetapi quality turun.

Misalnya target page mendapat 50 inlinks baru.

Kelihatannya bagus.

Tetapi semua berasal dari footer boilerplate.

Atau anchor-nya generik.

Atau source pages tidak relevant.

Atau link mengarah melalui redirect.

Simpan:

Source URL.

Destination URL.

Anchor.

Context/location.

Followability.

HTTP target.

Canonical status.

Relevance cluster jika bisa.

Kemudian post-change audit bisa melihat relationship, bukan hanya count.

Schema Baseline yang Benar Bukan Cuma “Validator Lolos”

Markup bisa valid secara syntax tetapi salah secara semantics.

Contoh:

Semua pages diberi Organization.

Product page memakai Article.

sameAs menunjuk akun yang bukan milik entity.

Author diisi brand walau content sebenarnya punya named author.

Validator mungkin tidak mengeluh pada beberapa kasus.

Tetapi meaning salah.

Simpan semantic audit.

Apakah type sesuai object?

Apakah property didukung visible content?

Apakah relation masuk akal?

Apakah ID graph konsisten?

Apakah sameAs benar?

Ini baseline yang benar-benar membantu.

Setelah Deploy, Jangan Langsung Menilai

Internal link bisa ditemukan crawler pada waktu berbeda.

Schema output bisa diproses ulang.

Search system berubah.

AI retrieval juga dynamic.

Hasil satu jam setelah deploy bukan evaluation final.

Tetapkan observation cadence.

Day 0:
Technical validation.

Day 3:
Crawl/index spot check.

Week 1:
Initial monitoring.

Week 2–4:
Early comparison.

Month 2:
More stable trend view.

Cadence tergantung site dan scale.

Tidak ada angka universal.

Yang penting jangan memutuskan “berhasil” dari snapshot yang terlalu cepat.

Buat Change Log yang Membosankan tetapi Berguna

Tanggal.

URL.

Perubahan.

Owner.

Reason.

Expected effect.

Risk.

Rollback path.

Ini tidak sexy.

Tapi saat hasil berubah tiga minggu kemudian, change log menjadi penyelamat.

Tanpa log, meeting berubah menjadi:

“Siapa yang ubah page ini?”

“Kayaknya bulan lalu.”

“Schema-nya dari plugin atau runtime?”

“Lupa.”

Measurement selesai sebelum mulai.

Baseline Bukan untuk Membuktikan Kita Benar

Tujuan baseline bukan mencari evidence bahwa perubahan menghasilkan uplift.

Tujuannya membuka kemungkinan bahwa perubahan tidak menghasilkan effect yang terobservasi.

Atau bahkan effect negatif.

Kalau owned citation tidak berubah setelah schema cleanup, itu data.

Kalau query coverage naik tetapi recommendation tidak, itu data.

Kalau internal link graph lebih bersih tetapi AI visibility flat, itu data.

Kita belajar.

GEO yang sehat bukan rangkaian success story yang semuanya naik.

Ia proses observation.

Sebelum Menekan Deploy

Kembali ke jam 16.20 tadi.

Developer masih menunggu.

SEO lead masih ingin live.

Marketing masih ingin update cepat.

Checklist lima menit:

Raw schema snapshot sudah disimpan?

Internal link crawl sudah ada?

Query set sudah dikunci?

AI baseline sudah diuji?

Search Console export sudah disimpan?

Change scope sudah ditulis?

Measurement window sudah ditentukan?

Kalau belum, tahan deploy sebentar.

Bukan karena perfeksionisme.

Karena tanpa kondisi awal, semua perubahan setelah itu akan lebih sulit dibaca.

Schema dan internal link penting.

Tetapi measurement sebelum perubahan sama pentingnya.

Kalau tidak, kita hanya punya dua hal: pekerjaan yang sudah dilakukan dan cerita yang kita buat sesudah melihat hasil.

Baseline menjaga keduanya tetap terpisah.

Satu tambahan yang sering terlupa adalah menyimpan kondisi eksternal yang diketahui. Kalau pada minggu baseline ada campaign besar, redesign, migrasi hosting, perubahan robots, atau coverage issue, tulis sebagai annotation. Baseline bukan usaha membuat dunia berhenti berubah. Baseline adalah usaha mencatat kondisi yang cukup lengkap agar tiga minggu kemudian kita tidak menafsirkan perubahan dengan ingatan yang sudah bias.

Catatan kecil seperti ini sering menyelamatkan interpretasi besar di kemudian hari.