При смяна на поддръжката на сайт целта е новият отговорник да може да поддържа работещата система, а собственикът да запази контрол над нея. Получена парола за WordPress не доказва достъп до домейна, пощата, резервните копия или лицензите. Затова предаването започва с опис, а не с незабавно изключване на стария изпълнител.
Тук разглеждаме самата смяна на вече работещ проект. Ако още сравнявате кандидати, използвайте ръководството за избор на изпълнител. Прехвърлянето на поддръжката не изисква автоматично редизайн, нов домейн или друг хостинг.
Направете един регистър за всички активи
За всеки актив запишете доставчика, титуляря или упълномощения представител, необходимата роля, подновяването и доказателството, че новият достъп работи. Ако не знаете отговора, отбележете „неизвестно“ с конкретен човек, който ще го изясни. Не замествайте липсващия факт с предположение.
| Актив | Какво се уточнява | Как се приема |
|---|---|---|
| Домейн и DNS | Кой управлява регистрацията, записите и подновяването | Упълномощеният собственик може да влезе и да възстанови достъп |
| Хостинг и поща | Къде са сайтът и пощенските кутии; може да са отделно | Новият отговорник вижда договорения сайт и нужните настройки |
| Файлове и база | Къде е текущата версия и какво влиза в копието | Има опис и проверка на възстановяване в отделна среда |
| Лицензи и външни услуги | Чий е абонаментът и какво позволява прехвърлянето | Писмено е ясно кой подновява и кои функции зависят от него |
| Измерване и интеграции | Кои профили, роли и връзки са нужни | Достъпът е потвърден, без ненужни административни права |
Изтеглете празния приемо-предавателен регистър. Той е работен шаблон, не договор или удостоверение за собственост. Попълвайте роли, срокове и резултати от проверки; паролите и ключовете се предават през подходящ защитен механизъм.
Реален пример: защо копие на началната страница не стига
В прегледаната на 21 октомври 2026 г. версия на DrNiki кратката форма е в index.html, поведението ѝ е в assets/quick-enquiry.js, общата функция за изпращане е в app.js, а обработката на сървъра е в contact.php. Пощенската услуга е още една зависимост извън самия интерфейс.
Това е проверен пример от собствен код, не твърдение за клиентско прехвърляне. Ако новият изпълнител получи само HTML и снимките, формата може да изглежда завършена, но предаването ще е непълно. При WordPress към темата и разширенията се добавят базата, качените файлове и конкретните настройки. Опишете действителната система, вместо да приемате, че всички сайтове се предават по един начин.
Разграничете собственост, достъп и работна роля
Човекът, който може да редактира текст, не е непременно титуляр на домейна. Администраторът на WordPress също няма автоматично права в хостинг панела или пощенската услуга. Проверете всеки акаунт отделно и уговорете прехвърлянето с действително упълномощените лица.
Ролите в WordPress дават различни възможности. Редакторът работи със съдържание; администраторската роля включва по-широк контрол. Разширенията могат да добавят собствени права, затова демонстрирайте нужната задача с конкретния акаунт. Не раздавайте обща администраторска парола на всички участници.
Когато платформата позволява, използвайте отделни покани и профили. Собственикът трябва да има работещ начин за възстановяване на достъпа, който не зависи единствено от напускащия изпълнител. Ако титулярят, договорът или лицензът са неясни, въпросът се решава с доставчика и страните; техническа смяна на имейл не замества това уточнение.
Проверете новия достъп преди приемане
Уговорете малка, обратима задача: новият поддържащ отваря правилния проект, намира страницата и показва как би редактирал текст в работно копие. Проверете дали има достъп до договорените инструменти, а не само до празен профил със сходно име. За магазини и форми уточнете кой отговаря за тестовите поръчки и съобщения.
Копието се проверява в отделна среда. Запишете кога е направено и как ще се запазят поръчките или редакциите, възникнали след него. Не възстановявайте стара база върху работещ магазин само за да докажете, че архивът се отваря. При реално местене на сървър използвайте и плана за смяна на хостинг.
Премахнете старите права след потвърдено предаване
След приемането прегледайте поканите, потребителите, интеграционните ключове и автоматичните задачи. Уточнете кои остават необходими и кой ги използва. При подмяна на ключ първо се проверява новата връзка; иначе премахването може да прекъсне плащане, изпращане или синхронизация.
Записът „старият достъп е премахнат“ трябва да сочи конкретна услуга и дата. Изход от браузъра не е отнемане на права. Преди премахване на WordPress потребител проверете и съдържанието, свързано с него, така че смяната на автора да не стане случайно изтриване на работа.
Накрая определете кой приема проблеми, как се заявява промяна и какво остава извън поддръжката. Обикновените малки редакции не означават включен редизайн, миграция или аварийно възстановяване; тези задачи се договарят отделно. Доброто предаване завършва с работещ контрол и списък на изключенията, не само с папка, озаглавена „сайт“.
Често задавани въпроси
Трябва ли да сменя хостинга при нова фирма за поддръжка?
Не задължително. Първо проверете дали текущата среда е подходяща и дали необходимият достъп може да се предостави. Преместването е отделна задача с отделни проверки.
Достатъчен ли е администраторски достъп до WordPress?
Не. Домейнът, хостингът, пощата, лицензите и външните профили имат собствени достъпи. Опишете и проверете всеки необходим актив.
Кога да премахна стария изпълнител?
След като упълномощеният собственик потвърди новия достъп, копието и договорените проверки. Прегледайте и ключовете и автоматичните връзки, за да не прекъснете работещ процес.