SEO SEO для канонических URL + тег Rel = Canonical - Whiteboard Friday - CommonDenominator.email - электронная почта и CRM-консультирование

1. Транскрипция видео
2. Что такое «канонический» URL?
3. Различные способы канонизации нескольких URL
4. НЕ РЕКОМЕНДУЕТСЯ
5. Когда канонизировать URL

Сообщение от randfish

Если у вас когда-либо возникали вопросы по поводу канонического тега, хорошо, у нас для вас есть Whiteboard Friday. В сегодняшнем эпизоде ​​Рэнд определяет, что означает rel = canonical и его предполагаемое назначение, когда рекомендуется его использовать, как его использовать, и какие ситуации нужно избегать.

Нажмите на изображение доски выше, чтобы открыть версию с высоким разрешением в новой вкладке!

Транскрипция видео

Привет, фанаты Moz и добро пожаловать на очередное издание Whiteboard Friday. На этой неделе мы поговорим о некоторых лучших SEO-методах для канонизации и использования тега rel = canonical.

Прежде чем мы это сделаем, я думаю, что стоит поговорить о том, что такое канонический URL, потому что канонический URL не просто ссылается на страницу, на которую мы нацеливаемся или используем тег rel = canonical. Фактически канонизация существует намного дольше, чем сам тег rel = canonical, появившийся в 2009 году, и есть много разных вещей, которые означает канонический URL.

Что такое «канонический» URL?

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

Так, например, у меня есть канонический URL, ABC.com/a.

Тогда у меня есть копия этого по какой-то причине. Может быть, это исторический артефакт или проблема в архитектуре моего сайта. Может быть, я сделал это намеренно. Может быть, я делаю это для каких-то целей отслеживания или тестирования. Но этот URL находится на ABC.com/b.

Затем у меня есть другая версия, ABC.com/a?ref=twitter. Что там происходит? Ну, это параметр URL. Параметр URL не меняет содержимое. Содержание точно такое же, как у A, но я действительно не хочу, чтобы Google запутался и оценил эту версию, что может случиться, кстати. Вы увидите URL-адреса, отличные от оригинальной версии, которые иногда имеют странные ранжирования параметров URL в Google. Иногда эта версия получает больше ссылок, чем эта версия, потому что они публикуются в Твиттере, и именно поэтому все выбирают, копируют, вставляют и связывают. Это все хорошо, пока мы канонизируем это.

Или этот, это версия для печати. Это ABC.com/aprint.html. Итак, во всех этих случаях я хочу сказать Google: «Не индексируйте это. Индексируйте это. Не индексируйте это. Индексируйте это. Не индексируйте это. Индексируйте это. ”

Я могу сделать это, используя ссылку rel = canonical, где Google говорит: «Это страница». Вы помещаете это в тег заголовка любого документа, и Google узнает: «Ага, это копия или клон». или дубликат этого другого. Я должен канонизировать все мои ранговые сигналы, и я должен убедиться, что эта другая версия занимает место ».

Кстати, вы можете быть ссылками на себя. Так что ABC.com/a вполне может пойти дальше и использовать это, указывая на себя. Таким образом, в случае, если кто-то, кого вы никогда не встречали, решит вставить вопросительный знак, какой-то странный параметр и указать вам, вы все равно говорите Google: «Эй, угадай, что? Это оригинальная версия ».

Отлично. Поэтому, поскольку я не хочу, чтобы Google был сбит с толку, я могу использовать этот процесс канонизации для этого. Тег rel = canonical - отличный способ. Кстати, к вашему сведению, его можно использовать междоменный. Так, например, если я переиздаю контент на А на чем-то вроде Medium.com/@RandFish, что, как мне кажется, является моей учетной записью Medium / a, угадайте, что? Я могу вставить междоменный rel = canonical, сказав им: «Вот здесь». Теперь, даже если Google сканирует этот другой веб-сайт, они узнают, что это оригинальная версия. Довольно чертовски круто.

Различные способы канонизации нескольких URL

Существуют разные способы канонизации нескольких URL.

1. Rel = канонический.

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

2. 301 редирект.

Перенаправление 301, это в основном код состояния, говорящий Google: «Эй, знаешь что? Я собираюсь взять / б, я собираюсь указать на / а. Было ошибкой когда-либо иметь / б. Я не хочу, чтобы кто-нибудь посещал его. Я не хочу, чтобы это засоряло мою веб-аналитику данными о посещениях. Знаешь что? Давайте просто 301 перенаправим этот старый URL на новый, на правильный ».

3. Пассивные параметры в поисковой консоли Google.

Некоторые части меня любят это, некоторые части меня нет. Я думаю, что для очень сложных веб-сайтов с тоннами параметров URL и тонной URL иногда бывает просто невероятно больно обращаться к команде разработчиков веб-приложений и говорить: «Эй, нам нужно очистить все эти параметры URL. Мне нужно, чтобы вы добавили тег rel = canonical на все эти разные типы страниц, и вот на что они должны указывать. Вот логика, чтобы сделать это ». Они как,« Да, угадайте что? SEO не является для нас приоритетом в течение следующих шести месяцев, поэтому вам придется с этим справиться ».

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

Так, например, у вас есть sessionid = бла, бла, бла. Вы можете установить это, чтобы быть пассивным. Вы можете установить пассивность на определенные виды URL. Вы можете установить его как пассивный для всех типов URL. Это помогает Google сказать: «Эй, угадай, что? Всякий раз, когда вы видите этот параметр URL, просто относитесь к нему, как будто он вообще не существует ». Это может быть полезным способом канонизации.

4. Используйте хеши местоположений.

Итак, допустим, что моя цель с / b состояла в том, чтобы в основном иметь тот же контент, что и / a, но с одним небольшим отличием: я собирался взять блок контента о подразделе темы и поместить его наверх. Таким образом, у A есть раздел о ручках для досок вверху, но B помещает раздел о ручках для досок внизу, а сами разделы о досках вверху. Ну, это тот же контент, та же цель поиска за ним. Я делаю то же самое.

Ну, угадай что? Вы можете использовать хеш в URL. Так что это # ​​b, и это кого-то перепрыгнет - его также называют URL-адрес фрагмента - кто-то переместится в этот конкретный раздел на странице. Вы можете увидеть это, например, Moz.com/about/jobs , Я думаю, если вы подключите #listings , это приведет вас прямо к списку вакансий. Вместо того, чтобы читать о том, каково это работать здесь, вы можете просто перейти непосредственно к списку рабочих мест. Теперь Google считает, что все это один URL. Таким образом, они не собираются оценивать их по-другому. Они не индексируются по-разному. Они по существу канонизированы по одному и тому же URL.

НЕ РЕКОМЕНДУЕТСЯ

Я не рекомендую ...

5. Блокирование Google от сканирования одного URL, но не другой версии.

Потому что угадай что? Даже если вы используете robots.txt и блокируете паука Googlebot, и вы отправляете его, и они не могут его достать, потому что вы сказали, что robots.txt запрещает / b, Google не будет знать, что / b и / a имеют одинаковый контент на них , Как они могли?

Они не могут ползти. Таким образом, они не могут видеть ничего, что здесь. Это невидимо для них. Поэтому они не будут знать, что какие-либо сигналы ранжирования, какие-либо ссылки, которые там указывают, какие-либо сигналы вовлечения, какие-либо сигналы контента, какие бы сигналы ранжирования не помогли A ранжироваться лучше, они не смогут их увидеть. Если вы можете канонизировать одним из этих способов, теперь вы говорите Google, да, B - это то же самое, что и A, объедините их силы, дайте мне все возможности ранжирования.

6. Я бы также не рекомендовал блокировать индексацию.

Так что вы можете сказать: «О, хорошо, Рэнд, я буду использовать мета-роботов без индексного тега, чтобы Google мог сканировать его, они могли видеть, что контент такой же, но я не позволю им индексировать его. ." Угадай, что? Та же проблема. Они могут видеть, что контент один и тот же, но если Google не достаточно умен, чтобы автоматически канонизировать, чему я бы им не доверял, я бы всегда сначала доверял себе, вы, по сути, опять же мешаете им объединять ранжирующие сигналы B в А, и это то, что вы действительно хотите.

7. Я бы не рекомендовал использовать 302, 307 или любые другие 30x, кроме 301.

Это тот парень, которого ты хочешь. Это постоянный редирект. Наиболее вероятно, что он наиболее успешен в канонизации, хотя Google сказал: «Мы часто относимся к 301 и 302 одинаково». Исключением из этого правила является то, что 301, вероятно, лучше для канонизации. Угадай, что мы пытаемся сделать? КаноническаяФорма!

8. Не используйте 40-кратную неканоническую версию.

Так что не берите / b и говорите: «О, хорошо, это не та версия, которую мы хотим больше. Мы сделаем это 404 ». Не делайте этого 404, когда вы могли бы 301. Если вы отправите его сюда с 301 или используете rel = canonical в своем заголовке, вы берете все сигналы и указываете их на A. Вы потерять их, если вы 404, что в B. Теперь все сигналы от B. ушли. Это грустная и ужасная вещь. Вы тоже не хотите этого делать.

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

Когда канонизировать URL

И последнее, но не менее важное: когда мы должны канонизировать URL-адреса, а не нет?

I. Если содержание очень похоже или точно дублируется.

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

II. Если контент обслуживает одно и то же (или почти одинаковое) намерение поисковика (даже если цели KW несколько различаются).

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

Например, эта пятничная доска об использовании rel = canonical, о канонизации заменит старая версия с 2009 года. Мы собираемся взять эту старую версию, и мы будем использовать rel = canonical. Почему мы собираемся использовать rel = canonical? Так что вы по-прежнему можете получить доступ к старой, если по какой-то причине вы хотите увидеть версию, с которой мы первоначально вышли в 2009 году. Но мы определенно не хотим, чтобы люди посещали эту версию, и мы хотим сказать Google: «Эй, самый современный, новый, лучший - это новая версия, которую вы смотрите прямо сейчас ». Я знаю, что это немного мета, но это вполне разумное использование.

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

III. Если вы переиздаете или обновляете или обновляете старый контент.

Как и в примере с Whiteboard Friday, который я только что использовал, вы должны использовать rel = canonical в большинстве случаев. Есть несколько исключений. Если вы хотите сохранить эту старую версию, но хотите, чтобы сигналы ранжирования старой версии пришли к новой версии, вы можете взять содержимое из старой версии, повторно опубликовать его в / a-old. Затем возьмите / a и перенаправьте его или опубликуйте новую версию там, и пусть эта версия будет той, которая является канонической, и старая версия существует по некоторому URL, который вы только что создали, но это / old. Таким образом, повторная публикация, обновление, обновление старого контента, как правило, канонизация - это путь, и вы можете сохранить старую версию, если хотите.

Внутривенно Если контент, продукт, событие и т. Д. Больше недоступны, и по другому URL-адресу есть почти лучшее совпадение.

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

Хорошо, ребята. С нетерпением ждем ваших вопросов о rel = canonicals, канонических URL-адресах и канонизации в целом в SEO. И мы еще увидимся на следующей неделе для очередного выпуска Whiteboard Friday. Береги себя.

Видео транскрипция от Speechpad.com

Зарегистрируйтесь в The Moz Top 10 еженедельно отправляющая вам по электронной почте обновленную информацию о десяти самых популярных новостях, советах и ​​ссылках на радости, обнаруженных командой Moz. Думайте об этом как о своем эксклюзивном дайджесте материала, который вы не успеваете выследить, но хотите прочитать!

Похожие

Комментарии