Структурирование

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

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

Содержание

Релевантность

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

Естественно, что этот шаблон ранжирования по релевантности распространяется не только на связи между документами, но и на всю структуру категорий веб-сайта. Создатели сайтов могут использовать этот факт — нужно строить иерархии, которые идут от широкой темы до более специфичного контента. Очевидно, что в любой системе категоризации есть некая доля субъективности. Не зацикливайтесь на совершенствовании того, что хотят видеть поисковые движки. Вместо этого думайте сначала о ваших посетителях и используйте эти указания только для того, чтобы ваша креативность не перегрузила проект.

Таксономия

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

Основные элементы таксономии

Иерархические таксономии — имеют древовидную структуру (родительские и дочерние элементы). Классический пример — рубрики или категории (например: Игрушки -> квдрокоптер -> дрон).
Плоские (линейные) таксономии — не имеют вложенности, элементы равны друг другу. Классический пример — теги (метки) или ключевые слова, описывающие конкретную сторону материала.

Примеры в веб-разработке (на примере WordPress)

В популярных CMS (например, WordPress) таксономия — это встроенный инструмент группировки записей:

Стандартные категории (category)
Стандартные метки (post_tag)
Пользовательские таксономии (например, «Цвет», «Бренд» или «Размер» для интернет-магазина).

Онтология

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

Зачем нужна онтология на сайте

Понятная структура для поиска и фильтров: Помогает связывать товары, услуги или статьи по смыслу, а не просто по папкам (например, понимает, что центровочные пластины — это вид систем центрирования, а пластины — это элемент такой системы или инструмент).
Улучшение работы ИИ и чат-ботов: Дает языковым моделям точный контекст, снижая количество галлюцинаций (бот оперирует фактами из карты связей, а не додумывает).
Продвижение (SEO) и семантические сети: Помогает поисковым системам (например, через микроразметку RDF/OWL) лучше понять, о чем ваш сайт, и показывать расширенные сниппеты.
Интеграция данных:Позволяет объединять информацию из разных баз данных сайта в единую смысловую систему.

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

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

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

Архитектура сайта

Плоская и глубокая

Одно из самых строгих правил оптимизации под поисковые системы — это создание плоской архитектуры сайта. Плоские сайты требуют минимального количества «кликов» для достижения любой заданной страницы. Глубокие же сайты создают длинные маршруты ссылок, требующихся для доступа к контенту. Почти для любого сайта размером менее 10 тыс. страниц весь контент должен быть доступен максимум за три «клика» от начальной страницы (или страницы с картой сайта). При наличии 100 ссылок на странице даже сайты с миллионами страниц могут дать доступ к любой странице максимум за пять или шесть «кликов» — если применяются правильные структуры ссылок и навигации. Если сайт создан не плоским, то для достижения нужного контента может понадобиться слишком много «кликов». В отличие от него, плоский сайт позволяет пользователям и поисковым движкам достичь большей части контента всего несколькими «кликами».

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

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

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

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

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

Решение при этом упомянутых ранее проблем разбиения зависит от контента веб-сайта. Далее представлены некоторые возможности с примерами.

Воспользуйтесь атрибутами rel=»next» и rel=»prev». Преимущество использования этих элементов состоит в том, что они позволяют Google узнать последовательность страниц. Если Google видит эти атрибуты, то ссылки на все страницы будут обрабатываться как ссылки на всю последовательность страниц. Кроме того, Google покажет в индексе самую релевантную страницу из последовательности (чаще всего это будет первая страница — но не всегда).

Информируя Google о структуре разбиения на страницы, эти атрибуты могут использоваться независимо от присутствия страницы view-all (о ней — чуть позже). В приведенном далее примере показано, как использовать атрибуты rel=»next» и rel=»prev» для разбитого на 12 страниц контента.

В разделе head первой страницы вашего разбитого на страницы контента поставьте атрибут rel=»next», указывающий на вторую страницу контента. Код должен выглядеть примерно так: <link rel=»next» href=»http://www.вашсайт.com/products?prod=qwert&p=2″ />

В разделе head последней страницы вашего разбитого на страницы контента поставьте атрибут rel=»prev», указывающий на вторую от конца страницу контента. Код должен выглядеть примерно так: <link rel=»prev» href=»http://www.вашсайт.com/products?prod=qwert&p=11″ />

В разделе head страниц 2-11 установите атрибуты rel=»next» и rel=»prev», указывающие соответственно на последующие и предыдущие страницы. Вот пример кода соответствующих атрибутов для шестой страницы:

Кстати, в 2012 году поддержку атрибутов rel=»next» и rel=»prev» объявил и Bing (bit.ly/paginated_and_sequenced).

Создайте страницу view-all и используйте канонический атрибут. Наличие на сайте длинных статей, разбитых на несколько страниц, ведет к тому, что якорный текст в ссылках на эти страницы содержит 1, 2 и т. д. Названия самих страниц могут отличаться весьма незначительно, и поэтому они будут конкурировать друг с другом за поисковый трафик. И если кто-то разместит ссылку на эту статью, но не на первую ее страницу, то «сок» этой ссылки будет в значительной степени потрачен впустую.

Чтобы справиться с такой проблемой, можно сохранить версию статьи с разбиением на страницы, но создать также и ее версию на одной странице — она и будет страницей view-all. Затем нужно воспользоваться атрибутом rel=»canonical» (более подробно он обсуждается далее), чтобы указать со страниц статьи на страницу view-all. Это позволит сосредоточить весь «сок ссылок» и внимание поисковых движков на одной странице. Следует также сделать ссылки на страницу view-all со всех страниц статьи. Однако если страница view-all загружается слишком медленно (из-за своего размера), то это, возможно, не лучший вариант.

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