Ngôn ngữ

Bộ nhớ đệm cho SEO

Cách bộ nhớ đệm của trình duyệt và máy chủ với Cache-Control, ETag và CDN cải thiện hiệu suất, Core Web Vitals, cùng những cạm bẫy ảnh hưởng tới hoạt động crawl.

Xuất bản lần đầu: 2 thg 7, 2026 · Cập nhật lần cuối: 9 thg 8, 2026 · Advanced
Ngôn ngữ
AIĐược viết bởiAI v2

Bộ nhớ đệm lưu bản sao của trang hoặc tài nguyên trong trình duyệt, tại edge CDN hoặc trong cache riêng của crawler để không phải tạo hay tải lại. Nó không phải yếu tố xếp hạng trực tiếp, nhưng hỗ trợ tốc độ trang / Core Web Vitals qua TTFB và LCP, đồng thời tăng hiệu quả crawl. Crawler của Google chỉ tuân theo ETag và Last-Modified, ưu tiên ETag và xem max-age như gợi ý crawl lại; các directive bộ nhớ đệm HTTP khác không được hỗ trợ. Rủi ro lớn nhất không phải thời lượng cache chậm mà là cấu hình sai CDN và cache cũ chặn bot hoặc khiến bot nhận nội dung sai.

Tóm tắt — Bộ nhớ đệm hoạt động ở ba lớp quan trọng với SEO: trình duyệt, CDN edge và bộ nhớ đệm yêu cầu có điều kiện của crawler. Nó không phải yếu tố xếp hạng, nhưng thúc đẩy tốc độ trang (TTFB/LCP và — thông qua bfcache — Core Web Vitals của lượt điều hướng lặp lại) cũng như hiệu quả thu thập dữ liệu. Crawler của Google ưu tiên ETag hơn Last-Modified, chỉ đọc max-age như gợi ý về thời điểm crawl lại và — theo tài liệu của chính Google — “other HTTP caching directives aren’t supported.” (bản dịch) “các directive bộ nhớ đệm HTTP khác không được hỗ trợ.” CDN có thể được Google cho crawl ở tốc độ cao hơn sau khi bộ nhớ đệm đã ấm; rủi ro thực sự là lúc ra mắt với bộ nhớ đệm lạnh và cấu hình sai CDN/WAF chặn hoàn toàn bot.

Evidence for this claim Google's crawler documentation supports ETag/If-None-Match and Last-Modified/If-Modified-Since, prefers ETag when both are present, and says other HTTP caching directives are unsupported; Google's separate max-age advice is a recrawl-timing hint, not proof it follows browser cache semantics. Scope: Google crawling Confidence: high · Verified: Crawling December: HTTP caching Evidence for this claim HTTP caching uses Cache-Control and validators to control reuse and revalidation. Scope: Current official or standards documentation. Confidence: high · Verified: MDN: HTTP caching Evidence for this claim Browser caches can reuse stored responses according to HTTP caching semantics. Scope: Current official or standards documentation. Confidence: high · Verified: MDN: HTTP caching

Ba lớp bộ nhớ đệm

Bộ nhớ đệm cho SEO không phải một cơ chế duy nhất mà gồm ba lớp, mỗi lớp được kiểm soát hơi khác nhau:

  1. Bộ nhớ đệm của trình duyệt — thiết bị của khách truy cập lưu tệp để các lượt xem lặp lại không cần truy cập mạng. Đây là vấn đề PageSpeed Insights nhắc đến qua cảnh báo “Serve static assets with an efficient cache policy” (bản dịch) “Phục vụ tài nguyên tĩnh bằng chính sách bộ nhớ đệm hiệu quả”.
  2. Bộ nhớ đệm CDN / edge — mạng phân phối nội dung lưu bản sao tại các node edge trên toàn thế giới; xem bài phân tích chuyên sâu về CDN và SEO để hiểu đầy đủ. Theo mô tả của Google, CDN là lớp trung gian giữa origin và người dùng, và trong lịch sử “biggest focus is caching” (bản dịch) “trọng tâm lớn nhất là lưu đệm”: lưu nội dung của URL để máy chủ của bạn không phải phục vụ lại tệp đó trong một khoảng thời gian.
  3. Bộ nhớ đệm phía crawler — Googlebot và Bingbot lưu hồ sơ riêng về việc nội dung có thay đổi hay không bằng các yêu cầu có điều kiện. Đây là đòn bẩy về crawl budget; cơ chế chi tiết thuộc bài về yêu cầu có điều kiện, còn ở đây tôi chỉ tóm tắt.

Cụm từ “bộ nhớ đệm của trình duyệt” ở trên là cách gọi tắt cho nhiều cơ chế. Theo hướng dẫn về bộ nhớ đệm HTTP của MDN, bạn nên phân biệt: bộ nhớ đệm HTTP riêng tư (theo từng trình duyệt, dùng request làm khóa và trên trình duyệt hiện đại còn được phân vùng theo website cấp cao nhất để hạn chế theo dõi chéo website), bộ nhớ đệm trong RAM của phiên hiện tại, bfcache được trình bày bên dưới và — tách biệt — Cache Storage của service worker, do JavaScript của website kiểm soát và không chịu sự điều khiển trực tiếp của header Cache-Control. “Kiểm tra bộ nhớ đệm trình duyệt” có thể là bốn quy trình gỡ lỗi khác nhau tùy cơ chế nào đang gặp sự cố.

Vì sao bộ nhớ đệm hỗ trợ Core Web Vitals

Tải tài nguyên qua mạng vừa chậm vừa tốn kém. Bộ nhớ đệm loại bỏ độ trễ mạng và chi phí truyền dữ liệu đối với mọi thứ chưa thay đổi. Điều đó tác động trực tiếp đến hai chỉ số liên quan tới Core Web Vitals: TTFB (response được lưu đệm bỏ qua việc tạo lại tại origin) và LCP (hình ảnh/CSS/phông chữ được lưu đệm render sớm hơn).

Những directive Cache-Control quan trọng

Cache-Control là header chính. Đây là những directive đáng biết:

  • max-age=<seconds> — khoảng thời gian một bản sao còn mới. Với tài nguyên bất biến có phiên bản, tài liệu Lighthouse của Chrome khuyến nghị lưu đệm một năm hoặc lâu hơn, chẳng hạn Cache-Control: max-age=31536000.
  • no-cache — không có nghĩa là “không lưu đệm”. Nó có nghĩa “hãy lưu, nhưng phải xác thực lại với máy chủ trước khi tái sử dụng”. Cơ chế này vẫn cho phép luồng 304 nhẹ.
  • no-store — directive thực sự yêu cầu không lưu bất kỳ bản sao nào ở đâu trong bộ nhớ đệm HTTP. Đây là directive về bộ nhớ đệm, không phải công tắc quyền riêng tư tổng quát: theo RFC 9111, nó không phải cách đáng tin cậy để xóa lịch sử trình duyệt và không quy định gì về Cache Storage riêng của service worker.
  • public / private — quy định bộ nhớ đệm dùng chung như CDN có được lưu response hay chỉ trình duyệt của người dùng cuối được lưu.
  • immutable — bỏ qua hoàn toàn việc xác thực lại khi response vẫn còn mới. Nó không có nghĩa “không bao giờ cũ”; khi max-age hết hạn, các quy tắc về độ mới thông thường lại được áp dụng.
  • must-revalidate — tác động ở đầu kia của dòng thời gian: chỉ có hiệu lực sau khi response trở nên cũ và yêu cầu cache phải xác thực lại với origin thay vì vẫn phục vụ bản sao cũ.
  • s-maxage, stale-while-revalidate, stale-if-error — các cơ chế kiểm soát chi tiết chủ yếu dành cho CDN và bộ nhớ đệm dùng chung khác (lifetime riêng cho cache dùng chung, tái sử dụng bản cũ trong giới hạn khi request nền đang chạy và tái sử dụng bản cũ trong giới hạn khi origin lỗi). Mức hỗ trợ khác nhau theo trình duyệt/CDN, vì vậy hãy kiểm tra khả năng hỗ trợ hiện tại trước khi phụ thuộc vào chúng; như sẽ trình bày bên dưới, crawler của Google không tuân theo tập directive bổ sung này.

Phá bộ nhớ đệm bằng tên tệp có phiên bản

Mẹo giúp bạn vừa lưu đệm mạnh tay vừa cập nhật tức thì là đưa hàm băm nội dung vào tên tệp, chẳng hạn style.x234dff.css. URL là khóa bộ nhớ đệm, nên đổi tệp sẽ đổi URL và khiến cache tải phiên bản mới ngay, trong khi các phiên bản cũ vẫn có thể được lưu bao lâu tùy ý. Cả hướng dẫn bộ nhớ đệm HTTP của web.dev và bài viết kỹ thuật front-end của Bing đều mô tả cùng mẫu này: Bing băm nội dung tệp vào URL để “the URL acts as the cache key,” (bản dịch) “URL đóng vai trò khóa bộ nhớ đệm”, nhờ đó cache nhất quán và có thể dùng thời hạn dài.

Cạm bẫy bfcache — khi no-store âm thầm làm hại CWV

Đây là một vấn đề ít được đề cập. Bộ nhớ đệm back/forward (bfcache) giúp thao tác “quay lại” khôi phục trang tức thì. Một lần khôi phục từ bfcache bỏ qua hoàn toàn phép đo LCP/CLS/INP, nên chỉ có lợi cho dữ liệu thực địa CrUX. Tuy nhiên, theo hướng dẫn bfcache của Google, việc đặt Cache-Control: no-store trên chính document của trang từng khiến trình duyệt từ chối lưu trang đó vào bfcache. Nếu cần HTML luôn mới nhưng không muốn mất điều kiện dùng bộ nhớ đệm back/forward, hãy dùng no-cache hoặc max-age=0 thay cho no-store.

Cache quyết định “đủ mới” như thế nào

Trước khi dùng bất kỳ validator nào, cache kiểm tra độ mới: tuổi của response được lưu đã vượt lifetime mà Cache-Control quy định chưa (hoặc nếu không có lifetime rõ ràng, đã vượt thời gian heuristic mà cache được phép ước tính chưa)? Header response Age cho biết cache dùng chung đã giữ response bao lâu; nhờ đó bạn có thể xem trong DevTools hoặc log CDN còn lại bao nhiêu lifetime. Response còn mới có thể được tái sử dụng ngay mà không cần request. Response cũ phải được xác thực trước khi tái sử dụng; đây chính là lúc ETag/If-None-Match và Last-Modified/If-Modified-Since phát huy tác dụng. Phần tiếp theo trình bày phiên bản hẹp hơn của cơ chế HTTP tổng quát này dành cho Googlebot.

Cách Googlebot sử dụng bộ nhớ đệm để crawl hiệu quả

Trong bài Crawl tháng 12: bộ nhớ đệm HTTP tháng 12/2024, Google đưa ra yêu cầu thẳng thắn hiếm thấy: hãy bật bộ nhớ đệm để crawler có thể bỏ qua việc tải lại các trang không đổi. Điểm dữ liệu đáng chú ý là số lượt fetch có thể lưu đệm đã giảm: khoảng 0,026% tổng số lượt fetch có thể lưu đệm cách đây 10 năm, còn hiện nay con số đó là 0,017%. Các tỷ lệ đều nhỏ, nhưng rõ ràng Google muốn chúng tăng chứ không giảm.

ETag và Last-Modified — Google ưu tiên loại nào

Hạ tầng crawl của Google hỗ trợ hai validator tiêu chuẩn: ETag (với If-None-Match) và Last-Modified (với If-Modified-Since). Google “strongly recommends ETag” (bản dịch) “đặc biệt khuyến nghị dùng ETag” vì giá trị này không có cấu trúc nên ít gặp lỗi phân tích hơn chuỗi ngày tháng; nếu có cả hai, crawler “use the ETag value” (bản dịch) “dùng giá trị ETag” đúng theo tiêu chuẩn HTTP. Google vẫn đề nghị đặt cả hai vì “other applications such as CMSes” (bản dịch) “các ứng dụng khác như CMS” sử dụng chúng. Nếu dùng Last-Modified, ngày phải tuân theo định dạng HTTP, chẳng hạn Fri, 4 Sep 1998 19:15:56 GMT, nếu không sẽ không được phân tích.

Khi validator mà crawler lưu vẫn khớp, máy chủ trả về 304 Not Modified không có body — đó chính là mục đích. Theo Google, không có body nghĩa là máy chủ không phải tốn tài nguyên tính toán để “generating content” (bản dịch) “tạo nội dung” và không tốn băng thông truyền nội dung. Cơ chế 304 này là phần liên quan tới crawl budget được giải thích kỹ trong bài về yêu cầu có điều kiện; ở đây chỉ cần biết nó tồn tại và tiết kiệm chi phí cho cả hai phía.

Sắc thái mà hầu hết mọi người bỏ lỡ

Crawler của Google không thực thi toàn bộ tập directive Cache-Control như trình duyệt hoặc CDN. Theo tài liệu tổng quan chính thức về crawler, ngoài ETag/Last-Modified, “other HTTP caching directives aren’t supported.” (bản dịch) “các directive bộ nhớ đệm HTTP khác không được hỗ trợ”. Có một ngoại lệ một phần: Google nói bạn có thể tùy chọn đặt max-age để “help crawlers determine when to recrawl” (bản dịch) “giúp crawler xác định thời điểm crawl lại” một URL — đây là gợi ý, không phải khóa cứng. Vì vậy no-cache, s-maxage, stale-while-revalidate và các directive tương tự vẫn định hình hành vi trình duyệt/CDN nhưng không thay đổi cách Googlebot lưu đệm. Lời khuyên của Google về thời điểm vô hiệu hóa cache cũng hợp lý: yêu cầu làm mới cache “on significant changes” (bản dịch) “khi có thay đổi đáng kể”; chỉ cập nhật năm bản quyền ở footer thì không đáng kể.

CDN và hoạt động thu thập dữ liệu

CDN mang lại nhiều hơn tốc độ. Hạ tầng crawl của Google được thiết kế để cho phép “higher crawl rates on sites backed by a CDN” (bản dịch) “crawl rate cao hơn trên các website được CDN hỗ trợ”, suy ra từ địa chỉ IP phục vụ URL; Google giả định origin có CDN hỗ trợ có thể xử lý nhiều request đồng thời hơn.

Nhưng có một điểm cần tính trước: bộ nhớ đệm lạnh. Trong lần truy cập đầu tiên vào một URL, “the CDN’s cache is ‘cold’” (bản dịch) “bộ nhớ đệm của CDN đang ‘lạnh’” — chưa ai request URL đó, nên origin vẫn phải phục vụ ít nhất một lần để làm ấm cache. Vì vậy, Google cảnh báo việc ra mắt nhiều URL cùng lúc tạo gánh nặng thực sự lên crawl budget, với crawl rate cao trong vài ngày. Nếu triển khai quy mô lớn hoặc migration website, hãy dự trù origin phải chịu toàn bộ tải cho từng URL trước khi CDN bắt đầu hỗ trợ.

Cấu hình sai CDN là một rủi ro cho hoạt động crawl

Các vấn đề đáng sợ nhất liên quan tới bộ nhớ đệm không phải thời lượng cache chậm mà là cấu hình CDN và WAF chặn bot. Bài viết của Google về CDN nói rõ rằng với trường hợp chặn tạm thời, “HTTP 503/429 status codes” (bản dịch) “mã trạng thái HTTP 503/429” là cách ưu tiên để báo hiệu, trong khi timeout mạng được coi là lỗi “cứng”, có tính kết thúc và có thể khiến URL bị xóa khỏi index. Trường hợp tinh vi là soft block: một interstitial xác minh bot. Crawler chỉ nhìn thấy trang thử thách chứ không thấy website của bạn, vì vậy Google “strongly recommends returning a 503” (bản dịch) “đặc biệt khuyến nghị trả về 503” cho client tự động. “The easiest way to check” (bản dịch) “Cách dễ nhất để kiểm tra” CDN có âm thầm chặn Google hay không là công cụ URL Inspection trong Search Console: xem hình ảnh đã render; nếu xuất hiện thử thách bot hoặc trang trống, hãy làm việc với nhà cung cấp CDN.

Chuyển việc xử lý redirect sang CDN là kỹ thuật tôi ưa thích. Trên podcast Marketing Speak, tôi mô tả như sau: “One of my personal favorites that I don’t think it’s used enough, it’s actually just off loading your redirects to the CDN level.” (bản dịch) “Một trong những cách tôi thích nhất nhưng nghĩ rằng chưa được dùng đủ là chuyển hẳn việc xử lý redirect lên cấp CDN.” (Đi tới câu trích dẫn)

Những cạm bẫy bộ nhớ đệm làm hại việc crawl và index

Đây là góc nhìn mà hầu hết bài “bộ nhớ đệm cho SEO” bỏ qua. Cache không chỉ giúp mọi thứ nhanh hơn; một cache sai có thể phục vụ sai byte cho bot và làm hỏng quá trình crawl hoặc index.

Một trường hợp có thật: cache dùng chung phục vụ tệp robots.txt chặn bot. Tôi đã điều tra một vụ Googlebot bị chặn không liên tục và truy nguyên được nguyên nhân là cache CDN dùng chung giữa môi trường kiểm thử và website live. Như tôi viết trong bài Indexed, though blocked by robots.txt: “One possible cause would be a shared cache between a test environment and a live environment. When the cache from the test environment is active, the robots.txt file may include a blocking directive.” (bản dịch) “Một nguyên nhân có thể là cache dùng chung giữa môi trường kiểm thử và môi trường live. Khi cache từ môi trường kiểm thử hoạt động, tệp robots.txt có thể chứa directive chặn.” Cách khắc phục là tách cache hoặc loại trừ tệp .txt khỏi cache ở môi trường kiểm thử. Một cấu hình bộ nhớ đệm sai đã trực tiếp gây lỗi crawl; đây mới là loại rủi ro thực sự gây thiệt hại.

Các cạm bẫy khác cùng nhóm gồm:

  • Cache CDN cũ phục vụ nội dung lỗi thời cho bot. Nếu edge cache giữ phiên bản cũ quá lâu sau khi bạn xuất bản thay đổi, bot sẽ tiếp tục thấy phiên bản đó. Hãy purge khi xuất bản hoặc gắn lifetime của cache với tần suất thay đổi thực tế của trang.
  • Phân mảnh cache do Vary / User-Agent. Khóa của cache dùng chung thường chỉ là URL; Vary thêm các header request như User-Agent hoặc Accept-Language vào khóa để lưu riêng từng biến thể. Nếu bỏ sót một header thực sự làm thay đổi response, requester này có thể nhận biến thể của requester khác — gây nhầm lẫn mobile/desktop hoặc bot/người. Nếu thêm quá nhiều header vào Vary, cache bị chia thành quá nhiều khóa gần giống nhau và hầu như không cải thiện hit rate. Ngoài ra, trình duyệt hiện đại còn phân vùng cache riêng theo website cấp cao nhất để bảo vệ quyền riêng tư; vì vậy tài nguyên được lưu khi nhúng trên website này thường không được tái sử dụng khi nhúng trên website khác. Đây là cơ chế khác với Vary; đừng nhầm lẫn khi gỡ lỗi báo cáo “tại sao nội dung này không được lưu đệm”.

Nguyên tắc chung của tôi về thời lượng bắt nguồn từ các thử nghiệm chỉ số hiển thị nội dung lớn nhất. Trong hướng dẫn của Ahrefs về chỉ số này, tôi diễn đạt nguyên tắc như sau: “Your cache time should be as long as you are comfortable with” (bản dịch) “Thời gian lưu đệm nên dài đến mức bạn cảm thấy phù hợp”. Xem nguồn Tôi cũng mô tả cấu hình lý tưởng: “An ideal setup is to cache for a really long period of time but purge the cache when you make a change to a page.” (bản dịch) “Cấu hình lý tưởng là lưu đệm trong thời gian rất dài nhưng xóa cache khi bạn thay đổi trang.” Lưu dài hạn, xóa tức thì: sự kết hợp đó vừa giữ tốc độ vừa bảo đảm nội dung mới.

Bộ nhớ đệm có phải yếu tố xếp hạng không?

Không — ít nhất không trực tiếp. Không có tín hiệu xếp hạng nào cho việc đặt ETag hoặc có chính sách Cache-Control tốt. Điều bộ nhớ đệm thực sự làm là hỗ trợ hai yếu tố liên quan đến khả năng hiển thị: tốc độ trang / Core Web Vitals (một đầu vào rõ ràng của trải nghiệm trang) và hiệu quả crawl (quyết định tốc độ phát hiện và làm mới nội dung mới hoặc vừa cập nhật, qua đó gián tiếp tác động tới kết quả nhạy cảm với độ mới). Hãy cấu hình bộ nhớ đệm vì nó giúp website nhanh và dễ crawl, không phải vì mong đợi thứ hạng tăng trực tiếp.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.