Hiển thị các bài đăng có nhãn chuyên gia seo. Hiển thị tất cả bài đăng
Hiển thị các bài đăng có nhãn chuyên gia seo. Hiển thị tất cả bài đăng

Thứ Hai, 2 tháng 7, 2012

Tầm quan trọng của cấu trúc internal link

Dịch vụ SEO là một trong những phần quan trọng cho chiến dịch Online Marketing mà bạn phải chuẩn bị trước khi thiết kế website. Khi internet tiếp tục phát triển hàng giờ , và có rất nhiều trang web xuất hiện nhiều hơn hàng ngày đang cạnh tranh nhau rất gay gắt nhằm có một vị trí hàng đầu trên các công cụ tìm kiếm; để có thể xuất hiện Top 10 trên các công cụ tìm kiếm, thì bạn phải có một chiến dịch SEO tổng thể và lâu dài.

Có rất nhiều câu hỏi về những cách xây backlink hiệu quả trong SEO , trong bài viết này, tôi xin đề cập về việc xây dựng backlinks từ bên ngoài và cấu trúc backlinks liên kết nội bộ . Nếu như vấn đề này vẫn còn liên quan và phổ biến đến ngày hôm nay (sau khi trải qua nhiều lần Google Panda Updated) ? Đặc biệt là các liên kết bên ngoài và cấu trúc liên kết nội bộ trong site đã thay đổi như thế nào sau khi có nhiều cập nhật mới mà Google đưa vào SEO?

Xây dựng backlink vấn là một việc làm phổ biến và quan trong mặc dù sau nhiều lần Google Panda Updated . Vấn đề hầu hết mọi người dường như cảm thấy backinks có hiệu quả thấp là vì họ đang liên kết thông qua các từ khóa không liên quan đến website hay các dịch vụ họ đang kinh doanh, liên kết với các trang web có cấu trúc site rất tệ , và backlinks không được da dạng hoặc chất lượng kém.

Sau đây là những gì tôi xin đưa ra dẫn chứng cho việc xây links cho các từ khóa không liên quan .

Nếu tôi có một trang web có nội dung dựa trên :
- Blue Widgets
- Dark Blue Widgets
- Small Dark Blue Widgets

Trước kia tôi chỉ cần dùng hàng loạt các từ khóa không liên quan đến nội dung làm anchor text, hiệu quả của việc này khá tốt và có hiệu ứng trong thời gian dài, còn bây giờ thì không còn hiệu quả nữa .

Vì thế tôi sẽ không xây dưng backlinks với những anchor text như sau, mặc dù những từ khóa này vẫn cùng một thể loại:
- Green Widgets
- Bright Pink Widgets

Tôi sẽ xây links theo các từ khóa sau:
- Widgets
- Where to buy blue widgets
- Dark blue widget reviews
- What is a widget
- Small and Big Dark Blue Widgets
Bạn phải xem xét thật kỹ để đặt anchor text ở dạng “phrases”, ý của tôi là sử dụng anchor text một cách rất than thiện và “natural” với SEs.




Chúng ta đang liên kết các nội dung liên qua có cùng chủ đề lại với nhau.
Trong ví dụ này, một bài viết với chủ đề là “Blue widgets” được liên kết với một bài viết “Dark Blue Widgets”, và bài viết này được liên kết với bài viết mới “Small Dark Blue Widgets” và cuối cùng bài viết này được liên kết lại với bài viết đầu tiên “Blue Widgets”

Bạn cũng có thể làm theo cách sau đây:



Một số người dùng cách này để xây dựng pagerank theo nhóm, nhưng tôi không quan tâm nhiều đến Pagerank.

Pagerank chỉ là một công cụ nhỏ mà trong thuật toán Google dùng để xác định một webpage có giá tri, nhưng nó sẽ biến mất sớm trong thời gian tới (cũng như Google PR Toolbar), vấn đề chủ yếu là thời gian.

External Links:

Nếu bạn muốn cạnh tranh với các đối thủ cho những từ khóa có lượng cạnh tranh cao, thì bạn phải xây dựng một lượng backlinks bên ngoài có giá trị, trỏ về site của bạn.

Bạn phải nhớ những điều sau đây:
* Backlinks phải đến từ nhiều nguồn khác nhau. Backlinks đa dạng sẽ tốt hơn nhiều so với 10k links cùng một dạng. Nếu bạn muốn bán hàng trong mùa cao điểm hoặc chào hàng một sản phẩm mới, thì bạn có thể nghĩ ngay đến Google Adwords.

* Để SEO có hiệu quả tốt, bạn phải tối ưu hóa onpage và offpage, internal links and external links một cách toàn diện.

* Hãy nhớ rằng không chỉ sử dụng môt từ hay cụm từ làm anchor text, bạn phải sử dụng nhiều từ khóa liên quan để làm anchor text.

*Xây dựng mạng lưới liên kết riêng trên các web freebie , các trang web của riêng bạn trên nhiều địa chỉ IP khác nhau , vv … ! Tránh xa hay hạn chế sử dụng Google Analytics và Google webmaster tools . Bạn có thể sử dụng Tool analytics này: Piwik.

* Tạo liên kết từ các social bookmark , press release , bài viết , blog , vẫn còn rất hiệu quả.


(Nguồn seopandaagency.org)

Google Penguin và mối bận tâm về SEO

Một thời gian sau khi Google Penguin ra đời, Google vui mừng vì thuật toán chống spam mới này đang hoàn thiện như dự định. Nhưng có một vài điều tổn hại do thuật toán này gây ra còn đang được cân nhắc cách khắc phục và vẫn còn những mối bận tâm về Negative SEO như một mối đe doạ. Matt Cutt, Trưởng nhóm Webspam của Google có đưa ra một số ý kiến trong một cuộc phỏng vấn như sau:

Penguin: "là một sự thành công"

Mục đích của bất kỳ lần cập nhật thuật toán là cải thiện kết quả tìm kiếm. Vậy, Penguin đã cải thiện như thế nào cho Google?

"Theo quan điểm của chúng tôi thì đây là một thành công" - Matt Cutt nói
Còn những kết quả bất thường thì sao?

Chắc chắn rằng ngay sau khi Peguin ra đời, người ta nhanh chóng dẫn ra các ví dụ về các kết quả dư thừa. Ví dụ như trang Viagra chính thức không được liệt kê trong khi những trang khác bị hack lại được liệt kê vào. Một trang website trống được liệt kê nhằm mục đích "kiếm tiền qua mạng" và có nhiều trang trống khác có thứ hạng cao. Các trang sao chép nội dung – Scamr sites thì được báo cáo là vượt thứ hạng so với những trang bị sao chép.
Vậy thì Penguin thành công như thế nào khi những loại trường hợp này xảy ra?

Matt Cutt nói rằng nhiều vấn đề đã có trước khi Penguin ra đời và những vấn đề này không phải do thuật toán chống spam mới này gây ra.

Thực tế, vấn đề của Viagra hiện giờ được xác định là vấn đề có trước khi Penguin ra đời. Do vậy, Penguin không gây ra vấn đề này.
Còn những khẳng định sai ở một số ít tình huống?

Những khẳng định sai trong trường hợp người ta thấy rằng trang của họ đã bị thuật toán Penguin đánh sai khi họ không làm spam?

Matt Cutt cho biết "Chúng tôi đã xem xét một vài tình huống cần điều tra thêm nhưng sự thay đổi này chưa có tác động như thuật toán Panda hay Florida"

Google cập nhật thuật toán Panda với mục đích loại bỏ những nội dung rác, nội dung copy, loại bỏ những website có thương hiệu kém vào năm ngoái. Thuật toán Florida là một cập nhật quan trọng của Google năm 2003 nhằm cải thiện chất lượng tìm kiếm.

Tôi đồng ý rằng cả hai thuật toán trên dường như có tác động tới nhiều trang hơn thuật toán Penguin. Tôi đưa ra quan điểm như vậy dựa trên việc theo dõi các phản ứng với tất cả các cập nhật này. Chắc chắn rằng không phải tất cả mọi người sẽ đồng ý với tôi. Điều này cũng như lời nhắc nhở thường xuyên rằng bất cứ trang nào bị rớt khỏi thứ hàng thì trang khác dành được thứ hạng. Các bạn ít khi nghe điều này từ những ai dành được thứ hạng.

Điểm mấu chốt ở đây là Google dường như tin rằng thuật toán Penguin thực sự tóm được những kẻ spam đúng theo ý định của Google.

Tại sao Spam vẫn "lọt lưới"

Chắc chắn khi tôi nhìn vào các báo cáo, tôi thường thấy spam là cốt lõi của nguyên nhân khiến ai đó bị rớt hạng. Nhưng nếu thuật toán Penguin có hiệu lực thì tại sao một vài trang rõ ràng spam vẫn lọt qua?

"Không có thuật toán nào là hoàn hảo cả. Khi chúng tôi muốn sự hoàn hảo, phương pháp thử nghiệm của chúng tôi là 'Làm những gì để có kết quả tốt hơn trước'" - Matt Cutt cho biết vậy.

Matt Cutt cũng giải thích rằng thuật toán Penguin được thiết kế hoàn toàn chính xác. Nó hoạt động chống lại các trang dính níu đến spam.Tuy một vài spam vẫn có thể lọt qua nhưng mặt tích cực của nó thì bạn lại có một số những khẳng định sai.
Bạn có thể khôi phục bằng cách nào?

Một trong số những khó khăn nhất với lần cập nhật này là nói cho mọi người biết cách khôi phục. Bất cứ trang nào nào bị Penguin đánh vào đều được tin là đang spam Google.

Trước kia, nếu bạn spam Google, người ta nói rằng bạn phải lưu khiếu nại bằng hình thức Reconsideration request. Tuy vậy, Google đã nói rõ rằng hình thức khiếu nại reconsideration request không giúp ích gì cho nhữn trang bị thuật toán Penguin đánh vào. Google cũng cho biết yêu cầu này sẽ tự khôi phục nếu họ xóa sạch spam.

Tuy nhiên, một trong những lý do chính tôi nhận thấy khi xem các trang bị thuật toán Penguin đánh vào có thể là do các trang này đang thực hiện các kết nối xấu. Mọi người đã sử dụng WordPress themes miễn phí (WordPress là một phần mềm mã nguồn mở miễn phí mà bất kỳ ai cũng có thể sử dụng để xây dựng một website hay blog) hoặc sử dụng các đường kết nối tương hỗ chất lượng kém, mua link hoặc tham gia vào các mạng kết nối như những mạng gần đây Google đang chống lại.

Vậy mọi người có thể tự thoát khỏi các mạng kết nối này như thế nào, nếu họ không có sự kiểm soát với các link này bây giờ?

"Có thể xóa sạch những link này" Matt Cutt nói như vậy đồng thời đưa ra đề nghị rằng mọi người nên xem xét lại hai video ông đã thực hiện về chủ đề này:

Xem clip: http://www.youtube.com/watch?v=ES01L4xjSXE
"Rút cục lại thì bạn hãy cố gắng giải quyết những gì bạn có thể làm được"

Hãy truy cập Penguin để cập nhật lại

Nếu bạn xóa sạch các thứ rồi thì bạn biết Penguin được cập nhật bằng cách nào? Một cách lý tưởng thì bạn sẽ xem lưu lượng từ phục hồi của Google để biết thời gian tới Penguin được cập nhật.

Điều này dẫn tới một điểm quan trọng khác. Đó là thuật toán Penguin cũng như Panda là một bộ lọc, đôi khi được làm mới. Thuật toán Penguin không hoạt động liên tục nhưng hơn thế nó được dùng để tag kiểu như spam ngoài phạm vi bộ lọc spam định kỳ của Google.

Có phải thuật toán Penguin là một sự trừng phạt rộng rãi các trang hoặc trang cụ thể nào đó giống như thuật toán Panda? Nhưng căn cứ vào việc Panda có ảnh hưởng rộng tới các trang thì tôi cho rằng giả định thuật toán Penguin cũng làm được như vậy là công bằng thôi.

Theo như Matt Cutt thì điều này có nghĩa là nếu một vài trang của trang web của bạn bị tưởng là giống Penguin, thì tất cả có thể cũng bị tưởng như vậy. Cũng như vậy, khôi phục nghĩa là xóa sạch spam. Nếu bạn đã xóa rồi và vẫn chưa khôi phục được thì cuối cùng bạn cần bắt đầu một trang mới.

Một bận tâm mới về SEO mang tính tiêu cực

Trước khi có thuật toán Penguin, buổi trò chuyện về "negative SEO" – SEO mang tính tiêu cục đều chưa đi đến đầu đến đũa. Kể từ sau đó, dường như nó càng tệ hơn. Tôi đã xem những website mà nghe có vẻ như ai đó đang bị nguy hiểm nghiêm trọng vì đối thủ cạnh tranh có thể hãm hại họ.

Cốt lõi những nỗi sợ hãi này dường như một loạt giả định hoàn hảo. Gần đây Google hướng tới một số mưu đồ kết nối. Điều này khiến một vài người mất lưu lượng. Google cũng đã gửi những cảnh báo về các trang có đường link “giả mạo” hoặc “bất thường”. Việc này đã tạo ra nhiều lo lắng hơn cho một số ai đó. Sau đó, Penguin Update xuất hiện và đánh các link này, khiến càng nhiều người mất lưu lượng vì họ bị thuật toán Penguin Update đánh vào hoặc là không còn hưởng lợi từ spam link đã bị quét.
Những thứ này tạo độ chín muồi để mọi người khẳng định rằng việc chỉ ra các link xấu ở một trang web có thể tổn hại nó. Nhưng như tôi đã viết trước đó thì mối bận tâm về SEO mang tính tiêu cực không còn mới. Các SEO mang tính tiêu cực đã có từ nhiều năm nay rồi. Dù vậy, chúng ta chưa nhận thấy nó là mối bận tâm lớn.

Google đã nói rằng không dễ dàng gì cho những kẻ khác gây hại một trang web và thực tế thì có vẻ chỉ là trường hợp hy hữu thôi. Nói cụ thể thì việc chỉ ra các link xấu ở một trang tốt có các dấu hiệu tốt giống như là đang cố gắng lây truyền bệnh dịch cho một cơ thể mà nó có kháng thể rồi. Những điều tốt đẹp có sức nặng hơn những điều xấu.

Matt Cutts nhấn mạnh lại rằng SEO mang tính tiêu cực này rất hiếm có. Ông cho biết “Chúng tôi đã nỗ lực làm việc rất nhiều để đảm bảo chắc chắn rằng một ai đó cũng không thể gây tổn thương tới người khác”

Đồng thời, Matt Cutts lưu ý những gì Google nói trước kia. Hầu hết 700.000 thông điệp Google gửi tới công chúng đầu năm nay không phải là về các mạng lưới link xấu. Một cách tình cờ thì các thông điệp này không được viết cùng một ngày. Hơn thế, nhiều trang có cả những hình thức phạt Algorithmic penalty (Hình thức phạt giống của thuật toán Panda) và Manual penalty (Phạt xem xét thủ công) có kèm theo chúng nhưng chưa bao giờ tiết lộ. Gần đây, Google đã quyết định mở ra những trang này.

Sau chiến dịch SEO mang tính tiêu cực là cảnh báo link

Chắc chắn, khi một thông điệp mới đưa ra, nó có thể dẫn tới trường hợp như của Dan Thies. Trang của anh ta bị một số nhằm vào để cố gắng phô trương các công việc SEO mang tính tiêu cực. Anh ta nhận được một cảnh báo link bất thường sau khi điều này xảy ra. Anh ta cũng bị rớt một vài thứ hạng. Đây phải chăng là bằng chứng các công việc của SEO mang tính tiêu cực?

Thies nói với tôi rằng thứ hạng anh ta mất có khả năng do những thay đổi mà bản thân anh ta tự tạo ra khi anh ta gỡ bỏ link qua tất cả các trang trên trang web của anh ta để quay trở về trang chủ của anh ấy. Sau khi phục hồi lại, anh ta nói với tôi là anh ấy đã dành lại được các thứ hạng của mình.

Anh ấy nói toàn bộ lưu lượng không tệ đi. Dường như nó không giống như những mối lo ngại rằng SEO mang tính tiêu cực là một đe dọa “tàng hình” vì nếu nó đã làm việc đủ để tag trang web của anh ta như một phần việc của Penguin Update thì đáng lẽ anh ấy bị rớt hạng khủng khiếp.

Còn cảnh báo link thì sao? Thies đã tin rằng cảnh báo link xuất hiện do nỗ lực của SEO mang tính tiêu cực. Quả là một điều đáng sợ. Anh ta cũng nói rằng anh ấy lưu 3 hình thức khiếu nại reconsideration request mà mỗi lần đều có thư phản hồi nói rằng không tìm thấy hoạt động spam nào. Có phải anh ấy bị đánh bởi một cảnh báo nhưng không có cái nào liên quan tới lệnh trừng phạt?

Tôi đã hỏi Matt Cutts về tình huống này nhưng ông từ chối bình luận về trường hợp cụ thể của Thies. Ông nói rằng thông thường thì một cảnh báo link là một thông báo trước về việc rớt thứ hạng. Nếu trang web cố định vấn đề rồi và thực hiện thao tác khiếu nại reconsideration request đủ nhanh thì có thể ngăn được khả năng rớt thứ hạng.

Giải tỏa một số những lo lắng

Tôi mong muốn chúng ta sẽ tiếp tục thảo luận về SEO mang tính tiêu cực này và tin chắc rằng nó cũng là mối bận tâm lớn cho bất cứ ai. Tôi đã tham gia một buổi thảo luận về Quyến sách SEO cũng rất đáng để đọc.

Khi việc mua link rẻ hơn bao giờ, chúng ta sẽ dễ thấy tại sao phải bận tâm, lo lắng. Những câu chuyện giả dụ như điều gì đã xảy ra với Thies hoặc người nhận được cảnh báo sau khi 24.000 link hiển thị được chỉ ra ở trang web của anh ta gây ra phiền toái.

Lại sau đó, người này đi cảnh báo sau khi rõ ràng là anh ta đã làm rớt thứ hạng bởi thuật toán Penguin. Các link SEO mang tính tiêu cực cũng thực sự gây ra sự rớt hạng này hay còn một cái gì đó nữa chăng? Nói theo cách phổ biến thì thật khó nói vì các trang thực sự thì lại không được cung cấp.

Phức tạp vấn đề hơn nữa, một vài người mà làm mất lưu lượng vì thuật toán Penguin có thể lại không phải là nạn nhân của lệnh trừng phạt. Hơn thế nữa, Google có thể đã ngừng cho phép một số link vượt qua độ tin cậy (pass credit) nếu những link này bị nghi là một phần của nỗ lực đẩy thứ hạng trang vi phạm điều luật SEO. Nếu các trang bị lệ thuộc nhiều vào các link giả mạo thì các trang này sẽ thấy rớt hạng chỉ vì độ tin cậy của link bị xuống cấp chứ không phải vì chúng phải chịu trừng phạt.

Tôi đã thấy rất nhiều người hiện giờ công khai mong ước cách “disvow – không chỉ ra các link ở website của họ. Google không có ý kiến gì về việc bổ sung thêm tính năng như vậy lúc này khi tôi hỏi về điều này. Chắc chắn tôi không chờ đợi nó bây giờ. Bạn cũng vậy thôi nếu bạn biết rằng bạn đã từng bị thuật toán Penguin đánh vào. Tôi sẽ làm những gì tôi có thể để xóa sạch các thứ đi.

Một đề nghị thú vị ngoài cuộc thảo luận về Quyển sách SEO là Google không nên trừng phạt các trang web vì chỉ ra các link xấu ở trong trang đó. Hãy bỏ qua các link này, đừng để các link này vượt qua độ tin cậy (pass credit). Đây là một đề nghị tuyệt vời nhằm xoa dịu mối lo lắng về SEO mang tính tiêu cực như tôi thường nói.

Source:sưu tầm từ các site dịch từ SearchEngineLand

Thứ Sáu, 18 tháng 5, 2012

Unnatural links là gì?


Ngày hôm qua, sau khi mình dịch bài Google Penguin xử lý nhiều blog WordPress chứa link ẩn trong plugins/themes, có một bạn đã hỏi mình về Unnatural Links. Vậy Unnatural Links là gì?

Unnatural Links dịch ra có nghĩa là những liên kết không tự nhiên hay các liên kết không bình thường. Thế nhưng mà như thế nào là liên kết không bình thường? Và đối với Google thì liên kết như thế nào là liên kết không bình thường? Để giải quyết vấn đề này chắc có lẽ không đơn giản chút nào.

Ở đây mình xin phép đưa một vài ý kiến cá nhân của mình về Unnatural Links, có thể ngay trong lúc viết bài này mình không hệ thống hết được toàn bộ các vấn đề và các hình thức Unnatural Links nhưng mình sẽ cập nhật thêm ở đây khi nhớ được hay tìm được thêm các thông tin mới.

Trước hết, để định nghĩa về Unnatural Links thì có lẽ trước hết chúng ta cần định nghĩa về Natrual Links trước, tức các liên kết tự nhiên. Vậy như thế nào là liên kết tự nhiên?

Nếu các bạn thường xuyên theo dõi các thông tin về SEO ở các trang nước ngoài, thì thấy tháng trước 04/2012, trước khi Google Penguin ra đời, Google đã tuyên bố sẽ có hình thức xử phạt các website làm SEO quá liều. Tuyên bố này đã khiến cho nhiều webmaster trên khắp thế giới cảm thấy hoang mang. Đồng thời cũng đã xảy ra nhiều cuộc thảo luận xung quanh vấn đề đại loại như Như thế nào là làm SEO quá liều?

Sau một thời gian, Matt Cutts cũng có một chút đính chính cho câu nói của mình nhằm để trấn an các webmaster làm SEO và làm web với mục đích chính là phục vụ người dùng, những người làm SEO mũ trắng (SEO white hat) thì không phải quá lo lắng về vấn đề này. Đoạn dưới đây tôi đã từng trích trong bài Google cập nhật chống webspam trên kết quả tìm kiếm.


“I think ‘over-optimization’ wasn’t the best description, because it blurred the distinction between white hat SEO and webspam. This change is targeted at webspam, not SEO, and we tried to make that fact more clear in the blog post,” Cutts told me.
Nói tóm lại, Google chỉ đơn thuần là cải tiến thuật toán của họ để có thể phân tích các website tốt hơn nhằm hạn chế tình trạng spam với mục đích SEO và làm SEO trái với Google Webmaster Guidelines. Trong đó, các liên kết thiếu tự nhiên được xây dựng cũng là vấn đề mà Google cũng áp dụng đối với thuật toán của Google Penguin.

Trở lại vấn đề như thế nào là liên kết tự nhiên (Natural Links)? Trước hết, tôi nghĩ chúng ta cần quên đi khái niệm SEO để tìm hiểu về thuật ngữ này. Theo tôi, liên kết tự nhiên là những liên kết thường được chia sẻ bởi những người dùng thông thường. Mà người dùng thông thường thì thường hay có các thói quen chia sẻ liên kết như sau:

Chỉ copy URL trên thanh address sau đó paste vào nơi cần chia sẻ mà không làm các Anchor Text như người làm SEO vẫn thường hay làm. Ví dụ như tôi là một người dùng bình thường và khi tham gia các diễn đàn, có người hỏi về dịch vụ SEO, tôi biết được một dịch vụ SEO uy tín và tôi vào website đó để lấy đường dẫn chia sẻ thì tôi sẽ chia sẻ theo dạng là đường dẫn: http://www.vietsol.net/dich-vu-seo/ thay vì Dịch vụ SEO.
Vẫn có một số người dùng rành các tính năng sử dụng web và sử dụng tạo Anchor Text để bài viết gọn gàng và dễ nhìn hơn. Tuy nhiên, nếu như liên kết được chia sẻ theo dạng này thì thường các Anchor Text sẽ không cố định như một người làm SEO có target từ khóa rõ ràng. Bạn có thể xem một ví dụ dưới đây tôi trích lại trong bài Lỗi Google Classifier for parked domain là gì?

Vào khoảng ngày 20/04/2012, hàng loạt các website đang đứng ở thứ hạng cao bất ngờ bị rớt hạng. Điều này đã làm rất nhiều các webmaster trên thế giới không khỏi cảm thấy bất ngờ. Lúc đầu, ngay cả các chuyên gia còn lầm tưởng có lẽ là do Google cập nhật Google Panda phiên bản mới hoặc Google tiến hành xử phạt các website làm SEO quá liều. Tuy nhiên, ngay sau đó, Matt Cutts, người đại diện của Google giao tiếp với các webmaster đã xác nhận trên Google+ đây không phải là cập nhật Google Panda và xử phạt các website làm SEO quá liều mà là do lỗi thuật toán Classifier for parked domain.
Ở đoạn trích trên các bạn thấy rằng cụm từ “các website đang đứng ở thứ hạng cao bất ngờ bị rớt hạng” tôi link đến bài Biến động của Google ngày 20/04/2012.

Và như thế, những hình thức tạo ra các liên kết thiếu tự nhiên được gọi là Unnatural Links. Vậy, Unnatural Links có những hình thức nào? Dưới đây tôi xin phép liệt kê ra một số hình thức của nó:

Trao đổi liên kết – Exchange Links

Vì mục đích SEO và tăng thứ hạng website các webmaster thường hay trao đổi liên kết với nhau để tăng chỉ số Goolge PageRank và đẩy thứ hạng cho từ khóa nào đó. Với hình thức trao đổi liên kết, lượng backlinks của một website tham gia trao đổi liên kết sẽ bỗng dưng tăng lên một cách đột biến với số lượng nhiều trong một thời gian ngắn.

Hiện nay, phổ biến có các hình thức trao đổi liên kết như: trao đổi một chiều, trao đổi hai chiều, trao đổi chéo. Hầu hết các hình thức này đều dẫn đến kết quả là một website sẽ có lượng liên kết tăng đột biến trong thời gian ngắn. Và điểm đặc biệt nữa là các website này đa phần đều dùng chung một Anchor Text.

Đến đây, có lẽ sẽ có một câu hỏi phản biện đại khái như: Vậy nếu như một Webmaster thấy có một website nào đó hữu ích và đặt liên kết đến website đó nhằm để giới thiệu thêm thông tin hữu ích đến với người dùng của mình ở mục Liên kết hữu ích thì sao?

Theo tôi thì thông thường các hình thức liên kết tự nhiên sẽ là liên kết đến trang chủ thay vì liên kết đến các landing page như người làm SEO thường làm. Ngoài ra, thường các website trao đổi liên kết với nhau vì mục đích tăng Google PageRank thường là thiếu tương thích về nội dung. Ví dụ như: một website về thời trang liên kết với website bán linh kiện điện tử, một website làm về nông sản liên kết với một website cung cấp các thông tin về công nghệ thông tin,…

Các hình thức trao đổi liên kết thường được các Webmaster đặt ở khu vực khuất, khó nhìn thấy hay đặt tít tận dưới footer các website. Vì vậy, những liên kết dạng này chẳng những không có độ liên quan mà người dùng còn khó thấy, khó đọc bởi vì có quá nhiều liên kết trong một khu vực hẹp. Từ đó dẫn đến việc các liên kết này có độ tương tác thấp.

Mua liên kết – Paid Links

Đây cũng là hình thức tương tự như hình thức trao đổi liên kết, đây có thể xem tương tự như hình thức trao đổi liên kết một chiều. Tuy nhiên, hình thức này có lẽ chỉ đa phần là từ các website bán Text Links ở Việt Nam. Phần lớn các website bán Text Links ở nước ngoài bởi các dịch vụ bán Text Links chuyên nghiệp có hơi khác chút. Đó là khi bạn mua liên kết thì thường mỗi website chỉ đặt liên kết ở duy nhất một trang và đặt trên nhiều website.

Và như vậy, tất nhiên hình thức mua liên kết giống trao đổi liên kết một chiều cũng sẽ có hình thức bị phạt tương tự. Hình thức mua Text Links ở nước ngoài có lẽ sẽ khó khăn hơn đối với Google trong việc phát hiện mua Text Links. Nhưng nếu Google phát hiện ra được hệ thống website bán Text Links thì website của bạn cũng không tránh khỏi bị phạt.

Việc xử lý những website mua Text Links là điều mà Google luôn nổ lực để khắc phục trong nhiều năm qua.

Liên kết từ các Blog Network

Đây là một hình thức cũng rất khó phát hiện. Đã có khá nhiều doanh nghiệp làm SEO bằng hình thức tạo ra nhiều blog vệ tinh để viết bài rồi tăng lượng liên kết đến các website của mình. Ngoài ra, cũng có các doanh nghiệp thuê các blogger viết bài và đặt liên kết trong bài viết đến các website theo yêu cầu của mình.

Hình thức này không chỉ được xem là việc tạo ra những liên kết thiếu tự nhiên mà những nội dung trên các hệ thống blog này còn được liệt vào dạng nội dung farm, những nội dung kém chất lượng. Về nội dung farm và kém chất lượng thì năm vừa rồi Google cũng đã làm rất tốt với Google Panda.

Ngoài ra, vừa rồi, nếu bạn thường xuyên cập nhật các thông tin về SEO có lẽ cũng biết thông tin về Google xử phạt một số hệ thống Blog Network tạo ra nhiều nội dung kém chất lượng.

Lời kết

Tóm lại, Unnatural Links là những liên kết thiếu tự nhiên, không giống như những liên kết tự nhiên được chia sẻ bởi những người dùng thông thường. Có thể vẫn còn khá nhiều hình thức tạo ra liên kết thiếu tự nhiên khác. Các liên kết thiếu tự nhiên này thường có các thuộc tính sau:

1. Lượng liên kết tăng đột biến trong một thời gian ngắn.
2. Phần lớn các liên kết đến một trang nào đó đều dùng chung một Anchor Text với từ khóa mà các webmaster hướng đến để làm SEO.
3. Có nhiều liên kết đặt trên các website có nội dung hay chủ đề không phù hợp.
4. Thường là các liên kết đến landing page mà các webmaster hướng đến cho việc làm SEO.
5. Các liên kết này có tính tương tác thấp.

Theo blog babywolfvn

Thứ Năm, 10 tháng 5, 2012

Thuật toán mới của Google ảnh hưởng đến các website Việt Nam?

Đầu tháng, Google tuyên bố thay đổi mạnh mẽ ở thuật toán (Panda) nhằm trong sạch hóa danh sách kết quả tìm kiếm trả về, công bằng, có ích hơn với người sử dụng. Trong lần cập nhật này, các website sản xuất nội dung gốc được ưu tiên xuất hiện ở vị trí cao hơn trong danh sách tìm kiếm trả về. Ngược lại, các website nội dung thấp, đặc biệt là các website dạng “content farm”, tức là website sao chép nội dung từ các địa chỉ khác sẽ bị thẳng tay đẩy xuống dưới.

Matt Cutts, chuyên gia cấp cao của Google cho biết hãng đã mất gần một năm nghiên cứu trước khi đưa ra thuật toán mới, lần thay đổi này tác động đến khoảng 11,8% các truy vấn tìm kiếm. "Chúng tôi luôn cố gắng nâng cao vị trí của những website xứng đáng. Trang web nào chất lượng đáng được nhìn nhận ưu ái hơn so với những trang ‘ăn theo.’ Đó là những gì lần thay đổi thuật toán này nhắm đến."



Thực tế, theo nhiều nhận định thì thay đổi lần này của Google là tất yếu. Sau lần cập nhật thuật toán lớn Caffein năm 2009, các nội dung hời hợt, nội dung thấp dễ dàng xuất hiện trong top đầu kết quả tìm kiếm mà Google trả về, gây khó khăn cho người sử dụng. Tuy nhiên, sự thay đổi của Google vẫn đang gây ra nhiều tranh cãi, quan điểm xuất phát từ hai nhóm, những người hưởng lợi từ thuật toán của Google và những người bị thiệt. (lưu lượng truy cập từ Google chiếm một phần quan trọng trong tổng lưu lượng truy cập vào một website).

Bước đầu đã có các tác động đến các website Việt Nam

Sau một thời gian áp dụng, phía cộng đồng người làm SEO tại Việt Nam cũng bắt đầu nhận thấy sự ảnh hưởng của thuật toán mới. Ông Nguyễn Văn Tuấn, trưởng bộ phận Thương mại điện tử công ty VCCorp cho biết: “Thuật toán mới của Google có vẻ đang tác động ít nhiều đến hệ thống các website Việt Nam. Các nhóm từ khóa “hot” về nhà đất như bat dong san, mua ban nha dat, bất động sản... cho thấy sự dịch chuyển về thứ hạng các website trong danh sách tìm kiếm trả về.”

Anh Duy Nhân, quản trị Câu lạc bộ Webmaster Việt Nam cũng cho biết: “Cộng đồng SEO trong nước gần đây ghi nhận không ít trường hợp bị tụt thứ hạng website ở một hoặc nhiều từ khóa.” Trên diễn đàn thegioiseo, ddth... cũng có thể thấy nhiều trường hợp thành viên kêu ca bị rớt hạng từ khóa, mất lưu lượng truy cập (traffic) sau khi Google mạnh tay cải tổ công cụ tìm kiếm.

Ngược lại, một số ý kiến khác lại hoanh nghênh, cho rằng chính sách của Google đang tác động tích cực đến hiệu quả làm SEO của mình. Ví dụ trường hợp của GOMM, công ty này (có trụ sở tại TP Hồ Chí Minh) cho biết nhiều website đang được họ xây dựng và quản trị đã tăng đột biến lượng truy cập trong thời gian qua, có những site trung bình khoảng 10.000 visit/ ngày nay đã tới 19.000 visit/ ngày.

Ông Nguyễn Văn Tuấn cũng khẳng định: “Một vài website trong hệ thống Thương mại điện tử của VCCorp, như rongbay.com cũng nhận thấy visit có được từ Google thể hiện dấu hiệu tăng trưởng, theo kinh nghiệm của tôi thì nguyên nhân phần nhiều ở sự thay đổi thuật toán”.

Như vậy, có thể thấy sự lần cập nhật thuật toán mới của Google sau một thời gian ngắn đã gây ra các tác động đến hệ thống website trong nước. Tuy nhiên, điều khiến nhiều người quan tâm là số phận các website dạng "content farm" tại Việt Nam thì ở thời điểm này vẫn khó có thể đánh giác chính xác.

Ở Việt Nam, website dạng này không hiếm và một trong số đó còn đạt được thứ hạng rất cao ở nhiều từ khóa. Lý giải hợp lý theo ông Tuấn vì Google chưa áp dụng triệt để chính sách mới ở các thị trường nhỏ, cần thêm thời gian nữa để chúng ta chứng kiến sự “trừng phạt” với các content farm tại Việt Nam. Trên thế giới, thời gian qua, nhiều website lớn dạng này đã tụt hạng thê thảm, điển hình như Suite101.com (traffic từ từ Google giảm 94%).

Giới làm SEO “mũ trắng” hưởng ứng thuật toán mới

Chiến dịch cải tổ lần này của Google nhằm tuyên chiến với vấn nạn sao chép nội dung và xây dựng website nội dung thấp. Số lượng website “rác” dạng này trong vài năm qua sản sinh ra quá nhiều và không ít trong số chúng chen được lên vị trí cao trong danh sách kết quả tìm kiếm trả về. Ghi nhận trên nhiều diễn đàn, chính người dùng Việt Nam thời gian gần đây cũng đang tỏ ra khá khó chịu khi truy cập nhầm các website “rác” dạng này (xin không nêu tên cụ thể).

Nội dung luôn là một trong các yếu tố hàng đầu quyết định hiệu quả SEO (Content is King) nhưng khác với quan điểm trước đây (site càng nhiều nội dung càng tốt), Google giờ đã đẩy mạnh cả đánh giá về chất lượng. Bạn khó mà qua mặt được hệ thống xếp hạng nếu website có lượng nội dung dày đặc nhưng giá trị hời hợt và chủ yếu đi sao chép từ nhiều nơi.


Một bộ phận người xây dựng site dạng content farm, nội dung thấp, sử dụng các thủ thuật SEO để câu traffic từ Google không sớm hay muộn cũng sẽ chịu “hình phạt”. Ngược lại, nhưng người làm SEO "mũ trắng", tuân thủ đúng các quy tắc “chơi đẹp” từ Google và chú trọng đến việc sản xuất nội dung gần thì tiếp tục gặt hái thành công.

Một điểm chưa được làm rõ trong thông tin mà Google cung cấp là định nghĩa chính xác về website “nội dung thấp”. Ngoài ra, “Tần xuất index dữ liệu của Google đối với các site khác nhau là khác nhau, vậy đâu có thể chắc chắn được website nào sao chép nội dung, website nào tự sản xuất?” - nhiều người dùng thắc mắc. Tuy nhiên, theo ông Tuấn và nhiều chuyên gia khác thì: “Google không thiếu các công cụ và chỉ số để đánh giá đâu là website thấp, website copy nội dung. Google hiểu hơn ai hết điều này và chắc chắn phải có phương án công bằng trước khi áp dụng.” Bên cạnh đó, việc kêu gọi phản hồi trực tiếp từ người dùng cũng là một kênh tham khảo giá trị.

Chính vì vậy, những người hoạt động chân chính trong ngành SEO Việt Nam đa phần đều cho rằng sự thay đổi thuật toán của Google là cần thiết và đáng hoan nghênh.

“Ở vai trò một người xây dựng website theo khuynh hướng mang lại cái lợi cho người dùng, tôi và các bạn hoan nghênh những thay đổi của Google nhằm làm môi trường tìm kiếm được trong sạch hơn, bớt "rác" hơn đồng thời mang đến cho việc SEO những thách thức mới đòi hỏi người làm SEO phải sử dụng cái đầu nhiều hơn, cập nhật thông tin liên tục hơn.” - Anh Duy Nhân chia sẻ.

Công bằng hơn trong đánh giá thứ hạng website, kết quả trả về phản ảnh đúng nỗ lực xây dựng nội dung và chiến lược SEO thông minh. Hưởng lợi từ thuật toán mới của Google ngoài giới SEO “mũ trắng” còn là chính những người dùng cuối. Vì thế, hơn lúc nào hết, Google đang cho thấy nỗ lực củng cố vị trí số một về tìm kiếm của mình trong mắt người dùng internet.

Theo Genk

Thứ Năm, 3 tháng 5, 2012

Cách hiển thị logo trên trang kết quả tìm kiếm của Google

Có 1 số bạn hỏi tôi qua email và Yahoo về cách hiển thị logo trên trang kết quả tìm kiếm của Google, tôi có trả lời "bạn thử tìm hiểu về Rich Snippets của Google, chắc chắn bạn sẽ làm được". Mục đích câu trả lời của tôi là để các bạn tự tìm hiểu sẽ giúp các bạn có kinh nghiệm và hiểu rõ về nó hơn mà thôi. Nay tôi viết bài hướng dẫn này để giúp các bạn hiểu và có thể tự làm được, khi đọc xong bạn sẽ thấy nó chẳng có gì cao siêu và khó khăn cả.



Đầu tiên chúng ta cần tìm hiểu về thuật ngữ Snippets

Snippets là gì? Snippets là những dòng nội dung xuất hiện trong kết quả tìm kiếm và nằm dưới tiêu đề. Snippets được thiết kế để cung cấp cho người dùng biết những gì có trên trang web và tại sao nó liên quan đến truy vấn tìm kiếm của họ.
(Bạn có thể tham khảo thêm về Snippets tại đây: http://support.google.com/webmasters...p;answer=99170)

Quay lại vấn đề chính, để hiển thị được Logo hoặc hình ảnh bất kỳ trang kết quả tìm kiếm của Google, bạn có thể sử dụng một trong hai cách sau sau:

1. Hiển thị thông tin tác giả trên công cụ tìm kiếm

Với cách hiển thị thông tin tác giả trên công cụ tìm kiếm, chỉ hiển thị được trên Google.com, hiện tại Google.com.vn chưa hỗ trợ hiển thị thông tin tác giả này, vì thế tôi sẽ không hướng dẫn cách thêm phần thông tin tác giả này vào website của bạn. Bạn có thể tìm hiểu thêm về nó rất đơn giản tại đây: http://support.google.com/webmasters...answer=1408986


Hiển thị thông tin tác giả trên công cụ tìm kiếm

2. Rich Snippets Recipes

Rich Snippets Recipes thực ra được Google thiết kế để hỗ trợ cho các trang web cung cấp các thực đơn về các món ăn, cách chế biến, thành phần của các món ăn đó và kèm cả hình ảnh của nó nữa...
Lợi dụng đặc điểm là có hỗ trợ hình ảnh trên kết quả tìm kiếm nên một số webmaster đã ứng dụng nó vào website của mình và họ đã thành công, "bước đầu qua mặt được Google". Khi bạn đọc đến đây chắc bạn đã hiểu được một phần vấn đề, vì vậy tôi khuyên các bạn nên bỏ ý định thực hiện việc này, vì nếu bạn đọc tiếp, bạn sẽ tò mò và muốn làm thử cho bằng được. Tôi đã cảnh báo rồi nhé, đọc tiếp hay không là quyền của bạn thôi.

Mỗi Rich Snippets (RS) đều có 3 định dạng khác nhau đó là: Microdata, Microformats, RDFa. Ở bài này tôi sẽ cung cấp cho các bạn code và cách sử dụng Microdata cho RS Recipes.

Đây là đoạn code để hiển thị Logo trên Google:

<div style="margin-top: -1px; position: fixed; text-indent: -99999px;" itemscope itemtype="http://data-vocabulary.org/Recipe" >
<h1 itemprop="name">Tên công ty của bạn</h1>
<img itemprop="photo" src="http://ngocchinh.com/wp-content/themes/ngocchinh/images/logo.png" />
By <span itemprop="author">Trần Ngọc Chính</span>
<span itemprop="summary">Mô tả về công ty bạn</span>
<span itemprop="review" itemscope itemtype="http://data-vocabulary.org/Review-aggregate">
<span itemprop="rating">4.5</span> sao trên
<span itemprop="count">912</span>người dùng</span>
</span>
</div> 
 
Các bạn chỉ cần sửa lại tên công ty, đường dẫn đến Logo của bạn, thông tin Author và mô tả. Sau đó bạn có thể copy đoạn code này đặt vào website của bạn.

Ở hình dưới tôi đã thay thế các thông tin trong code trên để có thể hiển thị logo trên Google, bạn cũng có thể kiểm tra tại công cụ Rich Snippets Testing Tool tại đường dẫn sau: http://www.google.com/webmasters/tools/richsnippets


Rich Snippets Recipes cho trang InboundMarketing.vn

Nếu thấy kết quả của bạn hiện ra Logo là bạn đã làm đúng. Việc còn lại là ngồi chờ Google update website của bạn, thông thường khoảng 2 ngày là bạn sẽ nhìn thấy được kết quả trên công cụ tìm kiếm.

Ngoài ra bạn có thể sử dụng định dạng Microformats và RDFa để thực hiện, code cũng gần giống nhau, bạn tham khảo thêm tại: http://support.google.com/webmasters...;answer=173379

Chúc các bạn thành công !

P/s: Mặc dù biết tác dụng của nó sẽ làm đẹp kết quả tìm kiếm của bạn, quảng cáo thêm cho logo hoặc hình ảnh sản phẩm của công ty bạn, tăng tỷ lệ click chuột CTR vào website của bạn, nhưng tôi không khuyến khích các bạn thêm vào website của mình (ngoại trừ trang web của bạn là website cung cấp các công thức chế biến món ăn...) và dừng lại ở mức đọc để hiểu thêm về việc ứng dụng các Snippets mà thôi.


(Nguồn: Ngocchinh.com)

Thứ Năm, 26 tháng 4, 2012

Eric Enge phỏng vấn Matt Cutts (phần cuối)

Nội dung bài phỏng vấn của Eric Enge với Matt Cutts (Phần cuối).

>>Eric Enge phỏng vấn Matt Cutts (phần 2)
Eric Enge: Nếu ai đó chọn cách làm như vậy (sử dụng link mã hoá bằng JavaScript hoặc là iFrame) liệu những thứ đó có bị coi là hành động spam không hoặc đơn giản chỉ là công việc tiêu tốn thời gian của họ?
“..sự thay đổi căn bản NoFollow để thực hiện Pagerank Sculpting ít hiệu quả hơn thì cuối cùng cũng có một phần nào đó được thúc đẩy bởi vì chất lượng tìm kiếm mà mọi người tham gia vốn là để thấy được những linkage giống nhau hoặc tương tự như thế đối với người sử dụng cũng như là công cụ tìm kiếm.”
Matt Cutts: Tôi không chắc rằng hành động đó có bị coi là spam không nhưng sự thay đổi căn bản NoFollow làm cho Pagerank Sculpting ít hiệu hơn, ít nhất là trong việc thúc đẩy chấtl lượng tìm kiếm. Bởi vì những người dùng muốn nhìn thấy kết quả search tốt giống như là đối với SE. Nói chung, tôi nghĩ bạn sẽ muốn SE đi đến những nơi mà người dùng sẽ đi đến.
Trong một vài trường hợp, Tôi nghĩ rằng Pagerank Sculpting cố gắng tách các nội dung đó ra. Giả sử bạn đang suy nghĩ về điều này, bạn sẽ tự hỏi tại sao bạn muốn tách ra và gửi bots tới nhiều trang khác nhau hơn là người dùng làm. Theo kinh nghiệm của tôi, chúng tôi thực sự muốn bots của chúng tôi ở trong những trang giống nhau và về cơ bản là cùng một hướng như các công cụ tìm kiếm và người sử dụng. Tôi có thể tưởng tượng rằng nếu iFrame hoặc là Javascript kỳ lạ nào đấy lan tràn khắp nơi tới mức nó có thể ảnh hưởng tới chất lượng của việc tìm kiếm, chúng tôi có thể sẽ that đổi cách mà Pagerank có thể được tính qua những loại liên kết này.
Chính vì thể chúng ta không cần thiết phải coi chúng là những spam, chúng ta đều rất muốn những liên kết và những trang mà công cụ tìm kiếm có thể tìm thấy ở trong cùng một khu vực và cùng một chất lượng giống như những liên kết và trang mà người dùng sẽ tìm thấy khi họ vào site đó.
Eric Enge: Thế còn những file PDF thì sao?
Matt Cutts: Chúng tôi hoàn toàn vẫn xử lý các file PDF. Tôi sẽ không nói về việc liệu những liên kết ở file PDF có thể qua được Pagerank. Nhưng một cách tốt nhất để để hình dung về file PDF là coi chúng giống như Flash mà chúng không giống như file format có tác động tích cực và cố hữu đối với các web, nhưng chúng cũng có thể rất hữu dụng. Chúng tôi cũng cố tìm những nội dung hữu ích trong Flash file và trong PDF file. Tuy nhiên, người sử dụng thì không muốn nhận được file PDF. Nếu như bạn có thể tạo được nội dung ở dạng file thông thường như là HTML thì sẽ hữu ích với người dùng hơn là PDF.
Eric Enge: Có một trường hợp, người sử dụng tạo ta một file nhưng họ không muốn file đó bị chỉnh sửa nhưng họ vẫn muốn người khác có thể sử dụng và góp ý giống như eBook.
Matt Cutts: Tôi không nghĩ rằng chúng ta có thể index password bảo vệ PDF files. Một vài file PDF là hình ảnh. Tuy nhiên có một vài trường hợp mà trong đó chúng ta có thể chạy OCR trên PDF.
Eric Enge: Nếu như bạn có một file PDF là văn bản chứ không phải hình ảnh?
Matt Cutts: Mọi người hoàn toàn có thể làm như vậy nếu họ muốn nhưng tôi nghĩ rằng PDF là điều cuối cùng mà người ta mắc phải và thường mất một ít thời gian để mở nó. Mọi người cũng nên cân nhắc việc này sẽ có tác dụng như thế nào đối với kinh nghiệm của họ.
Eric Enge: Với cách xử lý JavaScript mới, các bạn (Google) thật sự đang làm gì? Có thực sự chạy những đoạn mã JavaScript trên web ko?
Matt Cutts: Chúng tôi scan JavaScript 1 lúc rồi tìm liên kết. Google đã trở nên có kinh nghiệm hơn nhiều với JavaScript và có thể chạy một vài đoạn JavaScript. Tôi không nói rằng chúng tôi chạy tất cả các đoạn JavaScript và vì thế trong một vài trường hợp chúng tôi không chạy Javascript. Thực ra thì có một vài JavaScript rất phổ biến và thông dụng như Google Analytics mà bạn không muốn thực hiện vì bạn không muốn mô phỏng lại những thứ Googebot đã làm trong Google Analytics của bạn.
Chúng tôi có khả chạy phần lớn Javascripts khi chúng tôi cần hoặc muốn. Một điều cần lưu ý khi bạn quảng cáo bằng Javascript là bạn có thể sử dụng No Follow trong những liên kết JavaScript.
Eric Enge: Nếu người khác có quảng cáo trên site của bạn thì Google muốn mọi người sử dụng No Follow những liên kết này, đúng không?
Matt Cutts: Chính xác là như vậy. Cách hành sử của chúng ta không thay đổi và tôi cũng không mong nó thay đổi. Nếu bạn mua quảng cáo, điều đó rất tuyệt đối với người sử dụng, nhưng chúng ta không muốn những quảng cáo đó ảnh hưởng tới thứ bậc của công cụ tìm kiếm. Ví dụ như, nếu như liên kết của bạn tới một redirects, redirects này được blocked khỏi robots.txt, điều này chắc chắn rằng chúng tôi sẽ không theo liên kết này. Nếu bạn sử dụng JavaScript, bạn có thể thực hiện NoFollow trong JavaScript. Rất nhiều quảng cáo sử dụng 302s đơn giản vì chúng chỉ là tạm thời. Những quảng cáo này không phải là lâu dài chính vì thể chúng tôi cố vận hành chúng một cách thích hợp.
Quan điểm của chúng tôi về vấn đề này không thay đổi và trên thực tế chúng tôi phải lập một bản báo cáo về những liên kết spam trong những tháng tới. Chúng tôi có một vài công cụ và kỹ thuật online để xử lý vấn đền này. Chúng tôi có thể thu thập một vài phản hồi ở nhưng loại liên kết spam khác nhau trong quá trình thực hiện.
Eric Enge: Nếu như có một ai đó sử dụng 302 trong liên kết ở những quảng cáo này?
Matt Cutts: Điều đó có thể được. Chúng tôi có thể xử lý nó và nhận ra rằng đó là một quảng cáo. Chúng tôi làm rất nhiều thứ để tìm ra quảng cáo và chắc chắn rằng chúng sẽ không ảnh hưởng tới công cụ tìm kiếm.
Một điều thú vị là hầu hết một network quảng cáo có rất nhiều cách bảo vệ khác nhau. Thông dụng nhất là 302 redirect ở một site nào đó đã được block bởi robots.txt vì không ai muốn theo 1 link quảng cáo. Những quảng cáo này hoàn toàn sẽ không có tác dụng vì googebot sẽ đánh giá credit rất thấp hoặc không có credit card. Dù sao đi nữa thì bạn không muốn nó làm rối những phân tích của bạn thêm nữa.
Eric Enge: Trong trường hợp này, liệu liên kết này có phá hủy link juice không?
Matt Cutts: Tôi phải kiểm tra điều này, tôi chưa nói với đội crawl và index về vấn đề này. Đó là trường hợp mà phần lớn nội dung của bạn là HTML và bạn có một lượng rất nhỏ quảng cáo vì thế đó có thể không phải là một vấn đề lớn.
Eric Enge: Cám ơn Matt!
Matt Cutts: Cám ơn Eric!
(Nguồn : Làm seo.com)

Eric Enge phỏng vấn Matt Cutts (phần 3)

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)

Eric Enge phỏng vấn Matt Cutts (phần 2)


Eric Enge: Hãy cùng tìm hiểu về faceted navigation. Ví dụ như, ở Zappos, người ta có thể mua giày theo số, theo cỡ, theo màu, theo nhãn hiệu và những mẫu giống nhau sẽ được thống kê theo 20 cách khác nhau. Điều đó như một bài toán đánh đố. Anh có suy nghĩ gì về trường hợp này?

Matt Cutts: Nói chung “Faceted navigation” có thể khiến nhiều người hiểu nhầm. Những người sử dụng thường không xử lý vấn đề này tốt, và trở nên mất phương hướng không biết mình đang ở điểm nào. Có thể có rât nhiều cách để lướt qua nội dung một trang. Nhưng nếu bạn muốn mỗi nội dung trang tương ứng với một URL thì cũng không phải là điều khó. Có rất nhiều cách để chia nhỏ và kiểm tra dữ liệu. Nếu bạn có thể tự quyết định cách nào là quan trọng và hữu hiệu nhất để có thể truy cập vào được nội dung thì bạn sẽ có cấu trúc riêng đối với các tham số URL.
Có thể lấy ví dụ như : Category có thể là tham số đầu tiên sau đó tới giá cả. Ngay cả khi một người đang xem qua giá cả và sau đó nhấn vào mục Catgory là điều hoàn toàn có thể làm được, chính vì thế hệ thống thứ bậc các điều bạn nghĩ sẽ được sắp xếp trong các tham số URL dưới dạng từng vị trí.
Theo cách này, loại quan trọng nhất sẽ được đặt lên đầu tiên và loại quan trọng tiếp theo sẽ được đặt ở vị trí thứ hai. Điều này có thể giúp các công cụ tìm kiếm phát hiện ra nội dung dễ dàng hơn chút ít bởi vì chúng có thể nhận ra rằng chúng có thể nhận được những nội dung hữu ích hoặc tương tự nếu chúng bỏ đi tham số cuối cùng này. Nói chung, “faceted navigation” là một vấn đề vô cùng hóc búa bởi vì bạn tạo ra rất nhiều cách khác nhau để ai đó có thể tìm được trang đó. Bạn có thể có rất nhiều đường dẫn intermediate trước khi chúng tới được sản phẩm cuối cùng.
Có lẽ sẽ dễ hiểu hơn khi sử dụng khái niệm trang intermediate, đây là một thực tiễn. Nếu một ai đó phải click qua 7 lớp của “faceted navigation” để có thể chọn được sản phẩm, họ có thể mất kiên nhẫn. Đó cũng là một điều bất bình thường trong công cụ tìm kiếm nếu chúng ta phải click qua 7 hay 8 lớp của một “faceted navigation” trước khi chúng ta có thể tìm được sản phẩm. Ở một vài trường hợp, sẽ là rất nhiều click và rất nhiều Pagerank bị chia cho những trang này mà không có một sản phẩm cụ thể nào người ta có thể mua được. Mỗi lần click là một cơ hội để một lượng phần trăm nhỏ Pagerank bị phung phí.
“Faceted navigation có thể là tốt với một số người sử dụng nếu bạn có thể quyết định những thứ bậc riêng bạn có thể phân loại các trang và cố gắng chắc chắn rằng “faceted navigation” là khá thấp. Những điều này có thể là một ứng dụng tốt giúp các công cụ tìm kiếm tìm ra được sản phẩm thực sự tốt hơn.
Eric Enge: Nếu bạn có những trang có cùng sản phẩm hoặc về bản chất là cùng một loại sản phẩm với nhiều kiểu đặt hàng khác nhau, cách sử tốt nhất là dùng “canonical tag”?
Matt Cutts: Cũng có thể như vậy, hoặc bạn cũng có thể tưởng tượng việc sắp xếp lại vị trí của những tham số theo cách riêng của bạn. Nói chung, ý tưởng về “canonical tag” được thiết kế để cho phép bạn chỉ cho các công cụ tìm kiếm rằng 2 trang nội dung là như nhau. Bạn có thể không muốn phân biệt một bản đen và một bản trắng của một sản phẩm nếu bạn có 11 màu khác nhau cho sản phẩm này. Bạn có thể chỉ muốn có một trang sản phẩm mặc định mà sau đó trang này đủ thông minh để tự chuyển đổi sang các trang khác nhau.Thể hiện những biến đổi nhỏ trong một sản phẩm và có một rel=canonical để đi tới tất cả là một cách tốt để sử dụng “rel=canonical tag”
Eric Enge: Hãy nói về những tác động đối với Pagerank, crawl và index của một vài công cụ cơ bản. Hãy bắt đầu với công cụ 301 Redirect yêu thích của chúng ta.
Matt Cutts: Nói chung 301 Redirect có thể chuyển được Pagerank. Đó có thể là một công cụ hữu hiệu để di chuyển giữa các trang trong một site, hoặc thậm chí là giữa các site. Rất nhiều người sử dụng chúng và dường như là nó hoạt động khá tốt vì nó có tác dụng dẫn tới trang cần thiết rất nhanh. Tôi dùng nó khi thử đi từ mattcutts.com tới dullest.com và quá trình chuyển đổi đó diễn ra khá nhanh. Thử nghiệm riêng của tôi đã chứng tỏ nó hoạt động khá thành công. Thực tế, nếu bạn truy cập vào site dullest.com ngay bây giờ, tôi sẽ chẳng vào được trang nào. Tất cả các trang đã di chuyển từ dullest.com tới mattcutts.com. Ít nhất đối với tôi, 301 Redirect làm việc như tôi mong muốn. Những trang yêu thích sẽ được chuyển tới một trang mới nếu như bạn truy cập trang theo kiểu chuyển trang và đó có thể là một công cụ vô cùng mạnh.
Eric Enge: Có thể nói như bạn di chuyển từ một domain này tới một domain khác và bạn tự viết một câu để hướng dẫn công cụ tìm kiếm và những người sử dụng khác để đi từ một domain này tới một domain khác. Trong những trường hợp như thế này, có một vài mất mát trong Pagerank có thể sảy ra rất đơn giản bởi vì người sử dụng thực hiện một liên kết tới một site không liên kết nó tới một tên miền mới.
Matt Cutts: Đó là một câu hỏi hay và tôi không hoàn toàn chắc chắn về câu trả lời. Tôi có thể chắc chắn biết được sự mất Pagerank như thế nào. Tôi không hoàn toàn chắc chắn đội crawl và index sẽ xử lý thế nào với Pagerank chính vì thế tôi sẽ phải kiểm tra lại trường hợp này. (Chú ý rằng: trong một email, Matt thông báo rằng đây là trường hợp xảy ra trong thực tế. Pagerank bị mất khi thực hiện Redirect 301)
Eric Enge: Hãy nói về 302 Redirect
Matt Cutts: 302 chỉ là giải pháp tạm thời. Nếu như bạn chỉ để một thứ vào một nơi trong một khoảng thời gian ngắn thì 302 là một lựa chọn thích hợp. Chúng sẽ không theo Pagerank nhưng chúng cũng có thể vô cùng hữu ích. Nếu một site chỉ làm một việc gì đó trong một khoảng thời gian ngắn, 302 có thể là một lựa chọn hoàn hảo.
Eric Enge: Thế còn Server side redirects trả về “HTTP Status Code” hoặc là “200 Status Code”?
Matt Cutts: Nếu chúng ta chỉ thấy thông báo 200, chúng tôi thừa nhận rằng nội dung trả về ở địa chỉ URL mà chúng ta yêu cầu. Nếu nhà cung cấp dịch vụ đang làm một số kiểu URL rewrite kỳ lạ trên server side, chúng ta sẽ không thể biết được.Tất cả những gì chúng ta biết là chúng ra cố yêu cầu URL cũ, chúng tôi lấy được một vài nội dung và có thể index nội dung đó. Chúng tôi sẽ index nó dưới vị trí URL nguyên gốc.
Eric Enge: Vì vậy bản chất của nó là giống như 302 đúng không?
Matt Cutts: Không hẳn là như vậy.Về bản chất, bạn đang lãng phí trên web server để trả về một trang có nội dung khác so với trang mà bạn yêu cầu. Như chúng ta quan tâm, chúng tôi nhìn thấy một liên kết, chúng tôi theo liên kết đó và chúng tôi yêu cầu nội dung. Bạn trả lại chúng tôi nội dung và chúng tôi index nội dung đó tại URL đó.
Mọi người có thể làm nhiều việc khác nhau ở trên server side. Bạn có thể tưởng tượng rằng một CMS được thực hiện trong một web server sẽ không thực hiện 301 hay 302, nhưng nó sẽ gây ra vài điều phức tạp và có thể có rất nhiều lỗi sảy ra.
Eric Enge: Anh có thể nói một cách tổng quát về canonical tag?
Matt Cutts: Có rất nhiều điều phải nhớ ở đây. Nếu bạn có thể giảm số lượng nội dung trùng lặp bằng cách sử dụng kiến trúc của site , đó là một điều nên làm. Những trang mà bạn kết nối không cần thiết phải hoàn toàn là trang trùng lặp, nhưng chúng có thể là trùng lặp về khải niệm cùng với một sản phẩm khác hoặc một thứ nào đó có quan hệ gần gũi. Chúng ta có thể thực hiện Cross – domain, rel=canonical đã công bố tháng 12.
Có thể lấy ví dụ như, tôi có thể đặt rel=canonical cho tài khoản của trường cũ để tới trang mattcutts.com của tôi. Đó là một cách tốt để sử dụng rel=canonical nếu bạn không thể vào được web server để thêm vào redirects trong bất cứ trường hợp nào. Tuy nhiên, Hầu hết mọi người sử dụng chúng cho những nội dung trùng lặp để chắc chắn rằng bản canonical của trang đó được index hơn là một vài bản khác của một trang mà bạn không muốn index.
Eric Enge: Vì vậy nếu một ai đó liên kết tới một trang có canonical tag, về bản chất liệu nó có thể đối xử giống như 301 đối với bản canonical của trang không?
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 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 cho 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.
(còn tiếp)

Eric Enge phỏng vấn Matt Cutts (Phần 1)

Matt Cutts là kỹ sư phần mềm của Google từ năm tháng 1/2000. Trước khi làm việc cho Google, anh đã hoàn thành đề tài nghiên cứu của mình về đồ họa máy tính tại trường Đại học North Carolina ở Chapel Hill. Ngoài ra anh cũng đã tốt nghiệp thạc sỹ tại trường UNC – Chapel Hill và cử nhân toán học và canh nghệ tại trường Đại học Kentucky.


Matt là tác giả của phần mềm Safe Search là bộ lọc hữu hiệu phục vụ cho Google. Ngoài kinh nghiệm làm việc ở Google, Matt còn nắm giữ những thanh tin tối mật khi làm việc cho Bộ Quốc Phòng Mỹ và anh cũng làm việc cho một công ty game. Anh chia se rằng Google là một trong những công việc thú vị nhất của anh cho tới nay.
Hiện nay Matt đang quản lý đội Webspam cho Google. Matt nói về những vấn đề liên quan tới Webspam trên blog của mình.
Nội dung cuộc phỏng vấn
Enric Enge: Chúng ta hãy cùng tìm hiểu khái niệm “crawl budget”. Theo tôi được biết thì Googlebot sẽ đi tới các website và tính toán số lượng trang nó sẽ phải Index trong một ngày và nó sẽ rời đi khi đã hoàn thành công việc.
Matt Cutts: Tôi sẽ cố gắng nói trình bày theo một cách khác cho dễ hiểu. Điều đầu tiên chúng ta nên nhớ rằng sẽ không có bất cứ một điều nào giống như “indexation cap”. Rất nhiều người nghĩ rằng một domain chỉ được Index một lượng trang nhất định. Nhưng googlebot không hoàn toàn làm việc như thế.
“…số lượng trang mà chúng tôi Crawl tương ứng với Pagerank của trang đó”
Cũng không có một giới hạn nào cho việc crawl. Cách tốt nhất để nắm được vấn đề này là chúng ta nên hiểu số lượng trang được Index tương ứng với Pagerank. Chính vì thế nếu bạn có nhiều liên kết tới trang chủ của bạn, chúng tôi sẽ crawl trang đó. Sau đó trang chủ của bạn có thể liên kết tới rất nhiều những trang khác và những trang đó sẽ có được Pagerank. Chúng tôi cũng sẽ crawl luôn những trang đó. Tuy nhiên, khi trang của bạn càng sâu thì đồng nghĩa với việc Pagerank của bạn sẽ có xu hướng giảm xuống.

Một cách lý giải khác là những trang có Pagerank thấp trong website của bạn sẽ phải cạnh tranh với rất nhiều những trang khác có cùng Pagerank hoặc có Pagerank cao hơn. Có rất nhiều trang trong website của bạn có Pagerank rất thấp hoặc bằng 0. Những trang có nhiều liên kết thường được nhận ra và crawl khá nhanh. Những trang có Pagerank thấp có xu hướng được crawl không thường xuyên.
Một điều cũng vô cùng thú vị khi nghiên cứu thuật ngữ “crawl budget” là mặc dù không có bất cứ một giới hạn nào trong crawl nhưng vẫn có khái niệm “host load”. Host load là số lượng kết nối đồng thời mà server có thể xử lý được. Tưởng tượng rằng website của bạn chỉ có thể xử lý 1 kết nối cùng 1 lúc. Điều này chỉ cho phép googlebot lấy 1 trang tại 1 thời điểm và dẫn tới việc “host load” sẽ rất thấp. Trong khi đó có một số trang như Facebook hoặc Twitter có thể có “host load” rất cao vì cùng một lúc các website này cho phép thực hiện nhiều kết nối.
Trang của bạn có thể ở trong một host ảo với rất nhiều website khác cùng một địa chỉ IP. Về mặt lý thuyết, website của bạn sẽ bị hạn chế về số lượng trang googlebot crawl. Nếu chúng ta chỉ có thể lấy ra 2 trang từ 1 website vào một thời điểm và chúng ta chỉ có thể crawl chúng vào một thời điểm cụ thể, sẽ đặt ra một câu hỏi liệu chúng ta có thể lấy được bao nhiêu trang từ host đó.
Eric Enge: Chính vì vậy ở đây anh sẽ có hai nhân tố. Một là Pagerank, từ đây chúng ta có thể tính được số lượng trang có thể crawl được trên website. Nhưng “host load” cũng có thể ảnh hưởng tới kết quả của kết quả này.
Matt Cutts: Đúng như vậy. Cho tới nay, có một lượng lớn các website đứng ở vị trí hàng đầu mà Pagerank và những nhân tố khác có thể quyết định việc chúng ta sẽ đi sâu vào nghiên cứu website này như thế nào.Tuy nhiên “host load” cũng có thể có những ảnh hưởng nhất định với một website. Điều này dẫn tới vấn đề những nội dung trùng lặp. Tưởng tượng rằng chúng ta kiểm tra 3 trang từ 1 website và phát hiện ra rằng hai trang kia lại là bản sao của trang thứ 3. Chúng ta sẽ loại hai trang kia và chỉ giữ lại một trang. Đó là lý do tại sao nội dung của các trang có vẻ ít. Chính vì thế chúng ta có thể sẽ kiểm tra nhiều tới mức có thể từ 1 trang.
Nếu mà “host load” của bạn bị giới hạn, bạn chỉ có một lượng hữu hạn các trang đượng Crawl do giới hạn của webserver, khi bạn có những trang trùng lặp chúng tôi sẽ loại bỏ những trang đó điều này đồng nghĩa với việc bạn bỏ lỡ cơ hội có những trang có nội dung đặc biệt, chất lượng tốt được Index.
Eric Enge: Chính vì chi phí cho những trang có nội dung giống nhau sẽ lãng phí “crawl budget”.
Matt Cutts: Đúng như vậy. Có một ý kiến cho rằng nếu nếu bạn có một lượng Pagerank cụ thể, chúng tôi sẽ kiểm tra nhiều website đó. Nhưng một số trang có thể bị loại và đó là một kiểu lãng phí. Điều này cũng có thể xảy ra ở host load khi chúng ta không thể truy cập rất nhiều trang.
Eric Enge: Một khái niệm nữa mà chúng ta cần đề cập tới đó là khái niệm “link juice”. Tôi sẽ sử dụng thuật ngữ Pagerank nhưng tổng quát hơn sẽ được hiểu là “link juice”. Thuật ngữ “link juice” ở đây có thể được hiểu là có những mối liên hệ với những khái niệm như sự tin cậy và uy tín của thuật ngữ Pagerank. Khi bạn liên kết từ một trang tới trang bản sao, bạn đang lãng phí Pagerank của mình. Điều đó có đúng không?
Matt Cutts: Cũng có thể hiểu theo cách đó. Điển hình, nội dung trùng lặp không phải là một nhân tố quan trọng quyết định việc bao nhiêu trang sẽ được crawl, nhưng đó cũng là một nhân tố. Lời khuyên của tôi ở đây là nó sẽ trở nên hữu hiệu hơn nếu bạn có thể sắp xếp được cấu trúc của website. Vì sau đó bạn sẽ không phải lo lắng nhiều về vấn đề những trang có nội dung trùng lặp và những vấn đề khác đi kèm với chúng. Bạn có thể sử dụng 301 Redirects cho những URLs trùng lặp sao để gộp chúng lại vào cùng một URL. Nếu bạn không thể dùng 301 Redirect, bạn có thể dùng rel=canonincal.
Một vài người không thể kết nối được với web server để thực hiện một 301 redirect. Nguyên nhân của việc này có thể là do họ đang truy cập vào mạng của trường học, free host hoặc là một host nào đó tương tự. Nhưng nếu họ có thể xử lý nó trong cấu trúc của site, thì sau này họ có thể giải quyết nó với 301 Redirect hoặc rel=canonical.
Eric Enge: Đúng vậy, đó chắc chắn là một tiêu chuẩn vàng. Có thể hiểu là bạn có 1 trang và có 10 liên kết tới trang đó. Nếu 3 trong số những trang đó là những trang trùng lặp và bị loại bỏ thì bạn đã bỏ mất 3 cơ hội để được chúng tôi crawl.
(đối với những nội dung trùng lặp):” Chúng ta cố gắng gộp những trang đó lại hơn là loại chúng hoàn toàn”
Matt Cutts: Không cần thiết phải như vậy. Đó là một trường hợp mà chúng ta có thể thử nghiệm. Chúng ta cố gắng gộp những trang đó lại hơn là loại chúng hoàn toàn. Nếu bạn liên kết tới 3 trang có nội dung giống nhau, công cụ tìm kiếm sẽ có thể nhận ra đó là 3 trang giống nhau và chuyển link juice tới những trang đã được gộp lại này.
Đó không phải là trường hợp mà Pagerank bị lãng phí hoàn toàn. Nó phụ thuộc vào công cụ tìm kiếm và cách triển khai. Giả sử rằng các công cụ tìm kiếm đều triển khai khác nhau, nếu bạn có thể làm được việc đó trên website của bạn nơi mà các liên kết đều đi tới 1 trang duy nhất. Đó làm một điều thích hợp hơn.
Eric Enge: Anh có thể nói them về Session IDs?
Matt Cutts: Đừng sử dụng nó. Ngày nay, hầu hết mọi người sẽ có một ý tưởng hay để tạo một website mà không sử dụng Session IDs. Về điểm này, hầu hết những người sáng tạo phần mềm đều nghĩ tới, không chỉ đứng ở góc độ công cụ tìm kiếm mà còn ở góc độ của người sử dụng. Người sử dụng thường có xu hướng click vào những link đẹp và họ cũng thường có xu hướng nhớ những liên kết trông đẹp mắt hơn. Tuy nhiên Nếu bạn không thể tránh khỏi điều đó, Google sẽ cung cấp cho bạn một công cụ để giải quyết vấn đề Session IDs. Người ta vẫn có thể làm như ở trong Yahoo!, nói một cách dễ hiểu là nếu một thông số URL không có giá trị hoặc không có thông số có thể sẽ bị bỏ qua, họ sẽ viết lại chúng với một URL đẹp hơn. Google cung cấp lựa chọn này cho người dùng và sẽ rất tốt nếu chúng ta sử dụng nó. Một vài công cụ tìm kiếm khác cũng làm như thế, nhưng sẽ tốt nhất nếu bạn không phải sử dụng Session IDs.
Eric Enge: Cuối cùng, điều đó có thể dẫn tới tình trạng các nội dung trùng lặp
Matt Cutts: Đúng, chính xác là như vậy và công cụ tìm kiếm gần như có thể xử lý vấn đề này khá tốt. Những trường hợp điển hình nhất cũng không phải là vấn đề hóc búa nhưng tôi đã từng gặp một trường hợp mà ở đó rất nhiều trang với những phiên bản khác nhau được index với những Session IDs khác nhau. Với những site riêng của bạn thì bạn nên xem xét kỹ vấn đề này và bạn sẽ không phải lo ngại về việc công cụ tìm kiếm xử lý vấn đề này như thế nào.
Eric Enge: Hãy thử xem xét những chương trình liên minh (Affiliate programs). Người khác gửi cho bạn những truy cập, họ đặt cho các URL đó một tham số. Bạn giữ những tham số đó trong suốt quá trình người khác vào thăm website, đó là một điều hoàn toàn bình thường. Liệu có phải công cụ tìm kiếm sử lý vấn đề này rất tốt hoặc là sẽ xảy ra nguy cơ có những nội dung trùng lập ở đây.
Matt Cutts: Nội dung trùng lập hoàn toàn có thể xảy ra. Nếu bạn tham gia các chương trình co-brand (Sử dụng chung một thương hiệu) mà sự khác nhau giữa các trang chỉ là biểu tượng và đó là cách mà những người sử dụng dùng chúng như những trang giống nhau. Công cụ tìm kiếm tỏ ra rất hữu hiệu trong việc cố gắng gộp những trang này vào với nhau, nhưng trong một vài trường hợp vẫn xảy ra tình trạng những nội dung trùng lặp.
Eric Enge: Với những trường hợp như thế này vẫn có những giải pháp SEO kinh điển. Theo phương cách này, điều bạn thật sự cần làm là để họ đặt một tham số vào trong URL, nhưng khi người sử dụng click vào liên kết này để tới site của bạn, bạn sẽ 301 redirect họ về trang đó mà không cần tham số và để tham số đó trong cookie.
Matt Cutts: Cũng có thể làm như vậy. Điều này cũng giống như việc thuê trang để quảng cáo. Bạn có thể nghĩ tới việc tạo một trang con cho thuê quảng cáo trong một thư mục URL riêng biệt mà bạn có thể block vào robots.txt như một ví dụ. Quảng cáo hay những liên kết con chủ yếu là nhắm tới những người sử dụng thực sự chứ không phải là các công cụ tìm kiếm. Đó chính là điểm rất dễ nhận ra và bạn không phải lo lắng về việc những mã liên kết này sẽ bị rò rỉ hoặc tạo ra những nội dung trùng lặp nếu những trang này không được crawl ở phần đầu.
Eric Enge: nếu Googlebot nhận ra một chương trình chương trình liên minh (Affiliate) liệu nó có đối xử với liên kết này như quảng cáo hay một Endorsement?
(với những link Affiliate) “..Chúng tôi sẽ không đếm chúng như Endorsement
Matt Cutts: Chúng tôi muốn xử lý những kiên kết này một cách thích hợp. Nhiều thời gian đồng nghĩa với việc những liên kết này về bản chất sẽ tiêu tốn rất nhiều tiền của. Chính vì vậy, chúng tôi sẽ không đếm chúng như một endorsement.

(Còn tiếp)


Cách tăng tốc độ website (site speed)

Google thừa nhận Tốc độ website cũng là 1 yếu tố xếp hạng của google . Nhưng không phải chỉ thế, site speed còn ảnh hưởng lớn đến người dùng (tính khả dụng tức Usability). Dĩ nhiên nếu tốc độ tải site nhanh thì website của bạn sẽ được nhiều lượt xem (pageviews) hơn – một trong những yếu tố ảnh hưởng đến chiến dịch bán quảng cáo của bạn.
Bài viết rất hữu ích dưới đây do Anh Khoa (PC World VN) dịch từ Yahoo! Developer Network giới thiệu 9/35 phương pháp tăng tốc website.
Các lập trình viên trên Yahoo! Developer Network cho biết hiện có khoảng 35 phương pháp, kỹ thuật thường được sử dụng ngay trong khâu thiết kế để trang web “hiện hình” nhanh hơn.
Các lập trình viên trên Yahoo! Developer Network cho biết hiện có khoảng 35 phương pháp, kỹ thuật thường được sử dụng ngay trong khâu thiết kế để trang web “hiện hình” nhanh hơn. Về cơ bản, các “chiêu “ này được phân vào 7 nhóm, gồm Content (nội dung), Server (máy chủ), Cookie, CSS, Java Script, Image (hình ảnh), Mobile (di động), và người thiết kế website sẽ tùy thực tế mà khai thác, kết hợp các kỹ thuật này với nhau sao cho đạt kết quả tốt nhất.
Trong bài này, chúng ta hãy cùng điểm qua 9 phương pháp thuộc nhóm Content và 21 phương pháp còn lại xin được gửi đến các bạn ở kỳ sau.
1) Hạn chế yêu cầu HTTP
Thực tế cho thấy, với mọi trang web hay website, khi nhận được yêu cầu hiển thị thì khoảng 80% quãng thời gian mà người dùng phải chờ đợi thường dành cho công tác truyền nhận dữ liệu giữa máy chủ dịch vụ (hay nói rõ hơn là nơi lưu trữ trang web) với trình duyệt. Trong khi đó, hầu hết thời gian “chết” này lại bị “cột chặt” với việc tải về tất cả thành phần trong một trang web như hình ảnh, định dạng (stylesheet), mã lệnh kịch bản (script), nội dung Flash,… để trình duyệt có thể dựng lại trang web trên màn hình (máy tính hay thiết bị di động) của người dùng. Do đó, giảm số lượng thành phần các nội dung dạng này đồng nghĩa với việc giảm số lượng yêu cầu HTTP (HTTP request) từ trình duyệt.
Một cách để giảm số lượng các thành phần trong một trang web là cố gắng làm đơn giản thiết kế của chính trang web đó. Tuy nhiên, câu hỏi mà nhiều nhà thiết kế web thường đặt ra ở đây là “có cách nào xây dựng một trang web có nội dung phong phú trong khi vẫn đảm bảo tốc độ đáp ứng /hiển thị nhanh hay không?”. Hiện có vài kỹ thuật giúp giảm số lượng yêu cầu HTTP nhưng vẫn hỗ trợ thiết kế trang web phong phú, chẳng hạn:
“Gom” các tập tin (Combined files) là giải pháp cơ bản để giảm số lượng yêu cầu HTTP, bằng cách kết nối tất cả script có trên trang web vào một tập tin script duy nhất, và tương tự là kết hợp tất cả CSS vào một tập tin stylesheet. Các tập tin được nối lại với nhau gây khó khăn hơn cho người lập trình (và cả website nữa) vì script và stylesheet thường khác nhau ở mỗi trang web.
Trong khi đó, CSS Sprites là phương thức được nhiều lập trình viên thích sử dụng để giảm số lượng yêu cầu HTTP, bằng cách giảm số lần yêu cầu truy xuất hình ảnh. Cụ thể, người lập trình và thiết kế trang web cần kết hợp các hình nền vào một hình duy nhất và sau đó sử dụng công cụ lập trình (như CSS background-image và background-position) để yêu cầu hiển thị đúng phần ảnh cần thiết.
Tương tự, phương pháp Image maps cũng kết hợp nhiều ảnh vào một ảnh duy nhất. Với phương pháp này, dung lượng nội dung hình ảnh cần hiển thị sẽ không đổi (bởi bằng tổng các tập tin hình ảnh thành phần trước đó), tuy nhiên phương pháp “góp gạo” này làm cho số lần yêu cầu HTTP giảm đến mức tối thiểu, do đó cũng giúp trang web đáp ứng nhanh hơn rất nhiều. Lưu ý, phương pháp Image maps chỉ có thể áp dụng khi các ảnh xuất hiện cạnh nhau trên trang web.
Ngoài ra, còn có phương pháp Inline Image, sử dụng cú pháp data: URL để nhúng dữ liệu dạng hình ảnh vào ngay trong trang web và dĩ nhiên việc này sẽ làm tăng kích thước của tập tin HTML. Tuy nhiên, kết hợp các ảnh nhúng trong stylesheet (được lưu đệm) là cách để giảm số lần yêu cầu HTTP, đồng thời tránh hiện tượng tăng dung lượng của trang web. Đáng tiếc, phương pháp này hiện chưa được hỗ trợ trên tất cả trình duyệt phổ biến.
Nhìn chung, giảm số lượng yêu cầu HTTP là phương pháp đầu tiên bạn cần nghĩ đến khi muốn cải thiện tốc độ hiển thị cũng như thời gian đáp ứng của trang web.
2) Giảm truy vấn DNS
Về cơ bản, hệ thống phân giải tên miền (Domain Name System) có nhiệm vụ “ánh xạ” tên máy chủ (hay trang web) với địa chỉ IP, giống như là danh bạ điện thoại. Thông thường, cần từ 20 đến 120 miligiây để DNS tìm kiếm địa chỉ IP của một tên máychủ (hostname) và trình duyệt sẽ không thể tải về bất kỳ nội dung gì từ hostname cho đến khi tác vụ tìm kiếm DNS hoàn tất.

lam seo a1003 ud 88a Các cách tăng tốc độ website (site speed)

Các tìm kiếm DNS thường được lưu lại để trình duyệt chạy nhanh hơn. Thông tin này có thể lưu trên máy chủ chuyên dụng của ISP hay máy chủ trong mạng nội bộ, tuy nhiên đôi khi cũng có thể lưu trên máy tính của người dùng cá nhân. Thông tin về DNS nằm trong vùng nhớ riêng của HĐH (như “DNS Client service” trên Microsoft Windows). Hầu hết trình duyệt có vùng nhớ lưu trữ riêng, độc lập với vùng nhớ DNS của HĐH. Khi trình duyệt còn lưu thông tin DNS, nó sẽ không không làm phiền HĐH tiến hành truy vấn.
Mặc định, Internet Explorer lưu thông tin DNS trong thời hạn 30 phút, được xác định bởi thông số DnsCachTimeOut trong Registry, trong khi đó Firefox chỉ lưu thông tin này trong vòng 1 phút, được kiểm soát bởi thông số cấu hình network.dnsCacheExpiration.
Khi vùng nhớ DNS trống (với cả trình duyệt và HĐH), số lượng truy vấn DNS bằng đúng số lượng hostname được đề cập trong trang web. Chúng bao gồm các hostname được sử dụng trong địa chỉ URL, hình ảnh cũng như các tập tin script, stylesheet, đối tượng Flash của trang web. Giảm số lượng các hostname đồng nghĩa với việc giảm số lần truy vấn DNS.
Tuy nhiên, việc giảm số lượng hostname (không trùng nhau) có nguy cơ làm giảm số lượng các tác vụ tải về song song diễn ra trong nội bộ trang web. Tránh được thao tác truy vấn DNS sẽ làm giảm thời gian đáp ứng, tuy nhiên giảm số lượng tải về song song có thể làm tăng thời gian này. Nhiều lập trình viên khắc phục tình huống này bằng cách phân chia các đối tượng kể trên ra tối thiểu 2 nhưng không được hơn 4 hostname – đây là sự dàn xếp tốt nhất để giảm số lần truy vấn DNS và cho phép khả năng tải về song song ở mức cao.
3) Lưu tạm cho Ajax
Một trong những lợi ích đáng chú ý của Ajax là khả năng cung cấp các phản hồi tức thời cho người dùng. Tuy nhiên, việc sử dụng Ajax không đảm bảo rằng người dùng sẽ chịu ngồi im chờ dữ liệu đến – các dữ liệu này là phản hồi XML hay JavaScript dạng không được đồng bộ. Trong nhiều ứng dụng, vấn đề người dùng có chấp nhận chờ đợi hay không phụ thuộc vào việc Ajax được sử dụng như thế nào. Ví dụ, trong tiện ích email trên nền web (như Yahoo! Mail hay GMail), người dùng vẫn phải chời kết quả truy vấn Ajax tìm kiếm tất cả email khớp với yêu cầu mà họ đặt ra.
Bạn cần hiểu rằng “không đồng bộ” (asynchronous) không có nghĩa là “tức thời”.
Để cải thiện tốc độ của trang web, việc quan trọng là cần tối ưu các phản hồi Ajax. Cách quan trọng nhất để cải thiện hiệu năng của Ajax là làm cho các phản hồi được lưu tạm trong bộ nhớ (trình duyệt hay máy tính tùy chủ ý của người thiết kế). Với phương pháp này, người dùng cần lưu ý đến thời hạn của các giá trị được lưu trữ.
4) Sử dụng thành phần được tải về sau khi nạp trang web
Bạn có thể nhìn cận cảnh trang web của mình và tự hỏi “Cái gì cần thiết phải có để có thể dựng lên một trang web ngay lúc ban đầu?”. Ở tình huống này, bạn xác định đâu là những thông tin cốt lõi cần hiển thị trước tiên, định dạng chung cho toàn trang web. Sau đó, nếu cần, bạn hãy nghĩ đến các định dạng riêng cho từng khu vực hiển thị, các hiệu ứng và trình đơn tương tác. Ví dụ, mã JavaScript xử lý hiệu ứng pop-up khi người dùng rê chuột qua một vùng nội dung nào không cần tải về trước vì trang web phải nạp xong thì người dùng mới thấy nội dung để rê chuột lên.
Với mục đích này, bạn có thể sử dụng công cụ YUI Image Loader, cho phép làm trễ sự xuất hiện của một ảnh, hay công cụ YUI Get utility cho phép áp dụng tức thời JavaScript hay CSS lên trang web.
5) Sử dụng thành phần được tải về trước khi nạp trang web
Nhiều người dùng thường cho rằng khó phân biệt được sự khác nhau giữa phương pháp sử dụng các thành phần được tải về sau khi nạp trang web và sử dụng các thành phần được tải về trước khi nạp trang web, song thực tế thì kết quả từ 2 phương pháp này rất chênh lệch. Bằng cách tải về trước các thành phần, bạn có thể tận dụng thời gian chờ của trình duyệt và yêu cầu tải về các thành phần (như hình ảnh, stylesheet, script,…) sắp sử dụng tới. Với phương pháp này, khi người dùng ghé thăm trang web tiếp theo, bạn có đã trong tay gần như đầy đủ các thành phần trong bộ nhớ và dĩ nhiên là trang web sẽ xuất hiện nhanh hơn.
Việc tải về trước các nội dung thường được chia thành các dạng: tải về trước không cần điều kiện, có điều kiện và theo dự báo – phụ thuộc vào chủ ý của người thiết kế trang web.
6) Giảm số lượng đối tượng DOM
Một trang web phức tạp thường có dung lượng tải về lớn và việc này cũng sẽ làm cho việc truy xuất các đối tượng DOM (Document Object Model) trong JavaScript trở nên “ì ạch”. Chắc chắn sẽ có sự khác biệt khi bạn duyệt qua một trang web với 500 đối tượng và một trang web với 5000 đối tượng, thậm chí nhiều hơn.
Một số lượng lớn đối tượng DOM có thể là triệu chứng cảnh báo bạn cần cải tiến mã HTML của trang web mà không cần thiết phải gỡ bỏ hay giảm bớt nội dung. Bạn đang sử dụng nhiều bảng biểu được xếp chồng lên nhau cho mục địch hiển thị, hay sử dụng nhiều tag dạng <div> chỉ để khắc phục những trục trặc liên quan đến hiển thị?
Bạn có thể sử dụng các công cụ của YUI CSS (http://developer.yahoo.com/yui/), như grids.css để kiểm soát tốt phần thiết kế (layout), hay font.css và reset.css có thể giúp bạn bỏ qua định dạng mặc định của trình duyệt. Đây là cơ hội tốt để bạn làm mới cũng như tạo ra sự khác biệt cho trang web của mình trong khâu hiển thị.
Các lập trình viên thường tự hỏi bao nhiêu đối tượng DOM là quá nhiều? Ví dụ, trang chủ của Yahoo! là một là trang web khá dày đặc nhưng chỉ có dưới 700 đối tượng. Bạn có thể dễ dàng xác định số lượng đối tượng DOM với tiện ích Firebug (http://getfirebug.com/). Trong cửa sổ console, bạn gõ vào lệnh document.getElementsByTagName(‘*’).length.
7) Đặt trên nhiều domain
Việc phân chia các thành phần trong một trang web sẽ cho phép bạn tối đa các tác vụ tải về song song. Hãy đảm bảo rằng bạn đang sử dụng 2-4 domain vì việc này có liên quan đến việc truy vấn DNS. Ví dụ, bạn có thể đặt (host) nội dung động và HTML tại địa chỉ www.example.org và sau đó phân các thành phần tĩnh sang 2 domain khác là static1.example.org và static2.example.org. Bạn có thể tham khảo thêm thông tin về giải pháp này tại địa chỉ http://yuiblog.com/blog/2007/04/11/performance-research-part-4/.
8. Tối thiểu số lượng iFrame
Về cơ bản, iframe cho phép một tài liệu HTML được chèn vào tài liệu gốc (hay còn gọi là tài liệu cha). Bạn nên hiểu cách thức iframe hoạt động để sử dụng hiệu quả nhất. Ưu điểm của iframe:
* Hỗ trợ các nội dung tốc độ chậm của bên thứ 3 như banner hay hình quảng cáo, v.v.
* Cho phép bổ sung các mã lệnh hay công cụ bảo mật
* Hỗ trợ tải về song song các script
Nhược điểm của iframe:
* Khoá trang web khi đang tải về
* Không trực quan về ngôn ngữ
9) Không sử dụng thông báo “404”
Như đã nêu ở trên, các yêu cầu HTTP không cần thiết chắc chắn sẽ làm giảm tốc độ đáp ứng của trang web; không những thế, khi nhận được phản hồi vô ích từ một yêu cầu HTTP (như thông báo 404 Not Found), người sử dụng sẽ cảm thấy khó chịu.
Vài website có sáng kiến tạo ra các thông báo 404 hấp dẫn hơn, đại loại như “404: Did you mean X?”, để người dùng cảm thấy dễ chịu hơn trước một trục trặc. Tuy nhiên việc này cũng sẽ làm lãng phí tài nguyên của máy chủ.
Ngoài ra, vấn đề trở nên tệ khi liên kết đến một đoạn mã JavaScript bên ngoài sai và kết quả là người dùng sẽ nhận được thông báo lỗi 404. Trước hết, tác vụ tải về này sẽ vô hiệu hóa mọi tải về song song. Tiếp đến, trình duyệt có thể cố gắng phân tích phần thân của phản hồi 404 như là mã JavaScript; cố gắng tìm thứ gì có thể sử dụng.
Theo PC World VN
Girls Generation - Korean