Audit SEO: Cara Saya Mengaudit Website Langkah demi Langkah

Audit SEO adalah keputusan tentang apa yang pada situs diperbaiki lebih dulu, dengan bukti pada setiap rekomendasi dan cara memeriksanya setelah diterapkan. Daftar kesalahan dari alat baru bahan untuk audit. Audit teknis adalah bagian audit yang memeriksa apakah robot mesin pencari dan asisten AI bisa mengambil serta membaca situs, dan apakah mesin pencari bisa mengindeksnya.

Audit saya kerjakan dalam delapan langkah:

1. Saya menentukan tujuan dan kondisi situs sebelum menjalankan crawler, yaitu program yang menelusuri situs seperti robot mesin pencari.
2. Saya memeriksa apakah robot sama sekali menerima situs.
3. Saya mengumpulkan data dari beberapa sumber dan memeriksa apa yang tidak dilihat masing-masing sumber.
4. Saya meneliti kata kunci dan hasil Google sebelum membahas sisi teknis.
5. Saya menelaah situs menurut katalog masalah dengan syarat prioritas.
6. Pada setiap isu saya tunjukkan bukti.
7. Saya menentukan urutan, upaya pengerjaan, dan varian.
8. Hasilnya saya serahkan ke pemeriksaan silang, dan setelah implementasi saya memeriksa setiap isu.

Apa itu audit SEO dan apa bedanya dengan audit teknis?

Audit SEO menunjukkan kondisi situs dan apa yang membatasi visibilitasnya, sedangkan audit teknis memeriksa apakah mesin pencari bisa mengambil, merender, dan mengindeks situs. Dalam audit lengkap saya memeriksa sisi teknis, arsitektur, dan konten halaman, kata kunci, tautan eksternal, serta pesaing, dan pada akhirnya menyusun urutan tindakan. Audit teknis cukup jika pertanyaannya teknis: penurunan setelah implementasi, migrasi, halaman yang keluar dari indeks.

Audit adalah masukan bagi strategi, bukan strategi itu sendiri. Strategi menjawab permintaan mana yang diperebutkan dan apa yang dilepaskan, sedangkan audit menjawab apa yang hari ini menghalanginya. Dalam tulisan tentang strategi SEO saya jelaskan bagaimana yang satu beralih ke yang lain.

Bagaimana cara melakukan audit SEO langkah demi langkah?

Urutan langkah penting, karena langkah awal menentukan apakah angka dari langkah berikutnya bisa dipercaya. Di dua tempat saya menghentikan proses untuk mengambil keputusan: setelah langkah pertama saya menetapkan cakupan, dan setelah pemeriksaan silang, sebelum dikirim ke klien, saya memeriksa prioritas dan tesis.

Langkah 1. Tujuan dan kondisi situs, sebelum saya menjalankan crawler

Pertanyaan pertama adalah apakah situs kehilangan trafik atau belum membangunnya, karena dari jawabannya bergantung seluruh audit. Situs tanpa visibilitas lebih dulu membutuhkan peta kata kunci dan halaman yang seharusnya menjawabnya. Situs yang sudah punya visibilitas lebih dulu membutuhkan perlindungan atas apa yang sudah menempati posisi, sebelum ada yang mulai memperbaikinya.

Sebelum mulai, saya menanyakan hal-hal yang tidak ditunjukkan alat mana pun. Produk atau layanan mana yang menghasilkan uang, apakah ada rencana mengganti sistem manajemen konten atau mendesain ulang situs, siapa yang akan menerapkan rekomendasi dan berapa waktu yang dimilikinya. Dari jawabannya lahir cakupan audit dan daftar hal yang tidak saya uraikan, karena tidak akan ada yang menerapkannya.

Tahap ini harus dilalui sendiri, meski banyak spesialis kini menyerahkannya kepada model bahasa. Model bahasa kadang membantu, tetapi tidak memahami bisnis klien. Ia juga tidak membawa sudut pandang kreatif dan unik yang dimiliki spesialis SEO berpengalaman.

Langkah 2. Apakah robot sama sekali menerima situs

Sebelum membaca angka apa pun dari alat, saya memeriksa apakah server mengizinkan robot masuk, karena robot yang diblokir menghasilkan data yang tampak seperti masalah SEO. Dalam satu minggu pada Juli 2026, tiga “masalah SEO” di tiga situs berbeda ternyata blokade robot:

1. Satu situs “kehilangan” lebih dari 2.200 tautan, karena halaman asal tautan itu berada di balik firewall yang menolak robot alat analisis tautan.
2. Satu toko online punya skor kesehatan situs 0 di alat dengan hampir 42 ribu kesalahan, karena alih-alih halaman, robot alat menerima respons firewall Cloudflare.
3. Di situs ketiga blokade menghentikan crawler pada alamat pertama, dan selama tiga minggu tidak ada yang mencatatnya.

Alamat yang sama saya ambil sebagai peramban biasa dan sebagai robot Google, Bing, OpenAI, Perplexity, dan Anthropic, lalu saya bandingkan kode respons dan ukuran halaman. Selisih antara peramban dan robot adalah hal pertama yang harus dijelaskan sebelum saya mulai menghitung apa pun. Uji semacam itu mengirim permintaan dari alamat IP saya dengan nama robot, sedangkan firewall mengenali robot Google dan Bing yang asli dari alamat asalnya. Blokade “Googlebot” dalam uji karenanya tidak membuktikan blokade Googlebot yang asli. Search Console, panel gratis Google untuk pemilik situs, menunjukkan bagaimana Googlebot asli melihat situs.

File robots.txt saya baca sampai habis dengan parser, yaitu program yang menerapkan aturan seperti robot, bukan secara visual. Robot Google hanya menerapkan satu kelompok aturan, yaitu yang namanya paling cocok dengan nama robot, dan mengabaikan sisanya. Aturan Disallow: tanpa jalur tidak memblokir apa pun (Google Search Central). Pada Agustus 2026 dari potongan robots.txt salah satu situs tampak bahwa situs itu memblokir Google. Parser menunjukkan bahwa Googlebot punya akses penuh, sedangkan yang diblokir adalah robot Bing dan asisten AI. Diagnosisnya jadi berbeda: masalahnya ada pada Bing dan robot AI, bukan pada Google.

Ketiadaan file robots.txt tidak memblokir Google, tetapi setelah setiap implementasi saya memeriksa apakah file itu tidak hilang. Google memperlakukan kesalahan 4xx pada robots.txt (kecuali 429) seolah file itu tidak ada, yaitu tanpa pembatasan (Google Search Central). Situs saya pada Agustus 2026 mengembalikan kesalahan 404 pada robots.txt sebelum saya memperbaikinya.

Langkah 3. Data dari beberapa sumber dan apa yang tidak dilihat masing-masing

Setiap angka dari crawler adalah hipotesis sampai sumber kedua mengonfirmasinya. Saya mengumpulkan crawl dengan dan tanpa eksekusi JavaScript serta data kecepatan dari pengguna sungguhan dari laporan CrUX. Ditambah profil tautan dan hasil Google untuk kata kunci penting pada hari pengukuran. Dalam tulisan tentang link building saya jelaskan bagaimana saya memeriksa profil tautan sebelum rencana kampanye. Pada setiap file saya mencatat sumber, tanggal, dan cakupan, supaya sebulan kemudian setiap angka bisa direproduksi.

Data Search Console saya ambil lewat API, yaitu antarmuka untuk mengambil data secara otomatis, karena ekspor dari panel memotong daftar sampai 1.000 baris. API memberikan sampai 50 ribu baris per hari untuk setiap jenis hasil, misalnya terpisah untuk hasil halaman, gambar, dan video (Google, Bantuan Search Console). Dalam tulisan tentang alat AI untuk SEO saya tunjukkan bagaimana ekspor yang terpotong menaikkan CTR di satu situs.

Crawler bisa menghitung terlalu rendah ukuran situs, jadi jumlah halaman dan produk saya periksa di sumber kedua. Di dua toko online crawler sampai ke halaman pertama daftar produk dalam kategori dan tidak melangkah lebih jauh, padahal halaman daftar berikutnya berfungsi dan tidak diblokir. Di satu toko ia menemukan kurang dari setengah produk, di toko lain kurang dari sepertiga. Jika angka itu saya laporkan sebagai kondisi toko, audit akan menggambarkan kekurangan penawaran yang tidak ada.

Perubahan mendadak pada data harian saya jelaskan sebelum menetapkan penyebabnya. Saya melakukannya untuk klik, tayangan, posisi, sesi, dan permintaan robot Google. Saya mencari hari-hari ketika median tujuh hari berturut-turut berbeda sedikitnya 25% dari median empat belas hari sebelumnya. Pada setiap tanggal semacam itu saya mencatat penjelasan: implementasi, pembaruan Google, gangguan, perubahan pengukuran, atau “penyebab tidak diketahui”. Uraian tanggal memberi hipotesis, dan penyebab baru saya tunjuk setelah memeriksa kemungkinan penjelasan lain.

Langkah 4. Kata kunci dan hasil Google sebelum sisi teknis

Lebih dulu saya mencari peluang, baru memperbaiki kesalahan. Sebagian masalah teknis hanya bisa dinilai dengan latar kata kunci: apakah filter di toko harus diindeks, apakah sebuah tag layak punya halaman sendiri, apakah dua halaman benar-benar bersaing memperebutkan hal yang sama. Dalam katalog 32 jenis masalah bertanda bahwa tanpa analisis kata kunci dan hasil Google masalah itu tidak bisa dinilai.

Tidak adanya halaman untuk kata kunci penting adalah salah satu masalah yang cukup sering dalam audit saya: 15 dari 63 audit, di 14 dari 50 situs. Crawler tidak akan melaporkannya sendiri, karena hanya mengambil halaman yang ada. Hal itu baru terlihat ketika saya menyandingkan permintaan dengan daftar alamat dan dengan halaman pesaing yang muncul di hasil.

Langkah 5. Telaah menurut katalog dengan syarat prioritas

Kesalahan yang sama punya prioritas tinggi atau rendah tergantung tempat munculnya. Tautan internal ke alamat dengan pengalihan di templat yang berulang di ribuan halaman berprioritas tinggi. Tautan yang sama di isi satu entri blog berprioritas sedang, dan di entri arsip rendah.

Setiap jenis masalah dalam katalog punya aturan deteksi, syarat pelaporan, bukti yang diwajibkan, prioritas beserta syaratnya, dan cara memeriksa setelah implementasi. Dari 256 jenis, 86 memulai aturan prioritas dengan “tinggi”, tetapi hampir selalu dengan syarat: jika kata kunci punya permintaan, jika halaman punya trafik, jika kesalahan ada di templat.

Karena itu skor kesehatan situs dari alat tidak menentukan prioritas. Alat menghitung kesalahan, bukan trafik yang bergantung padanya. Rekomendasi untuk halaman dengan trafik yang tidak diketahui tidak mendapat prioritas tinggi sebelum saya memeriksa datanya.

Langkah 6. Bukti pada setiap isu

Isu tanpa bukti tetap ada di audit sebagai “perlu diperiksa”, bukan sebagai rekomendasi. Buktinya bisa tangkapan layar tempat di kode, atau HTML dari server di samping versi setelah eksekusi JavaScript. Bisa juga grafik dari Search Console atau pengukuran kecepatan dengan nama elemen yang merusaknya. Elemen yang memperlambat pemuatan atau menggeser tata letak halaman saya sebut sesuai penunjukan pengukuran, bukan sesuai kecocokannya dengan hipotesis saya.

Setiap isu saya uraikan dalam empat bagian, dari masalah sampai pemeriksaan perbaikan. Saya menulis apa masalahnya, mengapa merugikan dan apa yang dipengaruhinya, bagaimana memperbaikinya langkah demi langkah, dan bagaimana kita memeriksa bahwa perbaikan berhasil. Kode yang perlu diperbaiki saya salin dari situs apa adanya, supaya programmer melihat persis tempat yang harus diubah.

Beginilah ringkasnya satu laporan tentang tautan ke pengalihan:

• Masalah: tautan di menu mengarah ke alamat tanpa garis miring di akhir, yang dialihkan ke versi dengan garis miring.
• Mengapa merugikan: menu ada di setiap halaman, jadi setiap klik dan setiap pengambilan oleh robot melewati pengalihan tambahan. Dalam laporan alat, ribuan tautan semacam itu menyulitkan menemukan kesalahan yang lebih penting.
• Perbaikan: di templat menu ganti alamat dengan alamat tujuan, dengan potongan kode sebelum dan sesudah perubahan.
• Pemeriksaan: setelah implementasi crawl tidak menunjukkan di templat tautan ke alamat dengan pengalihan.

Langkah 7. Urutan, upaya pengerjaan, dan varian

Hasil audit adalah urutan, bukan jumlah temuan. Di awal dokumen ada tabel semua isu dengan prioritas dan upaya pengerjaan. Upaya saya gambarkan dalam empat kategori: beberapa jam, satu atau dua hari, seminggu, atau seluruh proyek. Tim dengan kemampuan lebih terbatas mendapat varian minimal di samping varian penuh, dengan penjelasan terus terang apa yang hilang jika memilih jalan yang lebih pendek.

Implementasi berjalan persis menurut audit. Jika saat penawaran implementasi muncul varian yang lebih murah, kliennya yang memilih dan saya mencatatnya terus terang, bukan mengganti rekomendasi tanpa sepengetahuannya.

Langkah 8. Pemeriksaan silang dan pemeriksaan setelah implementasi

Sebelum audit sampai ke klien, dokumen diperiksa oleh orang yang tidak menulisnya. Saya melakukan dua putaran pemeriksaan: yang pertama pada seluruh dokumen, yang kedua hanya pada apa yang berubah setelah yang pertama. Pemeriksaan menghitung ulang angka dari nol dan mencari tesis yang tidak bisa dipertahankan dengan bukti. Pada akhirnya saya sendiri memeriksa prioritas dan tesis yang bergantung pada situasi klien.

Setelah implementasi, setiap isu saya periksa di situs yang berjalan dan saya tandai sebagai diterapkan dengan benar, sebagian, atau belum diterapkan. Pemeriksaan ini sudah termasuk dalam harga audit. Tanpa langkah itu audit berhenti di dokumen, bukan di perubahan pada situs.

Apa yang diperiksa dalam audit teknis?

Dalam audit teknis saya menelusuri belasan area, dan masalah paling sering saya laporkan pada pengalihan, arsitektur situs, dan konten. Kolom terakhir menunjukkan di berapa dari 63 audit dalam arsip penulis melaporkan sedikitnya satu masalah dari area itu. Kolom “Yang saya periksa” memberi contoh, bukan cakupan penuh area. Tabel menampilkan area terpilih, sedangkan katalog membagi masalah ke dalam 22 area.

Masalah yang jarang dilaporkan belum tentu jarang terjadi. Kecepatan dan JavaScript punya sedikit laporan dalam tabel ini, tetapi audit di arsip punya cakupan berbeda-beda. Rendahnya jumlah laporan karenanya tidak menunjukkan seberapa sering masalah itu muncul di situs.

Bagaimana saya memeriksa pengindeksan situs?

Pengindeksan saya periksa pada tiga daftar: apa yang ada di peta situs, apa yang diindeks Google, dan apa yang ditemukan crawler lewat tautan. Selisih antara ketiga daftar itu menunjukkan masalah lebih baik daripada masing-masing daftar sendirian. Peta situs dengan alamat yang mengembalikan pengalihan, kesalahan, atau dikeluarkan dari indeks dilaporkan di 20 dari 63 audit, di 18 dari 50 situs. Untuk alamat tunggal saya memakai inspeksi URL di Search Console, yang juga menunjukkan halaman setelah eksekusi JavaScript.

Apakah Core Web Vitals memengaruhi posisi?

Core Web Vitals adalah bagian dari sistem peringkat Google, tetapi tidak mengalahkan relevansi konten. Google menulis terus terang bahwa sistem peringkatnya memakai Core Web Vitals. Google juga menulis bahwa ia selalu berusaha menampilkan konten yang paling relevan, bahkan ketika pengalaman di halaman buruk (Google Search Central). Dalam audit saya memakai data dari pengguna sungguhan dari laporan CrUX, bukan dari satu uji di alat laboratorium. Di tempat Google punya data semacam itu untuk berbagai jenis halaman, saya sajikan terpisah. Ketiadaan data itu saya jelaskan dalam audit. Sejak 12 Maret 2024 ukuran reaksi halaman adalah INP, yang menggantikan FID (web.dev).

Kesalahan apa yang paling sering saya temukan dalam audit SEO?

Yang paling sering berulang adalah kesalahan kerapian, yaitu yang mudah dideteksi alat: tautan ke pengalihan dan ke kesalahan 404, peta situs dengan alamat yang salah, serta judul dan deskripsi halaman yang terduplikasi. Tautan internal ke alamat dengan pengalihan muncul di 24 dari 63 audit, di 20 dari 50 situs. Alat mendeteksinya dengan baik, dan biaya perbaikannya bergantung pada templat dan sistem situs.

Masalah struktur yang lebih jarang dilaporkan bisa berdampak pada trafik lebih besar daripada kesalahan kerapian. Ketiadaan halaman untuk kata kunci penting dilaporkan di 15 dari 63 audit, dan sebanyak itu pula blog yang tidak menautkan ke halaman penawaran dan kategori. Katalog memberi halaman yang hilang prioritas tinggi jika kata kunci punya permintaan dan pesaing menempati posisi dengan halaman tersendiri. Blog tanpa tautan mendapat prioritas tinggi jika halaman tujuan punya trafik atau pendapatan dan blog punya otoritas. Syarat-syarat itu saya periksa pada data sebelum menetapkan prioritas.

• 938temuan dalam 63 audit di 50 situs, yang menjadi dasar katalog 256 jenis masalahArsip audit 2020-2026, katalog dari 11.10.2026
• 38%audit dengan tautan internal ke alamat dengan pengalihan, masalah yang paling sering dilaporkan di arsip (24 dari 63)Katalog dari 11.10.2026
• 15 dari 63audit tanpa halaman untuk kata kunci penting, yang tidak akan dilaporkan crawler sendiriKatalog dari 11.10.2026
• 14jenis rekomendasi yang kini ditandai katalog sebagai usang, dan 30 lainnya sebagai praktik yang berubahKatalog dari 11.10.2026

Apa yang berubah dalam audit SEO sejak 2020?

Dalam audit 2023-2026 data terstruktur dan paginasi muncul lebih sering daripada pada 2020-2022, sedangkan pengalihan, alamat kanonis, dan pengindeksan lebih jarang. Masalah data terstruktur dilaporkan di 23 dari 33 audit yang lebih baru dibanding 16 dari 30 yang lebih lama. Pengalihan dan kode respons: 23 dari 33 dibanding 27 dari 30. Blokade robot AI baru muncul dalam audit dari 2026. Tahun audit adalah tanggal file di arsip, jadi tidak selalu tahun pelaksanaan pekerjaan.

Penurunan tidak membuktikan bahwa masalah pengalihan sudah hilang. Komposisi audit berubah: yang lebih baru lebih sering menyangkut data terstruktur, konten, dan visibilitas di AI, dan cara kerja pun berubah. Dari grafik ini terbaca apa yang dikerjakan audit, bukan bagaimana situs di Polandia berubah.

Rekomendasi SEO apa yang sekarang sudah usang?

Beberapa rekomendasi masih muncul dalam audit dan panduan, padahal sekarang tidak layak diterapkan. Sebagian dulu berfungsi beberapa tahun lalu, dan sebagian sudah lama tidak dianjurkan atau diabaikan Google. Dalam tabel pada setiap praktik saya sebutkan alasan dan apa yang dilakukan sebagai gantinya.

Sumber untuk tabel: Google tentang paginasi, Google tentang lima kesalahan dengan rel=canonical, Google tentang hasil FAQ dan HowTo, Matt Cutts tentang nofollow dan pembagian kekuatan tautan, John Mueller tentang pengalihan ke beranda, dikutip Search Engine Roundtable, Google tentang robots.txt, Google tentang aturan yang tidak didukung di robots.txt, Google tentang peta situs, Google tentang kolom lastmod, changefreq, dan priority, web.dev tentang INP, Google tentang kotak pencarian di hasil.

Karena itu setiap rekomendasi dalam katalog saya punya kolom keaktualan beserta alasannya. Katalog kini menandai 14 jenis rekomendasi sebagai usang dan 30 sebagai praktik yang berubah. Rekomendasi yang benar beberapa tahun lalu tidak masuk audit hanya karena dulu pernah berfungsi.

Bagaimana memeriksa akses robot AI dalam audit?

Akses robot AI saya periksa pada langkah yang sama dengan akses Googlebot, karena pengaturan firewall atau CDN yang sama bisa memblokirnya. CDN adalah jaringan server perantara, misalnya Cloudflare. Pada September 2026 saya memeriksa 12 domain klien saya yang berjalan di belakang Cloudflare. File robots.txt saja menunjukkan:

• 3 domain memblokir kumpulan tujuh robot yang sama, yang mengumpulkan data untuk melatih model, dengan daftar nama yang identik. Daftar identik mengisyaratkan sumber yang sama, misalnya pengaturan siap pakai di panel Cloudflare. Dari luar pengaturan itu tidak terlihat, jadi harus dikonfirmasi di panel itu sendiri.
• 1 domain memblokir robot yang mengambil halaman untuk jawaban ChatGPT, Perplexity, dan Claude. Ia tidak melakukannya secara langsung, melainkan lewat aturan umum untuk semua robot yang tidak disebut namanya. Domain yang sama menampilkan kepada GPTBot halaman pengaman tanpa tag noindex, yang mengeluarkan halaman dari indeks. Jika halaman semacam itu diterima robot pengindeks, ke indeks bisa masuk halaman blokade alih-alih konten.
• 8 domain tidak punya blokade di robots.txt.

Robot yang mengambil halaman untuk jawaban dan robot yang mengumpulkan data untuk pelatihan Anda putuskan terpisah. Dalam tulisan tentang GEO dan AI SEO saya jelaskan cara membedakannya. Sejak 31 Agustus 2026 ada juga pengaturan tersendiri di Search Console yang mengeluarkan situs dari AI Overview, Mode AI, dan fitur generatif di Discover. Menurut Google, pengaturan itu tidak memengaruhi hasil pencarian lainnya (Bantuan Search Console). Pengaturan semacam itu saya periksa dalam audit seperti robots.txt, karena seseorang bisa mengaktifkannya tanpa sepengetahuan orang yang bertanggung jawab atas SEO. Apakah setelah akses dibuka merek muncul di jawaban adalah pengukuran tersendiri, yang saya jelaskan dalam tulisan tentang visibilitas merek di AI.

Uji dari satu alamat IP hanya menunjukkan sebagian situasi, dan sendirian bisa memberi alarm palsu. Pada peninjauan yang sama serangkaian permintaan melaporkan blokade setelah melewati batas pada dua domain. Blokade itu dipicu oleh permintaan saya sendiri sebelumnya. Pemeriksaan beberapa menit kemudian, dengan satu identitas robot dan permintaan tunggal, memberi lima dan tujuh respons benar berturut-turut. Tanpa pemeriksaan itu dua klien akan menerima informasi tentang blokade yang tidak ada. Baru log server menunjukkan apakah ChatGPT benar-benar mengambil situs. Dalam tulisan tentang file llms.txt saya tunjukkan apa yang terlihat di log situs saya.

Kode 200 tidak berarti robot menerima konten. Pada satu klien dengan aplikasi JavaScript, Googlebot dan Bingbot menerima HTML siap dari layanan prerender, sedangkan robot asisten AI menerima halaman kosong. Layanan itu mengenali robot dari namanya dan tidak punya robot AI dalam daftarnya. Uji saya memberi hasil “beres”, karena mengukur kode respons, bukan konten. Sejak itu saya membandingkan konten yang diterima robot dengan konten setelah eksekusi JavaScript di peramban.

Apakah audit SEO gratis sudah cukup?

Alat gratis menunjukkan daftar kesalahan, tetapi dari laporannya saja tidak terlihat mana yang merugikan trafik Anda. Pada kata kunci “audyt seo” di Google Polandia, 7 dari 9 hasil organik di halaman pertama adalah alat atau tawaran audit gratis (hasil dari 17 Oktober 2026). Laporan semacam itu menghitung kesalahan menurut aturan alat, bukan menurut berapa banyak trafik dan pendapatan yang bergantung padanya. Perlu juga diperiksa apakah hasilnya bukan berasal dari blokade robot, seperti pada toko dengan skor kesehatan 0.

Banyak yang bisa Anda kerjakan gratis, jika tahu ke mana melihat. Search Console menunjukkan data Google tentang pengindeksan, Core Web Vitals, dan halaman setelah eksekusi JavaScript. Versi gratis Screaming Frog menelusuri sampai 500 alamat dalam satu crawl (Screaming Frog), yang cukup untuk situs perusahaan kecil. Audit bersama konsultan masuk akal ketika kesalahan sangat mahal (migrasi, penurunan trafik, toko besar) atau ketika Anda tidak punya waktu untuk menyusun dan menilai data.

Apakah ChatGPT bisa melakukan audit SEO?

ChatGPT maupun model AI lain tidak bisa melakukan audit lengkap sendiri, karena tidak melihat situs seperti robot mesin pencari. Biasanya ia melihatnya lewat alat yang mengambil situs dan mengubahnya menjadi teks. Model akan membaca data yang Anda berikan dan mengusulkan apa yang perlu diperiksa. Alat pengambilan bisa menghilangkan sebagian situs: pada September 2026 saya memeriksa bahwa alat pengambil halaman di Claude Code membuang data terstruktur saat mengubah halaman menjadi teks. Model menjawab bahwa informasi itu tidak ada, padahal ada di markup pada halaman yang sama. Audit yang dibuat dengan cara itu akan melaporkan ketiadaan data terstruktur yang sebenarnya ada. Dalam proses saya AI adalah alat, terutama untuk agregasi data dari crawl, Search Console, dan sumber lain. Cakupan, penilaian, dan prioritas saya tetapkan sendiri.

Berapa biaya audit SEO?

Audit saya tagih seperti konsultasi: 70 EUR per jam kerja, belum termasuk PPN, dengan batas atas jam yang ditetapkan sebelum mulai. Jumlah jam bergantung pada apa yang perlu diperiksa:

• audit diagnostik, yaitu satu atau dua masalah konkret (penurunan, migrasi, pengindeksan), biasanya 10-16 jam, yaitu 700-1.120 EUR di luar PPN;
• audit lengkap dengan urutan tindakan biasanya 32-50 jam, yaitu 2.240-3.500 EUR di luar PPN;
• situs kecil sampai 500 alamat mendekati batas bawah, dan toko dengan ribuan alamat dan filter mendekati batas atas;
• versi bahasa biasanya menambah 3-5 jam, dan krisis yang sedang berlangsung dan perlu didiagnosis 4-8 jam.

Dalam harga ada analisis, laporan dengan rekomendasi, pertemuan untuk membahasnya, dan pemeriksaan setelah implementasi. Implementasinya sendiri dikerjakan tim Anda, atau saya hitung biayanya secara terpisah.

Tanpa akses ke Search Console, panel CDN, dan hosting, saya tidak bisa memeriksa bagian teknis sepenuhnya, dan saya mengatakannya sebelum penawaran. Saya lalu menyebutkan apa yang tanpa akses itu tidak bisa saya verifikasi dan mempersempit cakupan sesuai kebutuhan. Dalam tulisan tentang konsultasi SEO saya jelaskan kapan sebagai pengganti audit cukup percakapan tentang satu keputusan.

Pertanyaan yang paling sering diajukan tentang audit SEO

Dari mana sebaiknya mulai?

Mulailah dari satu pertanyaan: apakah situs kehilangan trafik atau belum membangunnya. Dari jawabannya bergantung apakah Anda lebih dulu melindungi halaman yang sudah punya posisi atau mencari kata kunci yang halamannya belum ada. Lalu lakukan tiga pemeriksaan gratis dari jawaban tentang audit sendiri: robots.txt, laporan pengindeksan di Search Console, dan crawl dengan versi gratis Screaming Frog. Jika hasilnya mengejutkan Anda atau Anda tidak tahu apa yang diperbaiki lebih dulu, itu topik yang baik untuk konsultasi.