Checklist SEO Sebelum Website Diluncurkan: Pemeriksaan Go-Live

Checklist SEO sebelum website launch membantu tim menemukan masalah yang sebaiknya ditangani sebelum pengunjung dan mesin pencari diarahkan ke situs baru. Periksa URL final, akses crawling, title dan canonical, tautan, redirect, sitemap, tampilan ponsel, formulir, serta pengukuran. Catat pemilik tugas dan buktinya agar keputusan go-live dapat diperiksa. Checklist ini mengurangi risiko masalah yang terlewat; checklist tidak menjamin Google mengindeks atau memberi peringkat pada halaman.

Sebelum mulai, bedakan peluncuran situs baru dari migrasi. Website baru tanpa URL lama tidak membutuhkan peta redirect untuk semua halaman. Sebaliknya, jika Anda mengubah domain, protokol, struktur URL, atau menggabungkan konten lama, pemetaan tujuan dan pengujian redirect menjadi pekerjaan penting. Google juga menyarankan pengujian situs baru, pemetaan URL lama ke tujuan baru, redirect yang benar, dan pemantauan setelah perpindahan. Panduan Google tentang perpindahan situs terutama membahas perubahan URL, jadi sesuaikan bagian migrasi dengan skala perubahan yang benar-benar Anda lakukan.

1. Bekukan daftar URL dan tentukan halaman yang perlu ditemukan

Sebelum memeriksa metadata, buat daftar URL yang akan diluncurkan. Daftar ini menjadi acuan bersama bagi penulis, desainer, pengembang, dan orang yang mengelola Search Console. Simpan satu versi final; perubahan URL setelah pemeriksaan dapat membuat bukti sebelumnya tidak lagi sesuai.

Mulai dari halaman yang benar-benar ada, bukan hanya daftar menu. Jika situs sudah berjalan, inventaris lama dapat disusun dari sitemap, crawl situs, data analitik, dan laporan tautan di Search Console. Untuk situs baru, buat daftar dari struktur dan naskah yang telah disetujui. Tandai halaman yang harus menerima kunjungan organik, misalnya halaman layanan, kategori, artikel, atau lokasi.

Tetapkan keputusan untuk setiap URL lama: tetap menggunakan URL, dialihkan ke padanan yang sesuai, atau mengembalikan status tidak ditemukan jika konten memang dihapus tanpa pengganti yang relevan. Jangan mengarahkan semua URL lama ke homepage secara otomatis. Pengunjung yang mencari informasi tertentu seharusnya menerima halaman pengganti yang sepadan; pengalihan yang tidak relevan dapat membingungkan pengguna dan diperlakukan sebagai soft 404.

2. Pastikan aturan staging tidak terbawa ke situs live

Situs staging dipakai untuk meninjau halaman sebelum peluncuran. Jika isinya tidak untuk publik, batasi akses dengan autentikasi atau kontrol akses yang sesuai. Bila memakai aturan noindex selama pengembangan, simpan daftar halaman yang memakai aturan itu dan jadwalkan pemeriksaan untuk memastikan hanya aturan yang tepat yang dihapus saat go-live.

Periksa robots.txt dan aturan indeksasi secara terpisah. Google menjelaskan bahwa noindex hanya dapat dibaca crawler ketika URL dapat diakses dan tidak diblokir oleh robots.txt. Karena itu, memblokir crawling saja bukan pengganti noindex jika tujuan Anda memang agar crawler melihat aturan tersebut. Di sisi lain, ketika situs siap dipublikasikan, pastikan halaman yang ingin ditemukan dapat diakses crawler dan tidak masih membawa noindex dari staging. Dokumentasi Google tentang noindex.

Jangan menghapus semua aturan perlindungan tanpa memeriksa fungsinya. Beberapa halaman—seperti area akun atau halaman internal—memang tidak ditujukan untuk hasil pencarian. Buat daftar pengecualian, tentukan siapa yang menyetujuinya, lalu uji satu halaman contoh dari tiap kelompok. Untuk halaman yang penting bagi pencarian, gunakan pemeriksaan URL di Search Console setelah URL live tersedia.

3. Periksa elemen yang membantu orang dan crawler mengenali halaman

Untuk setiap URL yang memang layak ditemukan, pastikan konten utamanya tampil dan sesuai tujuan pencarian. Lalu periksa elemen berikut:

• Title: unik dan menjelaskan topik atau layanan pada halaman tersebut. Hindari satu title yang disalin ke semua URL.
• Deskripsi pencarian: merangkum isi halaman secara akurat. Google dapat memilih cuplikan lain dari konten, sehingga deskripsi bukan jaminan teks yang akan selalu ditampilkan.
• Heading utama: terlihat dan konsisten dengan topik halaman. Pastikan tidak ada judul kosong atau heading templat yang muncul sebagai isi.
• Canonical: mengarah ke versi URL yang memang Anda tetapkan sebagai pilihan utama. Periksa protokol, domain, slash, dan parameter dengan cermat.
• Bahasa: untuk halaman Indonesia dan Inggris, gunakan URL versi bahasa masing-masing, konten utama dalam satu bahasa, dan pasangan hreflang yang sesuai. Google merekomendasikan URL berbeda untuk tiap versi bahasa dan mendukung hreflang untuk membantu hasil mengarah ke versi yang tepat. Panduan Google untuk situs multibahasa.
• Structured data: bila digunakan, datanya harus sesuai isi yang dapat dilihat pengguna. Validasi format dan jenis markup; structured data bukan syarat agar situs dapat diluncurkan dan tidak menjamin hasil kaya.

Selain pemeriksaan otomatis, baca beberapa halaman seperti calon pelanggan. Apakah layanan, area yang dilayani, harga jika ditampilkan, batas penawaran, dan langkah berikutnya jelas? Title yang baik tidak dapat menggantikan informasi yang hilang dari halaman.

4. Uji tautan internal, sitemap, dan error halaman

Klik menu, breadcrumb, tautan dalam artikel, tombol utama, dan footer. Arahkan tautan internal langsung ke URL final, bukan lewat alamat lama yang kemudian dialihkan. Periksa pula tautan gambar, unduhan, dan formulir bila aset atau endpoint-nya berubah.

Sitemap XML sebaiknya mencantumkan URL final yang ingin ditawarkan kepada crawler. Jangan masukkan URL staging, halaman yang sengaja noindex, URL yang dialihkan, atau alamat dengan error. Sitemap membantu Google menemukan URL, tetapi bukan perintah agar seluruh halaman masuk indeks. Setelah rilis, kirim sitemap melalui Search Console dan gunakan laporan untuk melihat statusnya.

Untuk perubahan URL, buat peta redirect sebelum rilis. Redirect permanen seperti 301 atau 308 sesuai bila sebuah halaman benar-benar berpindah secara permanen. Uji URL lama sampai tujuan akhir: status respons, relevansi konten tujuan, dan jumlah lompatan. Google menganjurkan redirect permanen sisi server bila memungkinkan dan menyarankan agar rantai redirect tetap pendek. URL yang dihapus tanpa pengganti yang sesuai sebaiknya tidak dialihkan ke halaman yang tidak relevan. Panduan redirect dalam perpindahan situs.

Periksa halaman 404 dengan dua cara: tampilannya membantu orang kembali ke halaman relevan, dan server benar-benar mengembalikan status 404 ketika halaman tidak ada. Pesan “halaman tidak ditemukan” yang masih mengembalikan status sukses dapat menyulitkan diagnosis.

5. Coba pengalaman nyata di ponsel dan ukur alur penting

Pengunjung tidak datang hanya untuk membaca title. Coba alur yang menghasilkan prospek atau transaksi dari perangkat ponsel dan desktop:

1. Buka halaman dari tautan masuk, lalu ikuti navigasi menuju layanan atau produk.
2. Gunakan formulir seperti calon pelanggan: isi kolom, kirim, dan pastikan pesan berhasil atau kesalahan tampil jelas.
3. Periksa tombol telepon, WhatsApp, email, jadwal, pembayaran, atau unduhan bila halaman menggunakannya.
4. Pastikan banner cookie atau dialog lain tidak menutupi kontrol penting.
5. Tinjau halaman pada ukuran layar sempit dan lebar: teks, tabel, gambar, menu, dan tombol tidak terpotong.
6. Uji kecepatan pada halaman utama dan halaman dengan media berat; catat masalah yang menghambat alur, bukan sekadar mengejar satu skor.

Jika analitik dipakai, verifikasi bahwa tag yang seharusnya aktif berjalan pada URL live dan event penting tercatat sekali. Contohnya, pengiriman formulir dapat diuji dengan data uji yang memang disetujui dan tidak mengirim data pribadi ke laporan analitik. Pastikan pengaturan consent dan kebijakan privasi sesuai implementasi situs. Catat kondisi awal agar laporan setelah peluncuran dapat dibandingkan.

6. Gunakan papan go/no-go yang bisa diaudit

Checklist menjadi lebih berguna ketika setiap baris memiliki pemilik, status, dan bukti. Isi status dengan tiga pilihan sederhana: Siap, Menghambat rilis, atau Dikerjakan setelah rilis. Pekerjaan yang ditunda harus punya alasan, penanggung jawab, dan tanggal tinjau.

Masalah yang membuat halaman penting tidak dapat diakses, salah tujuan, atau gagal menerima inquiry biasanya perlu diperlakukan sebagai penghambat. Sedangkan pengembangan konten lanjutan dan eksperimen dapat masuk backlog setelah rilis, selama keputusan tersebut disengaja dan risiko dipahami. Jangan menganggap seluruh audit harus sempurna sebelum situs dapat dibuka; utamakan masalah yang menghalangi pengguna dan crawler memahami atau menggunakan halaman.

7. Rencana hari peluncuran dan minggu pertama

Sebelum rilis

• Bekukan daftar URL, title, canonical, serta keputusan redirect.
• Uji alur utama formulir dan navigasi pada staging.
• Siapkan sitemap final dan aturan robots yang sesuai.
• Simpan snapshot sitemap, crawl, error, dan laporan analitik jika situs lama sudah berjalan.
• Tentukan kontak teknis dan bisnis yang dapat menyetujui rollback atau perbaikan.

Saat rilis

• Aktifkan perubahan sesuai urutan yang disepakati.
• Uji URL prioritas dengan browser dan periksa redirect dari beberapa alamat lama.
• Pastikan halaman yang ditujukan untuk pencarian dapat diakses dan tidak tertahan aturan staging.
• Kirim sitemap terbaru di Search Console.
• Uji satu konversi dari awal sampai notifikasi diterima.

Hari ke-1 sampai ke-7

Periksa status URL prioritas melalui URL Inspection dan laporan Search Console; tinjau error server, 404 yang tidak direncanakan, redirect salah, formulir yang gagal, dan event analitik. Jika ada banyak URL, sitemap membantu Google menemukannya; untuk beberapa URL tertentu, URL Inspection dapat meminta crawling. Google menyatakan recrawl dapat memerlukan beberapa hari hingga beberapa minggu dan permintaan tidak menjamin URL akan langsung atau pasti tampil di hasil pencarian. Panduan meminta Google merayapi ulang URL.

Saat menilai perubahan, catat tanggal rilis, bagian yang berubah, dan sumber data. Jika beberapa komponen seperti domain, template, dan konten berubah sekaligus, akan lebih sulit mengetahui penyebab suatu gejala. Untuk migrasi, fluktuasi sementara dapat terjadi sementara Google merayapi dan memproses URL baru; lihat tren dan masalah teknis bersama-sama sebelum memutuskan perubahan lanjutan.

Kesalahan go-live yang perlu dihindari

• Mengandalkan satu skor Lighthouse sebagai bukti semua halaman sudah siap.
• Meninggalkan noindex staging pada halaman live yang seharusnya ditemukan.
• Memblokir crawling lalu berharap crawler membaca noindex yang tidak dapat diakses.
• Mengarahkan semua URL yang berubah ke homepage tanpa mengecek kesesuaian.
• Menganggap pengiriman sitemap atau permintaan recrawl berarti halaman pasti diindeks.
• Mengubah struktur URL setelah QA tanpa memperbarui sitemap, canonical, tautan, dan peta redirect.
• Menguji formulir tanpa memastikan notifikasi benar-benar diterima tim yang bertanggung jawab.

Jika arsitektur website masih perlu dirapikan sebelum launch, gunakan panduan arsitektur website. Untuk meninjau struktur halaman dan koneksi internal, baca juga struktur website bisnis dan panduan Core Web Vitals di Indonesia. Anda juga dapat memulai dari mini audit website Oura bila memerlukan daftar prioritas untuk situs Anda.

Rujukan resmi

• Panduan Google tentang perpindahan situs dan perubahan URL
• Panduan Google tentang aturan noindex
• Panduan Google untuk situs multibahasa
• Panduan Google untuk meminta crawling ulang

FAQ — Pertanyaan yang sering diajukan

Bacaan terkait

Lanjutkan ke panduan dan cerita yang membahas keputusan serupa.

Panduan

Fondasi SEO untuk pencarian AI

Rawat akses teknis dan informasi yang membantu pembaca.

Baca selengkapnya →Panduan

Pengukuran prospek dengan GA4

Hubungkan tindakan website dengan konteks sales.

Baca selengkapnya →Panduan

Brief proyek website yang jelas

Sepakati tujuan, cakupan, serta keputusan proyek.

Baca selengkapnya →Panduan

Copy layanan sebelum konsultasi

Perjelas manfaat, cakupan, bukti, dan langkah berikutnya.

Baca selengkapnya →