pushState和SEO

很多人一直在说,使用pushState而不是hashbang。

我不明白的是,如果不使用hashbang,你将如何search引擎友好?

推测你的pushState内容是由客户端JavaScript代码生成的。

该情景因此是:

我在example.com 。 我的用户点击一个链接: href="example.com/blog"

pushState捕获点击,更新URL,从某处抓取JSON文件,并在内容区域创build博客文章列表。

随着hashbangs,谷歌知道去escaped_fragmenturl获取其静态内容。

使用pushState,Google只是看不到任何东西,因为它不能使用JavaScript代码来加载JSON并随后创build模板。

唯一能做的就是在服务器端渲染模板,但是这完全否定了将应用层推送到客户端的好处。

所以,我得到这个权利,pushState是不友好的客户端应用程序的search引擎优化?

那么对于那些不想在他们的URL中使用hash-bangs的人来说,使用meta标签怎么样? <meta name="fragment" content="!">

有关详情,请参阅此处: https : //developers.google.com/webmasters/ajax-crawling/docs/getting-started

不幸的是,我不认为NickC澄清了我认为OP的问题。 问题是,如果我们不使用hash-bang,我们不知道我们正在提供什么内容。 Pushstate并没有为我们解决这个问题。 我们不希望search引擎告诉最终用户导航到一些URL,这些URL会分发出无格式的JSON。 相反,我们创build了URL(可以触发更多URL的其他调用),通过AJAX检索数据并以我们喜欢的方式呈现给用户。 如果用户不是人,那么作为替代scheme,我们可以提供html快照,以便search引擎可以正确引导用户访问他们期望以(以一种可见的方式)查找请求的数据的URL。 但最终的挑战是我们如何确定用户的types? 是的,我们可以使用.htaccess或其他的东西来重写我们检测到的search引擎机器人的URL,但是我不确定这是多么的全面和未来。 谷歌可能会惩​​罚人们做这种事情,但我没有完全研究它。 所以(pushstate +谷歌的元标记)组合似乎是一个可能的解决scheme。

如果你需要search引擎来阅读你的内容, pushState是不好的?

不,关于pushState的讨论是围绕完成相同的一般过程hashbangs,但更好看的url。 想想当你使用hashbang时真的发生了什么…

你说:

借助hashbangs,Google知道要转到escaped_fragmenturl以获取其静态内容。

换句话说,

  1. Google会看到指向example.com/#!/blog的链接
  2. Google请求example.com/?_escaped_fragment_=/blog
  3. 返回用户应该看到的内容快照

正如你所看到的,它已经依赖于服务器。 如果您没有提供服务器内容的快照,则说明您的网站没有正确索引。

那么Google如何看待pushState?

使用pushState,谷歌只是看不到任何东西,因为它不能使用JavaScript来加载JSON,随后创build模板。

实际上,Google会通过site.com/blog查看任何可以请求的内容。 一个URL仍然指向服务器上的一个资源,客户仍然遵守这个合同。 当然,对于现代客户来说,Javascript已经为在没有页面刷新的情况下检索和交互内容开辟了新的可能性,但是合同是一样的。

所以pushState优雅之处在于,它为所有用户提供了相同的内容,新老用户可以使用 JS而不是新用户,但新用户可以获得更好的体验 。

你如何让Google看到你的内容?

  1. Facebook方法 – 在网站site.com/blog上提供相同的内容,当您将/blog推送到/blog上时,您的客户端应用程序将转换成相同的内容。 (Facebook不使用pushState ,但我知道,但他们用hashbangs这样做)

  2. Twitter方法 – 将所有传入的URLredirect到hashbang等效项。 换句话说,到“/ blog”的链接推送/blog到状态。 但是,如果直接请求,浏览器将以#!/blog结尾。 (对于Googlebot,可以_escaped_fragment_路由到_escaped_fragment_对于其他客户端,您可以将状态推回到漂亮的URL)。

那么你用pushState失去了_escaped_fragment_能力吗?

你说过几个不同的评论

转义片段是完全不同的。 您可以提供纯正的非风格内容,caching的内容,而不会被置于普通页面的负载之下。

理想的解决scheme是Google要么执行JavaScript网站,要么执行某种方式来知道即使对于推送网站(robots.txt),也有一个转义的片段URL。

你提到的好处不是孤立的_escaped_fragment_ 。 它为你做重写并使用一个特别命名的GET参数实际上是一个实现细节。 没有什么特别的,你不能用标准的URL做 – 换句话说,用你自己的mod_rewrite或你的服务器的等价物重写/blog/?content=/blog

如果你根本不提供服务器端内容呢?

如果你不能重写URL并且在/blog提供某种内容 (或者你推入浏览器的任何状态),那么你的服务器就不再遵守HTTP协议了。

这是非常重要的,因为页面重新加载(无论出于何种原因)将会在这个URL上提取内容。 (请参阅https://wiki.mozilla.org/Firefox_3.6/PushState_Security_Review-“view-source和reload都将在新的URI被推送时获取内容。”);

这不是在客户端绘制一次用户界面,而是通过JS API加载内容是一个不好的目标,只是它没有被HTTP和URL真正解释,而且基本上不是向后兼容的。

目前 ,hashbangs的目的是为了表示在客户端而不是在服务器上导航的不同页面状态。 例如,重载会加载相同的资源,然后读取,分析和处理哈希值。

它恰好是他们也被使用 (特别是通过Facebook和Twitter)将历史logging更改为服务器端位置,而不刷新页面。 正是在这些用例中,人们正在推荐放弃pushState的hashbangs。

如果你渲染客户端的所有内容,你应该将pushState看作更方便的历史API的一部分,而不是使用hashbang的方法。

关于pushState和#!所有有趣的讨论#! ,而且我还是看不到原来海报的pushState是如何取代#的目的。

我们的解决scheme使我们99%基于JavaScript的Ajax站点/应用程序SEOable使用#! 当然。 由于客户端呈现是通过HTML,JavaScript和PHP完成的,因此我们在由页面着陆控制的加载器中使用以下逻辑。 HTML文件与JavaScript和PHP是完全分开的,因为我们希望两者都使用相同的HTML(大部分)。 JavaScript和PHP的function大致相同,但是PHP代码不那么复杂,因为JavaScript是一个更丰富的用户体验。

JavaScript使用jQuery将它想要的内容注入到HTML中。 PHP使用PHPQuery向HTML中注入它想要的内容 – 使用“几乎”相同的逻辑,但是更简单,因为PHP版本将仅用于显示具有SEOable链接的SEOable版本,不能像JavaScript版本那样进行交互。

所有构成页面的三个组件,page.htm,page.js和page.php都存在于任何使用转义片段来知道是否加载PHP版本代替JavaScript版本的东西。 PHP版本不需要存在非SEO内容(例如只能在用户login后才能看到的页面)。 一切都很简单。

我仍然困惑的是,一些前端开发人员如果不使用服务器端技术与浏览器结合使用,就不能使用服务器端技术来开发伟大的网站(如Google Docs的丰富性)。如果JavaScript没有启用,那么我们的99%JavaScript解决scheme如果没有PHP,当然不会做任何事情。

如果启用了JavaScript,可以在PHP提供的页面上放置一个很好的URL,并redirect到JavaScript版本,但从用户angular度来看,这是不好的,因为用户是更重要的受众。

在旁边注意。 如果你只是做一个简单的网站,可以运行没有任何JavaScript,那么我可以看到pushState是有用的,如果你想逐步提高你的用户体验从一个简单的静态渲染的内容到更好的东西,但如果你想给你的用户从最好的经验得到…让我们说你的最新的游戏写在JavaScript或类似的Google文档,那么这个解决scheme的使用是有限的,因为优雅的回落,只能走到目前为止,用户体验是痛苦的比较远见的网站。