что это такое, влияние технологии на SEO

AJAX (от английского Asynchronous Javascript and XML) — это технология динамической подгрузки данных на сайте, например для бесконечной загрузки контента на главной или другой странице. Характерный маркер AJAX — непрерывная подгрузка контента. Простыми словами, AJAX — обновление страницы без ее перезагрузки.

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

Схематичное представление стандартных веб-приложений и AJAX-приложений. Источник иллюстрации: Wikipedia

По сравнению с другими веб-технологиями, AJAX сравнительно молод: впервые о нем как о самостоятельном подходе к формированию интерфейсов веб-приложений заговорили в 2005 году. Автором технологии принято считать Джесси Джеймса Гаррета.

Читайте также:

Сайты с WWW или без WWW: что лучше для SEO?

Как устроен AJAX технически

В AJAX используется несколько технологий: подход Dynamic HTML для постоянного изменения содержания веб-страницы и сразу несколько технологий динамического обращения к серверу. В частности, динамическая генерация тегов img и script и динамическая генерация побочных фреймов.

Что касается форматов данных, то для их передачи в AJAX можно использовать XML, стандартный текст, JSON и стандартный HTML.

AJAX и SEO: проблемы с индексированием

Может ли Google сканировать AJAX-контент? Короткий ответ: да, может. Более длинный ответ — да, но краулерам делать это сложнее. Одностраничные веб-приложения, использующие фреймворки AJAX, исторически были очень проблематичными с точки зрения SEO. Вот их основные недостатки:

• Проблемы со сканированием. Важный для краулеров контент был скрыт внутри JavaScript, который отображался только на стороне клиента, а это означало, что роботы Google, по сути, видели пустой экран.
• Проблемы с панелью навигации (Кнопка «Назад» не работает в браузере или работает некорректно).
• Маскировка. При AJAX-подходе вебмастеры создавали две версии контента. Первую — для пользователя, вторую — для поисковых систем. А это запрещено и карается санкциями.

Читайте также:

Что такое контент: виды, форматы, критерии качества

В течение многих лет Google советовал вебмастерам использовать соответствующую схему сканирования AJAX — чтобы сообщать краулерам о том, что на сайте есть AJAX-контент. Схема сканирования AJAX с использованием параметра _escaped_fragment позволяла Google получать предварительно обработанную версию страницы.

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

Выдержка из справки «Центра Google Поиска» касательно AJAX

Все изменилось в 2015 году. Google объявил, что теперь его краулеры научились сканировать, читать и анализировать контент внутри JavaScript без каких-либо проблем, что сделало применение схемы сканирования AJAX с параметром _escaped_fragment устаревшей.

Читайте также:

Robots.txt: что это, как создать и правильно настроить

Что происходит с индексацией AJAX-страниц в 2022 году

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

Действительно, Google может индексировать динамический AJAX-контент. Но есть неочевидные моменты:

• Скрытый HTML. Если важный контент спрятан внутри JavaScript, краулерам может будет сложнее получить к нему доступ. Индексирование (и последующее ранжирование) может быть искусственно приостановлено. Чтобы избежать этого, убедитесь, что важный для пользователя контент хранится в формате HTML. В этом случае краулеры Google и «Яндекс» легко его проиндексируют.
• Отсутствующие ссылки. Google использует внутренние ссылки в качестве сигнала для установления связи между страницами сайта. А внешние ссылки — как один из факторов ранжирования. Другими словами, когда контент качественный, экспертный — на него ссылаются другие трастовые домены. Очень важно, чтобы ссылки на сайте были доступны для краулеров и не скрывались внутри JavaScript.

Об индексации Google мы также писали в статье «9 причин, почему Google не индексирует сайт».

Как AJAX влияет на SEO

Получается, соблюдая вышеуказанные условия, можно совсем не беспокоиться об индексации AJAX-контента?

Для этого вернемся в прошлое и найдем официальный ответ Google, данный по этому поводу:

«… пока вы не блокируете Googlebot от сканирования JavaScript или CSS, Google будет отображать ваши страницы в результатах поиска».

Формулировка несколько туманная, но суть ясна. Google как бы говорит: «Это не наша проблема, а ваша». Таким образом, в 2022 году больше не нужно использовать обходные пути и «костыли», чтобы дать понять Google, где AJAX-контент, а где — обычный. Он умеет сканировать его и самостоятельно.

Google активно выступает за контент и пользовательский опыт. AJAX-контент несколько противоречит этому подходу: взять хотя бы некорректный URL-адрес страницы, который формируется при таком подходе. А для краулеров это важно: URL должен отражать реальное расположение страницы!

Чтобы решить проблему с URL-страниц при AJAX-подходе, нужно использовать History API с функцией pushState(). Она меняет URL, который выводится на стороне клиента.

Использование pushState позволяет сохранить AJAX-контент на сайте и решает проблему некорректного URL-страницы.

Читайте также:

Отличия SEO под Яндекс и Google

Еще одна вещь, на которую Google обращает внимание в 2022 году — это hashbang (#!).

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

Как сделать AJAX-контент доступным для Google и «Яндекса»

Вот еще несколько советов, которые помогут сделать AJAX-страницы и AJAX-контент доступными для поисковых систем. Вот что нужно сделать:

• Оптимизировать структуру URL. Настоятельно рекомендуем использовать метод History API c pushState вместо протокола_escaped_fragment (который уже устарел, как мы помним).

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

• Оптимизировать скорость сайта. Когда браузер на стороне клиента создает DOM (интерфейс программирования приложений) — велика вероятность генерации раздутого кода внутри HTML.
  Такой код снизит скорость загрузки страницы и, следовательно, затруднит работу краулеров Google и «Яндекса». А вы помните, что у них, ко всему прочему, существуют еще и лимиты по количество обращений к сайту при сканировании, так называемый Crawl Budget?

Краулинговый бюджет — лимит поискового робота по количеству обращений к определенному домену.

Так что убедитесь, что вы удалили все ресурсы, блокирующие рендеринг, чтобы Google мог эффективно анализировать CSS на странице и все использующиеся скрипты.

Технический аудит сайта

• Наличие дублей страниц, безопасность, корректность всех технических параметров: переадресаций, robots.txt, sitemap.xml скорость загрузки и др.
• Техническая оптимизация — один из основных этапов в продвижении.

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

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

Используйте функцию History API и все советы, которые мы дали выше: так вы застрахуете свой сайт от проблем с индексацией и сможете использовать все достоинства технологии без страха санкций. А prerender поможет убедиться, что AJAX-контент доступен при каждом обращении Googlebot’а.

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

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

Почему у поисковых систем возникали серьезные сложности при попытке индексации сайтов с AJAX? Чтобы ответить на этот вопрос, необходимо рассмотреть то, как именно происходит взаимодействие клиента с сервером.

Читайте также:

Как составить грамотное ТЗ на создание сайта: примеры и частые ошибки

Последовательность обращения к серверу: стандартный и AJAX

Стандартный подход к построению интерфейса веб-приложения подразумевает следующую последовательность взаимодействия клиента и сервера:

1. Пользователь открывает страницу сайта.
2. Происходит взаимодействие с каким-либо элементом на странице.
3. При соответствующем клике браузер создает HTTP-запрос.
4. Сформированный HTTP-запрос посылается на сервер.
5. Сервер создает новую версию страницы.
6. Браузер получает соответствующий запрос и перезагружает первоначальную версию веб-страницы, чтобы вывести страницу с изменениями.

AJAX же подход подразумевает совсем иную последовательность взаимодействия клиента и сервера:

1. Пользователь открывает страницу сайта.
2. Происходит взаимодействие с каким-либо элементом на странице.
3. Скрипт на сайте идентифицирует тип данных, который требуется для получения обновленной версии веб-страницы.
4. Браузер или иной веб-клиент посылает внутри HTTP-запроса необходимый тип данных.
5. Сервер отвечает, возвращая документ не целиком, а только ту его часть, которая необходима для обновления страницы
6. Скрипт на сайте видоизменяет содержимое страницы с учетом данных полученных в HTTP-запросе, который пришел с сервера.

Читайте также:

11 устаревших практик SEO продвижения, которых стоит избегать

Достоинства AJAX

AJAX-подход особенно ценен для медиаконтента. Если на сайте используется видео- или аудиоплеер, то AJAX позволяет транслировать поток непрерывно. Эта технология используется такими крупными проектами, как SoundCloud, Last.fm, YouTube, Vimeo.

YouTube до сих пор использует AJAX-подход на всех страницах сервиса

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

1. Пользователь не может загружать большие объемы трафика. Сайты, созданные целиком на AJAX, загружаются гораздо быстрее и экономят пользовательский трафик.
2. Вебмастер хочет внедрить окно с динамическими данными. Например, сделать показ остатка товара в интернет-магазине или окно с подсказками. AJAX идеален для вывода подобных данных. Контент при этом выводится мгновенно, без задержек или подгрузок. AJAX позволяет добавить автозаполнение без перезагрузки страницы
3. Вебмастер столкнулся с перегруженностью сервера. В большинстве случаев AJAX позволяет существенно снизить нагрузку сайта, создаваемую на сервер . Дело в том, что подгружается только измененная часть страницы или даже голый набор данных, который позже изменяется за счет скрипта.

Продвижение сайта по трафику

• Приводим целевой трафик с помощью огромного семантического ядра.
• Рассчитайте стоимость продвижения с помощью онлайн-калькулятора.

Недостатки AJAX

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

Ajax Load More — плагин бесконечной прокрутки для ленивой загрузки сообщений, отдельных страниц и постов, комментариев с помощью запросов на основе Ajax

О том, как избежать вышеуказанных проблем, мы уже говорили в разделе «AJAX и SEO». А вот еще несколько недостатков AJAX для вебмастера:

• URL страницы не отражает ее реальное расположение внутри сайта.
• Посещение AJAX-страниц может не фиксироваться веб-аналитикой. Дело в том, что браузер не записывает их в качестве посещенных в силу технических особенностей взаимодействия цепочки «клиент-сервер», которые мы уже описывали в начале.
• Не весь AJAX-контент может быть проиндексирован.
• JS должен быть активирован в браузере. Очень косвенный недостаток, так как сегодня без включенного JavaScript вы просто не откроете ни один современный сайт.
• У пользователя недоступна браузерная функция «Назад».
• Краулерам может показываться содержание страницы, которое не увидят пользователи. По правилам поисковых систем это серьезное нарушение:

Google прямо запрещает манипулировать содержанием страницы

Присоединяйтесь к нашему Telegram-каналу!

• Теперь Вы можете читать последние новости из мира интернет-маркетинга в мессенджере Telegram на своём мобильном телефоне.
• Для этого вам необходимо подписаться на наш канал.

Резюме. Правильный AJAX для SEO

Чтобы подытожить все вышесказанное и не запутаться, вот главные выводы:

1. Google и «Яндекс» в 2022 году умеют индексировать AJAX-контент. Но в особо сложных технических случаях индексация AJAX-страниц действительно может быть затруднена. Решить эти проблемы, а также внедрить инструменты на основе AJAX помогут плагины независимых разработчиков для вашей CMS. Огромная часть плагинов для WordPress так или иначе связана с AJAX-подходом
2. Если никакие способы не помогают вашему сайту и AJAX-контент ПС упорно не видят — настройте prerender. Этот способ гарантирует, что краулеры будут видеть HTML-код страницы даже при активном AJAX. Внедрить prerender не составит никакой сложности: для популярных CMS доступны плагины сторонних разработчиков.
3. После выполнения всех вышеуказанных действий заново сгенерируйте или обновите XML-карту. Так вы значительно облегчите задачу краулерам.

Создание сайтов

• Разработка эффективных сайтов для продаж в интернете.
• Создаем сайты с нуля любой сложности, от сайтов визиток до интернет-магазинов и крупных порталов.

javascript — Индексация AJAX сайтов

Вопрос задан 9 лет 2 месяца назад

Изменён 7 лет 3 месяца назад

Просмотрен 2k раз

Я уже читал о индексации AJAX сайтов на Yandex Help и GoogleSupport, но у меня структура уже не позволяет делать глобальные изменения.

Если я сделаю определение USER_AGENT на GoogleBot или YandexBot(названия могут быть не точными), в PHP скриптах, и подменю полностью сайт на HTML версию, будут ли мои ссылки индексироваться и появляться в поисковике?

• ajax
• javascript
• google
• яндекс
• php

3

Чтобы обеспечить индексацию SPA (Sinlge Page Apps), лучше всего использовать изоморфные решения. Это такие фреймворки/библиотеки, которые умеют строить страницы как на клиенте, так и на сервере. Лучший вариант сейчас — это React.js + Flux, и хорошей альтернативой в будущем будет Angular2.

Поставили как то задачу чтобы музыка беспрерывно на сайте звучала. Также с помощью AJAX’а были созданы переходы по сайту. Для индексации поисковыми ботами создали дублирующий контроллер который выдавал страницы в зависимости от GET данных. Создали sitemap для индексации поисковыми ботами. В итоге при заходе бота по любой ссылке из sitemap, выдавался соответствующий контент. При переходе из поисковой выдачи, пользователь попадал на нужную страницу, а дальше уже через AJAX совершал переходы по сайту. Более подробно рассказать не смогу так как такую систему создавать придётся в зависимости от имеющегося кода.

Зарегистрируйтесь или войдите

Регистрация через Google

Регистрация через Facebook

Регистрация через почту

Отправить без регистрации

Почта

Необходима, но никому не показывается

Отправить без регистрации

Почта

Необходима, но никому не показывается

Нажимая на кнопку «Отправить ответ», вы соглашаетесь с нашими пользовательским соглашением, политикой конфиденциальности и политикой о куки

Подходит ли AJAX для SEO? Анализ и советы по индексации Google

30 июня 2021 г. • SEO

Мир веб-разработки прошел долгий путь с момента изобретения Всемирной паутины.

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

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

Подходит ли AJAX для SEO? Как заставить Google и другие поисковые системы правильно сканировать и индексировать ваш веб-сайт AJAX? Мы рассмотрим эти вопросы и дадим некоторые рекомендации.

Что такое AJAX?

Чтобы понять, почему AJAX так проблематичен для SEO-команд и владельцев веб-сайтов, полезно понять, что такое AJAX и что он делает.

AJAX означает асинхронный JavaScript и XML. Это протокол, который позволяет браузеру отправлять HTTP-запросы к серверам без необходимости обновлять страницу.

AJAX может отправлять и получать информацию в:

• JSON
• XML
• HTML
• Текстовые файлы

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

AJAX, тем временем, асинхронно загружает JavaScript между вами и сервером в фоновом режиме и извлекает новый контент в реальном времени после загрузки страницы. Вместо того, чтобы загружать данные через HTTP через строку URL, AJAX использует XMLHttpRequest для обновления отдельных частей страницы, в то время как страница в целом остается интерактивной.

Представьте, как работает лента Twitter. Вы подписаны на любое количество людей, которые, вероятно, твитят несколько раз в день. Обычно на это указывает кнопка «Загрузить больше твитов» вверху или внизу ленты.

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

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

Тем не менее, у AJAX есть свои подводные камни.

Является ли AJAX SEO дружественным

Может ли Google сканировать контент AJAX? Короткий ответ: да. Длинный ответ — да, но это немного сложнее.

Одностраничные веб-приложения, использующие фреймворки AJAX, исторически были очень проблематичными с точки зрения SEO и вызывали такие проблемы, как:

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

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

Потом все изменилось. В 2015 году Google объявил, что Google теперь в целом может сканировать, читать и анализировать JavaScript без каких-либо проблем, что сделало схему сканирования AJAX устаревшей. Это был момент, когда Google вместо этого начал рекомендовать решения для динамического рендеринга.

SEO-проблемы, которые могут возникнуть при использовании AJAX

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

Вот некоторые из вещей, которые могут пойти не так:

Скрытый HTML

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

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

Отсутствующие ссылки

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

По этой причине очень важно, чтобы все ваши ссылки были читабельными и не скрывались под AJAX JavaScript.

Как AJAX влияет на поисковую оптимизацию

Значит ли это, что вам не нужно беспокоиться о том, сможет ли Google просканировать ваш веб-сайт AJAX? Не обязательно.

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

Если мы посмотрим на точную формулировку отказа Google от схемы сканирования AJAX, она гласит:

«… пока вы не блокируете робота Googlebot от сканирования ваших файлов JavaScript или CSS, мы можем вообще в состоянии отображать и понимать ваши веб-страницы, как современные браузеры».

Рабочее слово здесь обычно . По сути, это способ Google замести следы, пожимая плечами, когда дело доходит до веб-сайтов AJAX, и говоря: «Это не наша проблема».

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

Итак, какие теперь правила?

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

Одним из способов соблюдения этих стандартов является использование History API с функцией pushState(), которая изменяет путь URL-адреса, отображаемого в адресной строке на стороне клиента.

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

Еще одна вещь, на которую сейчас обращает внимание Google, — это разметка, известная как #!, или разметка «hashbang».

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

Как сделать свой веб-сайт AJAX доступным для сканирования

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

Некоторые вещи, на которые следует обратить внимание, включают:

Оптимизация структуры URL

Настоятельно рекомендуется использовать pushState History API вместо протокола _escaped_fragment. Функция обновляет URL-адрес в адресной строке, чтобы любой контент JavaScript отображался без проблем.

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

Оптимизировать скорость веб-сайта

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

Веб-сайты AJAX могут работать на вас

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

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

А еще лучше используйте Prerender, чтобы убедиться, что ваш веб-сайт AJAX беспрепятственно сканируется каждый раз, когда Google посещает ваш веб-сайт.

Подпишитесь на демо-версию сегодня и получите рейтинг своего AJAX-сайта в поисковой выдаче без каких-либо хлопот и головной боли.

Как JavaScript и AJAX влияют на индексацию в Google?

Автор: Ramón Saquete

Содержание

• 1 Проблемы CSR при начальной загрузке страницы
  • 1.1 Проблемы в результате медленного рендеринга
  • 1.2 Проблемы с индексацией:

  900 проблемы с CSR переход на следующую страницу

  • 2. 1 Проблемы с индексированием
  • 2.2 Что происходит с фрагментами теперь, когда Google может индексировать AJAX?
  • 3 Блокировка индексации частичных ответов через AJAX
  • 4 Заключение

  Со временем Google значительно улучшил индексацию JavaScript и AJAX . Вначале он ничего не индексировал и не переходил ни по каким ссылкам, появляющимся в контенте, загруженном через эти фреймворки. Но затем мало-помалу он начал индексировать некоторые реализации и улучшать свои возможности. В настоящее время он может индексировать множество различных реализаций и переходить по ссылкам, загружаемым через AJAX или API Fetch . Тем не менее все еще будут случаи, когда это может не сработать .

  Чтобы проанализировать случаи, когда Google может не индексировать наш сайт, сначала нам нужно понять концепцию рендеринга на стороне клиента (CSR). Это означает, что HTML-код нарисован на стороне клиента с помощью JavaScript , обычно с использованием AJAX в избытке. Первоначально веб-сайты всегда отображали HTML на стороне сервера ( Server Side Rendering или SSR), но с некоторых пор CSR стал популярным с появлением фреймворков JavaScript, таких как Angular, React и Vue 9.0016 . Однако CSR отрицательно влияет на индексацию , производительность рендеринга веб-сайтов и, следовательно, на SEO .

  Как мы уже объясняли ранее, для обеспечения индексации во всех поисковых системах и ситуациях , помимо достижения хорошей производительности, лучшим решением является использование универсального фреймворка , так как с этими мерами мы получим что-то под названием Гибридный рендеринг . Он заключается в прорисовке веб-сайта на сервере при первой загрузке, а затем на клиенте с помощью JavaScript и AJAX, когда навигация переходит к ссылкам, следующим за . Хотя на самом деле существует больше ситуаций, когда использование термина «гибридный рендеринг» также допустимо.

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

  Проблемы CSR при первоначальной загрузке страницы

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

  Проблемы в результате медленного рендеринга

  Процесс индексации Google проходит следующие этапы:

  1. Сканирование : Googlebot запрашивает URL-адрес на сервере.
  2. Первая волна индексации : он мгновенно индексирует контент, созданный на сервере, и получает новые ссылки для сканирования.
  3. Генерирует нарисованный HTML на стороне клиента, запуская JavaScript . Этот процесс требует значительных вычислительных ресурсов (это можно сделать сразу или даже занять несколько дней, ожидая получения необходимых для этого ресурсов).
  4. Вторая волна индексации : с отрисовкой HTML на стороне клиента оставшееся содержимое индексируется, и получаются новые ссылки для обхода.
  Как работает Googlebot. Источник: https://www.youtube.com/watch?v=PFwUbgvpdaQ&feature=youtu.be&t=14m21s

  Помимо того факта, что для полного индексирования страниц может потребоваться больше времени, что приведет к задержке индексации последующих страниц, связанных с ними, если рендеринг страницы выполняется медленно, средство визуализации робота Googlebot может оставлять незакрашенные части . Мы проверили это с помощью параметра «Просмотреть как Google», предоставленного Google Search Console , и созданный им снимок экрана не рисует ничего, что занимает более 5 секунд для отображения. Однако он генерирует HTML, который занимает больше времени, чем эти 5 секунд. Чтобы понять, почему это происходит, мы должны иметь в виду, что Средство визуализации Google Search Console сначала создает HTML-код, запускающий JavaScript, с помощью средства визуализации Googlebot, а затем закрашивает пиксели страницы . Первая задача — та, которую необходимо учитывать для индексации, к которой мы относим термин CSR. В Google Search Console мы видим HTML-код, сгенерированный во время первой волны индексации, а не тот, который был сгенерирован средством визуализации Googlebot .

  В Google Search Console мы не видим HTML-код, нарисованный с помощью JavaScript, запускаемый роботом Googlebot 🕷 и используемый на последнем этапе индексации. Для этого мы должны использовать этот инструмент: https://search.google.com/test/mobile-friendly 😲Нажмите, чтобы твитнуть

  https://search.google.com/test/mobile-friendly

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

  1. HTML загружается и обрабатывается для запроса связанных файлов и создания DOM .
  2. CSS загружается и обрабатывается, для запроса связанных файлов и создания CSSOM .
  3. JavaScript загружен, скомпилирован и запущен для запуска AJAX-запросов .
  4. Запрос AJAX перемещается в очередь запросов и ожидает ответа вместе с другими запрошенными файлами.
  5. Запущен AJAX-запрос , который должен пройти по сети на сервер.
  6. Сервер отвечает на запросы через сеть, и наконец, нам нужно дождаться запуска JavaScript, чтобы отрисовать содержимое HTML-шаблона страницы .

  Время запроса и загрузки процесса, который мы только что описали, зависит от загрузки сети и сервера в это время . Более того, Googlebot использует только HTTP/1.1 , что медленнее, чем HTTP/2, потому что запросы обрабатываются один за другим, а не все одновременно. Необходимо, чтобы и клиент, и сервер разрешали использование HTTP/2, поэтому Googlebot будет использовать только HTTP/1.1, даже если наш сервер разрешает HTTP/2 . Подводя итог, это означает, что Googlebot ждет завершения каждого запроса, чтобы запустить следующий, и, возможно, он не будет пытаться распараллелить определенные запросы, открывая различные соединения, как это делают браузеры (хотя мы точно не знаем, как это происходит). Имеет ли это). Таким образом, мы находимся в ситуации, когда мы можем превзойти эти 19 секунд, которые мы оценили ранее как .

  Представьте, например, что с запросами изображений, CSS, JavaScript и AJAX запускается более 200 запросов, каждый из которых занимает 100 мс. Если запросы AJAX отправляются в конец очереди, мы, вероятно, превышает время, необходимое для индексации их содержимого .

  С другой стороны, из-за этих проблем с производительностью CSR, мы получим худшую оценку по показателю FCP (First Contentful Paint) в PageSpeed ​​с точки зрения рендеринга и его WPO, и, как следствие, худший рейтинг .

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

  Проблемы с индексированием:

  При индексировании контента, нарисованного на стороне клиента, Googlebot может столкнуться со следующими проблемами, которые препятствуют индексированию HTML-кода, сгенерированного JavaScript.

• Они используют JavaScript API , не распознанный роботом Googlebot (в настоящее время мы знаем, что веб-сокеты, WebGL, WebVR, IndexedDB и WebSQL не поддерживаются — дополнительная информация доступна на странице https://developers.google.com/search/docs/guides). /рендеринг).
• Файлы JavaScript заблокированы robots.txt .
• Файлы JavaScript обслуживаются через HTTP, в то время как веб-сайт использует HTTPS .
• Есть ошибки JavaScript .
• Если приложение запрашивает разрешение пользователя на что-то, и от этого зависит рендеринг основного контента, то оно не будет отрисовываться, потому что Googlebot по умолчанию отклоняет любое запрашиваемое им разрешение.

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

Мы должны иметь в виду, что в HTML , сгенерированном предыдущим инструментом, все метаданные (включая канонический URL) будут игнорироваться роботом Googlebot, поскольку он принимает во внимание информацию только тогда, когда она отображается на сервере .

Проблемы CSR с переходом на следующую страницу

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

Проблемы с индексацией

В отличие от CSR при начальной загрузке, переход на следующую страницу с переключением основного контента через JavaScript выполняется быстрее, чем SSR . Но у нас будут проблемы с индексацией, если:

• Ссылки не имеют действительного URL-адреса, возвращающего 200 OK в атрибуте href .
• Сервер возвращает ошибку при прямом доступе к URL-адресу без JavaScript или с включенным JavaScript и удалении всех кешей . Будьте осторожны с этим: если мы перейдем на страницу, нажав на ссылку, может показаться, что она работает, потому что она загружается JavaScript. Даже при прямом доступе, если веб-сайт использует Service Worker, веб-сайт может имитировать правильный ответ, загружая свой кэш. Но Googlebot — это поисковый робот без сохранения состояния, поэтому он не принимает во внимание кеш Server Worker или любые другие технологии JavaScript, такие как локальное хранилище или хранилище сеансов, поэтому он получит сообщение об ошибке.

Кроме того, чтобы веб-сайт был доступен, URL-адрес должен измениться с помощью JavaScript с API истории .

Что происходит с фрагментами теперь, когда Google может индексировать AJAX?

Фрагменты — это часть URL-адреса, которая может стоять в конце, перед которой ставится решетка # . Например:

 http://www.humanlevel.com/blog.html#example 

Этот тип URL-адресов никогда не достигает сервера , они управляются только на стороне клиента. Это означает, что при запросе вышеуказанного URL-адреса на сервер он получит запрос «http://www.humanlevel.com/blog.html», а в клиенте браузер прокрутит до фрагмента документа, который упоминается. Это обычное и изначально предполагаемое использование для этих URL-адресов , широко известных как привязки HTML . А анкором, на самом деле, является любая ссылка (тег «а» в HTML происходит от анкора ). Однако в прежние времена фрагменты также использовались для изменения URL-адресов через JavaScript на загруженных AJAX страницах , чтобы позволить пользователю перемещаться по истории просмотров. Это было реализовано таким образом, потому что тогда фрагмент был единственной частью URL, которую мы могли изменить с помощью JavaScript, поэтому разработчики воспользовались этим, чтобы использовать их не по назначению. Это изменилось с появлением API-интерфейса истории, поскольку он позволял изменять весь URL-адрес с помощью JavaScript.

Раньше, когда Google не мог индексировать AJAX, если URL-адрес изменял свое содержимое через AJAX на основе части фрагмента, мы знали, что он будет индексировать только URL-адрес и содержимое без учета фрагмента. Итак… что происходит со страницами с фрагментами теперь, когда Google может индексировать AJAX? Поведение точно такое же. Если мы свяжем страницу с фрагментом, и она изменит свое содержимое при доступе через фрагмент, она проиндексирует содержимое, игнорируя фрагмент, и популярность пойдет на этот URL , потому что Google надеется, что фрагмент будет использоваться в качестве привязки, а не для изменения содержимого, как следует.

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

Блокировка индексации частичных ответов через AJAX

Когда запрос AJAX отправляется на URL-адресов REST или GraphQL API , нам возвращается JSON или часть страницы, которую мы не хотим индексировать . Поэтому мы должны заблокировать индексацию URL-адресов, на которые направлены эти запросы .

Раньше мы могли заблокировать их с помощью robots.txt , но с тех пор, как появился рендерер Googlebot, мы не можем заблокировать какой-либо ресурс, используемый для рисования HTML.

В настоящее время Google немного умнее, и он обычно не пытается индексировать ответы с помощью JSON, но если мы хотим убедиться, что они не будут проиндексированы, универсальное решение, применимое ко всем поисковым системам, заключается в следующем: сделать так, чтобы все URL-адреса, используемые с AJAX, принимали только запросы, сделанные с помощью метода POST , поскольку он не используется поисковыми роботами. Когда запрос GET достигает сервера, он должен возвращать ошибку 404. С точки зрения программирования это не заставляет нас удалять параметры из QueryString URL.

Существует также возможность добавления HTTP-заголовка «X-Robots-Tag: noindex» (придуманный Google) к ответам AJAX или чтобы эти ответы возвращались с кодом 404 или 410. Если мы используем эти методы для загруженного контента непосредственно из HTML, он не будет проиндексирован, как если бы мы заблокировали его через файл robots.txt. Однако, учитывая, что это JavaScript, рисующий ответ на странице, Google не устанавливает связь между этим ответом и JavaScript, рисующим контент , поэтому он делает именно то, что мы от него ожидаем. А именно: не индексировать частичный ответ и полностью индексировать сгенерированный HTML. Будьте осторожны с этим, потому что это поведение может когда-нибудь измениться, как и весь наш контент, загружаемый через AJAX, если мы применим этот метод.

Заключение

Теперь Google может индексировать JavaScript и AJAX, но это неизбежно влечет за собой более высокие затраты на индексирование уже обработанного HTML на сервере .