透過集合功能整理內容
你可以依據偏好儲存及分類內容。
針對 Google 搜尋開始使用 Signed Exchange
Signed Exchange (SXG) 可讓 Google 搜尋預先擷取您的內容，同時確保使用者的隱私安全。從實務上來看，這代表如果相關聯的網站支援 SXG，那麼不論是 Google 搜尋中顯示的 AMP 還是非 AMP 搜尋結果，或許都可以透過保護隱私權的方式預先擷取某些關鍵資源，例如 HTML、JavaScript、CSS、圖片或字型等。
由於關鍵資源已準備就緒，因此當使用者最終點選搜尋結果時，網頁開始顯示的速度就會變快，進而提供更優質的使用者體驗。不過，這可能表示內容的最大內容繪製 (LCP) 得分會較低，進而提升整體網頁體驗。
實作 SXG
如要實作 SXG，請按照 web.dev 的詳盡指南操作。
實作後，請按照 Chrome 指南使用 Signed Exchange 最佳化 LCP。
如果是 AMP 網頁，請按照 amp.dev 的詳盡指南操作。
Google 搜尋的其他相關規定
Google 會使用 SXG 快取來預先擷取您的內容，因此可能會多次提供這些快取 SXG。
為確保 Google 搜尋能夠顯示最新的內容，請妥善設定 SXG 的到期日。原則上，請確保到期日在以下兩個日期之前：
- 由 HTTP 標頭判定的快取到期時間
- 如果內容是透過 JavaScript 或內嵌 JavaScript 建立，就是 1 天後；其他情況則是 7 天後
為確保內容在多部裝置上提供時能正常顯示，請執行以下操作：
- 將購物車等個人化內容移至 SXG 外的延遲載入元素中。或者，您也可以新增
Vary: Cookie 簽名標頭；只有不具備您的網站 Cookie 的訪客才會看到含有這個標頭的 SXG。
- 採用回應式網頁設計來建構網頁，或者透過不同網址提供電腦版和行動版網頁；您也可以使用
supported-media meta 標記為網頁加註，說明這些網頁不是回應式網頁。
例如，在網頁的 <head> 元素中加入下列標記：
<meta name=supported-media content="only screen and (max-width: 640px)">
監控及對 SXG 進行偵錯
如需可用來對 SXG 偵錯的工具清單，請參閱 web.dev 的 SXG 工具指南。
如果 Googlebot 無法剖析 SXG，系統為了擷取 text/html 變數，可能會在 Accept 標頭中缺少 application/signed-exchange;v=b3 的情況下重新檢索網址。
如果發生任何 SXG 索引錯誤，Google 搜尋會連結至原始網址，不使用 SXG。
如果是 AMP 網頁，請使用 Search Console 中的 AMP 狀態報告來監控 SXG 錯誤。
對 Google SXG 快取進行偵錯
如要判斷 SXG 是否符合快取規定，請使用 SXG Validator Chrome 擴充功能。
或者直接查詢 Google SXG 快取。
舉例來說，如果 SXG 網址為 https://signed-exchange-testing.dev/sxgs/valid.html，請將對應的快取網址建立為：
https://signed--exchange--testing-dev.webpkgcache.com/doc/-/s/signed-exchange-testing.dev/sxgs/valid.html
用來計算子網域和網址路徑後置字串的演算法與 AMP 快取的演算法相同，但中置字串 /doc/-/ 並不相同。
如果回應是 SXG，表示原始伺服器的回應符合 Google SXG 快取規定；如果不是，回應會含有用來說明原因的 HTTP 標頭。
- 如果有
Warning 標頭，代表發生錯誤，導致 SXG 無法符合快取規定。
- 如果有
Location 標頭，即表示快取尚未擷取該標頭。這並不是 SXG 中的錯誤。
無論是哪一種回應，快取都會將對原始網址的要求排入佇列，然後要求更新的網址。這個要求何時會發生，以及是否會發生，取決於多項因素，包括 Googlebot 檢索網站的速度。
Google 對 SXG 快取的時間不會超過 SXG 簽名中的 expires 值，或是 SXG 回應中未簽署標頭中的更新生命週期。
針對 AMP 網頁，您可以使用網址檢查工具對快取錯誤進行偵錯。
訂閱 webpackaging-announce 郵寄清單即可掌握下列各項最新異動：
- Google SXG 快取變動，包括新功能啟用和舊功能淘汰等內容。
- SXG 工具 Web Packager、NGINX SXG 模組和 libsxg 的重大變更。
如果您對 Google 搜尋的 SXG 有任何疑問，請造訪搜尋中心產品討論社群。
除非另有註明，否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權，程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間：2025-08-04 (世界標準時間)。
[null,null,["上次更新時間：2025-08-04 (世界標準時間)。"],[[["\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)."]]
