Где JavaScript и SEO встречаются

1. Вступление
2. Как работает Google?
3. Вызов под названием JavaScript
4. Руководство по адаптации веб-сайта JS для поисковых систем
5. Тематическое исследование
6. Ресурсы

В следующем документе мы рассмотрим тему JS с точки зрения SEO и выложим всю нашу информацию и рекомендации по этому вопросу.

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

Вступление

(a) Чтобы установить нашу точку зрения на сайты JavaScript с точки зрения SEO, давайте начнем с цитаты известного Гуглера Джона Мюллера:

Сообщение ясно - Google понимает, что использование JavaScript будет только расти, и они приспосабливаются к этому.
В 2018 году законно создать сайт, широко использующий JS; Преимущества очевидны, и возможности Google со временем будут постоянно улучшаться и адаптироваться к стандартам Интернета.

(b) Сказав, что в краткосрочном и среднесрочном плане веб-сайты JS столкнутся с Google со значительными проблемами сканирования и индексации, о чем мы и расскажем в этой статье - мы наметим проблемы, с которыми Google сталкивается при работе с JS сайты и рекомендуемая практика для их преодоления.
Для лучшего понимания предмета теперь мы кратко рассмотрим, как Google сканирует и индексирует сеть, а также проблемы, которые JavaScript представляет для поисковых систем.

Как работает Google?

(а) Эффективность
Прежде всего, важно понимать, что центральным элементом во всех вопросах, касающихся технического SEO, является эффективность - вопрос первостепенной важности для механизмов сканирования и индексации Google, которые должны работать с максимальной эффективностью. Интернет - это огромный океан, который нужно сканировать и индексировать, однако ресурсы Google, какими бы обширными они ни были, в конечном итоге ограничены.
Вот почему значительная часть технического SEO направлена ​​на содействие сканированию и индексации на веб-сайте, будь то четкое определение одного тега <h1> на веб-странице или блокирование всей области веб-сайта с помощью файла robots.txt. и целый ряд других действий, призванных помочь механизмам сканирования и индексации сосредоточиться только на соответствующих веб-страницах и четко «понять» содержимое веб-страницы.

(б) Сканирование и индексирование
Давайте начнем с краткого объяснения процесса и того, как работают два основных механизма Google:
Механизм сканирования - известный как Googlebot - отвечает за обнаружение новых URL-адресов и передачу их для индексации; сканер запрашивает адрес с сервера, получает от него файл HTML и перенаправляет его для индексации, собирая при этом любые ссылки на дополнительные адреса, содержащиеся в файле, и продолжая сканировать их дальше.
Механизм индексации, иногда называемый кофеином, отвечает за оценку и индексацию контента по URL-адресу, полученному от Googlebot; среди прочих операций механизм отвечает за индексацию содержимого веб-страницы, оценку ее важности, а также определение приоритетов сканирования страницы для робота Googlebot, то есть частоты посещений веб-страницы в зависимости от ее уровня важности.
Как можно заключить, механизмы работают одновременно и параллельно - один из них сканирует и обнаруживает адреса, а другой индексирует их содержание: эффективность.
В то же время следует отметить, что это отдельные механизмы.

(в) скорость
Далее, имея это в виду, теперь мы можем рассмотреть скорость загрузки. Google строго следит за эффективным использованием своих ресурсов, не выделяя более нескольких секунд на рендеринг веб-страницы (считается, что он выделяет примерно 5 секунд, но на самом деле это зависит от сайта). Через несколько секунд Google движется дальше; т. е. содержимое, не отображаемое в течение нескольких секунд, не может быть проиндексировано. Конечно, страдает не только конкретная веб-страница, но и весь веб-сайт, если ресурсы на его страницах загружаются слишком долго - Google далек от радости (мягко говоря) сканировать и индексировать из-за загрузки сайта накладывает на свои ресурсы; это может привести к тому, что будет просканировано меньше страниц сайта, и с меньшей частотой.

(d) WRS на основе Chrome 41
На этой записке кофеина, это было официально объявлено что служба веб-рендеринга Google основана на браузере Chrome 41 и фактически идентична этой версии браузера; другими словами, Google использует 3-х (!) -летний браузер для рендеринга веб-страниц.
Понимание возможностей и ограничений Chrome 41 значительно облегчит создание веб-сайта, который Google может сканировать и индексировать должным образом.
Браузер Chrome 41 также следует использовать в качестве важного средства отладки.

Chrome 41 может быть установлен здесь.

Вызов под названием JavaScript

Изучив механизмы сканирования и индексации Google, мы можем теперь обратиться к проблемам, которые JS представляет для поисковых систем: Короче говоря, основная проблема с JS заключается в его неэффективности для Google (несмотря на то, что это приятно для пользователей), в сочетании с тем, что JS имеет тенденцию игнорировать ограничения Google.
Давайте посмотрим на это более подробно и изложим точки трения между JS и поисковыми системами:

1. Рендеринг на стороне клиента - многие JS-сайты используют рендеринг на стороне клиента, т. Е. HTML загружается на стороне клиента, что оказывает значительное влияние на поисковые системы.

> Основным следствием является необходимость для Google выделять ресурсы для отображения веб-страницы. На веб-сайтах, загруженных на стороне сервера, робот Googlebot запрашивает веб-страницу с сервера и получает весь HTML-код, уже обработанный и готовый для индексации; Робот Googlebot передает HTML-код «как есть» в Caffeine, который затем может проиндексировать его - это двухэтапный процесс: сканирование и индексация. На загруженных на стороне клиента веб-сайтах JS поисковая система получает только базовый файл с сервера, и в этом процессе требуется дополнительный этап - рендеринг полного HTML-кода веб-страницы в процессе подготовки к индексации, теперь этот процесс влечет за собой дополнительный этап: сканирование > Рендеринг> Индексирование. Дополнительный этап, рендеринг, требует выделения дополнительных ресурсов Google, и, как указано, Google управляет своими ресурсами с максимальной эффективностью.

> Дополнительным следствием, вытекающим из предыдущего, является неспособность Googlebot сканировать ссылки и дополнительные адреса одновременно с работой, проделанной Caffeine. Как уже упоминалось, на клиентских веб-сайтах JS, отображаемых на стороне клиента, робот Googlebot не получает обработанный и готовый HTML-код с сервера, поэтому для того, чтобы робот Googlebot продолжал чистить и сканировать новые URL-адреса с веб-страницы, он должен дождаться, пока Caffeine завершит рендеринг веб-страницу, найдите на ней ссылки и перешлите их обратно, чтобы их можно было сканировать: неэффективно.

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

Пояснение : термин «рендеринг» относится к компиляции HTML (DOM), а не к визуализации DOM в пикселях:

Стоит уделить немного времени и углубиться в процесс индексации загруженной веб-страницы JS на стороне сервера:
В видео для разработчиков ( Вот ) Google объявил (и, как объяснялось выше), что для поисковой системы процесс рендеринга полностью отделен от сканирования или индексации, и что для веб-страниц, требующих рендеринга, индексация приостанавливается до тех пор, пока не будут доступны необходимые ресурсы рендеринга : -

Google также сообщил (в том же видео), что для веб-страниц, требующих рендеринга, фактически существует две волны индексации:

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

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

2. Несовместимость с Chrome 41 - современные библиотеки JS могут использовать вещи, которые не существовали 3 года назад и которые Chrome 41 не может воспроизвести (например, ES6); Это означает, что Google также не может отображать их, а контент, который Google не знает, как отображать, не может быть проиндексирован.
Следует отметить, что не менее важным является тот факт, что пользователи с более старыми браузерами («старые» могут даже включать более новые версии Explorer или даже Safari) будут сталкиваться с такими же проблемами при посещении веб-сайта и могут просматривать контент частично или нет на все.

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

4. Скрытый контент - кроме того, JS использует различные типы пользовательских событий, инициируемых пользовательским взаимодействием (например, onclick) для загрузки контента, т.е. контент не будет загружаться при начальной загрузке веб-страницы, но только когда пользователь инициирует определенное взаимодействие, если браузер отправит на сервер дополнительный запрос и загрузит запрошенный контент. Важно понимать, что Google не является пользователем в том смысле, что он не взаимодействует с веб-страницей, что означает, что контент, отсутствующий на веб-странице по завершении начальной загрузки, скорее скрыт за каким-либо поведением пользователя / взаимодействие, не будет доступно для Google и, следовательно, не будет проиндексирован.
5. URL-адрес - некоторые из библиотек JS (например, Angular 1) используют хэш-тег (#) в URL-адресах, однако Google игнорирует что-либо после хэштега в URL-адресе, поскольку это не является уникальным адресом. но внутренняя ссылка на определенное место на той же веб-странице, своего рода закладка; то есть Google не видит это как уникальный адрес, требующий отдельной индексации.
В итоге: хотя Google имеет возможность сканировать и индексировать JS, все еще существуют некоторые ограничения, связанные с тем, что Google является BOT и его необходимостью в качестве поисковой системы для эффективной работы, поэтому в настоящий момент ему по-прежнему нужна наша помощь, чтобы обеспечить сканирование и индексацию JS.

Руководство по адаптации веб-сайта JS для поисковых систем

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

(а) Обслуживание веб-страниц
Чтобы гарантировать, что веб-страницы, основанные на JS, обслуживаются так, чтобы Google мог легко и эффективно индексировать (другими словами, максимально экономя на этапе рендеринга), Google предлагает 2 возможных решения, общим знаменателем которых является то, что для Google веб-страницы обслуживаются, причем основная часть их контента уже представлена.

Решение A - Гибридный рендеринг. Идеальное решение, которое, по мнению Google, установит долгосрочный стандарт, хотя его сложнее реализовать.
Решение B - Динамический рендеринг: функциональное решение, которое в настоящее время удовлетворительно решает проблему.
Давайте уточним:

Гибридный рендеринг или изоморфный JavaScript
Google рекомендует обслуживать веб-сайт (рекомендация, показанная здесь в официальном видео Google для разработчиков, аналогичная рекомендация здесь в дополнительном видео Джона Мюллера) с использованием гибридного рендеринга, который может быть выполнен с использованием изоморфного JavaScript.
Руководящий принцип объединяет использование рендеринга сервера и клиента.
Основная часть контента, важного для пользователя и поисковых систем, отображается на стороне сервера, достигая браузера в виде HTML; и элементы веб-страницы, в основном предназначенные для взаимодействия с пользователем (которые по большей части не имеют отношения к Google), отображаются на стороне клиента. Таким образом, Google не нужно отображать контент веб-страницы, который важен для индексации, однако веб-сайт, тем не менее, может предложить пользователям богатый и динамичный пользовательский опыт.

Точный баланс между рендерингом на стороне клиента и на стороне сервера хорошо объяснен здесь:

На практике реализация гибридного рендеринга может быть сложной в большинстве фреймворков, однако для балансировки рендеринга на стороне сервера и клиента можно использовать платформу Angular Universal ( Угловой универсальный Официальный веб-сайт).
Для этого решения также требуется сервер на базе JS.

Динамический рендеринг
Это решение основано на принципе сервера, идентифицирующего запросы Googlebot (пользовательским агентом) и отображающего веб-страницу на стороне сервера только для Google, но страница продолжает отображаться на стороне клиента для пользователей в обычном режиме. мода.
Для этого решения Google рекомендует, чтобы рендеринг не выполнялся для робота Google на сервере как есть, потому что для этого может потребоваться большой объем ресурсов сервера, но, скорее, он рекомендует интегрировать инфраструктуру на сервере, что позволяет выполнять рендеринг извне для Google.
Блок-схема динамического рендеринга:

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

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

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

(б) Использование Chrome 41 Как уже говорилось, Google WRS основан на браузере Chrome 41; поэтому необходимо знакомство с ограничениями Chrome 41, как и оптимизация сайта для поисковых возможностей Google.

Рекомендуется использовать Chrome 41 в качестве средства отладки.
Проверка «Консоли» (в разделе «Проверка») в Chrome 41 покажет нам список проблем, с которыми браузер столкнулся при загрузке веб-страницы - это те же препятствия, с которыми Google столкнется при загрузке страницы: бесценный интеллект.
На следующем снимке экрана показан сайт JS, испытывающий затруднения при ранжировании; GSC «fetch & render» показал, что во время рендеринга что-то идет не так, однако только в Chrome 41 (в консоли, в разделе Inspect) мы смогли увидеть причину проблемы:

Кроме того, у Google WRS (на основе Chrome 41) есть несколько ограничений, на которые стоит обратить внимание:

(в) Изящная деградация
В дополнение к вышесказанному, веб-сайт должен быть адаптирован к старым / менее продвинутым браузерам; Помимо формы, помогающей Google отображать сайт, это также позволяет пользователям старых браузеров загружать сайт. Здесь мы можем только рекомендовать использование транспиллинга / полизаполнения, хотя, естественно, ваша собственная команда разработчиков может определить решения, подходящие для вашего сайта, при условии, что тесты на совместимость с Chrome 41 выполнены, как указано.

(d) Оптимизированный путь рендеринга
Как уже упоминалось, скорость загрузки важна, и для веб-сайтов JS, склонных к медленной загрузке сценариев - контент, который загружается слишком долго, может не индексироваться, поскольку страница будет заброшена заранее. Поэтому акцент должен быть сделан на этапе разработки при загрузке страницы сайта; помощь технической команды Google и их Руководство по оптимизации рендеринга Рекомендовано.

(e) Использование History API
Используйте дружественные URL-адреса, в любом случае избегайте использования фрагментированных URL-адресов (содержащих хэштеги - как объяснено (Google игнорирует что-либо после хэштега, не индексируя уникальный адрес).
Также следует избегать адресов хеш-бэнга (#!): Хотя Google способен их сканировать, недавно объявил эти адреса с пропущенными фрагментами игнорируются, поскольку имеется возможность прямой визуализации адреса hashbang, тем не менее наш опыт показывает, что адреса hashbang создают множество проблем.

Рекомендация Google с использованием History API (около 100 секунд. Время просмотра с этого момента в видео ); Это решение позволяет создавать удобные URL-адреса на одностраничных веб-сайтах приложений, а также на тех, которые широко используют JS.

(f) Ссылки
Каждая URL-ссылка, которую мы хотим, чтобы Google сканировал и индексировал, должна быть связана с помощью ссылки href на сайте; избегайте использования ссылок onclick и JS. Google сканирует только ссылки href ( здесь в видео ) и построение ссылок в HTML гарантирует, что Google сканирует и достигает всего контента на сайте.

(g) Центральные встроенные элементы
Как подразумевается в пар. (a) центральные элементы и контент на странице из POV поисковой системы (т. е. основной контент и метатеги - заголовок, канонический и т. п.) должны быть встроенными, чтобы обеспечить их доступность для поисковых систем. Другими словами, правильная реализация гибридного / динамического рендеринга гарантирует, что центральные элементы отображаются на стороне сервера и достигают встроенного браузера и в HTML для Googlebot.

(h) Ленивая загрузка изображений
Поскольку веб-сайт использует ленивую загрузку изображений для повышения скорости загрузки (т. Е. Веб-страница изначально загружается заполнителем в том месте, где находится изображение, и только когда изображение входит в порт просмотра пользователя, на его экране появляется запрос отправляется на сервер и само изображение загружается), убедитесь, что изображения доступны для поисковых систем. Как указано, поисковая система не взаимодействует с веб-страницей; он не прокручивает и не вставляет изображение на свой экран, то есть поисковая система отображает страницу без изображений (как уже упоминалось выше, изображения изначально не загружаются) и не может их проиндексировать.

Доступны 2 решения:

(i) Вставка изображения с тегом <noscript /> вокруг элемента <img>. Этот тег определяет альтернативу для браузеров, которые не поддерживают скрипты, включая изображение для них при начальной загрузке; Таким образом, Google может получить доступ к файлу изображения через этот тег в коде:

(ii) Вставка структурированных данных вокруг изображения, позволяющая Google получать доступ к изображению через структурированные данные:

(i) Дополнительная информация о Google
Мы воспользуемся возможностью обсудить два вопроса, которые не обязательно связаны с JS, но важны для разработки веб-сайта, адаптированного для поисковых систем:

> Google не имеет статуса
Сканер Google определен как не имеющий состояния, поэтому любой контент веб-сайта, отображаемый только пользователям в определенном состоянии, например, пользователи, имеющие определенные файлы cookie (например, контент, предназначенный для зарегистрированных пользователей), не будет доступен для Google.
Далее следует то, что Google очищает при загрузке веб-страницы, и любой контент, поддерживаемый данными, сохраненными через одну из них, не будет доступен для Google и поэтому не будет проиндексирован:

Google использует кеширование
Поисковая система активно использует кеширование, и файлы AJAX также можно найти в кеше Google; следовательно, следует убедиться, что если в файлы JS будут внесены изменения, механизм управления версиями в их URL-адресе должен использоваться, чтобы Google знал, что нужно повторно запросить файл:

Чего не делать

- Не блокируйте JS с помощью robots.txt - по понятным причинам, хотя по некоторым причинам его все еще можно увидеть на многих сайтах.

- Не используйте ссылки onclick для важного содержимого веб-страницы: как отмечалось, Google не ведет себя как пользователь; контент, для загрузки которого требуется взаимодействие с пользователем, не будет ни отображаться, ни индексироваться Google.
Пример важного контента - открытие панели инструментов навигации. Распространенная ошибка - найти панель инструментов навигации за кнопкой мыши; т.е. только когда пользователь щелкает значок меню, выполняется запрос и меню загружается. В этой ситуации Google не отображает панель инструментов со всеми вытекающими отсюда последствиями (не сканирует содержащиеся в ней ссылки и не может оценить важность веб-страниц, связанных по латеральным ссылкам).

Совет по проверке функциональности - тестирование с помощью Chrome 41: если открывающаяся панель навигации (или любой другой объект, который вы хотите проверить) находится в DOM, когда веб-страница изначально загружена, то она также будет там для Google, который может искать это по завершении начальной загрузки. В противном случае контент скрыт и требует взаимодействия с пользователем для загрузки, и Google не будет ни отображать, ни индексировать его.

- Не используйте перенаправления JS: перенаправления должны быть на уровне сервера (301); Исходя из опыта, перенаправления JS создают проблемы как с идентификацией перенаправления, так и с передачей «ссылочного сока» (несмотря на намеки Google о том, что он может с ними справиться) - перенаправления JS - это проблема, которую лучше всего не допускать без необходимости.

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

Вы можете проверить свою учетную запись Google Analytics, чтобы узнать, какая доля органического трафика на вашем сайте поступает из других поисковых систем - в разделе Приобретение> Кампании> Органические ключевые слова> Источник.

Тематическое исследование

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

Например, вот как тест Fetch as Google выглядел в учетной записи GSC клиента:

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

Вот как выглядит пример веб-страницы после исправления:

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

GSC указывает на приятное увеличение количества показов в мобильных поисковых системах для этих веб-страниц сразу после исправления:

Аналогичная тенденция наблюдается в кликах из результатов мобильного поиска для этих веб-страниц:

Естественно, это отражено и в пользовательских данных Google Analytics:

Этот тестовый пример иллюстрирует важность работы с Chrome 41.

Ресурсы

Основные ссылки для понимания предмета:

Это видео следует смотреть в первую очередь:

https://www.youtube.com/watch?v=PFwUbgvpdaQ&feature=youtu.be - официальное видео от Google по адаптации JS к поисковым системам;

с последующим-

https://www.youtube.com/watch?v=83As5qYrMno— обучающее видео Google для разработчиков о том, как создать веб-сайт на основе JS, адаптированный для Google.

Для тех, кто ищет дальнейшее чтение и обогащение / руководство / дополнительную информацию:

https://www.elephate.com/blog/ultimate-guide-javascript-seo/ - общее руководство
https://www.elephate.com/blog/chrome-41-key-to-website-rendering/— использование Chrome 41
http://www.stateofdigital.com/javascript-seo-crawling-indexing/ - отличный отчет о механизмах сканирования и поиска и проблеме с JS

https://hackernoon.com/polyfills-everything-you-ever-wanted-to-know-or-maybe-a-bit-less-7c8de164e423— объяснение полифилов
https://www.searchenginejournal.com/javascript-seo-like-peanut-butter-and-jelly-thanks-to-isomorphic-js/183337/ - - что такое изоморфность?
https://webmasters.googleblog.com/2017/12/rendering-ajax-crawling-pages.html - уведомление Google о игнорировании оставшихся фрагментов
http://www.stateofdigital.com/javascript-seo-the-definitive-resource-list/ - большая база данных по JS
https://moz.com/blog/javascript-seo - общее руководство по SEO & JS

https://www.briggsby.com/dealing-with-javascript-for-seo/ - другое превосходное общее руководство
https://www.elephate.com/blog/javascript-vs-crawl-budget-ready-player-one/ - учет влияния JS на бюджет сканирования
https://www.elephate.com/blog/everything-you-know-about-javascript-indexing-is-wrong/ - выводы, сделанные из крупнейшего исследования, проведенного по этому вопросу

http://diveinto.html5doctor.com/history.html - объяснение истории API; сосредоточив внимание на аспекте «почему»

https://universal.angular.io/ - официальный сайт Angular Universal

Похожие

Комментарии