Alto CMS и SEO — возможности «из коробки» и из плагинов

Есть у меня подозрение, что многие админы сайтов, создаваемых на базе Alto CMS, просто не знают всех возможностей СЕО-оптимизации, которые заложены в функционал движка или дополняются бесплатными плагинами. Вот и решил я об этом рассказать.
Файл robots.txt
Файл robots.txt идет прямо в комплекте с движком. Не стану утверждать, что это идеальный вариант, но рискну предположить, что он подойдет для большинства сайтов на Alto CMS. Но вы, разумеется, можете всегда отредактировать его, как посчитаете нужным.

Тег <title>
По умолчанию значение тега <title> состоит из нескольких частей, разделенных знаком слеш — «/». Но в конфигурации движка можно задать правила, по которым формируется это значение.
// максимальное число частей, из которых состоит тег &lt;title&gt;
$config['view']['html']['title_max']   = 0;       

// разделитель между частями тега &lt;title&gt;
$config['view']['html']['title_sep']   = ' / ';   

// строка, которая всегда добавляется в конец значения тега &lt;title&gt;
$config['view']['html']['title']       = '___view.name___';

Мета-тег <description>
По умолчанию значение мета-тег <description> для статей формируется из нескольких начальных слов текста. Число слов задается в конфиг-файле:
// количество слов из статьи для вывода в мета-тег &lt;description&gt;
$config['view']['html']['description_max_words'] = 20;

Структура URL статей и ЧПУ
Вид URL статей задается в админке. Подробнее об этом можно прочитать в статье ЧПУ в Alto CMS — в стиле Livestreet, Wordpress, NiceURL и вообще как угодно.

Редирект на новые адреса
Если вы переехали на Альто с другого движка, где была иная структура адресов, или решили на сайте изменить правила формирования URL, либо еще по каким причинам у вашего сайта изменились адреса, то вы можете задать правила редиректа со старых адресов на новые, используя настройки, описанные в статье Внешний редирект средствами движка

Это то, что вы можете использовать в Alto CMS прямо «из коробки» без каких-либо дополнительных плагинов. Но есть еще несколько бесплатных плагинов, о которых, как минимум, стоит знать.

Плагин sitemap
Формирует карту сайта, позволяет указать, какие разделы стоит включать в карту, задать такие параметры, как частоту обновления, приоритет индексирования и т.д.
Плагин Seopack — Управление SEO-параметрами страниц
Для любой страницы сайта вы можете задать совершенно произвольное значение тега <title>, а также мета-тегов <description> и <keywords>. Эти значения привязываются к URL страницы и при ее отображении выводятся в HTML вместо стандартных.
Плагин Похожие статьи
Этот плагин, конечно, в первую очередь для людей создан, чтобы им проще было находить нужную информацию, но есть мнение, что поисковики тоже любят перекрестные ссылки между релевантными страницами.

А в заключение — цитата из Руководства по поисковой оптимизации для начинающих от компании Google:
...мы хотели бы еще раз привлечь ваше внимание к тому, что в первую очередь оптимизация вашего сайта должна быть рассчитана на пользователей. Именно они являются целевой аудиторией вашего сайта. Излишняя увлеченность специфическими трюками для достижения максимума в топе может не принести желаемых результатов. Оптимизация для поисковых систем – всего лишь способ немного вырваться вперед, в том, что касается видимости для поисковых роботов, но вашей целевой аудиторией являются пользователи интернета, а не поисковые системы.

Похожие статьи

  • Плагин Sitemap адаптирован под Alto
    Конечно, механизм генерации sitemap должен быть в коробке любого более-менее серьезного движка. Но чтоб он в коробке оказался, его туда нужно положить. А у предка Альто такого функционала не было изначально. Поэтому...
  • Дублирование страниц
    Добрый день! Сегодня обнаружил в метрике, что она и та же страница отображается по разным ссылкам: http://site.ru/blog/category/1.html и http://site.ru/ru/blog/category/1.html Причем в коде и у той и у той...
  • Замена title плагином
    Всем привет! Можно ли заменить title у всего сайта (добавление значения, изменение)например добавить номер страницы у блогов и тд. Это нужно для борьбы с дубль title для гугла. Сейчас я сделал это в ядре, но...
  • Плагин Sitemap — обновление
    Плагин Sitemap был обновлен, и в каталог выложены две его новых версии: 1.0.3 и 1.1.2. Первая версия предназначена для работы на сайтах под Alto CMS 1.0.+ (и на более ранних), а вторая — для Alto CMS версии 1.1....

45 комментариев

0
Кстати, было бы неплохо еще настроить для Альто корректную отдачу заголовков Last-Modified, сейчас они вообще не отдаются, проверить можно тут
0
А это уже, наверное, задача сервера, не?
0
На сервере конечно можно пошаманить и добиться отдачи заголовков, но они будут некорректны для динамических страниц, под каждую CMS для этого дела свои функции с запросами к БД.
Вот один из примеров:


// <!-- Запрет кэширования страниц браузерами и proxy-серверами -->
function NoCache($lastmodified=""){
  if($lastmodified=="")
	$lastmodified=mktime(date("H"),date("i"),date("s"),date("m"),date("d"),date("Y"));
  header("Last-Modified: ".gmdate("D, d M Y H:i:s",$lastmodified_t)." GMT");
  header('Expires: '.gmdate("D, d M Y H:i:s").' GMT');
  header('Content-Type: text/html; charset=windows-1251');
  Header("Cache-Control: no-cache, must-revalidate");
  Header("Pragma: no-cache");
  Header("Last-Modified: ".gmdate("D, d M Y H:i:s",$lastmodified)." GMT");
}

##################################################


	//Проверка времени последнего обновления документа
	if (isset($_SERVER['HTTP_IF_MODIFIED_SINCE']) && $_SERVER['HTTP_IF_MODIFIED_SINCE']!="") 
		$modifiedSince = date2unixstamp($_SERVER['HTTP_IF_MODIFIED_SINCE']);
	else 
	{ 
		// Устанавливаем время модификации в ноль
		$modifiedSince = 0; 
	} 
	
	if((int)$page['date_modified']>0) 
	{
		$lastmodified=gmmktime(substr($page['date_modified'],11,2),substr($page['date_modified'],14,2),substr($page['date_modified'],17,2),substr($page['date_modified'],5,2),substr($page['date_modified'],8,2),substr($page['date_modified'],0,4));
		$lastmodified_t=mktime(substr($page['date_modified'],11,2),substr($page['date_modified'],14,2),substr($page['date_modified'],17,2),substr($page['date_modified'],5,2),substr($page['date_modified'],8,2),substr($page['date_modified'],0,4));
	}
	else 
	{
		$lastmodified_t=mktime(date("H"),date("i"),date("s"),date("m"),date("d"),date("Y"));
		$lastmodified=gmmktime(date("H"),date("i"),date("s"),date("m"),date("d"),date("Y"));
	}
	
	// Сравниваем время последней модификации контента с кэшем клиента
	if ($lastmodified < $modifiedSince) 
	{ 
		// Разгружаем канал передачи данных!
		unset($headers);
		header("HTTP/1.1 304 Not Modified");
		exit(); 
	}
}

foreach($headers as $k=>$v)	
	header($v);	
if($error_no===false) {
	echo $content;
	die();
}
NoCache($lastmodified_t);



//вывод содержимого
echo $content;
0
Пардон, я спросонья немного не в дугу ответил. Конечно, для динамических страниц значение для Last-Modified должно формироваться движком, не сервером.

Я имел ввиду, что вот эту логику — проверка заголовков от клиента If-Modified-Since/If-None-Match и, если что, отправка 304 без контента — вот это, как мне казалось, должен делать сервер, а не движок. Хотя, я могу ошибаться, не вполне в этом уверен.
0
Промаявшись полдня ощущением дежавю, таки восстановил картину мира, и вспомнил, что когда-то сам озадачивался уже такой темой, но так и не пришел ни к какому решению и вот почему.

Вот есть, например, это страница, где сейчас комментарии пишем. Какое значение ставить у last-modified? Учитывая, что есть сам топик, и к нему могут быть (а могут и не быть) комменты, то это либо дата создания топика, либо дата его редактирования, либо дата последнего комментария, либо дата редактирования комментария. В общем, одна из четырех дат (самая последняя существующая из них). Но есть еще и прямой эфир в сайдбаре — надо и оттуда дату проверять. Но есть еще и список блогов, есть виджет со списком плагинов. На других сайтах могут быть свои виджеты, и мы не можем наверняка знать, когда в последний раз обновились данные, которые в них отображаются.

В общем, получается, что сделать-то можно, но надо понимать, что тогда часть элементов на странице у юзеров будут обновляться с задержкой по времени. Для нагруженных проектов это может быть и допустимо, но вряд ли все владельцы сайтов этого захотят.
+2
По большому счету AltoCMS с точки зрения SEO оптимизации, соотв. большей части требований поисковых систем, ничуть ни уступая DLE, Joomla и т.д. и как мне кажется намного лучше Wordpress.

Но при этом, есть несколько моментов, которые необходимо учитывать вебмастеру при создании сайта на AltoCMS:

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

2. Переадресация с www на site.ru (похоже уже реализовано) и переадресация с index.php и index.html на site.ru/

В htaccess последнее будет выглядеть примерно так
### Редиректы с index.php или index.html на сайт
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.(php|html)\ HTTP/
RewriteRule .* / [R=301,L]


3. Дублирование страниц со слешами и без них. Почти все страницы/разделы дублируются site.ru/people и site.ru/people/, в т.ч. и простые статьи (т.е. одна и та же страница доступна с разных url), что может привести к большому количеству дублей и как следствие пессимизации в поисковой выдаче. Вероятнее всего, так же можно решить средствами htaccess.
0
Касательно 3 пункта, ведь ссылки на сайте везде указываются со слешом в конце. Откуда поисковик узнает о неправильных?
0
Это не имеет особого значения, на вас могут поставить ссылку site.ru/people с другого сайта (любые другие варианты) и если не будет переадресации на site.ru/people/, она проиндексируется как отдельная страница.
0
Не замечал подобных проблем. В индексе нет таких страниц без слеша у меня.
0
это не значит, что со временем они не появятся, особенно если на сайт активно ссылаются.

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

Тем более в адресной строке, откуда копируют пользователи, эти страницы всегда со слешем, т.е. это его надо еще и специально убрать.
0
не думаю что поисковики такие тупые
Они и не тупые. Это роботы и они следуют правилам.

Как это повлияет на выдачу — однозначного ответа нет и выяснить это можно только опытным путем.
хоть как-то повлияет на какие-то позиции
Источник информации, что это не влияет на позиции — два дубля одной и той же страницы?
0
Они и не тупые. Это роботы и они следуют правилам.

Роботов пишут люди.

Источник информации, что это не влияет на позиции — два дубля одной и той же страницы?

о_О
0
При правильной верстке на самом сайте ссылок без слеша быть не должно, это верно. Но Алена права в том, что рано или поздно поисковик может узнать о вариантах и без слеша. Как решать эту проблему — на уровне .htaccess, на уровне конфига или аж на уровне экшенов — у меня нет пока хорошего рецепта.

И интересно — кто-нибудь изучал, как подобные проблемы решаются в других CMS?
Отредактирован:
0
Попробовал в вордпрессе, срабатывает 301 редирект на уровне кода php. А вот где именно пока не смог найти.
0
И интересно — кто-нибудь изучал, как подобные проблемы решаются в других CMS?

В DLE например это решается с помощью php, есть отличная статья alaev.info/blog/post/2400

Кусок кода оттуда, не знаю будет ли полезным…
//решение проблемы с категориями, редирект на верный урл, добавление слеша в конец
			if( $config['allow_alt_url'] == "yes" AND $category_id AND $view_template != "rss") {
 
				$re_cat = get_url( $category_id );
 
				if ($re_cat != $_GET['category'] OR substr ( $_SERVER['REQUEST_URI'], - 1, 1 ) != '/' ) {
					$re_url = explode ( "index.php", strtolower ( $_SERVER['PHP_SELF'] ) );
					$re_url = reset ( $re_url );
 
					header("HTTP/1.0 301 Moved Permanently");
					header("Location: {$re_url}{$re_cat}/");
					die("Redirect");
				}
			}
//решение проблемы с категориями, редирект на верный урл, добавление слеша в конец
0
Вот такое правило в .htaccess решает эту проблему:

RewriteCond %{REQUEST_URI} !\?
RewriteCond %{REQUEST_URI} !\&
RewriteCond %{REQUEST_URI} !\=
RewriteCond %{REQUEST_URI} !\.
RewriteCond %{REQUEST_URI} !\/$
RewriteRule ^(.*[^\/])$ /$1/ [R=301,L]

Только его нужно его добавить ДО переадресации на index.php

Почему-то мне кажется, что это более верный подход
Отредактирован:
0
а при отсутствии апача? Многие живут php-fpm + nginx
0
Мда, что-то я все время упускаю этот момент. С nginx я как-то не очень дружу, но есть уверенность, что подобные же правила и там можно сформулировать. Причем, с одной стороны, чисто на nginx сидят те, кто юзает VPS/VDS (на шаред-хостинге не встречал я такого), значит, им доступны любые файлы конфигурации. С другой — они могут быть такими же чайниками, как и шаред-юзеры, и что-то править в конфигах (а не просто .htacces в корне сайта) для них может быть опасно.

Надо думать…
0
… и переадресация с index.php и index.html на site.ru/
А вот это, по-моему, совсем не обязательно, т.к. на странице site.ru/index.php в HTML-коде будет:
<link rel="canonical" href="http://site.ru/"/>
0
Вот так и не поняла, их нужно вместе использовать или можно обойтись одним, например «canonical». Сам гугл рекомендует 301 редирект для таких случаев, как один из самых надежных support.google.com/webmasters/answer/139066?hl=ru#4
0
Это про другое.
0
Вы сейчас о чем?
0
Суть такая: допустим, есть адреса «site.ru/a.html» и «site.ru/b.html», которые отображают один и тот же контент, но мы считаем, что «a.html» — это каноническая страница. Если мы ставим редирект с «a.html» на «b.html», то страницу «b.html» робот даже и не загружает, а сразу идет, куда нужно.

Если использовать rel=canonical на «b.html», то робот ее загрузит, распрасит, увидит директиву и на индексацию отдавать не станет. Но при этом Гугл оговаривает, что, теоретически, возможны какие-то баги, глюки и прочие обстоятельства, при которых страница «b.html» все же может случайно оказаться в индексе.

Поэтому редирект, конечно, более предпочтителен (т.к. исключает всякие случайности), но с точки зрения логики (как должна работать индексация) использование rel=canonical вполне достаточно.
0
Тут еще момент, что пользователь не видит тег rel=«canonical» и теоретически может заходить на site.ru/ и site.ru/index.php, а так же в теории давать ссылки на оба адреса. В этом случае ссылочный вес страницы может разделиться между site.ru/ и site.ru/index.php, т.к. для суммирования ссылочного веса нужна исключительно склейка страниц, а это 301 редирект.

Вообще насколько я понимаю сам тег canonical говорит о содержимом страницы, но не передает ее вес.
0
Уже представил пользователя который к site.ru дописывает «index.php» (помимо того что удаляет слеши перед тем как ссылки выкладывать)
0
Вы мне напоминаете одного человека, который недавно здесь насоздавал кучу тем в т.ч. про SEO, а потом их удалил. Аргументы у вас примерно те же.

Написать могут все что угодно в т.ч. дописать index.php и не скопировать слеш. Вы бы наверное сильно удивились, узнав какие письма иногда приходят администрации крупного проекта от пользователей.

Но дело даже не в этом, существует свод правил и рекомендаций, которых как мне кажется желательно придерживаться.
0
Переход на личности засчитан, Алена.
0
Ничего личного, просто мнение по поводу ваших последних комментов.
0
С точки зрения сео цмс конечно — тихий ужас. Тайтл, который выводится и в шапке, и в тайтле. Тайтл — очень важный параметр… мегаважный для продвижения (!!!). К примеру я хочу в тайтле иметь фразу «Крутой магазин про продаже резиновых ботинок». Но в шапке я хочу, чтобы выводился адрес сайта — sapojki.ru. Так вот хрен там. Но тут ладно, тут плагин сеопак, думаю, поможет. Почему в статье заголовок идет под тегом h2, а не h1? Это ГРУБЕЙШАЯ сео-ошибка. Почему в списке обзоров при клике на картинку-превью мне открывается эта картинка по центру экрана (как этот дурацкий джиквери плагин отключить мне так и не ответили :(), вместо того, чтобы переходить в полную статью. Ну и как выше сказала Alyona, везде надо подчищать дубли. Редиректы с индекса, с безслеша на слеш итд. Чтобы в пагинаторе не было page1 (а здесь он есть во всех разделах, включая главную) — в итоге дубли дубли дубли.
Я не то, чтобы ругаюсь. Давайте просто вместе доведем все до ума. Я уже у себя допилил некоторые моменты, но на некоторые у меня пока не хватает знания движка.
Отредактирован:
0
Почему в статье заголовок идет под тегом h2, а не h1?

Рекомендую к прочтению sites.google.com/site/webmasterhelpforum/ru/stati/rukovodstvo-po-poiskovoj-optimizacii-dla-nacinausih-ot-google/rukovodstvo-po-poiskovoi-optimizatsii-dlya-nachinayushchikh-ot-google


А по факту, изменить под себя, думаю не потребует много времени. По умолчанию же, как мне кажется лучше придерживаться рекомендаций гугла.
0
Так в алтоцмс в статье H1 тупо вообще нет :)
Вообще я всегда делаю так. В h1 у меня название статьи. Допустим «Обзор планшета Lenovo blabla8». Далее идет какой-то кусочек текста и пошли подзаголовки с тегами h2 и под ними текст. Типа «Характеристики планшета Lenovo blabla8» — и ниже пишем характеристики. Еще один подзаголовок «Дисплей планшета Lenovo blabla2» — и ниже пишем про дисплей.

По факту меняется за минуту — в topic.type_default-show.tpl меняем h2 на h1 и в стилях прописываем размер.

ПыСы Кстати гугл мой блог не очень любит, зато яндекс просто обожает.
ПыПыСы И добавьте в редактор тег спойлер, наконец )
0
H1 пусть и недавно, но появился.

У страниц page1 стоит
<link rel="canonical" href="http://demo.altocms.ru/new/index/newall/"/>
0
Я вчера качал последнюю бету и никакого h1 там не увидел. Ставил шаблон experience simple.
По поводу пагинации — принял. Тогда с этим все ок.
0
h1 в соответствии с рекомендациями гугла проставлен на заголовке сайта. А новости имеют теперь h2 вместо прежнего h3
0
А вот на этот сайт 80% заходов из поисковиков — это Гугл
0
У меня с яндекса 65%, остальное делят гугл и мейл. Суммарно где-то 4к уников в сутки. Это не очень много, в принципе. Вот щас новый блог стал делать — на вашей цмс.
0
А вот если по какой бы то ни было причине в индексе окажутся site.ru и site.ru/index.php их вес разделится и это может принести серьезные неприятности для сайта.
0
Как и между site.ru и site.ru/page1. Вообще сеошники рекомендуют страницы пагинации закрывать все кроме первой. Лучше всего через мету роботс и noindex,follow.
0
Трудно, конечно, въехать сразу, где тайтл — это тайтл, а где тайтл — это просто тайтл. Но повторю то, что уже есть в статье:

1) В конфиге можно задавать правила формирования тега <title>, как хотите. В т.ч. можете задать обязательную часть, а можете и не задавать.

2) С помощью плагина Seopack можно задавать абсолютно произвольные значения <title> без всяких правил, как левая нога захотела, на любых страницах сайта.

3) В дополнение к уже сказанному — есть еще конфиг-параметр view.name:
$config['view']['name'] = 'Your Site Name'; // название сайта
Он, как правило, выводится в шапке сайта, и он же обычно используется как часть тега <title>. Но это вовсе не обязательно и Вы можете на своем сайте настроить это, как угодно.

Давайте просто вместе доведем все до ума
Давайте. Только, желательно, делать свои предложения без эмоций, системно, и хоть как-то обосновывать.
0
Да просто по какой-то причине мой ип тут вчера залочился (404 выдает), хотя я мирно сидел читал статьи и скачал пару плагинов бесплатных. Никого не трогал… даже не зарегился тогда еще. Приходится теперь через анонимайзер заходить, что неудобно.
0
Еще один момент. На странице очень много дублей ссылок. Например, на главную. Ссылка и в логотипе, и в меню «Интересное», и в меню «Статьи», причем дублируется еще и в футере. Меж тем это мешает роботу обходить сайт. Да и по сео рекомендуется иметь на странице не больше 100 внутренних ссылок и желательно без повторов.
0
Например, на главную
И какие ссылки предлагаете убрать?
+1
Ну смотрите. В одной лишь шапке сразу 3(!) ссылки на главную. На логотипе оставляем, так как общепринято, что логотип == ссылке. Статьи и интересное я бы выкинул. В футере можно вообще все дублированные ссылки убрать. Объясню почему. Хидер в шаблоне фиксированный, как и боковые кнопки — он едет со скроллером вместе, поэтому перейти на любой раздел и так можно из любого положения на странице — через хидер и боковые кнопки.
0
Вопрос в том, что так устроена навигация. Т.е. нужно менять логику обоих меню. Думаю можно удалить у себя на проекте, если вам мешает — удалить всегда легче, чем добавить.
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.