Ручний процес

Аудит посилань після публікації за допомогою GitHub Actions або звичайного cron

Публікація опублікована, а конвеєр ще не завершено. Цей ручний процес додає планований аудит, який записує дані про посилання для кожного сайту та повідомляє людині лише тоді, коли щось виглядає неправильно.

Дослідницька команда SEOBlogBot · Оновлено 2026-10-29

Верстак майстерні з колесом розкладу, токенами кредитів та дзвоном сповіщення у стилі low-poly

Навіщо взагалі проводити аудит після публікації

Контрольна точка бачить чернетку. Аудит бачить, що насправді робить живий сайт. Плагіни переписують посилання, редактори вставляють affiliate-перенаправлення замість чистих URL-адрес, а міграція CDN може перетворити один хост на інший. Нічого з цього не існує на етапі чернетки, тому запуск після публікації — це перше місце, де це може проявитися.

Корисний аудит нудний за своєю природою. Він працює за розкладом, записує один рядок і залишається тихим, якщо не спрацювало виняток. Тихо — це ціль. Місяць тихих журналів означає, що робота виконується, а не те, що вона простоює.

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

Де виконується робота

Запишіть тригер. Три налаштування покривають більшість команд, і кожне з них виконує однакові запити. Журнал важливіший за тригер, тому що дата, URL-адреса та використані кредити мають потрапляти туди кожного разу.

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

Якщо сайт збирається з репозиторію, планований робочий процес додає найменше тертя. Робота живе поруч із кодом, а ключ знаходиться в сховищі секретів репозиторію. Файл робочого процесу нижче — це мінімум, який вам потрібен. Зберігайте його в репозиторії, переглядайте як будь-який інший код, та фіксуйте версії дій, на які ви покладаєтеся.

Звичайний сервер з cron

Команди, які вже тримають машину для своєї збірки, можуть запланувати ті ж самі команди там. Такий інструмент, як n8n, може виконувати їх через крок Execute Command, або рядок crontab може виконувати їх напряму. У будь-якому випадку робота повинна виконуватися від імені користувача, який може читати ключ і нічого більше.

Вебхук від вашої CMS

Деякі налаштування CMS запускають вебхук, коли публікація стає живою, і ця подія може запустити аудит. Перевірка тоді виконується в момент, коли публікація стає публічною. Зберігайте також планований запуск, оскільки один пропущений вебхук залишає публікацію без перевірки.

Ручний процес, по порядку

Запуск при публікації та знову через 30 днів

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

Спочатку викличте безкоштовний огляд

action=overview повертає загальні цифри сайту безкоштовно. Збережіть їх як базовий рядок для цього запуску, з датою поруч.

Витягуйте платні списки лише при зміні

Якщо огляд відрізняється від минулого місяця, викличте refdomains (2 кредити) та anchors (2 кредити) та зробіть diff проти збережених списків.

Запишіть один рядок у журнал

Дата, URL публікації, виконані запити, баланс _credits. Звичайний CSV, зафіксований у приватному репозиторії, достатній.

Сповіщайте лише про винятки

HTTP 401, HTTP 402, порожній результат для сайту, який мав рядки минулого місяця, або падіння рейтингу на 10 балів або більше.

Латунні терези, що зважують одну велику рослину проти двох менших однакових рослин

Які сайти перевіряти

Почніть з домену, який розміщує публікацію. Потім запустіть той самий аудит проти двох або трьох колег, яких ви хочете порівняти. Використовуйте compare для цього. Він приймає до 20 доменів за 1 кредит, тому перевірка колег коштує майже нічого.

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

Збереження ключа поза журналами

Запланована робота читає свій ключ кожного запуску, тому їй ніколи не потрібен крок входу. Єдина річ, яку потрібно захистити — це сам ключ. У нього є три очевидні витоки: коміт, надруковане середовище та URL-адреса, яку записує проксі. Закрийте кожен з них.

Використовуйте сховище секретів, а не файл у репозиторії

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

Надсилайте ключ у заголовку

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

Обмежте, хто може читати сховище

Надайте доступ на читання людям, які підтримують роботу, і нікому більше. Переглядайте цей список, коли робота переходить у інші руки.

Ключ, який багато людей можуть читати, — це ключ, який одного дня опиниться вставленим у вікно чату.

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

Відповідь, яка надійшла, ще не є відповіддю, яку можна використовувати. Використовуйте один порядок кожного разу. Записуйте лише те, що пройшло, і журналюйте решту. Відхилену відповідь — це доказ, і наступній людині, яка буде налагоджувати роботу, захочеться її побачити.

Спочатку перевірте статус та ok

Прочитайте код стану HTTP, потім поле ok у тілі. 200 з ok встановленим у false — це все ще невдалий запит, і журнал повинен так сказати.

Парсуйте JSON перед будь-яким записом

Підтвердіть, що тіло є дійсним JSON, перш ніж розпаковувати, парсити або додавати щось. Обрізане завантаження може статися на ненадійному раннері. Зламаний файл, записаний у журнал, виглядає нормально, доки хтось його не відкриє.

Ставтеся до порожнього списку як до питання

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

Файл робочого процесу для початку

Збережіть ключ як секрет репозиторію з назвою SBB_KEY. Вираз cron запускається першого числа кожного місяця о 06:00 UTC.

yaml

name: monthly-link-audit
on:
  schedule:
    - cron: '0 6 1 * *'
  workflow_dispatch: {}
jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Overview (free)
        run: |
          curl -fsS "https://seoblogbot.com/api.php?action=overview&q=example.com" > overview.json
      - name: Refdomains (2 credits)
        env:
          SBB_KEY: ${{ secrets.SBB_KEY }}
        run: |
          curl -fsS -H "Authorization: Bearer $SBB_KEY" \
            "https://seoblogbot.com/api.php?action=refdomains&q=example.com&per=500" > refdomains.json
      - name: Log credits
        run: jq -r '._credits' refdomains.json >> credits.log

Що йде не так і що показує журнал

Симптом	Ймовірна причина	Перший крок
HTTP 401	Секрет відсутній або оновлений	Створіть секрет знову, запустіть workflow_dispatch
HTTP 402	Закінчилися кредити	Поповніть з сторінки облікового запису, запустіть знову
Порожні рядки для відомого сайту	Оновлення індексу в процесі або одрук в домені	Повторіть спробу через день; перевірте наявність `www.`
Рейтинг змістився на кілька балів	Щомісячне оновлення	Нічого не робити; дивіться на тренд
Рейтинг впав на 10+	Втрачені посилання або велика зміна оновлення	Витягніть `refdomains` та зробіть diff

Cron на звичайному сервері

Ті ж самі команди виконуються з рядка crontab. Збережіть ключ у файлі середовища, який може читати лише користувач роботи, та журналюйте у файл, який ви обрізаєте.

Кам'яні терези з одним важким грузом та порожньою чашею в пастельному освітленні

Витрати та де їх прочитати

Щомісячний аудит для одного сайту коштує 4 кредити, коли ви витягуєте обидва списки, що становить $0.0004. Виклик огляду безкоштовний. Місяць без змін тому коштує нічого, крім цього.

Якщо ваша команда публікує десять публікацій на день на кількох сайтах, аудит все одно є однією щомісячною роботою на сайт, а не однією роботою на публікацію. Це тримає кількість малою, а журнал читабельним.

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

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

Попросіть перший запуск надрукувати _credits. Довіряйте відповіді, а не будь-якій таблиці. Посібник воріт охоплює перевірку на стороні чернетки, яка передує цій.

Плановий запуск GitHub виконується в UTC, тому початок о 06:00 припадає на іншу годину для кожної команди. Запишіть часовий пояс у ручний процес, щоб ніхто не здивувався журналу.

Питання щодо запуску аудиту

Більшість цих питань надходять від команд, які щойно запланували роботу вперше.

Чи це google backlink checker API?

Це аудит, побудований на нашому власному API, а не продукт Google. Google не публікує загальний API зворотних посилань, тому цифри походять з нашого власного краулера та нашого власного індексу.

Чи може аудит виконуватися з кожною збіркою?

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

Чи мені все ще потрібен аудит, якщо у мене є ворота?

Так, якщо ви публікуєте через плагіни або CDN. Ворота бачать вашу чернетку, а аудит бачить живу сторінку. Кожна з них ловить відмови, які інша не бачить.

Що робити, якщо робота завершиться посередині?

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

Скільки кредитів я повинен запланувати на кожен сайт?

Заплануйте 4 кредити на сайт на місяць для двох платних витягів, плюс все, що витрачають ваші ворота на чернетках. Безкоштовний огляд нічого не додає до цієї цифри, а журнал показує реальну загальну суму.

Чому два запуски кілька днів поспіль не збігаються?

Індекс оновлюється приблизно раз на місяць, тому щоденні зміни зазвичай є шумом. Порівняйте знімок цього місяця з минулим місяцем, перш ніж відкривати інцидент.

Підписання ручного процесу

Секрет існує, і робочий процес один раз запущено вручну.
Файл журналу записує дату, URL, запити та _credits.
Хтось володіє каналом сповіщень.
Робота ставиться до щомісячних даних як до щомісячних.
Відмова самого аудиту сторінить людину.