Nội dung phần 3 bài phỏng vấn của Eric Enge với Matt Cutts (Googler).
>>Eric Enge phỏng vấn Matt Cutts (phần 2)
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.
Eric Enge: Thế còn về Pagerank Sculpting? Liệu những nhà xuất bản nên xem xét đến việc sử dụng link bằng Javascript hay là sử dụng liên kết bên trong iframe?
Matt Cutts: Lời khuyên của tôi trong trường hợp này cũng giống như ý tưởng về Pagerank Sculpting. Mặc dù trước đây chúng ta đã từng thảo luận rằng Pagerank Sculpting không phải là cách hữu hiệu nhất để hướng dẫn Googlebot crawl trong 1 site. Sở dĩ chúng tôi nói Pagerank Sculpting không phải là cách tốt nhất để tiết kiệm thời gian bởi lẽ thời gian đó nên dành để kiếm được nhiều đường dẫn và tạo ra được nhiều nội dung trong site của bạn.
Pagerank Sculpting sẽ lấy những Pagerank bạn đã có và cố chỉ dẫn nó tới những trang khác mà bạn nghĩ là sẽ hữu hiệu hơn và có rất nhiều cách tốt hơn để làm việc đó. Nếu bạn có một sản phẩm mang tới cho bạn nhiều giá trị thặng dư và sự chuyển biến, bạn có thể đặt nó ngay tại phần đầu hoặc phần giữa của trang. Rất nhiều Pagerank sẽ được chuyển từ liên kết đó tới trang sản phẩm.
Cấu trúc của trang là cách mà bạn tạo ra các liên kết và cấu trúc thể hiện trên một trang thu hút số lượng người nhiều nhất xem sản phẩm là cách hữu hiệu hơn để tiếp cận và sau đó thực hiện sculpting Pagerank tới các liên kết. Nếu bạn có thể cấu trúc lại site tập trung Pagerank vào những trang quan trọng nhất hoặc là trang mang lại cho bạn nhiều giá trị thặng dư nhất. Đó là một cách tốt hơn để sculpt trực tiếp sau đó dùng iFrame hoặc là Javascript đã được mã hóa.
Tôi cảm thấy rằng nếu bạn có thể tạo được cấu trúc của site ngay từ đầu sau đó bạn sẽ không phải lo lắng quá nhiều hoặc là không cần phải suy nghĩ về Pagerank Sculpting. Làm như vậy mọi thứ sẽ được rõ rang. Mọi người được khuyến khích rằng họ có thể làm bất cứ thứ gì họ muốn trên site của họ, nhưng theo kinh nghiệm của tôi, Pagerank Sculpting không phải là cách tốt nhất để mọi người giành thời gian.
Eric Enge: Tôi chỉ đưa ra một ví dụ về site với những vấn đề về faceted navigation và như tôi đã đề cập có một số lượng các trang đã không được index. Thực chất ở đây là muốn tìm cách để Googlebot không phải giành thời gian cho những trang mà không muốn có mặt trong index. Anh nghĩ như thế nào về vấn đề này?
Matt Cutts: Một ví dụ tốt nhất là hãy bắt đầu với những sản phẩm bán chạy nhất của anh, đặt chúng lên những trang đầu tiên và từ những trang có những sản phẩm này bạn có thể liên kết tới những trang có những sản phẩm bán chạy thứ 10 hoặc là hàng trăm. Mỗi sản phẩm có thể có 10 liên kết và mỗi liên kết này lại có thể dẫn tới 10 sản phẩm khác bán tốt tương tự như vậy. Hãy nghĩ tới những site như Youtube hay là Amazon, chúng đã làm rất tốt việc dẫn người xem tới những trang có liên quan hoặc những sản phẩm có liên quan mà họ muốn mua.
Nếu như bạn truy cập vào một trong số những trang này và bạn thấy một vài điều có vẻ tốt, bạn click vào và từ đây bạn thấy có 5 hoặc nhiều hơn những sản phẩm liên quan và hữu dụng. Bạn đã có thể dẫn người sử dụng và công cụ tìm kiếm thẳng tới sản phẩm quan trọng của bạn hơn là bắt đầu bằng faceted navigation phức tạp. Đấy là cách mà các site có thể tiến hành thử nghiệm và tìm ra cách làm việc nào hiệu quả nhất với họ.
Có rất nhiều cách để bạn có thể thực hiện cấu trúc của site hơn là sculpting Pagerank. Cách mà bạn nghĩ rằng bạn có thể tới được sản phẩm và khả thi để bán nó. Mọi người sẽ có xu hướng click vào nó nhiều hơn. Bạn cũng có thể phân phối Pagerank rất cẩn thận giữa các sản phẩm có liên quan và sử dụng những liên kết có liên quan này về thẳng trang có sản phẩm của họ hơn là phải thực hiện nhiều bước navigation. Tôi nghĩ rằng có rất nhiều cách làm như vậy mà không cần thiết phải sử dụng Sculpt pagerank.
(Còn tiếp)
