Google все еще Ajax
Можете ли вы теперь доверять Google для ползания сайтов Ajax?
Краткое содержание:
14 октября Google объявил, что они больше не рекомендуют схему ползания Ajax, которую они опубликовали в 2009 году. Это поднимает вопрос о том, можете ли вы доверять Google успешно ползти и индексировать сайт Ajax.
Ключевые моменты:
- Веб -дизайнеры и инженеры предпочитают использовать AJAX для создания приложений для одного страницы (SPA) с такими рамками, как Angular и React.
- Ajax позволяет гладкие интерактивные веб -приложения, которые работают, например, настольные приложения.
- В спа -салоне контент HTML изначально не загружается в браузер. Вместо этого Ajax использует JavaScript для динамической связи с веб -сервером и рендеринг HTML.
- Google смог ползти некоторого контента JavaScript, но SEO для SEO для Spa Ajax Sites создает проблемы.
- В 2009 году Google представил спрыгиваемое решение AJAX, которое включало использование URL-адресов или метатеток «сбежавшего фрагмента» или метатеток, чтобы поручить Google принести предварительную версию страницы с полным HTML.
- Несмотря на способность Google ползти JavaScript, многие сайты, которые позволили Google заполнить их спа -сайты Ajax, испытывали ограниченный успех.
- Некоторые сайты даже увидели значительное падение органического трафика после перехода на реализацию Ajax.
- 14 октября Google объявил, что они больше не рекомендуют свое старое предложение Ajax Clawing, но они все еще поддерживают его.
- Существует неправильное представление о том, что Google теперь может ползти сайтов Ajax без проблем, но важно отметить, что они утверждают, что «в целом способны» отображать и понимать веб -страницы, такие как современные браузеры.
- Крайне важно учитывать язык, используемый Google, и не полагаться исключительно на предположение, что они могут полностью понять страницы Ajax.
Вопросы:
- Может ли Google успешно индексировать сайты Ajax?
- Какова цель использования Ajax в веб -дизайне?
- Что происходит, когда спа -салон изначально загружается?
- Какие проблемы сталкиваются с Ajax, которые исторически сталкиваются с SEO?
- Какие методы были предложены Google в 2009 году, чтобы сделать Ajax полным?
- Позволил Google Crawl Ajax сайты приводит к успешной индексации для многих веб -сайтов?
- Какое негативное влияние испытало некоторые сайты после внедрения AJAX?
- Что объявил Google 14 октября относительно их рекомендации Ajax Crawling?
- Точно ли верить, что Google теперь может эффективно ползти AJAX сайтов?
- Почему важно учитывать язык Google в их объявлении?
- Можете ли вы доверять Google, чтобы полностью понять и ползти свой сайт Ajax?
- Как веб -дизайнеры и инженеры используют Ajax в создании веб -приложений?
- Какова роль JavaScript в процессе рендеринга сайта Ajax?
- Почему некоторые веб-сайты прибегли к предварительно-рендерированным снимкам HTML в качестве решения?
- Что существует в заблуждении о способности Google заползть сайты Ajax?
Ответы:
- Google может ползти сайтов Ajax, но успех индексации варьируется и не гарантируется.
- Ajax используется в веб -дизайне для создания приложений для одностраничных страниц (SPA), которые обеспечивают плавную и интерактивную пользовательскую работу, аналогичную выделенным приложениям для настольных компьютеров.
- Когда спа -салон загружается изначально, содержание HTML не получает и не производится. Вместо этого браузер полагается на JavaScript для связи с сервером и динамически отображать HTML.
- Исторически, сайты Ajax столкнулись с проблемами с SEO, потому что способность Google ползти контент JavaScript была ограниченной. Это привело к трудностям в эффективной индексации и рейтингах.
- В 2009 году Google предложил два метода, чтобы сделать Ajax полным. Один участвовал в использовании URL -адресов «сбежавшего фрагмента», что привело к уродливым URL -адресам. Другой метод использовал Meta = “фрагмент” Теги на странице, чтобы поручить Google принести предварительно Рендерринную версию с полным HTML.
- Позволяя Google на сайты Ajax не всегда приводили к успешной индексации для многих веб -сайтов. На некоторых сайтах была полностью оказана и индексированная часть их страниц, в то время как другие испытывали значительное снижение органического движения.
- После реализации Ajax некоторые веб -сайты оказали негативное влияние на их органический трафик и должны были оправиться от падения посетителей.
- 14 октября Google объявил, что они больше не рекомендуют свое старое предложение Ajax Clawing, но они продолжают его поддерживать. Это означает, что они активно не предлагают его использование, но все же признают его функциональность.
- Не точно предположить, что Google теперь может эффективно ползти сайтов Ajax без каких -либо проблем. Хотя они утверждают, что «в целом способны» отображать и понимать веб -страницы, такие как современные браузеры, важно учитывать используемый язык, а не только полагаться на это утверждение.
- Важно учитывать язык Google в их объявлении, потому что они не предоставляют гарантию бесшовной индексации для сайтов Ajax. Фраза «в целом способна» подразумевает потенциал ограничений и проблем в полном понимании и ползании страниц Ajax.
- Доверие Google, чтобы полностью понять и ползти, сайт Ajax не рекомендуется без дальнейшего тестирования и мониторинга. Успех индексации может варьироваться, и крайне важно рассмотреть альтернативные решения, такие как предварительные снимки HTML.
- Веб -дизайнеры и инженеры используют AJAX для создания спа -салонов с такими рамками, как Angular и React, что позволяет разработать веб -приложения, которые предлагают интерактивное и плавное пользовательское впечатление, аналогичное выделенным приложениям для настольных компьютеров.
- JavaScript играет важную роль в процессе рендеринга сайта Ajax. Он динамически общается с веб -сервером для создания и отображения контента HTML для пользователя для взаимодействия с.
- Веб-сайты прибегают к снимкам HTML перед срендом HTML, потому что некоторые фреймворки AJAX, такие как Angular, еще не поддерживают рендеринг на стороне сервера. Предварительное использование позволяет создавать снимки HTML, которые обслуживаются поисковыми системами, обеспечивая полную индексацию и видимость.
- Существует неправильное представление о том, что способность Google ползти сайтов Ajax теперь безупречна. Тем не менее, важно отметить, что их способность понимать и ползти содержание JavaScript улучшилась, но проблемы и ограничения все еще могут существовать.
Можете ли вы теперь доверять Google для ползания сайтов Ajax
А потом, 14 октября, Google сказал:
Содержит ли Google Clawl Ajax контент? [закрыто]
Хочу улучшить этот вопрос? Обновите вопрос, поэтому он фокусируется на одной проблеме, только отредактировав этот пост.
Закрыто 7 лет назад .
На домашней странице моего сайта я использую функцию jQuery Ajax, чтобы снять список недавней деятельности пользователей. Недавняя деятельность отображается на странице, и каждая строка недавней деятельности включает в себя ссылку на профиль пользователя пользователя, который выполнял деятельность. Будет ли Google фактически сделать вызов Ajax, чтобы снять эту информацию и использовать ее в расчете релевантности / поток сока ссылки? Я надеюсь, что это не Поскольку страницы профиля пользователя не очень достойны Google Index, и я не хочу, чтобы все эти ссылки на страницы профиля пользователя разбавляли ссылку моей домашней страницы вдали от других более важных ссылок.
Можете ли вы теперь доверять Google для ползания сайтов Ajax?
14 октября Google объявил, что больше не рекомендует схему ползания Ajax, которую они опубликовали в 2009 году. Обозреватель Марк Манро погружается в вопрос о том, означает ли это, что вы теперь можете рассчитывать на то, чтобы Google успешно ползти и индексировать сайт Ajax.
Марк Манро 13 ноября 2015 года в 9:18 | Время чтения: 7 минут
Веб -дизайнеры и инженеры любят Ajax для создания одностраничных приложений (SPA) с популярными рамками, такими как Angular и React. Реализации Pure Ajax могут предоставить плавное интерактивное веб -приложение, которое больше похоже на выделенное настольное приложение.
В спа -салоне, как правило, содержимое HTML не загружается в браузер на начальной выборке веб -страницы. Ajax использует JavaScript для динамической связи с веб -сервером, чтобы создать HTML для отображения страницы и взаимодействия с пользователем. (Есть техника под названием “Рендеринг на стороне сервера” где JavaScript фактически выполняется на сервере, а запрос страницы возвращается с рендерированным HTML. Тем не менее, этот подход еще не поддерживается во всех структурах SPA и добавляет сложности к разработке.)
Одной из проблем с сайтами Spa Ajax была SEO. Google на самом деле какое -то время ползает контентом JavaScript. Фактически, эта недавняя серия тестов подтвердила Google’Способность ползать, метаданные и контент, вставленные через JavaScript. Тем не менее, веб -сайты, использующие рамки Pure Spa Ajax.
Еще в 2009 году Google разработал решение, чтобы сделать Ajax полным. Этот метод либо создает “сбежал фрагмента” URL -адреса (уродливые URL -адреса) или совсем недавно, чистые URL -адреса с Мета =”фрагмент” тег на странице.
URL-URL-фрагмент сбежавшего фрагмента или мета-фрагментного тега инструктирует Google выйти и получить предварительно Рендерленную версию страницы, которая выполнила весь JavaScript и имеет полный HTML, который Google может анализировать и индекс. В этом методе паук обслуживает совершенно другой исходный код страницы (HTML VS. JavaScript).
С словами, что Google Crawls JavaScript, многие сайты решили позволить Google ползти на своих сайтах спа -сайте Ajax. В общем, это не было очень успешным. В прошлом году я проконсультировался с парой веб -сайтов с Ajax Angular внедрением. Google имел некоторый успех, и около 30 процентов страниц в Google’S кеш был полностью отображен. Остальные 70 процентов были пустыми.
Популярный продовольственный сайт переключился на Angular, полагая, что Google может ползти его. Они потеряли около 70 процентов своего органического трафика и все еще восстанавливаются после этого разгрома. В конечном счете, оба сайта отправились на снимки HTML перед сбором.
А потом, 14 октября, Google сказал:
Мы больше не рекомендуем предложение ползания Ajax, которое мы сделали еще в 2009 году.
Обратите внимание, что они все еще поддержка их старое предложение. (Были некоторые статьи, в которых объявлялись, что они больше не поддерживают их, но это не так – они просто больше не рекомендуют этот подход.)
Опустив старую рекомендацию, они, казалось, говорили, что теперь могут ползти Ajax.
Затем, всего через неделю после объявления, клиент с недавно запущенным сайтом попросил меня проверить это. Это был угловой сайт, снова реализация спа -салона Ajax.
После изучения Google’S Индекс и кэш, мы видели несколько частично индексированных страниц без полного контента. Я подтвердил свою более раннюю рекомендацию по использованию снимков HTML или прогрессивного улучшения.
Этот сайт был построен с помощью Angular, который еще не поддерживает рендеринг на стороне сервера (опять же, в данном случае сервер первоначально отображает страницу для обслуживания документа HTML), поэтому прогрессивное улучшение будет трудно поддержать, а снимки HTML все еще являются лучшими для них решением для них.
Она ответила, “Но почему? Все, что я читаю, говорит мне, что Google может ползти Ajax.”
Они могут? Позволять’S обращайте внимания на новую рекомендацию в отношении Ajax.
Google’новые рекомендации Ajax
Объясняя, почему они выпускают старую рекомендацию, говорят они (акцент мой):
Мы вообще способен Чтобы отобрать и понимать ваши веб -страницы, такие как современные браузеры.
Многие люди могут быстро сделать вывод, что теперь они могут ползти Ajax без проблем. Но посмотрите на язык: “вообще способен”? Спорим ли вы, что ваш бизнес доходов от знаний о том, что Google “вообще способен” Чтобы понять вашу страницу?
Может быть, я просто выбираю семантику? Позволять’S изучите объявление дальше. Позже в своем объявлении они заявляют в отношении Ajax:
Поскольку предположения о нашем предложении 2009 года больше не действительны, мы рекомендуем следовать принципам прогрессивного улучшения.
Они не доносят’T написал это в своем объявлении, но рекомендуя прогрессивное улучшение (которое загружает HTML для браузеров, которые доны’T поддерживаю JavaScript), они, похоже, неявно говорят, “Дон’T рассчитывайте на то, что мы ползете ваш JavaScript.” Зачем рекомендовать этот метод, если действительно Google может последовательно заползть спа -сайты Ajax?
Я волновался, что, возможно, переоцениваю Google’Слова, но потом…
Джон Мюллер подтверждает, что у Google все еще есть проблемы с Ajax
27 октября (менее чем через две недели после объявления Google) Джон Мюллер, на своем веб -мастерском Hangout, подтвердил, что у Google действительно все еще есть проблемы с Ajax.
Вы можете просмотреть обмен около 1:08:00 в видео, где был вопрос, касающийся конкретной угловой реализации:
У них все еще есть проблемы с рендерингом, и они ожидают улучшения со временем. Джон рекомендует некоторые действия, чтобы помочь отладить проблемы.
В конечном счете, он рекомендовал использовать HTML -снимки, пока Google не станет лучше в Ajax (да, метод, который был просто официально устарел).
Так что делать?
- Прогрессивное улучшение. Рендеринг на стороне сервера потребуется для прогрессивного улучшения, и он еще не поддерживается Angular. Тем не менее, предстоящий угловой 2.0 будет поддерживать рендеринг на стороне сервера. React сегодня поддерживает рендеринг на стороне сервера. Это, однако, больше работы, чем просто создание снимков HTML. Вы должны убедиться, что вы отображаете любые необходимые ссылки, чтобы Google мог ползать и указать дополнительный контент, который загружается на страницу. Тем не менее, для сайтов, использующих структуру Ajax, это будет мой рекомендуемый подход. (И, конечно, это Google’S Рекомендуемый подход.)
- Предварительно снимки HTML-снимки. Опять Дон’Это не смутится, если вы слышали или читали, что Google больше не поддерживает этот метод. Они будут продолжать поддерживать его в обозримом будущем. Они больше не рекомендуют это. Этот метод работает; Тем не менее, написание кода для предварительного разрешения и обслуживания снимков не является тривиальным. Хорошая новость в том, что есть несколько поставщиков, таких как Prerender.IO, кто сделает работу за вас по относительно низкой цене. Это, вероятно, самый простой подход. Этот метод не идеален. Обслуживание различного исходного кода для Crawlers против. Браузеры (HTML VS. JavaScript) может быть проблематичным. Это можно считать техникой маскировки, и не обязательно очевидно, что обслуживают боты. Это’Важно контролировать Google’S кеш, чтобы убедиться, что они не обслуживаются не той страницей. Тем не менее, если вы используете платформу, которая не поддерживает рендеринг на стороне сервера, то это может быть ваше единственное решение.
Береженого Бог бережет
Даже если бы я видел доказательства того, что Google постоянно ползал сайтам Ajax, я бы все равно был бы осторожным. Требуется гораздо больше ресурсов и гораздо больше времени, чтобы полностью отобразить страницу, чем просто служить HTML.
Что будет с сайтами с сотнями тысяч или миллионов страниц? Как это повлияет на бюджет восхищения? Останется ли скорость полза?
Прежде чем рекомендовать этот подход, я’D Скорее подождите и увидите убедительные доказательства того, что Google может и постоянно ползет большие, чистые одностраничные приложения Ajax без негативного влияния на скорость ползания, индексацию и рейтинги. Пожалуйста, поделитесь своим собственным опытом.
Мнения, выраженные в этой статье, являются мнениями приглашенного автора и не обязательно. Сотрудники авторов перечислены здесь.
Как JavaScript и Ajax влияют на индексацию в Google?
Со временем Google значительно улучшил свой индексация JavaScript и Ajax. Вначале это не сделало’T index whate whout или следовал за любыми ссылками, появляющимися в контенте, загруженном через эти рамки. Но потом, понемногу, он начал индексировать некоторые реализации и улучшать свои возможности. В настоящее время он может индексировать множество различных реализаций, и перейдите по ссылкам, загруженным через Аякс или API. Тем не менее, все еще будут случаи, когда это может не сделать этого.
Чтобы проанализировать случаи, в которых Google может не индексировать наш сайт, сначала нам нужно понять концепцию Рендеринг на стороне клиента (CSR). Это подразумевает это HTML нарисован на стороне клиента с JavaScript, обычно используется Аякс в избытке. Первоначально веб-сайты всегда нарисовали серверную сторону HTML (Рендеринг на стороне сервера или SSR), но в течение некоторого времени, CSR стал популярным, с прибытием фреймворков JavaScript, таких как Angular, React и Vue. Однако, КСО негативно влияет на индексацию, Производительность рендеринга веб -сайта и, следовательно, SEO.
Как мы’уже объяснил раньше, Для обеспечения индексации во всех поисковых системах и ситуациях, Помимо достижения хорошей производительности, Лучшее решение – использовать универсальную структуру, Как и в случае с этими мерами, мы в конечном итоге Гибридный рендеринг. Он состоит в рисовать веб -сайт на сервере при первой загрузке, а затем на клиенте через JavaScript и Ajax, когда навигация перемещается к следующим ссылкам. Хотя на самом деле существует больше ситуаций, когда использование гибридного члена рендеринга также действителен.
Иногда компания по разработке использует CSR и не делает’T предложить нам возможность использовать универсальную структуру. Этот Веб-разработка на основе CSR доставит нам неприятности, в большей или меньшей степени, в зависимости от гусени. В этом посте мы собираемся проанализировать Какие эти проблемы с Google’S Crawler есть и как их решить.
Проблемы с КСО во время начальной нагрузки страницы
Во -первых, мы собираемся проанализировать проблемы индексации, происходящие Как только мы введем URL за пределами сайта, и когда HTML отображается на стороне клиента с JavaScript.
Проблемы в результате медленного рендеринга
Google’S Процесс индексации проходит следующие шаги:
- Ползание: GoogleBot запрашивает URL на сервере.
- Первая волна индексации: Он индексирует контент, нарисованный на сервере мгновенно, и получает новые ссылки на Crawl.
- Он генерирует нарисованную HTML-сторону клиента, запустив JavaScript. Этот процесс является вычислительно дорогостоящим (это может быть сделано в данный момент или занять несколько дней, даже ожидая, чтобы получить необходимые ресурсы для этого).
- Вторая волна индексации: С помощью HTML-нарисованной на стороне клиента оставшийся контент индексируется, а новые ссылки для ползаются.
Помимо того факта, что Страницы могут занять больше времени для полного индекса, тем самым задерживая индексацию последующих страниц, связанных с ними, если рендеринг страницы является медленным, Googlebot’S redender может оставить неокрашенные детали. Мы’ve проверил это, используя вариант “Просмотреть как Google” Предоставлено Google Search Console, и скриншот, который он генерирует’T нарисуйте все, что требует более 5 секунд, чтобы быть отображенным. Однако он генерирует HTML, который занимает больше времени, чем эти 5 секунд. Чтобы понять, почему это происходит, мы должны помнить, что Google Search Console’S Renderer Сначала строит HTML, используя JavaScript с GoogleBot’S redender, а затем рисует страницу’S пиксели. Первая задача – это то, что необходимо учитывать для индексации, к которому мы ссылаемся с термином CSR. В консоли поиска Google мы видим HTML, сгенерированный во время первой волны индексации, а не тот, который сгенерирован Googlebot’S redender.
В консоли поиска Google мы не можем увидеть HTML, нарисованный JavaScript, который запускается Googlebot и используется на последней фазе индексации. Для этого мы должны использовать этот инструмент: https: // search.Google.com/test/specially �� �� Нажмите, чтобы твитнуть
В тестах мы’вел, когда рендеринг HTML занял более 19 секунд, он не сделал’t, чтобы что -либо индексировать. Хотя это много времени, в некоторых случаях его можно превзойти, особенно если мы интенсивно используем Ajax, и в этих случаях Google’S рендерер, как и любой рендерер, действительно должен ждать следующих шагов:
- HTML загружается и обрабатывается Запросить связанные файлы и создать DOM.
- CSS загружается и обрабатывается, Запросить связанные файлы и создать CSSOM.
- JavaScript загружается, Скомпилировано и запустить, чтобы запустить запросы Ajax (ы).
- Запрос Ajax перемещается в очередь запроса, В ожидании ответа, вместе с другими запрошенными файлами.
- Ajax запрос запущен, и он должен пройти через сеть на сервер.
- Сервер отвечает на запросы через сеть и, наконец,, Мы должны ждать, пока JavaScript запустит, чтобы нарисовать содержание страницы’S HTML Шаблон.
Запрос и время загрузки только что описанного процесса зависят от загрузки сети и сервера за это время. Более того, Googlebot использует только http/1.1, что медленнее, чем http/2, потому что запросы рассматриваются один за другим, а не все одновременно. Это’Необходимо, чтобы как клиент, так и сервер разрешали использовать http/2, поэтому именно поэтому Googlebot будет использовать только http/1.1, даже если наш сервер позволяет HTTP/2. Подводя итог, это означает, что Googlebot ждет каждого запроса, чтобы запустить следующий, и он’возможно, он выиграл’t, пытаясь параллельно определенные запросы, открывая различные соединения, как это делают браузеры (хотя мы доново’точно не знаю, как это делает это). Поэтому мы находимся в ситуации, когда Мы могли бы превзойти эти 19 секунд, которые мы оценили ранее.
Представьте, например, с изображениями, CSS, JavaScript и Ajax запускаются более 200 запросов, каждый из которых занимает 100 мс. Если запросы Ajax отправляются на обратную очередь, мы’ll, вероятно превышать необходимое время для индексированного их контента.
С другой стороны, из -за этих проблем с производительностью КСО, Мы получим худшую оценку для метрики FCP (первая удовлетворенная краска) в PageSpeed с точки зрения рендеринга и его WPO, и, как следствие, худшие рейтинги.
Проблемы индексации:
При индексации контента нарисованной клиентской стороной, Googlebot может столкнуться с следующими проблемами, что предотвратит индексацию HTML, сгенерированного JavaScript, HTML:
- Они используют Версия JavaScript Груплер не делает’t распознавать.
- Они используют JavaScript API Не распознается Googlebot (в настоящее время мы знаем, что веб -сокеты, WebGL, WebVR, IndexedDB и WebSQL не поддерживаются – больше информации на https: // Разработчики.Google.com/search/docs/Guides/рендеринг).
- Файлы JavaScript заблокированы роботами.текст.
- Файлы JavaScript обслуживаются через HTTP, в то время как веб -сайт использует https.
- Есть JavaScript ошибки.
- Если заявка запрашивает Пользовательский разрешение Чтобы что -то сделать, и от этого зависит от рендеринга основного контента, он выиграл’Т -окрашен, потому что Googlebot отрицает любое разрешение’S запрошен по умолчанию.
Чтобы узнать, страдаем ли мы от какой -либо из этих проблем, мы должны использовать Google’с Мобильный тест. Он покажет нам скриншот о том, как на экране нарисована страница, похожая на консоль поиска Google, но также показывает нам HTML -код, сгенерированный рендерером (как упоминалось ранее), Регистры журналов ошибок в коде JavaScript, и Особенности javaScript, рендерера, еще не может интерпретировать. Мы должны использовать этот инструмент для проверки всех URL -адресов, которые являются репрезентативными для каждого шаблона страницы на нашем веб -сайте, чтобы убедиться, что веб -сайт индексируется.
Мы должны помнить, что в HTML генерируется предыдущим инструментом, все метаданные (включая канонический URL) будет проигнорирован GoogleBot, так как он учитывает информацию только тогда, когда она’S нарисован на сервере.
Проблемы с КСО в отношении навигации на следующую страницу
Теперь, пусть’S Посмотрите, что происходит, когда мы используем ссылку для навигации, как только мы’Re уже на веб-сайте, и HTML нарисован в сторону клиента.
Индексация проблем
Вопреки КСО во время начальной нагрузки, Навигация на следующую страницу Переключение основного контента через JavaScript быстрее, чем SSR. Но мы’у меня есть проблемы с индексацией, если:
- Ссылки Дон’t есть действительный URL -адрес, возвращающий 200 ОК в своем href атрибут.
- Сервер возвращает ошибку при непосредственном доступе к URL -адресу, без JavaScript или с включенным JavaScript и удалением всех кэшей. Будьте осторожны с этим: если мы перейдем на страницу, нажав на ссылку, может показаться, что это может показаться’S Работа, потому что он загружается JavaScript. Даже при непосредственном доступе, если веб -сайт использует работника службы, веб -сайт может имитировать правильный ответ, загрузив его кэш. Но Googlebot – это гусеница без сохранения состояния, причина, по которой он не делает’T примите во внимание любой кэш работников сервера или любую другую технологию JavaScript, такую как локальное хранилище или хранение сеанса, поэтому он получит ошибку.
Более того, чтобы веб -сайт был доступен, URL должен измениться, используя JavaScript с История API.
Что происходит с фрагментами сейчас, когда Google может индексировать Ajax?
Фрагменты являются частью URL, который может появиться в конце, которому предшествует хэш #. Например:
http: // www.HumanLevel.com/блог.html#пример
Этот вид URL -адресов никогда не достигает сервера, они управляются только на стороне клиента. Это означает, что при запросе вышеуказанного URL -адреса сервера он получит запрос на “http: // www.HumanLevel.com/блог.HTML”, и в клиенте браузер прокрутит фрагмент документа, упоминаемого. Это общее и первоначально предполагаемое использование для этих URL -адресов, широко известен как HTML -якоря. И якорь, на самом деле, это любая ссылка ( “а” тег в HTML происходит от якорь). Однако еще в старые времена, Фрагменты также использовались для изменения URL-адресов с помощью JavaScript на страницах, загруженных AJAX, намереваясь позволить пользователю перемещаться по истории просмотра. Он был реализован таким образом, потому что тогда фрагмент был единственной частью URL, который мы могли бы изменить с помощью JavaScript, поэтому разработчики воспользовались этим, чтобы использовать их так, как они были’t намеревался. Это изменилось с появлением API истории, потому что это позволило изменить весь URL -адрес с помощью JavaScript.
Вернувшись, когда Google не мог’T Index Ajax, если URL изменил его содержание через Ajax, на основе фрагментной части, мы знали, что он будет только индексировать URL и содержание, не принимая во внимание фрагмент. Так что … что происходит с страницами с фрагментами сейчас, когда Google может индексировать Ajax? Поведение точно такое же. Если мы связываем страницу с фрагментом, и она изменит свой контент при обращении к фрагменту, она будет индексировать контент, игнорируя фрагмент, и популярность пойдет на этот URL, Поскольку Google доверяет, что фрагмент будет использоваться в качестве якоря, а не для изменения контента, как следует.
Тем не менее, Google в настоящее время индексирует URL -адреса с хэшбангом (#!). Это может быть реализовано с помощью простого добавления восклицательного знака или хлопнуть, и Google заставит его работать, чтобы поддерживать обратную совместимость с устаревшей спецификацией, чтобы сделать AJAX индексацией. Эта практика, однако, не рекомендуется, потому что теперь она должна быть реализована с помощью API истории и кроме, Google может внезапно прекратить индексацию URL -адресов Hashbang в любое время.
Блокирование индексации частичных ответов через AJAX
Когда Аякс запрос отправляется URL -адреса отдыха или API GraphQL, мы’Re вернул а Json или кусок страницы, которую мы не надеем’Т хочу индексировать. Поэтому мы должны Заблокируйте индексацию URL -адресов, на которые направлены эти запросы.
В тот день мы могли бы блокировать их с помощью роботов.текст, Но со времен Googlebot’S redender стал существовать, мы не можем блокировать любой ресурс, используемый для рисования HTML.
В настоящее время Google немного умнее и это не’Т обычно Попытка индексировать ответы с JSONS, но если мы хотим убедиться, что они не надеты’t, Универсальное решение, применимое ко всем поисковым системам, состоит в том, чтобы сделать все URL -адреса, используемые с AJAX, чтобы принять только запросы, сделанные с помощью метода POST, Потому что это не’T Используется Crawlers. Когда запрос GET достигнет сервера, он должен вернуть ошибку 404. С точки зрения программирования, это не’T заставляйте нас удалить параметры из URL’S querystring.
Существует также возможность добавления HTTP “X-Robots-Tag: noindex” Заголовок (изобретенный Google) для ответов Ajax или чтобы эти ответы были возвращены с 404 или 410. Если мы используем эти методы на контенте, загруженном непосредственно из HTML, он выиграл’T, как если бы мы заблокировали его через роботов.txt file. Однако, Учитывая, что это’S JavaScript рисует ответ на странице, Google Do Do’t установите отношения между этим ответом и JavaScript, Так что это делает именно то, что мы ожидаем от этого. И это: не указать частичный отклик и полностью индексировать сгенерированный HTML. Осторожно с этим, потому что это поведение может измениться когда -нибудь, как и весь наш контент, загруженный через Ajax, если мы применим эту технику.
Заключение
Google теперь может индексировать JavaScript и Ajax, но это неизбежно подразумевает Более высокая стоимость индексации уже обработанного HTML на сервере. Это означает, что SSR является и будет оставаться лучшим вариантом в течение довольно долгого времени. Если у вас нет другой альтернативы, кроме как иметь дело с веб -сайтом CSR, полностью или частично, вы теперь знаете, как это сделать.