All in One SEO Pack и внутренняя поисковая оптимизация блога на WordPress (метатеги Canonical, Description и Title)

Мета-тэг Canonical и его настройка в All in One SEO Pack

Галочка в поле «Канонические URL» в окне настроек All in One SEO Pack позволяет избежать дублирования контента в WordPress (содержимого материалов вашего проекта) в индексе некоторых поисковиков.

Давайте сначала рассмотрим, откуда может появиться дублирование контента в Вордпрессе. А появиться оно может в том случае, если один и тот же материал будет доступен по разным адресам (URL). Например, если вы используете тег MORE для разделения текста материала на вступительную часть, публикуемую на главной, и полную версию, открываемую либо по нажатию на заголовок материала, либо по нажатию на ссылку, формируемую с помощью тега MORE (например, Читать далее...).

Так вот, при щелчке в WP блоге по заголовку материала, полная его версия откроется по одному адресу, а при щелчке по ссылке «Читать далее» — по другому (отличаться они будут только надписью типа #more-2788 в конце URL адреса). Во втором случае документ откроется на том месте, где он закончился на главной странице блога (где стоял тег more).

В принципе, можно применить хак и убрать в настройках движка WordPress добавление #more-2788 к Урлу, но тогда вебстраница будет открываться сначала, что мне кажется не очень удобным для читателя (придется искать то место, где он закончил чтение на главной).

Но есть альтернативный вариант решения проблемы дублирования контента в WordPress, при котором и волки будут сыты, и овцы останутся целы. Выход из создавшейся ситуации придумала компания Google, анонсировав в начале этого года новый метатег Canonical, о поддержке которого сразу же заявили Яху и Microsoft.

Таким образом, если ваш ресурс имеет идентичный или очень похожий контент, доступный по разным URL, то новый тег Canonical позволит указать тот URL , который должен возвращаться к поисковой системе. При этом все характеристики, такие как ссылочный вес и тому подобное, передадутся на нужную (каноническую) версию адреса.

С точки зрения Html синтаксиса, мета-тег Canonical добавляется между открывающим и закрывающим тегами HEAD в HTML коде вебстраниц с дублированным контентом. В результате Google, Yahoo, Bing, а с недавних пор и Яндекс, поймут, что все дубликаты ссылаются на канонический URL, указанный в Canonical. Дополнительные свойства вебстраницы, такие как PageRank, также перенесутся с дублирующих вебстраниц на указанную.

В качестве примера приведу вид этого Canonical для странички с материалом моего WP блога, на которую я перешел по ссылке «Читать далее». В адресной строке я при этом вижу адрес:

https://ktonanovenkogo.ru/vokrug-da-okolo/hosting/fajl-hosts-gde-on-naxoditsya-v-windows-chto-delat-kak-udalit-virus.html#more-6188

Но в исходном коде, сформированном движком WordPress, (в верхней его части) можно найти строчку:

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

Благодаря плагину All in One SEO Pack в WordPress, проблема дублирования контента в индексе Yandex, Google, Яхоо и поисковика Bing решается простой установкой галочки «Канонические URL'ы», которая, кстати, по умолчанию уже включена. Но теперь вы знаете, что такое тег Canonical и зачем нужен.

Возможные проблемы с Canonical при использовании All in One SEO

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

Прошлым летом я совершенно случайно глянул на количество страниц этого блога, которые находятся в индексе, и был шокирован — их там аж 8000 тысяч. В Google чуть более 1500 тысяч, что тоже несколько больше обычного.

Перешел по ссылке из окна РДС бара (именно им и смотрел) на Яндекс со списком страниц моего сайта в его индексе. Полистал его смальца и слегка «удивился» (ранее стоящее тут слово было удалено цензурой), ибо нашел там кучу дублей, которые вели на одни и те же посты (статьи, т.е. записи в терминологии WordPress), но Урлы у них были различные (а содержание одинаковое). Крайне неприятная ситуация, которую нужно было срочно решать, пока карающий меч не...

Дубли в индексе Яндекса я нашел примерно такие:

/seo/prodvizhenie-kommercheskix-sajtov/retargeting-vkontakte.html/122

/seo/prodvizhenie-kommercheskix-sajtov/retargeting-vkontakte.html/123
/seo/prodvizhenie-kommercheskix-sajtov/retargeting-vkontakte.html/124

Пару минут я пытался сформулировать запрос для поиска ответа в Яндексе на сложившуюся ситуацию. Ничего не придумал и полез посмотреть в исходном коде, а какой, собственно, там rel="canonical" прописан. Если основной страницы (без слеша и цифирек на конце), то все ОК.

Однако канонический Урл меня крайне разочаровал. На блоге https://ktonanovenkogo.ru я это дело уже поправил, поэтому приведу скрин с другого блога на WordPress, где наблюдается та же картина, что и была тут какое-то время назад:

Абзац, причем полный. Поисковик в этом случае был совершенно прав, что загнал эти дубли в индекс, ибо rel="canonical" не указывает на основную страницу.

Да и к тому же чуть выше в коде стоит rel="prev", который содержит ссылку на страницу с номером на единицу меньше той, для которой мы просматриваем исходный код. Поисковик по этой служебной link ссылке перейдет (ведь именно для него она тут и проставлена), в результате чего в индекс попадет еще один дубль и так до бесконечности.

Если внимательно приглядеться к скриншоту, то виновника этого безобразия вычислить не сложно — это тот самый плагин All in One SEO Pack, который до сих пор меня не подводил. Однако, все в жизни когда-то бывает в первый раз. Что приятно — эта ситуация сейчас практически полностью успешно разрешается через настройки данного плагина. Все просто и логично, но лучше это сделать до попадания кучи дублей в индекс, чем как я делать настройки уже после.

Настройки плагина сейчас вынесены в отдельный пункт «All in One SEO, который расположен в вверху левого меню админки WordPress. В самом верху окна настроек следует поставить галочку в поле «Запретить пагинацию для канонических URL».

Это уберет злосчастные слеш и цифирьки после Урла основной страницы в теге rel=»canonical", который будет прописываться для таких страничек. Забыл сказать, что эти цифирьки (на вроде .html/124) есть ни что иное как пагинация, т.е. разбиение поста на страницы (про пагинацию можете почитать в статье про плагин WP-PageNavi).

Хотя у запичей (постов) на моем блоге никакой пагинации в помине нет и не было, но WordPress (а точнее наш любимый Ол ин Ван Сео) их виртуализировал. После установки указанной галочки, сохранения изменений и сброса кеша исходный код проблемных страниц с Урлами стал уже выглядеть иначе, что меня порадовало, ибо в rel="canonical" был указан действительно канонический Урл, а не страница псевдо-пагинации с цифрами на конце. Уф, одной проблемой меньше.

Однако, в индексе Яндексе уже имеется куча дублей, от которых надо избавиться. Поэтому я прокрутил страницу с настройками All in One SEO практически до самого низа и поставил галочку в поле «Использовать noindex для страниц/записей с пагинацией».

Удаляем rel='prev' из исходного кода блога на WordPress

В итоге, код формируемый этим плагинов в «шапке» стал примерно таким:

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

Для этого нужно будет открыть на редактирование (советую использовать связку Файлзила+Нотепад, а не встроенный редактор файлов в WordPress) файлик functions.php из папки с используемой вами темой оформления (wp-content/themes/название) и добавить в него после ‹?php следующие строчки кода:

function mayak_remove_prev_link( $data ) {
return false;
}
add_filter( 'aioseop_prev_link', 'mayak_remove_prev_link' );
add_filter( 'aioseop_next_link', 'mayak_remove_prev_link' );

Собственно, все. Теперь проблемный участок исходного кода, формируемый плагином All in One SEO Pack для страниц с дурацкой погинаций, у меня выглядит вполне себе благопристойно (на мой взгляд):

Примерно через три недели после проведенных махинаций манипуляций в индексе Яндекса осталось уже только около 1000 страниц, что примерно соответствует их реальному количеству на этом блоге. Что и требовалось доказать.

Настройка Title для всех типов страниц в WordPress

Продолжим разбираться с настройками плагина — All in One SEO Pack. Если вы установите галочку «Перезаписывать заголовки», то сможете настраивать для различных типов вебстраниц в WordPress вид их Тайтлов в соответствии с правилами, описанными в приведенных ниже полях.

Вся прелесть данного плагина в том, что вам практически ничего не надо менять в его настройках по умолчанию, чтобы получить максимальный эффект. Я ничего пока и не менял в приведенных на рисунке полях, но вы можете вносить изменения по своему разумению и видению лучшего варианта (пользуясь случаем, хочу спросить у вас: есть мнение, что Яндекс не учитывает слова в тайтле после символа «|» — так ли это на самом деле?)

Немного поясню надпись:

%post_title% | %blog_title%

Сие означает, что Тайтл будет формироваться из заголовка данной публикации, плюс (вертикальная черта, если быть точным) название блога. Точно так же обстоит дело и с категориями (%category_title% | %blog_title%), статическими страницами (%page_title% | %blog_title%), архивами и другими типами записей, формируемыми нашим любимым движком.

Запрет индексации архивов или категорий в All in One SEO Pack

Область «Настройки индексирования (noindex)» в настройках All in One SEO Pack — позволяют бороться с дублированием контента в индексе поисковых машин. Дело в том, что в рубриках, тегах и архивах, которые создает Вордпресс, могут повторяться анонсы одних и тех же публикаций.

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

<meta name="robots" content="noindex,follow" />

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

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

Почему именно я запретил индексацию страниц с пагинацией — объяснил чуть выше, а страницы с результатами внутреннего поиска по сайту (средствами WordPress) тоже желательно запретить, ибо поисковики сильно не любят, когда их индексную базу забиваю тонны «результатов поиска».

Генерация описания страниц и подтверждение авторства

Галочки в начале области «Расширенные настройки» активируют автоматическую генерацию мета-тэга Description, если вы не задали их вручную при написании статьи в админке.

Содержимое берется из поля «Цитата», если оно было заполнено, или из начальной части текста. Я бы не советовал включать эту опцию в настройках. Лучше создавать каждый раз вручную отдельное описание (Description) для материала при его написании.

C недавних пор в функционал этого плагина добавили еще и возможность подтверждения авторства ваших материалов в выдаче Гугла с помощью своего аккаунта в социальной сети Google+.

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

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

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

В новых версиях плагина появилась возможность активировать дополнительные модули, например, «Производительность», но для меня главное не создавать слишком большой нагрузки на сервер и этот модуль я отключил:

Прописываем Title и Description для каждой страницы блога

Кроме, собственно, настроек. Теперь, благодаря All in One SEO Pack, при написании или редактировании статьи у вас будет возможность, при желании (а оно у вас обязательно должно возникать), указать для нее уникальное (обязательно, и это очень важно) содержимое мета-тегов «Title», «Description».

Это можно будет сделать в админке WordPress в окне редактирования любой страницы или записи. Область для ввода мета-тегов называется «All in One SEO Pack», которое вы можете найти в окне редактирования материала (при желании вы можете его перетащить за верхнюю полосу в любое удобное для вас место в окне редактирования).

Я обычно заполняю только поле мета-тега «Description», т.к тот тайтл, который формируется из заголовка публикации, меня вполне устраивает.

Если вдруг под окном редактирования статьи вы этого блока не нашли, то прокрутите страницу вверх и кликните по расположенной справа вкладке «Настройка экрана», а в выпавшей панели поставьте галочку в поле «All in One SEO»:

Проблема с All in One SEO Pack и ее решение — убираем rel=prev и исправляем rel=canonical, чтобы убрать из индекса дубли

Случайно сегодня глянул на количество страницы этого блога, которые находятся в индексе, и был шокирован — их там аж 8000 тысяч. В Google чуть более 1500 тысяч, что тоже несколько больше обычного.

Перешел по ссылке из окна РДС бара (именно им и смотрел) на Яндекс со списком страниц моего сайта в его индексе. Полистал его смальца и слегка прифигел, ибо нашел там кучу дублей, которые вели на одни и те же посты (статьи, т.е. записи в терминологии WordPress), но Урлы у них были различные. Крайне неприятная ситуация, которую нужно было срочно решать.

Дубли страниц блога на WordPress в индексе поисковиков

Дубли в индексе Яндекса я нашел примерно такие:

/seo/prodvizhenie-kommercheskix-sajtov/retargeting-vkontakte.html/122

/seo/prodvizhenie-kommercheskix-sajtov/retargeting-vkontakte.html/123
/seo/prodvizhenie-kommercheskix-sajtov/retargeting-vkontakte.html/124

Пару минут я пытался сформулировать запрос для поиска ответа на сложившуюся ситуацию. Ничего не придумал и полез посмотреть в исходном коде, а какой, собственно, там rel="canonical" прописан. Если основной страницы (без слеша и цифирек на конце), то все ОК. Однако канонический Урл меня крайне разочаровал. На блоге https://ktonanovenkogo.ru я это дело уже поправил, поэтому приведу скрин с другого блога на WordPress, где наблюдается та же картина, что и была тут какое-то время назад:

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

Если внимательно приглядеться к скриншоту, то виновника этого безобразия вычислить не сложно — это тот самый плагин All in One SEO Pack, о котором я писал лет пять назад (надо бы тот пост обновить, да руки все не доходят) и который до сих пор меня не подводил. Однако, все в жизни когда-то бывает в первый раз.

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

Правда, я там не нашел вариант удаления мета-тега с rel='prev', но эта проблема легко решилась с помощью добавления нескольких строк кода в замечательный файлик функшионс.пхп. Но обо всем по порядку.

Настройка тега rel="canonical" в All in One SEO для устранения дублей

Настройки плагина сейчас вынесены в отдельный пункт "All in One SEO, который расположен в вверху левого меню админки WordPress. В самом верху окна настроек следует поставить галочку в поле «Запретить пагинацию для канонических URL».

Это уберет злосчастные слеш и цифирьки после Урла основной страницы в теге rel="canonical", который будет прописываться для таких страничек. Забыл сказать, что эти цифирьки (на вроде .html/124) есть ни что иное как пагинация, т.е. разбиение поста на страницы.

Лично я свои посты никогда не разбиваю, да и любую другую пагинацию (главной страницы или рубрик) закрываю от индексации в файлике роботс.тхт. А тут получается вообще какая-то псевдо-пагинация постов, которой вроде как и нет, но WordPress на страницы с цифрами, написанными через слеш после Урла, не выдает 404 ошибки, а считает, что это пагинация. Бред какой-то, но факт остается фактом. Если вместо цифр написать через слеш буквы, то выдает 404 ошибка.

После сохранения изменения исходный код проблемных страниц с Урлами вида:

https://ktonanovenkogo.ru/seo/prodvizhenie-kommercheskix-sajtov/retargeting-vkontakte.html/344

Стал уже выглядеть иначе, что меня порадовало, ибо в rel="canonical" был указан действительно канонический Урл, а не страница псевдо-пагинации с цифрами на конце:

Однако, в индексе Яндексе уже имеется куча дублей, от которых надо избавиться. Поэтому я прокрутил страницу с настройками All in One SEO практически до самого низа и поставил галочку в поле «Использовать noindex для страниц/записей с пагинацией».

В результате этого на страницах пагинации (с цифирьками на конце) в исходном коде теперь добавляется запрет на их индексацию через мета-тег name="robots" со значением "noindex,follow" (что означает инструкцию роботам поисковых систем — не индексировать, но по ссылкам переходить):

<meta name="robots" content="noindex,follow" />

Удаляем мета-тег rel='prev' из исходного кода страницы блога на WordPress

Как видно из второго отсюда скрнишота (выше по тексту), то там обведен в рамочку не только правильный тег rel="canonical", но и совершенно бестолковый и даже вредный в данном случае тег rel='prev', в котором указана ссылка на предыдущую страницу пагинации. Но, как я уже упоминал, никакой пагинации в статьях у меня нет и этот тег вводит в заблуждение поисковики, а значит его надо убрать.

Сделать это несложно. Достаточно будет открыть на редактирование (советую использовать связку Файлзила+Нотепад, а не встроенный редактор файлов в WordPress) файлик functions.php из папки с используемой вами темой оформления (wp-content/themes/название) и добавить в него после <?php следующие строчки кода:

function mayak_remove_prev_link( $data ) {
return false;
}
add_filter( 'aioseop_prev_link', 'mayak_remove_prev_link' );
add_filter( 'aioseop_next_link', 'mayak_remove_prev_link' );

Если что-то пошло не так (блог не открывается), то откатите изменения в Нотепаде++ и посмотрите внимательно, куда именно вы пихаете приведенный код. Если чуток подумаете, то все обязательно получится.

Собственно, все. Теперь проблемный участок исходного кода, формируемый плагином All in One SEO Pack для страниц с дурацкой погинаций, у меня выглядит вполне себе благопристойно (на мой взгляд):

Что и требовалось реализовать. Ура...

P.S. Примерно через три недели опосля написания этого поста после очередного апа Яндекса в его индексе осталось уже только около 1000 страниц, что примерно соответствует их реальному количеству на этом блоге.