推送状态和 SEO
很多人一直在说，用pushState而不是hashbang。
我不明白的是，如果不使用 hashbang，你将如何对搜索引擎友好？
据推测，您的 PushState 内容是由客户端 JavaScript 代码生成的。
场景如下：
我在 example.com 上。我的用户单击一个链接：href="example.com/blog"
PushState 捕获单击、更新 URL、从某处获取 JSON 文件，并在内容区域中创建博客文章列表。
借助 hashbang，Google 知道要访问 escaped_fragment URL 来获取其静态内容。
对于pushState，Google 什么也看不到，因为它无法使用JavaScript 代码加载JSON 并随后创建模板。
我能看到的唯一方法是在服务器端渲染模板，但这完全否定了将应用程序层推送到客户端的好处。
那么我说得对吗？pushState 对于客户端应用程序来说根本不适合 SEO？
Many people have been saying, use pushState rather than hashbang.
What I don't understand is, how would you be search-engine friendly without using hashbang?
Presumably your pushState content is generated by client-side JavaScript code.
The scenario is thusly:
I'm on example.com. My user clicks a link: href="example.com/blog"
pushState captures the click, updates the URL, grabs a JSON file from somewhere, and creates the listing of blog posts in the content area.
With hashbangs, google knows to go to the escaped_fragment URL to get their static content.
With pushState, Google just sees nothing as it can't use the JavaScript code to load the JSON and subsequently create the template.
The only way to do it I can see is to render the template on the server side, but that completely negates the benefits of pushing the application layer to the client.
So am I getting this right, pushState is not SEO friendly for client-side applications at all?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您需要搜索引擎来读取您的内容，
pushState是否不好？不，关于
pushState的讨论旨在完成与 hashbang 相同的一般过程，但具有更好看的 URL。想想当你使用 hashbangs 时到底会发生什么......你说：
换句话说，
example.com/#!/blog的链接example.com/?_escaped_fragment_=/blog为可以看到，它已经依赖于服务器了。 如果您没有从服务器提供内容快照，那么您的网站就无法正确编入索引。
那么 Google 将如何查看带有 PushState 的内容呢？
实际上，Google 会在
site.example/blog上看到它可以请求的任何内容。 URL 仍然指向服务器上的资源，并且客户端仍然遵守此契约。当然，对于现代客户来说，JavaScript 开辟了无需刷新页面即可检索内容并与之交互的新可能性，但契约是相同的。因此，
pushState的预期优雅之处在于，它为所有用户提供相同的内容，无论新老用户、是否支持 JS，但新用户获得增强的体验。如何让 Google 看到您的内容？
Facebook 方法 — 在 URL
site.example/blog上提供相同的内容，当您将/blog推送到状态时，客户端应用程序将转换为该内容。 （据我所知，Facebook 尚未使用pushState，但他们使用 hashbangs 来实现此目的）Twitter 方法 — 将所有传入 URL 重定向到 hashbang 等效项。换句话说，指向“/blog”的链接将
/blog推入状态。但如果直接请求，浏览器最终会到达#!/blog。 （对于 Googlebot，这将根据您的需要路由到_escaped_fragment_。对于其他客户端，您可以pushState返回漂亮的 URL）。那么，您会失去
pushState的_escaped_fragment_功能吗？在几个不同的评论中，你说
您提到的好处并非孤立于
_escaped_fragment_。它为您进行重写并使用专门命名的GET参数，这实际上是一个实现细节。没有什么特别之处是您无法使用标准 URL 实现的 — 换句话说，您可以使用/?content=/blog自行重写a href="http://httpd.apache.org/docs/current/mod/mod_rewrite.html" rel="nofollow noreferrer">mod_rewrite 或服务器的等效项。如果您根本不提供服务器端内容怎么办？
如果您无法重写 URL 并在
/blog（或您推送到浏览器中的任何状态）提供某种内容，那么您的服务器实际上不再遵守HTTP 合约。这很重要，因为页面重新加载（无论出于何种原因）都会提取此 URL 上的内容。 （请参阅https://wiki.mozilla.org/Firefox_3.6/PushState_Security_Review —“如果推送了内容，view-source 和 reload 都会在新的 URI 处获取内容。”）
这并不是说在客户端绘制一次用户界面并通过 JS API 加载内容是不好的目标，只是它没有真正考虑到 HTTP 和 URL，而且基本上不向后兼容。
目前这正是 hashbang 的用途——表示在客户端而不是服务器上导航的不同页面状态。例如，重新加载将加载相同的资源，然后该资源可以读取、解析和处理哈希值。
恰好它们也被用来（尤其是 Facebook 和 Twitter）将历史记录更改到服务器端位置，而无需刷新页面。 正是在这些用例中，人们建议放弃 hashbangs 而使用 PushState。
如果您在客户端呈现所有内容，则应该将
pushState视为更方便的历史记录的一部分API，而不是使用 hashbangs 的方法。Is
pushStatebad if you need search engines to read your content?No, the talk about
pushStateis geared around accomplishing the same general process to hashbangs, but with better-looking URLs. Think about what really happens when you use hashbangs...You say:
So in other words,
example.com/#!/blogexample.com/?_escaped_fragment_=/blogAs you can see, it already relies on the server. If you aren't serving a snapshot of the content from the server, then your site isn't getting indexed properly.
So how will Google see anything with pushState?
Actually, Google will see whatever it can request at
site.example/blog. A URL still points to a resource on the server, and clients still obey this contract. Of course, for modern clients, JavaScript has opened up new possibilities for retrieving and interacting with content without a page refresh, but the contracts are the same.So the intended elegance of
pushStateis that it serves the same content to all users, old and new, JS-capable and not, but the new users get an enhanced experience.How do you get Google to see your content?
The Facebook approach — serve the same content at the URL
site.example/blogthat your client app would transform into when you push/blogonto the state. (Facebook doesn't usepushStateyet that I know of, but they do this with hashbangs)The Twitter approach — redirect all incoming URLs to the hashbang equivalent. In other words, a link to "/blog" pushes
/blogonto the state. But if it's requested directly, the browser ends up at#!/blog. (For Googlebot, this would then route to_escaped_fragment_as you want. For other clients, you couldpushStateback to the pretty URL).So do you lose the
_escaped_fragment_capability withpushState?In a couple of different comments, you said
The benefits you mentioned are not isolated to
_escaped_fragment_. That it does the rewriting for you and uses a specially-namedGETparam is really an implementation detail. There is nothing really special about it that you couldn't do with standard URLs — in other words, rewrite/blogto/?content=/blogon your own using mod_rewrite or your server's equivalent.What if you don't serve server-side content at all?
If you can't rewrite URLs and serve some kind of content at
/blog(or whatever state you pushed into the browser), then your server is really no longer abiding by the HTTP contract.This is important because a page reload (for whatever reason) will pull content at this URL. (See https://wiki.mozilla.org/Firefox_3.6/PushState_Security_Review — "view-source and reload will both fetch the content at the new URI if one was pushed.")
It's not that drawing user interfaces once on the client-side and loading content via JS APIs is a bad goal, its just that it isn't really accounted for with HTTP and URLs and it's basically not backward-compatible.
At the moment, this is the exact thing that hashbangs are intended for — to represent distinct page states that are navigated on the client and not on the server. A reload, for example, will load the same resource which can then read, parse, and process the hashed value.
It just happens to be that they have also been used (notably by Facebook and Twitter) to change the history to a server-side location without a page refresh. It is in those use cases that people are recommending abandoning hashbangs for pushState.
If you render all content client-side, you should think of
pushStateas part of a more convenient history API, and not a way out of using hashbangs.对于那些不想在 URL 中出现 hash-bangs 的人来说，使用 Google 建议的元标记怎么样：
请参阅此处了解更多信息：
https://developers.google.com/webmasters/ajax-crawling/ docs/getting-started
不幸的是，我认为 Nicole 没有澄清我认为 OP 遇到的问题。问题很简单，如果我们不使用 hash-bang，我们就不知道我们正在向谁提供内容。 Pushstate 并没有为我们解决这个问题。我们不希望搜索引擎告诉最终用户导航到某个输出未格式化 JSON 的 URL。相反，我们创建 URL（触发对更多 URL 的其他调用），通过 AJAX 检索数据并以我们喜欢的方式将其呈现给用户。如果用户不是人类，那么作为替代方案，我们可以提供 html 快照，以便搜索引擎可以正确地将人类用户引导至他们期望找到所请求数据的 URL（并且以可呈现的方式）。但最终的挑战是我们如何确定用户的类型？是的，我们可以使用 .htaccess 或其他东西来重写我们检测到的搜索引擎机器人的 URL，但我不确定这有多全面和面向未来。谷歌也可能会惩罚做这种事情的人，但我还没有充分研究过。因此（pushstate + google 的元标记）组合似乎是一个可能的解决方案。
What about using the meta tag that Google suggests for those who don't want hash-bangs in their URLs:
<meta name="fragment" content="!">See here for more info:
https://developers.google.com/webmasters/ajax-crawling/docs/getting-started
Unfortunately I don't think Nicole clarified the issue that I thought the OP was having. The problem is simply that we don't know who we are serving content to if we don't use the hash-bang. Pushstate does not solve this for us. We don't want search engines telling end-users to navigate to some URL that spits out unformatted JSON. Instead, we create URLs (that trigger other calls to more URLs) that retrieve data via AJAX and present it to the user in the manner we prefer. If the user is not a human, then as an alternative we can serve an html-snapshot, so that search engines can properly direct human users to the URL that they would expect to find the requested data at (and in a presentable manner). But the ultimate challenge is how do we determine the type of user? Yes we can possibly use .htaccess or something to rewrite the URL for search engine bots we detect, but I'm not sure how fullproof and futureproof this is. It may also be possible that Google could penalize people for doing this sort of thing, but I have not researched it fully. So the (pushstate + google's meta tag) combo seems to be a likely solution.
关于pushState 和
#!的所有有趣的讨论，我仍然看不出pushState 如何取代原海报所要求的#! 的用途。当然，我们的解决方案是使用
#!来使 99% 基于 JavaScript 的 Ajax 站点/应用程序可进行 SEO。由于客户端渲染是通过 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 版本。对于非 SEO 内容（例如仅在用户登录后才能看到的页面），不需要存在 PHP 版本。一切都很简单。
我仍然很困惑一些前端开发人员如何在不使用服务器端技术与浏览器技术的情况下开发出色的网站（利用 Google 文档的丰富性）...如果甚至没有启用 JavaScript，那么我们 99% JavaScript 的解决方案如果没有 PHP，当然不会做任何事情。
如果启用了 JavaScript，则可以有一个好的 URL 登陆 PHP 服务的页面并重定向到 JavaScript 版本，但从用户的角度来看这并不好，因为用户是更重要的受众。
附带说明一下。如果您只是制作一个无需任何 JavaScript 即可运行的简单网站，那么如果您想逐步增强用户体验，从简单的静态呈现内容变成更好的内容，那么我可以看到 PushState 非常有用，但如果您想为用户提供go get 的最佳体验...假设您最新的游戏是用 JavaScript 或 Google Docs 之类的东西编写的，那么它在该解决方案中的使用就受到了一定的限制，因为与愿景相比，在用户体验变得痛苦之前，优雅地回退只能走这么远网站的。
All interesting talk about pushState and
#!, and I still cannot see how pushState replaces #!'s purpose as the original poster asks.Our solution to make our 99% JavaScript-based Ajax site/application SEOable is using
#!of course. Since client rendering is done via HTML, JavaScript and PHP we use the following logic in a loader controlled by our page landing. The HTML files are totally separated from the JavaScript and PHP because we want the same HTML in both (for most part). The JavaScript and PHP do mostly the same thing, but the PHP code is less complicated as the JavaScript is a much richer user experience.The JavaScript uses jQuery to inject into HTML the content it wants. PHP uses PHPQuery to inject into the HTML the content it wants - using 'almost' the same logic, but much simpler as the PHP version will only be used to display an SEOable version with SEOable links and not be interacted with like the JavaScript version.
All are the three components that make up a page, page.htm, page.js and page.php exist for anything that uses the escaped fragment to know whether to load the PHP version in place of the JavaScript version. The PHP version doesn't need to exist for non-SEOable content (such as pages that can only be seen after user login). All is straightforward.
I'm still puzzled how some front end developers get away developing great sites (with the richness of Google Docs) without using server-side technologies in conjunction with browser ones... If JavaScript is not even enabled, then our 99% JavaScript solution will of course not do anything without the PHP in place.
It is possible to have a nice URL to land on a PHP served page and redirect to a JavaScript version if JavaScript is enabled, but that is not nice from a user perspective since users are the more important audience.
On a side note. If you are making just a simple website that can function without any JavaScript, then I can see pushState being useful if your want to progressively enhance your user experience from a simple statically rendered content into something better, but if you want to give your user the best experience from the go get... let's say your latest game written in JavaScript or something like Google Docs then it's use for this solution is somewhat limiting as gracefully falling back can only go so far before the user experience is painful compared to the vision of the site.