[[["เข้าใจง่าย","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)."]]
