32
мента на пассажи, именно в них и происходит процесс поиска. Если ключе-
вые слова расположены в одном пассаже документа, то в запросах, содержа-
щих большое количество слов, при прочих равных условиях, такой документ
будет считаться более релевантным. Если же сложится ситуация, что поиско-
вая система не обнаружит документ, в котором ключевые слова идут в одном
пассаже, то продолжится поиск документа, в котором слова расположены в
разных пассажах. Удобно, что поисковые системы распознают морфологию
русского языка, что позволяет изменять формы слов (например, падежи).
Также замечена небольшая разница в результатах поиска в Яндекс при вве-
дении букв запроса прописными и строчными буквами. При возможности
желательно применить ключевое слово в нескольких вариантах.
2. Точное вхождение ключевого слова в тег title. HTML–тег <title>
имеет важнейшее значение в тексте страницы. Именно он включает в себя
заголовок документа, а также должен включать и ключевые слова, упомина-
ющиеся в нем. Например, Яндекс учитывает 15 слов в <title>, Google – 70
символов. Важно не прибегать к бессмысленному повтору слов-ключевиков.
По причине ограниченности учета текста в <title> ключевые слова следует
разносить по разным документам интрнет-ресурса.
3. Полное включение ключевого слова в тег keywords. Тег
<keywords> должен содержать ключевые слова, описывающие документ.
Влияние текста в этом теге на релевантность крайне мало, однако замечены
случаи понижения релевантности при полностью совпадающем тексте для
всех или большого числа документов внутри одного веб-сайта.
4. Точное вхождение ключевого слова в тег description. Тег
<description> – описание документа. Его содержимое может выводиться в
«сниппете» – выдержке из документа под ссылкой в результатах поиска (рис
2.1):
33
Рисунок 2.1 – Пример сниппета
(выдержка из документа под ссылкой в результатах поиска)
5. Точное вхождение ключевого слова в теги h1–h6. Один из ключе-
вых тегов в документе, обозначающий иерархию заголовков и подзаголовков
на странице. Каждый документ должен включать в себя как минимум тег
<hl> с ключевыми словами. Допускается дублирование текста из тега <title>.
6. Плотность ключевого слова в тексте страницы – до 5%. Если из-
лишне часто использовать ключевые слова в документе, то можно понизить
уровень релевантности, что может полностью исключить документ из ре-
зультатов поиска. Оптимальный процент не установлен, однако рекомендо-
вано не превышать 5%. Перед проведением поисковой оптимизации лучше
всего проанализировать первые 10–20 результатов поиска по интересующему
ключевому слову и использовать средние значения при написании текста.
Необходимо также исходить из простого правила – текст должен быть чита-
ем.
34
7. Общий объем полезного текста на странице больше 1000–2000
знаков. Поисковые системы имеют ограничение на объем индексируемого
документа. Страницы с большими объемами (3000 и более) текста не повы-
шают релевантность текста, в таких случаях рекомендуется разбивать текст
на несколько страниц, связанных ссылками.
8. Обновление веб-сайта. На уровне релевантности положительно
сказывается появление на веб-сайте документов, уникальных по своему со-
держанию. При этом важнее продемонстрировать поисковой системе, что
сайт постоянно развивается, наличие ключевых слов уже не обязательно.
Лучше ежедневно добавлять по одному документу, нежели в один день сразу
выложить 30 документов. Текст должен нести смысловую нагрузку (страни-
ца, на которой размещено одно – единственное изображение, не является та-
ковой), корректно отформатирован (разбит на абзацы и т.д.).
9. Отметка ключевого слова жирным шрифтом (теги <strong> или
<b>). Выделение ключевых слов в документе жирным шрифтом повышает
его релевантность. Но не стоит выделять ключевое слово несколько раз или
форматировать таким образом целые предложения.
10. Точное вхождение ключевого слова в текстах гиперссылок в дру-
гих документах веб-сайта. По аналогии с учетом внешних факторов – учетом
анкоров внешних ссылок, при расчете релевантности используются и внут-
ренние ссылки. Таким образом, повышается релевантность документа при
наличии ключевых слов в анкорах ссылок внутри веб-сайта. Многие веб-
сайты содержат меню «сквозных» (расположенных на всех страницах) ссы-
лок, где на главную страницу указывает ссылка с анкором «главная». Если
стоит задача повысить релевантность главной страницы по ключевым сло-
вам, то данный анкор недопустим. Эту сквозную ссылку необходимо закрыть
от индексации, оставив ее при этом в меню для пользователей. На главную
страницу должна вести ссылка с анкором в виде ключевых слов.
35
11. Уникальность документа внутри веб-сайта. Многие веб-сайты
содержат большое количество документов, не имеющих полезной для поис-
ковой системы информации. К примеру, результаты поиска по сайту, версии
документов для печати (версии основных документов без графических эле-
ментов), метки (теги), списки документов, сортированные по датам, различ-
ные сортировки данных в таблицах по столбцам. Все эти данные уже проин-
дексированы поисковой системой. К примеру, текст новости проиндексиро-
ван по постоянному адресу, но выдержка из этой новости встречается в поис-
ке по датам опубликования, метках и т.д. Такой документ внутри веб-сайта
уже не уникален. Значительного понижения релевантности не будет, но же-
лательно избегать многочисленного повторения документа или его частей
внутри ресурса.
12. Уникальность документа и веб-сайта в целом в сети Интернет.
Один из важнейших факторов. Особенно важно для относительно новых (ме-
нее 3 лет) веб-сайтов. Веб-сайты, которые содержат большое число докумен-
тов, скопированных (но при этом разрешенных для индексации поисковыми
системами) с других веб-сайтов, могут быть убраны из результатов поиска
или стать нерелевантными ко всем запросам. Старые веб-сайты, имеющие
авторитет, могут размещать неуникальную информацию [41]. К таким мож-
но отнести подавляющее большинство новостных ресурсов, которые копи-
руют новости и пресс– релизы друг у друга и не получают никаких санкций
со стороны поисковых систем.
13. Корректная работа скриптов. Большинство современных веб-сайтов
работают на различных «движках» (скриптах), используют различные систе-
мы управления содержимым. «Чистых» (не берутся в расчет документы, со-
зданные с помощью подмены адресов через ModRewrite [61] или их аналога-
ми) статических документов HTML (т.е. с расширением .htm или .html) ста-
новится все меньше. При этом большинство готовых решений систем управ-
ления содержимым неправильно обрабатывают запросы к документам.
36
Правильная работа скриптов – залог исключения т.н. случайных дублей
информации, а также пустых страниц. Допустим, документ с новостью до-
ступен по адресу: http://www.site.ru/news.php?id=l – по URL–адресу можно с
большой долей вероятности утверждать, что скрипт работает на языке РНР
[5, с.336], а параметр id – идентификатор новости в используемой скриптом
базы данных. Тогда, если скрипт больше нс использует никаких других па-
раметров, при запросе вида http://www.site.ru/news.php?id=l&par=2 веб-сервер
должен возвращать ошибку 404 – не найдено, чтобы поисковый робот не
внес эту страницу в свой индекс, Иначе может возникнуть дублирование ин-
формации, т.к. по адресам:
http://www.site.ru/news.php?id=l
http://www.site.ru/news.php?id==l&par=2
поисковому роботу веб-сервером будет возращен код 200 – найдено, и в ин-
декс поискового робота могут попасть две одинаковые страницы с разными
URL–адресами.
Аналогично должна быть организована проверка корректности значе-
ния параметра URL-адреса: в случае, если новость с идентификатором в базе
данных не существует, веб-сервер должен возвращать ответ 404 [53, с.261] –
не найдено, иначе (а так происходит на 99% веб-сайтах) веб-сервер вернет
код 200 – найдено, и поисковый робот проиндексирует веб-страницу, состо-
ящую из графического шаблона для страницы новостей без текстовой ин-
формации.
14. Запрет от индексации избыточных и служебных страниц и разделов.
Используя стандарт исключений для роботов, необходимо запретить поиско-
вому роботу индексировать служебные разделы веб-сайта (к примеру, папку
со скриптами системы управления (http://www.site.ru/admin/) версии доку-
ментов для печати, различные документы, полученные путем сортировки
таблиц по столбцам, а также любые другие документы, не несущие новой
37
текстовой информации. Для запрета индексации отдельных документов ис-
пользуется файл robots.txt, размещенный в корневой папке:
User–agent: Yandex ,
Disallow: / # блокирует доступ ко всему сайту
User–agent: Yandex
Disallow: /cgi–bin # блокирует доступ к страницам
#начинающимся с '/cgi–bin'
В поле 'User-agent' указывается поисковый робот: Yandex или
Googlebot. Значение 'User-agent' для остальных поисковых систем можно
найти в Интернет.
Затем идет блок с разрешениями ('Allow') или запретами ('Disallow')
страниц и разделов. Нельзя допускать пустые переводы строк между дирек-
тивами 'User-agent' и Disallow' ('Allow'), а также между самими 'Disallow'
('Allow') директивами.
Согласно стандарту перед каждой директивой 'User-agent' следует до-
бавлять пустой перевод строки, так как директив 'User-agent' может быть не-
сколько [50].
Для описания комментариев предусмотрен символ '#'. При этом все,
что расположено после этого символа и до первого перевода строки, не при-
нимается во внимание. Для разрешения доступа поисковому роботу к неко-
торым частям веб-сайта или индексации его целиком, применяйте директиву
'Allow':
User–agent: Yandex
Allow: /cgi–bin
Disallow: /
# запрещает скачивать все, кроме страниц
# начинающихся с '/cgi–bin'
При «наложении» директив выбирается первая в порядке появления в
выбранном User–agent блоке:
38
User–agent: Yandex
Allow: /cgi–bin
Disallow: /
# запрещает скачивать все, кроме страниц
# начинающихся с '/cgi–bin’User–agent: Yandex
User–agent: Yandex
Disallow: /
AJIow: /cgi–bin
# запрещает скачивать весь сайт
Директивы Allow–Disallow без параметров.
Отсутствие параметров у директивы трактуется следующим образом:
User–agent: Yandex
Disallow: # тоже что и Allow: /
User–agent: Yandex
Allow: # тоже что и Disallow: /
Несмотря на то, что стандарт исключений для роботов не является обя-
зательным для использования, большинство поисковых систем руководству-
ются содержимым файла robots.txt перед индексированием документов веб-
сайта [58]. Однако каждая поисковая система имеет свои особенности при
разборе этого файла. Для проведения поисковой оптимизации достаточно
вышеперечисленных примеров. Более полную информацию об анализе файла
robots.txt поисковым роботом Яндекс можно найти на
http://help.yandex.ru/webmaster/ [61].
15. «Понятные» URI–адреса веб–страниц
При проектировании системы управления («движка») веб-сайта необ-
ходимо использовать замену динамических адресов вида:
http://www.site.ru/index.php?a=l&b=2&c=3&d=4 на статические;
http://www.site.ru/al/b2/c3/d4 такой адрес напоминает по структуре вложенные
папки [59].
39
Подмена адресов необходима по следующим причинам.
«Длинные» URI-адреса (адреса с большим количеством параметров
скрипта, в примере выше 4 параметра – a, b, с, d) иногда плохо индексируют-
ся. Особенно это относится к поисковой системе Google.
Поисковые системы подсвечивают слова запроса пользователя,
найденные в URI-адресе. При этом используется транслитерация, единого
стандарта. Чтобы проверить, как именно переводятся кириллица в латиницу,
необходимо вводить запросы в поисковую систему. При этом одна буква мо-
жет иметь несколько вариантов транслитерации, к примеру, для ‘щ’ будут
показаны запросы содержащие ‘sch’ и ’sh’.
Так же в Яндекс есть подсветка в URI-адресах (рисунок 2.2).
Рисунок 2.2 – Подсветка слов запросов в URI веб-сайта
Влияние слов запроса в URI-адресе на релевантность было замечено в
Яндекс при вводе алгоритма «Снежинск». Влияние это минимально, но под-
светка слов запроса делает ссылку более заметной и может повышать CTR
(от англ, click–to–ratio), количество переходов, отнесенной к количеству по-
казов ссылки, выраженное в процентах [56].
Для подмены адресов при использовании веб–сервера Apache следует
произвести загрузку файла «.htaccess» (при этом точка должна стоять именно
в начале имени файла) в папку сервера, в которой будут заменяться адреса. В
40
случае, если скрипты расположены в разных папках, в каждой из них должен
быть свой файл htaccess [60].
Первые две записи приводят в запуск модуль:
RewriteEngine on
Options +FollowSymlinks
Такая запись, как «RewriteEngine off» выступает как отмена всех по-
следующих команд, что крайне удобно: вместо комментирования всех после-
дующие строк нужно просто установить «off».
Опция «+FollowSymlinks» помогает ограничивать применение
mod_rewrite для отдельных каталогов, иначе директивы будут действовать на
весь сервер.
Следующая запись:
RewriteBase /
«/» является корневым (основным) URI Если у вас какой–то другой URI, вы
можете указать это в данной директиве, однако «/» обычно эквивалентно ад-
ресу «http://site.ru».
Файл .htaccess можно читать на ряде серверов после ввода URI следу-
ющего формата в поле адреса вашего браузера: http://www.site.ru/.htaccess.
Это является важным нарушением защиты, поскольку содержание вашего
.htaccess может показать важную информацию об установках и настройках
веб-сайта, что можно применить против вас.
Для обеспечения защиты файла .htaccess от несанкционированного до-
ступа требуется произвести запись в файл:
Rewrite Rule ^.htaccess$ – [F]
Такое правило читается следующим образом: При попытке обращения
к файлу .htaccess система должна произвести код ошибки «HTTP response of
403» или «403 Forbidden – You don't have permission to access /.htaccess on this
server» – доступ к файлу .htaccess запрещен [48].
Конструкция ^. Htaccess$ в этом регулярном выражении означает:
41
^ – якорь начала строки;
$ – якорь конца строки.
Между начальным и конечным якорем должно находиться имя файла,
что будет выступать гарантией того, что только оно и никакое другое высту-
пить источником сгенерирования кода ошибки.
[F] – специальный «запрещающий» флажок (forbidden).
В данном примере, файл ".htaccess" будет включать в себя следующие
строки:
RewriteEngine on
Options +FollowSymlinks
RewriteBase /
RewriteRule ^.htaccess$ – [F]
В итоге содержимое файла «.htaccess» будет выглядеть следующим об-
разом:
RewriteEngine onOptions +FollowSymlinks
RewriteBase /
RewriteRule ^ htaccess$ – [F]
Для «подмены» адреса: http://www.site.ru/cgi–bin/sliop.cgi?productl на
http://www.site.ru/shop/productl необходимо использовать следующую кон-
струкцию в файле .htaccess:
RewriteRule ^(.*)shop/(.*)$ $lcgi–bin/shop.cgi?$2
$l и $2, используемые нами, представляют «backreferences», которые
связаны с текстовыми группами. Вызываемый URI разделяется на части. Всё,
что находится перед и после «shop/», определяется и хранится в двух упомя-
нутых переменных: $l и $2.
Для записи вида:
RewriteRule ^(.*)shop/(.*)$ $lcgi–bin/shop.cgi?$2 применяется общий синтак-
сис: RewriteRuIe текущий URL перезаписываемый URL Эта директива вы-
полняет «подмену» URI адреса.