Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang
Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
Tổng quan về trình thu thập dữ liệu và trình tìm nạp của Google (tác nhân người dùng)
Google sử dụng trình thu thập dữ liệu và trình tìm nạp để thực hiện hành động cho các sản phẩm của Google, theo cách tự động hoặc kích hoạt theo yêu cầu của người dùng. Trình thu thập dữ liệu (đôi khi còn gọi là "robot" hoặc "spider") là thuật ngữ chung để chỉ mọi chương trình có chức năng tự động phát hiện và quét các trang web.
Trình tìm nạp đóng vai trò như một chương trình giống như wget, thường thay mặt người dùng thực hiện một yêu cầu. Ứng dụng khách của Google được chia thành ba loại:
Các trình thu thập dữ liệu chung dùng cho các sản phẩm của Google (chẳng hạn như Googlebot). Các trình thu thập dữ liệu này luôn tuân thủ các quy tắc trong tệp robots.txt đối với hoạt động thu thập dữ tin tự động.
Trình thu thập dữ liệu theo trường hợp đặc biệt tương tự như trình thu thập dữ liệu chung, tuy nhiên sẽ được một số sản phẩm cụ thể sử dụng trong trường hợp có thoả thuận về quá trình thu thập dữ liệu giữa trang web được thu thập dữ tin và sản phẩm của Google. Ví dụ: AdsBot bỏ qua tác nhân người dùng chung trong tệp robots.txt (*) khi có sự cho phép của nhà xuất bản quảng cáo.
Trình tìm nạp do người dùng kích hoạt là một trong số các công cụ và chức năng sản phẩm mà người dùng cuối kích hoạt hoạt động tìm nạp. Ví dụ: Google Site Verifier thực hiện hành động theo yêu cầu của người dùng.
Thuộc tính kỹ thuật của các trình thu thập dữ liệu và trình tìm nạp của Google
Chúng tôi đã thiết kế để có thể cho phép hàng nghìn máy chạy các trình thu thập dữ liệu và trình tìm nạp của Google cùng lúc nhằm cải thiện hiệu suất và quy mô tương ứng với sự phát triển của môi trường web. Để tối ưu hoá mức sử dụng băng thông, các ứng dụng khách này được phân phối trên nhiều trung tâm dữ liệu trên toàn thế giới để được ở gần những trang web mà chúng có thể truy cập. Do đó, nhật ký của bạn có thể cho thấy các lượt truy cập từ một vài địa chỉ IP.
Google chủ yếu truy cập từ các địa chỉ IP ở Hoa Kỳ. Trong trường hợp phát hiện thấy một trang web chặn yêu cầu từ Hoa Kỳ, có thể Google sẽ cố gắng thu thập dữ liệu qua địa chỉ IP ở các quốc gia khác.
Các giao thức truyền dữ liệu được hỗ trợ
Các trình thu thập dữ liệu và trình tìm nạp của Google hỗ trợ HTTP/1.1 và HTTP/2. Trình thu thập dữ liệu sẽ sử dụng phiên bản giao thức mang lại hiệu suất thu thập dữ liệu tốt nhất và có thể chuyển đổi giao thức giữa các phiên thu thập dữ liệu tuỳ thuộc vào số liệu thống kê thu thập dữ liệu trước đó. Phiên bản giao thức mặc định mà trình thu thập dữ liệu của Google sử dụng là HTTP/1.1; việc thu thập dữ liệu qua HTTP/2 có thể giúp tiết kiệm tài nguyên điện toán (ví dụ: CPU, RAM) cho trang web của bạn và Googlebot, nhưng trang web sẽ không nhận được lợi ích cụ thể nào về sản phẩm của Google (ví dụ: không tăng thứ hạng trên Google Tìm kiếm).
Để chọn không cho phép thu thập dữ liệu qua HTTP/2, hãy hướng dẫn máy chủ lưu trữ trang web của bạn phản hồi bằng mã trạng thái HTTP 421 khi Google tìm cách thu thập dữ liệu trên trang web của bạn qua HTTP/2. Nếu việc này không khả thi, bạn có thể gửi tin nhắn cho nhóm Thu thập dữ liệu (mặc dù giải pháp này chỉ là tạm thời).
Cơ sở hạ tầng của trình thu thập dữ liệu của Google cũng hỗ trợ hoạt động thu thập dữ liệu thông qua FTP (được định nghĩa trong RFC959 và các nội dung cập nhật của tài liệu này) và FTPS (được định nghĩa trong RFC4217 và các nội dung cập nhật của tài liệu này). Tuy nhiên, hoạt động thu thập dữ liệu thông qua các giao thức này rất hiếm khi xảy ra.
Các định dạng mã hoá nội dung được hỗ trợ
Trình thu thập dữ liệu và trình tìm nạp của Google hỗ trợ các phương thức mã hoá (nén) nội dung sau: gzip, deflate và Brotli (br). Các phương thức mã hoá nội dung mà từng tác nhân người dùng của Google hỗ trợ sẽ được giới thiệu trong tiêu đề Accept-Encoding của từng yêu cầu mà chúng thực hiện. Ví dụ: Accept-Encoding: gzip, deflate, br.
Tốc độ thu thập dữ liệu và mức tải của máy chủ lưu trữ
Mục tiêu của chúng tôi là thu thập dữ liệu nhiều trang nhất có thể trên trang web của bạn trong mỗi lần truy cập mà không làm máy chủ của bạn quá tải. Nếu trang web của bạn không đáp ứng được các yêu cầu thu thập dữ liệu của Google, thì bạn có thể giảm tốc độ thu thập dữ liệu. Xin lưu ý rằng việc gửi mã phản hồi HTTP không phù hợp đến trình thu thập dữ liệu của Google có thể ảnh hưởng đến cách trang web của bạn xuất hiện trong các sản phẩm của Google.
Hoạt động lưu vào bộ nhớ cache HTTP
Cơ sở hạ tầng thu thập dữ liệu của Google hỗ trợ tính năng lưu vào bộ nhớ cache HTTP theo phương thức phỏng đoán được định nghĩa trong tiêu chuẩn lưu vào bộ nhớ cache HTTP, cụ thể là thông qua tiêu đề của yêu cầu phản hồi ETag và If-None-Match, cũng như tiêu đề của yêu cầu phản hồi Last-Modified và If-Modified-Since.
Nếu cả hai trường ETag và Last-Modified của tiêu đề phản hồi đều có trong phản hồi HTTP, thì trình thu thập dữ liệu của Google sẽ sử dụng giá trị ETag theo yêu cầu của tiêu chuẩn HTTP.
Đối với trình thu thập dữ tin của Google, bạn nên sử dụng ETag thay vì tiêu đề Last-Modified để cho biết lựa chọn ưu tiên về hoạt động lưu vào bộ nhớ cache vì ETag không gặp vấn đề về định dạng ngày.
Các lệnh khác để lưu vào bộ nhớ cache HTTP không được hỗ trợ.
Các trình thu thập dữ liệu và trình tìm nạp riêng lẻ của Google có thể sử dụng hoặc không sử dụng tính năng lưu vào bộ nhớ cache, tuỳ thuộc vào nhu cầu của sản phẩm mà các trình thu thập và trình tìm nạp này liên kết. Ví dụ: Googlebot hỗ trợ lưu vào bộ nhớ cache khi thu thập lại dữ liệu trên các URL cho Google Tìm kiếm và Storebot-Google chỉ hỗ trợ lưu vào bộ nhớ cache trong một số điều kiện nhất định.
Để triển khai tính năng lưu vào bộ nhớ cache HTTP cho trang web, hãy liên hệ với nhà cung cấp dịch vụ lưu trữ hoặc hệ thống quản lý nội dung.
ETag và If-None-Match
Cơ sở hạ tầng thu thập dữ liệu của Google hỗ trợ ETag và If-None-Match được định nghĩa trong Tiêu chuẩn lưu vào bộ nhớ cache HTTP.
Tìm hiểu thêm về tiêu đề phản hồi ETag và tiêu đề của yêu cầu tương ứng If-None-Match.
Last-Modified và If-Modified-Since
Cơ sở hạ tầng thu thập dữ liệu của Google hỗ trợ Last-Modified và If-Modified-Since được định nghĩa trong Tiêu chuẩn lưu vào bộ nhớ cache HTTP với các lưu ý sau:
Ngày trong tiêu đề Last-Modified phải được định dạng theo tiêu chuẩn HTTP.
Để tránh các vấn đề về phân tích cú pháp, bạn nên sử dụng định dạng ngày sau: "Ngày trong tuần, DD Mon YYYY HH:MM:SS Múi giờ". Ví dụ:
"Fri, 4 Sep 1998 19:15:56 GMT".
Mặc dù không bắt buộc, nhưng bạn cũng nên cân nhắc việc thiết lập trường max-age của tiêu đề phản hồi Cache-Control nhằm giúp trình thu thập dữ liệu xác định thời điểm thu thập dữ liệu lại đối với một URL cụ thể. Thiết lập giá trị của trường max-age thành số giây dự kiến mà nội dung sẽ không thay đổi. Ví dụ: Cache-Control: max-age=94043.
[[["Dễ hiểu","easyToUnderstand","thumb-up"],["Giúp tôi giải quyết được vấn đề","solvedMyProblem","thumb-up"],["Khác","otherUp","thumb-up"]],[["Thiếu thông tin tôi cần","missingTheInformationINeed","thumb-down"],["Quá phức tạp/quá nhiều bước","tooComplicatedTooManySteps","thumb-down"],["Đã lỗi thời","outOfDate","thumb-down"],["Vấn đề về bản dịch","translationIssue","thumb-down"],["Vấn đề về mẫu/mã","samplesCodeIssue","thumb-down"],["Khác","otherDown","thumb-down"]],["Cập nhật lần gần đây nhất: 2025-08-04 UTC."],[[["\u003cp\u003eGoogle uses crawlers and fetchers, categorized as common, special-case, and user-triggered, to automatically discover and scan websites or make single requests on behalf of users.\u003c/p\u003e\n"],["\u003cp\u003eGoogle's crawlers and fetchers, distributed globally for optimized performance, primarily egress from US IP addresses and support HTTP/1.1, HTTP/2, FTP, and FTPS protocols for content access.\u003c/p\u003e\n"],["\u003cp\u003eGoogle aims for efficient crawling without overloading servers and supports content encodings like gzip, deflate, and Brotli, while also respecting robots.txt rules for automatic crawls.\u003c/p\u003e\n"],["\u003cp\u003eGoogle utilizes HTTP caching mechanisms, primarily ETag and Last-Modified headers, to minimize redundant data transfer and improve crawling efficiency.\u003c/p\u003e\n"],["\u003cp\u003eGoogle's crawlers can be verified through their user-agent, source IP address, and reverse DNS hostname, ensuring authenticity and security.\u003c/p\u003e\n"]]],["Google's crawlers, which automatically discover and scan websites, and fetchers, which make single requests, serve Google products. Clients are categorized as common crawlers, special-case crawlers (with site-specific agreements), and user-triggered fetchers. They operate from global datacenters, use HTTP/1.1 or HTTP/2, and support gzip, deflate, and Brotli compression. Crawl rates can be adjusted to prevent server overload. Caching, via ETag and Last-Modified headers, is supported to optimize crawling efficiency. To identify a google crawler, use HTTP user-agent, source IP address, and the reverse DNS hostname.\n"],null,["# Google Crawler (User Agent) Overview | Google Search Central\n\nOverview of Google crawlers and fetchers (user agents)\n======================================================\n\n\nGoogle uses crawlers and fetchers to perform actions for its products, either automatically or\ntriggered by user request. Crawler (sometimes also called a \"robot\" or \"spider\") is a generic term\nfor any program that is used to\n[automatically discover and scan websites](/search/docs/fundamentals/how-search-works#crawling).\nFetchers act as a program like\n[wget](https://www.gnu.org/software/wget/) that typically make a\nsingle request on behalf of a user. Google's clients fall into three categories:\n\n|------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| [Common crawlers](/search/docs/crawling-indexing/google-common-crawlers) | The common crawlers used for Google's products (such as [Googlebot](/search/docs/crawling-indexing/googlebot)). They always respect robots.txt rules for automatic crawls. |\n| [Special-case crawlers](/search/docs/crawling-indexing/google-special-case-crawlers) | Special-case crawlers are similar to common crawlers, however are used by specific products where there's an agreement between the crawled site and the Google product about the crawl process. For example, `AdsBot` ignores the global robots.txt user agent (`*`) with the ad publisher's permission. |\n| [User-triggered fetchers](/search/docs/crawling-indexing/google-user-triggered-fetchers) | User-triggered fetchers are part of tools and product functions where the end user triggers a fetch. For example, [Google Site Verifier](https://support.google.com/webmasters/answer/9008080) acts on the request of a user. |\n\nTechnical properties of Google's crawlers and fetchers\n------------------------------------------------------\n\n\nGoogle's crawlers and fetchers are designed to be run simultaneously by thousands of machines to\nimprove performance and scale as the web grows. To optimize bandwidth usage, these clients are\ndistributed across many datacenters across the world so they're located near the sites that they\nmight access. Therefore, your logs may show visits from several IP addresses.\nGoogle egresses primarily from IP addresses in the United States. In case Google detects that a\nsite is blocking requests from the United States, it may attempt to crawl from IP addresses\nlocated in other countries.\n\n### Supported transfer protocols\n\n\nGoogle's crawlers and fetchers support HTTP/1.1 and\n[HTTP/2](https://en.wikipedia.org/wiki/HTTP/2). The crawlers will\nuse the protocol version that provides the best crawling performance and may switch protocols\nbetween crawling sessions depending on previous crawling statistics. The default protocol\nversion used by Google's crawlers is HTTP/1.1; crawling over HTTP/2 may save computing resources\n(for example, CPU, RAM) for your site and Googlebot, but otherwise\nthere's no Google-product specific benefit to the site (for example, no ranking boost in Google Search).\nTo opt out from crawling over HTTP/2, instruct the server that's hosting your site to respond\nwith a `421` HTTP status code when Google attempts to access your site over\nHTTP/2. If that's not feasible, you\n[can send a message to the Crawling team](https://www.google.com/webmasters/tools/googlebot-report)\n(however this solution is temporary).\n\n\nGoogle's crawler infrastructure also supports crawling through FTP (as defined by\n[RFC959](https://datatracker.ietf.org/doc/html/rfc959) and its\nupdates) and FTPS (as defined by\n[RFC4217](https://datatracker.ietf.org/doc/html/rfc4217) and its\nupdates), however crawling through these protocols is rare.\n\n### Supported content encodings\n\n\nGoogle's crawlers and fetchers support the following content encodings (compressions):\n[gzip](https://en.wikipedia.org/wiki/Gzip),\n[deflate](https://en.wikipedia.org/wiki/Deflate), and\n[Brotli (br)](https://en.wikipedia.org/wiki/Brotli). The\ncontent encodings supported by each Google user agent is advertised in the\n`Accept-Encoding` header of each request they make. For example,\n`Accept-Encoding: gzip, deflate, br`.\n\n### Crawl rate and host load\n\n\nOur goal\nis to crawl as many pages from your site as we can on each visit without overwhelming your\nserver. If your site is having trouble keeping up with Google's crawling requests, you can\n[reduce the crawl rate](/search/docs/crawling-indexing/reduce-crawl-rate). Note that\nsending the inappropriate\n[HTTP response code](/search/docs/crawling-indexing/http-network-errors)\nto Google's crawlers may affect how your site appears in Google products.\n\n### HTTP Caching\n\n\nGoogle's crawling infrastructure supports heuristic HTTP caching as defined by the\n[HTTP caching standard](https://httpwg.org/specs/rfc9111.html),\nspecifically through the `ETag` response- and `If-None-Match` request\nheader, and the `Last-Modified` response- and `If-Modified-Since` request\nheader.\n| Note: Consider setting both the `Etag` and `Last-Modified` values regardless of the preference of Google's crawlers. These headers are also used by other applications such as CMSes.\n\n\nIf both `ETag` and `Last-Modified` response header fields are present in the\nHTTP response, Google's crawlers use the `ETag` value as\n[required by the HTTP standard](https://www.rfc-editor.org/rfc/rfc9110.html#section-13.1.3).\nFor Google's crawlers specifically, we recommend using\n[`ETag`](https://www.rfc-editor.org/rfc/rfc9110#name-etag)\ninstead of the `Last-Modified` header to indicate caching preference as\n`ETag` doesn't have date formatting issues.\n\n\nOther HTTP caching directives aren't supported.\n\n\nIndividual Google crawlers and fetchers may or may not make use of caching, depending on the needs\nof the product they're associated with. For example, `Googlebot` supports caching when\nre-crawling URLs for Google Search, and `Storebot-Google` only supports caching in\ncertain conditions.\n\n\nTo implement HTTP caching for your site, get in touch with your hosting or content management\nsystem provider.\n\n#### `ETag` and `If-None-Match`\n\n\nGoogle's crawling infrastructure supports `ETag` and `If-None-Match` as\ndefined by the\n[HTTP Caching standard](https://httpwg.org/specs/rfc9111.html).\nLearn more about the\n[`ETag`](https://www.rfc-editor.org/rfc/rfc9110#name-etag)\nresponse header and its request header counterpart,\n[`If-None-Match`](https://www.rfc-editor.org/rfc/rfc9110#name-if-none-match).\n\n#### Last-Modified and If-Modified-Since\n\n\nGoogle's crawling infrastructure supports `Last-Modified` and\n`If-Modified-Since` as defined by the\n[HTTP Caching standard](https://httpwg.org/specs/rfc9111.html)\nwith the following caveats:\n\n- The date in the `Last-Modified` header must be formatted according to the [HTTP standard](https://www.rfc-editor.org/rfc/rfc9110.html). To avoid parsing issues, we recommend using the following date format: \"Weekday, DD Mon YYYY HH:MM:SS Timezone\". For example, \"Fri, 4 Sep 1998 19:15:56 GMT\".\n- While not required, consider also setting the [`max-age` field of the `Cache-Control` response header](https://www.rfc-editor.org/rfc/rfc9111.html#name-max-age-2) to help crawlers determine when to recrawl the specific URL. Set the value of the `max-age` field to the expected number of seconds the content will be unchanged. For example, `Cache-Control: max-age=94043`.\n\n\nLearn more about the\n[`Last-Modified`](https://www.rfc-editor.org/rfc/rfc9110#name-last-modified)\nresponse header and its request header counterpart, [`If-Modified-Since`](https://www.rfc-editor.org/rfc/rfc9110#name-if-modified-since).\n\nVerifying Google's crawlers and fetchers\n----------------------------------------\n\n\nGoogle's crawlers identify themselves in three ways:\n\n1. The HTTP `user-agent` request header.\n2. The source IP address of the request.\n3. The reverse DNS hostname of the source IP.\n\n\nLearn how to use these details to\n[verify Google's crawlers and fetchers](/search/docs/crawling-indexing/verifying-googlebot)."]]
