Действительно ли history.pushState справляется с URL-адресами hash bang?

В последнее время я много читал о хэш-бангах URL-адресов и history.pushState для создания SEO-дружественных AJAX-сайтов. Кажется, все согласны с тем, что pushState — лучший подход, поэтому я хочу его использовать.

Вот проблема: у меня есть одностраничный веб-сайт и (на сервере) база данных с примерно тремя миллионами записей — у меня нет статических страниц для всех этих записей, но я получаю их с помощью AJAX и вставляю на сайт (если пользователь щелкает определенную ссылку или выполняет поиск).

Я знаю, что с HashBang-URLs Spider будет искать другой URL-адрес (escaped_fragment…), поэтому на стороне сервера я могу обслуживать «уродливую» страницу, которая не содержит стилей, а содержит только контент, который я хочу проиндексировать.

Пользователи могут добавлять URL-адреса в закладки и получать красивый контент, потому что URL-адреса разные (#!…), а Javascript будет генерировать контент.

С другой стороны, с history.pushState я буду вынужден использовать такие URL-адреса, как «…getItem.php?itemid=356375» (правильно?) — но теперь я больше не могу размещать здесь уродливый контент, потому что пользователи могут добавлять эти URL-адреса в закладки. .

Итак, вкратце:

Hash-Bang позволяет нам сосредоточиться на рендеринге красивого контента на стороне клиента с помощью javascript, одновременно предоставляя поисковым системам «уродливые» страницы, содержащие только контент. PushState заставляет нас постоянно показывать красивый контент без использования javascript? >

Есть ли обходной путь для этого? Любой способ не обслуживать красивый контент на стороне сервера (в моем случае PHP), в то же время позволяя пользователям добавлять в закладки URL-адреса, которые обслуживают красивый контент (через Javascript)?


javascript php seo pushstate hashbang
person Fluchtpunkt    schedule 17.06.2014    source источник
comment
Я не думаю, что вы получаете метод pushState. Представьте, что у каждой подстраницы есть прекрасные URL-адреса, как если бы вы использовали #!, но без #!. Вместо того, чтобы поддерживать отдельные уродливые URL-адреса, вы должны напрямую поддерживать дружественные URL-адреса, чтобы они генерировали правильный и читаемый ботом контент (вы можете сделать это, если # не задействован). Затем pushState позволяет вам обновлять адресную строку с закладками, когда пользователь переключает подстраницы через ваш AJAX.   -  person Tony McCreath    schedule 18.06.2014
comment
Привет, Тиггерито, на самом деле я уже использовал pushState таким образом. Для более быстрой загрузки содержимого существующих страниц, включая функцию кнопки «Назад» и т. д. Это прекрасно работает — и, конечно же, Google индексирует эти сайты. Но настоящая проблема возникает для всего контента, для которого у нас нет страниц, но мы отображаем его с помощью Javascript и хотим, чтобы Google проиндексировал… и, к сожалению, не может предоставить альтернативную ссылку «escaped_fragement…» — только для SEO, например, при использовании # !. Чем больше я читаю об этом, тем больше убеждаюсь, что pushState не может заменить #! в этом аспекте, но для большинства людей это просто не имеет значения.   -  person Fluchtpunkt    schedule 19.06.2014

Ответы (1)


arrow_upward
0
arrow_downward

Я работал с этой проблемой пару месяцев и пришел к выводу, что надо уметь поддерживать #! пути на вашем сайте, если вы хотите, чтобы Google выполнял сканирование _escaped_fragment_.

Я обнаружил, что Google просто не _escaped_fragment_ # или стандартный путь подходящим образом.

У меня гораздо больше подробностей написано в моем блоге.

http://mark.stratmann.me/articles/the-great-ajax-seo-saga

person Mark Stratmann    schedule 29.10.2014