Audit SEO Teknis: Crawl, Pengindeksan, Arsitektur, Core Web Vitals

Sebagian besar "audit SEO teknis" berakhir sebagai PDF 200 halaman yang tersimpan di folder Google Drive yang tidak pernah dibuka siapa pun. Tim engineering mengabaikannya karena membacanya seperti makalah akademis: inventaris masalah tanpa triage, tanpa template tiket, dan tanpa estimasi trafik yang terlampir pada setiap perbaikan.

Inilah versi IC-nya. Lima area fokus, diagnosis yang disebutkan namanya, dan antrean tiket pengembang yang benar-benar akan diambil oleh engineering di sprint berikutnya. Nilai audit ini bukan pada presentasinya. Nilainya ada pada PR yang sudah di-merge.

Jika Anda meninggalkan audit kuartalan dengan spreadsheet 47 tab tapi tanpa satu pun commit, Anda baru saja menjalankan proyek riset, bukan audit.

Kerangka Audit 5 Area

Setiap audit teknis yang saya jalankan mencakup lima area yang sama, dalam urutan ini, karena ketergantungannya mengalir ke bawah: tidak ada gunanya mengoptimalkan CWV pada halaman yang tidak bisa dirayapi Google, dan tidak ada gunanya memperbaiki schema pada halaman yang tidak terindeks. Kerjakan funnelnya.

1. Kemampuan dirayapi
2. Cakupan indeks
3. Arsitektur dan tautan internal
4. Core Web Vitals
5. Data terstruktur

Anda bisa menyelesaikan tahap pertama dalam dua hari kerja fokus untuk situs dengan kurang dari 50.000 URL. Untuk yang lebih besar, rencanakan seminggu dan andalkan lebih banyak pada pengambilan sampel log.

1. Kemampuan Dirayapi

Alat: Screaming Frog atau Sitebulb untuk crawl penuh, log server untuk apa yang benar-benar diambil oleh Googlebot, penguji robots.txt di GSC.

Mulailah dengan robots.txt. Baca baris per baris. Kemudian periksa apa yang diblokir di tingkat direktori versus tingkat pola. Kesalahan klasik yang saya temukan setidaknya sekali per kuartal:

• Aturan staging bocor ke produksi. Seseorang menyalin Disallow: / dari staging ke robots.txt produksi saat deployment. Seluruh situs menjadi gelap dalam 48 jam. Perbaikannya hanya dua karakter. Dampaknya berlangsung enam minggu.
• Rute /api/ tidak sengaja diblokir padahal melayani konten yang di-hydrate. Beberapa aplikasi Next.js dan Nuxt mengambil dari /api/... untuk data ISR atau SSR. Jika endpoint tersebut diblokir, Googlebot melihat halaman yang setengah dirender pada tahap kedua.
• CSS dan JS diblokir. Masih terjadi. Googlebot perlu merender halaman. Jika tidak bisa memuat stylesheet Anda, pemeriksaan mobile-friendliness gagal dan peringkat turun.
• Disallow pada navigasi berfaset yang juga merupakan tempat 60% trafik long-tail berada. Umum di e-commerce. Blokir URL parameter di robots.txt dan Anda juga memblokir sinyal canonical yang seharusnya mengkonsolidasikannya.

Setelah robots.txt, jalankan crawl Screaming Frog penuh dengan rendering JavaScript diaktifkan. Bandingkan HTML yang dirender dengan HTML mentah. Jika versi yang dirender memiliki 3.000 kata lebih banyak dari yang mentah, Anda memiliki masalah rendering JS. (Lebih lanjut di bawah.)

Kemudian sampel log server Anda. Dua minggu log akses yang difilter ke user agent Googlebot. Kelompokkan berdasarkan kode status dan pola URL. Anda mencari:

• Error 5xx yang menghantam Googlebot (server tidak mampu mengikuti laju crawl)
• Soft 404 (status 200 dengan konten "halaman tidak ditemukan")
• Jebakan crawl (kombinasi parameter tak terbatas pada navigasi berfaset, widget kalender yang berakhir di tahun 3024, ID sesi dalam URL)

Anggaran perayapan hanya penting pada situs dengan lebih dari 100.000 URL. Jika Anda adalah situs SaaS dengan 800 halaman, berhentilah khawatir tentang anggaran perayapan dan pikirkan mengapa 12 dari 800 halaman itu menghasilkan 90% trafik organik.

2. Cakupan Indeks

Alat: Laporan Index Coverage GSC (sekarang laporan Pages), Screaming Frog yang membandingkan yang dirayapi vs yang terindeks.

Buka laporan Pages di GSC. Filter ke "Not indexed." Baca setiap alasan status. Dua yang paling sering mengirimkan bug regresi:

• "Discovered, currently not indexed." Google menemukan URL tapi belum mengambilnya. Biasanya berarti prioritas crawl rendah (konten tipis, tautan internal lemah) atau situs di server yang lambat.
• "Crawled, currently not indexed." Google mengambilnya dan memutuskan untuk tidak mengindeks. Ini adalah sinyal kualitas. Konten tipis, hampir-duplikat, dan halaman yang dianggap Google bernilai rendah semuanya masuk sini. Memperbaiki ini adalah masalah konten, bukan masalah teknis. Jangan buat tiket ke tim engineering untuk "Crawled, not indexed."

Sekarang yang klasik:

• Noindex pada halaman penting. Kesalahan canonical yang membuat diri sendiri rugi. Seseorang menambahkan <meta name="robots" content="noindex"> ke file layout yang digunakan seluruh direktori /blog/ dan trafik anjlok dalam 30 hari. Saya pernah melihat ini terjadi dari pengembang yang menguji satu artikel dan lupa mengembalikan perubahan layout. Selalu grep basis kode untuk noindex saat audit. Selalu.
• Ketidaksesuaian canonical. Halaman A memiliki <link rel="canonical" href="page-b">, halaman B memiliki <link rel="canonical" href="page-a">. Google memilih satu dan mengabaikan yang lain, tapi mana yang dipilih adalah keberuntungan. Perbaikan: setiap halaman melakukan canonical ke dirinya sendiri kecuali Anda memiliki alasan konsolidasi yang disengaja.
• Penanganan parameter. Parameter UTM, ID sesi, urutan pengurutan, kombinasi filter. Setiap varian adalah URL terpisah bagi Google kecuali Anda melakukan canonical. Aturan default: setiap URL berparameter melakukan canonical ke URL dasar yang bersih. Ganti hanya untuk parameter yang mengubah konten secara bermakna (seperti varian produk).
• Error hreflang. Jika Anda menjalankan multi-bahasa, error return-tag hreflang berdampak berantai. Laporan International Targeting di GSC masih menampilkan ini.

Pemeriksaan kewarasan: lakukan site:domainkamu.com di Google. Angka yang dikembalikan seharusnya kira-kira sesuai dengan jumlah terindeks GSC Anda (dalam 20%). Jika site: menampilkan 12.000 dan GSC menampilkan 4.000, ada yang tidak beres dan celahnya biasanya adalah URL parameter yang diindeks Google sebelum Anda melakukan canonical pada mereka.

3. Arsitektur dan Tautan Internal

Alat: Sitebulb (terbaik di kelasnya untuk memvisualisasikan kedalaman situs), laporan kedalaman crawl Screaming Frog.

Tiga diagnosis, diurutkan berdasarkan seberapa sering saya menemukannya dalam audit:

Kedalaman dari halaman utama. Apa pun yang lebih dari empat klik dari halaman utama adalah tanda peringatan. Jalankan crawl Screaming Frog, urutkan berdasarkan kedalaman crawl menurun. Halaman di kedalaman 6 ke atas biasanya adalah halaman yatim atau terjebak oleh navigasi yang buruk. Jika halaman produk dengan pendapatan tertinggi Anda berada di kedalaman 5, Anda memiliki bug arsitektur, bukan bug konten.

Halaman yatim. Halaman dengan nol tautan internal masuk. Sitebulb memiliki laporan khusus. Penyebab umum: halaman landing lama dari kampanye, posting blog yang lupa ditautkan tim editorial dari mana pun, halaman produk yang diluncurkan tanpa pembaruan navigasi. Tautkan ke sana dari hub yang relevan atau tambahkan noindex. Jangan biarkan membusuk.

Distribusi tautan internal. Jalankan hitungan tautan internal per URL di Screaming Frog. Plot distribusinya. Anda mencari ekor panjang halaman dengan 0-2 tautan internal. Halaman-halaman tersebut akan sulit berperingkat tidak peduli seberapa bagus kontennya. Struktur hub-and-spoke (halaman pilar ke klaster artikel terkait) adalah perbaikan paling bersih: setiap artikel klaster menautkan ke halaman pilar, halaman pilar menautkan kembali ke setiap artikel klaster.

Jebakan navigasi berfaset. Jika Anda adalah e-commerce atau marketplace, navigasi berfaset bisa menghasilkan jutaan kombinasi URL. Pohon keputusannya:

• Filter yang mengubah konten secara bermakna (kategori, merek) → dapat diindeks, canonical ke diri sendiri
• Filter yang hanya mengurutkan atau membuat paginasi → noindex atau canonical ke kategori dasar
• Filter kombinasi (kategori + merek + harga + ukuran) → blokir di robots.txt atau gunakan AJAX agar tidak menghasilkan URL yang bisa dirayapi

Breadcrumb. Setiap halaman konten harus memiliki komponen breadcrumb yang terlihat, ditandai dengan schema BreadcrumbList. Breadcrumb membantu pengguna berorientasi, memberi Google sinyal struktural tambahan, dan mendapatkan tampilan breadcrumb di SERP.

4. Core Web Vitals

Alat: PageSpeed Insights untuk data lab dan lapangan, Lighthouse untuk pengujian lab yang dapat direproduksi, panel Performa Chrome DevTools untuk diagnosis, laporan Core Web Vitals GSC untuk pemantauan.

Ambang batasnya penting. Hafalkan:

Selalu ukur pada data lapangan (CrUX, angka pengguna nyata di PageSpeed Insights dan GSC), bukan lab. Angka lab bercerita kepada Anda; angka lapangan menceritakan kebenaran. Lab bisa lulus sementara CrUX gagal karena pengguna nyata menggunakan jaringan yang lebih lambat dan perangkat yang lebih lama.

Urutkan perbaikan berdasarkan level. Setiap metrik memiliki tangga yang jelas:

Perbaikan LCP (urutan berdasarkan upaya vs dampak):

Perbaikan INP:

Perbaikan CLS:

Jalankan PageSpeed Insights pada 10 template teratas Anda (halaman utama, posting blog, kategori, produk, harga, dll.), bukan pada URL individual. Template adalah tempat Anda mengirimkan perbaikan sekali dan perbaikan itu menyebar.

5. Data Terstruktur

Alat: Laporan Rich Results GSC, validator schema.org, ekstraksi data terstruktur Screaming Frog.

Pemeriksaan cakupan. Setiap jenis konten harus memiliki schema yang sesuai:

• Artikel → Article atau BlogPosting
• Halaman produk → Product dengan Offer
• Halaman FAQ → FAQPage
• Organisasi (halaman utama dan footer) → Organization
• Breadcrumb (setiap halaman) → BreadcrumbList
• Konten cara melakukan → HowTo

Jalankan Screaming Frog dengan ekstraksi data terstruktur diaktifkan. Filter ke URL dengan error atau jenis yang hilang. Silang referensi dengan laporan Rich Results GSC. Itulah sumber kebenaran untuk apa yang divalidasi Google.

Aspek AEO (optimisasi mesin jawaban) semakin penting setiap kuartal. Sistem pencarian berbasis LLM sangat mengandalkan data terstruktur saat memutuskan konten mana yang dikutip. Halaman FAQ dengan schema FAQPage yang valid dan pasangan T&J yang bersih dikutip oleh ChatGPT, Perplexity, dan AI Overviews Google jauh lebih andal daripada konten yang sama tanpa schema. Schema bukan sekadar untuk rich snippet lagi. Ini adalah cara mesin memutuskan halaman Anda membahas tentang apa.

Realitas Rendering JS

Jika situs Anda adalah SPA yang dibangun di atas React, Vue, Svelte, atau Angular tanpa SSR atau SSG, Anda bermain di mode sulit.

Googlebot melakukan render dua tahap. Tahap pertama: ia melihat respons HTML awal Anda. Untuk SPA yang belum dirender, itu hampir berupa <div id="root"></div> kosong dengan tag skrip. Tahap kedua: jam hingga minggu kemudian, ketika antrean render Google memiliki kapasitas, ia mengambil ulang dan menjalankan JS. Konten diindeks, pada akhirnya.

Diagnosis "halaman kosong di Screaming Frog": jalankan Screaming Frog dengan rendering JS dimatikan. Jika halaman Anda mengembalikan 200 OK dengan <body> kosong, itulah yang dilihat Googlebot pada tahap pertama. Sekarang jalankan dengan rendering JS diaktifkan. Jika konten muncul, Google akan sampai ke sana pada akhirnya. Jika tidak, Anda memiliki bug yang lebih dalam (dinding autentikasi, hydration yang rusak, error JS yang menghalangi render).

Kapan ini penting:

• Konten berita dan tren. Jika Anda bergantung pada Googlebot mengindeks dalam 24 jam, penundaan tahap kedua akan mematikan Anda. SSR atau SSG, tanpa pengecualian.
• Katalog besar. Situs e-commerce dengan 50.000 produk yang menggunakan client-side rendering akan melihat anggaran perayapan habis di antrean render. Google memutuskan halaman mana yang layak untuk tahap kedua.
• Halaman dengan pembatasan autentikasi. Jika logika hydration Anda mengalihkan pengguna yang tidak terautentikasi (yang merupakan Googlebot), Google melihat pengalihan, bukan konten Anda.

Pohon keputusannya:

• Jika Anda adalah situs konten → SSG (Next.js, Astro, Eleventy)
• Jika Anda adalah aplikasi produk → SSR untuk halaman marketing, CSR untuk aplikasi itu sendiri
• Jika migrasi terlalu mahal → prerendering (Prerender.io, Rendertron) sebagai solusi sementara

Minta tim engineering untuk mencatat header User-Agent pada kegagalan render. Jika Anda melihat Googlebot di sana, Anda punya bukti untuk dibawa ke sesi perencanaan sprint.

Mengemas Temuan sebagai Tiket Pengembang

Di sinilah sebagian besar audit gagal. Temuannya nyata. Tiket tidak pernah ditulis. Engineering memilih tugas termudah dari backlog karena tidak ada yang melampirkan dampak bisnis pada audit Anda.

Hasilnya adalah antrean tiket yang diprioritaskan. Pembagian standar saya untuk audit kuartalan:

• 3 P0 (masalah yang menghalangi pengindeksan). Situs tidak bisa berperingkat jika ini tidak diperbaiki. Contoh: noindex pada halaman penting, disallow robots.txt pada direktori yang bisa diindeks, tag canonical yang mengarah ke URL 404.
• 8 P1 (kegagalan Core Web Vitals dan masalah arsitektur). Contoh: LCP > 4 dtk pada template teratas, tidak ada tautan internal ke halaman pendapatan, navigasi berfaset yang menghasilkan jebakan crawl.
• 20 P2: kesenjangan schema, pembersihan hreflang, penulisan ulang deskripsi meta, alt text gambar, pemolesan arsitektur minor.

Setiap tiket memerlukan field yang sama:

Judul: [SEO P0] Tag meta noindex pada layout /blog/*

Pola URL: Semua URL yang cocok dengan /blog/*
Langkah reproduksi:
  1. Kunjungi https://contoh.com/blog/posting-manapun
  2. Lihat sumber halaman
  3. Temukan <meta name="robots" content="noindex"> di <head>
Yang diharapkan: tag noindex seharusnya tidak ada pada posting blog yang bisa diindeks
Bukti: Screenshot dari view-source, laporan Pages GSC menampilkan 247 URL
  dengan status "Excluded by 'noindex' tag"
Estimasi dampak trafik: 247 URL saat ini dikecualikan. 20 teratas dari URL tersebut
  berada di posisi 4-15 sebelum noindex ditambahkan (data Ahrefs).
  Estimasi pemulihan: 8.000-12.000 kunjungan organik bulanan dalam 60 hari
  setelah perbaikan + pengindeksan ulang.
Penerimaan: File layout tidak lagi merender tag noindex untuk /blog/*.
  Jumlah "Excluded by noindex" di laporan Pages GSC berkurang minimal 240.

Engineering akan mengambil tiket yang tertulis seperti itu. Mereka tidak akan mengambil tiket yang tertulis seperti "Perbaiki masalah pengindeksan di blog."

Kadence Audit

Audit mendalam kuartalan mencakup semua lima area. Dua hari kerja fokus, ditambah seminggu untuk menulis tiket dan memandu mereka melalui perencanaan sprint. Setiap kuartal.

Pemeriksaan cakupan indeks bulanan. Buka laporan Pages GSC pada Senin pertama setiap bulan. Bandingkan dengan snapshot bulan sebelumnya. Selidiki kategori "Not indexed" yang tumbuh lebih dari 10%.

Pemindaian regresi CWV mingguan. Laporan Core Web Vitals GSC. Template apa pun yang beralih dari "Good" ke "Needs Improvement" diselidiki dalam minggu itu. Menangkap regresi CWV pada 1 minggu adalah perbaikan 1 jam. Menangkap pada 8 minggu setelah rilis adalah penggalian multi-sprint.

Pengambilan sampel log server: kuartalan sudah cukup untuk sebagian besar situs, bulanan untuk situs dengan lebih dari 500.000 URL.

Audit bukan hasil kerja satu kali. Ini adalah kadence operasional. Yang pertama membutuhkan lebih banyak usaha karena Anda menetapkan baseline. Pada kuartal ketiga, sebagian besar waktu Anda digunakan untuk pemindaian regresi dan triage masalah baru, bukan re-audit penuh.

Kirimkan perbaikan, bukan temuan. Audit hanya sebagus PR yang sudah di-merge.

Pelajari Lebih Lanjut

• Daftar Periksa SEO On-Page untuk Halaman Pilar
• Strategi Tautan Internal untuk B2B SaaS
• Schema Markup untuk B2B SaaS
• Alur Kerja GSC Mingguan