Перші 30 днів після запуску сайту: що перевіряти та записувати

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

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

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

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

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

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

Окремо пройдіть незаповнені обов’язкові поля й повторне надсилання: помилка має бути зрозумілою, а повторний клік не повинен створювати плутанину. Деталі — у посібнику про поля та стани форми заявки. Після виправлення повторіть саме той сценарій, який не працював.

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

У підтвердженій властивості Search Console перевірте головну й ключові послуги через інструмент перевірки URL. Збережіть статус, дату останнього сканування та обрану Google канонічну адресу, якщо ці дані доступні. Звіт про індекс описує відому Google версію; перевірка опублікованої сторінки допомагає оцінити її поточну доступність.

Якщо потрібний URL недоступний або виключений помилково, передайте виконавцю адресу та точний статус. Нехай він перевірить відповідь сервера, випадкові обмеження індексації, canonical і sitemap на робочому домені. Закриті службові сторінки й демонстрації можуть бути виключені навмисно — відкривати для пошуку все підряд не потрібно.

Технічні передумови розібрані в посібнику про SEO до запуску. Після суттєвого виправлення можна запросити повторне сканування URL, але повторні запити не прискорюють його. Успішна перевірка не гарантує індексації, а індексація — високої позиції. Сім днів тут є точкою контролю, а не дедлайном Google.

За наявності даних відкрийте звіт ефективності Search Console: подивіться, які сторінки й запити мають покази та кліки. Показ означає видимість посилання в пошуку, клік — перехід із результатів. Жоден із цих показників не дорівнює заявці або продажу.

Виберіть однакові дати й фільтри для повторних переглядів. Окремо дивіться запити з назвою компанії та запити про послугу: вони відповідають на різні питання. Для нового сайту кількох показів або короткого періоду недостатньо, щоб оцінити попит чи зробити висновок про невдалу структуру.

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

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

Наприклад, відвідувачі запитують, чи входить вивезення сміття у прибирання. Це навчальна ситуація, не результат клієнтського проєкту XEVOR. Перша зміна — уточнити склад і виключення на сторінці послуги та біля звернення, а після публікації подивитися, чи стало менше таких непорозумінь.

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

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

Не закривайте задачу лише за повідомленням «виправлено». Повторіть дію на робочій адресі та зазначте результат. Дата публікації зміни допоможе не приписувати їй показники, зібрані раніше.

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

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

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

Надішліть XEVOR адресу сайту й опис задачі: що не працює, як це повторити та які зміни потрібні. Короткий журнал допоможе предметно обговорити роботи. Склад підтримки, платформа та можливість доробок узгоджуються після ознайомлення із сайтом.