Техническая оптимизация статей

Техническая SEO оптимизация статей

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

//

Содержание:

Если вы читали другие мои статьи, то вам не удалось избежать того факта, что быстрое наполнение и индексирование Google вашего новостного контента имеет решающее значение для успеха SEO.

В большинстве случаев первоначальное окно видимости Top Stories составляет менее 48 часов, и Google отдает предпочтение “первым издателям”, когда речь идет о показе новостных статей о последних событиях. Отсюда вытекает важность быстрого индексирования Google только что опубликованных статей.

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

Существует множество различных аспектов, которые играют важную роль, но здесь я сосредоточусь исключительно на самих статьях – в частности, на исходном HTML-коде статьи.

Многоуровневое индексирование

Тот факт, что Google имеет многоуровневую систему индексации, уже давно не является секретом.

Несколько лет назад Google открыто признался, что использует как минимум два этапа индексирования. На первом этапе Google анализирует необработанный HTML страницы, затем происходит второй этап рендеринга, на котором страница загружается в безголовый браузер Chrome и выполняется соответствующий код на стороне клиента.

Вот как Google визуализирует этот процесс:

Многоуровневое индексирование

Аспект индексации, связанный с рендерингом, не является мгновенным. Из документации Google по JavaScript и SEO (выделено автором):

«Googlebot ставит в очередь все страницы для рендеринга, если только метатег или заголовок robots не указывает роботу Googlebot не индексировать страницу. Страница может оставаться в этой очереди несколько секунд, но это может занять и больше времени. Как только ресурсы Googlebot позволяют, безголовый Chromium отображает страницу и выполняет JavaScript».

Это, а также дополнительное утверждение о том, что Google “также использует HTML для индексации страницы”, заставило многих разработчиков предположить, что использование JavaScript на стороне клиента вполне приемлемо для SEO.

К сожалению, это определенно не так.

Хотя тонкости JavaScript и SEO выходят за рамки этой статьи, достаточно сказать, что использование клиентского JS для загрузки содержимого страницы – исключительно плохая идея. Даже Google признает, что использование рендеринга на стороне сервера предпочтительнее:

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

В контексте новостей использование JavaScript на стороне клиента для контента активно не поощряется. В своей документации по техническим требованиям для издателей новостей Google прямо заявляет следующее (выделено автором):

«Страницы ваших статей должны использовать формат HTML, а основной текст не должен быть встроен в JavaScript ».

На то есть очень веская причина. Хотя Google надеется, что сможет отобразить все страницы, которые он решит проиндексировать, задержка, которую фаза рендеринга вносит в процесс индексации, непредсказуема.

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

Таким образом, когда Google индексирует новостные статьи для использования в Top Stories и Google News, фаза рендеринга отсутствует. Google индексирует необработанный HTML-код статьи и делает все возможное, чтобы извлечь заголовок и содержание статьи. Клиентский JavaScript не выполняется.

Google полагается исключительно на источник HTML для индексации содержания статьи для Новостей Google. И хотя синтаксический анализ HTML в Google чертовски хорош, он не идеален. Это влияет на то, как издатели должны форматировать HTML своих статей.

SEO – это вероятностный подход

Прежде чем перейти к конкретике, я хочу обсудить, как мы должны думать о SEO.

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

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

Сегодня SEO совсем другое дело. Количество ингредиентов выросло в геометрической прогрессии, а поисковые системы стали намного сложнее. Вместо того чтобы думать о SEO как о детерминированном процессе (сделай А, и произойдет Б), мы должны рассматривать SEO как вероятностный процесс (сделай А, и есть шанс, что произойдет Б).

Следующие советы по оптимизации HTML-текста статей посвящены повышению вероятности. В частности, предоставление Googlebot оптимального HTML снижает вероятность того, что что-то пойдет не так при индексировании вашей статьи Google.

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

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

Однако иногда плохой HTML вызывает заминку, и Google не индексирует статью. Техническая оптимизация HTML вашей статьи уменьшает вероятность этого.

Оптимизация <HEAD>

Давайте начнем с того, с чего начинается HTML: с <head> страницы. Раздел <head> HTML статьи содержит несколько важнейших элементов, которые Google обязательно должен разобрать.

К ним относятся <title>, <meta name=”description”>, <link rel=”canonical”>, <link rel=”amphtml”>, <meta name=”robots”> инструкции, а также различные теги <link rel=”alternate”>, содержащие ссылки на hreflang и/или мобильные альтернативные URL. Кроме того, в <head> располагаются метатеги Open Graph, на которые Google также часто полагается.

Оптимизация <HEAD>

Обычно рекомендуется также помещать соответствующий сниппет структурированных данных статьи в <head>. Теоретически вы можете поместить его в любое место HTML-источника, но практически безопаснее всего поместить его в <head>, чтобы Google прочитал и обработал его.

Почему? Как мы выяснили путем проб и ошибок (много ошибок), Google не всегда правильно анализирует весь <head>.

Я лично сталкивался с несколькими сценариями, когда Google не распознавал важные метатеги, такие как hreflang, канонические теги и сниппеты структурированных данных. Во всех этих случаях приоритезация этих элементов в <head> приводила к тому, что Google начинал правильно анализировать эти элементы.

Приоритет этих элементов означает размещение их в начале <head> перед любыми сниппетами CSS и JavaScript. Мы неоднократно убеждались, что это приводит к снижению количества ошибок и повышению вероятности того, что Google безупречно разберет эти метатеги и сниппеты структурированных данных.

Что может заставить Google не распознать должным образом все элементы <head>? Я мог бы посвятить этому целую статью, скоро значит она появится.

Если кратко, то иногда код в <head>, например HTML, встроенный в теги <noscript> может заставить Google поверить, что <head> закончился, а <body> начался. Любые метатеги, представленные ниже такого кода, ломающего <head>, будут должным образом игнорироваться Google, поскольку поисковая система (правильно) не подчиняется никаким метатегам, которые, по ее мнению, находятся в <body> HTML-страницы.

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

Оптимизация HTML статьи

Давным-давно (с точки зрения SEO) издатели новостей имели доступ к специальному отчету об ошибках сканирования в Webmaster Tools/Search Console. Эти отчеты показывали ошибки, с которыми Google сталкивался при индексировании статей издателей, одобренных для включения в Google News.

ошибки сканирования в Webmaster Tools/Search Console

Эти специальные отчеты были прекращены в 2018 году, что весьма прискорбно, поскольку они предоставляли издателям массу информации, которую можно было использовать для оптимизации HTML статей.

Среди ошибок, о которых там сообщалось, были такие, как “статья фрагментирована” и “заголовок не найден”, и изучение этих вопросов давало важные подсказки о том, как Google разбирает HTML статьи для индексации. Возможно, они были слишком полезны, так как выявляли некоторые слабые места Google в обработке HTML.

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

Лучшие практики (по моей версии):

Заголовок статьи должен быть первым заголовком <h1>

Я убежден, что Google ищет первый тег заголовка <h1> в HTML статьи и начинает разбирать содержимое статьи с этого момента. Поэтому важно убедиться, что первый заголовок <h1> в HTML действительно является заголовком статьи.

По общим соображениям доступности рекомендуется иметь только один заголовок <h1>, и он должен быть основным заголовком веб-страницы.

Избегайте кодированного HTML в заголовке статьи

Я видел много случаев, когда Google не мог правильно проанализировать заголовок статьи, если он содержал закодированные строки специальных символов, например:

кодированный HTML в заголовке статьи

Безопаснее просто использовать фактические символы или вместо этого полагаться на экранированные строки UTF-8.

Ограничьте HTML над открывающим заголовком <h1>

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

Я сталкивался со случаем, когда HTML статьи содержал около 450 КБ CSS и скриптов в <head> и начале <body> над заголовком статьи <h1>, и Google индексировал эти статьи с большим трудом. Примерно каждая пятая статья не индексировалась должным образом в Google News – они отображались как ошибки «сбой извлечения» в отчете об ошибках сканирования новостей.

Когда мы уменьшили нагрузку HTML над заголовком <h1> примерно до 100 КБ, количество ошибок резко сократилось, и Google без проблем индексировал статьи для Google News и Top Stories.

Минимизируйте прерывающие HTML-фрагменты в коде вашей статьи

Когда Google находит в статье начальный заголовок <h1>, он анализирует HTML под ним, чтобы проиндексировать содержание всей статьи.

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

Я рекомендую попытаться поместить все содержимое статьи в один непрерывный блок HTML, от открывающего заголовка <h1> до последнего абзаца.

Любые элементы, которые вы хотите визуально включить в текст статьи на отображаемой в браузере веб-странице, в идеале должны располагаться ниже или (что менее идеально) выше HTML статьи в исходном коде. С помощью правильного CSS вы можете вставить их в любое место на странице – просто убедитесь, что HTML для этих элементов не нарушает содержание статьи.

Semantic HTML поможет

В пятой версии HTML были введены дополнительные семантические теги <header>, <section>, <article> и <footer>, для обозначения определенных элементов страницы в исходном тексте HTML.

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

TLDR: чистый код по-прежнему имеет значение

Сосредоточение внимания на чистом, семантическом HTML может показаться устаревшей точкой зрения. Это не то, чему многие веб-разработчики уделяют много внимания. Один взгляд на HTML, создаваемый многими платформами и фреймворками, заставляет классического HTML-кодера (как, например, вас) вздрогнуть.

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

Однако для Google News чистый HTML все же довольно важен. Аккуратный код может сыграть решающую роль между тем, чтобы статья получила хорошую видимость в Top Stories, или вообще не попала в индекс.

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

Подведем итоги

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

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

Предыдущая

HTML-код: Распространенные ошибки SEO

Следующая

Как нанять SEO-фрилансера без проблем в 2022 году?

Последние от Советы