Tuy nhiên, HTML5 không phải là chuyện lớn. Hãy nghĩ rằng HTML5 không chỉ là một công cụ mà nó là một tập các công cụ, một tập các tính năng mới, trong một vài trường hợp chúng độc lập với nhau. Bài viết này nói về lợi ích của HTML5 đối với SEO. Tuy nhiên, chúng tôi sẽ đề cập đến những gì mà trình duyệt không hỗ trợ và làm thế nào để liên quan đến SEO, có rất nhiều bits trong bộ công cụ HTML5 mà không ảnh hưởng gì đến các trình duyệt.
Chúng tôi sẽ xem xét một số vấn đề thường gặp trong SEO, thảo luận về cách HTML5 có thể giúp đỡ để giải quyết chúng. Tôi chắc chắc rằng có nhiều tình huống khác mà HTML5 có thể giúp chúng tôi. Tôi nghĩ rằng HTML5 có thể cung cấp một biện pháp hỗ trợ, có thể là ngay bây giờ hoặc trong tương lai gần.
Vấn đề 1: Phân trang
Các vấn đề: nội dung trùng lặp, ngân sách thu thập dữ liệu (crawl budget), juice flow (lưu thông dòng chảy).
Bạn có hàng triệu trang, ví dụ như các danh sách sản phẩm trong một danh mục đặc biệt để liệt kê một tập hợp các sản phẩm trên đó. Bây giờ bạn muốn xếp hạng, nhưng lại không muốn nội dung trùng lặp, lãng phí ngân sách hay việc thu thập dữ liệu cho phép Google thu thập thông tin hàng trăm trang mà vô giá trị. Tuy nhiên, có thể bạn muốn chúng được thu thập để đảm bảo nội dung được index? Có lẽ bạn muốn chúng thu thập thông tin nhưng nhận thức về những sản phẩm cùng loại được liệt kê trong các nhóm khác nhau và trình tự trong các chuyên mục khác nhau và bạn đang lo lắng về điều này. Giá mà bạn có thể nói chuyện được với Google: “Này! Trang này là các danh mục đánh số trang, vì vậy hãy đối xử với chúng cho phù hợp!”.
Đây là một kịch bản phổ biến cho nhiều trang web, đặc biệt là các trang web thương mại điện tử, tuy nhiên nhiều khách hàng vẫn gặp khó khăn. Tiếc là Googlebot chưa được sinh ra vì thế chúng tôi phải tìm cách khác. Vào HTML5 và các liên kết tuần tự:
Chuỗi các tài liệu là một trong những nơi mà mỗi tài liệu có thể có một người anh em trước đó và anh em tiếp theo. Một tài liệu không có anh em trước đó là bắt đầu của trình tự, một tài liệu không có anh em tiếp theo là kết thúc của trình tự đó.
Một tài liệu có thể là một phần của nhiều dãy
Nguồn: W3 HTML5 Spec (http://dev.w3.org/html5/spec-author-...ial-link-types)
Điều đó khá chính xác cho vấn đề mô tả của chúng tôi! Vậy làm thế nào để “liên kết tuần tự” được làm việc? Dĩ nhiên phải thông qua người bạn cũ của chúng tôi đó là thuộc tính rel. Trước đây khi chưa có HTML 5, trang trước của bạn và trang kế tiếp có thể trông giống như:
<a href='products.php?page=3'>Previous Page</a> <a href='products.php?page=5'>Next Page</a>
Và bây giờ chỉ cần thêm thuộc tính rel là đủ
<a href='products.php?page=3' rel='prev'>Previous Page</a> <a href='products.php?page=5' rel='next'>Next Page</a>
Rõ ràng tín hiệu gửi đến các trang là một chuỗi giống nhau, và rõ ràng là thông tin ngữ nghĩa này là một cách làm sạch cho Google, Bing và các công cụ khác biết về mối quan hệ này.
Đây không phải là một giải pháp đơn giản và tôi sẽ chưa đề nghị bạn làm việc này, nhưng tôi muốn khuyên bạn nên thêm những thuộc tính này vào liên kết phân trang của bạn. Nó không phải là một giải pháp hoàn chỉnh vì có dãy các tài liệu chưa phân trang theo cách liệt kê sản phẩm (ví dụ trong phần 1 hướng dẫn) và chúng tôi vẫn chưa có một bức tranh hoàn chỉnh để Google có thể tin tưởng vào những thuộc tính này. Tuy nhiên, bạn có thể nói cho Google biết về nội dung của bạn tốt hơn là bạn giúp họ hiểu và index nội dung của bạn và những thuộc tính này là một chỉ số tuyệt vời đối với Google và là nơi lý tưởng để bắt đầu.
Thực hiện: Triển khai rel prev/next trên các liên kết phân trang.
Vấn đề 2: Cấu trúc phân trang
Những vấn đề: index chính xác, ngân sách thu thập dữ liệu, SERP CTR (tỷ lệ click trên trang kết quả tìm kiếm), lưu lượng dòng chảy.
Những năm gần đây, chúng tôi đã tập trung nhiều vào ngữ nghĩa HTML. Ban đầu, chúng tôi tập trung làm nội dung và các định dạng dễ dàng hơn khi nó được phân loại rõ ràng : ý nghĩa và nội dung của HTML, CSS là ngôn ngữ quy định cách trình bày của các thẻ HTML, còn Javascript cho hành vi bổ sung. Loại bỏ bất cứ điều gì trong HTML mà chỉ để trình bày là điều không quá khó khăn, nhưng để xác định đầy đủ ý nghĩa của nội dung với HTML gần như là không thể - HTML đơn giản không phải là một ngôn ngữ phong phú. Microformats (là công cụ để gia tăng giá trị của trang kết quả tìm kiếm) đã bắt đầu ngập lụt trong cố gắng để thêm vào một số những khoảng trống, nhưng thực tế HTML vẫn đang được sử dụng.
Một lần nữa, cuộc đột kích HTML5 để cứu vãn tình thế !Nó không đưa ra tất cả các câu trả lời nhưng nó cũng góp phần cung cấp toàn bộ các thẻ mới, chúng tôi có thể sử dụng để tổ chức nội dung của trang web và cung cấp cho Google và giúp đỡ các công cụ rất nhiều trong việc giải thích các trang web của chúng tôi. Một số thẻ bao gồm:
<section> <header> <footer> <article> <hgroup> <aside> <nav>
Đây chủ yếu liên quan đến những gì bạn mong muốn và tôi sẽ không mô tả chúng chi tiết ở đây. Nếu bạn muốn tìm hiểu thêm về chúng hãy vào trang web của w3schools và đi đến phần HTML5 Tag Reference (http://www.w3schools.com/html5/html5....1379862728793)
Tôi sẽ chỉ đưa ra một vài ví dụ...
Trước đây, bộ phận cấu thành của hầu hết các trang đã được tách ra với thẻ div:
<div id="myarticle"> ... </div> <div id="extrafacts"> ... </div>
Tuy nhiên, trong HTML5, chúng tôi có một mảng rộng hơn về các thẻ để gán ngữ nghĩa với các phần tử, do đó ví dụ tương tự có thể trông giống như sau:
<article> ... </article> <aside> ... </aside>
Ngay lập tức bạn sẽ thấy sự khác biệt – bây giờ bản thân các thẻ truyền một số thông tin về những gì mà chúng chứa.
Một ví dụ khác, chúng ta có thể cuộn trang lên trên để gọn gàng hơn, xem thẻ H1 truyền thống, và nhìn vào ví dụ này:
Thẻ H1 làm những gì trên trang này? Thực tế là không phải tất cả các trang không mượn thẻ này để chia với một tiêu đề chính. HTML5 sử dụng một cách tiếp cận hợp lý hơn và nhiều phần tử thẻ H1 trên một trang:
<section id="finance"> <header> <h1></h1> </header> ... <footer> </footer> </section> <section id="entertainment"> <header> <h1></h1> </header> ... <footer> </footer> </section>
HTML5 đủ thông minh để hiểu rằng các phần tử này là các tiêu đề và cuối trang là các thẻ cha mẹ của chúng.
Đối với SEO điều này làm cho cấu trúc một trang trở nên dễ dàng hơn đáng kể và cho một công cụ tìm kiếm, nó giúp các trang dễ dàng hơn để giải thích và index chính xác.
Làm thế nào Google xử lý tất cả những vấn đề này, vì vậy tôi muốn tư vấn cho bạn một cách tiếp cận thực tế tại thời điểm này. Nếu bạn không thấy thoải mái với các phần tử H1 thì bạn có thể sử dụng các phần tử khác. Có thể bạn sẽ thấy rằng với hầu hết các dự án đều có phần tử này.
Một điều cuối cùng trước khi bạn bắt đầu!
Với Firefox, Chrome của Safari, bạn sẽ có thể áp dụng CSS. Trong trình duyệt IE sẽ không đến được CSS mà không cần sự giúp đỡ. May mắn thay, có một số giải pháp hiện có trong mã nguồn mở html5shiv (http://code.google.com/p/html5shiv/?....1379862728793). Bạn hãy tải xuống và cài đặt nó, bạn sẽ thấy điều đó rất thú vị.
Hành động: Bắt đầu dần dần tái cấu trúc thiết kế trang của bạn để từ từ tích hợp với phần tử mới. Bắt đầu thay hoặc bổ sung các thẻ div tổng quát bằng các thẻ mới này.
Vấn đề 3: Tìm kiếm trang nội bộ
Vấn đề chính: index chính xác, nội dung trùng lặp, ngân sách thu thập dữ liệu.
Bây giờ nếu trang web của bạn có một tính năng tìm kiếm nội bộ trên trang, câu trả lời là nó sẽ được chặn với robots.txt và ngăn những cơn ác mộng khủng khiếp có thể xảy ra. Tuy nhiên, một số trang web pha trộn các tính năng tìm kiếm với hệ thống định vị lạ hoặc thậm chí sử dụng các kết quả tìm kiếm như một cách để liệt kê các loại sản phẩm nào đó để sau đó liên kết chúng lại. Giải pháp tốt nhất là để sửa chữa trang IA (kiến trúc thông tin) nhưng không phải lúc nào cũng làm được.
Hơn nữa, bạn có thể thấy rất nhiều người liên kết để tìm kiếm các trang kết quả và trong một số trường hợp bạn muốn chúng được index.
Vâng, HTML5 cung cấp một cách nhanh chóng và dễ dàng để cho Google biết những gì đang xảy ra…
<a href='/search.php' rel='search'>Search the site</a>
Điều này cho phép các công cụ tìm kiếm biết rằng trang mục tiêu là một công cụ tìm kiếm, và không lặp đi lặp lại nhưng đó là một tín hiệu thực sự hữu ích, công cụ tìm kiếm có thể cung cấp cho bạn và sẽ có tất cả 20 giây để thêm vào mỗi liên kết cần thiết. Trong khi bạn đang muốn kiểm tra opensearch.org cho phép một số công cụ mất đi một số thứ quan trọng – bao gồm cả trình duyệt để khám phá tính năng tìm kiếm và tích hợp trực tiếp vào thanh tìm kiếm các trình duyệt.
Hành động: thêm tìm kiếm rel cho tất cả các liên kết đối với bất kỳ tính năng tìm kiếm trên trang web.
Vấn đề 4: Microformats != schema.org
Vấn đề chính: chia sẻ xã hội, SERP CTR, rich snippets (đoạn thông tin đặc biệt)
Microformat và RDFa là hai hình thức máy nhúng thông tin dữ liệu có thể đọc được trang web, cả 2 hình thức này rất nổi tiếng trong cộng đồng SEO. Microformat và RDFa đã cho thấy sức hấp dẫn rõ rệt kể từ khi Google giới thiệu rich snippets vào năm 2009, điều này cho phép SEO thêm một số bling (lấp lánh) vào danh sách SERP của họ:
Microdata là một định dạng và là một phần đặc tả của HTML5, nhưng nó vẫn nằm trong cái bóng và nhiều người đã không nhìn thấy sự phổ biến của nó.
Gần đây đã có thông báo của schema.org từ Google, Bing và Yahoo. Cùng với sự kích động này đã gây ra một số nhầm lẫn với nhiều SEO, họ nghĩ đây là một định dạng mới.
Schema.org cho biết nó không phải là một định dạng hay là ngôn ngữ của riêng họ, nhưng nó thực sự là vốn từ vựng mà các công cụ tìm kiếm đều đã thống nhất và tôn trọng. Nó đưa ra các kiểu thực thể và các thuộc tính mà bạn có thể chèn vào các metadata trên trang web của bạn và đảm bảo rằng tất cả các công cụ tìm kiếm sẽ hiểu.
NHƯNG
Các từ vựng của schema.org chỉ dùng trong định dạng microdata.
Hiện tại, bạn không thể sử dụng nó với Microformats hay định dạng RDFa. Các công cụ tìm kiếm nói sẽ thay đổi khi nào chúng cảm thấy thích hợp, nhưng trong khi chờ đợi nếu bạn muốn tận dụng lợi thế các từ vựng của schema.org, bạn cần phải sử dụng microdata của HTML5.
schema.org đưa ra cách sử dụng chi tiết microdata (http://schema.org/docs/gs.html?__hst....1379969743570) và đặt nó trên trang web của bạn, do đó nó có thể đọc được.
May mắn là bạn không phải bắt buộc quyết định giữa các định dạng và Google đã xác nhận rằng nó OK các định dạng khác nhau trên cùng một trang web đánh dấu lên các metadata tương tự. Vì vậy, ngay cả khi bạn có Microformats hoặc RDFa, bạn vẫn có thể sử dụng Microdata của schema.org, và tôi khuyến khích bạn làm điều đó. Tôi tưởng tượng rằng Google bắt đầu cho thấy một ưu tiên cho metadata bằng cách sử dụng từ vựng của schema.org.
Hành động: bao gồm Microdata cùng Microformats và RDFa bạn đã có. Tìm kiếm thêm cơ hội để sử dụng định dạng này.
Vấn đề 5: AJAX và URL
Vấn đề chính: lập chỉ mục chính xác, chia sẻ xã hội, và lưu lượng dòng chảy
Đây là vấn đề khá nổi tiếng và rất nhiều SEO không thích. Các trang web AJAX rất tốt đối với người dùng và cải thiện trải nghiệm người dùng rất nhiều…cho đến thời điểm này người dùng cố gắng để đánh dấu trang web của họ đang mở hay gửi email cho một người nào đó, hay chia sẽ thông qua các phương tiện truyền thông xã hội hoặc sử dụng nút back, hoặc tìm trang trong lịch sử của họ vào ngày hôm sau.
Đơn giản là AJAX và SEO không bao giờ được thiết kế để kết hợp với nhau và bây giờ chúng tôi đang ở trong một thế giới mà mọi người muốn có cả hai. Nếu bạn làm cách nào đó quản lý để tránh xảy ra vấn đề này mà không nhận thức được là sau đó tôi sẽ phác thảo một thời gian ngắn về nó…AJAX cho phép một trang web thông qua việc sử dụng javascript, cập nhật các nội dung của một trang web mà không cần thiết phải tải lại trang, một yêu cầu mới từ http sẽ được gửi và nội dung mới có thể sẽ thay thế một số nội dung cũ trên trang web nhưng vì trang không tải lại nên URL không thay đổi.
Phương pháp truyền thống để giải quyết vấn đề này để đảm bảo Googlebot có thể thu thập nội dung chỉ đơn giản là các lời gọi AJAX được nối với thẻ <a> truyền thống để bạn có thể href đến cùng một nội dung mà Google sẽ nhận (và thậm chí điều này đã không được thực hiện thường xuyên – có nghĩa là nội dung bị mắc kẹt và sẽ không bao giờ được index). Điều này là tốt cho việc thu thập dữ liệu của SEO, nhưng ngày nay chúng ta cần phải xem xét thực tế là chia sẻ xã hội là một khía cạnh quan trọng trong SEO và nếu người dùng không thể sao chép và dán chính xác URL thì sau đó bạn sẽ gặp rất nhiều khó khăn.
Vì vậy, HTML5 đã xuất hiện để giải cứu tình huống này, nó cung cấp một số tính năng DOM mới mà chúng ta có thể sử dụng với javascript để tự động thay đổi URL trong thanh địa chỉ mà không cần tải lại trang. Đây là dưới dạng history.pushState () (https://developer.mozilla.org/en-US/...er_history)và phương thức (replaceState() & popState()):
var stateObj = { foo: "bar" };
history.pushState(stateObj, "page 2", "bar.html");
Không chỉ history.pushState () cho phép chúng ta cập nhật các URL mà nó còn đẩy các URL mới với các lịch sử trình duyệt, vì vậy người dùng có thể sử dụng nút back như mong muốn và tìm thấy những trang trong lịch sử của họ sau này.
Kiểm tra demo của HTML5 pushState (http://html5demos.com/history?__hstc....1379969743570).
Thật đáng tiếc, trình duyệt IE chưa hỗ trợ pushState thậm chí ngay cả với IE9, do đó bạn có thể hoàn toàn quên đi cách sử dụng. Bạn không thể làm việc trên IE nhưng nó sẽ hướng dẫn tích hợp với các trình duyệt khác mặc dù IE9 cho phép cải tiến các tính năng cho một số người dùng còn hơn là không có gì cả.
Hành động: nếu bạn được tham gia vào việc thiết kế một trang web AJAX thì bạn cần phải tích hợp giải pháp PushState. Và cũng cần phải xem xét tái cấu trúc nội dung AJAX bạn có.
Tổng hợp
HTML5 và các công nghệ liên quan là vô cùng thú vị cho SEO, người sử dụng và các trang web nói chung. Tuy nhiên, nó vẫn cần phải được nghiên cứu trong một thời gian dài trước khi có thể được triển khai rộng của nhiều tính năng chủ yếu là nhờ vào thực tế thậm chí phiên bản mới nhất của Internet Explorer cũng không cố gắng hỗ trợ một số tính năng.
Tuy nhiên trong thời gian đó, chắc chắn sẽ có những phần có thể được sử dụng cho SEO và các phần có thể được sử dụng cho tính năng người sử dụng và tôi khuyến khích tất cả mọi người áp dụng những tính năng này khi có thể. Nếu một số tính năng bạn muốn tung ra cho những người dùng trình duyệt hiện đại trong khi vẫn hỗ trợ người sử dụng phiên bản chưa đầy đủ, bạn nên kiểm tra phần mở rộng này của fallbacks HTML5 thông qua trình duyệt.
Trường hợp tiếp theo?
Về phần tôi, tôi luôn tự hỏi công cụ tìm kiếm sẽ làm gì để mở rộng các tiện ích khi HTML5 được áp dụng một cách phổ biển. Khi bài viết trên Google+ được hiển thị trong SERPs, chúng ta đang thấy một sự chuyển đồi từ “tìm kiếm web” nghĩa là tìm kiếm các trang web, và có thể hiểu rộng hơn đó là tìm kiếm thông tin trên web. Có lẽ, chúng ta sẽ sớm được sử dụng thuộc tính rel kinh điển trên <section> và < article>, loại thẻ này thực sự cho phép chúng ta có sự linh hoạt mà không bị nghi ngờ về nội dung trùng lặp.
Sau đó là WAI-ARIA (sáng kiến tiếp cận web - ứng dụng chạy trên Internet), một đặc tả kỹ thuật riêng đối với các ứng dụng web nhưng được ghi nhận trong HTML5. Với thuộc tính “role” chúng tôi đang hướng tới việc có thể để cho trình thu thập thông tin về hành vi của các trang web mà không phải chỉ có nội dung.
Tôi biết rõ là HTML5 đang đến, và mỗi SEO cần phải tăng tốc để tiếp nhận điều này. Nếu bây giờ bạn chưa sẵn sàng để tiếp nhận HTML5, nhưng đã triển khai một số khía cạnh khác của HTML5 thì bạn sẽ có một vị trí tốt trước khi HTML5 được sử dụng một phổ biến.
- Bài viết của Tom Anthony (Distilled).
Không có nhận xét nào:
Đăng nhận xét