Website Tidak Bisa Diakses — Checklist Berurutan

Langkah 1 — Hanya Anda atau semua orang

Jangan lewati langkah ini. Sudah banyak jam terbuang untuk memperbaiki server yang sebenarnya sehat.

• Buka situs lewat data seluler dengan Wi-Fi dimatikan. Kalau bisa, servernya baik-baik saja dan masalahnya ada di jaringan, DNS, atau browser Anda.
• Gunakan salah satu alat pemeriksa "down for everyone". Alat itu mengakses dari server eksternal dan memberi jawaban yang objektif.
• Buka lewat jendela penyamaran, lalu lewat browser lain. Ini mencoret cache dan ekstensi dari daftar kecurigaan.
• Kalau hanya Anda yang tidak bisa, bersihkan DNS cache lalu coba lagi. Di macOS: "sudo dscacheutil -flushcache"; di Windows: "ipconfig /flushdns".

Langkah 2 — Baca persis apa yang Anda terima

Pesan yang muncul sudah sangat mempersempit masalah bahkan sebelum Anda login ke mana pun.

Langkah 3 — DNS dan domain

• Periksa apakah domainnya masih aktif. Domain kedaluwarsa adalah penyebab yang paling sering terlewat, dan sangat mudah terjadi ketika email perpanjangan masuk ke folder spam.
• Jalankan "dig situsanda.com +short" atau "nslookup situsanda.com". Tanpa hasil berarti DNS-lah masalahnya dan semua lapisan di bawahnya tidak perlu diperiksa.
• Bandingkan IP yang dikembalikan dengan IP server Anda yang sebenarnya. Kalau berbeda, record DNS menunjuk ke tempat yang salah, biasanya sisa dari kepindahan sebelumnya.
• Pastikan nameserver-nya milik penyedia DNS yang benar-benar Anda pakai. Mengubah record di satu tempat sementara domainnya memakai nameserver di tempat lain adalah situasi yang sangat sering terjadi.
• Kalau baru mengubah DNS, tunggu. Record punya TTL, dan resolver di seluruh dunia akan menyimpan nilai lama sampai masa itu habis.

Langkah 4 — Apakah servernya hidup

• Ping alamat IP server. Ada balasan berarti mesinnya menyala dan terhubung; itu belum berkata apa-apa soal web server, tapi mencoret kemungkinan mesinnya mati.
• Coba SSH ke server. Kalau bisa masuk, sistem operasinya sehat dan Anda bisa memeriksa lebih dalam dari dalam.
• Kalau bisa ping tapi semua port timeout, kemungkinan besar firewall memblokir Anda, bukan server yang mati. Pemblokir brute-force yang memblokir IP setelah beberapa kali gagal login adalah penyebab yang sangat umum — coba dari jaringan lain untuk memastikan.
• Periksa panel penyedia untuk pengumuman maintenance, insiden, atau pemakaian yang melebihi kuota. Kadang jawabannya sudah ada di halaman status mereka.
• Kalau bisa masuk ke server, jalankan "df -h" dan "free -m" lebih dulu. Disk penuh dan RAM habis adalah dua penyebab akar dari sebagian besar masalah lain di daftar ini.

Langkah 5 — Layanan dan aplikasi

• Periksa web server berjalan: "systemctl status nginx" atau "systemctl status apache2".
• Periksa lapisan aplikasi: "systemctl status php8.2-fpm", atau proses Node maupun Gunicorn sesuai stack Anda.
• Periksa database: "systemctl status mysql" atau "mariadb".
• Baca error log sambil memuat ulang halaman. Ini langkah paling bernilai di seluruh daftar — "tail -f /var/log/nginx/error.log" sering menjawab pertanyaannya dalam hitungan detik.
• Kalau masalah dimulai tepat setelah sebuah perubahan, kembalikan perubahan itu sebelum mendiagnosis lebih jauh. Update plugin, penyuntingan konfigurasi, dan deploy kode baru adalah penyebab sebagian besar kerusakan mendadak.
• Periksa masa berlaku sertifikat SSL kalau errornya berkaitan dengan HTTPS. Tugas perpanjangan otomatis yang gagal diam-diam jauh lebih sering terjadi daripada yang dibayangkan.

Setelah pulih

Situs yang kembali jalan bukan berarti pekerjaannya selesai. Bagian paling bernilai justru ada di sepuluh menit sesudahnya.

Catat penyebab sebenarnya, bukan sekadar cara memperbaikinya. "Restart MySQL" adalah tindakan; "MySQL dibunuh OOM killer karena VPS 1GB tanpa swap" adalah penyebabnya, dan hanya yang kedua yang mencegah kejadian berikutnya.

Pasang monitoring uptime kalau belum ada. Mengetahui situs down dari sebuah peringatan jauh lebih baik daripada mengetahuinya dari pelanggan, dan layanan dasarnya gratis.

Tambahkan peringatan untuk hal-hal yang menyebabkan insiden kali ini: ruang disk, memori, masa berlaku sertifikat, dan masa berlaku domain. Empat peringatan itu mencakup sebagian besar insiden yang bisa diprediksi.

Periksa Search Console beberapa hari kemudian. Kalau downtime-nya panjang, laporan Crawl stats akan menunjukkan berapa banyak error yang ditemui Googlebot dan apakah Anda perlu meminta pengindeksan ulang.