Anda baru saja setup Google Sites dengan custom domain. Versi www.namadomain.com bisa diakses normal — gembok SSL hijau, halaman tampil sempurna. Tapi begitu buka namadomain.com tanpa www, browser langsung blokir dengan pesan "This site can't provide a secure connection" dan kode error ERR_SSL_PROTOCOL_ERROR. Kasus ini sangat umum — penyebabnya 1 setting DNS yang sering terlewat saat setup custom domain. Kabar baiknya: bisa difix dalam 5–10 menit, dan ada beberapa solusi alternatif tergantung setup Anda.
www.namadomain.com ✅ bisa diakses normal dengan SSL valid, tapi namadomain.com (root/apex domain tanpa www) ❌ muncul ERR_SSL_PROTOCOL_ERROR. Kalau dua-duanya error → kemungkinan masalah berbeda (DNS belum propagasi, domain belum terhubung di Google Sites, atau certificate masih pending).Kenapa Masalah Ini Harus Segera Difix?
Kelihatannya sepele — toh website masih bisa diakses via www. Tapi efek negatifnya nyata dan menumpuk diam-diam:
- Backlink hilang nilainya — orang yang share link sering copy URL tanpa www (
namadomain.com/halaman). Klik di mana saja → error → bounce. Authority dari backlink terbuang. - SEO terganggu — Google bot crawl apex domain → SSL error → halaman tidak bisa di-index. Search Console akan kasih warning "URL is not on Google".
- Trust runtuh — pengunjung yang tidak teknis akan menyangka website Anda diretas atau ditutup. Untuk situs profesional (akademisi, bisnis, lembaga), ini sangat merugikan reputasi.
- Email forwarding berisiko terganggu — kalau Anda pakai email
[email protected], kesalahan DNS bisa menyebabkan MX record juga tidak optimal. - Bounce rate naik di Analytics — Google Analytics akan mencatat banyak entry error yang merusak metrik traffic Anda.
Kenapa ERR_SSL_PROTOCOL_ERROR Bisa Terjadi di Google Sites?
Akar masalahnya ada di A record root domain (apex) yang mengarah ke IP yang salah — bukan ke server Google Sites. Google Sites hanya bisa menerbitkan SSL certificate untuk domain yang DNS-nya benar-benar mengarah ke server mereka. Kalau IP-nya salah, Google tidak bisa verifikasi kepemilikan domain → SSL tidak diterbitkan → browser memblokir koneksi HTTPS dengan ERR_SSL_PROTOCOL_ERROR.
A record root domain (@) mengarah ke IP random — biasanya IP parking domain dari registrar lama (contoh: IP Hostinger CDN, Namecheap parking, dll). Google Sites tidak mengenal IP ini sehingga tidak menerbitkan SSL.
A record root domain (@) mengarah ke 4 IP resmi Google Sites: 216.239.32.21, 216.239.34.21, 216.239.36.21, 216.239.38.21. CNAME www → ghs.googlehosted.com.
Pasang Cloudflare gratis di depan domain. Cloudflare kasih SSL universal otomatis untuk apex + www, plus CNAME flattening (apex bisa "CNAME-style" ke ghs.googlehosted.com) dan proteksi DDoS. Cocok kalau registrar Anda tidak fleksibel.
Cara Diagnosa — Konfirmasi Penyebab Sebelum Fix
Sebelum mengubah DNS, pastikan dulu diagnosa-nya benar — supaya tidak hapus record penting yang masih dipakai. Gunakan DNS Lookup CekIPSaya untuk cek A record. Masukkan domain tanpa www dan amati hasilnya:
@. Kalau mengarah ke IP selain 216.239.32.21 / .34.21 / .36.21 / .38.21 — ini penyebabnya. Catat IP yang muncul (akan dihapus di langkah fix).www.namadomain.com. Kalau CNAME-nya sudah ghs.googlehosted.com tapi root domain belum mengarah ke IP Google → konfirmasi: ini masalah A record yang perlu difix.openssl s_client -connect namadomain.com:443 -servername namadomain.com. Kalau muncul "tlsv1 alert internal error" → server di IP tujuan tidak punya cert untuk domain Anda. Diagnosa 100% benar.www: echo | openssl s_client -connect www.namadomain.com:443 2>/dev/null | openssl x509 -noout -ext subjectAltName. Kalau hasilnya hanya DNS:www.namadomain.com tanpa apex → cert memang hanya cover www.Cara Pakai nslookup untuk Konfirmasi Diagnosis
Setelah kamu curiga ada masalah DNS, gunakan command nslookup untuk konfirmasi. Tool ini tersedia di Windows (CMD), macOS, dan Linux tanpa perlu install apapun. Ini juga cara paling efektif untuk mematahkan argumen "dari jaringan A bisa, dari jaringan B tidak bisa" — karena hasilnya akan identik dari manapun selama A record belum diubah.
nslookup namadomain.com. Lihat field "Address" di output — kalau bukan IP Google Sites, DNS A record-nya salah.nslookup namadomain.com 8.8.8.8. Ini bypass DNS jaringan lokal dan langsung query Google DNS. Kalau hasilnya SAMA dengan Step 1 → masalah bukan di jaringan lokal, tapi di A record registrar domain.# Test 1: pakai DNS jaringan kamu
nslookup namadomain.com
# Output yang SALAH (A record belum difix):
# Name: namadomain.com
# Address: 2.x.x.x ← IP bukan milik Google
# Test 2: pakai Google DNS langsung
nslookup namadomain.com 8.8.8.8
# Kalau hasilnya SAMA → masalah di registrar, bukan jaringan
# Output yang BENAR (setelah A record difix):
# Name: namadomain.com
# Address: 216.239.32.21 ← IP Google Sitesnslookup namadomain.com 8.8.8.8. Kalau IP yang muncul sama, berarti masalahnya bukan di jaringan mereka melainkan di A record registrar domain. Semua jaringan di dunia akan resolve ke IP yang sama selama A record-nya belum diubah.Solusi 1 (🥇 Recommended): Update A Record ke Google Sites
Solusi paling resmi & sederhana — ini yang direkomendasikan Google Workspace Help. Cocok untuk semua kasus, tidak perlu pindah nameserver, tidak perlu service tambahan.
@ (root domain) yang tidak mengarah ke IP Google Sites. Hapus semuanya. ⚠️ Jangan hapus MX, TXT, atau CNAME www — itu untuk fungsi lain.@, TTL 3600): 216.239.32.21 · 216.239.34.21 · 216.239.36.21 · 216.239.38.21. Empat IP ini IP resmi Google untuk redundansi load balancing.www — harus tetap mengarah ke ghs.googlehosted.com. Kalau sudah benar, jangan diubah.sites.google.com → pilih site → Settings → Custom domains. Pastikan root domain (tanpa www) terdaftar dengan status Connected. Kalau belum, klik "Add custom domain" dan ikuti verifikasi domain.www tetap bisa diakses. Google Sites akan otomatis terbitkan SSL setelah deteksi A record sudah benar.Solusi 2: Cloudflare Free Plan + CNAME Flattening
Kalau Anda mau setup yang lebih powerful — sekaligus dapat CDN, DDoS protection, dan analytics — pasang Cloudflare gratis di depan domain. Cloudflare punya fitur CNAME Flattening yang membuat apex domain bisa "berperilaku seperti CNAME" — pointer ke ghs.googlehosted.com → resolve otomatis ke IP Google. SSL Universal Cloudflare cover apex + www tanpa konfigurasi tambahan.
cloudflare.com → Sign Up → Add Site → masukkan namadomain.com → pilih plan Free.ada.ns.cloudflare.com, bob.ns.cloudflare.com). Pindah NS di registrar Anda. Tunggu propagasi 1–24 jam.CNAME, name @, target ghs.googlehosted.com, Proxy status Proxied (orange cloud). Cloudflare akan flatten otomatis.www → ghs.googlehosted.com juga proxied (orange cloud). Cloudflare cert akan cover keduanya.Solusi 3: HTTPS Forwarding di Registrar
Sebagian registrar menyediakan fitur "Domain Forwarding with HTTPS" — apex domain di-redirect 301 ke https://www.namadomain.com, dan registrar yang handle SSL untuk redirect itu. Cek panel registrar Anda untuk fitur "URL Forwarding" atau "Domain Forwarding". Kalau tersedia dan support HTTPS — aktifkan, jadi namadomain.com auto-redirect ke versi www yang sudah valid.
Solusi 4: Pertimbangkan Pindah Hosting yang Native Mendukung Apex SSL
Solusi terakhir untuk yang ingin lebih fleksibel: pindah dari Google Sites ke platform yang native mendukung apex domain SSL otomatis — seperti Vercel, Netlify, atau Cloudflare Pages (semuanya gratis untuk situs personal/akademis). Platform ini auto-issue SSL untuk apex + www tanpa setup A record manual. Tradeoff: harus migrasi konten dari Google Sites — tidak instan. Tapi long-term ini paling sustainable kalau Anda butuh kontrol design lebih.
Ringkasan Perubahan DNS (Solusi 1 — Standard Google)
| Type | Host / Name | Value | TTL | Aksi |
|---|---|---|---|---|
| A | @ | IP lama (contoh: 203.0.113.1) | — | ❌ HAPUS |
| A | @ | 216.239.32.21 | 3600 | ✅ TAMBAH |
| A | @ | 216.239.34.21 | 3600 | ✅ TAMBAH |
| A | @ | 216.239.36.21 | 3600 | ✅ TAMBAH |
| A | @ | 216.239.38.21 | 3600 | ✅ TAMBAH |
| CNAME | www | ghs.googlehosted.com. | 3600 | ⚠️ BIARKAN |
| MX | @ | (jangan diubah jika ada) | — | ⚠️ BIARKAN |
| TXT | @ | (SPF/verifikasi domain) | — | ⚠️ BIARKAN |
Cara Verifikasi Fix Berhasil
Setelah propagasi DNS (cek di dnschecker.org dari berbagai lokasi), verifikasi dengan 3 langkah berikut. Semua harus pass sebelum dianggap fix berhasil:
dig namadomain.com A +short
# Output yang diharapkan setelah fix:
# 216.239.32.21
# 216.239.34.21
# 216.239.36.21
# 216.239.38.21curl -sI https://namadomain.com | head -3
# Output yang diharapkan:
# HTTP/2 200
# (atau)
# HTTP/2 301
# location: https://www.namadomain.com/echo | openssl s_client -connect namadomain.com:443 \
-servername namadomain.com 2>/dev/null \
| openssl x509 -noout -ext subjectAltName
# Output yang diharapkan:
# DNS:namadomain.com, DNS:www.namadomain.comCara visual paling cepat: buka https://namadomain.com di browser incognito (supaya cache tidak bias). Kalau muncul gembok 🔒 dan halaman tampil sempurna — fix berhasil 🎉.
Alur Teknis: Kenapa SSL Handshake Gagal
GET https://apex
Mau buka domain
→ IP parking lama
A record salah
Tidak punya cert
Untuk domain user
Internal error
Handshake batal
ERR_SSL_PROTOCOL_ERROR
User lihat error
Diagram di atas menjelaskan kenapa error muncul: browser meminta koneksi HTTPS ke domain → DNS mengembalikan IP yang salah (parking) → server di IP tersebut tidak punya cert untuk domain user → TLS handshake gagal di tahap server hello → browser block dengan ERR_SSL_PROTOCOL_ERROR. Setelah A record difix ke IP Google, server Google sudah punya cert valid yang cover domain user → handshake sukses → halaman tampil.
Kenapa www Bisa Tapi Root Domain Tidak?
Karena standar DNS punya aturan ketat: subdomain (www) bisa pakai CNAME, tapi root/apex domain harus pakai A record (atau ALIAS/ANAME bagi DNS provider yang support). Jadi waktu setup Google Sites, biasanya CNAME www → ghs.googlehosted.com sudah benar dari awal — itu kenapa www.namadomain.com jalan. Tapi A record root domain seringkali masih default ke IP parking dari registrar (yang dipasang otomatis saat domain baru dibeli) — dan itulah penyebab apex domain mati. Google Sites tidak bisa terbitkan SSL untuk domain yang IP-nya bukan milik mereka.
ALIAS @ → ghs.googlehosted.com sebagai pengganti 4 A record Google. Lebih mudah maintenance.Bedakan dengan Error Lain yang Mirip
A record salah IP. Ciri: www jalan, apex error. Solusi: Solusi 1 atau 2 di artikel ini.
DNS belum resolve sama sekali — domain belum dikonfigurasi atau NS salah. Ciri: dig tidak menampilkan record apapun. Solusi: tambah semua DNS record dari awal, cek nameserver di registrar.
DNS sudah benar tapi cert yang aktif untuk domain lain. Ciri: gembok merah, nama domain mismatch di detail cert. Solusi: re-verify domain di Google Sites Settings, atau tunggu re-issue cert.
DNS sudah benar tapi Google Sites masih proses SSL. Ciri: dig menunjukkan IP Google tapi browser masih error. Solusi: tunggu 1–24 jam, atau klik "Re-verify" di Google Sites Settings.
Salah satu dosen di sebuah perguruan tinggi negeri di Indonesia membuat website akademik personal menggunakan Google Sites dengan custom domain organisasi (.org). Setup awal: domain dibeli dari registrar populer, langsung pakai default DNS dari registrar tersebut. Versi
www.namasitus.org berfungsi sempurna — gembok hijau, halaman tampil normal. Tapi kalau buka namasitus.org tanpa www, langsung ERR_SSL_PROTOCOL_ERROR. Diagnosa via DNS Lookup CekIPSaya: A record root domain ternyata mengarah ke IP parking page dari infrastruktur registrar lama (default A record yang dipasang otomatis saat domain baru dibeli — biasanya berupa landing page "Domain Parked" milik registrar). Nameserver pun masih pakai NS default dari registrar (umumnya
ns1/ns2.dns-parking.com atau sejenisnya). Cek SSL via openssl s_client: muncul tlsv1 alert internal error (alert 80) — server di IP parking memang tidak punya cert untuk domain user. Cek SAN cert www: hanya cover www.namasitus.org, apex tidak ada. Fix: hapus A record IP parking lama, tambah 4 A record Google (
216.239.32.21 dst). Propagasi DNS sekitar 2 jam, dan dalam 6 jam Google Sites sudah terbitkan SSL untuk apex. Pengecekan ulang via DNS Lookup menunjukkan A record sudah benar, dan https://namasitus.org sudah bisa diakses dengan gembok hijau dan SAN cert cover apex + www. Total waktu fix: 8 jam (5 menit edit DNS + 7 jam 55 menit menunggu propagasi & SSL issuance). Pelajaran: setiap kali setup custom domain di Google Sites, langsung verifikasi A record root domain di hari yang sama — jangan biarkan apex domain "tergantung" di IP parking registrar.@ yang mengarah ke IP non-Google.FAQ — Pertanyaan yang Sering Ditanyakan
Kesimpulan
ERR_SSL_PROTOCOL_ERROR di Google Sites custom domain hampir selalu disebabkan oleh A record root domain yang salah — biasanya masih mengarah ke IP parking dari registrar. Solusi paling cepat: hapus A record lama, ganti dengan 4 IP resmi Google Sites (216.239.32.21, .34.21, .36.21, .38.21), tunggu propagasi DNS 15 menit–24 jam. Alternatif: pakai Cloudflare gratis untuk dapat universal SSL yang langsung cover apex domain. Verifikasi via DNS Lookup, atau pelajari cara kerja DNS dan cara cek DNS record online untuk diagnosa lebih dalam.