1. Что видит пользователь, что видит сканер
2. Текущая практика
3. Соглашение между сканером и сервером

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

Что видит пользователь, что видит сканер

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

Но представьте, что на самом деле пользователь видит в браузере много контента, касающегося фильмов и информации о них. Как это произошло? Браузер выполняет скрипт getMovieInformation.js и создает HTML-код, который видит пользователь, например что-то вроде этого:

Это важная идея: браузер может выполнять JavaScript и создавать контент на лету, а сканер не может. Чтобы сканер мог видеть то, что видит пользователь, сервер должен предоставить сканеру моментальный снимок HTML - результат выполнения JavaScript на вашей странице. Наш подход обеспечивает именно это: он позволяет собственному веб-серверу владельца сайта возвращать сканеру этот HTML - созданный из фрагментов статического контента, а также путем выполнения JavaScript - для страниц приложения. Это то, что мы называем снимком HTML .

Если вам интересно ваше собственное приложение, загрузите его в браузере, а затем просмотрите исходный код (например, в Firefox щелкните правой кнопкой мыши и выберите «Просмотреть исходный код страницы»). В нашем примере «View Page Source» не будет содержать слова «осьминог». Точно так же, если часть вашего контента создается динамически, источник страницы не будет включать в себя весь контент, который вы хотите, чтобы сканер увидел. Другими словами, «Просмотр исходного кода страницы» - это именно то, что получает сканер. Почему это важно? Это важно, поскольку результаты поиска частично основаны на словах, найденных сканером на странице. Другими словами, если сканер не может найти ваш контент, он не доступен для поиска.

Текущая практика

В настоящее время веб-мастера создают «параллельную вселенную» контента. Пользователи браузеров с поддержкой JavaScript будут видеть контент, который создается динамически, тогда как пользователи браузеров без поддержки JavaScript, а также сканеры будут видеть контент, который является статическим и создан в автономном режиме. В современной практике часто используется «прогрессивное улучшение» в виде Hijax-ссылок. От Официальный блог Google для веб-мастеров :

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

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

<a href="ajax.htm?foo=32" onClick="navigate('ajax.html#foo=32'); return false"> foo 32 </a>

Обратите внимание, что URL статической ссылки имеет параметр (? Foo = 32) вместо фрагмента (# foo = 32), который используется кодом AJAX. Это важно, так как поисковые системы понимают параметры URL, но часто игнорируют фрагменты. Веб-разработчик Джереми Кит назвал эту технику Hijax. Поскольку теперь вы предлагаете статические ссылки, пользователи и поисковые системы могут ссылаться на конкретный контент, которым они хотят поделиться или на который ссылаются.

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

Соглашение между сканером и сервером

Чтобы ваш AJAX-приложение могло сканироваться, ваш сайт должен соблюдать новое соглашение. Это соглашение основывается на следующем:

1. Сайт использует схему сканирования AJAX.
2. Для каждого URL с динамически создаваемым контентом ваш сервер предоставляет снимок HTML, который представляет собой контент, который видит пользователь (с помощью браузера). Часто такими URL-адресами являются URL-адреса AJAX, то есть URL-адреса, содержащие фрагмент хеша, например www.example.com/index.html#key=value, где # key = value - это фрагмент хеша. Снимок HTML - это все содержимое, которое появляется на странице после выполнения JavaScript.
3. Поисковая система индексирует снимок HTML и предоставляет ваши исходные URL-адреса AJAX в результатах поиска.

Чтобы это работало, приложение должно использовать определенный синтаксис в URL-адресах AJAX (назовем их «симпатичными URL-адресами»; почему вы это поймете в следующих разделах). Сканер поисковой системы временно преобразует эти "красивые URL-адреса" в "ужасные URL-адреса" и запрашивает их с вашего сервера. Этот запрос «некрасивого URL» указывает серверу, что он не должен возвращать обычную веб-страницу, которую он дал бы браузеру, а вместо этого снимок HTML. Когда сканер получает содержимое для измененного уродливого URL-адреса, он индексирует его содержимое, а затем отображает оригинальный красивый URL-адрес в результатах поиска. Другими словами, конечные пользователи всегда будут видеть красивый URL, содержащий фрагмент хеша. Следующая диаграмма обобщает соглашение:

Для получения более подробной информации о том, как реализовать это соглашение на вашем сервере, продолжайте читать: Руководство по началу работы а также Спецификация ,

Похожие

Комментарии