«Я не знала, как дать доступ фрилансеру, чтобы он не сломал весь сайт: рассказываю, как организовала безопасный доступ через панель хостинга и роли в WordPress»

У меня был интернет‑магазин текстиля: WordPress + WooCommerce, 280 товаров, корзина, личный кабинет, формы обратной связи, интеграция с CRM и рассылкой. Клиент сказал: «Нужно передать сайт на доработку: фрилансер сделает новый каталог и поправит фильтры. Но я боюсь, что он случайно удалит базу или сломает корзину». Я кивнула, а внутри всё сжалось: «А если он зайдёт по FTP, удалит папку с темой, и сайт превратится в белый экран? Или получит админский доступ и поменяет пароли? Или скачает базу с товарами и унесёт её?»

До этого я либо вообще не давала доступ (и проект тормозился), либо выдавала полный доступ «на доверии»: FTP с правами на всю папку, админку с правами администратора, базу данных — всё разом. В одном проекте так и случилось: фрилансер случайно удалил старую тему, а в новой не было нужных хуков для корзины — заявки перестали уходить, и мы потеряли продажи за день. Тогда я поняла: доступ должен быть строго под задачу, с минимальными правами, бэкапом и планом на случай ЧП. Панель Timeweb позволяет это сделать без сложных скриптов: отдельные FTP‑пользователи, контроль логов, бэкапы и phpMyAdmin.

Чего я боялась больше всего

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

Потерять базу данных или товары. Что фрилансер скачает или случайно удалит базу, и мы потеряем каталог и историю заказов.
Сломать корзину и формы. Что неправильная правка темы или плагина отключит корзину, и заявки перестанут приходить.
Получить «белый экран» из‑за удаления файлов. Что удалят критичные папки или wp-config.php, и сайт перестанет запускаться.
Не успеть откатиться быстро. Что проблема случится вечером, а я не смогу за 10 минут вернуть стабильную версию.
Дать слишком много прав «для удобства». Что ради скорости я выдам админский доступ, а потом придётся менять все пароли и чистить сайт от лишних плагинов.

С этим списком я пошла в панель Timeweb и составила план: бэкап → отдельные доступы под задачу → контроль → тест на поддомене.

Шаг 1: сделать бэкап и зафиксировать состояние сайта

В панели Timeweb я:

Нажала «Создать резервную копию» для файлов и базы данных. Статус «Готов» — теперь я могла откатиться за 5–10 минут.
Записала текущие настройки: домен, доступы к админке, список критических плагинов (WooCommerce, CRM‑интеграция, кэш).
Проверила, что корзина, формы и личный кабинет работают, чтобы потом сравнить «до и после».

Это была моя страховка: если что‑то сломается, я верну стабильную версию и спокойно разберусь, не теряя заказы.

Шаг 2: создать отдельные доступы строго под задачу

Я разделила доступы на три уровня и выдала только то, что нужно под конкретную задачу фрилансера.

FTP‑доступ с ограничением по папке
В панели хостинга я создала нового FTP‑пользователя и ограничила его доступ только нужной папкой. Например, если задача — доработать тему, доступ давала только к public_html/wp-content/themes/new-theme. Если нужно было поправить виджеты — только к папке с плагином. Так фрилансер не мог случайно удалить другие темы, плагины или конфиги.

Доступ к базе данных с ограниченными правами
Если фрилансеру нужна была работа с базой (например, поправить атрибуты товаров), я создавала отдельного пользователя БД с правами только на чтение или на конкретную базу. Никаких прав на удаление таблиц или дамп всей базы. В phpMyAdmin панели Timeweb это делается быстро и прозрачно.

Роли в WordPress строго под задачу
В админке я выдавала не администратора, а роль под задачу:

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

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

Шаг 3: использовать тестовую площадку вместо основного сайта

Самый безопасный вариант: дать доступ не к основному сайту, а к копии на поддомене. Я:

Создала поддомен test-textile.site.ru.
Развернула туда бэкап: файлы + база.
Настроила в wp-config.php новый домен и пути.
Передала фрилансеру доступы именно к этой тестовой версии.

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

Шаг 4: контролировать изменения и логи

Даже при ограниченных правах я держала руку на пульсе:

Смотрела логи FTP в панели Timeweb. Там видно, кто и когда заходил, какие файлы загружал или удалял. Если фрилансер пытался зайти в запрещённую папку — это сразу видно.
Проверяла список файлов в файловом менеджере. Если появились странные файлы (.sh, .php с непонятными именами) или пропали важные папки — сразу останавливала работы.
Контролировала базу данных. В phpMyAdmin проверяла, не создавались ли новые таблицы, не менялись ли критически важные настройки.
Тестировала ключевые сценарии ежедневно. Каждый день я проверяла корзину, оформление заказа, личный кабинет и формы — чтобы убедиться, что доработки не сломали конверсии.

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

Шаг 5: закрыть доступы и проверить итоговую стабильность

Когда доработки были приняты, я:

Отключила FTP‑аккаунт фрилансера в панели хостинга.
Удалила тестовый поддомен (или оставила как архив, если он нужен для истории).
Сменила пароли, если фрилансер знал какие‑то доступы.
Провела финальное тестирование: корзина, заказ, личный кабинет, CRM‑интеграции.
Сделала новый бэкап уже с обновлённой версией сайта.

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

Где я чуть не ошиблась (и что панель подсказала)

Хотела дать FTP с доступом ко всей папке. Думала: «Так ему будет удобнее». Поддержка подсказала: «Лучше ограничить доступ одной папкой: это сильно снижает риск случайной поломки».
Собиралась выдать админский доступ в WordPress. Думала: «Он быстрее всё сделает». Панель и опыт подсказали: роль «редактор» закрывает 90 % задач, а риск сломать сайт падает в разы.
Не хотела делать тестовую копию. Думала: «Это лишние 30 минут». Но эти 30 минут спасли нас от простоя на сутки: на тесте фрилансер сломал AJAX‑фильтры, и я это увидела до переноса на основной сайт.
Игнорировала логи. Думала: «Если сайт открывается, значит, всё ок». В логах было видно, что фрилансер загрузил файл‑скрипт, который мог использоваться для спама. Панель помогла быстро заметить и удалить.
Не планировала закрытие доступов. Думала: «Потом закрою». Лучше закрывать сразу после сдачи: чем дольше доступ открыт, тем выше риск.

Что реально помогло на Timeweb

Отдельные FTP‑пользователи с ограничением по папкам. Я могла дать доступ только туда, куда нужно, и не бояться, что удалят весь сайт.
Управление пользователями базы данных и phpMyAdmin. Быстро создавала ограниченные доступы и проверяла, что именно менялось в базе.
Бэкапы в один клик и возможность развернуть на поддомене. Это давало мне «полигон» для тестов и гарантию быстрого отката.
Логи FTP и доступа к файлам. Я видела, кто, когда и какие файлы менял — это сильно снижало тревожность.
Файловый менеджер с удобной навигацией. Быстро проверяла, нет ли лишних файлов, и сверяла структуру папок.
Поддержка. Когда сомневалась, можно ли ограничить FTP‑доступ или как лучше выдать права в БД, в чате быстро подсказывали безопасный вариант.

Практические советы, чтобы безопасно передавать сайт на доработку

Если вы тоже планируете дать доступ подрядчику:

Всегда делайте бэкап перед передачей доступов. На Timeweb это пара кликов, а откатиться можно за минуты.
Создавайте отдельные FTP‑аккаунты под проект. И обязательно ограничивайте доступ одной папкой — так фрилансер не сможет сломать весь сайт.
Не выдавайте админский доступ в WordPress. Используйте роли «редактор», «автор» или «участник» — этого хватает для большинства задач.
Для работы с базой данных создавайте пользователей с ограниченными правами. Никаких прав на удаление и дамп всей БД.
Давайте доступ к тестовой копии на поддомене. Так вы тестируете доработки без риска для основного сайта и конверсий.
Контролируйте логи и изменения файлов. В панели хостинга видно, кто заходил и что менял — используйте это как страховку.
Ежедневно проверяйте ключевые сценарии: корзина, оформление, личный кабинет, формы. Пока они не работают идеально — доработки не приняты.
Сразу закрывайте доступы после сдачи проекта. Не оставляйте их «на всякий случай».
При необходимости меняйте пароли. Если фрилансер знал какие‑то учётные данные, лучше их обновить.
Держите реестр доступов и задач. Кто, когда, к чему и на какой срок получил доступ — это экономит часы при разборе инцидентов.

Сейчас я спокойно передаю сайты на доработку: знаю, что у меня есть бэкап, тестовая площадка, ограниченные доступы, контроль логов и чёткий план действий. А клиент получает результат без простоя и потери заказов, потому что все риски я закрыла ещё до того, как фрилансер зашёл на сайт. И всё это благодаря тому, что я перестала полагаться на «доверие» и начала действовать системно. А Timeweb даёт для этого все нужные инструменты: FTP с ограничениями, phpMyAdmin, бэкапы, логи, поддомены и поддержку, которая помогает выстроить безопасный процесс.