تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
بدء استخدام آلية Signed Exchange على "بحث Google"
تتيح آلية Signed Exchange (SXG)
لمحرّك بحث Google جلب المحتوى مسبقًا مع الحفاظ على خصوصية المستخدم. ومن الناحية العملية، يشير هذا الأمر إلى أنّ النتائج بتنسيق AMP أو غيره من التنسيقات والتي تظهر على محرّك بحث Google قد تجلب بعض الموارد الرئيسية مسبقًا (مثل HTML أو JavaScript أو CSS أو الصور أو الخطوط) بأسلوب يحفظ الخصوصية، وذلك في حال كان الموقع الإلكتروني المرتبط متوافقًا مع SXG.
عندما ينقر المستخدم في النهاية على النتيجة المطلوبة، يبدأ عرض صفحة الويب بسرعة أكبر لأنّ الموارد الرئيسية متوفّرة مسبقًا، ما يؤدي إلى تحسين تجربة المستخدم. وقد يؤدي هذا الأمر إلى انخفاض نتيجة سرعة عرض أكبر محتوى مرئي (LCP) للمحتوى الخاص بك، ما قد يحسّن بدوره تجربة الصفحة بشكل عام.
يستخدم محرّك بحث Google ذاكرة تخزين مؤقت في SXG لجلب المحتوى مسبقًا. وقد يعرض محرّك بحث Google محتوى SXG المخزن مؤقتًا
عدة مرات.
للتأكد من عرض المحتوى الأحدث في محرّك بحث Google، اضبط قيم انتهاء صلاحية SXG بشكلٍ مناسب. كقاعدة إرشادية، تأكَّد من أنّ تاريخ انتهاء الصلاحية يسبق كلا التاريخين التاليَين:
تاريخ انتهاء صلاحية ذاكرة التخزين المؤقت الذي تحدّده عناوين HTTP
تاريخ اليوم التالي إذا كان المحتوى بلغة JavaScript أو مضمّنًا في JavaScript، وبخلاف ذلك، التاريخ بعد 7 أيام
للتأكد من أنّ المحتوى يظهر بشكل صحيح عند عرضه على عدة أجهزة، يمكنك إجراء ما يلي:
انقل المحتوى المخصّص، مثل سلّات التسوّق، إلى عناصر التحميل الكسول
خارج نطاق SXG. ويمكنك بدلاً من ذلك إضافة عنوان Vary: Cookie المُوقَّع، وسيتم عندها عرض
ملفات SXG التي تتضمّن هذا العنوان فقط للزوّار الذين يدخلون إلى موقعك الإلكتروني بدون استخدام ملفات تعريف الارتباط.
أنشِئ الصفحات باستخدام
تصميم الويب السريع الاستجابة.
وبدلاً من ذلك، يمكنك عرض الصفحات المخصّصة لأجهزة الكمبيوتر وتلك المتوافقة مع الأجهزة الجوّالة على
عناوين URL منفصلة، أو إضافة تعليقات توضيحية إلى
الصفحات تشير إلى أنّها غير متجاوبة، وذلك باستخدام
علامة meta المسماة supported-media.
على سبيل المثال، في عنصر <head> للصفحة، أضِف العلامة التالية:
<meta name=supported-media content="only screen and (max-width: 640px)">
في حال تعذّر على Googlebot تحليل SXG، قد يعيد الزحف إلى عنوان URL بدون application/signed-exchange;v=b3
في العنوان Accept لاسترداد الصيغة text/html. في حال
حدوث خطأ فهرسة متعلّق بآلية SXG، سيضيف محرك بحث Google رابطًا يؤدي إلى عنوان URL الأصلي، بدون SXG.
كطريقة بديلة، يمكنك الاستعلام عن ذاكرة التخزين المؤقت الخاصة بخدمة SXG من Google مباشرةً.
على سبيل المثال، إذا كان عنوان URL الخاص بآلية SXG هو https://signed-exchange-testing.dev/sxgs/valid.html، يمكنك صياغة
عنوان URL المقابل لذاكرة التخزين المؤقت:
إذا كان الردّ عبارة عن SXG، هذا يعني أنّ الاستجابة من خادم المصدر تستوفي متطلبات ذاكرة التخزين المؤقت الخاصة بخدمة SXG من Google.
وبخلاف ذلك، سيتضمّن الردّ عنوان HTTP يشير إلى السبب.
إذا كان هناك عنوان Warning، سيشير إلى الخطأ الذي منع SXG من
تلبية متطلبات ذاكرة التخزين المؤقت.
إذا كان هناك عنوان Location، هذا يعني أن ذاكرة التخزين المؤقت لم تجلب الردّ بعد. ولا يشير ذلك إلى
وجود خطأ في SXG.
بغض النظر عن الردّ، تُدرِج ذاكرة التخزين المؤقت طلبًا في عنوان URL المصدر للحصول على نسخة
معدّلة. وهناك عوامل متعددّة تؤثّر في وقت حدوث هذا الطلب واحتمال حدوثه، من بينها سرعة زحف Googlebot إلى موقعك الإلكتروني.
لا يخزِّن محرّك بحث Google ملفات SXG مؤقتًا لمدة تتجاوز القيمة expires لتوقيع SXG
أو
مدة
حداثة العناوين غير الموقَّعة لاستجابة SXG.
بالنسبة إلى صفحات AMP، يمكنك استخدام
أداة فحص عنوان URL
لتصحيح أخطاء التخزين المؤقت.
الاطّلاع على آخر المعلومات
اشترِك في القائمة البريدية webpackaging-announce للبقاء على اطّلاع بالتغييرات التالية:
التغييرات التي نجريها على ذاكرة التخزين المؤقت الخاصة بخدمة SXG من Google والتي تفعّل إمكانات جديدة أو توقف إمكانات أخرى
التغييرات الكبيرة التي نجريها على أدوات SXG، من بينها Web Packager ووحدة NGINX SXG وlibsxg
تاريخ التعديل الأخير: 2025-08-04 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","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 (حسب التوقيت العالمي المتفَّق عليه)"],[[["\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)."]]
