Сгенерировать длинное описание товара или десяток статей стало проще, чем собрать достоверные сведения для них. Владельцу сайта нужно разобраться, где помощь в подготовке текста превращается в выпуск страниц, которые ничего не добавляют покупателю. Google сделал этот вопрос заметнее в своём руководстве для вебмастеров.

1 октября 2026 года в журнале Search Central появилось обновление: руководство по генеративному ИИ-контенту дополнено информацией из рекомендаций асессорам. Google объясняет изменение согласованием документации с презентациями для мероприятий разработчиков. Запись сообщает об уточнении руководства; оснований объявлять её отдельным запуском поискового алгоритма она не даёт.

Как читать обновлённое руководство

Текущая версия документа обращает внимание на массовые страницы без пользы, низкую оригинальность и отсутствие дополнительной ценности. Оценки асессоров служат проверке качества поисковых систем и напрямую не меняют ранжирование. Само руководство признаёт пользу генеративного ИИ для изучения темы и организации исходного материала.

Редакции стоит оценивать готовый материал. Пометки «написан человеком» или «сделан нейросетью» сами по себе не показывают, насколько он полезен. Человек может пересказать чужой материал без полезных дополнений, а инструмент может помочь аккуратно оформить собственные сведения компании.

Отдельно действует политика Google о злоупотреблении массовым контентом. В ней речь о множестве неоригинальных страниц, создаваемых прежде всего для манипулирования поиском, независимо от способа подготовки. Поэтому произвольное число публикаций в неделю нельзя использовать как универсальную границу безопасности. Вопросы цели, содержания и пользы остаются существенными.

Для магазина это удобный повод пересмотреть задания на тексты. Задание из ключевых слов, объёма и требования переписать текст поставщика не объясняет, что должен узнать покупатель. Начинать лучше с его решения: подобрать размер, проверить совместимость, оценить условия применения или понять различия между моделями.

Дополнительная ценность должна быть конкретной

Представим условную карточку крепления для монитора. Исходный текст содержит общие фразы об удобстве рабочего места, а таблица характеристик повторяет название модели. После литературной обработки читать её приятнее, но вопрос покупателя остаётся: подойдёт ли крепление к его столу и экрану?

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

У статьи другая задача. Если она объясняет выбор крепления, читателю нужны критерии и случаи, когда конкретное решение неудобно. Полезны наблюдения компании: какие ограничения обнаруживаются при установке, что стоит измерить заранее, какие вопросы задают покупатели. При отсутствии своего опыта следует прямо опираться на проверенные документы и обозначать границы разбора.

Рекомендуем для каждого материала заранее записать один вопрос читателя и перечень собственных дополнений. Это могут быть фотографии, сравнение по конкретным условиям, уточнение документации или разбор реального обращения с разрешёнными к публикации данными. Важно, чтобы дополнение можно было показать, а не обозначить словом «экспертный».

Если два будущих текста отвечают на один вопрос и отличаются только перестановкой фраз, стоит пересмотреть их назначение. Возможно, полезнее расширить существующую страницу. Такое решение экономит время на проверке и поддержке материалов. Это редакционная рекомендация Digi-Web, а не количественное правило Google о допустимом числе похожих страниц.

Проверка фактов начинается с исходных данных

Google рекомендует проверять автоматически подготовленный контент вручную на точность и надёжность. Для команды сайта предлагаем сделать проверку предметной: не читать весь текст с общим ощущением «вроде правильно», а выделять утверждения, которые читатель может использовать для решения.

В карточке это свойства, размеры, условия эксплуатации, совместимость, наличие и комплектность. В статье о сервисе — доступность функции, ограничения тарифа, дата изменения и действия пользователя. В новости важно разделить анонс, испытание и общедоступный запуск. Если подтверждено только испытание, текст не должен обещать читателю доступную настройку.

Рабочую проверку можно организовать так:

• Отметить все числа, даты, условия и категоричные утверждения.
• Для каждого указать документ, наблюдение или ответ ответственного сотрудника, которым оно подтверждается.
• Проверить соответствие конкретной модели товара или текущей версии сервиса.
• Убрать неподтверждённое утверждение либо явно обозначить, чего пока не удалось установить.

Рассмотрим условную ошибку: в источнике сказано, что адаптер работает с несколькими моделями устройств, а в подготовленном тексте появилось «подходит ко всем». Небольшое изменение делает описание фактически другим. Проверка должна вернуть точные границы совместимости, даже если менее категоричный вариант выглядит менее эффектно.

Назначьте ответственного за спорные сведения. Редактор может улучшить формулировку, а свойства товара должен подтвердить специалист, который с ним работает. Если он ещё не ответил, карточка не становится достоверной от повторного прогона текста через модель.

Проверьте и то, что посетитель не читает в основном тексте

В руководстве Google проверка распространяется также на title, description, структурированные данные и alt изображений. Для разметки требуется учитывать правила соответствующей поисковой функции и проверять её корректность. Это положения текущего документа; называть каждое из них впервые введённым 1 октября без истории изменений было бы неточно.

Проверяйте метаданные вместе с готовой страницей. Заголовок должен описывать именно представленную модель или тему. Анонс не должен обещать функцию, которой в материале нет. Альтернативный текст изображения (alt) нужно сверять с самим снимком, особенно когда похожие фотографии относятся к разным вариантам товара.

Условный пример: текст карточки честно объясняет ограниченную совместимость, а автоматически составленный title всё ещё обещает «универсальный адаптер для всех устройств». Проверка основного описания не устранила ошибку страницы. Аналогично, цена в видимой части может быть обновлена, а подготовленная отдельно разметка оставаться с прежним значением.

Поэтому полезно сравнивать сведения в разных частях страницы. Название модели, цена и условия предложения должны согласовываться там, где они используются. После ручной правки нужно убедиться, что публикация действительно передала её в нужные поля, а не сохранила только в редакторском документе.

Данные Merchant Center проверяются отдельно

Обновлённое руководство отсылает также к правилам для товарных данных Google Merchant Center. Это отдельный предмет проверки: условия передачи фида нельзя автоматически превращать в требования к любой статье на сайте. Дата обновления поискового руководства также не доказывает, что соответствующие правила Merchant Center появились именно в этот день.

В официальной политике Merchant Center об ИИ-контенте для сгенерированных изображений указаны IPTC-метаданные DigitalSourceType со значением TrainedAlgorithmicMedia. Встроенные метаданные нужно сохранять. Для названий и описаний, подготовленных генеративным ИИ, используются атрибуты structured_title и structured_description. В каждом передаются digital_source_type со значением trained_algorithmic_media и content с самим текстом.

Проверьте, как магазин формирует фид и какие поля уходят в Merchant Center. Возможности Google для подготовки товарного контента мы разбирали в обзоре ИИ-инструментов для интернет-магазина. Исправление текста в CMS не гарантирует, что экспорт передал нужный атрибут. Точно так же наличие исходного изображения с метаданными не подтверждает, что они сохранились после обработки файла для сайта.

Рекомендуем взять конкретную карточку, для которой использовалась генерация, и пройти её путь: исходный материал, загруженный файл, опубликованная страница и переданные товарные данные. Проверять следует получившийся результат на каждом нужном этапе, а не наличие галочки в настройках интеграции. Если формат не поддерживается текущим экспортом, это задача для его разработчика, а не повод переименовать поле произвольно.

Для магазина, который не использует Merchant Center, такая проверка фида не возникает автоматически. Его ближайшая задача остаётся на странице: показать достоверные свойства, согласовать основной текст с метаданными и объяснить полезные условия выбора. Для статьи — обозначить подтверждённые сведения и собственный вклад в разбор.

Начните с одной готовой страницы: подтвердите её факты, проверьте метаданные и покажите, какую полезную информацию добавила компания. Если товар передаётся во внешний сервис, сравните с этой страницей и экспортированные данные. Обнаруженные ошибки помогут составить задание для следующих материалов.