Плохо ли pushState, если вам нужны поисковые системы для чтения вашего контента?
Нет, разговоры о pushState направлены на выполнение того же общего процесса с хэш-бангами, но с более привлекательными URL-адресами. Подумайте о том, что на самом деле происходит, когда вы используете хэшбанки ...
Вы говорите:
С помощью hashbangs Google знает, что нужно перейти по URL-адресу escaped_fragment, чтобы получить их статическое содержимое.
То есть, другими словами,
- Google видит ссылку на
example.com/#!/blog
- Google-запросы
example.com/?_escaped_fragment_=/blog
- Вы возвращаете снимок содержимого, которое должен видеть пользователь
Как видите, он уже зависит от сервера. Если вы не передаете моментальный снимок контента с сервера, значит, ваш сайт не индексируется должным образом.
Так как же Google увидит что-то с pushState?
С помощью pushState Google просто ничего не видит, поскольку не может использовать javascript для загрузки json и последующего создания шаблона.
На самом деле, Google увидит все, что может запросить, на site.com/blog. URL-адрес по-прежнему указывает на ресурс на сервере, и клиенты по-прежнему подчиняются этому контракту. Конечно, для современных клиентов Javascript открыл новые возможности для поиска и взаимодействия с контентом без обновления page , но контракты те же.
Таким образом, предполагаемая элегантность pushState заключается в том, что он предоставляет одинаковый контент всем пользователям, старым и новым, с поддержкой JS и нет, но новые пользователи получают расширенные возможности .
Как вы можете заставить Google видеть ваш контент?
Подход Facebook & mdash; показывать тот же контент по URL site.com/blog, в который ваше клиентское приложение преобразуется, когда вы нажимаете /blog в состояние (Facebook пока не использует pushState, о котором я знаю, но они делают это с помощью hashbangs)
подход Твиттера & mdash; перенаправить все входящие URL-адреса в эквивалент hashbang. Другими словами, ссылка на "/ blog" помещает /blog в состояние. Но если он запрашивается напрямую, браузер заканчивается на #!/blog. (Для робота Googlebot это затем приведет к _escaped_fragment_, как вы хотите. Для других клиентов вы можете pushState вернуться к красивому URL).
Так вы теряете способность _escaped_fragment_ с pushState?
В нескольких разных комментариях вы сказали
сбежавший фрагмент совершенно другой. Вы можете обслуживать чистый нетемизированный контент, кэшированный контент и не подвергаться нагрузке, которую представляют собой обычные страницы.
Идеальным решением для Google является либо создание сайтов JavaScript, либо реализация какого-либо способа узнать, что существует URL-адрес фрагмента с отступом даже для сайтов pushstate (robots.txt?).
Упомянутые вами преимущества не относятся к _escaped_fragment_. То, что он выполняет переписывание для вас и использует специально названный параметр GET, действительно является деталью реализации. В этом нет ничего особенного, чего нельзя было бы сделать со стандартными URL-адресами & mdash; другими словами, переписать /blog в /?content=/blog самостоятельно, используя mod_rewrite или эквивалент вашего сервера.
Что если вы вообще не обслуживаете серверный контент?
Если вы не можете переписать URL-адреса и обслуживать какой-либо контент в /blog (или в любом другом состоянии, которое вы вставили в браузер), то ваш сервер больше не соблюдает HTTP-контракт.
Это важно, потому что при перезагрузке страницы (по любой причине) содержимое будет извлечено по этому URL. (См. https://wiki.mozilla.org/Firefox_3.6/PushState_Security_Review & mdash; "view-source и reload будут извлекать содержимое по новому URI, если он был выдвинут.")
Дело не в том, что рисование пользовательских интерфейсов один раз на стороне клиента и загрузка контента через API-интерфейсы JS - плохая цель, просто в том, что на самом деле это не учитывается с помощью HTTP и URL-адресов, и, по сути, оно обратно несовместимо.
На данный момент это именно то, для чего предназначены хэш-банги - для представления отдельных состояний страницы, которые перемещаются на клиенте, а не на сервере.Например, перезагрузка загрузит тот же ресурс, который затем сможет прочитать, проанализировать и обработать хэшированное значение.
Просто так получилось, что они также использовали (особенно через Facebook и Twitter), чтобы изменить историю на местоположение на стороне сервера без обновления страницы. Именно в этих случаях пользователи рекомендуют отказаться от хеш-бангов для pushState.
Если вы визуализируете весь контент на стороне клиента, вы должны думать о pushState как о более удобной историиAPI, а не выход из использования hashbangs.