Agentic Web 2026: Checklist Teknis untuk Tim Produk dan Marketing

Jam 09.17, sebuah tim lintas fungsi duduk di ruang meeting dengan masalah yang sebenarnya cukup sederhana.

Marketing ingin AI agent bisa membantu calon buyer menemukan layanan dan mengirim request demo.

Product ingin flow-nya mulus.

Engineering ingin requirement yang konkret.

Security tidak mau agent bebas melakukan action sensitif.

Lalu muncul slide berjudul: “Make Website Agent-Ready.”

Engineer melihat slide itu beberapa detik.

“Agent-ready yang mana?”

Pertanyaan itu tepat.

Di 2026, tidak ada satu stempel universal yang membuat sebuah website resmi “agent-ready”. Browser agent, search system, MCP client, A2A client, dan manusia berinteraksi dengan surface berbeda. Karena itu checklist yang berguna harus dimulai dari use case, bukan dari hype.

Untuk tim produk dan marketing, targetnya bukan membuat semua halaman bisa dijalankan mesin.

Targetnya membuat journey yang memang relevan menjadi discoverable, understandable, actionable, safe, dan measurable.

Berikut checklist teknis yang lebih realistis.

1. Tentukan agentic journey sebelum mengubah website

Jangan mulai dari teknologi.

Tuliskan lima sampai dua puluh pekerjaan yang benar-benar berguna.

Contoh:

menemukan produk,
membandingkan plan,
meminta proposal,
mencari slot booking,
menyiapkan checkout,
mengubah jadwal,
mengambil invoice,
membuka support ticket,
mengelola subscription.

Untuk setiap task, tulis:

siapa user-nya,
entry point,
data yang dibutuhkan,
action yang boleh,
action yang tidak boleh,
kapan harus confirmation,
kapan harus human handoff,
dan apa final state yang benar.

Kalau journey belum jelas, implementasi akan jadi kumpulan feature tanpa tujuan.

Checklist:
[ ] Ada daftar priority agentic journeys.
[ ] Setiap journey punya expected outcome.
[ ] High-impact action punya stopping point.
[ ] Human takeover didefinisikan.
[ ] Business owner untuk setiap journey jelas.

2. Pisahkan discovery, comprehension, dan action

Website bisa ditemukan tetapi tidak dipahami.

Dipahami tetapi tidak bisa dijalankan.

Bisa dijalankan tetapi tidak aman.

Jadi jangan membuat satu status “agent-ready”.

Uji tiga layer.

Discovery:
bisakah agent mencapai halaman atau control yang benar?

Comprehension:
bisakah agent memahami apa fungsi halaman, data, dan action?

Action:
bisakah action yang diizinkan diselesaikan dengan state yang jelas?

Ini membantu marketing dan engineering bicara dengan bahasa sama.

Marketing mungkin peduli entry dari AI search.
Product peduli task flow.
Engineering peduli semantics dan backend state.
Security peduli permission.

Semua masuk, tetapi tidak dicampur.

3. Rapikan information architecture

Agent browser tetap membutuhkan jalur.

Navigation yang cantik tetapi ambigu bisa menyulitkan.

Periksa:

label menu,
hierarki halaman,
breadcrumb,
related path,
search internal,
footer utility links,
account navigation,
contact path,
dan return path setelah action.

Gunakan label yang menjelaskan destination.

“Solutions” bisa masuk akal jika isi di bawahnya jelas.

Tetapi kalau perusahaan punya empat menu bernama “Explore”, agent maupun manusia perlu context ekstra.

Checklist:
[ ] Primary navigation punya label jelas.
[ ] Halaman penting tidak menjadi orphan.
[ ] Breadcrumb benar jika digunakan.
[ ] Utility action mudah dibedakan dari content link.
[ ] Mobile navigation punya fungsi setara.
[ ] Tidak ada critical path yang hanya bergantung hover.

4. Gunakan semantic HTML sebagai fondasi

Jangan menjadikan ARIA sebagai plaster untuk markup yang salah.

Mulai dari elemen native yang sesuai:

button untuk action,
link untuk navigation,
label untuk form,
heading untuk hierarchy,
table untuk data tabular,
list untuk list,
dialog untuk dialog bila implementasinya sesuai.

W3C ARIA Authoring Practices menekankan penggunaan semantics yang tepat untuk widget dan pattern.

Accessible name juga penting agar control mempunyai nama yang bisa dikenali assistive technology.

Agentic relevance-nya sederhana: semakin explicit struktur interface, semakin sedikit inferensi yang dibutuhkan.

Tetapi jangan jual ini sebagai ranking hack.

Checklist:
[ ] Interactive element menggunakan semantic role yang tepat.
[ ] Button punya accessible name.
[ ] Link purpose cukup jelas dari context.
[ ] Heading hierarchy tidak random.
[ ] Hidden element tidak tetap menerima interaction tanpa alasan.
[ ] Custom widget mengikuti accessibility pattern yang valid.

5. Audit form seperti agent akan mengisinya

Form adalah bottleneck klasik.

Cek setiap field.

Apakah label terlihat dan programmatically associated?

Apakah required state jelas?

Apakah accepted format dijelaskan?

Apakah autocomplete relevan?

Apakah date input punya mekanisme yang bisa dioperasikan?

Apakah custom select punya role dan state yang benar?

Apakah validation muncul setelah submit atau terlalu agresif?

Apakah error menjelaskan cara memperbaiki?

W3C guidance tentang labels dan instructions sudah cukup jelas: user perlu tahu input apa yang diharapkan.

Agent juga mendapat manfaat dari explicit instruction.

Checklist:
[ ] Semua control form punya label.
[ ] Placeholder bukan satu-satunya label.
[ ] Error terkait dengan field yang salah.
[ ] Required field jelas.
[ ] Format constraint dinyatakan.
[ ] Success state setelah submit jelas.
[ ] Duplicate submission dicegah bila consequence-nya penting.

6. Buat action consequence eksplisit

Tombol “Lanjut” kadang cukup.

Kadang tidak.

Untuk action penting, label harus membantu menjelaskan consequence.

Bandingkan:

“Lanjut”

dengan:

“Kirim permintaan demo”
“Batalkan langganan”
“Simpan alamat”
“Konfirmasi pembayaran”

Semakin irreversible action-nya, semakin penting clarity.

Checklist:
[ ] High-impact button punya label spesifik.
[ ] Destructive action dibedakan.
[ ] Final amount terlihat sebelum purchase.
[ ] Data destination jelas sebelum sensitive submit.
[ ] User bisa review sebelum irreversible action.
[ ] Cancel atau back path tersedia bila relevan.

7. Definisikan state, jangan hanya mengandalkan visual effect

Agent perlu tahu apakah sesuatu berhasil.

Manusia juga.

Setelah action, website harus menghasilkan state yang bisa dipahami.

Contoh:

“Permintaan berhasil dikirim.”
“Perubahan belum disimpan.”
“Pembayaran gagal. Pesanan belum dibuat.”
“Slot sudah tidak tersedia.”
“File sedang diproses.”

Jangan hanya membuat button berubah hijau selama 800 milidetik.

Checklist:
[ ] Loading state jelas.
[ ] Success state jelas.
[ ] Failure state jelas.
[ ] Selected state explicit.
[ ] Authentication state tidak ambigu.
[ ] Cart atau booking state konsisten.
[ ] Refresh tidak menghasilkan action ganda.

8. Rancang error untuk recovery

Error message harus memberi jalan keluar.

“Unexpected error” boleh ada sebagai fallback, tetapi bukan desain utama.

Kelompokkan error:

validation,
authentication,
authorization,
availability,
rate limit,
network,
server,
third-party,
conflict,
expired state.

Lalu tentukan recovery.

Retry?
Edit input?
Login lagi?
Pilih slot lain?
Hubungi manusia?

Checklist:
[ ] Error menjelaskan apa yang gagal.
[ ] Error tidak membocorkan data sensitif.
[ ] Retry aman.
[ ] Idempotency dipertimbangkan untuk action penting.
[ ] Session expiry punya recovery path.
[ ] Third-party failure tidak membuat state menggantung tanpa penjelasan.

9. Authentication dan authorization harus lebih jelas, bukan lebih longgar

Agentic web bukan alasan menurunkan security.

Kalau agent memakai site dalam logged-in context, permission tetap berasal dari user dan sistem.

Test:

login,
SSO,
MFA,
session expiry,
role change,
tenant switching,
logout,
account switching,
dan permission denied.

Principle of least privilege tetap relevan.

Agent tidak perlu akses semua data hanya karena ia bisa membantu satu task.

Checklist:
[ ] Role dan permission diuji.
[ ] Agent tidak mendapat privilege tambahan dari UI shortcut.
[ ] Sensitive action membutuhkan auth state yang sesuai.
[ ] Session expiry tidak menghasilkan silent failure.
[ ] Multi-account context terlihat jelas.
[ ] Tenant boundary diuji.

10. Tentukan confirmation policy

Jangan menyerahkan keputusan confirmation sepenuhnya kepada model.

Website dan backend perlu punya aturan.

Contoh action yang mungkin low-risk:
filter,
sort,
open page,
save shortlist.

Action yang lebih consequential:
submit form,
send message,
publish,
purchase,
cancel,
delete,
change security setting,
transfer data.

OpenAI dalam material agent safety menekankan user control dan mitigasi untuk tindakan sensitif. Detail setiap platform berbeda, tetapi website bisa membuat boundary-nya sendiri jelas.

Checklist:
[ ] Action risk diklasifikasikan.
[ ] Confirmation point didesain.
[ ] Confirmation menjelaskan consequence.
[ ] Review data tersedia sebelum final submit.
[ ] User bisa mengambil alih.
[ ] Irreversible action punya friction yang proporsional.

11. Uji indirect prompt injection

Ini bukan fitur opsional untuk workflow agentic yang membaca content eksternal.

OpenAI menjelaskan pada 2026 bahwa agent yang browsing, retrieving information, dan mengambil action membuka attack surface baru untuk prompt injection.

Website sendiri dapat menjadi sumber content yang kemudian dibaca agent.

Jika ada user-generated content, third-party embed, document upload, review, comment, atau marketplace listing, risikonya bertambah.

Checklist:
[ ] External content dianggap untrusted data.
[ ] Instruction hierarchy tidak bergantung pada isi webpage.
[ ] UGC punya moderation dan security review yang sesuai.
[ ] Sensitive action tidak ditentukan oleh arbitrary page text.
[ ] Controlled injection testing dilakukan di staging.
[ ] Logging mendukung incident investigation.

12. Jangan lupakan accessibility

Accessibility bukan subproject terpisah yang baru diingat saat audit.

Keyboard.
Focus.
Labels.
Roles.
Names.
States.
Error.
Contrast.
Alternative text.
Dialog behavior.

Semua tetap penting untuk manusia.

Dan banyak di antaranya juga memperbaiki explicitness interface untuk automation.

Checklist:
[ ] WCAG-related testing masuk QA.
[ ] Keyboard journey diuji.
[ ] Focus order masuk akal.
[ ] Modal tidak trap user secara salah.
[ ] Status penting dapat diketahui tanpa warna saja.
[ ] Automated checker dilengkapi manual testing.

13. Test responsive dan cross-domain flow

Journey agentic bisa melewati banyak surface.

Mobile menu.
Payment provider.
Booking engine.
Identity provider.
Support portal.
Document CDN.

Test whole flow.

Checklist:
[ ] Desktop dan mobile breakpoint diuji.
[ ] Redirect destination jelas.
[ ] Cross-domain return path benar.
[ ] Third-party error diuji.
[ ] Login state tidak hilang tanpa explanation.
[ ] User tahu ketika meninggalkan domain utama.

14. Instrument task outcome

Kalau tidak diukur, tim hanya punya anecdote.

Log secukupnya:

task,
entry point,
agent/client,
timestamp,
login state,
action,
confirmation,
error,
handoff,
final outcome.

Jangan merekam sensitive data hanya karena “analytics”.

Privacy tetap berlaku.

Checklist:
[ ] Event taxonomy tersedia.
[ ] Failure mode diklasifikasikan.
[ ] Human intervention dicatat.
[ ] Safety intervention dibedakan dari UX failure.
[ ] Version test disimpan.
[ ] Data retention punya policy.

15. Pisahkan AI visibility dari agentic completion

Google pada 2026 menyediakan dedicated Generative AI performance reporting di Search Console. Itu membantu melihat visibility di AI features Google.

Tetapi itu bukan agentic task completion report.

Marketing perlu memisahkan:

apakah brand ditemukan dalam AI search,
apakah website dipilih,
apakah agent mencapai action surface,
apakah task selesai,
apakah outcome benar,
dan apakah action aman.

Jangan mengubah internal metric menjadi klaim ranking.

Checklist:
[ ] AI search visibility punya measurement sendiri.
[ ] Agent task testing punya measurement sendiri.
[ ] Citation/mention tidak dianggap otomatis sebagai action success.
[ ] Completion tidak dianggap sukses jika outcome salah.
[ ] Safety tidak dikorbankan demi conversion.

16. Kalau pakai MCP atau A2A, ukur layer itu terpisah

Website agent-ready tidak otomatis berarti tool server siap.

MCP 2026-07-28 punya mekanisme tools/list untuk capability discovery pada server. A2A memakai Agent Card untuk agent discovery.

Kalau bisnis memakai layer ini, audit secara terpisah.

MCP:
tool naming,
schema,
description,
permission,
version,
error,
observability.

A2A:
Agent Card,
identity,
endpoint,
capability,
skills,
authentication,
version compatibility.

Jangan menaruh semua di bawah label “website optimization”.

17. Jalankan regression test setiap perubahan penting

Agentic usability dapat rusak karena perubahan kecil.

CTA diganti copy.
Modal baru ditambahkan.
Form library di-upgrade.
Payment vendor berubah.
Navigation direstrukturisasi.
Auth flow diganti.
Cookie banner baru aktif.

Buat task suite repeatable.

Tidak harus ribuan test.

Dua puluh journey yang benar-benar penting dan dijalankan berkala lebih berguna daripada audit spektakuler sekali setahun.

Checklist:
[ ] Priority task punya regression suite.
[ ] Staging diuji sebelum release.
[ ] Production smoke test tersedia.
[ ] Failure punya owner.
[ ] Major frontend change memicu retest.
[ ] Agent/client version dicatat jika tersedia.

Checklist terakhir: apakah ini tetap website yang bagus untuk manusia?

Setelah semua pembahasan agent, pertanyaan terakhir justru paling manusiawi.

Apakah calon buyer mengerti halaman ini?

Apakah orang tahu apa yang akan terjadi kalau menekan tombol?

Apakah form masuk akal?

Apakah error membantu?

Apakah pricing transparan?

Apakah user bisa batal?

Apakah website accessible?

Apakah content tetap enak dibaca?

Kalau jawabannya tidak, jangan rayakan karena agent berhasil melewati flow.

Situs yang bagus untuk agent tetapi buruk untuk manusia bukan kemenangan.

Tim di meeting pagi tadi akhirnya mengganti judul slide.

Bukan lagi “Make Website Agent-Ready.”

Mereka menulis:

“Make Priority Journeys Explicit, Safe, and Testable.”

Itu jauh lebih actionable.

Dan untuk 2026, itu mungkin definisi kerja paling sehat dari agentic web readiness: bukan badge, bukan hack, bukan klaim bahwa mesin akan memberi ranking.

Tetapi kemampuan sistem untuk membuat task yang memang relevan dapat ditemukan, dipahami, dijalankan dalam boundary yang benar, diobservasi, dan dikembalikan kepada manusia saat keputusan membutuhkan manusia.