SEO JavaScript: pastikan tautan bertahan setelah rendering
Google merender JavaScript dengan Chromium evergreen. Masalahnya jarang terjadi pada proses rendering itu sendiri. Masalahnya adalah tautan yang tidak pernah menjadi jangkar, dan halaman yang bergantung pada state yang tidak dimiliki crawler.
Tim riset ArchiLinks ·
Apa yang dilihat oleh crawler
Googlebot telah menggunakan Chromium evergreen sejak Mei 2019. Hal ini menyelesaikan pertanyaan apakah browser tersebut dapat menjalankan JavaScript modern.
Risiko praktisnya adalah risiko lama: rendering terjadi setelah crawling dan dapat tertunda, konten di balik klik atau login tidak pernah muncul, dan tautan yang dibangun dari handler onclick pada div bukanlah tautan. Sebelum memeriksa backlink pada halaman situs web yang baru saja Anda pindahkan ke front-end React, pastikan halaman-halaman tersebut menampilkan konten mereka dalam respons mentah atau dalam HTML yang telah dirender.
SSR, SSG, CSR: apa yang berubah untuk tautan
| Pendekatan | Konten dalam respons pertama | Tautan internal sebagai jangkar | Cocok untuk |
|---|---|---|---|
| SSR (Next.js, Nuxt) | Ya | Ya, jika Anda menggunakan jangkar asli | Halaman publik dengan data yang berubah-ubah |
| SSG atau prarender | Ya | Ya | Dokumentasi, blog, halaman pemasaran |
| Aplikasi single-page CSR | Tidak, shell kosong | Hanya setelah proses rendering | Dasbor di balik login |
| Hibrida (SSR untuk halaman utama, CSR untuk aplikasi) | Per rute | Per rute | Sebagian besar produk dengan sisi publik |
Uji satu: HTML mentah versus HTML yang telah dirender
Jika tautan utama muncul dalam respons pertama, pertanyaannya sudah terjawab. Jika tidak, bandingkan dengan hasil render headless.
# raw response: are the links there?
curl -s https://new-shop.com/guides/ | grep -o '<a [^>]*href="[^"]*"' | head -20
# rendered DOM with headless Chrome
chrome --headless --dump-dom https://new-shop.com/guides/ | grep -c '<a '
Di mana tautan eksternal masuk
Bug rendering menyembunyikan konten Anda. Hal ini tidak menghapus tautan yang sudah diberikan oleh situs lain.
Setelah migrasi ke Next.js, Vite, atau CMS headless, jalankan toppages untuk host tersebut dan uji 20 URL dengan tautan terbanyak untuk status, kanonik, dan konten yang terlihat. Lakukan ini terlebih dahulu. Jika halaman dengan 40 domain penaut mengembalikan cangkang kosong atau 404 sisi klien, perbaiki segera sebelum hal lain, karena di situlah otoritas Anda terkonsentrasi. Halaman ekuitas tautan internal vs eksternal menunjukkan cara membandingkan daftar tersebut dengan tautan internal Anda, dan daftar periksa migrasi mengintegrasikan pengujian ini ke dalam rencana peluncuran.
Kerangka kerja kurang penting daripada disiplin. Express dengan mesin template, tema WordPress, dan router aplikasi Next.js semuanya dapat menyajikan tautan yang dapat di-crawl. Masing-masing juga dapat gagal jika tim mengirimkan jangkar yang hanya muncul setelah klik.
Daftar periksa tautan dan rendering
- Navigasi dan paginasi menggunakan
<a href>, bukan penangan klik pada elemen lain. - Setiap rute mengembalikan kode status yang sebenarnya. Layar 404 lunak harus mengembalikan 404.
noindexatau kanonik yang disuntikkan oleh JavaScript harus sesuai dengan yang ada dalam respons server.- Konteks cadangan dalam respons pertama adalah halaman yang sebenarnya, bukan indikator pemuatan yang mungkin diindeks oleh Google.
- Kode autentikasi tidak mengarahkan crawler pada rute publik.
- File CSS dan JS yang diperlukan untuk rendering tidak diblokir di robots.txt.
- Pemuatan lambat menggunakan IntersectionObserver atau atribut pemuatan bawaan, bukan peristiwa gulir.
Membaca bukti dari Search Console
Search Console menjawab sebagian besar pertanyaan tentang rendering jika Anda meminta laporan yang tepat. Gunakan Inspeksi URL, lalu Lihat halaman yang di-crawl.
Bandingkan tiga hal: HTML yang diambil Google, tangkapan layar, dan sumber daya halaman yang gagal dimuat. Halaman yang tampak lengkap di browser Anda tetapi kosong dalam tangkapan layar biasanya diblokir oleh kesalahan skrip atau sumber daya yang tidak diizinkan, dan solusinya ada di dalam build Anda, bukan di konten Anda.
Ingatlah tentang penundaan. Perubahan yang Anda terbitkan hari ini hanya akan muncul di alat inspeksi setelah Google melakukan peng-crawlan ulang terhadap URL tersebut, yang bisa memakan waktu beberapa hari.
Kapan SSR layak digunakan
Halaman publik yang harus peringkat: ya. Dashboard: tidak.
Jika sebuah rute harus mendatangkan lalu lintas organik, sajikan konten dalam respons pertama. Jika berada di balik login, lewati kompleksitasnya. Pilih per rute dan bukan per proyek, serta dokumentasikan keputusan tersebut agar pengembang berikutnya tidak membatalkannya.
- Gunakan pengujian Rich Results dan URL Inspection untuk membandingkan hasil render.
- Uji dengan pengujian langsung di Search Console setelah setiap pembaruan framework.
Apakah rendering server diperlukan, atau apakah prerendering sudah cukup?
Rendering server bersifat opsional. Ini adalah cara agar respons pertama memuat apa yang dibutuhkan crawler. Banyak situs publik mencapainya dengan prerendering, build statis, atau render server untuk halaman-halaman penting, dan membiarkan bagian yang memerlukan login tetap di sisi klien.
Misalkan halaman produk dan dokumentasi Anda bersifat publik, sementara dashboard berada di balik login. Prerender kelompok pertama. Biarkan dashboard tetap di sisi klien. Halaman publik kemudian akan menyertakan tautannya dalam respons pertama, sementara dashboard dapat tetap sekompleks yang diperlukan.
Prerendering hanya halaman beranda
Prerendering halaman beranda mengatasi proses crawl pertama, tetapi membuat setiap rute lain menunggu di browser. Jika halaman beranda menautkan ke halaman kategori yang di-render di sisi klien, tautan di halaman-halaman tersebut masih bergantung pada proses rendering. Periksa setiap template yang Anda miliki, bukan hanya halaman depan.
Simpan daftar singkat rute publik beserta metode rendernya. Daftar ini akan menunjukkan celah lebih cepat dibandingkan laporan crawl.
Apakah rendering server mengubah visibilitas lokal
Rendering server dapat mengubah seberapa cepat konten pertama muncul, dan pembaca merasakannya. Hal ini tidak membuat halaman relevan untuk kueri lokal secara otomatis. Sinyal tersebut berasal dari konten halaman, detail bisnis, dan tautan yang mengarah ke halaman tersebut.
Perlakukan rendering sebagai cara agar sinyal-sinyal tersebut dapat dibaca oleh crawler, dan ukur tautan secara terpisah menggunakan API.
Aplikasi Vite dan React yang menyajikan satu shell
Build Vite yang menyajikan satu shell HTML untuk setiap path membebani sisi klien. Aplikasi seperti itu masih dapat peringkat untuk beberapa kueri, tetapi setiap rute publik memerlukan rencana: prerender, render di server, atau terima kerugian tersebut dan tuliskan keputusannya.
Sebelum memeriksa backlink pada rute situs setelah build ulang, tentukan bagaimana setiap rute publik mendapatkan kontennya. Jika tidak, data tautan akan menunjukkan tautan eksternal yang mengarah ke halaman kosong.
Menguji apakah sebuah rute menampilkan tautannya
Dua pengujian menjawab sebagian besar pertanyaan. Respons mentah menunjukkan apa yang diterima crawler sebelum skrip apa pun dijalankan. DOM yang di-render menunjukkan apa yang dibangun browser setelahnya. Tautan yang hanya muncul di yang kedua tetap merupakan tautan, tetapi bergantung pada keberhasilan proses rendering.
Membaca pengujian langsung di Search Console
Jalankan pengujian langsung dari URL Inspection pada satu rute sekaligus. Lihat HTML yang di-render, lalu daftar sumber daya yang gagal dimuat. Skrip yang diblokir dapat menghapus seluruh blok navigasi, dan halaman terlihat tipis tanpa menampilkan kesalahan yang terlihat.
Ulangi pengujian setelah pembaruan framework, karena pengaturan default baru dapat mengubah apakah tautan di-render sebelum atau setelah skrip dijalankan. Panduan halaman tidak diindeks mencakup langkah-langkah yang harus dilakukan ketika halaman yang sudah di-render masih belum terindeks.
Ketika sebuah rute di-render tetapi kontennya hanya spinner
Fallback dalam respons pertama lebih penting daripada yang diharapkan sebagian besar tim. Spinner atau wadah kosong berarti halaman tidak memuat teks apa pun untuk crawler pada saat itu. Masukkan judul, pengantar, dan tautan utama dalam respons pertama, meskipun daftar detail dimuat kemudian.
Fallback yang merupakan halaman asli dapat tetap sederhana. Tugas utamanya hanyalah menahan konten hingga bagian lain tiba.
Memindahkan situs sisi klien tanpa kehilangan tautannya
Daftar rute dengan tautan eksternal
Jalankan toppages untuk host dan catat 50 URL teratas. Uji rute-rute tersebut terlebih dahulu, sebelum perubahan kode, agar Anda mengetahui apa yang harus dipertahankan oleh build ulang.
Bandingkan output mentah dan yang di-render
Untuk setiap rute, periksa HTML mentah dan DOM yang di-render pada build lama dan baru. Catat tautan apa pun yang ada di satu sisi tetapi tidak di sisi lainnya.
Ganti penangan klik dengan anchor
Ubah navigasi menjadi anchor sungguhan dengan alamat yang sesuai. Pekerjaan kecepatan dapat ditunda ke sprint berikutnya, sementara anchor yang hilang dapat menghilangkan jalur halaman ke dalam situs.
Ulangi pengujian setelah peluncuran
Satu minggu setelah peluncuran, jalankan pengujian langsung pada rute yang sama dan bandingkan hasilnya dengan yang sebelumnya. Perbedaan menunjukkan di mana build mengubah output.
Kode status dan redirect dalam aplikasi sisi klien
Aplikasi single-page sering menampilkan layar not-found sementara server mengembalikan status 200. Google dapat memperlakukan halaman seperti itu sebagai soft 404, dan tautan eksternal yang mengarah ke URL yang hilang tersebut tidak banyak membantu Anda. Perbaikannya berada di sisi server.
Rute tidak dikenal yang masih mengembalikan 200
Kembalikan 404 sungguhan dari server untuk rute apa pun yang tidak ada, dan pertahankan layar not-found di aplikasi untuk pengunjung yang tiba melalui rute sisi klien. Jika ada pengganti, kirimkan 301.
Periksa beberapa alamat buatan di host langsung setelah setiap peluncuran. Kode respons adalah hal yang harus dibaca, bukan halaman yang Anda lihat di browser.
Redirect yang berjalan di browser
Redirect yang dipicu setelah halaman dimuat, misalnya dengan membaca parameter URL di dalam komponen, adalah hal yang berbeda dari redirect server. Crawler mungkin mengindeks respons pertama sebelum redirect berjalan. Jika sebuah rute telah berpindah secara permanen, kembalikan 301 dari server dan pertahankan parameter yang mengubah konten. Reseta peta redirect menunjukkan cara menguji aturan-aturan tersebut.
