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 1)

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

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

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.

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

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

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

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)

Read More

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 1)

>>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)

Read More

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

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

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)

Read More

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)

Read More

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.

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

Read More

Tốc độ website cũng là 1 yếu tố xếp hạng của google

Google chính thức tuyên bố đang sử dụng tốc độ của site (site speed) như là một trong những yếu tố quyết định kết quả xếp hạng. Thực ra giới SEO chuyên nghiệp đã tỉ tai nhau từ lâu, nhưng việc Google công khai bí mật sẽ giúp tác động mạnh mẽ hơn đến các bộ phận thiết kế web.

Hơn 1 năm trước, khi đánh giá lại mức độ thân thiên Google (SEO friendly) các sản phẩm Zing sau hơn 1 năm hoạt động, mình cũng có đề cập đến tốc độ site. Khi đó site nhạc Zing Mp3 và News là 2 site tương đối “nặng ký” nhất.

Sau hơn 1 năm thì dù 2 site có thanh thoát hơn 1 chút, nhưng vẫn còn chậm hơn rất nhiều site khác nói chung. Tuy nhiên, sắp tới, mình tin 2 site này sẽ chú trọng hơn nữa về site speed để cạnh tranh với khá nhiều đối thủ đang lên rất nhanh.

Làm sao để đo tốc độ trang web? Nếu bạn là webmaster, có thể dùng các công cụ sau:

• Page Speed, một add-on của Firefox, có thể đề xuất các thay đổi cần thiết.
• YSlow, công cụ miễn phí của Yahoo! cũng giúp đề xuất các cải tiến.
• WebPagetest
• Hoặc vào Webmaster Tools, Labs > Site Performance để xem và so sánh tốc độ site bạn với phần còn lại của thế giới.

Vậy làm thế nào để giúp web tải nhanh hơn? Ngoài phần cứng (server, đường truyền) thì khi thiết kế web cần lưu ý các điểm sau:

• Gom những file code javascript bên ngoài (external javascripts) vào cùng 1 file. Và nén file lại, tham khảo tại http://javascriptcompressor.com/
• Gom các file CSS vào 1 file và cũng nén lại, tham khảo tại http://www.csscompressor.com/.
• Dùng gzip để nén các file nếu web server có hỗ trợ (hosting sẽ thực hiện công việc này giúp bạn)
• Nén các hình ảnh để được dung lượng tối ưu nhất nhưng vẫn đảm bảo chất lượng hình ảnh.
• Đặt các tracking code (như Google Analytics) và  javascript khác ở cuối trang (trước khi đóng thẻ body)
• Xem thêm các cách tăng tốc website…

Cá nhân mình nghĩ, nếu onsite SEO và uy tín của các site gần như nhau, thì tốc độ ảnh hưởng mạnh mẽ đến kết quả tìm kiếm.

Du Nguyễn – Làm SEO.com

Read More

Google bắt đầu phạt website SEO quá liều

Google đang thay đổi thuật toán tìm kiếm để phạt các Web spam hay "tối ưu hóa công cụ tìm kiếm (SEO) quá liều" đồng thời ưu tiên các website có nội dung chất lượng cao và ít tinh chế SEO hơn.

 

Theo dịch vụ tin tức IDG News Service, hôm qua (24/4), Google công bố một sự thay đổi về thuật toán dùng để trừng phạt các website vi phạm các hướng dẫn chất lượng của hãng và đồng thời thưởng những website tạo ra nội dung hữu ích cho người dùng chứ không phải chỉ để phục vụ cho thuật toán. Thay đổi này sẽ áp dụng từ vài ngày tới.

Đặc biệt, những thay đổi này nhằm mục đích giảm lượng nội dung mà hiển thị cao trên kết quả tìm kiếm của người dùng trên Google nhưng lại không đặc biệt có giá trị hoặc hữu ích. Những nội dung kiểu này còn bị xem là Web spam.

Matt Cutts, phụ trách về Web spam của Google, lần đầu tiên nhắc đến kế hoạch này tại hội nghị SXSW Interactive hồi tháng Ba vừa qua.

Ông Cutts cho biết thuật toán sẽ đánh giá xem liệu các trang web có "nhồi quá nhiều từ khóa trên trang, hoặc liệu chúng có trao đổi quá nhiều liên kết hoặc bất cứ điều gì họ đang làm để đi xa quá những gì một người dùng bình thường mong đợi ở một kết quả tìm kiếm cụ thể".

Google thậm chí còn nâng cao vấn đề ông Cutts đã mô tả thành "SEO quá đà". Hôm qua, hãng nhấn mạnh trong thông cáo rằng sự thay đổi thuật toán sẽ chỉ nhắm vào các hành vi vi phạm hướng dẫn của mình như "nhồi nhét từ khóa", "gian kế link".

Trong thông cáo ra ngày 24/4, Google không cho biết chi tiết về việc thuật toán sẽ phân biệt nội dung có ích với Web spam như thế nào mà chỉ nói hãng sẽ ưu tiên cho những website có nội dung thực sự hữu ích với người dùng.

Read More

Cách tăng fan cho fan page facebook (Phần 2)

XI. Promote Fan Page của bạn ở ngay cửa hàng.

Nếu bạn có một quán ăn, cửa hàng, hay văn phòng công ty vậy thì tại bàn tiếp tân hãy đặt một biểu tượng bằng bìa cứng thể hiện thương hiệu của bạn đã có mặt tại Facebook, nhớ để cả đường link đến fan page. Khách hàng sẽ cảm thấy thú vị, xen lẫn tò mò và chắc chắn họ sẽ viếng thăm fan page của bạn thôi.


Trong trường hợp này, sẽ hay nhất nếu bạn có một username cho fan page thật dễ nhớ và có liên quan tới thương hiệu của mình (username của fan page có dạng: )
Nếu bạn sắp in ra một loạt các coupon giảm giá, đừng quên in thêm logo facebook, đường dẫn fan page và những lời kêu gọi như:” Dùng thử xem, bạn sẽ “like” chúng tôi thôi mà”…
Nhiều công ty còn tận dụng khoảng không gian tại các thang máy để đặt các biểu tượng bắt mắt, hài hươc về Facebook và Twitter và dĩ n

hiên là có liên quan tới fan page của họ. Bạn còn đợi gì nữa mà không áp dụng ngay đi chứ. Các bạn có thể tham khảo về chiến dịch quảng bá tích hợp với Facebook của Coca Cola – vô cùng sáng tạo.

XII. Đặt đường link fan page vào profile facebook của bạn
Nếu bạn muốn quảng bá fan page của mình tới bạn bè, có một cách rất dễ dàng và nhanh chóng.
Hãy để ý dưới profile picture của mình, sẽ có một ô cho phép bạn viết linh tinh gì đó về bản thân. Ô này thường được gọi nôm na là “mini bio” và a lê hấp sao chúng ta không thêm đường link fan page của mình vào đây chứ nhỉ. Ô này giới hạn số lượng kí tự, nên các bạn để ý không đánh vượt quá số lượng kí tự cho phép nhé.

 

XIII. Đưa Page Badge vào Profile cá nhân
Các bạn hãy sử dụng 1 trong 2 ứng dụng này – Profile HTML hoặc Extended Info để có thể add code của Page Badge vào profile cá nhân của mình. Sau khi đã đưa code của Page badge vào ô HTML các bạn trở về trang profile cá nhân và click vào nút dấu cộng (“+”) để add thêm tab. Nếu không thấy tên tab nằm trong menu xổ xuống bạn có thể đánh “ Profile HTML” hoặc Extended Info” trong ô search, tab sẽ hiện ra ngay.

 

Nói thêm về cách add page badge vào tab bạn cần vào Facebook Badge để tạo Badge cho fan page của mình. Sau đó lấy code đem vào Profile HTML hoặc
Extened info.
Nếu không thích hình ảnh của Page Badge, bạn có thể tự thiết kế một hình ảnh khác ( màu mè hơn), sử dụng HTML hoặc Phototoshop. Ở đây, bạn nào biết
HTML thì không cần phải nói nhiều. Còn bạn nào tự thiết kế đồ họa Page Badge cho chính mình thì sau khi thiết kế xong, các bạn up lên photobucket ( hoặc bất
cứ trang nào cho phép lưu trữ ảnh) sau đó lấy code dưới dạng sau:

Mã:

<a href=”http://media.photobucket.com/image/seo/trofimiuk/Seo Taiji/f25ee1d01d4d5dc27025b54802475555.jpg?o=1″ target=”_blank”><img src=”http://i747.photobucket.com/albums/xx112/trofimiuk/Seo%20Taiji/f25ee1d01d4d5dc27025b54802475555.jpg” border=”0″></a>

Lưu ý các bạn sửa phần đánh dấu hightlight trong hình thành địa chỉ link trang fan page của mình để khi click vào, người click sẽ được đưa tới page của bạn.

XIV. Sử dụng nút share
Nút Share xuất hiện đầy rẫy trên Facebook và dĩ nhiên là nó cũng có mặt tại fan page. Các bạn để ý ở góc trái gần dưới cùng của fan page có một nút share ( giờ đã được thiết kế cho to hơn). Chúng ta chỉ cần click vào đó và add thêm vài dòng comment cập nhật hoặc mô tả hoạt động của fan page vào đồng thời có thể loa loa kêu gọi mọi người vào chơi. Nút share thực sự còn “mạnh” và tiện dụng hơn cả chức năng “Suggest to friends” nhiều đó mọi người. Thử xài đi, bạn sẽ thấy ngay tác dụng của nó.

XV. Sử dụng @ Tag tại Status của chính mình
Thông thường nếu bạn đã là friend của ai đó hoặc là fan của một page nào đó thì tại ô status bạn có thể sử dụng @ Tag để đặt link tới profile hoặc page đó. Vì thế hãy tận dụng chức năng này để cập lên wall của mình những hoat động đang diễn ra tại fan page của bạn và dĩ nhiên là không quên dùng @ tag để kèm theo đường link.
Nếu status của bạn lôi cuốn, người đọc sẽ có xu hương click vào link để đến page thăm thú. Lợi điểm của chức năng này còn ở chỗ nó cho ta đặt link chữ chứ không cần show cả đường link gốc dài dòng ra. Như vậy link sẽ cuốn hút và thân thiện hơn. Các bạn xem hình dưới đây:
XVI. Thêm @tag fan page vào cuối mỗi post trên wall của bạn bè
Hình thức này giống dạng một chữ kí sau mỗi message vậy đó. Sau khi viết vài ba dòng trên wall của bạn bè, bạn có thể dùng @tag để thêm link của fan page vào dòng cuối cùng. Lưu ý, đừng lạm dụng chức năng này nhé, trừ khi bạn post một điều gì đó hay ho hoặc có ích cho bạn mình thì khả năng mọi người click vào link của bạn sẽ cao. Ngược lại post của bạn sẽ bị xóa thẳng tay.

XVII. Thêm @tag fan page vào cuối mỗi post trên wall của Fan Page khác.
Cách này cũng tương tự như việc thêm @tag fan page vào cuối mỗi post trên wall của bạn bè ở trên, nhưng lần này bạn lại càng phải cẩn trọng hơn, đặc biệt là với những fan page cùng ngành hoặc đối thủ cạnh tranh. Nếu lạm dụng chỉ để quảng cáo trắng trợn, bạn sẽ bị bài trừ không thương tiếc. Rải link cũng phải có nghệ thuật đúng không các bạn ?

XVII. Landing Page lung linh.

nguồn: seongon

Read More

Cách tăng fan cho fan page facebook (Phần 1)

Thu hút Fan cho Fanpage Facebook là yếu tố sống còn của một Fanpage. Thật buồn tẻ nếu lập ra một Fanpage mà chỉ có vài chục friend, cập nhật cũng chẳng biết để làm gì nữa. Ngay cả với các doanh nghiệp lớn, nếu không có chiến lược thu hút Fan rõ ràng thì Fanpage cũng … mốc.


I. “Suggest to friends”
Cách thông thường nhất là sau khi tạo Fanpage Facebook, chúng ta tìm “Suggest to Friends” và mời tất cả bạn bè của mình thích trang mình vừa mới tạo.
Đã có rất nhiều người phàn nàn rằng họ không thích bị spam bởi những email đề nghị thích trang này trang nọ nhưng phần lớn chúng ta sẽ click vào đường dẫn trong email để xem trang này có đúng với sở thích của mình không
Tuy nhiên công cụ suggest to friends không phải lúc nào cũng hiệu quà bở một số lí do:
1. Một cá nhân trên Facebook chỉ có thể like tối đa 500 page.
2. Nếu những người mà bạn đề nghị trở thành Fan đã là Fan của 500 page thì dù họ có thực sự thích trang của bạn cũng lực bất tòng tâm.
Với cách này bạn cần chú ý:
1. Không bao giờ Suggest like khi fan page của bạn trống rỗng.
2. Thay vì suggest toàn bộ friends list, hãy nhớ xem, bạn có những người bạn thân và có uy tín nào. Hãy gửi Suggest đến những người ấy trước. Đó sẽ là những “influencer” (cá nhân ảnh hưởng)- những người thậm chí sẵn sàng “Like” fan page chỉ vì đó là lời đề nghị của bạn và họ cũng là những “con virus” khỏe nhất (nghĩa bóng). Sau đó hãy gửi message cám ơn và khuyến khích họ suggest cho bạn bè của mình.

II. Nhúng Widget Like Box vào website.
Doanh nghiệp nào cũng thường có website riêng của mình. Hãy nói với webmaster của mình rằng bạn muốn đặt một Like Box ( hiện nay Fan Box đã được đổi tên thành Like Box vì nút “become a fan” đã được chuyển thành nút “Like”) lên website của công ty bạn. Khách hàng sẽ nhận thấy có cách nhanh chóng để họ thường xuyên theo dõi thông tin trên website thông qua Facebook và khi đó thì khả năng họ bấm like.
Ngoài ra bạn còn có thể yêu cầu webmaster thêm Widget Live Stream đi kèm với Like Box để cập nhật những hoạt động mà bạn đã đưa lên Fan Page của mình, đồng thời cho phép các Fan có thể comment trực tiếp ngay tại Like Box.

III. Dùng email để giới thiệu.
Giả sử bạn có một danh sách các email đã thu thập được từ website của công ty mình, chúng ta có thể gửi email đến những người dùng tiềm năng ấy với nội dung giới thiệu về fan page mà công ty bạn vừa tạo trên Facebook đồng thời thể hiện mong muốn người nhận email sẽ ghé thăm fan page của mình.
Trong email giới thiệu về fan page bạn không cần thiết phải dùng những từ hay cụm từ như: “Hãy là Fan của cty ABC”, “Vào viết vài dòng suy nghĩ của bạn lên wall của chúng tôi đi !”….Chỉ cần nhớ đặt một biểu tượng Fan Page Badge vào chữ kí email của mình. Nếu bạn là sếp và không chuyên về IT bạn chỉ cần nhắc marketer của mình rằng:” Nhớ cho thêm biểu tượng Fan Page ( Fan Page Badge) vào chữ kí email nhé” là họ sẽ hiểu ngay. Khi click vào badge, người đọc mail sẽ được đưa thẳng tới fan page.

IV. Tạo một Video lôi cuốn để giới thiệu về Fan Page
Bạn muốn người xem nhớ Fanpage của mình thì trước tiên bạn phải quyến rũ. Đa phần khi vào các Page, thứ “đập vào mặt” chúng ta đầu tiên là Wall với những Status, links …dài ngoằng. Bạn nên nhớ ấn tượng đầu tiên là ấn tượng mãi mãi, vì thế chúng ta sẽ khiến những khách đến chơi nhà ấn tượng hơn gấp nhiều lần nếu có thể tự làm một video clip giới thiệu về trang của mình.
Các bạn có thể tham khảo page của Steve Spangler, một page có video giới thiệu rất hài hước và lôi cuốn. Bảo đảm sau khi xem xong bạn phải bấm Like ngay.
Đây là một ví dụ mẫu rất đáng học tập phải không mọi người. Cách tạo các tab đa dạng kiểu này đòi hỏi bạn phải dùng đến ngôn ngữ FBML mà nói trắng ra là HTML nhưng được tích hợp với Facebook. Cách làm thế nào mình sẽ mô tả và hướng dẫn các bạn ở phần sau của bài này. À, và các bạn nhớ là nếu có làm trang video này thì phải set cho landing tab của mình là ở tab Video đã tạo nhé. Tức là khi người dùng vào Page của bạn thì tab đầu tiên “đập vào mặt” họ là tab video của bạn.

V. Kêu gọi Fan tag họ vào photo của bạn
Trong trường hợp bạn tổ chức một sự kiện nào đó, hãy nhớ chụp thật nhiều ảnh, sau đó upload ảnh lên Fan Page rồi kêu gọi và khuyến khích các fan của mình vào chỉ ra xem họ có mặt ở đâu trong ảnh bằng cách “tag”. Phương thức này mang lại hai điểm tích cực:
1. Về mặt tâm lý: Fan sẽ cảm thấy mình trở nên quan trọng hơn và biến thành 1 phần của tổ chức hay sản phẩm mà họ yêu mến. Đó chẳng khác gì một hình thức “cam kết” của fan rằng tôi cảm thấy hạnh phúc, tôi sẽ sẽ trung thành luôn hâm mộ sản phẩm dịch vụ ( hoặc tổ chức, công ty ) này. Bạn có thể thấy ngay cả báo Tuổi Trẻ cũng áp dụng hình thức này trong các hoạt động kỉ niệm 35 năm của tờ báo ( tại trang báo giấy)
2. Về mặt lan truyền: Mỗi khi các fan tag mình vào ảnh thì thumbnail của tấm ảnh này cũng sẽ xuất hiện tại News Feed của họ, và các bạn của fan cũng sẽ thấy. Một cách lan truyền vô cùng hiệu quả, miễn phí và quan trọng hơn, đó là điều mà các fan tự nguyện làm. Hình ảnh lúc nào cũng có tiếng nói và sinh động hơn kí tự đúng không các bạn ?

VI. Upload video lên FanPage và Embed tại website của bạn.
Đây là điều rất đơn giản nhưng dường như có nhiều người lại quên mất và bỏ qua sức mạnh này của Facebook.
Hãy Upload video lên Fan Page và embed nó vào website của bạn ! Tại sao thế ? Tại sao lại dùng Facebook mà không dùng Youtube trong trường hợp này ? Câu trả lời đó là hãy để ý khi video của bạn được host trên Facebook và được embed thì tại khung hình video ở góc trái, phía trên, sẽ xuất hiện một đường link đặc biệt:
Nếu người xem chưa Like Page của bạn đường link sẽ có hình thù thế này:
Như vậy nếu video của bạn ấn tượng và chiếm được trái tim của người xem, họ sẽ có thể bấm Like ngay lập tức. Quá tiện phải không nào ! Còn nếu người xem đã Like Page của bạn thì đường link sẽ dẫn người xem tới trang video tại Fan Page và biết đâu đấy khi họ tìm ra được những thứ thú vị khác, họ sẽ thành fan của bạn lúc nào không hay.

VII. Liên kết FanPage tới Twitter.
Đây là cũng là điều mà các chủ fan page rất hay quên vì vốn ngó lơ Twitter.
Một động tác rất đơn giản, hãy liên kết tài khoản Twiiter với fan page của Facebook để bất cứ hoạt động nào của fan page cũng sẽ được cập nhật lên Twitter. Vậy là bạn đã có thể mở rộng thì tầm ảnh hưởng của Page và có cơ hội thu hút được thêm nhiều fan tiềm năng khác rồi đấy. Bạn có thể lựa chọn những thông tin nào thì được cập nhật lên Twitter như hình minh họa dưới đây.
Tuy nhiên số lượng kí tự tối đa trong Status của Facebook là 420, còn trong Twitter là 140. Vì thế bạn phải cân nhắc trong post thông tin lên ô Status của Facebook. Twiter sẽ chuyển đường link bạn share trên Facebook Page thành một đường link ngắn hơn có dạng như http://bit.ly/bvAivP đồng thời sẽ tỉa gọt số lượng kí tự xuống sao cho vừa đúng 140 kí tự.
Ngoài ra tại profile và background của Twitter, bạn cũng nên đề cập tới fan page của mình bằng cách kèm theo đường dẫn. Đây là một mẹo nhỏ nhưng cũng có thể tạo được tác động dẫn dắt người dùng đến fan page.

VIII. Tích hợp chức năng comment vào landing tab
Thương mại điện tử có phải là điều gì mới lạ không ? Không. Nhưng thương mại điện tử trên Facebook Page mới là điều đáng để tâm. Với những cửa hàng bán đồ lưu niệm, shop thời trang…. thì việc đem sản phẩm của mình đến gần hơn với người tiêu dùng thông qua Facebook Page là một điều rất tuyệt vời và tiện lợi hơn bao giờ hết.
Hãy lấy ví dụ của trang bán áo thun nổi tiếng threadless. Công ty này đã đem các sản phẩm của mình lên Facebook thông qua 1 landing tab. Các loại áo thun được trưng bày một cách đơn giản nhưng không kém bắt mắt. Điểm mấu chốt là họ đã chèn thêm tính năng comment giúp người dùng không chỉ có thể đặt hàng thông qua page mà còn có thể gửi comment của mình về sản phẩm đến những người bạn khác.
Threadless đã tận dụng triệt để môi trường Facebook để phát triển kinh doanh và cho chúng ta thấy sức mạnh của cụm từ “Word of Mouth” trong tiếp thị.
Và các bạn có thể thấy kết quả là nhờ tích hợp một chức năng khá đơn giản và cơ bản là comment, họ đã xây dựng cho mình hơn 140,000 fan một cách tự nhiên (organically). Nếu các bạn là những chủ cửa hàng thì còn chần chừ gì nữa mà không học tập Threadless. Để tích hợp plugin comment các bạn vào link sau: comment box

IX. Tìm kiếm fan thông qua SMS
Cách này nghe có vẻ khá mới ở Việt Nam nhưng ở nước ngoài thì rất thịnh hành. Bạn cứ hình dung thế này nhé, công ty bạn phát một đoạn TVC dài 30 giây rất hay và ấn tượng, nhưng quảng cáo hay mà không kết lại bằng việc mở ra một phương thức tiếp cận với sản phẩm thì cũng không thể gọi là thành công. Chính vì thế mà một số công ty đã thêm vào cuối các đoạn TVC hoặc quảng cáo trên Radio những lời kêu gọi như:” Hãy soan tin với cú pháp FAN dấu cách username hoặc LIKE dấu cách username gửi đến số 8X…”.

Chỉ cần 1 tin nhắn và không cần truy cập internet, người tiêu dùng có thể gia nhập ngay vào hàng ngũ những tín đồ thương hiệu của bạn. Mình nghĩ , trong tương lai ngắn tới đây thôi, Việt Nam cũng sẽ áp dụng phương thức này. Lưu ý, cách này chỉ có thể áp dụng khi fan page của bạn đã có ít nhất 25 fan, và người dùng facebook muốn thực hiện tác vụ nhắn tin phải có số điện thoại di động được chứng thực cùng với username của mình.

X. Đưa Fan Page vào các ấn phẩm quảng cáo
Thay vì chỉ đặt tên website, điạ chỉ email lên card visit, letter head, brochure, poster, banner, bìa báo…bạn chỉ cần in thêm địa chỉ Fan Page của mình. Thế thôi cũng đủ tạo nên sự khác biệt cho doanh nghiệp của bạn rồi đấy. Tỉ lệ người tiêu dùng có Facebook là rất cao, thay vì chỉ nhìn qua banner quảng cáo rồi chẳng nhớ gì thì giờ đây Facebook đã tạo ra một điểm chung giữa thương hiệu của bạn và người tiêu dùng. Họ sẽ dễ dàng nhớ đến bạn hơn và cũng như dễ tiếp cận để tìm hiểu về sản phẩm dịch vụ của công ty.
Hãng đồ lót Victoria Secret đã làm cả một sự kiện ra mắt fan page của mình tại địa chỉ Victoria’s Secret Pink
Nguồn : seongon

Read More

Giải pháp SEO - SEM cho các công ty phát triển phầm mềm

Giải pháp SEO - SEM cho các công ty phát triển phần mềm có nhiều sự lựa chọn, sau đây tôi xin giới thiệu 1 giải pháp khá hữu hiệu để ngoài việc quảng bá sản phẩm còn có thể dễ dàng bán được sản phẩm, do đó nội dung tiêu đề đã đề cập SEO and SEM.

1. Trước tiên xin giới thiệu thế nào là PAD (PAD XML)

Portable Application Description (PAD) là một loại tài liệu được định dạng để có thể được đọc bởi các máy tính, thiết kế bởi Hiệp hội các Chuyên gia Shareware (Association of Shareware Professionals).

Nó cho phép tác giả mô tả sản phẩm và thông số kỹ thuật tới các nguồn trực tuyến theo tiêu chuẩn, bằng cách sử dụng một lược đồ XML đơn giản cho phép người quản trị web và các chương trình thư viện tự động liệt kê danh sách các chương trình - phần mềm. PAD tiết kiệm thời gian cho cả tác giả và người quản trị web.

Ví dụ về file PAD XML cụ thể như sau: http://www.softbuzz.net/pad.xml

2. Chương trình phần mềm tạo file PAD

Chính vì tính đặc thù và phổ biến của PAD mà người ta thiết kế ra các chương trình chuyên biệt cho người dùng dễ dàng tạo ra các file PAD, trong đó phải kể đến là PADGEN: http://www.softbuzz.net/windows/deve...bution/padgen/

Đây là một công cụ mạnh và phổ biến được các nhà thiết kế phần mềm ưa dùng.

Ngoài ra cũng có nhiều PAD editor, hay PAD validator miễn phí các bạn có thể tham khảo: http://www.softbuzz.net/download/pad/

3. Quảng bá sản phẩm

Vậy làm sao để quảng bá các sản phẩm của mình sau khi đã có phần mềm và file PAD.

Các bạn có thể dễ dàng submit file PAD với nội dung về sản phẩm phần mềm của mình cho các trang download miễn phí như download.com hay rất nhiều trang web về phần mềm download khác.

Nhưng trước cả những điều đó, việc nên xây dựng cho mình một hệ thống bán hàng như các Vendor tại các trang cung cấp bán hàng trực tuyến như: Regnow hay Plimus eSellrate ShareIt cũng là việc nên làm, điều này kích thích việc bán hàng của các thành viên đang ký bán hàng dạng Affiliate để kiếm tiền online (Make Money Online - MMO, trogn mỗi PAD file bạn điền đầy đủ các ID để dễ dàng cho người Affiliate.

Việc làm này nhắm vào các đối tượng kiếm tiền online, họ sẽ tự động bán hàng cho bạn và quảng bá sản phẩm cho bạn.

Ngoài ra, việc Submit các file PAD lên các địa chỉ website cung cấp phần mềm download cũng là việc làm tối cần thiết, để làm được việc này chúng ta làm theo 2 cách:

* Dùng phần mềm PAD Submitter: đây là các phần mềm được các nhà thiết kế chuyên để submit các file PAD một cách tự động vào hàng ngàn website cho phép giới thiệu và download phần mềm, các bạn có thể tìm cho mình 1 chương trình phần mềm thích hợp tại: http://www.softbuzz.net/download/pad/

* Phương pháp thủ công: đó là gửi các file PAD tới các website này, thông thường tìm và submit thủ công vào mục Submit Software: http://www.softbuzz.net/index.php?a=pad

Kết luận: Ngày nay các phần mềm phát triển khá đa dạng cung cấp cho người dùng, các doanh nghiệp nhiều sự lựa chọn. Để giới thiệu được sản phẩm phàn mềm của mình đến tay người tiêu dùng, các nhà sản xuất có nhiều giải pháp, trong đó giới thiệu bán sản phẩm online là một thế mạnh, để làm được việc đó cần một chiên dịch SEO SEM thật tốt, chúng tôi cũng xin chia sẻ chút kinh nghiệm ít ỏi của mình về vấn đề này, và giới thiệu đến các bạn nhưng phần mềm SEO tốt nhất để các nhà phát triển lựa chọn cho mình những giải pháp tốt nhất nhắm tăng hiệu quả kinh doanh. Các bạn có thể truy cập http://joomquery.com/vi/seo-sef-sem/seo-tools.html để lựa chọn phầm mềm.

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

Nguồn : thegioiseo.com

Read More

Thiết kế website dùng div hay table tốt hơn cho seo

Trong thiết kế web seo chuyên nghiệp ta nên sử dụng tag nào ? Bài viết này phần nào đó giúp các bạn có thể định hướng được các trường hợp nào nên sử dụng tag<div> hay tag <table>

Trước hết, mình cùng bàn luận với nhau về tính năng của 2 tag trên:
Cả 2 tag đều có tác dụng là bao một hay nhiều khối, nhưng cách sắp sếp các khối ấy khác nhau:

• <table>: sắp xếp khá dễ dàng và ít lỗi vì bản thân <table> là tạo bảng, nhưng cũng khá bất tiện với những cấu trúc khác thường ví dụ như hình sau:

Cần sử dụng khá nhiều tag HTML :
<table width=“200px” border=“0″>
<tr>
<td>Seo</td>
<td>&nbsp;</td>
<td>24H</td>
</tr>
<tr>
<td>&nbsp;</td>
<td>Web</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>Top</td>
<td>&nbsp;</td>
<td>Tốt</td>
</tr>
</table>

• <div> : Sắp xếp hơi phức tạp hơn, dễ bị lỗi nếu không cố định bằng kích thước nhưng trái lại thì khá linh động trong cách trình bày. Ví dụ như trường hợp :

<div id=“ngoai”><div id=“trong”></div></div>
<div id=”trong”> có kích thước ngang hoặc rộng to hơn <div id=”ngoai”> vẫn được, đây là điều <table> không làm được dù cố định kích thước nhưng nếu <tr> (hoặc <td>) ở trong lớn hơn <table> ngoài thì tự động thẻ ngoài sẽ giãn ra.
Đọc qua có lẽ các bạn thấy điều này đâu có ảnh hưởng gì đến SEO, thật sự có đấy, hiện nay các website ra đời đều nhắm đến việc SEO sau khi thiết kế, nên thường thiết kế đơn giản dễ hiểu và dễ tối ưu. Vì vậy, viết HTML có xu hướng làm sao cho WEB càng ít code càng tốt, tùy vào cấu trúc website mà các bạn chọn 1 trong 2 thẻ trên nhé.

Số lượng code:
Bạn sẽ phải thừa nhận về điều này, tag <div> cấu trúc nhỏ hay lớn chỉ khác nhau thuộc tính “width – height”, còn <table> thì càng lớn sẽ càng tốn rất nhiều code, phải định dạng từng <tr>, <td> nếu từng ô khác nhau.
Vậy, ở trường hợp cấu trúc lớn như tổng trang web, tổng cột bên phải web, … thì ta nên dùng <div> vì cấu trúc sẽ nhẹ nhàng hơn. Nhưng những cấu trúc nhỏ, gọn như khung thông tin gồm tên, giá sản phẩm, khuyến mãi thì ta nên dùng <table>.
Kết hợp cả 2 như vậy, tốc độ load nhanh sẽ được người dùng ưu ái hơn, spider google cũng thích hơn, đó là điều SEO chuyên nghiệp cần lưu ý.

Tốc độ load:
Đây là vấn đề được tranh cãi rất nhiều, có người cho rằng <div> được load nhanh hơn, vì sau khi load lần thứ nhất thì trình duyệt lưu CSS vào cache. Có người cho rằng sử dụng 2 thẻ này có tốc độ load như nhau, nhưng vì <table> khi load hết bảng mới hiện ra, còn<div> thì load từng phần nên bị lầm tưởng <div> load nhanh hơn… và rất nhiều lý do khác. Nhưng lý do thật sự <div> load nhanh hơn <table> đấy các bạn, vì mô hình DOM duyệt <table> khá chậm và các trình duyệt phổ biến hiện nay có xu hướng chuộng <div> hơn.

Page Speed nhanh là một lợi thế SEO của trang web, vì vậy trong thiết kế web chuyên nghiệp người ta chọn <div> nhiều hơn.

Phù hợp với CSS:
Vấn đề này thì không cần giải thích vì <div> mang một lợi thế mạnh hơn hẳn so với <table>. <div> và css như hai cái chân của một người vậy, thiếu 1 cái thì di chuyển không biết sao đây, hoặc nếu thay thế 1 chân bằng cây gậy, dù đi được nhưng không thể chạy được.
Trên đây là những so sánh cơ bản về <div> và <table> có ảnh hướng đến SEO chuyên nghiệp, nhưng việc lựa chọn còn tùy thuộc vào nhiều yếu tố khác nữa, đặc biệt là yếu tố thói quen của người dùng.

Các bạn hãy cùng chia sẻ ý kiến riêng của mình để cùng giúp nhau thăng tiến về HTML trong SEO WEB chuyên nghiệp.

nguồn Seoweb24h.com

Read More