Советы по Web-разработке: Десять (или чуть больше) файлов, необходимых для каждого Web-сайта
Позаботьтесь об основах вашего нового (или не очень нового) сайта
Дэвид Мерц, писатель, Gnosis Software, Inc.
Описание: Вне зависимости от того, какую систему управления
контентом или какой каркас Web-приложений вы используете, существуют
базовые вещи, о которых необходимо позаботиться. Конечно, выдающийся
интерфейс и полезное содержимое сайта – это замечательно, но, прежде чем
заниматься этими вопросами, следует обеспечить необходимый минимум –
набор файлов, с помощью которых пользователи (причем как люди, так и
машины) могут выяснить, для чего же нужен ваш сайт.
Существует несколько стандартных файлов, которые должны быть,
но далеко не всегда присутствуют в каждом Web-сайте. Как правило, это
вопрос исключительно удобства, а не технической необходимости, но,
забывая о них, вы вредите своему же сайту. Если пользователи наудачу
пробуют обращаться по разным URL, то будет лучше, если они будут
находить то, что искали, в основном. В этой статье мы кратко рассмотрим каждый из стандартных файлов.
Как именно пользователь получает доступ к тому или иному
ресурсу, зависит от Web-сервера и архитектуры вашего Web-приложения. При
использовании "традиционных” серверов типа Apache, работающих со
статичными ресурсами, ресурсы, как правило, представляют собой
обыкновенные файлы на сервере. Но в другом случае они могут являться
записями в базе данных, строками конфигурационного файла, классами
некоего серверного процесса и т.д. В этой статье речь пойдет о том, что,
в конечном счете, получит пользователь, а не о том, как именно это
будет реализовано.
При работе с вашим сайтом пользователи обязательно попробуют
обратиться к несуществующим ресурсам. В основном это происходит из-за
опечаток в адресах страниц, но также встречаются недействительные
ссылки, ошибки в конфигурации сервера, искаженные по разным причинам URL
и т.д. Поэтому, если ресурс по той или иной причине недоступен,
желательно перенаправить пользователя на некую резервную страницу, с
которой он может продолжить навигацию по сайту. Конечно, получив
стандартное сообщение "страница не найдена”, пользователь поймет, что
произошло, но это никак не поможет ему решить, что делать дальше.
Есть одна вещь, о которой необходимо помнить при создании
собственной страницы 404.html (или при использовании механизма,
поддерживаемого вашим Web-сервером, для замены стандартного сообщения
"страница не найдена”). Очень часто разработчики совершают ошибку,
используя так называемую "мягкую” страницу 404. Другими словами, сервер
перенаправляет пользователя к странице, которая возвращается с
заголовком "200 OK”. Как правило, эта страница просто содержит текст
"страница не найдена”, часто даже не упоминая об ошибке 404. Не делайте
этого! Всегда четко информируйте своих пользователей (а также их
браузеры и другие программы) о произошедшем, используя точные заголовки
ответов.
Итак, зачем вы вообще создали этот сайт? Иногда на этот вопрос
отвечает главная страница. Но зачастую это не так, страница просто
предлагает пользователям авторизоваться, создает общее впечатление о
сайте, показывает заставку и т.д. Несмотря на то, что, скорее всего, к
странице "о сайте” (about.html) можно перейти по ссылке с главной
страницы, лучше всегда размещать ее по адресу http://mysite.example.com/about.html. Кто-нибудь обязательно попробует обратиться по этому URL напрямую.
Качественно сделанная страница about.html должна содержать
краткий обзор вашего сайта, возможно, информацию о том, зачем вы его
создали, чем он интересен, а также несколько ссылок для обратного
перехода к основным разделам сайта. Этой странице не требуется никакого
продвинутого оформления и, как правило, она его не содержит. Сделайте ее
достаточно лаконичной, чтобы пользователь мог быстро перейти к более
важным вещам, представленным на вашем сайте.
А сами-то вы кто? Как и в случае с about.html, пользователи,
наверное, смогут докопаться до этой информации, сделав несколько кликов,
начиная с главной страницы. Но не заставляйте их делать этого,
разместите страницу contact.html по адресу: http://mysite.example.com/contact.html.
Поместите ту же информацию на страницу contacts.html, а также
продублируйте файлы, поменяв расширение на .htm. Лишние файлы ничему не
повредят. При этом можно оставить ссылки, ведущие к contact.html – в
подобной избыточности нет ничего страшного.
Кто является правообладателем этой информации? Скорее всего,
именно вы, но опять же – кто вы? Частное лицо? Компания? Какое-то
объединение? Государственная организация? Если информация, выложенная на
вашем сайте, является общедоступной или она защищена какой-то из
свободных лицензий – важно, чтобы пользователи об этом узнали. В
настоящее время весь контент изначально считается защищенным авторскими
правами, поэтому, если в случае ваших материалов это не так, укажите на
это пользователям. Подобным вещам уделяют внимание не так много
Web-сайтов, но почему бы об этом не позаботиться? Кому-нибудь это
обязательно пригодится.
Разумеется, разные материалы могут иметь разных
правообладателей. В этом случае пусть на главной странице объясняется,
как определять различия такого рода для разных страниц. Также, в случае
необходимости, можно упомянуть и о защите торговых марок.
Далеко не в каждом Web-сайте роль главной страницы играет файл
index.html. В зависимости от конфигурации могут использоваться
преобразования URL, динамическая генерация и т.д. Но пользователям-то
все равно! Просто убедитесь, что URL http://mysite.example.com/index.html
указывает на главную страницу, даже если вам для этого придется создать
простой HTML-файл, перенаправляющий пользователя по нужному адресу.
Вдобавок не забудьте убедиться, что так же будет работать
уродливое расширение .htm, ранее использовавшееся в Windows. А если
хватит терпения, можно заставить и index.cgi перенаправлять пользователя
к главной странице.
В настоящее время большой объем информации доступен через
каналы RSS. Имеет смысл их добавлять ко многим, хотя и не ко всем
Web-сайтам. При этом вполне приемлемо генерировать разное содержимое
лент в зависимости от настроек пользователя, авторизации или факта
оплаты определенной информации. RSS-ленты совершенно не обязательно
должны быть унифицированными.
Тем не менее, если некоторую информацию в RSS добавлять можно
всегда, то просто возьмите и сделайте это. Например, в index.rss можно
поместить своего рода "приманку", рассказав при этом, чем может
быть полезно полное содержимое ленты. Или хотя бы пояснить, почему RSS
не нужен для вашего сайта.
Если вы планируете собирать любую информацию о
пользователях, даже если это всего лишь имена для входа в систему или
логин для учета трафика, обязательно сообщите им, как вы собираетесь ее
использовать. Юридические вопросы, возникающие вокруг создателей и
пользователей сайтов, весьма сложны, а я не юрист, и уж тем более – не ваш
юрист. Но могу сказать, что пользователи будут чувствовать себя
спокойнее, зная, что вы подумали о конфиденциальности их данных. Кстати,
вполне возможно, что имеет смысл проконсультироваться с юристом по поводу использования информации о пользователях.
Если вы не хотите, чтобы все материалы на вашем Web-сайте
автоматически индексировались, укажите это в файле robots.txt. На самом
деле, даже если вы хотите, чтобы индексировалось все - явно
напишите об этом. Директива стандарта исключений для роботов (Robots
Exclusion Standard) не является строго обязательной для следования.
Поэтому, если вам очень не хочется, чтобы какие-то ресурсы были
проиндексированы, то либо вообще не помещайте их на Web-сайт, либо
защищайте соответствующими правами доступа. Но все основные сканирующие
системы следуют инструкциям в файле robots.txt. Так что указывайте ваши
пожелания явно.
Файл security.html может использоваться по-разному. Однако если
при работе с вашим сайтом у пользователей возникнут вопросы о
конфиденциальности данных, например, если вы получаете от них некую
секретную информацию, то методы обеспечения конфиденциальности
рекомендуется документировать (хотя бы перечислить их). Также в этот
файл можно поместить контактную информацию, чтобы пользователи знали,
куда направлять вопросы и пожелания. Подобное описание политики
безопасности должно легко находиться по ссылкам. Но не помешает
поместить копию файла по адресу http://mysite.example.com/security.html.
Способ представления карты сайта не очень хорошо стандартизирован. Существуют общие полезные рекомендации, но насколько детальной
будет карта, зависит от того, насколько динамическим является
содержимое вашего сайта. Кроме того, доступность информации зависит от
предназначения сайта. Например, не следует указывать пользователям о
существовании некого материала X, если у них нет к нему доступа. Поэтому
решайте сами, но старайтесь все же предоставить карту сайта в каком-то виде.
Для многих сайтов карта – это всего лишь способ удобного
расположения информации для роботов, например поисковых сервисов. В
частности, Google предложил соглашение в дополнение к robots.txt.
Вкратце: создается файл XML, в котором описываются все материалы данного
сайта; он играет роль "списка включений” в дополнение к "списку
исключений” файла robots.txt.
Есть вещи, которые происходят вне Web. Например, если навигация
на вашем сайте не оправдывает надежд или же пользователи оказываются не
способными оценить его элегантный дизайн, то, по крайней мере, они
должны иметь возможность связаться с вами через электронную почту.
Любыми способами повсюду помещайте контактную информацию,
например, в contact.html. При этом удостоверьтесь, что письма, посланные
на несколько адресов общего назначения, будут перенаправлены нужному
человеку. К подобным адресам относятся как минимум следующие:
postmaster@mysite.example.com, webmaster@mysite.example.com и
security@mysite.example.com. Специально для пользователей старой закалки
можно также включить адрес root@mysite.example.com (не перенаправляя
письма пользователю "root” из соображений безопасности). Можно также
добавить с десяток адресов, органично вписывающихся в тематику вашего
сайта. В наше время адреса e-mail практически так же дешевы, как
символьные ссылки в каталоге вашего Web-сервера.
