Audit SEO Teknikal: Perangkak, Pengindeksan, Seni Bina, Core Web Vitals

Kebanyakan "audit SEO teknikal" akhirnya menjadi PDF 200 halaman yang disimpan dalam folder Google Drive yang tidak pernah dibuka sesiapa. Pasukan jurutera mengabaikannya kerana ia dibaca seperti kertas akademik: inventori isu tanpa pengisihan, tanpa templat tiket, dan tanpa anggaran trafik yang dilampirkan pada pembetulan.

Inilah versi IC. Lima kawasan fokus, diagnosis yang dinamakan, dan antrian tiket dev yang akan jurutera anda ambil dalam sprint seterusnya. Nilai audit bukan pada dek persembahan. Nilai audit adalah pada PR yang digabungkan.

Jika anda keluar dari audit suku tahunan dengan spreadsheet 47 tab tetapi tanpa commit, anda telah menjalankan projek penyelidikan, bukan audit.

Rangka Kerja Audit 5 Kawasan

Setiap audit teknikal yang saya jalankan meliputi lima kawasan yang sama, dalam urutan ini, kerana kebergantungan berjalan ke bawah: tidak ada gunanya mengoptimumkan CWV pada halaman yang tidak dapat diperangkak oleh Google, dan tidak ada gunanya membaiki schema pada halaman yang tidak diindeks. Kerjakan dari atas ke bawah.

1. Kebolehrangkakan
2. Liputan indeks
3. Seni bina dan pautan dalaman
4. Core Web Vitals
5. Data berstruktur

Anda boleh menyelesaikan laluan pertama dalam dua hari fokus untuk laman di bawah 50K URL. Apa-apa yang lebih besar, rancang seminggu dan bergantung lebih pada pensampelan log.

1. Kebolehrangkakan

Alat: Screaming Frog atau Sitebulb untuk perangkak penuh, log pelayan untuk apa yang Googlebot benar-benar ambil, penguji robots.txt dalam GSC.

Mulakan dengan robots.txt. Baca baris demi baris. Kemudian semak apa yang disekat pada peringkat direktori berbanding peringkat corak. Kesilapan klasik yang saya lihat sekurang-kurangnya sekali setiap suku tahun:

• Peraturan staging tersebar ke produksi. Seseorang menyalin Disallow: / dari staging ke dalam robots.txt produksi semasa deploy. Seluruh laman menjadi gelap dalam 48 jam. Pembetulannya dua aksara. Kerosakan mengambil masa enam minggu untuk pulih.
• Laluan /api/ terdisallow secara tidak sengaja apabila ia menyajikan kandungan yang dihidrat. Sesetengah aplikasi Next.js dan Nuxt mengambil dari /api/... untuk data ISR atau SSR. Jika titik akhir tersebut disekat, Googlebot melihat halaman yang separuh dipaparkan pada laluan kedua.
• CSS dan JS disekat. Masih berlaku. Googlebot perlu memaparkan halaman. Jika ia tidak dapat memuatkan stylesheet anda, pemeriksaan mesra mudah alih gagal dan kedudukan carian merosot.
• Disallow pada navigasi bersisi yang juga merupakan tempat 60% trafik ekor panjang berada. Biasa dalam e-dagang. Sekat URL parameter dalam robots.txt dan anda juga telah menyekat isyarat canonical yang sepatutnya menyatukan mereka.

Selepas robots.txt, jalankan perangkak Screaming Frog penuh dengan pemaparan JavaScript diaktifkan. Bandingkan HTML yang dipaparkan dengan HTML mentah. Jika versi yang dipaparkan mempunyai 3,000 perkataan lebih daripada mentah, anda mempunyai masalah pemaparan JS. (Lebih lanjut mengenai perkara itu di bawah.)

Kemudian sampel log pelayan anda. Dua minggu log akses ditapis kepada ejen pengguna Googlebot. Kumpulkan mengikut kod status dan corak URL. Anda mencari:

• Ralat 5xx yang mengenai Googlebot (pelayan tidak dapat mengekalkan kadar perangkak)
• 404 lembut (status 200 dengan kandungan "halaman tidak ditemui")
• Perangkap perangkak (kombinasi parameter infiniti pada navigasi bersisi, widget kalendar yang pergi ke tahun 3024, ID sesi dalam URL)

Bajet perangkak hanya penting pada laman melebihi 100K URL. Jika anda adalah laman SaaS dengan 800 halaman, berhenti bimbang tentang bajet perangkak dan bimbang tentang mengapa 12 daripada 800 halaman itu mendorong 90% trafik organik.

2. Liputan Indeks

Alat: Laporan Halaman GSC (dahulunya Index Coverage), Screaming Frog membandingkan diperangkak vs diindeks.

Buka laporan Halaman GSC. Tapis kepada "Tidak diindeks." Baca setiap sebab status. Dua yang menghantar paling banyak bug regresi:

• "Ditemui, belum diindeks." Google menjumpai URL tetapi belum mengambilnya. Biasanya bermakna keutamaan perangkak rendah (kandungan nipis, pautan dalaman lemah) atau laman pada pelayan yang perlahan.
• "Diperangkak, belum diindeks." Google mengambilnya dan memutuskan tidak mengindeksnya. Ini adalah isyarat kualiti. Kandungan nipis, hampir pendua, dan halaman yang Google anggap bernilai rendah semuanya berada di sini. Membaiki ini adalah masalah kandungan, bukan masalah teknikal. Jangan tiketkan pasukan dev untuk "Diperangkak, tidak diindeks."

Kini klasik-klasik:

• Noindex pada halaman penting. Kesilapan canonical yang terkenal. Seseorang menambah <meta name="robots" content="noindex"> pada fail layout yang digunakan oleh seluruh direktori /blog/ dan trafik jatuh dalam 30 hari. Saya pernah melihat ini dihantar oleh dev yang menguji satu artikel dan lupa untuk mengembalikan perubahan layout. Sentiasa grep codebase untuk noindex semasa audit. Sentiasa.
• Ketidakpadanan canonical. Halaman A mempunyai <link rel="canonical" href="page-b">, halaman B mempunyai <link rel="canonical" href="page-a">. Google memilih satu dan mengabaikan yang lain, tetapi ia adalah pilihan rawak. Penyelesaian: setiap halaman canonical kepada dirinya sendiri melainkan anda mempunyai sebab penyatuan yang disengajakan.
• Pengendalian parameter. Parameter UTM, ID sesi, urutan isih, kombinasi penapis. Setiap varian adalah URL berasingan kepada Google melainkan anda canonical. Peraturan lalai: setiap URL berparameter canonical kepada URL asas yang bersih. Ganti hanya untuk parameter yang mengubah kandungan dengan bermakna (seperti varian produk).
• Ralat hreflang. Jika anda menjalankan berbilang bahasa, ralat tag-kembali hreflang merebak. Laporan Penyasaran Antarabangsa GSC masih menunjukkan ini.

Pemeriksaan waras: site:yourdomain.com dalam Google. Nombor yang dikembalikan sepatutnya hampir sama dengan kiraan diindeks GSC anda (dalam lingkungan 20%). Jika site: menunjukkan 12,000 dan GSC menunjukkan 4,000, ada sesuatu yang tidak kena, dan jurang itu biasanya URL parameter yang Google indeks sebelum anda canonical.

3. Seni Bina dan Pautan Dalaman

Alat: Sitebulb (terbaik dalam kelas untuk menggambarkan kedalaman laman), laporan kedalaman perangkak Screaming Frog.

Tiga diagnostik, disusun mengikut kekerapan saya melihatnya dalam audit:

Kedalaman dari halaman utama. Apa-apa yang lebih dari empat klik dari halaman utama adalah tanda amaran. Jalankan perangkak Screaming Frog, isih mengikut kedalaman perangkak menurun. Halaman pada kedalaman 6+ biasanya adalah halaman yatim atau terdampar oleh navigasi yang buruk. Jika halaman produk hasil pendapatan tertinggi anda berada di kedalaman 5, anda mempunyai bug seni bina, bukan bug kandungan.

Halaman yatim. Halaman tanpa pautan masuk dalaman. Sitebulb mempunyai laporan khusus untuk ini. Penyebab biasa: halaman pendaratan lama dari kempen, artikel blog yang pasukan editorial lupa untuk memautkan dari mana-mana, halaman produk yang dilancarkan tanpa kemas kini navigasi. Sama ada pautan kepada mereka dari hub yang relevan atau noindex mereka. Jangan biarkan mereka terbiar.

Pengagihan pautan dalaman. Jalankan kiraan pautan dalaman Screaming Frog per URL. Plot taburannya. Anda mencari ekor panjang halaman dengan 0-2 pautan dalaman. Halaman tersebut akan sukar mendapat kedudukan tidak kira sebaik mana kandungannya. Struktur hub-dan-jejari (halaman tonggak kepada kluster artikel berkaitan) adalah pembetulan paling bersih: setiap artikel kluster memaut kepada tonggak, tonggak memaut balik kepada setiap artikel kluster.

Perangkap navigasi bersisi. Jika anda dalam e-dagang atau marketplace, navigasi bersisi boleh menjana jutaan kombinasi URL. Pokok keputusan:

• Penapis yang mengubah kandungan dengan bermakna (kategori, jenama) boleh diindeks, canonical kepada diri sendiri
• Penapis yang hanya mengisih atau menghalamankan tidak diindeks atau canonical kepada kategori asas
• Penapis kombinasi (kategori + jenama + harga + saiz) disekat dalam robots.txt atau gunakan AJAX supaya tidak menjana URL yang boleh diperangkak

Breadcrumb. Setiap halaman kandungan sepatutnya mempunyai komponen breadcrumb yang kelihatan, ditandai dengan schema BreadcrumbList. Breadcrumb membantu pengguna memberi orientasi, memberikan Google isyarat struktur tambahan, dan mendapat paparan breadcrumb dalam SERP.

4. Core Web Vitals

Alat: PageSpeed Insights untuk data makmal dan lapangan, Lighthouse untuk pengujian makmal yang boleh diulang, panel Prestasi Chrome DevTools untuk diagnosis, laporan Core Web Vitals GSC untuk pemantauan.

Ambang nilai penting. Hafal ia:

Sentiasa ukur pada data lapangan (CrUX, nombor pengguna sebenar dalam PageSpeed Insights dan GSC), bukan makmal. Nombor makmal memberitahu anda cerita; nombor lapangan memberitahu anda kebenaran. Makmal boleh lulus sementara CrUX gagal kerana pengguna sebenar menggunakan rangkaian yang lebih perlahan dan peranti yang lebih lama.

Susun pembetulan mengikut peringkat. Setiap metrik mempunyai tangga yang jelas:

Pembetulan LCP (mengikut urutan usaha berbanding impak):

Pembetulan INP:

Pembetulan CLS:

Jalankan PageSpeed Insights pada 10 templat teratas anda (halaman utama, artikel blog, kategori, produk, harga, dan lain-lain), bukan pada URL individu. Templat adalah tempat anda menghantar pembetulan sekali dan ia merebak ke seluruh laman.

5. Data Berstruktur

Alat: Laporan Hasil Kaya GSC, pengesah schema.org, pengekstrakan data berstruktur Screaming Frog.

Semakan liputan. Setiap jenis kandungan sepatutnya mempunyai 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
• Kandungan cara-cara: HowTo

Jalankan Screaming Frog dengan pengekstrakan data berstruktur diaktifkan. Tapis kepada URL dengan ralat atau jenis yang hilang. Semak silang dengan laporan Hasil Kaya GSC. Itulah sumber kebenaran untuk apa yang Google sahkan.

Sudut AEO (pengoptimuman enjin jawapan) semakin penting setiap suku tahun. Sistem carian berkuasa LLM bergantung banyak pada data berstruktur apabila memutuskan kandungan mana untuk dirujuk. Halaman FAQ dengan schema FAQPage yang sah dan pasangan S&J yang bersih dirujuk oleh ChatGPT, Perplexity, dan AI Overviews Google dengan lebih kebolehpercayaan berbanding kandungan yang sama tanpa schema. Schema bukan lagi sekadar untuk petikan kaya. Ia adalah cara mesin menentukan apa yang halaman anda bicarakan.

Realiti Pemaparan JS

Jika laman anda adalah SPA yang dibina pada React, Vue, Svelte, atau Angular tanpa SSR atau SSG, anda bermain dalam mod sukar.

Googlebot melakukan pemaparan dua laluan. Laluan pertama: ia melihat respons HTML awal anda. Untuk SPA yang tidak dipaparkan, itu adalah <div id="root"></div> yang hampir kosong dengan tag skrip. Laluan kedua: jam hingga minggu kemudian, apabila antrian pemaparan Google mempunyai kapasiti, ia mengambil semula dan menjalankan JS. Kandungan diindeks, akhirnya.

Diagnosis "halaman kosong dalam Screaming Frog": jalankan Screaming Frog dengan pemaparan JS DIMATIKAN. Jika halaman anda mengembalikan 200 OK dengan <body> kosong, itulah yang Googlebot lihat pada laluan pertama. Sekarang jalankan dengan pemaparan JS DIHIDUPKAN. Jika kandungan muncul, Google akan sampai ke sana akhirnya. Jika tidak, anda mempunyai bug yang lebih dalam (dinding auth, hidrasi yang rosak, ralat JS yang menyekat pemaparan).

Bila ini penting:

• Kandungan berita dan tular. Jika anda bergantung pada Googlebot mengindeks dalam masa 24 jam, kelewatan laluan kedua membinasakan anda. SSR atau SSG, tanpa pengecualian.
• Katalog besar. Laman e-dagang 50K produk dengan pemaparan sisi klien akan menyaksikan bajet perangkak terbakar pada antrian pemaparan. Google memutuskan halaman mana yang berbaloi untuk laluan kedua.
• Halaman dengan gerbang auth. Jika logik hidrasi anda mengubah hala pengguna yang tidak disahkan (yang mana Googlebot termasuk), Google melihat ubah hala, bukan kandungan anda.

Pokok keputusan:

• Jika anda adalah laman kandungan: SSG (Next.js, Astro, Eleventy)
• Jika anda adalah aplikasi produk: SSR untuk halaman pemasaran, CSR untuk aplikasi itu sendiri
• Jika penghijrahan terlalu mahal: prapemaparan (Prerender.io, Rendertron) sebagai langkah sementara

Minta pasukan jurutera untuk log header User-Agent pada kegagalan pemaparan. Jika anda melihat Googlebot di sana, anda mempunyai bukti untuk dibawa ke sesi perancangan sprint.

Membungkus Penemuan sebagai Tiket Dev

Di sinilah kebanyakan audit terbunuh. Penemuan adalah nyata. Tiket tidak pernah ditulis. Jurutera memilih tugas paling mudah dari backlog kerana tiada siapa melampirkan impak perniagaan pada audit anda.

Penghantaran adalah antrian tiket yang diprioritaskan. Pembahagian standard saya untuk audit suku tahunan:

• 3 P0 (isu yang menyekat pengindeksan). Laman tidak boleh mendapat kedudukan jika ini tidak diperbaiki. Contoh: noindex pada halaman penting, robots.txt disallow pada direktori yang boleh diindeks, tag canonical yang menghala kepada 404.
• 8 P1 (kegagalan Core Web Vitals dan masalah seni bina). Contoh: LCP > 4s pada templat teratas, tiada pautan dalaman ke halaman hasil pendapatan, navigasi bersisi menjana perangkap perangkak.
• 20 P2: jurang schema, pembersihan hreflang, penulisan semula penerangan meta, alt text imej, polish seni bina minor.

Setiap tiket memerlukan medan yang sama:

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

Corak URL: Semua URL yang sepadan dengan /blog/*
Cara semula:
  1. Lawati https://example.com/blog/mana-mana-artikel
  2. Lihat sumber
  3. Lihat <meta name="robots" content="noindex"> dalam <head>
Dijangka: Tag noindex tidak sepatutnya hadir pada artikel blog yang boleh diindeks
Bukti: Tangkap skrin lihat-sumber, laporan Halaman GSC menunjukkan 247 URL
  dengan status "Dikecualikan oleh tag 'noindex'"
Anggaran impak trafik: 247 URL dikecualikan semasa ini. 20 teratas
  mendapat kedudukan 4-15 sebelum noindex ditambah (data Ahrefs).
  Anggaran pemulihan: 8K-12K lawatan organik bulanan dalam masa 60 hari
  selepas pembetulan + pengindeksan semula.
Penerimaan: Fail layout tidak lagi memaparkan tag noindex untuk /blog/*.
  Kiraan "Dikecualikan oleh noindex" laporan Halaman GSC turun sebanyak lebih 240.

Jurutera akan mengambil tiket yang berbunyi begitu. Mereka tidak akan mengambil tiket yang berbunyi "Baiki isu pengindeksan pada blog."

Kekerapan Audit

Audit mendalam suku tahunan meliputi kesemua lima kawasan. Dua hari kerja yang fokus, ditambah seminggu untuk menulis tiket dan memandunya melalui perancangan sprint. Setiap suku tahun.

Semakan liputan indeks bulanan. Buka laporan Halaman GSC pada Isnin pertama setiap bulan. Bandingkan dengan petikan bulan sebelumnya. Siasat sebarang kategori "Tidak diindeks" yang meningkat lebih dari 10%.

Imbasan regresi CWV mingguan. Laporan Core Web Vitals GSC. Mana-mana templat yang bertukar dari "Baik" kepada "Perlu Penambahbaikan" disiasat dalam minggu itu juga. Mengesan regresi CWV pada 1 minggu adalah pembetulan 1 jam. Mengesan pada 8 minggu selepas pelancaran adalah penggalian berbilang sprint.

Pensampelan log pelayan: suku tahunan memadai untuk kebanyakan laman, bulanan untuk laman melebihi 500K URL.

Audit bukan penghantaran sekali sahaja. Ia adalah kadens operasi. Yang pertama adalah lebih berat kerana anda sedang menetapkan garis asas. Menjelang suku tahun ketiga, kebanyakan masa anda digunakan untuk imbasan regresi dan triaj isu baharu, bukan audit penuh semula.

Hantar pembetulan, bukan penemuan. Audit hanya sebaik PR yang digabungkan.

Ketahui Lebih Lanjut

• On-Page SEO Checklist for Pillar Pages
• Internal Linking Strategy for B2B SaaS
• Schema Markup for B2B SaaS
• GSC Weekly Workflow