Otomatiskan cek pra-publikasi dengan Claude Code: jangan biarkan jalur konversi bocor

Suatu pagi saya membuka dasbor analitik dan langsung membeku. Artikel yang saya terbitkan kemarin mendapat PV tiga kali lipat dari biasanya. Tapi pendaftaran PDF gratis: 0. Klik ke produk: 0. Persis situasi “viral tapi tidak ada satu rupiah pun yang bergerak”.

Setelah saya telusuri, penyebabnya sepele. Tombol pendaftaran di akhir artikel masih mengarah ke halaman produk lama yang sudah saya tutup setengah tahun lalu. Lebih parah lagi, versi bahasa Inggris artikel itu tiba-tiba berganti ke bahasa Inggris di tengah body, jadi pembaca dari luar negeri langsung kabur di titik itu. Isi artikelnya sudah bagus, tapi beberapa baris terakhir membuat semuanya bocor.

Sejak hari itu, saya memisahkan total antara “menulis artikel” dan “memastikan artikel layak dipublikasikan”. Kalau cek yang kedua saya kerjakan manual tiap kali, pasti saya bolos. Jadi saya jadikan pola tetap yang dijalankan Claude Code. Hari ini saya bongkar seluruh isinya dalam bentuk yang bisa langsung Anda salin.

Poin penting

• Penyebab utama PV naik tapi pendaftaran tidak naik biasanya adalah kesalahan yang seharusnya ketahuan sebelum publish: link mati, halaman produk lama, dan body yang masih berbahasa lain.
• Kunci item yang dicek sebelum publish menjadi sembilan, lalu periksa dalam urutan yang sama setiap kali. Kebocoran langsung berkurang drastis.
• Yang diserahkan ke Claude Code adalah “membuka halaman dan memeriksa item secara mekanis”. Tombol mana yang jadi bintang, itu manusia yang menentukan.
• Cukup batasi tombol pendaftaran menjadi satu per artikel, pembaca tidak bingung dan lebih mudah lanjut ke tindakan berikutnya.
• Simpan hasil pemeriksaan sebagai log supaya nanti bisa ditelusuri “atas dasar apa artikel ini dipublikasikan”.

Tentukan sembilan item yang dicek sebelum publish

Kalau hanya bilang “cek baik-baik ya”, baik manusia maupun AI tidak akan berbuat apa-apa. Memeriksa berarti daftar item yang konkret. Inilah sembilan item yang saya tetapkan.

#	Item cek	Yang dilihat
1	Halaman terbuka	Server mengembalikan 200 (bukan 404 atau 500)
2	Judul benar	Heading utama di atas halaman cocok dengan judul artikel
3	Penunjukan URL kanonis	Canonical URL menunjuk ke URL artikel itu sendiri
4	Gambar hero	Gambar tampil (bukan gambar lama atau kosong)
5	Bahasa body	Tiap versi bahasa ditulis dalam bahasa itu sejak awal
6	Panduan PDF gratis	Tombol daftar ada dan link tujuannya hidup
7	Link materi	Link mengarah ke halaman produk yang dimaksud (bukan produk lain)
8	Jalur ke halaman konsultasi	Link mengarah ke halaman konsultasi
9	Tampilan ponsel	Tidak ada scroll horizontal (tidak ada elemen yang meluber)

Yang penting adalah nomor 3 dan 7. Kalau canonical URL menunjuk ke halaman utama atau artikel lain, mesin pencari akan menganggap halaman itu yang asli, dan artikel yang sudah susah payah dibuat jadi tidak dinilai. Salah link tujuan paling sering terjadi justru pada artikel yang dibuat dari salin-tempel.

Batas tugas AI dan batas keputusan manusia

Kalau dua hal ini dicampur, bakal celaka. Saya tarik garisnya dengan jelas.

Yang diserahkan ke Claude Code adalah pemeriksaan yang bisa dinilai secara mekanis. Membuka halaman, membaca heading, mengambil link tujuan, melihat apakah gambar tampil, mengecek layout di lebar ponsel. Bagian ini membosankan kalau dikerjakan manusia, dan karena membosankan pasti dibolos, jadi saya suruh AI mengerjakannya tiap kali.

Yang diputuskan manusia adalah bagian yang butuh pertimbangan. Tombol mana yang jadi bintang di artikel ini. Apakah pilihan kata di body terasa alami. Apakah artikel sedang memandu ke produk lama. Dan keputusan akhir: “apakah artikel ini benar-benar layak dipublikasikan”. Kalau bagian ini dilempar bulat-bulat ke AI, akan lahir artikel yang linknya hidup tapi isinya melenceng.

Patokan saat ragu sederhana. Hal yang jawabannya pasti tunggal serahkan ke AI, hal yang menyangkut selera atau strategi serahkan ke manusia. Apakah link mengembalikan 200 itu jawabannya tunggal, jadi AI. Dari tiga tombol mana yang ditonjolkan itu strategi, jadi manusia.

Template instruksi siap salin

Ini instruksi yang bisa langsung Anda tempel ke Claude Code. Cukup ganti nama repositori dan URL yang ingin dicek dengan milik Anda.

Untuk tiap URL berikut, jalankan cek pra-publikasi.
Pastikan: halaman terbuka dengan status 200, heading utama cocok dengan judul artikel,
canonical URL menunjuk ke artikel yang sama, gambar hero tampil,
body ditulis dalam bahasanya, tombol daftar PDF gratis hidup,
link materi mengarah ke halaman produk yang dimaksud, link ke halaman konsultasi benar,
dan tidak ada scroll horizontal pada lebar ponsel.

Untuk tiap URL, laporkan dalam satu baris dengan memisahkan item yang lolos dan yang gagal.
Jangan dianggap lolos hanya karena "terbuka dengan 200". Jika ada item yang gagal,
tulis juga dugaan penyebab dan file mana yang perlu diperbaiki.

Dua kalimat terakhir adalah intinya. Kalau berhenti di “terbuka dengan 200 = OK”, Anda akan melewatkan salah link tujuan yang justru paling sering terjadi. Suruh AI selalu memisahkan item yang gagal, dan suruh sebutkan lokasi perbaikannya, supaya Anda bisa langsung masuk ke tahap memperbaiki.

Skrip penilaian yang langsung jalan

Bagian yang merangkum hasil pemeriksaan lalu mengembalikan “boleh publish atau tidak” secara mekanis sebaiknya dijadikan kode supaya tidak goyah tiap kali. Ini versi minimal yang jalan di Node.js.

// Sembilan item yang wajib lolos sebelum publish
const requiredChecks = [
  "Halaman terbuka dengan 200",
  "Heading utama cocok dengan judul artikel",
  "Canonical URL menunjuk ke artikel yang sama",
  "Gambar hero tampil",
  "Body ditulis dalam bahasanya",
  "Tombol daftar PDF gratis hidup",
  "Link materi mengarah ke produk yang dimaksud",
  "Link ke halaman konsultasi benar",
  "Tidak ada scroll horizontal di lebar ponsel",
];

// passed berisi array nama item yang lolos
function summarizeSmokeResult(passed) {
  const missing = requiredChecks.filter((check) => !passed.includes(check));
  return {
    ok: missing.length === 0,
    missing,
    nextAction: missing.length === 0 ? "boleh publish" : "perbaiki lalu cek ulang",
  };
}

// Contoh jalan: hanya link materi yang gagal
const passed = requiredChecks.filter((c) => c !== "Link materi mengarah ke produk yang dimaksud");
const result = summarizeSmokeResult(passed);

console.log(result.ok ? "Publish OK" : "Publish TIDAK");
console.log("Item gagal:", result.missing);
console.log("Tindakan berikutnya:", result.nextAction);

Saat skrip ini dijalankan, akan tampil Publish TIDAK, nama item yang gagal, dan apa yang harus dilakukan berikutnya. Cukup satu item kurang saja, ok jadi false, jadi tidak akan terjadi kecelakaan publish dengan alasan “kira-kira sudah OK”. Anda tinggal mengisi array passed dengan hasil yang dicek AI lewat instruksi tadi.

Tiga situasi nyata di mana ini benar-benar berguna

1. Hari saat publish beberapa artikel sekaligus Di hari saya menerbitkan tiga artikel sekaligus, pemeriksaan cenderung asal. Saya buka tiap artikel satu per satu di lebar ponsel, lalu scroll sampai dekat heading, awal body, dan tombol pendaftaran. Kalau versi selain bahasa Inggris ternyata body-nya masih berbahasa Inggris, saya hentikan publish di titik itu. Justru di hari yang rawan asal-asalan, daftar tetap inilah yang menyelamatkan.

2. Saat hanya mengganti tombol di artikel populer Bahkan kalau hanya mengganti satu tombol di akhir artikel yang sering dibaca, minta “cari bagian terkait dan perbaiki ya” itu terlalu luas. Tentukan dulu: file mana yang boleh disentuh, file mana yang tidak, URL apa yang dicek, dan tiap link tujuannya. Hanya dengan ini, pemeriksaan setelah kerja berubah dari “kayaknya sih bagus” menjadi “dengan bukti ini, layak publish”.

3. Pemeriksaan kualitas artikel multibahasa Walau pengaturan bahasa artikel sudah benar, kalau body-nya masih berbahasa Inggris, itu belum kualitas layak publish. Untuk tiap bahasa, lihat heading utama, awal body, dan sekitar tombol, lalu pastikan pembaca bahasa itu paham apa yang harus dilakukan berikutnya. Untuk pembaca Indonesia, penjelasan PDF gratis, panduan ke materi, dan ajakan konsultasi semuanya harus terbaca alami dalam bahasa Indonesia.

Jebakan yang sering terjadi dan cara memperbaikinya

Jebakan 1: Melapor “sudah bisa publish” hanya karena build lokal lolos Walau build di komputer sukses, belum tentu halaman di tujuan publikasi tampil benar. Cara memperbaikinya: jadikan objek pemeriksaan bukan “hasil build lokal” melainkan “wujud nyata URL publik”. Pada AI pun, tegaskan “buka URL publik lalu periksa”.

Jebakan 2: Menjejer semua tombol pendaftaran Kalau PDF gratis, materi A, materi B, dan konsultasi dijejer dengan ukuran sama, pembaca bingung harus klik yang mana, dan ujungnya tidak klik apa pun. Cara memperbaikinya: tentukan satu tombol bintang per artikel, sisanya turunkan jadi pendukung yang lebih kalem.

Jebakan 3: Link tujuan menuju produk lain Tertulis “PDF gratis” tapi saat diklik malah menuju materi berbayar, ini sering terjadi pada artikel salin-tempel. Cara memperbaikinya: pastikan AI selalu mengambil link tujuan pada item cek nomor 7, lalu cocokkan sampai ID produk secara visual.

Jebakan 4: Mengubah besar-besaran tanpa menyiapkan cara mengembalikan Menulis ulang area luas tepat sebelum publish lalu tidak bisa mengembalikan saat rusak, itu skenario terburuk. Cara memperbaikinya: batasi satu sesi kerja hanya pada cakupan di mana Anda bisa menyiapkan dulu “langkah mengembalikan kalau aneh”. Kerja yang langkah pengembaliannya tidak bisa ditulis, berarti terlalu besar untuk sesi itu.

Pertanyaan umum

T. PV naik tapi pendaftaran tidak naik. Apa yang harus saya lihat lebih dulu? J. Lihat dulu link tujuan tombol pendaftaran dan bahasa body. Link tujuan masih ke halaman produk lama, atau versi untuk pembaca luar negeri belum diterjemahkan, itu dua penyebab terbesar. Ini termasuk item cek nomor 5, 6, dan 7.

T. Apakah pemeriksaan ini perlu tiap kali? Merepotkan. J. Perlu tiap kali. Justru karena itu jangan dikerjakan manual; serahkan instruksi di artikel ini ke Claude Code dan biarkan dijalankan secara mekanis. Pemeriksaan yang merepotkan justru paling sering dibolos manusia di hari sibuk. Dan kecelakaan selalu terjadi tepat di hari yang dibolos.

T. Kalau tombol dibatasi satu, bukankah pintu masuk ke produk lain berkurang? J. Yang penting bukan jumlah pintu masuk, melainkan apakah pembaca bisa mengklik satu tombol tanpa bingung. Kalau dijejer banyak, pembaca tidak bisa memilih lalu kabur. Tentukan satu bintang, dan letakkan link pendukung secara alami satu sampai dua buah di dalam artikel, itu keseimbangan yang pas.

T. Kenapa penunjukan canonical URL begitu penting? J. Mesin pencari menilai halaman yang ditunjuk sebagai canonical URL sebagai yang “asli”. Kalau di sini menunjuk ke artikel lain atau halaman utama, yang dinilai bukan artikel yang Anda tulis melainkan halaman lain, dan peringkat pencarian pun terkumpul ke sana.

T. Untuk apa menyimpan log pemeriksaan? J. Untuk menelusuri nanti “atas dasar apa artikel dipublikasikan”. Saat masalah muncul, jadi lebih mudah memisahkan di mana kebocorannya: body, tombol, link, atau jalur konsultasi. Kalau tidak tersimpan, di operasi berikutnya Anda harus memeriksa ulang dari nol.

Simpan hasil pemeriksaan dalam satu lembar

Menyimpan catatan singkat setelah publish membuat pemeriksaan berikutnya jauh lebih ringan. Bentuk seperti ini sudah cukup.

- artikel: claude-code-revenue-smoke-test
- tanggal publish: 2026-06-14
- bukti yang dicek: URL publik, heading utama, penunjukan canonical, gambar hero, bahasa body, link tujuan tombol
- tombol bintang: link materi (untuk pembaca yang jalan sendiri)
- angka yang dilihat berikutnya: PV, pendaftaran PDF, klik materi, transisi ke halaman konsultasi

Saat melihat angka pun, jangan menilai hanya dari PV. Sejajarkan pendaftaran PDF gratis, klik materi, dan transisi ke halaman konsultasi pada tanggal yang sama. Cocokkan dengan hipotesis: kalau artikel untuk pemula, pendaftaran PDF mestinya naik; kalau artikel soal pengaturan atau perizinan, klik materi mestinya naik. Dengan kebiasaan ini, posting harian berubah dari “sekadar pekerjaan menerbitkan” menjadi “mekanisme memperbaiki jalur konversi sedikit demi sedikit”.

Garis batas antara “pemeriksaan yang diserahkan ke mesin” dan “keputusan yang ditentukan manusia” ini berlaku sama di luar cek revenue. Gambaran besar saat non-engineer memakai Claude Code saya rangkum di Cara non-engineer memakai Claude Code, dan trik kecil untuk mempercepat kerja harian ada di Tips menaikkan produktivitas Claude Code. Karena meminta AI memeriksa dengan benar butuh instruksi yang presisi, bacalah juga Teknik praktis prompt Claude Code sebagai pelengkap.

Adapun mekanisme yang jadi fondasi dari proses seperti menyuruh AI membaca file atau memeriksa link bisa Anda lihat di Claude Docs resmi. Kalau Anda merasa perilakunya berubah, melihat sumber primer dulu pada akhirnya adalah cara tercepat.

Hasil yang benar-benar saya coba

Saya menjalankan pola ini di situs saya sendiri selama sekitar dua minggu. Yang ingin saya pastikan: “apakah cek sembilan item pra-publikasi benar-benar mengurangi kebocoran”.

Hasilnya, beberapa masalah yang dulu lolos begitu saja ketika saya hanya melihat “halaman terbuka dengan 200” ternyata terdeteksi. Konkretnya: dua artikel hampir terbit dengan gambar hero pinjaman dari artikel lain, satu artikel tombol pendaftarannya masih menunjuk produk lama, dan satu artikel versi bahasa Inggris body-nya berganti ke bahasa lain di tengah. Semuanya, kalau hanya pakai “terbuka dengan 200”, dianggap lolos.

Yang paling terasa adalah operasi membatasi tombol pendaftaran menjadi satu per artikel. Setelah saya rapikan artikel yang dulu menjejer PDF gratis, materi, dan konsultasi dengan bobot sama menjadi satu bintang, rasio klik tombol naik terlihat jelas. Saya merasakan langsung lewat angka bahwa pembaca lebih bergerak saat pilihannya sedikit.

Sebaliknya, saya juga jadi paham bahwa pemeriksaan ini tidak akan bertahan kalau dikerjakan manual. Beberapa hari pertama saya kerjakan manual, lalu di hari sibuk langsung saya bolos begitu saja. Baru setelah saya jadikan bentuk instruksi dan skrip yang dijalankan dengan langkah sama tiap kali, akhirnya kebiasaan ini menempel.

Jadikan pemeriksaan pra-publikasi yang membosankan ini sebagai mekanisme. Itu adalah asuransi termurah untuk mengubah PV menjadi revenue. Kalau Anda ingin memasukkannya ke operasi blog perusahaan atau alur publikasi tim, lewat pelatihan dan konsultasi kita bisa merancang bersama pola yang pas dengan operasi nyata Anda.