pushState và SEO

Nhiều người đã nói, sử dụng pushState thay vì hashbang.

Điều tôi không hiểu là, làm thế nào bạn sẽ thân thiện với công cụ tìm kiếm mà không sử dụng hashbang?

Có lẽ nội dung pushState của bạn được tạo bởi mã JavaScript phía máy khách.

Kịch bản là như vậy:

Tôi đang ở trên example.com. Người dùng của tôi nhấp vào một liên kết:href="example.com/blog"

pushState nắm bắt lần nhấp, cập nhật URL, lấy tệp JSON từ đâu đó và tạo danh sách các bài đăng trên blog trong khu vực nội dung.

Với hashbangs, google biết cách truy cập URL Escape_fragment để lấy nội dung tĩnh của chúng.

Với pushState, Google không thấy gì vì nó không thể sử dụng mã JavaScript để tải JSON và sau đó tạo mẫu.

Cách duy nhất để làm điều đó mà tôi có thể thấy là hiển thị mẫu ở phía máy chủ, nhưng điều đó hoàn toàn phủ nhận lợi ích của việc đẩy lớp ứng dụng đến máy khách.

Vì vậy, tôi hiểu đúng, pushState không thân thiện với SEO cho các ứng dụng phía máy khách?

Còn về việc sử dụng thẻ meta mà Google đề xuất cho những người không muốn sử dụng hash-bangs trong URL của họ: <meta name="fragment" content="!">

Xem tại đây để biết thêm thông tin: https://developers.google.com/webmasters/ajax-crawling/docs/getting-started

Thật không may, tôi không nghĩ Nicole làm rõ vấn đề mà tôi nghĩ OP đang gặp phải. Vấn đề chỉ đơn giản là chúng ta không biết mình đang phân phối nội dung cho ai nếu chúng ta không sử dụng hash-bang. Pushstate không giải quyết điều này cho chúng tôi. Chúng tôi không muốn các công cụ tìm kiếm yêu cầu người dùng cuối điều hướng đến một số URL tạo ra JSON chưa được định dạng. Thay vào đó, chúng tôi tạo các URL (kích hoạt các lệnh gọi khác đến nhiều URL hơn) để truy xuất dữ liệu qua AJAX và hiển thị dữ liệu đó cho người dùng theo cách chúng tôi muốn. Nếu người dùng không phải là con người, thì thay vào đó, chúng tôi có thể cung cấp ảnh chụp nhanh html để các công cụ tìm kiếm có thể hướng người dùng đến URL mà họ mong đợi để tìm thấy dữ liệu được yêu cầu (và theo cách dễ thấy). Nhưng thách thức cuối cùng là làm thế nào để chúng ta xác định loại người dùng? Có, chúng tôi có thể có thể sử dụng. htaccess hoặc thứ gì đó để viết lại URL cho các bot của công cụ tìm kiếm mà chúng tôi phát hiện, nhưng tôi không chắc mức độ an toàn và lâu dài của điều này. Cũng có thể Google có thể phạt mọi người vì làm điều này, nhưng tôi chưa nghiên cứu đầy đủ. Vì vậy, kết hợp (pushstate + thẻ meta của google) dường như là một giải pháp khả thi.

Thật pushStatetệ nếu bạn cần công cụ tìm kiếm để đọc nội dung của bạn?

Không, cuộc thảo luận pushStatexoay quanh việc hoàn thành cùng một quy trình chung cho hashbangs, nhưng với các URL đẹp hơn. Hãy nghĩ về những gì thực sự xảy ra khi bạn sử dụng hashbangs ...

Bạn nói:

Với hashbangs, Google biết cách truy cập URL Escape_fragment để lấy nội dung tĩnh của chúng.

Nói cách khác,

1. Google thấy một liên kết đến example.com/#!/blog
2. Yêu cầu của Google example.com/?_escaped_fragment_=/blog
3. Bạn trả lại ảnh chụp nhanh của nội dung mà người dùng sẽ thấy

Như bạn có thể thấy, nó đã dựa vào máy chủ. Nếu bạn không cung cấp ảnh chụp nhanh nội dung từ máy chủ, thì trang web của bạn không được lập chỉ mục đúng cách.

Vậy làm thế nào Google sẽ thấy bất cứ điều gì với pushState?

Với pushState, google không thấy gì vì nó không thể sử dụng javascript để tải json và sau đó tạo mẫu.

Trên thực tế, Google sẽ xem bất cứ điều gì nó có thể yêu cầu site.com/blog. Một URL vẫn trỏ đến một tài nguyên trên máy chủ và các máy khách vẫn tuân theo hợp đồng này. Tất nhiên, đối với các máy khách hiện đại, Javascript đã mở ra những khả năng mới để truy xuất và tương tác với nội dung mà không cần làm mới trang , nhưng các hợp đồng đều giống nhau.

Vì vậy, sự sang trọng dự kiến pushStatelà nó phục vụ cùng một nội dung cho tất cả người dùng, cũ và mới, có khả năng JS và không, nhưng người dùng mới có được trải nghiệm nâng cao .

Bạn làm cách nào để Google xem nội dung của bạn?

1. Cách tiếp cận của Facebook - phân phát cùng một nội dung tại URL site.com/blogmà ứng dụng khách của bạn sẽ chuyển đổi thành khi bạn chuyển sang /blogtrạng thái. (Facebook chưa sử dụng pushStatemà tôi biết, nhưng họ làm điều này với hashbangs)

2. Cách tiếp cận của Twitter - chuyển hướng tất cả các URL đến thành hashbang tương đương. Nói cách khác, một liên kết đến "/ blog" đẩy /bloglên trạng thái. Nhưng nếu nó được yêu cầu trực tiếp, trình duyệt sẽ kết thúc tại #!/blog. (Đối với Googlebot, điều này sau đó sẽ định tuyến đến _escaped_fragment_như bạn muốn. Đối với các khách hàng khác, bạn có thể pushStatequay lại URL đẹp).

Vì vậy, bạn có mất _escaped_fragment_khả năng với pushState?

Trong một vài nhận xét khác nhau, bạn nói

phân mảnh thoát là hoàn toàn khác nhau. Bạn có thể cung cấp nội dung thuần túy không được kiểm soát, nội dung được lưu trong bộ nhớ cache và không bị đặt dưới tải như các trang bình thường.

Giải pháp lý tưởng là để Google thực hiện các trang web JavaScript hoặc triển khai một số cách để biết rằng có một URL phân đoạn thoát ngay cả đối với các trang web pushstate (robots.txt?).

Những lợi ích bạn đề cập không bị cô lập _escaped_fragment_. Rằng nó thực hiện việc viết lại cho bạn và sử dụng một tham số được đặt tên đặc biệt GETthực sự là một chi tiết triển khai. Nói cách khác, viết lại - không có gì thực sự đặc biệt về nó mà bạn không thể làm gì với URL giữa các ý kiến /blogđể /?content=/blogtrên bạn sử dụng riêng mod_rewrite hoặc của máy chủ của bạn tương đương.

Điều gì sẽ xảy ra nếu bạn không phân phát nội dung phía máy chủ?

Nếu bạn không thể viết lại URL và phân phát một số loại nội dung tại /blog(hoặc bất kỳ trạng thái nào bạn đã đẩy vào trình duyệt), thì máy chủ của bạn thực sự không còn tuân thủ hợp đồng HTTP nữa.

Điều này quan trọng vì tải lại trang (vì bất kỳ lý do gì) sẽ kéo nội dung tại URL này. (Xem https://wiki.mozilla.org/Firefox_3.6/PushState_Security_Review - "view-source và reload đều sẽ tìm nạp nội dung tại URI mới nếu một URI được đẩy.")

Không phải việc vẽ giao diện người dùng một lần ở phía máy khách và tải nội dung qua JS API là một mục tiêu tồi, chỉ là nó không thực sự được tính đến với HTTP và URL và về cơ bản nó không tương thích ngược.

Hiện tại, đây là thứ chính xác mà các hashbang nhằm mục đích - đại diện cho các trạng thái trang riêng biệt được điều hướng trên máy khách chứ không phải trên máy chủ. Ví dụ: tải lại sẽ tải cùng một tài nguyên mà sau đó có thể đọc, phân tích cú pháp và xử lý giá trị đã băm.

Thật tình cờ là chúng cũng đã được sử dụng (đặc biệt là Facebook và Twitter) để thay đổi lịch sử thành vị trí phía máy chủ mà không cần làm mới trang. Đó là trong những trường hợp sử dụng mà mọi người khuyên nên bỏ hashbangs cho pushState.

Nếu bạn hiển thị tất cả nội dung ở phía máy khách, bạn nên pushStatecoi đây là một phần của API lịch sử thuận tiện hơn, và không phải là một cách để sử dụng hashbangs.

Tất cả các cuộc nói chuyện thú vị về pushState và #!, và tôi vẫn không thể thấy cách pushState thay thế mục đích của #! Như người đăng ban đầu yêu cầu.

Tất nhiên, giải pháp của chúng tôi để làm cho trang web / ứng dụng Ajax dựa trên 99% JavaScript của chúng tôi có thể SEO được #!. Vì hiển thị ứng dụng khách được thực hiện qua HTML, JavaScript và PHP, chúng tôi sử dụng logic sau trong trình tải được kiểm soát bởi đích trang của chúng tôi. Các tệp HTML hoàn toàn được tách biệt khỏi JavaScript và PHP vì chúng tôi muốn HTML giống nhau trong cả hai (hầu hết các phần). JavaScript và PHP hầu hết làm được những điều tương tự, nhưng mã PHP ít phức tạp hơn vì JavaScript mang lại trải nghiệm người dùng phong phú hơn nhiều.

JavaScript sử dụng jQuery để đưa vào HTML nội dung mà nó muốn. PHP sử dụng PHPQuery để đưa vào HTML nội dung mà nó muốn - sử dụng 'gần như' cùng một logic, nhưng đơn giản hơn nhiều vì phiên bản PHP sẽ chỉ được sử dụng để hiển thị phiên bản có thể SEO với các liên kết có thể SEO và không được tương tác như phiên bản JavaScript.

Tất cả đều là ba thành phần tạo nên một trang, page.htm, page.js và page.php tồn tại cho bất kỳ thứ gì sử dụng đoạn mã thoát để biết có nên tải phiên bản PHP thay cho phiên bản JavaScript hay không. Phiên bản PHP không cần tồn tại cho nội dung không thể SEO (chẳng hạn như các trang chỉ có thể được nhìn thấy sau khi người dùng đăng nhập). Tất cả là đơn giản.

Tôi vẫn đang phân vân làm cách nào một số nhà phát triển giao diện người dùng có thể phát triển các trang web tuyệt vời (với sự phong phú của Google Tài liệu) mà không sử dụng các công nghệ phía máy chủ kết hợp với các công nghệ của trình duyệt ... Nếu JavaScript thậm chí không được bật, thì giải pháp 99% JavaScript của chúng tôi tất nhiên sẽ không làm được gì nếu không có PHP.

Có thể có một URL đẹp để truy cập vào trang được phân phát PHP và chuyển hướng đến phiên bản JavaScript nếu JavaScript được bật, nhưng điều đó không đẹp từ góc độ người dùng vì người dùng là đối tượng quan trọng hơn.

Còn một chú ý đáng nói. Nếu bạn chỉ đang tạo một trang web đơn giản có thể hoạt động mà không cần bất kỳ JavaScript nào, thì tôi có thể thấy pushState hữu ích nếu bạn muốn nâng cao dần trải nghiệm người dùng của mình từ một nội dung được hiển thị tĩnh đơn giản thành một thứ gì đó tốt hơn, nhưng nếu bạn muốn cung cấp cho người dùng của mình trải nghiệm tốt nhất từ ​​khi di chuyển ... giả sử trò chơi mới nhất của bạn được viết bằng JavaScript hoặc thứ gì đó như Google Tài liệu thì việc sử dụng giải pháp này có phần hạn chế vì việc lùi lại một cách duyên dáng chỉ có thể tiến xa trước khi trải nghiệm người dùng bị tổn hại so với tầm nhìn của trang web.