서명된 교환(SXG)을 사용하면 Google 검색에서 사용자의 개인 정보를 보호하면서 콘텐츠를 미리 가져올 수 있습니다. 실질적으로는 연결된 웹사이트에서 SXG를 지원하는 경우 Google 검색에 표시되는 AMP 결과와 AMP가 아닌 결과에서 모두 개인 정보를 보호하는 방식으로 몇 가지 주요 리소스(HTML, 자바스크립트, CSS, 이미지, 글꼴 등)를 미리 가져올 수 있다는 의미입니다.
사용자가 최종적으로 결과를 클릭하면 주요 리소스를 이미 사용할 수 있으므로 웹페이지의 렌더링이 훨씬 빠르게 시작되어 사용자 환경이 개선됩니다. 즉, 콘텐츠의 최대 콘텐츠 렌더링 시간(LCP) 점수가 낮아지면서 전반적인 페이지 경험이 개선될 수 있습니다.
Google은 SXG 캐시를 사용하여 콘텐츠를 미리 가져옵니다. Google은 이러한 캐시된 SXG를 여러 번 제공할 수 있습니다.
Google 검색에 최신 콘텐츠가 표시되도록 하려면 SXG 만료 값을 적절하게 설정하세요. 일반적으로 만료일은 다음 두 날짜 전이어야 합니다.
HTTP 헤더에 지정된 캐시 만료일
콘텐츠가 자바스크립트나 인라인 자바스크립트인 경우 향후 1일, 그 외의 경우 향후 7일
콘텐츠가 여러 기기에 게재될 때 제대로 표시되도록 하려면 다음 안내를 따르세요.
장바구니와 같은 맞춤설정된 콘텐츠를 SXG 외부에 있는 지연 로드 요소로 이동합니다. 또는 Vary: Cookie 서명된 헤더를 추가합니다. 이 헤더가 있는 SXG는 사이트 쿠키가 없는 방문자에게만 표시됩니다.
반응형 웹 디자인을 사용하여 페이지를 빌드합니다.
또는 데스크톱과 모바일 페이지를 별도 URL에 제공하거나 supported-mediameta 태그를 사용하여 페이지가 응답하지 않는다고 명시하는 주석을 페이지에 추가합니다.
예를 들어 페이지의 <head> 요소에서 다음 태그를 추가합니다.
<meta name=supported-media content="only screen and (max-width: 640px)">
Googlebot이 SXG를 파싱할 수 없는 경우 text/html 변형을 가져오기 위해 Accept 헤더에 application/signed-exchange;v=b3이 없는 URL을 다시 크롤링할 수 있습니다. SXG 색인 생성 오류가 발생하는 경우 Google 검색은 SXG 없이 원래 URL로 연결됩니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-08-04(UTC)"],[[["\u003cp\u003eSigned Exchanges (SXGs) enable Google Search to prefetch website content, enhancing user experience by speeding up page load times while maintaining privacy.\u003c/p\u003e\n"],["\u003cp\u003eImplementing SXGs involves following specific guides for general websites and AMP pages, ensuring content is optimized for Google Search.\u003c/p\u003e\n"],["\u003cp\u003eGoogle caches SXGs and recommends setting appropriate expiration values to keep content up-to-date in search results.\u003c/p\u003e\n"],["\u003cp\u003eFor content to display correctly across devices, developers should consider lazy-loading personalized elements or implementing responsive design techniques.\u003c/p\u003e\n"],["\u003cp\u003eMonitoring and debugging SXGs involves utilizing various tools and resources, including Chrome extensions and Google Search Console, to identify and resolve potential issues.\u003c/p\u003e\n"]]],["Signed exchanges (SXG) enable Google Search to prefetch website content, improving user experience by reducing page load times. To implement SXG, use guides from web.dev or amp.dev (for AMP pages). Ensure up-to-date content by setting SXG expiration to less than one day (for JavaScript) or seven days, or less than the HTTP cache expiration. Optimize for multiple devices, and use debugging tools like the SXG Validator extension. Monitor SXG performance and errors via Google Search Console, and stay informed of updates via the webpackaging-announce mailing list.\n"],null,["# Signed Exchanges on Google Search | Google Search Central\n\nGet started with signed exchanges on Google Search\n==================================================\n\n\n[Signed exchanges](https://web.dev/articles/signed-exchanges) (SXG) allow\nGoogle Search to prefetch your content while preserving the user's privacy. In practice, this\nmeans that both AMP and non-AMP results shown on Google Search may prefetch a few key\nresources (such as HTML, JavaScript, CSS, images, or fonts) in a privacy-preserving manner,\nif the associated website supports SXG.\n\n\nWhen the user ultimately clicks the result, the web page starts rendering much sooner since\nkey resources are already available, leading to a better user experience. This could mean a\nlower [Largest Contentful Paint (LCP)](https://web.dev/articles/lcp) score\nfor your content, which can improve\n[page experience](/search/docs/appearance/page-experience) overall.\n\nImplement SXG\n-------------\n\n\nTo implement SXG, follow [web.dev's\nin-depth guide](https://web.dev/articles/signed-exchanges#tooling). After implementing, follow\n[Chrome's guide to optimizing LCP using Signed Exchanges](https://developer.chrome.com/blog/optimizing-lcp-using-signed-exchanges).\n\n\nFor AMP pages, follow [amp.dev's in-depth guide](https://amp.dev/documentation/guides-and-tutorials/optimize-and-measure/signed-exchange/).\n\n### Additional requirements for Google Search\n\n\nGoogle uses a cache of SXG to prefetch your content. Google may serve these cached SXG\nmultiple times.\n\n\nTo make sure that up-to-date content displays in Google Search, set the SXG expiration values\nappropriately. As a rule of thumb, make sure that the expiration date is less than both of these dates:\n\n- The cache expiration determined by your HTTP headers\n- 1 day in the future if the content is JavaScript or inlines JavaScript; otherwise 7 days in the future\n\n\nTo make sure that content displays properly when served on multiple devices, do the following:\n\n1. Move personalized content, such as shopping carts, into lazy-loaded elements that are outside of the SXG. Alternatively, add the `Vary: Cookie` signed header; SXGs with this header will be shown only to visitors without a cookie for your site.\n2. Build the pages with [responsive web design](https://web.dev/articles/responsive-web-design-basics). Alternatively, serve desktop and mobile pages on [separate URLs](/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing#separate-urls), or annotate the pages to state that they aren't responsive, using the [`supported-media` `meta` tag](https://github.com/google/webpackager/blob/main/docs/supported_media.md). For example, in the page's `\u003chead\u003e` element, add the following tag: \n\n ```text\n \u003cmeta name=supported-media content=\"only screen and (max-width: 640px)\"\u003e\n ```\n\nMonitor and debug SXG\n---------------------\n\n\nFor a list of tools that you can use to debug SXG, check out [web.dev's guide to SXG tools](https://web.dev/articles/signed-exchanges#tooling).\n\n\nIn the event that Googlebot can't parse an SXG, it may recrawl the URL without `application/signed-exchange;v=b3`\nin the `Accept` header, in order to retrieve the `text/html` variant. In\nthe event of any SXG indexing error, Google Search will link to the original URL, without SXG.\n\n\nFor AMP pages, use the [AMP\nstatus report](https://support.google.com/webmasters/answer/7450883) in Search Console to monitor [SXG errors](https://support.google.com/webmasters/answer/7450883#sgx_warning_list).\n\nDebug the Google SXG cache\n--------------------------\n\n\nTo determine whether SXG meets the cache requirements, use the\n[SXG Validator Chrome extension](https://chrome.google.com/webstore/detail/sxg-validator/hiijcdgcphjeljafieaejfhodfbpmgoe).\n\n\nAlternatively, query the Google SXG cache directly.\nFor example, if the SXG URL is `https://signed-exchange-testing.dev/sxgs/valid.html`, formulate\nthe corresponding cache URL:\n\n\n`https://signed--exchange--testing-dev.webpkgcache.com/doc/-/s/signed-exchange-testing.dev/sxgs/valid.html`\n\n\nThe algorithm for computing the subdomain and the URL path suffix is the\n[same as for the AMP Cache](https://amp.dev/documentation/guides-and-tutorials/learn/amp-caches-and-cors/amp-cache-urls/),\nwhile the infix string `/doc/-/` is different.\n\n\nIf the response is a SXG, then this means the response from the origin server meets the\nGoogle SXG [cache requirements](https://github.com/google/webpackager/blob/main/docs/cache_requirements.md).\nOtherwise, it will include an HTTP header that indicates the reason.\n\n- If there is a `Warning` header, then it indicates an error that prevented the SXG from meeting the cache requirements.\n- If there is a `Location` header, then it has not yet been fetched by the cache. This is not an error in your SXG.\n\n\nRegardless of the response, the cache enqueues a request to the original URL for an updated\ncopy. There are several factors for when and if this request happens, including how fast\nGooglebot can crawl your site.\n\n\nGoogle doesn't cache SXGs for longer than the `expires` value of the SXG signature\nor the\n[freshness\nlifetime](https://datatracker.ietf.org/doc/html/rfc7234#section-4.2.1) of the unsigned headers of the SXG response.\n\n\nFor AMP pages, you can use the\n[URL Inspection Tool](https://support.google.com/webmasters/answer/9012289)\nto debug caching errors.\n\nStay informed\n-------------\n\n\nSubscribe to the [webpackaging-announce](https://groups.google.com/g/webpackaging-announce)\nmailing list to stay up-to-date with the following changes:\n\n- Changes to the Google SXG cache that enable new capabilities or deprecate other capabilities.\n- Major changes to the SXG tools Web Packager, NGINX SXG module, and libsxg.\n\n\nIf you have questions about SXG on Google Search, visit the\n[Search Central Help Community](https://support.google.com/webmasters/community)."]]
