Правда о совершенных SEO URL

1. URL и SEO - Основы
2. Должен ли я действительно изменить свою структуру URL?
3. Динамические URL
4. Неструктурированные URL
5. Длинные URL
6. Ключевое слово Фарш
7. Ключевое слово каннибализация
8. Резюме: SEO URL - лучшие практики

Далее следует гостевая статья Паскаля Ландау
(кто заранее извиняется за промежуток времени ..)

Тема «SEO и URL-адреса» является типичным многолетним фаворитом и поднимается в различных вопросах: «Как долго может быть URL-адрес?», «Имеет ли значение количество каталогов?», «Где должны быть мои ключевые слова?» И т. Д. На SEOMoz сегодня очень красивая и подробная статья под названием Должен ли я изменить свои URL для SEO? появился. Это отвечает не только на вопрос в названии, но также и на других распространенных ошибках и проясняется с некоторыми предрассудками - достаточная причина, чтобы разобрать часть на немецком 😉

URL и SEO - Основы

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

Должен ли я действительно изменить свою структуру URL?

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

Динамические URL

Динамические URL-адреса - это URL-адреса, содержимое страницы которых контролируется параметрами. Они обозначены знаком вопроса после пути. Пример WordPress можно увидеть, если вы не адаптируете структуру PermaLink в новой установке. URL-адреса тогда, например,
http://www.example.com/?p=1417 или слишком
http://www.example.com/?p=1417&category=5 .
Проблемы с этим:

• Ключевое слово не включено в URL (плохо для SEO и юзабилити)
• URL-адреса обычно становятся излишне длинными (хотя бы потому, что параметры всегда состоят из пар & key = value, а ключ является избыточным)
• Они более склонны к созданию дублированного контента

Конечно, два приведенных выше случая являются крайними, и это явно рекомендация перейти на говорящие URL-адреса. Но есть и примеры, в которых параметры не так плохо реализованы. пример:
http://www.example.com/blog/?t=perfekte-urls
Здесь также управление контентом осуществляется через параметры, так что существует динамический URL. Лучшим вариантом будет http://www.example.com/blog/perfekte-urls/, а с совершенно новой страницей вы также выберете URL. На старой установленной странице с более чем 1000 страницами в индексе, вероятно, нет, потому что улучшение, во всяком случае, должно быть минимальным.
Итог: что делать с динамическими URL?
Я лично изменил бы структуру, если бы было включено более одного параметра или если этот один параметр не представляет ключевые слова страницы . Для больших страниц я бы сделал это только в том случае, если текущая структура демонстрирует существенные недостатки в рейтинге , например, потому что в значительной степени все остальные факторы оптимизированы так же, как в соревновании, но длинный хвост все еще не работает.

Неструктурированные URL

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

• http://www.example.com/tisch/
• http://www.example.com/stuhl/
• http://www.example.com/hocker/

об изменении в

• http://www.example.com/moebel/tisch/
• http://www.example.com/moebel/stuhl/
• http://www.example.com/moebel/hocker/

думаю. Д-р Пит утверждает, что последние упомянутые URL говорят больше о содержании и, следовательно, могут быть предпочтительными (как пользователем, так и поисковой системой). С другой стороны, фактическое ключевое слово продолжает давить. Кроме того, вторая структура естественна для Проблемы с дублированным содержимым из-за граненой навигации уязвима. Однако я не вижу каких-либо ощутимых преимуществ или недостатков.
Кстати: чистая глубина каталога не является аргументом! Через такие методы, как mod_rewrite Можно смоделировать любое количество каталогов, поэтому нет недостатка. Для поисковых систем путь ссылки , то есть расстояние (то есть количество ссылок, которые пользователь должен щелкнуть), считается до нижней части главной страницы. Это может быть отражено в структуре URL, но это далеко не обязательно!
Мое личное мнение по этой проблеме - выбор второго решения. Это просто вопрос последовательности для меня, чтобы структурировать свой контент таким образом, чтобы эта структура была представлена ​​как в URL, так и в глубине ссылок. Но: это определенно не тот критерий, который я бы написал мелом на странице.
Итог: что делать с неструктурированными URL?
Чистая структура URL не является критерием, в котором стоит попытаться оптимизировать. Здесь я бы ничего не изменил, но позаботился о том, чтобы структуры ссылок были соответственно скорректированы.

Длинные URL

То же относится и к URL-адресам, и к заголовкам: как можно дольше и как можно короче. Хитрость заключается в том, чтобы найти правильную длину. Я не знаю какой-либо «оптимальной» длины для URL, но URL во фрагменте усекается после определенного количества символов. К сожалению, никакой конкретной информации нет , потому что она варьируется с одной стороны (я думаю, что Google уделяет здесь внимание частично разделителям, поэтому слова в середине не обрезаются, а также как «промежуточные каталоги» по / ... / ) и по другим хлебным крошкам отображается там, где URL не отображается напрямую (пример: http://www.google.de/search?hl=de&q=inurl:myseosolution.de/seo-tutorial/ ).

Длина отображаемого URL во фрагменте варьируется

Общие аргументы против длинных URL:

• Чем больше слов в URL, тем меньше вес каждого
• Длинные URL выглядят глупо в браузере и их трудно запомнить (удобство использования ...)
• Может вызвать проблемы с копированием и вставкой
• Некоторые приложения для социальных сетей имеют проблемы с слишком длинными URL

Проблема сама по себе играет в ранее обсужденной структуре URL, потому что каждый каталог «удлиняет» URL. Часто возникают проблемы с избыточностью , например, в следующем примере:
http://www.example.com/hamburg/mietwagen-hamburg-in-hamburg-mieten/
Тем не менее, этот пример довольно интересный, потому что, как бы вы решили проблему (целевое ключевое слово: "аренда автомобиля Гамбург")?

1. http://www.example.com/hamburg/mietwagen/
2. http://www.example.com/mietwagen-hamburg/
3. http://www.example.com/hamburg/mietwagen-hamburg/

Д-р Пит предпочел бы вариант 1, я бы предпочел вариант 3. Я все еще могу потерять сознание от разговора Художник и SEO Мартин Миссфельдт Вспомните SEMSEO на разогреве, в котором рассказывалось о важности дорожки для картин. И если я правильно помню, «/rosen/rot.jpg» явно был в невыгодном положении по сравнению с «/rosen-rot.jpg». Насколько это может быть перенесено на «нормальные» URL-адреса, я точно не знаю, но имя файла или последний каталог URL-адреса имеют определенную специальную позицию (как я уже говорил, промежуточные каталоги находятся в фрагменте частично с / ... / сокращенно).
Я определенно рекомендую пропустить слова-заполнители в URL:
Вместо http://www.example.com/hamburg/experience-report-to-a-Opel-Insignia/
скорее http://www.example.com/hamburg/Erfahrungsbericht-Opel-Insignia/ .
Итог: что делать с длинными URL?
Чистая длина URL-адреса не является критерием, в котором стоит попытаться оптимизировать. Однако при использовании новых URL-адресов я бы осторожно удалил слова из слов и сосредоточился на основных ключевых словах.

Ключевое слово Фарш

Здесь особо нечего сказать. Заполнение ключевыми словами - это ненужное повторение ключевых слов для манипулирования поисковыми системами. Устаревшее, не стоит и не должно быть сделано. Если это в настоящее время относится к вам, и вещь «работает», то ничто не изменит существующие URL, но оставьте это на новом. Если у вас, как правило, плохой рейтинг, это станет отправной точкой для исследования первопричин 😉
Пример: http://www.example.com/hamburg/mietwagen-hamburg-in-hamburg-mieten-günstig-mietwagen-mieten/
Лучше: http://www.example.com/hamburg/mietwagen/ или http://www.example.com/hamburg/mietwagen-hamburg/

Ключевое слово каннибализация

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

Резюме: SEO URL - лучшие практики

Самое важное сообщение в этой статье со слегка озадаченным названием «Правда о совершенных SEO-URL» - не предпринимать поспешных шагов в отношении оптимизации URL-адресов. Хотя URL-адреса не являются на 100% совершенными на существующих страницах, скорее всего, ожидаемые улучшения не оправдывают риск изменения структуры URL-адресов. Однако с новыми проектами, а также с новыми добавленными URL-адресами с существующими сторонами следует, конечно, с самого начала делать все правильно.
К таким «мини-улучшениям», изменение которых не стоит, я считаю, например:

Расширение файла URL Полностью независимо от того, является ли html, php или просто a / _ (Underscore) в качестве разделителя Конечно, вы не должны этого делать, но Google признает, что это в значительной степени все еще шумит слова в URL. Не оптимально, но определенно не большая просадка. Неструктурированные URL Субдомен или подпапка Если ссылка на странице остается прежней, это не имеет значения, а субдомены усложняют администрирование

Я не могу придумать больше мини-улучшений, пожалуйста, добавьте их в комментариях 😉 Конечно, в целом: война мой Первая статья здесь, дайте мне знать, что вы думаете!

Похожие

Комментарии