pushState и SEO

Question

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

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

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

Сценарий таков:

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

Является pushState плохо, если вам нужны поисковые системы для чтения вашего контента?

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

Ты говоришь:

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

Другими словами,

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, (Для Googlebot, это будет затем направить в _escaped_fragment_ как ты хочешь. Для других клиентов вы могли бы pushState вернуться к красивому URL).

Так ты теряешь _escaped_fragment_ возможность с pushState?

В паре разных комментариев вы сказали

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

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

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

Что если вы вообще не обслуживаете серверный контент?

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

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

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

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

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

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

Answer 3

Все интересные разговоры о pushState и #!, и я до сих пор не вижу, как pushState заменяет цель #!, как просит оригинальный автор.

Наше решение, позволяющее сделать наш сайт / приложение 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.

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

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

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

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