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

И главное
На кой черт все это надо.  

Стандарту уже 6 лет. При этом, Google стал причиной форка стандарта с которым мы сейчас и имеем дело. То есть формально стандартизировать такие процессы может только группа W3. Но ее медлительность, и академичность, то есть оторванность от реальных задач привела к конфликту между ними и крупными игроками рынка. В результате чего и появилась группа whtwg. Стандартом которой мы и пользуемся.

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

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

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

все секционные теги: section article aside nav

Вложенность секций, то есть иерархия определяется ей, а не весом заголовка h1-h6. Цифра у заголовка не имеет никакого значения для определения значимости.

!!! Секционные руты: blockquote td figure fieldset

Группы: hgroup header footer  p address ol ul dl(только в части термин - занчение)  legend datail

Таблицы: table caption thead tfoot tr td th
но это все работало и раньше.

Формы: label button, legend, плейсхолдеры

Фразовый контент: a img strong b u mark small time cite
тут все намного сложнее. Потому что судя по всему менялось не то что учитывается или не учитывается, а то как учитывается.

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

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

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

Сам по себе h1 безусловно не является header. Теги H* это особая часть контента называемая заголвочный контент. У нее своя роль. Именно поэтому  нельзя сделать в одной секции два заголовка. Это пирведет к неявному созданию новых секций, вплоть до вываливания контента из одной секции в другую, даже уровнем выше.

Я правильно понял, что если внутри одной секции два h, то гугол сам разбивает ее на 2 секции с одним заголовком у каждой?

И там получается по умолчанию связь И?

Demi, молодёжь она разная, и используется стек вообще разный, если в процентном соотношении то реакт все считают модным, молодёжным решением. Встречаю кучу 20 летних разработчиков которые мечтают работать с react) Раньше разработчик оканчивал институт и хотел работать к примеру с python или c#, сейчас react и js) Никто не  хочет работать с чем то серьёзным, напрягаться и тп, все хотят по быстрому освоить реакт и работать на нём, как по мне так и сам js, это не особо серьёзная история)

всем привет! #вопрос. скинули файл key collector с семантикой, но у меня файл открывается пустым, хотя он сто процентов не пустой. кто-то сталкивался с такой ситуацией?

1) Согласно стандарту да. Это разбиватеся на две секции. И тут как раз важен вес заголовка для разрешени конфликтной ситуации - какой секцию делать.

2) Как поступает гугл, сказать может точно только сам гугл. НО, очевидно что если раньше гугл парсил html4 и выделял разделы опираясь на заголовки, то так или иначе он уже создавал логические секции, которые ничем не отличаются от html5 секций. Разве что менее гибкие. А учитывая факт игнорирования веса заголовка, это подвержадется почти на 100%.

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

Разные версии коллектора?

По факту можно статью в WP оборачивать в <article>, а внутри уже не дробить на секции? Внутреннюю структуру статьи строить через Н2-Н3? Гугл поймёт что это всё неявные секции и выстроит правильную иерархию?

Короче в частных случаях можно и Н2-Н3 обойтись

Структуру документа в HTML5 удобно в инструменте https://www.sitegardien.com/html5viewer/semantichtml5viewer.php смотреть. Кстати у backlinko размечен сайт (на WP)  в HTML5 н/п https://backlinko.com/content-marketing-tips @demimurych как тебе его верстка?

Можно. Стандарт предполагает строгий алгоритм повдения в этом случае. Что в какую секцию попадает.
И даже можно продумать схему чтобы ничего не вывалилоось никуда. То есть общий шаблон сделать таким образом чтобы сама статтья всегда оказывалась изолированной.

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

Структуру документа в HTML5 удобно в инструменте https://www.sitegardien.com/html5viewer/semantichtml5viewer.php смотреть. Кстати у backlinko размечен сайт (на WP)  в HTML5 н/п https://backlinko.com/content-marketing-tips @demimurych как тебе его верстка?

Я просто делаю сайты только на WP и поэтому на ходу соображаю как проще реализовать секционную вёрстку внутри поста. Если там тупо внутри писать теги <section> то их может "съесть" сам WP при обновлении поста. Да есть уже блочная вёрстка гутенберга, но по-моему она больше для оформления а не семантики. Поэтому открытый вопрос ,как это верстать на WP с наименьшими усилиями. В голову пока приходят шорткоды... Либо что-то кастомное пилить