Теперь нас можно найти в LinkedIn. Если вас интересуют новости и ресурсы Google Поиска о том, как оптимизировать показ сайта в результатах поиска, подпишитесь на нас в LinkedIn.

Как использовать обмен с подписью в Google Поиске

Функция обмена с подписью (SXG) позволяет Google Поиску выполнять предзагрузку контента, не нарушая конфиденциальность пользователя. Это означает, что при показе обычных и AMP-результатов в Google Поиске может выполняться предварительная загрузка некоторых ключевых ресурсов (например, кода HTML, JavaScript и CSS, а также изображений и шрифтов) с сохранением конфиденциальности, если содержащий эти ресурсы сайт поддерживает технологию SXG.

Таким образом, когда пользователь нажимает на результат, отрисовка веб-страницы начинает осуществляться намного быстрее благодаря тому, что основные ресурсы уже доступны. Это повышает удобство просмотра ваших материалов. Может также сократиться время отрисовки самого крупного контента (LCP). Хотя само по себе использование обмена с подписью не учитывается при определении позиции сайта в Google Поиске, уменьшение показателя LCP может сыграть свою роль, поскольку удобство страниц входит в число критериев ранжирования.

Как настроить SXG

Следуйте подробному руководству на сайте web.dev. Настроив SXG, ознакомьтесь со сведениями о том, как оценить и оптимизировать рост эффективности, связанный с этой функцией.

Если вас интересует настройка этой функции для AMP-страниц, следуйте подробному руководству на сайте amp.dev.

Дополнительные требования, относящиеся к показу контента в Google Поиске

Выполняя предзагрузку вашего контента, Google использует кеш SXG-файлов. Кешированные SXG-файлы могут отправляться с наших серверов многократно.

Чтобы в Google Поиске был представлен актуальный контент, правильно указывайте дату, до которой данные в формате SXG будут считаться действительными. Соблюдайте следующие условия:

Такая дата должна предшествовать моменту окончания срока, который указан в вашем HTTP-заголовке.
Такая дата должна наступать не позже чем на следующий день, если контент создается с помощью кода JavaScript или содержит такой код, а в противном случае – не позже чем через семь дней.

Как обеспечить корректный показ материалов на разных устройствах:

Перенесите персонализированный контент, например содержимое корзины интернет-магазина, в элементы с отложенной загрузкой, которые не включаются в SXG-файлы. Также можно добавить подписанный заголовок Vary: Cookie, чтобы SXG-файлы с ним показывались только посетителям, у которых нет файла cookie вашего сайта.
Используйте адаптивный дизайн. Если это невозможно, то размещайте страницы для компьютеров и мобильных устройств по разным URL. Также вы можете помечать неадаптивные страницы метатегом supported-media. Пример такого тега в элементе страницы <head>:
```
<meta name=supported-media content="only screen and (max-width: 640px)">
```

Как выявлять и устранять неполадки SXG

Ознакомьтесь со списком инструментов для отладки SXG-файлов на сайте web.dev.

Когда у робота Googlebot не получается обработать SXG, он может повторно отсканировать URL без элемента application/signed-exchange;v=b3 в заголовке Accept, чтобы получить вариант text/html. При возникновении ошибки индексирования SXG Google Поиск установит связь с исходным URL, где не используется SXG.

В случае с AMP-страницами выявлять ошибки SXG поможет отчет о статусе AMP-страниц в Search Console.

Как выполнять отладку при работе с кешем Google SXG Cache

Чтобы определить, отвечает ли SXG-файл требованиям кеша, воспользуйтесь расширением SXG Validator в браузере Chrome.

Также можно отправить запрос непосредственно в Google SXG Cache. Например, если URL для SXG – https://signed-exchange-testing.dev/sxgs/valid.html, то URL кешированного файла будет таким:

https://signed--exchange--testing-dev.webpkgcache.com/doc/-/s/signed-exchange-testing.dev/sxgs/valid.html

Субдомен и фрагмент URL в конце формируются по тому же принципу, что и для кеша Google AMP Cache, а компонент /doc/-/ в середине отличается.

Если вы получите ответ в формате SXG, значит ответ с исходного сервера соответствует требованиям кеша Google SXG Cache. В противном случае причина проблемы будет указана в HTTP-заголовке.

Заголовок Warning означает, что обнаружена ошибка, из-за которой SXG-файл не соответствует требованиям кеша.
Заголовок Location означает, что SXG-файл пока не добавлен в кеш. Это не говорит о наличии ошибок.

Независимо от вида ответа кеш добавляет в очередь запрос к исходному URL, который должен вернуть актуальную копию файла. Вероятность и время выполнения запроса зависят от разных факторов, например от частоты сканирования вашего сайта роботом Googlebot.

Google кеширует SXG-файлы на срок, указанный в параметре expires подписи SXG, или на срок действия неподписанных заголовков ответа SXG.

Ошибки кеширования, связанные с AMP-страницами, можно устранять при помощи инструмента проверки URL.

Следите за новостями

Подпишитесь на рассылку webpackaging-announce, чтобы своевременно получать следующую информацию:

уведомления о внедрении или упразднении функций кеша Google SXG Cache;
сведения о существенных изменениях в таких инструментах для работы с технологией SXG, как Web Packager, SXG-модуль nginx и библиотека libsxg.

Если у вас есть вопросы по поводу использования обмена с подписью в Google Поиске, посетите наш справочный форум.