Неканоническая страница сайта как исправить


Атрибут rel=canonical

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

Атрибут rel=canonical был введен Google 12 февраля 2009 года. Он учитывается до сих пор, поисковой системой Яндекс в том числе. Атрибут rel=canonical указывает поисковым роботам какая страница является предпочтительной при индексации, если на сайте имеется несколько  страниц с одинаковым содержимым, но с разными URL-адресами.

Допустим существует 2 страницы:

http://nazyrov.ru/chto-takoe-alexa-rank.html
http://nazyrov.ru/chto-takoe-alexa-rank.html?id=4535

В данном случае первая страница является основной, именно для нее и должен быть прописан атрибут rel=canonical. А вторая страница является лишь ее копией, но с другим URL-адресом. Следовательно, если не будет прописан rel=canonical, то поисковая система будет индексировать как основной адрес, так и дубль страницы.

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

Возьмем интернет магазин с 10 000 товарами. У каждого товара на сайте своя страница и несколько дублей. Представляете как подпортит продвижение сайта могут 20 000 дублированных страниц?

Откуда берутся неканонические страницы на сайте

Неканонические страницы или дубли генерируют движки управления, такие как WordPress, phpBB и прочие. Если у вас сайт написан на чистом HTML, то дублированных страниц в принципе быть не должно, если только вы их специально не добавляли конечно.

Если мы обратимся к справочнику вебмастера в Google и Яндекс, то увидим следующее:

Сообщение Google


Рекомендации Яндекс

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

Как прописать атрибут rel=canonical

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

Если взять CMS WordPress, то практически все SEO плагины предоставляют возможность прописать канонический URL автоматически. Я пользуюсь плагином All In One Seo Pack, поэтому покажу на его примере.

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

Если взглянем на исходный код страницы, то увидим что rel=canonical прописан. И если поисковый робот зайдет на этот дубль страницы, то увидит, что страница не является основной.

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

Руководство для начинающих по поиску и устранению канонических проблем SEO

Сообщение обновлено:

Канонические проблемы, вызванные дублированием контента, являются действительно распространенной проблемой SEO для веб-сайтов. Наличие идентичного или очень похожего контента на нескольких URL-адресах может привести к проблемам с индексированием. Хуже того, это может снизить количество ссылок, что может повредить вашему поисковому рейтингу.

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

Содержание:

Каковы канонические проблемы в SEO?

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

Например, веб-сайт может загружать свою домашнюю страницу для всех следующих URL-адресов:

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

Почему возникают проблемы с каноническими проблемами?

Есть несколько причин, по которым канонические проблемы являются проблемой для SEO.

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

Вот отличное видео от Джона Мюллера из Google, объясняющее, как поисковая система выбирает канонический URL-адрес, когда несколько URL-адресов на сайте отображают одинаковый или похожий контент:

   

Во-вторых, если ваш контент доступен через несколько URL-адресов , другие сайты могут ссылаться на другие URL-адреса при цитировании содержимого вашего сайта. Это диверсифицирует ваш ссылочный капитал на нескольких страницах, разбавляя его.

Третья проблема вызвана сочетанием двух вышеуказанных проблем.Допустим, у вас есть 100 ссылок, указывающих на URL 1, и 10 ссылок, указывающих на URL 2. Затем Google выбирает URL 2 в качестве канонической версии вашей страницы. Он может учитывать только ссылки, указывающие на URL 2, а не ссылки, указывающие на URL 1, при ранжировании страницы, что может ухудшить ваш рейтинг.

Каковы некоторые распространенные причины канонических проблем?

Существует множество сценариев, которые вызывают канонические проблемы, но вот несколько из наиболее распространенных, согласно Google:

  • HTTPS vs.HTTP : если ваш сайт защищен сертификатом SSL, возможно, он загружается при вводе как HTTPS-, так и HTTP-версии вашего URL. Эта проблема создает дубликаты каждой страницы вашего веб-сайта.
  • WWW по сравнению с не-WWW : если вы не указали версию своего URL по умолчанию, возможно, ваш сайт загружается при предварительном вводе URL-адреса в WWW и без предварительного задания WWW. Опять же, эта проблема создает дубликаты каждой страницы вашего веб-сайта.
  • URL-адреса, которые меняются в зависимости от взаимодействия с пользователем. : Некоторые сайты, в частности сайты электронной торговли, генерируют разные URL-адреса на основе параметров поиска или фильтров. Например:
  • URL-адреса, которые меняются в зависимости от устройства, используемого для просмотра страницы. : Если у вас есть другой веб-сайт для пользователей компьютеров и мобильных устройств (m. [Site] .com против [site] .com) или если вы используете AMP (amp. [site] .com против [site] .com), это может создать канонические проблемы.
  • Синдицированный контент : если вы публикуете свой контент на нескольких веб-сайтах или разрешаете его синдицирование - например, вы публикуете каждое новое сообщение в блоге на своем веб-сайте и на Medium - это может создать канонические проблемы.

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

Как определить, есть ли на вашем сайте канонические проблемы

Канонические проблемы, вызванные HTTP / HTTPS или WWW / не-WWW, - это самые простые проблемы для определения. Чтобы определить, являются ли эти проблемы на вашем сайте, введите каждую возможную версию URL вашего сайта в адресной строке браузера. Например:

Если все эти URL-адреса перенаправляют на один из этих URL-адресов (например, каждый из этих URL-адресов AuthorityLabs перенаправляет на https: // www.authoritylabs.com), значит, на вашем сайте нет этих канонических проблем. Но если какой-либо из этих URL-адресов не может перенаправить на ваш предпочтительный URL-адрес, у вас есть каноническая проблема.

Выявление других проблем может оказаться более трудным и трудоемким. Например, один из вариантов, который вы можете попробовать, - это зайти в Google, ввести site: [yoursite.com] и просмотреть все страницы в индексе Google, чтобы увидеть, есть ли там что-нибудь, что вас удивит.

Но перелистывание десятков или сотен результатов Google может быть не идеальным, поэтому другой вариант - использовать такой инструмент, как Screaming Frog, для сканирования всего вашего сайта и создания списка всех его URL.

Или, чтобы избавиться от необходимости просматривать каждый URL-адрес вашего сайта в отдельности для поиска проблем, вы можете использовать функции аудита сайта в популярных инструментах SEO, таких как Ahrefs, Moz или SEMrush. Все эти инструменты имеют функции, которые ищут дублирующийся контент и канонические проблемы на вашем сайте и создают простой для понимания отчет, который вы можете использовать для устранения этих проблем.

Как исправить типичные канонические проблемы

Существует два основных способа исправить канонические проблемы на веб-сайте: путем внедрения 301 редиректа и / или путем добавления канонических тегов на страницы вашего сайта, чтобы сообщить Google, какая из нескольких похожих страниц предпочтительнее. .Правильный вариант зависит от канонической проблемы, которую вы пытаетесь решить.

Внедрение переадресации 301 на всем сайте для повторяющихся страниц

Решает проблемы с HTTP / HTTPS и WWW / не-WWW

Канонические проблемы HTTP / HTTPS и WWW / не-WWW могут быть исправлены путем реализации переадресации 301 на всем сайте на правильный версия вашего URL.

Есть несколько способов настроить переадресацию по всему сайту. Самый простой и наименее рискованный способ - настроить перенаправление через хост вашего сайта.

Вы можете начать с поиска в Google по запросу «HTTP to HTTPS redirect [host name]» или «WWW to non-WWW redirect [host name]» и посмотреть, есть ли у вашего хоста страница поддержки, объясняющая, как внести изменения. И наоборот, вы можете обратиться за помощью в службу поддержки вашего хоста.

Если у вас есть разработчики, которые могут помочь, они также могут настроить ваши перенаправления, используя перенаправления .htaccess (Apache), перенаправления NGINX или другие методы.

После внесения изменений вы можете заметить некоторые изменения трафика и рейтинга.Согласно Google, это нормально, и через короткий промежуток времени ваш трафик и рейтинг восстановятся.

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

Также стоит отметить, что могут потребоваться некоторые другие изменения помимо перенаправления URL-адресов, например обновление файла robots.txt, карт сайта и любых жестко заданных URL-адресов, поэтому вы можете захотеть использовать HTTP в руководство по миграции сайта HTTPS, чтобы не пропустить ни одного важного шага.

Добавление канонических тегов ко всем страницам вашего сайта

Устраняет проблемы с URL-адресами, которые меняются в зависимости от взаимодействия с пользователем (например, сайтов электронной торговли)

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

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

Например, на сайтах WordPress вы можете использовать премиум-версию плагина Yoast SEO для автоматического добавления самореференциальных канонических тегов на каждую страницу вашего сайта. Пользователи HubSpot CMS могут изменить свои настройки, чтобы CMS автоматически добавляла самодостаточные URL. Shopify автоматически добавляет канонические теги на ваши страницы, поэтому вам не нужно об этом беспокоиться.

Если вы используете другую CMS, отличную от одной из перечисленных выше, стоит провести некоторое исследование, чтобы выяснить, предлагает ли ваша CMS простое решение для добавления канонических тегов на страницы вашего сайта.

Ссылайте повторяющиеся страницы на предпочтительный URL-адрес с помощью канонических тегов

Устраняет проблемы с URL-адресами, которые меняются в зависимости от устройства, используемого для просмотра страницы.

Если на вашем сайте есть и мобильный (m. [Site] .com), и версия для ПК ([site] .com), выберите сайт, который будет служить вашей канонической версией. Скорее всего, это будет ваш сайт для настольных компьютеров, поэтому мы будем использовать его в качестве примера нашей канонической версии ниже.

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

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

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

Убедитесь, что другие сайты используют канонические теги при публикации вашего контента

Решает проблемы с синдицированным контентом / контентом, который дублируется на нескольких сайтах

Если вы объединяете свой контент или публикуете его на нескольких сайтах, важно убедиться, что любой Дополнительный сайт, на котором публикуется ваш контент, включает тег rel = canonical, который указывает на URL-адрес контента на вашем сайте. В противном случае Google может быть не в состоянии определить исходный источник контента и может поставить вторичный сайт выше, чем ваш.

Рекомендации по использованию канонических тегов

При добавлении канонических тегов на страницы вашего веб-сайта важно соблюдать несколько рекомендаций:

  • Добавьте канонический тег и URL-адрес на каждую страницу вашего сайта. Даже если в настоящее время у вас нет проблем с дублированием контента, как вы видели, они могут легко произойти случайно и без вашего ведома. По этой причине рекомендуется просто по умолчанию добавлять самореферентные канонические теги на каждую страницу вашего сайта и каждую новую страницу, которую вы создаете.
  • Убедитесь, что сайты, повторно публикующие ваш контент, добавляют канонические теги, указывающие на ваш URL. В противном случае Google не будет знать наверняка, какой сайт был первоначальным источником содержания, и может поставить страницу, на которой повторно опубликовано ваше содержание, выше, чем ваша страница в результатах поиска.
  • Время от времени проверяйте канонические теги и URL-адреса. Рекомендуется время от времени проверять свои канонические публикации, чтобы убедиться, что они все еще существуют и работают правильно.Вы можете проверить это, запустив аудит сайта в инструменте SEO или используя расширение браузера, такое как MozBar, которое показывает вам канонический URL-адрес любой веб-страницы.
  • Не канонизировать при перенаправлении. Если нет смысла дублировать контент на двух или более разных URL-адресах, не беспокойтесь о добавлении канонического тега на неосновную страницу. Просто 301 перенаправит его на основной URL.
  • Убедитесь, что вы всегда используете одну и ту же структуру URL. Не добавляйте каноническую версию, использующую HTTP или WWW, если каноническая версия вашего веб-сайта - HTTPS или не WWW. Сохраняйте единообразие формата URL-адресов на всем сайте и в канонических тегах.
  • Используйте абсолютные URL-адреса, а не относительные. Абсолютный URL-адрес выглядит так: https://www.authoritylabs.com/pricing-updated/. Относительный URL не включает первую часть вашего домена: / pricing-updated /. При добавлении канонических тегов используйте абсолютные URL-адреса.
  • Канонизировать страницы на разных языках в первую страницу для этого языка. Если вы публикуете несколько версий своих страниц / контента на разных языках, не канонизируйте страницы, скажем, на немецком, в страницы на английском языке. Канонические немецкие страницы на главной странице написаны на немецком, даже если вы считаете английскую версию своей основной страницей.

Нет штрафа за дублированный контент, но есть проблемы с дублированием контента

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

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

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

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

.

c # - Как программно исправить неканонический список контроля доступа?

Переполнение стека
  1. Около
  2. Товары
  3. Для команд
  1. Переполнение стека Общественные вопросы и ответы
  2. Переполнение стека для команд Где разработчики и технологи делятся частными знаниями с коллегами
.Отсутствует

Canonicals, как исправить?

Здравствуйте!

Я рад видеть, что вы так глубоко погрузились в SEO!

Начиная с TSF v3.2.4, мы удаляем канонические URL-адреса со страниц, для которых для тега robots установлено значение «noindex» - если канонический URL-адрес не указывает на другую страницу.

Мы делаем это, потому что эти теги являются конфликтующими директивами, и это помогает ускорить деиндексирование. Screaming Frog также должен учитывать это.

По умолчанию мы применяем «noindex» к страницам с разбивкой на страницы, что вы также видите на изображениях, которыми вы поделились.Для этого есть переключатель на странице настроек SEO.

Надеюсь, это проясняет ситуацию 🙂 Если вы обнаружите еще какие-либо сомнительные данные, не стесняйтесь спрашивать нас об этом. Ура!

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

На многих моих страницах указаны неправильные канонические URL-адреса, например:
https://www.awesome.site.com/course/course-01
канонический адрес:
https://www.amazing.site.com/about

Но эти страницы совершенно разные.
>> Стоит отметить, что я использую мультисайт WP, поэтому панель администратора управляет двумя поддоменами:
https://www.awesome.site.com
https://www.amazing.site.com

Как я могу исправить свои канонические URL-адреса для определенной страницы?

Согласно вашему предыдущему ответу, я могу включить опцию «Noindex», но это неэффективно с точки зрения индексации и SEO!

Thx за консультацию

Ответил на запрос webzen69 на GitHub.

.

Почему нет канонического набора для страниц блога?

Привет

Всегда должен быть канонический URL, выводимый The SEO Framework (если это не страница BuddyPress).

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

Итак, канонический URL-адрес должен указывать на текущую страницу с разбивкой на страницы, а ссылки для разбивки на страницы сообщают сканерам, есть ли «предыдущая» или «следующая» страница.

Есть известная ошибка, при которой страницы блога всегда указывают на главную страницу блога, как, кажется, делает Yoast SEO. Это происходит только в том случае, если страница блога не является главной.

Google считает это самой распространенной ошибкой, здесь:
https://webmasters.googleblog.com/2013/04/5-common-mistakes-with-relcanonical.html

Указание rel = canonical со страницы 2 (или любой более поздней страницы) на страницу 1 не является правильным использованием rel = canonical, поскольку это не повторяющиеся страницы. Использование rel = canonical в этом случае приведет к тому, что контент на страницах 2 и выше вообще не будет проиндексирован.

Они предлагают указать URL-адрес на страницу «просмотреть все»; но по умолчанию это не поддерживается в WordPress. Мы могли бы добавить поддержку для этого, но это вызовет проблемы с производительностью.

Вот более подробное объяснение этой проблемы, где они демонстрируют использование разбивки на страницы в каноническом URL:
https://webmasters.googleblog.com/2011/09/pagination-with-relnext-and-relprev.html

Hi Sybre Waaijer,

Большое спасибо за быстрый ответ.

Мне очень жаль, я ошибочно указал страницу блога (домашнюю страницу).

На самом деле я имел в виду страницы категорий (Таксономия).

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

Также я не смог найти, как можно добавить параметр %% page %% в конце метаданных страницы категории, чтобы избежать дублирования, если Google проигнорировал канонический параметр, и действительно кажется, что часто Google игнорирует канонический URL и показывает повторяющиеся проблемы с инструментами для веб-мастеров по таксономии.

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

Опять же, мне очень жаль, что я создал путаницу.

Я очень ценю вашу оперативную поддержку и усилия, которые вы приложили, чтобы сделать ваш плагин одним из лучших!

С уважением
Swagatam

  • Этот ответ был изменен 2 года 1 месяц назад пользователем swagatam1975.

Hi Swagatam,

Не было путаницы 🙂 Чтобы исправить: то, что я написал, применимо ко всем страницам с разбивкой на страницы, включая термины и таксономии.

Подтвердить:

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

Итак, канонический URL-адрес должен указывать на текущую страницу с разбивкой на страницы, а ссылки для разбивки на страницы сообщают сканерам, есть ли «предыдущая» или «следующая» страница.

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

Даже если все теги отображаются правильно, синтаксическому анализатору Google может потребоваться время, чтобы «соединить точки». Таким образом, они будут отображать предупреждения в своей Search Console в качестве меры предосторожности, которые вы обычно можете игнорировать, поскольку они устраняются автоматически.

Итак, нет необходимости накладывать исправления не на те места.

Теперь TSF автоматически обеспечивает вывод заголовков на страницы. Таким образом, нигде нет необходимости в %% page %%.

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

Надеюсь, это проясняет ситуацию 🙂 Ура!

Большое спасибо Sybre за это подробное объяснение,

Он действительно прояснил все, что касается канокализации.

Я снова переключился на SEO Framework, я сохранил настройки по умолчанию, как есть, за исключением пары вещей, а именно:

1) Я установил отдельный плагин для генерации карты сайта.
2) Я предпочел, чтобы страницы архива были проиндексированы, сняв отметку с опции, которая говорит:
«Применять noindex к каждой второй или более поздней странице архива?»

Мне интересно проиндексировать страницы категорий, так как я добавил к ним уникальные описания, и я считаю, что они будут весьма полезны для читателей, чтобы выбрать наиболее подходящую статью по своему выбору 🙂

Буду признателен, если вы подтвердите, подходят ли они или не рекомендуются?

Я искренне благодарен за ваше время и ценные предложения.

Жду вашего ответа!

С уважением
Swagatam

  • Этот ответ был изменен 2 года 1 месяц назад пользователем swagatam1975.
  • Этот ответ был изменен 2 года 1 месяц назад пользователем swagatam1975.

Hi Swagatam,

То, что вы настроили, нормально 🙂

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

Тем не менее, если возникнут какие-либо проблемы, связанные с этими настройками, Google Search Console сможет уведомить вас об этом.

Я считаю, что на ваши вопросы были даны ответы, включая исходный вопрос по теме. Итак, я отмечаю это как решенное. Если у вас есть еще вопросы, то смело открывайте новую тему 🙂 Удачных выходных!

Большое спасибо, Sybre, за эту потрясающую поддержку и за разрешение всех моих сомнений, вам тоже удачных выходных !!

Привет, я понимаю ваши замечания о таксономиях:

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

Некоторые люди используют архивные страницы как ценный контент, о чем упоминалось выше swagatam1975. Другие, по какой-либо причине, могут предпочесть, чтобы страницы таксономии были скрыты или их было трудно найти. Для этого есть ли в плагине SEO Framework параметр, который позволит мне не индексировать архивы, как я сделал это с плагином Yoast? Я заинтересован в переключении и нащупываю каждую из функций, которые сейчас использую в Yoast.

Привет, @ dsb264!

Да, из правил есть исключения. Даже у меня есть недостатки, что не может не радовать: я вынужден внедрять, использовать и полировать их 😉

Что касается настроек роботов: (CPT) термины, такие как категории и теги, да. Архивы CPT, пока нет.
Не стесняйтесь установить плагин на тестовом сайте, чтобы проверить, соответствует ли он вашим целям.

Если у вас есть еще вопросы, открывайте новую тему, чтобы мы не беспокоили других 🙂

.

Смотрите также

Поделиться в соц. сетях

Опубликовать в Facebook
Опубликовать в Одноклассники
Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий