Первые 30 дней после запуска сайта: что проверять и записывать

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

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

• Назначьте человека, который получает обращения и подтверждает тест.
• Запишите контакт исполнителя, канал сообщения о сбое и согласованное время реагирования.
• Укажите, у кого есть доступ к Search Console и к аналитике, если она подключена. Отсутствие инструмента тоже зафиксируйте.
• Согласуйте, кто может опубликовать исправление и вернуть рабочую версию, если изменение окажется неудачным.

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

Откройте главную и основные услуги на телефоне и компьютере без входа в аккаунт разработчика. Проверьте меню, языковые переходы, контакты и кнопки. Обратите внимание, не перекрывает ли форму клавиатура или закреплённая панель, читаются ли условия и загружаются ли изображения.

Отправьте согласованный тестовый запрос со своими тестовыми данными и явной пометкой «Тест». Проверьте сообщение на странице, получение в рабочей почте или CRM и возможность ответить. Если предусмотрено письмо клиенту, проверьте и его. Сообщение об успехе на экране само по себе не доказывает доставку.

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

Если начинаете привлекать платные переходы, используйте чек-лист лендинга перед рекламой. Он дополняет проверку соответствием объявления странице; этот месячный план не заменяет приёмку рекламного маршрута.

В подтверждённом ресурсе Search Console проверьте главную и ключевые услуги через инструмент проверки URL. Сохраните статус, дату последнего сканирования и выбранный Google канонический адрес, если эти данные доступны. Отчёт об индексе описывает известную Google версию; проверка опубликованной страницы помогает оценить её текущую доступность.

Если нужный URL недоступен или исключён по ошибке, передайте исполнителю адрес и точный статус. Пусть он проверит ответ сервера, случайные ограничения индексации, canonical и sitemap на рабочем домене. Закрытые служебные страницы и демонстрации могут быть исключены намеренно — открывать для поиска всё подряд не нужно.

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

При наличии данных откройте отчёт об эффективности Search Console: посмотрите, у каких страниц и запросов есть показы и клики. Показ означает видимость ссылки в поиске, клик — переход из результатов. Ни один из этих показателей не равен заявке или продаже.

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

Если аналитика подключена, сверьте согласованные события с контрольным обращением. Нажатие кнопки, принятая форма и полученное письмо — разные события. Отмечайте тесты и учитывайте ограничения сбора данных. Если аналитики нет, ведите учёт полученных обращений без предположений об источнике; не вычисляйте конверсию из несовместимых наборов данных.

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

Например, посетители спрашивают, входит ли вывоз мусора в уборку. Это учебная ситуация, а не результат клиентского проекта XEVOR. Первое изменение — уточнить состав и исключения на странице услуги и рядом с обращением, а после публикации посмотреть, стало ли меньше таких недоразумений.

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

Для каждой записи нужны дата, URL или сценарий, фактический результат, влияние на клиента, ответственный и повторная проверка. Ниже — условные примеры, а не данные студии. Скриншоты ошибок добавляйте без контактов и текстов реальных заявок.

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

• Сайт или основное действие не работают — нужны диагностика и исправление, а не ожидание нового отчёта.
• Ключевые страницы не индексируются — разберите конкретные статусы и технические причины; одним количеством статей это не исправить.
• Есть релевантные переходы, но люди не понимают условия — проверьте содержание, путь к обращению и работу формы.
• Обращения приходят, но разговор не продолжается — пересмотрите ответ команды, соответствие услуги и ожидания клиента.
• Данных ещё мало — продолжите наблюдение и план привлечения аудитории. Отсутствие заявок само по себе не является основанием для полного редизайна.

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

План проверок и технических доработок можно обсудить в рамках поддержки сайта. Если наблюдения показали потребность в другом наборе страниц и сценариях, сначала определите объём редизайна. Для нового проекта заложите этот период в план разработки сайта для бизнеса ещё до запуска.

Отправьте XEVOR адрес сайта и описание задачи: что не работает, как это повторить и какие изменения нужны. Короткий журнал поможет предметно обсудить работы. Состав поддержки, платформа и возможность доработок согласуются после знакомства с сайтом.