Полное руководство об URL-адресах в 2022 году

Полное руководство об URL-адресах в 2022 году

От протокола HTTPS до доменного имени, вплоть до (отсутствия) косой черты - каждая часть URL-адреса веб-страницы играет свою роль.

//

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

Независимо от того, работаете ли вы в сфере технологий/продуктов, редакционной работы и т.д., тема URL поднимается всегда. Какой URL лучше всего подходит для статьи? Имеет ли значение дата в URL? Имеет ли значение год, например 2022, в URL? Как создать оптимальные URL для разделов и тегов? Можем ли мы изменить наш (под)домен? Обычные вопросы, на которые издатели хотят получить простые ответы.

В этой статье я рассмотрю (почти) всё, что связано с URL-адресами. От протокола HTTP(S), вашего доменного имени и поддомена, до соглашений об именах ваших разделов и папок, вплоть до URL отдельных статей и того, используете ли вы при этом слэш (/) в конце. Обсудим каждую деталь и объясню, какое влияние она может оказать на SEO вашего сайта.

Спойлер: оптимизированные URL играют лишь малую роль в ранжировании статьи в любой вертикали Google.

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

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

Что такое URL?

URL – это веб-адрес ресурса. Этим ресурсом может быть веб-страница, изображение, файл JavaScript и т. д. Если к нему можно получить доступ через Интернет, он имеет URL.

Что такое URL?

URL состоит из нескольких компонентов. Он начинается со схемы, которая в наши дни обычно имеет вид «https://». Это означает, что речь идет о веб-ресурсе, обслуживаемом по протоколу HTTP с включенным шифрованием.

Затем мы получаем доменное имя – www.example.com – которое само состоит из трех компонентов:

  1. Субдомен: это обычное, но необязательное явление. Большинство сайтов используют субдомен «www», но многие сайты вообще не имеют субдомена и используют только домены второго и верхнего уровня.
    Например, freelance-blog.pro не использует поддомен, в то время как news.google.com является поддоменом google.com.
  2. Домен второго уровня: это основная часть доменного имени, которая обычно упоминается на одном дыхании с доменом верхнего уровня, когда мы говорим о веб-сайтах. Мы всегда говорим “Google точка com”, когда речь идет о сайте Google.
  3. Домен верхнего уровня: эта последняя часть доменного имени исторически обозначала тип организации (.com для коммерческих предприятий, .org для организаций и т.д.) и/или страну, с которой связан домен (.ru для предприятий в России, .by для каждого белорусского сайта и т.д.).
    В настоящее время домены верхнего уровня не указывают на типы бизнеса, хотя часто все еще имеют большое значение для страны, на которую, как предполагается, ориентирован ваш сайт. Подробнее об этом позже.

После домена указывается путь к веб-ресурсу, который обычно состоит из каталога (также известного как папка) и иногда заканчивается именем файла. Иногда URL может содержать параметры, которые обозначаются вопросительным знаком «?», за которым следует параметр.

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

HTTP против HTTPS

Первый вопрос, который возникает, – какую схему вы должны использовать? И ответ прост: HTTPS. В 2022 году только HTTPS!

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

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

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

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

HTTP/2?

Возможно, вы слышали о таком явлении, как HTTP/2. Это следующая версия протокола HTTP. На протяжении большей части существования интернета мы использовали версию 1.1 протокола HTTP, и пришло время для обновления.

Протокол HTTP/2 немного быстрее, чем HTTP/1.1, при этом ресурсы веб-страницы запрашиваются мгновенно, а не последовательно.

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

В лучшем случае, переход на HTTP/2 может немного повысить скорость сканирования вашего веб-сайта, так как робот Googlebot будет сканировать ваш сайт немного быстрее и эффективнее.

Доменные имена

Доменное имя издателя новостей – это не просто бренд. Ваше доменное имя посылает сильные сигналы о целевой направленности и релевантности.

Вопреки распространенному мнению, вам больше не нужно указывать в доменном имени конкретные ключевые слова. Сайт «freelance-blog.pro» не будет лучше ранжироваться по запросу “блог о фрилансе” из-за наличия этих слов в домене. Так было в доисторической сети интернет, но уже много лет это не является фактором.

Однако есть два важнейших компонента вашего домена, которые определяют ваш успех в Новостях Google: домен верхнего уровня (TLD) и субдомен.

TLD и геотаргетинг

Если вы используете общий TLD, например .com или .info, Google будет считать, что вы не нацелены на конкретную страну. Тем не менее, вы можете сообщить Google, что ваш контент предназначен для определенной страны.

Однако Google может сделать вывод о геотаргетированности вашего контента по другим признакам, таким как язык контента, структура папок, ссылки hreflang и т. д.

Если вы используете домен верхнего уровня с кодом страны (ccTLD), например .ru или .co.uk, Google всегда будет считать, что ваш контент предназначен в первую очередь для пользователей этой страны. Это не полностью помешает вашему сайту ранжироваться в других странах, но сильно помешает вам ранжироваться за пределами версии Google для вашей целевой страны.

Исключением являются домены верхнего уровня ccTLD, которые обычно используются как общие домены верхнего уровня, поэтому Google не предполагает геотаргетинг. Примером может служить домен .ms ccTLD, который является доменом с кодом страны Монтсеррат, но так часто используется за пределами Монтсеррата, что Google не предполагает геотаргетинг.

Если вы хотите проверить, считается ли TLD универсальным или привязанным к конкретной стране, Google ведет список TLD, которые он считает универсальными.

Субдомены

Используете ли вы субдомены или нет, не имеет значения для SEO. Google все равно, будете ли вы www.freelance-blog.pro, news.freelance-blog.pro, или просто freelance-blog.pro.

Что Google действительно волнует, так это согласованность.

Субдомены

Включение в экосистему новостей Google (что само по себе является спорной темой в наши дни) основано на полном доменном имени, также называемом «имя хоста».

Для Google www.example.com – это другой сайт, а не example.com. Если в настоящее время вы включены в Google Новости с веб-сайтом www.example.com, но решили изменить структуру сайта и переместить новостной контент на news.example.com, вы, по сути, сменили доменное имя.

Это означает, что вы потеряете свое включение в Google Новости.

Даже при наличии 301-редиректов и уведомления о смене адреса включение в Google Новости для вашего измененного домена маловероятно.

Всякий раз, когда я видел, как издатели меняют любую часть своего доменного имени – будь то просто поддомен, или полная смена домена – они всегда теряют трафик Google.

Этот трафик не возвращается. В лучшем случае они получат несколько всплесков трафика Google, но ничего существенного.

Когда они затем отменяют смену домена и возвращаются на старый домен, обычно мы видим, что трафик Google сразу же возвращается.

Итак, урок ясен: если вы в настоящее время получаете хороший трафик из Google, не меняйте никакую часть своего доменного имени.

Папки / Каталоги

Папки (они же каталоги) используются для разделения содержимого на разделы и подразделы. Обычно название раздела, например “Спорт”, напрямую указывается в названии папки: /sport/.

Важно использовать имена папок, которые точно отражают содержание раздела. URL папки должен отражать ее тему. Поэтому не стоит называть папку /sport/, а затем использовать ее для сбора статей о погоде; если она называется /sport/, в ней должны содержаться статьи о спорте.

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

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

Иерархия папок необязательна

При создании подраздела, который является частью более крупного раздела – например, регби в разделе “Спорт” – следует ли создавать папку /rugby/ в папке /sport/, чтобы получить /sport/rugby/?

Или вы можете просто использовать /rugby/ как папку в домене, без каких-либо отношений “родитель-ребенок”?

Ответ: для SEO разница минимальна.

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

Лично я предпочитаю иерархические папки (example.com/sport/rugby/), но вы также можете использовать корневые папки для каждого раздела и подраздела на вашем сайте (example.com/sport/ и example.com/rugby/). Иерархия папок может служить для удобства пользователей, но она не помогает и не мешает вашему SEO в значительной степени.

Основными факторами, определяющими SEO-ценность данного (под)раздела, являются название раздела (в частности, заголовок <h1> и мета-тег <title>) и внутренняя перелинковка.

Основными факторами, определяющими SEO-ценность данного (под)раздела, являются название раздела (в частности, заголовок и мета-тег ) и внутренняя перелинковка.

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

Когда такой подраздел, как “Регби”, является частью верхней навигации вашего сайта – в идеале, как часть набора контекстных поднавигационных ссылок под верхней навигационной рубрикой “Спорт” – тогда URL-адрес подраздела не имеет значения. Будь то /sport/rugby/ или просто /rugby/, важно, чтобы ссылка «Rugby» занимала видное место в верхней навигации.

Джон Мюллер, сотрудник Google, заявил, что важна глубина клика, а не фактическая структура папок URL.

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

URL-адреса статей

Итак, из чего складывается идеально оптимизированный URL-адрес статьи? Я получаю очень много вопросов по этому поводу, поэтому я рассмотрю наиболее распространенные из них по очереди:

  • Должны ли URL-адреса статей содержать даты?

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

Но это небольшой риск, поскольку дата “публикации”, или “последнего изменения” на странице с большей вероятностью будет замечена. Для Google эта визуальная дата в сочетании с атрибутом ‘dateModified’ в структурированных данных NewsArticle и атрибутом <lastmod> в XML-карте сайта играют гораздо большую роль. Дата в URL ничтожно мала.

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

  • Должны ли URL-адреса статей иметь структуру папок?

Это необязательно, но может помочь. Google любит, когда соответствующие объекты, упомянутые в статье, отражены в URL. Если вы пишете статью о сборной России по футболу, то вам поможет наличие слов «футбол» и «Россия» в URL статьи.

Будет ли это в виде (под)папок или как часть имени файла статьи (также известного как “slug”), не имеет значения, главное, чтобы они были в полном URL-адресе статьи.

Таким образом, для Google все это нормально:

example.com/russia-defeat-blr-football
example.com/football/russia-defeat-blr-six-zero
example.com/football/russia/wales-defeated-six-zero

Имейте в виду, что в наши дни Google очень хорошо понимает синонимы.

Вы можете легко проверить это: просто выполните поиск Google по двум похожим фразам, и вы, скорее всего, увидите очень похожие результаты SERP.

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

  • Может ли URL отличаться от заголовка?

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

URL-адрес и заголовок должны совпадать тематически. Заголовок служит тематической цели: он указывает на содержание статьи. URL-адрес служит той же цели.

Для статьи с таким URL оба следующих заголовка вполне приемлемы:

URL: /ireland-defeat-russia-six-nations-opener/

✅ Заголовок: Ирландия разгромила Россию в первом матче Шести наций

✅ Заголовок: Конвей и Хансен стали звездами, когда Россия потерпела сокрушительное поражение от ирландской регбийной команды

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

  • Можно ли использовать специальные символы в URL?

Короткий ответ: да, но не стоит этого делать.

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

Для разделения слов рекомендуется использовать дефисы. Избегайте специальных символов, которые могут привести к кодировке URL (это когда вы видите числовые строки с символом процента).

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

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

  • Можно ли использовать заглавные буквы?

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

Поэтому /Irish-Rugby/ – это другая страница, чем /irish-rugby/. Если ваш сайт размещает идентичный контент на обоих этих URL-адресах, вы можете создать для себя проблемы с дублированием контента.

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

Просто придерживайтесь строчных букв в URL-адресах.

  • Что как насчет расширений файлов типа .html ?

Этот вопрос может быть актуален, если у вас есть сайт, на котором в конце URL веб-страницы все еще используются расширения типа .php или .html.

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

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

То же самое относится и к слэшам в конце. Эти два URL-адреса, по сути, являются двумя разными страницами, как считает Google:

example.com/russia-defeat-blr-football
example.com/russia-defeat-blr-football/

Слэш делает URL-адрес другим и заставит Google рассматривать его как отдельную статью.

Простого тега rel=canonical недостаточно для устранения такого дублирования. Используете ли вы .html, или слэш, или вообще ничего, не имеет значения для SEO, Google воспринимает их все одинаково.

Но вы всегда захотите внедрить автоматическое перенаправление с нежелательной версии на желательную, или выдавать ошибку 404 Not Found на нежелательной версии URL-адреса.

А ваши внутренние ссылки и XML-sitemaps должны всегда ссылаться на предпочтительные URL-адреса и только на предпочтительные URL-адреса.

  • Можно ли использовать параметры в URL-адресах статей?

Можно, но не следует этого делать. В документации Publisher Center, касающейся перенаправлений, Google особо рекомендует не использовать параметр ‘?id=’ в URL-адресах статей.

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

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

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

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

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

Поэтому, как правило, избегайте использования параметров в URL-адресах статей.

  • Нужен ли моим URL-адресам статей уникальный идентификатор?

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

Google отказался от этого требования много лет назад, когда система индексирования новостей стала более совершенной (а в 2019 году объединилась с обычной системой индексирования). Поэтому вам в 2022 году больше не нужны уникальные коды ID в URL-адресах статей.

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

  • Какой длины должен быть мой URL?

Сколько угодно, вплоть до довольно экстремального ограничения в 2048 символов, встроенного в большинство браузеров. Существует небольшая корреляция между длиной URL и эффективностью статьи в экосистеме новостей Google.

Как правило, я предпочитаю несколько более короткие URL, но это в основном по причинам удобства использования. Я рекомендую удалять стоп-слова из URL, поэтому я бы предпочел, чтобы:

/russia-defeat-blr-six-nations-opener

а не

/russia-defeat-blr-in-six-nations-opener

Но различия незначительны, и для SEO это не имеет значения. Независимо от того, будет ли URL-адрес вашей статьи состоять из 50 или 200 символов, Google будет ранжировать ее просто отлично.

Стоит ли вам менять URL?

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

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

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

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

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

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

Проблема с изменением URL-адресов

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

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

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

Кроме того, существует теория, согласно которой при перенаправлении теряется определенная часть PageRank (ссылочный капитал). На протяжении многих лет Google давал противоречивую информацию об этом, хотя в последнее время они, кажется, стандартизировали свое мнение: “При перенаправлении ценность ссылок не теряется”, к чему я, признаться, отношусь несколько скептически.

Независимо от этого, совет остается прежним: не меняйте URL-адреса ни для одной части индексируемого контента, если у вас нет на то веских причин.

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

URL-адрес и фактор ранжирования

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

URL-адрес и фактор ранжирования

Для статей я считаю, что это основные факторы ранжирования, характерные для новостей, перечисленные в порядке важности:

  1. Заголовок статьи.
  2. Содержание и качество статьи.
  3. Размер и соотношение сторон изображения.
  4. Категоризация статей.
  5. Средние показатели Core Web Vitals статьи.
  6. Факторы E-A-T сайта.
  7. URL-адрес статьи.
  8. Meta Title

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

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

Предыдущая

Как разработать план маркетинга для бизнес планирования на 2022 год?

Следующая

Топ 10 лучших поисковых систем (десять самых популярных в мире)

Последние от Должен прочитать