Website yang memakai HTTPS masih dapat mempunyai link, canonical, atau resource beralamat lama. Auditnya perlu memisahkan konsistensi URL halaman dari keamanan pemuatan resource. Mengarahkan HTTP ke HTTPS tidak otomatis memperbaiki seluruh isi halaman.
Mulai dari host yang dimiliki dan fungsinya. Jangan menganggap www, domain utama, dan semua subdomain harus menuju satu aplikasi. Bisnis bisa sengaja memakai host berbeda untuk portal, toko, atau layanan lain.
Buat peta host yang disetujui
Tulis alamat utama untuk setiap fungsi, lalu tentukan variasi yang benar-benar merupakan alias.
| Host ilustratif | Fungsi | Tujuan yang diharapkan |
|---|---|---|
example.com |
Website publik | Tetap di host ini |
www.example.com |
Alias website publik | Ke alamat utama bila diputuskan |
app.example.com |
Aplikasi pelanggan | Tetap aplikasi terpisah |
help.example.com |
Dokumentasi | Mengikuti arsitektur dokumentasi |
Peta ini mencegah redirect luas yang merusak aplikasi lain. Keputusan host merupakan keputusan arsitektur, bukan sekadar preferensi penulisan URL.
Uji variasi URL halaman yang sama
Untuk satu halaman publik, periksa HTTP/HTTPS dan varian host terkait. Catat status awal, setiap redirect, dan tujuan akhir.
Google mendokumentasikan redirect dan canonical sebagai cara menyampaikan URL utama; konsistensi protokol dan sitemap membantu menghindari sinyal bertentangan. Panduan konsolidasi URL.
Jika HTTP berpindah ke HTTPS tetapi canonical masih menunjuk HTTP, temukan sumber metadata. Jangan hanya mengubah satu halaman jika kesalahan berasal dari konfigurasi template bersama.
Pahami mixed content melalui resource
Mixed content terjadi ketika halaman aman memuat resource melalui koneksi tidak aman, misalnya halaman HTTPS meminta script HTTP. Browser dapat meningkatkan sebagian request ke HTTPS atau memblokir jenis tertentu. Perilakunya berbeda menurut resource dan browser. Penjelasan mixed content MDN.
Contoh ilustratif:
<img src="http://media.example.com/foto-produk.jpg" alt="Detail produk">
Jangan sekadar mengganti http menjadi https tanpa memastikan server menyediakan resource di alamat aman. Sesudah perubahan, periksa respons, sertifikat, dan gambar yang tampil.
Cari sumber URL lama
URL resource dapat berasal dari template, database konten, CSS, plugin, atau API. Periksa panel Network dan Console untuk menemukan request yang gagal atau diperingatkan.
Telusuri komponen yang menghasilkan URL tersebut. Jika berasal dari field konten, perbaikan template mungkin tidak menyentuh artikel lama. Jika berasal dari CSS, pencarian pada body artikel tidak akan menemukannya.
| Sumber | Masalah contoh | Tindakan yang diperiksa |
|---|---|---|
| Template | Canonical HTTP | Sumber alamat situs |
| Konten | Gambar lama HTTP | Padanan HTTPS yang tersedia |
| CSS | Font tidak aman | URL resource yang sah |
| API | Host lama pada data | Pembentukan URL di sumber |
| Sitemap | Host alias tercantum | Generator daftar |
Contoh diagnosis: tombol terlihat, fungsi gagal
Halaman layanan terbuka lewat HTTPS, tetapi script formulir dimuat dari HTTP dan diblokir. Pengunjung melihat tombol kirim, namun pengiriman tidak berjalan.
Dampaknya bukan sekadar nilai audit. Fungsi pengguna terputus. Periksa request script, pastikan versi aman tersedia, lalu uji formulir dari awal sampai respons sukses pada lingkungan yang sesuai.
Jangan menonaktifkan perlindungan browser untuk membuat demo tampak bekerja. Perbaiki resource serta konfigurasi yang menyebabkan pemuatan tidak aman. Jika sumber pihak ketiga tidak menyediakan versi yang layak, bahas pengganti berdasarkan fungsi yang dibutuhkan.
Verifikasi sesudah koreksi
Ulangi akses langsung pada halaman prioritas dan beberapa template. Periksa bahwa tidak ada loop, host tujuan benar, canonical dan sitemap selaras, serta resource penting berhasil dimuat.
Gunakan sesi baru atau kondisi cache yang dicatat. Browser yang menyimpan resource lama dapat menyamarkan perubahan, sedangkan cache kosong saja tidak mewakili semua pengalaman. Tujuannya mengetahui kondisi pengujian, bukan memilih hasil paling bagus.
Periksa pula link unduhan dan formulir. Halaman utama yang aman belum membuktikan seluruh perjalanan pengguna memakai tujuan yang sesuai. Satu endpoint lama dapat menjadi sumber kegagalan tersisa.
Perubahan DNS, sertifikat, atau kebijakan keamanan sebaiknya dikerjakan pengelola yang memahami dependensinya. Audit ini menyediakan daftar keputusan dan bukti, bukan alasan mengganti konfigurasi seluruh domain tanpa pemetaan.
Mulailah dengan peta host dan satu URL penting. Dari sana kamu bisa membedakan alias yang perlu diselaraskan, aplikasi yang harus tetap terpisah, dan resource lama yang perlu diperbaiki.
