DemiMurych
H1 обобщает только ее текстовую часть.
Это прекрасно. Такое я вижу впервые. Вы подняли мне натсроение на день вперед.
Потому простите, но я не смог пройти мимо, несмотря на все попытки людей обьяснить мне почему это бесполезно.
О заголовках и title
h1 - h6 это набор заголовков стандарта HTML4 где семантические связи между блоками контента выстраивались за счет иерархии этих заголовков. Строго говоря парадокс html4 заключается в том, что формально не может быть ситуации когда h1 отличался от title. Стандарт просто не позволял сверстать страницу иначе. Так как h1 заголовок мог быть только один на странице. Как следствие ситуация когда meta информация из заголовка title и контент задающий тему документа должны были быть одинаковыми. Иначе они противоречили друг другу. От туда и шли рекомендации SEO специалистов о необходимости делать h1 другим но перекликающимся с мета title
В 2014 году появляется первая официальная версия стандарта HTML5, в рамках которого был сформирован аппарат семнатической верстки. Полностью меняющий подход к описанию семантики контента. Кроме всего прочего в нем было указано что вес заголовка (цифра у буквы H) перестала иметь какое либо значение (изначально эти теги вообще собирались убрать и оставить один тег H), и использовалось только в ситуациях когда сверстаный макет должен был быть обратно совместим с html4 или верстальщик обозначил страницу как html5 (страница начинается с ) но вся верстка внутри типичная html4 каша.
Минимум с 2016 года, Google стала разбирать страницу следуя именно правилам html5 семнатике. А с 2018 года, эти правила стали иметь наивысший приоритет. То есть если до 2018 года, ваша html4 каша в верстке с со всеми вашими SEO рекомендациями еще парсилась как та, которую принимают за данность, то с 2018 года, контент стал строго рассматриваться в рамках семантики html5 и вся html4 каша стала резко проседать в выдаче. Каждый полсдеющий апдейт гугла вносил дополнительные коррективы в то, насколько они серьезно относятся к корректности реализации этого аппарата, где семнатические связи блоков (в html4 - иерархия h1-h6, в html5 правила взаимосвязи секционного контента) иммеет первоочередное значение, поскольку является фундаментом построения страницы.
Та ссылка что Вы дали, об эксперименте Шепарда в 2020 году о влиянии h1, была предметом гомерического хохота в среде SEO специалистов. Два года уже гугл на каждом повороте орет о том, что для них ваши h1-h6 это мертвому припарки, и они определяют значение контента по иным принципам (HTML5), а человечище из Moz в 2020 году ставит опыт проверяя html4 и с удивлением обнаруживает что оно дескать не работает.
6 лет стандарту, два года официальных заявлений, а мы впервые решили перепроверить как работает. Занавес.
Так вот в рамках стандарта html5 заголовок секции, первой из которой является тег body, считающейся родительской секцией, может быть заголовок любого уровня. Потому что не имеети значения как вы обозначите заголовок секции, являющийся родительской. Она всего одна.
В рамках стандарта - секция не обязательно должна иметь заголовок.
В рамках стандарта - секция может иметь сколь угодно много дочерних секций, значение которых определяется уровнем вложенности одной в другую.
Как итог возвращаясь к вопросу о title и основном заголовке документа, в рамках семантики html5 стало возможно верстать страницы, когда мета информация заголовка title определяет тему ВСЕГО документа, при этом мы можем иметь 1,2,3 ... n секций имеющих равный приоритет друг перед другом и заявляющих о разных темах в рамках обшей темы обнаруженной в мета тайтл.
Типичный пример - каталог любого магазина, где мета тайт будет определять тему - условно Черешня, а старница будет иметь перечисления типов черешни, и каждый из блоков будет самостоятельной секцией, со своей самостоятельной несвязанной с другими иерархией, в рамках общей структуры. Чего в html4 сделать было невозможно. Так как вы были прибиты гвоздями к иерархии h1 -h6.
На примере seopulse
Вот взять ваш проект seopulse. У вас там главная страница сейчас размечена человеком который пытался разобраться с семнатикой html5 и часто удачно. У вас там правильно задана структура секциями артикл, но применено очень странное решение с aside которое на вскидку интерпретируется как ошибка. Если только вы по каким то причинам не решили, что для вашего списка материалов где авторство имеет важнейшее значение, зачем то это самое авторство нужно убить, чем снизить в глазах индексирующего алгоритма и тех критериев которые сейчас предьявляет гугл к контенту такого рода.
Скорее всего просто не разобрались с тем что такое aside. И на вашем месте я бы это бегом исправлял, пока гугл еще не отдает секции aside критического значения.
Следом идет тег picture который уже однозначно демонстрирует что человек не понимал что делал. Так как это группирующий тег для встраиваемого контента, внтури которого НИКАК не может быть тега noscript. Который явно вставлен плагином для LazyLoada, написанный очередным альтернативно одаренным программистом не знающим зачем в html5 112 тегов со своей семантикой и тем более как нужно работать с тегом picture.
В итоге ваши изображения сейчас с высокой долей вероятности либо не значат ничего для индексирующего алгоритма (так как структура поясняющая их значение привела к полной неоднозначности их роли), либо интерпретируются в негативном свете.
Как резюме, у вас шаблон сверстан на базе какого то другого шаблона, который писался одним человеком - понимающим многое в html5 и доделывался другим, который ничерта в этом не понимал.
Оптимизация изображений
изображения для Google это фразовый контент, то есть ровно то что вы считаете текстом. При этом значение этого контента уже намного выше текста.
ALT атрибут - это фразовая интерпретация изображения, которая при анализе текста подставляется вместо самого изображения. НО только в том случае, если анализ изображения - того что на нем нарисовано, показал, что фраза из alt атрибута дейтсвительно соответствует распознанным образам.
Если вдруг еще кто то, до сих пор сомневается в этом то у меня новости - ГУГЛ ОФИЦИАЛЬНО написал это в своей документации.
Микроразметка
Микроразметка, это не способ получения сниппетов в поисковой выдаче. Сниппеты это следствие.
Микроразметка это часть стандарта семнатической верстки HTML5. Которая используется индексирующим алгоритмом прежде всего по назначению - для того чтобы понять где у вас ноты а где рыбу заворачивали. Как следствие, правильная микроразметка это необходимое правило для верной интепретации вашего контента. А не для формирования сниппетов, которые и без микроразметки можно получить.
Фото видео
Фото и видео, как я сказал выше, это не просто хрены с горы, а непосредственные участники вашего текста с влиянием на страницу намного большим чем сам текст. Потому правильная верстка этих элементов в рамках фразового контента - залог успеха.
Игого
Если не хотите оставаться на обочине сео рынка, подтягивайте свой технический уровень. 2020 год в Google прошел под девизом "Техничка наша ВСЬООО"
когда у масы техническиих факторов их степень влияния подняли с нуля до критического.
DemiMurych
Вы очень глубоко заблуждаетесь. И если год назад у вас был шанс стать в позу - дескать у них нигде не написано значит такого нет, то теперь почти везьде на официальном сайте это оказывается в той или иной форме. Не говоря о публичных выступлениях официальных лиц. На ютубе есть канал гугла по сео. Там все время что дядя Женя, что дядя Мартин, чуть ли не в каждом видео о микроразметке поясняют зачем она нужна. И сниппеты, это всего лишь следствие.
Вот вам набор примеров
https://developers.google.c...
. Вся эта информация может быть размечена с помощью структурированных данных, что облегчает ее анализ для таких систем, как Google Поиск. Когда вы добавляете новые объекты, относящиеся к странице, Google Поиск получает более полное представление о ней и может показывать ее в различных результатах поиска.
Чтобы система Google Поиска могла определить, чему посвящена ваша страница, укажите главный тип структурированных данных, соответствующий ее основному контенту.
Если не связать объекты, система Google Поиска может не знать, что нужно показывать видео в качестве расширенного результата по запросу "рецепт".
Соответствие этим правилам нелегко проверить автоматически. Их нарушение может привести к тому, что синтаксически корректные структурированные данные не появятся в расширенных результатах или будут помечены как спам.
Как легко убедиться по этим цитатам, влияние микроразмемкти выходит далеко за пределы косметического оформления сниппетов.
От прямого влияния на выдачу, до ручных мер. И это только самый начальный уровень всего этого.
Все что ниже уже лично мои прохладные переживания по этому поводу.
я даже не заглядывая в записи могу назвать три разных способа, неправильной разметкой похоронить страницы, при этом выполняя все строго по официальной документации гугла.
1. Гугл поддерживает почти всю спецификацию schema.org.
То что люди видят на этой странице https://developers.google.c...
это только урезанные правила для формирования сниппетов. И то далеко не всех. И нигде в рамках документации вы не найдете полного списка.
По простым причинам - это стоит денег.
2.
нужна именно для формирования сниппетов, но никак не для дополнительного понимания контента "что мы можем нового узнать из разметки, что не можем узнать из страницы?",
Простой ответ - ВСЕ.
Микроразметка это часть стандарта семантической верстки. Когда кто то просто отдаст страницу с товаром без разметки, то попробуйте себе представить хотя бы на пальцах алгоритм, который разберет эту кашу по свойствам. Попробуйте понять где телефон для сапорта, а где для менеджера, где вообще телефон а не артикул, где цена и что это за набор странных букв в углу.
бот не умеет смотреть глазами человека, он должен парсить теги - разметку. И если люди не позаботились о том, чтобы структурировать свою информацию, а это в большистве случаев так, то никакая магия не поможет боту без разметки понять этот контент.
Вопрос про пикча я не понял.