Hal yang Selama Ini Saya Salah Pahami tentang robots.txt

• Setelah mencoba memblokir seluruh crawler situs web melalui pengaturan robots.txt, muncul efek samping tak terduga
• Pratinjau posting LinkedIn hilang, dan jangkauan posting juga menurun
• Penyebabnya adalah robots.txt memblokir akses LinkedInBot ke halaman, sehingga pengambilan meta tag terhambat
• Saya jadi menyadari kembali bahwa Open Graph Protocol berperan krusial dalam pembuatan pratinjau di media sosial
• Masalah terselesaikan setelah robots.txt diubah menjadi skema izin sebagian, dan saya pun menyadari perlunya pengujian yang memadai saat mengubah fitur

---

Pendahuluan: Pengaturan robots.txt dan pengalaman dengan masalah yang tidak disengaja

• Belakangan ini saya mempelajari pengaturan robots.txt di blog, sambil memikirkan isu hak data atas konten saya
• Saya mengubah robots.txt untuk memblokir semua crawler di situs web
• Tanpa diduga, perubahan itu menimbulkan hasil yang tidak diinginkan di situs web saya

Masalah pratinjau posting LinkedIn

• Setelah mengubah robots.txt, saat saya membagikan tautan blog saya di LinkedIn, pratinjau (thumbnail, ringkasan) tidak lagi muncul
• Sebelumnya pratinjau tampil normal, tetapi setelah perubahan, visibilitas dan respons menurun drastis
• Awalnya saya mengira ini hanya masalah sementara, tetapi gejala ini bertahan lebih dari 2 minggu
• Saat dianalisis dengan LinkedIn Post Inspector, diketahui bahwa robots.txt membatasi akses LinkedInBot sehingga metadata tidak dapat diambil
• Di platform media sosial, untuk membuat pratinjau tautan, permintaan ke halaman dan pengambilan meta tag adalah hal yang wajib

Pengenalan Open Graph Protocol

• Open Graph Protocol(OGP) adalah protokol standar yang dibuat oleh Facebook untuk menjadikan halaman web sebagai objek social graph
• OGP mendefinisikan meta tag wajib minimum
  • og:title: judul posting
  • og:type: tipe objek, misalnya "video.movie"
  • og:image: URL gambar thumbnail
  • og:url: URL representatif untuk objek tersebut
• Berkat protokol ini, konten dapat diringkas secara efektif dan ditampilkan dengan menarik di berbagai platform sosial

Selesai dengan izin sebagian pada robots.txt

• Untuk mengatasi masalah ini, saya mengubah robots.txt agar hanya mengizinkan LinkedInBot
• Jika Anda juga membutuhkan pratinjau di platform sosial lain, setiap bot harus diizinkan secara terpisah
• Contoh pengaturan yang saat ini digunakan:

  User-agent: LinkedInBot
  Allow: /
  
  User-agent: *
  Disallow: /
  

Refleksi dan pelajaran yang didapat

• Jika semua crawler diblokir tanpa pandang bulu, masalah pada visibilitas dan presentasi konten bisa terjadi
• Saya menyadari bahwa mengambil tindakan ini tanpa pengujian yang memadai terhadap dampaknya adalah sebuah kesalahan
• Dari pengalaman ini, saya jadi lebih memahami Open Graph Protocol, LinkedIn Post Inspector, dan berbagai alat serta standar web yang berguna
• Saat menambah atau mengubah fitur, perlu ada pemahaman dan verifikasi yang cukup terhadap seluruh area yang terdampak
• Awalnya saya tidak menghubungkan OGP dengan pemblokiran robots.txt, tetapi lewat pengalaman ini saya menyadari pentingnya hal tersebut

[GN⁺]

Opini Hacker News

• Dulu, tujuan utama robots.txt adalah mencegah penalti konten duplikat dari mesin pencari. Saat mengelola situs dinamis yang sulit diatur, halaman yang sama bisa terekspos lewat banyak URL karena parameter kueri dan semacamnya, lalu kena penalti dari mesin pencari. robots.txt berfungsi untuk memberi tahu, "ini URL resminya, jadi abaikan yang lain." Selain itu, ini juga membantu crawler yang ‘baik’ agar tidak tersesat dalam perayapan tautan tanpa akhir. Tentu saja crawler yang ‘jahat’ tidak peduli, dan bot semacam itu diblokir dengan hal-hal seperti pemblokiran IP. Memblokir berdasarkan User-Agent tidak ada artinya. Percaya bahwa bot jahat akan patuh pada aturan dengan tertib itu naif. Header DNT (Do Not Track) juga sama saja, seperti meminta perusahaan yang memang bisnisnya melacak agar "tolong jangan lacak saya." Atau mirip dengan ide Evil Bit dalam RFC yang berharap paket berbahaya dengan jujur menandai header-nya dengan "saya berbahaya"

  • Perlu diingat bahwa usulan Evil Bit adalah RFC April Mop lihat RFC 3514

  • Jadi sempat terpikir apakah robots.txt perannya mirip sitemap, tapi sebenarnya justru kebalikannya. robots.txt memberi tahu tempat yang tidak boleh diakses crawler, sedangkan sitemap memberi tahu tempat yang ingin kita indekskan. Saya tidak tahu soal tujuan awalnya untuk mengelola penalti konten duplikat, jadi ini terasa menambah konteks baru terhadap sudut pandang soal kontrol SEO

  • Intinya, jika suatu tindakan dinyatakan sebagai ‘larangan’, itu hanya efektif untuk sebagian pihak yang jujur atau yang secara tidak sengaja tidak menyamarkan nama user agent dengan benar. Di luar itu biasanya tidak terlalu mempan, jadi pada akhirnya agak simbolis

  • Seperti header DNT, upaya yang tampak tidak mungkin diterapkan di dunia nyata sering dikritik, tetapi sebenarnya ide DNT adalah upaya yang dimaksudkan untuk diterapkan bersama perangkat hukum. Meski pemblokiran teknis yang benar-benar sempurna sulit dilakukan, perlu diingat bahwa bila pelanggaran hukum dilakukan dalam skala besar, pada akhirnya bisa terungkap lewat whistleblower internal

  • Ada orang yang percaya bahwa kalau aturan dibuat semua orang akan mematuhinya, dan saya kadang bertanya-tanya apakah keyakinan itu berasal dari perbedaan budaya

• Pada 2003 saya pernah membuat mesin pencari sendiri dan merayapi web. Saya memasukkan alamat email utama ke user agent, dan benar-benar menerima sangat banyak email protes. Meski saya membuat crawler sebaik dan sesopan mungkin, rasanya orang-orang tidak menginginkan apa pun selain Google. Sikap seperti inilah yang mencegah munculnya pesaing untuk melawan Google. Ini bukan cuma soal masalah pratinjau LinkedIn; kita juga harus memikirkan bahwa web seharusnya terbuka untuk berbagai bot dan pengguna. Tentu crawler jahat harus diblokir, tetapi sikap yang menganggap semua bot pada dasarnya jahat juga tidak ideal

  • Dari sudut pandang saya yang berusaha menjalankan bot dengan baik, pengalaman paling menyebalkan adalah ketika seseorang membuat bot jahat yang menyerang dengan memakai user agent bot saya, lalu komplainnya datang ke saya

  • Siapa pun tentu ingin melindungi bot mereka sendiri, tetapi pada kenyataannya ini bukan cuma soal bot milik sendiri; masalahnya adalah ada sekitar 9000 bot serupa berkeliaran dan membebani resource server secara berlebihan. Bot-bot seperti ini memang tidak membawa traffic referral

  • Di awal saya juga mengambil pendekatan memblokir segalanya, tetapi kemudian saya menyadari keterhubungan dan kompleksitas web. Menurut saya, punya kendali atas resource sendiri itu penting. Namun saat memutuskan apakah traffic tertentu ingin diizinkan atau diblokir, kita perlu bertanya pada diri sendiri ‘kenapa’, dan perlu tahu apa yang dilakukan masing-masing bot. Proses ini butuh waktu dan usaha. Saya mulai tertarik pada robots.txt karena kebiasaan perusahaan AI yang merayapi secara serampangan untuk pelatihan data. Saya ingin memilih sendiri apakah akan mengizinkan atau memblokir. Memang tidak semua bot mematuhi robots.txt, tetapi cukup banyak yang menaatinya. Salah satu cara untuk menguji langsung adalah meminta model dengan kemampuan browsing untuk melakukan scraping pada tautan tertentu. Pada akhirnya, apakah sebuah bot itu berbahaya lebih ditentukan oleh bagaimana perusahaan tersebut memakai data dan bagaimana perasaan saya tentang itu

  • Menanggapi argumen “tidak semua bot berbahaya, jadi jangan blokir semuanya”, saya rasa pada dasarnya mendekat tanpa dasar kepercayaan adalah strategi yang berisiko

  • Wajar jika orang curiga terhadap crawler yang tidak dikenal. Mayoritas crawler itu berbahaya, dan tidak ada cara mengetahui baik atau buruknya lebih dulu, jadi masuk akal bila bot yang tidak dikenal diperlakukan sementara sebagai berbahaya secara default

• Saya berusaha menahan diri untuk tidak terlalu kritis, tetapi saya heran tulisan ini seolah-olah penulisnya baru menyadari konsekuensi tindakannya dengan sangat dramatis. Kisah pertumbuhan pribadi memang bisa bermakna, tetapi tulisan ini terasa lebih seperti pengakuan kebodohan daripada wawasan. Pada akhirnya saya merasa ini diposting demi mencari perhatian

  • Penulis tidak menyadari bahwa fetcher pratinjau halaman itu bukan crawler yang ia maksud, dan ia juga tidak terpikir untuk memblokirnya lewat robots.txt. Mungkin ini bukan hal yang mengejutkan, tetapi setidaknya dari sudut pandangnya sendiri ada sesuatu yang baru ia pelajari. Saya rasa tulisan blog yang benar-benar ditulis manusia bisa meningkatkan kualitas rata-rata web

  • Dia mempostingnya di sini (Hacker News) karena tidak muncul di Google

  • Buat saya juga ada bagian yang terasa benar-benar baru. Ini menjadi kesempatan untuk belajar lebih jauh tentang Open Graph Protocol dan Robots Exclusion Protocol. Saya cenderung mencatat dan membagikan hal-hal yang saya pelajari atau anggap menarik. Saya membagikannya karena merasa orang lain mungkin juga akan tertarik

  • Saya heran bagaimana tulisan ini bisa sampai ke halaman depan. Rasanya seperti penjelasan panjang untuk hal yang sangat jelas: “jika air dibendung, yang baik akan menghindar dan yang jahat akan mengabaikannya.” Pada akhirnya robots.txt hanyalah “tolong jangan” yang sopan, bukan firewall, dan itu sudah jelas

• Masalah robots.txt adalah pada akhirnya ia memfilter berdasarkan ‘identitas’ crawler, bukan tujuannya. Penulis juga memblokir semua bot untuk mencegah pengumpulan AI, tetapi kemudian mengizinkan lagi crawler untuk pratinjau OpenGraph (LinkedIn, dll.). Lalu bagaimana jika tautannya dibagikan di Twitter atau Mastodon? Kita harus mengizinkan UA semua media sosial satu per satu, dan pada akhirnya ini menguntungkan hanya segelintir platform besar. Pada dasarnya dibutuhkan cara untuk “memblokir pelatihan AI, tetapi mengizinkan indeks pencarian, pratinjau, arsip, dll.” Untuk menegakkannya secara nyata mungkin perlu kerangka hukum, tetapi itu pun tidak mudah

  • Diskusi tentang kegunaan mendasar robots.txt memang selalu ada. Menurut saya, pada awalnya (dan sampai sekarang) ini terutama ditujukan untuk kebanyakan crawler yang bekerja dengan mengikuti tautan dan menemukan hal baru. Mesin pencari adalah contoh utamanya. Namun jika pengguna secara langsung meminta URL tertentu (misalnya browser, langganan iCal, dll.), maka tidak perlu mengikuti robots.txt. Dalam praktiknya pernah ada layanan seperti Google Calendar yang gagal berlangganan karena diblokir robots.txt, dan menurut saya itu perilaku yang salah. Dalam kasus pratinjau URL, jika pengguna hanya meminta satu tautan, itu lebih dekat ke permintaan spesifik daripada crawling. Tetapi jika ada banyak tautan dalam pesan panjang, itu juga menjadi semacam crawling. Kesimpulannya, menurut saya masih belum jelas apakah fungsi pratinjau URL di media sosial seharusnya mengikuti robots.txt

  • Data seperti Common Crawl bisa dipakai ulang baik untuk mesin pencari maupun pelatihan AI dan lain-lain. Sulit membedakan berdasarkan penggunaan

  • Ini bisa diselesaikan dengan memisahkan cara berbagi informasi bukan secara in-band melainkan out-of-band. Jika metadata Open Graph disediakan lewat jalur/header terpisah, maka jalur itu (data yang tidak terlalu berguna) bisa diizinkan, sementara konten utama bisa ditolak dengan tegas. Kerangka hukum tidak selalu wajib

  • Saya suka ide membuat standar yang memungkinkan izin/blokir berdasarkan fungsi atau tujuan. Namun verifikasi fungsi dan pencegahan spoofing adalah kuncinya, dan pada akhirnya isu hukumnya juga terkait. Dalam praktiknya tampaknya kita harus mengizinkan lagi berbagai platform seperti pratinjau media sosial, dan saya banyak belajar dalam proses memilih dengan hati-hati apa yang akan diizinkan atau diblokir. Mendengar berbagai pendapat seperti ini sangat membantu

• Untuk OP, 1) Anda mungkin hanya memikirkan LinkedIn, tetapi pada kenyataannya tautan Anda bisa dibagikan juga di media sosial lain seperti Facebook, Bluesky, dan sebagainya. Saya juga mengalami bahwa di ai.robots.txt milik Facebook, crawler untuk pratinjau FB bisa ikut terblokir (contoh ai.robots.txt).

2. Soal peringkat Google dan pemblokiran robots.txt, meski ada faktor lain seperti tautan tidak langsung, pada dasarnya mengizinkan crawling langsung jauh lebih menguntungkan untuk SEO Naver/Google. Jika diblokir, thumbnail/deskripsi tidak tampil di hasil pencarian sehingga kualitasnya turun. Jika traffic dari mesin pencari penting, pemblokiran total lewat robots.txt perlu dipikirkan matang-matang

• Terima kasih atas masukannya! 1) Saya juga hanya memikirkan LinkedIn dan HN. Saya tidak sempat memikirkan bahwa orang lain bisa membagikan tautan blog saya di berbagai platform. Mungkin saya perlu mempertimbangkan ulang untuk mengizinkan akses dari banyak platform. 2) Melihat tren mesin pencari yang mengarah ke ringkasan AI, saya pikir ke depan traffic organik yang masuk ke situs itu sendiri akan berkurang. Jadi saya tidak terlalu menyesalkan berkurangnya traffic pencarian Google. Bisa saja saya berubah pikiran nanti, tetapi untuk saat ini saya merasa efek word-of-mouth lewat HN dan berbagi di media sosial akan menghasilkan traffic yang lebih berarti untuk blog saya. Saya ingin meneliti lebih jauh apakah keputusan yang saya ambil justru akan merugikan diri saya sendiri. Berbagai pendapat sangat membantu dalam pengambilan keputusan

• Ada efek samping lain yang muncul karena orang mencampuradukkan ‘crawling’ dan ‘indexing’ dalam robots.txt.
  Untuk memblokir halaman baru agar tidak masuk ke indeks Google sejak awal, pemblokiran robots.txt memang efektif.
  Tetapi jika ingin menghapus halaman yang sudah terindeks lalu hanya menambahkannya ke robots.txt, itu kesalahan. Karena Google tidak bisa merayapi halaman tersebut, hasil pencarian bisa tetap menampilkannya tanpa metadata, dan noindex meta tag pun tidak bisa diperiksa, sehingga halaman itu bisa bertahan lama di hasil pencarian. Google memang akhirnya akan menghapus halaman itu sepenuhnya nanti, tetapi prosesnya bisa sangat membuat frustrasi

  • Google bisa mengetahui URL yang diblokir oleh robots.txt lewat tautan eksternal dan sebagainya, dan dalam kasus seperti itu, meski tidak bisa merayapi, catatan yang sudah terindeks bisa tetap muncul di hasil pencarian (lihat peringatan: dokumentasi resmi Google). Untuk benar-benar menghapusnya dari hasil pencarian, noindex tag di dalam kode wajib ditambahkan, dan jika robots.txt memblokirnya maka tag ini juga tidak bisa dibaca, jadi perlu hati-hati

  • Dalam kasus saya, saya tidak terlalu ingin Google menghapusnya dari indeks. Saya tidak terlalu peduli pada pengindeksan, saya hanya peduli pada crawling dan scraping. Saya akui pernah memakai istilahnya secara campur aduk

• Tulisan ini terasa terlalu bertele-tele untuk hal yang sebenarnya cukup disampaikan dalam satu-dua kalimat. Rasanya seperti gaya menambah panjang tulisan saat masa sekolah

  • Masalahnya sebenarnya bisa dijelaskan dalam satu paragraf. Tujuan tulisan saya adalah mendokumentasikan perjalanan dari pengalaman dan masalah saya, riset yang saya lakukan, sampai solusi yang saya ambil. Saya menulis sedetail mungkin agar orang nonteknis pun bisa mengikuti

• Keterbatasan mendasar robots.txt adalah bahwa masalahnya justru bot yang tidak mematuhinya, bukan bot yang mematuhinya. robots.txt tidak bisa mengendalikan sebagian besar bot yang menjadi sumber masalah traffic saat ini. Semakin jahat bot yang benar-benar merusak server, semakin tidak peduli mereka pada robots.txt

  • Untuk menangkap bot seperti itu, ‘honeypot’ bisa berguna. Nyatakan secara eksplisit di robots.txt bahwa jalur /honeypot dilarang, lalu tambahkan tautan <a href="/honeypot">ban me</a> yang diberi display:none di index.html. IP yang mengakses jalur ini bisa langsung diblokir

  • Saya tidak tahu kenapa ini dapat downvote. Tidak ada dasar untuk percaya bahwa perusahaan besar seperti OpenAI, Anthropic, dan lain-lain mematuhi robots.txt dengan baik. Perusahaan-perusahaan ini mempersulit deteksi dengan merutekan traffic lewat IP ISP rumahan, dan membagi tanggung jawab dengan menghindari pelacakan langsung melalui ‘iklan pihak ketiga’

• Hal yang paling mengejutkan bagi saya adalah hampir tidak ada library parser yang tertata rapi untuk menafsirkan robots.txt dan meta robots tag sekaligus, termasuk menentukan prioritas izin/blokir saat terjadi konflik. Parser referensi resmi Google adalah kasus langka karena berbasis C++11, dan untuk library Python atau JS yang benar-benar populer, situasinya sering membuat developer harus mengimplementasikannya sendiri. Bahkan untuk meta robots, informasinya tidak berada di file robots.txt, tetapi tersembunyi di dalam index.html. Masalahnya, bahkan penulis bot yang secara moral ingin berbuat benar pun kesulitan karena tingkat implementasinya tinggi

  • Di pustaka standar Python ada urllib.robotparser (dokumentasi resmi). Sementara itu rel=nofollow punya tujuan yang sepenuhnya berbeda dari robots.txt. Atribut ini berarti mesin pencari tidak perlu ‘mempercayai’ tautan tersebut (memberi nilai link), bukan berarti “jangan ikuti tautan ini” (penjelasan detail). Tujuan awalnya adalah mencegah orang di komunitas spam meninggalkan tautan ke situs mereka sendiri secara sembarangan

  • Developer bot ‘baik’ yang tidak punya resource besar pada dasarnya tidak akan membombardir server secara serampangan, jadi dalam praktiknya kekurangan library jarang benar-benar menjadi masalah besar

  • Jika ingin membuat bot yang benar dengan niat baik, saya rasa sangat mungkin juga untuk mengalihbahasakan parser library itu ke bahasa lain sebagai open source dan merilisnya. Tidak ada yang terlalu sulit

• Menariknya, Apple mendekati masalah ini dengan cara berbeda. Saat membagikan tautan di iMessage, klien dari pihak ‘pengirim’ langsung mengambil data untuk membuat pratinjau. Layanan seperti LinkedIn tentu punya alasan mengapa server mereka sendiri yang mengambil data tautan secara langsung (spam, pencegahan phishing, dll.), tetapi tetap saja ini pendekatan yang berbeda

  • Saya juga merasa masuk akal jika klien yang menerima pesan lalu langsung membuat pratinjau dari tautan di dalamnya. Dan saya juga berharap sudah ada orang yang menunjukkan hal ini. Namun saya paham ada berbagai alasan mengapa server melakukan scraping sendiri. 1) Bersiap untuk masa depan ketika semua halaman bisa diambil dan dimanfaatkan; 2) Bahkan jika halaman berubah, menjadi 404, atau database klien hilang, server tetap bisa memberikan informasi pratinjau yang sudah diambil sebelumnya; 3) Klien tidak perlu membuat pratinjau sendiri dan bisa melihat pratinjau dengan cepat bersama pesan. Pada akhirnya, jika seperti iMessage pihak ‘pengirim’ yang membuat pratinjau, maka hanya ‘poin 1’ dan ‘sebagian dari poin 2’ yang tersisa, dan dari sisi keandalan, membiarkan server terus mencoba ulang mungkin pilihan yang lebih baik