9 Things You Need to Know About Google’s Mobile-Friendly Update

Rumors are flying about Google’s upcoming mobile-friendly update, and bits of reliable information have come from several sources. My colleague Emily Grossman and I wanted to cut through the noise and bring online marketers a clearer picture of what’s in store later this month. In this post, you’ll find our answers to nine key questions about the update.

1. What changes is Google making to its algorithm on April 21st?

Answer: Recently, Google has been rolling out lots of changes to apps, Google Play, the presentation of mobile SERPS, and some of the more advanced development guidelines that impact mobile; we believe that many of these are in preparation for the 4/21 update. Google has been downplaying some of these changes, and we have no exclusive advanced knowledge about anything that Google will announce on 4/21, but based on what we have seen and heard recently, here is our best guess of what is coming in the future (on 4/21 or soon thereafter):

We believe Google will launch a new mobile crawler (probably with an Android user-agent) that can do a better job of crawling single-page web apps, Android apps, and maybe even Deep Links in iOS apps. The new Mobile-Friendly guidelines that launched last month focus on exposing JS and CSS because Android apps are built in Java, and single-page web apps rely heavily on JavaScript for their fluid, app-like experience.

Some example sites that use Responsive Design well in a single-page app architecture are:

  • Hulu.com,
  • Refinery29.com,
  • Facebook’s news feed,
  • Techcrunch.com,
  • The Google Play Store,
  • Pinterest.com, and of course
  • http://scrollsample.appspot.com/items from John Muller of Google.

Also, according to Rob Ousbey of Distilled, Google has been testing this kind of architecture on Blogspot.com (a Google property).

Google has also recently been pushing for more feeds from Trusted Partners, which are a key component of both mobile apps and single-page web apps since Phantom JS and Prerender IO (and similar technologies) together essentially generate crawlable feeds for indexing single-page web apps. We think this increased focus on JS, CSS, and feeds is also the reason why Google needs the additional mobile index that Gary Illyes mentioned in his “Meet the Search Engines” interview at SMX West a couple weeks ago, and why suddenly Google has been talking about apps as “first class citizens,” as called out by Mariya Moeva in the title of her SMX West presentation.

A new mobile-only index to go with the new crawler also makes sense because Google wants to index and rank both app content and deep links to screens in apps, but it does not necessarily want to figure them into the desktop algorithm or slow it down with content that should never rank in a desktop search. We also think that the recent increased focus on deep links and the announcement from Google about Google Play’s new automated and manual review process are related. This announcement indicates, almost definitively, that Google has built a crawler that is capable of crawling Android apps. We believe that this new crawler will also be able to index more than one content rendering (web page or app screen data-set) to one URL/URI and it will probably will focus more on feeds, schema and sitemaps for its own efficiency. Most of the native apps that would benefit from deep linking are driven by data feeds, and crawling the feeds instead of the apps would give Google the ability to understand the app content, especially for iOS apps, (which they are still not likely able to crawl), without having to crawl the app code. Then, it can crawl the deep-linked web content to validate the app content.

FYI: Garry Illyes mentioned that Google is retiring their old AJAX indexing instructions, but did not say how they would be replaced, except to specify in a Google+ post that Google would not click links to get more content. Instead, they would need an OnLoad event to trigger further crawling. These webmaster instructions for making AJAX crawlable were often relied on as a way to make single-page web apps crawlable, and we think that feeds will play a role here, too, as part of the replacement. Relying more heavily on feeds also makes it easier for Google to scrape data directly into SERPS, which they have been doing more and more. (See the appendix of this slide deck, starting on slide 30, for lots of mobile examples of this change in play already.) This probably will include the ability to scrape forms directly into a SERP, à la the form markup for auto-complete that Google just announced.

We are also inclined to believe that the use of the new “Mobile-Friendly” designation in mobile SERPS may be temporary, as long as SEOs and webmasters feel incentivized to make their CSS and JavaScript crawlable, and get into the new mobile index. “Mobile-Friendly” in the SERP is a bit clunky, and takes up a lot of space, so Google may decide switch to something else, like the “slow” tag shown to the right, originally spotted in testing by Barry Schwartz. In fact, showing the “Slow” tag might make sense later in the game, after most webmasters have made the updates, and Google instead needs to create a more serious and impactful negative incentive for the stragglers. (This is Barry’s image; we have not actually seen this one yet).

In terms of the Mobile-Friendly announcement, it is surprising that Google has not focused more on mobile page speed, minimizing redirects and avoiding mobile-only errors—their historical focus for mobile SEO. This could be because page speed does not matter as much in the evaluation of content if Google is getting most of its crawl information from feeds. Our guess is that things like page speed and load time will rebound in focus after 4/21. We also think mobile UX indicators that are currently showing at the bottom of the Google PageSpeed tool (at the bottom of the “mobile” tab) will play into the new mobile algorithm—we have actually witnessed Google testing their inclusion in the Mobile-Friendly tool already, as shown below, and of course, they were recently added to everyone’s Webmaster Tools reports. It is possible that the current focus on CSS and JavaScript is to ensure that as many pages are in the new index as possible at launch.

2. If my site is not mobile-friendly, will this impact my desktop rankings as well?

Answer: On a panel at SMX Munich (2 weeks after SMX West) Zineb from Google answered ‘no’ without hesitation. We took this as another indication that the new index is related to a new crawler and/or a major change to the infrastructure they are using to parse, index, and evaluate mobile search results but not desktop results. That said, you should probably take some time soon to make sure that your site works—at least in a passable way—on mobile devices, just in case there are eventual desktop repercussions (and because this is a user experience best practice that can lead to other improvements that are still desktop ranking factors, such as decreasing your bounce rate).

3. How much will mobile rankings be impacted?

Answer: On the same panel at SMX Munich (mentioned above), Zineb said that this 4/21 change will be bigger than the Panda and Penguin updates. Again, we think this fits well with an infrastructure change. It is unclear if all mobile devices will be impacted in the change or not. The change might be more impactful for Android devices or might impact Android and iOS devices equally—though currently we are seeing significant differences between iOS and Android for some types of search results, with more significant changes happening on Android than on iOS.

Deep linking is a key distinction between mobile SERPs on the Android OS and SERPs on iOS (currently, SERPs only display Android app deep links, and only on Android devices). But there is reason to believe this gap will be closing. For example, in his recent Moz post and in his presentation at SMX West, Justin Briggs mentioned that a few sample iOS deep links were validating in Google’s deep link tool. This may indicate that iOS apps with deep links will be easier to surface in the new framework, but it is still possible that won’t make it into the 4/21 update. It is also unclear whether or not Google will maintain its stance on tablets being more like desktop experiences than they are like mobile devices, and what exactly Google is considering “mobile.” What we can say here, though, is that Android tablets DO appear to be including the App Pack results, so we think they will change their stance here, and start to classify tablets as mobile on 4/21.

Emails are also increasingly impacting SERPs—particularly mobile SERPs), since mobile email opens have grown by 180% in three years, and Google is trying to take advantage of this increased engagement on mobile devices. As of now, schema can be included in emails to drive notifications in the Google Now app, and also to let Google surface marked-up emails in a browser-based search. This all happens by virtue of Google crawling all emails that come into your Gmail account, and indexing them to your user-profile so that they are accessible and able to rank like this across all of your devices (even if you aren’t currently logged into your Gmail account on your phone). Optimizing emails for mobile search is also becoming more important, and in the 4/21 update Google could do more to push the use of Schema markup in emails to drive personalized search results like the one shown to the right.

Inclusions like this mean that even if you are able to maintain your keyword rankings in mobile search after April 21, you may not necessarily be able to sustain your mobile traffic.

4. What about sites that redirect to a mobile subdomain? Will they be considered mobile-friendly?

Answer: This is an interesting question, because immediately after the roll-out of the Mobile-Friendly tagging, we actually saw significantly more mDot (‘m.’) websites ranking well in the mobile SERPS. It’s almost like they counted the mobile subdomain as a Mobile-Friendly signal, but started the algorithm fresh, with no historical data to indicate which other sites had fewer obvious signals of mobility, like a responsive design, or an adaptive or dynamically served mobile site. It is also interesting to note that many of the Google representatives seem to have recently backed off of their strong insistence on responsive design. They still say that it is the least error-prone, and easiest to crawl and index, but they also now seem to be more willing to acknowledge the other viable mobile site architectures.

5. How do I know if my site meets Google’s requirements for mobile friendliness?

Answer: Google has created a Mobile-Friendliness tool that will give you a ‘yes’ or ‘no’ answer on a per-url basis. Pages are evaluated individually, so another quick way to get a sense for how your top pages perform is to do a “site:” query for the domain in question on your phone. That will allow you to see all the pages indexed to the domain, and evaluate which ones are considered Mobile-Friendly and which are not, without having to submit them to the tool one at a time.

Google has been clear that Mobile-Friendly test results are binary, meaning that your page is either Mobile-Friendly or it is not. There is no 50% or 70% Mobile-Friendly result possible—no middle ground. They have also taken care to specify that Google’s Mobile-Friendly evaluations are somewhat instant, implying that there is no proving-time or “sandbox” associated with the tag, but this could be somewhat misleading. There may be no intentional time-delay before a page is awarded the Mobile-Friendly notation, but it will only change after a crawl of the site indicates that the page is now Mobile-Friendly, so it is close to instantaneous if the pages are getting crawled on a very regular basis.

We have found that the tool result does not necessarily match up with what we are seeing on our phones. We have occasionally also noticed that sometimes two pages in the same page template will perform differently, even though the content that changes between the template is primarily text. Both of these variations could simply be an indication of real-time delay between the tool and the crawler—the tool does an ad-hoc check on the URL to assess mobile-friendliness, but if the bot has not been by the site to evaluate its mobile friendliness recently, then the page in question would not yet have the Mobile-Friendly designation in the SERP. With this in mind, remember that when you are updating a page, and pushing it live for testing, you must use the tool to see if the update has been successful, until the site is re-crawled. This also means that once you see success in the tool, the best way to get the Mobile-Friendly designation to show up in the results faster might just be to push a sitemap in Webmaster tools, and try to trigger a fresh crawl.

6. How does having a mobile app impact my mobile rankings?

Answer: There are two things to consider here. First, if a mobile search query is highly correlated with mobile app listings (the app “download pages” in the Google Play and iOS App Stores), your app could see significantly more visibility within mobile search results pages. This is because Google has started treating apps as a new kind of universal search result, returning an “App Pack” of Google Play results for certain searches on Android devices (shown at the right), and adding an Apps drop-down to the main nav-bar on iOS devices (not shown).

An “App Pack” is a group of related apps that rank together for a given query, shown together in a box separate from the inline organic search results. It has different formatting and an “Apps” header. These often float to the top of a mobile search result, pushing the second or sometimes even the first organic result below the fold. This is also discussed in Justin Briggs’ article about apps. Currently, there is a high correlation between Google Play “App Pack” rankings and exact-match keywords in the app title. Google also seems to be evaluating app quality here and tries to serve only higher-than-average rated apps in the App Pack (this generally tends to be around a 3.5 – 4 star minimum for common keyword phrases).

If Google starts to serve these App Packs on iOS device searches as well, all apps that have keyword-optimized titles and have high-quality ratings and reviews could jump up to the top of the mobile web SERPs, increasing their visability and likely downloads. Conversely, mobile websites that currently enjoy an above-the-fold #1 or #2 organic ranking may get pushed below the fold in mobile SERPs, especially for queries that are highly correlated with mobile app results. This could cause a negative impact on mobile website visibility (without necessarily changing standard numeric rankings), in cases where a query returns a mobile App Pack—regardless of whether or not an app within that pack is yours.

Second, Mariya Moeva (Google Webmaster Trends Analyst) recently announced at SMX West that Google will be considering “high quality” apps to be a positive ranking factor in mobile search. We took this to mean that Deep Links between your website and your app will improve your website rankings in mobile search. Deep Links are different from app store listings in the App Store or Google Play, because they link directly to a specific screen within your app experience. They look just like regular links in the mobile search result, but when you click them, you are given the option of opening the link in on the web or in the app.

Currently, if you add Deep Links to your Android mobile app and associate your app URIs with corresponding (content-matching) webpages, Google will recognize the connection between your app content and your web content (and allow users who have your app installed to access your content directly in the mobile app). As it is now, the only way for Deep Links to your app contents to appear in search results is:

  • For app screens to have a 1-1 content parity with webpages
  • For those screens to have proper Deep Link coding that associates them with the corresponding pages on the website, AND
  • For your app to be installed on the searcher’s device. If the app is not installed or there is no corresponding web content, the links in the SERP will just behave as normal, web links.

Mariya didn’t state exactly how Google will be evaluating the quality of apps, but we can guess that Google will be considering signals like star ratings, reviews, and +1s. And if what we assume about the 4/21 update proves to be true, it is possible that app URIs without corresponding Deep Linked web content may rank independently in a mobile SERP from information that Google aquired via app feeds. In this case, “app quality” could be a positive mobile ranking signal for its own URIs/ screens, and not just the website it is associated with. This would be a great boon for app descovery.

7. Do I need an app, and if so, should it be Android, iOS or both? What if I have a limited budget?

Answer: If you have the budget to develop both a mobile app and a mobile website, there can be significant value to maintaining both, particularly if you leverage the mobile app as a “value add” for your customers and not just a website duplicate (though enabling some functionality duplication is necessary for deep linking). If you have a limited budget, you will have to make a choice, but it is important to consider this a business choice and not primarily an SEO choice. Your business might be well served by a mobile website or might be better served by a mobile app with only a promotional mobile web landing page meant to send web traffic to app stores (ex. Tinder). In general, most businesses can be extremely well served by a mobile website and should focus their budget on making that experience great across many devices. We only recommend going “app-first” if you are trying to offer an experience that cannot be delivered well on a mobile website. Experiences that offer a valuable offline utilities (think photo-editing apps), or take advantage of heavy computing (like gaming apps) or rely on non-web input elements such as device accelerometers or GPS, are often better suited for an app.

Apps are generally riskier because they require more up-front investment, and have to be tightly in sync with app store guidelines and approval processes that you have no control over. There are a lot of barriers to entry; just building and maintaining an experience can cost an average of $100k per platform, so it’s important that you know this is the right experience for your customers before you choose this path.

If you decide that an app experience is the best choice for your business (or you have budgeted an app in addition to your mobile web experience), you can use the operating system data in Google Analytics to help you determine which Operating System is more popular among your users. If you don’t have this data because you don’t have a website yet or you have too limited a mobile audience to determine a trend, you should choose the platform that best matches with your monetization strategies. iOS users tend to spend more money than their Android counterparts, but there are more total Android users around the world than iOS users. The implication is that if you plan to monetize your app with user transactions like In App Purchases (IAPs) or Subscriptions, iOS may be the way to start, but if you plan to monetize your app with advertisements, Android could be just as lucrative, if not more so. If Android app discovery is made easier with the 4/21 update but iOS app discovery is not, that could also factor into the decision process.

8. How is mobile traffic impacted by the user search query? Is there a way I can find out if my top keywords are mostly desktop or mobile keywords?

Answer: Search queries actually matter more and more for mobile, because Google is trying to do a much better job of anticipating and embracing a user’s intent from the query. This means that often, Google is presenting the information a searcher requests directly in the search result above the organic rankings. SEOs are used to this for local-mobile searches, but it is now happening for all kinds of searches, so it can steal traffic that would otherwise go to the site and can skew success metrics.

Google has expanded the types of information that they scrape and pull from a site directly into an answer box, especially in mobile. They have also increased and diversified the number of aggregator-style “Sponsored” results that show up in mobile—especially on Android. The top mobile search result for most flight, hotel, music, and TV show queries are now specially designed, sponsored, aggregated results that push the old organic results below the fold. Whenever you see a little grey ‘i’ in the upper right hand corner of a mobile search result – especially a specially formatted list of results that Google has aggregated for you, that means that Google is probably getting a small portion of any related transaction, even if it is just the website paying for the click. Simple blue-link search results may soon be a thing of the past—especially above the fold.

Even regular, non-aggregator-style PPC results are taking up more room and looking more compelling with click-to-call, star ratings, app icons, links for directions and ad extensions, so these may be more of a threat for SEO moving forward (shown on the right). There is a long list of examples that we shared in the Appendix of Cindy’s SMX Munich deck about the Future of Mobile SEO. With all the scraping, PPC may be the only way to out-rank Google and get above the fold for some queries in the mobile SERP.

If you have not seen Dr. Pete’s presentation from SMX West this year about the Changing of Google SERPS, you really must! It addresses this question in the desktop format, but I think the crux of what he is saying is even truer in mobile. This Dr. Pete quote from a related interview is very telling:

“Google is essentially competing against us with our own information, and I think that’s a turning point in the relationship between Google and webmasters.” -Dr. Pete

In terms of which keywords are more mobile-oriented than desktop-oriented, this can be a difficult question. You can get some basic information from Webmaster Tools by filtering the keyword information to show mobile only queries, and you can do something similar in Google Analytics. Beyond that, there are some more sophisticated solutions, like those from Search Metrics and Brightedge, but those are often out of reach for smaller operations.

9. What is Google’s goal with all of these mobile-friendly changes?

There are obviously a lot of goals in the mix here, but we do believe that Google is making these changes primarily to provide a better mobile experience for searchers, and give people exactly what they want. That said though, they are also in it to make money. Being able to easily surface apps in a search result will help them drive more and better app development for Google Play and monetize their other content like TV shows, books, magazines, movies, and music—all of which have been threatened recently by competitors like Hulu, Amazon, and of course iOS App Store and iTunes.

Google has been encouraging publishers to include transcripts with videos and song lyrics with songs. In the long run, those will help Google scrape and show those things in answer boxes, as shown at the right, but eventually they will probably also surface their own version of the content from Google Play, with links just below the answer box, so that you can watch the video or download the song directly to your phone on Google Play. When you think about Google’s intentions on this front, and try to envision the future, it is important to note that Google is actually already offering Google Play for iOS, which currently just provides the Google Music cloud-storage and a music subscription model. We expect this to expand as well, so that Google can expand their level of competitiveness here too.


Google Analytics中已集成GDN(Google Display Network)广告的报表,可通过Acquisition > AdWords > Display Targeting来进行访问。在谷歌分析中,可在Display Targeting报表中查看以下细分信息:
– Display Keywords
– Placements
– Topics
– Interests & Remarketing
– Gender
– Age
Google分析Display Targeting报表


Moz(前SEOmoz)市场研究员皮特.梅耶博士向Searchengineland透露,Google在搜索结果页面中正进行一个测试。测试的内容是是在对本地词的搜索结果中显示”深度文章“(In-depth articles,对某一话题的深度解析,旨在为用户提供更详细的信息)。







美国国家司法联盟(National Association of Attorneys General (NAAG))指责Google仍在搜索结果中向消费用户提供非法、假冒产品(包括毒品)显示结果,而且还允许经营此类产品的网站在Google上做广告。

在美国国家司法联盟的官方网站上并未找到相关论述,但今日美国和密西西比商业日报都转载了司法联盟的上述论述,该论述出自司法联盟知识产权委员会的联合主席Jim Hood:



密西西比商业日报文章称,知识产权委员会关心的不仅仅是违法药品和公司的广告,还有谷歌在将盗版内容驱逐出搜索引擎的所为与所不为。该委员会希望Google解释为什么他们愿意从搜索结果中彻底删除一部内容(如未成年色情片,德国纳粹的相关内容),却不删除其它的一些内容。 .


该知识产权委员会还想问Google,怎样并且将于何时屏蔽掉在输入类似”buy oxycodone”这类词时的自动推荐功能。 (Oxycodone中文为羟可酮,是一种具兴奋作用的止痛剂,属处方药,在网站买卖属非法行为。)






美国时间6月5日,Google宣布了AdWords中图片扩展(Image Extensions)官方beta版的正式发布。在过去的两个月中到处都能看到有人谈论图片扩展。图片扩展让AdWords广告投放者可以在文字广告旁显示相关的图片。Google对于其显示效果的设计肯定还会有修改,当前版本的范例如下:

Google AdWords图片扩展


截至当前,还不清楚能在同一个搜索结果中显示多少条带图片的广告,以及这一扩展是否有与产品列表广告(Product Listing Ads)重叠之处。从上面的例子看,该扩展可能会与Sitelinks或者其它扩展整合在一起。




Matt Cutts谈Rel=”author”

Google反垃圾组的负责人Matt Cutts在新的视频中谈到了使用rel=”author”标签如何潜在地帮助Google的反垃圾组提升搜索质量。
Matt Cutts说到从匿名的网络转向实名的网络将有助于Google了解到书写内容的人的权威度以及人们普遍的信任度。也有助于Google区分出垃圾信息制造者以及具有权威及信任度的作者。

视频中Matt Cutts所举的例子是Searchengineland.com的创始人Danny Sullivan。他举例说如果Danny在PR值很低的论坛中发帖,Google可能会赋予Danny所发帖更高的权威值,即便整个域名或论坛具有很低的PR值。

Matt Cutts的视频内容如下:




自从去年9月发布商们发现从iOS 6上使用Safari浏览器在Google上搜索进入网站的访客似乎被计算成了直接访问,而非来自搜索引擎。最终结果,并非神秘的Google截断数据,而事实上的原因原来是因为移动版的Safari不支持 “meta referrer”标签。





Google分析用户对“Not Provided”的情况再熟悉不过了,这些被处理过的搜索关键词通常成为最大流量来源,被称作”not provided”。


对于移动版Safari浏览器来说,iOS 6的出现导致奇怪的事情发生。并不是搜索词被经过处理,事实上任何推荐者(相当于网络上的来电人ID)信息都没有被传递。使用移动版Safari的用户来至Google搜索,但当他们点击搜索结果链接时,发布商们看到的数据是直接访问,似乎Google并没有参与其中。

结果,很多发布商可能看到搜索流量的下降,而事实上并非真的是搜索流量有下降,只是计算时未拿到正确属性罢 了。事看来看,不太确定BuzzFeed上月所声称的搜索流量下降是这个原因所致,但至少它是其中一个因素。

什么是Meta Referrer标签

为什么移动版的Safari浏览器相比较其它同样使用安全搜索的移动版浏览器(Firefox, Chrome等)表现如此截然不同呢?其它浏览器并流量完全去除掉推荐人信息的传递,这主要源自meta推荐人标签。


在浏览器支持该标签的情况下,这种做法自然不会有问题。Stephen Merity最近写道,Chrome和Safari是支持的,而Firefox和IE则不支持。因而,后两者可能无法正确报出来自Google,Faceboo,Reddit和Hacker News的推荐。





另一种方法是移动版Safari像桌面版那样开始支持推荐人元标签,Danny Sullivan曾就此问题问过苹果和谷歌公司,但双方均未做出任何评论。


Google Glass也许永远都不会成为流行的消费设备,但这并不能阻止像Trulia这样的公司的开发热情,Trulia正在开发Google Glass上的首个房地产搜索应用。


此应用一旦上线,将会按照用户对房屋的搜索喜好去Trulia的数据库中匹配不动产列表,然后将匹配结果返回到谷歌眼镜上。并且看起来该应用将会添加诸如添加房地产信息至”My Trulia”,在用户靠近匹配不动产时接收消息,提供导航甚至是通过谷歌眼镜给销售拨打电话的功能。

该应用与大多数桌面房地产搜索网站的工作原理相同,所以可能让人觉得没什么特别之处,但实际上它还是有其特别之处的。截至目前,在Goolge Glass上的大多数应用仅能提供在其它设备上极小部分的功能。这主要受限于谷歌眼镜自身的设计特征。所以能够在谷歌眼镜上看到一个和网上类似功能的房地产App就已经相当特别了。




Matt Cutts谈SEO人员的一些误解

Google的反垃圾组负责人Matt Cutts,发布了一段题为”SEO行业的误解有哪些?“的视频(What are some misconceptions in the SEO industry?)。Matt在5分钟的简短视频中讨论了三个主题:
(1) SEO误以为Google的算法更新会带来数据的刷新,

(2) Panda和Penguin算法不是要让Google在短期内挣更多的钱;

(3) SEO从业者花费过多时间用于链接建设,并且太过关注搜索引擎本身。.



Matt说他看到SEO行业最大的误解之一就是误以为算法的更新会带来数据的刷新。简单地说算法更新(algorithm update)是Google修改搜索结果排名的算法,将有可能影响到搜索结果的排名、收录或过滤 。而数据刷新‘(data refresh)是Google更新算法运行位置的数据。比如,最近对Penguin进行了更新,这次更新是一个数法更新。它对算法工作机制进行了修改。而在此之前的Penguin 3和2则大多仅仅是数据刷新。




然后,Matt Cutts解释了Google是如何看待长期目录的,就是让搜索者快乐,这样他们会不停地回来搜索更多内容。Google有很多方法让用户找到他们所需要的内容,Matt Cutts反复强调Google很少会看重短期营业收入目标的。 显然这是Matt从公关角度所表达的观点,也许他本人100%相信这一点的。



然后他又提到了一些好站点曾经都将主要精力放在网站设计和用户体验上。这样用户才会开心并推荐给更多的人。Matt说到Craigslist就是一个很好的站点,便该站的用户体验不够好。因而,有很多初出茅庐的网站可以通过优秀的用户体验而抢占至市场份额。 i