Apa Itu Technical SEO? Wajib tahu bagi pemula

Tanyakan kepada sepuluh agensi apa saja yang tercakup dalam technical SEO, dan Anda akan menerima sepuluh invoice yang berbeda. Tanyakan kepada Google, daftarnya jauh lebih pendek. Halaman technical requirements milik Google menyebut tiga hal yang harus dipenuhi sebuah halaman agar layak untuk indexing (pengindeksan): Googlebot (crawler milik Google) tidak diblokir dari halaman itu, halaman mengembalikan respons yang berfungsi, dan halaman memiliki konten yang bisa diindeks. Hanya itu standarnya. Selebihnya adalah optimasi, dan optimasi selalu punya titik jenuh.

Panduan ini membahas apa itu technical SEO, bagaimana crawling (perayapan) dan indexing benar-benar bekerja, berapa persis ambang batas Core Web Vitals, dan masalah yang tidak akan selesai dengan pekerjaan engineering sebanyak apa pun. Anda juga akan mendapat daftar taktik yang justru dibantah oleh dokumentasi Google sendiri. Taktik-taktik itulah yang bisa Anda coret dari anggaran.

Yang Akan Anda Pelajari

• Google hanya menyebut tiga syarat teknis untuk indexing, dan menyatakan indexing tetap tidak dijamin (Google Search Central).
• Core Web Vitals lolos pada LCP 2,5 detik, INP 200 milidetik, CLS 0,1, di persentil ke-75.
• robots.txt mengendalikan crawling, bukan indexing. Keduanya terus-menerus tertukar.
• Panduan crawl budget hanya ditujukan untuk situs dengan 1 juta+ halaman. Sebagian besar situs bisa melewatinya.

Apa itu technical SEO, dan apa yang sebenarnya diperbaikinya?

Technical SEO adalah pekerjaan yang membuat halaman Anda bisa ditemukan, bisa diambil, dan layak masuk indeks. Google Search Central menyebut persis tiga syarat teknis: Googlebot tidak diblokir, halaman berfungsi (respons sukses HTTP 200), dan halaman memiliki konten yang bisa diindeks. Halaman yang sama menambahkan satu peringatan yang layak dikutip: "Indexing tidak dijamin" (Google Search Central).

Standar itu rendah, dan sebagian besar isinya tidak berubah. Ini kebalikan dari cara technical SEO biasanya dijual, yaitu sebagai permukaan tak berujung yang selalu bisa diperbaiki. Begitu sebuah halaman memenuhi ketiga syarat tersebut, pekerjaan teknis tambahan tidak membuatnya lebih layak. Halaman itu sudah layak. Yang Anda dapat dari pekerjaan lanjutan adalah mempertahankan kelayakan tersebut dalam skala besar, di ribuan URL, di setiap perubahan template, dan di setiap migrasi.

Karena itu, akan lebih mudah jika disiplin ini dipecah menjadi empat tugas:

• Akses. Bisakah crawler menjangkau dan mengambil halaman Anda?
• Interpretasi. Apakah mereka melihat konten yang sama dengan yang dilihat pengunjung Anda?
• Instruksi. Apakah robots.txt, sitemap, dan tag canonical Anda benar-benar menyatakan apa yang Anda kira mereka nyatakan?
• Pengalaman. Apakah halaman Anda cukup cepat dan stabil sehingga Anda tidak kalah dalam persaingan ketat?

Perhatikan apa yang tidak ada di daftar itu: relevansi, kualitas, dan permintaan. Panduan Google tentang helpful content menyatakannya dengan gamblang: "SEO bisa menjadi aktivitas yang bermanfaat jika diterapkan pada konten yang mengutamakan manusia, bukan konten yang mengutamakan mesin pencari" (Google Search Central). Technical SEO adalah pengali bagi konten yang memang pantas menempati peringkat. Kalikan nol, hasilnya tetap nol.

Bagaimana cara kerja crawling, rendering, dan indexing?

Google menjelaskan Search sebagai tiga tahap: crawling, indexing, dan serving (Google Search Central). Untuk situs yang berat JavaScript, ada satu tugas keempat yang tersembunyi di dalamnya: rendering (perenderan). Setiap tahap adalah sistem terpisah dengan mode kegagalan yang berbeda, dan Google terus terang menyatakan bahwa melewati semuanya pun tetap tidak memaksa halaman Anda masuk indeks.

Mendiagnosis masalah SEO jauh lebih mudah begitu Anda tahu tahap mana dari ketiganya yang bermasalah. Halaman yang tidak pernah di-crawl dan halaman yang sudah di-crawl tetapi tidak diindeks membutuhkan perbaikan yang sama sekali berbeda.

Crawling: bisakah Googlebot mengambil URL itu?

Crawling adalah sebuah permintaan pengambilan, dan kode status HTTP yang Anda kembalikan menentukan apa yang terjadi berikutnya. Google mendokumentasikan efeknya dengan jelas (Google Search Central). Redirect permanen 301 adalah sinyal canonical yang kuat, sedangkan redirect sementara 302 tergolong lemah. Googlebot mengikuti hingga 10 lompatan redirect sebelum menyerah.

404 dan 410 diperlakukan dengan cara yang sama, dan keduanya sama-sama berujung pada penghapusan dari indeks seiring waktu. Ini mengejutkan banyak orang yang mengira 410 ("gone") bekerja lebih cepat. Error server justru lebih berpengaruh: respons 5xx memperlambat crawling dan pada akhirnya mengeluarkan URL dari indeks. Respons 429 ("too many requests") juga dihitung sebagai error server, sehingga rate limiting yang terlalu agresif bisa diam-diam menggerus cakupan indeks Anda.

Rendering: apakah Googlebot melihat apa yang dilihat pengunjung Anda?

Googlebot memproses JavaScript dalam tiga fase: crawl, render, lalu index. Detail pentingnya, rendering ditunda ke dalam antrean dan dijalankan oleh headless Chromium ketika sumber daya memungkinkan (Google Search Central). Prosesnya tidak instan, dan Google tidak memublikasikan komitmen tingkat layanan apa pun soal berapa lama antrean itu berjalan.

Ada konsekuensi praktisnya. Jika konten utama, link, atau tag canonical Anda baru muncul setelah JavaScript dijalankan, semuanya masuk ke Search dengan jeda yang tidak Anda kendalikan. Bagi situs berita atau katalog besar yang sering berubah, jeda itu adalah biaya nyata. Bagi situs profil perusahaan berisi 30 halaman yang diperbarui dua kali setahun, jeda itu biasanya tidak sepadan dengan ongkos berganti platform.

Indexing: apakah halaman disimpan dan layak ditayangkan?

Indexing adalah tahap ketika Google menganalisis halaman dan memutuskan apakah akan menyimpannya. Kelayakan bukanlah jaminan, dan Google menyatakannya secara terbuka. Halaman bisa memenuhi setiap syarat teknis dan tetap tidak masuk indeks, paling sering karena Google menilainya duplikat atau tidak layak disimpan. Ketika itu terjadi, perbaikannya ada di sisi editorial, bukan di sisi teknis.

Tiga file yang mengendalikan perilaku mesin pencari

Tiga lapisan instruksi menangani sebagian besar pekerjaan ini: robots.txt, sitemap XML, dan rel=canonical. Hanya satu di antaranya yang berupa aturan. Google menyebut pengiriman sitemap sebagai petunjuk tanpa jaminan bahwa file tersebut akan diunduh, dan menyebut rel=canonical sebagai petunjuk yang bisa saja diabaikannya. robots.txt bersifat mengikat, tetapi hanya untuk crawling.

robots.txt mengendalikan crawling, bukan indexing

Ini adalah kesalahpahaman termahal dalam technical SEO. Google menyatakan secara eksplisit bahwa robots.txt adalah alat pengelola crawling, bukan alat pengendali indeks. URL yang di-disallow tetap bisa diindeks jika situs lain menautkannya, dan biasanya muncul di hasil pencarian tanpa deskripsi (Google Search Central).

Detail spesifikasinya lebih penting daripada dugaan kebanyakan marketer. Google mengurai maksimal 500 kibibyte robots.txt dan mengabaikan sisanya. Aturan berlaku per host, protokol, dan port, sehingga https://example.com dan https://shop.example.com membutuhkan file yang terpisah. Respons 4xx (kecuali 429) diperlakukan seolah robots.txt tidak ada sama sekali, artinya Googlebot merayapi situs Anda tanpa batasan. Respons 5xx menghentikan crawling selama 12 jam pertama, lalu Google beralih ke salinan bagus terakhir Anda selama kurang lebih 30 hari sambil terus mencoba lagi (Google Search Central).

Semua ini bukan trivia khas Google. RFC 9309, spesifikasi Standards Track untuk Robots Exclusion Protocol, menetapkan lokasi file di scheme://authority/robots.txt, menyarankan crawler menerapkan batas parsing dan mewajibkan batas tersebut menampung minimal 500 kibibyte jika diterapkan, mengharuskan crawler "menganggap semuanya dilarang" ketika terjadi error 5xx, dan menyelesaikan aturan yang saling bertabrakan berdasarkan jumlah oktet terbanyak yang cocok, dengan allow menang jika hasilnya seri persis (IETF). Aturan terakhir itulah yang menjelaskan mengapa Disallow yang luas ditambah Allow yang sempit berperilaku seperti yang Anda lihat.

Jebakan yang wajib Anda hafal: jika Anda memasang tag noindex di sebuah halaman dan memblokir URL yang sama di robots.txt, keduanya saling meniadakan. Googlebot tidak pernah mengambil halaman itu, sehingga tidak pernah membaca noindex-nya, dan URL tersebut tetap bisa muncul di hasil pencarian. Google mendokumentasikan hal ini secara langsung (Google Search Central). Untuk menghapus sebuah halaman, izinkan crawling agar Googlebot benar-benar bisa melihat noindex itu.

Sitemap XML punya batas yang keras dan pengaruh yang lunak

Protokol sitemap membatasi satu file pada 50.000 URL atau 50MB tanpa kompresi. Melewati salah satu batas itu, Anda harus memecah filenya dan memakai sitemap index (sitemaps.org). Hanya <loc> yang wajib. <lastmod>, <changefreq>, dan <priority> semuanya opsional, dan spesifikasinya menyebut <changefreq> "sekadar petunjuk, bukan perintah."

Perhatikan bahasa spesifikasinya sendiri tentang <priority>: field ini "kemungkinan besar tidak memengaruhi posisi URL Anda". Itu penulis protokolnya sendiri yang memberi tahu Anda bahwa field tersebut tidak melakukan apa yang selama bertahun-tahun dijual agensi. Google menambahkan catatannya sendiri: mengirimkan sitemap hanyalah petunjuk, tanpa jaminan Google mengunduh filenya atau merayapi URL di dalamnya (Google Search Central).

Sitemap tetap layak dipertahankan di situs besar, di situs dengan internal link yang lemah, dan untuk URL baru yang sedikit menerima tautan masuk. Di situs 50 halaman dengan tautan internal yang rapi, sitemap hanyalah pekerjaan rumah tangga, bukan strategi.

Tag canonical hanyalah petunjuk, dan sinyal saling menumpuk

rel=canonical memberi tahu Google versi mana dari sebuah halaman duplikat yang Anda inginkan. Google tetap bisa memilih versi yang lain (Google Search Central). Dokumentasinya memeringkat kekuatan sinyal kanonikalisasi: redirect dan rel=canonical sama-sama kuat, sedangkan pencantuman di sitemap tergolong lemah. Sinyal-sinyal itu saling menumpuk, dan di situlah letak bagian yang bisa Anda kerjakan.

Jadi jangan bergantung pada satu tag saja. Arahkan redirect, tag canonical, internal link, dan entri sitemap ke URL yang sama. Ketika keempatnya sepakat, Google biasanya ikut sepakat dengan Anda. Ketika keempatnya saling bertentangan, Google yang memutuskan, dan Anda belum tentu suka jawabannya.

Berapa ambang batas Core Web Vitals?

Metrik	Baik	Perlu perbaikan	Buruk
LCP (Largest Contentful Paint)	2,5 detik atau kurang	Di atas 2,5 detik sampai 4,0 detik	Di atas 4,0 detik
INP (Interaction to Next Paint)	200 ms atau kurang	Di atas 200 ms sampai 500 ms	Di atas 500 ms
CLS (Cumulative Layout Shift)	0,1 atau kurang	Di atas 0,1 sampai 0,25	Di atas 0,25

Sumber: ambang batas menurut web.dev, "Web Vitals". Core Web Vitals dinilai pada persentil ke-75 dari page load, dipisahkan antara mobile dan desktop.

Apa yang sebenarnya diukur setiap metrik

Namanya memang tidak transparan, jadi berikut yang sebenarnya sedang dihitung. LCP mengukur waktu render gambar, blok teks, atau video terbesar yang terlihat di viewport, dihitung sejak pengguna pertama kali membuka halaman (web.dev). Metrik ini adalah perkiraan untuk pertanyaan "kapan halaman ini terlihat selesai dimuat oleh mata manusia?"

INP mengukur latensi di setiap klik, ketukan, dan interaksi keyboard sepanjang siklus hidup halaman, lalu melaporkan yang paling lama sambil mengecualikan outlier (web.dev). Scroll, hover, dan zoom tidak dihitung. INP menggantikan First Input Delay sebagai Core Web Vital yang stabil, jadi anggap FID sudah pensiun.

CLS mengukur ledakan pergeseran layout tak terduga yang terbesar sepanjang siklus hidup halaman, dengan skor berupa impact fraction dikalikan distance fraction (web.dev). Inilah metrik yang menangkap iklan dan gambar yang mendorong konten ke sana kemari tepat ketika jempol pembaca hendak menyentuhnya.

Mengapa persentil ke-75?

Karena rata-rata menyembunyikan kunjungan terburuk Anda. web.dev menjelaskan bahwa persentil ke-75 "mencapai keseimbangan yang wajar", memastikan tiga dari empat kunjungan memenuhi target sekaligus menahan pengaruh outlier (web.dev). Pengguna median Anda bisa saja baik-baik saja sementara seperempat trafik Anda menderita, dan angka median tidak akan memberi tahu Anda soal itu.

Ambang batasnya sendiri tidak ditentukan berdasarkan perasaan. Google menetapkannya dengan tiga kriteria: berbasis riset persepsi manusia, bisa dicapai setidaknya oleh 10% origin yang sudah ada, dan seragam di semua perangkat (web.dev). Kriteria ketiga itulah alasan Anda tidak mendapat target yang lebih longgar untuk mobile.

Apa yang tidak bisa diperbaiki technical SEO, menurut Google sendiri

Tidak ada sinyal peringkat page experience yang tunggal. Dokumentasi page experience Google menyatakan bahwa sistem peringkat intinya melihat berbagai macam sinyal, dan bahwa Google "selalu berusaha menampilkan konten yang paling relevan, bahkan jika page experience-nya di bawah standar" (Google Search Central). Page experience adalah penentu ketika hasilnya seri, bukan tuas pendongkrak.

Baca ulang kalimat itu jika Anda hampir menyetujui proyek performa berbiaya miliaran rupiah yang dijual dengan janji peringkat. Kerangka berpikir Google adalah bahwa page experience membantu ketika sudah banyak konten bermanfaat yang tersedia dan sesuatu harus memecah kebuntuan. Jika konten Anda tidak ada di dalam kumpulan itu, kecepatan tidak akan memasukkan Anda ke sana.

Halaman yang sama juga tegas soal Core Web Vitals: skor bagus tidak menjamin peringkat, karena "page experience yang baik tidak hanya ditentukan oleh skor Core Web Vitals". Jadi inilah daftar jujur tentang apa yang tidak akan dilakukan pekerjaan teknis untuk Anda:

• Tidak akan menciptakan relevansi. Google menampilkan hasil yang paling relevan bahkan ketika pengalamannya di bawah standar.
• Tidak akan memperbaiki konten tipis atau konten yang mengutamakan mesin pencari. Panduan helpful content Google memosisikan SEO sebagai berguna jika diterapkan pada konten yang mengutamakan manusia.
• Tidak akan memproduksi kepercayaan. Di dalam E-E-A-T, Google menyebut trust sebagai "anggota keluarga yang paling penting", dan mencatat bahwa unsur lainnya berkontribusi pada trust alih-alih wajib dipenuhi satu per satu (Google Search Central).
• Tidak akan menjamin rich results. Structured data yang benar dan lolos Rich Results Test pun tetap tidak menjamin rich results, dan menandai konten yang tidak terlihat oleh pembaca melanggar pedoman Google (Google Search Central).

Poin terakhir itu sering menjebak tim. Lolos validasi dan mendapatkan rich result adalah dua hasil yang berbeda, dan hanya satu di antaranya yang ada dalam kendali Anda.

Mitos mana yang bisa Anda coret dari anggaran?

Mulai dari crawl budget. Google membatasi panduan crawl budget-nya untuk situs dengan lebih dari 1 juta halaman unik yang berubah kira-kira mingguan, atau lebih dari 10.000 halaman unik yang berubah harian. Jika situs Anda lebih kecil dan indexing-nya berjalan lancar, Google menyatakan Anda tidak membutuhkan panduan itu (Google Search Central).

"Crawl budget penting untuk semua situs." Tidak. Kasus ketiga yang memenuhi syarat adalah situs dengan banyak URL yang tersangkut di status "Discovered, currently not indexed" pada Search Console. Jika Anda tidak masuk salah satu dari tiga kategori itu, pekerjaan crawl budget adalah pos anggaran tanpa hasil yang terdokumentasi. Periksa laporannya sebelum Anda menyusun cakupan proyek.

"robots.txt menjauhkan halaman dari Google." Itu hanya kendali crawling. Jika Anda butuh sebuah halaman hilang, yang Anda butuhkan adalah noindex pada URL yang bisa di-crawl, atau autentikasi, atau penghapusan. Memblokir adalah alat yang salah, dan jika digabung dengan noindex justru kontraproduktif.

"Priority dan changefreq di sitemap membantu peringkat." Protokol sitemaps.org menyatakan <priority> "kemungkinan besar tidak memengaruhi posisi URL Anda". Kedua field itu hanyalah petunjuk opsional. Jika ada yang menagih Anda untuk menyetelnya, itu jam kerja berbayar yang tidak menghasilkan apa pun yang bisa diukur.

"Skor Lighthouse 100 meningkatkan peringkat." Lighthouse menghasilkan data lab dari simulasi pemuatan halaman. Penilaian Core Web Vitals memakai data lapangan pada persentil ke-75 dari kunjungan nyata. Keduanya menjawab pertanyaan yang berbeda, dan Google tidak pernah mengaitkan skor Lighthouse dengan peringkat. Lighthouse adalah alat debugging yang berguna. Ia bukan papan skor.

"Kecepatan halaman adalah faktor peringkat terpenting nomor sekian." Baik Google maupun badan standar mana pun tidak pernah mengukur bobot sinyal apa pun, dan Google menyatakan sejak awal memang tidak ada sinyal page experience tunggal yang bisa dibobot. Angka peringkat spesifik mana pun yang pernah ditunjukkan kepada Anda hanyalah tebakan seseorang yang dibungkus jas laboratorium.

"Google me-render JavaScript secara instan." Rendering masuk antrean dan berjalan ketika sumber daya memungkinkan. Google menyatakan prosesnya bisa lebih lama dan tidak memublikasikan SLA apa pun. Rencanakan adanya jeda, jangan berasumsi hasilnya setara dengan browser Anda.

Dari mana Anda harus mulai kalau tidak semuanya bisa diperbaiki?

Perbaiki kelayakan sebelum pengalaman. Tiga syarat teknis Google pada dasarnya bersifat biner: halaman yang diblokir, rusak, atau kosong tidak bernilai apa pun, sekencang apa pun ia dimuat. Core Web Vitals baru berperan sebagai penentu saat seri setelah konten yang relevan tersedia (Google Search Central). Kerjakan daftarnya dengan urutan itu.

1. Pastikan halaman penghasil pendapatan Anda bisa diindeks. Periksa ketiga syarat itu pada 20 URL yang benar-benar menghasilkan uang. Tidak diblokir, mengembalikan 200, konten asli ada di dalam HTML. Ini hanya butuh satu sore dan menemukan lebih banyak kerusakan daripada crawl seluruh situs.
2. Periksa kode status per template, bukan per sampel. Satu template yang rusak bisa menjatuhkan ribuan URL sekaligus. Cari respons 5xx dan 429 lebih dulu, karena keduanya memperlambat crawling dan pada akhirnya mengeluarkan URL dari indeks.
3. Baca robots.txt seperti seorang crawler. Pastikan ada satu file untuk setiap host, protokol, dan port. Cari URL mana pun yang membawa Disallow sekaligus noindex. Pastikan ukuran filenya di bawah 500 kibibyte, yang terutama relevan bagi situs e-commerce besar dengan aturan yang dibuat otomatis.
4. Buat sinyal canonical Anda sepakat. Redirect, tag canonical, internal link, dan entri sitemap semuanya harus menunjuk ke URL yang sama. Pertentangan sering muncul setelah migrasi dan pergantian platform, dan murah diperbaiki begitu ditemukan.
5. Uji apakah rendering menyembunyikan konten Anda. Bandingkan HTML mentah dengan halaman yang sudah dirender. Ini mendesak untuk katalog dan situs berita yang berat JavaScript, dan nyaris tidak relevan untuk situs kecil yang dirender di sisi server.
6. Setelah itu baru kejar Core Web Vitals, lewat data lapangan. Pakai data lapangan pada persentil ke-75, bukan skor lab. Prioritaskan template berdasarkan trafik, bukan berdasarkan halaman mana yang paling gampang diperbaiki.
7. Lewati crawl budget kecuali Anda memang memenuhi syarat. 1 juta+ halaman, atau 10.000+ halaman yang berubah harian, atau setumpuk URL berstatus "Discovered, currently not indexed". Selain itu, belanjakan uangnya untuk konten.

Dalam pengalaman kami, kemenangan terbesar di situs berukuran menengah datang dari langkah 1 sampai 4, dan biayanya hitungan hari, bukan hitungan kuartal. Itu penilaian kami dari audit yang berulang, bukan sesuatu yang didokumentasikan Google. Yang memang didokumentasikan Google adalah batas atasnya: penuhi ketiga syarat, jaga instruksinya tetap konsisten, dan terima kenyataan bahwa indexing tidak pernah dijanjikan kepada siapa pun.

Pertanyaan yang sering diajukan

Apakah technical SEO layak dibayar untuk situs kecil?

Biasanya satu kali audit sudah cukup, lalu pemeriksaan berkala setiap selesai desain ulang. Kerangka Google sendiri: Anda tidak perlu membaca panduan crawl budget-nya jika halaman Anda di-crawl pada hari yang sama saat Anda menerbitkannya. Situs kecil sebaiknya memverifikasi ketiga syarat teknis, menjaga sinyal canonical tetap konsisten, dan mengalihkan sisa anggarannya ke konten yang mampu mendatangkan tautan.

Apakah memblokir halaman di robots.txt akan menghapusnya dari Google?

Tidak. Google menyatakan bahwa robots.txt adalah alat pengelola crawling, bukan alat pengendali indeks. URL yang diblokir tetap bisa diindeks jika situs lain menautkannya, dan biasanya muncul tanpa deskripsi. Untuk menghapus sebuah halaman, izinkan crawling dan sajikan tag noindex, atau gunakan autentikasi atau alat penghapusan.

Apakah saya perlu skor Lighthouse yang sempurna?

Google tidak pernah mengaitkan skor Lighthouse dengan peringkat. Lighthouse melaporkan data lab dari simulasi pemuatan, sedangkan Core Web Vitals dinilai dari data lapangan pada persentil ke-75 dari page load yang nyata. Gunakan Lighthouse untuk mendiagnosis masalah spesifik, lalu verifikasi perbaikannya di data lapangan sebelum Anda mengklaim keberhasilan.

Berapa lama Google me-render JavaScript saya?

Google tidak memublikasikan angkanya. Dokumentasi JavaScript SEO miliknya menyatakan bahwa rendering ditunda ke dalam antrean dan dijalankan oleh headless Chromium ketika sumber daya memungkinkan, dan prosesnya bisa lebih lama daripada crawling. Vendor mana pun yang menyebut waktu rendering spesifik dalam hitungan detik sedang menebak. Render konten kritis di sisi server jika soal waktu memang penting bagi bisnis Anda.

Apakah lolos Core Web Vitals menjamin peringkat yang lebih baik?

Tidak. Google menyatakan tidak ada sinyal peringkat page experience yang tunggal, bahwa "page experience yang baik tidak hanya ditentukan oleh skor Core Web Vitals", dan bahwa Google menampilkan konten yang paling relevan bahkan ketika page experience-nya di bawah standar. Anggap skor yang lolos sebagai cara menghilangkan kerugian, bukan cara membeli keunggulan.