Panduan

Setting Redirect dan Rewrite

Cara mengatur redirect dan rewrite di Netlify, Vercel, Cloudflare, dan GitHub Pages: beda 301 dan 302, serta menjaga peringkat saat URL berubah.

Redirect dan rewrite terlihat mirip — keduanya membuat satu URL menyajikan isi dari tempat lain. Tapi perbedaannya penting, dan salah pilih bisa merusak peringkat pencarianmu atau membuat aplikasimu tidak berfungsi.

Redirect atau rewrite?

RedirectRewrite
URL di address barBerubahTetap
Yang tahuBrowser dan penggunaHanya server
Status HTTP301 atau 302200
Dipakai untukHalaman pindah alamatFallback SPA, proxy API

Redirect memberi tahu browser: "yang kamu cari sekarang ada di sini." Browser pergi ke alamat baru, dan address bar berubah.

Rewrite menyajikan isi dari tempat lain tanpa memberi tahu siapa pun. Alamat di address bar tetap seperti yang diminta.

301 atau 302?

Untuk redirect, angka statusnya menentukan bagaimana mesin pencari memperlakukannya.

  • 301 — permanen. Mesin pencari memindahkan sinyal peringkat dari URL lama ke yang baru, dan mengganti URL lama di indeksnya. Browser juga menyimpannya di cache, kadang cukup lama.
  • 302 — sementara. Mesin pencari mempertahankan URL lama di indeks, dan tidak memindahkan sinyal peringkat.

Aturannya sederhana: kalau perpindahannya permanen, pakai 301. Memakai 302 untuk perpindahan permanen berarti halaman barumu tidak mewarisi apa pun dari yang lama.

301 sulit dibatalkan

Browser menyimpan redirect 301 di cache secara agresif. Kalau kamu memasang 301 lalu berubah pikiran, pengunjung lama bisa tetap dialihkan berhari-hari meski aturannya sudah kamu hapus. Kalau belum yakin, mulai dari 302.

Netlify

Dua cara, sama saja hasilnya. Lewat netlify.toml:

[[redirects]]
  from = "/artikel-lama"
  to = "/blog/artikel-baru"
  status = 301

[[redirects]]
  from = "/blog/*"
  to = "/artikel/:splat"
  status = 301

# Fallback SPA — perhatikan status 200
[[redirects]]
  from = "/*"
  to = "/index.html"
  status = 200

Atau lewat berkas public/_redirects (tanpa ekstensi), satu aturan per baris:

/artikel-lama    /blog/artikel-baru    301
/blog/*          /artikel/:splat       301
/*               /index.html           200

:splat berisi apa pun yang cocok dengan tanda bintang. Jadi /blog/halo jadi /artikel/halo.

Netlify membaca aturan berurutan dari atas, dan berhenti di yang pertama cocok. Karena itu aturan /* harus selalu di paling bawah — kalau di atas, ia menelan semuanya.

Vercel

Semuanya di vercel.json, dengan redirects dan rewrites dipisah jelas:

{
  "redirects": [
    {
      "source": "/artikel-lama",
      "destination": "/blog/artikel-baru",
      "permanent": true
    },
    {
      "source": "/blog/:slug",
      "destination": "/artikel/:slug",
      "permanent": true
    }
  ],
  "rewrites": [
    { "source": "/(.*)", "destination": "/index.html" }
  ]
}

"permanent": true berarti 301, false berarti 302.

Untuk redirect berdasarkan domain — misalnya mengarahkan non-www ke www:

{
  "redirects": [
    {
      "source": "/(.*)",
      "has": [{ "type": "host", "value": "situsku.com" }],
      "destination": "https://www.situsku.com/$1",
      "permanent": true
    }
  ]
}

Cloudflare Workers

Untuk fallback SPA, ada opsi khusus di wrangler.jsonc — lebih rapi daripada menulis aturan:

{
  "assets": {
    "directory": "./dist",
    "not_found_handling": "single-page-application"
  }
}

Untuk redirect biasa, Cloudflare membaca berkas _redirects di folder aset dengan format yang sama seperti Netlify:

/artikel-lama    /blog/artikel-baru    301
/blog/*          /artikel/:splat       301

Kalau kamu butuh logika yang lebih rumit, tulis saja di kode Worker-mu.

GitHub Pages

GitHub Pages tidak mendukung redirect maupun rewrite. Tidak ada berkas konfigurasi, tidak ada pengaturan.

Yang bisa dilakukan cuma dua akal-akalan.

Untuk fallback SPA, salin index.html jadi 404.html saat build:

cp dist/index.html dist/404.html

Aplikasimu termuat, tapi server tetap mengembalikan status 404. Mesin pencari melihat semua halaman dalammu sebagai tidak ditemukan — masalah nyata untuk situs publik.

Untuk memindahkan satu halaman, pakai meta refresh di HTML:

<meta http-equiv="refresh" content="0; url=/halaman-baru">
<link rel="canonical" href="https://situsku.com/halaman-baru">

Ini bekerja untuk pengunjung, tapi bukan redirect 301 sungguhan dan tidak memindahkan sinyal peringkat sebaik yang asli. Tag canonical membantu sedikit.

Kalau kamu butuh redirect yang benar, ini salah satu alasan paling kuat untuk pindah dari GitHub Pages. Lihat GitHub Pages vs Netlify.

Kesalahan yang paling sering terjadi

Memakai 301 untuk fallback SPA

Ini merusak aplikasimu. Dengan 301, alamat di address bar berubah jadi /, dan routermu tidak pernah melihat rute yang diminta. Fallback SPA harus berstatus 200 — itu rewrite, bukan redirect.

Menaruh aturan wildcard di atas

Netlify berhenti di aturan pertama yang cocok. Kalau /* ada di baris pertama, semua aturan di bawahnya tidak pernah terpakai.

Rantai redirect

URL A mengarah ke B, B mengarah ke C. Tiap lompatan menambah waktu tunggu dan mengurangi sinyal peringkat yang diteruskan. Arahkan A langsung ke C.

curl -sIL https://situsku.com/halaman-lama | grep -i "^HTTP\|^location"

Kalau keluarannya menampilkan lebih dari satu baris HTTP, kamu punya rantai.

Lupa versi www dan non-www

Kalau situsku.com dan www.situsku.com sama-sama menyajikan isi yang sama tanpa redirect, mesin pencari melihat dua situs berbeda dengan konten identik — dan sinyal peringkatmu terbelah dua. Pilih satu, redirect yang lain dengan 301.

Memeriksa hasilnya

Jangan percaya pada tampilan browser saja — cache bisa menipu. Periksa dari terminal:

curl -sSI https://situsku.com/artikel-lama | head -5

Yang perlu kamu lihat: baris status 301 atau 302, dan header location yang menunjuk ke tujuan yang benar.

Untuk memastikan tidak ada rantai:

curl -sIL https://situsku.com/artikel-lama | grep -ci "^HTTP"

Hasil 2 berarti satu redirect lalu satu halaman — itu benar. Lebih dari itu berarti ada rantai yang perlu dipangkas.

Saat mengubah struktur URL

Kalau kamu merombak alamat seluruh situs, urutan yang aman:

  1. Catat semua URL lama sebelum diubah — ambil dari sitemap lama atau dari data Search Console.
  2. Petakan tiap URL lama ke padanannya yang baru. Kalau tidak ada padanan, arahkan ke halaman kategori terdekat, bukan ke beranda.
  3. Pasang redirect 301 untuk semuanya.
  4. Perbarui sitemap dengan URL baru saja.
  5. Kirim ulang sitemap ke Google Search Console.
  6. Pantau laporan cakupan selama beberapa minggu.

Langkah kedua yang paling sering dikerjakan asal-asalan. Mengarahkan semua halaman lama ke beranda memang cepat, tapi mesin pencari memperlakukannya hampir sama dengan halaman yang dihapus — dan kamu kehilangan peringkat yang sudah terbangun.

Untuk redirect terkait perpindahan domain, lihat juga panduan custom domain dan SSL.