401 Tidak Terotorisasi

TL;DR — 401 Tidak Terotorisasi berarti server meminta Anda masuk sebelum menyerahkan halaman; kredensial Anda hilang, salah, atau kedaluwarsa. Mesin pencari tidak pernah masuk, jadi jika sebuah halaman mengembalikan 401 kepada Googlebot, Google tidak dapat melihatnya dan tidak akan memasukkannya ke hasil pencarian. Itu memang yang diinginkan untuk halaman privat (staging, khusus anggota), dan baru menjadi masalah ketika terjadi pada halaman yang ingin Anda ditemukan orang.

Apa arti 401

Saat browser Anda (atau crawler mesin pencari) meminta halaman kepada server, server menjawab dengan kode status. 401 Tidak Terotorisasi adalah cara server berkata: “I’m not going to show you this until you prove who you are.” (terjemahan) “Saya tidak akan menampilkan ini sampai Anda membuktikan identitas Anda.” Kredensial yang Anda kirim hilang, tidak valid, atau kedaluwarsa—jadi Anda perlu masuk. Evidence for this claim A 401 response means the request lacks valid authentication credentials and the response must include a WWW-Authenticate challenge. Scope: RFC 9110 defines the status semantics and required challenge header; it does not prescribe a site's authentication product or login flow. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.5.2 — 401 Unauthorized

Anda melihatnya setiap kali halaman menampilkan kotak nama pengguna/kata sandi atau mengarahkan Anda ke layar login. Di balik layar, itu sering kali merupakan 401.

Mengapa ini penting untuk SEO

Inilah masalahnya: Googlebot dan Bingbot tidak pernah masuk. Mereka tidak memiliki nama pengguna dan kata sandi untuk situs Anda, dan tidak mengetik di kotak login. Jadi ketika crawler menemukan 401, ia tidak dapat melewati gerbang tersebut. Bagi Google, konten halaman itu secara efektif tidak ada.

Hasil praktisnya:

• Halaman yang mengembalikan 401 tidak akan diindeks—halaman itu tidak dapat muncul di pencarian.
• Halaman yang sebelumnya berperingkat tetapi kini mengembalikan 401 akan keluar dari indeks seiring waktu. Evidence for this claim Google does not index 4xx URLs and removes already-indexed 4xx URLs over time. Scope: Google's crawler documentation supports the Search indexing outcome for 401 responses; it does not address access decisions for private users. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers

Kapan 401 wajar (dan kapan menjadi masalah)

401 tidak otomatis merupakan bug yang harus diperbaiki. Itu adalah jawaban yang tepat untuk halaman yang memang harus privat:

• 401 yang baik: situs staging, area khusus anggota, alat admin internal, atau portal klien. Anda memang ingin semuanya tersembunyi dari Google, dan dinding login melakukan tugas itu.
• 401 yang buruk: artikel blog, halaman produk, atau landing page yang seharusnya publik tetapi tiba-tiba meminta login—biasanya karena firewall salah konfigurasi, perlindungan kata sandi yang tertinggal, token kedaluwarsa, atau konflik plugin.

Alarm palsu yang paling umum adalah “but it loads fine for me!” (Terjemahan: “Tetapi di saya halaman ini dimuat dengan baik!”)—karena Anda sudah login sedangkan crawler belum. Untuk melihat apa yang dilihat Googlebot, buka halaman dalam jendela privat/incognito atau gunakan alat Inspeksi URL di Google Search Console.

401 vs 403—versi singkat

Anda akan sering melihat 401 disebut berdampingan dengan 403 Forbidden. Keduanya terdengar mirip, tetapi artinya berbeda:

• 401 = “Who are you?” (terjemahan) “Siapa Anda?” Kredensial hilang—silakan masuk.
• 403 = “I know who you are, and no.” (terjemahan) “Saya tahu siapa Anda, tetapi tidak.” Server memahami permintaan, tetapi tetap menolak akses.

Bagi Google, hasilnya sama: keduanya tidak diindeks karena crawler tidak dapat menjangkau konten dengan cara apa pun.

Ingin detail teknis—header tepat yang wajib dikirim 401, isi dokumentasi Google, dan cara memperbaiki 401 yang tidak diinginkan? Beralihlah ke tab Advanced.

TL;DR — 401 Tidak Terotorisasi adalah kesalahan klien (RFC 9110 §15.5.2, yang menggantikan RFC 7235) yang berarti permintaan tidak memiliki kredensial autentikasi yang valid—termasuk kredensial yang sudah dikirim tetapi ditolak, bukan hanya yang tidak pernah dikirim. 401 yang sesuai spesifikasi juga mengirim header WWW-Authenticate yang menyebutkan skema yang diharapkan. Ini berbeda dari 403 (penolakan yang tidak memerlukan tantangan tersebut dan bisa sama sekali tidak berkaitan dengan kredensial), tetapi Google memperlakukan semua 4xx kecuali 429 dengan cara sama untuk pengindeksan: kontennya “doesn’t exist” (Terjemahan: “tidak ada”), sehingga tidak diindeks dan URL yang sebelumnya diindeks akan turun dari indeks seiring waktu. Karena Googlebot biasa tidak pernah mengirim kredensial, 403 kepada Googlebot—menurut pernyataan Google sendiri—biasanya merupakan salah konfigurasi server. 401/403 tidak memengaruhi laju crawl seluruh situs (mitos yang sering diulang), walaupun URL individual yang terus menghasilkan 4xx akan lebih jarang di-crawl ulang. 401 adalah cara yang benar dan direkomendasikan Google untuk membatasi konten yang benar-benar privat; ini hanya masalah ketika mengenai halaman yang ingin Anda indeks. Untuk konten berbayar ada jalur yang disetujui, bukan 401 menyeluruh.

Apa sebenarnya 401 itu

401 Tidak Terotorisasi adalah respons kesalahan klien. Definisi MDN adalah penjelasan teknis yang paling jelas:

“The HTTP 401 Unauthorized client error response status code indicates that a request was not successful because it lacks valid authentication credentials for the requested resource. This status code is sent with an HTTP WWW-Authenticate response header that contains information on the authentication scheme the server expects the client to include to make the request successfully.” (terjemahan) “Kode status respons kesalahan klien HTTP 401 Tidak Terotorisasi menunjukkan bahwa permintaan tidak berhasil karena tidak memiliki kredensial autentikasi yang valid untuk sumber daya yang diminta. Kode status ini dikirim bersama header respons HTTP WWW-Authenticate yang berisi informasi tentang skema autentikasi yang diharapkan server untuk disertakan klien agar permintaan berhasil.”

Ada dua hal penting dari definisi itu. Pertama, “autentikasi”—peminta belum membuktikan identitasnya. Biasanya berarti kredensial hilang, tidak valid, atau kedaluwarsa, tetapi 401 juga dapat muncul setelah kredensial sudah dikirim lalu ditolak; jadi jangan menganggap tidak ada header autentikasi tanpa memeriksa permintaannya. Kedua, 401 yang sesuai spesifikasi harus membawa header WWW-Authenticate—menurut RFC 9110 §15.5.2, yang menggantikan RFC 7235—untuk memberi tahu klien skema yang diharapkan (HTTP Basic Auth, token Bearer, alur cookie sesi, dan sebagainya). Saat men-debug 401, header itu adalah hal pertama yang harus diperiksa: apakah ada sama sekali dan skema apa yang disebutkannya. Evidence for this claim A 401 response means the request lacks valid authentication credentials and the response must include a WWW-Authenticate challenge. Scope: RFC 9110 defines the status semantics and required challenge header; it does not prescribe a site's authentication product or login flow. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.5.2 — 401 Unauthorized

Dalam panduan kode status saya sendiri, saya merangkum 401 sebagai: “the client hasn’t identified or verified itself when needed.” (terjemahan) “klien belum mengidentifikasi atau memverifikasi dirinya ketika diperlukan.” Itulah intinya—belum ada yang menyatakan identitasnya.

401 vs 403 Forbidden—perbedaan yang penting

Di sinilah banyak orang menjadi rancu, jadi mari kita pertegas. Dalam satu baris:

• 401 = “Who are you?” (terjemahan) “Siapa Anda?”—kredensial hilang atau tidak valid; lakukan autentikasi lalu coba lagi.
• 403 = “I know who you are, but no.” (terjemahan) “Saya tahu siapa Anda, tetapi tidak.”—permintaan dipahami, tetapi akses ditolak terlepas dari kredensial.

MDN menjelaskannya dengan cara yang sama:

“A 401 Unauthorized is similar to the 403 Forbidden response, except that a 403 is returned when a request contains valid credentials, but the client does not have permissions to perform a certain action.” (terjemahan) “401 Tidak Terotorisasi mirip dengan respons 403 Forbidden, kecuali 403 dikembalikan ketika permintaan berisi kredensial yang valid tetapi klien tidak memiliki izin untuk melakukan tindakan tertentu.”

Saya membuat kontras yang sama dalam panduan saya: 401 adalah “the client hasn’t identified or verified itself when needed,” (terjemahan) “klien belum mengidentifikasi atau memverifikasi dirinya ketika diperlukan,” sedangkan 403 adalah “the client is known but doesn’t have access rights.” (terjemahan) “klien sudah dikenal tetapi tidak memiliki hak akses.” Ini adalah perbedaan autentikasi dan otorisasi.

Ringkasan itu dapat diandalkan, tetapi berikut uji protokol yang lebih tajam jika Anda harus memilih di kode atau aturan WAF: 401 memerlukan tantangan WWW-Authenticate—RFC 9110 menyatakannya sebagai MUST—sedangkan 403 tidak wajib memilikinya karena penolakan 403 dapat disebabkan hal yang sama sekali tidak berkaitan dengan kredensial (blokir IP, aturan izin, atau kebijakan pembatasan laju). Jadi “apakah kredensial ada?” bukan cara yang andal untuk membedakan keduanya: 401 dapat mengikuti kredensial yang ditolak, bukan hanya yang hilang. Saat menentukan kode yang dikembalikan, tanyakan: apakah saya mengeluarkan tantangan autentikasi (401) atau penolakan langsung (403)?

Inilah twist SEO yang tidak terlalu terlihat, dan ini memang poin Google tentang 403. Googlebot biasa tidak pernah mengirim kredensial. Jadi 403 yang diberikan khusus kepada Googlebot berarti, menurut Google sendiri, server salah menanganinya:

Google memperingatkan bahwa 403 kepada Googlebot biasanya menandakan salah konfigurasi: Googlebot tidak pernah mengirim kredensial, sehingga penolakan yang dibingkai sebagai kredensial ditolak tidak semestinya terjadi. Halaman yang terus mengembalikan 403 tidak akan diindeks.

Itu diagnosis yang berguna. 401 kepada Googlebot dapat disengaja (halaman memang digate). 403 kepada Googlebot biasanya menunjukkan salah konfigurasi—Googlebot tidak mengirim kredensial, jadi tidak ada alasan untuk memicu respons “kredensial ditolak” untuknya. Jika Anda melihat 403 pada halaman yang seharusnya dapat dijangkau Googlebot, curigai konfigurasi CDN, WAF, atau server terlebih dahulu. (Ini menjelaskan crawler Google yang umum. Google mendokumentasikan crawler khusus dan pengambil yang dipicu pengguna sebagai kategori terpisah dengan perilaku masing-masing, jadi jangan menggeneralisasi aturan “tidak pernah mengirim kredensial” ke setiap integrasi produk Google tanpa memeriksanya.)

Baris terakhir adalah intinya: untuk pengindeksan, Google memperlakukan keduanya sama.

Cara Google memperlakukan halaman 401

Dokumentasi kode status HTTP Google menjelaskan keluarga 4xx secara tegas:

“Google doesn’t use the content from URLs that return 4xx status codes. If a URL was previously used but is now returning 4xx status code, Google systems will stop using the URL over time. In the case of Google Search, Google doesn’t index URLs that return a 4xx status code, and URLs that are already indexed and return a 4xx status code are removed from the index.” (terjemahan) “Google tidak menggunakan konten dari URL yang mengembalikan kode status 4xx. Jika URL sebelumnya digunakan tetapi kini mengembalikan kode status 4xx, sistem Google akan berhenti menggunakan URL itu seiring waktu. Dalam Google Penelusuran, Google tidak mengindeks URL yang mengembalikan kode status 4xx, dan URL yang sudah diindeks lalu mengembalikan kode status 4xx dihapus dari indeks.” Evidence for this claim Google does not index 4xx URLs and removes already-indexed 4xx URLs over time. Scope: Google's crawler documentation supports the Search indexing outcome for 401 responses; it does not address access decisions for private users. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers

401 bukan pengecualian dalam keluarga itu. Dalam tabel dokumentasi, 401 (unauthorized) dan 403 (forbidden) tercantum sebagai baris terpisah dengan satu penjelasan yang sama:

“All 4xx errors, except 429, are treated the same: Google crawlers inform the next processing system that the content doesn’t exist.” (terjemahan) “Semua kesalahan 4xx, kecuali 429, diperlakukan sama: crawler Google memberi tahu sistem pemrosesan berikutnya bahwa konten tersebut tidak ada.”

Jadi hasilnya biner, bukan penurunan peringkat. Halaman yang menghasilkan 401 tidak “berperingkat lebih rendah”—halaman itu sama sekali tidak diindeks, atau dihapus jika sebelumnya sudah diindeks. Tidak ada penalti parsial. Ini sejalan dengan klaim dasar dalam panduan saya: 4xxs akan membuat halaman keluar dari indeks. Artikel ini adalah pendalaman khusus 401 di atas dasar tersebut.

Ada satu nuansa tentang waktu: penghapusan terjadi “over time” (Terjemahan: “seiring waktu”), bukan pada pengambilan pertama yang buruk. Dokumentasi Google menggambarkan proses bertahap, dan sistem crawling secara historis memang menoleransi kesalahan singkat sebelum menganggap URL benar-benar hilang.

Mitos laju crawl—401 TIDAK memperlambat crawling

Hal ini sering menjebak artikel yang sebenarnya bagus, jadi mari kita tepat. 401 (atau 403) tidak memperlambat laju crawl Google. Google mengatakannya secara langsung:

Google menyatakan bahwa kode status 401 dan 403 bukan alat untuk membatasi laju crawl; semua kode 4xx selain 429 tidak berdampak pada laju tersebut.

Ini penting karena Anda akan menemukan saran bahwa menggating halaman dengan 401 “menghemat anggaran crawl” atau “membuang anggaran crawl”—keduanya keliru. Hanya 429 (dan sinyal gaya 5xx seperti 503) yang memberi tahu Googlebot untuk mundur. 401 bukan throttle; itu sinyal “konten tidak ada” untuk pengindeksan, titik. Jika benar-benar ingin memperlambat crawl sementara, gunakan 429/503, bukan 401/403.

Satu catatan ruang lingkup, karena dua klaim ini mudah tercampur: “tidak memengaruhi laju crawl” berkaitan dengan laju crawl seluruh situs. Secara terpisah, Google mengatakan URL individual yang terus mengembalikan 4xx akan di-crawl ulang lebih jarang seiring waktu—frekuensi percobaannya turun bertahap. Jadi anggaran crawl tingkat situs tidak diperlambat, tetapi URL yang terus menghasilkan 401 memang diperiksa lebih jarang karena Google menurunkan prioritasnya.

Ada juga kasus khusus yang perlu diketahui: 401 pada halaman biasa dan 401 pada /robots.txt sendiri tidak ditangani dengan cara yang sama. Jika file robots.txt mengembalikan non-429 4xx (termasuk 401), Google memperlakukannya seolah-olah tidak ada robots.txt sama sekali—diasumsikan tidak ada pembatasan crawl dari file itu, bukan seluruh situs dianggap tidak dapat dijangkau. Jangan letakkan /robots.txt di balik dinding autentikasi yang sama dengan halaman privat.

Apakah 401 selalu masalah? Tidak.

401 hanya merupakan bug jika tidak disengaja pada halaman yang ingin Anda jadikan publik. Jika halaman memang privat, 401 adalah cara yang tepat untuk menjauhkannya dari pencarian—dan itulah yang direkomendasikan Google. John Mueller pernah menyampaikannya dengan jelas (dikutip Search Engine Journal): pendekatan ideal adalah autentikasi sisi server yang mencegah pengguna biasa melihat konten—“that would include GoogleBot” (terjemahan) “itu termasuk GoogleBot.” (Dikutip oleh Search Engine Journal dari hangout Google tahun 2019; perlakukan sebagai pernyataan yang diparafrasakan secara akurat, bukan kutipan yang diverifikasi per fragmen.)

Autentikasi sisi server (yang menghasilkan 401) adalah mekanisme yang direkomendasikan untuk menyembunyikan konten nonpublik—lebih dahulu daripada robots.txt—karena benar-benar memblokir akses, bukan sekadar meminta bot untuk tidak datang.

Kerangka keputusannya sederhana:

• Harus tetap 401: lingkungan staging, area khusus anggota, alat internal, dan apa pun yang benar-benar privat. Itu bekerja sesuai rancangan; jangan “perbaiki”.
• Perlu diperbaiki: halaman publik yang dapat diindeks tetapi secara tidak sengaja mengembalikan 401—false positive CDN/WAF, Basic Auth yang tertinggal, token kedaluwarsa, atau konflik plugin/middleware.

Dampak SEO dan jebakan “di saya berfungsi”

Kegagalan praktis yang mungkin terjadi:

• Halaman yang ingin diindeks tetap tidak terlihat sampai gerbangnya dilepas.
• Halaman yang sebelumnya berperingkat menghilang jika mulai mengembalikan 401.
• Jebakan “di saya berfungsi”: orang yang menguji sudah terautentikasi, login, atau memakai IP yang diizinkan—crawler tidak. Panduan Google sendiri untuk kasus 401: “You can verify this error by visiting the page in incognito mode.” (terjemahan) “Anda dapat memverifikasi kesalahan ini dengan mengunjungi halaman dalam mode incognito.” Lebih baik lagi, uji tanpa autentikasi dengan curl -I https://example.com/page, atau gunakan Inspeksi URL / Live Test Search Console.

Jika Anda memang perlu membiarkan crawler nyata lewat, verifikasi dengan IP / reverse-DNS, jangan hanya mempercayai string user-agent—string user-agent mudah dipalsukan, sehingga mengizinkan “Googlebot” hanya berdasarkan nama adalah celah keamanan, bukan perbaikan.

Bagaimana dengan konten berbayar atau khusus pelanggan?

401 menyeluruh kepada semua orang (termasuk Googlebot) bukan satu-satunya pilihan jika Anda ingin konten berpagar tetap dapat berperingkat. Google mendukung pengindeksan konten berbayar melalui structured data isAccessibleForFree, disertai pemberian akses kepada identitas crawler Google khusus untuk konten pelanggan/terdaftar. Tujuan markup tersebut adalah:

“This structured data helps Google differentiate paywalled content from the practice of cloaking, which violates spam policies.” (terjemahan) “Data terstruktur ini membantu Google membedakan konten berbayar dari praktik cloaking, yang melanggar kebijakan spam.”

Peringatannya jelas: menyajikan konten penuh secara diam-diam hanya kepada Googlebot, tanpa pengungkapan data terstruktur, adalah cloaking—risiko pelanggaran kebijakan spam. Jika ingin konten berpagar diindeks, lakukan dengan cara yang disetujui (markup + akses crawler), bukan melewati gerbang secara diam-diam.

Cara memperbaiki 401 yang tidak diinginkan

1. Pastikan memang tidak diinginkan. Apakah halaman ini seharusnya publik? Jika hanya staging atau khusus anggota, tidak ada yang perlu diperbaiki.
2. Hapus persyaratan autentikasi pada halaman publik—lepaskan Basic Auth yang tertinggal (.htaccess/nginx), perbaiki token kedaluwarsa, dan selesaikan konflik plugin/middleware.
3. Periksa CDN/WAF—jangan berasumsi sudah tahu lapisan mana yang mengeluarkan 401. Respons (dan header WWW-Authenticate) menunjukkan ada tantangan; itu tidak menunjukkan asalnya. Aplikasi, proxy identitas/autentikasi, aturan manajemen bot CDN/WAF, dan server origin semuanya dapat menghasilkan 401. False positive dari aturan bot di edge sering menjadi penyebab; periksa log di setiap lapisan dan verifikasi Googlebot dengan reverse DNS sebelum membuat allowlist.
4. Izinkan crawler terverifikasi lewat IP/reverse-DNS, bukan user-agent.
5. Jangan gunakan 401 untuk menghapus indeks pada halaman yang sebenarnya bisa dibuat publik—gunakan noindex (dengan crawling tetap diizinkan). Dinding login untuk konten yang memang harus privat.
6. Validasi perbaikan dengan Live Test Inspeksi URL—anggap hasil lulus sebagai konfirmasi pengambilan saat ini, bukan jaminan. Google tidak menjanjikan jadwal tetap untuk crawl ulang, pengindeksan ulang, atau pemulihan peringkat setelah 401 diperbaiki; Live Test yang lulus menunjukkan pengambilan langsung Google berhasil, bukan bahwa crawling terjadwal atau pengindeksan sudah menyusul. Beri waktu dan periksa kembali laporan Page Indexing, jangan mengharapkan pembalikan seketika.

Untuk alur diagnosis–perbaikan–validasi lengkap di Google Search Console, khususnya status Page Indexing “Blocked due to unauthorized request (401)”, lihat artikel pendamping khusus—artikel ini tetap berada pada tingkat protokol dan konsep.

Bing

Bing secara fungsional bekerja dengan cara yang sama: URL yang mengembalikan 401 (atau 403) kepada Bingbot tidak dapat diakses dan tidak akan diindeks. Bingbot memerlukan akses tanpa autentikasi seperti Googlebot; untuk allowlist, verifikasi melalui rentang IP yang dipublikasikan, bukan user-agent.

Ringkasan AI

Inti ringkas dari versi Advanced:

• 401 = kredensial hilang, tidak valid, atau ditolak (“who are you?” (terjemahan) “siapa Anda?”). RFC 9110 §15.5.2 (yang menggantikan RFC 7235) mewajibkan header WWW-Authenticate yang menyebut skema yang harus digunakan klien—dan 401 tidak membuktikan bahwa kredensial tidak dikirim; 401 dapat muncul setelah kredensial dikirim lalu ditolak.
• 401 vs 403, uji yang andal: 401 memerlukan tantangan WWW-Authenticate; 403 tidak, karena penolakan 403 bisa sama sekali tidak terkait kredensial (blokir IP, aturan izin, batas laju). Karena Googlebot biasa tidak pernah mengirim kredensial, 403 kepada Googlebot biasanya merupakan salah konfigurasi server menurut Google—Google mendokumentasikan identitas crawler/pengambil lain secara terpisah, jadi jangan menggeneralisasikannya ke setiap klien Google.
• Hasil pengindeksan identik: Google memperlakukan semua 4xx kecuali 429 dengan cara sama—kontennya “doesn’t exist” (terjemahan) “tidak ada”, jadi tidak diindeks, dan URL yang sebelumnya diindeks turun seiring waktu. Ini biner, bukan penurunan peringkat.
• Tidak berdampak pada laju crawl seluruh situs, tetapi frekuensi per URL turun: 401/403 tidak membatasi crawl keseluruhan—hanya sinyal 429/bergaya 5xx yang melakukannya. Secara terpisah, URL individual yang terus menghasilkan 4xx di-crawl ulang lebih jarang. Selain itu, 401 pada /robots.txt diperlakukan sebagai “tidak ada robots.txt”, bukan blokir.
• 401 sering kali benar: autentikasi sisi server adalah cara yang direkomendasikan Google untuk menyembunyikan halaman staging/anggota/privat. Ini hanya masalah ketika mengenai halaman yang ingin Anda indeks—dan respons itu sendiri tidak memberi tahu lapisan mana (aplikasi, proxy identitas, CDN/WAF, origin) yang menghasilkannya.
• Jebakan “di saya berfungsi”: Anda sudah terautentikasi, crawler belum. Uji dalam incognito, dengan curl -I, atau Inspeksi URL—Live Test yang lulus hanya memastikan pengambilan saat ini, bukan jadwal crawl ulang/pemulihan yang terjamin.
• Paywall: gunakan markup isAccessibleForFree + akses crawler, bukan 401 menyeluruh. Menyajikan konten penuh diam-diam kepada Googlebot adalah cloaking.
• Perbaikan: hapus persyaratan autentikasi / verifikasi crawler dengan IP/reverse-DNS (jangan user-agent) / gunakan noindex—bukan 401—untuk menghapus indeks halaman yang sebenarnya bisa dibuat publik.

Dokumentasi resmi

Dokumentasi sumber utama dari Google dan spesifikasi HTTP.

Google

• Cara kode status HTTP, kesalahan jaringan dan DNS memengaruhi Google Penelusuran —penanganan 4xx, aturan “diperlakukan sama”, dan peringatan laju crawl untuk 401/403.
• Laporan Page Indexing —definisi status “Blocked due to unauthorized request (401)” dan “Blocked due to access forbidden (403)”.
• Data terstruktur untuk langganan dan konten berbayar —isAccessibleForFree dan alternatif yang disetujui untuk 401 menyeluruh.
• Memverifikasi Googlebot dan crawler Google lainnya —verifikasi melalui IP/reverse-DNS, bukan user-agent, sebelum allowlist.

Standar / referensi

• RFC 9110 §15.5.2—Semantik HTTP: 401 Tidak Terotorisasi —spesifikasi 401 + WWW-Authenticate saat ini (menggantikan RFC 7235).
• MDN—401 Tidak Terotorisasi —definisi teknis untuk pengembang (referensi sekunder, bukan khusus SEO).

Kutipan dari sumber

Pernyataan yang tercatat. Setiap tautan adalah deep link yang melompat ke bagian yang dikutip pada halaman sumber.

Google—cara 4xx (termasuk 401) ditangani

• “Google doesn’t use the content from URLs that return 4xx status codes… Google doesn’t index URLs that return a 4xx status code, and URLs that are already indexed and return a 4xx status code are removed from the index.” (terjemahan) “Google tidak menggunakan konten dari URL yang mengembalikan kode status 4xx… Google tidak mengindeks URL yang mengembalikan kode status 4xx, dan URL yang sudah diindeks lalu mengembalikan kode status 4xx dihapus dari indeks.” — Dokumentasi Google Search Central. Lompat ke kutipan
• “All 4xx errors, except 429, are treated the same: Google crawlers inform the next processing system that the content doesn’t exist.” (terjemahan) “Semua kesalahan 4xx, kecuali 429, diperlakukan sama: crawler Google memberi tahu sistem pemrosesan berikutnya bahwa konten tidak ada.” Lompat ke kutipan
• “Don’t use 401 and 403 status codes for limiting the crawl rate. The 4xx status codes, except 429, have no effect on crawl rate.” (terjemahan) “Jangan gunakan kode status 401 dan 403 untuk membatasi laju crawl. Kode status 4xx, kecuali 429, tidak memengaruhi laju crawl.” Lompat ke kutipan

Google—bantuan Search Console, entri 401 dan 403

• “The page was blocked to Googlebot by a request for authorization (401 response)… You can verify this error by visiting the page in incognito mode.” (terjemahan) “Halaman diblokir untuk Googlebot oleh permintaan otorisasi (respons 401)… Anda dapat memverifikasi kesalahan ini dengan mengunjungi halaman dalam mode incognito.” — Bantuan Google Search Console, laporan Page Indexing. Lompat ke kutipan
• “HTTP 403 means that the user agent provided credentials, but was not granted access. However, Googlebot never provides credentials, so your server is returning this error incorrectly. The page will not be indexed.” (terjemahan) “HTTP 403 berarti agen pengguna memberikan kredensial tetapi tidak diberi akses. Namun, Googlebot tidak pernah memberikan kredensial, jadi server Anda mengembalikan kesalahan ini secara tidak benar. Halaman tidak akan diindeks.” Lompat ke kutipan

Google—konten berbayar

• “This structured data helps Google differentiate paywalled content from the practice of cloaking, which violates spam policies.” (terjemahan) “Data terstruktur ini membantu Google membedakan konten berbayar dari praktik cloaking, yang melanggar kebijakan spam.” — Dokumentasi Google Search Central. Lompat ke kutipan

MDN—definisi teknis

• “The HTTP 401 Unauthorized client error response status code indicates that a request was not successful because it lacks valid authentication credentials for the requested resource.” (terjemahan) “Kode status respons kesalahan klien HTTP 401 Tidak Terotorisasi menunjukkan bahwa permintaan tidak berhasil karena tidak memiliki kredensial autentikasi yang valid untuk sumber daya yang diminta.” — MDN Web Docs (referensi teknis sekunder, bukan khusus SEO). Lompat ke kutipan
• “A 401 Unauthorized is similar to the 403 Forbidden response, except that a 403 is returned when a request contains valid credentials, but the client does not have permissions to perform a certain action.” (terjemahan) “401 Tidak Terotorisasi mirip dengan respons 403 Forbidden, kecuali 403 dikembalikan ketika permintaan berisi kredensial valid tetapi klien tidak memiliki izin melakukan tindakan tertentu.” Lompat ke kutipan

John Mueller, Google (dikutip Search Engine Journal)

• Tentang menyembunyikan konten nonpublik: autentikasi sisi server yang mencegah pengguna biasa melihat konten—“that would include GoogleBot” (terjemahan) “itu termasuk GoogleBot”—adalah pendekatan ideal. Dikutip oleh Search Engine Journal dari hangout Google tahun 2019; perlakukan sebagai pernyataan yang diparafrasakan secara akurat, bukan kutipan yang diverifikasi per fragmen.

401 vs 403—yang mana yang saya lihat, dan apakah perlu diperbaiki?

Dua pertanyaan yang benar-benar dimiliki pembaca: apakah ini 401 atau 403? dan apakah ini masalah? Ikuti alurnya.

Prompt: diagnosis 401 yang tidak disengaja

Tempelkan header respons anonim dari satu URL yang terdampak beserta konfigurasi autentikasi, CDN, atau middleware yang relevan. Hapus token, cookie, dan rahasia terlebih dahulu.

Diagnose why this public URL returns HTTP 401 to an unauthenticated client. Check for
a valid WWW-Authenticate challenge, separate origin authentication from CDN/WAF and
application middleware, and distinguish an intentional private gate from a public-page
regression. Return: evidence, likely issuing layer, minimum safe fix, and exact
anonymous validation requests. Do not recommend user-agent-only bot allowlisting.

[PASTE SANITIZED HEADERS, LOG EVENT, AND CONFIG]

Prompt: tinjau pengecualian autentikasi

Review this proposed crawler-access rule for a gated site. Identify whether it relies
only on a spoofable user-agent, whether crawler identity is verified by published IP
ranges or reverse-and-forward DNS, and whether serving different content would create
a cloaking risk. Give a least-privilege alternative and a rollback test.

[PASTE SANITIZED RULE]

Shell: periksa tantangan anonim

Jalankan ini di terminal tanpa cookie atau kredensial browser.

URL='https://example.com/private'
curl -sS -D - -o /dev/null "$URL"

Untuk 401 yang nyata, periksa WWW-Authenticate. URL publik yang mengembalikan 401 secara anonim tetapi 200 di browser Anda yang sudah login adalah jebakan keadaan autentikasi yang dijelaskan di atas.

PowerShell: periksa respons anonim yang sama

$response = Invoke-WebRequest -Uri 'https://example.com/private' -SkipHttpErrorCheck
$response.StatusCode
$response.Headers['WWW-Authenticate']

Shell: bandingkan user-agent umum dan user-agent bot yang diklaim

URL='https://example.com/page'
curl -sS -o /dev/null -w 'generic %{http_code}\n' "$URL"
curl -sS -o /dev/null -w 'claimed-bot %{http_code}\n' -A 'Googlebot' "$URL"

Perbandingan ini dapat menyingkap aturan berbasis user-agent, tetapi tidak memverifikasi Googlebot; klien mana pun dapat mengirim string itu. Konfirmasikan lalu lintas crawler nyata secara terpisah melalui IP atau reverse-and-forward DNS sebelum mengubah aturan akses.

Alat untuk menemukan lapisan yang mengembalikan 401

• Bulk HTTP Status Code Checker: pastikan URL publik mana yang mengembalikan 401 tanpa sesi browser Anda dan ekspor kumpulannya.
• HTTP Header Checker: periksa WWW-Authenticate, header cache/CDN, dan lompatan redirect untuk petunjuk tentang lapisan penerbit.
• Googlebot Verifier: validasi bukti IP crawler sebelum membuat pengecualian akses; string user-agent saja tidak membuktikan apa pun.
• Inspeksi URL Search Console, Live Test: pastikan apa yang dapat diakses pengambilan langsung Google setelah perbaikan.
• Peristiwa keamanan CDN/WAF dan log origin: cocokkan ID permintaan dan waktu untuk menentukan apakah edge, aplikasi, atau origin yang menghasilkan 401.

Uji diri: 401 Tidak Terotorisasi

Lima pertanyaan singkat tentang arti 401 dan cara mesin pencari menanganinya. Pilih jawaban untuk setiap pertanyaan, lalu periksa hasilnya.

Log perubahan