Trí Tuệ Nhân Tạo

Home Top Ad

Responsive Ads Here

Thời gian tải trang và hiển thị màn hình của toilaquantri.com Mô phỏng quá trình truy cập website của trình duyệt Đầu tiên khi bạn truy cập ...

Tốc độ tải Website phụ thuộc vào gì? DNS, Hosting

Tốc độ tải Website phụ thuộc vào gì?
Thời gian tải trang và hiển thị màn hình của toilaquantri.com

Mô phỏng quá trình truy cập website của trình duyệt

Đầu tiên khi bạn truy cập 1 trang website nào đó ví dụ như Website https://www.toilaquantri.com/ trên trình duyệt Chrome xem như mà mới nhất hiện tại.

Ngay lặp tức trình duyệt đó sẽ gởi yêu cầu vượt qua tường lửa (Firewall) của máy tính và cho phép truy cập vào internet. (Firewall) - Bất kì máy tính nào kết nối tới Internet cũng cần có filewall, giúp quản lý những gì được phép vào mạng và những gì được phép ra khỏi mạng. Ngăn chặn các truy cập bất hợp lệ truy cập vào internet.


Tên miền https://www.toilaquantri.com/ được phân giải ra thành IP tương ứng để truy cập tới máy chủ gọi DNS (Phân giải tên miền) => Do vậy quá trình phân giải tên miền sẽ mất 1 khoảng thời gian truy cập web (1)

IP là địa chỉ truy cập tới máy chủ tên miền
>> Xem chi tiết về IP: Tìm hiểu về địa chỉ IPv4 (Phân lớp IP, Subnet Mask, Địa chỉ MAC)

Ví dụ như Website toilaquantri.com đặt tại Server của Google đang đặt tại California/Mỹ tại TP Mountain View.


Dựa tên giao thức https. Ngay lập tức trình duyệt sẽ gởi yêu cầu đến Server sẽ trả về thông tin truy cập của người dùng kèm Cookie để file nào được tải về File nào được lấy từ bộ nhớ đệm đã lưu trước đó thông qua Cookie

– Tiếp đến, máy chủ sẽ gửi một file văn bản có các thẻ HTML đến trình duyệt web của bạn (một cookies khác cũng được gửi kèm theo từ máy chủ tới trình duyệt web, cookies này được ghi trên đầu trang của mỗi trang web).

– Trình duyệt web đọc các thẻ HTML để xác lập định dạng (hình thức trình bày) trang web và kết xuất nội dung trang ra màn hình của bạn.
  • Sẽ mất 1 khoảng thời gian để Server trả về thông tin gọi là Thời gian hồi đáp Server hay gọi là phản hồi máy chủ (2)
  • Tốc độ đường truyền mạng và khoảng cách để truyền về. (3)
  • Thời gian phân giải code của trình duyệt và hiển thị ra ngoài màn hình (4)

Thời gian phản hồi máy chủ (Hồi đáp Server)

Thời gian phản hồi của máy chủ đo thời gian cần để tải HTML cần thiết để bắt đầu hiển thị trang từ máy chủ của bạn, trừ đi độ trễ mạng giữa Google và máy chủ của bạn. Có thể có sự khác biệt từ lần chạy này đến lần chạy tiếp theo, nhưng sự khác biệt không nên quá lớn. Thời gian này dưới 200ms là đạt yêu cầu.

Độ trễ mạng

Độ trễ được đo bằng cách xác định thời gian cần để 01 gói dữ liệu mạng đi tới đích và trở về điểm xuất phát ban đầu.

Hồi đáp Server = Thời gian tải HTML của Website - Độ trễ mạng (giữa Google và Server bạn đặt)

Thời gian chuyển hướng trang đích


Giả sử bạn truy cập vào địa chỉ http://www.toilaquantri.com (Không có HTTPS) -> sau đó sẽ chuyển tiếp sang trang https://www.toilaquantri.com/ (Có HTTPS) mà mình đã sẽ mặc định sẽ tốn thêm 1 khoảng thời gian gọi là thời gian chuyển hướng trang đích (5)

Thời gian tải Website thực tế

Thời gian để trình duyệt gởi yêu cầu vào Internet + Phân giải tên miền thành IP (DNS) + Truy cập để máy chủ hồi đáp + Độ trễ mạng (Trả thông tin và tải về trình duyệt) + Trình duyệt đọc code là hiển thị.
Thực tế tốc độ tải Website phụ thuộc vào cả người chủ website lẫn người dùng chứ không thuộc về riêng một công cụ test tốc độ website nào cả.

Tối ưu Website Đối với chủ Website:

  1. Thực tế là bạn nên đặt máy chủ gần vị trí của người dùng để có thời gian tải dữ liệu từ máy chủ về nhanh nhất. Ở VN thì nên đặt máy chủ ở VN hoặc gần nhất là Singapore hoặc Hồng Kông thuộc châu Á.
  2. Sử dụng Hosting/Server có băng thông cao, CPU mạnh để xử lý yêu cầu nhanh chóng.
  3. Tối ưu Code Website và dữ liệu để giảm dung lượng tải về (Code web, hình ảnh, video..)
  4. Xử lí lưu Cache để lưu vào bộ nhớ đệm người dùng tránh tải trực tiếp từ Server các nội dung ít thay đổi.

Đối với người dùng để tăng tốc độ tải Website

  1. Sử dụng trình duyệt mới nhất để phân giải code nhanh như Google Chrome, Firefox
  2. Sử dụng mạng nhanh, độ trễ mạng thấp, băng thông cao.
  3. Dùng máy tính cấu hình mạnh, dung lượng ram cao. Dùng ổ cứng SSD cho tốc độ đọc ghi nhanh hơn 6 lần HDD và thực tế cho thấy máy tính mạnh tải website nhanh hơn rất nhiều so với máy tính cấu hình yếu.
  4. Cài đặt DNS phân giải nhanh ưu tiên dùng Google 8.8.8.8 - 8.8.4.4 vì hiện cho tốc độ nhanh nhất.

Một số DNS có tốc độ nhanh được liệt kê có thể sử dụng:

Tốc độ tải trang test với Toilaquantri.com

Sau khi tìm hiểu quá trình tải website và ứng dụng toàn bộ quá trình tải trang có thể thấy ban đầu Website toilaquantri.com cho ra thời gian tải toàn trang là 6.5s (ảnh đầu bài) -> giảm xuống còn 3.5s.

Mình rất vui khi làm được điều này.



Đánh giá tốc độ website theo thời gian

  • Thời gian tải trang từ 0-4s => Tốt
  • Thời gian tải trang từ 4-6s => Trung bình
  • Thời gian tải trang trên >6s => Quá tệ cần phải tối ưu tốc độ website
Nếu bạn muốn website mình có tốc độ tải trang nhanh hơn có thể liên hệ dịch vụ tối ưu Tốc độ Website của mình!
  • Email: Haiphungmarketing@gmail.com
  • SĐT: 0932.913.631 (Mr Phụng)

Gần đây Google Pagespeed Insights đã đưa ra 2 dữ liệu thực là FCP DCL khi kiểm tra website với Google Pagespeed Insights. Bước đầu Google đã...

FCP DCL là gì? trong Google Pagespeed Insights

Gần đây Google Pagespeed Insights đã đưa ra 2 dữ liệu thực là FCP DCL khi kiểm tra website với Google Pagespeed Insights.

Bước đầu Google đã đưa tốc độ tải trang trên Mobile (Di động) vào một trong các yếu tố xếp hạng website trên Google (SEO) động thái này cho rằng bạn phải làm cho Website thật nhanh lên nữa trên Mobile khi mà tốc độ phát triển, traffic từ Mobile đã vượt qua Desktop.

FCP DCL trong Google Pagespeed Insights
FCP DCL trong Google Pagespeed Insights

FCP là gì?

1. FCP (First Contentful Paint): Thời gian phản hồi nội dung đầu tiên của website (có thể hiểu load hoàn chỉnh thành phần đầu tiên của website).

Thành phần này là đối tượng đầu tiên hiển thị trên trình duyệt.

Ví dụ: Website của mình phải tải qua 1 loạt Meta tags, sau đó tải CSS sau đó mới HTML thì lúc đó thành phần đầu tiên mới tải xong => Quá chậm.

Vì vậy bạn phải đưa các thành phần HTML lên đầu <html> thì càng tốt.

Thang thời gian Xếp hạng FCP

  • Fast: Time FCP mobile < 1.6s & desktop < 1.0s (Nhanh)
  • Average: Time FCP mobile < 3.0s & desktop < 2.1s (Trung bình)
  • Slow: Time FCP mobile > 3.0s & desktop > 2.1s (Chậm)

Trên Thiết bị di động, website toilaquantri.com có:
FCP = 1.3s < 1.6s => Nhanh (xanh)

DCL là gì?

DCL (DOM Content Loaded)
Trong đó:
  • DOM (Document Object Model: Mô hình đối tượng tài liệu) + Content Loaded (Nội dung tải hoàn chỉnh)
  • Khi tài liệu HTML được tải và phân tích cú pháp
HTML ban đầu đã được tải và phân tích cú pháp hoàn chỉnh (có thể hiểu là load được hết layout)

Thang thời gian Xếp hạng DCL

  • Fast: Time FCP mobile < 2.1s & desktop < 1.4s
  • Average: Time FCP mobile < 4.2s & desktop < 2.8s
  • Slow: Time FCP mobile > 4.2s & desktop > 2.8s

Trên Mobile thì website toilaquantri.com có DCL = 3.7s. Nằm giữa khoảng 2.8s và 4.2s nên đạt trung bình.

FCP DCL sẽ thu thập trong vòng 30 ngày của website bạn nên sẽ có website hiển thị website chưa hiển thị được.

Ngoài ra còn có các chỉ số khác như Tối ưu hóa FMP / TTI chứ không chỉ là FCP DCL (xem ảnh trên đầu bài sẽ rõ)

Google đưa ra bài nghiên cứu của mình tại đây: 

Text/HTML ratio là gì? Text/HTML ratio là tỉ lệ giữ Text so với Code HTML trong trang website . Theo đề xuất của công cụ SEOquake thì tỉ lệ ...

Tối ưu Text/HTML ratio để tối ưu SEO Audit #5

Text/HTML ratio là gì?

Text/HTML ratio là tỉ lệ giữ Text so với Code HTML trong trang website. Theo đề xuất của công cụ SEOquake thì tỉ lệ này không được dưới 15% mới tốt cho SEO.

Chỉ số Text/HTML ratio được đưa ra là nhằm giảm thiểu dung lượng code, tăng tỉ lệ text để người dùng đọc => trải nghiệm người dùng => Tăng Time Onsite => Chuẩn SEO Onpage.

=> Text/HTML ratio được tích bằng dung lượng kb chứ không tin bằng thời gian tải trang hay diện tích. 

Mình có thử là chỉnh font chữ to lên trong bài viết nhưng tỉ lệ Text/HTML không những không tăng mà còn giảm, vì vậy tỉ lệ này được tính bằng thương số của dung lượng.
Tối ưu Text/HTML ratio
Tối ưu Text/HTML ratio

Tools check Text/HTML ratio

Giới thiệu từ tools test Text/HTML Small SEO Tools:

Chúng tôi muốn cung cấp cho bạn những công cụ tốt nhất mà bạn có thể sử dụng để tối ưu hóa trang web của mình và Bộ kiểm tra tỷ lệ mã văn bản này là một trong số chúng.
Các nhà phát triển của chúng tôi đã tạo công cụ này để cung cấp cho chủ sở hữu trang web, quản trị viên web và chuyên gia SEO một mã kiểm tra tỷ lệ văn bản nhanh và đáng tin cậy.
Để sử dụng công cụ này, chỉ cần nhập URL của bất kỳ trang web nào và nhấp vào nút "Kiểm tra". Hệ thống của chúng tôi sẽ xử lý yêu cầu của bạn và sẽ hiển thị cho bạn kết quả ngay lập tức. Nó sẽ cung cấp cho bạn các chi tiết sau đây về trang web của bạn:
  • Kích thước trang
  • Kích thước mã
  • Cỡ chữ
  • Tỷ lệ mã thành văn bản

Ví dụ 1:
Text: 10kb và HTML là 100kb thì kết quả: Text/HTML ratio = 10% < 15% chưa đạt yêu cầu.

=> Như vậy để tối ưu Text/HTML ratio là phải tăng dung lượng Text hoặc giảm dung lượng HTML hoặc đồng thời cả 2.

Ví dụ 2: https://www.toilaquantri.com/2018/06/chuyen-gia-ninh-mang-phan-tich-khuyen-diem-luat-an-ninh-mang-mang-VN.html

Mình tiến hành kiểm tra tỉ lệ Text/HTML ratio (với SEOquake) = 21.03% khá chuẩn vì đây là một bài viết độ dài tương đối với khá nhiều chữ.


Ví dụ 3: https://www.toilaquantri.com/2018/05/thuc-hien-seo-audit-website-qua-7-buoc.html

Đây là một bài viết với độ dài trung bình và 90% các bài viết trên trang blog của mình có độ dài như thế này thì tỉ lệ Text/HTML ratio = 10.76% => Quá tệ.

Vì sao mình lại đề xuất tỉ lệ Text/HTML ratio?

Vì đây là chỉ số cuối cùng mà Website toilaquantri.com chưa tối ưu được, các phần lại mình đã tối ưu hết cả rồi. Bạn có thể kiểm tra bất kì bài viết nào trên website của mình với SEOquake và chỉ lỗi Text/HTML nữa mà thôi.

Và cả SEOquake, Small SEO tools đều đưa ra chỉ số này trong SEO Audit.

Giải pháp tăng Text/HTML ratio lên 15%

#1: Viết bài dài hơn từ 1000 từ trở lên

Chuyện này thì quá đơn giản ai làm cũng được. Trước đây bạn đã từng nghe nói là phải viết bài dài hơn mới chuẩn SEO và giờ đây mình khuyến khích bạn viết dài hơn chỉ đề tối ưu Text/HTML ratio.

Hiệu quả như thế nào bạn cứ tự trãi nghiệm nhé, mình vẫn theo triết lí Content là vua mà.

Viết dài nhưng hay và hấp dẫn chứ đừng viết dài mà dở.

#2: Giảm HTML để tăng Text/HTML

Một việc không ngờ đến là Website sử dụng càng nhiều ảnh lại càng dễ thiếu thẻ Alt và làm tăng HTML làm Website nặng đi, tải trang lâu hơn.

Ngoài code HTML thì ảnh là kẻ thù của Text/HTML ratio. Nên mình đã thử tắt hiện thị ảnh trên tiện tích Bài viết xem nhiều và tỉ lệ có tăng từ 10.76% -> 11.41% => Vậy là HTML có liên quan tới ảnh sẽ làm tăng HTML lên.

Việc giảm code HTML như xóa bớt Javascript, nén CSS, HTML không dùng đến cũng là giải pháp tuy nhiên sẽ mất thời gian nhiều và áp dụng cho các bạn rành code. Đặc biệt là treo quá nhiều quảng cáo chứa Javascript như Google Adwords ở website của mình cũng làm giảm đáng kể Text/HTML.

Đối với Wordpress hãy sử dụng các Plugin hỗ trợ để nén HTML, CSS, Gzip để nhé!

#3 Gia tăng Text tự động

Mình đã dùng bài viết liên quan gọi ta các tiêu đề chỉ là chữ (text) liên quan đến từ nhãn trong bài viết và đặt 3 nhãn.

Thì thấy tỷ lệ đã tăng thêm 1% :D

Khá chua là khi gọi ra thêm text thì lại tốn thêm Javascript lại tăng thêm nên thương số Text/HTML mới tăng ít như vậy :)))

Bài viết liên quan gọi đa nhãn để tăng Text
Bạn có thể sử dụng bài viết liên quan chỉ gọi text giống như mình để tăng thêm text.

Kết luận:
  • Viết bài dài hơn 20-50% so với hiện tại
  • Nén ảnh trước khi dùng
  • Nén HTML, CSS, Javascript, Gzip...vv các kĩ thuật để giảm tải trang
  • Hạn chế các mã quảng cáo. Website mình dùng Google Adsense nên tỉ lệ này khá nhiều chứ thật ra trang toilaquantri.com tối ưu khá tốt
  • vv

Entity Building là khái niệm khá mới mẻ mà mình gặp lần đầu tiên được định nghĩa với cty GTV và hầu như chỉ có bên GTV chia sẻ khái niệm này...

Entity building Google là gì? Góc nhìn Marketing và Coder

Entity Building là khái niệm khá mới mẻ mà mình gặp lần đầu tiên được định nghĩa với cty GTV và hầu như chỉ có bên GTV chia sẻ khái niệm này.

Có nhiều bạn thắc mắc Entity khái niệm khá mới mẻ nhưng qua tìm hiểu thì chỉ triển khai Schema thì lí do tại sao?. Cách đặt tên cũng có lí do như sau:

Entity Building có thể hiểu rằng khai báo các thông tin tồn tại trên Website và trên các MXH hoặc trích dẫn nội dung hữu ích khác trên internet từ bên ngoài có lợi cho SEO theo các dữ liệu có cấu trúc dữ liệu. Nhằm để giúp Google hiểu, thu thập và hiểu thông tin đó nhanh chóng. 

Google cũng cung cấp "Trình đánh dấu siêu văn bản" trong Webmaster Tools để định nghĩa các văn bản này. Rõ ràng Google muốn chúng ta định nghĩa một lần nữa các văn bản này.

Entity Building là gì?

Entity (Thực thể) Building (Xây dựng): Xây dựng các thực thể để gia tăng sự tin cậy với Google.
Giả sử bạn kinh doanh một mặt hàng nào đó với tư cách là cty có tư cách pháp nhân hẳn hoi, có địa chỉ (mặt bằng) kinh doanh và với nền tảng kinh doanh lâu năm thì nó sẽ làm tăng sự tin tưởng của KH vào sản phẩm và đơn vị kinh doanh.

Thì các nền tảng để tạo sự tin cậy đó gọi là thực thể.

Thì Entity building cũng thế. Entity thực chất là khai báo các dữ liệu Siêu cấu trúc dữ liệu (Schema, Microformats...) nhằm xác định các thông tin trên Website như về Dịch vụ, Địa chỉ kinh doanh (Local SEO..), giá bán, hình ảnh, đánh giá..vv thông qua cấu trúc dữ liệu Schema.

Một phần nữa trong dữ liệu Schema thì mình vừa tìm hiểu và triển khai dữ liệu Microfomats (click để xem).
Schema Galaxy mà Google muốn thu thập
Schema Galaxy mà Google muốn thu thập

Các SEOer hiện nay lại không biết nhiều về cấu trúc web và tối ưu Website nên xem nhẹ những cấu trúc dữ liệu vốn là thông tin để giao tiếp nhanh chóng với Google và sự tối ưu Web mà thiên về áp dụng Backlink. Lạm dụng quá đà vào các Tools như GSA để bắn link.

Như một bài viết trước mình đã chia sẻ SEO 2018 thì content là vua hay backlink là vua mình đã nói lên 3 quan điểm của mình.

Sơ lược về cách mà Schema giới thiệu

Rõ ràng theo Schema.org giới thiệu không chỉ đánh dấu thực thể mà còn đánh dấu cả các hành động, các app ứng dụng khác.

Hành động đó biểu hiện qua dữ liệu SearchAction để thu thập hành động tìm kiếm trên website và các app ứng dụng.

Những website đánh mạnh về tin tức, content (build internal link) hoặc triển khai social nhiều thì khi triển khai Schema có thể sẽ làm gia tăng thứ hạng tổng thể thấy rõ rệt nhất. 
Những Website ít nội dung thì kết quả sẽ chậm thấy và tăng nhẹ hơn. Và cái tên Entity đặt là khá hay

Triển khai Schema (Entity Building) cũng chỉ là 1 bước trong quy trình 7 bước thuộc về SEO Audit mà mình chia sẻ tại Serie về >> SEO Audit << mà mình khuyên bạn nên áp dụng nghiêm ngặt mình luôn sử dụng SEO Audit hầu hết các dự án.

Tuy nhiên triển khai Schema cũng không mất thời gian mấy nên bạn cứ việc áp dụng và khi triển khai SEO Audit bất cứ mọi thứ liên quan đến tối ưu code website mình sẽ thử nghiệm và chia sẻ kết quả.

Như vậy Schema mang hàm nghĩa rộng hơn Entity nhiều.

Phân nhóm Schema để triển khai cho Website.

Một số lưu ý khi triển khai
Hạn chế dùng code cứng mà nên dùng các hàm gọi dữ liệu
Ví dụ để điền tên tác giả thay vì nhập Huỳnh Phụng Blogger thì ta dùng hàm gọi tên tác giả <data:blog.author/>
Các hàm thường áp dụng để gọi dữ liệu có cấu trúc bên dưới như sau:
  1. Gọi URL bài viết
  2. Gọi Tiêu đề Website
  3. Gọi ảnh đầu tiên của bài viết
  4. Gọi tên tác giả của bài viết
  5. Gọi mô tả trang web
Mình chỉ rành các hàm gọi dữ liệu của Blogger nên không thể hướng dẫn nền tảng Wordpress cho bạn được.
Các hàm gọi dữ liệu blogger xem tại: Tổng hợp hàm gọi dữ liệu Blogger

Mình phân thành 6 nhóm dữ liệu để các bạn dễ dàng triển khai:
  • Từ nhóm 1 đến nhóm 4: Bất kì website nào cũng nên áp dụng bất kì nền tảng web nào
  • Nhóm 5,6: Tùy chỉnh theo loại hình kinh doanh, dịch vụ của website với từng nhóm ngành..

Nhóm 1: Schema cho cấu trúc Website (5)

Áp dụng toàn trang
Khi lập trình website bạn phải khai báo các Header-wrapper, Sidebar-Wrapper, Footer-Wrapper, Nav (Menu), Boby.

Thói quen dùng <div> khai báo chuyển sang thành <nav> <header> <aside> <main> <footer> được mô tả như sau:

Theo dõi cách mà mình khai báo cấu trúc website có Schema nhé:

Khai báo Schema trong cấu trúc Website


Nhóm 2: Schema Organization: Khai báo thông tin tổ chức, cty (1)

  • Bao gồm: Email, SĐT, số Fax, Địa chỉ, Tên gọi tổ chức (nhớ thay lại giá trị)
  • Cấu trúc này đặt trước </head>
  • Áp dụng toàn trang
<!-- Schema Organization // Khai báo địa chỉ, SĐT doanh nghiệp -->
<script type='application/ld+json'>
{
  "@context": "http://schema.org",
  "@type": "Organization",
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Hồ Chí Minh, Vietnam",
    "postalCode": "700000",
    "streetAddress": "98 Nguyễn Văn Lượng Gò Vấp"
  },
  "email": "haiphungmarketing@gmail.com",
  "faxNumber": "( 33 1) 42 68 53 01",
  "member": [
    {
      "@type": "Organization"
    },
    {
      "@type": "Organization"
    }
  ],
  "alumni": [
    {
      "@type": "Person",
      "name": "Huỳnh Phụng Blogger"
    },
    {
      "@type": "Person",
      "name": "Phụng Eagle"
    }
  ],
  "name": "Tôi Là Quản Trị",
  "telephone": "(+84) 932 913 631"
}
</script>

Nhóm 3:  Schema Person: Khai báo Tác giả/Admin/Biên tập viên Website (1)

Schema Persion: Áp dụng tại trang chủ

<!-- Schema Person // Khai báo thông tin tác giả -->
<script type='application/ld+json'>
{
"@context": "http://schema.org",
"@type": "Person",
"name": "Huỳnh Phụng Blogger",
"url": "https://www.toilaquantri.com/",
"sameAs": [
"http://www.admin.toilaquantri.com/","https://www.facebook.com/huynhphungblogger","https://www.facebook.com/huynhphung.websfy","https://twitter.com/kehuydietpro","https://plus.google.com/114911979260821967359"]
}
</script>
  • Các link màu đỏ các liên kết đến MXH của tác giả hoặc các trang Profile có liên quan.
  • Tên tác giả nên lấy là tên Đồng bộ với Google+ (Đối với Blogger)

Schema Persion: Áp dụng tại bài viết

<script type='application/ld+json'>
{
  "@context": "http://schema.org",
  "@type": "Person",
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Gò Vấp",
    "addressRegion": "Việt Nam",
    "postalCode": "700000",
    "streetAddress": "98 Nguyễn Văn Lượng"
  },
  "colleague": [
    "http://www.admin.toilaquantri.com/#about-us"
  ],
  "email": "mailto:haiphungmarketing@gmail.com",
  "image": "https://lh4.googleusercontent.com/-R2_TEhEsrvA/AAAAAAAAAAI/AAAAAAAAMF0/88U_zH8nu4g/s512-c/photo.jpg",
  "jobTitle": "Digital Marketer",
"worksFor":"http://dichvuseo.info",
 "name": "Huỳnh Phụng Blogger",
  "telephone": "(+84) 932913631",
  "url": "https://www.toilaquantri.com"
}
</script>

Nhóm 4: Tạo Google Search Box (1)

Google Search Box là khung search xuất hiện ngoài kết quả tìm kiếm Google
Để xuất hiện được thì cần 2 điều kiện
  1. Chèn code Schema Google Sitebox
  2. Người dùng tìm kiếm trên website cực nhiều. Ngay cả VNexpress còn chưa có được Search Box thì bạn hiểu độ khó thế nào rồi. Những website có traffic khoảng 10k/ngày và cố tình tối ưu thì may ra có thể
  • Chỉ chèn tại trang chủ
<script type='application/ld+json'>
{ "@context": "http://schema.org", "@type": "WebSite", "url": "https://www.toilaquantri.com/", "potentialAction": { "@type": "SearchAction", "target": "https://www.toilaquantri.com/?q={search_term}", "query-input": "required name=search_term" } }
</script>
Search box của Cốc cốc cho website Vietnam. Còn Google là thua

Khi áp dụng 3 dạng Schema trên bạn có 7 dữ liệu có cấu trúc. Tiếp theo ta triển khai về cấu trúc dịch vụ. Ở đây ta áp dụng 1 trong cấu trúc dữ liệu tùy vào loại hình Website của bạn.

Nhóm 5: Schema Service: Dịch vụ / Schema Product: Sản Phẩm / Schema Events Sự kiện / Nhà hàng, khách sạn / Schema công thức món ăn / NewsArticle (Web tin tức, tạp chí) (6)

Phần này tùy vào từng loại Website hoặc từng mục đích của từng trang trong website mà sử dụng Schema khác nhau. Không áp dụng chung cho nhiều loại schema ở nhóm 5 cho 1 trang được.
  • Phần này triển khai hơi phức tạp mình sẽ hỗ trợ qua Email.
  • Bạn cần gởi thông tin trang Website của bạn về email Haiphungmarketing@gmail.com để mình hỗ trợ.

Mình đang áp dụng 4 loại dữ liệu là NewsArticle, Product, Events, Service cùng lúc ở 1 trang. Vốn 4 dữ liệu này không nên dùng chung 1 trang và mình đang theo dõi kết quả từ khóa mình có bị Google đánh rớt top không vì mình đang thử nghiệm.

Nhóm 6: Schema Breadcumbs, Headline, Hatom, Updated time..

Nhóm này giúp Google nhận nhiên được cấu trúc đường dẫn (Breadcumbs, tiêu đề bài viết (headline), nội dung bài viết, mô tả, thời gian đăng bài (time public, updated), tác giả bài viết (author)...vv

Schema Website lấy thông tin như tiêu đề Web, mô tả (meta Description) thì các dạng trên thuộc Schema blog lấy tiêu đề bài viết, thông tin liên quan tác giả, ngày đăng.. Xem hướng dẫn fix tại đây

Phần quan trong nhất là Schema ở nhóm 5 và nhóm 6. Hãy liên lạc với mình để mình hỗ trợ cho bạn triển khai nhé.

P/s:
Nếu Schema nhóm 5 sử dụng dạng ld JSon <script> thì thông tin khai báo chính xác hơn nhưng phải triển khai từng từng trang để tránh thu thập liệu trùng trên tất cả các trang. Do vậy nên mình không liệt kê hết được vào đây nên sẽ hỗ trợ riêng.

Còn triển khai dạng html thì có thể dễ sai, chậm hiển thị mà khai báo cấu trúc website lại thích hợp dùng dạng này.

Một dạng khai báo dữ liệu nữa là Microformats khá hay mà mình sẽ hướng dẫn triển khai sau.

Giả sử Website của bạn có 1000 traffic (lượt truy cập)/ngày. Vậy làm thế nào để gấp đôi traffic lên thành 2000 traffics/ngày từ SEO (Organic...

Tăng 20 lần traffic với bộ từ top 11-30

Giả sử Website của bạn có 1000 traffic (lượt truy cập)/ngày. Vậy làm thế nào để gấp đôi traffic lên thành 2000 traffics/ngày từ SEO (Organic Traffic). Tư duy nhỏ sau đây sẽ giúp bạn thực hiện được điều đó một cách nhanh chóng.
Tăng 350% Website traffic

Đầu tiên chúng ta tìm hiểu về khái niệm Microformats Nếu tách riêng ra Micro + Formats (Những định dạng siêu nhỏ). Ở đây theo ngữ cảnh mình ...

13 dữ liệu Microformats,14 Schema makup để xác định Entity Building - SEO Audit #4

Đầu tiên chúng ta tìm hiểu về khái niệm Microformats
Nếu tách riêng ra Micro + Formats (Những định dạng siêu nhỏ). Ở đây theo ngữ cảnh mình sẽ giải thích như sau:
Đây chính là những định dạng để giúp Google nhận dạng nhanh chóng dữ liệu trước kho thông tin khổng lồ trên Internet. Từ những đánh dấu siêu văn bản của nó để bỏ vào kho dữ liệu siêu khổng lồ của các trung tâm dữ liệu. Ở đây ta mặc định nói đến Google nhé!
entity Building seo google
entity Building seo google System

Ví dụ bạn khai báo địa chỉ văn phòng với Google như sau:

Địa chỉ: 98 Nguyễn Văn Lượng Phường 17 Gò Vấp, TPHCM.
Google sẽ không nhận dạng được Nguyễn Văn Lượng là tên người, tên quán ăn, tên quán nhậu hay là gì? Mà thật ra đó địa chỉ của cty bạn nằm trên đó.

Vậy là thế nào Google biết đây là tên đường??.

Sẽ có cấu trúc khai báo như sau Google sẽ cung cấp cho ta các cấu trúc dữ liệu để ta khai báo chi tiết gọi là Microfomats.

Các thể class thường từ rút gọn của các từ tiếng anh có nghĩa khi bạn hiểu một xíu về tiếng anh là có thể khai báo được ngay. Và thường bắt đầu bằng chữ p-

Ví dụ:
Văn Phòng: <span class="h-adr">
<span class="p-street-address">98 Nguyễn Văn Lượng</span>,
<span class="p-locality">Gò Vấp, HCM</span>,
<span class="p-country-name">Vietnam</span>-
<span class="p-postal-code">700000</span>
</span>
<p class="h-geo geo">
<span class="p-latitude latitude">10.83</span>,
<span class="p-longitude longitude">106.67</span>
</p>

Vậy Google đã xác định bằng cách dùng thẻ class Microformats bao bọc bởi thẻ p-street-address. Đơn giản như cbo.

Cấu trúc trên là khai báo địa chỉ dữ liệu là h-adr

Có tất cả 3 cấu trúc dữ liệu mà mình đã tìm hiểu được:

1. Microdata tương tự như Microformats
2. RDFa (cũng theo Schema)
3. JS-SON LD (Schema.org mà bạn biết đến)
  • Và Microdata tương tự như Microformats khai báo dựa theo HTML là các thẻ class bao bọc văn bản.
  • RDFa cũng khai báo theo HTML kiểu dữ liều từ Schema
  • Tuy nhiên JS-SON LD lại khai báo theo Javascript.

Có tất cả 13 dữ liệu Microformats được cung cấp như sau:

  1. h-adr (Khai báo địa chỉ công ty, doanh nghiệp)
  2. h-card (Khai báo người)
  3. h-entry (Khai báo, tiêu đề, nội dung, ngày tháng đăng, tác giả)
  4. h-event (Khái báo sự kiện)
  5. h-feed (Khái báo tên trang)
  6. h-geo (Khai báo địa lí)
  7. h-item (Khái báo về đối tượng nào đó bất kì)
  8. h-listing (Khai báo danh mục)
  9. h-product (Khai báo sản phẩm)
  10. h-recipe (Khai báo công thức như món ăn chẳng hạn)
  11. h-resume (Khai báo lí lịch, sơ lượt về một đối tượng)
  12. h-review (Khai báo đánh giá)
  13. h-review-aggregate (Khai báo đánh giá)
Cả 3 dạng dữ liệu có cấu trúc này sẽ giúp Google nhận diện văn bản chuyển đổi thông tin nhanh chóng hơn, chính xác hơn nhờ đó giúp Google hiểu website của bạn hơn làm tăng độ Trust tổng thể Website.

Phân biệt các dữ liệu Microfomatsr, RDFa, JS-SON LD

  • Microformats: Xác định thông qua các thẻ class.
  • RDFa: Xác định thông qua vocab (từ vựng) và property (thuộc tính) định nghĩa sẳn.
  • ld+json: Thông qua Javascript các mã script này sẽ không nhìn được bằng văn bản mà  chỉ nhầm khai báo cho Google.
Trong đó Microformat là dễ triển khai nhất.

Lấy Microformats của 13 loại trên tại: (Click trực tiếp vào)

  1. h-adr
  2. h-card
  3. h-entry
  4. h-event
  5. h-feed
  6. h-geo
  7. h-item
  8. h-listing
  9. h-product
  10. h-recipe
  11. h-resume
  12. h-review
  13. h-review-aggregate
Kết quả khi kiểm tra bằng SEOquake mà mình đã triển khai được cho website toilaquantri.com

Dữ liệu của Microfomats và Schema.org
Dữ liệu của Microfomats và Schema.org


Trước đó mình cũng công bố 20 loại dữ liệu Schema đã triển khai thành công gồm:
Loại dữ liệu
Nguồn
Trang
Mục
Các mục bị lỗi





1. hatom (Tiêu đề, thời gian..)
Đánh dấu: microformats.org
484
484
2. Breadcrumb
Đánh dấu: rdf.data-vocabulary.org
400
1.127
3. WebSite (Website)
Đánh dấu: schema.org
487
574
4. WPHeader (Header website)
Đánh dấu: schema.org
487
509
5. WPFooter (Footer)
Đánh dấu: schema.org
487
487
6. SiteNavigationElement (Menu)
Đánh dấu: schema.org
487
487
6. Blog (Bloger)
Đánh dấu: schema.org
487
487
7. WPSideBar (Cột Sidebar)
Đánh dấu: schema.org
482
482
8. Person (Tác giả)
Đánh dấu: schema.org
401
401
9. BreadcrumbList
Đánh dấu: schema.org
394
394
10. NewsArticle (Tin tức)
Đánh dấu: schema.org
388
388
11. Organization (Tổ chức)
Đánh dấu: schema.org
320
320
12. ProfessionalService (Dịch vụ)
Đánh dấu: schema.org
27
27
13. Event (Sự kiện)
Đánh dấu: schema.org
2
6
14. Product (Sản phẩm )
Đánh dấu: schema.org
2
2

Traffic của website tổng thể tăng gấp 2-3 lần. Thứ hạng trung bình có thể đã tăng thêm 10-20 bậc sau khi ta tối ưu, quả là kết quả không hề nhỏ!.


Kết quả của tháng 2/2018 tăng gấp đôi so với tháng trước đó.
Traffic tăng từ 2-3 lần sau khi triển khai