Автоматизация SEO: API Вебмастера и скрипты
Специалист, который каждое утро руками открывает Вебмастер, листает раздел «Страницы в поиске», копирует цифры в таблицу и отправляет по одной ссылке на переобход, тратит на рутину заметную часть рабочего времени — и всё равно замечает проблему на третий день, а не в тот час, когда она возникла. Всё это давно закрывается API: и Яндекс.Вебмастер, и Google Search Console отдают те же данные машинно, в JSON, по расписанию. В этой статье разбираем, что именно стоит автоматизировать, какие ручки есть у обоих API, где лимиты и как собрать рабочие сценарии, которые реально экономят время. Если руки до этого не доходят, автоматизацию можно переложить на подрядчика вместе с SEO-продвижением.
Коротко
- Автоматизировать в первую очередь стоит то, что нужно делать часто и одинаково: контроль индексации, переобход, снятие позиций, сбор данных для отчётов, мониторинг доступности.
- API Яндекс.Вебмастера даёт индексацию, поисковые запросы, ошибки, переобход URL и мониторинг важных страниц. Квоты на переобход выделяются на сайт и зависят от его размера и качества.
- Google Search Console API отдаёт Search Analytics (клики, показы, CTR, позиции), статусы индексации через URL Inspection и управление sitemap.
- Ценность автоматизации — не в самих отчётах, а в исторических данных и алертах: интерфейсы хранят ограниченное окно, ваша база — сколько нужно.
- Скрипт не заменяет специалиста: он снимает рутину и приносит аномалии, решения принимает человек.
- Начинать надо с одного сценария, доведённого до конца, а не с «платформы автоматизации всего».
Что вообще имеет смысл автоматизировать
Первое правило автоматизации в SEO звучит скучно, но экономит месяцы: автоматизируют не то, что интересно автоматизировать, а то, что делается регулярно, по одному и тому же алгоритму и без творческих решений. Если задачу выполняют раз в квартал и каждый раз по-новому — скрипт под неё будет дороже ручной работы. Если задачу делают каждый день одинаково — она обязана быть автоматизирована.
Разложим типовой пул задач по этому критерию. Контроль индексации: сравнить список страниц из карты сайта с тем, что реально в поиске, и найти разницу. Алгоритм не меняется никогда — идеальный кандидат. Отправка на переобход: взять новые и изменённые URL, отправить в очередь, зафиксировать результат. Тоже механика без вариантов. Снятие позиций: одинаковая процедура с фиксированным ядром. Сбор данных для отчёта: выгрузить, свести, посчитать дельты — тут автоматизируется сбор и расчёт, но не выводы. Мониторинг ошибок сервера и кодов ответа: проверка по расписанию с порогом срабатывания.
А вот что автоматизировать не надо: интерпретацию данных, решение о том, какие страницы схлопывать, а какие разносить, оценку качества текста, выбор стратегии. Скрипт отлично отвечает на вопрос «что изменилось», но не отвечает на вопрос «почему и что теперь делать». Разбор причины падения — по-прежнему работа головы, и статья про то, почему сайт упал в выдаче, показывает, насколько там много ветвлений.
Главный принцип
Автоматизация в SEO окупается не сэкономленными кликами, а сокращением времени реакции. Ручной контроль замечает выпадение страниц из индекса через дни или недели. Скрипт с ежедневной проверкой и порогом срабатывания приносит ту же новость через сутки — а иногда этого хватает, чтобы поймать сломанный robots.txt до того, как из поиска вылетит половина каталога.
API Яндекс.Вебмастера: что реально отдаёт
Начинать стоит с Яндекса — для большинства коммерческих проектов рунета это основной источник органики, и его API покрывает большую часть повседневной рутины. Прежде чем лезть в API, имеет смысл понимать интерфейс: разделы, метрики и логика описаны в материале про Яндекс.Вебмастер, а API — это ровно те же данные, только в JSON.
Авторизация и базовая механика
Доступ идёт через OAuth-токен: вы регистрируете приложение, получаете токен, дальше каждый запрос уходит с заголовком авторизации. Работа начинается с получения идентификатора пользователя, затем — списка сайтов, к которым у вас есть доступ. Каждый сайт имеет свой host_id, и он подставляется во все последующие вызовы. Права на сайт должны быть подтверждены в интерфейсе — API не выдаст данные по домену, который вы не верифицировали.
Основные группы методов
- Индексирование. История количества страниц в поиске, загруженных и исключённых страниц, а также разбивка исключённых по причинам — дубли, ошибки, запрет в robots.txt, недостаточное качество. Это самая ценная группа: именно тут ловятся массовые выпадения. Тема подробно разобрана в статье про индексацию сайта в Яндексе.
- Поисковые запросы. Показы, клики, средняя позиция и CTR по запросам и по URL за период. Фактически это данные для анализа спроса и точек роста, только машинно и с историей.
- Переобход страниц. Отправка URL в очередь на повторное сканирование и проверка статуса задачи. Квота ограничена и выделяется на конкретный сайт.
- Важные страницы. Список страниц, за которыми Вебмастер следит отдельно и присылает уведомления об изменении статуса. Через API туда удобно закидывать посадочные автоматически.
- Диагностика и ошибки. Проблемы сайта с уровнями критичности — фатальные, критичные, возможные, рекомендации.
- Внешние ссылки. История ссылочной массы и список ссылок — полезно для контроля профиля, о котором идёт речь в материале про ссылочное продвижение.
- Оригинальные тексты. Добавление текста до публикации, чтобы закрепить авторство.
Про квоты на переобход
Это место, где чаще всего ломаются ожидания. Квота переобхода не бесконечна, выделяется на сайт, обновляется ежедневно и зависит от размера и качества ресурса: молодой сайт на десяток страниц получает единицы адресов в сутки, крупный качественный проект — существенно больше. Поэтому скрипт переобхода должен не «слать всё подряд», а работать с приоритетной очередью: сначала новые и коммерчески значимые страницы, потом изменённые, потом всё остальное. И обязательно — фиксировать остаток квоты и не пытаться пробить лимит повторами: это не ускорит индексацию.
Частое заблуждение
Отправка URL на переобход — это не команда «проиндексируй», а заявка «посмотри сюда раньше обычного». Робот всё равно оценит страницу по своим критериям и может исключить её как недостаточно качественную или как дубль. Если страница выпадает и возвращается после каждого переобхода — проблема не в очереди, а в самой странице.
Google Search Console API: что берём оттуда
Даже если Google для проекта вторичен, его API стоит подключить хотя бы ради качества данных по запросам. Общая логика интерфейса и специфика работы с ним из России описаны в разборе Google Search Console. Через API доступны три практически значимые группы.
Search Analytics — центральный метод. Отдаёт клики, показы, CTR и среднюю позицию с группировкой по запросу, странице, стране, устройству, типу поиска и дате. Ключевой момент, ради которого автоматизация и затевается: интерфейс хранит ограниченное окно истории, и как только оно истекает, данные пропадают навсегда. Скрипт, который ежедневно выгружает Search Analytics в вашу базу, за год накапливает архив, которого у вас иначе просто не будет — и позволяет сравнивать «июль к июлю», а не только «неделя к неделе».
URL Inspection — проверка конкретного адреса: статус индексации, канонический URL по мнению Google, дата последнего сканирования, статус мобильной пригодности. Метод жёстко лимитирован по количеству вызовов в сутки, поэтому его нельзя гонять по всему каталогу — только по контрольной выборке важных страниц.
Sitemaps — список карт сайта, количество отправленных и проиндексированных URL, ошибки обработки. Удобно для контроля крупных структур, особенно когда карт много и они генерируются автоматически; детали устройства самих карт — в статье про sitemap.xml.
Таблица: что чем автоматизировать
| Задача | Источник | Периодичность | На что смотреть / порог тревоги |
|---|---|---|---|
| Страницы в поиске | API Вебмастера, индексирование | Ежедневно | Резкое изменение к скользящему среднему за неделю — повод разбираться |
| Исключённые страницы по причинам | API Вебмастера | Ежедневно | Рост категории «дубли» или «запрещено в robots.txt» — красный флаг |
| Переобход URL | API Вебмастера | По событию публикации | Остаток суточной квоты, статус задачи |
| Клики, показы, позиции | GSC Search Analytics + запросы Вебмастера | Ежедневно | Падение кликов при сохранении показов — проблема со сниппетом |
| Статус индексации адреса | GSC URL Inspection | Еженедельно, по выборке | Жёсткий суточный лимит вызовов — только контрольный список |
| Ошибки и диагностика | API Вебмастера, диагностика | Ежедневно | Появление любой фатальной или критичной проблемы |
| Коды ответа и доступность | Свой скрипт-пингер | Каждые 5–15 минут | Не-200 на посадочных, рост времени ответа |
| Целостность robots.txt и метатегов | Свой скрипт-диффер | Ежедневно | Любое неожиданное изменение файла или появление noindex |
| Ссылочный профиль | API Вебмастера, внешние ссылки | Еженедельно | Всплеск новых доноров — вероятная негативная атака |
Сценарий 1: ежедневный мониторинг индексации
Это первый скрипт, который стоит написать, и он же приносит больше всего пользы на единицу усилий. Логика простая: каждую ночь забираем из API Вебмастера историю по страницам в поиске, загруженным и исключённым, складываем в свою таблицу с датой, сравниваем со вчера и со скользящим средним за 7 дней. Если отклонение превышает заданный порог — отправляем уведомление.
Отдельно, и это важнее агрегата, разбираем исключённые страницы по причинам. Общая цифра «в поиске 4 800 страниц» мало о чём говорит: она может стоять на месте, пока внутри сотня коммерческих карточек ушла в дубли, а сотня мусорных фильтров пришла им на замену. Пофакторная разбивка ловит это сразу. Резкий рост категории «дубли» обычно означает, что где-то поехали параметры фильтров или canonical — механика описана в статье про canonical и дубли. Рост «запрещено в robots.txt» — почти всегда чей-то деплой с тестовым файлом; такие истории и их последствия разобраны в инструкции по robots.txt.
Второй слой этого же сценария — сверка карты сайта с реальностью. Берём URL из sitemap, берём проиндексированные страницы, считаем разницу в обе стороны. Страницы, которые есть в карте, но не в поиске, — кандидаты на переобход и на разбор качества. Страницы, которые в поиске есть, но в карте отсутствуют, — обычно технический мусор, который надо либо закрывать, либо легализовать. Обе выборки лучше сразу класть в отдельные листы отчёта — они и станут задачами на неделю.
Сценарий 2: умный переобход по событию
Ручная отправка ссылок на переобход — самая бессмысленная рутина в профессии. Автоматизируется полностью. Схема ниже — рабочая последовательность, которую можно повторить на любом стеке.
Ловим событие изменения
Источник — либо хук CMS при публикации и правке, либо ежедневный дифф sitemap по полю lastmod, либо сравнение хеша HTML страницы с предыдущим снимком. Третий вариант надёжнее всего: он ловит реальные правки, а не проставленные автоматом даты.
Кладём URL в очередь с приоритетом
Приоритет 1 — новые коммерческие посадочные и карточки. Приоритет 2 — существенно изменённые страницы. Приоритет 3 — косметика. Очередь хранится в вашей базе, а не в голове скрипта: перезапуск не должен терять состояние.
Проверяем страницу перед отправкой
Обязательный шаг, который экономит квоту: перед отправкой скрипт запрашивает URL и убеждается, что код ответа 200, нет noindex, canonical указывает сам на себя и контент непустой. Отправлять на переобход страницу с noindex — сжигать лимит впустую.
Отправляем в пределах квоты
Читаем остаток суточной квоты, берём из очереди столько адресов, сколько влезает, по приоритету. Остаток переносим на завтра. Никаких повторных отправок одного и того же URL чаще, чем раз в несколько дней.
Фиксируем результат и замыкаем цикл
Записываем дату отправки, затем через несколько дней проверяем, появилась ли страница в поиске. Если после двух-трёх циклов переобхода страница так и не индексируется — скрипт помечает её как проблемную и передаёт человеку: это уже вопрос качества или структуры, а не очереди.
Пятый шаг — то, что отличает рабочую автоматизацию от имитации. Скрипт, который просто шлёт URL и не проверяет исход, создаёт иллюзию работы. Скрипт, который замыкает петлю обратной связи, превращается в диагностический инструмент и сам приносит список страниц, требующих внимания.
Сценарий 3: сбор позиций и работа с запросами
Позиции — данные, которые почти всегда собирают неправильно. Первое, что нужно понять: официальные API отдают среднюю позицию по показам, а не позицию в конкретной выдаче. Это не одно и то же. Средняя позиция 8,4 может означать и стабильную восьмёрку, и метание между третьим и пятнадцатым местом. Для отчётности среднее вполне годится, для диагностики — нет.
Практичная схема выглядит так. Базовый слой — ежедневная выгрузка запросов из API Вебмастера и Search Analytics в свою базу: запрос, URL, показы, клики, CTR, средняя позиция, дата, регион. Этот слой бесплатен, легален и даёт полную картину видимости. Поверх него — съём позиций сторонним сервисом по приоритетному ядру: не по всем десяти тысячам фраз, а по нескольким сотням, которые реально влияют на деньги. Такой гибрид дешевле и честнее, чем попытка снимать всё подряд.
Дальше начинается то, ради чего всё затевалось, — автоматическая аналитика поверх накопленных данных. Скрипт сам, без человека, находит несколько типов ситуаций:
- Каннибализация. Один запрос за период показывался по двум и более URL — Яндекс не может выбрать посадочную. Скрипт выдаёт список конфликтов; дальше решение принимает человек, опираясь на логику кластеризации запросов.
- Просевший CTR. Показы на месте, позиция на месте, клики упали — почти всегда переписан title или конкурент собрал более привлекательный сниппет. Что с этим делать, разобрано в материалах про title и description и про сниппет и CTR.
- Запросы на границе ТОПа. Фразы с позицией 11–20 и заметными показами — самый дешёвый рост. Скрипт формирует этот список каждую неделю сам.
- Страницы-сироты по спросу. URL с показами, но без внутренних ссылок с релевантных разделов — прямая заявка на доработку внутренней перелинковки.
Сценарий 4: отчёты, которые собираются сами
Отчёт — это последняя стадия, и собирать его руками, когда данные уже лежат в базе, бессмысленно. Но у автоматических отчётов есть своя болезнь: их делают перегруженными. Дашборд на сорок графиков не читает никто, включая того, кто его собрал.
Алерты, минуты
Только аномалии и только тем, кто может среагировать: сайт недоступен, фатальная ошибка в диагностике, обвал индексации, изменился robots.txt. Пять-семь триггеров максимум, иначе на них перестают смотреть.
Рабочая сводка, ежедневно
Для специалиста: страницы в поиске и дельта, разбивка исключённых, отправленные на переобход и их судьба, топ выросших и упавших запросов. Читается за две минуты.
Отчёт клиенту, ежемесячно
Трафик, видимость, позиции по приоритетному ядру, конверсии и заявки, что сделано и что дальше. Собирается автоматически, комментируется человеком.
Деньги, ежеквартально
Связка «запрос → страница → заявка → сделка» из CRM. Тут автоматизация только подаёт цифры, а выводы про окупаемость делает специалист.
Ключевая мысль: автоматизируется сбор и расчёт, а не интерпретация. Отчёт без комментария «вот это выросло, потому что мы сделали то-то, а вот это упало, и вот план» — просто выгрузка. Какие метрики и KPI туда класть, подробно разобрано в статье про оценку эффективности SEO, а привязка к деньгам — в материале про сквозную аналитику.
Инфраструктура: где это живёт
Не нужен кластер и не нужна «платформа». Рабочий минимум, который закрывает всё описанное выше, выглядит так и разворачивается за день-два.
Планировщик. Обычный cron на любом дешёвом сервере. Ночные выгрузки — раз в сутки, пингер доступности — каждые несколько минут. Никаких оркестраторов на старте.
Хранилище. Одна база данных, куда всё складывается с датой. Не Google-таблица: у таблиц кончаются строки и ломаются формулы на десятках тысяч записей. База — это и есть главный актив: именно она даёт историю глубже, чем окно интерфейсов.
Скрипты. Python — фактический стандарт: HTTP-запрос, разбор JSON, запись в базу. Каждый сценарий — отдельный небольшой скрипт с одной задачей. Монолит «делает всё» невозможно чинить.
Витрина. Любой BI поверх базы или простые графики. Витрина — самая заменяемая часть системы, поэтому вкладываться в неё в последнюю очередь.
Три вещи, которые новички забывают и потом неделю ищут причину. Первое — обработка ошибок и повторы: API периодически отвечает ошибкой или таймаутом, и скрипт без ретраев с паузой однажды молча пропустит день данных. Второе — идемпотентность: повторный запуск за ту же дату должен обновлять запись, а не плодить дубли, иначе аналитика поедет. Третье — мониторинг самого мониторинга: если скрипт упал, вы должны узнать об этом; тишина не равна «всё хорошо». Отсутствие данных за сутки — это тоже алерт.
Типичные ошибки автоматизации
Строить платформу вместо скрипта
Классика: полгода проектируют универсальную систему, не выпускают ничего. Один рабочий скрипт мониторинга индексации приносит больше пользы, чем архитектура на бумаге.
Игнорировать квоты и получать бан
Долбёж API без пауз и без учёта лимитов приводит к блокировке токена. Уважайте квоты, ставьте задержки, кешируйте то, что не меняется ежечасно.
Алерт на каждый чих
Уведомление о колебании индексации на две страницы приходит трижды в день — и через неделю его отправляют в архив не читая. Пороги должны быть значимыми.
Скрести выдачу вместо API
Самописный парсер выдачи — капча, прокси, вечная починка после смены вёрстки, риски. Если данные есть в API — берите из API.
Верить цифрам без проверки
Метод API изменился, поле переименовали, скрипт пишет нули — а вы уверены, что трафик обвалился. Раз в месяц сверяйте выгрузку с интерфейсом вручную.
Считать скрипт заменой специалиста
Автоматизация приносит факты. Гипотезы, приоритеты и решения — работа человека. Дашборд сам по себе не двигает позиции ни на пункт.
Что автоматизировать за пределами API
Официальные API — ядро, но вокруг них есть слой, который закрывается собственными скриптами и приносит не меньше пользы.
Регулярный краулинг своего сайта. Раз в неделю обходим сайт и складываем в базу: коды ответа, title, description, H1, canonical, robots-метатеги, длину текста, вес страницы. На следующей неделе сравниваем. Скрипт сам покажет, где у пятидесяти карточек внезапно стал одинаковый title и где появились битые ссылки и ошибки 404. Это дифф-контроль, и он ловит последствия деплоев быстрее любого аудита.
Пингер доступности. Каждые несколько минут проверяем главную и десяток ключевых посадочных: код ответа и время отклика. Пятисотые ошибки в момент обхода роботом стоят позиций, а хостинг редко сообщает о них сам — эта связь разобрана в статье про хостинг и SEO.
Контроль критичных файлов. Ежедневный дифф robots.txt и sitemap. Строка Disallow, случайно доехавшая с тестового окружения, — одна из самых дорогих аварий в отрасли, и обнаруживают её обычно по обвалу трафика через неделю.
Мониторинг Core Web Vitals. Регулярный автоматический замер ключевых шаблонов страниц, чтобы деградация скорости после релиза всплывала сразу, а не на квартальном аудите. Что именно измерять и какие пороги считать рабочими — в разборе Core Web Vitals.
Слежение за конкурентами. Еженедельный снимок их структуры и новых разделов. Механику ручного анализа, которую вы будете автоматизировать, разбирает статья про анализ конкурентов.
С чего начать: план на две недели
Выпишите свою рутину за месяц
Буквально списком: что вы делаете руками и сколько раз. Задачи, повторяющиеся чаще раза в неделю по одному алгоритму, — ваш список на автоматизацию. Всё остальное пока не трогайте.
Получите доступы
OAuth-токен для API Вебмастера, доступ к GSC API. Проверьте, что права на сайт подтверждены и токены хранятся не в коде, а в переменных окружения.
Сделайте один скрипт до конца
Ежедневная выгрузка индексации в базу плюс одно уведомление при отклонении выше порога. Не два скрипта, не десять — один, доведённый до работающего состояния и живущий в cron.
Добавьте переобход с приоритетами
Очередь, проверка страницы перед отправкой, учёт квоты, фиксация исхода. Здесь высвобождается больше всего ручного времени.
Накопите историю запросов
Ежедневная выгрузка Search Analytics и запросов Вебмастера. Ценность появится не завтра, а через квартал — но начинать копить надо сегодня, задним числом эти данные не восстановить.
Соберите отчёт поверх базы
Когда в базе есть история, отчёт — это запрос к ней. И только теперь имеет смысл думать про витрину и красивые графики.
Через две недели такой работы у вас будет система, которая каждое утро сама сообщает, что изменилось, и освобождает те самые часы — не на «ничего не делать», а на то, что скрипт не умеет: стратегию, структуру, контент и работу с бизнесом. Как это выглядит на реальных проектах, видно в наших кейсах, а сравнить объём работ со стоимостью можно на странице цен на продвижение.
Частые вопросы
Для описанных сценариев достаточно базового Python: HTTP-запрос, разбор JSON, запись в базу. Это уровень нескольких вечеров обучения, а не профессии разработчика. Часть задач закрывается готовыми решениями и коннекторами без кода, но у них есть потолок: вы ограничены тем, что предусмотрел вендор. Свои скрипты дают полный контроль и стоят дешевле на дистанции. Компромисс — заказать разработку у программиста один раз, а дальше поддерживать самому: логика там простая и меняется редко.
Единого числа нет: квота выделяется на конкретный сайт и зависит от его размера, качества и истории. Маленький новый сайт получает единицы адресов в сутки, крупный качественный проект — существенно больше. Текущий остаток квоты возвращает сам API, и правильный скрипт всегда сначала читает остаток, а потом решает, сколько адресов взять из очереди. Пытаться пробить лимит повторными отправками бесполезно и вредно — это не ускоряет индексацию и только сжигает лимит.
Нет, это разные инструменты. Мониторинг отвечает на вопрос «что изменилось со вчера» и работает непрерывно. Аудит отвечает на вопрос «что вообще устроено неправильно» и требует человеческой экспертизы: оценки структуры, семантики, коммерческих факторов, конкурентного окружения. Скрипт никогда не скажет вам, что каталог спроектирован не под спрос. Автоматизация — это глаза, аудит — голова, и одно без другого не работает.
Частично. Официальные API отдают среднюю позицию по показам — этого достаточно для отчётности и для отслеживания трендов, но недостаточно для точной диагностики: средняя позиция сглаживает разброс. Самописный парсинг выдачи технически возможен, но упирается в капчи, прокси и постоянную починку после смены вёрстки. Практичная схема — база из официальных API по всей видимости плюс съём позиций сервисом по приоритетным нескольким сотням фраз.
Считайте по двум осям. Первая — освобождённые часы: посчитайте, сколько времени в месяц уходило на ручную рутину, и умножьте на стоимость часа специалиста. Вторая, более весомая, — сокращение времени реакции. Один вовремя пойманный сломанный robots.txt или обвал индексации, замеченный за сутки вместо трёх недель, окупает всю систему целиком. Именно вторая ось обычно и оправдывает вложение, хотя измерить её труднее.
Сначала проверьте очевидное: срок действия токена, лимиты запросов, изменения в методах. API обоих сервисов эволюционируют, поля переименовываются, методы устаревают. Поэтому в скрипте обязаны быть повторы с паузой при временных ошибках, логирование ответов и отдельный алерт на само падение скрипта. Самая опасная ситуация — не ошибка, а тихий сбой: скрипт формально работает, но пишет нули, и вы принимаете решения по пустым данным. Раз в месяц сверяйте выгрузку с интерфейсом руками.
На сайте в десяток страниц полноценная система избыточна — там ручной контроль дешевле. Но два вещи стоит поставить на автомат при любом размере: пингер доступности и дифф robots.txt. Они пишутся за час и защищают от аварий, которые для маленького сайта фатальны. Всё остальное имеет смысл начиная с нескольких сотен страниц, когда ручной обзор перестаёт быть реалистичным.
Для рутины вокруг данных — да: написание самих скриптов, разбор выгрузок, черновая группировка запросов, генерация гипотез по аномалиям. Для того, что попадает на сайт, — крайне осторожно: массовая автогенерация текстов и метатегов ведёт к переспаму и фильтрам. Риски и рабочие сценарии подробно разобраны в материале про нейросети в SEO. Правило простое: нейросеть помогает обрабатывать данные, но не публикует за вас.
Автоматизируем мониторинг и выведем сайт в ТОП
Настроим мониторинг индексации, переобход по API, сбор позиций и прозрачные отчёты — и займёмся продвижением, пока скрипты следят за техникой. Договор, понятные KPI, отчёты каждую неделю.
- Пакет «Старт» от 55 000 ₽/мес
- Пакет «Стандарт» 75 000 ₽/мес
- Пакет «Премиум» 95 000 ₽/мес
- Бесплатный аудит и прогноз
- Договор с гарантией результата
- Отчёты каждую неделю
Комментарии (14)
Кирилл
Пятый шаг в сценарии с переобходом — прямо в точку. У меня скрипт год слал URL и никогда не проверял, что с ними стало потом. Получается, я автоматизировал имитацию работы.
Марина_К
Про разбивку исключённых по причинам — это самое ценное в статье. У нас общее число страниц в поиске месяц стояло ровно, все были довольны, а внутри половина карточек тихо ушла в дубли. Заметили только когда заявки просели.
AdminSEO Мастер
Марина, классический случай — агрегат врёт, потому что притока и оттока поровну. Поставьте отдельный порог на каждую категорию исключённых, особенно на «дубли» и «запрещено в robots.txt»: там рост на пару десятков страниц уже повод лезть разбираться, даже если общая цифра не дрогнула.
vladimir77
Согласен насчёт «начинать с одного скрипта». Я в своё время месяца три рисовал архитектуру универсальной системы и в итоге не выкатил ничего.
Ольга П.
Подскажите по третьему шагу переобхода — проверка страницы перед отправкой. Достаточно кода 200 и отсутствия noindex, или canonical тоже обязательно смотреть? Просто у нас на фильтрах canonical часто ведёт на категорию.
AdminSEO Мастер
Ольга, canonical смотреть обязательно, и ваш пример — ровно та причина. Если canonical ведёт на другую страницу, отправлять этот URL бессмысленно: робот всё равно склеит его с целевой, а квота сгорит. Правило простое — в очередь попадает только страница с self-canonical.
Дмитрий
Не соглашусь, что cron на дешёвом сервере — рабочий минимум. Когда скриптов становится больше десятка, зависимости между ними в cron не выразить, и вы всё равно приедете к оркестратору. Лучше сразу закладываться.
Ирина
Спасибо за абзац про тихий сбой. У меня скрипт три недели писал нули после того, как в API переименовали поле, и я всерьёз готовила клиенту объяснение обвала трафика.
Сергей_бизнес
Я владелец, не специалист. У нас магазин, около 800 страниц, подрядчик на аутсорсе. Стоит ли мне вообще требовать всю эту автоматизацию, или это внутренняя кухня агентства и меня не касается?
AdminSEO Мастер
Сергей, кухня действительно внутренняя, но одну вещь требовать стоит: чтобы история выгружалась в базу, доступ к которой есть у вас, а не только у подрядчика. Смена агентства без накопленного архива по запросам означает, что вы начинаете историю с нуля. Если хотите — посмотрим на вашем аудите, что уже собирается, а что теряется.
Анна Т.
Про то, что средняя позиция 8,4 может быть метанием между третьим и пятнадцатым — объяснила это заказчику вашими же словами, наконец дошло, почему я не хочу строить отчёт только на средней.
Максим
Пингер и дифф robots.txt написал за вечер по вашей же логике. Через месяц поймал Disallow, приехавший с тестового окружения, в течение получаса. Одно это уже окупило вечер.
Тимур_К
А что если хостинг без возможности поставить cron и своей базы? Шаред, доступ только по FTP. Есть смысл городить что-то на стороне или проще забить и смотреть руками?
AdminSEO Мастер
Тимур, скриптам не обязательно жить на том же хостинге, что и сайт — они ходят в API снаружи. Возьмите самую дешёвую VPS или любой сервис с планировщиком, база там же. Сайт вообще не знает о существовании вашего мониторинга, и это правильно.
Женя
Пять-семь триггеров максимум — золотые слова. У нас в чате алертов было штук тридцать, читать их перестали примерно на второй неделе.
Ростислав
Гибрид из статьи работает: базу видимости тянем из API, а сервисом снимаем позиции только по паре сотен фраз, которые кормят. Раньше платили за съём десяти тысяч и половину не открывали ни разу.
Наиля
Скептически отношусь к поиску каннибализации скриптом. По моему опыту он выдаёт кучу конфликтов, где два URL просто соседи по смыслу и склеивать их не надо. Разбирать список руками выходит дольше, чем найти проблему глазами.
AdminSEO Мастер
Наиля, возражение справедливое, если скрипт ловит любое пересечение. Отсекайте шум порогами: конфликт засчитываем, только когда у обоих URL заметные показы и обе страницы попадали в выдачу по запросу в разные дни — то есть Яндекс реально переключался между ними. После такого фильтра список обычно сокращается в разы и становится рабочим.
Глеб_П
Начал копить Search Analytics в базу полгода назад просто на всякий случай. Сейчас сравниваю сезон с сезоном и понимаю, что это была лучшая инвестиция вечера в моей практике. Задним числом эти данные правда не достать.