Mengecek keamanan website tidak cukup dengan melihat ikon gembok di browser. HTTPS memang penting, tetapi website yang sudah memakai HTTPS tetap bisa terkena malware, spam SEO, redirect mencurigakan, plugin rentan, atau kebocoran akses admin.
Untuk pemilik bisnis, terutama yang menggunakan website untuk menerima leads, formulir kontak, transaksi, atau data pelanggan, pengecekan keamanan perlu dilihat dari dua sisi. Pertama, apa yang terlihat oleh pengunjung. Kedua, apa yang terjadi di balik website.
Jika pengecekan hanya dilakukan dari luar, Anda mungkin tahu website tampak aman saat dibuka. Namun, itu belum membuktikan file, database, akun admin, plugin, dan konfigurasi server benar-benar bersih.
Apa yang Sebenarnya Dicek Saat Mengecek Keamanan Website?
Dalam praktiknya, “cek keamanan website” bisa berarti beberapa hal. Pengunjung biasanya ingin memastikan sebuah situs aman untuk dibuka, login, atau diisi data. Pemilik website ingin tahu apakah websitenya aman dari malware, phishing, kebocoran data, spam SEO, atau masalah teknis yang bisa merusak reputasi bisnis.
Karena itu, cara mengeceknya tidak bisa bergantung pada satu alat. Ada hal yang bisa dilihat dari browser, seperti HTTPS, mixed content, peringatan keamanan, atau reputasi domain. Ada juga hal yang perlu dicek dari dalam, seperti plugin WordPress, file server, akun admin, backup, dan laporan Google Search Console.
Kesalahan yang sering terjadi adalah menganggap hasil “aman” dari satu scanner online sebagai bukti bahwa website sudah sepenuhnya aman. Padahal, scanner eksternal hanya membaca bagian publik website. Alat seperti ini belum tentu bisa melihat file tersembunyi, database, backdoor di hosting, user admin mencurigakan, atau celah plugin yang belum tampak dari luar.
Cara yang lebih tepat adalah membagi pengecekan ke beberapa lapisan: koneksi, reputasi domain, malware, CMS, login, server, backup, dan data pengguna. Dengan begitu, Anda tidak berhenti di tanda gembok, tetapi juga memeriksa risiko yang lebih sering merugikan website bisnis.
Mulai dari HTTPS, tapi Jangan Berhenti di Sana
Langkah paling dasar adalah memastikan website memakai HTTPS dengan sertifikat SSL/TLS yang valid. HTTPS membuat koneksi antara browser dan server terenkripsi, sehingga data yang dikirim pengunjung tidak mudah disadap atau dimodifikasi di tengah jalan.
Namun, HTTPS bukan jaminan bahwa website bebas dari penipuan, malware, atau peretasan. Situs phishing dan website yang sudah disusupi juga bisa memakai HTTPS. Jadi, HTTPS sebaiknya dipahami sebagai syarat dasar keamanan koneksi, bukan bukti bahwa seluruh website aman.
Dari sisi bisnis, HTTPS tetap penting. Website tanpa HTTPS bisa terlihat kurang profesional, menurunkan kepercayaan pengunjung, dan memicu peringatan browser pada kondisi tertentu. Google juga sudah mengumumkan rencana Chrome untuk makin mendorong koneksi aman secara default, sehingga website publik yang masih bergantung pada HTTP berisiko menimbulkan friksi bagi pengguna.
Yang perlu dicek bukan hanya apakah SSL sudah aktif. Pastikan semua versi URL diarahkan dengan benar ke HTTPS. Misalnya, http://domain.com, http://www.domain.com, https://domain.com, dan https://www.domain.com sebaiknya tidak membuka versi website yang berbeda-beda tanpa kontrol.
Cek juga apakah sertifikat masih berlaku, redirect berjalan benar, dan tidak ada halaman penting yang masih terbuka lewat HTTP. Untuk pengecekan teknis yang lebih rinci, alat seperti SSL Labs dapat membantu membaca kualitas konfigurasi SSL/TLS, bukan hanya mendeteksi ada atau tidaknya sertifikat.
Waspadai Mixed Content Setelah Pasang SSL
Banyak website merasa sudah aman setelah memasang SSL, padahal masih punya masalah mixed content. Kondisi ini terjadi ketika halaman utama sudah HTTPS, tetapi sebagian gambar, script, CSS, iframe, atau resource lain masih dipanggil lewat HTTP.
Masalah ini sering muncul pada website lama, WordPress hasil migrasi, atau website yang baru mengaktifkan SSL dari hosting. Dari luar, halaman mungkin tetap terlihat normal. Namun, di baliknya, browser bisa memblokir sebagian resource atau menampilkan peringatan karena halaman aman memuat konten tidak aman.
Mixed content juga bisa mengganggu pengalaman pengguna. Tampilan website bisa rusak karena file CSS tidak termuat, form tidak bekerja, gambar hilang, atau script tertentu diblokir browser. Pada website bisnis, efeknya bisa langsung terasa pada kepercayaan pengunjung dan performa konversi.
Cara mengeceknya bisa dimulai dari browser. Buka halaman website, klik ikon di sebelah URL, lalu lihat apakah ada peringatan bahwa koneksi tidak sepenuhnya aman. Anda juga bisa membuka Developer Tools dan melihat bagian Console untuk menemukan resource yang masih dipanggil lewat http://.
Untuk pemilik website, perbaikannya biasanya mencakup penggantian URL lama di database, pembaruan link internal, pengaturan ulang CDN, dan pengecekan theme atau plugin yang masih memanggil file eksternal lewat HTTP. Jadi, pemasangan SSL sebaiknya diikuti audit kecil, bukan dianggap selesai begitu sertifikat aktif.
Cek Apakah Website Ditandai Berbahaya oleh Google
Setelah koneksi dasar aman, cek apakah website pernah ditandai sebagai situs berbahaya. Google Safe Browsing dapat memberi sinyal apakah sebuah website terdeteksi mengandung konten berbahaya, phishing, malware, atau perilaku mencurigakan.
Bagi pemilik website, Google Search Console lebih penting lagi. Di dalamnya ada laporan Security Issues yang dapat menampilkan masalah jika Google mendeteksi website diretas, menampilkan phishing, malware, atau unwanted software. Ini bukan sekadar isu teknis, karena peringatan dari Google bisa membuat calon pelanggan batal membuka website.
Dampaknya bisa langsung terasa pada bisnis. Website yang ditandai berbahaya dapat memunculkan peringatan di browser atau hasil pencarian. Pengunjung biasanya tidak akan membaca penjelasan teknisnya. Mereka cukup melihat peringatan merah, lalu menutup halaman.
Karena itu, website bisnis sebaiknya terhubung ke Google Search Console. Banyak pemilik website baru membuka Search Console saat traffic turun, padahal laporan keamanan bisa menjadi alarm awal sebelum masalah makin besar.
Jika website terkena peringatan keamanan, jangan hanya menghapus tampilan yang terlihat mencurigakan. Perlu dicek sumber masalahnya, apakah berasal dari plugin, file yang disisipkan, akun admin baru, folder upload, script eksternal, atau akses hosting yang bocor. Jika akar masalah tidak dibersihkan, peringatan bisa muncul lagi.
Gunakan Scanner Online, tetapi Pahami Batasnya
Scanner online seperti SiteCheck dapat membantu mengecek indikasi dari luar, misalnya malware yang terlihat publik, defacement, blacklist, CMS usang, atau konfigurasi yang mencurigakan. Alat seperti ini berguna sebagai pengecekan awal, terutama jika Anda tidak punya akses teknis ke server.
Namun, hasil scanner online tidak boleh dianggap sebagai keputusan final. Jika hasilnya “tidak ditemukan malware”, artinya alat tersebut tidak menemukan masalah dari sisi yang bisa ia akses. Itu tidak berarti website pasti bersih.
Beberapa serangan tidak selalu terlihat di halaman utama. Ada malware yang hanya aktif untuk pengunjung dari negara tertentu, hanya muncul di perangkat mobile, hanya terlihat untuk Googlebot, atau hanya mengarahkan pengunjung dari search engine. Ada juga backdoor yang tidak memunculkan gejala sampai penyerang menggunakannya lagi.
Untuk website WordPress, scanner internal seperti plugin keamanan dapat memeriksa file website, pola malware, backdoor, shell, URL mencurigakan, dan perubahan file inti. Pemeriksaan dari dalam seperti ini lebih kuat untuk menemukan masalah yang tidak terlihat dari luar.
Meski begitu, plugin keamanan juga bukan pengganti audit manual. Jika website sudah dicurigai diretas, pemeriksaan idealnya mencakup file server, database, user admin, log akses, cron job, permission folder, dan konfigurasi hosting. Pada website yang memproses data penting, bantuan developer atau security specialist sering kali lebih aman daripada mencoba membersihkan sendiri.
Periksa WordPress, Plugin, dan Theme dengan Lebih Serius
Banyak website bisnis di Indonesia memakai WordPress karena mudah dikelola dan fleksibel. Risikonya, masalah keamanan WordPress sering kali bukan berasal dari core WordPress saja, tetapi dari plugin dan theme pihak ketiga.
Laporan Patchstack mencatat ribuan kerentanan baru pada ekosistem WordPress pada 2024, dengan mayoritas besar berada di plugin dan sebagian kecil di theme. Ini menunjukkan bahwa saran “update WordPress” saja belum cukup. Plugin yang aktif, plugin yang sudah tidak dipakai, theme lama, dan plugin nulled juga perlu masuk daftar pengecekan.
Untuk pemilik website, cara praktisnya adalah mulai dari inventaris. Lihat plugin apa saja yang terpasang, mana yang benar-benar dipakai, mana yang sudah lama tidak diperbarui, dan apakah developer plugin masih aktif merilis update.
Plugin yang tidak digunakan sebaiknya dihapus, bukan hanya dinonaktifkan. Theme lama yang tidak dipakai juga perlu dibersihkan. Semakin banyak komponen yang tersisa di website, semakin banyak titik risiko yang harus dipantau.
Hindari plugin atau theme nulled. Walaupun terlihat menghemat biaya, file seperti ini bisa membawa script tersembunyi, backdoor, atau kode yang membuka akses ke website. Untuk website bisnis, biaya perbaikan setelah diretas biasanya jauh lebih mahal daripada lisensi resmi atau pengembangan yang lebih rapi.
Cek Tanda Website Diretas yang Sering Tidak Terlihat
Website yang diretas tidak selalu langsung rusak. Banyak kasus justru terlihat normal bagi pemilik, tetapi diam-diam menampilkan halaman spam, redirect, atau konten tersembunyi untuk search engine.
Salah satu tanda yang perlu dicek adalah munculnya URL asing di hasil Google. Gunakan operator site:domainanda.com, lalu lihat apakah ada halaman judi, obat, pinjaman, karakter Jepang, atau judul yang tidak pernah Anda buat. Jika ada, website kemungkinan terkena spam SEO atau injected pages.
Kasus seperti Japanese keyword hack dan injected gibberish URL sering menyerang CMS populer. Penyerang menambahkan halaman otomatis berisi kata kunci spam, link, dan konten yang tidak relevan untuk memanfaatkan reputasi domain Anda di search engine.
Tanda lain yang perlu diperhatikan adalah redirect aneh dari hasil Google, halaman yang hanya bermasalah di mobile, user admin baru yang tidak dikenal, file PHP mencurigakan di folder upload, perubahan .htaccess, atau lonjakan halaman terindeks tanpa alasan jelas.
Untuk bisnis, masalah seperti ini bukan sekadar urusan teknis. Jika calon pelanggan menemukan halaman spam di domain Anda, kepercayaan bisa turun. Jika Google menandai website bermasalah, traffic organik dan reputasi brand ikut terdampak.
Audit Login dan Akses Admin
Keamanan website sering jebol dari hal yang terlihat sederhana: password lemah, akun admin lama, akses vendor yang tidak pernah dicabut, atau login tanpa perlindungan tambahan. Karena itu, audit akses admin perlu menjadi bagian dari pengecekan keamanan.
Mulai dari daftar user. Pastikan hanya orang yang masih membutuhkan akses yang punya akun. Jika ada mantan karyawan, vendor lama, freelancer, atau akun tidak jelas, hapus akunnya atau turunkan rolenya.
Gunakan password unik untuk website, hosting, email admin, dan akun terkait lain. Jangan memakai password yang sama untuk banyak akun. Jika satu akun bocor, penyerang bisa mencoba kombinasi yang sama ke WordPress, cPanel, email, atau layanan lain.
Aktifkan 2FA atau MFA jika tersedia. Verifikasi tambahan ini membantu mengurangi risiko jika password diketahui pihak lain. Untuk website bisnis, perlindungan login seperti ini sebaiknya dianggap standar, bukan fitur tambahan yang hanya dipakai perusahaan besar.
Anda juga bisa membatasi percobaan login, mengganti URL login bila relevan, memantau login mencurigakan, dan memastikan role user sesuai kebutuhan. Tidak semua orang perlu menjadi administrator. Editor, penulis, atau staf marketing sebaiknya hanya punya akses sesuai pekerjaannya.
Cek Security Headers dan Konfigurasi Browser
Security headers adalah pengaturan yang dikirim server ke browser untuk membantu mengurangi risiko tertentu. Pengaturan ini bukan pengganti perbaikan kode, tetapi bisa menjadi lapisan perlindungan tambahan.
Contohnya, HSTS membantu memastikan browser memakai HTTPS. Content Security Policy atau CSP dapat membatasi sumber script dan resource yang boleh dimuat, sehingga membantu mengurangi dampak serangan seperti XSS. X-Frame-Options atau frame-ancestors dapat membantu mengurangi risiko clickjacking.
Ada juga X-Content-Type-Options, Referrer-Policy, dan Permissions-Policy. Masing-masing punya fungsi berbeda, seperti membatasi MIME sniffing, mengontrol informasi referrer, atau membatasi akses fitur browser tertentu.
Untuk mengeceknya, alat seperti Mozilla HTTP Observatory bisa memberi gambaran konfigurasi HTTP security headers. Namun, skor bukan tujuan utama. Yang lebih penting adalah memahami rekomendasi mana yang relevan dengan website Anda.
Beberapa header perlu diterapkan dengan hati-hati. CSP yang terlalu ketat, misalnya, bisa membuat script, form, chat widget, analytics, atau fitur pihak ketiga tidak berjalan. Jadi, konfigurasi keamanan harus diuji, bukan langsung disalin tanpa memahami dampaknya.
Perhatikan Data Pengunjung dan Tanggung Jawab Bisnis
Untuk website bisnis, keamanan tidak berhenti pada tampilan depan. Jika website mengumpulkan nama, email, nomor HP, alamat, pesan konsultasi, data order, atau dokumen pelanggan, Anda juga perlu memikirkan bagaimana data itu disimpan dan siapa yang bisa mengaksesnya.
Di Indonesia, UU No. 27 Tahun 2022 tentang Pelindungan Data Pribadi mengatur berbagai hal terkait data pribadi, termasuk kewajiban pihak yang memproses data. Artikel teknis seperti ini tidak perlu berubah menjadi nasihat hukum, tetapi pemilik website tetap perlu sadar bahwa keamanan website berkaitan dengan kepercayaan dan tanggung jawab data.
Cek formulir kontak, plugin form, CRM, email notifikasi, dashboard admin, dan backup. Pastikan data tidak dikirim ke pihak yang tidak perlu, tidak tersimpan di tempat yang mudah diakses publik, dan tidak bisa dibaca oleh user yang tidak punya wewenang.
Jika website memakai banyak integrasi, seperti live chat, analytics, pixel iklan, form pihak ketiga, atau plugin marketing, periksa lagi akses dan pengaturannya. Semakin banyak layanan terhubung, semakin penting dokumentasi dan kontrol akses.
Untuk website yang menangani transaksi, membership, portal pelanggan, atau data sensitif lain, pengecekan mandiri biasanya tidak cukup. Anda perlu pendekatan yang lebih formal, seperti audit teknis, vulnerability assessment, atau penetration testing sesuai tingkat risiko website.
Kapan Cukup Cek Sendiri dan Kapan Perlu Bantuan Teknis?
Untuk website profil bisnis sederhana, pengecekan mandiri masih masuk akal sebagai langkah awal. Anda bisa mengecek HTTPS, mixed content, Safe Browsing, Search Console, plugin, user admin, dan backup secara rutin.
Namun, jika website sudah menunjukkan gejala diretas, jangan hanya mengandalkan checklist permukaan. Gejala seperti redirect aneh, halaman spam di Google, file mencurigakan, peringatan browser, user admin asing, atau website yang sering kembali terinfeksi membutuhkan pemeriksaan lebih dalam.
Bantuan teknis juga lebih layak jika website menyimpan data pelanggan, menerima pembayaran, punya area login, atau menjadi sumber leads utama. Dalam kondisi seperti ini, downtime dan hilangnya kepercayaan bisa lebih mahal daripada biaya audit atau perbaikan.
Sebagai patokan, pengecekan sendiri cocok untuk screening dan perawatan rutin. Bantuan developer atau security specialist lebih tepat untuk investigasi, pembersihan malware, hardening server, audit plugin, perbaikan konfigurasi, dan validasi setelah website pernah diretas.
Untuk bisnis yang sedang membangun atau merombak website, keamanan sebaiknya dibahas sejak awal. Struktur hosting, pemilihan plugin, role user, backup, form, dan integrasi marketing lebih mudah dirapikan sejak proses pembuatan website daripada diperbaiki setelah masalah muncul.
Checklist Praktis untuk Cek Keamanan Website
Agar tidak tercecer, Anda bisa memakai urutan pengecekan berikut:
| Area yang Dicek | Yang Perlu Diperhatikan |
|---|---|
| HTTPS dan SSL | Sertifikat aktif, redirect HTTP ke HTTPS, tidak ada halaman penting yang masih HTTP |
| Mixed content | Gambar, script, CSS, iframe, dan resource eksternal tidak dipanggil lewat HTTP |
| Reputasi domain | Tidak ditandai berbahaya oleh Google Safe Browsing atau Search Console |
| WordPress/CMS | Core, plugin, dan theme diperbarui; plugin tidak dipakai dihapus |
| User admin | Tidak ada user asing, akses vendor lama dicabut, role sesuai kebutuhan |
| Login | Password unik, 2FA/MFA aktif, percobaan login dibatasi |
| Indeks Google | Tidak ada halaman spam, URL asing, atau judul mencurigakan di hasil site: |
| File dan server | Tidak ada file PHP asing, backdoor, perubahan .htaccess, atau permission longgar |
| Backup | Backup berjalan rutin dan pernah diuji restore |
| Data pengguna | Form, CRM, email, dan akses data pelanggan dikontrol dengan jelas |
Checklist ini bukan jaminan website pasti aman. Namun, urutan ini membantu Anda melihat keamanan website sebagai sistem, bukan sekadar hasil dari satu tool.
Jika ada satu area yang belum bisa Anda cek sendiri, catat sebagai risiko. Misalnya, Anda bisa mengecek SSL dan Search Console, tetapi belum bisa memeriksa file server. Dari situ, Anda tahu bagian mana yang perlu dibantu developer.
Kesimpulan
Cara cek keamanan website yang benar dimulai dari hal dasar seperti HTTPS, lalu dilanjutkan ke bagian yang sering luput: mixed content, plugin rentan, user admin mencurigakan, halaman spam tersembunyi, atau malware yang hanya aktif pada kondisi tertentu.
Untuk website bisnis, tujuan pengecekan bukan sekadar mendapat skor “aman”. Yang lebih penting adalah memastikan pengunjung bisa percaya, data pelanggan tidak diperlakukan sembarangan, dan website tidak menjadi sumber risiko bagi reputasi brand.
Gunakan scanner online sebagai langkah awal, Search Console sebagai alarm penting, audit CMS untuk mengecek risiko dari dalam, dan bantuan teknis jika website sudah menyimpan data penting atau menunjukkan tanda-tanda diretas. Keamanan website bukan pekerjaan sekali selesai. Ia perlu dirawat mengikuti perubahan website, plugin, server, dan cara pelanggan berinteraksi dengan bisnis Anda.
Referensi
- Google Security Blog: HTTPS by Default
- SSL Labs SSL Server Test
- MDN Web Docs: Mixed Content
- Google Transparency Report: Safe Browsing
- Google Search Console Help: Security Issues Report
- Patchstack: State of WordPress Security in 2025
- MDN Web Docs: Content Security Policy
- BPK RI: UU No. 27 Tahun 2022 tentang Pelindungan Data Pribadi

