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

11 Июль, 2015

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

Число страниц в Яндексе в Рдс баре

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

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


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

http://ktonanovenkogo.ru/seo/prodvizhenie-kommercheskix-sajtov/retargeting-vkontakte.html/122
http://ktonanovenkogo.ru/seo/prodvizhenie-kommercheskix-sajtov/retargeting-vkontakte.html/123
http://ktonanovenkogo.ru/seo/prodvizhenie-kommercheskix-sajtov/retargeting-vkontakte.html/124

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

Неправильный канонический Урл от All in One SEO Pack

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

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

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

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

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


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

Запретить пагинацию для канонических URL в All in One SEO

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

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

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

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

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

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

Использовать noindex для страниц/записей с пагинацией в All in One SEO

В результате этого на страницах пагинации (с цифирьками на конце) в исходном коде теперь добавляется запрет на их индексацию через мета-тег 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 для страниц с дурацкой погинаций, у меня выглядит вполне себе благопристойно (на мой взгляд):

Починили All in One SEO Pack

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

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

Число страниц в индексе Яндекса

Удачи вам! До скорых встреч на страницах блога KtoNaNovenkogo.ru

Еще:

Рубрики :Основы WordPress

Комментарии и отзывы

alexzsoft

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

Olga

спасибо за статью.

у меня в коде нашлось следующее: rel="alternate" — это не критично?

и вот это в поиске: sitemap-pt-post-2013-10.xml — штук 5 — как избавиться, не подскажете?

заранее, спасибо!

Иван

Хоть бы ссылку указывали где берете код, ведь это не ваше решение. Имею ввиду код для удаления мета-тега rel='prev'

Дмитрий

Иван: да, конечно. http://seo-mayak.com/sozdanie-bloga/wordpress-dlya-novichkov/atribut-rel-canonical-ssylki-na-kanonicheskie-stranicy.html

Но я не уверен, что это первоисточник, просто в поиске Гугла этот сайт по запросу «удалить ...» был в Топе.

alexzsoft: скрытый индекс не особо полезен, ибо используется в ранжировании лишь в случаях, когда в основном ничего достойного найдено не будет. ИМХО.

Olga: ну, если у Вас многоязычный сайта, то этот мета-тег нужен.

Olga

/ну, если у Вас многоязычный сайта, то этот мета-тег нужен./

Не многоязычный. просто в хедере удалить его код?

Андрей

Тема давно уже всплывшая и решённая у многих блоггеров. Странно, Дмитрий, что Вы только сейчас это заметили. Уж Вам то надо быть в авангарде 🙂 , на Вас многие равняются.

По поводу первоисточника кода: автор использует mayak в коде, как своего рода копирайт и ревностно относится к тем, кто берёт его решение и не ставит ссылку на первоисточник.

Хотя это решение (без mayak) уже давно в сети.

Дмитрий

Андрей: ну, я об это в самом начале сказал, что проблема не нова, но пословица про «гром и перекрестится» она к большинству из нас применима (ко мне так точно). Всегда найдутся более важные дела, чтобы отложить, а потом забыть.

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

Робинзон

Столкнулся с тем, что AIO сейчас прописывает rel="canonical" на главной странице со слэшем на конце. выходит так:

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

Наталья

А Гугл убрал лишние страницы из поиска? Наверное, нет?

Кэр Лаэда

function mayak_remove_link ( $data ) {

return false;

}

add_filter ( 'aioseop_prev_link', 'mayak_remove_link' );

add_filter ( 'aioseop_next_link', 'mayak_remove_link' );

Правильный код ( тот не до конца пашет)

Cass

Спасибо дружище, сам тоже долго формулировал вопрос!

Aleks

Спасибо, статья помогла. Хотел было уже через htaccess это все редиректить. Но так правильней, в этом htaccess костылей и так уже хватает...

Елена

Здравствуйте снова, Дмитрий.

Не совсем по теме статьи, но я не могу найти подходящей, чтобы задать вопрос о проблеме.

А вопрос вот какой: при любом редактировании настроек в консоли админки вордпресс после сохранения появляется белая страница с надписью (укажу ниже). Также, при написании статьи и сохранении уже написанного, появляется все тот же текст, меняются только номера строчек в конце сообщения.

Текст:

Deprecated: Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set 'always_populate_raw_post_data' to '-1' in php.ini and use the php://input stream instead. in Unknown on line 0 Warning: Cannot modify header information — headers already sent in Unknown on line 0 Warning: Cannot modify header information — headers already sent in /home/l/leonati5/pro7sfer.ru/public_html/wp-admin/post.php on line 197 Warning: Cannot modify header information — headers already sent in /home/l/leonati5/pro7sfer.ru/public_html/wp-includes/pluggable.php on line 1228

перевод:

Устаревшие: Автоматически заселение $ HTTP_RAW_POST_DATA устарела и будет удалена в будущих версиях. Чтобы избежать этого предупреждения набора 'always_populate_raw_post_data' на '-1' в php.ini и использовать PHP: // входной поток вместо. в Unknown в строке 0 Предупреждение: Не удается изменить информацию в заголовке — заголовки уже прислал в Unknown в строке 0 Предупреждение: Не удается изменить информацию в заголовке — заголовки уже прислал в /home/l/leonati5/pro7sfer.ru/public_html/wp-admin/post. PHP на линии 197 Предупреждение: не удается изменить информацию в заголовке — заголовки уже прислал в /home/l/leonati5/pro7sfer.ru/public_html/wp-includes/pluggable.php на линии 1228

Подскажите пожалуйста, как быть? что это и как с этим бороться!??

Спасибо!

Подписаться не комментируя