Усі сценарії/ Розробник
Перевірка релізу на стейджингу до викладки
Реліз змінює шаблон, роутинг чи рендеринг — і через тиждень з'ясовується, що сторінки категорій отримали noindex, canonical вказує на стейджинг, а частина посилань веде на 404. Такі речі легко зловити до викладки, якщо порівняти сайт до і після.
- Хто
- Розробник, тімлід, QA, технічний SEO у продуктовій команді
- Сайт
- Застосунок або сайт із регулярними релізами й закритим стейджингом
- Що болить
- SEO-регресії видно лише після того, як впав трафік
- Що треба
- Перевірка перед кожною викладкою, без ручного перегляду сторінок
Кроки в Molfar
Дайте Molfar доступ до стейджингу
У «Налаштування › Запити» вкажіть логін і пароль Basic-автентифікації: кожен запит отримає заголовок Authorization. Там само можна додати свої заголовки, наприклад Accept-Language. Усе зберігається лише у файлі налаштувань на цьому комп'ютері.
Налаштування · Запити — документація (англійською)
На знімку: Старт сканування Окресліть межі сканування
Шаблони включення й виключення, глибина, параметри в адресах і піддомени задають, які адреси сканування може відвідати, — щоб перевіряти саме те, що змінює реліз.
Налаштування · Межі сканування — документація (англійською)
На знімку: Структура сайту Скануйте стейджинг до релізу
Перше сканування — точка відліку. Під час сканування видно етапи, правила robots.txt і останні прочитані сторінки.
Сканування — документація (англійською)
На знімку: Огляд після сканування Після релізу — звіт Release check
Коли реліз доїхав на стейджинг, проскануйте його знову. Звіт Release check відповідає на питання: що змінилося з минулого сканування і чи реліз щось зламав.
Звіти · Release check — документація (англійською)
На знімку: Історія сканувань Розберіть зміни сторінка за сторінкою
В «Історії» оберіть старіше (A) і новіше (B) сканування: що змінилося в порівнюваних полях і які перевірки погіршилися.
Історія — документація (англійською)На знімку: Історія сканувань Після деплою перевірте ключові сторінки
URL audit перевіряє одну адресу без сканування: статус, швидкість, що змінює JavaScript у title, canonical, meta robots і H1, і знімки на десктопі та як Googlebot smartphone.
URL audit — документація (англійською)
На знімку: URL audit Доручіть перевірку агенту
Через MCP ваш AI-агент може запустити сканування, дочекатися його й порівняти два сканування — усе у відкритому вікні Molfar, де ви бачите кожен крок.
MCP — документація (англійською)
На знімку: Підключення AI-агента (MCP)
Що ви отримаєте
Регресії до викладки
Що реліз змінив на стейджингу, ще до того, як це побачив Google.
Порівняння A і B
Зміни сторінка за сторінкою і перевірки, що погіршилися.
Контроль після деплою
Ключові сторінки продакшену перевірено одна за одною.
Що варто знати
- «Історія» порівнює сканування одного сайту: стейджинг порівнюється зі стейджингом, а не з продакшеном.
- Порівнювати варто сканування схожого обсягу: зміна меж чи ліміту між ними теж виглядатиме як зміна сайту.
- Перемикач MCP може бути закритий для вашого акаунта; замок пояснює, що його відкриває.
Питання
- Стейджинг закритий не паролем, а VPN. Це працює?
- Molfar сканує з вашого комп'ютера, тож бачить те, що бачить ваш комп'ютер, коли VPN увімкнено.
- Це можна вбудувати в CI?
- Molfar — десктопний застосунок, а не CLI для CI. Але AI-агент на вашому комп'ютері може запускати перевірку через MCP.
- Чи зачепить сканування продакшен?
- Ні, якщо межі сканування обмежують його стейджингом. Темп запитів задається в налаштуваннях сканування.