- Judul Tag
- URL
- Header
- Tubuh Teks dll
- IP Deteksi / Redirection
- Kecepatan situs
- 301 dan 302 Redirects
- HTTP Header
- Crawler Access
- Javascript
- Flash
Ini adalah tujuh hal yang saya akan membahas di bawah ini.
1) IP Deteksi / Redirection
Saya baru saja mengalami masalah ini tangan pertama pada proyek klien dan itu sangat, sangat berantakan. Bagi Anda yang tidak terbiasa dengan hal ini, deteksi IP dan pengalihan melibatkan menentukan alamat IP dari pengguna di situs Anda, kemudian menunjukkan kepada mereka konten (atau mengarahkan mereka ke URL baru) berdasarkan lokasi mereka. Untuk memberikan contoh, jika seseorang mendarat di www.domain.co.uk dan alamat IP mereka menunjukkan mereka berada di Perancis, Anda bisa mengarahkan mereka untuk www.domain.fr yang berisi konten Perancis.Untuk pengguna, ini tidak benar-benar hal yang mengerikan. Hal ini tidak sangat mudah deteksi IP tidak selalu 100% akurat, tetapi biasanya itu berarti Anda dapat menunjukkan pengguna konten yang lebih relevan dengan lokasi dan bahasa mereka. Kedengarannya bagus dan masuk akal.
Namun untuk crawler mesin pencari, ini bisa sangat merepotkan. Terutama karena mereka biasanya akan merangkak dari IP berbasis di AS, ini berarti bahwa mereka tidak pernah dapat melihat beberapa konten Anda. Klien baru-baru ini saya sedang mengarahkan berdasarkan IP dan akhirnya mengarahkan mesin pencari ke domain .us mereka. Ini berarti bahwa mesin pencari tidak melihat negara-negara lain mereka menargetkan termasuk Inggris dan Australia. http://warnaku-ungu.blogspot.com/2015/03/meggunakan-seo-teknis.html
2) Kecepatan Site
Ini pasti harus tinggi pada daftar prioritas untuk pengembang Anda akan melihat. Bukan hanya karena kita tahu itu menjadi faktor peringkat , tetapi terutama karena situs cepat lebih baik bagi pengguna dan akhirnya, konversi. Berapa lama Anda bertahan di situs yang memakan waktu lebih lama dari beberapa detik untuk memuat? Pengguna yang sama.Dari sudut pandang SEO, Anda perlu peduli tentang kecepatan situs karena Google terobsesi dengan kecepatan . Baru saja saya membaca Di Plex yang memberikan wawasan ke dalam hari-hari awal Google dan menjelaskan kasus di mana Larry Page telah mengukur kecepatan produk dalam kepalanya dan telah akurat dalam persepuluh detik. Setiap produk yang dia memberikan umpan balik pada kebutuhan untuk menjadi super cepat untuk itu untuk memiliki kesempatan untuk bergerak maju. Google memahami berapa banyak pengguna peduli tentang kecepatan, sehingga Anda harus juga.
Jika Anda sedang berjuang dengan pengembang di sini, pergi ke webpagetest.org dan membandingkan situs klien Anda dengan beberapa pesaing. Kemudian mengirim pengembang salinan video:
Hal ini sering dapat memberi mereka dorongan yang mereka butuhkan untuk mengambil kecepatan situs sedikit lebih serius. Dalam hal spesifik, lihatlah panduan epik ini dari Craig tentang Kecepatan Situs dan SEO untuk mendapatkan tangan pada tips dan alat untuk meningkatkan kecepatan situs.
3) 301 dan 302 Redirects
Maaf, tapi banyak pengembang (dan SEO) mendapatkan ini salah. Sekarang, Anda hanya perlu menerapkan dua jenis redirect - 301 atau 302. Thats it. Tidak ada 303s, 307s atau apa pun. Ada dua cara utama bahwa hal ini dapat mengacaukan, cara pertama saya akan berbicara tentang menggunakan salah jenis redirect.Mendapatkan 301s dan 302s Mixed Up
Untuk memberikan beberapa latar belakang dan konteks. Sebuah 301 redirect biasanya digunakan dalam SEO untuk salah satu alasan berikut -
- Sebuah halaman telah pindah ke suatu tempat atau diturunkan, sehingga Anda ingin mengarahkan pengguna dan mesin pencari ke halaman baru yang sesuai
- Entah bagaimana Anda telah membuat beberapa duplikat konten dan ingin menghapusnya dari indeks Google dengan mengalihkan mereka ke versi kanonik utama
Meskipun tidak SEO friendly (kita akan membahas mengapa sebentar lagi), ada beberapa alasan yang tulus untuk SEO menggunakan 302 redirect -
- Sebuah halaman mungkin hanya sementara tidak tersedia, misalnya produk yang lama saham di sebuah situs e-commerce yang akan kembali di saham segera
- Anda mungkin ingin menguji pindah ke domain baru untuk mendapatkan umpan balik pelanggan tetapi tidak ingin merusak domain sejarah dan peringkat tua
Alasan umum mengapa beberapa SEO dan pengembang mendapatkan ini salah adalah bahwa untuk pengguna, mereka tidak melihat perbedaan apapun. Mereka akan diarahkan pula. Tapi mesin pencari akan melihat perbedaan. Saya telah melihat contoh klien bergerak situs mereka seluruh ke domain baru dan semua pengalihan menjadi 302. Ini buruk karena -
- Link juice tidak akan diteruskan menyeberang ke URL baru, yang berarti mereka tidak mungkin untuk peringkat yang baik dalam jangka pendek dan jangka panjang mungkin
- Google tidak akan menyingkirkan URL lama dari indeks yang berarti Anda dapat memiliki beberapa URL dari domain lama dan baru diindeks pada saat yang sama
Mengarahkan semua URL kembali ke Homepage
Ini adalah masalah lain yang pernah saya jumpai lebih dari sekali. Google menyarankan bahwa ketika Anda menerapkan pengalihan, Anda melakukannya pada satu untuk satu dasar. Sebagai contoh -
Anda harus mengarahkan:
http://www.old-site.com/product-name-12345 ke http://www.new-site.com/product-name-12345
http://www.old-site.com/product-name-10000 ke http://www.new-site.com/product-name-10000
Apa yang beberapa orang berbuat salah adalah redirect -
http://www.old-site.com/product-name-12345 ke http://www.new-site.com
http://www.old-site.com/product-name-10000 ke http://www.new-site.com
Mengarahkan semua halaman kembali ke homepage, atau bahkan kategori tingkat atas tunggal, adalah buruk bagi pengguna dan kadang-kadang dapat melihat manipulatif. Juga tidak melewati link juice yang sangat dibutuhkan menyeberang ke halaman jauh di dalam situs Anda yang membutuhkan mereka, dalam contoh di atas, halaman produk tidak mendapatkan jus yang mereka butuhkan.
Sekali lagi, saya telah melihat banyak situs kehilangan banyak lalu lintas dengan melakukan hal ini. Terutama karena mereka kehilangan peringkat untuk halaman yang mendalam yang biasanya ekor panjang.
4) Kode HTTP header
Kemungkinannya adalah bahwa banyak pengembang akan tahu apa kode HTTP header ini berarti, tetapi dalam kaitannya dengan SEO, mereka mungkin tidak tahu apa efek yang mereka miliki atau bagaimana mesin pencari memperlakukan mereka. Ada banyak dan banyak kode status di luar sana (apakah Anda tahu bahwa kode status 418 berarti aku teko ?!), tetapi sebagai SEO, Anda tentu harus mengenal HTTP header berikut dengan baik dan tahu apa dampaknya dapat memiliki. Untuk cara visual yang hebat untuk memahami kode header, orang-orang di SEOgadget membuat infografis, klik pada gambar di bawah ini untuk membuka Infographic penuh:
200 Sukses - Ini berarti bahwa halaman telah dimuat berhasil. Untuk pengguna dan mesin pencari, ini berarti bahwa halaman bekerja dengan baik dan harus diindeks dan peringkat.
301 Moved Permanently - ini telah dibahas secara lebih rinci di atas, tetapi dalam ringkasan, berarti bahwa halaman telah secara permanen dipindahkan ke tempat lain. Kedua pengguna dan mesin pencari diarahkan dan sebagian link juice dilewatkan di redirect, halaman lama akan dihapus dari indeks.
302 sementara Dipindahkan - Sekali lagi, ini dijelaskan di atas, tetapi berarti bahwa halaman untuk sementara dipindahkan ke tempat lain. Pengguna tidak akan melihat perbedaan antara 301 dan 302, tetapi mesin pencari tidak akan lulus jus link di atasnya tidak akan mereka de-index URL lama.
404 Halaman Tidak Ditemukan - Anda mungkin akrab dengan yang satu ini. Untuk pengguna dan mesin pencari, ini berarti bahwa halaman yang diminta tidak dapat dimuat. Jika halaman diindeks tiba-tiba menjadi halaman 404, dari waktu ke waktu mesin pencari akan berhenti peringkat itu (dari pengalaman dan tes saya tetap).
Sidenote cepat di sini dari pengalaman. Sesuatu yang pernah saya jumpai beberapa kali adalah situasi di mana halaman akan ditampilkan kepada pengguna yang terlihat seperti 404, namun ketika Anda melihat header HTTP, maka akan tampil 200 kode Sukses sebagai gantinya. Hal ini tidak baik dan Google telah diklasifikasikan ini 404s lembut. Alasan mereka tidak baik adalah bahwa sulit bagi Anda untuk menemukan kesalahan ini menggunakan log server atau Google Webmaster Tools. Meskipun Google tidak mencoba untuk menemukan mereka , yang terbaik untuk tidak mengandalkan Google untuk melakukan ini untuk Anda.
Praktik terbaik adalah untuk memastikan bahwa halaman 404 sebenarnya mengembalikan header HTTP 404. By the way, Anda harus memeriksa Distilasi 404 halaman yang dibangun kami magang Andrew.
410 Halaman permanen Tidak Ditemukan - Saya tidak yakin mengapa saya akan menggunakan ini daripada 301 redirect, tapi mungkin ada beberapa penggunaan yang baik dan nilainya mengetahui bagaimana Google mengobatinya .
500 Internal Server Error - Ini adalah halaman kesalahan umum dan tidak sangat membantu karena tidak biasanya memberikan banyak detail mengapa kesalahan terjadi. Anda pasti harus mencoba dan menjaga kesalahan ini ke minimum absolut.
503 Service Unavailable - Sementara ini bukan kode yang biasa harus menggunakan, hal ini berguna untuk mengetahui apakah situs Anda untuk sementara down dan akan segera kembali. Misalnya jika Anda meluncurkan kembali situs atau desain baru, Anda mungkin harus melakukan ini dengan mengambil lokasi offline. Yang lebih baik untuk mengembalikan 503 sehingga mesin pencari tahu untuk kembali lagi nanti. John Mu juga menegaskan posisi Google dalam hal ini :
"Secara optimal, semua seperti" server down "URL harus kembali kode hasil 503 (layanan tidak tersedia). Melakukan yang juga mencegah mesin pencari dari merangkak dan mengindeks halaman error:-). Kadang-kadang aku terkejut melihat betapa banyak situs besar lupa untuk melakukan hal ini ... "
5) Crawler Access
Bagi saya, membatasi akses crawler dan mengoptimalkan penyisihan merangkak Anda adalah bagian diabaikan dari SEO. Mungkin karena itu dapat sedikit sulit untuk melaksanakan dan tidak benar-benar ilmu pasti nya. Untuk memahami hal ini dan mengoptimalkan itu, Anda harus terlebih dahulu menjadi nyaman dengan konsep penyisihan merangkak. Rand menulis posting besar atas pada SEOmoz tentang ini mengikuti beberapa komentar dari Matt Cutts pada topik.Pada tingkat dasar, Google akan merangkak kasar berdasarkan PageRank sebagai Matt Cutts telah dijelaskan sebelumnya :
Intinya untuk SEO - Jangan berpikir bahwa Google secara otomatis akan
merangkak dan mengindeks setiap halaman di situs Anda, sementara Google
telah membuat jelas bahwa mereka ingin mencari setiap informasi di web,
mereka memiliki sumber daya yang terbatas dan harus selektif tentang
halaman mana yang mereka merangkak berulang-ulang. 
Sayangnya, banyak SEO tidak selalu dalam posisi untuk bisa bekerja dengan pengembang dan menentukan arsitektur situs dari awal. Biasanya yang kasus bekerja dengan arsitektur situs yang ada dan berusaha untuk memperbaiki dan mengoptimalkan apa yang Anda bisa. Ada beberapa cara untuk melakukan ini dan Anda perlu untuk bekerja dengan pengembang untuk menggunakan teknik ini secara efektif.
Robots.txt - ini adalah file pertama bahwa sebuah mesin pencari akan meminta ketika mereka menjelajah situs Anda. Dalam file ini, mereka akan mencoba untuk melihat apakah ada area situs atau URL tertentu bahwa mereka tidak harus merangkak. Ada beberapa perdebatan tentang bagaimana ketat mesin pencari mematuhi whats terkandung dalam file robots.txt, tapi saya masih berpikir Anda harus menggunakannya dan merasa yang handal dalam banyak kasus. Sebuah file robots.txt biasanya terlihat seperti ini yang dari Amazon.co.uk :
Atau jika Anda adalah seseorang seperti Rishi , mungkin terlihat seperti ini :
Jika Anda tidak terbiasa dengan cara menulis file robots.txt, yang terbaik untuk mendapatkan nyaman dengan itu sebelum berbicara dengan pengembang pada topik. Baca panduan ini dari Google dan uji di situs Anda sendiri.
Tindakan untuk mengambil di sini adalah untuk mengambil baik melihat situs Anda dan memutuskan mana bagian yang Anda tidak ingin mesin pencari untuk menjelajah. Menggunakan beberapa hati di sini meskipun, karena Anda tidak ingin memblokir halaman secara tidak sengaja.
Rel = Canonical - Saya tidak pernah merekomendasikan menggunakan rel = kanonik tag di situs baru. Beberapa mungkin tidak setuju dengan saya, tapi saya melihat rel = kanonik sebagai upaya terakhir dalam memecahkan masalah arsitektur situs. Jika Anda dapat menghindari masalah ini di tempat pertama, melakukannya. Jangan berpikir rel = kanonik sebagai alat untuk membantu Anda.
Alasan utama untuk ini adalah bahwa tag ini bukan aturan yang ketat. Mesin pencari tidak harus memperhatikan dan dapat mengubah cara mereka memperlakukan setiap saat mereka inginkan. Bukti saat ini menunjukkan bahwa mesin pencari memperhatikan dan menggunakannya cukup kuat. Tapi aku masih akan menyarankan agar mengandalkan itu untuk jangka panjang.
Perlu membuat pengembang Anda sadar tag ini dan memastikan mereka tahu implikasi menggunakannya. Hal ini dapat membantu dalam memecahkan masalah duplikat konten, tapi pada saat yang sama, dapat dengan mudah salah jika Anda tidak menggunakannya dengan benar. Keuntungan besar untuk menggunakan rel = kanonik dari sudut pandang pembangunan adalah bahwa (dalam teori) lebih mudah diterapkan daripada 301 redirect:
6) Javascript
Javascript bisa menjadi hal yang besar, dapat menambahkan fungsionalitas besar untuk situs web Anda dan meningkatkan pengalaman pengguna. Namun, mesin pencari berjuang dengan pemahaman Javascript. Mereka menjadi lebih baik sepanjang waktu dan secara aktif berusaha untuk mengeksekusi Javascript sehingga mereka dapat mengakses lebih banyak konten. Karena itu, ada dua hal penting yang perlu Anda ingat -Jangan menempatkan konten yang berharga dalam javascript - Anda ingin memastikan bahwa mesin pencari dapat membaca semua konten yang telah diproduksi. Jangan biarkan semua usaha Anda pergi ke limbah dengan menempatkan konten Anda di dalam javascript yang mesin pencari tidak bisa mendapatkan.
Sebuah cara yang umum saya pernah melihat ini dilakukan di masa lalu adalah ketika menavigasi antara tab pada halaman produk e-commerce. Ketika pengguna mengklik tab seperti "Informasi selengkapnya", konten tersebut dimuat dalam menggunakan javascript. Ini bagus untuk pengguna, tetapi mesin pencari mungkin tidak dapat menemukan konten tambahan ini. Sementara mereka mungkin bisa sampai ke sana, praktek terbaik untuk menjadi aman dan memuat konten ke halaman tanpa harus mengeksekusi javascript tambahan.
Sesuatu yang saya pasti akan menganjurkan adalah penggunaan Jquery mana mungkin. Jquery dapat membuat elemen halaman terlihat hanya indah seperti javascript, tetapi pada umumnya SEO friendly. Ketika Anda melihat sumber pada elemen dibuat menggunakan Jquery, Anda biasanya dapat melihat konten yang besar untuk mesin pencari.
Jangan menempatkan konten atau link dalam javascript untuk sengaja menyembunyikannya dari Google - ini adalah taktik lama yang SEO akan digunakan untuk berbagai alasan. Ini kembali pada hari ketika mesin pencari benar-benar berjuang untuk melihat apa yang ada di dalam javascript. Sehingga dapat digunakan untuk praktik lama seperti PageRank patung atau hanya bersembunyi terang-terangan konten.
7) flash
Sebagian besar dari Anda harus tahu yang satu ini, tetapi hanya untuk kelengkapan, mari kita berbicara secara singkat tentang flash. Seperti javascript, mesin pencari berjuang untuk memahami unsur-unsur flash halaman. Meskipun berbagai perbaikan , mesin pencari tidak cukup sebagai maju seperti mereka dengan javascript. Namun Google dapat mengekstrak beberapa teks dan URL yang berada dalam elemen flash, tetapi tidak semua mesin pencari bisa melakukan ini.Intinya di sini adalah bahwa Anda tidak bisa membiarkan klien, pengembang atau desainer untuk membangun situs mereka seluruh berdasarkan elemen flash. Meningkatkan halaman menggunakan lampu kilat baik-baik saja, tapi saya akan berhati-hati tentang bagaimana mesin pencari bisa melihatnya.
Kesimpulan
Saya pikir ada takeaways kunci:- Cinta pengembang Anda! Mereka dapat melakukan beberapa pekerjaan yang mengagumkan untuk Anda dan jangan meremehkan kemampuan mereka untuk melakukan hal-hal keren untuk membantu SEO
- Jangan menganggap mereka tahu segalanya - siap untuk membantu mereka memahami implikasi SEO dari pekerjaan mereka
- Memberikan pengembang kredit di mana akibat - jika mereka membuat perubahan ke situs dan membantu hasil
http://masihakudisini.kinja.com/tempat-kursus-website-seo-desain-grafis-favorit-2015-1688473431
http://frata.org/2015/02/28/tempat-kursus-website-seo-desain-grafis-favorit-2015-di-jakarta
perlu diikuti langkah-langkahnya nih..
BalasHapus