Core Web Vitals dan Latensi: Apakah Halaman yang Lebih Cepat Mendapatkan Lebih Banyak Kutipan Kecerdasan Buatan?

Core Web Vitals dan Latensi: Apakah Halaman yang Lebih Cepat Mendapatkan Lebih Banyak Kutipan Kecerdasan Buatan?

Pendahuluan

Situs web yang cepat lebih mudah digunakan oleh orang-orang. Mungkin juga lebih mudah bagi mesin pencari dan sistem kecerdasan buatan untuk mengambil, merender, dan memahaminya.

Namun, sering kali ada perbedaan penting yang terlewatkan:

Halaman yang lebih cepat dapat meningkatkan crawling dan ketersediaan konten. Hal itu tidak berarti kecepatan saja menyebabkan sistem kecerdasan buatan mengutip halaman tersebut.

Pada tanggal 2 Agustus 2026, Google menyatakan bahwa waktu respons server yang stabil dan latensi yang lebih rendah dapat meningkatkan kapasitas crawl situs. Google juga menyatakan bahwa fitur pencarian kecerdasan buatannya menggunakan sistem pencarian dan pengindeksan dasar yang sama dengan pencarian tradisional dan tidak memerlukan markup kecerdasan buatan khusus atau optimasi kecepatan. (developers.google.com)

Artikel ini menyajikan rencana pengujian berbasis bukti daripada mengklaim bahwa eksperimen yang telah selesai telah dijalankan. Tidak ada situs, kumpulan halaman, log server, atau kumpulan data kutipan yang disediakan. Tujuannya adalah untuk mendefinisikan studi terkontrol yang dapat mengukur:

1. Apakah waktu ke byte pertama yang lebih rendah meningkatkan frekuensi crawling.
2. Apakah Largest Contentful Paint yang lebih rendah meningkatkan penemuan atau pengindeksan.
3. Apakah Cumulative Layout Shift yang lebih rendah memengaruhi crawling atau pengambilan kecerdasan buatan.
4. Apakah peningkatan kinerja meningkatkan tingkat halaman yang secara visual dikutip oleh sistem pencarian kecerdasan buatan.

Jawaban Singkat

Waktu ke byte pertama yang lebih rendah dapat meningkatkan crawling dalam kondisi yang tepat

Dokumentasi crawl Google saat ini menyatakan bahwa batas kapasitas crawl-nya dapat meningkat ketika suatu situs memiliki waktu respons yang stabil atau membaik, termasuk waktu ke byte pertama. Jika waktu respons meningkat, atau jika situs mengembalikan terlalu banyak kesalahan server atau respons batas kecepatan, Google dapat mengurangi crawling. (developers.google.com)

Namun, waktu respons yang lebih cepat tidak menjamin lebih banyak crawling. Permintaan crawl juga bergantung pada faktor-faktor seperti:

• Seberapa sering situs berubah.
• Seberapa populer situs dan halamannya.
• Apakah kontennya bermanfaat dan unik.
• Berapa banyak URL duplikat atau bernilai rendah yang ada.
• Apakah URL yang diperbarui disertakan dalam sitemap.

Ini berarti latensi yang lebih rendah harus memiliki efek terkuat pada situs web besar, sering diperbarui, atau situs web yang terbatas servernya, tidak selalu pada situs kecil dengan konten baru yang terbatas.

Largest Contentful Paint yang lebih rendah dapat membantu secara tidak langsung

Largest Contentful Paint mengukur kapan konten visual utama muncul bagi pengguna. Google juga menyatakan bahwa waktu respons server dan waktu yang diperlukan untuk merender halaman serta sumber daya yang disematkan dapat memengaruhi efisiensi crawling. (developers.google.com)

Kemungkinan hubungannya adalah tidak langsung:

Latensi lebih rendah → pengiriman sumber daya lebih cepat → rendering atau pengambilan lebih efisien → lebih sedikit timeout crawl atau pengambilan tidak lengkap.

Efeknya akan paling kuat ketika konten penting bergantung pada:

• JavaScript yang lambat.
• Gambar besar.
• Stylesheet yang menghalangi rendering.
• Client-side rendering.
• Sumber daya tersemat yang berat.

Skor Largest Contentful Paint yang cepat itu sendiri tidak mungkin menjadi sinyal kutipan kecerdasan buatan secara langsung.

Cumulative Layout Shift yang lebih rendah mungkin memiliki sedikit efek crawling langsung

Cumulative Layout Shift mengukur pergerakan tak terduga dari konten yang terlihat. Ini terutama merupakan metrik pengalaman pengguna. Penyebab umum meliputi gambar tanpa dimensi, iklan yang dimasukkan secara dinamis, konten tersemat, dan web font. (web.dev)

Crawler tidak mengalami layout shift dengan cara yang sama seperti pengunjung manusia. Oleh karena itu, hubungan langsung antara Cumulative Layout Shift yang lebih rendah dan crawling yang lebih banyak tidak mungkin terjadi.

Mungkin ada hubungan tidak langsung ketika layout shift yang tinggi disebabkan oleh:

• Konten yang dimasukkan terlambat oleh JavaScript.
• Teks penting yang tersembunyi sampai skrip berjalan.
• Gambar atau embed yang menunda konstruksi halaman.
• Template tidak stabil yang menghasilkan konten berbeda selama pengambilan yang berbeda.

Dalam kasus-kasus tersebut, masalah sebenarnya bukanlah skor layout shift. Masalah sebenarnya adalah halaman mungkin sulit diproses atau mungkin menampilkan konten penting terlalu lambat.

Halaman yang lebih cepat tidak otomatis lebih sering dikutip

Google menyatakan bahwa halaman yang muncul di fitur kecerdasan buatan harus terlebih dahulu diindeks dan memenuhi syarat untuk muncul di hasil pencarian normal dengan cuplikan. Google juga menyatakan bahwa tidak ada persyaratan teknis tambahan atau optimasi kecerdasan buatan khusus untuk ikhtisar kecerdasan buatan dan mode kecerdasan buatan mereka. (developers.google.com)

OpenAI juga menyatakan bahwa peringkat pencarian ChatGPT bergantung pada banyak faktor dan bahwa mengizinkan search crawler-nya, OAI-SearchBot, penting untuk penyertaan. Tidak disebutkan bahwa Core Web Vitals yang lebih rendah secara langsung meningkatkan probabilitas kutipan. (help.openai.com)

Ini menunjukkan model empat tahap:

1. Penemuan — Apakah sistem mengetahui URL tersebut ada?
2. Pengambilan dan pemrosesan — Bisakah sistem mengambil dan memahami halaman?
3. Pengindeksan dan pengambilan — Apakah halaman dipilih untuk kueri tertentu?
4. Pemilihan kutipan — Apakah halaman ditampilkan sebagai sumber yang terlihat dalam jawaban?

Kecepatan halaman dapat memengaruhi dua tahap pertama. Ini tidak ditetapkan sebagai penyebab langsung dari tahap keempat.

Penelitian terbaru juga menunjukkan bahwa sistem kecerdasan buatan mungkin membaca banyak halaman yang relevan tetapi hanya mengutip beberapa di antaranya. Dengan kata lain, pengambilan dan kutipan adalah peristiwa terpisah. (cambridge.org)

Apa yang Harus Diuji?

Studi ini harus menguji dua pertanyaan berbeda daripada memperlakukan “visibilitas kecerdasan buatan” sebagai satu metrik.

Pertanyaan 1: Apakah kinerja memengaruhi crawling?

Hasil utama:

• Waktu dari publikasi hingga permintaan crawler pertama.
• Jumlah permintaan crawler per halaman per hari.
• Waktu antara recrawl yang berhasil.
• Jumlah halaman yang di-crawl per 1.000 halaman yang diterbitkan.
• Persentase pengambilan yang berhasil.
• Tingkat kesalahan server dan respons batas kecepatan.
• Waktu dari publikasi hingga pengindeksan.

Pertanyaan 2: Apakah kinerja memengaruhi pemilihan kutipan?

Hasil utama:

• Persentase kueri yang diuji yang menghasilkan kutipan yang terlihat.
• Tingkat kutipan per halaman yang memenuhi syarat.
• Pangsa kutipan dalam kueri.
• Persentase halaman yang diambil yang menjadi kutipan yang terlihat.
• Ketahanan kutipan dari waktu ke waktu.
• Tingkat kutipan oleh sistem kecerdasan buatan.

Hasil ini harus dipisahkan berdasarkan penyedia. Ikhtisar kecerdasan buatan Google, hasil pencarian ChatGPT, jawaban Microsoft Copilot, jawaban Perplexity, dan respons pencarian Claude dapat menggunakan indeks, crawler, sistem peringkat, dan jadwal penyegaran yang berbeda.

Desain Eksperimental

1. Bangun kumpulan halaman yang terkontrol

Gunakan kumpulan halaman yang cukup besar untuk menghasilkan data crawler dan kutipan yang bermakna.

Desain awal yang praktis akan mencakup:

• 240 hingga 800 halaman.
• Setidaknya 20 halaman per template halaman.
• Tiga hingga lima kategori konten.
• Campuran halaman evergreen dan halaman yang diperbarui secara berkala.
• Jumlah halaman yang sama di setiap kelompok perlakuan.

Setiap halaman harus memiliki:

• Struktur HTML yang serupa.
• Panjang konten yang serupa.
• Sistem penerbitan yang sama.
• Pola tautan internal yang sama.
• Aturan kanonis yang sama.
• Perlakuan sitemap yang sama.
• Izin robots.txt yang sama.
• Topik yang unik dan bermanfaat.

Jangan membuat ratusan halaman tipis atau yang hampir duplikat hanya untuk eksperimen. Panduan Google memperingatkan bahwa URL duplikat dan bernilai rendah dapat membuang sumber daya crawl dan mengurangi efisiensi situs. (developers.google.com)

Desain pasangan cocok sangat berguna. Misalnya, pasangkan halaman dengan kesamaan:

• Panjang konten.
• Permintaan topik.
• Frekuensi pembaruan.
• Jumlah tautan internal.
• Jumlah tautan eksternal.
• Lalu lintas historis.
• Posisi peringkat pencarian.

Kemudian tempatkan satu halaman dari setiap pasangan di kelompok kontrol dan yang lainnya di kelompok perlakuan.

2. Gunakan desain perlakuan faktorial

Perlakuan kinerja utama harus diuji secara independen dan bersama-sama.

Ini menciptakan eksperimen terkontrol untuk tiga optimasi yang diminta:

• HTTP/3.
• Content delivery network edge caching.
• Kompresi gambar.

Perlakuan stabilitas tata letak diperlukan karena tiga optimasi pertama tidak secara andal mengisolasi Cumulative Layout Shift. Kompresi gambar dapat menurunkan Largest Contentful Paint tanpa mengubah stabilitas tata letak sama sekali.

Mengapa HTTP/3 memerlukan pengukuran tersendiri

HTTP/3 menggunakan protokol transportasi QUIC dan menyediakan aliran independen, yang dapat menghindari head-of-line blocking tingkat transportasi yang ditemukan di HTTP/2 melalui TCP. Manfaatnya tergantung pada apakah klien atau crawler benar-benar menegosiasikan HTTP/3. (rfc-editor.org)

Oleh karena itu, catat protokol yang dinegosiasikan untuk setiap permintaan:

• HTTP/1.1.
• HTTP/2.
• HTTP/3.

Jangan berasumsi bahwa mengaktifkan HTTP/3 berarti setiap crawler menggunakannya. Jika Googlebot, OAI-SearchBot, atau crawler lain terus menggunakan HTTP/2, HTTP/3 tidak dapat memengaruhi permintaan crawler tersebut.

Mengapa edge caching harus diuji dengan hati-hati

Jaringan pengiriman konten dapat mengurangi waktu ke byte pertama dengan menyajikan konten lebih dekat ke pemohon. Ini juga dapat mengurangi jumlah permintaan yang mencapai server asal. (web.dev)

Uji setidaknya tiga status cache:

1. Cold cache — Edge harus menghubungi asal.
2. Warm cache — Edge menyajikan halaman tanpa menghubungi asal.
3. Revalidated cache — Edge atau crawler menggunakan nilai ETag atau Last-Modified dan menerima respons 304 Not Modified.

Google secara khusus merekomendasikan caching HTTP yang efisien dan mendukung penggunaan respons 304 Not Modified untuk mengurangi pemrosesan dan bandwidth yang tidak perlu. (developers.google.com)

Jangan biarkan caching menyajikan konten usang atau tidak akurat kepada crawler. Catat:

• Cache hit atau miss.
• Usia cache.
• Lokasi edge.
• Waktu respons asal.
• Versi konten.
• Kode status.
• Header validasi.

Mengapa kompresi gambar harus terkait dengan Largest Contentful Paint

WebP dan AVIF umumnya memberikan kompresi yang lebih baik daripada format gambar lama. Gambar yang lebih kecil dapat mengurangi waktu transfer dan dapat meningkatkan Largest Contentful Paint ketika gambar tersebut adalah elemen Largest Contentful Paint. (web.dev)

Uji coba harus menggunakan:

• Dimensi gambar yang sama.
• Target kualitas visual yang sama.
• Gambar srcset responsif.
• Format modern dengan fallback yang sesuai.
• Nilai width dan height eksplisit.
• Tanpa lazy loading untuk gambar Largest Contentful Paint.
• URL gambar yang terlihat dalam HTML awal.

Kompresi gambar saja mungkin tidak meningkatkan Largest Contentful Paint jika penundaan sebenarnya berasal dari JavaScript atau penemuan sumber daya yang terlambat. Panduan kinerja Google mencatat bahwa mengurangi waktu unduh gambar dapat menggeser penundaan ke bagian lain halaman jika elemen Largest Contentful Paint ditampilkan terlambat. (web.dev)

3. Jalankan uji coba cukup lama

Uji coba singkat mungkin melewatkan efek dari penjadwalan crawl dan penyegaran indeks.

Desain yang praktis adalah:

• Dua minggu pengukuran baseline.
• Enam hingga dua belas minggu pengukuran perlakuan.
• Periode pembalikan atau crossover terakhir jika memungkinkan.

Untuk uji crossover, tukar perlakuan antara kelompok halaman yang cocok. Jika efek kinerja menghilang saat perlakuan dihilangkan, hasilnya lebih kuat daripada perbandingan sederhana sebelum dan sesudah.

Data lapangan Core Web Vitals harus dievaluasi selama periode yang sesuai. Laporan Pengalaman Pengguna Chrome menggunakan agregasi 28 hari bergulir, sehingga tidak dirancang untuk menunjukkan perubahan instan setelah penerapan. (developer.chrome.com)

4. Ukur populasi crawler lengkap

Jangan perlakukan semua lalu lintas otomatis sebagai satu kelompok.

Minimal, pisahkan:

Search crawler

• Googlebot.
• Bingbot.

Crawler pencarian kecerdasan buatan

• OAI-SearchBot.
• PerplexityBot.
• Claude-SearchBot.

Fetcher yang diminta pengguna

• Perplexity-User.
• Claude-User.
• Fetcher pengguna ChatGPT yang dapat diidentifikasi.

Training crawler

• GPTBot.
• ClaudeBot.
• Kontrol Google-Extended.

Training crawler tidak boleh digunakan sebagai proksi untuk kutipan pencarian kecerdasan buatan. Anthropic, OpenAI, dan Google membedakan antara crawler yang digunakan untuk pelatihan, pencarian, atau pengambilan yang diminta pengguna. Google juga menyatakan bahwa Google-Extended tidak memengaruhi penyertaan atau peringkat Google Search. (help.openai.com)

Perplexity juga membedakan antara PerplexityBot, yang mendukung pengindeksan pencarian, dan Perplexity-User, yang dapat mengambil halaman sebagai respons terhadap permintaan pengguna. (docs.perplexity.ai)

Verifikasi identitas crawler menggunakan rentang IP yang diterbitkan atau DNS terbalik di mana penyedia mendukungnya. String user-agent dapat disalin oleh crawler yang tidak terkait. Google secara khusus memperingatkan bahwa string user-agent Googlebot dapat dipalsukan. (developers.google.com)

Metrik yang Harus Dikumpulkan

Metrik kinerja

Kumpulkan data laboratorium dan pengguna nyata:

• Waktu ke byte pertama.
• First Contentful Paint.
• Largest Contentful Paint.
• Cumulative Layout Shift.
• Interaction to Next Paint.
• Total bobot halaman.
• Ukuran HTML awal.
• Ukuran transfer gambar.
• Jumlah permintaan.
• Waktu yang dihabiskan dalam pemrosesan server.
• Waktu yang dihabiskan menunggu sumber daya Largest Contentful Paint.
• Protokol HTTP.
• Status cache.

Google merekomendasikan target kasar waktu ke byte pertama sebesar 800 milidetik atau kurang, tetapi waktu ke byte pertama itu sendiri bukan Core Web Vital. (web.dev)

Ambang batas “baik” Core Web Vitals saat ini pada persentil ke-75 adalah:

• Largest Contentful Paint: 2,5 detik atau kurang.
• Cumulative Layout Shift: 0,1 atau kurang.
• Interaction to Next Paint: 200 milidetik atau kurang. (web.dev)

Metrik crawl

Untuk setiap permintaan crawler yang terverifikasi, catat:

text timestamp url user_agent verified_bot source_ip http_protocol status_code response_time time_to_first_byte bytes_sent cache_status edge_location etag last_modified referrer

Hitung:

text crawl_requests_per_url_day successful_fetch_rate 5xx_rate 429_rate median_recrawl_interval p75_recrawl_interval publication_to_first_fetch publication_to_first_index

Metrik kutipan kecerdasan buatan

Gunakan kumpulan kueri tetap di setiap platform. Kumpulan kueri harus mencakup:

• Pertanyaan faktual langsung.
• Pertanyaan perbandingan.
• Pertanyaan “terbaik” atau rekomendasi.
• Pertanyaan sensitif kesegaran.
• Pertanyaan di mana halaman yang diuji adalah jawaban terkuat.
• Pertanyaan di mana halaman yang diuji relevan tetapi tidak dominan.

Untuk setiap kueri, catat:

text engine model or experience timestamp location device query pages shown as sources page citation order whether the tested page was cited whether the tested page was retrieved but not cited answer text hash

Ulangi kueri karena jawaban kecerdasan buatan dapat bervariasi. Gunakan jadwal tetap, seperti tiga kali seminggu, dan catat perubahan pada mesin atau model.

Microsoft Bing Webmaster Tools kini menyediakan laporan Kinerja Kecerdasan Buatan yang menunjukkan halaman yang dikutip, kueri yang mendasari, dan tren kutipan di seluruh pengalaman kecerdasan buatan Microsoft yang didukung. Microsoft memperingatkan bahwa data tersebut diagregasi, disampel, dan observasional; tidak dapat membuktikan bahwa perubahan halaman tertentu menyebabkan perubahan kutipan. (bing.com)

Google juga mulai meluncurkan laporan kinerja kecerdasan buatan generatif khusus di Search Console pada Juni 2026. Laporan tersebut awalnya hanya tersedia untuk sebagian kecil situs web, sehingga akses mungkin bervariasi. (developers.google.com)

Analisis Statistik

Frekuensi crawling

Gunakan model hitungan efek campuran, seperti model binomial negatif:

text crawl_count ~ treatment + time_to_first_byte + page_age + update_frequency + sitemap_status + internal_links + server_errors + (1 | page) + (1 | crawler)

Efek halaman dan crawler penting karena beberapa halaman secara alami menerima lebih banyak perhatian daripada yang lain, dan crawler yang berbeda memiliki jadwal yang berbeda.

Penemuan dan pengindeksan

Gunakan analisis survival untuk:

• Waktu dari publikasi hingga pengambilan pertama.
• Waktu dari publikasi hingga indeks pertama.
• Waktu dari pembaruan hingga recrawl.

Hasil utamanya bukan hanya apakah sebuah halaman akhirnya di-crawl. Ini adalah apakah perlakuan mengurangi waktu yang diperlukan agar halaman ditemukan dan diproses.

Pemilihan kutipan kecerdasan buatan

Gunakan model logistik hierarkis:

text citation_present ~ treatment + time_to_first_byte + largest_contentful_paint + cumulative_layout_shift + indexed_status + search_visibility + content_freshness + page_authority + (1 | query) + (1 | engine) + (1 | page)

Jalankan dua model terpisah:

1. Model pengambilan — Apakah halaman diambil atau ditampilkan sebagai kandidat?
2. Model kutipan — Jika diambil, apakah halaman dikutip secara visual?

Perbedaan ini sangat penting. Peningkatan kinerja yang meningkatkan crawling tetapi tidak pengambilan bukanlah efek kutipan kecerdasan buatan. Peningkatan kinerja yang meningkatkan pengambilan tetapi tidak kutipan menunjukkan bahwa halaman sedang dipertimbangkan tetapi kalah selama pemilihan sumber.

Temuan yang Diharapkan

Ini adalah hipotesis kerja, bukan hasil eksperimen yang diklaim.

Hipotesis 1: Waktu ke byte pertama akan memiliki efek crawl yang paling jelas

Harapkan hubungan positif antara waktu ke byte pertama yang lebih rendah dan kapasitas crawl ketika:

• Situs memiliki banyak halaman.
• Halaman sering berubah.
• Server asal lambat atau kelebihan beban.
• Situs mengembalikan respons 5xx atau 429.
• Crawler menghabiskan waktu signifikan menunggu respons.

Harapkan sedikit efek terukur pada situs kecil dengan permintaan crawl yang rendah.

Hipotesis 2: Largest Contentful Paint akan penting melalui rendering dan pengiriman sumber daya

Harapkan Largest Contentful Paint yang lebih rendah akan membantu ketika:

• Halaman bergantung pada rendering browser.
• Konten penting berada di balik JavaScript.
• Gambar besar atau stylesheet diperlukan untuk pengindeksan.
• Crawler mengambil banyak sumber daya halaman.
• Perlakuan yang lebih lambat menghasilkan timeout atau rendering yang tidak lengkap.

Harapkan hubungan yang lemah ketika teks penting halaman sudah ada dalam HTML awal.

Hipotesis 3: Cumulative Layout Shift akan memiliki sedikit efek langsung

Harapkan tidak ada hubungan langsung yang berarti antara Cumulative Layout Shift dan frekuensi crawl atau tingkat kutipan setelah mengendalikan struktur halaman dan perilaku JavaScript.

Jika Cumulative Layout Shift tampaknya memprediksi kutipan, selidiki apakah itu bertindak sebagai proksi untuk:

• Client-side rendering.
• Penyisipan konten terlambat.
• Iklan tidak stabil.
• Teks tersembunyi atau tertunda.
• HTML yang tidak terstruktur dengan baik.

Hipotesis 4: Kecepatan saja tidak akan menghasilkan lebih banyak kutipan kecerdasan buatan

Prediktor terkuat dari pemilihan kutipan kemungkinan akan tetap:

• Relevansi dengan kueri.
• Kualitas konten.
• Jawaban yang jelas.
• Kesegaran.
• Otoritas dan kepercayaan.
• Kelayakan indeks pencarian.
• Peringkat pengambilan.
• Apakah halaman secara langsung mendukung klaim yang dibuat.

Panduan Google menekankan konten yang bermanfaat, andal, dan mengutamakan manusia serta menyatakan bahwa fitur pencarian kecerdasan buatan didasarkan pada sistem pencarian dan pengindeksan yang ada. (developers.google.com)

Anggaran Kinerja yang Disetel untuk Pengambilan Kecerdasan Buatan

Berikut ini adalah anggaran operasional yang diusulkan. Ini bukan formula peringkat kecerdasan buatan yang dipublikasikan.

Dokumentasi Google saat ini menyatakan bahwa Googlebot mengambil 2 megabyte pertama dari file yang didukung dan mengambil skrip eksternal serta stylesheet secara terpisah. Ini juga merekomendasikan menempatkan metadata penting dan data terstruktur di awal HTML. (developers.google.com)

Rekomendasi Implementasi

HTTP/3

Gunakan HTTP/3 ketika didukung oleh penyedia hosting dan jaringan pengiriman konten.

Ukur:

• Tingkat negosiasi HTTP/3.
• Tingkat fallback HTTP/2.
• Waktu penyiapan koneksi.
• Waktu ke byte pertama.
• Kinerja berdasarkan wilayah geografis.
• Kinerja berdasarkan crawler.

Jangan perlakukan HTTP/3 sebagai optimasi pencarian atau kecerdasan buatan yang dijamin. Ini adalah peningkatan transportasi yang mungkin hanya membantu klien yang menggunakannya.

Content Delivery Network Edge Caching

Untuk halaman publik yang tidak dipersonalisasi:

• Tetapkan aturan Cache-Control yang jelas.
• Gunakan caching jangka panjang untuk aset statis bervariasi.
• Gunakan caching singkat namun berguna untuk HTML yang sering diperbarui.
• Hindari fragmentasi cache dari parameter kueri yang tidak perlu.
• Pertahankan URL kanonis.
• Dukung ETag dan Last-Modified.
• Uji status cache dingin, hangat, dan divalidasi ulang.
• Konfirmasikan bahwa permintaan crawler menerima konten penting yang sama dengan permintaan manusia.

Jaringan pengiriman konten harus mengurangi latensi tanpa menciptakan versi halaman yang usang, tidak konsisten, atau khusus bot.

Kompresi Gambar

Untuk gambar:

• Gunakan AVIF atau WebP ketika kualitas visual dapat diterima.
• Sediakan ukuran gambar responsif.
• Jangan menyajikan gambar ukuran desktop ke layar mobile kecil.
• Jangan lazy-load gambar Largest Contentful Paint.
• Sertakan dimensi gambar.
• Tempatkan gambar Largest Contentful Paint dalam HTML awal.
• Gunakan fetchpriority="high" hanya jika sesuai.
• Pertahankan penjelasan penting dalam teks daripada hanya menyematkannya di dalam gambar.

Kompresi gambar paling berharga ketika gambar adalah elemen Largest Contentful Paint. Ini tidak akan memperbaiki halaman yang penundaan utamanya berasal dari rendering server atau eksekusi JavaScript. (web.dev)

Stabilitas Tata Letak

Untuk menurunkan Cumulative Layout Shift:

• Tetapkan atribut lebar dan tinggi pada gambar.
• Cadangkan ruang untuk iklan.
• Cadangkan ruang untuk video tersemat dan konten sosial.
• Hindari menyisipkan banner di atas teks yang ada.
• Gunakan strategi pemuatan font yang stabil.
• Hindari mengganti blok besar konten yang dirender server setelah halaman dimuat.

Perubahan ini meningkatkan pengalaman pengguna meskipun tidak memiliki efek terukur pada crawling atau kutipan. (web.dev)

Peralatan dan Pemantauan

Alat kinerja

Gunakan:

• Chrome User Experience Report untuk Core Web Vitals pengguna nyata.
• Application programming interface (API) Chrome User Experience Report untuk pengumpulan data lapangan otomatis.
• PageSpeed Insights untuk audit laboratorium dan data lapangan.
• Lighthouse untuk uji laboratorium yang dapat diulang.
• Lighthouse Continuous Integration untuk anggaran kinerja pull-request.
• WebPageTest untuk uji multi-lokasi, status cache, dan perbandingan protokol.
• Chrome DevTools untuk debugging Largest Contentful Paint dan layout shift.
• Pustaka JavaScript web-vitals untuk pemantauan pengguna nyata.

Application programming interface (API) Chrome User Experience Report menyediakan data lapangan teragregasi tingkat halaman dan tingkat asal, termasuk Largest Contentful Paint, Cumulative Layout Shift, Interaction to Next Paint, dan waktu eksperimental ke byte pertama. (developer.chrome.com)

Lighthouse Continuous Integration dapat menjalankan pemeriksaan kinerja pada setiap perubahan kode dan menyebabkan build gagal jika anggaran terlampaui. (github.com)

Pemantauan crawler

Gunakan log server, log edge, dan sejumlah kecil probe sintetik.

Contoh probe:

bash curl --http3 -sS -o /dev/null -D -
-w 'status=%{http_code}\nhttp_version=%{http_version}\nnamelookup=%{time_namelookup}\nconnect=%{time_connect}\nstarttransfer=%{time_starttransfer}\ntotal=%{time_total}\nsize=%{size_download}\n'
-A 'Mozilla/5.0 (compatible; OAI-SearchBot/1.0)'
https://example.com/page

Jalankan uji coba yang sama dengan:

• Googlebot.
• Bingbot.
• OAI-SearchBot.
• PerplexityBot.
• Claude-SearchBot.
• User-agent browser normal.

Uji coba harus memverifikasi:

• Kode status.
• Izin robots.
• Header respons.
• Konten HTML.
• Versi HTTP.
• Status cache.
• Waktu respons.
• Apakah teks penting ada tanpa JavaScript.

Pemantauan pencarian dan pengindeksan

Gunakan:

• Statistik crawl Google Search Console.
• Laporan pengindeksan halaman Google Search Console.
• Inspeksi URL Google Search Console.
• Data sitemap Google Search Console.
• Laporan kecerdasan buatan generatif Google Search Console jika tersedia.
• Permintaan crawl dan halaman yang diindeks Bing Webmaster Tools.
• Kinerja Kecerdasan Buatan Bing Webmaster Tools.
• Pemeriksaan sitemap harian dan lastmod.

Application programming interface (API) Search Console dapat mengambil data kinerja berdasarkan halaman, kueri, tanggal, perangkat, dan tampilan pencarian, tunduk pada batas datanya. (developers.google.com)

Pemantauan kutipan

Buat panel kutipan yang berisi 50 hingga 200 kueri stabil per topik. Jalankan panel sesuai jadwal tetap dan catat:

• Apakah platform mencari.
• Sumber mana yang muncul.
• Apakah URL yang diuji dikutip.
• Urutan kutipan.
• Tanggal dan waktu jawaban.
• Apakah halaman berubah.
• Apakah model atau pengalaman pencarian berubah.

Jangan membandingkan jumlah kutipan dari sistem yang berbeda seolah-olah setara. Microsoft menyatakan bahwa aktivitas kutipan bukanlah skor peringkat, skor otoritas, ukuran lalu lintas, atau skor kualitas. (bing.com)

Aturan Peringatan

Buat peringatan untuk:

• Waktu ke byte pertama meningkat lebih dari 25 persen.
• Largest Contentful Paint bergerak di atas 2,5 detik pada persentil ke-75.
• Cumulative Layout Shift bergerak di atas 0,1.
• Peningkatan berkelanjutan dalam respons 5xx atau 429.
• Penurunan tingkat keberhasilan crawler.
• Perubahan robots.txt.
• Kesalahan sitemap.
• Penurunan mendadak pada halaman yang diindeks.
• Penurunan mendadak dalam kutipan kecerdasan buatan di beberapa platform.
• Perubahan volume kutipan yang hanya memengaruhi satu platform.

Penurunan kutipan yang memengaruhi satu platform mungkin disebabkan oleh perubahan model, indeks, kueri, atau produk daripada masalah kinerja halaman. Microsoft secara eksplisit memperingatkan bahwa tren kutipan bersifat observasional dan dapat berubah karena pembaruan konten, permintaan pengguna, serta perubahan sistem atau model. (bing.com)

Kesimpulan Akhir

Kesimpulan yang paling dapat dipertahankan adalah:

Halaman yang lebih cepat dapat meningkatkan efisiensi crawl, terutama ketika latensi server, ukuran sumber daya, kesalahan, atau penundaan rendering menjadi faktor pembatas. Namun saat ini tidak ada bukti kuat bahwa Core Web Vitals yang lebih rendah secara langsung menyebabkan sistem kecerdasan buatan memilih halaman sebagai kutipan.

Rantai kausal yang diharapkan adalah:

text Lower latency → better server capacity → fewer failed or delayed fetches → faster discovery and processing → improved chance of being indexed and retrieved → possible increase in citations

Langkah terakhir tetap tidak pasti karena pemilihan kutipan bergantung pada relevansi, kualitas, kesegaran, otoritas, maksud kueri, peringkat pengambilan, dan perilaku setiap sistem kecerdasan buatan.

Bagi sebagian besar situs web, strategi kinerja yang tepat karena itu bukan “optimalkan untuk kutipan kecerdasan buatan” secara terpisah. Ini adalah:

1. Jaga konten penting tetap tersedia di HTML awal.
2. Jaga waktu ke byte pertama tetap stabil.
3. Gunakan edge caching untuk konten publik.
4. Kompres dan prioritaskan gambar penting.
5. Cegah layout shift.
6. Kembalikan kode status yang andal.
7. Jaga sitemap dan tautan internal tetap terkini.
8. Izinkan search crawler yang benar.
9. Ukur crawling, pengindeksan, pengambilan, dan kutipan sebagai tahapan terpisah.

Pendekatan tersebut menghasilkan situs web yang lebih cepat untuk orang-orang, situs yang lebih sehat untuk search crawler, dan dasar yang dapat diuji untuk memahami visibilitas kecerdasan buatan.