SEO-аудит 7 сайтов через один сервисный аккаунт Search Console

Семь сайтов, семь вкладок, ноль общей картины

У меня в работе не один сайт, а портфель — на момент этой истории семь проектов разного размера и тематики. У каждого свой Google Search Console, у каждого своя история, свои проблемы. Пока сайт один, аудит — это открыть GSC, посмотреть отчёты, сделать выводы. Когда сайтов семь, та же процедура превращается в семь открытых вкладок, семь наборов цифр в голове и ноль ощущения, что видишь картину целиком.

Хуже другое: ручной обход не просто медленный, он ненадёжный. Когда сверяешь семь проектов вручную, неизбежно смотришь на них с разной тщательностью — тот сайт, который сегодня «горит», разберёшь подробно, а остальные пролистаешь по диагонали. Проблемы, которые не кричат сами о себе — тихие технические утечки трафика, — в таком режиме почти гарантированно проходят мимо. Мне нужен был не ещё один поход в интерфейс, а способ смотреть на весь портфель одним запросом.

Решение: один сервисный аккаунт на все семь сайтов

Идея простая: вместо того чтобы логиниться в GSC под каждый сайт отдельно, я завёл один сервисный аккаунт Google и добавил его пользователем с доступом на чтение сразу во все семь проектов. Дальше — Python-скрипт, обёртка над GSC API, который умеет за один прогон пройтись по всем сайтам, авторизованным на этот аккаунт, и вытащить данные разом: список сайтов, суммарные метрики по каждому (клики, показы, CTR, средняя позиция), топ-запросы и топ-страницы.

Технически это не сложная разработка — GSC API открыт и хорошо документирован, вся работа в том, чтобы один раз собрать пайплайн и больше не возвращаться к веб-интерфейсу за рутинными цифрами. Написал скрипт с помощью Claude Code, буквально за один присест: цикл по списку сайтов, вызов API, агрегация в одну таблицу.

Отдельно от скрипта сбора данных написал второй — analyze.py. Его задача не показать цифры, а найти в них проблему: пройтись по выгрузке и подсветить конкретные паттерны, которые обычно означают утечку трафика, а не просто «сайт слабо ранжируется».

Что нашёл аудит летом 2026 года

Первый же прогон по всем семи сайтам вскрыл две категории проблем, которые в разрозненном виде — по одной вкладке за раз — легко не заметить.

www-дубли. У части сайтов один и тот же контент оказался доступен по двум разным адресам одновременно — например, с www и без www, или по http и https без жёсткой склейки в один канонический вариант. Для человека, который просто открывает сайт в браузере, разницы никакой: браузер сам разберётся и покажет страницу. А вот для поисковика это два разных адреса с одинаковым контентом. Он не обязан понимать, что это один и тот же сайт, — он честно делит сигналы (ссылки, поведенческие метрики, историю индексации) между двумя URL вместо того, чтобы концентрировать их на одном.

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

Как чинил найденное

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

1. Собрать полный список дублей. По каждому сайту из выгрузки скрипта выписал, какие адреса реально отдают одинаковый контент — www/без www, http/https, со слэшем на конце и без.
2. Починить то, что чинится на сервере. Там, где хостинг и конфигурация были под моим контролем, поставил серверный 301-редирект на единственный канонический адрес — и дубль перестал существовать физически, а не только логически.
3. Отложить то, что требует стороннего доступа. На части проектов настройка редиректа зависела от конфигурации на стороне клиента или стороннего сервиса — эти случаи я не стал изображать решёнными, а честно занёс в список задач с пометкой, кто и что должен сделать.
4. Прогнать analyze.py по всему портфелю повторно. После первого раунда правок повторил аудит по всем семи сайтам, чтобы убедиться: закрытые дубли действительно исчезли из выгрузки, а не просто перестали бросаться в глаза.

Урок: портфель требует системы, а не героизма

Главный вывод этой истории не про www-дубли и не про каннибализацию — эти проблемы сами по себе довольно типовые и хорошо описаны. Вывод про масштаб: пока сайт один, можно быть внимательным руками и почти всё заметить. Как только сайтов становится семь и больше, ручное внимание перестаёт быть надёжной стратегией — не потому что вы стали хуже работать, а потому что физически нельзя одинаково тщательно держать в голове семь независимых картин одновременно.

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

Что я теперь делаю по этому портфелю регулярно:

• Гоняю сводный скрипт по всем сайтам на регулярной основе, а не только когда что-то явно пошло не так.
• Держу отдельный чек по www/http-https дублям как первую проверку для любого нового проекта, ещё до того как он попадёт в общий аудит.
• Не считаю проблему решённой, пока повторный прогон analyze.py не подтвердит, что паттерн действительно исчез из данных, а не просто из поля зрения.

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