JavaScript SEO: Kenapa Konten Anda Terlihat di Browser Tapi Hilang di Google

JavaScript SEO: Kenapa Konten Anda Terlihat di Browser Tapi Hilang di Google

Ada satu percakapan yang saya alami berulang kali, dan polanya selalu sama. Pemilik website bilang halamannya sudah jadi, isinya lengkap, bahkan desainnya bagus. Developer-nya buka halaman itu di laptop, klik kanan, Inspect, dan semua teks ada di sana. Tapi di Search Console, halaman itu berstatus terindeks dengan konten yang nyaris kosong, atau malah tidak terindeks sama sekali. Dua orang melihat halaman yang sama dan sampai pada kesimpulan yang berlawanan.

Yang terjadi bukan salah satu dari mereka berbohong. Yang terjadi adalah mereka melihat dua versi halaman yang berbeda. Di artikel ini saya akan tunjukkan di titik mana kedua versi itu berpisah, bagaimana cara membuktikannya dalam dua puluh menit tanpa tools berbayar, dan kesalahan JavaScript SEO mana yang benar-benar memakan trafik dibanding yang cuma ramai dibicarakan. Saya juga akan masuk ke bagian yang hampir tidak dibahas panduan lain: tahun ini masalahnya bukan lagi sekadar Googlebot, tapi mesin-mesin AI yang mulai jadi sumber trafik dan sama sekali tidak menjalankan JavaScript Anda.

Delapan tahun saya menangani SEO, dan website berbasis framework JavaScript selalu jadi kategori kasus yang paling sering disalahdiagnosis. Bukan karena masalahnya rumit. Karena yang diperbaiki hampir selalu bukan yang rusak.

Satu Halaman, Dua Versi, Dan Hanya Satu yang Dibaca Google

Begini urutannya. Saat browser Anda membuka halaman, ia menerima satu dokumen HTML dari server, lalu menjalankan semua JavaScript di dalamnya, menarik data dari API, dan menyusun tampilan akhir. Yang Anda lihat di layar adalah hasil akhir itu. Yang dikirim server tadi sudah lama tertimbun.

Googlebot menerima dokumen yang sama persis. Bedanya, ia tidak langsung menjalankan JavaScript-nya. Ia membaca HTML mentah dulu, mencatat tautan yang ada di dalamnya, lalu menaruh halaman itu di antrean untuk dirender nanti. Nanti itu bisa beberapa detik, bisa beberapa menit, dan untuk sebagian kecil halaman bisa jauh lebih lama.

Jadi kalau HTML mentah Anda isinya cuma sebuah div kosong dan satu baris script, itulah versi pertama yang Google punya tentang halaman Anda. Versi lengkapnya menyusul, dengan syarat semuanya berjalan lancar sampai akhir. Klik kanan Inspect tidak pernah menunjukkan versi pertama ini, karena Inspect memperlihatkan DOM yang sudah selesai dibentuk. Di situ letak kesalahpahaman antara pemilik website dan developer-nya.

Satu hal yang perlu diluruskan sejak awal: pengecekan dengan mematikan JavaScript di browser bukan simulasi yang akurat. Googlebot menjalankan JavaScript. Ia hanya menjalankannya terpisah dari saat merayapi, dan di lingkungan yang lebih rapuh dari laptop Anda.

Apa Itu JavaScript SEO? Tiga Hal yang Sebenarnya Dicakup

JavaScript SEO adalah praktik memastikan konten dan tautan yang dihasilkan JavaScript benar-benar bisa dirayapi, dirender, dan diindeks mesin pencari, bukan hanya tampil di browser pengunjung.

Isinya menyempit ke tiga pekerjaan:

  1. Memastikan konten penting ada di HTML yang diterima crawler, bukan hanya muncul setelah JavaScript selesai bekerja.
  2. Memastikan tautan bisa diikuti, yang berarti tautan asli dengan atribut href, bukan elemen yang jadi bisa diklik karena ditempeli event listener.
  3. Memastikan sinyal teknis tidak berubah di tengah jalan, termasuk canonical, status HTTP, dan tag robots yang disuntikkan belakangan oleh script.

Tiga poin itu yang membedakan JavaScript SEO dari technical SEO pada umumnya. Sitemap, kompresi gambar, dan minifikasi memang penting, tapi itu berlaku untuk website apa pun. Kalau sebuah panduan JavaScript SEO isinya mayoritas hal seperti itu, panduan itu belum menyentuh masalahnya.

Tiga Antrean yang Harus Dilewati Sebelum Konten Anda Terindeks

Google sendiri membagi prosesnya jadi tiga tahap: merayapi, merender, lalu mengindeks. Yang sering terlewat adalah bahwa ketiganya tidak berjalan dalam satu tarikan napas. Di antara tahap satu dan dua ada antrean, dan antrean itu punya aturan sendiri soal siapa yang dilayani dan siapa yang dilewati.

Saya paling sering menjelaskannya dengan tiga pos pemeriksaan.

Pos Pertama: Apakah Halamannya Boleh Diambil

Sebelum apa pun terjadi, Googlebot memeriksa robots.txt. Kalau URL-nya diblokir, selesai, tidak ada rendering sama sekali. Yang lebih sering jadi masalah bukan halamannya, tapi file JavaScript dan CSS-nya. Saya pernah menemukan satu baris disallow pada folder aset di sebuah toko online, dan akibatnya Google menerima halaman produk tanpa harga, tanpa deskripsi, tanpa apa-apa. Halamannya sendiri sama sekali tidak diblokir. Yang diblokir adalah bahan untuk membangunnya.

Kalau Anda ingin memahami urutan lengkapnya sampai ke level jenis-jenis crawler yang dipakai Google, saya sudah membahas tiga tahapan cara kerja Googlebot dari crawling sampai indexing secara terpisah dan lebih detail.

Pos Kedua: Apakah Halamannya Layak Dirender

Halaman dengan status 200 masuk antrean rendering. Halaman dengan status lain, misalnya 404, bisa dilewati. Dan ini bagian yang membuat banyak orang terjebak: kalau tag noindex sudah ada di HTML awal, Google bisa memutuskan tidak perlu merender halaman itu sama sekali. Artinya JavaScript yang tugasnya menghapus noindex tersebut tidak akan pernah dijalankan. Niatnya mengatur indexing secara dinamis, hasilnya halaman mati sebelum dibuka.

Pos Ketiga: Apakah Rendernya Berhasil

Rendering terjadi di Chromium versi headless. Ia modern, tapi ia bukan browser Anda. Tidak ada ekstensi, tidak ada cache yang hangat, tidak ada koneksi secepat kantor Anda. Satu permintaan API yang gagal atau timeout dan halaman itu selesai dirender dalam keadaan setengah jadi. Yang masuk index adalah versi setengah jadi itu, bukan versi yang Anda lihat.

Rata-rata jeda antara perayapan dan rendering sebenarnya hitungan detik, bukan hitungan hari seperti yang sering diceritakan. Tapi angka rata-rata menyesatkan di sini. Yang bikin repot adalah ekor panjangnya, sebagian kecil halaman yang antre jauh lebih lama, dan halaman-halaman itu biasanya justru halaman baru yang Anda paling butuh cepat terindeks.

Masalahnya Hampir Selalu Bukan JavaScript-nya

Ini bagian yang mungkin kurang populer, tapi saya pegang terus setelah bertahun-tahun: JavaScript bukan penyebab masalah SEO. Keputusan soal siapa yang menyusun HTML, itu penyebabnya.

React, Vue, Next, Nuxt, Svelte, semuanya bisa menghasilkan website yang menang di Google. Yang menentukan bukan nama framework-nya, tapi apakah HTML yang sampai ke crawler sudah berisi konten atau masih kosong. Pertanyaannya sesederhana itu, dan hampir tidak pernah ditanyakan di awal proyek.

Tahun 2023 saya pernah mengaudit sebuah website layanan B2B yang baru dibangun ulang. Developer-nya bagus, kodenya rapi, skor Lighthouse-nya tinggi. Tapi trafik organiknya turun sekitar 70 persen dalam dua bulan setelah rilis. Semua orang menduga penyebabnya kecepatan, atau struktur URL yang berubah, atau redirect yang salah. Saya cek HTML mentah satu halaman layanan. Isinya satu div dan satu bundle script. Seluruh isi halaman disusun di sisi pengunjung. Google menerima rumah kosong, lalu disuruh menebak isinya.

Perbaikannya tidak elegan dan tidak menyenangkan: halaman-halaman yang menargetkan keyword dipindah ke rendering sisi server. Butuh waktu, butuh argumen panjang dengan tim dev, dan tidak ada satu pun plugin yang bisa menyelesaikannya. Tapi itu satu-satunya yang menyentuh akar masalahnya.

Yang sering terjadi di lapangan, energi habis di tempat yang salah. Orang menghabiskan tiga minggu mengejar skor Core Web Vitals sementara separuh kontennya tidak pernah masuk index. Cepat tapi tidak terbaca tetap nol.

Empat Langkah Diagnosa: Dari Dugaan ke Bukti dalam Dua Puluh Menit

Sebagian besar perdebatan soal JavaScript SEO sebenarnya bisa diakhiri dengan data, bukan opini. Empat langkah ini urutannya sengaja saya susun dari yang paling murah ke yang paling mahal, supaya Anda berhenti begitu ketemu jawabannya. Jangan lompat ke langkah empat sebelum langkah satu beres, karena itu cara tercepat memperbaiki masalah yang tidak Anda punya.

Langkah 1: Bandingkan View Source dengan Inspect

Buka halaman yang bermasalah. Klik kanan, pilih View Page Source, bukan Inspect. Yang muncul adalah HTML mentah, versi yang pertama kali diterima Google. Cari satu kalimat spesifik dari isi artikel Anda di halaman itu dengan Ctrl+F.

Kalau kalimatnya ada, konten Anda dikirim dari server dan masalahnya di tempat lain. Kalau tidak ada, Anda sudah menemukan akarnya dalam waktu kurang dari satu menit.

Langkah 2: Lihat Rendered HTML di Search Console

Masuk ke URL Inspection di Search Console, tempel URL-nya, lalu buka tab HTML pada hasil live test. Ini yang paling mendekati apa yang benar-benar dilihat Google setelah rendering.

Bandingkan dengan hasil langkah satu. Kalau konten muncul di sini tapi tidak di View Source, berarti Google berhasil merender, dan risiko Anda ada di jeda antrean serta di halaman-halaman yang rendernya gagal diam-diam. Kalau di sini juga kosong, berarti rendering-nya memang gagal.

Langkah 3: Cek Screenshot dan Pesan Error

Di halaman hasil yang sama, Search Console menampilkan screenshot halaman dari sisi Google beserta daftar sumber daya yang gagal dimuat. Daftar itu sering diabaikan padahal isinya jawaban. Satu endpoint API yang kena blokir, satu font yang timeout, satu script pihak ketiga yang menghentikan eksekusi, semuanya muncul di situ.

Langkah 4: Petakan Status Indexing per URL, Bukan per Website

Baru setelah tiga langkah di atas, masuk ke laporan Page Indexing. Yang Anda cari bukan jumlah total, tapi status spesifik tiap URL. Crawled currently not indexed punya penyebab yang berbeda dari Discovered currently not indexed, dan keduanya minta tindakan yang berlawanan. Saya sudah menguraikan cara membaca status halaman yang tidak terindeks dan siapa yang sebenarnya memutuskan karena bagian ini paling sering jadi sumber tindakan yang sia-sia.

Kalau proses diagnosa seperti ini terasa makan waktu dan Anda lebih butuh jawabannya daripada prosesnya, biasanya memang lebih cepat diaudit langsung oleh orang yang sudah hafal polanya. Itu salah satu pekerjaan yang saya kerjakan lewat jasa SEO, dan untuk website berbasis framework JavaScript biasanya titik macetnya ketemu di hari pertama.

Lima Kesalahan yang Jarang Masuk Checklist

Checklist JavaScript SEO yang beredar umumnya menyebut sitemap, canonical, dan alt text. Benar, tapi itu bukan yang bikin website kehilangan trafik. Lima hal berikut yang saya temukan paling sering, dan hampir semuanya tidak ada di daftar populer.

Tautan yang bukan tautan. Elemen div atau span yang dibuat bisa diklik lewat JavaScript tidak akan diikuti Googlebot. Ia butuh elemen a dengan href berisi URL sebenarnya. Banyak menu navigasi modern gagal di titik ini, dan efeknya seluruh cabang halaman di bawahnya jadi yatim.

URL dengan tanda pagar. Routing yang memakai fragmen seperti /produk#detail tidak diperlakukan sebagai halaman terpisah. Pakai History API dengan URL yang sebenarnya. Ini masalah lama yang masih saya temukan di proyek baru.

Soft 404 di aplikasi satu halaman. Halaman yang tidak ada tetap mengembalikan status 200 karena server selalu mengirim shell yang sama, lalu JavaScript menampilkan tulisan “tidak ditemukan”. Google membaca status 200 dan menganggapnya halaman sah bernilai nol. Solusinya mengarahkan ke URL yang benar-benar mengembalikan 404 di server.

Aset lama yang masih dipakai saat render. Layanan rendering Google bisa mengabaikan header caching Anda dan memakai versi file yang kedaluwarsa. Makanya nama file build sebaiknya mengandung sidik jari konten, misalnya main.a7f3c2.js, supaya versi baru tidak pernah tertukar dengan versi lama.

Konten yang baru muncul setelah diklik. Tab, accordion, dan infinite scroll yang isinya baru diambil saat ada interaksi pengunjung sama saja dengan tidak ada bagi crawler. Googlebot tidak mengklik apa pun. Kalau isinya penting untuk ranking, isinya harus sudah ada sebelum ada interaksi.

Dari lima itu, nomor satu dan nomor tiga yang paling mahal menurut saya. Keduanya tidak memunculkan error di mana pun. Websitenya terlihat sehat sampai Anda sadar separuh halaman tidak pernah dikunjungi Google.

Yang Berubah di 2026: Googlebot Bisa Render, Crawler AI Tidak

Ini bagian yang membuat saya menulis ulang cara saya menjelaskan JavaScript SEO sepanjang tahun ini.

Selama bertahun-tahun, seluruh diskusi berpusat pada Googlebot. Dan Googlebot sudah cukup baik. Ia menjalankan JavaScript, jeda render-nya makin pendek, dan untuk banyak website rendering sisi pengunjung masih bisa lolos dengan luka ringan. Sampai sini banyak orang menyimpulkan bahwa JavaScript SEO sudah jadi masalah yang selesai.

Lalu sumber trafik bertambah. ChatGPT, Perplexity, dan asisten AI lain sekarang mengirim pengunjung, dan lebih penting lagi, membentuk persepsi orang tentang merek Anda sebelum mereka pernah mengetik nama Anda di Google. Masalahnya, crawler mesin-mesin itu berperilaku seperti Googlebot sepuluh tahun lalu. Pengujian independen yang paling banyak dikutip menunjukkan mereka mengambil HTML mentah dan tidak menjalankan JavaScript sama sekali. Salah satunya bahkan tercatat mengunduh file JavaScript dalam jumlah besar tanpa pernah menjalankan satu pun.

Konsekuensinya lugas. Website yang menyusun kontennya di sisi pengunjung bisa tetap muncul di Google, karena ringkasan AI milik Google disuapi oleh Googlebot yang memang merender. Tapi website yang sama praktis tidak terlihat oleh ChatGPT dan Perplexity. Bukan peringkatnya jelek. Kontennya tidak ada dari sudut pandang mereka.

Jadi pertanyaan yang dulu bisa dijawab “Google sudah bisa render, jadi aman” sekarang punya jawaban berbeda. Sekarang pertanyaannya adalah apakah Anda rela tidak hadir di kanal yang pertumbuhannya paling cepat, hanya karena HTML Anda kosong saat diambil.

Ada satu kesimpulan praktis dari sini yang jarang disebut: nilai rendering sisi server naik, bukan turun, justru di saat Googlebot makin canggih. Dan pilihan arsitektur jadi keputusan bisnis, bukan selera teknis. Saya sudah membahas sisi arsitekturnya lebih jauh di tulisan soal kapan headless CMS layak dipakai dan kapan justru merugikan SEO, termasuk strategi rendering mana yang cocok untuk tiap skala bisnis.

Satu catatan soal dynamic rendering, menyajikan versi berbeda khusus untuk crawler. Google sendiri sudah menyebutnya solusi sementara, bukan jawaban jangka panjang, dan mengarahkan orang ke rendering sisi server, rendering statis, atau hidrasi. Saya setuju sepenuhnya. Setiap kali saya menemukannya di proyek warisan, ia sudah rusak dan tidak ada yang sadar.

Satu Hal yang Bisa Anda Cek Sepuluh Menit dari Sekarang

Kalau Anda hanya mau mengerjakan satu hal setelah membaca ini, kerjakan yang ini. Ambil satu halaman yang paling penting untuk bisnis Anda, halaman layanan atau halaman produk utama. Buka View Page Source. Cari satu kalimat dari isi halaman itu.

Ketemu, bagus, Anda bisa tidur tenang untuk halaman itu dan lanjut memeriksa halaman berikutnya. Tidak ketemu, Anda baru saja menemukan alasan kenapa konten yang Anda bayar mahal tidak pernah memberi hasil.

Dari situ keputusannya jadi jauh lebih mudah, karena pertanyaannya berpindah dari “apa yang salah dengan SEO saya” menjadi “halaman mana saja yang perlu dipindah ke rendering sisi server, dan mana yang bisa dibiarkan”. Pertanyaan kedua ada jawabannya. Pertanyaan pertama tidak.

Kalau ternyata akar masalahnya ada di arsitektur dan perlu dibereskan dari fondasi, bukan ditambal, itu wilayah pekerjaan yang saya tangani lewat jasa web development. Detailnya bisa Anda cek di sana.

Pertanyaan yang Sering Muncul

Apakah Google benar-benar bisa membaca JavaScript? Bisa. Google menjalankan JavaScript memakai Chromium versi headless yang selalu diperbarui. Yang perlu diingat, rendering itu terjadi di tahap terpisah setelah perayapan, jadi hasilnya tidak selalu sama dengan apa yang Anda lihat di browser.

Framework mana yang paling SEO friendly? Tidak ada jawaban berdasarkan nama framework. React, Vue, maupun Svelte sama-sama bisa menghasilkan website yang menang asalkan HTML yang dikirim ke crawler sudah berisi konten. Yang menentukan mode rendering-nya, bukan logo di dokumentasinya.

Apakah rendering sisi pengunjung otomatis buruk untuk SEO? Tidak otomatis buruk, tapi risikonya lebih tinggi dan sekarang bertambah. Untuk halaman yang menargetkan keyword dan halaman yang ingin dikutip mesin AI, rendering sisi server atau statis jelas lebih aman.

Kenapa halaman saya terindeks tapi isinya tidak lengkap di hasil pencarian? Biasanya karena render berhasil sebagian. Satu permintaan data gagal atau terlalu lambat, lalu Google mengindeks halaman dalam keadaan setengah terisi. Cek daftar sumber daya yang gagal dimuat di URL Inspection.

Apakah mematikan JavaScript di browser cara yang sah untuk mengetes? Tidak. Itu mensimulasikan crawler yang tidak bisa render sama sekali, dan Googlebot bukan itu. Pakai View Page Source untuk melihat HTML mentah dan URL Inspection untuk melihat hasil render.

Kalau sudah pakai rendering sisi server, apakah urusannya selesai? Belum, tapi bagian tersulitnya selesai. Yang masih perlu dijaga adalah tautan yang benar-benar berupa elemen a, status HTTP yang jujur, dan konten penting yang tidak disembunyikan di balik interaksi pengunjung.

en_USEnglish