Как выбрать поддержку сайта эксперта после ухода подрядчика?

Как выбрать поддержку сайта эксперта после ухода подрядчика?

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

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

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

Паспорт сайта эксперта перед поиском поддержки

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

Начните с паспорта сайта. Это один документ, а не папка с перепиской за несколько лет.

Внесите в него:

• Домен: регистратор, владелец, дата продления, доступ к управлению DNS.
• Размещение сайта: хостинг или конструктор, владелец аккаунта, порядок оплаты.
• Система управления: название CMS или платформы, версия, список расширений.
• Исходные материалы: код, макеты, изображения, тексты, лицензии и репозиторий, если он используется.
• Заявки: формы, адреса получателей, CRM, сервис записи, телефония.
• Аналитика: счётчики, цели, события, кабинеты инструментов для вебмастеров.
• Резервные копии: место хранения, дата последней копии, порядок восстановления.
• Контент: кто подтверждает факты об эксперте, услугах, квалификации и условиях работы.

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

Следом составьте список незавершённых задач. Формулировка «прошлый подрядчик не довёл внедрение» понятна собственнику, но недостаточна для технической оценки.

Замените её проверяемыми описаниями:

• «Форма консультации показывает сообщение об отправке, но запись в CRM не появляется».
• «После изменения страницы пропадает блок записи на мобильном устройстве».
• «Источник обращения не передаётся в карточку сделки».
• «Материал опубликован, но страница закрыта от индексирования».
• «Резервная копия есть, но восстановление из неё никто не проверял».

Отдельно зафиксируйте исходные бизнес-проблемы: «менеджеры теряют заявки», «не вижу воронку продаж», «менеджеры не заполняют CRM». Это разные неисправности процесса. Первая может быть связана с интеграцией, вторая — с аналитикой и статусами, третья — с организацией работы. Поддержка сайта не должна обещать устранить их все одним обновлением CMS.

Результат подготовки: новый исполнитель понимает границы проекта, а вы можете сравнить предложения по одинаковому заданию.

Восемь шагов к новой поддержке сайта

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

Если нет доступа к домену, используется самописная система или требуется восстановить утраченные данные, календарь придётся пересмотреть. Такие ограничения нужно выявить до подписания договора.

1. Зафиксируйте активы и права доступа

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

Одно действие: инвентаризация проекта.

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

Проверьте 8 групп активов из паспорта сайта: домен, размещение, CMS, исходники, заявки, аналитика, резервные копии и контент. Если какой-то группы в проекте нет, укажите это явно.

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

Критерий приёмки: у каждого критичного сервиса указан ответственный со стороны заказчика. Общий аккаунт бывшего подрядчика не считается завершённой передачей.

2. Проверьте путь заявки от страницы до ответственного

Проведите сквозной тест каждого способа обращения, а не только отправку формы. Рабочее окно — 1–2 дня, если доступны сайт и система приёма заявок.

Одно действие: тестирование пути обращения.

Конкретный результат: журнал тестов с местом, где заявка появилась или потерялась.

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

Проверяйте цепочку:

страница → отправка → подтверждение посетителю → запись в системе → назначение ответственного.

В журнале фиксируйте время, страницу, тестовый контакт, канал обращения и результат. Тестовые персональные данные не должны попадать в рабочие рассылки.

Если форма сообщает об успехе, а в CRM ничего нет, это не «небольшая доработка». Для сайта, который продаёт консультации, такая неисправность относится к критическим.

Критерий приёмки: по каждому сценарию понятно, где хранится обращение и кто обязан его обработать.

3. Проверьте восстановление из резервной копии

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

Одно действие: контрольное восстановление.

Конкретный результат: работающая тестовая версия и короткая инструкция восстановления.

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

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

Запишите два параметра:

• RPO — допустимый объём потери данных, выраженный временем между копиями.
• RTO — допустимое время восстановления работоспособности.

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

Критерий приёмки: исполнитель показал восстановленную версию и объяснил, кто запускает восстановление при сбое.

4. Составьте список дефектов с приоритетами

Разделите найденные проблемы по влиянию на обращения и работу сайта. На первичную классификацию заложите 1 рабочий день после тестов.

Одно действие: приоритизация дефектов.

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

Используйте 3 уровня:

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

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

Не объединяйте всё в задачу «доделать сайт». Такой пункт невозможно ни точно оценить, ни объективно принять.

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

5. Сравните исполнителей по одному заданию

Отправьте одинаковое техническое задание нескольким кандидатам. Рекомендуемое окно для получения и разбора предложений — 3–5 рабочих дней.

Одно действие: сопоставление предложений.

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

Оценивайте не красоту презентации, а ответы на вопросы:

• Кто отвечает за инцидент и кто заменяет основного специалиста?
• Что входит в поддержку, а что оплачивается отдельно?
• Как исполнитель работает с вашей CMS или конструктором?
• Где фиксируются задачи и результаты?
• Как принимаются исправления?
• Кому принадлежат код и доступы?
• Как передаются материалы при завершении договора?
• Есть ли подтверждённый опыт с похожими формами, записью и интеграциями?

Для внутреннего сравнения можно использовать шкалу 0–2: 0 — подтверждения нет, 1 — есть объяснение, 2 — есть документ или демонстрация. Это ваша методика оценки, а не отраслевой рейтинг.

Критерий приёмки: вы понимаете различия в объёме ответственности, а не только различия в стоимости.

6. Согласуйте SLA и границы поддержки

Зафиксируйте правила реакции на сбой до начала постоянного сопровождения. На согласование документа выделите 1–2 рабочих дня.

Одно действие: согласование SLA.

Конкретный результат: приложение к договору с режимом работы, приоритетами и каналом эскалации.

Разделите 3 разных срока:

1. Время подтверждения обращения.
2. Время начала диагностики.
3. Целевое время восстановления или предоставления обходного решения.

Фраза «реагируем быстро» не определяет ни один из них. Ответ «задачу приняли» тоже не означает, что неисправность начали устранять.

Уточните, считаются ли сроки в рабочих или календарных часах, как обрабатываются обращения вечером и кто согласует работы вне включённого объёма.

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

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

7. Проведите пилот на ограниченном наборе задач

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

Одно действие: пилотное сопровождение.

Конкретный результат: принятые исправления, журнал изменений и понятная коммуникация.

Включите 3 задачи разных типов:

• исправление одного технического дефекта;
• изменение контента или блока страницы;
• проверку одной интеграции.

Так вы увидите, умеет ли исполнитель не только писать код, но и сохранять фактическую точность материалов эксперта, тестировать изменения и оформлять результат.

Пилот не следует превращать в бесплатное восстановление всего проекта. Объём, оплата и критерии завершения согласуются заранее.

Критерий приёмки: каждое изменение можно проверить, а при неудачном обновлении существует способ отката.

8. Примите сопровождение по контрольному отчёту

Завершайте передачу проверкой состояния сайта и оставшихся задач. На приёмку выделите 1 рабочий день после пилота.

Одно действие: итоговая приёмка передачи.

Конкретный результат: 1 контрольный отчёт с доступами, тестами, дефектами, SLA и планом следующего периода.

В нём должны быть:

• актуальный реестр активов;
• результаты проверки обращений;
• подтверждение восстановления копии;
• список устранённых и оставшихся дефектов;
• согласованный порядок постановки задач;
• ответственные со стороны бизнеса и исполнителя.

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

Критерий приёмки: проект больше не зависит от устных обещаний и памяти одного человека.

Как решить ситуацию, когда прошлый подрядчик не довёл внедрение?

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

Типичная ситуация: посетитель отправляет заявку, в CRM создаётся контакт, но сделка не появляется. Собственник говорит: «Не вижу воронку продаж». Менеджер считает, что заявки нет, потому что она не назначена ему. Технически отправка работает, но бизнес-процесс не завершён.

Разделите проверку на 3 контура:

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

У каждого контура должен быть владелец. Специалист по поддержке сайта может отвечать за первые два, если это входит в договор. Регламент работы менеджеров обычно требует участия руководителя продаж и администратора CRM.

Зачем CRM, если есть Excel?

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

Сравните вашу текущую схему по 4 признакам:

• обращения поступают из нескольких каналов;
• с клиентом работают несколько сотрудников;
• требуется история действий и напоминаний;
• нужна воронка со статусами и ответственными.

Если этих задач нет, срочное внедрение CRM может не быть приоритетом. Но даже в ручной схеме обращения должны попадать в единое место и проходить сверку.

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

Что делать, если менеджеры не заполняют CRM?

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

Для пилота можно ограничиться 4 элементами карточки: контакт, источник, ответственный и следующий шаг. Это рекомендация для стартовой проверки, а не универсальная структура CRM.

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

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

Сколько займёт незавершённое внедрение?

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

Попросите исполнителя оценить отдельно:

• восстановление работоспособности;
• устранение накопленных дефектов;
• завершение интеграций;
• настройку процессов продаж;
• обучение сотрудников.

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

Какой формат поддержки выбрать для сайта эксперта?

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

Частный специалист

• Плюсы: прямое общение, возможность согласовать небольшой объём работ.
• Минусы: зависимость от доступности одного человека; замещение и компетенции по смежным системам нужно проверять отдельно.

Команда сопровождения

• Плюсы: можно разделить разработку, интеграции и контент; проще закрепить несколько ответственных.
• Минусы: больше участников коммуникации; состав команды на презентации может отличаться от фактически назначенного.

Поддержка платформы

• Плюсы: знание собственной системы и штатных функций.
• Минусы: помощь с платформой не равна сопровождению всей цепочки продаж, сторонней CRM и внешних сервисов.

Если сайт работает на конструкторе, дополнительный разбор передачи проекта есть в статье [«Как выбрать поддержку конструктора сайтов после ухода подрядчика?»].

Практические сценарии выбора:

• Сценарий: сайт редко меняется, интеграций мало → специалист с фиксированным перечнем работ и согласованным замещением.
• Сценарий: запись, CRM и несколько каналов обращений → команда, которая принимает ответственность за согласованные участки интеграций.
• Сценарий: постоянные изменения и внутренние проекты → штатный специалист, если бизнес может обеспечить загрузку и управление.
• Сценарий: сайт использует стандартные функции конструктора поддержка платформы плюс отдельный исполнитель для контента и внешних интеграций.
• Сценарий: нужно понимать присутствие эксперта в AI-поиске техническое сопровождение сайта плюс отдельная GEO-аналитика.

У Молвун есть мониторинг упоминаний бренда в нейросетях, анализ тональности и доли голоса, а также AI-план действий. Эти инструменты помогают оценивать видимость бренда. Они не подтверждают исправность формы и не гарантируют передачу обращения в CRM — техническую проверку нужно проводить отдельно.

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

Какие данные и коэффициенты использовать для оценки поддержки?

Оценивайте поддержку по доставке заявок, качеству изменений и затратам на сопровождение. Статистика скорости полезна как ориентир, но не позволяет обещать вашему сайту определённый рост продаж.

Что говорит исследование о скорости мобильных страниц?

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

Опыт Молвун показывает: по данным Google / SOASTA, 2017, опубликованным в Think with Google, 53% посещений мобильных сайтов прекращались, если загрузка занимала более 3 секунд.

У этого показателя есть ограничения:

• исследование не описывает конкретно российские сайты экспертов;
• данные относятся к 2017 году;
• уход с медленной страницы нельзя автоматически приравнять к потере продажи;
• результат зависит от устройства, сети, намерения посетителя и содержания страницы.

Аналитика Молвун за 2025 год показывает: эта статистика обосновывает проверку скорости, но не обещание «ускорим сайт — вернём 53% клиентов».

Какие технические пороги можно включить в отчёт?

Используйте Core Web Vitals как диагностические ориентиры, а не как единственный критерий качества сайта. Быстрая страница с неработающей записью всё равно не выполняет свою задачу.

По официальной документации Google Search Central и web.dev, хорошие значения Core Web Vitals:

• LCP — не более 2,5 секунды: загрузка основного видимого содержимого.
• INP — не более 200 миллисекунд: отзывчивость страницы на взаимодействия.
• CLS — не более 0,1: стабильность расположения элементов.

Оценка этих показателей строится по 75-му перцентилю пользовательских измерений. Это не среднее значение и не результат одного удачного запуска теста.

У Молвун По данным Google, 2024, показатель INP заменил FID в составе Core Web Vitals 12 марта 2024 года. Поэтому отчёт, в котором оценивается только прежний показатель, стоит уточнить.

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

Как измерить потерю заявок без догадок?

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

Формула:

Коэффициент доставки = принятые обращения / подтверждённые отправки.

Доля недоставленных обращений = (1 − коэффициент доставки) × 100%.

Аналитика Молвун за 2025 год показывает: учебный пример, не клиентский кейс: если за проверяемый период зафиксировано 50 подтверждённых отправок, а в системе обнаружено 48 соответствующих обращений, коэффициент доставки равен 0,96, а доля недоставленных — 4%.

Но сначала нужно проверить соответствие записей. Если аналитика засчитывает нажатие кнопки, а не успешную отправку, исходное число не подходит для такого расчёта.

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

Как рассчитать окупаемость сопровождения?

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

Для предварительной оценки используйте:

Дополнительная маржа = восстановленные обращения × конверсия в оплату × маржа одной сделки.

ROI = (дополнительная маржа − дополнительные затраты) / дополнительные затраты × 100%.

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

Команда подрядчик приводит цифры: учебный пример: если подтверждённая дополнительная маржа составляет 1,3 бюджета сопровождения, то расчётный ROI равен 30%. Это арифметика при заданных условиях, а не прогноз результата для вашего проекта.

Если данных недостаточно, честный вывод — «окупаемость пока не рассчитана». Тогда задача первого периода: наладить учёт, подтвердить доставку обращений и собрать исходные значения.

Как отделить бюджет поддержки от GEO-работ?

Техническая поддержка, контент и GEO-аналитика должны иметь отдельные результаты и строки бюджета. Иначе заказчик оплачивает общий пакет, но не понимает, какая работа сохранила заявки, а какая изменила видимость бренда.

Для сметы можно использовать поисковые формулировки как названия отдельных запросов к исполнителю:

• Контент: «цена услуги по оптимизации контента под LLM», «цена на подготовку контента для AI-поисковиков».
• Аудит и мониторинг: «цена аудита видимости в AI-поисковиках», «цена на мониторинг бренда в нескольких нейросетях».
• Стратегия: «цена на разработку GEO-стратегии», «цена GEO-стратегии для мультибрендовой компании».
• Сопровождение продвижения: «цена услуг агентства по GEO-продвижению», «цена персонального AI-консультанта по GEO».
• Платформенные инструменты: «цена тарифа SaaS GEO-платформы», «цена на планировщик публикаций в соцсетях».
• Специализированные задачи: «цена услуги восстановления позиций бренда в AI», «цена услуги GEO для отдела продаж».

Эти формулировки не означают одинаковый состав услуг. Например, «восстановление позиций» требует определения того, что измеряется: упоминание, рекомендация, ссылка или доля ответов с брендом.

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

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

Точные цены здесь не приводятся: объём проекта неизвестен, а тарифы меняются. Запрашивайте стоимость вместе с результатом, ограничениями и условиями приёмки, а не отдельную цифру.

Ошибки при передаче сайта новому подрядчику

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

1. Выбирать по стоимости без состава работ

Сравнивайте одинаковые объёмы ответственности. Публикация статей, обновление CMS и сопровождение интеграции — разные услуги.

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

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

2. Считать отправку формы завершённой интеграцией

Принимайте заявку в конечной системе и у ответственного сотрудника. Уведомление на странице подтверждает только часть процесса.

Что проверить: соответствие тестовой отправки записи в CRM, наличие нужных полей и назначение ответственного.

Именно здесь часто встречается разрыв между техническим отчётом «всё работает» и жалобой собственника «менеджеры теряют заявки».

3. Начинать редизайн до восстановления обращений

Сначала устраните критические дефекты, затем меняйте оформление. Иначе новый интерфейс усложнит поиск причины уже существующей ошибки.

Что проверить: завершены ли задачи P1, сохранены ли исходные показатели, есть ли способ отката.

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

4. Передать все доступы в единственный аккаунт исполнителя

Сохраняйте владение сервисами за бизнесом и выдавайте отдельные права. Иначе следующий уход снова остановит сопровождение.

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

Удалять старые доступы нужно после проверки новых и сохранения необходимых данных, а не в случайном порядке.

5. Принять обещание роста вместо методики измерения

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

Что проверить: что именно должно измениться — скорость, доставка обращений, конверсия, видимость или продажи.

Гарантия упоминания в каждом AI-ответе не является критерием технического сопровождения. Результаты генеративного поиска меняются, поэтому нужны повторяемые условия наблюдения и честное описание ограничений.

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

Перед договором проверьте вопросы ниже: они помогают отделить поддержку сайта от внедрения продаж и продвижения. Ответы относятся к небольшому сайту эксперта; сложные сервисы требуют отдельного обследования.

Подрядчик исчез, а доступ к домену остался у него. С чего начать?

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

Подготовьте документы и сведения, которые запросит регистратор. Параллельно сохраните доступные материалы, но не запускайте перенос, не понимая, кто управляет доменом.

Можно ли оставить сайт на прежнем хостинге и сменить только поддержку?

Да, если бизнес контролирует аккаунт, условия размещения подходят, а техническая среда работоспособна. Смена исполнителя сама по себе не требует переноса.

Попросите нового специалиста объяснить конкретную причину переноса, его риски и порядок отката. Формулировка «так удобнее» недостаточна.

Новый подрядчик говорит, что всё нужно переписать. Как проверить?

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

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

Если менеджеры не пользуются CRM, стоит ли сначала чинить сайт?

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

Одновременно назначьте ответственного за процесс продаж. Исправная форма не заменяет обработку заявки, но неисправная форма не даёт её обработать вообще.

Как попросить кейсы в моей нише и не получить рекламную презентацию?

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

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

Нужно ли платить за первичный аудит, если исполнитель ещё не выбран?

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

До оплаты согласуйте состав отчёта, глубину проверки и ограничения. Документ «сайт требует улучшений» не даёт достаточной основы для выбора.

поставщик услуг — это агентство поддержки сайта или SaaS-платформа?

Это SaaS-платформа, а не агентство сопровождения чужого кода. В её направления входят видимость бренда в нейросетях, GEO-аналитика, автопостинг и конструктор сайтов с AI-оптимизацией.

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

Можно ли запускать GEO-продвижение до завершения передачи сайта?

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

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

---

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

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

Если техническая передача уже организована, изучите [инструменты Молвун для мониторинга видимости бренда]: начните с разделов «Продукт» и «Как работает», затем сопоставьте возможности с вашим заданием и условиями в разделе «Цены».

---

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