Чек-лист приёмки сайта перед запуском: что проверить, чтобы не потерять заявки и поиск

Многие проблемы нового сайта не видны на макете. Это настройки, оставшиеся с тестового сервера: запрет индексации, формы, которые пишут на почту разработчика, счётчик аналитики, который не видит заявок. Ниже — чек-лист из шести блоков. Он пригодится разработчику перед сдачей проекта и владельцу, который принимает сайт у подрядчика.

Коротко: перед запуском проверьте шесть вещей.

1. Индексация: основной сайт открыт для поисковиков, тестовый сервер закрыт.
2. Адреса: одна версия домена на HTTPS, редиректы со старых страниц, честная страница 404.
3. Формы: каждая заявка сохраняется и доходит до ответственного.
4. Аналитика: просмотры считаются один раз, цель срабатывает только после успешной отправки.
5. Мобильная версия, скорость и превью ссылок в мессенджерах.
6. Доступы и бэкапы: всё оформлено на владельца, резервная копия восстанавливается.

Два прохода: на тестовом сервере и после переключения

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

До переключения, на тестовом адресе: формы, мобильная версия, тексты, страница 404, скорость, события аналитики в режиме отладки.

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

Тестовый сервер надёжнее закрывать паролем на уровне сервера, а не только запретом индексации: доступ к содержимому получат только авторизованные пользователи. После переноса всё равно проверьте настройки основного сайта — пароль сам по себе не удаляет noindex из CMS или конфигурации сервера.

1. Индексация: noindex, robots.txt, sitemap, canonical

На тестовом сервере индексацию обычно запрещают. Если запрет забыть снять, сайт работает, а в поиске его нет.

Что проверить на основном домене для страниц, которые должны попадать в поиск:

• В коде страниц нет тега meta name="robots" content="noindex".
• Сервер не отдаёт заголовок X-Robots-Tag: noindex. Его не видно в коде страницы, только в ответе сервера.
• В robots.txt нет строки Disallow: / для всех роботов.
• В sitemap только рабочие страницы основного домена: полные адреса с https, без тестового адреса и без страниц, закрытых от индексации.
• canonical указывает на предпочтительный адрес страницы на основном домене, а не на тестовый. Для самостоятельной страницы это обычно её собственный адрес; для дубля — адрес основной версии.

Не путайте robots.txt и noindex. robots.txt запрещает обход, но Google прямо пишет, что это не способ убрать страницу из поиска: запрещённый адрес всё равно может попасть в индекс, если на него ссылаются. А если страница закрыта в robots.txt, поисковик не увидит на ней noindex. Поэтому для тестового сервера лучше пароль, а на рабочем сайте страницы, которые должны быть в поиске, не закрывают ни тем, ни другим.

Проверить заголовки и robots.txt можно из терминала:

curl -sI https://example.com/ | grep -i x-robots-tag
curl -s https://example.com/robots.txt

Для страницы, которую нужно индексировать, в выводе первой команды не должно быть запрета noindex или none для Googlebot. Сам заголовок X-Robots-Tag допустим: он может задавать другие правила. Во втором ответе не должно быть Disallow: / для всех роботов. Затем откройте главную и пару типовых страниц в инструменте проверки URL в Search Console: он показывает, разрешены ли обход и индексация.

Sitemap отправьте в отчёте Sitemaps в Search Console и добавьте строку Sitemap: с полным адресом файла в robots.txt. В одном файле помещается до 50 000 адресов и до 50 МБ без сжатия, поэтому обычному сайту хватает одного файла (документация Google). Для canonical Google рекомендует абсолютные адреса, а не относительные.

2. Адреса: HTTPS, одна версия домена, редиректы, 404

• Все варианты адреса — с http и https, с www и без — ведут на одну основную версию постоянным редиректом 301 или 308, лучше за один шаг.
• Сертификат действует для обеих версий домена, с www и без, иначе часть посетителей увидит предупреждение браузера.
• На страницах нет смешанного контента: скриптов, стилей, шрифтов и встроенных фреймов по http. Браузеры блокируют такие запросы, и часть страницы просто не загрузится.
• Несуществующий адрес отвечает кодом 404 и показывает понятную страницу с навигацией. Если страница «не найдено» отвечает кодом 200, Search Console может отметить её как soft 404.

Цепочку редиректов удобно смотреть так:

curl -sIL http://www.example.com/ | grep -iE "^http|^location"

Для проверяемого адреса ожидается один ответ 301 или 308 с адресом основной версии и затем 200. Если редиректов два-три подряд, настройте сразу один переход на итоговый адрес.

Если новый сайт заменяет старый

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

Учебный пример карты редиректов:

Не отправляйте все старые страницы на главную: Google может посчитать такой редирект soft 404. Ставьте редирект сразу на итоговую страницу, без цепочек, и держите редиректы не меньше года. Это рекомендации из руководства Google по переезду сайта.

3. Формы: заявка сохраняется и доходит

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

Для каждой формы — обратной связи, заказа звонка, расчёта, подписки:

1. Отправьте заявку с телефона и с компьютера. Отметьте, куда она пришла и через сколько: почта, Telegram, CRM.
2. Проверьте, что заявка сохраняется на сайте или в CRM, даже если письмо не ушло. Уведомление — копия, а не единственное место хранения.
3. Убедитесь, что уведомления идут на рабочие адреса владельца, а не на почту разработчика или в тестовый чат.
4. Посмотрите, что видит человек после отправки: понятное подтверждение, а не пустую страницу. Повторное нажатие кнопки не должно создавать дубль.
5. Отправьте форму с ошибками: пустой телефон, неверная почта. Сообщение должно объяснять, что исправить, а уже введённые данные не должны стираться.
6. Проверьте, что защита от спама не мешает живым людям: отправьте форму с мобильного интернета и из браузера без входа в аккаунты.

Как организовать сохранение и обработку заявки, разобрали в статье о B2B-каталоге.

Письма-уведомления часто попадают в спам, если домен отправителя не настроен. Для доставки в личные ящики Gmail Google требует от отправителей SPF или DKIM и корректные DNS-записи, а от массовых отправителей — SPF и DKIM вместе, а также DMARC. Отправляйте уведомления через почтовый сервис с подтверждённым доменом и проверьте, куда письмо попадает в Gmail и в рабочей почте.

Для полей телефона и почты MDN рекомендует type="tel" и type="email", а атрибут inputmode подсказывает телефону, какую клавиатуру показать. Проверьте это на реальном смартфоне: вводить номер с буквенной клавиатуры неудобно.

Формы собирают персональные данные. Текст согласия и политику конфиденциальности согласуйте с юристом с учётом закона РК «О персональных данных и их защите».

4. Аналитика: визиты и заявки без дублей

• Счётчик стоит на всех страницах основного домена ровно один раз. Частая ошибка — код вставлен и напрямую, и через Google Tag Manager: тогда каждый просмотр считается дважды.
• Событие заявки срабатывает только после успешной отправки, а не по клику на кнопку. В GA4 для этого есть рекомендованное событие generate_lead — отправка формы или запроса информации (справка Google Analytics).
• События проверены в отчёте DebugView: он показывает данные в реальном времени, когда включён режим отладки (справка).
• Сайт подтверждён в Search Console, sitemap отправлен.
• Если используете Яндекс Метрику или пиксели рекламных систем, проверка та же: один код, цель только на успешную отправку.
• Тестовые заявки подписаны, например «ТЕСТ» в имени, и удалены из CRM, чтобы менеджеры не тратили на них время.

5. Мобильная версия, скорость и превью ссылок

Мобильная версия. Откройте сайт на реальных телефонах — iPhone с Safari и Android с Chrome — и в инструментах разработчика на ширине 360, 390 и 768 пикселей. Нет горизонтальной прокрутки, текст читается без увеличения, кнопки удобно нажимать пальцем, меню открывается и закрывается, номер телефона в шапке нажимается и запускает звонок, клавиатура не закрывает поле, в которое человек вводит данные.

Скорость. Проверьте главную и пару типовых страниц в PageSpeed Insights, начиная с мобильной версии. У нового сайта ещё нет данных реальных посетителей: они собираются за последние 28 дней и появляются, только когда трафика достаточно (документация PageSpeed Insights). Поэтому на запуске смотрите лабораторный тест. Ориентиры Google: LCP до 2,5 секунды, INP до 200 мс, CLS до 0,1 (web.dev). INP лабораторный тест не измеряет, вместо него там показан Total Blocking Time.

Типичные причины плохих цифр на запуске: тяжёлые изображения первого экрана, картинки без атрибутов width и height, из-за которых страница прыгает при загрузке, баннеры и формы, которые появляются поверх или над контентом (web.dev о сдвигах макета), лишние сторонние скрипты.

Превью ссылок. У каждой страницы свои title и description. Для мессенджеров и соцсетей задайте разметку Open Graph: протокол называет четыре обязательных свойства — og:title, og:type, og:image и og:url (ogp.me). Картинку превью указывайте полным адресом. Отправьте ссылку себе в мессенджер и посмотрите, как выглядит карточка. Делайте это до того, как ссылку начнут пересылать: мессенджеры запоминают превью и не всегда сразу обновляют его после правок.

Фавикон. Для показа в Google иконка должна быть квадратной и не меньше 8×8 пикселей, рекомендуется больше 48×48, а файл не должен быть закрыт от обхода (требования Google).

6. Доступы, бэкапы и уборка после разработки

• Домен оформлен на владельца или его компанию, а не на разработчика. Проверьте это в кабинете регистратора.
• Хостинг, DNS, почтовый сервис и платные подключения — на аккаунтах владельца. Есть список: что подключено, где, кто платит и когда продление.
• В админке у каждого свой аккаунт с нужными правами, без общего логина admin. Там, где можно, включена двухфакторная защита. Пароли передаются через менеджер паролей, а не сообщением в чате.
• Если сайт написан на заказ, код лежит в репозитории, к которому у владельца есть доступ.
• Резервные копии делаются автоматически и хранятся вне сервера сайта. Перед запуском один раз восстановите копию на тестовом сервере: копия, которую ни разу не восстанавливали, может подвести в нужный момент.
• Убраны следы разработки: тестовые страницы и заявки, временный текст-заполнитель, тестовые аккаунты, режим отладки (WP_DEBUG, APP_DEBUG и аналоги). Страницы ошибок не показывают технических подробностей.
• CMS, тема и плагины обновлены, неиспользуемые плагины удалены.

Полный чек-лист в одной таблице

Первая неделя после запуска

• Первые несколько дней отправляйте одну тестовую заявку в день и проверяйте, что она дошла.
• В Search Console смотрите отчёты об индексировании страниц и Sitemaps: нет ли ошибок и исключённых страниц, которые должны быть в поиске.
• Проверьте, какие несуществующие адреса запрашивают посетители: в логах сервера или в отчёте о страницах 404, если он настроен. Для старых адресов с трафиком добавьте редиректы.
• В аналитике не должно быть резких провалов или удвоенных цифр.
• Убедитесь, что первая автоматическая резервная копия создалась.
• Данные реальных посетителей в PageSpeed Insights появятся позже, когда наберётся трафик, — вернитесь к ним примерно через месяц.

Если сайт делаете не вы

Владельцу: попросите подрядчика пройти таблицу и прислать результат — скриншоты, вывод команд, список доступов. Это не вопрос недоверия: у каждого пункта есть понятный результат, его легко проверить вместе. Разработчику та же таблица помогает сдать проект без вопроса «почему не приходят заявки» через неделю.

В PIP проверка страниц, форм и мобильной версии входит в подготовку к запуску при разработке сайта, а среди результатов этапа запуска в процессе работы — инструкции и доступы.

Готовите запуск нового сайта? Расскажите о задаче — обсудим, что нужно сделать и в каком порядке.

Короткие подсказки для владельцев сайтов и веб-мастеров — в Telegram-канале @pip_kz.

Источники

• Google: как запретить индексацию с помощью noindex
• Google: введение в robots.txt
• Google: создание и отправка sitemap
• Google: переезд сайта со сменой адресов
• Google: требования к отправителям почты
• web.dev: Core Web Vitals
• Протокол Open Graph