Daftar periksa relaunch untuk toko online, situs pemesanan, & situs perusahaan

Saatnya untuk melakukan relaunch? Selamat, bahwa kamu menemukan artikel ini. Pembahasan berikut mungkin akan memberikan kontribusi penting bagi kamu agar relaunch berhasil dan mencapai hasil yang fantastis. Karena hal itu tidak selalu terjadi. Aku pemilik agensi dan akan memberitahumu tepatnya apa yang dapat memaksa kamu dan orang-orang seperti aku untuk bekerja dengan sangat baik serta untuk menghindari kesalahan-kesalahan umum dalam relaunch. Namun, mari kita mulai dari awal.

Relaunch website adalah penataan kembali dan penyegaran dari sebuah website yang sudah ada. Dalam hal ini, baik desain, konten, maupun teknologi dapat diubah. Tujuan dari relaunch website adalah untuk meningkatkan kualitas website dan menyesuaikannya dengan tuntutan saat ini.

Beberapa pemicu eksternal mendorong perusahaan untuk menyatakan tujuan "relaunch": karyawan baru yang membawa ide-ide menarik, pimpinan baru datang dan ingin membersihkan secara digital, pesaing memiliki website baru, atau penurunan pendapatan. Mungkin istri dari pimpinan tidak menyukai tampilan lama website atau generasi Z tidak merasa nyaman dengan website tersebut. Mungkin hal tersebut sudah tidak asing bagi kamu. Namun, alasan bahwa sudah saatnya untuk website baru, sama seperti opini personal, bukanlah alasan yang tepat untuk relaunch.

Namun, ada beberapa alasan yang lebih beralasan mengapa perusahaan atau organisasi ingin melakukan relaunch website. Beberapa alasan pokok tersebut antara lain:

• Desain usang dan/atau perubahan merek: Website yang usang dapat memberikan kesan bahwa perusahaan tersebut ketinggalan zaman atau tidak aktif lagi. Desain yang segar dan modern diharapkan dapat meningkatkan citra perusahaan. Jika citra merek atau identitas perusahaan berubah, seringkali diinginkan untuk melakukan relaunch website guna mencerminkan pesan merek yang baru.
• Pengalaman pengguna yang lebih baik: Jika tata letak website tidak ramah pengguna, hal ini dapat menyebabkan tingkat bounce rate yang tinggi. Relaunch dapat diperlukan untuk meningkatkan pengalaman pengguna dan memudahkan navigasi website.
• Optimisasi mobile: Karena semakin banyak orang yang mengakses website melalui perangkat mobile, penting untuk memastikan website dapat berfungsi dengan baik pada berbagai ukuran layar dan perangkat.
• Optimisasi mesin pencari (SEO): Website yang usang dapat memiliki masalah kinerja SEO. Relaunch memberikan kesempatan untuk membuat perubahan yang ramah SEO guna meningkatkan visibilitas di mesin pencari.
• Pembaruan konten: Jika informasi, layanan, atau produk perusahaan mengalami perubahan, website harus diperbarui untuk mencerminkan perubahan tersebut.
• Peningkatan keamanan: Website lama sering rentan terhadap risiko keamanan. Relaunch dapat digunakan untuk meningkatkan keamanan website dan melindungi dari serangan cyber.
• Pembaruan teknologi: Penggunaan teknologi yang ketinggalan zaman dapat mempengaruhi kinerja website. Relaunch dapat memberikan kesempatan untuk beralih ke teknologi dan platform web yang lebih mutakhir.
• Aksesibilitas: Peningkatan aksesibilitas merupakan perhatian penting bagi banyak website, untuk memastikan bahwa website dapat diakses oleh individu dengan disabilitas.
• Daya saing: Untuk tetap bersaing dengan pesaing, penting untuk memiliki website modern dan berkualitas. Relaunch dapat membantu menjaga atau meningkatkan daya saing.
• Peningkatan analitik: Dengan menerapkan alat analisis yang lebih baik dan pengumpulan data, perusahaan dapat lebih memahami dan mengoptimalkan kinerja website mereka.
• Kepatuhan dengan persyaratan hukum: Hukum dan regulasi terkait privasi data, aksesibilitas, dan keamanan terus berubah. Relaunch mungkin diperlukan untuk memastikan website mematuhi persyaratan tersebut.

Alasan-alasan ini dapat muncul secara individual atau secara kombinasi dan bervariasi tergantung pada tujuan dan kebutuhan perusahaan. Relaunch website seringkali merupakan keputusan strategis untuk meningkatkan prisitasi online dan mencapai tujuan perusahaan. Jika melihat daftar di atas satu per satu, akan terlihat bahwa kebanyakan alasan tersebut dapat diimplementasikan dengan sprint kecil dan tidak memerlukan relaunch besar.

Oleh karena itu, mari kita bedakan apa yang dimaksud dengan relaunch dan apa yang bukan: Desain baru dengan dasar teknis yang sudah ada lebih mirip dengan Facelifting. Relaunch baru tercapai ketika dengan tujuan relaunch terdapat perubahan nyata dalam pengalaman pengguna, cara kerja, dan dasar teknisnya.

Relaunch selalu harus didasari oleh fakta (misalnya, teknologi mendekati kebuntuhan dan tidak dapat ditingkatkan lagi), data kuantitatif, dan data perbandingan.

Ini adalah rekomendasi pertama yang ingin saya sampaikan di sini: Evolution over Revolution! Hindari relaunch sepanjang mungkin dan cobalah untuk mengimplementasikan semua poin yang telah diangkat untuk relaunch secara individu atau secara inkremental. Perbaiki satu hal, terapkan, evaluasi, implementasi kembali, atau lanjutkan ke poin berikutnya. Contoh terbaiknya adalah Amazon, yang benar-benar hanya sedikit mengubah dan memperbaiki diri dan telah lama tidak melakukan perubahan besar dalam relaunch.

Relaunch selalu membawa risiko besar terhadap visibilitasmu di Google. Semua orang fokus pada peningkatan, tapi sedikit yang menaruh perhatian pada risiko. Tentu saja, antarmuka pengguna akan meningkat, pengalaman pengguna positif akan naik, secara teknis kita kembali segar. Namun, jika kesuksesanmu sebagai usahawan bergantung pada visibilitas organik yang kuat, relaunch adalah saat terakhir dan diputuskan hanya jika rasa sakitmu cukup besar yang disebabkan oleh kombinasi alasan-alasan di atas yang tidak dapat diselesaikan dalam sprint individu. Mengapa? Lihat bagaimana hasil visibilitas online dari keempat website setelah relaunch:

Rencanakan relaunch Anda secara hati-hati dan pastikan keberhasilan realisasinya dengan menggunakan checklist. Terutama tetapkan dua tujuan, pertama untuk mempertahankan visibilitas online Anda dan kedua untuk menemukan cara agar dalam kerangka relaunch dapat menciptakan dasar untuk meningkatkan visibilitas online. Artikel ini hadir untuk memberikan panduan relaunch kepada Anda, sehingga risiko relaunch Anda tetap terbatas dan Anda benar-benar mendapatkan hasil kerja yang sangat baik dengan potensi kesuksesan SEO organik yang berkelanjutan.

Rencana Relaunch

Perencanaan relaunch situs web harus dilakukan dengan cermat. Penting untuk mempertimbangkan langkah-langkah berikut:

• Analisis situs web yang sudah ada dan pencatatan kondisi saat ini: Pertama, situs web yang sudah ada harus dianalisis untuk mengidentifikasi kekuatan dan kelemahannya.
• Menetapkan tujuan: Tujuan relaunch situs web harus didefinisikan dengan jelas. Ini meliputi, misalnya, peningkatan tingkat konversi, peningkatan jumlah pengunjung, atau perubahan ke CMS baru dengan perawatan konten dan pemeliharaan yang ditingkatkan.
• Pengembangan konsep: Berdasarkan analisis dan tujuan serta analisis pesaing, sebuah konsep untuk relaunch situs web harus dikembangkan. Konsep tersebut harus mencakup aspek-aspek berikut: Desain, Konten, Teknologi, dan SEO/Pemasaran.
• Implementasi: Konsep kemudian diimplementasikan. Ini termasuk pengembangan desain, pembuatan/penyesuaian konten, dan penerapan perubahan teknis.
• Pengujian: Situs web baru harus diuji secara menyeluruh sebelum diluncurkan, untuk memastikan bahwa situs tersebut berfungsi tanpa kesalahan. Ini juga termasuk penggunaan checklist yang telah ditentukan.
• Peluncuran: Situs web baru kemudian diluncurkan. Dan situs tersebut akan terus diuji secara langsung, dievaluasi, dan disesuaikan.

Penetapan Tujuan dan Strategi Relaunch

Tentukan dengan tepat tujuan apa yang ingin dicapai oleh relaunch. Tujuan tersebut bisa (selain alasan-alasan yang disebutkan di atas): 

• Peningkatan Pengalaman Pengguna
• Peningkatan Keterbacaan
• Pembangunan Penawaran Konten
• Modernisasi Desain
• Peningkatan Pendapatan dan Nilai Keranjang Belanja 
• Pergantian ke CMS lain dengan pemeliharaan konten yang lebih mudah dan pemeliharaan teknis yang lebih baik
• Kemungkinan pemeliharaan dan penerimaan pembaruan yang lebih mudah dimasa mendatang.

Saran: Setelah pertemuan awal dalam tim sebagai perusahaan - sebelum memasuki pembicaraan dengan agensi pelaksana - semua pihak yang terlibat dalam proyek harus mencatat tujuan relaunch Anda di selembar kertas atau ke dalam kotak masukan mereka dalam alat komunikasi Anda (misalnya Slack). Jika semua orang kemudian secara bersamaan menunjukkan tujuan mereka, Anda akan kagum melihat betapa beragam pandangan mereka, meskipun tujuan tersebut sudah dibicarakan secara lisan dalam pertemuan sebelumnya. Oleh karena itu, penting untuk menuliskan tujuan secara tertulis juga. Dengan mengetahui tujuan Anda dengan jelas, Anda dapat memeriksanya pada prototipe UI pada tahap awal untuk memastikan bahwa tujuan tersebut telah dipertimbangkan secara konseptual.

Dokumen Persyaratan Memberikan Kepastian Tentang Tugas Relaunch

Agensi memerlukan briefing proyek yang komprehensif dari klien untuk menyusun penawaran. Perusahaan biasanya memiliki dokumen Word atau PDF yang lebih atau kurang menjelaskan rencana tersebut. Ada kuesioner atau dilakukan workshop, dengan cara tersebut agensi dapat menyoroti titik-titik sakit klien untuk dapat memberikan penawaran. Pada proyek yang lebih besar, dokumen persyaratan relaunch (lastenheft) dapat dibuat. Semakin lengkap, semakin baik. 

Sebuah dokumen persyaratan memainkan peran penting dalam relaunch situs web. Ini digunakan untuk mencatat persyaratan, tujuan, dan harapan relaunch secara tertulis. Dokumen persyaratan yang baik membantu memastikan bahwa semua pihak terkait - baik itu tim pengembangan, tim desain, atau klien - memiliki pemahaman yang jelas tentang apa yang harus dicapai selama proses relaunch. Hal ini juga merupakan dasar untuk penawaran yang pasti dan terikat dari agensi pelaksana. Berikut adalah informasi dan elemen yang biasanya terdapat dalam dokumen persyaratan untuk relaunch situs web:

• Tujuan dan Tujuan: Deskripsi tujuan utama relaunch, misalnya, peningkatan pengalaman pengguna, peningkatan visibilitas dalam mesin pencari, atau pergantian CMS dengan pembaruan desain.
• Lingkup Proyek: Definisi yang jelas tentang apa yang termasuk dan yang tidak termasuk dalam relaunch. Ini bisa mencakup jumlah halaman, integrasi alat pihak ketiga, atau revisi konten.
• Persyaratan Desain: Informasi tentang desain visual situs web yang diinginkan, termasuk layout dan kepatuhan terhadap pedoman desain perusahaan terkait warna, jenis huruf, dan gambar.
• Persyaratan Fungsionalitas: Rincian tentang fungsi dan interaksi yang diinginkan pada situs web, seperti formulir kontak, fungsi pencarian, fungsi e-commerce, dll.
• Persyaratan Teknis: Spesifikasi untuk teknologi yang akan digunakan selama relaunch, seperti pemilihan Sistem Manajemen Konten (CMS) atau implementasi fungsi khusus. Penggunaan format gambar dan grafis modern (WebP, AVIF, SVG) juga termasuk di dalamnya.
• Pencadangan Manual dan Otomatis dan Revisi dari Pengeditan Konten.
• Persyaratan Konten: Pedoman jelas untuk merevisi, memperbarui, atau membuat kembali konten, termasuk teks, gambar, video, dan media lainnya. Penanganan metadata dan data terstruktur.
• Persyaratan SEO: lebih lanjutnya dalam bagian konten berikutnya.
• Jadwal dan Milestone: Jadwal yang menetapkan tanggal mulai dan selesai yang direncanakan untuk relaunch serta tonggak penting.
• Anggaran: Informasi tentang anggaran untuk relaunch, termasuk biaya desain, pengembangan, hosting, serta layanan pihak ketiga yang mungkin dibutuhkan.
• Penjaminan Kualitas dengan Alat Uji: Deskripsi pengujian dan prosedur kontrol kualitas yang akan dilakukan selama relaunch untuk memastikan bahwa situs web berfungsi dengan baik.
• Persyaratan Pemeliharaan dan Dukungan: Persyaratan untuk pemeliharaan berkelanjutan dan dukungan situs web setelah relaunch.

Suatu daftar kebutuhan yang terstruktur dengan baik sangat penting untuk menghindari kesalahpahaman, mengatur proyek secara efisien, dan memastikan bahwa harapan dari semua pihak terpenuhi. Ini berfungsi sebagai panduan dan dokumen referensi untuk seluruh tim proyek dan membantu memastikan keberhasilan rencana pengembangan ulang situs web.

Ketika kami merencanakan pengembangan ulang TutKit.com dengan pergantian lengkap dari CodIgniter ke Laravel, daftar kebutuhan kami terdiri dari 220 halaman - bukanlah tugas yang menggoda bagi sebuah agensi untuk menyelesaikannya.

Catatan: Konsep, desain, fungsi, dan teknologi yang digunakan tidak akan dijelaskan secara detail dalam artikel saya. Situs web baru akan tampak menarik. Ancaman terbesar dalam pengembangan ulang sebenarnya terletak pada penurunan pengalaman pengguna teknis dan kualitas halaman yang disebabkan oleh tidak adanya 301-Redirects, dll., yang kemudian akan menyebabkan penurunan peringkat dan visibilitas. Untuk mencegah hal ini, fokus utama akan diberikan pada memastikan keberhasilan proyek dari sudut pandang pengalaman pengguna dan SEO.

Definisi Persyaratan SEO untuk Situs Web Baru

Briefing dari klien atau daftar kebutuhan yang lebih rinci telah mengatur hal-hal seperti yang diinginkan secara artistik, konten, fungsional, dan teknis, dan menjadi dasar bagi sebuah agensi untuk menyusun kalkulasi.

Untuk Checklist Pengembangan Ulang untuk Menjamin Keberhasilan Proyek, hal-hal berikut perlu diperhatikan dari sudut pandang SEO:

• perubahan struktur URL (Peta Alih Arah URL!) dan perubahan jalur tautan
• perubahan navigasi (penting karena penghubungan internal dan hierarki tautan)
• perubahan teknologi (CMS, Framework JavaScript, Server, …)
• perubahan konten (potensi kehilangan visibilitas halaman yang telah baik peringkatnya)

Halaman akan mendapatkan peringkat tinggi di Google karena relevansi kontennya, oleh karena itu pertanyaan yang penting adalah apakah konten yang ada akan berubah atau digabungkan, apakah konten akan dihapus dan/atau konten baru akan ditambahkan? Apakah struktur konten dari kategori atau halaman akan berubah? Dari poin-poin ini, persyaratan SEO harus ditarik yang akan dimasukkan dalam Checklist Pengembangan Ulang.

Apakah metadata dari konten lama juga akan dipindahkan dan berubah? Bagaimana perawatan konten dilakukan oleh editor dan apakah konten halaman terhubung dengan data terstruktur?

Akankah gambar yang ada atau baru diletakkan di situs dengan format gambar modern untuk situs web (WebP/Avif) dan apakah perhatian diberikan pada SEO gambar dengan URL yang bisa diinterpretasikan dengan huruf kecil, yaitu bukan lagi 1234.jpg => hotel-ostsee-warnemuende_suite-nachtigall.avif.

Demikian pula, perlu untuk memastikan bahwa file gambar dikaitkan dengan data terstruktur (ImageObject) dan Thumbnail dikirimkan ke Google, untuk meningkatkan kemungkinan gambar disematkan dalam potongan hasil pencarian dan terdaftar di Google Gambar.

Juga menarik dalam konteks ini adalah bagaimana cara meningkatkan hasil sinyal dari pengguna. Misalnya, pada halaman konten dapat disematkan video, video penjelasan, dan bantuan. Jika pengguna yang datang dari Google ke halaman arahan mengklik video dan menontonnya, maka lamanya kunjungan akan meningkat (sinyal pengguna yang baik), tingkat kembali ke hasil pencarian Google juga akan membaik (sinyal pengguna yang baik).

Juga perlu dipertimbangkan bagaimana bagian-bagian isi dapat diintegrasikan ke dalam halaman, yang memenuhi Persyaratan Bantuan Konten Google dan untuk prinsip E-E-A-T dari Google.

Bagi Google, "Bantuan Konten" adalah konten yang relevan dan berguna bagi pengguna. Konten ini secara komprehensif dan informatif menjawab pertanyaan pengguna, memberikan solusi untuk masalah, dan memberikan nilai tambahan di luar pesan promosi semata.

Berikut adalah beberapa contoh konten bermanfaat:

• Tutorial dan Panduan: Konten tersebut membantu pengguna belajar tugas baru atau memecahkan masalah yang ada.
• Ulasan dan Perbandingan: Konten ini membantu pengguna memilih produk atau layanan yang tepat.
• Berita dan Pembaruan: Konten ini memberikan informasi terbaru dan tren kepada pengguna.
• Infografis dan Diagram: Konten ini membantu memvisualisasikan data dan informasi yang kompleks.
• Artikel Blog: Konten ini memberikan wawasan mendalam mengenai suatu topik tertentu.

Google menggunakan berbagai sinyal untuk mengenali konten yang bermanfaat. Termasuk di antaranya adalah:

• Perilaku Pengguna: Google memantau bagaimana pengguna berinteraksi dengan konten, misalnya berapa lama mereka tinggal di halaman, seberapa sering mereka membagikannya, dan seberapa sering mereka memberikannya penilaian.
• Sinyal Kualitas: Google menilai kualitas konten berdasarkan faktor-faktor seperti relevansi, kelengkapan, dan kebaruan.
• Umpan Balik dari Pengguna: Google juga mempertimbangkan umpan balik dari pengguna, seperti penilaian dan komentar.
• Dengan memperhatikan sinyal-sinyal ini, pemilik situs web dapat meningkatkan peluang agar kontennya dianggap bermanfaat.

Prinsip EEAT adalah konsep yang dikembangkan oleh Google untuk menilai kualitas situs web dan konten web. Ini mewakili Keahlian, Pengalaman, Otoritas, dan Kepercayaan, yaitu Keahlian, Pengalaman, Otoritas, dan Kepercayaan.

• Keahlian merujuk pada pengetahuan dan pengalaman individu yang membuat konten tersebut. Google menilai keahlian berdasarkan faktor-faktor seperti pendidikan, pengalaman kerja, dan penghargaan.
• Pengalaman menjadi bukti ketika konten juga dibuat dengan pengalaman tertentu, misalnya berdasarkan penggunaan nyata suatu produk, kunjungan aktual ke suatu tempat, atau deskripsi dari pengalaman seseorang?
• Otoritas merujuk pada reputasi situs web atau konten web. Google menilai otoritas berdasarkan faktor-faktor seperti backlink, aktivitas media sosial, dan ulasan pengguna.
• Kepercayaan merujuk pada keandalan dan kredibilitas situs web atau konten web. Google menilai kepercayaan berdasarkan faktor-faktor seperti privasi, keamanan, dan transparansi.

Apa persyaratan SEO untuk fitur baru dan yang sudah ada dalam hal frontend dan backend? Berikut ini beberapa contohnya:

• Kemudahan diindeks (konten yang relevan harus tetap terlihat dan dapat diindeks tanpa JavaScript)
• Keterangannya tentang tujuan situs web dan jelas tentang Call-to-Action (tindakan yang diinginkan dari pelanggan target di halaman tersebut)
• Menghindari konten duplikat melalui misalnya halaman kategori yang dibuat secara otomatis atau duplikat halaman melalui artikel variasi
• Memastikan PageSpeed tinggi dengan menghindari terlalu banyak file JavaScript dan CSS, dengan menggunakan format gambar modern (WebP/AVIF)

Persyaratan SEO ini harus termasuk dalam briefing proyek atau dalam spesifikasi proyek, juga harus melalui checklist yang terkait dengan alat uji atau sebagai perbandingan IST-SOLL dalam jaminan kualitas proyek dan tambahan sebagai kriteria penerimaan untuk layanan agensi. Selengkapnya di bawah.

Penetapan Pihak Berkepentingan Proyek Internal dan Eksternal

Tentukan pihak berkepentingan proyek - di sini dari sudut pandang pelanggan atau pemilik situs web:

• Siapa yang bertanggung jawab atas manajemen proyek dan membuat keputusan akhir?
• Siapa yang bertanggung jawab untuk koordinasi dan komunikasi dengan agensi atau dengan pelanggan?
• Siapa yang mengelola proyek secara internal?
• Siapa yang menyiapkan konten dan bantuan bagi agensi secara internal?
• Siapa yang menerapkan desain User Experience?
• Siapa yang menerapkan pengembangan?
• Siapa yang melaporkan kepada pelanggan secara berkala sesuai dengan interval yang ditetapkan?
• Siapa yang bertanggung jawab atas pengujian oleh agensi/pelanggan dan jaminan kualitas?
• Apakah konsultan eksternal diikutsertakan (misalnya untuk SEO atau persyaratan hukum)?
• Siapa yang membebaskan tugas? Siapa yang menerima tugas dalam sistem tiket setelah selesai dikerjakan?
• Siapa yang harus diinformasikan pada waktu tertentu (karyawan, pelanggan, mitra, pengelola kampanye iklan, …)?

Empat Hal Penting dalam Memilih Penyelenggara Proyek Eksternal

1. Sudahkah agensi itu merealisasikan satu atau lebih proyek semacam itu? Apakah ada referensi? Ada testimonial pelanggan dan apakah mungkin untuk wawancara kembali dengan pelanggan agensi - yang direkomendasikan untuk pengembangan individual yang besar?
   
2. Apakah dengan tawaran dan implementasi teknis (CMS/sistem toko/framework) sudah memenuhi semua persyaratan yang terkait dengan relaunch? Apakah ada fitur atau persyaratan khusus yang harus diprogramkan (bahkan melalui plugin atau modul)? Apakah di dalam tawaran ada layanan tertentu yang dikecualikan atau ditunda untuk waktu yang akan datang, tetapi sangat diperlukan untuk keberhasilan proyek? Penting untuk tidak menambahkan masalah baru yang lebih besar daripada alasan awal untuk relaunch.
   
3. Apakah agensi atau penyedia layanan cocok baik dari ukuran tim maupun lokasi regional dan (melalui evaluasi Kununu mungkin) turnover karyawan yang dapat dipahami untuk pelayanan jangka panjang perusahaan?
   
4. Apakah ada kontak langsung dengan tim desain dan pengembangan yang melaksanakan? Masuk akal untuk mengenal tim proyek aktual di agensi. Para profesional penjualan yang ceria dan obat penawaran kosong yang segera menghilang hanya bertugas untuk mendapat kontrak dan kemudian tidak lagi bertanggung jawab. Karena itu, sebaiknya juga disepakati kontak langsung dengan tim yang melaksanakan projek tersebut.

Empat Tips untuk Perlindungan Anda sendiri dalam Konteks Ini

1. Sebagai pelanggan, perhatikan teknologi yang digunakan oleh agensi. Coba cari tahu apa yang ada dalam tawaran dengan googling "CMS + Kekurangan" atau "CMS + Pengalaman". Anda harus tahu persis apa yang Anda hadapi. Disarankan untuk menggunakan solusi Open Source. Saya sadar bahwa ini tidak selalu memungkinkan. Lebih baik pastikan bahwa ada komunitas pengembang yang besar untuk teknologi yang digunakan, sehingga Anda tidak akan berakhir dengan solusi propietary yang hanya agensi Anda yang bisa kelola, yang pada akhirnya akan memberikan Anda tekanan tersendiri.
   
2. Pastikan juga bahwa Anda mendapatkan hak penggunaan dan pengeditan tanpa batas dari layanan agensi sehingga Anda memiliki hak untuk mengembangkan situs web itu sendiri secara internal atau eksternal. Klausul semacam ini harus dimasukkan dalam kontrak kerja.
   
3. Jika perusahaan Anda memiliki tim yang cakap dalam teknologi dan memiliki administrator sistem, pengembang perangkat lunak, atau yang sejenis dalam tim, layak untuk menyiapkan GIT untuk melakukan Version Control dan JIRA (atau alat serupa) untuk manajemen proyek atau sistem tiket dalam akun Anda sendiri dahulu. Kemudian berikan akses penuh pada agensi dan pekerjaan dapat dimulai. Semakin besar proyeknya, semakin kasar dan menyakitkan akan menjadi. Jadi, lebih baik jika Anda memiliki kendali penuh atas akses dan akun yang penting. Namun saya sadar bahwa rekomendasi ini secara fungsional hanya bisa diikuti oleh sedikit pelanggan.
   
4. Terkadang agensi menawarkan hosting langsung kepada pelanggan. Kami sendiri tidak suka hal ini, karena meningkatkan ketergantungan dalam hubungan pelanggan, selain itu, kami yakin bahwa penyedia web hosting merupakan yang terbaik untuk web hosting karena spesialisasinya. Kami bahkan pernah membangun dan mengelola server kami sendiri dan menghabiskan banyak sumber daya tenaga kerja dan waktu. Kami kembali lagi. Sekarang sistem kami berjalan di cloud server dari salah satu penyedia web hosting besar di Jerman dan kami bahagia. Pastikan untuk memeriksa apakah back up server-side sudah termasuk dalam paket, yang dapat dipulihkan hanya dengan beberapa klik.

Penentuan Rentang Waktu dan Tanggal Peluncuran

Relaunch dilakukan dalam beberapa sprint proyek. Ini bisa berdasarkan pengalaman agensi kami:

• Kondisi saat ini dicatat (melalui alat uji, namun juga secara tertulis dengan kesan tentang apa yang berjalan baik dari sisi pelanggan dan mana yang perlu diperbaiki)
• Fase riset dengan analisis pesaing dan penelusuran solusi/inspirasi
• Konsepsi wireframe
• Desain antarmuka pengguna
• Pengembangan frontend dan backend
• Migrasi data atau impor konten (otomatis/manual)
• Optimisasi konten struktural dan isi (teks dan gambar) & Sprint SEO

Proyek sprint tumpang tindih karena seiring berjalannya pekerjaan, pihak berkepentingan baru turut aktif.

Penting untuk menentukan rentang waktu untuk setiap sprint proyek dan menyelaraskannya dengan pihak yang terlibat.

Apakah agensi untuk klien, jika proyek tersebut cukup besar, menyiapkan Saluran Slack sendiri untuk komunikasi yang lebih cepat?

Saran di sini: Sangat baik jika agensi sudah mulai menggunakan prototipe yang dapat diklik pada tahap yang sangat awal, sudah pada konsepsi wireframe dan terutama saat mempresentasikan dan menguji Desain Antarmuka Pengguna. Dengan demikian, pelanggan akan lebih memahami pengalaman situs web. File JPG atau PNG sederhana sebagai proposal tata letak tidak lagi sesuai zaman. Harus berupa prototipe yang dapat diklik, yang dibuat dengan Sketch, Figma, Adobe XD, atau alat profesional lainnya.

Pada tahap awal ini, perubahan dapat dilakukan dengan mudah. Jika fitur dan bagian situs web telah dikembangkan, perubahan akan jauh lebih rumit dan kemungkinan memunculkan negosiasi tambahan yang tidak diinginkan.

Di sini terlihat bagaimana prototipe untuk Desain Antarmuka Pengguna mobile dengan jalur klik terlihat:

Pertanyaannya adalah, mulai dari kapan uji coba dari sisi klien dapat dilakukan. Pengembang harus menguji pekerjaan lokal mereka setelah dimasukkan ke dalam sistem tahap. Terdengar sepele, tetapi setiap orang yang bekerja sama dengan pengembang akan langsung mengerti maksud saya. Setelah itu, orang yang bertanggung jawab untuk penjaminan kualitas dari agensi harus menguji tiket atau fitur tersebut. Barulah tiket tersebut diizinkan untuk diuji oleh klien. Klien seharusnya tidak merasa sebagai Alpha-Tester, melainkan menemukan sistem yang telah diuji oleh empat mata. Agensi adalah Alpha-Tester, sementara klien adalah Beta-Tester! Apakah ada akses ke sistem tiket agensi?

Juga, harus ditetapkan secara tertulis bahwa laporan dari pihak agensi kepada klien harus dilakukan dengan frekuensi tertentu. Misalnya, setiap Jumat akan ada laporan melalui surel tentang status pekerjaan saat ini, sirkuit umpan balik yang dibutuhkan, atau permintaan tambahan. Ini juga merupakan saran dari pengalaman agensi kami: Lebih baik memberi informasi kepada klien mengenai apa yang telah terjadi dan apa yang akan dilakukan di minggu berikutnya. Transparansi membantu agar semua pihak tetap bersemangat dalam proyek.

Tanggal peluncuran juga harus ditetapkan. Menurut Hukum Parkinson, pekerjaan akan meluas sesuai dengan waktu yang tersedia untuk menyelesaikannya. Dengan kata lain, semakin banyak waktu yang tersedia untuk menyelesaikan tugas, semakin banyak waktu yang akan digunakan, terlepas dari kompleksitas atau kerumitan sebenarnya. Kedatangan yang direncanakan juga harus dimasukkan dalam kontrak kerja. Melewatkan tanggal ini bahkan bisa dihukum dengan denda kontrak. Sebagai pedoman, denda kontrak sebesar 0,2% dari jumlah kontrak per hari kerja yang terlambat dan maksimal 5% dari jumlah kontrak dapat efektif. Denda kontrak tersebut tidak harus digunakan oleh klien, tetapi memberikan fleksibilitas kepada agensi untuk meminta kompensasi tambahan.

Penting: Jangan meluncurkan pada hari Jumat. Juga tidak antara liburan atau di jam sibuk perusahaan. Kami benar-benar merekomendasikan meluncurkan pada jam-jam malam dari hari Minggu ke Senin, terutama jika alamat IP berubah, sehingga pengaturan DNS di sebagian besar penyedia masih diperbarui kembali pada hari Senin, yang sering kali sudah terjadi pada larut pagi, jika entri DNS diubah selama jam-jam malam. Sehingga masih ada 4,5 hari kerja efektif untuk pengujian langsung dan perbaikan bug yang terjadi.

Pencatatan Status Saat Ini dari Situs Web Anda

Keadaan saat ini harus dicatat sebelum memulai pekerjaan. Dalam kondisi saat ini, dicatat bagaimana hasil pengukuran teknis untuk parameter tersebut. Di samping kanan, Anda dapat memasukkan nilai target:

Di dalam daftar ini, Anda akan menemukan Seobility sebagai alat SEO yang kami gunakan dengan senang hati untuk memeriksa faktor-faktor OnPage, di mana saya juga telah mempublikasikan Training SEO. Ada banyak alat sejenis yang tersedia seperti Sistrix, Semrush, Ryte, SE Ranking, Screamingfrog dll. Pada alat SEO ini, yang terutama penting adalah mengidentifikasi dan memperbaiki kesalahan umum OnPage. Di sini, ada tiga area inti yaitu Teknik & Meta, Struktur dan Konten, seperti yang dianalisis oleh Seobility. Dalam bentuk yang sama, Anda akan menemukan hal ini juga pada alat SEO lainnya. Pentingnya adalah satu sisi, bahwa selalu dilakukan pemeriksaan penuh, artinya SEMUA halaman di-crawl dan bukan hanya halaman beranda, dan di sisi lain, bahwa Anda memasukkan nilai atau skor kesalahan untuk kondisi saat ini dan nilai target yang seharusnya tercapai setelah optimisasi. Di Seobility, nilai 90 atau lebih tinggi diinginkan. Anda juga akan menemukan alat alternatif untuk tujuan lainnya. Yang penting adalah penggunaan minimal satu alat, untuk memastikan tersedianya data yang luar biasa.

Ini adalah contoh nilai kami saat ini untuk kualitas OnPage:

Sign-in pengguna dapat diukur secara statistik dengan Google Analytics 4, seperti Bouncerate, Halaman/Pengunjung, Durasi kunjungan, dll. Asalkan Google Analytics atau alat analisis lainnya digunakan dengan benar, data tersebut harus dipertimbangkan dalam pencatatan kondisi saat ini. 

Juga harus dibuat daftar backlink, yang dapat dibuat secara gratis di sini: https://www.seobility.net/de/backlinkcheck/

Juga, simpan file sitemap.xml lama, serta Full-Backup dari situs. Semua halaman relevan juga harus dipindahkan ke dalam daftar Google Sheet, yang akan menjadi dasar untuk Peta-Redirect-URL. Daftar CSV semacam itu dapat dengan mudah diekspor melalui alat SEO seperti Seobility. Dalam Peta-Redirect-URL, semua halaman relevan serta halaman yang terhubung melalui backlink eksternal (lihat daftar backlink) diperhitungkan, yang kemudian perlu dialihkan karena URL halaman berubah. URL yang dihapus harus dialihkan ke URL baru yang sesuai dengan yang lama. Penting untuk mencegah rantai pengalihan! Pengalihan lama yang masih ada harus dialihkan langsung ke URL tujuan baru. Juga, harus dipertimbangkan untuk file PDF dan gambar di mana terdapat tautan, sehingga ini juga dialihkan dengan benar dan tidak menjadi tautan 404.

Pengalihan dilakukan sebagai 301-Redirects berdasarkan Peta-Redirect-URL di dalam .htaccess, melalui Peta-Redirect melalui konfigurasi Vhost, atau solusi pangkalan data. Pelanggan seharusnya dapat merawat sendiri. Juga pastikan pengalihan bersifat permanen.

Juga disarankan untuk melakukan tangkapan layar Fullpage untuk setiap jenis halaman. Ini adalah cadangan dari konten lama, jika setelah Going-Live masih ada pertanyaan apakah jenis konten tidak dipindahkan dll.

Berdasarkan pada halaman yang ada, fitur, dan konten serta berdasarkan pada hasil pengukuran, dapat diidentifikasi apa yang sudah berjalan dengan baik dan apa yang diidentifikasi sebagai area yang memiliki potensi untuk dioptimalkan, yang ingin diperbaiki melalui relaunch.

Daftar Periksa: Sebelum Relaunch

Segera setelah Desain antarmuka pengguna dikonfirmasi dan agensi sedang dalam proses sprint pengembangan, daftar periksa berikut relevan, yang secara kronologis mencantumkan poin-poin penting hingga hari penggantian:

1. Lingkungan Dev dengan akses untuk semua pihak terlibat tersedia untuk pengujian
2. Lingkungan Dev berjalan di noindex
3. Aksesibilitas untuk alat pengujian di Lingkungan Dev (Izin IP atau Login http) telah diatur
4. Konfigurasi Lingkungan Dev sesuai dengan mungkin sesuai dengan Sistem Live
5. Struktur Halaman Lingkungan Dev sesuai dengan halaman Live yang akan datang
6. Migrasi data Lama sudah dilakukan
7. Penyesuaian konten telah dilakukan
8. SEO gambar telah dilakukan
9. 301-Redirects berdasarkan Peta-Redirect-URL sudah diatur 
10. Periksa OnPage dengan Seobility sudah dilakukan, kesalahan sudah diperbaiki, nilai target sudah tercapai
11. Data Open-Graph valid
12. Data terstruktur valid
13. Periksa Pagespeed untuk semua jenis halaman sudah dilakukan, nilai target sudah tercapai
14. Kebijakan Cookie konten berfungsi
15. Header Keamanan sudah diatur
16. Aksesibilitas sudah diberikan, nilai target sudah tercapai
17. Hreflang valid (untuk halaman multibahasa)
18. Teks hukum (Syarat dan Ketentuan, Imprint, Pernyataan Pembatalan, Kebijakan Privasi) sudah diperbarui, Kepatuhan GDPR terpenuhi
19. Update CMS, Frameworks, plugin yang digunakan pada versi terbaru sudah dilakukan
20. Pengujian Fungsi akhir melintasi browser dan perangkat tanpa kesalahan
21. Status Final dan tanggal peluncuran sudah diumumkan 
22. Full-Backup sudah dibuat

Penggunaan Data Terstruktur (Schema-Markup) - lihat Poin 12 pada daftar - masih sering diabaikan. Pelajari dan baca tentang topik ini dan apa yang disampaikan Google tentang markup untuk data terstruktur dalam Pencarian Google. Google semakin memberikan penekanan yang lebih berat pada data yang valid dalam kerangka SGE, yaitu hasil pencarian yang dibuat oleh kecerdasan buatan. Juga, Update Konten Bermanfaat dari Google mengharuskan konten jauh lebih diverifikasi melalui keahlian, pengalaman, otoritas, dan kepercayaan. Data terstruktur adalah bagian dari solusi untuk menyederhanakan validasi ini untuk Google. Gunakan Validator Markup Skema setelah mengintegrasikan data terstruktur, tetapi periksa juga halaman Anda dengan Linter Data Terstruktur, yang direkomendasikan dan di-link oleh Google dalam PageSpeed Insights. Di sana Anda akan mendapatkan informasi yang lebih komprehensif tentang kesalahan kode yang terkait dengan penggunaan data terstruktur Anda.

Pada Poin 16, pertama kalinya Aksesibilitas muncul dalam artikel ini. Sudah ada area Aksesibilitas pada PageSpeed Insights dan angka hijau di sana diharapkan. Pengujian apakah suatu halaman dapat diakses atau tidak harus dilakukan selain dari PageSpeed Insights, juga melalui https://www.accessibilitychecker.org dan/atau https://wave.webaim.org. Terutama saat berhadapan dengan relaunch, poin ini harus diperhitungkan karena mulai dari tahun 2025 topik ini akan menjadi penting untuk situs web sesuai dengan undang-undang pelindungan aksesibilitas. Periksa dengan menggunakan alat tersebut tidak hanya berlaku untuk halaman utama, tetapi juga setiap jenis halaman – hal yang sama berlaku untuk pengujian PageSpeed!

Dalam rangka relaunch, seringkali terjadi penyesuaian dan penyegaran pada teks hukum. Ini harus dipertimbangkan sejak dini bahwa teks mungkin disediakan melalui pengacara ahli atau generator hukum. Begitu juga dengan perjanjian pemrosesan pesanan harus dipertimbangkan, jika misalnya digunakan penyedia webhost baru atau terjadi perubahan layanan newsletter.

Poin 18 dengan pembaruan CMS, pustaka JavaScript yang digunakan, modul dan plugin yang diinstal sama pentingnya namun sering diabaikan. Relaunch bisa berlangsung selama beberapa bulan bahkan lebih lama. Dalam sistem WordPress, mudah untuk melihat mungkin sebelum tanggal relaunch sudah tersedia banyak pembaruan. Sebagai langkah pencegahan, pelanggan harus memastikan bahwa versi terbaru digunakan saat live.

Ketika ada perubahan pada layanan eksternal, tugas tambahan muncul yang seharusnya diidentifikasi dalam checklist, seperti saat ada perubahan layanan newsletter: 

• Data impor kontak newsletter ke layanan NL baru
• Penghubungan dengan layanan Newsletter di situs web pada formulir pendaftaran
• Perjanjian AV
• Pembuatan template Mailing baru
• dan seterusnya

Sepanjang sprint pengembangan, tentu saja terus-menerus dilakukan uji fungsi dan lainnya. Membuat checklist yang sangat rinci untuk pengujian sangatlah penting agar tidak ada yang terlupakan. Tidak cukup hanya dengan melakukan klik-klik di situs web, baik sebagai agensi pelaksana maupun pelanggan. Setelah relaunch dari TutKit.com, checklist penerimaan kami tentunya mencapai 1.000 baris. Dan ini masih berlaku hingga saat ini: setelah pembaruan besar penting, kami memeriksa sekitar 70 interaksi melalui checklist untuk Chrome, Safari, dan Android.

Checklist: Hari Relaunch dan Hari-hari Berikutnya

Hari Relaunch telah tiba dan bukan pada hari Jumat atau pada hari antara libur. Situs web baru diluncurkan, pengaturan DNS telah disesuaikan. Saat ini, penting untuk memeriksa dan mengevaluasi kembali semuanya dari awal. Periksa hal berikut: 

1. Periksa robots.txt agar robots tidak di-blokir
2. Lingkungan live berjalan pada index, follow
3. Tag Canonical telah diatur dengan benar
4. Periksa teks sumber halaman untuk rute absolut (rute link dari lingkungan pengujian ke situs langsung)
5. Redireksi dari http ke https dengan/ tanpa www ke halaman utama dan halaman bawahnya berfungsi
6. Uji redireksi melalui Peta Redirect URL, juga keberadaan rantai redireksi
7. Periksa OnPage dari Halaman Live dengan Seobility untuk Teknologi & Meta, Struktur dan Konten ... terutama periksa halaman Noindex yang dikeluarkan melalui Seobility
8. Data Open Graph valid
9. Data Terstruktur valid
10. Periksa Pagespeed untuk semua jenis halaman, nilai target tercapai
11. Kebijakan Cookie dengan Alat Konsentrasi Cookie berfungsi seperti seharusnya
12. Header Keamanan telah diatur
13. Aksesibilitas telah terpenuhi
14. Periksa Hreflang pada situs web multibahasa
15. Uji fungsi lintas browser dan perangkat terakhir tidak menunjukkan kesalahan
16. Kirim sitemap.xml baru ke Google Search Console
17. Perbarui halaman destinasi pada kampanye Google Ads
18. Ketika ada perubahan domain tertentu, pertimbangkan tautan di media sosial, tanda tangan email, dll.

Kami menggunakan Mailhog dalam lingkungan Dev kami untuk menguji email secara lokal. Dalam kasus seperti itu, penting untuk memastikan data SMTP yang benar untuk Penerimaan Email di Sistem Langsung terdeteksi, agar email dikirim ke tujuan sebagaimana mestinya.

Harus diperhatikan pula bahwa saat ada Penyedia Pembayaran seperti Paypal di sistem Dev, Sandbox diimplementasikan, sedangkan kemudian, tentu saja, koneksi yang benar harus dibuat di sistem langsung.

Dalam beberapa hari berikutnya, perhatian khusus perlu diberikan terhadap Google Search Console. Yang paling menarik tentu saja adalah bagaimana peringkat Anda berubah. Fokuskan perhatian khusus pada perubahan tak terduga dan pesan kesalahan:

1. Crawling: Status Host ... Menarik robots.txt, Resolusi DNS, Koneksi Server
2. Statistik Crawling ... Permintaan, Ukuran Download, Waktu Respon Rata-rata
3. Klik di SERP
4. Tampilan di SERP
5. CTR Rata-rata di SERP
6. Posisi rata-rata di SERP
7. Keberhasilan Core Web Vitals 

Terutama Google Search Console akan memberi tahu Anda tentang kesalahan seperti Kesalahan URL, Kesalahan Href-Lang, Indeksasi halaman yang disebarkan diindeks/niet indekst. Untuk tidak diindeks harus ada alasan (Pengalihan, noindex) .... Di sana Anda juga dapat melihat Konten ganda atau masalah lainnya. Jika Search Console melaporkan masalah dengan data terstruktur atau Core Web Vitals, periksanya. Hanya melalui data langsung Anda akan mengetahui, misalnya, bahwa halaman Anda meskipun memiliki PageSpeed tinggi, memiliki masalah dengan Core Web Vitals karena misalnya kesalahan CLS. Di sini Anda bisa melihat dengan baik lonjakan apa yang mungkin terjadi saat melakukan perubahan situs web:

Anda dapat langsung melihat URL yang buruk atau perlu dioptimalkan. Ambil satu URL dan lakukan uji PageSpeed dengannya di PageSpeed Insights. Di sana Anda akan mendapatkan petunjuk tentang mengapa Core Web Vitals tidak terpenuhi dan apa yang dapat Anda lakukan untuk memperbaiki kesalahan tersebut. Buka panah kecil ke bawah untuk informasi lebih lanjut. Biasanya rekomendasi ini hanya bisa diimplementasikan oleh pengembang. Namun penting bagi Anda untuk dapat mengidentifikasi masalahnya untuk kemudian menanganinya bersama agensi Anda.

Analisislah data Anda dari alat analisis Anda, seperti Google Analytics 4. Juga perhatikan metrik yang dapat Anda tangkap dari sisi sistem Anda, misalnya, Pemesanan, Konversi, Nilai Keranjang Belanja, Pembelian/Penjualan per Hari, Jumlah Pendaftaran Newsletter, Permintaan Kontak, Unduhan Konten Tertentu atau Tontonan Video.

Statistik Crawling di Google Search Console sangat penting untuk pemeriksaan dalam beberapa hari berikutnya. Anda dapat menemukannya melalui pengaturan di sebelah kiri menu. Seharusnya aktivitas Crawl lebih terlihat langsung. Jika tidak, apakah ada Kesalahan Crawl?

Status Host memberikan kesalahan langsung, seperti yang terlihat di sini setelah relaunch, ketika permintaan Crawling terdapat robots.txt yang gagal dan juga koneksi server kadang-kadang terputus:

Juga menarik apa yang disampaikan oleh Statistik Crawling. Biasanya setelah relanch, terjadi peningkatan dalam permintaan Crawling. Di sana Anda juga dapat melihat apakah masih ada halaman 404 yang di-crawl. Jika beberapa di antaranya tidak sesuai, bicarakan dengan para pengembang.

Anda akan melihat apakah server Anda, PageSpeed Anda, dan kode Anda relatif bagus jika waktu respons halaman Anda kurang dari 400. Semakin dekat dengan 1000 ms, semakin disarankan untuk mengoptimalkan PageSpeed, misalnya dengan mengurangi permintaan database dan meningkatkan daya server (misalnya, lebih banyak daya komputasi, pembaruan perangkat lunak server terbaru, beralih ke HTTP2 atau HTTP3 (pada Nginx)).

Secara perspektif, anggaran Crawl untuk situs web individu karena semakin banyak konten (AI) di situs web kemungkinan lebih terbatas, oleh karena itu di sini perlu dicapai waktu respons halaman yang bagus, sehingga bot dapat melakukan pengindeksan sebanyak mungkin pada halaman Anda dalam waktu yang tersedia.

Ceklis Relaunch untuk Diunduh

Klik pada Checklists untuk Relaunch tersemat juga sebagai file PDF untuk diunduh. Unduh dan pastikan kesuksesan proyek Anda dengan itu!

Pengakuan Seorang Pemilik Agensi

Persyaratan SEO dalam daftar periksa juga bisa mendapatkan instruksi rinci seperti Memperhatikan struktur Judul dari H1 sampai H6, dan sebagainya. Penetapan nilai target dalam peralatan uji menghemat daftar periksa Relaunch secara keseluruhan secara substansial, karena mencapai nilai teratas dari alat uji yang disebutkan dalam daftar periksa hanya bisa dicapai dengan mematuhi Kode yang bersih, Penggunaan teknologi modern, Memperhatikan Faktor SEO On-Page, dll. Kurang lebih akan membahayakan standar web terbaru dan persyaratan teknis dan SEO secara sangat rinci dalam daftar kebutuhan, yang secara profesional tidak bisa dipahami oleh klien. Jika agensi harus mencapai nilai tinggi dalam uji alat, mereka tidak punya pilihan lain selain bekerja sesuai dengan standar praktik - juga pengalaman baru bagi agensi :-)

Sudah saatnya untuk melakukan pengakuan. Definisi persyaratan SEO serta pendekatan daftar periksa dengan pengamanan dan pencapaian nilai target yang berlaku di berbagai alat uji merupakan suatu keidealan yang jarang sekali ditemukan di dalam kenyataan. Hal itu tergantung pada:

• batas anggaran dari pihak klien
• kepentingan optimasi laba dari pihak agensi
• batasan yang disebabkan oleh teknologi yang digunakan
• dan sayangnya juga: ketidaktahuan dan ketidakmampuan di kedua belah pihak

Saya tidak bisa menyalahkan klien. Mereka sedang mencari bantuan profesional dan hampir setiap agen digital menulis di situs web dan dalam white paper mereka bahwa optimisasi mesin pencari adalah salah satu keahlian inti mereka. Selalu ada referensi yang membuktikan bahwa setelah diluncurkan kembali, keterlihatan online meningkat sebesar faktor 3, 5, atau 10. Namun, jika dari 10 pengunjung sekarang ada 100 pengunjung setiap hari, meskipun itu adalah peningkatan 1000 persen, itu belum tentu kesuksesan. Banyak kesuksesan pada mesin pencari bergantung pada fakta bahwa pesaing mereka secara digital masih jauh lebih lemah.

Agen terus melakukan pekerjaan yang biasa saja dengan metode-metode ketinggalan zaman, karena mereka belum menggunakan alat-alat modern untuk jaminan kualitas, meskipun secara bertele-tele dalam posting, referensi, praktik terbaik, dll. mereka mengklaim memiliki keahlian SEO. Mereka mungkin agen dengan pengetahuan yang luas, tapi dalam pelaksanaan, mereka terbilang lemah. Itu terdengar keras, tapi itu adalah kenyataan. Sungguh. Silakan periksa lebih lanjut! Gunakan daftar periksa di atas dan masukkan agen terbaik dari wilayah tempat Anda tinggal, beserta URL mereka, ke alat-alat yang telah disebutkan di atas. Dan kemudian gunakan referensi situs web terbaru yang Anda temukan dari agen, dan ulangi prosesnya. Apa hasil yang akan Anda lihat? Persis seperti yang Anda harapkan dalam kerjasama. Anda bahkan bisa memeriksa referensi kami sendiri dan akan melihat bahwa bahkan pada proyek klien kami, kami belum tentu mencapai nilai tertinggi di semua aspek. Pendekatan dengan sikap menjunjung tinggi Jaminan Kualitas berbasis data hanya berkembang di projek-projek kami dari waktu ke waktu dan telah diakui melalui karya kami di TutKit.com. 

Anda bisa melakukan pengecekan semacam itu dengan hampir setiap agen, karena hanya sedikit yang benar-benar memprioritaskan kualitas dalam pengamanan data, karena tak ada satu pun yang bertahan di pasar dengan proyek-proyek sendiri selama bertahun-tahun dan harus berkompetisi dengan pemain-pemain internasional dalam persaingan ketat akan keterlihatan online, sehingga agen-agen mungkin acuh apakah sebuah proyek berhasil atau tidak, selama tagihan agen terendap dan klien bisa merayakan situs web yang indah (meskipun hanya berkualitas biasa) di postingan mereka dan dengan penghargaan yang mereka terima. Ironinya, menurut alat uji yang disebutkan di atas, biasanya agen SEO-pun dengan situs web mereka sendiri mendapatkan peringkat terendah, karena seringkali sepertinya mereka hanya mengandalkan satu metode saja ... paket konten yang dikembangkan berdasarkan kata kunci klien untuk situs web. Untuk kebutuhan teknis lainnya, seringkali kekurangan pengembang yang berkompeten.

Salah satu keuntungan adalah jika agensinya berada di tempat lain sehingga Anda tidak akan bertemu dengan klien ketika sedang berbelanja di toko peralatan rumah tangga sebagai karyawan agensinya, yang justru menjadi dalang penurunan keterlihatan dalam persentase dua digit setelah diluncurkan kembali. Namun, klien jarang memeriksa penurunan keterlihatan ini, meskipun semua orang memiliki banner persetujuan cookie, sedikit yang benar-benar menganalisis angka-angka tersebut dan mengambil tindakan dari situ. Pada akhirnya, perlu menaikkan biaya iklan AdSpend. Masyarakat tidak menyadari bahwa peringkat organik saat ini sangat dipengaruhi oleh berbagai parameter teknis, sinyal pengguna, dan (masih) backlink, karena kecerdasan buatan dan akan memperbarui konten situs web dalam jumlah dan kualitas yang belum pernah terjadi sebelumnya, dan kita akan segera menyambut banyak situs web baru yang diterjemahkan ke dalam bahasa kita di hasil pencarian, karena dengan alat terjemahan AI, semakin mudah menerjemahkan toko online, portal, SAAS, dan situs web lainnya dan mengejar pasar digital di negara kita. Kita harus bersiap untuk persaingan sengit. Ini baru awalnya...

Kesimpulan tentang daftar periksa pembaruan situs web berbasis data

Daftar periksa berbasis data seperti ini adalah salah satu cara efektif untuk memaksa agensi untuk bekerja dengan baik secara mengikat. Bahkan disarankan untuk membuat capaian tertentu dalam alat uji menjadi kriteria penerimaan. Harus diatur dalam kontrak bahwa sebagian pembayaran hanya boleh dicairkan setelah empat minggu dari peluncuran kembali, jika semua data penting sudah tersedia dan keberhasilan nilai teratas telah dikonfirmasi (seperti Core Web Vitals dan snippet produk yang divalidasi berdasarkan markup skema di Console Pencarian). Dengan bantuan alur kerja ini - seperti yang dijelaskan dalam artikel ini - kerugian keterlihatan Anda setelah peluncuran kembali dengan perubahan konten, struktural, dan teknis yang kuat akan tetap terbatas dan Anda akan membangun dasar agar Google segera meningkatkan peringkat situs web atau toko online Anda.

Jika artikel ini menarik bagi Anda, silakan periksa konten kami yang lain: