Correction, Versioning, dan Deprecation: Tiga Kebiasaan yang Harus Masuk SOP Konten

Banyak website punya SOP produksi.

Riset.

Draft.

Edit.

Approve.

Publish.

Selesai.

Yang hilang justru bagian setelah publish.

Apa yang dilakukan ketika fakta salah?

Apa yang dilakukan ketika fakta berubah?

Apa yang dilakukan ketika halaman sudah tidak berlaku?

Sebagian tim menjawab semuanya dengan tombol Edit.

Masalahnya, correction, versioning, dan deprecation bukan tindakan yang sama.

Kalau tiga kebiasaan ini tidak masuk SOP, website perlahan menjadi gudang informasi dengan status yang tidak jelas.

Di era AI search, problem-nya membesar.

Mesin jawaban bisa menemukan halaman lama, policy lama, product lama, PDF lama, dan article lama lalu menggunakannya untuk menjawab pertanyaan hari ini.

Kita tidak bisa mengontrol semua retrieval.

Tetapi kita bisa memperjelas lifecycle informasi yang kita publish.

Correction menjawab: apa yang salah?

Correction dipakai ketika informasi sebelumnya tidak benar.

Contoh:

Alamat ditulis Jalan A, seharusnya Jalan B.

Artikel menulis biaya Rp500.000, source resmi saat itu sebenarnya Rp750.000.

Nama regulator salah.

Product capability diklaim padahal tidak ada.

Correction harus merekam:

Apa claim lama.

Apa claim benar.

Kapan error ditemukan.

Kapan diperbaiki.

Source.

Severity.

Affected asset.

Apakah public note diperlukan.

Jangan mengubah error menjadi “update” hanya supaya terdengar lebih nyaman.

Semantics matter.

Kalau data sebelumnya salah, sebut correction secara internal.

Public wording bisa profesional.

“Koreksi: versi sebelumnya mencantumkan biaya yang tidak tepat.”

Transparency tidak perlu dramatis.

Versioning menjawab: apa yang berubah?

Versioning dipakai ketika informasi punya iterasi.

Policy v1.

Policy v2.

Product spec v3.

Methodology.

Terms.

Pricing plan.

Dataset.

Research.

FAQ regulated.

Versioning membuat orang tahu bahwa dua dokumen berbeda adalah dua state yang valid pada waktu berbeda.

Tanpa version:

policy.pdf

policy-final.pdf

policy-final-baru.pdf

policy-final-revisi-fix.pdf

Ini bukan lucu kalau policy dipakai AI knowledge base.

System bisa ingest file salah.

User mendapat rule lama.

Gunakan version identifier.

Effective date.

Superseded link.

Owner.

Changelog.

Tidak harus semantic versioning 1.2.3 untuk semua artikel.

Yang penting user dan system bisa membedakan.

Deprecation menjawab: apa yang tidak lagi berlaku?

Product dihentikan.

Program selesai.

API endpoint retired.

Policy diganti.

Cabang tutup.

Service discontinued.

Artikel technology sudah obsolete.

Jangan selalu delete.

Deprecation memberi context.

“This service is no longer available as of 1 July 2026.”

“Policy ini digantikan oleh version 3.”

“Dokumen ini disimpan untuk arsip dan tidak boleh digunakan sebagai current guidance.”

Ini jauh lebih informatif daripada 404.

Tentu ada kondisi delete memang benar, misalnya duplicate, legal removal, privacy, atau content yang tidak punya archival value.

Tetapi default delete bisa menghilangkan provenance.

Default keep tanpa label juga berbahaya.

Deprecation berada di tengah.

Tiga status ini harus masuk CMS thinking

CMS tradisional punya:

Draft.

Published.

Scheduled.

Trash.

Untuk knowledge governance, itu kurang.

Tambahkan mental state:

Current.

Corrected.

Superseded.

Deprecated.

Archived.

Historical.

Under review.

Conflicted.

Tidak harus semua menjadi post status teknis.

Bisa field internal.

Tag governance.

Database.

Content registry.

Yang penting workflow mengenal state.

AI assistant internal jangan ingest semua page hanya karena status Published.

Ia perlu tahu currentness.

Correction SOP

Ketika error ditemukan:

1. Capture issue.

2. Freeze claim.

3. Verify source of truth.

4. Classify severity.

5. Identify affected assets.

6. Correct canonical source.

7. Add public note jika material.

8. Update dependent system.

9. Contact external source jika relevant.

10. Retest.

11. Close dengan evidence.

SOP ini harus punya owner.

Jangan “content team” generik.

Claim owner menentukan truth.

Editor publish.

Versioning SOP

Ketika perubahan material direncanakan:

1. Assign version.

2. Set effective date.

3. Record previous version.

4. Write change summary.

5. Approve.

6. Publish new version.

7. Mark previous superseded.

8. Update internal knowledge.

9. Update links.

10. Monitor conflict.

Untuk policy, legal mungkin owner.

Untuk product, product owner.

Untuk price, commerce.

Untuk methodology, research.

Versioning tanpa owner hanya numbering.

Deprecation SOP

Ketika asset tidak lagi current:

Tanya:

Apakah perlu historical record?

Apakah ada traffic?

Apakah ada external links?

Apakah user bisa salah mengambil keputusan?

Apakah pengganti tersedia?

Apakah legal retention berlaku?

Pilihan:

Deprecation banner + link replacement.

Redirect.

Archive.

Noindex jika appropriate.

Delete.

Block from internal AI ingestion.

Update sitemap.

Update navigation.

Jangan memilih action hanya berdasarkan SEO traffic.

Information consequence lebih penting.

Deprecation date harus absolute

Buruk:

“Layanan ini sudah tidak tersedia.”

Sejak kapan?

Lebih baik:

“Layanan ini dihentikan pada 30 Juni 2026.”

AI dan manusia mendapat temporal context.

Relative word seperti “baru”, “sekarang”, “kemarin”, “terbaru” cepat menjadi stale.

Untuk lifecycle information, gunakan tanggal.

Versioning membantu AI measurement juga

Misalnya AI answer salah mengutip policy v1.

Kalau page hanya di-overwrite menjadi v2 tanpa history, kita tidak tahu kenapa source lama berbeda.

Kalau versioning ada:

v1 valid sampai 31 Mei.

v2 effective 1 Juni.

AI answer 10 Juni menggunakan v1.

Classification:
stale.

Action:
improve current source, deprecate v1, retest.

Diagnosis lebih tepat.

Correction membantu reputasi

Brand takut correction note.

Tetapi user lebih takut informasi yang diam-diam berubah setelah keputusan dibuat.

Especially high-stakes.

Finance.

Health.

Legal.

Commerce policy.

Security.

Correction trail menunjukkan accountability.

Bukan berarti semua typo diumumkan.

Materiality threshold.

Small formatting edit:
silent.

Wrong product price:
correction.

Updated price karena perubahan resmi:
version/update.

Old plan discontinued:
deprecation.

Tiga kategori.

Simple.

Deprecation mengurangi AI knowledge contamination

Internal RAG sering menarik semua document.

Lama.

Baru.

Draft.

Archive.

Model kemudian bingung.

SOP deprecation harus terhubung ke ingestion.

Document metadata:

status=current.

status=superseded.

status=deprecated.

Retriever default hanya current.

Historical query boleh membuka archive.

Ini jauh lebih efektif daripada berharap model “memilih versi terbaru” dari isi teks.

System harus membantu.

Machine-readable status bukan jaminan external AI mengikuti

Kalau organisasi menambahkan metadata internal, ChatGPT external belum tentu tahu.

Distinction wajib.

Internal governance:
kita bisa enforce.

Public web:
kita hanya bisa membuat state lebih jelas.

Visible note.

Date.

Link.

Current canonical page.

HTTP behavior.

Structured data yang memang sesuai supported use case.

Jangan invent schema “deprecatedArticle” jika vocabulary tidak mendukung.

Machine clarity harus berbasis standard yang nyata.

Changelog bukan untuk semua artikel

Jangan over-engineer.

Lifestyle article tidak perlu version log 20 baris.

Tetapi evergreen guide yang memengaruhi keputusan mungkin perlu update history.

Use risk and volatility.

High:
policy, product, regulation, price, eligibility, technical docs.

Medium:
service guide, comparison, institutional data.

Low:
opinion, culture, historical feature.

Semakin high, semakin formal lifecycle.

SOP harus menentukan threshold.

Content audit berubah kalau lifecycle dipakai

Audit bukan lagi:

Page punya traffic?

Keyword apa?

Word count?

Tambahkan:

Current?

Owner?

Last verified?

Superseded?

Dependent asset?

Correction open?

Version known?

High-risk claim?

AI answer conflict?

Sekarang audit membantu governance.

Bukan hanya SEO cleanup.

Apa hubungan dengan deprecation API/software?

Software industry sudah lama paham deprecation.

OpenAI API sendiri menyediakan deprecation documentation untuk model dan endpoint tertentu.

Kenapa?

Developer perlu waktu migrasi.

Perubahan punya impact.

Lifecycle harus terlihat.

Konten organisasi juga perlu mindset serupa.

Kalau policy atau product berubah, user butuh migration context.

“Yang lama sudah tidak berlaku, pakai yang ini.”

Sangat sederhana.

Tetapi banyak website gagal melakukannya.

Correction, versioning, dan deprecation juga harus ada di handover

Agency selesai contract.

Editor resign.

Product manager pindah.

Siapa tahu halaman mana yang deprecated?

Buat registry.

Content ID.

Owner.

Status.

Current version.

Last verified.

Replacement.

Critical dependency.

Open correction.

Kalau system hanya hidup di kepala seseorang, governance rapuh.

Three habits lebih penting daripada tool

Bisa dilakukan di Notion.

Spreadsheet.

CMS custom fields.

Git.

Database.

PIM.

DAM.

Knowledge graph.

Tool bukan point.

Disiplin:

Correction tidak disembunyikan.

Version tidak bercampur.

Deprecated tidak menyamar sebagai current.

Kalau tiga hal ini berjalan, AI search program mendapat benefit besar.

Public evidence lebih mudah dibaca.

Internal RAG lebih bersih.

Customer service tidak pakai policy lama.

Sales deck lebih current.

Correction lebih cepat.

Measurement lebih akurat.

SOP konten jangan berhenti saat Publish

Publish sebenarnya awal lifecycle.

Setelah itu:

Fact berubah.

Source berubah.

Regulasi berubah.

Product berubah.

Model berubah.

User menemukan error.

External source conflict.

AI answer membawa versi lama.

SOP harus siap.

Correction menjawab kesalahan.

Versioning menjawab perubahan.

Deprecation menjawab akhir masa berlaku.

Tiga kebiasaan tersebut terdengar administratif.

Tetapi kalau dilakukan konsisten, mereka mengubah website dari kumpulan halaman menjadi information system yang punya memory.

Dan di era AI, memory yang rapi jauh lebih valuable daripada ribuan halaman yang semuanya terlihat “published” tetapi tidak ada yang tahu mana yang masih benar.

Ada satu layer yang sering menjadi sumber masalah: external asset.

Perusahaan sudah men-deprecate page sendiri, tetapi partner masih menautkan PDF lama.

Marketplace masih menyebut old policy.

Media kit lama tersimpan di Google Drive public.

Sales rep punya deck lokal.

SOP perlu mengenal external dependency.

Setelah deprecation material:

buat affected-source list,
hubungi owner,
update shared asset,
check partner page,
check public storage,
check knowledge base,
check chatbot,
check AI source observation jika issue berasal dari sana.

Tidak semua external source bisa diubah.

Kalau tidak bisa, status residual risk.

Current canonical page harus makin jelas.

SOP juga perlu retention rule.

Jangan menyimpan semua versi selamanya tanpa reason.

Legal retention bisa berbeda.

Operational log mungkin satu periode.

Public archive bisa selective.

Privacy requirement bisa meminta deletion.

Buat policy per content class.

Version history yang baik bukan penimbunan.

Ia menyimpan cukup information untuk audit dan continuity tanpa membuat data graveyard.

Untuk high-impact content, reviewer harus melihat diff.

Jangan approve seluruh dokumen dari nol.

Tampilkan perubahan.

Apa yang ditambah.

Apa yang dihapus.

Apa claim yang berubah.

Diff review menurunkan risiko perubahan kecil yang mengubah meaning tanpa terlihat.

Terutama untuk regulation, pricing, terms, dan product capability.

Workflow content yang matang akhirnya mirip software release.

Ada source.

Ada version.

Ada change.

Ada review.

Ada rollback.

Ada deprecation.

Bedanya, object yang dikelola bukan code.

Object-nya adalah public truth.