Cara Setting robots.txt WordPress yang Benar di 2026 (Isinya Apa Saja)

robots.txt WordPress yang baik panjangnya sekitar lima baris. Blokir /wp-admin/, izinkan admin-ajax.php, arahkan crawler ke sitemap Anda, lalu berhenti di situ — daftar blokir 40 baris yang bertebaran di forum kebanyakan merusak rendering atau tidak berguna sama sekali. Ini seluruh isinya:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://example.com/wp-sitemap.xml

Ganti domainnya, dan kalau Anda memakai plugin SEO yang mengambil alih sitemap, arahkan baris Sitemap ke indeks milik plugin tersebut. Sudah, itu saja. Kalau file Anda lebih panjang dari ini, baris-baris tambahannya kemungkinan besar sedang merugikan Anda.

WordPress sudah membuatkannya — sampai Anda membuat file asli

WordPress menyediakan robots.txt virtual. Ketika ada permintaan masuk ke /robots.txt dan tidak ada file asli di root web Anda, WordPress mencegat permintaan itu dan mencetak responsnya di memori. Tidak ada yang ditulis ke disk. Keluaran bawaannya adalah blok wp-admin di atas, ditambah satu baris Sitemap: untuk wp-sitemap.xml yang sudah dikeluarkan core sejak WordPress 5.5.

Ada dua hal yang mengubah keluaran itu. Kalau Pengaturan → Membaca → Cegah mesin pencari mengindeks situs ini dicentang, WordPress mengganti seluruh isinya dengan Disallow: /, yang memblokir semuanya. Kotak centang itu adalah penyebab paling umum sebuah situs lenyap dari pencarian setelah diluncurkan. Kedua, plugin dan tema bisa mengubah keluaran virtual lewat filter robots_txt, dan lewat jalur itulah plugin SEO menyisipkan baris sitemap dan aturan mereka sendiri.

Sekarang bagian yang menghabiskan sore hari banyak orang. File robots.txt fisik di root web Anda diam-diam mengalahkan semuanya. Server web Anda menemukan file asli di disk, menyajikannya, dan WordPress tidak pernah dimuat. Generator virtualnya tidak berjalan. Filter robots_txt tidak terpicu. Editor robots.txt di plugin SEO Anda mungkin masih menampilkan antarmuka rapi berisi aturan yang benar, dan tak satu pun dari itu sampai ke crawler.

Tempat aturannya berada	Bisa diedit di admin WordPress	Yang menang pada permintaan nyata
Virtual (tidak ada file di disk)	Ya, lewat filter robots_txt atau plugin	Hanya kalau tidak ada file fisik
File fisik di root web	Hanya kalau pluginnya menulis ke disk	Selalu

Jadi sebelum menelusuri apa pun: buka https://namasitus.com/robots.txt di peramban, lalu sambungkan lewat SFTP atau file manager hosting Anda dan periksa apakah ada file robots.txt asli di samping wp-config.php dan .htaccess. Kalau ada, file itulah robots.txt Anda. Edit di sana, atau hapus dan biarkan WordPress yang mengurus — tapi pilih salah satu. Menjalankan keduanya adalah cara situs berakhir dengan URL sitemap basi yang tak seorang pun bisa temukan.

Kenapa /wp-admin/ diblokir tapi admin-ajax.php diizinkan

/wp-admin/ berisi dasbor. URL-URL itu tidak ada gunanya di hasil pencarian dan merayapinya hanya membakar jatah crawl untuk halaman yang berujung ke layar login. Memblokir direktorinya bukan hal yang diperdebatkan.

admin-ajax.php memang berada di dalam direktori itu, tapi bukan halaman admin. Ini endpoint yang dipakai plugin dan tema untuk menangani permintaan AJAX di sisi depan — tombol muat lagi, grid produk yang difilter, kalkulator, formulir. Kalau crawler tidak bisa mengambilnya, ia tidak bisa melihat konten yang dimuat fitur-fitur tersebut, dan Google merender halaman Anda seperti yang dilihat pengunjung dengan fiturnya rusak.

Apakah Google benar-benar perlu mengambil admin-ajax.php di situs Anda tergantung apakah sisi depan situs memakainya. Jawaban jujurnya: di banyak situs modern hal ini sama sekali tidak berpengaruh, karena temanya memakai REST API di /wp-json/. Baris Allow itu asuransi murah terhadap kegagalan yang nyata, bukan faktor peringkat. Pertahankan karena tidak memakan biaya apa pun.

Jangan blokir /wp-content/ atau /wp-includes/

Ini saran robots.txt terburuk yang masih beredar, dan asalnya dari era ketika Google belum merender halaman.

/wp-content/ berisi tema, plugin, dan unggahan Anda — stylesheet, skrip, dan gambar yang membuat halaman Anda tampak seperti halaman. /wp-includes/ berisi JavaScript core yang diandalkan banyak plugin. Google merender halaman Anda dengan peramban headless sebelum menilainya. Blokir direktori tersebut dan perendernya menerima halaman tanpa CSS dan tanpa gambar. Yang dinilai Google adalah dinding teks polos dengan tata letak rusak, dan itu memengaruhi cara Google memahami konten Anda serta menilai kenyamanannya di perangkat mobile.

Kalau Anda mewarisi file yang berisi baris-baris ini, hapus:

Disallow: /wp-content/
Disallow: /wp-includes/
Disallow: /wp-content/plugins/
Disallow: /wp-content/themes/

Anda bisa memastikan kerusakannya sendiri lewat alat URL Inspection di Google Search Console. Jalankan tes langsung pada halaman mana pun, lihat tangkapan layar hasil render, lalu periksa daftar resource halaman untuk item yang terblokir. Kalau CSS Anda tertera terblokir, itulah penyebabnya.

Direktif Sitemap

Satu baris, URL absolut, dan boleh ditaruh di mana saja dalam file — baris ini tidak terikat pada grup User-agent mana pun.

Sitemap: https://example.com/wp-sitemap.xml

Gunakan URL yang benar-benar bisa dibuka. WordPress core menyajikan wp-sitemap.xml. Sebagian besar plugin SEO menonaktifkan sitemap core dan menyajikan indeks mereka sendiri di jalur berbeda, biasanya sitemap_index.xml. Buka URL Anda di peramban sebelum memasangnya — baris Sitemap yang mengarah ke 404 lebih buruk daripada tidak ada baris sama sekali, karena tampak benar saat diaudit.

Mencantumkan beberapa sitemap tidak masalah, satu per baris. Mengirimkan sitemap lewat Search Console tetap layak dilakukan secara terpisah; direktif di robots.txt adalah cara crawler yang tidak pernah melihat akun Search Console Anda menemukannya.

robots.txt bukan noindex, dan bukan pula keamanan

Dua salah paham inilah penyebab sebagian besar kerusakan akibat robots.txt.

Memblokir sebuah URL tidak menghapusnya dari Google. Robots.txt mengatur perayapan. Kalau ada situs lain yang menautkan URL yang diblokir, Google tetap bisa mengindeks URL itu sendiri — Anda mendapat hasil pencarian berupa alamat polos dengan catatan bahwa tidak ada informasi tersedia. Dan ada jebakan yang lebih menyebalkan: kalau sebuah halaman sudah punya tag meta noindex lalu Anda memblokirnya di robots.txt, Google tidak bisa merayapinya, tidak bisa melihat noindex itu, dan halamannya bisa tetap terindeks tanpa batas waktu. Untuk menghapus sebuah halaman, izinkan perayapan lalu sajikan tag meta robots noindex di bagian head halaman atau header HTTP X-Robots-Tag. Google berhenti mendukung direktif noindex di dalam robots.txt sejak 2019.

Memblokir sebuah jalur tidak melindunginya. robots.txt Anda bersifat publik menurut definisinya. Mencantumkan /private-client-files/ memberi tahu setiap pengunjung dan setiap pemindai persis ke mana harus melihat, dan kepatuhannya sukarela — Google menghormatinya, bot bermusuhan tidak. Apa pun yang perlu dilindungi butuh autentikasi, pembatasan IP, atau aturan di level server dalam .htaccess, bukan satu baris di file teks yang justru mengiklankan sasarannya.

Aturan yang layak ditambahkan, dan yang layak dilewati

Ada dua tambahan yang benar-benar berguna di banyak situs. Memblokir jalur hasil pencarian internal mencegah crawler menghasilkan URL bernilai rendah tanpa henti. Memblokir jalur keranjang atau checkout di WooCommerce menjauhkan URL berparameter sesi dari perayapan.

Disallow: /?s=
Disallow: /search/

Lewati yang berikut:

• Crawl-delay — Google mengabaikannya sepenuhnya. Gunakan kontrol laju perayapan di Search Console kalau Anda benar-benar punya masalah beban server.
• Memblokir /feed/ atau /trackback/ — URL yang tidak berbahaya, dan feed itu berguna.
• Daftar panjang berisi nama bot satu per satu — sebagian besar bot yang ingin diblokir orang memang tidak jujur menyebutkan identitasnya.
• Memblokir /wp-json/ — bisa jadi itulah yang dipakai tema Anda untuk menampilkan konten.

Susun filenya dengan generator robots.txt WordPress, yang menghasilkan versi minimal yang benar dan memungkinkan Anda menambahkan aturan pencarian serta toko tanpa mengetik sintaksnya sendiri.

Setelah Anda mengubahnya

Buka https://namasitus.com/robots.txt secara langsung dan pastikan byte yang tersaji sesuai harapan Anda — bukan sekadar apa yang ditampilkan editor plugin Anda. Lalu jalankan URL inspection langsung di Search Console pada halaman biasa dan periksa bahwa tidak ada resource CSS atau JavaScript yang terlaporkan terblokir. Google menyimpan cache robots.txt kira-kira sehari, jadi perbaikan tidak langsung berlaku, dan kesalahan pun tidak. Jeda itulah alasan Anda sebaiknya memverifikasi dengan cermat alih-alih menguji langsung di situs produksi lalu menunggu.