Trong SEO, chúng tôi sử dụng rất nhiều công cụ khác nhau để phân tích và đánh giá, để có cái nhìn đầy đủ hơn về các vấn đề kĩ thuật có thể gây hại cho hệ thống của mình: có thể là phân tích web, chuẩn đoán, thu thập dữ liệu, các công cụ Google Webmaster, Bing... Tôi tin rằng các công cụ này rất hữu ích cho tất cả chúng ta, nhưng tôi cũng khá chắc chắn rằng có những lỗ hổng trong dữ liệu do các công cụ này thu thập và có thể không chính xác. Chỉ có một dữ liệu cho phép bạn biết nhiều thông tin về search engine một cách chắn chắn, chẳng hạn như các crawler đã thu thập dữ liệu trên website bạn như thế nào - đó chính là server log.

Một bản ghi log của một máy chủ(hay còn gọi là nhật ký máy chủ, server log) là một bản ghi toàn vẹn những hành động được thực hiện bởi một máy chủ cụ thể. Trong trường hợp đó là một máy chủ web, bạn có thể sẽ nhận được nhiều thông tin hữu ích trên đó. Trong thực tế, những ngày trước khi có những công cụ phân tích web miễn phí như Google Analytics, những công cụ phân tích nội tại của hệ thống máy chủ đã được sử dụng, điển hình như công cụ AWStats có thể cung cấp cho bạn chi tiết về số lượng người dùng truy cập site hàng ngày và còn nhiều hơn thế nữa.


Ban đầu, tôi định viết một bài viết về chủ đề này, nhưng sau khi phân tích và nhìn nhận tôi nhận ra rằng có rất nhiều vấn đề dàn trải cần được đề cập, nên tôi sẽ chia bài viết của mình thành 2 phần, mỗi phần tôi sẽ làm nổi bật một số vấn đề khác nhau được tìm thấy trong server log.

  • Bài này: làm thế nào để lấy và phân tích một tệp tin log và xác thực các vấn đề dựa vào mã phản hồi của máy chủ (ví dụ 404, 302, 500...).
  • Bài tiếp: xác định nội dung trùng lặp, tạo điều kiện để SE thu thập dữ liệu, xem xét các xu hướng, tìm ra các mô hình và một vài mẹo nhỏ không liên quan gì đến SEO.


Bước 1: lấy file Server log

Web server log có thể có nhiều định dạng khác nhau, các cách đọc khác nhau tùy thuộc vào hệ thống, hệ điều hành... của máy chủ bạn sử dụng. Trong đó, Apache và Microsoft IIS là phổ biến nhất. Trong bài viết này, tôi sẽ phân tích file log trên Apache được SEOmoz gửi đến.

Nếu bạn làm việc trong một công ty lớn và có một Sys Admin, thật tuyệt, bạn có thể hỏi anh ta(hoặc cô ta - nhưng chắc hơi hiếm) về file log của một ngày với các thông số được tôi liệt kê dưới đây. Tôi khuyên các bạn nên giữ kích thước của tập tin log dưới 1Gb để tránh làm nghẽn khi đọc và phân tích. Nếu bạn có quyền tạo log, bạn có thể tạo ra các file log trong chính host mà bạn đang sử dụng. Một vài dịch vụ lưu trữ chúng trong thư mục /logs và đưa vào đó những file log đã được nén theo từng ngày - bạn có thể sử dụng chúng. Nhưng hãy chắc chắn dữ liệu của bạn bao gồm:

  • Host: bạn sử dụng nó để lọc thông tin nội bộ trong máy chủ. Trong trường hợp của SEOMoz, Rogerbot Crawler dành nhiều thời gian để thu thập trang web khác nhau, nên chúng tôi sử dụng yếu tố này để loại bỏ trong phân tích của chúng tôi.
  • Date: Nếu bạn đang phân tích nhiều ngày, chúng sẽ cho bạn xu hướng.
  • Page/File: thứ này sẽ cho bạn biết những trang, thư mục này được thu thập và có thể giúp xác định các vấn đề tồn tại ở các phần nhất định trên trang hoặc ở một loạt nội dung nào đó.
  • Response code: hay còn được biết đến như phản ứng cua máy chủ: trang nạp tốt(200), lỗi không tìm thấy (404), máy chủ down(503)... - những thông tin này rất giá trị đối với người làm SEO khi phân tích quá trình thu thập dữ liệu.
  • Referrers: thông tin này tuơng đối không có giá trị khi phân tích quá trình thu thập dữ liệu. Tuy nhiên nó có thể giúp xác định được lưu lượng truy cập từ các nguồn khác đến.
  • User Agent: thông tin này cho bạn biết request nào là từ công cụ tìm kiếm, request nào không phải. Đây là điều mà hiện nay các công cụ phân tích và thu thập dữ liệu chưa làm được.



Theo mặc định Apache log file sẽ không có User Agent hoặc Referrer. Hai thông tin này có thể được tìm thấy trong một hệ thống log khác được gọi là common log file. Bạn cần phải thực hiện việc kết hợp 2 log file này lại để có một báo cáo đầy đủ như những gì chúng ta đã liệt kê ở trên. Bạn có thể nhờ Sys Admin của mình thực hiện việc này hoặc nếu không, bạn có thể gây ấn tượng với anh ta bằng cách sử dụng đoạn lệnh sau:




Mã:
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\""
Đối với Apache 1.3 bạn có thể sử dụng "combined CustomLog log/acces_log combined" để kết hợp.

Đối với những người sử dụng công cụ kéo thả, bạn có thể tiến hành chỉnh lại file httpd.conf để tạo ra các lệnh chỉ thị thực hiện việc này. Bạn có thể xem thêm chi tiết về việc này tại đây.

Bước 2: Phân tích một tập tin log

Bây giờ, bạn có thể đã có trong tay một tập tin log ở dạng nén với tên vnwebmaster_com.gz chẳng hạn, và bây giờ đã đến lúc chúng ta môt xẻ nó ra. Có rất nhiều phần mềm, trang web cho phép bạn phân tích theo cú pháp của một file log. Tiêu chí chính mà chúng tôi dùng để tìm kiếm phần mềm phù hợp bao gồm: khả năng phân tích dữ liệu thô, khả năng lọc trước khi phân tích cú pháp và khả năng xuất ra định dạng CSV. Tôi đã quyết định chọn Web Log Explorer và nó đã làm việc cho tôi trong nhiều năm nay. Tôi sẽ sử dụng nó cùng với Excel để vẽ biểu đồ trong phân tích này. Cũng cần nói thêm rằng tôi đã sử dụng AWstats cho các phân tích cơ bản, nhưng tôi nhận ra rằng nó không cung cấp mức độ kiểm soát và linh hoạt mà tôi cần.

Bước đầu tiên là nhập dữ liệu vào phần mềm cung cấp cú pháp của bạn. Hầu hết các phần mềm phân tích log đều cho phép bạn nhập với nhiều định dạng log khác nhau và có một phần trợ giúp từng bước(simpe wizard) cho phép bạn nhập liệu một cách dễ dàng. Với lần đầu tiên phân tích, tôi xem hết tất cả dữ liệu và không sử dụng bất kì bộ lọc nào. Tại thời điểm này bạn có thể làm một trong hai điều: chuẩn bị bộ lọc để phân tích tiếp và xuất bản để phân tích trong Excel hoặc làm phần lớn các phân tích trong dữ liệu của mình. Tôi thích làm phần lớn công việc trong Excel để tạo ra các biểu đồ xu hướng(tôi sẽ nhận được điều này trong bài tiếp theo). Nếu bạn muốn phân tích nhanh chóng các bản ghi của bạn, sử dụng phần mềm phân tích cú pháp log là một lựa chọn không tồi.

Thủ thuật nhập dữ liệu: hãy chắc chắn rằng bạn có đưa vào các biến trong URL. Tôi sẽ cho bạn thấy trong bài viết sau các vấn đề khi thu thập dữ liệu, các nguồn trùng lắp dữ liệu như thế nào.

​
Bạn có thể lựa chọn lọc dữ liệu theo các biểu thức chính qui cơ bản trước khi phân tích dữ liệu. Ví dụ chúng ta cần phân tích lưu lượng truy cập đến một phần cụ thể nào đó trên trang web, chúng ta có thể làm như sau:


​
Một khi bạn có tất cả dữ liệu đã được tải lên, hãy xuất tất cả các yêu cầu xuất phát từ spider ra, bao gồm cả các mã phản hồi từ máy chủ (response code):

​
Và sau khi xuất tất cả các tập tin ra dạng CSV và mở bằng Excel, dưới đây là một số bước để dữ liệu sẵn sàng cho việc phân tích và tái phân tích.

1. Page/File: trong phân tích của chúng tôi, chúng tôi cố gắng tìm kiếm thông tin trong các thư mục mà chúng tôi nghi ngờ là có vấn đề. Vì vậy, chúng tôi cố gắng cô lập các thư mục từ tập tin. Công thức được chúng tôi sử dụng trong Excel tương tự như thế này:




Mã:
=IF(ISNUMBER(SEARCH("/",C29,2)),MID(C29,(SEARCH("/",C29)),(SEARCH("/",C29,(SEARCH("/",C29)+1)))-(SEARCH("/",C29))),"no directory")
2. User Agent: để hạn chế phân tích, chúng tôi chỉ phân tích những máy chủ tìm kiếm cụ thể mà chúng tôi quan tâm và bỏ qua những máy chủ khác không cần thiết Trong trường hợp này, chúng tôi chỉ phân tích các công cụ tìm kiếm sau: Googlebot, Googlebot-Images, BingBot, Yahoo, Yandex và Baidu.

Đây là công thức Excel:




Mã:
=IF(ISNUMBER(SEARCH("googlebot-image",H29)),"GoogleBot-Image", IF(ISNUMBER(SEARCH("googlebot",H29)),"GoogleBot",IF(ISNUMBER(SEARCH("bing",H29)),"BingBot",IF(ISNUMBER(SEARCH("Yahoo",H29)),"Yahoo", IF(ISNUMBER(SEARCH("yandex",H29)),"yandex",IF(ISNUMBER(SEARCH("baidu",H29)),"Baidu", "other"))))))
Bây giờ, nếu log của bạn đã sẵn sàng cho việc phân tích, bạn sẽ có một bảng như thế này:

​
Bước 3: Khám phá máy chủ và các lỗi phản hồi

Cách nhanh chóng để tìm ra các vấn đề mà công cụ tìm kiếm gặp phải khi thu thập dữ liệu đó là nhìn vào các mã phản hồi từ máy chủ. Quá nhiều 404(Page not found) nghĩa là nguồn tài nguyên thu thập dữ liệu đang bị lãng phí, chuyển hướng 302 nhiều có thể được trỏ đến từ một liên kết quan trọng đã chết nào đó... Trong khi Google Webmaster Tools cung cấp các thông tin như vậy; nó không cung cấp một cách hoàn chỉnh. Còn ở đây: LOG không nói dối !

Bước đầu tiên để phân tích là tạo ra một bảng mục từ dữ liệu log của bạn. Mục tiêu của chúng ta ở đây là cô lập các con nhện tìm kiếm cùng với mã phản hồi từ máy chủ tương ứng. Chọn tất cả dữ liệu của bạn và vào Data -> Pivot Table

Ở cấp độ cơ bản nhất, chúng ta sẽ công cụ tìm kiếm nào đã vào SEOmoz vào ngày đặc biệt này:

​
Không có một kết luận chắc chắn nào ở đây, tuy nhiên có vài điểm chúng ta có thể lưu tâm tới để phân tích sâu hơn. Đầu tiên, BingBot đã crawl đến 80% hệ thống. Tại sao? Thứ hai, other chiếm hơm một nửa số lượng, chúng ta đã bỏ lỡ mất một User Agent nào đó quan trọng chăng ? Sau này, chúng tôi nhận ra rằng RogerBot đã chiếm hơn một nữa tương ứng với phần other. Tuy nhiên, do mục đích của mình chúng tôi đã loại bỏ nó như đã nói ở trên.

Tiếp theo hãy cùng quan sát mã phản hồi từ máy chủ.

​
Tôi đã nêu bật những vấn đề mà chúng ta muốn có cái nhìn rõ hơn về nó. Nhìn chung, tỉ lệ xấu không cao lắm và khôg ảnh hưởng nhiều. Tuy nhiên, chúng ta sống với câu thần chú "mỗi chút nhỏ đều có ích" nên chúng ta sẽ cố gắng tìm ra những gì đang xảy ra với mỗi chút nhỏ như vậy.

1. Tại sao Bing thu thập dữ liệu gấp 2 lần Google ? Chúng ta nên điều tra xem nếu Bing crawl không hiệu quả bằng Google thì những điều gì chúng ta có thể giúp họ thu thập dữ liệu tốt hơn. Hoặc nếu Google không scrawl sâu như Bing thì điều gì sẽ giúp họ crawl dữ liệu sâu như Bing để thu thập dữ liệu nhiều hơn.

Bằng cách loại ra các trang có mã phản hồi thành công(200) của BingBot để tìm ra thủ phạm, tất cả đã rõ ràng. Gần 60.000 liên kết trong tổng số 100.000 liên kết được Bing crawl đã chuyển hướng người dùng đến đăng nhập từ một liên kết bình luận.

​
Vấn đề: SEOMoz là một kiến trúc mà khi bình luận bạn phải đăng nhập, và nếu Javascript không được kích hoạt, nó sẽ yêu cầu một liên kết chuyển hướng người dùng được phục vụ và phản hồi với mã 200 như một liên kết bình thường cho một trang báo lỗi. Với gần 60.000 lần thu thập dữ liệu đi đến đây và kết thúc, đây là một nguồn thu thập dữ liệu lớn bị lãng phí. Điều quan trọng là SEOMoz chặn các công cụ crawl ở trang đấy.

Giải pháp: thêm rel="nofollow" cho tất cả các bình luận và trả lời bình luận có chứa liên kết. Thông thường phương pháp đơn giản và thường được sử dụng nhất là chỉ thị cho các robot thu thập dữ liệu không quét các liên kết trong bình luận là thông qua tập tin robots.txt. Thật không may, điều này sẽ không thể thực hiện được trong trường hợp này vì URL được thực thi thông qua mã Javascript sau khi nhấp chuột.

GoogleBot đối phó với các bình luận tốt hơn so với BingBot và tránh chúng hoàn toàn. Tuy nhiên, Google vẫn đang crawl một số liên kết chuyển hướng đến trang đăng nhập. Lướt qua file robots.txt một chút và tôi cho rằng liên kết đó nên được chặn lại.

2. Số lượng mã phản hồi 302 của Google và Bing là chấp nhận được. Nó cũng không làm ảnh hưởng hệ thống nhiều đến mức cần được xem xét lại trong khi có những cách khác, cái khác có thể xử lý và làm tác động ngược lại đến nó.

3. Dữ liệu có giá trị nhất mà bạn nhận được thông qua việc đọc các bản log của máy chủ đó là có thể ghi nhận được việc giải quyết các lỗi 404 thông qua việc thu thập dữ liệu. SEOMoz đã làm rất tốt việc này và không có một mức độ đáng báo động nào đối với các lỗi 404. Một cách nhanh chóng để giải quyết các vấn đề tiềm năng có thể xảy ra đó là cô lập các thư mục 404. Điều này có thể thực hiện được bằng cách tạo ra một pivot table với label "Directory" với số lượng danh mục trong một lĩnh vực có giá trị của bạn. Bạn sẽ nhận ra cái gì đó như:

​
Vấn đề: Vấn đề lớn nhất ở đây là 90% các lỗi 404 xuất phát từ danh mục comments.Với các phân tích về BingBot và chuyển hướng Javascript đã nói ở trên thì số liệu này không có gì đáng ngạc nhiên.

Giải pháp: tin tốt lành là sau khi chúng tôi đặt rel="nofollow" trên những nhận xét, số lượng 404 được giảm đáng kể và đang được chăm sóc tốt.

Kết luận:

Google, Bing cung cấp cho bạn các thông tin về lỗi thu thập dữ liệu, nhưng trong nhiều trường hợp họ giới hạn dữ liệu. SEOer như chúng ta nên tận dụng tất cả các nguồn dữ liệu có thể để phân tích báo cáo. Và chỉ có một loại dữ liệu bạn có thể tin tưởng được: dữ liệu của bạn.

Và hãy nhớ: LOG không bao giờ nói dối!

Còn tiếp phần 2...

Tác giả: Tim Resnik
Nguồn: SEOMOz