Будьте едины с гусеничным - Pt 1 - Nrwl

1. 3 части
2. Googlebot
3. Трехчастная история Googlebot
4. Возраст серверных страниц
5. Эпоха понимания
6. Эпоха грамотности
7. Прогрессивное улучшение
8. URL и ссылки
9. Нет хэшей
10. вариации
11. onclick 👎 <a href=учреждения> 👍
12. Консоль поиска
13. Правильные роботы
14. Быть быстрым
15. Как Googlebot сканирует

Джефф Кросс является соучредителем nrwl.io , предоставляя Angular консалтинг для корпоративных команд. Ранее он работал в основной группе Angular в Google, возглавляя команду Angular Mobile.

Googlebot

3 части

Это первая из трех статей о том, как Googlebot делает приложения Angular понятными и индексируемыми. В этой статье мы рассмотрим краткую историю развития способности робота Googlebot сканировать приложения JavaScript и расскажем о некоторых лучших практиках, которые применимы к приложениям JavaScript в целом. Во 2-й и 3-й частях будут рассмотрены специфические для Angular аспекты и полезные инструменты.

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

Googlebot

SEO это широкая тема. Эта статья посвящена одному аспекту SEO: сканированию. Я сосредотачиваюсь только на одном сканере, Googlebot (сканере Google), и я сосредоточен только на сканировании приложений JavaScript и Angular. Под сканированием я подразумеваю процесс навигации, загрузки и анализа страниц роботом Google. Я не буду освещать вопросы индексации, ранжирования или других забавных тем.

Трехчастная история Googlebot

Пред-2009 (Возраст серверных страниц), 2009–2015 (Возраст автоматизированного понимания), 2015+ (Возраст грамотности)

Возраст серверных страниц

До 2009 года разработчики просто соглашались с тем, что если они используют jQuery, Backbone или другие библиотеки JS для отображения своих приложений в браузере, поисковые системы не смогут понять их содержание. Таким образом, страницы должны быть отображены на сервере в некоторой форме, а затем могут быть улучшены с помощью JavaScript в браузере. По мере того, как структуры JavaScript начали совершенствоваться и использоваться для создания целых приложений, «одностраничных приложений», Google обнаружил необходимость предоставить разработчикам способ инструктировать сканер о содержании их приложений.

Эпоха понимания

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

На сегодняшний день сайт документации AngularJS реализует этот протокол. Если вы посетите https://docs.angularjs.org/api/ng/function/angular.bind , вы увидите нормальную страницу.

Снимок экрана https://docs.angularjs.org/api/ng/function/angular.bind

Но если вы измените URL-адрес, чтобы включить _escaped_fragment_ , https://docs.angularjs.org/ ? _escaped_fragment_ = api / ng / function / angular.bind вы увидите тот же контент в гораздо более простой, не стилизованной форме, без JavaScript, чтобы сканер мог легко понять содержимое страницы.

Снимок экрана https://docs.angularjs.org/?_escaped_fragment_=api/ng/function/angular.bind

В октябре 2009 года Googlebot расширял свои возможности по обработке и анализу JavaScript-приложений. Предоставляя параметр _escaped_fragment_, разработчики могут помочь сканеру больше уверенности в содержании динамических страниц.

Эпоха грамотности

Перейдя к октябрю 2015 года, робот Google стал гораздо более продвинутым в области навигации и анализа приложений JavaScript. Поисковая команда объявлено в блоге Google для веб-мастеров что предыдущее предложение об использовании _escaped_fragment_ устарело. Сканер достаточно развился, чтобы можно было уверенно и последовательно сканировать одностраничные приложения JavaScript.

Так что, с улучшениями в сканере, могут ли разработчики JavaScript просто разрабатывать приложения как обычно, не беспокоясь о возможности сканирования? Как правило, да, но не без некоторых оговорок, оговорок и звездочек. Чтобы помочь прояснить текущие рекомендации по обеспечению возможности сканирования приложений JavaScript, Джон Мюллер из Google опубликовано в Google+ с некоторыми краткими предложениями. Джон также представлен на ту же тему на AngularConnect 2016 вдаваясь в некоторые подробности, чем его пост в Google+, но повторяя многие из тех же пунктов. Я предложу свое резюме поста и презентации.

Прогрессивное улучшение, URL и ссылки, консоль поиска, правильные роботы, будь быстрым

Прогрессивное улучшение

Браузер, используемый сканером для визуализации приложений JavaScript, не обладает всеми функциями Chrome и других современных браузеров. По состоянию на выступлении Джона в сентябре 2016 года, некоторые не поддерживаемые API включают ServiceWorker, Fetch, Promise, requestAnimationFrame и localStorage. Большинство приложений, вероятно, уже заполнены большинством из них, или, по крайней мере, имеют запасной вариант. Если какой-либо из этих API-интерфейсов используется для визуализации содержимого страницы, важно, чтобы страница корректно проваливалась и могла по-прежнему отображать контент в их отсутствие.

URL и ссылки

Канонические URL

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

Нет хэшей

У Google также есть сильный уклон против URL, которые используют хеш (/ # /) внутри путей. Если Google видит ссылки, содержащие хэш, он предполагает, что содержимое после хеша незначительно. Google редко индексирует URL с помощью хэшей.

вариации

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

onclick 👎 <a href=учреждения> 👍

Робот Googlebot не рассматривает обработчики кликов как ссылки, поэтому важно, чтобы ссылки на контент были представлены в атрибуте href якорных элементов.

Консоль поиска

Консоль поиска Google предоставляет критически важный инструмент для управления и мониторинга отношений сайта с индексом Google. Для разработчиков JavaScript следует отметить Просмотреть как Google инструмент. «Получить как Google» позволяет разработчикам запрашивать, чтобы робот Google загружал страницу, а затем отображает некоторые характеристики этой страницы в том виде, в каком ее видел Google. Разработчики JavaScript захотят нажать кнопку «Выбрать и отобразить», после чего робот Google будет отображать приложение JavaScript. По завершении сканирования отобразится снимок экрана с отображаемой страницей.

Получить как Google скриншот nrwl.io

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

Правильные роботы

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

Быть быстрым

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

Как Googlebot сканирует

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

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

Джефф Кросс является соучредителем Nrwl - Предприятие Angular Consulting.

Похожие

Комментарии