it-swarm-id.com

pushState dan SEO

Banyak orang mengatakan, gunakan pushState daripada hashbang.

Yang tidak saya mengerti adalah, bagaimana Anda akan ramah mesin pencari tanpa menggunakan hashbang?

Agaknya konten pushState Anda dihasilkan oleh kode JavaScript sisi klien.

Skenarionya adalah sebagai berikut:

Saya menggunakan example.com. Pengguna saya mengklik sebuah tautan: href="example.com/blog"

pushState menangkap klik, memperbarui URL, mengambil file JSON dari suatu tempat, dan membuat daftar posting blog di area konten.

Dengan hashbangs, google tahu untuk pergi ke URL escaped_fragment untuk mendapatkan konten statis mereka.

Dengan pushState, Google tidak melihat apa-apa karena tidak dapat menggunakan kode JavaScript untuk memuat JSON dan kemudian membuat template.

Satu-satunya cara untuk melakukannya yang dapat saya lihat adalah dengan merender template di sisi server, tetapi itu sepenuhnya meniadakan manfaat dari mendorong lapisan aplikasi ke klien.

Jadi, apakah saya sudah benar, pushState sama sekali tidak ramah SEO untuk aplikasi sisi klien?

76
Harry

Bagaimana dengan menggunakan tag meta yang disarankan Google untuk mereka yang tidak ingin poni hash di URL mereka: <meta name="fragment" content="!">

Lihat di sini untuk info lebih lanjut: https://developers.google.com/webmasters/ajax-crawling/docs/getting-started

Sayangnya saya tidak berpikir NickC mengklarifikasi masalah yang saya pikir OP miliki. Masalahnya adalah kita tidak tahu kepada siapa kita melayani konten jika kita tidak menggunakan hash-bang. Pushstate tidak menyelesaikan ini untuk kami. Kami tidak ingin mesin pencari memberi tahu pengguna akhir untuk menavigasi ke beberapa URL yang mengeluarkan JSON yang tidak diformat. Sebaliknya, kami membuat URL (yang memicu panggilan lain ke lebih banyak URL) yang mengambil data melalui AJAX dan menyajikannya kepada pengguna dengan cara yang kami inginkan. Jika pengguna bukan manusia, maka sebagai alternatif, kami dapat melayani html-snapshot, sehingga mesin pencari dapat mengarahkan pengguna manusia dengan baik ke URL yang mereka harapkan untuk menemukan data yang diminta di (dan dengan cara yang rapi). Tetapi tantangan utamanya adalah bagaimana kita menentukan tipe pengguna? Ya, kami mungkin dapat menggunakan .htaccess atau sesuatu untuk menulis ulang URL untuk bot mesin pencari yang kami deteksi, tetapi saya tidak yakin seberapa tahan dan futureproofnya hal ini. Mungkin juga bahwa Google dapat menghukum orang karena melakukan hal semacam ini, tetapi saya belum meneliti sepenuhnya. Jadi kombo (pushstate + google's tag) sepertinya merupakan solusi yang mungkin.

16
prograhammer

Apakah pushState buruk jika Anda membutuhkan mesin pencari untuk membaca konten Anda?

Tidak, pembicaraan tentang pushState diarahkan untuk menyelesaikan proses umum yang sama dengan hashbangs, tetapi dengan URL yang lebih baik. Pikirkan tentang apa yang sebenarnya terjadi ketika Anda menggunakan hashbangs ...

Kamu bilang:

Dengan hashbangs, Google tahu untuk pergi ke URL escaped_fragment untuk mendapatkan konten statis mereka.

Jadi dengan kata lain,

  1. Google melihat tautan ke example.com/#!/blog
  2. Google meminta example.com/?_escaped_fragment_=/blog
  3. Anda mengembalikan cuplikan konten yang harus dilihat pengguna

Seperti yang Anda lihat, itu sudah bergantung pada server. Jika Anda tidak menyajikan snapshot konten dari server, maka situs Anda tidak diindeks dengan benar.

Jadi bagaimana Google melihat sesuatu dengan pushState?

Dengan pushState, google tidak melihat apa-apa karena tidak dapat menggunakan javascript untuk memuat json dan kemudian membuat template.

Sebenarnya, Google akan melihat apa pun yang dapat diminta di site.com/blog. URL masih menunjuk ke sumber daya di server, dan klien masih mematuhi kontrak ini. Tentu saja, untuk klien modern, Javascript telah membuka kemungkinan baru untuk mengambil dan berinteraksi dengan konten tanpa pembaruan halaman, tetapi kontraknya sama.

Jadi keanggunan yang dimaksudkan dari pushState adalah ia menyajikan konten yang sama untuk semua pengguna, lama dan baru, berkemampuan JS dan tidak, tetapi pengguna baru mendapatkan pengalaman yang ditingkatkan .

Bagaimana Anda membuat Google melihat konten Anda?

  1. Pendekatan Facebook - sajikan konten yang sama di URL site.com/blog yang akan diubah oleh aplikasi klien Anda saat Anda Push /blog ke status. (Facebook belum menggunakan pushState yang saya tahu, tetapi mereka melakukan ini dengan hashbangs)

  2. Pendekatan Twitter - redirect semua URL yang masuk ke setara hashbang. Dengan kata lain, tautan ke "/ blog" mendorong /blog ke status. Tetapi jika diminta secara langsung, browser berakhir di #!/blog. (Untuk Googlebot, ini kemudian akan merutekan ke _escaped_fragment_ seperti yang Anda inginkan. Untuk klien lain, Anda dapat pushState kembali ke URL cantik).

Jadi, apakah Anda kehilangan kemampuan _escaped_fragment_ dengan pushState?

Dalam beberapa komentar berbeda, Anda berkata

fragmen yang lolos sama sekali berbeda. Anda dapat menayangkan konten murni tanpa cacat, konten yang di-cache, dan tidak diletakkan di bawah beban seperti halaman normal.

Solusi yang ideal adalah bagi Google untuk melakukan situs JavaScript atau menerapkan beberapa cara untuk mengetahui bahwa ada URL fragmen yang lolos bahkan untuk situs pushstate (robots.txt?).

Manfaat yang Anda sebutkan tidak terisolasi ke _escaped_fragment_. Bahwa ia melakukan penulisan ulang untuk Anda dan menggunakan param GET yang bernama khusus benar-benar detail implementasi. Tidak ada yang benar-benar istimewa tentang hal itu yang tidak dapat Anda lakukan dengan URL standar - dengan kata lain, tulis ulang /blog menjadi /?content=/blog sendiri menggunakan mod_rewrite atau yang setara dengan server Anda.

Bagaimana jika Anda sama sekali tidak menyajikan konten sisi server?

Jika Anda tidak dapat menulis ulang URL dan melayani semacam konten di /blog (atau keadaan apa pun yang Anda masukkan ke browser), maka server Anda benar-benar tidak lagi mematuhi kontrak HTTP.

Ini penting karena memuat ulang halaman (untuk alasan apa pun) akan menarik konten di URL ini. (Lihat https://wiki.mozilla.org/Firefox_3.6/PushState_Security_Review - "view-source dan memuat ulang keduanya akan mengambil konten di URI baru jika ada yang didorong.")

Bukannya menggambar antarmuka pengguna sekali di sisi klien dan memuat konten melalui API JS adalah tujuan yang buruk, hanya saja itu tidak benar-benar diperhitungkan dengan HTTP dan URL dan pada dasarnya tidak kompatibel ke belakang.

Saat ini, ini adalah hal yang persis sama dengan hashbangs yang dimaksudkan - untuk mewakili status halaman berbeda yang dinavigasi pada klien dan bukan pada server. Reload, misalnya, akan memuat sumber daya sama yang kemudian dapat membaca, mem-parsing, dan memproses nilai hash.

Kebetulan mereka memiliki juga telah digunakan (terutama oleh Facebook dan Twitter) untuk mengubah sejarah ke lokasi sisi server tanpa penyegaran halaman. Dalam kasus-kasus penggunaan itulah orang merekomendasikan meninggalkan hashbangs untuk pushState.

Jika Anda merender semua sisi klien konten, Anda harus menganggap pushState sebagai bagian dari API riwayat yang lebih nyaman, dan bukan jalan keluar untuk menggunakan hashbangs.

97
Nicole

Semua pembicaraan menarik tentang pushState dan #!, dan saya masih tidak bisa melihat bagaimana pushState menggantikan tujuan #!.

Solusi kami untuk membuat situs/aplikasi Ajax berbasis JavaScript 99% kami yang SEOable menggunakan #! tentu saja. Karena rendering klien dilakukan melalui HTML, JavaScript, dan PHP kami menggunakan logika berikut dalam loader yang dikendalikan oleh pendaratan halaman kami. File HTML benar-benar terpisah dari JavaScript dan PHP karena kami menginginkan HTML yang sama di keduanya (sebagian besar). JavaScript dan PHP sebagian besar melakukan hal yang sama, tetapi kode PHP tidak terlalu rumit karena JavaScript adalah pengalaman pengguna yang jauh lebih kaya.

JavaScript menggunakan jQuery untuk menyuntikkan ke HTML konten yang diinginkan. PHP menggunakan PHPQuery untuk menyuntikkan ke HTML konten yang diinginkan - menggunakan 'hampir' logika yang sama, tetapi jauh lebih sederhana karena versi PHP hanya akan digunakan untuk menampilkan versi SEOable dengan tautan SEOable dan tidak berinteraksi dengan seperti versi JavaScript.

Semua adalah tiga komponen yang membentuk halaman, page.htm, page.js, dan page.php ada untuk apa pun yang menggunakan fragmen yang lolos untuk mengetahui apakah memuat versi PHP sebagai pengganti versi JavaScript. Versi PHP tidak perlu ada untuk konten non-SEOable (seperti halaman yang hanya bisa dilihat setelah login pengguna). Semua mudah.

Saya masih bingung bagaimana beberapa pengembang front-end pergi mengembangkan situs-situs hebat (dengan kekayaan Google Documents) tanpa menggunakan teknologi sisi-server bersamaan dengan yang menggunakan browser ... Jika JavaScript bahkan tidak diaktifkan, maka solusi JavaScript 99% kami tentu saja tidak akan melakukan apa pun tanpa PHP di tempatnya.

Dimungkinkan untuk memiliki URL Nice untuk mendarat di halaman yang dilayani PHP dan mengalihkan ke versi JavaScript jika JavaScript diaktifkan, tetapi itu tidak baik dari perspektif pengguna karena pengguna adalah audiens yang lebih penting.

Di samping catatan. Jika Anda hanya membuat situs web sederhana yang dapat berfungsi tanpa JavaScript, maka saya dapat melihat pushState bermanfaat jika Anda ingin secara progresif meningkatkan pengalaman pengguna Anda dari konten yang dirender secara statis menjadi sesuatu yang lebih baik, tetapi jika Anda ingin memberi pengguna Anda pengalaman terbaik sejak awal dapatkan ... katakanlah game terbaru Anda yang ditulis dalam JavaScript atau sesuatu seperti Google Documents maka penggunaannya untuk solusi ini agak terbatas karena mundur dengan anggun hanya bisa berjalan sejauh ini sebelum pengalaman pengguna terasa menyakitkan dibandingkan dengan penglihatan dari situs.

0
Julian