Передать подрядчику свой логин администратора — быстро, но неудобно контролировать: непонятно, кто менял настройки, а после завершения работ приходится менять пароль во всех местах. Надёжнее заранее определить задачу, создать отдельную учётную запись с минимально достаточными правами и сразу записать, как доступ будет отозван.
1. Сначала опишите работу, а потом выбирайте роль
Не начинайте с вопроса «давать ли администратора». Начните со списка действий. Подрядчику может требоваться только редактирование текстов, публикация материалов, загрузка изображений, настройка плагина или работа с сервером. Это разные уровни доступа.
| Что нужно сделать | Какой доступ рассмотреть | Что проверить |
|---|---|---|
| Подготовить черновики | Contributor | Публикация остаётся у владельца или редактора |
| Публиковать свои записи | Author | Не требуется ли редактировать чужие материалы |
| Редактировать страницы и записи команды | Editor | Не нужны ли настройки темы и плагинов |
| Установить или настроить плагин, изменить системные параметры | Administrator — только если без него задача невозможна | Срок, резервная копия, тестовая среда и список изменений |
| Изменить DNS, PHP, базу данных или файлы сервера | Отдельный доступ у регистратора или хостинга | Не подменять серверный доступ учётной записью WordPress |
В WordPress права задаются ролями и отдельными возможностями. Официальная справка по ролям и правам уточняет: Administrator имеет доступ ко всем функциям администрирования одного сайта, Editor управляет публикациями, включая материалы других пользователей, а Author — только собственными. Поэтому название роли следует сопоставлять с конкретной задачей, а не с должностью исполнителя.
2. Создайте отдельную учётную запись
- Откройте Пользователи → Добавить нового.
- Укажите рабочий адрес подрядчика, а не общий ящик компании.
- Придумайте понятное имя пользователя, по которому запись можно узнать в журнале действий и списке авторов.
- Назначьте минимальную подходящую роль.
- Передайте исполнителю только его данные. Не отправляйте свой пароль администратора.
- Запишите владельца доступа, цель и дату пересмотра в простой таблице доступов.
Если сайт уже использует двухфакторную аутентификацию, включите её и для временной учётной записи. Не отключайте защиту ради удобства входа: лучше заранее проверить, сможет ли подрядчик завершить настройку.
Когда нужен доступ интеграции, а не человека
Скрипту, мобильному приложению или сервису публикации не обязательно знать основной пароль пользователя. WordPress поддерживает пароли приложений — отдельные отзываемые данные для API. Они не предназначены для входа человека через wp-login.php. В официальном руководстве по Application Passwords рекомендуется создавать отдельный пароль для каждой интеграции, использовать HTTPS и отзывать ключ, когда он больше не нужен.
Важно: пароль приложения наследует возможности пользователя, к которому он привязан. Сначала создайте пользователя с подходящей ролью, затем выдавайте интеграции отдельный ключ.
3. Подготовьте безопасную точку возврата
До начала работ договоритесь, что именно считается завершённой задачей и как проверить результат. Если изменения затрагивают плагины, тему или базу данных, сначала проверьте резервную копию и тестовое восстановление. Одна надпись «backup completed» ещё не подтверждает, что архив полный и пригоден для возврата сайта.
Для рискованных изменений полезна тестовая копия сайта. На ней можно проверить совместимость, форму заказа и мобильную версию без вмешательства в рабочий сайт. Если подрядчик предлагает установить новый инструмент, заранее пройдите семь вопросов перед установкой плагина: зачем он нужен, кто его поддерживает и как будет удалён.
4. Зафиксируйте границы работы
Короткое задание на доступ может состоять из пяти строк:
- цель: например, настроить отправку писем из формы;
- разрешённая область: конкретный плагин и тестовая страница;
- запрещённая область: платежи, пользователи, товары, DNS;
- контрольная точка: скриншоты настроек и тестовая заявка;
- срок доступа: дата завершения и ответственный за отзыв.
Просите сообщать о действиях, которые выходят за первоначальный план. Например, обновление ядра, темы или нескольких связанных плагинов — отдельное изменение с собственным риском. Для таких работ используйте порядок безопасного обновления WordPress.
5. Проверьте результат до отзыва доступа
Не ограничивайтесь фразой «всё готово». Проверьте пользовательский сценарий, который должен был измениться:
- Откройте сайт в приватном окне и на телефоне.
- Пройдите целевое действие: отправку формы, оформление заказа или публикацию записи.
- Проверьте письма, уведомления и записи в административной панели.
- Сравните результат с заданием и сохраните краткий список внесённых изменений.
- Убедитесь, что подрядчик не оставил тестовые страницы, пользователей и черновики.
6. Отзовите доступ без потери контента
После приёмки откройте список пользователей и решите, нужно ли удалить учётную запись или временно понизить её роль. Перед удалением проверьте, принадлежит ли ей опубликованный контент: записи следует назначить действующему владельцу, а не удалять вместе с пользователем.
Затем отзовите связанные пароли приложений, токены хостинга и другие временные ключи. Если подрядчику всё же передавали общий пароль, смените его у всех, кто его использовал. Финальная проверка — вход под отозванной учётной записью должен быть невозможен, а сайт и целевой сценарий должны продолжать работать.
Короткий чек-лист владельца сайта
- Задача описана через конкретные действия.
- Создан отдельный пользователь, общий пароль не передавался.
- Выбрана минимально достаточная роль.
- Есть проверенная резервная копия и план возврата.
- Зафиксированы границы, срок и критерий приёмки.
- Результат протестирован с точки зрения посетителя.
- Контент переназначен, временный доступ и ключи отозваны.
Полезные товары по теме
Безопасность онлайн-бизнеса
Учебный материал о паролях, бизнес-аккаунтах и безопасной передаче доступа команде или подрядчику.