Як дозволити Google сканувати вміст вашого AJAX

При роботі над оптимізацією сайту фахівці часто стикаються з такою дилемою:

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

На щастя, Google зробив пропозицію про те, як веб-майстри можуть вбити двох зайців. Посилання на документацію Google будуть приведені в кінці, оскільки це все зводиться до відносно простих понять.

Хоча Google зробив цю пропозицію рік тому, мабуть, воно не привернула великої уваги оптимізаторів, хоча їм воно повинно бути особливо корисно. Цей пост призначений для людей, які ще не вивчили пропозицію Google по скануванню AJAX - і тому він написаний коротко і без зайвих технічних деталей.

Основи

По суті, якщо сайт слід цієї пропозиції, він повинен зробити доступними дві версії його змісту:

1. Контент для користувачів з включеним JS на адреси в «стилі AJAX»

2. Контент для пошукових систем, на статичному «традиційному» URL - Google ставиться до цього як «HTML-знімку».

Історично склалося так, що розробники використовували анкорние частині URL-адреси на AJAX-сайтах (це 'хеш' символ, #, і текст після нього). Це добре для користувача, але пошукова система не може впоратися з цим.

Замість того щоб використовувати хеш, #, нова пропозиція вимагає використання хеша і знаку оклику: #!

Поєднання! # Іноді називають hashbang (хешбенг), так і будемо його позначати.

Сканування протоколу AJAX

Як тільки ви почнете використовувати хешбенг в URL, Google визначить, що ви прямуєте його протоколу, і буде інтерпретувати ваші URL-адреси в особливим чином - вони будуть брати все після hashbang, і передавати його на сайт замість параметра URL. Назва, яку вони використовують для параметра: _escaped_fragment_

Google буде переписувати URL, та запитувати контент зі статичних сторінок. Щоб показати, як виглядають переписані URL, ось кілька прикладів:

  • www.demo.com/ #! seattle/hotels стає www.demo.com/?_escaped_fragment=seattle/hotels
  • www.demo.com/users #! name = rob стає www.demo.com/users?_escaped_fragment_=name=rob
  • Поки ви можете отримувати статичні сторінки (правий URL в цих прикладах), щоб відобразити той самий контент, що буде бачити користувач (ліва URL), вона буде працювати так, як слід.

    Два пропозиції з приводу статичних адрес

    Поки Google повертає статичні URL-адреси в індекс - це має сенс, оскільки вони не хочуть, щоб заподіювалася шкоди тим користувачам, які не використовують JS, відправляючи їх на сторінку, яка вимагає Javascript. З цієї причини, сайти можуть хотіти додати Javascript, який будуть виявляти користувачів з включеним JS, і прив'язувати їх до «розширеної» AJAX версії сторінки, яку вони дивляться.

    Крім того, маложелательно, щоб ваші індексовані URL-адреси показувалися в результатах пошуку з параметром «_escaped_fragment_». Цього можна легко уникнути, якщо «статична версія» ваших сторінок знаходиться на більш привабливих URL-адресах, і використовувати 301 редірект, щоб направити пошукового павука з _escaped_parameter_ версії до більш привабливому варіанту.

    У прикладі вище, на сайті можуть прийняти рішення про 301 редірект від

    www.demo.com?_escaped_fragment=seattle/hotels до www.demo.com/каталог/Сіетл/Готелі

    Живий приклад

    На щастя для нас, є велика вже готова демонстрація цієї пропозиції на досить великому веб-сайті: нової версії Twitter.

    Якщо ви користувач Twitter, увійдіть в систему, і ви отримаєте Javascript, за яким ви зможете побачити свій профіль тут:

  • http://twitter.com/ #!/RobOusbey
  • Тим не менш, робот Google буде розпізнавати це як URL в новому форматі замість запиту URL:

  • http://twitter.com/?_escaped_fragment_=/RobOusbey
  • Розумно, що Twitter хоче підтримати зворотну сумісність (щоб індексовані URL-адреси не виглядали як сміття), тому йде 301 редірект на URL:

  • http://twitter.com/RobOusbey
  • (І якщо ви увійшли в Twitter як користувач, цей URL фактично перенаправляє вас до першого).

    Більше по темі

    Найкраще місце для подальшого читання з цієї теми, безумовно, сторінки допомогою Google. Вони дають інформацію про те, як сайти повинні працювати, щоб відповідати цій пропозиції, і містять деякі цікаві поради щодо реалізації, такі як використання маніпуляцій серверним DOM для створення моментальних знімків.

    Центральної блог веб-майстрів Google зробив офіційний анонс цього, і Джон Мюллер запропонував обговорити цю тему WMC форумах.

    Використовуючи блог Google, форум і довідку, ви повинні знайти все необхідне, щоб перетворити ваші фантазії з AJAX сайтів в те, що Google буде любити, так само, як і користувачі. Удачі!

    is a post from: Aweb-Blog

    Реoкомендую також прочитати наступні статті

    Опубліковано: 23/04/11 @ 11:05
    Розділ javascript Блоги Пошуковики

    Рекомендуємо:

    З яких сайтів потрібно купувати посилання, а з яких ні
    Новий алгоритм від Яндекса "Краснодар"
    Міжнародне інтерв'ю - Джеральд Вебер, відомий SEO-спеціаліст, президент SEM-Group.net, США
    Як змусити посилання працювати? 15 принципів нарощування посилань
    Урок по створенню новорічної ілюстрації