Проверка бэклинков страницы при публикации: пошаговое руководство
Один вебхук, один HTTP-запрос, одно решение. Это руководство проведет команду headless CMS через процесс срабатывания, вызовы API и обработку сбоев.
Исследовательская команда Contentin ·
Определите, что может делать контрольная точка
Проверка бэклинков страницы в процессе выпуска — это небольшая задача. Держите её в рамках малого. Самая сложная часть — решить, какие изменения ответа допустимы, потому что граф ссылок, обновляемый раз в месяц, не может самостоятельно блокировать публикацию страницы.
Мы рекомендуем, чтобы контрольная точка выводила предупреждение, фиксировала событие и позволяла сборке продолжиться. Правила по умолчанию могут меняться. Жесткие блокировки уместны для вещей, которые вы контролируете, таких как сломанная разметка или отсутствующий canonical-тег. Данные о ссылках — это сигнал, а сигналы могут изменяться.
Запишите это. Сделайте это до начала кодирования. Однострочная политика вроде «предупредить редактора, пометить запись, никогда не останавливать деплой» сэкономит долгие споры в 18:00 в день релиза. Это также подскажет следующему инженеру, какие сбои были запланированы, а какие — ошибками, что важнее, чем может показаться. Пересматривайте её раз в квартал.
Шесть шагов от нажатия кнопки публикации до сохранения заметки
1
Выберите триггер
Подпишитесь на событие публикации вашей CMS. Contentful, Sanity и Strapi могут вызывать URL, который вам принадлежит, при публикации записи, а Storyblok и Payload также предлагают вебхуки или хуки. Отфильтруйте контентные типы, содержащие исходящие или canonical-ссылки.
2
Сведите URL к домену
API принимает домен в параметре q, поэтому https://www.example.com/blog/post?x=1 сначала нужно преобразовать в example.com. Один раз определите, как вы обрабатываете www, и протестируйте один реальный домен с помощью бесплатного действия domain перед тем, как что-то строить.
3
Сначала вызовите бесплатное действие
overview ничего не стоит. Если ответ будет «тонким», домен может быть новым или просто неизвестен нашему индексу. Это не доказательство чего-либо плохого.
4
Тратьте кредиты только при срабатывании правила
Когда ваше правило говорит «посмотреть ближе», вызовите backlinks с параметром per=100. Это стоит 2 кредита независимо от количества строк, поэтому запрашивайте полезную страницу строк, а не десять маленьких.
5
Запишите заметку, а не сырой JSON
Сохраняйте краткий вердикт в отдельном поле, а также дату проверки. Сырые ответы раздувают записи и быстро устаревают, так как индекс обновляется каждый месяц.
6
Мягкая обработка ошибок
HTTP 401 означает, что ключ отсутствует или неверен — уведомите человека. HTTP 402 означает, что кредиты исчерпаны. При любой другой ошибке: запишите её в лог, пропустите проверку и разрешите публикацию.
Где хранится ключ и как обрабатывать 402
Каждый платный запрос содержит ваш ключ, либо в строке запроса, либо в заголовке Bearer. Предпочитайте заголовок. Строка запроса может попасть в логи сервера и трассировки прокси, тогда как заголовок обычно в них не попадает.
Храните ключ как секрет в среде вашей хостинг-платформы, никогда — в самой записи. Редакторы могут прочитать любое поле, к которому у них есть доступ, но переменные окружения функции обычно видны только тем, кто управляет деплоем.
Где должен храниться ключ?
Утечка ключа может привести к расходу баланса на вашем аккаунте, поэтому относитесь к нему как к паролю. Храните его вне репозитория и вне CMS, а также меняйте его, если он когда-либо появится в логах в открытом виде.
Мечьте свои логи именем хука. Это позволит легко отследить расходы до конкретной функции, даже если несколько хуков используют один аккаунт.
Может ли no-code инструмент выполнить запрос?
Да, если в инструменте есть шаг обычного HTTP-запроса. Многие конструкторы автоматизации могут отправить GET-запрос со строкой запроса и получить JSON-ответ, поэтому для бесплатного действия просмотра обзора код вообще не нужен.
Начните только с бесплатных действий. Поток, срабатывающий при каждом сохранении черновика, может расходовать кредиты быстрее, чем редактор заметит это, поэтому добавляйте платный шаг только после того, как бесплатные вызовы проработают стабильно какое-то время.
Что должен запускать статус 402?
Статус 402 означает, что баланс пуст. Он ничего не говорит о странице. Пропустите платную проверку, запишите событие в лог и отправьте одно уведомление тому, кто пополняет аккаунт, затем разрешите публикацию.
Установите предупреждение о балансе на уровне, значительно превышающем ноль, чтобы предупреждение пришло, пока ещё есть время пополнить счёт. Цикл повторных попыток здесь не поможет, так как каждый запрос будет завершаться одной и той же ошибкой до тех пор, пока кто-то не добавит кредиты. Цифры указаны в таблице стоимости.
Протестируйте два запроса из терминала
Выполните их один раз для домена, который вам известен, до того, как хук сделает это за вас. Прочтите поле _credits во втором ответе.
bash
# free, no key
curl -s "https://contentin.app/api.php?action=overview&q=example.com"
# 2 credits, key in a header
curl -s -H "Authorization: Bearer sk_live_..." \
"https://contentin.app/api.php?action=backlinks&q=example.com&per=100"
Какой домен подставлять в параметр q
API принимает чистый домен в параметре q, поэтому полный URL нужно сначала привести к нужному виду. Напишите эту логику преобразования один раз в одной функции. Затем протестируйте её на реальных URL.
Относительные ссылки и отсутствующие протоколы — это случаи, которые чаще всего ломают хук. Преобразование, работающее на чистых примерах, всё ещё может дать сбой на «грязных» URL, которые редактор вставляет в 17:00.
Влияет ли наличие www на ответ?
Может быть, и самый честный способ узнать это — спросить. Запустите бесплатную проверку домена в обеих формах для одного известного вам сайта, а затем сравните два ответа рядом.
Какое бы правило вы ни выбрали, запишите его в комментарии к коду, чтобы следующий инженер не гадал. Комментарий ничего не стоит, но спасает от долгого спора в будущем.
А как насчет редиректов и поддоменов?
Отправляйте хост, на который фактически попадают ваши читатели, а не ссылку, которую редактор вставил несколько лет назад. Если эта ссылка ведет на редирект, сократите конечный адрес и проигнорируйте промежуточный переход.
Блог на отдельном поддомене — это вопрос суждения. Заранее решите, проверяется ли он отдельно или вместе с родительским доменом, и запишите этот выбор рядом с правилом.
Чек-лист перед запуском для хука
Хук срабатывает только при публикации, а не при каждом сохранении черновика
URL сокращается до базового домена перед вызовом
Бесплатные действия выполняются первыми, а кредиты тратятся только при установке флага
У 401 и 402 есть свои собственные оповещения и свои собственные сообщения
Установлен таймаут, поэтому медленный API никогда не заблокирует редактора
Сохраненная заметка содержит дату, поэтому никто не примет ее за актуальные данные
Одна и та же запись, опубликованная дважды, не будет оплачена дважды (см. список мифов)
Что логировать, а что оставить за пределами записи
Строка лога для каждой пропущенной проверки — это самое дешевое аудиторское следствие, которое вы можете создать. Запишите ID записи, домен, который вы отправили, код состояния и то, был ли выполнен платный шаг. Обычно этого достаточно.
Сохраненная заметка остается краткой и датированной, как указано в шагах выше. Полные ответы должны храниться в ваших собственных логах, если они должны храниться где-либо, потому что они большие и быстро устаревают.
Какие поля должны быть в строке лога?
Начните с ID записи и версии публикации. Повторный вебхук тогда будет отображаться как одна и та же пара дважды, что именно то, что вы хотите видеть.
Добавьте домен, имя действия, код состояния и время начала вызова. Оставьте сам ключ вне лога, так как лог, содержащий его, становится вторым местом, где хранятся секреты.
Как долго должна жить сохраненная заметка?
Пока живет запись, если только более новая проверка не заменит ее. Важно, чтобы читатель мог понять, насколько стара заметка, потому что заметка, сделанная несколько месяцев назад, выглядит как актуальные данные.
Руководство по полю оценки показывает четыре поля, которые мы рекомендуем для этой заметки, включая дату.
Протестируйте хок на staging-окружении перед запуском
Выполните эти четыре проверки, прежде чем кто-либо начнет полагаться на хук.
1
Воспроизведите одну прошлую публикацию
Запустите хук с копией записи, которую вы уже опубликовали. Сравните сохраненную заметку с тем, что вы ожидали, и подтвердите, что одна и та же запись не была оплачена дважды.
2
Попробуйте домен, зарегистрированный недавно
Используйте домен партнера, который для вас новый. Пустой или скудный ответ должен быть сохранен как неизвестный, а не как ошибка, и заметка должна говорить об этом простыми словами.
3
Намеренно вызовите 402
Запустите хук с ключом на тестовом аккаунте, баланс которого вы обнулили. Подтвердите, что пропуск, строка лога и оповещение срабатывают, а публикация все еще достигает сборки.
4
Прочитайте сообщение, которое видит редактор
Попросите кого-то извне команды прочитать текст ошибки вслух. Если они не могут сказать, что делать дальше, перепишите сообщение перед днем запуска. Постмортем показывает, сколько стоило неясное сообщение одной вымышленной команде.
Что хук не может увидеть
Наш индекс обновляется примерно раз в месяц. Ссылка, добавленная после последней проверки, не будет отображаться, а удаленная ссылка может все еще появляться. Для подтверждения в тот же день используйте отчет Links в Google Search Console.
