Pengembangan Web untuk SEO: Satu Lagi Hampir Goes South

Terakhir Diperbarui pada 14 September 2018

Inilah sebabnya mengapa Anda memiliki perusahaan SEO, seperti Itu! Perusahaan, untuk menangkap dan memperbaiki apa yang salah dengan desain ulang situs web yang ada. Seperti yang diketahui oleh siapa pun yang bekerja di industri pemasaran internet dan telah melalui pembangunan kembali situs web yang berfungsi, banyak sekali hal yang bisa salah. Baru-baru ini, klien PPC (bayar per klik) dan SEO (optimasi mesin pencari) baru saja selesai membangun kembali situs web mereka dan diluncurkan tanpa mengizinkan peninjauan. Pembuatan ulang terbaru dari situs klien ini sangat salah saat diluncurkan, jadi saya akan menyentuh beberapa hal yang diharapkan dan tidak terduga yang dapat, dan mungkin terjadi.

Kebutuhan

Klien ini membeli bisnis yang sudah ada yang memiliki situs web e-niaga dan informasi yang sudah ada dan merupakan pemimpin dalam industri mereka. Pengembang web tidak datang dengan pembelian. Untuk beberapa alasan yang tidak pernah diungkapkan kepada saya, klien tidak dapat memperbarui halaman apa pun di luar keranjang belanja. Keranjang belanja tidak ramah seluler dan kami dapat melihat perbedaan konversinya dari desktop versus seluler. Konversi seluler hampir tidak ada. Sebagian besar penjualan online mereka dihasilkan oleh pencarian organik desktop, PPC, kunjungan langsung dan rujukan.

Banyak elemen yang dibutuhkan untuk meningkatkan SEO mereka, juga tidak ada. Tidak ada kemampuan untuk mengubah meta data, tag h1, tag alt/title, dll. Sebagian besar data ini dihasilkan secara terprogram; serta menu dan struktur navigasi. Situs baru ini juga harus aman. Singkatnya, yang mereka butuhkan adalah situs web baru yang ramah seluler, aman, dan keranjang belanja dengan konektor untuk bekerja dengan rangkaian perangkat lunak perencanaan sumber daya perusahaan (ERP) yang ada.

Misi

Klien ini memiliki 3.766 kata kunci dengan hasil peringkat di seratus teratas SERP Google. Lima ratus tiga puluh delapan (538) kata kunci dengan hasil halaman 1, membawa volume pencarian bulanan rata-rata 65.790 dan peringkat 43 kata kunci di posisi satu di SERP Google yang memiliki volume pencarian bulanan rata-rata 6.110. Tugas saya adalah membimbing mereka melalui persyaratan yang dibutuhkan oleh sistem administrasi baru untuk menyediakan kemampuan untuk menerapkan SEO ke depan. Ini juga termasuk melindungi hasil peringkat mereka yang ada sebaik mungkin.

Seleksi

Klien akhirnya memilih vendor luar negeri yang dapat menyediakan integrasi antara perangkat lunak ERP mereka yang ada dan solusi keranjang belanja dan situs web baru yang ramah seluler dan aman. Karena tidak terbiasa dengan vendor luar negeri ini, klien memberi saya rekaman demo produk untuk mengonfirmasi bahwa sistem administrasi akan menyediakan apa yang kami butuhkan untuk menerapkan SEO. Setelah meninjau demo, saya menyimpulkan bahwa kami memiliki elemen yang diperlukan untuk membantu klien dengan peningkatan SEO. Kami dapat membuat judul halaman, deskripsi meta, dan tag h1 kami sendiri. Kami dapat memperbarui kode Google Analytics (GA), di mana kode tersebut menjalankan kode GA lama, usang, dan tidak memiliki akun Search Console. Kami memiliki akses ke gambar untuk menambahkan teks alt/judul yang diformat dengan benar. Seperti yang kami ketahui kemudian, dan sangat terlambat, bahkan ada kemampuan untuk menerapkan pengalihan 301 tepat di setiap halaman. Tapi itu hanya sebagian dari cerita.

Hasil

Ternyata, pengembang menyediakan template, keranjang belanja, dan integrasi ERP. Klien ditugaskan untuk memindahkan konten (menyalin konten situs lama dan menempelkannya ke halaman baru di sistem administrasi), termasuk meta data yang ada. Mereka juga ditugaskan untuk memasukkan URL situs lama ke dalam data halaman baru, halaman demi halaman. Ternyata ini diperumit oleh fakta bahwa klien tidak dapat menyalin dan menempelkan URL situs lama secara utuh. Klien menganggap ini sebagai prosedur operasi standar dan tidak memberi tahu siapa pun tentang hal ini. Kami awalnya merekomendasikan agar pengembang membuat file pengalihan 301 yang tepat. Garis waktu peluncuran tidak mengizinkan klien untuk mengizinkan kami meninjau operasi yang benar. Mereka baru saja meluncurkannya dan di situlah semuanya salah.

Setelah pemberitahuan bahwa situs yang dibangun kembali telah diluncurkan, kami mulai menguji secara manual hasil peringkat kata kunci asli terhadap hasil peringkat saat ini. Hanya untuk melihat seperti apa situs baru itu dan semua data telah ditransfer. Semua hasil peringkat di SERP Google yang masih ada menghasilkan kode respons 404 kecuali halaman beranda. Ternyata, URL situs lama dibuat dengan ekstensi .html dan URL baru tidak. Sistem administrasi sama sekali tidak mengizinkan URL lama untuk ditempelkan ke bidang pengalihan 301 yang disediakan, jadi klien menempelkan URL lama tanpa ekstensi .html. Klien menganggap ini adalah prosedur operasi standar.

Setelah banyak diskusi internal, kami menemukan bahwa jika Anda menghapus ekstensi .html, halaman akan dialihkan dengan benar ke versi aman dari URL baru, dalam banyak kasus. Namun, dalam beberapa kasus, URL lama, tanpa ekstensi .html, akan dialihkan ke URL baru yang sangat tidak ramah mesin telusur yang berisi string kueri yang belum pernah kita lihat sebelumnya. Dalam pemeriksaan lebih lanjut, kami menemukan bahwa URL baru yang tidak dikenal ini dihasilkan oleh navigasi di menu utama. Jadi kami memiliki pengalihan satu ke satu, dalam banyak kasus, dari URL lama, ekstensi .html dihapus, ke URL ramah mesin telusur baru yang aman dan kami dapat menavigasi ke konten yang sama dari navigasi utama yang menghasilkan non -URL ramah.

Konten duplikat? Nah, apakah tag rel= canonical ditempatkan, Anda mungkin bertanya? Benar? Tidak. Tag rel=canonical pada URL yang ramah mesin telusur dan dialihkan ditetapkan untuk menunjuk ke URL baru yang tidak ramah mesin telusur yang berisi string kueri. Saat memeriksa tag rel=canonical halaman yang tidak ramah, kami menemukan bahwa tag ini merujuk ke URL yang sama sekali berbeda. Satu berisi kategori dan bukan string kueri. Jadi, satu konten ditampilkan untuk tiga URL berbeda, dengan tag rel=canonical yang tidak disetel dengan benar.

Selanjutnya, kami menemukan bahwa semua bot telah dilarang di file robots.txt. Kemudian kami memeriksa aktivitas di GA. Klien masih menerima kunjungan dari semua sumber, tetapi mencatat nol konversi. Selain itu, klien ingin kami mendorong perayapan dan pengindeksan yang membutuhkan Google Search Console. Masalahnya di sini adalah kode GA yang ada sudah lama dan tidak pernah ada kode verifikasi Search Console yang ditempatkan di situs. Ini adalah salah satu item yang tidak dapat diubah oleh klien karena alasan yang tidak pernah diungkapkan.

Untungnya, klien telah mengambil rekomendasi kami untuk menerapkan pembaruan kode GA mereka ke versi terbaru. Mereka sendiri juga menambahkan pengelola tag Google. Ups! Mungkin penembakan ganda kode GA? Dengan Google Pengelola Tag dan kode GA asinkron yang diperbarui, kami dapat membuat akun Search Console baru yang aman (https vs. http) untuk klien, dan kemudian menemukan bahwa tidak ada peta situs .xml untuk dikirimkan untuk perayapan yang diminta .

Setelah pemberitahuan, klien berkomunikasi dengan pengembang dan diberi dua URL peta situs .xml. Satu berhasil. Satu tidak. Yang berfungsi memiliki satu entri yang menunjuk ke peta situs .xml yang tidak berfungsi. Peta situs .xml yang tidak berfungsi tidak memiliki pemformatan yang tepat saat dilihat di browser. Jadi kami tidak mengirimkan peta situs .xml yang disediakan pada saat itu.

Hasil akhir

Kami memberi tahu klien, melalui email bertahap, tentang apa yang kami temukan. Pertama, masalah pengalihan yang gagal dan kami menemukan bahwa jika kami menghapus ekstensi .html, mereka dialihkan dengan benar. Klien memberi tahu pengembang dan pengembang menjawab bahwa Anda tidak dapat menempatkan ekstensi .html di alat pengalihan 301 yang disediakan. Penemuan lebih lanjut mengungkapkan bahwa klien telah menemukan ini dan berpikir bahwa ini adalah prosedur operasi standar.

Untuk beberapa alasan, situs web asli telah dihapus (oopsy besar di sini, selalu memiliki versi kerja yang siap untuk digunakan kembali) sehingga kami tidak dapat menarik URL lama apa pun untuk membuat pengalihan 301 permanen baru melalui file .htaccess. Resolusinya adalah membuat pencocokan baru satu lawan satu, URL lama vs. URL baru, spreadsheet, menarik data laman landas dari GA selama setahun terakhir, agar pengembang dapat membuat pengalihan yang berfungsi dengan baik menggantikan pengalihan 301 di sistem administrasi yang ditugaskan pada klien.

Masalah diselesaikan dengan biaya tambahan untuk klien dari pengembang. Setiap hasil peringkat lama yang ada dengan ekstensi .html mulai dialihkan dengan benar dan dalam 14 hari, hasil peringkat telah diganti dengan URL aman baru dan, sebagian besar, sangat dekat dengan hasil peringkat yang sudah ada sebelumnya. Masalah tag rel=canonical telah diselesaikan dalam pertemuan online dengan agen penjualan pengembang web dan disebabkan oleh kesalahan input pengguna. Ada beberapa bidang di mana data dapat dimasukkan atau dipilih dari pilihan yang ada dan solusinya diperlukan untuk mengatur ulang bidang ini dan membersihkan cache.

Dua versi tambahan dari URL yang ramah dan aman segera hilang. Mengenai bot /disallow di robots.txt, setelah pemberitahuan, pengembang dengan cepat menyelesaikan masalah ini.

Ditemukan bahwa masalah dengan data konversi GA tampaknya terisolasi ke penyedia layanan pedagang klien; yang baru dan berbeda dari provider lama. Tidak ada yang berpikir untuk berkomunikasi dengan penyedia layanan pedagang bahwa kami memerlukan kode GA di halaman checkout mereka untuk memberikan data e-niaga yang diperlukan klien untuk membuat keputusan bisnis yang tepat tentang upaya pemasaran mereka. Kami tidak diberitahu tentang keberadaan penyedia layanan pedagang baru.

Terakhir, kami secara manual membuat file peta situs .xml yang ingin kami unggah ke server dan meminta pengembang menonaktifkan apa pun yang membuat peta situs .xml mereka yang tidak berfungsi. Dalam diskusi lebih lanjut dengan agen penjualan pengembang, kami diberitahu bahwa kami tidak dapat mengunggah peta situs .xml lainnya ke server.

Setelah menunjukkan hasilnya kepada agen penjualan pengembang, dia menyatakan bahwa dia akan memeriksanya, namun, dia menyarankan agar kami melihat kode sumbernya. Saat melihat dalam kode sumber, dokumen .xml telah diformat dengan benar. Setelah melihat hasil ini, kami memberi tahu Google, melalui Search Console, bahwa kami sebenarnya memiliki peta situs .xml yang berfungsi. Akhirnya, selama beberapa hari, Google akhirnya mencatat bahwa kami memiliki peta situs .xml yang berfungsi dan mulai menampilkan URL yang diindeks. Namun, seperti yang dinyatakan sebelumnya, peta situs .xml yang diformat dengan benar hanya memiliki satu entri yang menunjuk ke peta situs .xml tambahan yang tidak akan diselesaikan di browser, tetapi ditampilkan dengan benar di kode sumber.

Nah, masalah ini telah berubah menjadi masalah yang lebih besar karena peta situs .xml tambahan menghasilkan kode respons 500, jadi ada masalah dengan agen Google yang mengakses area situs ini. Dan, mulai hari ini, kedua peta situs .xml menghasilkan 500 kode respons. Seminggu sebelumnya, kami telah meminta perayapan menggunakan alat ambil, render, kirim yang tersedia bagi kami di Google Search Console yang kami yakini menyebabkan perayapan dan pengindeksan situs baru.

Jadi, sebagai penutup, jika itu bisa salah, itu akan terjadi, ketika membangun kembali situs web Anda dan semoga, Anda akan dapat menghindari beberapa kesalahan ini. Memblokir bot di file robots.txt dan mengarahkan ulang secara tidak benar dapat membuat Anda keluar dari bisnis online atau, setidaknya, dalam bahaya. Jika bot tidak dapat merayapi situs Anda, Anda pada akhirnya akan turun dari indeks dan ketika Anda turun dari indeks, kecuali jika bot tersebut berasal dari rujukan, langsung, atau sumber non-organik lainnya, sebagian besar kunjungan penelusuran organik akan menjadi tidak ada.

Jika hasilnya tidak dialihkan dengan benar, pengunjung Organik dapat melihat situs Anda sebagai tidak dapat dipercaya. Pelanggan lama yang menyimpan situs Anda sebagai bookmark, mungkin menjadi frustrasi saat bookmark mereka tidak dialihkan dengan benar. Belum lagi kami harus menutup kampanye PPC mereka untuk sementara. Mengklik iklan berbayar dan mendapatkan respons halaman 404 tidak ditemukan tidak hanya membuat pengunjung Anda frustrasi, tetapi juga mahal! Klik menghabiskan uang Anda dan Anda tidak mendapatkan laba atas investasi Anda. Dan, inilah mengapa Anda memiliki kami.

– Mark Gray, Manajer SEO Senior