Доработки CMS под продвижение (динамические URL, идентификатор сессий и мета-теги)

1. Введение
2. От динамики к статике
3. Идентификаторы сессий
4. Мета-теги
5. Заключение

1. Введение

Существует большое количество технологий для создания сайтов. Особенно популярны так называемые CMS (Content Management Systems) или системы управления контентом. Это системы, позволяющие упростить процессы создания и управления сайтов. Но создатели таких систем не всегда заботятся о будущем продвижении ресурса. Чаще всего упускают из вида некоторые детали, которые позволили бы сократить время и средства на подготовку проекта к продвижению.

Среди них можно выделить:

1. Динамические урлы.
2. Идентификатор сессий.
3. Метатеги.

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

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

Некоторые соглашения:

1. Под платформой в этой статье будет пониматься готовая система для создания сайта, которая включает как саму CMS, так и окружение (OC, сервер, дополнительные программы и настройки).
2. Все ниже изложенное относится к языку программирования php и серверу apache.

2. От динамики к статике

Очень часто можно видеть в строке запроса адреса вида index.php?part=2&page=1 или /?page=about и тп. Простому пользователю в принципе все равно, как выглядит адрес, а поисковой машине - не совсем. Почему появляются такие адреса? Очень просто. Большая часть CMS построена по принципу: физически одна страница, которая в зависимости от переданных параметров (GET запрос) отображает нужное содержание. Является ли это проблемой? Раньше, когда поисковые роботы не понимали символов типа ? Или & - это была проблема. Сейчас поисковые машины стали нормально понимать такие адреса и ведется много споров о том, хуже или лучше продвигать страницы с динамическими адресами. По моему субъективному мнению, сайт со статическими урлами выглядит, по крайней мере, представительней в глазах пользователя. Проще запомнить страницу типа www.foo.ru/about и затем зайти на нее еще раз, чем страницу с именем www.foo.ru/index.php?article=about. Да и у поискового робота будет меньше проблем.

А что делать, если уже есть система, которая формирует динамические адреса вида?
Выхода 2: Изменить систему и исправить существующую (или правильно настроить). Первый вариант предпочтителен в следующих случаях:

1. ресурс только создается, и выбирается платформа;
2. ресурс небольшой, и легко переносимый;
3. принято решение о координальной смене платформы (редизайн, функционал и т.п.).

В этом случае необходимо обратить внимание на следующие моменты:

1. Система должна уметь формировать статические адреса.
2. В системе должна быть возможность изменять метатеги для всех страниц, в том числе и для формируемых динамически.
3. Скорость генерации страниц должна быть достаточно высокой.

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

Перейдем непосредственно к статическим адресам. Существует несколько способов создать статические адреса. Основные принципы можно посмотреть в статье "Человеко понятные урлы (ЧПУ)". Здесь на примере расскажем о mod_rewrite. О том, что это такое и как это работает, написано уже большое количество статей. Их можно посмотреть на:

http://www.opennet.ru/docs/RUS/rewriteguide/

http:\/\/sitemaker\.ru\/technologies\/webserver\/mod_rewrite\/

http:\/\/httpd\.apache\.org\/docs\/1\.3\/mod\/mod_rewrite\.html

Поэтому пропустим описание, перейдем к сути.
Допустим, у нас есть сайт, который состоит физически из одной страницы, и в зависимости от параметров, выдает нужное содержание. Ниже приведен пример кода такой страницы.

$menu = array();
$menu['main'] = array('url' => '/index.php', 'title' => 'Главная');
$menu['about'] = array('url' => '/index.php?page=about', 'title' => 'О компании');

if ($_GET[page] == 'about') {
   $title = 'О компании';
   $content = 'Это статья о компании';
} else {
   $title = 'Главная';
   $content = 'Это главная страница';
}
?>

< title >=$title?>

foreach ($menu as $item) {
   echo '
• ' . $item['title'] . '
';
}
?>

=$content?>

Первое что нужно сделать - это переписать код таким образом, чтобы все ссылки формировались статически. Для вышеприведенного примера это будет:

$menu = array();
$menu['main'] = array('url' => '/', 'title' => 'Главная');
menu['about'] = array('url' => '/about/', 'title' => 'О компании');

if ($_GET[page] == 'about') {
   $title = 'О компании';
   $content = 'Это статья о компании';
} else {
   $title = 'Главная';
   $content = 'Это главная страница';
}
?>

< title >=$title?>

foreach ($menu as $item) {
   echo '
• ' . $item['title'] . '
';
}
?>

=$content?>

При этом естественно, главная страница будет отображаться, а страничка "О компании" будет выдавать 404 ошибку. Вот тут нам и понадобится mod_rewrite. Создаем файл .htaccess (системный файл сервера apache, необходимый для хранения нужных настроек) в корне сайта. Вначале нам нужно включить реврайтовый движок. Пишем в созданном файле:

RewriteEngine On

Теперь нам нужно объяснить серверу, что адрес /about/ на самом деле /index.php?page=about. Делается это примерно следующим образом:

RewriteRule ^about/$ /index.php?page=about [L]

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

RewriteRule ^([a-z]+)/$ /index.php?page=$1 [L]

В этом случае все адреса вида /Что_либо/ будут перенаправляться на /index.php?page=Что_либо. Следует также заметить, что это будет так называемый "внутренний редирект". То есть при запросе страницы /about/ мы получим 200 ответ, а не 3хх, что очень важно.

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

1. В нашем примере любая страница (кроме about) будет главной. То есть если мы наберем /foo/, мы получим содержание главной страницы. Это может привести к появлению дублей и склейке страниц. Поэтому необходимо внимательно следить за тем, чтобы такие страницы закрыть. Например, принудительно ставить 404 заголовок или перенаправлять на страницу, которая отдает его.
2. Могут возникнуть проблемы с регулярными выражениями. Например, на одном хостинге RewriteRule ^about/$ /index.php?page=about [L] сработает, а на другом нужно будет написать RewriteRule ^about/$ http://www.foo.com/index.php?page=about [L].
3. mod_rewrite может просто не быть на хостинге или запрещено использование .htaccess. В большинстве случаев достаточно позвонить на хостинг и попросить настроить.
4. Многие современные системы достаточно сложны, и может понадобится длительное время на переработку кода. Приведенный пример подходит для небольших систем. В другом случае стоит задуматься о переходе на другую систему.

Для людей, которые только планируют создавать сайт, стоит заложить в систему данную возможность.

3. Идентификаторы сессий

В некотором роде продолжение первого пункта. Идентификаторы сессий действительно большая проблема для продвижения. Сессии – это механизм, позволяющий однозначно идентифицировать пользователя (браузер), а также создать для этого пользователя файл на сервере, в котором хранятся нужные переменные сеанса в течение работы. Для идентификации пользователя используется идентификатор сессий – SID (Session Identifer). С его помощью сервер определяет, какой пользователь к нему обращается и выбирает нужные данные из соответствующего файла. Для того чтобы это работало необходимо пользователю вначале передать такой идентификатор, а потом запрашивать его при каждом обращении к серверу. Существует 2 способа передачи: при помощи cookie или в строке запроса, при помощи метода GET. Именно второй вариант вызывает проблему, так как появляются адреса вида: http://www.foo.ru/index.php?PHPSESID=1ac79eda21a164672e1665b698ff8723. Но это было бы не страшно, если бы этот идентификатор был постоянным, однако у сессии есть время жизни. И при следующем заходе на страницу php сгенерит новый идентификатор сессии. Это может повлечь за собой 2 проблемы: появятся много разных страниц с абсолютно одинаковым содержанием, причем при каждом обходе будет добавляться новая страница, или проиндексируется одна страница, а при переходе по этой ссылке страница может выдать ошибку, так как такой идентификатор уже не существует.

Эта большая проблема решается на удивление достаточно просто (в большинстве случаев). Решается все тем же файлом .htaccess.
Достаточно прописать туда следующие строки:

php_flag session.use_only_cookie On

“говорит” серверу – передавать идентификатор сессий через cookie
и

php_flag session.use_trans_sid Off

“выключает” передачу идентификатора сессий через присоединение его к урлам.

В этом случае информация об идентификаторе сессии будет хранится в cookie.

Возможные проблемы:

1. У пользователя могут быть отключены cookie. Но таких немного.
2. Не разрешено использование .htaccess. Как и выше – чаще всего решается звонком или письмом в службу поддержки.

4. Мета-теги

Очень часто забывают о таких элементах, как мета-теги. Об их полезности уже много написано. Вот цитата с форума: «В общем и целом поисковик работает, как этакий браузер, который бродит по ссылкам, загружает страницы и анализирует текст. Отсутствие мета-тегов не критично, но при грамотном использовании они могут повысить видимость в поисковиках».

Проблема одна: отсутствие мета-тегов на нужных страницах.
Решений же может быть несколько.

1. Для небольшого статического сайта достаточно прописать их на страницах. Для этого даже ничего не нужно знать, кроме основ HTML.
2. Для небольшого динамического сайта, в котором вообще отсутствует такая возможность, я могу предложить следующее решение (оно не является единственным или очень красивым, однако в большинстве случаев срабатывает, и не отнимает много времени).

Создаем файл, например, metha.php, в котором пишем код:

    // по дефолту
    $RZ_title = 'Заголовок';
    $RZ_kw = 'Ключевые слова';
    $RZ_ds = 'Описание';

    /* если надо - перепишем по строке запроса*/
    /* в case пишем адреса относительно начала сайта */
    switch ($_SERVER["REQUEST_URI"]) {
      case '/' : // для главной
       $RZ_title = 'главная';
       $RZ_kw = 'слова на главной';
       $RZ_ds = 'описание для главной';
       break;
      case '/about/' :
       $RZ_title = 'Другая страница';
       $RZ_kw = 'слова Другая страница';
       $RZ_ds = 'описание для Другая страница';
       break;
    }
?>

Количество переменных можно увеличить, например, добавить уникальный альт картинки для каждой страницы, или добавить, например, афоризм или ссылку.

Кладем данный файлик в корень сайта.

Далее на каждой странице вначале делаем
include('metha.php') ?>
И в нужных местах вставляем, например,
< title > echo $RZ_title; ?>

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

Достоинства данного метода:

1. Мы можем указать значения для любой страницы с вероятностью 99%.
2. Предложенный метод расширяем и модифицируем.
3. Легко встроить практически в любую CMS.
4. Можно править значения только в одном месте.

Недостатки:

1. Подходит только для небольших ресурсов или как временная заглушка.
2. Необходимо следить за именами переменных, чтобы не переписать системные или нужные переменные.
3. Для большого динамического сайта, построенного на системе, в которой не предусмотрены мета-тэги можно либо доработать (но на это потребуется время и ресурсы, однако результат будет самым лучшим), либо поменять систему, либо использовать предыдущую заглушку (если продвигается небольшое количество страниц).

5. Заключение

Еще раз повторюсь, что статья не является решением всех проблем. Здесь были показаны лишь некоторые способы, которые реально применялись на практике. Также в статье приведены некоторые ссылки, которые могут быть весьма полезны.
В статье применялись некоторые определения из книги «Самоучитель PHP 5» Д.Н. Колисниченко.