Mengatasi Soft 404 pada Website Next.js & React

Website berbasis Next.js dan React mampu menghadirkan pengalaman pengguna yang cepat dan interaktif. Namun, mekanisme rendering dan routing berbasis JavaScript juga dapat menimbulkan masalah teknis SEO yang tidak selalu terlihat oleh pengunjung. Salah satu masalah tersebut adalah soft 404.

Soft 404 terjadi ketika sebuah URL menampilkan halaman yang tidak tersedia, kosong, atau menyerupai halaman error, tetapi server tetap mengirimkan kode status HTTP 200 OK. Dari sisi pengguna, halaman tersebut jelas bermasalah. Dari sisi server, permintaannya justru dianggap berhasil.

Ketidaksesuaian antara isi halaman dan kode status inilah yang membingungkan mesin pencari. Google dapat mengklasifikasikan URL tersebut sebagai soft 404 dan mengecualikannya dari hasil penelusuran. Karena itu, memperbaiki desain halaman error saja tidak cukup. Developer juga harus memastikan server memberikan kode status yang sesuai dengan kondisi konten.

Memahami Perbedaan 404 dan Soft 404

Apa Itu Error 404?

Error 404 Not Found adalah respons resmi dari server yang menyatakan bahwa resource pada URL tertentu tidak ditemukan. Sebagai contoh, ketika pengguna membuka:

https://contoh.com/artikel/tidak-tersedia

server seharusnya memberikan respons seperti berikut:

HTTP/1.1 404 Not Found
Content-Type: text/html

Server tetap boleh menampilkan halaman 404 yang menarik, lengkap dengan navigasi, kolom pencarian, rekomendasi artikel, dan tombol kembali ke halaman utama. Halaman yang ramah pengguna tidak harus mengembalikan status 200.

Google menjelaskan bahwa halaman yang sudah dihapus dan tidak mempunyai pengganti yang relevan sebaiknya mengembalikan status 404 atau 410. Kode tersebut membantu mesin pencari memahami bahwa URL tidak perlu dipertahankan di dalam indeks. Informasi ini dijelaskan dalam dokumentasi resmi Google Search Central tentang error crawling.

Apa Itu Soft 404?

Soft 404 bukan nama kode status HTTP. Istilah ini merupakan klasifikasi yang digunakan Google ketika menemukan ketidaksesuaian antara respons server dan isi halaman.

Contohnya:

HTTP/1.1 200 OK

Akan tetapi, isi halaman menyatakan:

Artikel tidak ditemukan.

Situasi tersebut disebut soft 404 karena server mengatakan bahwa permintaan berhasil, sedangkan konten menunjukkan bahwa resource sebenarnya tidak tersedia.

Google juga dapat menganggap halaman kosong, hampir kosong, gagal memuat konten utama, atau hanya berisi pesan error sebagai soft 404. Artinya, masalah ini tidak terbatas pada halaman yang secara eksplisit menampilkan tulisan “404”. Koneksi database yang gagal, data API yang tidak tersedia, atau JavaScript yang gagal dijalankan juga dapat menghasilkan kondisi serupa.

Mengapa Soft 404 Bermasalah bagi SEO?

Soft 404 dapat menyebabkan beberapa masalah:

• URL tidak dimasukkan atau dikeluarkan dari indeks Google.
• Googlebot menghabiskan waktu untuk merayapi URL yang sebenarnya tidak memiliki konten.
• Mesin pencari kesulitan membedakan halaman valid dari halaman yang telah dihapus.
• Laporan pengindeksan di Google Search Console dipenuhi URL bermasalah.
• Pengguna menerima pengalaman yang membingungkan karena halaman terlihat rusak, tetapi secara teknis dianggap berhasil.
• URL penting dapat lebih lambat ditemukan apabila situs memiliki banyak URL soft 404.

Namun, keberadaan beberapa 404 asli bukanlah sesuatu yang harus ditakuti. Google menyebut 404 sebagai bagian normal dari web. Masalah utamanya bukan kode 404, melainkan URL tidak valid yang memberikan kode status keliru atau pengalihan yang tidak relevan. Penjelasan tersebut dapat ditemukan dalam artikel resmi Google Search Central mengenai dampak error 404.

Mengapa Soft 404 Sering Terjadi pada React?

React pada dasarnya merupakan library untuk membangun antarmuka pengguna, bukan server HTTP. Oleh sebab itu, kemampuan aplikasi React dalam memberikan status 404 sangat bergantung pada server, platform hosting, atau framework yang menjalankannya.

Fallback SPA Mengembalikan index.html

Single-page application atau SPA biasanya menggunakan konfigurasi fallback. Semua permintaan URL diarahkan ke berkas index.html, lalu React Router menentukan komponen yang harus ditampilkan.

Alurnya kurang lebih seperti berikut:

Permintaan /produk/produk-yang-tidak-ada
                ↓
Server mengirim index.html dengan status 200
                ↓
React dijalankan di browser
                ↓
React Router menampilkan halaman “Tidak Ditemukan”

Meskipun pengguna melihat halaman 404, status yang pertama kali diterima crawler tetap 200 OK. Inilah pola soft 404 yang umum pada aplikasi React client-side rendered.

Pengecekan Data Dilakukan Setelah Halaman Dimuat

Pertimbangkan pola berikut:

function ProductPage() {
  const [product, setProduct] = useState(null);
  const [notFound, setNotFound] = useState(false);

  useEffect(() => {
    fetch("/api/products/123")
      .then((response) => {
        if (response.status === 404) {
          setNotFound(true);
          return null;
        }

        return response.json();
      })
      .then((data) => {
        if (data) setProduct(data);
      });
  }, []);

  if (notFound) {
    return <h1>Produk tidak ditemukan</h1>;
  }

  return product ? <Product data={product} /> : <p>Memuat...</p>;
}

Kode tersebut dapat menampilkan UI yang benar bagi pengguna, tetapi tidak mampu mengubah status dokumen HTML yang sebelumnya sudah dikirim server sebagai 200. Status 404 dari API juga tidak otomatis mengubah status halaman yang sedang dibuka.

Catch-All Redirect ke Halaman Utama

Konfigurasi yang mengarahkan setiap URL tidak dikenal ke halaman utama juga dapat dianggap sebagai soft 404. Contohnya:

/artikel/tidak-ada → 302 → /

Redirect semacam ini tidak menyelesaikan masalah karena halaman utama bukan pengganti yang setara dengan artikel yang hilang. Google memperingatkan bahwa mengarahkan banyak URL lama ke satu halaman yang tidak relevan, seperti homepage, dapat diperlakukan sebagai soft 404. Redirect hanya tepat jika terdapat tujuan baru yang benar-benar relevan. Lihat panduan resmi Google mengenai migrasi dan pemetaan URL.

Cara Mengatasi Soft 404 pada React SPA

Prioritaskan Penanganan di Sisi Server

Solusi terbaik adalah membuat server atau platform hosting mengenali URL yang benar-benar tersedia. URL yang tidak valid harus menghasilkan respons:

HTTP/1.1 404 Not Found

Pendekatan ini dapat dilakukan melalui:

• server Node.js atau Express;
• server-side rendering;
• pre-rendering;
• edge function atau serverless function;
• konfigurasi web server;
• aturan routing dari platform hosting.

Jika aplikasi harus sepenuhnya client-side rendered, developer perlu memahami keterbatasannya: React yang berjalan setelah dokumen dimuat tidak dapat mengganti status HTTP dokumen utama.

Gunakan Halaman 404 yang Benar-Benar Menghasilkan Status 404

Google menyarankan dua pendekatan untuk SPA ketika status halaman tidak mudah ditentukan dari client-side routing.

Pendekatan pertama adalah mengarahkan pengguna ke URL error yang oleh server benar-benar diberikan status 404:

async function loadProduct(productId) {
  const response = await fetch(`/api/products/${productId}`);

  if (response.status === 404) {
    window.location.replace("/not-found");
    return;
  }

  if (!response.ok) {
    throw new Error("Gagal mengambil data produk");
  }

  return response.json();
}

Syarat pentingnya adalah endpoint /not-found harus dikonfigurasi agar memberikan status HTTP 404, bukan sekadar menampilkan komponen error dengan status 200.

Pendekatan kedua adalah memasang noindex secara dinamis pada halaman error:

import { Helmet } from "react-helmet-async";

function NotFoundPage() {
  return (
    <>
      <Helmet>
        <meta name="robots" content="noindex" />
        <title>Halaman Tidak Ditemukan</title>
      </Helmet>

      <main>
        <h1>Halaman tidak ditemukan</h1>
        <p>URL yang Anda buka mungkin salah atau sudah tidak tersedia.</p>
      </main>
    </>
  );
}

Google mendokumentasikan redirect menuju URL berstatus 404 dan pemasangan noindex sebagai strategi untuk menghindari soft 404 pada SPA. Namun, jika infrastruktur memungkinkan, mengirim status 404 yang sebenarnya tetap menjadi pilihan paling jelas. Panduan lengkapnya tersedia dalam dokumentasi JavaScript SEO Google Search Central.

Perlu diperhatikan bahwa noindex bukan pengganti universal untuk 404. Noindex hanya meminta mesin pencari agar tidak mengindeks halaman, sedangkan kode 404 menjelaskan bahwa resource memang tidak ditemukan.

Jangan Menggunakan robots.txt sebagai Solusi Utama

Memblokir URL soft 404 melalui robots.txt bukan solusi yang tepat. Jika crawler dilarang membuka URL, Google mungkin tidak dapat melihat status HTTP, halaman error, maupun perintah noindex di dalamnya.

robots.txt mengatur proses crawling, sedangkan 404, 410, dan noindex berhubungan dengan keadaan serta pengindeksan URL. Ketiganya memiliki fungsi yang berbeda.

Mengatasi Soft 404 pada Next.js App Router

App Router digunakan pada proyek Next.js yang memakai direktori app.

Gunakan Fungsi notFound()

Pada halaman dinamis, data sebaiknya diperiksa di Server Component. Jika resource tidak ditemukan, panggil fungsi notFound() dari next/navigation.

// app/products/[slug]/page.tsx

import { notFound } from "next/navigation";

async function getProduct(slug: string) {
  const response = await fetch(
    `https://api.example.com/products/${slug}`,
    { cache: "no-store" }
  );

  if (response.status === 404) {
    return null;
  }

  if (!response.ok) {
    throw new Error("Gagal mengambil data produk");
  }

  return response.json();
}

export default async function ProductPage({
  params,
}: {
  params: Promise<{ slug: string }>;
}) {
  const { slug } = await params;
  const product = await getProduct(slug);

  if (!product) {
    notFound();
  }

  return (
    <main>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
    </main>
  );
}

Pemanggilan notFound() menghentikan rendering segmen route tersebut dan menampilkan komponen dari berkas not-found. Next.js juga menyisipkan meta tag noindex untuk mesin pencari. Perilaku ini tercantum dalam referensi resmi fungsi notFound().

Jangan menulis pola seperti ini:

if (!product) {
  return <NotFound />;
}

Pola tersebut hanya mengubah tampilan komponen. Next.js tidak diberi sinyal bahwa route harus diperlakukan sebagai halaman yang tidak ditemukan, sehingga respons masih dapat berupa 200 OK.

Buat Tampilan not-found.tsx

Selanjutnya, buat UI untuk halaman yang tidak ditemukan:

// app/products/[slug]/not-found.tsx

import Link from "next/link";

export default function ProductNotFound() {
  return (
    <main>
      <h1>Produk Tidak Ditemukan</h1>
      <p>
        Produk mungkin telah dihapus, dipindahkan, atau URL yang Anda
        masukkan tidak tepat.
      </p>

      <Link href="/products">Lihat semua produk</Link>
    </main>
  );
}

Untuk menangani URL yang sama sekali tidak cocok dengan route aplikasi, developer juga dapat menyediakan:

app/not-found.tsx

Berkas tersebut menjadi tampilan not-found tingkat root untuk URL yang tidak tertangani.

Waspadai Streaming Response

Ada nuansa penting pada App Router. Dokumentasi Next.js menjelaskan bahwa tampilan not-found dapat menghasilkan status 200 pada respons yang sudah mulai di-stream, sedangkan respons yang belum di-stream dapat menghasilkan status 404.

Hal ini terjadi karena header HTTP tidak dapat diubah setelah server mulai mengirimkan bagian awal respons. Jika keberadaan resource baru diketahui setelah streaming dimulai, status awal mungkin sudah terlanjur dikirim.

Next.js mengurangi risiko pengindeksan dengan memasukkan meta robots noindex ketika notFound() dipanggil. Meskipun begitu, untuk route yang sangat penting bagi SEO, lakukan pengecekan keberadaan resource sedini mungkin sebelum batas streaming atau Suspense yang relevan mulai mengirimkan konten.

Contohnya:

export default async function ArticlePage({ params }) {
  const { slug } = await params;

  // Validasi dilakukan sebelum merender bagian halaman.
  const article = await getArticle(slug);

  if (!article) {
    notFound();
  }

  return <ArticleDetail article={article} />;
}

Dengan cara ini, keputusan antara menampilkan konten dan halaman not-found dibuat pada tahap awal proses rendering. Keterangan mengenai perbedaan status respons streamed dan non-streamed tersedia pada dokumentasi file convention not-found.js.

Mengatasi Soft 404 pada Next.js Pages Router

Pages Router menggunakan direktori pages. Penanganannya berbeda dari App Router.

Menggunakan getServerSideProps

Untuk halaman dinamis yang datanya harus diperiksa setiap kali ada permintaan, gunakan getServerSideProps dan kembalikan notFound: true.

// pages/products/[slug].tsx

export async function getServerSideProps({ params }) {
  const response = await fetch(
    `https://api.example.com/products/${params.slug}`
  );

  if (response.status === 404) {
    return {
      notFound: true,
    };
  }

  if (!response.ok) {
    throw new Error("Gagal mengambil data produk");
  }

  const product = await response.json();

  return {
    props: {
      product,
    },
  };
}

export default function ProductPage({ product }) {
  return (
    <main>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
    </main>
  );
}

Nilai notFound: true membuat Next.js menampilkan halaman 404 dan mengembalikan status yang sesuai. Hal ini lebih benar dibandingkan mengirim data kosong sebagai props lalu menampilkan pesan “produk tidak ditemukan” di komponen. Perilakunya dijelaskan dalam dokumentasi getServerSideProps Next.js.

Menggunakan getStaticProps pada Halaman Dinamis

Untuk halaman yang dibuat secara statis, pemeriksaan dapat dilakukan melalui getStaticProps:

export async function getStaticProps({ params }) {
  const response = await fetch(
    `https://api.example.com/articles/${params.slug}`
  );

  if (response.status === 404) {
    return {
      notFound: true,
    };
  }

  if (!response.ok) {
    throw new Error("Gagal mengambil artikel");
  }

  const article = await response.json();

  return {
    props: {
      article,
    },
    revalidate: 300,
  };
}

Pendekatan ini juga berguna ketika konten yang sebelumnya tersedia kemudian dihapus. Saat proses regenerasi berikutnya berjalan, notFound: true memungkinkan halaman lama diperlakukan sebagai tidak ditemukan.

Membuat pages/404.tsx

Untuk menyesuaikan tampilannya, buat halaman berikut:

// pages/404.tsx

import Link from "next/link";

export default function Custom404() {
  return (
    <main>
      <h1>404 — Halaman Tidak Ditemukan</h1>
      <p>
        Halaman mungkin telah dipindahkan atau tidak lagi tersedia.
      </p>
      <Link href="/">Kembali ke halaman utama</Link>
    </main>
  );
}

Next.js menghasilkan halaman pages/404 secara statis agar dapat dikirim dengan cepat tanpa melakukan server rendering pada setiap permintaan. Informasi tersebut tersedia dalam dokumentasi custom error pages Next.js.

Memilih antara 404, 410, dan 301 Redirect

Tidak setiap URL bermasalah harus diperlakukan dengan cara yang sama. Pilihan respons harus mengikuti keadaan kontennya.

Gunakan 404 Jika Resource Tidak Ditemukan

Status 404 Not Found digunakan apabila:

• URL salah;
• slug tidak dikenali;
• resource belum pernah tersedia;
• konten hilang dan tidak ada pengganti yang relevan;
• server tidak mengetahui apakah kondisi tersebut permanen.

Gunakan 410 Jika Konten Sengaja Dihapus Permanen

Status 410 Gone dapat digunakan apabila developer mengetahui secara pasti bahwa konten telah dihapus secara permanen dan tidak akan kembali.

Next.js menyediakan mekanisme 404 secara langsung melalui notFound(). Jika aplikasi benar-benar membutuhkan 410, status tersebut biasanya harus diberikan melalui Route Handler, server khusus, middleware yang dirancang dengan tepat, atau konfigurasi infrastruktur.

Jangan menggunakan 410 hanya karena ingin mempercepat penghapusan URL tanpa memahami konsekuensinya. Pastikan resource memang tidak mempunyai pengganti dan benar-benar tidak akan dikembalikan.

Gunakan 301 Jika Terdapat Pengganti yang Relevan

Status 301 Moved Permanently digunakan ketika konten telah dipindahkan secara permanen ke URL lain yang sepadan.

Contoh:

/artikel/react-seo-lama
        ↓ 301
/artikel/seo-react

Hindari mengalihkan semua halaman yang hilang ke homepage. Redirect harus membantu pengguna mencapai konten pengganti yang memiliki maksud dan substansi serupa.

Membedakan Data Tidak Ditemukan dan Server Bermasalah

Salah satu kesalahan implementasi yang sering terjadi adalah menganggap semua kegagalan API sebagai 404.

Kode berikut bermasalah:

const response = await fetch(url);

if (!response.ok) {
  notFound();
}

response.ok akan bernilai false untuk berbagai kegagalan, termasuk 401, 403, 404, 429, dan 500. Mengubah semuanya menjadi 404 dapat menyembunyikan gangguan autentikasi, pembatasan permintaan, atau kerusakan server.

Gunakan penanganan yang lebih spesifik:

const response = await fetch(url);

if (response.status === 404) {
  notFound();
}

if (response.status === 401 || response.status === 403) {
  throw new Error("Akses ke resource ditolak");
}

if (response.status === 429) {
  throw new Error("Batas permintaan API telah tercapai");
}

if (!response.ok) {
  throw new Error("Terjadi gangguan pada layanan");
}

Secara konseptual:

• 404 berarti resource tidak ditemukan.
• 401 atau 403 berarti terdapat masalah autentikasi atau izin.
• 429 berarti terlalu banyak permintaan.
• 500 berarti terjadi kesalahan internal.
• Data kosong tidak selalu berarti resource tidak ada.

Pemisahan ini penting agar mesin pencari tidak diberi informasi palsu ketika masalah sebenarnya bersifat sementara.

Menangani Halaman Tipis yang Dianggap Soft 404

Kadang-kadang URL memang valid dan server sudah mengirimkan status 200, tetapi Google tetap menandainya sebagai soft 404. Hal ini dapat terjadi apabila halaman:

• hampir tidak memiliki konten utama;
• hanya menampilkan placeholder;
• gagal memuat data ketika dirender Googlebot;
• memuat pesan seperti “konten tidak tersedia” secara dominan;
• bergantung pada JavaScript atau resource yang gagal dimuat;
• memiliki hasil pencarian internal yang kosong;
• terlihat seperti halaman error meskipun secara bisnis dianggap valid.

Jika halaman seharusnya tetap tersedia, jangan langsung mengubahnya menjadi 404. Periksa terlebih dahulu apakah Googlebot menerima dan dapat merender konten yang sama dengan pengguna.

Langkah perbaikannya dapat berupa:

• memastikan API dapat diakses ketika halaman dirender;
• tidak memblokir berkas JavaScript dan CSS penting;
• menambahkan konten utama yang benar-benar bermanfaat;
• memperbaiki timeout atau kegagalan database;
• memberikan fallback yang informatif;
• menggunakan server-side rendering atau pre-rendering untuk konten penting;
• mengevaluasi hasil render melalui URL Inspection.

Menurut Google, halaman valid dapat ditandai soft 404 apabila konten tidak termuat dengan benar, resource penting hilang, atau hasil render terlihat kosong. Karena itu, diagnosis harus mencakup status HTTP sekaligus isi HTML yang dirender.

Cara Mendeteksi dan Menguji Soft 404

Periksa Google Search Console

Buka laporan pengindeksan halaman di Google Search Console dan cari kategori soft 404. Lakukan pemeriksaan terhadap beberapa URL contoh untuk menemukan pola yang sama, misalnya:

• seluruh slug yang tidak valid;
• produk yang telah dihapus;
• hasil pencarian kosong;
• URL dengan parameter tertentu;
• route yang gagal mengambil data;
• halaman lama setelah migrasi.

Setelah perbaikan diterapkan, gunakan fitur validasi pada Search Console. Perubahan status tidak selalu langsung terlihat karena Google perlu melakukan crawling ulang.

Periksa Status HTTP

Gunakan pemeriksa header atau perintah berikut:

curl -I https://contoh.com/produk/tidak-ada

Hasil yang diharapkan:

HTTP/2 404

Untuk mengikuti redirect:

curl -IL https://contoh.com/url-lama

Pengujian jangan dilakukan hanya pada browser. Browser lebih menonjolkan tampilan halaman, sedangkan masalah soft 404 justru sering berada pada header HTTP yang tidak terlihat.

Uji HTML Awal dan Hasil Render

Untuk aplikasi JavaScript, periksa dua keadaan:

1. HTML yang pertama kali dikirim server.
2. Halaman setelah JavaScript selesai dijalankan.

Apabila HTML awal hanya berupa app shell berstatus 200, kemudian pesan “tidak ditemukan” baru muncul setelah fetch client-side, URL tersebut berisiko menjadi soft 404.

URL Inspection di Google Search Console dapat membantu melihat status respons dan hasil render yang diterima Google. Developer juga sebaiknya menguji:

• JavaScript dalam keadaan aktif dan nonaktif;
• perangkat desktop dan mobile;
• respons API;
• error pada console;
• resource yang diblokir;
• timeout dan loading yang terlalu lama.

Uji pada Lingkungan Produksi

Perilaku routing lokal belum tentu sama dengan produksi. Hosting dapat mempunyai fallback rewrite yang mengubah semua URL menjadi 200 OK.

Karena itu, pengujian harus dilakukan terhadap domain produksi atau staging yang memiliki konfigurasi serupa dengan produksi. Periksa juga konfigurasi CDN, reverse proxy, serverless function, dan cache karena lapisan-lapisan tersebut dapat mengubah status respons.

Praktik Terbaik Halaman 404

Halaman 404 yang benar secara teknis tetap perlu membantu pengguna. Halaman yang baik sebaiknya:

• menjelaskan bahwa halaman tidak ditemukan;
• menggunakan tampilan yang konsisten dengan website;
• menyediakan tautan menuju homepage;
• menawarkan navigasi atau kolom pencarian;
• merekomendasikan kategori atau konten populer;
• tidak meniru halaman konten normal;
• tidak memuat iklan secara berlebihan;
• tidak melakukan redirect otomatis ke tujuan yang tidak relevan;
• tetap memberikan status HTTP 404.

Jangan menghapus navigasi hanya demi membuat halaman terlihat seperti error. Status HTTP menangani komunikasi dengan mesin pencari, sedangkan desain halaman membantu manusia menemukan jalan keluar.

Checklist Implementasi

Sebelum menutup proses perbaikan, pastikan hal-hal berikut telah diperiksa:

• URL yang tidak tersedia tidak mengembalikan 200 OK.
• App Router menggunakan notFound(), bukan hanya me-render komponen error.
• Pages Router menggunakan notFound: true pada fungsi pengambilan data yang sesuai.
• React SPA memiliki penanganan server-side atau strategi noindex yang dapat dirender crawler.
• Redirect hanya diarahkan ke halaman pengganti yang relevan.
• Kesalahan API 500, 403, atau 429 tidak disamarkan menjadi 404.
• Halaman valid mempunyai konten utama yang cukup dan dapat dirender.
• Resource penting tidak diblokir secara tidak sengaja.
• Sitemap tidak mencantumkan URL yang telah dihapus.
• Internal link tidak mengarah ke URL rusak.
• Status diuji pada lingkungan produksi menggunakan pemeriksa header.
• Hasil render diperiksa melalui Google Search Console.
• Perbaikan diajukan untuk divalidasi setelah deployment.

Status HTTP yang Tepat adalah Fondasi Penanganan Soft 404

Soft 404 bukan semata-mata masalah desain halaman error. Akar persoalannya adalah perbedaan antara keadaan resource, isi halaman, dan status HTTP yang diberikan server.

Pada Next.js, solusi utamanya adalah menangani ketiadaan data di sisi server. App Router menyediakan notFound() dan not-found.tsx, sedangkan Pages Router menyediakan notFound: true serta pages/404.tsx. Pada React SPA murni, masalahnya lebih menantang karena browser tidak dapat mengubah status dokumen setelah server mengirimkan 200 OK. Solusi idealnya adalah melibatkan server, pre-rendering, atau platform hosting dalam menentukan status URL.

Ringkasan pemilihan respons yang tepat dapat dilihat pada tabel berikut:

Kondisi URL atau konten	Respons yang disarankan	Tujuan
Halaman tersedia dan memiliki konten yang benar	200 OK	Menyatakan bahwa permintaan berhasil
Resource tidak ditemukan	404 Not Found	Menjelaskan bahwa URL tidak memiliki resource
Konten sengaja dihapus permanen tanpa pengganti	410 Gone	Menegaskan bahwa resource telah dihapus
Konten dipindahkan permanen ke halaman yang relevan	301 Moved Permanently	Mengarahkan pengguna dan mesin pencari ke lokasi baru
Pemindahan hanya bersifat sementara	302 Found atau redirect sementara yang sesuai	Mempertahankan URL asal sebagai lokasi utama
Halaman error pada SPA tidak dapat memberikan 404	noindex atau redirect ke URL yang benar-benar berstatus 404	Mencegah halaman error masuk indeks
Server atau API sedang mengalami gangguan	Status 5xx yang sesuai	Menunjukkan masalah sementara pada layanan
Pengguna tidak memiliki izin	401 atau 403	Menjelaskan masalah autentikasi atau otorisasi

Prinsip akhirnya sederhana: jangan hanya membuat halaman terlihat seperti 404. Pastikan lapisan server, framework, dan mesin pencari juga menerima sinyal yang benar. Ketika status HTTP, konten, redirect, dan metadata selaras, website menjadi lebih mudah dipahami oleh pengguna sekaligus lebih sehat dari sisi technical SEO.