UGC в Google: как подготовить форум к Fresh Data Program и сохранить контроль над индексацией
Для форума пользовательский материал не заканчивается в момент публикации. Автор может добавить уточнение, модератор — удалить серийный номер или скрыть комментарий, а поисковая система в это время будет получать одну из предыдущих версий страницы. В результате HTML, структурированные данные и очередь отправки могут описывать разные состояния одного URL.
В октябре Google представил документацию UGC Fresh Data Program и одновременно обновил рекомендации по индексации пользовательских материалов. Перед платформами стоят две связанные задачи: быстро передавать свежие публичные обсуждения и заранее определить, какие страницы действительно должны находиться через поиск.
Что предполагает UGC Fresh Data Program
Fresh Data Program — отдельный канал для передачи свежего популярного пользовательского контента и сигналов взаимодействия одобренным платформам. В опубликованных требованиях упоминаются стабильные URL, доступность материалов для пользователей и Googlebot, публичные профили авторов, активная модерация и возможность пожаловаться на публикацию.
От участников также ожидаются готовность к OAuth 2.0, проверка JSON-LD и поддержка структурированных данных на страницах. Google рекомендует передавать новые публикации в течение нескольких минут, а обновлять показатели взаимодействия — в пределах 72 часов с момента создания материала. Подробная спецификация интеграции предоставляется платформам, которые приняты в программу.
Канал работает отдельно от Indexing API и стандартного обхода страниц. При этом само участие в программе не гарантирует попадание публикации в результаты поиска. Поэтому до подачи заявки форуму важно проверить, может ли он точно восстановить состояние страницы на момент отправки: какой текст видел анонимный посетитель, сколько комментариев было доступно и успела ли модерация изменить публикацию.
Какие пользовательские страницы предназначены для поиска
Наличие URL не означает, что страницу нужно индексировать. Открытая ветка технического обсуждения может быть полезна поисковой аудитории, тогда как автоматически созданный диагностический отчёт иногда предназначен только для передачи в службу поддержки. Если в таком отчёте есть закрытые сведения, доступ к ним должен контролироваться приложением, а не только настройками поисковой индексации.
- Публичное обсуждение с актуальным текстом, автором и видимыми комментариями можно рассматривать для отправки по условиям программы.
- Материал, доступный по ссылке, но исключённый из поиска, может использовать директиву noindex, если это соответствует характеру данных.
- Ограниченные материалы должны проходить проверку прав доступа и не попадать в очередь отправки.
- Снятые публикации нужно обрабатывать по принятой политике удаления, отменяя ещё не отправленные задания.
Директива noindex управляет присутствием страницы в поиске, но не заменяет авторизацию. Google должен иметь возможность прочитать директиву при обходе, а человек с URL всё ещё может открыть публичную страницу. Для конфиденциальных отчётов поэтому необходима отдельная проверка прав на стороне продукта.
Одна версия для HTML, JSON-LD и очереди
Надёжный вариант — строить отправку вокруг неизменяемого снимка публичной версии обсуждения. В нём стоит хранить URL, номер версии, время первой публикации и последнего изменения, ссылку на профиль автора, текст, видимые комментарии и актуальные счётчики. HTML и структурированные данные должны формироваться из этого же снимка, а не из разных источников.
Для обсуждений Google документирует использование разметки DiscussionForumPosting, сведений об авторе, комментариев и показателей взаимодействия. Конкретный тип разметки зависит от назначения страницы и её фактического содержания.
Новую версию и событие для очереди лучше сохранять в одной транзакции. Перед отправкой воркер должен сравнивать версию задания с текущей публичной версией. Если в очереди осталась версия 17, а модератор уже выпустил версию 18, старое задание следует погасить и обработать актуальное состояние. После снятия ветки с публикации отправку нужно отменить.
Для счётчиков взаимодействий полезно использовать отдельные события с номером ревизии и временем наблюдения. Число комментариев может уменьшиться после модерации, поэтому логика «передавать только выросшие значения» приведёт к ошибкам. Итоговое значение нужно рассчитывать по правилам видимости самой площадки и проверять порядок версий.
Как проверить готовность до получения API
До доступа к партнёрской спецификации можно взять небольшую выборку реальных страниц и прогнать их через тот же рендерер и очередь, которые используются в продукте. Для тестов подойдёт локальный получатель, сохраняющий номер версии события и время доставки.
- Правка до отправки. Поставить версию 17 в очередь, опубликовать версию 18 и только затем запустить обработчик. Старое состояние должно быть погашено.
- Снятие публикации. Скрыть ветку между постановкой задания и обработкой, после чего проверить повторную проверку статуса и отмену отправки.
- Модерация комментария. Сопоставить публичный HTML, JSON-LD и счётчик после удаления комментария. Все представления должны описывать одну версию.
- Материал по ссылке. Проверить фактический HTTP-ответ, директиву на конечном URL и отсутствие такой страницы в очереди, даже если пользователи активно ею делятся.
Для диагностики стоит измерять три интервала: от публикации до появления актуального HTML, от публикации до передачи события и от публикации до первого наблюдаемого появления в поиске. Первые два показателя характеризуют работу платформы, а третий зависит также от внешней обработки и методики наблюдения. В отчётах важно хранить размер выборки и учитывать URL, которые не были замечены в поиске, иначе медиана только по найденным страницам исказит результат.
Связь с GEO и генеративным поиском
Google рекомендует публиковать содержательные материалы с собственным опытом и сохранять их техническую доступность для поиска. Форум естественным образом создаёт такой контент, когда участник указывает версию продукта, условия воспроизведения проблемы, наблюдаемый результат и способ проверки. Модератору важно не потерять этот контекст рядом с итоговым выводом, особенно если первоначальный совет позднее был исправлен.
Для оценки видимости веток в ответах генеративного поиска можно завести отдельную панель наблюдений. В ней стоит сохранять формулировку вопроса, дату, язык, регион, режим поиска и URL источника, если он отображается. Отдельно следует отмечать, была ли процитирована актуальная версия совета. Обнаружение ветки и перенос в ответ именно исправленного факта — разные результаты, и ни один из них сам по себе не доказывает влияние Fresh Data Program.
Для первого релиза достаточно выбрать один раздел форума и проверить четыре сценария: правку, снятие публикации, изменение комментариев и обработку материалов по ссылке. Если команда может быстро сопоставить публичную страницу с версией в очереди, отменить устаревшее задание и измерить задержки, у неё уже есть базовая архитектура для дальнейшей интеграции.
