Phỏng vấn Matt Cutts – chuyên gia của Google (P3)

Matt Cutts: Vâng, gọi đó là 301 của 1 người đàn ông nghèo nàn cũng không phải là một điều quá tệ. Nếu như web server của bạn có thể thực hiện trực tiếp 301, bạn có thể thực hiện được điều đó, nhưng nếu bạn không có khả năng truy cập được vào web server hoặc là có quá nhiều khó khăn để thiết lập 301 thì bạn có thể thực hiện rel=canonical.

Đó là một điều hoàn toàn tốt cho một trang tự liên kết sử dụng rel=canonical, và với Google thì nó thật sự hữu ích để thực hiện rel=canonical với mọi trang trong site của bạn. Mọi người nghĩ rằng nó rất tiết kiệm nhưng thật ra không hẳn là như vậy. Chúng ra tự hỏi bản thân về một trường hợp mà mỗi trang trong một site đều dùng rel=canonical. Miễn là bạn quan tâm tới việc chúng sẽ dẫn tới được đúng trang và sẽ chẳng có vấn đề gì cả.

Eric Enge: Tôi nghĩ rằng tôi đã nghe thấy anh nói trong quá khứ rằng nó hơi mạnh để thực hiện một rel=canonical Chỉ dẫn. Về bản chất anh gọi nó là một lời gợi ý.

Matt Cutts: Vâng. Điển hình, đội crawl muốn coi những thứ đó như một lời gợi ý và phần lớn thời gian chúng tôi sử dụng chúng để quảng cáo. Nếu bạn gọi nó là một chỉ dẫn, thì bạn sẽ rơi vào tình trạng phải tuân theo chúng, nhưng đội crawl và index muốn giành chúng như một quyền sau cùng để quyết định nếu như mà người chủ site đang tự hại mình và không nghe theo rel=canonical tag. Phần lớn thời gian, mọi người sẽ thấy tác dụng của rel=canonical tag. Nếu chúng ta có thể nói rằng họ không có ý làm như vậy, chúng ta sẽ có thể lờ nó đi.

Eric Enge: Webmaster tools “bỏ qua những tham số” cũng giống như cách làm của canonical tag.

Matt Cutts: Vâng, về bản chất thì đúng là như vậy. Đó là một việc khá dễ chịu vì robots.txt có thể có bị cản đường bởi vì nếu bạn block một trang để nó không bị crawl thì chúng tôi sẽ không thể truy cập vào được. Chúng tôi sẽ không thể biết nó là một bản sao của trang khác. Nhưng nếu như bạn nói cho chúng tôi biết trên bảng điều khiển của webmaster tham số nào không cần thiết, chúng tôi có thể tận dụng được những thông tin đó.

Eric Enge: Hãy nói vể những file KML. Liệu có nên đặt những trang này vào robots.txt để tiết kiệm crawl budget?

“…nếu như bạn cố block một URL nào đó trong file robots.txt, chúng tôi thường sẽ nhận ra URL đó và giữ thông tin đó ở index của chúng tôi. Chính vì thế không cần thiết phải tiết kiệm crawl budget của bạn.”

Matt Cutts: Thông thường, tôi sẽ không khuyến nghị làm việc đó. Những lời khuyên hữu ích nhất sẽ do những chuyên gia crawl và đội index là để cho Google crawl những trang mà bạn quan tâm và chúng rôi sẽ cố loại bỏ những trang có nội dung trùng lặp. Bạn cũng có thể khắc phục vấn đề này với việc tạo cấu trúc site tốt hoặc dùng 301s. Nhưng nếu bạn cố block một vài URL bằng robots.txt, chúng tôi thường sẽ nhận ra URL đó và giữ chúng ở index của chúng tôi. Chính vì thế không cần thiết phải tiết kiệm crawl budget của bạn. Đó cũng là một điều thú vị vì Google sẽ cố crawl rất nhiều những trang khác nhau ngay cả những trang không phải HTML, và trong thực tế Google cũng sẽ crawl những file KML.

Điều chúng ta nên làm là để Googlebot crawl những trang này rồi loại bỏ sự trùng lặp. Hoặc nếu bạn có khả năng, bạn có thể sử dụng cấu trúc của trang để xử lý vấn đề trùng lặp trước đó. Nếu site của bạn 50% là file KML hoặc bạn có một lượng lớn không cân đối các fonts và bạn không muốn chúng được crawl, bạn có thể sử dụng robots.txt. Robots.txt cho phép wildcard chính vì thế bạn có thể block chúng. Hầu hết với các file HTML có một số trang mở rộng hoặc một số định dạng file khác, tôi khuyến nghị nên để Google crawl chúng.

Eric Enge: Google sẽ tránh được những mánh khoé nếu như tỷ lệ số “trang thực sự” ít.

Matt Cutts: Đúng như vậy

Eric Enge: Google có thực hiện yêu cầu HEAD (HEAD request) để phân loại nội đúng không?

Matt Cutts: Với những người không biết thì có rất nhiều cách để tiếp cận và kiểm tra nội dung. Nếu như bạn thực hiện một GET request web server sẽ trả lại nội dung. Nếu bạn thực hiện một HEAD request tức là bạn đang hỏi Webserver xem nội dung có gì thay đổi không. Web server chỉ phải trả lời có hoặc không và nó không thật sự phải gửi nội dung. Thoạt tiên, bạn có thể nghĩ rằng yêu cầu HEAD là một cách khá tốt cho công cụ tìm kiếm crawl web và chỉ truy cập vào những trang đã thay đổi từ lần crawl trước.

Tuy nhiên có vẻ như là hầu hết mọi web server phải làm việc chẳng có gì khác (so với GET) để tìm ra câu trả lời liệu những trang đó đã thay đổi hay chưa khi bạn thực hiện yêu cầu HEAD. Trong những thử nghiệm của chúng tôi, chúng tôi nhận ra rằng hầy hết các lần sẽ hiệu quả hơn khi thực hiện GET. Sẽ có một vài trường hợp chúng ta sẽ phải sử dụng tới HEAD. Ví dụ như, trong quá trình crawl hình ảnh, chúng ta có thể sử dụng yêu cầu HEAD bởi vì hình ảnh có thể lớn hơn rất nhiều so với trang nội .

Khi crawl web, nội dung text và HTML, chúng tôi sử dụng GET và không sử dụng yêu cầu HEAD trước. Chúng tôi vẫn dùng những thứ như If-Modified-Since để web server có thể cung cấp cho chúng tôi thông tin liệu trang đó đã thay đổi hay chưa. Vẫn còn rất nhiều cách khá thông minh để bạn có thể crawl web nhưng yêu cầu HEAD sẽ không tiết kiện được nhiều bandwidth khi crawl nội dung HTML mặc dù chúng tôi sử dụng chúng cho việc crawl nội dung hình ảnh.

Eric Enge: Và anh cũng có thể sử dụng chúng để crawl nội dung video đúng không?

Matt Cutts: Đúng, nhưng tôi sẽ phải kiểm tra lại điều đó.

Eric Enge: Mở rộng thêm phần bàn luận về faceted navigation, chúng tôi đã từng làm việc với 1 site có sự sắp xếp faceted navigation vô cùng phức tạp. Thật sự nó tạo ra “Trải nghiệm người dùng” khá tốt. Họ nhận thấy rất nhiều sự thay đổi sau khi thực hiện điều này trên site của họ. Kết quả là doanh thu trên một visitor tăng lên rất khả quan.

Matt Cutts: Hoàn toàn như vậy.

Eric Enge: Nhưng mặt khác, họ cũng nhận thấy số lượng những trang được index đã giảm đi đáng kể trên site. Có lẽ, về bản chất những trang này đã liệt kê những sản phẩm nhiều cách khác nhau.

Những trang đó không không phải những trang rich text và chúng ta không có nhiều thứ để crawl vì chúng giống như những trang có chất lượng kém hoặc là những trang trùng lặp. Vậy thế nào là cách tốt nhất để giải quyết vấn đề trên? Họ có nên ngăn chặn việc crawl những trang này không?

Matt Cutts: Trong một vài trường hợp, đối với các công cụ tìm kiếm faceted navigation có thể giống như mê cung bởi vì bạn có rất nhiều cách để chia nhỏ và tổ chức dữ liệu. Nếu như mà các công cụ tìm kiếm không thể vượt qua được các ma trận (mê cung?) để tìm được sản phẩm thực sự trên trang khác. Sau đó thỉnh thoảng có thể xảy ra những mánh khoé trên phương diện thuật toán để quyết định giá trị gia tăng của mỗi trang.

Trở lại với những lời khuyên trước đây mà tôi đã từng khuyến nghị, có một điều chúng ta nên nghĩ tới là nếu bạn có thể hạn chế số lượng các vấn đề hoặc là các mặt để có thể tìm được dữ liệu dễ dàng hơn và thỉnh thoảng sẽ giảm được sự nhầm lẫn. Đó là những điều đôi khi bạn nên xem xét. Nếu như có một category mặc định, một hệ thống cấp bậc mặc định hoặc một cách mà bạn nghĩ là hữu hiệu nhất hoặc thân thiện với người sử dụng nhất để thông qua. Đó có thể là một điều đáng thử.

Bạn có thể tưởng tượng cố gẳng thực hiện rel=canonical ở những trang faceted navigation này để đưa bạn trở về cách chuẩn mực của faceted navigation. Đó là một cách mà bạn có thể muốn thí nghiệm xem nó làm việc hiệu quả như thế nào. Tôi có thể tưởng tượng ra rằng nó có thể giúp hợp nhất những trang faceted này về một đường dẫn gồm rất nhiều những sản phẩm. Nhưng bạn cũng cần biết xem người sử dụng phản ứng thế nào

Eric Enge: Như vậy nếu Googlebot tới một site và nó nhận thấy 70% những trang đó đã được redirect hoặc được rel=canonical tới những trang khác, điều gì sẽ xảy ra? Khi anh gặp trường hợp như vậy, anh có giảm thời gian crawl những trang này không bởi vì anh đã nhìn thấy những tag đó trước đây?

Matt Cutts: Rel=canonical khó có thể ảnh hưởng tới điều đó nhưng thuật toán của chúng tôi cố crawl site đó để biết được độ hữu ích và giá trị của những trang đó. Nếu có một lượng lớn các trang chúng tôi cho rằng có giá trị thấp thì chúng tôi sẽ không crawl nhiều những trang của site đó, nhưng đó là sự độc lập của rel=canonical. Điều đó sẽ chỉ xảy ra với faceted navigation thường xuyên nếu tất cả những gì chúng ta thấy chỉ là liên kết và rất nhiều liên kết.

Đó là trường hợp khi mà các site cá nhân có thể muốn thí nghiệm với nhiều cách tiếp cận khác nhau. Tôi nghĩ rằng không có gì là sai khi bạn dùng rel=canonical để cố dẫn các công cụ tìm kiếm tới một đường dẫn mặc định khi đi qua các categories khác nhau. Bạn chỉ đang cố thử nghiệm và giảm lượng đường dẫn và đưa chúng trở về một cấu trúc đường dẫn logic hơn.

Eric Enge: Có vẻ như vẫn còn bất lợi ở đây. Những chuyên gia crawl giành rất nhiều thời gian ở những trang này không phải với mục đích index.

Matt Cutts: Đúng như vậy. Nếu như bạn nghĩ về điều đó, mọi cấp bậc và mọi cách bạn có thể chia nhỏ và tổ chức dữ liệu như một chiều khác mà trong đó các chuyên gia crawl có thể crawl toàn bộ các sản phẩm còn lại theo số lượng trang và những trang này có thể không có sản phẩm thực sự. Bạn vẫn có thể đi qua thành phố, màu sắc, giá cả hay bất cứ thứ gì. Bạn thật sự muốn hầu hết các trang của bạn có những sản phẩm thực sự với nhiều text. Nếu navigation của bạn phức tạp, có ít dữ liệu cho công cụ tìm kiếm tìm và index và đáp ứng yêu cầu của người sử dụng.

Rất nhiều lần, faceted navaigation giống như những cái bẫy (các lớp???) giữa người sử dụng, các công cụ tìm kiếm và sản phẩm thực. Đó là các tầng lớp với rất nhiều những trang khác nhau không dẫn bạn tới thẳng trang nội dung. Đôi lúc, đây là một điều vô cùng nan giải đối với các công cụ tìm kiếm và người sử dụng.

(Còn tiếp)

Leave a Reply

Your email address will not be published. Required fields are marked *