pushState和SEO [英] pushState and SEO

问题描述

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

Many people have been saying, use pushState rather than hashbang.

我不明白的是，如果不使用hashbang，你将如何成为搜索引擎友好的？

What I don't understand is, how would you be search-engine friendly without using hashbang?

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

Presumably your pushState content is generated by client-side JavaScript code.

因此场景是：

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

I'm on example.com. My user clicks a link: href="example.com/blog"

pushState捕获点击，更新URL，从某个地方获取JSON文件，并在内容区域中创建博客帖子列表。

pushState captures the click, updates the URL, grabs a JSON file from somewhere, and creates the listing of blog posts in the content area.

使用hashbangs，google知道转到escaped_fragment URL以获取他们的静态内容。

With hashbangs, google knows to go to the escaped_fragment URL to get their static content.

使用pushState，Google只看不到任何东西，因为它无法使用JavaScript代码加载JSON并随后创建模板。

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.

所以我说得对，pushState对客户端应用程序来说不是SEO友好的吗？

So am I getting this right, pushState is not SEO friendly for client-side applications at all?

推荐答案

使用Google为那些不希望在其网址中使用哈希爆炸的人建议的元标记怎么样：
< meta name =fragmentcontent =！> ;

What about using the meta tag that Google suggests for those who don't want hash-bangs in their URLs: <meta name="fragment" content="!">

有关详细信息，请参阅此处：
https：/ /developers.google.com/webmasters/ajax-crawling/docs/getting-started

See here for more info: https://developers.google.com/webmasters/ajax-crawling/docs/getting-started

不幸的是，我不认为NickC澄清了我认为的问题OP有。问题很简单，如果我们不使用hash-bang，我们就不知道我们要为哪些内容提供服务。 Pushstate并没有为我们解决这个问题。我们不希望搜索引擎告诉最终用户导航到一些吐出未格式化JSON的URL。相反，我们创建URL（触发对更多URL的其他调用），通过AJAX检索数据并以我们喜欢的方式将其呈现给用户。如果用户不是人，那么作为替代方案，我们可以提供html快照，以便搜索引擎可以正确地将人类用户引导到他们期望在（并且以可呈现的方式）找到所请求数据的URL。但最终的挑战是我们如何确定用户的类型？是的，我们可以使用.htaccess或其他东西重写我们检测到的搜索引擎机器人的URL，但我不确定这是多么完整和未来的防范。 Google也可能会因为做这类事而惩罚人，但我还没有完全研究过它。所以（pushstate + google的元标记）组合似乎是一种可能的解决方案。

Unfortunately I don't think NickC 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和SEO的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！