Там про,
что в общем и среднем я не считаю обязательным требованием.
p.s. Формально это требование можно реализовать, сделав полную текстовую карту сайта и разместить на неё ссылку в подвале.
Зависит от сложности. В больших и сложных структурах конечно не все, их может быть многие сотни и даже тысячи.
Вот это ключевая оговорка, потому что нч и микро нч категории могут формировать бОльший объём url-ов.
Про что конкретно спрашивают, цитата,
-
НО главная в этой конструкции страница "стеллажи с ящиками" уже не в 2-3 шагах от главной, что, если верить рекомендациям в сети, уже не правильно.
про то и отвечаю.
Нет.
Объём структуры может быть гораздо шире, чем содержание меню.
Я не говорил, что меню не устраивает.
Если толково продумать, то вопрос решается и штатными решениями "нормальных ИМ" и доп. внедрениями.
Совершенно верно.
В общем, ничего подозрительного. TC ищет стажёра-рутинщика на мизерную "студенческую" з/п.
Как правило это резонно только на вырост, чтобы через пол года активности расти в квалификации и стоимости труда.
Если этого не происходит:
(Стажёр косячит и бездельничает) - с ним прекращают сотрудничество и ищут нового (и так по кругу).
(Стажёр вырос и чувствует силы для более сложных задач, а TC так не считает) - сотрудник трудоустраивается в другом месте.
Cтруктурная URL вложенность не равна навигационной пользовательской вложенности.
Если сайт реально большой и в нём сложная многоуровневая URL реализация, то тот же кластер "Стеллажи с ящиками", который может быть на 4 или 5-ом уровне URL вложенности, вы можете вынести на Главную в виде анонса и тогда он будет в одном клике от Главной. Будет вам соответствие рекомендациям :)
p.s. В таком случае лучше создавать mind карту и фиксировать рабочие решения. Это и есть этап структурного проектирования, где решается какая будет URL вложенность и как распределить рабочие выводы, чтобы ключевые товарные группы находились в 2-3 шагах от Главной.
C чего вы решили?
Вопрос в том, как вы сделали сайт, насколько он полезен и как вы с ним работаете.
Значит эффективная полезность сайта и ваших стараний соответствует указанному результату.
ПС не гарантируют трафик любому созданному сайту. Надо разбираться в деталях.
Ох уж эти "найти определённые картинки".
Определённые чем? ТЗ? Озвучьте ТЗ, тогда будет конкретика.
А так - общие выводы на общение указания.
p.s. Найти не проблема, проблема изготовить/подготовить материал для легального бизнес использования.
Нет, конкретного универсального численного барьера после которого к сайту начнут "прилепать" проблемы.
Для какого-то сайта - несколько десятков, для какого-то сайта несколько сотен и т.д.
Вас никто не предупредит о том, что хватит, сайт просто начинает теряет поисковую видимость, хуже индексироваться и потом вы теряете ликвидность для продажи ссылок.
Алгоритмы реализованы так, чтобы очевидные проблемы выявлялись, когда уже поздно.
Так или иначе не надо называть Сергея "сущностью" - это оскорбление. Ещё совсем не так давно ты тоже меня не шибко жаловал, но как только буквально позавчера удалось сменить тональность разговора, вектор переменился и во взаимном диалоге появилось много ценных и полезных рабочих мыслей.
Думаю, вполне достаточно было бы указать на неточность формулировки без эмоционального наката.
Я думаю нам всем ещё предстоит поработать над тактичность и сетевым этикетом.
Уверен, и ты, и я, и Сергей (и многие остальные) при определённом состоянии можем быть вполне адекватными и культурными людьми, я думаю не стоит лишний раз доводить до состояния, когда мы начинаем демонстрировать не лучшие свои стороны 😉
Странность в указании этой технологической избыточности и том, что в контексте эта пара слов -> REST API указывает на архитектурный стиль.
Т.е. терминологически это неверно и Sly32 на это ревностно указал, хотя мог бы указать в другой тональности и тут конечно взаимная тональность накручивает негатив.
Я бы например не прицепился к твоему первоначальному посту (я и не программист, не мне отстаивать корректность), но когда тут возникало твоё ответное упорство, всё-таки, имеет смысл расставить точки над и.
Приведет аналогию, почему я тоже это вижу странным. Допустим, говоря о кластеризации, я каждый раз к слову кластеризация буду добавлять soft/мiddle/hard, указывая на вариации принципа объединения url-ов по результатам в serp-е. И так каждый раз :)
Для указания доступности выбранных параметров - это уместно, указав конкретный один вариант, а вот для указания, например, проведённой работы, например,
..
4. Выполнена soft/мiddle/hard кластеризация
это избыточно и не нужно, потому как в указанном виде soft/мiddle/hard кластеризация указывает на принцип и доступные способы кластеризации, но не на рабочий акт.
Поэтому, когда Sly32 указывает,
Я с ним согласен. И в своей работе тоже не слышал, чтобы программисты в команде так писали в описании рабочих задач, поэтому в каких вопросах определённо не помешает Sly32 прислушаться к нам, а в таких вопросах - к нему.
Но на самом деле это не повод, чтобы ругаться.
