SEO Teknis Perusahaan - Webinar Kekuatan Halaman Pertama

Hai semuanya, dan selamat datang di rekap webinar panel Page One Power tentang SEO Teknis Perusahaan .

Pertama, saya ingin mengucapkan terima kasih kepada panelis kami yang luar biasa karena telah berbagi waktu dan wawasan mereka dengan kami dan audiens kami! Panel ahli kami menampilkan:

• Tom Anthony, Kepala Penelitian & Pengembangan di Distilled
• Paul Shapiro, Direktur Strategi & Inovasi di Catalyst
• Patrick Stox, Spesialis SEO di IBM
• dan Nicholas Chimonas, Direktur Litbang di Page One Power.

Ini adalah webinar yang luar biasa dengan diskusi dan percakapan menarik seputar berbagai topik yang berkaitan dengan SEO teknis tingkat perusahaan.

Catatan: rekap ini akan memparafrasekan percakapan, bukan transkripsi langsung. Jika Anda tertarik untuk mendengar percakapan yang tepat, Anda dapat menonton video yang disematkan.

Ikhtisar

Percakapan berlangsung sekitar satu jam, di mana panel kami membahas sejumlah topik, tantangan, dan solusi.

Untuk membuat diskusi lebih mudah dicerna, saya telah menguraikan semuanya di sini. Video yang disematkan disertakan yang dimulai di awal setiap pertanyaan yang sesuai (dilambangkan dengan subjudul kuning).

Saya juga telah mengeluarkan kutipan atau ide yang sangat menarik melalui teks blok, untuk meningkatkan keterbacaan. Sekali lagi, ini bukan kutipan langsung.

Jika Anda lebih suka menonton rekaman video secara keseluruhan, ini dia:

Berikut adalah pertanyaan yang dibahas panel ahli kami:

1. Situs perusahaan memiliki ribuan bahkan jutaan halaman. Bagaimana Anda memprioritaskan dan mengelola masalah teknis pada skala ini?
2. Bekerja dengan klien perusahaan berarti siklus implementasi yang lebih lambat. Bagaimana Anda membuat rencana yang sesuai?
3. SEO sering menerima pengakuan minimal dalam struktur perusahaan. Bagaimana Anda memperjuangkan anggaran, nilai jual di hulu, dan mendapatkan prioritas?
4. SEO teknis membutuhkan kolaborasi di berbagai departemen. Bagaimana cara membangun kerjasama antar departemen?
5. Apa yang paling Anda sukai dari SEO teknis?
6. Bagaimana Anda menangani perubahan inventaris besar-besaran yang menyebabkan banyak 404 setiap hari?
7. Apakah disarankan untuk memiliki CSS dan Javascript besar untuk situs web di footer agar halaman dimuat lebih cepat?
8. Bagaimana Anda mengukur hasil perubahan secara akurat dan menunjukkan hasil tersebut kepada klien?

Pertanyaan-pertanyaan ini berfungsi sebagai titik awal untuk diskusi, membantu memandu percakapan daripada mengendalikannya.

Karena percakapan tidak ditulis dalam naskah, panelis kami dapat memasukkan anekdot pribadi, strategi unik, dan banyak informasi dan saran dunia nyata.

Semoga kamu menikmati!

Pertanyaan Pertama: Situs perusahaan memiliki ribuan bahkan jutaan halaman. Bagaimana Anda memprioritaskan dan mengelola masalah teknis pada skala ini?

Diskusi dimulai pukul 04.05.

Nicholas: Patrick, ayo berangkat bersamamu.

Prioritas berdasarkan Dampak

Patrick: Oke. Saya akan mengatakan memukul di mana Anda akan membuat dampak yang layak. Pada skala itu untuk halaman demi halaman, kecuali jika itu adalah salah satu halaman terpenting, itu tidak akan membuat banyak perbedaan. Tetapi terkadang Anda harus melakukan halaman demi halaman untuk mendapatkan beberapa kemenangan kecil dan membangun kepercayaan yang dibutuhkan untuk menangani proyek yang lebih besar.

Bagi kami, ini tentang menangani berbagai masalah dengan sistem CMS yang berbeda dan unit bisnis yang berbeda satu per satu sehingga kami dapat membangun studi kasus, dan menunjukkan dampaknya kepada orang lain. Itulah cara kita melakukannya.

Nicholas: Apakah Anda merasa lebih mudah mendapatkan persetujuan jika Anda telah membuktikan kasus Anda dengan subbagian yang lebih kecil dari situs Anda? Lalu Anda memiliki kekuatan untuk meyakinkan tim pengembangan untuk melakukannya dalam skala yang lebih besar?

Patrick: Ya tentu saja.

Nicholas: Paul, apa pendapatmu tentang ini? Kami juga memiliki pertanyaan dari audiens jika Anda ingin menjawabnya. Pertanyaannya adalah, "Bagaimana Anda mengoptimalkan anggaran perayapan untuk klien perusahaan?"

Paul: Biarkan saya menangani pertanyaan utama terlebih dahulu.

Saya pikir itu benar-benar turun untuk dapat menilai dampak dari setiap perubahan yang akan Anda buat.

Setelah Anda tahu berapa biayanya dan apa yang akan dibutuhkan, itu akan lebih mudah untuk diprioritaskan.

Itu berarti membangun model, memperkirakan dampak, menghitung biaya (orang, sumber daya, teknologi, dll.) untuk menerapkan perubahan, dan dari sana Anda harus dapat memprioritaskannya. Setelah Anda tahu berapa biayanya dan apa yang diperlukan untuk sampai ke sana, akan lebih mudah untuk memprioritaskannya.

Anggaran Perayapan

Dalam hal pertanyaan anggaran perayapan, Anda dapat melihat artikel yang saya tulis untuk Search Engine Land yang menjelaskan bagaimana Anda dapat menggunakan algoritme PageRank dan menghitungnya di seluruh situs web Anda secara internal, dan menggunakannya untuk memengaruhi anggaran perayapan Anda.

Nikolas: Tentu. Itu adalah pendekatan yang benar-benar sering diabaikan, mencoba mendapatkan beberapa data di balik mengapa menurut Anda perubahan dalam arsitektur ini akan membuat perubahan yang Anda harapkan.

Tom, apa pendapatmu tentang ini?

Mengikat ROI ke SEO Teknis

Tom: Pertama, saya setuju dengan Patrick dan Paul. Korelasi dari hal-hal yang mereka sentuh adalah mencoba memahami perbaikan apa yang akan memiliki ROI tertinggi.

Anda perlu mengidentifikasi area situs perusahaan mana yang benar-benar layak untuk dikerjakan, dan memahami seberapa cepat sesuatu dapat diimplementasikan.

Jadi, Anda tidak hanya perlu memiliki hipotesis tentang upaya yang diperlukan, tetapi Anda juga perlu berbicara tentang hasil dan umur panjang. Contoh kasus buruk adalah sesuatu yang akan memakan waktu lama bagi para pengembang, sehingga pada saat imbalannya datang, itu tidak lagi sepadan.

Anda perlu mengidentifikasi area situs perusahaan mana yang benar-benar layak untuk dikerjakan, dan memahami seberapa cepat sesuatu dapat diimplementasikan.

Dalam hal ODN Distilled, salah satu hal yang menarik dari sudut pandang kami adalah memiliki hipotesis dampak yang lebih baik.

Biasanya, situs perusahaan memiliki simpanan panjang perubahan SEO teknis yang memerlukan beberapa tingkat prioritas. Jadi kami mendorong orang untuk menggunakan ODN untuk pengujian guna membantu kami membuat hipotesis yang lebih baik tentang dampak perubahan tertentu. Sangat sulit untuk memprediksi ROI dari perubahan SEO teknis di situs perusahaan, tetapi ODN memungkinkan kami untuk menguji banyak hal yang berbeda.

Nicholas: Saya pikir itu benar terutama pada tingkat ini (perusahaan), perubahan sederhana mungkin memiliki dampak yang lebih besar dari yang Anda harapkan. Dan saya pikir SEO on-page lebih penting ketika bekerja di situs yang lebih besar.

Tomo: Tentu saja. Dan Mike King memiliki posting bagus tentang SEO teknis di Moz.

Nicholas: Ya, postingan Mike menunjukkan bahwa banyak alat SEO kami berada di balik permainan ini. Jadi, jika Anda hanya mengandalkan alat dan tidak memeriksa semuanya secara manual, Anda mungkin melewatkan masalah penting. Ini adalah posting yang menarik dan saya sarankan untuk memeriksanya.

Pertanyaan Kedua: Bekerja dengan klien perusahaan berarti siklus implementasi yang lebih lambat. Bagaimana Anda membuat rencana yang sesuai?

Pembahasan soal ini dimulai pada pukul 12:50.

Nicholas: Patrick, mari kembali ke Anda untuk yang satu ini.

Patrick: Ha, itu pertanyaan yang menyenangkan! Terkadang Anda menunggu, banyak perubahan yang saya tunggu, saya tidak berharap terjadi tahun ini atau bahkan tahun depan dalam beberapa kasus. Tapi selalu ada banyak hal lain yang harus dilakukan.

Tapi tidak selalu seperti itu. Jika Anda memiliki dukungan eksekutif dan dukungan tim, hal-hal dapat bergerak cukup cepat. Itu tidak selalu lambat.

Nicholas: Ya, saya telah mengalami kedua sisi mata uang. Saya pikir Anda benar sekali, dan itu tergantung di mana Anda memiliki dukungan (pada tingkat organisasi apa) yang dapat mendorongnya dan mewujudkannya lebih cepat.

Dan di sisi lain—di mana segala sesuatunya berjalan lambat dan tidak diimplementasikan—itu karena Anda belum mendapatkan kepercayaan atau dukungan dengan membuktikan diri. Setelah Anda membuktikan pentingnya rekomendasi Anda, sering kali ini menjadi siklus implementasi yang lebih cepat.

Jadi Paul, apa pendapat Anda tentang ini?

Menerapkan Perubahan Sendiri

Paul: Sering kali Anda tidak dapat melakukan apa-apa tentang waktu implementasi, itu akan menjadi proses yang lambat. Apa yang dapat Anda lakukan adalah mengimplementasikannya sendiri, jika memungkinkan. Jika Anda memiliki kesempatan untuk membuat perubahan sendiri, itu akan membantu mempercepat prosesnya. Hal kecil apa pun yang dapat Anda terapkan sendiri akan mempercepat prosesnya.

Jika Anda memiliki tim teknologi yang kuat, Anda dapat membangun kepercayaan dengan pengembang dan insinyur dengan mengakui bahwa perubahan pada akhirnya mungkin tidak substansial, dan menawarkan bantuan jika Anda bisa. Anda dapat menyelesaikan sesuatu lebih cepat hanya dengan mengetahui apa yang Anda lakukan.

Selain itu, pastikan Anda mengomunikasikan dengan jelas nilai perubahan ini dan berbicara dengan orang yang tepat. Jika Anda memiliki tim teknologi yang kuat, Anda dapat membangun kepercayaan dengan pengembang dan insinyur dengan mengakui bahwa perubahan pada akhirnya mungkin tidak substansial, dan menawarkan bantuan jika Anda bisa. Anda dapat menyelesaikan sesuatu lebih cepat hanya dengan mengetahui apa yang Anda lakukan.

Nicholas: Bersedia mengambil kendali dan mendukung para pengembang dan berempati terhadap bandwidth mereka membantu. Memang benar bahwa jika Anda membuat diri Anda tersedia, Anda bisa mendapatkan akses, dan sering kali mendapatkan akses untuk membuat perubahan sendiri lebih mudah daripada disimpan di backlog dan membuatnya sampai ke puncak.

Jadi Tom, bisakah kamu menimbang di sini.

Membangun Hubungan dengan Tim Pengembang

Tom: Saya benar-benar menggemakan apa yang dikatakan orang lain tentang berteman dengan para pengembang dan membuat mereka berada di pihak Anda.

Hanya dengan hadir, Anda akan menemukan bahwa Anda dapat menyelesaikan lebih banyak daripada saat Anda menerima email tanpa wajah yang masuk ke kotak masuk mereka.

Dari perspektif agensi, jika Anda memiliki klien, Anda harus pergi dan bekerja dari kantor mereka. Setelah Anda berada di kantor mereka, Anda dapat melihat dinamika dan memahami dengan siapa Anda perlu berbicara untuk menyelesaikan sesuatu. Dalam hal tim pengembang, lihat apakah Anda bisa ikut serta dalam rapat mereka.

Hanya dengan hadir, Anda akan menemukan bahwa Anda dapat menyelesaikan lebih banyak daripada saat Anda menerima email tanpa wajah yang masuk ke kotak masuk mereka. Kami memiliki konsultan yang datang dan duduk dalam rapat, dan tiba-tiba tiket SEO yang sebelumnya mendekam mulai menggelembung ke atas. Para konsultan bahkan tidak perlu mengatakan apa-apa—hanya menjadi orang sungguhan yang diinvestasikan dalam hasil tiket ini, membuat tiket itu melayang ke atas.

Kemudian cari tahu apa yang dapat Anda lakukan untuk membantu para pengembang. Seringkali ada tiket yang mereka rasa sulit karena alasan tertentu, yang tidak selalu dikomunikasikan kembali kepada Anda. Tetapi jika Anda benar-benar berbicara dengan mereka, Anda dapat mengetahui mengapa mereka berjuang dan menawarkan bantuan. Ini akan membuat Anda percaya dengan mereka karena mereka akan menghargai bahwa Anda telah berbicara dengan mereka dan mengenali tantangan mereka.

Anggaran Perayapan (lanjutan)

Analisis log jauh lebih mudah diakses daripada yang Anda pikirkan, dan Anda dapat menggunakannya untuk mengumpulkan banyak data yang dapat ditindaklanjuti. Itu adalah sesuatu yang telah jatuh di pinggir jalan, tetapi kayu gelondongan adalah tambang emas.

Dan kembali ke hal anggaran perayapan, pada analisis log skala perusahaan sangat membantu untuk anggaran perayapan. Analisis log jauh lebih mudah diakses daripada yang Anda pikirkan, dan Anda dapat menggunakannya untuk mengumpulkan banyak data yang dapat ditindaklanjuti. Itu adalah sesuatu yang telah jatuh di pinggir jalan, tetapi kayu gelondongan adalah tambang emas.

Nicholas: Dan tidak pernah semudah ini dengan alat seperti Screaming Frog Log Analyzer. Jika Anda belum pernah melakukannya sebelumnya, Anda harus mencobanya karena Anda akan kagum dengan apa yang dapat Anda pelajari.

Tom: Seringkali bagian tersulit pada skala perusahaan hanyalah meyakinkan seseorang untuk memberi Anda akses ke log. Tetapi sekali lagi, memasukkan diri Anda ke dalam tim yang tepat akan membantu.

Menggunakan ODN untuk Melewati Siklus Implementasi

Nicholas: Dan satu hal lagi. Dengan ODN Distilled, Anda dapat melewati siklus implementasi dan bertanggung jawab untuk membuat perubahan sendiri. ODN bertindak seperti CDN dan memungkinkan Anda untuk melewati sistem lama apa pun yang ada.

Tom: Ya, itu menyebar mirip dengan CDN dan dari sudut pandang pengguna mereka tidak melihatnya ada di sana. Dan itu bertindak hampir seperti CMS baru yang hanya duduk di atas segalanya.

Yang sangat menarik dari hal ini adalah kami mengharapkan banyak pushback dari tim pengembang karena mereka akan merasa kehilangan kendali. Namun yang mengejutkan adalah banyak tim pengembang menyambut baik perubahan ini karena mereka juga frustrasi dengan platform lama. Jadi kami (SEO) frustrasi karena tiket kami tidak selesai, dan mereka (pengembang) frustrasi karena tidak dapat menyelesaikannya. ODN menciptakan platform di mana SEO dapat membantu tim pengembang dan mencapai tujuan bersama untuk membuat situs web sesukses mungkin.

Nicholas: Benar, ini adalah kemenangan.

Catatan: Nicholas menggabungkan pertanyaan tiga dan empat karena pertanyaan tiga telah disinggung, dan diikat dengan baik dengan pertanyaan empat. Jawaban atas kedua pertanyaan tersebut di bawah ini.

Pertanyaan Tiga: SEO sering menerima pengakuan minimal dalam struktur perusahaan. Bagaimana Anda memperjuangkan anggaran, nilai jual di hulu, dan mendapatkan prioritas?

Pertanyaan Empat: SEO Teknis membutuhkan kolaborasi di berbagai departemen. Bagaimana cara membangun kerjasama antar departemen?

Diskusi seputar pertanyaan ini dimulai pada pukul 23:30.

Nicholas: Mari kita mulai dengan Patrick. Saya pikir ini adalah pertanyaan yang sangat menarik dalam konteks IBM.

Pelatihan & Kolaborasi di Tingkat Perusahaan

Patrick: Oke, kita punya dua pertanyaan sekaligus. Sejauh pengakuan dalam struktur perusahaan, kita sudah berbicara tentang tes, studi kasus, memprediksi ROI, dll Tapi saya pikir bagian besar yang hilang adalah pelatihan karyawan dan tim yang berbeda.

Memberikan kredit kepada tim sangat membantu. Jika sebuah tim telah melakukan pekerjaan yang hebat, maka beri mereka penghargaan untuk itu. Jika mereka telah melakukan banyak kerja keras dan membuat perbaikan yang Anda sarankan, itu adalah kemenangan mereka bersama dengan Anda.

Percaya atau tidak, tetapi dalam SEO perusahaan kami bekerja dengan SEO yang jauh lebih sedikit per ukuran situs, jadi pelatihan sangat penting. Dan bagian yang baik tentang pelatihan adalah membantu Anda menemukan orang yang mendapatkannya, yang akan menjadi penginjil Anda.

Memberikan kredit kepada tim sangat membantu. Jika sebuah tim telah melakukan pekerjaan yang hebat, maka beri mereka penghargaan untuk itu. Jika mereka telah melakukan banyak kerja keras dan membuat perbaikan yang Anda sarankan, itu adalah kemenangan mereka bersama dengan Anda.

Jika ada sesuatu yang menurut Anda akan berdampak, jangan menyerah. Anda hanya perlu menemukan seseorang yang akan mendengarkan dan menemukan cara untuk memastikannya tidak mati dalam simpanan.

Sejauh kolaborasi, bekerja dengan tim berulang kali akan membantu membangun hubungan. Bahkan terkadang Anda dapat membantu tim mendapatkan anggaran atau membayar dari anggaran Anda sendiri untuk membantu mereka mendapatkan sumber daya yang mereka butuhkan untuk melakukan sebuah proyek.

Jangan Menyerah pada Proyek

Patrick: Saya terus mendengar backlog, backlog, backlog...itu cukup sering terjadi. Internal atau instansi, tidak masalah tetap dorong. Jika ada sesuatu yang menurut Anda akan berdampak, jangan menyerah. Anda hanya perlu menemukan seseorang yang akan mendengarkan dan menemukan cara untuk memastikannya tidak mati dalam simpanan.

Nicholas: Ya, itu benar-benar membuatku gila ketika itu terjadi. Tapi saya lebih sering menemukan, jika saya terus mendorong saya bisa mewujudkannya. Sangat penting bahwa Anda tidak menyerah.

Patrick: Tom membuat poin bagus sebelumnya tentang orang-orang agensi yang masuk. Ketika orang-orang masuk, mereka biasanya bertemu dengan orang yang tepat dan mendengarkan mereka. Anda dapat mengatakan hal yang sama lima hal kepada seseorang sebagai in-house dan tidak mendapatkan hasil, tetapi jika seorang agen datang dan mengatakan hal yang sama tiba-tiba ada lebih banyak dukungan dan Anda telah dikuatkan.

Nicholas: Ya, itu sangat benar. Saya memiliki orang-orang di dalam organisasi yang mengatakan, "Terima kasih. Saya telah mengatakan hal yang sama, tetapi kami hanya membutuhkan seseorang dari luar untuk mengatakannya lagi".

Terima kasih atas jawaban Anda yang satu itu Patrick. Saya menghargai transparansi Anda. Dan Paul, mari kita dengar pendapat Anda tentang pertanyaan-pertanyaan ini.

Bicaralah Bahasa

Paul: Pertama-tama, saya menyukai tip Tom yang dia sebutkan sebelumnya tentang mengambil kesempatan untuk membangun hubungan tatap muka dengan klien.

Dalam hal hal lain yang dapat Anda lakukan, mengetahui dengan siapa Anda berbicara dan berbicara dalam bahasa mereka sangat membantu. Misalnya, jika Anda berbicara dengan tim pemasaran, Anda pasti ingin berbicara tentang dolar dan sen dan bagaimana hal itu akan memengaruhi pekerjaan mereka.

Nicholas: Tentu saja, itu adalah tip yang bagus untuk pergi ke kantor klien. Jadi Tom, apa tips hebat lainnya yang Anda miliki untuk kami?

Pelaporan SEO Teknis

Tom: Satu hal yang belum kami sebutkan—yang menyentuh pertanyaan ketiga—adalah bagaimana Anda melakukan pelaporan. SEO memiliki kecenderungan untuk menulis laporan besar yang memadukan alasan SEO dengan hasil. Salah satu tip untuk pelaporan yang lebih baik adalah jangan mengubur prospek—baris subjek email Anda harus menjadi nilai tambah tingkat atas. Tetapi juga, jangan hanya memberi mereka dokumen Word yang besar.

Anda harus melihat bahasa apa yang digunakan klien dalam laporan tahunan mereka atau di situs web mereka, dan mencerminkan bahasa itu di dek slide Anda. Dengan begitu, semua ucapan Anda terhubung kembali ke mereka dalam bahasa mereka sendiri.

Anda dapat membuat laporan sebagai dek slide yang menyajikan takeaways tingkat tinggi utama, membuat informasi sangat mudah diakses dan dibagikan. Karena laporan teks besar itu tidak akan dibaca oleh tingkat manajemen, tetapi jika Anda memberi mereka dek slide yang dapat dipindai, lebih banyak orang di dalam bisnis akan mengetahui apa yang Anda lakukan untuk bisnis mereka.

Poin lain yang sangat penting adalah poin yang dibuat Paulus—bicaralah dalam bahasa mereka. Anda harus melihat bahasa apa yang digunakan klien dalam laporan tahunan mereka atau di situs web mereka, dan mencerminkan bahasa itu di dek slide Anda. Dengan begitu, semua ucapan Anda terhubung kembali ke mereka dalam bahasa mereka sendiri. Dan hubungkan dengan pendapatan, karena itulah yang dipedulikan oleh tingkat manajemen.

Soroti Tujuan/Sasaran Umum

Pendekatan yang lebih taktis adalah mencari tahu apa tujuan masing-masing departemen. Memahami tujuan mereka akan memungkinkan Anda untuk menjelaskan bagaimana perubahan Anda akan membantu mereka mencapai tujuan mereka.

Nicholas: Ya, itu poin yang sangat bagus untuk memahami tujuan departemen tempat Anda bekerja dan mengaitkan pelaporan Anda langsung ke dalamnya.

Patrick: Itu poin yang bagus. Setiap departemen akan memiliki tujuan yang berbeda dan Anda dapat membuat kartu skor yang akan menunjukkan kepada berbagai departemen ini bagaimana rekomendasi Anda akan membantu mereka memenuhi tujuan pribadi mereka.

Nikolas: Benar. Dan itu dapat memberikan motivasi untuk bergerak melalui siklus implementasi.

Paul: Ada posting bagus oleh Rob Ousbey di blog Moz yang saya sarankan Anda baca jika Anda berurusan dengan masalah ini.

Nicholas: Posting yang ditulis David Sottimano yang menyediakan daftar periksa untuk SEO Junior juga layak untuk dicoba.

Membuat Laporan Serbaguna

Nicholas: Satu hal lain yang Anda sebutkan Tom yang menarik bagi saya adalah segitiga pelaporan. Dalam benak saya, saya selalu melihatnya sebagai tiga jenis laporan berbeda yang akan Anda kumpulkan, termasuk: spreadsheet dan ringkasan data, tayangan slide untuk tingkat eksekutif yang tidak menginginkan seluk beluk melainkan ringkasan, dan kemudian laporan tertulis panjang yang menjelaskan semuanya secara mendalam.

Saat Anda melakukan pelaporan, apakah Anda biasanya melakukan ketiganya atau Anda menyesuaikan laporan berdasarkan dengan siapa Anda bekerja?

Tom: Yang sering kami lakukan adalah mengonversi laporan berisi teks menjadi tabel. Jadi Anda dapat memiliki rekomendasi dalam satu kalimat, dan kemudian dalam kolom Anda dapat memiliki alasan teknis, apa yang perlu dilakukan, dan apa dampaknya. Ini bekerja dengan baik karena tim yang berbeda mungkin tertarik pada kolom yang berbeda dan mereka dapat melewati informasi yang tidak relevan dengan mudah.

Jika Anda dapat membuat satu laporan sedemikian rupa sehingga dapat diakses oleh beberapa tim, Anda tidak perlu membuat beberapa laporan yang berbeda.

Nicholas: Ya, saya yakin itu benar.

Tom: Jadi, jika Anda dapat membuat satu laporan sedemikian rupa sehingga dapat diakses oleh banyak tim, Anda tidak perlu membuat beberapa laporan yang berbeda.

Nicholas: Benar, itu sangat masuk akal. Saya pikir akan selalu ada nilai dalam memasukkan informasi itu ke dalam tayangan slide dengan grafik dan gambar, tetapi saya suka menghindari melakukan itu jika memungkinkan karena itu pekerjaan yang sibuk.

Pertanyaan Lima: Apa yang paling Anda sukai dari SEO teknis?

Percakapan dimulai pada pukul 38:42.

Nicholas: Patrick, ayo kita bawa pergi.

Teknis SEO: Tantangan Baru, Kreativitas, dan Hasil Terukur

Patrick: Saya suka pertanyaan ini! Bagi saya, saya suka bahwa selalu ada masalah baru dan hal-hal yang belum pernah saya lihat sebelumnya. Selalu ada sesuatu yang saya rasa tidak akan saya lihat di tempat lain—selalu ada sesuatu yang baru.

Nicholas: Saya setuju, itu salah satu hal terbaik tentang SEO teknis, Jarang ada momen kering, selalu ada teka-teki baru untuk dipecahkan.

Paul bagaimana dengan Anda, apa yang paling Anda sukai?

Paul: Anda tahu, SEO teknis membuat reputasi ini sangat kering. Tapi menurut saya ini adalah salah satu bidang SEO yang paling kreatif, karena Anda berurusan dengan bentuk kendala dan Anda dipaksa untuk menemukan solusi unik dan memecahkan masalah dengan cara yang menarik. Jadi bagi saya, kreativitas yang terlibat dalam SEO teknis yang melakukannya untuk saya.

Nikolas: Tentu. Dibutuhkan jenis pemikiran yang kreatif dan di luar kotak untuk mendekati masalah teknis dan memahaminya.

Jadi Tom, apa hal favorit Anda tentang SEO teknis?

Tom: Saya akan mengulangi jawaban yang sama menurut saya—bagian teka-teki pemecahan ini. Seringkali, tidak ada satu jawaban yang benar atau ketika ada, kita tidak dapat benar-benar melakukan solusi itu sehingga kita harus menemukan jawaban terbaik berikutnya. Itu adalah pemikiran kreatif untuk menemukan solusi yang berbeda.

Dalam SEO teknis Anda benar-benar dapat melihat apa yang telah Anda capai.

Alasan lain adalah bahwa ini adalah salah satu bidang pemasaran di mana Anda dapat benar-benar mulai mengukur dampak Anda, sedangkan sulit untuk melakukannya di bidang pemasaran lainnya. Dalam SEO teknis Anda benar-benar dapat melihat apa yang telah Anda capai.

Nicholas: Tentu, dan salah satu bagian terbaik dari SEO teknis adalah pengujian dan eksperimen. Bermain dengan mesin pencari dan algoritme pembelajaran mesin dan mencoba mencari tahu apa yang paling berhasil sangat menarik bagi saya.

Tomo: Ya. Dan mengoptimalkan terhadap algoritma Google yang selalu berubah berarti apa yang berhasil beberapa bulan yang lalu mungkin tidak lagi menjadi masalah, jadi Anda harus terus belajar.

Nicholas: Tentu saja. Itu adalah serangkaian alasan yang sangat bagus mengapa SEO teknis luar biasa, terima kasih tuan-tuan.

Pertanyaan Enam: Bagaimana Anda menangani perubahan inventaris besar-besaran yang menyebabkan berton-ton 404 detik setiap hari?

Diskusi dimulai pada menit ke 43:40.

Patrick: Jadi saya berasumsi itu e-niaga. Saya kira saya akan mulai dengan apakah produknya akan kembali? Jika mereka hanya 404 karena kehabisan persediaan tetapi mereka akan memiliki persediaan minggu depan, itu berbeda dari jika produk baru saja habis.

Dalam kasus yang pertama, saya tidak akan membiarkan halaman 404, saya hanya akan menunjukkan bahwa mereka kehabisan stok. Dalam kasus yang terakhir, jika itu satu ton, Anda mungkin perlu meningkatkan pengalihan Anda atau memprioritaskannya berdasarkan tautan masuk (baik internal maupun eksternal) untuk memastikan Anda tidak mendapatkan banyak 404.

Memverifikasi Data

Nicholas: Saya ingin tahu apakah pertanyaan ini datang dari seseorang yang mendapatkan banyak kesalahan di Alat Webmaster karena ini adalah 404 lunak. Jadi tidak apa-apa jika ini menjadi 404, tetapi mereka tidak boleh menjadi 404 lunak dan Anda perlu memastikan server Anda mengirimkan respons yang tepat.

Tom: Ini adalah alasan lain untuk hal-hal analisis file log, karena itu adalah data yang benar-benar dapat Anda percayai. Terkadang dengan Alat Webmaster sangat sulit untuk mengetahui apakah data tersebut dapat dipercaya. Dan memiliki pendekatan reaksioner dan bertindak berdasarkan itu bisa berbahaya, jadi Anda ingin memverifikasi apa yang sebenarnya terjadi terlebih dahulu.

Paul: Anda mungkin juga ingin bertanya mengapa 404. Apakah disengaja atau tidak? Anda mungkin ingin mengonfigurasi ulang sesuatu sehingga tidak 404 ketika stok habis, dan itu akan tergantung pada CMS apa pun yang Anda gunakan.

Nicholas: Dan itu sangat tergantung pada situasi dan apakah ini adalah produk yang benar-benar hilang selamanya, atau akan kembali lagi? Itu benar-benar faktor penentu.

Pertanyaan Tujuh: Apakah disarankan untuk memiliki CSS dan JavaScript yang besar untuk situs web di footer agar halaman dimuat lebih cepat?

Diskusi dimulai pada 46:20.

Tom: Jadi sebenarnya ada dua pertanyaan di sana. JavaScript pasti harus ada di footer, itu praktik terbaik standar untuk kecepatan halaman. Saya belum pernah mendengar kasus yang bagus untuk itu (JavaScript) yang berdampak pada SEO.

Anda harus selalu memverifikasi apa yang terjadi di dalam Search Console.

Masalah yang lebih besar dengan file JavaScript baru-baru ini adalah orang menggunakan file JavaScript pihak ketiga yang terkadang lebih lambat, dan sering diblokir oleh robots.txt. Jadi, jika Anda melakukan render apa pun dengan Google di dalam Search Console, Anda akan melihat bahwa itu sebenarnya diblokir. Jadi, Anda harus selalu memverifikasi apa yang terjadi di dalam Search Console.

Nikolas: Benar. Satu masalah menarik yang saya miliki dengan JavaScript di kepala adalah dengan Search Console mendeteksi kode hreflang di bawahnya. Jadi Search Console mengatakan tidak ada halaman dengan markup, dan itu karena JavaScript berada di atas hreflang di kepala.

Jadi kami memindahkan JavaScript ke footer, dan itu mendeteksi hreflang dan juga membuat pengambilan dan rendering juga berfungsi dengan baik.

Pertanyaan Delapan: Bagaimana Anda mengukur hasil perubahan secara akurat dan menunjukkan hasil tersebut kepada klien?

Diskusi dimulai pada 48:51.

Tom: Ada banyak cara berbeda untuk melakukan ini. Salah satu cara yang menarik adalah dengan menggunakan pustaka CausalImpact Google untuk membantu Anda menguji dampak dari perubahan yang Anda buat. Tom mereferensikan posting ini oleh Mark Edmondson.

Di luar itu, semakin banyak orang mulai menggunakan metodologi A/B. Tom mereferensikan posting ini oleh Etsy.

Nicholas: Mari kita dengar dari Patrick atau Paul tentang ini.

Patrick: Ini akan tergantung pada skala, Anda hanya perlu melacak apa yang penting. Pastikan Anda memiliki data yang Anda butuhkan untuk melacak apa yang ingin Anda lakukan.

Nikolas: Tentu. Saya tidak tahu apakah Anda pernah sampai ke ujung jalan sendiri dan tidak memiliki data, tetapi itu bukan tempat yang menyenangkan untuk dikunjungi.

Baiklah mari kita selesaikan ini dengan pemikiran terakhirmu Paul.

Paulus: Tentu. Pertama-tama, saya pikir metodologi pengujian A/B sangat diremehkan di lingkungan SEO, dan jika Anda dapat mengetahui proses yang baik untuk melakukan itu dalam organisasi Anda, saya sangat menyarankan itu.

Jika itu tidak memungkinkan, maka Anda terjebak dengan melihat perubahan apa yang dibuat, kapan perubahan itu dibuat, kapan mesin telusur mengetahui perubahan ini, dan apa dampaknya (lalu lintas naik, konversi meningkat, dll.).

Dan kemudian Anda mencoba menghilangkan sebanyak mungkin faktor asing dan mengisolasinya dari perubahan yang telah Anda buat. Ini tidak selalu mudah, tetapi Anda setidaknya dapat melakukan pekerjaan yang layak dengan mengatakan bahwa ini adalah dampak dari perubahan yang diberikan.

Dan Itu Bungkus!