Mengelola Pengguna dan Peran di WordPress untuk Tim Redaksi: Hak Akses, Alur Editorial, dan Keamanan Akun Publisher

Mengelola pengguna dan peran di WordPress adalah pekerjaan yang sering ditunda sampai terjadi masalah: seorang penulis lepas tidak sengaja mengubah pengaturan iklan, kontributor menerbitkan artikel yang belum direview, atau akun lama seorang mantan anggota tim masih aktif berbulan-bulan setelah ia berhenti. Padahal WordPress sudah menyediakan sistem peran dan capability yang rapi sejak awal — enam peran bawaan dengan batas kewenangan yang jelas — dan sebagian besar kekacauan tim redaksi bisa dicegah hanya dengan memberikan setiap orang peran serendah mungkin yang masih memungkinkannya bekerja. Artikel ini menjelaskan keenam peran itu, cara memetakan jabatan tim redaksi ke peran yang tepat, alur editorial yang aman dari draf sampai terbit, cara membuat peran kustom bila peran bawaan tidak cukup, serta rutinitas audit dan keamanan akun yang membuat situs publisher tetap terkendali meski timnya terus bertambah.

Poin Kunci

• WordPress memiliki enam peran bawaan: Super Admin (khusus Multisite), Administrator, Editor, Author, Contributor, dan Subscriber — masing-masing adalah kumpulan capability, yaitu izin untuk satu tindakan spesifik.
• Prinsip yang paling aman adalah least privilege: berikan peran terendah yang masih memungkinkan seseorang menyelesaikan tugasnya, dan naikkan hanya bila ada alasan yang jelas.
• Contributor tidak bisa menerbitkan dan tidak bisa mengunggah file; Author bisa menerbitkan tulisannya sendiri; Editor bisa mengelola tulisan semua orang; hanya Administrator yang bisa memasang plugin, mengubah tema, dan mengelola pengguna.
• Alur editorial yang aman memisahkan penulis dan penerbit: kontributor menulis draf, editor mereview dan menerbitkan — bukan semua orang memegang tombol Publish.
• Audit akun berkala wajib dilakukan: hapus akun yang tidak lagi dipakai, turunkan peran yang terlalu tinggi, dan pastikan hanya pemilik situs (plus paling banyak satu orang teknis yang dipercaya) yang memegang peran Administrator.
• Keamanan akun adalah bagian dari manajemen pengguna: kata sandi unik yang panjang, autentikasi dua faktor untuk Administrator dan Editor, dan Application Password terpisah untuk integrasi — bukan kata sandi utama.

Daftar Isi

1. Mengapa Peran Pengguna Penting untuk Publisher
2. Enam Peran Bawaan WordPress dan Batas Masing-Masing
3. Tabel Perbandingan Capability Peran Bawaan
4. Capability: Satuan Izin yang Sebenarnya Dicek WordPress
5. Memetakan Jabatan Tim Redaksi ke Peran yang Tepat
6. Cara Menambah, Mengubah, dan Menghapus Pengguna
7. Alur Editorial yang Aman: dari Draf sampai Terbit
8. Peran Kustom: Kapan Perlu dan Cara Membuatnya
9. Audit Akun Berkala: Menemukan Admin yang Tidak Perlu
10. Mengamankan Akun Tim: Kata Sandi, 2FA, dan Application Password
11. Kesalahan Umum dalam Mengelola Pengguna WordPress
12. Checklist Penerapan untuk Tim Redaksi Kecil
13. FAQ
14. Kesimpulan
15. Sumber resmi yang dirujuk

1. Mengapa Peran Pengguna Penting untuk Publisher

Situs publisher yang dikelola sendirian jarang memikirkan peran pengguna. Pemiliknya adalah Administrator, ia menulis, menerbitkan, memasang plugin, dan mengatur iklan — semuanya dari satu akun. Masalah mulai muncul begitu ada orang kedua. Seorang penulis tamu diminta menulis artikel, seorang editor paruh waktu diminta mereview, atau seorang staf teknis diminta memperbaiki tampilan. Tanpa pembagian peran yang dipikirkan, jawaban paling mudah adalah memberikan akun Administrator kepada semua orang. Jawaban itu juga yang paling berbahaya.

Administrator di instalasi WordPress single-site pada dasarnya memegang kendali penuh: memasang dan menghapus plugin, mengganti tema, mengedit file tema, mengubah pengaturan situs, serta mengelola — termasuk menghapus — pengguna lain. Dokumentasi resmi WordPress menyatakan dengan jelas bahwa pada instalasi single-site, Administrator memiliki semua capability, dan hanya pada Multisite sebagian kemampuan itu naik ke Super Admin. Artinya, akun Administrator yang bocor atau disalahgunakan bukan sekadar “seseorang bisa mengedit artikel”, melainkan pengambilalihan situs secara penuh. Seorang penulis yang hanya butuh menulis artikel tidak pernah membutuhkan kemampuan memasang plugin.

Risiko kedua bersifat operasional, bukan keamanan. Ketika semua orang bisa menerbitkan, tidak ada lagi gerbang kualitas. Artikel yang belum diperiksa faktanya, judul yang belum dioptimasi SEO-nya, atau gambar tanpa alt text bisa terbit begitu saja — dan untuk situs yang mengandalkan AdSense, kualitas konten yang tidak konsisten adalah risiko nyata terhadap pendapatan maupun reputasi di mata Google. Peran yang tepat menciptakan pemisahan tugas secara alami: penulis menulis, editor memeriksa, dan hanya editor (atau pemilik) yang menerbitkan.

Risiko ketiga adalah akumulasi akun. Tim redaksi berubah: penulis lepas selesai kontraknya, kontributor berhenti, agensi selesai mengerjakan proyek. Jika tidak ada yang secara rutin meninjau daftar pengguna, akun-akun lama menumpuk dan setiap akun adalah pintu masuk tambahan ke situs. Panduan keamanan resmi Learn WordPress secara eksplisit menempatkan “review user base” — meninjau basis pengguna, menghapus pengguna yang tidak perlu, dan sangat selektif terhadap siapa yang menjadi admin — sebagai salah satu dari tujuh tips meningkatkan keamanan situs. Bukan tips tambahan, melainkan bagian inti dari keamanan WordPress.

Ada juga dimensi hukum yang sering luput. Setiap akun pengguna menyimpan data pribadi: nama, alamat email, dan kadang lebih. Situs yang mengumpulkan dan menyimpan data pribadi pengguna — termasuk timnya sendiri — perlu memperlakukannya dengan benar, misalnya tidak membagikan kredensial login antar orang dan menghapus akun beserta datanya ketika sudah tidak diperlukan. Prinsipnya sederhana: akun adalah milik satu orang, untuk satu tujuan, selama masih dibutuhkan.

Terakhir, manajemen peran yang baik menghemat waktu. Ketika peran sudah benar, editor tidak perlu lagi mengejar penulis untuk memperbaiki artikel yang terlanjur terbit, pemilik tidak perlu khawatir ada yang mengubah pengaturan iklan, dan onboarding anggota baru menjadi urusan lima menit: buat akun, pilih peran, kirim kredensial. Artikel ini membahas semua itu langkah demi langkah, dengan merujuk pada dokumentasi resmi WordPress di setiap klaim teknisnya.

2. Enam Peran Bawaan WordPress dan Batas Masing-Masing

WordPress menyediakan enam peran bawaan. Lima di antaranya ada di setiap instalasi single-site, dan yang keenam — Super Admin — hanya muncul ketika Multisite diaktifkan. Dokumentasi resmi WordPress.org merangkum masing-masing peran dalam satu kalimat yang sudah cukup menjadi panduan:

Super Admin adalah peran untuk pengelola jaringan Multisite. Ia memiliki semua capability dan dapat mengelola seluruh jaringan: membuat situs baru, memasang plugin dan tema untuk semua situs, serta mengelola pengguna di tingkat jaringan. Untuk situs publisher biasa yang bukan Multisite, peran ini tidak relevan — dan justru karena itu pula, di instalasi single-site, Administrator menjadi pemegang kendali penuh.

Administrator adalah seseorang yang memiliki akses ke semua fitur administrasi dalam satu situs. Ia bisa memasang dan menghapus plugin dan tema, mengubah pengaturan, mengelola pengguna, serta mempublikasikan dan mengelola semua konten. Dokumentasi resmi menegaskan bahwa pada instalasi single-site, Administrator pada dasarnya adalah Super Admin untuk situsnya sendiri. Karena itu aturan praktisnya keras: peran ini hanya untuk pemilik situs dan, bila benar-benar perlu, satu orang teknis yang sangat dipercaya. Jangan pernah memberikannya kepada penulis, editor, atau agensi yang hanya mengerjakan tugas terbatas.

Editor adalah seseorang yang dapat menerbitkan dan mengelola postingan, termasuk postingan pengguna lain. Editor bisa mengedit dan menghapus tulisan siapa pun, mengelola halaman, kategori, tag, dan memoderasi komentar. Yang tidak bisa dilakukan Editor justru sama pentingnya: ia tidak bisa memasang plugin, mengganti tema, mengubah pengaturan situs, atau mengelola pengguna. Batas ini membuat Editor menjadi peran yang ideal untuk penanggung jawab redaksi — ia mengendalikan konten sepenuhnya, tetapi tidak bisa mengubah mesin situsnya.

Author adalah seseorang yang dapat menerbitkan dan mengelola postingannya sendiri. Author bisa menulis, mengedit, menghapus, dan menerbitkan tulisannya sendiri, serta mengunggah file media untuk artikelnya. Ia tidak bisa menyentuh tulisan orang lain dan tidak bisa mengedit halaman. Peran ini cocok untuk penulis tetap yang sudah dipercaya kualitas tulisannya dan memang diizinkan menerbitkan langsung — misalnya penulis senior atau pemilik kolom.

Contributor adalah seseorang yang dapat menulis dan mengelola postingannya sendiri, tetapi tidak dapat menerbitkannya. Draf yang dibuat Contributor berstatus menunggu peninjauan sampai Editor atau Administrator menyetujuinya. Contributor juga tidak bisa mengunggah file media — gambar harus diunggah oleh Editor atau Author. Peran ini adalah pilihan default yang benar untuk penulis tamu, penulis lepas baru, dan siapa pun yang tulisannya harus melewati review sebelum terbit.

Subscriber adalah seseorang yang hanya dapat mengelola profilnya sendiri. Ia hanya memiliki capability “read” — membaca konten dan mengubah data profilnya. Peran ini tepat untuk pembaca yang butuh akun, misalnya anggota komunitas atau pelanggan, tetapi tidak boleh menyentuh dasbor dengan cara apa pun yang bermakna. Jika situs Anda mengizinkan pendaftaran pengguna, Subscriber adalah peran default yang sebaiknya dipilih.

Satu hal yang perlu dipahami: peran bukanlah sekadar label. WordPress tidak memeriksa nama peran ketika seseorang mencoba melakukan sesuatu; ia memeriksa capability. Inilah yang membuat sistem ini fleksibel sekaligus menuntut ketelitian, dan dibahas lebih lanjut pada Bagian 4.

3. Tabel Perbandingan Capability Peran Bawaan

Tabel berikut merangkum capability yang paling sering ditanyakan, berdasarkan dokumentasi resmi WordPress.org. Tanda centang berarti peran tersebut memiliki capability itu secara default di instalasi single-site.

Beberapa catatan penting dari tabel ini. Pertama, garis pemisah yang paling tegas ada di antara Author dan Contributor: kemampuan menerbitkan dan mengunggah file. Jika seorang penulis lepas meminta “tolong saya bisa upload gambar sendiri”, jawaban teknisnya adalah menaikkan perannya dari Contributor ke Author — dan konsekuensi yang ikut naik adalah ia juga bisa menerbitkan sendiri tanpa review. Keputusan itu harus disadari, bukan sekadar mengabulkan permintaan.

Kedua, Editor dan Author terpisah oleh kemampuan mengelola konten orang lain. Editor bisa mengedit tulisan siapa pun; Author tidak. Inilah alasan Editor adalah gerbang kualitas: hanya Editor (dan Administrator) yang bisa memperbaiki tulisan Contributor sebelum terbit.

Ketiga, seluruh baris di bagian bawah tabel — pengaturan, plugin, tema, pengguna — hanya dimiliki Administrator. Inilah yang membuat prinsip least privilege begitu penting: tidak ada jabatan redaksi yang membutuhkan kemampuan memasang plugin. Jika seorang anggota tim mengaku butuh akses plugin untuk tugasnya, hampir selalu ada cara lain: minta ia menjelaskan tugasnya, lalu carilah plugin yang menyediakan capability khusus, atau kerjakan tugas itu sendiri sebagai Administrator.

Sebagai gambaran skala, sebuah panduan independen yang menghitung langsung dari tabel capability resmi WordPress mencatat Administrator memegang 52 capability pada instalasi single-site, Editor 26, dan Author 7. Angka ini berasal dari perhitungan pihak ketiga, bukan dari dokumentasi resmi, tetapi ia menggambarkan dengan baik betapa curamnya jurang antara satu peran dan peran berikutnya: dari Author ke Editor, kewenangan melonjak 19 capability sekaligus. Tidak ada peran bawaan di antara keduanya — dan di situlah peran kustom masuk, dibahas pada Bagian 8.

4. Capability: Satuan Izin yang Sebenarnya Dicek WordPress

Memahami capability adalah kunci memahami mengapa sistem peran WordPress bekerja seperti yang ia lakukan — dan mengapa ia kadang berperilaku di luar dugaan. Peran hanyalah nama untuk sekelompok capability. Ketika seorang pengguna mengklik tombol Publish, WordPress tidak bertanya “apakah pengguna ini seorang Author?”, melainkan “apakah pengguna ini memiliki capability publish_posts?”. Pengecekan ini dilakukan lewat fungsi current_user_can() di dalam kode inti WordPress, dan berlaku untuk setiap tindakan: mengedit, menghapus, mengunggah, memoderasi, sampai mengubah pengaturan.

Implikasinya ada dua. Pertama, dua pengguna dengan label peran yang sama bisa memiliki kekuatan berbeda bila capability mereka sudah dikustomisasi — misalnya lewat plugin atau potongan kode. Label peran tidak menjamin apa pun; yang menjamin adalah daftar capability yang benar-benar dimiliki akun itu. Kedua, plugin dapat menambahkan capability sendiri di atas capability bawaan. Plugin keanggotaan, toko online, atau LMS biasanya mendaftarkan capability khusus untuk fitur mereka, sehingga tabel peran bawaan di Bagian 3 adalah titik awal, bukan gambaran lengkap, untuk situs yang sudah memasang banyak plugin.

Beberapa capability penting yang layak dikenal namanya:

• read — capability paling dasar, dimiliki semua peran termasuk Subscriber. Tanpa ini, pengguna bahkan tidak bisa mengakses dasbor.
• edit_posts — kemampuan membuat dan mengedit tulisan sendiri. Inilah gerbang masuk ke editor tulisan; Contributor adalah peran terendah yang memilikinya.
• publish_posts — kemampuan menerbitkan tulisan sendiri. Garis antara Contributor dan Author.
• edit_others_posts — kemampuan mengedit tulisan pengguna lain. Garis antara Author dan Editor, dan capability yang membuat Editor bisa mereview draf Contributor.
• upload_files — kemampuan mengunggah ke Media Library. Author ke atas memilikinya; Contributor tidak.
• moderate_comments — kemampuan menyetujui, menghapus, dan menandai komentar sebagai spam. Dimiliki Editor ke atas.
• manage_categories — kemampuan membuat dan mengedit kategori serta tag.
• manage_options — kemampuan mengubah pengaturan situs. Ini juga capability yang dipakai sebagian besar halaman pengaturan plugin sebagai gerbang akses, sehingga memberikannya kepada seseorang berarti memberinya akses ke pengaturan banyak plugin sekaligus.
• edit_users, promote_users, delete_users — kemampuan mengelola pengguna lain. Hanya Administrator.
• install_plugins, activate_plugins, edit_plugins — kemampuan yang berhubungan dengan plugin. Hanya Administrator di single-site.

Capability juga disimpan sebagai state di database, tepatnya pada baris wp_user_roles di tabel wp_options. Konsekuensi praktisnya: peran kustom yang dibuat lewat plugin tidak hilang ketika pluginnya dinonaktifkan. Peran itu tetap ada, tetap terpasang pada penggunanya, dan tetap ditegakkan. Ini penting diketahui saat membersihkan situs — menonaktifkan plugin peran tidak otomatis mengembalikan keadaan seperti semula. Untuk mengembalikan peran bawaan ke kondisi aslinya, plugin seperti Members menyediakan tombol reset satu klik, dan itu jauh lebih aman daripada mengutak-atik database secara manual.

Satu peringatan terakhir: beberapa capability lama sudah tidak dipakai lagi oleh inti WordPress, misalnya edit_files, dan ada capability yang digantikan — add_users digantikan oleh promote_users sejak WordPress 4.4. Jika Anda mengikuti tutorial lama yang menyebut capability tersebut, perlakukan dengan curiga dan periksa kembali ke dokumentasi resmi terbaru.

5. Memetakan Jabatan Tim Redaksi ke Peran yang Tepat

Teori peran menjadi berguna ketika diterjemahkan ke jabatan nyata dalam tim redaksi. Tabel berikut adalah pemetaan yang dipakai banyak tim publisher kecil sebagai titik awal — patokan praktik, bukan aturan resmi WordPress — dan dapat disesuaikan dengan kebutuhan masing-masing situs.

Ada tiga keputusan dalam tabel ini yang paling sering menimbulkan perdebatan, dan ketiganya layak dibahas.

Pertama, korektor. Banyak tim memberikan peran Editor kepada korektor karena korektor memang harus mengedit tulisan orang lain. Itu benar secara capability — edit_others_posts hanya dimiliki Editor ke atas. Namun Editor juga bisa menerbitkan, dan bila Anda tidak ingin korektor menerbitkan, solusi yang tepat adalah peran kustom: salin Editor, lalu cabut publish_posts. Cara membuatnya ada di Bagian 8.

Kedua, staf teknis dan agensi. Ini adalah sumber paling umum dari akun Administrator yang berlebih. Seorang pengembang yang memperbaiki tema memang butuh akses Administrator, tetapi hanya selama pekerjaan berlangsung. Praktik yang aman: buat akun Administrator terpisah atas nama orangnya (bukan akun bersama), berikan tenggat yang jelas, dan hapus atau turunkan perannya begitu pekerjaan selesai. Jangan pernah memberikan kredensial akun Administrator utama Anda kepada pihak luar.

Ketiga, manajer media sosial. Banyak plugin media sosial meminta akses Administrator untuk pengaturan awal, tetapi setelah terhubung, aktivitas hariannya — menjadwalkan postingan, misalnya — sering tidak memerlukan peran setinggi itu. Periksa halaman pengaturan plugin Anda: bila halaman itu memakai capability manage_options, maka semua penggunanya harus Administrator. Dalam kasus seperti itu, lebih aman bila penjadwalan dilakukan oleh Editor atau pemilik, atau gunakan alat eksternal yang terhubung lewat Application Password dengan akun berperilaku rendah.

Prinsip yang menyatukan ketiganya: tanyakan “tindakan apa yang benar-benar perlu dilakukan orang ini?”, bukan “jabatan apa yang ia pegang?”. Jabatan adalah urusan organisasi; capability adalah urusan keamanan. Terjemahkan tugas menjadi capability, lalu pilih peran dengan capability yang paling mendekati — dan bila tidak ada yang pas, buat peran kustom.

6. Cara Menambah, Mengubah, dan Menghapus Pengguna

Setelah pemetaan jelas, pelaksanaannya di dasbor WordPress sebenarnya sederhana. Semua langkah di bagian ini memakai fitur bawaan WordPress, tanpa plugin tambahan.

Menambah pengguna baru. Buka menu Pengguna, lalu Tambah Baru. Isi nama pengguna (username), alamat email, nama depan dan belakang, dan pilih peran dari menu dropdown. WordPress akan membuat kata sandi otomatis yang kuat — gunakan itu, atau buat kata sandi sendiri yang panjang dan unik — lalu centang opsi untuk mengirimkan email pemberitahuan kepada pengguna baru. Email itu berisi tautan untuk mengatur kata sandinya sendiri. Penting: jangan pernah mengirim kata sandi lewat pesan chat atau email biasa dalam bentuk teks polos. Biarkan pengguna mengatur kata sandinya sendiri lewat tautan resmi WordPress.

Satu hal yang sering ditanyakan: apakah pengguna baru bisa mendaftar sendiri? Secara default, pendaftaran di WordPress nonaktif. Anda bisa mengaktifkannya di Pengaturan, lalu Umum, dengan mencentang “Siapa pun bisa mendaftar” dan memilih peran default untuk pendaftar baru. Dokumentasi resmi WordPress menyatakan peran default untuk pengguna baru diatur di Pengaturan, lalu Umum. Untuk situs publisher, peran default yang aman adalah Subscriber. Jangan pernah mengatur peran default ke Author atau lebih tinggi — itu berarti siapa pun yang mendaftar bisa langsung menerbitkan.

Mengubah peran pengguna. Buka Pengguna, lalu Semua Pengguna. Arahkan ke pengguna yang dimaksud, klik “Ubah peran menjadi…” yang muncul, atau buka halaman profilnya dan pilih peran baru dari dropdown, lalu simpan. Perubahan berlaku seketika: begitu peran diturunkan, menu-menu yang tidak lagi berhak diakses pengguna itu langsung hilang dari dasbornya. Inilah cara Anda menaikkan seorang Contributor yang sudah terbukti kualitasnya menjadi Author, atau menurunkan seorang Editor yang sudah tidak lagi aktif.

Menghapus pengguna. Di daftar Semua Pengguna, pilih pengguna, lalu Hapus. WordPress akan bertanya apa yang harus dilakukan dengan konten milik pengguna itu: hapus semua kontennya, atau alihkan (attribute) ke pengguna lain. Untuk tim redaksi, hampir selalu pilih alihkan ke Editor atau Administrator — menghapus artikel yang sudah terbit dan mungkin sudah terindeks Google hanya karena penulisnya berhenti adalah kesalahan yang mahal. Pilihan pengalihan ini juga alasan mengapa Anda sebaiknya tidak menghapus akun penulis lama secara tergesa-gesa; pastikan dulu ke mana kontennya dialihkan.

Mengelola profil sendiri. Setiap pengguna dapat membuka Pengguna, lalu Profil, untuk memperbarui nama tampilannya, alamat email, dan kata sandinya. Di halaman yang sama pula pengguna dapat membuat Application Password untuk integrasi — dibahas pada Bagian 10. Sebagai administrator, biasakan memeriksa bahwa nama tampilan (display name) penulis sudah benar sebelum artikelnya terbit, karena nama itulah yang muncul di byline artikel dan arsip penulis.

7. Alur Editorial yang Aman: dari Draf sampai Terbit

Peran yang benar baru menghasilkan nilai bila disertai alur kerja yang memanfaatkan batas-batas peran itu. Berikut alur yang dipakai banyak tim publisher kecil, dan dapat dijalankan sepenuhnya dengan peran bawaan WordPress.

Langkah 1 — Penulis membuat draf. Contributor atau Author menulis artikel di editor, mengisi judul, dan menyimpan sebagai draf. Contributor tidak memiliki tombol Publish — tombol yang ia lihat hanyalah “Kirim untuk Ditinjau” (Submit for Review). Status itu adalah sinyal bagi editor bahwa ada draf menunggu. Author yang menulis drafnya sendiri bisa memilih menerbitkan langsung, tetapi dalam tim yang menerapkan review, penulis senior pun sebaiknya menyimpan sebagai draf dan memberi tahu editor.

Langkah 2 — Editor mereview. Editor membuka draf dari menu Postingan, lalu Semua Postingan, dengan filter status “Menunggu Tinjau” (Pending). Di sini editor memeriksa hal-hal yang sering lolos dari penulis: akurasi klaim dan sumbernya, struktur heading (judul di kolom judul, isi dimulai dari H2, bukan H1 ganda), kelengkapan gambar dan alt text, kategori dan tag yang benar, serta excerpt yang terisi. Bila ada yang perlu diperbaiki, editor bisa mengedit langsung — karena Editor memiliki edit_others_posts — atau mengembalikan draf dengan catatan. Perlu diingat: ketika editor mengedit draf orang lain, nama penulis asli tetap tercatat sebagai penulis artikel, kecuali editor sengaja mengubahnya di panel penulis.

Langkah 3 — Penjadwalan atau penerbitan. Setelah draf disetujui, Editor (atau Administrator) yang menekan Terbitkan, atau menjadwalkan tanggal terbit lewat panel tanggal di editor. Penjadwalan sebaiknya menjadi wewenang editor juga, agar ritme terbit situs tetap terkendali — misalnya satu artikel per hari pada jam yang sama — bukan mengikuti kapan masing-masing penulis selesai menulis.

Langkah 4 — Pemeriksaan setelah terbit. Editor atau pemilik membuka URL publik artikel, memastikan thumbnail tampil, judul benar, dan tidak ada bagian yang hilang. Pemeriksaan ini penting karena beberapa masalah — misalnya bagian artikel yang gagal tersimpan saat ditempel dari dokumen lain — hanya terlihat di halaman publik, bukan di editor. Untuk situs yang mengirim URL ke Google dan Bing setelah terbit, langkah ini juga menjadi gerbang sebelum pengiriman indeks dilakukan.

Langkah 5 — Revisi setelah terbit. Bila artikel yang sudah terbit perlu diperbaiki, yang boleh mengeditnya adalah penulis aslinya (Author bisa mengedit tulisannya sendiri yang sudah terbit) atau Editor. Contributor tidak bisa mengedit artikel yang sudah terbit — ia bahkan tidak bisa mengedit drafnya sendiri setelah draf itu berubah status, tergantung pengaturan. Aturan ini melindungi artikel yang sudah tayang dari perubahan yang tidak melalui editor.

Alur ini sengaja sederhana, dan kesederhanaannya adalah kekuatannya: setiap perpindahan status melibatkan orang yang berbeda, sehingga kesalahan satu orang tertangkap oleh orang berikutnya. Untuk tim yang lebih besar, alur yang sama bisa diperkaya dengan plugin editorial — misalnya plugin yang menambah status kustom seperti “Butuh Foto” atau “Siap Review” — tetapi fondasinya tetap peran bawaan WordPress.

Satu catatan tentang kolaborasi real-time: WordPress tidak memiliki pengeditan kolaboratif seperti Google Docs. Jika dua orang membuka editor yang sama, WordPress akan mengunci postingan untuk pengguna kedua (post lock) dan menampilkan siapa yang sedang mengedit. Jangan mencoba mengakali kunci ini dengan berbagi satu akun — akun bersama menghilangkan jejak siapa melakukan apa, dan melanggar prinsip satu akun untuk satu orang.

8. Peran Kustom: Kapan Perlu dan Cara Membuatnya

Peran bawaan WordPress hanya lima (di luar Super Admin). Cepat atau lambat, tim redaksi akan menemukan celah di antaranya: korektor yang perlu mengedit tetapi tidak menerbitkan, penulis senior yang boleh mengunggah gambar tetapi belum boleh terbit sendiri, atau editor foto yang hanya perlu mengelola Media Library. Untuk celah seperti itulah peran kustom dibuat.

Kapan peran kustom diperlukan — dan kapan tidak. Buat peran kustom bila ada tugas yang berulang dan tidak terpetakan ke peran bawaan. Jangan buat peran kustom untuk satu tugas sekali jalan; untuk itu, lebih mudah memberikan peran bawaan yang lebih tinggi untuk sementara, lalu menurunkannya lagi. Jangan pula membuat peran kustom hanya karena nama jabatannya terdengar berbeda — bila tugasnya sama dengan Author, gunakan Author, apa pun sebutan jabatannya di organisasi Anda.

Cara pertama: plugin User Role Editor. Plugin gratis ini tersedia di direktori plugin WordPress.org dan, menurut halaman resminya, memungkinkan Anda mengubah peran dan capability dengan mencentang kotak, menambahkan peran baru dari nol atau sebagai salinan peran lain, menghapus peran yang tidak lagi dipakai (selama tidak ada pengguna yang masih memakainya), serta menetapkan capability per pengguna. Versi terbarunya saat artikel ini ditulis adalah 4.66.3 (diperbarui 26 Oktober 2026). Langkah umumnya: pasang plugin, buka Pengguna, lalu User Role Editor, pilih peran yang ingin disalin — misalnya Editor — klik Add Role, beri ID dan nama peran baru, lalu hilangkan centang pada capability yang tidak diinginkan, misalnya publish_posts untuk peran “Korektor”. Simpan, lalu tetapkan peran baru itu kepada pengguna yang bersangkutan dari halaman Pengguna.

Cara kedua: plugin Members. Members adalah plugin peran dan keanggotaan berbasis sistem roles and capabilities WordPress, juga tersedia gratis di WordPress.org. Ia menyediakan Role Editor untuk membuat dan mengedit peran, kemampuan mengkloning peran, memberikan beberapa peran kepada satu pengguna, serta menolak capability tertentu secara eksplisit untuk suatu peran. Members juga menyediakan tombol Reset Roles yang mengembalikan kelima peran bawaan ke capability aslinya dalam satu klik — fitur penyelamat bila kustomisasi sebelumnya sudah berantakan dan Anda ingin mulai dari awal. Members membutuhkan WordPress 6.9 atau lebih baru pada versi terkininya, jadi periksa kecocokan versi sebelum memasang.

Cara ketiga: kode, untuk pengembang. Bila Anda nyaman menambahkan potongan kode — misalnya lewat plugin kustom atau child theme — WordPress menyediakan fungsi add_role() untuk membuat peran dan add_cap() untuk menambah capability ke peran yang ada. Contoh singkat membuat peran korektor dari dokumentasi pengembang:

add_role( 'proofreader', 'Korektor', array(
    'read' => true,
    'edit_posts' => true,
    'edit_others_posts' => true,
    'edit_published_posts' => true,
) );

Peran di atas bisa membaca, mengedit tulisan sendiri dan tulisan orang lain, tetapi tidak bisa menerbitkan dan tidak bisa mengunggah file. Perlu diingat bahwa add_role() hanya perlu dijalankan sekali — peran yang dibuat tersimpan di database — jadi letakkan kode ini di hook aktivasi plugin, bukan di file yang dieksekusi setiap kali halaman dimuat. Dan seperti sudah disinggung pada Bagian 4, peran yang dibuat lewat kode tidak hilang saat pluginnya dinonaktifkan; untuk menghapusnya diperlukan remove_role().

Peringatan yang tidak boleh dilewatkan. Kemampuan mengedit peran adalah kemampuan yang sangat kuat, dan karena itu hanya Administrator yang boleh melakukannya. Jangan pernah memberikan akses ke halaman User Role Editor atau Members kepada Editor atau Author, dengan cara apa pun. Selain itu, sebelum mengubah capability peran bawaan, buatlah cadangan (backup) database terlebih dahulu — perubahan peran tersimpan di database, dan kesalahan di sini sulit dilacak tanpa cadangan. Terakhir, setiap peran kustom harus dicatat: nama, salinan dari peran apa, capability apa yang ditambah atau dikurangi, dan siapa saja penggunanya. Tanpa catatan itu, enam bulan kemudian tidak ada yang ingat mengapa peran “Editor Foto” bisa menghapus komentar.

9. Audit Akun Berkala: Menemukan Admin yang Tidak Perlu

Manajemen pengguna bukan pekerjaan sekali jalan. Akun bertambah, orang berganti peran, dan proyek selesai — tetapi akun jarang berkurang dengan sendirinya. Karena itu audit akun berkala adalah rutinitas wajib, dan panduan keamanan resmi WordPress menempatkannya sejajar dengan kata sandi yang kuat dan autentikasi dua faktor. Patokan praktik yang masuk akal untuk tim kecil: audit setiap tiga bulan, dan audit tambahan setiap kali seseorang keluar dari tim atau sebuah proyek selesai.

Langkah audit yang bisa diselesaikan dalam 15 menit:

1. Buka Pengguna, lalu Semua Pengguna, dan urutkan berdasarkan peran. Fokus pertama: siapa saja yang berstatus Administrator? Seharusnya hanya pemilik situs dan paling banyak satu orang teknis yang dipercaya. Setiap nama lain di daftar ini harus bisa menjelaskan mengapa ia butuh kendali penuh.
2. Periksa tanggal terakhir setiap pengguna aktif. WordPress tidak menampilkan “terakhir login” secara bawaan — untuk itu ada plugin activity log — tetapi Anda bisa memeriksa dari tanggal artikel terakhir yang ia tulis atau dari log aktivitas bila plugin semacam itu terpasang. Akun yang tidak aktif lebih dari tiga bulan patut dipertanyakan.
3. Turunkan peran yang terlalu tinggi. Editor yang sudah tidak lagi mereview, Author yang sudah berhenti menulis — turunkan ke Contributor atau hapus, tergantung apakah ia masih akan berkontribusi.
4. Hapus akun yang sudah tidak dipakai, dengan mengalihkan kontennya ke pengguna aktif seperti dijelaskan pada Bagian 6. Jangan menunda penghapusan akun mantan anggota tim dengan alasan “nanti saja” — akun yang tidak diawasi adalah akun yang paling mungkin disalahgunakan.
5. Periksa peran default pendaftaran di Pengaturan, lalu Umum. Pastikan tetap Subscriber dan pendaftaran hanya aktif bila memang dibutuhkan. Banyak situs membiarkan pendaftaran aktif tanpa sadar setelah memasang plugin yang mengaktifkannya.
6. Periksa Application Password yang masih aktif di profil setiap Administrator. Application Password yang tidak dikenal atau tidak lagi dipakai harus dicabut — caranya ada di Bagian 10.
7. Catat hasil audit: siapa yang dihapus, siapa yang diturunkan, dan kapan audit dilakukan. Catatan ini menjadi bukti bila di kemudian hari muncul pertanyaan tentang siapa yang memiliki akses ke situs.

Satu hal yang sering terlewat dalam audit adalah akun layanan (service account) — akun yang dibuat untuk plugin, alat otomatisasi, atau integrasi. Akun semacam ini sering diberi peran Administrator saat penyiapan, lalu dilupakan. Prinsip yang sama berlaku: berikan peran serendah mungkin. Untuk integrasi yang hanya membaca data atau mengirim konten, peran Author atau bahkan Contributor sering kali sudah cukup, dan Application Password dengan akun berperilaku rendah jauh lebih aman daripada kata sandi Administrator yang dibagikan ke layanan pihak ketiga.

Audit juga menjadi momen yang tepat untuk memeriksa konsistensi nama tampilan penulis. Arsip penulis di situs publisher adalah aset: halaman arsip penulis yang rapi dengan foto dan bio yang benar membantu pembaca mengenali penulis dan membantu Google memahami siapa di balik konten — bagian dari sinyal E-E-A-T yang relevan untuk situs konten. Pastikan setiap penulis aktif memiliki nama tampilan yang benar dan, bila tema mendukungnya, biografi singkat di profilnya.

10. Mengamankan Akun Tim: Kata Sandi, 2FA, dan Application Password

Peran yang tepat tidak ada gunanya bila akunnya sendiri mudah dibobol. Keamanan akun adalah separuh dari manajemen pengguna, dan tiga lapisan berikut saling melengkapi: kata sandi yang kuat, autentikasi dua faktor, dan pemisahan kredensial integrasi.

Kata sandi yang kuat dan unik. Panduan keamanan resmi Learn WordPress merekomendasikan penggunaan password manager dan kata sandi yang panjangnya setidaknya 10 sampai 12 karakter, mencakup angka dan simbol, serta tidak pernah sama antara satu layanan dengan layanan lain. Jangan pernah memakai “admin” sebagai nama pengguna — ini adalah nama pengguna pertama yang dicoba dalam serangan brute force. WordPress sendiri, saat Anda membuat atau mengatur ulang kata sandi, akan menyarankan kata sandi acak yang panjang lengkap dengan indikator kekuatan; gunakan saran itu, dan simpan kata sandinya di password manager, bukan di catatan yang dibagikan lewat chat. Setiap anggota tim harus memiliki akun dan kata sandinya sendiri. Akun bersama — satu username dan kata sandi yang dipakai bergantian oleh beberapa orang — menghilangkan akuntabilitas dan membuat pencabutan akses menjadi mustahil tanpa mengganti kata sandi untuk semua orang.

Autentikasi dua faktor (2FA). 2FA menambahkan lapisan kedua pada proses login: selain kata sandi, pengguna harus memasukkan kode sekali pakai dari aplikasi autentikator atau email. Learn WordPress menyatakan bahwa 2FA dapat meningkatkan keamanan situs secara signifikan, karena sekalipun kata sandi bocor, penyerang tetap tidak bisa masuk tanpa faktor kedua. WordPress inti tidak menyediakan 2FA — ia ditambahkan lewat plugin. Plugin resmi dari kontributor WordPress.org bernama Two-Factor mendukung kode email, kode sekali pakai berbasis waktu (TOTP) dari aplikasi autentikator, dan kode cadangan. Alternatif yang juga disebut dalam panduan resmi antara lain WP 2FA dan Google Authenticator. Aturan praktis yang layak diterapkan: wajibkan 2FA untuk semua Administrator, dan sangat disarankan untuk Editor. Untuk tim kecil, aktifkan 2FA segera setelah akun dibuat — jangan menunggu sampai situs menjadi target.

Satu hal penting tentang 2FA: siapkan jalur pemulihan sebelum mengaktifkannya. Bila seorang administrator kehilangan ponselnya dan tidak memiliki kode cadangan, ia bisa terkunci dari situsnya sendiri. Simpan kode cadangan di tempat yang aman, dan pastikan ada setidaknya satu Administrator lain — atau akses darurat lewat hosting — yang dapat menonaktifkan 2FA bila diperlukan. Dokumentasi plugin Two-Factor menjelaskan bahwa pengaturan 2FA berada di halaman Profil masing-masing pengguna, di bagian Two-Factor Options.

Application Password untuk integrasi. Banyak tugas publisher modern melibatkan integrasi: alat yang mengirim artikel dari Google Docs, aplikasi seluler, atau layanan otomatisasi yang mempublikasikan lewat REST API. Untuk keperluan seperti ini, WordPress menyediakan Application Password — kata sandi terpisah yang dibuat per pengguna dan per aplikasi, yang dapat dicabut satu per satu tanpa mengubah kata sandi utama. Application Password diperkenalkan di WordPress 5.6, dibuat dari halaman Profil pengguna, hanya ditampilkan sekali saat pembuatan, dan tidak berfungsi untuk login ke wp-admin — ia hanya berlaku untuk permintaan API. Praktik yang aman: buat Application Password dengan akun berperilaku rendah yang khusus dibuat untuk integrasi itu, beri nama yang menjelaskan tujuannya (“Aplikasi Penjadwal Media Sosial”, misalnya), dan cabut segera bila integrasi sudah tidak dipakai. Jangan pernah memakai kata sandi utama akun Administrator untuk integrasi, dan jangan pernah memakai satu Application Password untuk banyak layanan sekaligus — bila satu layanan bocor, Anda harus bisa mencabut aksesnya saja tanpa mengganggu yang lain.

Pembatasan percobaan login. Lapisan tambahan yang layak disebut: batasi percobaan login yang gagal. WordPress inti tidak membatasi jumlah percobaan login, sehingga plugin keamanan seperti Wordfence, Jetpack Security, atau iThemes — ketiganya disebut dalam panduan Learn WordPress — dapat menambahkan pembatasan ini sekaligus memindai kerentanan yang dilaporkan. Untuk tim kecil, memasang satu plugin keamanan yang tepercaya dan mengaktifkan pembatasan login adalah langkah yang murah dan efektif. Yang tidak kalah penting: pastikan WordPress, tema, dan plugin selalu diperbarui, karena pembaruan keamanan sering menutup celah yang sedang dieksploitasi.

11. Kesalahan Umum dalam Mengelola Pengguna WordPress

Sebagian besar insiden akses di situs publisher bukan berasal dari serangan yang canggih, melainkan dari kesalahan yang berulang. Berikut kesalahan yang paling sering terjadi, dan cara menghindarinya.

Memberikan Administrator kepada semua orang. Ini kesalahan nomor satu, dan sudah dibahas panjang lebar di Bagian 1. Aturan sederhananya: bila seseorang hanya menulis, ia Contributor atau Author. Bila ia mereview, ia Editor. Administrator hanya untuk yang mengelola situsnya. Setiap kali Anda tergoda memberikan Administrator “supaya gampang”, ingatlah bahwa Anda baru saja memberikan kunci yang sama dengan yang Anda pegang.

Menggunakan akun bersama. Satu akun “redaksi” yang dipakai lima orang adalah lima orang yang tidak bisa dibedakan. Bila terjadi perubahan yang merugikan — artikel terhapus, pengaturan berubah — tidak ada yang bisa ditelusuri. Selain itu, ketika satu orang keluar dari tim, kata sandi akun bersama harus diganti dan dibagikan ulang ke semua orang — sebuah pekerjaan yang hampir selalu tertunda, sehingga mantan anggota tim tetap bisa masuk. Buat akun per orang, selalu.

Membiarkan peran default pendaftaran terlalu tinggi. Situs yang mengaktifkan pendaftaran pengguna dengan peran default Author secara efektif membiarkan siapa pun di internet menerbitkan artikel. Periksa Pengaturan, lalu Umum, secara berkala. Untuk kebanyakan situs publisher, pendaftaran sebaiknya nonaktif sama sekali; bila harus aktif, peran defaultnya adalah Subscriber.

Menghapus pengguna tanpa mengalihkan kontennya. WordPress menawarkan pilihan saat menghapus pengguna, tetapi pilihan “hapus semua konten” sering diklik tanpa dipikirkan. Artikel yang sudah terbit dan terindeks ikut terhapus, tautan internal mengarah ke halaman 404, dan otoritas halaman yang sudah dibangun selama berbulan-bulan hilang begitu saja. Selalu alihkan konten ke pengguna aktif.

Memberikan akses plugin lewat peran yang salah. Banyak plugin menempatkan halaman pengaturannya di balik capability manage_options, yang berarti hanya Administrator yang bisa membukanya. Memberikan Administrator kepada seseorang hanya agar ia bisa membuka satu halaman pengaturan plugin adalah kesalahan. Solusinya: periksa apakah plugin itu menyediakan pengaturan capability sendiri, atau kerjakan pengaturan itu sendiri sebagai Administrator dan berikan tugas hariannya lewat peran yang lebih rendah.

Tidak mencatat peran kustom. Peran kustom yang dibuat tanpa catatan menjadi misteri beberapa bulan kemudian. Siapa yang membuat peran “Editor Foto”? Capability apa yang ia miliki? Siapa saja penggunanya? Tanpa catatan, audit menjadi tebak-tebakan. Simpan catatan sederhana — bahkan sebuah halaman atau dokumen — yang mencatat setiap peran kustom, salinan dari peran apa, dan siapa penggunanya.

Mengabaikan akun yang sudah tidak aktif. Akun mantan penulis lepas yang masih aktif dua tahun setelah kontraknya berakhir adalah pintu masuk yang tidak diawasi. Audit triwulanan pada Bagian 9 ada justru untuk mencegah hal ini. Jadwalkan di kalender, dan perlakukan sebagai tugas rutin seperti halnya backup.

Mengandalkan kata sandi saja. Tanpa 2FA, keamanan akun Administrator bergantung pada satu rahasia. Sekali kata sandi itu bocor — lewat phishing, kebocoran data di layanan lain, atau sekadar kata sandi yang lemah — situs terbuka sepenuhnya. Aktifkan 2FA untuk Administrator dan Editor, dan gunakan password manager untuk semua akun.

12. Checklist Penerapan untuk Tim Redaksi Kecil

Bagian terakhir ini merangkum seluruh artikel menjadi daftar tindakan yang bisa diselesaikan dalam satu sesi kerja. Patokan waktunya adalah ilustrasi untuk tim dengan kurang dari sepuluh pengguna; tim yang lebih besar mungkin membutuhkan waktu lebih lama, tetapi langkah-langkahnya sama.

Hari ini (30 menit):

• Buka Pengguna, lalu Semua Pengguna. Catat siapa saja yang berstatus Administrator. Bila ada yang tidak seharusnya, turunkan perannya sekarang.
• Periksa Pengaturan, lalu Umum. Pastikan pendaftaran pengguna nonaktif, atau bila aktif, peran defaultnya adalah Subscriber.
• Aktifkan 2FA untuk akun Administrator Anda sendiri, dan simpan kode cadangannya di tempat yang aman.

Minggu ini:

• Petakan setiap anggota tim ke peran yang tepat mengikuti tabel pada Bagian 5. Naikkan atau turunkan peran sesuai pemetaan itu.
• Buat akun terpisah untuk setiap orang yang masih memakai akun bersama, lalu hapus akun bersamanya setelah konten dialihkan.
• Periksa Application Password yang aktif di profil Administrator, dan cabut yang tidak dikenal.
• Buat peran kustom bila ada celah yang berulang — misalnya peran Korektor dari salinan Editor tanpa publish_posts — dan catat peran itu beserta penggunanya.

Setiap tiga bulan (jadwalkan di kalender):

• Ulangi audit akun pada Bagian 9: hapus akun yang tidak aktif, turunkan peran yang terlalu tinggi, dan periksa kembali peran default pendaftaran.
• Tinjau daftar peran kustom: apakah masih ada yang memakai peran itu? Apakah capability-nya masih sesuai?
• Pastikan setiap anggota tim baru sudah mendapatkan 2FA, dan setiap anggota yang keluar sudah tidak memiliki akses.

Setiap ada anggota baru:

• Buat akun dengan peran terendah yang memadai — biasanya Contributor untuk penulis baru.
• Kirim tautan pengaturan kata sandi resmi WordPress, bukan kata sandi dalam bentuk teks.
• Minta ia mengaktifkan 2FA pada hari pertama, dan catat tanggal bergabungnya beserta perannya.

Mengelola pengguna dan peran bukanlah pekerjaan yang glamor, tetapi inilah fondasi yang membuat semua pekerjaan glamor — artikel yang bagus, terbit tepat waktu, dan pendapatan iklan yang stabil — bisa berjalan tanpa gangguan. Situs publisher yang tumbuh adalah situs yang timnya tumbuh, dan tim yang tumbuh membutuhkan pagar yang jelas tentang siapa boleh melakukan apa. WordPress sudah menyediakan pagar itu; tugas pemilik situs hanyalah memasangnya dengan benar dan memeriksanya secara berkala.

FAQ

Apakah seorang Contributor bisa mengunggah gambar ke artikelnya?

Tidak. Secara default, Contributor tidak memiliki capability upload_files, sehingga ia tidak bisa mengunggah file ke Media Library. Bila penulis lepas Anda perlu mengunggah gambar sendiri, ada dua pilihan: naikkan perannya menjadi Author — dengan konsekuensi ia juga bisa menerbitkan sendiri — atau biarkan Editor yang mengunggahnya. Untuk tim yang menerapkan review ketat, pilihan kedua lebih aman: penulis mengirim gambar lewat cara lain, dan editor mengunggahnya saat mereview draf.

Berapa banyak Administrator yang sebaiknya dimiliki sebuah situs?

Patokan praktik yang umum adalah satu: pemilik situs. Bila memang ada kebutuhan teknis, tambahkan paling banyak satu orang teknis yang sangat dipercaya, dan hanya selama ia aktif mengerjakan situs. Setiap Administrator tambahan adalah pengambilalihan situs penuh yang menunggu terjadi, karena Administrator bisa mengubah apa saja — termasuk menurunkan peran Administrator lain. Audit triwulanan harus selalu memeriksa daftar ini terlebih dahulu.

Apakah Editor bisa menghapus artikel yang ditulis Administrator?

Ya, Editor bisa mengedit dan menghapus postingan pengguna lain, termasuk postingan Administrator, karena Editor memiliki capability edit_others_posts dan delete_others_posts. Inilah alasan Editor harus dijabat oleh orang yang dipercaya penuh atas konten. Bila Anda membutuhkan seseorang yang bisa mengedit tetapi tidak menghapus, buatlah peran kustom dari salinan Editor tanpa capability delete_others_posts dan delete_published_posts.

Apa yang terjadi pada artikel seseorang bila akunnya dihapus?

Saat menghapus pengguna, WordPress menanyakan apakah semua konten miliknya harus dihapus atau dialihkan ke pengguna lain. Pilih alihkan ke pengguna aktif — biasanya Editor atau Administrator — agar artikel yang sudah terbit tetap tayang dan tautannya tetap berfungsi. Menghapus konten beserta akunnya akan membuat seluruh artikel orang itu hilang dari situs dan dari indeks Google.

Apakah peran kustom hilang bila plugin pembuatnya dinonaktifkan?

Tidak. Peran dan capability disimpan di database WordPress (baris wp_user_roles di tabel wp_options), bukan di dalam plugin. Menonaktifkan plugin seperti User Role Editor atau Members tidak menghapus peran kustom yang sudah dibuat. Untuk mengembalikan peran bawaan ke kondisi aslinya, gunakan fitur reset yang disediakan plugin Members, atau hapus peran kustom secara eksplisit lewat fungsi remove_role().

Bagaimana cara membatasi percobaan login yang gagal di WordPress?

WordPress inti tidak membatasi jumlah percobaan login, jadi perlindungan ini ditambahkan lewat plugin keamanan. Panduan resmi Learn WordPress menyebut Wordfence, Jetpack Security, dan iThemes sebagai contoh plugin yang dapat memindai kerentanan dan menambahkan perlindungan login. Pasang salah satu yang tepercaya, aktifkan pembatasan percobaan login, dan pastikan Administrator serta Editor juga memakai autentikasi dua faktor — pembatasan login dan 2FA saling melengkapi, bukan saling menggantikan.

Kesimpulan

Mengelola pengguna dan peran di WordPress adalah pekerjaan fondasi bagi setiap situs publisher yang tidak lagi dikelola sendirian. Enam peran bawaan — Administrator, Editor, Author, Contributor, Subscriber, plus Super Admin untuk Multisite — sudah menyediakan pembagian tugas yang masuk akal: penulis menulis, editor mereview dan menerbitkan, dan hanya pemilik situs yang memegang kendali atas plugin, tema, dan pengaturan. Prinsip least privilege — peran terendah yang masih memungkinkan seseorang bekerja — melindungi situs dari kesalahan yang tidak disengaja maupun penyalahgunaan, sementara alur editorial yang memisahkan penulis dan penerbit menjaga kualitas setiap artikel yang terbit. Bila peran bawaan tidak cukup, peran kustom dari plugin seperti User Role Editor atau Members dapat mengisi celah di antaranya, asalkan dicatat dan diaudit. Dan semua itu hanya berfungsi bila akunnya sendiri aman: kata sandi yang panjang dan unik, autentikasi dua faktor untuk Administrator dan Editor, Application Password terpisah untuk integrasi, serta audit akun setiap tiga bulan untuk menghapus akses yang sudah tidak diperlukan. Mulailah dari langkah yang paling berdampak hari ini: periksa siapa saja Administrator di situs Anda, dan pastikan hanya orang yang seharusnya yang memegang kunci itu.

Sumber resmi yang dirujuk

1. WordPress.org — Roles and Capabilities (dokumentasi resmi: enam peran bawaan, definisi setiap peran, daftar capability, pengaturan peran default di Settings > General) — https://wordpress.org/documentation/article/roles-and-capabilities/
2. WordPress Developer Resources — Roles and Capabilities, Plugin Handbook (penyimpanan peran di tabel options dengan kunci user_roles, fungsi add_role/add_cap/remove_role) — https://developer.wordpress.org/plugins/users/roles-and-capabilities/
3. Learn WordPress — 7 Tips to Improve Website Security (password manager, kata sandi minimal 10–12 karakter dengan angka dan simbol, jangan memakai “admin” sebagai username, autentikasi dua faktor, review user base, plugin keamanan Wordfence/Jetpack Security/iThemes) — https://learn.wordpress.org/lesson/7-tips-to-improve-website-security/
4. WordPress.org — User Role Editor (plugin: ubah peran dan capability lewat kotak centang, tambah peran baru sebagai salinan peran lain, capability per pengguna, beberapa peran untuk satu pengguna, versi 4.66.3 diperbarui 26 Oktober 2026) — https://wordpress.org/plugins/user-role-editor/
5. WordPress.org — Members, Membership & User Role Editor Plugin (Role Editor, kloning peran, beberapa peran per pengguna, penolakan capability eksplisit, tombol Reset Roles, membutuhkan WordPress 6.9 atau lebih baru) — https://wordpress.org/plugins/members/
6. WordPress.org — Two-Factor (plugin resmi kontributor WordPress.org: kode email, TOTP, kode cadangan; pengaturan di halaman Profil pengguna) — dirujuk melalui panduan Learn WordPress dan dokumentasi plugin Two-Factor di direktori WordPress.org.