Чому я більше не тримаю власний сервер для перевірки сторінок

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

Мені не подобається дізнаватися про такі зміни через кілька тижнів із графіка органічного трафіку. Сьогодні зміни потрапляють на сайт різними шляхами: через релізи, експерименти, конструктори й робочі процеси з ШІ. Часто це допомагає. Але важливу зміну стало легше внести й не помітити, до чого вона призвела. Я хотів дізнаватися про неї раніше.

Мені потрібен був монітор, а не ще один сервер

Раніше я розв’язував подібні задачі на власних серверах і надсилав сповіщення через Telegram-ботів. Це працювало. У мене є і складніший Page Guardian для ситуацій, де потрібно більше логіки та контролю. Але не кожна перевірка потребує такої системи.

Page Guardian Lite - спрощена версія для швидких і зрозумілих перевірок: невеликий список важливих сторінок, кілька базових SEO-сигналів і коротке повідомлення про результат. Коли нічого складнішого не потрібно, я не хочу заради цього підтримувати окремий сервер, стежити за його середовищем і ще й помічати, коли сам монітор перестав запускатися.

Для цієї лайт-версії я вибрав простішу схему. Це невелика програма на TypeScript зі списком сторінок та очікуваних SEO-сигналів. Для кожного URL можна задати потрібний HTTP-статус, title, H1, канонічне посилання, метатег robots або description. Програма може отримати HTML напряму або відкрити сторінку в браузері - з JavaScript чи без нього.

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

Це привід перевірити сторінку, а не автоматичний висновок про вплив на SEO. Зникнення блоку не доводить, що позиції впадуть. А помилка під час перевірки в GitHub Actions ще не означає, що таку саму помилку бачать усі відвідувачі.

Що робить GitHub Actions

Код, налаштування й розклад лежать у GitHub-репозиторії. Коли спрацьовує розклад, GitHub Actions запускає тимчасове середовище, встановлює залежності та браузер, перевіряє сторінки й завершує роботу. Результат бот надсилає у Slack. Попередній знімок зберігається в окремій гілці репозиторію, щоб наступний запуск мав із чим порівнювати. Мені не потрібно тримати власну машину ввімкненою між перевірками.

Є і компроміс. Запуск за розкладом не гарантований до хвилини: він може запізнитися або зрідка не відбутися. Але для мене не принципово, чи прийде звіт о 21:00 або о 22:33. Мені важливо регулярно бачити стан сторінок, а не отримувати сповіщення в точну хвилину, тому такі затримки мене влаштовують.

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

Як спробувати на своїх сторінках

Початок короткий: завантажити код у власний приватний репозиторій, замінити URL із прикладу та очікувані значення, додати дані Slack-бота до секретів репозиторію. Потім зробити тестовий запуск без повідомлення в Slack, перевірити результат і лише після робочого запуску ввімкнути розклад. Докладні кроки є в README. Там також є запит для ШІ-помічника, який може провести вас через налаштування.

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

Я не чекаю від цього інструмента пояснення кожного коливання трафіку. Він відповідає на вужче, але корисне запитання: чи не стала важлива сторінка непомітно іншою, ніж ми планували?

Думаю, Page Guardian Lite буде корисним невеликим компаніям, які не хочуть багато витрачати на інструменти моніторингу, а також спеціалістам і агенціям, що працюють із багатьма невеликими клієнтами.

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