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

Пока подрядчик работает, проблема незаметна.

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

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

Для WordPress это особенно актуально. ⚠️ У сайта есть не одна точка доступа, а целая цепочка зависимостей: домен, DNS, хостинг, база данных, файлы, администраторы WordPress, почта, SSL, CDN, аналитика, рекламные системы, лицензии и резервные копии.

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

🔐 Что значит «бизнес не контролирует свой сайт»

Контроль над сайтом — это не просто логин и пароль от /wp-admin.

Полный контроль означает, что собственник или ответственное лицо компании может самостоятельно:

  • управлять доменом;
  • изменить DNS-записи;
  • получить доступ к хостингу или серверу;
  • скачать файлы сайта;
  • получить копию базы данных;
  • войти в WordPress с правами администратора;
  • восстановить сайт из резервной копии;
  • управлять SSL-сертификатом;
  • контролировать корпоративную почту, связанную с сервисами сайта;
  • получить доступ к Google Analytics и Search Console;
  • управлять CDN и системами защиты;
  • продлить необходимые лицензии;
  • сменить подрядчика без разрешения предыдущего.

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

Причём потерян он может быть даже при наличии доступа в WordPress.

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

🧩 Самая частая ошибка: считать сайт одним объектом

У бизнеса обычно есть ощущение, что сайт — это одна вещь.

На самом деле технически это набор независимых компонентов.

Условно его можно представить так:

Домен → DNS → сервер/хостинг → файлы WordPress + база данных → WordPress → внешние сервисы

Параллельно работают:

  • SSL;
  • CDN;
  • почта;
  • аналитика;
  • системы вебмастеров;
  • CAPTCHA;
  • платежные системы;
  • карты;
  • SMTP;
  • сервисы резервного копирования;
  • лицензии премиальных плагинов;
  • интеграции с CRM.

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

Именно поэтому вопрос «У нас есть пароль от WordPress?» недостаточен.

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

🌐 Домен зарегистрирован не на компанию

Это одна из наиболее неприятных ситуаций.

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

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

  • продлением домена;
  • сменой DNS;
  • переносом сайта;
  • подключением почты;
  • подтверждением владения;
  • восстановлением доступа;
  • сменой регистрационных данных.

Особенно опасна ситуация, когда никто внутри компании не знает, где зарегистрирован домен.

Проверка начинается с простого вопроса:

Кто сегодня может войти в аккаунт регистратора и изменить DNS домена?

Если ответ — «только наш разработчик», это уже повод провести аудит.

🖥️ 2. Хостинг оформлен на подрядчика

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

Для небольшого проекта это иногда кажется удобным.

Подрядчик говорит:

«Не переживайте, мы всё сами настроим».

Действительно, на старте это экономит время.

Но через несколько лет появляется зависимость.

Компания не знает:

  • какой тариф используется;
  • где расположен сервер;
  • кто имеет SSH-доступ;
  • где находятся резервные копии;
  • какие версии PHP и MySQL используются;
  • какие дополнительные сервисы подключены;
  • какие ограничения установлены на аккаунте;
  • кто получает уведомления от хостинга.

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

Иногда доступ подрядчик передаёт без проблем.

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

И тогда перенос требует отдельной технической процедуры.

👤 3. Единственный администратор WordPress — разработчик

Ещё один типичный сценарий: в WordPress есть один пользователь с ролью Administrator.

Это разработчик.

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

Проблема здесь не только в зависимости от конкретного человека.

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

У владельца бизнеса должны быть собственные административные учётные записи.

При этом не стоит создавать один общий логин вроде admin и передавать его нескольким сотрудникам.

Правильнее:

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

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

💾 4. Резервные копии существуют только «на словах»

Фраза «у нас есть бэкап» ничего не гарантирует.

Нужно знать:

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

💾 Резервная копия WordPress — это не только папка с файлами.

Для полноценного восстановления обычно необходимы как минимум:

файлы сайта + база данных.

Если резервируется только wp-content, восстановить полноценный проект может не получиться.

Ещё хуже, когда единственная копия находится на том же сервере.

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

🔑 5. Премиальные плагины привязаны к почте подрядчика

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

На WordPress могут использоваться коммерческие:

  • конструкторы;
  • SEO-плагины;
  • системы резервного копирования;
  • формы;
  • оптимизаторы;
  • security-плагины;
  • дополнительные модули WooCommerce.

Лицензия может быть оформлена на email разработчика или агентства.

Пока сайт работает — это незаметно.

После смены подрядчика возникают вопросы:

Кто владелец лицензии?

Можно ли официально перенести её на компанию?

Есть ли у бизнеса подтверждение покупки?

Что произойдёт после окончания срока подписки?

Если критически важная функциональность зависит от чужой лицензии, это ещё одна форма технической зависимости.

📧 6. Доступы хранятся в личной почте сотрудника

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

Например:

  • Search Console — на Gmail бывшего специалиста;
  • Analytics — на личный аккаунт маркетолога;
  • хостинг — на почту разработчика;
  • домен — на аккаунт агентства;
  • SMTP — на личный адрес;
  • CDN — на старый email.

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

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

Не к конкретному сотруднику.

Не к подрядчику.

Не к личной почте.

⏳ Почему проблема обычно обнаруживается слишком поздно

Пока сайт работает, никто не хочет заниматься инфраструктурой.

Бизнес видит:

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

Кажется, что всё в порядке.

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

Хорошая проверка выглядит так:

«Что будет, если завтра этот подрядчик исчезнет?»

Если ответ:

«Найдём другого»,

следующий вопрос:

«А сможет ли новый подрядчик получить всё необходимое без участия старого?»

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

Как проверить, кто реально контролирует сайт

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

🔎 Что проверить

🌐 Домен

  • Кто владелец аккаунта регистратора?
  • У кого есть доступ?
  • Где зарегистрирован домен?
  • Кто может изменить DNS?

🖥️ Хостинг

  • На кого оформлен аккаунт?
  • У кого есть доступ к панели и серверу?
  • Где находятся файлы и база данных?
  • Кто получает уведомления от хостинга?

⚙️ WordPress

  • Есть ли у компании собственный Administrator?
  • Кто ещё имеет доступ?
  • Есть ли неизвестные или старые пользователи?

💾 Резервные копии

  • Где хранятся бэкапы?
  • Кто может их скачать?
  • Есть ли копия вне основного сервера?
  • Проверялось ли восстановление?

📊 Внешние сервисы

  • Google Analytics и Search Console
  • CDN и SSL
  • SMTP и CAPTCHA
  • CRM и платёжные интеграции
  • Лицензии премиальных плагинов

❗ Если по какому-либо пункту вы не можете быстро назвать владельца, место хранения или человека с доступом — этот компонент стоит проверить отдельно.
| Лицензии | Компания / подрядчик | ? | Кабинеты производителей |

❗ Знак вопроса здесь — не мелочь.

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

🏢 Что должно принадлежать компании

Минимальный набор контроля для бизнеса:

Домен

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

Хостинг

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

WordPress

У владельца должны быть административные права.

Резервные копии

Компания должна знать, где находятся копии и каким способом сайт восстанавливается.

Аналитика

Google Analytics, Search Console и другие системы должны быть доступны ответственным сотрудникам компании.

Лицензии

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

DNS и почта

Это особенно критично для бизнеса.

Изменение DNS может повлиять не только на сайт, но и на корпоративную почту, поддомены, SPF, DKIM, DMARC и сторонние сервисы.

🛠️ Что делать, если доступы уже находятся у подрядчика

Не стоит начинать с требования:

«Передайте нам всё».

Сначала нужно понять структуру проекта.

Резкий перенос без аудита может привести к отключению:

  • почты;
  • платежей;
  • API;
  • CDN;
  • SSL;
  • интеграций;
  • аналитики.

Безопаснее действовать поэтапно.

Шаг 1. Составить карту инфраструктуры

Определить:

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

Шаг 2. Создать собственные аккаунты

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

Это позволяет постепенно переводить управление с подрядчика на владельца.

Шаг 3. Получить резервную копию

До любых серьёзных изменений нужно иметь независимую копию сайта.

Желательно проверить не только наличие архива, но и возможность его восстановления.

Шаг 4. Проверить права доступа

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

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

Шаг 5. Только потом менять подрядчика

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

🔒 Почему нельзя просто сменить пароль администратора

Потому что WordPress — только один слой.

Предположим, компания изменила пароль от /wp-admin.

Подрядчик всё ещё может иметь:

  • доступ к хостингу;
  • SSH;
  • FTP/SFTP;
  • базу данных;
  • панель CDN;
  • DNS;
  • аккаунт регистратора;
  • резервные копии;
  • API-ключи.

В некоторых случаях доступ к серверу позволяет создать нового пользователя WordPress или изменить файлы сайта.

Поэтому полноценная передача проекта требует проверки всей инфраструктуры, а не только CMS.

📦 Как выглядит нормальная передача WordPress-проекта

Хорошая передача сайта — это не письмо с текстом:

«Логин: admin, пароль: 123456».

У проекта должна существовать понятная техническая документация.

В ней желательно зафиксировать:

  • домен;
  • регистратора;
  • DNS;
  • хостинг;
  • IP-адрес сервера;
  • версию PHP;
  • версию WordPress;
  • используемую тему;
  • список плагинов;
  • платные лицензии;
  • внешние интеграции;
  • SMTP;
  • CDN;
  • SSL;
  • резервное копирование;
  • аналитические системы;
  • Search Console;
  • доступы;
  • инструкции по восстановлению.

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

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

⚠️ Что происходит при смене подрядчика без подготовки

Представим обычный сценарий.

Компания несколько лет работает с одной веб-студией.

Домен находится у студии.

Хостинг тоже.

WordPress настроен.

Резервные копии делает разработчик.

Аналитика подключена к его Google-аккаунту.

Всё работает.

Компания решает перейти к другой команде.

Новый разработчик просит:

— Дайте доступ к хостингу.

Ответ:

— У нас его нет.

— Тогда резервную копию.

— Её делает старая студия.

— А доступ к домену?

— Тоже у них.

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

Если старый подрядчик отвечает и готов сотрудничать — вопрос решается.

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

🧠 Самая опасная зависимость — не техническая

Есть ещё одна проблема.

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

Это называется зависимостью от конкретного человека.

Например:

«Спросите у нашего программиста, он знает».

А программист знает:

  • где лежит сервер;
  • почему используется нестандартный cron;
  • какой плагин нельзя обновлять;
  • почему форма работает через отдельный SMTP;
  • где находится резервная копия;
  • какой API-ключ используется;
  • почему на сайте установлен старый PHP;
  • как устроена интеграция с CRM.

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

Поэтому документация — часть контроля над сайтом.

🤝 Как снизить зависимость от подрядчиков

Подрядчик не должен становиться владельцем инфраструктуры.

Его задача — обслуживать систему.

Разница принципиальная.

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

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

При этом вовсе не требуется постоянно самостоятельно администрировать сервер.

Бизнес может передать техническое обслуживание специалистам.

Но право распоряжаться инфраструктурой должно оставаться у владельца.

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

✅ Чек-лист владельца WordPress-сайта

Проверьте каждый пункт.

🌐 Домен

  • Компания знает регистратора.
  • Есть доступ к аккаунту.
  • В аккаунте указана актуальная корпоративная почта.
  • Компания может изменить DNS.
  • Известна дата продления домена.

🖥️ Хостинг

  • Известен провайдер.
  • Есть собственный аккаунт компании.
  • Известно расположение сайта.
  • Есть доступ к файлам.
  • Есть доступ к базе данных или понятный способ её получить.

⚙️ WordPress

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

💾 Резервные копии

  • Известно, где находятся бэкапы.
  • Они создаются регулярно.
  • Есть несколько точек восстановления.
  • Есть копия вне основного сервера.
  • Восстановление хотя бы периодически проверяется.

Внешние сервисы

  • Google Analytics.
  • Search Console.
  • CDN.
  • SMTP.
  • SSL.
  • CAPTCHA.
  • CRM-интеграции.
  • Платёжные системы.
  • Лицензии плагинов.

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

🚨 Когда зависимость от подрядчика становится критичной

Не обязательно ждать конфликта.

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

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

Последний пункт особенно показателен.

Нормальная техническая поддержка не должна превращаться в право собственности на сайт.

💡 Нужно ли полностью отказываться от управления через подрядчика

Нет.

Передавать бизнесу все технические операции необязательно.

Большинство компаний не должны самостоятельно заниматься:

  • обновлением WordPress;
  • настройкой сервера;
  • оптимизацией базы;
  • проверкой PHP;
  • настройкой кеширования;
  • устранением конфликтов плагинов;
  • мониторингом безопасности.

Для этого и существует техническая поддержка.

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

Можно передать специалистам обслуживание сайта и при этом сохранить у компании:

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

Это более здоровая архитектура отношений между бизнесом и подрядчиком.

🔄 Что делать перед передачей сайта новому подрядчику

Если компания собирается сменить веб-студию, не стоит начинать с переноса файлов.

Сначала нужно провести инвентаризацию.

Новый подрядчик должен получить хотя бы:

  1. доступ к WordPress;
  2. доступ к хостингу;
  3. информацию о домене и DNS;
  4. резервную копию;
  5. данные о базе;
  6. список плагинов;
  7. информацию о лицензиях;
  8. доступ к аналитике;
  9. информацию о внешних интеграциях;
  10. описание текущей инфраструктуры.

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

Иногда выясняется, что сайт проще и безопаснее перенести на новый хостинг.

Иногда достаточно сменить владельцев аккаунтов.

А иногда сначала приходится восстанавливать доступ к отдельным сервисам.

Универсального сценария нет — его определяет состояние конкретного проекта.

🎯 Главный принцип: подрядчика можно заменить, сайт — нельзя потерять

Хороший подрядчик не строит систему, в которой бизнес не может уйти.

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

Это не означает, что подрядчик не нужен.

Наоборот, чем сложнее WordPress-проект, тем больше значение имеет профессиональная поддержка.

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

🏢 Сайт должен оставаться активом компании.

Домен — контролироваться компанией.

Данные — принадлежать компании.

Резервные копии — быть доступными компании.

Доступы — находиться под контролем компании.

А подрядчик должен отвечать за то, чтобы всё это работало стабильно и безопасно.

Проблема «сайт находится у подрядчика» редко возникает в один день.

Обычно зависимость формируется постепенно.

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

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

Пока всё работает, это незаметно.

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

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

У компании должна быть возможность в любой момент ответить на пять вопросов:

Где находится домен?

Где размещён сайт?

Где лежит резервная копия?

Кто имеет административный доступ?

Может ли новый подрядчик принять проект без участия старого?

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

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