Mengatasi Error Mixed Content dan HTTPS di WordPress: Cara Memperbaiki Gembok Tidak Aman Tanpa Merusak Iklan

Situs Anda sudah memakai HTTPS, sertifikat SSL sudah terpasang, tetapi gembok di bilah alamat browser tetap tidak muncul — atau muncul sebentar lalu berubah menjadi peringatan “Tidak sepenuhnya aman”. Gambar kadang hilang, menu kadang tidak berfungsi, dan iklan sesekali tidak tampil. Kondisi ini hampir selalu disebabkan oleh mixed content: halaman dimuat lewat HTTPS, tetapi sebagian isinya — gambar, skrip, stylesheet, font, atau iframe — masih diminta lewat HTTP yang tidak terenkripsi. Browser modern menangani masalah ini dengan tegas: skrip dan stylesheet yang tidak aman diblokir, sementara gambar yang tidak aman dimuat dengan peringatan. Akibatnya bukan hanya tampilan yang rusak; kepercayaan pembaca menurun, formulir bisa gagal, dan sebagian fitur situs berhenti bekerja tanpa pesan kesalahan yang jelas.

Artikel ini menjelaskan mixed content dari nol sampai tuntas untuk publisher WordPress: apa bedanya mixed content aktif dan pasif, cara menemukan URL HTTP yang masih tersisa dengan alat bawaan browser, urutan perbaikan yang aman — mulai dari pengaturan alamat situs, migrasi satu klik WordPress 5.7, sampai search and replace di database yang tidak merusak data serial — serta cara memastikan iklan AdSense tetap tampil dan cara mencegah masalah yang sama muncul lagi. Semua langkah disusun agar bisa diikuti pemilik situs tanpa latar belakang pemrograman, dengan peringatan yang jelas pada setiap langkah yang berisiko.

Poin Kunci

• Mixed content terjadi ketika halaman HTTPS memuat sebagian sumber daya lewat HTTP; skrip dan stylesheet yang tidak aman diblokir browser, sedangkan gambar dan video biasanya hanya memicu peringatan.
• Penyebab paling umum adalah alamat situs yang masih HTTP, tautan gambar lama di artikel yang ditulis sebelum migrasi HTTPS, serta URL yang tersimpan di pengaturan tema, widget, dan page builder.
• Perbaikan yang benar dimulai dari sertifikat dan kedua alamat situs di Pengaturan > Umum, lalu menemukan URL HTTP yang tersisa lewat tab Console di developer tools browser, dan baru kemudian memperbarui URL yang tersimpan di database.
• Sejak WordPress 5.7, Site Health menyediakan tombol migrasi HTTPS satu klik yang memperbarui alamat situs dan menulis ulang URL lama secara otomatis pada tampilan — tetapi tidak mengubah database dan tidak menjangkau data page builder atau post meta.
• Jangan pernah melakukan find and replace mentah di database: data WordPress yang terserialisasi bisa rusak. Gunakan alat search and replace yang memahami format serial, jalankan dry run dulu, dan selalu buat cadangan penuh sebelum mengubah apa pun.
• HTTPS adalah sinyal ranking Google yang ringan — diumumkan 6 Agustus 2014 dan digambarkan sebagai sinyal yang sangat ringan — sehingga memperbaiki mixed content lebih berdampak pada kepercayaan pembaca dan berfungsinya situs daripada pada lonjakan peringkat.
• Setelah perbaikan, verifikasi dengan membersihkan cache plugin dan CDN, memeriksa ulang console browser, lalu memastikan Search Console hanya mengindeks versi HTTPS.

Daftar Isi

1. Apa Itu Mixed Content dan Mengapa Gembok Browser Hilang
2. Mixed Content Aktif vs Pasif: Mana yang Diblokir dan Mana yang Hanya Diperingatkan
3. Dampak Mixed Content bagi Publisher: Kepercayaan, Fungsi Situs, dan Iklan
4. HTTPS Menurut Google: Sinyal Ringan, Bukan Jalan Pintas Peringkat
5. Persiapan Wajib Sebelum Memperbaiki Apa Pun: Cadangan dan Staging
6. Langkah 1: Pastikan Sertifikat SSL Benar-Benar Valid
7. Langkah 2: Ubah Alamat WordPress dan Alamat Situs ke HTTPS
8. Langkah 3: Gunakan Migrasi Satu Klik WordPress 5.7 di Site Health
9. Langkah 4: Temukan Semua URL HTTP yang Tersisa dengan Developer Tools
10. Langkah 5: Perbarui URL Lama di Database dengan Cara yang Aman
11. Langkah 6: Perbaiki Mixed Content dari Tema, Widget, dan Page Builder
12. Langkah 7: Atasi Embed dan Layanan Pihak Ketiga yang Masih HTTP
13. Langkah 8: Paksa Redirect HTTP ke HTTPS dalam Satu Lompatan
14. Langkah 9: Lindungi Situs dengan HSTS Setelah Semuanya Stabil
15. Kapan Plugin Pembantu Diperlukan dan Kapan Justru Dihindari
16. Checklist Verifikasi Akhir: Dari Console Browser sampai Search Console
17. Kesalahan Umum yang Membuat Mixed Content Kembali Lagi
18. FAQ
19. Kesimpulan
20. Sumber resmi yang dirujuk

Apa Itu Mixed Content dan Mengapa Gembok Browser Hilang

Mixed content adalah kondisi ketika sebuah halaman web dimuat melalui koneksi HTTPS yang aman, tetapi sebagian sumber daya di dalam halaman itu diminta melalui HTTP yang tidak terenkripsi. MDN Web Docs mendefinisikan mixed content sebagai halaman yang dimuat secara aman tetapi menggunakan sumber daya yang diambil lewat HTTP atau protokol tidak aman lainnya. Gembok di bilah alamat browser menandakan bahwa koneksi antara browser dan server terenkripsi; ketika ada satu saja sumber daya yang diambil tanpa enkripsi, jaminan itu menjadi tidak utuh, dan browser menunjukkannya dengan menghilangkan gembok atau menampilkan peringatan.

Untuk memahami mengapa masalah ini begitu umum di WordPress, perlu dipahami cara WordPress menyimpan alamat. Ketika Anda menyisipkan gambar ke dalam artikel, WordPress menyimpan URL lengkap gambar itu di dalam konten artikel — misalnya http://situsanda.com/wp-content/uploads/2025/01/gambar.jpg. URL itu ditulis pada saat artikel dibuat. Jika situs Anda bermigrasi dari HTTP ke HTTPS setahun kemudian, URL yang sudah tersimpan di ratusan artikel lama tidak berubah dengan sendirinya. Halaman baru yang Anda tulis setelah migrasi akan memakai HTTPS, tetapi artikel lama tetap memanggil gambar lamanya lewat HTTP. Inilah sumber mixed content yang paling sering ditemui publisher: bukan kesalahan hari ini, melainkan jejak dari masa sebelum HTTPS.

Sumber lain yang juga umum adalah pengaturan tema dan widget. Banyak tema menyimpan URL logo, gambar latar, atau tautan media sosial sebagai URL lengkap. Widget teks dan blok HTML kustom juga sering berisi tautan yang ditulis manual dengan http://. Page builder menyimpan datanya sendiri di post meta, terpisah dari konten artikel, sehingga URL lama di sana tidak ikut berubah ketika konten artikel diperbaiki. Layanan pihak ketiga — misalnya embed video lama, font dari server eksternal, atau skrip pelacak — juga bisa menjadi sumbernya apabila layanan tersebut masih dipanggil lewat HTTP.

Penting untuk dipahami bahwa mixed content bukan berarti sertifikat SSL Anda rusak. Sertifikat bisa sepenuhnya valid dan situs tetap menampilkan peringatan, karena masalahnya bukan pada sertifikat, melainkan pada isi halaman. Sebaliknya, situs tanpa sertifikat sama sekali tidak akan mengalami mixed content — ia hanya akan ditandai “Tidak aman” secara keseluruhan. Karena itu, ketika gembok hilang setelah SSL terpasang, langkah pertama yang benar adalah mencari isi halaman yang masih HTTP, bukan membeli sertifikat baru.

Tanda-tanda situs Anda mengalami mixed content

Gejala yang paling mudah dikenali adalah gembok yang hilang atau berubah menjadi segitiga peringatan di bilah alamat. Di Chrome, halaman yang memuat mixed content pasif biasanya menampilkan gembok dengan tanda peringatan, sedangkan halaman dengan mixed content aktif yang diblokir bisa menampilkan ikon “Tidak aman” atau pesan bahwa sebagian konten diblokir. Gejala lain yang sering luput dari perhatian adalah gambar yang tidak muncul di artikel lama, slider yang tidak bergerak, menu dropdown yang tidak terbuka, atau formulir kontak yang tidak bisa dikirim. Semua itu bisa terjadi karena skrip atau stylesheet yang dibutuhkan halaman diblokir oleh browser.

Gejala yang paling merugikan publisher sering kali tidak terlihat oleh pemilik situs sendiri. Iklan bisa gagal tampil apabila skrip iklan atau sumber daya pendukungnya terblokir, dan karena pemilik situs biasanya menguji dari perangkatnya sendiri dengan cache yang sudah tersimpan, masalah ini baru ketahuan setelah pembaca mengeluh atau pendapatan menurun. Karena itu, pemeriksaan mixed content sebaiknya dilakukan secara berkala dan dari jendela penyamaran browser, bukan hanya dari sesi yang sudah lama tersimpan.

Mixed Content Aktif vs Pasif: Mana yang Diblokir dan Mana yang Hanya Diperingatkan

Browser tidak memperlakukan semua mixed content dengan cara yang sama. MDN membedakan dua jenis: mixed content aktif dan mixed content pasif. Perbedaan ini penting karena menentukan seberapa parah kerusakan yang ditimbulkan dan urutan mana yang harus diperbaiki lebih dulu.

Mixed content aktif adalah sumber daya yang dapat mengubah perilaku halaman: skrip JavaScript, stylesheet CSS, iframe, font, dan permintaan pengambilan data seperti XMLHttpRequest atau fetch. Browser memblokir jenis ini secara langsung, karena skrip yang dimuat tanpa enkripsi dapat dimodifikasi oleh pihak ketiga di tengah jalan dan mengubah isi halaman — termasuk mencuri data formulir atau menampilkan konten palsu. Ketika stylesheet diblokir, halaman kehilangan tampilannya dan terlihat seperti teks polos. Ketika skrip diblokir, menu, slider, pemutar video, dan formulir bisa berhenti berfungsi. Inilah jenis mixed content yang paling merusak dan harus diperbaiki pertama.

Mixed content pasif adalah sumber daya yang hanya ditampilkan, bukan dieksekusi: gambar, video, dan audio. Browser umumnya tetap memuatnya, tetapi menurunkan status keamanan halaman dan menampilkan peringatan. Gambar yang dimuat lewat HTTP bisa saja dimodifikasi di tengah jalan — misalnya diganti dengan gambar lain — tetapi tidak bisa mengubah perilaku halaman. Karena itu browser bersikap lebih lunak, meski tetap memberi peringatan. Dalam praktiknya, gambar adalah sumber mixed content yang paling banyak jumlahnya, karena setiap artikel lama bisa menyimpan puluhan URL gambar HTTP.

Perlu dicatat bahwa perilaku browser terus berkembang: browser modern semakin sering meningkatkan otomatis permintaan HTTP menjadi HTTPS bila server tujuan mendukungnya. Namun peningkatan otomatis ini tidak bisa diandalkan — apabila sumber daya tersebut memang tidak tersedia lewat HTTPS, permintaan akan gagal dan sumber daya tetap tidak tampil. Jangan mengandalkan perilaku browser sebagai perbaikan; perbaiki URL yang tersimpan di situs Anda sendiri.

Dampak Mixed Content bagi Publisher: Kepercayaan, Fungsi Situs, dan Iklan

Dampak pertama dan paling langsung adalah kepercayaan pembaca. Gembok dan label “aman” di bilah alamat telah menjadi tanda yang dikenali pembaca awam sekalipun. Ketika label itu berubah menjadi peringatan, sebagian pembaca akan ragu melanjutkan — terutama pada halaman yang meminta mereka mengisi formulir, berlangganan buletin, atau mengklik tautan afiliasi. Bagi situs berita dan media kecil seperti Bang Eko Media, kepercayaan adalah modal utama; peringatan keamanan yang muncul di setiap artikel lama perlahan-lahan menggerus kredibilitas yang dibangun lewat konten.

Dampak kedua adalah rusaknya fungsi situs. Skrip yang diblokir dapat menghentikan menu navigasi, galeri gambar, pemutar audio, dan tombol berbagi. Stylesheet yang diblokir membuat halaman tampil tanpa gaya, sehingga pembaca melihat susunan teks yang berantakan. Masalah ini sering kali hanya terjadi pada artikel lama tertentu, sehingga pemilik situs yang hanya memeriksa halaman depan tidak pernah menyadarinya. Pembaca yang membuka artikel lama dari hasil pencarian Google justru menjadi pihak yang paling sering menemui halaman rusak.

Dampak ketiga berkaitan dengan iklan, dan ini yang paling sensitif bagi publisher AdSense. Tag iklan AdSense sendiri dimuat lewat HTTPS, tetapi unit iklan bergantung pada skrip dan stylesheet lain — dari tema, plugin, maupun layanan pendukung — yang apabila terblokir dapat mengganggu tata letak atau proses pemuatan iklan. Selain itu, halaman yang menampilkan peringatan keamanan cenderung membuat pembaca menutup halaman lebih cepat, sehingga peluang iklan dilihat dan diklik menurun. Perlu ditegaskan: memperbaiki mixed content bukan jaminan pendapatan naik, dan artikel ini tidak menjanjikan hal itu. Yang benar adalah sebaliknya — mixed content yang dibiarkan adalah hambatan yang tidak perlu bagi pendapatan yang seharusnya sudah Anda peroleh dari konten yang sama.

Dampak keempat adalah fitur browser modern yang tidak berfungsi. Banyak fitur web modern mensyaratkan konteks aman (secure context), dan halaman dengan mixed content dapat kehilangan akses ke sebagian fitur tersebut. Dokumentasi Google Search Central tentang HTTPS juga mencatat bahwa HTTPS dibutuhkan untuk banyak fitur browser modern. Bagi publisher, ini berarti embed interaktif, notifikasi, atau fitur berbagi tertentu bisa gagal diam-diam pada halaman yang bermasalah.

HTTPS Menurut Google: Sinyal Ringan, Bukan Jalan Pintas Peringkat

Salah satu kesalahpahaman yang paling sering beredar adalah anggapan bahwa memasang SSL akan mendongkrak peringkat secara signifikan. Fakta resminya lebih sederhana. Google mengumumkan pada 6 Agustus 2014 melalui blog Search Central bahwa mereka mulai menggunakan koneksi aman sebagai sinyal ranking. Dalam pengumuman yang sama, Google menggambarkannya sebagai sinyal yang sangat ringan — memengaruhi kurang dari satu persen kueri global dan berbobot lebih kecil daripada sinyal lain seperti kualitas konten. Dokumentasi Google Search Central tentang HTTPS menegaskan kembali bahwa HTTPS adalah sinyal ranking yang ringan dan berfungsi sebagai pemutus seri: ketika dua halaman dinilai sama, halaman yang aman dapat menang.

Artinya, HTTPS menghilangkan kerugian kecil, bukan menciptakan keunggulan besar. Pada 2026, hampir semua pesaing Anda sudah memakai HTTPS, sehingga sinyal ini tidak lagi membedakan Anda dari mereka. Yang membedakan adalah konten yang membantu, struktur yang jelas, dan pengalaman pembaca yang baik — dan mixed content merusak ketiganya secara tidak langsung: pembaca pergi lebih cepat, halaman berfungsi setengah-setengah, dan kepercayaan menurun.

Ada satu hal penting lain dari dokumentasi Google: Googlebot merayapi dan mengindeks URL HTTPS secara normal, dan HTTPS bukan syarat mutlak untuk diindeks. Google tidak pernah mengumumkan tenggat yang menghapus halaman HTTP dari indeks. Jadi jangan panik apabila sebagian URL HTTP lama masih terindeks; yang perlu dilakukan adalah memastikan setiap URL HTTP mengarahkan (redirect) dengan benar ke padanan HTTPS-nya dan versi HTTPS-lah yang ditetapkan sebagai kanonis. Bagian redirect di artikel ini menjelaskan caranya.

Apa yang sebenarnya Google nilai dari sisi keamanan

Google menilai keamanan sebagai bagian dari pengalaman halaman, bukan sebagai pengganti kualitas konten. Halaman yang aman tetapi tipis tidak akan mengalahkan halaman yang membantu hanya karena memakai HTTPS. Sebaliknya, halaman yang bagus tetapi memuat peringatan keamanan akan kehilangan pembaca sebelum pembaca sempat menilai isinya. Jadi cara yang tepat untuk memandang pekerjaan ini adalah: memperbaiki mixed content adalah pekerjaan kebersihan teknis yang melindungi nilai konten Anda, bukan trik SEO. Kerjakan dengan benar, verifikasi hasilnya, lalu kembali fokus menulis artikel yang membantu pembaca.

Persiapan Wajib Sebelum Memperbaiki Apa Pun: Cadangan dan Staging

Setiap langkah perbaikan dalam artikel ini menyentuh pengaturan situs atau database. Karena itu, aturan pertama yang tidak boleh dilewati adalah membuat cadangan penuh — berkas dan database — sebelum mengubah apa pun. Cadangan adalah satu-satunya jalan kembali apabila sebuah langkah menimbulkan masalah. Banyak publisher menunda perbaikan mixed content selama berbulan-bulan justru karena takut merusak situs; cadangan yang baik menghilangkan ketakutan itu karena setiap perubahan menjadi bisa dibatalkan.

Jika hosting Anda menyediakan fitur cadangan otomatis, periksa kapan cadangan terakhir dibuat dan pastikan Anda tahu cara memulihkannya. Jika tidak, gunakan plugin cadangan tepercaya atau fitur cadangan dari panel hosting. Simpan salinan cadangan di luar server situs Anda — misalnya di komputer sendiri atau penyimpanan cloud — agar tetap bisa dipakai apabila server bermasalah. Setelah cadangan dibuat, uji bahwa berkas cadangan benar-benar ada dan ukurannya wajar; cadangan yang tidak pernah diuji sama saja dengan tidak punya cadangan.

Apabila situs Anda menerima traffic yang cukup besar atau menghasilkan pendapatan iklan setiap jam, pertimbangkan untuk melakukan perbaikan besar — terutama search and replace di database — pada jam traffic rendah, dan bila memungkinkan di lingkungan staging terlebih dahulu. Staging adalah salinan situs yang tidak terlihat publik, tempat Anda bisa menguji perubahan tanpa risiko. Banyak host, termasuk Hostinger, menyediakan fitur staging; panduan staging WordPress untuk publisher telah dibahas di artikel lain di situs ini. Untuk perbaikan kecil seperti mengubah alamat situs atau memperbaiki satu gambar, staging tidak wajib. Untuk perubahan database menyeluruh, staging sangat dianjurkan.

Checklist persiapan singkat

• Buat cadangan penuh berkas dan database, lalu pastikan berkas cadangan tersimpan di luar server.
• Catat kondisi awal: buka beberapa artikel lama di jendela penyamaran dan catat halaman mana yang menampilkan peringatan.
• Pastikan Anda masih bisa masuk ke dashboard WordPress dan panel hosting sebelum mengubah pengaturan apa pun.
• Siapkan akses ke pengelola berkas hosting atau FTP, untuk berjaga-jaga apabila Anda perlu mengedit wp-config.php atau .htaccess.
• Jangan melakukan perbaikan sambil situs sedang dalam pemeliharaan plugin atau pembaruan tema; selesaikan satu pekerjaan dalam satu waktu.

Langkah 1: Pastikan Sertifikat SSL Benar-Benar Valid

Sebelum memperbaiki isi halaman, pastikan fondasinya benar: sertifikat SSL harus valid, mencakup nama domain yang dipakai, dan terpasang dengan benar. Buka versi HTTPS dari halaman depan situs Anda dan klik ikon gembok atau ikon keamanan di bilah alamat untuk melihat detail sertifikat. Periksa tiga hal: sertifikat diterbitkan untuk domain Anda (termasuk versi www dan non-www yang Anda pakai), tanggal kedaluarsanya masih jauh, dan tidak ada pesan kesalahan sertifikat.

Apabila browser menampilkan kesalahan sertifikat — misalnya sertifikat kedaluwarsa, nama domain tidak cocok, atau rantai sertifikat tidak lengkap — maka masalah Anda bukan mixed content, melainkan sertifikat itu sendiri. Dalam kondisi ini, perbaiki sertifikat terlebih dahulu melalui hosting Anda. Sebagian besar host modern, termasuk Hostinger, menyediakan sertifikat gratis dari Let’s Encrypt yang diperpanjang otomatis; apabila perpanjangan otomatis gagal, biasanya ada tombol untuk memasang ulang sertifikat di panel hosting.

Periksa juga bahwa sertifikat mencakup www dan non-www. Sertifikat yang hanya mencakup situsanda.com tetapi tidak www.situsanda.com akan menimbulkan kesalahan pada salah satu versi alamat. Kebanyakan sertifikat modern mencakup keduanya, tetapi apabila Anda memasang sertifikat secara manual, hal ini patut diperiksa. Terakhir, tanyakan ke host Anda apakah server sudah mendukung TLS 1.2 dan TLS 1.3. Versi TLS yang lama, yaitu TLS 1.0 dan 1.1, sudah tidak lagi dipakai oleh browser modern — sebagai patokan praktik umum, server Anda sebaiknya hanya menawarkan TLS 1.2 dan 1.3.

Cara cepat memeriksa sertifikat dari luar

Anda tidak harus mengandalkan browser sendiri. Pemeriksa SSL daring seperti SSL Labs dari Qualys dapat memindai konfigurasi server Anda dan melaporkan versi TLS yang didukung, tanggal kedaluwarsa, serta masalah rantai sertifikat. Hasil pemindaian ini berguna sebagai bukti kondisi awal dan sebagai pembanding setelah perbaikan. Simpan tangkapan layar hasil pemindaian sebelum dan sesudah perbaikan; dokumentasi kecil seperti ini sangat membantu apabila masalah muncul kembali di kemudian hari.

Langkah 2: Ubah Alamat WordPress dan Alamat Situs ke HTTPS

WordPress menyimpan dua alamat penting di Pengaturan > Umum: Alamat WordPress (URL) dan Alamat Situs (URL). Keduanya disimpan di tabel options database sebagai siteurl dan home, dan dokumentasi Migrating WordPress di WordPress.org menegaskan bahwa keduanya harus menyertakan bagian https://. Apabila salah satu masih memakai http://, WordPress akan terus menghasilkan tautan internal yang tidak aman, dan mixed content akan terus muncul apa pun yang Anda perbaiki di tempat lain.

Cara mengubahnya sederhana: masuk ke dashboard WordPress, buka Pengaturan > Umum, ubah kedua kolom dari http:// menjadi https://, lalu simpan. Pastikan Anda mengubah keduanya, bukan hanya salah satu. Alamat WordPress adalah tempat berkas WordPress berada, sedangkan Alamat Situs adalah alamat yang dilihat pengunjung; pada sebagian besar instalasi keduanya sama, tetapi pada instalasi di subdirektori keduanya bisa berbeda. Ubah keduanya ke HTTPS dengan nama domain yang sama seperti sebelumnya.

Apabila kolom alamat tidak bisa diubah

Ada dua kondisi yang membuat kolom ini terkunci atau perubahan tidak tersimpan. Pertama, apabila konstanta WP_HOME atau WP_SITEURL didefinisikan di berkas wp-config.php, nilai di berkas tersebut akan mengalahkan pengaturan di dashboard. Dokumentasi WordPress menjelaskan bahwa konstanta ini mengesampingkan nilai database tanpa mengubahnya, sehingga perubahan di Pengaturan > Umum tidak akan berpengaruh. Periksa wp-config.php dan ubah nilai konstanta tersebut ke HTTPS apabila ada. Kedua, apabila kedua alamat memakai domain yang berbeda — misalnya WordPress di satu subdomain dan situs di domain lain — migrasi satu klik WordPress 5.7 tidak mendukung konfigurasi ini, dan Anda perlu menangani perubahan alamat secara manual dengan lebih hati-hati.

Setelah mengubah kedua alamat, keluar dari dashboard lalu masuk kembali, dan buka halaman depan situs Anda. Perhatikan apakah gembok sudah muncul pada halaman depan. Apabila halaman depan sudah aman tetapi artikel lama masih menampilkan peringatan, berarti masalahnya ada pada URL yang tersimpan di konten lama — dan itulah yang ditangani pada langkah-langkah berikutnya.

Langkah 3: Gunakan Migrasi Satu Klik WordPress 5.7 di Site Health

Sejak WordPress 5.7, WordPress menyediakan deteksi HTTPS dan migrasi satu klik melalui layar Site Health. Apabila server Anda sudah mendukung HTTPS tetapi pengaturan situs masih memakai HTTP, Site Health akan menampilkan masalah kritis bertuliskan bahwa situs Anda tidak memakai HTTPS, lengkap dengan tombol untuk memperbarui situs ke HTTPS. Tombol ini memperbarui home dan siteurl di database dan mengaktifkan penulisan ulang URL lama secara otomatis pada tampilan.

Mekanisme di balik tombol ini dijelaskan dalam catatan pengembang Make WordPress Core tentang HTTPS di WordPress 5.7. WordPress memperkenalkan fungsi wp_replace_insecure_home_url() yang menulis ulang URL HTTP lama menjadi HTTPS pada saat konten ditampilkan — mencakup konten artikel, kutipan, teks widget, dan CSS kustom. Penulisan ulang ini hanya aktif bila beberapa syarat terpenuhi: situs memakai HTTPS, alamat situs dan alamat WordPress memakai domain yang sama, dan sebuah penanda internal bernama https_migration_required telah diaktifkan ketika alamat diubah pada situs yang sudah memiliki konten.

Batas penting migrasi satu klik yang wajib dipahami

Migrasi satu klik adalah bantuan besar, tetapi bukan perbaikan menyeluruh. Catatan pengembang yang sama menegaskan batas-batasnya: penulisan ulang hanya terjadi pada saat tampilan, database tidak diubah, dan data yang tersimpan di tempat lain — seperti data page builder, pengaturan plugin, dan post meta — tidak tercakup. Artinya, URL lama tetap ada di database Anda; WordPress hanya menutupinya saat menampilkan halaman. Apabila suatu hari Anda mematikan mekanisme ini atau memindahkan situs, URL lama itu bisa muncul kembali.

Karena itu, perlakukan migrasi satu klik sebagai langkah awal yang baik, bukan sebagai garis akhir. Setelah menggunakannya, tetap lanjutkan ke langkah pencarian dan perbaikan URL tersimpan di bawah ini. Apabila Anda nantinya memutuskan untuk benar-benar mengganti URL di database, dokumentasi menyarankan untuk menghapus opsi https_migration_required agar logika penulisan ulang tidak berjalan tanpa perlu. Untuk sebagian besar publisher, urutan yang aman adalah: gunakan migrasi satu klik, verifikasi hasilnya, lalu perbaiki database secara permanen dengan alat yang tepat.

Langkah 4: Temukan Semua URL HTTP yang Tersisa dengan Developer Tools

Setelah alamat situs diperbaiki, langkah berikutnya adalah menemukan URL HTTP yang masih tersisa — satu per satu, dengan nama berkas yang tepat. Alat terbaik untuk ini sudah ada di browser Anda: developer tools. Di Chrome atau Firefox, buka halaman yang bermasalah, tekan F12 atau klik kanan lalu pilih Inspect, kemudian buka tab Console. Peringatan mixed content akan tercantum di sana dengan URL tidak aman yang terlibat, misalnya: “Mixed Content: The page at ‘https://situsanda.com/…’ was loaded over HTTPS, but requested an insecure image ‘http://situsanda.com/wp-content/uploads/logo.png’.”

Catat setiap URL yang muncul. Tab Network juga membantu: muat ulang halaman dengan panel Network terbuka, lalu saring atau cari permintaan yang memakai http://. Cara ini menunjukkan sumber daya apa saja yang masih diminta lewat HTTP, termasuk yang tidak muncul di Console. Periksa halaman-halaman terpenting Anda terlebih dahulu: halaman depan, artikel dengan traffic tertinggi, halaman kontak, dan halaman yang memuat formulir. Artikel lama yang ditulis sebelum migrasi HTTPS adalah prioritas, karena di sanalah URL gambar lama paling banyak tersimpan.

Pemeriksa daring untuk pemindaian seluruh situs

Memeriksa halaman satu per satu memang teliti, tetapi memakan waktu bila situs Anda memiliki ratusan artikel. Pemeriksa daring seperti Why No Padlock dapat memindai satu halaman dan melaporkan semua sumber daya yang tidak aman di halaman itu. Untuk pemindaian seluruh situs, sebagian alat audit SEO dan keamanan menyediakan laporan mixed content per halaman. Gunakan pemindai daring sebagai pelengkap, bukan pengganti: hasil pemindaian memberi Anda daftar, tetapi verifikasi akhir tetap harus dilakukan di browser Anda sendiri, karena hanya di sanalah Anda melihat apa yang benar-benar dialami pembaca.

Satu kebiasaan yang perlu dibangun adalah memeriksa dari jendela penyamaran (incognito). Jendela biasa menyimpan cache lama, sehingga halaman bisa tampak sudah benar padahal yang ditampilkan adalah versi lama yang tersimpan. Jendela penyamaran memaksa browser mengambil halaman segar dari server, sehingga hasil pemeriksaan lebih dapat dipercaya.

Langkah 5: Perbarui URL Lama di Database dengan Cara yang Aman

Inilah langkah yang paling sering menimbulkan kerusakan apabila dilakukan dengan cara yang salah — dan juga langkah yang paling menyelesaikan masalah secara permanen. Sebagian besar URL HTTP lama tersimpan di database WordPress: di konten artikel, di pengaturan tema, di widget, dan di post meta. Mengubahnya satu per satu lewat editor artikel bisa memakan waktu berhari-hari bila situs Anda sudah memiliki ratusan artikel. Solusinya adalah search and replace di database — tetapi dengan alat yang benar.

Mengapa find and replace mentah berbahaya

WordPress.org memperingatkan bahwa pencarian dan penggantian mentah di seluruh database dapat merusak data serial (serialized data). Sebagian tema dan widget menyimpan nilai beserta panjang karakter URL yang tercatat di dalamnya; apabila Anda mengganti http:// menjadi https://, panjang URL bertambah satu karakter, tetapi angka panjang yang tercatat tidak ikut berubah — dan data tersebut menjadi rusak. Akibatnya bisa berupa pengaturan tema yang hilang, widget yang kosong, atau halaman yang error. Dokumentasi Migrating WordPress di WordPress.org juga menegaskan satu larangan yang tidak boleh dilanggar: jangan pernah mengubah kolom GUID.

Cara aman: plugin search and replace yang memahami serial

Gunakan plugin search and replace yang menangani data serial dengan benar, misalnya Better Search Replace. Alur kerjanya: cari http://situsanda.com dan ganti dengan https://situsanda.com, pilih semua tabel, dan — ini yang terpenting — jalankan dry run terlebih dahulu untuk melihat pratinjau berapa banyak perubahan yang akan dibuat dan di tabel mana saja. Dry run tidak mengubah apa pun; ia hanya menunjukkan apa yang akan terjadi. Periksa hasilnya: apabila jumlah perubahan tampak wajar dan tabel yang terkena adalah tabel yang Anda harapkan, barulah jalankan penggantian yang sebenarnya.

Perlu diperhatikan satu hal: ganti hanya domain Anda sendiri pada langkah ini. URL pihak ketiga yang masih HTTP — misalnya gambar dari server lain — tidak akan teratasi dengan mengganti domain Anda, dan menanganinya memerlukan langkah terpisah di bagian embed dan layanan pihak ketiga. Selain itu, lakukan penggantian dalam satu sesi yang tenang, tanpa menjalankan pembaruan plugin atau tema secara bersamaan, agar apabila terjadi masalah, penyebabnya mudah dilacak.

Setelah search and replace: bersihkan semua cache

Setelah database diperbarui, bersihkan cache di semua lapisan: cache plugin WordPress Anda, cache server bila ada, dan cache CDN seperti Cloudflare. Cache yang tidak dibersihkan akan terus menyajikan versi halaman lama yang masih berisi URL HTTP, sehingga Anda mengira perbaikan gagal padahal database sudah benar. Setelah membersihkan cache, buka kembali halaman yang tadi bermasalah di jendela penyamaran dan periksa tab Console. Apabila peringatan sudah hilang, langkah ini berhasil.

Langkah 6: Perbaiki Mixed Content dari Tema, Widget, dan Page Builder

Tidak semua URL HTTP tersimpan di konten artikel. Tiga tempat lain yang sering menjadi sumber adalah tema, widget, dan page builder — dan ketiganya memerlukan penanganan yang berbeda.

Tema menyimpan URL di pengaturannya: logo, favicon, gambar latar header, dan tautan media sosial sering disimpan sebagai URL lengkap di tabel options. Buka Pengaturan tema (Customizer atau panel pengaturan tema Anda) dan periksa setiap kolom yang berisi URL. Apabila ada yang masih http://, ubah ke https:// secara manual. Sebagian tema juga menyimpan URL di berkas template-nya; apabila Anda menemukan URL HTTP yang ditulis langsung di dalam berkas tema, ubah lewat editor tema atau pengelola berkas hosting — dan catat perubahan Anda, karena pembaruan tema dapat menimpa perubahan pada berkas tema. Untuk perubahan berkas tema yang permanen, gunakan child theme.

Widget teks dan blok HTML kustom adalah sumber yang sering terlupakan. Widget ini menyimpan konten apa adanya, termasuk tautan gambar yang ditulis manual bertahun-tahun lalu. Buka Tampilan > Widget dan periksa setiap widget teks, widget HTML kustom, dan blok di area footer serta sidebar. Perbarui URL HTTP yang Anda temukan ke HTTPS. Jangan lupa memeriksa widget di semua area widget yang aktif, bukan hanya sidebar utama.

Page builder seperti Elementor menyimpan datanya sendiri di post meta dalam format yang tidak ikut berubah ketika Anda memperbaiki konten artikel biasa. Karena itu, setelah search and replace database, buka beberapa halaman yang dibuat dengan page builder dan periksa kembali console-nya. Sebagian page builder menyediakan fitur “Regenerate CSS” atau “Replace URL” di pengaturannya; gunakan fitur tersebut untuk menulis ulang URL di data page builder. Sebagai patokan praktik, setelah mengganti URL di data page builder, selalu bersihkan cache page builder dan muat ulang halaman untuk memastikan perubahan diterapkan.

Langkah 7: Atasi Embed dan Layanan Pihak Ketiga yang Masih HTTP

Setelah URL milik sendiri beres, sisa mixed content biasanya berasal dari luar: embed video lama, font dari server eksternal, skrip pelacak, atau gambar yang di-hotlink dari situs lain. Prinsip penanganannya sederhana: apabila layanan tersebut tersedia lewat HTTPS, ubah URL panggilannya ke HTTPS; apabila tidak tersedia, ganti atau hapus sumbernya.

Mulailah dengan embed video dan media lama. Embed YouTube atau Vimeo lama kadang masih memakai http:// di kode embed-nya. Buka artikel yang bersangkutan, perbarui kode embed ke versi HTTPS, atau lebih mudah: hapus kode embed lama dan tempel ulang URL video — editor blok WordPress akan membuat embed baru yang memakai HTTPS secara otomatis. Untuk gambar yang di-hotlink dari situs lain, unduh gambar tersebut dan unggah ke media library Anda sendiri. Selain menghilangkan mixed content, cara ini juga melindungi Anda dari gambar yang hilang apabila situs asal menghapusnya.

Font eksternal dan skrip pelacak memerlukan perhatian khusus. Periksa dari mana font Anda dimuat: apabila tema Anda memuat Google Fonts lewat HTTP, perbarui URL-nya ke HTTPS atau biarkan WordPress memuatnya dengan URL relatif protokol. Skrip pelacak, iklan, dan layanan analitik lama yang masih dipanggil lewat HTTP harus diperbarui ke versi HTTPS-nya — hampir semua layanan besar sudah mendukung HTTPS sejak lama, sehingga yang diperlukan biasanya hanya mengubah http:// menjadi https:// di kode yang ditempel. Apabila sebuah layanan ternyata tidak mendukung HTTPS sama sekali, itu adalah tanda layanan tersebut sudah tidak terawat; cari penggantinya.

Satu catatan khusus untuk publisher iklan

Periksa juga kode iklan dan skrip monetisasi yang Anda tempel manual di tema atau widget — misalnya kode dari jaringan iklan selain AdSense, skrip afiliasi, atau tag pengelola iklan. Kode-kode ini sering ditempel sekali lalu dilupakan bertahun-tahun. Apabila ada yang masih memakai HTTP, perbarui ke HTTPS atau ambil ulang kode terbaru dari dashboard jaringan tersebut. Iklan yang skripnya terblokir tidak hanya gagal tampil; ia juga bisa meninggalkan ruang kosong yang merusak tata letak halaman.

Langkah 8: Paksa Redirect HTTP ke HTTPS dalam Satu Lompatan

Memperbaiki URL yang tersimpan adalah pekerjaan utama, tetapi Anda juga memerlukan jaring pengaman: setiap permintaan HTTP yang masih datang — dari tautan lama di situs lain, bookmark pembaca, atau hasil pencarian yang belum diperbarui — harus diarahkan ke versi HTTPS-nya. Tanpa redirect, pengunjung yang membuka versi HTTP situs Anda akan tetap melihat situs yang tidak aman, dan Google bisa mengindeks dua versi URL yang sama.

Aturan redirect yang benar adalah: setiap URL http:// mengarah ke padanan https://-nya dalam satu lompatan (single hop), tanpa rantai. Rantai redirect seperti http://situsanda.com → https://www.situsanda.com → https://situsanda.com memperlambat pemuatan halaman dan membingungkan perayap. Tujuan akhirnya adalah satu URL kanonis yang aman untuk setiap halaman, di mana pun tautan itu berasal.

Cara mengatur redirect

Cara paling umum di hosting berbasis Apache adalah menambahkan aturan redirect di berkas .htaccess. Aturan standar yang banyak dipakai host adalah mengarahkan semua permintaan HTTP ke HTTPS dengan status 301 (permanen). Sebelum mengedit .htaccess, unduh salinannya sebagai cadangan — kesalahan satu karakter di berkas ini dapat membuat seluruh situs tidak bisa diakses. Apabila Anda tidak nyaman mengedit .htaccess, sebagian besar panel hosting menyediakan tombol “Force HTTPS” yang melakukan hal yang sama tanpa perlu mengedit berkas. Plugin seperti Really Simple SSL juga dapat mengatur redirect ini, tetapi ingat prinsip dari bagian plugin di bawah: gunakan plugin sebagai alat bantu, bukan sebagai pengganti perbaikan URL yang tersimpan.

Setelah redirect aktif, uji dengan membuka versi HTTP dari beberapa URL: halaman depan, satu artikel, dan satu halaman arsip. Semuanya harus berpindah ke HTTPS secara otomatis dan hanya sekali. Periksa juga versi www dan non-www: putuskan satu versi kanonis (misalnya tanpa www), dan pastikan versi lainnya mengarah ke versi kanonis tersebut, juga dalam satu lompatan ke HTTPS. Apabila situs Anda berada di balik CDN atau reverse proxy, pastikan proxy meneruskan informasi protokol yang benar — misalnya header X-Forwarded-Proto: https — agar WordPress mengenali permintaan sebagai HTTPS dan tidak terjebak dalam loop redirect.

Langkah 9: Lindungi Situs dengan HSTS Setelah Semuanya Stabil

Setelah semua halaman bersih dari mixed content dan redirect berjalan dengan benar, Anda bisa mempertimbangkan lapisan perlindungan tambahan bernama HSTS (HTTP Strict Transport Security). HSTS adalah header yang memberi tahu browser untuk selalu memakai HTTPS pada domain Anda, sehingga browser tidak pernah mencoba HTTP terlebih dahulu — menutup celah sebelum redirect sempat terjadi.

HSTS diaktifkan dengan menambahkan header Strict-Transport-Security di konfigurasi server atau .htaccess. Sebagai patokan praktik yang aman, mulailah dengan durasi yang pendek — misalnya satu hari atau satu minggu — dan perpanjang durasinya hanya setelah Anda yakin semuanya stabil selama beberapa minggu. Alasannya: HSTS yang sudah tersimpan di browser pengunjung sulit ditarik kembali. Apabila Anda mengaktifkan HSTS dengan durasi panjang lalu ternyata masih ada subdomain yang belum mendukung HTTPS, pengunjung tidak akan bisa membuka subdomain tersebut sampai durasi HSTS kedaluwarsa.

Untuk situs yang sudah sepenuhnya HTTPS, HSTS adalah langkah pengerasan yang masuk akal. Untuk situs yang masih memiliki subdomain lama atau layanan pihak ketiga yang belum aman, tunda HSTS sampai semuanya beres. HSTS bersifat opsional dan tidak memengaruhi peringkat secara langsung; nilainya adalah perlindungan tambahan bagi pembaca Anda.

Header keamanan lain yang patut dipertimbangkan

Selain HSTS, ada beberapa header keamanan yang sering dipasang bersamaan: X-Content-Type-Options: nosniff untuk mencegah browser menebak jenis berkas, perlindungan frame untuk mencegah situs Anda dibingkai oleh situs lain, dan Referrer-Policy untuk mengendalikan informasi referrer. Header yang paling relevan dengan topik artikel ini adalah Content-Security-Policy (CSP), yang mendaftarkan sumber mana saja yang diizinkan memasok skrip dan gaya ke halaman Anda. CSP yang disusun dengan benar dapat mencegah mixed content baru muncul, karena browser akan menolak sumber di luar daftar. Namun CSP yang disusun sembarangan dapat memblokir skrip iklan dan layanan yang sah — termasuk AdSense — sehingga susunlah dengan hati-hati, uji di mode laporan terlebih dahulu, dan jangan mengaktifkan CSP yang ketat tanpa pengujian menyeluruh.

Kapan Plugin Pembantu Diperlukan dan Kapan Justru Dihindari

Ada dua plugin yang paling sering disebut dalam panduan mixed content: Really Simple SSL dan SSL Insecure Content Fixer. Keduanya bekerja dengan menulis ulang URL pada saat halaman ditampilkan — mirip dengan mekanisme WordPress 5.7 — dan keduanya dapat membantu pada situasi tertentu. Namun keduanya juga dapat menutupi masalah, bukan menyelesaikannya, dan penting untuk memahami kapan menggunakannya.

Really Simple SSL mendeteksi pengaturan SSL, memaksa situs ke HTTPS, menangani redirect, dan mencoba memperbaiki mixed content dengan menulis ulang URL. Plugin ini berguna sebagai jaring pengaman pada situs yang baru bermigrasi atau pada situs yang pemiliknya belum sempat memperbaiki database. SSL Insecure Content Fixer bekerja pada tingkat yang lebih spesifik: ia memperbaiki konten yang tidak aman pada tingkat WordPress dan media, dengan beberapa tingkat perbaikan yang bisa dipilih — dari yang sederhana (CSS, JavaScript, dan gambar) sampai yang lebih menyeluruh.

Prinsip yang perlu dipegang

Plugin yang menulis ulang URL pada saat tampilan adalah perban, bukan obat. Selama plugin aktif, halaman tampak benar; begitu plugin dinonaktifkan, URL lama yang masih tersimpan di database akan muncul kembali. Karena itu, urutan yang benar adalah: perbaiki database dan pengaturan terlebih dahulu, lalu gunakan plugin hanya bila masih ada sisa yang sulit dijangkau — misalnya URL di data plugin lama yang tidak menyediakan alat penggantian. Apabila Anda sudah menyelesaikan search and replace dan semua halaman terverifikasi bersih, Anda tidak memerlukan plugin penulisan ulang URL berjalan terus-menerus. Mempertahankan satu plugin tambahan hanya untuk menutupi masalah yang sebenarnya sudah selesai berarti menambah beban pemeliharaan tanpa manfaat.

Satu pengecualian: apabila situs Anda memiliki ribuan artikel dan perbaikan database belum bisa dilakukan sekaligus, plugin penulisan ulang dapat menjadi jembatan sementara sambil Anda memperbaiki database secara bertahap. Dalam kondisi ini, catat bahwa plugin tersebut bersifat sementara, dan jadwalkan perbaikan permanennya. Jangan biarkan solusi sementara menjadi permanen karena terlupakan.

Checklist Verifikasi Akhir: Dari Console Browser sampai Search Console

Perbaikan belum selesai sebelum diverifikasi. Berikut urutan pemeriksaan akhir yang sebaiknya Anda jalankan setelah semua langkah di atas selesai:

Verifikasi di browser

Buka halaman depan dan lima sampai sepuluh artikel lama — terutama yang ditulis sebelum migrasi HTTPS — di jendela penyamaran. Periksa tiga hal pada setiap halaman: gembok tampil tanpa peringatan, tab Console tidak lagi menampilkan peringatan mixed content, dan semua gambar, menu, slider, serta formulir berfungsi normal. Apabila satu halaman masih menampilkan peringatan, catat URL yang dilaporkan Console dan ulangi langkah perbaikan untuk sumber tersebut. Jangan menganggap pekerjaan selesai hanya karena halaman depan sudah bersih; artikel lama adalah tempat masalah bersembunyi.

Verifikasi redirect dan kanonis

Buka versi HTTP dari halaman depan dan satu artikel. Keduanya harus berpindah ke HTTPS dalam satu lompatan. Periksa juga bahwa versi www dan non-www mengarah ke versi kanonis yang sama. Gunakan pemeriksa redirect daring apabila Anda ingin memastikan tidak ada rantai redirect yang tersembunyi. Rantai redirect yang panjang memperlambat halaman dan membuang anggaran perayapan (crawl budget) Google.

Verifikasi di Google Search Console

Buka Google Search Console dan periksa laporan Halaman (Pages). Pastikan Google mengindeks versi HTTPS dari halaman Anda, bukan versi HTTP. Apabila masih ada URL HTTP yang terindeks, periksa apakah redirect-nya bekerja dan apakah sitemap Anda hanya berisi URL HTTPS. Gunakan properti Domain di Search Console agar data HTTP dan HTTPS beserta subdomain terkonsolidasi dalam satu tampilan. Minta pengindeksan ulang untuk halaman-halaman penting yang baru diperbaiki, dan pantau laporan selama beberapa hari untuk memastikan tidak ada URL HTTP baru yang muncul.

Verifikasi iklan dan fungsi penting

Masuk sebagai pengunjung biasa — bukan sebagai admin yang sudah masuk — dan buka beberapa artikel dengan traffic tertinggi. Pastikan unit iklan tampil normal, tata letak tidak rusak, dan tidak ada ruang kosong yang mencurigakan di tempat iklan seharusnya tampil. Uji formulir kontak dan formulir berlangganan dengan mengirim satu pengiriman uji. Terakhir, periksa kecepatan halaman: perbaikan mixed content kadang mengubah cara sumber daya dimuat, dan pemeriksaan Core Web Vitals setelah perbaikan adalah kebiasaan yang baik.

Kesalahan Umum yang Membuat Mixed Content Kembali Lagi

Mixed content yang sudah diperbaiki bisa muncul kembali apabila kebiasaan penyebabnya tidak diubah. Berikut kesalahan yang paling sering membuat masalah ini berulang:

Menempel URL lengkap dengan HTTP di artikel baru

Kebiasaan menulis URL lengkap http:// di dalam artikel — misalnya saat menautkan gambar dari situs sendiri — adalah sumber mixed content baru yang paling umum. Biasakan memakai tombol tambah media WordPress untuk menyisipkan gambar, karena WordPress akan memakai alamat situs yang benar secara otomatis. Apabila Anda harus menulis URL manual, selalu gunakan https://.

Mengganti tema tanpa memeriksa pengaturannya

Tema baru membawa pengaturan baru, dan pengaturan itu kadang berisi URL contoh yang memakai HTTP. Setiap kali mengganti tema, periksa logo, gambar latar, dan tautan media sosial di pengaturan tema sebelum mengumumkan tema baru kepada pembaca. Hal yang sama berlaku setiap kali memasang plugin baru yang menyimpan URL di pengaturannya.

Mengandalkan plugin penulisan ulang lalu melupakan database

Seperti dijelaskan di atas, plugin penulisan ulang URL menyembunyikan masalah tanpa memperbaikinya. Apabila plugin tersebut dinonaktifkan saat pembaruan atau diganti, seluruh mixed content lama akan muncul kembali dalam semalam. Perbaikan database adalah satu-satunya penyelesaian permanen; plugin hanya jembatan.

Melakukan search and replace tanpa dry run dan tanpa cadangan

Mengganti URL di database tanpa pratinjau dan tanpa cadangan adalah cara tercepat merusak situs. Selalu jalankan dry run, periksa tabel yang akan berubah, dan pastikan cadangan penuh sudah dibuat. Satu menit kehati-hatian di awal menghemat berjam-jam pemulihan.

Mengubah GUID saat search and replace

Kolom GUID di tabel posts adalah pengenal unik setiap artikel dan tidak boleh diubah, bahkan ketika isinya masih memakai URL HTTP lama. WordPress.org secara tegas memperingatkan hal ini dalam dokumentasi migrasinya. Alat search and replace yang baik tidak menyentuh GUID; apabila alat yang Anda pakai tidak memberi pilihan untuk mengecualikan GUID, jangan gunakan alat itu.

Lupa membersihkan cache setelah perbaikan

Cache plugin, cache server, dan cache CDN yang tidak dibersihkan akan terus menyajikan halaman lama. Banyak publisher mengira perbaikan mereka gagal, padahal yang mereka lihat adalah halaman yang tersimpan di cache. Selalu bersihkan semua lapisan cache setelah perbaikan, lalu periksa dari jendela penyamaran.

FAQ

Apa itu mixed content di WordPress?

Mixed content adalah kondisi ketika halaman WordPress dimuat lewat HTTPS, tetapi sebagian sumber dayanya — gambar, skrip, stylesheet, font, atau iframe — masih diminta lewat HTTP. Menurut MDN, halaman yang dimuat secara aman tetapi memakai sumber daya dari protokol tidak aman disebut mixed content. Penyebab paling umum adalah URL gambar lama di artikel yang ditulis sebelum situs bermigrasi ke HTTPS, serta URL yang tersimpan di pengaturan tema, widget, dan page builder.

Mengapa gembok browser hilang padahal SSL sudah terpasang?

Karena sertifikat SSL dan isi halaman adalah dua hal yang berbeda. Sertifikat yang valid hanya menjamin koneksi ke server terenkripsi; apabila isi halaman masih memanggil sumber daya lewat HTTP, browser tetap menampilkan peringatan. Periksa tab Console di developer tools untuk melihat URL HTTP mana yang masih diminta, lalu perbaiki URL yang tersimpan tersebut — jangan membeli sertifikat baru.

Apakah mixed content memengaruhi peringkat Google?

HTTPS adalah sinyal ranking Google yang ringan — diumumkan pada 6 Agustus 2014 sebagai sinyal yang sangat ringan dan memengaruhi kurang dari satu persen kueri global. Mixed content sendiri tidak diumumkan sebagai faktor ranking tersendiri; dampaknya lebih terasa pada kepercayaan pembaca dan berfungsinya halaman. Halaman yang menampilkan peringatan keamanan membuat pembaca pergi lebih cepat, dan itulah kerugian yang sebenarnya.

Bagaimana cara menemukan semua mixed content di situs saya?

Buka halaman di Chrome atau Firefox, tekan F12, lalu buka tab Console — peringatan mixed content tercantum di sana lengkap dengan URL yang bermasalah. Tab Network juga menampilkan semua permintaan HTTP. Periksa halaman depan dan artikel lama dengan traffic tertinggi terlebih dahulu, dan gunakan pemindai daring seperti Why No Padlock sebagai pelengkap. Selalu periksa dari jendela penyamaran agar cache lama tidak menutupi masalah.

Apakah plugin Really Simple SSL cukup untuk memperbaiki mixed content?

Plugin seperti Really Simple SSL dan SSL Insecure Content Fixer membantu dengan menulis ulang URL pada saat halaman ditampilkan, tetapi tidak mengubah URL yang tersimpan di database. Selama plugin aktif, halaman tampak benar; begitu plugin dinonaktifkan, masalah kembali. Gunakan plugin sebagai jembatan sementara, dan selesaikan perbaikan permanen dengan search and replace database yang memahami data serial, setelah cadangan penuh dibuat.

Apakah memperbaiki mixed content akan mengganggu iklan AdSense?

Tidak, apabila dilakukan dengan benar — justru sebaliknya, mixed content yang dibiarkan dapat mengganggu pemuatan skrip pendukung iklan dan membuat pembaca menutup halaman lebih cepat. Yang perlu dijaga adalah jangan sampai proses perbaikan memblokir atau mengubah kode iklan yang sah: perbarui URL HTTP di kode iklan manual ke HTTPS, uji tampilan iklan sebagai pengunjung biasa setelah perbaikan, dan bersihkan cache sebelum memeriksa. Artikel ini tidak menjanjikan kenaikan pendapatan; tujuannya adalah menghilangkan hambatan teknis yang tidak perlu.

Kesimpulan

Mixed content adalah masalah kebersihan teknis yang sangat umum di situs WordPress yang bermigrasi ke HTTPS — dan sangat bisa diselesaikan tanpa keahlian pemrograman. Urutan yang benar adalah: pastikan sertifikat valid, ubah kedua alamat situs ke HTTPS, manfaatkan migrasi satu klik WordPress 5.7 sebagai langkah awal, temukan URL HTTP yang tersisa lewat tab Console browser, lalu perbaiki URL yang tersimpan di database dengan alat search and replace yang memahami data serial — selalu setelah cadangan penuh dan dry run. Setelah itu, tangani tema, widget, page builder, dan embed pihak ketiga, pasang redirect HTTP ke HTTPS dalam satu lompatan, dan pertimbangkan HSTS hanya setelah semuanya stabil.

Dua prinsip yang perlu dipegang sepanjang proses ini: pertama, perbaiki data yang tersimpan, bukan hanya tampilannya — plugin penulisan ulang URL adalah jembatan, bukan penyelesaian. Kedua, verifikasi setiap langkah di browser sebagai pengunjung biasa, bukan sebagai admin yang sudah masuk. Gembok yang kembali muncul di artikel lama Anda adalah tanda bahwa pembaca mendapatkan halaman yang utuh, aman, dan berfungsi penuh — dan itulah fondasi yang membuat konten bagus Anda benar-benar dibaca sampai selesai.

Sumber resmi yang dirujuk

• Google Search Central — HTTPS as a ranking signal (blog, 6 Agustus 2014): developers.google.com/search/blog/2014/08/https-as-ranking-signal
• Google Search Central — HTTPS basics (dokumentasi crawling dan indexing): developers.google.com/search/docs/crawling-indexing/https
• MDN Web Docs — Mixed content: developer.mozilla.org/en-US/docs/Web/Security/Mixed_content
• Make WordPress Core — HTTPS in WordPress 5.7 (catatan pengembang, deteksi HTTPS dan migrasi satu klik, fungsi wp_replace_insecure_home_url): make.wordpress.org/core/tag/site-health/
• WordPress.org — Migrating WordPress (alamat situs siteurl dan home, peringatan data serial dan GUID): wordpress.org/documentation/article/moving-wordpress/
• Developer.WordPress.org — Referensi fungsi wp_is_using_https() (diperkenalkan WordPress 5.7): developer.wordpress.org/reference/functions/wp_is_using_https/
• WordPress.org — Plugin Better Search Replace (dokumentasi plugin di direktori plugin WordPress): wordpress.org/plugins/better-search-replace/
• WordPress.org — Plugin Really Simple SSL (dokumentasi plugin di direktori plugin WordPress): wordpress.org/plugins/really-simple-ssl/
• WordPress.org — Plugin SSL Insecure Content Fixer (dokumentasi plugin di direktori plugin WordPress): wordpress.org/plugins/ssl-insecure-content-fixer/
• SSL Labs dari Qualys — pemeriksa SSL daring yang disebut di Langkah 1 untuk memindai konfigurasi server dan versi TLS: ssllabs.com/ssltest/