PushState и SEO

Ответ 1

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

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

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

Ответ 2

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

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

Вы говорите:

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

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

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

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

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

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

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

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

Как вы получаете Google для просмотра своего контента?

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

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

Итак, вы теряете возможность _escaped_fragment_ с помощью pushState?

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

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

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

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

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

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

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

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

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

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

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

Ответ 3

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

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

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

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

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

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

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