Как приготовить публикацию для Гугл Discover: чек-лист для SEO-специалиста
Попадание в ленту Discover может принести много трафика, но даже многообещающий материал не сработает, если поисковик неправильно считает данные со странички. В данной для нас статье – практическая {инструкция} для SEO-специалистов и разрабов, которая поможет приготовить и проверить публикацию перед выпуском.
Что такое Гугл Discover и чем он увлекателен издателям
Гугл Discover – лента советов со статьями и видео, которую Гугл сформировывает без запроса в поисковике. Юзер открывает ленту, а система сама решает, какие материалы ему показать и в котором порядке.
Для издателей Discover – доп источник трафика. Если сюжет набирает популярность, публикация может получить широкий охват, в том числе посреди людей без сформированного энтузиазма к теме.
|
Подробнее о работе рекомендательной ленты – в статье Персонализированный и неперсонализированный Гугл Discover: в чем разница |
Пригодной темы недостаточно, чтоб попасть в ленту. Поначалу Гугл должен обработать содержимое странички и найти, к какой группы относится публикация и как представить ее в наставлениях.
Для этого система анализирует данные материала – от заголовка и изображения до разметки и технических характеристик странички. Если часть данных передается неправильно, Гугл может некорректно обработать публикацию, ограничить ее показы либо совсем не добавить в ленту.
|
Discover Trends помогает SEO-специалистам отыскивать доп точки роста в Гугл Discover. Инспектируйте, есть ли трафик в нише клиента, изучайте публикации соперников и добавляйте в контент-план темы за пределами традиционного поискового спроса. Сервис помогает отыскивать материалы с потенциалом в Discover и выслеживать, какие темы получают огромные охваты. Заказать демо |
Какие данные Гугл анализирует при формировании ленты
До этого чем подобрать публикации, Chrome либо приложение Гугл инспектирует, можно ли загрузить и обновить Discover. Система учитывает, избран ли Гугл поисковой машиной по дефлоту, включена ли лента и не исчерпан ли предел ее обновлений. Он составляет около 20 запросов фида в денек.
Далее на сервер отчаливает большенный набор данных, посреди которых:
-
Технические свойства. Язык и локаль, размер экрана, операционная система, версия Chrome и остальные опции приложения либо браузера.
-
Интересы юзера. Гугл учитывает, к каким материалам юзер переходил за крайние день, 7, 14 и 30 дней. Наиболее свежайшие интересы посильнее влияют на персонализированные советы.
-
История ленты. Когда приложение запрашивает у серверов Гугл новейшую выборку для Discover, то передает данные о материалах, которые юзер уже лицезрел. В перечне быть может до 500 публикаций – это дозволяет не дублировать показ карточек.
-
Деяния с карточками. Система фиксирует показы и клики, позицию материала в ленте, категорию, источник, отметки юзера «Не демонстрировать этот контент».
Гугл заблаговременно предсказывает возможность клика по карточке – этот показатель именуется PCTR, либо прогнозный CTR. Опосля показа система ассоциирует прогноз с настоящим поведением юзера: кликнул он по материалу, пролистал карточку либо укрыл ее. Эта реакция может употребляться для корректировки PCTR и влиять на предстоящее ранжирование.
Любая карточка сохраняется в ленте Discover до 48 часов с момента первой загрузки. Опосля этого приложение принудительно запрашивает обновление, потому с течением времени старенькые советы заменяются новенькими.
Как Гугл получает данные о материале
Перед тем как представить публикацию в Discover, Гугл собирает данные о самой страничке. Их обработка начинается на сервере. Googlebot получает HTML, извлекает структурированные данные и метатеги, а потом передает материал на систематизацию. Система описывает его тему и остальные признаки, которые употребляются при подборе советов.
Информация берется не из 1-го источника – для различных характеристик предусмотрены цепочки фоллбэков, другими словами запасных источников. Если значение не найдено в приоритетном, Гугл инспектирует последующий в цепочке.
Вот источники, из которых Гугл получает главные данные о публикации:
|
Сигнал |
Цепочка фоллбэков |
|
Title |
Schema.org → og:title → twitter:title → HTML title |
|
Image |
og:image → twitter:image → og:image:secure_url |
|
Publisher |
Schema.org → og:site_name → author (HTML) |
|
Language |
og:locale → inLanguage (JSON-LD) → «en» |
|
Paywall |
article:content_tier + isAccessibleForFree |
Один и этот же параметр, к примеру заголовок либо издатель, быть может указан сходу в нескольких источниках. Если значения различаются, Гугл выбирает меж ними. Потому HTML, структурированные данные и Open Graph лучше согласовывать меж собой. Дальше на примере заголовков мы покажем, к чему могут привести расхождения.
Обработка странички не завершается первым обходом Googlebot. Опосля того как юзер открывает публикацию, приложение добавочно инспектирует ее состояние и передает данные на сервер Гугл. А именно, система выслеживает доступность материала, конфигурации метаданных, также пэйвол – ограничение доступа к контенту.
RSS и WebFeed
Не считая обыденного обхода веб-сайта Гугл может узнавать о новейших публикациях через WebFeed – доп канал, связанный с RSS-фидами издателей. Если юзер подписывается на источник публикации, Гугл находит его RSS-фид и учитывает подписку при формировании советов. Материалы такового источника могут появляться в наставлениях почаще.
Для публикаций, приобретенных через WebFeed, Гугл собирает те же данные о взаимодействиях, что и для других карточек Discover: показы, клики и остальные деяния юзеров. Потому реакция подписчиков потенциально может учитываться при оценке фактического CTR материала. Не считая RSS, WebFeed раздельно инспектирует favicon веб-сайта – его доступность и правильность тоже необходимо включить в технический аудит.
Как Гугл выбирает и переписывает заглавия
У одной публикации быть может несколько вариантов заголовка: в Schema.org, Open Graph, Twitter-разметке и HTML. Но при всем этом не постоянно в карточке Discover возникает один из данных издателем вариантов.
Из 34 тыщ публикаций, изученных WSS, лишь в 32% случаев заголовок в ленте совпал и с Open Graph, и с HTML title.

Как Гугл выбирает заглавия
Гугл может поменять один из данных заголовков либо сгенерировать новейший, даже если такового варианта нет ни в каком элементе странички.
К примеру, у Euronews выходила статья с заголовком «Польский мега-аэропорт станет одним из огромнейших транспортных узлов Европы». В Discover Гугл сформировал наиболее определенный вариант – «Польша строит мега-аэропорт за 30 млрд евро», взяв сумму из публикации.
Еще Гугл может убирать служебные части заголовка. Приблизительно в 16% показов из подборки система удаляет брендовый суффикс, к примеру заглавие издания, добавленное в конце: «Заголовок статьи – XBT Games». Аналогично Гугл может убрать и заглавие рубрики, к примеру «Заголовок статьи – Анонсы». Потому прописанный в title бренд либо раздел не гарантирует, что юзер увидит их в карточке Discover.
Как приготовить изображение для Гугл Discover
Изображение влияет на то, как материал отображается в Discover, а технические характеристики файла – на возможность корректно показать карточку. К иллюстрации есть несколько требований:

Главные требования к изображениям для карточек Гугл Discover
Для большого превью используйте картину шириной не наименее 1200 пикселей. Если она меньше, материал, быстрее всего, получит thumbnail – маленькое изображение рядом с заголовком.
Очередной неотклонимый параметр снутри метатега robots – max-image-preview: large. Он разрешает Гугл употреблять полноразмерное изображение в результатах и наставлениях. Без этого картина отображается лишь в уменьшенном формате.
Также уточните, какое изображение обозначено в Open Graph – метатеге og:image. Гугл может получить картину из нескольких источников, но вариант из Open Graph время от времени становится приоритетнее изображения из микроразметки.
Перед публикацией проверьте и технические характеристики файла:
-
Доступность файла. URL изображения должен раскрываться для Гугл и не быть заблокирован в robots.txt.
-
Качество отображения. Удостоверьтесь, что картина точная, без приметного размытия, пикселизации и остальных изъянов.
-
Формат файла. Используйте JPEG, PNG либо WebP. Данных о преимуществе какого-нибудь из этих форматов для ранжирования нет – они все могут нормально отображаться в ленте.
Можно ли поменять заголовок и изображение опосля публикации
Гугл замечает конфигурации во время показов материала в Discover. Опосля открытия статьи юзером система повторно инспектирует часть метаданных и передает новейшие на сервер.
Поменять заголовок либо картину можно, пока материал получает показы в Discover. Но сама правка не запускает рост охватов – почти все зависит от того, что конкретно изменяется и в которой момент.
К примеру, на Stavka.tv материал о матче «Сочи» – «Спартак» достигнул пика видимости около 16:00 UTC – приблизительно за полчаса до начала игры. Позже коэффициент в заголовке обновили, но это не посодействовало продлить показы. К моменту смены коэффициента волна энтузиазма прошла, потому что аудитория в главном уже сделала ставки.
Предсказательная модель Гугл понимает про паттерны, которые понижают CTR. Если их убрать, показы могут вырасти. Но смена заголовка сама по для себя не дает автоматического буста – это быстрее очередной метод попасть в ленту, если начальная формулировка не нравится Гугл.
Как проверить язык и локаль
Гугл учитывает язык текста и регион, для которого предназначена публикация. Для определения языка предусмотрена цепочка фолбэков:
og:locale → inLanguage в JSON-LD → язык по дефлоту.
Перед публикацией проверьте:
-
og:locale – сочетание языка и региона, к примеру ru_RU либо en_GB.
-
inLanguage в структурированных данных.
-
Соответствуют ли эти значения друг дружке и настоящей аудитории материала.
-
Не осталась ли в шаблоне локаль иной языковой версии веб-сайта.
-
Не ограничивает ли обозначенная локаль публикацию регионом, на который материал практически не рассчитан.
Ошибки тут могут приметно сказаться на показах. Мы следили ситуации, когда опции локали приметно влияли на географию показов. К примеру, у издателей, которые сузивали локаль до отдельного городка, трафик из Discover резко падал. А при сочетании британского языка с локалью Португалии публикации переставали показываться в остальных странах, а в неких вариантах трафик снижался практически до нуля.
Локаль лучше задавать исходя из фактического языка и географии аудитории, а не пробовать с ее помощью добавочно сузить таргетинг.
Если публикация создана для нескольких рынков, проверьте опции каждой языковой версии странички.
Что может помешать материалу показаться в ленте Discover
До формирования готовой ленты Discover срабатывают четыре уровня фильтрации: три на стороне клиента и один на сервере. 1-ые три определяют, можно ли загрузить и обновить ленту, а 4-ый – какие материалы попадут в нее.

Четыре уровня фильтрации при формировании ленты Гугл Discover
Часть фильтров зависит от опций устройства юзера и внутренних устройств Гугл – издатель не влияет на их. Но характеристики веб-сайта и самой публикации можно надзирать.
Вот несколько советов, которые понизят риск того, что материал отсеется на шагах фильтрации.
Проверьте разметку пэйвола. Опосля открытия статьи Гугл добавочно описывает, доступен ли материал юзеру. Для этого употребляются признаки article:content_tier и isAccessibleForFree. Если контент закрыт, система может исключить карточку из ранжирования. Потому значения в разметке должны соответствовать реальному состоянию странички. Смотрите, чтоб открытый материал по ошибке не был помечен как находящийся за пэйволом.
Учитывайте фильтрацию на уровне домена. Перед окончательным формированием фида работает серверный фильтр. Если домен заблокирован, его публикации могут пройти индексацию и систематизацию, но не попадут в готовую ленту. Потому при резком исчезновении показов проверьте URL и состояние домена в поиске.
Смотрите за доступностью Open Graph Image. Гугл повторно инспектирует изображение уже опосля визита юзера. Если og:image поменялся, Гугл может поменять картину, а если файл стал недоступен – и совсем исключить материал из Discover. Потому опосля публикации не удаляйте начальный файл, не меняйте его URL на несуществующий и не закрывайте доступ к нему.
Технический чек-лист перед публикацией
Перед выпуском материала проверьте главные технические характеристики странички и карточки Discover:
-
Заглавия согласованы. headline в Schema.org, og:title, twitter:title и HTML title не противоречат друг дружке.
-
Основное изображение обозначено в og:image.
-
Ширина изображения – не наименее 1200 пикселей, если нужна карточка с большим превью.
-
Указана директива max-image-preview: large.
-
Изображение доступно Гугл: URL действителен, файл не заблокирован в robots.txt, картина сохраняет свойство опосля сжатия.
-
Язык и локаль указаны корректно. og:locale и inLanguage соответствуют языку странички и региону аудитории.
-
Пэйвол размечен верно. article:content_tier и isAccessibleForFree соответствуют фактическому доступу к публикации.
-
RSS-фид верно указан на страничке, доступен для загрузки и содержит животрепещущие материалы, а favicon веб-сайта корректно загружается.
-
Страничка и ее главные элементы доступны Googlebot и не закрыты от обхода.
Эти опции не гарантируют попадание в Discover, но понижают риск технических ошибок и помогают Гугл корректно обработать публикацию.
|
Техно подготовка – принципиальная, но не единственная часть работы с Discover. В последующем материале разбираем, как отыскивать многообещающие тренды, выбирать момент публикации и получать из ленты больше трафика |