Кластеризация семантики и выгрузки GSC / Вебмастера на ноутбуке: обход лимита 1 000 строк, лемматизация и Polars/DuckDB

Кластеризация семантики и выгрузки GSC / Вебмастера на ноутбуке: обход лимита 1 000 строк, лемматизация и Polars/DuckDB

Веб-интерфейс отчёта «Эффективность» в Google Search Console отдаёт при нажатии кнопки «Экспорт» максимум 1 000 строк — для информационного портала, медицинского справочника или интернет-магазина с 300 000 низкочастотных запросов это меньше 0,5 % реальной видимости сайта! В то же время платные облачные сервисы постраничной кластеризации на ядрах в 200 000–500 000 ключей требуют ощутимых бюджетов на каждую пересборку порога группировки.

На современном рабочем ноутбуке вся цепочка — пакетная выгрузка всех 100 % доступных пар Запрос + URL по официальному бесплатному API -> морфологическая чистка и дедупликация -> поиск каннибализации страниц -> графовая/векторная кластеризация — выполняется локально за считанные минуты без абонентской платы.

Как выгрузить сотни тысяч строк из API Google Search Console и Яндекс Вебмастера

Официальный метод searchanalytics.query Google Search Console API v1 отдаёт до 25 000 строк за один HTTP-запрос с пагинацией через смещение startRow (0, 25000, 50000...) вплоть до полного исчерпания выборки за период (или ежедневного экспорта без потерь!). Аналогично API Яндекс Вебмастера v4 позволяет автоматизировать сбор статистики популярных запросов, истории показов/позиций и примеров индексируемых URL в локальную базу данных ноутбука:

Детектор внутренней каннибализации страниц на ноутбуке за 5 строк кода

Прежде чем заказывать новые статьи или создавать новые теговые страницы в каталоге, проверьте на выгрузке GSC, не воюют ли уже существующие разделы сайта друг с другом за один и тот же интент! В библиотеке Polars (написанной на Rust и задействующей все ядра процессора ноутбука) поиск каннибализирующих пар на миллионе строк занимает меньше секунды:

import polars as pl

df = pl.read_parquet("gsc_query_page_90d.parquet")
cannibal = (
    df.group_by(["query", "page"])
    .agg(pl.col("clicks").sum(), pl.col("impressions").sum(), pl.col("position").mean())
    .filter(pl.col("impressions") >= 30)
    .with_columns(
        pl.col("page").count().over("query").alias("competing_urls"),
        (pl.col("impressions") / pl.col("impressions").sum().over("query")).round(2).alias("share"),
    )
    .filter(pl.col("competing_urls") >= 2)
    .sort(["impressions", "query"], descending=[True, False])
)
cannibal.write_parquet("cannibalization_report.parquet")

Сопоставьте найденные конфликтующие URL с картой редиректов и каноникалов из обхода Screaming Frog и частотой обхода робота в серверных логах DuckDB — в 80 % случаев склейка двух слабых конкурирующих страниц на позиции 14 выводит объединённый документ в ТОП-3 без единой внешней ссылки!

Три уровня локальной кластеризации на ноутбуке: Леммы -> SERP Hard/Soft -> Векторные эмбеддинги

Когда перед SEO-отделом стоит задача разобрать сырое семантическое ядро на 300 000 фраз из поисковых подсказок, баз и кампаний контекстной рекламы, не отправляйте в дорогой парсинг выдачи грязный массив с падежными дублями:

1. Ступень 1 — Нормализация и русская лемматизация (pymorphy3): приведение всех словоформ к начальной форме словаря OpenCorpora ("купить ноутбука для сметчика" и "ноутбуки сметчику купить" склеиваются в единый отсортированный ключ лемм), удаление стоп-слов, неявных дублей и мусорных топонимов чужих стран. На 8-ядерном ноутбуке с кэшированием lru_cache уникальных слов 500 000 фраз лемматизируются за 4–7 секунд, сразу сокращая ядро на 35–55 %!
2. Ступень 2 — Кластеризация по пересечению ТОП-10 выдачи (Hard против Soft):
   • Режим Hard: все запросы внутри одной группы обязаны иметь минимум N (обычно 3–4) общих URL с каждым другим запросом кластера — идеально для информационных статей блога и узких карточек услуг, где малейшее смешение интентов размывает релевантность!
   • Режим Soft: запросы связываются с центральным «маркерным» ВЧ-запросом — подходит для широких листингов категорий e-commerce, но на больших ядрах без ограничения степени связности склонен сваливать соседние подкатегории в один гигантский «снежный ком» (решается алгоритмом выделения плотных сообществ Louvain / Leiden на графе общих URL!).
3. Ступень 3 — Локальные мультиязычные эмбеддинги (intfloat/multilingual-e5-small / bge-m3 на CPU/GPU ноутбука): позволяют мгновенно предгруппировать миллионные хвосты бессерверных микрозапросов по смыслу и отфильтровать нерелевантные отрасли ещё до съёма выдачи.

Аппаратные требования к ноутбуку семантика и контент-аналитика

• Key Collector 4 и тяжёлые таблицы: настольная Windows-программа Key Collector при открытии проектов на 150 000+ фраз со снятыми частотностями активно нагружает процессор, SQLite-диск и оперативную память, а локальные Python-тетрадки Jupyter с матрицами косинусной близости TF-IDF / Embeddings легко занимают 12–24 ГБ RAM.
• Оптимальный баланс: процессор на 8–12 ядер, 32 ГБ ОЗУ (или 16 ГБ со свободным слотом расширения — практичные бизнес-платформы разобраны в подборке ноутбуков для 1С, аналитики и расчётов) и быстрый NVMe SSD на 1 ТБ (при съёме локальных SERP-выгрузок в JSON/SQLite на 200 тыс. ключей сырой слепок выдачи занимает 15–40 ГБ на диске).

Чек-лист сборки семантического ядра без самоканнибализации

• [ ] Выполнена полная выгрузка фактических пар Запрос + Посадочная страница из API GSC и Яндекс Вебмастера в обход 1000-строчного лимита интерфейса.
• [ ] Проведены нормализация регистра, замена ё -> е, склейка падежных/числовых дублей лемматизатором и чистка явных нецелевых минус-слов (рефераты, б/у или бесплатно — в зависимости от бизнес-модели!).
• [ ] Разделены коммерческие (листинги/карточки каталога) и информационные (статьи и руководства /blog/) интенты по составу реальной выдачи ТОП-10, чтобы не пытаться продвигать статью блога по транзакционному запросу каталога и наоборот!
• [ ] Каждому новому кластеру сопоставлен либо уже существующий URL сайта (на доработку), либо строго уникальный проектный slug с проверкой отсутствия смыслового дубля во всём плане публикаций.

Частые вопросы

Почему сумма кликов по запросам в API Google Search Console всегда меньше общей суммы кликов по страницам сайта? В целях конфиденциальности пользователей Google скрывает (Anonymized Queries) редкие индивидуальные и персональные микрозапросы в разрезе измерения query: они не возвращаются ни в интерфейсе, ни по API при добавлении группировки query, но полностью учитываются в итоговых суммах при запросе статистики только с измерением ["page", "date"]! Всегда выгружайте обе таблицы отдельно — разница покажет точную долю скрытого сверхдлинного хвоста каждой статьи.

Достаточно ли одной нейросетевой/векторной кластеризации без проверки реального ТОП-10 поисковика? Нет! Лингвистически запросы «ремонт кофемашины своими руками» и «ремонт кофемашины на дому недорого» лежат в векторном пространстве очень близко, но поисковая система считает первый запрос информационной инструкцией (статья/видео), а второй — коммерческой услугой сервисного центра с совершенно разным ТОП-10! Финальная проверка по пересечению выдачи защищает от объединения несовместимых коммерческих и статейных интентов на одной странице.