Нутра SEO: от поискового спроса до деплоя

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

Практическая рекомендация для нутры: один рынок → проверенный продукт → подтверждённый спрос → URL-план по SERP → реестр утверждений → структура → текст → семантический аудит → сборка → проверки → деплой → наблюдения. Эту последовательность стоит автоматизировать вокруг явных артефактов и критериев готовности. Она не является формулой Google: это предложенная инженерная система.

Google описывает системы понимания концепций и отдельных фрагментов страницы, но не публикует целевой косинус, публичный вектор документа или алгоритм, позволяющий «подогнать» текст под ранжирование. Косинус собственного эмбеддера — диагностическая метрика вашей модели. [1] [18] [19]

Как читать руководство

Основной сценарий — affiliate-проект о БАДах; рядом разобраны собственный бренд и магазин. Страна и продукт не заданы, поэтому примеры запросов англоязычные, а правовые развилки показаны для США, ЕС, Мексики и России. Это проектирование процесса, без расчёта реального спроса или экспертизы конкретного товара. Проверка источников: 9 сентября 2026 года.

Более старую страницу Google об AI features следует читать вместе с новыми материалами. Например, прежнее описание объединённой отчётности не отменяет появления отдельного отчёта в 2026 году. Дата чтения важнее даты пересказа в SEO-блоге. [4] [52]

Что остаётся устойчивым

Задача страницы, надёжность информации, оригинальная польза и понятное происхождение текста важнее количества повторённых терминов. Для вопросов, влияющих на здоровье, Google уделяет особое внимание качеству и доверию. E-E-A-T — рамка оценки, а не публичный числовой фактор, который можно поднять добавлением подписи врача. [2]

Векторизация — любое превращение текста в набор чисел. Эмбеддинг — обученное представление, где взаимное расположение векторов отражает некоторые отношения между текстами. Разные модели кодируют эти отношения по-разному; математическая близость не равна истинности, медицинской допустимости или одинаковому поисковому намерению. [18] [19]

Двухступенчатый retrieval → rerank описан в Sentence Transformers: быстрый поиск сужает набор, более дорогая модель оценивает пары. BEIR показывает, почему важно сравнивать подходы на разных задачах, а MTEB — почему нет одной лучшей модели для всех типов анализа. [20] [21] [22]

Что именно считает косинус

Это косинус угла между ненулевыми векторами. Общий диапазон — от −1 до 1. Для нормированных векторов скалярное произведение равно косинусной близости. Число 0,87 означает значение в выбранном пространстве, а не «87% SEO-качества» и не вероятность попасть в топ. Для нулевого вектора формула не определена. [19]

Четыре ошибки интерпретации

• «Косинус высокий — объединяем». «Купить магний» и «побочные эффекты магния» близки тематически, но могут ожидать разных типов страниц.
• «Косинус низкий — удалить». Доставка, возврат и раскрытие партнёрства могут быть далеко от медицинской темы и при этом нужны посетителю.
• «Модель от Google повторяет Search». Gemini API — отдельный продукт. Его score не раскрывает внутреннее ранжирование Google.
• «Отрицание проверено сходством». Фразы «доказана эффективность» и «эффективность не доказана» нельзя различать только порогом эмбеддинга.

Далее — предложенная методика. Размеры выборок, число соседей и пороги служат стартовыми параметрами, а не нормативами Google.

Как готовить корпус

1. Сохранить исходный HTML, конечный URL после редиректов, дату и код ответа. Для PDF — файл, страницы и связь с первоисточником.
2. Отделить основной материал от меню, cookie-баннеров и служебных повторов. Таблицы состава и предупреждения сохранить вместе с подписями.
3. Разделить текст по смысловым секциям. Стартовый эксперимент — фрагменты примерно 200–450 токенов с небольшим перекрытием, если оно нужно. Учитывать реальный лимит модели, включая добавленные заголовки.
4. Сохранять в каждом фрагменте URL, язык, рынок, heading_path, тип источника, дату, source_id, claim_id и content_hash.
5. Убрать точные дубли до платного API. Сохранить модель, её ревизию, нормализацию и правила извлечения вместе с векторами.

Эта нарезка нужна собственной системе поиска. Она не требует публиковать на сайте страницы по 300 токенов или абзацы фиксированной длины. Один смысловой раздел может содержать несколько индексируемых фрагментов, оставаясь единым читательским блоком.

Выбор модели

Практический пилот: разметить 150–300 пар запросов и 50–100 пар «вопрос → фрагмент», выделив неоднозначные бренды, различия форм вещества, дозировки, отрицания и медицинские ограничения. Разделить калибровочную и контрольную части. Для объединения страниц измерять precision и число ложных объединений; для поиска источников — Recall@10/20 и качество первых результатов. Выбор «лидера общего MTEB» без такого пилота не завершает оценку. [21]

Порог нельзя переносить между экспериментами

Косинус 0,8 у E5 и у BGE не обязан означать одинаковое отношение текстов. После смены модели, префикса, длины фрагмента или языка пороги калибруются снова. Для спорных пар хранить manual_review, а не принудительное yes/no. Отдельная метка «смысл близок, утверждения противоречат» полезнее попытки зашить медицинскую достоверность в один score.

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

1. 0. Продукт и рынокКому продаём, от чьего имени, какие документы есть
2. 1. Сбор ключейБренд, категория, конкуренты, реальные формулировки
3. 2. Проверка SERPСпрос, сущность, интент, ожидаемый тип страницы
4. 3. URL-планПредкластеры → пересечение выдачи → merge / keep
5. 4. Реестр доказательствУтверждение → источник → границы → проверяющий
6. 5. План страницыВопросы, необходимые блоки, собственная польза
7. 6. Текст и метаЧерновик по фактам → экспертиза → редактура
8. 7. Семантический QAПолнота ответа, дубли, ссылки и точные термины
9. 8. Сборка сайтаКонтентная модель, шаблоны, schema, доступность
10. 9. Проверка и деплойPreview → выпуск → smoke test → GSC
11. 10. НаблюдениеИндексация → запросы → конверсии → итерация

Почему именно такой порядок

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

Первый выпуск — ограниченная партия действительно готовых страниц, например 5–12 материалов одного продуктового направления. Это рекомендация по управлению качеством, а не SEO-минимум. Если фактов хватает только на три полезных URL, выпускать три. Служебные страницы и документы добавлять по реальной необходимости.

До парсинга ключей нужно определить, какой товар существует в выбранной стране и кто отвечает за его продажу. «Нутра» — коммерческое обозначение вертикали, а не единая юридическая категория. БАД, косметическое средство и зарегистрированный препарат могут требовать разных правил, даже если CPA-сеть объединяет их в одном каталоге.

Развилка: три типа сайта

Для affiliate самостоятельная ценность — метод сравнения, проверка состава и документов, ограничения доказательств и условия покупки. Google рекомендует подкреплять обзоры собственным опытом и оригинальными измерениями. Это не разрешает выдавать впечатления от приёма БАДа за клиническое испытание. [7]

Критерий готовности: продукт однозначно идентифицирован, рынок выбран, роль сайта описана честно; неподтверждённые сведения помечены как отсутствующие. Не заполнять пробелы догадками. Цена, количество капсул и «официальность» — тоже проверяемые утверждения.

Собирать запросы нужно вокруг покупателя и товара, а не только вокруг одного названия. Источники дают разные виды наблюдений: keyword database оценивает спрос, Search Console показывает видимость существующего сайта, текущая SERP — состав выдачи в конкретный момент. Эти данные не заменяют друг друга. [28] [29] [32]

Последовательность сбора

1. Зафиксировать GEO, язык, устройство, дату и исходные seeds. Не присваивать спрос одного рынка другому.
2. Выгрузить suggestions / related keywords, затем ранжируемые запросы 3–5 релевантных доменов. Домены отобрать по совпадению рынка и бизнес-модели.
3. Добавить вопросы и уточнения из SERP, customer support и GSC при наличии. Сохранить источник каждой строки.
4. Отделить бренд от омонимов. Частотность по совпавшему слову не доказывает спрос на ваш товар.
5. Нормализовать пробелы и очевидный технический мусор. Хранить исходное написание, диакритику, дозировку, отрицания и формы вещества. Не сливать glycine и glycinate по похожим буквам.
6. Дедуплицировать по запросу + GEO + языку + источнику измерения. Не суммировать повторные оценки одного спроса.
7. Поставить предварительные метки интента, риска, сущности и коммерческой близости. Это маршрутизация анализа, ещё не URL-план.

Нулевая частотность не означает отсутствия пользователей. Это может быть длинный хвост или ограничение источника. При этом нельзя обещать трафик на основании одного правдоподобного запроса. Если спрос бренда не подтверждается, возможен другой проект — категория или образовательная библиотека, но это отдельная бизнес-гипотеза.

Минимальная схема keywords.csv

keyword_raw,keyword_normalized,geo,language,source,observed_at,volume,volume_period,entity_id,intent_candidate,risk,serp_status
"[brand] reviews","[brand] reviews",US,en,demo,2026-09-09,,unknown,product_demo,commercial,medium,not_fetched

Объём и сложность. CPC и competition в рекламных данных не являются сложностью органического SEO. Оценки keyword difficulty разных сервисов тоже различаются. В приоритете проверить фактических конкурентов, формат результатов и способность дать собственный полезный ответ. Не строить бюджет на сложении частотностей близких вариаций.

Что уже можно использовать из локального набора

dfs-product-keywords содержит режимы verify → product → plan и скрипт анализа пересечения URL. Следующий фрагмент — шаблон последовательности, не выполненный сбор данных. Значения продукта и страны нужно заменить до запуска; живые запросы расходуют API-баланс.

python3 ~/.codex/skills/dfs-product-keywords/tools/product_keywords.py verify "REAL_PRODUCT" --niche nutra --geo US
python3 ~/.codex/skills/dfs-product-keywords/tools/product_keywords.py product "REAL_PRODUCT" --niche nutra --geo US --out work/keywords
python3 ~/.codex/skills/dfs-product-keywords/tools/product_keywords.py plan "REAL_PRODUCT" --niche nutra --geo US --out work/keywords --serp-per-bucket 5 --top 10 --overlap 0.30 --min-shared 3

Выход этапа: raw-выгрузки, очищенное ядро, список исключений с причинами, журнал стоимости и список запросов на проверку SERP. Сохранять неизвестную частотность как null, а не как придуманное число.

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

Протокол SERP-снимка

Для представителя каждой группы и спорных модификаторов сохранить первые 10 органических URL, позиции, title, видимый snippet, тип результата, язык, страну, устройство и время. Отдельно зафиксировать shopping, видео, форумы, PAA и AI-блоки. Платную рекламу не подмешивать в органическое пересечение. DataForSEO позволяет получать SERP с заданной поисковой системой и локацией; сырой ответ стоит хранить для воспроизводимости. [29]

Что извлекать со страниц конкурентов

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

Для небольшого исследования достаточно targeted scrape нескольких сильных и нескольких характерных результатов. Firecrawl предлагает map для поиска URL и scrape/crawl для извлечения; начинать с ограниченного объёма и сохранять оригинальный URL рядом с очищенным текстом. [30]

Выход этапа: snapshots JSON + таблица «запрос → тип страницы → основная задача → конкуренты → неопределённость». Снимок показывает выдачу в конкретное время; он не доказывает причин ранжирования.

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

В существующем dfs-product-keywords начальная эвристика: минимум три общих органических URL и overlap ≥ 0,30 при анализе top-10. Это не Jaccard: у Jaccard в знаменателе объединение множеств. Порог 0,30 — параметр конкретного инструмента, не универсальное определение интента. При неполной выдаче уверенность снижается даже тогда, когда формальный порог проходит.

Один числовой пример

Синтетические данные В двух полных top-10 найдено четыре общих URL. Overlap = 4/10 = 0,40; Jaccard = 4/(10+10−4) = 0,25. Метрики описывают одну пару, но числа различны — всегда фиксировать формулу.

Все значения в таблице придуманы для объяснения; реальная модель и live SERP здесь не запускались. Таблица демонстрирует конфликт сигналов, а не пороги для внедрения.

Защита от «моста»

Если A пересекается с B, а B с C, это ещё не значит, что A и C требуют одного URL. Связные компоненты графа могут разрастись в смешанный кластер. Существующий скрипт помечает компонент с непрошедшими парами как manual-review. Для финального merge проверять все необходимые пары, тип страницы, достаточность SERP и человеческую задачу.

Правило одного главного URL

Каждому подтверждённому кластеру назначить основной URL, формат, цель, обязательные факты, родительский раздел и ссылки. Несколько модификаторов одного запроса могут жить секциями на странице продукта. Новый slug появляется, когда есть отдельная задача и достаточно самостоятельного содержания, а не потому, что regex выделил слово reviews.

cluster_id: brand_purchase_us
primary_job: "Проверить продукт и условия покупки"
primary_url: /reviews/demo-product/
site_model: affiliate
serp_evidence: required_before_release
decision: manual_review
required_facts: [label, seller_identity, price_date, disclosure]
merge_candidates: [brand_price, brand_buy]
separate_candidates: [ingredient_guide]
reason: "Демонстрационный контракт; реальная выдача ещё не проверена"

Каннибализация — практический диагноз конкуренции страниц за одну задачу, а не сам факт сходства. Проверять его после запуска по запросам, выбираемым Google URL, сменам посадочной и полезности каждой страницы. Полезная страница о составе и страница о доставке могут пересекаться словами без проблемы.

Для нутры нужен отдельный слой между найденными источниками и текстом. Его единица — утверждение: что именно говорится, о каком веществе или продукте, для какой группы людей, в каких условиях и на каком основании. Ссылка на PubMed сама по себе этого не решает.

Разделить четыре разных вида фактов

FTC требует учитывать прямые и подразумеваемые рекламные сообщения и обеспечивать научное обоснование claims. Перенос результата на другой продукт, выбор только удобного исследования или обещание через отзыв могут исказить доказательства. Дисклеймер не исправляет обманчивое основное сообщение. [39]

Как собирать evidence ledger

1. Начать с официальной этикетки и документов продукта. Зафиксировать версию, страну, партию и производителя.
2. Для медицинского контекста искать официальные справочники, клинические рекомендации, систематические обзоры и затем первичные исследования. Справочник NIH ODS по магнию — пример стартового ориентира с ссылками на литературу, а не одобрение выбранного БАДа. [42]
3. Из исследования извлечь population, intervention, comparator, outcomes, дозу, форму, длительность, размер выборки, финансирование, ограничения и дату.
4. Проверить, соответствует ли планируемая фраза реально измеренному исходу. Изменение лабораторного показателя не автоматически означает доказанную пользу для самочувствия или риска болезни.
5. Проверить отсутствие отзыва/исправления статьи, актуальность и противоречащие данные. Отсутствие найденных испытаний описывать с датой и границами поиска, а не абсолютным «исследований нет».
6. Отдельно вынести применимость к продукту и разрешённость коммерческого использования в выбранной юрисдикции. Научная достоверность и допустимость рекламы — две разные проверки.
7. Присвоить статус approved / qualified / unsupported / rejected и сохранить точную разрешённую формулировку.

claim_id: CLM-014
claim_text: "В порции указано 100 мг элементарного магния"
entity: DEMO_PRODUCT
claim_type: label_fact
source_id: LABEL-2026-01
source_locator: "Supplement Facts, serving size"
product_version: demo
market: US
evidence_applicability: exact_product_label
scientific_review: not_applicable_to_label_transcription
regulatory_review: pending
status: draft
allowed_wording: null
reviewed_by: null
expires_on: null
# Учебная запись. Не содержит подтверждённых фактов о реальном товаре.

RAG как помощник проверяющего

Извлекать источники лучше гибридно: буквальный поиск ловит точное название, дозу и форму; dense retrieval находит смысловые кандидаты; reranker уточняет порядок. После этого человек читает оригинал и проверяет достаточность доказательства. Цитату нельзя автоматически считать подтверждением только потому, что она близка к вопросу. [20] [22]

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

Ниже — карта предварительной проверки, а не юридическое заключение о конкретном товаре. Перед выпуском профильный специалист сверяет категорию продукта, формулировки, рекламный формат и текущие местные требования. Английский текст не означает рынок США, а испанский — единый набор правил для всех стран.

Библиотека запрещённых и условных формулировок

Таблица выше — предложенные редакционные фильтры на основе различий между обоснованными и вводящими в заблуждение claims. Финальный статус конкретной фразы зависит от контекста и страны. В российской рекламе даже добросовестная ссылка на исследование требует отдельной проверки способа подачи. [38] [39] [44]

Affiliate-особенности

Раскрывать коммерческую связь рядом с рекомендацией и переходом. Не писать «официальный сайт», если проект не имеет такого статуса. Видимое объяснение партнёрства и технический атрибут rel="sponsored" решают разные задачи: первое информирует человека, второе квалифицирует ссылку для Google. Рекомендации FTC об endorsement относятся к соответствующему рынку; Google описывает sponsored отдельно. [15] [50]

Здесь подходит уже существующий gist-page-plan: одна работа страницы, обязательное ядро, сравнение с выдачей, удаление повторов и тест заменяемости. GIST используется как редакторская модель полезности и разнообразия информации. Он не объявляется механизмом Google.

Бриф, который можно передать автору

Пример структуры независимого обзора

1. Краткое заключение. Что проверено, главные ограничения и тип читателя, которому полезен обзор.
2. Что это за продукт. Точная версия, производитель, форма, упаковка; собственное фото или корректно обозначенный официальный материал.
3. Состав и количество на порцию. Таблица с единицами; различить массу соединения и активного компонента, где это применимо.
4. Что известно о заявленных эффектах. Отдельно данные по ингредиенту и по готовому продукту, качество и ограничения.
5. Безопасность и ограничения. Предупреждения этикетки и проверенный медицинский контекст без персональных схем лечения.
6. Цена и условия. Дата проверки, стоимость порции, доставка, подписка, возврат, кто продавец.
7. Альтернативы. Сравнение по заранее объявленным критериям, с честным отсутствием данных.
8. Методика и источники. Кто собирал и проверял материал, что реально тестировалось, коммерческая связь.

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

Тест заменяемости

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

Рекомендации Google по обзорам поддерживают ориентацию на выбор, собственные данные, сравнение и ограничения. Они не задают универсальную длину статьи или обязательный список H2. [7]

LLM получает структуру, разрешённые факты, список источников и явные неизвестные. Сначала создаёт черновик, затем извлекает из него утверждения для проверки. Самопроверка модели полезна как предварительный фильтр, но не заменяет профильного редактора в содержательных вопросах здоровья.

Подготовь черновик по page-brief и approved-claims.
Сохрани одну работу страницы и заданный тип материала.
Каждое медицинское или продуктово-специфичное утверждение свяжи с claim_id.
Не переноси доказательства ингредиента на готовый продукт.
Не выдумывай цену, отзывы, автора, сертификат, исследование или опыт тестирования.
Если факта нет, добавь его в missing_facts; не заполняй предположением.
Не усиливай степень уверенности исходного источника.
Выход: draft + claim_map + missing_facts + вопросы проверяющему.

Четыре прохода редактуры

1. Предметный: сущности, форма вещества, единицы, точность цитирования, границы исследования.
2. Регуляторный: прямые и подразумеваемые claims, CTA, meta, иллюстрации, отзывы, дисклеймеры выбранного рынка.
3. Поисковый: отвечает ли страница запросу и ожидаемому формату; нет ли конфликтов с другими URL.
4. Языковой: убрать воду, двусмысленность, повторение, навязанные ключи. Локальная редактура нужна после перевода; машинный перевод не подтверждает соответствие рынку.

Пример до / после

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

Title, H1 и description

gist-meta следует запускать после фактов и структуры. Title — точное описание задачи и отличительного факта, H1 — понятное название страницы, description — дополнительная информация для решения о клике. Google может сформировать заголовок и сниппет из других частей страницы; фиксированная длина в символах не гарантирует отображение. [8] [9]

Не заставлять title содержать все модификаторы. Не писать «официальный» для affiliate. Не прятать неподтверждённое медицинское обещание в description: это тоже видимая коммерческая формулировка. Пиксельный preview и длина — проверки удобства отображения, а не медицинской или поисковой корректности.

Выход этапа: утверждённый текст, claim_map, meta-map, список иллюстраций с происхождением, подписи реальных авторов и даты настоящего пересмотра. Менять дату автоматически при каждой сборке не нужно.

Теперь у эмбеддингов есть конкретная работа: найти места, которые стоит прочитать внимательнее. Не нужен общий «SEO cosine score». Нужны несколько независимых отчётов с объяснимыми причинами и ссылкой на проблемный фрагмент.

Матрица покрытия вместо гонки за терминами

Пример Статусы в таблице иллюстрируют аудит вымышленного черновика. Coverage можно считать как долю подтверждённо закрытых обязательных вопросов с редакционными весами. Но safety-вопросы и фактические ошибки должны быть отдельными блокерами: высокий средний процент не компенсирует опасный пробел.

Техническая схема анализа

1. Extract main content, preserve tables and warnings.
2. Split into semantic sections; attach URL and heading_path.
3. Encode questions and sections with one pinned model.
4. Retrieve top-k candidate sections per question.
5. Re-rank candidates if the corpus is large enough to justify it.
6. Verify answer sufficiency and source support.
7. Export findings: question_id, section_id, issue, evidence, action.
8. Re-run only on changed content hashes.

Screaming Frog уже умеет находить семантически похожие страницы и тематические выбросы через embeddings. Это удобный готовый интерфейс для аудита, но «выброс» не является рекомендацией удалить страницу. Юридическая информация, возврат или контактная страница могут быть необходимы независимо от близости к основному корпусу. [26]

Полностью учебный сценарий Независимый англоязычный affiliate-проект исследует вымышленный Demo Magnesium для США. Никакие частотности, позиции, состав и продажи не выдаются за реальные. Пример показывает документы и решения, которые потребуются на настоящем товаре.

Предварительная карта страниц

/reviews/demo-magnesium/          # основной обзор, если подтверждён SERP
/guides/magnesium-forms/           # отдельная образовательная задача
/compare/demo-vs-alternative/      # только при спросе и достаточных данных
/methodology/                     # реальные методы сравнения
/editorial-policy/                # ответственность и правила пересмотра
/affiliate-disclosure/            # коммерческая связь
/about/                          # реальная организация / редакция
/contact/                        # работающий канал связи
/privacy/                        # фактическая обработка данных

Не добавлять автоматически /reviews/, /side-effects/, /buy/ и /price/ к одному продукту только ради расширения. Если один обзор качественно закрывает эти модификаторы и выдача сходится, оставить один URL с якорями. Сравнение не выпускать, пока нет проверенных данных об альтернативе.

Пример собственной полезности: стоимость порции

Формула: цена упаковки / число порций по этикетке. Для сравнения учитывать валюту, дату, размер порции, количество вещества, условия подписки и доставку. Нельзя сравнивать цену капсулы с ценой порции или считать меньшую цену доказательством лучшего медицинского результата. Реальные числа подставляются только после проверки.

Справочник NIH ODS подходит для поиска исходных медицинских источников о магнии, его формах и ограничениях. Он не подтверждает состав Demo Magnesium или пользу этого вымышленного товара. [42]

Skill задаёт порядок действий и проверки. Скрипт выполняет повторяемую операцию. MCP даёт агенту доступ к инструментам сервиса. Плагин Codex может упаковать skills и подключения. WordPress-плагин работает внутри CMS. Наличие skill с названием сервиса не означает, что подключён API и доступны данные аккаунта.

Минимальный рабочий стек

Готовые SEO-редакторы: когда покупать

Не покупать одновременно несколько редакторов ради четырёх похожих баллов. Для небольшого проекта сначала закрыть доступ к SERP, продуктовым документам и качественной проверке текста. Тарифы и лимиты зависят от плана и меняются; без конкретного объёма работ точная «цена SEO-стека» будет ложной точностью.

Если сайт на WordPress

Выбрать один основной SEO-плагин и проверить реальный вывод HTML. Yoast документирует title, description, canonical, robots, sitemap и schema. У Rank Math есть управление sitemap; конкретные расширенные функции сверять по текущему плану. Не запускать два конкурирующих генератора мета и schema одновременно. Плагин не заменяет реестр claims и медицинский review. [46] [47]

Что уже доступно в этой среде

Web search, создание локальных файлов, браузерные инструменты и Sites присутствуют. В рекомендованном каталоге есть неустановленные GitHub и Cloudflare, а также исследовательские Consensus и SciSpace. Их наличие в каталоге не подтверждает подключение аккаунта или доступ к полным текстам исследований. Для текущего исследования установка не требовалась.

В доступных инструментах управления плагинами не обнаружены функции поиска общего каталога. Поэтому внешние интеграции выше проверены по официальным сайтам и репозиториям, а не представлены как установленные плагины. Конкретный marketplace ID для DataForSEO или Firecrawl здесь не предполагается.

Как оценивать внешнюю интеграцию

Проверить владельца репозитория, назначение каждого разрешения, поддерживаемый транспорт, журнал изменений, лимиты и способ хранения credentials. Для конвейера зафиксировать версию пакета; не выполнять непроверенный install-скрипт из случайной подборки skills. Настройка должна проходить отдельный read-only smoke test до массовой работы.

В рабочем наборе уже есть большая часть нужного процесса. Исследование файлов подтвердило реализацию dfs-product-keywords и разделение GIST на структуру, мета и постпубликационный анализ. Полный повторный «мегаскилл для нутры» создаст дублирование; полезнее добавить недостающие узкие звенья.

Что нашлось при чтении файлов

Эти изменения предложены по результатам чтения; установленные skills в рамках исследования не изменялись. Репозиторий AgriciDaniel/codex-seo существует и подходит как источник обновлений, но свежая версия набора всё равно должна проходить проверку по текущей документации Google. Популярность skill не подтверждает его SEO-гипотезы. [45]

Три узких skill, которых не хватает

Оркестрацию держать в коротком runbook: какие входы обязательны, куда записывается результат и кто принимает спорное решение. Для официального бренда дополнительно нужен профиль first-party copy внутри редакторского шага или отдельный маленький skill; он не должен одновременно собирать ключи, оценивать исследования и деплоить сайт.

Для небольшого affiliate-проекта или информационного сайта бренда предлагается Astro со статической генерацией: контент хранится как структурированные записи, страницы собираются из проверенных шаблонов. Astro content collections поддерживают схемы и валидацию. Выбор сделан ради простоты сопровождения и контроля контента; сам фреймворк не даёт бонуса Google. [33]

Одна модель данных для текста и шаблонов

project/
  data/
    product.json                 # проверенные факты товара
    evidence.jsonl               # источники и применимость
    claims.jsonl                 # разрешённые формулировки
    url-plan.json                # кластеры, страницы, причины
    links.json                  # утверждённые внутренние связи
  content/
    reviews/product.md
    guides/ingredient.md
  src/
    layouts/
    components/ProductFacts.astro
    components/EvidenceTable.astro
    components/Disclosure.astro
  public/
    robots.txt
    images/
  tools/
    validate_claims.py
    validate_routes.py
    smoke_urls.py
  releases/
    release-manifest.json

Не дублировать цену вручную в тексте, JSON-LD и таблице. Выводить её из одного проверенного источника с датой актуальности. То же касается названия, состава, порций и статуса наличия. В сборке запрещать попадание draft/unsupported claims на публичные страницы.

Компоненты, полезные именно для нутры

• ProductFacts: единицы, форма вещества, размер порции, происхождение информации и дата.
• EvidenceTable: объект исследования, вывод, ограничения и применимость к продукту.
• SafetySection: подтверждённые предупреждения и условия обращения за индивидуальной консультацией.
• PriceBreakdown: цена порции и прозрачные условия сделки без скрытой подписки.
• ReviewMethod: что реально проверялось и кем; документы и фото имеют происхождение.
• Disclosure: статус редакции, продавца и партнёрских ссылок.

Google умеет обрабатывать JavaScript. SSG предлагается здесь как инженерный выбор для предсказуемого HTML и скорости, а не как утверждение, что Google «не видит JS». При любом рендеринге проверить фактический HTML и доступность важных данных. [14]

Разметка по реальному содержанию

Для страницы продажи рассмотреть Product/Offer и merchant listings при выполнении условий; для редакционного обзора — подходящую Product/Review-разметку и product snippets. Данные должны соответствовать видимой странице; доступность rich result не гарантируется. Не выдумывать рейтинг, автора или наличие товара. [10] [51]

FAQ можно оставить как удобный раздел вопросов, но не обещать FAQ-сниппет. Article, BreadcrumbList и Organization применять только там, где они описывают реальные сущности и соответствуют текущей документации. Schema.org-валидность и поддержка поисковой функции Google — разные проверки.

Core Web Vitals

Это границы категории good; оценивать на 75-м перцентиле полевых данных и учитывать мобильный/desktop опыт. Один запуск Lighthouse не измеряет реальный INP всей аудитории и не доказывает прохождение CWV. Для нового сайта использовать лабораторные проверки и затем дополнять их полевыми наблюдениями. [17]

Не объединять всё в средний «SEO Health 93». Отдельный noindex или неверный состав блокирует выпуск независимо от других баллов. Рекомендованные статусы проверки: pass, fail, unknown, not_applicable. Unknown нельзя автоматически превращать в pass.

Деплой — не последняя команда сборки, а переход проверенной версии в публичную среду. Для предложенного статического Astro-проекта Cloudflare Pages документирует build command и output directory; обычно используются npm run build и dist. Конкретные значения сверить с репозиторием. Если понадобился SSR, выбрать поддерживаемый адаптер и заново проверить окружение. [34]

1. Создать preview конкретного commit

   Сборка из lockfile, валидаторы данных, ссылки и schema. Preview защищён доступом; noindex — дополнительный сигнал, а не защита конфиденциальности. Не публиковать тестовые claims в открытой индексируемой среде.

2. Проверить контент и пользовательский путь

   Все предназначенные к выпуску страницы проходят claim-check. На мобильном и desktop проверить таблицы, CTA, ошибки формы, обратную связь, переход к продавцу и страницу благодарности. Сохранять результаты как часть manifest.

3. Настроить production-конфигурацию

   Домен, DNS, HTTPS, site URL, redirects, секреты только в server/build environment. Сверить отсутствие preview-домена в canonical, sitemap и ссылках. Ключи API не включать в браузерный bundle.

4. Выпустить проверенную версию

   Записать commit, deployment_id, список URL, версии контента, ответственных и предыдущий рабочий release для отката. Для выпуска реального сайта с неподтверждёнными фактами требуется завершить проверки, а не просто дождаться зелёной сборки.

5. Проверить публичный домен

   Повторить HTTP, robots, canonical, sitemap, schema, медиа и формы на production. CDN и переменные окружения могут изменить поведение по сравнению с preview. Реальная проверка заказа — в согласованном тестовом режиме.

6. Настроить наблюдения

   Подтвердить право на сайт в GSC, отправить sitemap, проверить важные URL через URL Inspection и зафиксировать baseline. Запрос переобхода не гарантирует срок или факт индексирования.

Indexing API не является универсальным ускорителем нутра-сайтов. Документация ограничивает его применимость страницами с JobPosting или BroadcastEvent, вложенным в VideoObject. Для обычных статей и продуктов использовать подходящие механизмы обнаружения и проверки. [16]

{
  "release_id": "demo-2026-09-09",
  "commit": "REQUIRED_REAL_COMMIT",
  "environment": "production",
  "checks": {
    "claims": "pending",
    "content_review": "pending",
    "routes": "pending",
    "canonical_sitemap": "pending",
    "forms": "pending",
    "production_smoke": "pending"
  },
  "rollback_deployment": null,
  "released_at": null
}

После технического сбоя можно вернуть предыдущую версию, восстановить домен и повторить smoke test. При ошибке в утверждениях сначала снять или исправить неверный материал и проверить, нет ли его в мета, JSON-LD и других страницах. Откат к версии с той же ошибкой проблему не решит.

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

Search Analytics API имеет ограничения выдачи строк и не гарантирует возврат абсолютно всех данных; агрегаты и детализации могут не совпадать. Отдельный AI-отчёт описывает другой набор измерений. Наличие функции в UI не означает, что те же поля уже есть в используемой версии API. [32] [4]

Расписание первого цикла

• День выпуска: production smoke, аналитика, ссылки, sitemap, baseline.
• Через 3–7 дней: доступность, обход, технические ошибки. Не делать вывод о качестве темы из раннего отсутствия трафика.
• Через 2–4 недели: изучить реальные запросы и выбранные URL, если накопились данные. Срок — контрольная точка, не обещание индексации.
• Через 6–8 недель: сопоставить страницы и кластеры с достаточным объёмом наблюдений; проверить конверсии и коммерческие ограничения.
• Затем ежемесячно: пересмотр доказательств по триггерам, свежесть продукта и итерации по значимым данным.

Диагностика вместо переписывания всего сайта

Менять один крупный класс факторов за раз и вести журнал: гипотеза, версия, дата, затронутые страницы, ожидаемая метрика, окно наблюдения. По возможности сравнивать с похожими неизменёнными страницами и учитывать сезонность, ассортимент, изменения SERP и обновления Google. Простое before/after не устанавливает причинность.

Основная экономия возникает от переиспользования данных и ясных решений. Для маленького сайта собственная векторная база и сложная оркестрация могут стоить больше, чем ручная проверка десятка страниц. Сначала измерить, какая операция действительно повторяется.

Что считать в бюджете

Токены и тариф embedding API должны быть в согласованных единицах: например, цена за миллион токенов требует деления T на миллион. Дополнительно учесть подписки, хранение, извлечение PDF, повторные запросы, изображения, локализацию и сопровождение. Внутренний журнал стоимости должен сохранять услугу, endpoint, объём и фактическую сумму.

Сценарий нагрузки 2 000 исходных ключей после очистки дают 800 уникальных; из них 120 выбираются для первичного SERP-снимка и ещё 30 — для спорных пар. Итого планируется 150 снимков, а не 2 000 по умолчанию. Затем 40–60 страниц конкурентов идут на targeted scrape. Эти числа иллюстративны: выборка может пропустить интенты, поэтому случайный аудит оставшихся групп обязателен.

Оптимизация расходов

1. Кэшировать SERP по запросу, стране, языку, устройству и дате. Обновлять по необходимости, не бесконечно пользоваться старой выдачей.
2. Векторизовать только изменённый текст по content_hash + model_revision + preprocessing_version.
3. Сначала удалять точные дубли, затем считать семантику.
4. Использовать bi-encoder для кандидатов; reranker применять к ограниченному набору.
5. Не отправлять целый сайт в LLM для исправления двух мета-тегов.
6. Не экономить на проверке клинических утверждений за счёт лишних автоматических проходов.

Роли и ответственность

Один человек может совмещать роли, но названия ролей не создают квалификацию. Агент не должен подписывать материал именем эксперта, которого нет, или отмечать «medical approved» после собственной генеративной проверки.

Когда нужна векторная база

Для первых сотен страниц достаточно файлов с метаданными и матрицы векторов. При большом корпусе, частых обновлениях и фильтрации по рынку/продукту можно перейти к Postgres + pgvector. Он поддерживает точный и приближённый поиск; при ANN нужно проверять потерю recall. Выбор инфраструктуры следует нагрузке, а не стремлению иметь «векторный SEO-стек».

Что делать с патентами, утечками и корреляциями

Патент показывает возможный технический подход, но не доказывает его использование в текущем поиске. Утечка названия поля не раскрывает его вес, контекст и применимость. Корреляция между термином и позициями может отражать тему, бренд, ссылки или формат выдачи. Такие материалы годятся для постановки проверяемых гипотез, но не для блокирующих требований к нутра-тексту.

Центроиды и тепловые карты: полезны с оговорками

Можно усреднить нормированные векторы документов кластера, затем снова нормировать центроид и сравнить с ним собственные секции. Это поможет увидеть тематические отклонения. Но центроид может смешать разные интенты, унаследовать шаблонный шум или «сгладить» важные исключения. Анализ секций и отдельных вопросов обычно объяснимее единственного расстояния страницы до среднего топа.

Визуальная проекция UMAP/t-SNE тоже не заменяет расстояния исходного пространства: два узла рядом на картинке не обязательно требуют merge. Для окончательного решения возвращаться к текстам, SERP-снимкам и задаче читателя.

Что остаётся неизвестным

Точные веса ранжирования Google, причинный эффект выбранного эмбеддера на SEO, спрос конкретного бренда и допустимость конкретного товара без документов здесь не установлены. Это не пробел, который надо заполнить уверенным тоном. Для первых двух — нужны ограниченные гипотезы и наблюдения; для последних двух — реальные данные продукта и рынка.

Отметки сохраняются только в текущем браузере, если доступен localStorage. Это личный чек-лист для будущего проекта; отметка не запускает API и не означает, что реальный сайт уже проверен.

Команда агенту для следующего реального проекта

Построй нутра-процесс для продукта [название], страны [GEO], языка [язык].
Модель сайта: [affiliate / бренд / магазин].
Начни с паспорта продукта и списка недостающих фактов.
Используй dfs-product-keywords для verify, сбора ключей и URL-плана по live SERP.
Не назначай страницы по regex-бакетам или одному cosine score.
До написания текста подготовь evidence ledger и список разрешённых claims.
Структуру делай через gist-page-plan, мета через gist-meta.
Текст проверяй по фактам, рынку и задаче; эмбеддинги используй для аудита.
Собери preview с воспроизводимыми данными, проведи QA, подготовь release manifest.
Для каждого шага сохраняй вход, выход, стоимость и причину спорного решения.
Неподтверждённые сведения оставляй неизвестными.
Публикацию и последующие действия выполняй в рамках согласованного доступа.

Первое улучшение системы

Приоритет — nutra-evidence с машинно проверяемым реестром claims. Затем точечное обновление устаревших SEO-правил и отдельный semantic-content-audit. Именно эти элементы закрывают промежуток между уже существующими skills для ключей и текста. Конвейер деплоя стоит добавлять после первого проверенного продукта и шаблона.

Официальные материалы Google используются для описания Search и инструментов Google; публикации исследователей — для свойств retrieval и эмбеддингов; регуляторы — для карты проверок нутра-утверждений. Документация поставщика подтверждает наличие функций, но не независимый эффект на SEO. КонсультантПлюс используется как доступный текст российского закона, а не как первичный сайт регулятора.

Рабочие схемы, пороги выборки, контентные контракты и последовательность выпуска — авторские рекомендации на основе этих источников. Здесь не проводилось исследование реальной SERP конкретного продукта, платный keyword research, клиническая экспертиза товара или измерение роста позиции.

Для правил 2026 года приоритет отдан новым датированным публикациям перед старыми справочными страницами. Проверка всех внешних материалов: 09.09.2026. Дата версии не указывается там, где она не была надёжно зафиксирована.

1. 01
   A guide to Google Search ranking systems

   Google · Документация

   Дата версии не зафиксирована; проверено 09.09.2026

2. 02
   Creating helpful, reliable, people-first content

   Google · Документация

   Дата версии не зафиксирована; проверено 09.09.2026

3. 03
   Optimizing your website for generative AI features on Google Search

   Google · Документация

   Обновлено 10.07.2026; проверено 09.09.2026

4. 04
   Introducing Search Generative AI performance reports in Search Console

   Google · Обновление продукта

   03.06.2026; примечание о глобальном запуске — 31.08.2026

5. 05
   Latest Google Search documentation updates

   Google · Журнал изменений

   Записи за март–август 2026; проверено 09.09.2026

6. 06
   Spam policies for Google web search

   Google · Документация

   Дата версии не зафиксирована; проверено 09.09.2026

7. 07
   Write high quality reviews

   Google · Документация

   Обновлено 10.12.2025; проверено 09.09.2026

8. 08
   Influencing your title links in search results

   Google · Документация

   Дата версии не зафиксирована; проверено 09.09.2026

9. 09
   Control your snippets in search results

   Google · Документация

   Дата версии не зафиксирована; проверено 09.09.2026

10. 10
    Introduction to Product structured data

    Google · Документация

    Дата версии не зафиксирована; проверено 09.09.2026

11. 11
    How to specify a canonical URL

    Google · Документация

    Дата версии не зафиксирована; проверено 09.09.2026

12. 12
    Build and submit a sitemap

    Google · Документация

    Дата версии не зафиксирована; проверено 09.09.2026

13. 13
    Introduction to robots.txt

    Google · Документация

    Дата версии не зафиксирована; проверено 09.09.2026

14. 14
    Understand JavaScript SEO basics

    Google · Документация

    Дата версии не зафиксирована; проверено 09.09.2026

15. 15
    Qualify your outbound links to Google

    Google · Документация

    Дата версии не зафиксирована; проверено 09.09.2026

16. 16
    How to use the Indexing API

    Google · Документация

    Дата версии не зафиксирована; проверено 09.09.2026

17. 17
    Web Vitals

    Google / web.dev · Документация

    Дата версии не зафиксирована; проверено 09.09.2026

18. 18
    Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks

    Nils Reimers, Iryna Gurevych · Исследование

    2019; проверено 09.09.2026

19. 19
    Semantic Textual Similarity

    Sentence Transformers · Документация

    Дата версии не зафиксирована; проверено 09.09.2026

20. 20
    Retrieve & Re-Rank

    Sentence Transformers · Документация

    Дата версии не зафиксирована; проверено 09.09.2026

21. 21
    MTEB: Massive Text Embedding Benchmark

    Muennighoff, Tazi, Magne, Reimers · Исследование

    2022; проверено 09.09.2026

22. 22
    BEIR: A Heterogeneous Benchmark for Zero-shot Evaluation of Information Retrieval Models

    Thakur et al. · Исследование

    2021; проверено 09.09.2026

23. 23
    intfloat/multilingual-e5-base — model card

    intfloat · Карточка модели

    Дата версии не зафиксирована; проверено 09.09.2026

24. 24
    BAAI/bge-m3 — model card

    BAAI · Карточка модели

    Дата версии не зафиксирована; проверено 09.09.2026

25. 25
    Embeddings — Gemini API

    Google · Документация

    Дата версии не зафиксирована; проверено 09.09.2026

26. 26
    How to identify semantically similar pages & outliers

    Screaming Frog · Документация поставщика

    Дата версии не зафиксирована; проверено 09.09.2026

27. 27
    DataForSEO MCP Server v3

    DataForSEO · Официальный репозиторий

    Дата версии не зафиксирована; проверено 09.09.2026

28. 28
    Google keyword ideas — DataForSEO Labs

    DataForSEO · Документация

    Дата версии не зафиксирована; проверено 09.09.2026

29. 29
    SERP API overview

    DataForSEO · Документация

    Дата версии не зафиксирована; проверено 09.09.2026

30. 30
    Official Firecrawl MCP Server

    Firecrawl · Официальный репозиторий

    Дата версии не зафиксирована; проверено 09.09.2026

31. 31
    Try the Google Analytics MCP server

    Google · Документация

    Дата версии не зафиксирована; проверено 09.09.2026

32. 32
    Search Analytics: query

    Google · Документация

    Дата версии не зафиксирована; проверено 09.09.2026

33. 33
    Content collections

    Astro · Документация

    Дата версии не зафиксирована; проверено 09.09.2026

34. 34
    Deploy an Astro site — Cloudflare Pages

    Cloudflare · Документация

    Дата версии не зафиксирована; проверено 09.09.2026

35. 35
    Content Score in the Editor Explained

    Surfer · Документация поставщика

    Дата версии не зафиксирована; проверено 09.09.2026

36. 36
    Monitoring Your Published Content

    Clearscope · Документация поставщика

    Дата версии не зафиксирована; проверено 09.09.2026

37. 37
    How to automate your internal linking

    InLinks · Документация поставщика

    Дата версии не зафиксирована; проверено 09.09.2026

38. 38
    Structure/Function Claims

    FDA · Регулятор

    Дата версии не зафиксирована; проверено 09.09.2026

39. 39
    Health Products Compliance Guidance

    FTC · Регулятор

    Декабрь 2022; проверено 09.09.2026

40. 40
    EU register of health claims

    European Commission · Регулятор

    Дата версии не зафиксирована; проверено 09.09.2026

41. 41
    Marco jurídico para suplementos alimenticios

    COFEPRIS · Регулятор

    Дата версии не зафиксирована; проверено 09.09.2026

42. 42
    Magnesium — Health Professional Fact Sheet

    NIH Office of Dietary Supplements · Медицинский справочник

    Дата версии не зафиксирована; проверено 09.09.2026

43. 43
    Информация о выборе и проверке БАД

    Роспотребнадзор · Регулятор

    Дата версии не зафиксирована; проверено 09.09.2026

44. 44
    Статья 25. Реклама БАД и пищевых добавок

    КонсультантПлюс / текст федерального закона · Правовая база

    Дата версии не зафиксирована; проверено 09.09.2026

45. 45
    codex-seo

    AgriciDaniel · Репозиторий автора

    Дата версии не зафиксирована; проверено 09.09.2026

46. 46
    Yoast developer portal: core SEO features

    Yoast · Документация поставщика

    Дата версии не зафиксирована; проверено 09.09.2026

47. 47
    Sitemap — Rank Math Documentation

    Rank Math · Документация поставщика

    Дата версии не зафиксирована; проверено 09.09.2026

48. 48
    Cloudflare’s own MCP servers

    Cloudflare · Документация

    Дата версии не зафиксирована; проверено 09.09.2026

49. 49
    pgvector: vector similarity search for Postgres

    pgvector · Репозиторий авторов

    Дата версии не зафиксирована; проверено 09.09.2026

50. 50
    Disclosures 101 for Social Media Influencers

    FTC · Регулятор

    2019; проверено 09.09.2026

51. 51
    Product snippet structured data

    Google · Документация

    Дата версии не зафиксирована; проверено 09.09.2026

52. 52
    AI features and your website

    Google · Документация

    Обновлено 10.12.2025; читать вместе с источниками 3 и 4 за 2026 год

Локальные материалы, проверенные отдельно

Прочитаны SKILL.md для dfs-product-keywords, gist-page-plan, gist-meta, gist-post-publish, seo; проверены фрагменты seo-geo/SKILL.md и seo/references/quality-gates.md, наличие скриптов product_keywords.py, serp_cluster.py и meta_check.py. Пути записаны в отчёте относительно каталога skills, чтобы документ можно было пересылать. Это локальные правила процесса, а не источники сведений о Google.