Peta Redirect WordPress ke Next.js di Vercel Tanpa Bocor SEO

Saat deploy pertama saya buka vercel.json dan isinya cuma satu baris: deploymentEnabled. Beberapa hari kemudian saya cek Search Console, 21 URL lama dari WordPress masih balik 404, halaman, postingan, kategori, sampai wp-sitemap.xml.

Awalnya saya kira nanti aja urusan redirect, toh next.config.js kan tempatnya. Saya juga sempat mikir trafik dari postingan demo theme yang usang nggak bakal ngaruh. Ternyata menunggu cuma bikin link equity bocor percuma, setiap 404 adalah sinyal yang hilang untuk Google.

Saya putuskan bikin peta redirect eksplisit di vercel.json lewat commit ec14f43 di egpindo-website [1]. Kenapa bukan next.config.js? Karena file ini jadi satu sumber kebenaran untuk semua routing di level infrastruktur, bahkan untuk path yang bukan halaman Next.js.

Salah Asumsi Awal

Banyak yang mengira redirect harus masuk ke kode aplikasi. Padahal Vercel memproses redirect di Edge di semua region secara independen [1], dan konfigurasi di vercel.json dievaluasi saat build time [2]. Batasnya juga longgar: hingga 2.048 aturan dan 4.096 karakter per source atau destination [2], jauh di atas 21 aturan yang saya butuhkan. Naruh di level infrastruktur jadi lebih efisien, nggak nambah beban runtime aplikasi.

Detail yang bikin saya berhenti sejenak: permanent: true di vercel.json bukan 301, tapi 308. Di ekosistem Next.js, permanent: true dipetakan ke 308 dan false ke 307 untuk menjaga method request tetap utuh [3]. Beda dengan 301/302 yang pada beberapa browser mengubah POST jadi GET, 307/308 secara eksplisit mempertahankan method asal [3].

Kenapa Saya Pilih vercel.json

Saya pribadi pilih vercel.json untuk kasus migrasi legacy begini, meski next.config.js juga bisa melakukan hal yang sama. Alasannya simpel: vercel.json lebih predictable untuk routing level platform. Perubahan kecil pada redirect nggak harus lewat logika aplikasi, dan saya bisa melihat semua aturan legacy dalam satu tempat tanpa campur aduk dengan config Next.js lain.

Untuk SEO, Google memperlakukan 301 dan 308 sama sebagai sinyal permanen [4]. Di dokumen konsolidasi duplikat, Google menempatkan redirect sebagai sinyal terkuat bahwa target harus jadi kanonis, di atas rel=canonical dan sitemap [4]. Sinyal-sinyal itu bisa ditumpuk, makin konsisten, makin besar peluang URL pilihan muncul di hasil pencarian [4]. Jadi angka statusnya bukan debat kusir; yang penting adalah semantik permanen plus konsistensi di internal link dan sitemap.

{
  "trailingSlash": false,
  "redirects": [
    { "source": "/about", "destination": "/id/about", "permanent": true },
    { "source": "/category/service", "destination": "/id/service", "permanent": true },
    { "source": "/2022/08/30/egp-terapkan-guard-profesional", "destination": "/id/blog/egp-terapkan-guard-profesional", "permanent": true },
    { "source": "/2022/08/23/facts-about-business-that-will-help-you-success", "destination": "/id/blog", "permanent": true },
    { "source": "/wp-sitemap.xml", "destination": "/sitemap.xml", "permanent": true }
  ]
}

Potongan di atas cuma 5 dari 21 aturan agar kebaca, tapi polanya sama: source adalah path lama, destination adalah path baru, permanent: true artinya 308.

Peta 21 Aturan dan Jebakan Canonical

Saya kelompokkan 21 aturan biar nggak jadi dump asal. Sembilan untuk halaman statis seperti /about, /service, /diklat, /client, /gallery, /artikel, /contact, kategori, dan sample-page. Dua belas untuk postingan dengan strategi beda: empat carryover murni karena kontennya masih relevan dan saya sudah bawa slug-nya ke /id/blog/*, empat dari pillar page lama seperti penyedia pengamanan dan pelatih keamanan saya arahkan ke /id/service atau /id/diklat yang lebih baru, dan empat dari postingan demo theme yang isinya lorem ipsum saya lempar ke /id/blog agar trafik nggak hilang percuma.

Saya tambah tiga aturan untuk kategori lama dan satu untuk wp-sitemap.xml -> /sitemap.xml. Semua saya kunci dengan trailingSlash false biar nggak mismatch antara source dan destination, satu slash ketinggalan aja bisa bikin rule nggak ke-match.

Redirect saja nggak cukup. Di commit berikutnya 60a7dc9 saya betulkan canonical di frontend/src/app/[locale]/blog/[slug]/page.tsx: sebelumnya canonical menunjuk ke sourceUrl WordPress lama, yang sekarang justru 301 balik ke halaman baru. Canonical yang menunjuk ke URL yang redirect balik ke dirinya sendiri adalah loop yang membingungkan crawler. Fix-nya: canonical jadi self-referencing ke halaman itu sendiri, atribusi ke artikel asli tetap lewat link baca sumber yang kelihatan.

Kalau kamu lagi migrasi WordPress lama, jangan tunda peta redirect. Kategorikan dulu, baru tulis aturan satu per satu, dan pastikan canonical nggak berantem sama redirect yang kamu buat sendiri.

Sumber

• [1] Vercel Docs, Routing Redirects. vercel.com/docs/routing/redirects
• [2] Vercel Docs, Configuration Redirects. vercel.com/docs/routing/redirects/configuration-redirects
• [3] Next.js Docs, redirects. nextjs.org/docs/app/api-reference/config/next-config-js/redirects
• [4] Google Search Central, Consolidate duplicate URLs. developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls