В общем, ничего подозрительного. 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 прислушаться к нам, а в таких вопросах - к нему.
Но на самом деле это не повод, чтобы ругаться.
Начните с разбора, что я писал и о чём я не писал.
Я не писал про необходимость замены, я опровергал этот тезис.
Не по адресу.
Это если хотите без простыней.
Конкретно и коротко, ещё раз цитирую,
--
для саунд-дизайна (и рекламной продукции) AI-шка конечно будет активно применяться.
Пожалуйста.
Я не против 😊
Здесь простынь была длинней, чем обычно, но special for you, потому что ты поймешь эти нюансировки, для большинства это конечно не нужно.
Согласен, в этом смысле я азартен и "горю любимым делом" 😎 простите..
Вопрос хороший, и не редкий. Попробуем разобраться, надеюсь остальные коллеги тоже поделятся своим опытом.
(открывая шкаф, доставая свежую простынку) - Обратимся к практике.
Бизнес практика показывает, что такого запроса и такой задачи (оценить влияние изменённой структуры на сайт) у бизнеса нет. Такая задача как подряд может возникать между SEO специалистами, между собственником (который пытается разобраться в SEO) и SEO специалистом, но только как отдельный рабочий эпизод.
В чём специфика. Бизнес не приходит к SEO за разовой работой (варианты услуги линк билдинга и отдельных задач относится к вышеуказанным эпизодам делегирования).
Бизнесу нужен поисковый трафик, увеличение продаж, прибыль, поэтому вопрос нужно рассматривать именно в этом аспекте. Кейсы реализуются в логике - вот что было, и вот что стало с нашими N-цать внедрениями (среди которых и реализация структуры).
Поэтому отвечая на твой вопрос,
таких кейсов, что SEO специалист взялся исправлять только структуру, а всё оставил так как было в общем не бывает.
Т.е. сложно представить себе ситуацию, где всё идеально, и всё продумано и реализовано, но вот структура - беда.
Задача кейса - продемонстрировать комплексную работу, потому что кейсы демонстируют как мы умеем и как после нашей работы бизнесу становится хорошо.
Кейсы не создаются для того, чтобы выполнить одну работу, а всё остальное - проигнорировать только потому, что такой вопрос возникает на Серче и нужно провести чистый эксперимент.
Следовательно, в бизнес контексте практически невозможно себе представить ситуацию, где взятый в работу сайт, будет модернизироваться по структуре и всё. А потом будут производиться замеры реализации структуры. Всё необходимые задачи внедряются поступательно и тут всегда вместе и структура, и on page оптимизация, и копирайтинг, и маркетинговые внедрения, и UX/UI решения и дизайнерские дополнения.
Бизнесу нужно всё в комплексе, желательно быстро и за разумные деньги. Для него структура - частности.
Поэтому даже если мы сейчас пойдем искать кейсы, где будет речь про структурную модернизацию (и это прям бизнес кейс, а не просто описание решения), то там будет всё вместе.
Это что касается практической стороны seo в коммерческих задачах.
В любительской нише могут встречаться мнения, что отдельны вебмастер сначала наполнить сайт так (как получилось на WP с дефолтными настройками), а потом ему подсказали, что структуру можно улучшить, он нанял программиста (или исправил сам), но для его сайта на 15 страниц ничего не изменилось. В его картине мира структура не роляет.
Для меня полезность ЧПУ и структурной модернизации очевидна (и кроме того о чём пишут в справочниках) помогает:
- Быстрее сформировать навигационные цепочки в серпе
- Быстрее сформировать Быстрее ссылки
- Однозначно определить правила url адресации, логику вложенности, правила нотирования и канонизации
- Получить более удобное представление структуры в Вебмастере, где покластерно выводится объём индексации
- Получить более гибкие условия для пост аналитики кластеров, мониторинга запросов, используя регулярки для составления нужные фильтры (и атрибуции), например,
Кто знает как, зачем и какие задачи это решает, тот от приведения структуры к нужному виду не откажется.
Приведем житейскую всем понятную аналогию.
Ребенок приходит в секцию (допустим его приводят родители) в спортивные секцию, в зал. Ребенок условно, ничего про спортивные занятие в зале не знает и о спорте в общем не имеет ясного представления (мал ещё).
Ему рассказывают, что нужна спортивная форма, допустим, не штаны (а в зависимости от спортивной дисциплины) - шоры, не ботинки или кроссовки, а кеды или боксёрки, не рубашка, а футболка, и не синтетика, а х/б и прочие, прочие детали, которые ребенок воспринимает как правила, но полезную функциональность понимает только с возрастом.
Всё это совсем-совсем базовые и фундаментальные вещи, на которых строится всё остальное. Можно ли ими частично пренебрегать? Формально - можно (если в каких-то обстоятельствах можно) и достигать своих результатов.
Также и со структурой. Структура - фундамент, на которой всё базируется и развивается, где нужно решить все ключевые базовые элементы и не создавать условия (вольно или невольно), для противоречий и конфликтов.
Почему я привожу эту аналогию, потому что проф. спортсмену не нужно рассказывать про спортивную форму, он её использует без напоминаний и понимает, что кроссовки нельзя, потому что велик риск подвернуть ногу, шорты, потому что они дают идеальную мобильность и лёгкость при высокоинтенсивных нагрузках и т.д.
SEO-шник, когда ему предлагает сайт на модернизацию в любому случай будет поднимать вопрос структурной модернизации (если этот вопрос не решался и в структуре сайта бардак), потому что это создаёт необходимые условия для оптимальной работы.
Надеюсь ответил на вопрос.
p.s. В общем и целом полезность структуры наглядна и очевидна именно на больших сайтах. На маленьких, где заметных изменений нет и не будет, реструктуризация нескольких страниц скорее всего не даст никакой полезности.
