Ajax Crawling: старый путь против нового пути (#!)

Старый способ

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

<a href="page.html" id="example">Page</a>
<script type="text/javascript">
    $('#example').click(function(){
        $.ajax({
            url: 'ajax/page.html',
            success: function(data){
                $('#content').html(data);
            }
        })
   });
</script>

edit: Я использовал для реализации события haschange для поддержки закладок для пользователей javascript.

Новый способ

Недавно Google придумал идею обхода ajax, читайте об этом здесь:

http://code.google.com/web/ajaxcrawling/

http://www.asual.com/jquery/address/samples/crawling/

В основном они предлагают изменить "website.com/#page" на "website.com/#!page" и добавить страницу, содержащую фрагмент, например "website.com/? _ escaped_fragment_ = page"

Какая польза от использования нового способа?

Мне кажется, что новый способ добавляет намного больше работы и сложности к чему-то, что до этого я сделал простым способом: я разработал веб-сайт для работы без ajax, а затем добавил ajax и hashchange event (для поддержки кнопки возврата и закладка) на завершающем этапе.

С точки зрения SEO, каковы преимущества использования нового способа?

Ответы

Ответ 1

Идея состоит в том, чтобы сделать приложения AJAX полными. Согласно спецификациям HTTP, URL-адреса относятся к одному и тому же документу независимо от идентификатора фрагмента (часть после метки хэша). Поэтому поисковые системы игнорируют идентификатор фрагмента: если у вас есть ссылка на www.example.com/page#content, искатель просто запросит www.example.com/page.

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

РЕДАКТИРОВАТЬ Что касается исходного вопроса: если у вас уже есть регулярные ссылки на статические страницы, эта схема вам не поможет.

Ответ 2

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

Ответ 3

Идея этого заключается в том, что пользователи Javascript также могут закладок страниц, я думаю. Если вы посмотрите на свой "старый" метод, он просто заменит содержимое на странице; нет способа скопировать URL-адрес, чтобы показать страницу в текущем состоянии другим людям.

Итак, если вы внедрили новый метод #!, вы должны убедиться, что эти URL-адреса указывают на правильные страницы через Javascript.

Ответ 4

Я думаю, что для Google просто проще убедиться, что вы не работаете с дублирующимся контентом. я включаю хэш, например foo/#/bar.html, в URL-адреса и передаю его в структуру постоянной ссылки, но я не совсем уверен, нравится ли Google или нет.

интересный вопрос. +1