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

1. КСО проблемы при начальной загрузке страницы
2. Проблемы из-за медлительности покраски
3. Проблемы с индексированием:
4. Проблемы с индексацией
5. Что происходит с фрагментами сейчас, когда Google может индексировать AJAX?
6. Блокировка индексации частичных ответов AJAX
7. заключение

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

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

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

Как уже объяснялось в предыдущем посте, для обеспечения индексации во всех пауках и ситуациях , в дополнение к хорошей производительности, лучшим решением является использование универсальные рамки , поскольку при таком подходе мы используем то, что некоторые называют гибридной отрисовкой ( Hybrid Rendering ), рисование на сервере при первой загрузке и на клиенте с JavaScript и AJAX при переходе по следующим ссылкам. Хотя на самом деле существуют другие ситуации, в которых также было бы целесообразно использовать термин гибридный рендеринг.

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

КСО проблемы при начальной загрузке страницы

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

Проблемы из-за медлительности покраски

Google выполняет индексацию следующим образом:

1. Отслеживание : робот Google запрашивает URL-адрес сервера.
2. Первая волна индексации : мгновенно индексируйте контент, нарисованный на сервере, и получайте новые ссылки для отслеживания.
3. Генерирует HTML, который нарисован на клиенте, выполняя JavaScript . Этот процесс очень затратен в вычислительном отношении (он может быть выполнен в данный момент или даже занять несколько дней, ожидая наличия ресурсов для этого).
4. Вторая волна индексации : при написании HTML-кода на клиенте отсутствующий контент индексируется, и для отслеживания создаются новые ссылки.

Кроме того, для полного индексирования страниц может потребоваться больше времени, что приводит к задержке индексации связанных страниц, если рисование страницы выполняется медленно, средство визуализации Googlebot может оставить неокрашенные части . В тестах, которые мы выполнили с опцией "сканировать как Google" в консоли поиска Google , в генерируемом ею снимке мы не видели, чтобы он рисовал ничего, что показывалось бы более 5 секунд. Тем не менее, он индексирует сгенерированный HTML после этих 5 секунд. Чтобы понять, почему это происходит, мы должны помнить, что средство рендеринга консоли поиска Google сначала строит HTML, выполняя JavaScript с помощью средства рендеринга Googlebot, а затем рисует пиксели страницы , причем первая задача должна быть принята во внимание. для индексации и к которому мы обращаемся с термином CSR. В консоли поиска Google мы видим HTML-код, созданный в первой волне индексации, а не тот, который генерируется средством визуализации Googlebot .

В тестах, которые мы сделали, когда 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 картины и, следовательно, худшее позиционирование .

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

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

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

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

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

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

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

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

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

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

Фрагменты - это часть URL-адреса, которая может отображаться в конце этих строк и которая содержит блокнот . пример:

Я http://www.humanlevel.com/blog.html#ejemplo

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

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

Однако в настоящее время Google индексирует URL-адреса с помощью hashbang (#!). Это реализовано без необходимости делать что-либо, кроме добавления восклицательного знака, и 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, уже «разжеванного» на сервере , поэтому SSR является и будет лучшим вариантом в течение некоторого времени. Но если у вас нет выбора, кроме как столкнуться с полностью CSR-сайтом или с частью, которая использует CSR, вы уже знаете, как с этим бороться.