Руководство по диагностике распространенных проблем JavaScript SEO

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

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

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

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

Кратко о рендеринге

Прежде чем мы перейдем к более детальным вещам, давайте поговорим об общей картине.

Чтобы поисковая система могла понять контент, основанный на JavaScript, она должна просканировать и отобразить страницу.

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

Если он решает не отображать страницу или не может правильно отображать содержимое, это может быть проблемой.

Все сводится к тому, как внешний интерфейс обслуживает HTML в начальном ответе сервера.

Когда URL-адрес создается в браузере, внешний интерфейс, такой как React, Vue или Gatsby, будет генерировать HTML для страницы. Сканер проверяет, доступен ли уже этот HTML-код на сервере («предварительно обработанный» HTML), прежде чем отправить URL-адрес для ожидания рендеринга, чтобы он мог просмотреть полученный контент.

Доступность предварительно обработанного HTML зависит от того, как настроен внешний интерфейс. Он либо сгенерирует HTML через сервер, либо в клиентском браузере.

Рендеринг на стороне сервера

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

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

Рендеринг на стороне клиента

В CSR HTML создается в браузере вместе со всеми компонентами JavaScript. JavaScript нуждается в рендеринге, прежде чем HTML станет доступен для сканирования.

Если служба визуализации решает не отображать страницу, отправленную в очередь, копии, внутренние URL-адреса, ссылки на изображения и даже метаданные остаются недоступными для поисковых роботов.

В результате у поисковых систем практически нет контекста, чтобы понять актуальность URL-адреса для поисковых запросов.

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

Безусловно, существуют инструменты, которые помогут выявить проблемы SEO, связанные с JavaScript.

Вы можете провести много исследований, используя инструменты браузера и Google Search Console. Вот краткий список, который составляет надежный набор инструментов:

• Просмотр исходного кода: щелкните правой кнопкой мыши страницу и нажмите «Просмотреть исходный код», чтобы просмотреть предварительно обработанный HTML-код страницы (первоначальный ответ сервера).
• Проверка URL-адреса в реальном времени (проверка URL-адреса): просмотрите снимок экрана, HTML и другие важные сведения о отображаемой странице на вкладке проверки URL-адреса в Google Search Console. (Многие проблемы с рендерингом можно обнаружить, сравнив предварительно обработанный HTML-код из «источника просмотра» с визуализированным HTML-кодом при тестировании активного URL-адреса в GSC.)
• Инструменты разработчика Chrome: щелкните правой кнопкой мыши страницу и выберите «Проверить», чтобы открыть инструменты для просмотра ошибок JavaScript и т. д.
• Wappalyzer: просмотрите стек, на котором построен любой сайт, и найдите информацию о конкретной платформе, установив это бесплатное расширение для Chrome.

Распространенные SEO-проблемы с JavaScript

Проблема 1. Предварительно обработанный HTML недоступен повсеместно

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

Если сканер решит поместить URL-адрес в процесс рендеринга, он попадет в очередь рендеринга. Это происходит из-за того, что сканер может обнаружить несоответствие между предварительно обработанной и обработанной структурой HTML. (Что имеет большой смысл, если нет предварительно обработанного HTML!)

Нет никаких гарантий того, как долго URL-адрес ожидает службы веб-рендеринга. Лучший способ склонить WRS к своевременному рендерингу — убедиться, что на сайте есть ключевые авторитетные сигналы, иллюстрирующие важность URL-адреса (например, ссылки в верхней части навигации, множество внутренних ссылок, обозначенных как канонические). Это немного усложняется, потому что авторитетные сигналы также необходимо сканировать.

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

Перейдите в «Страницы» > «Индексирование страниц» > «Просканировано» — в настоящее время не проиндексировано и найдите в списке наличие приоритетных страниц.

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

Общие причины

Настройки по умолчанию

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

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

Одностраничное приложение

Если сайт представляет собой одностраничное приложение, он полностью обернут в JavaScript и генерирует все компоненты страницы в браузере (то есть все), отображается на стороне клиента, а новые страницы обслуживаются без перезагрузки).

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

Это не означает, что невозможно настроить SPA более удобным для SEO образом. Но есть вероятность, что для этого потребуется значительная работа разработчиков.

Проблема 2. Некоторое содержимое страницы недоступно для поисковых роботов

Заставить поисковую систему отображать URL-адрес — это здорово, только если все элементы доступны для сканирования. Что делать, если он отображает страницу, но есть разделы страницы, которые недоступны?

Например, SEO-специалист проводит анализ внутренних ссылок и практически не обнаруживает внутренних ссылок для URL-адреса, связанного с несколькими страницами.

Если ссылка не отображается в HTML-коде, созданном с помощью инструмента Test Live URL, вероятно, она используется в ресурсах JavaScript, к которым у Google нет доступа.

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

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

Общие причины

Ошибки JavaScript

Давайте начнем с отказа от ответственности здесь. Большинство ошибок JavaScript, с которыми вы сталкиваетесь, не имеют значения для SEO.

Поэтому, если вы отправитесь на поиски ошибок, отнесете длинный список своему разработчику и начнете разговор с вопроса «Что это за ошибки?», они могут воспринять это не очень хорошо.

Подойдите к вопросу «почему», поговорив о проблеме, чтобы он мог стать экспертом по JavaScript (потому что он им является!).

При этом существуют синтаксические ошибки, которые могут сделать остальную часть страницы неразборчивой (например, «блокировка рендеринга»). Когда это происходит, средство визуализации не может выделить отдельные элементы HTML, структурировать содержимое в DOM или понять отношения.

Как правило, эти типы ошибок распознаваемы, потому что они также имеют какой-то эффект в представлении браузера.

В дополнение к визуальному подтверждению также можно увидеть ошибки JavaScript, щелкнув правой кнопкой мыши страницу, выбрав «проверить» и перейдя на вкладку «Консоль».

Контент требует взаимодействия с пользователем

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

Почему это имеет значение? Подумайте о нашем старом, надежном друге, раскрывающемся списке «аккордеон» и о том, как много сайтов используют его для организации контента, такого как сведения о продукте и часто задаваемые вопросы.

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

Чтобы проверить, вы можете «осмотреть» страницу и посмотреть, находится ли «скрытый» контент (то, что отображается, когда вы нажимаете на аккордеон) в HTML.

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

Проблема 3: разделы сайта не сканируются

Google может отображать или не отображать вашу страницу, если он просканирует ее и отправит в очередь. Если он не сканирует страницу, даже эта возможность исключена.

Чтобы понять, сканирует ли Google страницы, может пригодиться отчет «Статистика сканирования» « Настройки» > «Статистика сканирования» .

Выберите Запросы сканирования: ОК (200), чтобы увидеть все экземпляры сканирования 200 страниц состояния за последние три месяца. Затем используйте фильтрацию для поиска отдельных URL-адресов или целых каталогов.

Если URL-адреса не отображаются в журналах сканирования, есть большая вероятность, что Google не может обнаружить страницы и просканировать их (или они не содержат 200 страниц, что является совершенно другой проблемой).

Общие причины

Внутренние ссылки не сканируются

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

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

Простой способ проверить это — перейти по URL-адресу, который ссылается на потерянную страницу, о которой сообщается. Щелкните правой кнопкой мыши на странице и нажмите «Просмотр исходного кода».

Затем используйте CMD + f для поиска URL-адреса страницы-сироты. Если он не отображается в предварительно обработанном HTML-коде, но появляется на странице при отображении в браузере, перейдите к четвертому вопросу.

XML-карта сайта не обновляется

Карта сайта в формате XML имеет решающее значение, поскольку помогает Google обнаруживать новые страницы и понимать, каким URL-адресам отдавать приоритет при сканировании.

Без карты сайта XML обнаружение страниц возможно только по ссылкам.

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

В зависимости от используемого внешнего интерфейса у вас может быть доступ к плагинам, которые могут создавать динамические карты сайта в формате XML.

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

Это должно быть относительно легко проверить, запустив карту сайта через ваш любимый инструмент SEO.

Проблема 4: внутренние ссылки отсутствуют

Недоступность внутренних ссылок на поисковые роботы — это не только потенциальная проблема обнаружения, но и проблема справедливости. Поскольку ссылки передают SEO-качество от ссылочного URL-адреса к целевому URL-адресу, они являются важным фактором в повышении авторитета как страницы, так и домена.

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

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

Общие причины

Требуется взаимодействие с пользователем, чтобы перейти по ссылке

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

При настройке бесконечной прокрутки бесчисленное количество продуктов на странице списка продуктов (категории) не будет загружаться, если пользователь не прокрутит страницу за определенную точку (ленивая загрузка) или не нажмет кнопку «Показать больше».

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

Вот почему SEO-специалисты обычно предпочитают настоящую разбивку на страницы, в которой каждая страница результатов имеет отдельный URL-адрес для сканирования.

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

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

Как минимум следуйте рекомендациям Google по оптимизации бесконечной прокрутки.

Ссылки не закодированы должным образом

Когда Google сканирует сайт или отображает URL-адрес в очереди, он загружает версию страницы без сохранения состояния. Это большая часть того, почему так важно использовать правильные теги href и якоря (структура ссылок, которую вы видите чаще всего). Сканер не может отслеживать такие форматы ссылок, как router, span или onClick.

Может следовать:

• <ссылка=»
• <ссылка=»

Не удается подписаться:

• <a routerLink=»некоторые/путь»>
• <промежуток href=»
• <a onclick=»перейти(‘

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

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

Проблема 5: Метаданные отсутствуют

На HTML-странице метаданные, такие как заголовок, описание, канонический URL-адрес и метатег robots, находятся в заголовке.

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

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

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

Общие причины

Отсутствие или неправильная конфигурация носителя метаданных

В среде JS плагин создает заголовок и вставляет в него метаданные. (Самый популярный пример — React Helmet.) Даже если плагин уже установлен, обычно его нужно правильно настроить.

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

Проблема 6: ресурсы не сканируются

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

Поскольку у них также есть свои собственные URL-адреса, к ним также применяются законы сканируемости. Если файлы заблокированы для сканирования, Google не может проанализировать страницу для ее отображения.

Чтобы узнать, сканируются ли URL-адреса, вы можете просмотреть прошлые запросы в GSC Crawl Stats.

• Изображения: выберите «Настройки» > «Статистика сканирования» > «Запросы на сканирование: изображение».
• JavaScript: выберите «Настройки» > «Статистика сканирования» > «Запросы на сканирование: изображение».

Общие причины

Каталог заблокирован robots.txt

URL-адреса скриптов и изображений обычно находятся в своих собственных выделенных поддоменах или подпапках, поэтому выражение запрета в файле robots.txt предотвратит сканирование.

Некоторые инструменты SEO сообщат вам, заблокированы ли какие-либо файлы сценариев или изображений, но проблему довольно легко обнаружить, если вы знаете, где вложены ваши изображения и файлы сценариев. Вы можете найти эти структуры URL в файле robots.txt.

Вы также можете увидеть любые скрипты, заблокированные при отображении страницы, с помощью инструмента проверки URL-адресов в Google Search Console. «Проверить действующий URL», затем перейдите в раздел « Просмотр протестированной страницы» > «Дополнительная информация» > «Ресурсы страницы» .

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

Подружитесь с JavaScript

Да, JavaScript может иметь некоторые проблемы с SEO. Но по мере развития SEO лучшие практики становятся синонимом отличного пользовательского опыта.

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

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