Антоний Казанский

Видимо благодаря перестановке слов :))))) Это товарищу из Сочи надо задать вопрос - достаточно ли усердно от отслеживает конкурентныe тайтлы и сразу многократно исправляет свои, чтобы не приведи случай их дублировать :)

Верно. Кто давно и упорно работает с текстовой оптимизацией знает, что стараться натянуть все частотные запросы из СЯ на тайтл не нужно, запросы нужно грамотно распределять по всей структуре H заголовков, отдельных фраз и цитат. 

Уже нередки случаи когда Гугл в поисковой выдаче может подменять title более релеватной фразой из тела документа.

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

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

Делайте просто и понятно. Если уложитесь в 70 символов, то SE сервисы не будут сигнализировать, что у вас слишком длинный Title :)

Никакого значения это для поисковых систем не имеет.

Не нужно громоздить все эти длинные конструкции. 

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

О, Господи :) Секта непримиримых ревнителей уникального тайтла? :)

Вы же не первый год на форуме, неужели серьёзно считаете, что тайтл должен быть строго уникальным? :)

Да, по-моему, года назад или больше мы с тобой обсуждали эту тему.

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

В больших разветвлённых проектах все эти задачи решают вместе.

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

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

Тогда вы противоречиво иллюстрируете свою мысль здесь:

Здесь у вас Теги - дочерний элемент родительского уровня Категория.

А вот как раз нет. В своём изложении вы пытаетесь представить структуру то через тег, то через категорию; предлагаете то одну вложенность для обсуждения, то другую. О чём это говорит?

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

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

Вот! Поэтому определяя типовые схемы карт пользователя вы должны понимать, где сосредотачивается ваше ядро по точкам входа на сайт и какое дальнейшее распределение  по нему происходит.

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

Да, пожалуйста..

Так, смотрите, вырисовывается следующее:

Звуковые эффекты -> Собаки -> Звуки собак

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

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

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

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

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

Теги являющиеся подуровнями родительской категории можно собирать по общему семантическому признаку, допустим, Собака -> Лай собаки, а теги, которые частичное семантическое совпадение, ну, допустим,

Так вот, к какой категории отнести данный фрагмент? Явно не к собакам, потому что одиночный лай в конце фрагмента - явно не центральная тема. Вы отнесете этот фрагмент к категории "Звуки города". Но расширив ваши информационные задачи вы можете решить, что этот одиночный лай может быть полезен для категории "Лай собаки" и используете как раз тег "звуки города + собачий лай". В этом случае данный тег уже нелогично делать подкатегорией "Лай собаки" и он может быть самостоятельным тегом вне общей структуры, а может быть и прикреплен как родительский элемент категории Звуки города.

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

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

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

И вы сами в этом убедились..

Поможет в борьбе с DOS атаками. А диапазоны ненужных IP можно действительно банить самостоятельно.

Ваша правда. 

P.s. Мне очень понравился пост. Живой, эмоциональный - самый нерв проблемы. 

А то тут любят советовать Cloudflare для борьбы с ботами, а на самом деле он общую проблему не решает.