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，谷歌知道去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 为那些不希望在其 URL 中使用 hash-bang 的人推荐的元标记:

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/文档/入门

See here for more info: 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 的元标记)组合似乎是一个可能的解决方案.

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