Google은 크롤러 또는 가져오기 도구를 사용하여 자동 또는 사용자 요청에 의해 트리거되는 방식으로 제품에 대한 작업을 수행합니다. 크롤러('로봇' 또는 '스파이더'라고도 함)는 일반적으로 웹사이트를 자동으로 검색하고 스캔하는 데 사용되는 프로그램을 가리키는 용어입니다.
가져오기 도구는 일반적으로 사용자를 대신하여 단일 요청을 실행하는 wget과 같은 프로그램 역할을 합니다. Google의 클라이언트는 세 가지 카테고리로 분류됩니다.
사용자 트리거 가져오기 도구는 최종 사용자가 가져오기를 트리거하는 도구 및 제품 기능입니다. 예를 들어 Google 사이트 인증 도구는 사용자의 요청에 따라 작동합니다.
Google 크롤러 및 가져오기 도구의 기술 속성
Google 크롤러와 가져오기 도구는 웹이 확장됨에 따라 성능과 규모를 향상시키기 위해 수천 대의 컴퓨터에서 동시에 실행되도록 설계되었습니다. 대역폭 사용량을 최적화하기 위해 이 클라이언트는 전 세계 여러 데이터 센터에 분산되어 액세스할 수 있는 사이트 근처에 위치합니다. 그러므로 로그에는 여러 IP 주소에서 방문한 내역이 표시될 수 있습니다.
Google은 주로 미국 IP 주소에서 이그레스합니다. Google이 미국에서 발생한 요청을 차단하는 사이트를 감지하면 다른 국가에 있는 IP 주소에서 크롤링을 시도할 수 있습니다.
지원되는 전송 프로토콜
Google 크롤러와 가져오기 도구는 HTTP/1.1 및 HTTP/2를 지원합니다. 이 크롤러는 가장 우수한 크롤링 성능을 제공하는 프로토콜 버전을 사용하며 이전 크롤링 통계에 따라 크롤링 세션 간에 프로토콜을 전환할 수 있습니다. Google 크롤러에서 사용하는 기본 프로토콜 버전은 HTTP/1.1입니다. HTTP/2를 통해 크롤링하면 사이트와 Googlebot의 컴퓨팅 리소스(예: CPU, RAM)를 절약할 수 있지만 사이트에는 Google 제품별 이점이 없습니다(예: Google 검색에서 순위가 상승하지 않음).
HTTP/2를 통한 크롤링을 거부하려면 Google이 HTTP/2를 통해 사이트에 액세스하려고 할 때 421 HTTP 상태 코드로 응답하도록 사이트를 호스팅하는 서버에 지시합니다. 그렇게 할 수 없는 경우 크롤링팀에 메시지를 보내면 됩니다(단, 이 방법은 일시적임).
Google의 크롤러 인프라는 FTP(RFC959 및 업데이트에 정의됨) 및 FTPS(RFC4217 및 업데이트에 정의됨)를 통한 크롤링도 지원하지만 이러한 프로토콜을 통한 크롤링은 드뭅니다.
지원되는 콘텐츠 인코딩
Google의 크롤러와 가져오기 도구는 다음과 같은 콘텐츠 인코딩(압축)을 지원합니다.
gzip,
deflate,
Brotli(br) 각 Google 사용자 에이전트에서 지원하는 콘텐츠 인코딩은 각 요청의 Accept-Encoding 헤더에 광고됩니다. 예:
Accept-Encoding: gzip, deflate, br.
크롤링 속도 및 호스트 로드
Google의 목표는 방문한 사이트에서 서버에 무리를 주지 않으면서 가능한 한 많은 페이지를 크롤링하는 것입니다. 사이트에서 Google의 크롤링 요청 속도를 맞추는 데 문제가 있는 경우 크롤링 속도를 낮출 수 있습니다. Google 크롤러에 부적절한 HTTP 응답 코드를 전송하면 Google 제품에 사이트가 표시되는 방식에 영향을 미칠 수 있습니다.
HTTP 캐싱
Google의 크롤링 인프라는 HTTP 캐싱 표준에 정의된 휴리스틱 HTTP 캐싱을 지원합니다. 특히 ETag 응답 및 If-None-Match 요청 헤더, Last-Modified 응답 및 If-Modified-Since 요청 헤더를 통해 이러한 캐싱을 지원합니다.
HTTP 응답에 ETag 및 Last-Modified 응답 헤더 필드가 모두 있는 경우 Google 크롤러는 HTTP 표준에서 요구하는 대로ETag 값을 사용합니다.
특히 Google 크롤러의 경우 Last-Modified 헤더 대신 ETag를 사용하여 캐싱 환경설정을 지정하는 것이 좋습니다. ETag에는 날짜 형식 지정 문제가 없기 때문입니다.
다른 HTTP 캐싱 지시는 지원되지 않습니다.
개별 Google 크롤러와 가져오기 도구는 연결된 제품의 요구사항에 따라 캐싱을 사용할 수도 있고 사용하지 않을 수도 있습니다. 예를 들어 Googlebot은 Google 검색의 URL을 다시 크롤링할 때 캐싱을 지원하고 Storebot-Google은 특정 조건에서만 캐싱을 지원합니다.
사이트에 HTTP 캐싱을 구현하려면 호스팅 또는 콘텐츠 관리 시스템 제공업체에 문의하세요.
ETag 및 If-None-Match
Google의 크롤링 인프라는 HTTP 캐싱 표준에 정의된 대로 ETag 및 If-None-Match를 지원합니다.
ETag 응답 헤더와 이에 상응하는 요청 헤더인 If-None-Match에 대해 자세히 알아보세요.
Last-Modified 및 If-Modified-Since
Google의 크롤링 인프라는 HTTP 캐싱 표준에 정의된 Last-Modified 및 If-Modified-Since를 지원하지만 다음과 같은 예외가 있습니다.
Last-Modified 헤더의 날짜는 HTTP 표준에 따라 형식이 지정되어야 합니다.
파싱 문제를 방지하려면 '평일, DD Mon YYYY HH:MM:SS 시간대'와 같은 날짜 형식을 사용하는 것이 좋습니다. 예를 들면 'Fri, 4 Sep 1998 19:15:56 GMT'처럼 설정할 수 있습니다.
필수는 아니지만 크롤러가 특정 URL을 다시 크롤링할 시기를 결정하는 데 도움이 되도록 Cache-Control 응답 헤더의 max-age 필드도 설정해 보세요. max-age 필드의 값을 콘텐츠가 변경되지 않을 것으로 예상되는 초 수로 설정합니다. 예를 들면 'Cache-Control: max-age=94043'과 같이 설정할 수 있습니다.
[null,null,["최종 업데이트: 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)."]]
