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

Чек-лист передачи сайта для бизнеса из ОАЭ должен охватывать девять пунктов: регистранта домена и аккаунт регистратора, в котором он находится, записи DNS, аккаунт хостинга, логин администратора CMS, репозиторий кода для всего, что сделано на заказ, ресурсы Analytics и Search Console, почтовые аккаунты, привязанные к домену, SSL-сертификат и резервные копии. Большинство из этого можно проверить за считаные минуты, если знать, куда смотреть. Когда сайт строило агентство, честный вопрос звучит не как «есть ли у нас логин», а как «чьё имя стоит на каждом из этих девяти пунктов, и можем ли мы действовать без чьего-либо разрешения».

Что получить при передаче сайта: домен и DNS

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

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

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

Аккаунт хостинга при передаче сайта

Хостинг, это пункт, который чаще всего пропускают в чек-листе передачи сайта, потому что сайт работает вне зависимости от того, кто владеет аккаунтом. Аккаунт хостинга, это место, где на самом деле находятся файлы сайта, база данных и настройки сервера. Это не то же самое, что домен, и не то же самое, что логин в CMS, и бизнес вполне может иметь одно без двух других. Попросите название провайдера хостинга, имя и почту владельца аккаунта и способ оплаты, а затем войдите сами и убедитесь, что видите файлы сайта, базу данных и любые настройки панели управления, например версию PHP или SSL.

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

Аккаунты администратора CMS и роли пользователей

Логин в CMS, это пункт, который большинство бизнесов принимает за покрытие всего остального в чек-листе передачи сайта, и обычно это самое слабое предположение в списке. Возможность войти в WordPress не равна владению сайтом. Собственная документация WordPress о ролях и возможностях описывает шесть встроенных ролей, от Подписчика до Администратора, и при передаче эта разница имеет значение. Администратор может управлять плагинами, темами, обновлениями и другими пользователями. Редактор может публиковать и редактировать контент, но не может трогать плагины, темы или пользовательские аккаунты. Если при передаче сайта ваша команда получает только логин Редактора или Автора, вы сможете обновлять блог, но не сможете добавить плагин формы, изменить настройку темы или позже убрать доступ агентства.

Просите аккаунт Администратора, созданный под корпоративной почтой, которую контролируете вы, а не под личным адресом того, кто строил сайт. Если агентству нужен постоянный доступ для обслуживания, это нормальная и разумная договорённость, но это должен быть второй аккаунт Администратора, добавленный после вашего, а не единственный. Та же логика применяется к любой другой CMS или платформе для интернет-магазина: найдите эквивалент высшей роли и убедитесь, что она сначала закреплена за вашим бизнесом.

Репозиторий кода для сайта, сделанного на заказ

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

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

Кому принадлежат данные Analytics и Search Console вашего сайта

Analytics и Search Console, это два отдельных продукта Google с двумя отдельными уровнями владения, и чек-лист передачи сайта должен рассматривать их именно так. Рекомендации Google Search Console описывают подтверждённого владельца как того, кто доказал право владения токеном, например HTML-файлом, метатегом или записью DNS, а делегированного владельца как того, кому подтверждённый владелец предоставил тот же статус без токена. Ниже стоят полные и ограниченные пользователи, которые могут просматривать данные, но не могут управлять тем, у кого ещё есть доступ. Google прямо говорит, что у ресурса всегда должен оставаться хотя бы один подтверждённый владелец, иначе доступ к нему не сохранится ни у кого.

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

При передаче попросите две вещи: почту вашего бизнеса как подтверждённого владельца в Search Console и права Администратора на уровне аккаунта, а не только ресурса, в Analytics. Затем войдите сами и проверьте, что именно вы, а не только агентство, значитесь в списке владельцев или пользователей каждого ресурса.

Почта, SSL и резервные копии в чек-листе вашего сайта

Чек-лист передачи сайта должен называть и почту, поскольку продажа или перенос домена может незаметно сломать каждый почтовый ящик на нём. Почтовые аккаунты на вашем домене, например info@ или sales@, обычно находятся внутри того же хостинга или DNS-настройки, описанных выше, поэтому, владея этим аккаунтом, вы обычно получаете и почтовые ящики. Исключение, это отдельный почтовый сервис, например размещённая почтовая платформа, купленная и оплачиваемая агентством. Уточните, какой это случай, и если почта оплачивается отдельно, перенесите аккаунт в собственный платёжный профиль вашего бизнеса.

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

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

Чек-лист передачи сайта, когда всё держит агентство

Если, прочитав разделы выше, вы узнали в нескольких из них свой собственный сайт, решение редко бывает драматичным. Большинство агентств готовы перенести аккаунты на имя клиента, проблема обычно в том, что никто не спросил об этом ясно и письменно. Отправьте одно сообщение, охватывающее регистранта домена, аккаунт регистратора, DNS, хостинг, логин Администратора в CMS, репозиторий кода, если он есть, владение Analytics и Search Console, почтовые аккаунты и договорённости по SSL и резервным копиям, и попросите каждый пункт по имени.

• Домен: имя регистранта и аккаунт регистратора подтверждены на имя вашего бизнеса, проверено через Whois.
• DNS: доступ к панели, управляющей записями, с пометкой о назначении каждой записи.
• Хостинг: аккаунт зарегистрирован на ваш бизнес, агентство добавлено как соавтор при необходимости.
• CMS: аккаунт Администратора под собственной корпоративной почтой, отдельный от любого логина агентства.
• Репозиторий кода: передан или предоставлен собственному аккаунту вашей организации.
• Search Console: почта вашего бизнеса как подтверждённый владелец.
• Analytics: права Администратора на уровне аккаунта, а не только ресурса.
• Почта: почтовые ящики и любой отдельный почтовый сервис оплачиваются под вашим бизнесом.
• SSL и резервные копии: подтверждённое владение или автопродление, и резервная копия, которую вы можете скачать сами.

Там, где домен, ресурс Search Console или аккаунт Analytics по-настоящему невозможно перенести, например потому что прежний разработчик недоступен, отнеситесь к этому как к отдельному проекту: зарегистрируйте новый ресурс или аккаунт на имя вашего бизнеса, настройте редиректы там, где это возможно, и держите старый под рукой как запись, а не оставляйте вопрос открытым бесконечно.

Чем может помочь Digital Marketing Dubai

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