Bounce rate tăng 32% chỉ vì trang web chậm hơn 2 giây.

Đó không phải là con số mình tự bịa — đó là dữ liệu từ nghiên cứu của Google với hàng triệu phiên duyệt web trên thiết bị di động. Và đây chính là lý do tại sao, từ năm 2021, Google chính thức đưa Core Web Vitals vào bộ tín hiệu xếp hạng của mình.

Bạn có thể đang tự hỏi: “Mình đã làm SEO bao lâu nay, tại sao lại cần thêm 3 chỉ số nữa?”

Câu trả lời ngắn gọn: vì đây là lần đầu tiên Google đo lường trải nghiệm người dùng thực sự thay vì chỉ đọc code. Và sự khác biệt đó thay đổi hoàn toàn cách bạn nghĩ về tối ưu website.

Trong bài viết này, bạn sẽ hiểu Core Web Vitals là gì, từng chỉ số đo lường điều gì, cách cải thiện chúng — và quan trọng hơn, một vài góc nhìn phân tích mà hầu hết các tài liệu tiếng Việt chưa đề cập đến.

Mục lục

  1. Core Web Vitals là gì? — Không phải định nghĩa sách giáo khoa
  2. 3 Chỉ số Core Web Vitals: LCP, CLS, INP
  3. Ngưỡng đạt chuẩn và cách Google đánh giá
  4. Cách đo lường Core Web Vitals
  5. Cách cải thiện từng chỉ số
  6. Góc nhìn phân tích: Điều Google không nói thẳng
  7. Core Web Vitals ảnh hưởng đến SEO như thế nào?
  8. Sai lầm phổ biến khi tối ưu Core Web Vitals
  9. Câu hỏi thường gặp
  10. Kết luận

Core Web Vitals là gì?

Định nghĩa thực sự — không phải lý thuyết

Core Web Vitals (viết tắt: CWV) là bộ 3 chỉ số kỹ thuật do Google định nghĩa để đo lường chất lượng trải nghiệm người dùng trên một trang web, tập trung vào ba khía cạnh: tốc độ tải, độ ổn định hình ảnh, và khả năng phản hồi tương tác.

Nói đơn giản hơn: Google không còn chỉ nhìn vào nội dung bạn viết hay liên kết bạn có — họ bắt đầu đặt mình vào vị trí người dùng và hỏi: “Trang này có thoải mái để dùng không?”

Core Web Vitals là một phần trong sáng kiến lớn hơn gọi là Web Vitals — bộ tiêu chuẩn chất lượng mà Google xây dựng để giúp developer tạo ra trải nghiệm web tốt hơn. Trong số tất cả các Web Vitals, Core Web Vitals là nhóm được Google chọn để tích hợp vào thuật toán xếp hạng.

Tại sao Core Web Vitals ra đời?

Trước năm 2020, các chỉ số về tốc độ website đã tồn tại, nhưng chúng rất rời rạc — PageSpeed Score là một số, Time to First Byte là số khác, First Contentful Paint lại là số khác nữa. Không có bộ tiêu chuẩn thống nhất nào để developer và SEO có thể cùng nhìn vào một bức tranh chung.

Google đưa ra Core Web Vitals để giải quyết vấn đề đó: một bộ chỉ số chuẩn hóa, đo lường được, và có ngưỡng rõ ràng.

Quan trọng hơn, Google đã thừa nhận rằng các tín hiệu cũ — như Page Speed — dễ bị “đánh giá sai” vì chúng đo trên máy chủ của Google (lab data), không phải từ trải nghiệm thực tế của người dùng. Core Web Vitals ưu tiên field data — dữ liệu thực từ hàng triệu người dùng Chrome thực sự ghé thăm trang của bạn.

Ai nên quan tâm đến Core Web Vitals?

Nếu bạn thuộc một trong các nhóm sau, đây là chủ đề bắt buộc phải hiểu:

  • Web developer và kỹ sư front-end — người trực tiếp tác động đến các chỉ số này
  • SEO specialist và content strategist — người cần hiểu page experience ảnh hưởng đến ranking như thế nào
  • Product manager và business owner — người cần biết website của mình “đạt chuẩn” hay chưa
  • Digital marketer chạy paid traffic — vì landing page kém CWV cũng ảnh hưởng đến Quality Score

3 Chỉ số Core Web Vitals: LCP, CLS, INP

Kể từ tháng 3 năm 2024, bộ ba Core Web Vitals bao gồm: LCP, CLS, và INP (INP đã chính thức thay thế FID từ đầu 2024).

LCP — Largest Contentful Paint (Hiển thị nội dung lớn nhất)

LCP đo gì? Thời gian để phần tử nội dung lớn nhất trên màn hình hoàn tất việc tải và hiển thị.

Phần tử “lớn nhất” thường là ảnh hero, banner đầu trang, hoặc một đoạn văn lớn — bất kỳ thứ gì chiếm diện tích màn hình nhiều nhất trong vùng hiển thị ban đầu (viewport) mà người dùng thấy khi trang vừa mở.

Vì sao LCP quan trọng? Hãy nghĩ đến lần cuối bạn mở một trang web và nhìn thấy màn hình trắng 3-4 giây. Dù nội dung trang đó có hay đến đâu, bạn đã bắt đầu phân vân có nên chờ không. LCP là cách Google đo lường điểm cảm giác trang đã sẵn sàng đó.

Ngưỡng chuẩn:

  • Tốt: dưới 2,5 giây
  • Cần cải thiện: 2,5 – 4 giây
  • Kém: trên 4 giây

Nguyên nhân LCP kém phổ biến nhất:

  • Server response time chậm (TTFB cao)
  • Ảnh không được tối ưu (quá nặng, không dùng lazy loading)
  • JavaScript hoặc CSS chặn quá trình render (render-blocking resources)
  • Font chữ web tải chậm

CLS — Cumulative Layout Shift (Độ dịch chuyển bố cục tích lũy)

CLS đo gì? Tổng lượng dịch chuyển bố cục bất ngờ xảy ra trong suốt vòng đời của trang.

Đây là chỉ số duy nhất trong ba CWV không đo thời gian — mà đo điểm số (score) dựa trên mức độ các phần tử di chuyển bất ngờ trên màn hình.

Ví dụ thực tế: Bạn đang đọc một bài báo, ngón tay chuẩn bị nhấp vào một đường link. Đúng lúc đó, một banner quảng cáo tải xong và đẩy toàn bộ nội dung xuống — bạn vô tình nhấp vào cái gì đó khác. Đó là CLS đang xảy ra.

Hoặc kinh điển hơn: giỏ hàng có 56 sản phẩm, bạn đang chuẩn bị xóa một vài món thì trang giật cục — và bạn nhấn vào nút “Đặt hàng” thay vì nút xóa. Đây không phải chuyện cười — nó là lý do tại sao CLS được coi là chỉ số quan trọng với ecommerce.

Ngưỡng chuẩn:

  • Tốt: 0,1 hoặc thấp hơn
  • Cần cải thiện: 0,1 – 0,25
  • Kém: trên 0,25

Nguyên nhân CLS kém phổ biến nhất:

  • Ảnh và video không có thuộc tính width/height cố định
  • Quảng cáo, iframe, hoặc embed không có kích thước placeholder
  • Nội dung được inject động (popup, banner, notification) không có không gian dự phòng
  • Font chữ web gây “text swap” khi tải xong (FOUT/FOIT)

INP — Interaction to Next Paint (Thời gian từ tương tác đến vẽ lại màn hình)

INP đo gì? Độ trễ giữa thời điểm người dùng thực hiện một thao tác (click, tap, gõ phím) và thời điểm trình duyệt vẽ lại màn hình để phản hồi thao tác đó.

INP là chỉ số mới nhất trong bộ ba, chính thức thay thế FID (First Input Delay) từ tháng 3/2024. Sự khác biệt quan trọng: FID chỉ đo lần tương tác đầu tiên của người dùng với trang, trong khi INP đo tất cả các tương tác trong suốt phiên — và lấy giá trị tệ nhất (gần percentile 98) làm điểm cuối cùng.

Vì sao điều này quan trọng? Một trang web có thể phản hồi nhanh lần click đầu tiên nhưng trở nên “lag” sau khi JavaScript đã chạy đủ lâu. INP bắt được điều đó, còn FID thì không.

Ngưỡng chuẩn:

  • Tốt: dưới 200ms
  • Cần cải thiện: 200 – 500ms
  • Kém: trên 500ms

Nguyên nhân INP kém phổ biến nhất:

  • JavaScript nặng chặn main thread của trình duyệt
  • Long tasks (tác vụ kéo dài trên 50ms) xảy ra thường xuyên
  • Third-party scripts (chat widget, analytics, ads) tiêu tốn tài nguyên
  • React/SPA rendering không được tối ưu

Ngưỡng đạt chuẩn và cách Google đánh giá

Google không đánh giá theo kiểu “được điểm 85 là pass” — họ dùng hệ thống ba mức: Good (Tốt), Needs Improvement (Cần cải thiện), Poor (Kém).

Chỉ số Tốt Cần cải thiện Kém
LCP ≤ 2,5 giây 2,5 – 4 giây > 4 giây
CLS ≤ 0,1 0,1 – 0,25 > 0,25
INP ≤ 200ms 200 – 500ms > 500ms

Điều quan trọng cần hiểu: Google đánh giá theo 75th percentile — tức là 75% số lượt tải trang thực tế phải đạt ngưỡng “Tốt” thì URL đó mới được coi là pass. Điều này có nghĩa là bạn không thể chỉ tối ưu cho trường hợp lý tưởng — bạn phải tối ưu cho cả những người dùng có kết nối chậm, thiết bị cũ.

Cách đo lường Core Web Vitals

Hai loại dữ liệu: Lab và Field

Đây là điểm mà nhiều người nhầm lẫn, và sự nhầm lẫn này dẫn đến quyết định tối ưu sai hướng.

Lab data (dữ liệu phòng thí nghiệm): Đo trên máy tính mô phỏng, trong điều kiện cố định. Tools: Lighthouse, PageSpeed Insights (khi chạy thủ công), WebPageTest.

Field data (dữ liệu thực địa): Đo từ người dùng thực thông qua Chrome User Experience Report (CrUX). Tools: Google Search Console, PageSpeed Insights (phần CrUX), Chrome UX Report.

Google chỉ dùng field data cho mục đích xếp hạng. Lab data hữu ích để debug, nhưng không phản ánh trực tiếp điểm số mà Google thấy. Một trang có thể đạt 90 trên Lighthouse nhưng vẫn fail Core Web Vitals nếu người dùng thực tế đang trải nghiệm kém.

Công cụ đo lường chính

Google Search Console — PageSpeed Insights Report Đây là nơi đầu tiên bạn nên kiểm tra. Search Console phân chia URL thành hai nhóm: URL đạt và URL chưa đạt, với dữ liệu field data thực từ Chrome. Đây là nguồn dữ liệu gần nhất với cách Google đánh giá.

PageSpeed Insights (pagespeed.web.dev) Cung cấp cả hai: field data từ CrUX (nếu có đủ dữ liệu) và lab data từ Lighthouse. Hữu ích để xem nhanh và debug từng URL.

Chrome DevTools — Performance Panel Dành cho developer cần đào sâu. Có thể record toàn bộ phiên tải trang, xem từng millisecond, phân tích long tasks và render timeline.

WebPageTest (webpagetest.org) Công cụ nâng cao, cho phép test từ nhiều vị trí địa lý, nhiều loại thiết bị và kết nối mạng. Rất tốt để hiểu tại sao người dùng ở một vùng địa lý nhất định gặp vấn đề.

Cách cải thiện từng chỉ số

Cải thiện LCP

1. Giảm TTFB (Time to First Byte) Server chậm = LCP chậm. Sử dụng CDN để phân phối nội dung gần người dùng hơn, nâng cấp hosting nếu cần, và bật server-side caching.

2. Tối ưu ảnh Ảnh thường là nguyên nhân số một của LCP kém. Checklist cơ bản:

  • Chuyển sang định dạng WebP hoặc AVIF (nhỏ hơn 30-50% so với JPEG/PNG cùng chất lượng)
  • Thêm thuộc tính loading="eager" và fetchpriority="high" cho ảnh LCP
  • Preload ảnh hero với <link rel="preload">
  • Không dùng lazy loading cho ảnh LCP

3. Loại bỏ render-blocking resources Các file CSS và JavaScript tải trong <head> mà không có defer hoặc async sẽ chặn trình duyệt render trang. Audit bằng Lighthouse và loại bỏ hoặc trì hoãn những resource không cần thiết cho lần render đầu tiên.

4. Preconnect đến domain bên thứ ba Nếu LCP element tải từ một domain khác (ví dụ: CDN của ảnh), thêm <link rel="preconnect"> để trình duyệt thiết lập kết nối sớm hơn.

Cải thiện CLS

1. Luôn khai báo kích thước cho ảnh và video Thêm thuộc tính width và height vào tất cả thẻ <img> và <video>. Trình duyệt sẽ dành sẵn không gian trước khi nội dung tải xong, tránh layout shift.

2. Dành không gian cho quảng cáo và embed Nếu trang có quảng cáo động, đặt container có kích thước cố định. Không để trình duyệt quyết định kích thước sau khi ad đã tải.

3. Tránh inject nội dung trên nội dung hiện có Popup, banner, cookie consent — tất cả nên slide từ trên xuống hoặc từ dưới lên thay vì đẩy nội dung sang bên. Hoặc dự phòng không gian từ đầu.

4. Xử lý font chữ web đúng cách Sử dụng font-display: swap kết hợp với size-adjust để giảm thiểu sự thay đổi bố cục khi font tải xong.

Cải thiện INP

INP là chỉ số khó cải thiện nhất trong ba CWV vì nó liên quan trực tiếp đến kiến trúc JavaScript.

1. Phân tích và chia nhỏ Long Tasks Bất kỳ tác vụ JavaScript nào chạy hơn 50ms đều được coi là Long Task và có thể chặn trình duyệt phản hồi tương tác. Dùng Chrome DevTools Performance tab để tìm và chia nhỏ chúng.

2. Defer hoặc loại bỏ third-party scripts không cần thiết Chat widget, pixel tracking, analytics — mỗi script đều tiêu tốn main thread. Kiểm tra từng script và quyết định: cần thiết không? Có thể load sau không?

3. Sử dụng Web Workers cho tác vụ nặng Các tác vụ tính toán nặng nên được chuyển sang Web Worker để chạy trên thread riêng, không can thiệp vào thread chính của trình duyệt.

4. Tối ưu Event Handlers Đảm bảo event handler cho click, tap không thực hiện quá nhiều công việc đồng bộ. Dùng requestAnimationFrame hoặc setTimeout để tách phần nặng ra khỏi handler.

Góc nhìn phân tích: Điều Google không nói thẳng

Đây là phần mà hầu hết các bài viết về Core Web Vitals bỏ qua — vì hầu hết chỉ tổng hợp lại tài liệu chính thức của Google mà không phân tích sâu hơn.

1. Core Web Vitals là “tín hiệu tie-breaker”, không phải ranking factor chủ đạo

Google xác nhận rằng Core Web Vitals là một page experience signal trong hơn 200 tín hiệu xếp hạng. Nhưng vị trí của nó trong hệ thống đó là gì?

Từ nhiều bằng chứng thực nghiệm và thông báo chính thức, CWV hoạt động như một tie-breaker — khi hai trang có chất lượng nội dung và authority tương đương, trang có CWV tốt hơn sẽ được ưu tiên. Không phải là: trang CWV tốt thì sẽ vượt qua trang có nội dung và authority tốt hơn.

Hệ quả thực tế: Đừng đánh đổi chất lượng nội dung để tối ưu CWV. Ưu tiên vẫn là: nội dung đúng, authority có, CWV tốt là nước son thêm vào.

2. Field data không có nghĩa là website của bạn “thực sự nhanh”

CrUX (Chrome User Experience Report) chỉ thu thập dữ liệu từ người dùng đã opt-in vào Chrome data sharing, dùng Chrome trên desktop hoặc Android. Nếu đối tượng của bạn dùng Safari trên iPhone nhiều — một tệp khá phổ biến ở Việt Nam — CrUX hoàn toàn không phản ánh trải nghiệm của họ.

Bài học: Dữ liệu field data của Google là quan trọng với SEO, nhưng để thực sự hiểu trải nghiệm người dùng của bạn, bạn cần thêm RUM (Real User Monitoring) từ các tool như Sentry, Datadog, hoặc even GA4.

3. INP đang bị đánh giá thấp hơn mức cần thiết

Kể từ khi INP thay thế FID (tháng 3/2024), nhiều trang web đột ngột thấy điểm CWV của mình tụt giảm — vì FID rất dễ pass (chỉ cần phản hồi nhanh lần đầu), trong khi INP đòi hỏi responsiveness xuyên suốt toàn bộ phiên.

Quan sát của mình qua các website SPA (Single Page Application) dùng React hoặc Vue: INP thường là điểm yếu nhất, và nó đặc biệt tệ trên thiết bị tầm trung. Trong khi developer thường test trên MacBook Pro mới nhất, người dùng thực tế ở Việt Nam có thể đang dùng điện thoại Android tầm trung với RAM 3-4GB.

Khuyến nghị: Khi test INP, luôn dùng tính năng CPU throttling trong Chrome DevTools để mô phỏng thiết bị yếu hơn.

4. “Đạt chuẩn” và “trải nghiệm tốt” là hai chuyện khác nhau

Một trang có LCP = 2,4 giây technically “pass” — nhưng so với trang của đối thủ có LCP = 1,1 giây, người dùng vẫn cảm nhận được sự khác biệt rõ ràng. Google hiện chưa phân biệt granular hơn bên trong vùng “Good”, nhưng điều đó không có nghĩa là bạn nên dừng lại ở mức pass.

Trong kinh nghiệm phân tích nhiều website, mình nhận thấy: mỗi 100ms cải thiện LCP thường dẫn đến khoảng 0,5-1% tăng conversion rate — dù trang đó đã pass ngưỡng “Good”. Điều đó có nghĩa là CWV không chỉ là game SEO — nó là game business.

5. Core Web Vitals sẽ tiếp tục thay đổi

Google đã thay thế FID bằng INP. Điều đó cho thấy bộ chỉ số này không cố định. Trong tương lai, có thể sẽ có thêm chỉ số mới liên quan đến Smooth Animations (hiệu ứng mượt mà) hoặc các tín hiệu về responsiveness trên thiết bị yếu mà hiện tại chưa được đo chính thức.

Hiểu tại sao mỗi chỉ số tồn tại — không chỉ là giá trị ngưỡng của nó — sẽ giúp bạn thích nghi tốt hơn khi bộ chỉ số thay đổi.

Core Web Vitals ảnh hưởng đến SEO như thế nào?

Tín hiệu Page Experience trong algorithm

Từ tháng 6/2021, Google chính thức tích hợp Core Web Vitals vào hệ thống xếp hạng như một phần của Page Experience Signal — cùng với các tín hiệu khác như HTTPS, mobile-friendly, safe browsing, và không có intrusive interstitials.

Điều này có nghĩa là: dù nội dung và backlink vẫn là yếu tố chính quyết định ranking, một trang có CWV kém sẽ gặp bất lợi so với trang tương đương có CWV tốt.

Trường hợp CWV cực kỳ quan trọng

Dù CWV không phải ranking factor số một, có những tình huống nó trở nên quyết định hơn:

  • Kết quả tìm kiếm cạnh tranh cao: khi nhiều trang có chất lượng nội dung và authority gần như nhau, CWV là yếu tố phân biệt
  • Mobile search: Google dùng mobile-first indexing, và người dùng mobile có ngưỡng chịu đựng với trang chậm thấp hơn nhiều
  • Trang thương mại điện tử: CLS kém ảnh hưởng trực tiếp đến conversion, không chỉ ranking
  • Landing page quảng cáo: Google Ads Quality Score cũng xem xét page experience

CWV không thay thế được nội dung tốt

Một trang với LCP = 0,8 giây, CLS = 0, INP = 100ms — nhưng nội dung mỏng, không có authority — sẽ không outrank một trang có nội dung sâu, nhiều backlink chất lượng, dù trang đó có LCP = 2,4 giây.

Đây là điều quan trọng cần nhớ: CWV là điều kiện cần, không phải điều kiện đủ để rank tốt.

Sai lầm phổ biến khi tối ưu Core Web Vitals

Sai lầm 1: Chỉ dựa vào Lighthouse để đánh giá

Lighthouse chạy trong môi trường kiểm soát, không phản ánh field data. Điểm Lighthouse cao không đảm bảo CWV pass trong Search Console.

Cách đúng: Dùng Search Console là nguồn chính, Lighthouse chỉ để debug.

Sai lầm 2: Chỉ test trên một thiết bị

Developer thường test trên máy mạnh, WiFi nhanh. Người dùng thực tế dùng nhiều loại thiết bị khác nhau.

Cách đúng: Test với CPU throttling 4x và kết nối 3G Fast trong Chrome DevTools.

Sai lầm 3: Tối ưu xong rồi quên

Core Web Vitals là chỉ số động — thay đổi mỗi khi bạn thêm plugin, cập nhật theme, hoặc tích hợp third-party script mới.

Cách đúng: Thiết lập monitoring tự động (Google Search Console Alert hoặc tool như Calibre, SpeedCurve) để nhận cảnh báo khi CWV tụt giảm.

Sai lầm 4: Cố tối ưu CLS bằng cách ẩn nội dung

Một số người giải quyết CLS bằng cách dùng visibility: hidden trong khi chờ nội dung tải. Trình duyệt không tính layout shift cho nội dung ẩn — nhưng người dùng vẫn nhìn thấy khoảng trống, gây trải nghiệm xấu.

Cách đúng: Đặt placeholder với kích thước cố định thay vì ẩn nội dung.

Sai lầm 5: Chỉ tối ưu trang chủ

Google đánh giá từng URL riêng biệt. Trang chủ đạt chuẩn không có nghĩa là toàn bộ website đạt chuẩn.

Cách đúng: Xem báo cáo Core Web Vitals trong Search Console theo nhóm URL, ưu tiên các trang quan trọng nhất (landing page, product page, bài viết nhiều traffic).

Câu hỏi thường gặp

Core Web Vitals có ảnh hưởng trực tiếp đến thứ hạng không?

Có — nhưng ảnh hưởng có mức độ. CWV là một trong nhiều tín hiệu xếp hạng, và nội dung + authority vẫn quan trọng hơn. Tuy nhiên, khi các trang cạnh tranh tương đương nhau, CWV có thể là yếu tố quyết định.

Nếu website chưa có đủ dữ liệu CrUX thì sao?

Google cần đủ dữ liệu người dùng thực trong 28 ngày mới hiển thị CWV trong Search Console. Nếu URL quá mới hoặc traffic quá thấp, bạn sẽ không thấy field data. Lúc này, dùng lab data (Lighthouse) để định hướng tối ưu, nhưng hãy tăng traffic để có field data thực sự.

INP khác FID như thế nào và tại sao quan trọng hơn?

FID chỉ đo tương tác đầu tiên của người dùng với trang. INP đo tất cả các tương tác trong phiên và lấy giá trị xấu nhất (percentile 98). INP phản ánh toàn diện hơn trải nghiệm tương tác thực sự của người dùng — đặc biệt quan trọng với các ứng dụng web và trang có nhiều tương tác.

CLS ảnh hưởng đến mobile nhiều hơn desktop không?

Thường là có. Màn hình nhỏ hơn nghĩa là một layout shift nhỏ trên desktop sẽ trông lớn hơn trên mobile. Ngoài ra, mạng di động chậm hơn khiến nội dung tải trễ hơn, tạo nhiều cơ hội cho layout shift xảy ra.

Công cụ nào tốt nhất để theo dõi Core Web Vitals liên tục?

Cho website nhỏ đến trung bình: Google Search Console là đủ. Cho enterprise hoặc cần alerting và historical trend: SpeedCurve, Calibre, hoặc tích hợp CrUX API vào dashboard nội bộ.

Kết luận

Core Web Vitals — LCP, CLS, và INP — không phải chỉ là ba con số kỹ thuật để bạn “vượt ngưỡng rồi quên đi”. Chúng đại diện cho một cách Google đang dần đánh giá website: không chỉ nhìn vào nội dung, mà nhìn vào trải nghiệm thực sự của người dùng.

Ba điều bạn nên làm ngay sau khi đọc bài này:

  1. Kiểm tra ngay Core Web Vitals của website trong Google Search Console — tab Trải nghiệm → Core Web Vitals
  2. Ưu tiên trang quan trọng nhất (trang nhiều traffic, landing page chính) — tối ưu LCP trước vì đó thường là chỉ số yếu nhất
  3. Thiết lập monitoring để không bị bất ngờ khi CWV tụt giảm sau mỗi lần cập nhật website

Core Web Vitals không phải là đích đến cuối cùng — nhưng nó là tín hiệu rõ ràng nhất cho thấy Google đang chuyển dịch sang một tiêu chuẩn mới: website tốt là website người dùng muốn ở lại, không chỉ website mà Google bot dễ crawl.

Bài viết thuộc track Phân Tích — tập trung vào góc nhìn độc lập và phân tích cá nhân về các chủ đề SEO và kỹ thuật web.