SEO Single Page Application: Cara Membuat SPA Terindeks Google dan Terbaca oleh AI

SEO single page application adalah sekumpulan teknik yang membuat aplikasi JavaScript yang dibangun dengan React, Vue, Angular, atau Svelte semudah di-crawl seperti situs web klasik. Masalahnya terdokumentasi dengan baik: Google menjelaskan di dasar-dasar SEO JavaScript bahwa ia memproses halaman JavaScript dalam tiga fase (crawling, rendering, pengindeksan), dan setiap kelemahan SPA berada di suatu titik dalam alur itu. Panduan ini berfokus pada SPA; untuk situs JavaScript secara umum, baca panduan kami tentang SEO JavaScript.

Apa itu single page application, dan mengapa sulit untuk SEO?

Situs web tradisional mengembalikan dokumen HTML lengkap untuk setiap URL. SPA mengembalikan dokumen yang hampir sama untuk setiap URL: <div id="root"> kosong, beberapa meta tag, dan bundle JavaScript yang besar. Browser mengunduh bundle, memanggil API, lalu menggambar halaman. Ketika pengunjung mengklik tautan, JavaScript menukar konten tanpa memuat ulang.

Bagi manusia dengan ponsel cepat, hasilnya terasa instan. Bagi crawler, respons pertama adalah shell kosong: tanpa heading, tanpa teks, tanpa tautan. Semuanya bergantung pada apakah bot mengeksekusi JavaScript, dan kapan. Satu fakta itu menjelaskan sebagian besar masalah SEO SPA:

• Konten tertunda atau hilang: teks baru ada setelah rendering, yang dilakukan Google belakangan dan dilewati bot lain.
• Satu URL untuk banyak tampilan: SPA lama melakukan routing dengan fragmen (/#/pricing), dan bagian setelah # tidak pernah dikirim ke server, sehingga semua tampilan runtuh menjadi satu URL.
• Title dan deskripsi identik: shell membawa satu <title>, dan jika router tidak memperbaruinya, setiap halaman memakai title yang sama.
• Tautan tanpa href: tombol dan handler onClick bernavigasi bagi pengguna tetapi tidak memberi crawler apa pun untuk diikuti.
• Error soft 404: server menjawab 200 untuk setiap path, termasuk halaman yang tidak ada, sehingga tampilan error terindeks sebagai halaman tipis.
• JavaScript berat: bundle besar memperlambat tampilan pertama dan interaksi, yang merugikan Core Web Vitals.

Bagaimana Google meng-crawl dan merender SPA?

Googlebot pertama-tama mengambil HTML mentah dan membaca tautan serta direktif yang ditemukan di sana. Halaman yang mengembalikan status 200 kemudian dimasukkan ke antrean untuk Web Rendering Service, Chromium headless. Google menyatakan bahwa halaman "mungkin berada di antrean ini selama beberapa detik, tetapi bisa lebih lama dari itu". Setelah dirender, HTML hasilnya diurai lagi untuk konten dan tautan, lalu diindeks.

Empat detail dari dokumentasi Google yang penting bagi SPA:

1. Hanya elemen <a> dengan href yang merupakan tautan andal. Tautan yang disisipkan oleh JavaScript tidak masalah selama mengikuti format itu.
2. Fragmen bukan halaman terpisah. Google meminta Anda memakai History API (pushState) alih-alih rute #. Google menghentikan skema crawling AJAX lamanya (URL #!) pada Oktober 2015.
3. noindex di HTML asli menang. Google dapat melewati rendering saat melihat noindex, jadi menghapusnya dengan JavaScript belakangan tidak berhasil.
4. Rendering memakai file cache. Googlebot menyimpan cache JavaScript dan CSS secara agresif, jadi gunakan nama file dengan fingerprint (hash konten pada nama file) untuk menghindari bundle usang.

Konsekuensi praktisnya: Google bisa mengindeks SPA yang dirender di sisi klien, tetapi Anda menambahkan langkah kedua, penundaan, dan titik kegagalan pada setiap halaman. Timeout, panggilan API yang diblokir, atau error JavaScript saat rendering membuat versi yang terindeks kosong. Periksa apa yang dilihat Google dengan alat Inspeksi URL di Search Console, dan baca panduan kami tentang cara kerja pengindeksan Google jika halaman tetap tidak terindeks.

Apakah ChatGPT, Claude, dan Perplexity membaca JavaScript?

Sebagian besar tidak. Dalam studi yang diterbitkan pada Desember 2024 tentang trafik jaringannya, Vercel dan MERJ menemukan bahwa "tidak ada crawler AI utama yang saat ini merender JavaScript": GPTBot, OAI-SearchBot, dan ChatGPT-User (OpenAI), ClaudeBot (Anthropic), PerplexityBot, Meta-ExternalAgent, dan Bytespider semuanya hanya membaca HTML mentah. Mereka memang mengunduh file JavaScript (sekitar 11.5% permintaan ChatGPT dan 23.8% permintaan Claude) tetapi tidak menjalankannya. Pengecualiannya adalah Gemini, yang mengandalkan infrastruktur rendering Google, dan AppleBot, yang memakai crawler berbasis browser.

Untuk SPA yang dirender di sisi klien, ini berarti crawler AI yang menyuplai ChatGPT, Claude, dan Perplexity melihat halaman kosong. Produk Anda bisa berperingkat di Google dan tetap tidak terlihat di jawaban AI, karena asisten tidak pernah membaca satu kata pun darinya. Hal yang sama berlaku untuk sebagian besar bot pratinjau tautan di jaringan sosial dan aplikasi pesan, yang membaca tag Open Graph di HTML mentah. Setelah konten ada di HTML, periksa juga bahwa robots.txt mengizinkan crawler AI yang Anda inginkan.

Strategi rendering mana yang sebaiknya dipakai SPA?

Solusinya adalah mengirim HTML sungguhan pada respons pertama. Google menyebut dynamic rendering (menyajikan versi prerender hanya untuk bot) sebagai "solusi sementara dan bukan solusi yang direkomendasikan" dalam dokumentasi dynamic rendering-nya, dan mengarahkan ke server-side rendering, static rendering, atau hydration sebagai gantinya. Definisi di bawah mengikuti referensi Rendering on the Web di web.dev.

Sebagian besar framework modern memungkinkan Anda memadukan strategi per rute: statis untuk halaman pemasaran, dirender server untuk katalog, dirender klien untuk aplikasi setelah login. Pengaturan hibrida itu memberi crawler HTML lengkap di tempat trafik pencarian terjadi dan mempertahankan pengalaman SPA di tempat yang memberi nilai.

Opsi framework

Situs yang dihasilkan oleh AI website builder layak disebut khusus: banyak yang mengekspor aplikasi React yang dirender di sisi klien. Jika Anda membangun situs dengan salah satunya, lihat catatan kami tentang SEO dan GEO Lovable sebelum menganggap Google dan ChatGPT dapat membacanya.

Checklist SEO SPA: apa yang diperbaiki per rute

1. Beri setiap tampilan URL yang bersih dan dapat di-crawl

Gunakan History API (/pricing, jangan pernah /#/pricing), satu URL per konten, dan URL yang sama baik pengunjung datang langsung maupun lewat navigasi dalam aplikasi. Setiap URL harus memuat konten yang benar saat dibuka di tab baru, yang merupakan uji yang dilakukan crawler.

2. Gunakan tautan sungguhan

Setiap elemen navigasi yang mengarah ke halaman yang dapat diindeks sebaiknya berupa <a href="/path">. Komponen tautan framework (Link, NuxtLink, routerLink) menghasilkan markup ini; handler klik kustom pada elemen div atau button tidak. Tautan yang baik juga membawa arsitektur situs Anda: jika sebuah halaman tidak ditautkan, crawler jarang menemukannya.

3. Perbarui title, deskripsi, dan canonical per rute

Setiap rute membutuhkan title, meta description, canonical, dan tag Open Graph sendiri, yang sebaiknya dibuat di server. Halaman kami tentang meta tag mendaftar apa yang perlu diatur. Pertahankan satu canonical tag: Google merekomendasikan untuk mengaturnya di HTML, dan jika JavaScript mengubahnya, hasilnya tidak boleh bertentangan dengan yang asli.

4. Kembalikan kode status yang jujur

Produk yang hilang dan artikel yang dihapus tidak boleh menjawab 200 dengan pesan error. Dengan SSR, kembalikan 404 atau 410 sungguhan dari server. Dalam SPA murni, Google menerima dua alternatif: alihkan dengan JavaScript ke URL yang mengembalikan 404, atau tambahkan meta robots noindex pada tampilan error.

5. Taruh konten utama dan data terstruktur di HTML

Heading, teks isi, harga, FAQ, dan data terstruktur JSON-LD sebaiknya ada di respons server, bukan dimuat setelah klik atau gulir. Konten di balik tab yang dirender sesuai permintaan, atau di balik tombol "muat lebih banyak", sering terlewat.

6. Jaga JavaScript tetap ringan

Pecah bundle per rute, tunda yang tidak dibutuhkan untuk tampilan pertama, dan hindari merender ulang seluruh halaman saat hydration. Perhatikan bahwa data lapangan Chrome (CrUX) mengaitkan metrik navigasi dalam aplikasi dengan URL yang pertama kali dimuat pengunjung, jadi uji templat utama Anda satu per satu.

7. Uji apa yang diterima bot

Bandingkan tiga versi dari setiap templat utama: HTML mentah (lihat sumber atau ambil halaman dengan alat baris perintah), HTML hasil render Google (Inspeksi URL, lalu "Lihat halaman yang di-crawl"), dan halaman dengan JavaScript dinonaktifkan. Jika teks utama hanya muncul di versi kedua, crawler AI tidak melihatnya. Audit crawlability untuk AI gratis kami dan indexability checker menjalankan pemeriksaan ini pada URL mana pun.

Bagaimana mengetahui apakah SPA Anda bermasalah dengan SEO?

SEO SPA dan GEO: ditemukan di Google dan dikutip oleh AI

Selama bertahun-tahun, client-side rendering adalah risiko yang bisa dikelola karena Google akhirnya merender JavaScript. Dengan sebagian penemuan kini terjadi di ChatGPT, Claude, Gemini, dan Perplexity, biayanya berubah: halaman yang baru ada setelah JavaScript dieksekusi tidak ada di sumber yang bisa dibaca sebagian besar asisten. Crawlability di HTML mentah telah menjadi syarat pertama generative engine optimization.

Setelah HTML lengkap, sisanya mengikuti aturan yang biasa: halaman yang menjawab satu pertanyaan dengan jelas, dengan fakta bersumber dan data terstruktur, adalah yang dikutip asisten. Fitur optimasi GEO Sorank membantu Anda menulis dan menerbitkan konten itu, dan pelacakan sebutan AI menunjukkan apakah ChatGPT, Claude, dan Gemini mengutip merek Anda setelah perbaikan rendering.

Aturan utama SEO single page application muat dalam satu kalimat: apa pun yang ingin Anda peringkatkan di Google dan dikutip AI harus ada di HTML yang dikirim server. Pertahankan SPA untuk pengalaman setelah login, render halaman publik di server atau saat build, lalu uji apa yang diterima bot sebelum dan sesudah setiap rilis.