Поисковая оптимизация. Практическое руководство по продвижению сайта в Интернете

Выражение Disallow: ничего не запрещает, так как без параметров.

Примеры использования файлов robots.txt

Пример 1:

# Инструкции для всех роботов User-agent: *

Disallow: /

# Инструкции для робота «Рамблера»

User-agent: StackRambler

Disallow:

Этот файл robots. txt запрещает индексацию всех страниц сайта всем роботам, кроме робота «Рамблера», которому, наоборот, разрешена индексация всех страниц сайта.

Пример 2:

User-agent: *

Disallow: /search/

Disallow: /404/

User-agent: StackRambler

User-agent: Aport

User-agent: Yandex

Disallow: /de/

Disallow: /en/

Данный файл robots. txt запрещает для индексации русским поисковикам англоязычную и немецкую версии сайта. Как следствие, достигается более высокая скорость индексации. Кроме того, запрещена индексация всеми поисковыми роботами страниц /search/ и /404/.

Существует еще один способ управления индексацией сайта.

Использование мета-тегов robots

В отличие от файлов robots. txt, описывающих индексацию сайта в целом, тег <meta name = «Robots» content=«…»> управляет индексацией конкретной веб-страницы.

Инструкции по индексации записываются в поле content.

Возможны следующие инструкции:

? noindex – запрещает индексирование документа;

? NOFOLLOW – запрещает проход по ссылкам, имеющимся в документе;

? index – разрешает индексирование документа;

? FOLLOW – разрешает проход по ссылкам;

? ALL – равносильно INDEX, FOLLOW;

? NONE – равносильно NOINDEX, NOFOLLOW.

Для каждого сайта использование и содержание файла robots. txt индивидуально. Для сайтов с количеством контента в несколько десятков или сотен страниц данный файл может и не пригодиться.

Тестирование сайтов на предмет взлома, защита сайта от взлома

Для того чтобы продавать товары и услуги, ваш сайт должен быть защищен от взлома. Конечно, на 100 % гарантировать защиту никто не может. В Интернете довольно много талантливых хакеров, которые при желании могут взломать почти любой сайт. Тем более если им дать денег. На хакерских форумах часто можно видеть предложение подобных услуг.

Однако от самых распространенных методов взлома ваш сайт должен быть защищен! К сожалению, многие разработчики оставляют в коде сайта большое количество «дыр», из-за которых ваш бизнес может сильно пострадать. Порой даже сайты серьезных корпораций довольно слабо защищены от хулиганов.

Самые распространенные «дыры» и методы защиты от них

К сожалению, большинство сайтов и серверов, на которых расположены эти сайты, имеют свои слабые места, или, проще говоря, «дыры». По данным исследователей уязвимостей веб-приложений, около 63 % сайтов имеют критические уязвимости (http://www.ptsecurity.ru/stat2007.asp). И, что еще хуже, в 93 случаях из 100 сайты имеют уязвимости средней степени риска. Это означает лишь то, что их можно взломать и тем самым причинить владельцу определенные убытки. Не думаю, что вас устроит такое положение дел.

Рассмотрим «дыры», которые могут присутствовать на сайтах (табл. 1.9).

Таблица 1.9. Варианты «дыр», которые могут присутствовать на сайте[6 - Информация взята с сайта http://www.ptsecurity.ru/stat2007.asp.]

Как видите, уязвимостей много и некоторые из них встречаются довольно часто.

Как закрыть «дыры»?

Сразу скажу, что на 100 % «дыры» в сайте закрыть очень тяжело. Иначе говоря, полную гарантию дают только в морге. Но самые «очевидные» уязвимости выявлять и устранять можно и нужно. Причем желательно еще на этапе разработки сайта. Это можно сделать с помощью специализированного программного обеспечения. Благо такое программное обеспечение есть, и даже можно попробовать бесплатные версии. Обзор некоторых программ можно найти по адресу www.xakep.ru/post/37183/default.asp. Практически все программы могут «ловить» те или иные уязвимости и выдавать отчеты с рекомендациями к действию.

Очень важно, чтобы эти действия были проведены как на уровне разработчиков сайта (веб-программистов), так и на уровне тех, кто отвечает за серверы (сисадминов). Иначе может оказаться, что на сайте все «дыры» закрыты, а на сервере для хакеров сплошное раздолье.

Мне приходилось работать с программой X-Spider. Это программный комплекс, позволяющий искать уязвимости как на уровне сервера, так и на уровне сайта. Достаточно мощный и с доступными отчетами. Подходит как для сисадмина, так и для обычного менеджера, ничего не понимающего в «железе» и Linux. Единственный «недостаток» такого софта – он стоит денег. Хотя и небольших. Подробнее про сам софт и отчеты можно почитать, например, в этом обзоре: http://www.ixbt.com/soft/xspider7.shtml.

Еще можно после всех своих свершений заплатить некоторую сумму в долларах хакерам, чтобы они попробовали вас поломать. Когда поломают, пусть заодно расскажут о «дырах», через которые поломали.

А теперь жуткая банальщина, но я вынужден это написать. После проведения тестирования уязвимостей надо составить некий план по их устранению. После того как все сделано, еще раз проверьте все на уязвимости. И так до бесконечности.?

Организация бэкапов сайта

Бэкап – это резервная копия вашего сайта. Любая уважающая себя хостинговая компания предлагает услуги по резервированию данных. Как правило, бэкапы делаются каждую ночь и за определенный период времени. Основное назначение бэкапа – восстановление сайта после взлома или сбоя на сервере. В нашей практике встречались случаи, когда крупные хостинговые компании «теряли» или «забывали» делать бэкапы сайтов либо делали их не еженощно, а как бог на душу положит, несмотря на то, что договором было предусмотрено ежедневное резервное копирование. Таким образом, наличие бэкапов необходимо контролировать. А еще лучше, если бэкап будет вестись не только силами хостинговой компании, но и независимо вами либо кем– то из сотрудников вашей компании. Если же у вас собственный сервер, то делать бэкапы и следить за ними – обязанность системного администратора. Хотя и сисадмины нуждаются в вашем постоянном контроле.

Случаи из практики

Случай 1. Хостер забыл сделать бэкапы. В нашей практике был случай, когда один очень известный хостер (не будем показывать пальцами) «забыл» сделать бэкапы сайтов. Хотя по договору они заявлялись. Что-то у них там не сработало, и бэкапов за последние две недели не было. Пришлось восстанавливать сайты с бэкапов давностью 17 дней и считать потери.

Случай 2. Когда бэкапов вообще не было. Случаются и более экстремальные случаи, когда бэкапов нет вообще. У одного из клиентов вирус «съел» половину сайта. Естественно, что у хостера был запрошен бэкап, но бэкапов не оказалось. Итог печален – удалось восстановить только часть сайта.