Сайтостроение

15 советов по созданию URL от Рэнда Фишкина (Часть 2)

В прошлой статье вы могли перечитать перевод первой части статьи Рэнда Фишкина о структурировании URL адресов с точки зрения поисковой оптимизации. Сегодня мы продолжим этот список:

№7: Постарайтесь, чтобы URL соответствовал заголовку статьи (когда в этом есть смысл)

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

domen.com/7-бутылок-моего-любимого-виски-айла

Или так:

domen.com/blog/любимые-7-бутылок-виски-айла

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

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

На скриншоте выше вы можете увидеть, как я анонсировал две статьи в Facebook. В первом примере совершенно не ясно, куда вы попадете при переходе по ссылке. Единственное, что можно узнать из адреса– то, что это новостной раздел на сайте BBC. Пояснение также весьма расплывчатое. Во втором примере журнал PacificStandard создал такой URL-адрес, которые дает четкое представление о содержании статьи, поскольку почти полностью повторяет ее заголовок.

№8: Необязательно использовать стоп-слова

Если в заголовке статьи есть так называемые стоп-слова (предлоги, местоимения, союзы, которые игнорируются поисковиками для снижения объема индекса), совсем не обязательно вставлять их в URL-адрес. Конечно, если хотите, можете их оставить, но зачастую, удалив их, вы делаете URL короче и легче для восприятия. Опять же – решать вам.

№9: Удалите/урежьте количество используемых пунктуационных знаков

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

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

№10: Сократите количество редиректов до двух и менее.

Если пользователь или краулер запрашивает страницу с адресом URL A, а попадает на страницу URL B, в этом нет ничего плохого. Всё хорошо, даже если URL В перенаправляет его на страницу URL C. (не идеально, конечно. Можно было бы сделать прямой редирект с А на С. Но не критично). Если же цепочка из редиректов состоит из более, чем 2х звеньев, у вас могут быть проблемы.

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

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

№11: Чем меньше фолдеров, тем лучше

Рассмотрим URL вроде этого:

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

А теперь вот такой:

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

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

В отношении большого количества фолдеров так же нет жестких требований, так что опять же – решать вам.

№12: Избегайте использовать хэш символы в URL для создания отдельно взятого/уникального контента

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

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

№13: Будьте осторожны с регистром

Пару лет назад Джон Шэррод из Search Discovery написал прекрасную статью о том, какие проблемы возникают у тех, кто не обращает внимание на чувствительность регистров в URL-адресах. Конечно, если вы используете Microsoft/IIS сервера – тут всё просто. Но когда речь идет о серверах Linux/UNIX, у вас могут возникнуть проблемы, т.к. они распознают разные регистры, и  domen.com/AbC приведет вас на совершенно другую страницу, нежели domen.com/aBc.

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

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

Впервые за несколько лет я не буду советовать вам избегать подчеркивания для разделения слов. Поисковикам всё-таки удалось решить эту проблему, и они могут читать как дефисы, так и подчеркивания.

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

№15: Не нужно постоянно повторять ключевые слова. Иначе сайт будет похож на спамерский.

Посмотрите на следующий пример. Видите? Несколько раз повторяется фраза «canoe puppies». Выглядит подозрительно и, скорее всего, отпугнет посетителя.

Повторение ключевых слов не поможет вам с ранжированием. Google и Bing доработали свои алгоритмы, так что они не клюют на ключевые слова, несколько раз повторяющиеся в URL. Скорее, наоборот, вы можете себе этим навредить.

RU/KZ