Cara Memperbaiki Error 404 Setelah Deploy Website atau Aplikasi

Jika aplikasimu berjalan di lokal tetapi halaman menampilkan 404 setelah deploy, penyebab paling umum adalah routing single-page app (SPA) yang belum diatur: server mencari file bernama /dashboard yang tidak ada, karena route itu hanya ada di JavaScript. Solusinya adalah aturan fallback yang menyajikan index.html untuk route aplikasi. Penyebab lain adalah file yang tidak ada di output build, path yang case-sensitive, perbedaan trailing slash, base path yang salah, dan route API yang belum pernah di-deploy.

Mulailah dengan mencatat URL persis yang menghasilkan 404 dan bagaimana kamu sampai ke sana. Polanya akan langsung menunjuk ke penyebabnya.

Langkah 1: Temukan polanya

Untuk melihat status code yang sebenarnya, buka developer tools (klik kanan → Inspect), pilih tab Network, muat ulang, dan lihat status dari request pertama.

Langkah 2: Tambahkan fallback SPA

Ini kasus klasiknya. Di single-page app React, Vue, atau Svelte, server hanya punya beberapa file asli: index.html dan beberapa file JavaScript dan CSS. Route seperti /dashboard atau /projects/42 ditangani oleh router di browser.

• Klik tautan berfungsi: router mengubah URL dan menggambar halaman baru tanpa meminta server.
• Refresh atau membuka tautan langsung gagal: browser meminta /dashboard ke server, server tidak punya file tersebut, lalu mengembalikan 404.

Solusinya adalah aturan yang mengatakan: jika request tidak cocok dengan file asli, sajikan index.html dengan status 200, dan biarkan router mengambil alih. Caranya bergantung pada host (periksa dokumentasi terbaru host kamu, karena detailnya berubah):

Pastikan aturan tidak menelan file asli: request ke /assets/app.js harus tetap mengembalikan file JavaScript. Jika yang dikembalikan adalah index.html, kamu akan melihat halaman kosong dengan error “Failed to load module script”. Lihat cara memperbaiki halaman putih kosong.

Beri juga router sebuah route catch-all agar URL yang tidak cocok dengan halaman mana pun menampilkan “Halaman tidak ditemukan” yang ramah, bukan layar kosong.

Jika kamu tidak bisa mengubah pengaturan server, hash routing (URL seperti /#/dashboard) menghindari masalah ini, karena bagian setelah # tidak pernah dikirim ke server. Ini solusi sementara, bukan pilihan pertama: URL-nya kurang rapi dan kurang ramah untuk mesin pencari.

Framework yang merender halaman di server atau membuatnya saat build (Next.js, Astro, dan sejenisnya) biasanya memiliki file asli atau route server untuk setiap halaman, sehingga masalah ini lebih jarang terjadi di sana. Padanannya adalah halaman yang tidak pernah dibuat saat build.

Langkah 3: Periksa apa yang benar-benar di-deploy

Jika semuanya 404, kemungkinan server tidak menyajikan aplikasi yang sudah dibangun.

• Folder yang benar. Host harus mempublikasikan output build (umumnya dist untuk Vite, build untuk Create React App, out untuk ekspor statis Next.js), bukan root proyek.
• Build berhasil dijalankan. Baca log deploy. Jika build gagal, host mungkin tidak men-deploy apa pun, atau malah versi lama.
• index.html berada di level atas folder yang dipublikasikan, bukan di sub-folder.
• Base path cocok. Jika aplikasi disajikan dari contoh.com/app/, ia harus dibangun dengan base itu (base di Vite, basename di React Router), atau setiap route dan aset akan meleset.

Langkah 4: Perbaiki file yang hilang dan path yang salah

Ketika halaman termuat tetapi aset 404:

• Case sensitivity. macOS dan Windows biasanya menganggap Logo.png dan logo.png sebagai file yang sama. Kebanyakan server Linux tidak. Buat setiap referensi cocok persis dengan nama file yang asli.
• File di luar build. Di Vite, file di public/ disalin apa adanya dan dirujuk dari root (/logo.png). File yang di-import dalam kode akan di-bundle. File yang berada di tempat lain dalam proyek mungkin tidak ter-deploy sama sekali.
• Path relatif. images/photo.jpg diselesaikan relatif terhadap URL saat ini, sehingga rusak di /blog/post-1. Gunakan /images/photo.jpg.
• File unggahan yang disimpan di disk lokal. Jika unggahan pengguna ditulis ke folder server, file itu hilang saat versi baru di-deploy. Gunakan penyimpanan file yang semestinya.

Langkah 5: Tangani trailing slash secara konsisten

/about dan /about/ adalah dua URL yang berbeda. Host berbeda dalam menambah atau menghapus slash, dan ketidakcocokan dengan tautan atau router bisa menghasilkan 404 atau loop redirect. Pilih satu gaya, buat tautanmu memakai gaya itu, dan atur host agar mengarahkan bentuk lainnya ke sana. Konsistensi juga membantu mesin pencari, yang jika tidak akan melihat dua salinan dari setiap halaman.

Langkah 6: Perbaiki route API yang 404

Jika halaman termuat tetapi tab Network menampilkan request /api/... dengan 404:

• Backend belum di-deploy. Host statis hanya menyajikan file; backend harus berjalan di suatu tempat.
• Path di-route secara berbeda di produksi. Di development, proxy mungkin meneruskan /api ke server terpisah. Di produksi, host perlu rewrite yang setara, atau front end harus memanggil alamat asli API.
• Fallback SPA menangkapnya. Request API yang mengembalikan index.html dengan status 200 berarti aturan fallback terlalu luas. Kecualikan /api/* darinya.

Permintaan aplikasi yang sudah dipublikasikan ke /api/orders mengembalikan 404, padahal di pratinjau berfungsi. Periksa bagaimana /api di-route di pratinjau dibanding aplikasi yang dipublikasikan, dan buat front end produksi menjangkau backend dengan cara yang sama.

Langkah 7: Arahkan URL lama

Jika kamu pindah dari situs lain atau menata ulang struktur, URL lama yang masih dipakai orang dan mesin pencari akan menghasilkan 404. Tambahkan redirect 301 (permanen) dari setiap URL lama ke lokasi barunya. Simpan daftarnya dan uji sampel setelah peluncuran. Panduan kami tentang memigrasikan situs WordPress membahas cara menyusun daftar itu.

Langkah 8: Periksa domainnya

Jika aplikasi berfungsi di alamat host tetapi 404 di domain kustommu, domain itu mungkin mengarah ke proyek yang salah, atau host belum mengaitkan domain itu dengan situsmu. Periksa record DNS dan pengaturan domain di host. Lihat cara menghubungkan domain kustom.

Buat halaman 404 aslimu bermanfaat

Beberapa 404 memang benar: seseorang salah mengetik URL. Buat halaman itu membantu:

• Pesan singkat dan tautan ke halaman utama serta bagian-bagian penting
• Kotak pencarian, jika situsnya punya fitur pencarian
• Header dan navigasi yang sama dengan bagian lain situs

Jika setup kamu memungkinkan, kembalikan status 404 yang sebenarnya untuk halaman yang tidak ada. Pesan “tidak ditemukan” yang dikembalikan dengan status 200 adalah yang oleh mesin pencari disebut soft 404, dan itu bisa membuang waktu crawl mereka serta membingungkan indexing.

Kesalahan umum

• Hanya menguji dengan mengklik. Selalu uji dengan menempelkan URL dalam ke tab baru lalu me-refresh.
• Fallback yang menangkap semuanya. Aset dan route API mengembalikan index.html, yang menyebabkan halaman kosong dan error API yang membingungkan.
• Huruf besar-kecil yang tidak cocok yang hanya rusak di server.
• Mendeploy folder sumber alih-alih output build.
• Menata ulang URL tanpa redirect. Setiap tautan lama menjadi 404.

404 di Mythex

Di Mythex, kamu mempublikasikan dari workspace, dan front end statis di-deploy sebagai situs statis. Jika halaman yang dipublikasikan menghasilkan 404, berikan agen URL yang tepat, apakah itu terjadi saat refresh atau saat klik, dan apa yang ditampilkan tab Network, lalu minta agen memeriksa routing-nya. Publikasikan ulang setelah perbaikan, karena aplikasi yang aktif adalah snapshot sampai kamu mempublikasikannya lagi. Jika kamu baru saja mengubah proyek dan situs yang aktif terlihat lama, publikasikan ulang dan lakukan hard refresh. Gunakan Perbaiki dengan AI di dialog publikasi jika build gagal. Lihat Cara mempublikasikan dan Pemecahan masalah publikasi di dokumentasi, dan panduan kami tentang men-debug aplikasi buatan AI.

Checklist 404

• Mencatat URL persis yang 404 dan apakah saat klik, refresh, atau keduanya
• Fallback SPA menyajikan index.html untuk route aplikasi, dengan status 200
• Fallback mengecualikan file asli dan /api/*
• Router memiliki route catch-all untuk halaman “tidak ditemukan”
• Folder output build yang dipublikasikan benar, dan build berhasil
• Base path cocok dengan tempat aplikasi disajikan
• Kapitalisasi nama file cocok dengan setiap referensi
• Path aset diawali dengan /
• Gaya trailing slash konsisten
• Route API di-deploy dan di-route di produksi
• Redirect 301 untuk URL lama
• Deep link diuji dengan menempelkannya ke tab baru

Pertanyaan