Praktik Terbaik Sitemap XML: Isi dan Perawatannya

Sitemap XML yang baik hanya memuat URL kanonis yang bisa diindeks dan menjawab HTTP 200, dengan lastmod yang jujur, di bawah batas 50.000 URL dan 50 MB per file, dideklarasikan di robots.txt, serta diperbarui otomatis setiap kali konten berubah. Sisanya — changefreq, priority, URL pengalih — hanyalah beban.

Prinsip dasar: sitemap adalah daftar undangan, bukan sensus

Anggap sitemap sebagai daftar halaman yang Anda banggakan dan ingin diindeks. Setiap URL yang tidak memenuhi tiga syarat berikut sebaiknya dikeluarkan:

• Kanonis. Hanya versi kanonis dari sebuah halaman. Jangan cantumkan varian dengan parameter pelacakan, versi http, atau duplikat yang canonical tag-nya menunjuk ke halaman lain.
• Dapat diindeks. Tidak ber-tag noindex dan tidak diblokir robots.txt. Sitemap yang memuat halaman terlarang mengirim sinyal bertentangan ke crawler.
• Berstatus 200. Bukan redirect, bukan 404, bukan halaman error. Crawler yang berulang kali menemukan URL mati di sitemap Anda belajar untuk kurang memercayainya.

Halaman login, keranjang belanja, hasil pencarian internal, halaman terima kasih, dan arsip tag tipis umumnya tidak pantas masuk. Aturan praktisnya: kalau Anda tidak ingin halaman itu muncul di hasil pencarian, jangan cantumkan di sitemap.

Bagaimana dengan halaman yang dihapus atau dipindah?

Begitu sebuah halaman dihapus atau dialihkan permanen, keluarkan URL lamanya dari sitemap pada regenerasi berikutnya. Membiarkan URL 404 atau 301 menumpuk membuat crawler membuang waktu dan pelan-pelan menurunkan kepercayaan terhadap file Anda. Untuk pengalihan, cantumkan URL tujuannya — bukan URL asalnya. Ini alasan lain mengapa sitemap sebaiknya dihasilkan dari sumber data yang sama dengan situs itu sendiri, bukan dirawat terpisah.

lastmod: hanya berguna jika jujur

Google menyatakan di dokumentasinya bahwa lastmod dipakai hanya jika nilainya konsisten dan dapat diverifikasi. Artinya: isi dengan tanggal perubahan konten yang berarti — bukan tanggal build, bukan waktu sekarang di setiap regenerasi. Menyetel semua lastmod ke hari ini setiap kali situs di-build adalah cara tercepat membuat Google mengabaikan field itu di seluruh situs Anda. Jika Anda tidak bisa mengisinya dengan jujur, lebih baik hilangkan sama sekali.

changefreq dan priority: boleh ada, tapi tak dibaca

Katakan dengan gamblang: Google mengabaikan changefreq dan priority, dan sudah mengonfirmasinya bertahun-tahun. Bing pun sebagian besar sama. Keduanya tetap valid secara XML, jadi tidak perlu buru-buru menghapusnya dari sitemap lama, tetapi jangan habiskan satu menit pun menyetel priority 0.8 versus 0.6 — perayapan Anda dikendalikan oleh tautan internal dan akurasi lastmod, bukan oleh angka-angka itu.

Batas ukuran dan kapan harus memecah

Satu file maksimal 50.000 URL dan 50 MB tanpa kompresi. Praktik yang sehat adalah memecah jauh sebelum batas itu — banyak tim memakai 10.000 hingga 40.000 URL per file — lalu merangkainya dengan sebuah sitemap index. Pecahan berdasarkan tipe konten (misalnya sitemap-produk.xml, sitemap-blog.xml) punya bonus diagnostik: statistik indeksasi per bagian situs terlihat terpisah di Search Console. Detailnya ada di panduan sitemap index kami.

Kompresi gzip

Sitemap boleh disajikan sebagai .xml.gz. Yang perlu diingat: batas 50 MB dihitung dari ukuran setelah didekompresi, jadi gzip menghemat bandwidth tetapi tidak menaikkan kapasitas. Untuk sitemap besar yang diregenerasi rutin, gzip tetap layak karena mempercepat pengambilan oleh crawler.

Autodiscovery lewat robots.txt

Selain disubmit manual, sitemap bisa ditemukan otomatis lewat satu baris di robots.txt:

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

Baris ini berlaku untuk semua mesin pencari, boleh muncul lebih dari sekali, dan wajib memakai URL absolut. Ini juga satu-satunya mekanisme resmi yang membuat sitemap boleh memuat URL dari host lain. Pasang baris ini sekali dan setiap crawler yang membaca robots.txt Anda akan menemukan sitemap-nya — termasuk mesin pencari yang tidak punya dasbor webmaster untuk submit manual.

Submit di Search Console dan Bing Webmaster Tools

Di Google Search Console, buka menu Sitemaps, masukkan URL-nya, dan pantau laporan status: jumlah URL yang ditemukan versus yang diindeks memberi gambaran kesehatan yang jujur. Di Bing Webmaster Tools prosesnya serupa. Submit cukup sekali per file — keduanya akan mengambil ulang secara berkala. Yang perlu Anda lakukan setelahnya adalah memantau, bukan submit ulang tiap minggu.

Seberapa sering regenerasi? Dinamis vs statis

Aturan praktisnya: sitemap harus berubah setiap kali daftar halaman atau kontennya berubah.

• Situs statis (dibangun dengan generator situs statis): buat sitemap sebagai bagian dari proses build. Setiap deploy otomatis menghasilkan sitemap segar — tidak ada yang perlu diingat.
• Situs dinamis (CMS, e-commerce): sajikan sitemap dari data langsung atau regenerasi lewat cron. Konten yang berubah tiap jam pantas mendapat regenerasi tiap jam; blog yang terbit mingguan cukup harian.

Sitemap dinamis yang dirakit saat diminta punya kelebihan selalu segar, tetapi pastikan responsnya cepat dan di-cache secukupnya — sitemap yang butuh sepuluh detik untuk dirakit di situs besar bisa membuat pengambilan crawler kehabisan waktu. Versi statis hasil build lebih murah disajikan dan lebih mudah di-debug: apa yang Anda lihat di file persis yang dilihat Googlebot.

Yang harus dihindari adalah sitemap yang dibuat manual sekali lalu dilupakan: dalam enam bulan ia penuh URL mati dan kehilangan halaman baru — lihat daftar akibatnya di panduan memperbaiki error sitemap.

Mitos vs kenyataan

Daftar periksa perawatan

1. Sitemap dibuat otomatis oleh build atau cron, bukan manual.
2. Hanya URL kanonis, 200, dan dapat diindeks yang tercantum.
3. lastmod diisi dari tanggal perubahan konten yang sebenarnya.
4. Baris Sitemap: ada di robots.txt.
5. Sudah disubmit di Google Search Console dan Bing Webmaster Tools.
6. Divalidasi ulang setelah setiap perubahan besar pada situs — validator kami menyelesaikannya dalam hitungan detik.