Схема сканирования AJAX от Google и ее влияние на SEO

1. Что такое AJAX?
2. Проблема ползания AJAX
3. Решения для сканирования AJAX
4. Техника Hijax
5. Схема сканирования AJAX от Google
6. Распространенные ошибки веб-разработки
7. Если вы используете предложение Google? Давайте сосредоточимся на тематическом исследовании.
8. Выводы

Почти 2 года назад Google предложил новый способ сделать приложения и веб-сайты AJAX доступными для сканирования. Как многие из вас знают, поисковые системы очень хороши в индексировании и анализе документов HTML, но они не особенно хороши в понимании JavaScript и, следовательно, в обход контента AJAX. Несмотря на то, что прошло 2 года, только небольшое количество веб-сайтов правильно реализовали предложение Google. Более того, несмотря на то, что Google начал сканировать, индексировать и представлять такие страницы AJAX в поисковой выдаче, другие поисковые системы, такие как Bing, не поддерживают этот новый «метод».

Причина, по которой я пишу эту статью, состоит в том, чтобы кратко объяснить, что такое AJAX , обсудить проблему сканирования контента AJAX , просмотреть различные предлагаемые решения , обсудить типичные ошибки, которые допускают веб-разработчики при использовании технологий, не дружественных поисковой системе. например, AJAX и Flash и, наконец, чтобы объяснить, следует ли вам использовать предложение Google. Несмотря на то, что эта тема немного продвинута и требует базовых знаний о методах веб-разработки и о веб-технологиях в целом, я стараюсь меньше концентрироваться на части программирования и больше на части SEO. Если у вас есть какие-либо вопросы, не стесняйтесь размещать их в комментариях ниже, и мы постараемся рассказать о них в следующем сообщении в блоге.

Что такое AJAX?

AJAX является аббревиатурой от Asynchronous Javascript And Xml . Это набор методов веб-разработки, которые позволяют разработчикам программного обеспечения создавать интерактивные веб-приложения. Используя Javascript, браузер взаимодействует с пользователем и отправляет веб-запросы на сервер, который отвечает в XML (также в JSON или HTML). AJAX обычно используется для обновления определенных частей HTML-страницы без перенаправления или обновления страницы. Также методы AJAX позволяют создавать быстрые веб-приложения, которые значительно сокращают время загрузки и обеспечивают лучший пользовательский опыт. Подробное описание AJAX выходит за рамки этой статьи, тем не менее, если вы разработчик и хотите узнать больше, я настоятельно рекомендую вам прочесть учебник AJAX от W3scools.

Проблема ползания AJAX

Основная проблема сканирования AJAX заключается в том, что он в значительной степени опирается на JavaScript, который является клиентским языком сценариев, который работает в браузере (Internet Explorer, Mozilla, Opera, Chrome и т. Д.). Более того, разные браузеры поддерживают разные функции и функции (хотя это начало меняться с годами). Наконец, что не менее важно, выполнение JavaScript требует дополнительных ресурсов, и это увеличивает затраты для поисковых систем. Как мы обсуждали в прошлом, когда определенный метод увеличивает эксплуатационные расходы поисковых систем, они дают стимул веб-мастерам избегать использования таких методов или обходят проблему, предлагая менее дорогостоящие подходы .

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

Решения для сканирования AJAX

2 самых популярных метода, которые предлагались на протяжении многих лет, - это подход Hijax и схема сканирования AJAX от Google.

Техника Hijax

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

<a href=veloperjavascript:someFunction(`somepage.html#parameter=1`)casts> Нажмите меня </a>

Ни как это:

<a href= двуспальная информация> Нажмите меня </a>

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

<a href = »somepage.html? parameter = 1 ″ onclick =» someFunction (`somepage.html # parameter = 1`); вернуть ложь »> Нажмите меня </a>

Приведенный выше код перенаправит поисковую систему на целевую страницу, если JavaScript отключен, но в то же время запустит код AJAX, если JavaScript включен (очевидно, метод someFunction должен обрабатывать щелчок и загружать содержимое AJAX. пользователю). В результате и пользователи, и поисковые системы смогут получить доступ к содержанию связанной страницы.

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

Схема сканирования AJAX от Google

Схема сканирования AJAX от Google предлагает помечать адреса всех страниц, которые загружают контент AJAX определенными символами. Основная идея заключается в том, чтобы использовать специальные хеш-фрагменты (#!) В URL-адресах этих страниц, чтобы указать, что они загружают содержимое AJAX. Когда Google находит ссылку, которая указывает на URL «AJAX», например «http://example.com/page?query #! состояние », он автоматически интерпретирует его (экранирует) как« http://example.com/page?query & _escaped_fragment_ = state ».

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

После того как Google видит «URL AJAX» и после интерпретации (экранирования) он захватывает содержимое страницы и индексирует его. Наконец, когда проиндексированная страница представлена ​​в результатах поиска, Google показывает пользователю исходный URL AJAX, а не «экранированный». В результате программист должен иметь возможность обрабатывать запросы пользователя и представлять соответствующий контент при загрузке страницы.

Так что, как вы, наверное, понимаете, Google предложил способ сделать AJAX-контент доступным для обхода без выполнения JavaScript (эти доктора наук умны, не так ли?). Этот метод является более общим, чем Hijax, поскольку он охватывает больше случаев, но он намного сложнее, требует дополнительного кодирования и в настоящее время поддерживается только Google .

Распространенные ошибки веб-разработки

Как мы видели выше, одна из наиболее распространенных ошибок, которые делают веб-разработчики, заключается в том, что они не предоставляют в ссылках JavaScript значимый URL для поисковых систем. Еще одна вещь, которую многие веб-разработчики игнорируют, заключается в том, что в соответствии с веб-спецификациями и протоколами каждый параметр URL, содержащийся после символа «#» (фрагменты хеша), НИКОГДА не отправляется на веб-сервер. Таким образом, следующие URL-адреса создают абсолютно одинаковые веб-запросы к серверу:

http://example.com/#state

http://example.com/#param1=1&param2=2

http://example.com/#/directory/page.html

http://example.com/#/directory/page.html?param=1

Все приведенные выше ссылки будут генерировать веб-запрос на URL http://example.com/, а все дополнительные параметры после # будут полностью игнорироваться. Вот почему поисковые системы игнорируют все после # (мы поговорим о «#!» Чуть позже, но да, он также создает на сервере тот же веб-запрос, что и предыдущие URL).

ТАК! Исходя из вышеизложенного, мы заключаем, что большинство техник AJAX или Flash, которые обещают оптимизированные для SEO URL-адреса с использованием фрагментов хэша, НЕ работают . Некоторые из них даже пытаются изменить заголовок и текст промежуточной страницы с помощью JavaScript, чтобы сделать сайты более удобными для SEO. Не теряйте времени с этими методами, потому что они не работают. Если вы полагаетесь на код JavaScript для того, чтобы сделать ваш сайт более дружественным к SEO, вы идете по неверному пути!

Единственное исключение из приведенного выше правила - это когда #! используется. Так что вы можете подумать, что если вы используете #! вместо # у тебя все будет хорошо. К сожалению, ответ НЕТ ! Просто используя его, вы ничего не получите. Вы также должны написать код на PHP, JSP, ASP или ASP.NET, чтобы гарантировать, что ваш сервер будет обрабатывать схему сканирования AJAX от Google и отображать соответствующую удерживающую страницу (как мы объяснили выше).

Если вы используете предложение Google? Давайте сосредоточимся на тематическом исследовании.

В настоящее время схема сканирования Google AJAX реализована на относительно небольшом количестве веб-сайтов, и многие из них не сделали это должным образом. Один из веб-сайтов, на котором была проделана довольно хорошая работа, - thebullittagency.com (обратите внимание, что он не имеет отношения к нашей компании).

Прежде всего, давайте запустим в Google запрос «Особенности блога Fabric Luca Bacchetti». URL первого результата следующий:

http://thebullittagency.com/#!/blog/21-Fabric-Blog-Features-Luca-Bacchetti-

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

http://thebullittagency.com/?&_escaped_fragment_=/blog/21-Fabric-Blog-Features-Luca-Bacchetti-

Как требуется из схемы обхода AJAX, они возвращают более или менее тот же HTML-контент, что и тот, который они загружают с AJAX. Обратите внимание, что если вы хотите быть на 100% безопасным, вы должны представить точно такой же код, чтобы избежать автоматического запрета на маскировку.

Теперь давайте посмотрим, как Google обрабатывает PageRank для URL AJAX. Давайте проверим значения PageRank с помощью нашего Инструмент проверки PageRank , (Обратите внимание, что все наши инструменты обрабатывают схему сканирования AJAX). Вот результаты:

http://thebullittagency.com/#!/blog/ - PageRank: 3

http://thebullittagency.com/?&_escaped_fragment_=/blog/ - PageRank: 3

http://thebullittagency.com/ - PageRank: 4

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

Теперь посмотрим, сколько страниц проиндексировано. Если мы поищем в Google запрос «site: thebullittagency.com», мы получим более 1 тысячи результатов, что означает, что веб-сайт обычно индексируется. Также, если мы попробуем запрос «site: http: //thebullittagency.com/#! / Blog», мы получим все статьи, которые были написаны в их блоге. Так что схема сканирования Google AJAX безопасна в использовании, верно? Нету!

Давайте сделаем запрос «site: thebullittagency.com» на Bing. Ну, там не все так хорошо. Есть только 2 результата: домашняя страница и ужасный экранированный URL, которые, вероятно, были отправлены либо вручную, либо связаны напрямую из внешнего источника. Так что Bing не обрабатывает все эти URL, они игнорируют все после #! и когда ссылка размещается на внутренней странице, они пропускают весь сок на главной странице.

Но если это правда, то почему твиттер правильно проиндексирован на Bing? Ответ в том, что Twitter использует #! в своих URL, но когда поисковая система запрашивает версию страницы «http://twitter.com/username», они обычно предоставляют HTML. Конечно, если пользователь пытается получить доступ к этой версии, он делает хитрый JavaScript-редирект на #! версии, используя следующий код: «window.location.replace (` / #! / Username`); ». Почему Twitter использует этот подход? Поскольку с помощью AJAX у них меньше обновлений страниц , они сокращают время загрузки и сокращают эксплуатационные расходы (меньше серверов, больше пропускной способности и т. Д.).

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

Выводы

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

Когда вы должны его использовать? Возможно, вы можете использовать метод Google, когда у вас нет другого выбора . Лично я считаю, что у вас всегда есть возможность не использовать технологию AJAX на страницах, которые важны для поисковых систем. Если бы мне пришлось использовать AJAX, я бы выбрал технику Hijax, которая проще, безопаснее и поддерживается всеми поисковыми системами.

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

Похожие

Комментарии