Eric Enge phỏng vấn Matt Cutts (phần 3)
Tiếp theo phần 1 và phần 2, mình xin chia sẻ tiếp phần 3 nội dung bài
phỏng vấn của Eric Enge với Matt Cutts (Googler).
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.
Phỏng vấn Matt Cutts (phần 1)
Phỏng vấn Matt Cutts (phần 2)
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.
