Аудит ссылок после публикации с помощью GitHub Actions или обычного cron

Зачем вообще проводить аудит после публикации

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

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

Официального API проверки обратных ссылок Google для общего пользования нет, поэтому команды используют сторонние индексные системы ссылок. Это наш собственный краулер. Search Console показывает вид Google на ваши собственные ссылки, а аудит дополняет его, а не заменяет.

Где выполняется задача

Зафиксируйте триггер. Три настройки покрывают большинство команд, и каждая из них выполняет одни и те же вызовы. Лог важнее триггера, потому что дата, URL и использованные кредиты должны попадать туда каждый раз.

GitHub Actions для репозитория

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

Обычный сервер с cron

Команды, которые уже поддерживают машину для сборки, могут запланировать те же команды там. Инструмент вроде n8n может выполнять их через шаг Execute Command, или строка crontab может запускать их напрямую. В любом случае задача должна выполняться от имени пользователя, который может читать ключ, но не имеет других прав.

Вебхук от вашей CMS

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

Какие сайты проверять

Начните с домена, на котором размещен пост. Затем запустите тот же аудит для двух-трех сайтов-конкурентов, с которыми вы хотите сравниться. Используйте compare для этого. Он принимает до 20 доменов за 1 кредит, поэтому проверка конкурентов стоит почти ничего.

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

Как скрыть ключ из логов

Запланированная задача считывает свой ключ при каждом запуске, поэтому ей не нужен шаг входа. Единственное, что нужно защитить — это сам ключ. У него есть три очевидные точки утечки: коммит, распечатанная переменная окружения и URL, который записывает прокси. Закройте каждую из них.

Используйте хранилище секретов, а не файл в репозитории

Вставьте ключ в хранилище секретов вашего CI-провайдера или в файл окружения, который может читать только пользователь задачи. Никогда не фиксируйте его. Шаг, который выводит свое окружение, напечатает ключ, поэтому не делайте такого шага.

Передавайте ключ в заголовке

Заголовок Bearer держит ключ в стороне от большинства журналов доступа, потому что URL записываются, а заголовки обычно нет. Форма с query-строкой тоже работает, но оставляет копию в каждом прокси, который видит запрос.

Ограничьте круг лиц, которые могут читать хранилище

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

Ключ, который могут читать многие люди, однажды окажется вставленным в окно чата.

Проверяйте ответ перед тем, как записать его

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

Сначала проверьте статус и поле ok

Прочитайте код состояния HTTP, затем поле ok в теле ответа. Ответ со статусом 200 и ok равным false — это все еще неудачный вызов, и об этом должно быть написано в логе.

Парсите JSON перед любой записью

Подтвердите, что тело ответа является валидным JSON, прежде чем распаковывать, парсить или добавлять что-либо. Обрезанная загрузка может произойти на нестабильном раннере. Сломанный файл, записанный в лог, выглядит нормально, пока кто-то его не откроет.

Относитесь к пустому списку как к вопросу

Пустой результат для сайта, который имел строки в прошлом месяце, — это вопрос, а не факт. Проверьте написание домена, включая ведущий www., прежде чем кто-то получит оповещение.

Стоимость и где ее посмотреть

Ежемесячный аудит одного сайта стоит 4 кредита, если вы загружаете оба списка, что составляет $0.0004. Вызов обзора бесплатный. Месяц без изменений поэтому стоит ничего, кроме самого обзора.

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

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

Большая стоимость обычно связана с минутами вашего CI-провайдера, а не с нашими кредитами. Таблица стоимости ставит обе строки рядом, чтобы вы могли решить, какую из них оптимизировать в первую очередь.

Попросите первый запуск вывести _credits. Доверяйте ответу, а не любой таблице. Руководство по воротам охватывает проверку на этапе черновика, которая предшествует этой.

Расписание GitHub работает в UTC, поэтому старт в 06:00 приходится на разное локальное время для каждой команды. Укажите часовой пояс в руководстве, чтобы никто не удивился логу.

Вопросы о запуске аудита

Большинство этих вопросов задают команды, которые только что запланировали задачу впервые.

Это API проверки обратных ссылок Google?

Это аудит, построенный на нашем собственном API, а не продукт Google. Google не публикует общий API обратных ссылок, поэтому цифры берутся из нашего собственного краулера и нашего собственного индекса.

Может ли аудит запускаться при каждой сборке?

Может, но ежемесячная загрузка refdomains не должна запускаться при каждой сборке. Запускайте бесплатный обзор при каждой публикации, а платные загрузки — раз в месяц.

Нужен ли мне аудит, если у меня есть ворота?

Да, если вы публикуете через плагины или CDN. Ворота видят ваш черновик, а аудит — живую страницу. Каждая из них обнаруживает сбои, которые не видит другая.

Что делать, если задача прерывается на полпути?

Записывайте результат каждого шага в отдельный файл, чтобы сбойная загрузка не портила обзор. Перезапускайте с места сбоя, а не с начала, чтобы избежать двойной оплаты за ту же загрузку.

Сколько кредитов мне зарезервировать на каждый сайт?

Зарезервируйте 4 кредита на сайт в месяц для двух платных загрузок, плюс то, что тратят ворота на черновики. Бесплатный обзор не добавляет ничего к этой цифре, а лог показывает реальную сумму.

Почему два запуска, сделанных с разницей в несколько дней, расходятся?

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