SEO, смягчая дублирующиеся проблемы с контентом

1. Перенаправление вместо ответа
2. Используйте Canonicalization

Это часть моего Entreprenerd: маркетинг для программистов Книга, которая в настоящее время доступна для чтения бесплатно онлайн.

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

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

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

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

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

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

• Ваш сайт существует в клонированной форме в нескольких доменах и поддоменах. Чаще всего это происходит, когда ваш веб-сайт отвечает и обслуживает один и тот же контент как для www.mywebsite.com, так и для mywebsite.com. По сути, это создает дубликаты для каждой страницы всего домена - единственное отличие состоит в том, что одна версия имеет «www» впереди, а другая - нет.

• Ваш веб-сайт имеет несколько URL-адресов для доступа к одному и тому же контенту. Например, «/ t-shirts» и «/ category / t-shirts» могут указывать на одну и ту же страницу (т. Е. На ту, которая отображает футболки, которые вы предлагаете для продажи). Эта проблема часто возникает на домашней странице, которая на старомодных веб-сайтах может быть доступна по-разному с помощью «/index.php», «/ home» и корневого URL-адреса «/».

• Вы добавляете параметры к URL-адресам, и некоторые изменения этих параметров приводят к тому же или очень похожему содержанию, что и другие изменения. Например, параметры сортировки, такие как «/ t-shirts? Sort = price_asc», приводят к тому же контенту, только переставленному. Иногда параметры фильтров также приводят к дублированию, например, когда «/ t-shirts? Review_score_greater_than = 3» (который фильтрует страницу, чтобы показать только элементы с оценками более 3) влияет на набор данных, в котором каждый элемент имеет оценку обзора по крайней мере, 4, что означает, что отфильтрованная страница точно такая же, как и нефильтрованный оригинал. Поисковые системы не удаляют эти параметры автоматически, как вы могли бы ожидать.

• Ваш веб-сайт отправляет HTTP-статус 200 как на «/ products», так и на эквивалентную косую черту «/ products /». Удивительно, но Google рассматривает оба сайта как отдельные URL, явно указав их в официальной литературе для веб-мастеров. Они упоминают, что эта практика «часто в порядке», но не «совершенно оптимальна». Внимательный веб-мастер должен убедиться, что их веб-сайт реагирует только на одну из этих возможностей.

• Ваш веб-сайт отображает одинаковое содержимое как в верхнем, так и в нижнем регистре версий URL (например, «/ taxons / t-shirts» и «/ taxons / T-SHIRTS» ведут к одному и тому же содержимому).

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

Теперь вернемся к удалению нежелательного дублированного контента.

Перенаправление вместо ответа

Это должно стать вашей первой линией защиты от дублирующегося контента, благодаря простоте использования и малому влиянию на сок ссылок SEO по сравнению с ядерной опцией - директивой robots.txt (которую мы увидим позже).

Допустим, вы хотите, чтобы ваши клиенты могли посещать сайты www.mywebsite.com и mywebsite.com. Вместо того, чтобы отображать контент для обеих возможностей (и отвечать на 200), вы должны указать маршрутизатору вашего сервера ответить кодом ответа HTTP 301 (постоянное перенаправление) на одну из двух возможностей, перенаправив все эти запросы на ваш теперь официально утвержденный выбор. Веб-страница, на которую указывает точка перенаправления, получит не менее 90% от рейтинга перенаправленной ссылки.

Пока мы находимся на теме перенаправлений, давайте выделим еще одну их цель в SEO: сохранение ссылочного сока на удаленных или отредактированных URL-адресах. Как вы знаете, любая страница на вашем веб-сайте может накапливать репутацию, ссылки и рейтинг Google в обычных поисках. Но всякий раз, когда вы редактируете его URL-имя (или вообще удаляете страницу), вы сбрасываете счетчики на ноль, отбрасывая каждую последнюю каплю SEO-сока, заработанного этим URL-адресом. В этих условиях на помощь приходит код ответа 301. Его эффект - напоминание роботу Google: «Эй, робот Google, старая страница, которую ты ищешь, перемещена. Пожалуйста, обновите свой индекс и перенесите все мои SEO рейтинги соответственно. Kthxbai. »Этот момент важен. В самом деле, я бы сказал, что редактирование URL-адреса без перенаправления 301 на старое настолько близко к самоубийству SEO, насколько я могу себе представить. И все же это происходит постоянно.

Сложно убедиться, что перенаправления всегда создаются после редактирования старых URL-адресов. Вам нужно не только следить за программистами, которые редактируют структуры URL, но также за административным персоналом, который редактирует ссылки в CMS, и за обычными пользователями, которые изменяют свой собственный контент, как это часто происходит. Чтобы решить эти проблемы в систематическом масштабе, рассмотрите возможность применения неизменяемых постоянных ссылок, прикрепленных к каждому фрагменту содержимого базы данных, тем самым замораживая исходный URL-адрес и защищая его от изменений. Если это невозможно (скажем, потому что вашим клиентам необходимо изменить URL-адреса), рассмотрите систему с поддержкой базы данных, которая автоматически запоминает ваши старые URL-адреса и отвечает на запросы для них, отправляя их 301-м до их последнего воплощения.

Используйте Canonicalization

В отличие от перенаправлений, при канонизации ваш сервер будет продолжать отвечать (с кодом состояния HTTP 200) на дублирующиеся URL-адреса. Вместо этого теперь будут добавлены фрагменты HTML-кода, добавленные к дублирующимся страницам, и цель этого состоит в том, чтобы объяснить Google, какая страница является «канонической» (т. Е. Окончательной, которая должна отображаться в их результатах поиска и накапливать все поисковый сок).

Вот пример используемой канонизации, как вы можете увидеть на странице «http://www.mywebsite.com/index.php», которая дублирует корневой URL.

<link href = "http://www.mywebsite.com" rel = "canonical">

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

Как и в случае с перенаправлениями, канонизация сохраняет сок ссылок на повторяющихся страницах.

Атрибут href канонического тега URL принимает полностью определенные абсолютные пути (включая «http: //») и относительные пути (не). Я рекомендую придерживаться полностью определенных абсолютных путей, поскольку плохо сформированные пути могут потенциально привести к коварным, разрушительным ошибкам (см. Предупреждение Google по этой теме). Например, если вы напишите «mywebsite.com/t-shirts», он будет относить ваш SEO-контент к «http://www.mywebsite.com/mywebsite.com/t-shirts Между» - несуществующей странице. Это происходит потому, что начальный «/» отсутствовал в относительном пути.

Кстати, при использовании абсолютных путей есть потенциальная ошибка: вам нужен правильный протокол («https: //…» против «http: //…»)

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

Несмотря на эту возможность, я, тем не менее, рекомендую не использовать robots.txt для этих целей, а вместо этого советую вам обратиться к перенаправлениям или каноническим URL-адресам (или мета-тэгам robots…).

Почему так? Дублирующие URL-адреса иногда накапливают приличный SEO-сок (например, мобильная версия вашего сайта [«m.mywebsite.com»]). В идеале вы хотите направить этот SEO-сок на свою главную страницу (например, «www.mywebsite.com»), чтобы не потерять авторитет. Проблема с перечислением URL-адресов в файле robots.txt заключается в том, что вы теряете ВСЕ их SEO-сок. Как говорит Адам Одетт, это «тупик Пейджранка», «кувалда». Эта трата не происходит с другими механизмами уменьшения дублирующегося контента, такими как перенаправления и канонизация, которые гораздо более эффективны при сохранении SEO-сока.

Все это говорит о том, что есть хорошие сценарии использования для директив роботов. Основным среди них является удаление низкокачественного неповторяющегося контента из индекса Google. Поначалу может показаться нелогичным хотеть уменьшить площадь сканирования вашего сайта, но для многих веб-мастеров этот подход приносит дивиденды. Наличие ограничения robots.txt не дает паршивым точкам входа на ваш сайт появляться в результатах поиска. Например, в моей компании Oxbridge Notes у нас есть (по общему мнению, дурацкий) дизайн URL-адреса, согласно которому каждая страница продукта ссылается на вложенную страницу для отправки вопросов продавцу этого конкретного продукта. Это дает нам такие URL-адреса, как «/ land-law-notes / purchase_inquiries», «contract-law-notes / seller_inquiries» и т. Д., Тысячи раз. Я не хотел, чтобы эти общие, заполненные вопросом страницы формы вопросов засоряли мои результаты поиска и конкурировали с моими оптимизированными целевыми страницами (родительские страницы продукта, такие как «/ land-law-notes»), поэтому с этой целью Я обновил свое уведомление robots.txt с указанием не сканировать эти страницы «customer_inquiries».

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

Еще один хороший пример использования robots.txt - конфиденциальность. В стране, где я живу, каждый владелец сайта должен разместить свои контактные данные на своем сайте на странице, известной как импрессум. Как человек, ведущий веб-бизнес с удаленными работниками, у меня нет выделенного офиса. В этом случае закон требует, чтобы я разместил свой домашний адрес на странице импрессума. Это заставляет меня чувствовать себя неловко из-за моей конфиденциальности и моей безопасности. Не так давно на меня напал отвратительный грабитель и пригрозил, что если я сообщу о нем в полицию (что я впоследствии и сделал), он будет ждать меня возле моей квартиры (чего, к счастью, он впоследствии не сделал). У этой угрозы были зубы, хотя, потому что я знал, что столь злонамеренному персонажу, чтобы выяснить, где я живу, нужно только найти «адрес Джека Кинселлы». (Он знал мое имя по идентификационной карточке, которую он украл у меня.) Возможно, robots.txt мог бы снизить этот риск, например, если бы я дал указание поисковым системам не индексировать страницу, содержащую мой адрес.

Robots.txt также может сохранить конфиденциальность в менее драматических обстоятельствах. Например, некоторые веб-мастера используют его, чтобы скрыть контент и функции, которые еще не были официально запущены.

Если вы действительно хотите ограничить доступ сканеров к контенту с помощью директив robots, я бы посоветовал вам не полагаться на классический файл robots.txt, а вместо этого полагаться на более новый, и, на мой взгляд, превосходящий, тег meta robots.

Большая проблема с файлом robots.txt заключается в том, что он не совсем делает то, что предполагает; это только инструктирует поисковые системы не посещать URL . Удивительно, но поисковые системы, тем не менее, будут индексировать существование этого URL и отображать уродливые, урезанные, лишенные содержания записи-призраки для результатов поиска. Вы, вероятно, не хотите этого:

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

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

<meta name = "robots" rel = "noindex, follow">

В приведенном выше примере показан тег meta robots, указывающий роботу Google не индексировать страницу, а «Следовать» (т. Е. Приписать ссылку на сок) любые ссылки на этой заблокированной странице, это означает, что внешние ссылки на эту «роботизированную» страницу не будут полностью потрачены впустую, как если бы мы использовали запись robots.txt. (Таким образом, эта директива follow следует, по существу, устраняет основной недостаток сока ссылок в обычных записях robots.txt.)

Полное описание различных аргументов, принимаемых тегами мета-роботов, см. В руководстве Google по этой теме. (Интересный пример: инструкция «noarchive» предписывает роботу Google не включать страницу в кеш Google, что является хорошим благом для конфиденциальности).

Последний пункт: мета-тег robots является свойством HTML. Что если вы хотите ограничить индексацию не-HTML контента, такого как PDF-файлы? Заголовок X-Robots-Tag HTTP выполняет эту роль и принимает те же аргументы, что и мета-тег robots, предоставляя вам точно такой же набор функций для контента в альтернативных форматах.