Audit Website Sebelum Redesign: Apa yang Diperiksa?

Melakukan audit website sebelum redesign membantu tim mengetahui apa yang perlu diubah dan apa yang masih berguna. Tanpa pemeriksaan, proyek mudah berangkat dari selera visual lalu mengulang masalah lama dalam tampilan yang baru. Audit memberi dasar untuk menilai kebutuhan konten, struktur, fungsi, dan pekerjaan teknis.

Dokumen hasilnya tidak harus dipenuhi ratusan temuan. Yang lebih penting adalah contoh halaman, bukti masalah, dampak terhadap tugas pengunjung, dan langkah perbaikan yang dapat diprioritaskan. Gunakan pemeriksaan berikut sebagai kerangka diskusi dengan tim internal serta vendor yang akan menangani pembaruan.

Inventarisasi halaman serta fungsi penting: audit website sebelum redesign

Buat daftar halaman dan fungsi sebelum menilai desainnya. Kelompokkan beranda, layanan, produk, artikel, lokasi, kontak, serta halaman khusus. Sertakan dokumen dan URL yang sering dibagikan lewat proposal atau pesan, walaupun tidak muncul pada menu utama.

Catat tujuan setiap halaman, pemilik informasi, dan status bahan. Pisahkan halaman aktif, isi usang, serta halaman yang belum diketahui kegunaannya. Jangan langsung menghapus konten yang jarang Anda buka; periksa dahulu apakah masih dipakai pelanggan atau bagian lain perusahaan.

Untuk fungsi, tulis skenario, bukan nama komponen. Form perlu dilihat dari pengisian sampai penerimaan pesan. Katalog perlu diperiksa pada pencarian, detail, dokumen, dan pembaruan admin. Inventaris ini kemudian menjadi acuan ketika tim menentukan lingkup redesign.

Tandai bagian yang tidak dapat diperiksa karena akses terbatas. Keterbatasan audit harus terlihat agar keputusan tidak bergantung pada asumsi yang tidak pernah diuji.

Petakan perjalanan dari pintu masuk ke kontak

Pilih beberapa tugas penting dan jalankan seperti pengunjung baru. Mulailah dari halaman yang mungkin ditemukan melalui pencarian, iklan, atau tautan pesan. Catat apakah pengguna dapat memahami penawaran dan mengetahui langkah berikutnya tanpa penjelasan dari staf.

Sebagai contoh hipotetis, buyer mesin masuk langsung ke detail produk. Ia membutuhkan kapasitas, sumber daya, dokumen, dan jalur pertanyaan. Beranda yang menarik tidak membantu jika informasi tersebut tidak tersedia atau tersembunyi pada file yang tidak dikenali.

Catat titik ketika konteks hilang. Tombol yang hanya berbunyi “selengkapnya” dapat sulit dipahami di luar susunan awalnya. Form umum juga bisa meminta pengunjung mengulang produk atau cabang yang baru dilihat.

Gunakan catatan tugas untuk membedakan hambatan utama dari preferensi. Banyak langkah belum tentu buruk jika setiap langkah membantu memilih, tetapi langkah yang tidak jelas perlu ditelusuri alasan dan dampaknya.

Tinjau kejelasan isi dan penawaran

Tinjau apakah halaman menjawab pertanyaan yang wajar sebelum orang menghubungi tim. Periksa layanan, batas area, proses, syarat, serta informasi harga jika memang dapat dipublikasikan. Jangan meminta penulis memperjelas bagian yang fakta dasarnya belum disetujui perusahaan.

Pisahkan fakta, klaim, dan ilustrasi. Bukti proyek harus sesuai pekerjaan yang benar dilakukan. Angka hasil atau testimoni memerlukan sumber yang dapat diperiksa, sedangkan contoh penggunaan perlu ditandai sebagai ilustrasi agar tidak dibaca sebagai pengalaman klien.

Periksa konsistensi antarhalaman. Nama layanan, kontak, jam buka, dan deskripsi proses yang berbeda dapat membuat pengunjung ragu. Tetapkan pemilik informasi agar koreksi tidak hanya menyentuh halaman yang kebetulan ditemukan saat audit.

Ubah temuan menjadi kebutuhan konten yang spesifik. Alih-alih menulis “copy kurang menjual”, catat pertanyaan yang belum terjawab, bagian yang membingungkan, dan fakta yang perlu dikonfirmasi kepada pemilik layanan.

Periksa navigasi mobile serta formulir

Jalankan tugas yang sama melalui ponsel. Periksa menu, keterbacaan, tabel, gambar, dan tombol kontak. Perhatikan apakah elemen mengambang menutupi isi atau apakah pengunjung perlu memperbesar layar untuk mengisi form.

Uji formulir dengan data lengkap, data tidak valid, dan percobaan pengiriman gagal jika kondisi pengujian memungkinkan. Periksa label, pesan kesalahan, konfirmasi, serta penerimaan oleh tim. Hindari menggunakan data pelanggan nyata untuk sekadar membuktikan alur bekerja.

Catat perangkat, browser, dan kondisi saat masalah muncul. Informasi ini membantu pengembang mengulangi masalah. Pernyataan “form kadang rusak” lebih sulit ditindaklanjuti daripada langkah yang menjelaskan halaman, input, dan hasil yang terlihat.

Jangan menyimpulkan semua pengunjung mengalami masalah yang sama dari satu percobaan. Gunakan temuan sebagai dasar pengujian tambahan, lalu jelaskan keterbatasannya pada laporan.

Catat masalah aksesibilitas yang terlihat

Panduan aksesibilitas MDN menjelaskan upaya membuat website dapat digunakan oleh lebih banyak orang. Mulailah dari struktur heading, label form, kontras, dan navigasi keyboard. Pemeriksaan ini perlu masuk penilaian fungsi, bukan dianggap hiasan tambahan.

Coba menavigasi bagian utama tanpa mouse. Periksa urutan fokus dan apakah pengguna mengetahui posisi yang sedang dipilih. Tautan serta tombol harus mempunyai label yang menjelaskan tindakannya, terutama ketika dibaca terpisah dari konteks visual.

Periksa gambar yang berisi informasi penting. Jika jadwal atau persyaratan hanya tersedia dalam gambar, pengunjung dapat kesulitan membaca atau mengaksesnya. Tinjau kebutuhan teks alternatif dan pertimbangkan penyajian informasi sebagai teks yang dapat diperbarui.

Pemeriksaan dasar tidak sama dengan audit kepatuhan penuh. Nyatakan cakupan dan metode yang digunakan. Temuan otomatis tetap perlu diperiksa manusia agar rekomendasinya sesuai konteks halaman.

Uji kinerja dan kondisi teknis dasar

Dokumentasi Core Web Vitals Google membahas metrik pengalaman pengguna seperti pemuatan, interaksi, dan kestabilan tampilan. Gunakan temuan kinerja untuk mencari sumber hambatan, bukan menyatakan satu skor sebagai penilaian menyeluruh website.

Bedakan kondisi pengujian dan data lapangan yang tersedia. Hasil satu percobaan dapat dipengaruhi perangkat, koneksi, serta layanan pihak ketiga. Catat metode agar tim dapat membandingkan pemeriksaan dengan dasar yang sama.

Periksa gambar besar, font, video, dan script yang tidak mendukung tugas utama. Setiap komponen perlu mempunyai alasan penggunaan. Menghapus komponen secara sembarang juga dapat merusak pengukuran atau fungsi yang memang dibutuhkan.

Masukkan pemeriksaan teknis dasar seperti respons halaman, tautan rusak, dan integrasi kontak. Temuan perlu dihubungkan dengan halaman atau template yang terpengaruh, lalu dibahas bersama pihak yang dapat mengimplementasikan perbaikannya.

Tinjau URL dan halaman organik yang dipertahankan

Penjelasan Google tentang cara kerja pencarian membedakan perayapan, pengindeksan, dan penyajian hasil. Dalam audit, periksa apakah halaman penting dapat ditemukan serta diakses, tetapi jangan menjanjikan bahwa setiap URL pasti diindeks atau mendapat posisi tertentu.

Inventarisasi URL yang akan dipertahankan, digabung, dipindahkan, atau dihentikan. Hubungkan keputusan dengan isi pengganti yang relevan. Mengganti struktur website perlu mempertimbangkan tautan yang sudah digunakan pelanggan dan alat pencarian.

Periksa judul, canonical, pengaturan indeks, serta tautan internal sesuai akses yang tersedia. Jika data pencarian tidak tersedia, sebutkan batasnya. Audit tetap dapat menemukan masalah, tetapi tidak boleh mengarang trafik atau volume untuk memberi kesan lebih pasti.

Simpan daftar pemeriksaan untuk setelah peluncuran. Migrasi memerlukan validasi pada website aktif karena konfigurasi lingkungan uji dan produksi dapat berbeda.

Ubah temuan menjadi daftar pekerjaan berprioritas

Kelompokkan temuan berdasarkan dampak, usaha, dan dependensi. Hambatan formulir utama mungkin perlu diperbaiki segera. Perubahan model data dapat menunggu keputusan arsitektur. Koreksi fakta tertentu memerlukan persetujuan pemilik layanan sebelum pengembang mengubah halaman.

Setiap rekomendasi sebaiknya mempunyai contoh, alasan, pemilik, dan cara memeriksa hasil. Hindari daftar panjang yang tidak menunjukkan urutan. Tim membutuhkan dasar untuk memilih pekerjaan pertama dan memahami masalah yang masih tersisa.

Susun beberapa lingkup: perbaikan terbatas, redesign, atau pembangunan ulang bila temuan memang mendukungnya. Jelaskan bagian yang dapat dipakai kembali dan risiko dari masing-masing pilihan. Audit website sebelum redesign seharusnya membantu keputusan, bukan otomatis membenarkan proyek paling besar.

Akhiri dengan daftar keputusan yang belum selesai. Pemilik bisnis, penulis, desainer, dan pengembang dapat menyelesaikan bagiannya melalui rencana kerja yang sama. Dengan demikian, audit berubah menjadi pekerjaan yang dapat ditinjau, bukan dokumen yang berhenti setelah presentasi.

Contoh keputusan yang dapat ditinjau

Sebagai ilustrasi hipotetis, perusahaan material ingin memperbarui website karena pertanyaan tentang produk terlalu umum. Audit mengambil satu tugas: calon pembeli mencari produk dengan spesifikasi tertentu lalu meminta penawaran. Tim menjalankan tugas melalui ponsel dan mencatat bahwa kategori mudah ditemukan, tetapi detail mutu serta area pengiriman tidak tersedia.

Mereka tidak langsung menyimpulkan perlu mengganti seluruh desain. Temuan dipisahkan menjadi kebutuhan isi, model katalog, dan alur kontak. Tim teknis memeriksa spesifikasi, penjualan menjelaskan data awal penawaran, dan pengembang menilai perubahan field produk. Foto besar yang memperlambat halaman dicatat sebagai pekerjaan berbeda.

Backlog kemudian menempatkan informasi spesifikasi serta form kebutuhan sebagai prioritas. Penggantian animasi beranda memiliki alasan yang lebih lemah karena tidak menyelesaikan tugas utama. Setiap item diberi kriteria uji: produk dapat ditemukan, dokumen terbuka, dan permintaan membawa informasi yang diperlukan. Keputusan ini menunjukkan bagaimana audit membantu menentukan lingkup berdasarkan hambatan nyata.

Tim juga memeriksa bagaimana admin memperbarui informasi pengiriman. Mereka menemukan bahwa rincian yang sama ditulis ulang pada beberapa halaman. Masalah ini menambah risiko inkonsistensi ketika area layanan berubah. Rekomendasinya bukan sekadar memperbaiki kalimat, tetapi menentukan satu sumber informasi yang dipelihara oleh pemilik proses dan ditampilkan secara konsisten.

Untuk memperkirakan usaha, pengembang meminta contoh produk sederhana dan produk dengan variasi. Penulis meminta daftar pertanyaan pelanggan beserta fakta yang disetujui. Dengan bahan ini, masing-masing pihak dapat menjelaskan pekerjaannya tanpa menebak jumlah dokumen atau pola data. Temuan audit menjadi penghubung antara kebutuhan pengguna dan estimasi pelaksanaan.

Sebelum proyek dimulai, perusahaan memilih URL yang akan dipertahankan. Halaman produk yang masih berguna tidak dihapus hanya karena tampilannya akan berubah. Halaman berulang dipetakan ke pengganti yang paling relevan. Daftar tersebut disimpan sebagai bahan pengujian migrasi, lalu diperiksa kembali setelah website aktif diperbarui.

Audit tidak menjanjikan penjualan meningkat setelah daftar pekerjaan selesai. Tim menilai keberhasilan awal dari hal yang dapat diperiksa: informasi benar, tugas pencarian produk dapat dijalankan, dan form berfungsi. Kualitas permintaan kemudian dibahas bersama sales menggunakan data yang tersedia. Jika masalah masih muncul, perusahaan dapat kembali ke catatan tugas dan memperbaiki bagian yang belum membantu, tanpa menganggap seluruh keputusan awal pasti benar.

Dalam laporan akhir, bagian keterbatasan tetap terlihat. Halaman yang belum dapat diuji, akses yang belum tersedia, dan fakta yang menunggu persetujuan tidak ditampilkan sebagai pekerjaan yang sudah selesai. Keterbukaan ini membantu pengambil keputusan memahami ketidakpastian sebelum menyetujui lingkup pembaruan.

Pertanyaan yang sering muncul

Apakah audit harus menunggu akses analytics?

Tidak. Pemeriksaan isi, navigasi, aksesibilitas, dan fungsi dapat dimulai dari akses publik. Namun, jelaskan batas ketika data perilaku atau pencarian belum tersedia. Jangan mengganti data yang hilang dengan perkiraan trafik yang tidak memiliki sumber.

Apakah semua temuan perlu masuk redesign?

Tidak. Sebagian dapat diperbaiki segera, sebagian bergantung pada perubahan struktur, dan sebagian membutuhkan klarifikasi. Prioritaskan berdasarkan tugas utama, risiko, dan dependensi. Catat pekerjaan yang ditunda agar tidak hilang dari pembahasan.

Apa keluaran audit yang paling berguna bagi vendor?

Daftar temuan dengan contoh URL, langkah mengulangi masalah, dampak, dan kriteria penerimaan. Tambahkan inventaris isi serta keputusan URL. Informasi itu membantu vendor memperkirakan pekerjaan dengan lebih tepat daripada komentar umum tentang tampilan.

Bacaan untuk langkah berikutnya

Sesuaikan pembahasan ini dengan proses bisnis sebelum meminta proposal. Anda dapat memeriksa lingkup pembuatan website sebagai titik awal menentukan pekerjaan dan kebutuhan akses.

Contoh kebutuhan industri yang relevan dapat ditelusuri pada Rumah Mewah, Rumah Sakit, Brand Fashion. Gunakan konteksnya untuk menilai informasi, jalur kontak, dan tanggung jawab operasional yang benar dibutuhkan.

• Menyusun Brief Website agar Proposal Lebih Tepat
• Redesign atau Bangun Ulang Website: Cara Menentukannya
• Struktur Website B2B untuk Memudahkan Permintaan Penawaran
• Ruang Lingkup Audit SEO: Isi Laporan yang Berguna

Sumber rujukan

• MDN Web Docs: What is accessibility?
• Google Search Central: Understanding Core Web Vitals and Google search results
• Google Search Central: In-depth guide to how Google Search works