ссылки на страницу содержат как исправить
Проблема с All in One SEO Pack и ее решение — убираем rel=prev и исправляем rel=canonical, чтобы убрать из индекса дубли
Здравствуйте, уважаемые читатели блога KtoNaNovenkogo.ru. Случайно сегодня глянул на количество страницы этого блога, которые находятся в индексе, и был шокирован — их там аж 8000 тысяч. В Google чуть более 1500 тысяч, что тоже несколько больше обычного.
Перешел по ссылке из окна РДС бара (именно им и смотрел) на Яндекс со списком страниц моего сайта в его индексе. Полистал его смальца и слегка прифигел, ибо нашел там кучу дублей, которые вели на одни и те же посты (статьи, т.е. записи в терминологии WordPress), но Урлы у них были различные. Крайне неприятная ситуация, которую нужно было срочно решать.
Дубли страниц блога на WordPress в индексе поисковиков
Дубли в индексе Яндекса я нашел примерно такие:
Пару минут я пытался сформулировать запрос для поиска ответа на сложившуюся ситуацию. Ничего не придумал и полез посмотреть в исходном коде, а какой, собственно, там rel=»canonical» прописан. Если основной страницы (без слеша и цифирек на конце), то все ОК. Однако канонический Урл меня крайне разочаровал. На блоге https://ktonanovenkogo.ru я это дело уже поправил, поэтому приведу скрин с другого блога на WordPress, где наблюдается та же картина, что и была тут какое-то время назад:
Если внимательно приглядеться к скриншоту, то виновника этого безобразия вычислить не сложно — это тот самый плагин All in One SEO Pack, о котором я писал лет пять назад (надо бы тот пост обновить, да руки все не доходят) и который до сих пор меня не подводил. Однако, все в жизни когда-то бывает в первый раз.
Проблема эта не нова и ее уже не раз обсуждали. Но все это прошло мимо и вскользь, а вот теперь вернулось бумерангом и вдарило по темечку. Что приятно — эта ситуация сейчас практически полностью успешно разрешается через настройки данного плагина. Все просто и логично, но лучше это сделать до попадания кучи дублей в индекс, чем как я делать настройки уже после.
Правда, я там не нашел вариант удаления мета-тега с rel=’prev’, но эта проблема легко решилась с помощью добавления нескольких строк кода в замечательный файлик функшионс.пхп. Но обо всем по порядку.
Настройка тега rel=»canonical» в All in One SEO для устранения дублей
Настройки плагина сейчас вынесены в отдельный пункт «All in One SEO, который расположен в вверху левого меню админки WordPress. В самом верху окна настроек следует поставить галочку в поле «Запретить пагинацию для канонических URL».
Лично я свои посты никогда не разбиваю, да и любую другую пагинацию (главной страницы или рубрик) закрываю от индексации в файлике роботс.тхт. А тут получается вообще какая-то псевдо-пагинация постов, которой вроде как и нет, но WordPress на страницы с цифрами, написанными через слеш после Урла, не выдает 404 ошибки, а считает, что это пагинация. Бред какой-то, но факт остается фактом. Если вместо цифр написать через слеш буквы, то выдает 404 ошибка.
После сохранения изменения исходный код проблемных страниц с Урлами вида:
Стал уже выглядеть иначе, что меня порадовало, ибо в rel=»canonical» был указан действительно канонический Урл, а не страница псевдо-пагинации с цифрами на конце:
Однако, в индексе Яндексе уже имеется куча дублей, от которых надо избавиться. Поэтому я прокрутил страницу с настройками All in One SEO практически до самого низа и поставил галочку в поле «Использовать noindex для страниц/записей с пагинацией».
В результате этого на страницах пагинации (с цифирьками на конце) в исходном коде теперь добавляется запрет на их индексацию через мета-тег name=»robots» со значением «noindex,follow» (что означает инструкцию роботам поисковых систем — не индексировать, но по ссылкам переходить):
Удаляем мета-тег rel=’prev’ из исходного кода страницы блога на WordPress
Сделать это несложно. Достаточно будет открыть на редактирование (советую использовать связку Файлзила+Нотепад, а не встроенный редактор файлов в WordPress) файлик functions.php из папки с используемой вами темой оформления ( wp-content/themes/название ) и добавить в него после следующие строчки кода:
Если что-то пошло не так (блог не открывается), то откатите изменения в Нотепаде++ и посмотрите внимательно, куда именно вы пихаете приведенный код. Если чуток подумаете, то все обязательно получится.
Собственно, все. Теперь проблемный участок исходного кода, формируемый плагином All in One SEO Pack для страниц с дурацкой погинаций, у меня выглядит вполне себе благопристойно (на мой взгляд):
Что и требовалось реализовать. Ура.
P.S. Примерно через три недели опосля написания этого поста после очередного апа Яндекса в его индексе осталось уже только около 1000 страниц, что примерно соответствует их реальному количеству на этом блоге.
Удачи вам! До скорых встреч на страницах блога KtoNaNovenkogo.ru
Комментарии и отзывы (16)
Запрещать индексацию по-моему нельзя, т.к. эти страницы уйдут в скрытые страницы поисковых систем, а не удаляться.
у меня в коде нашлось следующее: rel=»alternate» — это не критично?
и вот это в поиске: sitemap-pt-post-2013-10.xml — штук 5 — как избавиться, не подскажете?
Хоть бы ссылку указывали где берете код, ведь это не ваше решение. Имею ввиду код для удаления мета-тега rel=’prev’
alexzsoft: скрытый индекс не особо полезен, ибо используется в ранжировании лишь в случаях, когда в основном ничего достойного найдено не будет. ИМХО.
Olga: ну, если у Вас многоязычный сайта, то этот мета-тег нужен.
/ну, если у Вас многоязычный сайта, то этот мета-тег нужен./
Не многоязычный. просто в хедере удалить его код?
По поводу первоисточника кода: автор использует mayak в коде, как своего рода копирайт и ревностно относится к тем, кто берёт его решение и не ставит ссылку на первоисточник.
Хотя это решение (без mayak) уже давно в сети.
Андрей: ну, я об это в самом начале сказал, что проблема не нова, но пословица про «гром и перекрестится» она к большинству из нас применима (ко мне так точно). Всегда найдутся более важные дела, чтобы отложить, а потом забыть.
Да, конечно же, решение не новое. Пару лет назад (или даже больше) я уже чистил код от мета-ссылок на предыдущие и последующие посты, но в какой-то момент, видимо, откатился на ранее сделанный бекап, где этого еще не было прописано. В общем, в этом посте была описана работа над ошибками, причем повторная.
Столкнулся с тем, что AIO сейчас прописывает rel=»canonical» на главной странице со слэшем на конце. выходит так:
Прежние версии плагина прописывалина главной каноникал без слэша. (на ктонановенького, кстати, тоже теперь каноникал со слешэм). Как вернуться к прежнему варианту и убрать слэш из этой конструкции, не подскажете?
А Гугл убрал лишние страницы из поиска? Наверное, нет?
Правильный код ( тот не до конца пашет)
Спасибо дружище, сам тоже долго формулировал вопрос!
Спасибо, статья помогла. Хотел было уже через htaccess это все редиректить. Но так правильней, в этом htaccess костылей и так уже хватает.
Здравствуйте снова, Дмитрий.
Не совсем по теме статьи, но я не могу найти подходящей, чтобы задать вопрос о проблеме.
А вопрос вот какой: при любом редактировании настроек в консоли админки вордпресс после сохранения появляется белая страница с надписью (укажу ниже). Также, при написании статьи и сохранении уже написанного, появляется все тот же текст, меняются только номера строчек в конце сообщения.
Подскажите пожалуйста, как быть? что это и как с этим бороться.
Благодарен за столь понятный и легкоусвояемый пост. Тяжело было сформулировать запрос в поисковике для решения сложившейся проблемы. Вы оказались на первом месте ))
Спасибо!! Только один вопрос, настроил канонический тег на страницу со слэшем и соответственно 301 редирект настроил с без слэша, на слэш!! Я правильно все сделал?