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分析Display广告报表

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

Google”深度文章“测试

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

从下面的截屏中,皮特在搜索[墨西哥餐厅]是触发了如下的结果。本地结果和地图出现在了搜索结果中,同时也出现了里森,纽约时报,华尔街日报对餐厅的评价文章。

下面是截屏内容:

谷歌深度文章测试

Searchengineland在联系Google后其发言人证实了上述的说法。

Google总是在不断地测试算法、搜索结果和用户界面等等。所以这个测试不会让任何人感到意外,我们今后还将看到更多的此类测试。

Google仍从非法药物广告中获益

美国国家司法联盟(National Association of Attorneys General (NAAG))指责Google仍在搜索结果中向消费用户提供非法、假冒产品(包括毒品)显示结果,而且还允许经营此类产品的网站在Google上做广告。
NAAG要求Google的创始人之一拉里.佩奇出席6月17至19日在波士顿举行的司法大会并讨论相关问题。

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

我们每次检测都发现谷歌的搜索引擎上可以轻松找到非法商法,包话经营非处方危险药品,各种假冒商品,侵权电影、音乐、软件和游戏的网站。这种行为意味着Google置消费者于危险的境地,并助长一些不当行为,而Google却冠冕堂皇的从中获利。

Google曾于2011年花费了5亿美金和司法部处理此类事件,当时司法部的调查发现,谷歌帮助和允许加拿大药业诈骗公司在违反美国法律的情况下在Google上进行广告推广。

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

删除内容是可以完成的,但似乎谷歌不愿意删除那些未开方的处方药内容,以及盗版电影和歌曲的下载内容。

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

谷歌上购买羟可酮

Google的一位官方发言人当地时间下午就美国司法联盟的这一指责给出了如下回应:

我们非常重视用户的安全,并向司法总长Hood说明了Google是如何在抗击网上流通的非法和假冒药品上强化政策的。在过去的两年中,我们删除了300多万条非法药物广告,并定期删除那些被标记为违反YouTube政策的危险视频和非法内容。我们将继续致力于与像因特网安全药业中心这样的业内合作伙伴和组织合作处理此类事件。

但目前尚未得至Google是否会安排人员参加月底在波士顿举行的会议。.

AdWords图片扩展进入Beta测试

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

Google AdWords图片扩展

Google称每6次搜索中就有1次会出现图片内容。现在,文字广告可借机证明图片内容的重要性,此前产品图片广告是唯一能在AdWords中出现图图片内容搜索结果的广告,而且这也仅限于产品搜索结果。新的扩展为广告投放者提供图片显示更多的选择。

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

图片扩展更有更可能在Google认为搜索者想要找到图片内容时被触发。比如说,在搜索”豪华汽车设计”时,就比搜索”本地汽车商”更有可能触发图片扩展。

使用图片扩展广告投放者选取想要包含的图片并提交审核,当然,投放者需要有权使用该图片。

如果想加参加到beta测试中,需要填写表格或联系AdWords客服。

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的视频内容如下:

但请大家也不要忘记即便Google讨论某一算法甚至为某一算法申请专例,并不能代表Google一定会在线上搜索中使用该算法。

为何移动Safari用户的搜索来源显示为直接访问

苹果Safari浏览器

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

是的,很多仔细调查过这个情况的广告发布商可能认为他们早已知道其中的原因。那就是谷歌安全搜索,以及Google是如何在2011年10月改回此机制以屏蔽一些搜索词,也就意味着任何使用该机制的都会使得搜索推荐人的数据被去除而不传递。

事实并非完全如些。

Google安全搜索去除搜索词而非推荐网站

Google安全搜索确实会保留来自广告发布商的搜索关键词,当然除非那些广告发布商付费以出现在谷歌的广告中。Google安全搜索对搜索词进行处理而传递一个广义的搜索词,所以发布商们可以看到流量来自Google但却无法知道具体的搜索关键词。

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

移动版Safari不传递推荐者信息

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

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

什么是Meta Referrer标签

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

2012年3月,Google对如何处理推荐人报告进行另一个改变。曾经的标准做法是通过它的Web服务器将信息传弟给浏览器,Google此时开始使用推荐人元标签取而代之,以保证页面自身有效地嵌入推荐人信息。可以理解为页面本身报出推荐人信息,而非之前的Web服务器。

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

奇怪的是,Firefox并不存在这种”去除推荐者”的问题,有问题的反而是移动版Safari浏览器。所以Merity有关Firefox浏览器的说明可能并不准确。

移动版Safari不支持推荐者元标签

桌面版Safari在处理推荐人元标签时是毫无问题,但似乎移动版的并非如此。

有两种修复的方法:一种方法是Google可以恢复到之前的通过服务器传输推荐人信息的方法。但一旦这样做的话,在人们离开Google安全搜索环境而进入到不安全的内容发布网站时就会丢失掉这一信息,因为之前标准的推荐者传递机制就是这样做的。

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

Trulia开发谷歌眼镜房地产搜索应用

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

这家房地产搜索引擎将此计划公布给了旧金山NBC的附属新闻部门,并于周一在博客中分享了更多细节。

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

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

Trulia以下的演示视频表明了该应用的使用方法和功能:

如果该应用确如视频中所描述的那样的话,它将是一个我们所能遇到的非常强大的谷歌眼镜应用。

Trulia公司博客并没有说明此应用的完成时间,只是说开发团队希望该应用能”尽快”上线。

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从业者花费过多时间用于链接建设,并且太过关注搜索引擎本身。.

以下是视频内容以及相关总结:

算法更新Vs.数据刷新

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

Panda和Penguin的更新并非是为Google创造更多营收

很多业界人士认为Google发布诸如Panda和Penguin之类的算法更新,是为了在短期内增加营收。Matt说这绝对是误读,算法和自然搜索跟营业收入是完全不挂钩的。

Matt同时还说到根据早前的营收报表,分析认为Panda是导致Google接下来数季度收入无法增高的原因之一。因为Panda会对Google收入带来短期的负面影响,为什么呢?因为Panda的目标就是消除通过AdSense获取收入的一些低质站点。

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

SEO人员过度关注链接建设和搜索引擎

Matt在本视频中的最一个论点是讨论SEO人员在哪些领域花费了过多的精力。其中包括链接建设和搜索引擎,而不是他们的用户。Matt说他们应该在社交媒体以及其它领域花更多的时间来创建网站的认知度。

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