Как принять сайт у разработчика после создания

Принять сайт у разработчика за пятнадцать минут по ссылке «всё готово, посмотрите» — самый дорогой способ сэкономить время: через полгода выясняется, что домен оформлен на студию, в robots.txt с этапа разработки висит Disallow: /, а заявки с формы уходят на почту уволившегося менеджера. Ко мне такие сайты приходят пачками, и почти всегда владелец говорит одну и ту же фразу: «мы же всё смотрели, всё работало». Смотрели картинку. Приёмка — это не просмотр главной страницы с ноутбука, а формальная процедура с чек-листом, командами в терминале и подписью под актом только после того, как каждый пункт закрыт.

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

Почему приёмка — отдельная работа, а не формальность

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

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

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

Что должно быть в договоре до начала работ

Половина конфликтов при приёмке решается не на приёмке, а за два месяца до неё — на этапе подписания договора. Если в договоре нет пункта про передачу исходников, никакой чек-лист не заставит подрядчика их отдать.

• Домен регистрируется на заказчика (юрлицо или физлицо владельца), а не на подрядчика. Прописывается прямо: «доменное имя регистрируется на имя Заказчика».
• Хостинг оформляется на реквизиты и почту заказчика; подрядчик получает доступ как пользователь, а не как владелец аккаунта.
• Исключительные права на дизайн-макеты, вёрстку и написанный код передаются заказчику после оплаты — с формулировкой про отчуждение исключительного права, а не «предоставление права использования».
• Перечень передаваемых материалов: исходники макетов (Figma или PSD), архив файлов сайта, дамп базы данных, список используемых сторонних сервисов и лицензий.
• Лицензии на изображения и шрифты: указывается источник каждой платной картинки и на кого оформлена лицензия. Бесплатные стоки тоже фиксируются — с названием и ссылкой.
• Критерии приёмки: сайт открыт для индексации, отдаёт код 200, формы доставляют письма, счётчик установлен. Лучше приложить чек-лист отдельным приложением к договору.
• Гарантийный срок на устранение ошибок: обычно от одного до трёх месяцев, бесплатно, с описанием, что считается ошибкой, а что доработкой.
• Порядок передачи доступов: в течение скольких дней после подписания акта и в каком виде.

Если договор уже подписан без этих пунктов, всё равно проходите чек-лист. Просто рычагов будет меньше, и главный из них — остаток оплаты.

Доступы и права: с чего начинается приёмка

Первое, что забирают, — доступы. Не потому что подрядчик обязательно недобросовестный, а потому что через год он может закрыть ИП, сменить почту или просто перестать отвечать. Сайт, к которому нет доступов, ремонту не подлежит — его переделывают заново.

Актив	Что именно передаётся	На кого оформлено
Домен	Логин и пароль от личного кабинета регистратора	Владелец бизнеса или его юрлицо
Хостинг или сервер	Панель управления, доступ по SSH или FTP	Компания-заказчик, оплата с её карты или счёта
Админка сайта	Отдельная учётная запись с ролью администратора	Почта владельца, не общая почта студии
База данных	Хост, имя базы, пользователь, пароль, свежий дамп	Доступ через панель хостинга
Исходники	Макеты Figma или PSD, архив файлов сайта	Копия на стороне заказчика
Почта сайта	Ящик, с которого уходят письма форм, и куда приходят заявки	Корпоративный домен заказчика
Аналитика	Метрика, Вебмастер, Search Console — права владельца	Аккаунт владельца, подрядчик — гость
Лицензии	Список платных плагинов, тем, шрифтов, фото с ключами	Заказчик как лицензиат

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

Домен и хостинг: чьи они на самом деле

Домен — единственный актив сайта, который нельзя восстановить или переделать. Файлы можно скачать, тексты переписать, дизайн перерисовать. Домен с накопленной историей в поиске и в рекламе уникален.

Проверка занимает минуту: откройте сервис whois по своему домену и посмотрите поля с администратором и датой окончания регистрации. Для доменов в зонах .ru и .рф персональные данные скрыты, но поле «Тип» покажет, физлицо это или организация, а поле organization для юрлиц выводится открыто. Если в whois значится название студии — домен не ваш, независимо от того, что написано в счёте.

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

• дату окончания регистрации — до неё должно оставаться не меньше нескольких месяцев;
• включено ли автопродление и привязана ли к нему ваша карта;
• на какую почту приходят уведомления регистратора: доступ к этой почте должен быть у вас;
• записи DNS — куда указывают A-запись и MX-записи почты.

С хостингом та же логика. Аккаунт должен быть оформлен на компанию, оплачиваться с её счёта, а уведомления о продлении приходить на почту, которую читают. Хостинг, оплаченный подрядчиком «пакетом на всех клиентов», означает, что ваш сайт живёт на чужом аккаунте и выключается вместе с отношениями.

Индексация: самая частая и самая дорогая ошибка

Из всех дефектов приёмки закрытая индексация обходится дороже всего, потому что она не видна вообще никак. Сайт открывается, работает, красиво выглядит — и не существует для поиска. Проблема всплывает через два-три месяца, когда владелец замечает, что переходов из поиска нет, а к этому времени уже потеряно всё время, которое сайт мог набирать возраст и позиции.

Закрыть сайт от индексации можно четырьмя независимыми способами, и каждый из них проверяется отдельно. Ни один не отменяет остальных: сайт может быть открыт в robots.txt и при этом закрыт мета-тегом.

Подробнее об этом — в статье «Почему сайт не продвигается».

1. Запрет в robots.txt

На этапе разработки в файл почти всегда кладут две строки, запрещающие обход всего сайта. Проверка:

curl -s https://site.ru/robots.txt

В ответе не должно быть Disallow: / под User-agent: *. Запрещать можно служебные каталоги, поиск по сайту, страницы корзины и личного кабинета — но не сайт целиком. Заодно посмотрите, указан ли в файле адрес карты сайта строкой Sitemap: с полным https-адресом.

2. Мета-тег noindex в коде страниц

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

curl -s https://site.ru/ | grep -i "noindex"

Помогу с продвижением: SEO-продвижение от Анатолия Кузнецова — вывожу сайты в топ Яндекса белыми методами.

Пустой вывод — хорошо. Если строка нашлась, смотрите, что именно закрыто: тег вида <meta name="robots" content="noindex, nofollow"> на посадочной странице недопустим, а на странице «спасибо за заявку» или на результатах поиска по сайту он уместен.

3. Галочка в настройках WordPress

В WordPress есть отдельный переключатель: «Настройки» — «Чтение» — «Попросить поисковые системы не индексировать сайт». Если он включён, движок сам добавит noindex во все страницы, и никакой SEO-плагин это не перебьёт. Заходите в админку и снимаете галочку лично, а не спрашиваете «а вы сняли?».

4. Заголовок X-Robots-Tag и пароль от разработки

Самый неочевидный вариант: запрет отдаётся не в HTML, а в заголовках ответа сервера. В коде страницы его не видно, поисковый робот его читает. Проверка одной командой:

curl -I https://site.ru/ | grep -i robots

Ответ должен быть пустым. Если выводится X-Robots-Tag: noindex, сайт закрыт на уровне сервера — ищите директиву в конфигурации nginx, в .htaccess или в коде движка.

Туда же — HTTP-авторизация, которой закрывают тестовую площадку. Если сервер отвечает кодом 401 и просит логин с паролем, сайт недоступен ни людям, ни роботам. Проверяется первой строкой ответа:

curl -sI https://site.ru/ | head -1

5. Карта сайта

Sitemap должен открываться по прямому адресу, отдавать код 200 и содержать реальные адреса. Быстрый счёт количества ссылок:

curl -s https://site.ru/sitemap.xml | grep -c "<loc>"

Если число заметно меньше количества страниц сайта — карта собрана неполно. Если в карте попадаются адреса с http вместо https, с www при основном зеркале без www или страницы, закрытые в robots.txt, — карту переделывают.

Техника: один адрес, коды ответа, скорость

Сайт должен открываться по одному-единственному адресу. Все остальные варианты — с www и без, по http и по https, со слешем на конце и без него — должны вести на основной 301-м редиректом. Иначе поисковик видит несколько копий одного сайта и делит между ними сигналы.

Проверка всех четырёх вариантов одной командой:

for u in http://site.ru http://www.site.ru https://site.ru https://www.site.ru; do echo -n "$u -> "; curl -sI "$u" | head -1; done

Три из четырёх должны отдавать 301, один — 200. Причём редирект должен быть сразу на конечный адрес, а не цепочкой из двух-трёх переходов. Цепочку видно с ключом -L:

Тему разбирал отдельно: «Как проверить сайт перед покупкой».

curl -sIL http://www.site.ru/ | grep -i "^HTTP\|^location"

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

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

curl -o /dev/null -s -w "код %{http_code}, ответ %{time_starttransfer} c\n" https://site.ru/

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

Коды ответа сервера и что они означают на приёмке

Код	Что означает	Норма на приёмке
200	Страница отдаётся нормально	Все рабочие страницы сайта
301	Постоянный редирект	Зеркала www и http, старые адреса при переносе
302	Временный редирект	Недопустим для склейки зеркал
401	Требуется авторизация	Недопустим: сайт закрыт паролем разработки
403	Доступ запрещён	Только для служебных каталогов
404	Страница не найдена	Только для несуществующих адресов, с оформленной страницей
500, 502, 503	Ошибка на стороне сервера	Недопустим ни на одной странице

Отдельно проверьте несуществующий адрес: наберите в браузере site.ru/proverka-404. Сервер должен вернуть именно код 404, а не 200 с текстом «страница не найдена» — второй вариант плодит бесконечные пустые страницы в индексе. Сама страница 404 должна быть оформлена в дизайне сайта, с меню, поиском и ссылкой на главную, а не показывать белый экран с системной надписью.

Содержание страниц: title, description, h1, alt

Разработчик редко считает мета-теги своей зоной ответственности, и в итоге на всех страницах стоит одинаковый title вида «Главная — Сайт» либо шаблон из названия движка. Для поиска это означает, что все страницы выглядят одинаково.

• Title. Уникальный на каждой странице, содержит суть страницы. Проверяется быстро: curl -s https://site.ru/uslugi/ | grep -o "<title>.*</title>" для нескольких разных адресов подряд — значения должны отличаться.
• Description. Тоже уникальный. Пустой description не смертелен, одинаковый на весь сайт — хуже.
• Заголовок h1. Ровно один на страницу. Часто дизайнер оформляет логотип или слоган тегом h1, и тогда на всех страницах заголовок одинаковый. Считается командой: curl -s https://site.ru/ | grep -c "<h1", результат должен быть 1.
• Атрибут alt у изображений. Должен быть заполнен осмысленным текстом. Пустые alt на карточках товаров и в галерее — потерянный трафик из поиска по картинкам.
• Тексты. Никакой «рыбы». Поищите на сайте слово Lorem: curl -s https://site.ru/ | grep -i lorem. Тот же приём — поиск фраз «текст о компании», «здесь будет описание», «телефон: 8 (800) 000-00-00».
• Контакты. Реальный телефон, реальный адрес, реальные реквизиты, а не заглушки из демо-данных темы.

Отдельная проверка — демо-контент. Темы для WordPress ставятся вместе с примерами: чужие товары, посты «Hello world», страница «Пример страницы», карточки сотрудников с фотографиями из стока. Всё это индексируется наравне с настоящими страницами.

Изображения: вес, формат, размеры

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

Что смотреть:

• вес отдельной картинки в блоке контента — обычно достаточно 100–200 КБ, для фона первого экрана чуть больше;
• формат: WebP или AVIF вместо JPEG и PNG там, где это возможно;
• реальные размеры: если картинка выводится в блоке шириной 400 пикселей, файл шириной 4000 пикселей грузится впустую;
• отложенная загрузка для картинок ниже первого экрана;
• явно заданные ширина и высота, чтобы вёрстка не прыгала при загрузке.

Быстрая проверка веса конкретного файла без скачивания:

curl -sI https://site.ru/wp-content/uploads/2026/08/foto.jpg | grep -i content-length

Если нужна помощь по теме — создание сайтов.

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

Мобильная версия: проверять только на реальном телефоне

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

• Горизонтальная прокрутка. Её быть не должно ни на одной странице. Чаще всего вылезает из-за широкой таблицы, длинного адреса почты без переносов или блока с фиксированной шириной в пикселях.
• Кнопки. Нажимаются пальцем с первого раза, не наезжают друг на друга, не прячутся под плавающими элементами вроде виджета чата.
• Меню. Открывается, закрывается, прокручивается, если пунктов много, и не перекрывает контент навсегда.
• Формы. Поля заполняются, клавиатура не закрывает кнопку отправки, для телефона всплывает цифровая клавиатура, для почты — с символом собаки.
• Телефон кликабелен. Номер обёрнут ссылкой tel:, по нажатию открывается звонилка. Адрес почты — ссылкой mailto:.
• Размер шрифта. Основной текст читается без увеличения пальцами.
• Всплывающие окна. Закрываются крестиком, который попадает в палец, а не в пиксель.

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

Смежный материал по теме — «Нулевые заходы на сайт в Яндекс Метрике».

Формы и аналитика: заявка обязана дойти

Самый простой и самый пропускаемый пункт приёмки. Разработчик пишет «форма настроена», владелец верит. Проверять надо лично, со своего телефона, отправив настоящую заявку с настоящими данными.

1. Отправьте заявку с телефона, заполнив все поля так, как это сделал бы клиент.
2. Убедитесь, что после отправки показывается понятное сообщение об успехе, а не пустой экран.
3. Откройте почту, на которую должны падать заявки, и найдите письмо. Не в папке «Спам», а во «Входящих».
4. Проверьте, что в письме есть все заполненные поля, а не только имя.
5. Повторите то же самое для каждой формы на сайте: обратный звонок, форма в подвале, форма в модальном окне, форма на странице контактов, расчёт стоимости.
6. Проверьте почту получателя: заявки должны идти на действующий корпоративный ящик, а не на личную почту разработчика или на ящик, который никто не открывает.

Если письма падают в спам, причина обычно в отправке с адреса, не принадлежащего домену сайта. Лечится настройкой записей SPF и DKIM для домена и отправкой писем через SMTP собственной почты, а не встроенной функцией движка.

По аналитике на момент приёмки должно быть готово:

• счётчик Яндекс.Метрики установлен на всех страницах, включая страницу «спасибо» и карточки товаров;
• в счётчике включены вебвизор и карта скроллинга, чтобы потом было что анализировать;
• настроены цели: отправка каждой формы, клик по номеру телефона, клик по мессенджеру;
• цели проверены живой заявкой — конверсия видна в отчёте, а не «должна работать»;
• сайт добавлен и подтверждён в Яндекс.Вебмастере, там же указан регион и загружен sitemap;
• сайт добавлен и подтверждён в Google Search Console, карта сайта отправлена;
• права владельца во всех сервисах — у вас, подрядчику выдан гостевой доступ.

Безопасность и резервные копии

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

• Версия движка и плагинов. Обновлены на момент сдачи. Плагин, который не обновлялся годами, — открытая дверь.
• Список пользователей. В админке не должно остаться учётных записей подрядчика, тестовых аккаунтов, пользователя admin с паролем из демо. Роль администратора — только у тех, кому она нужна.
• Резервное копирование. Настроено автоматически, копии складываются не на тот же сервер, где живёт сайт, а во внешнее хранилище. Проверьте, что копия действительно создаётся и что вы умеете её развернуть.
• Служебные файлы. Закрыты от посторонних: архивы вида backup.zip, дампы базы dump.sql, файлы конфигурации, папки .git, страницы установки движка. Быстрая проверка — попробуйте открыть эти адреса в браузере, сервер должен отдать 403 или 404.
• Пароли. Все выданные вам пароли смените сразу после приёмки, включая доступ к базе и панели хостинга.
• Отладочный режим. Выключен. На страницах не должно быть предупреждений PHP и сообщений о недостающих переменных.

Сводный чек-лист приёмки по группам

Группа	Что проверяем	Чем проверяем	Норма
Доступы	Домен, хостинг, админка, база, исходники	Личный вход под своими данными	Всё открывается лично, без посредников
Индексация	robots.txt, noindex, галочка в WordPress, X-Robots-Tag	curl -I URL | grep -i robots	Запретов нет, sitemap отдаётся
Техника	Одно зеркало, сертификат, коды ответа, скорость	curl -sI, замер time_starttransfer	200 на рабочих, 301 на зеркалах, ответ до 0,5 с
Содержание	title, description, h1, alt, тексты	Просмотр кода, grep по страницам	Уникально, один h1, без «рыбы»
Мобильная	Прокрутка, кнопки, меню, формы, tel-ссылка	Реальный телефон, два браузера	Ничего не уезжает, всё нажимается
Формы	Доставка письма, содержимое, папка «Входящие»	Личная тестовая заявка	Письмо дошло со всеми полями
Аналитика	Метрика, цели, Вебмастер, Search Console, регион	Отчёты сервисов после тестовой заявки	Визит и цель зафиксированы
Безопасность	Обновления, пользователи, бэкапы, служебные файлы	Админка, панель хостинга, браузер	Чисто, копии создаются, лишних админов нет

Типичные проблемы и как их поймать за минуту

Проблема	Как проявляется	Проверка
Сайт закрыт в robots.txt	Нет переходов из поиска, страниц нет в индексе	curl -s https://site.ru/robots.txt
Мета-тег noindex	То же, но robots.txt чистый	curl -s URL | grep -i noindex
Запрет в заголовках сервера	Код страницы чистый, робот всё равно не берёт	curl -I URL | grep -i robots
Пароль от разработки	Браузер просит логин, робот получает 401	curl -sI URL | head -1
Два зеркала одновременно	Сайт открыт и с www, и без, оба отдают 200	Перебор четырёх адресов через curl -sI
Мягкая 404	Любой адрес отдаёт 200 с текстом об ошибке	Открыть site.ru/proverka-404 и снять код
Форма не доставляет письма	Заявок нет, а трафик идёт	Личная заявка с телефона
Письма в спаме	Заявки находятся, но в отдельной папке	Проверить папку «Спам», настроить SPF и DKIM
Домен на подрядчике	Всплывает при попытке продлить или перенести	Whois по домену, вход в кабинет регистратора
Демо-контент	В поиске находятся «Пример страницы» и Lorem ipsum	grep -i lorem по страницам, просмотр списка записей
Тяжёлые картинки	Сайт долго грузится на мобильном интернете	curl -sI на файл, смотреть content-length
Одинаковые title	Все страницы в поиске выглядят одинаково	grep по title на нескольких адресах

Типичные отговорки подрядчиков и что отвечать

Что говорит подрядчик	Что это значит	Что отвечать
«Домен пусть пока полежит у нас, так удобнее продлевать»	Домен вам не принадлежит	Перенос на мой аккаунт до подписания акта, продление настрою сам
«Индексацию откроем после запуска рекламы»	Забыли снять запрет и не хотят признавать	Открыть сейчас, при мне, и показать чистый ответ curl
«Мета-теги — это уже SEO, в договор не входило»	Шаблонные title на всём сайте	Уникальные title и по одному h1 — часть работоспособности, не продвижения
«Формы точно работают, мы проверяли»	Проверяли на своей почте месяц назад	Отправляю заявку сейчас, при вас, и открываю свой ящик
«Скорость зависит от хостинга»	Не оптимизировали картинки и запросы	Замеряем время ответа на нескольких страницах и сравниваем
«На телефоне так и должно выглядеть»	Мобильную версию не проверяли на устройстве	Показываю горизонтальную прокрутку на своём телефоне
«Исходники макетов не отдаём, это наша база»	Привязка к себе на будущее	Права переданы по договору после оплаты, жду архив
«Метрику поставит ваш подрядчик по рекламе»	Счётчика нет, данных не будет	Счётчик и цели — часть сдачи, статистика нужна с первого дня
«Бэкапы делает хостинг»	Никто не проверял, есть ли они	Покажите последнюю копию и разверните её на тестовой площадке

Общий принцип разговора: не спорить о терминах, а просить показать результат на экране. Любой пункт чек-листа проверяется за минуту при вас, и это снимает спор без обсуждений.

Что делать, если сайт уже принят, а проблемы нашлись

Ситуация обычная: акт подписан, оплата прошла, через месяц выясняется, что сайт закрыт от индексации или домен на подрядчике. Порядок действий такой.

1. Зафиксировать состояние. Сохраните скриншоты, вывод команд curl, письма с обещаниями. Это понадобится и в переговорах, и в суде, если до него дойдёт.
2. Разделить дефекты на срочные и остальные. Срочные — закрытая индексация, неработающие формы, отсутствие доступов, дыры в безопасности. Их чинят немедленно, своими силами или силами другого специалиста, не дожидаясь ответа подрядчика.
3. Написать письменную претензию. С перечнем дефектов, ссылками на пункты договора и разумным сроком устранения. Устные договорённости в этой стадии не работают.
4. Отдельно решить вопрос с доменом. Если он на подрядчике, добивайтесь переноса. Если переговоры зашли в тупик, оцените, что дешевле: судиться или регистрировать новый домен и переносить сайт с настройкой редиректов.
5. Сменить все пароли, к которым у подрядчика был доступ: хостинг, админка, база, почта, аналитика. Даже при мирном расставании.
6. Проверить, что успело попасть в индекс. Если сайт какое-то время был открыт с демо-контентом или дублями, лишние страницы нужно закрыть и убрать из поиска.
7. Проверить и восстановить резервную копию. Убедитесь, что у вас есть свежий архив файлов и дамп базы, лежащие отдельно от хостинга.

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

Почему приёмку нельзя откладывать «на потом»

Аргумент «сначала запустимся, а проверим позже» звучит разумно и стоит дорого по нескольким причинам.

• Теряется время индексации. Новый сайт набирает доверие поиска месяцами. Каждый месяц с запретом в robots.txt — месяц, вычеркнутый из этого срока, который нельзя нагнать деньгами.
• Теряются заявки. Неработающая форма не сообщает о себе. Пока её не проверили, реклама льёт трафик, посетители жмут кнопку, а обращения не доходят.
• Пропадает рычаг. До подписания акта и финальной оплаты подрядчик заинтересован закрыть вопрос. После — исправления становятся новыми задачами по новым ценам.
• Копится техдолг. В сайт с неисправленной архитектурой добавляют страницы, тексты, интеграции. Через полгода правка, которая стоила час, требует переделки половины шаблонов.
• Разработчик уходит. Люди меняют работу, студии закрываются. Через год спрашивать будет не у кого, а без исходников и доступов сайт становится чёрным ящиком.
• Индексируется мусор. Демо-страницы, дубли с www, тестовый поддомен — всё это попадает в поиск и потом убирается неделями.

Как пройти приёмку за один день

Практический порядок, если нужно уложиться в один рабочий день и не потерять ни одного пункта.

1. Утро: доступы. Заходите лично в кабинет регистратора, панель хостинга, админку, скачиваете дамп базы и архив файлов себе.
2. Дальше: индексация. Четыре проверки подряд — robots.txt, noindex в коде, галочка в настройках, заголовки сервера. Плюс sitemap.
3. Техника: перебор четырёх адресов сайта, замер времени ответа на четырёх типах страниц, проверка 404 и цепочек редиректов.
4. Содержание: выборочно десять страниц разных типов — title, description, h1, alt, отсутствие «рыбы».
5. Обед и телефон: проходите сайт целиком с мобильного, отправляете заявки со всех форм.
6. После обеда: почта. Ищете письма во «Входящих», проверяете содержимое, смотрите отчёты Метрики — визит и достижение цели.
7. Вечер: безопасность. Список пользователей, версии, бэкапы, служебные файлы.
8. Финал: письмо подрядчику со списком найденного и сроком. Акт подписывается после закрытия списка.

Один день внимательной работы на этом этапе экономит месяцы разбирательств и потерянного трафика.

Частые вопросы

Можно ли принимать сайт по частям, не дожидаясь полной готовности?

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

Что делать, если разработчик отказывается передавать домен?

Сначала письменно, со ссылкой на пункт договора об оформлении домена на заказчика. Если пункта в договоре нет, а домен зарегистрирован на подрядчика, юридически он принадлежит ему. Тогда остаётся договариваться о выкупе или переносе, а параллельно оценивать вариант с новым доменом. Уроком на будущее: домен всегда регистрируется первым и сразу на владельца бизнеса, ещё до выбора подрядчика.

Нужно ли привлекать стороннего специалиста для приёмки?

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

Сайт открывается медленно, но подрядчик говорит, что дело в хостинге. Как понять, кто прав?

Разделите два показателя. Время ответа сервера измеряется через curl и отражает работу хостинга и движка. Время полной загрузки зависит ещё и от веса картинок, скриптов и шрифтов. Если ответ сервера укладывается в полсекунды, а страница грузится долго, проблема во фронтенде и её решает разработчик. Если сервер отвечает две секунды на статической странице, вопрос действительно к хостингу или к запросам в базу.

Через сколько после приёмки сайт появится в поиске?

После того как сайт открыт для индексации, добавлен в Вебмастер и Search Console и карта сайта отправлена, первые страницы обычно попадают в индекс в течение нескольких недель. Полная индексация большого каталога занимает дольше. Ускорить помогает переобход по списку адресов в Вебмастере, внутренняя перелинковка и первые внешние упоминания. Главное условие остаётся тем же: ни одного запрета из четырёх, которые проверяются на приёмке.

Коротко

• Доступы забираются лично: домен на владельце, хостинг на компании, админка под своей учётной записью, дамп базы скачан себе.
• Индексация проверяется четырьмя независимыми способами — robots.txt, мета-тег, галочка в настройках движка и заголовок ответа сервера через curl -I URL | grep -i robots.
• Техническая часть сводится к трём вещам: одно зеркало вместо четырёх, код 200 на рабочих страницах и время ответа сервера до 0,5 секунды.
• Формы и мобильная версия проверяются только руками с реального телефона: заявка должна дойти во «Входящие» со всеми полями.
• Акт подписывается после закрытия чек-листа, а не до: после подписи каждая правка становится новой задачей с новым счётом.

Проверить сайт перед приёмкой можно через бесплатный аудит — отчёт приходит на почту.

2:29

Проверить сайт по этим пунктам разом можно через бесплатный аудит — отчёт приходит на почту.