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

Россия+7 (495) 960-65-87
Шрифт:
0 3512

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. О том, что это такое и как это работает, написано уже большое количество статей. Их можно посмотреть на:

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


$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 '
  • < a href="'%20.%20%24item%5B'url'%5D%20.%20'" rel="nofollow" target="_blank">' . $item['title'] . '< /a>
  • ';
    }
    ?>

=$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 '
  • < a href="'%20.%20%24item%5B'url'%5D%20.%20'" rel="nofollow" target="_blank">' . $item['title'] . '< /a>
  • ';
    }
    ?>

=$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» Д.Н. Колисниченко.

Есть о чем рассказать? Тогда присылайте свои материалы Даше Калинской


Новые 
Новые
Лучшие
Старые
Сообщество
Подписаться 
Подписаться на дискуссию:
E-mail:
ОК
Вы подписаны на комментарии
Ошибка. Пожалуйста, попробуйте ещё раз.
Отправить отзыв
    ПОПУЛЯРНЫЕ ОБСУЖДЕНИЯ НА SEONEWS
    SEOnews и Serpstat запускают конкурс для интернет-маркетологов
    Marina Lagutina
    1
    комментарий
    0
    читателей
    Полный профиль
    Marina Lagutina - Добрый день! Видимо я из тех, кто пытается последней вскочить в уходящий поезд. Ночью написала статью на тему "обзор инструментов контент-маркетинга". Своего блога нет. Отправила вам не мейл. Я еще могу у вас разместиться или искать, кто возьмет статью к себе в блог?
    «Я оптимизировал сайт, а он не в ТОП! Что делать?»
    Павел Горбунов
    7
    комментариев
    0
    читателей
    Полный профиль
    Павел Горбунов - Как можно в инструменте tools.pixelplus.ru/tools/text-natural сравнить текст со страницы конкурента и со своей страницы? Я вижу возможность только для проверки одного урла.
    Монетизация сайта. Как, когда, сколько?
    Гость2
    1
    комментарий
    0
    читателей
    Полный профиль
    Гость2 - Руслан! Спасибо за ваш сервис и за данную статью в частности! С апреля являюсь вашим пользователем - очень доволен как сервисом, так и уровнем заработка! Еще раз спасибо, удачи вашему проекту!
    Мир глазами поисковых систем
    Александр Рунов
    7
    комментариев
    0
    читателей
    Полный профиль
    Александр Рунов - Какой регион, если не секрет? В Мск, в ряде ВК тематик (в тех же "окнах" или "колесах"), без работы с внешними факторами по ВЧ запросам в ТОП не выплывешь. Хотя в большинстве направлений вполне реально.
    Влияние HTTPS на ранжирование региональных поддоменов в Яндексе
    Екатерина Иванова
    1
    комментарий
    0
    читателей
    Полный профиль
    Екатерина Иванова - Посмотрите на сколько упал трафик и на сколько потом вырос:упал на 10-20% на 1 месяц, а вырос в итоге в 5 раз. Одним мартовским трафиком всё падение перекрыли. Или можно ждать Яндекс неопределённое количество времени со стартовым уровнем трафика. Упущенные возможности и всё-такое.
    Google.ru внесли в реестр запрещенных сайтов
    Гость
    1
    комментарий
    0
    читателей
    Полный профиль
    Гость - Гон, все работает и будет работать. Да и пусть банят, будет как с рутрекером.
    День рождения SEOnews: 12 лет в эфире!
    Анна Макарова
    308
    комментариев
    0
    читателей
    Полный профиль
    Анна Макарова - Ура )
    7 причин не работать на биржах копирайтинга
    Dasha Shkaruba
    6
    комментариев
    0
    читателей
    Полный профиль
    Dasha Shkaruba - Спасибо за мнение! Кстати, на бирже главреда прием анкет закрыт
    Инфографика: самые распространенные SEO-ошибки Рунета
    Alex Wise
    3
    комментария
    0
    читателей
    Полный профиль
    Alex Wise - Спасибо, Женя, за рекомендацию! :) Андрей, чтобы понять, какой программой пользоваться, нужно сделать несколько вещей: 1. Попробовать обе: у нас в Netpeak Spider бесплатный триал на 14 дней с полным функционало; у SFSS до 500 URL всегда бесплатно, но с ограниченным функционалом. 2. Понять свой стиль работы – если вы любите полный контроль и из-за этого более высокую скорость пробивки, тогда выбирайте Netpeak Spider. Если для вас не так важна скорость и количество пробитых URL, то можно остановиться на SFSS. 3. Определиться с нужными функциями: их в обоих программах очень много и как в Netpeak Spider есть уникальные, так и в SFSS есть свои уникальные. Мы всегда ориентируемся на то, чтобы быстро и чётко показать ошибки – для этого у нас вся таблица красится в соответствующие цвета. Думайте!) И, если что, обращайтесь с вопросами – мы будем рады помочь!)
    Интеграция call tracking и CRM: углубленный анализ данных о звонках и продажах
    Денис
    2
    комментария
    0
    читателей
    Полный профиль
    Денис - Какой смысл вообще в облачных CRM, обрезанный фугкционал, свое дописать невозможно, слив клиентов другим компаниям. Серверные бесплатные CRM куда надежней и кастамизируй как хочешь.
    ТОП КОММЕНТАТОРОВ
    Комментариев
    910
    Комментариев
    834
    Комментариев
    554
    Комментариев
    540
    Комментариев
    483
    Комментариев
    373
    Комментариев
    308
    Комментариев
    262
    Комментариев
    224
    Комментариев
    171
    Комментариев
    156
    Комментариев
    137
    Комментариев
    121
    Комментариев
    97
    Комментариев
    97
    Комментариев
    95
    Комментариев
    80
    Комментариев
    77
    Комментариев
    67
    Комментариев
    60
    Комментариев
    59
    Комментариев
    55
    Комментариев
    53
    Комментариев
    52
    Комментариев
    46

    Отправьте отзыв!
    Отправьте отзыв!