pushState и SEO

многие люди говорят, используйте pushState, а не hashbang.

то, что я не понимаю, как бы Вы были дружественны к поисковой системе без использования hashbang?

предположительно ваш контент pushState генерируется клиентским кодом JavaScript.

сценарий выглядит так:

Я example.com. Мой пользователь нажимает ссылку:href="example.com/blog"

pushState захватывает щелчок, обновляет URL-адрес, захватывает файл JSON откуда-то и создает список сообщений в блоге в области содержимого.

С hashbangs, google знает, чтобы перейти к escaped_fragment URL, чтобы получить их статическое содержимое.

С pushState Google просто ничего не видит, поскольку он не может использовать код JavaScript для загрузки JSON и последующего создания шаблона.

единственный способ сделать это, который я вижу, - это отобразить шаблон на стороне сервера, но это полностью отрицает преимущества нажатия слоя приложения на клиент.

Итак, я правильно понимаю, pushState не является SEO дружественным для клиентских приложений вообще?

75
hashbang javascript pushstate seo web-applications

3 ответов

Как насчет использования мета-тега, который Google предлагает для тех, кто не хочет хэш-челки в своих URL-адресах: <meta name="fragment" content="!">

см. здесь для получения дополнительной информации: https://developers.google.com/webmasters/ajax-crawling/docs/getting-started

к сожалению, я не думаю, что NickC прояснил проблему,которую я думал, что у OP. Проблема просто в том, что мы не знаем, кому мы служим, если мы не используем хэш-Банг. Pushstate не решит это США. Мы не хотим, чтобы поисковые системы говорили конечным пользователям переходить к некоторому URL, который выплевывает неформатированный JSON. Вместо этого мы создаем URL-адреса (которые вызывают другие вызовы других URL-адресов), которые извлекают данные через AJAX и представляют их пользователю так, как мы предпочитаем. Если пользователь не является человеком, то в качестве альтернативы мы можем использовать HTML-снимок, чтобы поисковые системы могли правильно направлять пользователей на URL-адрес, по которому они ожидали бы найти запрошенные данные (и презентабельно). Но конечная задача - как определить тип пользователя? Да мы можем использовать .htaccess или что-то переписать URL для поисковых ботов мы обнаруживаем, но я не уверен, насколько это fullproof и futureproof. Также возможно, что Google может наказывать людей за такие вещи, но я не исследовал это полностью. Таким образом, комбо (pushstate + мета-тег google) кажется вероятным решением.

15

Is pushState плохо, если вам нужны поисковые системы, чтобы читать ваш контент?

нет, разговор о pushState ориентирован на выполнение того же общего процесса для hashbangs, но с более красивыми URL-адресами. Подумайте о том, что на самом деле происходит, когда вы используете hashbangs...

вы говорите:

С hashbangs, Google знает, чтобы перейти к escaped_fragment URL, чтобы получить их статическое содержимое.

так в других слова,

  1. Google видит ссылку на example.com/#!/blog
  2. запросы Google example.com/?_escaped_fragment_=/blog
  3. вы верните снимок содержимого, которое пользователь должен увидеть

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

Итак, как Google увидит что-нибудь с pushState?

С pushState google просто ничего не видит, поскольку он не может использовать javascript для загрузки json и последующего создания шаблона.

на самом деле, Google увидит все, что он может запросить в site.com/blog. URL-адрес по-прежнему указывает на ресурс на сервере, и клиенты по-прежнему подчиняются этому контракту. Конечно, для современных клиентов Javascript открыл новые возможности для извлечения и взаимодействия с контентом без страница обновить, но контракты такие же.

Итак, предполагаемая элегантность pushState Это то, что он обслуживает один и тот же контент для всех пользователей, старых и новых, JS-способных и нет, но новых пользователей получить расширенные возможности.

как вы заставляете Google видеть ваш контент?

  1. подход Facebook-обслуживать тот же контент по URL site.com/blog что ваше клиентское приложение превратится в, когда вы нажмете /blog на государство. (Facebook не использует pushState еще что я знаю, но они делают это с hashbangs)

  2. подход Twitter-перенаправить все входящие URL-адреса на эквивалент hashbang. Другими словами, ссылка на" / blog " толкает /blog на государство. Но если он запрашивается напрямую, браузер заканчивается на #!/blog. (Для Googlebot это будет маршрут к _escaped_fragment_ как вы хотите. Для других клиентов, вы могли бы pushState вернуться к довольно URL-адрес).

так что вы теряете _escaped_fragment_ возможности pushState?

в нескольких разных комментариях вы сказали

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

идеальным решением для Google является либо сделать сайты JavaScript, либо реализовать какой-то способ узнать, что есть URL-адрес экранированного фрагмента даже для сайтов pushstate (роботов.txt?).

преимущества, которые вы упомянули, не изолированы от _escaped_fragment_. Что он делает переписывание для вас и использует специально названный GET param-это действительно деталь реализации. Нет ничего особенного в этом, что вы не могли бы сделать со стандартными URL - адресами-другими словами, переписать /blog to /?content=/blog С помощью и mod_rewrite или эквивалент вашего сервера.

что делать, если вы не служите серверный контент вообще?

если вы не можете переписать URL-адреса и служить какой-то контент at /blog (или любое состояние, которое вы нажали в браузере), тогда ваш сервер действительно больше не соблюдает контракт HTTP.

это важно, потому что перезагрузка страницы (по какой-либо причине) будет вытягивать контент по этому URL-адресу. (см. https://wiki.mozilla.org/Firefox_3.6/PushState_Security_Review- " view-source и перезагрузка будут получать содержимое в новом URI, если его толкнули.")

дело не в том, что рисование пользовательских интерфейсов один раз на стороне клиента и загрузка контента через JS APIs-плохая цель, просто она на самом деле не учитывается с HTTP и URL-адресами, и она в основном не обратно совместима.

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

так случилось, что у них есть также используется (в частности Facebook и Twitter), чтобы изменить историю на стороне сервера без обновления страницы. именно в этих случаях использования люди рекомендуют отказаться от hashbangs для pushState.

если вы визуализируете все содержимое на стороне клиента, вы должны подумайте о pushState как часть более удобного API истории, а не выход из использования hashbangs.

97

все интересные разговоры о pushState и #!, и я все еще не вижу, как pushState заменяет #!'s цель, как спрашивает оригинальный плакат.

наше решение, чтобы сделать наш сайт/приложение Ajax на основе 99% JavaScript SEOable использует #! конечно. Поскольку рендеринг клиента выполняется через HTML, JavaScript и PHP, мы используем следующую логику в загрузчике, контролируемом нашей страницей. HTML-файлы полностью отделены от JavaScript и PHP, потому что мы хотим тот же HTML в обоих (по большей части). JavaScript и PHP делают в основном то же самое, но PHP-код менее сложный, так как JavaScript намного богаче пользовательского опыта.

JavaScript использует jQuery для ввода в HTML содержимого, которое он хочет. PHP использует PHPQuery для ввода в HTML содержимого, которое он хочет - используя "почти" ту же логику, но намного проще, поскольку версия PHP будет использоваться только для отображения SEOable версии с SEOable ссылками и не будет взаимодействовать с JavaScript версия.

все три компонента, которые составляют страницы, страницы.htm, page.js и Пейдж.php существует для всего, что использует экранированный фрагмент, чтобы знать, загружать ли версию PHP вместо версии JavaScript. Версия PHP не должна существовать для не-SEOable контента (например, страницы, которые можно увидеть только после входа пользователя). Все просто.

Я все еще озадачен тем, как некоторые разработчики front end уходят от разработки отличных сайтов (с богатством Google Docs) без использования серверных технологий в сочетании с браузерными... Если JavaScript даже не включен, то наше решение 99% JavaScript, конечно, ничего не будет делать без PHP на месте.

можно иметь хороший URL, чтобы приземлиться на странице, обслуживаемой PHP, и перенаправить на версию JavaScript, если JavaScript включен, но это не хорошо с точки зрения пользователя, поскольку пользователи являются более важной аудиторией.

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

0