Jawaban singkat: Google Indexing API bukan alat untuk mempercepat indeksasi semua halaman bisnis. Penggunaannya dibatasi untuk halaman dengan JobPosting atau BroadcastEvent yang berada dalam VideoObject. Kuota bawaan 200 permintaan publish per hari per proyek bukan hak untuk mengirim artikel, katalog, atau landing page umum. Respons HTTP 200 membuktikan notifikasi diterima, bukan membuktikan URL masuk indeks.
Pada 16 Oktober 2026, Google memperbarui dokumentasi kuota Indexing API. Catatan perubahannya menyebut penyesuaian informasi batas dan proses, termasuk penghapusan formulir lama. Ini merupakan pembaruan dokumentasi, bukan pengumuman bahwa seluruh jenis halaman boleh memakai API tersebut. Bagi pemilik website Indonesia, keputusan pertama tetap sama: tentukan masalah sebenarnya sebelum membeli layanan yang menjanjikan indeksasi instan.
Panduan ini membahas pemilihan jalur pengiriman URL, pembacaan bukti, dan kontrol operasional. Fokusnya berbeda dari optimasi crawl budget untuk katalog besar atau pembuatan artikel baru. Tidak ada klaim hasil eksperimen klien di sini; seluruh batas produk merujuk dokumentasi Google, sedangkan alur audit berikut merupakan rekomendasi kerja yang bisa diperiksa sendiri.
Apa yang berubah pada dokumentasi 16 Oktober?
Halaman pembaruan Search Central mencatat perubahan halaman kuota dan penghapusan formulir yang sudah tidak sesuai. Halaman kuota yang dibuka saat penulisan menampilkan batas bawaan, tautan untuk melihat kuota di Google API Console, serta informasi bahwa pemakaian Indexing API tersedia tanpa pembayaran. Jangan menyimpulkan angka tersebut baru dinaikkan hanya karena tanggal dokumennya baru.
Ada perbedaan penting antara isi dokumentasi utama dan ringkasan otomatis yang kadang menyertainya. Ketika ada pertentangan, baca bagian utama yang menjelaskan ketentuan aktual. Jangan membangun prosedur pengajuan kuota berdasarkan cuplikan mesin pencari atau petunjuk lama yang sudah tidak tercantum. Catat tanggal pemeriksaan agar tim bisa menelusuri alasan suatu keputusan.
Batas berikut adalah angka bawaan yang ditampilkan Google, bukan target aktivitas harian. Kuota proyek yang benar-benar tersedia harus diperiksa di konsol. Jangan menjalankan pekerjaan produksi hanya berdasarkan tabel artikel ini, terutama jika sudah ada aplikasi lain yang menggunakan proyek yang sama.
| Jenis batas | Nilai bawaan | Implikasi operasional |
|---|---|---|
| Publish per hari per proyek | 200 | Mencakup URL_UPDATED dan URL_DELETED |
| Permintaan metadata per menit per proyek | 180 | Pemeriksaan notifikasi juga memiliki batas |
| Semua permintaan per menit per proyek | 380 | Perhitungkan aktivitas aplikasi lain |
Google menyebut reset kuota harian berlangsung pada tengah malam Pacific Time. Jangan menyamakannya dengan tengah malam WIB atau memakai selisih jam tetap sepanjang tahun tanpa memperhatikan perubahan waktu setempat. Untuk pelaporan tim Indonesia, simpan waktu kejadian dengan zona waktu yang jelas, lalu tampilkan konversinya di dashboard operasional.
Apakah website perusahaan dan toko online boleh memakainya?
Artikel edukasi, halaman layanan, dan produk toko online biasa tidak memenuhi cakupan API hanya karena memiliki structured data. Menambahkan JobPosting palsu pada landing page tidak mengubah halaman itu menjadi lowongan kerja yang sah. Demikian pula, video promosi rekaman bukan otomatis acara siaran langsung. Markup harus menggambarkan konten yang benar-benar dilihat pengguna.
Situs perusahaan bisa memiliki bagian karier yang memenuhi cakupan, meskipun halaman layanan di domain yang sama tidak. Evaluasi dilakukan per halaman dan jenis konten, bukan per merek. Pisahkan antrean notifikasi lowongan yang valid dari antrean publikasi blog. Pemisahan ini mencegah integrasi yang awalnya benar berubah menjadi pengiriman seluruh situs setelah pengembang menambahkan fitur baru.
Untuk situs biasa, prioritasnya adalah URL yang dapat ditemukan, respons server yang benar, canonical yang konsisten, sitemap yang valid, serta konten yang memang layak ditampilkan. Jika masalahnya halaman diblokir atau kontennya duplikat, menambah mekanisme notifikasi tidak memperbaiki akar masalah. Lihat juga panduan audit technical SEO sebelum memilih solusi tambahan.
Bukti apa yang membedakan diterima, dirayapi, dan diindeks?
Ketiga kondisi tersebut tidak boleh digabung menjadi satu label sukses. Notifikasi diterima berarti endpoint menerima permintaan. Dirayapi berarti crawler mengambil halaman. Diindeks berarti Google menyimpan halaman sebagai bagian dari indeksnya; itu pun belum menjamin halaman tampil untuk setiap kueri. Masing-masing memerlukan bukti dari sumber yang sesuai.
Dokumentasi penggunaan API menyatakan respons HTTP 200 berarti Google dapat mencoba merayapi kembali URL tersebut segera. Bahasa ini bukan jaminan waktu atau kepastian indeksasi. Endpoint metadata mengembalikan informasi notifikasi terakhir, bukan jawaban tentang kapan halaman masuk indeks. Dashboard yang hanya menampilkan respons publish tidak boleh diberi judul laporan halaman terindeks.
| Pertanyaan tim | Bukti yang dicari | Yang tidak cukup |
|---|---|---|
| Apakah notifikasi diterima? | Respons API dan metadata notifikasi | Pesan sukses aplikasi tanpa respons tersimpan |
| Apakah halaman dapat diakses? | Status HTTP, robots, konten awal | URL terlihat normal di browser administrator |
| Apakah Google memilih URL ini? | URL Inspection dan canonical pilihan Google | Canonical yang kita tulis sendiri |
| Apakah halaman menghasilkan kunjungan? | Data performa Search Console | Status indeks atau jumlah submit |
Jika akses Search Console belum tersedia, tandai status indeksasi sebagai belum diverifikasi. Jangan menggantinya dengan pencarian site: lalu mengklaim jumlah indeks lengkap. Pemeriksaan publik bisa membantu investigasi awal, tetapi keputusan konsolidasi halaman atau evaluasi vendor membutuhkan bukti yang lebih terarah dan konteks yang memadai.
Bagaimana mengaudit layanan yang menjanjikan indeksasi cepat?
Minta vendor menjelaskan jenis halaman yang dikirim, endpoint yang digunakan, dan definisi sukses dalam laporannya. Untuk artikel biasa, jawaban bahwa semua URL akan dimasukkan lewat Indexing API merupakan alasan untuk meninjau ulang metode tersebut. Hindari menilai kualitas layanan hanya dari banyaknya permintaan yang bisa dikirim atau tangkapan layar status sukses.
Periksa juga kepemilikan proyek dan akses. Proyek cloud serta properti Search Console sebaiknya tetap berada di bawah kendali organisasi yang berhak. Jangan mengirim private key lewat percakapan terbuka, menanam kredensial di JavaScript publik, atau menyerahkan akses yang tidak diperlukan. Gunakan pemberian akses resmi sesuai kebutuhan pekerjaan serta prosedur pencabutannya ketika kerja sama berakhir.
Google memperingatkan bahwa penyalahgunaan, termasuk penggunaan banyak akun untuk melampaui batas, dapat berujung pencabutan akses. Karena itu, tawaran memutar banyak akun demi melewati kuota bukan optimasi teknis yang aman. Ukur vendor dari diagnosis, transparansi, kepatuhan, dan bukti hasil yang bisa diverifikasi, bukan dari janji kepastian ranking atau indeksasi.
Bagaimana alur yang benar untuk halaman yang memenuhi syarat?
Mulailah dari inventaris URL lowongan atau siaran langsung yang benar-benar memenuhi cakupan. Verifikasi bahwa konten, markup, status HTTP, dan akses publik saling sesuai. Lalu ikuti prasyarat Google: aktifkan API, buat service account, verifikasi kepemilikan Search Console, dan siapkan autentikasi. Jangan melewati pemeriksaan konten hanya karena integrasi teknis sudah bisa mengembalikan token.
Simpan antrean berdasarkan perubahan yang nyata, bukan pengiriman ulang seluruh daftar setiap kali proses dijalankan. Catat URL, jenis notifikasi, waktu, status respons, serta alasan perubahan. Jika ada kegagalan jaringan atau pembatasan, gunakan percobaan ulang yang terbatas sesuai petunjuk API. Hindari pengulangan tanpa batas yang menghabiskan kuota dan menyulitkan diagnosis.
Pengiriman batch dapat menggabungkan hingga 100 panggilan dalam satu permintaan HTTP. Ini mengurangi jumlah koneksi, bukan memberi tambahan kuota atau menghapus batas per URL. Periksa hasil setiap item secara terpisah. Satu batch yang terkirim tidak membuktikan semua item di dalamnya berhasil, apalagi membuktikan seluruh halaman telah diindeks.
Apa prosedur ketika lowongan atau acara dihapus?
Untuk pemberitahuan URL_DELETED, dokumentasi Google meminta halaman lebih dahulu memberikan status 404 atau 410, atau memuat meta robots noindex. Notifikasi bukan pengganti perubahan keadaan halaman. Jangan mengirim permintaan penghapusan saat URL masih menampilkan konten aktif yang sebenarnya ingin dipertahankan dalam pencarian.
Bedakan penghapusan dari perpindahan. Jika halaman dipindahkan, audit redirect dan target penggantinya; jangan otomatis menjalankan prosedur penghapusan hanya karena slug lama tidak digunakan lagi. Keputusan harus mengikuti keadaan konten serta pengalaman pengguna. Redirect seluruh lowongan kedaluwarsa ke homepage tanpa menilai relevansinya juga bukan jawaban universal.
Simpan daftar perubahan supaya operator dapat menelusuri siapa yang memutuskan penghapusan dan mengapa. Sebelum menjalankan antrean produksi, periksa sampel URL secara manual. Pengamanan kecil ini lebih bernilai daripada menambah otomatisasi yang membuat kesalahan tersebar lebih cepat. Bila tindakan penghapusan tidak disengaja, hentikan antrean dan pulihkan keadaan situs sesuai prosedur yang disetujui.
Checklist apa yang dipakai sebelum menyatakan pekerjaan selesai?
- Jenis halaman sesuai cakupan
JobPostingatau siaran langsung yang didukung. - Konten nyata dan structured data tidak saling bertentangan.
- Kepemilikan proyek, kredensial, serta akses Search Console terdokumentasi.
- Kuota aktual diperiksa di konsol, bukan diasumsikan dari batas bawaan.
- Waktu reset dipahami dalam Pacific Time, bukan disamakan dengan WIB.
- Respons per URL disimpan tanpa membocorkan token atau private key.
- Status notifikasi dipisahkan dari status crawl dan status indeksasi.
- Penghapusan mengikuti keadaan halaman dan persyaratan Google.
- Tidak ada rotasi akun untuk menghindari batas pemakaian.
- Laporan menyebut data yang belum tersedia secara eksplisit.
Untuk blog dan halaman bisnis umum, gunakan waktu audit untuk memeriksa discoverability, kualitas konten, internal link, serta sitemap. Baca panduan crawl budget dan navigasi katalog bila masalahnya ledakan URL. Untuk perbaikan yang membutuhkan akses sumber dan implementasi, layanan SEO Socta dapat menjadi titik awal pembahasan cakupan audit, tanpa menjanjikan tanggal indeksasi atau kenaikan ranking.
Sumber primer dan tanggal pemeriksaan
- Google Search Central, Latest documentation updates, entri 16 Oktober 2026 tentang pembaruan kuota Indexing API; diakses 18 Oktober 2026.
- Google Search Central, Quota and pricing information, terakhir diperbarui 16 Oktober 2026; diakses 18 Oktober 2026.
- Google Search Central, Indexing API Quickstart, terakhir diperbarui 16 Oktober 2026; diakses 18 Oktober 2026.
- Google Search Central, Using the Indexing API, diperiksa 18 Oktober 2026 untuk arti respons, batch, metadata, dan penghapusan URL.
