SEO для приложений JavaScript, издание 2016 года

1. Схема сканирования Ajax
2. Prerender.io

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

Традиционно сканеры поисковых систем смотрели только на необработанный текстовый контент, содержащийся в теле ответа HTTP, и на самом деле не интерпретировали то, что интерпретировал бы типичный браузер с JavaScript. Когда страницы с большим количеством контента, отображаемого с помощью JavaScript, начали появляться, Google начал сканировать и индексировать его еще в 2008 году, но довольно ограниченным образом. Схема сканирования Ajax до сих пор было стандартным, хотя и неуклюжим решением этой проблемы. Google вкладывает много работы в более элегантный подход к лучше понимать веб-страницы и, наконец, 14 октября 2015 года они официально объявили, что Схема сканирования AJAX устарела , Своими словами:

Мы больше не рекомендуем предложение по сканированию AJAX, которое мы сделали еще в 2009 году.

Больше никаких непредсказуемых попыток сканирования минимального масштаба. Это официально, теперь они должны поддержать все это. В конце концов, [некоторые подробные и всесторонние тесты, сделанные почти год назад] (( http://searchengineland.com/tested-googlebot-crawls-javascript-heres-learned-220157 ) показал, что Google теперь может обрабатывать JavaScript как никогда, включая перенаправления, ссылки, динамически вставляемый контент, метаданные и элементы страницы. Так что [можем ли мы доверять Google] (( http://searchengineland.com/can-now-trust-google-crawl-ajax-sites-235267 ) полностью сканировать Ajax-сайты? К сожалению, ответ - нет, по крайней мере, пока.

Согласно нашему опыту, хотя большая часть функций на основе JavaScript теперь понимается роботом Googlebot, он постоянно не может сканировать контент, извлеченный API XMLHttpRequest из внешнего источника - или что-либо построенное поверх или связанное с этим API. Такое поведение присутствует в чистом JavaScript, jQuery, AngularJS или других современных средах JavaScript. Всякий раз, когда вам нужно извлечь контент из «внешнего» URL-адреса или вызвать конечную точку API REST для получения некоторых данных, есть вероятность, что они не будут сканироваться и индексироваться должным образом. Это приводит к огромным последствиям для приложений, работающих с любым видом Backend-as-a-Service (BaaS) или подобной инфраструктурой. Для решения этой проблемы потребуется рендеринг на стороне сервера, и хотя он поддерживается в некоторых средах JavaScript (например, реагировать ), нам нужно универсальное решение, пока оно не станет широко доступным.

Вот пример. Взгляните на один из самых простых Стартовые комплекты блога Baasic , Он построен с использованием AngularJS и извлекает список сообщений блога из нашего API, отображая его в виде простого макета. Кажется, все в порядке, не так ли?

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

Статическое содержимое самой страницы индексируется, но динамически генерируемый материал отсутствует - вот доказательство тому:

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

Схема сканирования Ajax

Google и другие продвинутые поисковые системы поддерживают формат URL hashbang (! #), Который был оригинальным методом создания постоянных ссылок для приложений JS. Всякий раз, когда сканер видит URL-адрес, содержащий хэш-банг -

http://www.site.com/#!/some/page

это преобразует URL в

http://www.site/?_escaped_fragment_=/some/page

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

Более новый HTML5 PushState не работает так же, так как он изменяет URL и историю браузера. Если вы используете pushState, вы должны использовать следующий тег в заголовке ваших страниц:

<meta name = "фрагмент" content = "!">

Это говорит роботу Google о повторном посещении сайта с помощью фрагмента ? _Escaped = в URL.

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

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

Мы решили запустить выделенную службу предварительного рендеринга на наших собственных серверах, используя Prerender.io.

Prerender.io

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

Если вы обслуживаете свои приложения из ASP.NET, промежуточное ПО может быть простым модулем HTTP , Тем не менее, мы обычно выбираем подход, который использует правила перезаписи URL. Его можно использовать с Apache, Nginx или любым другим сервером - актуальные пакеты и инструкции можно загрузить с Вот ,

Теперь нам нужно установить сервис Prerender.io на наших серверах. Его исходный код находится в свободном доступе, но документация по установке немного лаконична. Мы проведем вас через этот процесс в следующем посте. А пока, пожалуйста, поделитесь своим опытом со стратегиями SEO для приложений JavaScript.

Похожие

Комментарии