июня 02 2015

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

aVadim 2 июня 2015, 02:29 в избранное в избранном 45 комментариев

Alto CMS inside - как это устроено и работает

Есть у меня подозрение, что многие админы сайтов, создаваемых на базе 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:

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

Теги:

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

Кстати, было бы неплохо еще настроить для Альто корректную отдачу заголовков Last-Modified, сейчас они вообще не отдаются, проверить можно тут

А это уже, наверное, задача сервера, не?

На сервере конечно можно пошаманить и добиться отдачи заголовков, но они будут некорректны для динамических страниц, под каждую 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;

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

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

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

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

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

По большому счету 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.

Касательно 3 пункта, ведь ссылки на сайте везде указываются со слешом в конце. Откуда поисковик узнает о неправильных?

Это не имеет особого значения, на вас могут поставить ссылку site.ru/people с другого сайта (любые другие варианты) и если не будет переадресации на site.ru/people/, она проиндексируется как отдельная страница.

Не замечал подобных проблем. В индексе нет таких страниц без слеша у меня.

это не значит, что со временем они не появятся, особенно если на сайт активно ссылаются.

Если есть желание можете провести эксперимент. Дать несколько ссылок на страницу без слеша и проверить через время в проиндексированных.

Отредактирован: 3 июня 2015, 12:43

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

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

не думаю что поисковики такие тупые

Они и не тупые. Это роботы и они следуют правилам.

Как это повлияет на выдачу — однозначного ответа нет и выяснить это можно только опытным путем.

хоть как-то повлияет на какие-то позиции

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

Они и не тупые. Это роботы и они следуют правилам.

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

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

о_О

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

И интересно — кто-нибудь изучал, как подобные проблемы решаются в других CMS?

Отредактирован: 3 июня 2015, 12:49

Попробовал в вордпрессе, срабатывает 301 редирект на уровне кода php. А вот где именно пока не смог найти.

И интересно — кто-нибудь изучал, как подобные проблемы решаются в других 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");
				}
			}
//решение проблемы с категориями, редирект на верный урл, добавление слеша в конец

Вот такое правило в .htaccess решает эту проблему:

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

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

Почему-то мне кажется, что это более верный подход

Отредактирован: 3 июня 2015, 13:20

а при отсутствии апача? Многие живут php-fpm + nginx

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

Надо думать…

… и переадресация с index.php и index.html на site.ru/

А вот это, по-моему, совсем не обязательно, т.к. на странице site.ru/index.php в HTML-коде будет:

<link rel="canonical" href="http://site.ru/"/>

Вот так и не поняла, их нужно вместе использовать или можно обойтись одним, например «canonical». Сам гугл рекомендует 301 редирект для таких случаев, как один из самых надежных support.google.com/webmasters/answer/139066?hl=ru#4

Это про другое.

Вы сейчас о чем?

Суть такая: допустим, есть адреса «site.ru/a.html» и «site.ru/b.html», которые отображают один и тот же контент, но мы считаем, что «a.html» — это каноническая страница. Если мы ставим редирект с «a.html» на «b.html», то страницу «b.html» робот даже и не загружает, а сразу идет, куда нужно.

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

Поэтому редирект, конечно, более предпочтителен (т.к. исключает всякие случайности), но с точки зрения логики (как должна работать индексация) использование rel=canonical вполне достаточно.

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

Вообще насколько я понимаю сам тег canonical говорит о содержимом страницы, но не передает ее вес.

Уже представил пользователя который к site.ru дописывает «index.php» (помимо того что удаляет слеши перед тем как ссылки выкладывать)

Вы мне напоминаете одного человека, который недавно здесь насоздавал кучу тем в т.ч. про SEO, а потом их удалил. Аргументы у вас примерно те же.

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

Но дело даже не в этом, существует свод правил и рекомендаций, которых как мне кажется желательно придерживаться.

Переход на личности засчитан, Алена.

Ничего личного, просто мнение по поводу ваших последних комментов.

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

Отредактирован: 5 июня 2015, 15:07

Почему в статье заголовок идет под тегом h2, а не h1?

А по факту, изменить под себя, думаю не потребует много времени. По умолчанию же, как мне кажется лучше придерживаться рекомендаций гугла.

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

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

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

H1 пусть и недавно, но появился.

У страниц page1 стоит

<link rel="canonical" href="http://demo.altocms.ru/new/index/newall/"/>

Я вчера качал последнюю бету и никакого h1 там не увидел. Ставил шаблон experience simple.
По поводу пагинации — принял. Тогда с этим все ок.

h1 в соответствии с рекомендациями гугла проставлен на заголовке сайта. А новости имеют теперь h2 вместо прежнего h3

А вот на этот сайт 80% заходов из поисковиков — это Гугл

У меня с яндекса 65%, остальное делят гугл и мейл. Суммарно где-то 4к уников в сутки. Это не очень много, в принципе. Вот щас новый блог стал делать — на вашей цмс.

А вот если по какой бы то ни было причине в индексе окажутся site.ru и site.ru/index.php их вес разделится и это может принести серьезные неприятности для сайта.

Как и между site.ru и site.ru/page1. Вообще сеошники рекомендуют страницы пагинации закрывать все кроме первой. Лучше всего через мету роботс и noindex,follow.

Трудно, конечно, въехать сразу, где тайтл — это тайтл, а где тайтл — это просто тайтл. Но повторю то, что уже есть в статье:

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

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

3) В дополнение к уже сказанному — есть еще конфиг-параметр view.name:

$config['view']['name'] = 'Your Site Name'; // название сайта

Он, как правило, выводится в шапке сайта, и он же обычно используется как часть тега <title>. Но это вовсе не обязательно и Вы можете на своем сайте настроить это, как угодно.

Давайте просто вместе доведем все до ума

Давайте. Только, желательно, делать свои предложения без эмоций, системно, и хоть как-то обосновывать.

Да просто по какой-то причине мой ип тут вчера залочился (404 выдает), хотя я мирно сидел читал статьи и скачал пару плагинов бесплатных. Никого не трогал… даже не зарегился тогда еще. Приходится теперь через анонимайзер заходить, что неудобно.

Еще один момент. На странице очень много дублей ссылок. Например, на главную. Ссылка и в логотипе, и в меню «Интересное», и в меню «Статьи», причем дублируется еще и в футере. Меж тем это мешает роботу обходить сайт. Да и по сео рекомендуется иметь на странице не больше 100 внутренних ссылок и желательно без повторов.

Например, на главную

И какие ссылки предлагаете убрать?

Ну смотрите. В одной лишь шапке сразу 3(!) ссылки на главную. На логотипе оставляем, так как общепринято, что логотип == ссылке. Статьи и интересное я бы выкинул. В футере можно вообще все дублированные ссылки убрать. Объясню почему. Хидер в шаблоне фиксированный, как и боковые кнопки — он едет со скроллером вместе, поэтому перейти на любой раздел и так можно из любого положения на странице — через хидер и боковые кнопки.

Вопрос в том, что так устроена навигация. Т.е. нужно менять логику обоих меню. Думаю можно удалить у себя на проекте, если вам мешает — удалить всегда легче, чем добавить.

Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.

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

Файл robots.txt

Тег <title>

Мета-тег <description>

Структура URL статей и ЧПУ

Редирект на новые адреса

Плагин sitemap

Плагин Seopack — Управление SEO-параметрами страниц

Плагин Похожие статьи

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

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

Бесплатные модули

Плагин "Рефералы"

Счетчик просмотра топиков

Checkbox

Интеграция с phpBBex

Magic Rules

Песочница

Множественная загрузка файлов / Multiple File Upload

Content Fields eXtended