0

15 лучших SEO-приемов для структурирования адресов URL

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

#1: По возможности всегда используйте один домен и поддомен

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

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

#2: Обеспечьте хорошую читаемость для людей

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

Читабельность может быть субъективным фактором, но для наглядности я приведу такую иллюстрацию:

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

#3: Не забывайте про ключевые слова в URL

Для ранжирования все еще актуально использовать ключевые слова в URL. И на это есть несколько причин.

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

Второе: адреса URL постоянно копируются и вставляются, и когда в ссылке нет анкорного текста, сам URL выполняет эту роль (что является эффективной вводной информацией для ранжирования). Например:

 

Третье: ключевые слова в URL видны на страницах выдачи. Исследования показывают, что URL — один из самых значимых элементов, который рассматривают пользователи, когда выбирают, по какой ссылке пройти.

#4: Если несколько адресов URL обслуживают похожий контент, то канонизируйте их

Если у вас есть два адреса URL, которые обслуживают схожий контент, канонизируйте их с помощью переадресации 301 (если нет объективных причин сохранять дубликат) или атрибута rel=canonical (если вам нужно сохранить различающиеся версии для разных посетителей) (Например, оставить страницу с более дружелюбным для печати видом).

Поисковые системы не накладывают штрафов за дублирование контента (как минимум пока вы не начали создавать копии в больших масштабах), но это может сказаться на ранжировании, что навредит вашему потенциальному трафику. Если страница A занимает определенное место в выдаче, а ее дубликат, страница A2, находится примерно на том же уровне, то при их канонизации, страница A получит больше шансов укрепить свою позицию и привлечь посетителей.

#5: По возможности исключайте динамические параметры

Такой вариант адреса выглядит некрасиво:

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

Создатели многих платформ CMS с годами осознали это, но не все. Посмотрите инструменты вроде mod_rewrite и ISAPI rewrite или URL Rewrite Module от Microsoft (для IIS), чтобы облегчить для себя этот процесс.

Некоторые динамические параметры применяются для отслеживания кликов (например, такие встраиваются в популярные приложения для социального взаимодействия вроде Buffer или к примеру UTM-метки в Яндекс Директе). В целом это небольшая проблема, но параметры создают неприглядные и очень длинные адреса URL. Решите для себя, перевесит ли польза отслеживающего параметра сопутствующие негативные эффекты.

Исследование от RadiumOne за 2014 год показывает, что социальные взаимодействия (которые имеют положительное, но обычно непрямое влияние на SEO) с более короткими, логично связанными с сайтом и контентом адресами URL работают лучше, чем непонятные сокращения или длинные строки URL.

#6: Используйте короткие адреса вместо длинных

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

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

#7: Старайтесь сопоставлять адреса URL с заголовками страниц (если это имеет смысл)

Это не значит, что если заголовок на вашей странице звучит как «7 моих любимых сортов шотландского виски (и как покупка одной бутылки стоила мне целой коллекции Lego)», то адрес должен полностью ему соответствовать.  Скажем, этот вариант

kolyaswhisky.com/my-favorite-7-islay-whiskies

будет неплохо выглядеть. Можно и так:

kolyaswhisky.com/blog/favorite-7-bottles-islay-whisky

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

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

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

Стоит следовать тому же принципу в своих адресах URL и заголовках.

#8: Не беспокойтесь о стоп-словах в URL

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

Например, в адресе URL поста, который вы читаете, я решил оставить слово «for». Мне кажется, что со словом адрес легче прочитать, и это не слишком увеличивает длину URL.

#9: Удаляйте / регулируйте громоздкую пунктуацию

Есть много текстовых знаков, которые при попадании в адрес URL становятся отталкивающими частицами тяжело читаемого мусора. Но есть отличный способ удалить такие знаки или проконтролировать их наличие. На Perishable Press доступен список сохраняемых и не сохраняемых символов:

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

#10: Ограничивайте количество перенаправлений до двух и менее

Когда пользователь или поисковый агент запрашивает URL A, который перенаправляет на URL B, это нормально. Даже в том случае, если URL B затем перенаправляет на URL C (лучше, конечно, направить URL A напрямую к URL C, но ничего страшного в этом нет). Но если переадресация продолжается после двух скачков, у вас могут возникнуть проблемы.

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

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

#11: Сократите количество папок

Возьмем этот URL:

kolyaswhisky.com/scotch/lagavulin/15yr/distillers-edition/pedro-ximenez-cask/750ml

И преобразуем его в такой вариант:

kolyaswhisky.com/scotch/lagavulin-distillers-edition-750ml

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

Требование необязательное, и вам самим решать, как поступить.

#12: Избегайте в URL хеша, который создает отдельный/уникальный контент

Хеш (или идентификатор фрагментов URL) исторически был способом посылать пользователя в конкретное место на определенной странице. Хеши также могут использоваться вроде отслеживающих параметров (например, kolyaswhisky.com/lagavulin#src=twitter). Но использование хешей URL для отображения уникального контента — плохая идея.

Есть и исключения. Например, компания Google позволила разработчикам использовать формат шебанг (#!) для динамических приложений AJAX. Но даже они не особенно привлекательны, понятны пользователю или просты с точки зрения SEO, в отличие от статических переписанных адресов. Большинство сайтов, от Amazon до Twitter, получили огромную пользу от упрощения их предыдущих сложных и использующих шебанг адресов URL. Учтите это.

#13: Будьте осторожны с чувствительностью к регистру

Несколько лет назад Джон Шеррод из Search Discovery написал отличную статью, в которой отмечались сложности и проблемы, связанные с чувствительностью к регистру в URL. Вкратце, если вы используете серверы Microsoft/IIS, в основном проблем не возникнет. Но если вы используете хостинг с Linux/Unix, то могут возникнуть сложности, так как системы чувствительны к регистру, и поэтому адрес kolyaswhisky.com/AbC будет отличаться от kolyaswhisky.com/aBc. Это нехорошо.

В идеале вам нужно, чтобы URL с неправильным регистром автоматически перенаправлялся/канонизировался на правильный. Здесь помогут протоколы переименования htaccess.  Например, такой:

RewriteEngine On
RewriteBase /

RewriteRule [A-Z] - [E=HASCAPS:TRUE,S=1]

RewriteRule ![A-Z] - [S=28]

RewriteRule ^([^A]*)A(.*)$ $1a$2
RewriteRule ^([^B]*)B(.*)$ $1b$2
RewriteRule ^([^C]*)C(.*)$ $1c$2
RewriteRule ^([^D]*)D(.*)$ $1d$2
RewriteRule ^([^E]*)E(.*)$ $1e$2
RewriteRule ^([^F]*)F(.*)$ $1f$2
RewriteRule ^([^G]*)G(.*)$ $1g$2
RewriteRule ^([^H]*)H(.*)$ $1h$2
RewriteRule ^([^I]*)I(.*)$ $1i$2
RewriteRule ^([^J]*)J(.*)$ $1j$2
RewriteRule ^([^K]*)K(.*)$ $1k$2
RewriteRule ^([^L]*)L(.*)$ $1l$2
RewriteRule ^([^M]*)M(.*)$ $1m$2
RewriteRule ^([^N]*)N(.*)$ $1n$2
RewriteRule ^([^O]*)O(.*)$ $1o$2
RewriteRule ^([^P]*)P(.*)$ $1p$2
RewriteRule ^([^Q]*)Q(.*)$ $1q$2
RewriteRule ^([^R]*)R(.*)$ $1r$2
RewriteRule ^([^S]*)S(.*)$ $1s$2
RewriteRule ^([^T]*)T(.*)$ $1t$2
RewriteRule ^([^U]*)U(.*)$ $1u$2
RewriteRule ^([^V]*)V(.*)$ $1v$2
RewriteRule ^([^W]*)W(.*)$ $1w$2
RewriteRule ^([^X]*)X(.*)$ $1x$2
RewriteRule ^([^Y]*)Y(.*)$ $1y$2
RewriteRule ^([^Z]*)Z(.*)$ $1z$2

RewriteRule [A-Z] - [N]

RewriteCond %{ENV:HASCAPS} TRUE
RewriteRule ^/?(.*) /$1 [R=301,L]

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

#14: Используйте дефисы и подчеркивания для разделения слов

Ранее я рекомендовал не использовать подчеркивания для разделения слов в URL. Но за последние несколько лет поисковые системы успешно преодолели прошлые трудности с этим разделителем, и теперь рассматривают подчеркивания наравне с дефисами.

Пробелы тоже работают, но в адресе вместо них автоматически подставляется сочетание «%20», что выглядит грубо и снижает читабельность. Постарайтесь избегать их (это довольно легко сделать в современных CMS).

#15: Не захламляйте сайт ключевыми словами и повторениями, так как это не имеет смысла

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

Такие повторения не способствуют вашему поисковому ранжированию. Google и Bing уже отошли от алгоритмов, которые положительно воспринимали появление нескольких ключевых слов в строке URL. Не теряйте свои шансы заработать клик (который МОЖЕТ повлиять на ранжирование), используя много ключевых слов и повторений в URL.

Климович Николай
Климович Николай

Климович Николай

SEO-эксперт, интернет-маркетолог, психолог, предприниматель. Является партнером проекта GoGetLinks (направление: услуги поисковой оптимизации). Основатель проектов Apose и Rooota. Работает в сфере интернет-бизнеса с 2009 года. Постоянный спикер на конференциях посвященных интернет-бизнесу и поисковым системам.

Добавить комментарий

Ваш e-mail не будет опубликован.