Создание сайта для бизнеса: как не испортить все с самого начала

Если вы используете на практике нехитрые советы из этой статьи, то ваш сайт получит серьезное преимущество перед 60% конкурентов. Не верите? Ок, цифра 60% взята с потолка приведена просто по личным наблюдениям. Но то, что огромное число бизнесменов и стартаперов игнорирует простейшие требования к разработке со стороны интернет-маркетинга – факт.

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

В этой статье речь идет об одном из первых решений, которое надо осознанно принять владельцу проекта. А именно – о выборе способа размещения рабочей (тестовой) версии сайта, которая будет основой для разработки. Многим кажется, что это неважно и никак не влияет на дальнейшую судьбу проекта. И совершенно напрасно.

Какие проблемы могут возникнуть на этапе разработки?

Типичная история создания сайта выглядит следующим образом.

Заказчик выбирает доменное имя, разработчик регистрирует его (хорошо если не на себя), делегирует на сервер, ставит туда движок в стандартной комплектации. После череды долгих согласований к сайту прилепляется дизайн. Счастливый владелец хвастается им в Фейсбуке и просит советов. К ужасу разработчиков, поступает множество высокопрофессиональных рекомендаций – от домохозяйки, инженера слаботочных систем и школьника. Потом руки доходят до того, чтобы поменять текст на главной. Параллельно программисты ковыряют плагины и дополнения; в разных местах регулярно вылезают надписи “error” и “warning”. Месяца через три сайт более-менее похож на дело.

Что здесь не так? (Ответ “все” не принимается.)

А вот что. Долгое время рабочая версия была доступна любому желающему. “Любой желающий”, это, в том числе:

1. Роботы поисковых систем. За несколько месяцев Яндекс и Google имеют возможность полностью ознакомиться с новым сайтом. Тестовая версия по определению представляет собой некачественный сайт. Продвижение будет затруднено. В самом лучшем случае вам придется ждать, пока ресурс будет переиндексирован (с учетом частоты апдейтов в Яндексе – ждать довольно долго!). В худшем – весьма вероятно наложение санкций, которые так просто не снимутся.
2. Парсеры, копирующие контент. Делаете хороший сайт, выкладываете уникальные материалы? В Сети немало тех, кто не прочь скопировать с молодого сайта все ценное. В сочетании с первым пунктом получается вдвойне неприятно.
3. Хакеры. Если вы думаете, что хакеры – это сумрачные гении, которые бодаются с мировыми корпорациями и Пентагоном, спешу вас разочаровать. Взлом сайтов поставлен на поток. Недавно познакомился с кейсом: человек установил WordPress и поставил несколько защитных плагинов. В том числе такой, что ведет лог попыток входа в админку. Так вот, на молодом, неизвестном никому сайте, за час было зарегистрировано более тысячи попыток подобрать пароль с разных IP.

Думаю, этого достаточно, чтобы понять, насколько серьезна и актуальна проблема.

Рабочая версия сайта: варианты

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

На домене с запретом индексации

Первое, что приходит в голову что-то слышавшим о SEO разработчикам – просто закрыть сайт от индексации. Для этого достаточно разместить в robots.txt следующее:

User-agent: *
Disallow: / # блокирует доступ ко всему сайту

Огромное большинство разработчиков на этом месте решают, что “можно спать спокойно”. Увы, это не так. Robots.txt заблокирует доступ только “добропорядочным” ботам. Парсерам контента и хакерам совершенно все равно, есть robots.txt или нет. Кроме того, по некоторым наблюдениям,  есть шанс, что после снятия запрета сайт будет индексироваться более туго. Это преодолимо, но зачем нам лишняя неприятность?

На техническом домене

Часто разработчики размещают тестовый сайт клиента на поддомене своего сайта: kompaniya.razrabotchikvasya.ru. В этом случае снимается риск санкций за низкое качество. Зато прибавляется другая потенциальная опасность. Поисковые системы могут в дальнейшем посчитать ваш основной сайт неглавным зеркалом, а технический поддомен – основной версией сайта. Именно поддомену достанется трафик. Не то чтобы это очень частая проблема, но при определенной кривизне рук программиста – вполне реальная. Более того, учинить это безобразие вполне может и опытный разработчик. Чтобы иметь дополнительный рычаг влияния на клиента – например, как страховку от просрочки платежа.

Конечно же, остаются проблемы с воровством контента и взломом сайта.

На локальном сервере

Сайт не размещается в Интернете, все файлы и базы данных имеются только на компьютере разработчика. Это легко сделать, установив, например, готовые программные пакеты вроде Denwer или Openserver. Промежуточные результаты можно показывать заказчику, просто принося на флешке или же установив аналогичный сервер на компьютере клиента.

Способ полностью лишен перечисленных выше недостатков. Взламывать сайты до их появления в общем доступе рядовые хакеры еще не научились, равно как и поисковики – сканировать флешки.

Вариант плохо подходит сайтам, над которыми работает команда удаленных сотрудников: синхронизировать все работы проще на одном сервере.

С http-аутентификацией

Базовая HTTP-авторизация – это возможность ограничить доступ к сайту с использованием логина и пароля средствами самого сервера, без дополнительных скриптов. Пришедшие на защищенную таким образом страницу роботы и парсеры получат ответ 401 (требуется авторизация). Это гораздо более увесистый замок, нежели robots.txt. И гораздо удобнее для совместной работы, чем локальный сервер.

См. статью о том, как установить такую защиту (раздел “паролирование директорий”). Настройка несложная.

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

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

Трюк с hosts

Схема с HTTP-авторизацией часто отвергается заказчиками как слишком сложная. Что же, есть вариант минимальной модификации самого простого варианта – работы сразу с основным доменом. Вот он:

1. Домен никуда не делегируем.
2. Однако на хостинге создаем сайт на этом домене.
3. На компьютерах всех сотрудников редактируем файл hosts (прописываем инструкцию вида “ip сервера site.ru”).
4. На этих компьютерах будет открываться сайт, залитый на хостинг, с ним можно взаимодействовать как и с любым другим.

Все действия очень просты и доступны. Я для примера создал на своем хостинге домен searchengines.guru (крупнейший в Рунете форум о SEO) и отредактировал hosts. Все заняло полторы минуты, и вот пожалуйста:

Итак, если вы создаете сайт не для развлечения, а чтобы привлекать через него клиентов, то советую остановиться на одном из трех последних вариантов (локальный сервер, HTTP-авторизация, редактирование hosts), несмотря на некоторые неудобства. Ну и в целом – относиться к проекту серьезно с самого начала, не пускать его на самотек.

Нормально делай – нормально будет!